Andrew Boardman
--- a/proposals.md 0 → 100644

+ 87

− 0
+++ b/proposals.md 0 → 100644

+ 87

− 0
+# Lifecycle of Haskell Foundation Proposals
+
+## Purpose
+
+This document lays out how the proposal process works for the Haskell Foundation (HF).
+
+A proposal is any change that someone would like to see in the way that the HF operates:
+* Policy - Changes in the rules governing what the HF can and cannot do.
+* Process - Changes in the way the HF makes things happen.
+* Projects - Adding, removing, or changing the HF's support of a project.
+* Grants - Adding, removing, or changing the HF's financial support.
+
+## Proposals vs. Issues
+
+If a contributor has an idea for change, but that idea is not yet fully-formed into a proposal,
+they should open a new Issue (not a Merge Request) in the [proposals](https://gitlab.haskell.org/hf/proposals)
+repo. The community can then work to refine that idea into a proposal, eventually making an
+MR. Issues will not be submitted to the Board for approval, as
+the approval process requires the details that comprise a proper proposal.
+
+## Creation
+
+Proposals are created as Merge Requests in the [proposals](https://gitlab.haskell.org/hf/proposals) repository of the [Haskell GitLab](https://gitlab.haskell.org/). Create a markdown file with an appropriate name, define the proposal as described below, and open an MR when you are ready for comments and review.
+
+We recommend anyone who wishes to make a proposal find a Board or Executive Team sponsor.
+
+## Format
+
+The following is the recommending format:
+
+### Objective
+
+A short summary of the problem to be solved, and how this proposal solves it.
+
+### Motivation
+
+What is the problem being solved?
+
+### Current State
+
+What is the current state of affairs addressed by this proposal, and what is
+the impact if the proposal is not accepted?
+
+### Description
+
+Detailed description of what is being proposed, and the supporting evidence
+that it will be effective.
+
+### Alternatives
+
+What other reasonable approaches could be taken instead? What are the pros
+and cons?
+
+### Why the Haskell Foundation?
+
+Why is this proposal being made to the HF, rather than some other group?
+What unique value does the HF bring?
+
+### How to Measure Success
+
+What techniques will be used to measure if this proposal was successful?
+This needs to be part of the implementation strategy, so we can have the
+data to inform future HF decisions.
+
+## Community Notification and RFC
+
+We encourage authors to post to the [Haskell Discourse](https://discourse.haskell.org/) under the Haskell Foundation topic with the initial text and a link to the MR.
+
+## Review and Commentary
+
+Feedback, commentary, dissent, and change requests are handled in the merge request. In particular, they should be comments at the line of the document in question.
+
+Discussions on Discourse and social media platforms are encouraged, however no one working on the proposal nor members of the HF are required to read or incorporate feedback outside the merge request itself.
+
+## Official Board Vote
+
+Board members are the Executive Team have approval rights for the Proposals repo. When the proposers are ready they notify the Board, by sending email to the [Board mailing list](mailto:board@haskell.foundation), that the merge request is ready for a final up or down vote.
+
+Any Board member who votes no is requested to add a comment to the MR with their reservations.
+
+### Board Meeting Vote
+
+We expect that gitlab approval recording is sufficient to not require other Board voting mechanisms.
+
+## Merger
+
+Once the voting is finished by whichever mechanism, a successful proposal will be merged by a member of the Executive Team or the Board Chairperson into the master branch of the repo and will become official.