Chapter 11. The Ubuntu Community

Community is a word often used in discussions of Ubuntu. Early articles about Ubuntu bore subtitles asking, “Would you like some community with that?” The earliest press releases and communiqués from the project emphasized a “community-driven approach” to operating system development and distribution. In fact, the highest-level governance board in Ubuntu is called the Community Council and Canonical, Ltd. and employs a full-time community team. It is to that end that we have made a very conscious decision to spend an entire chapter of this book describing the Ubuntu community. In fact, every edition has been dedicated to the Ubuntu community!

Still, while the Ubuntu community is important, it is not always easy to succinctly describe it. Ubuntu is, in large part, developed and funded by Canonical. The community, almost by definition, extends far beyond Canonical. The Ubuntu project has Members and self-declared activists, but the Ubuntu community is more than even those with such explicitly declared relationships. The project contains a wide variety of venues for participation. But while the community is active in each of these areas, its scope is even wider.

The Ubuntu community is the collection of individuals who build, promote, distribute, support, document, translate, and advocate Ubuntu—in myriad ways and in myriad venues. Most people in the Ubuntu community have never met, talked with, or heard of each other. Members of the community are linked by their contributions, both technical and nontechnical, and by Ubuntu itself. These contributions have built Ubuntu as a distribution, as a social movement, as a set of support infrastructures, and as a project. In short, they have built Ubuntu as a community. While any active software development project has a number of people making contributions, not every project has a community.

Community is also a term that represents a promise by the Ubuntu project to remain inclusive. The focus on community means that volunteers are not only welcome but also essential. It means that Ubuntu is a “place” where individuals can come together to create something greater than the sum of its parts. The word community gives a nod to the fact that while much development work is paid for by Canonical, and while some people contribute more hours, more effort, more code, more translations, more documentation, or more advocacy work to Ubuntu than others, no individual or subgroup can take credit for everything that Ubuntu has become. In Ubuntu, no contribution is expendable. Having a community also reflects Ubuntu’s goal to provide a low barrier for entry for these contributions. Anyone who cares about Ubuntu can contribute to the project and can, in whatever ways are most appropriate, become a participant in the Ubuntu community.

This chapter provides a bird’s-eye view of the venues and processes in which the Ubuntu community is active. First, it takes a tour through the venues through which the Ubuntu community both consumes and communicates information. It continues by looking at the way the community is organized and the processes by which that organization works. Finally, it walks you through the ways you can participate in the Ubuntu community and contribute to its success.

Of course, this activity is public only to those who know where to find it. This section tries to document the venues for communication in Ubuntu as completely as possible. It describes the places where discussions of development, support, and advocacy take place. While nobody can engage in communication in all of the venues described, knowledge of what exists allows participants to be more informed when they need to choose the right place to ask a question or to make a suggestion.

An overview of community structure is also provided on this Web site, explaining the governance structure and the councils and boards. Finally, the site provides an overview of the support and documentation options for users of Ubuntu.

An up-to-date, full page of mailing lists for Ubuntu can be found at https://lists.ubuntu.com, where users can see a list of available mailing lists, view archived discussions, and subscribe to lists through a Web interface.

Lists are one of the oldest forms of communication by e-mail. A mailing list provides a single e-mail address that, when mailed to, will then relay the received message to a large number of people. In Ubuntu, lists are topical, and individuals can subscribe to a mailing list if they want to receive information on the list’s topic. All mailing lists at Ubuntu are hosted at http://lists.ubuntu.com.

With a few exceptions (e.g., the e-mail list for the Community Council), anybody can subscribe to any Ubuntu list. In most cases, the capability to send e-mail to lists is restricted to list members (membership in lists is, of course, open to anyone). This means that all e-mail sent to a list from someone who is not a member of that list is put into a queue to be reviewed by a human moderator before it is broadcast to list members. This is done as an antispam measure. Users can subscribe to lists and then configure the system to never send e-mail. For several e-mail lists, all messages are moderated. This is largely to ensure that lists remain “low volume” or “announcement only.”

