5042: Web: GSoC: Add openLilyLib project suggestion

diff --git a/Documentation/web/community.itexi b/Documentation/web/community.itexi
index 69e30954b249ae6505482759999adbe87969248e..5a4d81f9574dfd9df820a67d416c7aa374f43522 100644 (file)
--- a/Documentation/web/community.itexi
+++ b/Documentation/web/community.itexi
@@ -1028,6 +1028,52 @@ Carl Sorensen
 
 @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{Mentor:} Urs Liska
+
+@divEnd
+
 @divClass{column-center-middle-color3}
 @subheading Help improve compilation behavior