my GSoC application - please review! (also, who will be my mentor?)

[Janek Warchoł]

Hi all,

below is my application, written according to GNU guidelines
(http://www.gnu.org/software/soc-projects/guidelines.html).  What do
you think about it?
Also, since this is a new project not mentioned on our GSoC page, i
need to know who will mentor me - Mike? :)  (it would be great if
someone also decided to be a backup mentor just in case)
Apart from guiding me during my work on the project, the mentor is
supposed to review my application, submit mid-term and final
evaluations of my work to Google and talk with GNU, our umbrella
organization.  Since the number of student slots is limited and there
are many free software projects in the umbrella, it may be necessary
to convince GNU administrator Jose Marchesi (address@hidden) that
it's absolutely essential that he chooses LilyPond applications over
other projects (actually, i think that everyone, especially our
administrator Graham, Han-Wen and Jan, can take part in convincing
Jose :D)

Thanks!
Janek


My name:
Jan Warchoł
(I usually use form "Janek" to distinguish myself from Jan
Nieuwenhuizen in LilyPond community)

My email address:
address@hidden

The name of the project:
LilyPond: improve Lyrics support

Summary:
LilyPond support for lyrics is currently similar to the two market
leaders (Finale and Sibelius) - users can add any number of lyric
verses, in any language supported by UTF-8 encoding.  I want to add
advanced lyric positioning functions that will be unique to LilyPond:
syllabes will be automatically moved to faciliate easier sight reading
for singers and avoid any ambiguities in interpretation.  Lyric
syllabes will no longer casuse disturbances in note spacing - instead
of moving notes to fit lyrics, lyrics will adapt their position to
allow for the optimal note spacing.

Benefits:
Users will have their lyrics automatically typeset in quality equal to
best hand-engraved professional publications; LilyPond's default lyric
positioning will surpass any other music notation program (including
world market leaders Finale and Sibelius).  There will be virtually no
need for hard-coded manual corrections, so the scores will be easier
to maintain and rearrange.

GNU project will benefit by having a music engraving program offering
its users unique possibilities and very efficient workflow.  LilyPond
is already delivering great typography, but producing professional
scores of such works as G. F. Handel's "Messiah" still requires some
manual corrections; better lyrics positioning is one of the few
improvements needed to have LilyPond automatically produce
publication-quality scores of such great works.

Deliverables:
I've prepared a detailed report on the features that are needed,
putting each feature into separate issue for greater clarity.  It is
available in LilyPond's bug tracker:
http://code.google.com/p/lilypond/issues/list?q=label:GSoC-LyricProject
(so even if my application isn't accepted the community will benefit
by having a thourough report on the matter).
Of course these features shouldn't be addressed separately; they are
connected to each other and a good solution must provide a generic
architecture.  I suggest to add some new properties to LyricText
grobs, for example a right- and left-alignment edge (would solve
issues 2451 and 2452).  I'll investigate how much of the formatting
process can be done after line-breaking is calculated, as it would be
best to know where lines are broken and how much space is available
for each notehead before calculating alignment of lyric syllabes.
However, if this turns out to be impossible, I'll estimate measure
width and place syllabes according to worst-case scenario, and then
adjust their position after line breaking is done.
Most of the changes will be done Lyric_engraver class; however, fixing
issues 2462 and 2450 will require modifications to horizontal spacing
algorithm itself.
As for issue 2459, the plan is to add a new type of context - a
breakable line.  I will then add a command that will allow users to
choose breaking points - that's an easy thing to do.  Then, when I
finish other issues, I'll add automatic breaking based on the gap
between neighbor obejcts, the difference between vertical baseline
position, and overall vertical tightness of music.

All new features will have regresstion tests.  Most of the tests are
already written - they're now added as examples in tracker issues.
Documentation - I'll have to list and describe new object properties,
contexts and functions in Internals Reference.  I'll explain how to
use new possibilities in notation reference, section 2.1.2 "Techniques
specific to lyrics"

