Add the topic-tools label

[iritkatriel]

We don't have a label for issues related to debugger support and the stuff that's in the Tools/ repo.

[ezio-melotti]

There are two options for this:

• If the label is about the Tools/ dir, it should be one of the dir-based green ones
• if the label is more generic and includes things that might or might not be in the Tools/ dir, then it could be a topic-tools label

[iritkatriel]

Blue topic-tools. It's not just for the Tools/ directory.

[AlexWaygood]

I'm confused about whether e.g. Argument Clinic-related issues should have this proposed label applied to them or not. Argument Clinic lives in the Tools/ directory, on the one hand. But on the other, we already have a specific label for AC issues, and AC issues don't really have anything to do with debuggers.

[iritkatriel]

No, I don't think this label covers AC. This is also why it's blue and not green, it's not tied to the directory.

[AlexWaygood]

Would topic-external-tools be a better name, then?

[iritkatriel]

They're not external if they're implemented in Tools/

[AlexWaygood]

Which things implemented in Tools/ would be covered by the label?

[iritkatriel]

I don't think we need to get into analysis paralysis here. These labels are not clear-cut categories (should a socket issue be labelled as stdlib or extension-modules? Should an AC issue be interpreter-core or build?)

The labels are useful not because we always know exactly which label to put where, but because they convey useful information.

[gvanrossum]

Certainly the PEG generator and the cases generator?

[AlexWaygood]

I'm not trying to get into analysis paralysis. But I don't currently feel like I have a good understanding of what this label would be for, and that means I wouldn't know which issues I should be applying it to when triaging at CPython. I'm trying to understand your "vision" for the label so that I can constructively suggest a better name that I'd find easier to understand :)

[iritkatriel]

I'm more interested in having a label for issues related to debugging and debugger support. The stuff in tools can often also fall under interpreter-core or build.

[iritkatriel]

But I wouldn't label it topic-debugging because one day we will have an issue about coverage tooling and we won't know where to put it.

[AlexWaygood]

Maybe topic-debuggers, then? Or topic-debuggers-and-profilers?

I feel like having "tools" in the name is misleading (even with the different colour), since there are more things in Tools/ that don't relate to profilers/debuggers than things that do

[iritkatriel]

As I wrote above, I don't think we should add a label just for profilers and debugger. It's too narrow.

[brandtbucher]

I also don't think the two categories are really related. The stuff in Tools and debuggers/profilers are completely different things from a triage/maintenance perspective. They're all just "tools" in an abstract sense.

I don't think it's a problem to introduce two labels: one for the directory, and one for debuggers and profilers. We already have super granular "topic" labels; something like topic-debuggers would actually be one of the more general labels in the group.

[brandtbucher]

@gaogaotiantian, would you find a label like topic-debuggers useful?

[iritkatriel]

@gaogaotiantian, would you find a label like topic-debuggers useful?

Are you suggesting that topic-debuggers will apply both to pdb/bdb and to issues related to gdb support?

[gaogaotiantian]

@gaogaotiantian, would you find a label like topic-debuggers useful?

From my personal perspective, I think the important thing is the purpose of the label (not just for this specific one, the labeling system). Do we need labels to

• Categorize all issues, or
• Find the specific group of people to deal with the issue

For example, topic-asyncio, topic-typing, topic-subinterpreters - they are describing a very specific area of CPython. Without having to read the title and the content of the issue, I would know if I would be interested in it, or even who I should assign it to.

topic-tools on the other hand, seems like an effort to "collect some of the uncatetorized issues" to me. Not saying that having it is useless - but I do wonder about the effectivity of the label. Will people realize that the issue is of their interest or in their expertise much faster? Tools/ is a very large directory and there are plenty of miscellaneous things in it, and some of the contents are probably covered by existing topics (like Tools/ssl might be covered by topic-SSL?).

topic-debuggers or topic-debuggers-profilers is a much clearer topic to me and it serves the purpose to narrow the issue down to a specific area that would only interest certain people. I agree it's narrow, but is it narrower than topic-sqlite3 or topic-ensurepip? Or the cutoff is that the topic area has to own a directory in Lib/?

That being said, if something like topic-debuggers-profilers is created and used, I'll probably monitor the label. If topic-tools is used, I'll probably wait for a while and see how we eventually interpret the label.

Again, just sharing my two cents, I don't have a very strong opinion on either label.

[iritkatriel]

If we add a green tools label and a blue topic-debugging label, is that ok with everyone?

[AlexWaygood]

the cutoff is that the topic area has to own a directory in Lib/?

No, not necessarily — we have topic-WebAssembly, which doesn't really own a directory in Lib/

[AlexWaygood]

If we add a green tools label and a blue topic-debugging label, is that ok with everyone?

Yup, that makes sense to me! Though I'd capitalise the T (Tools rather than tools) to doubly emphasise that it's referring to the name of the directory the code is in rather than an interest area.

[gaogaotiantian]

