From: Federico Bruni Date: Fri, 31 Mar 2017 06:44:13 +0000 (+0200) Subject: web: move Google Summer of Code information in included/ X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=3f5d679ade0f797d5f907569656223d09b09d5db;p=lilypond.git web: move Google Summer of Code information in included/ So translators can choose not to translate this node of community.itexi. GSoC page gets quite frequent updates and keeping the translations up-to-date may be cumbersome and not worth the effort (as GSoC applicants are required to speak english). Issue 5112. --- diff --git a/Documentation/included/gsoc.itexi b/Documentation/included/gsoc.itexi new file mode 100644 index 0000000000..78eb25f274 --- /dev/null +++ b/Documentation/included/gsoc.itexi @@ -0,0 +1,402 @@ +@c -*- coding: utf-8; mode: texinfo; -*- +@c This file is part of community.itexi +@c It's been moved here to reduce maintenance burden on translators. It's up +@c to translators the choice of translating this section of community.itexi or +@c not (as GSoC students are required to speak english, a translated page is +@c not needed). + +@c Current proposals for Google Summer of Code +@macro gsocCurrent + +@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 bigger-subsubheadings} +@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}. + + +@subsubheading 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. + +@emph{Difficulty:} Easy/medium + +@emph{Requirements:} Scheme (Guile), but the level necessary can be +easily learned + +@emph{Recommended:} Chord theory and naming + +@emph{Mentor:} Carl Sorensen + + +@subsubheading 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. + +@emph{Difficulty}: Easy/medium + +@emph{Requirements}: C++ and willingness to get familiar with LilyPond +internals. + +@emph{Recommended}: Interest and experience in working with font files. +A little bit of METAFONT. + +@emph{Mentors}: Werner Lemberg, Abraham Lee + + +@subsubheading 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 + +@emph{Difficulty:} easy + +@emph{Requirements:} MetaFont, C++, good eye for details + +@emph{Recommended knowledge:} basic LilyPond knowledge + +@emph{Mentor:} Werner Lemberg + + +@subsubheading 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. + +@emph{Difficulty:} medium + +@emph{Requirements:} Scheme (interaction with LilyPond internals), +contemporary notation techniques + +@emph{Recommended:} sense of building hierarchical frameworks + +@emph{Mentors:} @emph{NN,} Urs Liska + + +@subsubheading 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. + +@emph{Difficulty:} easy/medium + +@emph{Requirements:} Python, PyQt, LilyPond basics, LibreOffice +extension basics + +@emph{Recommended knowledge:} Familiarity with Frescobaldi code based +or willingness to learn during bonding period + +@emph{Mentor(s):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice) + + +@subsubheading 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. + +@emph{Difficulty:} medium + +@emph{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) + +@emph{Mentors:} Urs Liska, Matteo Ceccarello + + +@subsubheading 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). + +@emph{Difficulty:} medium + +@emph{Requirements:} MusicXML, Python, Scheme, basic LilyPond knowledge + +@emph{Recommended:} Familiarity with other scorewriters (for cross-testing) + +@emph{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 +@end macro + + +@c Inactive proposals for Google Summer of Code +@macro gsocInactive +@subheading Inactive 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. + + +@subsubheading 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. + +@emph{Difficulty:} hard + +@emph{Requirements:} C++, experience with writing heuristics + +@emph{Recommended knowledge:} LilyPond knowledge, aesthetic sense + + +@subsubheading 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. + +@emph{Difficulty:} medium + +@emph{Requirements:} C++, MIDI + +@emph{Recommended:} familiarity with LilyPond internals + + +@subsubheading 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. + +@emph{Difficulty:} medium + +@emph{Requirements:} C++, experience with writing heuristics + +@emph{Recommended knowledge:} aesthetic sense + + +@subsubheading 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. + +@emph{Difficulty:} medium + +@emph{Requirements:} C++ + +@end macro diff --git a/Documentation/web/community.itexi b/Documentation/web/community.itexi index 2f4cf32720..eea46827a2 100644 --- a/Documentation/web/community.itexi +++ b/Documentation/web/community.itexi @@ -9,6 +9,7 @@ @include included/acknowledge.itexi @include included/authors.itexi +@include included/gsoc.itexi @include included/helpus.itexi @node Community @@ -882,330 +883,8 @@ manuals can be found at @url{http://lilypond.org}} @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 bigger-subsubheadings} -@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}. - - -@subsubheading 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. - -@emph{Difficulty:} Easy/medium - -@emph{Requirements:} Scheme (Guile), but the level necessary can be -easily learned - -@emph{Recommended:} Chord theory and naming - -@emph{Mentor:} Carl Sorensen - - -@subsubheading 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. - -@emph{Difficulty}: Easy/medium - -@emph{Requirements}: C++ and willingness to get familiar with LilyPond -internals. - -@emph{Recommended}: Interest and experience in working with font files. -A little bit of METAFONT. - -@emph{Mentors}: Werner Lemberg, Abraham Lee - - -@subsubheading 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 - -@emph{Difficulty:} easy - -@emph{Requirements:} MetaFont, C++, good eye for details - -@emph{Recommended knowledge:} basic LilyPond knowledge - -@emph{Mentor:} Werner Lemberg - - -@subsubheading 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. - -@emph{Difficulty:} medium - -@emph{Requirements:} Scheme (interaction with LilyPond internals), -contemporary notation techniques - -@emph{Recommended:} sense of building hierarchical frameworks - -@emph{Mentors:} @emph{NN,} Urs Liska - - -@subsubheading 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. - -@emph{Difficulty:} easy/medium - -@emph{Requirements:} Python, PyQt, LilyPond basics, LibreOffice -extension basics - -@emph{Recommended knowledge:} Familiarity with Frescobaldi code based -or willingness to learn during bonding period - -@emph{Mentor(s):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice) - - -@subsubheading 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. - -@emph{Difficulty:} medium - -@emph{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) +@gsocCurrent -@emph{Mentors:} Urs Liska, Matteo Ceccarello - - -@subsubheading 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). - -@emph{Difficulty:} medium - -@emph{Requirements:} MusicXML, Python, Scheme, basic LilyPond knowledge - -@emph{Recommended:} Familiarity with other scorewriters (for cross-testing) - -@emph{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 @@ -1414,68 +1093,7 @@ Developers' changelogs by version: @divEnd @divClass{column-center-middle-color2 bigger-subsubheadings} -@subheading Inactive 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. - - -@subsubheading 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. - -@emph{Difficulty:} hard - -@emph{Requirements:} C++, experience with writing heuristics - -@emph{Recommended knowledge:} LilyPond knowledge, aesthetic sense - - -@subsubheading 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. - -@emph{Difficulty:} medium - -@emph{Requirements:} C++, MIDI - -@emph{Recommended:} familiarity with LilyPond internals - - -@subsubheading 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. - -@emph{Difficulty:} medium - -@emph{Requirements:} C++, experience with writing heuristics - -@emph{Recommended knowledge:} aesthetic sense - - -@subsubheading 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. - -@emph{Difficulty:} medium - -@emph{Requirements:} C++ - +@gsocInactive @divEnd @divClass{column-center-middle-color2}