Mail archive
alpine-devel

Re: [alpine-devel] Stripping down the governance model proposal

From: Chloe Kudryavtsev <toast_at_toastin.space>
Date: Wed, 17 Apr 2019 19:24:22 -0400

On 4/15/2019 11:23 AM, Drew DeVault wrote:
> Simplified governance model:
>
> 1. The core team is stripped down to 3 trusted people.
> 2. The core team is generalized to "responsible for everything".
> 3. The core team delegates their responsibilities at their discretion.

The concern here is that we'd just delay the problems a bit.
The problem is that virtually all decisions currently go through a
single choke point.
Make that choke point bigger might help temporarily, but I have doubts
as to the degree.

> Notes:
>
> - The new core team would immediately grant everyone already in core the
> necessary abilities to do the jobs they already do.
> - The core team can delegate delegation itself, for example to expand
> the leadership of aports.

The current system basically has the large core with all the powers and
abilities.
In practice, the problems we have remain.
This usually means that there isn't enough "grease" in the system to
move things along.
Formality (up to a certain point, past which it becomes red tape
instead) usually is said "grease".

> Based on this simplified model, informal teams will materialize as
> they're needed with minimal pomp & circumstance. The process for e.g.
> joining aports as a committer to community, becomes informally
> convincing the people who are responsible for giving people commit
> access to aports to add you. The person making that call might want to
> run it by the mailing list or the IRC channel for comments before
> pulling the trigger.

Again... this is basically the status quo, and it isn't really working
out, with very few people disagreeing on that front.

> The process for establishing a Python team is just getting a bunch of interested people together and doing the work. If it's necessary to connect an ad-hoc team like that with resources, just make the case to the person responsible for those resources.
How well this works generally depends.
This worked out somewhat ok with docs, because there was a lot of
motivation to help getting it started, and only one person (me) actually
needed any access.
This didn't quite happen to the suggestion of said python team, though,
which again suggests a lack of grease - more people = more things to do
= greater initial resistance to get through.

> Official externally-facing roles can be established at the pleasure of
> the core team, as well. A security team, for example, can be established
> less informally and have membership written down somewhere, with a
> point-of-contact for the rest of the world.

There are currently informal themes (in an internal-only wiki).
However, due to lack of formality (or some other factors), not everyone
on them is actually active.
Furthermore, the lists aren't up to date in the other direction too -
some people are effectively on them, while not being on the list.
This ultimately defeats the purpose of having these lists around, and
does not help with external facets.

> This may be simple enough for bootstrapping purposes and ought to solve
> the problems we set out to fix. As more complex procedures are shown to
> be necessary over time, they can be added.

This does not solve the problems we have set out to fix.
As a reminder, let me re-iterate them here:

1. All decision making has to be done by a small number of people, so
things get done slowly, if at all.
This stays in place, the number of people goes up to 3, and that's about it.
Since we aren't improving the system in any other way relevant to this,
there is no reason to expect this to suddenly change.

2. Motivated people can't make their way into a position of trust, and
become demotivated.
Similarly, we are not changing the methods of getting into a position to
do the work effectively.
There is no reason to expect this to change the situation.

3. There is no interface between alpine and the outside world.
As I mentioned, we currently have an internal-wiki with semi-unofficial
listings, like what you propose.
They are not accurate.
There is no reason to assume that, without making things more official,
they would be taken more seriously.
Having an inaccurate and buggy interface might be worse than the choke
point, even.

4. People responsible for everything are unable to specialize.
This does nothing in that regard too.
It says that the new core would be able to delegate things, but they
have that ability *now*, and it isn't happening very much.
There is no reason to assume this would change if we don't modify anything.

As a summary, I think a response to your opening statement is appropriate:

> There is a general sense of dissatisfaction with the governance proposal
> under discussion. It's too big and makes a lot of changes at once.

The issue with the dissatisfaction is that it reduces the odds of
passing it through.
If a proposal that fixes all the issues does not pass through, it fixes
no issues.
This is the other end of the spectrum.
It is simple to make a proposal that passes, but actually fixes nothing.
However, if a proposal that fixes nothing passes, nothing was fixed.
These two scenarios are effectively identical.

I would prefer to fix as much as possible without dissatisfying the
community, as opposed to enact minimal change with no effect.
If a specific thing doesn't fix something, while being intended to fix
it, it should either be improved to have the desired effect or replaced
with something that does.
This is not such a thing.


---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Wed Apr 17 2019 - 19:24:22 UTC