Subject: [alpine-devel] [PATCH 0/2] Re: [RFC] New Governance Model

From: Drew DeVault <[email-masked]>
Date: Tue, 9 Apr 2019 01:02:08 -0400

Spoke with Chloe about this privately. I think the original charter of
the base team dillutes the authority necessary for it to be effective in
times of crisis. By outlining a bunch of limitations on the base team,
it gives tools to bad actors to undermine their authority with, and
works against the trust we're supposed to be putting in that team.

This reframes the base team as self-governing, putting how it governs
itself as out of scope for the project-wide governance document, and
updates the project governance docs accordingly to establish the base
team more firmly as the final authority on the project.

However, the information lost is still important. We should find a place
to put a document which establishes the principles to which the base
team holds itself. These include at least:

- Live up to the faith the project has put in you
- Trust the teams and generally avoid intervention
- Have faith in the election process and trust the next base team to
  execute the role responsibly

We should use these principles when establishing the initial base team.
As new members cycle in, the veterans should use their first year to
educate them on the principles by which they can be responsible stewards
of the project.

Aside: the first patch is pretty unopinionated. I shoved all of the
opinions into the second patch.

Drew DeVault (2):
  Move team structure before team administration
  Rework the base team description

 modules/Teams/pages/index.adoc | 62 ++++++++++++++++------------------
 1 file changed, 29 insertions(+), 33 deletions(-)

-- 
2.21.0

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

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Tue, 9 Apr 2019 01:15:27 -0400

Applied: doesn't change anything substantial, but communicates the 
intent better.
Modified the order of the team and base h2s, since they broke in the 
combination of the patches (see git log).

P.S. Looks like this broke threading, so I encourage further 
conversation to carry on in the original thread.

---

---

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

You have to establish what the teams are before you can establish how
they are maintained
---
 modules/Teams/pages/index.adoc | 66 +++++++++++++++++-----------------
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/modules/Teams/pages/index.adoc b/modules/Teams/pages/index.adoc
index 667e915..9560dc3 100644
--- a/modules/Teams/pages/index.adoc
+++ b/modules/Teams/pages/index.adoc
@@ -24,6 +24,39 @@ Team Admins are marked in *bold* in official team listings.
 There is no distinction between technical and non-technical team members. Both are valued, and any useful distinctions are left to the discretion of individual teams.
 ====
 
+== Team Structure
+
+=== Internal Organization
+Teams organize themselves internally however they want.
+However, all teams must have at least 1 admin, and at most 3.
+This document does contain multiple recommendations, which, if followed, will make external relations easier.
+Further, team administrators must follow non-team-local expectations.
+
+=== Creating a New Team
+An existing team member within the project may propose creating a new team.
+In that scenario, the process will be the same as in <<_becoming_a_team_administrator>>.
+If the vote passes, the new team is formed, with the sponsor member as the only administrator.
+
+=== Dissolution of Teams
+A team is dissolved if it has no more members.
+If a team has no more administrators, one must be nominated, as in <<_becoming_a_team_administrator>>.
+If the vote does not pass, the team is dissolved as well.
+
+== The Base Team
+The Base team is purely an administrative one.
+It is also the only team that shall not have admins, and has a static number of members.
+The Base team must always have exactly 3 members, to guarantee quorum.
+The Base team technically owns Alpine.
+Alpine's policies apply to them, but they have the power to bypass them in case of extreme need.
+
+It is expected that the Base team does not do anything unless prompted.
+Violation of this without there being a strong need is effectively a violation of trust of the entire rest of the project.
+Similarly, the Base team is expected to trust team admins and members to do the correct thing on their own.
+
+Base team members are elected through a project-wide {votelink}[Vote].
+A term is 3 years long, and the terms are staggered (each year, a new Base team member must be elected).
+Term cycling is allowed - you cannot replace yourself, but you can replace the next person to rotate out.
+
 == Membership
 
 === Being a Member
@@ -65,36 +98,3 @@ Removing members (and especially administrators) is an extreme measure.
 In most cases, it is possible to solve issues through other means.
 It is highly recommended that the removal of anyone from the project be strongly considered before it is suggested.
 ====
