Mail archive

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

From: Natanael Copa <>
Date: Thu, 11 Apr 2019 14:31:19 +0200

On Wed, 10 Apr 2019 12:30:46 -0400
Chloe Kudryavtsev <> wrote:

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

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.

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

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?


Received on Thu Apr 11 2019 - 14:31:19 UTC