[Numpy-discussion] NumPy Governance

[Charles R Harris]

On Mon, Dec 5, 2011 at 12:43 PM, Benjamin Root <ben.root at ou.edu> wrote:

> On Mon, Dec 5, 2011 at 12:06 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
>
>> On Sat, Dec 3, 2011 at 6:18 PM, Travis Oliphant <teoliphant at gmail.com>wrote:
>>
>>>
>>> Hi everyone,
>>>
>>> There have been some wonderfully vigorous discussions over the past few
>>> months that have made it clear that we need some clarity about how
>>> decisions will be made in the NumPy community.
>>>
>>> When we were a smaller bunch of people it seemed easier to come to an
>>> agreement and things pretty much evolved based on (mostly) consensus and
>>> who was available to actually do the work.
>>>
>>> There is a need for a more clear structure so that we know how decisions
>>> will get made and so that code can move forward while paying attention to
>>> the current user-base.   There has been a "steering committee" structure
>>> for SciPy in the past, and I have certainly been prone to lump both NumPy
>>> and SciPy together given that I have a strong interest in and have spent a
>>> great amount of time working on both projects.    Others have also spent
>>> time on both projects.
>>>
>>> However, I think it is critical at this stage to clearly separate the
>>> projects and define a governing structure that is fair and agreeable for
>>> NumPy.   SciPy has multiple modules and will probably need structure around
>>> each module independently.    For now, I wanted to open up a discussion to
>>> see what people thought about NumPy's governance.
>>>
>>> My initial thoughts:
>>>
>>>        * discussions happen as they do now on the mailing list
>>>        * a small group of developers (5-11) constitute the "board" and
>>> major decisions are made by vote of that group (not just simple majority
>>> --- needs at least 2/3 +1 votes).
>>>        * votes are +1/+0/-0/-1
>>>        * if a topic is difficult to resolve it is moved off the main
>>> list and discussed on a separate "board" mailing list --- these should be
>>> rare, but parts of the NA discussion would probably qualify
>>>        * This board mailing list is "publically" viewable but only board
>>> members may post.
>>>        * The board is renewed and adjusted each year --- based on
>>> nomination and 2/3 vote of the current board until board is at 11.
>>>        * The chairman of the board is voted by a majority of the board
>>> and has veto power unless over-ridden by 3/4 of the board.
>>>        * Petitions to remove people off the board can be made by 50+
>>> independent reverse nominations (hopefully people will just withdraw if
>>> they are no longer active).
>>>
>>> All of these points are open for discussion.  I just thought I would
>>> start the conversation.   I will be much more active this next year with
>>> NumPy and will be very interested in the direction NumPy is taking.    I'm
>>> hoping to discern by this conversation, who else is very interested in the
>>> direction of NumPy so that the first board can be formally constituted.
>>>
>>
>> I'm definitely in support of something along these lines. My experience
>> entering NumPy development was that the development process, coding
>> standards, and other aspects of the process are not very well specified,
>> and people have many differing ideas about what has already been agreed
>> upon. I would recommend that fixing this state of affairs be placed high on
>> the agenda of the board, with the goal of making it easier to attract new
>> developers.
>>
>> A few people have proposed the BDFL approach, as in CPython development.
>> In practice, I believe Guido has done very well in the role because he only
>> uses the power as a last resort. Even if NumPy adopts a similar approach,
>> having a board along the lines Travis proposes would still be a good thing,
>> and having a BDFL would just mean that there's someone who could override
>> the will of the board and make an entirely different choice.
>>
>> It may be worth considering how the governance structure is related to
>> the different levels of the NumPy codebase. There is a (very) small group
>> of people who have contributed significant amounts of C code, a larger
>> group of people who have contributed significant amounts of Python code,
>> many people who have contributed small C and/or Python patches, and a large
>> number of people who contribute bug reports, email list comments, etc. It
>> may be worth designing the board taking into account these different groups
>> of developers and users.
>>
>> -Mark
>>
>>
>>>
>>> Best regards,
>>>
>>> -Travis
>>>
>>>
> Just some thoughts I have from this discussion.
>
> 1. I think that we need to encourage and entice more NumPy
> developers/contributors.  Having a board of only a few core developers puts
> us right back in the same boat we were in during the whole NA discussion,
> only more codified.  Increasing the size of the board with more core
> developers would diversify thought and counter-act "group-think".  I think
> that this problem needs to be solved before anything else.
>
>
Well, that's a tough one. Numpy development tends to attract folks with
spare time, i.e., students*, and those with an itch to scratch. Itched
scratched, degree obtained, they go back to their primary interest or on to
jobs and the rest of life. So developers come and go and a board needs to
be pretty flexible to reflect that. We can't wave around wads of cash or
stock options to attract new people. Mark does a good job of pointing out
some of the barriers to entry, and we could try to lower those. Indeed,
things are much better than they were but more can be done.

<snip>

Chuck

* I expect students think they are overworked, and sometimes they are, but
they also tend to be young and energetic with flexible schedules and few
outside commitments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20111205/8b5ac287/attachment.html>