areusch commented on a change in pull request #2: URL: https://github.com/apache/tvm-rfcs/pull/2#discussion_r616906736
########## File path: README.md ########## @@ -1,6 +1,64 @@ # TVM RFCs -This repoisitory is an evolving repo containing the new RFC process for TVM, more changes to come in next few days. +## What is an RFC? +[what-is-an-rfc]: #what-is-an-rfc +An RFC is a “Request for Change” to the TVM project. It is a design document +that describes a new feature, enhancement, or process to the TVM project. RFCs +should be the primary mechanism for proposing major features and changes. The +author of the RFC is responsible for the discussion of the change, and for +organizing the work around it. RFCs are text files, stored in the [Apache TVM +RFC repository](https://github.com/apache/tvm-rfcs), that serve as history and +documentation of TVM features. +## Who is the audience for RFCs? +[rfc-audience]: #rfc-audience +The primary audience of RFCs is the TVM development community. RFCs serve as a +guide for the design and implementation of features during and after their +development. A secondary audience is general users and developers who are +interested in how and why a feature was designed and implemented. + +## RFC Workflow +[rfc-workflow]: #rfc-workflow + +- **Community Discussion**: A need or issue is brought to the discussion forum. + During this phase, the developer and user community can discuss the need for + and requirements of the RFC +- **Pull Request**: After or concurrent with the conversation on the discussion + forum, a pull request is created using the format prescreibed by the + [RFC Template](https://github.com/apache/tvm-rfcs/blob/c436b06818cb65f72cac821616670b22a2473619/0000-template.md). + - Discussion about the details of the RFC can continue in the pull request. + - A committer of the corresponding area will approve and merge the RFC. + Normally the corresponding committer will become the shepherd of the + implementation PRs. + - RFCs are numbered consecutively based on their order of proposal, + regardless of if they are accepted or postponed. + - A successful RFC will include an overview with the problem the RFC is + attempting to address, a proposed solution that describes the design and + implementation strategy, and a timeline for completion. Optional sections can + include (but are not limited to) alternatives that were considered, security + considerations, and open problems that the RFC does not solve. + - It is expected that RFCs will change, as part of the feedback process and + as new implementation details arise. Changes to the RFC should not be squashed + or force pushed in order to retain change and discussion history. +- **Tracking Issue**: Upon merging a RFC, a tracking issue will be created where + implementors can continue sharing implementation details (including links to + pull requests). The issue will be closed when the RFC is either completed or + abandoned. +- **Implementation**: Work will begin on the RFC, with +pull requests linking back to the tracking issue. Upon completion of the RFC, +the tracking issue will be closed and the RFC will be moved to the +docs/rfc/completed directory. +- **Postponement**: An RFC may be postponed either + explicitly by the parties responsible for implementing it, or implicitly by + having no work done for a period of time defined by project leaders. The RFC + will be moved to the docs/rfc/postponed directory + - **Resuming an Postponed RFC**: Work on a postponed RFC may be resumed by a + new responsible party at any time after another discussion and pull request + review process to move the RFC from docs/rfc/abandoned to docs/rfc/active. + +## References +[references]: #references + +[RFC Discussion Post](https://discuss.tvm.apache.org/t/rfc-update-rfc-process/9033) Review comment: @tqchen I think it would be great to avoid linking to design documentation in the forum (as a goal--this will be impossible in the first few RFCs which will need to reference those posted on past forum topics). However, I think that it's still worth allowing linking to reference e.g. community discussion to understand how each design conclusion was reached. So the line would be: if you're linking to something which describes a design, that needs to be another RFC in the repo (or a past RFC on Discuss which was not yet ported). If you're just linking to additional context around a decision, or to something directly evidenced in a forum post, that's ok. However, we preserve the original goal of fully describing a design in the GH RFCs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
