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

101–110 of 320 posts

Re: Why users cannot create Issues directly

#101

Post by happymellon »

sumanthvepa wrote: post #88
gizmo686 wrote: post #35

Earlier quoted context omitted.

This depends on industry. Around here, working locally on laptop is a luxury, and most devs are required to treat their laptop like a thin client. Of course, being developer laptops, they all come with 16 gigs of RAM. In contrast, the remote VMs where we do all of the actual work are limited to 4GiB unless we get manager and IT approval for more.

Interesting. I required all my devs to use local VMs for development. We've saved a fair bit on cloud costs.

Current job used to let us run containers locally, but they decided to wrap initially docker, and then podman with "helper" scripts. These broke regularly, and became too much overhead to maintain so we are mandated to do local dev but access a dev k8 cluster to perform any level of testing that is more than unit and requires a db.

A really shame as running local docker/podman for postges was fine when you just ran the commands.

Re: Why users cannot create Issues directly

#102

Post by burnt-resistor »

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.

Your feedback is very important to us. Please fill out this long ass form and provide mountains of telemetry as barriers to participation.

Re: Why users cannot create Issues directly

#103

Post by magicalhippo »

bananadonkey wrote: post #85
magicalhippo wrote: post #75

Earlier quoted context omitted.

The issue for me is that bookmarks suck. They don't store the state (where I was reading) and they reload the webpage so I might get something else entirely when I come back. They also kinda just disappear from sight. If instead bookmarks worked like tab saving does, I would be happy to get rid of a few hundred tabs. Have them save the page and state like the tab saving mechanism does. Have some way to remind me of t…

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.

Re: Why users cannot create Issues directly

#104

Post by throwaway81523 »

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.

Re: Why users cannot create Issues directly

#105

Post by burnt-resistor »

Sure, issues for tasks and discussions for conversations.

And then there are developers who idly complain about normal participation on the work of issues and coordination of testing and feedback because it sends them a notification that they turned on. Unconstructive bitching drives users and collaborators away. They could solve their notification problem rather than impose a burden and emotional bullshit on everyone else.

Re: Why users cannot create Issues directly

#106

Post by stinkbeetle »

cik wrote: post #67
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.

You're 100% correct. I had a CVE reported to me in ~2022, shortly after the ChatGPT launch. I spent 4 hours slicing and dicing the issue, responding to how it was wrong, linking to background information, specific lines in the code, and then asking for or what am I missing . The response was literally "shrugs AI". Good for them.

Yeah but the article / post linked does not say that they won't look at reports of bugs or security problems, just that they are using issues to manage things they have decided are issues that should be worked on, and so public reporting using issues tickets will mess up that system they have. It's purely about their project's use of the issues system in github.

Unfortunately there is no such magic bullet for trawling through bug reports from users, but pushing more work out to the reporter can be reasonably effective at avoiding that kind of time wasting. Require that the reporters communicate responsively, that they test things promptly, that they provide reproducers and exact recipes for reproduction. Ask that they run git bisect / creduce / debug options / etc. Proactively close out bugs or mark them appropriately if reporters don't do the work.

Re: Why users cannot create Issues directly

#107

Post by marksomnian »

ohyoutravel wrote: post #100
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.…

I’ve been a very happy user for 2025, with some edge cases around the terminal not working on remote shells. I haven’t seen any memory leaks, but wanted to say I appreciate this detailed response.

In my experience, the remote shell weirdness is usually because the remote shell doesn’t recognise ghostty’s TERM=xterm-ghostty value. Fixed by either copying over a terminfo with it in, or setting TERM=xterm-256color before ssh’ing: https://ghostty.org/docs/help/terminfo

Re: Why users cannot create Issues directly

#108

Post by Hendrikto »

ozim wrote: post #87
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.

I believe most of it is people expecting stuff to work differently, not having time to wrap their head around proper usage of system, because they need specific outcome and they don't need mastery of the tool. Downside is that "Facebookization" created a trend where people expect everything to be obvious and achievable in minimal amount of clicks, without configuring anything. Now "LLMization" will push the trend for…

> If I can make a video with Sora by typing what I want in the box

IME, people cannot even articulate what they want when the know what they want, let alone when they don’t even understand what they want in the first place.

Re: Why users cannot create Issues directly

#109

Post by OmarShehata »

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

Re: Why users cannot create Issues directly

#110

Post by abenga »

transcriptase wrote: post #31
typeofhuman wrote: post #27

Earlier quoted context omitted.

I wonder if having less RAM would compel you to read, commit to long term memory, and then close those 80 tabs you have open.

I wonder if a good public flogging would compel chrome and web devs to have 80 tabs take up far less than a gigabyte of memory like they should in a world where optimization wasn’t wholesale abandoned under the assumption that hardware improvements would compensate for their laziness and incompetence.

Is there a straightforward way to have one-process-per tab in browsers without using significant amounts (O(n_tabs)) of memory?
Post reply on HN