Live data from Hacker News

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

lkml.org

261–270 of 277 posts

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

#261
post #12

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

Sounds like he is saying. Huawei is doing a lot of trivial cleanups to be able to say like they are a major contributor. Basically the argument is: - trivial patches are ok, if you are just doing it for practice. Like a student. - trivial patches are not ok, if you are doing a lot of them and only for the purpose to get a higher contribution ranking (like commits per company)

I don't think Qu says that Huawei isn't a major contributor.

See:

> > My contributions to the kernel in the past have mainly been on optimizing the performance of the ARM64 SMMU driver, > > including the iova optimization, strict mode optimization, and the lazy mode optimization. Also working on the > > development of some ARM SoC drivers.

> You indeed have done solid contribution to the kernel in the past, thus > better could have been done.

Also:

> Even without checking the git log, I can easily think of some big > contributions from your employer, like EROFS and F2FS. > Thus I don't have any doubt about that.

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

#262

Earlier quoted context omitted.

> The issue is that creating objective measure of contribution value is just unfeasible if at all possible. Could you give an example of a non trivial patch which value would be unfeasible to assess objectively? I am not familiar enough with the maintenance process to understand how hard it is to measure objectively the quality of a patch.

It is not about any single patch, you can't assess value of any patch objectively. For starters there isn't even an objectively established definition of value . You can't objectively measure something that only has subjective definitions. In a free market you could say that the price could be proxy for the value (ie how much somebody can pay for it should at least theoretically correspond to its value for that perso…

> For starters there isn't even an objectively established definition of value.

That's doesn't mean that one cannot come up with a definition . I believe that for a long time there wasn't a proper definition for energy.

> You can't objectively measure something that only has subjective definitions.

But it's your claim that it can only be subjective. Somehow you don't seem able to demonstrate it, nor even show an example of a patch - or a patch set - for which no meaningful objective quality measurement could be done.

Anyway, this might very well be a red herring: it doesn't matter if it's objective or not, as long as those involved agree with it. Apparently, the current measure is this KPI thing (which by the way, is very objective, since it doesn't involve the judgement of anyone), and this mail we're discussing seems to indicate its inadequacy (because it doesn't measure the right thing).

Now, whether having such measure is a good thing or not is of course a different matter, and perhaps it should be discussed first.

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

#264
post #194
post #31

Hi Leizhen, and guys in the mail list, Recently I find one patch removing a debug OOM error message from btrfs selftest. It's nothing special, some small cleanup work from some kernel newbie. But the mail address makes me cautious, "@huawei.com". The last time we got some similar patches from the same company, doing something harmless "cleanup". But those "fixes" are also useless. This makes me wonder, what is really…

Can you please not copy the entire OP like that? It's confusing, obscures your specific point, and leads other commenters to reply to random things in the OP, which is fine of course, but that's what the thread is for in the first place. We detached this comment from https://news.ycombinator.com/item?id=27630257 .

Well the reply was to a comment that didn't seem to have read the link so I felt it was apt but alright.

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

#265

Earlier quoted context omitted.

Actually I'm being silly, there is a good solution: Workplace Democracy. You can fool the higher ups come promotion time, but you can't fool all the people all the time. Mondragon please get in the tech biz.

Could you please show some real-world examples of this practice?

I am familiar with tech co-ops, but they are small, and so not good evidence.

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

#266
post #248

Earlier quoted context omitted.

Actually I'm being silly, there is a good solution: Workplace Democracy. You can fool the higher ups come promotion time, but you can't fool all the people all the time. Mondragon please get in the tech biz.

Didn't Donal Trump fool a lot of people in a democracy? And how does this have anything to do with metrics?

When there are just a few decision makers, a standard evaluation procedure is usually necessary for fairness / reproducibility.

When there as many evaluators as evaluatees, no standard evaluation procedure is needed on the theory that all the different ways and biases will cancel out. That doesn't work over time, as clearly America's electorate gets interested in different things, but I am less worried about that for co-ops.

The hope for co-ops vs state democracy is two fold.

Firstly, because people do work many hours at their job, but don't necessarily spend any time running the state, I hope they are more informed and engaged.

Secondly, the "both options are bad, I hate this" problem should be addressed by A, proportional representation (just like should be done with state democracy states), but also B of switching jobs. The barrier of switching jobs is much lower than immigrating, which ought to more than any thing else reign in defeatist apathy. And Co-ops can still fire people, remember.

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

#267
post #240

Earlier quoted context omitted.

This is trite. Just about any way of understanding something is going to create perverse incentives. Keeping the metrics secret has other problems too. I don't think there is a a good solution. Maybe with radically shortened work hours and less pay disparity, the strives can strive off the job instead.

Um, what? The degree to which a metric is directly tied to incentives absolutely impacts how much that metric will be gamed. It is not trite at all to caution that metrics that are critical to understanding your business should remain as decoupled as possible from incentives. This allows you to maintain the quality of the signals your metrics provide. This isn't just theory. This is precisely why there are laws that…

So tell me this: how is the degree to which a given metric is tied to incentives meant to be varied?

> This is precisely why there are laws that prohibit rewarding people based on how they voted.

Voting is not an evaluation method of the voter: the voter is the one doing the evaluating. Because the powers should not discriminate between voters as you say, the vote cannot be used to evaluate the voters on and individual basis at all.

Maybe the answer is that: no individual/team assessments of any sort. That makes no incentives. But that also doesn't help with fine-grained strategy.

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

#268
post #241

Earlier quoted context omitted.

It means that Linus used to be fairly brusk when he was younger (basis: e.g. flipping people off and telling people to "fuck off"), and recently he has apologized for his behavior (basis: the link you shared). To me this is him mellowing out in his old age. His younger self might not have agreed with this mellowing out, seeing it as unnecessary (basis: his responses previous to the apology to other people who called…

> To me ... My question remains: What is the basis of that? Do you work with him? Read his biography at least (assuming there is one)?

The basis is the sentence before that one.

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

#269
post #147

Earlier quoted context omitted.

Can we measure "impact" of changes? PKI measuring just commit count is pretty silly. Like SLOC. Cite folklore.org story of -10,000 lines added. Whereas Qu's suggestions are useful, important. Am totally ignorant about Linux, kernel, etc. But maybe there's already a leaderboard where the hivemind helps prioritize work.

A measure of the ratio of patch effort to review effort (as subjectively judged by the reviewer, perhaps to the nearest order of magnitude) might be informative.

Belated reply. Sorry. I really like this notion. But I can't imagine what it'd look like. Please post anything you come up with. Thanks.

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

#270
post #268

Earlier quoted context omitted.

> To me ... My question remains: What is the basis of that? Do you work with him? Read his biography at least (assuming there is one)?

The basis is the sentence before that one.

I guess it's just Internet speculation. I am looking for something with a real basis (not that you are required to give it to me).
Post reply on HN