Live data from Hacker News

Why users cannot create Issues directly

github.com

311–320 of 320 posts

Re: Why users cannot create Issues directly

#311
post #305

Earlier quoted context omitted.

This is not about understanding the message, but switching user mental activity. I go myself in the similar situations many times. One example: I tried to pay my bills in online bank application, but got into error. After several attempts, I did read message and it say "Header size exceed..." . It give me clue that app probably put too much history into cookies. Clear browser data, log in again, and all got works. Ev…

> This is not about understanding the message, ... 99% of the population have no idea what "Header size exceeded" means, so it absolutely is about understanding the message, if the devs expect people to read the error.

Yeah, I would certainly not expect the user to understand what to do about a "Header size exceeded" error.

But I WOULD expect the user, when sending a message to support, to say they're getting a "Header size exceeded" error, rather than just say "an error".

Re: Why users cannot create Issues directly

#312

Earlier quoted context omitted.

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

Facebook is a step forward in terms of features. But it is a clear regression in terms of UI, easiness, usability, understandability of email. Email is very simple in both concept and practice.

I think I disagree - when it comes to sharing large files, something like a video, or even a picture in 2005, email was nowhere near as good. And also having a place to comment on things without the stacking up of reply chrome is genuinely better.

Re: Why users cannot create Issues directly

#313

Earlier quoted context omitted.

Facebook is a step forward in terms of features. But it is a clear regression in terms of UI, easiness, usability, understandability of email. Email is very simple in both concept and practice.

I think I disagree - when it comes to sharing large files, something like a video, or even a picture in 2005, email was nowhere near as good. And also having a place to comment on things without the stacking up of reply chrome is genuinely better.

> when it comes to sharing large files, something like a video, or even a picture in 2005, email was nowhere near as good.

That's just a stupid limitation and not even a technical one. You could happily send GBs over email. You can also easily filter allowed attachment size by sender on the recipient side, because by the time the attachment size is told, both information was already provided.

Re: Why users cannot create Issues directly

#314
Thanks so much to Henryclarkethicalhacler for helping me hack into my husband's phone so I could see what he is up to and I was able to catch him red handed, now I am out and a lot happier credit goes to earlier mention hacker for a good job. If you are also interested in any hack job you can contact him via his email – HENRYCLARKETHICALHACKER@ GMAIL. COM

Tell him Victoria refer you

Re: Why users cannot create Issues directly

#315

Earlier quoted context omitted.

That's a shame to hear. I had to give up on Ghostty because of its memory leak issue. Granted, it was on an 8GB system, but that should be enough to run a terminal without memory exhaustion a few times a week. Foot has been rock solid, even though it lacks some of Ghostty's niceties.

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.…

I also see ghosty consume a massive amount of memory and periodically need to restart.

Re: Why users cannot create Issues directly

#316

We've been doing this on the Renovate project for years, and it's been hugely useful - we get a lot of reports that users feel to be a bug, but are often misunderstanding or expectations about behaviour that isn't necessarily true. There are absolutely bugs that get reported - either in functionality or documentation - but by requiring a level of triage in Discussions before promoting them up to Issues is a great way…

I've written some more about why we've settled on this: https://www.jvt.me/posts/2026/01/07/renovate-why-discussions...

Re: Why users cannot create Issues directly

#317

Earlier quoted context omitted.

Facebook is a step forward in terms of features. But it is a clear regression in terms of UI, easiness, usability, understandability of email. Email is very simple in both concept and practice.

I think I disagree - when it comes to sharing large files, something like a video, or even a picture in 2005, email was nowhere near as good. And also having a place to comment on things without the stacking up of reply chrome is genuinely better.

Email was created for email, not for file sharing of massive files (even though nothing stops). Facebook is even worse than email at sharing large files, video files or even pictures (like, imgur is much better).

Commenting on things is from a list of features (to be distinguished from UX/UI) I talked about.

Re: Why users cannot create Issues directly

#318

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've had the experience of getting to sit beside several categories of people across my career and watch them attempt to do something which is causing issues or errors. The pattern I have seen the most is what I can only describe as speedrunning the error. People will try to do the thing they (think they) know how to do. When information or error comes available on the screen, they completely ignore it; if it is a popup, it is closed as quickly as possible and if it is shown somewhere on the screen that doesn't interrupt their flow, then it is completely ignored.

I have given instructions to repeat, but more slowly, and people will still click through errors without a chance to read. I have asked people to go step by step and pause after every step so we can look at what's going on, and they will treat "do thing and close resulting error" as a single step, pausing only after having closed the error.

The only explanation I have that I can understand is that closing errors and popups is a reflex for many people, such that they don't even register doing it. I don't know if this is true or if people would agree with it.

I've seen this with programmers at all levels of seniority. I've seen it with technically capable non-programmers. I've seen it with non-technical people just trying to use some piece of software.

The only thing that's ever been effective for me is to coach people to copy all text and take screenshots of literally everything that is happening on their screen (too many narrow screenshots that obscure useful context, so I ask for whole-screen screenshots only). Some people do well with this. Some never seem to put any effort into the communication.

Re: Why users cannot create Issues directly

#319

Earlier quoted context omitted.

Totally on board with this gripe. Absolutely infuriating. But just one minor devil's advocate on the HTTP 403, although this doesn't excuse it at all. In Azure "private networking", many components still have a public IP and public dns record associated with the hostname of the given service, which clients may try to connect to if they aren't set up right. That IP will respond with a 403 error if they try to connect…

> That IP will respond with a 403 error if they try to connect to it. So Azure is indirectly training people that 403 potentially IS a "network issue"... You are not describing a network issue. You're sending requests that by design the origin servers refuse to authorize. This is basic HTTP. https://datatracker.ietf.org/doc/html/rfc7231#page-59 The origin servers could also return 404 in this usecase, but 403 is more…

They're not, but the point is that users can see the 403 due to network errors. If vpn + networking work then the user can access the resource through the private interface. If there are issues with network routing or VPN then they end up on the public interface and get 403. So from the user perspective the same action can result in success or 403 based on whether there are network issues.

Re: Why users cannot create Issues directly

#320

Earlier quoted context omitted.

Joel Spolsky solved this over 25 years ago https://www.joelonsoftware.com/2000/04/26/designing-for-peop...

That solves nothing, just describes the problem.

Well I know where you stand regarding P = NP
Post reply on HN