From: Glauber Costa <glommer@parallels.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
Jonathan Corbet <corbet@lwn.net>,
<ksummit-2012-discuss@lists.linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-2012-discuss] [ATTEND or not ATTEND] That's the question!
Date: Fri, 6 Jul 2012 13:59:04 +0400 [thread overview]
Message-ID: <4FF6B6E8.7080306@parallels.com> (raw)
In-Reply-To: <20120706095450.GB7728@somewhere.redhat.com>
>>
>> Resurrecting this one.
>>
>> So something just came across my mind: When I first read this thread, my
>> inner reaction was: "People will find ways to bypass and ill-optimize
>> their workflow for whatever measure we come up with".
>>
>> That's is pure human nature. Whenever we set up a metric, that becomes a
>> goal and a bunch of people - not all - will deviate from their expected
>> workflow to maximize that number. This happens with paper count in the
>> scientific community, for the Higgs Boson's sake! Why wouldn't it happen
>> with *any* metric we set for ourselves?
>>
>> So per-se, the fact that we have a lot of people trying to find out what
>> our metrics are, and look good in the face of it, is just a testament to
>> the success of Linux - but we know that already.
>>
>> The summary here, is that I don't think patch count *per se* is a bad
>> metric. Maybe we should just tweak the way we measure a bit to steer
>> people towards doing more useful work, and that would aid our review.
>>
>> The same way we have checkpatch, we can have something automated that
>> will attempt to rule out some trivial patches in the counting process.
>> We can scan a patch, and easily determine if each part of it is:
>>
>> * pure whitespace
>> * pure Documentation change
>> * comment fix
>>
>> And if a patch is 100 % comprised by those, we simply don't count it.
>> People that just want to increase their numbers - they will always
>> exist, will tend to stop doing that. Simply because doing it will not
>> help them at all.
>
> OTOH, documentation changes or comment fixes, and even sometimes pure whitespace
> fixes, can be very valuable contributions. This can be a useful and ungrateful
> work and that deserve credit.
>
> We just can't find an automated and right way to evaluate a contribution.
>
I am not saying or implying that they are not. I am merely pointing out
that metrics are good and healthy for us, but all of them will have
their perks, and a group of people will optimize for that.
I doubt that we'll stop having Documentation patches, for instances, if
we stop counting them. People who understand the value of it, will still
do it. They will just stop doing it for the sake of doing it, and even
worse, divided in a thousand patches what could easily be sent in just one.
Furthermore, I believe to be undeniable that even though those
contributions are indeed, valuable, they are not by any means as
valuable as the "real work", as Thomas describes.
next prev parent reply other threads:[~2012-07-06 10:01 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-15 22:56 [ATTEND or not ATTEND] That's the question! Thomas Gleixner
2012-06-15 23:34 ` [Ksummit-2012-discuss] " Greg KH
2012-06-16 10:50 ` Thomas Gleixner
2012-06-16 13:29 ` Jonathan Corbet
2012-06-16 13:32 ` Frederic Weisbecker
2012-06-16 13:56 ` Rafael J. Wysocki
2012-06-17 10:40 ` Thomas Gleixner
2012-06-17 18:51 ` Greg KH
2012-06-17 18:58 ` Mark Brown
2012-06-20 19:51 ` J. Bruce Fields
2012-07-06 9:43 ` Glauber Costa
2012-07-06 9:54 ` Frederic Weisbecker
2012-07-06 9:59 ` Glauber Costa [this message]
2012-07-06 10:00 ` Srivatsa S. Bhat
2012-07-06 10:03 ` Glauber Costa
2012-07-06 10:21 ` Srivatsa S. Bhat
2012-07-06 10:11 ` Richard Cochran
2012-07-06 10:14 ` Glauber Costa
2012-07-06 10:36 ` Srivatsa S. Bhat
2012-07-06 10:43 ` Glauber Costa
2012-07-06 12:42 ` Steven Rostedt
2012-07-17 22:17 ` david
2012-06-16 11:30 ` Alan Cox
2012-06-16 15:03 ` Phil Turmel
2012-06-16 16:43 ` Myklebust, Trond
2012-06-20 0:40 ` Dave Chinner
2012-06-17 17:04 ` Mark Brown
2012-06-19 15:45 ` Bjorn Helgaas
2012-06-19 19:18 ` Roland Dreier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FF6B6E8.7080306@parallels.com \
--to=glommer@parallels.com \
--cc=bfields@fieldses.org \
--cc=corbet@lwn.net \
--cc=fweisbec@gmail.com \
--cc=ksummit-2012-discuss@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.