Translation of GIT committish: FILL-IN-HEAD-COMMITTISH
When revising a translation, copy the HEAD committish of the
- version that you are working on. See TRANSLATION for details.
+ version that you are working on. For details, see the Contributors'
+ Guide, node Updating translation committishes..
@end ignore
-@include web/basic-authors.itexi
+@include included/acknowledge.itexi
+@include included/authors.itexi
+@include included/helpus.itexi
@node Community
@unnumbered Community
+@divClass{link-headings}
@divClass{column-center-top}
@subheading Interacting with the community
@item
@ref{Help us}: your assistance is requested.
+@item
+@ref{Sponsoring}: financial contributions.
+
@item
@ref{Development}: for contributors and testers.
+@item
+@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
@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,
+old news, etc.
@end itemize
@divEnd
+@divEnd
@divClass{hide}
@menu
* Tiny examples::
* Bug reports::
* Help us::
+* Sponsoring::
* Development::
+* Google Summer of Code::
* Authors::
+* Acknowledgements::
* Publications::
-* Old news::
+* News::
+* Attic::
@end menu
@divEnd
@warning{When asking questions, please use @ref{Tiny examples}!}
+@subsubheading LilyPond Snippet Repository
+
+The LilyPond Snippet Repository is a large collection of
+user-submitted examples, which can freely be copied and used
+in your own works. See what other people have written,
+and add your own!
+
+@example
+@uref{http://lsr.di.unimi.it}
+@end example
+
+Particularly instructive examples from LSR are included in our
+official documentation, in @ref{Snippets}.
+
@subsubheading IRC
@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,
-Portugese group}
+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
+@subheading The LilyPond Blog
-@subsubheading LilyPond Report
+Read our community blog, @q{Scores of Beauty}:
-The easiest way to keep touch is by reading our community
-newsletter, the @uref{http://news.lilynet.net/, LilyPond Report}.
+@example
+@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
+@subsubheading Translation mailing list: @code{translations@@lilynet.org}
+
+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
@node Tiny examples
@divClass{column-center-top}
@subheading What are @qq{Tiny examples}?
-A tiny example is an example from which nothing can be removed.
+A tiny example is an example from which @strong{nothing} can be removed.
@divEnd
@divClass{column-left-bottom}
understand it and help you.
@item
-A simple example demonstrates that you have put effort towards
+A tiny example demonstrates that you have put effort towards
solving the problem yourself. When people send huge portions of
-input, it looks like they don't care how if we help them or not.
+input, it looks like they don't care if we help them or not.
@item
-Creating a tiny example forces you to understand what is
+Creating a tiny example helps you to understand what is
happening. Many false problem reports can be avoided by
attempting to create a tiny example; if you cannot replicate a
@qq{bug} in a tiny example, then the problem was probably an
@divClass{column-right-bottom}
-@subheading How do I create them?
+@subheading How to create them?
@divClass{keep-bullets}
@itemize
@item
-Include the \version number.
+Include the @code{\version} number.
@item
Make it small! Examples about spacing or page layout might
require many bars of music, but most issues can be reproduced
-using only a single measure.
+using less than a single measure.
@item
When trying to create an example, try commenting out @w{(@code{%}
-or @code{%@{ @dots{} %@}})} sections of your file. If you can
-comment something while still demonstrating the main idea, then
-remove the commented-material!
+or @code{%@{ @dots{} %@}})} sections of your file. If you
+can comment something while still demonstrating the main idea,
+then remove the commented-material.
@item
-Avoid using complicated notes, keys, or time signatures, unless
+Avoid using complicated notes, keys or time signatures, unless
the bug is about the behavior of those items.
@item
Do not use @code{\override} or @code{\set} commands unless the bug
-is about those particular commands.
+is about those specific commands.
+
+@item
+Optionally, attach an image showing the desired graphical output.
@end itemize
@divEnd
@divEnd
+@divClass{column-center-bottom}
+@subheading How tiny should they be?
+
+Is the code below a minimal example?
+
+@example
+\version "2.14.1"
+\include "english.ly"
+
+\score @{
+ \new Staff @{
+ \key d \major
+ \numericTimeSignature
+ \time 2/4
+ <cs' d'' b''>16 <cs' d'' b''>8.
+ %% Here: the tie on the D's looks funny
+ %% Too tall? Left-hand endpoint is not aligned with the B tie?
+ ~
+ <cs' d'' b''>8 [ <b d'' a''> ]
+ @}
+@}
+@end example
+
+Well, it is not very big, but a truly minimal example is here:
+
+@example
+\version "2.14.1"
+@{
+ % middle tie looks funny here:
+ <c' d'' b''>8. ~ <c' d'' b''>8
+@}
+@end example
+Very few tiny examples exceed 10 lines of code -
+quite often 4 lines are enough to demonstrate the problem!
+
+@divEnd
@node Bug reports
@unnumberedsec Bug reports
+
+@divClass{heading-center}
+If you have input that results in a crash or wrong output,
+then that is a bug.
+@divEnd
+
@divClass{column-center-top}
@subheading Step 1: Known bugs
-If you have input that results in a crash or an erroneous output,
-then that is a bug. There is a list of current bugs on our google
-bug tracker,
+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-left-bottom}
@subheading Step 2: Creating a bug report
-If you have discovered a bug which is not listed, please help us
-by creating a bug report.
+If you have discovered a bug which is not listed,
+please help us by creating a bug report.
-@warning{We only accept bug reports in the form of @ref{Tiny
-examples}. We have very limited resources to deal with bug
-reports, so any non-minimal example will be rejected. Almost
+@warning{We only accept reports in the form of
+@ref{Tiny examples}. We have very limited resources,
+so any non-minimal example will be rejected. Almost
every bug can be demonstrated in four notes or less!}
Here is an example of a good bug report:
@example
-%% the octavation command doesn't
-%% change the output at all!
-
-\version "2.10.0"
-\paper@{ ragged-right=##t @}
-\relative c''' @{
- c1
- #(set-octavation 1)
- c1
+% Accidentals should be printed for only
+% the first note in a tie, but this version
+% prints flats on both notes.
+\version "2.10.1"
+
+\relative c'' @{
+ bes1 ~
+ bes1
@}
@end example
Once you have verified that the issue is not already known and
created a bug report, please send it to us!
-Unfortunately there is a strict @qq{no top-posting} check on the
-bug list, which is often incorrectly triggered by lilypond files.
-To avoid this, please add
+@divClass{keep-bullets}
+@itemize
+
+@item
+If you are subscribed to the @uref{mailto:bug-lilypond@@gnu.org,
+bug-lilypond@@gnu.org} mailing list, send an email like normal.
+
+@item
+If you are not subscribed, you can still post a bug report with
+the
+@uref{http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.bugs,
+gmane lilypond.bugs web interface}.
+
+However, there is a strict @qq{no top-posting} check on the gmane
+interface, which is often incorrectly triggered by lilypond files.
+To avoid this, please add:
@example
> I'm not top posting.
@end example
@noindent
-(you must include the @code{>} ) to the top of your bug report.
+(you @emph{must} include the @code{>} ) to the top of your bug
+report.
-@uref{http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.bugs,
-Post with the gmane lilypond.bugs interface}, or send an email to
-@uref{mailto:bug-lilypond@@gnu.prg, bug-lilypond@@gnu.org}.
+@end itemize
+@divEnd
+@divEnd
+
+@divClass{column-center-bottom}
+@subheading Step 4: Wait for a response
+
+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.
+
+Once a bug has been added to the tracker, you can comment it to add
+more information about it.
+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}
+@subheading Optional help: show the desired behavior
-Once your bug has been sent to the list, our Bug Meister will
-examine the report. He may ask you for more information, or may
-add the report to the tracker and let you know what the issue
-number is.
+Once an issue has been added to the tracker, it can be very
+helpful if we can see the desired output. Feel free to add input
+code and/or images (possibly created with other tools) which
+demonstrate what you think it should look like!
-You may mark the bug so that you automatically receive emails when
-any activity on the bug occurs. This requires you have a google
-account.
@divEnd
+
@node Help us
@unnumberedsec Help us
@divClass{column-center-top}
-@subheading We need you!
-
-The LilyPond development team is quite small; we really want to
-get more people involved. Please consider helping your fellow
-LilyPond users by contributing to development!
-
-Even working on small tasks can have a big impact: taking care
-of them let experienced developers work on advanced tasks, instead
-of spending time on those simple tasks.
+@helpusNeed
@divEnd
-
@divClass{column-left-top}
-@subheading Simple tasks
-
@divClass{keep-bullets}
+@helpusSimple
-@itemize
-@item
-Mailing list support: answer questions from fellow users.
-
-@item
-Bug reporting: help users create proper @ref{Bug reports}, and aid
-the Bug Team in handling @rcontrib{Issues}.
+@divEnd
+@divEnd
-@item
-Documentation: small changes can be proposed by following the
-guidelines for @rcontrib{Documentation suggestions}.
+@divClass{column-right-top}
+@helpusAdvanced
-@item
-LilyPond Snippet Repository (LSR): create and fix snippets. See
-@rcontrib{Adding and editing snippets}.
+@divEnd
-@item
-Discussions, reviews, and testing: the developers often ask for
-feedback about new documentation, potential syntax changes, and
-testing new features. Please contribute to these discussions!
-@end itemize
+@node Sponsoring
+@unnumberedsec Sponsoring
-@subheading Moderate tasks
+@divClass{keep-bullets}
+@divClass{column-left-top}
+@subheading Bounties
-@warning{These jobs generally require that you have the program
-and documentation source files, but do not require a full
-development environment. See @rcontrib{Starting with git}.}
+In the past,
@itemize
-@item
-Documentation: see
-@rcontrib{Documentation work}, and
-@rcontrib{Building documentation without compiling LilyPond}.
-
-@item
-Website: the website is built from the normal documentation
-source. See the info about documentation, and also
-@rcontrib{Website work}.
-
-@item
-Translations: see @rcontrib{Translating the documentation}, and
-@rcontrib{Translating the website}.
-
+@item some users have paid for new features
+@item some developers have added new features for hire
@end itemize
+The LilyPond project does not organize such efforts; we neither
+endorse nor discourage such agreements. Any contracts between
+private individuals is the business of those individuals, not
+ours.
-@subheading Complex tasks
+@divEnd
-@warning{These jobs generally require that you have the source
-code and can compile LilyPond. See @rcontrib{Starting with git},
-and @rcontrib{Compiling LilyPond}.}
+@divClass{column-right-top}
+@subheading Guidelines
-We suggest that new contributors using Windows use a virtual
-machine to run @emph{lilybuntu}. See
-@rcontrib{Using a Virtual Machine to Compile LilyPond}.
+Any user wanting to offer money in exchange for work should bear
+in mind the following points:
@itemize
@item
-Bugfixes, new features: the best way to begin is to join the
-Frogs, and read @rcontrib{Programming work}.
+LilyPond developers may advertise their services on the lilypond
+email lists from time to time.
+
+@item
+Any agreements between private individuals should include the
+normal precautions when conducting business: who pays, how much do
+they pay, with what method of payment, and upon what set of
+conditions. We suggest that any ambiguity or uncertainty in these
+questions should be resolved before any work begins.
@end itemize
@divEnd
-@divEnd
-
-
-@divClass{column-right-top}
-@subheading Projects
-
-@subsubheading Frogs
-
-Website and mailist: @uref{http://frogs.lilynet.net}
-The Frogs are ordinary LilyPond users who have chosen to get
-involved in their favorite software's development. Fixing bugs,
-implementing new features, documenting the source code: there's a
-lot to be done, but most importantly: this is a chance for
-everyone to learn more about LilyPond, about Free Software, about
-programming... and to have fun. If you're curious about any of
-it, then the word is: @emph{Join the Frogs!}
-
-
-
-@help{not active yet; either comment out or begin these projects
-before 2.14}
-
-@subsubheading Grand LilyPond Input Syntax Standardization
+@divClass{column-center-bottom}
+@subheading Interested developers
-Website: @uref{http://lilypond.org/~graham/gliss}
+Here is a list of people who have expressed an interest in
+bounties. Note that the amount of work done by individuals varies
+quite a bit throughout the years. We do not guarantee that this
+list is up-to-date, nor do we guarantee that the people listed
+here have any ability. The only criteria is "XYZ asked to be
+listed on this page".
-GLISS will stabilize the (non-tweak) input syntax for the upcoming
-LilyPond 3.0. After updating to 3.0, the input syntax for
-untweaked music will remain stable for the foreseeable future.
+Looking at the git history is a good way to determine who the most
+active and experienced developers are. Statistics up to version
+@versionDevel{}:
-We will have an extensive discussion period to determine the final
-input specification.
+@multitable @columnfractions .3 .3 .3
+@item @uref{http://lilypond.org/~graham/gitstats-all/, overall history}
+@tab @uref{http://lilypond.org/~graham/gitstats-1year/, past year}
+@tab @uref{http://lilypond.org/~graham/gitstats-3months/, past three months}
+@end multitable
-@subsubheading Grand Organizing Project
+Interested developers:
+@table @asis
+@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.
-Website and mailist: TODO
+@c Format
+@c @item @email{name@@adress.domain, Name}
+@c area of interest (256 chars max)
-GOP is our big recruiting drive for new contributors.
+@end table
@divEnd
-
-
-@ignore
-@divClass{column-center-bottom}
-@subheading Interested?
-
@divEnd
-@end ignore
@node Development
@unnumberedsec Development
@divClass{heading-center}
-@heading Development materials for LilyPond @versionDevel{}
+@ifclear web_version
+ @heading Development for LilyPond @version
+@end ifclear
+@ifset web_version
+ @heading Development for LilyPond @versionDevel
+@end ifset
+
+@c we normally don't allow named references, but in this case
+@c it's good to emphasize the "stable" part. -gp
@warning{These are @emph{unstable development} versions. If you
have the slightest doubt about how to use or install LilyPond, we
-urge you to use the stable @ref{Download}, and read the stable
-@ref{Manuals}.}
+urge you to use the @ref{Download, stable Download}, and read the
+@ref{Manuals, stable Manuals}.}
@divEnd
@divClass{column-right-top}
@subheading Contributor's Guide
-LilyPond development is a fairly complicated matter. LilyPond is
-a large, (mostly) stable project. In order to help new
-contributors, and to keep the whole system (mostly) stable, we
-have written a manual for contributors.
+LilyPond development is a fairly complicated matter. In order to
+help new contributors, and to keep the whole system (mostly)
+stable, we have written a manual for development tasks.
-@docLinks{Contributor's Guide, contributor,
+@docLinksBare{Contributor's Guide, contributor,
@rcontribnamed{Top,Contributor's Guide},
@manualDevelContributorSplit,
@manualDevelContributorBig, 500 kB,
@divEnd
-@c if Downloads was a bit longer, and/or the CG was a bit shorter,
-@c this would be great as column-right-top. -gp
@divClass{column-center-top}
@subheading Regression tests
@divClass{keep-bullets}
+
+@ifclear web_version
+
@itemize
+@item
+@uref{../../input/regression/collated-files.html, Regression tests}:
+This release's regtests.
+(@uref{../../input/regression/collated-files.pdf, pdf version})
-@item @uref{../../input/regression/collated-files.html, Regression tests}:
-This release's tests. (also in
-@uref{../input/regression/collated-files.pdf, pdf})
+@item
+@uref{../../input/regression/musicxml/collated-files.html, MusicXML tests}:
+This release's musicXML tests.
+(@uref{../../input/regression/musicxml/collated-files.pdf, pdf version})
-@item @uref{../../input/regression/musicxml/collated-files.html,
-MusicXML Regression tests}:
-This release's MusicXML tests. (also in
-@uref{../input/regression/musicxml/collated-files.pdf, pdf})
+@item
+@uref{../../input/regression/abc2ly/collated-files.html, abc2ly tests}:
+This release's abc2ly tests.
+(@uref{../../input/regression/abc2ly/collated-files.pdf, pdf version})
+
+@item
+@uref{../../input/regression/lilypond-book/collated-files.html, lilypond-book tests}:
+This release's lilypond-book tests.
+(@uref{../../input/regression/lilypond-book/collated-files.pdf, pdf version})
+@end itemize
+
+@end ifclear
+
+@ifset web_version
+@subsubheading Development version
+
+@itemize
+@item @regtestDevel (@regtestDevelPdf{})
+
+@item @regtestDevelXml (@regtestDevelXmlPdf{})
-@item @uref{http://lilypond.org/test, Archive of regression tests}:
-Comparisons between versions.
+@item @regtestDevelAbc (@regtestDevelAbcPdf{})
+@item @regtestDevelLilypondBook (@regtestDevelLilypondBookPdf{})
@end itemize
+
+@subsubheading Stable version
+
+@itemize
+@item @regtestStable (@regtestStablePdf{})
+
+@item @regtestStableXml (@regtestStableXmlPdf{})
+
+@item @regtestStableAbc (@regtestStableAbcPdf{})
+
+@item @regtestStableLilypondBook (@regtestStableLilypondBookPdf{})
+@end itemize
+@end ifset
+
+
+@subsubheading All versions
+
+@itemize
+@item @uref{http://lilypond.org/test, Comparisons between regression tests}
+
+@item @uref{http://lilypond.org/downloads/binaries/test-output/,
+Archive of all regression tests}
+
+@end itemize
+
@divEnd
@divEnd
@divClass{column-center-bottom}
@subheading Manuals
+@ifclear web_version
+@warning{These manuals are for LilyPond @version{}; the latest
+manuals can be found at @url{http://lilypond.org}}
+@end ifclear
+
+@divClass{normal-table}
@multitable @columnfractions .3 .3 .3
@headitem Introduction
+
@item
-@manualDevelLearningSplit
+@docLinkSplit{Learning,learning,@manualDevelLearningSplit}
@tab
-@manualDevelLearningBig
+@docLinkBig{Learning,learning,@manualDevelLearningBig}
@tab
-@manualDevelLearningPdf
+@docLinkPdf{Learning,learning,@manualDevelLearningPdf}
@item
-@manualDevelGlossarySplit
+@docLinkSplit{Glossary,music-glossary,@manualDevelGlossarySplit}
@tab
-@manualDevelGlossaryBig
+@docLinkBig{Glossary,music-glossary,@manualDevelGlossaryBig}
@tab
-@manualDevelGlossaryPdf
+@docLinkPdf{Glossary,music-glossary,@manualDevelGlossaryPdf}
@item
-@manualDevelEssaySplit
+@docLinkSplit{Essay,essay,@manualDevelEssaySplit}
@tab
-@manualDevelEssayBig
+@docLinkBig{Essay,essay,@manualDevelEssayBig}
@tab
-@manualDevelEssayPdf
+@docLinkPdf{Essay,essay,@manualDevelEssayPdf}
+@end multitable
+@multitable @columnfractions .3 .3 .3
@headitem Regular
@item
-@manualDevelNotationSplit
+@docLinkSplit{Notation,notation,@manualDevelNotationSplit}
@tab
-@manualDevelNotationBig
+@docLinkBig{Notation,notation,@manualDevelNotationBig}
@tab
-@manualDevelNotationPdf
+@docLinkPdf{Notation,notation,@manualDevelNotationPdf}
@item
-@manualDevelUsageSplit
+@docLinkSplit{Usage,usage,@manualDevelUsageSplit}
@tab
-@manualDevelUsageBig
+@docLinkBig{Usage,usage,@manualDevelUsageBig}
@tab
-@manualDevelUsagePdf
+@docLinkPdf{Usage,usage,@manualDevelUsagePdf}
@item
-@manualDevelSnippetsSplit
+@docLinkSplit{Snippets,snippets,@manualDevelSnippetsSplit}
@tab
-@manualDevelSnippetsBig
+@docLinkBig{Snippets,snippets,@manualDevelSnippetsBig}
@tab
-@manualDevelSnippetsPdf
+@docLinkPdf{Snippets,snippets,@manualDevelSnippetsPdf}
+@end multitable
+@multitable @columnfractions .3 .3 .3
@headitem Infrequent
@item
-@manualDevelWebSplit
+@docLinkSplit{Web,web,@manualDevelWebSplit}
@tab
-@manualDevelWebBig
+@docLinkBig{Web,web,@manualDevelWebBig}
@tab
-@manualDevelWebPdf
+@docLinkPdf{Web,web,@manualDevelWebPdf}
@item
-@manualDevelChangesSplit
+@docLinkSplit{Changes,changes,@manualDevelChangesSplit}
@tab
-@manualDevelChangesBig
+@docLinkBig{Changes,changes,@manualDevelChangesBig}
@tab
-@manualDevelChangesPdf
+@docLinkPdf{Changes,changes,@manualDevelChangesPdf}
@item
-@manualDevelExtendingSplit
+@docLinkSplit{Extending,extending,@manualDevelExtendingSplit}
@tab
-@manualDevelExtendingBig
+@docLinkBig{Extending,extending,@manualDevelExtendingBig}
@tab
-@manualDevelExtendingPdf
+@docLinkPdf{Extending,extending,@manualDevelExtendingPdf}
@item
-@manualDevelInternalsSplit
+@docLinkSplit{Internals,internals,@manualDevelInternalsSplit}
@tab
-@manualDevelInternalsBig
+@docLinkBig{Internals,internals,@manualDevelInternalsBig}
@tab
-@manualDevelInternalsPdf
+@docLinkPdf{Internals,internals,@manualDevelInternalsPdf}
+@end multitable
+@ifset web_version
+@multitable @columnfractions .3
+@headitem Downloadable
+
+@item
+@doctarballDevel
@end multitable
+@end ifset
+
+
+@divEnd
@divEnd
-@node Authors
-@unnumberedsec Authors
+@node Google Summer of Code
+@unnumberedsec Google Summer of Code
+
+@divClass{column-center-top}
+@subheading What is Google Summer of Code?
+
+@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-middle-color2}
+@subheading Project Ideas List
+
+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.
+
+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
-@help{Under construction; this is not an accurate list!}
+@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
+@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
+
+@divClass{column-center-middle-color3}
+@subheading Contemporary Notation
+
+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.
+
+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.
+
+@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
+
+@divEnd
+
+@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)
+
+@divEnd
+
+@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{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
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading MusicXML
+
+Improving MusicXML import and export functions:
+
+File interchange between LilyPond and other applications using MusicXML
+is still a difficult matter. To import MusicXML it has to be converted
+manually by the @code{musicxml2ly} script. Export @emph{to} MusicXML is
+only available as a rudimentary feature inside Frescobaldi. In order to
+provide natural interchange between LilyPond and MusicXML based
+applications there's the need of actual import functionality and a
+dedicated export backend.
+
+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.
+
+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 possible to use
+another XML library than the one provided by guile-2 in order to have
+this feature available in current LilyPond (which is based on guile-1.8).
+
+@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
+
+@divEnd
+
+@divClass{column-center-middle-color2}
+@subheading Information for Applicants/Participants
+
+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.
+
+@itemize
+
+@item
+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
+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
+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
+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.
+
+@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.
+
+@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.
+
+@end itemize
+
+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
@divClass{column-left-top}
@subheading Current Development Team
@docCurrent
+@subsubheading Bug squad
+
+@bugsquadCurrent
+
@subsubheading Support
@supportCurrent
@docPrevious
+@c uncomment when we have any previous members -gp
+@c @subsubheading Bug squad
+
+@c @bugsquadCurrent
+
@subsubheading Support
@supportPrevious
@divEnd
@divEnd
+@node Acknowledgements
+@unnumberedsec Acknowledgements
+
+@divClass{column-center-top}
+@subheading Acknowledgements
+
+@divClass{keep-bullets}
+@acknowledgementsCurrent
+@divEnd
+@divEnd
@node Publications
@unnumberedsec Publications
@divClass{column-center-top}
-@subheading What we wrote
+@subheading What we wrote about LilyPond
@divClass{keep-bullets}
-@itemize
-@item
-Han-Wen Nienhuys, @emph{LilyPond, Automated music formatting and
-the Art of Shipping}. Forum Internacional Software Livre 2006
-(FISL7.0) (@uref{http://lilypond.org/web/images/FISL7-slides.pdf,
-PDF 1095k})
+@include we-wrote.itexi
-@item
-Erik Sandberg, @emph{Separating input language and formatter in
-GNU Lilypond}. Master's Thesis, Uppsala University, Department of
-Information Technology March 2006.
-(@uref{http://lilypond.org/web/images/thesis-erik-sandberg.pdf,
-PDF 750k})
+@divEnd
+@divEnd
-@item
-Han-Wen Nienhuys and Jan Nieuwenhuizen, @emph{LilyPond, a system
-for automated music engraving}. Proceedings of the XIV Colloquium
-on Musical Informatics (XIV CIM 2003), Firenze, Italy, May 2003.
-(@uref{ http://lilypond.org/web/images/xivcim.pdf, PDF 95k})
+@divClass{column-center-bottom}
+@subheading What people did with LilyPond
-@end itemize
+@divClass{keep-bullets}
+
+@include others-did.itexi
@divEnd
@divEnd
+@contactUsAbout{academic papers}
-@divClass{column-center-bottom}
-@subheading What others wrote
+@node News
+@unnumberedsec News
-@divClass{keep-bullets}
-@itemize
+@include web/news-new.itexi
-@item
-September 2009
+@divClass{column-center-bottom}
+@subheading Old News
+Older news can be found in the @ref{Attic}, along with older
+announcements and changelogs
+@divEnd
-The German LinuxUser magazine wrote an
-@uref{http://www.linux-community.de/Internal/Artikel/Print-Artikel/LinuxUser/2009/10/Digitaler-Notenschluessel,
-article about LilyPond}.
+@node Attic
+@unnumberedsec Attic
+@divClass{column-center-top}
+@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.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{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}
-@item
-February 2008
+@divEnd
-In @uref{http://www.musicbyandrew.ca/finale-lilypond-1.html,
-articles on his personal site}, Andrew Hawryluk compares Finale
-and LilyPond in general terms, and evaluates engraving
-capabilities of both pieces of software in detail. The second
-article is an instructive analysis of engraving issues in
-Rachmaninoff's Piano Prelude No. 6, including comparisons with a
-hand-engraved reference edition.
+@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}
-@item
-June 2006
+@divEnd
-@uref{http://distrowatch.com,DistroWatch} awards LilyPond and
-@uref{http://distrowatch.com/weekly.php?issue=20060605,writes}
-@qq{Ladies and Gentleman, we are pleased to announce that, based
-on readers' requests, the DistroWatch May 2006 donation has been
-awarded to LilyPond (@euro{}190.00) and Lua (US$250.00).}
+@divClass{column-center-middle-color3}
+@subheading Changelogs
+
+Developers' changelogs by version:
+@miscLink{ChangeLog-2.10,v2.10},
+@miscLink{ChangeLog-2.3,v2.3},
+@miscLink{ChangeLog-2.1,v2.1},
+@miscLink{ChangeLog-1.5,v1.5 (1)},
+@miscLink{CHANGES-1.5,v1.5 (2)},
+@miscLink{CHANGES-1.4,v1.4},
+@miscLink{CHANGES-1.3,v1.3},
+@miscLink{CHANGES-1.2,v1.2},
+@miscLink{CHANGES-1.1,v1.1},
+@miscLink{CHANGES-1.0,v1.0},
+@miscLink{CHANGES-0.1,v0.1},
+@miscLink{CHANGES-0.0,v0.0}
-@item
-December 2005
+@divEnd
-@uref{http://linuxjournal.com,Linux Journal} publishes an article
-titled @uref{http://www.linuxjournal.com/article/8364, Make
-Stunning Schenker Graphs with GNU LilyPond}. It is an in-depth
-but hands-on feature article with crisp LilyPond graphics. Author
-Kris Shaffer remarks @qq{GNU Lilypond generates beautiful graphics
-that make commercial alternatives seem second-rate.}
+@divClass{column-center-middle-color2}
+@subheading Unused Google Summer of Code project suggestions
-@item
-August 20, 2005
+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.
-The Belgian newspaper De Standaard investigates what drives Free
-Software authors in an article titled
-@uref{http://www.standaard.be/Artikel/Detail.aspx?artikelId=G42H5GD6,
-Delen van KENNIS zonder WINSTBEJAG} (Non-profit sharing of
-knowlegde) in its @q{DS2 bijlage}. LilyPond is used as an example
-and the article is interspersed with quotes from an email
-interview with Jan Nieuwenhuizen. This marks LilyPond's first
-appearance in mainstream printed press.
+@divEnd
-@item
-June 2005
+@divClass{column-center-middle-color3}
+@subheading Improve slurs and ties
-A French article on the LilyPond 2.6 release appeared on
-@uref{http://linuxfr.org/2005/06/27/19210.html, linuxfr.org}.
+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.
-@item
-October 2004
+@strong{Difficulty:} hard
+@strong{Requirements:} C++, experience with writing heuristics
+@strong{Recommended knowledge:} LilyPond knowledge, aesthetic sense
-The editors of Computer!Totaal, a Dutch computer magazine,
-@uref{http://lilypond.org/web/images/computer-totaal.jpeg,
-describe LilyPond} in the October 2004 issue as: @qq{Wonderful
-free (open source) software [..] The sheet music produced by
-LilyPond is exceptionally pretty [..] a very powerful system that
-can do almost anything.}
-@item
-July, August 2004
+@divEnd
-Dave Phillips wrote an introductory article for
-@uref{http://linuxjournal.com,Linux Journal}: At
-the sounding edge: LilyPond, parts
-@uref{http://www.linuxjournal.com/article/7657, one} and
-@uref{http://www.linuxjournal.com/article/7719, two}.
+@divClass{column-center-middle-color3}
+@subheading Grace notes
-@item
-March 2004
+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.
-Chris Cannam
-@uref{http://www.all-day-breakfast.com/cannam/linux-musician/lilypond.html,interviewed}
-Han-Wen Nienhuys and Jan Nieuwenhuizen on linuxmusician.com
-(original site defunct). This interview was also reviewed in a
-@uref{http://slashdot.org/article.pl?sid=04/03/13/2054227&tid=,
-slashdot story}.
+@strong{Difficulty:} medium
+@strong{Requirements:} C++, MIDI
+@strong{Recommended:} familiarity with LilyPond internals
-@item
-February 2004
+@divEnd
-Jazz singer Gail Selkirk writes about
-@uref{http://www.songbirdofswing.com/editorial_page/lilypond/,
-Diving into LilyPond}. @qq{... you can make lead sheets or full
-orchestral parts, and the results can be stunning.}
-@uref{http://www.computermusic.co.uk/, Computer Music Special},
-issue CMS06.
+@divClass{column-center-middle-color3}
+@subheading Improve default beam positioning
-@end itemize
+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
-@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.
-@node Old news
-@unnumberedsec Old news
+@strong{Difficulty:} medium
+@strong{Requirements:} C++
-@include web/news-front.itexi
+@divEnd
-@include web/news.itexi
+@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