-
-== Team Structure
-
-=== Internal Organization
-Teams organize themselves internally however they want.
-However, all teams must have at least 1 admin, and at most 3.
-This document does contain multiple recommendations, which, if followed, will make external relations easier.
-Further, team administrators must follow non-team-local expectations.
-
-=== Creating a New Team
-An existing team member within the project may propose creating a new team.
-In that scenario, the process will be the same as in <<_becoming_a_team_administrator>>.
-If the vote passes, the new team is formed, with the sponsor member as the only administrator.
-
-=== Dissolution of Teams
-A team is dissolved if it has no more members.
-If a team has no more administrators, one must be nominated, as in <<_becoming_a_team_administrator>>.
-If the vote does not pass, the team is dissolved as well.
-
-== The Base Team
-The Base team is purely an administrative one.
-It is also the only team that shall not have admins, and has a static number of members.
-The Base team must always have exactly 3 members, to guarantee quorum.
-The Base team technically owns Alpine.
-Alpine's policies apply to them, but they have the power to bypass them in case of extreme need.
-
-It is expected that the Base team does not do anything unless prompted.
-Violation of this without there being a strong need is effectively a violation of trust of the entire rest of the project.
-Similarly, the Base team is expected to trust team admins and members to do the correct thing on their own.
-
-Base team members are elected through a project-wide {votelink}[Vote].
-A term is 3 years long, and the terms are staggered (each year, a new Base team member must be elected).
-Term cycling is allowed - you cannot replace yourself, but you can replace the next person to rotate out.
-- 
2.21.0

---

---

From: Drew DeVault <[email-masked]>
Date: Tue, 9 Apr 2019 01:02:10 -0400

It's important to firmly establish the authority of the base team. The
guiding principles to which the base team holds itself are out-of-scope
for this document and better served elsewhere.
---
 modules/Teams/pages/index.adoc | 28 ++++++++++++----------------
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/modules/Teams/pages/index.adoc b/modules/Teams/pages/index.adoc
index 9560dc3..f3cfe1d 100644
--- a/modules/Teams/pages/index.adoc
+++ b/modules/Teams/pages/index.adoc
@@ -26,13 +26,24 @@ There is no distinction between technical and non-technical team members. Both a
 
 == Team Structure
 
+== The Base team
+
+The Base team has ownership over Alpine Linux and is the last authority in any decision-making.
+For day-to-day operations, additional teams are established at the pleasure of the base team and given the authority necessary to conduct themselves.
+
+The Base team consists of 3 elected members, guaranteeing a quorum.
+Members of this team serve 3 year terms, staggered such that one member steps down per year.
+Each year, an election is held through a project-wide {votelink}[Vote].
+Members of the Base team cannot serve consecutive terms, but may be re-elected after a one year break.
+
 === Internal Organization
 Teams organize themselves internally however they want.
 However, all teams must have at least 1 admin, and at most 3.
 This document does contain multiple recommendations, which, if followed, will make external relations easier.
-Further, team administrators must follow non-team-local expectations.
+Further, team administrators must follow the policies of other teams when working in their domain.
 
 === Creating a New Team
+The base team needn't be involved in establishing every team - the project as a whole is permitted to self-govern in this respect.
 An existing team member within the project may propose creating a new team.
 In that scenario, the process will be the same as in <<_becoming_a_team_administrator>>.
 If the vote passes, the new team is formed, with the sponsor member as the only administrator.
@@ -42,21 +53,6 @@ A team is dissolved if it has no more members.
 If a team has no more administrators, one must be nominated, as in <<_becoming_a_team_administrator>>.
 If the vote does not pass, the team is dissolved as well.
 
-== The Base Team
 
 === Being a Member
-- 
2.21.0

---

---

From: Ted Trask <[email-masked]>
Date: Tue, 9 Apr 2019 07:44:17 -0400

Any scheme that would result in Natanael being removed from the base team after three years would not get my vote. As far as I am concerned, ncopa should be Alpine Linux’s Benevolent Dictator For Life. Completely serious.

Ted

> On Apr 9, 2019, at 1:02 AM, Drew DeVault <[email-masked]> wrote:
> 

---

---

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

On 2019-04-09  7:44 AM, Ted Trask wrote:
> Any scheme that would result in Natanael being removed from the base
> team after three years would not get my vote. As far as I am
> concerned, ncopa should be Alpine Linux’s Benevolent Dictator For
> Life. Completely serious.

One of the stated goals of this effort is to reduce ncopa's workload and
bus factor. What good is it if ncopa gets burnt out?

