I have worked in team with some kernel developers at Samsung, years ago, so let me put some perspective for those who do not understand the dynamics. In some companies, the amount of patents or Linux kernel patches you get accepted is direct measure of your success. As you know, whatever you measure becomes a target -- these guys feel very pressed to get ANY kernel commits accepted, no matter how small, irrelevant or…
Could someone ELI5 to me what KPI even stands for? Does that mean like they're like the shock troopers of open source?
“Please don't waste maintainers' time on your KPI grabbing patches”
121–130 of 277 posts
Re: “Please don't waste maintainers' time on your KPI grabbing patches”
#122Earlier quoted context omitted.
>> 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. My best guess: It creates a small amount of work for a maintainer to review and merge. This is worthwhile if a new contributor is learning their way around, and getting new contributors is very important to an OSS project. To have a large…
It's true that it creates an overhead for maintainers. But, on the other hand, maybe Linux process needs to be improved to relief the maintainers from having to review every single patch. Linux as a project is big enough, and if maintainers are the bottleneck, maybe it's time to have sub-maintainers to whom such tasks could be delegated.
I think insisting on quality is way more reasonable.
Re: “Please don't waste maintainers' time on your KPI grabbing patches”
#123I have worked in team with some kernel developers at Samsung, years ago, so let me put some perspective for those who do not understand the dynamics. In some companies, the amount of patents or Linux kernel patches you get accepted is direct measure of your success. As you know, whatever you measure becomes a target -- these guys feel very pressed to get ANY kernel commits accepted, no matter how small, irrelevant or…
Could someone ELI5 to me what KPI even stands for? Does that mean like they're like the shock troopers of open source?
Engineer's performance is measured, in part, by number of kernel commits. So, the number of kernel commits is a key performance indicator for the developer.
Re: “Please don't waste maintainers' time on your KPI grabbing patches”
#124Earlier quoted context omitted.
Doesn't work. "When a measure becomes a target, it ceases to be a good measure." You can totally build something that is a decent metric, but as soon as you create incentives to "game it" (optimize for the metric not the actual goal you're trying to measure), it will be gamed, and creating metrics that are resistant to that is nearly impossible in most cases.
Edit: Nvm, I misunderstood the initial problem and my solution doesn't address it. Why not just keep commits as a metric, then estimate the quality of those commits by sampling. If the organization appears to be gaming the stats then flag it as such.
Re: “Please don't waste maintainers' time on your KPI grabbing patches”
#125I have worked in team with some kernel developers at Samsung, years ago, so let me put some perspective for those who do not understand the dynamics. In some companies, the amount of patents or Linux kernel patches you get accepted is direct measure of your success. As you know, whatever you measure becomes a target -- these guys feel very pressed to get ANY kernel commits accepted, no matter how small, irrelevant or…
Could someone ELI5 to me what KPI even stands for? Does that mean like they're like the shock troopers of open source?
As such exactly what it is, will depend on company/industry/market/team/project/etc. It may be revenue or units sold or widgets made or turnover or customer satisfaction or days without accident etc. In principle, it communicates to teams what is important to business and helps everybody focus and sync.... with usual real-world caveats and implementation risks.
I imagine here, for a large-company linux team, a "KPI" was "how many commits you made" - they measure it, they track it, and reward/recognize/punish team members based on it. So people start working toward increasing the KPI in any feasible way - if you only want me to increase the KPI of commits done, OK, fine, I'll do some commits.
Re: “Please don't waste maintainers' time on your KPI grabbing patches”
#126I have worked in team with some kernel developers at Samsung, years ago, so let me put some perspective for those who do not understand the dynamics. In some companies, the amount of patents or Linux kernel patches you get accepted is direct measure of your success. As you know, whatever you measure becomes a target -- these guys feel very pressed to get ANY kernel commits accepted, no matter how small, irrelevant or…
Re: “Please don't waste maintainers' time on your KPI grabbing patches”
#127Without any context it looks like someone overreacted. It's essentially saying anybody else than Huawei sending cleanup patches is welcome but Huawei is not. Then they try to backtrack that statement by putting out a long list of things which aren't comparable in complexity to the original topic. Without more context I bet this thread is going to go off-topic.
>>It's essentially saying anybody else than Huawei sending cleanup patches is welcome but Huawei is not.
? I don't think you can because the article does not say that.
Re: “Please don't waste maintainers' time on your KPI grabbing patches”
#128I have worked in team with some kernel developers at Samsung, years ago, so let me put some perspective for those who do not understand the dynamics. In some companies, the amount of patents or Linux kernel patches you get accepted is direct measure of your success. As you know, whatever you measure becomes a target -- these guys feel very pressed to get ANY kernel commits accepted, no matter how small, irrelevant or…
Maybe a panel of maintainers could publish a quarterly review with attribution/thanks to the most important contributors. No metrics to game, only pure human expert opinions.
Re: “Please don't waste maintainers' time on your KPI grabbing patches”
#129I have worked in team with some kernel developers at Samsung, years ago, so let me put some perspective for those who do not understand the dynamics. In some companies, the amount of patents or Linux kernel patches you get accepted is direct measure of your success. As you know, whatever you measure becomes a target -- these guys feel very pressed to get ANY kernel commits accepted, no matter how small, irrelevant or…
Could someone ELI5 to me what KPI even stands for? Does that mean like they're like the shock troopers of open source?
It's a shit system that does exactly the opposite of what it's supposed to do IMHO, but that kind of stuff doesn't belong in an ELI5 explanation :-D.
Re: “Please don't waste maintainers' time on your KPI grabbing patches”
#130The fellow who is being named in this particular PR has been _quite_ busy lately, submitting mostly typo fixes and whitespace fixes: https://lore.kernel.org/lkml/?q=f%3Athunder.leizhen Sometimes their patches aren't even valid - they tried to fix "borken" to "broken" and the maintainer was not happy: https://lore.kernel.org/lkml/YK3wOkX6I78j73zD@gmail.com/ (this does come down to not being familiar with this particul…
Here is this person's commit history for the last year for additional context: https://public-001.gitsense.com/insights/github/repos?q=auth... They do appear to contribute regularly enough (relatively speaking) and based on some of the busfactor metrics, they are the sole maintainer or main maintainers for about 50 files. And if you look at their one line change commits, they do seem to be valid: https://public-001.g…
By construction, yes. You're only looking at their commits that were merged into Linus's tree.