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

[Brian Granger]

>> * 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?

Lack of time *can* be an issue for veteran developers.  But for eager
new developers this is not typically the problem.  For these people,
you simply need to make it perfectly clear how they can contribute to
the project.  The more specific we can be the better.

As a semi-outsider, here is what I *perceive* the Scipy model to be
currently (for new users):

* Checkout the SVN trunk.
* Make your changes.
* Contact the list and tell them about your new code.
* Then ???

This procedure is summarized on the scipy development page in the
following language:

"Interested people can get repository write access as well"

AND

"If you have some new code you'd like to see included in SciPy, the
first thing to do is make a SciKit"

Here is what I would like to see = this would make me wan't to
contribute code to scipy:

Contributing to SciPy is easy and anyone can do it.  Here is what you do:

* Create a branch using git/bzr/hg (we have to pick one).
* Write your code.
* Add tests and documentation to your code.
* Run the test suite
* Post your branch to github/launchpad/bitbucket
* Submit your branch for review using...

When someone is eager to write code, this is what they need!!!

> 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?

No project can escape its history.  But for an eager developer, there
is really no difference (from a workflow/testing/review perspective)
between writing new code and improving old code.

>> * 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.

+1

> 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 --

I agree that this is a hard habit to break.