I agree on almost everything you've written, but, getting the general userbase to understand this is... a challenge - the best we get is generally of the form: "It's crashing when I press this button", and a stacktrace (but that is thanks to the bug report feature).
My product have both a supporter and a product manager interacting with the customers, and they generally file the bug reports. They have the contact with the customer and try their best to fill out as much as possible. That said, they're not developers and every now and then they cut the corner and need to be reminded that "I cannot press this button" is not good enough - unless the error is sporadic, always, and I really mean always, include a step by step guide to reproduce and include any files or input that might be needed, and double check that it's causing the error.
I wrote this post with mostly small teams in mind, but I'm also curious how much these principles apply to large tech companies such as Facebook, Google, or Amazon. Can anyone who's worked there or been in a similar sort of place chime in? I've only worked at smallish companies (<50 people) and startups (including my own).
Also, all other feedback you might have is greatly appreciated :)
I think this article is great and the first point is absolutely spot on. What I dont’t really agree with is that teaching end-users and clients to report issues the way developers want is the solution.
I think the communication gap between developers and non-developers can better be resolved with intelligent software. Ideally I think this would be something along the lines of:
• automatically detect when an error happens,
• provide a list of all the actions leading up the error,
• capture all the information it can about the user that experienced the error,
• take a screenshot automatically
• provide a simple way for them to communicate with devs, and vice versa
There’s no reason why a customer should need to know about milestones, assignment, error verification, etc... They should instead get a chance to say they have a problem, and then be notified sometime later when that issue is resolved.
We’re working towards this with http://www.bugherd.com from the bottom point up to the first. For instance when an issue is reported in BugHerd we capture as much user data as you can throw at us, information about the page they’re on and optionally an automatic screenshot. Other startups like https://www.getsentry.com are tackling this same thing from the other end by focusing on the error detection side of things and working their way down.
All in all I think bug trackers that pay as much attention to end-users as they do devs are doing it right, because as you say those are the people that are going to be reporting the bulk of the issues and the ones devs ultimately care about.
It might seem a little passive-aggressive, but it's amazing what some people consider to be a proper bug report. Try querying your tracker for issues with the title ".* is broken".
My product have both a supporter and a product manager interacting with the customers, and they generally file the bug reports. They have the contact with the customer and try their best to fill out as much as possible. That said, they're not developers and every now and then they cut the corner and need to be reminded that "I cannot press this button" is not good enough - unless the error is sporadic, always, and I really mean always, include a step by step guide to reproduce and include any files or input that might be needed, and double check that it's causing the error.