If you're interested in making a significant change to the standard library, one that doesn't fall into the list of changes we accept, your first step is a written proposal. The proposal process ensures feedback from the widest possible set of community members, and it serves as an audit log of past proposals and, most importantly, the rationale behind them.
Examples of changes that need a proposal:
- Adding a new module.
- Adding or changing a trait that library types are expected to conform to.
- Changing an existing public API or its implicit behavior.
- Removing or deprecating a public API.
A proposal is a GitHub pull request that adds a document to the
proposals/
directory. Follow the contribution process to
open it, and the issue and PR etiquette when
discussing it.
Contributors are encouraged to react with a thumbs-up to proposal PRs if they're generally interested in and supportive of the high-level direction.
Note
The proposals/ directory also holds language and compiler design proposals
written by the Modular team. Those are internal design discussions that don't
go through this process, so don't treat them as a template for how a standard
library proposal is reviewed or decided.
Proposals are assigned to Mojo standard library leads to decide. A proposal PR can be merged once the assigned lead approves, all blocking issues have been decided, and any related decisions are incorporated. If the leads choose to defer or reject a proposal, the reviewing lead explains why and closes the PR.
Proposals take longer to review than a code change, because the team needs to discuss them and check they're in line with the overall strategy and vision for the standard library. We aim to review and discuss a proposal within six weeks of submission.
This process is heavily inspired by the process used by several other open source projects. We'll add more documentation in the future as we gain experience with it.