3 ms·

I'm not sure it's fair to blame user apathy/laziness. More likely, user burnout. I don't think I've ever had a single thing resolved by 'opening a case.' To

I'm not sure it's fair to blame user apathy/laziness. More likely, user burnout. I don't think I've ever had a single thing resolved by 'opening a case.' To me, I hear 'go fight with our offshore cs team until you give up.' This case seems starkly different, as the author just wants accountability and tracking, which is great. But I imagine most users are weary.

navjack27 4y ago
Not related to the author of this or any of the software that they've done but I was messing around with the Haiku operating system and one of their updates broke the trackpad for a laptop that I had it installed on. I went on the IRC for them and reported the bug they told me to open up a bug report on their issue tracker they immediately responded to the bug report I opened and I did some extra testing for them and by the time the next update was pushed out like the next day the issue is fixed. I thanked them a whole bunch they thanked me a whole bunch and we both went on our merry way.
cardiffspaceman 4y ago
I just had to recover some luggage that went astray within an airline's handling of missed flights. I didn't open a case. They had tracking numbers, which I had to find out and use. There was a place where notes were being appended, but I did not learn what the tracking number for the document that accumulated the notes was. Perhaps this works fine for "where's my luggage, give me my luggage" use cases.
zeeed 4y ago
There’s an interesting gap between the interest of the dev and the user here. The user wants a human to understand their sometimes multi-layered requests. The dev wants these requests to be de-layered and broken into separate issues for tracking and documentation. There really isn’t a good system today (that I know of) that would facilitate this process with both the user and the dev in mind. From a perspective of information structuring and prioritization, tickets are perfect (for the dev), yet they lack a “natural” (e.g. email, phone or chat) support exchange where an issue is several issues rolled into one. Or once an issue is resolved there’s the “oh btw while I have your attention” moment where an unrelated issue is discussed but the interaction between the same people is ongoing. To handle this properly in an email-to-ticket-system the dev would need to ask the user to resend the request in a different mail or themselves open a new issue, which is exactly the overhead the system tries to avoid in the first place. Or either party would need to remember the issue ids to keep a running list, all of which seems undesirable. In the case of a small team/single dev product it’s that human interaction that’s not paid for so the burden is put on the user, at the cost of a reduced interactive experience. Is there any better way of solving this? Or are systems being built to support this a bit better than how the Jiras/Redmines of this world are (not) handling it today?
- wahnfrieden 4y ago
  Losing the original customer voice and statements and context and breaking them down in to stories plays a large part as a condition leading to software that overall lacks a baseline level of polish and coherence, and which pits individual changes against each other at a micro level instead of caring for overall experiences or ever letting polish-level quality jump ahead of other pressing work
- andrewflnr 4y ago
  "sometimes multi-layered requests" are fundamentally a human problem, not a technology problem. I suppose ideally you'd have a human triage the incoming request into whatever de-layered channels are convenient for the dev. It's always going to require a human who understands both sides, unless you get an AGI that understands both sides.

navjack27 4y ago

Not related to the author of this or any of the software that they've done but I was messing around with the Haiku operating system and one of their updates broke the trackpad for a laptop that I had it installed on. I went on the IRC for them and reported the bug they told me to open up a bug report on their issue tracker they immediately responded to the bug report I opened and I did some extra testing for them and by the time the next update was pushed out like the next day the issue is fixed. I thanked them a whole bunch they thanked me a whole bunch and we both went on our merry way.

cardiffspaceman 4y ago

I just had to recover some luggage that went astray within an airline's handling of missed flights. I didn't open a case. They had tracking numbers, which I had to find out and use. There was a place where notes were being appended, but I did not learn what the tracking number for the document that accumulated the notes was. Perhaps this works fine for "where's my luggage, give me my luggage" use cases.

zeeed 4y ago

There’s an interesting gap between the interest of the dev and the user here. The user wants a human to understand their sometimes multi-layered requests. The dev wants these requests to be de-layered and broken into separate issues for tracking and documentation. There really isn’t a good system today (that I know of) that would facilitate this process with both the user and the dev in mind. From a perspective of information structuring and prioritization, tickets are perfect (for the dev), yet they lack a “natural” (e.g. email, phone or chat) support exchange where an issue is several issues rolled into one. Or once an issue is resolved there’s the “oh btw while I have your attention” moment where an unrelated issue is discussed but the interaction between the same people is ongoing. To handle this properly in an email-to-ticket-system the dev would need to ask the user to resend the request in a different mail or themselves open a new issue, which is exactly the overhead the system tries to avoid in the first place. Or either party would need to remember the issue ids to keep a running list, all of which seems undesirable. In the case of a small team/single dev product it’s that human interaction that’s not paid for so the burden is put on the user, at the cost of a reduced interactive experience. Is there any better way of solving this? Or are systems being built to support this a bit better than how the Jiras/Redmines of this world are (not) handling it today?

wahnfrieden 4y ago
Losing the original customer voice and statements and context and breaking them down in to stories plays a large part as a condition leading to software that overall lacks a baseline level of polish and coherence, and which pits individual changes against each other at a micro level instead of caring for overall experiences or ever letting polish-level quality jump ahead of other pressing work
andrewflnr 4y ago
"sometimes multi-layered requests" are fundamentally a human problem, not a technology problem. I suppose ideally you'd have a human triage the incoming request into whatever de-layered channels are convenient for the dev. It's always going to require a human who understands both sides, unless you get an AGI that understands both sides.