[Numpy-discussion] NumPy Governance

[Benjamin Root]

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.

Travis, I am currently in the process of getting hired by a company that
has really embraced the Python/SciPy software stack, but unfortunately has
not fully embraced OSS community development.  I wonder if Enthought could
produce (or maybe already has) teaching material showing other companies
how to incorporate community development into their business models (in
particular development of the SciPy stack)?  Maybe we can get some more
commitments of resources from other companies?

2. Nothing against Travis, but I am somewhat wary of declaring Travis as a
BDFL while he is the head of Enthought.  I think Travis has done an
excellent job of respecting the hierarchy of development (where EPD is
downstream of the OSS SciPy stack).  Having Travis as BDFL might, IMHO,
create possible conflicts of interest in the future. Again, I am not saying
that Travis would act against the interest of the SciPy stack, but rather,
I would like to avoid putting Travis in a position where such decisions
could become tempting.

3. I definitely +1 the idea of including representatives of other projects
on the board.  Each project could have their own process for selecting a
member to represent them.

4. I agree with Charles that a separate list would probably be
detrimental.  I also agree with Bruce that since the move to github, we
have had things become fragmented, and I think that needs to be
re-unified.  matplotlib is experiencing the same problem, and I have to
wonder if some other groups have already come up with a solution to this.
Maybe make a psuedo github account with the mailing list address as its
email address?

Just my 2 cents for now.
Ben Root
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20111205/00da4a83/attachment.html>