About the issue labels

[Thesola10]

As you may have noticed (or not, it's okay i won't cry) lately I started doing some cleanup in the issue labels, adding descriptions, assigning them to issues.

This thread lists issues with certain labels that should be discussed so as to not mess up existing workflows. The idea is to facilitate navigating the growing number of issues wherever possible.

[Thesola10]

not-paperwm-issue should be triaged into extension-conflict or upstream where appropriate, as those usually turn out to be the root causes. Anything else (i.e. a client app misbehaving) either warrants a dedicated label, or just none at all.

[Thesola10]

gnome-issue is redundant with upstream. We're a GNOME Shell extension, so semantically speaking our only upstream is GNOME, and we should prefer using more generic and recognizable labels to ease developer onboarding.

[Thesola10]

wont-fix is being used on issues that are still open. I get that it's more of a 'question mark' deal than outright closing an issue, but currently in e.g. #763 and #784 I'm seeing it combined with would-accept-PR -- this is sending mixed messages!

[Thesola10]

The wont-fix+would-accept-PR combo seems to be a "no official work will be put into this, fix it yourself" kinda label, but this would be better achieved by rewording+decluttering would-accept-PR on its own and leaving wont-fix as a verdict like out-of-scope. Or just using out-of-scope.

[Thesola10]

would-accept-PR versus help-wanted. This one isn't inherently a semantic issue, rather a functional one. The advantage help-wanted has over another label is that GitHub gives issues with it preferential treatment in the project's summary card, as shown in search views for instance.

[Thesola10]

The Time-Sensitive Trio

The WIP label. It gets left over in closed or abandoned issues, so it can be misleading. I'd recommend assigning someone to the issue, or just letting the issue-PR link speak for itself.

Same goes for merging soon which often gets left on merged PRs, and could effectively be replaced by the presence of an approving review.

As for PR IS READY, its job is fulfilled by just not setting the PR as WIP, where WIP has the added bonus of explicitly protecting the PR from being merged.

[Thesola10]

backport, as well as the #716 mega-issue, could be achieved with a Project. The fact that it applies by definition to issues/PRs that are already closed makes it harder to replace, but Projects aren't sensitive to open/closed state, so this could work.

[Thesola10]

stability has been left gathering dust, as is its only issue, #91. It's also too ambiguous for crash use cases, yet too specific for general project/workflow/ops improvements, which #91 is. Having too many labels makes important issues harder to discover.

Do we need a more generic "project/workflow/ops" label instead?

[Thesola10]

packaging, do we need this label? It appears to only apply to one issue, and apart from that I don't think there's so much to write about packaging that we'd need a separate label. This ties in to the "project/workflow/ops" label idea here

[Thesola10]

visual-bug and visual-enhancement could just be represented as visual+bug and visual+enhancement respectively, especially as one of bug or enhancement would already be present. This would involve creating a visual label and retroactively applying it instead of those two.

[Thesola10]

testing-requested seems to be redundant with seeking-feedback. After all, isn't testing a form of feedback anyway? seeking-feedback on a PR would carry the same meaning I'm sure.

[jtaala]

Hey @Thesola10, these changes look fine to me. Do you have perms to change labels? let me know.

[Thesola10]

I do have label perms and I have done some changes here and there before, but I wanted to gather opinions before changing stuff again