Converting Discussions into Tracked Issues

[HerrLevin]

I’d like to propose a small change to how we handle feature ideas in this repo.
Currently, concepts get discussed here and then fade away — or a developer picks something up directly without a reference, making it hard to track progress or for others to contribute.

The idea: When a discussion reaches enough interest and enough people show interest / we maintainers agree the concept is solid, an admin will convert it into an Issue. This way, the idea has a proper home, makes it open for anyone to pick up, and ensures PRs can reference it for better traceability.

What this means in practice:

• Keep sharing ideas here in Discussions as usual
• If a concept gains traction, it gets promoted to an Issue
• Anyone — not just the original author — can then take it on
• PRs should reference the issue they address

This keeps our backlog intentional while lowering the barrier for contributors to find meaningful work.

Thoughts? Happy to hear if anyone sees a downside to this flow. :)

[HerrLevin]

Addition to that: I just realised that we have many open features in the discussions that were already implemented. Converting discussions into features would prevent that a bit, b/c they're better linkable, etc.

[MrKrisKrisu]

I think the idea makes sense in principle, but I’m a bit hesitant about moving feature requests into Issues too quickly.

Right now, I actually like the strict separation we have: Issues are bugs, Discussions are feature ideas. It keeps the issue tracker focused on concrete problems and makes it much easier to see what needs fixing first.

My concern is that once feature requests also become Issues, the tracker may start to lose that clarity. Even with good intentions, open feature Issues can easily look like committed or prioritized work, and bugs end up competing with ideas for attention.

I do see the benefit in having more traceability for ideas that gain traction, especially if someone wants to pick them up later. I just think it would be good to preserve the current distinction as much as possible.

Maybe a middle ground would work better: keep feature requests in Discussions by default, and only create an Issue once a feature is explicitly accepted, clearly scoped, and actually ready to be worked on.

I’d also strongly prefer that such an Issue has a clear owner from the start. Simply creating an Issue and leaving it at „someone will probably do it” does not feel very useful in an open source project.

If a feature gets promoted into an Issue, I think it should ideally happen because someone is actually committed to implementing it.

[MrKrisKrisu]

On the other hand, to be fair, I have to say that since we switched to this separation, GitHub has introduced new features for issues, and the bug/feature/task type, for example, is quite nice. Together with the project feature, it's also quite nice.

[HerrLevin]

Even with good intentions, open feature Issues can easily look like committed or prioritized work, and bugs end up competing with ideas for attention.

I’d also strongly prefer that such an Issue has a clear owner from the start. Simply creating an Issue and leaving it at „someone will probably do it” does not feel very useful in an open source project.

I'd also like to keep it clear, that tracked features have a clear owner. But there are good feature requests that are doable by anyone but stall here b/c we as maintainers don't really want to implement it or simply don't have the time to implement it.

My approach would be:

• Planned features get assigned to the person wanting to implement it
• Good features with enough user support get published without an assignee and get tagged as such, so that any person can grab it and implement it – improving our open source approach
• Bigger planned features (e.g. migration from numeric IDs to UUIDs) get published as a tagged parent-feature (epic) with multiple sub-tasks that fall into either of the above points