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

Fri Aug 28 17:36:28 EDT 2015

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!

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150828/f0d07206/attachment.html>