zlacker

>>xpe+(OP)
100% agree.

If it's someone else's project, they have full authority to decide what is and isn't an issue. With large enough projects, you're going to have enough bad actors, people who don't read error messages, and just downright crazy people. Throw in people using AI for dubious purposes like CVE inflation, and it's even worse.

>>ok1234+Mh
The trouble here is that github issues is crap. Most bug trackers have ways to triage submissions. When a rando submits something, it has status "unconfirmed". Developers can then recategorize it, delete it, mark it as invalid, confirm that it's a real bug and mark it "confirmed", etc. Github issues is mostly a discussion system that was so inadequate that they supplemented it with another discussion system.

>>throwa+lI
> Most bug trackers have ways to triage submissions. When a rando submits something, it has status "unconfirmed". Developers can then recategorize it, delete it, mark it as invalid, confirm that it's a real bug and mark it "confirmed", etc.

As far as I'm aware, most large open GitHub projects use tags for that kind of classification. Would you consider that too clunky?

>>codefl+6O
This still puts the onus on the developers to categorise the issues which I'm guessing they don't want to do.

>>asdfao+TW
They're already doing that by moving discussions to issues. In fact it's more work for them because they have to actually create the issue instead of just adding a "confirmed bug" label or whatever.

I guess it probably leads to higher quality issue descriptions at least, but otherwise this seems pretty dumb and user-hostile.

>>IshKeb+kA1
There’s a one-click button to convert from discussion to issue (and vice versa). It’s hardly more work. But I do feel like discussions are kind of hidden and out of the way on GitHub.

On repos I maintain, I use an “untriaged” label for issues and I convert questions to discussions at issue triage time.