> @comaniac the RFC in my mind is mainly a design-level description of some > aspect of TVM. Like e.g. PEP, they are meant to be consumed by people less > familiar with the TVM codebase in order to gain familiarity. > > the tracking issue, on the other hand, documents the method and progress by > which the RFC changes were applied to the TVM codebase, as well as serves as > a convenient place to collect limitations (e.g. people can report major, > clearly-related problems, or link downstream issues, and readers can track > the efforts of resolving those things either on the tracking bug or on the > downstream issue). I think that while the RFC should get updated if issues > are discovered during implementation that affect the final result, the log of > PRs submitted to implement an RFC is too much detail for an RFC. > > Tracking issues are pretty easy to categorize, as well--they are clearly > distinct from any other issue and it's not hard for a reviewer to e.g. label > them at the time of merging the RFC. So I'm not sure I see how they will be > problematic to the overall organization. I agree if an RFC is rejected, we > don't lose anything by not opening a tracking issue. I similarly don't think > it's a big deal to have a bunch of closed tracking issues for RFCs in the > event that the issue was opened before the RFC was rejected.
What you mentioned makes sense to me, but it seems not a case at least for the current accepted and reviewed RFCs, and that's why I got this impression: the interface/API/underlying designs are documented in the RFC while the tracking issue only lists the implementation milestones linked to the PRs. If we all agree that the RFC here should retain high-level design without mentioning the interaction between TVM codebase, it would be better to refine the guideline as well as RFC/issue templates. For example, the statement in the Reference-Level explanation section in RFC template has "It is reasonably clear how the feature would be implemented." IMHO, it is inevitable to mention some details in the TVM codebase to make a clear explanation. On the other hand, my experience is that although one may propose a 100% reasonable RFC, the implementation is totally not acceptable. That's why I personally consider it would be better to also discuss the implementation in the RFC. We just need to make a clear claim that this part is highly related to TVM codebase and encourage readers to skip the section if they just want to know the high-level idea. Anyways, it seems a bit off to discuss the scope of RFC and tracking issue in this PR. In summary, what this PR wants to make sure is that tracking issues are opened before merging RFCs. The topic of whether to explicitly request authors to open a tracking issue upon filing an RFC PR (i.e., move the **Tracking Issue** step before **Pull Request** in README) can be continued in another PR. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/13#issuecomment-887787785
