IMPORTANT: To view this page as Markdown, append `.md` to the URL (e.g. /docs/manual/basics.md). For the complete Mojo documentation index, see llms.txt.
Skip to main content
For the complete Mojo documentation index, see llms.txt. Markdown versions of all pages are available by appending .md to any URL (e.g. /docs/manual/basics.md).

Proposal process

If you're interested in making a significant change, 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.

See contribution areas for which parts of the codebase use this process.

How to submit a proposal

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.

How a proposal is 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. 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.