We had several interesting unconference sessions and talks at the Google Summer of Code Mentor Summit 2011. I proposed and coordinated the unconference session titled "Community matters", the Saturday 22nd of October 1.30 - 2.30, at the room "Algiers". We had around 12 active participants from multiple organizations, representing AbiWord, Apache, and more.
The session notes are recorded in the Google Summer of Code wiki, which needs the log in credentials to access. Hence I summarize the notes again for the wider audience. These notes are from the thoughts of the mentors from the communities involved in the discussion, and they might reflect the communities involved (Hence the points, may of course, disagree to each other to some extend). I represent AbiWord, and hence my views are biased towards the culture of the AbiWord community, which I consider the best of all. ;)
The session notes are recorded in the Google Summer of Code wiki, which needs the log in credentials to access. Hence I summarize the notes again for the wider audience. These notes are from the thoughts of the mentors from the communities involved in the discussion, and they might reflect the communities involved (Hence the points, may of course, disagree to each other to some extend). I represent AbiWord, and hence my views are biased towards the culture of the AbiWord community, which I consider the best of all. ;)
What is a community
- People with a common purpose or goal
- Communicating with each other
- Contributing to achieving the goal
- Like a big family
- It's the most important asset in an open source organization.
- Defining the goal(s)
- Not everyone has the same goals, need to define them as a community
- Each one's goal regarding the community should contribute to the community's common goal.
- How to bring people in (making it easier to get started contributing)
- Reducing the hassles involved
- AbiWord: Helping or mentoring the interested newbies to start contributing to a project.
- Apache Software Foundation: give people commit access early.
- It's version control, we can roll it back!
- Make the restrictions social rather than mechanical (e.g., give someone commit access, but encourage them to get the code reviewed before committing, commit only in their area, etc.)
- Use GitHub, SourceForge, or something similar to have branches and pull requests, which makes people able to commit on their branch and collaborate with the community. Also GitHub allows people to not have to learn git. [barrier reduction]
- Have a policy that someone cannot contribute a completely new module until they have been part of the dev community for a year first.
- One thought: maybe you don't need that many people
- Novice issue tags plus "office hours" in IRC - mentor new dev contributors in learning the contributing processes, with an easy issue for the newbie, so the starting barrier would be reduced.
- Have someone who is the "greeter" in the issue queue. If an issue waits for a given time (say 3 days) with no response, the current "greeter" at least says "Thanks". This duty rotates as people get tired of it.
- Break tasks up into manageable chunks
- Communications are a major challenge
- Some people are always on IRC (coders usually), some never on IRC (designers).
- Ban IRC for making decisions - has to happen on a mailing list (Apache Software Foundation and many other projects)
- To make a mailing list work as the discussion tool, people have to be told "bring it to the mailing list"
- Some people like asynchronous communication (e.g., mailing lists) rather than synchronous/real-time (irc), plus with a world-wide community, real-time meetings are not possible
- Mailing lists are good for archives, but are slow for actual discussions
- Get people together in person from time to time, if possible.
- People are not located geographically close to each other.
- IRC becomes active around the clock, if we have developers around the globe (AbiWord).
- Language difficulties - English is not everyone's first language.
- Localizers help on overcoming the language barriers to a project.
- Have to make it feasible for users to provide feedback/issues
- Depends on the type of project, whether that is difficult or hard
- User community is where new developers come from
- Figure out how to interact with them
- Derby rarely uses mailing lists - they rather use the issue tracker.
- Many users are more familiar with the mailing lists.
- So mailing lists help building the community healthy and friendly.
- How to attract new members to the community
- Marketing to attract users
- Go to the competitive events and meet potential users there (if appropriate for project's target audience).
- Get academics interested, then students will follow and they become part of the organization.
- Cooperate and collaborate with the other FOSS project communities - Common code segments to be used by multiple communities.
- Marketing to attract users
- Statistics
- How many contribute x number of patches
- Measure how well the new contributors are getting integrated as regular contributors
- Community health: are we adding new contributors
- Don't measure lines of code or number of patches - doesn't reflect community health
- Measure how many contributors are contributing to a project or sub-project as a measure of its health
- Apache foundation board will warn and/or ban projects that are not on-boarding new contributors and otherwise acting in a healthy way
- 90/9/1 split
- 90% of users do not communicate. 9% submit bugs and maybe a patch occasionally. 1% get really involved.
- You can double the 9% part by greeting and other contributor support strategies.
P.S: The "!!!111" at the end of the title ("Community Matters!!!111") was intentional, and I put that on the session proposal too, to give it a kid's touch, who desperately wants to contribute to the FOSS communities. ;)
- AbiWord community's blog roll - Planet AbiSource.
