[SciPy-Dev] SciPy governance model

[josef.pktd at gmail.com]

On Sat, Jan 14, 2017 at 3:34 AM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Fri, Jan 13, 2017 at 8:47 PM,  <josef.pktd at gmail.com> wrote:
> >
> >
> > 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".
>
> I don't think we knew who was in charge of Scipy until the candidates
> discussed that a few months ago.
>

It wasn't spelled out, but it was pretty clear how decisions were worked
out.

Actually, closer to the terms of Debian, Ralf was more the project lead in
terms of pushing the "vision" and internal and external communication. Ralf
also had the decision power of the release manager.
Pauli has been the technical committee for final technical decisions.
(Besides being also just regular contributors.)



>
> Remember that the thing we're discussing is the FL in BDFL.   I get
> the impression we Scipiers mostly agree that having a named leader is
> a good idea.
>

I consider FL to mean For Unlimited Time. He or she can always step down
and go on to other things and appoint a successor or let the steering
council choose a successor.
For Life is a long time in open source development, and Guido is the only
one I know of that lasted for a long time.

The point of a BDFL is also that we have more trust in a person than in the
political system. So we choose a BDFL instead of having to write a
constitution that has to survive and make the system function for hundreds
of years and for a few hundred million members.

Josef



>
> > Didn't matplotlib and pandas not also have transition to
> > new de-facto BDFLs?
>
> Here are the Pandas governance docs :
> https://github.com/pandas-dev/pandas-governance .  Of course Pandas is
> a young project, but it also has a founder and main author, making the
> BDFL a more obvious model.
>
> Matplotlib did just adopt a similar doc, where the nominated BDFL is
> not the founder, but they've only had their governance doc for six
> months or so, and so we haven't got any data yet on the FL part:
>
> https://github.com/matplotlib/governance/blob/master/governance.md
>
> > 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.
>
> Yes, right - it is working well - but the point of a governance
> document is to keep it working well for a long time.   The value of
> the 4 year (or whatever) cycle is to have a chance to review whether
> things are still working well, and make changes if they are not.
>
> > 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?
>
> From our de-facto leaders, yes.  When the conversation veers off the
> content and onto the motivations or personal qualities of the
> participants, the only way of fixing that, is for someone with
> authority to intervene, calm the discussion down, and make space for
> the discussion to continue without rancor.  If that doesn't happen,
> then the discussion is useless because there's no space to work out
> the ideas.
>
> 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/20170114/78da9100/attachment.html>