[SciPy-Dev] SciPy governance model

[Ralf Gommers]

On Tue, Jan 17, 2017 at 8:19 AM, <josef.pktd at gmail.com> wrote:

>
>
> On Mon, Jan 16, 2017 at 12:39 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>
>> Hi,
>>
>> On Mon, Jan 16, 2017 at 1:01 AM, Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>> >
>> >
>> > On Sun, Jan 15, 2017 at 8:15 AM, Pauli Virtanen <pav at iki.fi> wrote:
>> >
>> > Interesting discussion so far!
>> >
>> >>
>> >>
>> >> Sat, 14 Jan 2017 10:03:43 -0800, Matthew Brett kirjoitti:
>> >> [clip]
>> >> > What do you think about the idea of having regular state-of-scipy
>> >> > reviews to make sure we're conscious about keeping on track,
>> assessing
>> >> > risks, improving process?
>> >>
>> >> For the technical aspect, this sounds something like the Scipy roadmap
>> >> (https://github.com/scipy/scipy/blob/master/doc/ROADMAP.rst.txt), and
>> the
>> >> discussion leading to it, in conferences and online in public.
>> >>
>> >> Something like regular prompts for discussion of technical and
>> >> organisation roadmap could be useful. At minimum, this could be simply
>> a
>> >> (bi-?)yearly post on the mailing list, to remind to update the roadmap
>> >> and to summarize / bring up / discuss any relevant organisation
>> updates /
>> >> issues in the preceding period.
>> >
>> >
>> > I quite like this idea. Documents like a roadmap can easily go out of
>> date
>> > if they're not actively maintained. Having a critical look at it once or
>> > twice a year will be helpful. Also +1 for adding some organizational
>> items
>> > to it (I'm thinking CoC, FSA, etc. should have been on there).
>> >
>> > The list of people on the steering committee also needs to be updated
>> with
>> > this kind of frequency.
>> >
>> > How about doing this around 1 January and 1 July every year?
>> >
>> > I'm not sensing a lot of enthusiasm for the fixed-term/election idea,
>>
>> I'm afraid the previous discussion on this thread has made it very
>> unlikely that you would see any enthusiasm, even if, in another world,
>> it was a good idea.  That's the tragedy of mailing list discussions,
>> as satirized here
>>
>> http://www.smbc-comics.com/?id=2939
>>
>> and evident from the recent discussion on the Jupyter governance
>> document. If anyone gets angry or dismissive about an idea, and that
>> isn't addressed, that's a very effective way of inducing consent and
>> shutting down the discussion.
>>
>
>
> Matthew,
> I think that's mis-characterizing this a bit.
>

I think so too, but just in case: if anyone feels uncomfortable to
contribute in this discussion on-list for whatever reason, then I'd much
appreciate to hear his/her opinion offline (both on the governance topic
and on what could have made contributing in public easier).


> We had several governance discussion over the last years, and my
> impression was that the vast majority of those commenting where in favor of
> a more laid back approach instead of a fully specified constitution and
> associated discussion.
>

I think Pauli hit the nail on the head with this:

"(i) the person can step
down at any time, and acting in good faith, will also listen to serious
calls to do so, (ii) regular elections can generate unnecessary work and
politics -- looking at the past 10 years of scipy, there has been little
of this, and I believe this is for the best, (iii) this is more of a role
for fallback decision making and less for a director/CEO."

(i) and (iii) would be good to add to the document itself I think.


> (I think what's missing is a chair wo/man of the steering council
>

This could be helpful, just to be able to give that person the
responsibility to ping everyone for bi-yearly updates, ensure the list of
people stays up to date, contact people that have stopped being active
about removal from the council, etc.

and heads/lieutenants for each sup-package,
>

We used to have this, in a MAINTAINERS document. The added value wasn't
high imho and it went out of date, so we removed it.


> and a specification of the rights of the release manager
>

That's probably useful to add, will do so.


> and maybe some more.)
>

Please add comments on the PR if more comes to mind.

Ralf


> IMO, given the current contributors and the way contributors are recruited
> and integrated, I don't see much difference between unlimited time and
> fixed time with renewal. So, we can as well stick with what we know.
>
> Josef
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20170118/717dc792/attachment.html>