Issue 4763: Web: Review GSoC page

Web/GSoC: Review list introduction
Web/GSoC: Review ScholarLY project description
Web/GSoC: Review Grace Notes project description
Web/GSoC: Review MusicXML project description
Web/GSoC: Review Slurs project description
Web/GSoC: Review Glyphs project description
Web/GSoC: Review Beaming project description
Web/GSoC: Review Compilation project description
Web/GSoC: Sort projects by mentor availability
Web/GSoC: Insert Spanner-per-Voice project suggestion
Web/GSoC: Incorporate suggestions by Paul's review
Web/GSoC: Add "Chord structure" project

diff --git a/Documentation/web/community.itexi b/Documentation/web/community.itexi
index a2209177002dd9ddb7e11e1dd16851827ca7afd7..214ee64d40fa0174e556a661da27970ad4dba6d8 100644 (file)
--- a/Documentation/web/community.itexi
+++ b/Documentation/web/community.itexi
@@ -904,44 +904,92 @@ developer mailing list (see @ref{Contact}).
 @divClass{column-center-middle-color2}
 @subheading Project Ideas List
 
 @divClass{column-center-middle-color2}
 @subheading Project Ideas List
 

-Below is a list of projects that was initially drawn up for GSoC 2012.
-It is maintained here as inspiration for future GSoC projects and for
-anyone who is interested in developing LilyPond.
+Below is a list of suggested projects for GSoC or for anyone who is
+interested in helping to improve LilyPond. (Last updated: February 2016)

 
 

