PostCrash: Difference between revisions

← Older edit

PostCrash (view source)

Revision as of 22:02, 5 July 2011

1,794 bytes removed , 5 July 2011

done

Rhelmer

canmove, Confirmed users

1,511

edits

@@ Line 1: / Line 1: @@
-{{DRAFT}}
+The goal of this project is to engage with users who provided an e-mail address in the Crash Reporter by
-The primary goal of this project is to engage with users who provided an e-mail address in the Crash Reporter by
 * Providing relevant info about their crash as well as general info about how to avoid crashes in Firefox.
 *Letting them know when their crash has been fixed in Firefox.
-A secondary goal is to develop about:crashes into a more useful resource for advanced users, with more info about the crashes upfront (e.g. signature, bug status, support documentation, Firefox fix status, etc) and add relevant pointers/info to Session Restore so people can find it.
 The project will require changes to SUMO and Socorro in order to supply the required functionality. For the secondary goal, Session Restore and/or about:crashes need to be changed, too.
-= Primary goal: Engage with users after Firefox crashes =
+= Engage with users after Firefox crashes =
 We should engage with users via e-mail in the following situations:
@@ Line 16: / Line 12: @@
 * After a bug has been fixed and shipped in a Firefox release, to inform the user that the bug is fixed in Firefox version x.y.z. This will also work as a powerful way of retaining users, including getting users back who may have switched to another browser between the crash report and the fix.
-== When submitting the crash report ==
+== When submitting the crash report (Q1 2011) ==
 This e-mail will be automated:
@@ Line 32: / Line 28: @@
 Issues with regard to authenticity of email / phishing can be addressed by encouraging users to "visit mozilla.com and click on blah for more information" (taking a lead from Paypal/eBay here).    We should make sure that emails come from a mozilla.com address and use whatever we have in place for email authentication.
-== When new support documentation is available (lower priority) ==
+== When new support documentation is available (Q4 2010/Q1 2011) ==
 This e-mail will be automated:
@@ Line 40: / Line 36: @@
 Generally, this e-mail should make the new information prominent, but otherwise retain the language and key messages of the initial e-mail.
-== When a bug has been fixed in a shipped Firefox release ==
+== When a bug has been fixed in a shipped Firefox release (Q4/October) ==
 This would in part be a manual workflow:
-# A Firefox bug is fixed in Bugzilla.
-# A cron job notices when a bug associated with a crash signature is fixed, and puts it in a queue for the QA team.
-# The QA team maintains this list of fixed signatures and keeps track of which Firefox release a fix is targeted for.
-# When a fix is scheduled for a final Firefox release, the QA team passes over a list of crash bugs fixed to the SUMO team.
-# The SUMO team writes personal (based on a template) messages for each such fixed crash, explaining in which Firefox version the bug has been fixed and what steps to take next for the user.
-# The messages are sent to each user who submitted a crash report with that crash signature.
-# The item is removed from the QA queue.
-===Suggested alternate workflow===
-(Laura) I think it's better to drive this from the Bugzilla end, as follows, as it's less work and hence more achievable in the time frame:
 # When a release is planned generate a list of fixed bugs (from Bugzilla)
 # Provide facility in Socorro to search by Bugzilla bug for a list of associated crashes
 # For each associated crash, generate a list of user submitted emails (minus any users who have said they don't want to be emailed again) - this function should be available only from the admin interface
 # Mark those emails as contacted for that given crash, so we don't contact them again.
-Do we want to provide functionality to email these users in Socorro?  This feels like it belongs in a different system. Providing Support with a list of emails per crash bug should be enough for version 1.
-= Secondary goals (not essential for this project) =
-== Session Restore dialog ==
-[[File:Post-crash_session_restore_flowchart.png|200px|thumb|right]]
-We want to make sure that more users are exposed to the already existing troubleshooting info about specific crashes, as well as general tips and advice on how to minimize crashes by keeping plugins up to date, etc.
-A good opportunity to do that is just after Firefox resumes from a crash. The Session Restore dialog should check if Firefox has crashed more than x (e.g. 3) times in the last 24 hours. If so, it should at the very least display general tips/advice for avoiding crashes, but it should also query Socorro/SUMO to see if there is specific support available for the crash and show that as well.
-The flowchart to the right illustrates the desired logic.
-On the SUMO side, there would be specific articles for known crash signatures (this is already the case for many crashes today), as well as a generic checklist guide for things a user should do to avoid crashes.
-== 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 a bug is resolved fixed, show the version it was fixed in.
-* if a 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 will by default only show an expanded view for the most recent crash.  Users may individually expand other crashes (something like "check crash status" on each previous crash).
-Question:
-* Should we show both hangs and crashes?  Users may load the page and see  nothing but hangs.  Does it make more sense to (perhaps by default) just show crashes?
-Changes to Socorro:
-* Add a webservice call.  Given crash id, return signature, associated plugin, associated bugzilla id and bug status.
-Possible mock
-[[File:About_crashes.png|600px]]
-==Early idea on a revamped about:crashes page==
-[[File:About-crash.png|600px]]
-* The latest crash automatically queries SUMO and Socorro for status info.
-* Older crashes might not query the servers automatically to reduce server load.
-* To reduce information overload, the crash ID isn't shown, but clicking on the signature takes you to the full report on Socorro.
-Some additional thoughts/ideas:
-* Would be even better if the page could query SUMO for the full article title and show that instead of "View solution" (the SUMO service should also support l10n to make sure that a localized article title appears if it exists).
-* The latest crash could be more prominently highlighted -- perhaps even have a separate section above the "Recent Crash Reports".
-* The generic support link at the bottom could be expanded into its own section. The target link could take you to a start page specializing on crash/hang problems, with prominent links for how to upgrade plugins, etc.
 =Technical requirements=
