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

281–290 of 320 posts

Re: Why users cannot create Issues directly

#281

Post by Conan_Kudo »

eqvinox wrote: post #205
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?

> As far as I'm aware, most large open GitHub projects use tags for that kind of classification. Would you consider that too clunky? Speaking for another large open GitHub project: Absofuckinglutely yes. I cannot overstate how bad this workflow is. There seems to be a development now in other platforms becoming more popular (gitlab, forgejo/codeberg, etc.) and I hope to god that it either forces GitHub to improve thi…

None of the alternative forges have a better issue tracker implementation. For the most part, they are basically copies of GitHub. No hope there. :(

Re: Why users cannot create Issues directly

#282

Post by rarkins »

bsnnkv wrote: post #63

I'm a fan of this. My own projects on GitHub have an action[1] which autocloses and autolocks any opened issues until they have been reviewed and accepted by me, and I only consider feature requests from sponsors. The real miss here is that there isn't a way on GitHub to only allow maintainers to create issues, instead we are left with these subpar workarounds. [1]: https://github.com/LGUG2Z/komorebi/blob/master/.git…

1. Set a default label for issues (e.g. “autoclose”) 2. Make your auto closing and locking logic based on that label (eg the label-actions github action) 3. As a maintainer, remember to remove the label when creating an issue!

Re: Why users cannot create Issues directly

#283

Post by pastage »

ericrallen wrote: post #255
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?

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

Having spent only a week triaging Mozilla bug reports I do not see how a different ticketing system makes it easier. It is just hard work.

Re: Why users cannot create Issues directly

#284

Post by bananadonkey »

magicalhippo wrote: post #103
bananadonkey wrote: post #85

Earlier quoted context omitted.

Regarding wanting to preserve the current version of a page: I use Karakeep to archive those pages. I am sure there are other similar solutions such as downloading an offline version, but this works well for me. I do this mostly for blog posts etc I might not get around to reading for weeks or months from now, and don't want them to disappear in the meantime. Everything else is either a pinned tab ( While browsing th…

I've started using Karakeep as well, however I don't find its built-in viewer as seamless as a plain browser page. It's also runs afoul of pages which combats bots due to its headless chrome. Anyway, just strikes me as odd that the browsers have the functionality right there, it's just not used to its full potential.

Websites that are walled off behind obscure captcha don't do well in Karakeep for sure, but so far for me those are usually e-commerce sites or sites I don't return to anyway.

Re: Why users cannot create Issues directly

#285

Post by ykonstant »

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…

>2. The psychological impact of the "open issue count" has real consequences despite being meaningless on its own. People will see a project with 1K+ issues and think "oh this is a buggy hell hole" when 950 of those issues are untriaged, unaccepted, 3rd party issues, etc.

Fully agree with this; as a beginner in the space I get nervous when I see a project having a thousand open issues since 2018.

Re: Why users cannot create Issues directly

#286

Post by locknitpicker »

snupples wrote: post #256
vladvasiliu wrote: post #253

Earlier quoted context omitted.

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…

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

You are not describing a network issue. You're sending requests that by design the origin servers refuse to authorize. This is basic HTTP.

https://datatracker.ietf.org/doc/html/rfc7231#page-59

The origin servers could also return 404 in this usecase, but 403 is more informative and easier to troubleshoot, because it means "yeah your request to this resource could be good but it's failing some precondition".

Re: Why users cannot create Issues directly

#287

Post by icepush »

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…

Joel Spolsky solved this over 25 years ago https://www.joelonsoftware.com/2000/04/26/designing-for-peop...

Re: Why users cannot create Issues directly

#288

Post by latexr »

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…

> Instead, it's "When I do X, I get an error".

Worse still, just “it doesn’t work” without even any steps.

I sometimes gave those users an analogy like going to the doctor or a mechanic and not providing enough information, but I don’t think it worked.

Re: Why users cannot create Issues directly

#289

Post by latexr »

mamcx wrote: post #278
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…

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.

You can test that theory with Magic the Gathering players. Reading exactly what the card says and interpreting it with the exact text of the rules is core to the game.

Re: Why users cannot create Issues directly

#290

Post by ahartmetz »

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

You might want to ask your user who can reproduce it to try heaptrack. It tracks allocations, whether they leak or not. If that doesn't find anything, check the few other ways that a program can require memory, such as mmap() calls and whatever else the platform documentation tells you.

Memory usage is not really difficult to debug usually, tbh.

Post reply on HN