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

[address@hidden]

On Apr 1, 2012, at 9:39 AM, Janek Warchoł wrote:

> 
> Also, since this is a new project not mentioned on our GSoC page, i
> need to know who will mentor me - Mike? :)

Doable, although if I mentor you you may wind up breaking more things than you 
fix!

Below is a diff with some corrections.  It's very well written.  Besides what I 
wrote below, three general comments:
--) speak more assertively
--) speak more confidently
--) use less technical terms

Cheers,
MS

Author: Mike Solomon <address@hidden>  2012-04-01 11:14:05
Committer: Mike Solomon <address@hidden>  2012-04-01 11:14:05
Parent: c35f566640d51950684263bc18e82dc60914d41d (initial proposition)
Branch: master
Follows: 
Precedes: 

    corrections

----------------------------------- prop.txt -----------------------------------
index 7c87774..8342069 100644
@@ -1,41 +1,44 @@
 Summary:
-LilyPond support for lyrics is currently similar to the two market
+LilyPond support for lyrics is currently similar to that of 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:
+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.
+[It may be worth it here to mention what lyrics are and show several
+examples of how they are written in music (handwritten, hand typeset,
+computer typeset).]
 
 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
+Users will have their lyrics automatically typeset with a quality equal to
+that of the best hand-engraved professional publications; LilyPond's default 
lyric
+positioning will surpass that of any other music notation program (including
+world market leaders such as Finale and Sibelius).  There will be virtually no
+need for hard-coded manual corrections, making scores 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
+The GNU project will benefit from having a music engraving program offering
+its users unique possibilities and a 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
+manual corrections; better lyric positioning is one of the few
 improvements needed to have LilyPond automatically produce
-publication-quality scores of such great works.
+publication-quality scores of 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:
+putting each feature into a separate issue for greater clarity.  The issues
+are viewable 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
+These features shouldn't be addressed separately; they are
+connected to each other and a good solution must be based on a generic
+architecture.  I suggest the addition of new properties to LyricText
+grobs, for example a right- and left-alignment edge (which 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
@@ -43,7 +46,13 @@ 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
+[This "However" and the sentence above it are too technical and too iffy.
+You are in competition with other candidates and you need to sound certain
+of yourself.  Also, for them, lign-breaking, measure width, etc. do not
+mean anything.  You need to use generic terms as much as possible and, when
+you can, include pretty pictures.]
+Most of the changes will be done Lyric_engraver class [again, not
+comprehensible for someone outside of the project]; 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
@@ -67,15 +76,18 @@ 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.
+3. May 7th - June 10th: do the necessary changes in the 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.
+[Stuff like this you can get rid of - just give the most pertinent
+aspects of the plan.]
 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.
+[This should also be gotten rid of.]
 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.
@@ -107,7 +119,7 @@ will be allowed to nag me.
 
 
 Qualification:
-I'm working on LilyPond for more than a year now; there are about 60
+I've been 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
@@ -128,19 +140,12 @@ 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).
+hours a week in the following months.
 
 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.
\ No newline at end of file
+the Epifania choir in which I sing bass and I regularly typeset vocal
+scores.  I know how important legibility is in lyric typesetting and how
+much clear lyrics will benefit choirs and thus music around the world.
+Also, being the one who prepared the Lyrics Bug Report, I have been collecting
+scanned examples of published scores for a long time and I know how to do
+the necessary research and coding to implement an elegant solution.