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/
