Ubuntu Wiki

From The Art Of Community by O'Reilly (http://www.artofcommunityonline.org) by Jono Bacon

Transparency is not only a key theme throughout this book, but throughout community building in general. Openness is an important ingredient in healthy communities, and your community needs to feel that there is transparency throughout its governance, processes, communication, and workflow.

In terms of workflow, transparency can be divided roughly into three areas:

• Tool access
  • How open and accessible are the tools that form the foundation of your community and workflow?
• Communication
  • How open and accessible are the communications channels in your community?
• Reporting
  • How well do you report what your community is doing?

Each of these three areas is important for a healthy community. Let’s now spend some time looking into each of them, and cover some of the key points in keeping your community open and accessible.

An important area in terms of transparency is how people who are not yet trusted contributors can contribute to the project to gain trust.

Tool Access

You should always ensure that the tools that you choose to use for your community are easy to access, well documented, and freely available.

When you have decided on your toolchain, you should ensure it is well documented on your community’s website. You should specify:

• The tools that are used in your project.
• Where you can obtain the tools required.
• Instructions for how to use these tools to obtain the work that your community produces (such as the source code for an application) and how to run it.

Another useful goal to aim for, particularly with regard to software development, is to ensure that each contribution is documented. Ideally, you want any contributor to be able to point to any of her contributions by referencing a URL on the Internet. If every contribution can be referenced, your community will be transparent by definition.

Communications

Openness in communication is essential. Your communication channels are the very lifeblood of how ideas, problems, and solutions flow between the different members of your community. The golden rule here is to ensure that anyone (including those who are not currently part of your community) can reference every communication online after it has occurred. I would like to be able to go to any community and read conversations that I was not a part of so I can evaluate the decisions that were made.

This is happening today in most open source projects. Most projects have open mailing lists, and these lists have publicly visible archives that are automatically made available on the Web. Many communities also have small programs called “bots” that log IRC conversations and make the discussions available on the Web.

I would highly recommend making these kinds of archives and logs available. In many cases, it is as simple as switching on a configuration option. The only time I consider it reasonable to have private archives is when a communication channel is being run by a Community Council.

For many communities, sensitive and private discussions, particularly those around conflict, are taken to the council. There are also conversations that pertain to an individual, such as if a contributor has had some complaints made about him. These kinds of discussions need honest input from the council members, and if archives of the conversation are available, many council members will feel uncomfortable making statements that they would otherwise make in private. Just compare and contrast the statements you yourself make in public and in private.

Transparency in communications is not purely about the free availability of archives, though. It is also about ensuring that everyone in your community is welcome to participate and communicate in an open manner. There is one enemy to this kind of participation—cliques.

Cliques exist everywhere. Some of them are pronounced, such as the thousands of invitationonly clubs and associations across the world. Some of them are less pronounced, such as the informal, unwritten, yet obvious groupings that occur when we are all at school. There is nothing wrong with groups; they are natural functions of human social interaction. But they can be destructive in communities that are explicit about their openness to new contributors.

I noticed this for the first time years ago when I set up my Linux User Group in Wolverhampton. As the group grew and regular members attended, a sense of familiarity set in. There were insider jokes, everyone knew the regulars, and the group was generally bonding. Although we welcomed new members, we occasionally heard of people being put off due to “cliquishness.”

Although you should not have overt cliques in your community, you also should not inhibit the ability for people to bond and form personal relationships. As you continue to engage with your community, there are some members who will naturally group together due to similar perspectives, sense of humor, or other attributions. Encourage and welcome these groups, but always be cognizant of the risk that these groups will be offputting to new users. Everyone knows what it feels like to feel unwelcome, but not everyone knows what it feels like to be a possible cause of that feeling.

Reporting

The final aspect of transparency with regard to workflow is keeping everyone on the same page. This is all about reporting.

Some time ago, we wanted to improve how different parts of the Ubuntu community communicate what they are working on. We have hundreds of contributors all over the world, each working on different teams, and I was keen to see a single web page from each team with bullet points containing what they had achieved that month.

This was something of a challenge. Reporting is not a natural by-product of community, and most communities struggle at producing metadata such as this. Communities are great at doing the work that interests them, but activity reports and additional information does not flow naturally. The only chance of making this work was to make the process as simple as possible, and to encourage as many people to engage in the process as possible.

The process I developed was about as simple as I could get. I had a set template on the Ubuntu wiki, and each template was named for the given month. I asked all teams to get their feedback in by the 20th of every month. This would leave a few days to tidy up any missing pieces of the report and announce it on the 22nd of each month. For each team, I asked someone to be a team reports contact, and every month I would nag them to get their content in. Some teams would be as reliable as you could imagine. Some less so. In general, though, the team-reporting framework generated some useful content.

The value of the team reports was obvious. They were well received, and it was fascinating and inspiring to see what everyone was working on. The approach I fleshed out could easily be rolled out to your own community. You should seriously consider it.

Another little story I will share about reporting was one that we faced at our Ubuntu Developer Summits (UDS). At every UDS we would have a large number of discussion sessions, and we had some facilities in which people could listen in to the sessions through an audio stream and communicate with us via IRC. Despite these methods of engagement, we still wanted to release a set of proceedings from the summit. This would be a summary of decisions made at UDS that would affect the development of the next version of Ubuntu.

Our first shot at this was to produce a wiki page for each track at UDS and ask attendees to update the page at the end of each session. A simple process, but it got limited uptake. There simply was not time at the end of sessions for people to summarize the agreements. As such, we got relatively sparse proceedings for each track.

For the next UDS, we had a different idea. In recent years microblogging platforms such as Twitter (http://www.twitter.com) and identi.ca (http://identi.ca) have become a common part of many people’s workflow. It is not uncommon to send out a quick “tweet” or “dent” to let the world know what you are doing. We figured this could be an interesting approach for our proceedings at UDS.

To do this, we conducted an interesting experiment that worked rather well. Using identi.ca we registered an account for each track at UDS. In each track room we had the login details for the account on the whiteboard. We would then encourage everyone to microblog as the sessions continued. The final part of the process was to write a script that took each of the microblog entries and divided the messages into the relevant sessions. As an example, all the messages on the community track between 1 p.m. and 2 p.m. would be automatically grouped under the heading “Making LoCo Teams Rock,” the name of the session at that time on the community track.

The moral of this story is that to get effective reports, the method needs to be as low-friction as possible. People were already used to microblogging, so asking people to microblog sessions was entirely natural for many people. This is the essence of effective reporting.

Another useful tool that has been a common staple at UDSs is a collaborative and cross-platform text editor called Gobby (http://gobby.0x539.de/trac/ ).

In the Gobby text editor, multiple people can edit the same document at the same time. You see the changes that other people make in real time in your instance of Gobby. It is a clever little tool. Gobby is useful when multiple people are working together to record notes for a session or working together on a specification or strategic document.