Bug Reporting workflow for end users

Registered by Nicholas Skaggs on 2013-08-16

Recently, reporting bugs has come into the limelight as a potentially difficult propostion for an end-user of ubuntu. Bugs are an important part of software, and users need a reliable way to report issues with there devices running ubuntu. In addition, as ubuntu enters the world of phablet devices it's important to understand the user story for reporting bugs from these devices.

Let's talk about potential enhancements to apport, the instructions for reporting a bug, and cover use cases like

Application crash
Non-crashing/Weird application behavoir
System crash
Background failures/crashes

Blueprint information

Status:
Not started
Approver:
Jono Bacon
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

https://bugs.launchpad.net/ubuntu/+bug/1212356

Current Scenario for bug reporting:
https://bugs.launchpad.net/ubuntu/+bug/1212356

http://summit.ubuntu.com/uds-1308/meeting/21857/foundations-1308-click-error-reporting/

Feedback:

Tools:
Apport
Whoopsie

Use cases:
Application crash
Non-crashing/Weird application behavoir
System crash
Background failures/crashes

* What is a bug? Could we use more ask.u.c, and have an upgrade process to bugs?
  * needs i18n

most common use case for bugs:
ubuntu-bug package name

helps gather log files and file the bug report

in launchpad, "report a bug" links are restricted to ubuntu bugcontrol members or to those that know the "secret". Some abuse it.

ubuntu-bug -w, let's you select a click a window instead of needing to supply a package name

ubuntu-bug, presents a dialog allowing you to select a symptom that is presenting itself

automated crash reports:
automated crash system
--replace manual process to understand how often issues are occuring
whoopsie watches for errors, to submit to

errors.ubuntu.com

65 million+ reports recieved and cataloged

lower the barrier for a crash report to be pushed to

phablet
dialog for crash report will happen first
on the desktop an application will disappear, while on mobile an app can disappear as normal interaction

recoverable errors;
developer intiated report

also will work on touch

https://wiki.ubuntu.com/ErrorTracker

Goal is reduce feedback loop, not require end user to manually push information about a misbehaving application
In addition developers can get more information without requiring a

Server side hooks
hooks in apport that allow you to send additional information that go beyond the traditional whoopsie report

Submit a report, server checks to see if developer wants additional information, if yes, the information is gather and then pushed to the server along with the data

What about "other" bugs? design bugs or user papercuts, unexpected features, etc

"hard" to report a bug is intended
-need to file a bug report in english
-need to be technical
-bug reports that are not of high quality cannot be used

phablet devices:
audience likely even more non-technical than desktop users
how to filter bug reports from the phablet devices for a technical audience?

create a link to push someone to traditional bug reporting,
  "submit a technical problem report" - or wording like that

ubuntu-bug does not know about click packages and they don't necessarily use Launchpad
-could be taught about it, but currently tied to apt

click packages potentially could have a url or feedback link intended for this

rather than working towards better manual reporting or feedback, plug any holes found in automated reporting
-serious bugs should be able to be automatically captured
-wishlist bugs, improper interaction (bad data) won't be :-)
-augment/adjust tools to find a package (e.g., a wrapper for apt-file, or dpkg -S)

So casual users provide feedback in review
Technical users could be pointed to filing a bug
-- define url / intergate with my-apps and ubuntu-bug

how can we collect and send data without knowledge of the destination server?

encode the url string with say the version for inteperation?

- so ex.: https://github.com/evandandrea/myapp/fileissue?version=%v (%v would be substituted for the installed application version or null if it wasn't installed)

how to determine if someone is a technical user / developer or a casual user?
-require a developer mode or flag?
-opt in on a system level?
-control via application UI?

leave in the hands of the application developer

do we push desktop users towards ratings and reviews similar to how we plan to handle it on the phone?

report a problem -- push to review and not a wiki page

(?)

Work Items

Work items:
[nskaggs] research changing process towards ratings/reviews for applications instead of bug reports for end users: TODO
[nskaggs] review usage of ask.u.c, answers.lp.com, review process, as "official" outlets for users encountering issues on the desktop: TODO
provide "feedback/bug report" URL (optional) in MyApps (per package): TODO
allow a %v (package version number) substitution in the bug report URL: TODO
for ubuntu packages, the bug report URL should spawn "ubuntu-bug <pkgname>" (implied LP URL, but with extra data): TODO

This blueprint contains Public information 
Everyone can see this information.