DomainKey-Signature: a=rsa-sha1; c=nofws; d=toastin.space; h=subject:to
	:references:cc:from:message-id:date:mime-version:in-reply-to
	:content-type:content-transfer-encoding; q=dns; s=ml; b=gWJJktfW
	ky/aMyK8wftQpl1O4ZI81JgEuVhI4rjvWwQWCNjcK6e3un0wg4sEeEsHMG4z4fUk
	8SV0edlNUbQXkkTaWF6HYun32dB+uAqbTLa+3J82C8pBgIABwA7oij/aNv2lsbkl
	6Y+NAs4auwRHACc4LBHRCKw3qykekaQyPB1qRksLavwxZhSsj87eovKX2JtaK1pR
	418+1NmqetwUdTodaoOMPADt2XssG9BQaI20V4LHJRkzxmfoq4y8HFsHNNz7AWK/
	Mx5SeI5YUhe5jD24f32Pnw8pB9xBqIjWe+XJu7yK+xX+QgZMXHxSD0BFDgrfmdMz
	L75REr+90QrtzQ==
Subject: Re: [alpine-devel] [RFC] New Governance Model
To: alpine-devel@lists.alpinelinux.org
References: <2a54dd89-9204-644f-6273-e5505d490e05@toastin.space>
 <20190410143631.7740d688@ncopa-desktop.copa.dup.pw>
 <d58b4a47-c6bf-e122-d02a-edc741271365@toastin.space>
 <20190411143119.644e3407@ncopa-desktop.copa.dup.pw>
Cc: Natanael Copa <ncopa@alpinelinux.org>
From: Chloe Kudryavtsev <toast@toastin.space>
Message-ID: <144bcb8f-66fe-29ad-f18d-bc90779bdfa7@toastin.space>
Date: Thu, 11 Apr 2019 10:25:21 -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: <20190411143119.644e3407@ncopa-desktop.copa.dup.pw>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 4/11/2019 8:31 AM, Natanael Copa wrote:
> 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.

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.

> 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
>> keep it.
> 
> 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.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---