Merge pull request #38 from suraj813/rfc-process

RFC-0024-Process-for-RFC-Shepherding

Author: subramen

README.md

@@ -1,2 +1,67 @@
-# rfcs
-PyTorch RFCs (experimental)
+# PyTorch RFCs
+
+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.
+
+
+## What the process is
+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.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](https://github.com/pytorch/rfcs/blob/rfc-process/RFC-0000-template.md#resolution).
+    - 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
+    - `shleved `if there are no plans to move ahead with the current RFC’s proposal
+- 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`.
+
+
+## Build consensus
+Before working on an RFC, it might be useful to gauge interest by posting on either [PyTorch Issues](https://github.com/pytorch/pytorch/issues), the [developer forum](https://dev-discuss.pytorch.org/c/rfc-chatter), or the [Slack channel](https://bit.ly/ptslack). Identifying interested stakeholders ([CODEOWNERS](https://github.com/pytorch/pytorch/blob/master/CODEOWNERS)) early on can ease consensus building.
+
+
+## Implementing an RFC
+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).
+
+
+## RFC Rejection
+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. 
+
+## Inspiration
+PyTorch's RFC process owes inspiration to the [Rust RFC Process](https://github.com/rust-lang/rfcs) and [React RFC Process](https://github.com/reactjs/rfcs/), and the [Artsy RFC process](https://github.com/artsy/README/blob/main/playbooks/rfcs.md#resolution) for the resolution template.
+
+## License
+By contributing to rfcs, you agree that your contributions will be licensed under the LICENSE file in the root directory of this source tree.

RFC-0000-template.md

@@ -0,0 +1,119 @@
+
+
+<details>
+<summary>Instructions - click to expand</summary>
+
+- 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](https://github.com/pytorch/rfcs/blob/rfc-process/RFC-0000-template.md#resolution).
+    - 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`.
+
+</details>
+
+
+
+
+
+# [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
+<github issue URL>
+
+
+#### Exceptions
+Not implementing on project X now. Will revisit the decision in 1 year.