Live data from Hacker News

“Please don't waste maintainers' time on your KPI grabbing patches”

lkml.org

201–210 of 277 posts

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#201
Got hit a while back with a GitHub account that was "bombing" OSS projects with Docker image "best practice" fixes related to Deb "recommends" or some other such stuff. Most of their history for the past year was exclusively opening these PRs with canned messages.

Some of the projects were very large(Apache Arrow, a large Google project IIRC), and they were opening commits up against largely test images.. And a LOT of them. On one of the larger projects somebody rightfully asked "What's the value add here?" who was promptly ignored by what I can only assume is a project manager who start humoring the submitter by trying to help them get this entirely useless work merged. It turned into an epic fail-whale causing all the projects tests to fail and that initial dev spent "too much time" trying to untangle it all before putting their foot down and reverted the changes.

Other project maintainers got wise to these fishy PRs and after inspecting the submitters history just started telling them to sod off.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#202

I see that these "cleanup" patches are not bringing much value, bust I also don't see why fixing spelling mistakes or log messages is considered as harmful, KPI boosting or not. The maintainer even said if someone else sent those patches it would be OK, but not if Huawei employees do it. If they distrust Huawei so much, why not just ban them from committing, the same way they did recently with university "security re…

I would agree with you. Those commits would be the easiest one to merge. How difficult is it to approve a typo correction? Saying a typo correction is not productive is actually the opposite: it takes very little time to review and approve. I don't know why people are mad that these commits are not from a student.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#203

Can someone explain this line to me please what you guys are doing is really KPI grabbing.

There's a movement away from evaluating people or teams qualitatively, which is difficult and prone to dumb biases, and towards quantitative measures, which are easy and prone to dumber biases.

Presumably here (I don't know if it's been proven) people in that org are being measured by how many commits they make, ignoring the depth or quality of the commits. Because it's someone's idea of a Key Performance Indicator (KPI.) So people are "grabbing" easy commits.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#204
post #42

Earlier quoted context omitted.

I think the proper way to do a “cleanup” patchset is to communicate with the maintainer beforehand and ask them what they’d prefer

Or as the maintainer themselves have indicated, bundling a number of these changes together along with a cover letter explaining them.

Would you rather spend 5 minutes to read a cover letter and code, or just read the diff see word_a has been changed to word_b in comments? Trivial typo or cosmetic changes should stay small, and can be approved in a few seconds.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#205
post #129
post #115

Earlier quoted context omitted.

Could someone ELI5 to me what KPI even stands for? Does that mean like they're like the shock troopers of open source?

