Tracking issues

[nrc]

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?

[anp]

Apologies if this isn’t quite on-topic… From the dashboard’s perspective (and from a more general automation perspective, perhaps relevant to @brson’s rust-z?) I wonder if it’d be possible to move RFC tracking issues (for both implementation and stabilization) to an easily parsed standard format for labels and titles.

It’d make it significantly easier to have a generated summary of RFC implementation and stabilization status if, for example, each RFC tracking issue had a label to denote that it’s a tracking issue (along with any other labels about the current status of the RFC) and a title like [RFC 1234] Implement the stuff from the RFC. Right now I’m finding not-quite-enough consistency.

For some examples, #35603 was opened and it links to RFC 1649 in the initial post’s body, but doesn’t have anything in the title. This issue and this issue both reference the RFC in the title, although they use slightly different formats for doing so.

Labels would also be nice, but a label doesn’t do much good from the perspective of automating the kind of summary you’re hoping for unless the issue itself also can be reliably parsed to determine which RFC it’s for.

[nrc]

Perhaps the dashboard could open tracking issues itself? It could then fill out a template itself (probably with some user-interaction) and ensure a consistent format?

I’ve found that many tracking issues have check-lists of sub-issues which are handy for at-a-glance ideas of progress and it can be valuable to have an issue for each item. However, doing this manually is a pain. Perhaps the dashboard could assist here too? (Apologies in advance for the feature creep).

[anp]

I like that idea! As far as I’m concerned, the dashboard has effectively infinite scope, so no worries there. I’m currently in the process of shipping a first version of the FCP coordination portion of the dashboard/bot/thing, so this seems like it’d be a logical extension on that work.

[nrc]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.