Ubuntu Wiki

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

One of the most wonderful attributes of communities is their ability to surprise. From tiny acorns great trees grow, and the branches of community often spread far and wide. We have seen this countless times, be it Ubuntu, Wikipedia, the Barack Obama campaign, or other communities you may have joined. When your community manages to captivate and develop mindshare, not only does the focus of the community grow but so does your membership. More of these people want to be a part of the journey that your community is on, and they often share the same passion and devotion to reaching the final destination as you do.

Although no one is going to quarrel with this growth, it can generate a headache: how on earth do we scale our governance bodies up to manage this larger group of people? Fortunately (in terms of hard problems) or unfortunately (in terms of not many people joining your community), this is a problem that only some of you will need to face.

Knowing When It Is Time

In an ideal world we would not need to set up any governance in the first place, let alone set up additional subcouncils. Each additional level of governance that you add to your community is another step away from being a simple and nimble entity that is clear for everyone to understand. It gets a lot more icky when there are Community Councils, team councils, delegated bodies, and other such pomp and grandeur. Your community should set up this additional governance only if absolutely necessary.

Of course, many communities need multiple levels of councils, and we certainly discovered that in the Ubuntu community. Despite its seeming complexity, I know that every piece in the Ubuntu community is absolutely necessary, and that is our ethos here.

Additional governance is required only when existing governance bodies are not able to scale or cater to your community’s requirements. Unfortunately, some communities don’t quite get this right and decide to set up vanity councils: governing bodies that achieve nothing more than making the members of the new council feel special.

This can happen in the simplest of scenarios. As an example, imagine the Tobe project that we discussed earlier really took off and became the hot new thing. If it is like any other successful community, a raft of additional resources will be created for the project. One typical example would be discussion forums. When the forums go online, we would likely see the same thing that has happened in other communities: a very passionate yet vocal community makes its home in the forums.

Although the Tobe Forums community may be small, the vocal few in the forums want to feel special: they want a governing council. In their eyes, governing councils bring all kind of fun things: a sense of control, authority, and power across the wider project. Not only this, but they see a council as required for the community to be a real community.

Nonsense.

There is simply no reason for this council. The Tobe Community Council already exists as a place to resolve issues, and the wider Tobe community is still fairly small. By creating this council you will effectively double the risk of bureaucracy.

Here are some indicators of when it might be time to reopen this chapter, blow the dust off, and read how to build a council again, but this time a subcouncil:

Bottlenecks:

Many councils face bottlenecks. These typically occur when the existing council is either failing to organize meetings, a few people on the council are holding decisions back, or there is too much work for the council to do. The first two issues should be solved by fixing your existing council. For the third issue, you may want to first see whether the existing council can commit more time to the council. If not, another council may be required.

Specific knowledge required:

When you form a large subcommunity in a specific area of your community, that subcommunity may require some specific knowledge that your general Community Council does not possess. When you see many issues occur that require this knowledge, a subcouncil may be required. One area that often calls for specific knowledge is conflict resolution in specific parts of the project. As an example, conflict in a developer community will require knowledge of both the people involved and the development tools and processes.

Separation of skills:

When you have a general Community Council up and running, you may find that a number of requests fall into one specific category and that these requests need more focus and experience. An example is if you get lots of technical requests that require extensive knowledge. This may warrant the formation of a Technical Board.

Locale/language:

If you have a large community forum around a specific language or locale and the people there are struggling to communicate with the main Community Council, a regional council or language-focused council may be required.

Each of these situations exceeds the time, knowledge, or skills of the existing governance body. The quantity of requests is the justification for the subcouncil: if you get only a few domain-specific requests that your Community Council struggles to deal with, a separate council may not be required, but if the council gets regular and repeated requests, it is worth considering.There are many examples where the issues just described resulted in the formation of councils.

One such example, mentioned earlier, was the formation of the Ubuntu Membership Boards. In terms of expertise, the Community Council was capable of handling each membership request, but the sheer volume made it unfeasible. These three subcouncils were formed to cover the Americas, Europe, and Asia, and took over the responsibility of reviewing Ubuntu membership requests.

Another example was the formation of the Forums Council, triggered by the overwhelming demand for governance and forums experience in the forums community. Similar considerations also spawned the Ubuntu MOTU Council, which governs the developer community that builds packages for parts of Ubuntu. The council was formed from existing MOTU developers to provide a better level of knowledge for assessing new developer requests.

All of these examples have ultimately been successful in governing their respective parts of the community.

Building the Subcouncil

Fortunately, once you have been through the process of building your main Community Council and have justified to yourself and your community that a subcouncil is required, forming this new subcouncil is relatively straightforward. All you need to do is repeat the steps earlier in this chapter that explained how to form a new council. While following the process you should take extra care to codify the council thoroughly. You should consult heavily with your community and expect a barrage of questions seeking to justify the new council.

Your community is going to be nervous about new governance, and you will likely notice a slight paranoia that some of their rights are going to vanish as they perceive the cold chains of bureaucracy clanking down hard on the community. If you’ve followed the careful thought processes I’ve described, such concerns are ridiculous.

We are all here to show bureaucracy who is boss, and ensure it has no home in our communities. Make sure your community knows this. This will require ensuring that your codification is easy to read and understand, and regular reassurance to your community about the scope and responsibility of the new governance body.

When you have a broadly acceptable codification in place, the next step is to run it past the existing Community Council. You should expect the document to go back and forth with the council a few times before it is considered complete. When this is ready, you are all set to ask the Community Council to nominate members for the new council and optionally have an election with your community members to select between these nominees.

Escalation

With at least two councils in place, you should now ensure that your community is entirely clear on how each council works and also how they fit together. More specifically, your community needs to know how issues can be escalated from one council to another.

To do this, you should write an issue escalation document that illustrates clearly how an issue should flow through your governance structure. Here is an example of how this document could be applied to the Tobe community with its Community Council and Forums Council.

TOBE COMMUNITY FORUMS ISSUE ESCALATION

In the Tobe community, we have two governing bodies that are available to resolve and manage issues. These are:

• Tobe Community Council—this council is the highest serving governing body in the Tobe community. It discusses and decides on general community issues, policies, and processes. This council is also the top-level platform to discuss conflict issues.
• Tobe Forums Council—the Forums Council governs the Tobe forums community and reports to the Tobe Community Council.

If you have a problem or concern, these governance structures are available to listen and pass judgment on the issue in question.

If you have a FORUMS issue, you should first add your issue to the Tobe Forums Council agenda by clicking [here]. Do not take your issue to the Tobe Community Council; you will be immediately asked to refer to the Tobe Forums Council first.

If you are dissatisfied with the service you have received from the Tobe Forums Council, you are welcome to escalate the issue to the Tobe Community Council. Please note that by doing this you are effectively stating the following:

• You believe that either the issue was not fairly and objectively considered by the Tobe Forums Council or that the council members do not possess the knowledge to effectively pass judgment on the issue in question.
• You are happy for the Tobe Community Council to perform an assessment of how effective the members of the Tobe Forums Council were in assessing the issue. To escalate the issue, add an item to the Tobe Community Council Agenda by clicking [here].

Establishing communication channels for your council is critical. This is an expected resource in each and every council that your community puts together. It allows the council to share ideas, deliberate on topics, and reach decisions.

Friends, the communication love doesn’t end there, though. Now we must put our devious little minds to another opportunity: how can we help our multiple councils communicate with each other? The reason and inspiration behind this shared cross-council communication are those two magical words in community management: best practice.

If you have two councils that are formed (e.g., a Community Council and a Forums Council), you essentially have two groups of motivated, responsible, objective, and reliable people. Although each member on these councils should have a minimum level of suitability for the council based on the attributes that we discussed earlier in this chapter, there is oodles of potential for these council members to learn from each other and further improve and refine their governance abilities.

To do this, I recommend you set up an additional mailing list on which you ask every council member in your community to be a member. I know, I know, you are probably getting a little sick of setting up all of these mailing lists, and I am by no means encouraging mailing list fetishism, but this cross-council list will be a valuable resource. Another added benefit of this list is that it lets you address all of the governing members of your community in one place, which is helpful for sharing best practices.

Although it may seem a little less-than-transparent, it's recommended that this governance mailing list be a closed, members-only list with closed archives that only the current council members in your community can access. The reasons for this are the same reasons behind the recommendations for each council to have a private mailing list: for honest and frank conversation to flourish, they often need a context that is unmonitored.

CategoryBuildingCommunity