Re: [Numpy-discussion] Governance model request

[Fernando Perez]

Hi all,

I would like to pitch in here, I am sorry that I didn't have the time
before...

First, I want to disclose that recently Continuum made a research gift to
the Jupyter project; we were just now writing up a blog post to acknowledge
this, but in light of this discussion, I feel that I should say this up
front so folks can gauge any potential bias accordingly.


On Tue, Sep 22, 2015 at 3:44 AM, Travis Oliphant 
wrote:

> I'm actually offended that so many at BIDS seem eager to crucify my
> intentions when I've done nothing but give away my time, my energy, my
> resources, and my sleep to NumPy for many, many years.I guess if your
> intent is to drive me away, then you are succeeding.


Travis, first, I'd like to kindly ask you not to conflate BIDS, an
institution where a large number of people work, with the personal opinions
of some, who happen to work there but in this case are speaking only for
themselves.  You say "so many at BIDS", but as far as I know, your
disagreements are with Stefan and Nathaniel (Matthew doesn't work at
BIDS).  You are painting with a very wide brush the work of many people,
and in the process, unfairly impacting others who have nothing to do with
this.

If anything, the only things I'm aware BIDS has done in an official
capacity regarding you or Continuum is to offer hosting for Continuum
developers at the DS4DS workshop and beyond (after an explicit request by
Matt Rocklin, and one we were delighted to honor), and our hosting of your
lecture in our Friday Data Science Lecture Series last week.

With that out of the way...


1. I hope the discussion can move past the suspicion and innuendo about
Continuum and Travis.  I haven't always agreed with how Travis communicates
some of his ideas, and I've said it to him in such instances (e.g. this
weekend, as I myself was surprised at how his last round of comments had
landed on the list a few days back).  But I also have worked closely with
him for years because I know that he has proven, not in words, but in
actions, that he has the best interests of our community at heart, and that
he is willing to try and do everything in his power to help whenever he
can.

When we founded Numfocus back in 2012, it would have been impossible for it
to really bootstrap without Travis' generosity, since he effectively footed
the bill for resources that were critically needed at the start. And yet,
he was always willing to take every step necessary to help Numfocus grow
independent of Continuum, so that it could be a real community asset:
today, there's not a single Continuum employee on the NF board (Travis and
I both resigned from the board a while back to allow for some fresh blood).

The creation and open-sourcing of conda has also been a critical
contribution, that I know many of us have benefited from: we all carry the
scars from the python packaging horror shows, and conda/anaconda has been a
life-changer. The fact that conda itself is open, means we have a core tool
that we can build upon.

To put it bluntly, few people in the whole world have given more of their
life, energy and resources to our community than Travis, and have done so
as generously as he has.  He may have made mistakes, and again, I often
disagree with how he communicates.  But accusations and innuendo like the
ones in this thread are damaging, hurtful and useless.  And one thing that
I hope people will remember is that, famous and powerful as Travis may be,
he's still our colleague, a member of our community, and *a human being*,
so let's remember that as well...


2. Conflicts of interest are a fact of life, in fact, I would argue that
every healthy and sufficiently interconnected community eventually *should*
have conflicts of interest. They are a sign that there is activity across
multiple centers of interest, and individuals with connections in multiple
areas of the community.  And we *want* folks who are engaged enough
precisely to have such interests!

For conflict of interest management, we don't need to reinvent the wheel,
this is actually something where our beloved institutions, blessed be their
bureaucratic souls, have tons of training materials that happen to be not
completely useless.  Most universities and the national labs have
information on COIs that provides guidelines, and Numpy could include in
its governance model more explicit language about COIs if desired.

So, the issue is not to view COIs as something evil or undesirable, but
rather as the very real consequence of operating in an interconnected set
of institutions.  And once you take that stance, you deal with that
rationally and realistically.

For example, you accept that companies aren't the only ones with potential
COIs: *all* entities have them. As Ryan May aptly pointed out, the notion
that academic institutions are somehow immune to hidden agendas or other
interests is naive at best... And I say that as someone who has happily
stayed in academia, resisting multiple overtures from i

[Numpy-discussion] Steering Committee Size

[Sebastian Berg]

Hi,

Trying to figure out at least a bit from  the discussions. While I am happy 
with the draft, I wonder if someone has some insights about some questions:

1. How large crowds have examples of working well with apache style voting?
2. How large do we expect numpy steering council to be (I have always thought 
about 10).
3. More on  opinions, how large does the community feel is too large (so that 
we should maybe elect people).

And to maybe more a discussion point, does the community feel that those who 
would be/are affectivly now in the Steering Council do not sufficiently 
represent old time contributers who were not active in the past year(s).

I cannot form/change my opinion based on the previous discussion, because I 
would like to get an idea of how everyone feels about these points first. Then 
we can fight about details :)

- Sebastian

(sending from phone, so sorry about eventual weird typos)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Tentative numpy tutorial

[Dan Patterson]

Bryan is this the tutorial to which you refer? 
http://docs.scipy.org/doc/scipy/reference/tutorial/index.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Governance model request

[Francesc Alted]

Hi Fernando,

I am happy that you decided to chime in here.  This thread derailed in a
bad way and I hope that your wise words will help to redress the situation.

In fact, I would like to propose you having part of a future steering
committee of NumPy.  I know that you may never have been implied in the
hard core development of NumPy, but my perception is that your opinions are
highly respected by almost everybody in the NumPy ecosystem.  More than
that, you have this rare ability of being able to get both a donation from
Microsoft and at the same time (same year?) being awarded by the FSF, which
frankly, is not an easy thing to do ;)

Just to clear, I am not saying that you should act as the person for
deciding the roadmap for NumPy at all, but a person that should be in
charge of acting as an independent referee in the foreseeable Conflicts of
Interest in the NumPy roadmap.

Sorry if that means more work for you Fernando, because I know that you
have become a very busy person, but I also know how much do you care about
the NumPy ecosystem, and IMHO the NumPy community needs a person like you
*now*.

Francesc

2015-09-23 10:02 GMT+02:00 Fernando Perez :

> Hi all,
>
> I would like to pitch in here, I am sorry that I didn't have the time
> before...
>
> First, I want to disclose that recently Continuum made a research gift to
> the Jupyter project; we were just now writing up a blog post to acknowledge
> this, but in light of this discussion, I feel that I should say this up
> front so folks can gauge any potential bias accordingly.
>
>
> On Tue, Sep 22, 2015 at 3:44 AM, Travis Oliphant 
> wrote:
>
>> I'm actually offended that so many at BIDS seem eager to crucify my
>> intentions when I've done nothing but give away my time, my energy, my
>> resources, and my sleep to NumPy for many, many years.I guess if your
>> intent is to drive me away, then you are succeeding.
>
>
> Travis, first, I'd like to kindly ask you not to conflate BIDS, an
> institution where a large number of people work, with the personal opinions
> of some, who happen to work there but in this case are speaking only for
> themselves.  You say "so many at BIDS", but as far as I know, your
> disagreements are with Stefan and Nathaniel (Matthew doesn't work at
> BIDS).  You are painting with a very wide brush the work of many people,
> and in the process, unfairly impacting others who have nothing to do with
> this.
>
> If anything, the only things I'm aware BIDS has done in an official
> capacity regarding you or Continuum is to offer hosting for Continuum
> developers at the DS4DS workshop and beyond (after an explicit request by
> Matt Rocklin, and one we were delighted to honor), and our hosting of your
> lecture in our Friday Data Science Lecture Series last week.
>
> With that out of the way...
>
>
> 1. I hope the discussion can move past the suspicion and innuendo about
> Continuum and Travis.  I haven't always agreed with how Travis communicates
> some of his ideas, and I've said it to him in such instances (e.g. this
> weekend, as I myself was surprised at how his last round of comments had
> landed on the list a few days back).  But I also have worked closely with
> him for years because I know that he has proven, not in words, but in
> actions, that he has the best interests of our community at heart, and that
> he is willing to try and do everything in his power to help whenever he
> can.
>
> When we founded Numfocus back in 2012, it would have been impossible for
> it to really bootstrap without Travis' generosity, since he effectively
> footed the bill for resources that were critically needed at the start. And
> yet, he was always willing to take every step necessary to help Numfocus
> grow independent of Continuum, so that it could be a real community asset:
> today, there's not a single Continuum employee on the NF board (Travis and
> I both resigned from the board a while back to allow for some fresh blood).
>
> The creation and open-sourcing of conda has also been a critical
> contribution, that I know many of us have benefited from: we all carry the
> scars from the python packaging horror shows, and conda/anaconda has been a
> life-changer. The fact that conda itself is open, means we have a core tool
> that we can build upon.
>
> To put it bluntly, few people in the whole world have given more of their
> life, energy and resources to our community than Travis, and have done so
> as generously as he has.  He may have made mistakes, and again, I often
> disagree with how he communicates.  But accusations and innuendo like the
> ones in this thread are damaging, hurtful and useless.  And one thing that
> I hope people will remember is that, famous and powerful as Travis may be,
> he's still our colleague, a member of our community, and *a human being*,
> so let's remember that as well...
>
>
> 2. Conflicts of interest are a fact of life, in fact, I would argue that
> every healthy and sufficiently interconnected comm

[Numpy-discussion] ANN: SfePy 2015.3

[Robert Cimrman]

I am pleased to announce release 2015.3 of SfePy.

Description
---

SfePy (simple finite elements in Python) is a software for solving systems of
coupled partial differential equations by the finite element method or by the
isogeometric analysis (preliminary support). It is distributed under the new
BSD license.

Home page: http://sfepy.org
Mailing list: http://groups.google.com/group/sfepy-devel
Git (source) repository, issue tracker, wiki: http://github.com/sfepy

Highlights of this release
--

- preliminary support for parallel computing
- unified evaluation of basis functions (= isogeometric analysis fields can be
  evaluated in arbitrary points)
- (mostly) fixed finding of reference element coordinates of physical points
- several new or improved examples

For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1
(rather long and technical).

Best regards,
Robert Cimrman on behalf of the SfePy development team

---

Contributors to this release in alphabetical order:

Robert Cimrman
Vladimir Lukes
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Governance model request

[Sebastian Berg]

On Wed Sep 23 12:39:59 2015 GMT+0200, Francesc Alted wrote:
> Hi Fernando,
> 
> I am happy that you decided to chime in here.  This thread derailed in a
> bad way and I hope that your wise words will help to redress the situation.
> 
> In fact, I would like to propose you having part of a future steering
> committee of NumPy.  I know that you may never have been implied in the
> hard core development of NumPy, but my perception is that your opinions are
> highly respected by almost everybody in the NumPy ecosystem.  More than
> that, you have this rare ability of being able to get both a donation from
> Microsoft and at the same time (same year?) being awarded by the FSF, which
> frankly, is not an easy thing to do ;)
> 
> Just to clear, I am not saying that you should act as the person for
> deciding the roadmap for NumPy at all, but a person that should be in
> charge of acting as an independent referee in the foreseeable Conflicts of
> Interest in the NumPy roadmap.
>

Is it ok if I get a bit angry soon ;)? We can find many great community 
leaders. But please tell me that you all feel that numpy is so central or 
whatever that these community leaders should be in some sense in charge of 
numpy. I am ready to accept that and maybe it can be helpful, and a huge gain 
for numpy, but I would like to see a clear statement and reasons.

I like Fernandos mail, too, nor do I doubt Travis achievements. But discussing 
who is great community leader, etc. is frankly not obvious to me related to 
numpy governance. Now if you say:

Guys, you should have some community leader guidance in numpy, then we can 
discuss who. But to me it is not obvious that community leaders who are *not* 
directly active in numpy should be explicitely in governance. I am aware that 
everyone wants to help, but right now I do not feel helped at all :). 

- Sebastian
 
