Improve communication with contributors on the issue tracker and PRs (Language summit follow up)

If the goal is simply to mark issues in a way understandable by the bot, a :+1: reaction on the first message is a simple and non-intrusive way of doing that: the bot can access the reaction and reply accordingly.

If instead (or in addition), the goal is to find/filter issues that haven’t been acknowledged yet, then a label (or IMHO better – the lack thereof[1]) is probably a better solution. Humans can use it in searches, and the bot can write messages when the label is added/removed and then again after a prolonged silence, pinging either the OP or the core devs depending on the presence/absence of the label.


  1. a new/untriaged/unacknowledged label could be added automatically on new issues, and removed when the issue is acknowledged. ↩︎

2 Likes

I have done this on other repos and found it extremely useful for everyone involved; being able to tell at a glance based on a label why an issue is still open is really powerful (hence the needs labels on PRs :grin:).

If that includes triagers, then I think this is a good practice. On GitHub - microsoft/vscode-python: Python extension for Visual Studio Code we used to have a classify label added on all new issues, then we said “thanks” and added the appropriate needs label to signify it had been triaged and to say (we dropped the label as we start from triage-needed and getting the issue assigned is the next step).

3 Likes

I think “triaged” is not quite the same as “acknowledged”. For example: someone reports a bug in some stdlib module. A triager reproduces the bug and pings the relevant expert. Arguably the issue is now triaged, but the triager is not an expert on this lib and cannot say whether this is a bug or user’s misunderstanding of how the library should work on some edge case. So the bug report is not acknowledged yet.

I actually don’t think “triaged” is a boolean state, it’s an ongoing process.

I don’t know whether it’s better to add an “acknowledged” label or an “unacknowledged” label that gets added to all new issues and is later removed. I don’t know if it matters much which way (in both cases we have the question of how we acknowledge the current open issues).

We currently have an “invalid” label (I think we quickly close those issues, not sure why we need the label). How about we add a new “valid” label and then an issue can be “valid” or “invalid” or unlabelled. A core dev’s adding “valid” could be interpreted as “I think this should be done and I am likely to help review patches for this”.

4 Likes

I prefer the latter: add the label by default to new issues and have a triager remove it after looking at it. This has some advantages:

  • it’s easy to search for issues that need attention
  • it’s easier to remove the label than adding it
  • it doesn’t add an extra label to all open issues

A triager can decide to leave the label (or even add it back), if they are not confident about the status and/or validity of issue. For example, they can ping the expert and let them remove the label after assessing the validity of the issue, or add it back on an old issue that might no longer be valid.

2 Likes

Do we now stick “unacknowledged” on all open issues? Otherwise we won’t be able to distinguish between “acknowledged” and “created before July 2022”.

I would propose waiting-triager as less scary for first-time contributors.

I wrote above why I think triage is a different thing than acknowledgement, but I share your dislike of the negativity of “unacknowledged” for new issues.

My preference would be to have labels for “valid” and “invalid”, so that it is possible to have neither (the initial state). If nobody looked at the issue in enough detail to determine whether it is valid or not, then we don’t know and there is no need for a label.

Also, “valid” is much shorter than “acknowledged” so it will take less real estate on the issues view.

(The “invalid” label is less useful than “valid”, because “invalid” issues should just be closed, but we already have it so removing it is a different discussion).

To note, as a contributor I would also find it rather harsh-sounding, and is indeed now redundant now that GitHub introduced the ability to explicitly close issues as “not planned” (a much less harsh label than invalid, IMO), which are indicated by the color and symbol of the issue icon in the UI.

3 Likes

I created an issue on the core-workflow tracker to add “valid” and remove “invalid”. This particular proposal can be discussed there:

2 Likes

First we should reach an agreement on the goals and the semantics of this new label, then we can apply it accordingly. Most of the open issues are already triaged/acknowledged, so they won’t need the label. We could still add it to issues with no replies or that lack certain labels (e.g. type-*).

My goal was to make sure that all new issues get looked at by a triager and/or core dev. The untriaged label can be used to automatically mark these new issues, so that triagers can look for them. Triagers can decide to remove the label or ping the relevant experts and let them remove it.

That’s not the goal of the “acknowledged/valid” label, so can we discuss that on a different thread?

“looked at by a triager/core dev” or “has an expert-*” label is a much lower bar than what we are discussing for this new label.

There is some overlapping though: if the issue has been triaged and the untriaged label removed, it’s implicitly valid/accepted (otherwise it would have been closed).

