On Tue, Sep 29, 2015 at 03:33PM, Bertrand Delacretaz wrote: > On Tue, Sep 29, 2015 at 3:23 PM, Cédric Champeau > <[email protected]> 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.
What Bertrand said. This topic has been discussed at length multiple times on a couple of lists. [email protected] and, IIRC, [email protected] are coming to mind. And the consensus was as above: the extra procedural bureaucracy doesn't solve anything. Quick search will help you to find the threads, in case you care to look them up. Thanks, Cos
