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.

But, I am super lazy.

▲

Etheryte 14 hours ago | parent | next [-]

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.

▲

johnfn 3 hours ago | parent | next [-]

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!

▲

Mawr 13 hours ago | parent | prev | next [-]

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.

	▲	Etheryte 12 hours ago \| parent \| next [-]
		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.
	▲	ncruces 12 hours ago \| parent \| prev \| next [-]
		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.
	▲	skywhopper 11 hours ago \| parent \| prev [-]
		How is “submit your issue to this nearly identical discussion tool in the same web app” a burden?

▲

IshKebab 6 hours ago | parent | prev [-]

> No one is forcing you to use any of these projects

Unless you only ever work on projects that you have full absolute control over (unlikely if you have a job) then yes they absolutely are.

▲

foxygen an hour ago | parent | prev | next [-]

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.

▲

arendtio 12 hours ago | parent | prev | next [-]

Maybe you should become part of the project if you find bugs regularly ;-)

▲

gertop 15 hours ago | parent | prev | next [-]

To be fair it also stinks of arrogance to think that you have the skills to know "what is clearly a bug" 100% of the time in projects you don't own.

	▲	Const-me 14 hours ago \| parent \| next [-]
		> to know "what is clearly a bug" 100% of the time in projects you don't own Owning a project is counter-productive for QA. If it’s your project, you know where to click and where to not click. OTOH, you don’t need to know anything about a project to conclude that a crash with access violation, or hang with 100% CPU usage, are clearly bugs.
	▲	RobotToaster 12 hours ago \| parent \| prev \| next [-]
		>90% of the time it's usually pretty clear if something is a bug, especially if there's log files full of errors.
	▲	pbhjpbhj 12 hours ago \| parent \| prev [-]
		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.

▲

layer8 10 hours ago | parent | prev | next [-]

How is opening a discussion more friction than opening an issue?

	▲	lijok 8 hours ago \| parent [-]
		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.

▲

skywhopper 11 hours ago | parent | prev | next [-]

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.

	▲	lijok 10 hours ago \| parent [-]
		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.

▲

burnt-resistor 13 hours ago | parent | prev [-]

Your feedback is very important to us. Please fill out this long ass form and provide mountains of telemetry as barriers to participation.