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

271–280 of 320 posts

Re: Why users cannot create Issues directly

#271

Post by machomaster »

philipallstar wrote: post #140
machomaster wrote: post #136

Earlier quoted context omitted.

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.

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.

Re: Why users cannot create Issues directly

#272

Post by [deleted] »

stonogo wrote: post #267
eqvinox wrote: post #260

Earlier quoted context omitted.

> I hate to break it to you, but all the other ticket systems do this by piling automation on top as well. The rebuke to your comment is right in your comment: "other ticket systems do this by…" The ticket system does it. As in, it has it built-in and/or well integrated. If GitHub had the same level of integration that other ticket systems achieve with their automation, this'd be a non-issue. But it doesn't, and it's…

No, it's not that well integrated. They don't call it 'tags' but they work exactly the same way. JIRA, the most commonly cited example in this thread, has a whole separate engine for it and your JIRA admin builds the ticket flow manually. All the way back in RT this sort of thing was handled by a cron job. Github leveraging actions to accomplish this isn't much of a difference. P.S. I didn't ask

[deleted]

Re: Why users cannot create Issues directly

#273

Post by hdjrudni »

eviks wrote: post #50
8n4vidtmkvmk wrote: post #48

Earlier quoted context omitted.

For one, it might require several rounds of back and forth before its ready to receive the tag, but now the details are spread across several comments instead of neatly at the top

No, you can always summarize details neatly at the top, you can edit comments, you know?

Still seems like a messier workflow and it might leave behind a dozen comments not related to the progress of the ticket.

Re: Why users cannot create Issues directly

#274

Post by monkey34 »

cinntaile wrote: post #254
sowbug wrote: post #241

Earlier quoted context omitted.

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 (all?) photo apps include a crop function, allowing your mom just crop out everything else.

I hope you’re being sarcastic. If not, expecting someone’s parent to know how to use a photo app’s crop functionality just to communicate an error state is a failure of understanding typical streaming app users.

Re: Why users cannot create Issues directly

#275

Post by tynorf »

gizmo686 wrote: post #37
tynorf wrote: post #25

Earlier quoted context omitted.

Chrome on my work laptop sits around 20-30GB all day every day.

How much would it take up if there was less RAM available. A web browser with a bunch of tabs open but not active seems like the type of system that can increase RAM usage by caching, and decrease it by swapping (either logically at the application level, or letting the OS actually swap)

The computer has 18GB of total RAM so I would hope that it’s already trying to conserve memory.

It’s kind of humorous that everyone interpreted the comment as complaining about Chrome. For all I know, it’s justified in using that much memory, or it’s the crappy websites I’m required to use for work with absurdly large heaps.

I really just meant that at least for work I need more than 8GB of RAM.

Re: Why users cannot create Issues directly

#276

Post by pixl97 »

Sohcahtoa82 wrote: post #265
traceroute66 wrote: post #248

Earlier quoted context omitted.

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

There are people that when using a computer, if anything goes remotely wrong, they completely lose all notions of language comprehension. You can make messages as non-technical as possible and provide troubleshooting steps, and they just throw their hands up and say "I'm not a computer person! I don't know what it's telling me!" 20 years ago, I worked the self-checkout registers in retail. I'd have people scan an ite…

>completely lose all notions of language comprehension

I see this pretty often. These aren't even what should be called typical users in theory. They are people doing a technical job and were hired with technical requirements, an application will spit out a well written error message in the domain they should be professionals in and their brain turns off. And ya, it ends up in a call to me where I state the same thing and they figure the problem out.

I really don't get it.

Re: Why users cannot create Issues directly

#277

Post by BatmanAoD »

traceroute66 wrote: post #248
Sohcahtoa82 wrote: post #232

Earlier quoted context omitted.

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

This seems to be missing the point. Sometimes users see error messages. Sometimes they're good, sometimes they're bad; and yeah, software engineers should endeavor to make sure that error behaviors are graceful, but of all the not-perfect things in this world, error handling is one of the least perfect, so users do encounter unfortunately ungraceful errors.

In that case (and even sometimes in the more "graceful" cases), we don't always expect the user to know what an error message means.

Re: Why users cannot create Issues directly

#278

Post by mamcx »

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…

My theory is that the best, absolute best predictor if someone could be a good programmer (or is) is the ability to read exactly what is written.

Is not math, logic or any of that asides. Is the actual ability to read, exactly, without adding or removing anything.

Re: Why users cannot create Issues directly

#279

Post by johnisgood »

garfieldnate wrote: post #236

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

Reminds me of EggDrop (famous old IRC bot written in Tcl) with lots of "die" in the configuration file. :D

Re: Why users cannot create Issues directly

#280

Post by [deleted] »

stonogo wrote: post #267
eqvinox wrote: post #260

Earlier quoted context omitted.

> I hate to break it to you, but all the other ticket systems do this by piling automation on top as well. The rebuke to your comment is right in your comment: "other ticket systems do this by…" The ticket system does it. As in, it has it built-in and/or well integrated. If GitHub had the same level of integration that other ticket systems achieve with their automation, this'd be a non-issue. But it doesn't, and it's…

No, it's not that well integrated. They don't call it 'tags' but they work exactly the same way. JIRA, the most commonly cited example in this thread, has a whole separate engine for it and your JIRA admin builds the ticket flow manually. All the way back in RT this sort of thing was handled by a cron job. Github leveraging actions to accomplish this isn't much of a difference. P.S. I didn't ask

[deleted]
Post reply on HN