[Numpy-discussion] Numpy discussion - was: Raveling, reshape order keyword unnecessarily confuses index and memory ordering

Paul Ivanov pivanov314 at gmail.com
Sun Apr 7 20:04:11 EDT 2013

Matthew Brett, on 2013-04-06 10:39,  wrote:
> Hi,
> On Sat, Apr 6, 2013 at 10:18 AM, matti picus <matti.picus at gmail.com> wrote:
> > as a lurker, may I say that this discussion seems to have become
> > non-productive?
> Well - the discussion is about two things - as so often the case on numpy.
> The first is about the particular change.
> The second is implicit, and keeps coming up, and that is about how
> change of any sort comes about in numpy.  These questions keep coming
> up.  Who decides on change?  Is there a veto?  Who has it?  When do we
> vote, when do we negotiate?
> For example, one small part of the discussion was the lack of
> developers in numpy.
> For some, stopping these long discussions (somehow) will help recruit
> developers.  The idea is that developers don't like these discussions,
> and, implicitly, that there is no problem, so the discussion is
> unnecessary.  This is a version of the old  'no man, no problem'
> solution.
> For others, these long and unproductive discussions are pointing at a
> severe problem right at the heart of numpy development, which is that
> it is very hard to work in a system where it is unclear how decisions
> get made. See for example Mark Wiebe's complaint at the end here [1].
>   If this second lot of people are right then we have two options a)
> stop the discussions, numpy decays and dies from lack of direction b)
> continue the discussions and hope that it becomes clear that this is
> indeed a serious problem, and there develops some agreement to fix it.
> [1] https://github.com/numpy/numpy.org/blob/master/NA-overview.rst

I just wanted to chime in that while the document on contributing
to numpy [2] is pretty thorough in terms of the technical details
expected of a submission - it makes practically no allusions to
the social aspects of contributing changes - e.g. the
expectations one should have when proposing a change - a loose
flowchart or set of possible outcomes.
2. http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html

Here's an example of what those expectations might be:

1. your change gets reviewed by a core committer, is deemed
acceptable, and gets merged.

2. specific changes are required to the implementation/logic,
after which the PR will be deemed acceptable, and get merged

3. the proposal is too broad in scope, or proposes a drastic
change that has not been discussed on the list, and should be
paused from further action pending the outcome of such a

About a year ago, it seems like something like situation 3
occurred, where folks didn't feel like there was sufficient
notice outside of having to pay attention to the Numpy PR queue.

In a related note - it should be made clear who the core
committers are, at this point. The github organization lists the
following eight:


Is that the core, the whole core, and nothing but the core?
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

More information about the NumPy-Discussion mailing list