+@node Google Summer of Code
+@unnumberedsec Google Summer of Code
+@translationof Google Summer of Code
+
+@divClass{column-center-top}
+@subheading ¿Qué es el Google Summer of Code (Verano del Código de Google)?
+
+@uref{https://summerofcode.withgoogle.com/, GSoC} es un programa
+global que ofrece a estudiantes una ayuda para que trabajen en
+proyectos de software de fuentes abiertas durante las vacaciones
+de verano. Durante tres meses, los estudiantes trabajan para
+completar una tarea dada como parte de la comunidad del proyecto y
+bajo la guía de mentores con experiencia. El programa es una
+excelente oportunidad para que los estudiantes obtengan
+experiencia en el desarrollo de software en el mundo real y hagan
+contribuciones que beneficie a todos. Atrae a colaboradores
+nuevos y anima a los estudiantes que ya participan en el
+desarrollo de LilyPond a que se impliquen aún más. LilyPond
+participa en el GSoC como parte del @uref{http://www.gnu.org/,
+proyecto GNU}.
+
+Hemos tenido participantes en el GSoC en 2012, 2015 y 2016 y
+animamos a los estudiantes a que envíen la solicitud para el
+programa de 2017.
+
+Si está interesado en presentarse al programa con LilyPond como
+proyecto, le rogamos que lea la información que aparece más abajo
+y que no dude en escribirnos a la lista de desarrolladores (véase
+@ref{Contacto}). El plazo de solicitud para estudiantes es desde
+el 20 de marzo hasta el 3 de abril de 2017, pero le recomendamos
+encarecidamente que se ponga en contacto con nuestra comunidad con
+antelación.
+
+@divEnd
+
+@divClass{column-center-bottom}
+@subheading Lista de ideas del proyecto
+
+Más abajo aparece una lista de GSoC project ideas (última
+actualización: enero de 2017), pero si tiene otras ideas para un
+proyecto que pueda completar en el plazo de tres meses del
+programa, se le invita a formular la sugerencia sobre nuestra
+lista de correo de desarrolladores (véase @ref{Contacto}).
+Existen varias áreas en las que LilyPond se puede mejorar, y
+nuestro equipo de desarrollo siempre está dispuesto a ayudar a los
+que desean enfrentarse a un proyecto similar a los que aparecen
+relacionados más abajo. Ya que la disponibilidad de los mentores
+varía de proyecto en proyecto y de un año a otro, lo más sensato
+es ponerse en contacto con nosotros lo antes posible.
+
+Hay una lista completa de todas las incidencias abiertas
+@uref{http://sourceforge.net/p/testlilyissues/issues/, aquí}.
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Mejora de la estructura interna de acordes
+
+La representación interna de los acordes de LilyPond no es lo
+bastante potente como para captar la nomenclatura de los acordes
+de jazz. Actualmente el acorde tiene una fundamental, un bajo y
+una inversión. Sería bueno poder manejar acordes múltiples o
+superpuestos, menor/mayor, etc. Para hacerlo, debe desarrollarse
+una representación interna con la capacidad de capturar la esencia
+de los acordes más complejos. Además, una vez que se haya
+desarrollado la representación interna, el formato de salida de
+los nombres de acorde puede mejorarse.
+
+@strong{Dificultad:} Fácil/intermedia
+@strong{Requisitos:} Scheme (Guile), pero el nivel necesario puede
+aprenderse fácilmente
+@strong{Conocimientos recomendados:} Teoría y nomenclatura de los acordes
+@strong{Mentor:} Carl Sorensen
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Adoptar el estándar SMuFL de codificación de tipografías
+
+Desde hace varios años circula un nuevo estándar para las fuentes
+tipográficas de música: @uref{http://www.smufl.org/, SMuFL}, que
+también se estudia como parte de un futuro estándar del W3C para
+la codificación de música. Como herramienta FLOSS, LilyPond
+debiera unirse a este estándar en lugar de usar una solución
+aislada como hace actualmente. La adopción de SMuFL ayudaría a
+integrar LilyPond con el mundo del software de notación musical y
+al final daría a los usuarios de LilyPond acceso a una más amplia
+selección de fuentes tipográficas de notación.
+
+Hacer que LilyPond cumpla el estándar SMuFL consiste en la
+reasignación de los glifos que se construyen a partir de código
+fuente de METAFONT, el ajuste de las métricas de los glifos a las
+especificaciones de SMuFL, y finalmente la actualización de la
+forma en que LilyPond localiza y posiciona los glifos. Como parte
+opcional de este proyecto, podría modificarse el mecanismo de
+carga de las fuentes por parte de LilyPond para que usara las
+fuentes de notación instaladas como fuentes del sistema en lugar
+de hacerlo dentro de la instalación de LilyPond.
+
+@strong{Dificultad:} Baja/media
+@strong{Requisitos:} C++ y disposición para familiarizarse con el funcionamiento interno de LilyPond.
+@strong{Conocimientos recomendados:} Interés y experiencia en el trabajo con archivos de fuentes tipográficas. Un poco de METAFONT.
+@strong{Mentores:} Werner Lemberg, Abraham Lee
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Añadir una variante especial de los glifos de fuente tipográfica
+
+@divClass{keep-bullets}
+@itemize
+
+@item
+Añadir variantes @q{sobre} y @q{entre} líneas del pentagrama.
+
+@item
+Variantes más bajas y estrechas de ciertos glifos, como
+alteraciones alccidentales. Otro ejemplo más específico sería una
+cabeza de nota breve de la notación antigua en dos variantes, una
+con un hueco pequeño dentro, y otra con un hueco grande.
+
+@end itemize
+@divEnd
+
+@strong{Dificultad:} fácil
+@strong{Requisitos:} MetaFont, C++, buen ojo para los detalles
+@strong{Conocimientos recomendados:} conocimientos básicos de LilyPond
+@strong{Mentor potencial:} Werner Lemberg
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Notación contemporánea
+
+LilyPond es muy bueno creando notación no estándar. Tener que
+@emph{codificar} cada uno de los elementos gráficos en lugar de
+simplemente @emph{dibujarlo} puede parecer engorroso pero de hecho
+es una gran virtud. Se pueden implementar funcionalidades
+notacionales nuevas con apariencia consistente, disposición
+automática y una interfaz sintáctica natural.
+
+Dentro del sistema de biblioteca
+@uref{https://github.com/openlilylib/oll-core, openLilyLib} el
+alumno creará una infraestructura fundamental y unos bloques
+constructivos para hacer más fácil la creación de notación
+contemporánea. Además (al menos) @emph{un} paquete en concreto se
+desarrollará para cubrir alguna notación contemporánea específica,
+como por ejemplo el estilo de algún compositor dado, técnicas de
+ejecución extendidas para un instrumento específico o una cierta
+categoría de efectos.
+
+@strong{Dificultad:} media
+@strong{Requisitos:} Scheme (interacción con las interioridades de LilyPond),
+técnicas de notación contemporánea
+@strong{Conocimientos recomendados:} habilidad para la elaboración de marcos de funcionamiento jerárquicos
+@strong{Mentores:} @strong{NN,} Urs Liska
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Reescritura de la extensión de LilyPond para LibreOffice con Python
+
+La extensión @uref{http://ooolilypond.sourceforge.net/,
+OOoLilyPond} hace posible incluir de forma muy práctica fragmentos
+de partitura de LilyPond dentro de documentos de
+OpenOffice.org/LibreOffice Writer, Draw e Impress, manteniendo al
+mismo tiempo la fuente y la imagen juntas. Después de muchos años
+sin desarrollo, se ha iniciado una tarea de hacer de nuevo que la
+extensión sea compatible con las versiones actuales de LibreOffice
+y de LilyPond.
+
+Sin embargo, según el ecosistema de LibreOffice ha cambiado
+significativamente, ahora es posible reescribir la extensión con
+Python y PyQt. Esto no solo será más potente en general, sino que
+permitirá la integración de funcionalidades de
+@uref{http://frescobaldi.org, Frescobaldi}, tales como el
+resaltado de sintaxis, facilidades durante la escritura,
+asistentes de partitura o transformaciones musicales.
+
+@strong{Dificultad:} baja/media
+@strong{Requisitos:} Python, PyQt, conceptos básicos de LilyPond y
+de extensiones de LibreOffice
+@strong{Conocimientos recomendados:} Familiaridad con la base de
+código de Frescobaldi o disposición para aprenderla durante el
+período fijado
+@strong{Mentor(es):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Pruebas y documentación automatizadas para 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{Dificultad:} media
+@strong{Requisitos:} 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{Mentores:} Urs Liska, Matteo Ceccarello
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading MusicXML
+
+Mejora de las funciones de importación y exportación de MusicXML:
+
+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{Dificultad:} media
+@strong{Requisitos:} MusicXML, Python, Scheme, basic LilyPond knowledge
+@strong{Conocimientos recomendados:} Familiarity with other scorewriters (for cross-testing)
+@strong{Mentor:} Jan-Peter Voigt
+
+@divEnd
+
+@divClass{column-center-middle-color2}
+@subheading Información para los solicitantes o participantes
+
+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.
projects / lilypond.git / blobdiff