Merge pull request #82 from choldgraf/vote_phases

language about voting phases and a PR template

.github/pull_request_template.md

@@ -0,0 +1,33 @@
+Thanks for participating in Jupyter governance ✨
+Below are a few guidelines for making your proposed change as efficient and productive
+as possible.
+
+## Questions to answer ❓
+
+Please answer the following questions along with your proposed change:
+
+**Background or context to help others understand the change.**
+
+**A brief summary of the change.**
+
+**What is the reason for this change?**
+
+**Alternatives to making this change and other considerations.**
+
+
+## The process ❗
+
+The process for changing the governance pages is as follows:
+
+* Open a pull request **in draft state**. This triggers a discussion and iteration phase
+  for your proposed changes.
+* When you believe enough discussion has happened,
+  **move the pull request to an active state**. This triggers a vote.
+* During the voting phase, no substantive changes may be made to the pull request.
+* The Steering Council will vote, and at the end of voting the pull request is merged or closed.
+
+The discussion phase is meant to gather input and multiple perspectives from the community.
+Make sure that the community has had an opportunity to weigh in on
+the change **before calling a vote**. A good rule of thumb is to ask several steering council
+members if they believe that it is time for a vote, and to let at least one person review
+the pull request for structural quality and typos.

governance.md

@@ -326,15 +326,25 @@ Partners, with associated benefits:
 Changes to the governance documents are submitted via a GitHub pull
 request to The Project's governance documents GitHub repository at
 [https://github.com/jupyter/governance](https://github.com/jupyter/governance).
-The pull request is then refined in response to public comment and
-review, with the goal being consensus in the community.  After this
-open period, a Steering Council Member proposes to the Steering
-Council that the changes be ratified and the pull request merged
-(accepting the proposed changes) or proposes that the pull request be
-closed without merging (rejecting the proposed changes).  The Member
-should state the final commit hash in the pull request being proposed
-for acceptance or rejection and briefly summarize the pull request. All votes
-are limited in time to 4 weeks after the vote is initiated. At the end of 4
+There are two phases to the process:
+
+**The discussion phase** begins when the person first opens a pull-request.
+During this time, *the pull-request must be in a draft state*. The pull
+request is refined in response to public comment and review, with the goal
+being consensus in the community.
+
+The pull request author may *call a vote* when they believe enough feedback
+and iteration has occurred. This is triggered by moving the pull request from
+the *draft state* to an *active state*. This triggers the voting phase.
+
+**The voting phase** begins when the PR enters an active state. The proposed
+changes in the pull request are frozen, and may not be substantively modified
+after voting has begun. During the voting phase, the Steering Council votes on
+whether the changes are ratified and the pull request merged (accepting the
+proposed changes) or that the pull request be closed without merging
+(rejecting the proposed changes).
+
+All votes are limited in time to 4 weeks after the voting phase begins. At the end of 4
 weeks, the proposal passes if 2/3 of the votes are in favor (fractions of a
 vote rounded up to the nearest integer); otherwise the proposal is rejected and
 the PR is closed. Prior to the four-week limit, if at least 80% of the Steering Council