[SciPy-Dev] module maintainers

Ralf Gommers ralf.gommers@googlemail....
Sat Mar 24 16:08:14 CDT 2012


On Tue, Mar 20, 2012 at 11:54 PM, Travis Oliphant <travis@continuum.io>wrote:

> Ok.    That is very helpful description.  I am 100% behind your vision
> here.
>
> I can put myself down for a maintainer on integrate, interpolate, and
> signal.
>
>
OK, I've made a number of updates:
- added Travis for the above 3 modules
- added RSS feed links for Trac as Vincent suggested
- extended the section on development rules
- added section on servers, docs, website etc. as discussed in another
thread.

I've sent a PR for this document: https://github.com/scipy/scipy/pull/184
This will make it easier to review in detail.

It would be great if module maintainers could write up something that can
be put in the document under "Status".

Cheers,
Ralf


>
> On Tue, Mar 20, 2012 at 1:51 PM, Travis Oliphant <travis@continuum.io>wrote:
>
>> Yes, it is a bit much.   Like I said, I can only 'assist'  :-)      But,
>> given that I am the original author of most of these modules (and several
>> others as well (sparse, misc, io, and fftpack), I still know the C-code
>> especially better than most, and feel like I should not leave them
>> unattended.
>>
>
> Agreed you know the code well. Not being on the maintainers list doesn't
> imply you're abandoning that code though.
>
>
>> If others step up so that there are at least 2 experienced people on a
>> module, then I can step away.   Until then, I still would like to be one of
>> the maintainers of the modules I know intimately.    My time will be
>> limited, but it seems like I could still be useful in helping some of the
>> modules along and clarifying the original intent.
>>
>
> This I fully agree with. Any info, feedback and code you are able to
> provide will be very helpful and welcome. It seems my first email wasn't as
> clear as I thought it was, so I'll try to be more explicit also about what
> I'm not proposing:
>
> 1. I'm not proposing to change the way decisions are made. Any significant
> decisions on adding (or not adding) new features or breaking backwards
> compatibility are made on this list after a discussion (preferably with
> full consensus).
>
> 2. I'm not proposing to give or take away commit rights. Changes in commit
> rights should always be discussed on this list before they are made. As I
> wrote in the draft document, someone can be a maintainer without being a
> committer, or vice versa.
>
> The above two points are unwritten rules of development as I understand
> them. It would be good to write them down explicitly in the same document I
> think. If there are more important ones, those can be added too. We've
> heard from a number of users and new committers recently that these kind of
> things aren't very clear, and writing them down would help.
>
> I'll now try to articulate again what I think this maintainers list should
> achieve, and who should be on it.
>
> Who should be on it:
> 1. The listed maintainers should be developers with a certain expertise on
> the code for the module.
> 2. They should be willing and have the time to respond to PRs, tickets and
> questions.
> 3. They should be interested in either keeping the module in good shape or
> moving it forward. They can take the lead in providing a "roadmap" for the
> module. That doesn't mean they get to decide all by themselves.
>
> What this should achieve:
> 1. A clearer picture of the status of and potential new directions for
> each module.
> 2. More/quicker responses to tickets and questions on the mailing list.
> 3. Indicating where we currently still have gaps in expertise/manpower.
> 4. When (3) is done, filling those gaps. So attracting new developers.
> 5. In case a PR stalls or there is disagreement, there's an obvious person
> or group of persons to help move things forward.
>
>
> Travis, I hope that clears things up. Of course you will not be prevented
> from being involved in any discussions and decisions, and as long as you're
> around on this list I'm sure your opinions will weigh heavily. I just don't
> see the point of listing you as a maintainer on half the modules, since
> you're not going to be involved much in regular maintenance and don't have
> the bandwidth to move all those modules forward.
>
> Cheers,
> Ralf
>
>
>>
>> On Tue, Mar 20, 2012 at 5:30 AM, Travis Oliphant <travis@continuum.io>wrote:
>>
>>> This is wonderful!
>>>
>>> The packages I can assist in maintaining and would like to be listed
>>> are:
>>>
>>> scipy.signal
>>> scipy.stats
>>> scipy.interpolate
>>> scipy.integrate
>>> scipy.special
>>> scipy.optimize
>>>
>>
>> Travis, I love your enthusiasm, but you indicated recently you don't have
>> the bandwidth to work on Scipy much. So this list is a bit much, isn't it?
>>
>> I actually proposed a limit of two modules per person in the SciPy Goal
>> thread. The motivation for that being to spread the load and expertise, and
>> get more people involved. That doesn't mean you can't work on more modules
>> of course. The only reason I didn't write that down in the end is that it
>> doesn't reflect the current status (mainly of Pauli's work and expertise).
>>
>>
>>> I can also be available to help answer questions on any of the other
>>> modules.
>>>
>>> This is always very much appreciated.
>>
>> Ralf
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev@scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev@scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20120324/bc045ad1/attachment-0001.html 


More information about the SciPy-Dev mailing list