You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Making everything reachable from the <./README.rst> file directly.
Also be very clear that the PR author has to invoke the review process
after the discussion has ended, and has to do so by notifying the
secretary (currently @nomeata).
Authors no longer have to handle labels, as they cannot do that anyways.
Each proposal document must follow the following outline. A template is provided in `proposal template <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0000-template.rst>`_.
69
+
70
+
a. *Motivation*: Give a strong reason for why the community needs this change. Describe the use case as clearly as possible and give at least one concrete example. Explain how the status quo is insufficient or not ideal.
71
+
72
+
b. *Proposed Change Specification*: Specify the change in precise and comprehensive yet concise language. Your specification may include,
73
+
74
+
- grammar and semantics of any new syntactic constructs
75
+
- the types and semantics of any new library interfaces
76
+
- how the proposed change addresses the original problem (perhaps referring back to the example)
77
+
78
+
c. *Effect and Interactions*. Detail how the proposed change addresses the original problem raised in the motivation. Detail how the proposed change interacts with existing language or compiler features. Think about what surprising or problematic interactions may occur.
79
+
80
+
d. *Costs and Drawbacks*. What are the drawbacks and costs to the community should this change be implemented? For example, does this make Haskell harder to learn for novice users? Does it make Haskell code harder to read or reason about? Will the implementation be complex or invasive?
81
+
82
+
e. *Alternatives*: List alternatives to your proposed change and discuss why they are insufficient.
83
+
84
+
f. *Unresolved questions*: Explicitly list any remaining issues that remain in the conceptual design and specification. Be upfront and trust that the community will help. Please do not list *implementation* issues.
85
+
86
+
g. *Implementation Plan* (Optional): If accepted who will implement the change? It's quite okay to say "unknown" if you don't feel willing or able to carry out the implementation yourself.
87
+
88
+
89
+
Note that proposals are written in `ReStructuredText
90
+
<http://www.sphinx-doc.org/en/stable/rest.html>`_ rather than Markdown for its
91
+
expressiveness and ease of integration into other GHC infrastructure. See the
The instructions below are intended for users with little experience using
5
+
GitHub and git.
6
+
7
+
Forking repositories
8
+
^^^^^^^^^^^^^^^^^^^^
9
+
10
+
1. Point your browser to the ``ghc-proposals/ghc-proposals`` repository
11
+
2. Click on "Fork" (in the upper right corner)
12
+
13
+
See GitHub's `documentation <https://help.github.com/articles/fork-a-repo/>`_ if
14
+
you are unfamiliar with GitHub's notion of "forking".
15
+
16
+
17
+
Setting up your proposal fork
18
+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
19
+
20
+
1. Clone the repository to your computer.
21
+
22
+
a. You find the clone command after clicking on "Clone or Download" button.
23
+
b. Open a terminal in the cloned directory.
24
+
25
+
2. Create a new branch for your proposal (say, ``$myproposal``). ::
26
+
27
+
git branch $myproposal
28
+
git checkout $myproposal
29
+
30
+
3. Copy the template to a new file ::
31
+
32
+
cd proposals
33
+
cp 0000-template.rst 0000-$myproposal.rst
34
+
35
+
4. Add the new file to the repository ::
36
+
37
+
git add 0000-$myproposal.rst
38
+
39
+
5. Commit the file with an informative commit message ::
40
+
41
+
git commit -a
42
+
43
+
6. Push your new branch to your GitHub repository ::
44
+
45
+
git push --set-upstream=origin $myproposal
46
+
47
+
You only need to do this once. For all future edits to your proposal you only
48
+
need to commit and push. e.g. ``git commit -a; git push``.
49
+
50
+
51
+
Moving your proposal to the Discussion phase
52
+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
53
+
54
+
In order to submit your proposal to the discussion phase,
55
+
56
+
1. Navigate to the main page of your repository in your browser
57
+
2. Select the branch containing your proposal in the "Branch:" drop-down
58
+
3. Click on "Compare & pull request" button
59
+
4. You will be brought to the "Open a pull request" page. Ensure that ``ghc-proposals/ghc-proposals`` is specifed as the "base fork" and that ``master`` is specified as the "base branch".
60
+
5. Verify that the diff shown only contains your proposal document.
61
+
6. In the "comment" box at the top of the page write a brief description of your proposal along with a link to the proposal document (link to the ``0000-$myproposal.rst`` file in your GitHub fork)
62
+
63
+
.. code-block::
64
+
65
+
This is a proposal augmenting our existing `Typeable` mechanism with a
66
+
variant, `Type.Reflection`, which provides a more strongly typed variant as
0 commit comments