The Criteria.

In the Jitsi project, we choose committers primarily on the Hippocratic Principle: first, do no harm. Our main criterion is not technical skill or even knowledge of the code, but merely that the committer show good judgement. Judgement can mean simply knowing what not to take on. A person might post only small patches, fixing fairly simple problems in the code; but if the patches apply cleanly, do not contain bugs, and are mostly in accord with the project’s log message and coding conventions, and there are enough patches to show a clear pattern, then an existing committer will usually propose that person for commit access. True, we might have no evidence that the person is able to solve complex problems in all areas of the code base, but that does not matter: the person has made it clear that they are capable of at least judging their own abilities. Technical skills can be learned (and taught), but judgment, for the most part, cannot. Therefore, it is the one thing we want to make sure a person has before we give them commit access.

The Procedure

After someone has successfully contributed a few non-trivial patches, some other committer, usually whoever has reviewed and applied the most patches from that contributor, proposes them for commit access. This proposal is first sent only to the other committers thus making sure that everyone can feel comfortable speaking their minds before the procedure goes public. If no strong objections have been made the proposition is being made on the [email protected] mailing list for a vote. In order for someone to be granted commit access they must earn at least five positive votes and one of these votes must belong to the project lead (Emil). Once these votes have been gathered the contributor is given membership to the developers team in the Jitsi organization on GitHub.

Note that all contributors are expected to sign our contributor agreement as either an individual or a corporation.

This document has been strongly influenced by Hacker’s Guide to Subversion and Karl Fogel’s book on “How to Run a Successful Free Software Project”