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

251–260 of 320 posts

Re: Why users cannot create Issues directly

#251

Post by zzzeek »

jamietanna wrote: post #220
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!

We (Renovate) have an issue template (for maintainers/Triage-rights only) which has a label on it Then GitHub Actions runs on new Issues and any that have that label get auto-closed The idea is that folks with Triage+ can remove that label when creating an Issue, but not external contributors - might be worth giving that a go?

my fear is people are going to post issue reports, sometimes good ones that we need to act upon, they get autoclosed, and the submitter either never bothers to re-post or they are so annoyed that they don't re-post.

it would be way better if there was only one way for them to get their content in, in the first place

Re: Why users cannot create Issues directly

#252

Post by franciscop »

IshKebab wrote: post #240
franciscop wrote: post #116

Earlier quoted context omitted.

As an OSS maintainer myself, while the amount of tickets about a specific topic _might_ be loosely related to the quality of the docs/installation/etc, this hasn't been true in my observations. It's one of those explanations that sound very plausible on paper, but if you see real world issues it just doesn't happen, users will ask questions that are clearly explained in the first paragraph of the readme, en masse.

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

Re: Why users cannot create Issues directly

#253

Post by vladvasiliu »

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…

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.

Re: Why users cannot create Issues directly

#254

Post by cinntaile »

sowbug wrote: post #241
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…

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.

Re: Why users cannot create Issues directly

#255

Post by ericrallen »

codeflo wrote: post #124
throwaway81523 wrote: post #104

Earlier quoted context omitted.

The trouble here is that github issues is crap. 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. Github issues is mostly a discussion system that was so inadequate that they supplemented it with another discussion system.

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

Just trying to triage and tag all of them can still be a full-time job’s worth of work in a popular repo.

Re: Why users cannot create Issues directly

#256

Post by snupples »

vladvasiliu wrote: post #253
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…

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…

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 to it. So Azure is indirectly training people that 403 potentially IS a "network issue"... (like their laptop is not connected to VPN, or Private DNS isn't set up right, or traffic isn't being routed correctly or some such).

Yeah, I get that's just plain silly, but it's IAAS/SAAS magic cloud abstraction and that's just the way Microsoft does things.

Re: Why users cannot create Issues directly

#257

Post by jamietanna »

zzzeek wrote: post #251
jamietanna wrote: post #220

Earlier quoted context omitted.

We (Renovate) have an issue template (for maintainers/Triage-rights only) which has a label on it Then GitHub Actions runs on new Issues and any that have that label get auto-closed The idea is that folks with Triage+ can remove that label when creating an Issue, but not external contributors - might be worth giving that a go?

my fear is people are going to post issue reports, sometimes good ones that we need to act upon, they get autoclosed, and the submitter either never bothers to re-post or they are so annoyed that they don't re-post. it would be way better if there was only one way for them to get their content in, in the first place

In our case, we've fortunately not found that's happened - we do end up looking at Issues that are closed in this way, and the majority of cases it's someone who's raised a Discussion and want to bypass the triage so create a new Issue from their comment

(I'm thinking of getting some data and words together to look at how this has helped us over the last ~18 months)

Re: Why users cannot create Issues directly

#258

Post by padjo »

I’m far from an AI booster but this sounds like a perfect job for an AI classifier to act as a gate keeper. If you can convince the AI that your bug report is sufficiently detailed to be actionable and issue gets created. Should reduce the low quality reports, crazy people and issue spam.

Re: Why users cannot create Issues directly

#259

Post by foxygen »

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.

Arrogance? Those people are spending their time and effort on an open source project, without asking a penny in return. I think they are entitled to have restrictions on how bugs should be reported.

Re: Why users cannot create Issues directly

#260

Post by eqvinox »

stonogo wrote: post #244
eqvinox wrote: post #206

Earlier quoted context omitted.

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.

> 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 a huge problem.

P.S.: I hate to break it to you, but "I hate to break it to you, but" is quite poor form.

Post reply on HN