This is ironically described in an open issue...
Why users cannot create Issues directly
171–180 of 320 posts
Re: Why users cannot create Issues directly
#172This is ironically described in an open issue...
Ironic, yet practical. This is so that the issue can be 'pinned' to the top of the Issues page, making it more visible:
Re: Why users cannot create Issues directly
#173Earlier quoted context omitted.
> Most bug trackers have ways to triage submissions. When a rando submits something, it has status "unconfirmed". Developers can then recategorize it, delete it, mark it as invalid, confirm that it's a real bug and mark it "confirmed", etc. As far as I'm aware, most large open GitHub projects use tags for that kind of classification. Would you consider that too clunky?
This still puts the onus on the developers to categorise the issues which I'm guessing they don't want to do.
Isn't that basically what Ghostty is doing also?
Re: Why users cannot create Issues directly
#174Earlier quoted context omitted.
It is weird to push the idea that Facebook is some kind of pinacle of good and easy to use UI. That's the first one. It's quite the opposite, with people constantly complaining how bad, clunky and confusing Facebook is. And it is not the recent trend either. It has always been this way and e.g. VK has always had a better UI/UX that Facebook (and Telegram's is better that Whatsapp's).
facebook literally obfuscates their UI to stop you turning off "features" they want to push on you it is a UI designed to be hard to use
You're talking about two different things here (and I'm not condoning either, to be clear.)
1) UI = a clearly documented way to configure all features and make the software work exactly how you want.
2) UI = load a web page and try to do the thing you wanted to do (in this case communicate with some specific people).
FB is clearly terrible at 1 but pretty alright at 2.
Re: Why users cannot create Issues directly
#175Earlier quoted context omitted.
I wonder if a good public flogging would compel chrome and web devs to have 80 tabs take up far less than a gigabyte of memory like they should in a world where optimization wasn’t wholesale abandoned under the assumption that hardware improvements would compensate for their laziness and incompetence.
The high memory usage is due to the optimization. Responsiveness, robustness and performance was improved by making each tab independent processes. And that's good. Nobody needs 80 tabs, that's what bookmarks are for.
"that's what bookmarks are for"
And if you are lucky, the content will still be there the next time.
Re: Why users cannot create Issues directly
#176> 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.
>> 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.
Re: Why users cannot create Issues directly
#177I 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 quick…
> 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).
Re: Why users cannot create Issues directly
#178Great post. This should be the default configuration, community can make discussions, contributors can make issues.
Re: Why users cannot create Issues directly
#179This is much better than the stale-bot bs irreversibly closing perfectly valid issues just because the reporter have not replied for couple weeks.
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.
Re: Why users cannot create Issues directly
#180For 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
Seems like the contributors don't feel like it's clear enough yet to make an actionable issue and needs more discussion. Are you a contributor?