Comment by shevy-java
13 hours 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!).
> 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