1,107
edits
PostCrash: Difference between revisions
no edit summary
(Created page with 'The goal of this project is to improve the user post-crash experience by: * Developing about:crashes into a more useful resource * Contacting the user by email after a crash is r…') |
No edit summary |
||
| Line 1: | Line 1: | ||
The goal of this project is to improve the user post-crash experience by: | The goal of this project is to improve the user post-crash experience by: | ||
* Developing about:crashes into a more useful resource | * Developing about:crashes into a more useful resource | ||
* Contacting the user by email after a crash is resolved | * Contacting the user by email after a crash is resolved | ||
The project will require changes to about:crashes, SUMO, and Socorro in order to supply the required functionality. | |||
= about:crashes = | |||
We want to make about:crashes more useful. Ideally, for each crash we would display: | |||
* the crash id | |||
* the crash signature (source: Socorro) | |||
* associated bugzilla ids (source: Socorro) and status of these bugs (source: Bugzilla or Socorro) | |||
* if s crash is associated with a plugin, link to plugincheck (source: Socorro) | |||
* If a canonical SUMO article exists, a link to that article, otherwise a link to SUMO search for that signature (as is currently done in Socorro) | |||
The client should obtain the extra information from Socorro and SUMO via XHR. This data should be stored locally once final. Final data includes: | |||
* crash signature | |||
* bugzilla ids for RESOLVED bugs | |||
* plugin association | |||
* canonical SUMO links | |||
Data that should be polled each time about:crashes is loaded includes: | |||
* Status of bugzilla bugs that were unresolved last time about:crashes was loaded | |||
* Search for a canonical SUMO article where one previously didn't exist | |||
In order to minimize load on Socorro and SUMO, we may only show this information for the last n crashes (where n is a smallish number, yet to be determined, perhaps even 1). We could display a link to "check crash status" on each previous crash. | |||
== Changes to SUMO == | |||
* Add a table that stores links between articles and signatures. The relationship may be m:n but is definitely 1:n. | |||
* Add a webservice call that searches for a canonical article and returns it if it exists. | |||
== Changes to Socorro == | |||
* Add a webservice call. Given crash id return signature, associated plugin, associated bugzilla id and bug status. | |||
= User email contact = | |||
This requires changes to Socorro. | |||
Periodically, we should run a job that does the following: | |||
* For each crash with a supplied user email address | |||
** Check the status of associated bugs | |||
** If an associated bug is resolved, queue an email to the user with the date of the crash, a link to the bug, and information about the version of the product in which this bug was resolved. | |||
==Questions== | |||
* Some crashes have more than one associated bug. Should we email the user each time a bug is fixed or when all the bugs are fixed (or some other model)? | |||
* What volume of users supply emails? (Check: For each of the topcrashers, how many associated user emails do we have?) The architecture of the solution for sending email depends on the volume. | |||