Should new github issues be for groomed, already-discussed items?

[RollingStar]

In the past, I've used this and other github 'issue' pages as almost a discussion forum. I have identified issues without a clear understanding of how to fix them. Some issues are hotly debated, and there may be multiple proposals to deal with them.

All this discussion and non-concrete suggestions could clutter up the issue page for someone who just wants to code and contribute to beets without having to come up with the solution too. We could separate them in an agile-ish way.

https://www.agilealliance.org/glossary/backlog/

Bug reports/github issues would be made by devs/approved contributors after the appropriate reproducibility / issue area was found, and a solution proposed, in another forum (either Github Discussions or Discourse).

I don't have a strong feeling on this. Maybe it would streamline things and make the work more bite-sized for those who want to do it, maybe it wouldn't have a difference. Obviously I don't think we should go back and make old issues fit this new concept.

[sampsyo]

Thanks for bringing this up, and I'm not sure either! The strategy we've been using to date is actually not too different: bugs/features are tagged needinfo while they're still "evolving," and then, when they eventually produce something actionable, we convert them into either bug or feature tickets. Often I'll change the title at that point to reflect the actionable version of the bug/request.

I guess the main trade-off is that starting new discussions would be lower-overhead, but converting them to "proper" issues would be higher-overhead?