11# OCaml RFCs
22
33This 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
1517We'll adjust and adapt the process as we go, but as a starting point
1618RFCs 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