search

opensearch-project / OpenSearch

🔎 Open source distributed and RESTful search engine.
https://opensearch.org/docs/latest/opensearch/index/
Apache License 2.0
9.77k stars 1.82k forks source link

[DISCUSS]: Contributor Ladder Proposal - aka How to become a maintainer #679

Open geekygirldawn opened 3 years ago

geekygirldawn commented 3 years ago

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.

Contributor

Description: A contributor contributes directly to the project and adds value to it, making the maintainers’ lives easier. Contributions need not be code.

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.

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.

Maintainer roles may also include non-code roles including:

Admin

Description: An admin has administrative responsibilities across the entire GitHub organization and can do things like cut releases.

stockholmux commented 3 years ago

Hey folks - FYI - this is not a vote that is binding. Definitely good form of feedback though.

dblock commented 3 years ago

I don't disagree in principle, but I don't agree on many things in language. The biggest 3 for me are:

  1. It's not clear that this ladder is incremental as we don't explicitly state approver = member + contributor + ... .
  2. We cite "regular" contributions, which implies if I stopped contributing one day I will be downgraded, which I disagree with.
  3. Approvers can't merge, which seems like we "trust you, but not really", maybe we don't need approvers at all.
jcgraybill commented 3 years ago

As everyone responds, it would be awesome if you could add a comment with details about what aspects of this contributor ladder particularly do & don't resonate with you, or that appeal & don't appeal to you. There's a lot here, so a lot of potential material for enlightening discussions.

geekygirldawn commented 3 years ago

It sounds like these decisions and discussions are happening between stakeholders internally within Amazon (as @stockholmux mentions in his forum post). Since there doesn't seem to be a point in continuing with this vote here in the community, I'm going to close this issue.

dblock commented 3 years ago

@geekygirldawn thank you - I wouldn't say these are actively happening right now, we just didn't get to it as we're focusing on getting a working beta

nknize commented 3 years ago

we're focusing on getting a working beta

Note to all that community participation in this is helpful and encouraged. See @dblock issue here and open bug reports, patches, etc. that can be backported to ensure compatibility and stability.

nknize commented 3 years ago

I'm reopening this and renaming from [VOTE] to [DISCUSS] as an attempt to facilitate an ongoing healthy discussion around this topic and keep the progress (not perfection) train moving forward. It feels like the controversy turned a lot of folks away; which would be unfortunate. I hope I'm wrong. Losing the voices is detrimental to a community driven project and so if we've lost anyone's voice I'd like to humbly ask you return and continue helping the project move closer toward a process on how to bring external folks aboard. @jcgraybill raised some great points to consider that (I think) many OpenSource projects do not handle very well:

  1. Include users in the community.
  2. Start simple, add complexity as needed. Is there a core idea here that matters the most, where we could all focus our efforts?
  3. For approver/maintainer/admin roles, what is their responsibility to users? If a maintainer adds a feature that users depend on, what is their ongoing responsibility to support it, update it, and ensure a good transition...

Here are my thoughts:

  1. This is such a fascinating and important concept. It would be a great first step to add overly active and participating users as Triage Maintainers if/when that day comes. Not sure how they fit in this "contributor ladder" since they wouldn't be regularly submitting PRs but, instead, regularly submitting issues and contributing to the project board / roadmap? A good followup question is: how do you guard against the "loud" user that tries to over influence the roadmap to their agenda (since we all, in fact, bring an agenda). Maybe that's naturally addressed through the nomination process?
  2. My personal interest is figuring out how to bring the first developer maintainer on board since we already have several folks donating their personal time and resources to the project and earning that merit.
  3. Regarding a responsibility to the users, maintaining the entire codebase is the responsibility of all the maintainers. (e.g., I have a responsibility as a maintainer to help fix/improve all code that I did and did not write). That's just the name of the open source game and the responsibility you choose to take if you accept the invitation to become a maintainer. In my personal OSS experience, a vibrant project is one where no single maintainer is expected to continue to maintain the code they wrote forever. Popular and critical features outlive their authors. So I actually thought of this question differently: How do we reduce friction for maintainers to share and educate their peer Maintainers on their contributed feature(s)? The easier to navigate the codebase and follow the features, the easier it is to maintain. I think that discussion is separate from this one? So maybe it's a separate discuss topic.

Curious what others think and thanks in advance for not getting overly discouraged to the point of turning away.

jkowall commented 3 years ago

Thanks for re-opening this one @nknize I agree we need to open things up, but that's an Amazon decision. If it doesn't change soon, then the community will have to figure out the best course of action for the next steps to have a multi-company open source project.

If I need to escalate something internally at Amazon to make this a reality I will do that, but I was hoping that we'd just determine the next steps in public versus closed-door meetings. I would like to see changes in the community meetings (open doc where people can add agenda items and take notes, auto-recording for those who miss meetings).

As far as maintainers it seems that your steps make sense, it's more about sharing workload, and if there are issues they can be discussed, but I don't see that becoming a problem in this community since there will be votes. I'm game for you nominating some names and us voting as an open community. I think we have a lot of good non-AWS contributors already to start with as long as they have time to help with reviews and discussions of course.

geekygirldawn commented 3 years ago

I'm reopening this and renaming from [VOTE] to [DISCUSS] as an attempt to facilitate an ongoing healthy discussion around this topic and keep the progress (not perfection) train moving forward.

@nknize I worry about fragmenting this conversation. We already have a lot of discussion about this proposal in the forum thread, and now we have a second, but disconnected place where this discussion is happening. I created this as a place to vote, and closed it when it was decided that this wasn't ready for a vote, so this was never really intended to be a second place for a discussion on this topic.

It feels like the controversy turned a lot of folks away; which would be unfortunate.

I admit to being very frustrated with this project. I've spent a lot of time trying to help, and made no real progress, so this time spent seems wasted. I have 20+ years of experience working in open source, and this is the most frustrated I've been in an open source community for a long time. I'm not inclined to spend much more time on this when my efforts are better appreciated and more productive in the other communities that I contribute to.