Comment by alkonaut | Hacker News Reader

Comment by alkonaut | Hacker News Reader

First, I think it's good that Microsoft and others separate tech support from bug reporting. Obviously some support requests will be due to bugs - but I'd never ever try to enter a bug via tech support (and this article shows why).

That said, the Microsoft way of bug reporting is utterly infuriating. If a bug like this is reported you want a human response from a developer familiar with the code in question, within at most a few days. This isn't support - I'm not buying a service from Microsoft I'm providing a service. For free.

Uservoice isn't working. It's a site where you vote on silly feature requests, not a proper bug reporting system where you can actually follow the issue being resolved. The bug report menu item in some products seem to take me to different places each time and differnt products do it differently. (and don't get me started on the people that respond on answers.ms... what is their correctness rate? 5%?)

I'm very happy to see that for a lot of the dev related projects you can now usually get a response on a github issue very quickly.

The problem here is that historically, bug reporting was linked to tech support because only enterprise customers were expected to report bugs, and those customers were paying for those bugs to be resolved (hotfixes, for instance).

Nowadays, Microsoft is asking for bug reports from everyone, but has not fully created a support structure to make that feasible at scale. They seem to be iterating over the problem though, and maybe eventually they'll get it right.

I can see how a select few enterprises basically have agreements that mean they call their software vendor when they can't get their work done - and the vendor fixes the problem whether it requires a patch or just hand holding.

But having this system only, thinking it can be applied to small business or private customers is beyond naïve. Especially since they lose a free service - the quality bug reports from competent users.

The devdiv is way ahead of the rest at Microsoft - and the OSS bits are basically world leading. So there is certainly hope.

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

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.

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.

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.

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.

Reply on news.ycombinator.com