> I'd suggest that "nearly done" is ambiguous? As a less ambiguous alternative > I'd propose always opening a tracking issue (if the RFC is big enough to > require it) when you raise an RFC and if it ultimately gets rejected we just > close the issue? This also allows code to evolve alongside the RFC.
I was thinking about that too, but I'm afraid that it might be confusing to see lots of RFC tracking issues (even they are closed). After all, deleting an issue is not allowed in Github, so it should be better to do our best to have only the tracking issues of accepted RFCs. Meanwhile, I do agree that "nearly done" is too vague. I might rephrase it to "when the RFC is about to be accepted, a committer should remind authors to open a tracking issue and update the link before merging". How does that sound? -- 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-887690611
