#title Setting Up a Community Council <> ''From The Art Of Community by O'Reilly (http://www.artofcommunityonline.org) by Jono Bacon'' A council is a group of selected members in a community who govern collectively. Issues and topics can be presented to this council, and they will come to a united opinion that is typically concluded in a vote. As an example, if the council has seven members, they may allocate 20 minutes to discussing a proposal and let it go forward if four members support it. (In practice, if your council is deciding a lot of issues on the basis of a bare majority, the community is not well governed and there is likely to be destructive conflict—but we’re just covering the basic principle here.) Many communities form a Community Council, a single council that governs the entire community. For most communities this is a great solution, but larger communities benefit from delegating some authority from the Community Council to additional subcouncils. For now, though, we are going to explore what is involved in setting up a single Community Council to govern your community. === COUNCILS VERSUS TEAMS === This chapter discusses long-term forms of governance, which are basically invested in councils or boards. This is different from groups that form more organically and naturally to handle particular objectives or goals in your strategic plan. The less formal groups are usually called teams or committees. I talked about teams in Chapter 2, and they are certainly the basis for effective community work. But teams or committees focus on getting some concrete task done, not on governance, so I don’t cover them in this chapter. Certainly, a council can form a team to handle a specific task related to governance, such as writing one of the documents I describe in this chapter or nominating members for councils. == Designing a Council == Our first task is to understand what you want to achieve with your Community Council and document the full extent of its responsibilities. Governance bodies are fundamentally institutions with an authority the community agrees on, so we need to understand where that authority begins and ends. This agreement is also important for your community: they will want to have confidence in what the Community Council can help with, and also will want to understand what areas are beyond their control. Obviously, the limits are even more important for subcouncils so they don’t make decisions at cross-purposes. Designing and documenting your council is important for three reasons: * Explicitly discussing the council’s responsibilities will help you as a community leader understand the full rationale behind the council and how it should work. * Clear expectations also help everyone who serves on the council know how to handle their responsibilities and will make them more willing to serve. * A well-designed and -documented council will protect your community from accusations of corruption. If the remit and extent of the council are well known and the members are known to act within those expectations, accusations of favoritism or misuse of authority will be rare. The building blocks of a council are your decisions regarding: * Responsibilities. * Structure. * Membership. * Communication. The next few sections of this chapter look at the choices you have for each of these building blocks, and some of the criteria that help you make your choice. Along the way, I’ll show you how to document your decision—a crucial aspect of governance. Like anything else you want your members to learn about, a council requires documentation. To make this as simple to understand as possible, it’s easiest to describe an example fictional council. So, friends, for the next few pages we are now all members of an exciting new open source project that has produced a Frequently Asked Questions content management system called Tobe (named after “to be or not to be, that is the question”). Actually, trivia fans, this was an old project I worked on many moons ago when I was a web developer, so it seems like an apt choice for an example. '''NOTE''' The Tobe project is no longer running, so don’t get too excited if you are looking for something similar. I still think an FAQ management system would be an incredible resource for many communities, though, so if you produce one, do let me know! Our fictional Tobe system is a complete web application for maintaining FAQs. It is written using the PHP language and MySQL database. Because it’s fictional, let’s say it has an excellent user interface, wonderfully written code, and legions of fans around the world (including Johnny Depp and Nicole Kidman). As such, Tobe has a large and bustling contributor community, so large that we are feeling the need for a Community Council to help guide the project forward and ensure the community is always open and accessible. === Responsibilities === The primary purpose of a council is to provide fair governance and feedback on an agreed set of responsibilities in the community. What you choose as these responsibilities will vary: it is highly dependent on your community. But your community needs to be united in agreement about what these responsibilities are. We need the community to be fully aware of what purpose the council serves. Choosing this set of responsibilities may be more complicated than you imagine. What we are shooting for here is a council that members need to consult relatively rarely and only when there’s no way around it. What we don’t want to do is to build an environment in which someone can’t scratch her leg without consulting the council. If we assign too much responsibility to the council, it will annoy the community and make it feel restrictive, and I can guarantee that the council will also become an impediment to getting things done. For communities, I heartily endorse the old aphorism, “That government is best which governs least.” On the other hand, we don’t want to provide the council with too little responsibility: it does need to have the power to resolve disputes and set direction firmly when the community needs that guidance. In a nutshell, we need to strike a balance. The common responsibilities that you may want to consider for your council are: === Membership approval === A council is often a useful body for approving or rejecting members who want to join your project. You need to decide what kind of members these should be—general members, developers, other contributors, etc. We will discuss this in more detail shortly. === Conflict resolution === Many councils act as an objective third party in dealing with conflict. In this case, members of the community will schedule a conflict discussion with the council, and the council members decide on an appropriate outcome. This has occurred in the Ubuntu community many times, and the Community Council typically has been successful in bringing closure to conflict issues. === Project values === Many councils act as an arbiter over the core values of a community. As an example, in the Ubuntu community there is a set of core values around freedom that the project always seeks to maintain. If anyone feels these core values should be adjusted, or if they have not been met, the member is advised to raise this with the Community Council. Note that upholding core values is key to conflict resolution, but it’s not quite the same thing, because communities also sometimes drift away from their values unintentionally and just need a reminder. === Community process changes === Councils can drive changes to processes in your community and get those changes accepted. If you have a Community Council that is known to fairly represent the community and they approve a process change, your community will feel like the process is now considered “official.” As an example, in the Ubuntu community we changed the process in which developers applied to be a member of the project, and the Community Council needed to approve it. When it was approved, the community unequivocally accepted it. === Ordaining governance bodies === If your community is large and requires multiple governance councils, your primary Community Council should be the body to make a proposed subcouncil official. As an example, Ubuntu’s Community Council approved and officially nominated members for subcouncils such as the Forums Council and IRC Council. === Direction === Councils often determine, or at least weigh in on, the long-term direction of a project. As an example, if you are a software project, your council may decide on the feature goals for a given release targeting a given release date. This is a controversial topic in governance, and many communities vary in whether they allow a governing body to dictate features or their timing. In the Ubuntu community, a separate body called the Technical Board acts as an arbiter over debates concerning feature direction. While you are considering which responsibilities your council should take on, ask yourself how much impact these topics are going have on the day-to-day work in your community. As we said earlier, you want to achieve a state in which your community has to interact with a governing body only on limited occasions. Let’s look at a few examples of what not to do: * As I mentioned, leaders may decide to grant councils the right to set feature direction when there’s no need for it. If you have excellent contributors who are not on the council, the right features may simply arise from their work and discussions. * The council does not act as a bottleneck to choose people for small, straightforward roles such as mailing list moderator. Making the moderators go before the council to approve a new moderator is a waste of everybody’s time, as long as the moderators are happy with their own decision. * The council should not have to approve the formation of a new team. Let people set up their own teams as they see a need. This will result in more teams and more diversity in your project. But the council could set up a special category of approved teams who have additional responsibility and need to be vetted by the council. An example of a useful role for an approved team is the Approved LoCo Teams (local user groups) in the Ubuntu community. While anyone can set up a local Ubuntu LoCo team, those teams who have demonstrated consistent good work can be approved and will have better access to merchandise, content, and resources. This is a useful way of reducing waste of resources because approved LoCo teams are generally a lot more responsible. After deciding on these responsibilities, you should put together a document that outlines each responsibility in detail. This can be the basis for forming the council. Let’s apply this to our Community Council for the Tobe project example. I think this would be a suitable selection of privileges. '''TOBE COMMUNITY COUNCIL RESPONSIBILITIES''' The Tobe Community Council (TCC) will govern the Tobe project by exercising the following responsibilities: * Developer Approval—the TCC will judge applications for project developer positions. A prospective developer should present a wiki page that outlines his work in the Tobe project and lists at least two endorsements from current developers. The TCC will vote on the application. * Process Changes—any significant changes to community-wide processes should be approved by the TCC. * Governance Changes—any changes to community governance (including the formation of new governance bodies) should be approved by the TCC. * Conflict Resolution—if a member of the community has a conflict with other members that is hampering work and cannot be resolved, this issue can be raised to the TCC. The notice can either be given publicly in a meeting or be privately posted to the TCC mailing list. Any case put before the TCC should have as much externally referenced evidence as possible to demonstrate the conflict. (You may notice that I have not included “Direction” in these responsibilities. I don’t believe that governed feature direction is necessary for a small community such as Tobe, because it could inhibit innovation.) == Structure == With our responsibilities in place, we now need to plan our council’s structure. While a council may seem a fairly straightforward structure—a group of cooperating members—we need to consider some important details. The first decision is how many members should be on the council. For most of the councils I have been involved in, a good number is five to seven. This provides a good range of opinion on topics while building in enough redundancy to handle absences (such as when members are on vacation). Base the number of council members on the number of good candidates you actually have available. Don’t pick seven members for the sake of a large size if you only have two or three existing contributors who would make suitable council members. We will discuss how to assess quality members later in this chapter. The next decision is whether one of your council members has a tie-breaking privilege. If you have a meeting attended by six council members and three vote on each side of an issue, you reach a deadlock that cannot move forward. So seriously consider appointing a member with the privilege to cast a tie-breaking vote in a deadlock situation. In the Ubuntu community, Mark Shuttleworth has this privilege. The Fedora and OpenSuSE Linux distributions have similar roles in place. If you decide to include a tie-breaking role, ensure that the person in this role is the very model of objectivity and responsibility. The privilege confers great power, and you must ensure it is always exerted with the best interests of the community at heart. We will discuss membership requirements in the next section, and your tie-breaker should excel in demonstrating the attributes in that section. '''NOTE''' Of course, you may consider yourself for this privilege. But before you do, look at yourself in the mirror and ask whether you deserve it. Although by reading this book you evidently have the interests of community at heart, can you really offer an entirely objective opinion? The next consideration when deciding on the membership structure of the council is how long each member serves. There are of course varying opinions on this. Some believe that one year is a suitable term, particularly given the fast-changing nature of community. Others believe two years is more appropriate because it provides a better sense of stability and focus for the council, and it lets your community get used to the same names and expectations. Some people, after serving on councils, say, “It took me a year to figure out how the council works.” I believe that term length is largely dependent on (a) the type of council you are building, and (b) the maturity of the membership you have available. For general Community Councils that oversee process changes, conflicts, and other similar elements from our list of responsibilities a few pages back, it is reasonable to have a two-year term. This has been used in many existing councils and has worked out well. For technical and direction-focused councils, I feel a one-year term is often more appropriate. A shorter term always ensures that your council has fresh perspective, and if the current council is serving well, simply allow the members to continue their term. Term length is related to the decision of whether existing council members can (a) serve repeat terms, and (b) be on multiple councils simultaneously in your community. If you have excellent governing community members, you should allow them to continue doing great work. However, you should also have a fair and representative system in place to ensure that your community does not develop an "old boys club" with ineffective governing members who may not be especially forward-thinking. In other words, excellence should not be capped by term length, but you should ensure your community can kick out ineffective members. '''ALWAYS MAINTAIN QUALITY''' Remember that if you have problems with an "old boys club" nesting in your council, your governance structure can be changed to prevent it. In some communities, if the selection process for governing members repeatedly nets ineffective officers, the general feeling can be "well, that’s the way the community works and we just have to deal with it." Don’t just deal with it. If your community governance is not working, change it so that it can work. Indoing this, it’s important not to single out and excoriate problematic members. A proposed modification to council nomination or election should not be “David Foo is doing a terrible job, so he should be banned from applying to the council in the future.” Instead, you should build a system that weeds out ineffective members quickly and averts their nomination in the first place. You can base the system on experiences with current bad council members, but think in general terms. Criteria for excluding and removing council members could include a required level of participation, audits of how well the council works, and an agreed manifesto listing what members will work on. Each of these initiatives can help your community judge whether a member is effective. Finally, institute a process to review whether members should still be on the council. Of course, you need to temper these considerations with moderation: you do not want council members to feel like Big Brother is constantly checking in on them. == Commercial sponsorship == Before we move on, I want to raise a sensitive consideration when it comes to the structure of your council: commercial investment and sponsorship. Many communities have commercial sponsors and investors. These sponsors often have a staff of developers and contributors who work within the community to make contributions that benefit the investor. Sometimes the community has a single sponsor, who perhaps founded the community in the first place. Examples of this situation include the major Linux distributions: Ubuntu was founded and is mostly funded by Canonical Ltd., Fedora by Red Hat, and OpenSuSE by Novell. With such significant investment in these communities, what impact should these investors have in the governance of the project? At what point is investment in a community considered a reasonable justification for governance? Let’s take a look at the impact of these sponsors on the governance of those projects: ''Ubuntu (sponsored by Canonical Ltd.):'' Of the seven places in the Ubuntu Community Council, only one seat is appointed—that of Canonical founder Mark Shuttleworth, who has tie-breaking power. The other six seats are open to anyone, Canonical or otherwise. ''Fedora (sponsored by Red Hat):'' The Fedora Board (their Community Council) has a Red Hat-appointed chairperson with tie-breaking power and nine seats. Of those nine seats, four are appointed to Red Hat staff and the other five are openly elected. This means that there must be at least half the board working at Red Hat, one of whom has a tie-breaking vote. ''OpenSuSE (sponsored by Novell):'' The OpenSuSE Board (their Community Council) has a chairperson who works for Novell and who has tie-breaking privileges. There are four other seats, two of which must be occupied by Novell staff. Although the numbers are different, the Fedora and OpenSuSE approaches produce essentially the same effect: a board in which 50% of the seats are reserved for the sponsor, one of whom is the chairman with a tie-breaking vote. This means that, conceivably, the sponsor could push through any issue they want: in OpenSuSE, the Novell staff could vote their majority, while in Fedora, there would be a deadlock of votes down the middle, allowing the chairman to cast the deciding vote. The Ubuntu approach is different: Mark Shuttleworth has the only reserved seat. Even with his tie-breaking privilege, it would be difficult to push something through unless it got to a deadlock, and Canonical has no way to engineer a deadlock internally, as all other seats are equally available to non-Canonical contributors. In fact, at the time of writing the majority of members on the Community Council don’t work for Canonical. I believe that for general volunteer communities such as open source projects, sponsorship and investment should never buy you a place in a governance body. I say this not because these commercial sponsors cannot be trusted, but because volunteer associative communities are often based upon the contributions of all members, and these members give of themselves in exchange for the assurance that their hard work will go toward their fellow members and the community’s future. Let us now apply some of this thinking to our Tobe example council. '''TOBE COMMUNITY COUNCIL STRUCTURE''' The Tobe Community Council (TCC) will have five membership seats, one of which is held by the founder of the project and has a tie-breaker privilege. Commercial sponsorship does not guarantee representation by employees of the sponsor on the council. == Membership == With a clear idea of your requirements and structure, the next step is to figure out what you are looking for in your council’s members. A council is nothing more than a collection of dependable people with a set of responsibilities. You need to depend on the members of your council to demonstrate maturity, competence, objectivity, and sensitivity. Good council members are there not just for their personal contributions and abilities, but because they can represent the needs of the community. After a keynote on governance at the SoCal Linux Expo in Los Angeles, a chap came over and asked the Ubuntu community manager what appeared to be a devilishly simple question: ''What kind of people should I look for to be on my community’s council?'' This got him thinking. Can we build a recipe for an excellent governing community member, and list the ingredients to look out for when choosing these members? Well, kind of. In my experience, community members come in many shapes and sizes. There is absolutely no commonality in terms of gender, race, career choice, technical experience, or age. You simply can’t look at someone in the street and determine that she is a great council member. As we discussed earlier in the book, these checkboxes of surface-level diversity items will not help you to build a great council. We instead need to look for deep-level attributes that point to maturity and capability in governance. Fortunately, there is a common set of traits that you should be looking for. It is these ingredients that will indicate that someone has the chops for governing your community: ''A listener:'' Great governors are always willing to listen. You will rely on your council members to listen to your community and make sensible decisions based upon hearing the full story. This is particularly important in cases of conflict resolution. A useful method of identifying this trait is to listen to a prospective council member in a normal conversation and make a mental note of just how much he listens as opposed to speaks. See how much he contributes to the discussion, see how often he chips in or interrupts, and see how much he queries the information he hears. This will help you determine whether he is a good listener. ''Unbiased and objective:'' Your council members need to ensure that they don’t demonstrate any apparent sense of bias. Of course, everyone is biased in one way or another, but you need to shoot for council members that can do their best to put their biases to one side. A good test of this is if a prospective council member is open to changing her views based upon further information. Another good sign is whether she is able to agree on a topic with someone whom she typically disagrees with. Watch her debate, and observe if she adjusts her argument as the debate progresses: this is a great attribute to have in a governing member. ''Detail-oriented:'' Great governors pay serious attention to detail. They understand that the devil is in the details, so they pick up on the hidden details in a discussion and ensure these details get covered. Watch how they communicate to see how they raise and react to details. ''Reliable:'' One of the most significant considerations with community-based governance is simply having people show up and fulfill their responsibilities on the council. If you have a governing body that has members who should attend meetings, don’t be surprised if some members don’t show up. You need to find people who are willing to put that PlayStation controller down, willing to get out of bed early if a meeting is scheduled to cater to another part of the world, and willing to make time for your community. Of course, life happens and people cannot always make meetings, but you can assess how reliable your prospective members are by seeing how often they attend your community over an extended period of time. Don’t assess them for the few months building up to nominations for the council, as they may try harder than normal to demonstrate reliability. Instead, observe them over a wider period of time without them knowing. This will help you get a more objective view on their reliability and attendance. ''A fair fighter:'' This is a rare trait. You really want to look out for people who will fight for the right thing, but put the integrity of the council and the community above the outcome of a fight. The ideal personality here is relaxed and calm, but when required, will put their head above water to do the right thing. The only way you can assess this is to look at their experience since they joined the community and balance the times they have stood up for different things, whether it was justified, and how they handled losing an argument. With these expectations in mind, you should properly document the expectations of council members so that prospective candidates have a clear idea of what is involved. Let’s apply this to our Tobe example. '''TOBE COMMUNITY COUNCIL MEMBERSHIP EXPECTATIONS''' Each seat on the Tobe Community Council (TCC) is for a period of two (2) years and has the following expectations: * Engagement—each member of the TCC is expected to engage with the community politely and fairly and to refrain from using bad language, offensive statements, or insulting comments. * Fairness—each member of the TCC is expected to consider each case brought to it; listen to all the evidence and perspectives from the people involved; and pass a fair, unbiased, and objective decision based upon the evidence provided, the goals of the Tobe project, and the best interests of the community. * Reliability—the TCC has a defined set of required meetings and responsibilities. Each member is expected to be responsive and receptive to these responsibilities. Each member is also expected to notify the TCC concerning any prolonged periods of absence. If a member of the TCC cannot fulfill his or her responsibilities, lacks the time to participate effectively, or otherwise cannot tend to the requirements of the TCC, he or she is expected to step down gracefully. It is also preferable but not required that the member who has stepped down help his or her replacement transition into the role easily. This rather juicy statement combined with the Responsibilities and Structure statements earlier provide a comprehensive set of expectations around the role of a governing member and its scope. Before we move on, I want to share a few thoughts about your own expectations. If this is your first time working to set up a governance body, it can often be difficult to figure out which people have the right requirements. If you are anything like I was when I first did this, you will be terrified that you have missed an important piece of fine print when documenting the council, and that you are going to unwittingly recruit a destructive idiot. First, don’t worry. This is your first time. Everyone makes mistakes, and you are going to as well. The best medicine for avoiding mistakes is experience, and I would highly recommend you find someone who has worked on governance before and ask that person to take a look at your work and pass comment. Take a quick look online at some of the existing governance bodies in communities that you follow, see who was involved in setting them up, and drop him an email to see whether he would be willing to offer some advice and thoughts. '''NOTE''' Of course, by saying this I know I am about to get deluged in email! I am certainly willing to help, but when the deluge occurs, I might not be able to help all of you, so don’t be offended if I don’t have time. In this section we have focused our efforts primarily on the attributes that we are looking for in our council members, but not how we actually elect them. We will discuss this a little later. === Communication === With a design in place that has firm responsibilities, structure, and membership expectations, we now need to decide how our council members will communicate with each other. Here we need to decide (a) which resources they will use to communicate, and (b) the requirements we make on their time for activities such as meetings. Let’s start with resources. You first need to ensure you have a primary communications channel in place. Earlier in this book we discussed some of the resources that are available, so we won’t cover that ground again, but let’s instead look at a suitable approach that many communities have used: a single mailing list and online chat channel. A mailing list is an excellent method of having general discussion inside the council. It is simple and low-bandwidth, and you can ensure that people’s access to it is restricted to their term on the council. Mailing lists are also useful for documenting discussion that may need to be revisited later. It's highly recommended to set up a mailing list, whatever your community. Before you rush out and do this, though, you need to make a few important decisions about its use: ''Focus:'' Mailing lists are excellent for general discussion. Although they can also be used for voting on an issue, I would instead recommend real-time discussion such as a phone call or IRC channel for that. Many communities have found that voting on mailing lists can take weeks to finalize. With real-time discussion, the voting is much quicker. ''Membership:'' Provide access to your mailing list only to members of the council. Make it clear that when they leave the council or their membership expires, their subscriptions to the mailing list will also expire. ''Privacy:'' Mailing list software packages provide the option to have public archives of the discussion. I strongly recommend that you have private, nonpublic archives. While this may surprise you, I recommend this because when public archives are available, your members will not be as blunt or honest in their feedback. When your council deals with a conflict issue or a membership request, you rely on honest opinions from your members about the individual(s) concerned. This can be tricky if the mailing list is public and a council member wants to share some critical views of that person with the rest of the members. If the list archives are private, you will get a better quality of feedback from your members. On the other hand, some organizations require open meetings by law. In this case, provide two mailing lists: a public one for most community issues and a private one for personnel issues, which includes the conflict and membership situations just mentioned. This is comparable to physical meetings where councils ask visitors to leave, and go into “executive session” for personnel issues. The problem with a mailing list (particularly one with limited membership and closed archives) is that it lacks the transparency and access that your community will rightfully expect. So I highly recommend that you augment your mailing list with regular real-time meetings, preferably using IRC or possibly even an open conference call on the phone. These meetings should be publicized as an opportunity for your community to raise topics with the council. The choice between IRC and the phone depends on the habits of your community members. From a pure features perspective, IRC is better: it is cheaper, easier to log, and accommodates more simultaneous participants than the phone. The problem with IRC is that only technical communities tend to know much about it. If your community has no idea what IRC is, getting them to use it is akin to trying to make a cat bark. As such, the phone could be a better bet. '''NOTE''' ''Of course, if your community is small and local, there is no reason that meetings can’t occur face-to-face in a local coffee shop or somewhere similar. Look at your community and make a decision based upon the norms of how it communicates.'' Whatever you decide, you should have regular meetings for your council. The purpose of these meetings is to provide an opportunity for your community to engage with the body that governs it. As such, you should make it explicitly clear to your council members that they should attend every meeting. A final note on communication is to make sure your community can add items to the council meeting agenda in a simple and organized way. Your community needs to feel that they can raise topics on the council. I recommend having a public agenda visible so that (a) people can add items to it, and (b) others can see what items are planned for discussion and join in if it interests them. A useful way of doing this is to set up a wiki and simply ask people to update the agenda page when they want to discuss a topic. Let’s now put a policy regarding communications in place for our Tobe Community Council. '''TOBE COMMUNITY COUNCIL COMMUNICATIONS''' The Tobe Community Council (TCC) has two primary resources for internal communication and interaction with the community: * tobe-community-council Mailing List—this mailing list, which is by invitation only, is available to all council members but to no one else. Council members are removed from the list when their role on the council ends. It can be used to raise any issue in private within the TCC. Discussions occur only within TCC members and are not archived or shared elsewhere. * #tobe-meeting—on the first Tuesday of every month at 18:00 UTC, the TCC has a public meeting that the full community is welcome to attend. The agenda, available at http://www.exampleproject.org/tobe/wiki/MeetingAgenda, will be discussed in each meeting. If you want to add an agenda item to the meeting, update that page and ensure you attend. All meetings are logged and available at http://www.exampleproject.org/tobe/meetinglogs. == Codifying Your Council == We are now rocking and a rolling with a good idea of how our council is going to look. Throughout our discussion we have documented our decisions for our Tobe example, and you should do the same for your own community. You can then gather these notes together and combine them all into the same document. This process is known as codifying the council. When you have this document together, make it publicly visible. You can then use it as a starting point to gather feedback from your community about the proposed council. Notify your community and provide a simple means of them providing feedback (such as updating a wiki page). This feedback provides an excellent opportunity to clarify any elements that are vague or incomplete in the document. It will also help you to engage with the community to ensure that the governance structure is really supported and reflective of the needs of the wider community. If you develop a Community Council plan in secret and in closed quarters, you will find it incredibly difficult to push it through, and rightfully so. This proposed governance body is a social contract about how your community is run, and the community must not only agree to it but also feel as comfortable about it as they do about that lovely old pair of snug shoes that we all have. To help illustrate council codification, I’ll present the codification document we used when forming the Ubuntu Forums Council. This was a council that was put in place in 2006 to help govern the hugely popular Ubuntu forums. Our codification document received extensive review and refinements, and when most people were happy with it, it was approved by the Ubuntu Community Council and put in place. Here it is. ''FORUMS COMMUNITY GOVERNANCE CODIFICATION'' The forums represent many people’s first meeting with Ubuntu and are an important resource for support and social interactions and have become one of the most important subprojects within Ubuntu. They are the single largest GNU/Linux support forums and one of the most important venues for community support and interaction. Started independently by Ryan Troy two years ago, their rapid success was officially recognized when they were designated as the Official Ubuntu Forums. This document aims to: * Increase recognition of contributions in the forums with membership, which is ultimately used to approve Community Council members. * Provide a clear delegation and codifications of the existing leadership in the forums and plan for handling these decisions in the future. * Describe clear democratic and meritocratic processes for the appointment of leadership and staff positions in the forums. * Remove several “single points of failure.” * Describe methods for both preventing and resolving any future inter-administrator or inter-staff conflicts within the forums. * Recognize the hard work of the forums staff through recognition as an integral and *integrated* part of the forums community. * Provide a straightforward process for top forums contributors to be recognized as full members in Ubuntu, with the right to vote on resolutions posed by the Community Council. * Provide for a reporting process so that news, ideas and work done in the project by Forums users will be communicated to the broader community and appropriately recognized. === Changes to Current Ubuntu Policy === The proposal includes both new policy and the codification of a few existing Ubuntu policies. These should be discussed with the Community Council and the forum staff. After it has been approved by the Community Council we will add it to the community governance page (http://www.ubuntu.com/community/processes/governance) in the Ubuntu website. Note that the document is structured to describe NOT JUST the Forums, but instead all the areas of the project which are large and independent enough to have their own dedicated leadership structures. === Team Councils === For active teams and subprojects with Ubuntu, the Ubuntu Community council delegates many of its responsibilities to “Team Councils.” These councils act as proxies for the Community Council over a particular team or scope of activity within the Ubuntu community. These governance councils are ultimately responsible for the actions and activity within their team or scope and resolves disputes and manage policies and procedures internal to their team and frequently appoint Ubuntu members on behalf of the Community Council. The Ubuntu Forums Council (FC) is the team governance council for the official Ubuntu forums. === Forums Council Charter === The Forums Council is the group that is ultimately responsible for the governing of the forums and interfacing between the forums and the rest of the Ubuntu community and governance systems. It will: * Consist of five (5) members. Membership should be public and published. * Decisions will be made by a majority of voting Forums Council members when at least three and more than half of the total members have voted. * FC members should be accessible by and responsive to the forums community (i.e., through a dedicated forum). * Hold “meetings” regularly and visibly. Meetings can either be in IRC in the “ubuntu-meeting” channel or in a special, publicly visible area or subforum. * Be appointed by the Ubuntu Community Council in consultation with the Forums Council, forums staff, and active contributors to the forums. Nominations would be open and public and would be considered and evaluated by the CC. Each candidate should prepare a wiki page summarizing their nomination and their contributions and including and referencing testimonials (e.g., something similar to what is prepared for Ubuntu membership). The CC commits to evaluating all nominations on the following criteria, listed in order of importance: — The nominees[’] (essential) active status as an Ubuntu member. — The nominees[’] support from at least one active forum staff member (essential). — Opinions and testimonials (positive and negative) from current members of the Forums Council; — Opinions and testimonials from current forums staff; — Opinions and testimonials from Ubuntu Members, Ubunteros, and other active participants in the forums; — Clear evidence of activity within the forums (quality, quantity and duration); * Serve terms of two (2) years. FC members could serve multiple or repeated terms. Weight will be given to proved contributors and reelection of consistently active members should be both easy and common. * Be formed, initially, of the current forums administrators (i.e., Ryan Troy [Ubuntu-Geek], John Dong [jdong], and Mike Braniff [KiwiNZ]). * Have a chairman with a casting vote, appointed by the Community Council, initially to be Ryan Troy. The FC would have a number of rights and responsibilities, and be ultimately responsible for the smooth operation of the forums. These include: * Appointing or recalling administrators, moderators and forums staff or determining criteria by which they are appointed. * Resolving disputes between forums staff and moderators as per the existing dispute resolution system and forums guidelines. * With advice, feedback, and help from the forums staff, maintaining and enforcing the Forums Guidelines and associated infrastructure (e.g., the resolution center). * Regularly and when possible (i.e., monthly), sending reports or representatives to CC members to weigh in on issues of membership and to update the council on the FC business. === Staff and Ubuntu Membership === Forums staff will be appointed by the Forums Council. Forums staff are expected to uphold and set an example that is consistent with the Code of Conduct. Forums staff and participants have the option to become Ubuntu members. Current staff can apply for membership at an Ubuntu CC meeting. Their contributions as staff members and contributors on the forums should provide more than sufficient evidence of a sustained and significant contribution to the Ubuntu community. === Dispute Resolution === The FC will be responsible for maintaining forum guidelines and systems for internal conflict resolution (e.g., the forums resolution center). Additionally, there should provide a documented method whereby any disagreements or conflicts between moderators can request a hearing by the FC. In extreme situations, users and moderators who feel that they have not been given a fair hearing by the FC can appeal a decision to the CC. The CC considers the FC to be a greater authority on forums matters and in the majority of these cases, the CC will likely refer these issues back to the FC. Any deadlock within the FC will can be referred to the Community Council for resolution. The Ubuntu Forums Council has been hugely successful, and the expectations around its governance have never been questioned. The document helped keep everyone on the same page. == Nominating and Electing Council Members == With a firm foundation of how your Community Council will work and one that has been publicly documented and approved by the community, the next step is to populate the council with members. Earlier we discussed the attributes that we are looking for in members (a listener, unbiased, objective, responsive, attentive to detail, etc.), but now let’s talk about how we can find and motivate these people. === Forming a new council === When forming a new council, especially the first council in your community, you typically need to grandfather people in. In other words, the first set of members who govern the council are a handpicked group who you are confident will get the council up and running under the agreement you just codified. Everyone in your community needs to feel that they have the opportunity to be on the council, but you also want to ensure that you maintain a high level of quality for your council members. A common solution to this problem is to have an election in which your community can vote for those who govern them. Unfortunately, the big misconception in community elections is that elections alone will sort the wheat from the chaff. In other words, many believe that if you have an open election, the community will settle on the highest quality candidates for the council. This is often not the case. Popularity contests do not form great governance bodies. Someone without the maturity and vision you need may have a lot of friends and influence and snag a place on the council. On the other hand, there may be a quiet and conscientious community member who is perfect for a position in the council but never gets noticed. In fact, the most qualified community members hardly ever put themselves forward for a governing council, because they are too wrapped up doing their work for the community. Fortunately, governments found long ago an effective compromise between pure representative elections and top-down selection: a nomination process. Pull together the members you know well, who you feel are the current de facto leaders of the community, and hold a meeting to nominate the appropriate people for a position on the council. The people who can participate in this discussion could be a founder, highly visible contributors, an existing council, or others with experience and insight into the community that you trust. This group should nominate a good range of people, and preferably more people than you have places for on the council. As an example, if you have five seats on the council, try to come up with seven or eight nominations. Each of these people should be an excellent candidate who satisfies the criteria we discussed earlier. Of course, you should always ensure that before potential members are publicly nominated, you contact them first to ensure they actually want to be on the council. Many people want to have nothing to do with governance. As you talk up your goals, some will come around to realize that serving on the council complements their current ways of contributing and flexes their talents, but others really have no stomach for meetings or rule-making, and should not be browbeaten into serving. Assume that you’ll be rejected the first time you approach each potential candidate. It’s almost a given. After all: * Most people are naturally modest and do not want to claim an honor. Even heroes who rescue people from burning buildings always give speeches afterward saying, “I’m not a hero.” * The people you want are busy and happy contributing to the community. They’re afraid that joining the council will take time away from their regular contributions (and they’re usually right), and they’re also afraid that governance is relatively dull. * Most people have never served on a board or council and don’t know what it entails. They assume they don’t have the competence to do so. * All kinds of cruft around the image most people have of governments and leaders get in the way of their seeing the good things councils can do. Anticipate all these reactions. They are legitimate, but you have counterarguments to offer. Try to meet in person with a candidate to listen to her views and have a candid exchange. If a face-to-face meeting is not possible, try to use a voice call. The general points you can make are: * Your community has reached a point where the lack of governance (or in the case where a council is creating subcouncils, the relative lack of attention to one area) is preventing the members from doing what they want. The potential candidate is furthering her personal goals as well as the goals of the community by taking on the new tasks of governance. * Power is not a bad thing. Whatever goals the contributor has, she can push them forward on a much greater scale by representing her needs on the council and making sure the community provides the resources for these tasks. * Nobody is putting on a jacket with medals and ribbons; serving on a council is not equivalent to becoming a Generalissimo. Other members of the community will still view the council members as ordinary folks whom they can complain to and have a beer with. * Some of the greatest life lessons come from serving on governing bodies. Everyone who does it says afterward that they’ve learned an immense amount about people; organizations; and the essential ways that the wheels of life turn in terms of timing, finance, and so forth. * A council term is limited, and before they know it, they will be back in the rank and file doing the work they originally loved—but this time with a far deeper understanding of this work and how to make it successful. * Everybody feels the same way at first. The very qualities that make them feel inadequate are precisely the ones that will make them good council members. Most candidates, once you sincerely hear their viewpoints and offer your own, will come around and agree to serve. But as I mentioned, some are truly ill-suited to council work. If they remain convinced that they’ll be bored, frustrated, or unproductive on your council, don’t pressure them—just express appreciation for the work they’re already doing. You can probably find a team handling some task that they’d like to work on, and over time they may work themselves through the community structure into a governance position. Next, ask candidates to produce pages that act as a platform for their candidacy. This page should essentially persuade anyone reading it that they are perfect for the role. To make this as simple as possible, you should provide them with a template that they can fill out with their information. Here is a suggested template: Candidacy Document for <
> Date: <
> INTRODUCTION<
> > they can bring to the council> <
> COMMUNITY EXPERIENCE<
> Item of experience.<
> Item of experience.<
> TESTIMONIALS<
> <
> <
> GOALS <
> <
> Each of these candidacy templates should be made available online in the same place so that your community members can review it. A wiki is a great solution. You can then open up a vote. How you conduct this vote depends largely on how your community is structured. As an example, if you have the concept of membership, such as approved members or approved developers, it is recommended to allow only those approved contributors to vote. This will give all legitimate members of the community a voice, while ensuring that the decision is made by those who actually know the community well enough to offer an informed opinion. If your community is more loosely formed and just consists of anyone who joins a forum or mailing list, it is more suitable to nominate members from core contributors in the community. ---- [[CategoryBuildingCommunity]]