Ubuntu’s mailing lists are run by the popular Mailman software, which may be familiar to some users. Mailman makes it simple to subscribe to lists, to unsubscribe, and to configure any number of options about mail delivery. One popular option is to receive a daily digest of messages rather than a separate e-mail each time a new message is sent. This is all available through a Web interface at https://lists.ubuntu.com. Users can also subscribe to lists by sending an e-mail with “subscribe” in the subject line to <mailing list name>-[email protected].

While each list plays an important role in the Ubuntu community, the following central lists warrant a little more detail. You might find it a good idea to subscribe to them.

ubuntu-announce This fully moderated list relays all important announcements for the Ubuntu project and usually contains less than one e-mail per week. It is the place where new releases are announced and where other important information can be found first. If you use Ubuntu, you may want to consider subscribing to this list. If you subscribe to only one list, this should be it.

community-announce This fully moderated list provides announcements that the general community may find valuable. Announcements may include details about when the next Ubuntu Developer Summit is being held and how to get involved or details of upcoming community elections, like that of the Ubuntu Community Council. No technical expertise is required to read this list, and it’s recommended you subscribe to keep track of events in the community.

ubuntu-devel-announce This fully moderated list contains announcements related to the development of Ubuntu. It is low volume and contains one to three e-mails per week. If you work with code in Ubuntu, use a development release, or contribute on any technical level, you should be on this list. This is the list that everyone involved in development for Ubuntu is expected to read.

ubuntu-devel-discuss This list is the primary open list for general-purpose discussion of Ubuntu development. If you are looking to contribute to Ubuntu in any technical way, you should subscribe to this list and begin to follow the discussion. The list has a relatively high volume of e-mails.

ubuntu-devel This list is a moderated list for discussion of Ubuntu. While subscribing remains free, posting to the list is restricted to those who are Ubuntu developers or to chosen other developers. Others may post, but all posts are checked by a moderation team.

Like mailing lists, IRC channels provide a venue for many different types of communication in many different subcommunities in Ubuntu. There are many different channels, including channels in a variety of languages.

All official Ubuntu IRC channels are located on the freenode IRC network, which also hosts a range of other free and open source software projects. Users can connect to IRC using several pieces of software in Ubuntu, including Empathy, Hexchat (successor to XChat; Figure 11-1), Irssi, and a freenode webchat client is available for users who aren’t using a local application on their machine for IRC but would like to join the channels from time to time (Figure 11-2). Mailing lists such as [email protected] will assist users in finding the right help and support; #ubuntu is designed for help and support. When joining any channel, users should carefully read the topic, as many frequently asked questions are answered there, and moderators of the channel can be annoyed by users who ask questions the moderators have already taken the time to answer in the channel’s topic.

Currently, the #ubuntu channel is usually the biggest channel on the freenode network, with more than 1,500 simultaneous users at most times, and it’s continuing to grow—especially around releases. Another important channel is #ubuntu-devel, which is reserved for discussion of Ubuntu development. Support for development releases has moved to #ubuntu+1. Maintaining channels with specific purposes has allowed the support community to stay focused and help as many people as possible. A full list of channels can be found at https://wiki.ubuntu.com/IRC/ChannelList.

The forums are accessible online at http://ubuntuforums.org and have shown an impressive amount of usage. The forums boast more than 2 million registered users, with approximately 5,000 online at any given moment. The topics discussed in the forums run the gamut in categories like these:

Support discussions, including spaces for questions about specific hardware (e.g., computers with Ubuntu preinstalled, or networking and multimedia cards) and specific use cases (e.g., desktop or server users)

Ubuntu community discussions, including spaces for discussions by people working on art for Ubuntu, those working in science and education, and those developing new documentation and tutorials

Forum-specific community discussion spaces, including several social spaces and places for administrative and community governance discussions

By covering such ground, the Ubuntu forums provide an impressive support resource. They offer an excellent venue for both asking questions and answering questions, and both receiving support and making important contributions to the Ubuntu community. If you are interested in any of these, the forums are a good place to begin.

