+10  Very well written down ideas Jaime.

2015-08-28 6:59 GMT+02:00 Jaime Fernández del Río <jaime.frio@gmail.com>:
On Thu, Aug 27, 2015 at 11:06 AM, Matthew Brett <matthew.brett@gmail.com> wrote:

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?
Are you trying to prove the point that consensus doesn't work by making it impossible to reach a consensus on this? ;-)

One thing we are doing very badly is leveraging resources outside of contributions of work and time from individuals.  Getting sponsors to finance work on what is the cornerstone of just about any Python package that has to add two numbers together shouldn't be too hard, especially seeing success stories like Jupyter's, who I believe has several paid developers working full time.  That requires formalizing governance, because apparently sponsors are a little wary of giving money to "people on the internet". ;-)  Fernando Pérez was extremely emphatic about the size of the opportunity NumPy was letting slip by not formalizing *any* governance model.  And it is a necessary first step so that e.g. we have the money to, say a year from now, get the right people together for a couple of days to figure out a better governance model.  I'd argue that money would be better spent financing a talented developer to advance e.g. Nathaniel's new dtype system to end all dtype systems, but that's a different story.

Largely because of the above, even if Nathaniel's document involved tossing a coin to resolve disputes, I'd rather have that now than something much better never. Because there really is no alternative to Nathaniel's write-up of the status quo, other than the status quo without a write-up: it has taken him two months to put this draft together, **after** we agreed over several hours of face to face discussion on what the model should be.  And I'm sure he has hated every minute he has had to put into it.  So if we keep going around this in circles, after a few days we will all grow tired and go back to fighting over whether indexing should transpose subspaces or not, and all that other cool stuff we really enjoy. And a year from now we will be in the same place we are now, only a year older and deeper in (technical) debt.


( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

NumPy-Discussion mailing list

Francesc Alted