groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <>
Subject Re: [DISCUSSION] What about moving out teh Incubator ?
Date Wed, 30 Sep 2015 10:16:00 GMT
On Wed, Sep 30, 2015 at 09:20AM, Emmanuel Lécharny wrote:
> Le 29/09/15 15:33, Bertrand Delacretaz a écrit :
> > On Tue, Sep 29, 2015 at 3:23 PM, Cédric Champeau
> > <> 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.

Earlier this year we did the same think in Bigtop: we have this guy who does
tremendous job setting up workshops, meetups, working with conference
organizers to put together Bigtop tracks, etc. And this worked amazingly well
for us!


View raw message