Re: ideas for Google Summer of Code

[Anne Ghisla]

On Friday 16 January 2009 13:11:12 Reinhold Kainhofer wrote:
> Am Freitag, 16. Januar 2009 schrieb Johannes Schindelin:
> > On Fri, 16 Jan 2009, Reinhold Kainhofer wrote:
> > > On Friday 16 January 2009 02:46:22 Johannes Schindelin wrote:
> > > > - the mentor is also expected to work almost full time at least in
> > > > the beginning,
> > >
> > > Sorry, but from my experience with mentoring KDE projects, this is not
> > > really true. It mostly depends on the student, of course, but the main
> > > point is that the student can easily contact the mentor (some short IRC
> > > sessions have proved to be extremely productive). The mentor doesn't
> > > have to be available full time or even work on the project full time.
> > > He rather needs to have a thorough knowledge of how to proceed and
> > > provide the correct pointers. The rest is usually figured out by the
> > > student anyway. At least these are my experiences.

I agree about that, my mentor gave me mainly indications on work to to, we had 
a IRC meeting at least once a week to set goals and examine problems, that's 
all.

> > - it is relatively hard to come up with a project that is neither too
> >   small nor too big for 3 months, from what I see in LilyPond,
>
> I don't think this is a big problem. It's up to the project to judge the
> success of the student: If the problem was too large, but the student still
> managed to do a substantial amount, even though it's not finished, we can
> still declare it a success. Similarly, if the student runs out of work, I'm
> sure we can find something related to keep him/her busy for the rest of the
> SoC...

I agree here too. I intentionally chose a project smaller than I could afford, 
first because it involved Python and I never programmed in Python before, 
second to have some time left to solve unexpected difficulties. 
This has been a successful choice: I ended the hard-coding part soon after 
mid-term evaluation, so I had time to polish code, do extensive testing and 
successfully end SoC.

> > - the natural mentor for any LilyPond project says he's not available
>
> Yes, that's the main bottleneck. For example, the MusicXML output backend
> would be a very good project, but I doubt that anyone other than Han-Wen
> could possibly mentor it...

As I said above, what I expect from a mentor is to know enough about the 
project to gave advices and keep me coding in the right direction. 
I also have quite a long time before SoC to get used of LilyPond development, 
therefore I can be operative from the beginning of the program.

> So what? LilyPond would be under the umbrella of GNU, which will get
> awarded a fixed number of students. So, inside GNU, we'll simply have to
> argue why we also need a student. We can even argue that the other projects
> already benefitted from the SoC in the previous years, while LilyPond
> didn't. So to be fair, Lilypond should also get a student...

IMHO, we can talk a lot about what could happen. Why don't we act as the 
application could be accepted? If it is, we will be ready to work on the 
project and have good chances to succeed; if not, I will anyway contribute to 
LilyPond as a volunteer.
I have to tell you that last year I proposed an application just for bet. See 
the result: development is still undergoing :) [0]

> Shouldn't we start collecting possible project ideas (not only for SoC, but
> for any possible newcomer to LilyPond, so that we don't have to point them
> to the bug tracker telling him/her to simply choose a bug and work on that,
> which can be cathastrophic if you don't know the internals yet)? How about
> a page in our wiki?

Good idea! The bug list is sometimes misleading, maybe a bug looks trivial but 
it requires lot of internals knowledge. This list can help me to pick up a 
suitable idea.

regards,

Anne

[0] http://wiki.qgis.org/qgiswiki/GSoC2008Rbinding

-- 
Please consider the environment before printing this email
Please do not send attachments in proprietary formats
http://www.gnu.org/philosophy/no-word-attachments.html
Use the UNI CEI Standard ISO/IEC 26300:2006
-----------------------------------------------------------
O< stop html mail - http://www.asciiribbon.org

signature.asc
Description: This is a digitally signed message part.