-Note that this is not an exhaustive list.  Other GSoC projects are also
-possible.  There are a number of areas where LilyPond could be improved
-and the LilyPond development team is always willing to help those who
-would like to tackle a project like those listed below.
+Mentor availability varies from project to project and from year to year.
+Send us an email on our developer mailing list (see @ref{Contact}), and
+we will help you find a mentor for a project that fits your interests
+and skills.
+
+If you have ideas for a GSoC project that is not listed below you can
+send us an email as well.  There are a number of areas where LilyPond
+could be improved, and our development team is always willing to help
+those who would like to tackle a project like those listed below.

 
 A full list of all the current open issues can be found
 @uref{http://sourceforge.net/p/testlilyissues/issues/, here}.
 
 @divEnd
 
 
 A full list of all the current open issues can be found
 @uref{http://sourceforge.net/p/testlilyissues/issues/, here}.
 
 @divEnd
 

+@divClass{column-center-middle-color3}
+@subheading Improve internal chord structure
+
+The internal representation of LilyPond chords is not powerful enough
+to capture the nomenclature of jazz chords.  Currently the chord has
+a root, a bass and an inversion.  It would be nice to be able to handle
+stacked or polychords, minor/major, etc.  In order to do this, an
+internal representation with the ability to capture the essence of
+complex chords must be developed.  As a bonus, once the internal
+representation is developed, the output formatting of chord names can
+be improved.
+
+@strong{Difficulty:} Easy/medium
+@strong{Requirements:} Scheme (Guile), but the level necessary can be
+easily learned
+@strong{Recommended:} Chord theory and naming
+@strong{Mentor:} Carl Sorensen
+
+@divEnd
+

 @divClass{column-center-middle-color3}
 @subheading ScholarLY
 
 ScholarLY is a library in
 @divClass{column-center-middle-color3}
 @subheading ScholarLY
 
 ScholarLY is a library in

-@uref{https://github.com/openlilylib/snippets, openLilyLib} that
-provides functionality for annotating scores, making it possible
-to manage scholarly workflows completely in the context of the score
-document.  So far it is possible to enter annotations of different
-types, produce clickable messages in the console output and export
-to text and LaTeX files.
+@uref{https://openlilylib.org, openLilyLib} that provides functionality
+for annotating scores, making it possible to manage scholarly workflows
+completely in the context of the score document.  So far it is possible
+to enter annotations of different types, produce clickable messages in
+the console output and export to text and LaTeX files.

 
 There are numerous feature requests to turn this library into an
 
 There are numerous feature requests to turn this library into an

-even more powerful and comprehensive tool, for example: Inserting
+even more powerful and comprehensive tool.  Some examples: Inserting

 music examples, producing footnotes, automatically applying styles
 to the annotated item (e.g. dash a slur, parenthesize an accidental),
 creating reports with point-and-click entries.  For a full description
 of this project suggestion please visit
 music examples, producing footnotes, automatically applying styles
 to the annotated item (e.g. dash a slur, parenthesize an accidental),
 creating reports with point-and-click entries.  For a full description
 of this project suggestion please visit

-@uref{https://github.com/openlilylib/scholarly/wiki/GSoC}.
+@uref{https://github.com/openlilylib/scholarly/wiki/GSoC, this Wiki page}.

 
 @strong{Difficulty:} medium
 @strong{Requirements:} Scheme, possibly LaTeX, (optionally Python)
 @strong{Recommended:} Experience with or interest in scholarly
 edition and collaborative workflows.
 
 @strong{Difficulty:} medium
 @strong{Requirements:} Scheme, possibly LaTeX, (optionally Python)
 @strong{Recommended:} Experience with or interest in scholarly
 edition and collaborative workflows.

-@strong{Potential Mentor:} Urs Liska
+@strong{Mentor:} Urs Liska
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Adding variants of font glyphs
+
+@divClass{keep-bullets}
+@itemize
+
+@item
+Adding @q{on} and @q{between} staff-line variants.
+
+@item
+Shorter and narrower variants of some glyphs for example, accidentals.
+Another, more specific example could be an ancient notation breve
+notehead coming in two variants one with a small or big @q{hole} within
+it.
+
+@end itemize
+@divEnd
+
+@strong{Difficulty:} easy
+@strong{Requirements:} MetaFont, C++, good eye for details
+@strong{Recommended knowledge:} basic LilyPond knowledge
+@strong{Mentor:} Werner Lemberg

 
 @divEnd
 
 
 @divEnd
 


@@ -949,13 +997,78 @@ edition and collaborative workflows.
 @subheading Grace notes
 
 Fix problems with synchronization of grace notes.  Grace notes can
 @subheading Grace notes
 
 Fix problems with synchronization of grace notes.  Grace notes can

-intefere with LilyPond's timing and cause odd effects, especially when
+interfere with LilyPond's timing and cause odd effects, especially when

 multiple staffs are used where some have grace notes and others don't.
 multiple staffs are used where some have grace notes and others don't.

+This is one of the longest-standing and one of the more embarrassing
+@uref{https://sourceforge.net/p/testlilyissues/issues/34/,bugs} in
+LilyPond.

 
 @strong{Difficulty:} medium
 @strong{Requirements:} C++, MIDI
 @strong{Recommended:} familiarity with LilyPond internals
 
 @strong{Difficulty:} medium
 @strong{Requirements:} C++, MIDI
 @strong{Recommended:} familiarity with LilyPond internals

-@strong{Potential Mentors:} Mike Solomon, Carl Sorensen
+@strong{Potential Mentors:} Mike Solomon (not available for GSoC 2016),
+Carl Sorensen
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Improve default beam positioning
+
+For regular, cross-staff, broken and kneed beams.  Beaming should depend
+on context and neighbor notes
+(see @uref{http://icking-music-archive.org/lists/sottisier/sottieng.pdf,
+section 2.2 here}).  If possible also reduce beaming-computation time.
+
+@strong{Difficulty:} medium
+@strong{Requirements:} C++, experience with writing heuristics
+@strong{Recommended knowledge:} aesthetic sense
+@strong{Potential Mentors:} Mike Solomon (not available for GSoC 2016),
+Carl Sorensen
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Allow spanners to cross voices
+
+Currently all sorts of spanners (ties, slurs, dynamics, text spanners,
+trills etc.) have to be ended in the context they were started.  However,
+this doesn't reflect the reality of notation in most polyphonic settings.
+Awkward workarounds with hidden voices are currently necessary to achieve
+cross-voice spanners.
+
+New ways of addressing this issue should be explored, for example by
+
+@divClass{keep-bullets}
+@itemize
+
+@item specifying a “target context” where the end of the spanner is
+expected
+
+@item explicitly specifying the ending object with an ID
+
+@end itemize
+@divEnd
+
+This feature would solve many problems that are commonly faced with
+piano music and combined parts. 
+
+@strong{Difficulty:} medium (?)
+@strong{Requirements:} C++, Scheme
+@strong{Potential Mentor:} Urs Liska
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Help improve compilation behavior
+
+Automatic code analysis tools, like valgrind memory leak detection or
+callgrind code profilers, provide valuable information about possible
+flaws in our C++ code.  Cleaning up warnings would allow us to automate
+the rejection of any patch which introduced extra warnings.
+
+@strong{Difficulty:} medium
+@strong{Requirements:} C++
+@strong{Potential Mentors:} Reinhold Kainhofer (not available for GSoC
+2016), Joe Neeman

 
 @divEnd
 
 
 @divEnd
 


@@ -989,9 +1102,13 @@ each output object to the XML tags.
 @end itemize
 @divEnd
 
 @end itemize
 @divEnd
 

+There are several possibilities for this project, including building upon
+the MusicXML export project from GSoC 2015.
+

 @strong{Difficulty:} medium
 @strong{Difficulty:} medium

-@strong{Requirements:} MusicXML, Python, basic LilyPond knowledge
-@strong{Potential Mentors:} Reinhold Kainhofer, Mike Solomon
+@strong{Requirements:} MusicXML, Python, Scheme, basic LilyPond knowledge
+@strong{Potential Mentors:} Reinhold Kainhofer, Mike Solomon (both not
+available for GSoC 2016)

 
 Familiarity with other scorewriters (for cross-testing) would also help.
 
 
 Familiarity with other scorewriters (for cross-testing) would also help.
 


@@ -1000,7 +1117,7 @@ Familiarity with other scorewriters (for cross-testing) would also help.
 @divClass{column-center-middle-color3}
 @subheading Improve slurs and ties
 
 @divClass{column-center-middle-color3}
 @subheading Improve slurs and ties
 

-The default curves of slurs and ties are often unsatisfactory. Ties
+The engraving quality of slurs and ties is often unsatisfactory. Ties

 @q{broken} by clef or staff changes are not handled well.  The project
 could include collecting and sorting examples of bad output, deciding on
 the intended output and writing code to improve them.
 @q{broken} by clef or staff changes are not handled well.  The project
 could include collecting and sorting examples of bad output, deciding on
 the intended output and writing code to improve them.


@@ -1008,61 +1125,8 @@ the intended output and writing code to improve them.
 @strong{Difficulty:} hard
 @strong{Requirements:} C++, experience with writing heuristics
 @strong{Recommended knowledge:} LilyPond knowledge, aesthetic sense
 @strong{Difficulty:} hard
 @strong{Requirements:} C++, experience with writing heuristics
 @strong{Recommended knowledge:} LilyPond knowledge, aesthetic sense

-@strong{Potential Mentor:} Mike Solomon
-
-@divEnd
-
-@divClass{column-center-middle-color3}
-@subheading Adding variants of font glyphs
-
-@divClass{keep-bullets}
-@itemize
-
-@item
-Adding @q{on} and @q{between} staff-line variants.
-
-@item
-Shorter and narrower variants of some glyphs for example, accidentals.
-Another, more specific example could be an ancient notation breve
-notehead coming in two variants one with a small or big @q{hole} within
-it.
-
-@end itemize
-@divEnd
-
-@strong{Difficulty:} easy
-@strong{Requirements:} MetaFont, C++, good eye for details
-@strong{Recommended knowledge:} basic LilyPond knowledge
-@strong{Potential Mentor:} Werner Lemberg
-
-@divEnd
-
-@divClass{column-center-middle-color3}
-@subheading Improve default beam positioning
-
-For regular, cross-staff, broken and kneed beams.  Beaming should depend
-on context and neighbor notes
-(see @uref{http://icking-music-archive.org/lists/sottisier/sottieng.pdf,
-section 2.2 here}).  If possible also reduce beaming-computation time.
-
-@strong{Difficulty:} medium
-@strong{Requirements:} C++, experience with writing heuristics
-@strong{Recommended knowledge:} aesthetic sense
-@strong{Potential Mentors:} Mike Solomon, Carl Sorensen
-
-@divEnd
-
-@divClass{column-center-middle-color3}
-@subheading Help improve compilation behavior
-
-Automatic code analysis tools, like valgrind memory leak detection or
-callgrind code profilers, provide valuable information about possible
-flaws in our C++ code.  Cleaning up warnings would allow us to automate
-the rejection of any patch which introduced extra warnings.
-
-@strong{Difficulty:} medium
-@strong{Requirements:} C++
-@strong{Potential Mentors:} Joe Neeman, Reinhold Kainhofer
+@strong{Potential Mentors:} Mike Solomon, Janek Warchoł (both not available for
+GSoC 2016)

 
 @divEnd
 
 
 @divEnd