Subject: [alpine-devel] [RFC] New Governance Model

From: Chloe Kudryavtsev <[email-masked]>
Date: Mon, 8 Apr 2019 22:59:34 -0400

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.

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.
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).
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).

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.

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.

4. Adding/Updating Policies
Every team may add and change their policies whenever they wish.
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.
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/

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Kaarle Ritvanen <[email-masked]>
Date: Tue, 9 Apr 2019 12:54:45 +0300 (EEST)

On Mon, 8 Apr 2019, Chloe Kudryavtsev wrote:

> 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.

Who is allowed to participate in a popular vote? Anyone who has an e-mail 
address? How is it ensured that nobody casts multiple votes e.g. using 
false identities?

BR,
Kaarle

---

---

From: Drew DeVault <[email-masked]>
Date: Tue, 9 Apr 2019 09:26:22 -0400

> address? How is it ensured that nobody casts multiple votes e.g. using 

Votes are held among team admins.

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Tue, 9 Apr 2019 09:51:41 -0400

> address? How is it ensured that nobody casts multiple votes e.g. using

By default, votes are held between admins.
"Popular" (or Project-Wide) votes are held between all members (clearly 
defined lits, after bootstrapping is complete).
In the latter case, the Base team ensures everything is done cleanly.
In the bootstrapping process, the person we select to handle the 
elections will do that (one-time job, though much more complicated than 
it will be afterwards).

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 11 Apr 2019 23:27:50 +0200

On Mon, 8 Apr 2019 22:59:34 -0400

> model, as a culmination of weeks, or even months of work.
...
> [1]: Full Text: https://beta.docs.alpinelinux.org/developer-handbook/0.1a/

Since we are sort of stuck with this, I suggest that we establish a
working group of 4 people that together comes up with a modified or new
proposal.

I suggest Chloe is one of those and I have a candidate of someone that
can be an external, neutral expert with experience of this process from
other distros.

It would be good to have two more with at least one long timer.

Are there any volunteers?

-nc

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Thu, 11 Apr 2019 20:01:09 -0400

> can be an external, neutral expert with experience of this process from

I have no problems with this.
If it takes more people and more time to get the proposal to a 
reasonably optimal state, then that's just what we'll have to do.
I do think we're reasonably close to that point, but I've also had that 
belief previously (and it has been wrong multiple times now).

> It would be good to have two more with at least one long timer.

I would like to stress that last part:
Having someone that's been with the project for a long time should 
guarantee that the zeitgeist of the project is adequately represented.
It's uncertain why this hasn't been the case so far (with you being an 
active participant, and several others such as Daniel tossing ideas), 
but hopefully having them be on a de-facto board that's handling this 
will remedy that situation.

---

---

From: Richard Mortier <[email-masked]>
Date: Fri, 12 Apr 2019 17:32:25 +0100

> will remedy that situation.

FWIW if volunteers are still required, I could volunteer, though (as
noted in other email) I'm a n00b so also happy to defer to pretty much
anyone else :)

If I read Chloe's email right about pushing discussion back onto this
thread from the other, then regarding the forced rotation for Base, my
2c:

I think there are advantages and disadvantages to such a model, and
it's not completely clear to me which dominates.
But does it have to be determined up front anyway?

In the interest of moving forward, and as a question to the more
established members of the community: is there an obvious set of 3
initial Base(*) team members (ncopa would be one presumably; are there
others? or perhaps just ncopa at first as the sole member of the
"bootstrap Base team"?) who could form it initially, and then run a
process under the new governance model to refine how the Base team is
constituted in future?

That would allow time for proper consideration of different options
while also not blocking other things (eg., trying to get packaging and
other load distributed off of ncopa's shoulders). It might also serve
as a useful test of the new model (re voting etc), to see whether it's
really fit for purpose and able to evolve as needs change. In the
worst case, nothing much changes: ncopa ends up resolving fundamental
disputes and basically operates as BDFL, though hopefully with
slightly more help in other matters. More likely (hopefully!) some
structure gets created with which the community (including ncopa :) is
content, and so everything improves in line with the principles.

(*) for want of a better name for now.

Also FWIW, and by way of background for my suggestion above: my
experience of governance models (largely in academic environments
admittedly) is that they're never actually correct, only ever good
enough for now; and they fundamentally involve people interacting, so
it's possible to spend a remarkably long time trying to work out
wording of rules that end up never being needed because the people
involved simply don't behave in ways that would trigger those rules.
IMO it's more important to ensure that the governance model remains
"live" -- that is, understood and trusted by those involved in
whatever is being governed -- than to try and pre-emptively define all
the rules very precisely.

Thanks!

--
Richard Mortier
[email-masked]

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Fri, 12 Apr 2019 14:00:57 -0400

> But does it have to be determined up front anyway?

That's a good point - perhaps we need only make sure Base (or the 
project as a whole) has the ability to deal with any such situations 
as/when they arise.
Still, looking at the (relatively now) newfound problems with forced 
rotation, I think it should be off the table indefinitely, at least for 
the near-to-medium future.

> process under the new governance model to refine how the Base team is

Not part of that group (similarly to you, though I've clearly not been 
lurking).
I think we could initialize with ncopa as the obvious initial 
3-year-term member, and ask him to handle elections for the 2 and 1 year 
"initial" term members.
My concern, however, is that this would add *more* work to do upon his 
shoulders (even if it's just a short-term thing).
That is why I was suggesting finding someone else to handle said process.

> content, and so everything improves in line with the principles.

The primary focus is very much de-centralization; teams that can 
self-govern to a large extent.
Having that obviously requires structure, and that part is where we seem 
to have gotten stuck, to some degree.
"Base" was never really intended to do much (even if they can in theory, 
in order to be effective at their job), but I can definitely see why a 
lot of discussion has been sparked from it.

> (*) for want of a better name for now.

++
I believe it can be changed later if we ever figure out a better title.

> the rules very precisely.

That does seem to be what's going on here.
Could you go over the current state of the document, and estimate what 
parts are missing vs what is "extra"?
In case the link's been lost, I have it added in [1].

> Thanks!

No, thank *you*.
More eyes on the problem is usually good, and your 2c has been quite 
valuable :)

[1]: https://beta.docs.alpinelinux.org/developer-handbook/0.1a/

---

---

From: Kevin Daudt <[email-masked]>
Date: Mon, 15 Apr 2019 21:35:59 +0200

> Are there any volunteers?

I'll volunteer to be part of the working group.

Kevin

---

---

From: Natanael Copa <[email-masked]>
Date: Mon, 15 Apr 2019 22:08:52 +0200

On Mon, 15 Apr 2019 21:35:59 +0200

> I'll volunteer to be part of the working group.

Wonderful!

Drew Devault also volunteered on IRC, but think we need at least one with
long history and/or trust. Kevin definitively has high level of trust,
so I think he is a good candidate. (he has access to build servers and
signing keys)

So we have Chloe, Richard and Kevin. I have also asked if Allison
Randal want be part of this work group as a neutral "external"
specialist. Allison has been developer and member of various other
distros like Debian, Ubuntu and SUSE and has some experience with open
source governance. She has already given me some good advice and ideas
regarding Alpine Linux re-org and said she can help us with this.

I suggest that Kevin do the coordination.

Thanks you all!

-nc

---

---

From: Nathan Angelacos <[email-masked]>
Date: Mon, 15 Apr 2019 17:03:24 -0400

I have history with the project.

If you want "old-guy BOFH" to be in the room, I would be willing to
participate.  But I'd rather my role be "hey grandpa, what do you
think?"

I think we have a lot of talent in this distro now, and definitely want
to see where that talent takes us.  If any of the new talent wants to
know how we got here, I have lots of stories. :)

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Mon, 15 Apr 2019 20:08:24 -0400

> participate.  But I'd rather my role be "hey grandpa, what do you

I, personally, welcome all opinions.
Especially those rooted in history with the project and community.
I'd be glad to hear anything (and everything) you might have to say!

> know how we got here, I have lots of stories. :)

I don't know if I'm included in the new talent set or not, but have a 
fascination with good storytelling in general!
I'd be glad to listen to any such stories that you may have to tell, 
assuming it's in a convenient setting for all involved. :)

---

---

From: Natanael Copa <[email-masked]>
Date: Wed, 10 Apr 2019 14:36:31 +0200

Hi!

> 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.

> 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.

> (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.

> 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.

> 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.

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.

> Every team may add and change their policies whenever they wish.

Does this include adding and removing team members?

> 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):
> 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.

> 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

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Wed, 10 Apr 2019 12:30:46 -0400

On 4/10/2019 8:36 AM, Natanael Copa wrote:
> describe the role.

"Base" was taken from Gentoo ([1]).
I'm not particularly attached to that name.

> What was wrong with "core" team? Keeping the term

That's exactly the problem with it.
Core used to have two major sides to it: managing the project and 
managing main/stable branches.
We're effectively splitting that into two components (base being the 
management aspect, and whatever we name the packaging team being that).
Calling either of those "core" would give people false impressions.
Furthermore...

> How about something like "steering team" or something in that direction?

That seems kind of long, but I agree we need a better name, ideally.
Does anyone else have any suggestions?
I don't think this is a critical part (besides not naming it "core"), 
but that just makes it all the more easier to change.

> involved in every single decision that is made, for various reasons.

The thing is that in order to be effective guardians of the project, any 
regulatory entity must have powers sufficient to effectively be able to 
do anything with the project.
Philosophically, the community *is* (and thus owns) the project.
In practice, however, "core" currently owns the project, and "base" will 
effectively own the project (unless they do not have enough power to 
effectively protect it).

> other projects to work with and don't want come back next year? So we

Because of how it works, we basically need 4 people instead of 3 to have 
a perpetual team - with them taking turns having a year-long break.
That's roughly what's expected.
However, people change over time - someone may want to leave, or someone 
may change and no longer adequately represent the project.
Having terms means that, in both of those scenarios, there is a peaceful 
way to resolve the situation.

> team, do we need to force rotation at any cost?

Forced rotation exists for the above reasons.
It has a lot of advantages, and very few disadvantages, so I'd like to 
keep it.
If base goes fully rogue, the project effectively must be forked 
(whether or not there's a documented way to override them), since the 
power to be effective guardians of the project is quite dangerous.
However, this is why there are three members - in order for base to go 
fully rogue, one must establish a quorum, and then try to remove 
elections without a fork happening.

> teams so they don't end up living in their on universes.

Admins essentially represent a given team.
Teams may obviously communicate between each other, but admins are 
intended to regularly communicate even without it necessarily being needed.
In the full document, you may also see that an existing expectation for 
admins is to participate in any meetings that go on.

> don't think it scales if we get many teams.

I don't expect votes to happen all that often after bootstrapping.
Votes are required for bigger things, such as changing project-wide 
policies.

> Does this include adding and removing team members?

This definitely includes adding members.
It's expected that removing members be done with greater prejudice.
Adding admins calls for a vote (as per above).
The idea is that teams self-govern to a large extent, and that does 
include various members.
This is why admin positions are taken a lot more seriously.
Also see below.

> skills in the different groups.

The concerns I have are as follows:
1. having multiple entities with effectively "ultimate power" (needed to 
be effective guardians) dilutes both
2. if the community committee is to exist, it should be controlled the 
same way as base is - multiplying the amount of elections by at least 2
3. I don't think dedicated-technical people should have any power over 
dedicated-community people and vice-versa. Base should be composed of 
"people", not "dedicated X" people.

I'm definitely willing to talk this over, but I think now isn't really 
the time to institute this.
After all, we have the necessary components to change policies in the 
future [2], so we can add it once it is needed.

> I guess it would be good to have the full proposal posted as a single

The issue would be that the actual document is separated into pages and 
categories - as it will be when fully finished.
As a result, any attempt to flatten it would be awkward.
Perhaps ddevault could try?
But yes, it's important to remember, as per the start of the original 
email, the email is the *summary*.

[1]: https://wiki.gentoo.org/wiki/Project:Base
[2]: 
https://beta.docs.alpinelinux.org/developer-handbook/0.1a/Policies/update.html

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 11 Apr 2019 14:31:19 +0200

On Wed, 10 Apr 2019 12:30:46 -0400

> effectively own the project (unless they do not have enough power to 

Just because they have been entrusted authority and power does not mean
they own it. They can not own the community members or people and they
legally don't own the code contributions unless the authors of those
explicitly says so (like they do with Gentoo).

So using the word "own" can be and has already been misunderstood, and
in my opinion does not describe what we are after. And in worst case
can be abused (3 years in future: "Hey we own the code so we make it
closed source now. The developer doc clearly states that we own this
project, which includes the code. You should have thought of that before
you sent the patches...")

I do agree that they need to been given the needed power, and I
understand what you mean. I just think we should use different words for
it to avoid confusion.

...
 
> Forced rotation exists for the above reasons.

If the community is not ready for enforced rotation. What are the
options? Or is forced rotation the only way to solve this?

> It has a lot of advantages, and very few disadvantages, so I'd like to 

What are the disadvantages?

-nc

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Thu, 11 Apr 2019 10:25:21 -0400

> understand what you mean. I just think we should use different words for

Okay, that makes sense to me.
We should thus reword it as something like so:
"Base is the ultimate authority, and the rest of the project structure 
exists [...]"
Would that be acceptable?

RE: patch ownership...
This is actually quite a major problem that we have right now.
People sending in patches (even non-members) could, at any time, decide 
that they no longer like alpine and legally threaten us.
This doesn't need to be in the proposal, but I'd like it noted that the 
parent packaging team should have a policy that dictates that all 
patches should be transferred in ownership to the project at large.

> What are the disadvantages?

I think I went over it in detail in my other email (which I had 
forgotten to CC at you, so please do still take a look).
The summary of the disadvantages of not rotating:
- Self-correction is impossible
- Structural changes of any kind are inherently violent
- New members have no reason to trust base (unlike members present 
during election)

I hadn't actually mentioned that last one in my other email, so let me 
explain.

Everyone trusts various people differently.
Whenever elections happen, what effectively is going on is that the 
project selects the person that they trust *most*.
People that, at the time, do not trust the elected person as much thus 
get a higher level of trust in them - after all, all their colleagues 
seem to trust them more than anyone else.
The issue is that, if someone joins the project a day after elections, 
this does not apply to them.
Perhaps the result would have been better if they had been given a 
chance to vote.
The only way to get the advantage of the heightened trust level for them 
is to go through a whole election cycle and give them the opportunity to 
vote.
Since we want to keep base small (for ensured quorum and the ability to 
make fast decisions), we can't just keep adding members, and thus 
rotation is necessary for that level of trust.
If the project does not have trust in base (e.g lots of people joined 
while there was a "functional base", and they are now the majority), 
this creates unneeded friction: what is a guardian group that does not 
have the trust of those it protects?

Put another way: the technical aptitude of Base doesn't matter too much 
- they're an administrative and conflict-resolving group above all.
What matters most is that they do whatever the project thinks is correct.
And what the project things is correct can change over time, since new 
people can join, old people can leave, and so on.

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 11 Apr 2019 17:00:06 +0200

On Thu, 11 Apr 2019 10:25:21 -0400

> Would that be acceptable?

Would be better at least.
 
> RE: patch ownership...

lets keep that discussion separated from this. Preferable at a
different time.

> The summary of the disadvantages of not rotating:

No, I meant: what are those very few disadvantages of forced rotation?

-nc

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Thu, 11 Apr 2019 11:29:19 -0400

> Would be better at least.

Okay, I'll patch it in later today (about to go out).

> lets keep that discussion separated from this. Preferable at a

Fair enough, just wanted it on record.

> No, I meant: what are those very few disadvantages of forced rotation?

Oh I see.
The disadvantages are such:
1. Elections have to be held, and have to be project-wide.
This is slow, and requires decent amounts of effort.
Thankfully, with how we have it set up, it only happens once a year, and 
is thus acceptable.
2. If the project is compromised (most project members do not have the 
project's best interests in mind), after 3 years the protection 
abilities of base also become compromised.
However, if the project is compromised, it's effectively already dead, 
this only accelerates that.

---