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