Five open PRs, and an offer to help out

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 #174, for issue #173. One line in _httpdomain.py. A summary written as a YAML block scalar renders literal ** on the page.
• PR #175, for issue #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 #179, for issue #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 #176, for issue #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 #177, for issue #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

Review PRs #174, #175, #176, #177, and #179, then read the details and comments on issue #172. The issue is ready only after the maintainer decides how to handle the related issues and release questions; no standalone change is defined here.