]> git.donarmstrong.com Git - lilypond.git/blobdiff - Documentation/web/community.itexi
5085: Web-GSoC: Update MusicXML project description
[lilypond.git] / Documentation / web / community.itexi
index 2a76a63ba8a6ecc1835d65abc9d44d483773db54..80374ac666d677d89103828e93ed433b1224d10e 100644 (file)
@@ -7,6 +7,7 @@
     Guide, node Updating translation committishes..
 @end ignore
 
+@include included/acknowledge.itexi
 @include included/authors.itexi
 @include included/helpus.itexi
 
@@ -48,11 +49,14 @@ discussing LilyPond.
 @ref{Development}: for contributors and testers.
 
 @item
-@ref{GSoC}: list of projects for Google Summer of Code.
+@ref{Google Summer of Code}: ideas for Google Summer of Code (GSoC).
 
 @item
 @ref{Authors}: the people who made LilyPond what it is today.
 
+@item
+@ref{Acknowledgements}: projects and institutions that support LilyPond
+
 @end itemize
 @divEnd
 
@@ -65,10 +69,11 @@ discussing LilyPond.
 @ref{Publications}: what we wrote, and have had written about us.
 
 @item
-@ref{Old news}: an archive.
+@ref{News}: news from the LilyPond project.
 
 @item
-@ref{Attic}: announcements and changelogs from past versions.
+@ref{Attic}: announcements and changelogs from past versions,
+old news, etc.
 
 @end itemize
 @divEnd
@@ -83,10 +88,11 @@ discussing LilyPond.
 * Help us::
 * Sponsoring::
 * Development::
-* GSoC::
+* Google Summer of Code::
 * Authors::
+* Acknowledgements::
 * Publications::
-* Old news::
+* News::
 * Attic::
 @end menu
 @divEnd
@@ -129,7 +135,7 @@ in your own works.  See what other people have written,
 and add your own!
 
 @example
-@uref{http://lsr.dsi.unimi.it}
+@uref{http://lsr.di.unimi.it}
 @end example
 
 Particularly instructive examples from LSR are included in our
@@ -173,8 +179,8 @@ be useful for others would better be posted to one of the mailing lists.
 @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}
@@ -182,26 +188,19 @@ 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}
@@ -228,12 +227,12 @@ archive3}
 
 
 @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,
@@ -253,7 +252,8 @@ send to lilypond-devel with gmane}
 
 @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,
@@ -272,13 +272,16 @@ archive3}
 @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
 
@@ -410,7 +413,7 @@ then that is a bug.
 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
@@ -487,14 +490,15 @@ report.
 
 Once your bug report has been sent to the list, our Bug Squad will
 examine it; they may ask you for more information.  You will be notified
-when the report will be added to the bug tracker. Please allow up to 4 days,
-as we have a limited number of volunteers for this task.
+when the report will be added to the bug tracker.  Please allow up to 4
+days, as we have a limited number of volunteers for this task.
 
 Once a bug has been added to the tracker, you can comment it to add
 more information about it.
-You may also mark the bug so that you automatically receive emails when
-any activity on the bug occurs.  This requires you have a google
-account.
+In order to be automatically notified about any activity on the
+tracker issue, you may subscribe by clicking the envelope
+symbol next to the issue title.
+Commenting and subscribing require being logged in with a sourceforge account.
 @divEnd
 
 @divClass{column-center-bottom}
@@ -595,10 +599,9 @@ active and experienced developers are.  Statistics up to version
 
 Interested developers:
 @table @asis
-@item @email{dak@@gnu.org, David Kastrup}
-Donations are required to let me continue my current fulltime work on
-LilyPond.  I focus on user and programmer interface design, coherence,
-implementation, simplification, documentation, and debugging.
+@item @email{lilypond-devel@@gnu.org, LilyPond developer list}
+Since no developer currently is listed for commercial development,
+your best bet is asking on the developer list.
 
 @c Format
 @c @item @email{name@@adress.domain, Name}
