[SciPy-Dev] module maintainers

Travis Oliphant travis@continuum...
Tue Mar 20 17:54:41 CDT 2012


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.

Thanks,

Travis 

--
Travis Oliphant
(on a mobile)
512-826-7480


On Mar 20, 2012, at 5:42 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:

> 
> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20120320/982a58a5/attachment-0001.html 


More information about the SciPy-Dev mailing list