[SciPy-dev] Scipy workflow (and not tools).

[Travis E. Oliphant]

Brian Granger wrote:
> Neil,
>
> Thanks for speaking up!  I think there are *many* people in your
> situation, including myself - I too am mostly a silent watcher of
> SciPy and I would be much more likely to contribute if the things you
> list were a part of the Scipy development culture:
>
> * Tests
> * Code review
> * Documentation
>   
What is standing in the way of these things being done more often?    
Tests are happening, code review is happening, and documentation is 
happening.   What exactly is the problem except lack of time from people 
who have historically committed to SciPy?

I want these things to happen and try to do them whenever I submit new 
code.   But, time is a factor, and people will disagree about "what 
constitutes a test" and "what constitutes good documentation."      

There is a lot of code in SciPy that was contributed by me very early on 
that may not live up to the same standard of testing and documentation 
that people have.  Is that the fundamental problem --- history? 
> * Good tools and workflow.
>   
This, I do see as a problem.     The value of DVCS is that it handles 
branches better and new contributors *want* to work on branches and this 
will encourage *everybody* (including me) to work on branches.   

I've been committing to trunk for many years on SciPy and NumPy without 
pre-commit code review.   It's hard for me to break that habit and I'm 
resisting requests that I stop doing that.    I'm willing to stop it -- 
if it will really help SciPy progress.  However, I'm not convinced that 
this kind of commit behavior by me and others is what is really stalling 
SciPy development.      It could be that other commit patterns are not 
advertised enough to assist newcomers and I'm all for advertising other 
commit patterns that help people contribute.    So, let's do that 
advertising.

I'm very encouraged by the experiments with a git-svn bridge and would 
love to see an issue-tracker with a command-line interface.  I'd also 
love to see more volunteers who are willing to tackle release management 
so that we can do it more regularly.    Ultimately, those who do the 
work of release management will define what SciPy *is*.  

Best regards,

-Travis