Skip to content

Commit 8a2fe52

Browse files
committed
Prepare for the public
1 parent 0895312 commit 8a2fe52

File tree

1 file changed

+34
-10
lines changed

1 file changed

+34
-10
lines changed

Readme.md

Lines changed: 34 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1,16 +1,18 @@
11
# OCaml RFCs
22

33
This repository is for proposals to change the OCaml language
4-
or the internals of its compiler. It currently has a single folder:
4+
or the internals of its compiler.
55

6-
- rfcs
6+
**It is for proposals by people who actually intend to implement the
7+
proposed changes. Feature requests from users of the language should
8+
instead by made as issues on [ocaml/ocaml](https://github.com/ocaml/ocaml)**.
79

8-
## RFCs
10+
## Making an RFC
911

10-
The rfcs folder is for accepted proposals for changes to the
11-
language. Files should be created in this directory via pull requests,
12-
and the merging of those pull requests should only happen once there
13-
is consensus to accept the change in principle.
12+
RFCs are made by creating a pull request that adds a file to the
13+
`rfcs` folder. The `rfcs` folder contains accepted proposals for
14+
changes to the language. The pull request will only be merged
15+
once there is consensus to accept the change in principle.
1416

1517
We'll adjust and adapt the process as we go, but as a starting point
1618
RFCs should provide:
@@ -21,6 +23,28 @@ RFCs should provide:
2123
- Drawbacks of the change and alternatives to the change
2224
- Unresolved questions
2325

24-
Then we can discuss the proposal in the comments of the pull request
25-
and, once consensus is reached, either merge or close the pull
26-
request.
26+
## Discussing an RFC
27+
28+
RFCs will be discussed in the comments of the pull request that
29+
proposes them. Authors should try to respond to queries and integrate
30+
feedback into the RFC document. Commenters should try to avoid
31+
unnecessary bike-shedding.
32+
33+
## Merging an RFC
34+
35+
Once those involved in discussing an RFC think that it is ready to be
36+
considered for approval they can nominate it for consideration at the
37+
next developers meeting. At that meeting a decision will be made to
38+
either:
39+
40+
- Accept the proposal and merge the RFC
41+
42+
- Reject the proposal and close the RFC
43+
44+
- Request further changes/discussion on the RFC before reconsidering
45+
at another meeting.
46+
47+
Once an RFC has been accepted into the repository authors can begin
48+
implementing the proposal and be reasonably confident that a suitable
49+
implementation of the feature will be accepted upstream into the
50+
compiler.

0 commit comments

Comments
 (0)