Hi, On Fri, Aug 28, 2015 at 5:59 AM, Jaime Fernández del Río <jaime.frio@gmail.com> wrote:
On Thu, Aug 27, 2015 at 11:06 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Thu, Aug 27, 2015 at 6:23 PM, <josef.pktd@gmail.com> wrote:
On Thu, Aug 27, 2015 at 12:22 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi
On Thu, Aug 27, 2015 at 5:11 PM, <josef.pktd@gmail.com> wrote:
On Thu, Aug 27, 2015 at 11:04 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Thu, Aug 27, 2015 at 3:34 PM, <josef.pktd@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? 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. Cheers, Matthew