Git Project Leadership Committee

Git Project Leadership Committee

[Jeff King]

This is a followup to the issue I raised back in March[1], which is
that our project committee at Software Freedom Conservancy has two
members, but is required by the charter to have at least three.

There wasn't any substantive discussion in response to that email or at
the contributor summit. I intentionally left my own opinions out of that
mail to avoid biasing discussion, and meant to follow-up after everyone
had a chance to speak. I didn't intend to leave it this long, though. :)

Just to recap: the project leadership committee (PLC) represents the Git
project within Conservancy and decides on project-specific matters,
including allocation of funds. Since joining in 2010, the PLC consisted
of me, Junio, and Shawn Pearce.  With Shawn's passing, we need to elect
another member (by simple majority of the remaining members) to meet our
minimum number of three.

You can get a sense of the types of issues and decisions from looking at
my report in [1], as well as past-year reports linked from there. If you
want a more precise picture of the day-to-day, it's mostly just
monitoring and discussing things on a project-specific mailing list that
gets an average of about 2-4 messages per month (usually one thread
every month or two). I'm happy to answer any other questions people have
about it.

Here are _my_ opinions on how we should fill the role. As 50% of the
voting populace, it's perhaps a disproportionately important opinion,
but I really would like to hear and take into account opinions from the
larger development community.

 - it should probably be somebody who has been with the project for a
   while (so we feel comfortable that they are representative) and that
   we expect to stay with the project for a while (so we're not doing
   this again in 6 months). But those are negotiable. It's not the worst
   thing for somebody to serve for a year or two and then move on.

 - we should avoid anyone who is affiliated with a company that already
   has a member on the committee. So nobody from Google and nobody from
   GitHub. I would extend that to Microsoft, too, given a certain
   impending acquisition. I'd expect anybody who is affiliated with a
   company to recuse themselves from decisions that directly affect that
   company (which is what we've done so far).

 - I think ideally the candidate would be somebody who represents the
   long tail of volunteer community members who don't work on Git as
   part of their day-job. The current members have a fairly skewed view
   in that respect. At the same time, we can't really represent the
   _really_ long tail of infrequent contributors, by the "stick around"
   criterion above.

 - I considered mostly people who have expressed interest in non-code
   issues (e.g., GSoC, money policy, etc). But I don't think that's a
   strict requirement if somebody is interested.

 - We're not restricted to three members. So we could add multiple
   people. Four may be bad because it creates ties. On the other hand,
   every decision so far has been unanimous. :)

So here are the nominations I came up with. If you'd like to nominate
somebody else (or yourself!), please do. If you have opinions, let me
know (public or private, as you prefer).

 - Christian Couder
 - Ævar Arnfjörð Bjarmason

Both are active, have been around a long time, and have taken part in
non-code activities and governance discussions. My understanding is that
Christian freelances on Git, which doesn't quite fit my "volunteer
representative" request, but I think contracting on Git is its own
interesting perspective to represent (and certainly he spent many years
on the volunteer side).

Phew. That turned out a little longer than I meant it to be, but I
wanted to lay out my thought process, both for this decision and because
we may eventually have to do this again in the future.

-Peff

[1] https://public-inbox.org/git/20180306231609.GA1632@sigill.intra.peff.net/

Re: Git Project Leadership Committee

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Here are _my_ opinions on how we should fill the role....
> ...
> So here are the nominations I came up with. If you'd like to nominate
> somebody else (or yourself!), please do. If you have opinions, let me
> know (public or private, as you prefer).
>
>  - Christian Couder
>  - Ævar Arnfjörð Bjarmason

