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 :-). > > 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. 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). 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. 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. > 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. 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? > 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. > 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.) 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." If this is unclear then suggestions for improvement would certainly be welcome. This is pretty much how we do things now, and it has worked pretty well so far -- people do get commit bits, releases get tagged, and everyone seems happy with this part. I'd actually like to see a more explicit set of rules around e.g. who gets commit bits, just to set expectations and provide a clearer onramp for new contributors, but that's something that we can easily discuss and make a decision on later. All of these questions are ones that are easy enough to solve given some framework for governance, but they do all require substantive discussion. We're not going to do them justice if we try to solve them off-the-cuff in this thread, and trying would just derail the underlying discussion about how we make decisions. So I think we should stay focused on that. > 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 honestly somewhat unclear on why having a "full picture of past history" is necessary to contribute effectively (surely if that were the case, then only Jim Hugunin could comment?), but if there are things I'm missing then I'd certainly like to know. You've made comments along these lines several times now, but unfortunately I can't do much to improve my understanding without more concrete examples. 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. > Thank you. I am also convinced that you're well-intentioned and doing the very best you can, and grateful that you are also passionate and eager about moving NumPy forward. -n -- Nathaniel J. Smith -- http://vorpus.org
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
