Bug Reporting workflow for end users
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
- Started by
- Completed by
Whiteboard
https:/
Current Scenario for bug reporting:
https:/
http://
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:/
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:/
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
