This page contains instructions on how to propose and implement feature changes to PyTorch.
To propose a new feature, you’ll submit a Request For Comments (RFC). This RFC is basically a design proposal where you can share a detailed description of what change you want to make, why it’s needed, and how you propose to implement it.
It’s easier to make changes while your feature is in the ideation phase vs the PR phase, and this doc gives core maintainers an opportunity to suggest refinements before you start code. For example, they may know of other planned efforts that your work would otherwise collide with, or they may suggest implementation changes that make your feature more broadly usable.
Smaller changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow on the main PyTorch repo.
RFCs are more suitable for design proposals that are too large to discuss on a feature-request issue, like adding a new abstraction, or if a discussion about the tradeoffs involved in a new addition are non-trivial.
If you are unsure whether something should be an RFC or a feature-request issue, you can ask by opening an issue in the main PyTorch/PyTorch repository.
RFCs are located in their own repository.
To create one:
RFC-0000-template.md
to RFC-00xx-your-feature.md
and fill it out with your proposal. The template is a guideline, feel free to add sections as appropriateRFC-00xx-your-feature.md
commenting
label(Note: A proposal may get rejected if it comes with unresolvable drawbacks or if it’s against the long term plans of the pytorch maintiners)
Every accepted RFC has an associated issue tracking its implementation in the PyTorch repository; thus that associated issue can be assigned a priority via the triage process that the team uses for all issues.
The author of an RFC is not obligated to implement it. Of course, the RFC author (like any other developer) is welcome to post an implementation for review after the RFC has been accepted.
If you are interested in working on the implementation for an accepted RFC, but cannot determine if someone else is already working on it, feel free to ask (e.g. by leaving a comment on the associated issue).
Some RFC pull requests are tagged with the "shelved" label when they are closed (as part of the rejection process). An RFC closed with "shelved" is marked as such because we want neither to think about evaluating the proposal nor about implementing the described feature until some time in the future, and we believe that we can afford to wait until then to do so.
PyTorch's RFC process owes inspiration to the Rust RFC Process and React RFC Process, and the Artsy RFC process for the resolution template.
By contributing to rfcs, you agree that your contributions will be licensed under the LICENSE file in the root directory of this source tree.