Report from PNWDS, BADCamp, and GSoC Mentor Summit
I spent the last two weekends at conferences -- a lot of traveling, but it is always good to see the people I'm interacting with online every day, and meet some new people.
The weekend of October 15, I attended the Pacific Northwest Drupal Summit. Highlights:
- Attended sessions on Responsive Design and embedding maps in Drupal.
- Presented a session on contributing to the Drupal community
- Participated in a "Birds of a Feather" gathering on community issues, and then attended a session on metrics for community health. See the GSoC section below for more on metrics.
The next weekend, I headed to the San Francisco Bay area. On Friday, I was at the Bay Area Drupal Camp Core Developer Summit. After a series of short talks (I gave one on what's happening in the Drupal documentation group), we spent the afternoon working on and discussing many aspects of Drupal. I was most excited by the novice contributors guide that Kathy H. was working on, which hopefully will be coming to Drupal.org shortly.
Saturday and Sunday I was at the Google Summer of Code (GSoC) Mentors Summit. This was a wonderful gathering of people from 175 open-source software communities where Google had sponsored students this past summer -- about 350 people who mentored students attended, and I was one of two representatives from the Drupal project. It was an "un-conference", which meant that we self-organized sessions, and most of them were discussions rather than presentations. I participated in several discussions about building better open source communities, documentation, Wikis, and Content Management Systems. My overriding feeling was that we are doing a lot of things really well in the Drupal community, but there were several ideas I heard (or particpated in creating) that could be useful for us:
- Make the documentation "gardening" tasks (cleanups, etc.) more visible
- Make the gardening tasks more fun.
- To get good documentation written, have a focused sprint. The GSoC held a documentation sprint the week before the mentor summit, and the process there worked really well. They had about 4 people from each project, and went through these steps (focusing on the outcome of writing a book, rather than any other documentation tasks):
- Define the audience, and come up with a one-sentence summary/title for the book (fairly quick).
- Generate a table of contents (took 1/5 of the time).
- Split up, and write the chapters, not worrying about the formatting. Editing in pairs rather than individually worked really well (took 1/2 of the time).
- Formatting and editing, to make the different chapters share formatting. The participants felt that leaving this to the end was good, since they didn't have to worry about it while they were writing (took 3/10 of the time).
- Print it out (something tangible to take home). The participants felt that the ability to see the book online as well as print it out (via Lulu.com or another print-on-demand publisher) was very good for their audiences (especially less technical and academic audiences).
They used the "Booki" tools for Python/Django, as installed at http://flossmanuals.net (which also displays the manuals they created). They all liked this system quite well. And they also said that having some "outsiders" present for the sprint was useful, to point out the things that a new person wouldn't understand.
- Two-minute screencasts would be a good addition to documentation (with captions for hearing-impaired people, and to improve comprehension by 70% for everyone). Making screencasts would be a great Google Code-In project for students, and YouTube has a captioning tool.
- Attracting and retaining contributors: I heard over and over the idea of thanking people for any contribution, being positive before criticizing a patch, and stressing in the community the idea of everyone being polite always.
- Metrics: Several projects are measuring the health of their community -- here's a blog post that lists several efforts. The key is to make sure the things you measure are really reflecting the health of the community.
- Have a "greeter" in the issue queue. If an issue waits for 3 days with no response, the current "greeter" at least says "Thanks". This duty rotates as people get tired of it.
- Making contributing into a game could help to increase participation and retention. Book: Game storming: A playbook for innovators, rulebreakers, and changemakers, by Dave Gray, Sunni Brown, James Macanufo (O'Reilly). Key ideas from the session:
- People get points for doing things that the project wants to encourage.
- Focus is on encouraging new contributions and more frequent contributions.
- Earning points gets you to a "level". Best if there is some fun pop-up or badge associated with this.
- Make sure the points/levels are not associated with real money or benefits, just recognition.
- Be careful about how the points are awarded. For instance, if you just count patch submissions, people will contribute lots of very small patches and be recognized more than people making larger contributions. So you could instead have peer-review ratings for issues (or "quests") to determine how many points you would get for fixing that issue, or maybe have a limit to how many patch-related points you could get in a certain time frame. Another idea: award "heart" points for the importance of the task (or the amount it is needed for the project, or for tasks people aren't doing that need to be done), and "star" points for the difficulty. Level advancement could be based on the sum of hearts and stars.
- Be careful about gender/age/culture issues when designing the game feel, so as not to alienate potential contributors.
- Keep the mechanics of the game simple, and automatic when you contribute.
- The game should support knowledge gain and mastery. Peer review can help - don't award points without someone approving the contribution. If a task is worth a certain number of points, someone can decide how many to allocate to which participant.
- Integrate the game into the project - information on the home page of the project (leader board tag cloud?), pull points from regular contributing activities (issue queue), don't change how people are already contributing but make the points a side effect of what people should be doing.