Re: Parseable tracking of code contributions.

On Jul 14, 2005, at 11:48 AM, kfogel@collab.net wrote:
>
> "Review" is when someone reviews your patch.
>
> "Analysis" is when someone analyses the *problem*, thus helping you to
> *produce* a patch.

Thanks for explaining.

>
> Someone may contribute analysis without ever reviewing the resulting
> patch. Someone may review a patch without having contributed at all
> to the analysis leading to that patch. In fact, these are the norms;
> while there are commits where the same person contributes both review
> and analysis, they don't seem to be the majority.
>

Yup, makes sense. Happens all the time.

>
> The reason I'm interested in tracking analyses in a parseable way is
> that it helps identify the sort of behavior we look for new
> developers.
>
> Now that all this is clear, do you still feel the same way about it?
>

Hm, not entirely. I agree that the question

   "Hm, how many patches has person X submitted? How many have been
approved?"

...comes up quite a bit. But the question

   "Hm, how much interesting discussion/analysis of problems has
person X contributed?"

...doesn't really come up, because the answer is always clear.
Someone who participates in dev@ discussions regularly leaves a mark
in your brain -- some good, some bad, but always present. It's not
something that needs to be quantified by tally marks.

Further problems:

* If we tried to quantify this stuff anyway, how would we account for
all of the person's "analyses" that weren't directly related to patches?

* Taken to the extreme: when merging the locking feature-branch,
should my log message have listed every non-committer who ever
participated in the 6 months of design conversations?

I still think that This Way Lies Madness.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 14 19:56:49 2005