In the world of open source, Committers are ones who hold they keys. Committers decide what code goes into the code base, they decide how a project builds, and they ultimately decide what gets delivered to the adopter community. With awesome power, comes awesome responsibility, and so it’s no mistake that the Open Source Rules of Engagement described by the Eclipse Development Process, puts Meritocracy on equal footing with Transparency and Openness: becoming a committer isn’t necessarily hard, but it does require a demonstration of commitment (committer… commitment… see what I did there?)
There’s two ways to become an Eclipse Committer. The first way is to be listed as an initial committer on a new project proposal. When projects come to the Eclipse Foundation we need them to actually start with committers, and so we include this as part of the bootstrapping. As part of the process of community vetting a new project proposal, the committers listed are themselves vetted by the community. That’s why we include space for a merit statement for every committer listed on a proposal (in many cases, the merit statement is an implied “these are the people who worked on the code that is being contributed”). In effect, the project proposal process also acts as a committer election that’s open to the entire community.
The second way to become a committer is to get voted in via Committer Election. This starts with a nomination by an existing committer that includes a statement of merit that usually takes the form of a list various contributions that the individual has made to the project. What constitutes a sufficient demonstration of merit varies by project team and PMC. Generally, though, after an individual has made a small number of high quality contributions that demonstrate that they understand how the project works, it’s pretty natural for them to be invited to join the team.
There’s actually a third way. In cases where a project is dysfunctional, the project leadership has an option to add and remove committers and project leads. In the rare cases where this option is exercised, it is first discussed in the corresponding Project Management Committee‘s (PMC) mailing list.
Last week, we rolled out some new infrastructure to support Committer Elections.
Every project page in the Project Management Infrastructure (PMI) includes a block of Committer Tools on the right side of the page. From this block, project committers can perform various actions, including the new Nominate a Committer action.
Committer Tools
Clicking this will bring up the nomination form where the existing committer will provide the name and email address of the nominee along with the statement of merit.
What the committer sees when they nominate a new committer.
When you click the Nominate button, the Committer Election begins by sending a note to the project mailing list inviting existing project committers to vote. Committers visit the election page to cast their vote and—since this is a transparent process—everybody else can watch the election unfold.
According to our election rules, an election ends when either everybody votes in the affirmative or seven days has passed. If at the end of the election we have at least three affirmative votes and no negative votes, the vote is considered successful and it passed on to the PMC for approval (note that when a project has fewer than three committers, success is declared if everybody votes in the affirmative). The PMC will validate that the merit statement is sufficient and that the election was executed correctly, and either approve or veto it. PMC-approved elections get passed into the next piece of the workflow: Committer Paperwork.
Regardless of how a developer becomes a committer (by vote, by proposal, or by appointment), they are required to complete legal paperwork before we can grant them write access to project resources. The Eclipse Foundation needs to ensure that all committers with write access to the code, websites, and issue tracking systems understand their role in the intellectual property process; and that we have accurate records of the people who are acting as change agents on the projects. Committers must provide documentation asserting that they have read, understood, and will follow the committer guidelines; and must gain their employers consent to their participation in Eclipse Foundation open source projects.
Our Commmitter Paperwork process is initiated whenever a developer joins us as a new committer, or—since paperwork is tied to a specific employer—when a committer changes employers.
The exact nature of the type of paperwork required varies based on the individual’s employment status and the Eclipse Foundation membership status of their employer. Again, a full discussion of this is out-of-scope for this post, but we need to have either an Individual Committer Agreement or a Member Committer Agreement on file for every committer. The workflow guides the new committer through the options.
Note that we’ve just gotten approval on an update to the Individual Committer Agreement that eliminates the need for the companion Eclipse Foundation Committer Employer Consent Form. This should make it easier for new committers to get started. We’re rolling the new version out now.
We owe this great new implementation of this workflow to the tireless efforts of the entire Eclipse IT Team, and especially Eric, Chris, and Matt. Big Thanks!
