On Wed, Sep 23, 2015 at 12:40 PM, Nathaniel Smith <njs@pobox.com> wrote:
However, that had been contentious enough that it would probably be a good idea to hash out some guidelines about the council membership.
We actually do have some of those already -- dunno if they're perfect, but they exist :-).
know -- I guess I meant "expand the guidelines..." .. but thanks for putting it all here. Also, I think there was a slight disconnect between the guidelines and the proposed "seed" council, as it was only the seed, no biggie, but I think folks got the wrong impression.
Then there's some language emphasising that "contributions" should *not* be read narrowly as a euphemism for "lines of code".)
yeah, this got lost a bit somehow...
Leaving the council: Happens by choice of member, or if inactive for one year and can't be contacted, or if inactive for two years.
somehow this seem to have been interpreted as "inactive in contributing to code", rather than "inactive in council communication/activity" -- but two years seems pleanty long to me. Proposal for seed council: "everyone who's merged a pull request since
Jan 1, 2014".
I think it matters little how the council is seeded, as it can grow and change from there -- but maybe folks will feel better if we define a few other parameters -- after all, this wouldn't get you anyone that had made large non-code contributions to the project. We didn't talk much about these -- I think mostly on the theory that
the exact details really aren't going to matter much in the end.
agreed -- it's kind of a self-regulating Oligarchy...
My interpretation is that these rules were designed to produce a council consisting of a broad spectrum of contributors who are actively engaged, in tune and up-to-date with the issues currently facing the project, and broadly respected by the broader community.
yup -- that's what we want :-)
I'm a little wary of the idea of capping the council size.
... Judging whether
someone is or isn't a "substantial contributor" is fine, we can do that. Having to make a relative judgement of which of two people is the *more* "substantial contributor", though -- that sounds awful.
indeed it does -- tough problem.
And given how conflict-adverse groups can be, I suspect that capping the council size would in practice just have the effect that it never takes in new blood.
Another very valid concern. Started me thinking about term limits -- which is an even worse idea :-)
I'd be interested to hear what Jupyter/IPython's experience with this is, though: they currently have a 10 (!) person steering council,
me too. Though as you mention, not having to rely on consensus makes a larger group more tenable.
Someone(s) with a long history of working with the code -- that institutional memory of why decisions were made the way they were could be key.
Sure -- though I can't really imagine any way of framing a rule like this that *wouldn't* be satisfied by Chuck + Ralf + Pauli, so my guess is that such a rule would not actually have any effect on the council membership in practice.
well, as someone that has been around the community, and relied on numpy (and numarray, and Numeric before that) for I think 17 years, maybe I have a different idea of what "history" is. Though I honestly don't remember when the folks you names joined up... To be specific, someone with a memory of the Numeric -> numarray semi-disaster would be nice to have around... Though, as you've stated, plenty of opportunity for wise old souls to be consulted and contribute even if not actually on the council.
Someone(s) that may not have worked on the core code, but is a major player in the community, perhaps as the leader of a Numpy-dependent project. This would provide representation for the broad community.
Pointing out features of the current draft again for reference: In the current text, the "NumFOCUS subcommittee" does have an external member to provide some oversight. (So mathematically speaking, this means that the subcommittee is not a subset -- go figure. I blame IPython.) But, this oversight is specifically for financial matters only, not technical ones: "This Subcommittee shall NOT make decisions about the direction, scope or technical direction of the Project."
right -- I was specifically thinking someone from an external project to help with the touch technical decisions, like breaking teh ABI, what kin do missing value implementation to use, etc. These issues are very, very important to the third party packages. But again, plenty of opportunity to contribute to the discussion anyway -- which I guess leads the the core issue: if all goes well, it will matter not a wit who is on the council! Thomas Caswell (one of the leaders of matplotlib) volunteered to be
our external member to start. We certainly could ask him to sit on the steering council as well, but honestly my guess is that this would have no effect, either positive or negative.
He's a great guy -- so I"m going to go positive :-)
(I know if someone asked me to serve on a hypothetical matplotlib steering council, then I would just... never do anything, because who am I to second-guess matplotlib's actual developers.)
That's an asymmetrical relationship -- MPL (and many others) depend on numpy -- decisions (particularly the contentious ones where this is all relevant) made about numpy drive changes on MPL L-- not the other way around.
But I mean, it probably wouldn't hurt either. I'm not super-wedded to the current text. I just think we should limit how much effort we spend trying to cover every possible situation ahead of time. If we're clever enough to solve a problem now hypothetically, then we're probably also clever enough to solve it later when it becomes concrete.
and maybe it's easier -- there will be a council to do it :-) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov