On 02/15/2012 05:02 PM, Matthew Brett wrote: > Hi, > > On Wed, Feb 15, 2012 at 4:27 PM, Dag Sverre Seljebotn > <d.s.seljeb...@astro.uio.no> wrote: >> On 02/15/2012 02:24 PM, Mark Wiebe wrote: >>> There certainly is governance now, it's just informal. It's a >>> combination of how the design discussions are carried out, how pull >>> requests occur, and who has commit rights. >> >> +1 >> >> If non-contributing users came along on the Cython list demanding that >> we set up a system to select non-developers along on a board that would >> have discussions in order to veto pull requests, I don't know whether >> we'd ignore it or ridicule it or try to show some patience, but we >> certainly wouldn't take it seriously. > > Ouch. Is that me, one of the non-contributing users? Was I > suggesting that we set up a system to select non-developers to a > board? I must say, now you mention it, I do feel a bit ridiculous.
In retrospect I was unfair and my email way too harsh. Anyway, I'm really happy with your follow-up in turning this into something more constructive. And I do appreciate that you brought the topic up in the first place. > >> It's obvious that one should try for consensus as long as possible, >> including listening to users. But in the very end, when agreement can't >> be reached by other means, the developers are the one making the calls. >> (This is simply a consequence that they are the only ones who can >> credibly threaten to fork the project.) > > I think the following are not in question: > > 1) Consensus is desirable > 2) Developers need to have the final say. > > But, I think it is clear in the both the ABI numpy 1.5.0 dispute, and > the mask / NA dispute, that we could have gone further in negotiating > to consensus. > > The question we're considering here is whether there is any way of > setting up a set of guidelines or procedures that would help us work > at and reach consensus. Or if we don't reach consensus, finding a way > to decide that is clear and fair. I don't think working on that seems > as silly and / or rude to me as it does to you. > >> Sure, structures that includes users in the process could be useful... >> but, if the devs are fine with the current situation (and I don't see >> Mark or Charles complaining), then I honestly think it is quite rude to >> not let the matter drop after the first ten posts or so. > > I have clearly overestimated my own importance and wisdom, and have > made myself appear foolish in the eyes of my peers. > >> Making things the way one wants it and scratching *ones own* itch is THE >> engine of open source development (whether one is putting in spare time >> or monetary funding). Trying to work against that with artificial >> structures doesn't sound wise for a project with as few devs as NumPy... > > You believe, I suppose, that there are no significant risks in nearly > all the numpy core development being done by a new company, or at > least, that there can little benefit to a governance discussion in > that situation. I think you are wrong, but of course it's a tenable > point of view, The question is more about what can possibly be done about it. To really shift power, my hunch is that the only practical way would be to, like Mark said, make sure there are very active non-Continuum-employed developers. But perhaps I'm wrong. Sometimes it is worth taking some risks because it means one can go forward faster. Possibly *a lot* faster, if one shifts things from email to personal communication. It is not like the current versions of NumPy disappear. If things do go wrong and NumPy is developed in some crazy direction, it's easy to go for the stagnated option simply by taking the current release and maintain bugfixes on it. Dag _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
