Loading Profile...
Custom issue statuses
Custom statuses would make this the perfect balance of simplicity and control for me.
When working on enhancements, for instance, different people may need to work on different elements of the task (UX guy on wireframes, designer on comps, developer on code, etc).
I'd hate to have to make three or four tickets for each enhancement, or use the categories in a hackish way (since it really would be a status for me).
It wouldn't even need to be super-flexible, since a bug fix could just be assigned a status that is further down the line (development, for instance). The only noodle would be allowing each status to be mapped to your core open/resolved/closed statuses.
Any thoughts on this?
When working on enhancements, for instance, different people may need to work on different elements of the task (UX guy on wireframes, designer on comps, developer on code, etc).
I'd hate to have to make three or four tickets for each enhancement, or use the categories in a hackish way (since it really would be a status for me).
It wouldn't even need to be super-flexible, since a bug fix could just be assigned a status that is further down the line (development, for instance). The only noodle would be allowing each status to be mapped to your core open/resolved/closed statuses.
Any thoughts on this?
I’m liking everything else
1
person likes 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 has not planned to implement this.
The best point from the company
-
Beyond "hacking" the categories to make it happen, we're really not thinking about adjusting the statuses.
If I'm understanding the goal correctly, the closest thing you could do would be to reassign the issue to a different team member as each step is complete.
So, the category could be enhancement, and as the wireframe is finished is finished, the issue could be reassigned to the designer. And when the designer is finished, they could reassign it to the developer.
We're definitely keeping an eye on how we can improve the workflow, but we're planning on being very cautious about adding too much configuration. Nonetheless, this is very valuable feedback.
I’m appreciative
The company and 1 other person think
this is one of the best points
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?Beyond "hacking" the categories to make it happen, we're really not thinking about adjusting the statuses.
If I'm understanding the goal correctly, the closest thing you could do would be to reassign the issue to a different team member as each step is complete.
So, the category could be enhancement, and as the wireframe is finished is finished, the issue could be reassigned to the designer. And when the designer is finished, they could reassign it to the developer.
We're definitely keeping an eye on how we can improve the workflow, but we're planning on being very cautious about adding too much configuration. Nonetheless, this is very valuable feedback.
I’m appreciative
The company and 1 other person think
this is one of the best points
3 Comments Add a comment
This is one of the best points
-
Good answer - in some ways I think it's good for the app's defaults to help shape behaviour.
One question I have on statuses is what the difference between 'resolved' and 'closed' is meant to be. The arrows on the interface suggest that the flow is meant to be open -> resolved -> closed. I'm assuming that the resolved -> closed step is meant to be about QA, and checking that the 'fix' really works? When you opened the bug though, and then you fixed it (and you're confident the fix works), the extra step feels a bit unnecessary. Should you jump straight from open to closed? -
Yes. It's simply a matter of differentiating for QA purposes. Depending on what works for you, it's perfectly ok to jump from Open to Closed. That's why Sifter doesn't explicitly prohibit it. We know there will be cases where the extra step isn't necessary.
-
Thanks for the feedback - I'll feel happier jumping my own bugs to 'closed' now. I wasn't sure at first whether 'closed' implied an alternative to 'resolved' (ie closed might be for bugs/feature requests that are rejected whereas resolved is for bugs fixed or features implemented). It's a question of terminology I guess.
-
Inappropriate?If you're the only person working on your app, then open to closed makes sense. If there is more than one person, then acceptance testing is often (rightfully) done by a person other than the person who addressed the issue. This is a good thing, and should definitely be supported, even if it means you're double-checking your own work.
Nothing worse than re-opening an old bug because you didn't really check hard enough or didn't get a second set of eyes.
To your initial sentence, I am fine with defaults, but in the search to find an issue tracking app that fits our process at Viget, we need multiple stages of explicit acceptance through the process of addressing a user story as a team.1 Comment Add a comment
This is one of the best points
-
I understand that need for custom statuses. Unfortunately, I don't foresee us ever taking Sifter in that direction. I believe Lighthouse enables you to create custom statuses. Have you taken a look at that yet?
-
Inappropriate?Just found you guys from the Campaign Monitor blog... it's looking like a really nice app and just what I need!
The one thing I'd like to do is move a bug/issue into a 'pending approval' state. With a lot of my clients bugs, issues and new features for their systems all tend to get merged into one in their brains. Bugs I'll normally fix free of charge, but new features I'll quote and bounce back at them before I proceed to fix it. Understand I could assign the ticket back to the client, but I could also do this for other reasons too... i.e. just a quick question about something...
As a result of having this kind of status it would mean I would be able to see those tickets that are pending approval and/or have quotes associated with them...?1 Comment Add a comment
This is one of the best points
-
I'm glad to hear you like what you see.
At this point, the available statuses are essentially set in stone. We spent a lot of time upfront determining what the statuses should be, and the interface depends heavily on maintaining that simplicity. (You can see the backstory in this article.
That said, you could probably handle this using custom categories. By setting up an "Enhancement" category, you could classify things and then explain your reasoning in the comment. If it's out of scope you could resolve or close the issue (depending on what makes sense for you).
The key reason we didn't create any kind of approval status is because a typical client doesn't care about the distinction. In their mind, as soon as they fire off a request, it's "Open". So even if you decide not to accept the request, in their mind it's something that is actively waiting for a response or action. From their point of view it's a distinction without a difference.
Regarding assignment, you generally shouldn't need to reassign issues back to clients. Anytime an issue is updated, Sifter will notify everyone involved with the issue, including the opener. The easiest way to think about it is that the assignee is always the person that is expected to do the work.
There are definitely times when you'd want to consider reassigning to the client, but it's not something you have to do every time.
EMPLOYEE
