111–120 of 320 posts
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.
[flagged]
Who does this project actually serve? The "users", or someone else?
If I'm getting overwhelmed with hundreds of issues per week about some confusion around installation or use, I think those issues are completely justified. Something should probably be fixed if the happy path is this obscure. Pushing this reality into another bucket is not the solution for me.
> This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on. How is this not trivially solved via a "ready-to-be-worked-on" tag?
For one, it might require several rounds of back and forth before its ready to receive the tag, but now the details are spread across several comments instead of neatly at the top
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.
[flagged]
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.
> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. Who does this project actually serve? The "users", or someone else? If I'm getting overwhelmed with hundreds of issues per week about some confusion around installation or use, I think those issues are completely justified. Something should probably be fixed if the happy path is…
It's one of those explanations that sound very plausible on paper, but if you see real world issues it just doesn't happen, users will ask questions that are clearly explained in the first paragraph of the readme, en masse.
> 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. Who does this project actually serve? The "users", or someone else? If I'm getting overwhelmed with hundreds of issues per week about some confusion around installation or use, I think those issues are completely justified. Something should probably be fixed if the happy path is…
> Any Discussion which clearly identifies a problem in Ghostty and can be confirmed or reproduced will be converted to an Issue by a maintainer
Earlier quoted context omitted.
[flagged]
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.
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.
Earlier quoted context omitted.
That's a shame to hear. I had to give up on Ghostty because of its memory leak issue. Granted, it was on an 8GB system, but that should be enough to run a terminal without memory exhaustion a few times a week. Foot has been rock solid, even though it lacks some of Ghostty's niceties.
btw, is it me or is there any justification for anyone including a developer to run more than 8GB of RAM for a laptop? I don't see functionality as having changed in the last 15 years. For me, only Rust compilation necessitates more RAM. But, I assume devs just do RAM heavy dev work on a server over ssh.