[Numpy-discussion] Governance model request

[Nathaniel Smith]

On Mon, Sep 21, 2015 at 9:20 AM, Travis Oliphant <travis at continuum.io> wrote:
>
> I wrote my recommendations quickly before heading on a plane.    I hope the spirit of them was caught correctly.    I also want to re-emphasize that I completely understand that the Steering Council is not to be making decisions that often and almost all activity will be similar to it is now --- discussion, debate, proposals, and pull-requests --- that is a good thing.
>
> However, there is a need for leadership to help unstick things and move the project forward from time to time because quite often doing *something* can be better than trying to please everyone with a voice.   My concerns about how to do this judgment have 2 major components:
>
> 1) The need for long-term consistency --- a one-year horizon on defining this group is too short in my mind for a decades-old project like NumPy.
> 2) The group that helps unstick things needs to be small (1, 3, or 5 at the most)

For reference, the rules for steering council membership were taken
directly from those used by the Jupyter project, and their steering
council currently has 10 people, making it larger than the "seed
council" proposed in the numpy document:
https://github.com/jupyter/governance/blob/master/people.md

> We could call this group the "adjudication group" rather than the "Steering Council" as well.   I could see that having a formal method of changing that "adjudication group" would be a good idea as well (and perhaps that formal vote could be made by a vote of a group of active contributors.   In that case, I would define active as having a time-window of 5 years instead of just 1).

I may be misreading things, but I'm getting the impression that the
active "adjudication group" you envision is radically different from
the "steering council" as envisioned by the current governance
document. It also, I think, radically different from anything I've
ever seen in a functioning community-run FOSS project and frankly it's
something where if I saw a project using this model, it would make me
extremely wary about contributing.

The key point that I think differs is that you envision that this
"adjudication group" will actually intervene into discussions and make
formal decisions in situations other than true irreconcilable crises,
which in my estimation happen approximately never. The only two kinds
of F/OSS projects that I can think of that run like this are (a)
projects that are not really community driven at all, but rather run
as internal company projects that happen to have a public repository,
(b) massive projects like Debian and Fedora that have to manage
literally thousands of contributors, and thus have especially robust
backstop procedures to handle the rare truly irreconcilable situation.

E.g., the Debian CTTE acts as an "adjudication group" in the way it
sounds like you envision it: on a regular basis, irreconcilable
arguments in Debian get taken to them to decide, and they issue a
ruling. By some back of the envelope calculations, it looks like they
issue approximately ~0.002 rulings per debian-contributor-year [1][2].
If we assume crudely that irreconcilable differences scale linearly
with the size of a project, this suggests that a ~20 person project
like NumPy should require a ruling ~once every 20 years.

Or quoting myself from the last thread about this [3]:
] Or on the other end of things, you have e.g. Subversion, which had an
] elaborate defined governance system with different levels of
] "core-ness", a voting system, etc. -- and they were 6 years into the
] project before they had their first vote. (The vote was on the crucial
] technical decision of whether to write function calls like "f ()" or
] "f()".)

These are two real projects and how they really work. And even in
projects that do have a BDFL, the successful ones almost never use
this power to actually "unstick things" (i.e., use their formal power
to resolve a discussion). Consider PEP 484, Guido's somewhat
controversial type hints proposal: rather than use his power to move
the debate along, he explicitly delegated his power to one of the
idea's strongest critics [4].

Of course, things to get stuck. But the only time that getting them
unstuck needs or even benefits from the existence of a formal
"unsticking things" group is if the group is actually using some
powers that they have. In 99.9% of cases, though, the correct way to
get things unstuck is for a new idea to be introduced, or for someone
respected to act as a mediator, or for someone to summarize the
situation and isolate some core of agreement that allows for forward
progress. But all of *these* things can and should be done by anyone
and everyone who can contribute them -- restricting them to a small
"adjudication group" makes no sense.

In terms of real-world examples: From my point of view, the worst
parts of the NA fiasco was caused by the decision to cut off debate
with a "ruling". (Specifically, that instead of working on
implementing bitpattern-NAs -- which did have consensus -- then Mark
would go off and work on the masked-NA strategy, and eventually that
it should be merged, despite it not having consensus. I note that dynd
supports only bitpattern-NAs.)

OTOH, probably the most difficult technical debate we've had recently
is issue 5844, about the potential interactions between __binop__
methods and __numpy_ufunc__, and this is a debate that AFAICT
certainly would not have benefited from the existence of an
adjudication body. As it happens, all three of your proposed
adjudication-body-members actually are in the debate anyway; if they
hadn't been, then the very last thing that debate needs is someone
wading in without any understanding of the complex technical issues
and trying to force some resolution.

I'm not saying that truly irreconcilable problems never arise. But
given that they're so rare, and that realistically any system that
could solve them would need to be backed by basically the same group
of people that are in the current governance document's "steering
council" (because in an OSS project it's the people doing the work
that ultimately have the power), there's no point in building an
elaborate voting system and method for defining the electorate just to
handle these cases -- and quite a bit of harm. So the proposed system
is basically the simplest one that could work. (I described this line
of reasoning in more detail in [3].)

I think it would really help if you could provide some examples of
successful community-driven projects and/or specific debates that
benefited from having an adjudication body like you envision?

I also suspect this fundamental difference in how we view the role of
a governance body explains why I am unbothered by the idea of steering
council membership "timing out" after 2 years of inactivity. The
steering council's job is to informally manage things day to day, and
in extreme cases to make judgement calls. These two things both
crucially require a broad and up-to-date understanding of the issues
facing the project, ongoing debates, personalities, etc. But the
council is never intended to make any judgement call on its own; the
whole idea of the structure is to make sure that decisions are based
on as broad a scope of expertise as possible. In particular we
regularly get historical insight from Chuck, Ralf, Pauli, Robert Kern,
David Cournapeau, Pearu Peterson, Anne Archibald, Matthew Brett,
Stefan van der Walt...
and it doesn't matter at all whether they're on the council or not.
(If it did matter, that would be terrible, right? Why would you want
to *not* listen to any of those people?) If you plan to become more
active and give your perspective on things more then that's awesome
and welcome, but AFAICT this particular point is pretty orthogonal to
the composition of the steering council.

See also this comment from Fernando about the Jupyter steering
council, which happened by chance to cross my email this morning:
    https://github.com/jupyter/governance/pull/6#issuecomment-142036050

-n

[1] https://www.debian.org/devel/tech-ctte#status
[2] https://contributors.debian.org/
[3] https://mail.scipy.org/pipermail/numpy-discussion/2015-September/073537.html
[4] See e.g. the bottom of this message from Nick Coghlan, where he
talks about how PEP "pronouncements" are done -- emphasizing in
particular (my paraphrase) that the point of a BDFL/BDFL-delegate is
not to resolve any substantive issues, and that a common strategy is
to choose the person who's most skeptical of the idea to be the
BDFL-delegate:
  http://thread.gmane.org/gmane.comp.python.distutils.devel/23867

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