In my experience, this is mainly caused by planning in too much detail, too far ahead. And then your plans change and it's a bunch of cl noise you have to clean up or live with.

The only system I've stuck with for my FLO projects is the following:

- One tag (or milestone) named "someday/maybe". This is for things that are reasonable to do (you'd accept patches), but not worth the time/effort for you to implement personally. It exists so you can filter them out without closing. - One milestone called "next release". Only add issues to this milestone when you've competed them. Note: don't close these issues yet; keeping them open results in more visibility and fewer duplicate bug reports.

When it's time to do a release, rename the "next release" milestone to the version of the release (ex: v2.4.1), close all the associated issues (making sure they're in the changelog as you go), and replace it with a fresh "next release" milestone.

---

In the past I also had a "planned" milestone, but it's redundant with someday/maybe; anything open and not assigned to a milestone is planned.

Red Moon has the same order of magnitude of open issues as Buttplug, and not much of a community.

- If there were a larger community, I'd probably write a high-level roadmap, describing my vision and areas where it currently falls short.

- If there were other contributors or significantly more open issues, I'd add a "high priority" tag, limited to ~10 issues at a time, so there's a way to engage with less noise.