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