Just today I've had a "technical" dude complain about something "not working".

He even checked "thing A" and "thing B" which "looked fine", but it still "didn't work". A and B had absolutely nothing to do with each either (they solve completely different problems).

I had to ask multiple times what exactly he was trying to do and what exactly he was experiencing.

I've even had "web devs" shout there must be some kind of "network problem" between their workstation and some web server, because they were getting an http 403 error.

So, yeah. Regular users? I honestly have 0 expectations from them. They just observe that the software doesn't do what they expect and they'll complain.

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

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.

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

All of this is possible on GitHub issues and is in fact done by many projects, by this metric I dont see how GitHub Issues is any different than say, JIRA. In both cases, as you mentioned, someone needs to triage those issues, which would, of course, be the developers as well. Nothing gained, nothing lost.

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

Having used many issue trackers over the years (JIRA, custom tools, GH Issues), I've found GitHub issues to be very usable.

Especially with the new features added last year (parent tickets, better boolean search etc) although I'm not sure if you need to opt in to get those.

In fact, it's become our primary issue tracker at work.

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.

I take the Basecamp philosophy of, “If it’s important enough, we won’t be able to ignore it, and it’s ok for anything else to fall through the cracks until someone feels like working on it.”

Well, that’s a paraphrase, but I remember reading that rough idea on their blog years ago, and it strikes me as perfectly fine for many kinds of projects.

Yeah but the article / post linked does not say that they won't look at reports of bugs or security problems, just that they are using issues to manage things they have decided are issues that should be worked on, and so public reporting using issues tickets will mess up that system they have. It's purely about their project's use of the issues system in github.

Unfortunately there is no such magic bullet for trawling through bug reports from users, but pushing more work out to the reporter can be reasonably effective at avoiding that kind of time wasting. Require that the reporters communicate responsively, that they test things promptly, that they provide reproducers and exact recipes for reproduction. Ask that they run git bisect / creduce / debug options / etc. Proactively close out bugs or mark them appropriately if reporters don't do the work.

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

> If I can make a video with Sora by typing what I want in the box

IME, people cannot even articulate what they want when the know what they want, let alone when they don’t even understand what they want in the first place.

To be clear, I think discussions on the whole as a product are pretty bad. I'm not happy having to use them, but given my experience trying different approaches across multiple "popular" projects on GH, this approach has so far been the least bad. Although I'm still sad about it.

> Yeah but a good issue tracker should be able to help you filter that stuff out.

Agreed. This highlights GitHub's issue management system being inadequate.

(Note: I'm the creator/lead of Ghostty)

[flagged]