Peter said:
My answer to this problem is to be inclusive, to trust people and grant
commit rights liberally. For example, I have recently granted Frank
Nikolajsen and Jamie Rasmussen commit rights.
I'd say that there needs to be a policy on how you get commit privs. Most people who contribute patches don't want/need commit privs. Most people who ask for commit privs don't do anything with them. I'd say maintainers should nominate users for commit privs. The scenario would work something like this:
1. A user goes and fixes something. He either submits a bug report, posts it on a mailng list or contacts the author of the package directly. Either way, the maintainer gets the fix.
2. The maintainer (who obviously has commit privs) commits the fix and acknowledges the user who submitted it.
3. The maintainer realizes this is the Nth fix this user has submitted and starts to get annoyed by having to review and commit all his changes.
4. The maintainer requests commit privs for the new user (after asking the user if he wants them).
5. The new user is given commit privs on the package or packages on which he's worked.
6. A "Commiter's Guide" (of which you seem to have the first draft of) is automatically mailed to the new commiter.
I'd say the maintainer who asked for commit privs for a user should act as a "mentor" for the new commiter. That way, you get a personal relationship between two developers.
I don't think liberally giving commit privs is a good idea. It can cause a lot of overhead if people liberally commit stuff they think is right but has not been properly reviewed or approved by the community at large.
Comments?
Regards,
-Oscar
