[Matplotlib-devel] Steering council bootstrapping

[Antony Lee]

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 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
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180922/700a9eea/attachment-0001.html>