Searching issues with module name

Core Development
1

It is difficult to search issues about the json module. I expect some other libraries have same difficulties.

Can we add label like “json” or “stdlib-json” every time when we find modules difficult to search?

Or can we have some convention like “[json]” in PR title? This convention can be used without adding many lables.

2

There are a few options, depending on the goals:

  • You can already use in:title json to narrow down the search:
    • it doesn’t find all the issues and include false positives
  • You can add “[json]” in the title and use the search query above:
    • triages might not know to add [json] in the title
    • GitHub search seems to ignore the []
  • We can add a label:
    • it’s easier for filtering and for triagers to add
    • it’s useful to notify people subscribed to the label
    • if we do it should be called expert-json[1]
  • You can create a project to track issues:
    • you will have to add existing issues manually
    • you have more freedom in organizing them
    • triagers might not know to add new json issues to the project

Adding the label is probably the easiest solution[2], unless the other solutions are enough to solve your problem. Let me know if you want me to add it.

  1. stdlib, docs, tests, interpreter-core, extension-modules are in a group on their own. ↩︎

  2. we recently added expert-sqlite to solve the same problem ↩︎

3

Some modules get more bug reports than others, we don’t have to add 305 labels :slight_smile: When I added the C API and Subinterpreters category for bugs, I also added [C API] and [Subinterpreters] to the issue title, because categories (now labels) were not disabled by default on bugs.python.org. IMO it helps to very quickly sort issues when browsing the whole list of issues, without having to read the whole issue title or even have to read its description.

In short, I’m in favor of adding a stdlib-json label and add [json] in the issue title.

4

I think the expert-* labels may be good candidates for replacing by projects.

The reason is that these labels represent a category that the issue belongs to, which isn’t expected to change throughout its lifetime. On the other hand, labels seem better for things that are more transient or process-related like status/stage/needs-something.

4 Likes
5

I have collected them in a project: @serhiy-storchaka's project python-json · GitHub .

I am currently working on a large project which will solve many of these issues. Will finish it in few weeks.

3 Likes
6

There sre 38 json-related issues and 76 zipfile-related issues (@serhiy-storchaka's project python-zipfile · GitHub).

1 Like
7

And not every module in the stdlib has someone who cares about its status, so the label may not be useful overall.

What’s probably best is to have a label for anything that has a maintainer, and then provide either guidance or a GHA workflow that picks up on /stdlib json or something that will add the appropriate [json] to the title as well as any appropriate label (if there is one). And anything lacking a maintainer we can add some other label to make them easy to find.

1 Like
8

I have created projects for a number of topics: Projects · python · GitHub .
For now, they look less convenient than labels, but they are potentially more powerful. I think we will use labels for larger and general categories, and projects for smaller and more short living (or at least with a determined plan) groups of issues. But projects need to be more mature for this.

3 Likes
9

Thank you!

10

Using built-in GitHub features would be preferable to custom solutions whenever possible. Labels, projects, milestones, and teams can all be set easily from the sidebar without having to edit the title and to post new messages to trigger GitHub actions (that also need to be written/configured/maintained).

I agree with Irit and Serhiy – once projects get more mature we could use them to replace the expert-* labels, making the label list more manageable. For now we can keep using labels and experimenting with projects.

2 Likes
11

Yep, always.

My concern is scale here. Will we end up with e.g. 200 project boards, one for each module in the stdlib? Can that be navigated easily? Same goes for the labels (and having worked on projects with hundreds of labels, I think it gets a bit unwieldy). At that point it becomes a maintainability challenge even if the feature is built into GitHub.

2 Likes
12

One key difference is that projects are usually assigned once, whereas labels are added/removed more often, so I’d rather have a short list of labels and a long list of projects than the other way around.

Since the beta projects are created at the org-level, there is the risk of ending up with a lot of projects if they start getting a wider adoption, but so far other other python repos didn’t really use beta projects. In addition, beta projects can be added to the repo and filtered more easily there, and I don’t think we need a project for each module anyway – just for the ones that have enough issues and/or where someone bothered creating a project.

Currently there are about 20, and some of them encompass multiple modules: Projects · cpython · GitHub

13

As a triager, how am I expected to (how should I) work with projects? Currently I can assign expert-* labels from the issue page, but it seems that doesn’t automatically add it to the relevant project. Equally, there doesn’t seem to be a way to add an issue to a project from the issue page, which is a major usability point. Thoughts welcome (including what people have been doing currently!).

A

2 Likes
14

We are still experimenting and figuring out what workflows work best.

This could be automated, but it won’t be necessary if we get rid of the expert-* labels.

In the issue sidebar there is a field just under “Labels” where you can search/filter projects:

image
image315×537 25.7 KB

When you select one, the issue will be added to that project, and the project will be visible in the sidebar:
image

You can also add issues in bulk from the issue list page, by selecting them with the checkbox on the left and then selecting a project they should be added to.

15

Triagers don’t have that drop-down :frowning: (I assume the same with editing issue/PR titles). Is there a way we can ask GitHub to vary/customise the permissions for triagers?

image

A

1 Like
16

That would need to be a feature request to GitHub as repo permissions are hard-coded to role types.

17

Ahh, sorry, I was under the impression we had some sort of direct relationship with GitHub / their product team. If seems custom roles are supported, but only for “Enterprise Cloud” – I assume Python is not using this, so we’d either need an exception from GitHub or some change to the public product, on my reading.

A

18

Our relationship as a project extended to them having some folks help us with the issue migration for CPython. Otherwise any other relationship stems from personal relationships any of may have with GitHub employees.

Nope, we are just plain-old, public GitHub. :slightly_smiling_face:

2 Likes
19

Per @ezio-melotti, GitHub has now released fine-grained roles! Link: Custom repository roles are now GA | GitHub Changelog

https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization

It might be useful if we grant Triagers permissions to manage projects on issues and edit titles, if possible – should I open an issue in core-workflow?

A

1 Like
20

So this is where I was asked about this! I couldn’t remember earlier today. :sweat_smile:

Doesn’t hurt. I’ve also posted about this to the core dev Discord server as well.

2 Likes