Re: Quit [now definitely O/T]

[Chris Snyder]

As a frequent LilyPond user (25-50% of my day job) and aspiring 
contributor, I'd like to throw in my two cents (USD, so not worth much - 
sorry).

Over the past year, I've submitted patches on occasion for possible 
inclusion in the trunk. On one occasion (accidentals in chords not 
spaced properly), I spent quite a bit of time implementing a solution 
proposed by one core developer, which took quite a bit of time 
(including a steep learning curve, which I'll discuss below), only to 
have another core developer reject it out of hand as being the wrong 
approach. The rejection left a bad taste in my mouth - it was fairly 
terse, and didn't acknowledge the wasted effort I had expended. Not 
surprisingly, I haven't found the motivation to touch that code again.

Over the past couple of days, I've been working on fixing a couple of 
bugs that were caused by an earlier bug fix I submitted (that was 
accepted). Joe Neeman has given me very constructive comments and asked 
for reasonable improvements. At times, however, I've been struck by the 
level of perfection required for patches such as mine, which seem to be 
much higher than the current code. For instance, I was asked to correct 
some indentation - never mind the fact that the code right around my 
patch was indented incorrectly (I thought about fixing the whole file, 
but didn't want to add noise to the patch set).

As I mentioned above (and others have mentioned), the learning curve for 
developing is quite steep. I applaud the effort by Graham et al to 
improve the documentation, especially the Contributor's Guide, which has 
been a big help even in its incomplete form. However, a lot of the code 
is difficult to follow - when is stop_translation_timestep called in 
engravers, for instance? It took me a while to understand that it will 
be called even due to rhythms in other voices besides the one the 
engraver is interested in.

A common response to questions about the code is to 
RTFlilypond-devel_archives, which can be helpful. The problem that I've 
found here is that often I'll find outdated discussions that describe 
the code as it worked in 2001 instead of now, and it's difficult to 
determine when the behavior changed.

I understand the frustration inherent in helping newbies (until you've 
had to explain to an 85-year-old customer how to find the Start menu in 
Windows, you haven't seen anything<g>), and I understand that a big 
problem is the lack of person-hours to improve the developer 
documentation. However, a change in tone could go a long ways toward 
recruiting and maintaining developers - instead of "RTFlilypond-devel, 
n00b!" how about, "Thanks for your willingness to help. Unfortunately, 
we don't have a lot of documentation for that right now. There were some 
discussions on lilypond-devel about it a while back that should give you 
some guidance, though be aware that the behavior changed in the fall of 
2004, so disregard anything before that. And feel free to come back with 
any further questions."

Of course, my accusation doesn't apply to all of the LilyPond 
developers, some of whom have been very helpful and pleasant to work 
with. The reason that I'm still hanging around, however, is a testament 
more to the quality of the product than to any welcoming atmosphere in 
the community.

(sorry if this message doesn't thread well - I couldn't figure out a 
good place in the conversation to reply to directly)

Chris Snyder
Adoro Music Publishing
1-616-828-4436 x800
http://www.adoromusicpub.com