[squeak-dev] Re: Summer(s) of Code 2007/2008

Klaus D. Witzel klaus.witzel at cobss.com
Fri Mar 7 22:39:09 UTC 2008

On Fri, 07 Mar 2008 23:08:26 +0100, Giovanni Corriga wrote:

> Klaus D. Witzel ha scritto:
>> On Fri, 07 Mar 2008 02:22:07 +0100, Giovanni Corriga wrote:
>>> Andreas Raab ha scritto:
>>>> Klaus D. Witzel wrote:
>>>>> I bet one (1.-) CHF that GTK support will not be included in the  
>>>>> next Squeak release, not counting 3.10, not talking about an  
>>>>> optional package.
>>>>  Why does everyone seem so exclusively focused on doing something  
>>>> that ends up "in the next Squeak release"? Is this a requirement for  
>>>> GSOC? I certainly don't see the HydraTools ever getting into a Squeak  
>>>> release but that doesn't make them any less useful for Squeak.
>>> As I said in my reply to Klaus, there's no need for the projects to be  
>>> geared toward inclusion in the next Squeak release. It's just that I'd  
>>> like for our students to be able to deliver something at the end of  
>>> the Summer.
>>  This *is* a good point and I would really like to be in favor of such  
>> policy. But I cannot since reality dictates something else. Let me  
>> mention the Delta Stream project as an example, its sheer complexity  
>> makes such an enterprise look like it has several ends [pun not  
>> intended] but it is nevertheless possible for a summer coder to make a  
>> significant contribution to DS without also making DS usable for the  
>> masses on the next day, no?
>>  Same goes for Cedrick's project suggestion, please don't expect that  
>> he will create *the* AI by that; all he wants is a port to Squeak  
>> Seaside for multi users (thereby enabling any form of persistency that  
>> users can afford BTW), instead of the current plain Java desktop.  
>> Thousands of other people will be able to do the "remainder" with  
>> Cedrick's base work, perhaps in the next SoC? This kind of policy  
>> *must* be possible, unless we want only gray-bearded experts to apply  
>> to autumn-of-life-long-coding projects.
>>  Think small, keep it open (= always unfinshed *and* always  
>> [re-]usable, as in Smalltalk) and do great things?
> That's a nice idea, generally speaking, but it doesn't really agree with  
> what Google expects.

I don't like to be misinterpreted, and I did not propose something which  
Google does not expect.

> To use your example, "finish DeltaStreams" isn't a good project, since  
> the scope is too wide and vague; "adding this four kinds of deltas" to  
> the system is much better in this regard.

That's what I wrote above: a summer coder can make a significant  
contribution to DS without also finishing the whole DS project at the same  
time (DS was used as an example for a long term project). It seems we are  
both after the same (more or less, I objected "to be included in the  
Squeak release" in a previous post) but what I wrote "doesn't really agree  
with what Google expects"?

And here's what Google writes, just for the records from

- http://code.google.com/p/google-summer-of-code/wiki/AdviceforMentors

At the 2007 mentor summit Leslie Hawthorn shared this important factoid:

  The most successful projects are the ones that are proposed by the  

Scope and Scale

It is in everybody's best interest that your students complete their  
projects with flying colors. A small amount of useful code is worth more  
than a mountain of almost finished code. A happy student at the end of the  
program is more likely to keep working on his/her project than a  
frustrated one. Choose the scope and scale of your projects to reflect the  
following constraints:
The brief duration of the program.
The initial time that will be spent managing infrastructure and getting  
things set up.
The fact that most students need the first month just to get their  
bearings and actually start producing code.
The fact that any project that is worthwhile has inherent difficulties and  
real intellectual challenges, some of which won't be anticipated or  
predicted at the onset of the project.

Therefore, whether the idea for the project comes from you or from your  
student, be ruthless in scaling it back until it really fits within the  
time constraints. If all goes well, you and the student will have a lot of  
time after the program to implement phase 2 of the project, and add all  
those features that would be "nice to have".


More information about the Squeak-dev mailing list