> Sorry if that means more work for you Fernando, because I know that you
> have become a very busy person, but I also know how much do you care about
> the NumPy ecosystem, and IMHO the NumPy community needs a person like you
> *now*.
> 
> Francesc
> 
> 2015-09-23 10:02 GMT+02:00 Fernando Perez :
> 
> > Hi all,
> >
> > I would like to pitch in here, I am sorry that I didn't have the time
> > before...
> >
> > First, I want to disclose that recently Continuum made a research gift to
> > the Jupyter project; we were just now writing up a blog post to acknowledge
> > this, but in light of this discussion, I feel that I should say this up
> > front so folks can gauge any potential bias accordingly.
> >
> >
> > On Tue, Sep 22, 2015 at 3:44 AM, Travis Oliphant 
> > wrote:
> >
> >> I'm actually offended that so many at BIDS seem eager to crucify my
> >> intentions when I've done nothing but give away my time, my energy, my
> >> resources, and my sleep to NumPy for many, many years.I guess if your
> >> intent is to drive me away, then you are succeeding.
> >
> >
> > Travis, first, I'd like to kindly ask you not to conflate BIDS, an
> > institution where a large number of people work, with the personal opinions
> > of some, who happen to work there but in this case are speaking only for
> > themselves.  You say "so many at BIDS", but as far as I know, your
> > disagreements are with Stefan and Nathaniel (Matthew doesn't work at
> > BIDS).  You are painting with a very wide brush the work of many people,
> > and in the process, unfairly impacting others who have nothing to do with
> > this.
> >
> > If anything, the only things I'm aware BIDS has done in an official
> > capacity regarding you or Continuum is to offer hosting for Continuum
> > developers at the DS4DS workshop and beyond (after an explicit request by
> > Matt Rocklin, and one we were delighted to honor), and our hosting of your
> > lecture in our Friday Data Science Lecture Series last week.
> >
> > With that out of the way...
> >
> >
> > 1. I hope the discussion can move past the suspicion and innuendo about
> > Continuum and Travis.  I haven't always agreed with how Travis communicates
> > some of his ideas, and I've said it to him in such instances (e.g. this
> > weekend, as I myself was surprised at how his last round of comments had
> > landed on the list a few days back).  But I also have worked closely with
> > him for years because I know that he has proven, not in words, but in
> > actions, that he has the best interests of our community at heart, and that
> > he is willing to try and do everything in his power to help whenever he
> > can.
> >
> > When we founded Numfocus back in 2012, it would have been impossible for
> > it to really bootstrap without Travis' generosity, since he effectively
> > footed the bill for resources that were critically needed at the start. And
> > yet, he was always willing to take every step necessary to help Numfocus
> > grow independent of Continuum, so that it could be a real community asset:
> > today, there's not a single Continuum employee on the NF board (Travis and
> >

Re: [Numpy-discussion] Governance model request

[Fernando Perez]

On Wed, Sep 23, 2015 at 6:55 AM, Sebastian Berg 
wrote:

> Is it ok if I get a bit angry soon ;)?


Don't worry, Sebastian :)

I appreciate Francesc's kind words, but I have no intention of imposing my
presence anywhere, it's not like I'm looking for extra work at this point.
The process of establishing governance has to come organically from within
a community.

Cheers

-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Governance model request

[Chris Barker - NOAA Federal]

> But discussing who is great community leader, etc. is frankly not obvious to 
> me related to numpy governance.

Thank you Sebastian.

Could we please try to get back to the governance issues, without
naming names? There are some specific questions on the table that need
to get hashed out.


Numpy does not have a BDFL. BDFLs are not selected, they are naturally
produced, and there is no one that fits that bill now. We *could*
decide to have a single individual executive leader, selected by some
sort of democratic process. But that is not the same as a BDFL. And I
think the almost-consensus  now is to not have that.

So here is what I think is on the table:

We have the steering council. Which leaves two questions:

-How big should it be?
-Who will be on the original, "seed" council?

Note that as I understand the current draft of the governance doc,
once established, the council itself decides who is on the council. So
at this point we really are ONLY deciding how it's going to start. It
has to be bootstrapped somehow.

However, that had been contentious enough that it would probably be a
good idea to hash out some guidelines about the council membership.

Personally, I have no idea how big the council should be. Too big, and
there is no point, consensus is harder to reach the larger the group,
and the main (only?) role of the council is to resolve issues where
consensus has not been reached in the larger community. But what is
too big?

As for make-up of the council, I think we need to expand beyond people
who have recently contributed core code.

Yes, the council does need to have expertise to make technical
decisions, but if you think about the likely contentious issues like
ABI breakage, a core-code focused view is incomplete. So there should
be representation by:

Someone(s) with a long history of working with the code -- that
institutional memory of why decisions were made the way they were
could be key.

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.

I do want to note that the governance document as I understand it is
consistent with these suggestions.

As for conflict of interest issues, etc:

Chill out people!

Numpy is an open source project, if it gets hijacked, it can be forked.

And the council is also democratic -- no one person can drive the
project. If a council member is not acting in the interests of the
community, s/he can be removed.

NOTE: while x.org, and egcs, Xemacs, and ... may be examples of
failures of governance, they are also examples of successes of open
source.

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

Re: [Numpy-discussion] Tentative numpy tutorial

[Matthew Brett]

Hi,

On Wed, Sep 23, 2015 at 2:25 AM, Dan Patterson
 wrote:
> Bryan is this the tutorial to which you refer? 
> http://docs.scipy.org/doc/scipy/reference/tutorial/index.html
> ___

I think it is the http://wiki.scipy.org/Tentative_NumPy_Tutorial

Cheers,

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

[Numpy-discussion] ANN: numtraits v0.2

[Thomas Robitaille]

Hi everyone,

We have released a small experimental package called numtraits that
builds on top of the traitlets package and provides a NumericalTrait
class that can be used to validate properties such as:

* number of dimension (for arrays)
* shape (for arrays)
* domain (e.g. positive, negative, range of values)
* units (with support for astropy.units, pint, and quantities)

The idea is to be able to write a class like:

class Sphere(HasTraits):

radius = NumericalTrait(domain='strictly-positive', ndim=0)
position = NumericalTrait(shape=(3,))

and all the validation will then be done automatically when the user
sets 'radius' or 'position'.

In addition, tuples and lists can get automatically converted to
arrays, and default values can be specified. You can read more about
the package and see examples of it in use here:

  https://github.com/astrofrog/numtraits

and it can be easily installed with

  pip install numtraits

The package supports both Python 3.3+ and Legacy Python (2.7) :)

At this point, we would be very interested in feedback - the package
is still very young and we can still change the API if needed. Please
open issues with suggestions!

Cheers,

Tom and Francesco
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Governance model request

[Charles R Harris]

On Wed, Sep 23, 2015 at 9:47 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> > But discussing who is great community leader, etc. is frankly not
> obvious to me related to numpy governance.
>
> Thank you Sebastian.
>
> Could we please try to get back to the governance issues, without
> naming names? There are some specific questions on the table that need
> to get hashed out.
>
>
> Numpy does not have a BDFL. BDFLs are not selected, they are naturally
> produced, and there is no one that fits that bill now. We *could*
> decide to have a single individual executive leader, selected by some
> sort of democratic process. But that is not the same as a BDFL. And I
> think the almost-consensus  now is to not have that.
>
> So here is what I think is on the table:
>
> We have the steering council. Which leaves two questions:
>
> -How big should it be?
> -Who will be on the original, "seed" council?
>
> Note that as I understand the current draft of the governance doc,
> once established, the council itself decides who is on the council. So
> at this point we really are ONLY deciding how it's going to start. It
> has to be bootstrapped somehow.
>
> However, that had been contentious enough that it would probably be a
> good idea to hash out some guidelines about the council membership.
>
> Personally, I have no idea how big the council should be. Too big, and
> there is no point, consensus is harder to reach the larger the group,
> and the main (only?) role of the council is to resolve issues where
> consensus has not been reached in the larger community. But what is
> too big?
>
> As for make-up of the council, I think we need to expand beyond people
> who have recently contributed core code.
>
> Yes, the council does need to have expertise to make technical
> decisions, but if you think about the likely contentious issues like
> ABI breakage, a core-code focused view is incomplete. So there should
> be representation by:
>
> Someone(s) with a long history of working with the code -- that
> institutional memory of why decisions were made the way they were
> could be key.
>
> 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.
>
> I do want to note that the governance document as I understand it is
> consistent with these suggestions.
>
> As for conflict of interest issues, etc:
>
> Chill out people!
>
> Numpy is an open source project, if it gets hijacked, it can be forked.
>
> And the council is also democratic -- no one person can drive the
> project. If a council member is not acting in the interests of the
> community, s/he can be removed.
>
>
Hear, hear. Well put Chris. I don't disagree with any of this.


> NOTE: while x.org, and egcs, Xemacs, and ... may be examples of
> failures of governance, they are also examples of successes of open
> source.
>

Good point.

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

[Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

[Nathaniel Smith]

Hi Travis,

On Tue, Sep 22, 2015 at 3:08 AM, Travis Oliphant  wrote:
>
>
> On Tue, Sep 22, 2015 at 4:33 AM, Nathaniel Smith  wrote:
>>
>> On Tue, Sep 22, 2015 at 1:24 AM, Travis Oliphant 
>> wrote:
>>>
>>> I actually do agree with your view of the steering council as being
>>> usually not really being needed.You are creating a straw-man by
>>> indicating otherwise.I don't believe a small council should do anything
>>> *except* resolve disputes that cannot be resolved without one.  Like you, I
>>> would expect that would almost never happen --- but I would argue that
>>> extrapolating from Debian's experience is not actually relevant here.
>>
>>
>> To be clear, Debian was only one example -- what I'm extrapolating from is
>> every community-driven F/OSS project that I'm aware of.
>>
>> It's entirely possible my data set is incomplete -- if you have some other
>> examples that you think would be better to extrapolate from, then I'd be
>> genuinely glad to hear them. You may have noticed that I'm a bit of an
>> enthusiast on this topic :-).
>>
>
>
> Yes, you are much better at that than I am.   I'm not even sure where I
> would look for this kind of data.
>
>>>
>>>
>>>
>>> So, if the steering council is not really needed then why have it at all?
>>> Let's just eliminate the concept entirely.
>>>
>>
>> In my view, the reasons for having such a council are:
>> 1) The framework is useful even if you never use it, because it means
>> people can run "what if" scenarios in their mind and make decisions on that
>> basis. In the US legal system, only a vanishingly small fraction of cases go
>> to the Supreme Court -- but the rules governing the Supreme Court have a
>> huge effect on all cases, because people can reason about what would happen
>> *if* they tried to appeal to the Supreme Court.
>
>
> O.K.  That is a good point.   I can see the value in that.
>
>
>>
>> 2) It provides a formal structure for interfacing with the outside world.
>> E.g., one can't do anything with money or corporate contributions without
>> having some kind of written-down and enforceable rules for making decisions
>> (even if in practice you always stick to the "everyone is equal and we
>> govern by consensus" part of the rules).
>
>
> O.K.
>
>>
>> 3) There are rare but important cases where discussions have to be had in
>> private. The main one is "personnel decisions" like inviting people to join
>> the council; another example Fernando has mentioned to me is that when they
>> need to coordinate a press release between the project and a funding body,
>> the steering council reviews the press release before it goes public.
>
>
> O.K.
>
>
>>
>> That's pretty much it, IMO.
>>
>> The framework we all worked out at the dev meeting in Austin seems to
>> handle these cases well AFAICT.
>
>
> How did we "all" work it out when not everyone was there?   This is where I
> get lost.   You talk about community decision making and yet any actual
> decision is always a subset of the community.I suppose you just rely on
> the "if nobody complains than it's o.k." rule?   That really only works if
> the project is moving slowly.

