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
- 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
- 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
- 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
- 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
I do not think the council should be responsible for:
- day-to-day code reviews / operation (this is running enough fine as it
- 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
-------------- next part --------------
An HTML attachment was scrubbed...