tqchen edited a comment on pull request #2: URL: https://github.com/apache/tvm-rfcs/pull/2#issuecomment-825933735
One concern is the need to move RFC text around depending on its implementation status. In practice it would add additional maintainace overheads and also loses the history of the RFC moditication. Per Rust RFC process, merging an RFC means that the community has get consensus on the design and desired way of improvements. Ideally the concensus of the design should be independent from the implementation status. Ideally the path to the text should not change after the RFC has been merged. The actual state of implementation can be tracked in somewhere else(e.g. a tracking issue) independent from the RFC repo(which reflects the consensus on the design). Alternatively, an RFC itself could contain a short status section that shows (proposed, implemented). I would be cautious marking an accepted RFC as postponed unless the design decision is superseded and no longer holds, in which case we might mark the rfc as abandoned. An implementation of RFC can happen soon, after a few month depending on the progress, they can also happen asynchrously given that apache-style development is quite asynchrous. -- 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: us...@infra.apache.org