By "all" I just meant "all of us who were there" (which was a majority
of the active maintainers + a number of other interested parties --
the list of attendees is in the meeting notes if you're curious).

In general I totally agree with your concern about only including a
subset of the community. That's why we followed up by posting to the
list a full set of notes on tentative-decisions-made, and the draft
governance document in particular, for further discussion. We've
already had multiple threads talking about it, even before this one.
And it's pretty explicit in the document itself that no non-trivial
decision can be considered final unless it's *at least* been posted on
the mailing list.

We didn't try to legislate the exact review requirements for every
decision, because it's impossible to have a set of rules that scales
from trivial typos (which just get merged, only github subscribers
even know it happened) to foundational discussions like this one. This
means that one of the things we trust contributors (esp. senior
contributors) to do is to use their knowledge of the project to make
judgement calls about how risky or controversial a given change will
be, or if there's some particular expertise that should be consulted.
(E.g. we might make sure to ping Robert Kern if there's some np.random
change being discussed; I'm hesitant to finalize the PyUFunc ABI
changes being discussed in the other thread until Ralf gets back,
because I know that among the core maintainers he's particularly
critical of the idea of breaking ABI.)

And if we new information later comes to light then a decision can
always be revisited -- people may get grumpy if you try to re-open an
issue that's been considered settled for a year, but if you have a
good reason and nothing irrevocable has happened (e.g. a veto
obviously can't remove code

Re: [Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

[Travis Oliphant]

Hi Nathaniel,

Thanks for the clarifications.   Is the governance document committed to
the repository?   I keep looking for it and have a hard time finding it ---
I think I read it last in an email.

In this way, I could make Pull Requests to the governance document if there
are concrete suggestions for change, and then have them reviewed in the
standard way.

I'm hopeful that a few tweaks to the document would satisfy all my
concerns.

Thanks,

-Travis




On Wed, Sep 23, 2015 at 1:04 PM, Nathaniel Smith  wrote:

> Hi Travis,
>
> On Tue, Sep 22, 2015 at 3:08 AM, Travis Oliphant 
> wrote:
> >
> >
> > On Tue, Sep 22, 2015 at 4:33 AM, Nathaniel Smith  wrote:
> >>
> >> On Tue, Sep 22, 2015 at 1:24 AM, Travis Oliphant 
> >> wrote:
> >>>
> >>> I actually do agree with your view of the steering council as being
> >>> usually not really being needed.You are creating a straw-man by
> >>> indicating otherwise.I don't believe a small council should do
> anything
> >>> *except* resolve disputes that cannot be resolved without one.  Like
> you, I
> >>> would expect that would almost never happen --- but I would argue that
> >>> extrapolating from Debian's experience is not actually relevant here.
> >>
> >>
> >> To be clear, Debian was only one example -- what I'm extrapolating from
> is
> >> every community-driven F/OSS project that I'm aware of.
> >>
> >> It's entirely possible my data set is incomplete -- if you have some
> other
> >> examples that you think would be better to extrapolate from, then I'd be
> >> genuinely glad to hear them. You may have noticed that I'm a bit of an
> >> enthusiast on this topic :-).
> >>
> >
> >
> > Yes, you are much better at that than I am.   I'm not even sure where I
> > would look for this kind of data.
> >
> >>>
> >>>
> >>>
> >>> So, if the steering council is not really needed then why have it at
> all?
> >>> Let's just eliminate the concept entirely.
> >>>
> >>
> >> In my view, the reasons for having such a council are:
> >> 1) The framework is useful even if you never use it, because it means
> >> people can run "what if" scenarios in their mind and make decisions on
> that
> >> basis. In the US legal system, only a vanishingly small fraction of
> cases go
> >> to the Supreme Court -- but the rules governing the Supreme Court have a
> >> huge effect on all cases, because people can reason about what would
> happen
> >> *if* they tried to appeal to the Supreme Court.
> >
> >
> > O.K.  That is a good point.   I can see the value in that.
> >
> >
> >>
> >> 2) It provides a formal structure for interfacing with the outside
> world.
> >> E.g., one can't do anything with money or corporate contributions
> without
> >> having some kind of written-down and enforceable rules for making
> decisions
> >> (even if in practice you always stick to the "everyone is equal and we
> >> govern by consensus" part of the rules).
> >
> >
> > O.K.
> >
> >>
> >> 3) There are rare but important cases where discussions have to be had
> in
> >> private. The main one is "personnel decisions" like inviting people to
> join
> >> the council; another example Fernando has mentioned to me is that when
> they
> >> need to coordinate a press release between the project and a funding
> body,
> >> the steering council reviews the press release before it goes public.
> >
> >
> > O.K.
> >
> >
> >>
> >> That's pretty much it, IMO.
> >>
> >> The framework we all worked out at the dev meeting in Austin seems to
> >> handle these cases well AFAICT.
> >
> >
> > How did we "all" work it out when not everyone was there?   This is
> where I
> > get lost.   You talk about community decision making and yet any actual
> > decision is always a subset of the community.I suppose you just rely
> on
> > the "if nobody complains than it's o.k." rule?   That really only works
> if
> > the project is moving slowly.
>
> By "all" I just meant "all of us who were there" (which was a majority
> of the active maintainers + a number of other interested parties --
> the list of attendees is in the meeting notes if you're curious).
>
> In general I totally agree with your concern about only including a
> subset of the community. That's why we followed up by posting to the
> list a full set of notes on tentative-decisions-made, and the draft
> governance document in particular, for further discussion. We've
> already had multiple threads talking about it, even before this one.
> And it's pretty explicit in the document itself that no non-trivial
> decision can be considered final unless it's *at least* been posted on
> the mailing list.
>
> We didn't try to legislate the exact review requirements for every
> decision, because it's impossible to have a set of rules that scales
> from trivial typos (which just get merged, only github subscribers
> even know it happened) to foundational discussions like this one. This
> means that one of the things we trust contributors (esp. senior
> contributors) to do is to use their knowledge o

Re: [Numpy-discussion] Governance model request

[Travis Oliphant]

On Wed, Sep 23, 2015 at 3:02 AM, Fernando Perez 
wrote:

> Hi all,
>
> I would like to pitch in here, I am sorry that I didn't have the time
> before...
>
> First, I want to disclose that recently Continuum made a research gift to
> the Jupyter project; we were just now writing up a blog post to acknowledge
> this, but in light of this discussion, I feel that I should say this up
> front so folks can gauge any potential bias accordingly.
>
>
> On Tue, Sep 22, 2015 at 3:44 AM, Travis Oliphant 
> wrote:
>
>> I'm actually offended that so many at BIDS seem eager to crucify my
>> intentions when I've done nothing but give away my time, my energy, my
>> resources, and my sleep to NumPy for many, many years.I guess if your
>> intent is to drive me away, then you are succeeding.
>
>
> Travis, first, I'd like to kindly ask you not to conflate BIDS, an
> institution where a large number of people work, with the personal opinions
> of some, who happen to work there but in this case are speaking only for
> themselves.  You say "so many at BIDS", but as far as I know, your
> disagreements are with Stefan and Nathaniel (Matthew doesn't work at
> BIDS).  You are painting with a very wide brush the work of many people,
> and in the process, unfairly impacting others who have nothing to do with
> this.
>

I accept that criticism and apologize for doing that.   My *human* side was
coming out, and I was not being fair.  In my head, though I was also
trying to illustrate how some seemed to be doing the same thing for
Continuum or other companies.   This did not come out very artfully in the
early morning hours. I'm sorry.BIDS is doing a lot for the
community --- the recent DS4DS workshop, for example, was a spectacularly
useful summit --- I hope that many different write-ups and reports of the
event make their way out into the world.

>
>
> 1. I hope the discussion can move past the suspicion and innuendo about
> Continuum and Travis.  I haven't always agreed with how Travis communicates
> some of his ideas, and I've said it to him in such instances (e.g. this
> weekend, as I myself was surprised at how his last round of comments had
> landed on the list a few days back).  But I also have worked closely with
> him for years because I know that he has proven, not in words, but in
> actions, that he has the best interests of our community at heart, and that
> he is willing to try and do everything in his power to help whenever he
> can.
>

I really hope it's just a perception problem (perhaps on my end).   There
are challenges with working in the commercial world (there are a lot of
things to do that have nothing to do with the technology creation) and
communicating on open-source mailing lists.As many have noticed,
despite my intentions to contribute, I really can't do the same level of
contribution personally that I could when I was a student and a professor
and had more time.

However, I think that it is also under-appreciated (or mis-understood) how
much time I have spent with training and helping people who have
contributed instead.It's important to me to build a company that can
sponsor people to work on open-source (in a community setting).We are
still working on that, but it has been my intent.  So, far it's actually
easier to sponsor new projects than it is to sponsor people on old
projects.   I am quite sure that if Continuum had put 3 people full time on
NumPy in 2012, there would have been a lot of back-lash and
mis-understanding.   That's why we didn't do it.The collateral effect
of that was the creation of other tools that could be somewhat competitive
with NumPy long term -- or not.

I'd like to learn how to work with the community in an optimal way so that
everyone benefits --- and progress happens.  That's also why we created
Numfocus --- though it is ironic that NumPy has been one of the last
projects to actually sign up and be a formally sponsored project.

2. Conflicts of interest are a fact of life, in fact, I would argue that
> every healthy and sufficiently interconnected community eventually *should*
> have conflicts of interest. They are a sign that there is activity across
> multiple centers of interest, and individuals with connections in multiple
> areas of the community.  And we *want* folks who are engaged enough
> precisely to have such interests!
>
> For conflict of interest management, we don't need to reinvent the wheel,
> this is actually something where our beloved institutions, blessed be their
> bureaucratic souls, have tons of training materials that happen to be not
> completely useless.  Most universities and the national labs have
> information on COIs that provides guidelines, and Numpy could include in
> its governance model more explicit language about COIs if desired.
>
> So, the issue is not to view COIs as something evil or undesirable, but
> rather as the very real consequence of operating in an interconnected set
> of institutions.  And once you 

[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
 wrote:
[snip]
> So here is what I think is on the table:
>
> We have the steering council. Which leaves two questions:
>
> -How big should it be?
> -Who will be on the original, "seed" council?
>
> Note that as I understand the current draft of the governance doc,
> once established, the council itself decides who is on the council. So
> at this point we really are ONLY deciding how it's going to start. It
> has to be bootstrapped somehow.
>
> However, that had been contentious enough that it would probably be a
> good idea to hash out some guidelines about the council membership.

We actually do have some of those already -- dunno if they're perfect,
but they exist :-). To make sure everyone's on the same page, here's a
condensed summary of what the draft currently says:

Joining the council: contributor must have produced "substantial" and
"sustained" contributions over at least one year + be voted on by the
current council + be interested and willing to serve. (Then there's
some language emphasising that "contributions" should *not* be read
narrowly as a euphemism for "lines of code".)

Leaving the council: Happens by choice of member, or if inactive for
one year and can't be contacted, or if inactive for two years. Former
members are listed as "emeritus" to recognize their past service.

Rejoining the council: aside from their entry on the list of emeritus
members, a former-member and a never-member are treated identically in
general, and the rules for re-joining are the same as the rules for
joining.

Proposal for seed council: "everyone who's merged a pull request since
Jan 1, 2014".

(Actual text is here:
http://thread.gmane.org/gmane.comp.python.numeric.general/61106 , see
section "Council membership".)

We didn't talk much about these -- I think mostly on the theory that
the exact details really aren't going to matter much in the end. These
specific rules are exactly the rules that Jupyter/IPython use, stolen
without changes.

My interpretation is that these rules were designed to produce a
council consisting of a broad spectrum of contributors who are
actively engaged, in tune and up-to-date with the issues currently
facing the project, and broadly respected by the broader community.
The rationale for doing things this way (if we keep it) would be that
the steering council's "primary responsibility is to facilitate the
ordinary community-based decision making procedure", so you need
people who are actively engaged in community discussions; and, if
things break down then the people best positioned to resolve it are
the ones who have the best view of what went wrong, understand the
personalities involved, and so forth.

In practice, I'm sure any council interventions would involve most
members deferring to whoever they judge has the most expertise,
whether or not that person is on the council -- it's not like they'll
ever be making a decision in a vacuum.

Regarding the seed council, I just tried to pick an objective
criterion and an arbitrary date that seemed generally in keeping with
idea of "should be active in the last 1-to-2-years-ish". Fiddling with
the exact date in particular makes very little difference -- between
pushing it back to 2 years ago today or forward to 1 year ago today,
the only thing that changes is whether Pauli makes the list or not.
(And Pauli is obviously a great council candidate, though I don't know
whether he even wants to be on it.)

> Personally, I have no idea how big the council should be. Too big, and
> there is no point, consensus is harder to reach the larger the group,
> and the main (only?) role of the council is to resolve issues where
> consensus has not been reached in the larger community. But what is
> too big?

I'm a little wary of the idea of capping the council size. Assuming
you're pre-filtering for basic competence and good faith (as we are),
then the only way making the council smaller helps with decision
making is that it arbitrarily throws away the opinion of some
dedicated and valuable contributors. Plus then we have to start making
judgements like "well, person A has been around for a while but pretty
inactive recently, and person B is doing awesome stuff, should we kick
person A off the council to let person B on or...?" Judging whether
someone is or isn't a "substantial contributor" is fine, we can do
that. Having to make a relative judgement of which of two people is
the *more* "substantial contributor", though -- that sounds awful.

