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.


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.


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.



   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

   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.


   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

   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.


   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

   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
Last modified 8 months ago Last modified on Feb 25, 2020, 9:28:53 PM