Le 29/09/15 15:33, Bertrand Delacretaz a écrit : > On Tue, Sep 29, 2015 at 3:23 PM, Cédric Champeau > <cedric.champ...@gmail.com> wrote: >> ....One exit criteria is "growing the community", and growing >> the community means finding new "committers", aka, people committed to the >> project. And The definition here of committer binds it to having write >> access to the repository, which has nothing to do with it IMHO.... > You are technically correct but giving those people commit access to > the repository, as part of making them committers, doesn't hurt. > > It's useful for 99% for them and for the others it's not a problem - > we trust them not to touch what they don't master (like any committer) > and worst case version control is our friend. > > So having two different roles for "coding committers" and "non-coding > committers" would complicate things while bringing no tangible > benefit. > > Basically, if you think someone is committed to Groovy and deserves to > be listed as such, make them committers, as there's no better role > here and the coding or non-coding distinction is not useful.
As a matter of fact, at Directory, we voted in someone who never contributed any code, but who spent a lot of his time educating people on how to use the software, and more important, advertized the project. We would call him an 'evangelist' at Sun /Oracle (except that evangelists have been recently eradicated from Oracle ;-) However, we had to grant him commit access to the code base, because it's part of the process. But there is more than just code in our coe base : - documentation - site - scripts and in this very case, he participated a lot of the site. So, yes, a committer is much more than just someone who write code, and yes, it's simpler to have one single commit flag for the project.
