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.
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 seeking help regarding the error. Instead, it's "When I do X, I get an error".
Maybe I have too much faith in people. I've seen even software engineers become absolutely blind when dealing with errors. I had a time 10 years ago as a tester when I filed a bug ticket with explicit steps that results in a "broken pipe error". The engineer closed the ticket as "Can Not Reproduce" with a comment saying "I can't complete your steps because I'm getting a 'broken pipe error'".
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 of "network problem" between their workstation and some web server, because they were getting an http 403 error.
So, yeah. Regular users? I honestly have 0 expectations from them. They just observe that the software doesn't do what they expect and they'll complain.
When debugging stuff with the devs at our work, I tend to overexplain as much as I can, because often there’s some deep link between systems that I don’t understand, but they do.
I’m a pretty firm believer in “no stupid questions (or comments)”, because often going in a strange direction that the devs assure me isn’t the problem, actually turns out to be the problem (maybe thing A actually has some connection to thing B in a very abstract way!).
I think just serving a different perspective or theory can help us all solve the problem faster, so sometimes it’s worth to pull that thread, even if it seems worthless in the moment.
Maybe I’m just lucky that my engineering colleagues are very patient with me (and maybe less lucky that some of our systems are so deeply intertwined), but I do hope they have more than zero expectations from me, as we mean well and just want to support where we can, knowing full well that ya’ll are leagues ahead in the smarts department.
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 to it. So Azure is indirectly training people that 403 potentially IS a "network issue"... (like their laptop is not connected to VPN, or Private DNS isn't set up right, or traffic isn't being routed correctly or some such).
Yeah, I get that's just plain silly, but it's IAAS/SAAS magic cloud abstraction and that's just the way Microsoft does things.
> 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.
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".
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.
> I do not expect users to understand what an error means
I'm not sure I agree.
Reason ?
The old adage "handle errors gracefully".
The "gracefully" part, by definition means taking into account the UX.
Ergo "gracefully" does not mean spitting out either (a) a meaningless generic message or (b) A bunch of incomprehensible tech-speak.
Your error should provide (a) a user-friendly plain-English description and (b) an error ID that you can then cross-reference (e.g. you know "error 42" means the database connection is foobar because the password is wrong)
During your support interaction you can then guide the user through uploading logs or whatever. Preferably through an "upload to support" button you've already carefully coded into your app.
Even if your app is targetting a techie audience, its the same ethos.
If there is a possibility a techie could solve the problem themselves (e.g. by RTFM or checking the config file), then the onus is on you to provide a suitably meaningful error message to help them on their troubleshooting journey.
There are people that when using a computer, if anything goes remotely wrong, they completely lose all notions of language comprehension. You can make messages as non-technical as possible and provide troubleshooting steps, and they just throw their hands up and say "I'm not a computer person! I don't know what it's telling me!"
20 years ago, I worked the self-checkout registers in retail. I'd have people scan an item (With the obvious audible "BEEP"), and then stand there confused about what to do next. The machine is telling them "Please place the item in the bag" and they'd tell me they don't know what to do. I'd say "What's the machine telling you?" "'Please place the item in the bag'" "Okay, then place the item in the bag" "Oh, okay"
It's like they don't understand words if a computer is saying them. But if they're coming from a human, they understand just fine, even if it's the exact same words.
"Incorrect password. You may have made a mistake entering it. Please try entering it again." "I don't know what that means, I'm going to call up tech support and just say I'm getting an error when I try to log in."
>completely lose all notions of language comprehension
I see this pretty often. These aren't even what should be called typical users in theory. They are people doing a technical job and were hired with technical requirements, an application will spit out a well written error message in the domain they should be professionals in and their brain turns off. And ya, it ends up in a call to me where I state the same thing and they figure the problem out.
I think part of it is that most users at some point encounter an error message that is just straight up wrong. For example, a login page that says "wrong password" when in reality the user is typing EXACTLY what they typed on account creation, but the site silently truncated the password. Even one such frustrating experience is enough to teach many users that as soon as they see any error message, they should stop trusting anything the system tells them, including the error message. It's extremely difficult to rebuild user trust after this sort of UX contract violation, particularly because less technical users don't mentally differentiate separate computer systems. All the systems are just "the computer."
Also arguably the users are kind of right. An error indicates that a program has violated its invariants, which may lead to undefined behavior. Any output from a program after entering the realm of undefined behavior SHOULD be mistrusted, including error messages.
I think it's something to do with the expectations of automation. We seem to be wired or trained to trust the machines fully, and enter a state of helplessness when we think we are driven by a machine.
I've seen this with gnss-assisted driving, or with automated driving, or with aircraft autopilot. Something disengages, gives unwarranted trust, we lose context, training fades ; and when thrown back in control, the avalanche of context and responsibility is overwhelming, compounded by the lack of context about the previous intermediate steps.
One of the most worrying dangers of automation, is this trust (even by supposed knowledgeable technicians) and the transition out of the 'the machine is perfect' and when it hands you back the helm on a failure, an inability to trust the machine again.
The way to avoid entering this state, seems to stay deeply engaged in the inputs and decisions of the system (read 'automation should be like iron man, not like ultron') and have a deep understanding of the moving parts, critical design decisions of the system, and traces/visualization/checklist of the intermediate steps.
I don't know where the corpus of research about this is (probably in safety engineering research tomes), but it crystallized for me when comparing the crew reactions and behaviour of the Rio-Paris Air France crash, and the Quantas A380 accident in Singapour.
For the first one, amongst many, many other errors (be it crew management, taking account of the weather...) and problematic sensor behaviour, the transcript tells a harrowing story of a crew not trusting their aircraft anymore after recovering from a sensor failure (that failure ejecting them from autopilot and giving them back mostly full control), ignoring their training, and many of the actual alarms the aircraft was rightly giving, blaring at them.
In the second case, a crew that tries to piece out what capabilities they still have after a massive engine failure (explosion), wrecking most of the other systems with shrapnel. And keeping enough in the loop to decide when the overwhelmed system is giving wrong sensor instructions (transfering fuel from the unaffected reservoirs to actually destroyed, leaky ones).
This is not about understanding the message, but switching user mental activity.
I go myself in the similar situations many times. One example: I tried to pay my bills in online bank application, but got into error. After several attempts, I did read message and it say "Header size exceed..." . It give me clue that app probably put too much history into cookies. Clear browser data, log in again, and all got works.
Even when error message was clearly understandable for my expertise, it took surprisingly long tome to switch from one mental activity - "Pay bills", to another - "Investigate technical problem". And you have to throw away all short memory to switch into another task. So all rumors about "stupid" users is direct consequence from how human mind works.
> This is not about understanding the message, ...
99% of the population have no idea what "Header size exceeded" means, so it absolutely is about understanding the message, if the devs expect people to read the error.
Yeah, I would certainly not expect the user to understand what to do about a "Header size exceeded" error.
But I WOULD expect the user, when sending a message to support, to say they're getting a "Header size exceeded" error, rather than just say "an error".
This seems to be missing the point. Sometimes users see error messages. Sometimes they're good, sometimes they're bad; and yeah, software engineers should endeavor to make sure that error behaviors are graceful, but of all the not-perfect things in this world, error handling is one of the least perfect, so users do encounter unfortunately ungraceful errors.
In that case (and even sometimes in the more "graceful" cases), we don't always expect the user to know what an error message means.
If I can victim-blame for a moment, I don't know what my mom is supposed to do when a streaming service on her TV says there's a problem and will she please report a GUID to the support department.
No, my mom is not eidetic, and no, she's not going to upload a photo of her living room.
Totally agree with you, though, when the full error message is at least capable of being copied to the clipboard.
I hope you’re being sarcastic. If not, expecting someone’s parent to know how to use a photo app’s crop functionality just to communicate an error state is a failure of understanding typical streaming app users.
I wasn't being sarcastic.
This is not a case of not being capable of doing something, it's about not knowing the functionality exists. Cropping is very simple.
I assumed the GP didn't know about it either or he would have taught his mom already.
Could the manufacturer solve this in a better way? Probably but that won't solve the issue the customer has now.
Poe's Law goes both ways. As a matter of fact, my mom invented digital photo cropping (or "pixel array extent adjustment," because even in her prime she wasn't a marketing genius, bless her heart). We know better than to expect her to submit a bug report once she's settled down to watch TV for the evening.
Jokes aside, "upload a photo of her living room" was meant to highlight the ridiculousness of the UX. I believe the designer of that flow had an OKR to decrease the number of reported bugs.
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?
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.
IMO it still has poor discoverability, constant filtering between the triage status flags and non-flagged stuff, stuff that might not have been flagged by accident, reporters putting tags on issues themselves, issues can only be closed by non-admins rather than truly deleted, random people complaining about this or that on unrelated tickets...
It all stems from the fact that all issues are in this one large pool rather than there being a completely separate list with already vetted stuff that nobody else can write into.
Sounds like it could be fixed by making it configurable to hide all issues without a certain tag (or auto-apply a hiding tag) for the issues "landing page".
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead.
Translation: sure, you can make this work by piling automation on top. But that doesn't make it a good system to begin with, and won't really result in a robust result either. I'd really rather have a better foundation to start with.
> I hate to break it to you, but all the other ticket systems do this by piling automation on top as well.
The rebuke to your comment is right in your comment: "other ticket systems do this by…"
The ticket system does it. As in, it has it built-in and/or well integrated. If GitHub had the same level of integration that other ticket systems achieve with their automation, this'd be a non-issue. But it doesn't, and it's a huge problem.
P.S.: I hate to break it to you, but "I hate to break it to you, but" is quite poor form.
No, it's not that well integrated. They don't call it 'tags' but they work exactly the same way. JIRA, the most commonly cited example in this thread, has a whole separate engine for it and your JIRA admin builds the ticket flow manually. All the way back in RT this sort of thing was handled by a cron job. Github leveraging actions to accomplish this isn't much of a difference.
They're already doing that by moving discussions to issues. In fact it's more work for them because they have to actually create the issue instead of just adding a "confirmed bug" label or whatever.
I guess it probably leads to higher quality issue descriptions at least, but otherwise this seems pretty dumb and user-hostile.
There’s a one-click button to convert from discussion to issue (and vice versa). It’s hardly more work. But I do feel like discussions are kind of hidden and out of the way on GitHub.
On repos I maintain, I use an “untriaged” label for issues and I convert questions to discussions at issue triage time.
> 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 this pile of expletive or makes these "alternate" platforms not be so alternate anymore so we can move off.
The classification here is not what type of issue it is, it's whether it's an issue or not. Creating an issue for things that aren't issues is fundamentally broken. There's no way to fix that except by piling bad design on bad design to make it so that you can represent non-issues using issues and have everything still be somewhat usable.
> 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.
All of this is possible on GitHub issues and is in fact done by many projects, by this metric I dont see how GitHub Issues is any different than say, JIRA. In both cases, as you mentioned, someone needs to triage those issues, which would, of course, be the developers as well. Nothing gained, nothing lost.
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.
Discussion systems all the way down :-). This is a fair assessment of the github issues system. I suspect that because git(1) can be a change control system for anything there is never any hope of making an effective issue tracker for a particular thing it is being used to manage change on. The choice the project made to allow the developers to determine when something was an issue is essentially adding a semantic layer on top of issues that customizes it for this particular corpus of change management.
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.
Don't forget the rude, entitled, and aggressive, they are legion.
It's simply a great idea. The mindset should be 'understand what's happening', not 'this is the software's fault'.
The discussion area also serves as a convenient explanation/exploration of the surrounding issues that is easy to find. It reduces the maintainer's workload and should be the default.
Yeah but a good issue tracker should be able to help you filter that stuff out. That ghostty finds discussions to be a better way to triage user requests/issues is somewhat quirky, although a perfectly valid option. As is just using issues, imo. Just good to make sure users know how to report an issue, and what information to include.
To be clear, I think discussions on the whole as a product are pretty bad. I'm not happy having to use them, but given my experience trying different approaches across multiple "popular" projects on GH, this approach has so far been the least bad. Although I'm still sad about it.
> Yeah but a good issue tracker should be able to help you filter that stuff out.
Agreed. This highlights GitHub's issue management system being inadequate.
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.
It is weird to push the idea that Facebook is some kind of pinacle of good and easy to use UI. That's the first one. It's quite the opposite, with people constantly complaining how bad, clunky and confusing Facebook is. And it is not the recent trend either. It has always been this way and e.g. VK has always had a better UI/UX that Facebook (and Telegram's is better that Whatsapp's).
But still, compared to something like email, the previous standard for most people, Facebook was an unbelievable step forward. People complain about anything.
Facebook is a step forward in terms of features. But it is a clear regression in terms of UI, easiness, usability, understandability of email. Email is very simple in both concept and practice.
I think I disagree - when it comes to sharing large files, something like a video, or even a picture in 2005, email was nowhere near as good. And also having a place to comment on things without the stacking up of reply chrome is genuinely better.
> when it comes to sharing large files, something like a video, or even a picture in 2005, email was nowhere near as good.
That's just a stupid limitation and not even a technical one. You could happily send GBs over email. You can also easily filter allowed attachment size by sender on the recipient side, because by the time the attachment size is told, both information was already provided.
> 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.
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.
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. The report at hand seems to affect a very limited number of users (given the lack of reports and information about them). There are lots of X meme posts about Ghostty in the macOS "Force Close" window using a massive amount of RAM but that isn't directly useful because that window also reports all the RAM _child processes_ are using (e.g. if you run a command in your shell that consumes 100 GB of RAM, macOS reports it as Ghostty using 100 GB of RAM). And the window by itself also doesn't tell us what you were doing in Ghostty. It farms good engagement, though.
2. We've run Ghostty on Linux under Valgrind in a variety of configurations (the full GUI), we run all of Ghostty's unit tests under Valgrind in CI for every commit, and we've run Ghostty on macOS with the Xcode Instruments leak checker in a variety of configurations and we haven't yet been able to find any leaks. Both of these run fully clean. So, the "easy" tools can't find it.
3. Following point 1 and 2, no maintainer familiar with the codebase has ever seen leaky behavior. Some of us run a build of Ghostty, working full time in a terminal, for weeks, and memory is stable.
4. Our Discord has ~30K users, and within it, we only have one active user who periodically gets a large memory issue. They haven't been able to narrow this down to any specific reproduction and they aren't familiar enough with the codebase to debug it themselves, unfortunately. They're trying!
To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users. That's why the discussion is open and we're soliciting input. I even spent about an hour today on the latest feedback (posted earlier today) trying to use that information to narrow it down. No dice, yet.
If anyone has more info, we'd love to find this. :)
This illustrates the difficulty of maintaining a separation between bugs and discussions:
> To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users
In this case it seems you believe a bug exists, but it isn't sufficiently well-understood and actionable to graduate to the bug tracker.
But the threshold of well-understood and actionable is fuzzy and subjective. Most bugs, in my experience, start with some amount of investigative work, and are actionable in the sense that some concrete steps would further the investigation, but full understanding is not achieved until very late in the game, around the time I am prototyping a fix.
Similarly the line between bug and feature request is often unclear. If the product breaks in specific configuration X, is it a bug, or a request to add support for configuration X?
I find it easier to have a single place for issue discussion at all stages of understanding or actionability, so that we don't have to worry about distinctions like this that feel a bit arbitrary.
Is the distinction arbitrary? It sounded like issues are used for clear, completable jobs for the maintainers. A mysterious bug is not that. The other work you describe is clearly happening, so I'm not seeing a problem with this approach other than its novelty for users. But to me it looks both clearer than the usual "issue soup" on a popular open source project and more effective at using maintainer time, so next time I open-source something I'd be inclined to try it.
Some people see "bug tracker" and think "a vetted report of a problem that needs fixing", others see "bug tracker" and think "a task/todo list of stuff ready for an engineer to work on"
Both are valid, and it makes sense to be clear about what the teams view is
Agreed. Honestly, I think of those as two very different needs that should have very different systems. To me a bug tracker is about collecting user reports of problems and finding commonalities. But most work should be driven by other information.
I think the confusion of bug tracking with work tracking comes out of the bad old days where we didn't write tests and we shipped large globs of changes all at once. In that world, people spent months putting bugs in, so it makes sense they'd need a database to track them all after the release. Bugs were the majority of the work.
But I think a team with good practices that ships early and often can spend a lot more time on adding value. In which case, jamming everything into a jumped-up bug tracker is the wrong approach.
I think these are valid concerns for a project maintainer to think through for managing a chosen solution but I don't think there is a single correct solution. The "correct", or likely least bad, solution depends on the specific project and tools available.
For bug reports, always using issues for everything also requires you to evaluate how long an issue should exist before it is closed out if it can't be reproduced(if trying to keep a clean issue list). That could lead to discussion fragmentation if now new reports start coming in that need to be reported, but not just anyone can manage issue states, so a new one is created.
From a practical standpoint, they have 40 pages of open discussion in the project and 6 pages of open issues, so I get where they're coming from. The GH issue tracker is less than stellar.
I have a one bit that might be useful that I learned from debugging/optimizing Emacs.
macOS' Instruments tool only checks for leaks when it can track allocations and it is limited to ~256 stack depth. For recursive calls or very deep stacks (Emacs) some allocations aren't tracked and only after setting malloc history flags [0] I started seeing some results (and leaks).
Another place I'm investigating (for Emacs) is that AppKit lifecycle doesn't actually align with Emacs lifecycle and so leaks are happening on the AppKit and that has ZERO to do with application. Seems that problem manifests mostly on a high end specs (multiple HiDPI displays with high variable refresh rate, powerful chip etc.)
Probably nothing you haven't investigated yet, but it is similar to the ghost (pun intended) I've been looking for.
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
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.
Complete speculation, but does tmux use the xterm alternative screen buffer? I can see a small bug in that causing huge memory leaks, but not showing up in testing.
On some level, that's impressive. Any idea of how long Ghostty was alive? Maybe this a new feature where Ghostty stores LLM model parameters in the terminal scrollback history? /s
Not which parts of this are sarcastic or not, but it was probably running for a few weeks. High variance on that estimate though. I was running 5+ Claude Code instances and a similar number of vim instances.
Is it possible for Ghostty to figure out how much memory its child processes (or tabs) are using? If so maybe it would help to surface this number on or near the tab itself, similar to how Chrome started doing this if you hover over a tab. It seems like many of these stem from people misinterpreting the memory number in Activity Monitor, and maybe having memory numbers on the tabs would help avoid that.
They don't have to be, but without a reproduction for maintainers, its up to the end users to provide enough information for us to track it down, and this user hasn't been able to yet.
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.
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 clean up for you, but some of those won’t be false positives.
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.
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 DAW with a bazillion plugins and samples, anything involving 4k video are all workloads that would struggle running on such a small RAM allowance.
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.
our company just went with the "server in the basement" approach, with every employee having a user account (no VM or docker separation, just normal file permissions). Sure, sounds like the 80s, but it works rearly well. Remote access with wireguard, uptime similar or better than cloud, sharing the same beefy CPUs works well and gives good utilization. Running jobs that need hundreds of GB of RAM isn't an issue as long as you respect other's needs too dont hog the RAM all day. And in amortized costs per employee its dirt cheap. I only wish we had more GPUs.
> Interesting. I required all my devs to use local VMs for development.
It doesn’t work when you’re developing on a large database, since it won’t fit. Database (and data warehouse) development has been held back from modern practices just for this reason.
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.
I find this quite surprising! What benefit does your org accrue by mandating that the db instance used for testing is centralised? Where I am, the tests simply assume that there’s a database available on a certain port. docker-compose.yml makes it easy to spin this up for those so inclined. At that stage it’s immaterial whether it’s running natively, or in docker, or forwarded from somewhere else. Our tests stump up all the data they need and tear down the db afterwards. In contrast, I imagine that a dev k8s cluster requires some management and would be a single point of failure.
I really don't understand why they do what they do.
Large corp gotta large corp?
My guess is that providing the ability to pull containers means you can run code that they haven't explicitly given permission for, and the laptop scanning tools can't hijack them?
Yes, zero latency typing in your local IDE on a laptop sounds like the dream.
In enterprise, we get shared servers with constant connection issues, performance problems, and full disks.
Alternatively we can use Windows VMs in Azure, with network attached storage where "git log" can take a full minute. And that's apparently the strategic solution.
Not to mention that in Azure 8 CPUs gets you four physical cores of a previous gen server CPU. To anyone working with 4 CPUs or 2 physical cores: good luck.
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 them after a week or month or so.
Combine that with a search function that can search in contents as well as the title, and I'm changing habbits ASAP.
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 (<5) or a bookmark (themselves shared when necessary on e.g a Slack canvas so the whole team has easy access, not just me).
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.
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.
If I'm doing work than involves three different libraries, I'm not reading and committing to memory the whole documentation for each of those libraries. I might well have a few tabs with some of those libraries' source files too. I can easily end up with tens of tabs open as a form of breadcrumb trail for an issue I'm tracking down.
Then there's all the basic stuff — email and calendar are tabs in my browser, not standalone applications. Ditto the the ticket I'm working on.
I think the real issue is that browsers need to some lightweight "sleep" mechanism that sits somewhere between a live tab and just keeping the source in cache.
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.
The high memory usage is due to the optimization. Responsiveness, robustness and performance was improved by making each tab independent processes. And that's good. Nobody needs 80 tabs, that's what bookmarks are for.
There is no justification for that IMHO. The program text only needs to be in memory once. However, each process probably has its own instance of the JS engine, together with the website's heap data and the JIT-compiled code objects. That adds up.
How much would it take up if there was less RAM available. A web browser with a bunch of tabs open but not active seems like the type of system that can increase RAM usage by caching, and decrease it by swapping (either logically at the application level, or letting the OS actually swap)
The computer has 18GB of total RAM so I would hope that it’s already trying to conserve memory.
It’s kind of humorous that everyone interpreted the comment as complaining about Chrome. For all I know, it’s justified in using that much memory, or it’s the crappy websites I’m required to use for work with absurdly large heaps.
I really just meant that at least for work I need more than 8GB of RAM.
Browsers can get quite bloated, especially if one is not in the habit of closing tabs or restarting it from time to time. IDEs, other development tools, and most Electron abominations are also not shy about guzzling memory.
It can also be remarkably picky about GPUs, even otherwise well-supported integrated GPUs, but any discussion of this is declared a GTK problem (or an nvidia problem, even on intel).
It's not clear to me why I'd want to use Ghostty over WezTern or Kitty, TBH. Ghostty is certainly trends on social media, but that's a negative signal for me.
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 notifications and your future replies are silently discarded.
As a maintainer, having two trackers per project never made sense to me, so I’ve disabled discussion everywhere.
This is mostly a criticism of how GitHub implemented this feature, not of the decision taken here.
I personally don’t like discussions either. I treat issues to be issues experienced by the user. It doesn’t mean that there’s an issue caused by bugs in the software. User creates an issue that turns out to be caused by user not following instructions? Just help the user and close the issue.
At the very least I think what matters here is the process. The same exact process could be implemented via, for example, issue labels. It would not be hard for maintainers to search for issues with label "bug", which only maintainers can assign. There are clear UX tradeoffs between the two approaches.
Why would checking be duplicated? One would need to check only the discussions in this case, since issues will be created from discussions once something is ready to be worked on (as I understood it)
That’s only for non-maintainer submissions. When a maintainer notices a bug or decides on a new feature, they can open an issue for that right away, without prior discussion.
I've been annoyed at this distinction myself when trying to troubleshoot problems with other Github-hosted software. I actually think the distinction Ghostty is making here where the Discussion section is open for anyone to bring up an issue with a project, and the Issues section is locked down to official maintainers and is only used for tracking well-scoped planned changes to the software (which might arise from a user-initiated discussion about a problem) makes a great deal of sense. I haven't seen any other Github-hosted project which organizes itself in exactly this way but I have zero problem with it as a user of Ghostty myself.
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.
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.
I always struggle to understand this level of entitlement. No one is forcing you to use any of these projects. The vast majority of the time, drive-by bug reports by users are a complete waste of time because they're either a user error or not described in sufficient detail to debug. In other words, mostly noise, and adding more noise isn't really helpful.
If you want to contribute, a much better way is to work on bugs that are already well defined. There is generally no shortage of known bugs in software, there is however a shortage of people fixing them.
There's zero entitlement expressed by the parent, he's just trying to help the project, but is encountering unnecessary friction.
It's not that he has some inner urge to contribute in some way, he just encountered a bug while using the software and wants to report it. The alternative isn't coding — it's no contribution at all.
I think this is exactly the point most people miss. No contribution is better than bad contribution. Most issues people file are bad. I previously worked at a major OSS company and the vast majority of bug reports are just noise. It takes time to sift through them and they add no value, just waste time. If people did less of that, that would be a good outcome, not a bad one. Sure, there's useful reports there sometimes, but it's more rare than you'd think. On top of that, many of those are dupes of issues we've already found and filed, just haven't had time to fix yet.
Maintainers did a bunch of useful work for them and they refuse to report issues the way maintainers find the most useful, because it's a burden to help maintainers do all their free work.
This is like being forced to pay 50 bucks to your apartment because someone else broke the door. Then when you complain about it people tell you you’re entitled!
But it’s not your apartment (project/repo), it’s someone else’s. If it were yours, the rules wouldn’t apply.
You can clone the other person’s apartment for free and do whatever you like, though. Just don’t barge in to someone else’s apartment and demand they treat you, a stranger, like if it were yours.
Arrogance? Those people are spending their time and effort on an open source project, without asking a penny in return. I think they are entitled to have restrictions on how bugs should be reported.
Fwiw, you might have misinterpreted the idiomatic expression "all the time" as meaning "100% of the time". It just means "often" or "commonly". The parent is just saying they often find bugs, they know they're bugs through experience.
Of course anyone can make a mistake. Maybe you prefer the 'discussions' route because it's only seemingly then possible for a projects own devs to make a mistake in creating an issue.
The arrogance in in users like yourself who think they know better than the project owners how to run their issue tracker. This is just a variation. It’s not a barrier, it’s an attempt to improve the quality of the issues that are filed in a way that’s more useful for everyone.
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.
In the python projects in question, unlike with the Ghostty project, there isn't an "issue triage" discussion category that maintainers look at. They have just discussions, and everything is treated as such. So when you raise an issue in discussions, it either goes to the void or people come in looking for a discussion of alternative approaches to do what you're trying to do that don't hit the bug, rather than treating the bug as a bug.
At a high level - the audience of discussions is the community at large, the audience of issues is the maintainers.
What Ghostty is doing with a dedicated category for issue triage should work just fine, despite it being an additional hop.
As a maintainers, if you want to be be able to tell real issues from non-issue discussions, you still gave to read them (triage). That's what's taking time.
I don't see how transforming a discussion into an issue is less effort than the other way around. Both are a click.
Github's issues and discussions seem the same feature to me (almost identical UI with different naming).
The only potential benefit I can see is that discussions have a top-level upvote count.
> able to tell real issues from non-issue discussions
imo almost all issues are real, including "non-issue" - i think you mean non-bug - "discussions." for example it is meaningful that discussions show a potential documentation feature, and products like "a terminal" are complete when their features are authored and also fully documented or discoverable (so intuitive as to not require documentation).
99% of the audience of github projects are other developers, not non-programmer end users. it is almost always wrong to think of issues as not real, every open source maintainer who gets hung up on wanting a category of issues narrower than the ones needed to make their product succeed winds up delegating their product development to a team of professionals and loses control (for an example that I know well: ComfyUI).
If discussions had a more modern UI with threads or something then the difference might be real. But AFAICT it’s the same set of functionality, so it’s effectively equivalent to a tag.
They sorta do: each comment on a discussion starts a thread you can reply to, unlike on issues where you have to keep quoting each other to track a topic if there’s more than one. It still sucks, especially since long threads are collapsed and thus harder to ctrl-f or link a reply, but it’s something.
Why do you say that? Curl (arguably one of the most used open source software in the world) currently has 5 open issues https://github.com/curl/curl/issues
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 better.
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)
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 this. You can accidentally _close_ it, but that sends an email notification. This sounds dumb, but it happens, usually due to keyboard shortcuts.
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.
My practical experience with #2 was Terraform ~5 years ago (when I last worked on it, can't speak to the current state). We had something like 1,800 open issues and someone on Twitter decided to farm engagement and dunk on it and use that as an example of how broken it is. It forced me to call for a feature freeze and full on-hands triage. We ultimately discovered there were ~5 crashing bugs, ~50 or so core bugs, ~100 bugs in providers we control, and the rest were 3rd party provider bugs (which we accepted in our issue tracker at the time) or unaccepted/undesigned features or unconfirmed bugs (no reproduction).
With the new approach, these are far enough away that it gets rid of this issue completely.
3. The back-and-forth process of confirming a bug or designing and accepting a feature produces a lot of noise that is difficult to hide within an issue. You can definitely update the original post but then there might be 100 comments below that you have to individually hide or write tooling to hide, because ongoing status update discussions may still be valuable.
This is also particularly relevant in today's era of AI where well written GH issues and curated comments produce excellent context for an agent to plan and execute. But, if you don't like AI you can ignore that and the point is still valid... for people!
By separating out the design + accept into two separate posts, it _forces_ you to rewrite the core post and shifts the discussion from design to progress. I've found it much cleaner and I'm very happy about this.
4. Flat threads don't work well for issue discussion. You even see this in traditional OSS that uses mailing lists (see LKML): they form a tree of responses! Issues are flat. Its annoying. Discussions are threaded! And that is very helpful to chase down separate chains of thought, or reproductions, or possibly unrelated issues or topics.
Once an issue is accepted, the flat threads work _fine_. I'd still prefer a tree, but it's a much smaller issue. :)
-----------
Okay I'm going to stop there. I have more, many more, but I hope this gives you enough for you to empathize a bit that there are some practical issues, and this is something I've both thought of critically for and tried for over a decade.
There's a handful of people in this thread who are throwing around words like "just" or "trivially" or just implying how obvious a simple solution looks without perhaps accepting that I've been triaging and working on GH issues in large open projects full-time non-stop for the last 15 years. I've tried it, I promise!
This is completely a failure of GitHub's product suite and as I noted in another comment I'm not _happy_ I have to do this. I don't think discussions are _good_. They're just the _least bad_ right now, unfortunately.
>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.
Point #2 is very true for me. I get concerned when I look at a project and see thousands of issues. For safety and to not waste my time, if I see that and the project is an unknown to me, I just have to believe that it indicates the project is not being maintained properly.
I definitely think splitting discussion and issues is a good idea for that reason alone.
I usually try to scan the issues and look at a few, to get a vibe of what the makeup of that number is. It can be really attractive to try to just compare project metrics like that, though.
Not to mention you can restrict who can file issues with permissions. So you have a forcing function, whereas hoping tags are correctly applied is a never ending battle.
For one, it might require several rounds of back and forth before its ready to receive the tag, but now the details are spread across several comments instead of neatly at the top
GitHub desperately needs a feature to pin comments in issues or sort by reactions.
Very often in those infamous bugs that has been open for years, having hundreds of ”me too” comments, there are gems with workarounds or reproductions, unfortunately hidden somewhere under 4 iterations of ”click to load 8 more comments”, making it difficult to find. This generates even more ”anyone know how to solve this” spam, further contributing to the difficulty to find the good post.
that solution is not trivial because it requires permission for anyone to comment on issues, which invites irrelevant or unhelpful comments or even complaints. the separation allows issues to be limited to developers only, those who actually work to fix the issues.
technically, messages are messages. this approach no more than grouping messages into different forums. it could also all be under discussion with a sub forum for issues, one for features, one for other topics, etc, and then there would need to be a permission system for each sub forum.
so all this does is to create two spheres of access for users and developers. and that's the point.
in the end it's really a matter of taste and preference.
That's not true, you can limit comments to collaborators if you don't like them. Although note that it's something you've made up, comments are not part of the original list of reasons. Moreover, comments aren't limited in the actual issues, so nothing prevents unhelpful comments, leaving your issue unresolved
How is it not trivially solved by a discussion section? Why is your solution better for someone else's work flow? Why do you feel like you get to impose your way of doing work on an open source project?
Why do you feel like it's ok to make up nonsense about imposing? How can I impose anything on that project? Why break the expected/established workflow of users if the explanation doesn't work? Why are you asking 3 questions without answering 1?
each project has its own workflow. no established workflow is broken. github traditionally imposed a different workflow because initially it didn't even have discussions.
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.
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.
I agree with the general philosophy about user submissions. Browsing closed discussions looks a lot like browsing closed issues. So I'm not sure that the policy is successfully turning bug reports into discussions. But it's at least keeping Issues free from noise for contributors. Github could do more to nudge users into approaching Discussions differently. https://github.com/ghostty-org/ghostty/discussions?discussio...
The point is the opposite, AFAICT. Any user complaint starts as a discussion. If an actionable bug report results from it, it goes to the tracker, which serves as list of problems to work on. A lot of discussions do not end this way, even though they may solve a user's issue anyway, e.g. by providing advice and reference.
Definitely discussing things could also happen in the issue tracker, and some <Actionable> tag could be used to mark issues that are ready to work upon. But I suspect that Discussions are better suited for, well, discussions, while the facilities of the issue tracker can then be used by maintainers / contributors.
Agreed. IMO, it makes sense to have a way to triage possible issues, confirm that they are, in fact, legitimate, and then create issue records to reflect them. As long as users have a way to report anomalous behavior, then, as you say, it’s really no different than using tags on issues. Po-tay-to, po-tah-to.
It is smart; it’s just not a qualitative improvement in many of the submitted discussions which are de facto tier one issues, which I guessed to be GitHub’s fault in the Discussions UX. Not seeing what has you feeling opposite.
Personally, I dig it! Selected parts from linked page:
"""Unlike some other projects, Ghostty does not use the issue tracker for discussion or feature requests. Instead, we use GitHub discussions for that. Once a discussion reaches a point where a well-understood, actionable item is identified, it is moved to the issue tracker. This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on.
This approach is based on years of experience maintaining open source projects and observing that 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves.[...]"""
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. 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!
I'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.
Thanks so much to Henryclarkethicalhacler for helping me hack into my husband's phone so I could see what he is up to and
I was able to catch him red handed, now I am out and a lot happier credit goes to earlier mention hacker for a
good job. If you are also interested in any hack job you can contact him via his email –
HENRYCLARKETHICALHACKER@ GMAIL. COM
I think this is ok. They attempt to add a barrier here, with the attempt to increase the quality of the issue suggested. This may not be the only goal; one may be to have fewer issues raised in total. But there may be several advantages, as well as disadvantages with that approach - it is simply a trade-off.
In particular when I maintain an open source project, I have a lack of time in general so I need to move quickly. I actually don't mind issue discussions on my project, but people can not expect me to invest a lot of time into managing all of those; whether this is a discussion or an issue directly, is not so important, but I know that some project owners don't like open issues that remain open for years. It is kind of a difference in philosophy here.
One trade off is that I am not so likely to get involved in such a project. I may start a discussion, but in general I am very chaotic and may never follow up on discussions I started, simply due to lack of time, too many things to do, forgetting too much too (I do keep notes locally, but these files just keep on growing!).
> But there may be several advantages, as well as disadvantages with that approach - it is simply a trade-off.
Above, the word _simply_ conveys a lot of meaning. This sentence, when considered alone, might be seen to imply that all trade-offs are in a sense, ok, because they are all sort of a matter of taste. This doesn't mesh with my understanding of the world. I frame it this way: for a given objective, some trade-offs are better than others.
Put in reverse, when I see a project making certain trade-offs, I don't assume those trade-offs are in service of some clearly defined objective. Often I see people and organizations mired in trade-offs that are inertial and/or unconsidered.
There is another interesting angle to consider: framing as a question it would be: «When building a product or running a project, how do I make sense of a huge variety of trade-offs?» For that, exploring the Pareto frontier can be a useful method (see [1]) because it reduces the combinatorial explosion.
In the case of Ghostty, I think its values are indeed better served by this GitHub process (which designates an issue as a clear actionable task derived from a discussion).
> Great post. This should be the default configuration, community can make discussions, contributors can make issues.
I'm not so sure. I think this sort of discussion mostly falls within the realm of bike shedding. I'll explain why.
There's such a thing as a ticket life cycle. Ticketing flows typically feature a triage/reproduction stage. Just because someone creates an issue that doesn't necessarily mean the issue exists or isn't already tracked somewhere else, or that the ticket has all the necessary and sufficient information to troubleshoot an issue. When a ticket is created, the first step is to have someone look at it and check if there's something to it. This happens even when tickets are created by internal stakeholders, such as QAs.
GitHub supports ticket labels, and the default set already cover these scenarios.
To me this discussion sounds like a project decided to update their workflow to move triage out of tickets and into a separate board. That's fine, it's the exact same thing but with a slightly more complex process. But it's the same thing.
> Great post. This should be the default configuration, community can make discussions, contributors can make issues.
1. We often say 'should' too easily. The post isn't making such a claim is it? I would shift away from saying 'should' to saying: start somewhere that works for your project, gather feedback and evidence, and adjust thoughtfully. You'll end up in a place that feels authentic.
2. If anything, I would prefer the default be random. Then projects end up being natural experiments. See [1]
3. At a meta level, this reminds me of Brian:
> Brian: Look, you've got it all wrong! You don't need to follow me. You don't need to follow anybody! You've got to think for yourselves! You're all individuals!
Not that not being able to open a ticket is not actually an implemented feature from GitHub; they simply added this issue template to let you know that you shouldn't open one:
*DO NOT OPEN A NEW ISSUE. PLEASE USE THE DISCUSSIONS SECTION.*
*I DIDN'T READ THE ABOVE LINE. PLEASE CLOSE THIS ISSUE.*
So they are using Issues as a project board to track and manage ongoing work items, but Projects is built for exactly that. May be better in the long term to move project management to Projects and let people file bugs with as little friction as possible.
We've been doing this on the Renovate project for years, and it's been hugely useful - we get a lot of reports that users feel to be a bug, but are often misunderstanding or expectations about behaviour that isn't necessarily true.
There are absolutely bugs that get reported - either in functionality or documentation - but by requiring a level of triage in Discussions before promoting them up to Issues is a great way to keep things more actionable for folks wanting to come in and contribute fixes that the maintainers do agree are needing a fix
For those interested in social science research, there are many ways to explore this empirically. You could mix and match some of the following approaches:
1. Ask a high-quality LLM in research mode to gather empirical statistics on how different GitHub projects are setup.
2. Put human eyes on the data you find, look for patterns, see what is interesting. (I recommend reading on approaches that promote transparency about the order in which you collect data, form hypotheses, etc.)
3. Put on your anthropologist hat and do open-ended interviews with project maintainers.
This makes perfect sense and is so much better than getting a flood of half-baked "issues" and then closing them automatically with a bot for "inactivity".
People complain about Github not allowing you to turn off issues and pull requests entirely, but I've always seen it as a positive. It means the truth about code quality, potential caveats, and better forked revisions can disseminate freely even when the author disappears. It becomes a spamfest at times, but is still probably a net positive for the ecosystem.
That being said, as long as you still have the discussion tab, auto-deleting all issues by default is not a big deal.
Yes. Even for casual users looking for help, it’s nice to know that the “issues” tab is just real issues and not random, duplicated complaints and questions. Especially on a project like this that attracts a lot of attention and is highly sensitive to the user’s very specific environment. Most issues are going to not be bugs, or even something the maintainers can work on directly. Instead of trying to cram everything into Issues, why not use the underutilized Discussions tool? Now the Issues list is much more useful as an active tracker of workable items, and as a historical reference of relatively deduped problems.
One difference is that if I submit an issue, and it requires some back and forth to figure out the actionable improvement, then suddenly the issue is very noisy.
Whereas if it goes via a Discussion first, the back and forth happens elsewhere.
Arguably an separate issue could still do this, but it being a discussion sets the expectation better.
This kind of thing happens in Jira or any company's internal bug tracker, and GitHub Issues is not any different. If you want a certain kind of "hygiene", you can always do that in the existing system instead of inventing a whole different solution.
> Arguably an separate issue could still do this, but it being a discussion sets the expectation better.
As someone wearing the post-sales support hat for a non-OSS product, I appreciate use of "ready" tags in Jira. Unlike OSS, our engineers prioritize KPIs to be compensated for their work, and so we must find a way to track the triage discussions within Jira. In a significant way, Jira is solid proof that work happened, even if no actual code was pushed into the repo. If the support team has an unconfirmed bug that requires a technical deep dive, then the "non-ready" Jiras seem like a good fit. I'm open to a better way of doing this and would like to learn more about alternatives, but for now, this is how the teams engage.
It's a good idea to reserve issues for well-defined, actionable stuff.
IRL every dev issue tracker needs a front-end bozo filter to handle the low-hanging fruit and the misunderstandings and the failures to RTFM and the cases of PEBCAK.
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 earmarking and tracking the progress of actionable items. This is somewhat similar to the integration between email clients and task managers, like how it's done in Gmail, Zoho, etc. You read the message first. If it requires an action from your side, create a task from it and link them.
There are other projects that do this too. A good example is the 'mise' project. Sourcehut projects use this workflow almost exclusively since it's the default by design. I think sourcehut had if before github did. What I would like to see is better integration between discussions/messages and task/issue lists on all these platforms.
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.
> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features).
>> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features).
> Do I ever make mistakes?
> No. It’s the users who are wrong.
This is a textbook example of being uncharitable. Framing matters a lot! If you frame something in an uncharitable way, you are likely to "lock in" that view and discount other ones. Mitchell is not saying «users are wrong to give feedback», he is merely saying «the usual conventions are not ideal for this project». Don't confuse the two.
It is clear to me that Mitchell is giving his answer to this question: «what process gives the best results for this OSS project?». He has adjusted the feedback process in a way that he thinks will give better results. This is a consequentialist framing of how to best serve the users of Ghostty, which I think is a useful lens.
I disagree. He's just trying to educate these guys about usability.
Most people by default see "user got something wrong" and respond "rtfm" or "you don't understand" or "don't make mistakes".
The vast majority of people using Ghostty are not stupid. If they misunderstood something or made a mistake, it's highly likely that it could have been avoided with changes to improve Ghostty.
>>> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features).
>> Do I ever make mistakes?
>> No. It’s the users who are wrong.
> I disagree. He's just trying to educate these guys about usability.
I invite you to reconsider for these reasons: (1) Have you seen people "just trying to educate" in an uncharitable way? Many people have. Such cases of 'education' may involve paternalism and/or assuming the other person is ignorant. For example, both can manifest in the phenomenon of "mansplaining". There are more tells, also: (2) The commenter doesn't ask questions; (3) The commenter doesn't steel-man the other position; (4) The commenter uses a mocking tone. (To be fair, I've done such things in the past, but I'm striving to do much less of it.)
> The vast majority of people using Ghostty are not stupid.
No one is claiming this. Individual intelligence is not the same as «how people behave in system S compared to system S'». In other words, people do 'stupid' things all too often -- just hop in an automobile and watch our collective behavior.* Not to mention riots and mobs.
In the case of some issue tracking systems, "not-stupid" people can do things that are counter productive.
So, if project leaders have the ability, dedication, sincerity, rationale, and motivation to experiment with different systems, I say GO FOR IT. Experiment. Take a risk. Refusing to experiment is often worse.
Some people forget a key underlying principle of 'agility'† : start somewhere, gather feedback, be rational, experiment, and see where it takes you. If you see two different teams in different circumstances doing things the same way, you might take a closer look: one or both might have rigid processes that have stopped learning.
> If they misunderstood something or made a mistake, it's highly likely that it could have been avoided with changes to improve Ghostty.
Maybe, but that sounds like a tall claim. Remember that the Ghostty team _did in-fact_ make changes to their _process_ based on reflection.
I put much more confidence in the Ghostty team, who has shown signs of thoughtfulness, to make careful and wise decisions than someone with no skin in the game (a vast majority of the people here), especially uncharitable ones.
* I try not to 'blame' individuals or groups -- most human responses are statistically predictable and often even sensible and maybe even justifiable from a narrow point of view. If anything, I ascribe more importance to the design of roads, automobiles, and the cultural pressures we face.
† Too many forms of 'agility' forget the notion of recursive self-improvement. They instead get mired in ceremony.
Those modern terminal projects have weird defaults and quirky behaviors just to be different.
So to me it's easy to believe that a user expects something to work a certain way, does minimal or no research about it, and go directly to report a bug when in reality it's intented behavior.
I can believe this. I think it depends on the project, but there are certainly some with very high false positives. Maybe that's indicative of a confusing app, I don't know.
"Slop drives me crazy and it feels like 95+% of bug reports, but man, AI code analysis is getting really good. There are users out there reporting bugs that don't know ANYTHING about our stack, but are great AI drivers and producing some high quality issue reports.
This person (linked below) was experiencing Ghostty crashes and took it upon themselves to use AI to write a python script that can decode our crash files, match them up with our dsym files, and analyze the codebase for attempting to find the root cause, and extracted that into an Agent Skill.
They then came into Discord, warned us they don't know Zig at all, don't know macOS dev at all, don't know terminals at all, and that they used AI, but that they thought critically about the issues and believed they were real and asked if we'd accept them. I took a look at one, was impressed, and said send them all.
This fixed 4 real crashing cases that I was able to manually verify and write a fix for from someone who -- on paper -- had no fucking clue what they were talking about. And yet, they drove an AI with expert skill.
I want to call out that in addition to driving AI with expert skill, they navigated the terrain with expert skill as well. They didn't just toss slop up on our repo. They came to Discord as a human, reached out as a human, and talked to other humans about what they've done. They were careful and thoughtful about the process.
People like this give me hope for what is possible. But it really, really depends on high quality people like this. Most today -- to continue the analogy -- are unfortunately driving like a teenager who has only driven toy go-karts."
Seems great to me. Perhaps GitHub should look into incorporating this into the UX somehow? So many projects are issues linking to other issues, I would love to see other projects adopt this to make github task tracking more usable.
Why would GitHub do that just because one project thinks is a good idea, especially when there is absolutely no concrete evidence that this is any more effective or efficient than using issues? All that we have is project maintainers' own beliefs. Bear in mind that these things can be studied and measured quantitatively.
The current "issues" system works fine for most small-medium projects and even many large projects. Any project who looks for a more "serious" solution would have its own Jira/bug tracker system, and you can find plenty of them.
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.
A lot of bugs where I work have the same pattern: one person writes up either what they found to be broken or what they couldn’t do due to a missing feature, then a shadow task is created that describes the bug and what needs to be changed to fix or implement it. I’ve never had problem with both the report and the work-tracker being in the same place but I can see why GitHub calling the product “Issues” might not have been a great name.
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.
Some of it may be unintentional. I've created issues directly through the `gh` CLI before, and issue templates don't show up there at all. If I haven't actually cloned the repo (or, more frequently, if I have a sparse checkout/deleted the files to save space), I have no way of knowing that there's a template and I'll just `gh issue -R some/thing create`.
I finally moved on to the official GitHub app on mobile, but before that I used fasthub and other clients that had no idea about issue templates.
GitHub really needs to add permissions to issues, so that users can't create issues without the template; any kind of failure in creation is a sign that you're doing something wrong. The ability to add tags to issues when creating via CLI would also be helpful.
my fear is people are going to post issue reports, sometimes good ones that we need to act upon, they get autoclosed, and the submitter either never bothers to re-post or they are so annoyed that they don't re-post.
it would be way better if there was only one way for them to get their content in, in the first place
In our case, we've fortunately not found that's happened - we do end up looking at Issues that are closed in this way, and the majority of cases it's someone who's raised a Discussion and want to bypass the triage so create a new Issue from their comment
(I'm thinking of getting some data and words together to look at how this has helped us over the last ~18 months)
The motivation for that is very convincing, yet a quick glance at Issues tab makes me understand it without any additional explanation.
It looks great. As mentally easy to process as Jira tasks. Or even better, cause it was written by a good "PM", which is not always a case commercially.
Works for large projects with active communities (Ghostty has both). The filter pays off when volume is high. Doesn't work for smaller projects where every report matters and you want to lower barriers. The brutal honesty ("80-90% of you are wrong") is refreshing but may alienate contributors. A middle ground would be issue templates with mandatory checklists, filters without adding an extra step.
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.
What I often do on ZeroFS [0] is to convert issues to discussions, it's a one click operation on github and helps reduce the noise for ill-defined issues.
Just do the Apple / Google / MS model where anyone can freely open tickets, and then those bugs are never seen or addressed by any developers. Essentially use the bug tracker as a honeypot to keep the users happy
Maybe "issue" should then be renamed into "TODOs". Because end users have "issues" with a product, it is up for someone with more knowledge to identify if the "issue" is PEBKAC, WONTFIX, FEATURE, or actually a TODO for the developers.
The term "discussion" does not have anything to do with this.
I understand these are all github choices of terms, and it should also be reframed properly by github.
Last week a friend posted an issue to ghostty's github, and it got closed very fast - so he read this "Why users cannot create Issues directly", copied the post and pasted as discussion. Not much difference from my perspective.
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.
This approach is very efficient and keeps the riff raff out. I love it. Even in our internal Jira tickets, they tend to spiral into long discussions in the comments, only to end up becoming entirely new features or even change what the "bug" originally was to something new. I might try to introduce a similar idea now that I've read this. Thanks
Just the first thing that popped into my head reading the reasoning. I think it makes a lot of sense to do it like this. Especially for a product which is cross platform that emulates / replaces other known products and on top has extensive configuration options. I also switched over from kitty a couple of weeks back and really like it.
I’m far from an AI booster but this sounds like a perfect job for an AI classifier to act as a gate keeper. If you can convince the AI that your bug report is sufficiently detailed to be actionable and issue gets created. Should reduce the low quality reports, crazy people and issue spam.
It's more or less what a customer of mine does with its support tickets. We receive the tickets, interact with customers, solve their problem and sometimes in the process we open one or more issues that enter into the backlog. Issues originated by a ticket usually have a high priority.
When I have a clear "Issue" which I've already researched, it's a bit of friction, but it doesn't seem like any more work to dump exactly the same text into a Discussion... and yea. Issues becoming a dumping ground is a real issue. This seems like a reasonable strategy / experiment.
Personally, I use GH Issues for my own work, but there’s very few issues, so it’s not a burden. I’m a non-fan of JIRA.
I have seen GH Issues turn into Reddit-like flamefests (every now and then, someone posts a particularly entertaining one, here). Not my idea of productive work.
@jdx has gone one step further with mise. The issues has been completely disabled. I presume he tracks real issues in another repo. It'd be nice if github could provide first class support for such a workflow.
I briefly tried to contribute to a popular AI project (a ChatGPT-like web-based interface) where I found some bugs and reported them as issues, with steps to reproduce. The maintainer closed them and moved them to discussions, which is what he did to any issue he didn't like or personally didn't believe mattered, I guess. Items in Discussions didn't get any attention, nor were follow-ups looked at. One of the issues even involved the total loss of user data on upgrade.
So this makes me think the developer here just doesn't like the idea of issues being reported on his project.
> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves.
Who does this project actually serve? The "users", or someone else?
If I'm getting overwhelmed with hundreds of issues per week about some confusion around installation or use, I think those issues are completely justified. Something should probably be fixed if the happy path is this obscure. Pushing this reality into another bucket is not the solution for me.
As an OSS maintainer myself, while the amount of tickets about a specific topic _might_ be loosely related to the quality of the docs/installation/etc, this hasn't been true in my observations.
It's one of those explanations that sound very plausible on paper, but if you see real world issues it just doesn't happen, users will ask questions that are clearly explained in the first paragraph of the readme, en masse.
> clearly explained in the first paragraph of the readme
Yeah but people justifiably don't exhaustively read documentation. If people are getting confused because they didn't read some bit of documentation - even the first paragraph of the readme - then you shouldn't just dismiss them as stupid and bask in your superior documentation-reading abilities. You should think about how to resolve that confusion in a way that they would actually see it.
It's hard to explain how to do that without a concrete example, but it usually is possible. It's also usually more work than just replying RTFM, but you should at least be aware that you are choosing not to bother.
I'd rather OSS authors write and improve the software and documentation for most people than do the very time-consuming, burnout-inducing free customer support you are suggesting here (especially for those not bothering of reading even the first paragraph of the documentation).
It's not customer support; it's giving the product good usability. I would much rather they do that than waste time writing documentation that people won't read.
I think a concrete example would help here. Let me find one from this repo...
Ok after looking through about 20 discussions I was actually unable to find a single one that was a misunderstanding or misconfiguration on the user's part. They appear to all be real bugs (or feature requests), and very high quality ones at that.
So I think their assertion that 80-90% of what people think are bugs are actually not is total and utter bullshit.
That's kind of unrelated to what we were discussing though; misunderstandings due to poor usability do happen but I guess we can't easily find examples in Ghostty.
Let's not forget there are actual people behind open source projects. I think it is extremely rude to say those people should SERVE the users of their open source projects for free. The project "serve" the needs of the maintainers. If you as a user don't like something, that is entirely YOUR problem. Feel free to fork it and fix the bugs you think are worthy fixing.
Did you also read the part about using Discussions instead? It’s not that users are not allowed to voice feedback, make request, or ask questions. They should just do so in a different place.
> Any Discussion which clearly identifies a problem in Ghostty and can be confirmed or reproduced will be converted to an Issue by a maintainer
I don’t see how this demonstrates that at all. Issues as a concept seems sound. There is a huge variety of social structures that are built around issues which might make it a good or bad fit
I have never worked on projects that give non members write access to our bug tracker.
This includes both our open source project not giving the public access. And our entirely closed source internal projects not giving other developers within the company write access.
The stale-bots are even worse than that. The reporter may have responded quickly, and the bug may be acknowledged as real. But if there's simply no activity in the issue for the month following, it will be closed.
This is a good AI application - something which accepts user problem reports and tries to group them together. Maybe even reproducing the bug in a sandbox if the description is good enough. Engaging with the complainant to get more info.
This could be useful if not used for enshittification, where you have to get past the chatbot to reach anybody useful.
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 seeking help regarding the error. Instead, it's "When I do X, I get an error".
Maybe I have too much faith in people. I've seen even software engineers become absolutely blind when dealing with errors. I had a time 10 years ago as a tester when I filed a bug ticket with explicit steps that results in a "broken pipe error". The engineer closed the ticket as "Can Not Reproduce" with a comment saying "I can't complete your steps because I'm getting a 'broken pipe error'".
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 of "network problem" between their workstation and some web server, because they were getting an http 403 error.
So, yeah. Regular users? I honestly have 0 expectations from them. They just observe that the software doesn't do what they expect and they'll complain.
Your “technical guy” sounds a lot like me.
When debugging stuff with the devs at our work, I tend to overexplain as much as I can, because often there’s some deep link between systems that I don’t understand, but they do.
I’m a pretty firm believer in “no stupid questions (or comments)”, because often going in a strange direction that the devs assure me isn’t the problem, actually turns out to be the problem (maybe thing A actually has some connection to thing B in a very abstract way!).
I think just serving a different perspective or theory can help us all solve the problem faster, so sometimes it’s worth to pull that thread, even if it seems worthless in the moment.
Maybe I’m just lucky that my engineering colleagues are very patient with me (and maybe less lucky that some of our systems are so deeply intertwined), but I do hope they have more than zero expectations from me, as we mean well and just want to support where we can, knowing full well that ya’ll are leagues ahead in the smarts department.
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 to it. So Azure is indirectly training people that 403 potentially IS a "network issue"... (like their laptop is not connected to VPN, or Private DNS isn't set up right, or traffic isn't being routed correctly or some such).
Yeah, I get that's just plain silly, but it's IAAS/SAAS magic cloud abstraction and that's just the way Microsoft does things.
> 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".
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.
> I do not expect users to understand what an error means
I'm not sure I agree.
Reason ?
The old adage "handle errors gracefully".
The "gracefully" part, by definition means taking into account the UX.
Ergo "gracefully" does not mean spitting out either (a) a meaningless generic message or (b) A bunch of incomprehensible tech-speak.
Your error should provide (a) a user-friendly plain-English description and (b) an error ID that you can then cross-reference (e.g. you know "error 42" means the database connection is foobar because the password is wrong)
During your support interaction you can then guide the user through uploading logs or whatever. Preferably through an "upload to support" button you've already carefully coded into your app.
Even if your app is targetting a techie audience, its the same ethos.
If there is a possibility a techie could solve the problem themselves (e.g. by RTFM or checking the config file), then the onus is on you to provide a suitably meaningful error message to help them on their troubleshooting journey.
There are people that when using a computer, if anything goes remotely wrong, they completely lose all notions of language comprehension. You can make messages as non-technical as possible and provide troubleshooting steps, and they just throw their hands up and say "I'm not a computer person! I don't know what it's telling me!"
20 years ago, I worked the self-checkout registers in retail. I'd have people scan an item (With the obvious audible "BEEP"), and then stand there confused about what to do next. The machine is telling them "Please place the item in the bag" and they'd tell me they don't know what to do. I'd say "What's the machine telling you?" "'Please place the item in the bag'" "Okay, then place the item in the bag" "Oh, okay"
It's like they don't understand words if a computer is saying them. But if they're coming from a human, they understand just fine, even if it's the exact same words.
"Incorrect password. You may have made a mistake entering it. Please try entering it again." "I don't know what that means, I'm going to call up tech support and just say I'm getting an error when I try to log in."
>completely lose all notions of language comprehension
I see this pretty often. These aren't even what should be called typical users in theory. They are people doing a technical job and were hired with technical requirements, an application will spit out a well written error message in the domain they should be professionals in and their brain turns off. And ya, it ends up in a call to me where I state the same thing and they figure the problem out.
I really don't get it.
I think part of it is that most users at some point encounter an error message that is just straight up wrong. For example, a login page that says "wrong password" when in reality the user is typing EXACTLY what they typed on account creation, but the site silently truncated the password. Even one such frustrating experience is enough to teach many users that as soon as they see any error message, they should stop trusting anything the system tells them, including the error message. It's extremely difficult to rebuild user trust after this sort of UX contract violation, particularly because less technical users don't mentally differentiate separate computer systems. All the systems are just "the computer."
Also arguably the users are kind of right. An error indicates that a program has violated its invariants, which may lead to undefined behavior. Any output from a program after entering the realm of undefined behavior SHOULD be mistrusted, including error messages.
I think it's something to do with the expectations of automation. We seem to be wired or trained to trust the machines fully, and enter a state of helplessness when we think we are driven by a machine.
I've seen this with gnss-assisted driving, or with automated driving, or with aircraft autopilot. Something disengages, gives unwarranted trust, we lose context, training fades ; and when thrown back in control, the avalanche of context and responsibility is overwhelming, compounded by the lack of context about the previous intermediate steps.
One of the most worrying dangers of automation, is this trust (even by supposed knowledgeable technicians) and the transition out of the 'the machine is perfect' and when it hands you back the helm on a failure, an inability to trust the machine again.
The way to avoid entering this state, seems to stay deeply engaged in the inputs and decisions of the system (read 'automation should be like iron man, not like ultron') and have a deep understanding of the moving parts, critical design decisions of the system, and traces/visualization/checklist of the intermediate steps.
I don't know where the corpus of research about this is (probably in safety engineering research tomes), but it crystallized for me when comparing the crew reactions and behaviour of the Rio-Paris Air France crash, and the Quantas A380 accident in Singapour.
For the first one, amongst many, many other errors (be it crew management, taking account of the weather...) and problematic sensor behaviour, the transcript tells a harrowing story of a crew not trusting their aircraft anymore after recovering from a sensor failure (that failure ejecting them from autopilot and giving them back mostly full control), ignoring their training, and many of the actual alarms the aircraft was rightly giving, blaring at them.
In the second case, a crew that tries to piece out what capabilities they still have after a massive engine failure (explosion), wrecking most of the other systems with shrapnel. And keeping enough in the loop to decide when the overwhelmed system is giving wrong sensor instructions (transfering fuel from the unaffected reservoirs to actually destroyed, leaky ones).
Human factor studies are often fascinating.
This is not about understanding the message, but switching user mental activity. I go myself in the similar situations many times. One example: I tried to pay my bills in online bank application, but got into error. After several attempts, I did read message and it say "Header size exceed..." . It give me clue that app probably put too much history into cookies. Clear browser data, log in again, and all got works.
Even when error message was clearly understandable for my expertise, it took surprisingly long tome to switch from one mental activity - "Pay bills", to another - "Investigate technical problem". And you have to throw away all short memory to switch into another task. So all rumors about "stupid" users is direct consequence from how human mind works.
> This is not about understanding the message, ...
99% of the population have no idea what "Header size exceeded" means, so it absolutely is about understanding the message, if the devs expect people to read the error.
Yeah, I would certainly not expect the user to understand what to do about a "Header size exceeded" error.
But I WOULD expect the user, when sending a message to support, to say they're getting a "Header size exceeded" error, rather than just say "an error".
This seems to be missing the point. Sometimes users see error messages. Sometimes they're good, sometimes they're bad; and yeah, software engineers should endeavor to make sure that error behaviors are graceful, but of all the not-perfect things in this world, error handling is one of the least perfect, so users do encounter unfortunately ungraceful errors.
In that case (and even sometimes in the more "graceful" cases), we don't always expect the user to know what an error message means.
If I can victim-blame for a moment, I don't know what my mom is supposed to do when a streaming service on her TV says there's a problem and will she please report a GUID to the support department.
No, my mom is not eidetic, and no, she's not going to upload a photo of her living room.
Totally agree with you, though, when the full error message is at least capable of being copied to the clipboard.
Most (all?) photo apps include a crop function, allowing your mom just crop out everything else.
I hope you’re being sarcastic. If not, expecting someone’s parent to know how to use a photo app’s crop functionality just to communicate an error state is a failure of understanding typical streaming app users.
I wasn't being sarcastic. This is not a case of not being capable of doing something, it's about not knowing the functionality exists. Cropping is very simple. I assumed the GP didn't know about it either or he would have taught his mom already.
Could the manufacturer solve this in a better way? Probably but that won't solve the issue the customer has now.
Poe's Law goes both ways. As a matter of fact, my mom invented digital photo cropping (or "pixel array extent adjustment," because even in her prime she wasn't a marketing genius, bless her heart). We know better than to expect her to submit a bug report once she's settled down to watch TV for the evening.
Jokes aside, "upload a photo of her living room" was meant to highlight the ridiculousness of the UX. I believe the designer of that flow had an OKR to decrease the number of reported bugs.
Joel Spolsky solved this over 25 years ago https://www.joelonsoftware.com/2000/04/26/designing-for-peop...
That solves nothing, just describes the problem.
> 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.
My wife’s a doctor. Trust me, this isn’t unique to technical pursuits.
Patient: My foot hurts.
Wife: Which part of it?
Patient: It all hurts.
Wife: Does your heel hurt?
Patient: No.
Wife: Does your arch hurt?
Patient: No.
Wife: Do your toes hurt?
Patient: This one does.
Wife: Does anything but that one toe hurt?
Patient: No.
Wife: puts on a brave smile
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.
IMO it still has poor discoverability, constant filtering between the triage status flags and non-flagged stuff, stuff that might not have been flagged by accident, reporters putting tags on issues themselves, issues can only be closed by non-admins rather than truly deleted, random people complaining about this or that on unrelated tickets...
It all stems from the fact that all issues are in this one large pool rather than there being a completely separate list with already vetted stuff that nobody else can write into.
Sounds like it could be fixed by making it configurable to hide all issues without a certain tag (or auto-apply a hiding tag) for the issues "landing page".
This still puts the onus on the developers to categorise the issues which I'm guessing they don't want to do.
How is that different from other bug tracking systems? The devs have to triage submitted tickets there too
There are several automation solutions for GH issues. You could have an automatic “unconfirmed” tag applied to every user-created issue if you wanted.
RFC1925¹, section 2(3):
Translation: sure, you can make this work by piling automation on top. But that doesn't make it a good system to begin with, and won't really result in a robust result either. I'd really rather have a better foundation to start with.¹ https://www.rfc-editor.org/rfc/rfc1925
I hate to break it to you, but all the other ticket systems do this by piling automation on top as well.
> I hate to break it to you, but all the other ticket systems do this by piling automation on top as well.
The rebuke to your comment is right in your comment: "other ticket systems do this by…"
The ticket system does it. As in, it has it built-in and/or well integrated. If GitHub had the same level of integration that other ticket systems achieve with their automation, this'd be a non-issue. But it doesn't, and it's a huge problem.
P.S.: I hate to break it to you, but "I hate to break it to you, but" is quite poor form.
No, it's not that well integrated. They don't call it 'tags' but they work exactly the same way. JIRA, the most commonly cited example in this thread, has a whole separate engine for it and your JIRA admin builds the ticket flow manually. All the way back in RT this sort of thing was handled by a cron job. Github leveraging actions to accomplish this isn't much of a difference.
P.S. I didn't ask
They're already doing that by moving discussions to issues. In fact it's more work for them because they have to actually create the issue instead of just adding a "confirmed bug" label or whatever.
I guess it probably leads to higher quality issue descriptions at least, but otherwise this seems pretty dumb and user-hostile.
There’s a one-click button to convert from discussion to issue (and vice versa). It’s hardly more work. But I do feel like discussions are kind of hidden and out of the way on GitHub.
On repos I maintain, I use an “untriaged” label for issues and I convert questions to discussions at issue triage time.
Isn't that basically what Ghostty is doing also?
That's always the case. Who else should triage?
> 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 this pile of expletive or makes these "alternate" platforms not be so alternate anymore so we can move off.
None of the alternative forges have a better issue tracker implementation. For the most part, they are basically copies of GitHub. No hope there. :(
The classification here is not what type of issue it is, it's whether it's an issue or not. Creating an issue for things that aren't issues is fundamentally broken. There's no way to fix that except by piling bad design on bad design to make it so that you can represent non-issues using issues and have everything still be somewhat usable.
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.
> 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.
All of this is possible on GitHub issues and is in fact done by many projects, by this metric I dont see how GitHub Issues is any different than say, JIRA. In both cases, as you mentioned, someone needs to triage those issues, which would, of course, be the developers as well. Nothing gained, nothing lost.
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.
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.
Discussion systems all the way down :-). This is a fair assessment of the github issues system. I suspect that because git(1) can be a change control system for anything there is never any hope of making an effective issue tracker for a particular thing it is being used to manage change on. The choice the project made to allow the developers to determine when something was an issue is essentially adding a semantic layer on top of issues that customizes it for this particular corpus of change management.
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.
Don't forget the rude, entitled, and aggressive, they are legion.
It's simply a great idea. The mindset should be 'understand what's happening', not 'this is the software's fault'.
The discussion area also serves as a convenient explanation/exploration of the surrounding issues that is easy to find. It reduces the maintainer's workload and should be the default.
[flagged]
Yeah but a good issue tracker should be able to help you filter that stuff out. That ghostty finds discussions to be a better way to triage user requests/issues is somewhat quirky, although a perfectly valid option. As is just using issues, imo. Just good to make sure users know how to report an issue, and what information to include.
To be clear, I think discussions on the whole as a product are pretty bad. I'm not happy having to use them, but given my experience trying different approaches across multiple "popular" projects on GH, this approach has so far been the least bad. Although I'm still sad about it.
> Yeah but a good issue tracker should be able to help you filter that stuff out.
Agreed. This highlights GitHub's issue management system being inadequate.
(Note: I'm the creator/lead of Ghostty)
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.
It is weird to push the idea that Facebook is some kind of pinacle of good and easy to use UI. That's the first one. It's quite the opposite, with people constantly complaining how bad, clunky and confusing Facebook is. And it is not the recent trend either. It has always been this way and e.g. VK has always had a better UI/UX that Facebook (and Telegram's is better that Whatsapp's).
Not as pinnacle of good - but pinnacle of “you don’t have to think, just scroll, occasionally like something” ;).
Then people expect accounting software to be just login click one or two buttons.
But still, compared to something like email, the previous standard for most people, Facebook was an unbelievable step forward. People complain about anything.
Facebook is a step forward in terms of features. But it is a clear regression in terms of UI, easiness, usability, understandability of email. Email is very simple in both concept and practice.
I think I disagree - when it comes to sharing large files, something like a video, or even a picture in 2005, email was nowhere near as good. And also having a place to comment on things without the stacking up of reply chrome is genuinely better.
> when it comes to sharing large files, something like a video, or even a picture in 2005, email was nowhere near as good.
That's just a stupid limitation and not even a technical one. You could happily send GBs over email. You can also easily filter allowed attachment size by sender on the recipient side, because by the time the attachment size is told, both information was already provided.
facebook literally obfuscates their UI to stop you turning off "features" they want to push on you
it is a UI designed to be hard to use
You're talking about two different things here (and I'm not condoning either, to be clear.)
1) UI = a clearly documented way to configure all features and make the software work exactly how you want.
2) UI = load a web page and try to do the thing you wanted to do (in this case communicate with some specific people).
FB is clearly terrible at 1 but pretty alright at 2.
> 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.
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.
For 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
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. The report at hand seems to affect a very limited number of users (given the lack of reports and information about them). There are lots of X meme posts about Ghostty in the macOS "Force Close" window using a massive amount of RAM but that isn't directly useful because that window also reports all the RAM _child processes_ are using (e.g. if you run a command in your shell that consumes 100 GB of RAM, macOS reports it as Ghostty using 100 GB of RAM). And the window by itself also doesn't tell us what you were doing in Ghostty. It farms good engagement, though.
2. We've run Ghostty on Linux under Valgrind in a variety of configurations (the full GUI), we run all of Ghostty's unit tests under Valgrind in CI for every commit, and we've run Ghostty on macOS with the Xcode Instruments leak checker in a variety of configurations and we haven't yet been able to find any leaks. Both of these run fully clean. So, the "easy" tools can't find it.
3. Following point 1 and 2, no maintainer familiar with the codebase has ever seen leaky behavior. Some of us run a build of Ghostty, working full time in a terminal, for weeks, and memory is stable.
4. Our Discord has ~30K users, and within it, we only have one active user who periodically gets a large memory issue. They haven't been able to narrow this down to any specific reproduction and they aren't familiar enough with the codebase to debug it themselves, unfortunately. They're trying!
To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users. That's why the discussion is open and we're soliciting input. I even spent about an hour today on the latest feedback (posted earlier today) trying to use that information to narrow it down. No dice, yet.
If anyone has more info, we'd love to find this. :)
This illustrates the difficulty of maintaining a separation between bugs and discussions:
> To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users
In this case it seems you believe a bug exists, but it isn't sufficiently well-understood and actionable to graduate to the bug tracker.
But the threshold of well-understood and actionable is fuzzy and subjective. Most bugs, in my experience, start with some amount of investigative work, and are actionable in the sense that some concrete steps would further the investigation, but full understanding is not achieved until very late in the game, around the time I am prototyping a fix.
Similarly the line between bug and feature request is often unclear. If the product breaks in specific configuration X, is it a bug, or a request to add support for configuration X?
I find it easier to have a single place for issue discussion at all stages of understanding or actionability, so that we don't have to worry about distinctions like this that feel a bit arbitrary.
Is the distinction arbitrary? It sounded like issues are used for clear, completable jobs for the maintainers. A mysterious bug is not that. The other work you describe is clearly happening, so I'm not seeing a problem with this approach other than its novelty for users. But to me it looks both clearer than the usual "issue soup" on a popular open source project and more effective at using maintainer time, so next time I open-source something I'd be inclined to try it.
Some people see "bug tracker" and think "a vetted report of a problem that needs fixing", others see "bug tracker" and think "a task/todo list of stuff ready for an engineer to work on"
Both are valid, and it makes sense to be clear about what the teams view is
Agreed. Honestly, I think of those as two very different needs that should have very different systems. To me a bug tracker is about collecting user reports of problems and finding commonalities. But most work should be driven by other information.
I think the confusion of bug tracking with work tracking comes out of the bad old days where we didn't write tests and we shipped large globs of changes all at once. In that world, people spent months putting bugs in, so it makes sense they'd need a database to track them all after the release. Bugs were the majority of the work.
But I think a team with good practices that ships early and often can spend a lot more time on adding value. In which case, jamming everything into a jumped-up bug tracker is the wrong approach.
I think these are valid concerns for a project maintainer to think through for managing a chosen solution but I don't think there is a single correct solution. The "correct", or likely least bad, solution depends on the specific project and tools available.
For bug reports, always using issues for everything also requires you to evaluate how long an issue should exist before it is closed out if it can't be reproduced(if trying to keep a clean issue list). That could lead to discussion fragmentation if now new reports start coming in that need to be reported, but not just anyone can manage issue states, so a new one is created.
From a practical standpoint, they have 40 pages of open discussion in the project and 6 pages of open issues, so I get where they're coming from. The GH issue tracker is less than stellar.
I also see ghosty consume a massive amount of memory and periodically need to restart.
I have a one bit that might be useful that I learned from debugging/optimizing Emacs.
macOS' Instruments tool only checks for leaks when it can track allocations and it is limited to ~256 stack depth. For recursive calls or very deep stacks (Emacs) some allocations aren't tracked and only after setting malloc history flags [0] I started seeing some results (and leaks).
Another place I'm investigating (for Emacs) is that AppKit lifecycle doesn't actually align with Emacs lifecycle and so leaks are happening on the AppKit and that has ZERO to do with application. Seems that problem manifests mostly on a high end specs (multiple HiDPI displays with high variable refresh rate, powerful chip etc.)
Probably nothing you haven't investigated yet, but it is similar to the ghost (pun intended) I've been looking for.
[0]: https://developer.apple.com/library/archive/documentation/Pe...
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
The terminfo database is one of those thankless xkcd dependencies. In this case, it's been thanklessly maintained since forever by Thomas Dickey.
https://xkcd.com/2347/
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.
Complete speculation, but does tmux use the xterm alternative screen buffer? I can see a small bug in that causing huge memory leaks, but not showing up in testing.
On some level, that's impressive. Any idea of how long Ghostty was alive? Maybe this a new feature where Ghostty stores LLM model parameters in the terminal scrollback history? /s
Not which parts of this are sarcastic or not, but it was probably running for a few weeks. High variance on that estimate though. I was running 5+ Claude Code instances and a similar number of vim instances.
Is it possible for Ghostty to figure out how much memory its child processes (or tabs) are using? If so maybe it would help to surface this number on or near the tab itself, similar to how Chrome started doing this if you hover over a tab. It seems like many of these stem from people misinterpreting the memory number in Activity Monitor, and maybe having memory numbers on the tabs would help avoid that.
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?
They don't have to be, but without a reproduction for maintainers, its up to the end users to provide enough information for us to track it down, and this user hasn't been able to yet.
The point is to reduce reported issues from non maintainers as close to 0 as possible. This does that.
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.
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 clean up for you, but some of those won’t be false positives.
Ghostty is written in Zig.
It will, but they will be abbreviated (only total amount shown, not the individual stack traces) unless you ask to show them in full.
I’m sure they would appreciate a report as it doesn’t seem that it can be reproduced yet
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.
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 DAW with a bazillion plugins and samples, anything involving 4k video are all workloads that would struggle running on such a small RAM allowance.
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.
> We've saved a fair bit on cloud costs
our company just went with the "server in the basement" approach, with every employee having a user account (no VM or docker separation, just normal file permissions). Sure, sounds like the 80s, but it works rearly well. Remote access with wireguard, uptime similar or better than cloud, sharing the same beefy CPUs works well and gives good utilization. Running jobs that need hundreds of GB of RAM isn't an issue as long as you respect other's needs too dont hog the RAM all day. And in amortized costs per employee its dirt cheap. I only wish we had more GPUs.
> Interesting. I required all my devs to use local VMs for development.
It doesn’t work when you’re developing on a large database, since it won’t fit. Database (and data warehouse) development has been held back from modern practices just for this reason.
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.
I find this quite surprising! What benefit does your org accrue by mandating that the db instance used for testing is centralised? Where I am, the tests simply assume that there’s a database available on a certain port. docker-compose.yml makes it easy to spin this up for those so inclined. At that stage it’s immaterial whether it’s running natively, or in docker, or forwarded from somewhere else. Our tests stump up all the data they need and tear down the db afterwards. In contrast, I imagine that a dev k8s cluster requires some management and would be a single point of failure.
I really don't understand why they do what they do.
Large corp gotta large corp?
My guess is that providing the ability to pull containers means you can run code that they haven't explicitly given permission for, and the laptop scanning tools can't hijack them?
For many companies, IP isn’t allowed to leave environments controlled by the company, which employee laptops are not.
Yes, zero latency typing in your local IDE on a laptop sounds like the dream.
In enterprise, we get shared servers with constant connection issues, performance problems, and full disks.
Alternatively we can use Windows VMs in Azure, with network attached storage where "git log" can take a full minute. And that's apparently the strategic solution.
Not to mention that in Azure 8 CPUs gets you four physical cores of a previous gen server CPU. To anyone working with 4 CPUs or 2 physical cores: good luck.
Browser + 2 vscode + 4 docker container + MS Teams + postman + MongoDB Compass
Sure it is bloated, but it is the stack we have for local development
> But, I assume devs just do RAM heavy dev work on a server over ssh.
This assumption is wrong. I compile stuff directly on my laptop, and so do a lot of other people.
Also, even if nobody ran compilers locally, there is still stuff like rustc, clangd, etc. which take lots of RAM.
You asked if there is a justification and then in the same post justified why you need it.
My post was about laptop RAM. I counted server-side RAM as a separate thing.
Chrome on my work laptop sits around 20-30GB all day every day.
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 them after a week or month or so.
Combine that with a search function that can search in contents as well as the title, and I'm changing habbits ASAP.
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 (<5) or a bookmark (themselves shared when necessary on e.g a Slack canvas so the whole team has easy access, not just me).
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.
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.
If I'm doing work than involves three different libraries, I'm not reading and committing to memory the whole documentation for each of those libraries. I might well have a few tabs with some of those libraries' source files too. I can easily end up with tens of tabs open as a form of breadcrumb trail for an issue I'm tracking down.
Then there's all the basic stuff — email and calendar are tabs in my browser, not standalone applications. Ditto the the ticket I'm working on.
I think the real issue is that browsers need to some lightweight "sleep" mechanism that sits somewhere between a live tab and just keeping the source in cache.
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.
The high memory usage is due to the optimization. Responsiveness, robustness and performance was improved by making each tab independent processes. And that's good. Nobody needs 80 tabs, that's what bookmarks are for.
"that's what bookmarks are for"
And if you are lucky, the content will still be there the next time.
Is there a straightforward way to have one-process-per tab in browsers without using significant amounts (O(n_tabs)) of memory?
There is no justification for that IMHO. The program text only needs to be in memory once. However, each process probably has its own instance of the JS engine, together with the website's heap data and the JIT-compiled code objects. That adds up.
I'd very much like a crash in one tab not to kill other tabs. And having per tab sandboxing would be more secure, no?
What do you mean? All these features are provided by process per tab.
[flagged]
Thats a weird assumption to make.
~10 projects in Cursor is 25GB on it's own.
How much would it take up if there was less RAM available. A web browser with a bunch of tabs open but not active seems like the type of system that can increase RAM usage by caching, and decrease it by swapping (either logically at the application level, or letting the OS actually swap)
The computer has 18GB of total RAM so I would hope that it’s already trying to conserve memory.
It’s kind of humorous that everyone interpreted the comment as complaining about Chrome. For all I know, it’s justified in using that much memory, or it’s the crappy websites I’m required to use for work with absurdly large heaps.
I really just meant that at least for work I need more than 8GB of RAM.
I do work off of a Chromebook with 8GB of RAM total, but I do keep an eye on how many tabs I have open.
>But, I assume devs just do RAM heavy dev work on a server over ssh.
Why do you assume that? Its nice to do things locally sometimes. Maybe even while having a browser open. It doesn't take much to go over 8gb.
With 32 GB I can run two whole Electron applications! Discord and Slack!
It's a life of luxury, I tell you.
Browsers can get quite bloated, especially if one is not in the habit of closing tabs or restarting it from time to time. IDEs, other development tools, and most Electron abominations are also not shy about guzzling memory.
The author says in the first link he only heard it reported twice, which I'm guessing is the latter two links (the two discussions)
Your second link looks like an X user trying to start a flamewar; the rest of the replies are hidden to me.
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.
It can also be remarkably picky about GPUs, even otherwise well-supported integrated GPUs, but any discussion of this is declared a GTK problem (or an nvidia problem, even on intel).
It's not clear to me why I'd want to use Ghostty over WezTern or Kitty, TBH. Ghostty is certainly trends on social media, but that's a negative signal for me.
Seems like the contributors don't feel like it's clear enough yet to make an actionable issue and needs more discussion. Are you a contributor?
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 notifications and your future replies are silently discarded.
As a maintainer, having two trackers per project never made sense to me, so I’ve disabled discussion everywhere.
This is mostly a criticism of how GitHub implemented this feature, not of the decision taken here.
> 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.
I personally don’t like discussions either. I treat issues to be issues experienced by the user. It doesn’t mean that there’s an issue caused by bugs in the software. User creates an issue that turns out to be caused by user not following instructions? Just help the user and close the issue.
At the very least I think what matters here is the process. The same exact process could be implemented via, for example, issue labels. It would not be hard for maintainers to search for issues with label "bug", which only maintainers can assign. There are clear UX tradeoffs between the two approaches.
Why would checking be duplicated? One would need to check only the discussions in this case, since issues will be created from discussions once something is ready to be worked on (as I understood it)
That’s only for non-maintainer submissions. When a maintainer notices a bug or decides on a new feature, they can open an issue for that right away, without prior discussion.
> Tickets cannot be moved between trackers
You can convert an issue to a discussion and vice versa, so no duplication is needed and your notification should be preserved.
Or do you mean something else?
I've been annoyed at this distinction myself when trying to troubleshoot problems with other Github-hosted software. I actually think the distinction Ghostty is making here where the Discussion section is open for anyone to bring up an issue with a project, and the Issues section is locked down to official maintainers and is only used for tracking well-scoped planned changes to the software (which might arise from a user-initiated discussion about a problem) makes a great deal of sense. I haven't seen any other Github-hosted project which organizes itself in exactly this way but I have zero problem with it as a user of Ghostty myself.
behold the best way to search github issues. Using Google or whatever decent search engine:
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
Google checks my site’s site map at least every day. I rarely see anything out of date in their index.
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.
I always struggle to understand this level of entitlement. No one is forcing you to use any of these projects. The vast majority of the time, drive-by bug reports by users are a complete waste of time because they're either a user error or not described in sufficient detail to debug. In other words, mostly noise, and adding more noise isn't really helpful.
If you want to contribute, a much better way is to work on bugs that are already well defined. There is generally no shortage of known bugs in software, there is however a shortage of people fixing them.
There's zero entitlement expressed by the parent, he's just trying to help the project, but is encountering unnecessary friction.
It's not that he has some inner urge to contribute in some way, he just encountered a bug while using the software and wants to report it. The alternative isn't coding — it's no contribution at all.
I think this is exactly the point most people miss. No contribution is better than bad contribution. Most issues people file are bad. I previously worked at a major OSS company and the vast majority of bug reports are just noise. It takes time to sift through them and they add no value, just waste time. If people did less of that, that would be a good outcome, not a bad one. Sure, there's useful reports there sometimes, but it's more rare than you'd think. On top of that, many of those are dupes of issues we've already found and filed, just haven't had time to fix yet.
How is “submit your issue to this nearly identical discussion tool in the same web app” a burden?
Maintainers did a bunch of useful work for them and they refuse to report issues the way maintainers find the most useful, because it's a burden to help maintainers do all their free work.
> No one is forcing you to use any of these projects
Unless you only ever work on projects that you have full absolute control over (unlikely if you have a job) then yes they absolutely are.
This is like being forced to pay 50 bucks to your apartment because someone else broke the door. Then when you complain about it people tell you you’re entitled!
But it’s not your apartment (project/repo), it’s someone else’s. If it were yours, the rules wouldn’t apply.
You can clone the other person’s apartment for free and do whatever you like, though. Just don’t barge in to someone else’s apartment and demand they treat you, a stranger, like if it were yours.
Arrogance? Those people are spending their time and effort on an open source project, without asking a penny in return. I think they are entitled to have restrictions on how bugs should be reported.
To be fair it also stinks of arrogance to think that you have the skills to know "what is clearly a bug" 100% of the time in projects you don't own.
> 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.
>90% of the time it's usually pretty clear if something is a bug, especially if there's log files full of errors.
Fwiw, you might have misinterpreted the idiomatic expression "all the time" as meaning "100% of the time". It just means "often" or "commonly". The parent is just saying they often find bugs, they know they're bugs through experience.
Of course anyone can make a mistake. Maybe you prefer the 'discussions' route because it's only seemingly then possible for a projects own devs to make a mistake in creating an issue.
The arrogance in in users like yourself who think they know better than the project owners how to run their issue tracker. This is just a variation. It’s not a barrier, it’s an attempt to improve the quality of the issues that are filed in a way that’s more useful for everyone.
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.
Maybe you should become part of the project if you find bugs regularly ;-)
How is opening a discussion more friction than opening an issue?
In the python projects in question, unlike with the Ghostty project, there isn't an "issue triage" discussion category that maintainers look at. They have just discussions, and everything is treated as such. So when you raise an issue in discussions, it either goes to the void or people come in looking for a discussion of alternative approaches to do what you're trying to do that don't hit the bug, rather than treating the bug as a bug.
At a high level - the audience of discussions is the community at large, the audience of issues is the maintainers.
What Ghostty is doing with a dedicated category for issue triage should work just fine, despite it being an additional hop.
Your feedback is very important to us. Please fill out this long ass form and provide mountains of telemetry as barriers to participation.
Issues simply don't scale. Using discussions as a filter is a good idea.
If you spend more time closing issues than creating them manually from discussions, the math adds up.
What is the actual difference?
As a maintainers, if you want to be be able to tell real issues from non-issue discussions, you still gave to read them (triage). That's what's taking time.
I don't see how transforming a discussion into an issue is less effort than the other way around. Both are a click.
Github's issues and discussions seem the same feature to me (almost identical UI with different naming).
The only potential benefit I can see is that discussions have a top-level upvote count.
> able to tell real issues from non-issue discussions
imo almost all issues are real, including "non-issue" - i think you mean non-bug - "discussions." for example it is meaningful that discussions show a potential documentation feature, and products like "a terminal" are complete when their features are authored and also fully documented or discoverable (so intuitive as to not require documentation).
99% of the audience of github projects are other developers, not non-programmer end users. it is almost always wrong to think of issues as not real, every open source maintainer who gets hung up on wanting a category of issues narrower than the ones needed to make their product succeed winds up delegating their product development to a team of professionals and loses control (for an example that I know well: ComfyUI).
If discussions had a more modern UI with threads or something then the difference might be real. But AFAICT it’s the same set of functionality, so it’s effectively equivalent to a tag.
They sorta do: each comment on a discussion starts a thread you can reply to, unlike on issues where you have to keep quoting each other to track a topic if there’s more than one. It still sucks, especially since long threads are collapsed and thus harder to ctrl-f or link a reply, but it’s something.
> If you spend more time closing issues than creating them manually from discussions, the math adds up.
The math is even better if you just ignore all issues and close them after two weeks for being stale!
Wish this was /s but it isn't.
As long as it does not affect the metrics of your resume! /s
Why do you say that? Curl (arguably one of the most used open source software in the world) currently has 5 open issues https://github.com/curl/curl/issues
Not sure curl is a good example since it’s already very mature and boring (in a good way)
> 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 better.
Can't you just set a bookmark with the filters you want?
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 this. You can accidentally _close_ it, but that sends an email notification. This sounds dumb, but it happens, usually due to keyboard shortcuts.
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.
My practical experience with #2 was Terraform ~5 years ago (when I last worked on it, can't speak to the current state). We had something like 1,800 open issues and someone on Twitter decided to farm engagement and dunk on it and use that as an example of how broken it is. It forced me to call for a feature freeze and full on-hands triage. We ultimately discovered there were ~5 crashing bugs, ~50 or so core bugs, ~100 bugs in providers we control, and the rest were 3rd party provider bugs (which we accepted in our issue tracker at the time) or unaccepted/undesigned features or unconfirmed bugs (no reproduction).
With the new approach, these are far enough away that it gets rid of this issue completely.
3. The back-and-forth process of confirming a bug or designing and accepting a feature produces a lot of noise that is difficult to hide within an issue. You can definitely update the original post but then there might be 100 comments below that you have to individually hide or write tooling to hide, because ongoing status update discussions may still be valuable.
This is also particularly relevant in today's era of AI where well written GH issues and curated comments produce excellent context for an agent to plan and execute. But, if you don't like AI you can ignore that and the point is still valid... for people!
By separating out the design + accept into two separate posts, it _forces_ you to rewrite the core post and shifts the discussion from design to progress. I've found it much cleaner and I'm very happy about this.
4. Flat threads don't work well for issue discussion. You even see this in traditional OSS that uses mailing lists (see LKML): they form a tree of responses! Issues are flat. Its annoying. Discussions are threaded! And that is very helpful to chase down separate chains of thought, or reproductions, or possibly unrelated issues or topics.
Once an issue is accepted, the flat threads work _fine_. I'd still prefer a tree, but it's a much smaller issue. :)
-----------
Okay I'm going to stop there. I have more, many more, but I hope this gives you enough for you to empathize a bit that there are some practical issues, and this is something I've both thought of critically for and tried for over a decade.
There's a handful of people in this thread who are throwing around words like "just" or "trivially" or just implying how obvious a simple solution looks without perhaps accepting that I've been triaging and working on GH issues in large open projects full-time non-stop for the last 15 years. I've tried it, I promise!
This is completely a failure of GitHub's product suite and as I noted in another comment I'm not _happy_ I have to do this. I don't think discussions are _good_. They're just the _least bad_ right now, unfortunately.
>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.
Point #2 is very true for me. I get concerned when I look at a project and see thousands of issues. For safety and to not waste my time, if I see that and the project is an unknown to me, I just have to believe that it indicates the project is not being maintained properly.
I definitely think splitting discussion and issues is a good idea for that reason alone.
I usually try to scan the issues and look at a few, to get a vibe of what the makeup of that number is. It can be really attractive to try to just compare project metrics like that, though.
Sounds like maybe the next project should be a better bug report/issue tracker
I recommend posting (or lining to) this somewhere on GitHub, maybe in the pinned issue.
Or as a discussion lol
Not to mention you can restrict who can file issues with permissions. So you have a forcing function, whereas hoping tags are correctly applied is a never ending battle.
Seems like a pretty huge cost just because you don't want to create a bookmark...
For one, it might require several rounds of back and forth before its ready to receive the tag, but now the details are spread across several comments instead of neatly at the top
GitHub desperately needs a feature to pin comments in issues or sort by reactions.
Very often in those infamous bugs that has been open for years, having hundreds of ”me too” comments, there are gems with workarounds or reproductions, unfortunately hidden somewhere under 4 iterations of ”click to load 8 more comments”, making it difficult to find. This generates even more ”anyone know how to solve this” spam, further contributing to the difficulty to find the good post.
No, you can always summarize details neatly at the top, you can edit comments, you know?
Yes but the person who is qualified to summarize might not be the person who initiated a discussion.
No again, the person qualified can edit the initial comment.
Hmm didn't realize that repo owners could edit other folks' comments
Still seems like a messier workflow and it might leave behind a dozen comments not related to the progress of the ticket.
Don't worry, I'm willing to bet that there's an AI integration in the works for this...
that solution is not trivial because it requires permission for anyone to comment on issues, which invites irrelevant or unhelpful comments or even complaints. the separation allows issues to be limited to developers only, those who actually work to fix the issues.
technically, messages are messages. this approach no more than grouping messages into different forums. it could also all be under discussion with a sub forum for issues, one for features, one for other topics, etc, and then there would need to be a permission system for each sub forum.
so all this does is to create two spheres of access for users and developers. and that's the point.
in the end it's really a matter of taste and preference.
That's not true, you can limit comments to collaborators if you don't like them. Although note that it's something you've made up, comments are not part of the original list of reasons. Moreover, comments aren't limited in the actual issues, so nothing prevents unhelpful comments, leaving your issue unresolved
well that's exactly what they did, limit comments to collaborators. anyone else can comment in the discussion forum.
Well, that's not what they did, did you not read the last sentence of my previous comment (or checked for yourself)?
How is it not trivially solved by a discussion section? Why is your solution better for someone else's work flow? Why do you feel like you get to impose your way of doing work on an open source project?
Why do you feel like it's ok to make up nonsense about imposing? How can I impose anything on that project? Why break the expected/established workflow of users if the explanation doesn't work? Why are you asking 3 questions without answering 1?
> Why break the expected/established workflow of users
Is it really that hard to open a discussion?
each project has its own workflow. no established workflow is broken. github traditionally imposed a different workflow because initially it didn't even have discussions.
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.
I agree with the general philosophy about user submissions. Browsing closed discussions looks a lot like browsing closed issues. So I'm not sure that the policy is successfully turning bug reports into discussions. But it's at least keeping Issues free from noise for contributors. Github could do more to nudge users into approaching Discussions differently. https://github.com/ghostty-org/ghostty/discussions?discussio...
The point is the opposite, AFAICT. Any user complaint starts as a discussion. If an actionable bug report results from it, it goes to the tracker, which serves as list of problems to work on. A lot of discussions do not end this way, even though they may solve a user's issue anyway, e.g. by providing advice and reference.
Definitely discussing things could also happen in the issue tracker, and some <Actionable> tag could be used to mark issues that are ready to work upon. But I suspect that Discussions are better suited for, well, discussions, while the facilities of the issue tracker can then be used by maintainers / contributors.
I find this separation pretty smart.
Agreed. IMO, it makes sense to have a way to triage possible issues, confirm that they are, in fact, legitimate, and then create issue records to reflect them. As long as users have a way to report anomalous behavior, then, as you say, it’s really no different than using tags on issues. Po-tay-to, po-tah-to.
It is smart; it’s just not a qualitative improvement in many of the submitted discussions which are de facto tier one issues, which I guessed to be GitHub’s fault in the Discussions UX. Not seeing what has you feeling opposite.
Personally, I dig it! Selected parts from linked page:
"""Unlike some other projects, Ghostty does not use the issue tracker for discussion or feature requests. Instead, we use GitHub discussions for that. Once a discussion reaches a point where a well-understood, actionable item is identified, it is moved to the issue tracker. This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on.
This approach is based on years of experience maintaining open source projects and observing that 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves.[...]"""
Kind of an unstructured Basecamp ShapeUp where the "ask" has been shaped already through requirements gathering and bets made.
I proposed something similar for bitcoin: https://gnusha.org/pi/bitcoindev/CABaSBax-meEsC2013zKYJnC3ph...
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/.github/workf...
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!
I'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.
Thanks so much to Henryclarkethicalhacler for helping me hack into my husband's phone so I could see what he is up to and I was able to catch him red handed, now I am out and a lot happier credit goes to earlier mention hacker for a good job. If you are also interested in any hack job you can contact him via his email – HENRYCLARKETHICALHACKER@ GMAIL. COM
Tell him Victoria refer you
I think this is ok. They attempt to add a barrier here, with the attempt to increase the quality of the issue suggested. This may not be the only goal; one may be to have fewer issues raised in total. But there may be several advantages, as well as disadvantages with that approach - it is simply a trade-off.
In particular when I maintain an open source project, I have a lack of time in general so I need to move quickly. I actually don't mind issue discussions on my project, but people can not expect me to invest a lot of time into managing all of those; whether this is a discussion or an issue directly, is not so important, but I know that some project owners don't like open issues that remain open for years. It is kind of a difference in philosophy here.
One trade off is that I am not so likely to get involved in such a project. I may start a discussion, but in general I am very chaotic and may never follow up on discussions I started, simply due to lack of time, too many things to do, forgetting too much too (I do keep notes locally, but these files just keep on growing!).
> But there may be several advantages, as well as disadvantages with that approach - it is simply a trade-off.
Above, the word _simply_ conveys a lot of meaning. This sentence, when considered alone, might be seen to imply that all trade-offs are in a sense, ok, because they are all sort of a matter of taste. This doesn't mesh with my understanding of the world. I frame it this way: for a given objective, some trade-offs are better than others.
Put in reverse, when I see a project making certain trade-offs, I don't assume those trade-offs are in service of some clearly defined objective. Often I see people and organizations mired in trade-offs that are inertial and/or unconsidered.
There is another interesting angle to consider: framing as a question it would be: «When building a product or running a project, how do I make sense of a huge variety of trade-offs?» For that, exploring the Pareto frontier can be a useful method (see [1]) because it reduces the combinatorial explosion.
In the case of Ghostty, I think its values are indeed better served by this GitHub process (which designates an issue as a clear actionable task derived from a discussion).
[1]: https://en.wikipedia.org/wiki/Pareto_front
Great post. This should be the default configuration, community can make discussions, contributors can make issues.
> Great post. This should be the default configuration, community can make discussions, contributors can make issues.
I'm not so sure. I think this sort of discussion mostly falls within the realm of bike shedding. I'll explain why.
There's such a thing as a ticket life cycle. Ticketing flows typically feature a triage/reproduction stage. Just because someone creates an issue that doesn't necessarily mean the issue exists or isn't already tracked somewhere else, or that the ticket has all the necessary and sufficient information to troubleshoot an issue. When a ticket is created, the first step is to have someone look at it and check if there's something to it. This happens even when tickets are created by internal stakeholders, such as QAs.
GitHub supports ticket labels, and the default set already cover these scenarios.
https://docs.github.com/en/issues/using-labels-and-milestone...
To me this discussion sounds like a project decided to update their workflow to move triage out of tickets and into a separate board. That's fine, it's the exact same thing but with a slightly more complex process. But it's the same thing.
> Great post. This should be the default configuration, community can make discussions, contributors can make issues.
1. We often say 'should' too easily. The post isn't making such a claim is it? I would shift away from saying 'should' to saying: start somewhere that works for your project, gather feedback and evidence, and adjust thoughtfully. You'll end up in a place that feels authentic.
2. If anything, I would prefer the default be random. Then projects end up being natural experiments. See [1]
3. At a meta level, this reminds me of Brian:
> Brian: Look, you've got it all wrong! You don't need to follow me. You don't need to follow anybody! You've got to think for yourselves! You're all individuals!
> Crowd: Yes! We're all individuals!
> Brian: You're all different!
> Crowd: Yes, we are all different!
> Man in crowd: I'm not...
> Crowd: Shhh!
[1]: https://en.wikipedia.org/wiki/Natural_experiment
Not that not being able to open a ticket is not actually an implemented feature from GitHub; they simply added this issue template to let you know that you shouldn't open one:
*DO NOT OPEN A NEW ISSUE. PLEASE USE THE DISCUSSIONS SECTION.*
*I DIDN'T READ THE ABOVE LINE. PLEASE CLOSE THIS ISSUE.*
Reminds me of EggDrop (famous old IRC bot written in Tcl) with lots of "die" in the configuration file. :D
So they are using Issues as a project board to track and manage ongoing work items, but Projects is built for exactly that. May be better in the long term to move project management to Projects and let people file bugs with as little friction as possible.
Yet another great suggestion to consider! Thanks. Mind sharing some Github repos that use projects in this way?... that you think are good exemplars?
We've been doing this on the Renovate project for years, and it's been hugely useful - we get a lot of reports that users feel to be a bug, but are often misunderstanding or expectations about behaviour that isn't necessarily true.
There are absolutely bugs that get reported - either in functionality or documentation - but by requiring a level of triage in Discussions before promoting them up to Issues is a great way to keep things more actionable for folks wanting to come in and contribute fixes that the maintainers do agree are needing a fix
How about using issue types? https://docs.github.com/en/issues/tracking-your-work-with-is...
For those interested in social science research, there are many ways to explore this empirically. You could mix and match some of the following approaches:
1. Ask a high-quality LLM in research mode to gather empirical statistics on how different GitHub projects are setup.
2. Put human eyes on the data you find, look for patterns, see what is interesting. (I recommend reading on approaches that promote transparency about the order in which you collect data, form hypotheses, etc.)
3. Put on your anthropologist hat and do open-ended interviews with project maintainers.
And so on.
This makes perfect sense and is so much better than getting a flood of half-baked "issues" and then closing them automatically with a bot for "inactivity".
People complain about Github not allowing you to turn off issues and pull requests entirely, but I've always seen it as a positive. It means the truth about code quality, potential caveats, and better forked revisions can disseminate freely even when the author disappears. It becomes a spamfest at times, but is still probably a net positive for the ecosystem.
That being said, as long as you still have the discussion tab, auto-deleting all issues by default is not a big deal.
Is this fundamentally different than just using tags on issues to separate ready to work on things from initial user submissions?
I feel like "technically, no" but "practically, yes".
Somehow the distinction of just adding a tag / using filters doesn't communicate the cultural/process distinction in the same way.
Yes. Even for casual users looking for help, it’s nice to know that the “issues” tab is just real issues and not random, duplicated complaints and questions. Especially on a project like this that attracts a lot of attention and is highly sensitive to the user’s very specific environment. Most issues are going to not be bugs, or even something the maintainers can work on directly. Instead of trying to cram everything into Issues, why not use the underutilized Discussions tool? Now the Issues list is much more useful as an active tracker of workable items, and as a historical reference of relatively deduped problems.
One difference is that if I submit an issue, and it requires some back and forth to figure out the actionable improvement, then suddenly the issue is very noisy.
Whereas if it goes via a Discussion first, the back and forth happens elsewhere.
Arguably an separate issue could still do this, but it being a discussion sets the expectation better.
This kind of thing happens in Jira or any company's internal bug tracker, and GitHub Issues is not any different. If you want a certain kind of "hygiene", you can always do that in the existing system instead of inventing a whole different solution.
> Arguably an separate issue could still do this, but it being a discussion sets the expectation better.
People do that all the time in bug trackers.
As someone wearing the post-sales support hat for a non-OSS product, I appreciate use of "ready" tags in Jira. Unlike OSS, our engineers prioritize KPIs to be compensated for their work, and so we must find a way to track the triage discussions within Jira. In a significant way, Jira is solid proof that work happened, even if no actual code was pushed into the repo. If the support team has an unconfirmed bug that requires a technical deep dive, then the "non-ready" Jiras seem like a good fit. I'm open to a better way of doing this and would like to learn more about alternatives, but for now, this is how the teams engage.
It's a good idea to reserve issues for well-defined, actionable stuff.
IRL every dev issue tracker needs a front-end bozo filter to handle the low-hanging fruit and the misunderstandings and the failures to RTFM and the cases of PEBCAK.
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 earmarking and tracking the progress of actionable items. This is somewhat similar to the integration between email clients and task managers, like how it's done in Gmail, Zoho, etc. You read the message first. If it requires an action from your side, create a task from it and link them.
There are other projects that do this too. A good example is the 'mise' project. Sourcehut projects use this workflow almost exclusively since it's the default by design. I think sourcehut had if before github did. What I would like to see is better integration between discussions/messages and task/issue lists on all these platforms.
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.
> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features).
Do I ever make mistakes?
No. It’s the users who are wrong.
>> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features).
> Do I ever make mistakes?
> No. It’s the users who are wrong.
This is a textbook example of being uncharitable. Framing matters a lot! If you frame something in an uncharitable way, you are likely to "lock in" that view and discount other ones. Mitchell is not saying «users are wrong to give feedback», he is merely saying «the usual conventions are not ideal for this project». Don't confuse the two.
It is clear to me that Mitchell is giving his answer to this question: «what process gives the best results for this OSS project?». He has adjusted the feedback process in a way that he thinks will give better results. This is a consequentialist framing of how to best serve the users of Ghostty, which I think is a useful lens.
I disagree. He's just trying to educate these guys about usability.
Most people by default see "user got something wrong" and respond "rtfm" or "you don't understand" or "don't make mistakes".
The vast majority of people using Ghostty are not stupid. If they misunderstood something or made a mistake, it's highly likely that it could have been avoided with changes to improve Ghostty.
>>> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features).
>> Do I ever make mistakes?
>> No. It’s the users who are wrong.
> I disagree. He's just trying to educate these guys about usability.
I invite you to reconsider for these reasons: (1) Have you seen people "just trying to educate" in an uncharitable way? Many people have. Such cases of 'education' may involve paternalism and/or assuming the other person is ignorant. For example, both can manifest in the phenomenon of "mansplaining". There are more tells, also: (2) The commenter doesn't ask questions; (3) The commenter doesn't steel-man the other position; (4) The commenter uses a mocking tone. (To be fair, I've done such things in the past, but I'm striving to do much less of it.)
> The vast majority of people using Ghostty are not stupid.
No one is claiming this. Individual intelligence is not the same as «how people behave in system S compared to system S'». In other words, people do 'stupid' things all too often -- just hop in an automobile and watch our collective behavior.* Not to mention riots and mobs.
In the case of some issue tracking systems, "not-stupid" people can do things that are counter productive.
So, if project leaders have the ability, dedication, sincerity, rationale, and motivation to experiment with different systems, I say GO FOR IT. Experiment. Take a risk. Refusing to experiment is often worse.
Some people forget a key underlying principle of 'agility'† : start somewhere, gather feedback, be rational, experiment, and see where it takes you. If you see two different teams in different circumstances doing things the same way, you might take a closer look: one or both might have rigid processes that have stopped learning.
> If they misunderstood something or made a mistake, it's highly likely that it could have been avoided with changes to improve Ghostty.
Maybe, but that sounds like a tall claim. Remember that the Ghostty team _did in-fact_ make changes to their _process_ based on reflection.
I put much more confidence in the Ghostty team, who has shown signs of thoughtfulness, to make careful and wise decisions than someone with no skin in the game (a vast majority of the people here), especially uncharitable ones.
* I try not to 'blame' individuals or groups -- most human responses are statistically predictable and often even sensible and maybe even justifiable from a narrow point of view. If anything, I ascribe more importance to the design of roads, automobiles, and the cultural pressures we face.
† Too many forms of 'agility' forget the notion of recursive self-improvement. They instead get mired in ceremony.
Those modern terminal projects have weird defaults and quirky behaviors just to be different.
So to me it's easy to believe that a user expects something to work a certain way, does minimal or no research about it, and go directly to report a bug when in reality it's intented behavior.
I can believe this. I think it depends on the project, but there are certainly some with very high false positives. Maybe that's indicative of a confusing app, I don't know.
I think the main point is that all issues are ready for contributors to work on
2025-12-30 https://x.com/mitchellh/status/2006114026191769924
"Slop drives me crazy and it feels like 95+% of bug reports, but man, AI code analysis is getting really good. There are users out there reporting bugs that don't know ANYTHING about our stack, but are great AI drivers and producing some high quality issue reports.
This person (linked below) was experiencing Ghostty crashes and took it upon themselves to use AI to write a python script that can decode our crash files, match them up with our dsym files, and analyze the codebase for attempting to find the root cause, and extracted that into an Agent Skill.
They then came into Discord, warned us they don't know Zig at all, don't know macOS dev at all, don't know terminals at all, and that they used AI, but that they thought critically about the issues and believed they were real and asked if we'd accept them. I took a look at one, was impressed, and said send them all.
This fixed 4 real crashing cases that I was able to manually verify and write a fix for from someone who -- on paper -- had no fucking clue what they were talking about. And yet, they drove an AI with expert skill.
I want to call out that in addition to driving AI with expert skill, they navigated the terrain with expert skill as well. They didn't just toss slop up on our repo. They came to Discord as a human, reached out as a human, and talked to other humans about what they've done. They were careful and thoughtful about the process.
People like this give me hope for what is possible. But it really, really depends on high quality people like this. Most today -- to continue the analogy -- are unfortunately driving like a teenager who has only driven toy go-karts."
"Examples: https://github.com/ghostty-org/ghostty/discussions?discussio... "
Seems great to me. Perhaps GitHub should look into incorporating this into the UX somehow? So many projects are issues linking to other issues, I would love to see other projects adopt this to make github task tracking more usable.
Why would GitHub do that just because one project thinks is a good idea, especially when there is absolutely no concrete evidence that this is any more effective or efficient than using issues? All that we have is project maintainers' own beliefs. Bear in mind that these things can be studied and measured quantitatively.
The current "issues" system works fine for most small-medium projects and even many large projects. Any project who looks for a more "serious" solution would have its own Jira/bug tracker system, and you can find plenty of them.
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.
A lot of bugs where I work have the same pattern: one person writes up either what they found to be broken or what they couldn’t do due to a missing feature, then a shadow task is created that describes the bug and what needs to be changed to fix or implement it. I’ve never had problem with both the report and the work-tracker being in the same place but I can see why GitHub calling the product “Issues” might not have been a great name.
This attitude is why the project has toxic maintainers from Germany to China: https://xcancel.com/QULuseslignux/status/1918296149724692968
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!
Some of it may be unintentional. I've created issues directly through the `gh` CLI before, and issue templates don't show up there at all. If I haven't actually cloned the repo (or, more frequently, if I have a sparse checkout/deleted the files to save space), I have no way of knowing that there's a template and I'll just `gh issue -R some/thing create`.
I finally moved on to the official GitHub app on mobile, but before that I used fasthub and other clients that had no idea about issue templates.
GitHub really needs to add permissions to issues, so that users can't create issues without the template; any kind of failure in creation is a sign that you're doing something wrong. The ability to add tags to issues when creating via CLI would also be helpful.
We (Renovate) have an issue template (for maintainers/Triage-rights only) which has a label on it
Then GitHub Actions runs on new Issues and any that have that label get auto-closed
The idea is that folks with Triage+ can remove that label when creating an Issue, but not external contributors - might be worth giving that a go?
my fear is people are going to post issue reports, sometimes good ones that we need to act upon, they get autoclosed, and the submitter either never bothers to re-post or they are so annoyed that they don't re-post.
it would be way better if there was only one way for them to get their content in, in the first place
In our case, we've fortunately not found that's happened - we do end up looking at Issues that are closed in this way, and the majority of cases it's someone who's raised a Discussion and want to bypass the triage so create a new Issue from their comment
(I'm thinking of getting some data and words together to look at how this has helped us over the last ~18 months)
The motivation for that is very convincing, yet a quick glance at Issues tab makes me understand it without any additional explanation.
It looks great. As mentally easy to process as Jira tasks. Or even better, cause it was written by a good "PM", which is not always a case commercially.
Works for large projects with active communities (Ghostty has both). The filter pays off when volume is high. Doesn't work for smaller projects where every report matters and you want to lower barriers. The brutal honesty ("80-90% of you are wrong") is refreshing but may alienate contributors. A middle ground would be issue templates with mandatory checklists, filters without adding an extra step.
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.
What I often do on ZeroFS [0] is to convert issues to discussions, it's a one click operation on github and helps reduce the noise for ill-defined issues.
[0] https://github.com/Barre/ZeroFS
Just do the Apple / Google / MS model where anyone can freely open tickets, and then those bugs are never seen or addressed by any developers. Essentially use the bug tracker as a honeypot to keep the users happy
Maybe "issue" should then be renamed into "TODOs". Because end users have "issues" with a product, it is up for someone with more knowledge to identify if the "issue" is PEBKAC, WONTFIX, FEATURE, or actually a TODO for the developers.
The term "discussion" does not have anything to do with this.
I understand these are all github choices of terms, and it should also be reframed properly by github.
Last week a friend posted an issue to ghostty's github, and it got closed very fast - so he read this "Why users cannot create Issues directly", copied the post and pasted as discussion. Not much difference from my perspective.
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.
This approach is very efficient and keeps the riff raff out. I love it. Even in our internal Jira tickets, they tend to spiral into long discussions in the comments, only to end up becoming entirely new features or even change what the "bug" originally was to something new. I might try to introduce a similar idea now that I've read this. Thanks
“It’s not a bug it’s a feature!”
Just the first thing that popped into my head reading the reasoning. I think it makes a lot of sense to do it like this. Especially for a product which is cross platform that emulates / replaces other known products and on top has extensive configuration options. I also switched over from kitty a couple of weeks back and really like it.
I’m far from an AI booster but this sounds like a perfect job for an AI classifier to act as a gate keeper. If you can convince the AI that your bug report is sufficiently detailed to be actionable and issue gets created. Should reduce the low quality reports, crazy people and issue spam.
It's more or less what a customer of mine does with its support tickets. We receive the tickets, interact with customers, solve their problem and sometimes in the process we open one or more issues that enter into the backlog. Issues originated by a ticket usually have a high priority.
Hmm. I like it.
When I have a clear "Issue" which I've already researched, it's a bit of friction, but it doesn't seem like any more work to dump exactly the same text into a Discussion... and yea. Issues becoming a dumping ground is a real issue. This seems like a reasonable strategy / experiment.
This makes sense.
Personally, I use GH Issues for my own work, but there’s very few issues, so it’s not a burden. I’m a non-fan of JIRA.
I have seen GH Issues turn into Reddit-like flamefests (every now and then, someone posts a particularly entertaining one, here). Not my idea of productive work.
@jdx has gone one step further with mise. The issues has been completely disabled. I presume he tracks real issues in another repo. It'd be nice if github could provide first class support for such a workflow.
I briefly tried to contribute to a popular AI project (a ChatGPT-like web-based interface) where I found some bugs and reported them as issues, with steps to reproduce. The maintainer closed them and moved them to discussions, which is what he did to any issue he didn't like or personally didn't believe mattered, I guess. Items in Discussions didn't get any attention, nor were follow-ups looked at. One of the issues even involved the total loss of user data on upgrade.
So this makes me think the developer here just doesn't like the idea of issues being reported on his project.
Having maintained a relatively popular open source project for a bunch of years, I love this idea. Totally stealing this for future projects.
If only you could have project boards with their different views be the top level tabs instead of just open issues and pull requests...
Why not use labels for this? Discussions seem to be a bad use case for bug reports, but I can understand using it for feature request
> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves.
Who does this project actually serve? The "users", or someone else?
If I'm getting overwhelmed with hundreds of issues per week about some confusion around installation or use, I think those issues are completely justified. Something should probably be fixed if the happy path is this obscure. Pushing this reality into another bucket is not the solution for me.
As an OSS maintainer myself, while the amount of tickets about a specific topic _might_ be loosely related to the quality of the docs/installation/etc, this hasn't been true in my observations.
It's one of those explanations that sound very plausible on paper, but if you see real world issues it just doesn't happen, users will ask questions that are clearly explained in the first paragraph of the readme, en masse.
> clearly explained in the first paragraph of the readme
Yeah but people justifiably don't exhaustively read documentation. If people are getting confused because they didn't read some bit of documentation - even the first paragraph of the readme - then you shouldn't just dismiss them as stupid and bask in your superior documentation-reading abilities. You should think about how to resolve that confusion in a way that they would actually see it.
It's hard to explain how to do that without a concrete example, but it usually is possible. It's also usually more work than just replying RTFM, but you should at least be aware that you are choosing not to bother.
I'd rather OSS authors write and improve the software and documentation for most people than do the very time-consuming, burnout-inducing free customer support you are suggesting here (especially for those not bothering of reading even the first paragraph of the documentation).
It's not customer support; it's giving the product good usability. I would much rather they do that than waste time writing documentation that people won't read.
I think a concrete example would help here. Let me find one from this repo...
Ok after looking through about 20 discussions I was actually unable to find a single one that was a misunderstanding or misconfiguration on the user's part. They appear to all be real bugs (or feature requests), and very high quality ones at that.
So I think their assertion that 80-90% of what people think are bugs are actually not is total and utter bullshit.
That's kind of unrelated to what we were discussing though; misunderstandings due to poor usability do happen but I guess we can't easily find examples in Ghostty.
Let's not forget there are actual people behind open source projects. I think it is extremely rude to say those people should SERVE the users of their open source projects for free. The project "serve" the needs of the maintainers. If you as a user don't like something, that is entirely YOUR problem. Feel free to fork it and fix the bugs you think are worthy fixing.
It serves the open source maintainers, who enjoy working on it.
Did you also read the part about using Discussions instead? It’s not that users are not allowed to voice feedback, make request, or ask questions. They should just do so in a different place.
> Any Discussion which clearly identifies a problem in Ghostty and can be confirmed or reproduced will be converted to an Issue by a maintainer
I wonder if just tagging and filtering automatically via a GitHub setting which currently doesn’t exist could serve the same purpose
How is the technical block done? Just a bot closing issues or is there some github setting for this?
To me this just shows that the Github issue concept is significantly flowed.
Open source is weird. It’s like everyone on the entire planet is your coworker and you have no real say in their hiring, on boarding, or firing.
I can see why there is trepidation and guard rails around giving them the key to your office planner.
I don’t see how this demonstrates that at all. Issues as a concept seems sound. There is a huge variety of social structures that are built around issues which might make it a good or bad fit
Great approach. It can also prevent negative energy leak to passionate maintainers.
I have never worked on projects that give non members write access to our bug tracker.
This includes both our open source project not giving the public access. And our entirely closed source internal projects not giving other developers within the company write access.
This is ironically described in an open issue...
Ironic, yet practical. This is so that the issue can be 'pinned' to the top of the Issues page, making it more visible:
https://github.com/ghostty-org/ghostty/issues
I didn’t know GitHub had discussions. This is great
Shouldn't this be a discussion?
This is much better than the stale-bot bs irreversibly closing perfectly valid issues just because the reporter have not replied for couple weeks.
The stale-bots are even worse than that. The reporter may have responded quickly, and the bug may be acknowledged as real. But if there's simply no activity in the issue for the month following, it will be closed.
this project sure has a ton of open bugs
This is a good AI application - something which accepts user problem reports and tries to group them together. Maybe even reproducing the bug in a sandbox if the description is good enough. Engaging with the complainant to get more info.
This could be useful if not used for enshittification, where you have to get past the chatbot to reach anybody useful.
[dead]
(2014)
It's actually (2024)