Loading Profile...
A "deferred" status would be rather handy
About 5-10% of our issues are stuff we can't fix right away.
Either something else is blocking it, or it needs something else to be developed, or it's very minor and can wait as something else more important has come up.
I tend to leave them as open and lower priority to trivial, but after a while it really starts adding a lot of cruft.
I don't want to close them as the issue hasn't been fixed. But nor are they really "open" in the same way as an open issue means "we need to fix this now(ish)"
I deferred status would be great, and useful as I can look at everything that is deferred and see what can be moved back live.
I know you probably don't want to mess up the great Open - Resolved - Closed flow, but perhaps something near the delete edit issue?
Either something else is blocking it, or it needs something else to be developed, or it's very minor and can wait as something else more important has come up.
I tend to leave them as open and lower priority to trivial, but after a while it really starts adding a lot of cruft.
I don't want to close them as the issue hasn't been fixed. But nor are they really "open" in the same way as an open issue means "we need to fix this now(ish)"
I deferred status would be great, and useful as I can look at everything that is deferred and see what can be moved back live.
I know you probably don't want to mess up the great Open - Resolved - Closed flow, but perhaps something near the delete edit issue?
I’m wary of feature requests but ever the hopeful
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 this under consideration.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?Unfortunately, the concept of "deferred" or "on hold" is something we don't believe in. I wrote more extensively about it with my original post about statuses some time ago. (http://garrettdimon.com/archives/2007...) The short of it is that even if it's blocked or you can't work on it, it is still open.
Long-term, I'd like a more elegant way to handle them, but deferring or putting them on hold feel like sweeping it under the rug. As you noted, there are several different reasons to defer something, and each is actually a unique situation with special context.
1. Blockers. Ideally, what would happen is that we'd find a way to elegantly add support for notating blocking issues. Then, if one issue is blocking 3 others, that issue implicitly becomes a much higher priority. Naturally, it's a lot easier to describe it than to implement elegantly, and it's interwoven with a couple of other ideas that we have.
2. Priority. In the case of an issue being deferred simply because it's not important yet, it really should just have a lower priority. If too much cruft is building up, then I'd suggest using milestones and maybe creating a milestone that's many years out and just putting them all in there. I personally wouldn't do that, but I believe it would help get them out of the way.
3. Future Enhancements. I have been thinking a lot about this facet in the context of new features, and it's something that's been very back and forth in my mind. On one hand, I really like the idea of being able to make note of an idea for future reference but put it on the back burner. On the other hand, I feel like I'm just building up a huge list of hypothetical new features that may not even be relevant by the time we get to them.
We have a huge backlog of features and enhancements, and I suspect we're not alone. They're not important enough to be at the front of the line, but they are worth remembering.
All of that is to say that I understand the challenges you're describing, and I agree that we need a more explicit and elegant way to address those problems. I just don't feel that deferring or putting issues on hold is the best way to handle it. It makes it too easy for them to get lost in the shuffle.
I’m hoping to pleasantly surprise you with a solution down the road
The company thinks
this is one of the best points
1 Comment Add a comment
This is one of the best points
-
I understand this is complex, and I'm sure a lot more complex than just throwing in an extra status.
However I think sometimes in being to simple, you can obscure some of the fact status's are more complex than just open/closed.
In reply to some of your points
1. Blockers aren't always internal. We might be waiting for a API update in a 3rd party. This update could be months away. I don't want to close the ticket down, but it's getting mixed in with actual tickets that need to be worked on. This is confusing.
2. I would do this for some items. But
-- I can't close milestones down when done (see here http://getsatisfaction.com/nextupdate...)
-- I can't shift things between milestones (Ideally I'd like to shift tasks between milestones so I can move it into deferred milestones and back to "The Lbirgh Blugrgh Project"
3. I would love to ditch Kindling App and log all tasks in Sifter instead. I would love to have a way to use sifter for "feature requests ideas" "things to do" "tweaks to make" etc etc. For me the only difference between a feature idea, a design tweak and an active task, is really when it gets done. Whilst I don't need the voting/volunteer/etc stuff of Kindling App, the ability to chuck ideas in a bucket, and then shift them to an active project and milestone would be rather useful. And I'd save $50 by ditching Kindlingapp
Your point of having a backlog that's worth remembering is exactly my problem. When they are just open tasks, we land up with so many open tasks worth remembering that we cant find the stuff we are meant to be working on right now too.
For me deferring tasks or marking stuff for future work is how I would do it in my workflow. But if you can find a more elegant way to do it, then better. Obviously I know what works for me, and I understand your challenge is to find something that works for everyone. I can only put forward my style and workflow and hope that helps you with your design process.
Thanks for the support and I look forward to seeing what you can do in this area. -
Inappropriate?1. If there's an external blocker, than it's not an issue so much as a new feature, and having a back burner to put it in would really be the best place for it. The problem there is that Sifter isn't yet designed to explicitly support managing feature requests. Unfortunately, something like that shouldn't be in Sifter at this point. (This is something that's very frustrating for me personally, and I'm exploring ideas for fixing it.)
2. We're very aware of the issue with closing milestones, and I'm already designing solutions. As for shifting things between milestones, you absolutely can change the milestone for an issue. You just can't change the project.
3. This is something that we are feeling the pain on ourselves. It's further down the line in terms of priority, but if we're feeling the pain on it, it will be addressed at some point. Essentially, we would like a back burner queue for items that we care about and want to capture our thoughts on, but that we're not quite ready to implement. The problem is that features and issues are inherently different things. Features would generally end up being broken down into multiple issues or todo's for implementation. It's a fine line between too simple and too complex.
In terms of not being able to find issues, I would really suggest leaning on milestones for organization. We know that they still need some enhancements to really become polished, but those are coming.
Thanks for sharing the workflow. Every lit bit helps us one way or another. Whether it's inspiration or just another perspective, it helps make things clearer.
I’m thankful
EMPLOYEE
