Re: [Numpy-discussion] Numpy discussion - was: Raveling, reshape order keyword unnecessarily confuses index and memory ordering
Hi, On Sat, Apr 6, 2013 at 10:18 AM, matti picus <matti.picus@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.
It seems all agree that docs needs improvement, perhaps a first step would be to suggest doc improvements, and then the need for renaming may become self-evident, or not.
I'm sure you're right - that doing the docs first would help, and thank you for the suggestion. Cheers, Matthew [1] https://github.com/numpy/numpy.org/blob/master/NA-overview.rst
Matthew Brett, on 2013-04-06 10:39, wrote:
Hi,
On Sat, Apr 6, 2013 at 10:18 AM, matti picus <matti.picus@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 discussion. 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: charris cournape njsmith pv rgommers rkern seberg teoliphant 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
Paul Ivanov <pivanov314 <at> gmail.com> writes: [clip]
In a related note - it should be made clear who the core committers are, at this point. The github organization lists the following eight:
charris cournape njsmith pv rgommers rkern seberg teoliphant
Is that the core, the whole core, and nothing but the core?
Actually, that's the list of people with admin access to the numpy organization, for creating repositories and managing commit access. The actual committer list is here (github has managed to make the team lists difficult to find): https://github.com/organizations/numpy/teams/14102 certik charris cournape FrancescAlted mwiebe njsmith pv rgommers rkern seberg stefanv teoliphant thouis Sure, it contains some names (such as mine) with previous association with the project but not so much recent activity. On the other hand, I don't see obvious missing names -- the policy has been to give commit access for people with sustained code contributions, see also git shortlog -a -c -s --since=now-2year | sort -n -- Pauli Virtanen
On Mon, Apr 8, 2013 at 5:38 AM, Pauli Virtanen <pav@iki.fi> wrote:
Paul Ivanov <pivanov314 <at> gmail.com> writes: [clip]
In a related note - it should be made clear who the core committers are, at this point. The github organization lists the following eight:
charris cournape njsmith pv rgommers rkern seberg teoliphant
Is that the core, the whole core, and nothing but the core?
Actually, that's the list of people with admin access to the numpy organization, for creating repositories and managing commit access.
The actual committer list is here (github has managed to make the team lists difficult to find):
https://github.com/organizations/numpy/teams/14102
certik charris cournape FrancescAlted mwiebe njsmith pv rgommers rkern seberg stefanv teoliphant thouis
Sure, it contains some names (such as mine) with previous association with the project but not so much recent activity. On the other hand, I don't see obvious missing names -- the policy has been to give commit access for people with sustained code contributions, see also
git shortlog -a -c -s --since=now-2year | sort -n
I find this helpful for a quick overview: http://www.ohloh.net/p/numpy/contributors?query=&sort=commits_12_mo Josef
-- Pauli Virtanen
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Apr 8, 2013 at 2:04 AM, Paul Ivanov <pivanov314@gmail.com> wrote:
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.
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 discussion.
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 number change. 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. Cheers, Ralf
Ralf Gommers, on 2013-04-09 00:06, wrote:
G. website improvement --> thank you, desperately needed. Here's some login credentials and a medal.
see https://github.com/numpy/numpy.org/pull/1 Do I really get a medal? ;) best, -- Paul Ivanov 314 address only used for lists, off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
On Mon, Apr 8, 2013 at 5:30 PM, Paul Ivanov <pivanov314@gmail.com> wrote:
Ralf Gommers, on 2013-04-09 00:06, wrote:
G. website improvement --> thank you, desperately needed. Here's some login credentials and a medal.
see https://github.com/numpy/numpy.org/pull/1
Do I really get a medal? ;)
Send the barcode and a self addressed envelope to NMR (Numpy Medal Rewards), PO Box 314159, Reno NV, and and we'll think about it. Chuck
participants (6)
-
Charles R Harris -
josef.pktd＠gmail.com -
Matthew Brett -
Paul Ivanov -
Pauli Virtanen -
Ralf Gommers