Decide rules for a contributor to become a committer
According to https://blog.waynebeaton.ca/posts/opensource/repository/:
[...] here must be a path to turn contributors into committers. That path must only be as challenging as necessary, and must be based entirely on an individual’s ability to implement the Eclipse Foundation Development Process, implement the Eclipse Foundation Intellectual Property Policy, and–of course–work in collaboration with the rest of the development team while contributing high quality content to the project. Nominations for a committer election must include a merit statement that includes references (links) to specific contributions that demonstrate that the individual meets the criteria. To be clear, committer status must never be based on employment status.
According to https://blog.waynebeaton.ca/posts/opensource/hired-a-committer/:
To be considered for committer status a candidate must demonstrate merit. Generally, this takes the form of making high-quality contributions to a project in the form of patches or new code, but can manifest in other ways. It may make sense, for example, to nominate a committer based on a history of helping users and adopters.
The demonstration of merit must be something that everybody can see. That is, the demonstration of merit must be transparent to the general public. Again, code contributions are an obvious example of this as the commit record is open for all. This is one of the reasons that commits must be correctly attributed (i.e., the Author field in a Git commit must include the author’s name and credentials); another reason being that implementing an effective intellectual property regime requires it. With the tools available today, it’s pretty easy to point to a pattern of contribution.
The entire process must be open. That is in the sense that it is open to all comers; as I like to say (in one form or another), that the playing field must be level. That means that the means by which an Eclipse project team decides to make somebody a committer must not be biased by who that individual works for, or any criteria other than the the quality of the contributions they’ve made to the project and their demonstration that they understand their role and responsibilities as a committer.
[Conclusion] To earn committer status, a candidate must demonstrate that they understand their responsibilities under the Eclipse Foundation Development Process as well as the project code.
According to https://www.eclipse.org/projects/handbook/#elections-committer:
[...] Becoming a committer is a privilege that is earned by contributing and showing discipline and good judgment. It is a responsibility that should be neither given nor taken lightly, nor is it a right based on employment by an Eclipse Foundation member company or any company employing existing committers.
Being a Eclipse committer is more than just having write-access to the project resources: there are specific IP due diligence and record keeping activities that committers must follow. New committers must ensure that they are familiar with the Committer Due Diligence Guidelines.
What are the Requirements?
There are only three requirements around nominating and electing new committers (note that there are additional committer paperwork requirements for the new committer):
- Define trust;
- Maintain vendor/employer neutrality; and
- Operate transparently (public and archived election).
Each project is entitled to define how it evaluates "[people] who have the trust of the Project’s Committers ... [through] contributing and showing discipline and good judgment". This definition needs to be a transparent and public document on the project’s website (the top-level project charter may provide this). It is extremely important to publish these criteria to avoid any issues around cliques or "the in-crowd" preventing others from joining a project.
There must not be any hint of "we (company W) hired person X to work on project Y thus person X should elected a committer". Committer status is independent of employment; thereare well-supported mechanisms for contributors without commit-rights and thus committer status is not required for a team member to be effective. Additionally, the team will want to make sure that they have confidence in the candidate irrespective of employment and management because the committer status will continue even after moves to another job.
The nomination and election process for a new committer is for more than just the project team - it is also for the entire Eclipse community, current and future. The larger community uses the artifacts of elections as (one of many pieces of) evidence about the maturity of the project team, and thus quality of the frameworks.
Note: Nominations such as "we all know Bob, vote for him" may work within the team, but actually harm the project’s reputation in the larger Eclipse community: that larger community does not know Bob and does not understand why the project team trusts him with the source code.
An election starts with a nomination by an existing committer.
Only project committers may nominate a new committer or vote in a committer election. To be successful, the election must receive a minimum of three positive +1 votes. Any committer can veto the election by casting a -1 vote, or indicate their participation in the process but with no opinion with a +0 vote. For projects with three or fewer committers all committers must vote. Committer elections run for one week, but will end prematurely if all project committers vote +1.
This got me thinking what are our rules for a contributor to become a committer. I think we should define what we think is necessary for a contributor to prove being ready to become a committer. We should decide on this, and make it part of our documentation on contributing.