Plan:
1. April 20th - May 1st: discuss general architecture design with my
mentor; list grob properties and methods that need to be created.
Determine how to harvest information about horizontal spacing and
whether any changes in horizontal spacing engine will be necessary.
2. May 1st - May 7th: discuss results of the previous step with whole
development team.
3. May 7th - June 10th: do necessary changes in architecture.
Implement the most important features - issues 2456, 2462 and 2459.
4. June 11th - June 29th: exam session on University.  Reduced GSoC
activity; writing drafts for remaining features and asking the
development team for feedback and testing of my work.
5. June 29th - July 9th: if everything is on schedule, I may take a
week of vacation.  However, if there are any doubts if everything goes
as planned, I don't go anywhere.  Prepare to mid-term evaluation; my
code should pass tests for issues 2456, 2462, 2459.
6. July 9th - July 13th: submit mid-term evaluation.
7. July 13th - August 1st: have working code for at least 12 out of 14
project issues.
8. August 1st - August 10th: writing documentation, releasing my code
for wide testing in a development release.
9. August 10th - August 20th: fixing unexpected bugs.
10. August 20th: celebrating and submitting a final evaluation.

Since my work is clearly divided into 14 issues, checking progress
will be easy - every issue has images showing how the LilyPond output
after my improvements should look like.
The features are related to each other, but it is not an
all-or-nothing deal.  Having any subset of them implemented will stil
be useful to LilyPond users.

Communication:
First of all, I'll use a simple rule: if I'm stuck for half an hour,
I'll ask my mentor for some hints.  Every 5 days I will send my mentor
a report on my progress (apart from usual questions asked to him and
to the whole development team).  Since real-time communication is most
efficient, we'll use LilyPond's IRC channel or instant messenger;
possibly we'll arrange regular sessions at least one day a week.

All my code will be visible all the time on a dedicated public
branch(es) in our git repository.  When appropriate, I will create
code reviews with appspot tool for other members of the team.  When
there's no activity on a branch for more than a few days, everyone
will be allowed to nag me.


Qualification:
I'm working on LilyPond for more than a year now; there are about 60
commits of mine in the official repository.  I know people in the
community, including my mentor, and they know me and value my work.  I
know how the development process looks like, so I don't need the
"community bonding period" - the day my proposal is accepted I start
working right away.  This will allow me to compensate for period of
reduced activity caused by university exams; it's also possible that I
will finish my project ahead of the schedule.
I'm an active member of the LilyPond community - see our mailing list
archive: 100 e-mails in February
http://lists.gnu.org/archive/html/lilypond-devel/2012-02/threads.html.
 Also, see my articles and an interview in the last issue of LilyPond
Report, our community newsletter:  link to be pasted.

Being accepted as GSoC student will not only enable me to spend my
summer implementing this project in LilyPond: in fact, the money
received will allow me to continue being involved at least until the
end of 2012 (quite possibly even longer).  The stipend from GSoC will
cover my financial needs for at least 8 months - therefore in addition
to spending at least 400 working hours on LilyPond until August 20th,
I'll dedicate 40 hours a week to LilyPond in September and about 10-20
hours a week in the following months.  Otherwise (that is, if i'm not
accepted as a GSoC student) I'll have to find a part-time job, and
it's possible that I will have to stop contributing to LilyPond in the
next academic year.

Additionally, I decided that if I suceed, I'll give $500 back to the
LilyPond community (i.e. pay one of the developers for implementing
some things that are too difficult for me to code).

And why I'm suited to do this particular issue?  I'm the librarian of
the Epifania choir in which I sing bass, so I regularly typeset vocal
scores.  Virtually every one of my several dozen scores will benefit
from implementing this feature.  Also, as I've already said, it was me
who prepared the Lyrics Bug Report; I was collecting scanned examples
of published scores for a long time and I know how this stuff should
work like.