[SciPy-Dev] SciPy governance model

[josef.pktd at gmail.com]

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

> Hi,
>
> On Fri, Jan 13, 2017 at 4:15 PM, Nathaniel Smith <njs at pobox.com> wrote:
> > On Fri, Jan 13, 2017 at 3: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:
> > [...]
> >>>> 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.
> >
> > It's still the case that this is a novel social organization you
> > invented that AFAICT has never been tested by any F/OSS project, and
> > directly goes against the F/OSS community's hard-won cultural
> > knowledge about what kinds of organizations work well (see e.g. [1]).
> > Now- these are not necessarily bad things! Our community is
> > legitimately different than a "traditional" group of F/OSS developers
> > in a variety of ways, and less encultured to the "traditional" way of
> > doing things. And social experimentation is great -- how else can we
> > find better ways to live? While there's a lot of wisdom and experience
> > in Karl Fogel's book, it's surely not the final word.
> >
> > But... we should also be realistic that when someone shows up saying
> > "hey I've worked out a better method of social organization based on
> > first principles and thinking really hard, it'll 100% definitely be
> > awesome", then historically it *usually* doesn't quite work out so
> > nicely as promised. And it's often difficult to effectively do this
> > kind of experimentation at the same time as doing the actual work of
> > like, developing software. "Choose boring technology" [2] applies to
> > social technology too.
>
> * I agree with boring technology, but I doubt you're really arguing
> that choosing a leader at regular intervals is novel in open source or
> elsewhere.  Debian is an obvious example [1];
> * I don't know if an 'election' is the right method of choosing
> someone, that's really up for debate.  Obviously an election is a very
> standard way of doing that;
> * I don't personally know of a BDFL system working well in the absence
> of the criteria I put above, but it would certainly be useful to have
> a look at a few examples.  Can you suggest a few to consider?
>
> > If scikit-image is set on doing this, maybe the pragmatic thing to do
> > is wait and see how it works out for them? I've seen zero appetite
> > from anyone else on this list for elections and such.
>
> I think your idea here is the BDFL is low risk and choosing a leader
> is high risk, but it seems to me that both have risks, and that the
> best way of assessing the relative risks is to consider and refine a
> couple of concrete proposals, with discussion of prior experience,
> where applicable.
>
> For the appetite thing, you are probably referring to the nervous
> atmosphere that surrounds any discussion of governance, which is
> presumably due to the strong reactions against any such discussion in
> the past.   I'm sure you'd agree that that 'get it over with as
> quickly as possible' is not the best way to come to a good solution.
> Having said that, if Ralf and / or Pauli do not have much interest in
> this topic, discussion will quickly become futile and
> counterproductive, and we will have to stop quickly to avoid making a
> mess.
>
> Cheers,
>
> Matthew
>
> [1] https://www.debian.org/devel/leader


One big difference between Debian and scipy is the scale. There are 21
members on the scipy steering council and just a few of them that cover a
larger part of scipy. The BDFL is a combination of technical council and a
bit of a president/Project Leader (internal and external representation) in
Debian terms, AFAIU.

aside: It looks like the Steering Council is also the constitutional
assembly that could switch from Benevolent Dictatorship to Democracy.
"Update policy documents such as this one."

At least this induced me to really read Ralf's PR, instead of just
superficially skimming it.

Overall, and given the composition and recruiting of scipy contributors and
maintainers, I don't see much difference if the technical council is a BDFL
or a BDF5YR  (5 year renewable).

Does Pauli feel forced to stick with scipy because he is BDFL?
Does Evgeni (for example) put in more work than he already does because he
wants to be elected the next BDF5YR?
Do we get 25 new institutional contributors and council members so they can
take over the BDF5YR role?

or Does live go on as usual?

Josef







>
> _______________________________________________
> 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/3c57847c/attachment.html>