reopening a ticket should set the status to "new"

[gay@…]

steps

1. create a new bug
2. accept the bug (now it falls off the New tickets report because someone has verified it is a real bug and accepted that it is their work item)
3. resolve the bug fixed
4. later someone *thinks* the bug isn't really fixed or some part of it has reopened, so they "reopen" the bug

results

The reopened bug just appears on that person's bug list even though no one has really verified whether reopening the bug was correct or not.

There is no way to see newly "reopened" bugs on their own because all reopened bugs have the same status "reopened" so they get lost.

expected

Reopening a ticket simply sets the status back to "new", so that it can go back through the same procedures as a new ticket. Verifying that it is real and it is assigned to the proper person. It is easy to see all "new" tickets together in one report, whether they are absolutely new or reopened.

Note: this is how bugzilla works.

[Christian Boos]

Replying to gay@recipezaar.com:

2. accept the bug (now it falls off the New tickets report because someone has verified it is a real bug and accepted that it is their work item)

That's an interesting option, discussed at length in #2045. Currently accept is often "abused" to mean "I'm working on it". The corollary of this abuse is that it's difficult to distinguish between valid new tickets and not yet screened ones. Setting a milestone can help here, but it's also clearly an abuse of the milestones, as this is really something which should be visible in the status of the ticket (i.e. new should mean not yet processed).

3. resolve the bug fixed

… so before that you probably want a "in progress" atatus, meaning that work has begun on the ticket (#2217), or a percent complete indicator (#1084), as in FlySpray.

There is no way to see newly "reopened" bugs on their own because all reopened bugs have the same status "reopened" so they get lost.

Here I think I've lost you: it's possible to see the newly "reopened" bugs on their own because they all have the same "reopened" status…

As I mentioned above, new should really mean new, not yet processed at all. You can well decide that a reopened ticket should be processed like a new ticket, but that doesn't mean they are at the same status; it should be possible to easily distinguish between them.

Reopening a ticket simply sets the status back to "new", so that it can go back through the same procedures as a new ticket. Verifying that it is real and it is assigned to the proper person. It is easy to see all "new" tickets together in one report, whether they are absolutely new or reopened.

Well, it's also very easy to set up a report or a custom query which shows the new and reopened tickets together, e.g. query:milestone=&status=new|reopened

So, to summarize: I think we should really come up with a new default WorkFlow, like the one I proposed in comment:ticket:2045:17.

Please follow-up on that ticket if you have additional comments to make about the default workflow.

Note that with the WorkFlow proposal, everyone will be able to have its own workflow … and more ;-)

[gay@…]

wow, I just came back to note a workaround I found and there are comments/resolution on this bug already. thanks!

Workaround

If you save changes on a ticket reassigning it to the same person the status will move from "reopened" to "new".

I can see why you think there is a distinction between truly "new" and "reopened" — there is factually. But from a workflow perspective they are the same. Here's where I think we differ. To me:

new = some (potential dimwit) reported a bug, could be real, could be junk

…someone looks at all new bugs, verifies they are real and assigns them to a person…

accepted = that person acknowledges they know about the bug

…all bugs are assigned to people, but some are low priority or don't have a milestone assigned; the bugs people are working on, are the current milestone bugs or high priority or whatever our team communicates is the current goal…

fixed = the fixer says it is fixed

…this is where I would like to add 2 more statuses, verified (when the tester verifies the fix works) and closed (which the fix is rolled into the build or the production site or someone else confirms the resolution of "fixed:invalid" etc.) but that is a separate issue…

reopened = is when someone claims the fix didn't take, so the bug should really go back to status new and someone has to verify the claims, we it is really the same as new to me.

So I guess I differ from your idea that accepted means actively working on the ticket. But I also don't want to add a bunch more states either (feedback, acknowledged, etc.). Letting the project determine workflow would be great. In the meantime, I've got my workaround and my custom field for verification ;)

[gay@…]

Oh, and so I forgot to mention, I have a report that puts both reopened/new in one list, so I can track what comes in and make sure people are aware of and accepting their bugs. This works for the new bugs; they fall off as people accept them (as they should). It doesn't for reopened bugs. They just sit there forever, and I don't know if anyone has verified the reopening or noticed that it was reopened, because those bugs can just get lost in a big list for someone…

Thus, my workaround, I now save changes on the bug so the status moves from reopened to new again.

[Christian Boos]

Replying to gay@recipezaar.com:

new

ok

accepted = that person acknowledges they know about the bug

see, acknowledges ;-)

fixed = the fixer says it is fixed

…this is where I would like to add 2 more statuses, verified (when the tester verifies the fix works) and closed

ok, this is also commonly requested, not sure if it should be made part of the default workflow, I think we'd better keep it as simple as possible (though this should probably be documented as a sample workflow).

reopened = is when someone claims the fix didn't take, so the bug should really go back to status new and someone has to verify the claims, we it is really the same as new to me.

yes, but the verification is not exactly about the same thing: we already know that the ticket was a valid one, it was already dispatched to someone and to a milestone, etc. It might well be simpler for the original assignee to verify that reopen claim than for a first-line screener…

However I think I see your point now, the "reopen" claim could possibly be a bogus one, like would be an invalid "new" ticket ;)

So I guess I differ from your idea that accepted means actively working on the ticket.

he, no, if you go through #2045, you'll realize it's not mine ;)

But I also don't want to add a bunch more states either (feedback, acknowledged, etc.). Letting the project determine workflow would be great. In the meantime, I've got my workaround and my custom field for verification ;)

Yes, a custom field for verification is the way to go for now. Hopefully the WorkFlow branch will make it for 0.11 (that's still the goal, isn't it?)

[anonymous]

Referring to comment:ticket:2045:20

Can you comment on this ?

[Christian Boos]

Replying to anonymous:

Referring to comment:ticket:2045:20

Can you comment on this ?

See ​workflow branch and default workflow mail on trac-dev.