comaniac commented on a change in pull request #2: URL: https://github.com/apache/tvm-rfcs/pull/2#discussion_r605857254
########## 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 Review comment: Ah sorry I think I misunderstood it before. I supposed "Merging RFC" meant merging the first PR of the RFC. I realized that "Merging RFC" here means the RFC is committed and the author can start filing PRs. Then it makes sense to have the flow like "merging RFC" -> "file a tracking issue" -> "file PRs and update the issue". -- 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]
