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

171–180 of 245 posts

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

#171

Post by khalladay »

bluedino wrote: post #142
klelatti wrote: post #82

Earlier quoted context omitted.

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

This is a weird stance to take. Software development is not sports. There is no "game day," and the best teams I've worked on have managed to treat folks with respect while still maintaining a high degree of quality.

You can treat people kindly without having to agree with their opinions, or taking their PRs. If you are already going to reply or interact with them, it costs the same to be kind as it does to be a jerk.

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

#172

Post by Macha »

the_gipsy wrote: post #165
antihero wrote: post #51

Ha, trying to get Alacritty to have a native-feel icon for macOS which had basically zero drawbacks and most other applications do was met with a straight up NOPE. Not up for debate, people supplied the assets and I even made a PR, nope, closed. Even though it was in a directory full of platform specific stuff (Alacritty.app resources), it was decided that it couldn't differ from the other icons, so Alacritty has to…

How many other non-apple apps “stick out like a sore thumb”?

On my dock:

Finder, Slack: Squircle

Chrome, VS Code: Logo in a white squircle

Alacritty, IntelliJ, Firefox, Obsidian: Unusual shaped logos

VPN: Circle

Webex: Squircle, but scaled wrong (different border radius and aspect ratio)

So only about half are squircles, and one of them is not the OS X squircle.

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

#174

Post by jszymborski »

jpe90 wrote: post #90

"The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects. Just because someone open sources something does not imply they owe the world a change in their status, focus and effort, e.g. from inventor to community manager. As a user of something open source you are not thereby entitled to anything at all. You are…

I don't think F.Brennan (OP) is making any demands here. He's simply commenting on a pattern of forsaking the good for the perfect in a lot of repositories that, in his opinion, cause them to stagnate.

I see no expectations, or demands in this post. Only disappointment at what OP sees as a missed opportunity.

OP is a pretty prolific contributor to open-source, and I get that ones purview doesn't extend past ones owns projects, but it certainly affords perspective. I hardly think any of the comments in this post are anything OP or any project maintainer should take personally or as undue pressure. It's simply well-trodden commentary [0].

[0] https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

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

#175

Post by asimpletune »

klelatti wrote: post #124
OJFord wrote: post #113

Earlier quoted context omitted.

The previous sentence was: > The barrier to entry isn't mailing lists, or Torvalds, or perfectionism or gatekeeping. i.e. the context is reviewing (however that's done) contributed code.

Well they could have said 'Most PRs are bug ridden garbage' - stronger than I would use but fair enough. But no, it's a comment on the characteristics of people contributing to projects. It's saying that they are not capable of making a quality contribution.

> It's saying that they are not capable of making a quality contribution.

But isn't that true? At least not right away, which is why the code gets reviewed. I'm pretty sure everyone writes bug ridden garbage, unless they're not already intimately familiar with the codebase already.

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

#176

Post by entropicdrifter »

klelatti wrote: post #124
OJFord wrote: post #113

Earlier quoted context omitted.

The previous sentence was: > The barrier to entry isn't mailing lists, or Torvalds, or perfectionism or gatekeeping. i.e. the context is reviewing (however that's done) contributed code.

Well they could have said 'Most PRs are bug ridden garbage' - stronger than I would use but fair enough. But no, it's a comment on the characteristics of people contributing to projects. It's saying that they are not capable of making a quality contribution.

It's saying they are not capable of making a quality contribution without criticism/review.

Your reply here is some serious pedantry, you're essentially arguing that the output of most programmers is totally disconnected from the abilities of most programmers.

Really, what other relevant external indicators of the abilities of a given programmer does anyone have access to besides the code they output?

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

#177

Post by zozbot234 »

DannyBee wrote: post #164
zozbot234 wrote: post #151

Earlier quoted context omitted.

"Accepting" a pull request means merging it, and broken code should not be merged. By all means feel free to propose improvements to the PR, then merge it. And if achieving a reasonably well-defined standard of correctness (i.e. avoiding complete and utter breakage) is not feasible, the PR should be scaled back until it becomes so. Start with the minimum useful change, then expand on it.

