Welcome to the Mojo community! 🔥 We’re very excited that you’re interested in contributing to the project. To help you get started and ensure a smooth process, we’ve put together this contributor guide.
There are many ways to contribute to the project, from joining the Discord community, to filing bugs, to contributing documentation, examples, or code.
Reporting issues is a great way to contribute to the project. Mojo uses GitHub Issues for tracking bugs.
Keep in mind that bugs with a reproducible test case and well-written supporting documentation are considered a higher priority. Ensure that reproducible steps are the smallest possible to maximize contributor time.
Also, before opening a new issue, take a moment to search through the already submitted issues to avoid creating duplicate issues for the maintainers to address.
We encourage you to provide as much information about the issue as practical. The more details you provide, the faster we can resolve the issue. The following is a template of the information that should accompany every submitted issue.
We’re happy to accept pull requests for the docs and examples. If your change is any one of the following, please create a pull request and we will happily accept it as quickly as possible:
Before embarking on any major change, please create an issue or start a discussion, so we can collaborate and agree on a solution.
For example, refactoring an entire code example or adding an entire new page to the documentation is a lot of work and it might conflict with other work that’s already in progress. We don’t want you to spend time on something that might require difficult reviews and rework, or that might get rejected.
See Pull Requests for information on creating your first pull request.
The standard library team is dedicated to creating a vibrant technical community around the Mojo programming language. Our vision includes a diverse and inclusive environment where developers are motivated to contribute to the growth of the Mojo package ecosystem with a myriad of community-driven additions.
For more information on our priorities, see the following documents:
For technical details on developing for the standard library, see the following documents:
To ensure a streamlined process, contributors are encouraged to focus on enhancements, bug fixes, and optimizations aligned with the library's overarching goals. These guidelines aim to facilitate a collaborative environment where contributors and the standard library team can work together effectively toward the continued improvement of Mojo.
These changes are uncontroversial, easier to review, and more likely to be accepted:
FileCheck
to using assert_*
functions from the
testing
module.Changes that don’t align with our vision and roadmap are unlikely to be accepted. For example:
We ask that contributors make pull requests as small as possible. When you are opening a pull request, check the number of lines modified in GitHub. The smaller the better (but don't exclude the tests or docstrings). If your pull request is over 100 lines, please try to split it into multiple pull requests. If you make them independant, it's even better as no synchronization will be needed for the merge.
This guideline is here for the following reasons:
Smaller pull requests means less work for the maintainers and faster reviews and merges for the contributors. It's a win-win!
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 proposals process ensures feedback from the widest possible set of community members and serves as an audit log of past proposal changes with most importantly the rationale behind it.
Proposals consist of a GitHub Pull Request that adds a
document to the proposals/
directory. Contributors are
encouraged to react with a thumbs-up to proposal PRs if they are generally
interested and supportive of the high-level direction. These are assigned to
Mojo standard library leads to decide. The 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 the proposal,
the reviewing lead should explain why and close the PR.
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 the process.
You can use a pull request to propose a change or bug fix to the Mojo Standard Library, Mojo examples, or Mojo documentation. This page gives an overview of the process. For a more detailed walkthrough, see How to contribute to the Mojo standard library: a step-by-step guide.
Note: Pull requests should be submitted against the nightly
branch,
which represents the most recent nightly build.
Before you start your first pull request, please complete this checklist:
We want to be sure that you spend your time efficiently and prepare changes that aren’t controversial and get stuck in long rounds of reviews. See the sections on Contributing to Docs and Examples and Contributing to the standard library for more details.
Go to the Mojo repo and click the fork button:
Clone your forked repo locally with the command:
git clone git@github.com:[your-username]/mojo.git
cd mojo
Add the upstream remote and fetch it:
git remote add upstream git@github.com:modularml/mojo.git
git fetch upstream
Make sure to branch off nightly
to work on your PR:
git checkout upstream/nightly
git checkout -b my-fix-pr
You should periodically make sure you've synced the latest changes, especially before raising a PR:
git fetch upstream
git rebase upstream/nightly
Now that you're on the nightly branch, you need to install the latest nightly Mojo compiler:
curl https://get.modular.com | sh -
modular auth
modular install nightly/mojo
If you already have an older nightly/mojo
compiler, replace
modular install nightly/mojo
with modular update nightly/mojo
.
Then, follow the instructions from the modular
tool in adding the mojo
compiler to your PATH
such as:
echo export MODULAR_HOME="$HOME/.modular" >> ~/.zshrc
echo 'export PATH="$HOME/.modular/pkg/packages.modular.com_nightly_mojo/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
If you're using bash, replace the three ~/.zshrc
above with ~/.bashrc
.
Install the Mojo nightly VS Code extension:
You can only have one Mojo extension enabled at a time, remember to switch back when using the stable release!
If your change is one of the improvements described above or it has been
discussed and agreed upon by the project maintainers, please create a pull
request into the nightly
branch.
First push your changes:
git push -u [your-username] my-fix-pr
You'll see a link to create a PR:
remote: Create a pull request for 'my-fix-pr' on GitHub by visiting:
remote: https://github.com/jackos/mojo/pull/new/my-fix-pr
Make sure you point it to the nightly
branch:
Now fill out the details:
Signed-off-by
line, as per the
Developer Certificate of Origin.Note: Accepted changes will generally show up in the release build (or on the website) for the next major release.
Thank you for your contributions! ❤️
For each pull request, we require that you certify that you wrote the change or otherwise have the right to pass it on as an open-source patch by adding a line at the end of your commit description message in the form of:
Signed-off-by: Jamie Smith <jamie.smith@example.com>
You must use your real name to contribute (no pseudonyms or anonymous
contributions). If you set your user.name
and user.email
git configs, you
can sign your commit automatically with git commit -s
.
Doing so serves as a digital signature in agreement to the following Developer Certificate of Origin (DCO):
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
The team commits to reviewing submitted pull requests within a week of submission.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。