Why users cannot create Issues directly

>>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
There are several automation solutions for GH issues. You could have an automatic “unconfirmed” tag applied to every user-created issue if you wanted.

>>Aurorn+dh1
RFC1925¹, section 2(3):

  With sufficient thrust, pigs fly just fine. However, this is
  not necessarily a good idea. It is hard to be sure where they
  are going to land, and it could be dangerous sitting under them
  as they fly overhead.

Translation: sure, you can make this work by piling automation on top. But that doesn't make it a good system to begin with, and won't really result in a robust result either. I'd really rather have a better foundation to start with.

¹ https://www.rfc-editor.org/rfc/rfc1925

>>eqvino+ax1
I hate to break it to you, but all the other ticket systems do this by piling automation on top as well.

>>stonog+t12
> I hate to break it to you, but all the other ticket systems do this by piling automation on top as well.

The rebuke to your comment is right in your comment: "other ticket systems do this by…"

The ticket system does it. As in, it has it built-in and/or well integrated. If GitHub had the same level of integration that other ticket systems achieve with their automation, this'd be a non-issue. But it doesn't, and it's a huge problem.

P.S.: I hate to break it to you, but "I hate to break it to you, but" is quite poor form.

zlacker