On Thu, Jun 10, 2010 at 2:37 PM, David Kastrup <[email protected]> wrote: > Graham Percival <[email protected]> writes: > >> If you >> can't reject the report for having no Tiny example, no version number, >> not being able to reproduce it, etc., then you MUST move on to the >> final point, namely adding it to the tracker. > > I should think that asking for the missing information (with copy on the > bug list so that other members of the squad might be aware of the > response) should be a valid option as well.
That's already point 5 on the list: http://kainhofer.com/~lilypond/Documentation/contributor/bug-squad-checklists.html (using kainhofer temporarily because that change isn't in the official docs until 2.13.24) > For the sake of not eventually getting swamped by leftovers, "add it to > the tracker" would likely be a better choice over "make a mental note to > ask for more information Real Soon Now (TM)". Yes. > 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 there's a Tiny example and the user explains why the output is incorrect, it goes into the tracker and the Bug Squad should forget about about that issue. They're not programmers, they're not supposed to be programmers. They should ignore that issue until a programmer marks it "fixed" and the next release is made; at that point, they verify that the fix worked (or not). If there isn't a Tiny example, or if the user didn't clearly explain why the output was bad, or any of the other points in the checklist, then they reject the report. By "reject", I mean "write back to the user, cc'd to the list, asking for more information". But then it's no longer the responsibility of the Bug Squad; it's the respnosibility of the user to come back with a better example / more info / whatever. Cheers, - Graham _______________________________________________ bug-lilypond mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-lilypond
