On Sat, Jun 05, 2010 at 06:32:55PM +0200, James Bailey wrote: > > On 05.06.2010, at 11:48, Graham Percival wrote: > >> I've updated CG 7 Issues: >> http://kainhofer.com/~lilypond/Documentation/contributor/issues.html > > Maybe it's simply how I process information, but I think of the list at > 7.1 as: > Is #1 true? Yes, proceed. No? Go to #2 > Is #2 true? Yes, proceed. No? Go to #3…
Aye, that's definitely the intent. > Given that order of operations, I think it would make more sense for the > ordering to be: > 1, 3, 4, 5, 2, 6 (or something along those lines). Maybe this is just me > trying to impose my understanding onto something that already makes sense > as it is. To save people looking it up: #2 is "tell the user to make a Tiny example if it isn't already". Based on our discussions yesterday, I had the impression that we still wanted to reject bug reports if the user hadn't made a Tiny example. In other words, if somebody sends the first movement of their symphony and says "the 2nd horn part in bar 37 looks bad", we immediately reject it and tell them to create a Tiny example. (without even looking at bar 37, or trying to figure out if it's already in the tracker, etc) As a policy question, I have no strong feelings -- I'm not going to be doing this work. As a doc-writing question, I'm happy that this portion of the CG is clear, so we can have one discussion (now) about this. (of course, nothing in the CG should imply that you can't do more work if you want to -- if you feel like examining a large score, or making a Tiny example because you like the person, or you want to encourage speakers of your native language, or because he's also writing for ditheridoo and you want more lilypond-published ditheridoo music in the world... go right ahead! My only concern in the CG is that we have a written policy of what Bug Squad members should be expected to do, mainly so that potential volunteers have a better idea of what they're getting into.) Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
