Date: Wed, 10 Apr 2019 14:36:31 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Alpine Development <alpine-devel@lists.alpinelinux.org>
Cc: Chloe Kudryavtsev <toast@toastin.space>
Subject: Re: [alpine-devel] [RFC] New Governance Model
Message-ID: <20190410143631.7740d688@ncopa-desktop.copa.dup.pw>
In-Reply-To: <2a54dd89-9204-644f-6273-e5505d490e05@toastin.space>
References: <2a54dd89-9204-644f-6273-e5505d490e05@toastin.space>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi!

On Mon, 8 Apr 2019 22:59:34 -0400
Chloe Kudryavtsev <toast@toastin.space> wrote:

> Hi all, this is the next step in the attempts to reach a new governance 
> model, as a culmination of weeks, or even months of work.

FWIW, this is not something Chloe has done alone. It is a result of
lots of discussions, primarily on #alpine-docs channel on Freenode, and
various people have been involved, including me.

I am very happy that Chloe has been driving this, since I have not had
the needed energy to push this. So a big thanks for the work done so
far!

I have also consulted others about open source governance, people that
has experience with that from other projects and have got some useful
information on what has worked well and what to watch out for etc.

> The following proposal is intended as a "bootstrap" proposal - one that 
> passes just enough through that everything it doesn't specify can be 
> specified using its provisions.

I specifically asked for this. So this proposal is not intended to be
the final goal. Instead of having discussions about a large set of
rules about teams and organization of teams (which teams, who is on the
different teams etc) lets start with the basics, who and how to modify
the rules.

Then the rest of the work ahead will hopefully be simpler.

> Full proposal contents can be found in [1] (multiple (short) pages, 
> navigation currently requires javascript, non-development UI is in 
> progress).
> For a summary, see below.
> 
> Plain "ACK"s are helpful.
> If you have concerns, they should align with the project's goals and 
> guiding principles (as per the previous RFC), and preferably be 
> actionable. (suggest the action if they are!)
> The steps expected past this point:
> 1. Get the proposal ratified (any modifications included, though very 
> few are expected at this point).
> 2. Find someone to handle initial Base elections (special case: first 
> elected has full term, second 2 years, and last only 1 year, as part of 
> the bootstrapping procedure).
> 3. It is expected that for the first month or so, Base actively 
> participates in further bootstrapping (setting up initial teams, adding 
> policies, etc) - as per spec, but more than is normally expected.
> 4. After that month, we are expected to be in a self-sustaining system, 
> at which point normal operation goes on (e.g new teams being established 
> by someone starting them and becoming their admin, rather than 
> Base-nominated).
> 
> Here is a summary of the proposal:
> 1. Base
> The Base team owns the project and can make any decision at any time 
> (but are expected to primarily act as arbitration, details within).

I think we need a better name than "base" which does not really
describe the role. What was wrong with "core" team? Keeping the term
"core" may help people to think that that this is not a completely new
thing, just a slight modification in how things has always been.

But "core" team does not either describe what the role is.

How about something like "steering team" or something in that direction?

I also think we need to reword the "Base team owns the project", which
does not really describes what we are after and can be misinterpreted
(and already caused some confusion on IRC).

It is the community that "owns" the project, but we need a smaller
trusted group (or single person) that can make decisions on behalf of
the community, because we cannot have every member of the community
involved in every single decision that is made, for various reasons.

Some people may want me to be the self benevolent dictator for life
that takes that role (which I sort of do in practice at this point),
but to be honest I don't want be alone in that position, and would like
to share that burden of responsibility.

> The Base team is comprised of 3 project-wide-elected members, with 
> 3-year staggered terms (1 election / year).
> Any Base team member may attempt to re-join, but not immediately after 
> their term ends (meaning that if everyone is consistently re-elected, 
> it's a rotation between 4 people).

The idea here is to protect against someone getting "eternal" power and
encourage new fresh impulses regularly. It also enforces the principle
that we should not depend on any single person (or organization) and
encourages that we train new people to take over a such role.

I don't really have any strong opinions on this really, even if it
always is uncomfortable to give up authority and control. I think it
could be nice to be able to have a break for a position like this, but
I don't know if it is any point to force changes in a "base" team that
work well together and everybody is happy with it either.

What happens if we have a well working team that everybody trust, and
there is no good candidate? Do we need to rotate and give authority to
someone we don't really trust? What if some of the "good" people find
other projects to work with and don't want come back next year? So we
risk losing good people.

It may be good to have a way to overrule the "base" team in big or
important decisions. For example with a full community vote. If we have
something in place for that, as a safety net against a broken "base"
team, do we need to force rotation at any cost?

> 2. Teams
> All teams are subteams of Base, and handle a subset of the project's
> needs. Base trusts the teams to handle day to day tasks related to
> their field, and teams trust Base to lead the project in the correct
> direction. Teams (including Base) may have policies, with the
> top-most policy being the official one for the subtree.
> If a specific team wishes to have a conflicting policy, they talk it
> out with the team whose policy it would conflict with.

Will probably be good to have some sort of coordination between the
teams so they don't end up living in their on universes.

> 3. Admins & Voting
> Admins of a team represent that team within the greater project.
> A team must always have at least one admin, and at most 3.
> Voting may either happen between admins (requirement: 2/3 majority)
> or through Base.
> Base may decide on an outcome outright, hold a popular vote, or
> refuse to handle the matter.
> Base elections *must* be done through popular vote.

Here is where I am a bit skeptic. I think it may work initially, but I
don't think it scales if we get many teams.

> 4. Adding/Updating Policies
> Every team may add and change their policies whenever they wish.

Does this include adding and removing team members?

> It is expected that they hold unofficial votes internally.
> Project-wide policies (not Base policies, but policies that affect
> even Base) must be put to the standard voting procedure, and take the
> form of a pull/merge request (with history) to the document.
> 
> FAQ (so far):
> 	Q: Why are there no separate tech and community committees?
> A: As per the "Prevent and respond to abuses of power without
> disrupting the project" guiding principle, having multiple entities
> with absolute power is undesirable.

I would like to have a split of authority of technical and community
issues, so even if we don't include this in the initial "bootstrap"
proposal, I think we should work having it separated.

That way the power gets divided between two groups instead of one group
sitting with all the power. We will also have people with different
skills in the different groups.

> There could be a separate also-elected community committee, but that 
> might topple over the current balance of efficiency.
> The recommended approach (instead) is to have a community arbitration 
> team, that has no official power (but does have policies that the
> other teams are expected to know).
> If they find any serious violations, they can talk to the
> perpetrators, and if no resolution happens, they can bring the matter
> to Base. If they attempt to abuse this power themselves, Base should
> notice this and react accordingly.
> 
> [1]: Full Text:
> https://beta.docs.alpinelinux.org/developer-handbook/0.1a/

I didn't really understand it initially, and I think I was not alone.
The proposal is in the above handbook, and this email was just a
summary.

I guess it would be good to have the full proposal posted as a single
email instead.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---