@subsubheading Other languages
@quotation
-@uref{http://lists.gnu.org/mailman/listinfo/lilypond-es,
-Spanish mailing list}
+@uref{http://lists.gnu.org/mailman/listinfo/lilypond-user-fr,
+French mailing list}
@uref{http://www.lilypondforum.de/,
German forum}
@uref{http://groups.google.com/group/lilypond-brasil,
Portuguese group}
-@uref{http://lists.gnu.org/mailman/listinfo/lilypond-user-fr,
-French mailing list}
-
-@uref{http://www.lilypondforum.nl/,
-Dutch forum}
+@uref{http://lists.gnu.org/mailman/listinfo/lilypond-es,
+Spanish mailing list}
@end quotation
-
@divEnd
@divClass{column-right-top}
-@subheading Stay Informed
-
-@subsubheading LilyPond Report
+@subheading The LilyPond Blog
-The easiest way to keep touch is by reading our community
-newsletter, the LilyPond Report:
+Read our community blog, @q{Scores of Beauty}:
@example
-@uref{http://news.lilynet.net}
+@uref{http://lilypondblog.org}
@end example
@subsubheading Releases mailing list: @code{info-lilypond@@gnu.org}
@divClass{column-right-bottom}
-@subheading Developer Discussion
+@subheading Developer Discussions and Translations
@subsubheading Developer mailing list: @code{lilypond-devel@@gnu.org}
-Most developer discussion takes place on this list. Patches
-should be sent here.
+Developer discussions take place on this list. Patches can also be sent
+here.
@quotation
@uref{http://lists.gnu.org/mailman/listinfo/lilypond-devel,
@subsubheading Bug mailing list: @code{bug-lilypond@@gnu.org}
-Bug-specific discussion takes place here.
+Bug reports and discussions should be sent here. Do not send patches
+to this list.
@quotation
@uref{http://lists.gnu.org/mailman/listinfo/bug-lilypond,
@warning{Before sending a message to the bug list, please read our
guidelines for @ref{Bug reports}.}
-@divEnd
-@divClass{column-right-bottom}
-@subheading Sensitive emails
+@subsubheading Translation mailing list: @code{translations@@lilynet.org}
-Private matters should be sent to Graham Percival (project
-manager), who will discuss it with those concerned.
+All discussions about translating LilyPond manuals should be sent here.
+Do not send patches to this list.
+
+@quotation
+@uref{http://lilypond-translations.3384276.n2.nabble.com/,
+Translation mailing list archive}
+@end quotation
@divEnd
We may already know about this bug. Check here:
@example
-@uref{http://code.google.com/p/lilypond/issues/list}
+@uref{http://sourceforge.net/p/testlilyissues/issues/}
@end example
@warning{Please @strong{DO NOT} add bug reports directly to the
@divClass{column-center-top}
@subheading What is Google Summer of Code?
-A global program run by Google that offers students stipends for working
-on open source software projects during summer vacations.
+@uref{https://developers.google.com/open-source/gsoc/, GSoC} is a global
+program that offers students stipends to write code for free software
+and open source projects during the summer. It is an excellent
+opportunity for students to gain experience with real-world software
+development and make a contribution that benefits everyone. It brings
+new contributors to LilyPond and enables students who are already
+involved to become more involved. LilyPond participates in GSoC as part
+of the @uref{http://www.gnu.org/, GNU project}.
-It is an excellent opportunity to find new contributors, and encourage
-students already participating in LilyPond development, to become more
-involved. One of our contributors was accepted in the 2012 program as
-part of the @uref{http://www.gnu.org/, GNU project}; and we are always
-looking for others to participate in future programs.
+We have had GSoC participants in 2012 and 2015 and encourage students to
+apply for future summers.
+
+If you have questions or would like to apply, send us an email on our
+developer mailing list (see @ref{Contact}).
@divEnd
@divClass{column-center-middle-color2}
-@subheading Our Ideas List
+@subheading Project Ideas List
+
+Below is a list of suggested projects for GSoC or for anyone who is
+interested in helping to improve LilyPond. (Last updated: February 2016)
-Below is a list of projects that were suggested for the GSoC 2012
-students and is retained here as an inspiration for anyone
-who is interested in developing LilyPond for future GSoC projects.
+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.
-There are many more things that can be done to improve LilyPond and
-members of the LilyPond development team are always willing to help
-those who would like to tackle projects such as those listed below.
+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://code.google.com/p/lilypond/issues/list, here}.
+@uref{http://sourceforge.net/p/testlilyissues/issues/, here}.
@divEnd
@divClass{column-center-middle-color3}
-@subheading Grace notes
+@subheading Improve internal chord structure
-Fix problems with synchronization of grace notes. Grace notes can
-intefere with LilyPond's timing and cause odd effects, especially when
-multiple staffs are used where some have grace notes and others don't.
+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:} medium
-@strong{Requirements:} C++, MIDI
-@strong{Recommended:} familiarity with LilyPond internals
-@strong{Mentor(s):} Mike Solomon, Carl Sorensen
+@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 MusicXML
-
-Improving MusicXML import and export functions:
-
-@divClass{keep-bullets}
-@itemize
-
-@item
-Handle basic musical content export like the MIDI export (i.e. using
-dedicated exporter classes, derived from the translator class).
-
-@item
-Build the XML tree of the basic musical content, add a connection from
-music event to XML tag.
-
-@item
-Let all LilyPond engravers do their job.
-
-@item
-Link each output object (i.e. each stencil or group of stencils) to the
-music cause (and thus to the XML tag in the XML tree).
-
-@item
-Add an XML output backend, which can then add layout information for
-each output object to the XML tags.
-
-@end itemize
-@divEnd
+@subheading ScholarLY
+
+ScholarLY is a library in
+@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
+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
+@uref{https://github.com/openlilylib/scholarly/wiki/GSoC, this Wiki page}.
@strong{Difficulty:} medium
-@strong{Requirements:} MusicXML, Python, basic LilyPond knowledge
-@strong{Mentor(s):} Reinhold Kainhofer, Mike Solomon
-
-Familiarity with other scorewriters (for cross-testing) would also help.
-
-@divEnd
-
-@divClass{column-center-middle-color3}
-@subheading Improve slurs and ties
-
-The default curves of slurs and ties are 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.
-
-@strong{Difficulty:} hard
-@strong{Requirements:} C++, experience with writing heuristics
-@strong{Recommended knowledge:} LilyPond knowledge, aesthetic sense
-@strong{Mentor(s):} Mike Solomon
+@strong{Requirements:} Scheme, possibly LaTeX, (optionally Python)
+@strong{Recommended:} Experience with or interest in scholarly
+edition and collaborative workflows.
+@strong{Mentor:} Urs Liska
@divEnd
@strong{Difficulty:} easy
@strong{Requirements:} MetaFont, C++, good eye for details
@strong{Recommended knowledge:} basic LilyPond knowledge
-@strong{Mentor(s):} Werner Lemberg
+@strong{Mentor:} Werner Lemberg
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Grace notes
+
+Fix problems with synchronization of grace notes. Grace notes can
+interfere with LilyPond's timing and cause odd effects, especially when
+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{Potential Mentors:} Mike Solomon (not available for GSoC 2016),
+Carl Sorensen
@divEnd
@strong{Difficulty:} medium
@strong{Requirements:} C++, experience with writing heuristics
@strong{Recommended knowledge:} aesthetic sense
-@strong{Mentor(s):} Mike Solomon, Carl Sorensen
+@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}
@strong{Difficulty:} medium
@strong{Requirements:} C++
-@strong{Mentor(s):} Joe Neeman, Reinhold Kainhofer
+@strong{Potential Mentors:} Reinhold Kainhofer (not available for GSoC
+2016), Joe Neeman
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading MusicXML
+
+Improving MusicXML import and export functions:
+
+@divClass{keep-bullets}
+@itemize
+
+@item
+Handle basic musical content export like the MIDI export (i.e. using
+dedicated exporter classes, derived from the translator class).
+
+@item
+Build the XML tree of the basic musical content, add a connection from
+music event to XML tag.
+
+@item
+Let all LilyPond engravers do their job.
+
+@item
+Link each output object (i.e. each stencil or group of stencils) to the
+music cause (and thus to the XML tag in the XML tree).
+
+@item
+Add an XML output backend, which can then add layout information for
+each output object to the XML tags.
+
+@end itemize
+@divEnd
+
+There are several possibilities for this project, including building upon
+the MusicXML export project from GSoC 2015.
+
+@strong{Difficulty:} medium
+@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.
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Improve slurs and 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.
+
+@strong{Difficulty:} hard
+@strong{Requirements:} C++, experience with writing heuristics
+@strong{Recommended knowledge:} LilyPond knowledge, aesthetic sense
+@strong{Potential Mentors:} Mike Solomon, Janek Warchoł (both not available for
+GSoC 2016)
@divEnd