And given how conflict-adverse groups can be, I suspect that capping
the council size would in practice just have the effect that it never
takes in new blood. (The old effect where "science advances one
retirement at a time".)

I'd be interested to hear what Jupyter/IPython's experience with this
is, though: they currently have a 10 (!) person steering council, I
assume they'd love to have more. Having lots o

Re: [Numpy-discussion] Governance model request

[Matthew Brett]

Hi,

On Wed, Sep 23, 2015 at 1:02 AM, Fernando Perez  wrote:

[snip]

> 1. I hope the discussion can move past the suspicion and innuendo about
> Continuum and Travis

I'm glad the discussion has become a little more calm now, but I find
it difficult not to be annoyed by this statement above.

I see a severe reaction to perceived 'suspicion and innuendo', but I
see no 'suspicion and innuendo'.  Unless you mean that any suggestion
of potential conflict of interest is suspicion and innuendo.

You imply rudeness and bad faith when you say this.  I suppose this
must be aimed at me or Stefan or both of us.  In any case, I think the
accusation is unhelpful and unfair.   It makes this discussion more
difficult to have in the future.

See you,

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

Re: [Numpy-discussion] Governance model request

[Fernando Perez]

On Wed, Sep 23, 2015 at 12:57 PM, Matthew Brett 
wrote:

> I see a severe reaction to perceived 'suspicion and innuendo', but I
> see no 'suspicion and innuendo'.  Unless you mean that any suggestion
> of potential conflict of interest is suspicion and innuendo.
>

No, as I said, COIs are absolutely a fact of life, and *should* be talked
about, openly and directly.  I was referring generically about the tone of
this thread, that Ryan described as "bizarre", others as "surpised",
"disheartened", etc.


> You imply rudeness and bad faith when you say this.  I suppose this
> must be aimed at me or Stefan or both of us.  In any case, I think the
> accusation is unhelpful and unfair.   It makes this discussion more
> difficult to have in the future.
>

It was sincerely my intention to frame my critique in a specific way that
made the discussion *easier* to have in the future, precisely by
acknowledging that COIs were part of life, and not only for commercial
entities.

I was NOT implying that Stefan and you were somehow guilty of anything, I
only mentioned your names when I asked Travis not to paint Berkeley folks
with a broad brush, that's all.

If only the two of you took offense at my wording, in the interest of
keeping this already contentious and fraught thread contained, I offer:

a) a public apology for my choice of words, since it was certainly not my
intent to offend you, and I was not aiming at you personally.

b) a suggestion that we discuss it further personally, taking advantage of
the fact that we happen to be physically close.


If anyone else would like me to answer in public because they feel a slight
on my part, I will do so.

Best,

f

-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Governance model request

[Fernando Perez]

On Wed, Sep 23, 2015 at 12:18 PM, Travis Oliphant 
wrote:

> I accept that criticism and apologize for doing that.   My *human* side
> was coming out, and I was not being fair.  In my head, though I was
> also trying to illustrate how some seemed to be doing the same thing for
> Continuum or other companies.   This did not come out very artfully in the
> early morning hours. I'm sorry.
>

Thank you.


>BIDS is doing a lot for the community --- the recent DS4DS workshop,
> for example, was a spectacularly useful summit --- I hope that many
> different write-ups and reports of the event make their way out into the
> world.
>
>>
We will put out a full public report, along with all the slides, which
we're collecting, etc. It may take us a few days, as we have an upcoming
event for BIDS and our two partner sites (UW and NYU), but we'll do it, as
we hope this will be useful to the entire community.

Cheers,

f


-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[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

On Wed, Sep 23, 2015 at 3:40 PM Nathaniel Smith  wrote:

> [splitting this out from the thread-o-doom]
>
> On Wed, Sep 23, 2015 at 8:47 AM, Chris Barker - NOAA Federal
>  wrote:
> [snip]
> > So here is what I think is on the table:
> >
> > We have the steering council. Which leaves two questions:
> >
> > -How big should it be?
> > -Who will be on the original, "seed" council?
> >
> > Note that as I understand the current draft of the governance doc,
> > once established, the council itself decides who is on the council. So
> > at this point we really are ONLY deciding how it's going to start. It
> > has to be bootstrapped somehow.
> >
> > However, that had been contentious enough that it would probably be a
> > good idea to hash out some guidelines about the council membership.
>
> We actually do have some of those already -- dunno if they're perfect,
> but they exist :-). To make sure everyone's on the same page, here's a
> condensed summary of what the draft currently says:
>
> Joining the council: contributor must have produced "substantial" and
> "sustained" contributions over at least one year + be voted on by the
> current council + be interested and willing to serve. (Then there's
> some language emphasising that "contributions" should *not* be read
> narrowly as a euphemism for "lines of code".)
>
> Leaving the council: Happens by choice of member, or if inactive for
> one year and can't be contacted, or if inactive for two years. Former
> members are listed as "emeritus" to recognize their past service.
>
> Rejoining the council: aside from their entry on the list of emeritus
> members, a former-member and a never-member are treated identically in
> general, and the rules for re-joining are the same as the rules for
> joining.
>
> Proposal for seed council: "everyone who's merged a pull request since
> Jan 1, 2014".
>
> (Actual text is here:
> http://thread.gmane.org/gmane.comp.python.numeric.general/61106 , see
> section "Council membership".)
>
> We didn't talk much about these -- I think mostly on the theory that
> the exact details really aren't going to matter much in the end. These
> specific rules are exactly the rules that Jupyter/IPython use, stolen
> without changes.
>
> My interpretation is that these rules were designed to produce a
> council consisting of a broad spectrum of contributors who are
> actively engaged, in tune and up-to-date with the issues currently
> facing the project, and broadly respected by the broader community.
> The rationale for doing things this way (if we keep it) would be that
> the steering council's "primary responsibility is to facilitate the
> ordinary community-based decision making procedure", so you need
> people who are actively engaged in community discussions; and, if
> things break down then the people best positioned to resolve it are
> the ones who have the best view of what went wrong, understand the
> personalities involved, and so forth.
>
> In practice, I'm sure any council interventions would involve most
> members deferring to whoever they judge has the most expertise,
> whether or not that person is on the council -- it's not like they'll
> ever be making a decision in a vacuum.
>
> Regarding the seed council, I just tried to pick an objective
> criterion and an arbitrary date that seemed generally in keeping with
> idea of "should be active in the last 1-to-2-years-ish". Fiddling with
> the exact date in particular makes very little difference -- between
> pushing it back to 2 years ago today or forward to 1 year ago today,
> the only thing that changes is whether Pauli makes the list or not.
> (And Pauli is obviously a great council candidate, though I don't know
> whether he even wants to be on it.)
>
> > Personally, I have no idea how big the council should be. Too big, and
> > there is no point, consensus is harder to reach the larger the group,
> > and the main (only?) role of the council is to resolve issues where
> > consensus has not been reached in the larger community. But what is
> > too big?
>
> I'm a little wary of the idea of capping the council size. Assuming
> you're pre-filtering for basic competence and good faith (as we are),
> then the only way making the council smaller helps with decision
> making is that it arbitrarily throws away the opinion of some
> dedicated and valuable contributors. Plus then we have to start making
> judgements like "well, person A has been around for a while but pretty
> inactive recently, and person B is doing awesome stuff, should we kick
> person A off the council to let person B on or...?" Judging whether
> someone is or isn't a "substantial contributor" is fine, we can do
> that. Having to make a relative judgement of which of two people is
> the *more* "substantial contributor", though -- th

[Numpy-discussion] "Become an Open Source Contributor" workshop

[Jaime Fernández del Río]

Apologies for the cross-posting.

The Data Science Student Society of the University of California San Diego,
or DS3 @ UCSD as they like to call themselves, will be holding biweekly
Python themed workshops starting this fall.  On the week of October 19th,
they will be having yours truly doing a "Become an Open Source Contributor"
piece.  It will be a shortish event, 60-90 minutes, so my idea was to cover
the following:

   1. (15 min) An introduction to the Python data science landscape.
   2. (30 min) An overview of the GitHub workflow that most (all?) of the
   projects follow.
   3. (30-45 min) A hands on session, where we would make sure everyone
   gets set up in GitHub, and forks and clones their favorite project.  Time
   and participant willingness permitting, I would like to take advantage of
   my commit bits, and have some of the participants submit a simple PR, e.g.
   fixing a documentation typo, to NumPy or SciPy, and hit the green button
   right there, so that they get to leave as knighted FOSS contributors.

And this is what I am hoping to get from you, the community:

   1. If anyone in the area would like to get involved, please contact me.
   I have recruited a couple of volunteers from PySanDiego, but could use more
   help.
   2. I'm also hoping to get some help, especially with the introductory
   part.  Given that the crowd will mostly be university students and some
   faculty, it would be great if someone who actually knew what they were
   talking about could deliver a short, 10 minute talk, on Python, data
   science, and academia.  I'm sure we could arrange it to have someone join
   by video conference.
   3. If you have organized anything similar in the past, and have material
   that I could use to, ahem, draw inspiration from, or recommendations to
   make, or whatever, I'd love to hear from you.

Thanks for reading!

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Travis Oliphant]

>
> Regarding the seed council, I just tried to pick an objective
> criterion and an arbitrary date that seemed generally in keeping with
> idea of "should be active in the last 1-to-2-years-ish". Fiddling with
> the exact date in particular makes very little difference -- between
> pushing it back to 2 years ago today or forward to 1 year ago today,
> the only thing that changes is whether Pauli makes the list or not.
> (And Pauli is obviously a great council candidate, though I don't know
> whether he even wants to be on it.)
>
> > Personally, I have no idea how big the council should be. Too big, and
> > there is no point, consensus is harder to reach the larger the group,
> > and the main (only?) role of the council is to resolve issues where
> > consensus has not been reached in the larger community. But what is
> > too big?
>
>
> > As for make-up of the council, I think we need to expand beyond people
> > who have recently contributed core code.
> >
> > Yes, the council does need to have expertise to make technical
> > decisions, but if you think about the likely contentious issues like
> > ABI breakage, a core-code focused view is incomplete. So there should
> > be representation by:
> >
> > Someone(s) with a long history of working with the code -- that
> > institutional memory of why decisions were made the way they were
> > could be key.
>
> Sure -- though I can't really imagine any way of framing a rule like
> this that *wouldn't* be satisfied by Chuck + Ralf + Pauli, so my guess
> is that such a rule would not actually have any effect on the council
> membership in practice.
>

As the original author of NumPy, I would like to be on the seed council as
long as it is larger than 7 people.That is my proposal.I don't need
to be a permanent member, but I do believe I have enough history that I can
understand issues even if I haven't been working on code directly.

I think I do bring history and information that provides all of the history
that could be helpful on occasion. In addition, if a matter is
important enough to even be brought to the attention of this council, I
would like to be involved in the discussion about it.

It's a simple change to the text --- basically an explanation that Travis
requested to be on the seed council.

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

Re: [Numpy-discussion] Governance model request

[Stefan van der Walt]

On 2015-09-23 13:36:35, Fernando Perez  wrote:
> On Wed, Sep 23, 2015 at 12:57 PM, Matthew Brett 
> wrote:
>
>> I see a severe reaction to perceived 'suspicion and innuendo', but I
>> see no 'suspicion and innuendo'.  Unless you mean that any suggestion
>> of potential conflict of interest is suspicion and innuendo.
>>
>
> No, as I said, COIs are absolutely a fact of life, and *should* be talked
> about, openly and directly.  I was referring generically about the tone of
> this thread, that Ryan described as "bizarre", others as "surpised",
> "disheartened", etc.

What I thought Matthew was saying is that you writing "I hope the
discussion can move past the suspicion and innuendo about Continuum and
Travis" gives validity to the view that those things are real whereas,
in my view, they were constructed in responses by others who didn't
accurately summarize the intent of what was being said (and I'm not
laying blame to anyone, I could certainly have worded myself more
clearly).

But, yes, it was disheartening—especially because we all know one
another and have hacked together late into the night at SciPy
conferences.  My experience has always been that we are reasonable
people who listen; but perhaps we forget that about one another from
time to time.

It is important to me that we work towards making this mailing list a
safe place for discussion again.  Part of that may be to do some
maintenance on bridges of trust that seem to have eroded a bit over the
years.

Perhaps some kind of group bonding activity, such as working on a shared
project, would help? ;)

> b) a suggestion that we discuss it further personally, taking advantage of
> the fact that we happen to be physically close.

Sure, I'm happy to discuss the personal side of this offline.

Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Governance model request

[Matthew Brett]

Hi,

On Wed, Sep 23, 2015 at 1:36 PM, Fernando Perez  wrote:
> On Wed, Sep 23, 2015 at 12:57 PM, Matthew Brett 
> wrote:
>>
>> I see a severe reaction to perceived 'suspicion and innuendo', but I
>> see no 'suspicion and innuendo'.  Unless you mean that any suggestion
>> of potential conflict of interest is suspicion and innuendo.
>
>
> No, as I said, COIs are absolutely a fact of life, and *should* be talked
> about, openly and directly.  I was referring generically about the tone of
> this thread, that Ryan described as "bizarre", others as "surpised",
> "disheartened", etc.

Sure, I said above, it is clearly true the some people reacted very strongly.

Did you see any remark made by me or Stefan or anyone else that could
reasonably be described as bizarre, surprising or disheartening?

Cheers,

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

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

[Chris Barker]

On Wed, Sep 23, 2015 at 12:40 PM, Nathaniel Smith  wrote:

> > However, that had been contentious enough that it would probably be a
> > good idea to hash out some guidelines about the council membership.
>
> We actually do have some of those already -- dunno if they're perfect,
> but they exist :-).


  know -- I guess I meant "expand the guidelines..." .. but thanks for
putting it all here.

Also, I think there was a slight disconnect between the guidelines and the
proposed "seed" council, as it was only the seed, no biggie, but I think
folks got the wrong impression.


> Then there's
> some language emphasising that "contributions" should *not* be read
> narrowly as a euphemism for "lines of code".)
>

yeah, this got lost a bit somehow...


> Leaving the council: Happens by choice of member, or if inactive for
> one year and can't be contacted, or if inactive for two years.


somehow this seem to have been interpreted as "inactive in contributing to
code", rather than "inactive in council communication/activity" -- but two
years seems pleanty long to me.

Proposal for seed council: "everyone who's merged a pull request since
> Jan 1, 2014".
>

I think it matters little how the council is seeded, as it can grow and
change from there -- but maybe folks will feel better if we define a few
other parameters -- after all, this wouldn't get you anyone that had made
large non-code contributions to the project.

We didn't talk much about these -- I think mostly on the theory that
> the exact details really aren't going to matter much in the end.


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


> My interpretation is that these rules were designed to produce a
> council consisting of a broad spectrum of contributors who are
> actively engaged, in tune and up-to-date with the issues currently
> facing the project, and broadly respected by the broader community.
>

yup -- that's what we want :-)


> I'm a little wary of the idea of capping the council size.

...

Judging whether
> someone is or isn't a "substantial contributor" is fine, we can do
> that. Having to make a relative judgement of which of two people is
> the *more* "substantial contributor", though -- that sounds awful.
>

indeed it  does -- tough problem.


> And given how conflict-adverse groups can be, I suspect that capping
> the council size would in practice just have the effect that it never
> takes in new blood.


Another very valid concern. Started me thinking about term limits -- which
is an even worse idea :-)


> I'd be interested to hear what Jupyter/IPython's experience with this
> is, though: they currently have a 10 (!) person steering council,


me too. Though as you mention, not having to rely on consensus makes a
larger group more tenable.


> > Someone(s) with a long history of working with the code -- that
> > institutional memory of why decisions were made the way they were
> > could be key.
>
> Sure -- though I can't really imagine any way of framing a rule like
> this that *wouldn't* be satisfied by Chuck + Ralf + Pauli, so my guess
> is that such a rule would not actually have any effect on the council
> membership in practice.
>

well, as someone that has been around the community, and relied on numpy
(and numarray, and Numeric before that) for I think 17 years, maybe I have
a different idea of what "history" is. Though I honestly don't remember
when the folks you names joined up...

To be specific, someone with a memory of the Numeric -> numarray
semi-disaster would be nice to have around... Though, as you've stated,
plenty of opportunity for wise old souls to be consulted and contribute
even if not actually on the council.


> > Someone(s) that may not have worked on the core code, but is a major
> > player in the community, perhaps as the leader of a Numpy-dependent
> > project. This would provide representation for the broad community.
>
> Pointing out features of the current draft again for reference: In the
> current text, the "NumFOCUS subcommittee" does have an external member
> to provide some oversight. (So mathematically speaking, this means
> that the subcommittee is not a subset -- go figure. I blame IPython.)
> But, this oversight is specifically for financial matters only, not
> technical ones: "This Subcommittee shall NOT make decisions about the
> direction, scope or technical direction of the Project."
>

right -- I was specifically thinking someone from an external project to
help with the touch technical decisions, like breaking teh ABI, what kin do
missing value implementation to use, etc. These issues are very, very
important to the third party packages.

But again, plenty of opportunity to contribute to the discussion anyway --
which I guess leads the the core issue: if all goes well, it will matter
not a wit who is on the council!

Thomas Caswell (one of the leaders of matplotlib) volunteered to be
> our external member to start. We certainly could ask him to sit on the
> steering council as we

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

[Chris Barker]

On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant 
wrote:


> As the original author of NumPy, I would like to be on the seed council as
> long as it is larger than 7 people.That is my proposal.
>

Or the seed council could invite Travis to join as its first order of
business :-)

Actually, maybe that's a way to handle it -- declare that the first order
of business for teh seed council is to expand the council.

I'd still like some guidelines (suggestions) for history and at least one
major dependent-on-numpy rep. Travis would certainly meet the history
requirement -- and maybe the other, too. :-)


> It's a simple change to the text --- basically an explanation that Travis
> requested to be on the seed council.
>

I'd rather the final draft of the document didn't name names, but no biggie.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Steering Committee Size

[Travis Oliphant]

On Wed, Sep 23, 2015 at 3:25 AM, Sebastian Berg 
wrote:

> Hi,
>
> Trying to figure out at least a bit from  the discussions. While I am
> happy with the draft, I wonder if someone has some insights about some
> questions:
>
> 1. How large crowds have examples of working well with apache style voting?
>

I don't have experience with this, other than Python mailing list where it
is fine.


> 2. How large do we expect numpy steering council to be (I have always
> thought about 10).
>

I don't know.  I don't think this is set as far as I'm aware.

3. More on  opinions, how large does the community feel is too large (so
> that we should maybe elect people).
>
> And to maybe more a discussion point, does the community feel that those
> who would be/are affectivly now in the Steering Council do not sufficiently
> represent old time contributers who were not active in the past year(s).
>

As I mentioned before, I am happy to serve on the initial seed council to
help transition more fully to this style of governance.

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

Re: [Numpy-discussion] Governance model request

[Chris Barker]

On Wed, Sep 23, 2015 at 2:31 PM, Stefan van der Walt 
wrote:

> > b) a suggestion that we discuss it further personally, taking advantage
> of
> > the fact that we happen to be physically close.
>
> Sure, I'm happy to discuss the personal side of this offline.
>

Hey! I want to have a beer with you folks too! Maybe time for a trip back
to the old stomping grounds

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

[Nathaniel Smith]

On Wed, Sep 23, 2015 at 11:59 AM, Travis Oliphant 
wrote:

> Hi Nathaniel,
>
> Thanks for the clarifications.   Is the governance document committed to
> the repository?   I keep looking for it and have a hard time finding it ---
> I think I read it last in an email.
>

Indeed, sorry -- getting it into the repo has been on my todo list, though
somewhat on hold given the uncertainty the last few days. For reference in
the mean time, the original posting is here:
  http://thread.gmane.org/gmane.comp.python.numeric.general/61106
and I'll paste it again at the bottom of this email.

(The only difference between the version in this email and the previous
should be the addition of Jaime to fill in the empty slot on the tentative
NumFOCUS subcommittee.)


>
>
In this way, I could make Pull Requests to the governance document if there
> are concrete suggestions for change, and then have them reviewed in the
> standard way.
>
>
While this makes sense, I think the "standard way" for reviewing
substantive changes (i.e., not just simple wording changes) here would be
via discussion on the mailing list :-). We're still trying to figure out
the best way to balance github versus mailing list... it sounds like things
are at least converging somewhat, though, so I'll work on getting a PR
together soon in any case.

-n

--

The purpose of this document is to formalize the governance process used by
the NumPy project in both ordinary and extraordinary situations, and to
clarify how decisions are made and how the various elements of our
community interact, including the relationship between open source
collaborative development and work that may be funded by for-profit or
non-profit entities.

Summary
===

