On Thu, Jun 10, 2010 at 4:38 PM, David Kastrup <[email protected]> wrote: > Graham Percival <[email protected]> writes: > >> On Thu, Jun 10, 2010 at 2:37 PM, David Kastrup <[email protected]> wrote: >> >>> And of course, adding more information is done _automatically_ when >>> someone responds to the tracked report. So adding to the tracker >>> with a canned phrase "Small example, and error symptom still missing" >>> might well be a safe choice in any case. >> >> I don't know what you mean by "error symptom still missing". If [...] >> the user explains why the output is incorrect, > > That's the error symptom. Probably "error syndrome" would have been a > more proper term. Sorry.
I had to look up "syndrome" on wikipedia, but I see what you mean. I disagree, though -- I would prefer to put the onus on the bug reporter. Once the issue is in the tracker, there's no urgency for the initial reporter to add more info. The key is to respond to the issue quickly. This works quite well; I did it for a year or two. As long as there's a reply and an actual discussion happens, users are happy to provide more information, explanations, and the rest. It's when they don't hear anything for days, weeks, or months that they get (justifiably) upset. That's why I keep on harping on the "find a reason to reject the report" idea -- if there's a clear-cut policy reason to "reject" a report, then the Squad member can reply immediately, or within 30 seconds, or something. But the key is to *reply*, instead of letting reports pass them by. On this point I'm going to use whatever veto power you give me. I'm convinced it will work; I did it this way for months and it worked just fine. If the Bug Squad adopts this method and it's failing over the course of 3-4 months, I'll be wiling to re-open the discussion, but not until then. Cheers, - Graham _______________________________________________ bug-lilypond mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-lilypond
