Contributor Summit planning

Contributor Summit planning

[Jeff King]

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.

-Peff

Re: Contributor Summit planning

[Derrick Stolee]

On 8/13/2018 12:31 PM, Jeff King 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?

I've only been to one contributor summit, but found it extremely useful 
in meeting community members face-to-face. I think the time spent was 
very productive.

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.

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

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

Thanks for starting the discussion early!

-Stolee

Re: Contributor Summit planning

[Jeff King]

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.

(I don't think that's an argument against remote inclusion, just an
opinion that we should continue to encourage in-person interaction).

-Peff

Re: Contributor Summit planning

[Johannes Schindelin]

Hi Peff & everybody,

On Mon, 13 Aug 2018, Jeff King wrote:

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

While I think it is a great thing to have Git contributors so close to Git
users every year, I could imagine that a good compromise would be to have
a Git Contributor Summit the day before GitMerge, as we already have it,
and then roughly half a year later an "online-only" Virtual Summit.

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

It was great. It was truly great. Thanks again for letting me do that!

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

Speaking from personal experience in my day job, I agree that it is easy
to have a discussion with a few remotes when you have only 5-10 team
members, and it gets pretty difficult when there are 20-30 people or more.

However, I found that those problems are rooted more in lack of
discipline, such as the people with physical presence simply talking over
the remote ones, seemingly without noticing what they are doing there.

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.

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

Indeed. That part is almost lost online. But not quite.

> (I don't think that's an argument against remote inclusion, just an
> opinion that we should continue to encourage in-person interaction).

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.

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.

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.

Ciao,
Dscho

Re: Contributor Summit planning

[Derrick Stolee]

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.

Thanks,

-Stolee

Re: Contributor Summit planning

[Johannes Schindelin]

Hi Stolee,

On Mon, 27 Aug 2018, Derrick Stolee wrote:

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

Not so sure I like this idea. For me, mails are *extremely* asynchronous.
I started already over a decode ago to switch off automatic mail checking,
as it interfered with my productivity.

And for me, one of the main benefits of a standup is the chiming in from
unexpected sides. That's very much a real-time thing, and I don't know how
to achieve that otherwise.

But for our standup, I could imagine that even so much as shifting it from
Friday to any other weekday would decrease the timezone issues (because,
you know, weekend).

Ciao,
Dscho

Re: Contributor Summit planning

[Jonathan Nieder]

Hi Derrick,

Derrick Stolee wrote:

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

For me, the real-time element is the entire point.  If timezones are a
problem for some people, I'm happy to e.g. alternate with a different
hour.

The current IRC experience might be a bit unrepresentative, due to
https://freenode.net/news/spam-shake:

| As you may be aware there has been a prolonged spambot attack
| directed at freenode (and other IRC networks) in recent weeks,
| targeting a number of individuals involved with freenode and the
| wider IRC communities.

A kind person configured the channel to withstand this spam attack.
This involved users having to authenticate to Freenode using
https://freenode.net/kb/answer/registration#nickname-setup so that it
knows whether you are a spammer.  Sorry for the inconvenience.

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.

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

I don't want to discourage a good idea.  The logical extension of this
(not one thread but a whole list) reminds me of the Kernel Newbies
mailing list <https://kernelnewbies.org/>, which appears to work well
in that context.  Given my current time commitments, I wouldn't be
able to participate, but I would be happy to see other volunteers set
something like that up if interested.

The usual practice of sending email about current work on progress to
git@vger to get feedback also still works, and that is something I can
commit to continue to spend time on.

Thanks,
Jonathan

Re: Contributor Summit planning

[Jonathan Nieder]

Jonathan Nieder wrote:

> The current IRC experience might be a bit unrepresentative, due to
> https://freenode.net/news/spam-shake:

https://freenode.net/news/spambot-attack may be a better link.

Thanks,
Jonathan

Re: Contributor Summit planning

[Johannes Schindelin]

Hi Jonathan,

On Tue, 28 Aug 2018, Jonathan Nieder wrote:

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

I did have problems seeing any private messages from anybody
non-authenticated, recently. Pratik & Paul switched to Gitter for our
private conversations for that reason.

Ciao,
Dscho

Re: Contributor Summit planning

[Jeff King]

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.

-Peff

Re: Contributor Summit planning

[Johannes Schindelin]

Hi Peff,

On Wed, 29 Aug 2018, Jeff King wrote:

> 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 don't, and I will keep looking.

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

I am glad you say that.

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

It is supposed to happen every two weeks, on Fridays, 17:00-17:30 UTC:
https://public-inbox.org/git/20180713170018.GA139708@aiede.svl.corp.google.com/

The latest one is logged here:
http://colabti.org/irclogger/irclogger_log/git-devel?date=2018-08-24#l144

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

That's a good idea. I am a week away from taking a vacation, and I will
try to come back to that idea afterwards and see what I can do there.

The more I think about it, the more excited I get about it.

Ciao,
Dscho

Re: Contributor Summit planning

[Stefan Beller]

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.

I think twice a year is fine for the community and has not reached the
point of diminishing returns.

As most contributors are from North America (estimated), I would not
mind a conference somewhere here.

