From 909988faa0d04a3176a71120c57573d9f84bf8f3 Mon Sep 17 00:00:00 2001 From: Urs Liska Date: Tue, 24 Jan 2017 10:27:11 +0100 Subject: [PATCH] 5042: Web: GSoC: Add openLilyLib project suggestion --- Documentation/web/community.itexi | 46 +++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) 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 -- 2.39.2