Contributor Summit planning

> For the past several years, we've held a Git Contributor Summit as part
> of the Git Merge conference. I'd like to get opinions from the community
> to help plan future installments. Any feedback or opinion is welcome,
> but some obvious things to think about:
>
>    - where, when, and how often?
>
>      Plans are shaping up to have Git Merge 2019 in Brussels right after
>      FOSDEM in February (like it was two years ago), with a contributor
>      summit attached.
>
>      Are there people who would be more likely to attend a contributor
>      summit if it were held elsewhere (e.g., in North America, probably
>      in the Bay Area)? Are people interested in attending a separate
>      contributor summit not attached to the larger Git Merge (and if so,
>      is there any other event it might be worth connecting it with,
>      time-wise)?  Are people interested in going to two summits in a year
>      (e.g., Brussels in February, and then maybe some in North America
>      later in the year), or is that diminishing returns?

>
>    - format
>
>      For those who haven't attended before, it's basically 25-ish Git
>      (and associated project) developers sitting in a room for a day
>      chatting about the project. Topics go on a whiteboard in the
>      morning, and then we discuss each for 30-60 minutes.
>
>      We could do multiple days (which might give more room for actually
>      working collaboratively instead of just discussing). We could do
>      something more formal (like actual talks). We could do something
>      less formal (like an all-day spaghetti buffet, where conversation
>      happens only between mouthfuls). The sky is the limit. Some of those
>      ideas may be better than others.

> The one thing I found missing that could be good is to have a remote option.
> Not everyone can travel or can afford to do so. I wonder if a simple Google
> Hangout could allow more participation from the community, even in a passive
> sense (those still at their day jobs listening in). It could even facilitate
> remote presenters, if applicable.

> On Mon, Aug 13, 2018 at 12:58:54PM -0400, Derrick Stolee wrote:
> 
> > I would be up for two meetings a year. I would expect that the variety of
> > locations would allow a larger set of contributors to make at least one
> > meeting a year. This may come at a cost of a smaller group in each summit.
> 
> Yeah, I do worry about it splitting the attendance. It could also be a
> thing we do _this_ year (if we care about having something in North
> America), and then try to make different plans in a future year.

> > The one thing I found missing that could be good is to have a remote
> > option.  Not everyone can travel or can afford to do so. I wonder if a
> > simple Google Hangout could allow more participation from the
> > community, even in a passive sense (those still at their day jobs
> > listening in). It could even facilitate remote presenters, if
> > applicable.
> 
> One year we had Dscho remote on a laptop sitting on a stool. I'm not
> sure how great that was for him. ;)

> I agree it would be nice to include remote people, but I think it would
> be very important to have a good A/V setup. Passive involvement is not
> too hard, but I would love a setup where they could actually participate
> in discussions. I've seen that work in 5-10 people conferences, but I'm
> not sure how well even good A/V scales to 20-30.

> One other thought on remote folks: IMHO one of the most valuable things
> about these kinds of events (especially the first ones I attended) is
> the informal interactions. The hallway talks and meals provide a venue
> for spontaneous conversation, but they also just help us understand in a
> visceral way that the people on the other end of our emails are actual
> humans. Which I think can help smooth subsequent online interactions.
> I'm not sure how much of that can be gained remotely.

> Point in favor of the pure-online meeting: the informal standup on IRC
> every second Friday. I really try to attend it (it is a bit awkward
> because it is on a Friday evening in my timezone, right at the time when I
> want to unwind from the work week), as it does have a similar effect to
> in-person standups: surprising collaborations spring up, unexpected help,
> and a general sense of belonging.
>
> Of course, the value of these standups comes from the makeup of the
> participants: Stefan, Brandon, Stolee, JeffH, Jonathan and other *very*
> active core contributors hang out for roughly half an hour, sharing what
> they are working on, exchanging ideas, etc.

> On 8/27/2018 9:22 AM, Johannes Schindelin wrote:
> > Point in favor of the pure-online meeting: the informal standup on IRC
> > every second Friday. I really try to attend it (it is a bit awkward
> > because it is on a Friday evening in my timezone, right at the time when I
> > want to unwind from the work week), as it does have a similar effect to
> > in-person standups: surprising collaborations spring up, unexpected help,
> > and a general sense of belonging.
> >
> > Of course, the value of these standups comes from the makeup of the
> > participants: Stefan, Brandon, Stolee, JeffH, Jonathan and other *very*
> > active core contributors hang out for roughly half an hour, sharing what
> > they are working on, exchanging ideas, etc.
> 
> A focused aside, since you brought up the online "standup": it seems the IRC
> channel has been less than ideal, with people trying to participate but having
> nickname issues or being muted. You also describe another issue: the timing.
> Having a real-time discussion has its benefits, but also it leaves many people
> out.
> 
> One idea to try next time is to create a mailing list thread asking for
> statuses, and each person can chime in asynchronously and spawn a new
> discussion based on that status. Perhaps we can try that next time.