The only caveat regarding the forums worth mentioning is that they are not frequently used by those developing Ubuntu—although there are exceptions to that rule. If users want to get involved in technical contributions to the project, they will, in all likelihood, have to augment their forums’ patronage with the use of mailing lists or Launchpad.

The forums were founded by and are moderated and maintained entirely by volunteers, and are governed by the Forums Council (discussed later in this chapter).

There are several Ubuntu wikis, but two are central to the community. The first is the Community Help wiki at https://help.ubuntu.com/community (Figure 11-3). It is edited and directed by the Ubuntu Documentation Team and focuses on issues of community-produced technical documentation for Ubuntu. The second wiki is at https://wiki.ubuntu.com and is meant to be used for everything else. The Community Help wiki can be thought of as a project to build an expansive manual through community contributions and editing. The general-purpose wiki is used for specification writing and traffic, conference organization, meet-ups, pages for teams and individuals involved in Ubuntu, and absolutely anything else that is in written form and relevant to the Ubuntu community. Both wikis can be edited, added to, or reorganized by anyone in the community who creates an account, and edits are unrestricted. Since registration is required, each change can be traced to a particular user.

Unlike other documentation that ships with Ubuntu, anyone can fix an error, inaccuracy, or out-of-date fact in the wiki. As a result, there is no good way to determine whether information in the wiki is correct. It cannot be subjected to the same type of quality assurance workflow that a document such as this book might be. However, it is also much more likely to be up-to-date in the quickly changing world of Ubuntu development, where there is a new release every six months. The wiki provides a venue for this level of up-to-date information with a low barrier to entry and, as a result, acts as an invaluable resource for the community.

The Fridge is perhaps best described as the community portal for Ubuntu. It is part news site, part grassroots marketing and advocacy site. It hosts news, interviews, calendars with lists of upcoming events, polls, and much more. The core content on the site is arranged as a Weblog. Users frequently set The Fridge as their home page or subscribe to the site via its RSS feed. The Fridge is unique in the community in that it appeals to a wide variety of Ubuntu participants—developers, advocates, translators, users—and provides a venue where each group can share information with others. There is a story every two to three days on The Fridge. Users can comment and discuss each story in the comments section on The Fridge.

Anyone can contribute content to The Fridge. If you would like to contribute, you can do so by sending your suggestions for features, articles, or even a piece of original work (such as an article, photo, or event review) to [email protected] or by following any of the suggested ways on the https://wiki.ubuntu.com/Fridge/Submit.

The site concentrates on answers that are voted on by the community and peer reviewed by other members of the site, which can keep the information up-to-date and topical.

The Ask Ubuntu Web site features the ability for users to ask and answer questions, and, through membership and active participation, to vote questions and answers up or down and edit questions and answers in a wiki fashion. Users of Stack Overflow can earn reputation points and “badges”; for example, a person is awarded 10 reputation points for receiving an “up” vote on an answer given to a question, and can receive badges for their valued contributions. All user-generated content is licensed under a Creative Commons license.

From here users will have access to answer or ask questions as well as search and view all the questions that have already been asked. Users do not have to register or log in to have access to the site. For those users who wish to register, there are several ways this can be accomplished. If you have an account on Google, Yahoo!, myOpenID, Facebook, your Ubuntu account, AOL, or OpenID, you can associate that account to your AskUbuntu account and sign in using any of those accounts.

Facebook: http://facebook.com/ubuntulinux

Twitter: http://twitter.com/ubuntu

Google+: https://google.com/+Ubuntu

The Mataró Sessions in Mataró, Catalonia, Spain, in December 2004—the first Ubuntu development summit

The two named Ubuntu conferences in 2005: Ubuntu Down Under in Sydney, Australia, in April and the Ubuntu Below Zero in Montreal, Canada, in November

Ubuntu Developer Summit Mountain View at Google Headquarters in Mountain View, California, in November 2006

Ubuntu Developer Summit-R in Copenhagen, Denmark, in October 2012

