Five open PRs, and an offer to help out #180

Hi @stephenfin,

I opened five PRs against master. Collecting them here so you don't have to reconstruct the set, with a question about releases at the end.

All five are green on the full matrix. Each one closes a single issue and adds a regression test. Roughly cheapest first:

• PR Fix #173: strip whitespace from operation summary before rendering #174, for issue httpdomain renderer: block-scalar summary produces unpaired ** and literal asterisks in output #173. One line in _httpdomain.py. A summary written as a YAML block scalar renders literal ** on the page.
• PR Fix #171: close the request body's sourcecode block with a blank line #175, for issue Old renderer with :request: emits a sourcecode block without a trailing blank line, warning under -W #171. One line each in openapi30.py and openapi31.py. The request body's sourcecode block never gets closed, so docutils warns and -W builds fail. Both renderers carry the same bug, and fixing only the 3.0 copy would have been a no-op for 3.1 users.
• PR Fix #178: handle non-object request bodies in the 3.0 renderer #179, for issue Old renderer with :request: crashes with KeyError: 'properties' for a non-object request body on OAS 3.0 #178, which I filed alongside it. It ports the guard you added in cca8fc3 across to the 3.0 renderer, which still raises KeyError: 'properties' on a non-object request body.
• PR Fix #165: make the httpdomain renderer's whitespace delimited options usable #176, for issue Some of the new httpdomain options fail with "unknown option" error #165. The five options with None in option_spec are rejected as unknown options. The reporter's patch was right, and one shared converter covers http-methods-order as well.
• PR Fix #166: derive examples from allOf compositions of non-object schemas #177, for issue ValueError: dictionary update sequence element #0 has length 1; 2 is required #166. An allOf that targets a non-object schema crashes example generation. That shape is what code generators emit for a documented enum property, so it probably affects more specs than the report suggests.

Two things need a decision from you rather than a review.

PR #176 changes behavior for projects already using those options. As of 0.9.0 the options are accepted but inert, so a project with :response-examples-for: in its docs has been getting it silently ignored. After the fix it takes effect and the rendered output changes. I think that's correct, since the options are documented as working, but you may want it called out in the changelog.

I haven't opened a PR for issue #172 yet, because it needs a direction call first. There's a comment on that issue with the details. The short version is that issues #172, #168, and #160 all come out of the same few lines deciding how a generated value becomes a rendered body, so a single fix could close all three. Three separate PRs work too. Tell me which shape you want and I'll write it.

On releases: is there a rhythm I should plan around, or is it as needed? I ask as a downstream consumer with a pinned version, not to rush you. The Ray documentation renders its Jobs API reference with this extension now, and I expect to want the same for the KubeRay docs, so I'd rather work with your schedule than around it.

One last thing. I'd like to keep contributing past this batch, including the dull parts. Happy to triage old issues, write reproducers for reports that don't have one, or review incoming PRs. I'm not asking for commit rights. I'd rather be a regular contributor than someone who drops five patches and disappears. Tell me what would actually be useful.

Thanks for maintaining this.

Douglas