I didn’t know GitHub had discussions. This is great
Why users cannot create Issues directly
81–90 of 320 posts
Re: Why users cannot create Issues directly
#82Earlier quoted context omitted.
An non-issue raised as an issue can never be closed, because the person who reported it will just open another one saying "Why did you close my issue without fixing it?" If that user is also raising valid, useful issues then you don't want to just ban them. Consequently your issues list will become unmanageable.
Reporting valid issues does not grant you the right to abuse the issue tracker.
I'm not saying it does. I'm saying that banning a user who is making a mistake in one area means you lose the value they provide in another (which might be valid issues, but equally it might be 90% of your revenue or something), so it's not always an obvious decision to just wield the ban hammer every time. Moving discussion of issues before they're created to a separate place helps keep the issue tracker focused on issues that are likely to be addressed.
An additional benefit of that is that a user whose discussion leads to a real issue being created will feel like they're genuinely being listened to. That creates a good customer experience, which is good for your brand's reputation. It's a positive experience. Closing non-issues in the tracker is a negative experience.
Re: Why users cannot create Issues directly
#83For example, memory leak investigation is currently spread across discussions, x/twitter and discord https://x.com/mitchellh/status/2004938171038277708 https://x.com/alxfazio/status/2004841392645050601 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/9962 but has not graduated to issue worthy status
For those who have the issue.
I reported the issue in discussions some time ago, but had no reaction/response.
I was able to reproduce the leak consistently. Finally I've got all the reports done by me, Ghostty sources and Claude Code and tried to fix it.
For the first couple of weeks there were no leaks at all, now it started again but only 1/10 of the times it was before.
https://github.com/ghostty-org/ghostty/discussions/9786 There are some logs and a Claude Code review md file that might be useful.
Hope it will help someone investigate further.
Re: Why users cannot create Issues directly
#84Earlier 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.…
Valgrind won’t show you leaks where you (or a GC) still holds a reference. This could mean you’re holding on to large chunks of memory that are still referenced in a closure or something. I don’t know what language or anything about your project, but if you’re using a GC language, make sure you disable GC when running with valgrind (a common mistake). You’ll see a ton of false positives that the GC would normally cle…
Ghostty is written in Zig.
Re: Why users cannot create Issues directly
#85Earlier 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.
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 the rest of my tabs are transient and don't really grow. I even mostly use private browsing for research, and only bookmark (or otherwise save) pages I deem to be of high quality. I might have a private window with multiple tabs for a given task, but it is quickly reduced to the minimum necessary pages and the the whole private window is thrown away once the initial source material gathering is done. This lets me turn off address bar search engines and instead search only saved history and bookmarks.
I often see colleagues with the same many browser windows of many tabs each open struggling to find what they need, and ponder their methods.
Re: Why users cannot create Issues directly
#86I've seen other projects that do this, and it makes a lot of sense. A discussion forum is a good place to start. It seems though that many projects don't have the Github "discussions" activated.
Re: Why users cannot create Issues directly
#87100% 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 forward. If I can make a video with Sora by typing what I want in the box, why would I need to click around or type some arcane configuration for a tool?
I don't think in general it is bad - it is only bad for specialist software where you cannot use that software without deeper understanding, but the expectation is still there.
Re: Why users cannot create Issues directly
#88Earlier quoted context omitted.
There's all the usual "$APPLICATION is a memory hog" complaints, for one. In the SWE world, dev servers are a luxury that you don't get in most companies, and most people use their laptops as workstations. Depending on your workflow, you might well have a bunch of VMs/containers running. Even outside of SWE world, people have plenty of use for more than 8GiB of RAM. Large Photoshop documents with loads of layers, a D…
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.
Re: Why users cannot create Issues directly
#89A 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 know "what is clearly a bug" 100% of the time in projects you don't own
Owning a project is counter-productive for QA. If it’s your project, you know where to click and where to not click.
OTOH, you don’t need to know anything about a project to conclude that a crash with access violation, or hang with 100% CPU usage, are clearly bugs.
Re: Why users cannot create Issues directly
#90Earlier 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.
btw, is it me or is there any justification for anyone including a developer to run more than 8GB of RAM for a laptop? I don't see functionality as having changed in the last 15 years. For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.
With 32 GB I can run two whole Electron applications! Discord and Slack!
It's a life of luxury, I tell you.