I'd be looking forward to Brussels next February!


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

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.

Stefan

Re: Contributor Summit planning

[Christian Couder]

On Mon, Aug 13, 2018 at 7:46 PM, Stefan Beller <sbeller@google.com> wrote:
> 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.

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!

> I think twice a year is fine for the community and has not reached the
> point of diminishing returns.

I agree.

> As most contributors are from North America (estimated), I would not
> mind a conference somewhere here.

Yeah, it looks like the Git Merge is most of the time in Europe, so it
would be nice to have something in North America too.

> I'd be looking forward to Brussels next February!

Looking forward to it too! I think it is a great idea to have it
around the time of the FOSDEM.

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

If we have GitTogethers again, I think it would be nice indeed if we
could do 2 days. For example maybe one day unconference and one day
working collaboratively or discussing in smaller groups. 2 days
instead of 1 would make it more valuable for developers based in
Europe (and maybe in North America and elsewhere) to come.

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

Thanks for starting this discussion.

Re: Contributor Summit planning

[Jeff King]

On Tue, Aug 14, 2018 at 06:31:50AM +0200, Christian Couder wrote:

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

Yeah, that's an interesting concept. In addition to amortizing travel
for one or maybe two Git devs who are mentors, it also allowed us to
pull in other open source folks who were tangential to Git (e.g., I
remember Joey Hess of git-annex fame came one year).

On the other hand, we can only send two mentors to the summit, so there
is no draw at all for the rest of the folks. :)

Timing-wise, it may be getting a little close to plan this year, as it's
exactly 2 months away (and I'd think many people, especially coming from
Europe, would already have made travel plans). We could start next year,
but that's 14 months away.

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

Heh. Every year I ask for topics on the list, and the response leads me
to believe that people are happy white-boarding in the morning. ;)

-Peff

Re: Contributor Summit planning

[Ævar Arnfjörð Bjarmason]

On Mon, Aug 13 2018, Jeff King 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?
>
>   - 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.

A few things, in no particular order (also in-reply-to the thread at
large):

 * Yeah these are really useful. Let's keep doing them!

 * In terms of how many per year & location, I think it's most
   interesting to listen to take feedback from top contributors[1] and
   check why the people who consistently don't come don't. Whether
   moving it to any other location would be useful for them, or whether
   they're generally just not interested.

   I.e. there's some Venn diagram to be drawn here of people who'd come
   no matter where it's held, people who'd only come if it's held at XYZ
   location etc., and likely time is going to be just as important for
   some as location.

   It would certainly be interesting to hear what would make Junio turn
   up again, or Nguyễn etc.

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

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

 * In terms of timing, we've had cases in past years where some topic
   (say large binary issues or large repo performance) was discussed at
   some length in the contributor summit, only to be followed by an
   announcement in the general conference (in this case LFS & GVFS)
   which was clearly under embargo before the talk given at the
   conference.

   I've said something to this effect before, but it would be nice if we
   could think about some solution to this. I.e. should we always be
   holding one contributor summit right after (not before) git merge, so
   that we're not pointlessly discussing some area while representatives
   from some company or other have to not comment and say "we have
   patches for 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
   [...]

   (Yeah this is just git.git, we'd want to do some union of
   "contributes to git ecosystem at large" for a proper list, also
   number of patches is only a fuzzy metric for contributions blah blah
   blah)

Re: Contributor Summit planning

[Jeff King]

On Mon, Aug 13, 2018 at 08:49:33PM +0200, Ævar Arnfjörð Bjarmason wrote:

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

Interesting points. I had in mind that the "invite list" for remote
would be the same as for in-person. I also am not categorically against
some kind of wider output for part of event, but I do think the casual
and intimate nature is most of what makes the event useful.

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

Yes, and I think we should continue with that offer. That's mostly been
paid out from project funds in past years, but I suspect we could dig up
sponsorship specific to the event if we had to.

> [...]
>    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?

Also good points. Obviously it's up to whoever is trying to keep their
secret what they want to do, but my opinion is that it's reasonable to
talk about things the day before. I really enjoyed in one of the early
years (Berlin 2013, I think) when Michael Haggerty gave two talks on
git-imerge: one to the general population that might be interested in
using it, and one to developers that really went into detail on the
theory of how it worked.

Another option I know we've discussed is having the contributor summit
the day _after_ the main conference. That really complicates the
logistics, though, because usually we piggy-back on the main event
space, which we already have available the day before for
main-conference setup and for training. I think it would also conflict
with people wanting to go to FOSDEM on the following day.

But I'll mention it to the folks organizing for this year to see if we
can work something out. Secrets aside, I think it would be fun to have a
session discussing all of the stuff we just heard about the day before. ;)

-Peff

Re: Contributor Summit planning

[Junio C Hamano]

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

Oh, using "git shortlog" might be also simpler ;-)

Re: Contributor Summit planning

[Stefan Beller]

On Mon, Aug 13, 2018 at 1:36 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Æ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.

No, I would disagree, as that removes you from top of the list,
and you seem to be a pretty central part of the community to say at least.

Ævar specifically pointed out that we might want to hear from you and Duy
if you want to attend a conference and if so how we can make that happen
(by choosing location/time/setting appropriately) IIUC.

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

Stefan

Re: Contributor Summit planning

[Jeff King]

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.

-Peff

Re: Contributor Summit planning

[Stefan Beller]

On Mon, Aug 13, 2018 at 2:06 PM Jeff King <peff@peff.net> 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@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.

Re: Contributor Summit planning

[Jeff King]

On Mon, Aug 13, 2018 at 02:19:07PM -0700, Stefan Beller wrote:

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

You could probably just drop any emails that start with "[PATCH" from
your count. They are ultimately counted separately in "git shortlog" on
the actual repo. And if you are sending tons of re-rolls you just do not
get any credit. ;)

The rabbit hole is deep there, though. Is it productive to have bugs in
your patch which force somebody else to reply (they get a point, good),
and then you have to respond explaining what's going on (you get a
point, bad, since you're now ahead of a hypothetical you who didn't have
the bug in the first place).

So I try not to think too hard on metrics, and just use them to get a
rough view on who is active.

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

Yep, another good example. More emails may mean you are incompetent at
diagnosing, or it may mean you are digging on a particularly hard
problem.

-Peff

Measuring Community Involvement (was Re: Contributor Summit planning)

[Derrick Stolee]

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:

1. Number of (non-merge) commit author tag-lines.

     using git repo:

   > git shortlog --no-merges --since 2017 -sne junio/next | head -n 20
    284  Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
    257  Jeff King <peff@peff.net>
    206  Stefan Beller <stefanbeller@gmail.com>
    192  brian m. carlson <sandals@crustytoothpaste.net>
    159  Brandon Williams <bmwill@google.com>
    149  Junio C Hamano <gitster@pobox.com>
    137  Elijah Newren <newren@gmail.com>
    116  René Scharfe <l.s.r@web.de>
    112  Johannes Schindelin <Johannes.Schindelin@gmx.de>
    105  Ævar Arnfjörð Bjarmason <avarab@gmail.com>
     96  Jonathan Tan <jonathantanmy@google.com>
     93  SZEDER Gábor <szeder.dev@gmail.com>
     78  Derrick Stolee <dstolee@microsoft.com>
     76  Martin Ågren <martin.agren@gmail.com>
     66  Michael Haggerty <mhagger@alum.mit.edu>
     61  Eric Sunshine <sunshine@sunshineco.com>
     46  Christian Couder <chriscool@tuxfamily.org>
     36  Phillip Wood <phillip.wood@dunelm.org.uk>
     35  Jonathan Nieder <jrnieder@gmail.com>
     33  Thomas Gummerer <t.gummerer@gmail.com>

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

3. Number of email messages sent.

     Using mailing list repo:

$ git shortlog --since 2017 -sne | head -n 20
   3749  Junio C Hamano <gitster@pobox.com>
   2213  Stefan Beller <sbeller@google.com>
   2112  Jeff King <peff@peff.net>
   1106  Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
   1028  Johannes Schindelin <Johannes.Schindelin@gmx.de>
    965  Ævar Arnfjörð Bjarmason <avarab@gmail.com>
    956  Brandon Williams <bmwill@google.com>
    947  Eric Sunshine <sunshine@sunshineco.com>
    890  Elijah Newren <newren@gmail.com>
    753  brian m. carlson <sandals@crustytoothpaste.net>
    677  Duy Nguyen <pclouds@gmail.com>
    646  Jonathan Nieder <jrnieder@gmail.com>
    629  Derrick Stolee <stolee@gmail.com>
    545  Christian Couder <christian.couder@gmail.com>
    515  Jonathan Tan <jonathantanmy@google.com>
    425  Johannes Schindelin <johannes.schindelin@gmx.de>
    425  Martin Ågren <martin.agren@gmail.com>
    420  Jeff Hostetler <git@jeffhostetler.com>
    420  SZEDER Gábor <szeder.dev@gmail.com>
    363  Phillip Wood <phillip.wood@talktalk.net>

3. Number of threads started by user.

     (For this and the measurements below, I imported emails into a SQL 
table with columns [commit, author, date, message-id, in-reply-to, 
subject] and ran queries)

