opensearch-project / opensearch-project/OpenSearch
[DISCUSS]: Contributor Ladder Proposal - aka How to become a maintainer
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 13.7k
- Forks
- 3k
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 108
Description
We’ve been talking about this proposal for a few weeks, and @nknize suggested that we start a new vote thread to make a decision. I tried to do this on the forum, but the forum will not accept replies of less than 20 characters, which makes adding just a +1, -1 impossible, so lets do the vote here, instead.
Please add a 👍 or 👎 on this issue to cast your vote. We'll close the voting and tally the results at the end of the day on Monday, May 17.
Feel free to add just a vote or you can comment below if you want to explain your vote or provide other thoughts on the proposal.
I’ve copied the most recent version of the proposal below to make sure people know what they are voting for, but you can read the whole discussion and see how the proposal evolved in the forum discussion.
Contributor Ladder
Community Member
Description: A community member participates in the community and contributes their time, thoughts, etc. Users are anonymous users of the project – once they stop being anonymous and participate, they become a community member.
- Responsibilities:
- Must follow the Code of Conduct
- How users can get involved with the community:
- Labeling issues
- Bug Triaging
- Participating in community calls
- Participating in the forums
Contributor
Description: A contributor contributes directly to the project and adds value to it, making the maintainers’ lives easier. Contributions need not be code.
- Responsibilities/Requirements include:
- Following the project contributing guide
- Following the Code of Conduct
- Criteria:
- Regularly submits PRs
- Provides comments and feedback on issues and PRs from other contributors
- Shows up at meetings
- Answers questions
Approver
Description: An approver approves pull requests before they're merged by maintainers. We all have unique skills and experiences, so when a person will be ready for this responsibility varies by contributor, but a rough guideline might be after submitting 20 PRs and providing feedback on 10 PRs from others.
- Responsibilities/Requirements include:
- Ensuring that contributions follow the contributing guide
- Following the Code of Conduct
- Reviewing and providing feedback on contributions from others in a timely manner
- Requirements:
- Agreement from 2 maintainers
- Additional privileges
- Has Github rights to approve (but not merge) pull requests in specific repositories
- Criteria:
- Experience as a contributor
- Regularly submits PRs
- Shows up at meetings
- Answers questions
Maintainer
Description: A maintainer is a contributor with commit access who can merge pull requests from others. Maintainer roles may include community managers, project managers, release managers, and docs managers.
- Responsibilities/Requirements include:
- Merging pull requests in a timely manner
- Ensuring that contributions follow the contributing guide
- Helping new contributors
- Following the Code of Conduct
- Requirements:
- A vote from the existing maintainers using an Apache-style procedural vote.
- Additional privileges
- Commit access to one or more project repos.
- Criteria
- Proven experience as a contributor and approver
- Shows up at meetings
- Answers questions
Maintainer roles may also include non-code roles including:
- Community Manager
- Project Manager
- Release Manager
- Docs Manager
- Etc.
Admin
Description: An admin has administrative responsibilities across the entire GitHub organization and can do things like cut releases.
- Responsibilities/Requirements include:
- Responsible for administration, infrastructure, and releases.
- Requirements:
- A vote from the existing maintainers using an Apache-style procedural vote.
- Additional privileges
- Admin access to the GitHub organization and other infrastructure.
- Criteria
- Previous administration experience
- Experience as a maintainer
- Shows up at meetings
- Answers questions
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the linked forum discussion and the contributor-ladder proposal in this issue before taking action. The stated next step is to cast a vote, with completion defined as closing the vote and tallying the results; no source files or tests are identified.
Written by the indexing model from the issue text.
Assessment
- Domain
- developer-experience
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100