Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

gist.github.com

Post reply on HN
Print view View original

141–150 of 245 posts

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#141

Post by jeroenhd »

Veen wrote: post #59
rtfeldman wrote: post #28

Posts like this are major contributors to maintainer burnout. Whatever value they have as a signal boost is a rounding error compared to the harm they cause to individuals as well as to the culture as a whole. Please don't ever post things like this. If you're this frustrated that the people who make free things for you aren't donating their time to you in the way you'd prefer, grab a drink with a friend and vent to…

The world does not owe maintainers protection from negative feedback. They are not high priests of open source whose behaviour is above criticism because they "make free things". It sucks to be criticized, even as politely as in the gist, but it's part of being an adult operating alongside other adults in a complex domain where disagreement is inevitable.

I agree, but only partially. Anyone doing anything in public opens themselves to criticism, but the criticism has to be well-intentioned and valid.

In this case, requirements about code quality and even refusal of code likely to introduce bugs is being called "gatekeeping" which is complete nonsense.

If you refuse a merge request for good reason, you don't deserve to get shit on by some salty contributor who doesn't want to bring their PR up to your standards. This article seems to indicate that any PR intended to be helpful must be merged, whatever the cost in maintenance, because otherwise you're gatekeeping.

If you refuse a PR for bad reasons ("I don't accept contributions from Chile because I had a bad holiday there once" and more racist/sexist variants thereof) then you definitely deserve criticism. What's happening here isn't really criticism, though, it's childish ranting about other people not putting in enough free work for the author and how that is somehow damaging to the volunteers, disguised behind polite words.

I think the world owes maintainers no protection from real, useful negative feedback, but a lot of negative feedback is just people being angry that they don't get their way. In a civil internet, that kind of behaviour has no place being called "criticism" and being assumed to just be par for the course of open source.

I've decided I never want to be an open source maintainer exactly because of the entitled people who write these articles, and I don't think I'm the only one being pushed away from open source for this reason.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#142

Post by bluedino »

klelatti wrote: post #82
xyzzy_plugh wrote: post #70

Earlier quoted context omitted.

I don't think this is an unfair generalization. You need at least one of the three: patience, skill, experience. I am not sure who would argue with that. If you lack skill and experience, it's no problem. But if you begin to get frustrated as soon as you receive feedback... you're going to have a bad time. I've seen some truly impressive contributions over the years and the common element that stands out isn't the au…

> bug ridden garbage > expect to be treated kindly Do you see why the first might make someone doubt the second?

It's a harsh reality. The best team can't be welcoming to sub-par players. At least not on game day.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#144

Post by andkon »

DannyBee wrote: post #134
Etheryte wrote: post #77

Earlier quoted context omitted.

As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception, and from the offset it's often not so straightforward to figure out which one you're dealing with. It isn't constructive to think of a contribution as a gift, if anything, it's a Greek gift [0]: contributing to an open source project creates more work for the m…

"As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception, " I've contributed to hundreds of projects, and maintained a ton, so i feel this pain, so please take what i say in that vein :) The question i usually ask when i see this is: "What is the thing you did that you think should have caused people's behavior to ch…

Wowwww this is lovely! Have you written anywhere about what you've done on the projects you've maintained along these lines? I think we'd all benefit from hearing more about what you can do in a project to make contributors more capable and helpful.

After all, it seems like their incentives should align? Like, why wouldn't they want to make a contribution that actually helps? Making that easier to actually do seems like time well spent for everyone.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#146

Post by bluedino »

xyzzy_plugh wrote: post #70
klelatti wrote: post #63

Earlier quoted context omitted.

> The fact is that most programmers do not have the patience, skill or experience to write half-decent code that isn't bug-ridden garbage. Whether or not you are right on this issue is this really the way to generalise about current / potential contributors? Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? Edit: I’m making no point about quality or otherwise of cont…

I don't think this is an unfair generalization. You need at least one of the three: patience, skill, experience. I am not sure who would argue with that. If you lack skill and experience, it's no problem. But if you begin to get frustrated as soon as you receive feedback... you're going to have a bad time. I've seen some truly impressive contributions over the years and the common element that stands out isn't the au…

> You need at least one of the three: patience, skill, experience.

I had a boss who was a self-admitted terrible programmer. I witnessed some of the worst practices ever while working there.

His quote was, "don't underestimate a persistent idiot (programmer) with a lot of time on his hands. He'll get it 'almost right', eventually"

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#147

Post by purple_turtle »

DannyBee wrote: post #140
xyzzy_plugh wrote: post #39

> So, here we are in 2020, and nix#864 remains unmerged. Fred, you say, you overreact. I read the entire PR. I _want_ to agree with the author, but I didn't find this reasonable. The feedback, for the most part, was not about being perfectionism. Not remotely. It's about being correct . This is not unique to Rust, which as a language spends a lot of time being correct in a few dimensions, but pretty traditional. You…

Speaking as a historically pedantic person, correctness is often a form of perfectionism. Just gussied up. Unless you have a verifiable system all the way down, you will always have bugs, crashed, and race conditions. Going all the way to 11 on trying to make it correct usually results in negligible improvement in correctness for a lot more time spent. Depends on the system of course. This is a terminal emulator, not…

Is it a valid reason to ignore known and found problems?

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#148

Post by purple_turtle »

ReleaseCandidat wrote: post #96
xyzzy_plugh wrote: post #39

> So, here we are in 2020, and nix#864 remains unmerged. Fred, you say, you overreact. I read the entire PR. I _want_ to agree with the author, but I didn't find this reasonable. The feedback, for the most part, was not about being perfectionism. Not remotely. It's about being correct . This is not unique to Rust, which as a language spends a lot of time being correct in a few dimensions, but pretty traditional. You…

> Take a look on LKML, or Git's mailing list, or on any serious project from the last 20 years. Yes. But we are talking about a terminal emulator. And not even about one bundled with a DE (or OS). This _should_ be exactly the type of project where people can get their first OSS programming experience.

> This _should_ be exactly the type of project where people can get their first OSS programming experience.

It is 100% up to maintainer of a given project, they are not obligated to do this.

People are 100% free to pursue sky-high reliability and bugfreeness in their project, no matter what it is.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#150

Post by purple_turtle »

ReleaseCandidat wrote: post #101
coldtea wrote: post #98

Earlier quoted context omitted.

Isn't that up to the maintainer? A maintainer might not want anybody else working on the code with them even. FOSS license != community project.

Yes of course, that's their decision. What I'm talking about that you can't expect the same contributors to a critical part of infrastructure as to a, well, more or less useless terminal emulator. You can't do the 45327th copy of something (yes, yes, I get it, it's in Rust) and behave like your project is the Linux kernel or the Rust compiler.

> behave like your project is the Linux kernel or the Rust compiler

Yes, misleading claims about project importance would be a bad idea.

But decisions like

> This _should_ be exactly the type of project where people can get their first OSS programming

is up to maintainers, not up to random people not running this projects

Post reply on HN