docs/source/community/contribution_guide.md
This page has been deprecated. Please refer to the [Contribution Guide](https://github.com/pytorch/pytorch/wiki/The-Ultimate-Guide-to-PyTorch-Contributions) on the PyTorch Wiki.
PyTorch is a GPU-accelerated Python tensor computation package for building deep neural networks using a tape-based autograd systems.
The PyTorch organization is governed by {doc}PyTorch Governance <governance>
and the technical guide to contributing
can be found in CONTRIBUTING.md.
The PyTorch development process involves a healthy amount of open discussions between the core development team and the community.
PyTorch operates similarly to most open source projects on GitHub. However, if you've never contributed to an open source project before, here is the basic process.
Figure out what you're going to work on. The majority of open source contributions come from people scratching their own itches. However, if you don't know what you want to work on, or are just looking to get more acquainted with the project, here are some tips for how to find appropriate tasks:
Figure out the scope of your change and reach out for design comments on a GitHub issue if it's large. The majority of pull requests are small; in that case, no need to let us know about what you want to do, just get cracking. But if the change is going to be large, it's usually a good idea to get some design comments about it first by submitting an RFC.
If you don't know how big a change is going to be, we can help you figure it out! Just post about it on issues or dev discuss.
Some feature additions are very standardized; for example, lots of people add new operators or optimizers to PyTorch. Design discussion in these cases boils down mostly to, "Do we want this operator/optimizer?" Giving evidence for its utility, e.g., usage in peer reviewed papers, or existence in other frameworks, helps a bit when making this case.
Core changes and refactors can be quite difficult to coordinate since the pace of development on the PyTorch main branch is quite fast. Definitely reach out about fundamental or cross-cutting changes; we can often give guidance about how to stage such changes into more easily reviewable pieces.
Code it out!
Open a pull request.
Iterate on the pull request until it's accepted!
New feature ideas are best discussed on a specific issue. Please include as much information as you can, any accompanying data, and your proposed solution. The PyTorch team and community frequently review new issues and comments where they think they can help. If you feel confident in your solution, go ahead and implement it.
If you've identified an issue, first search through the list of existing issues on the repo. If you are unable to find a similar issue, then create a new one. Supply as much information you can to reproduce the problematic behavior. Also, include any additional insights like the behavior you expect.
If you want to fix a specific issue, it's best to comment on the individual issue with your intent. However, we do not lock or assign issues except in cases where we have worked with the developer before. It's best to strike up a conversation on the issue and discuss your proposed solution. The PyTorch team can provide guidance that saves you time.
Issues that are labeled first-new-issue, low, or medium priority provide the best entrance points and are great places to start.
A great deal of the tutorials on pytorch.org come from the community itself and we welcome additional contributions. To learn more about how to contribute a new tutorial you can learn more here: PyTorch.org Tutorial Contribution Guide on GitHub
We aim to produce high quality documentation and tutorials. On rare occasions that content includes typos or bugs. If you find something you can fix, send us a pull request for consideration.
Take a look at the Documentation section to learn how our system works.
You can find active discussions happening on the PyTorch Discussion Forums for users as well as the PyTorch Dev Discussion Forums for developers and maintainers.
You can view a list of all open issues here. Commenting on an issue is a great way to get the attention of the team. From here you can share your ideas and how you plan to resolve the issue.
For more challenging issues, the team will provide feedback and direction for how to best solve the issue.
If you're not able to fix the issue yourself, commenting and sharing whether you can reproduce the issue can help the team identify problem areas.
We appreciate your help reviewing and commenting on pull requests. Our team strives to keep the number of open pull requests at a manageable size, we respond quickly for more information if we need it, and we merge PRs that we think are useful. However, due to the high level of interest, additional eyes on the pull requests are always appreciated.
Improving code readability helps everyone. It is often better to submit a small number of pull requests that touch a few files versus a large pull request that touches many files. Starting a discussion in the PyTorch forum here or on an issue related to your improvement is the best way to get started.
Additional test coverage is appreciated.
Your use of PyTorch in your projects, research papers, write ups, blogs, or general discussions around the internet helps to raise awareness for PyTorch and our growing community. Please reach out to [email protected] for marketing support.
If you feel that an issue could benefit from a particular tag or level of complexity, comment on the issue and share your opinion. If you feel an issue isn't categorized properly, comment and let the team know.
If this is your first time contributing to an open source project, some aspects of the development process may seem unusual to you.
(common-mistakes-to-avoid)=
Did you add tests? (Or if the change is hard to test, did you describe how you tested your change?)
We have a few motivations for why we ask for tests:
When is it OK not to add a test? Sometimes a change can't be conveniently tested, or the change is so obviously correct (and unlikely to be broken) that it's OK not to test it. On the contrary, if a change seems likely (or is known to be likely) to be accidentally broken, it's important to put in the time to work out a testing strategy.
Is your PR too long?
Comments for subtle things? In cases where the behavior of your code is nuanced, please include extra comments and documentation to allow us to better understand the intention of your code.
Did you add a hack? Sometimes, the right answer is a hack. But usually, we will have to discuss it.
Do you want to touch a very core component? To prevent major regressions, pull requests that touch core components receive extra scrutiny. Make sure you've discussed your changes with the team before undertaking major changes.
Want to add a new feature? If you want to add new features, comment your intention on the related issue. Our team tries to comment on and provide feedback to the community. It's better to have an open discussion with the team and the rest of the community before building new features. This helps us stay aware of what you're working on and increases the chance that it'll be merged.
Did you touch code unrelated to the PR? To aid in code review, please only include files in your pull request that are directly related to your changes.
(on-documentation)=
PyTorch documentation is generated from python source using Sphinx. Generated HTML is copied to the docs folder in the main branch of pytorch.org/docs, and is served via GitHub pages.
For C++ code we use Doxygen to generate the content files. The C++ docs are built on a special server and the resulting files are copied to the https://github.com/pytorch/cppdocs repo, and are served from GitHub pages.
PyTorch tutorials are documents used to help understand using PyTorch to accomplish specific tasks or to understand more holistic concepts. Tutorials are built using Sphinx-Gallery from executable python source files, or from restructured-text (rst) files.
For tutorials, pull requests trigger a rebuild of the entire site using CircleCI to test the effects of the change. This build is sharded into 9 worker builds and takes around 40 minutes total. At the same time, we do a Netlify build using make html-noplot, which builds the site without rendering the notebook output into pages for quick review.
After a PR is accepted, the site is rebuilt and deployed using GitHub Actions.