This documents the ways of working of the OCaml Language Committee. It is directly inspired by the organizational documents of the GHC Committee.
The goal of the committee is to provide a process by which the OCaml community can decide on the evolution of the OCaml language and its standard library (stdlib). Any member of the OCaml community can submit an idea for consideration by the committee. This should ordinarily be done only when general consensus is elusive; committee approval is not required to make changes to the language or stdlib. The committee will then deliberate and reach an internal consensus. It is hoped that the community will then proceed with the committee's recommendation, but exceptionally may disagree.
The committee is well suited to consider changes to the user interface of OCaml, including both the language and its stdlib. For example, the following changes are definitely in scope:
-
A change or addition to the syntax or semantics of the OCaml language
-
A change or addition to commands in the toplevel
-
A change or addition to the stdlib
Changes that are not necessarily within the scope of the committee include:
-
Changes to compiler-libs
-
Changes to the internal implementation details of the compiler (e.g. refactorings)
-
Changes to compiler flags
It is possible that the OCaml maintainers seek the opinion of the committee on these points, but it is generally not expected. (Compiler flags are part of the interface to the compiler, but one used mostly by other tools that are part of the OCaml ecosystem; those authors will likely have a more nuanced opinion of this part of the compiler's interface than members of the committee.)
In an Issue or PR on this RFCs repo or the ocaml repo, tag the chair of this committee, currently @Octachron, asking for committee consideration. That's it!
After an issue has been tagged for committee attention, the chair chooses a committee member as a shepherd. (This assignment ideally happens within days of the tag.) The chair then labels the issue with Pending shepherd recommendation.
The shepherd's first job is to summarize the question for the committee and make a recommendation of response. Responses need not be "yes" or "no"; sometimes the committee will be asked to choose among several different ideas for syntax, say. The shepherd corresponds with the author until the shepherd understands the issue well enough, and then formulates a summary of this communication and a recommendation. This summary and recommendation are posted to the rest of the committee via the committee's mailing list. The shepherd then sets the label Under consideration. This ideally happens within two weeks of the shepherd assignment.
The committee then debates, either via the mailing list or on the GitHub ticket. (The mailing list, though technically public, is a good place for conversations primarily intended to reach other committee members; the GitHub ticket will attract more responses from the wider community.) Hopefully the committee reaches consensus; the shepherd then posts the committee's response back to the author. If the committee is unable to reach consensus, it votes; if there are many options to consider, it may use a ranked voting algorithm, at the discretion of the shepherd. (That is, the shepherd is broadly empowered to choose the most effective approach toward making a decision for the particular issue at hand.) If there is any vote, the shepherd posts the result of the vote, including information about the strength of the win. Because the decision of the committee is non-binding, reflecting the level of committee support in the final answer may be of interest to the broader community in deciding how to proceed. Once the shepherd posts the committee's answer, the issue is no longer under consideration by the committee, and the Under consideration label is removed. Ideally this step lasts no more than four weeks.
You can reach the committee by email at ocaml-language-committee@inria.fr
. This is a mailing list with
public archives.
The current members, including their GitHub handle, when they joined first, when their term last renewed, when their term expires and their role, are:
Name | Handle | Join Date | Renewal Date | Term End | |
---|---|---|---|---|---|
![]() |
Florian Angeletti (chair) | @Octachron | 2025/01 | 2025/01 | 2028/01 |
![]() |
Nicolás Ojeda Bär | @nojb | 2025/01 | 2025/01 | 2028/01 |
![]() |
Frédéric Bour | @let-def | 2025/01 | 2025/01 | 2028/01 |
![]() |
Richard Eisenberg | @goldfirere | 2025/01 | 2025/01 | 2028/01 |
![]() |
Andrew Kennedy | @andrewjkennedy | 2025/01 | 2025/01 | 2028/01 |
![]() |
François Pottier | @fpottier | 2025/01 | 2025/01 | 2028/01 |
![]() |
Gabriel Scherer | @gasche | 2025/01 | 2025/01 | 2028/01 |
![]() |
Leo White | @lpw25 | 2025/01 | 2025/01 | 2028/01 |
![]() |
Jeremy Yallop | @yallop | 2025/01 | 2025/01 | 2028/01 |
The committee is formed of roughly 9 members of the OCaml community who wish to volunteer for this service. It is our aim that this committee be diverse; by representing different viewpoints, we will make decisions that benefit larger segments of our community.
Specifically, we would like the committee to represent at least the following constituencies:
- OCaml developers
- Authors (whether in print or online)
- Educators
- Industrial users
- Researchers
- Tooling developers
We recognize that we may not always live up to this ideal, but when choosing new members, we aim to correct any imbalances.
The committee has a chair. The chair is responsible for keeping the committee humming along, by dealing with requests and nominating members to consider language proposals. This role is one of service, and we are all grateful to the person who occupies it.
If the chair seems to be lax in their duties, it is the job of the rest of the committee to politely reach out to the chair and offer to let them step down.
The secretary's role is to administer the process for electing new members to the committee, as described below. The secretary also serves as a backup chair, should the chair be away or unavailable to contribute for a fixed period of time.
Officers serve until the end of their term on the committee, or when they choose to step down. When an officer slot is vacant, any member of the committee can self-nominate for the role. In the event of a contested officer slot, the entire committee votes for the officers, as tabulated by the (possibly outgoing) secretary. Votes are sent by direct email to the secretary, in order to be private.
Most official committee business takes place via the ocaml-language-committee@inria.fr
mailing list. The archives of this list are public, and any member of the community may subscribe. It is intended that the list be used by the committee, though community members might be asked to post there during relevant conversations.
Any business not on the public mailing list will be of a sensitive nature, most likely pertaining to individuals. In particular, discussions of selecting new members will not appear on the mailing list.
Any community thrives best by continuing to refresh itself with new members. The main criteria for becoming a member of the committee are:
- A track record of constructive contribution to public discussion of OCaml language and stdlib proposals
- A track record of constructive contribution to one or more of the communities outlined above (users, tool authors, etc)
- An expressed willingness to respond to proposals in a timely manner.
These criteria are not exhaustive -- nominations and self-nominations are free to strengthen the case in whatever way they deem appropriate --- but a record of thoughtful contribution in a public space carries the most weight.
Membership on the committee comes with a three-year term, extended so that a term expires only at the end of a nomination process.
A nomination process is triggered when the number of members is about to drop below 9.
When a nomination process is triggered, the secretary of the committee will put out a public call for nominations for people to join the committee. Nominations include a brief bio of the nominee and reasons why they would be appropriate for the committee. Self-nominations are welcome and expected. Members whose term is due to expire are free to re-nominate themselves. When the secretary's term is about to expire, another (unexpiring) member of the committee fills in for the secretary to run the process for replacing the secretary and any other members, unless the secretary is not being re-nominated and wishes to run the process one last time.
Members of the committee, including those whose term is about to expire, vote on new membership via a ranked voting system, according to the Schulze algorithm. The ranking system includes a method for choosing multiple winners.
The voting process may result in a number of new members not equal to the number of outgoing members. This is fine; the size of the committee is not fixed.
The nomination and voting process is kept private, by using direct email to committee members, not the mailing list.
Any member of the committee is free to step down at any time; such a member may choose to leave the committee immediately or to wait until the end of a nominating process (which would be triggered only when the number of members is about to drop below 9).
There is no process for members of the public at large to directly add or remove committee members. (That is, there is no public vote.) Representative voting across the internet is fraught, and the drawbacks to such a system seem to outweigh any benefits. It is expected that a misbehaving committee (say, one that selects only its friends and ignores other nominations) loses legitimacy and is publicly called into question in an attempt to make changes for the better in its operation.