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

261–270 of 320 posts

Re: Why users cannot create Issues directly

#261

Post by foxygen »

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…

Let's not forget there are actual people behind open source projects. I think it is extremely rude to say those people should SERVE the users of their open source projects for free. The project "serve" the needs of the maintainers. If you as a user don't like something, that is entirely YOUR problem. Feel free to fork it and fix the bugs you think are worthy fixing.

Re: Why users cannot create Issues directly

#262

Post by efreak »

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…

I recommend posting (or lining to) this somewhere on GitHub, maybe in the pinned issue.

Re: Why users cannot create Issues directly

#263

Post by efreak »

zzzeek wrote: post #199

Yes this is the identical pattern we strive for at SQLAlchemy. However github has no option to close issues to contributors only. These folks do what we do, they have an issue template called "do not use this". big whoop. People blow through those all day so we're clicking on "convert to discussion" all day. Github please add this feature!

Some of it may be unintentional. I've created issues directly through the `gh` CLI before, and issue templates don't show up there at all. If I haven't actually cloned the repo (or, more frequently, if I have a sparse checkout/deleted the files to save space), I have no way of knowing that there's a template and I'll just `gh issue -R some/thing create`.

I finally moved on to the official GitHub app on mobile, but before that I used fasthub and other clients that had no idea about issue templates.

GitHub really needs to add permissions to issues, so that users can't create issues without the template; any kind of failure in creation is a sign that you're doing something wrong. The ability to add tags to issues when creating via CLI would also be helpful.

Re: Why users cannot create Issues directly

#264

Post by IshKebab »

franciscop wrote: post #252
IshKebab wrote: post #240

Earlier quoted context omitted.

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

I'd rather OSS authors write and improve the software and documentation for most people than do the very time-consuming, burnout-inducing free customer support you are suggesting here (especially for those not bothering of reading even the first paragraph of the documentation).

It's not customer support; it's giving the product good usability. I would much rather they do that than waste time writing documentation that people won't read.

I think a concrete example would help here. Let me find one from this repo...

Ok after looking through about 20 discussions I was actually unable to find a single one that was a misunderstanding or misconfiguration on the user's part. They appear to all be real bugs (or feature requests), and very high quality ones at that.

So I think their assertion that 80-90% of what people think are bugs are actually not is total and utter bullshit.

That's kind of unrelated to what we were discussing though; misunderstandings due to poor usability do happen but I guess we can't easily find examples in Ghostty.

Re: Why users cannot create Issues directly

#265

Post by Sohcahtoa82 »

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…

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 item (With the obvious audible "BEEP"), and then stand there confused about what to do next. The machine is telling them "Please place the item in the bag" and they'd tell me they don't know what to do. I'd say "What's the machine telling you?" "'Please place the item in the bag'" "Okay, then place the item in the bag" "Oh, okay"

It's like they don't understand words if a computer is saying them. But if they're coming from a human, they understand just fine, even if it's the exact same words.

"Incorrect password. You may have made a mistake entering it. Please try entering it again." "I don't know what that means, I'm going to call up tech support and just say I'm getting an error when I try to log in."

Re: Why users cannot create Issues directly

#266

Post by 1123581321 »

nine_k wrote: post #11
1123581321 wrote: post #9

I agree with the general philosophy about user submissions. Browsing closed discussions looks a lot like browsing closed issues. So I'm not sure that the policy is successfully turning bug reports into discussions. But it's at least keeping Issues free from noise for contributors. Github could do more to nudge users into approaching Discussions differently. https://github.com/ghostty-org/ghostty/discussions?discussio…

The point is the opposite, AFAICT. Any user complaint starts as a discussion. If an actionable bug report results from it, it goes to the tracker, which serves as list of problems to work on. A lot of discussions do not end this way, even though they may solve a user's issue anyway, e.g. by providing advice and reference. Definitely discussing things could also happen in the issue tracker, and some tag could be used…

It is smart; it’s just not a qualitative improvement in many of the submitted discussions which are de facto tier one issues, which I guessed to be GitHub’s fault in the Discussions UX. Not seeing what has you feeling opposite.

Re: Why users cannot create Issues directly

#267

Post by stonogo »

eqvinox wrote: post #260
stonogo wrote: post #244

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.

> 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

Re: Why users cannot create Issues directly

#268

Post by ziml77 »

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…

Point #2 is very true for me. I get concerned when I look at a project and see thousands of issues. For safety and to not waste my time, if I see that and the project is an unknown to me, I just have to believe that it indicates the project is not being maintained properly.

I definitely think splitting discussion and issues is a good idea for that reason alone.

Re: Why users cannot create Issues directly

#269

Post by NewJazz »

ziml77 wrote: post #268
mitchellh wrote: post #221

Earlier quoted context omitted.

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…

Point #2 is very true for me. I get concerned when I look at a project and see thousands of issues. For safety and to not waste my time, if I see that and the project is an unknown to me, I just have to believe that it indicates the project is not being maintained properly. I definitely think splitting discussion and issues is a good idea for that reason alone.

I usually try to scan the issues and look at a few, to get a vibe of what the makeup of that number is. It can be really attractive to try to just compare project metrics like that, though.

Re: Why users cannot create Issues directly

#270

Post by NewJazz »

efreak wrote: post #262
mitchellh wrote: post #221

Earlier quoted context omitted.

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…

I recommend posting (or lining to) this somewhere on GitHub, maybe in the pinned issue.

Or as a discussion lol
Post reply on HN