Why users cannot create Issues directly • Hacker News Board

Re: Why users cannot create Issues directly

#131

Post by trinix912 » Fri, Jan 02, 2026, 10:54 AM UTC

codeflo wrote: post #124

throwaway81523 wrote: post #104

Earlier quoted context omitted.

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.

> 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?

IMO it still has poor discoverability, constant filtering between the triage status flags and non-flagged stuff, stuff that might not have been flagged by accident, reporters putting tags on issues themselves, issues can only be closed by non-admins rather than truly deleted, random people complaining about this or that on unrelated tickets...

It all stems from the fact that all issues are in this one large pool rather than there being a completely separate list with already vetted stuff that nobody else can write into.

Re: Why users cannot create Issues directly

#132

Post by WhyNotHugo » Fri, Jan 02, 2026, 11:00 AM UTC

Personally, I find the distinction between “issues” and “discussions” annoying.

For one, it duplicates the efforts in checking for prior reports. I might try 5–6 sets of keywords, but now I have to do so for 2 separate trackers.

Tickets cannot be moved between trackers, so instead folks resort to duplicating it and moving discussions… which is entirely opaque if you’re following up via email: you won’t get any more notifications and your future replies are silently discarded.

As a maintainer, having two trackers per project never made sense to me, so I’ve disabled discussion everywhere.

This is mostly a criticism of how GitHub implemented this feature, not of the decision taken here.

Re: Why users cannot create Issues directly

#133

Post by spinningarrow » Fri, Jan 02, 2026, 11:05 AM UTC

WhyNotHugo wrote: post #132

Personally, I find the distinction between “issues” and “discussions” annoying. For one, it duplicates the efforts in checking for prior reports. I might try 5–6 sets of keywords, but now I have to do so for 2 separate trackers. Tickets cannot be moved between trackers, so instead folks resort to duplicating it and moving discussions… which is entirely opaque if you’re following up via email: you won’t get any more n…

Why would checking be duplicated? One would need to check only the discussions in this case, since issues will be created from discussions once something is ready to be worked on (as I understood it)

Re: Why users cannot create Issues directly

#134

Post by abenga » Fri, Jan 02, 2026, 11:07 AM UTC

samus wrote: post #122

abenga wrote: post #110

Earlier quoted context omitted.

Is there a straightforward way to have one-process-per tab in browsers without using significant amounts (O(n_tabs)) of memory?

There is no justification for that IMHO. The program text only needs to be in memory once. However, each process probably has its own instance of the JS engine, together with the website's heap data and the JIT-compiled code objects. That adds up.

I'd very much like a crash in one tab not to kill other tabs. And having per tab sandboxing would be more secure, no?

Re: Why users cannot create Issues directly

#135

Post by creatonez » Fri, Jan 02, 2026, 11:09 AM UTC

People complain about Github not allowing you to turn off issues and pull requests entirely, but I've always seen it as a positive. It means the truth about code quality, potential caveats, and better forked revisions can disseminate freely even when the author disappears. It becomes a spamfest at times, but is still probably a net positive for the ecosystem.

That being said, as long as you still have the discussion tab, auto-deleting all issues by default is not a big deal.

Re: Why users cannot create Issues directly

#136

Post by machomaster » Fri, Jan 02, 2026, 11:12 AM UTC

ozim wrote: post #87

ok123456 wrote: post #29

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.

I believe most of it is people expecting stuff to work differently, not having time to wrap their head around proper usage of system, because they need specific outcome and they don't need mastery of the tool. Downside is that "Facebookization" created a trend where people expect everything to be obvious and achievable in minimal amount of clicks, without configuring anything. Now "LLMization" will push the trend for…

It is weird to push the idea that Facebook is some kind of pinacle of good and easy to use UI. That's the first one. It's quite the opposite, with people constantly complaining how bad, clunky and confusing Facebook is. And it is not the recent trend either. It has always been this way and e.g. VK has always had a better UI/UX that Facebook (and Telegram's is better that Whatsapp's).

Re: Why users cannot create Issues directly

#137

Post by xixixao » Fri, Jan 02, 2026, 11:14 AM UTC

WhyNotHugo wrote: post #132

Personally, I find the distinction between “issues” and “discussions” annoying. For one, it duplicates the efforts in checking for prior reports. I might try 5–6 sets of keywords, but now I have to do so for 2 separate trackers. Tickets cannot be moved between trackers, so instead folks resort to duplicating it and moving discussions… which is entirely opaque if you’re following up via email: you won’t get any more n…

At the very least I think what matters here is the process. The same exact process could be implemented via, for example, issue labels. It would not be hard for maintainers to search for issues with label "bug", which only maintainers can assign. There are clear UX tradeoffs between the two approaches.

Re: Why users cannot create Issues directly

#138

Post by randyrand » Fri, Jan 02, 2026, 11:16 AM UTC

bob1029 wrote: post #112

> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. Who does this project actually serve? The "users", or someone else? If I'm getting overwhelmed with hundreds of issues per week about some confusion around installation or use, I think those issues are completely justified. Something should probably be fixed if the happy path is…

It serves the open source maintainers, who enjoy working on it.

Re: Why users cannot create Issues directly

#139

Post by smallnix » Fri, Jan 02, 2026, 11:24 AM UTC

trinix912 wrote: post #131

codeflo wrote: post #124

Earlier quoted context omitted.

> 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?

IMO it still has poor discoverability, constant filtering between the triage status flags and non-flagged stuff, stuff that might not have been flagged by accident, reporters putting tags on issues themselves, issues can only be closed by non-admins rather than truly deleted, random people complaining about this or that on unrelated tickets... It all stems from the fact that all issues are in this one large pool rath…

Sounds like it could be fixed by making it configurable to hide all issues without a certain tag (or auto-apply a hiding tag) for the issues "landing page".

Re: Why users cannot create Issues directly

#140

Post by philipallstar » Fri, Jan 02, 2026, 11:31 AM UTC

machomaster wrote: post #136

ozim wrote: post #87

Earlier quoted context omitted.

I believe most of it is people expecting stuff to work differently, not having time to wrap their head around proper usage of system, because they need specific outcome and they don't need mastery of the tool. Downside is that "Facebookization" created a trend where people expect everything to be obvious and achievable in minimal amount of clicks, without configuring anything. Now "LLMization" will push the trend for…

It is weird to push the idea that Facebook is some kind of pinacle of good and easy to use UI. That's the first one. It's quite the opposite, with people constantly complaining how bad, clunky and confusing Facebook is. And it is not the recent trend either. It has always been this way and e.g. VK has always had a better UI/UX that Facebook (and Telegram's is better that Whatsapp's).

But still, compared to something like email, the previous standard for most people, Facebook was an unbelievable step forward. People complain about anything.