-
Notifications
You must be signed in to change notification settings - Fork 9.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define the maintainer role criteria and process #3524
Comments
@darrelmiller @earth2marsh we should define (as briefly mentioned in today's call)
|
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) |
@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. |
Once its own new membership is established, @OAI/tsc needs to define
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.
The text was updated successfully, but these errors were encountered: