[Sugar-devel] GSoc 2010 - Feedback requested

[Tomeu Vizoso]

On Tue, Mar 9, 2010 at 22:24, Tim McNamara <paperless at timmcnamara.co.nz> wrote:
> Hi all,
> Welcome to another round of GSoC. I welcome your thoughts on a few issues.

Thanks a lot for taking this enormous task. The comments below are
about GSoC projects in the Sugar core, not about most activities or
other Sugar-related projects.

> Here are some topic headers for discussion:
> Recruitment
> any suggestions on how to recruit?
> - mentors

Choose people who have already contributed and that won't overpromise.

> - students

Focus on quality, not quantity. Put a high initial bar, even if it
will mean we miss some good candidates. For this initial challenge,
they shouldn't expect help from the community, even if during the
project this will be strongly encouraged.

> How should we as a group deal with
> problems that we could face, any recommended counter-strategies
> - shy students / reluctance to engage on lists, etc

Reject them off-hand.

> - supporting the mentors

Have good back-up mentors.

> - incorporating code.. separate branches or regularly submitting to the
> trunk?

IMO, the biggest problems I have seen in past years have been:

- too undefined and big scope, and

- mentors not being experienced enough FOSS nor Sugar contributors.

About the first, people are warned from the start and seem to be
conscious of this risk, but as coding proceeds, they get tempted to
use the remaining time to expand the scope of the project instead of
polishing. Even when we should know already that the first 90% takes
only 10% of the total time... Regular and early pushing could help,
but it's often not possible for new features.

About the second, this is an endemic problem in SLs: we want to do
lots of development-related things, but very few people want to triage
and fix bugs and become module peers and maintainers, where we have a
bottleneck.

> Reporting
> what is the best way to monitor progress? should we make progress reports
> public?
> - which mailing lists should we encourage students to join?

IAEP and sugar-devel.

> - weekly, fourtnightly, monthly progress reporting?

At least weekly, I think.

> - keep progress reports between student/mentor?

Sounds good to me, but I think this should be done in the general
lists and not in a special list or in private threads or wikis.

> Code requirements
> what should Sugar Labs & mentors be looking for
> - coding style
> - level of comments
> - lines of code per week

The same that any other code:

http://wiki.sugarlabs.org/go/Development_Team/Code_guidelines

It still needs lots of work, specially in the class design section.

> Potential assessment criteria
> what is the relative importance of
> - IAEP, e.g. that the student 'gets' the education philosophy rather than a
> pure technology focus

For some projects, this may not be so important for SLs, for example
if the project was about optimizing SVG-rendering in Cairo. For the
student is a different matter, of course.

> - Willingness to learn from mentor's advice
> - Code quality
> - Code quantity
> - Communication skills

All very important, but code quantity less.

Regards,

Tomeu

> Cheers,
> Tim
> @timClicks
> Sugar Labs GSoC 2010 Coordinator
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>