On 5 February 2011 15:42, Graham Percival <[email protected]> wrote: > > Addendum in case anybody misunderstands: let's assume that > Reinhold has 30 minutes of spare time to work on lilypond. That's > enough time to: > - write docs for this part-combine feature. > or > - create a new draft of his patch for "keeping state in > part_combine_engraver", which sounds like a powerful new > feature for \partcombine > or > - review Joe's "optimizations for pure-hight approximations", > which appears to cut the compile time of large scores by 50%. > > Now, out of those options, almost anybody can write docs. It can > certainly be done if we combine Xavier writing initial stuff, > Colin doing some cleanup, and then James reviewing the patch on > Reitveld. But none of those people (AFAIK) can provide a serious > review of Joe's "cut compile time in half" patch. > > So the most efficient use of our meager resources is to encourage > experts like Reinhold to work on programming tasks, and to keep a > "vaccum" of minor doc tasks for helpful users to tackle.
OK, but there is still a problem in current "policy", isn't it? I mean, without this request on LilyPond French Users mailing list, what would have happened ? Reinhold implemented these new features more than 4 months ago, without documenting them in the [notation] manual (as current policy). If I would not have answered to this user on the French Users mailing list, thus noticing these new features were not documented, they would have remained undocumented (forgotten?), or… > - create a new draft of his patch for "keeping state in > part_combine_engraver", which sounds like a powerful new > feature for \partcombine OK, this is far beyond me. Should I have a look at Reinhold's PATCH 1698054, try to understand the new commands in order to do this "mundane doc task"? Or should I wait because this new patch for "keeping state in part_combine_engraver" may induce some changes in the way part-combination decision will be done? Cheers, Xavier -- Xavier Scheuer <[email protected]> _______________________________________________ bug-lilypond mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-lilypond