FWIW, even though my opinions might be slightly different in some
detail (e.g. I would not place as much weight on "ideally a
non-professional person" as Peff does), I pretty-much agree with
Peff on both the selection criteria and the nominations.

Thanks.

Re: Git Project Leadership Committee

[Elijah Newren]

On Thu, Aug 16, 2018 at 3:43 PM Jeff King <peff@peff.net> wrote:
>  - we should avoid anyone who is affiliated with a company that already
>    has a member on the committee. So nobody from Google and nobody from
>    GitHub. I would extend that to Microsoft, too, given a certain
>    impending acquisition. I'd expect anybody who is affiliated with a
>    company to recuse themselves from decisions that directly affect that
>    company (which is what we've done so far).

That might make it hard for some of us to nominate others, since as
far as I can tell (e.g. looking at shortlog -sne output) few git
contributors use work email addresses to do so and we don't
necessarily know employers of other contributors.

> So here are the nominations I came up with. If you'd like to nominate
> somebody else (or yourself!), please do. If you have opinions, let me
> know (public or private, as you prefer).
>
>  - Christian Couder
>  - Ævar Arnfjörð Bjarmason

I think either of them would be excellent choices.

Re: Git Project Leadership Committee

[Jeff King]

On Sat, Aug 18, 2018 at 07:32:38PM -0700, Elijah Newren wrote:

> On Thu, Aug 16, 2018 at 3:43 PM Jeff King <peff@peff.net> wrote:
> >  - we should avoid anyone who is affiliated with a company that already
> >    has a member on the committee. So nobody from Google and nobody from
> >    GitHub. I would extend that to Microsoft, too, given a certain
> >    impending acquisition. I'd expect anybody who is affiliated with a
> >    company to recuse themselves from decisions that directly affect that
> >    company (which is what we've done so far).
> 
> That might make it hard for some of us to nominate others, since as
> far as I can tell (e.g. looking at shortlog -sne output) few git
> contributors use work email addresses to do so and we don't
> necessarily know employers of other contributors.

I would say to err on the side of nominating, and the candidate can
provide the information.

-Peff

Re: Git Project Leadership Committee

[Ævar Arnfjörð Bjarmason]

On Thu, Aug 16 2018, Jeff King wrote:

>  - Christian Couder
>  - Ævar Arnfjörð Bjarmason

Thanks for the nomination. I'm happy to help the project by serving on
the leadership committee if you'll have me.

> Both are active, have been around a long time, and have taken part in
> non-code activities and governance discussions. My understanding is that
> Christian freelances on Git, which doesn't quite fit my "volunteer
> representative" request, but I think contracting on Git is its own
> interesting perspective to represent (and certainly he spent many years
> on the volunteer side).

I'd say I'd mostly be a "volunteer representative", but in the interest
of full disclosure here's the extent to which I'm not.

I'm involved in internal Git infrastructure at my employer, Booking.com,
and some of the the work I do on git is company sponsored, since it
happens to be stuff Booking.com needs from git. E.g. my recent
fetch.fsck.* series is one example of that, as well as the
"fetch.pruneTags" option in 2.17.

Booking.com doesn't really have any sort of git.git infrastructure team
in the sense that Microsoft & GitHub do. I'm on the team which, among
other things, manages our internal GitLab installation and git-related
things in general.

I'm trusted to spend company time on patching git when that's the
easiest or best way to accomplish some task. Usually I don't even
discuss the specifics of that with anyone, I just go ahead and do it.

I'm not aware of Booking.com, or its parent company Booking Holdings (or
sister companies) in any way being involved in any business model that
involves Git (unlike say GitHub, Atlassian etc).

So I can't imagine any situation where I'd need to recuse myself due to
real or perceived conflict of interest, but would of course do so if
there was even the appearance of impropriety.

Booking.com has also had a contract with Christian Couder to work on
things in git.git since 2015-ish. E.g. the rebase speedups Christian did
and the ongoing work on reftables is paid for by Booking.com.

During this time I've been the person tasked with managing the work that
Christian is doing on git.git for Booking.com, in a very loose sense of
"managing". It's usually just e.g. "hey rebase performance kind of
sucks, can you work on it?" "sure!".

I know Christian also does contract work for GitLab, e.g. I understand
that his delta island integration work these days is done on their
behalf, but I'll let him provide details on that or any other corporate
entanglements he may have to the extent he feels it's relevant.

Re: Git Project Leadership Committee

[Christian Couder]

On Fri, Aug 17, 2018 at 12:41 AM, Jeff King <peff@peff.net> wrote:

> So here are the nominations I came up with. If you'd like to nominate
> somebody else (or yourself!), please do. If you have opinions, let me
> know (public or private, as you prefer).
>
>  - Christian Couder
>  - Ævar Arnfjörð Bjarmason

Thanks for nominating both!

> Both are active, have been around a long time, and have taken part in
> non-code activities and governance discussions. My understanding is that
> Christian freelances on Git, which doesn't quite fit my "volunteer
> representative" request, but I think contracting on Git is its own
> interesting perspective to represent (and certainly he spent many years
> on the volunteer side).

Yeah, I am freelancing since October 2015 mostly for GitLab,
Booking.com and Protocol Labs as can be seen on my LinkedIn profile:

https://www.linkedin.com/in/christian-couder-569a731/

I feel lucky to be considered mostly like a regular employee
especially by GitLab and Protocol Labs. Both of these companies employ
a high ratio of remote developers from around the world, who often
have some kind of freelance legal status, so they give them as much as
possible the same kind of perks or incentives (like stock options) as
regular employees.

GitLab is a very open and transparent company. The way it works is
described in details in its Handbook
(https://about.gitlab.com/handbook/). Its informal policy regarding
Git has been to use regular released versions of Git in GitLab. If
possible GitLab should use a recent version of Git to benefit from the
latest improvements, though it should be compatible with old versions
of Git, as this can be useful for example to people who want to build
GitLab from source on top of a regular Linux distro that comes with an
old Git.

So for GitLab my work on Git has to be integrated upstream. I have
been working on remote odb related things, which I haven't managed to
get merged yet, and on a few other small things like delta islands for
which things have been going better so far.

I also do some Git support at GitLab (for Git users, GitLab
developers, customers, sales people, ...). I am sponsored by them to
participate in or give presentations at conferences (like FOSSASIA
2017, GSoC Mentor Summit, Bloomberg Hackathon, Git Merge, GitLab
Summit, ...). And sometimes I do other marketing, security, developer
relations or sales (like meeting a few French customers) related
things.

Ævar already talked in details about Booking.com and my work for them.

I have been working much less for Protocol Labs than for GitLab or
Booking.com since I started working for GitLab around 2 years ago.

As with Git I had started working on my free time on IPFS
(https://ipfs.io/) before I became a freelance working on it. So for
Protocol Labs I have been using Sharness
(https://github.com/chriscool/sharness/, which was created in 2011 by
extracting t/test-lib.sh from Git) to add and maintain end to end
tests to go-IPFS and other IPFS related projects.

Around one year ago Protocol Labs made a successful ICO (Initial Coin
Offering) for Filecoin (https://filecoin.io/) and since then things
have become a bit more like in a regular company (which is not
necessarily bad).

I have also had a few consulting contracts from various French
companies for a few days each about consulting or teaching Git/GitLab.

Re: Git Project Leadership Committee

[Jeff King]

On Thu, Aug 16, 2018 at 06:41:38PM -0400, Jeff King wrote:

>  - we should avoid anyone who is affiliated with a company that already
>    has a member on the committee. So nobody from Google and nobody from
>    GitHub. I would extend that to Microsoft, too, given a certain
>    impending acquisition. I'd expect anybody who is affiliated with a
>    company to recuse themselves from decisions that directly affect that
>    company (which is what we've done so far).
> 
>  - I think ideally the candidate would be somebody who represents the
>    long tail of volunteer community members who don't work on Git as
>    part of their day-job. The current members have a fairly skewed view
>    in that respect. At the same time, we can't really represent the
>    _really_ long tail of infrequent contributors, by the "stick around"
>    criterion above.

Thanks both Christian and Ævar for giving more details on your
situations elsewhere in the thread. I do think neither of you is quite
in the "I just do this in my spare time" situation. But I also think
that situation is going to be inversely correlated with being active in
the project and wanting to spend time on governance stuff. So IMHO some
compromise there is necessary. And I feel like both of you can represent
those interests, even if they're not exactly the situation you're in.

So what next?

There was a little bit of off-list discussion (mostly nominations to
avoid putting the candidate on the spot), but no new public candidates.
I'm happy to entertain more discussion here, but it seems like everybody
is reasonably happy with these two names.

So either Junio and I can pick one, or possibly we could have both (that
gives us a 4-person committee, but again, tied votes haven't been an
issue so far).

Any final thoughts are welcome.

Also, on a more meta-level, I'm happy to hear any thoughts about this
process that we might want to enshrine for later iterations. This is
obviously not nearly as formal as something like Debian elections. But I
don't think we're a big enough community to need that. So my attempt is
to just keep things informal, but try to give as many opportunities as
possible for people to speak up.

-Peff