Steering council bootstrapping

Folks,

I have opened https://github.com/matplotlib/governance/pull/5 to start the
process of filling out the steering council with Eric Firing and Ryan May
being the first 2 people on it. I would like Ryan and Eric to publicly
accept (I asked them privately already) and then we can merge that PR and
have non-trivial steering council!

The first order of business is to sort out what we want the steering
council to look like long term.

Our current governance documents are modeled on jupyter, but I think we
should diverge a bit.

- I would like to think of being on the council as a responsibility /
obligation / service rather than an honor or acknowledgement of previous
work to the community (we also need to pin down what work the council has
to do :wink: )
- cap the size of the council to 5 or 7. Much bigger, it gets unweilding
to schedule things / get things done, much smaller we may not capture the
diversity perspective we need. The requirement of odd came up in some of
the core python discussion if you let "the status queue" have a vote, but I
still lean towards an odd number as then it is BDFL + even number (see
below).
- have terms on the council (2 - 3 years?). If we cap the size and want to
be able to bring new people on, we need a standard way to also roll people
off (as a physicist, conservation of numbers is very important to me).
This also gives people on the council a graceful way off if they want it.
Given the first point, it seems like a good idea to give people a time
horizon for what they have signed up for. I don't think we should have any
sort of term limits. 2-3 years seems short enough you can see the end, but
long enough to get stuff done (at our glacial pace!).
- We should stagger the terms so every were we do 2 on / 2 off (hence why I
like the odd number total). If we go with a 5 person council, terms would
be 2 years, if we go with 7 terms would be 3 years.
- follow the model NF used for their board election: completely open
nomination, endorsement by a small group (in their case, projects leads of
all the sponsored projects), and final selection be the existing board /
council. There are some details to work about about the middle group
(everyone with a commit bit? + a list of "power users" ? + leads of
important down-stream projects? + ??). Would it be the full council or the
remaining n-2 people for the final selection?
- have a named secretary responsible for making sure votes / decisions
happen
- not have any explicit limits on commits / activity / etc. Trust the
above process to pick the right people.
- I could see making the case both for and against have an "outside" person
on the council

In terms of responsibilities, I am thinking things like
- writing and managing grants
- organizing mettings / workshops
- CoC issues (sorting out what to do about CoC is the next order of
business)
- approving the distrobution of commit bits
- developing high-level road maps (things like "we should overhaul color
handling to better address X, Y, Z")
- sorting out what to spend money on (this includes the finance
sub-committee)
- sorting out process (do we want to revive / enforce MEPs? branching
details (maybe that is too in the weeds?))

[this may or may not be a list of things I have not done but feel I should
be doing]

I do not think the council should be responsible for:
- day-to-day code reviews / operation (this is running enough fine as it
is)
- detailed feature review / design (ex "Should we spell feature X of the
color overhaul as foo or bar" or "what color should the bike shed be") (do
not want to make the council a bottle neck in the implementation process).

I am not sure if this is better to discuss this on the mailing list or on
github. I lean towards mailing list for now until we start talking about
exact wordings of things.

Sorry this is all over the place in terms of high level / low level. I
have been thinking about this for a while and finally opted to get it out
of my head in what ever state it was in :wink:

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180921/5d33a5a7/attachment.html>

Thank you for taking care of this.

In general, I don't have a strong opinion about the setup of the steering
committee or its responsibilities. However, given that you mentioned CoC
issues, and based on the recent threads on numpy-discussion regarding
numpy's CoC and on python-dev regarding "import this", I believe that CoC
issues are perceived sufficiently differently on the two sides of the
Atlantic that I would like to propose that the SC should (aim to) include
at least one non-North-American member (also as there are quite a few of us
among the core devs).

Note that I am explicitly NOT making myself a candidate to a SC position.
I'm also perfectly happy with the current 3-member SC; this is simply a
suggestion for later additions to the SC.

Antony

···

On Fri, Sep 21, 2018 at 11:37 PM Thomas Caswell <tcaswell at gmail.com> wrote:

Folks,

I have opened ENH: Start to grow the steering council by tacaswell · Pull Request #5 · matplotlib/governance · GitHub to start
the process of filling out the steering council with Eric Firing and Ryan
May being the first 2 people on it. I would like Ryan and Eric to publicly
accept (I asked them privately already) and then we can merge that PR and
have non-trivial steering council!

The first order of business is to sort out what we want the steering
council to look like long term.

Our current governance documents are modeled on jupyter, but I think we
should diverge a bit.

- I would like to think of being on the council as a responsibility /
obligation / service rather than an honor or acknowledgement of previous
work to the community (we also need to pin down what work the council has
to do :wink: )
- cap the size of the council to 5 or 7. Much bigger, it gets unweilding
to schedule things / get things done, much smaller we may not capture the
diversity perspective we need. The requirement of odd came up in some of
the core python discussion if you let "the status queue" have a vote, but I
still lean towards an odd number as then it is BDFL + even number (see
below).
- have terms on the council (2 - 3 years?). If we cap the size and want
to be able to bring new people on, we need a standard way to also roll
people off (as a physicist, conservation of numbers is very important to
me). This also gives people on the council a graceful way off if they want
it. Given the first point, it seems like a good idea to give people a time
horizon for what they have signed up for. I don't think we should have any
sort of term limits. 2-3 years seems short enough you can see the end, but
long enough to get stuff done (at our glacial pace!).
- We should stagger the terms so every were we do 2 on / 2 off (hence why
I like the odd number total). If we go with a 5 person council, terms
would be 2 years, if we go with 7 terms would be 3 years.
- follow the model NF used for their board election: completely open
nomination, endorsement by a small group (in their case, projects leads of
all the sponsored projects), and final selection be the existing board /
council. There are some details to work about about the middle group
(everyone with a commit bit? + a list of "power users" ? + leads of
important down-stream projects? + ??). Would it be the full council or the
remaining n-2 people for the final selection?
- have a named secretary responsible for making sure votes / decisions
happen
- not have any explicit limits on commits / activity / etc. Trust the
above process to pick the right people.
- I could see making the case both for and against have an "outside"
person on the council

In terms of responsibilities, I am thinking things like
- writing and managing grants
- organizing mettings / workshops
- CoC issues (sorting out what to do about CoC is the next order of
business)
- approving the distrobution of commit bits
- developing high-level road maps (things like "we should overhaul color
handling to better address X, Y, Z")
- sorting out what to spend money on (this includes the finance
sub-committee)
- sorting out process (do we want to revive / enforce MEPs? branching
details (maybe that is too in the weeds?))

[this may or may not be a list of things I have not done but feel I should
be doing]

I do not think the council should be responsible for:
- day-to-day code reviews / operation (this is running enough fine as it
is)
- detailed feature review / design (ex "Should we spell feature X of the
color overhaul as foo or bar" or "what color should the bike shed be") (do
not want to make the council a bottle neck in the implementation process).

I am not sure if this is better to discuss this on the mailing list or on
github. I lean towards mailing list for now until we start talking about
exact wordings of things.

Sorry this is all over the place in terms of high level / low level. I
have been thinking about this for a while and finally opted to get it out
of my head in what ever state it was in :wink:

Tom
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180922/700a9eea/attachment-0001.html&gt;

I accept, thank you.

Eric

···

On 2018/09/21 11:34 AM, Thomas Caswell wrote:

I would like Ryan and Eric to publicly accept (I asked them privately
already) and then we can merge that PR and have non-trivial steering
council!

Independently of the CoC, I think that having at least one
non-North-American member is highly desirable.

Eric

···

On 2018/09/22 5:12 AM, Antony Lee wrote:

Thank you for taking care of this.

In general, I don't have a strong opinion about the setup of the
steering committee or its responsibilities.? However, given that you
mentioned CoC issues, and based on the recent threads on
numpy-discussion regarding numpy's CoC and on python-dev regarding
"import this", I believe that CoC issues are perceived sufficiently
differently on the two sides of the Atlantic that I would like to
propose that the SC should (aim to) include at least one
non-North-American member (also as there are quite a few of us among the
core devs).

Note that I am explicitly NOT making myself a candidate to a SC
position.? I'm also perfectly happy with the current 3-member SC; this
is simply a suggestion for later additions to the SC.

Antony

On Fri, Sep 21, 2018 at 11:37 PM Thomas Caswell <tcaswell at gmail.com > <mailto:tcaswell at gmail.com>> wrote:

    Folks,

    I have opened ENH: Start to grow the steering council by tacaswell · Pull Request #5 · matplotlib/governance · GitHub
    start the process of filling out the steering council with Eric
    Firing and Ryan May being the first 2 people on it.? I would like
    Ryan and Eric to publicly accept (I asked them privately already)
    and then we can merge that PR and have non-trivial steering council!

    The first order of business is to sort out what we want the steering
    council to look like long term.

    Our current governance documents are modeled on jupyter, but I think
    we should diverge a bit.

    - I would like to think of being on the council as a responsibility
    / obligation / service rather than an honor or acknowledgement of
    previous work to the community (we also need to pin down what work
    the council has to do :wink: )
    - cap the size of the council to 5 or 7.? Much bigger, it gets
    unweilding to schedule things / get things done, much smaller we may
    not capture the diversity perspective we need.? The requirement of
    odd came up in some of the core python discussion if you let "the
    status queue" have a vote, but I still lean towards an odd number as
    then it is BDFL?+ even number (see below).
    - have terms on the council (2 - 3 years?).? If we cap the size and
    want to be able to bring new people on, we need a standard way to
    also roll people off (as a physicist, conservation of numbers is
    very important to me).? This also gives people on the council a
    graceful way off if they want it.? Given the first point, it seems
    like a good idea to give people a time horizon for what they have
    signed up for.? I don't think we should have any sort of term
    limits.? 2-3 years seems short enough you can see the end, but long
    enough to get stuff done (at our glacial pace!).
    - We should stagger the terms so every were we do 2 on / 2 off
    (hence why I like the odd number total).? If we go with a 5 person
    council, terms would be 2 years, if we go with 7 terms would be 3 years.
    - follow the model NF used for their board election: completely open
    nomination, endorsement by a small group (in their case, projects
    leads of all the sponsored projects), and final selection be the
    existing board / council.? There are some details to work about
    about the middle group (everyone with a commit bit??+ a list of
    "power users" ??+ leads of important down-stream projects??+ ??).
    Would it be the full council or the remaining n-2 people for the
    final selection?
    - have a named secretary responsible for making sure votes /
    decisions happen
    - not have any explicit limits on commits / activity / etc.? Trust
    the above process to pick the right people.
    - I could see making the case both for and against have an "outside"
    person on the council

    In terms of responsibilities, I am thinking things like
     ?- writing and managing grants
     ?- organizing mettings / workshops
     ?- CoC issues (sorting out what to do about CoC is the next order
    of business)
     ?- approving the distrobution of commit bits
     ?- developing high-level road maps (things like "we should overhaul
    color handling to better address X, Y, Z")
     ?- sorting out what to spend money on (this includes the finance
    sub-committee)
     ?- sorting out process (do we want to revive / enforce MEPs?
    branching details (maybe that is too in the weeds?))

    [this may or may not be a list of things I have not done but feel I
    should be doing]

    I do not think the council should be responsible for:
     ?- day-to-day code reviews / operation? (this is running enough
    fine as it is)
     ?- detailed feature review / design (ex "Should we spell feature X
    of the color overhaul as foo or bar" or "what color should the bike
    shed be") (do not want to make the council a bottle neck in the
    implementation process).

    I am not sure if this is better to discuss this on the mailing list
    or on github.? I lean towards mailing list for now until we start
    talking about exact wordings of things.

    Sorry this is all over the place in terms of high level / low
    level.? I have been thinking about this for a while and finally
    opted to get it out of my head in what ever state it was in :wink:

    Tom
    _______________________________________________
    Matplotlib-devel mailing list
    Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
    Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

I accept. I agree as well about non-North America membership.

Ryan

···

On Fri, Sep 21, 2018 at 5:37 PM Thomas Caswell <tcaswell at gmail.com> wrote:

Folks,

I have opened ENH: Start to grow the steering council by tacaswell · Pull Request #5 · matplotlib/governance · GitHub to start
the process of filling out the steering council with Eric Firing and Ryan
May being the first 2 people on it. I would like Ryan and Eric to publicly
accept (I asked them privately already) and then we can merge that PR and
have non-trivial steering council!

The first order of business is to sort out what we want the steering
council to look like long term.

Our current governance documents are modeled on jupyter, but I think we
should diverge a bit.

- I would like to think of being on the council as a responsibility /
obligation / service rather than an honor or acknowledgement of previous
work to the community (we also need to pin down what work the council has
to do :wink: )
- cap the size of the council to 5 or 7. Much bigger, it gets unweilding
to schedule things / get things done, much smaller we may not capture the
diversity perspective we need. The requirement of odd came up in some of
the core python discussion if you let "the status queue" have a vote, but I
still lean towards an odd number as then it is BDFL + even number (see
below).
- have terms on the council (2 - 3 years?). If we cap the size and want
to be able to bring new people on, we need a standard way to also roll
people off (as a physicist, conservation of numbers is very important to
me). This also gives people on the council a graceful way off if they want
it. Given the first point, it seems like a good idea to give people a time
horizon for what they have signed up for. I don't think we should have any
sort of term limits. 2-3 years seems short enough you can see the end, but
long enough to get stuff done (at our glacial pace!).
- We should stagger the terms so every were we do 2 on / 2 off (hence why
I like the odd number total). If we go with a 5 person council, terms
would be 2 years, if we go with 7 terms would be 3 years.
- follow the model NF used for their board election: completely open
nomination, endorsement by a small group (in their case, projects leads of
all the sponsored projects), and final selection be the existing board /
council. There are some details to work about about the middle group
(everyone with a commit bit? + a list of "power users" ? + leads of
important down-stream projects? + ??). Would it be the full council or the
remaining n-2 people for the final selection?
- have a named secretary responsible for making sure votes / decisions
happen
- not have any explicit limits on commits / activity / etc. Trust the
above process to pick the right people.
- I could see making the case both for and against have an "outside"
person on the council

In terms of responsibilities, I am thinking things like
- writing and managing grants
- organizing mettings / workshops
- CoC issues (sorting out what to do about CoC is the next order of
business)
- approving the distrobution of commit bits
- developing high-level road maps (things like "we should overhaul color
handling to better address X, Y, Z")
- sorting out what to spend money on (this includes the finance
sub-committee)
- sorting out process (do we want to revive / enforce MEPs? branching
details (maybe that is too in the weeds?))

[this may or may not be a list of things I have not done but feel I should
be doing]

I do not think the council should be responsible for:
- day-to-day code reviews / operation (this is running enough fine as it
is)
- detailed feature review / design (ex "Should we spell feature X of the
color overhaul as foo or bar" or "what color should the bike shed be") (do
not want to make the council a bottle neck in the implementation process).

I am not sure if this is better to discuss this on the mailing list or on
github. I lean towards mailing list for now until we start talking about
exact wordings of things.

Sorry this is all over the place in terms of high level / low level. I
have been thinking about this for a while and finally opted to get it out
of my head in what ever state it was in :wink:

Tom
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

--
Ryan May
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180922/61e751a9/attachment-0001.html&gt;