[Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

[Nathaniel Smith]

Hi Travis,

On Tue, Sep 22, 2015 at 3:08 AM, Travis Oliphant <travis at continuum.io> wrote:
>
>
> 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.

By "all" I just meant "all of us who were there" (which was a majority
of the active maintainers + a number of other interested parties --
the list of attendees is in the meeting notes if you're curious).

In general I totally agree with your concern about only including a
subset of the community. That's why we followed up by posting to the
list a full set of notes on tentative-decisions-made, and the draft
governance document in particular, for further discussion. We've
already had multiple threads talking about it, even before this one.
And it's pretty explicit in the document itself that no non-trivial
decision can be considered final unless it's *at least* been posted on
the mailing list.

We didn't try to legislate the exact review requirements for every
decision, because it's impossible to have a set of rules that scales
from trivial typos (which just get merged, only github subscribers
even know it happened) to foundational discussions like this one. This
means that one of the things we trust contributors (esp. senior
contributors) to do is to use their knowledge of the project to make
judgement calls about how risky or controversial a given change will
be, or if there's some particular expertise that should be consulted.
(E.g. we might make sure to ping Robert Kern if there's some np.random
change being discussed; I'm hesitant to finalize the PyUFunc ABI
changes being discussed in the other thread until Ralf gets back,
because I know that among the core maintainers he's particularly
critical of the idea of breaking ABI.)

And if we new information later comes to light then a decision can
always be revisited -- people may get grumpy if you try to re-open an
issue that's been considered settled for a year, but if you have a
good reason and nothing irrevocable has happened (e.g. a veto
obviously can't remove code from an existing release), then, well,
it's annoying but what can you do, let's hear your reason.

It's could certainly happen that sometimes the steering council +
mailing list readers will all miss something important. But this is
unavoidable in any system -- we're obviously not going to, like,
institute a one month waiting period on every single decision or
something. Ultimately you have to trust the core maintainers to have
good judgement about which changes to accept, together with good
meta-judgement about how controversial or broad-reaching any given
change is likely to be, and then hope that the rest of the community
will also supplement as they can.

>>> 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?

See above. For regular discussions, there are some rough guidelines
(uncontroversial bug fixes can just be merged; substantive API changes
need at least a few days review on the mailing list). This governance
discussion has been left open for a few weeks, and: "worst case, if a
change is more controversial than expected, or a crucial critique is
delayed because someone was on vacation, then it's no big deal: we
apologize for misjudging the situation, [back up, and sort things
out](http://producingoss.com/en/producingoss.html#version-control-relaxation)."

(I think we all thought the governance discussion was done, actually.
But then you posted, and so now we're talking about it some more. No
worries; if there's an issue, we'd rather know, right?)

For formal council votes (the ones we expect will rarely if every
happen), then we do have a slightly more formal rule: that the vote
"should be held open for long enough to give all interested Council
Members a chance to respond -- at least one week." The words "at
least" are in there to emphasize that the goal is to get an honest
read of the council; e.g. it's not legitimate to play games by
scheduling a vote when you know someone is on vacation.

>>
>> 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 draft governance document, anyone who cares enough to pay
attention effectively has a seat on this advisory council. I assume
this is a superset of the people that you would nominate?

> 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.

Oh good, I'm glad when things turn out to be misunderstandings,
because those are (relatively) easy to solve :-).

>>
>> 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.

I see, right, slight miscommunication here -- I was thinking about the
decision of "what process do we [in general] use to decide who gets a
commit bit", not the decision "should [this person] get a commit bit".
Currently, yeah, the general process is that commit bits get given out
by a somewhat informal private discussion among active committers (or,
presumably, the "the steering council" if it does get formalized). But
if someone wants to suggest that we switch to some other process
instead, or formalize the current process, then anything like that
would be proposed and debated on the mailing list.

(One of my favorite wacky policies is that there are projects like
Rubinius which automatically grant commit bits to everyone who submits
a successful patch. I guess the theory is that worst case, they go and
merge something they shouldn't have, more senior folks see it going by
and they revert it again, no biggie! Usually the problem is just the
opposite -- there are never enough reviewers. But I have not quite had
the guts to seriously propose this for numpy ;-).)

-n

-- 
Nathaniel J. Smith -- http://vorpus.org