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.

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.

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.

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.

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.

> 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, which typically ticketing flows 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. 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.

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

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?

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.

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.

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

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)

behold the best way to search github issues. Using Google or whatever decent search engine:

    site:https://github.com/org/repo key words

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.

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

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.

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.

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?

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.

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

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

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.

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.

Maybe you should become part of the project if you find bugs regularly ;-)

How is opening a discussion more friction than opening 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 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.

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

> 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

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.

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.

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.

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

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

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.

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.

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

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

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.

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.

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