Automate triage/awaiting reply labels for issues

[GfEW]

Developer TODO (don't remove)

• create new branch. put issue number at start of name
• update documentation
• merge and delete branch (don't squash because want commit history to see why I made changes)

I'm really glad keymapper development is "slower" as opposed to "stopped". It's a shame there're only two of you devs, understandably busy working for a living. As I'm not able to contribute to the code, I'd like to suggest a gradual improvement in issue handling to allow the project to profit more efficiently from your precious time.

Apparently, the quality of a considerable portion of issues filed to keymapper is so low that they can't be reasonably worked on without prior substantial improvment. Since the capacity you can afford to keymapper is tightly limited, I suppose that real, high quality issues would benefit if you could focus on them.

Therefor, two suggestions:

1. New issues:
   Auto-assign a distinctive label to new issues, e. g. new or needs triage.
   Such a label would also serve as a guide for assistive non-devs like myself to select issues that need to be checked for necessary clarifications or improvements, so you could spare the time.
2. Waiting for user input:
   For the likes of Potential crash on Android 14 #1311, a label like waiting for user or waiting for reply would allow to filter issues whose potential progress currently depends on action by the reporter. Thereby, they can remain open (rather than closed prematurely) without spamming the open issues list (as if they were ready to be worked on). I've seen this label in good, frequent use in other repos. Even though I don't know the details, github seems to provide some mechanism that auto-removes this label as soon as the reporter replies.

[sds100]

Hi @GfEW, these are great suggestions tbh. Its kind of been in the back of mind that I need to improve the system here 😂 We are now at 1314 issues... never thought it would happen.

[GfEW]

Great to see you like these suggestions and have created both labels already. I can't track progress on the automation side, so I'll leave it up to you to close this issue when you deem it done.

[GfEW]

One more thing:

I've checked your list of available labels, and so far, saw none denoting a possible triage result.

To make triage fully functional (beyond ensuring issue reporting quality), some triage result labels could facilitate proper prioritization, e. g.:

• upstream (if applicable): blocked by upstream issues
• need help: invite knowledgable contributors to a specific issue
• niche/won't fix: low prio, too high effort etc.
• ASAP/urgent: high prio, maybe security related, heavy impact etc..

That said, labels obviously can be useful only where really used and maintained. Since label granularity is a matter of personal workflow preferences and taste, please take the above ideas as nothing more than inspiration.

[sds100]

Good idea, I added a won't fix label. I generally keep track of ASAP/urgent issues by putting them in a project - and they rarely happen at this point. I've made the issue templates add the need triage label automatically as well. Thanks for the suggestions, I'll close this for now.

[GfEW]

p.s. Yet one more related remark (hopefully last on label improvement for now):

Because

• needs triage indicates the need for a decision, and
• won't fix indicates a result of that decision,

the former stops making sense as soon as the latter is applied. The same goes for issues that are closed for other reasons, e. g. when they're done.

Misplaced labels tend to require additional user side attention/judgement, and thereby, to fall short of the efficiency they could provide if applied consistently.
OTOH, maintaining consistency by removing invalid labels manually also requires extra attention and clicks.

So, how about auto-removing needs triage whenever an issue is labeled won't fix, or closed?

(Just saw this very issue still labeled needs triage despite being closed.)

[sds100]

Very good case in point, ill figure out a way haha