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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:37

Junio C Hamano [off-list ref] writes:
"Sverre Rabbelier" [off-list ref] writes:
quoted
quoted
 >>  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.

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

From: Sverre Rabbelier <hidden>
Date: 2016-06-15 22:44:38

On Wed, May 21, 2008 at 7:30 PM, Junio C Hamano [off-list ref] wrote:
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.
I think I know where this is coming from and what you say makes sense.
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.
Yup, in order to gather that kind of data a more elaborate tool (one
that is integrated with a review tool like Rietveld or such) together
with the VCS would be required. I'm confident that this project will
result in useful statistics. Perhaps they will not be enough to
determine which patches to let in and which ones to reject without
human interference (I'm actually quite sure that won't happen), but I
do think other useful statistics may be gathered and used
nevertheless.

-- 
Cheers,

Sverre Rabbelier
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help