Define the maintainer role criteria and process

[handrews]

Once its own new membership is established, @OAI/tsc needs to define

• The process for adding to @OAI/maintainer
• The criteria for being considered for @OAI/maintainer
• The scope of what @OAI/maintainer members can, should, and should not do

One criteria that might be considered is whether maintainers need to first be part of the @OAI/triage group.

Various other current Process issues, particularly around defining issue closure criteria, are likely relevant.

[handrews]

@darrelmiller @earth2marsh we should define (as briefly mentioned in today's call)

• what sort of changes can be merged with one approval
• what sort of changes can be approved by people not in one of the triage/maintainers/tsc groups (perhaps for some things, one approval with merge permissions and one from anyone who has been participating for a while might be enough)
• when needing multiple approvals, does the submitter ever count, or is it always "two people with merge access who are not the submitter"? (I can't remember what it was, but something in a past call made me wonder about this)

[lornajane]

Possibly useful reading: the equivalent documentation from the Kubernetes project, which has a recognised role between contributor and maintainer called "reviewer" which I thought was cool https://github.com/kubernetes/community/blob/master/community-membership.md

The submitter can never be an approver IMO - but an approver can merge. I don't think any approvals outside of the maintainer/tsc groups should count BUT we should encourage bystanders (especially but not exclusively triage members) to review regardless. Approving is one thing, but picking up missed points and giving thoughtful feedback is welcome from anyone. (I realise this question wasn't aimed at me, ignore as appropriate)

[handrews]

@lornajane yeah I think it's fine for folks to review (including using the "Approve" button). And when the PR is written in response to someone's request, it's often good to get their sign-off. But I agree on whose reviews count towards merging- that sometimes involves more considerations than just "is this technically correct."

One case that might be more tricky- I'd like it if @baywet could give approvals on JavaScript/Powershell/Workflow stuff, where he's probably the most qualified person around to do that. Even if he is not otherwise deeply involved in the spec-writing in a way that would normally be a criteria for being a "maintainer" (not to say you couldn't be, Vincent!). Since actually merging the spec is limited to the TSC, I think it is good to consider folks who contribute to other things in the repo for the maintainer level.

[lornajane]

Added guidelines for managing discussions, issues, and pull requests, and a description of the maintainer role to the contributing file: https://github.com/OAI/OpenAPI-Specification/blob/main/CONTRIBUTING.md#maintainers