SELECT TOP 20
        COUNT(*) as NumSent
       ,[Author]
   FROM [git].[dbo].[mailing-list]
   WHERE [In-Reply-To] = ''
         AND CONVERT(DATETIME,[Date]) > CONVERT(DATETIME, '01-01-2018 
00:00')
GROUP BY [Author]
ORDER BY NumSent DESC

| NumSent | Author                     |
|---------|----------------------------|
| 76      | Junio C Hamano             |
| 64      | Stefan Beller              |
| 54      | Philip Oakley              |
| 50      | Nguyá»…n Thái Ngọc Duy   |
| 49      | Robert P. J. Day           |
| 47      | Christian Couder           |
| 36      | Ramsay Jones               |
| 34      | Elijah Newren              |
| 34      | SZEDER Gábor              |
| 33      | Johannes Schindelin        |
| 31      | Jeff King                  |
| 30      | Ævar Arnfjörð Bjarmason |
| 24      | Jonathan Tan               |
| 22      | Alban Gruin                |
| 22      | brian m. carlson           |
| 18      | Randall S. Becker          |
| 15      | Paul-Sebastian Ungureanu   |
| 15      | Jeff Hostetler             |
| 15      | Brandon Williams           |
| 15      | Luke Diamand               |

4. Number of threads where the user participated

(This is measured by completing the transitive closure of In-Reply-To 
edges into a new 'BaseMessage' column.)

SELECT TOP 20
        COUNT(BaseMessage) as NumResponded
       ,Author
   FROM [git].[dbo].[mailing-list]
   WHERE [In-Reply-To] <> ''
         AND CONVERT(DATETIME,[Date]) > CONVERT(DATETIME, '01-01-2018 
00:00')
GROUP BY Author
ORDER BY NumResponded DESC

| NumResponded | Author                     |
|--------------|----------------------------|
| 2084         | Junio C Hamano             |
| 1596         | Stefan Beller              |
| 1211         | Jeff King                  |
| 1120         | Johannes Schindelin        |
| 1021         | Nguyá»…n Thái Ngọc Duy   |
| 799          | Eric Sunshine              |
| 797          | Ævar Arnfjörð Bjarmason |
| 693          | Brandon Williams           |
| 654          | Duy Nguyen                 |
| 600          | Elijah Newren              |
| 593          | brian m. carlson           |
| 591          | Derrick Stolee             |
| 318          | SZEDER Gábor              |
| 299          | Jonathan Tan               |
| 286          | Christian Couder           |
| 263          | Jonathan Nieder            |
| 257          | Phillip Wood               |
| 256          | Derrick Stolee             |
| 238          | Taylor Blau                |
| 216          | Martin Ã…gren              |

(Note, some names have not been de-duplicated across multiple email 
addresses, but the email addresses are removed from these tables since 
I'm using a markdown generator that strips the emails in < >.)

If you have other ideas for fun measurements, then please let me know.

Thanks,

-Stolee

Re: Measuring Community Involvement (was Re: Contributor Summit planning)

[Jeff King]

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

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

The shell hackery here isn't too bad, but doing it internally is a
little faster, a little more robust (less parsing), and lets you show
more details about the commits themselves (e.g., who reviews whom).

> 3. Number of threads started by user.

You have "started" and "participated in". I guess one more would be
"closed", as in "solved a bug", but that is quite hard to tell without
looking at the content. Taking just the last person in a thread as the
closer means that an OP saying "thanks!" wrecks it. And somebody who
rants long enough that everybody else loses interest gets marked as a
closer. ;)

> If you have other ideas for fun measurements, then please let me know.

I think I mentioned "surviving lines" elsewhere, which I do like this
(and almost certainly stole from Junio a long time ago):

  # Obviously you can tweak this as you like, but the mass-imported bits
  # in compat and xdiff tend to skew the counts. It's possibly worth
  # counting language lines separately.
  git ls-files '*.c' '*.h' :^compat :^contrib :^xdiff |
  while read fn; do
    # eye candy
    echo >&2 "Blaming $fn..."

    # You can use more/fewer -C to dig more or less for code moves.
    # Possibly "-w" would help, though I doubt it shifts things more
    # than a few percent anyway.
    git blame -C --line-porcelain $fn
  done |
  perl -lne '/^author (.*)/ and print $1' |
  sort | uniq -c | sort -rn | head

The output right now is:

  35156 Junio C Hamano
  22207 Jeff King
  17466 Nguyễn Thái Ngọc Duy
  12005 Johannes Schindelin
  10259 Michael Haggerty
   9389 Linus Torvalds
   8318 Brandon Williams
   7776 Stefan Beller
   5947 Christian Couder
   4935 René Scharfe

which seems reasonable.

-Peff

Re: Measuring Community Involvement (was Re: Contributor Summit planning)

[Stefan Beller]

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?

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

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/

Re: Measuring Community Involvement (was Re: Contributor Summit planning)

[Jeff King]

On Tue, Aug 14, 2018 at 12:47:59PM -0700, Stefan Beller wrote:

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

For our project, yes. But I was thinking of a tool that could be used
for other projects, too.

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

He wanted grouping by committer, which we ended up adding as a separate
feature. I think there's some discussion of the trailer thing in that
thread.

-Peff

Re: Measuring Community Involvement (was Re: Contributor Summit planning)

[Eric Wong]

Jeff King <peff@peff.net> wrote:
> 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.

Nothing prevents public-inbox from being adopted by other projects :)
Fwiw, Linux Foundation has LKML at https://lore.kernel.org/lkml

Re: Measuring Community Involvement (was Re: Contributor Summit planning)

[Junio C Hamano]

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) ;-)

Re: Measuring Community Involvement (was Re: Contributor Summit planning)

[Johannes Schindelin]

Hi Junio,

On Tue, 14 Aug 2018, Junio C Hamano wrote:

> 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) ;-)

And if you do not remember precisely, you can easily re-run `Linus` from
here: https://github.com/git/git/blob/todo/Linus

Ciao,
Dscho