I trust ncopa not to ratifiy a governance model that won't work, and you
ought to as well. Personally I agree that the BDFL model is a very
effective one, but I think that Chloe has found one which may be
similarly effective and has several advantages.

---

---

From: Ted Trask <[email-masked]>
Date: Tue, 9 Apr 2019 13:55:51 -0400

There is a big difference between sharing the workload and giving up authority. My main objection is to the stipulation that a base team member cannot be reelected immediately. Not only is ncopa sharing authority with two others for the first three years, he would be forced to give up all authority in the fourth year. Or am I reading it wrong?

Ted

> On Apr 9, 2019, at 9:31 AM, Drew DeVault <[email-masked]> wrote:
> 

---

---

From: Drew DeVault <[email-masked]>
Date: Tue, 9 Apr 2019 13:58:38 -0400

On 2019-04-09  1:55 PM, Ted Trask wrote:
> There is a big difference between sharing the workload and giving up
> authority. My main objection is to the stipulation that a base team
> member cannot be reelected immediately. Not only is ncopa sharing
> authority with two others for the first three years, he would be
> forced to give up all authority in the fourth year. Or am I reading it
> wrong?

You're interpreting it correctly, though I assume ncopa will continue to
serve his roles in teams other than base during that time. I think that
you should trust ncopa to back a governance model he believes will work,
even if it means he has to take a break every few years. He is far from
uninvolved in these discussions, I suggest you trust his judgement in
this matter. After all, if he doesn't want the authority then it's not
your place to force him to accept it.

---

---

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

On Tue, 9 Apr 2019 13:58:38 -0400
Drew DeVault <[email-masked]> wrote:

> this matter. 

I initially did not have strong opinion on the rotation model but the
more I think about it the less I like it.

> After all, if he doesn't want the authority then it's not

I have never said I want to resign.

I would very much like to share it and I would very much be able to
take a break if needed and leave it in trusted hands. I need to be
prepared to give up authority if that ever will be needed.

I must admit I am not very comfortable with the thought of being forced
to completely giving up authority but I am open to discuss it and not
completely against it.

I will unlike sit and do nothing for a year so why would I want to get
back to the Alpine drama instead of continue with the new thing I'm
doing?

-nc

---

---

From: Chloe Kudryavtsev <[email-masked]>
Date: Wed, 10 Apr 2019 14:52:58 -0400

> back to the Alpine drama instead of continue with the new thing I'm

You only have to take a break from being on base.
Membership (or even adminship) of multiple teams is allowed.
So you're not "leaving the project for a year", you just take a break 
from being "the ultimate authority" for a year.
In short, everyone except you (and maybe Carlo) are currently in that 
position, and I don't think saying that everyone except you "sit around 
and do nothing" is fair.

As such, surely you'll agree, that concern is a bit moot - after all, we 
don't expect people that haven't and aren't doing anything with the 
project to be elected into base, are we?

---

---

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

On Wed, 10 Apr 2019 14:52:58 -0400

> from being "the ultimate authority" for a year.

There is no guarantee that anyone gets re-elected.

So after being forced to step down I could have the choice to continue
do bug fixing, provide user support etc, but I would no longer have any
responsibility of how the projects goes, nor need to deal with people
drama and CoC violations, nor need to care about technical decisions.
That would be someone elses problem.

> position, and I don't think saying that everyone except you "sit around 

Ofcourse not. What I meant was that this would be a great opportunity
for me to start some new exciting project. If i did that. Why would I
be interested in getting back into "base" and clean up whatever mess
the last person has introduced?

> project to be elected into base, are we?

The concern here is, do we want rotate out good people? Or do we want
try keep them.

-nc

---

---

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

> There is no guarantee that anyone gets re-elected.

Ultimately, you have to trust the project to elect good people.
Just like you have to trust the project to write good code.

> What I meant was that this would be a great opportunity

Because you know you're the right person for the job.
Let me put it this way: if the only reason you want to remain in power 
is because you have it now, that sounds like you're on your way to 
burning out.

> The concern here is, do we want rotate out good people? Or do we want

We want to rotate people, period.
People can change - someone could go from being good to being less 
active, or even straight out bad.
Suggesting kicking someone out of a powerful group like base shakes up 
the entire project - it is inherently a violent event, and is inevitable.
Simply waiting a bit and not re-electing them is a peaceful resolution 
to such things: it is a self-correction mechanism.

