trac: please bring back 'reopen'
Michael Radziej
somehow the reopen button went on vacation with the trac udate--can
anyone call it back? It would be very appreciated by ticket #3320 ;-)
(At least, I cannot reopen from closed/invalid)
Cheers!
Michael
--
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
Jacob Kaplan-Moss
> somehow the reopen button went on vacation with the trac udate--can
> anyone call it back? It would be very appreciated by ticket #3320 ;-)
>
> (At least, I cannot reopen from closed/invalid)
Very interesting - it looks like that action is being hidden from
non-authenticated users... I'll investigate.
Jacob
Ramiro Morales
It's me or the "type" field (defect, enhancement, ...) of a ticket is
also missing?.
The wiki main page has been vandalized and need to be reverted to revision 250.
Regards,
--
Ramiro Morales
Jeremy Dunck
>
> Hi,
>
> somehow the reopen button went on vacation with the trac udate--can
> anyone call it back? It would be very appreciated by ticket #3320 ;-)
>
> (At least, I cannot reopen from closed/invalid)
Michael, I see that ticket was closed as invalid because it needed to
pass tests.
If I understand the triage process correctly, it should have been
marked accepted, but with has_patch=1 and patch_needs_improvement=1.
http://www.djangoproject.com/documentation/contributing/#ticket-triage
I'm sticking my nose in here because I hope to join as a triager
shortly, and because either the process isn't clear, or I'm missing
something.
Jacob, do you mind some hand-holding while we're learning the process?
Jacob Kaplan-Moss
> It's me or the "type" field (defect, enhancement, ...) of a ticket is
> also missing?.
We got rid of that field, along with a couple of other fields we don't really
use. In this specific case, besides not using it, the line between "defect"
and "enhancement" never really was clear vis a vis Django.
> The wiki main page has been vandalized and need to be reverted to
> revision 250.
Fixed, thanks.
Jacob
Michael Radziej
Jeremy Dunck wrote:
>
> On 1/18/07, Michael Radziej <m...@noris.de> wrote:
>>
>> Hi,
>>
>> somehow the reopen button went on vacation with the trac udate--can
>> anyone call it back? It would be very appreciated by ticket #3320 ;-)
>>
>> (At least, I cannot reopen from closed/invalid)
>
> Michael, I see that ticket was closed as invalid because it needed to
> pass tests.
>
> If I understand the triage process correctly, it should have been
> marked accepted, but with has_patch=1 and patch_needs_improvement=1.
Yeah, your're basically right, and I thought some time about it. I felt
that it would make more sense to close it and wait for more input, then
later decide how to proceed. The closing isn't meant as a rejection but
as a request to reply and then reopen the ticket.
The ticket is about upgrading simplejson with no particular bug or
problem as a reason. If I'd have a working patch, I'd straight pass it
on to the developers (Ready for Checkin). If I don't, I'd leave it to
the developers if they really want to upgrade (Design Decision Needed).
But I can't decide with a patch that looks good but has some probably
trivial bug. That's why I passed it back, and it seemed to work out.
Actually, I find myself needing some time to evolve the best way to deal
with all the tickets. I tend to put a lot of the tickets into the stage
"Design Decision Needed", and that's not so useful.
Any more opinions on this? I'm rather open for comments and still
finding my way.
Michael
Gary Wilson
> Jeremy Dunck wrote:
> > Michael, I see that ticket was closed as invalid because it needed to
> > pass tests.
> >
> > If I understand the triage process correctly, it should have been
> > marked accepted, but with has_patch=1 and patch_needs_improvement=1.
>
> Yeah, your're basically right, and I thought some time about it. I felt
> that it would make more sense to close it and wait for more input, then
> later decide how to proceed. The closing isn't meant as a rejection but
> as a request to reply and then reopen the ticket.
I agree with Jeremy here.
> The ticket is about upgrading simplejson with no particular bug or
> problem as a reason. If I'd have a working patch, I'd straight pass it
> on to the developers (Ready for Checkin). If I don't, I'd leave it to
> the developers if they really want to upgrade (Design Decision Needed).
>
> But I can't decide with a patch that looks good but has some probably
> trivial bug. That's why I passed it back, and it seemed to work out.
I would say a ticket should be closed as invalid only if there wasn't
enough information in the ticket subject + description to understand
what the problem is.
> Actually, I find myself needing some time to evolve the best way to deal
> with all the tickets. I tend to put a lot of the tickets into the stage
> "Design Decision Needed", and that's not so useful.
I think the number of tickets put into the design decision needed
category is inevitable. Ultimately, the decisions must be made by the
community or the people with the power to decide. This stage is the
bottleneck of the system for most tickets, as it takes either precious
core-developer time or hashing out in the community. Hopefully, this
whole triage system will allow the decision makers to more efficiently
make decisions, or at least point them to where their time is needed :)
Michael Radziej
Gary Wilson wrote:
> I would say a ticket should be closed as invalid only if there wasn't
> enough information in the ticket subject + description to understand
> what the problem is.
Do you disagree about the "invalid" vs. "wontfix", or about closing?
If it's the latter ... first, forget about this specific case (it's
solved, now, anyway). Let's look at a ticket where I ask the reporter
for further information that would be helpful for the core for further
decisions, but not essential (e.g., see #3298, but I've left it open for
now). IMHO, it shouldn't go into stage "Needs Decision" before the
information arrives.
I had a private mail with Jacob before the new system started about how
to handle cases like this, and his solution was to close it as invalid
or wontfix and the reporter reopen it when s/he replies. This type of
close is meant to be only temporary (assuming that reopen will be back
soon ;-)
The basic idea is (and this is *my* interpretation), we have enough
tickets. We probably have more tickets than we can process, even with
triaging. There's no use in keeping tickets when the reporter has lost
the interest in helping with it. (Of course this depends, and some bugs
are really, really imporant.)
Jacob, do I express this correctly?
Michael
Jacob Kaplan-Moss
> The basic idea is (and this is *my* interpretation), we have enough
> tickets. We probably have more tickets than we can process, even with
> triaging. There's no use in keeping tickets when the reporter has lost
> the interest in helping with it. (Of course this depends, and some bugs
> are really, really imporant.)
>
> Jacob, do I express this correctly?
That's about the size of it, yeah.
Basically: if there's not enough information attached to the ticket to act on
it, it should be closed INVALID or WORKSFORME. That'll serve two purposes:
* It'll force people with actual problems to better describe them if they want
their tickets to stay open.
* It'll keep tickets that aren't actionable out of the lists.
The key word here is "actionable" -- for a ticket to be open, there needs to
be a next action.
Let's look at a few examples taken somewhat randomly:
#3279: should be closed, obviously. There's no information other than a
revision range.
#3298: should stay open, but barely. If the OP hadn't at least tracked it
down to max_age, the ticket should be closed. As is it's on the edge since
we've got no idea which phone or browser it is. It really could go either way.
#760: should stay open. There's almost no information, nor is there a
suggested fix, but it's an easily confirmable problem, and thus actionable.
Hopefully that should shed some light on it.
Jacob
SmileyChris
> IMHO, it shouldn't go into stage "Needs Decision" before the
> information arrives.
I'm not a fan of instantly closing tickets while waiting for
information but I see the point Jacob/Micheal is expressing.
It would be great to have a GTD-like system, where all tickets start
out "unreviewed" but can be moved on to some other state (or just
closed) no matter what. Perhaps we need another triage state?
Alternatively, (if it's possible) perhaps another close state which
clearer defines why it has been closed.
SmileyChris
> > (At least, I cannot reopen from closed/invalid)
> Very interesting - it looks like that action is being hidden from
> non-authenticated users... I'll investigate.
How's the investigation going? I'm apprehensive of closing tickets
requiring more info until this gets fixed.
Gary Wilson
Reopening a ticket should probably also set the triage stage back to
unreviewed.
Until this is resolved, I suggest to add a keyword of "reopen" to
tickets to that need reopening, which then could be found with:
http://code.djangoproject.com/query?status=closed&keywords=%7Ereopen&order=priority
I was going to add this to the report page, but it seems like the page
has been locked down.
Michael Radziej
Gary Wilson schrieb:
> SmileyChris wrote:
>> On Jan 19, 2:29 am, Jacob Kaplan-Moss <j...@jacobian.org> wrote:
>>>> (At least, I cannot reopen from closed/invalid)
>>> Very interesting - it looks like that action is being hidden from
>>> non-authenticated users... I'll investigate.
>> How's the investigation going? I'm apprehensive of closing tickets
>> requiring more info until this gets fixed.
>
> Reopening a ticket should probably also set the triage stage back to
> unreviewed.
Hmm, I usually have an eye on the timeline and will have a look on
changes that modify the stage.
> Until this is resolved, I suggest to add a keyword of "reopen" to
> tickets to that need reopening, which then could be found with:
> http://code.djangoproject.com/query?status=closed&keywords=%7Ereopen&order=priority
That's a good idea!
> I was going to add this to the report page, but it seems like the page
> has been locked down.
Some playkid has already made attachements, so this was made sense.
Michael