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
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
I hadn't actually mentioned that last one in my other email, so let me
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
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.
Received on Thu Apr 11 2019 - 10:25:21 UTC