[Numpy-discussion] Numpy discussion - was: Raveling, reshape order keyword unnecessarily confuses index and memory ordering
pivanov314 at gmail.com
Sun Apr 7 20:04:11 EDT 2013
Matthew Brett, on 2013-04-06 10:39, wrote:
> 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'
> 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 .
> 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.
>  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  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.
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
Is that the core, the whole core, and nothing but the core?
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