[Matplotlib-devel] Steering council bootstrapping

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Matplotlib-devel] Steering council bootstrapping

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

Tom

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: Steering council bootstrapping

Antony Lee-3
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 <[hidden email]> wrote:
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 ;) ) 
- 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 ;) 

Tom
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: Steering council bootstrapping

Eric Firing
In reply to this post by tcaswell
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!
>

I accept, thank you.

Eric
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: Steering council bootstrapping

Eric Firing
In reply to this post by Antony Lee-3
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 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     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 ;) )
>     - 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 ;)
>
>     Tom
>     _______________________________________________
>     Matplotlib-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

Re: Steering council bootstrapping

Ryan May-3
In reply to this post by tcaswell
I accept. I agree as well about non-North America membership.

Ryan

On Fri, Sep 21, 2018 at 5:37 PM Thomas Caswell <[hidden email]> wrote:
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 ;) ) 
- 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 ;) 

Tom
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


--
Ryan May


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel