Add topic-tools label

[picnixz]

When we have a bug, or a feature in the Tools/ directory, we may sometimes add some label such as topic-JIT or topic-installation, but sometimes, we have no category at all and we're left with a bare type-bug label or type-feature label. I would like to suggest a topic-tools label to categorize issues that affect files in Tools/.

Some relevant issues:

• pygettext: help output for keywords prints the whole keyword dictionary cpython#129911
• pygettext: use an AST parser instead of a tokenizer cpython#104400 (incorrectly categorized as extension module)
• pygettext: use an AST parser instead of a tokenizer cpython#104400
• GDB extensions fails with optimized 3.13 due to cframe removal cpython#127147 (everything GDB related)

[tomasr8]

I'm going to be opening more issues related to pygettext so it'd be nice to be able to categorize them properly (though at least for pygettext I can use the Gettext GH project)

[picnixz]

The gettext project is more for the gettext module but maybe I'm mistaken? More generally, it's just that whenever I look at the issues list, I see a bare type-bug label and then re-look at the issue and see that I've already triaged it (although I could add the triaged label, it's still better to know what this is about without the needs to read the title IMO)

[tomasr8]

It's more like an umbrella for all i18n issues (excluding date & time).
It'd be nice if GH showed the project on the issue page so it'd be clear from the get go.

[erlend-aasland]

See also previous discussion: #516

[picnixz]

Ah. I forgot to look at a previous discussion on this. Mmh, looks like there were some different opinions on the usefulness and the scope of the label. I don't think it's worth re-doing the discussion that was already done in #516. My idea was just to have a label to indicate that this was in the Tools directory (so it would have been a green label, not a blue one) but I guess I can live with using triaged instead.

Note that the labels are useful to me because I know that a standalone type-bug is usually something that hasn't been triaged (it's the default label when someone opens a bug).

I'll close this one as not planned. For gettext & co, let's use the project and for debuggers, Tian will likely follow them. There would be something concerning the analyzer tools and other stuff that don't fall yet into a categorized label, but I can also try improving the issue title whenever possible as well.

[ezio-melotti]

More generally, it's just that whenever I look at the issues list, I see a bare type-bug label and then re-look at the issue and see that I've already triaged it (although I could add the triaged label, it's still better to know what this is about without the needs to read the title IMO)

In a previous discussion I suggested to have an untriaged label that is automatically assigned to all new issues. Triagers can easily remove it once they triaged the issue, rather than having to search and apply the triaged label (which doesn't really seem to be used).

Perhaps we should revisit that proposal instead?

[picnixz]

I fear that there will be too many "untriaged" labels. In addition, we need to remove the label once it's triaged. Note that most of the time, issues are well-triaged, except that sometimes they lack the directory label. I'm more interested with the refactoring label though (it could be categorized under a feature label but it's good to distinguish between the two IMO as I see the feature label as more of something public/documented whereas a refactoring is usually internal/skip news).