Get our issue management game in order

[Piedone]

Is your feature request related to a problem? Please describe.

We have about 1300 open issues. This alone is not necessarily a problem, but there are also ~350 without a milestone, so most possibly not triaged. Around 10% don't have any replies (which is BTW great that only this much, but it'd be better to get replies from the community for each issue), though less than that are opened by external community members.

There are 14 issues marked as "good first issue", which is a relatively low number.

We don't have much of a structure for priority, except for milestones for the immediately next version, 1.x, and the backlog. This is perhaps enough but at least should be documented and more apparent what they mean. There are also rarely used P* labels.

All of this doesn't help first contributors, or otherwise people looking to contribute. We don't have a clear policy on prioritization, and everyone basically works on what they prefer (And we should still have fun! That's kind of one of the points, but still, we should be able to communicate more clearly what the plan is.).

Describe the solution you'd like

• Triage all yet untriaged issues.
• Every week, make sure to triage all new issues.
• Add a comment, at least automatically, when an issue is triaged. As an issue author you don't get notified when your issue's milestone is updated, only about comments. So you may be left wondering. But something along the lines of "Thank you for submitting this issue, we triaged it and set the milestone according to the priority we think is appropriate (see <link to docs> on how we triage and prioritize issues). This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions <link>." Or close with a proper comment.
• Automatically close issues where we're waiting for some feedback from the author. This is NOT the same as automatically closing issues that haven't seen any recent updates (because that would require people to spam "yep, still an issue"); rather, close the issue if it's not clear and we asked the author something but they didn't reply. actions/stale can be used for this, with days-before-issue-stale: -1. That way, issues won't be marked as stale automatically, but if we do that manually (like adding the stale label, or feedback requested, see comments below) then it'll close automatically after a configured period of time.
• Label a person's first issue (or the first few) so we know to be especially gentle and patient with them. - Thinking more about it, this is not actually really necessary.
• Make it clear how we manage priorities. Perhaps get rid of the P* labels and instead only use milestones, with something like 1.8.2 (i.e. the next patch version, now v1.8.1 being current) indicating the highest prio for serious regressions and other urgent bug fixes, the next minor version for less urgent bug fixes and feature requests, and backlog for everything else.
• For contributors, document that you can sort issues by most commented and most thumbs up (as well as other reactions similarly). These correlate with popularity, i.e. we can see what the community most wants. - Revising contribution docs (Lombiq Technologies: OCORE-154) #15706
• Document all of the above. We have the CONTRIBUTING.md file, but I'd move its content out to the docs site (similar to this page to have something perhaps more appealing and link it from the MD file.

Describe alternatives you've considered

Nothing else comes to my mind.

Related: #15029 and #14585.

[Piedone]

This looks useful: #14585.

[sebastienros]

The dotnet org uses an MS bot that closes issues after some time of non-activity, or when tagged with "feedback requested" and not provided after some time.

[sebastienros]

Thank you for submitting this issue, we triaged it and set the milestone according to the priority we think is appropriate

[Piedone]

The "feedback requested" auto-close is great, we should probably do something like that. I had something like this in mind for PR too under #15029.

The inactivity auto-close I passionately hate :D because it can close issues that the development team didn't keep up to date, and requires people to continuously bump issues.

[Piedone]

I can work on this and #15439 once #15029 is closed (just waiting for reviews there) because this builds on the docs improvements there.

[Skrypt]

I think we could close PR's that are too old and at least keep an issue related with it so that we can still see the reference. If a PR is good but half done then we can still keep it for a contributor to pick up the remaining work.

[Piedone]

For PRs, see #15029. Stale PRs are now automatically closed after 75 days.

[Piedone]

I opened a PR for those pieces that need to be addressed with code. I have some remarks/questions there as well, please check: #15820.

Next, I'll go through issues. There are almost 500 issues without labels; the PR should fix issues being created without labels too. I'll label those appropriately, foremost as bug/enhancement. Then, the untriaged issues need to be triaged.

[Piedone]

I cleaned up labels too. Removed some unused ones, as well as "discussion" and "question": those open issues that were suitable for this (I checked all of them one by one) I converted to discussions, otherwise changed their labels. I removed them so we don't try to use them again (and thus keep dangling issues forever).

[hishamco]

Seems Zoltan starts to call ZoltanGC.Collect() :)

[Piedone]

Yep :).

[Piedone]

Please review the linked PR.

Currently, I'm going through the issues without labels (which include issues with and without the milestone set too).

Next, I'd go through the issues without milestones, starting with the oldest ones, and set their milestones according to my best judgment (if the issue is valid in the first place). This is because we have 300 such issues and it's hopeless to try to go through them in meetings. If you disagree, please let me know.

[Piedone]

No more issues without labels! I've gone through them all. There are about 200 untriaged issues (i.e. without milestones) though.

[hishamco]

Thanks for all the efforts Zoltan

[Piedone]

Triaged all old issues (i.e. all the ones up to the last month), closed a lot of invalid/outdated ones. We're now below 1000 open issues and <10 untriaged ones! For the last year or so it hovered around 1300. I think we'll manage to triage new issues now.