Thank you for all these details and links.

On 2025/02/21 02:41:05 Paul King wrote:
> Hi folks,
> 
> With my mentor hat on, just a reminder of one of the ASF's basic
> principles, meritocracy[1]. Some of you will know this principle well
> or will have heard me talk about it. This email is just to close the
> loop on some potential loose ends with how the concept works during
> incubation and make sure everyone has the same expectations.
> 
> Apologies if some of this is too basic, but there could easily be
> folks with different backgrounds, so I'm trying not to make too many
> assumptions. For folks familiar with how the ASF works, the *last para
> (or three)* is where the incubation side of things is discussed.
> 
> First, how meritocracy normally works. Each ASF project has a tiered
> set of permissions, rights and responsibilities. The more
> contributions someone makes, the higher they move up those tiers.
> 
> Anyone can contribute to your project by e.g. creating PRs. Folks who
> contribute a lot can become committers which gives them direct repo
> access rights. Committers who continue to contribute can become PMC
> (project management committee) members. PMC members have the right to
> vote on releases, vote on new committers and PMC members, and have
> extra permissions, e.g. to be able to formally carry out a release on
> behalf of the project (and on behalf of the ASF).
> 
> Voting folks into those roles is a way to recognise and reward their
> hard work and hopefully encourages them to do more. There is no limit
> to the number of folks you can have as committers or PMC members, so
> you shouldn't treat membership as a scarce resource. You should always
> be looking for potential new candidates for those roles, to grow your
> community, bring in new blood and fresh ideas, and for succession
> planning.
> 
> It is often easy to identify potential new committers/PMC members for
> code contributions, but also be on the lookout for other kinds of
> contributions, e.g. answering questions in mailing
> lists/slack/stackoverflow, giving conference talks, writing
> documentation or blog posts, and so forth. A successful project will
> have folks who do all those things.
> 
> Some projects have some predefined guidelines for moving up the tiers,
> e.g. you need to do X accepted pull requests, or similar rules. Most
> projects just do it from discussions within the team. Some advice that
> is often given is don't make your committer bar too high. Obviously,
> you don't want folks with direct repo permissions committing code full
> of bugs without review. But if you make the "X" too high, potential
> committer candidates might lose interest and leave the project and the
> opportunity will be lost. It is normally all about setting
> expectations.
> 
> The ASF also has the concept of "merit never expires". This means that
> once you become a committer/PMC member, you can stay there (if you
> want). There is a process for becoming emeritus or even turning off
> repo write bits (as a security measure) for folks that become
> inactive.
> 
> Votes for releases are normally done on the dev list and PMC member
> votes are binding needing at least three +1 votes. So you should aim
> to have at least 3 active folks on the PMC, ideally several (or many)
> more. There is an expectation that folks on the PMC will join the
> "private" mailing list. This is where votes for new committers/PMC
> members are done and where security (CVEs and the like) are typically
> sent. The "PMC members must be on the private mailing list" rule is
> not strictly enforced during incubation.
> 
> Now, tying this back to incubation. During incubation, Grails is
> termed a "podling" and the PMC is a podling PMC, a PPMC. Anyone listed
> in the original proposal[2] can sign an ICLA[3] and join as a
> committer. You could distinguish between committers and PPMC members
> at this point but I suggest you just put everyone on the PPMC. Upon
> successful graduation, a resolution will go to the board and it will
> list out committers and PMC members.
> 
> **You can have a discussion at that point about who has done the heavy
> lifting during incubation (or deserves historical merit) and should be
> on the PMC.**
> 
> For folks not listed in the original proposal, you should have
> discussions and votes on the private list. There are guides for how to
> do this[4,5] including email templates to use[6] and some of the
> incubator advice[7] is also helpful. Søren and myself can help with
> onboarding for now for successful candidates.
> 
> There is a huge amount of info about "The Apache Way" and "incubation"
> on the ASF site (not all of it as up-to-date as it could be), so
> please shout if you have questions. It is not critical to absorb all
> the information right now.
> 
> Cheers, Paul.
> [1] https://www.apache.org/foundation/how-it-works/#meritocracy
> [2] https://groovy.apache.org/wiki/grails-proposal.html
> [3] https://www.apache.org/licenses/contributor-agreements.html
> [4] https://www.apache.org/dev/pmc.html
> [5] https://www.apache.org/foundation/governance/pmcs
> [6] https://community.apache.org/pmc/adding-committers.html#email-templates
> [7] https://incubator.apache.org/cookbook/
> 

Reply via email to