From: Urs Liska
Date: Tue, 24 Jan 2017 09:27:11 +0000 (+0100)
Subject: 5042: Web: GSoC: Add openLilyLib project suggestion
X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=909988faa0d04a3176a71120c57573d9f84bf8f3;p=lilypond.git
5042: Web: GSoC: Add openLilyLib project suggestion
---
diff --git a/Documentation/web/community.itexi b/Documentation/web/community.itexi
index 69e30954b2..5a4d81f957 100644
--- 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