[RFC] RFC Process Update

[hogepodge]

No description provided.

[hsaputra]

Are we not sending the copy of topics from discuss.tvm.apache.org to dev@ mailing list anymore?

I could not find the email copy for the TVM discuss that linked with this PR: https://discuss.tvm.apache.org/t/rfc-update-rfc-process/9033

[hogepodge]

It looks like the forum is being archived. I don't know why that particular topic was missed.

[hsaputra]

Ah, I saw your latest comment from the TVM archiver to dev@ list. Maybe I accidentally delete the previous emails. I think we are still good. Thanks, Chris

[tqchen]

cc @apache/tvm-committers

[areusch]

doesn't have to be part of this change, but very supportive of adding a linter to this e.g. via GH actions or script + docker container. it would also be great to think about a policy as to how to link to things. For example, when linking to other RFCs, should links go to this repo or to the discuss forum?

Related is my comment on identifying RFCs. If RFCs can be easily identified by e.g. a number or name, then linking to them in this repo is also trivial.

[hogepodge]

@areusch @tqchen @jroesch ready for final review

[tqchen]

This seems to be a departure from the rust RFC model https://github.com/rust-lang/rfcs. I would recommend tomake the process more consistent with the rust RFC process(given it is already adopted as a good practice). In particular, a RFC pull request itself can be postponed, but the implementation of RFC should follow a separate process. See https://github.com/rust-lang/rfcs#implementing-an-rfc

Maintaining the state of the RFC implemention inside the rfc repo can also be a maintaince overhead. The status implementation should be tracked in a tracking issue.

Normally some RFCs are implemented immediately and some are done through out a longer process, however, once an RFC is accepted

[jroesch]

I think we just need to resolve @tqchen's comment since I think the request was brought up by @areusch and we can merge.

[hogepodge]

@tqchen @jroesch I updated the process to more closely match the Rust process. A few comments on it:

• I still kept it more lightweight than the Rust process. As a smaller community, I want to strike a balance between formalism and ease of application.
• One major difference is in postponement. The Rust community appears to postpone RFCs before they are merged, adding a tag. This is in contract to TVM postponement, which is meant to capture features that may have been accepted but aren't actively being developed. If this is a point of confusion, I would suggest we change the name to something else. I'm not convinced that the Rust model of postponement is necessary for a project of this size and scope.

[tqchen]

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.

[hogepodge]

Ok, that clears things up for me. Thanks. @tqchen I've updated the PR to move more of the mechanics of handling the RFC into the tracking issue, and deleted the requirements for moving the RFC around.

[tqchen]

Thanks @hogepodge . It looks good to me now. Now that we have close to finalization of the text, would be good to invite more community members to take a look by creating a new discuss post

[hogepodge]

Doesn't look like there's much conversation around this. I'm ready to move forward on it when you think it's appropriate.

https://discuss.tvm.apache.org/t/rfc-preparing-to-launch-new-rfc-process/9838

[tqchen]

cc @apache/tvm-committers final call for feedbacks for 36 hours before we merge and start the formal voting process