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

161–170 of 320 posts

Re: Why users cannot create Issues directly

#161

Post by lijok »

skywhopper wrote: post #128
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.

[flagged]

To be clear, I am not telling Mitchell how to run his project. I am providing info on how a change like this can be perceived from the other side. Do with the information what you will.

Re: Why users cannot create Issues directly

#162

Post by layer8 »

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.

How is opening a discussion more friction than opening an issue?

Re: Why users cannot create Issues directly

#163

Post by tarkin2 »

So how do the maintainers and contributers know when a Discussion details a bug ready to be worked on? Seems like, as with issues, they'll still be sorting though them and looking for the most active ones?

Edit: after reading the contributors doc, it seems that feature requests are discussions which should help. Unreproducible bugs, too; although I would wager that a lot of users believe they can reproduce bugs but in fact can't consistently, or believe their feature request is a bug.

It seems this approach is better but still requires someone to sort through the discussions before they're moved to the cleaner issues pile.

One big pile with filters, or a chaotic pile and a clean pile. That seems to be the end result of this, unless I'm missing something.

Re: Why users cannot create Issues directly

#164

Post by philipallstar »

asdfaoeu wrote: post #149
codeflo wrote: post #124

Earlier quoted context omitted.

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

This still puts the onus on the developers to categorise the issues which I'm guessing they don't want to do.

That's always the case. Who else should triage?

Re: Why users cannot create Issues directly

#165

Post by sesm »

mitchellh wrote: post #59
quantummagic wrote: post #8

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

Regarding point 4: why the user should be familiar with the codebase to investigate it? Shouldn't they create a memory dump and send it to dev team?

Re: Why users cannot create Issues directly

#166

Post by christophilus »

throwaway81523 wrote: post #104
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.

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.

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.

Re: Why users cannot create Issues directly

#167

Post by arccy »

botanical76 wrote: post #158
arccy wrote: post #144

Earlier quoted context omitted.

behold the best way to search github issues. Using Google or whatever decent search engine: site:https://github.com/org/repo key words

Does this actually work? I would think it will be out of date by at least weeks, and I'd be surprised if their crawlers actually iterate through every issue page.

At least for the fairly popular repos I work on, it's only a few hours out of date, at most 1 day.

So if I'm triaging a new issue, often it'll show up in the results as well

Re: Why users cannot create Issues directly

#168

Post by emil-lp »

WhyNotHugo wrote: post #132

Personally, I find the distinction between “issues” and “discussions” annoying. For one, it duplicates the efforts in checking for prior reports. I might try 5–6 sets of keywords, but now I have to do so for 2 separate trackers. Tickets cannot be moved between trackers, so instead folks resort to duplicating it and moving discussions… which is entirely opaque if you’re following up via email: you won’t get any more n…

> I find the distinction between “issues” and “discussions” annoying

The benefit is that all users who just ask for help, assistance, or are unable to install or use the software now have a place to ask.

You shouldn't create an issue just because you get an error when installing, but it might be beneficial to still ask for help.

If it is indeed a bug, then create a ticket, linking to the discussion.

Normally, too many issues are user errors.

Re: Why users cannot create Issues directly

#169

Post by ginko »

mitchellh wrote: post #65
eviks wrote: post #10

> This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on. How is this not trivially solved via a "ready-to-be-worked-on" tag?

Because I don't want my default view to be "triage." If GitHub allowed default issue views (and reflected that in the issue count in the tabs as well), then maybe. But currently, it doesn't work. I've tried it at large project scale across many (multiple projects with more than 20K stars and millions of downloads). Compared to that, this system has been a huge success. It has its own problems, but it's directionally…

Can't you just set a bookmark with the filters you want?

Re: Why users cannot create Issues directly

#170

Post by rorytbyrne »

mitchellh wrote: post #59
quantummagic wrote: post #8

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 spotted Ghostty using 20GB+ memory a few days ago on MacOS (according to Activity Monitor). I went through all my tmux sessions, killed everything, it was still 20GB+ so I re-started Ghostty. If I see it happen again, I'll take some notes.
Post reply on HN