Re: [RFC] Use cases for 'git statistics'

From: Junio C Hamano <gitster@pobox.com>
Date: May 21, 2008, 17:30 UTC
Message-ID: <7vprrf4lar.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vlk29er1w.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 18 quoted lines

> "Sverre Rabbelier" <srabbelier@gmail.com> writes:
>
>>>  >>  Details I think need to be provided by maintainer...
>>>  >
>>>  > Do you mean Junio, or the user of the program?
>>>
>>>  I mean that all I can provide is speculation.  I'm not, and never was
>>>  a maintainer of OSS project, and I don't know what criteria one use
>>>  (perhaps unvoiced criteria) to decide whether given patch needs to be
>>>  examined more closely, or the cursory browsing should be enough.
>>
>> I reckon more input from actual maintainers would be needed then.
>> Junio: aside from the original list with suggestions you provided,
>> could you shine your light as git maintainer on this?
> ...
> Project maintainers and old timers become familiar with habits, strengths
> and weaknesses of known contributors over time, and that is the source of
> such trust.

I just realized another thing about "the source of trust". The "statistics" would count _only_ what gets accepted, but maintainers and list participants have much richer set of datapoints to judge the strengths and weaknesses of contributors --- rejects.

An early round of contribution from somebody needs deeper review if the contributor has a history of taking many rounds of refinements to get a rather trivial change into an acceptable shape. IOW, over time people can learn who are meticulous and who are careless from rejection counts, which is not recorded in the committed history.