PostCrash

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 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.