Example of community manager job role Was: Re: FBReader now working on the FreeRunner
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. I know that my own favourite distro (Gentoo) has some kind of formal scheme to test the qualities of potential developers and introduce them to full developership. Such a set of formalities may bring its own disadvantages, however. Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Example of community manager job role Was: Re: FBReader now working on the FreeRunner
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. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Example of community manager job role Was: Re: FBReader now working on the FreeRunner
On Mon, 13 Oct 2008 21:30:22 +1030 Rod Whitby [EMAIL PROTECTED] 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. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Example of community manager job role Was: Re: FBReader now working on the FreeRunner
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 [EMAIL PROTECTED] 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. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
