Last week, I vetoed four committer elections for two Technology projects. Two weeks ago, I counselled another PMC about their approval of an election that I would also have vetoed.
I hate saying no to people.
Committers are elected to Eclipse projects after establishing merit with the project. The measure of merit to become a committer is one of those gray areas that keeps people like me up at night: the criteria for becoming an Eclipse project is more qualitative than quantitative and varies from situation to situation and project to project.
Regardless of the qualitative nature of acceptance, there are still minimal quantitative requirements. I tend to take an “at least one” view of this: a nomination must be able to identify at least one contribution from the prospective new committer. Ultimately, it’s the individual PMCs that decide how much is enough, but I’m pretty sure that it is universally accepted that a prospective new committer must have made at least one contribution in an open and transparent manner.
The “Nominating and Electing a new Committer” document describes what we need to see in a nomination:
A committer nomination should explain the candidate’s contributions to the project and thus why they should be elected as a Committer. Cite the bugs they have fixed via patches; cite the newsgroup postings they have answered; cite the dev list design discussions to which they have contributed; etc. In all cases, provide urls to source material: the bugs, posts, emails, wiki pages, etc.
The nomination should provide a pretty specific list of important things that the nominee has done for the project. That list should contain enough things to imply that the nominee understands the project, the code-base, and the Eclipse Development Process (and–very importantly–the intellectual property management processes).
We give the initial committers for a new project–as listed in the project proposal–a pass. The project proposal is required to include the nomination criteria, and so takes the place of the project’s initial committer election. We can’t reasonably expect that specific bugs be cited in this kind of nomination: we tend to accept nomination criteria that describes the nominee’s familiarity with the code base. The simple fact of the matter is that we have to start somewhere and–despite the fact that many new committers for entirely new projects aren’t familiar with the Eclipse Development Process–we put faith in the project leadership chain and project mentors that good things will develop. At the time of creation, I dump an unreasonable amount of data on the project leader’s virtual lap and say “read this”. In the future, I hope to create a New Project Bootcamp webinar that will make this easier.
It’s similar for committers that join the project along with a significant chunk of code. Few Eclipse projects will accept large chunks of new functionality without accompanying committers to support and evolve that code. In this case, new committers can be nominated as the code contribution is pushed into the IP process. It’s normally enough to cite the ID of the Eclipse Bugzilla record that contains the contribution in the nomination. This tends to work because large contributions tend to require considerable interaction before they are accepted into a project.
The nomination for developers who have established a record of providing high-quality contributions should cite specific Bugzilla/Gerrit records, activity in the project communication forums, etc. How much is enough, as I stated earlier, varies from situation to situation, project to project, and PMC to PMC. As a general rule, though, it’s not enough to state what the nominee will do; rather, you need to demonstrate that the nominee “gets it” and is going to be a valuable addition to the project and the Eclipse community in general.
All of this, frankly, can be huge pain in the arse for projects that just want to get a new committer on board. But, again, it’s more than just knowing the code base, being a subject matter expert, or getting hired to do a job. Committers are required to understand the Eclipse Development Process (especially the bits concerning intellectual property). And–since transparency is an important part of operating in open source–merit needs to be laid out for all to see.
