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.