[Numpy-discussion] composition of the steering council (was Re: Governance model request)

[Nathaniel Smith]

[splitting this out from the thread-o-doom]

On Wed, Sep 23, 2015 at 8:47 AM, Chris Barker - NOAA Federal
<***@noaa.gov> wrote:
[snip]

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

[Thomas Caswell]

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

Post by Nathaniel Smith
[splitting this out from the thread-o-doom]
On Wed, Sep 23, 2015 at 8:47 AM, Chris Barker - NOAA Federal
[snip]

-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
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".
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
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
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Travis Oliphant]

Post by Nathaniel Smith
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
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

[Chris Barker]

Post by Travis Oliphant
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. :-)

Post by Travis Oliphant
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 [phone] voice
7600 Sand Point Way NE [phone] fax
Seattle, WA 98115 [phone] main reception

***@noaa.gov

[Charles R Harris]

Post by Chris Barker

Post by Travis Oliphant
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.

Post by Chris Barker
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. :-)

Post by Travis Oliphant
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

[Travis Oliphant]

Post by Charles R Harris

Post by Chris Barker

Post by Travis Oliphant
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.

Post by Charles R Harris

Post by Chris Barker
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. :-)

Post by Travis Oliphant
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

Post by Charles R Harris
Chuck
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Sebastian Berg]

On Wed, Sep 23, 2015 at 6:19 PM, Charles R Harris
On Wed, Sep 23, 2015 at 3:42 PM, Chris Barker
On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant
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
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
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Charles R Harris]

Post by Travis Oliphant

Post by Nathaniel Smith
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
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

[Jaime Fernández del Río]

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

Post by Charles R Harris

Post by Travis Oliphant

Post by Nathaniel Smith
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
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
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Charles R Harris]

On Wed, Sep 23, 2015 at 5:41 PM, Jaime Fernández del Río <

Post by Jaime Fernández del Río
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 ;)

Post by Jaime Fernández del Río
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

[Travis Oliphant]

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

Post by Charles R Harris

Post by Travis Oliphant

Post by Nathaniel Smith
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
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
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Sebastian Berg]

Post by Nathaniel Smith
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

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.

Post by Nathaniel Smith
Chuck
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[David Cournapeau]

Post by Sebastian Berg

Post by Nathaniel Smith
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

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

Post by Sebastian Berg
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
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.

Post by Nathaniel Smith
Chuck
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Nathaniel Smith]

On Thu, Sep 24, 2015 at 10:45 AM, Sebastian Berg

[...]

Post by Sebastian Berg
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

[Travis Oliphant]

Post by Sebastian Berg
[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
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

Post by Sebastian Berg

Post by Nathaniel Smith
Chuck
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Nathaniel Smith]

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

Post by Travis Oliphant
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-down-after-2-terms-impact
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

[Thomas Caswell]

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

Post by Nathaniel Smith
[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,

Post by Travis Oliphant
As the original author of NumPy, I would like to be on the seed council

as

Post by Travis Oliphant
long as it is larger than 7 people. That is my proposal. I don't

need

Post by Travis Oliphant
to be a permanent member, but I do believe I have enough history that I

can

Post by Travis Oliphant
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

Post by Travis Oliphant
that could be helpful on occasion. In addition, if a matter is

important

Post by Travis Oliphant
enough to even be brought to the attention of this council, I would like

to

Post by Travis Oliphant
be involved in the discussion about it.

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
----- 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
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
<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
<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-down-after-2-terms-impact
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
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Sebastian Berg]

Post by Thomas Caswell
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

Post by Thomas Caswell
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
[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

Post by Travis Oliphant
As the original author of NumPy, I would like to be on the

seed council as

Post by Travis Oliphant
long as it is larger than 7 people. That is my proposal.

I don't need

Post by Travis Oliphant
to be a permanent member, but I do believe I have enough

history that I can

Post by Travis Oliphant
understand issues even if I haven't been working on code

directly.

Post by Travis Oliphant
I think I do bring history and information that provides all

of the history

Post by Travis Oliphant
that could be helpful on occasion. In addition, if a

matter is important

Post by Travis Oliphant
enough to even be brought to the attention of this council,

I would like to

Post by Travis Oliphant
be involved in the discussion about it.

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
----- 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
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
<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
<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-down-after-2-terms-impact
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
https://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Nathaniel Smith]

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

[Travis Oliphant]

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

Post by Thomas Caswell

Post by Thomas Caswell
Creating this organizational framework is a one time boot-strapping

event.

Post by Thomas Caswell
You could use wording like "The initial council will include those who

have

Post by Thomas Caswell
made significant contributions to numpy in the past and want to be on

it" or

Post by Thomas Caswell
"The initial council will be constructed by invitation by Nathaniel and
Chuck". More objective criteria should be used going forward, but in

terms

Post by Thomas Caswell
of getting things spun up quickly doing things by fiat is probably ok.

I am

Post by Thomas Caswell
not even sure that the method by which the initial group is formed needs

to

Post by Thomas Caswell
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
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Chris Barker]

Post by Travis Oliphant
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!

Post by Travis Oliphant
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

Post by Travis Oliphant
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.

Post by Travis Oliphant
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.

Post by Travis Oliphant
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 [phone] voice
7600 Sand Point Way NE [phone] fax
Seattle, WA 98115 [phone] main reception

***@noaa.gov

[Marten van Kerkwijk]

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.

[Nathaniel Smith]

On Fri, Sep 25, 2015 at 7:25 AM, Marten van Kerkwijk
<***@gmail.com> wrote:
[...]

Post by Marten van Kerkwijk
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

[Chris Barker]

Post by Nathaniel Smith

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.

Post by Nathaniel Smith
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...

Post by Nathaniel Smith
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

Post by Nathaniel Smith
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

Post by Nathaniel Smith
the exact details really aren't going to matter much in the end.

agreed -- it's kind of a self-regulating Oligarchy...

Post by Nathaniel Smith
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 :-)

Post by Nathaniel Smith
I'm a little wary of the idea of capping the council size.

...

Judging whether

Post by Nathaniel Smith
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.

Post by Nathaniel Smith
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 :-)

Post by Nathaniel Smith
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.

Post by Nathaniel Smith

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.

Post by Nathaniel Smith

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

Post by Nathaniel Smith
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 :-)

Post by Nathaniel Smith
(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.

Post by Nathaniel Smith
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 [phone] voice
7600 Sand Point Way NE [phone] fax
Seattle, WA 98115 [phone] main reception

***@noaa.gov