Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
spectre.console contributions are largely made by a small set of dedicated contributors/maintainers, whom have less time than open issues (fairly common occurence in the OSS world). As such, we've been discussing how to stay motivated in the face of a growing backlog, fairly prioritise the outstanding issues, potentially introduce some kind of overall roadmap planning and guidance.
At one point, we even discussed and considered blanket closing inactive issues and PR's after a certain age, see the RFC for this idea here: #1422, "Mark PR's as stale after 300 days, close them after another 60 if no activity"
Proposal
github-readme-stats have addressed this exact issue through up/downvotes against issues/features/bugs/PRs, to give their contributor community a very clear steer what to focus their efforts on. Here's what you will find featured fairly prominently on their repository readme:
This seems like a great approach for spectre.console to adopt provisionally, and road test. This PR includes the GitHub Action workflow to generate the 'top issues dashboard', making use of this marketplace action: https://github.com/marketplace/actions/top-issues-action
Follow on work required, once this PR has been merged
Once the action has executed successfully for the first time and the 'top issues dashboard' been created (ie. the issue # for the dashboard will be known), then I will submit a second PR for:
Testing
I've successfully implemented the Top Issues Dashboard on a public repo I own, experimenting with different settings, see: https://github.com/FrankRay78/PatienceOS/issues