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

191–200 of 320 posts

Re: Why users cannot create Issues directly

#191

Post by whythough1234 »

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.

Agreed. We have to stop this “first-class” citizen for anything but general communication platforms. This allows creating a barrier between specialists and common users.

Re: Why users cannot create Issues directly

#192

Post by alexpotato »

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.

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.

Re: Why users cannot create Issues directly

#194

Post by goku12 »

OmarShehata wrote: post #109
goku12 wrote: post #98

This is the natural way to do it. I have had to use the issue tracker for asking questions (support requests) or informing the developer of something (like of implementing a related feature in another software). Clearly, those aren't issues at all, and the normal workflow steps like closing the ticket doesn't make much sense at all. They belong to the discussions list. Issue trackers should be used exclusively for ea…

I think this is the natural process , but how you implement it doesn't matter. A lot of GitHub repos use "unlabelled issue" === "a discussion thread". The benefit is that instead of having to search two separate systems, you can just search one (if you can have an aggregate search over both then it really doesn't matter), these two implementations are isomorphic

I don't find them equivalent or isomorphic. You are rolling a generic discussion forum and a work planner/tracker into one. In my experience, such two-in-one solutions rarely work well. Discussions and Issues tend to interfere with each others' UX significantly when there is no explicit boundary. And it looks like Mitchell Hashimoto and a lot of others feel the same way.

Re: Why users cannot create Issues directly

#195

Post by Jolter »

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.

Google checks my site’s site map at least every day. I rarely see anything out of date in their index.

Re: Why users cannot create Issues directly

#196

Post by 12345hn6789 »

sesm wrote: post #165
mitchellh wrote: post #59

Earlier quoted context omitted.

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?

The point is to reduce reported issues from non maintainers as close to 0 as possible. This does that.

Re: Why users cannot create Issues directly

#198

Post by djoldman »

Intuitively, it seems like the Correct™ feature to handle the concepts of "issues" and "discussions" would be to have only one place to go to comment on a project.

There doesn't seem to be enough of a separation between the concepts of "issues" and "discussions" to support separating them into two features.

Given that discussions seem more general, it seems like the right path forward would be to have only discussions. Sub-features of issues could be added to discussions.

Re: Why users cannot create Issues directly

#199

Post by zzzeek »

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!

Re: Why users cannot create Issues directly

#200

Post by darkwater »

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?

> Would you consider that too clunky?

Absolutely. It's a patch that can achieve a similar result, but it's a patch indeed. A major features of every ticketing system, if not "the" major feature, is the ticket flow. Which should be opinionated. Customizable with the owner's opinion, but opinionated nonetheless. Using labels to cover missing areas in that flow is a clunky patch, in my book.

Post reply on HN