[Numpy-discussion] Comments on governance proposal (was: Notes from the numpy dev meeting at scipy 2015)

Fri Aug 28 20:09:37 EDT 2015

On Fri, Aug 28, 2015 at 3:36 PM, Jaime Fernández del Río <
jaime.frio at gmail.com> wrote:

> On Fri, Aug 28, 2015 at 2:40 AM, Sebastian Berg <
> sebastian at 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.frio at gmail.com> wrote:
>> > > On Thu, Aug 27, 2015 at 11:06 AM, Matthew Brett <
>> matthew.brett at gmail.com>
>> > > wrote:
>> > >>
>> > >> Hi,
>> > >>
>> > >> On Thu, Aug 27, 2015 at 6:23 PM,  <josef.pktd at gmail.com> wrote:
>> > >> >
>> > >> >
>> > >> > On Thu, Aug 27, 2015 at 12:22 PM, Matthew Brett
>> > >> > <matthew.brett at gmail.com>
>> > >> > wrote:
>> > >> >>
>> > >> >> Hi
>> > >> >>
>> > >> >> On Thu, Aug 27, 2015 at 5:11 PM,  <josef.pktd at gmail.com> wrote:
>> > >> >> >
>> > >> >> >
>> > >> >> > On Thu, Aug 27, 2015 at 11:04 AM, Matthew Brett
>> > >> >> > <matthew.brett at gmail.com>
>> > >> >> > wrote:
>> > >> >> >>
>> > >> >> >> Hi,
>> > >> >> >>
>> > >> >> >> On Thu, Aug 27, 2015 at 3:34 PM,  <josef.pktd at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150828/b19818e2/attachment.html>