[Numpy-discussion] Numpy governance update

[Matthew Brett]

Hi,

On Thu, Feb 16, 2012 at 11:54 AM, Christopher Jordan-Squire
<cjordan1 at uw.edu> wrote:
> On Thu, Feb 16, 2012 at 11:03 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> Hi,
>>
>> On Thu, Feb 16, 2012 at 4:23 AM, Francesc Alted <francesc at continuum.io> wrote:
>>> On Feb 16, 2012, at 12:15 PM, Jason Grout wrote:
>>>
>>>> On 2/15/12 6:27 PM, Dag Sverre Seljebotn wrote:
>>>>> 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.)
>>>>
>>>> Interesting point.  I hope I'm not pitching a log onto the fire here,
>>>> but in numpy's case, there are very many capable developers on other
>>>> projects who depend on numpy who could credibly threaten a fork if they
>>>> felt numpy was drastically going wrong.
>>>
>>> Jason, that there capable developers out there that are able to fork NumPy (or any other project you can realize) is a given.  The point Dag was signaling is that this threaten is more probable to happen *inside* the community.
>>>
>>> And you pointed out an important aspect too by saying "if they felt numpy was drastically going wrong".  It makes me the impression that some people is very frightened about something really bad would happen, well before it happens.  While I agree that this is *possible*, I'd also advocate to give Travis the benefit of doubt.  I'm convinced he (and Continuum as a whole) is making things happen that will benefit the entire NumPy community; but in case something gets really wrong and catastrophic, it is always a relief to know that things can be reverted in the pure open source tradition (by either doing a fork, creating a new foundation, or even better, proposing a new way to do things).  What it does not sound reasonable to me is to allow fear to block Continuum efforts for making a better NumPy.  I think it is better to relax a bit, see how things are going, and then judge by looking at the *results*.
>>
>> I'm finding this conversation a bit frustrating.
>>
>> The question on the table as I understand it, is just the following:
>>
>> Is there any governance structure / procedure / set of guidelines that
>> would help ensure the long-term health of the numpy project?
>>
>> The subtext of your response is that you regard *any structure at all*
>> as damaging to the numpy effort and in particular, as damaging to the
>> efforts of Continuum.  It seems to me that is a very extreme point of
>> view, and I think, honestly, it is not tenable.
>>
>> But surely - surely - the best thing to do here is to formulate
>> something that might be acceptable, and for everyone to say what they
>> think the problems would be.  Do you agree?
>>
>
> Perhaps I'm mistaken, but I think the subtext has more been that
> worrying about potential problems--which aren't yet actual
> problems--isn't terribly productive. Particularly when the people
> involved are smart, invested in the success of the broader numpy
> package, and very deserving of the benefit of the doubt.

OK - that is one point of view.  I'll state the most extreme version thus:

"There is no possible benefit to thinking of a governance structure
before problems arise".

That seems to me to be untenable.  As others have pointed out, the
kind of problems that might arise are fairly obvious, these kinds of
things have been thought about before, and designing a solution to
these problems after they have arisen may be considerably harder than
doing it before.

Here's another version of the argument:

"It is not possible to imagine a governance structure that would be
better than the current one".

That does seem to me to be extreme, and untenable until various
schemes have been seriously considered.

A more reasonable version of the same argument might be:

"The costs of working on an a governance structure are greater than
the potential benefits".

Is that defensible?  I don't think so.  But if it is, what are the
costs, exactly?

> Also, as Ralf said, David made a concrete proposal. What are your
> comments on his proposal?

Right - and so did Alan Isaac some time ago, which I responded to, and
got no reply.

I think - as Benjamin has said previously, we first have to establish
that *any* governance structure is worth discussing.  Including the
current one.  I'm hearing a lot of "no" to that.

Do you think that any governance structure is worth discussing?

If so, which do you prefer?

For David's proposal - I think it is likely to be impractical because,
at the moment, almost all agreement is informal and sometimes
off-list.  Given that situation, it would take an enormous amount of
balls to reject a Continuum pull-request.   If Continuum started to
lose interest in that mechanism, if I was them, I'd make the pull
requests unmanageably large and therefore impossible to review.  It
would require one person to be the gatekeeper for the whole community,
putting enormous strain on that person.

Lastly, I'm not seeing much commitment to what George Dafermos calls
"unmediated participation of all community members".

"The desire to realise democracy is not futile. Rather, the problem is
that real democracy, that is, that mode of governance which is
characterised by the unmediated participation of all community members
in the process of formulating problems and negotiating decisions, is
unattainable once a group is split into a fraction that decides and
commands and another that obeys. Such structures make a travesty of
the notion of democracy"

http://shareable.net/blog/governance-of-open-source-george-dafermos-interview

It seems to me that it is that we need to strive for, and we need to
think how that would best come about.

With Nathaniel, I also think that will lead to the most harmonious,
enjoyable and productive relationship between Continuum and the rest
of the community.

Best,

Matthew