Skip to end of metadata
Go to start of metadata

APPROVED by voice vote at the TSC meeting on 14 May 2018.

Acumos Technical Community Document Section 4.1.2

4.1.2 Committer

As specified in the Technical Charter, Committers are Contributors who have earned the ability to merge contributions (“commit”) source code, documentation or other technical artifacts in a project’s repository. A Contributor may become a Committer by a majority approval of the existing Committers. A Committer may be removed by a majority approval of the other Active Committers. Unless otherwise defined in TSC policies published on the Acumos Web Site, “Active Committers” are Committers who have merged contributions in at least two separate instances over the last six months.

Since there may be multiple repositories per project, Committer rights are per repository. Being a Committer on one repository in a project does not necessarily or automatically grant that individual Committer rights on all the repositories in the same project. Likewise, having Committer rights in a project does not automatically grant that individual Committer rights in other projects.

Committers are the decision makers for a project – design, code, patches, and releases. Typical characteristics of a Committer include but are not limited to:

  • Deep expertise in the code base over which they are Committers

  • Time dedicated to reviewing code contributions made by other Contributors

  • Demonstration of good judgment and mentoring of others in the gerrit process

  • Knowledge and understanding of the overall development activities occurring within the project and its components; this is important so that the review of new code is taken in the context of the overall development for the project

  • Knowledge and understanding of other, interdependent projects within the platform and how contributions to this project affect work being done elsewhere by others

The Committers on a project review each code contribution made by the Contributors and other Committers on the project. Often, a Committer will need to enter into a dialog with a Contributor to have them make changes to the contribution to better fit the functional, structural makeup, or style of the existing code base. It is preferable to have at least 2 Committers show approval (with a +1) for a contribution before it is accepted into the repository. Please note that it is very common for individuals to be a Committer on one project and a Contributor on another. However, there is nothing stopping an individual from being a Committer on multiple projects and repositories.

Committers are the best available individuals and usually work full-time on projects and components in active development.

In order to preserve meritocracy in selection of Committers while ensuring diversity of Committers, each initial project is encouraged to taking on at least two Committers from different companies (subject to meritocracy). Committer Promotion Process

While the initial committers on a project are nominated at project formation, it is expected that community members will emerge as willing committers over time. to Nomination

Project Contributors who are interested in promotion to project Committer should first approach the PTL and Committer community to discuss their interest and receive feedback on their work within the community.

To be promoted to Committer the TSC will be looking for the nominated Contributor:

  • To have a history of active contributions in the project

  • To have demonstrated to the PTL and existing Committers a deep knowledge of the code and project best practices

  • To have shown a willingness to lead and coordinate amongst peers

Once the project lead and committers feel the candidate has demonstrated these items, the project lead or delegate should formally nominate the candidate and start a vote. Note that, at the end of the day, the vote of the Committers is what matters, so who does the actual nomination is less important. Nomination for Committer Promotion

The nomination for Committer promotion begins with the PTL or delegate sending an e-mail to the acumosaidevdiscuss list requesting the Committers on the project vote on the nomination.

The nomination e-mail should begin with a clear topic name and be followed by a statement of motivation. The statement of motivation should describe any achievements or activities the Contributor has performed of notable value for the project and may include a link to a git-log of the nominee's activity history. More than one Contributor may be nominated in one nomination e-mail.

The e-mail may take the following form:

From: <project lead>


Subject: [project tag] Nomination for new Committer(s): <contributors name(s)>

Body: The motivation for nominating <contributors name> to Committer on the <project> project is due to a long history of providing value to the project through consistent high quality and valuable contributions. <refer to relevant contributions and the value they provided to the project> I provide a link to the relevant contributions. <link>
Please vote +1|0|-1 on whether you would like to see them as a Committer.

Once the e-mail has been sent the nomination stands until a clear majority vote for or against the nomination has been met, or the nominator withdraws the nomination. Voting shall take place according to the Condorcet or single transferable vote methods outlined previously.

While only project committers may vote, feedback from any and all community members is welcome during the nomination process and should be considered by both the project committers as well as the TSC.

If a majority of committers do not vote +1 after a reasonable effort has been made to contact them and a reasonable amount of time has passed, having all the cast votes be +1s has been interpreted as consensus and thus a majority vote is not required. After Voting

At the completion of a nomination process, if the nominee was successful, the PTL should inform the TSC via the TSC mailing list by forwarding the nomination e-mail along with a summary of the outcome of the Committer votes.

The PTL should additionally update the "Key Project Facts" section of the project wiki page as well as the INFO file in the project and/or component repository and inform the Linux Foundation facilities team of the individuals change in status. This should be done by sending an update e-mail to with the new committers e-mail and LinuxFoundation ID. This e-mail should either contain a link to the meeting minutes or relevant specific email archive recording the vote. Committer Removal

There are certain situations in which committers need to be removed from a project and/or repository. A Committer who is disruptive, or has been inactive for an extended period (e.g., six or more months), may have his or her Committer status revoked by the PTL.

  • Committers may choose to stand down / retire from a project when they no longer have the time or ability to engage effectively in the project.

  • It may also be that at times committers simply drift away from a project without communicating their intent to stand down.

  • In hopefully rare cases, it might happen that a Committer is perceived to be disruptive to the project and the peaceful work in the project is compromised or even damaged Committer Retirement

In general, it is preferable that committers themselves stand down / retire from a project when they determine they no longer intend to perform the role as expected of them. They may still remain active and contribute to the project although not in the capacity of a Committer. This is done in the form of an e-mail to the project stating their intention to stand down from the role of Committer. In this situation the PTL will then update the INFO file in the repository and forward the e-mail to the TSC ( and the helpdesk ( for administrative handling. It is important this e-mail contain the original e-mail from the Committer indicating his/her desire to stand down from the position. Removal of Inactive Committers

At times it may be that a Committer is not able to continue his work for a project and the project leader is not able to get in contact with the Committer any more, e.g. to get his consent to retire from the Committer role. In this case the PTL may notify the TSC that the inactive Committer is being removed from the project. The PTL then must demonstrate:

  • Sufficient evidence that the PTL has attempted to contact the Committer in question. Typically, this can be done by declaring that the Committer in question:

    • was not present in the project meetings for more than 6 months (see participant lists in the minutes or IRC); AND

    • did not contribute any patch for the project for more than 6 months; AND

    • did not participate in the email discussion of the project for more than 6 months

  • An approval by the project's committers to remove the Committer in question from the project, i.e. no objections within a week.

The PTL must notify the TSC mailing list ( on the inactive Committer removal. The PTL will then update the INFO file (or file a ticket to for administrative handling). Please note the section on "Contesting a Committer removal" below. Removal of Disruptive Committers

In the instance a Committer is perceived to be disruptive, the PTL may agree with other committers to remove the disruptive Committer from the project. In this instance the PTL must demonstrate:

  • Sufficient evidence that the Committer in question has in fact been disruptive.

    • Note that fighting of a position, solution or opinion cannot be considered disruptive

    • Only damage to the project's results or severe compromising behavior over a considerable period should be considered disruptive

  • Sufficient evidence that mediation has occurred on the issues highlighted including parties outside of the project's Committer pool, and no other consensus could be found.

  • A majority vote of current committers to remove the Committer in question from the project.

The PTL must notify the TSC mailing list ( on the Committer removal. The PTL will then update the INFO file (or file a ticket to for administrative handling). Please note the section on "Contesting a Committer removal" below.

Former committers removed for reasons other than being disruptive may be listed as Emeritus Committers on the project’s wiki page. That title expresses gratitude for their service but conveys none of the privileges of being a Committer. Contesting a Committer Removal

The TSC is responsible for overseeing the processes for maintaining the Committer lists. In the case that any member of the Acumos community would like to raise discussion or has concerns over a Committer removal, or the Committer removal process, he/she should reach out to the TSC via the TSC mailing list, or if preferred the TSC Chair Person directly to identify if further action or intervention by the TSC is needed. Adding Committers to Declining Projects

If a project has no active committers (e.g., due to resignations, etc.), the TSC may appoint an interim Committer from a project’s active Contributors. This term shall last until the next release date, after which time the Committer must stand for election from amongst other Committers on the project to maintain his or her status. In this special case, approval requires a majority of Committers who respond within two weeks. If no one responds by the deadline, then the Committer status is approved. This provision allows a project to continue development following an unexpected change in personnel.

The method by which the TSC appoints an interim Committer is first by request to the Acumos-TSC email list indicating the request to appoint an interim Committer for a project. After the reception of such an email, the normal TSC decision process applies.

  • No labels