Loading Profile...
Users should be able to directly move bug into Accepted or Rejected
Since we can't reject bugs as invalid or not a bug, we've started using labels to "tag" bugs as "+not a bug" when they're invalid. To do so, however, we need to mark bugs as "Accepted" after tagging them in the Icebox. This takes 8 clicks -
1.) Tag as "+not a bug"
2.) Click "Save"
3.) Find the bug since now it's collapsed
4.) Click "Start"
5.) Find the bug in the Current pane since it's now moved
6.) Click "Finish"
7.) Click "Deliver"
8.) Click "Accept"
It should take two. :)
1.) Tag as "+not a bug"
2.) Click "Save"
3.) Find the bug since now it's collapsed
4.) Click "Start"
5.) Find the bug in the Current pane since it's now moved
6.) Click "Finish"
7.) Click "Deliver"
8.) Click "Accept"
It should take two. :)
I’m tired of clicking
2
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company implemented this idea.
-
Inappropriate?I use a similar label "wont fix" for my projects
I think step 4 actually should be step 1 as you should start it before you research it and find it not to be a bug.
Then it is really a matter of adding the "not a bug" label to it, adding a comment why you don't consider it a bug, and marking it finished.
The only additional step from the normal work flow I see is that you then immediately mark it delivered as there is no code change and no need to do a deployment.
The way our projects work is it is not up to me the developer to then accept that story. The PM is really the one responsible for "Accepting" the fact that we developers are not going to do anything to fix this.
This change in the work flow is subtle yet important. Someone, presumably your PM, created and/or prioritized this story as important enough for you to look at, if you move it straight to done without the acceptance state, it would appear to whomever placed that bug there that it just disappeared from the backlog/current iteration, and by forcing them to accept (or reject) it, it may prevent that bug from being re-entered later on.
I find this work flow also useful for other stories/bugs with a similar scenario e.g. 'duplicate' -
Inappropriate?You can edit the state of the bug from the dropdown menu that is right below the label dropdown, if it is in the backlog. That should get you down to three clicks. (ironic that I need the 'wontfix' option right now in GS).2 Comments
Add a comment
This is one of the best points
-
The thing is, the bugs aren't in the backlog; they're in the icebox. We have a QA team that files bugs over the course of a day, and we triage them out of the icebox once a day - in a very GTD/Inbox Zero sense, we either a) fix them on the spot if they're < 2 minutes, b) mark them as invalid, won't fix, or not a bug if we know that's the case, or c) put them in the right priority in the backlog. After the triage, our icebox is empty.
Your suggestion still makes us touch a bug twice - once to sort it, and another to resolve it. We know we're not going to do the work, so why both spending the time to sort it onto the backlog? -
Paul, I guess there may still be some room for improvement. I'm thinking about why this workflow might not be better served and here's what I have come up with:
1. We are really really careful about not accepting things that we (personally) have delivered - you can avoid the bulk of false positives by making sure that two people are satisfied.
2. I think the 'wontfix' in Tracker is the delete button. It takes some courage I know! But remember that the story will still be visible in Project History in case QA is wondering what happened to the bugs.
