[Numpy-discussion] Numpy governance update

[Mark Wiebe]

On Wed, Feb 15, 2012 at 1:36 PM, Matthew Brett <matthew.brett at gmail.com>wrote:

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

The only way to reasonably mitigate the risk of development expertise being
in one company is to recruit more developers from elsewhere. I think those
new developers will appreciate having a say about how governance works,
which is why I suggested to postpone the meat of this discussion with an
interim solution, and move on to the recruitment topic.


> > If we need a formal structure, maybe a good approach is giving Travis the
> > final say for now, until a trigger point occurs. That could be 6 months
> > after the number of active developers hits 5, or something like that. At
> > that point, we would reopen the discussion with a larger group of people
> who
> > would directly play in that role, and any decision made then will
> probably
> > be better than a decision we make now while the development team is so
> > small.
>
> Honestly - as I was saying to Alan and indirectly to Ben - any formal
> model - at all - is preferable to the current situation. Personally, I
> would say that making the founder of a company, which is working to
> make money from Numpy, the only decision maker on numpy - is - scary.
>

I'm proposing to make Travis the backstop for when a decision can't be
decided informally, not to force all decisions through him. There's a
closely related project, Python, which follows a similar approach. ;)


> But maybe it's the best way.   But, again, we're all high-functioning
> sensible people, I'm sure it's possible for us to formulate what the
> risks are, what the potential solutions are, and come up with the best
> - maybe short-term - solution,
>

The biggest risk I see is stagnant development. If there has to be a formal
structure, I think it should be as simple as possible right now. I believe
Travis's heart is in the right place to tackle the many problems NumPy
faces, and putting him in the role of "decider of last resort" is a simple
formal structure that I believe will work well. When there is a bigger
active development community, there will be more voices, and more
importantly, those voices will represent the experience gained from a
bigger development team interacting with the numpy user community. That is
a better time to design a more complex governance structure.

Cheers,
Mark


>
> See you,
>
> Matthew
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120215/87e6e744/attachment.html>