[Numpy-discussion] Governance model request

[Travis Oliphant]

On Tue, Sep 22, 2015 at 4:33 AM, Nathaniel Smith <njs at pobox.com> wrote:

> On Tue, Sep 22, 2015 at 1:24 AM, Travis Oliphant <travis at continuum.io>
> wrote:
>
>> I actually do agree with your view of the steering council as being
>> usually not really being needed.    You are creating a straw-man by
>> indicating otherwise.    I don't believe a small council should do anything
>> *except* resolve disputes that cannot be resolved without one.  Like you, I
>> would expect that would almost never happen --- but I would argue that
>> extrapolating from Debian's experience is not actually relevant here.
>>
>
> To be clear, Debian was only one example -- what I'm extrapolating from is
> every community-driven F/OSS project that I'm aware of.
>
> It's entirely possible my data set is incomplete -- if you have some other
> examples that you think would be better to extrapolate from, then I'd be
> genuinely glad to hear them. You may have noticed that I'm a bit of an
> enthusiast on this topic :-).
>
>

Yes, you are much better at that than I am.   I'm not even sure where I
would look for this kind of data.


>
>>
> So, if the steering council is not really needed then why have it at all?
>> Let's just eliminate the concept entirely.
>>
>>
> In my view, the reasons for having such a council are:
> 1) The framework is useful even if you never use it, because it means
> people can run "what if" scenarios in their mind and make decisions on that
> basis. In the US legal system, only a vanishingly small fraction of cases
> go to the Supreme Court -- but the rules governing the Supreme Court have a
> huge effect on all cases, because people can reason about what would happen
> *if* they tried to appeal to the Supreme Court.
>

O.K.  That is a good point.   I can see the value in that.



> 2) It provides a formal structure for interfacing with the outside world.
> E.g., one can't do anything with money or corporate contributions without
> having some kind of written-down and enforceable rules for making decisions
> (even if in practice you always stick to the "everyone is equal and we
> govern by consensus" part of the rules).
>

O.K.


> 3) There are rare but important cases where discussions have to be had in
> private. The main one is "personnel decisions" like inviting people to join
> the council; another example Fernando has mentioned to me is that when they
> need to coordinate a press release between the project and a funding body,
> the steering council reviews the press release before it goes public.
>

O.K.



> That's pretty much it, IMO.
>
> The framework we all worked out at the dev meeting in Austin seems to
> handle these cases well AFAICT.
>

How did we "all" work it out when not everyone was there?   This is where I
get lost.   You talk about community decision making and yet any actual
decision is always a subset of the community.    I suppose you just rely on
the "if nobody complains than it's o.k." rule?   That really only works if
the project is moving slowly.


> But there are real questions that have to have an answer or an approach to
>> making a decision.  The answer to these questions cannot really be a vague
>> notion of "lack of vigorous opposition by people who read the mailing list"
>> which then gets parried about as "the community decided this."   The NumPy
>> user base is far, far larger than the number of people that read this list.
>>
>
> According to the dev meeting rules, no particularly "vigorous opposition"
> is required -- anyone who notices that something bad is happening can write
> a single email and stop an idea dead in its tracks, with only the steering
> council able to overrule. We expect this will rarely if ever happen,
> because the threat will be enough to keep everyone honest and listening,
> but about the only way we could possibly be *more* democratic is if we
> started phoning up random users at home to ask their opinion.
>

O.K.  so how long is the time allowed for this kind of opposition to be
noted?



>
> This is actually explicitly designed to prevent the situation where
> whoever talks the loudest and longest wins, and to put those with more and
> less time available on an equal footing.
>
>
>> For better or for worse, we will always be subject to the "tyranny of who
>> has time to contribute lately".    Fundamentally, I would argue that this
>> kind of "tyranny" should at least be tempered by additional considerations
>> from long-time contributors who may also be acting more indirectly than is
>> measured by a simple git log.
>>
>
> I guess I am missing something fundamental here. Who are these long-time
> contributors who will sit on your council of 1/3/5 but who don't even read
> the mailing list? How will they know when their special insight is
> necessary?
>

The long-time contributors wouldn't necessarily sit on that council.   But,
 I would support the idea of an advisory council that could act if it saw
things going the wrong direction.  This is where those people would sit.

In the case of a 1 / 3 / 5 member council -- I would not argue to be on it
at all (but I would argue that some care should be taken to be sure it has
people with some years of experience if they are available).    I'm only
asking to be on a steering council that is larger than 5 people, and I
don't actually prefer that the steering council be larger than 5 people.


> No, absolutely not. The proposal is that these issues are decided by open
> discussion on the mailing list. (With the possible exception of #4 -- I
> suspect that given an extreme situation like this, then once all other
> efforts to mitigate the situation had failed the steering council would
> probably feel compelled to talk things over to double-check they had
> consensus before acting, and likely some part of this would have to be done
> in private.)
>

O.K.  Then, I am misunderstanding.


>
> This is pretty explicit in the document (and again, this is text and ideas
> stolen directly from Jupyter/IPython):
>
> "During the everyday project activities, council members participate in
> all discussions, code review and other project activities as peers with all
> other Contributors and the Community. In these everyday activities, Council
> Members do not have any special power or privilege through their membership
> on the Council. [...] the Council may, if necessary [do pretty much
> anything, but] the Council's primary responsibility is to facilitate the
> ordinary community-based decision making procedure described above. If we
> ever have to step in and formally override the community for the health of
> the Project, then we will do so, but we will consider reaching this point
> to indicate a failure in our leadership."
>

Granting commit rights to the repo does not seem to me to be an "everyday
project activity" --- so I suppose I was confused.     I suppose that could
happen with no serious objections on the list.   It seems that the people
who actually have the commit bit presently should be consulted more than
the general public, though.


> This is pretty much how we do things now, and it has worked pretty well so
> far -- people do get commit bits, releases get tagged, and everyone seems
> happy with this part. I'd actually like to see a more explicit set of rules
> around e.g. who gets commit bits, just to set expectations and provide a
> clearer onramp for new contributors, but that's something that we can
> easily discuss and make a decision on later.
>

O.K.   I think that the commit bit has not been that clear --- and was
closer when I was more active to the commiters rule I gave before.


>
> All of these questions are ones that are easy enough to solve given some
> framework for governance, but they do all require substantive discussion.
> We're not going to do them justice if we try to solve them off-the-cuff in
> this thread, and trying would just derail the underlying discussion about
> how we make decisions. So I think we should stay focused on that.
>
>
>>  Perhaps rather than a steering council, though, we just need clear
>> answers to questions like the above --- which might be handled differently
>> for different questions.    I don't think these questions have very easy
>> answers.
>>
>> Ultimately NumPy has relied on and continues to rely on the mutual
>> respect of all the people that have worked on the code and tried to make it
>> better.     We all have opinions about how things have gone in the past,
>> and what has gone well and what hasn't.   But, nothing you have said
>> persuades me that you have a full picture of past history with respect to a
>> lot of the difficult kinds of conversations that have happened and the
>> different modes of activity that have tried to help move NumPy along.    In
>> fact, I think you mis-understand and mis-interpret that history quite
>> often.
>>
>
> I'm honestly somewhat unclear on why having a "full picture of past
> history" is necessary to contribute effectively (surely if that were the
> case, then only Jim Hugunin could comment?), but if there are things I'm
> missing then I'd certainly like to know. You've made comments along these
> lines several times now, but unfortunately I can't do much to improve my
> understanding without more concrete examples.
>

The reason is that you in particular make very long arguments that try to
persuade on the basis of your understanding of how things were done in the
past (both here and in other projects).   If you don't understand the
history and the arguments that have been had before, you are throwing away
information.   It's not a show-stopper, for sure, but it does potentially
make it less likely that a better solution will be found.

I will have to respond to your incorrect characterizations in another
thread.

-Travis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150922/796176eb/attachment.html>