4 ms·

> and store other ideas elsewhere. Why? Why have two places for the same thing? It's just an awkward tagging system. When would you search this but not search

by IanCal 3y ago

> and store other ideas elsewhere. 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.

idopmstuff 3y ago
> 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? 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.
- peebeebee 3y ago
  Backlog items can start as rough ideas though. Refining of a ticket can be done later when you need to. But it can only be started to be worked on when the team thinks it is refined enough.
  - idopmstuff 3y ago
    In my experience, if you go this route what you end up with is a thousand tickets with a title and little to no description text that eventually get deleted because you can't figure out what it was about six months later (even if you're the one who wrote it).
    - bhaney 3y ago
      And that problem somehow goes away if you store that same information in a separate system?
      - xboxnolifes 3y ago
        No, but it's about keeping the ticket box signal to noise ratio in check. One box for actionable, high signal items. One box for all the ~junk~ ideas.
        peebeebee 3y ago
        Junk ideas are useful to document too. When the idea resurfaces, one can read why it did not get through the first time. 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.
      - fourthark 3y ago
        Yes, because you just don't look at the list at all.
        IanCal 3y ago
        Which is fine, you can then save even more effort by never writing them down at all.
    - morgante 3y ago
      Those don't need to be separate systems, and keeping them in one system is often beneficial to see the evolution of the concept. 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.
- IanCal 3y ago
  Why does your second system get to have information written in it that the first doesn't, or get to be more vague? You can write tickets at any level of detail. 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.
  - nicoburns 3y ago
    > You can then "just" tag them. 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.
    - mcny 3y ago
      There are feature requests and there are what I would think of as design decisions / genuine defects depending on how you see it. 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-off-teams-ctrlshiftc-call-shortcut-i-keep/89b35005-745c-4123-aee9-88d721e2bb0d 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?
    - pc86 3y ago
      This seems like a very niche and uncommon request. The vast, vast majority of tickets I've worked on (90%+ for sure, maybe 95%+) have had multiple people putting in context, additional information, related/blocking/blocked links, reproduction steps, accessibility requirements, security requirements, etc. Not all tickets require all this info, but most of them require at least a couple of these categories. I obviously don't have the hard data but I would hazard a guess that the median ticket I deliver has been at least 15-20 minutes of total work from at least 2 or 3 people. Much higher when you're talking about greenfield development of something that is getting any level of scoping ahead of time. 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.
nicoburns 3y ago
> When would you search this but not search tickets? 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.
eviks 3y ago
How's is "cancel after X days" any better? Are there not enough decades-old bugs around to illustrate how it's not a good proxy? Why search through cancelled tickets which are resolved to find and unresolved issue? That's just a category error
- IanCal 3y ago
  The vast majority of tickets that haven't had any interaction for some length of time are irrelevant, it's an excellent proxy. 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?
  - eviks 3y ago
    It's just an excellent proxy of insufficient resources, nothing more. A missing feature doesn't automagically appear with time to make the ticket irrelevant. If it's not relevant, it shouldn't be in the system in the first place > 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
    - IanCal 3y ago
      > If it's not relevant, it shouldn't be in the system in the first place 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?
PeterisP 3y ago
They are not the same thing. 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".
- IanCal 3y ago
  > 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 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.

by IanCal 3y ago

idopmstuff 3y ago

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

peebeebee 3y ago
Backlog items can start as rough ideas though. Refining of a ticket can be done later when you need to. But it can only be started to be worked on when the team thinks it is refined enough.
- idopmstuff 3y ago
  In my experience, if you go this route what you end up with is a thousand tickets with a title and little to no description text that eventually get deleted because you can't figure out what it was about six months later (even if you're the one who wrote it).
  - bhaney 3y ago
    And that problem somehow goes away if you store that same information in a separate system?
    - xboxnolifes 3y ago
      No, but it's about keeping the ticket box signal to noise ratio in check. One box for actionable, high signal items. One box for all the ~junk~ ideas.
      - peebeebee 3y ago
        Junk ideas are useful to document too. When the idea resurfaces, one can read why it did not get through the first time. 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.
    - fourthark 3y ago
      Yes, because you just don't look at the list at all.
      - IanCal 3y ago
        Which is fine, you can then save even more effort by never writing them down at all.
  - morgante 3y ago
    Those don't need to be separate systems, and keeping them in one system is often beneficial to see the evolution of the concept. 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.
IanCal 3y ago
Why does your second system get to have information written in it that the first doesn't, or get to be more vague? You can write tickets at any level of detail. 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.
- nicoburns 3y ago
  > You can then "just" tag them. 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.
  - mcny 3y ago
    There are feature requests and there are what I would think of as design decisions / genuine defects depending on how you see it. 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-off-teams-ctrlshiftc-call-shortcut-i-keep/89b35005-745c-4123-aee9-88d721e2bb0d 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?
  - pc86 3y ago
    This seems like a very niche and uncommon request. The vast, vast majority of tickets I've worked on (90%+ for sure, maybe 95%+) have had multiple people putting in context, additional information, related/blocking/blocked links, reproduction steps, accessibility requirements, security requirements, etc. Not all tickets require all this info, but most of them require at least a couple of these categories. I obviously don't have the hard data but I would hazard a guess that the median ticket I deliver has been at least 15-20 minutes of total work from at least 2 or 3 people. Much higher when you're talking about greenfield development of something that is getting any level of scoping ahead of time. 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.

nicoburns 3y ago

> When would you search this but not search tickets? 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.

eviks 3y ago

How's is "cancel after X days" any better? Are there not enough decades-old bugs around to illustrate how it's not a good proxy? Why search through cancelled tickets which are resolved to find and unresolved issue? That's just a category error

IanCal 3y ago
The vast majority of tickets that haven't had any interaction for some length of time are irrelevant, it's an excellent proxy. 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?
- eviks 3y ago
  It's just an excellent proxy of insufficient resources, nothing more. A missing feature doesn't automagically appear with time to make the ticket irrelevant. If it's not relevant, it shouldn't be in the system in the first place > 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
  - IanCal 3y ago
    > If it's not relevant, it shouldn't be in the system in the first place 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?

PeterisP 3y ago

They are not the same thing. 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".

IanCal 3y ago
> 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 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.