DomainKey-Signature: a=rsa-sha1; c=nofws; d=toastin.space; h=subject:to
	:references:from:cc:message-id:date:mime-version:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=ml; b=sFQPV70R
	15/gL518XcMbwi5Zn/zUyiVk2BB1T7IPj9QE+Rtd+CB8Quv9B0sLcxaZ+Ls+hX5p
	21+M2P0UtEwJvUb9QWchNIFb7CSGQwSuRcLeL+96Ax4/6uNRZ0myoQ4JVldYQXCa
	HMtYSFzlWKpxpXRRs5ZpGuSDHt7ozFWA0ScDo3XigNM9WTQ7q/OJkK0DALxc73CD
	9T8c7TxapwuUeiO/IaSpv2KOok9ORWwystghnZHCSm7YhT5Ho91jwqoTpJpPi0ra
	N6rmoHe77RUYxCMKhIMOplbKsdDLyYk1iPbbcwqu3ymvP4G6G5BbZrhX3no0PiWA
	74OYlm24II2dzQ==
Subject: Re: [alpine-devel] Stripping down the governance model proposal
To: alpine-devel@lists.alpinelinux.org
References: <20190415152330.GG1179@homura.localdomain>
From: Chloe Kudryavtsev <toast@toastin.space>
Cc: Drew DeVault <sir@cmpwn.com>
Message-ID: <c5146728-ebc1-f90b-4333-6871c4402c6d@toastin.space>
Date: Wed, 17 Apr 2019 19:24:22 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:67.0) Gecko/20100101
 Thunderbird/67.0
Precedence: list
MIME-Version: 1.0
In-Reply-To: <20190415152330.GG1179@homura.localdomain>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit

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@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---