> > 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. >
Deleting an issue is not something we should do - keeping a record of why something was rejected is useful on a later date to know why but perhaps the issue of too many issues with the label is solved by a query for open rfc-tracking issues ? Ramana -- 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-887696764
