Writing Open Source

Addison Berry on Herding Cats in the Drupal Documentation Community

Addison Berry, aka @add1sun, presented about her experience as documentation lead for the Drupal content management system project the other day at the Writing Open Source conference in Owen Sound. In her role as chief cat-herder, she found that the most difficult people aren't poisonous. Instead they just don't know how to communicate with the community, and they need to translate where they're coming from to the way the community operates. It's hard work, she reports, to turn them into a contributor. She referred the audience to the "Poisonous People" presentation by the Subversion people, as yet unwatched by yours truly.

Addison talked about religious wars that occasionally break out. That is, the crux of the issue is more important than the resolution, and often leads to inaction. She also discussed the differences between recruiting in the corporate world and recruiting in the open source world. For private companies, they hire a skillset that they can filter for by listing the job requirements, either explicitly or implied. In open source, she says, you have the skillset first and you work with it. Many cats scratching their own itch, hence the herding to get them to scratch the community's itches too. The people you get working on a project have a rich background, both in terms of skills and life history. Skillsets include a lot of non-technical backgrounds in open source (Addison has an anthropology degree, for example, and my education is in political science).

Drupal has a large mass of documentation, and Addison is trying to whoop up energy in managing the base of existing documentation for Drupal 5 and 6 while gearing up for writing the documentation for the upcoming Drupal 7.

Open source has a natural passion that brings people together. Showing the example of a rowing team on her slide illustrated the need to hire a coach to tell them when to row. Herding involves keeping lines of communication open and opening up new ones as well as banging on pots about documentation. Instead of telling people what they can do, empower them by including them in the conversation. Addison, as leader, knows what she won't do and has so far been able to find people who will. Tracking metrics around the documentation—answering a question I had before I had the chance to ask it—Addison is not interested in, but she found someone who is. Many "soft-skills", such as facilitation, have come in handy even if the person with the skill does not claim membership in the software community. Also universities and their students have found time and energy to contribute usability testing as part of course credit or as part of their graduate studies.

Letting go and getting out of the way: Addison wanted the vision to be perfect, but quickly understood that she can't lead the charge or drag it out all the time: instead she recognized the need to let people run with things and support them. Getting people to trust you that that's the right direction.

Planet Writing Open Source
Feeds in the blogs from attendees of the open source documentation writers conference held in Owen Sound, Ontario.

Attending Writing Open Source June 12th to 14th

In a week, I will attend the Writing Open Source conference in Owen Sound, Ontario. I'm excited to meet some of my colleagues in the field of open source documentation, having written the bulk of the support materials for Bryght, the Drupal-powered hosted service. I'm particularly interested in meeting those working to document open source tools other than Drupal, to gain some perspective on what's out there and what's needed.

Writing documentation was my first task at Bryght back in 2004. I recall spending part of that Christmas break furiously jotting down the important steps to creating dynamic and community websites. This included checklists, instructions and descriptions of module settings and how people could take advantage of them. The initial push of documentation made the subsequent job of supporting customers easy: instead of each time having to explain how to do something, I quickly pointed to the documentation, either through a link or a copy & paste. Along the way I even heard from non-customers thanking me for the handy references. After the second time someone asked we documented the answer. (We even wrote documentation after the first time someone asked a question.) Sometimes it didn't work, and sometimes the documentation wasn't all that great or hard to find. We allowed comments and opened the forums and listened to feedback when what we wrote didn't make a whole lot of sense. That's the experience I'd like to share with the conference, and I'd like to hear of others' experiences in making complex software more understandable.

After the weekend conference, I'll spend a couple of full days in Toronto proper, getting some much needed distance from Vancouver. I'd like to meet with some of the Toronto Drupal heads, and others I know (but haven't met) from other online communities I'm part of. Sadly, my favourite baseball squadron, the Toronto Blue Jays, play on the road in late June. Surely a local pub will have the games in HD?

The themes at Writing Open Source have a lot in common with two sessions I attended at FSOSS (the Free and Open Source Symposium) in 2006. I wrote two well-received pieces about the symposium, both notes on sessions at the conference:

(Audio and video for both presentations are available at http://fsoss.senecac.on.ca/2006/recordings/)

I'm looking forward to the sessions in Owen Sound next week, and to sharing what I learn there!