Mentors needed for GSoC suggestions

[Urs Liska]

Hi developers,

this is pretty urgent, and I start a new thread for all those who may
not have followed up on
http://lists.gnu.org/archive/html/lilypond-devel/2016-01/msg00139.html.

We want to review our suggestions for Google Summer of Code projects.
But it seems although the projects listed on here:
http://lilypond.org/google-summer-of-code.html are all still valid and
urgent, the majority of them is orphaned with regard to potential mentors.

In order to be able to do an attractive *and* realistic presentation of
possible projects (that we can actively promote then) we should find
people who could volunteer mentoring any of these projects. I don't
think we have to *remove* orphaned projects but at least we should move
them down to the bottom of the page to a kind of "other ideas" list.
So please go through this list and consider them carefully:

1)
Fixing of grace notes
I think this is one of the most embarrassing and longest-standing issues
in LilyPond.
Carl Sorensen is there as a secondary mentor, but we'd need a primary
mentor.

2)
MusicXML Import/export
This project doesn't have *any* mentor ATM.
In addition it is not really clear what could be the actual task of it
as there is a multitude of possible fields to work on. There are several
options, the following being a non-exhaustive list:
- backporting the improvements in musicxml2ly-dev to the main musicxml2ly
- working on MusicXML export through the python-ly appraoch
- following up on last year's GSoC project exporting to MusicXML through
LilyPond/Scheme itself

3)
Improve Slurs and Ties
I think this is one of the actual *engraving* parts that would warrant
most attention, i.e. it is the part that usually requires the most (and
pretty cumbersome) manual post-processing.
There's no mentor available ATM.

4)
Improve default beam positioning
Carl Sorensen would be ready as secondary mentor, but we'd need a
primary one

5)
Help improving compilation behaviour
This is not visible to the end-user but would nevertheless be a good
investment on the long run.
Joe Neeman could imagine being a "backup mentor" but we'd definitely
need a primary mentor.

#####

So these five out of six proposals would have to be "downgraded" if no
mentor(s) volunteer for them.

What is left is the

1)
"Adding variants of font glyphs" project for which Werner Lemberg
volunteers as mentor.

2)
In addition there is a suggestion extending the ScholarLY library which
I would mentor (see
https://codereview.appspot.com/282290043/patch/1/10001 for a description).

3)
And there is a suggestion about adding chord structures that Carl
Sorensen would mentor (see the PS to
http://lists.gnu.org/archive/html/lilypond-devel/2016-01/msg00197.html
for a description).


And finally I have one more suggestion for a project, but I wouldn't
volunteer mentoring it as I don't even know where/how to tackle it.
Consequently I can't really judge if it is suitable as a GSoC project,
but my feeling is it could be considered:

4)
Allow spanners to cross voices
Currently all sorts of spanners (ties, slurs, dynamics, text spanners,
trills etc.) have to be ended in the same context they were started.
However, this doesn't reflect the reality of notation in most polyphonic
settings. Awkward workarounds with hidden voices are currently necessary
to achieve cross-voice spanners.
New ways of addressing this issue should be invented, for example by
allowing a "target context" specifying where to look for endings or by
explicitly defining IDs of the targeting grob (this is BTW an option how
spanners can be encoded in MEI). This is not at all about engraving -
which is already possible - so none of the complexities of actual
engraving code are involved.
This feature would solve a *lot* of problems that are commonly faced
with piano music and presumable other polyphonic instruments. And it
would make a *lot* of hacks obsolete that are now necessary when working
with the part combiner. So I would be really happy to see progress here.

Best
Urs