> A focused aside, since you brought up the online "standup": it seems the IRC
> channel has been less than ideal, with people trying to participate but
> having nickname issues or being muted. You also describe another issue: the
> timing. Having a real-time discussion has its benefits, but also it leaves
> many people out.

> [... talking about the IRC channel ...]
> 
> My offer to +v anyone affected by the channel's current settings still
> stands (just /msg me).  Zero people have taken me up on this offer so
> far.

> Having said that, I believe that we core contributors can learn to have a
> fruitful online meeting. With 30+ participants, too.
> 
> Learning from my past life in academia (it is hard for me to imagine a
> less disciplined crowd than a bunch of white, male, old scientists), we
> would need a moderator, and some forum that allows to "give somebody the
> mic". That software/platform should exist somewhere.

> I would love to have the best of both worlds. For example, it is an annual
> annoyance that we are discussion all kinds of things regarding Git, trying
> to steer the direction, to form collaborations on certain features, and
> the person at the helm is not even there.
> 
> Maybe *two* meetings per year, one attached to GitMerge, and one purely
> online, would help.

> Point in favor of the pure-online meeting: the informal standup on IRC
> every second Friday. I really try to attend it (it is a bit awkward
> because it is on a Friday evening in my timezone, right at the time when I
> want to unwind from the work week), as it does have a similar effect to
> in-person standups: surprising collaborations spring up, unexpected help,
> and a general sense of belonging.

> Such an online summit as I suggested above would really only work if
> enough frequent contributors would attend. If enough people like you,
> Junio, and the standup regulars would say: yep, we're willing to plan and
> attend an online summit, where we try to have a timezone-friendly
> "unconference"-style meeting on one day (on which we would of course try
> to free ourselves from our regular work obligations).
> 
> I guess I am asking for a "raise your hands", with mine high up in the
> air.

> On Mon, Aug 27, 2018 at 03:22:39PM +0200, Johannes Schindelin wrote:
> 
> > Having said that, I believe that we core contributors can learn to have a
> > fruitful online meeting. With 30+ participants, too.
> > 
> > Learning from my past life in academia (it is hard for me to imagine a
> > less disciplined crowd than a bunch of white, male, old scientists), we
> > would need a moderator, and some forum that allows to "give somebody the
> > mic". That software/platform should exist somewhere.
> 
> Yes, I agree that software tools could help a lot with a crowd that
> size. I have used various "virtual classroom" tools before, and I think
> the core of the idea is there, but I was often unimpressed by the
> execution (and expense). So if you know of a good tool, it might be
> worth trying.

> > I would love to have the best of both worlds. For example, it is an annual
> > annoyance that we are discussion all kinds of things regarding Git, trying
> > to steer the direction, to form collaborations on certain features, and
> > the person at the helm is not even there.
> > 
> > Maybe *two* meetings per year, one attached to GitMerge, and one purely
> > online, would help.
> 
> I'm somewhat skeptical of the utility of an online meeting. That said,
> I'm willing give it a try (or any other scheme people want to come up
> with, for that matter).

> > Point in favor of the pure-online meeting: the informal standup on IRC
> > every second Friday. I really try to attend it (it is a bit awkward
> > because it is on a Friday evening in my timezone, right at the time when I
> > want to unwind from the work week), as it does have a similar effect to
> > in-person standups: surprising collaborations spring up, unexpected help,
> > and a general sense of belonging.
> 
> Yes, I've been meaning to make it to another one (I popped in for one a
> month or two ago, and it didn't seem like much of anything was
> happening).
> 
> What time is it, again?

> > Such an online summit as I suggested above would really only work if
> > enough frequent contributors would attend. If enough people like you,
> > Junio, and the standup regulars would say: yep, we're willing to plan and
> > attend an online summit, where we try to have a timezone-friendly
> > "unconference"-style meeting on one day (on which we would of course try
> > to free ourselves from our regular work obligations).
> > 
> > I guess I am asking for a "raise your hands", with mine high up in the
> > air.
> 
> I'll come if you want to organize it.

>
> For the past several years, we've held a Git Contributor Summit as part
> of the Git Merge conference. I'd like to get opinions from the community
> to help plan future installments. Any feedback or opinion is welcome,
> but some obvious things to think about:
>
>   - where, when, and how often?
>
>     Plans are shaping up to have Git Merge 2019 in Brussels right after
>     FOSDEM in February (like it was two years ago), with a contributor
>     summit attached.
>
>     Are there people who would be more likely to attend a contributor
>     summit if it were held elsewhere (e.g., in North America, probably
>     in the Bay Area)? Are people interested in attending a separate
>     contributor summit not attached to the larger Git Merge (and if so,
>     is there any other event it might be worth connecting it with,
>     time-wise)?  Are people interested in going to two summits in a year
>     (e.g., Brussels in February, and then maybe some in North America
>     later in the year), or is that diminishing returns?

>   - format
>
>     For those who haven't attended before, it's basically 25-ish Git
>     (and associated project) developers sitting in a room for a day
>     chatting about the project. Topics go on a whiteboard in the
>     morning, and then we discuss each for 30-60 minutes.
>
>     We could do multiple days (which might give more room for actually
>     working collaboratively instead of just discussing). We could do
>     something more formal (like actual talks). We could do something
>     less formal (like an all-day spaghetti buffet, where conversation
>     happens only between mouthfuls). The sky is the limit. Some of those
>     ideas may be better than others.

> On Mon, Aug 13, 2018 at 9:31 AM Jeff King <peff@peff.net> wrote:
>>
>> For the past several years, we've held a Git Contributor Summit as part
>> of the Git Merge conference. I'd like to get opinions from the community
>> to help plan future installments. Any feedback or opinion is welcome,
>> but some obvious things to think about:
>>
>>   - where, when, and how often?
>>
>>     Plans are shaping up to have Git Merge 2019 in Brussels right after
>>     FOSDEM in February (like it was two years ago), with a contributor
>>     summit attached.
>>
>>     Are there people who would be more likely to attend a contributor
>>     summit if it were held elsewhere (e.g., in North America, probably
>>     in the Bay Area)? Are people interested in attending a separate
>>     contributor summit not attached to the larger Git Merge (and if so,
>>     is there any other event it might be worth connecting it with,
>>     time-wise)?  Are people interested in going to two summits in a year
>>     (e.g., Brussels in February, and then maybe some in North America
>>     later in the year), or is that diminishing returns?
>
> We have been kicking around the thought of reviving the GitTogethers
> like back in the olden days (I only know them from hearsay), in
> Mountain View or Sunnyvale at the Google Campus, but we have not yet
> spent enough thought to make it so.

>>   - format
>>
>>     For those who haven't attended before, it's basically 25-ish Git
>>     (and associated project) developers sitting in a room for a day
>>     chatting about the project. Topics go on a whiteboard in the
>>     morning, and then we discuss each for 30-60 minutes.
>>
>>     We could do multiple days (which might give more room for actually
>>     working collaboratively instead of just discussing). We could do
>>     something more formal (like actual talks). We could do something
>>     less formal (like an all-day spaghetti buffet, where conversation
>>     happens only between mouthfuls). The sky is the limit. Some of those
>>     ideas may be better than others.

> > We have been kicking around the thought of reviving the GitTogethers
> > like back in the olden days (I only know them from hearsay), in
> > Mountain View or Sunnyvale at the Google Campus, but we have not yet
> > spent enough thought to make it so.
> 
> I think it would be great to have GitTogethers again around the time
> of the GSoC Mentor Summit like we did a long time ago!

> > Personally I think the way is fine; we could collect topics in advance on
> > the list to have a head start, but the whiteboard is totally fine, IMHO.
> 
> Yeah for the GitTogethers we used to collect topics in advance, but we
> still had a whiteboard and voted on them at the beginning of the
> actual GitTogether.

> For the past several years, we've held a Git Contributor Summit as part
> of the Git Merge conference. I'd like to get opinions from the community
> to help plan future installments. Any feedback or opinion is welcome,
> but some obvious things to think about:
>
>   - where, when, and how often?
>
>     Plans are shaping up to have Git Merge 2019 in Brussels right after
>     FOSDEM in February (like it was two years ago), with a contributor
>     summit attached.
>
>     Are there people who would be more likely to attend a contributor
>     summit if it were held elsewhere (e.g., in North America, probably
>     in the Bay Area)? Are people interested in attending a separate
>     contributor summit not attached to the larger Git Merge (and if so,
>     is there any other event it might be worth connecting it with,
>     time-wise)?  Are people interested in going to two summits in a year
>     (e.g., Brussels in February, and then maybe some in North America
>     later in the year), or is that diminishing returns?
>
>   - format
>
>     For those who haven't attended before, it's basically 25-ish Git
>     (and associated project) developers sitting in a room for a day
>     chatting about the project. Topics go on a whiteboard in the
>     morning, and then we discuss each for 30-60 minutes.
>
>     We could do multiple days (which might give more room for actually
>     working collaboratively instead of just discussing). We could do
>     something more formal (like actual talks). We could do something
>     less formal (like an all-day spaghetti buffet, where conversation
>     happens only between mouthfuls). The sky is the limit. Some of those
>     ideas may be better than others.
>
> I hope this can stimulate a discussion on the list, but of course if
> anybody has private feedback about past events or future planning, feel
> free to email me off-list.

