[SciPy-Dev] SciPy governance model

[josef.pktd at gmail.com]

On Fri, Jan 13, 2017 at 6:32 PM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Fri, Jan 13, 2017 at 3:24 PM, Evgeni Burovski
> <evgeny.burovskiy at gmail.com> wrote:
> > On Fri, Jan 13, 2017 at 8:22 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
> >> Hi,
> >>
> >> On Wed, Jan 11, 2017 at 1:13 AM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
> >>>
> >>>
> >>> On Tue, Sep 13, 2016 at 9:03 PM, Ralf Gommers <ralf.gommers at gmail.com>
> >>> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Sep 10, 2016 at 10:25 AM, Ralf Gommers <
> ralf.gommers at gmail.com>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Sep 7, 2016 at 1:37 AM, Eric Larson <larson.eric.d at gmail.com
> >
> >>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>> My feeling is that having a clear leader in place is important, so
> I'm
> >>>>>>> also leaning away from the numpy model towards one where
> >>>>>>> responsibilities are more explicitly assigned.  Exactly how to best
> >>>>>>> make
> >>>>>>> that assignment is still unclear to me.
> >>>>>>
> >>>>>>
> >>>>>> +1 for BD(FL) / leader-style from me, too. I like Matthew's
> suggestion
> >>>>>> of the top 5 active folks discuss to see which of them are actually
> >>>>>> interested in taking on that role.
> >>>>>
> >>>>>
> >>>>> Thanks for the feedback everyone. Looks like everyone likes this
> >>>>> suggestion so far, so we'll give that a try.
> >>>>
> >>>>
> >>>> Hi all, I'm happy to report that we've worked this out. Pauli was our
> >>>> preferred candidate, and he has agreed to take up the role of BDFL!
> >
> > <snip>
> >
> >> The main question I'd like to raise, is whether we really want a BDFL,
> >> as opposed to an elected projected leader.
> >>
> >> I think a BDFL makes sense where there's one person who started the
> >> project, wrote most of the code (at least at some point in the
> >> project's history), has been in charge since the beginning, and is
> >> still very active.   I think that does correspond to the situation for
> >> Linus  / Linux; Guido / Python; and Fernando / IPython.   I don't
> >> think we have anyone matching that description in Scipy.
> >>
> >> On the other hand, I do think it's important to have a project leader,
> >> with final authority on the direction of the project, and who takes
> >> responsibility for the health of the project.
> >>
> >> So, I propose, rather than have a BDFL, we have a system for choosing
> >> a leader,
> >
> > Which is exactly how it worked this time --- using the system of your
> > suggestion, https://mail.scipy.org/pipermail/scipy-dev/2016-
> September/021476.html
> >
> >
> >> say every 4 years, where we may or may not have limits on
> >> the number of consecutive terms.
> >
> > While I agree that this model is better in the vast majority of
> > situations, it feels to be a bit of over-engineering for scipy.
> >
> >> We can use that 4 year cycle to
> >> make sure we're reconsidering the direction of the project regularly,
> >> and thinking about where we could improve, and where we might be
> >> messing up.   It provides a natural way to give people a rest from the
> >> job, if they want one.   If one leader steps back, and sees another
> >> leader doing something better than they did, they can learn from that
> >> when they next have a leadership term.
> >
> > I agree it's worth it to periodically sit down and think about the
> > direction of the project.
> > I'm not sure though there is benefit in tying this up to a machinery
> > of fixed-time leadership terms, holding formal elections and so on.
> >
> >
> >> Of course that requires some formalization, but I think it's a
> >> considerably better system than the BDFL, for our case.
> >
> > It seems to me that the effort needed to formalize it is not worth the
> > benefit, specifically in our case.
>
> Well - as a broader community, I think we'll have to do this anyway.
> For example, I know that Stefan vdW wants to set up this model for
> scikit-image.   I am sure he'd be happy to help draft it, I know I
> would.  Maybe we could do that in relation to this PR, making sure
> that we set some reasonable time limit for getting it done, say 3
> weeks.
>

I like the stability and continuity that a known BDFL offers and signals,
and wouldn't want a formalized voting system where somebody might try to
game the system and get the majority of "electoral votes".
Either scheduled elections are redundant because of a consensus or they
create additional stress if you need to get x%.

Josef
"Make Scipy great again"




>
> Cheers,
>
> Matthew
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> https://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20170113/445eec66/attachment.html>