On Mon, Nov 19, 2012 at 12:53:07AM +0000, Colin Hall wrote: > On Sun, Nov 18, 2012 at 05:51:10PM -0500, Ralph Palmer wrote: > > On Sun, Nov 18, 2012 at 4:56 PM, Colin Hall <colingh...@gmail.com> wrote: > > > > And Colin, could you point me to a refresher course in bug listing? Or > > should I just check the LilyPond docs? > > Just use the LilyPond CG here: > > http://www.lilypond.org/doc/v2.17/Documentation/contributor/issues > > I wrote some notes for Joseph when he started; I'll forward those on > if I can retrieve them.
See below for the notes I sent to Joe Wakeling, amended with some comments from Graham Percival. Cheers, Colin. The purpose of the bug squad is maintaining the Issue Tracker, in particular filtering out invalid bug reports and detecting fresh reports of known issues. My experience is that this is extremely time consuming at first. I was doing 5 to 10 hours per week in the early months. Yes, I think an hour a week is more likely once you have settled into it. You should read the Issues section of the Contributor's Guide: http://lilypond.org/doc/v2.17/Documentation/contributor/issues Ideally, dealing with a report goes like this: At 0 mins: You start reading the bug report. At 2 mins: You've had a think and one of the following applies: a) It looks like a bug. b) You're not sure. c) It is clearly invalid (see docs for validity tests) For each case, proceed as follows. Case (a) It looks like a bug. Spend up to 2 mins searching the issue tracker in case this is a known bug. If it's a new one, create a tracker. Reply to the post with a link to the tracker (the new tracker, or the existing one for a known bug), which is important so that the rest of the squad can see it has been dealt with. Case (b) You're not sure. Reply to the post asking for one of the devs to comment, or clarification from the OP. Case (c) It is clearly invalid (see docs for validity tests) Reply to the OP explaining why it is invalid. Be kind. If you can see what they have missed then make helpful suggestions. And you're done! This way you can keep it down to 8 to 12 mins per bug report. I like to keep the tone of the mailing list extremely polite, even at the risk of seeming a bit false at times. I think it is important to thank people for their reports and to also thank the devs when they pitch in with workarounds and descriptions of correct usage. Joseph asked if it is typically necessary or desirable for the bug squad to try and reproduce the bug. Graham suggested: If there's a report specific to an operating system you don't have, then of course you don't need to reproduce it. But if the report is a good Tiny example, say > > \version "2.14.1" > { > % middle tie looks funny here: > <c' d'' b''>8. ~ <c' d'' b''>8 > } then I'd would like it if you reproduced that bug and uploaded a --preview png showing the problem. We have scripts that help you do this. Joseph also asked if there were any recommendations for the appropriate setup here, given that people may be working with different versions, OS, etc.? To which I replied: I generally treat the Linux versions as definitive. I use a Win7 64-bit thin client laptop to a physical 32-bit Ubuntu machine and a VirtualBox 64-bit ubuntu on the same laptop, so those are the three test systems I have readily available. -- Colin Hall _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
