Add ability to create your own company specific statusses

I would to learn more about why you are making this request, can you give us examples of custom statuses that you use? Thanks!

I add my opinion about custom states. For Example, here status for BUGs:
* Recorded - ticket is created by a user but still assigned to him and not visible to all other project members. He can continue to edit it in order to track errors and adding details, before publish it.
* New/Open - ticket created by a user and published in order to make it visible to all project members. In this status it is still not confirmed by a reviewer (in big projects one person often verifies details and existence of a bug before assign it to a developer)
* Confirmed - ticket confirmed by a reviewer and assigned to a developer
* Taken into Account - ticket read and taken into account by developer that will solve it as soon as possible
* Started/In Progress - ticket is in "work in progress" status
* Pending - ticket is commented by developer, assigned to reporter in order to receive more clarification on it; in this status responsibility of ticket is owned by Reporter
* Completed/Resolved - ticket is developed by a developer in its local machine for example but not delivered on an environment testable by reporter or by a tester. Is useful for a devoloper to know that he already solved but still not visible to customer.
* Delivered - solution of bug is delivered on a TEST environment in order to be tested by reporter, and ticket is assigned to reporter
* Closed - ticket is considered solved by reporter, closed and unassigned; this status should also hide ticket from main tickets list

We could add also other status for specific issues, for example:
* Clone - ticket is a clone of another one. Reviewer could set this status and automatically link it to the original one.

In order to manage not only bugs but also "Change requests", we could add the following status (many others are shared with previous ones):
* Quoted - CR asked in tickets is quoted by a developer (such as "1 day of work") and assigned back to customer in order to allow it to accept estimation and give ok to developing.
* Accepted - customer accepted estimation and assigned again to developer that will change ticket to "Taken into account" status.

Responding on the why part of the question, over the years I've noticed that it does not work to force users of bug processing software to use a fixed amount of statussen. Most companies have already developed some kind of process and do not want to change that. If switching to Damnbugs means that these companies must change their working process, they'll never adopt the new system.  

IJsbrand can you give us an example of a custom status that you would like to create and how you use this status?

Thanks.

Could be anything. Suppose if a client wants to refer an bug to a number they use for changes, they'd like to have a custom numeric field. Or they have their own definition of statusses which are used throughout their company. For example 'Accepted' rather than 'Confirmed'.

Thank you IJsbrand.

Anyone else in this thread, please provided specific examples of custom statuses that you miss.

We would like to gain a better understanding of this need to ensure that we address it adequately.

thanks!

I already posted my status in last comment........

I would say that this does not only apply to statuses, but also types.

'Test' and 'Retest' would be real useful and I'm not sure if 'Invalid' was an option as I can't seem to log in at the moment but that would be also useful. Having 'Declined' to compliment the requested 'Accepted' above would be a good status for client requests.

I fear that the repeated request for examples of custom statuses hints at the possibility of the developers simply adding more predefined status options.  Two comments :

First, there's a danger of having 'too many' status options.  If a company has a workflow with only three or four status options, it doesn't want additional unused options that just confuse users and lead to problems.

Second, the underlying issue/request is basically to have all status options as fully soft.  By all means suggest some to make it easier for new users to get onboard and start using the service, but allow all of them to be custom defined, and/or deleted.

1. We will not add additional statuses, ever. I firmly believe that a good QA process can be conducted with the statuses we already have. As you rightfully pointed out, "there's a danger of having 'too many' status options." - so definitely, that's not happening.

2. Custom status is a hot topic internally. Carlos (CTO) wanted to do it due to high demand.

As stated above, I don't think Damn Bugs needs more statuses, I don't think it needs different nomenclature for the statuses we currently have, I think no one should need to customize the current statuses that we have, but obviously I'm not so grounded in my beliefs that I would turn a blind eye on user requests.

Clearly there's been enough demand to justify doing it, right now the issue is simply that it represents a lot of work and we have tons of other things we want/need to do, so we're prioritizing. It'll come.

Simon

Hi Tech,
As ou can see in my previous comment of many months ago, I suggeste a series of other status and for some of them I'm unable to find equivalent in DamnBugs. Examples of this affirmation are "Pending", "delivered", "quoted", "clone". In my company we're using Jira, and I can assure you that these kind of status are used.