@@ Line 138: / Line 69: @@
 *# If a canonical article exists for crash_signature (top search result), return the title and URL
 *# Else if other search results exist for crash_signature (e.g. forum threads), return URL to search results
+* Should be available sometime the week of March 14th.
+** See [https://bugzilla.mozilla.org/show_bug.cgi?id=631341 bug 631341].
+=== API ===
+Will be available as of SUMO's 2.6.2 release. Scheduled for 15 March 2011.
+ GET /postcrash?s=<signature>
+Return values:
+ HTTP/1.0 200 OK
+ Content-type: text/plain;charset=utf8
+ http://support.mozilla.com/...
+or
+ HTTP/1.0 404 Not Found
+A request without an <code>s</code> parameter will result in
+ HTTP/1.0 400 Bad Request
+Responses may set caching headers. Conditional GET is encouraged. Consumers should wait before requesting again in the event of a 5xx error.
+=Timeline=
+* <strike>Monday Sept 13: Meeting with QA to establish QA/Support workflow</strike>
+* <strike>October: Socorro 1.7.4 freeze (Socorro)</strike>
+* <strike>October: Socorro 1.7.4 push (Socorro)</strike>
+* <strike>October 22: Finalize e-mail template to send out for fixed bugs (Michael/David)</strike>
+* <strike>November 22: Finalize e-mail for [Russian crash] (David)</strike>
+* <strike>November 22: Finalize support e-mail FAQ and support article for Russian crash (David)</strike>
+* <strike>November 24: Have e-mail + support article + FAQ localized into Russian (Alexander)</strike>
+* <strike>November 30: Test e-mail campaign to a select number of people to ensure that the e-mail encoding is correct. This can be done on stage. (Laura/IT)</strike>
+* <strike>December 14: Push out Socorro 1.7.5.4 which adds support for UTF-8 encoded e-mails (Laura/Socorro/IT)</strike>
+* <strike>December 15: Send manual e-mail to users experiencing the Russian crash and use this as a basis for establishing additional requirements for Phase 2 in Q1 2011. (Michael/David/Austin/Christian)</strike>
+* <strike>December 17: Follow up with Daniel to determine hit rate (David)</strike>
+* <strike>December 17: Send out e-mail to the remaining Russian users</strike>
+* <strike>December 23: Finalize PRD to include requirements for Phase 2 in Q1 2011 (David)</strike>
+* Ongoing - Next Firefox 3.5.x/3.6.x release: Complie a list of actual crash bugs fixed (Christian)
+* Ongoing - Next Firefox 3.5.x/3.6.x release + 7 days: Send out first "crash fixed" e-mails (Michael/David/Christian)
+=Future requirements=
+* Ability to define a campaign with multiple crash signatures, each with its own set of filtering restrictions (product, versions, etc)
+* Ability to wildcard Firefox versions (e.g. "3.5.*,3.6.*")
+* Ability to specify whether a campaign is for a fixed or ongoing crash issue (which determines whether this is the final e-mail campaign for those users, or if we are allowed to send additional information in the future)
+* <strike>Asynchronous sending of the e-mail -- currently you have to select a really small date range because otherwise the system times out. If this could be changed to e.g. a backend query/job, sending e-mail in a large campaign would be much more straightforward.</strike>
 =Questions/Discussion=
@@ Line 147: / Line 126: @@
 ** Do repeated crashes mean repeated e-mails to the users with the same message, or do we track so that we don't keep telling users there is no fix for their crash yet?  if we don't track it the e-mails start to look like spam. --chofmann
-* we could be over engineering things here.  the system that we had with talkback served a good purpose.  when we found a specific crash that we had something specific to tell users about,  we constructed the message, then we queued up the system to watch for that signature and send the message.  This was for a very small number of the total overall crashes, but had useful information as opposed to just auto-responding. e.g.
+* we could be over engineering things here.  the system that we had with talkback served a good purpose.  when we found a specific crash that we had something specific to tell users about,  we constructed the message, then we queued up the system to watch for that signature and send the message.  This was for a very small number of the total overall crashes, but had useful information as opposed to just auto-responding. e.g. "from your recent crash we detected that you need to upgrade to Skype X.X to fix the crash."
- "from your recent crash we detected that you need to upgrade to Skype X.X to fix the crash."
+** For the record, this is pretty much exactly what this project is about: reaching out to users when we actually have something meaningful to say (like "your crash has been fixed").
 At any particular point in time we might have something this specific to say in an extremely low pct. of cases.  Numbers below indicate this might be lower than 1% of the time a user reports a crash to us.
@@ Line 177: / Line 156: @@
 -chofmann
 </pre>
+* The 3.6% might be heavily affected by the fact that the checkbox is unchecked by default. I.e. an insensible default. Can we change that?