X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id 39E59F84D6C for ; Thu, 11 Apr 2019 12:31:28 +0000 (UTC) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id 814389E1FDB; Thu, 11 Apr 2019 12:31:27 +0000 (UTC) Received: from ncopa-desktop.copa.dup.pw (67.63.200.37.customer.cdi.no [37.200.63.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: alpine@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id CDB9A9E035A; Thu, 11 Apr 2019 12:31:26 +0000 (UTC) Date: Thu, 11 Apr 2019 14:31:19 +0200 From: Natanael Copa To: Chloe Kudryavtsev Cc: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] [RFC] New Governance Model Message-ID: <20190411143119.644e3407@ncopa-desktop.copa.dup.pw> In-Reply-To: References: <2a54dd89-9204-644f-6273-e5505d490e05@toastin.space> <20190410143631.7740d688@ncopa-desktop.copa.dup.pw> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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? -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---