[mmilo]

The reason it takes hours to verify whether an issue is even an issue is because people that consume tech describe problems like this "My shit just broke, help!" while people that build tech need something like "I was logged in as an admin user on the dashboard interface using Firefox v.18 and I clicked on the submit button and validation didn’t work".

Most bug trackers worry about how best to show you a list of issues, the thing is if most of those issues aren’t reported correctly they’re useless.

We’re currently trying to resolve this problem for web devs specifically by creating an embedded tracker, where you integrate the bug reporting directly into a site or web app. Meaning people can report issues in the way that’s natural for them e.g. "this is broken" and the tracker handles capturing all the other data a dev needs to verify and fix the problem. Our app can be found at http://www.bugherd.com if it’s of any interest to anyone.

[Zak]

A big part of the problem is social, not technical. A bug report is essentially a set of instructions for a person who knows how to operate the software, but not necessarily anything else about the user's situation to follow. Most people are not used to writing instructions without conversational feedback and have a hard time figuring out what information in relevant and what to leave out.

For a high-volume end-user project like Chrome or Firefox, a wizard/flowchart type UI probably ought to be the default, with a more streamlined UI available to people who have been approved by admins or met some criteria programmed in to the system. An example of the process a user might go through is:

What's the problem? -> A web page doesn't look right in Chrome -> Have you tried it in another browser? -> No -> What other browsers do you have? -> None -> Ok. Here's a list of browsers that run on your OS and where to get them -> Firefox -> Ok, does it look right in Firefox? -> Yes -> Do you know how to take a screenshot?

And so on until the user has likely provided enough information for a good bug report. There could be short-circuits in the process - for example, when asking if the user has tried another browser, a small link a bit outside the main UI could say "I've tried another browser and I have screenshots from both".

[bruceboughton]

I'm not sure that encouraging users to download another browser to try the page in would (a) encourage many bug reports (b) be a great idea for user retention.

[Zak]

"Does it work in other browsers" is a standard question I've seen in templates in bug databases for open source browsers for rendering issues. Encouraging many bug reports probably shouldn't be a goal for a project with as large a userbase as Firefox or Chrome; encouraging actionable bug reports should be.