Example of community manager job role Was: Re: FBReader now working on the FreeRunner

Steve Mosher steve at openmoko.com
Mon Oct 13 19:36:56 CEST 2008

Agreed raster. I'm headed to Taiwan this week to discuss this and other 
matters, So any ideas that Rod, you or other come up with need to
get to me pretty soon.

Carsten Haitzler (The Rasterman) wrote:
> On Mon, 13 Oct 2008 21:30:22 +1030 Rod Whitby <rod at whitby.id.au> babbled:
>> Stroller wrote:
>>> On 12 Oct 2008, at 20:55, Rod Whitby wrote:
>>>> If Openmoko had a community manager, that person would contact  
>>>> Michael directly and:
>>>> 1) Invite Michael to get commit privs and commit this patch himself  
>>>> directly to the OM repo.  This may include teaching about how it all  
>>>> works.
>>> Is it possible to give Michael commit privs for only this package,  
>>> though? One surely wouldn't want to give them to a community member on  
>>> the basis of a single GUI app and later find he has b0rked the whole  
>>> kernel tree.
>> In four years of running a project with a very low commit barrier, I've
>> never had a single problem.  And configuration management systems are
>> designed to be able to remove an errant version, so even in the remote
>> case that it does happen it's trivial to detect (since lots of people
>> watch each and every commit) and fix.
>> If you give people guidance on what they should and should not modify,
>> then you will find that they follow those guidelines.
> agreed. in a decade of doing enlightenment - and about a decade of shared
> revision control systems (CVS and recently SVN) i have taken a liberal approach
> to allowing write access and have yet to be disappointed by it. lower the
> barriers and trust people to do the right thing after a quick "dont break stuff
> or we will hunt you down and cut out your eyes and feed them to our turtles"
> talking. it lets you spread the work and let other people pick up pieces when
> you don't have time. anyone who reads the cvs/svn commits lists (and ALL
> developers with commit access should), you spot activity on a project and you
> see the diff - if something strikes you as "that's wrong" its a single
> commandline away to revert it. normally you first have a chat to the committer
> to see "whats up".
> i agree with rod. a long period of experience has shown to me that being liberal
> is good here. don't hand out write access to anyone - but those who have sent a
> few patches and seem to have a clue - get it without further barriers. they are
> now in the fold of "core developers" who have direct access. all activity is
> monitored and logged and is revertable. not to mention the psychological
> "inclusiveness" that this shows to people.

More information about the community mailing list