<br><br><div class="gmail_quote">On Sat, Dec 10, 2011 at 8:19 AM, Bruce Southey <span dir="ltr"><<a href="mailto:bsouthey@gmail.com">bsouthey@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Mon, Dec 5, 2011 at 11:32 PM, Matthew Brett <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> 2011/12/5 Stéfan van der Walt <<a href="mailto:stefan@sun.ac.za">stefan@sun.ac.za</a>>:<br>
>> As for barriers to entry, improving the the nature of discourse on the<br>
>> mailing list (when it comes to thorny issues) would be good.<br>
>> Technical barriers are not that hard to breach for our community;<br>
>> setting the right social atmosphere is crucial.<br>
><br>
> I'm just about to get on a plane and am going to be out of internet<br>
> range for a while, so, in the spirit of constructive discussion:<br>
><br>
> In the spirit of use-cases:<br>
><br>
> Would it be fair to say that the two contentious recent discussions have been:<br>
><br>
> The numpy ABI breakage, 2.0 vs 1.5.1 discussion<br>
> The masked array discussion(s) ?<br>
><br>
> What did we do wrong or right in each of these two discussions?  What<br>
> could we have done better?  What process would help us to do better?<br>
><br>
> Travis - for your board-only-post mailing list - my feeling is that<br>
> this is going in the wrong direction.  The effect of the board-only<br>
> mailing list is to explicitly remove non-qualified people from the<br>
> discussion.   This will make it more explicit that the substantial<br>
> decisions will be make by a few important people.   Do you (Travis -<br>
> or Mark?) think that, if this had happened earlier in the masked array<br>
> discussion, it would have been less contentious, or had more<br>
> substantial content?  My instinct would be the reverse, and the best<br>
> solution would have been to pause and commit to beating out the issues<br>
> and getting agreement.<br>
><br>
> See you,<br>
><br>
> Matthew<br>
<br>
</div></div>I would also like to know the long term model for development since<br>
some of issues a direct results of that model. At the moment we seem<br>
stuck in the old svn model as we have a release that essentially<br>
splits from the current development branch where key developers just<br>
merge into without any discussion. This 'old svn' view did create some<br>
discussion regarding the NA object including the pull request. But we<br>
lacked the step about moving it into the current developmental branch.<br>
So at times that seemed to add 'insult to injury'<br>
(<a href="http://idioms.thefreedictionary.com/add+insult+to+injury" target="_blank">http://idioms.thefreedictionary.com/add+insult+to+injury</a>) which<br>
tended to decrease some of the interesting ideas expressed.<br>
<br>
So perhaps we could find a model that allows real bug fixes (ie have a<br>
valid ticket or maximum of 5 lines of changed code) to go the current<br>
developmental branch and enhancements come through as some other<br>
process that involves community discussions?<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>I think the rule should be that *anyone* seriously interested in what is happening in numpy development should be watching the pull requests. The complementary rule is that all commits go in through a pull request. There isn't much traffic on the pull requests and code/functionality review at that point is both useful and desirable. Large topics do tend to turn up on the list, the NA work, for example. But github makes it easy to follow what is going on and folks should take advantage of it.<br>
<br>Chuck<br></div><br></div>