Re-Triaging and Re-Labelling issues

Hi, everyone! First off, due to permissions limitations which we are still trying to resolve, I am currently the only person on the team who can manipulate the GitHub Labels for backintime. I wish it was different, but we'll have to deal with it for the moment :) What we currently have is: - 410 open Issues, tagged with - 47 old labels, of which - 37 old labels have only 1 to 3 associated Issues. For a start, I've created a visual distinction between the old Labels and our new Labels: - old Labels are grey-colored and lowercase (like "question", "discuss", "triaged") - new Labels are colorful and start with an uppcase letter (like "High", "Reproduced", "Distro-Specific") My suggestion is that we combine re-Labelling and re-triaging all open Issues. Fortunately, we have a head start, since we've already closed/merged around 40 Issues and Pull Requests since this new team got started in June. Good job, everyone :) My plan of action would be to: - look at any Issue that has no Label, or only old labels, - determine whether to close it or keep it, - find and apply the right Labels from our newly defined set, - in the end, remove or re-assign all old labels. This way, we can always tell that: - an Issue with no Label or only old labels hasn't been assessed by the new team yet, - Issues with colorful new labels have been triaged to the best of our current capabilites. Now, unfortunately, I'm the only one who can manipulate labels. I think it's _not_ a good plan to comment on every open Issue with some tekt like: "@emtiu please apply Labels 'Bug' and 'Reproduced'", because that would generate an enormous amount of notifications for everyone, and bring all the Issues to the top of the list for "recent activity" (meaning those comments). It's probably better to do it through this mailing list, in a special thread or something. It's more of a pain to coordinate such an operation out-of-band, but we'll avoid stirring up every single open Issue. This would mean you sending mails with suggestions like "apply Label 'High' to the following Issues: ...", followed by links to GitHub. I guess?! Let's discuss what you think :) Good night! Michael

Why not deleting all old labels first? The mailing list solution also seems a bit overhead and extra work for you. I would say it doesn't hurt much when we wait for re-triage until Germar handed over the rights to some more person. But if you fine with it I also would take the mailing list approach. btw: Does anyone know how fine granulated rights can be granted via GitHub? Can someone have rights to label Issues but not commit/merge?

Moin! On 07.09.2022 23:28, c.buhtz@posteo.jp wrote:
Why not deleting all old labels first?
Some of them contain useful information (like "discuss", indicating that there was never a consensus on the problem), so I'm trying to remove them bit by bit, instead of all at once.
Let's see what's practical. I will shout "Stop!" if I have an inbox full of Label suggestions that I can't handle ;) Cheers, Michael

Why not deleting all old labels first? The mailing list solution also seems a bit overhead and extra work for you. I would say it doesn't hurt much when we wait for re-triage until Germar handed over the rights to some more person. But if you fine with it I also would take the mailing list approach. btw: Does anyone know how fine granulated rights can be granted via GitHub? Can someone have rights to label Issues but not commit/merge?

Moin! On 07.09.2022 23:28, c.buhtz@posteo.jp wrote:
Why not deleting all old labels first?
Some of them contain useful information (like "discuss", indicating that there was never a consensus on the problem), so I'm trying to remove them bit by bit, instead of all at once.
Let's see what's practical. I will shout "Stop!" if I have an inbox full of Label suggestions that I can't handle ;) Cheers, Michael
participants (2)
-
c.buhtz@posteo.jp
-
Michael Büker