docs(governance): add ubuntu governance doc

Work with executives to designate governance organizationally and
within InnerSource teams.

#5

docs/maintainer-guide/hierarchy-community-governance.md

@@ -0,0 +1,78 @@
+# Governance
+
+## Table of contents
+
+<!-- toc -->
+
+- [Mission](#mission)
+- [Code of Conduct](#code-of-conduct)
+- [Goals](#goals)
+- [Guilds (Community Councils)](#guilds-community-councils)
+- [Chapters (Technical Board)](#chapters-technical-board)
+- [Executive Steering Committee](#executive-steering-committee)
+- [Appointments](#appointments)
+- [Delegation, councils, boards and teams](#delegation-councils-boards-and-teams)
+- [Working Groups (Delivery Teams)](#working-groups-delivery-teams)
+- [Local Meet-ups](#local-meet-ups)
+
+<!-- tocstop -->
+
+## Mission
+
+The mission of <%= productName %> draws a very diverse community of participants and collaborators and contributors, who have wildly different interests and goals. We want to draw on the talents of a diverse global community, and to do that, we establish high standards for collaboration, debate, delegation of responsibility and ethics.
+
+## Code of Conduct
+
+One of the key innovations that <%= productName %> pioneered in free software communities is the use of a Code of Conduct. It lays out the expectations that we have of those who participate, represent or engage with the project. Essentially, it calls on people to treat one another with respect regardless of their differences of opinion, and it is the foundation for all of our governance practices. The <%= productName %> Code of Conduct continues to serve as a template for many other communities since it was established in 2004.
+
+## Goals
+
+Our goals in setting up the governance structures of <%= productName %> are to ensure that:
+
+1. There is a defined process that helps people participate in decisions regarding the <%= productName %> community and distribution. It should be clear who is responsible for any given decision, and how others might contribute to the outcome.
+
+1. Decisions regarding the <%= productName %> distribution and community are taken in an accountable, fair and transparent fashion.
+
+1. Necessary decisions are actually taken, even when there is no clear consensus among the community. There is a single path for the appeal or escalation of a decision when needed.
+
+## Guilds (Community Councils)
+
+The social structures and community processes of <%= productName %> are supervised by the <%= productName %> Community Council, which manages nominations and elections for <%= productName %> boards and councils. The council is also responsible for the Code of Conduct and tasked with ensuring that community members and leaders live up to the standard it sets.
+
+The Council is ultimately responsible for dispute resolution, should it be required. For example, in the past, we have helped to resolve conflicts in LoCo teams and in the <%= productName %> forums - both very important parts of the community that have their own leadership structures carrying authority delegated by the Community Council.
+
+The Community Council meets every two weeks on Internet relay chat (IRC). You can propose an item for discussion at a council meeting on the Community Council Agenda page on the <%= productName %> Wiki.
+
+## Chapters (Technical Board)
+
+The Software Developement and Delivery Chapter is responsible for the technical direction of <%= productName %>. It makes decisions on package selection, packaging policy, installation systems and processes, kernel, X server, display management, library versions and dependencies. The board works with relevant teams to establish a consensus on the right path to take, especially where diverse elements of <%= productName %> cannot find consensus on shared components.
+
+The <%= productName %> Technical Board meets every two weeks on IRC - date and agenda of the next meeting, alternating with the Community Council. You can propose an item for discussion by putting it on the Technical Board Agenda on the <%= productName %> Wiki.
+
+## Executive Steering Committee
+
+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 Executive Steering Committee sponsors the InnerSource Program, and has the authority to ask people to work on specific projects, specific feature goals and specific bugs.
+
+The community functions best when it can reach broad consensus about a way forward. However, it is not uncommon in the open-source world for there to be multiple good arguments, no clear consensus, and for open questions to divide communities rather than enrich them. The debate absorbs the energy that might otherwise have gone towards the creation of a solution. In many cases, there is no one 'right' answer, and what is needed is a decision more than a debate. The SABDFL acts to provide clear leadership on difficult issues, and set the pace for the project.
+
+## Appointments
+
+Mark, as project sponsor, is responsible for short-listing volunteers and community nominees as candidates for both the Community Council and Technical Board. In each case, a poll of relevant members of the project is conducted to select, or veto, the final membership of the Community Council and Technical Board.
+
+## Delegation, councils, boards and teams
+
+The Community Council and Technical Board, in turn, delegate their responsibilities through a large, dynamic and complex web of teams that span both the globe and a vast diversity of disciplines. In general, these groups try to conduct polls of relevant portions of the community to test the quality of their appointments, but they can also act unilaterally to ensure that the best people are recognised as leaders, decision makers and experts to get the job done.
+
+## Working Groups (Delivery Teams)
+
+There are a number of key teams that are responsible for different areas of <%= productName %> — documentation, kernel, servers, laptops and translation to a name a few.
+
+If you have a particular interest in a specific aspect of the project, please join that team's discussions and contribute to their decisions. Examples include teams focused on <%= productName %> laptop usage, the <%= productName %> desktop look and feel, <%= productName %> for servers, release management and the installer. If you would like to set up a new team, please gather some like-minded people and propose ideas for consideration by the <%= productName %> Community Council.
+
+## Local Meet-ups
+
+A major part of the fabric of the community is the local community (LoCo) team structure. LoCo teams work with local Linux User Groups (LUGs), schools, municipalities and even national governments to open people's eyes to the world of free software.
+
+LoCo teams are a great way to gather free software lovers together for beer, open discussion, talks, marketing events, install-fests and to recognise the achievements of local free software contributors. We provide server hosting space for LoCo websites, wikis, mailing lists and other resources. LoCo members visit conferences to speak, hand out CDs, teach, debate and represent both <%= productName %> and the free software movement.
+
+The LoCo team action mostly happens on the <%= productName %> wiki - see the LoCo team directory for more information.