[Numpy-discussion] Numpy governance update

[josef.pktd at gmail.com]

On Wed, Feb 15, 2012 at 7:27 PM, Dag Sverre Seljebotn
<d.s.seljebotn at 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.brett at gmail.com
>> <mailto:matthew.brett at gmail.com>> wrote:
>>
>>     Hi,
>>
>>     On Wed, Feb 15, 2012 at 12:55 PM, Mark Wiebe <mwwiebe at gmail.com
>>     <mailto:mwwiebe at gmail.com>> wrote:
>>      > On Wed, Feb 15, 2012 at 12:09 PM, Matthew Brett
>>     <matthew.brett at gmail.com <mailto:matthew.brett at gmail.com>>
>>      > wrote:
>>      >>
>>      >> Hi,
>>      >>
>>      >> On Wed, Feb 15, 2012 at 11:46 AM, Benjamin Root <ben.root at ou.edu
>>     <mailto:ben.root at ou.edu>> wrote:
>>      >> >
>>      >> >
>>      >> > On Wed, Feb 15, 2012 at 1:32 PM, Alan G Isaac
>>     <alan.isaac at gmail.com <mailto:alan.isaac at 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.

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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion