[Numpy-discussion] Numpy governance update

[Matthew Brett]

Hi,

On Wed, Feb 15, 2012 at 9:47 PM, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> On 02/15/2012 05:02 PM, Matthew Brett wrote:
>> Hi,
>>
>> On Wed, Feb 15, 2012 at 4:27 PM, Dag Sverre Seljebotn
>> <d.s.seljebotn at astro.uio.no>  wrote:
>>> On 02/15/2012 02:24 PM, Mark Wiebe wrote:
>>>> 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.
>>
>> Ouch.  Is that me, one of the non-contributing users?  Was I
>> suggesting that we set up a system to select non-developers to a
>> board?   I must say, now you mention it, I do feel a bit ridiculous.
>
> In retrospect I was unfair and my email way too harsh. Anyway, I'm
> really happy with your follow-up in turning this into something more
> constructive.

Don't worry - thanks for this reply.

>> You believe, I suppose, that there are no significant risks in nearly
>> all the numpy core development being done by a new company, or at
>> least, that there can little benefit to a governance discussion in
>> that situation.  I think you are wrong, but of course it's a tenable
>> point of view,
>
> The question is more about what can possibly be done about it. To really
> shift power, my hunch is that the only practical way would be to, like
> Mark said, make sure there are very active non-Continuum-employed
> developers. But perhaps I'm wrong.

It's not obvious to me that there isn't a set of guidelines,
procedures, structures that would help to keep things clear in this
situation.  Obviously it would be good to have more non-Continuum
developers, but also obviously, there is a risk that that won't
happen.

> Sometimes it is worth taking some risks because it means one can go
> forward faster. Possibly *a lot* faster, if one shifts things from email
> to personal communication.

Yes, obviously it's in no-one's interest to slow down the Continuum
developers.   I wonder though whether there is a way of organizing
things, that does not slow down the Continuum developers, but does
keep the sense of community involvement and ownership.

> It is not like the current versions of NumPy disappear. If things do go
> wrong and NumPy is developed in some crazy direction, it's easy to go
> for the stagnated option simply by taking the current release and
> maintain bugfixes on it.

But we all want to avoid a fork, which is what that could easily become.

See you,

Matthew