Mail archive
alpine-devel

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

From: Chloe Kudryavtsev <toast_at_toastin.space>
Date: Wed, 10 Apr 2019 12:30:46 -0400

On 4/10/2019 8:36 AM, Natanael Copa wrote:
>> 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.

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

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

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

> But "core" team does not either describe what the role is.

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

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

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

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

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.

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

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.

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

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.

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

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

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

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

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.

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

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


---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Wed Apr 10 2019 - 12:30:46 UTC