Re: Measuring Community Involvement (was Re: Contributor Summit planning)

[Duy Nguyen]

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

Re: Measuring Community Involvement (was Re: Contributor Summit planning)

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]

Hi Duy,

On Wed, 15 Aug 2018, Duy Nguyen wrote:

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

Not really, as there is a high percentage of "on a tangent" replies in
many, many patch threads.

Ciao,
Dscho

Re: Contributor Summit planning

[Duy Nguyen]

On Mon, Aug 13, 2018 at 11:06 PM Jeff King <peff@peff.net> 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. :)

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

Re: Contributor Summit planning

[Jeff King]

On Tue, Aug 14, 2018 at 04:30:09PM +0200, Duy Nguyen wrote:

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

Since when? Junio still has everyone beat for all time, though of course
he cheats with easy ones like "update version field to v2.17.1". :)

I also sometimes look at "shortlog -ns --no-merges v2.17.0..v2.18.0" and
so on (i.e., each major release). I had a good run from about v2.10 to
v2.15, but I've been slipping since then.

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

I think "surviving lines" is another interesting metric, though it also
has flaws (if I s/sha1/oid/ on your line, it becomes my line; even
though my change is useful and should be counted, it's probably not as
important as whatever the code was doing in the first place).

-Peff

Re: Contributor Summit planning

[Stefan Beller]

On Tue, Aug 14, 2018 at 7:47 AM Jeff King <peff@peff.net> wrote:

>
> 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 could take all topics and see if you have at least one commit in there.
But that would mostly measure how much of an allrounder you are in the
code base (e.g. bug or style fixes such as Ramsay's "please squash this"
would be in many topics if not squashed).

There are other players who are very deep into one area of the code,
and probably have fewer series.

> I think "surviving lines" is another interesting metric, though it also
> has flaws (if I s/sha1/oid/ on your line, it becomes my line; even
> though my change is useful and should be counted, it's probably not as
> important as whatever the code was doing in the first place).

I wonder if we could measure the entropy added to the code base instead.
A patch that does s/sha1/oid/ (or introduction of a repository argument)
might compress very well, whereas new code might not compress very
well. ;-)

Re: Contributor Summit planning

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

Yes, a fix by somebody else to a bug that was recently introduced is
safest to apply to the original topic and merge down; that way makes
it more difficult to merge the original topic to older maintenance
track(s) without the fix by mistake.  So a "topic" with commits from
multiple people is not all that unusual.

Thanks.

Re: Contributor Summit planning

[Duy Nguyen]

On Mon, Aug 13, 2018 at 10:42 PM Stefan Beller <sbeller@google.com> wrote:
> Ævar specifically pointed out that we might want to hear from you and Duy
> if you want to attend a conference and if so how we can make that happen
> (by choosing location/time/setting appropriately) IIUC.

Since my name shows up... I'm with Elijah on the travel resistance
thing (and am probably even lazier than him). I guess I will remain
the mystery in the git circle.
-- 
Duy

Re: Contributor Summit planning

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

Hi AEvar,

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.

Ciao,
Dscho

Re: Contributor Summit planning

[Jeff King]

On Tue, Aug 28, 2018 at 12:49:55AM +0200, Johannes Schindelin wrote:

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

Thanks for bringing this up. It's very easy to forget that not everybody
is in exactly the same situation.

It's actually one of the things I worry _most_ about having an in-person
meeting: that it ends up widening the gap between people whose employer
is sponsoring their work on Git, and people who have to carve their Git
time out of the rest of their busy lives.

Your virtual meeting idea is obviously meant to help with that. But
fundamentally I think allowing people to participate asynchronously is
the most important part, and we need to make sure there's some kind of
artifact summarizing any real-time meetings (for virtual stuff,
recordings or IRC logs are probably fine; for the in-person one, I was
very happy with the notes you took last year).

-Peff

Re: Contributor Summit planning

[Elijah Newren]

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

RE: Contributor Summit planning

[Randall S. Becker]

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

Cheers,
Randall

Re: Contributor Summit planning

[Ævar Arnfjörð Bjarmason]

On Tue, Aug 14 2018, Randall S. Becker wrote:

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

Re: Contributor Summit planning

[Jeff King]

On Tue, Aug 14, 2018 at 04:06:23PM +0200, Ævar Arnfjörð Bjarmason wrote:

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

Amen.

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

I've bugged people privately in the past to see if they want to come,
and I think the limiting factor is usually just time/effort to travel.

-Peff

Re: Contributor Summit planning

[Jeff King]

On Tue, Aug 14, 2018 at 09:25:41AM -0400, Randall S. Becker wrote:

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

You'd definitely be welcome.

The point of having it "only developers" is mostly to keep the numbers
at a point where we can all sit around and have round-table discussions.
I don't think there are so many people at the fringe of "well, I only
have a few commits, is that enough?" for us to need to make any kind of
serious cut-off there.

What I think we want to avoid is random folks in the "I use Git, and it
would be neat to see people talk about it" camp. It would be nice to
accommodate that (and it might even manage to suck somebody into working
on the project). But that opens up a much larger pool of people, and if
(say) a hundred of them want to come, that wrecks the intimate
round-table approach.

That's all just my opinion, of course. I'm open to suggestions.

-Peff

Re: Contributor Summit planning

[Johannes Schindelin]

Hi Peff,

On Mon, 13 Aug 2018, Jeff King 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?

I cannot speak for "the people", but for myself: Brussels is an ideal
location *for me*. I would probably be unable to physically go to a
second, in-person meeting in the same year, but I would of course love to
attend remotely.

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

I guess I went off on a tangent here...

Ciao,
Dscho

Re: Contributor Summit planning

[Jeff King]

On Mon, Aug 27, 2018 at 03:34:16PM +0200, Johannes Schindelin wrote:

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

Thanks for your input. For what it's worth, that largely matches my
opinion, too. Most of the ideas I threw out there were just trying to
stimulate discussion (except for the spaghetti buffet, for which I am
a true believer).

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

-Peff

Re: Contributor Summit planning

[Johannes Schindelin]

Hi Peff,

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.

Ciao,
Dscho

Re: Contributor Summit planning

[Jeff King]

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.

-Peff

Re: Contributor Summit planning

[Johannes Schindelin]

Hi Peff,

On Wed, 29 Aug 2018, Jeff King wrote:

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

Well, proper mentoring *is* time-consuming. It is not like you're just
waiting for code to review, then do exactly the same as on the Git mailing
list. That'd not be mentoring. That'd be called "reviewing".

I still struggle, personally, to improve my mentoring skills, and at the
same time, I find it rewarding and I learn a lot. So I guess you can count
me in when it comes to Outreachy.

Ciao,
Dscho

Contributor Summit planning

[Jeff King]

The Git Merge Contributor Summit is scheduled for this coming Wednesday,
March 7th, in Barcelona.

If you're not registered, there are still one or two slots left for
last-minute attendees. Please email me if you're interested.

As in past years, I plan to run it like an unconference. Attendees are
expected to bring topics for group discussion. Short presentations are
also welcome. We'll put the topics on a whiteboard in the morning, and
pick whichever ones people are interested in.

Feel free to reply to this thread if you want to make plans or discuss
any proposed topics before the summit. Input or questions from
non-attendees is welcome here.

The rest of this email is all logistics for attendees, so if you're not
coming, you can stop reading. :)

There should be breakfast available in the contributor summit room
starting at 9am, so plan to get there around then, mingle and eat, and
then we'll start in earnest at 10am.

Registration is at the main Git Merge event space (Convent dels Àngels
at MACBA), and then our contributor summit space is across the street.
So go to the main registration first, and then signs and clueful staff
should be able to point you to the contributor summit room.

We have the space until 5pm, so we'll go until then or until we run out
of stuff to say, whichever comes first. Lunch will be served in the
room, and we'll probably take a few informal breaks during the day.

After we finish for the day, there are a few other events. Bitbucket is
hosting drinks and discussion from 5:30-7:30pm, open to all Git Merge
attendees (not just contributor summit people). Details and RSVP at:

  https://www.bevylabs.com/events/details/bevy-beers-with-bitbucket-presents-beers-with-bitbucket#/

Microsoft is sponsoring a dinner that evening at 8pm for just
contributor summit attendees. Details will be provided at the summit.

I look forward to seeing everybody there!

-Peff

Re: Contributor Summit planning

[Jeff King]

On Sat, Mar 03, 2018 at 05:30:10AM -0500, Jeff King wrote:

> As in past years, I plan to run it like an unconference. Attendees are
> expected to bring topics for group discussion. Short presentations are
> also welcome. We'll put the topics on a whiteboard in the morning, and
> pick whichever ones people are interested in.
> 
> Feel free to reply to this thread if you want to make plans or discuss
> any proposed topics before the summit. Input or questions from
> non-attendees is welcome here.

I'll plan to offer two topics:

 - a round-up of the current state and past year's activities of Git as
   a member project of Software Freedom Conservancy

 - some updates on the state of the git-scm.com since my report last
   year

As with last year, I'll try to send a written report to the list for
those who aren't at the summit in person.

-Peff

Re: Contributor Summit planning

[Derrick Stolee]

On 3/3/2018 5:39 AM, Jeff King wrote:
> On Sat, Mar 03, 2018 at 05:30:10AM -0500, Jeff King wrote:
>
>> As in past years, I plan to run it like an unconference. Attendees are
>> expected to bring topics for group discussion. Short presentations are
>> also welcome. We'll put the topics on a whiteboard in the morning, and
>> pick whichever ones people are interested in.
>>
>> Feel free to reply to this thread if you want to make plans or discuss
>> any proposed topics before the summit. Input or questions from
>> non-attendees is welcome here.
> I'll plan to offer two topics:
>
>   - a round-up of the current state and past year's activities of Git as
>     a member project of Software Freedom Conservancy
>
>   - some updates on the state of the git-scm.com since my report last
>     year
>
> As with last year, I'll try to send a written report to the list for
> those who aren't at the summit in person.
>
> -Peff

Thanks for putting this together, Peff.

I'll be ready to talk about the serialized commit graph [1], generation 
numbers, and other commit-walk optimizations.

