Updating our contribution process for the Mojo stdlib

Mojo
1

Community contributions to the Mojo :fire: stdlib have been one of the best parts of building this language in the open. We want to keep that going, and make it less likely that your work sits unreviewed or stalls out.

Starting with the 26.3 release, we’re asking contributors to open an issue before submitting non-trivial pull requests to the standard library, so that the team can align on the change before contributors start implementation work.

Why we’re doing this

We’ve seen too many contributors put real effort into a change, only to have it sit in the queue because it wasn’t quite what we needed, or because we didn’t have bandwidth to review it at that moment. That’s a frustrating experience, and we want to do better.

An issue upfront enables us to have a quick conversation about fit before anyone writes code, and it means you get a clear signal from us before you invest the time. Several other large open source projects use the same approach for the same reason.

This policy applies to new non-trivial stdlib PRs going forward. If you already have an open PR, you do not need to close it and reopen an issue just to satisfy the new process. However, the team may ask to move design discussion into an issue if the PR raises larger API or architectural questions and may close PRs that won’t be accepted.

What counts as trivial

Typos, doc clarifications, and small, obvious bug fixes don’t need an issue. Go ahead and open a PR directly for those. If you’re adding functionality, changing behavior, or touching architecture, please open an issue first.

How it works

  1. Open an issue describing what you want to change.
  2. Wait for the accepted label. That’s us saying “yes, please build this.”
  3. Write the code and open your PR with a link back to the issue.

The updated PR template will walk you through this, including a “Type of change” checklist to help frame the contribution.

We also recognize that requiring an issue first only works if issues get timely attention from the stdlib team. As part of this change, we’re going to be more intentional about triaging stdlib issues, giving early feedback, and marking accepted work clearly so contributors are not left guessing whether a proposed change is wanted. The goal is not to move the bottleneck from PRs to issues, but to make the conversation happen earlier, when it is still cheap to adjust course. We will respond to issues quickly (typically within 48-72 business hours) following conversations internally on a given topic.

Where we want your help for Mojo 1.0

As called out in the Mojo Roadmap, we would love your help in a few different areas that are important to Phase 1 as part of Mojo 1.0:

1. Applying stability markers throughout the standard library. We plan to publish a set of documents in the next week or so covering both the high-level areas we want to stabilize and the low-level details to keep in mind when stabilizing something as a standard library contributor. In the meantime, here are some of the things we plan on stabilizing:

  • Core collections (List, Dict, Set, InlineArray, Optional, String, etc.)

  • Core types such as IntLiteral, StringLiteral, FloatLiteral, Tuple, etc.

  • Core traits

We expect that as we work to stabilize things, we’ll do a bit of a “depth first search” that requires auditing APIs, ensuring consistency of identifiers and parameter naming, and validating the module location before we mark something @stable. This will naturally spawn more work/GitHub issues as we march toward stabilizing more of the library together. Note that many APIs can’t be @stable yet until we finish the SIMD unification with Int work, which is in progress.

2. Explore removing custom-Self types on methods
a. We are considering removing this language feature, so it would be valuable to audit APIs and determine what concrete language enhancements we’d need to replace or rework some of these.

3. Improvements to our Python-Mojo interop story
a. Examples include https://github.com/modular/modular/pull/6453
b. As function reflection comes into place (which we’re working on now), we expect several things to be simplified/cleaned up in this area of the library. There will likely be other spots in the stdlib that benefit from function reflection as well.

A note on the future

This is the right policy for right now, not necessarily forever. As we ship 1.0 and the codebase stabilizes, we’ll revisit the issue-first requirement for contributions that aren’t on the roadmap.

Please share any questions about this new policy change in the thread. Thanks for your continued collaboration!

2

Does it make sense to move towards something more like a proper RFC/PIP process for large changes (new datastructures, major language capabilities, etc)? We have proposals but those don’t get as much discussion as they probably should because you need to be watching the repo to see many of them.

3

+1 to this as well. Especially with the compiler on the brink of being open sourced, being able to refine a solid RFC process will be valuable as the compiler devs/team will absolutely need one for people who want to introduce new language features.

4

With coding agents lowering the cost of an implementation, sometimes an implementation is worth many words. I find it sometimes easier to explain my ideas with a working implementation. It also avoids the floating question “are you sure this is possible?”.

If the user is aware that the coding effort can be wasted time, and if it’s clear for the maintainers that they don’t need to review, just judge the proposal, then I don’t think it’s an issue to submit a big pull request.

If it’s my coding agent who is wasting its time coding, I don’t mind at all. Maybe there is a way we could communicate that we’re not asking for a code review?