[Numpy-discussion] Numpy discussion - was: Raveling, reshape order keyword unnecessarily confuses index and memory ordering
Mon Apr 8 17:06:58 CDT 2013
On Mon, Apr 8, 2013 at 2:04 AM, Paul Ivanov <email@example.com> wrote:
> 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.
This is a point I recognize, more description/guidance on how things work
(or should work) in practice would be useful. Last year we did make an
attempt to write up something on community process for SciPy:
https://github.com/scipy/scipy/blob/master/HACKING.rst.txt. I suspect it's
more beginner-oriented than what you have in mind, but large parts of it
could be taken over for numpy.
> 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
Good examples, here are a few more.
4. the proposal looks good, but hasn't yet been discussed on the list.
Please go do that, after that we continue.
5. You don't get a response to your PR or your post on the mailing list.
This ideally shouldn't happen, however the numpy development team is small
and very busy. Don't take it personally. If more than a week has passed
(for an email) please ping the list again. For PRs wait at least a week or
two, unless it's an urgent bug fix.
To me, the type of response that one is likely to receive is connected to
the type of contribution:
A. bug fix. --> situation 1 or 2
B. new feature/function --> situation 3 or 4
C. documentation, build improvement, etc. --> situation 1 or 2
D. backwards-incompatible changes --> there's a strong feeling in the
community that non-backwards-compatible changes are to be avoided unless
there's a very good reason why those changes have to be made. Only propose
these if you are convinced that there are no ways to achieve what you want
in another way. Do expect some resistance.
D1. ABI changes --> these are a last resort, and require a major version
D2. API changes --> these are in most cases less painful than ABI
changes, but don't happen all that often - even if the change is accepted a
(>1 year long) deprecation process is needed.
E. forwards-incompatible changes --> there's no guarantee that numpy
provides forwards compatibility. We don't go and break this for no reason,
but the threshold is low. Please discuss on the list.
F. adding new sub-modules --> situation 3. Adding new sub-modules is rare.
The numpy namespace is relatively flat, we aim to keep it that way. There
has to be a very good reason to add a new module.
G. website improvement --> thank you, desperately needed. Here's some login
credentials and a medal.
If the scipy doc I linked and the above make sense, I can draft something
for the numpy docs for people to comment on. I don't have much time this
week though, so I'd be grateful if someone would help out with this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion