Thanks for the reply.
What is the flow you suggested then? When a developer fixes a bug, how
should he mark it so that QA knows its resolved? And how should QA,
after verifying that the bug is indeed resolved, mark it as closed so
he will be able to filter out verified bugs?
Dylan Etkin I think its great to keep the issue tracker simple (its in fact why we use it) but I and many others seem to need one more state in the workflow. Even Github and Google code allow this (through "labels", and "keywords" respectively)
And We are not asking to customize the workflow. We just need to indicate that the code is in but someone other than the developer who fixed needs to test it. So one more state is all that is needed.
Otherwise I have been having to use the Component field.
I totally agree here, we really do need one more workflow state. Otherwise it is just impossible to distinguish between old fixed/verified bugs and recently fixed ones.
Once the issue is fixed by developer, the QA should verify the bug and somehow mark it as verified. Even on smallish projects where there is no dedicated QA, it is very useful for developers themselves, so that they would distinguish between the old already verified and/or tested bugs and the newly fixed ones.
Please reconsider your decision and add just one new workflow state. If you don't wish to increase the number of states, then it makes sense to remove one of invalid/wontfix sates, one of them is more than enough.
I have been using the Issue Tracker for one of my projects. I am used to using expensive trackers in funded business settings, and while there are many features that BitBucket does not emulate, one thing I am sorely missing which I'm not sure I can live without is the ability to set a bug status as "Claim Fixed/Resolved", so that the original tester/QA can go back and test to see if the bug has actually been resolved. This creates an ideal work-flow dynamic, where bugs are not just marked Resolved, but they are earmarked to be re-tested before being verified to be actually Resolved.
+1 for Closed, Verified or Approved. The goal of simplicity is not broken here, since it would be a non-customizable addition.
By the way, there is a new Vote feature all you guys can use for voting for this feature. Hope somebody is hearing us.
I'm not voting on this issue as I believe closed is the same as resolved but I do feel a testing workflow item is needed as requested here and would masively enhance bitbuket with no (as in 0) compromise on simplicity
I've already voted using the Vote link, but this issue is so important that I must write a post here and hope the bitbucket team can see it:
HOW COME ADDING ONE MORE "CLOSED" STATE WOULD MAKE THE ISSUE TRACKER NOT SIMPLE ANYMORE? It is so easy to implement this new feature, it is also easy for end user to use it, and it is even as easy as right now if an end user decide to not use it. So what is the logic behind this "keep it simple"?
My guess is that the issue tracker was originally designed for (and perhaps by?) solo developer, who takes full authority to say whether a bug is done; when he said it is "resolved", he means "closed". This assumption is fundamentally wrong when a project becomes serious and involves QA team and management team.