On Fri, Aug 28, 2015 at 3:36 PM, Jaime Fernández del Río < jaime.f...@gmail.com> wrote:
> On Fri, Aug 28, 2015 at 2:40 AM, Sebastian Berg < > sebast...@sipsolutions.net> wrote: > >> On Fr, 2015-08-28 at 09:46 +0100, Matthew Brett wrote: >> > Hi, >> > >> > On Fri, Aug 28, 2015 at 5:59 AM, Jaime Fernández del Río >> > <jaime.f...@gmail.com> wrote: >> > > On Thu, Aug 27, 2015 at 11:06 AM, Matthew Brett < >> matthew.br...@gmail.com> >> > > wrote: >> > >> >> > >> Hi, >> > >> >> > >> On Thu, Aug 27, 2015 at 6:23 PM, <josef.p...@gmail.com> wrote: >> > >> > >> > >> > >> > >> > On Thu, Aug 27, 2015 at 12:22 PM, Matthew Brett >> > >> > <matthew.br...@gmail.com> >> > >> > wrote: >> > >> >> >> > >> >> Hi >> > >> >> >> > >> >> On Thu, Aug 27, 2015 at 5:11 PM, <josef.p...@gmail.com> wrote: >> > >> >> > >> > >> >> > >> > >> >> > On Thu, Aug 27, 2015 at 11:04 AM, Matthew Brett >> > >> >> > <matthew.br...@gmail.com> >> > >> >> > wrote: >> > >> >> >> >> > >> >> >> Hi, >> > >> >> >> >> > >> >> >> On Thu, Aug 27, 2015 at 3:34 PM, <josef.p...@gmail.com> >> wrote: >> > >> >> >> [snip] >> > >> >> >> > I don't really see a problem with "codifying" the status quo. >> > >> >> >> >> > >> >> >> That's an excellent point. If we believe that the current >> > >> >> >> situation >> > >> >> >> is the best possible, both now and in the future, then >> codifying the >> > >> >> >> status quo is an excellent idea. >> > >> >> >> >> > >> >> >> So, we should probably first start by asking ourselves: >> > >> >> >> >> > >> >> >> * what numpy is doing well; >> > >> >> >> * what numpy could do better; >> > >> >> >> >> > >> >> >> and then ask, is there some way we could make it more likely >> we will >> > >> >> >> improve over time. >> > >> >> >> >> > >> >> >> [snip] >> > >> >> >> >> > >> >> >> > As the current debate shows it's possible to have a public >> > >> >> >> > discussion >> > >> >> >> > about >> > >> >> >> > the direction of the project without having to delegate >> providing >> > >> >> >> > a >> > >> >> >> > vision >> > >> >> >> > to a president. >> > >> >> >> >> > >> >> >> The idea of a president that I had in mind, was not someone who >> > >> >> >> makes >> > >> >> >> all decisions, but the person who holds themselves responsible >> for >> > >> >> >> the >> > >> >> >> performance of the project. If the project has a coherent >> vision >> > >> >> >> already, the president has no need to provide one, but it's the >> > >> >> >> president's job to worry about whether we have vision or not, >> and do >> > >> >> >> what they need to, to make sure we don't lose track of that. >> If >> > >> >> >> you >> > >> >> >> don't know it already, I highly recommend Jim Collins' work on >> > >> >> >> 'level >> > >> >> >> 5 leadership' [1] >> > >> >> > >> > >> >> > >> > >> >> > Still doesn't sound like the need for a president to me >> > >> >> > >> > >> >> > " the person who holds themselves responsible for the >> > >> >> > performance of the project" >> > >> >> > >> > >> >> > sounds more like the role of the "core" group (adding plural to >> > >> >> > persons) >> > >> >> > to >> > >> >> > me, and cannot be pushed of to an official president. >> > >> >> >> > >> >> Except that, in the past, having multiple people taking decisions >> has >> > >> >> led to the situation where no-one feels themselves accountable >> for the >> > >> >> result, hence this situation tends to lead to stagnation. >> > >> > >> > >> > >> > >> > Is there any evidence for this? >> > >> >> > >> Oh - dear - that's the key point, but I'm obviously not making it >> > >> clearly enough. Yes there is, and that was the evidence I was >> > >> pointing to before. >> > >> >> > >> But anyway - Sebastian is right - this discussion isn't going >> anywhere >> > >> useful. >> > >> >> > >> So - let's step back. >> > >> >> > >> In thinking about governance, we first need to ask what we want to >> > >> achieve. This includes considering the risks ahead for the project. >> > >> >> > >> So, in the spirit of fruitful discussion, can I ask what y'all >> > >> consider to be the current problems with working on numpy (other than >> > >> the technical ones). What is numpy doing well, and what is it doing >> > >> badly? What risks do we have to plan for in the future? >> > > >> > > <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? >> > >> >> Oh, it is true. I think we (those in the room in Austin) just have >> thought about it a bit already, so now we have to be a bit patient with >> everyone who just saw the plans the first time. But I hope we can agree >> that we should decide on some form of governance in the next few weeks, >> even if it may not be perfect. >> >> My personal problem with your ideas is not that I do not care for the >> warnings, but having already spend some time trying to put together this >> (and this is nothing weird, this is very common practice in open >> source), I personally do not want to spend time inventing something >> completely new. >> >> We must discuss improvements to the document, and even whole different >> approaches. But for me at least, I need something a little more >> specific. Maybe I am daft, but I hear "this is a bad idea" without also >> providing another approach (that seems doable). >> And I do not buy that it is *that* bad, it is a very common governance >> structure for open source. The presidency suggestions may be another >> approach and certainly something we can pick up ideas from, but to me it >> is so vague that I cannot even start comprehending what it would mean >> for the actual governance structure specifically for numpy (considering >> the size of the project, etc.). >> >> But by all means, I like proposals/learning from your ideas (i.e. maybe >> you can propose changes to the NEP sections), I personally would just >> like to see a bit more clearly where it goes. >> > > Perhaps we could add a paragraph to the document, stating that we > understand the risks and will keep an eye open for the dilution of > responsibility and lack of direction and ownership that may come from > consensus based decision making. And make it part of our governance model > that we will review the model yearly, to identify and correct issues. That > wouldn't require any substantial change right now, but wouldn't crystallize > a potentially harmful organization either. > > Jaime > > P.S. At some point during the discussion in Austin, the idea going around > was that the NUMFocus committee, which at the time was going to have three > members only, would also be vested with ultimate decision power. Just > imagine, we could have had a proper triumvirate: Chuck, Nathaniel and Ralf, > wearing togas and feasting around a triclinium while they decided the fate > of NumPy! > The idea is appealing, but I don't think anyone should have to see me in a toga. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
