PostCrash: Difference between revisions

1,098 bytes removed ,  5 October 2010
Line 36: 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.
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 (Q3) ==
== When a bug has been fixed in a shipped Firefox release (Q4/October) ==


This would in part be a manual workflow:
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)
# 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
# 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
# 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.
# 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.


=Technical requirements=
=Technical requirements=
1,623

edits