Why? Why have two places for the same thing? It's just an awkward tagging system. When would you search this but not search tickets?
Alternatively, just don't write them down. If you don't get a benefit from keeping the idea, don't write it down.
Mid-option, I think linear does this by default, cancel backlog items older than X. Not been touched or moved? Probably not relevant. Plus you can always search through cancelled tickets.
A ticket is a different level of detail. Takes more time, thought and effort to put together a good ticket. If it's for something that's not going to happen for 12 months, then there will have been enough change in the product/org/etc. that the original ticket won't work as written anyway.
A doc with a bunch of categorized feature ideas has enough info that you don't lose any good ideas, and then when it's actually time to attack one of those categories, then you can do the work of building out actual, ready-for-implementation tickets.
> Alternatively, just don't write them down. If you don't get a benefit from keeping the idea, don't write it down.
Totally agree with this. A lot of stuff isn't worth writing down. If it's way out in the future and really important, it'll come up again anyway.
A ticket-system like JIRA is the same as an e-mailclient to me. You sort by activity, having the most active tickets on top. You can flag/mark them, you can put them in different boxes or just use tags,... All are just means to create order in chaos.
But I would never think to move my old e-mail to a different 'system' than my normal e-mail(client). I never think of old e-mails or drafts as something I need to clean up.
I'll frequently have an idea and toss it into a backlog ticket. Maybe just as a title to start. When a customer mentions that problem/feature, I can add that info in the backlog even if it doesn't immediately become a priority.
When the issue does become something worth working on, I'll usually add more details but the various evidence accumulated over 6 months of letting the item "bake" is invaluable.
You can then just tag them.
This means that a search can ignore them, or it can bring them up while you're looking at features/etc.
All that administration overhead is why the ticket based system doesn't get this information. If it takes 30 seconds to create (and properly organise/categorise) a ticket then that's too slow. I want to be able to write tickets as fast as someone can say them, and move/reorder them with my usual copy paste / text editing tools.
This is across 8-10 jobs in multiple industries over close to 20 years. Some places have been better or worse than others but I can't think of any place where people routinely were creating, organizing, and categorizing tickets this quickly, at least not tickets that had any value to anyone other than them as a reminder to do one very specific thing.
Sure, for tickets that you deliver. But when we're talking about managing a backlog there might be 50 potential tickets that never get implemented (or even scoped) for every one that does. And you don't really want those to ever become a ticket at all because that ends up being far too much product work, precisely because it takes ~20 minutes for each ticket.
Put another way: you need a way to track high-level work for prioritisation before putting too much into scoping and detailing what implementing it would involve.
For example, ctrl shift v is how you paste unformatted in ms teams. You’d think by that logic, ctrl shift c would be copy but no it starts a call. There is no built in way to eliminate that and when I ask ms people they say “oh use powertoys and blah blah I had to do the same”.
There are multiple times this has been raised on the forums
https://answers.microsoft.com/en-us/msteams/forum/all/turn-o...
Do you want to put things like this on a different list, basically a “won’t fix” list? Why even write them down? Just to make people think you are listening?
A ticket is something where there is an understanding that we want to do it if time and resources permit, something where it would be okay for someone to grab it and do it.
On the other hand, an idea or suggestion may easily be something that should not ever be done, that drives the product in an inappropriate direction or adds an ability that we don't really want to exist for various reasons; and that is conceptually fundamentally different and should be kept in a separate place from the "big todo list".
If you want it to be that, sure. They're really just notes with IDs and tags. What you're describing is a curated backlog / upcoming work.
> On the other hand, an idea or suggestion may easily be something that should not ever be done
Ok? So either say why and cancel the ticket or delete it if you don't want a record of it. I don't get the value of writing it down in a different place so that you have to search in two places.
But it's worth reading the comment in context. If your problem is that old tickets are a nuisance because they're almost always irrelevant, just have them auto cancel and when you get that notification rescue the 2 per year that you truly want to keep.
If you don't have that problem, keep them.
> Why search through cancelled tickets which are resolved to find and unresolved issue?
Why would resolved tickets be cancelled?
Also, why search through two different systems?
> when you get that notification rescue the 2 per year that you truly want to keep.
That makes even less sense. Looking at notifications and making a decision on closing/reopening is a form of review. If you have time to review, do it properly on your own schedule and in batches rather than be beholden to some arbitrary autoclose timeline with yet another focus-destroying trickle of notifictions
It was when it was created, it's not now. And it is then practically removed.
Again you can build whatever workflow you want, tag stuff or move things if they're super important to you. Subscribe to them if they're vital. Or don't auto close if that doesn't work for you.
I don't think that having a tiny number of issues that are
* Never looked at
* Never prioritised
* Never searched for
* Not subscribed to by anyone that cares about them
* Somehow super important to not have a "cancelled" status on them
Should define your workflow to this degree that you start keeping multiple lists of work. I'm not sure I've ever come across an issue worth leaving like this. Can you tell me about an issue that fits this description?
> It's not now
You don't know that, in the process you yourself proposed that determination was done when you get an autoclose notification
The trick is to have each "ticket" be basically a bullet point in a list (where lists are grouped by headings/subheading in a single document). Maybe some are 3-4 lines, but most will be a single line bullet point. That way you don't have to search it (which doesn't tend to work very well as you won't know what you're looking for), you can actually browse the entire document.