KPI = Key Performance Indicator. It's basically a list of things that are considered during your evaluation. The more items off that check list you cross (if they're one-time items, like "ensure an uptime of X"), or the more of each you do (if they're things like "upstream patches" or "patents granted"), the better your score is. It's a shit system that does exactly the opposite of what it's supposed to do IMHO, but…

KPIs are actually very good when used properly, but they are (like many things) easily misused. For example if you provide a service then your obvious choice for the team's primary KPI would be service uptime.

Use SMART objectives (Specific, Measurable, Achievable, Relevant, Time-bounded) and set a realistic service uptime (e.g. how many nines you want in a given month/quarter/whatever) and KPIs directly enable good decisionmaking at all levels of the org.

Manager up in your grill about a choice you made? Point at the KPIs and say "this will help make it easier to meet our objectives for KPI 1.1" or whatever.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#206
post #138

Earlier quoted context omitted.

I think the email was completely effective in denouncing a behavior. Telling people to "fuck off" isn't required (nor desired, in my opinion). Linux health happened *despite* Linus' manners, not because of them.

It is naive to claim you can tell which part of Linus is and which isn't contributing to the success. For one, I think it might be possible Linus's no-nonsense attitude is for the better of the organization as people who can't work with it are leaving causing Linux developers, on average, to be more no-nonsense and also able to coexist better with other no-nonsense people. But, it is my conjecture only. We would neve…

It's possible to have a no-nonsense attitude without being offensive.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#207
post #138
post #135

Earlier quoted context omitted.

This is why ousting Linus puts the long-term health of the kernel at risk. It’s very difficult and expensive, at a personal and professional level, to tell colleagues to “fuck off” if they are submitting low quality garbage for reasons related to their salary. Linux was Linus’s baby, he had nearly absolute control, and he didn’t care too much about politeness - this was a magic recipe for him to be able to stave off…

I think the email was completely effective in denouncing a behavior. Telling people to "fuck off" isn't required (nor desired, in my opinion). Linux health happened *despite* Linus' manners, not because of them.

As others have pointed out, that's speculation.

I have trouble understanding why it bothers people so much that Linus is rude sometimes. You don't have to interact with him if you don't want. You can even contribute to the kernel without interacting with him. Whatever he's been doing has been working for going on 3 decades now, I don't see a burning need to change it because it bothers some outsiders.

There's this weird sense of entitlement. People want to elbow their way into this long-running and successful project and start telling everybody how they ought to behave. They think they have the right to contribute on their own terms without bothering to understand the project culture, and think it's everybody else's responsibility to make things easy for them and behave in a way they approve of.

If you really think the LKML is too toxic and hostile, to the detriment of the project, then feel free to fork it and start up a parallel project without the problems you see. Surely your friendly corporate-style culture will attract more contributors and soon you'll have the more successful kernel, right?

Personally, I like having somebody in charge of the core of the OS who's so concerned with correctness and hygiene that he gets upset when they're violated.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#208

The sense I got from the post was: "It's fine for noobs to cut their teeth on small issues, but as one of the largest tech companies, I'd expect more from your commits. It's obvious you're not even trying".

The point of the email is that the submitter is indeed trying, trying to improve their stats within their organization, at the expense of maintainers’ time, rather than working on the kernel in good faith.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#209
post #197

Earlier quoted context omitted.

The article that I linked goes into great detail about what the legal relationship between the employees and the union committee is, what level of control the union committee actually has over the shares, what happens if the company dissolves, and so on. Just saying that the union is a member of the national federation, and that the company is therefore owned by the Communist Party, is grossly inaccurate. The bottom…

"What’s the Deal with Huawei’s Ownership?" https://sayari.com/resources/huaweis-ownership-opaque-unusua... "Huawei claims to be owned entirely by its employees, but verifying this claim is a tricky proposition...However, comparing Huawei to other Chinese corporations reveals that Huawei’s ownership is highly unusual." .... "Using Chinese corporate data, we determined that Huawei’s ownership structure is very uncommon…

The article I linked to explains the origins of Huawei's ownership structure. It made sense when it was set up decades ago, though it's not the way that a company would be set up now. Yes, it may be unusual for a company this size to be set up this way, but there are very few companies of this size anyways. There does not appear to be anything nefarious about the use of the labor union committee as a vehicle for employee share ownership. It just appears to have been a reasonable way to set things up when Huawei was starting out.

Re: “Please don't waste maintainers' time on your KPI grabbing patches”

#210
post #138

Earlier quoted context omitted.

I think the email was completely effective in denouncing a behavior. Telling people to "fuck off" isn't required (nor desired, in my opinion). Linux health happened *despite* Linus' manners, not because of them.

You can watch a few conference talks where folks really go to town on Linus for his bad behavior. On GPLv3 lots of calls for Linus to stop supporting GPLv2 "How do we get you to stop..." https://www.youtube.com/watch?v=PaKIZ7gJlRU And the list goes on and on. That said, his decisions seem to have worked out amazingly well. At some point I can imagine getting tired at having to repeatedly defend your views.

>his decisions seem to have worked out amazingly well.

As someone who regularly deals with bugs and inconsistencies in Linux, I wouldn't say so. For me personally, I just want to be able to fix the issues, and would rather not spend the time bickering with someone who has some kind of personal vendetta about something that I don't know about. I try hard not to dump my baggage on other open source maintainers, I hope others can do the same.

Post reply on HN