<br><br><div class="gmail_quote">On Fri, Mar 13, 2009 at 7:24 AM, Benjamin M. Schwartz <span dir="ltr">&lt;<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div class="im"><br>
Jameson Quinn wrote:<br>
&gt; Honestly, this is news to me. (and I am the co-administrator of the<br>
&gt; Sugarlabs program). If I had to articulate my view of our priorities, it<br>
&gt; would be something like the following:<br>
&gt;<br>
&gt; 7-10 points: Key sugar core improvements. Long-standing, important gaps like<br>
&gt; versioning or unit-tests at the high end of this.<br>
<br>
</div>As others have pointed out many times, the SoC projects that are least<br>
likely to produce useful results are the ones that are the most ambitious.<br>
 In particular, it is difficult to find SoC applicants who are ready to<br>
make deep modifications to an existing codebase, or will be able to<br>
architect complex software.  Remember, SoC applicants are mostly current<br>
undergrads, so most have never participated in multi-person development<br>
effort, or written anything larger than 1000 lines.</blockquote><div><br>Agreed. However, I think that a relatively-skilled GSoC student could take on one of the tasks I mentioned. Versioning could build on CScott&#39;s OLPCFS2, which AFAIK works remarkably well; it really only needs an interface and maybe a converter. Unit tests require a harness (and Sugarbot already exists) and a couple of demo self-tests of the harness; the tests themselves would be a separate story. Yet it is true, both of these would still be ambitious, and would probably be scored down because of it.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
&gt; 0-8 points: Proposal quality.<br>
<br>
</div>Maybe this problem is wrapped up in &quot;Proposal quality&quot;.  If I were<br>
designing a system to reflect my own internal judgment structure, I would<br>
probably add another /multiplying/ factor, the estimated probability of<br>
success (although I hope we can do selection without resorting to<br>
numerical scores.)</blockquote><div><br>I agree. The numbers are only a way of communicating, not a proposed system for choosing. <br></div></div>