On Sun, Nov 14, 2010 at 5:22 PM, Andrew Godwin <and...@aeracode.org> wrote: > On 13/11/10 16:52, Daniel Moisset wrote: >> >> Hi, >> while working on the sprint today doing triaging we noticed that a >> lot of tickets were in the "Unreviewed" state because actually there's >> not enough information to move it to any other state (they can not be >> neither accepted/DDNd nor closed). In most cases we sent a reply back >> to the submitter asking for more details about their problem, but the >> ticket remains in the "Unreviewed" state, still taking the time of >> other triagers looking for tickets to review. >> >> Many projects have a "need information" state to report this >> situation. I think adding this to the ticket state diagram [1] would >> be helpful for triagers, and to developers reviewing the ticket list >> and wanting to know how many tickets actually need to be looked at >> before a release. >> >> What are the thoughts of the core team on this? > > We have this on the South trac, and it helps me greatly in filtering views > to just tickets that need my attention/responses instead of just getting > confronted with "all open tickets". You can also set it up so the default > action once you're in infoneeded is to move out of it, so it shouldn't even > cause more work for responders as they have to change the state back - it > just does. > > I'm +1 on adding this, but that's definitely biased by the fact that it > makes the two Tracs I use on a regular basis more similar.
To be clear, Andrew -- are you +1 to a "Needs Info" closing condition, or a "Needs info" ticket state? For me, it all hinges on whether a you consider that a reported issue should be open or closed by default. I tend towards "closed" by default, simply because our Trac instance is already a graveyard of old tickets. The history of Django's Trac instance doesn't suggest that an incomplete bug report will be updated after initial reporting; unless the reporter is a known member of the community, if a ticket isn't complete at time of reporting, it isn't going to get any better. To that end, I'm not sure what a Needs Info ticket state gains us. If someone opens a ticket that doesn't contain enough useful debugging information, we should be closing the ticket, not keeping it open for eternity in the hope that they'll come back and provide the detail they should have provided in the first place. If the reporter *is* inclined to provide more information, a "needs info" close state gives them an indication that the ball is in their court, differentiating between closed "Invalid" (i.e., You're wrong) and closed "WorksForMe" (i.e., can't reproduce), while keeping the ticket out of our working list until such time as they provide the missing details. So; I'm +0 to a close state, -0 to a ticket state. I'm +0 because this is already possible right now -- close "invalid" with a comment that indicates the ticket should be reopened if the reporter can provide more details. However, I can see that there might be a slight advantage to communicating that with something other than a comment. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