Thanks,
-Stolee

[1] 
https://public-inbox.org/git/1519698787-190494-1-git-send-email-dstolee@microsoft.com/T/#u

Re: Contributor Summit planning

[Brandon Williams]

On 03/03, Jeff King wrote:
> On Sat, Mar 03, 2018 at 05:30:10AM -0500, Jeff King wrote:
> 
> > As in past years, I plan to run it like an unconference. Attendees are
> > expected to bring topics for group discussion. Short presentations are
> > also welcome. We'll put the topics on a whiteboard in the morning, and
> > pick whichever ones people are interested in.
> > 
> > Feel free to reply to this thread if you want to make plans or discuss
> > any proposed topics before the summit. Input or questions from
> > non-attendees is welcome here.
> 
> I'll plan to offer two topics:
> 
>  - a round-up of the current state and past year's activities of Git as
>    a member project of Software Freedom Conservancy
> 
>  - some updates on the state of the git-scm.com since my report last
>    year
> 
> As with last year, I'll try to send a written report to the list for
> those who aren't at the summit in person.

Thanks for kicking things off!

Since I've been working on protocol stuff I'd like to spend a bit of
time discussing protocol v2 :)

-- 
Brandon Williams

Re: Contributor Summit planning

[Lars Schneider]

> On 03 Mar 2018, at 11:39, Jeff King <peff@peff.net> wrote:
> 
> On Sat, Mar 03, 2018 at 05:30:10AM -0500, Jeff King wrote:
> 
>> As in past years, I plan to run it like an unconference. Attendees are
>> expected to bring topics for group discussion. Short presentations are
>> also welcome. We'll put the topics on a whiteboard in the morning, and
>> pick whichever ones people are interested in.
>> 
>> Feel free to reply to this thread if you want to make plans or discuss
>> any proposed topics before the summit. Input or questions from
>> non-attendees is welcome here.
> 
> I'll plan to offer two topics:
> 
> - a round-up of the current state and past year's activities of Git as
>   a member project of Software Freedom Conservancy
> 
> - some updates on the state of the git-scm.com since my report last
>   year
> 
> As with last year, I'll try to send a written report to the list for
> those who aren't at the summit in person.

Thanks for starting this. I would like to propose the following topics:

- hooks: Discuss a proposal for multiple local Git hooks of the same type.

- error reporting: Git is distributed and therefore lots of errors are only
  reported locally. That makes it hard for administrators in larger 
  companies to see trouble. Would it make sense to add a config option that 
  would push recent errors along with "git push" to the server?

- fuzzing: Would it make sense to register Git to Google's OSS fuzzing
  program https://github.com/google/oss-fuzz ?


- Lars

Re: Contributor Summit planning

[Jonathan Nieder]

Lars Schneider wrote:

> Thanks for starting this. I would like to propose the following topics:

Cool!  Do you mind starting threads for these so people who aren't there
can provide input into the discussion, too?  In other words, I'm
imagining

 1. Thread starts on mailing list

 2. Contributor summit: in-person presentation, discussion, etc lead to
    people having better ideas

 3. On-list thread goes really well as a result of aforementioned
    in-person discussion

Quick feedback:

> - hooks: Discuss a proposal for multiple local Git hooks of the same type.

I'd be happy to weigh in on a mailing list thread about this.  It's
also related to
https://public-inbox.org/git/20171002234517.GV19555@aiede.mtv.corp.google.com/
which is an interest of mine.

> - error reporting: Git is distributed and therefore lots of errors are only
>   reported locally. That makes it hard for administrators in larger
>   companies to see trouble. Would it make sense to add a config option that
>   would push recent errors along with "git push" to the server?

I'm interested in instrumentation but worried about the privacy
ramifications of this particular proposal.  I'd be happy to see some
built-in instrumentation hooks (or even a standard instrumentation
approach, if the mailing list comes up with a good one that respects
privacy).

> - fuzzing: Would it make sense to register Git to Google's OSS fuzzing
>   program https://github.com/google/oss-fuzz ?

Of course!

Alongside the obvious security benefit, there is money available to
support someone working on this:
https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html
https://www.google.com/about/appsecurity/patch-rewards/ clarifies that
the reward goes to the contributor, so you don't even necessarily have
to share your reward with the Git project. ;-)

Thanks,
Jonathan

Re: Contributor Summit planning

[Ævar Arnfjörð Bjarmason]

On Mon, Mar 05 2018, Jonathan Nieder jotted:

> Lars Schneider wrote:
>> - error reporting: Git is distributed and therefore lots of errors are only
>>   reported locally. That makes it hard for administrators in larger
>>   companies to see trouble. Would it make sense to add a config option that
>>   would push recent errors along with "git push" to the server?
>
> I'm interested in instrumentation but worried about the privacy
> ramifications of this particular proposal.  I'd be happy to see some
> built-in instrumentation hooks (or even a standard instrumentation
> approach, if the mailing list comes up with a good one that respects
> privacy).

