[SciPy-Dev] module maintainers

[Ralf Gommers]

On Tue, Mar 20, 2012 at 1:51 PM, Travis Oliphant <travis at 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 at 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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20120320/307cd460/attachment.html>