Re: What should a community manager do?
Rod, > BTW, I can show you guys how to set up Trac so that you can issue all > the developers an SSL client certificate (which you can use in a lot > of > places instead of username and password) and it automatically logs > them > into trac using their email address so they automatically get emails > when the tickets change state ... Nice, thanks! I'm not sure roh or gismo are reading this, if not you may have to file a ticket in admin-trac :-) Wolfgang On Oct 12, 2008, at 8:03 PM, Rod Whitby wrote: > Wolfgang Spraul wrote: >> Rod, >> >>> It seems that access was granted sometime between then and now >> >> oh great, I'm happy to hear that. >> Maybe we don't talk about it enough publicly: We have an 'admin trac' >> issue tracker, that _EVERYBODY_ can use to send requests to the >> Openmoko admins. >> This is a public resource, same as pretty much everything else in the >> Openmoko project: >> >> http://admin-trac.openmoko.org/trac > > Ah, now I see what happened. I did raise a ticket in the admin-trac, > and since we use Trac a lot at my work and in the nslu2-linux > project, I > expected it to send me email on ticket state changes. It didn't, so I > assumed nothing had happened (my incorrect assumption). > > BTW, I can show you guys how to set up Trac so that you can issue all > the developers an SSL client certificate (which you can use in a lot > of > places instead of username and password) and it automatically logs > them > into trac using their email address so they automatically get emails > when the tickets change state ... > > -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Wolfgang Spraul wrote: > Rod, > >> It seems that access was granted sometime between then and now > > oh great, I'm happy to hear that. > Maybe we don't talk about it enough publicly: We have an 'admin trac' > issue tracker, that _EVERYBODY_ can use to send requests to the > Openmoko admins. > This is a public resource, same as pretty much everything else in the > Openmoko project: > > http://admin-trac.openmoko.org/trac Ah, now I see what happened. I did raise a ticket in the admin-trac, and since we use Trac a lot at my work and in the nslu2-linux project, I expected it to send me email on ticket state changes. It didn't, so I assumed nothing had happened (my incorrect assumption). BTW, I can show you guys how to set up Trac so that you can issue all the developers an SSL client certificate (which you can use in a lot of places instead of username and password) and it automatically logs them into trac using their email address so they automatically get emails when the tickets change state ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Rod, > It seems that access was granted sometime between then and now oh great, I'm happy to hear that. Maybe we don't talk about it enough publicly: We have an 'admin trac' issue tracker, that _EVERYBODY_ can use to send requests to the Openmoko admins. This is a public resource, same as pretty much everything else in the Openmoko project: http://admin-trac.openmoko.org/trac If you want read/write access to git.openmoko.org, or if you want to sign our NDA to get access to some NDA'd documents, please register an account there, then write up a request. Best Regards, Wolfgang On Oct 12, 2008, at 4:42 AM, Rod Whitby wrote: > Rod Whitby wrote: >> (Wolfgang told the Openmoko admins >> to give me svn and git access on the 22 Sept, and nothing has >> happened yet). > > I want to make a public retraction and apology on this point. It > seems > that access was granted sometime between then and now, but either I > wasn't informed of that or the notification got lost in transit. > > My apologies to Wolfgang and the Openmoko admins. > > -- Rod > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
digger vermont wrote: > > I didn't read it like that. As someone who is learning by doing it felt > more like an invitation. It was late when I posted that, so maybe it was the lack of sleep talking. But even still, I guess my point is that I don't think that to groups need to be isolated, separated but not mutually exclusive . I also agree with the separation of devel and community lists. Its like > rooms in a house. Different things happen in different rooms. However > that doesn't mean you can't go into different rooms. I entered OM > through the living-room. Heard lots of lively conversations. Joined in > some. Then I started to smell the cooking that made me hungry and went > into the kitchen to watch what was going on. Being hungry I started > looking for places to help. Help with the prep? Some appetizers? I'm > slowly learning to cook myself. If you're like me when I'm in the > kitchen cooking a big meal my focus is on the task at hand. Some banter > is around the food is fine, but conversations about church and state no. > Save that for the living-room. You know what, so do I... there is a need for organizing the community at this point and a separation of devel and users will accomplish a lot in my personal view. As I said earlier, the one thing that I would not like to see is an isolation of the two groups (if it can be helped anyway). The low bar to entry would help ensure that users making the jump into the development of Moko items will not have much to imped them. There may be other thing that users would need to make that jump when they feel that they are ready to do so. For now, even with what is purposed here... I am not sure that it would end there to help (yeah even Mom) users jump into Moko development. The only other thing that I can do at this point is keep an eye... see that things don't go south. -- View this message in context: http://n2.nabble.com/What-should-a-community-manager-do--tp1318997p1321791.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
On Sun, 12 Oct 2008 13:18:31 +1030, Rod Whitby <[EMAIL PROTECTED]> wrote: > Joel Newkirk wrote: >> WRT your final point, we already have the 'Support' mailinglist - my >> impression is that the intent of that list (not necessarily the actual >> usage though) is as a place for the 'user' to go when seeking answers > and >> fixes, rather than seeking to involve themselves in the actual quest for >> those answers and fixes. > > Indeed, the trouble is there is a third list "community" which muddies > the waters between "devel" and "support", and the five word descriptions > on lists.openmoko.org don't give people enough guidance on which list to > use for what. Nor is there a community manager who is consistently and > politely but firmly requiring people to use the correct lists ... > > -- Rod I think you've hit the mark there... A clear conception of what list is the appropriate venue for certain matters, a clear explanation of that, and someone designated to publicly but politely police posts could help a great deal. My impression has always been that Devel was for people (largely within OM ,I'd assumed) who were working on core development within the heart of the OS and relating more directly to the hardware, Support was for end-users to raise end-user concerns, and Community was basically for everything else, which at this point in the life of said community is largely relating to development and testing. If that, or just about any other reasonably logical division, were clearly stated and at least loosely enforced, and posts were required to include [FSO] etc identifying the relevant distribution in the subject, things could function much more smoothly. j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Joel Newkirk wrote: > On Sun, 12 Oct 2008 07:35:12 +1030, Rod Whitby <[EMAIL PROTECTED]> wrote: > >> Anyone who has the mindset of "this is broken, how can I fix it?" is a >> developer. >> >> Anyone who has the mindset of "this is broken, I expect it to be fixed >> by someone else right now!" is a user. >> >> The community will have both (and often a single person will be one or >> the other depending on what type of day they are having in real life), >> but you really do need areas in the community (like a developers mailing >> list) where the "user" mindset is simply not acceptable. To do this >> without disrepecting your users, you also need areas where the "user" >> mindset is fully accepted and responded to with excellent support. > > There's also a distinctly grey area that might be exemplified by > 'application developer' - someone who develops software for the platform, > but expects the underlying infrastructure to be stable and complete, and > instability or incompleteness to be resolved 'upstream' at OM, or by > whomever has produced the distribution of their choice. Effectively they > are of the 'user mindset' with regard to the core system (both kernelspace > and core functionality in userspace), but of the 'developer mindset' with > regard to everything sitting on top of it. (general userspace) Very good point. Just like kernel developers are "users" when thinking about the hardware ... > WRT your final point, we already have the 'Support' mailinglist - my > impression is that the intent of that list (not necessarily the actual > usage though) is as a place for the 'user' to go when seeking answers and > fixes, rather than seeking to involve themselves in the actual quest for > those answers and fixes. Indeed, the trouble is there is a third list "community" which muddies the waters between "devel" and "support", and the five word descriptions on lists.openmoko.org don't give people enough guidance on which list to use for what. Nor is there a community manager who is consistently and politely but firmly requiring people to use the correct lists ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Lorn Potter wrote: > Rod Whitby wrote: >> I'm sorry, but I don't believe one single community manager can cross >> the divide between the "developer" and "user" mindsets that I spoke >> about in my reply to your earlier post. > > I disagree. I have been doing exactly that for the last 5 years. Trying > to anyway. I believe a community manager can only be _one_ person. OK, for a single distribution (note that Openmoko currently has 5 different "Openmoko" distributions, not including Qtopia and Debian), I agree with you. But for the current state of Openmoko, I still believe it's too much for one person. > To have a user mindset, you simply need to use what you're trying to > evangelize everyday. You see the difficulties of actually using something. Fully agree. The trouble we have today is that there are so many half-finished, half-working distributions (and everyone is swapping between them constantly trying to find something that works) that nobody is getting any benefit from a synergy like that. Qtopia and Debian are the exceptions, because they are mature distributions with existing communities to which a new device is being added. The group of 5 (2007.X, 2008.X, FDOM, FSO, SHR) are the distributions I'm mainly referring to. > To work with the user community in this fashion, you need to care about > and understand the flaws the software may have (in terms of bugs and > usability) and the reasoning the developers may have done a particular > thing. Only a developer can do this part, and only a developer can work > with the developer community. Fully agree with this too. However, Openmoko currently has about five or six distinct developer communities and about the same number of distinct user communities as well. There is absolutely no way one person can cover all that. So for each distribution (e.g. Qtopia, Debian, ...) I fully agree that having a single community manager that covers both users and developers is the ideal situation. Unfortunately, the current situation with Openmoko is so far off the track (IMHO), that it will need multiple managers just to get it back on track. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Rod Whitby wrote: > Risto H. Kurppa wrote: >> On Sat, Oct 11, 2008 at 3:35 PM, Duv <[EMAIL PROTECTED]> wrote: >>> My only concern here is that there seems to be a separation between the >>> developer and the user... that in the community both seem to have there >>> little corner. Maybe I am reading that wrong, but if I am not... I am not >>> too sure that it's something that I would agree with, if only because the >>> current make-up of OpenMoko, Developer and user are one in the same. >> I agree: There's no reason to make a separation between developers and >> users. They do have a bit different needs but no matter what, they're >> all needed. A community manager should take care of all members of the >> community, from beginners to kernel developers. Help the beginners to >> get involved and allow and enable developers to work as efficiently as >> possible. > > I'm sorry, but I don't believe one single community manager can cross > the divide between the "developer" and "user" mindsets that I spoke > about in my reply to your earlier post. I disagree. I have been doing exactly that for the last 5 years. Trying to anyway. I believe a community manager can only be _one_ person. To have a user mindset, you simply need to use what you're trying to evangelize everyday. You see the difficulties of actually using something. To work with the user community in this fashion, you need to care about and understand the flaws the software may have (in terms of bugs and usability) and the reasoning the developers may have done a particular thing. Only a developer can do this part, and only a developer can work with the developer community. > > It's *really* difficult to spend your day answering end-user FAQs and > support issues, and then turn around and enthuse and excite your > developers. One person will burn out very quickly trying to do both. Perhaps. But variety is the spice of life. It all comes down to passion. > > Note that both needs (support of users and embracing of developers) do > need to be met for a well functioning community. But I don't believe a > single person can do the job of meeting both those needs. I do. -- Lorn 'ljp' Potter Software Engineer, Systems Group, Qt Software, Nokia Pty Ltd ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
On Sun, 12 Oct 2008 07:35:12 +1030, Rod Whitby <[EMAIL PROTECTED]> wrote: > Anyone who has the mindset of "this is broken, how can I fix it?" is a > developer. > > Anyone who has the mindset of "this is broken, I expect it to be fixed > by someone else right now!" is a user. > > The community will have both (and often a single person will be one or > the other depending on what type of day they are having in real life), > but you really do need areas in the community (like a developers mailing > list) where the "user" mindset is simply not acceptable. To do this > without disrepecting your users, you also need areas where the "user" > mindset is fully accepted and responded to with excellent support. There's also a distinctly grey area that might be exemplified by 'application developer' - someone who develops software for the platform, but expects the underlying infrastructure to be stable and complete, and instability or incompleteness to be resolved 'upstream' at OM, or by whomever has produced the distribution of their choice. Effectively they are of the 'user mindset' with regard to the core system (both kernelspace and core functionality in userspace), but of the 'developer mindset' with regard to everything sitting on top of it. (general userspace) WRT your final point, we already have the 'Support' mailinglist - my impression is that the intent of that list (not necessarily the actual usage though) is as a place for the 'user' to go when seeking answers and fixes, rather than seeking to involve themselves in the actual quest for those answers and fixes. j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Risto H. Kurppa wrote: > On Sat, Oct 11, 2008 at 3:35 PM, Duv <[EMAIL PROTECTED]> wrote: >> My only concern here is that there seems to be a separation between the >> developer and the user... that in the community both seem to have there >> little corner. Maybe I am reading that wrong, but if I am not... I am not >> too sure that it's something that I would agree with, if only because the >> current make-up of OpenMoko, Developer and user are one in the same. > > I agree: There's no reason to make a separation between developers and > users. They do have a bit different needs but no matter what, they're > all needed. A community manager should take care of all members of the > community, from beginners to kernel developers. Help the beginners to > get involved and allow and enable developers to work as efficiently as > possible. I'm sorry, but I don't believe one single community manager can cross the divide between the "developer" and "user" mindsets that I spoke about in my reply to your earlier post. It's *really* difficult to spend your day answering end-user FAQs and support issues, and then turn around and enthuse and excite your developers. One person will burn out very quickly trying to do both. Note that both needs (support of users and embracing of developers) do need to be met for a well functioning community. But I don't believe a single person can do the job of meeting both those needs. We found in the nslu2-linux community that if you encourage the more experienced users to start thinking of themselves as "mentors" for the new users, and if you give the developers "permission" to not have to answer end-user FAQs (since the more experienced users are expected to be doing that), then the two mailing lists (users and developers) have a much higher satisfaction rating. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Risto H. Kurppa wrote: > I also want to remind that community is not limited to the developers. > It should also include all users that can be used to create marketing > events and material, generate new ideas and test software and report > bugs. I like to think of the distinction between users and developers as a mindset difference rather than a difference in skills or ability. A user just wants to use the device, gets angry when things don't work as advertised, and expects support from the company that sold them the device. There's nothing wrong with that, by the way. A developer sees something that is not working properly as an opportunity to step in and try and fix it. If given the environment and accessibility to do so, they will often go as far as fixing it themselves and contributing the fix directly into the source base. Note that I make no distinction between code, doco, bug reports, marketing material, fonts, UI elements, wiki pages, etc when talking about developers. Anyone who has the mindset of "this is broken, how can I fix it?" is a developer. Anyone who has the mindset of "this is broken, I expect it to be fixed by someone else right now!" is a user. The community will have both (and often a single person will be one or the other depending on what type of day they are having in real life), but you really do need areas in the community (like a developers mailing list) where the "user" mindset is simply not acceptable. To do this without disrepecting your users, you also need areas where the "user" mindset is fully accepted and responded to with excellent support. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Rod Whitby wrote: > (Wolfgang told the Openmoko admins > to give me svn and git access on the 22 Sept, and nothing has happened yet). I want to make a public retraction and apology on this point. It seems that access was granted sometime between then and now, but either I wasn't informed of that or the notification got lost in transit. My apologies to Wolfgang and the Openmoko admins. -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Hi there, I fully agree with Rod! I would even go so far as to consider having a automatic registration system to get access to GIT, SVN, Wiki and all mailing lists in order to capture even the smallest contribution, regardless of if it is developer coding or correction of spelling errors in the Wiki. Everything that can lower the barrier to participation should be implemented. Since every system is version handled misuse is not a big problem, at least in my experience. We do that over at http://wiki.ops4j.org/confluence/display/ops4j/Principles+of+Open+Participation+Software It works very well! /peter GTalk:neubauer.peter Skypepeter.neubauer ICQ18762544 Phone +46704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - New Energy for Data - the Graph Database. http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org- New Energy for Java - Domain Driven Development. On Sat, Oct 11, 2008 at 11:32 AM, Stroller <[EMAIL PROTECTED]> wrote: > Blimey! Rod makes some GREAT points here - this email should probably > be a standard reference document for OSS projects. When I got to the > bottom & read his credentials they seemed entirely congruent with his > insights. > > I just want to add one little thing, and that's DON'T OVERLOOK THE > DETAILS... as Rod has been thorough in his post, so should you be > thorough if trying to foster an OSS project. Sure, looking after all > the little details should ensure that the bigger picture holds > together, too, but if everything else is going through a bad patch, or > someone is having a bad day, these little things can be the last straw. > > > On 11 Oct 2008, at 06:48, Rod Whitby wrote: >> ... Never let an external developer be >> inconvenienced because some mailing list is sending duplicate >> messages, >> ... > > Openmoko has been told about this COUNTLESS times, and nothing seems > to get done about it. Has anyone actually tried fixing the mailing > list software / server? Some days it just really pisses me off, > reading through the mailing list and having to click "delete" all the > time, because I've seen that message 3 times already. > > Stroller. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
On Sat, 2008-10-11 at 05:35 -0700, Duv wrote: > I think that we might be at a point where this should be our first concern. > How to lift the tide to all boats in the Moko pool. Management of the > community is a great start, since what we currently have would be best > described as disarray. > > My only concern here is that there seems to be a separation between the > developer and the user... that in the community both seem to have there > little corner. Maybe I am reading that wrong, but if I am not... I am not > too sure that it's something that I would agree with, if only because the > current make-up of OpenMoko, Developer and user are one in the same. I didn't read it like that. As someone who is learning by doing it felt more like an invitation. From Rod's post: "Make the barrier to entry very low (if you can write either the code or the manual page or the build system or the gui for "hello, world" for the openmoko, then you're qualified to have access to the SVN or Git repository)." I also agree with the separation of devel and community lists. Its like rooms in a house. Different things happen in different rooms. However that doesn't mean you can't go into different rooms. I entered OM through the living-room. Heard lots of lively conversations. Joined in some. Then I started to smell the cooking that made me hungry and went into the kitchen to watch what was going on. Being hungry I started looking for places to help. Help with the prep? Some appetizers? I'm slowly learning to cook myself. If you're like me when I'm in the kitchen cooking a big meal my focus is on the task at hand. Some banter is around the food is fine, but conversations about church and state no. Save that for the living-room. digger signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
On Sat, Oct 11, 2008 at 3:35 PM, Duv <[EMAIL PROTECTED]> wrote: > My only concern here is that there seems to be a separation between the > developer and the user... that in the community both seem to have there > little corner. Maybe I am reading that wrong, but if I am not... I am not > too sure that it's something that I would agree with, if only because the > current make-up of OpenMoko, Developer and user are one in the same. I agree: There's no reason to make a separation between developers and users. They do have a bit different needs but no matter what, they're all needed. A community manager should take care of all members of the community, from beginners to kernel developers. Help the beginners to get involved and allow and enable developers to work as efficiently as possible. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
I think that we might be at a point where this should be our first concern. How to lift the tide to all boats in the Moko pool. Management of the community is a great start, since what we currently have would be best described as disarray. My only concern here is that there seems to be a separation between the developer and the user... that in the community both seem to have there little corner. Maybe I am reading that wrong, but if I am not... I am not too sure that it's something that I would agree with, if only because the current make-up of OpenMoko, Developer and user are one in the same. Rod Whitby wrote: > > I'll answer this from the point of view of a "development community" > manager. I think you already have a fine "end-user community" manager > in Michael Shiloh. > > A development community manager must have the number one priority of > embracing all the disparate developers working on the Openmoko platform, > and being responsible for "bringing them into the fold": > > > > I say all this based on the experience of running the nslu2-linux.org > project for the last four years, and building a community of over 100 > developers and over 10 thousand users all working in common repositories > producing packages and images for four different distributions (targeted > to four different use cases) using the same top-level build system and > ending up in common official feeds on a single official download site. > > See the following documents for more details: > > http://www.nslu2-linux.org/presentation.pdf > http://www.batbox.org/IsThataLampInYourPocket.pdf > > -- Rod Whitby > (No, I'm not looking for the job) > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/What-should-a-community-manager-do--tp1318997p1319758.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Excellent posting!! This is a very good "job description" for someone like a community manager. Norbert ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Excellent point from Rod! I'm sure actions like this would boost the development to a completely new level! And having better software and rapid development means more satisfied users in the community as well, as soon as some minimal level (I'd say it's working phone in this case :) is reached. Some points here are general guidelines to work with a community, not just a job description for a developer community manager. I also want to remind that community is not limited to the developers. It should also include all users that can be used to create marketing events and material, generate new ideas and test software and report bugs. Rod, great post! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
On Saturday 11 October 2008, Rod Whitby wrote: > I'll answer this from the point of view of a "development community" > manager. I think you already have a fine "end-user community" > manager in Michael Shiloh. Thank you Rod, you posted all the ideas (and more) about the OM dev process, which were floating around in my head and which I have not expressed publicly so far. As a spare time developer for OM, I would like to seconds Rods proposals and would love to see them implemented. They would certainly transform the OM community into the community it should have been right from the launch of the Freerunner on. Cheers, Florian -- DI Florian Hackenberger [EMAIL PROTECTED] www.hackenberger.at ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What should a community manager do?
Blimey! Rod makes some GREAT points here - this email should probably be a standard reference document for OSS projects. When I got to the bottom & read his credentials they seemed entirely congruent with his insights. I just want to add one little thing, and that's DON'T OVERLOOK THE DETAILS... as Rod has been thorough in his post, so should you be thorough if trying to foster an OSS project. Sure, looking after all the little details should ensure that the bigger picture holds together, too, but if everything else is going through a bad patch, or someone is having a bad day, these little things can be the last straw. On 11 Oct 2008, at 06:48, Rod Whitby wrote: > ... Never let an external developer be > inconvenienced because some mailing list is sending duplicate > messages, > ... Openmoko has been told about this COUNTLESS times, and nothing seems to get done about it. Has anyone actually tried fixing the mailing list software / server? Some days it just really pisses me off, reading through the mailing list and having to click "delete" all the time, because I've seen that message 3 times already. Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
What should a community manager do?
Steve Mosher said: > Sean asked me what I thought of having a community manager. ... > I have my ideas about what a community manager would do to organize > and mobilize, But before I put those ideas down, I'd like to throw it > open to the community. > Question: what functions do you see a community manager performing. I'll answer this from the point of view of a "development community" manager. I think you already have a fine "end-user community" manager in Michael Shiloh. A development community manager must have the number one priority of embracing all the disparate developers working on the Openmoko platform, and being responsible for "bringing them into the fold": a) Make sure that they are all at least subscribed to the one developer mailing list, and that that list is forcible kept "pure" from end-user support issues (there are already lists for that). Yes, this means contacting developers individually, and personally (in private) requesting that they join the developer mailing list, and it also means telling people who abuse that developer mailing list for end-user support or chit-chat to go use the correct mailing list (politely, but in public, so others learn). Also make sure the community manager "hangs out" on the official development IRC channel for real-time interactions. b) Maintain a single build system and set of repositories which makes it easier for all those disparate developers to use the "Openmoko" developer resources instead of setting up their own elsewhere. Make the barrier to entry very low (if you can write either the code or the manual page or the build system or the gui for "hello, world" for the openmoko, then you're qualified to have access to the SVN or Git repository). Trust that developers will not abuse the repository, instead of forcibly locking them out (Wolfgang told the Openmoko admins to give me svn and git access on the 22 Sept, and nothing has happened yet). c) Manage those developer resources (mailing list, repositories, wiki) like they are your crown jewels. Never let an external developer be inconvenienced because some mailing list is sending duplicate messages, or some repository system is not allowing anonymous svn checkouts, or some autobuilder is not producing daily kernel packages. d) Show your external developers the appreciation they deserve. When a developer produces a kernel patch which solves a GSM problem, don't argue with him in public and make him feel that his work is not appreciated. Remember these developers are working for you for free. Embrace what they produce, and *make* *sure* that it makes its way into the official distribution. If a developer creates their own downloads area for kernels with their patches in them, then the development community manager has failed in their job. e) Focus the developers on the critical development needs. Do this by continuously reminding the developers of the most critical areas, and encouraging them to submit solutions to these problems. Treat those solutions with utmost respect, never make an external developer feel that they need to jump through more hoops than your employees to get something into the official distribution. f) Treat all the disparate development efforts as part of one "whole". If you see duplication of effort, talk to those people in private and nudge them towards joining efforts together in a single development repository in which they both work, instead of forcing them each to work in their own disparate development repositories in all corners of the internet. Continually encourage consolidation of the lowest levels of development and structure your repositories and development processes to allow multiple people to work on those areas in parallel. There should never be any areas where there is a single person (especially an openmoko employee) who feels that they and they alone are allowed to touch that code. g) *Never* cause a developer's work to be wasted. All those developers who fixed bugs in 2007.2, then 2007.11, then 2008.x, then qtopia, the FSO - every time that their work is somehow excluded by a decision made in private you loose the enthusiasm and drive that makes the difference between a herd of cats and an army of developers. Keep the developers aware of the long-term strategy of where you're heading. Don't surprise them with something that happened in private. h) Structure your software architecture for consolidation and stability at the lowest levels, and multiple co-existing choices at the highest levels. For goodness sake, have a *single* kernel that everyone contributes to and uses. Make sure that changes in that kernel *never* break userspace without the person proposing the breakage going out and proactively working with the userspace people to migrate before the change is forced upon them by surprise. Make sure that all the different choices at the higher levels are all built from the same source base, in the same set of repositories, and
