3 ms·

How do you propose filtering tech support from bug reports at scale?

SolarNet 9y ago
Letting customer support people push a button that says "This person appears to have an actual bug" that reports it to a specialized customer support team with some technical knowledge to be able to report it. These customer support people talk to people like this all day. They can know when an issue is an actual bug.
- i336_ 9y ago
  Hmmm. Getting the bug report to the right dev and eliciting the ever-important "huh, that's weird" is a really tricky routing problem due to Microsoft (and similar companies') scale. So... maybe... a team could be created, whose sole purpose is to distill potential issues into tiny testcases that take the fewest number of seconds for someone with domain knowledge to look at and go "okay I doubt this is invalid". Not to actually repro the issue (which might require significant setup), but rather to get an initial go/no-go. Then teams around the company could be routed batches of testcases to look at every couple of days. I know I'm describing issue tracking here - the specific point I'm getting at is that the first team I mentioned would handle all the back-and-forth with the customer until the testcase was as small as possible. The caveat emptor with this idea is that it's inspired by a single datapoint (OP's bug report) and may not scale to more nuanced problems. Hardware failure, for example, would fall right through this approach.
nradov 9y ago
The only practical way to do it is to have multiple tiers of tech support where tier-1 escalates anything that looks like a potential defect to tier-2/3. And then you have to build your employee compensation structure so that those upper-tier support analysts are at least partly rewarded for the number of valid defects they file, not just for how many support tickets they close.
alkonaut 9y ago
A bug report comes with steps to reproduce, attached logs etc. Just having a team first to throw out everything from the issue reporting that doesn't meet the issue quality requirements, next a team of second line support actually reproduce the bugs and make proper work items to be prioritized - or close them as "duplicate", "can't reproduce" or similar - which the reporter gets within just a couple of days. The trick is to set the quality threshold high. It should take a couple of hours to report a bug but that should be because of the effort of writing the issue - not because you navigate tech support phone people. So basically "I can't do this thing I need to do, although it worked in the last version" is tech support - not a bug report. With the minimal steps to reproduce, some logs and perhaps a vm image - it's s bug report.

Letting customer support people push a button that says "This person appears to have an actual bug" that reports it to a specialized customer support team with some technical knowledge to be able to report it. These customer support people talk to people like this all day. They can know when an issue is an actual bug.

i336_ 9y ago
Hmmm. Getting the bug report to the right dev and eliciting the ever-important "huh, that's weird" is a really tricky routing problem due to Microsoft (and similar companies') scale. So... maybe... a team could be created, whose sole purpose is to distill potential issues into tiny testcases that take the fewest number of seconds for someone with domain knowledge to look at and go "okay I doubt this is invalid". Not to actually repro the issue (which might require significant setup), but rather to get an initial go/no-go. Then teams around the company could be routed batches of testcases to look at every couple of days. I know I'm describing issue tracking here - the specific point I'm getting at is that the first team I mentioned would handle all the back-and-forth with the customer until the testcase was as small as possible. The caveat emptor with this idea is that it's inspired by a single datapoint (OP's bug report) and may not scale to more nuanced problems. Hardware failure, for example, would fall right through this approach.

nradov 9y ago

The only practical way to do it is to have multiple tiers of tech support where tier-1 escalates anything that looks like a potential defect to tier-2/3. And then you have to build your employee compensation structure so that those upper-tier support analysts are at least partly rewarded for the number of valid defects they file, not just for how many support tickets they close.

alkonaut 9y ago

A bug report comes with steps to reproduce, attached logs etc. Just having a team first to throw out everything from the issue reporting that doesn't meet the issue quality requirements, next a team of second line support actually reproduce the bugs and make proper work items to be prioritized - or close them as "duplicate", "can't reproduce" or similar - which the reporter gets within just a couple of days. The trick is to set the quality threshold high. It should take a couple of hours to report a bug but that should be because of the effort of writing the issue - not because you navigate tech support phone people. So basically "I can't do this thing I need to do, although it worked in the last version" is tech support - not a bug report. With the minimal steps to reproduce, some logs and perhaps a vm image - it's s bug report.