NumPy is a community-owned and community-run project. To the maximum extent
possible, decisions about project direction are made by community consensus
(but note that "consensus" here has a somewhat technical meaning that might
not match everyone's expectations -- see below). Some members of the
community additionally contribute by serving on the NumPy steering council,
where they are responsible for facilitating the establishment of community
consensus, for stewarding project resources, and -- in extreme cases -- for
making project decisions if the normal community-based process breaks down.

The Project
===

The NumPy Project (The Project) is an open source software project
affiliated with the 501(c)3 NumFocus Foundation. The goal of The Project is
to develop open source software for array-based computing in Python, and in
particular the `numpy` package, along with related software such as `f2py`
and the NumPy Sphinx extensions. The Software developed by The Project is
released under the BSD (or similar) open source license, developed openly
and hosted on public GitHub repositories under the `numpy` GitHub
organization.

The Project is developed by a team of distributed developers, called
Contributors. Contributors are individuals who have contributed code,
documentation, designs or other work to the Project. Anyone can be a
Contributor. Contributors can be affiliated with any legal entity or none.
Contributors participate in the project by submitting, reviewing and
discussing GitHub Pull Requests and Issues and participating in open and
public Project discussions on GitHub, mailing lists, and other channels.
The foundation of Project participation is openness and transparency.

Here is a list of the current Contributors to the main NumPy repository:

[
https://github.com/numpy/numpy/graphs/contributors](https://github.com/numpy/numpy/graphs/contributors)

The Project Community consists of all Contributors and Users of the
Project. Contributors work on behalf of and are responsible to the larger
Project Community and we strive to keep the barrier between Contributors
and Users as low as possible.

The Project is formally affiliated with the 501(c)3 NumFOCUS Foundation ([
http://numfocus.org](http://numfocus.org)), which serves as its fiscal
sponsor, may hold project trademarks and other intellectual property, helps
manage project donations and acts as a parent legal entity. NumFOCUS is the
only legal entity that has a formal relationship with the project (see
Institutional Partners section below).

Governance
==

This section describes the governance and leadership model of The Project.

The foundations of Project governance are:

-   Openness & Transparency
-   Active Contribution
-   Institutional Neutrality

Consensus-based decision making by the community


Normally, all project decisions will be made by consensus of all interested
Contributors. The primary goal of this approach is to ensure that the
people who are most affected by and involved in any given change can
contribute their knowledge in the confidence that their voices will be
heard, because thoughtful review from a broad community is the best
mechanism we know of for creating high-qual

Re: [Numpy-discussion] Governance model request

[Fernando Perez]

On Wed, Sep 23, 2015 at 2:31 PM, Stefan van der Walt 
wrote:

> Perhaps some kind of group bonding activity, such as working on a shared
> project, would help? ;)
>

Indeed, there's a bunch of fresh 2x4s, screws and bolts with your name on
them ;)

Cheers,

f
-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Governance model request

[Charles R Harris]

On Wed, Sep 23, 2015 at 3:32 PM, Matthew Brett 
wrote:

> Hi,
>
> On Wed, Sep 23, 2015 at 1:36 PM, Fernando Perez 
> wrote:
> > On Wed, Sep 23, 2015 at 12:57 PM, Matthew Brett  >
> > wrote:
> >>
> >> I see a severe reaction to perceived 'suspicion and innuendo', but I
> >> see no 'suspicion and innuendo'.  Unless you mean that any suggestion
> >> of potential conflict of interest is suspicion and innuendo.
> >
> >
> > No, as I said, COIs are absolutely a fact of life, and *should* be talked
> > about, openly and directly.  I was referring generically about the tone
> of
> > this thread, that Ryan described as "bizarre", others as "surpised",
> > "disheartened", etc.
>
> Sure, I said above, it is clearly true the some people reacted very
> strongly.
>
> Did you see any remark made by me or Stefan or anyone else that could
> reasonably be described as bizarre, surprising or disheartening?
>

Stephan and Matthew, go to your rooms ;)

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

Re: [Numpy-discussion] "Become an Open Source Contributor" workshop

[Nathan Goldbaum]

If you are going to do work at a terminal, I'd suggest using a library like
doitlive (http://doitlive.readthedocs.org/en/latest/) so you can't make
mistakes while still making it look like you are actually typing everything
at a terminal. You will also be able to share your exact terminal sessions
with the students if they want to come back to it later.

On Wed, Sep 23, 2015 at 4:57 PM, Stefan van der Walt 
wrote:

> Hi Jaime
>
> On 2015-09-23 14:06:08, Jaime Fernández del Río 
> wrote:
> >3. If you have organized anything similar in the past, and have
> material
> >that I could use to, ahem, draw inspiration from, or recommendations
> to
> >make, or whatever, I'd love to hear from you.
>
> Here's the new developer workflow page for scikit-image, I'm sure many
> other projects have similar ones:
>
> http://scikit-image.org/docs/stable/contribute.html
>
> Perhaps you can harvest some ideas.  Also, a beginner's summary to git
> workflow:
>
> http://rogerdudler.github.io/git-guide/
>
> It's a lot to teach in only an hour or two, so if I were teaching I'd
> keep it simple (basic) and clear (to make sure the students can "keep it
> in their heads"), and to make sure they have a clear avenue for
> questions when they get stuck after the class.
>
> Stéfan
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] "Become an Open Source Contributor" workshop

[Stefan van der Walt]

Hi Jaime

On 2015-09-23 14:06:08, Jaime Fernández del Río  wrote:
>3. If you have organized anything similar in the past, and have material
>that I could use to, ahem, draw inspiration from, or recommendations to
>make, or whatever, I'd love to hear from you.

Here's the new developer workflow page for scikit-image, I'm sure many
other projects have similar ones:

http://scikit-image.org/docs/stable/contribute.html

Perhaps you can harvest some ideas.  Also, a beginner's summary to git
workflow:

http://rogerdudler.github.io/git-guide/

It's a lot to teach in only an hour or two, so if I were teaching I'd
keep it simple (basic) and clear (to make sure the students can "keep it
in their heads"), and to make sure they have a clear avenue for
questions when they get stuck after the class.

Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Governance model request

[Fernando Perez]

On Wed, Sep 23, 2015 at 2:32 PM, Matthew Brett 
wrote:

> Did you see any remark made by me or Stefan or anyone else that could
> reasonably be described as bizarre, surprising or disheartening?
>

As I said already, I wasn't referring to you personally, but to the tone of
the thread.  It was the taste that the thread left in my mouth after
reading tens of very long emails, and I guess I wasn't the only one, since
multiple folks used such adjectives.  But it was a poor choice of words on
my part.

And no, I didn't make a quote-by-quote analysis of the thread, I'm sorry.

One last time, it was *not* a personal reference to you: the only reason I
mentioned your names was because of the Berkeley clarification regarding
BIDS that I asked of Travis, that's all.  If that comment hadn't been made,
 I would not have made any mention whatsoever of anyone in particular.  I
apologize for not foreseeing that this would have made you feel singled
out, in retrospect, I should have.

In my mind, it was the opposite, as I felt that you had every right to
express whatever opinions you have speaking for yourselves, independent of
your affiliations, and I was simply asking Travis to separate individuals
from institutions.  But I should have realized that calling anyone out by
name in a context like this is a bad idea regardless.

Cheers,

f
-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

[Travis Oliphant]

>
>
> Here is a list of the current Contributors to the main NumPy repository:
>
> [
> https://github.com/numpy/numpy/graphs/contributors](https://github.com/numpy/numpy/graphs/contributors)
>
>
One of the problems with this list is that my contributions to the project
are extremely under-represented because the large majority of my commitment
of code happened in 2005 to 2006 before github was used.  So, using
this as a list of the contributors is quite misleading --- and there are a
lot of people now looking only at lists like this one and it might confuse
them why I care so much.So, if you are going to make this list public
in a governance document like this, then I think some acknowledgement of
the source of the original code and the contributors to that needs to also
be made --- or you could just also point to the THANKS document which lists
people up to about 2008.   Between 2008 and 2010 we will lose
contributions, still and this can be acknowledged.


> Consensus-based decision making by the community
> 
>
> Normally, all project decisions will be made by consensus of all
> interested Contributors. The primary goal of this approach is to ensure
> that the people who are most affected by and involved in any given change
> can contribute their knowledge in the confidence that their voices will be
> heard, because thoughtful review from a broad community is the best
> mechanism we know of for creating high-quality software.
>
> The mechanism we use to accomplish this goal may be unfamiliar for those
> who are not experienced with the cultural norms around free/open-source
> software development. We provide a summary here, and highly recommend that
> all Contributors additionally read [Chapter 4: Social and Political
> Infrastructure](
> http://producingoss.com/en/producingoss.html#social-infrastructure) of
> Karl Fogel's classic *Producing Open Source Software*, and in particular
> the section on [Consensus-based Democracy](
> http://producingoss.com/en/producingoss.html#consensus-democracy), for a
> more detailed discussion.
>
> In this context, consensus does *not* require:
>
> - that we wait to solicit everybody's opinion on every change,
> - that we ever hold a vote on anything,
> - or that everybody is happy or agrees with every decision.
>
> For us, what consensus means is that we entrust *everyone* with the right
> to veto any change if they feel it necessary. While this may sound like a
> recipe for obstruction and pain, this is not what happens. Instead, we find
> that most people take this responsibility seriously, and only invoke their
> veto when they judge that a serious problem is being ignored, and that
> their veto is necessary to protect the project. And in practice, it turns
> out that such vetoes are almost never formally invoked, because their mere
> possibility ensures that Contributors are motivated from the start to find
> some solution that everyone can live with -- thus accomplishing our goal of
> ensuring that all interested perspectives are taken into account.
>
> How do we know when consensus has been achieved? In principle, this is
> rather difficult, since consensus is defined by the absence of vetos, which
> requires us to somehow prove a negative. In practice, we use a combination
> of our best judgement (e.g., a simple and uncontroversial bug fix posted on
> GitHub and reviewed by a core developer is probably fine) and best efforts
> (e.g., all substantive API changes must be posted to the mailing list in
> order to give the broader community a chance to catch any problems and
> suggest improvements; we assume that anyone who cares enough about NumPy to
> invoke their veto right should be on the mailing list). If no-one bothers
> to comment on the mailing list after a few days, then it's probably fine.
> And worst case, if a change is more controversial than expected, or a
> crucial critique is delayed because someone was on vacation, then it's no
> big deal: we apologize for misjudging the situation, [back up, and sort
> things out](
> http://producingoss.com/en/producingoss.html#version-control-relaxation).
>
> If one does need to invoke a formal veto, then it should consist of:
>
> - an unambiguous statement that a veto is being invoked,
> - an explanation of why it is being invoked, and
> - a description of what conditions (if any) would convince the vetoer to
> withdraw their veto.
>
> If all proposals for resolving some issue are vetoed, then the status quo
> wins by default.
>
> In the worst case, if a Contributor is genuinely misusing their veto in an
> obstructive fashion to the detriment of the project, then they can be
> ejected from the project by consensus of the Steering Council -- see below.
>
> Steering Council
> 
>
> The Project will have a Steering Council that consists of Project
> Contributors who have produced contributions that are substantial in
> quality and quantity, and sus

Re: [Numpy-discussion] Governance model request

[Travis Oliphant]

>
>
> One last time, it was *not* a personal reference to you: the only reason I
> mentioned your names was because of the Berkeley clarification regarding
> BIDS that I asked of Travis, that's all.  If that comment hadn't been made,
>  I would not have made any mention whatsoever of anyone in particular.  I
> apologize for not foreseeing that this would have made you feel singled
> out, in retrospect, I should have.
>
> In my mind, it was the opposite, as I felt that you had every right to
> express whatever opinions you have speaking for yourselves, independent of
> your affiliations, and I was simply asking Travis to separate individuals
> from institutions.  But I should have realized that calling anyone out by
> name in a context like this is a bad idea regardless.
>
>
This was my fault for not being more careful in my words.   I felt multiple
things when I wrote my emails that led to incorrectly chosen words --- but
mostly I was feeling unappreciated, attacked, and accused.   I'm sure now
that was not intended --- but there have been mis-understandings.  I expect
they will happen again.   I know if we listen to each other and trust that
while we may see the world differently and have different framings of
solutions --- we can work to coordinate on an important technical activity
together.

In retrospect, my initial email requesting inclusion on the seed council
could have been worded better (as there were multiple things conflated
together).   I am responding to the actual text of the governance document
in the other thread so as to clarify what my proposal actually is in the
context of that document.

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

Re: [Numpy-discussion] "Become an Open Source Contributor" workshop

[Chris Barker]

On Wed, Sep 23, 2015 at 3:04 PM, Nathan Goldbaum 
wrote:

> If you are going to do work at a terminal, I'd suggest using a library
> like doitlive (http://doitlive.readthedocs.org/en/latest/) so you can't
> make mistakes while still making it look like you are actually typing
> everything at a terminal.
>

This is pretty cool! And, I think perfect for a presentation or the like.

But for teaching, I find that one of the valuable things I do is make
mistakes at the command line (or iPython notebook, or editor...), and then
show the students how I discover and recover from the mistake...

just a thought

-Chris




> You will also be able to share your exact terminal sessions with the
> students if they want to come back to it later.
>
> On Wed, Sep 23, 2015 at 4:57 PM, Stefan van der Walt  > wrote:
>
>> Hi Jaime
>>
>> On 2015-09-23 14:06:08, Jaime Fernández del Río 
>> wrote:
>> >3. If you have organized anything similar in the past, and have
>> material
>> >that I could use to, ahem, draw inspiration from, or recommendations
>> to
>> >make, or whatever, I'd love to hear from you.
>>
>> Here's the new developer workflow page for scikit-image, I'm sure many
>> other projects have similar ones:
>>
>> http://scikit-image.org/docs/stable/contribute.html
>>
>> Perhaps you can harvest some ideas.  Also, a beginner's summary to git
>> workflow:
>>
>> http://rogerdudler.github.io/git-guide/
>>
>> It's a lot to teach in only an hour or two, so if I were teaching I'd
>> keep it simple (basic) and clear (to make sure the students can "keep it
>> in their heads"), and to make sure they have a clear avenue for
>> questions when they get stuck after the class.
>>
>> Stéfan
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

[Stephan Hoyer]

Travis -- have you included all your email addresses in your GitHub profile? 
When I type git shortlog -ne, I see 2063 commits from your Continuum address 
that seem to be missing from the contributors page on github. Generally 
speaking, the git logs tend to be more reliable for these counts.

On Wed, Sep 23, 2015 at 3:12 PM, Travis Oliphant 
wrote:

>>
>>
>> Here is a list of the current Contributors to the main NumPy repository:
>>
>> [
>> https://github.com/numpy/numpy/graphs/contributors](https://github.com/numpy/numpy/graphs/contributors)
>>
>>
> One of the problems with this list is that my contributions to the project
> are extremely under-represented because the large majority of my commitment
> of code happened in 2005 to 2006 before github was used.  So, using
> this as a list of the contributors is quite misleading --- and there are a
> lot of people now looking only at lists like this one and it might confuse
> them why I care so much.So, if you are going to make this list public
> in a governance document like this, then I think some acknowledgement of
> the source of the original code and the contributors to that needs to also
> be made --- or you could just also point to the THANKS document which lists
> people up to about 2008.   Between 2008 and 2010 we will lose
> contributions, still and this can be acknowledged.
>> Consensus-based decision making by the community
>> 
>>
>> Normally, all project decisions will be made by consensus of all
>> interested Contributors. The primary goal of this approach is to ensure
>> that the people who are most affected by and involved in any given change
>> can contribute their knowledge in the confidence that their voices will be
>> heard, because thoughtful review from a broad community is the best
>> mechanism we know of for creating high-quality software.
>>
>> The mechanism we use to accomplish this goal may be unfamiliar for those
>> who are not experienced with the cultural norms around free/open-source
>> software development. We provide a summary here, and highly recommend that
>> all Contributors additionally read [Chapter 4: Social and Political
>> Infrastructure](
>> http://producingoss.com/en/producingoss.html#social-infrastructure) of
>> Karl Fogel's classic *Producing Open Source Software*, and in particular
>> the section on [Consensus-based Democracy](
>> http://producingoss.com/en/producingoss.html#consensus-democracy), for a
>> more detailed discussion.
>>
>> In this context, consensus does *not* require:
>>
>> - that we wait to solicit everybody's opinion on every change,
>> - that we ever hold a vote on anything,
>> - or that everybody is happy or agrees with every decision.
>>
>> For us, what consensus means is that we entrust *everyone* with the right
>> to veto any change if they feel it necessary. While this may sound like a
>> recipe for obstruction and pain, this is not what happens. Instead, we find
>> that most people take this responsibility seriously, and only invoke their
>> veto when they judge that a serious problem is being ignored, and that
>> their veto is necessary to protect the project. And in practice, it turns
>> out that such vetoes are almost never formally invoked, because their mere
>> possibility ensures that Contributors are motivated from the start to find
>> some solution that everyone can live with -- thus accomplishing our goal of
>> ensuring that all interested perspectives are taken into account.
>>
>> How do we know when consensus has been achieved? In principle, this is
>> rather difficult, since consensus is defined by the absence of vetos, which
>> requires us to somehow prove a negative. In practice, we use a combination
>> of our best judgement (e.g., a simple and uncontroversial bug fix posted on
>> GitHub and reviewed by a core developer is probably fine) and best efforts
>> (e.g., all substantive API changes must be posted to the mailing list in
>> order to give the broader community a chance to catch any problems and
>> suggest improvements; we assume that anyone who cares enough about NumPy to
>> invoke their veto right should be on the mailing list). If no-one bothers
>> to comment on the mailing list after a few days, then it's probably fine.
>> And worst case, if a change is more controversial than expected, or a
>> crucial critique is delayed because someone was on vacation, then it's no
>> big deal: we apologize for misjudging the situation, [back up, and sort
>> things out](
>> http://producingoss.com/en/producingoss.html#version-control-relaxation).
>>
>> If one does need to invoke a formal veto, then it should consist of:
>>
>> - an unambiguous statement that a veto is being invoked,
>> - an explanation of why it is being invoked, and
>> - a description of what conditions (if any) would convince the vetoer to
>> withdraw their veto.
>>
>> If all proposals for resolving some issue are vetoed, then the status quo
>> wins by defau

Re: [Numpy-discussion] Governance model request

[Matthew Brett]

On Wed, Sep 23, 2015 at 3:08 PM, Fernando Perez  wrote:
>
> On Wed, Sep 23, 2015 at 2:32 PM, Matthew Brett 
> wrote:
>>
>> Did you see any remark made by me or Stefan or anyone else that could
>> reasonably be described as bizarre, surprising or disheartening?
>
>
> As I said already, I wasn't referring to you personally, but to the tone of
> the thread.  It was the taste that the thread left in my mouth after reading
> tens of very long emails, and I guess I wasn't the only one, since multiple
> folks used such adjectives.  But it was a poor choice of words on my part.
>
> One last time, it was *not* a personal reference to you: the only reason I
> mentioned your names was because of the Berkeley clarification regarding
> BIDS that I asked of Travis, that's all.

You know me well, I not reacting to personal offense, otherwise I
would email you privately.

See you,

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

Re: [Numpy-discussion] Governance model request

[Fernando Perez]

On Wed, Sep 23, 2015 at 3:19 PM, Travis Oliphant 
wrote:

> This was my fault for not being more careful in my words.   I felt
> multiple things when I wrote my emails that led to incorrectly chosen words
> --- but mostly I was feeling unappreciated, attacked, and accused.   I'm
> sure now that was not intended --- but there have been mis-understandings.
> I expect they will happen again.   I know if we listen to each other and
> trust that while we may see the world differently and have different
> framings of solutions --- we can work to coordinate on an important
> technical activity together.
>
> In retrospect, my initial email requesting inclusion on the seed council
> could have been worded better (as there were multiple things conflated
> together).   I am responding to the actual text of the governance document
> in the other thread so as to clarify what my proposal actually is in the
> context of that document.
>

No worries, I wasn't digging it up further, really! Just clarifying for
other reasons, not digging into you :)

Glad to see the other thread proceeding further, let's let this one die as
peacefully as it can...

Best,

f
-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

On Wed, Sep 23, 2015 at 3:21 PM, Travis Oliphant 
wrote:

>
>
>> Regarding the seed council, I just tried to pick an objective
>> criterion and an arbitrary date that seemed generally in keeping with
>> idea of "should be active in the last 1-to-2-years-ish". Fiddling with
>> the exact date in particular makes very little difference -- between
>> pushing it back to 2 years ago today or forward to 1 year ago today,
>> the only thing that changes is whether Pauli makes the list or not.
>> (And Pauli is obviously a great council candidate, though I don't know
>> whether he even wants to be on it.)
>>
>> > Personally, I have no idea how big the council should be. Too big, and
>> > there is no point, consensus is harder to reach the larger the group,
>> > and the main (only?) role of the council is to resolve issues where
>> > consensus has not been reached in the larger community. But what is
>> > too big?
>>
>>
>> > As for make-up of the council, I think we need to expand beyond people
>> > who have recently contributed core code.
>> >
>> > Yes, the council does need to have expertise to make technical
>> > decisions, but if you think about the likely contentious issues like
>> > ABI breakage, a core-code focused view is incomplete. So there should
>> > be representation by:
>> >
>> > Someone(s) with a long history of working with the code -- that
>> > institutional memory of why decisions were made the way they were
>> > could be key.
>>
>> Sure -- though I can't really imagine any way of framing a rule like
>> this that *wouldn't* be satisfied by Chuck + Ralf + Pauli, so my guess
>> is that such a rule would not actually have any effect on the council
>> membership in practice.
>>
>
> As the original author of NumPy, I would like to be on the seed council as
> long as it is larger than 7 people.That is my proposal.I don't need
> to be a permanent member, but I do believe I have enough history that I can
> understand issues even if I haven't been working on code directly.
>
> I think I do bring history and information that provides all of the
> history that could be helpful on occasion. In addition, if a matter is
> important enough to even be brought to the attention of this council, I
> would like to be involved in the discussion about it.
>
> It's a simple change to the text --- basically an explanation that Travis
> requested to be on the seed council.
>

I too would like you to be a member. We could either write it into the text
in recognition of your status as the Numpy creator, or it could be the
first order of business. I would only ask that you give yourself some time
to become familiar with how things work and the people involved in the
current community. It has been some years since you have been active in
code development.

Chuck

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

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

[Charles R Harris]

On Wed, Sep 23, 2015 at 3:42 PM, Chris Barker  wrote:

> On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant 
> wrote:
>
>
>> As the original author of NumPy, I would like to be on the seed council
>> as long as it is larger than 7 people.That is my proposal.
>>
>
> Or the seed council could invite Travis to join as its first order of
> business :-)
>
> Actually, maybe that's a way to handle it -- declare that the first order
> of business for teh seed council is to expand the council.
>

Perhaps we should specify a yearly meeting to review the past year and
nominate people for commit rights and council membership. Long term, we
might also want to start removing commit rights, perhaps by adding a team
category on github with restricted rights -- committer emeritus, so to
speak.


> I'd still like some guidelines (suggestions) for history and at least one
> major dependent-on-numpy rep. Travis would certainly meet the history
> requirement -- and maybe the other, too. :-)
>
>
>> It's a simple change to the text --- basically an explanation that Travis
>> requested to be on the seed council.
>>
>
> I'd rather the final draft of the document didn't name names, but no
> biggie.
>

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

Re: [Numpy-discussion] "Become an Open Source Contributor" workshop

[Charles R Harris]

On Wed, Sep 23, 2015 at 3:06 PM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:

> Apologies for the cross-posting.
>
> The Data Science Student Society of the University of California San
> Diego, or DS3 @ UCSD as they like to call themselves, will be holding
> biweekly Python themed workshops starting this fall.  On the week of
> October 19th, they will be having yours truly doing a "Become an Open
> Source Contributor" piece.  It will be a shortish event, 60-90 minutes, so
> my idea was to cover the following:
>
>1. (15 min) An introduction to the Python data science landscape.
>2. (30 min) An overview of the GitHub workflow that most (all?) of the
>projects follow.
>3. (30-45 min) A hands on session, where we would make sure everyone
>gets set up in GitHub, and forks and clones their favorite project.  Time
>and participant willingness permitting, I would like to take advantage of
>my commit bits, and have some of the participants submit a simple PR, e.g.
>fixing a documentation typo, to NumPy or SciPy, and hit the green button
>right there, so that they get to leave as knighted FOSS contributors.
>
>
You could create a `foolscrap` repo in the numpy project on github and use
that. That would probably be useful for other people as well.



Chuck

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

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

[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


On Wed, Sep 23, 2015 at 4:08 PM, Charles R Harris  wrote:

>
>
> On Wed, Sep 23, 2015 at 3:21 PM, Travis Oliphant 
> wrote:
>
>>
>>
>>> Regarding the seed council, I just tried to pick an objective
>>> criterion and an arbitrary date that seemed generally in keeping with
>>> idea of "should be active in the last 1-to-2-years-ish". Fiddling with
>>> the exact date in particular makes very little difference -- between
>>> pushing it back to 2 years ago today or forward to 1 year ago today,
>>> the only thing that changes is whether Pauli makes the list or not.
>>> (And Pauli is obviously a great council candidate, though I don't know
>>> whether he even wants to be on it.)
>>>
>>> > Personally, I have no idea how big the council should be. Too big, and
>>> > there is no point, consensus is harder to reach the larger the group,
>>> > and the main (only?) role of the council is to resolve issues where
>>> > consensus has not been reached in the larger community. But what is
>>> > too big?
>>>
>>>
>>> > As for make-up of the council, I think we need to expand beyond people
>>> > who have recently contributed core code.
>>> >
>>> > Yes, the council does need to have expertise to make technical
>>> > decisions, but if you think about the likely contentious issues like
>>> > ABI breakage, a core-code focused view is incomplete. So there should
>>> > be representation by:
>>> >
>>> > Someone(s) with a long history of working with the code -- that
>>> > institutional memory of why decisions were made the way they were
>>> > could be key.
>>>
>>> Sure -- though I can't really imagine any way of framing a rule like
>>> this that *wouldn't* be satisfied by Chuck + Ralf + Pauli, so my guess
>>> is that such a rule would not actually have any effect on the council
>>> membership in practice.
>>>
>>
>> As the original author of NumPy, I would like to be on the seed council
>> as long as it is larger than 7 people.That is my proposal.I don't
>> need to be a permanent member, but I do believe I have enough history that
>> I can understand issues even if I haven't been working on code directly.
>>
>>
>> I think I do bring history and information that provides all of the
>> history that could be helpful on occasion. In addition, if a matter is
>> important enough to even be brought to the attention of this council, I
>> would like to be involved in the discussion about it.
>>
>> It's a simple change to the text --- basically an explanation that Travis
>> requested to be on the seed council.
>>
>
> I too would like you to be a member. We could either write it into the
> text in recognition of your status as the Numpy creator, or it could be the
> first order of business. I would only ask that you give yourself some time
> to become familiar with how things work and the people involved in the
> current community. It has been some years since you have been active in
> code development.
>
> Chuck
>
>>
>>
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>


-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

On Wed, Sep 23, 2015 at 5:41 PM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:

> For what it is worth, I'm +1 on including any of the "founding fathers"
> (and uncles!) that wish to be included in the committee, or council, or
> however we ended up calling it.  I'm also OK with singling out Travis as
> creator of NumPy in the wording of the document.
>

I think "Founding Entities" would be the politically correct term ;)


>
> Especially since the prerogative of members is not to **VOTE**, but to
> **VETO**, I don't see adding more people having any effect on the
> individual power of members, so my +1 stands regardless of what the total
> member count is.
>
>


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

Re: [Numpy-discussion] ANN: numtraits v0.2

[Stefan van der Walt]

Hi Thomas

On 2015-09-23 09:39:00, Thomas Robitaille  wrote:
> We have released a small experimental package called numtraits that
> builds on top of the traitlets package and provides a NumericalTrait
> class that can be used to validate properties such as:

This looks great!  At the moment, a pip install tries to install a
different version of NumPy, even though I already have the development
version on my tree.  In scikit-image, we use something like the
following in setup.py to prevent that from happening:

 # Do not try and upgrade larger dependencies
 INSTALL_REQUIRES = ['numpy', 'traitlets']
 try:
 __import__('numpy')
 INSTALL_REQUIRES = ['traitlets']
 except ImportError:
 pass

Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ANN: numtraits v0.2

[Nathaniel Smith]

On Wed, Sep 23, 2015 at 5:10 PM, Stefan van der Walt
 wrote:
> Hi Thomas
>
> On 2015-09-23 09:39:00, Thomas Robitaille  wrote:
>> We have released a small experimental package called numtraits that
>> builds on top of the traitlets package and provides a NumericalTrait
>> class that can be used to validate properties such as:
>
> This looks great!  At the moment, a pip install tries to install a
> different version of NumPy, even though I already have the development
> version on my tree.

FYI the alternative solution is to fix your local numpy install to
give pip an accurate picture of what you have installed. The key thing
is to make sure you have a .egg-info / .dist-info for your numpy --
that's what pip looks for to figure out what's installed. (python
setupegg.py egg_info will generate one IIRC).

-n

-- 
Nathaniel J. Smith -- http://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Plan for 1.9.4 release

[Matthew Brett]

Hi,

I'm afraid our very helpful testers have found a problem with f2py and
Numpy 1.9.3 (and earlier):

https://github.com/numpy/numpy/issues/6348

I think we need a numpy 1.9.4 soon therefore.

I started a branch / PR here : https://github.com/numpy/numpy/pull/6350

Any other fixes?   Carl - do you want to get your mingw-w64 PR in for this?

Cheers,

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

Re: [Numpy-discussion] ANN: numtraits v0.2

[Stefan van der Walt]

On 2015-09-23 17:16:14, Nathaniel Smith  wrote:
>> This looks great!  At the moment, a pip install tries to install a
>> different version of NumPy, even though I already have the development
>> version on my tree.
>
> FYI the alternative solution is to fix your local numpy install to
> give pip an accurate picture of what you have installed. The key thing
> is to make sure you have a .egg-info / .dist-info for your numpy --
> that's what pip looks for to figure out what's installed. (python
> setupegg.py egg_info will generate one IIRC).

Looks like 'pip install -e .' in the numpy directory also fixed it.
Good to know, thanks.

Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Plan for 1.9.4 release

[Fernando Perez]

Chance this will be merged into 1.10? I know there's an rc floating out
there for 1.10, and this sounds like an actual bug...  Would be great to
have a solid 1.10 for the 3.5 crowd :)

On Wed, Sep 23, 2015 at 5:24 PM, Matthew Brett 
wrote:

> Hi,
>
> I'm afraid our very helpful testers have found a problem with f2py and
> Numpy 1.9.3 (and earlier):
>
> https://github.com/numpy/numpy/issues/6348
>
> I think we need a numpy 1.9.4 soon therefore.
>
> I started a branch / PR here : https://github.com/numpy/numpy/pull/6350
>
> Any other fixes?   Carl - do you want to get your mingw-w64 PR in for this?
>
> Cheers,
>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Plan for 1.9.4 release

[Matthew Brett]

Hi,

On Wed, Sep 23, 2015 at 5:30 PM, Fernando Perez  wrote:
> Chance this will be merged into 1.10? I know there's an rc floating out
> there for 1.10, and this sounds like an actual bug...  Would be great to
> have a solid 1.10 for the 3.5 crowd :)

1.10 already contains the f2py fixes, luckily...

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

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

[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


On Wed, Sep 23, 2015 at 6:08 PM, Charles R Harris  wrote:

>
>
> On Wed, Sep 23, 2015 at 3:21 PM, Travis Oliphant 
> wrote:
>
>>
>>
>>> Regarding the seed council, I just tried to pick an objective
>>> criterion and an arbitrary date that seemed generally in keeping with
>>> idea of "should be active in the last 1-to-2-years-ish". Fiddling with
>>> the exact date in particular makes very little difference -- between
>>> pushing it back to 2 years ago today or forward to 1 year ago today,
>>> the only thing that changes is whether Pauli makes the list or not.
>>> (And Pauli is obviously a great council candidate, though I don't know
>>> whether he even wants to be on it.)
>>>
>>> > Personally, I have no idea how big the council should be. Too big, and
>>> > there is no point, consensus is harder to reach the larger the group,
>>> > and the main (only?) role of the council is to resolve issues where
>>> > consensus has not been reached in the larger community. But what is
>>> > too big?
>>>
>>>
>>> > As for make-up of the council, I think we need to expand beyond people
>>> > who have recently contributed core code.
>>> >
>>> > Yes, the council does need to have expertise to make technical
>>> > decisions, but if you think about the likely contentious issues like
>>> > ABI breakage, a core-code focused view is incomplete. So there should
>>> > be representation by:
>>> >
>>> > Someone(s) with a long history of working with the code -- that
>>> > institutional memory of why decisions were made the way they were
>>> > could be key.
>>>
>>> Sure -- though I can't really imagine any way of framing a rule like
>>> this that *wouldn't* be satisfied by Chuck + Ralf + Pauli, so my guess
>>> is that such a rule would not actually have any effect on the council
>>> membership in practice.
>>>
>>
>> As the original author of NumPy, I would like to be on the seed council
>> as long as it is larger than 7 people.That is my proposal.I don't
>> need to be a permanent member, but I do believe I have enough history that
>> I can understand issues even if I haven't been working on code directly.
>>
>>
>> I think I do bring history and information that provides all of the
>> history that could be helpful on occasion. In addition, if a matter is
>> important enough to even be brought to the attention of this council, I
>> would like to be involved in the discussion about it.
>>
>> It's a simple change to the text --- basically an explanation that Travis
>> requested to be on the seed council.
>>
>
> I too would like you to be a member. We could either write it into the
> text in recognition of your status as the Numpy creator, or it could be the
> first order of business. I would only ask that you give yourself some time
> to become familiar with how things work and the people involved in the
> current community. It has been some years since you have been active in
> code development.
>
> Chuck
>
>>
>>
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>


-- 

*Travis Oliphant*
*Co-founder and CEO*


@teoliphant
512-222-5440
http://www.continuum.io
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Plan for 1.9.4 release

[Fernando Perez]

Ah, great, glad to hear that. Thx!

On Wed, Sep 23, 2015 at 5:43 PM, Matthew Brett 
wrote:

> Hi,
>
> On Wed, Sep 23, 2015 at 5:30 PM, Fernando Perez 
> wrote:
> > Chance this will be merged into 1.10? I know there's an rc floating out
> > there for 1.10, and this sounds like an actual bug...  Would be great to
> > have a solid 1.10 for the 3.5 crowd :)
>
> 1.10 already contains the f2py fixes, luckily...
>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

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

[Travis Oliphant]

On Wed, Sep 23, 2015 at 6:19 PM, Charles R Harris  wrote:

>
>
> On Wed, Sep 23, 2015 at 3:42 PM, Chris Barker 
> wrote:
>
>> On Wed, Sep 23, 2015 at 2:21 PM, Travis Oliphant 
>> wrote:
>>
>>
>>> As the original author of NumPy, I would like to be on the seed council
>>> as long as it is larger than 7 people.That is my proposal.
>>>
>>
>> Or the seed council could invite Travis to join as its first order of
>> business :-)
>>
>> Actually, maybe that's a way to handle it -- declare that the first order
>> of business for teh seed council is to expand the council.
>>
>
> Perhaps we should specify a yearly meeting to review the past year and
> nominate people for commit rights and council membership. Long term, we
> might also want to start removing commit rights, perhaps by adding a team
> category on github with restricted rights -- committer emeritus, so to
> speak.
>

That's a pretty good idea, actually.



>
>
>> I'd still like some guidelines (suggestions) for history and at least one
>> major dependent-on-numpy rep. Travis would certainly meet the history
>> requirement -- and maybe the other, too. :-)
>>
>>
>>> It's a simple change to the text --- basically an explanation that
>>> Travis requested to be on the seed council.
>>>
>>
>> I'd rather the final draft of the document didn't name names, but no
>> biggie.
>>
>
I'm fine with that too --- except you will need to name the initial seed
council.

-Travis




>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>


-- 

*Travis Oliphant*
*Co-founder and CEO*


@teoliphant
512-222-5440
http://www.continuum.io
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Tentative NumPy Tutorial inaccessible

[Stefan van der Walt]

On 2015-09-22 23:53:19, Nathaniel Smith  wrote:
> On Tue, Sep 22, 2015 at 10:58 PM, Andriy Yurchuk  wrote:
>> Hi!
>>
>> The Tentative NumPy Tutorial is no longer accessible by the URL
>> http://wiki.scipy.org/Tentative_NumPy_Tutorial, it returns a 403. The link
>> to this page is still on NumPy homepage though. Has the page been moved
>> somewhere else?
>
> No, our infrastructure is just in some disarray right now... there's
> some discussion here: https://github.com/numpy/numpy/issues/6325
> (and I just pointed this out there as well since the relevant admins
> seem to be reading that thread).

FWIW, that tutorial is not that useful any longer.  I'd refer to

http://scipy-lectures.github.io/

instead.

Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ANN: numtraits v0.2

[Sylvain Corlay]

Hi Thomas,

This is great news!

FYI, the traitlets module has been undergoing significant refactoring
lately, improving the API to favor a broader usage in the community.  One
reason for this is that several projects outside of the Jupyter
organization are considering adopting traitlets. You can find a summary of
the ongoing work and API changes here:
https://github.com/ipython/traitlets/issues/48

One of the items in this discussion is about what would be the best place
for a repository of trait types for standard data structures of the scipy
stack (numpy array, pandas series and dataframes, etc...) It is unlikely
that such trait types would be accepted in those libraries at this moment,
and the main traitlets package might not be the right place for it either -
hence the need for another repo. However, if we don't work on a centralized
project, we will probably see a number of competing implementations in
different libraries that are clients of traitlets.

Hence the idea would be to propose a new project in the Jupyter incubator
with a reference implementation. What would be cool would be to join forces
and work on a specification or start a discussion of what the ideal
implementation for such trait types would look like.

Cheers,

Sylvain


On Wed, Sep 23, 2015 at 12:39 PM, Thomas Robitaille <
thomas.robitai...@gmail.com> wrote:

> Hi everyone,
>
> We have released a small experimental package called numtraits that
> builds on top of the traitlets package and provides a NumericalTrait
> class that can be used to validate properties such as:
>
> * number of dimension (for arrays)
> * shape (for arrays)
> * domain (e.g. positive, negative, range of values)
> * units (with support for astropy.units, pint, and quantities)
>
> The idea is to be able to write a class like:
>
> class Sphere(HasTraits):
>
> radius = NumericalTrait(domain='strictly-positive', ndim=0)
> position = NumericalTrait(shape=(3,))
>
> and all the validation will then be done automatically when the user
> sets 'radius' or 'position'.
>
> In addition, tuples and lists can get automatically converted to
> arrays, and default values can be specified. You can read more about
> the package and see examples of it in use here:
>
>   https://github.com/astrofrog/numtraits
>
> and it can be easily installed with
>
>   pip install numtraits
>
> The package supports both Python 3.3+ and Legacy Python (2.7) :)
>
> At this point, we would be very interested in feedback - the package
> is still very young and we can still change the API if needed. Please
> open issues with suggestions!
>
> Cheers,
>
> Tom and Francesco
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Fwd: [Matplotlib-devel] Fwd: [NumFOCUS Projects] grant opportunity

[Nathaniel Smith]

-- Forwarded message --
From: Thomas Caswell 
Date: Wed, Sep 23, 2015 at 8:51 PM
Subject: [Matplotlib-devel] Fwd: [NumFOCUS Projects] grant opportunity
To: matplotlib development list 


If anyone has some downtime and would like to be paid to hack on open source.

Submissions are due Sept 30

Tom

-- Forwarded message -
From: Gina Helfrich 
Date: Fri, Sep 18, 2015 at 12:10 PM
Subject: [NumFOCUS Projects] grant opportunity
To: 


Hi all,

Wanted to bring this opportunity to your attention:

Stripe is looking to host three to four developers at their San
Francisco office for three months to work full-time on an open-source
project. The grant is no-strings-attached: $7,500 per month in
addition to desk space at our office and meals during the week. "We
want to provide everything needed to focus and have a substantial
impact on an open-source project."

More info: https://stripe.com/blog/open-source-retreat-2016

The program will run from January 15th until April 15th, 2016 at
Stripe HQ in the Mission District of San Francisco.

Best,
Gina

--
Gina Helfrich, Ph.D.
Communications Director
NumFOCUS | Open Code, Better Science
g...@numfocus.org | 512-222-5449

--
You received this message because you are subscribed to the Google
Groups "Fiscally Sponsored Project Representatives" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to projects+unsubscr...@numfocus.org.
To post to this group, send email to proje...@numfocus.org.
Visit this group at http://groups.google.com/a/numfocus.org/group/projects/.
To view this discussion on the web visit
https://groups.google.com/a/numfocus.org/d/msgid/projects/CAFhTXRPxOsUubAHE%2BJuXzk%2B%3D4KjJmwXnAWGzNGw%3DPuXnQeiFhg%40mail.gmail.com.

___
Matplotlib-devel mailing list
matplotlib-de...@python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel



-- 
Nathaniel J. Smith -- http://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Governance model request

[Paul Ivanov]

On Wed, Sep 23, 2015 at 3:37 PM, Fernando Perez 
wrote:

>
> Glad to see the other thread proceeding further, let's let this one die as
> peacefully as it can...
>
>
This Monty Python sketch seems relevant:

https://www.youtube.com/watch?v=grbSQ6O6kbs

(hope everyone's in good health and regains better spirits, back to lurking
for me)
-- 
   _
  / \
A*   \^   -
 ,./   _.`\\ / \
/ ,--.S\/   \
   /  `"~,_ \\
 __o   ?
   _ \<,_ /:\
--(_)/-(_).../ | \
--...J
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Python needs goto

[Charles R Harris]

At last, goto for python !

Usage:

from goto import with_goto

@with_goto
def range(start, stop):
i = start
result = []

label .begin
if i == stop:
goto .end

result.append(i)
i += 1
goto .begin

label .end
return result


HT: LWN

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