Twitter github

Streamlining Committer Elections in Open Source

There’s been some discussion as of late amongst the Eclipse Architecture Council about streamlining the committer election process.

I brought the issue up because I have mentored quite a few projects at Eclipse.org and have seen the good and bad parts of the process in play. We are also at a time where we are modifying the Eclipse Development Process so we have the opportunity to make some changes to the committer election process. I don’t like the process currently because I think it takes too long for a committer to get elected and eventually get commit rights to source control. From the 7 day election period to the paperwork, I think we can do a bit better. I like the process because it plays into the fact that Eclipse is a meritocracy and allows existing committers and community members to speak their mind. In reality, there are very few times where I have seen someone voted down when an election was called. In most cases, I’ll bet existing committers have talked amongst themselves already before calling an election so that veto vote is less likely to happen.

How do other mature open source projects deal with this? How do we make it better?

Anyways, if you have any comments or suggestions, please speak up on the bug. It would be nice to hear from people what they experienced when they were being on-boarded as an Eclipse committer or even other open source projects.

  • vogella

    I recently went through this process and I actually liked it. All the “+1″ on the mailing list were really nice to see. And I think one or two weeks for getting commit rights are not to bad. I believe having a small barrier actually helps.

  • vogella

    I recently went through this process and I actually liked it. All the “+1″ on the mailing list were really nice to see. And I think one or two weeks for getting commit rights are not to bad. I believe having a small barrier actually helps.