I perfectly understand that it would not have sense to add more status to current list, and is for this reason that I suggested to allow free customization. Every team has its workflow, and sometime it also depends by single project and by people are involved in. Flexibility could allow DamnBugs to become more feasible for everyone.
For more details, please refer to my past comment.

Thank you.

Tech, we want to add a Status of Defer for bugs to deal with later.
Please more flexibility.

> I think no one should need to customize the current statuses that we have

Well, that's the thing. This software is being used for a variety of purposes across multiple countries. Let me give you an example.

I am developing software for internal use. QA is provided informally by my colleagues (which is why I'm using a free application...) I'm not doing CI because I'm the only developer. So, each fix is deployed independently.

For my own benefit, I'd like to be able to mark a bug as "Implemented". Then, when I deploy it for QA, I'd like to mark it as "Ready for QA" or something. (We're using Feedback for now.) Then, when it's been QA'd, the colleague doing it can mark it as "Resolved". However, if QA finds a problem, they should mark it as... well, something. Feedback would be good, but we're using that as "Ready for QA". Finally, when it's deployed to Production, I can mark it as "Closed".

I really have no need to have both "Confirmed" and "Acknowledged". To me, these are redundant. In fact, I don't even use them at all. I would be happy to change the labels on these and use them for something else.

As you can see, the existing statuses work pretty well, but they're not quite right. If the exact wording didn't matter, then they could just be labeled Status 1, Status 2, and so forth. Connotations matter.

Thanks again for making this very useful tool available for free, and for listening closely to your users!

This is a very useful explanation. Thank you. I was just writing a blog post on the subject and you kinda just made the whole thing fall apart. Now I have to re-think my arguments :-)

But FYI - we're working on this next after the API is released next week.

One question: why aren't you using "Resolved" as "Ready for QA"?

> But FYI - we're working on this next after the API is released next week.

Awesome on both counts!

> One question: why aren't you using "Resolved" as "Ready for QA"?

That's an option we've played with. The trick is that there also needs to be a "Ready to Deploy/Passed QA" status.

When I am done implementing a feature/fixing a bug, but haven't deployed it to the staging server yet, I might mark it as Resolved and leave it as assigned to myself. Then when I deploy it to staging, I leave it as Resolved and make it unassigned. Then the next available QA person will take it and test it.

However, what happens when QA passes my fix? They can't deploy it. So, they mark it as Resolved and assign it back to me.

Thus, the same combination of status and assignment can mean two different things. That's what we're trying to deal with at the moment.

I continue to push with "custom statuses"; sincerely I don't understand why you're so much against them. Could be the best solution for everyone. Default statuses could be actual ones, with ability to add others, delete something, or simply change name to existing ones, all based on single projects. The best flexibility for everyone

Agree with whats been said by others. I'm really confused as to why you don't seem in favour of custom statuses, although happy you are reviewing this due to the amount of demand it's clearly attracted. Not everyones workflow is the same, and it's sometimes not easy to fit a project around the default statuses currently supplied. I'd even be prepared to pay a premium to have the ability to add custom ones as it would make the bug logging perfect for us.

Woohoo!

For what it's worth I actually went and looked up the meanings of your standard status' and I think you actually have it about right in the sense that you can do what you need to do (though I understand people's want for their own status') but having a community using the same status all around is rather nice. Two things I have noticed though are:
1. For resolved, it seems common practice to have multiple types of resolved (i.e. fixed, duplicate, no change required etc.), but I can all see an argument for saying that the extra info could go in as a comment.
2. The other thing I notice is that you can have a bug type of suggestion, that's effectively what this whole knowledge base is for and you use status' of planned, under review, declined, completed etc. Surely it makes sense to offer those as status' (even if it's just for when the suggestion type is selected). Just a thought.

Hey Guys,

Firstly thank you for the great tool.

The only thing keeping us from using this as our primary bug application is the lack of custom status messages.

I know you are busy with but could you possibly give us an ETA on when it will be done ?

Thanks again.

Byron: the feature is ready and currently being tested. We are shooting for a Friday release, but we won't release it if there's still bugs. To be safe, next week.

Great news, thanks guys

This is now live in our Pro version.

Everyone who posted a comment in this thread, please send us an email at: support@crowdsourcedtesting.com and we will upgrade your account for free.

Thank you.