If we add a green tools label and a blue topic-debugging label, is that ok with everyone?

Makes sense to me.

[ezio-melotti]

I tend to agree with @gaogaotiantian that a topic-debugging label seems well defined and potentially useful.

tools however is more generic and might not be as useful:

• people tend to follow well-defined labels about specific topics -- Tools/ includes several unrelated tools
• we used to have "Demos and Tools" on bpo, but it was rarely used and was removed during the migration
  • Tools/demo got removed too: gh-97681: Remove Tools/demo/ directory cpython#97682
• we already have topic-* labels that can be used for some of the existing tools (e.g. unicode, ssl, wasm, etc. tools)

tools could be used in combination with other labels (e.g. tools + topic-ssl to find issues related to ssl tools) to further refine searches. However, the more labels we add, the more difficult it becomes to triage properly, since triagers will have to know/remember about this new label and apply it accordingly.

[serhiy-storchaka]

Don't forget about projects. You can create projects to categorise issues and add fields to categorise issues in the project without increasing the labels list.

[iritkatriel]

tools however is more generic and might not be as useful:

Why is this not true for stdlib and interpreter-core?

[iritkatriel]

Don't forget about projects. You can create projects to categorise issues and add fields to categorise issues in the project without increasing the labels list.

That we're using a mixture of labels and projects and nobody knows what's supposed to be going on is a bug rather than a feature. Our triage workflow is a complete mess and the discussion on this issue is proof of that.

[gaogaotiantian]

tools however is more generic and might not be as useful:

Why is this not true for stdlib and interpreter-core?

To be honest, I did not find stdlib very helpful. interpreter-core on the other hand, might be a narrower tag.

Instead of "what issues could be categorized into this", I often think of tags as "who cares about this tag". Tags without real corresponding functionality (like needs backport) should either

• Accelerate the process for people to decide if they are interested or not
• Provide the ability to back-search the issues that might be missed

As far as I can tell, stdlib serves neither. It's more like a "labeled" label - indicating a triager has looked at the issue and decide it's not spam. It's too broad and I doubt if anyone really cares about it.

[iritkatriel]

A new contributor who doesn't know C and is looking for something to do might search for stdlib issues.

[AlexWaygood]

A new contributor who doesn't know C and is looking for something to do might search for stdlib issues.

I'm not sure if any new contributors are actually doing this. But, if that's the theoretical use-case for the stdlib label, I think we'd be served better by language-python and language-C labels. Python files aren't only found in the Lib/ directory.

[gaogaotiantian]

That we're using a mixture of labels and projects and nobody knows what's supposed to be going on is a bug rather than a feature. Our triage workflow is a complete mess and the discussion on this issue is proof of that.

I agree our triage workflow has some issues. Triagers should make life easier for core-devs (or other contributors). Our current workflow deals with spam fine (I think), but it does not save much of the time for core-devs.

In an ideal world, contributors, core-dev or not, do not need to go through "untriaged issues". They can find their interested ones (or the ones they are responsible, if they are code owners) with just tags. Or when they are quickly scanning the issues, they can skip many issues just based on the tags on them.

Because of the nature of CPython, we can't do strict code ownership (we have many outside contributors and many code that is not owned by anyone), and that's the reason for tags - it's a middle layer where we compile the issues to pre-defined bytecodes, and let the contributors to pick the bytecode they are interested in.

Thus, the tagging system should be like a compiler - we should be able to compile all the issues to bytecodes, and we should have relatively clear and orthogonal bytecodes so contributors can pick them up.

We do not do perfect on either process at this point (and it's not anyone's fault, unlike code, issues are harder to compile).

However, that's the reason that I like the new tag topic-debugging -> it's a new bytecode that helps both process. It's easy for the triagers without any strong background knowledge to categorize to, and it helps the contributors that are interested in the field to find related issues.

stdlib on the other hand, is less useful. I doubt any new contributors would use that tag to search "Python related issues", because - who would know that? I don't expect any new contributors to understand what a "stdlib" is. As a Python user, that means built-in modules for me (and that's how we define it in our docs), but obviously it's not? As a C programmer, I might think that's a specific library as in C.

Also, github has a globally recognized label for that - good first issue.

[iritkatriel]

In an ideal world, contributors, core-dev or not, do not need to go through "untriaged issues". They can find their interested ones (or the ones they are responsible, if they are code owners) with just tags.

This applies to core devs who are focused on or "own" a narrow part of python. There are some of those but I would estimate that about half of the active core devs are not in this category.

stdlib on the other hand, is less useful. I doubt any new contributors would use that tag to search "Python related issues", because - who would know that?

Not for their first issue, but for their first few months while they are looking around. I think most new contributors do that before they find areas of focus or larger projects to work on.

[ezio-melotti]

Perhaps we can start by adding the blue topic-debugging label (since everyone seems to agree on that), and move the discussion about the triaging workflow and the other labels elsewhere (e.g. Discourse)?

[iritkatriel]

This isn't going anywhere, so I'm closing.