Repository navigation
Add the topic-tools label #516
Description
Activity
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 atopic-toolslabel
- If the label is about the
Blue topic-tools. It's not just for the Tools/ directory.
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.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.
Reacted by Alex WaygoodWould
topic-external-toolsbe a better name, then?They're not external if they're implemented in Tools/
Which things implemented in
Tools/would be covered by the label?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.
Certainly the PEG generator and the cases generator?
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 :)
Reacted by Erlend E. AaslandI'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.
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.
Maybe
topic-debuggers, then? Ortopic-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 doReacted by Erlend E. Aasland7 remaining items
If we add a green
toolslabel and a bluetopic-debugginglabel, is that ok with everyone?Yup, that makes sense to me! Though I'd capitalise the T (
Toolsrather thantools) to doubly emphasise that it's referring to the name of the directory the code is in rather than an interest area.If we add a green
toolslabel and a bluetopic-debugginglabel, is that ok with everyone?Makes sense to me.
I tend to agree with @gaogaotiantian that a
topic-debugginglabel seems well defined and potentially useful.toolshowever 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/demogot 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)
toolscould be used in combination with other labels (e.g.tools+topic-sslto find issues related tossltools) 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.Reacted by Alex Waygood, Jelle Zijlstra and Erlend E. Aasland- people tend to follow well-defined labels about specific topics --
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.
Reacted by Ezio Melotti and Erlend E. Aaslandtoolshowever is more generic and might not be as useful:Why is this not true for stdlib and interpreter-core?
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.
Reacted by Alex Waygoodtoolshowever 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
stdlibvery helpful.interpreter-coreon 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,
stdlibserves 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.Reacted by Alex WaygoodA new contributor who doesn't know C and is looking for something to do might search for stdlib issues.
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
stdliblabel, I think we'd be served better bylanguage-pythonandlanguage-Clabels. Python files aren't only found in theLib/directory.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.stdlibon 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.Reacted by Alex Waygood and Erlend E. AaslandIn 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.
Perhaps we can start by adding the blue
topic-debugginglabel (since everyone seems to agree on that), and move the discussion about the triaging workflow and the other labels elsewhere (e.g. Discourse)?Reacted by Alex Waygood and Erlend E. AaslandThis isn't going anywhere, so I'm closing.
We don't have a label for issues related to debugger support and the stuff that's in the Tools/ repo.