Broken is a very loaded word. So i don't agree with this as written. If by broken you mean "does not compile or pass tests", then fine, sure. If by broken you mean "there are likely some hard issues in there", then no, i don't agree. I've watched plenty of really good software where the dev process amounts to: 1. Integrate code that is more experimental into the development trunk 2. Let people discover what is wrong…

> 1. Integrate code that is more experimental into the development trunk

> 2. Let people discover what is wrong with it

> 3. Fix and iterate it

This kind of experimentation can be done on a separate branch. There's no need to involve whoever maintains the "main" development branch until the code is reasonably OK for release.

In some cases, it can be acceptable to merge code that's clearly marked as experimental into the main trunk if it's a totally separate feature that can be ensured to not affect normal use of the project. You can see this, e.g. with "nightly" Rust features, which are opt-in and clearly separate from the "stable" language. But this is not very feasible in something like a terminal emulator, for obvious reasons.

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

#178

Post by he_is_legend »

ghusbands wrote: post #131
xyzzy_plugh wrote: post #88

Earlier quoted context omitted.

I didn't give that feedback to a contributor. I didn't encourage maintainers to insult contributors. If you don't know what you're doing and you don't know that you don't know what you're doing, then yes it's likely what you produce will be both bug ridden and garbage. It takes time and patience to refine it into something good. It doesn't mean you shouldn't try. If you , or anyone else -- colleague, stranger, whatev…

Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind, which will be visible in other ways and will turn some people away. It can help your outlook on the world and your impact on others to make an effort to think less negatively.

Sometimes honesty and truth can hurt. Sometimes you have to accept that and move on. Alternatively you can coddle people so that they think every thing that they do is wonderful and a gift to all of mankind. Or you can take offence at honest criticism everything and ... well here we are. Word policing, and overbearing nicety as form of karma currency are not good things. Adults sometimes call each other not nice names. The world is not a cosy blanket left in the sun covered with kittens.

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

#179

Post by DannyBee »

andkon wrote: post #144
DannyBee wrote: post #134

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, " 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 l…

I used to write it in a blog a long time ago, but that website died and i'm just too busy these days ;)

Ironically, my experience overall as a manager (not just in open source) is that when you ask this question, a lot of the time you get the answer that nobody did anything, because of the latter thing you describe.

IE nobody is acting malicious, but they expected people would want to do X on their own, so nobody tried anything specifically.

In those cases, once you get people onto the path of specifically trying things, and seeing what happens, it's often a great improvement. Even without lots of other process/measurement.

Beyond that, one of the things we do internally, that is a bit harder to do well externally due to social norms/etc, is ask people. In open source, it's trickier because if i contribute randomly to 200 projects, i don't want every single one of them spamming me directly to find out more about my experiences ;)

But occasionally poking people on PR's that are taking a while, or went really well, etc, and seeing if the people they are willing to fill out a form anonymously or something, even if heavily biased, would at least give you some notions of what is going well or not for people.

There is also a lot to be said for analytics on PRs, but again, open source is not very advanced at this right now, so i don't think it's near as viable yet as just asking some people

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

#180

Post by Veen »

jeroenhd wrote: post #141
Veen wrote: post #59

Earlier quoted context omitted.

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…

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

I strongly agree with you. I know gatekeeping has negative connotations and has become a sort of generalized boo word in some circles. But I'm glad maintainers act as gate keepers. Some code is crap and some coders aren't very good. Or, at least, their abilities don't match their ambitions. Someone has to keep low-quality work out of open source projects, and it's not a job I would want.

Nevertheless, quis custodiet ipsos custodes? The real problem with gate-keeping is when the gate-keepers aren't accountable. Criticism is one of the ways we can keep them accountable.

It's the same many areas. I want engineering schools and guilds to gate-keep so bridges don't fall down when I'm driving across them. I want news and book editors to gate-keep so I don't have to wade through acres of dross to find worthwhile content. And I want maintainers to gate-keep so open source software works when I need it.

Post reply on HN