That's a shame to hear. I had to give up on Ghostty because of its memory leak issue. Granted, it was on an 8GB system, but that should be enough to run a terminal without memory exhaustion a few times a week. Foot has been rock solid, even though it lacks some of Ghostty's niceties.
btw, is it me or is there any justification for anyone including a developer to run more than 8GB of RAM for a laptop? I don't see functionality as having changed in the last 15 years.
For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.
I agree with the general philosophy about user submissions. Browsing closed discussions looks a lot like browsing closed issues. So I'm not sure that the policy is successfully turning bug reports into discussions. But it's at least keeping Issues free from noise for contributors. Github could do more to nudge users into approaching Discussions differently. https://github.com/ghostty-org/ghostty/discussions?discussio...
The point is the opposite, AFAICT. Any user complaint starts as a discussion. If an actionable bug report results from it, it goes to the tracker, which serves as list of problems to work on. A lot of discussions do not end this way, even though they may solve a user's issue anyway, e.g. by providing advice and reference.
Definitely discussing things could also happen in the issue tracker, and some <Actionable> tag could be used to mark issues that are ready to work upon. But I suspect that Discussions are better suited for, well, discussions, while the facilities of the issue tracker can then be used by maintainers / contributors.
Agreed. IMO, it makes sense to have a way to triage possible issues, confirm that they are, in fact, legitimate, and then create issue records to reflect them. As long as users have a way to report anomalous behavior, then, as you say, it’s really no different than using tags on issues. Po-tay-to, po-tah-to.
As a maintainers, if you want to be be able to tell real issues from non-issue discussions, you still gave to read them (triage). That's what's taking time.
I don't see how transforming a discussion into an issue is less effort than the other way around. Both are a click.
Github's issues and discussions seem the same feature to me (almost identical UI with different naming).
The only potential benefit I can see is that discussions have a top-level upvote count.
> able to tell real issues from non-issue discussions
imo almost all issues are real, including "non-issue" - i think you mean non-bug - "discussions." for example it is meaningful that discussions show a potential documentation feature, and products like "a terminal" are complete when their features are authored and also fully documented or discoverable (so intuitive as to not require documentation).
99% of the audience of github projects are other developers, not non-programmer end users. it is almost always wrong to think of issues as not real, every open source maintainer who gets hung up on wanting a category of issues narrower than the ones needed to make their product succeed winds up delegating their product development to a team of professionals and loses control (for an example that I know well: ComfyUI).
If discussions had a more modern UI with threads or something then the difference might be real. But AFAICT it’s the same set of functionality, so it’s effectively equivalent to a tag.
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
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.
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.
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.[...]"""
but has not graduated to issue worthy status
For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.
Your second link looks like an X user trying to start a flamewar; the rest of the replies are hidden to me.
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.
How is this not trivially solved via a "ready-to-be-worked-on" tag?
If you spend more time closing issues than creating them manually from discussions, the math adds up.
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.
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).
The math is even better if you just ignore all issues and close them after two weeks for being stale!
Wish this was /s but it isn't.
"""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.[...]"""