|
|
= Network team metapolicy =
|
|
|
|
|
|
{{{
|
|
|
This is the version of the proposal for accepting policies that we
|
|
|
discussed at our July 12, 2019 in-person meeting. It is amended
|
|
|
as discussed in the meeting, and not otherwise.
|
|
|
|
|
|
This is version 4.
|
|
|
|
|
|
As of 29 July, all team voters have agreed that this policy is
|
|
|
what we agreed upon. ~~It is now provisional policy, and becomes
|
|
|
non-provisional on October 29.~~ It is now team policy.
|
|
|
|
|
|
|
|
|
SCOPE
|
|
|
|
|
|
This document describes how we adopt policy proposals that apply to
|
|
|
our team and its work. It doesn't apply to change proposals in our
|
|
|
software, but rather to things like our LTS policy, our security
|
|
|
issue policy, our supported platform policy, our team member roles
|
|
|
policies, our release timelines, and things like that.
|
|
|
|
|
|
This metapolicy is meant to work for a team where people trust one
|
|
|
another; it is not trying to be robust against rules-lawyers.
|
|
|
|
|
|
RATIONALE
|
|
|
|
|
|
This process is meant to prevent situations where our proposals
|
|
|
become deadlocked waiting to know whether we have consensus.
|
|
|
|
|
|
It is meant to ensure that we have a discussion period for every
|
|
|
proposed policy, that the discussion period ends, and that we take
|
|
|
an affirmative decision about each proposal.
|
|
|
|
|
|
PROCESS
|
|
|
|
|
|
1. THE DISCUSSION PERIOD
|
|
|
|
|
|
A team member writes a draft policy and sends it to network-team
|
|
|
for comment. The draft policy comes with a target date when we
|
|
|
hope to conclude discussion.
|
|
|
|
|
|
If the policy is one that affects other groups or teams, or
|
|
|
which we should get their input on, we put it on the wiki as a
|
|
|
draft policy and circulate it to those teams or to a tor mailing
|
|
|
list as appropriate.
|
|
|
|
|
|
Team members are expected to pick target dates so that all other
|
|
|
team members have a reasonable amount of time to see and comment
|
|
|
on the policy. Two working weeks is a reasonable time for simple
|
|
|
policies; longer is reasonable for more complicated policies.
|
|
|
|
|
|
A proposed policy may be amended at any point during the discussion
|
|
|
period.
|
|
|
|
|
|
All pending proposals should be listed in the discussion section
|
|
|
of each week's meeting. By default, every proposal should have
|
|
|
been discussed during at least 2 meetings.
|
|
|
|
|
|
The proponent or any team member may call for the discussion
|
|
|
period to be extended.
|
|
|
|
|
|
2. VOTING
|
|
|
|
|
|
At the end of the discussion period, if any changes have been made to
|
|
|
the proposal, the proponent should provide a final "clean" version
|
|
|
for adoption. Each team member should then declare their status on
|
|
|
the proposal. Possibilities are "+1" (in favor), "-1" (against), and
|
|
|
"+0"/"-0" (weakly in favor/weakly against). There is no difference
|
|
|
in outcome between +0 and -0: they are just for indicating an
|
|
|
opinion.
|
|
|
|
|
|
By default we vote on the network-team@ mailing list. Any member
|
|
|
may call for a secret ballot. In that event, we ask some
|
|
|
mutually agreed upon party to tally the votes using a mutually
|
|
|
agreed upon method.
|
|
|
|
|
|
3. OUTCOME
|
|
|
|
|
|
Members may vote early, and may change their votes. At the end
|
|
|
of the voting period, we ask people who have not already voted to
|
|
|
do so.
|
|
|
|
|
|
If any team member votes "-1", the proposal does not pass.
|
|
|
|
|
|
If less than half of the team votes "+1", the proposal does not
|
|
|
pass.
|
|
|
|
|
|
If the proposal receives "+1" votes from at least half of the
|
|
|
team, and it receives no "-1" votes, it passes.
|
|
|
|
|
|
When a proposal passes, it becomes _provisional_ policy. A
|
|
|
provisional policy. A provisional policy remains provisional for
|
|
|
three months, and then is accepted as policy. While a policy is
|
|
|
provisional, any member may veto it by changing their vote to
|
|
|
"-1". Afterwards, when the policy is no longer provisional,
|
|
|
changing it requires another policy proposal.
|
|
|
|
|
|
When a draft becomes policy or provisional policy, we put it on
|
|
|
our Wiki.
|
|
|
|
|
|
4. Who are the voters?
|
|
|
|
|
|
The voters are the Tor staff on the network team, and the associated
|
|
|
PM. As of adoption, this is ahf, asn, catalyst, dgoulet, gaba,
|
|
|
mikeperry, nickm, and teor. We can amend this later with policy
|
|
|
proposals.
|
|
|
}}} |
|
|
\ No newline at end of file |