As the community has grown, it has become increasingly difficult for Ubuntu Developer Summit (UDS) events to accommodate everyone who wants to attend in person. In 2013, the Ubuntu Developer Summits moved to being online-only events that are held over video chat. These new events are called Ubuntu Online Summits (UOS).

With the support of Canonical, Ubuntu tries to organize the Ubuntu Online Summits so that they occur twice per release. Usually the first occurs toward the very beginning of a release cycle, so that the specifications and goals for the forthcoming release can be discussed, thrashed out, and decided upon. A second UOS then takes place mid-cycle so that tasks can be formally reviewed and plans adjusted prior to release as needed. While the format changes slightly each time, these meetings have been between three days and two weeks in length.

At UOS, attendees describe features that they would like to see in the next Ubuntu release. At an arranged time or in a series of meetings, a small set of interested community contributors and developers work to draft a written specification. This process of drafting involves brainstorming and ends up with a formal, approved spec that describes a problem or need and provides a detailed description of how it will be fixed or implemented. While these specifications are often technical in nature, they are also used to describe goals that may pertain to localization, documentation, or community building. For example, both The Fridge and the planning of each summit began as a specification. With time, these specifications are categorized in terms of priority for the upcoming release. Later, individuals will claim or be assigned some set of these specs. Each specification is written up and improved as a blueprint on Launchpad so that Ubuntu developers and contributors who cannot attend the summit are still able to participate.

These summits also address issues within the community. For example, many of the Ubuntu leaders participate to discuss how they could help grow not only their own leadership abilities but those of the Ubuntu community as well.

In addition to these summits, Canonical organizes a number of in-person, invitation-only sprints each year. These sprints tend to be one- to three- week intense collocated work sessions that involve a team or subteam tasked with a well-defined goal. They provide a time when team members can write code, write documentation, make plans, or do whatever else is necessary to fulfill that goal. The sprints tend to involve fewer than 100 people, and their attempts to squeeze large amounts of work into a short period of time have earned them a reputation for being exhausting, fulfilling, amazingly productive, fun experiences. These sprints are work sessions and are usually limited to a group of Canonical employees; however, on occasion, they may also include volunteer attendees.

While many local community teams have regular meetings and their own Ubuntu events, several larger-scale UbuCons have been held to date, and several more are currently being planned. The first two UbuCons took place at Google headquarters, in Mountain View and in New York City, and others are designed to coincide with the much larger Linux World conferences that many other Ubuntu users attend. Attended by a group of a few hundred users and a handful of developers, UbuCons have provided a simple way for users to connect with one another. Additionally, some UbuCons have provided space for “installfests” where users can bring computers and have Ubuntu installed on their machines by other Ubuntu users, developers, and aficionados.

Any active group of Ubuntu users can plan a UbuCon, and UbuCons have taken place in a variety of locations around the world. For example, UbuCons now take place in conjunction with such events as the Southern California Linux Expo, Ohio Linux Fest, Southeast Linux Fest, and others. This piggybacking onto the larger events worked so well that in 2010, several other organizations permitted a UbuCon to be organized as a smaller part of their larger event, and the practice is expected to continue in the future. When these UbuCons are collocated with conferences, they are well attended because Ubuntu users are already attending the larger events. Local Community teams (LoCos, covered later in this chapter) can afford to organize these UbuCons because the venue costs are quite low and can usually be covered by only one sponsor. Such gatherings are free events, and popular Ubuntu speakers often are already attending the larger event and are willing and happy to add some participation in the UbuCon to their schedule.

With the move to online-only summits, community-organized UbuCons became even more popular. In 2016, the first UbuCon Summit was held in Pasadena, California. A collaboration between a LoCo and Canonical, the UbuCon Summit grew out of an existing UbuCon that had been hosted by the California LoCo in the past. The UbuCon Summit featured a user track and a developer track on the first day, and an unconference for developers and other Ubuntu contributors on the second day. This was the first summit-type event to have strong funding, planning, and collaboration between Canonical and the community, and also featured external sponsors, including GitHub, Dell, and Hewlett-Packard Enterprise.

