Skip to content

Latest commit

 

History

History
119 lines (79 loc) · 5.02 KB

RFC-0000-template.md

File metadata and controls

119 lines (79 loc) · 5.02 KB
Raw
Instructions - click to expand
  • Fork the rfcs repo: https://github.com/pytorch/rfcs
  • Copy RFC-0000-template.md to RFC-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 draft label 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.md file on the PR and assign the commenting label.
  • 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 stalled to the PR.
  • Once the discussion has settled, assign a new label based on the level of support:
    • accepted if a decision has been made in the RFC
    • draft if the author needs to rework the RFC’s proposal
    • shelved if there are no plans to move ahead with the current RFC’s proposal. We want neither to think about evaluating the proposal nor about implementing the described feature until some time in the future.
  • A state of accepted means 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.

[Title]

Authors:

  • @nickname
  • @nickname

Summary

A short paragraph or bullet list that quickly explains what you're trying to do.

Motivation

What motivates this proposal and why is it important? How should users and developers think about this feature, how would it impact the way PyTorch is used? Explain impact and value of this feature

Proposed Implementation

This is the bulk of the RFC. Explain the design in enough detail for somebody familiar with PyTorch to understand, and for somebody familiar with the implementation to implement. This should get into specifics and corner-cases, and include examples of how the feature is used, and how it will interact with other features. Any new terminology should be defined here. Consider:

  • using examples and diagrams to help illustrate your ideas.
  • including code examples, if you're proposing an interface or system contract.
  • linking to project briefs or wireframes that are relevant.

**Metrics **

What are the main metrics to measure the value of this feature?

Drawbacks

Are there any reasons why we should not do this? Here we aim to evaluate risk and check ourselves.

Please consider:

  • is it a breaking change?
  • Impact on UX
  • implementation cost, both in terms of code size and complexity
  • integration of this feature with other existing and planned features

Alternatives

What other designs have been considered? What is the impact of not doing this?

Prior Art

Discuss prior art (both good and bad) in relation to this proposal:

  • Does this feature exist in other libraries? What experience has their community had?
  • What lessons can be learned from other implementations of this feature?
  • Published papers or great posts that discuss this

How we teach this

  • What names and terminology work best for these concepts and why? How is this idea best presented?
  • Would the acceptance of this proposal mean the PyTorch documentation must be re-organized or altered?
  • How should this feature be taught to existing PyTorch users?

Unresolved questions

  • What parts of the design do you expect to resolve through the RFC process before this gets merged?
  • What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
  • What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?

Resolution

We decided to do it. X% of the engineering team actively approved of this change.

Level of Support

Choose one of the following:

  • 1: Overwhelming positive feedback.
  • 2: Positive feedback.
  • 3: Majority Acceptance, with conflicting Feedback.
  • 4: Acceptance, with Little Feedback.
  • 5: Unclear Resolution.
  • 6: RFC Rejected.
  • 7: RFC Rejected, with Conflicting Feedback.

Additional Context

Some people were in favor of it, but some people didn’t want it for project X.

Next Steps

Will implement it.

Tracking issue

Exceptions

Not implementing on project X now. Will revisit the decision in 1 year.