>  * I think we should tread carefully when it comes to say some form of
>    remote A/V participation open to the Internet.
> 
>    It was fine to have Dscho on a chair, but it would be quite different
>    if this were say streamed on YouTube and everyone felt like they were
>    on stage the whole time, and if offhand comments / jokes etc. were
>    recorded.
> 
>    I'm not categorically against that, it's just something to think
>    carefully about. Maybe if there's demand for it we could dedicate
>    some time slot to that.

>    Or would those companies be OK with trusting that some 20-ish of us
>    can hold our tongues for one day and not ruin the surprise?
>
>    There's also overlap with the remote A/V concerns there. I.e. an
>    acceptable compromise for those companies might be to talk about
>    those features freely in the contributor summit trusting that it's a
>    closed forum, but that wouldn't work if it's going to be broadcasted.
>
> 1. git.git$ git log --pretty=format:%aN --since=2018-01-01|sort|uniq -c|sort -nr|head -n 20

>
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
> >    Or would those companies be OK with trusting that some 20-ish of us
> >    can hold our tongues for one day and not ruin the surprise?
> >
> >    There's also overlap with the remote A/V concerns there. I.e. an
> >    acceptable compromise for those companies might be to talk about
> >    those features freely in the contributor summit trusting that it's a
> >    closed forum, but that wouldn't work if it's going to be broadcasted.
> >
> > 1. git.git$ git log --pretty=format:%aN --since=2018-01-01|sort|uniq -c|sort -nr|head -n 20
>
> You'd need --no-merges there at least.

>
> 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.

> However the mailing list participation numbers there doesn't really
> help me:
> 
> ~/git-ml$ git shortlog --since 2017 -sne
>   3721  Junio C Hamano <gitster@pobox.com>
>   2166  Stefan Beller <stefanbeller@gmail.com>
>   2071  Jeff King <peff@peff.net>
> 
> 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.

> On 8/13/2018 5:54 PM, Jeff King wrote:
> > So I try not to think too hard on metrics, and just use them to get a
> > rough view on who is active.
> 
> I've been very interested in measuring community involvement, with the
> knowledge that any metric is flawed and we should not ever say "this metric
> is how we measure the quality of a contributor". It can be helpful, though,
> to track some metrics and their change over time.
> 
> Here are a few measurements we can make:

> 2. Number of other commit tag-lines (Reviewed-By, Helped-By, Reported-By,
> etc.).
> 
>     Using git repo:
> 
>     $ git log --since=2018-01-01 junio/next|grep by:|grep -v
> Signed-off-by:|sort|uniq -c|sort -nr|head -n 20