While conferences and summits act as a site for major technical advances in brainstorming and development, they are also fun and enjoyable experiences. They provide a venue for users to put faces to names, IRC nicknames, and e-mail addresses, and they provide for enjoyable, humorous, and productive interaction.

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.

1. Ensure that a process is defined that allows people to contribute to decisions regarding the Ubuntu community and distribution.

2. Ensure that decisions regarding the Ubuntu distribution and community are made in a fair and transparent fashion.

3. Ensure that necessary decisions are actually made, even when there is no clear consensus among 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 the council or board governing that area of the community and at times can and may be escalated 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 the Community Council 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 as Ubuntu members and maintainers, they have a voice in approving members of both the Community Council and the Technical Board.

When participants feel that a particular area is under-served, they can go ahead and build a new team by drafting the details of the team in the Ubuntu wiki and recruiting contributors to help with their efforts. 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 forms of team councils. These councils are either 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, or they are completely-self run. These team councils have regular meetings, resolve conflicts, report to the Community Council each cycle, and in some cases even grant Membership on behalf of the Community Council.

The community team members each specialize in and work with their area of the community to help educate, encourage, and ignite greater participation. This also helps establish trust relationships with Canonical, upstream software projects, news and blog writers, and the wider community, which helps maintain a healthy and inclusive community that is empowered to develop, design, and influence the direction and growth of the Ubuntu project.

The Ubuntu community team has implemented the following new opportunities to engage the Ubuntu community:

For the Ubuntu Developer Community

Ubuntu Packaging Guide: http://packaging.ubuntu.com/

Ubuntu App Developer Web site: http://developer.ubuntu.com

Facebook: www.facebook.com/ubuntudev

Twitter: www.twitter.com/ubuntudev

Google +: https://plus.google.com/u/1/107265043789873157543/posts

For the Cloud Community

Ubuntu Cloud Web site: www.ubuntu.com/cloud

Juju Charms: https://jujucharms.com/

Twitter: www.twitter.com/ubuntucloud

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.

Want to find a Local Community team near you? All you have to do is go to the Ubuntu Local Community Team Portal at http://loco.ubuntu.com/ and begin by selecting your region of the world on the map or clicking the teams tab at the top of the page. Either action will bring up a list of current LoCo teams.

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 responsibilities of the MOTUs are many. Some important ones are that MOTUs

Understand packaging concepts and have substantial experience uploading packages through a sponsor.

Apply this knowledge by uploading new packages and updating existing packages in the universe component.

May contribute to the main component in cooperation with a core developer.

Answer questions of other developers to expand their understanding of packaging work.

Provide guidance for prospective Ubuntu developers regarding technical issues.

MOTU contributors are the people who are interested in contributing to Ubuntu and are learning how to package and work in the Ubuntu development community. They primarily work by using MOTUs as sponsors for their work. There are no requirements or exams to pass to become a MOTU contributor, just a willingness to learn and a commitment to the Ubuntu Code of Conduct. Many of these contributors do 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.

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. These are generally 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 no one will be asked to leave without a substantial review and an opportunity to defend himself or herself.

A third area of Council work is assisting teams with any blockers they may encounter in the running of their team. This may include, but is not limited to, assisting with getting access to resources lost due to a contributor stepping away, moving away blockers that the team may have in the community, and assisting with appointment of new leadership should the need arise. To this end, the Community Council works to meeting with key teams in the community each cycle during their regular meetings to see if they can assist the teams in any way.

Fourth, the Community Council is ultimately responsible for approving and welcoming new members to the project, 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 twice a month 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 moderate the channel so as to regain order. Full transcripts of meetings are published following a Community Council meeting. The current members of the Community Council can always be found at https://launchpad.net/~communitycouncil. Appointments to the Council are overseen by Shuttleworth, and a final vote among all Ubuntu Members is taken to select nominees from a list. Appointments last for a period of two years.

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 twice a month on IRC. Also like the Community Council, any user can submit an item or proposal for discussion by the Technical Board prior to the scheduled meeting. Meetings are open to all interested parties, although decision making and voting are restricted to Technical Board members. Full transcripts and rules about noise, as they pertain to the Community Council, also apply to the Technical Board. You can always find the current list of the Technical Board members at https://launchpad.net/~techboard. 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 two years.

