I’ve been having a hard time tracking the tracking issues in the Rust repo. In particular in the language domain, we have a whole bunch of issues which are somewhere between an accepted RFC and a stable part of the language. The process for issues is something like:
RFC accepted -> create tracking issue -> implement -> get experience -> stabilise (via FCP)
There are also issues which never had an RFC but were implemented (usually a long time ago) and are unstable.
In order to track and categorise tracking issues we use the B- labels on GitHub (I think, but am not 100% sure that we only use B- labels for tracking issues and that all tracking issues have at least one B- label). AIUI, all open tracking issues are B-unstable. Every tracking issue should be assigned to at least one (and preferably only one) team (e.g., labelled T-lang).
I recently added the B-RFC-implemented label, there also exists the B-RFC-accepted label. Tracking issues where an RFC is accepted and waiting for implementation should be B-RFC-accepted, that tag should be removed when implementation is complete. When the bulk of implementation is complete, we should add the B-RFC-implemented label. The intention here is to be able to see at a glance where on the above time-line an issue sits.
One niggle here is that there is a distinction between unstable, implemented issues which had an RFC or not. I’m not sure if it is actually worth making that distinction - from a tracking perspective, once a feature is implemented it is not too important whether an RFC existed or not.
So, some requests:
- could someone from the other teams triage the non-T-lang issues to make sure the labels reflect the above policy?
- could we be stricter with ourselves about keeping tracking issues up to date, both text and labels? (I found it quite hard in some cases to tell whether a feature had been implemented and what issues remained).
I’d be interested in hearing people’s thoughts and comments here. Some questions - is it worth having the distinction between RFC and non-RFC issues (and thus the B-RFC-implemented label)? Could we do this better in any way?