@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. -- 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-887764234
