[SciPy-Dev] module maintainers
Sat Mar 24 16:08:14 CDT 2012
On Tue, Mar 20, 2012 at 11:54 PM, Travis Oliphant <email@example.com>wrote:
> Ok. That is very helpful description. I am 100% behind your vision
> I can put myself down for a maintainer on integrate, interpolate, and
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
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".
> On Tue, Mar 20, 2012 at 1:51 PM, Travis Oliphant <firstname.lastname@example.org>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
> 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
> 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.
>> On Tue, Mar 20, 2012 at 5:30 AM, Travis Oliphant <email@example.com>wrote:
>>> This is wonderful!
>>> The packages I can assist in maintaining and would like to be listed
>> 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
>>> This is always very much appreciated.
>> SciPy-Dev mailing list
>> SciPy-Dev mailing list
> SciPy-Dev mailing list
> SciPy-Dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev