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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