I don’t think so. Most triage work doesn’t go as far as determining whether the issue is valid. For example, putting an “expert-asyncio” label just means the issue is related to asyncio. It doesn’t mean that the user didn’t misunderstand the output and reported a valid bug that needs to be fixed.

As I mentioned above, in that case the triagers should leave the label and let the experts remove it or close the issue. This was also discussed here: Triaging/reviewing/fixing issues and PRs - #15 by ezio-melotti (and in the following two messages).

It doesn’t make sense to me that a label is called “untriaged” and it’s the expert’s (not the triager’s) job to bring the issue to a state where the label can be removed.

I’m open to use a different name. Some previous bikesheddings included new, unclassified, classify [1], awaiting triage, needs triage, unacknowledged, waiting-triager.


  1. this is meant to indicate the next action that should be taken ↩︎

All those names sound like something that a triager can quite quickly remove from an issue after a cursory look. So you clearly have in mind a label for triagers, while the “valid” label is primarily for experts to use (we don’t expect triagers to be able to make that decision). There really isn’t much overlap between these two labels. They mean different things and they will be applied by different people.

I created an issue for the “valid” label on the core-workflow tracker. How about you create another issue for the triagers’ label, and then they can be discussed on separate threads, which will hopefully reduce the confusion.

2 Likes

As a reminder, if consensus can’t be reached, you can always ask the SC to weigh in and make a call.

2 Likes

I think you are misunderstanding me. I’ll try to summarize:

  • issues can be grouped in three categories: “valid”, “invalid”, “not yet determined”
  • invalid issues can be closed, leaving us with “not yet determined” and “valid”
  • the distinction between the two can be determined by the presence (or absence) of a label

I think we both agree on this.


One of the initial point of contention, which is also related to the name of the label and to the group of people that apply the label, is what exactly “valid” means.

An issue can initially go through the following stages:

  • new/untriaged → partially triaged → fully triaged → approved

My initial goal was to draw the line around “fully triaged”[1], whereas you want to draw it further ahead, around “approved”[2]. This is fine with me, because it seems to accomplish both my and your goals:

  • My goal was to make sure that all new issues were looked at by a triager/core-dev. If you search for issues that are not yet approved and sort by creation date (which is already the default), you will find the new/untriaged on top. There will also be some additional issues that have ongoing discussions (or are languishing in a limbo) at the bottom of the list, but I can easily live with that.
  • Your goal was (IIUC) to determine if the issue is valid or not, in order to tell the OP whether he still has to do something or if it’s now up to the core-devs to push the issue forward.

This is why I said that there is overlapping, even though with the line pushed further ahead, the name (un)triaged clearly becomes inappropriate.


The next point of contention is whether to:

  • have “not yet determined” as the default, and add a label to mark issues as “valid”
  • have a label for “not yet determined” added automatically on new issues, and remove it once the issue is accepted as “valid”

I prefer the latter, for the reasons stated above:

  • it’s easy to search for issues that need attention
  • it’s easier to remove the label than adding it
  • it doesn’t add an extra label to all open issues

Another point of contention (somewhat irrelevant, but I might as well clarify), is who should approve issues:

  • some issues are clearly invalid: both triagers and experts can close them;
  • some issues are clearly valid: both triagers and expert can add/remove the label;
  • some issues are ambiguous: triagers should ping relevant experts and let them decide.

Finally, the name of the label should be decided based on whether the label should be removed or added:

  • if the label is added automatically to new issues: awaiting approval, needs approval, pending approval or something along these lines might work. Since relatively few issues will have the label for a short period of time before they are approved or rejected, it doesn’t matter if it’s a bit long.
  • if the label is added once the issue is approved: valid, approved, accepted, acknowledged might work.

In addition, I also wanted to ask you if you are still planning to use this label programmatically to have a bot pinging the OP/core-devs after a period of inactivity.


  1. meaning that all relevant labels have been set and the experts mentioned ↩︎

  2. meaning that either the bug has been confirmed valid, or a feature requested approved ↩︎

2 Likes

Looks like we’re beginning to converge towards some common understanding. Indeed, we are targeting different problems as you described.

I have a couple of comments on what you wrote:

  1. I don’t know what “fully triaged” means. When would you say that an issue is fully triaged?

  2. I don’t think we should assume that all currently open issues are valid (re “it doesn’t add an extra label to all open issues”.)

I don’t think this is what will happen. There are many issues that are undecided for a long time. “valid” essentially means “we should definitely do something about this issue”. It’s often not an easy decision to make.

2 Likes