6 ms·

Yep. All the time when I worked in IT: Me: Please try these 3 things and let me know how it goes: (list of 3 things with instructions) Them: I tried (thing #1

Yep. All the time when I worked in IT: Me: Please try these 3 things and let me know how it goes: (list of 3 things with instructions) Them: I tried (thing #1) and it didn’t work. Me: Thank you, please try these 2 things and let me know how it goes Them: I tried (thing #2) and it didn’t work. Me: Thank you, please try this thing and let me know how it goes Them: (no response) Me: Just checking in to see if this is resolved? Them: (no response) Me: I’m closing this ticket as I haven’t heard back, let me know if this is still a problem and I can reopen it Them: Don’t close the ticket, I’m still having this issue Me: No problem, can you try this thing and let me know how it goes? Them: (no response)

zelphirkalt 2y ago
And sometimes the last one becomes: Them: Don’t close the ticket, I hadn't had a chance to check that yet. Life gets in between and this one library or project is usually hardly the only thing that person juggles. We need to accept, that sometimes issues remain open for an extended duration. The worst is, when you have the same error or issue someone else had already, but their issue got closed by an effin github bot, that automatically closes issues, because someone hasn't replied for a day or two. Like, you are not the center of the other person's life. Just like no one forces you to work at no cost for others and help them, they should not be forced to give undivided focus to your project's issues. Having bots close issues, accompanied by a rude automated message is often contra-productive. It would be fine to instead post a reminder in the issue, asking for an update like shown in the example: Me: Just checking in to see if this is resolved? This is actually a very polite form of handling it.
- ecnahc515 2y ago
  I almost never see bots close issues that are less than 30 days old. Many projects can change a lot in 30-90 days and the bug may no longer exist, keeping issues open when they may no longer be relevant isn't helping anyone either. If it is still relevant, it can simply be re-opened. I don't see any downside to semi-aggressively closing stale issues. If it's easily reproduced then most good projects will mark it so that it won't be auto-closed.
  - ants_everywhere 2y ago
    I encounter prematurely closed tickets all the time, practically every day. So many software projects close bugs with bots, and they have an unrealistically rosy picture of how bug-free their software is.
  - LoganDark 2y ago
    Usually it can't be reopened because you can't even really get someone to look at it, because issues are wrongfully closed so frequently that they don't pay attention to complaints about the closures. Take a look at this issue to see what it takes to keep something open: https://github.com/oobabooga/text-generation-webui/issues/4138 https://github.com/oobabooga/text-generation-webui/issues/41... (not especially proud of my reactions there, but I hate being abused, even by robots.)
    - ipaddr 2y ago
      When I see some bug like this I do wonder why don't more people fix the issue themselves or think that it might be specific to their setup or accept a little random lag. If I received a bug like that I would immediately think why are you telling me this... just fix it yourself and share your fix if you want. I probably have higher expectations from my users. You give the software away now they want you to fix it for them.
      - LoganDark 2y ago
        > If I received a bug like that I would immediately think why are you telling me this... just fix it yourself Then you're part of the problem. I am far less equipped to handle a bug like this than you'd think. It would take me so much more work and time than asking someone who already knows the project and how to work on it. If I did this for every bug I reported, I wouldn't have a job because I wouldn't have any time left for one. You know, this is also my issue with Linux. The attitude is generally that if you want to run Linux, you are expected to do anything you need completely on your own, including fixing bugs. This is why macOS is my preferred operating system. (Not that I can run it right now...) I'm of course not entitled to anything from you (or anyone), but the one thing I won't do is fix it myself. I don't really want to be a hacker right now. I've tried. I can be, but it rarely pays off for me. Not even financially, just emotionally.
- eek2121 2y ago
  This. Usually if you are looking at tickets closed, that means you are using that as a metric, which is a BAD idea. Ticket lifetimes and movement are more appropriate metrics.
- jstanley 2y ago
  What I find really infuriating is when I was the last person to post on my issue, and I'm waiting on an update from the maintainer, and the github bot threatens to close the issue on me for not posting any updates! I've started replying to it with "No updates here." to reset the timer.
trimethylpurine 2y ago
The user will have found another solution that's more intuitive after trying thing #1 and failing.
tda 2y ago
Me: This very specific thing is broken in general for your product when I do a and b. Just like users x,y and z report on <random forum>. (Siemens) Support: Before I can help you, please find the serial number via <tedious procedure>, and the exact version of subsystems <x, y and z>. Me: Here you go, though I fail to see how my specific setup is relevant as the problem has been reported on forums for years, and it is easily reproducible Support: Please update to latest version x. Me: Version x has known regression which will break the machine for the customer. I did the 1 hour procedure anyway but the issue is still present. Support: Please execute this <obtuse command that runs a trace> and download the log from <airgapped machine> with SCP Me: O well, did that here is the file. Don't understand why you can't run it on your machine Support: Please try <irrelevant thing>, reboot (wait 5 minutes) and run the trace again Me: (Gives up)
- Sohcahtoa82 2y ago
  I wonder how flows like that happen. Is Support just completely disconnected from Engineering? Do they not have a way to report issues and indicate that many customers are having a specific issue? Does the company believe that giving a customer a runaround will make them less upset than saying "Sorry, this is a known issue. We're working on it but do not have a timeline"? Certainly at some point, some support person is going to be like "Huh, we have a lot of customers complaining about an issue, and our usual flowchart script doesn't seem to resolve it" and try to work it up the chain, right? Or does it get to their manager who says "Meh, that's an engineering problem, not a support problem. Get back to your tickets!" and never pass it up?
  - teractiveodular 2y ago
    If you're working with a large company, Support is outsourced to a bunch of people reading scripts in Manila/Bangalore, and the external company employing them is actively incentivized to never resolve the root cause of any issue, because doing so would mean less tickets and less billable hours.
    - rusticpenn 2y ago
latentsea 2y ago
>Me: Please try these 3 things and let me know how it goes: (list of 3 things with instructions) Them: I tried (thing #1) and it didn’t work. I noticed I do exactly this when troubling shooting problems with LLMs!
suzzer99 2y ago
We had a Salesforce consultant who was like this. I'd send him a list of five things he needed to do to make his jitterbit connection work with our internal API. He'd do one thing, report that it still didn't work. I'd ask if he did the other four things. He'd do the next thing, report that it still didn't work, etc. God only knows how much that department was paying him.
- loa_in_ 2y ago
  That's a person artificially extending their own task to get some slack from their company's toxicity.
micw 2y ago
_This_ is exact the place where a LLM could step in and could really help: 1. Customer describes the problem 2. You get the problem, parsed by the model, including a summary and a suggestion what could help. 3. You write "do that 3 things" 4. The model tells the customer to do the 1st, then the 2nd and so on 5. The model reminds the customer in intervals that things are not completed 6. the model notifies you after the 3 things are done and the issue is still there.
- jclulow 2y ago
  You don't need an expensive, opaque, antisocial system to run interference against your users. What you need is literally just a checklist. Give the user a checklist instead of just freeform text -- where they can check off the three individual things to try. When they've checked them all off, they can go back to the well for another response from support.
wegfawefgawefg 2y ago
I had this experience with an online game crashing. This is a game I play all the time, which recently recieved an update that adds a kernel level anticheat program. The game would start and then black screen, and I would get a null reference exception popup. Audio and input would continue without any graphics. To me this likely indicates a lack of init result check on some pointer that gets passed to a graphics init function, and then they try to access the pointer that was never assigned to. (my guess anyways) I was punushed for "leaving" the game, banned for a couple weeks, and sent an obnoxious email about my bad behaviour. I reached out to them on customer support handfuls of times and was always given a list of three steps such as "upgrading graphics drivers", "ensuring i disable my firewall", "using a pc with high enough specs" (my machine is ridiculously overspecd) and things like that. I would follow the three obviously pointless steps, and then be given another set of obviously unrelated steps. This went on about five times over a month. At some point I just told them, look im a fucking game developer, give me a log dump tool, or a build with debug symbols and I will fix it myself, and finally a real human showed up and actually sent me one. I recreated the bug and sent log captures but they wouldnt let me help beyond that. Then at the end they still scolded me for "leaving" the game. I dont blame the average person for expecting customer support to be unhelpful or a robot by default, and not following steps.
deleted 2y ago
[deleted]

zelphirkalt 2y ago

And sometimes the last one becomes: Them: Don’t close the ticket, I hadn't had a chance to check that yet. Life gets in between and this one library or project is usually hardly the only thing that person juggles. We need to accept, that sometimes issues remain open for an extended duration. The worst is, when you have the same error or issue someone else had already, but their issue got closed by an effin github bot, that automatically closes issues, because someone hasn't replied for a day or two. Like, you are not the center of the other person's life. Just like no one forces you to work at no cost for others and help them, they should not be forced to give undivided focus to your project's issues. Having bots close issues, accompanied by a rude automated message is often contra-productive. It would be fine to instead post a reminder in the issue, asking for an update like shown in the example: Me: Just checking in to see if this is resolved? This is actually a very polite form of handling it.

ecnahc515 2y ago
I almost never see bots close issues that are less than 30 days old. Many projects can change a lot in 30-90 days and the bug may no longer exist, keeping issues open when they may no longer be relevant isn't helping anyone either. If it is still relevant, it can simply be re-opened. I don't see any downside to semi-aggressively closing stale issues. If it's easily reproduced then most good projects will mark it so that it won't be auto-closed.
- ants_everywhere 2y ago
  I encounter prematurely closed tickets all the time, practically every day. So many software projects close bugs with bots, and they have an unrealistically rosy picture of how bug-free their software is.
- LoganDark 2y ago
  Usually it can't be reopened because you can't even really get someone to look at it, because issues are wrongfully closed so frequently that they don't pay attention to complaints about the closures. Take a look at this issue to see what it takes to keep something open: https://github.com/oobabooga/text-generation-webui/issues/4138 https://github.com/oobabooga/text-generation-webui/issues/41... (not especially proud of my reactions there, but I hate being abused, even by robots.)
  - ipaddr 2y ago
    When I see some bug like this I do wonder why don't more people fix the issue themselves or think that it might be specific to their setup or accept a little random lag. If I received a bug like that I would immediately think why are you telling me this... just fix it yourself and share your fix if you want. I probably have higher expectations from my users. You give the software away now they want you to fix it for them.
    - LoganDark 2y ago
      > If I received a bug like that I would immediately think why are you telling me this... just fix it yourself Then you're part of the problem. I am far less equipped to handle a bug like this than you'd think. It would take me so much more work and time than asking someone who already knows the project and how to work on it. If I did this for every bug I reported, I wouldn't have a job because I wouldn't have any time left for one. You know, this is also my issue with Linux. The attitude is generally that if you want to run Linux, you are expected to do anything you need completely on your own, including fixing bugs. This is why macOS is my preferred operating system. (Not that I can run it right now...) I'm of course not entitled to anything from you (or anyone), but the one thing I won't do is fix it myself. I don't really want to be a hacker right now. I've tried. I can be, but it rarely pays off for me. Not even financially, just emotionally.
eek2121 2y ago
This. Usually if you are looking at tickets closed, that means you are using that as a metric, which is a BAD idea. Ticket lifetimes and movement are more appropriate metrics.
jstanley 2y ago
What I find really infuriating is when I was the last person to post on my issue, and I'm waiting on an update from the maintainer, and the github bot threatens to close the issue on me for not posting any updates! I've started replying to it with "No updates here." to reset the timer.

trimethylpurine 2y ago

The user will have found another solution that's more intuitive after trying thing #1 and failing.

tda 2y ago

Me: This very specific thing is broken in general for your product when I do a and b. Just like users x,y and z report on <random forum>. (Siemens) Support: Before I can help you, please find the serial number via <tedious procedure>, and the exact version of subsystems <x, y and z>. Me: Here you go, though I fail to see how my specific setup is relevant as the problem has been reported on forums for years, and it is easily reproducible Support: Please update to latest version x. Me: Version x has known regression which will break the machine for the customer. I did the 1 hour procedure anyway but the issue is still present. Support: Please execute this <obtuse command that runs a trace> and download the log from <airgapped machine> with SCP Me: O well, did that here is the file. Don't understand why you can't run it on your machine Support: Please try <irrelevant thing>, reboot (wait 5 minutes) and run the trace again Me: (Gives up)

Sohcahtoa82 2y ago
I wonder how flows like that happen. Is Support just completely disconnected from Engineering? Do they not have a way to report issues and indicate that many customers are having a specific issue? Does the company believe that giving a customer a runaround will make them less upset than saying "Sorry, this is a known issue. We're working on it but do not have a timeline"? Certainly at some point, some support person is going to be like "Huh, we have a lot of customers complaining about an issue, and our usual flowchart script doesn't seem to resolve it" and try to work it up the chain, right? Or does it get to their manager who says "Meh, that's an engineering problem, not a support problem. Get back to your tickets!" and never pass it up?
- teractiveodular 2y ago
  If you're working with a large company, Support is outsourced to a bunch of people reading scripts in Manila/Bangalore, and the external company employing them is actively incentivized to never resolve the root cause of any issue, because doing so would mean less tickets and less billable hours.
  - rusticpenn 2y ago

latentsea 2y ago

>Me: Please try these 3 things and let me know how it goes: (list of 3 things with instructions) Them: I tried (thing #1) and it didn’t work. I noticed I do exactly this when troubling shooting problems with LLMs!

suzzer99 2y ago

We had a Salesforce consultant who was like this. I'd send him a list of five things he needed to do to make his jitterbit connection work with our internal API. He'd do one thing, report that it still didn't work. I'd ask if he did the other four things. He'd do the next thing, report that it still didn't work, etc. God only knows how much that department was paying him.

loa_in_ 2y ago
That's a person artificially extending their own task to get some slack from their company's toxicity.

micw 2y ago

_This_ is exact the place where a LLM could step in and could really help: 1. Customer describes the problem 2. You get the problem, parsed by the model, including a summary and a suggestion what could help. 3. You write "do that 3 things" 4. The model tells the customer to do the 1st, then the 2nd and so on 5. The model reminds the customer in intervals that things are not completed 6. the model notifies you after the 3 things are done and the issue is still there.

jclulow 2y ago
You don't need an expensive, opaque, antisocial system to run interference against your users. What you need is literally just a checklist. Give the user a checklist instead of just freeform text -- where they can check off the three individual things to try. When they've checked them all off, they can go back to the well for another response from support.

wegfawefgawefg 2y ago

I had this experience with an online game crashing. This is a game I play all the time, which recently recieved an update that adds a kernel level anticheat program. The game would start and then black screen, and I would get a null reference exception popup. Audio and input would continue without any graphics. To me this likely indicates a lack of init result check on some pointer that gets passed to a graphics init function, and then they try to access the pointer that was never assigned to. (my guess anyways) I was punushed for "leaving" the game, banned for a couple weeks, and sent an obnoxious email about my bad behaviour. I reached out to them on customer support handfuls of times and was always given a list of three steps such as "upgrading graphics drivers", "ensuring i disable my firewall", "using a pc with high enough specs" (my machine is ridiculously overspecd) and things like that. I would follow the three obviously pointless steps, and then be given another set of obviously unrelated steps. This went on about five times over a month. At some point I just told them, look im a fucking game developer, give me a log dump tool, or a build with debug symbols and I will fix it myself, and finally a real human showed up and actually sent me one. I recreated the bug and sent log captures but they wouldnt let me help beyond that. Then at the end they still scolded me for "leaving" the game. I dont blame the average person for expecting customer support to be unhelpful or a robot by default, and not following steps.

deleted 2y ago

[deleted]