• Table of Contents
• What is an RFC
• RFC Audience
• RFC Workflow
• References
• About TVM
• License
• Contribute to TVM

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, that serve as history and documentation of TVM features.

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.

To work on a major feature within the TVM project, an RFC must first be merged into the TVM RFC repository as a markdown file. Once merged, the RFC is considered to be "active" and may be implemented, with the goal of merging the implementation into the TVM project. These are steps that should be taken in the RFC process:

• 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
  • 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 according to the PR number assigned by GitHub in the tvm-rfcs repository. To allocate a new RFC number, open a PR against tvm-rfcs (initially, you might need to use a dummy number in the filename for the RFC content; this can be updated after the RFC PR is created).
  • Legacy RFCs are those RFCs which were accepted prior to forming the tvm-rfcs repo. These will be numbered consecutively, prefixed with the letter L to indicate it is a legacy RFC. For example, L0001.
  • 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. In order to retain change and discussion history, changes to the RFC should not be squashed or force pushed.
  • The formal RFC may link back to the original discussion if there is additional context or discussion, but all of the final feature design must be completely described in the pull request.
• Tracking Issue: When the RFC review is about to merge, a committer should remind authors to open a tracking issue in the main TVM repository with the title "[RFC][Tracking][<RFC-no.>] " and rfc-tracking label (added by a committer), where implementors can continue sharing implementation details (including links to pull requests). The issue will be closed when the RFC is either completed or postponed.
• 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 with the tag "completed". It is not a requirement for the author of an RFC to implement it. The tracking issue will serve as the primary location for communication about the status of RFC implementation. If you are curious about who is working on an RFC, feel free to ask on the comment on the associated issue.
• Changes: It is not uncommon for design changes to be required during or after the initial implementation. If this is the case, the RFC should be updated to reflect the change. In the instance where the change is a significant addition rather than a simple modification, a new RFC should be posted with appropriate tracking issue.
• 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 tracking issue for the RFC will be closed with the tag "postponed".
  • Resuming an Postponed RFC: Work on a postponed RFC may be resumed by a new responsible party at any time after appropriate discussion in the tracking issue. The issue will be reopened, and the "postponed" tag removed.

RFC Discussion Post

Apache TVM is a compiler stack for deep learning systems. It is designed to close the gap between the productivity-focused deep learning frameworks, and the performance- and efficiency-focused hardware backends. TVM works with deep learning frameworks to provide end to end compilation to different backends.

© Contributors Licensed under an Apache-2.0 license.

TVM adopts Apache committer model. We aim to create an open source project that is maintained and owned by the community. Check out the Contributor Guide.