Of course we want to keep good people, but the process of selecting 
people should be through positive reinforcement (re-elect the good 
people!), rather than negatively selecting the bad ones.

This is also why you cannot be re-elected immediately.
When elections are coming up, the person about to end their term would 
have significant amounts of influence, and if they were bad they could 
use those to try to pressure people into re-electing them.
Similarly, a good person that's about to end their term would be 
vulnerable to bad external actors pressuring people into not re-electing 
them (for instance, someone could go through everything you have ever 
said, and tried to dig up something embarrassing).
Both of these types of events are unneeded strain on the project, and 
both are effectively eliminated by enforcing a one-year-break between 
being in power.

If the worst scenario you're considering is someone ends up finding 
something they like doing better, I don't believe that to be bad.
I would instead be glad for the person that found something they like 
doing even more :)
(Note: same applies to any people that leave the project in general for 
such reasons - we should strive to be an amazing project to contribute 
to, rather than keeping people around because they have a sense of 
obligation, in my opinion. This is one of my long term goals as well, 
though one that's less seemingly distant.)

---

---

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

On Thu, 11 Apr 2019 10:16:03 -0400

> We want to rotate people, period.

So we want rotate out the good people.

> Of course we want to keep good people,

So we don't want rotate out the good people.

> but the process of selecting 

Maybe I was unclear. I was talking about the project as a whole. We
don't elect our contributors. They join on their initiative.

-nc

---

---

From: Drew DeVault <[email-masked]>
Date: Thu, 11 Apr 2019 11:27:35 -0400

I've also been unsure about forced rotation. Why don't we compromise and
eliminate the restriction about serving consecutive terms?

---

---

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

> eliminate the restriction about serving consecutive terms?

You actually brought up one of the reason forced rotation has to exist 
in one of our talks previously.
Allow me to quote myself with the relevant examples:

On 4/11/2019, I wrote:
> When elections are coming up, the person about to end their term would have significant amounts of influence, and if they were bad they could use those to try to pressure people into re-electing them.
> Similarly, a good person that's about to end their term would be vulnerable to bad external actors pressuring people into not re-electing them (for instance, someone could go through everything you have ever said, and tried to dig up something embarrassing).
> Both of these types of events are unneeded strain on the project, and both are effectively eliminated by enforcing a one-year-break between being in power. 

If we were to eliminate the restriction about serving consecutive terms, 
we would have to make sure we are prepared for well-known real scenarios 
like the above.
I think forced rotation is an adequate method of preventing them 
inherently, and also gives the base member the opportunity to see the 
world from the position of everyone else - refreshing their perspective 
and enabling them to serve better.

If we can come out with ways to have both of the above that is not 
forced rotation, I would be onboard, but I'm not really seeing any 
acceptable approach.
Do you have one? :)

---

---

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

> So we don't want rotate out the good people.

Let me be more specific:
We want to rotate out people that we give absolute power to.
Whether or not they're good or bad.
The people that are good will just be back in a year.
The people that are bad are less likely to create a war due to leaving.

> don't elect our contributors. They join on their initiative.

We indeed do not elect our contributors.
The rotation stuff *only* applies to base.
Kicking an admin out for misbehavior is not the same as trying to kick 
out a base member.
It's still quite the event, but it is not project-wide-devastation levels.
As such, there is no need to rotate out admins (and definitely not 
regular members).

---

---

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

On Thu, 11 Apr 2019 11:31:09 -0400

> >> We want to rotate people, period.  

To be honest, I find this worrying. Who are "we" here?

There are people in this very thread that explicitly said they don't
want rotation.

There are a significant amount of people who have not responded to this
proposal at all for various reasons, so I have spent this week calling
people to ask what they think and what they feel about it.

There have also been people that in private has reached out to me and
expressed concern about this proposal, where it comes from and what
your intentions are.

My impression is that people are worried about this rotation thing.

> The rotation stuff *only* applies to base.

So my point here is that whatever happens in the
leadership tend to propagate to the rest of an organization. If you
want honesty in the organization, the leadership needs to be honest. If
you want diversity in an organization, you start in the leadership
board. If you want a peaceful organization you need to have a peaceful
leadership board.

So lets flip this rotation of people thing around.

In case that that would want to have forced rotation through the
organization, where we would want to replace people, regardless if they
are good or bad, then the logical step would be to implement forced
rotation in the "base" team.