> Thanks, it was nice to see a more comprehensive list in one spot.
>
> It would be neat to have a tool that presents all of these
> automatically, but I think the email ones are pretty tricky (most people
> don't have the whole list archive sitting around).

>
> > 2. Number of other commit tag-lines (Reviewed-By, Helped-By, Reported-By,
> > etc.).
> >
> >     Using git repo:
> >
> >     $ git log --since=2018-01-01 junio/next|grep by:|grep -v
> > Signed-off-by:|sort|uniq -c|sort -nr|head -n 20
>
> At one point I sent a patch series that would let shortlog group by
> trailers. Nobody seemed all that interested and I didn't end up using it
> for its original purpose, so I didn't polish it further.  But I'd be
> happy to re-submit it if you think it would be useful.

> On Tue, Aug 14, 2018 at 12:36 PM Jeff King <peff@peff.net> wrote:
> 
> > Thanks, it was nice to see a more comprehensive list in one spot.
> >
> > It would be neat to have a tool that presents all of these
> > automatically, but I think the email ones are pretty tricky (most people
> > don't have the whole list archive sitting around).
> 
> With the advent of public inbox, this is easy to obtain?

> > At one point I sent a patch series that would let shortlog group by
> > trailers. Nobody seemed all that interested and I didn't end up using it
> > for its original purpose, so I didn't polish it further.  But I'd be
> > happy to re-submit it if you think it would be useful.
> 
> I would think it is useful. Didn't Linus also ask for a related thing?
> https://public-inbox.org/git/CA+55aFzWkE43rSm-TJNKkHq4F3eOiGR0-Bo9V1=a1s=vQ0KPqQ@mail.gmail.com/

> On Tue, Aug 14, 2018 at 12:47:59PM -0700, Stefan Beller wrote:
> > With the advent of public inbox, this is easy to obtain?
> 
> For our project, yes. But I was thinking of a tool that could be used
> for other projects, too.

> On Tue, Aug 14, 2018 at 01:43:38PM -0400, Derrick Stolee wrote:
>
>> On 8/13/2018 5:54 PM, Jeff King wrote:
>> > So I try not to think too hard on metrics, and just use them to get a
>> > rough view on who is active.
>> 
>> I've been very interested in measuring community involvement, with the
>> knowledge that any metric is flawed and we should not ever say "this metric
>> is how we measure the quality of a contributor". It can be helpful, though,
>> to track some metrics and their change over time.
>> 
>> Here are a few measurements we can make:
>
> Thanks, it was nice to see a more comprehensive list in one spot.
>
> It would be neat to have a tool that presents all of these
> automatically, but I think the email ones are pretty tricky (most people
> don't have the whole list archive sitting around).

> Jeff King <peff@peff.net> writes:
> 
> > On Tue, Aug 14, 2018 at 01:43:38PM -0400, Derrick Stolee wrote:
> >
> >> On 8/13/2018 5:54 PM, Jeff King wrote:
> >> > So I try not to think too hard on metrics, and just use them to get a
> >> > rough view on who is active.
> >> 
> >> I've been very interested in measuring community involvement, with the
> >> knowledge that any metric is flawed and we should not ever say "this metric
> >> is how we measure the quality of a contributor". It can be helpful, though,
> >> to track some metrics and their change over time.
> >> 
> >> Here are a few measurements we can make:
> >
> > Thanks, it was nice to see a more comprehensive list in one spot.
> >
> > It would be neat to have a tool that presents all of these
> > automatically, but I think the email ones are pretty tricky (most people
> > don't have the whole list archive sitting around).
> 
> I do not think it covered e-mail at all, but there was git stats
> project several years ago (perhaps part of GSoC IIRC).
> 
> > I think I mentioned "surviving lines" elsewhere, which I do like this
> > (and almost certainly stole from Junio a long time ago):
> 
> Yeah, I recall that one as part of counting how many of 1244 lines
> Linus originally wrote still were in our codebase at around v1.6.0
> timeframe (the answer was ~220 IIRC) ;-)

> 2. Number of other commit tag-lines (Reviewed-By, Helped-By,
> Reported-By, etc.).
>
>      Using git repo:
>
>      $ git log --since=2018-01-01 junio/next|grep by:|grep -v
> Signed-off-by:|sort|uniq -c|sort -nr|head -n 20
>
>       66     Reviewed-by: Stefan Beller <sbeller@google.com>
>       22     Reviewed-by: Jeff King <peff@peff.net>
>       19     Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
>       12     Helped-by: Eric Sunshine <sunshine@sunshineco.com>
>       11     Helped-by: Junio C Hamano <gitster@pobox.com>
>        9     Helped-by: Jeff King <peff@peff.net>
>        8     Reviewed-by: Elijah Newren <newren@gmail.com>
>        7     Reported-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
>        7     Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>        7     Acked-by: Brandon Williams <bmwill@google.com>
>        6     Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
>        6     Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>        5     Mentored-by: Christian Couder <christian.couder@gmail.com>
>        5     Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>        4     Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
>        4     Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>        4     Helped-by: Stefan Beller <sbeller@google.com>
>        4     Helped-by: René Scharfe <l.s.r@web.de>
>        3     Reviewed-by: Martin Ågren <martin.agren@gmail.com>
>        3     Reviewed-by: Lars Schneider <larsxschneider@gmail.com>
>
>      (There does not appear to be enough density here to make a useful
> metric.)

> On Tue, Aug 14, 2018 at 7:43 PM Derrick Stolee <stolee@gmail.com> wrote:
> > 2. Number of other commit tag-lines (Reviewed-By, Helped-By,
> > Reported-By, etc.).
> >
> >      Using git repo:
> >
> >      $ git log --since=2018-01-01 junio/next|grep by:|grep -v
> > Signed-off-by:|sort|uniq -c|sort -nr|head -n 20
> >
> >       66     Reviewed-by: Stefan Beller <sbeller@google.com>
> >       22     Reviewed-by: Jeff King <peff@peff.net>
> >       19     Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
> >       12     Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> >       11     Helped-by: Junio C Hamano <gitster@pobox.com>
> >        9     Helped-by: Jeff King <peff@peff.net>
> >        8     Reviewed-by: Elijah Newren <newren@gmail.com>
> >        7     Reported-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
> >        7     Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> >        7     Acked-by: Brandon Williams <bmwill@google.com>
> >        6     Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
> >        6     Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> >        5     Mentored-by: Christian Couder <christian.couder@gmail.com>
> >        5     Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> >        4     Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
> >        4     Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> >        4     Helped-by: Stefan Beller <sbeller@google.com>
> >        4     Helped-by: René Scharfe <l.s.r@web.de>
> >        3     Reviewed-by: Martin Ågren <martin.agren@gmail.com>
> >        3     Reviewed-by: Lars Schneider <larsxschneider@gmail.com>
> >
> >      (There does not appear to be enough density here to make a useful
> > metric.)
> 
> If your database keeps mail relationship (e.g. what mail is replied to
> what according to In-Reply-To header) then look for mail replies to
> patches. I think we have a rough picture who are active reviewers with
> that.

>
> 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 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. :)
> 
> --no-merges makes me number one. Not sure if I should laugh or cry :D

> Going off topic a bit, can we count the number of topics of each
> contributor? I could do it by decorating git log with remote refs from
> Junio's repo and counting based on the two-letter prefix in the
> topic/ref name but that's too hacky. fyi Jeff you're up to  second
> position now with 34 topics (I'm unfortunately still the first with
> 38).

>
> One problem there is that the prefixes are ambiguous (e.g., Jacob Keller
> shares with me, and I think at least one other over the years). You
> could look at the author of the tip commit, but that's not always right
> (and in fact, counting just merged topics misses bug-fixes that get
> applied directly on top of other people's topics). And of course there's
> the notion that "topic" might be a documentation typo fix, or it might
> be the entire range-diff program.

> One problem there is that the prefixes are ambiguous (e.g., Jacob Keller
> shares with me, and I think at least one other over the years). You
> could look at the author of the tip commit, but that's not always right
> (and in fact, counting just merged topics misses bug-fixes that get
> applied directly on top of other people's topics).

> On Mon, 13 Aug 2018, Ævar Arnfjörð Bjarmason wrote:
> 
> >  * Re the second half of "Not everyone can travel or can afford to do
> >    so" from Derrick, there's been travel sponsorships in past years.
> 
> Just to make sure that you understand: there are many more reasons than
> just travel costs involved. Just to name a few:
> 
> - visa issues.
> 
> - some people have to take care of family members and are not at liberty
>   to leave for even so much as half a day.
> 
> - conflicting schedules.
> 
> - mental health. As a friend of mine once put it: nobody is completely
>   "healthy", we all suffer, on a spectrum, from anxiety, trauma, and other
>   issues. The more inclusive we are, the more we can benefit from
>   everybody's talents and contributions.
> 
> Just saying. Money is sometimes not the solution.

>
> For the past several years, we've held a Git Contributor Summit as part
> of the Git Merge conference. I'd like to get opinions from the community
> to help plan future installments. Any feedback or opinion is welcome,
> but some obvious things to think about:
>
>   - where, when, and how often?
>
>     Plans are shaping up to have Git Merge 2019 in Brussels right after
>     FOSDEM in February (like it was two years ago), with a contributor
>     summit attached.
>
>     Are there people who would be more likely to attend a contributor
>     summit if it were held elsewhere (e.g., in North America, probably
>     in the Bay Area)? Are people interested in attending a separate
>     contributor summit not attached to the larger Git Merge (and if so,
>     is there any other event it might be worth connecting it with,
>     time-wise)?  Are people interested in going to two summits in a year
>     (e.g., Brussels in February, and then maybe some in North America
>     later in the year), or is that diminishing returns?

> On Mon, Aug 13, 2018 at 10:27 AM Jeff King <peff@peff.net> wrote:
> >
> > For the past several years, we've held a Git Contributor Summit as
> > part of the Git Merge conference. I'd like to get opinions from the
> > community to help plan future installments. Any feedback or opinion is
> > welcome, but some obvious things to think about:
> >
> >   - where, when, and how often?
> >
> >     Plans are shaping up to have Git Merge 2019 in Brussels right after
> >     FOSDEM in February (like it was two years ago), with a contributor
> >     summit attached.
> >
> >     Are there people who would be more likely to attend a contributor
> >     summit if it were held elsewhere (e.g., in North America, probably
> >     in the Bay Area)? Are people interested in attending a separate
> >     contributor summit not attached to the larger Git Merge (and if so,
> >     is there any other event it might be worth connecting it with,
> >     time-wise)?  Are people interested in going to two summits in a year
> >     (e.g., Brussels in February, and then maybe some in North America
> >     later in the year), or is that diminishing returns?
> 
> Convincing my employer to send me to an event in North America is a lot
> easier than one in Europe; they mostly allow me to work on git stuff as a side
> project just to make me happy rather than as a business priority, so
> competing business interests, shifting managers, etc. make things hard for
> me to predict (so you may want to weight my preferences less than normal).
> 
> My last manger did say they'd send me to the next contributor summit (I
> think even if it ended up being in Europe rather than North America), but of
> course, he was pulled to a different team a few months ago, so I'm not sure
> if that still stands.
> 
> 
> On a personal note, I'm also somewhat travel averse.  It'd be nice to go to a
> Git conference again (last and only I went to was I think Git Together 2011),
> but I know when it comes close to time to actually travel, I'll start
> questioning my sanity when I said that -- particularly if it's far away or at all
> complicated.  (So maybe you really ought to discount my preferences...)

> On August 14, 2018 2:53 AM, Elijah Newren wrote:
>> On Mon, Aug 13, 2018 at 10:27 AM Jeff King <peff@peff.net> wrote:
>> >
>> > For the past several years, we've held a Git Contributor Summit as
>> > part of the Git Merge conference. I'd like to get opinions from the
>> > community to help plan future installments. Any feedback or opinion is
>> > welcome, but some obvious things to think about:
>> >
>> >   - where, when, and how often?
>> >
>> >     Plans are shaping up to have Git Merge 2019 in Brussels right after
>> >     FOSDEM in February (like it was two years ago), with a contributor
>> >     summit attached.
>> >
>> >     Are there people who would be more likely to attend a contributor
>> >     summit if it were held elsewhere (e.g., in North America, probably
>> >     in the Bay Area)? Are people interested in attending a separate
>> >     contributor summit not attached to the larger Git Merge (and if so,
>> >     is there any other event it might be worth connecting it with,
>> >     time-wise)?  Are people interested in going to two summits in a year
>> >     (e.g., Brussels in February, and then maybe some in North America
>> >     later in the year), or is that diminishing returns?
>>
>> Convincing my employer to send me to an event in North America is a lot
>> easier than one in Europe; they mostly allow me to work on git stuff as a side
>> project just to make me happy rather than as a business priority, so
>> competing business interests, shifting managers, etc. make things hard for
>> me to predict (so you may want to weight my preferences less than normal).
>>
>> My last manger did say they'd send me to the next contributor summit (I
>> think even if it ended up being in Europe rather than North America), but of
>> course, he was pulled to a different team a few months ago, so I'm not sure
>> if that still stands.
>>
>>
>> On a personal note, I'm also somewhat travel averse.  It'd be nice to go to a
>> Git conference again (last and only I went to was I think Git Together 2011),
>> but I know when it comes close to time to actually travel, I'll start
>> questioning my sanity when I said that -- particularly if it's far away or at all
>> complicated.  (So maybe you really ought to discount my preferences...)
>
> Unrelated directly to above, I noticed that I actually showed up on
> the list for 2018 based on git log anyway. Does this mean I'd be
> welcome? Personally, it's actually easier to get approval to travel to
> Brussels now than SFO even though the latter is closer. With that in
> mind, I can do either (or both - depending on scheduling).

> I very much regret sending that 'git log' command without some further
> explanation.
> 
> It was only meant as a *very* rough shortlist of people in the context
> of a discussion of why some active contributors don't come to the
> contributor summit. I.e. whether that's because of the location, timing
> or whatever.
> 
> Any output from such a command definitely doesn't mean "you shouldn't
> come to the contributor summit because this one-liner doesn't list
> you".

> I only meant to suggest that it would be interesting as a heuristic to
> solicit feedback from people who *are* very active contributors to the
> main git project who don't show up, to see why that is. Only because it
> might be indicative of why some people who'd otherwise don't show up
> don't show up.

> Unrelated directly to above, I noticed that I actually showed up on
> the list for 2018 based on git log anyway. Does this mean I'd be
> welcome? Personally, it's actually easier to get approval to travel to
> Brussels now than SFO even though the latter is closer. With that in
> mind, I can do either (or both - depending on scheduling).

> For the past several years, we've held a Git Contributor Summit as part
> of the Git Merge conference. I'd like to get opinions from the community
> to help plan future installments. Any feedback or opinion is welcome,
> but some obvious things to think about:
> 
>   - where, when, and how often?
> 
>     Plans are shaping up to have Git Merge 2019 in Brussels right after
>     FOSDEM in February (like it was two years ago), with a contributor
>     summit attached.
> 
>     Are there people who would be more likely to attend a contributor
>     summit if it were held elsewhere (e.g., in North America, probably
>     in the Bay Area)? Are people interested in attending a separate
>     contributor summit not attached to the larger Git Merge (and if so,
>     is there any other event it might be worth connecting it with,
>     time-wise)?  Are people interested in going to two summits in a year
>     (e.g., Brussels in February, and then maybe some in North America
>     later in the year), or is that diminishing returns?

>   - format
> 
>     For those who haven't attended before, it's basically 25-ish Git
>     (and associated project) developers sitting in a room for a day
>     chatting about the project. Topics go on a whiteboard in the
>     morning, and then we discuss each for 30-60 minutes.
> 
>     We could do multiple days (which might give more room for actually
>     working collaboratively instead of just discussing). We could do
>     something more formal (like actual talks). We could do something
>     less formal (like an all-day spaghetti buffet, where conversation
>     happens only between mouthfuls). The sky is the limit. Some of those
>     ideas may be better than others.

> >   - format
> > 
> >     For those who haven't attended before, it's basically 25-ish Git
> >     (and associated project) developers sitting in a room for a day
> >     chatting about the project. Topics go on a whiteboard in the
> >     morning, and then we discuss each for 30-60 minutes.
> > 
> >     We could do multiple days (which might give more room for actually
> >     working collaboratively instead of just discussing). We could do
> >     something more formal (like actual talks). We could do something
> >     less formal (like an all-day spaghetti buffet, where conversation
> >     happens only between mouthfuls). The sky is the limit. Some of those
> >     ideas may be better than others.
> 
> I found the unconference-style, one day meeting to be most productive.
> 
> As to more formal? I don't know... talks seem to be fun and all, but they
> require a lot of preparation. Something championed in our standups are
> "chalk talks", i.e. somebody presenting in a bit more detail what they are
> working on, in particular explaining the context (think: Stolee
> enlightening the audience about finer points of computational graph
> theory) *without* preparing for it specifically. That makes for fun
> presentations, if a bit more chaotic than a real "conference talk". This
> format obviously lends itself to Google Hangouts.
> 
> As to multiple days: Of course it would be nice to have a kind of a "hack
> day", but I wonder how productive this would be in the context of Git,
> where interests very so widely.

> Rather than have a "hack day", I would actually prefer to work with other
> contributors in a way that we have not done before, but which I had the
> pleasure of "test ballooning" with Pratik: using Visual Studio Code Live
> Share. This allows multiple users to work on the same code base, in the
> same worktree, seeing what each other is doing. It requires a separate
> communication channel to talk; Pratik & I used IRC, but I think Google
> Hangout (or Skype or WhatsApp or <insert-your-favorite-chat-here>) would
> have worked a bit better. It's kind of pair programming, but with some of
> the limitations removed.

> On Mon, Aug 27, 2018 at 03:34:16PM +0200, Johannes Schindelin wrote:
> 
> > Rather than have a "hack day", I would actually prefer to work with
> > other contributors in a way that we have not done before, but which I
> > had the pleasure of "test ballooning" with Pratik: using Visual Studio
> > Code Live Share. This allows multiple users to work on the same code
> > base, in the same worktree, seeing what each other is doing. It
> > requires a separate communication channel to talk; Pratik & I used
> > IRC, but I think Google Hangout (or Skype or WhatsApp or
> > <insert-your-favorite-chat-here>) would have worked a bit better. It's
> > kind of pair programming, but with some of the limitations removed.
> 
> OK, I said in my earlier email that I would give any scheme a try, but I
> really don't like pair programming. ;)

> On Wed, 29 Aug 2018, Jeff King wrote:
> 
> > On Mon, Aug 27, 2018 at 03:34:16PM +0200, Johannes Schindelin wrote:
> > 
> > > Rather than have a "hack day", I would actually prefer to work with
> > > other contributors in a way that we have not done before, but which I
> > > had the pleasure of "test ballooning" with Pratik: using Visual Studio
> > > Code Live Share. This allows multiple users to work on the same code
> > > base, in the same worktree, seeing what each other is doing. It
> > > requires a separate communication channel to talk; Pratik & I used
> > > IRC, but I think Google Hangout (or Skype or WhatsApp or
> > > <insert-your-favorite-chat-here>) would have worked a bit better. It's
> > > kind of pair programming, but with some of the limitations removed.
> > 
> > OK, I said in my earlier email that I would give any scheme a try, but I
> > really don't like pair programming. ;)
> 
> Tastes do differ, and that's okay.
> 
> I found it pretty invaluable a tool for intense 1:1 mentoring. It
> definitely helps a lot with getting over the initial hurdles.

> On Wed, Aug 29, 2018 at 04:46:29PM +0200, Johannes Schindelin wrote:
> 
> > On Wed, 29 Aug 2018, Jeff King wrote:
> > 
> > > On Mon, Aug 27, 2018 at 03:34:16PM +0200, Johannes Schindelin wrote:
> > > 
> > > > Rather than have a "hack day", I would actually prefer to work with
> > > > other contributors in a way that we have not done before, but which I
> > > > had the pleasure of "test ballooning" with Pratik: using Visual Studio
> > > > Code Live Share. This allows multiple users to work on the same code
> > > > base, in the same worktree, seeing what each other is doing. It
> > > > requires a separate communication channel to talk; Pratik & I used
> > > > IRC, but I think Google Hangout (or Skype or WhatsApp or
> > > > <insert-your-favorite-chat-here>) would have worked a bit better. It's
> > > > kind of pair programming, but with some of the limitations removed.
> > > 
> > > OK, I said in my earlier email that I would give any scheme a try, but I
> > > really don't like pair programming. ;)
> > 
> > Tastes do differ, and that's okay.
> > 
> > I found it pretty invaluable a tool for intense 1:1 mentoring. It
> > definitely helps a lot with getting over the initial hurdles.
> 
> Actually, I would agree that mentoring is probably one of the best uses
> for pairing like that. In retrospect, I think we should have done more
> real-time collaboration during Outreachy last winter.  It's still not my
> taste, but I think we could have accomplished more overall.
> 
> Not that I need to convince you, but just seconding your advice for the
> benefit of people who are thinking about mentoring in the future.