Subject: Alpine community governance

From: Natanael Copa <[email-masked]>
Date: Fri, 18 Oct 2019 11:17:49 +0200

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.

---

From: "Drew DeVault" <[email-masked]>
Date: Sat, 26 Oct 2019 10:46:58 -0400

> problem and desirable features?

Yes.

---

From: "Drew DeVault" <[email-masked]>
Date: Sat, 26 Oct 2019 12:17:22 -0400

Moving a discussion from IRC to the ML:

One easy way to improve the core team's bandwidth would be a simple git
hook which allowed anyone to push changes to packages for which they're
listed as the maintainer. This reduces the core team's workload to
dealing with new packages, new maintainers, etc; but removes the burden
of dealing with every change to aports.

---

From: Rasmus Thomsen <[email-masked]>
Date: Sun, 27 Oct 2019 13:42:20 +0000

> listed as the maintainer.

Hm, although that does sound like it'd significantly lessen the
workload on core member I dislike this approach, at least with how we
currently handle maintainership of packages. About everyone can become
a maintainer (which is a good thing IMHO since this allows people
knowing the package well but not Alpine's packaging process to be a
maintainer) as of now and I feel like it'd be best to have someone look
over the changes of maintainers which aren't that experienced with
Alpine's packaging process yet. Maybe just having somewhat strict CI
rules and only allowing a merge if CI passes would do the trick to
ensure QA is done though.

> This reduces the core team's workload to

---

From: Bart Ribbers <[email-masked]>
Date: Sun, 27 Oct 2019 16:42:36 +0100

> ensure QA is done though.

Then you have the problem that some packages take more time to compile than 
the CI allows. For example CI time had to be increased for my fork in Gitlab 
as I push KDE and Plasma changes, which almost all the time take more than 1 
hour to complete. I don't think it's feasible to manually increase the set 
time for every person's fork that needs it.

---

From: "Drew DeVault" <[email-masked]>
Date: Sun, 27 Oct 2019 11:44:02 -0400

> time for every person's fork that needs it.

FWIW, builds.sr.ht's limit is 4 hours and I think that we could manage
almost all builds under that deadline.

---

From: Kevin Daudt <[email-masked]>
Date: Sun, 27 Oct 2019 18:14:29 +0100

> almost all builds under that deadline.

FWIW, we can increase the limit as much as is necessary. The limit is
just there to prevent stuck jobs keeping hold of the runners for too
long.

---

From: Sören Tempel <[email-masked]>
Date: Sun, 27 Oct 2019 17:15:24 +0100

Rasmus Thomsen <[email-masked]> wrote:
> currently handle maintainership of packages.

To move my discussion contribution from the IRC to the ML: IMHO we
should rethink the aport maintainer role in general. Many package
maintainer comments are horribly outdated and contain contact
information of people who haven't committed in the past few years. Some
packages (even in main/ and community/) don't even have a maintainer
comment.

Even packages with accurate maintainer comments are often poorly
maintained, by the person maintained in the maintainer comment, i.e.
updates are done by different developers et cetera.

In my ideal scenario package upgrades would always be done by the
maintainer (would also reduce the patch queue as trivial package
upgrades are no longer part of it). It should also be possible to
contact the maintainer regarding issues with the aport and the
maintainer should be responsible for reviewing patches submitted to
GitLab/GitHub/Patchwork.

Currently, the maintainer is just some person who added their contact
information to the aport at some point in time. Debian, for instance,
has a very elaborate process for this sort of thing which might help
avoiding some of these pitfalls [0].

> Maybe just having somewhat strict CI rules and only allowing a merge
> if CI passes would do the trick to ensure QA is done though.

I disagree, I don't think CI rules can ever be good enough to catch any
sort of mistakes that a manual review might find. Also consider
malicious patches added to an aport, et cetera.

Cheers,
Sören

[0]: https://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_Maintainer

---

From: Rasmus Thomsen <[email-masked]>
Date: Mon, 28 Oct 2019 15:55:37 +0000

> packages (even in main/ and community/) don't even have a maintainer

Yes, right now maintainership often doesn't reflect who actually takes
care of a package, but I don't think the work of always keeping this
up-to-date is worth it (considering how often people come and go in the
OSS landscape).

> upgrades are no longer part of it).

That's terrible IMHO since this often creates a "this is MY package"
mentality, disallowing people other than the maintainer upgrading the
package and as such holding up progress. I mostly noticed that in the
time I used Gentoo, sometimes patches just sat around for months
without anyone looking at them because only the maintainer was allowed
to look at them (and was absent for a long time). One solution to this
could be agressively handing over the maintainance of packages who's
maintainer has been absent to a "Alpine general" (or something along
those lines) group which will then take care of updating it until
another maintainer has been found. But I fear that that'll create lots
of bureaucratic work for little gain, which can both demotivate
maintainers (it's annoying when you first have to ask for
maintainership of a package before being able to upgrade and might even
fence off new contributors which don't know our process well) and holds
off others from doing more useful things (like updating packages).

>  It should also be possible to
> contact the maintainer regarding issues with the aport

Hm, IMHO contacting the maintainer directly isn't a good tactic,
because:

* Maintainers often are absent (which is just in the nature of OSS)
* Private communications aren't searchable my others (like Gitlab
issues are)
* Often asking the upstream of the package is better than asking the
maintainer

>  and the

Again, maintainers in OSS projects often go absent without a warning,
maybe because they lost interest in the project or don't have enough
freetime to contribute anymore. This could lead to patches rotting for
a long time instead of letting a known group of coredevs review the
patch.

> avoiding some of these pitfalls [0].

A very elaborate process, which create lots of work and scares new
contributors off (or at least it least it does so for me). Really, the
ease of contributing to Alpine is a great thing and it'd be a shame if
we lost that.

> malicious patches added to an aport, et cetera.

Yup, it sure isn't good enough, but just letting maintainers push
without any checks in place other than that they maintain the package
is even worse.

> Sören

Regards,

Rasmus
> [0]: 
> https://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_Maintainer

---

From: Taner Tas <[email-masked]>
Date: Mon, 28 Oct 2019 03:31:07 +0000 (UTC)

At least we can discus about some git hooks that easing maintainer PR's on testing repo. Since testing repo is enabled by user and regarding the purpose of this repo, this could be a feasible idea in my opinion.

---

From: Rasmus Thomsen <[email-masked]>
Date: Mon, 28 Oct 2019 15:43:23 +0000

On Mon, 2019-10-28 at 03:31 +0000, Taner Tas wrote:
> At least we can discus about some git hooks that easing maintainer
> PR's on testing repo. Since testing repo is enabled by user and
> regarding the purpose of this repo, this could be a feasible idea in
> my opinion.
> 

Sure, that _could_ be feasible but IMHO we don't have much of a problem
with the review queue of packages for testing and community, most stuff
that rots is in the main repo due to less people having push access for
those, so we wouldn't really gain much by allowing maintainers to push
to testing without a review (which does often catch errors).