Choose label colors

[mkoeppe]

... so that we can configure the colors of individual labels.

In particular, set the colors of the labels that GitHub predefines (#99 (comment)):

#d73a4a bug
#0075ca documentation
#cfd3d7 duplicate
#a2eeef enhancement
#7057ff good first issue
#e4e669 invalid
#d876e3 question
#E81FF9 wishlist item
#ffffff wontfix
#008672 help wanted

Need to make color decisions for:

• component: math component
• component: other component
• duplicate/invalid/wontfix
• worksforme
• feature
• pending
• priority: minor, critical, blocker, trivial,
• status: needs review, positive review, needs info, needs work

https://en.wikipedia.org/wiki/Web_colors

[kwankyu]

Don't try to write text in the color band. It does not reflect well the real labels, which will have bold white or black text.

[mkoeppe]

As I said in #99 (comment), the duplicate, invalid, wontfix labels could all have the same color.
Likewise for duplicate/invalid/wontfix and worksforme. For example:
#cfd3d7 duplicate, invalid, wontfix, duplicate/invalid/wontfix, worksforme

[kwankyu]

We settled on the labels: https://34.105.185.241/sagemath/sage-20230116142640/labels. The following table is out of date.

Preliminary label colors:

group	label	color
component	mathematics	#0000ff
component	infrastructure	#0075ca
status	needs review	#7fff00
status	needs info	#ffff00
status	positive review	#dfffc0
status	needs work	#ffff00
type	duplicate / invalid / wontfix	#696969
type	works for me	#696969
type	feature	#696969
type	pending	#696969
priority	trivial	#fff9e5
priority	minor	#ffe799
priority	major	#ffd500
priority	critical	#ffaa00
priority	blocker	#ff0000
	bug	#d73a4a	predefined
	documentation		removed
	duplicate		removed
type	enhancement	#696969	predefined
	good first issue	#7057ff	predefined
	invalid		removed
	question		removed
type	wishlist item	#E81FF9	predefined
	wontfix		removed
	help wanted	#008672	predefined

[tobiasdiez]

A few comments:

• I would not make all status and type comments the same (or almost the same) color. The main advantage of these labels is that you can easily see what action is required by scrolling the list of issues/PRs. So for example "status: needs review" should attract attention because devs should have a look at it, while "status: needs work" can be more quite.
• Some of the "types" seem to be actually a status: duplicate, worksforme, pending
• What is a "trivial" priority?
• I would see the predefined labels as a suggestion from github but not something we need to stick with. So in particular, they should be sorted in the status / type pattern and merged if necessary (e.g. duplicate, wontfix and status: duplicate/invalid/wontfix)

[mkoeppe]

• So for example "status: needs review" should attract attention because devs should have a look at it, while "status: needs work" can be more quite.

excellent point.

[mkoeppe]

• What is a "trivial" priority?

It's the lowest priority on our Trac - for tickets such as simple fixes of typos

[tobiasdiez]

So:

• p1: trivial
• p2: minor
• p3: critial
• p4: blocker

Another scale that I've seen being used is: chore / nice to have / minor / important / urgent.

[mkoeppe]

In between "minor" and "critical" we have on Trac the default "major" priority, which I am currently not translating into a label at all.

[tobiasdiez]

Also, I don't think having 30 or so component labels is such a big deal. When you assign a label to an issue github gives you a nice autocompletion, and the "status/type/prio" prefix helps you in that since it hides the non-relevant labels.

For example, vscode has more than 400 labels: https://github.com/microsoft/vscode/labels

[mkoeppe]

So if the scale from trivial to blocker is represented by different saturations of yellowish orange, then we should also have label for "major".

The idea with suppressing "major" was to reduce noise.
But that only works if "trivial" and "minor" are marked with a color that indicate "more boring than an unlabeled issue"

[tobiasdiez]

In between "minor" and "critical" we have on Trac the default "major" priority, which I am currently not translating into a label at all.

I would suggest to export it and have "no prio label" as a place holder for "not triaged yet". Also you can always delete the major priority later (but adding it to the existing issues is hard).

[mkoeppe]

OK,

• I now map "major" to a label in 7f2cfc0 -- then we can use a middle saturation of yellowish orange for it.

[mkoeppe]

• Some of the "types" seem to be actually a status: duplicate, worksforme, pending

The label "pending" is how I map our special Trac milestone sage-pending, which has been used to mark tickets that are either stuck or forgotten.

• predefined labels [...] should be sorted in the status / type pattern and merged if necessary (e.g. duplicate, wontfix and status: duplicate/invalid/wontfix)

In Trac, we have a special milestone "sage-duplicate/invalid/wontfix" and in addition a "resolution", which is one of the three. (Then there is also a resolution "fixed", which is used for merged tickets.) Label "duplicate/invalid/wontfix" is for tickets that have not been closed yet but have been proposed to be closed with one of these resolutions by moving it to the special milestone. The migration script already does a bit of simplification to the duplicate, invalid, wontfix stuff.

[kwankyu]

.. and the "status/type/prio" prefix helps you in that since it hides the non-relevant labels.

"s: status", "t: type" "p: priority", "c: component " would suffice.

[kwankyu]

I would see the predefined labels as a suggestion from github but not something we need to stick with. So in particular, they should be sorted in the status / type pattern and merged if necessary (e.g. duplicate, wontfix and status: duplicate/invalid/wontfix)

We may retain a subset of these predefined labels and delete the others. Right?

If we keep a label, then it will be without a prefix (status, type, priority, component) and will have its own color.