Hi Nathaniel, Thanks for the clarifications. Is the governance document committed to the repository? I keep looking for it and have a hard time finding it --- I think I read it last in an email.
In this way, I could make Pull Requests to the governance document if there are concrete suggestions for change, and then have them reviewed in the standard way. I'm hopeful that a few tweaks to the document would satisfy all my concerns. Thanks, -Travis On Wed, Sep 23, 2015 at 1:04 PM, Nathaniel Smith <n...@pobox.com> wrote: > Hi Travis, > > On Tue, Sep 22, 2015 at 3:08 AM, Travis Oliphant <tra...@continuum.io> > wrote: > > > > > > On Tue, Sep 22, 2015 at 4:33 AM, Nathaniel Smith <n...@pobox.com> wrote: > >> > >> On Tue, Sep 22, 2015 at 1:24 AM, Travis Oliphant <tra...@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 > _______________________________________________ > 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
