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.
Arrogance? Those people are spending their time and effort on an open source project, without asking a penny in return. I think they are entitled to have restrictions on how bugs should be reported.
In the python projects in question, unlike with the Ghostty project, there isn't an "issue triage" discussion category that maintainers look at. They have just discussions, and everything is treated as such. So when you raise an issue in discussions, it either goes to the void or people come in looking for a discussion of alternative approaches to do what you're trying to do that don't hit the bug, rather than treating the bug as a bug.
At a high level - the audience of discussions is the community at large, the audience of issues is the maintainers.
What Ghostty is doing with a dedicated category for issue triage should work just fine, despite it being an additional hop.
I always struggle to understand this level of entitlement. No one is forcing you to use any of these projects. The vast majority of the time, drive-by bug reports by users are a complete waste of time because they're either a user error or not described in sufficient detail to debug. In other words, mostly noise, and adding more noise isn't really helpful.
If you want to contribute, a much better way is to work on bugs that are already well defined. There is generally no shortage of known bugs in software, there is however a shortage of people fixing them.
There's zero entitlement expressed by the parent, he's just trying to help the project, but is encountering unnecessary friction.
It's not that he has some inner urge to contribute in some way, he just encountered a bug while using the software and wants to report it. The alternative isn't coding — it's no contribution at all.
I think this is exactly the point most people miss. No contribution is better than bad contribution. Most issues people file are bad. I previously worked at a major OSS company and the vast majority of bug reports are just noise. It takes time to sift through them and they add no value, just waste time. If people did less of that, that would be a good outcome, not a bad one. Sure, there's useful reports there sometimes, but it's more rare than you'd think. On top of that, many of those are dupes of issues we've already found and filed, just haven't had time to fix yet.
Maintainers did a bunch of useful work for them and they refuse to report issues the way maintainers find the most useful, because it's a burden to help maintainers do all their free work.
This is like being forced to pay 50 bucks to your apartment because someone else broke the door. Then when you complain about it people tell you you’re entitled!
But it’s not your apartment (project/repo), it’s someone else’s. If it were yours, the rules wouldn’t apply.
You can clone the other person’s apartment for free and do whatever you like, though. Just don’t barge in to someone else’s apartment and demand they treat you, a stranger, like if it were yours.
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.
The arrogance in in users like yourself who think they know better than the project owners how to run their issue tracker. This is just a variation. It’s not a barrier, it’s an attempt to improve the quality of the issues that are filed in a way that’s more useful for everyone.
To be clear, I am not telling Mitchell how to run his project. I am providing info on how a change like this can be perceived from the other side. Do with the information what you will.
But, I am super lazy.