Some projects- httpd notably- have extended a commit bit to contributors who only wrote documentation, trusting that they would use it responsibly. They said it worked well. It wasn't a ceiling on the committer's role, but they knew to ping people before pushing changes to some parts of the tree.
I haven't been on a project that generated enough documentation for that particular role, but testing/build engineers on Hadoop have been given a commit bit in the past. The result was more mixed there, but positive overall. Same process. -C On Thu, Sep 26, 2013 at 7:07 AM, Kevin Minder <[email protected]> wrote: > Hey Everyone, > > My recent change to move most of the release specific docs from wiki to svn > is likely to create a bottleneck for us. The one thing that I really liked > about using the wiki was that it had a very low barrier to entry for anyone > interested in working with docs. Specifically we have direct control over > the wiki permissions so it is very easy to grant privs. Now this being said > we have been fairly free (possible too free) in granting those privs. > Having these docs in svn will require commit privs in that repo for release > doc updates. > > So my question is do we want to distinguish between a code and doc > committer? If not, what should the process be for making someone a doc > committer? Does it have to be a formal as it is for code committers? > > Kevin. > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader of > this message is not the intended recipient, you are hereby notified that any > printing, copying, dissemination, distribution, disclosure or forwarding of > this communication is strictly prohibited. If you have received this > communication in error, please contact the sender immediately and delete it > from your system. Thank You.
