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 all use the same official feeds. i) Never fork wholesale from upstream. If you need to make a branch, then talk to upstream and try to make the branch in *their* repo. If you need to fork, then fork the absolute minimum set of things possible. The current state of org.openembedded.dev in OE vs org.openmoko.dev in OM is a complete waste of time and effort that has not gained anybody anything. j) Mantain an autobuilder, and manage it proactively. Whenever you see someone mention a package on the mailing lists, make sure that someone adds that package to the autobuilder so that it's part of the official feeds. Have mechanisms where developers can commit source code for a new package and cause the autobuilder to build and release that package on the official feeds without any employee intervention. Treat third-party feeds and packages listed on third-party websites as indications that the development community manager has failed in their job. 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