[Matplotlib-devel] Steering council bootstrapping

[Eric Firing]

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 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
>     Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
>     https://mail.python.org/mailman/listinfo/matplotlib-devel
> 
> 
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>