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.
So, if the steering council is not really needed then why have it at all?
Let's just eliminate the concept entirely.
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.
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.
So, what are the questions that have to have an answer that even calls for
some kind of governance? I know Nathaniel's document listed some of them
(and perhaps all of them). Here are mine:
1) who gets commit rights to the repo (and who has them removed)?
2) who tags the release of NumPy?
3) how is it decided where money is spent if it's donated to the project
(and not just to people directly)?
4) how is it decided if someone needs to be removed from participation in
the group because they are not adding to the conversation (we have been
fortunate that this hasn't happened in NumPy before --- but it could)?
5) how is it decided what goes on the NumPy website --- i.e. will
advertisers be able to put their logos or book-covers there?
If I understand what you are proposing, then basically the "steering
council" decides these things. 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 convinced you are well-intentioned and doing the very best you can, and
I'm very grateful that you are passionate and eager about moving NumPy
forward. Ultimately I hope it will help things.
Here is my attempt at a proposal for how to answer the above questions:
1) who gets commit rights to the repo (and who has them removed)?
* people who contribute regularly are granted commit rights by another
committer with at least two additional nominations and the lack of a veto
within 1 week of the proposal.
* nobody has commit rights removed except by unanimous consent of all the
other committers (with consent being implied if not responded to within 2
weeks).
2) who tags the release of NumPy?
* whomever volunteers to be release manager and if there is no veto from
committers.
3) how is it decided where money is spent if it's donated to the project
(and not just to people directly)?
* three people who self-select represent NumPy to Numfocus following the
rules of Numfocus (that there is only one representative from any
organization).
* If 3 committers oppose one of those people and nominate another in
place, then that person is replaced.
4) how is it decided if someone needs to be removed from participation in
the group because they are not adding to the conversation (we have been
fortunate that this hasn't happened in NumPy before --- but it could)?
* unanimous consent of all committers (with a 2 week period given for
consent to be given --- and it is assumed given if they are not heard
from).
5) how is it decided what goes on the NumPy website --- i.e. will
advertisers be able to put their logos or book-covers there?
* only Numfocus can advertise and put their logo on the website
Now, I'm sure one can poke holes in the above --- and I would welcome
better answers to the above questions. Perhaps we should just decide how
specific decisions get made and make a document that lists that and only
talks about committers instead of inventing another "bit" to differentiate
people in the community.
-Travis
On Tue, Sep 22, 2015 at 2:11 AM, Nathaniel Smith <n...@pobox.com> wrote:
> On Mon, Sep 21, 2015 at 9:20 AM, Travis Oliphant <tra...@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
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
--
*Travis Oliphant*
*Co-founder and CEO*
@teoliphant
512-222-5440
http://www.continuum.io
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
