Date: Fri, 18 Oct 2019 11:17:49 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Alpine Develmopment <~alpine/devel@lists.alpinelinux.org>
Subject: Alpine community governance
Message-ID: <20191018111749.430b15a9@ncopa-desktop.copa.dup.pw>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi!

The working group has been working on a proposal for the Alpine Linux
governance. Before we post any suggestions we'd like to try define and
agree on current state and current problem, so we avoid discussions
which are trying to solve different problems due to disagreement what
the problem is.

Richard Mortier has written down the current state, the problems and
what features we want.

Do you think this is a good description of the current state, current
problem and desirable features?

Thanks!
-nc

# Alpine Community Governance

Per the [website](https://alpinelinux.org/about), "Alpine Linux is an
independent, non-commercial, general purpose Linux distribution
designed for power users who appreciate security, simplicity and
resource efficiency". The Community exists to support the Project which
develops the Distribution, and adheres to a [code of
conduct](https://alpinelinux.org/community/code-of-conduct.html). While
successful so far, problems are becoming apparent as the popularity of
the distribution increases, primarily due to heavy reliance on Natanael
(`@ncopa`), the project lead.

This note describes the current governance practices of the Community,
attempts to describe known problems with that practice, and suggests
some features that the Alpine Community might find desirable in any
evolution of its governance structure. It draws directly and indirectly
on many sources including the draft statement of the project [goals][],
and both the [interim][] and [draft][] new governance proposals.

[goals]: https://beta.docs.alpinelinux.org/governance/0.1a/index.html#_project_goals
[draft]: https://beta.docs.alpinelinux.org/governance/0.1a/index.html
[interim]: https://wiki.alpinelinux.org/wiki/Governance

Particular thanks to Natanael, the Governance Working Group (Allison
Randall, Kevin Daudt `_ikke_`, Richard Mortier `mort___`), William
Pitcock, and Chloe (`@SpaceToast`) have all fed into this.

## Current Practice

In effect, Natanael is Benevolent Dictator with overall responsibility
for everything. Everything includes but is not limited to:

- Team coordination and membership
- Security incidents
- Release engineering
- Governance
- Package maintenance
- Build server infrastructure
- Kernel work
- Sub-projects including abuild, boot scripts, alpine installer etc
- Docker base images
- Recruiting
- Conflict resolution
- Social media presence, marketing
- Quality assurance and testing

In some of these responsibilities he is supported by the community,
e.g., the many package maintainers take responsibility for maintaining
their own packages, but that support is often informal and
responsibility ends up reverting to him. In a handful he is more
formally supported by teams that have been formed:

- The _Core Team_ comprises those with commit rights to `aports/`,
  currently around 13 people.
- An informal _Infrastructure Team_ comprising Carlo Landmeter
  (`@clandmeter`), Kevin, and Drew DeVault (`@ddevault`) looks after
  the Alpine Linux infrastructure (MQTT, build servers, git servers,
  mailing list, patchworks, etc).
- A _Documentation Team_ comprising Chloe (`@SpaceToast`) looks after
  maintaining and updating the Wiki and other documentation.

Team additions occur by "lazy consensus" -- nomination is accepted once
two or more team members indicate support. In practice, neither team
changes very frequently (perhaps the Core Team slightly more often than
the Infrastructure Team), but when changes are required, the team comes
together to discuss proposed additions, until consensus is reached. If
no consensus is reached then the proposed change is blocked until
consensus can be reached.

Team departures have occurred over the years for a variety of reasons,
with the departing individual sometimes later returning. In practice
the only person who can eject someone from a team is Natanael; this has
only very rarely actually happened.

In recent months, a distinction has become apparent within the Core
Team: while all members have the commit rights to maintain packages,
some are no longer actively participating in any other community
activity (e.g., replying to emails).

In the end, in practice, most decisions are ratified by Natanael before
being enacted anyway.

## Problems with Current Practice

There are undeniable problems with the current approach:

- It doesn't scale well as Community size increases (Natanael is
  increasingly a bottleneck).
- It doesn't scale well as team size increases (risking either
  increasing difficulty to reach consensus if the number in support is
  increased, or risking fragmentation of the team if the size increases
  while support from only two is required).
- It isn't always transparent (public and private discussions take
  place via IRC and email, making it sometimes difficult to track
  what's happening as well as making it difficult for newcomers to
  understand practices and participate).

## Desirable Features

The governance processes of the Alpine Linux Community will need to
evolve over time, as the Community grows and as problems are
encountered and overcome. The underlying principles of the Project are
referenced above; in support of these, governance mechanisms should be:

- **Transparent**. That is, documented and designed to take place in
  the open, in full view of the Community as far as possible.
- **Lightweight**. Although the Community has recently grown, and this
  has triggered the need for a more formal governance structure, the
  Community is still small enough that largely informal discussion and
  consensus building is a satisfactory way forward for most day-to-day
  matters. If growth continues to the point the more heavyweight
  processes are needed, that bridge should be crossed at that point --
  it would be (at best) distracting to try to write down strict rules
  that cover all possible eventualities at this stage.
- **Evolvable**. Whatever processes are instituted now, they will
  surely need to change. They should do so in ways that adhere to the
  above two properties (Transparent; Lightweight), and which enable
  further future evolution.