I like the idea of needmoreinfo as a resolution, which makes it clear to the reporter that they need to take the next step to re-open the ticket with more info. I don't think that closed with "invalid" and a comment makes this as clear.
However, I think there's another problem area where we need to be able to make it clear that someone needs to take the next step, and that is when a ticket has been "accepted", feedback has been given to the reporter, and the reporter has actioned that feedback (e.g. by uploading a patch with tests and docs as per the feedback). In this case the ticket will often languish in "accepted" for months (or years). Since it is frowned upon for a reporter to mark their own ticket as RFC, there's no way for the reporter to flag the ticket as feedback actioned and put it back in the court of the original triager or core developer who accepted it and gave their feedback, who can then either push it up to RFC or commit it themselves. Cheers. Tai. On Nov 15, 12:35 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > 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.