Launchpad team: https://launchpad.net/~forum-council

Wiki page: https://wiki.ubuntu.com/ForumCouncil

Mailing list: [email protected]

Ubuntu IRC Council The IRC Council is the group that is ultimately responsible for governing the IRC channels and interfacing between IRC and the rest of the Ubuntu community and governance systems. The IRC Council also has the ability to grant Ubuntu Membership to key contributors.

Launchpad Team: https://launchpad.net/~ubuntu-irc-council

Wiki page: https://wiki.ubuntu.com/IrcTeam/IrcCouncil

Mailing list: [email protected]

Ubuntu LoCo Council The LoCo Council governs the LoCo community, makes decisions on resource allocations, deals with conflict resolution, and makes decisions about where the project should move forward.

Launchpad team: https://launchpad.net/~ubuntu-lococouncil

Wiki page: http://loco.ubuntu.com/loco-council/

Mailing list: [email protected]

Ubuntu Developer Membership Board The Ubuntu Developer Membership Board is the group responsible for considering and approving applications to become Members of the Ubuntu Core Developer team.

Launchpad team: https://launchpad.net/~developer-membership-board

Wiki page: https://wiki.ubuntu.com/DeveloperMembershipBoard

Mailing list: [email protected]

Ubuntu Membership Approval Board The Ubuntu Membership Approval Board is made up of a geographically distributed team that is responsible for considering applications for Ubuntu Membership.

Launchpad team: https://launchpad.net/~ubuntu-membership-board

Wiki page: https://wiki.ubuntu.com/Membership/Boards

Mailing list: [email protected]

The Ubuntu flavors (e.g., Kubuntu, Edubuntu) may also be governed by a council, but this is determined by each project and may change over time as the projects change and evolve.

Shuttleworth also maintains a tie-breaking vote on the Community Council 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.

Ubuntu 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 self-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 Membership board, can be easily reactivated.

The process to become a Member is relatively straightforward and is documented in depth at https://wiki.ubuntu.com/Membership. Most important, it requires that users document their contributions on a wiki page that includes links to code, mailing list messages, specific forms of documentation that clearly demonstrate their involvement, and/or other relevant material. Membership applications also need to include testimonials on work and involvement in Ubuntu.

Users aiming to contribute to Ubuntu’s documentation would be advised to take notes as they puzzle through problems and to document solutions when they find them. Before writing, users should also check to see whether documentation for a particular problem already exists. When it does, users would be wise to choose to improve or augment existing documentation rather than write a new document. Similarly, users can make meaningful contributions by reading through existing documentation and fixing factual, technical, stylistic, spelling, and grammar errors. Users who spend a large amount of time working on documentation may, with time, also want to join the Ubuntu Documentation Team, which can help organize and coordinate this work in terms of Ubuntu documentation goals.

Trackers for ISOs and packages are available through the Ubuntu Quality team. When users helping out with QA find bugs, they should report them in the Ubuntu bug-tracking system. They can also help by “triaging” bugs, closing or merging duplicates, or verifying bugs and adding information to a bug’s description. If you intend to become involved in QA, you should subscribe to the ubuntu-devel-announce mailing list and the ubuntu-quality mailing list, consider monitoring ubuntu-devel, and join the #ubuntu-quality IRC channel on irc.freenode.net.

With the rise of cloud-based software, infrastructure packaging is also available in the form of Juju Charms (https://jujucharms.com/). Juju Charms use the Juju service to specify and orchestrate dependencies and relationships among specific services that run on a server. For instance, a piece of blogging software may require a Web server and a database; these can be defined in Juju and launched on separate servers or with additional features, thereby making them highly available.