[SciPy-Dev] SciPy governance model

[josef.pktd at gmail.com]

On Wed, Jan 18, 2017 at 4:40 AM, Ralf Gommers <ralf.gommers at gmail.com>
wrote:

>
>
> 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.
>

I don't think it needs to be in the governance document. It illustrates the
size difference in the organization compared to Debian for example.

scipy has experts (developers familiar with code and topic) in some areas
and generic maintainers (especially for topics without expert), but who is
available fluctuates given the small numbers of maintainers relative to the
size of scipy. .



>
>
>> 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.
>

I think additional roles can be added in future, if the growth of scipy
makes it large enough to require that those roles are formally defined.

In general, I would prefer to have some impeachment clauses instead of just
pointing at forking, but given that Pauli is the BDFL, I don't think it's
necessary and we don't have to come up with a system for replacing the
BDFL, chairman of the council and the council itself.

Josef



>
> 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
>>
>>
> _______________________________________________
> 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/20170118/9aeda6be/attachment.html>