Change proposal for the contribution ladder

[avishnu]

The current contribution ladder for OpenEBS has 4 stages, which are, in a nut-shell, in increasing order of responsibilities (please refer: https://github.com/openebs/community/blob/develop/GOVERNANCE.md):

1. Adopters: use the product, may fork the source, contribute issues, ideas and fixes.
2. Contributors: help in fixing issues, code or otherwise. Active on Slack, GitHub and community meetings. Some of the contributors could be elevated by given write access, allowing them to add others as reviewers to their pull requests or review other's changes.
3. Special Maintainers: are contributors with expertise and authority in a specific domain but do not have responsibility or voting rights in the umbrella project.
4. Maintainer: primary elected group, responsible for the well-being and success of the whole project.

While the above does list the roles/responsibilities to a large extent, I see a scope for improvement on 2 aspects:

1. Overlapping roles: There is no clear distinction between an adopter and a contributor in their functional areas.
2. Overloaded responsibilities: Some contributors have write access, while others don't. This potentially opens up the need to have another stage.

My thoughts:

1. Limit adopter role to usage of the product and posting queries or Slack or GitHub. When an adopter starts raising GitHub issues/enhancement requests/pull requests, they have grown to be a contributor.
2. Have an additional stage called Reviewer (or Approver) between Contributor and Special maintainer. This group will have the write access to approve pull requests from others. This clearly elevates their status and differentiates them from a Contributor.

[avishnu]

Request the current maintainers to weigh in with their thoughts.

[tiagolobocastro]

I think it's a good idea to clarify this.

Also this allows us to formalize the reviewers a bit more as it's a bit of a grey area within the contributors bucket:

"Some of the contributors could be elevated by given write access, allowing them to add others as reviewers to their pull requests or review other's changes"

CODEOWNERS also useful here at a per-repo level

Here are some interesting reads regarding the ladder:

• https://glossary.cncf.io/contributor-ladder
• https://github.com/cncf/project-template/blob/main/CONTRIBUTOR_LADDER.md

[orville-wright]

I feel that the issue only really exists at the lowers levels of the ladder.

Down at that level, I do see the need to clarify the difference between an ADOIPTER and a CONTRIBUTOR.

IMHO...

• a CONTRIBUTOR is someone who gives something to the project. They are engaged with the project level. They may not always be a user of the product, but their focus is more at the project level and for the benefit of all users. Contributors submit BUGs and ISSUES for the benefit of all users and they may contribute to the resolution of the Bug/Issue. They may even fix it and document the fox or submit code.

• an ADOPTER is a user of the product who is generally using it for themselves or the company they represent. They're generally taking something from the project and not focused on the project or other users of the project/product Their interest is mostly just the product and their use of it. Adopters submit BUGs and ISSUES b/c doing this helps their personal cause. They will mostly want someone else to fix the bug/issue for them. (i.e. a Contributor, or someone higher up on the ladder).

If we want to accentuate the difference between ADOPTER and CONTRIUBUTOR, this is how I see it.
I'm not sure what benefit the project gets by splitting these 2 roles out in this way... maybe we & CNCF TOC are just looking for language clarification? If so... this is my language / wording.

• SPECIAL MAINTAINERS - we have this pretty well covered. We just need to make sure that it is always clear that they do not have Binding voting power. Only Maintainers hold that. And that we don't split voting down at the Sub-project level...

  • For example: If LocalPV-LVM was a sub-project then its special maintainers couldn't have a vote to leave the OpenEBS project. That vote would have to be proposed up to the Maintainers and only the Maintainers would vote with their Binding votes.

• MAINTAINERS are well defined - but I'd think we need to make sure that it is explicitly clear that Maintainers are accountable only to CNCF; who is the sole legal ownership governing entity of the OpenEBS project. I'm not sure we have this language in the definition of MAINTAINERS.

  • And that Maintainers are the only roles that hold and cast Binding Votes. - No other role has this project power.

re: @tiagolobocastro suggestion... CODEOWNERS also useful here at a per-repo level.

• I do like the role of Codeowner. Its clear what this means a the engineering GitHub, code level... but I an reticent about using the word OWNER in an opensource project role, because CNCF is the sole owner of all things related to the project. So Codeowner is kind of weird relative to CNCF's Superuser ownership status.. Technically, CNCF owns all the code.... I think ?

[tiagolobocastro]

You're reading too much into the literal word owner here, it's just who owns the review of the code.
In fact, if you see other proposals in many times they ask projects to setup code owners.
No they don't own the code. Ownership belongs to authors and contributors.

[Abhinandan-Purkait]

MOM from Maintainer's Meet

• Define the role of Sub Project maintainer.
• Identify the Sub Projects.
• Pathway from Contributor --> Approver(Codeowner) --> Sub Project Maintainer?
• Pathway to Special Maintainer?
• Maintainer needs to be at least an Approver or a Sub Project Maintainer
• Approver or a Sub Project Maintainer can apply for maintainership and the decision is left on the maintainers.
• Emeritus members to be specified. Does this require permission from them to be included? This applies from the point of sandbox application not prior to that?