1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues


Issue #5179 closed

Add a status of "Closed" to issues (BB-10249)

created an issue

the workflow of a bug/issue should be - new -> open (when assgined to a dev) -> resolved -> closed (after QA verified the fix is OK)

Comments (39)

  1. Dylan Etkin

    Hi Tomer,

    We have decided to keep the issue tracker as simple as possible. We have resolved and we feel that represents the closed state.

    If you are looking for something more customizable we would recommend JIRA.



  2. HBP reporter

    (Reply via to...@cmycasa.com):

    Hi Dylan. 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?


  3. Adam Gent

    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.

    Here is another request https://bitbucket.org/site/master/issue/4588/customisable-workflows (there are many more like this... although people say different things a majority of them want just a "testing" state).... I should also state I'm a paying customer :)

  4. Vladimir Sizikov

    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.


  5. Jason Keefer


    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.

  6. Steven Berlan

    +1 Closed status

    It is irritating sifting through the All tab in issues because a lack of consideration for a verified fixed workflow status.

    QA is part of the standard lifecycle of developing software. You should not be using this crippling oversimplification to push Jira.

  7. Jaime Olivares

    +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.

  8. Ray Luo

    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.

    Please, bitbucket team, wake up.

  9. Log in to comment