<b>[If you only have 30 seconds to read this email, read the </b><b>bold text only]</b><br><div class="gmail_quote"><span style="font-family: courier new,monospace;">
<br><b>Dear</b> SciPy <b>developer</b>s</span><br style="font-family: courier new,monospace;"><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">The past while has seen a rocky ride with the SciPy servers, but yesterday Peter Wang announced that he is attending to the situation. &nbsp;This, then, seems like the perfect time to <b>stand back and take a look at our infrastructure</b>, and whether we should continue with the current setup.</span><br style="font-family: courier new,monospace;">

<br><font face="courier new,monospace">To put this conversation into context, we have to face the facts: SciPy has a large user community relative to the number of developers.&nbsp; A big library of code, used by many scientists, is supported by a small handful of people all over the world.&nbsp; <b>We cannot afford</b> <b>a high barrier to contribution</b>, and we have to lower the effort it takes for a developer to merge contributed code.<br>

<br><b>I&#39;d like to propose two changes</b> to the status quo:<br><br>1. <b>Change to a distributed revision control system</b>, encouraging more open collaboration.<br>2. <b>Determine guidelines for code acceptance</b>, in terms of unit tests, documentation and peer review.<br>

<br>Allow me to motivate these changes, and then suggest practical approaches for their implementation:<br><br>Subversion allows only a selected group of developers to change the SciPy source code.&nbsp; This does not encourage a culture of meritocracy, but worse, has practical implications, in that users cannot merge their own patches.&nbsp; I won&#39;t discuss the advantages of distributed revision control here, but note that it shifts responsibility from the current core developers to contributers; <b>that benefits us all!</b><br>

<br>This ties in with my second point: code review.&nbsp; The current developers have access to SVN because they are experienced programmers with knowledge of SciPy&#39;s scientific domains of application.&nbsp; We are unable to employ this scarce resource fully, because it simply takes too long to merge a patch from Trac, review it, *bring it up to scratch*, and commit it.&nbsp; <b>We have to put a system in place which allows contributers to take responsibility for their own patches, and for core developers to guide and advise during this process.</b>&nbsp; As it is, we have many patches waiting on Trac for up to a year or more without any feedback; that is not acceptable.<br>

<br>My view on testing is simple: <b>untested code is probably broken code</b> (and I can show examples from the past year&#39;s commit logs to corroborate this statement).&nbsp; <b>As for documentation, we cannot afford to be without it.<br>

</b><br>Implementation:<br><br>Enthought generously hosts SciPy, and I hope they will continue doing so.&nbsp; New software will need to be installed on the server, but we have many hands willing to tackle that task: David Cournapeau and myself included.&nbsp; Before deploying to <a href="http://scipy.org" target="_blank">scipy.org</a>, <b>we will configure a </b>different<b> server as a proof of concept.</b><br>

<br>1) <b>Distributed revision control system: David Cournapeau and myself have been test driving Git [1] on SciPy and NumPy for a while.&nbsp; It is fast, well supported, has great branch support, and is simple to use for the average contributor, while allowing powerful patch-carving for the more adventurous.</b><br>

<br>2) <b>Ticketing back-end:</b> David is exploring RedMine [2], and I&#39;d like to take a look at InDefero [3], but <b>we&#39;ll do a careful analysis</b> of trac-git (like FedoraHosted) too.<br><br>Thank you for taking the time to deliberate on SciPy&#39;s future.&nbsp; I would love to hear your comments.<br>

<br>Kind regards<br>Stéfan<br><br>[1] <a href="http://git.or.cz/course/svn.html" target="_blank">http://git.or.cz/course/svn.html</a><br>[2] <a href="http://www.redmine.org/" target="_blank">http://www.redmine.org/</a><br>
[3] <a href="http://scipy.indefero.net/p/numpy/">http://scipy.indefero.net/p/numpy/</a><br>
[4] <a href="http://fedorahosted.org" target="_blank">http://fedorahosted.org</a><br><br style="font-family: courier new,monospace;"></font>
</div><br>