[Matplotlib-devel] Steering council bootstrapping

[Ryan May]

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 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
>


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