<div dir="ltr">I accept. I agree as well about non-North America membership.<div><br></div><div>Ryan</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 21, 2018 at 5:37 PM Thomas Caswell <<a href="mailto:tcaswell@gmail.com">tcaswell@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Folks,<div><br></div><div>I have opened <a href="https://github.com/matplotlib/governance/pull/5" target="_blank">https://github.com/matplotlib/governance/pull/5</a> 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!</div><div><br></div><div>The first order of business is to sort out what we want the steering council to look like long term.  <br></div><div><br></div><div>Our current governance documents are modeled on jupyter, but I think we should diverge a bit. </div><div><br></div><div>- 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 ;) ) </div><div>- 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).  <br></div><div>- 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!).</div><div>- 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.</div><div>- 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?</div><div>- have a named secretary responsible for making sure votes / decisions happen</div><div>- not have any explicit limits on commits / activity / etc.  Trust the above process to pick the right people.</div><div>- I could see making the case both for and against have an "outside" person on the council</div><div><br></div><div>In terms of responsibilities, I am thinking things like</div><div> - writing and managing grants</div><div> - organizing mettings / workshops</div><div> - CoC issues (sorting out what to do about CoC is the next order of business)</div><div> - approving the distrobution of commit bits</div><div> - developing high-level road maps (things like "we should overhaul color handling to better address X, Y, Z")</div><div> - sorting out what to spend money on (this includes the finance sub-committee)</div><div> - sorting out process (do we want to revive / enforce MEPs? branching details (maybe that is too in the weeds?))</div><div><br></div><div>[this may or may not be a list of things I have not done but feel I should be doing]</div><div><br></div><div>I do not think the council should be responsible for:</div><div> - day-to-day code reviews / operation  (this is running enough fine as it is)</div><div> - 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).</div><div><br></div><div>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.  </div><div><br></div><div>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 ;) </div><div><br></div><div>Tom</div></div>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Ryan May<br><br></div></div></div>