@@ -759,7 +762,7 @@ This release's lilypond-book tests.
 @itemize
 @item @uref{http://lilypond.org/test, Comparisons between regression tests}
 
-@item @uref{http://lilypond.org/download/binaries/test-output/,
+@item @uref{http://lilypond.org/downloads/binaries/test-output/,
 Archive of all regression tests}
 
 @end itemize
@@ -780,6 +783,7 @@ manuals can be found at @url{http://lilypond.org}}
 @divClass{normal-table}
 @multitable @columnfractions .3 .3 .3
 @headitem Introduction
+
 @item
 @docLinkSplit{Learning,learning,@manualDevelLearningSplit}
 @tab
@@ -800,7 +804,9 @@ manuals can be found at @url{http://lilypond.org}}
 @docLinkBig{Essay,essay,@manualDevelEssayBig}
 @tab
 @docLinkPdf{Essay,essay,@manualDevelEssayPdf}
+@end multitable
 
+@multitable @columnfractions .3 .3 .3
 @headitem Regular
 
 @item
@@ -823,7 +829,9 @@ manuals can be found at @url{http://lilypond.org}}
 @docLinkBig{Snippets,snippets,@manualDevelSnippetsBig}
 @tab
 @docLinkPdf{Snippets,snippets,@manualDevelSnippetsPdf}
+@end multitable
 
+@multitable @columnfractions .3 .3 .3
 @headitem Infrequent
 
 @item
@@ -853,15 +861,17 @@ manuals can be found at @url{http://lilypond.org}}
 @docLinkBig{Internals,internals,@manualDevelInternalsBig}
 @tab
 @docLinkPdf{Internals,internals,@manualDevelInternalsPdf}
+@end multitable
 
 @ifset web_version
+@multitable @columnfractions .3
 @headitem Downloadable
 
 @item
 @doctarballDevel
+@end multitable
 @end ifset
 
-@end multitable
 
 @divEnd
 @divEnd
@@ -869,197 +879,329 @@ manuals can be found at @url{http://lilypond.org}}
 
 
 
-@node GSoC
-@unnumberedsec GSoC
+@node Google Summer of Code
+@unnumberedsec Google Summer of Code
 
 @divClass{column-center-top}
 @subheading What is Google Summer of Code?
 
-Quoting
-@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012, GSoC website},
-@qq{Google Summer of Code is a global program that offers students
-stipends to write code for open source projects.  Google has worked
-with the open source community to identify and fund exciting projects
-for the upcoming summer.}
-
-The LilyPond Team decided that this is an excellent opportunity to find
-new contributors, encourage students already participating in LilyPond
-development to become more involved, and - last but not least - write some
-great code for the benefit of all!
-
-We are participating in GSoC as a part of GNU Project.  See
-@uref{http://www.gnu.org/software/soc-projects/guidelines.html, GNU GSoC webpage}
-for information on how to participate.
+@uref{https://summerofcode.withgoogle.com/, GSoC} is a global program
+that offers students stipends to write code for free software and open
+source projects during the summer.  For three months students work to
+complete a given task as part of the project's community and under the
+guidance of experienced mentors.  The program 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}.
+
+We have had GSoC participants in 2012, 2015 and 2016 and encourage
+students to apply for the 2017 program.
+
+If you are interested to apply for the program with LilyPond as a
+project, please read the information below and don't hesitate to write
+us on our developer mailing list (see @ref{Contact}).  The student
+application window is March 20 to April 3, 2017, but we strongly
+encourage you to get in touch with our community ahead of that.
 
 @divEnd
 
-@divClass{column-center-bottom}
-@subheading Our Ideas List
+@divClass{column-center-middle-color2}
+@subheading Project Ideas List
 
-Below is a list of projects suggested for GSoC students.  If you don't
-see a project that suits you, feel free to suggest your own!
-It's also possible to scale down a project if you feel it's too big.
+Below is a list of GSoC project ideas (last update: January 2017), but
+if you have other ideas for a project you may complete within the three
+months of the program you're welcome to make a suggestion on our
+developer mailing list (see @ref{Contact}).  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 similar to
+those listed below.  As mentor availability varies from project to
+project and from year to year it is wise to get in touch with us as
+early as possible.
 
-We require that every student has basic @code{git} knowledge, and
-recommend that everyone applying for projects other than the last one
-have basic music notation knowledge.
+A full list of all the current open issues can be found
+@uref{http://sourceforge.net/p/testlilyissues/issues/, here}.
 
-@subheading Grace notes
+@divEnd
 
-Fix problems with synchronization of grace notes,
-together with all underlying architecture (see
-@uref{http://code.google.com/p/lilypond/issues/detail?id=34, issue 34 in our tracker}).
-Grace notes are confusing to LilyPond's timing because they're like
-going back in time.  This causes weird effects, especially when one staff
-has a grace note and the other doesn't.
+@divClass{column-center-middle-color3}
+@subheading Improve internal chord structure
 
-@strong{Difficulty:} medium
+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{Requirements:} C++, MIDI
+@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
 
-@strong{Recommended:} familiarity with LilyPond internals
+@divEnd
 
-@strong{Mentor(s):} Mike Solomon, Carl Sorensen
+@divClass{column-center-middle-color3}
+@subheading Adopt the SMuFL music font encoding standard
+
+For several years now a new standard for music fonts has been around:
+@uref{http://www.smufl.org/, SMuFL}, which is also discussed as becoming part of
+a future W3C standard for music encoding.  As a FLOSS tool LilyPond should
+adhere to such an open standard instead of using an isolated solution like it
+does today.  Adopting SMuFL will help integrating LilyPond with the world of
+music notation software and eventually give LilyPond users access to a wider
+selection of notation fonts.
+
+Making LilyPond compliant to SMuFL includes remapping of the glyphs that are
+built from METAFONT sources, adjusting the glyphs' metrics to SMuFL's
+specifications, and finally updating the way LilyPond looks up and positions the
+glyphs.  As an optional part of this project LilyPond's font loading mechanism
+could be modified to use notation fonts installed as system fonts instead of
+inside the LilyPond installation.
+
+@strong{Difficulty:} Easy/medium
+@strong{Requirements:} C++ and willingness to get familiar with LilyPond
+internals.
+@strong{Recommended:} Interest and experience in working with font files.
+A little bit of METAFONT.
+@strong{Mentors:} Werner Lemberg, Abraham Lee
 
-@subheading MusicXML
+@divEnd
 
-Adding comprehensive MusicXML export and improving import,
-together with tests checking that it works. Depending on time available,
-implement some or all of the following:
+@divClass{column-center-middle-color3}
+@subheading Adding variants of font glyphs
 
 @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)
+Adding @q{on} and @q{between} staff-line variants.
 
 @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
-add ability to link each output object
-(basically each stencil / group of stencils) to the music cause
-(and thus to the XML tag in the XML tree)
-
-@item
-Add a XML output backend, which can then add the layout information
-for each output object to the XML tags
+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
 
-The goal will be considered achieved when a (previously chosen) score could be
-imported from MusicXML and exported back with no unintentional loss of data.
+@strong{Difficulty:} easy
+@strong{Requirements:} MetaFont, C++, good eye for details
+@strong{Recommended knowledge:} basic LilyPond knowledge
+@strong{Mentor:} Werner Lemberg
 
-@strong{Difficulty:} medium
+@divEnd
 
-@strong{Requirements:} MusicXML, Python, basic LilyPond knowledge
+@divClass{column-center-middle-color3}
+@subheading Contemporary Notation
 
-@strong{Mentor(s):} Reinhold Kainhofer, Mike Solomon
+LilyPond is very good at creating non-standard notation.  Having to
+@emph{code} every graphical element instead of simply @emph{drawing}
+it may seem cumbersome but is in fact a strong asset.  New notational
+functionality can be provided with consistent appearance, automatic
+layout and a natural syntactic interface.
 
-familiarity with other scorewriters (for cross-testing) would be a nice bonus.
+Within the @uref{https://github.com/openlilylib/oll-core, openLilyLib}
+library system the student will create a fundamental infrastructure
+and building blocks to make creating contemporary notation easier.
+Additionally (at least) @emph{one} concrete package is developed to
+cover specific contemporary notation, such as for example the style
+of a given composer, extended playing techniques for a specific
+instrument or a certain category of effects.
 
-@subheading Improve slurs and ties
+@strong{Difficulty:} medium
+@strong{Requirements:} Scheme (interaction with LilyPond internals),
+contemporary notation techniques
+@strong{Recommended:} sense of building hierarchical frameworks
+@strong{Mentors:} @strong{NN,} Urs Liska
 
-The default shape of slur and tie curves is often unsatisfactory.
-Ties on enharmonic notes @code{@{ cis'~ des' @}} are not supported,
-ties "broken" by clef or staff change aren't supported well.
-The project includes collecting and sorting examples of bad output,
-deciding on the intended output and writing the actual code.
+@divEnd
 
-@strong{Difficulty:} hard
+@divClass{column-center-middle-color3}
+@subheading Rewrite LibreOffice LilyPond Extension with Python
+
+The @uref{http://ooolilypond.sourceforge.net/, OOoLilyPond} extension
+made it possible to conveniently include LilyPond score snippets in
+OpenOffice.org/LibreOffice Writer, Draw and Impress documents while
+keeping source and image together.  After many years without development
+an initial effort has started to make the extension compatible again
+with current versions of LibreOffice and LilyPond.
+
+However, as the LibreOffice ecosystem has changed substantially it is
+now possible to rewrite the extension with Python and PyQt.  This will
+not only be more powerful in general but will allow the integration of
+functionality from @uref{http://frescobaldi.org, Frescobaldi}, such as
+for example syntax highlighting, entry helpers, score wizards or musical
+transformations.
+
+@strong{Difficulty:} easy/medium
+@strong{Requirements:} Python, PyQt, LilyPond basics, LibreOffice
+extension basics
+@strong{Recommended knowledge:} Familiarity with Frescobaldi code based
+or willingness to learn during bonding period
+@strong{Mentor(s):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)
 
-@strong{Requirements:} C++, experience with writing heuristics
+@divEnd
 
-@strong{Recommended knowledge:} LilyPond knowledge, aesthetic sense
+@divClass{column-center-middle-color3}
+@subheading Automated testing and documentation for openLilyLib
+
+@uref{https://github.com/openlilylib, openLilyLib} is an extension
+framework for LilyPond code providing a “snippets” repository and a
+suite of integrated packages such as for example page layout tools or
+scholarly annotations.  It is very powerful and promising, but to really
+get off the ground two features are missing: automated testing and
+documentation generation.
+
+Automated testing is necessary to ensure modifications to functionality
+don't break other functions within the library.  There is already some
+Automated Testing of the “snippets” repository with Github's Travis
+server, but this has to be reconsidered and extended to cover the
+standalone packages too.
+
+In order to be usable for a wider range of LilyPond users on a “consumer
+level” openLilyLib needs proper documentation.  This documentation has
+to be generated from the sources, so a system is needed that requires
+package authors to document the input files and provide additional usage
+examples, from which documentation is generated.  Ideally but not
+necessarily this is implemented as a Git hook, i.e. automatically upon
+each update to the repository.  We don't prescribe the tools and
+approaches to be used, but the most widely used language in the LilyPond
+domain is Python, so there would be some bias towards that.
+Alternatively a Scheme solution could be fine so generating the
+documentation would actually be triggered by “compiling” a certain
+LilyPond input file.  In general it is advisable to make use of proven
+concepts and tools from other languages.
+
+The eventual output of the documentation should be a static HTML site
+that can be viewed locally and/or uploaded to a website.  But it would
+be beneficial if the tool would first generate an intermediate
+representation (e.g. a JSON file with additional media files) from which
+a Single Page Application could retrieve content for display on
+openLilyLib's @uref{https://openlilylib.org, website}.  Development of
+such a SPA @emph{can} be part of the GSoC project, but is optional.
 
-@strong{Mentor(s):} Mike Solomon
+@strong{Difficulty:} medium
+@strong{Requirements:} Python or Scheme, static website generator(s) or
+(Node.js based) dynamic web application technology. Continuous
+Integration (can be learned during the bonding period)
+@strong{Mentors:} Urs Liska, Matteo Ceccarello
 
-@subheading Adding special variant of font glyphs
-Adding on-staff-line, between-staff-line, shorter and narrower variants
-of some glyphs, for example accidentals, together with a generic
-infrasctucture to support them.  An example is ancient notation breve notehead
-coming in two variants, with smaller and bigger hole.
+@divEnd
 
-@strong{Difficulty:} easy
+@divClass{column-center-middle-color3}
+@subheading MusicXML
 
-@strong{Requirements:} MetaFont, C++, good eye for details
+Improving MusicXML import and export functions:
 
-@strong{Recommended knowledge:} basic LilyPond knowledge
+File interchange between LilyPond and other applications using MusicXML is still
+a difficult matter. To import MusicXML it has to be converted manually by
+mysicxml2ly. Export is only available as midi file or as a rudimentary feature
+inside Frescobaldi. In order to provide natural interchange between LilyPond
+and MusicXML-based applications there's need of an import functionality
+and an export backend.
 
-@strong{Mentor(s):} Werner Lemberg
+Importing XML shall provide file, line and column to add origin-attributes to
+generated objects. That way point and click can be made available in Frescobaldi
+or other supported IDEs.
 
-@subheading Improve beaming
+Exporting XML shall be realized with an exporter class like the Midi export.
+This may be based on the work already done in
+@uref{https://github.com/DavidGarfinkle/Lilypond_MusicXMLexport, GSoC 2015}
+by David Garfinkle. It should be checked, if it is suitable to use another
+XML-library than the one provided by guile-2, so that this feature is
+available in current LilyPond - based on guile-1.8.
 
-Default positioning of regular, cross-staff, broken and kneed beams
-should be improved.  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, reduce beaming computation time.
 
 @strong{Difficulty:} medium
+@strong{Requirements:} MusicXML, Python, Scheme, basic LilyPond knowledge
+@strong{Recommended:} Familiarity with other scorewriters (for cross-testing)
+@strong{Mentor:} Jan-Peter Voigt
 
-@strong{Requirements:} C++, experience with writing heuristics
 
-@strong{Recommended knowledge:} aesthetic sense
 
-@strong{Mentor(s):} Mike Solomon, Carl Sorensen
+@divEnd
+
+@divClass{column-center-middle-color2}
+@subheading Information for Applicants/Participants
 
-@subheading Better tablature support
+In order to have a satisfying experience with GSoC applicants are
+strongly advised to thoroughly read the following recommendations.  Some
+of these are relevant for the application process, others for the time
+within the project.
 
-@divClass{keep-bullets}
 @itemize
 
 @item
-non-monotonic string tunings, like Ukulele
+Read all applicable information on the program's website, particularly
+the
+@uref{https://developers.google.com/open-source/gsoc/resources/manual,
+students' manual}.  Make sure you fulfil all of Google's prerequisites
+and are willing to join the program as a full-time commitment over the
+coding period of three months.
 
 @item
-create tablature input mode (currently musical information is entered
-in western-common-music-notation-terms, i.e. @qq{a quarter f sharp note}
-and then converted to tablature) for transcribing medieval lute tablature
+Please get in touch with us as soon as possible if you are interested in
+applying with a project.  Mentor availability may change without notice,
+project proposals may need fine-tuning, and many other reasons might
+require us to reject or ignore an application that hasn't been discussed
+before.
 
 @item
-implement modern tablature features, such as bends, pull-off, hammer-on
+We do not know in advance how many “slots” we will have available for
+projects, so please be aware that you may find yourself in competition
+with other applicants or not.  Interested or even enthusiastic response
+from our mentors is no guarantee of eventually being accepted, and
+@emph{not} being accepted does not necessarily indicate a negative
+evaluation of your application.  If we have to decide between different
+applicants there may be various aspects to consider.
 
 @item
-if a fretboard shape is defined for a given chord, use this information when
-displaying the chord on the staff (and not just display a default chord shape)
-
-@end itemize
-@divEnd
-
-@strong{Difficulty:} easy
-
-@strong{Requirements:} C++
-
-@strong{Recommended knowledge:} tablature notation familiarity
-
-@strong{Mentor(s):} Carl Sorensen
+Integration in the LilyPond community is a fundamental part of GSoC, and
+we expect our students to make substantial efforts to become community
+members.  Within the @emph{bonding period} we expect you to write a blog
+post about your project (either on @uref{http://lilypondblog.org, Scores
+of Beauty} or on any other blog) and to be active on our mailing lists,
+introducing yourself but also communicating about unrelated tasks.  This
+goes beyond the mere setting up of a working environment and
+familiarizing yourself with the relevant code, but we think it is
+crucial for the GSoC project to be mutually satisfying.
 
-@subheading Clean up various compilation warnings
-
-Clean up compiler warnings, static code analysis, and valgrind warnings.
-Automatic code analysis tools (warnings in @code{g++} and @code{clang})
-and analysis tools like valgrind memory leak detection and callgrind code
-profilers provide valuable information about possible flaws in C++ code.
-Cleaning these warnings would allow us to automatically reject any patch
-which introduced extra warnings.
+@item
+If you are accepted to the program you will have one mentor explicitly
+assigned to your project.  With this mentor you will have to agree upon
+a communication strategy, be it emails, chatrooms, issue trackers or
+voice/video chats.  Regular communication is absolutely crucial for the
+success of a GSoC project so you are stricly required to keep talking to
+your mentor.  But keep in mind that your mentor has explicitly taken
+over the responsibility for your project, and while unlike you he isn't
+paid for this activity you are still entitled to get regular attention
+from him.
 
-@strong{Difficulty:} medium
+@item
+In order to get support from your mentor you have to give him a chance
+to follow your progress and efforts.  Therefore it is important to
+regularly commit your changes to the versioning repository you are
+working on.  Don't hesitate making unfinished code available because you
+are afraid of criticism, and don't suppress questions because you think
+they might be considered stupid.  But ideally your code should at any
+time be accompanied by compatible testing code.  Your mentor may not be
+able to properly assess your code by only @emph{reading} it without the
+opportunity to apply it in a real example.
 
-@strong{Requirements:} C++
+@end itemize
 
-@strong{Mentor(s):} Joe Neeman, Reinhold Kainhofer
+There is a list of inactive projects in the @ref{Attic}.  We list
+projects there that are still considered valuable but for which there
+are currently no mentors available.
 
 @divEnd
 
-
-
-
 @node Authors
 @unnumberedsec Authors
 
@@ -1144,6 +1286,16 @@ which introduced extra warnings.
 @divEnd
 @divEnd
 
+@node Acknowledgements
+@unnumberedsec Acknowledgements
+
+@divClass{column-center-top}
+@subheading Acknowledgements
+
+@divClass{keep-bullets}
+@acknowledgementsCurrent
+@divEnd
+@divEnd
 
 
 @node Publications
@@ -1172,18 +1324,16 @@ which introduced extra warnings.
 @contactUsAbout{academic papers}
 
 
-@node Old news
-@unnumberedsec Old news
+@node News
+@unnumberedsec News
 
-@divClass{heading-center}
-@warning{Many old announcements and changelogs can be found in
-the @ref{Attic}}
-@divEnd
-
-@include web/news-front.itexi
-
-@include web/news.itexi
+@include web/news-new.itexi
 
+@divClass{column-center-bottom}
+@subheading Old News
+Older news can be found in the @ref{Attic}, along with older
+announcements and changelogs
+@divEnd
 
 @node Attic
 @unnumberedsec Attic
@@ -1192,28 +1342,57 @@ the @ref{Attic}}
 @subheading Announcements
 
 Announcements and news by version:
+@uref{http://lilypond.org/doc/v2.16/Documentation/web/index#Lilypond-2_002e16_002e0-released_0021-August-24_002c-2012-1,v2.16},
+@uref{http://lilypond.org/doc/v2.14/Documentation/web/index#LilyPond-2_002e14_002e0-released_0021-June-6_002c-2011,v2.14},
 @miscLink{announce-v2.12,v2.12},
-@miscLink{announce-v2.12.de,v2.12 (German)},
-@miscLink{announce-v2.12.es,v2.12 (Spanish)},
-@miscLink{announce-v2.12.fr,v2.12 (French)},
 @miscLink{announce-v2.10,v2.10},
 @miscLink{announce-v2.8,v2.8},
 @miscLink{announce-v2.6,v2.6},
 @miscLink{announce-v2.4,v2.4},
 @miscLink{announce-v2.2,v2.2},
 @miscLink{announce-v2.0,v2.0},
-@miscLink{NEWS-1.4,v1.4},
-@miscLink{NEWS-1.2,v1.2 (1)},
-@miscLink{ANNOUNCE-1.2,v1.2 (2)},
+@miscLink{ANNOUNCE-1.2,v1.2},
 @miscLink{ANNOUNCE-1.0,v1.0},
 @miscLink{ANNOUNCE-0.1,v0.1}
 
+Descriptive list of changes by version:
+@uref{http://lilypond.org/doc/v2.16/Documentation/changes/index.html,v2.16},
+@uref{http://lilypond.org/doc/v2.14/Documentation/changes/index.html,v2.14},
+@uref{http://lilypond.org/doc/v2.12/Documentation/topdocs/NEWS,v2.12},
+@uref{http://lilypond.org/doc/v2.10/Documentation/topdocs/NEWS,v2.10},
+@uref{http://lilypond.org/doc/v2.8/Documentation/topdocs/NEWS,v2.8},
+@uref{http://lilypond.org/doc/v2.6/Documentation/topdocs/NEWS,v2.6},
+@uref{http://lilypond.org/doc/v2.4/Documentation/topdocs/out-www/NEWS,v2.4},
+@uref{http://lilypond.org/doc/v2.2/Documentation/topdocs/out-www/NEWS,v2.2},
+@uref{http://lilypond.org/doc/v2.0/Documentation/topdocs/out-www/NEWS,v2.0},
+@uref{http://lilypond.org/doc/v1.8/Documentation/topdocs/out-www/NEWS,v1.8},
+@uref{http://lilypond.org/doc/v1.6/Documentation/out-www/NEWS,v1.6},
+@miscLink{NEWS-1.4,v1.4},
+@miscLink{NEWS-1.2,v1.2}
+
 @divEnd
 
-@divClass{column-center-bottom}
+@divClass{column-center-middle-color3}
+@subheading Thanks
+
+Thanks to developers, contributors, bug hunters and suggestions for
+@miscLink{THANKS-2.16,v2.16},
+@miscLink{THANKS-2.14,v2.14},
+@miscLink{THANKS-2.12,v2.12},
+@miscLink{THANKS-2.10,v2.10},
+@miscLink{THANKS-2.8,v2.8},
+@miscLink{THANKS-2.6,v2.6},
+@miscLink{THANKS-2.4,v2.4},
+@miscLink{THANKS-2.2,v2.2},
+@miscLink{THANKS-2.0,v2.0},
+@miscLink{THANKS-1.8,v1.8}
+
+@divEnd
+
+@divClass{column-center-middle-color3}
 @subheading Changelogs
 
-Changelogs by version:
+Developers' changelogs by version:
 @miscLink{ChangeLog-2.10,v2.10},
 @miscLink{ChangeLog-2.3,v2.3},
 @miscLink{ChangeLog-2.1,v2.1},
@@ -1228,3 +1407,79 @@ Changelogs by version:
 @miscLink{CHANGES-0.0,v0.0}
 
 @divEnd
+
+@divClass{column-center-middle-color2}
+@subheading Unused Google Summer of Code project suggestions
+
+The following list describes GSoC projects that had been proposed
+in recent years and which are still considered valuable but for
+which we currently don't have mentors available.
+
+@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
+
+
+@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
+
+@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 section 2.2 of
+@uref{http://imslp.org/wiki/Repository_of_Music-Notation_Mistakes_%28Coulon%2C_Jean-Pierre%29,
+this book}).  If possible also reduce beaming-computation time.
+
+@strong{Difficulty:} medium
+@strong{Requirements:} C++, experience with writing heuristics
+@strong{Recommended knowledge:} aesthetic sense
+
+@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++
+
+@divEnd
+
+@divClass{column-center-middle-color2}
+@subheading Old News
+
+Older news items dating back to July 2003.  Newer news can be found on
+the @ref{News} page.
+@divEnd
+
+@include web/news-old.itexi