Repository navigation
Define the maintainer role criteria and process #3524
Description
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.
Activity
handrews commentedon Feb 8, 2024
@darrelmiller @earth2marsh we should define (as briefly mentioned in today's call)
lornajane commentedon Feb 11, 2024
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 commentedon Feb 11, 2024
@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 commentedon Dec 12, 2024
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