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  (multiple (short) pages,
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
Here is a summary of the proposal:
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).
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
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.
: Full Text: https://beta.docs.alpinelinux.org/developer-handbook/0.1a/
Received on Mon Apr 08 2019 - 22:59:34 UTC