Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why users cannot create Issues directly

github.com

Post reply on HN
Print view View original

241–250 of 320 posts

Re: Why users cannot create Issues directly

#241

Post by sowbug »

Sohcahtoa82 wrote: post #232
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 seekin…

If I can victim-blame for a moment, I don't know what my mom is supposed to do when a streaming service on her TV says there's a problem and will she please report a GUID to the support department.

No, my mom is not eidetic, and no, she's not going to upload a photo of her living room.

Totally agree with you, though, when the full error message is at least capable of being copied to the clipboard.

Re: Why users cannot create Issues directly

#242

Post by pmontra »

It's more or less what a customer of mine does with its support tickets. We receive the tickets, interact with customers, solve their problem and sometimes in the process we open one or more issues that enter into the backlog. Issues originated by a ticket usually have a high priority.

Re: Why users cannot create Issues directly

#243

Post by bflesch »

Maybe "issue" should then be renamed into "TODOs". Because end users have "issues" with a product, it is up for someone with more knowledge to identify if the "issue" is PEBKAC, WONTFIX, FEATURE, or actually a TODO for the developers.

The term "discussion" does not have anything to do with this.

I understand these are all github choices of terms, and it should also be reframed properly by github.

Re: Why users cannot create Issues directly

#244

Post by stonogo »

eqvinox wrote: post #206
Aurornis wrote: post #189

Earlier quoted context omitted.

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

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…

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

Re: Why users cannot create Issues directly

#245

Post by rorytbyrne »

xpe wrote: post #185
rorytbyrne wrote: post #170

Earlier quoted context omitted.

I spotted Ghostty using 20GB+ memory a few days ago on MacOS (according to Activity Monitor). I went through all my tmux sessions, killed everything, it was still 20GB+ so I re-started Ghostty. If I see it happen again, I'll take some notes.

On some level, that's impressive. Any idea of how long Ghostty was alive? Maybe this a new feature where Ghostty stores LLM model parameters in the terminal scrollback history? /s

Not which parts of this are sarcastic or not, but it was probably running for a few weeks. High variance on that estimate though. I was running 5+ Claude Code instances and a similar number of vim instances.

Re: Why users cannot create Issues directly

#246

Post by mprovost »

marksomnian wrote: post #107
ohyoutravel wrote: post #100

Earlier quoted context omitted.

I’ve been a very happy user for 2025, with some edge cases around the terminal not working on remote shells. I haven’t seen any memory leaks, but wanted to say I appreciate this detailed response.

In my experience, the remote shell weirdness is usually because the remote shell doesn’t recognise ghostty’s TERM=xterm-ghostty value. Fixed by either copying over a terminfo with it in, or setting TERM=xterm-256color before ssh’ing: https://ghostty.org/docs/help/terminfo

The terminfo database is one of those thankless xkcd dependencies. In this case, it's been thanklessly maintained since forever by Thomas Dickey.

https://xkcd.com/2347/

Re: Why users cannot create Issues directly

#247

Post by NoGravitas »

Maxious wrote: post #6

For example, memory leak investigation is currently spread across discussions, x/twitter and discord https://x.com/mitchellh/status/2004938171038277708 https://x.com/alxfazio/status/2004841392645050601 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/9962 but has not graduated to issue worthy status

It can also be remarkably picky about GPUs, even otherwise well-supported integrated GPUs, but any discussion of this is declared a GTK problem (or an nvidia problem, even on intel).

Re: Why users cannot create Issues directly

#248

Post by traceroute66 »

Sohcahtoa82 wrote: post #232
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 seekin…

> I do not expect users to understand what an error means

I'm not sure I agree.

Reason ?

The old adage "handle errors gracefully".

The "gracefully" part, by definition means taking into account the UX.

Ergo "gracefully" does not mean spitting out either (a) a meaningless generic message or (b) A bunch of incomprehensible tech-speak.

Your error should provide (a) a user-friendly plain-English description and (b) an error ID that you can then cross-reference (e.g. you know "error 42" means the database connection is foobar because the password is wrong)

During your support interaction you can then guide the user through uploading logs or whatever. Preferably through an "upload to support" button you've already carefully coded into your app.

Even if your app is targetting a techie audience, its the same ethos.

If there is a possibility a techie could solve the problem themselves (e.g. by RTFM or checking the config file), then the onus is on you to provide a suitably meaningful error message to help them on their troubleshooting journey.

Re: Why users cannot create Issues directly

#249

Post by mitchellh »

sesm wrote: post #165
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.…

Regarding point 4: why the user should be familiar with the codebase to investigate it? Shouldn't they create a memory dump and send it to dev team?

They don't have to be, but without a reproduction for maintainers, its up to the end users to provide enough information for us to track it down, and this user hasn't been able to yet.

Re: Why users cannot create Issues directly

#250

Post by johnfn »

Etheryte wrote: post #77
lijok wrote: post #69

A couple of big projects in the python space use this approach. Pisses me off as a power user. I find what are clearly bugs all the time, and am forced through a funnel that places the burden on me. Stinks of arrogance to think your project is that rock solid you should add friction for reporting bugs. Especially in “forever v0” projects. But, I am super lazy.

[flagged]

This is like being forced to pay 50 bucks to your apartment because someone else broke the door. Then when you complain about it people tell you you’re entitled!
Post reply on HN