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

jason-sage@creativetra... jason-sage@creativetra...
Tue Feb 24 19:24:38 CST 2009

Andrew Straw wrote:
> Stéfan van der Walt wrote:
>> Rob,
>> 2009/2/25 Rob Clewley <rob.clewley@gmail.com>:
>>> I don't want to have the responsibility of "owning" anything about the
>>> existing code for ODE solving (and maybe some other numerical
>>> methods), even though I have some stake in it. But I'll happily share
>>> in some of the reviewing and possibly testing of changes and
>>> improvements to that code.
>> I think you raise an important point.
>> As an Open Source project, we could could succeed without much (any)
>> formal hierarchy.  Naturally, the system evolves into a kind of
>> meritocracy, where capability and dedication counts heavily (as it
>> should).
>> Informal ownership (I care for this code, therefore I take note of its
>> progress) is helpful in moderate doses.  For example, I like the fact
>> that Nathan reviews all patches related to sparse matrices; he knows
>> that part of SciPy extremely well, and his advice is valuable.  Of
>> course, other reviews of such a patch would be just as welcome.
>> The main argument I tried to put forth earlier was:
>> Contributing to a project is easy when you know what is expected of
>> you (clear guidelines), and when you know that you'll be treated on
>> merit alone (the same as everybody else).  Merit carries no malice,
>> and is about as impartial as it gets.
> I also want to point out that a formal code review process that is open
> (such as a web gui) encourages participation by people who may not feel
> they have the time or abilities to write new code, but would feel
> comfortable commenting on a patch sitting in front of them. I think it
> new developers could be fostered this way, too. Finally, while the
> prospect of having code go up for review won't encourage Travo to submit
> new code, it might have that effect on someone with less experience who
> is afraid that his/her new feature won't compile on Windows (for
> example). A formal code review process allows that person to put
> something online and say "don't apply as-is -- I'm looking for help
> integrating with Windows" or simply "I got this far, but I wonder how to
> do XXX". I realize these things are possible, to a degree, with Trac,
> but I agree that a better workflow process would be very useful.

This guarantee of a review made a huge difference in me being 
comfortable starting to contribute to Sage.  I didn't have to get 
everything perfect; I knew someone would review my changes and offer 

Another thing that I learned from the Sage project was that if you 
require it ("build it" :), they will come.  It may take time, but 
requiring review of patches seems to pull people out of the woodwork to 
try reviewing the patches; people that would be too hesitant to actually 
write code for Sage, at least yet.  It's a great, nonthreatening way to 
learn the system (there is often more than one review of a patch, 
especially if one of the reviewers is new to Sage).

Just a few more reasons for a formal policy of reviews.


Jason Grout

More information about the Scipy-dev mailing list