Comment by eduction

I can believe this. I think it depends on the project, but there are certainly some with very high false positives. Maybe that's indicative of a confusing app, I don't know.

I think the main point is that all issues are ready for contributors to work on

>> 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.

Those modern terminal projects have weird defaults and quirky behaviors just to be different.

So to me it's easy to believe that a user expects something to work a certain way, does minimal or no research about it, and go directly to report a bug when in reality it's intented behavior.