- Chapter 7. The Ubuntu Community
- Teams, Processes, and Community Governance
- Getting Involved
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Teams, Processes, and Community Governance
Ubuntu operates under the famous hacker mantra of “rough consensus and running code.” The project attempts to forge consensus, to make good technical decisions, and to move forward. It attempts to minimize politicization wherever possible and to distribute power to those who are best at getting good work done. Mark Shuttleworth explains, “This is not a democracy, it’s a meritocracy. We try to operate more on consensus than on votes, seeking agreement from the people who will have to do the work.”
The project attempts to keep disagreements from spiraling out of control by enforcing mutual respect at all times with its Code of Conduct described in Chapter 1. Disagreements, of course, are inevitable and can be technical or nontechnical in nature. The community needs to be able to deal with these and, toward that end, has created a lightweight governance system that aims to ensure that disagreements are resolved carefully and that the project always has a strong, fair, and responsive direction.
The Ubuntu Web site describes the goals of its community governance system as threefold.
- Ensure that a process is defined that allows people to contribute to decisions regarding the Ubuntu community and distribution.
- Ensure that decisions regarding the Ubuntu distribution and community are made in a fair and transparent fashion.
- Ensure that necessary decisions are actually made, even when there is no clear consensus amongst the community.
With these goals in mind, Ubuntu’s system is based on the delegation of decision-making power to small and medium-sized teams. When disagreements arise, they are handled within a relevant team. In the cases of some larger teams, team councils handle a variety of dispute resolutions in a very structured fashion. When teams cannot resolve their own disagreements or when there are disagreements between teams, issues are forwarded to either the Community Council or the Technical Board—depending on whether the issue is technical in nature. As the financier and the project’s progenitor, Shuttleworth sits on both boards and occupies a special position as the self-appointed benevolent dictator for life (SABDFL). Users can participate in the Ubuntu governance structure by serving on teams and by approving members of both the Community Council and the Technical Board as Ubuntu members and maintainers.
Teams
Most work in Ubuntu is delegated to a set of teams, each responsible for a particular area of work in Ubuntu. A sample of important teams (which is by no means complete) might include the forums, marketing, art, documentation, kernel, server, laptop, and translation teams. Anyone with an interest in a particular aspect of the Ubuntu project can join a team’s discussion and contribute to its decisions.
When participants feel that a particular area is underserved, they can go ahead and build a new team by beginning work and writing up a proposal for consideration by the Community Council, which approves the creation of all new teams. Rather than catalyzing work with the creation of a team, the Community Council likes to recognize existing work with official team status. Teams should always involve the participation of several individuals. There are no one-man or one-woman teams in Ubuntu.
Several teams are so large and important that they have built their own more advanced governance structures in the forums of team councils. These councils are appointed by the community council from active members and leaders within the team and act as delegates of the Community Council for that team and its domain in the project. These team councils have regular meetings, resolve conflicts, report to the Community Council, and in some cases even grant membership on behalf of the Community Council. Current large teams with councils include the forums, Edubuntu, Kubuntu, and MOTU teams.
Local Community Teams
Local community teams, affectionately referred to as LoCos in the community, are an extremely important type of team. Each LoCo is responsible for promoting, supporting, and representing Ubuntu in a particular locale. These locales are usually geographical and frequently countrywide, although in some situations they may overlap geographically. Ubuntu tries to encourage LoCos to work together whenever possible.
LoCos are like Linux User Groups (LUGs) and may often work closely with or be associated with a LUG. LoCos are often involved in localization or translations of Ubuntu into local languages and in advocacy in local schools, public administrations, and communities. The best LoCos meet regularly for social events, talks, and discussion. Often, they meet for installfests, where team members help new users install Ubuntu onto their computers. Representatives of LoCos are asked to assist with localization matters, to speak on behalf of the Ubuntu project at local conferences and trade shows, and to organize a booth or presence at such events.
Canonical, Ltd. provides each team with a mailing list and a domain name (usually in the form of ubuntu-<CC>.org, where CC is the country’s two-letter country code). Canonical also is willing to host LoCo Web pages, wikis, forums, blogs, download areas, and additional mailing lists. LoCos are open to participation by anyone.
MOTUs
Another very special team that deserves an in-depth description in this book is the MOTUs. The MOTUs are the maintainers of Ubuntu’s universe repository, and the acronym stands, jokingly (if not slightly embarrassingly), for Masters of the Universe. MOTUs call themselves “the brave souls who try to keep the universe section of Ubuntu in shape.”
MOTUs are package maintainers. They maintain, as a group, the vast majority of packages in the Ubuntu archive. Several of the packages that have been well maintained by the MOTUs have, with time, migrated into the main component and become an official part of the Ubuntu distribution. Because Ubuntu does not make support or quality promises regarding the packages in universe, the MOTU team provides a way for maintainers to sharpen their teeth and (since it’s sometimes unavoidable) make mistakes before jumping into the higher-responsibility packages in main.
The roles and responsibility of the MOTUs are many. Two important ones are these:
- Filing and fixing bugs on Ubuntu packages using Malone
- Getting new or updated packages included in Ubuntu’s universe
This work is done largely by full-fledged MOTU members, who, as team members, can upload directly into Ubuntu. This group is helped by MOTU hopefuls, who work closely with the MOTUs and whose work is then sponsored into Ubuntu. Many of these hopefuls graduate to full-fledged MOTUs, and many MOTUs eventually are granted full-core developer status. This three-step system is the process by which almost all new maintainers learn to maintain packages in Ubuntu and gain their stripes.
The Community Council
The Community Council and the Technical Board are the highest-level governance structures within Ubuntu. The Community Council, as it pertains to all Ubuntu members and activities, is arguably the most powerful team within the Ubuntu project. The Community Council is charged with supervising the social structures, venues, and processes of the project.
The Community Council’s day-to-day work involves five major areas in Ubuntu. The first, and the most straightforward, is the maintenance of the Ubuntu Code of Conduct. The Community Council is the only body that can approve revisions to the code. Because the Community Council does not ask each member to “reagree” to the code when it is changed, each of these revisions must be fully within the spirit of the previous drafts.
The second charge of the Community Council is the arbitration of disputes that cannot be handled within a particular team or that arise between teams. Very frequently, these are disputes about the Code of Conduct that may require clarification of a part of the Code of Conduct or a description of whether any of the code was in fact violated by a particular action or behavior. However, the Community Council’s purview is not limited to Code of Conduct violations, and the Community Council is available to handle disputes in any nontechnical situation. In most situations, the Community Council does not take action against individuals but, rather, helps group members come to agreement or consensus among themselves. If this fails, the Community Council can ask a maintainer or other member of the community to apologize and refrain from particular behavior or to leave the community. The Council promises that nobody will be asked to leave without a substantial review and an opportunity to defend him- or herself.
A third area of council work is the creation and dissolution of teams and the appointment of team leaders. New teams are proposed to the Community Council in the manner described earlier in the section on teams, and the Community Council either approves the request or asks the proposer to wait. Defunct or inactive teams can similarly be dissolved by the Community Council. In cases where team leadership is requested, the Community Council can appoint leaders of teams or shift leadership to different team members. In most situations, the appointment of team leaders is an internal team matter but, when requested, the Community Council is available to intervene.
Fourth, the Community Council is responsible for approving and welcoming new members to the project. This will be described in more depth in the upcoming subsection on membership.
Finally, the Community Council is responsible for all community-related structures and processes. New types of teams, requirements for membership, and core philosophical documents should first be approved by the Community Council. Community members who wish to suggest new structures or processes can submit their proposal to the Community Council for discussion and approval.
The Community Council meets every two weeks on IRC. Any community participant can submit an item or proposal for discussion by the Community Council. Meetings are open to the community, but the Council seeks only consensus or votes from Council members—although it consults representatives from the team that submitted the proposal and other community members. If an open meeting becomes too noisy, the Council reserves the right to move to a private channel for the duration of the meeting. To date, this has never happened. In all situations, full transcripts of meetings are published immediately following a Community Council meeting. The Community Council at the time of this writing consists of Benjamin Mako Hill, Mark Shuttleworth, James Troup, Daniel Holbach, Corey Burger, Matthew East, and Mike Basinger. Notably, only Shuttleworth and Troup are Canonical employees. Appointments to the board are made by Shuttleworth and subject to confirmation by a vote among all members. Appointments are for a period of two years.
The Technical Board
The Ubuntu Technical Board is responsible for the Ubuntu project’s technical direction. By handling all technical matters, the Technical Board complements the Community Council as Ubuntu’s highest rung of project governance. In particular, the Technical Board is responsible for three major areas of Ubuntu policy: package policy, release feature goals, and package selection. Also, the Technical Board is available to arbitrate any technical disagreements or issues within or between teams in a manner similar to the one described earlier in relation to the Community Council.
The Technical Board’s first responsibility is Ubuntu’s package policy. The Technical Board maintains the policy document, which describes the processes and standards to which all Ubuntu packages are held. Since the policy is constantly evolving, each Ubuntu release is associated with a specific version of the Ubuntu package policy as determined by the Technical Board. Any suggestions or proposals about policy are suggested to and considered by the Technical Board.
Also, the Technical Board is responsible for maintaining Ubuntu’s feature goals for each release. During each release cycle, there is a date defined as Feature Freeze, after which no new features are added. The Technical Board sets these dates and decides when and if the rules can be bent for a particular feature or piece of software.
Finally, the Technical Board is responsible for maintaining the list of pieces of software (i.e., packages) in Ubuntu. In this capacity, the Technical Board determines which software is installed in the default desktop installation and which packages qualify for full support as part of the main component of Ubuntu. Users and developers can propose a particular piece of software for inclusion in main, the base install, or a desktop install. In all cases, the ultimate decision will be made by the Technical Board.
Like the Community Council, the Technical Board meets at least every two weeks on IRC. Also like the Community Council, any user can submit an item or proposal for discussion by the Technical Board ahead of the meeting. Meetings are open to all interested parties, although decision making and voting is restricted to Technical Board members. Full transcripts and rules about noise, as they pertain to the Community Council, also apply to the Technical Board. The Technical Board at the time of this writing comprises Matt Zimmerman as board chair, Scott James Remnant, and Mark Shuttleworth. Nominations for the Technical Board are considered at the beginning of each release cycle. Like the Community Council, appointments are made by Shuttleworth but are subject to confirmation by a vote among the maintainers instead of all members. Appointments are made for a period of one year.
The SABDFL
Mark Shuttleworth jokingly refers to himself as Ubuntu’s SABDFL—self-appointed benevolent dictator for life. He plays an admittedly undemocratic role as the sponsor of the Ubuntu project and the sole owner of Canonical, Ltd. Shuttleworth has the ability, with regard to Canonical, Ltd. employees, to ask people to work on specific projects, feature goals, and bugs. He does exactly this.
Shuttleworth also maintains a tie-breaking vote on the Technical Board and Community Council but has never used this power and has publicly said that he will not use it lightly. In situations where the boards are split and there is no one “right” answer, the SABDFL will provide a decision instead of more debate. The SABDFL exists to provide clear leadership on difficult issues and to set the pace and direction for the project. In exchange for this power, he has the responsibility to listen to the community and to understand that the use of his SABDFL authority can weaken the project.
Ubunteros and Ubuntu Members
Membership in the Ubuntu project is one official way that the project recognizes sustained and significant contributions. The first level of membership in Ubuntu is as an Ubuntero (formerly, the name was Ubuntite). Ubunteros are Ubuntu activists and can be any person in the Ubuntu community who has explicitly committed to observing the Ubuntu Code of Conduct. Ubunteros are self-nominated and self-confirmed. Using Launchpad, participants can generate a GPG encryption key and “sign” the Code of Conduct as a way of pledging to uphold it within the Ubuntu community. By doing so, that participant automatically gains status as an Ubuntero.
The next, more significant, step is official membership. Official membership is available to any Ubuntero who has demonstrated a significant and sustained set of contributions to the Ubuntu community. These contributions can be of any kind—technical or nontechnical—but need to be of a form that can be represented to the Community Council, which will consider each application individually. A list of types of contributions that qualify appears in the following section on getting involved. The Community Council tries to be flexible in the variety of different types of contributions that it accepts in consideration of membership.
Members are responsible for confirming, by voting, all nominations to the Ubuntu Community Council. They also may be asked by the Community Council to vote on resolutions put to the general membership. In exchange, members gain the right to an @ubuntu.com e-mail address and the right to carry Ubuntu business cards. Membership lasts for two years and is renewable. Members who fail to renew their membership will be marked as inactive but, with renewed activity and a simple procedure that involves approval of the Community Council, can be easily reactivated.
The process to become a member is relatively straightforward and is documented in depth on the Ubuntu Web site. Most important, it requires that users document their contributions on a wiki page that includes links to code, mailing list messages, documentation, or other relevant material. Membership applications should also include testimonials on work and involvement in Ubuntu from current Ubuntu members.