On Fri, Aug 28, 2015 at 1:46 AM, Matthew Brett <matthew.br...@gmail.com> wrote: > Hi, > > On Fri, Aug 28, 2015 at 5:59 AM, Jaime Fernández del Río > <jaime.f...@gmail.com> wrote: [...] >> <joke> >> Are you trying to prove the point that consensus doesn't work by making it >> impossible to reach a consensus on this? ;-) >> </joke> > > Forgive me if I use this joke to see if I can get us any further. > > If this was code, I think this joke would not be funny, because we > wouldn't expect to reach consensus without considering all the > options, and discussing their pros and cons. > > Why would that not be useful in the case of forms of governance? > > One reason might be that the specific form of governance can have no > influence on the long-term health of the project. > > I am convinced that that is wrong - that the form of governance has a > large influence on the long-term health of a project. > > If there is some possibility that this is true, then it seems to me > that we would be foolish not to try and come to some reasoned choice > about the form of governance.
That seems fair, and I also think that even if we end up not changing anything then there's still some utility in having the discussion. Certainly one of my secret fears in writing all this up is that it would end up being just some words that only I cared about and everyone else ignored, so seeing other people engaging with it is heartening :-). I'm not feeling inspired this Friday evening to write a full white paper reviewing the universe of possible governance, but I'll summarize a bit what the reasoning was that led us to what we ended up with (at least as I remember it and from my perspective). Some of the sources that were mentioned for reference and positive or negative inspiration include Karl Fogel's chapter on governance, the Debian constitution, the gcc/egcs fork+reverse-fork, glibc/eglibc ditto, subversion, Jupyter/ipython, the Linux kernel, python, matplotlib, the Apache foundation's processes, the gnome foundation, nodejs, ... I'm certainly forgetting some. The basic observation that we started from was that all the successful projects seemed to fit a similar template: (1) basically all actual decision making is done by informal and maximally inclusive consensus-based processes, (2) there are some sort of more formal "backstop" rules that are called into play if informal processes break down (which hopefully never even happens). These projects don't tend to look that similar on paper, because people tend to only write down the "backstop" rules, and those vary a lot. So e.g., for some projects like Python or IPython, the formal rule is "the BDFL decides". But then if you look at what successful BDFLs do with this power, they mostly enforce rule #1 above. (Karl discusses this: http://producingoss.com/en/producingoss.html#benevolent-dictator). E.g., if you watch Guido, I don't think I've ever seen him say "I know people don't like X but we're doing it anyway". He mostly sits back to watch the debate, steps in occasionally to prune off unproductive lines of conversation (e.g. in the PEP 465 debate where he watched for a while, stepped in to tell people to knock it off with the pointless bikeshedding about which character to use, and then went back to watching) or encourage people to keep thinking about something, is always very careful not to actually make any strong statements, etc. Or, e.g., the bit in the draft governance about how the steering committee's secondary job is to make decisions, and their primary job is to prevent things reaching the point where they have to? That's a straight paraphrase of Fernando talking about his BDFL philosophy. 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()".) Or e.g. the massive and famously fractious Debian has their CTTE, which theoretically is the final arbiter of technical decisions in Debian and has immense powers... but they issue like ~5 rulings a year on average, and have gone years without issuing a ruling at all. So, our thought process was: for our purposes, since we don't have a BDFL, we can't depend on them to be the unwritten mechanism for enforcing rule #1, so first we should write down rule #1. And then we should attach some kind of workable backstop procedure. "Consensus among a core group" seemed like a good bet. It does mean you need to have a formal rule for defining who is in the "core group", because the point of having a formal backstop rule is that it be... formal... but otherwise it's about as simple as you can get: it requires minimal voting logistics (it's trivial to tell whether you have consensus, because if someone disagrees, there's your answer), it's minimally gameable (no temptation to form factions), and because in practice doing anything more complicated than consensus would first require consensus to agree on the more complicated system, so it's a safe procedure to agree on now and try to improve later if we have problems. But we don't really expect to have problems, since our goal is to never even use this system, so spending lots of effort imagining hypothetical scenarios didn't seem like a great use of time. And then we took the Jupyter/IPython governance document, ripped out the BDFL-dependent parts, replaced them with the two ideas above, and called it a day. This is an interesting article I came across today, about how "merely" documenting the status quo provides non-trivial benefits: https://kateheddleston.com/blog/the-null-process (Not that I would necessarily say that the draft I sent is just formalizing the status quo -- IMO the biggest problem with the status quo is that no-one is quite sure what it even is! Which leads to things like that time people panicked because I said we should consider all our options before making a decision [1], or the frustrating and unproductive tendency of contentious technical debates to switch over into becoming ad-hoc one-off debates about decision making processes...) -n [1] http://mail.scipy.org/pipermail/numpy-discussion/2015-April/072629.html -- Nathaniel J. Smith -- http://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
