Git Project Leadership Committee

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

 



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




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

  Powered by Linux