Re: [boost] [Summer of Code] An overview of Boost participation inGSoC 2006

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2006-10-21 16:03:37

----- Mensaje original -----
De: Robert Ramey <ramey_at_[hidden]>
Fecha: Viernes, Octubre 20, 2006 7:01 pm
Asunto: Re: [boost] [Summer of Code] An overview of Boost participation
        inGSoC 2006
Para: boost_at_[hidden]

> Giovanni Piero Deretta wrote:
> >> Conduct student-mentor exclusively through public channels
> >
> > This would also be great. While our mentors have been very helpful,
> > more comments on our problems would have been useful. I would 
> mandate> that all *technical* communications should be public.
> 
> I have to say I think this is not at all a good idea.
> 
> In development of a "speculative" idea,  there are lots of failed
> experiments.  Doing this in public would only consume lots of time
> and distract from job at hand.
> 
> I think a better approach would be for software developers
> (us included) to keep a log of what we've been doing.  This
> would include a record of the failed approaches that had been
> tried and discarded.  This would eventually form the basis
> of the "rationale" and be very handy when a project is submited
> for review (formal or otherwise).
> 
> Personally, I think the idea of software development as a
> collaborative activity is overrated.  I see it as more personal.
> Of course criticism (constructive and otherwise) is a public
> activity.  So I think those public dissicussions which speculate
> on how libraries should be designed and what they should
> include and not include are much less valuable than those
> discussions which revolve around a specific example of the
> implementation of an idea.  The former is sort of more fun,
> and the later can be more difficult and painful - but I think
> its ultimately more productive.

Hello Robert,

In some sense I agree with you that nothing beats a dedicated
mind with focus, time and lack of pressure to produce solid
designs upon which others can later build up, discuss etc. But
this scenario is different in that it's a student who's doing the
work, and the whole thing is supposed to be mentored and
validated by the organization. Some guidance is expected
and indeed (IMHO) needed, so what the rule about pulic
communication tries to fight against is the (possibly natural)
tendency of students to try and do all the work on their own
without giving the community the possibility to assess the
progress and orientation of the project.

[...]
 
> >> Maintain code, docs and tests in parallel
> >
> > I'm guilty of not doing this, so yes, mentors should *require* 
their
> > students to have docs and test up to date.
> 
> I think that the projects are really in the early stages of 
> developmentrather than being refined for "release".  So I think 
> its pre-mature to insist upon this level of formality.

Indeed, by the deadline of GSoC no project could be said
to be ready for formal review. What's asked is that students
plan their work carefully so as to arrive to that deadline
having advanced reasonably along the three dimensions (code,
tests, docs). I know of at least one project where the code
was fairly complete but contained no docs at all by the
end of GSoC. This should have been detected and remedied
during the program.

> Robert Ramey 

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo