On Wed, Feb 15, 2012 at 5:26 PM, Mark Wiebe <mwwi...@gmail.com> wrote: > On Wed, Feb 15, 2012 at 4:57 PM, <josef.p...@gmail.com> wrote: >> >> On Wed, Feb 15, 2012 at 7:27 PM, Dag Sverre Seljebotn >> <d.s.seljeb...@astro.uio.no> wrote: >> > On 02/15/2012 02:24 PM, Mark Wiebe wrote: >> >> On Wed, Feb 15, 2012 at 1:36 PM, Matthew Brett <matthew.br...@gmail.com >> >> <mailto:matthew.br...@gmail.com>> wrote: >> >> >> >> Hi, >> >> >> >> On Wed, Feb 15, 2012 at 12:55 PM, Mark Wiebe <mwwi...@gmail.com >> >> <mailto:mwwi...@gmail.com>> wrote: >> >> > On Wed, Feb 15, 2012 at 12:09 PM, Matthew Brett >> >> <matthew.br...@gmail.com <mailto:matthew.br...@gmail.com>> >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> On Wed, Feb 15, 2012 at 11:46 AM, Benjamin Root >> >> <ben.r...@ou.edu >> >> <mailto:ben.r...@ou.edu>> wrote: >> >> >> > >> >> >> > >> >> >> > On Wed, Feb 15, 2012 at 1:32 PM, Alan G Isaac >> >> <alan.is...@gmail.com <mailto:alan.is...@gmail.com>> >> >> >> > wrote: >> >> >> >> Can you provide an example where a more formal >> >> >> >> governance structure for NumPy would have meant >> >> >> >> more or better code development? (Please do not >> >> >> >> suggest the NA discussion!) >> >> >> >> >> >> >> > >> >> >> > Why not the NA discussion? Would we really want to have that >> >> happen >> >> >> > again? >> >> >> > Note that it still isn't fully resolved and progress still >> >> needs to be >> >> >> > made >> >> >> > (I think the last thread did an excellent job of fleshing out >> >> the ideas, >> >> >> > but >> >> >> > it became too much to digest. We may need to have someone go >> >> through >> >> >> > the >> >> >> > information, reduce it down and make one last push to bring >> >> it >> >> to a >> >> >> > conclusion). The NA discussion is the perfect example where >> >> a >> >> >> > governance >> >> >> > structure would help resolve disputes. >> >> >> >> >> >> Yes, that was the most obvious example. I don't know about you, >> >> but I >> >> >> can't see any sign of that one being resolved. >> >> >> >> >> >> The other obvious example was the dispute about ABI breakage >> >> for >> >> numpy >> >> >> 1.5.0 where I believe Travis did invoke some sort of committee >> >> to >> >> >> vote, but (Travis can correct me if I'm wrong), the committee >> >> was >> >> >> named ad-hoc and contacted off-list. >> >> >> >> >> >> > >> >> >> >> >> >> >> >> Can you provide an example of what you might >> >> >> >> envision as a "more formal governance structure"? >> >> >> >> (I assume that any such structure will not put people >> >> >> >> who are not core contributors to NumPy in a position >> >> >> >> to tell core contributors what to spend their time on.) >> >> >> >> >> >> >> >> Early last December, Chuck Harris estimated that three >> >> >> >> people were active NumPy developers. I liked the idea of >> >> >> >> creating a "board" of these 3 and a rule that says any >> >> >> >> active developer can request to join the board, that >> >> >> >> additions are determined by majority vote of the existing >> >> >> >> board, and that having the board both small and odd >> >> >> >> numbered is a priority. I also suggested inviting to this >> >> >> >> board a developer or two from important projects that are >> >> >> >> very NumPy dependent (e.g., Matplotlib). >> >> >> >> >> >> >> >> I still like this idea. Would it fully satisfy you? >> >> >> >> >> >> >> > >> >> >> > I actually like that idea. Matthew, is this along the lines >> >> of what you >> >> >> > were thinking? >> >> >> >> >> >> Honestly it would make me very happy if the discussion moved to >> >> what >> >> >> form the governance should take. I would have thought that 3 >> >> was too >> >> >> small a number. >> >> > >> >> > >> >> > One thing to note about this point is that during the NA >> >> discussion, the >> >> > only people doing active C-level development were Charles and >> >> me. >> >> I suspect >> >> > a discussion about how to recruit more people into that group >> >> might be more >> >> > important than governance at this point in time. >> >> >> >> Mark - a) thanks for replying, it's good to hear your voice and b) >> >> I >> >> don't think there's any competition between the discussion about >> >> governance and the need to recruit more people into the group who >> >> understand the C code. >> >> >> >> >> >> There hasn't really been any discussion about recruiting developers to >> >> compete with the governance topic, now we can let the topics compete. >> >> :) >> >> >> >> Some of the mechanisms which will help are already being set in motion >> >> through the discussion about better infrastructure support like bug >> >> trackers and continuous integration. The forthcoming roadmap discussion >> >> Travis alluded to, where we will propose a roadmap for review by the >> >> numpy user community, will include many more such points. >> >> >> >> Remember we are deciding here between governance - of a form to be >> >> decided - and no governance - which I think is the current >> >> situation. >> >> I know your desire is to see more people contributing to the C >> >> code. >> >> It would help a lot if you could say what you think the barriers >> >> are, >> >> how they could be lowered, and the risks that you see as a result >> >> of >> >> the numpy C expertise moving essentially into one company. Then we >> >> can formulate some governance that would help lower those barriers >> >> and >> >> reduce those risks. >> >> >> >> >> >> There certainly is governance now, it's just informal. It's a >> >> combination of how the design discussions are carried out, how pull >> >> requests occur, and who has commit rights. >> > >> > +1 >> > >> > If non-contributing users came along on the Cython list demanding that >> > we set up a system to select non-developers along on a board that would >> > have discussions in order to veto pull requests, I don't know whether >> > we'd ignore it or ridicule it or try to show some patience, but we >> > certainly wouldn't take it seriously. >> > >> > It's obvious that one should try for consensus as long as possible, >> > including listening to users. But in the very end, when agreement can't >> > be reached by other means, the developers are the one making the calls. >> > (This is simply a consequence that they are the only ones who can >> > credibly threaten to fork the project.) >> > >> > Sure, structures that includes users in the process could be useful... >> > but, if the devs are fine with the current situation (and I don't see >> > Mark or Charles complaining), then I honestly think it is quite rude to >> > not let the matter drop after the first ten posts or so. >> > >> > Making things the way one wants it and scratching *ones own* itch is THE >> > engine of open source development (whether one is putting in spare time >> > or monetary funding). Trying to work against that with artificial >> > structures doesn't sound wise for a project with as few devs as NumPy... >> >> I don't think you can restrict the Numpy developer or contributor >> group just to the developers that work on the C core like Charles and >> Mark, and others over the years I have been following it ( Pauli and >> David, ...). >> There is a large part of non C numpy, Pierre for example, and Joe >> Harrington put money and a lot of effort into bringing the >> documentation into the current state, the documentation was mostly a >> community effort. > > > This is very true, at the moment the number of people doing feature-work > within numpy purely in Python is similarly small and sporadic. Here's a > current example: > > https://github.com/numpy/numpy/pull/198 > > Having such a small development core is one of the reasons it often takes a > while for such pull requests to get reviewed by someone, and a situation > Continuum and anyone else with resources to contribute can help improve. One > thing that's clear to me is that the current documentation on how to > contribute code, documentation, and other help to NumPy is lacking, and this > is something that needs improvement. > > An example I really like is LibreOffice's "get involved" page. > > http://www.libreoffice.org/get-involved/ > > Producing something similar for NumPy will take some work, but I believe > it's needed. >
+1 to Mark, Perry, Dag. On the topic of 'nifty webpages other projects have that I wish numpy/scipy had', eigen (an open-source C++ linear algebra library) has a nice To Do list that gives concrete, approachable things new developers could add to: http://eigen.tuxfamily.org/index.php?title=Todo. 'Course, that would mean people agreeing on what there was to do.... -Chris JS > Cheers, > Mark > >> >> >> Of course I only ever contributed to scipy, except of two or three >> bugfixes in numpy.random, but I still care about the direction numpy >> is going, as do developers of the "SciPy" community which crucially >> rely on numpy. >> >> Josef >> >> >> > >> > Dag >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion@scipy.org >> > http://mail.scipy.org/mailman/listinfo/numpy-discussion >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
