I agree with the general philosophy about user submissions. Browsing closed discussions looks a lot like browsing closed issues. So I'm not sure that the policy is successfully turning bug reports into discussions. But it's at least keeping Issues free from noise for contributors. Github could do more to nudge users into approaching Discussions differently. https://github.com/ghostty-org/ghostty/discussions?discussio...
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.
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.
Personally, I dig it! Selected parts from linked page:
"""Unlike some other projects, Ghostty does not use the issue tracker for discussion or feature requests. Instead, we use GitHub discussions for that. Once a discussion reaches a point where a well-understood, actionable item is identified, it is moved to the issue tracker. This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on.
This approach is based on years of experience maintaining open source projects and observing that 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves.[...]"""
I agree with the general philosophy about user submissions. Browsing closed discussions looks a lot like browsing closed issues. So I'm not sure that the policy is successfully turning bug reports into discussions. But it's at least keeping Issues free from noise for contributors. Github could do more to nudge users into approaching Discussions differently. https://github.com/ghostty-org/ghostty/discussions?discussio...
For example, memory leak investigation is currently spread across discussions, x/twitter and discord https://x.com/mitchellh/status/2004938171038277708 https://x.com/alxfazio/status/2004841392645050601 https://github.com/ghostty-org/ghostty/discussions/10114 https://github.com/ghostty-org/ghostty/discussions/9962
but has not graduated to issue worthy status
That's a shame to hear. I had to give up on Ghostty because of its memory leak issue. Granted, it was on an 8GB system, but that should be enough to run a terminal without memory exhaustion a few times a week. Foot has been rock solid, even though it lacks some of Ghostty's niceties.
> 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?
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.
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.
Personally, I dig it! Selected parts from linked page:
"""Unlike some other projects, Ghostty does not use the issue tracker for discussion or feature requests. Instead, we use GitHub discussions for that. Once a discussion reaches a point where a well-understood, actionable item is identified, it is moved to the issue tracker. This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on.
This approach is based on years of experience maintaining open source projects and observing that 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves.[...]"""
Kind of an unstructured Basecamp ShapeUp where the "ask" has been shaped already through requirements gathering and bets made.
I proposed something similar for bitcoin: https://gnusha.org/pi/bitcoindev/CABaSBax-meEsC2013zKYJnC3ph...