[meta] Labels in this repo

[petrochenkov]

This is a tracking issue for changes in labels in this repo.

If you want to discuss how issues and PRs in this repo should be labeled, please leave a comment here.
If you want to make to make a large change (e.g. remove some labels), please leave a comment here.

Conventions for labels in this repo

So far the primary rule is that every issue and PR should have at least one T- label marking it with relevant team, so people from various teams interested in triaging or picking up ideas for RFCs can filter issues easily.

Large issue categories like T-lang may have more fine-grained labeling in the future (To Be Defined).

PRs in this repo follow the RFC process and should be labeled with process-related tags if necessary - final-comment-period/proposed-final-comment-period/etc.

cc @Centril

[petrochenkov]

I'm going to nuke the A-wishlist label soon which is applied randomly and almost all this repo is some kind of wish-list by itself.
I'm leaving this comment for a sanity check.

[petrochenkov]

I previously did some other large changes (beyond just labeling a bunch of issues) without notifying people - merging two labels for library-related issues into one and merging two labels for the tools team into one.

[Centril]

Removing labels

Agree with getting rid of A-wishlist =)

Few other candidates:

• A-servo - the Rust project is now a lot more decoupled from Servo than before... seems strange to continue to bless the Servo project this way, cool as it is.
• A-stabilize - stabilization goes via rust-lang/rust and not here.
• A-enhancement - this is almost always the case and so adds zero additional information and is redundant.

It also seems we are not using the S- status labels at all - should they go as well, or maybe we should start using them?

I propose we rename A-breaking-change into just breaking-change since it is not an area at all but more a general description.

Adding new ones?

It might a good idea to reuse the scheme in the rust-lang/rust repository with the many A- labels for traits, const fn, lifetimes, etc. so we can categorize RFCs more finely based on what they are about rather than just what team is responsible. This will also make it easier to find duplicates and generally coordinate and triage similar-purposed RFCs. This will of course have the initial cost that some one has to label a bunch of issues and current and closed/merged RFCs, but I can do that.

[petrochenkov]

@Centril
Everything LGTM, except that I'd prefer to not add any new labels until all open issues/PRs have T- labels.

[Centril]

@petrochenkov Seems like a good roll-out plan. I'll start adding a bunch of labels =)

[Centril]

@petrochenkov This is now done for all open issues & PRs that can reasonably have T- labels.

[petrochenkov]

The S- process labels seem to be a short-lived experiment. They were used for couple of months, then everyone successfully forgot about them.
Since they do not apply to any open issues/PRs I'd rather remove them.

[petrochenkov]

Looks like A-community-library issues should be closed by-definition as "not our business", but the label should be kept so these library ideas can be found if necessary.

[Centril]

Agree with S-, let's get rid of em.

On A-community-library I think we should rename it to community-library (and keep it) and give it a different color so that it does not get intermingled with possible new A- labels that we will actually use to classify semantic content.

[Centril]

@petrochenkov How do we deal with the postponed label? Feels like postponed RFCs should have the label for easier searching...?

EDIT: I'm suggesting we not have tracking issues for postponed RFCs at all as they just increase clutter - discussion can continue even tho the PR itself is closed..

[petrochenkov]

My idea so far is to keep an open issue for each postponed RFC and keep the postponed label only on that issue to avoid duplication.
(If some postponed PR doesn't have an open issue yet, then it should have the postponed label itself.)

[Centril]

@petrochenkov imo the indirection doesn't help - we have massive clutter atm, so it is better to not have postponement issues at all?

[petrochenkov]

Hmm, maybe.
So the alternative is to close all the postponement issues and keep the postponed label on the last RFC PR trying to solve that specific problem?
Sounds reasonable to me as well (the fewer issues the better).

[Centril]

Yes exactly =)

[Centril]

I propose we introduce the label FCP-complete and have the rfcbot change the label from final-comment-period to that once it is complete so that it gets easier to see and manage FCPs.

cc @aturon

[Centril]

I think we can close this now; I'll open up a new issue if need be for further discussion about labels.