Becoming a committer


What do you think the requirement to becoming a committer are? is there an official process ? if there are none, what do you think of something along those lines?

The following process applies to the core projects (mangeiq, manageiq-classical-ui … <other repos?> ). other plugins/providers may follow a more informal process.

What is a committer

A ManageIQ committer is a person with commit access to one or more of the repositories under the ManageIQ organization. Committers are members of the ManageIQ contributors community who exhibit most of the following behaviors:

  • Review and merge code and documentation
  • Help triaging bugs and testing pull requests
  • Make well formed pull requests
  • Take care of releases
  • Have a sense of duty about the ManageIQ project
  • Play well with others, are respectful, show gratitude

We ask new contributors to ‘act as a committer’ to the extent we feel they are capable.

If you want to become a committer, we expect you help with some of these tasks:

  • Review and test the patches submitted by others; this helps to offload the burden on existing committers, who will definitely appreciate your efforts
  • Participate in discussions about releases, road maps, architecture, and long-term plans
  • Improve the website
  • Improve project infrastructure in order to increase the efficiency of committers and other contributors
  • Help raise the project’s quality bar (e.g. by setting up code coverage analysis)
  • As much as possible, keep your activity sustained rather than sporadic

Other things that are nice to do:

  • Support users and other developers on the various channels (ManageIQ Talk, github issues and in gitter channels).
  • Participate in (or even initiate) real-world events such as user/developer meetups, papers/talks at conferences, etc

How do I become a committer?

One person has to nominate you to the group of existing committers. The person who nominates you has to:

  • Submit 10 examples that prove this person behaves like a committer. For instance:
    • Strategic patches to the project that fix or add key functionality
    • talk threads where the person is clearly helpful
    • Comments that prove the person has triaged bugs
    • Proof the nominee has maintained a plugin/provider successfully
    • Anything else that shows the nominee should become a committer
  • Explain how the nominee is involved in the community and cares about the future of the project

This nomination is public and should be made to the ManageIQ developer Talk. After the nomination is submitted, two other committers have to second the nomination. If no one objects in one week, the nomination is accepted.

Such objections may happen in public on the nomination thread. Understandably, however, not everyone is comfortable giving objections publicly. Therefore, it is acceptable for other committers to raise their concerns with the sponsor and/or other committers privately if they wish to do so. The sponsor is expected to update the nomination thread to show that it is on hold pending private concerns.

Regardless, during any objections, private or public, the nomination is on hold until the objections are resolved or the nomination is rejected. In the event of a failed nomination, the sponsor (as part of the discussing group) will know the grounds for the rejection, and can pass along constructive feedback to the candidate. Care should be taken to do this sensitively.

How do I lose committer status?

If you are inactive in the community for one year, we will remove you from the committers list and revoke your permission, but we will make a mention of you in list of previous committers.

In the event that a committer continues to disregard good citizenship (or actively disrupts the project), we may need to revoke that person’s status. The process is the same as for nominating a new committer: someone suggests the revocation with a good reason, two people second the motion, and a vote may be called if consensus cannot be reached. We hope that’s simple enough, and that we never have to test it in practice.

Special thanks to Chromium, Mozilla, V8, FreeBSD, Apache Hive and Foreman project for providing the basis of this procedure.

@ohadlevy thanks for starting this, it’s much needed.

a few comments/questions:

  • I think the following should be more well scoped, it reads a bit vague to me and too open for interpretation:
    “Have a sense of duty about the ManageIQ project”

  • "Take care of releases"
    afaik the releases are not handled by committers today, perhaps that part also needs refinement (or change the current process)

  • “Participate in discussions about releases, road maps, architecture, and long-term plans” - where are those discussions taking place today?

discussions should happen in the open, either here, github or gitter. ideally a comon place such as

I agree about the should happen.
However if currently it is not happening, we can’t/shouldn’t rely on that for committer selection/on going expected behavior of a committer :slight_smile:

1 Like

I think the objections should also be public like it is done with projects at Eclipse Foundation.

Does this post renew my inactivity counter to 0 days? :wink:

I’ll like to point out this part:

Review and test the patches submitted by others; this helps to offload the burden on existing committers, who will definitely appreciate your efforts

I think that the committer status should be earned by contribution and by good review history.

We still struggle with review quality due to various reasons. The lack of people doing detailed review being one of the most prominent reasons.


Excellent point on good review history @martinpovolny. Perhaps, that should be a metric on the way to becoming a committer of a repo – n PR reviews with positive feedback from other committers within a certain timeframe.

IMHO - when someone is proposing a developer (or a developer proposing himself) - it should include why such a change make sense - that should include a list of PR’s - a few examples from the Foreman Project:

I have stumbled upon this slide deck on code review. It has some great points in it.

Such as that:

  • The review has it start, it’s end and a result.
  • Doing a review of a PR means acception certain responsibility.
  • Everyone should be participating in review. Junior or senior. I’d add that if for whatever reason a single person cannot do the full review, it’s important to tell what was done and what was not.
  • and much more, please, read below


How to successfully grow a code review culture from Nina Zakharenko

When evaluating whether an Engineer should be granted merge rights I would consider:

  • How long has this Engineer been making PRs on the repo? Is this person familiar enough with the code to anticipate a breaking PR or propose improvements to a PR?

  • What standard is his/her own code? How much constructive feedback does his/her PRs typically get?

  • How sound is this person’s judgement? Nit pick or valid quality control? Will he/she push back when necessary?

  • Turn around time - will this person let PRs go stale? Does this person understand the need to get PRs promptly reviewed and merged?

As much as I almost always favor openness, I’m not entirely sure a public rejection is a good idea. Some people will be fine with it but many will not. I prefer approval and denial to be communicated privately.

Fully agree - hence there are ways to communicate in private, but the nomination process IMHO should be done publicly, anyone who has concerns may choose to communicate in private if desired.