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.