Update RFC numbering guidance to use PR number

[areusch]

Hi all,

After some discussion, we'd like to propose that RFCs are numbered according to the GitHub PR number. This follows the idea of documenting those RFCs which are rejected. While it adds an extra step to the initial RFC posting, it simplifies all future references by not allocating two different IDs (PR number and RFC number). It also makes it very easy to find the discussion associated with a given PR when viewing it outside of a PR (e.g. through browsing the tvm-rfcs repo) and makes for one less link to update.

This also has precedent in the rust community.

Sending this PR as a proposal and would like for everyone to discuss/approve/reject this idea here.

@hogepodge @apache/tvm-committers @tqchen

-Andrew

[tqchen]

I like the idea. It follows the common practice in previous communities and simplifies the RFC process.

[comaniac]

Agree. It makes a lot of sense to me. Some follow-ups:

• Should we update the merged and under review RFC PRs wit this rule?
• It makes me think of that we don't really have rules to reject an RFC. Like what is the criteria to reject an RFC and should a rejected RFC PR directly be re-opened with improvements, or a new RFC PR has to be opened and associated with the rejected one. But this is not related to this PR, so we should discuss more in another thread.

[tqchen]

Yes we can udpdate the merged RFC, the only one I am aware of is autoTIR RFC and perhaps @junrushao1994 can chime in

[tqchen]

let us wait for another two days and if there is no objection, we can merge it in

[Mousius]

This is a great improvement 😸

[tqchen]

cc @junrushao1994 would be great if you can send a followup PR to rename the autoTIR RFC, and update links

[hogepodge]

Thanks for the update. I'm glad to see that we're refining the RFC process as it goes into production.

[junrushao]

Will apply the rule to meta schedule RFC this weekend