I have this use-case as well, and figured a good approach would be:q

 1. Add corresponding config variables for GIT_TRACE_* so you could
    config them in /etc/gitconfig (or elsewhere). Similar to
    e.g. user.name & GIT_AUTHOR_NAME

 2. Add some new trace like e.g. GIT_TRACE_COMMANDS, make it take a
    format string in GIT_TRACE_COMMANDS_FORMAT (or usually via
    config). Thus setting GIT_TRACE_COMMANDS to a file would e.g. spew
    your current repo path, subcommand, or even the absolute command
    line to the file.

 3. Have some cronjob or other monitoring thingy pick up the file &
    submit to central logging.

Of course you could overdo the format specifiers in #2 and e.g. send the
full commands along, but it seems to me that it would be sufficient for
privacy concerns to document that caveat with some examples.

After all, for this use-case we're talking about us somehow guarding
against a sysadmin who can just install a /etc/profile.d/git_wrapper
anyway that'll log everything you do with git, or even provide a custom
git binary, so it's always going to be left to their best judgement.

Re: Contributor Summit planning

[Ævar Arnfjörð Bjarmason]

On Mon, Mar 05 2018, Lars Schneider jotted:

>> On 03 Mar 2018, at 11:39, Jeff King <peff@peff.net> wrote:
>>
>> On Sat, Mar 03, 2018 at 05:30:10AM -0500, Jeff King wrote:
>>
>>> As in past years, I plan to run it like an unconference. Attendees are
>>> expected to bring topics for group discussion. Short presentations are
>>> also welcome. We'll put the topics on a whiteboard in the morning, and
>>> pick whichever ones people are interested in.
>>>
>>> Feel free to reply to this thread if you want to make plans or discuss
>>> any proposed topics before the summit. Input or questions from
>>> non-attendees is welcome here.
>>
>> I'll plan to offer two topics:
>>
>> - a round-up of the current state and past year's activities of Git as
>>   a member project of Software Freedom Conservancy
>>
>> - some updates on the state of the git-scm.com since my report last
>>   year
>>
>> As with last year, I'll try to send a written report to the list for
>> those who aren't at the summit in person.
>
> Thanks for starting this. I would like to propose the following topics:
>
> - hooks: Discuss a proposal for multiple local Git hooks of the same type.

I'm assuming you mean having stuff like pre-receive.d/* in addition to
pre-receive:

I had a WIP series for this that I didn't end up pursuing after getting
discouraged at:
https://public-inbox.org/git/CACBZZX6j6q2DUN_Z-Pnent1u714dVNPFBrL_PiEQyLmCzLUVxg@mail.gmail.com/

There's various bolt-on solutions that do this for subsets of the hooks,
e.g. GitLab now has this at
https://docs.gitlab.com/ee/administration/custom_hooks.html and this
stand-alone solution:
https://gist.github.com/carlos-jenkins/89da9dcf9e0d528ac978311938aade43

I still think this would be great to have, but Junio's objection being:

> Junio: And I have to say that a sequential execution that always
> Junio: short-circuits at the first failure is below that threshold.
> Junio:
> Junio: One reason I care about allowing the users to specify "do not
> Junio: shortcut" is that I anticipate that people would want to have a
> Junio: logging of the result at the end of the chain.

Got me discouraged, it would have made the implementation a bit more
complex, and I found other solutions to the problem I was trying to
solve.

Now we use Gitlab's implementation of this which has the semantics I
proposed at the time, and you just put log hooks at the beginning, but
of course that's server-side only. Having this be generally usable in
git would be great.

Re: Contributor Summit planning

[Ævar Arnfjörð Bjarmason]

On Sat, Mar 03 2018, Jeff King jotted:

> Feel free to reply to this thread if you want to make plans or discuss
> any proposed topics before the summit. Input or questions from
> non-attendees is welcome here.

1)

Last year we discussed the general topic of performance. That's of
course very general, and can touch multiple unrelated areas of git
(worktree 'status' performance, all things protocol, storing big
objects, graph traversal, etc.).

No doubt others will propose other topics we'd want to carve out into
their own discussions (e.g. I'm expecting the v2 protocol to be one such
topic), but it'll be nice to have something that brings everyone
up-to-date on what the status is for purposes of coordination &
collaboration.

2)

I doubt many are interested in these as topics during the contributor
summit (but will propose them on the board if others care), but I have a
couple of things that touch quite a lot of things that I'm going to get
around to working on (or have in some WIP state):

 - PCRE-ification & PCRE convert:

   a) Use the interface recently added to PCRE to use it also for basic &
      extended POSIX regexps. This speeds things up a lot

   b) See if we can use PCRE (or at least extended regexp) consistently in
      the rest of git via single interface. Relevant code:

      git grep '\b(regcomp|regexec)\b' -- '*.[ch]'

   c) Maybe if we like a) && b) enough for performance reasons we'd be
     happy to make PCRE a hard dependency, and would then ship with a
     compat/pcre2 (~80k lines) instead of the current ancient (and hard
     to update) compat/regex/* (~10k lines).

 - Adding the ability to optionally read a .gitconfig shipped with the
   repo, see
   https://public-inbox.org/git/87zi6eakkt.fsf@evledraar.gmail.com/