DomainKey-Signature: a=rsa-sha1; c=nofws; d=toastin.space; h=from
	:subject:to:message-id:date:mime-version:content-type
	:content-transfer-encoding; q=dns; s=ml; b=Si3gLtAYhBBwh2rjBiSqP
	DYq/QizsqPLZpEdWWE8vO93IkfDoJtYDLryCqvHC2pUM1H6lub4M5zrSVxc0iMzM
	KaRyLh9PFwLNvRgEkJ6sTj9Clf2KM5hePhBIh2NGIzOQULXmBwVWpIL05u9O0scc
	Xt4bwdMXlWMn8aKL3U4lh76rI9pZtE+nlrd2M4A2WHNeusOVjvBF+1+PJLUKyusL
	MDAhbt2NLXqpJElYAGS+HPHC8H47CwGGZS7NIE7LfvsluDLpFrByHzIuWPsVeo0d
	mOcpXgzXfexO+Lrb7FSwPsyny6+eFevCdwA2emtS2rk/zlwe51aO674GeKt5Tvrg
	g==
From: Chloe Kudryavtsev <toast@toastin.space>
Subject: [alpine-devel] [RFC] New Governance Model
To: alpine-devel@lists.alpinelinux.org
Message-ID: <2a54dd89-9204-644f-6273-e5505d490e05@toastin.space>
Date: Mon, 8 Apr 2019 22:59:34 -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
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit

Hi all, this is the next step in the attempts to reach a new governance 
model, as a culmination of weeks, or even months of work.

The following proposal is intended as a "bootstrap" proposal - one that 
passes just enough through that everything it doesn't specify can be 
specified using its provisions.
Full proposal contents can be found in [1] (multiple (short) pages, 
navigation currently requires javascript, non-development UI is in 
progress).
For a summary, see below.

Plain "ACK"s are helpful.
If you have concerns, they should align with the project's goals and 
guiding principles (as per the previous RFC), and preferably be 
actionable. (suggest the action if they are!)
The steps expected past this point:
1. Get the proposal ratified (any modifications included, though very 
few are expected at this point).
2. Find someone to handle initial Base elections (special case: first 
elected has full term, second 2 years, and last only 1 year, as part of 
the bootstrapping procedure).
3. It is expected that for the first month or so, Base actively 
participates in further bootstrapping (setting up initial teams, adding 
policies, etc) - as per spec, but more than is normally expected.
4. After that month, we are expected to be in a self-sustaining system, 
at which point normal operation goes on (e.g new teams being established 
by someone starting them and becoming their admin, rather than 
Base-nominated).

Here is a summary of the proposal:
1. Base
The Base team owns the project and can make any decision at any time 
(but are expected to primarily act as arbitration, details within).
The Base team is comprised of 3 project-wide-elected members, with 
3-year staggered terms (1 election / year).
Any Base team member may attempt to re-join, but not immediately after 
their term ends (meaning that if everyone is consistently re-elected, 
it's a rotation between 4 people).

2. Teams
All teams are subteams of Base, and handle a subset of the project's needs.
Base trusts the teams to handle day to day tasks related to their field, 
and teams trust Base to lead the project in the correct direction.
Teams (including Base) may have policies, with the top-most policy being 
the official one for the subtree.
If a specific team wishes to have a conflicting policy, they talk it out 
with the team whose policy it would conflict with.

3. Admins & Voting
Admins of a team represent that team within the greater project.
A team must always have at least one admin, and at most 3.
Voting may either happen between admins (requirement: 2/3 majority) or 
through Base.
Base may decide on an outcome outright, hold a popular vote, or refuse 
to handle the matter.
Base elections *must* be done through popular vote.

4. Adding/Updating Policies
Every team may add and change their policies whenever they wish.
It is expected that they hold unofficial votes internally.
Project-wide policies (not Base policies, but policies that affect even 
Base) must be put to the standard voting procedure, and take the form of 
a pull/merge request (with history) to the document.

FAQ (so far):
	Q: Why are there no separate tech and community committees?
A: As per the "Prevent and respond to abuses of power without disrupting 
the project" guiding principle, having multiple entities with absolute 
power is undesirable.
There could be a separate also-elected community committee, but that 
might topple over the current balance of efficiency.
The recommended approach (instead) is to have a community arbitration 
team, that has no official power (but does have policies that the other 
teams are expected to know).
If they find any serious violations, they can talk to the perpetrators, 
and if no resolution happens, they can bring the matter to Base.
If they attempt to abuse this power themselves, Base should notice this 
and react accordingly.

[1]: Full Text: https://beta.docs.alpinelinux.org/developer-handbook/0.1a/


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---