Strategy for labelling issues in stdlib

[awvwgk]

Is there a general guideline for applying labels on the stdlib issue tracker? We have a bunch topic labels which are clear (utilities, mathematics, ...) but there are additional state labels (idea, API, specification, in progress, release) available.

Also, since issues and patches can transition between the states applying labels is usually quite tedious and they become quickly outdated.

[milancurcic]

I think the general guideline is "use labels that make sense to you".

There are GitHub labels that come out of the box. There are topical labels (utilities, math, etc.) that somebody (@jvdp1 maybe?) created at some point in the past. And there are labels for each step of the Workflow that I created.

But we don't have a guide on how to use the labels. It's somewhat casual and ad hoc.

Any suggestions welcome.

[jvdp1]

Indeed, I created a few of these labels last years. Ideally developers should adapt the state labels (e.g., when opening a PR), but I guess this will not happen often. As @milancurcic said, any sggestions are welcome.

[awvwgk]

I found that most project using state labels have some kind of automation in place to make sure they are up-to-date (usually a GitHub bot or a GitHub action) or an active triage team. I think especially for state labels it is important to have clear guidelines and an entity that enforces those to prevent the labeling to get outdated and become useless.

I perceive adjusting labels after an issue is resolved as similarly error-prone as deleting a feature branch after the patch is merged. I usually do it, yet I have 50+ stale feature branches in several of my most active forks.

Since building an active triage team seems like a lot to ask from the volunteers here, I would prefer some automation. A not label-based automation are project boards, the nice thing is that they can change the state automatically on events like, closing or merging. I never been a fan of project boards so far for tracking releases (milestone labels work just better), but the workflow states might be legitimate application of those (see https://github.com/fortran-lang/stdlib/projects/1).

The good thing about project boards is that they disappear from the issue history completely once they are deleted, so if it doesn't work out, we can get rid of it again without a trace.

[awvwgk]

I added some state labels for the PRs:

1. reviewers needed: this patch needs more reviews to move forward
2. under review: currently under discussion
3. waiting for OP: changes have been requested in the review that must be addressed first
4. wontfix: proposed patch was rejected or is stale

[awvwgk]

I added a bunch of new labels for topics and applied them on the issue tracker. Also I updated the compilers label to make it specific for the compiler involved and added build and platform labels to make it easier to navigate the issue tracker in search for bugs.