Hi, On Tue, Oct 25, 2011 at 11:24 AM, Benjamin Root <ben.root@ou.edu> wrote:
On Tue, Oct 25, 2011 at 1:03 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Oct 25, 2011 at 8:04 AM, Lluís <xscript@gmx.net> wrote:
Matthew Brett writes:
I'm afraid I find this whole thread very unpleasant.
I have the odd impression of being back at high school. Some of the big kids are pushing me around and then the other kids join in.
It didn't have to be this way.
Someone could have replied like this to Nathaniel:
"Oh - yes - I'm sorry - we actually had the discussion on the pull request. Looking back, I see that we didn't flag this up on the mailing list and maybe we should have. Thanks for pointing that out. Maybe we could start another discussion of the API in view of the changes that have gone in".
But that didn't happen.
Well, I really thought that all the interested parties would take a look at [1].
While it's true that the pull requests are not obvious if you're not using the functionalities of the github web (or unless announced in this list), I think that Mark's announcement was precisely directed at having a new round of discussions after having some code to play around with and see how intuitive or counter-intuitive the implemented concepts could be.
I just wanted to be clear what I meant.
The key point is not whether or not the pull-request or request for testing was in fact the right place for the discussion that Travis suggested. I guess you can argue that either way. I'd say no, but I can see how you would disagree on that.
This is getting very meta... a disagreement about the disagreement.
Yes, the important point is a social one. The other points are details.
The key point is - how much do we value constructive disagreement?
Personally, I value it very much.
Well - I think everyone believes that that they value constructive discussion, but the question is, what happens when people really disagree?
My impression of the discussion we all had at the beginning was that the needs of the two distinct communities (R-users and masked array users) were both heard and largely addressed. Aspects of both approaches were used, and the final result is, IMHO, inspired and elegant. Is it perfect? No. Are there ways to improve it? Absolutely, and I fully expect that to happen.
To be clear once more, I personally feel we don't need to discuss: 1) Whether Mark did a good job on the code (I have high bias to imagine so). 2) Whether something along these lines would be good to have in numpy
If we do value constructive disagreement then we'll go out of our way to talk through the points of contention, and make sure that the people who disagree, especially the minority, feel that they have been fully heard.
If we don't value constructive disagreement then we'll let the other side know that further disagreement will be taken as a sign of bad faith.
Now - what do you see here? I see the second and that worries me.
It is disappointing that you choose not to participate in the thread linked above or in the pull request itself. If I remember correctly, you were working on finishing up your dissertation, so I fully understand the time constraints involved there. However, the pull request and the email notification is the de facto method of staging and discussing changes in any development project. No objections were raised in that pull request, so it went in after some time passed. To hold off the merge, all one would need to do is fire off a quick comment requesting a delay to have a chance to review the pull request.
I think the pull-request was not the right vehicle for the discussion, you think it was, that's fine, I don't think we need to rehearse that. My question (if you are answering my question) is: if you put yourself in my or Nathaniel's shoes, would you feel that you had been warmly encouraged to express disagreement, or would you feel something else.
Luckily, git is a VCS, so we are fully capable of reverting any necessary changes if warranted. If you have any concerns or suggestions for changes in the current implementation, feel free to raise them and open additional pull requests. There is no "ganging up" here or any other subterfuge. Tell us exactly what are your issues with the current setup, provide example code demonstrating the issues, and we can certainly discuss ways to improve this.
Has the situation changed since the counter-NEP that Nathaniel and I wrote up?
Remember, we *all* have a common agreement here. NumPy needs better support for missing data (in whatever form). Let's work from that assumption and make NumPy a better library to use for everybody!
I remember walking past a church in a small town in the California desert. It had a sign outside saying 'People who are busy rowing do not have time to rock the boat'. This seemed to me a total failure to understand the New Testament, but also a recipe for organizational disaster. See you, Matthew