+@strong{Mentores potenciales:} Mike Solomon (not available for GSoC 2016),
+Carl Sorensen
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Mejora del posicionamiento de las barras de corchea (y figuras menores)
+
+Para barras de corchea normales, de pentagrama cruzado,
+interrumpidas y en ángulo. El barrado debería depender del
+contexto y de las notas vecinas (véase la sección 2.2 de
+@uref{http://imslp.org/wiki/Repository_of_Music-Notation_Mistakes_%28Coulon,_Jean-Pierre%29,
+este libro}). Si es posible, reducir el tiempo de cálculo del
+barrado.
+
+@strong{Dificultad:} media
+@strong{Requisitos:} C++, experiencia con heurística de la escritura
+@strong{Conocimientos recomendados:} sentido estético
+@strong{Mentores potenciales:} Mike Solomon (not available for GSoC 2016), Carl Sorensen
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Permitir objetos extensos entre voces distintas
+
+Actualmente, toda clase de objetos extensos (ligaduras de unión y
+de expresión, matices dinámicos, textos extensos, trinos, etc.)
+tienen que terminar en el mismo contexto en que empezaron. Sin
+embargo, esto no refleja la realidad de la notación de la mayoría
+de las configuraciones polifónicas. En la actualidad son
+necesarios extraños rodeos con voces ocultas para conseguir
+objetos de extensión entre voces distintas.
+
+Deberían explorarse nuevas formas de abordar este problema, por
+ejemplo por medio de
+
+@divClass{keep-bullets}
+@itemize
+
+@item la especificación de un "contexto de destino" en el que se espera que termine el objeto
+
+@item la especificación explícita del objeto que termina con un identificador
+
+@end itemize
+@divEnd
+
+Esta funcionalidad resolvería muchos problemas presentes de manera
+habitual con la música para piano y partes combinadas.
+
+@strong{Dificultad:} media (?)
+@strong{Requisitos:} C++, Scheme
+@strong{Mentor potencial:} Urs Liska
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Ayudar a mejorar el comportamiento de la compilación
+
+Las herramientas de análisis automático del código, como la
+detección de filtraciones de memoria de Valgrind o el perfilador
+de código Callgrind, proveen una información valiosa acerca de los
+posibles problemas de nuestro código de C++. La limpieza de estas
+advertencias nos permitiría rechazar automáticamente cualquier
+parche que introdujese más advertencias de las que hay
+actualmente.
+
+@strong{Dificultad:} media
+@strong{Requisitos:} C++
+@strong{Mentores potenciales:} Reinhold Kainhofer (no disponible
+para el GSoC 2016), Joe Neeman