On 15/11/10 01:35, Russell Keith-Magee 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.
It was ticket state, not closing state (sorry about the reply lag!). I
guess it's more that I don't like closing bugs purely because they've
not got enough information - it gives the wrong impression in my mind (I
only close once I have positive affirmation that it is invalid,
worksforme, etc.)
This is, I suspect, more a relic of the way I use Trac. I'm fine with a
closing state as well, I just feel like closing tickets before we even
know what they are sends the wrong impression.
On the other hand, we want to keep the trac as cruft-free as possible,
so I suppose closing tickets is fine in that regard. The ticket state
proposal has merit in that it can be crafted so that someone replying to
a ticket in needsinfo state moves it back into a "normal" state, thus
needing the minimum level of Trac competency from the reporter, and not
presenting a rather imposing "ticket closed!!!" interface - getting to a
project's ticket and finding it closed deters me from replying a lot
more than finding it in a "needsinfo" state.
Andrew
--
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.
