Re: Contributor Summit planning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 13, 2018 at 2:06 PM Jeff King <peff@xxxxxxxx> wrote:
>
> On Mon, Aug 13, 2018 at 01:41:51PM -0700, Stefan Beller wrote:
>
> > > Oh, using "git shortlog" might be also simpler ;-)
> >
> > I guess you'd need to memorize a different set of flags for that
> > as without -s it would be harder to parse than the oneliner above.
>
> I frequently using "git shortlog -ns" to see who is active (especially
> coupled with "--since=".
>
> I also use "--no-merges", because it makes me look a lot better when
> compared relatively to Junio. :) I agree with you that "--no-merges"
> means we don't capture all the work that goes into integrating. But
> there's a lot of work that isn't reflected in commit count (reviewing,
> bug triage, the fact that some commits are much bigger than others,
> etc). So at best it's a starting point for figuring out who
> participates.

Heh. I tried finding that out, by looking at the public inbox repository
that contains the mailing list. (Recently I was looking at that repo to
learn about our workflow for different reasons, too)

However the mailing list participation numbers there doesn't really
help me:

~/git-ml$ git shortlog --since 2017 -sne
  3721  Junio C Hamano <gitster@xxxxxxxxx>
  2166  Stefan Beller <stefanbeller@xxxxxxxxx>
  2071  Jeff King <peff@xxxxxxxx>

and I certainly do not provide as much value as Junio or you do;
I am just good at resending long patch series to drive up the email
count. But I think that data would be also interesting to look at if
we were to find out what drives the community.

Maybe some derived metrics posts on mailing list divided by
commits appearing in origin/next can guide if one is a effective
contributor; but then as you said there are other ways to contribute
effectively as well.

Reviewing and bug triage do show up in the mailing
list but not as commits in git.git, but the numbers alone would
not hint at the quality. In fact the opposite is the case: if you only
need one email to diagnose a bug, suggest a workaround and
include a proper patch, it is more helpful to the community than
having more emails, potentially going back and forth.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux