17 ms·

Why users cannot create Issues directly

773 points by xpe 10mo ago

RockieYang 10mo ago
Great approach. It can also prevent negative energy leak to passionate maintainers.
xpe 10mo ago
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.[...]"""
- CharlieDigital 10mo ago
  Kind of an unstructured Basecamp ShapeUp where the "ask" has been shaped already through requirements gathering and bets made.
- kanzure 10mo ago
  I proposed something similar for bitcoin: https://gnusha.org/pi/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com/#t https://gnusha.org/pi/bitcoindev/CABaSBax-meEsC2013zKYJnC3ph...
keyle 10mo ago
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.
- sammy2255 10mo ago
  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 https://github.com/curl/curl/issues
  - mi_lk 10mo ago
    Not sure curl is a good example since it’s already very mature and boring (in a good way)
- nh2 10mo ago
  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.
  - oofbey 10mo ago
    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.
    - just-ok 10mo ago
      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.
  - doctorpangloss 10mo ago
    > 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).
Maxious 10mo ago
For example, memory leak investigation is currently spread across discussions, x/twitter and discord https://x.com/mitchellh/status/2004938171038277708 https://x.com/mitchellh/status/2004938171038277708 https://x.com/alxfazio/status/2004841392645050601 https://x.com/alxfazio/status/2004841392645050601 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/9962 https://github.com/ghostty-org/ghostty/discussions/9962 but has not graduated to issue worthy status
- quantummagic 10mo ago
  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.
  - mi_lk 10mo ago
    I’m sure they would appreciate a report as it doesn’t seem that it can be reproduced yet
  - favflam 10mo ago
    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.
    - tynorf 10mo ago
      Chrome on my work laptop sits around 20-30GB all day every day.
      - typeofhuman 10mo ago
        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.
literatepeople 10mo ago
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.
- g947o 10mo ago
  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.
1123581321 10mo ago
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?discussions_q=is:closed+ https://github.com/ghostty-org/ghostty/discussions?discussio...
- nine_k 10mo ago
  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.
  - drob518 10mo ago
    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.
  - 1123581321 10mo ago
    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.
eviks 10mo ago
> 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?
- voxl 10mo ago
  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?
  - eviks 10mo ago
    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?
    - em-bee 10mo ago
      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.
    - orangeisthe 10mo ago
      > Why break the expected/established workflow of users Is it really that hard to open a discussion?
- 8n4vidtmkvmk 10mo ago
  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
  - eviks 10mo ago
    No, you can always summarize details neatly at the top, you can edit comments, you know?
cortesoft 10mo ago
Is this fundamentally different than just using tags on issues to separate ready to work on things from initial user submissions?
- jonahx 10mo ago
  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.
- sleekest 10mo ago
  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.
  - g947o 10mo ago
    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.
    - evanjrowley 10mo ago
      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.
rbbydotdev 10mo ago
I wonder if just tagging and filtering automatically via a GitHub setting which currently doesn’t exist could serve the same purpose
paxys 10mo ago
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.
- xpe 10mo ago
  Yet another great suggestion to consider! Thanks. Mind sharing some Github repos that use projects in this way?... that you think are good exemplars?
lawgimenez 10mo ago
How about using issue types? https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-types-in-an-organization https://docs.github.com/en/issues/tracking-your-work-with-is...
- xpe 10mo ago
  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.
ok123456 10mo ago
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.
- nutjob2 10mo ago
  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.
  - shevy-java 10mo ago
    [flagged]
- NewJazz 10mo ago
  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.
  - mitchellh 10mo ago
    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)
- cik 10mo ago
Groxx 10mo ago
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.
gizmo686 10mo ago
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.
eduction 10mo ago
> 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.
- 8n4vidtmkvmk 10mo ago
  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.
- gertop 10mo ago
  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.
- anttiharju 10mo ago
  I think the main point is that all issues are ready for contributors to work on
- xpe 10mo ago
  >> 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.
purpleidea 10mo ago
How is the technical block done? Just a bot closing issues or is there some github setting for this?
otterley 10mo ago
(2014)
- jamietanna 10mo ago
  It's actually (2024)
pella 10mo ago
2025-12-30 https://x.com/mitchellh/status/2006114026191769924 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?discussions_q=is%3Aclosed+crash+author%3A0xBigBoss https://github.com/ghostty-org/ghostty/discussions?discussio... "
Animats 10mo ago
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.
shevy-java 10mo ago
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!).
- xpe 10mo ago
  > 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 https://en.wikipedia.org/wiki/Pareto_front
bsnnkv 10mo ago
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/workflows/feature-check.yaml https://github.com/LGUG2Z/komorebi/blob/master/.github/workf...
- rarkins 10mo ago
  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!
lijok 10mo ago
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.
- arendtio 10mo ago
  Maybe you should become part of the project if you find bugs regularly ;-)
- gertop 10mo ago
  [flagged]
  - Const-me 10mo ago
    > 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.
  - RobotToaster 10mo ago
    >90% of the time it's usually pretty clear if something is a bug, especially if there's log files full of errors.
  - pbhjpbhj 10mo ago
    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.
- Etheryte 10mo ago
gorgoiler 10mo ago
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.
firesteelrain 10mo ago
I didn’t know GitHub had discussions. This is great
BrenBarn 10mo ago
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.
larusso 10mo ago
“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.
cjk 10mo ago
Having maintained a relatively popular open source project for a bunch of years, I love this idea. Totally stealing this for future projects.
deleted 10mo ago
[deleted]
goku12 10mo ago
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.
- OmarShehata 10mo ago
  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
  - goku12 10mo ago
    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.
burnt-resistor 10mo ago
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.
bob1029 10mo ago
> 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.
- franciscop 10mo ago
  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.
  - IshKebab 10mo ago
    > 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.
    - franciscop 10mo ago
      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).
snudan 10mo ago
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
Eikon 10mo ago
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 https://github.com/Barre/ZeroFS
euroderf 10mo ago
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.
ChrisMarshallNY 10mo ago
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.
WhyNotHugo 10mo ago
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.
- spinningarrow 10mo ago
  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)
  - layer8 10mo ago
    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.
- xixixao 10mo ago
  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.
- arccy 10mo ago
  behold the best way to search github issues. Using Google or whatever decent search engine: site:https://github.com/org/repo key words
  - botanical76 10mo ago
creatonez 10mo ago
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.
arccy 10mo ago
If only you could have project boards with their different views be the top level tabs instead of just open issues and pull requests...
harvie 10mo ago
This is much better than the stale-bot bs irreversibly closing perfectly valid issues just because the reporter have not replied for couple weeks.
- cpburns2009 10mo ago
  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.
nikanj 10mo ago
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
konhi 10mo ago
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.
jwr 10mo ago
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".
tarkin2 10mo ago
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.
Levitating 10mo ago
This is ironically described in an open issue...
- ColinEberhardt 10mo ago
  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 https://github.com/ghostty-org/ghostty/issues
timcobb 10mo ago
Great post. This should be the default configuration, community can make discussions, contributors can make issues.
- xpe 10mo ago
  > 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 https://en.wikipedia.org/wiki/Natural_experiment
- locknitpicker 10mo ago
  > 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-milestones-to-track-work/managing-labels 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.
jamietanna 10mo ago
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
- jamietanna 9mo ago
  I've written some more about why we've settled on this: https://www.jvt.me/posts/2026/01/07/renovate-why-discussions/ https://www.jvt.me/posts/2026/01/07/renovate-why-discussions...
robertclaus 10mo ago
Shouldn't this be a discussion?
deleted 10mo ago
[deleted]
djoldman 10mo ago
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.
zzzeek 10mo ago
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!
- jamietanna 10mo ago
  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?
  - zzzeek 10mo ago
    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
    - jamietanna 10mo ago
      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)
- efreak 10mo ago
  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.
T3RMINATED 10mo ago
[dead]
figmert 10mo ago
@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.
kreco 10mo ago
To me this just shows that the Github issue concept is significantly flowed.
- klysm 10mo ago
  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
- deleted 10mo ago
  [deleted]
- ikawe 10mo ago
  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.
lacoolj 10mo ago
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
sigmonsays 10mo ago
this project sure has a ton of open bugs
halyconWays 10mo ago
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.
garfieldnate 10mo ago
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.*
- johnisgood 10mo ago
  Reminds me of EggDrop (famous old IRC bot written in Tcl) with lots of "die" in the configuration file. :D
pmontra 10mo ago
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.
bflesch 10mo ago
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.
padjo 10mo ago
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.
gverrilla 9mo ago
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.
andreyandrade 9mo ago
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.
RustSupremacist 9mo ago
This attitude is why the project has toxic maintainers from Germany to China: https://xcancel.com/QULuseslignux/status/1918296149724692968 https://xcancel.com/QULuseslignux/status/1918296149724692968
Stancyhd8 9mo ago
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

773 points by xpe 10mo ago

Great approach. It can also prevent negative energy leak to passionate maintainers.

xpe 10mo ago

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

CharlieDigital 10mo ago
Kind of an unstructured Basecamp ShapeUp where the "ask" has been shaped already through requirements gathering and bets made.
kanzure 10mo ago
I proposed something similar for bitcoin: https://gnusha.org/pi/bitcoindev/CABaSBax-meEsC2013zKYJnC3phFFB_W3cHQLroUJcPDZKsjB8w@mail.gmail.com/#t https://gnusha.org/pi/bitcoindev/CABaSBax-meEsC2013zKYJnC3ph...

keyle 10mo ago

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.

sammy2255 10mo ago
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 https://github.com/curl/curl/issues
- mi_lk 10mo ago
  Not sure curl is a good example since it’s already very mature and boring (in a good way)
nh2 10mo ago
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.
- oofbey 10mo ago
  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.
  - just-ok 10mo ago
    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.
- doctorpangloss 10mo ago
  > 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).

Maxious 10mo ago

For example, memory leak investigation is currently spread across discussions, x/twitter and discord https://x.com/mitchellh/status/2004938171038277708 https://x.com/mitchellh/status/2004938171038277708 https://x.com/alxfazio/status/2004841392645050601 https://x.com/alxfazio/status/2004841392645050601 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/9962 https://github.com/ghostty-org/ghostty/discussions/9962 but has not graduated to issue worthy status

quantummagic 10mo ago
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.
- mi_lk 10mo ago
  I’m sure they would appreciate a report as it doesn’t seem that it can be reproduced yet
- favflam 10mo ago
  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.
  - tynorf 10mo ago
    Chrome on my work laptop sits around 20-30GB all day every day.
    - typeofhuman 10mo ago
      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.

literatepeople 10mo ago

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.

g947o 10mo ago
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.

1123581321 10mo ago

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?discussions_q=is:closed+ https://github.com/ghostty-org/ghostty/discussions?discussio...

nine_k 10mo ago
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.
- drob518 10mo ago
  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.
- 1123581321 10mo ago
  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.

eviks 10mo ago

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

voxl 10mo ago
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?
- eviks 10mo ago
  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?
  - em-bee 10mo ago
    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.
  - orangeisthe 10mo ago
    > Why break the expected/established workflow of users Is it really that hard to open a discussion?
8n4vidtmkvmk 10mo ago
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
- eviks 10mo ago
  No, you can always summarize details neatly at the top, you can edit comments, you know?

cortesoft 10mo ago

Is this fundamentally different than just using tags on issues to separate ready to work on things from initial user submissions?

jonahx 10mo ago
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.
sleekest 10mo ago
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.
- g947o 10mo ago
  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.
  - evanjrowley 10mo ago
    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.

rbbydotdev 10mo ago

I wonder if just tagging and filtering automatically via a GitHub setting which currently doesn’t exist could serve the same purpose

paxys 10mo ago

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.

xpe 10mo ago
Yet another great suggestion to consider! Thanks. Mind sharing some Github repos that use projects in this way?... that you think are good exemplars?

lawgimenez 10mo ago

How about using issue types? https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-types-in-an-organization https://docs.github.com/en/issues/tracking-your-work-with-is...

xpe 10mo ago
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.

ok123456 10mo ago

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.

nutjob2 10mo ago
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.
- shevy-java 10mo ago
  [flagged]
NewJazz 10mo ago
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.
- mitchellh 10mo ago
  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)
cik 10mo ago

Groxx 10mo ago

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.

gizmo686 10mo ago

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.

eduction 10mo ago

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

8n4vidtmkvmk 10mo ago
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.
gertop 10mo ago
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.
anttiharju 10mo ago
I think the main point is that all issues are ready for contributors to work on
xpe 10mo ago
>> 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.

purpleidea 10mo ago

How is the technical block done? Just a bot closing issues or is there some github setting for this?

otterley 10mo ago

(2014)

jamietanna 10mo ago
It's actually (2024)

pella 10mo ago

2025-12-30 https://x.com/mitchellh/status/2006114026191769924 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?discussions_q=is%3Aclosed+crash+author%3A0xBigBoss https://github.com/ghostty-org/ghostty/discussions?discussio... "

Animats 10mo ago

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.

shevy-java 10mo ago

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

xpe 10mo ago
> 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 https://en.wikipedia.org/wiki/Pareto_front

bsnnkv 10mo ago

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/workflows/feature-check.yaml https://github.com/LGUG2Z/komorebi/blob/master/.github/workf...

rarkins 10mo ago
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!

lijok 10mo ago

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.

arendtio 10mo ago
Maybe you should become part of the project if you find bugs regularly ;-)
gertop 10mo ago
[flagged]
- Const-me 10mo ago
  > 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.
- RobotToaster 10mo ago
  >90% of the time it's usually pretty clear if something is a bug, especially if there's log files full of errors.
- pbhjpbhj 10mo ago
  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.
Etheryte 10mo ago

gorgoiler 10mo ago

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.

firesteelrain 10mo ago

I didn’t know GitHub had discussions. This is great

BrenBarn 10mo ago

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.

larusso 10mo ago

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

cjk 10mo ago

Having maintained a relatively popular open source project for a bunch of years, I love this idea. Totally stealing this for future projects.

deleted 10mo ago

[deleted]

goku12 10mo ago

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.

OmarShehata 10mo ago
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
- goku12 10mo ago
  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.

burnt-resistor 10mo ago

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.

bob1029 10mo ago

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

franciscop 10mo ago
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.
- IshKebab 10mo ago
  > 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.
  - franciscop 10mo ago
    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).

snudan 10mo ago

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

Eikon 10mo ago

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 https://github.com/Barre/ZeroFS

euroderf 10mo ago

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.

ChrisMarshallNY 10mo ago

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.

WhyNotHugo 10mo ago

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.

spinningarrow 10mo ago
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)
- layer8 10mo ago
  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.
xixixao 10mo ago
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.
arccy 10mo ago
behold the best way to search github issues. Using Google or whatever decent search engine: site:https://github.com/org/repo key words
- botanical76 10mo ago

creatonez 10mo ago

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.

arccy 10mo ago

If only you could have project boards with their different views be the top level tabs instead of just open issues and pull requests...

harvie 10mo ago

This is much better than the stale-bot bs irreversibly closing perfectly valid issues just because the reporter have not replied for couple weeks.

cpburns2009 10mo ago
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.

nikanj 10mo ago

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

konhi 10mo ago

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.

jwr 10mo ago

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

tarkin2 10mo ago

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.

Levitating 10mo ago

This is ironically described in an open issue...

ColinEberhardt 10mo ago
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 https://github.com/ghostty-org/ghostty/issues

timcobb 10mo ago

Great post. This should be the default configuration, community can make discussions, contributors can make issues.

xpe 10mo ago
> 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 https://en.wikipedia.org/wiki/Natural_experiment
locknitpicker 10mo ago
> 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-milestones-to-track-work/managing-labels 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.

jamietanna 10mo ago

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

jamietanna 9mo ago
I've written some more about why we've settled on this: https://www.jvt.me/posts/2026/01/07/renovate-why-discussions/ https://www.jvt.me/posts/2026/01/07/renovate-why-discussions...

robertclaus 10mo ago

Shouldn't this be a discussion?

deleted 10mo ago

[deleted]

djoldman 10mo ago

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.

zzzeek 10mo ago

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!

jamietanna 10mo ago
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?
- zzzeek 10mo ago
  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
  - jamietanna 10mo ago
    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)
efreak 10mo ago
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.

T3RMINATED 10mo ago

[dead]

figmert 10mo ago

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

kreco 10mo ago

To me this just shows that the Github issue concept is significantly flowed.

klysm 10mo ago
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
deleted 10mo ago
[deleted]
ikawe 10mo ago
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.

lacoolj 10mo ago

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

sigmonsays 10mo ago

this project sure has a ton of open bugs

halyconWays 10mo ago

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.

garfieldnate 10mo ago

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

johnisgood 10mo ago
Reminds me of EggDrop (famous old IRC bot written in Tcl) with lots of "die" in the configuration file. :D

pmontra 10mo ago

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.

bflesch 10mo ago

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.

padjo 10mo ago

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.

gverrilla 9mo ago

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.

andreyandrade 9mo ago

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.

RustSupremacist 9mo ago

This attitude is why the project has toxic maintainers from Germany to China: https://xcancel.com/QULuseslignux/status/1918296149724692968 https://xcancel.com/QULuseslignux/status/1918296149724692968

Stancyhd8 9mo ago

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