Why users cannot create Issues directly • Hacker News Board

Re: Why users cannot create Issues directly

#231

Post by ChuckMcM » Fri, Jan 02, 2026, 6:16 PM UTC

throwaway81523 wrote: post #104

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.

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.

Discussion systems all the way down :-). This is a fair assessment of the github issues system. I suspect that because git(1) can be a change control system for anything there is never any hope of making an effective issue tracker for a particular thing it is being used to manage change on. The choice the project made to allow the developers to determine when something was an issue is essentially adding a semantic layer on top of issues that customizes it for this particular corpus of change management.

Re: Why users cannot create Issues directly

#232

Post by Sohcahtoa82 » Fri, Jan 02, 2026, 6:20 PM UTC

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.

> people who don't read error messages

One of my pet peeves that I will never understand.

I do not expect users to understand what an error means, but I absolutely expect them to tell me what the error says. I try to understand things from the perspective of a non-technical user, but I cannot fathom why even a non-technical user would think that they don't need to include the contents of an error message when seeking help regarding the error. Instead, it's "When I do X, I get an error".

Maybe I have too much faith in people. I've seen even software engineers become absolutely blind when dealing with errors. I had a time 10 years ago as a tester when I filed a bug ticket with explicit steps that results in a "broken pipe error". The engineer closed the ticket as "Can Not Reproduce" with a comment saying "I can't complete your steps because I'm getting a 'broken pipe error'".

Re: Why users cannot create Issues directly

#233

Post by sigmonsays » Fri, Jan 02, 2026, 6:27 PM UTC

this project sure has a ton of open bugs

Re: Why users cannot create Issues directly

#234

Post by halyconWays » Fri, Jan 02, 2026, 6:30 PM UTC

I briefly tried to contribute to a popular AI project (a ChatGPT-like web-based interface) where I found some bugs and reported them as issues, with steps to reproduce. The maintainer closed them and moved them to discussions, which is what he did to any issue he didn't like or personally didn't believe mattered, I guess. Items in Discussions didn't get any attention, nor were follow-ups looked at. One of the issues even involved the total loss of user data on upgrade.

So this makes me think the developer here just doesn't like the idea of issues being reported on his project.

Re: Why users cannot create Issues directly

#235

Post by IshKebab » Fri, Jan 02, 2026, 6:34 PM UTC

xpe wrote: post #176

eduction wrote: post #41

> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features). Do I ever make mistakes? No. It’s the users who are wrong.

>> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features). > Do I ever make mistakes? > No. It’s the users who are wrong. This is a textbook example of being uncharitable. Framing matters a lot! If you frame somethi…

I disagree. He's just trying to educate these guys about usability.

Most people by default see "user got something wrong" and respond "rtfm" or "you don't understand" or "don't make mistakes".

The vast majority of people using Ghostty are not stupid. If they misunderstood something or made a mistake, it's highly likely that it could have been avoided with changes to improve Ghostty.

Re: Why users cannot create Issues directly

#236

Post by garfieldnate » Fri, Jan 02, 2026, 6:34 PM UTC

Not that not being able to open a ticket is not actually an implemented feature from GitHub; they simply added this issue template to let you know that you shouldn't open one:

*DO NOT OPEN A NEW ISSUE. PLEASE USE THE DISCUSSIONS SECTION.*

*I DIDN'T READ THE ABOVE LINE. PLEASE CLOSE THIS ISSUE.*

Re: Why users cannot create Issues directly

#237

Post by coxley » Fri, Jan 02, 2026, 6:36 PM UTC

mitchellh wrote: post #221

eviks wrote: post #204

Earlier quoted context omitted.

How does different count affect search? You can use a bookmark to change the view, and if using bookmarks is too much, ok, but that's not a bold universal reason. (also, what is "huge success" in methods of organizing issues?) bookmark: (and if your browser supports shortcuts, it can be as easy to open as remembering to type a single char) https://github.com/ghostty-org/ghostty/issues?q=is%3Aissue%2...

Here is an abridged set of reasons, just because it quickly turns into a very big thing: 1. The barrier to mislabel is too low. There is no confirmation to remove labels. There is no email notification on label change. We've had "accepted" issues accidentally lose their accepted label and enter the quagmire of thousands of unconfirmed issues. Its lost. In this new approach, every issue is critical and you can't do th…

Not to mention you can restrict who can file issues with permissions. So you have a forcing function, whereas hoping tags are correctly applied is a never ending battle.

Re: Why users cannot create Issues directly

#238

Post by kccqzy » Fri, Jan 02, 2026, 6:36 PM UTC

emil-lp wrote: post #168

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…

> I find the distinction between “issues” and “discussions” annoying The benefit is that all users who just ask for help, assistance, or are unable to install or use the software now have a place to ask. You shouldn't create an issue just because you get an error when installing, but it might be beneficial to still ask for help. If it is indeed a bug, then create a ticket, linking to the discussion. Normally, too man…

I personally don’t like discussions either. I treat issues to be issues experienced by the user. It doesn’t mean that there’s an issue caused by bugs in the software. User creates an issue that turns out to be caused by user not following instructions? Just help the user and close the issue.

Re: Why users cannot create Issues directly

#239

Post by scsh » Fri, Jan 02, 2026, 6:38 PM UTC

skobes wrote: post #147

mitchellh wrote: post #59

Earlier quoted context omitted.

Note that this is an active discussion where we're trying to get to a point of clarity where we can promote to an issue (when it is actionable). The discussion is open and this is the system working as intended! I want to clarify though that there isn't a known widespread "memory leak issue." You didn't say "widespread", but just in case that is taken by anyone else. :) To clarify, there are a few challenges here: 1.…

This illustrates the difficulty of maintaining a separation between bugs and discussions: > To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users In this case it seems you believe a bug exists, but it isn't sufficiently well-understood and actionable to graduate to the bug tracker. But the threshold of well-understood and actionable is fuzzy and subjective. Most bu…

I think these are valid concerns for a project maintainer to think through for managing a chosen solution but I don't think there is a single correct solution. The "correct", or likely least bad, solution depends on the specific project and tools available.

For bug reports, always using issues for everything also requires you to evaluate how long an issue should exist before it is closed out if it can't be reproduced(if trying to keep a clean issue list). That could lead to discussion fragmentation if now new reports start coming in that need to be reported, but not just anyone can manage issue states, so a new one is created.

From a practical standpoint, they have 40 pages of open discussion in the project and 6 pages of open issues, so I get where they're coming from. The GH issue tracker is less than stellar.

Re: Why users cannot create Issues directly

#240

Post by IshKebab » Fri, Jan 02, 2026, 6:38 PM UTC

franciscop wrote: post #116

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…

As an OSS maintainer myself, while the amount of tickets about a specific topic _might_ be loosely related to the quality of the docs/installation/etc, this hasn't been true in my observations. It's one of those explanations that sound very plausible on paper, but if you see real world issues it just doesn't happen, users will ask questions that are clearly explained in the first paragraph of the readme, en masse.

> clearly explained in the first paragraph of the readme

Yeah but people justifiably don't exhaustively read documentation. If people are getting confused because they didn't read some bit of documentation - even the first paragraph of the readme - then you shouldn't just dismiss them as stupid and bask in your superior documentation-reading abilities. You should think about how to resolve that confusion in a way that they would actually see it.

It's hard to explain how to do that without a concrete example, but it usually is possible. It's also usually more work than just replying RTFM, but you should at least be aware that you are choosing not to bother.