But if we want to keep the good people within the he organization, then
maybe forced rotation of "base" team is not the best approach. I mean,
it would not surprise me if losing good people in the rotation process
becomes a side-effect, a hidden cost.

Is rotation worth the risk of losing good people?

Maybe it is.

But before you say that we will not lose anyone (we already lost at
least two over this), please imagine yourself in this situation: You
create a small distro and spend 13 years to raise and maintain your
baby. You see people come and people go. You see people stick in good
times and bad times. Then the distro grows big.

And a new person shows up and after 5 months he says:
- We want Chloe to step down. Anyone can take over, just not Chloe.

You respond:
- Hum sure, why not, would be nice to let someone else deal with the
  people drama. I could be a part of a technical lead team instead,
  that would be nice.

- No, no! We don't want any separate technical lead team at all. *We*
  want Chloe to step down. Period. But she may come back in a year.

So to prove to everyone - including yourself - that you are not a power
abuser, you do step down.

But would you actually want to come back after that?

-nc

---

---

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

>>>>> The concern here is, do we want rotate out good people? Or do we want
"people with Alpine's best interests in mind".

> There are people in this very thread that explicitly said they don't

And my point of view (so far) has been: "well, this solves problems A 
and B, and provides advantage C, and it doesn't look like anyone has any 
better ideas"; which actually remains true, but...

> My impression is that people are worried about this rotation thing.

This has become my impression as well.
Whether it is for (unnamed) logical reasons, or (as I suspect it is) for 
emotional reasons, people do not seem to want this.
That does leave us with the issues (and, I would hope, desirable 
advantage) mentioned above, however.

> board. If you want a peaceful organization you need to have a peaceful

This has actually not been something I've considered, and is a good point.

> least two over this)

And herein lies the obvious problem (as per the above thing I hadn't 
considered).
If it does play out that way (and, as you say, it seems like it is), the 
things I outlined definitely are not worth it.
Being wrong is something I do on occasion, but I had hoped that it would 
be caught (and properly explored as it is now) earlier.

> please imagine yourself in this situation: You

As a note, I decided not to interject within this block, and simply talk 
about it as a whole afterwards.

1. It is clear that you took the idea of forced rotation personally.
I see why that happened, and have been trying to avoid it through my 
statements.
The idea is so: when you write general rules, you typically do not want 
to add specific exceptions (especially involving a single person).
Perhaps this is an atypical case.
I would certainly want (and expect) for you to be elected at every 
instance where you are available, and it was not my intent for you to 
take the proposal in this way.
However, my intent is mostly irrelevant to the fact that it *has* happened.
I would like you to know that I am deeply sorry and regretful that this 
is how that played out, and reaffirm that that was never my intent.

2. As I think I mentioned at the start, the "We" I was using was 
supposed to include you.
It's quite clear at this point that I've misrepresented the de-facto 
desires (whatever they are based in), and regret that as well.

> But would you actually want to come back after that
3. This outlines another failing of mine - I've clearly failed to 
(sufficiently) empathize with you.
Your original wording of the problem seemed confusing and contradictory, 
but instead of trying to figure out the original intent, I had responded 
to the words.
I hope to be better in this regard as well.

> - No, no! We don't want any separate technical lead team at all.4. This is quite interesting; my perception was the opposite.
I see Base as both the technical and community leads, but primarily the 
former (after all, most conflicts they'd be resolving would be of 
technical nature; I expected the community things to be less common).
My objection was thus to not having an additional all-powerful entity 
that would then be the community leadership.
If we consider Base the community leadership, the technical leadership 
would not actually need to be all-powerful (only the parent of 
everything but Base), and that could certainly be done.

In short, 4 seems to have been a communication issue.
Not really certain who's at fault in that one (nor that there 
necessarily need be someone specific at fault), but I've definitely been 
an active participant.

---

In summary, the side effects (some of which had only been pointed now) 
of forced rotation probably are not worth the outlined advantages.
It would be nice to come up with something else that gets us at least 
some of the advantages without said side-effects and controversy.

Further, the approach I had taken (due to my lack of attentiveness, the 
source of which ultimately is not relevant to the result) has caused you 
to take the idea personally.
I find this regrettable, and I am sorry that I wasn't good enough to 
catch and stop that earlier.

As to the way forward, please refer to my other email (response to the 
call re: a working group).

---