This document describes the technical process for accepting a proposal, assuming the proposal has gone through the proposal process.
Before accepting, the shepherd should check for the following (extracted from the review criteria):
- Is the proposal self-standing? It should not refer explicitly to the GitHub trail, for instance.
- Is the proposal precise? The specification section should fully describe
the proposal payload. In particular:
- If there is new syntax, is it described in BNF notation?
- If applicable, are there typing rules? If there are not, could typing rules be reasonably extracted from the proposal text?
- Are any changes to runtime behavior precisely specified?
- Is there a reasonable description of how the new feature might be documented in Haddock? Linted by HLint? Treated by other tools? (These will not apply to every proposal.)
- Is the proposal sufficiently illustrated with examples? Examples help us understand the details that will be needed during implementation.
A committee member accepts a proposal by following this sequence of steps:
- Add a new commit on top of the PR branch that:
- Changes the filename of the proposal to correspond to the PR number.
- Updates any metadata fields that may have changed in the template on
mastersince the PR branch split off. - Fills in these metadata fields as appropriate, including changing "is discussed" to "was discussed".
- Merge the PR branch into master, and push.
- Update the PR description to start with the text "The proposal has been accepted; the following discussion is mostly of historic interest." where the word "proposal" links to the final rendered version, as found on https://github.com/ghc-proposals/ghc-proposals/tree/master/proposals
- If the PR title has "(under review)", remove it.
- Set the PR to have the "Accepted" label.
- Comment on the PR that the proposal was accepted.
- Close the PR if GitHub has not detected the merge.
- Announce on the committee mailing list.