composition of the steering council (was Re: Governance model request)
[splitting this out from the thread-o-doom] On Wed, Sep 23, 2015 at 8:47 AM, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote: [snip]
So here is what I think is on the table:
We have the steering council. Which leaves two questions:
-How big should it be? -Who will be on the original, "seed" council?
Note that as I understand the current draft of the governance doc, once established, the council itself decides who is on the council. So at this point we really are ONLY deciding how it's going to start. It has to be bootstrapped somehow.
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 :-). To make sure everyone's on the same page, here's a condensed summary of what the draft currently says: Joining the council: contributor must have produced "substantial" and "sustained" contributions over at least one year + be voted on by the current council + be interested and willing to serve. (Then there's some language emphasising that "contributions" should *not* be read narrowly as a euphemism for "lines of code".) 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. Former members are listed as "emeritus" to recognize their past service. Rejoining the council: aside from their entry on the list of emeritus members, a former-member and a never-member are treated identically in general, and the rules for re-joining are the same as the rules for joining. Proposal for seed council: "everyone who's merged a pull request since Jan 1, 2014". (Actual text is here: http://thread.gmane.org/gmane.comp.python.numeric.general/61106 , see section "Council membership".) 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. These specific rules are exactly the rules that Jupyter/IPython use, stolen without changes. 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. The rationale for doing things this way (if we keep it) would be that the steering council's "primary responsibility is to facilitate the ordinary community-based decision making procedure", so you need people who are actively engaged in community discussions; and, if things break down then the people best positioned to resolve it are the ones who have the best view of what went wrong, understand the personalities involved, and so forth. In practice, I'm sure any council interventions would involve most members deferring to whoever they judge has the most expertise, whether or not that person is on the council -- it's not like they'll ever be making a decision in a vacuum. Regarding the seed council, I just tried to pick an objective criterion and an arbitrary date that seemed generally in keeping with idea of "should be active in the last 1-to-2-years-ish". Fiddling with the exact date in particular makes very little difference -- between pushing it back to 2 years ago today or forward to 1 year ago today, the only thing that changes is whether Pauli makes the list or not. (And Pauli is obviously a great council candidate, though I don't know whether he even wants to be on it.)
Personally, I have no idea how big the council should be. Too big, and there is no point, consensus is harder to reach the larger the group, and the main (only?) role of the council is to resolve issues where consensus has not been reached in the larger community. But what is too big?
I'm a little wary of the idea of capping the council size. Assuming you're pre-filtering for basic competence and good faith (as we are), then the only way making the council smaller helps with decision making is that it arbitrarily throws away the opinion of some dedicated and valuable contributors. Plus then we have to start making judgements like "well, person A has been around for a while but pretty inactive recently, and person B is doing awesome stuff, should we kick person A off the council to let person B on or...?" 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. 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. (The old effect where "science advances one retirement at a time".) I'd be interested to hear what Jupyter/IPython's experience with this is, though: they currently have a 10 (!) person steering council, I assume they'd love to have more. Having lots of contributors who are active and engaged enough to meet the steering council qualifications is a good problem to have :-). Technically their situation is slightly different because their council runs on regular voting rather than Apache-style consensus voting (a luxury they can afford because they have a BDFL to step in if regular voting ends up disenfranchising the minority), but I sort of get the impression that in practice they just don't vote unless they know it will be unanimous, and it's worked out for them so far. (To understate the case.)
As for make-up of the council, I think we need to expand beyond people who have recently contributed core code.
Yes, the council does need to have expertise to make technical decisions, but if you think about the likely contentious issues like ABI breakage, a core-code focused view is incomplete. So there should be representation by:
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.
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." 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. (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.) It's not like we don't already hear from downstream projects on a regular basis. And if things have gone *so* pear-shaped that we have a situation where the steering council feels they need to issue a ruling, *and simultaneously* the members of the council are so out-of-touch that they don't know or care about the needs of downstream projects, then the situation is unsalvageable and we should fork and start over. 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. -n -- Nathaniel J. Smith -- http://vorpus.org
If I were to be included in the steering council I suspect my main contribution would be to occasionally remind everyone that we are all committed to the success of the open scientific stack. Tom On Wed, Sep 23, 2015 at 3:40 PM Nathaniel Smith <njs@pobox.com> wrote:
[splitting this out from the thread-o-doom]
On Wed, Sep 23, 2015 at 8:47 AM, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote: [snip]
So here is what I think is on the table:
We have the steering council. Which leaves two questions:
-How big should it be? -Who will be on the original, "seed" council?
Note that as I understand the current draft of the governance doc, once established, the council itself decides who is on the council. So at this point we really are ONLY deciding how it's going to start. It has to be bootstrapped somehow.
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 :-). To make sure everyone's on the same page, here's a condensed summary of what the draft currently says:
Joining the council: contributor must have produced "substantial" and "sustained" contributions over at least one year + be voted on by the current council + be interested and willing to serve. (Then there's some language emphasising that "contributions" should *not* be read narrowly as a euphemism for "lines of code".)
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. Former members are listed as "emeritus" to recognize their past service.
Rejoining the council: aside from their entry on the list of emeritus members, a former-member and a never-member are treated identically in general, and the rules for re-joining are the same as the rules for joining.
Proposal for seed council: "everyone who's merged a pull request since Jan 1, 2014".
(Actual text is here: http://thread.gmane.org/gmane.comp.python.numeric.general/61106 , see section "Council membership".)
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. These specific rules are exactly the rules that Jupyter/IPython use, stolen without changes.
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. The rationale for doing things this way (if we keep it) would be that the steering council's "primary responsibility is to facilitate the ordinary community-based decision making procedure", so you need people who are actively engaged in community discussions; and, if things break down then the people best positioned to resolve it are the ones who have the best view of what went wrong, understand the personalities involved, and so forth.
In practice, I'm sure any council interventions would involve most members deferring to whoever they judge has the most expertise, whether or not that person is on the council -- it's not like they'll ever be making a decision in a vacuum.
Regarding the seed council, I just tried to pick an objective criterion and an arbitrary date that seemed generally in keeping with idea of "should be active in the last 1-to-2-years-ish". Fiddling with the exact date in particular makes very little difference -- between pushing it back to 2 years ago today or forward to 1 year ago today, the only thing that changes is whether Pauli makes the list or not. (And Pauli is obviously a great council candidate, though I don't know whether he even wants to be on it.)
Personally, I have no idea how big the council should be. Too big, and there is no point, consensus is harder to reach the larger the group, and the main (only?) role of the council is to resolve issues where consensus has not been reached in the larger community. But what is too big?
I'm a little wary of the idea of capping the council size. Assuming you're pre-filtering for basic competence and good faith (as we are), then the only way making the council smaller helps with decision making is that it arbitrarily throws away the opinion of some dedicated and valuable contributors. Plus then we have to start making judgements like "well, person A has been around for a while but pretty inactive recently, and person B is doing awesome stuff, should we kick person A off the council to let person B on or...?" 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.
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. (The old effect where "science advances one retirement at a time".)
I'd be interested to hear what Jupyter/IPython's experience with this is, though: they currently have a 10 (!) person steering council, I assume they'd love to have more. Having lots of contributors who are active and engaged enough to meet the steering council qualifications is a good problem to have :-). Technically their situation is slightly different because their council runs on regular voting rather than Apache-style consensus voting (a luxury they can afford because they have a BDFL to step in if regular voting ends up disenfranchising the minority), but I sort of get the impression that in practice they just don't vote unless they know it will be unanimous, and it's worked out for them so far. (To understate the case.)
As for make-up of the council, I think we need to expand beyond people who have recently contributed core code.
Yes, the council does need to have expertise to make technical decisions, but if you think about the likely contentious issues like ABI breakage, a core-code focused view is incomplete. So there should be representation by:
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.
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."
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. (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.)
It's not like we don't already hear from downstream projects on a regular basis. And if things have gone *so* pear-shaped that we have a situation where the steering council feels they need to issue a ruling, *and simultaneously* the members of the council are so out-of-touch that they don't know or care about the needs of downstream projects, then the situation is unsalvageable and we should fork and start over.
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.
-n
-- Nathaniel J. Smith -- http://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Regarding the seed council, I just tried to pick an objective criterion and an arbitrary date that seemed generally in keeping with idea of "should be active in the last 1-to-2-years-ish". Fiddling with the exact date in particular makes very little difference -- between pushing it back to 2 years ago today or forward to 1 year ago today, the only thing that changes is whether Pauli makes the list or not. (And Pauli is obviously a great council candidate, though I don't know whether he even wants to be on it.)
Personally, I have no idea how big the council should be. Too big, and there is no point, consensus is harder to reach the larger the group, and the main (only?) role of the council is to resolve issues where consensus has not been reached in the larger community. But what is too big?
As for make-up of the council, I think we need to expand beyond people who have recently contributed core code.
Yes, the council does need to have expertise to make technical decisions, but if you think about the likely contentious issues like ABI breakage, a core-code focused view is incomplete. So there should be representation by:
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.
As the original author of NumPy, I would like to be on the seed council as long as it is larger than 7 people. That is my proposal. I don't need to be a permanent member, but I do believe I have enough history that I can understand issues even if I haven't been working on code directly. I think I do bring history and information that provides all of the history that could be helpful on occasion. In addition, if a matter is important enough to even be brought to the attention of this council, I would like to be involved in the discussion about it. It's a simple change to the text --- basically an explanation that Travis requested to be on the seed council. -Travis
On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant <travis@continuum.io> wrote:
As the original author of NumPy, I would like to be on the seed council as long as it is larger than 7 people. That is my proposal.
Or the seed council could invite Travis to join as its first order of business :-) Actually, maybe that's a way to handle it -- declare that the first order of business for teh seed council is to expand the council. I'd still like some guidelines (suggestions) for history and at least one major dependent-on-numpy rep. Travis would certainly meet the history requirement -- and maybe the other, too. :-)
It's a simple change to the text --- basically an explanation that Travis requested to be on the seed council.
I'd rather the final draft of the document didn't name names, but no biggie. -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
On Wed, Sep 23, 2015 at 3:42 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant <travis@continuum.io> wrote:
As the original author of NumPy, I would like to be on the seed council as long as it is larger than 7 people. That is my proposal.
Or the seed council could invite Travis to join as its first order of business :-)
Actually, maybe that's a way to handle it -- declare that the first order of business for teh seed council is to expand the council.
Perhaps we should specify a yearly meeting to review the past year and nominate people for commit rights and council membership. Long term, we might also want to start removing commit rights, perhaps by adding a team category on github with restricted rights -- committer emeritus, so to speak.
I'd still like some guidelines (suggestions) for history and at least one major dependent-on-numpy rep. Travis would certainly meet the history requirement -- and maybe the other, too. :-)
It's a simple change to the text --- basically an explanation that Travis requested to be on the seed council.
I'd rather the final draft of the document didn't name names, but no biggie.
Chuck
On Wed, Sep 23, 2015 at 6:19 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Wed, Sep 23, 2015 at 3:42 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant <travis@continuum.io> wrote:
As the original author of NumPy, I would like to be on the seed council as long as it is larger than 7 people. That is my proposal.
Or the seed council could invite Travis to join as its first order of business :-)
Actually, maybe that's a way to handle it -- declare that the first order of business for teh seed council is to expand the council.
Perhaps we should specify a yearly meeting to review the past year and nominate people for commit rights and council membership. Long term, we might also want to start removing commit rights, perhaps by adding a team category on github with restricted rights -- committer emeritus, so to speak.
That's a pretty good idea, actually.
I'd still like some guidelines (suggestions) for history and at least one major dependent-on-numpy rep. Travis would certainly meet the history requirement -- and maybe the other, too. :-)
It's a simple change to the text --- basically an explanation that Travis requested to be on the seed council.
I'd rather the final draft of the document didn't name names, but no biggie.
I'm fine with that too --- except you will need to name the initial seed council. -Travis
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
-- *Travis Oliphant* *Co-founder and CEO* @teoliphant 512-222-5440 http://www.continuum.io
On Mi, 2015-09-23 at 19:48 -0500, Travis Oliphant wrote:
On Wed, Sep 23, 2015 at 6:19 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Wed, Sep 23, 2015 at 3:42 PM, Chris Barker <chris.barker@noaa.gov> wrote: On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant <travis@continuum.io> wrote:
As the original author of NumPy, I would like to be on the seed council as long as it is larger than 7 people. That is my proposal.
Or the seed council could invite Travis to join as its first order of business :-)
Actually, maybe that's a way to handle it -- declare that the first order of business for teh seed council is to expand the council.
Perhaps we should specify a yearly meeting to review the past year and nominate people for commit rights and council membership. Long term, we might also want to start removing commit rights, perhaps by adding a team category on github with restricted rights -- committer emeritus, so to speak.
That's a pretty good idea, actually.
+1, lets make sure that dynamics of getting new people in and inactive out won't stall too easily.
I'd still like some guidelines (suggestions) for history and at least one major dependent-on-numpy rep. Travis would certainly meet the history requirement -- and maybe the other, too. :-)
It's a simple change to the text --- basically an explanation that Travis requested to be on the seed council.
I'd rather the final draft of the document didn't name names, but no biggie.
I'm fine with that too --- except you will need to name the initial seed council.
-Travis
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Travis Oliphant Co-founder and CEO
@teoliphant 512-222-5440 http://www.continuum.io _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Sep 23, 2015 at 3:21 PM, Travis Oliphant <travis@continuum.io> wrote:
Regarding the seed council, I just tried to pick an objective criterion and an arbitrary date that seemed generally in keeping with idea of "should be active in the last 1-to-2-years-ish". Fiddling with the exact date in particular makes very little difference -- between pushing it back to 2 years ago today or forward to 1 year ago today, the only thing that changes is whether Pauli makes the list or not. (And Pauli is obviously a great council candidate, though I don't know whether he even wants to be on it.)
Personally, I have no idea how big the council should be. Too big, and there is no point, consensus is harder to reach the larger the group, and the main (only?) role of the council is to resolve issues where consensus has not been reached in the larger community. But what is too big?
As for make-up of the council, I think we need to expand beyond people who have recently contributed core code.
Yes, the council does need to have expertise to make technical decisions, but if you think about the likely contentious issues like ABI breakage, a core-code focused view is incomplete. So there should be representation by:
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.
As the original author of NumPy, I would like to be on the seed council as long as it is larger than 7 people. That is my proposal. I don't need to be a permanent member, but I do believe I have enough history that I can understand issues even if I haven't been working on code directly.
I think I do bring history and information that provides all of the history that could be helpful on occasion. In addition, if a matter is important enough to even be brought to the attention of this council, I would like to be involved in the discussion about it.
It's a simple change to the text --- basically an explanation that Travis requested to be on the seed council.
I too would like you to be a member. We could either write it into the text in recognition of your status as the Numpy creator, or it could be the first order of business. I would only ask that you give yourself some time to become familiar with how things work and the people involved in the current community. It has been some years since you have been active in code development. Chuck
For what it is worth, I'm +1 on including any of the "founding fathers" (and uncles!) that wish to be included in the committee, or council, or however we ended up calling it. I'm also OK with singling out Travis as creator of NumPy in the wording of the document. Especially since the prerogative of members is not to **VOTE**, but to **VETO**, I don't see adding more people having any effect on the individual power of members, so my +1 stands regardless of what the total member count is. Jaime On Wed, Sep 23, 2015 at 4:08 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Wed, Sep 23, 2015 at 3:21 PM, Travis Oliphant <travis@continuum.io> wrote:
Regarding the seed council, I just tried to pick an objective criterion and an arbitrary date that seemed generally in keeping with idea of "should be active in the last 1-to-2-years-ish". Fiddling with the exact date in particular makes very little difference -- between pushing it back to 2 years ago today or forward to 1 year ago today, the only thing that changes is whether Pauli makes the list or not. (And Pauli is obviously a great council candidate, though I don't know whether he even wants to be on it.)
Personally, I have no idea how big the council should be. Too big, and there is no point, consensus is harder to reach the larger the group, and the main (only?) role of the council is to resolve issues where consensus has not been reached in the larger community. But what is too big?
As for make-up of the council, I think we need to expand beyond people who have recently contributed core code.
Yes, the council does need to have expertise to make technical decisions, but if you think about the likely contentious issues like ABI breakage, a core-code focused view is incomplete. So there should be representation by:
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.
As the original author of NumPy, I would like to be on the seed council as long as it is larger than 7 people. That is my proposal. I don't need to be a permanent member, but I do believe I have enough history that I can understand issues even if I haven't been working on code directly.
I think I do bring history and information that provides all of the history that could be helpful on occasion. In addition, if a matter is important enough to even be brought to the attention of this council, I would like to be involved in the discussion about it.
It's a simple change to the text --- basically an explanation that Travis requested to be on the seed council.
I too would like you to be a member. We could either write it into the text in recognition of your status as the Numpy creator, or it could be the first order of business. I would only ask that you give yourself some time to become familiar with how things work and the people involved in the current community. It has been some years since you have been active in code development.
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
-- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.
On Wed, Sep 23, 2015 at 5:41 PM, Jaime Fernández del Río < jaime.frio@gmail.com> wrote:
For what it is worth, I'm +1 on including any of the "founding fathers" (and uncles!) that wish to be included in the committee, or council, or however we ended up calling it. I'm also OK with singling out Travis as creator of NumPy in the wording of the document.
I think "Founding Entities" would be the politically correct term ;)
Especially since the prerogative of members is not to **VOTE**, but to **VETO**, I don't see adding more people having any effect on the individual power of members, so my +1 stands regardless of what the total member count is.
<snip> Chuck
Thanks Chuck, I have been paying some attention, actually --- just not speaking up until there is a major difference of opinion (like the governance document...). I guess I don't feel like I've completely lost track of "how things work" --- while there are some new wonderful faces and contributors. It all feels pretty familiar to past experiences (just pleasantly bigger and more people). I don't expect to be the most active participant for sure, but I continue to hope to train others where possible and be a resource for others to ask questions of. -Travis On Wed, Sep 23, 2015 at 6:08 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Wed, Sep 23, 2015 at 3:21 PM, Travis Oliphant <travis@continuum.io> wrote:
Regarding the seed council, I just tried to pick an objective criterion and an arbitrary date that seemed generally in keeping with idea of "should be active in the last 1-to-2-years-ish". Fiddling with the exact date in particular makes very little difference -- between pushing it back to 2 years ago today or forward to 1 year ago today, the only thing that changes is whether Pauli makes the list or not. (And Pauli is obviously a great council candidate, though I don't know whether he even wants to be on it.)
Personally, I have no idea how big the council should be. Too big, and there is no point, consensus is harder to reach the larger the group, and the main (only?) role of the council is to resolve issues where consensus has not been reached in the larger community. But what is too big?
As for make-up of the council, I think we need to expand beyond people who have recently contributed core code.
Yes, the council does need to have expertise to make technical decisions, but if you think about the likely contentious issues like ABI breakage, a core-code focused view is incomplete. So there should be representation by:
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.
As the original author of NumPy, I would like to be on the seed council as long as it is larger than 7 people. That is my proposal. I don't need to be a permanent member, but I do believe I have enough history that I can understand issues even if I haven't been working on code directly.
I think I do bring history and information that provides all of the history that could be helpful on occasion. In addition, if a matter is important enough to even be brought to the attention of this council, I would like to be involved in the discussion about it.
It's a simple change to the text --- basically an explanation that Travis requested to be on the seed council.
I too would like you to be a member. We could either write it into the text in recognition of your status as the Numpy creator, or it could be the first order of business. I would only ask that you give yourself some time to become familiar with how things work and the people involved in the current community. It has been some years since you have been active in code development.
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
-- *Travis Oliphant* *Co-founder and CEO* @teoliphant 512-222-5440 http://www.continuum.io
On Mi, 2015-09-23 at 17:08 -0600, Charles R Harris wrote:
On Wed, Sep 23, 2015 at 3:21 PM, Travis Oliphant <travis@continuum.io> wrote:
Regarding the seed council, I just tried to pick an objective criterion and an arbitrary date that seemed generally in keeping with idea of "should be active in the last 1-to-2-years-ish". Fiddling with the exact date in particular makes very little difference -- between pushing it back to 2 years ago today or forward to 1 year ago today, the only thing that changes is whether Pauli makes the list or not. (And Pauli is obviously a great council candidate, though I don't know whether he even wants to be on it.)
> Personally, I have no idea how big the council should be. Too big, and > there is no point, consensus is harder to reach the larger the group, > and the main (only?) role of the council is to resolve issues where > consensus has not been reached in the larger community. But what is > too big?
> As for make-up of the council, I think we need to expand beyond people > who have recently contributed core code. > > Yes, the council does need to have expertise to make technical > decisions, but if you think about the likely contentious issues like > ABI breakage, a core-code focused view is incomplete. So there should > be representation by: > > 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.
As the original author of NumPy, I would like to be on the seed council as long as it is larger than 7 people. That is my proposal. I don't need to be a permanent member, but I do believe I have enough history that I can understand issues even if I haven't been working on code directly.
I think I do bring history and information that provides all of the history that could be helpful on occasion. In addition, if a matter is important enough to even be brought to the attention of this council, I would like to be involved in the discussion about it.
It's a simple change to the text --- basically an explanation that Travis requested to be on the seed council.
I too would like you to be a member. We could either write it into the text in recognition of your status as the Numpy creator, or it could be the first order of business. I would only ask that you give yourself some time to become familiar with how things work and the people involved in the current community. It has been some years since you have been active in code development.
I think I can agree with that. On a serious note, I now realize that I am probably the one with the most objection, so for everyone, do not bother with trying to convince me, you probably cannot fully, nor do you have to, I will let it stand as is after this and let others take over from here (after this, probably whatever Chuck says is good). [1] More to the point of the actual members: So to say, I feel the council members have to try to be *directly* active and see being active as a necessary *commitment* (i.e. also try to travel to meetings). This will always be a difficult judgment of course, but there is no help to it. The current definitions imply this. And two years seems fine. It is not that short, at least unless someone stops contributing very abruptly which I do not think is that usual. I will weight in to keep the current times but do not feel very strongly. About using the commit log to seed, I think there are some old term contributers (David Cournapeau maybe?), who never stopped doing quite a bit but may not have merge commits. However, I think we can start of with what we had, then I would hope Chuck and maybe Ralf can fill in the blanks. About the size, I think if we get too many -- if that is possible -- we should just change the governance at that time to be not veto based anymore. This is something to keep in mind, but probably does not need to be formalized. - Sebastian [1] Sorry to "footnote" this, but I think I am probably rudely repeating myself and frankly do **not want this to be discussed**. It is just to try to be fully clear where I come from: Until SciPy 2015, I could list many people on this list who have shown more direct involvement in numpy then Travis since I joined and have no affiliation to numpy. If Travis had been new to the community at the time, I would be surprised if I would even recognize his name. I know this is only half the picture and Travis already mentioned another side, but this is what I mostly saw even if it may be a harsh and rude assessment.
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Sep 24, 2015 at 10:45 AM, Sebastian Berg <sebastian@sipsolutions.net
wrote:
On Mi, 2015-09-23 at 17:08 -0600, Charles R Harris wrote:
On Wed, Sep 23, 2015 at 3:21 PM, Travis Oliphant <travis@continuum.io> wrote:
Regarding the seed council, I just tried to pick an objective criterion and an arbitrary date that seemed generally in keeping with idea of "should be active in the last 1-to-2-years-ish". Fiddling with the exact date in particular makes very little difference -- between pushing it back to 2 years ago today or forward to 1 year ago today, the only thing that changes is whether Pauli makes the list or not. (And Pauli is obviously a great council candidate, though I don't know whether he even wants to be on it.)
> Personally, I have no idea how big the council should be. Too big, and > there is no point, consensus is harder to reach the larger the group, > and the main (only?) role of the council is to resolve issues where > consensus has not been reached in the larger community. But what is > too big?
> As for make-up of the council, I think we need to expand beyond people > who have recently contributed core code. > > Yes, the council does need to have expertise to make technical > decisions, but if you think about the likely contentious issues like > ABI breakage, a core-code focused view is incomplete. So there should > be representation by: > > 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.
As the original author of NumPy, I would like to be on the seed council as long as it is larger than 7 people. That is my proposal. I don't need to be a permanent member, but I do believe I have enough history that I can understand issues even if I haven't been working on code directly.
I think I do bring history and information that provides all of the history that could be helpful on occasion. In addition, if a matter is important enough to even be brought to the attention of this council, I would like to be involved in the discussion about it.
It's a simple change to the text --- basically an explanation that Travis requested to be on the seed council.
I too would like you to be a member. We could either write it into the text in recognition of your status as the Numpy creator, or it could be the first order of business. I would only ask that you give yourself some time to become familiar with how things work and the people involved in the current community. It has been some years since you have been active in code development.
I think I can agree with that. On a serious note, I now realize that I am probably the one with the most objection, so for everyone, do not bother with trying to convince me, you probably cannot fully, nor do you have to, I will let it stand as is after this and let others take over from here (after this, probably whatever Chuck says is good). [1]
More to the point of the actual members:
So to say, I feel the council members have to try to be *directly* active and see being active as a necessary *commitment* (i.e. also try to travel to meetings). This will always be a difficult judgment of course, but there is no help to it. The current definitions imply this. And two years seems fine. It is not that short, at least unless someone stops contributing very abruptly which I do not think is that usual. I will weight in to keep the current times but do not feel very strongly.
About using the commit log to seed, I think there are some old term contributers (David Cournapeau maybe?), who never stopped doing quite a bit but may not have merge commits. However, I think we can start of with what we had, then I would hope Chuck and maybe Ralf can fill in the blanks.
AFAIK, I still have merge commits. I am actually doing a bit of numpy development ATM, so I would prefer keeping them, but I won't fight it either. David
About the size, I think if we get too many -- if that is possible -- we should just change the governance at that time to be not veto based anymore. This is something to keep in mind, but probably does not need to be formalized.
- Sebastian
[1] Sorry to "footnote" this, but I think I am probably rudely repeating myself and frankly do **not want this to be discussed**. It is just to try to be fully clear where I come from: Until SciPy 2015, I could list many people on this list who have shown more direct involvement in numpy then Travis since I joined and have no affiliation to numpy. If Travis had been new to the community at the time, I would be surprised if I would even recognize his name. I know this is only half the picture and Travis already mentioned another side, but this is what I mostly saw even if it may be a harsh and rude assessment.
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Sep 24, 2015 at 10:45 AM, David Cournapeau <cournape@gmail.com> wrote:
On Thu, Sep 24, 2015 at 10:45 AM, Sebastian Berg <sebastian@sipsolutions.net> wrote:
[...]
About using the commit log to seed, I think there are some old term contributers (David Cournapeau maybe?), who never stopped doing quite a bit but may not have merge commits. However, I think we can start of with what we had, then I would hope Chuck and maybe Ralf can fill in the blanks.
AFAIK, I still have merge commits. I am actually doing a bit of numpy development ATM, so I would prefer keeping them, but I won't fight it either.
For the record -- Sebastian's "not have merge commits" here I think means that looking at git history shows that you haven't reviewed/merged any other people's pull requests in the time period we've been looking at for the steering council discussion. AFAIK you do still have write permission to the repository on github, and there hasn't been any proposal to change those permissions around. (I'd certainly be in favor of *not* restricting commit permission to just the "steering council". But we can talk about that later once we've figured out what the steering council actually is :-).) -n -- Nathaniel J. Smith -- http://vorpus.org
[1] Sorry to "footnote" this, but I think I am probably rudely repeating myself and frankly do **not want this to be discussed**. It is just to try to be fully clear where I come from: Until SciPy 2015, I could list many people on this list who have shown more direct involvement in numpy then Travis since I joined and have no affiliation to numpy. If Travis had been new to the community at the time, I would be surprised if I would even recognize his name. I know this is only half the picture and Travis already mentioned another side, but this is what I mostly saw even if it may be a harsh and rude assessment.
I do understand this. That's actually why I'm speaking up, because I don't think my activity has been understood by many people who have joined this list only recently. I don't want to interfere with your activity or impede your progress, or to be asked permission for anything. In fact, I want to understand how to best use my limited time to support things. You in particular are interested in indexing and fixing it --- the current code is there for a reason and some of the issues being discussed today have been discussed before --- though we have the benefit of hindsight now. I have mostly been behind the scenes helping people since about 2010 --- but still thinking a lot about NumPy, the downstream community, integration with other libraries, and where things could go. I don't have the time to commit major code changes, but I do have the time to contribute perspective and even a design idea or two from time to time. Obviously, nobody has to listen. I understand and appreciate that there are a lot of people that have contributed code and discussion since 2009 and to them it probably seems I'm just popping in and out --- and if you only look at the contributor log you can wonder "who is this guy...". But, I did do *a lot* of work to get NumPy off the ground. Quite a bit of that work was very lonely with people interested in the merger but pretty skeptical until the work was nearly done (and then many people helped finish it and get it working and tested). I wish I had been a better architect at the time (I can see now many things that would have been done differently). But, I'm still proud of the work I did in creating a foundation many could build on --- at the time nobody else was stepping up to do the job. Since that time, I have remained very interested in the success of NumPy and supporting the many *users* of NumPy. What I most bring to the current community is having observed many, many uses of NumPy in the wild --- from people who would never post to this list and whose use-cases are absent from discussion or misunderstood. I also bring knowledge about the wider Python ecosystem and the broader world outside of NumPy alone. The group is free to take my ideas and/or contributions or leave them. And I am also free to just review pull requests and contribute if and when I might. Best, -Travis
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
-- *Travis Oliphant* *Co-founder and CEO* @teoliphant 512-222-5440 http://www.continuum.io
[Travis: sorry for writing all this referring to you in third person -- I guess it might feel a bit awkward to read! You're certainly part of the intended audience, but then it felt even more awkward trying to write in second person... this is clearly a bug in English.] Hi all, On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant <travis@continuum.io> wrote:
As the original author of NumPy, I would like to be on the seed council as long as it is larger than 7 people. That is my proposal. I don't need to be a permanent member, but I do believe I have enough history that I can understand issues even if I haven't been working on code directly.
I think I do bring history and information that provides all of the history that could be helpful on occasion. In addition, if a matter is important enough to even be brought to the attention of this council, I would like to be involved in the discussion about it.
Regarding the question of Travis being on the council: My overall feeling on this pretty neutral: I think it won't make much of a difference to NumPy really either way, because the important thing will be Travis's insights, available time to contribute, etc., and these will (I assume) be pretty much the same regardless of whether he's on the council or not. (Any matter so intractable that it actually needs the council's emergency powers will presumably be heralded by an epic multi-month message thread of doom, plus Travis has plenty of friends on the council who know where to find him when historical insight is needed, so I'm not worried about anyone missing out on a chance to be involved.) I'm sure we can make it work either way. But, I want to play devil's advocate for a bit, because there are some connected issues that IMHO we should at least think through if we're going to do this, and I think the easiest way to do that is to try and articulate the case against. So, here's the case against Travis being on the steering council immediately + an alternative option for comparison: ----- begin devil's advocate ----- First, just as a procedural matter, it seems clear that putting Travis on the council now will require changing the document in ways that violate Sebastian/Chris's concept of a "no names" rule -- at least in spirit if not in letter. The problem isn't just the initial council seeding; it's that Travis formally stepped down from the project more than 2.5 years ago, was mostly inactive for some time before that, and IIRC has been almost completely unheard-from between then and a few weeks ago. (Of course please correct me if I'm forgetting something, and obviously I'm talking with respect to numpy only -- clearly Travis has been doing tons of great things, but while numpy certainly benefits from e.g. the existence of NumFOCUS, creating NumFOCUS doesn't really feel like what we mean by "project activity" :-).) This means that as currently written, it's pretty unambiguous: he doesn't qualify to be added by the normal nomination process (requires "sustained" activity over the last year), and if he were added anyway (e.g. as part of the seed council) then according to the rules he would then be immediately removed for inactivity (requires being active within the last 1 year, or else within the 2 years plus affirmation that they planned to "return to active participation soon" -- this post hoc analysis requires a bit of squinting to apply at all, but it's pretty hard to reconcile with >2 years inactivity + his "moving on from numpy to blaze" post). To avoid referencing him by name we could add some text about "founding developers" or something as a fig leaf, but judging from Robert's last email it sounds like Travis is the only person in question, so this really would just be a fig leaf. Of course we have the option of modifying the rules to make this work -- I'm not really sure how to do this, but it's our text and I'm sure we can make it do whatever we want somehow. But any kinds of special case modifications for a single person create two problems: 1) Given that whether or not Travis is listed on the steering council probably won't affect the project much or at all, it could easily appear to an outside observer that the purpose of these rules changes was not to benefit NumPy, but only to benefit Travis's ego. Not that there's anything wrong with massaging Travis's ego :-). BUT, it sends a clear message (whether we mean it that way or not): that we think being on the steering council should affect one's ego. And there *is* something very wrong with this *message*. It's crucial that serving on the steering council be understood to be a job, not a privilege -- sort of like being release manager. It's an important and valued job, we're glad people volunteer, but it's an absolutely fundamental rule that council members do *not* get any special treatment outside of specific limited circumstances. If being on the steering council becomes a trophy or judgement of worth, and being left off it becomes an insult that implies someone's contributions are less worthy, then we are starting down the slippery slope that Matthew worries about, where there's an unspoken class distinction between the "important contributors" and "everyone else". This exact problem has destroyed the community in many F/OSS projects (see: BSDs, XFree86, lots of modern corporate-controlled projects). Emotions get high in these discussions, but it's important to remember that at the end of the day all this "steering council" stuff is just some bureaucracy we need to get organized so that we can get back to the real work that matters -- no-one's worth is up for debate, and the steering council is just one part of the whole project. And not even the most important part. 2) If we change the rules in one case, then it's hard to prove to outside observers that the rules really are the rules and are really applied equally to everyone. Brian Granger was telling us at SciPy how this has been a major challenge for Jupyter/IPython when working with large companies -- they really want to have confidence in the governance structure before they get involved. We don't want to end up in a conversation like: <IBM> We'd like to contribute, but first we'd like some evidence that you're really a robust independent project and not subject to corporate capture. <NumPy> Well, here's our governance document, it clearly lays out the rules for contributions, and in particular how corporate contributions get no special privileges... <IBM> Sure, that's what it says, but the first time a well-connected CEO who employs the leaders of substantial portions of the numerical ecosystem asked, you changed the rules to give him special privileges. <NumPy> Well, yes, but that was an extremely special case that had nothing to do with the corporate stuff you just said -- it was because Travis is just that awesome. <IBM> Well, we are a faceless corporate monolith and have no idea who this Travis guy is, but okay, fine, he's just that awesome. Is anyone else that awesome? Where's the line -- what other special cases are there that are special enough to break the rules? The next time one comes up, will you follow the rules that you wrote down or do something else? <NumPy> ...we're not sure? ...that would kind of suck. So those are two problems that would apply for any special cases added to the rules, regardless of who particularly they were for. There's also the further concern that the steering council's main job is to "provide useful guidance, both technical and in terms of project direction, to potentially less experienced contributors" and "facilitate the ordinary community-based decision making procedure", and in Travis's case in particular, it's sort of unclear whether he's the best person for these jobs right now. Between his limited time (e.g. "I don't have time myself to engage in the community process" [1]) and the way the project has changed since he was actively involved, interactions in recent years have tended to be a bit awkward -- not because of any wrong-doing on anyone's part, but just because we're generally out-of-sync, resulting in e.g. self-merged pull requests [2][3] [glad to hear you don't do this anymore though!], or struggles to contribute to discussions based on limited context [4], or emails [5][6] that scare Chris Barker [7]. And usually with these kinds of discussions (e.g. for commit rights) you get enthusiastic unanimity, so Sebastian's unusually frank concerns give me serious pause [8]. Everyone else on the proposed steering council list certainly doesn't agree about everything, but we do all have ongoing relationships from interacting on the tracker and mailing list, making day-to-day decisions, and it's not clear to me that Travis even wants/is able to participate at that level currently. So what's the alternative option? I'd suggest: Keep the Jupyer/IPython rules for council member eligibility, and add Travis in a year when he becomes eligible by those rules. (Assuming he remains active and interested -- personally in his position I'd be tempted to just stick with the much cushier "Founder / Leader Emeritus" job -- all the respect, none of the day-to-day hassle ;-).) In the mean time we still get his insight and other contributions, and it provides a clear period for him ease into how we do things these days, which addresses Chuck and Sebastian's concerns. And, more importantly, it takes advantage of a unique opportunity: it takes the above negatives and turns them into positives. If later on someone feels slighted at not being on the steering council, we can say "look, even *Travis* isn't (wasn't) on the steering council -- you've misunderstood what this means", or if IBM comes calling we can say: <NumPy> Look, if we were going to break the rules for anyone, we would have broken them for Travis. But he followed the same process as everyone else. That's how we do things around here. I've had several long conversations with Travis recently, and one thing that's been very clear is that he still sees NumPy as being his baby and he's hungry to find ways to help it -- but maybe struggling to work out how to do that most effectively. It's a thing about babies -- eventually they grow up, become rebellious teenagers, and then -- if you did a good job parenting, and are very lucky -- they move out, have their own lives, and maybe call occasionally to ask for advice and money ;-). I'm not a parent, but I have been a child, and I understand this is often a challenging transition... In the case of NumPy, I think the last few years have shown that the project can more-or-less grow and succeed even without Travis -- but pulling a George Washington http://deadpresidents.tumblr.com/post/24687113413/did-washington-stepping-do... like this would make a contribution to NumPy's long-term stability in a way that only Travis can do. ----- end devil's advocate ----- Again, I want to emphasize that while I've tried to make as strong a case as I can above, my actual belief right now is that NumPy will be just fine either way -- especially if we can think of ways to address and minimize the two specific problems described above. But at the very least I wanted to make sure they were on the table as concerns. -n [1] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073564.html [2] https://github.com/numpy/numpy/pull/2940 [3] https://github.com/numpy/numpy/pull/2772 [4] https://github.com/numpy/numpy/issues/5844#issuecomment-141723799 [5] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073562.html [6] https://mail.python.org/pipermail/python-dev/2015-September/141609.html [7] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073582.html [8] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073748.html -- Nathaniel J. Smith -- http://vorpus.org
To respond to the devils advocate: Creating this organizational framework is a one time boot-strapping event. You could use wording like "The initial council will include those who have made significant contributions to numpy in the past and want to be on it" or "The initial council will be constructed by invitation by Nathaniel and Chuck". More objective criteria should be used going forward, but in terms of getting things spun up quickly doing things by fiat is probably ok. I am not even sure that the method by which the initial group is formed needs to go into the governing document. I think this addresses most of the concerns, IBM is happy (enough) because this was done as part of a one-time boot strapping operation of standing the rules up and there are no explicit names in the governing documents. It also acknowledges that there is a discontinuity/singularity in the governance of the project which means you get to do singular thing :). Tom On Fri, Sep 25, 2015 at 8:40 AM Nathaniel Smith <njs@pobox.com> wrote:
[Travis: sorry for writing all this referring to you in third person -- I guess it might feel a bit awkward to read! You're certainly part of the intended audience, but then it felt even more awkward trying to write in second person... this is clearly a bug in English.]
Hi all,
On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant <travis@continuum.io> wrote:
As the original author of NumPy, I would like to be on the seed council as long as it is larger than 7 people. That is my proposal. I don't need to be a permanent member, but I do believe I have enough history that I can understand issues even if I haven't been working on code directly.
I think I do bring history and information that provides all of the history that could be helpful on occasion. In addition, if a matter is important enough to even be brought to the attention of this council, I would like to be involved in the discussion about it.
Regarding the question of Travis being on the council:
My overall feeling on this pretty neutral: I think it won't make much of a difference to NumPy really either way, because the important thing will be Travis's insights, available time to contribute, etc., and these will (I assume) be pretty much the same regardless of whether he's on the council or not. (Any matter so intractable that it actually needs the council's emergency powers will presumably be heralded by an epic multi-month message thread of doom, plus Travis has plenty of friends on the council who know where to find him when historical insight is needed, so I'm not worried about anyone missing out on a chance to be involved.) I'm sure we can make it work either way.
But, I want to play devil's advocate for a bit, because there are some connected issues that IMHO we should at least think through if we're going to do this, and I think the easiest way to do that is to try and articulate the case against. So, here's the case against Travis being on the steering council immediately + an alternative option for comparison:
----- begin devil's advocate -----
First, just as a procedural matter, it seems clear that putting Travis on the council now will require changing the document in ways that violate Sebastian/Chris's concept of a "no names" rule -- at least in spirit if not in letter. The problem isn't just the initial council seeding; it's that Travis formally stepped down from the project more than 2.5 years ago, was mostly inactive for some time before that, and IIRC has been almost completely unheard-from between then and a few weeks ago. (Of course please correct me if I'm forgetting something, and obviously I'm talking with respect to numpy only -- clearly Travis has been doing tons of great things, but while numpy certainly benefits from e.g. the existence of NumFOCUS, creating NumFOCUS doesn't really feel like what we mean by "project activity" :-).)
This means that as currently written, it's pretty unambiguous: he doesn't qualify to be added by the normal nomination process (requires "sustained" activity over the last year), and if he were added anyway (e.g. as part of the seed council) then according to the rules he would then be immediately removed for inactivity (requires being active within the last 1 year, or else within the 2 years plus affirmation that they planned to "return to active participation soon" -- this post hoc analysis requires a bit of squinting to apply at all, but it's pretty hard to reconcile with >2 years inactivity + his "moving on from numpy to blaze" post). To avoid referencing him by name we could add some text about "founding developers" or something as a fig leaf, but judging from Robert's last email it sounds like Travis is the only person in question, so this really would just be a fig leaf.
Of course we have the option of modifying the rules to make this work -- I'm not really sure how to do this, but it's our text and I'm sure we can make it do whatever we want somehow. But any kinds of special case modifications for a single person create two problems:
1) Given that whether or not Travis is listed on the steering council probably won't affect the project much or at all, it could easily appear to an outside observer that the purpose of these rules changes was not to benefit NumPy, but only to benefit Travis's ego. Not that there's anything wrong with massaging Travis's ego :-). BUT, it sends a clear message (whether we mean it that way or not): that we think being on the steering council should affect one's ego. And there *is* something very wrong with this *message*.
It's crucial that serving on the steering council be understood to be a job, not a privilege -- sort of like being release manager. It's an important and valued job, we're glad people volunteer, but it's an absolutely fundamental rule that council members do *not* get any special treatment outside of specific limited circumstances. If being on the steering council becomes a trophy or judgement of worth, and being left off it becomes an insult that implies someone's contributions are less worthy, then we are starting down the slippery slope that Matthew worries about, where there's an unspoken class distinction between the "important contributors" and "everyone else". This exact problem has destroyed the community in many F/OSS projects (see: BSDs, XFree86, lots of modern corporate-controlled projects).
Emotions get high in these discussions, but it's important to remember that at the end of the day all this "steering council" stuff is just some bureaucracy we need to get organized so that we can get back to the real work that matters -- no-one's worth is up for debate, and the steering council is just one part of the whole project. And not even the most important part.
2) If we change the rules in one case, then it's hard to prove to outside observers that the rules really are the rules and are really applied equally to everyone. Brian Granger was telling us at SciPy how this has been a major challenge for Jupyter/IPython when working with large companies -- they really want to have confidence in the governance structure before they get involved. We don't want to end up in a conversation like:
<IBM> We'd like to contribute, but first we'd like some evidence that you're really a robust independent project and not subject to corporate capture. <NumPy> Well, here's our governance document, it clearly lays out the rules for contributions, and in particular how corporate contributions get no special privileges... <IBM> Sure, that's what it says, but the first time a well-connected CEO who employs the leaders of substantial portions of the numerical ecosystem asked, you changed the rules to give him special privileges. <NumPy> Well, yes, but that was an extremely special case that had nothing to do with the corporate stuff you just said -- it was because Travis is just that awesome. <IBM> Well, we are a faceless corporate monolith and have no idea who this Travis guy is, but okay, fine, he's just that awesome. Is anyone else that awesome? Where's the line -- what other special cases are there that are special enough to break the rules? The next time one comes up, will you follow the rules that you wrote down or do something else? <NumPy> ...we're not sure?
...that would kind of suck.
So those are two problems that would apply for any special cases added to the rules, regardless of who particularly they were for.
There's also the further concern that the steering council's main job is to "provide useful guidance, both technical and in terms of project direction, to potentially less experienced contributors" and "facilitate the ordinary community-based decision making procedure", and in Travis's case in particular, it's sort of unclear whether he's the best person for these jobs right now. Between his limited time (e.g. "I don't have time myself to engage in the community process" [1]) and the way the project has changed since he was actively involved, interactions in recent years have tended to be a bit awkward -- not because of any wrong-doing on anyone's part, but just because we're generally out-of-sync, resulting in e.g. self-merged pull requests [2][3] [glad to hear you don't do this anymore though!], or struggles to contribute to discussions based on limited context [4], or emails [5][6] that scare Chris Barker [7]. And usually with these kinds of discussions (e.g. for commit rights) you get enthusiastic unanimity, so Sebastian's unusually frank concerns give me serious pause [8]. Everyone else on the proposed steering council list certainly doesn't agree about everything, but we do all have ongoing relationships from interacting on the tracker and mailing list, making day-to-day decisions, and it's not clear to me that Travis even wants/is able to participate at that level currently.
So what's the alternative option? I'd suggest: Keep the Jupyer/IPython rules for council member eligibility, and add Travis in a year when he becomes eligible by those rules. (Assuming he remains active and interested -- personally in his position I'd be tempted to just stick with the much cushier "Founder / Leader Emeritus" job -- all the respect, none of the day-to-day hassle ;-).) In the mean time we still get his insight and other contributions, and it provides a clear period for him ease into how we do things these days, which addresses Chuck and Sebastian's concerns.
And, more importantly, it takes advantage of a unique opportunity: it takes the above negatives and turns them into positives. If later on someone feels slighted at not being on the steering council, we can say "look, even *Travis* isn't (wasn't) on the steering council -- you've misunderstood what this means", or if IBM comes calling we can say:
<NumPy> Look, if we were going to break the rules for anyone, we would have broken them for Travis. But he followed the same process as everyone else. That's how we do things around here.
I've had several long conversations with Travis recently, and one thing that's been very clear is that he still sees NumPy as being his baby and he's hungry to find ways to help it -- but maybe struggling to work out how to do that most effectively. It's a thing about babies -- eventually they grow up, become rebellious teenagers, and then -- if you did a good job parenting, and are very lucky -- they move out, have their own lives, and maybe call occasionally to ask for advice and money ;-). I'm not a parent, but I have been a child, and I understand this is often a challenging transition...
In the case of NumPy, I think the last few years have shown that the project can more-or-less grow and succeed even without Travis -- but pulling a George Washington
http://deadpresidents.tumblr.com/post/24687113413/did-washington-stepping-do... like this would make a contribution to NumPy's long-term stability in a way that only Travis can do.
----- end devil's advocate -----
Again, I want to emphasize that while I've tried to make as strong a case as I can above, my actual belief right now is that NumPy will be just fine either way -- especially if we can think of ways to address and minimize the two specific problems described above. But at the very least I wanted to make sure they were on the table as concerns.
-n
[1] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073564.html [2] https://github.com/numpy/numpy/pull/2940 [3] https://github.com/numpy/numpy/pull/2772 [4] https://github.com/numpy/numpy/issues/5844#issuecomment-141723799 [5] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073562.html [6] https://mail.python.org/pipermail/python-dev/2015-September/141609.html [7] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073582.html [8] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073748.html
-- Nathaniel J. Smith -- http://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fr, 2015-09-25 at 14:15 +0000, Thomas Caswell wrote:
To respond to the devils advocate:
Creating this organizational framework is a one time boot-strapping event. You could use wording like "The initial council will include those who have made significant contributions to numpy in the past and want to be on it" or "The initial council will be constructed by invitation by Nathaniel and Chuck". More objective criteria should be used going forward, but in terms of getting things spun up quickly doing things by fiat is probably ok. I am not even sure that the method by which the initial group is formed needs to go into the governing document.
I think you are probably right, we probably do not need to document how exactly people were picked to be in the seed. At least unless the final list creates a headache for someone in the community, in which case a formal definition may be easier for consensus. Maybe I can say that if we agree to the current proposal, and you, Travis, say that you plan to be more directly active/visible than the last few years, then I am happy if you are in the seed. Plus, I do have a feeling that this might come more easy now if we do plan more regular meetings and maybe discussions on some larger issues. However, I still do have a bit of a bad taste about doing an exception for you to stay should you not find the time. This is just because I like the current rules and do not like exceptions much. As I said, I will not get in the way of any consensus saying otherwise though and I am sure there are many ways to change the current draft that even I will like ;)! - Sebastian
I think this addresses most of the concerns, IBM is happy (enough) because this was done as part of a one-time boot strapping operation of standing the rules up and there are no explicit names in the governing documents. It also acknowledges that there is a discontinuity/singularity in the governance of the project which means you get to do singular thing :).
Tom
On Fri, Sep 25, 2015 at 8:40 AM Nathaniel Smith <njs@pobox.com> wrote:
[Travis: sorry for writing all this referring to you in third person -- I guess it might feel a bit awkward to read! You're certainly part of the intended audience, but then it felt even more awkward trying to write in second person... this is clearly a bug in English.]
Hi all,
On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant <travis@continuum.io> wrote: > As the original author of NumPy, I would like to be on the seed council as > long as it is larger than 7 people. That is my proposal. I don't need > to be a permanent member, but I do believe I have enough history that I can > understand issues even if I haven't been working on code directly. > > I think I do bring history and information that provides all of the history > that could be helpful on occasion. In addition, if a matter is important > enough to even be brought to the attention of this council, I would like to > be involved in the discussion about it.
Regarding the question of Travis being on the council:
My overall feeling on this pretty neutral: I think it won't make much of a difference to NumPy really either way, because the important thing will be Travis's insights, available time to contribute, etc., and these will (I assume) be pretty much the same regardless of whether he's on the council or not. (Any matter so intractable that it actually needs the council's emergency powers will presumably be heralded by an epic multi-month message thread of doom, plus Travis has plenty of friends on the council who know where to find him when historical insight is needed, so I'm not worried about anyone missing out on a chance to be involved.) I'm sure we can make it work either way.
But, I want to play devil's advocate for a bit, because there are some connected issues that IMHO we should at least think through if we're going to do this, and I think the easiest way to do that is to try and articulate the case against. So, here's the case against Travis being on the steering council immediately + an alternative option for comparison:
----- begin devil's advocate -----
First, just as a procedural matter, it seems clear that putting Travis on the council now will require changing the document in ways that violate Sebastian/Chris's concept of a "no names" rule -- at least in spirit if not in letter. The problem isn't just the initial council seeding; it's that Travis formally stepped down from the project more than 2.5 years ago, was mostly inactive for some time before that, and IIRC has been almost completely unheard-from between then and a few weeks ago. (Of course please correct me if I'm forgetting something, and obviously I'm talking with respect to numpy only -- clearly Travis has been doing tons of great things, but while numpy certainly benefits from e.g. the existence of NumFOCUS, creating NumFOCUS doesn't really feel like what we mean by "project activity" :-).)
This means that as currently written, it's pretty unambiguous: he doesn't qualify to be added by the normal nomination process (requires "sustained" activity over the last year), and if he were added anyway (e.g. as part of the seed council) then according to the rules he would then be immediately removed for inactivity (requires being active within the last 1 year, or else within the 2 years plus affirmation that they planned to "return to active participation soon" -- this post hoc analysis requires a bit of squinting to apply at all, but it's pretty hard to reconcile with >2 years inactivity + his "moving on from numpy to blaze" post). To avoid referencing him by name we could add some text about "founding developers" or something as a fig leaf, but judging from Robert's last email it sounds like Travis is the only person in question, so this really would just be a fig leaf.
Of course we have the option of modifying the rules to make this work -- I'm not really sure how to do this, but it's our text and I'm sure we can make it do whatever we want somehow. But any kinds of special case modifications for a single person create two problems:
1) Given that whether or not Travis is listed on the steering council probably won't affect the project much or at all, it could easily appear to an outside observer that the purpose of these rules changes was not to benefit NumPy, but only to benefit Travis's ego. Not that there's anything wrong with massaging Travis's ego :-). BUT, it sends a clear message (whether we mean it that way or not): that we think being on the steering council should affect one's ego. And there *is* something very wrong with this *message*.
It's crucial that serving on the steering council be understood to be a job, not a privilege -- sort of like being release manager. It's an important and valued job, we're glad people volunteer, but it's an absolutely fundamental rule that council members do *not* get any special treatment outside of specific limited circumstances. If being on the steering council becomes a trophy or judgement of worth, and being left off it becomes an insult that implies someone's contributions are less worthy, then we are starting down the slippery slope that Matthew worries about, where there's an unspoken class distinction between the "important contributors" and "everyone else". This exact problem has destroyed the community in many F/OSS projects (see: BSDs, XFree86, lots of modern corporate-controlled projects).
Emotions get high in these discussions, but it's important to remember that at the end of the day all this "steering council" stuff is just some bureaucracy we need to get organized so that we can get back to the real work that matters -- no-one's worth is up for debate, and the steering council is just one part of the whole project. And not even the most important part.
2) If we change the rules in one case, then it's hard to prove to outside observers that the rules really are the rules and are really applied equally to everyone. Brian Granger was telling us at SciPy how this has been a major challenge for Jupyter/IPython when working with large companies -- they really want to have confidence in the governance structure before they get involved. We don't want to end up in a conversation like:
<IBM> We'd like to contribute, but first we'd like some evidence that you're really a robust independent project and not subject to corporate capture. <NumPy> Well, here's our governance document, it clearly lays out the rules for contributions, and in particular how corporate contributions get no special privileges... <IBM> Sure, that's what it says, but the first time a well-connected CEO who employs the leaders of substantial portions of the numerical ecosystem asked, you changed the rules to give him special privileges. <NumPy> Well, yes, but that was an extremely special case that had nothing to do with the corporate stuff you just said -- it was because Travis is just that awesome. <IBM> Well, we are a faceless corporate monolith and have no idea who this Travis guy is, but okay, fine, he's just that awesome. Is anyone else that awesome? Where's the line -- what other special cases are there that are special enough to break the rules? The next time one comes up, will you follow the rules that you wrote down or do something else? <NumPy> ...we're not sure?
...that would kind of suck.
So those are two problems that would apply for any special cases added to the rules, regardless of who particularly they were for.
There's also the further concern that the steering council's main job is to "provide useful guidance, both technical and in terms of project direction, to potentially less experienced contributors" and "facilitate the ordinary community-based decision making procedure", and in Travis's case in particular, it's sort of unclear whether he's the best person for these jobs right now. Between his limited time (e.g. "I don't have time myself to engage in the community process" [1]) and the way the project has changed since he was actively involved, interactions in recent years have tended to be a bit awkward -- not because of any wrong-doing on anyone's part, but just because we're generally out-of-sync, resulting in e.g. self-merged pull requests [2][3] [glad to hear you don't do this anymore though!], or struggles to contribute to discussions based on limited context [4], or emails [5][6] that scare Chris Barker [7]. And usually with these kinds of discussions (e.g. for commit rights) you get enthusiastic unanimity, so Sebastian's unusually frank concerns give me serious pause [8]. Everyone else on the proposed steering council list certainly doesn't agree about everything, but we do all have ongoing relationships from interacting on the tracker and mailing list, making day-to-day decisions, and it's not clear to me that Travis even wants/is able to participate at that level currently.
So what's the alternative option? I'd suggest: Keep the Jupyer/IPython rules for council member eligibility, and add Travis in a year when he becomes eligible by those rules. (Assuming he remains active and interested -- personally in his position I'd be tempted to just stick with the much cushier "Founder / Leader Emeritus" job -- all the respect, none of the day-to-day hassle ;-).) In the mean time we still get his insight and other contributions, and it provides a clear period for him ease into how we do things these days, which addresses Chuck and Sebastian's concerns.
And, more importantly, it takes advantage of a unique opportunity: it takes the above negatives and turns them into positives. If later on someone feels slighted at not being on the steering council, we can say "look, even *Travis* isn't (wasn't) on the steering council -- you've misunderstood what this means", or if IBM comes calling we can say:
<NumPy> Look, if we were going to break the rules for anyone, we would have broken them for Travis. But he followed the same process as everyone else. That's how we do things around here.
I've had several long conversations with Travis recently, and one thing that's been very clear is that he still sees NumPy as being his baby and he's hungry to find ways to help it -- but maybe struggling to work out how to do that most effectively. It's a thing about babies -- eventually they grow up, become rebellious teenagers, and then -- if you did a good job parenting, and are very lucky -- they move out, have their own lives, and maybe call occasionally to ask for advice and money ;-). I'm not a parent, but I have been a child, and I understand this is often a challenging transition...
In the case of NumPy, I think the last few years have shown that the project can more-or-less grow and succeed even without Travis -- but pulling a George Washington http://deadpresidents.tumblr.com/post/24687113413/did-washington-stepping-do... like this would make a contribution to NumPy's long-term stability in a way that only Travis can do.
----- end devil's advocate -----
Again, I want to emphasize that while I've tried to make as strong a case as I can above, my actual belief right now is that NumPy will be just fine either way -- especially if we can think of ways to address and minimize the two specific problems described above. But at the very least I wanted to make sure they were on the table as concerns.
-n
[1] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073564.html [2] https://github.com/numpy/numpy/pull/2940 [3] https://github.com/numpy/numpy/pull/2772 [4] https://github.com/numpy/numpy/issues/5844#issuecomment-141723799 [5] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073562.html [6] https://mail.python.org/pipermail/python-dev/2015-September/141609.html [7] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073582.html [8] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073748.html
-- Nathaniel J. Smith -- http://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Sep 25, 2015 at 7:15 AM, Thomas Caswell <tcaswell@gmail.com> wrote:
To respond to the devils advocate:
Creating this organizational framework is a one time boot-strapping event. You could use wording like "The initial council will include those who have made significant contributions to numpy in the past and want to be on it" or "The initial council will be constructed by invitation by Nathaniel and Chuck". More objective criteria should be used going forward, but in terms of getting things spun up quickly doing things by fiat is probably ok. I am not even sure that the method by which the initial group is formed needs to go into the governing document.
The problem is that according to the current text, not only is Travis ineligible to join the council (it's a little weird to put people on the seed council who wouldn't be eligible to join it normally, but okay, sure) -- he's not even eligible to stay on the council once he joins. So we would need to change the text no matter what. Which we can do, if we decide that that's what we need to do to accomplish what we want. It's our text, after all. I think it's extremely important though that what we actually do, and what we write down saying we will do, somehow match. Otherwise this whole exercise has no point. -n -- Nathaniel J. Smith -- http://vorpus.org
Thanks for the candid discussion and for expressing concerns freely. I think Nathaniel's "parenting" characterization of NumPy from me is pretty accurate. I do feel a responsibility for the *stuff* that's out there, and that is what drives me. I do see the many contributions from others and really learn from them as well. I have seen conversations on this list and others have characterizations of history that I don't agree with which affects decisions that are being made --- and so I feel compelled to try and share my view. I'm in a situation now where at least for 6 months or so I can help with NumPy more than I have been able to for 7 years. Focusing on the initial governance text, my issues are that 1) 1 year of inactivity to be removed from the council is too little for a long-running project like NumPy --- somewhere between 2 and 4 years would be more appropriate. I suppose 1 year of inactivity is fine if that is defined only as "failure to vote on matters before the council" 2) The seed council should not just be recent contributors but should include as many people as are willing to help who have a long history with the project. 3) I think people who contribute significantly generally should be able to re-join the steering council more easily than "going through the 1-year vetting process" again --- they would have to be approved by the current steering council but it should not be automatically disallowed (thus requiring the equivalent of an amendment to change it). I applaud the fact that the steering council will not be and should not be used except when absolutely necessary and for limited functions. Thanks, -Travis On Tue, Sep 29, 2015 at 4:06 AM, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Sep 25, 2015 at 7:15 AM, Thomas Caswell <tcaswell@gmail.com> wrote:
To respond to the devils advocate:
Creating this organizational framework is a one time boot-strapping event. You could use wording like "The initial council will include those who have made significant contributions to numpy in the past and want to be on it" or "The initial council will be constructed by invitation by Nathaniel and Chuck". More objective criteria should be used going forward, but in terms of getting things spun up quickly doing things by fiat is probably ok. I am not even sure that the method by which the initial group is formed needs to go into the governing document.
The problem is that according to the current text, not only is Travis ineligible to join the council (it's a little weird to put people on the seed council who wouldn't be eligible to join it normally, but okay, sure) -- he's not even eligible to stay on the council once he joins. So we would need to change the text no matter what.
Which we can do, if we decide that that's what we need to do to accomplish what we want. It's our text, after all. I think it's extremely important though that what we actually do, and what we write down saying we will do, somehow match. Otherwise this whole exercise has no point.
-n
-- Nathaniel J. Smith -- http://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
-- *Travis Oliphant* *Co-founder and CEO* @teoliphant 512-222-5440 http://www.continuum.io
On Tue, Sep 29, 2015 at 7:32 AM, Travis Oliphant <travis@continuum.io> wrote:
I'm in a situation now where at least for 6 months or so I can help with NumPy more than I have been able to for 7 years.
great news!
1) 1 year of inactivity to be removed from the council is too little for a long-running project like NumPy
I always read this as "activity in council matters", not "activity in commits to the code". If that's not what is meant, then we should re-write that. So no, Travis is not ineligible for the council, as there has been no council to be active on. And in that case, my vague memory is that Travis has popped his head into architecture discussions on this list at least once a year essentially forever, so there is every indication that he has been and will be active in that sense. --- somewhere between 2 and 4 years would be more appropriate. I suppose
1 year of inactivity is fine if that is defined only as "failure to vote on matters before the council"
exactly. -- I wld expand "activity" to mean more than voting, but that's the idea. More like active participation in discussions / issues, and/or attending meetings, if there are any.
2) The seed council should not just be recent contributors but should include as many people as are willing to help who have a long history with the project.
again, I don't think we need so much emphasis in the "seed council" that is only needed to have SOME way to start. Though I guess as long as we're having the discussion, we should have an outline of the expectations for the council in general, which should indeed include a couple members with long history.
3) I think people who contribute significantly generally should be able to re-join the steering council more easily than "going through the 1-year vetting process" again --- they would have to be approved by the current steering council but it should not be automatically disallowed (thus requiring the equivalent of an amendment to change it).
Sure -- give the Council Flexibility to keep the council current. However, the idea here is that we want some continuity -- not have people popping on and off the council on short time spans as their schedules allow. -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
Hi Nathaniel, Piping in again from the outside: being on council would certainly seem to be a job not a privilege, and I suspect it will be hard enough to find people willing to actually put in work to worry about restricting membership overly. Given this, my suggestion would be to have a general, no-name escape clause to the rules, stating that anybody who does not formally meet the rules is welcome to *volunteer* being on the council, with a suggestion on what s/he might contribute, and the existing council can then decide whether or not that contribution is welcome. My sense would be that any time this happens one will be most happy to accept. All the best, Marten p.s. Independently of rules, I don't see how Travis would not qualify even from current work, given that he has just committed to actively try to improve/generalize dtype.
On Fri, Sep 25, 2015 at 7:25 AM, Marten van Kerkwijk <m.h.vankerkwijk@gmail.com> wrote: [...]
p.s. Independently of rules, I don't see how Travis would not qualify even from current work, given that he has just committed to actively try to improve/generalize dtype.
Just to clarify what's happening here (at least as I understand it -- hopefully Travis / Continuum folks will be in communication with the community at some point), it sounds like the plan is not so much that Travis will be working on the dtype stuff (he has no time) as that he's hiring other people to work on it: "Travis (Continuum) is working with 3 part-time people (currently Kerry Oliphant, Christian Tismer and Yarko Tymciurak) with additional advisement from Irwin Zaid, Jeff Reback, and Antoine Pitrou. The target of this effort is two Python packages (currently called memtype and gufunc) which could serve as prototypes and/or scaffolding and/or implementations of the same ideas that get into NumPy. They will be working and communicating with the NumPy community. Travis's brother, Kerry Oliphant, is leading the group and tasked with communicating with the broader community about the activities of this team." -- https://bids.hackpad.com/Python-Stack-Refactoring-uU9RVWkMc0J So this seems orthogonal to the steering council discussion -- decisions about steering council membership are 100% about actual work done by actual individuals, without any regard to who is writing checks to whom. (This is a key part of the whole maintaining-independence, keeping-corporate-influence-at-arms-length aspect of the governance plan.) (It also sounds like Continuum's current plan is that instead of improving numpy directly, they will be off building a toy array library to explore the idea of implementing this stuff directly in the core interpreter as builtin types. And in parallel, those of us who are interested in this stuff in numpy will be getting to work on actually implementing new dtype stuff in numpy. And I guess at some point we'll compare notes and see how close our two implementations ended up being in retrospect? Right now I don't understand any path for their work to be useful to numpy, and it sounds like for now the numpy team should just proceed with our existing refactoring plans on the assumption that nothing will come of the Continuum work, and if that's wrong then it will be a pleasant surprise. But Travis is aware of my thoughts here and keen to do it this way anyway, and it's their money and time, so, up to them really...) -n -- Nathaniel J. Smith -- http://vorpus.org
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
participants (9)
-
Charles R Harris -
Chris Barker -
David Cournapeau -
Jaime Fernández del Río -
Marten van Kerkwijk -
Nathaniel Smith -
Sebastian Berg -
Thomas Caswell -
Travis Oliphant