Re: Quit [now definitely O/T]

[Graham Percival]

On Thu, Nov 12, 2009 at 05:32:26PM -0500, Chris Snyder wrote:
> I think my experience does illustrate the care necessary in shepherding  
> new developers. I think the LilyPond developer community would do well  
> to treat newbies with kid gloves - contributing to a project for the  
> first time can be intimidating. The Frogs program is a good step, but  
> it's not very well publicized.

I think your "mistake" -- which was quite a natural response --
was to send the patch to lilypond-devel.  One of the ideas behind
the Frogs is that Carl could gently suggest some improvements
privately; then you could send it to the frog mailist for more
general viewing; and then (and only then!) you could send it to
-devel.

One problem with this model is that Carl (and other people on the
frog list) don't know a lot about the lilypond internals, so your
patch might make it all the way to -devel before getting rejected
due to major architectural grounds.  I have no answer to that,
other than "each time this happens, Carl + the frogs will learn
more about the general architecture, and can then spot such
problems earlier".

I agree that the Frogs should be better publicized... but that
just brings me back to the new website.


>> If we had a perfect code-formatting tool, we could just run the files
>> through the tool.  But we don't.
>
> I vaguely remember some discussion on this at one point, but I can't  
> find anything in the mailing list archives. I'd like to do some  
> investigating as to what tools are available - it would save a lot of  
> headache.

There's an issue on the tracker about this; I think it has a link
or two.  (I hope it does, at least)

It would be great if you *could* investigate this.  Spending days
fluffing around with indentation is a totally stupid waste of
time.  Quite apart from the literal waste of time (it's a task a
computer can do!), as you know, it's highly demoralizing.  To
everybody involved; experienced developers hate rejecting patches
due to whitespace issues.

This is literally one of the biggest problems for new/learning
developers.  I think the website + Frog publicity is more
important, but getting this automated is probably #3.


>> I didn't even know that.  I hope we can get this documented.  Would you be
>> willing to take a stab at how events are passed to engravers (or how various
>> routines inside an engraver are called from outside the engraver)?
>
> Perhaps this could be part of a developer tutorial that details creating  
> a new engraver from scratch? I'm envisioning a LM-equivalent for the CG  
> with the same relationship that the LM has to the NR (the full names of  
> which must not be named).

If it's something that a user might do, put it in Extending.  If
not, put it in the CG.

If you won't want to merge it with CG 8 (or whichever one is about
programming), we could add a chapter just for programmming.  I
mean, programming knowledge, rather than programming
style/languages.

Cheers,
- Graham