# Add a "discussion" and "voting" period to proposed changes

## Background

In [a recent proposed change](https://github.com/jupyter/governance/pull/77), an issue arose where discussion and edits to the PR happened **after** some people had already voted. This brought up two challenges:

* It was unclear whether these notes were nullified (or whether they _should_ be nullified).
* It was unclear to newcomers to the discussion [what they were voting on](https://github.com/jupyter/governance/pull/77#issuecomment-628170461).

This PR tries to improve upon both of these issues with a slight modification to the voting process. It follows two main principles:

* When people vote, it should be clear what they’re voting on, and the content of the proposed change shouldn’t be changed after they vote.
* When people haven’t been closely following a topic, they should have quick access to the current state of conversation, and more importantly to the current thing they’re voting on.

## A summary of the proposed solution

This proposal adds a **discussion phase** to the process. During the discussion phase, the PR is in a *draft state* and feedback, iteration, and edits are encouraged.

The PR author can call a vote at any point, at which point the PR leaves "draft" phase and enters the "active" state. At this point, no edits are allowed to the PR, and input from the SC is encouraged to be in the form of voting rather than lengthy discussion.

The aim is to make it clearer when a change is in "discussion phase" vs. "voting phase", and to provide guidelines that make these phases more efficient and easier to participate in.

It also adds a pull-request template with language to try and encourage positive and productive voting.

## A summary of the proposed change

This proposal implements an extra "step" in proposing a change to Jupyter Governance. The _current_ process is:

* A person opens a PR in the governance repo
* A combination of voting, discussing, and editing happens
* Enough votes happen and a decision is made

This proposal aims to explicitly separate the "discussion" and "voting" phases of a proposed change. The new process has these main steps:

- A PR is opened in a draft phase for deliberation and discussion
- When the PR is ready for voting, it goes out of draft phase
- This begins the 4 week voting window
- Substantive changes are no longer allowed on the PR (typos etc are fine)
- If a material change happens, it needs to happen in a new pull request

* **Discussion phase**. This is initiated when a person opens a **Draft PR** in the governance repo. While in draft mode, comments, discussion, and changes are welcome to the PR. The goal of this stage is to get input from the community.
* **Transition to voting**. At any point, the author may initiate a vote by moving the PR out of "draft" status.
* The decision to move to the voting phase is up to the author - they are expected to allow for enough feedback that other members have enough information to cast a vote.
* **Voting phase**. When this happens, **no more changes to the PR may be made**.
* If any edits must happen, the PR must re-enter Draft mode and the voting process is reset. It begins again when the PR becomes active again.
* Large discussion is discouraged at this point - that should have happened in the draft stage. However, if major new points are brought up then the author must update the top-level comment with these perspectives.
* If the content of the PR changes in a material way (more substantially than fixing typos). Then the PR must enter back into a "draft" stage again, and votes are nullified. The author may re-start the voting phase again at their discretion
* Once the voting phase begins, a decision is made according to the current Jupyter Governance practices.

In addition, this PR adds in a **Pull Request Template** to guide those proposing a change. It's goal is to make it clear what information will result in useful conversation. It has the following fields:

* getting feedback on whether it's time to call a vote, summarizing conversation in the top comment, etc

* The PR author must update the top-level comment to reflect and summarize the current state of conversation. Major points brought up during the "draft window" should be mentioned, as well as major pros/cons that were raised.
* The top-level comment must contain a list of "yes/no" checkboxes, one per steering council member. These checkboxes reflect the current state of voting.

# A brief summary of the change

# What is the reason for this change?

# Alternatives to making this change and other considerations