areusch commented on a change in pull request #2:
URL: https://github.com/apache/tvm-rfcs/pull/2#discussion_r605878898
##########
File path: README.md
##########
@@ -1,6 +1,64 @@
# TVM RFCs
-This repoisitory is an evolving repo containing the new RFC process for TVM,
more changes to come in next few days.
+## What is an RFC?
+[what-is-an-rfc]: #what-is-an-rfc
+An RFC is a “Request for Change” to the TVM project. It is a design document
Review comment:
I guess another option is that when the PR is ready to land, there
should be a merge conflict if someone submitted another RFC PR since you
initially opened the PR. so at merge time, you could renumber.
as Jared points out, we may need to undertake a migration process, and given
the number of past RFCs it seems likely that the migration process would
overlap with brand new RFCs being submitted. this means that RFC numbers may
not monotonically increase with the order of their adoption. so i'm wondering
if making the RFC numbers start at 1 and then having to map to discussion forum
topic ID is really buying us anything. should we just adopt the topic id from
the forum into the RFC ID? then it would be simple to move back and forth.
the PR ID is yet another id that may confuse ppl, but I don't see a way
around that.
this also brings up a related question. now we are discussing this on the PR
rather than in the forum thread. admittedly, the discussion is about a process
related to the RFC repo itself....but we are still splitting the discussion.
Someone who just views the RFC for RFCs thread may not see this.
Do we have policy about where discussion should happen? splitting discussion
into two parts seems bad, but code-review naturally lends to discussion because
of the inline-comment feature.
--
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:
[email protected]
