[SciPy-Dev] SciPy governance model

Fri Jan 13 23:47:50 EST 2017

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

> On Fri, Jan 13, 2017 at 7:38 PM, Nathaniel Smith <njs at pobox.com> wrote:
> > On Fri, Jan 13, 2017 at 5: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.
> >
> > I'm arguing exactly that. (In open source, obviously; scipy is not a
> > nation-state.)
>
> or an arm of local government or a school or a ...
>
> >> Debian is an obvious example [1];
> >
> > But the Debian Project Leader is *nothing at all* like a BDFL. In fact
> > their powers are extraordinarily limited; mostly it's just "convince
> > people to do stuff by talking to them" (i.e. "exercising leadership")
> > and "serve as a project figurehead". Which is what your links says!
> > They explicitly *cannot* make decisions about the technical direction
> > of the project; in the Debian system that power is delegated in a
> > complicated way to individual maintainers, mailing list consensus, the
> > CTTE, and GRs.
>
> Look - please - calm down.   We can have serious calm discussion about
> this.  Sure, Debian uses it's leader in a different way, as could we,
> I don't think we have to bring out the shotguns here.
>
> > If I seem frustrated in discussing these topics with you, then this is
> > why :-(. As is probably obvious to everyone, I actually love geeking
> > out about this kind of thing! But when you make such misleading and
> > hand-wavy arguments it feels lazy, like you're more interested in
> > vague in-principle discussions than in actually trying to put together
> > a real system that can be implemented and help the project move on and
> > accomplish its real goals.
>
> So - this is really very frustrating.  I just proposed writing up a
> document, and comparing to the current one, in a short and reasonable
> period.   I told you that Stefan, who's credentials as a project
> leader can't reasonably be challenged, is also thinking hard about
> this.  It's terribly tiring to have to justify my good faith every
> time we have this discussion.
>
>  I know that's not your intention and I'm
> > sorry if that sounds harsh. But at this point I'm having trouble
> > seeing how your comments are helping move things forward in any kind
> > of practical way.
>
> I don't know about harsh, but it certainly sounds impatient and
> patronizing.
>
> Incidentally, I had hoped you'd provide a couple of examples of BDFL
> projects where the BDFL was not the founder / major author.  Maybe the
> discussion could get better if we covered stuff like that.
>

The example is scipy. Pauli has been the implied BDFL for years with Ralf
as "Assistant BDFL". Didn't matplotlib and pandas not also have transition
to new de-facto BDFLs?

I once mentioned in a related mailing list discussion that we should just
codify the status quo which has worked and is working pretty well.

Two of the longest scipy github discussions I have been involved with
https://github.com/scipy/scipy/pull/448   compromise implemented
https://github.com/scipy/scipy/issues/3129   rejected, full solution about
2 years later

(In scipy stats I'm glad to leave all controversial decisions to Evgeni and
Ralf, outside those related to statistical theory.)

>
> >> * 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.
> >
> > I'm more referring about the part where scipy *has* a governance
> > document now that seems perfectly workable. It's not identical to the
> > one I would have written, but so what, there are lots of workable
> > models and this looks like one of them. I'm not seeing folks jumping
> > in eager to redo that process for unclear benefits.
>
> I had hoped to cover that in my previous email.   In practice, if Ralf
> and Pauli do not want to discuss this, this discussion is pointless,
> and we should stop this right now.   However, contrary to your
> apparent assumption, I did not start this discussion to annoy, confuse
> or impress, I started it in the hope of finding the best possible
> model for Scipy governance,
>

You are waiting for a pronouncement from our BDFLs?

Josef

>
> Best,
>
> 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/51a1744f/attachment.html>