Hi all, I proposed ages ago to have a public process for people to gain Subversion access - after a long wait, I'd like to propose the following for feedback, based on the Subversion criteria. The next step is to define modules & module maintainers, and to publish the initial list of committers to the project. I'll add this to the wiki.
All comments are welcome. Cheers, Dave. Openwengo commit access There are two types of commit access: full and partial. Full means anywhere in the tree, partial means only in that committer's specific area(s) of expertise. The COMMITTERS file lists all committers, both full and partial, and says the domains for each partial committer. How full commit access is granted After someone has successfully contributed a few non-trivial patches, some full committer, usually whoever has reviewed and applied the most patches from that contributor, proposes them for commit access. This proposal is sent only to the other full committers -- the ensuing discussion is private, so that everyone can feel comfortable speaking their minds. Assuming there are no objections, the contributor is granted commit access. The decision is made by consensus; there are no formal rules governing the procedure, though generally if someone strongly objects the access is not offered, or is offered on a provisional basis. The primary criterion for full commit access is good judgment. You do not have to be a technical wizard, or demonstrate deep knowledge of the entire codebase, to become a full committer. You just need to know what you don't know. If your patches adhere to the programming guidelines of the project, adhere to all the usual unquantifiable rules of coding (code should be readable, robust, maintainable, etc.), and respect the Hippocratic Principle of "first, do no harm", then you will probably get commit access pretty quickly. The size, complexity, and quantity of your patches do not matter as much as the degree of care you show in avoiding bugs and minimizing unnecessary impact on the rest of the code. Many full committers are people who have not made major code contributions, but rather lots of small, clean fixes, each of which was an unambiguous improvement to the code. (Of course, this does not mean the project needs a bunch of very trivial patches whose only purpose is to gain commit access; knowing what's worth a patch post and what's not is part of showing good judgement :-) .) How partial commit access is granted A full committer sponsors the partial committer. Usually this means the full committer has applied several patches to the same area from the proposed partial committer, and realizes things would be easier if the person were just committing directly. Approval is not required from the full committers; it is assumed that sponsors know what they're doing and will watch the partial committer's first few commits to make sure everything's going smoothly. Patches submitted by a partial committer may be committed by that committer even if they are outside that person's domain. This requires approval (often expressed as a +1 vote) from at least one full committer. In such a case, the approval should be noted in the log message, like so: Approved by: lundblad The "obvious fix" rule Any committer, whether full or partial, may commit fixes for obvious typos, grammar mistakes, and formatting problems wherever they may be — in the web pages, API documentation, code comments, commit messages, etc. We rely on the committer's judgement to determine what is "obvious"; if you're not sure, just ask. -- Dave Neary OpenWengo Community Development Manager Email: [EMAIL PROTECTED] Tel: +33 9 51 13 46 45 Mob: +33 6 28 09 73 11 _______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel
