Skip to content
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

Open
Tracked by #3516
handrews opened this issue Jan 25, 2024 · 3 comments
Open
Tracked by #3516

Define the maintainer role criteria and process #3524

handrews opened this issue Jan 25, 2024 · 3 comments
Labels

Comments

@handrews
Copy link
Member

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
Copy link
Member Author

handrews commented Feb 8, 2024

@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
Copy link
Contributor

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
Copy link
Member Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Todo
Development

No branches or pull requests

3 participants
@lornajane @handrews and others