I think we should pause work on this until we’ve decided on exactly which approach we’re proceeding with.
I’d really like labels for each of the expert areas, so I can easily find all bugs related to typing or sqlite or asyncio or some other major part of the stdlib. Maybe we just have to accept that the list of labels will be extremely long; I don’t think the costs you list are that bad.
I’d recommend doing both.
- I’m pretty sure that only distinguishing by color will not work well, since I’m pretty sure we’d have colour blind folks looking at these pages.
- I don’t think that a long list of labels is problematic, as long as its well organised.
It takes a bit of upfront effort but that effort pays off well. It’s also a decent amount of work to apply them on every issue though, something that bpo currently offsets onto the person filing the issue; which we might want to make possible.
I’ve found pip’s issue tracker much easier to triage since we’ve moved to our prefix-based model for labels.
And, as a purely bikesheding note: I think it’s reasonable to do something like “type: bug” instead of “type-bug”. Both of them will show up when you say “bug” or “type” or “type bug” in the label picker, and I personally find the visual separation of
type: bug to be nicer than the lack of separation in
Yes, especially as the “Filter by label” box lets you find things quickly:
Thanks everyone for the feedback!
Fair enough. If the triagers are fine with the price of dealing with a long list of labels in order to have a more powerful issue search/filtering, then I guess it’s a worthy trade-off.
PIP currently has 90 labels (Labels · pypa/pip · GitHub) and it seems to mostly use one-letter prefixes that are not immediately obvious (in fact it took me several clicks to find this page that lists the labels) and also has some “long” prefixes (like
type: *). Black also uses a similar one-letter convention and has 45 labels (Labels · psf/black · GitHub). Jupyter Notebook mostly uses “long” prefixes and has 48 labels (Labels · jupyter/notebook · GitHub). CPython now has 31 labels (Labels · python/cpython · GitHub – one disappeared overnight ).
All of them also have some unprefixed labels (e.g.
invalid). The colors seem somewhat inconsistent within the same category, except in the case of Jupyter which is fairly consistent. Even within category that use the same color, there are some differently-colored exceptions (e.g. the red
type-security among the other blue
If everyone else has experience working on repos with a many labels, I would be curious to hear about it.
That said, if we agree on having more labels, we still need to decide which ones we want to keep. I will update the list above and ask again for feedback.
The good news is that the label name, description, and color can be changed at any time, so we will have plenty of time to bikeshed after the migration.
I think we need some issue management labels. Things like:
awaiting-information (OP was requested to clarify something).
pending-close (a core dev or triager suggests closing, but wants to give others a chance to object).
Maybe the bots can automatically close issues if they have one of these labels for a month.
FWIW, on the main Spyder repository, we get 150+ issues per month (and used to get double that or more before we implemented a bunch of automatic troubleshooting and triage steps).
Back when I was in charge of it, we introduced a
status: Awaiting Followup tag for this case, since it was very common that users would not give us enough information to propose a solution, reproduce a bug, close as a duplicate or otherwise act on it. If they didn’t answer after 8 days, the issue would be closed.
It has since become very successful and kept our issue backlog more manageable, and I believe we’ve automated that nowadays (and there are many bots and GH Actions to do so). I’ve seen it used on a number of other projects as well, in combination with bots/GH Actions/etc that take care of the followup.
A big issue for us with tags in general was core devs not applying and using them consistently; having a dedicated and relatively experienced person in charge of triaging issues and PRs (me; now its handled by everyone on a rotating basis, one core dev per day of the week) was pretty critical for that. In this case, you have a whole team of them, so that should hopefully be somewhat less of a concern.
ISTM that both indicate an issue that should be closed unless more information that prove its validity are provided. Something like this is definitely useful to have, but perhaps we don’t need to distinguish between the two.
FTR Black and PyPI have
S: awaiting response and
S: needs repro, Jupyter has
I think it would make sense to automatically close after a few days issues that have been marked with the aforementioned labels by a human, since they are not useful in their current state. I wouldn’t close old/stale issues just because they are old.
We already have a GH Action to label old PRs as
stale after 30 days, and remove
stale after activity.
After another 14 days, PRs labelled
CLA not signed are auto-closed.
(Those also with
CLA signed are not auto-closed.)
I can see value auto-closing issues that have
stale and human-applied label(s), and we could use the same GH Action.
We also have a probot that automatically applies a “status:Needs Triage” label to new issues.
compile error is fundamentally different from the other two, and I suspect if we don’t have a
crash tag then people will be tempted to put
[crash] in the title.
I’d just keep them separate. The definitions you have in the first post are (almost) clear enough to handle triaging (I’d clarify that
compile error is for compiling CPython, rather than “Python”).
This sounds quite useful, especially because we have a number of labels that are directly correlated to specific files/paths. Thanks for sharing!
Upon further thought, I think it’s better keeping them separate, for two reasons:
- While reporting, triagers know the difference and users can’t set labels directly, so misreporting shouldn’t be a problem;
- While searching/filtering, devs might be interested in finding crashes and compile errors specifically, without having these kinds of issues lost among other generic bugs.
I would consider renaming
type-build in order to encompass all build related errors: configure not functioning as intended, makefile bugs, problems with build related tools (freeze, etc.), and of course compilation errors.
Note that we already have the
Build and the
Cross-Build components, and I was already planning to merge them. Should we also add
type-compile-error and combine all three into
type-build (or just
Since renaming and removing labels can be easily done at any time after the migration, I decided to map most of the fields to labels during the migration, and we can then update the labels after the migration. Colors and descriptions can be updated too.
Merging label can technically be done after the migration too, by selecting all issues with label
B, adding label
A to all of them, and removing label
B. Doing this after the migration however will generate two new events on each issue (addition of
A and removal of
B), and will update their “Last updated” date, making some searches more difficult. Because of this, doing it before the migration is better – the downside is that if we change our minds on a merge, it’s tricky to undo it.
Based on the feedback I received, I changed the following things:
type-performanceand added a
performancelabels that can be combined with the other
- Temporarily renamed
type-teststo match the existing labels in the CPython repo (these should be renamed)
- Added labels for
3.11(these can be removed afterwards)
deferred-blockerlabels (these can also be removed)
pendingto map to
- Added labels for most components
Regarding the components, this is the full mapping:
- Library (Lib)->
- Interpreter Core->
- Extension Modules->
- C API->
- 2to3 (2.x to 3.x conversion tool)->
build(easily searchable, not too useful)
- Demos and Tools-> `` (only a few issues, not too useful)
- Regular Expressions->
- Argument Clinic->
- FreeBSD-> `` (only a few issues, easily searchable)
interpreter-core(only a few issues, easily searchable)
library(only a few issues, easily searchable)
FreeBSD and Demos and Tools have no corresponding labels, Cross-build and Build have been merged into
build, Distutils has been included into
library, Parser into
(I’ll update the initial post shortly) – done
What about renaming type-behavior to type-bug?
This can be easily done either before or after the migration, and renaming
type-bug is fine with me.
python/cpython repo already has
type-bugfix for PRs though, so there are a few options:
type-bugin the mapping, so that both issues and PRs will end up under the same label;
- Get rid of the
type-bugfixlabel for PRs and only mark issues with
type-bug(issues are linked to PRs anyway, so we don’t need to mark them twice unless some bot/script needs that label)
- Keep both labels, use
type-bugfor issues and
Nothing will be improved by having two different tags, you can filter with
I’ve already renamed some of the labels on the
type-bug(this will replace
I also noticed that the
python/cpython already has some stage-like labels:
awaiting change review,
awaiting core review,
awaiting review. bpo has these stages
Should we map
awaiting * labels don’t seem to be documented, so I’m not entirely sure what mapping (if any) would make more sense.
IIRC some bot owns the ‘awaiting’ labels.