The RFC (request for comments) is a structured document that allows community members to propose an idea to everyone before it is implemented. RFCs enable stakeholders to be aware and confident about the direction PyTorch is evolving in.
Many 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, please open an issue in the main PyTorch repository first to discuss.
In short, to get a major feature added to PyTorch, one must first get the RFC merged into the RFC repository as a markdown file. At that point the RFC is "active" and may be implemented with the goal of eventual inclusion into PyTorch.
- Fork the rfcs repo: https://github.com/pytorch/rfcs
- Copy
RFC-0000-template.mdtoRFC-00xx-my-feature.md, or write your own open-ended proposal. Put care into the details. - Submit a pull request titled
RFC-00xx-my-feature.- Assign the
draftlabel while composing the RFC. You may find it easier to use a WYSIWYG editor (like Google Docs) when working with a few close collaborators; feel free to use whatever platform you like. Ideally this document is publicly visible and is linked to from the PR. - When opening the RFC for general discussion, copy your document into the
RFC-00xx-my-feature.mdfile on the PR and assign thecommentinglabel.
- Assign the
- Build consensus for your proposal, integrate feedback and revise it as needed, and summarize the outcome of the discussion via a resolution template.
- If the RFC is idle here (no activity for 2 weeks), assign the label
stalledto the PR.
- If the RFC is idle here (no activity for 2 weeks), assign the label
- Once the discussion has settled, assign a new label based on the level of support:
acceptedif a decision has been made in the RFCdraftif the author needs to rework the RFC’s proposalshlevedif there are no plans to move ahead with the current RFC’s proposal
- A state of
acceptedmeans that the core team has agreed in principle to the proposal, and it is ready for implementation. - The author (or any interested developer) should next open a tracking issue on Github corresponding to the RFC.
- This tracking issue should contain the implementation next steps. Link to this tracking issue on the RFC (in the Resolution > Next Steps section)
- Once all relevant PRs are merged, the RFC’s status label can be finally updated to
closed.
Before working on an RFC, it might be useful to gauge interest by posting on either PyTorch Issues, the developer forum, or the Slack channel. Identifying interested stakeholders (CODEOWNERS) early on can ease consensus building.
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.