Closed Bug 965610 Opened 11 years ago Closed 11 years ago

Do not send "We're so sorry" mails

Categories

(Socorro :: Backend, task, P1)

Product:
Socorro
Component:
Backend
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: johannes.linke, Assigned: adrian)

Details

(Whiteboard: [config change])

I'm using nightly and had a crash. The crash reporter opened, i described what happened, and provided my email address where it said "Allow Mozilla to contact me about this report" Regardless what the exact wording there is, I expected to get questions regarding the crash or a notification that it got fixed or no mail at all. Instead, i got the "We're so sorry" email, which I did not expect. IMO there are multiple issues. 1. I entrusted Mozilla my email address, which i don't do with a lot of people/entities, and Mozilla forfeited this trust by using it for something which i didn't ask for. Now I wouldn't find it surprising if I got some surveys or other stuff in the next days, which is pretty bad for my image of Mozilla. 2. I belong to the possibly quite large part of Firefox' users who are able to google "Firefox crash" and find the link in this mail right on top of the search results. So if i really cared about fixing the crash locally on my PC, I could do so without the email. 3. I had a few crashes over the past years, each time I wanted to give Mozilla the possibility to contact me if it helps fixing the bug, and each time i got this mail. Receiving an email multiple times does not add any more information to it. 4. I don't see any reason why this can't be done e.g. with a about:crashed tab which is opened right after the next start. I like Mozilla, I like Firefox, I want to help and give you my email address when Firefox crashes, and I am seriously annoyed by these emails. I really hope it gets changed.
Summary: Do not send "We're so sorry mails" → Do not send "We're so sorry" mails
PS: I am aware that https://support.mozilla.org/en-US/kb/Mozilla%20Crash%20Reporter says i'll get this email with "support information". I don't think this is a valid excuse as people usually won't have read this page when experiencing a crash.
Component: General → Plug-ins
Product: Firefox → Core
I think I agree with the basic sentiment that we should email people only when we have questions or a solution to their problem. I don't think this is a "betrayal of trust", since we're only using it to email specifically because of a crash and not in any other capacity. But also, the generic instructions are typically not going to be that useful. > 4. I don't see any reason why this can't be done e.g. with a about:crashed tab which is opened > right after the next start. This is actually quite difficult, and is on my 2014 goals but requires understanding how much it would cost to process all crashes (currently we only use a sample of 10% of crashes from release users). Then we need to figure out how to deal with things like hooking specific crashes up to particular support articles and localization and other things. So rest assured that I'm looking at this problem closely but don't have a final plan in place yet! As for the request at hand, I do think we should stop sending the generic email. We should continue to send the more specific emails that we have set up for known crash reasons. Adrian can you make that change?
Component: Plug-ins → Backend
Product: Core → Socorro
I've had such annoying emails in the past shortly after sending crash reports for Firefox ESR but not for SeaMonkey trunk. I'm on Linux, so setting Hardware/OS to All/All.
OS: Windows 8.1 → All
Hardware: x86_64 → All
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Tony Mechelynck [:tonymec] from comment #3) > I've had such annoying emails in the past shortly after sending crash > reports for Firefox ESR but not for SeaMonkey trunk. Yes, we send those emails only for Firefox crashes at the moment. (In reply to Benjamin Smedberg [:bsmedberg] from comment #2) > As for the request at hand, I do think we should stop sending the generic > email. We should continue to send the more specific emails that we have set > up for known crash reasons. Adrian can you make that change? There are two things I can do: never again send the generic email (code change), or increase the minimum delay between two emails (currently 7 days) (config change, dead simple). As those automatic emails were commissioned by the SUMO team, I'd like to get Cheng's opinion here before doing anything.
As the product manager for Firefox crash handling, I expect to make the final decision here, but I do want to make sure that Cheng has seen this bug and had a chance to object. (use NEEDINFO!)
Flags: needinfo?(cwwmozilla)
I think we could do an effective single email if we had better actionable steps for people to do, but that may require building better things into FHR. Let's stop the email for now but re-open the discussion of making 3-4 generally useful emails (like "we think your crash is caused by an add-on: ______" or "we fixed it in the latest version of Firefox, please update here" or "we found similar crashes were caused by _____ third party software/malware"
Flags: needinfo?(cwwmozilla)
So, one concern I have when we stop this is that we go back to the bad behavior of having people specify an email address and not getting back to most of those people - which is not ideal. I'm not sure if the current email or that state is worse in the end, though.
I think we've been using this single email as a stopgap. Let's try to figure out a real solution.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #7) > So, one concern I have when we stop this is that we go back to the bad > behavior of having people specify an email address and not getting back to > most of those people - which is not ideal. When entering my emailadress i "allowed Mozilla to contact me". For me this does not mean "Please contact me" but "contact me when you need something or have news regarding the crash". I wouldn't feel obliged to send a mail just because the user entered an address. (In reply to Benjamin Smedberg [:bsmedberg] from comment #2) > > 4. I don't see any reason why this can't be done e.g. with a about:crashed tab which is opened > > right after the next start. > > This is actually quite difficult, and is on my 2014 goals but requires > understanding how much it would cost to process all crashes (currently we > only use a sample of 10% of crashes from release users). Then we need to > figure out how to deal with things like hooking specific crashes up to > particular support articles and localization and other things. Out of interest, could you further elaborate? I didn't mean to ask for about:crash-pages for specific crashes, only for the first (simple?) step of moving the content of the crash email to about:crashed. What would the disadvantage of this be compared with the mail? Sure, more help on specific crashes would be even better. And what do you mean by "processing 10% of all crashes"?
Adrian, for now please disable the generic email completely: we should keep sending the other emails for when we know the solution to a specific problem. Johannes, I didn't realize you were proposing opening a page for the "generic" content. I suspect that in general users just want to get back to what they were doing brefore the crash and we'd just be annoying them by popping something in front. On the other hand, if they are crashing regularly *or* we know how they can fix their problem, we can be more aggressive about it. That is the thing I'm working on. And yes currently we don't process every crash report from release users. For machine/storage/cost reasons we only process and classify 10% of those crashes.
Assignee: nobody → adrian
Priority: -- → P1
(In reply to Johannes Linke from comment #9) We actually put this in place because we kept getting a bunch of support requests along the lines of "I keep telling you about these crashes but you never tell me if you do anything about them". People interpret adding their email address as them sending us an email about a problem. The problem here is that if you send someone an email and all you ever get back is a canned autoresponder that isn't helpful, it's not actually better than not getting anything back.
(In reply to [:Cww] from comment #11) > (In reply to Johannes Linke from comment #9) > We actually put this in place because we kept getting a bunch of support > requests along the lines of "I keep telling you about these crashes but you > never tell me if you do anything about them". People interpret adding their > email address as them sending us an email about a problem. > > The problem here is that if you send someone an email and all you ever get > back is a canned autoresponder that isn't helpful, it's not actually better > than not getting anything back. Would it be feasible to have some preference to get autoresponder emails, or not get them? I know that they are sent from server-side, where the user's about:config is not available, but OTOH Breakpad sends the values of many prefs as part of the crash report: maybe this could be just one more of them. In that case, however, it would have to be parsed server-side to determine whether to send or not send an email which basically is just an ACK response.
(In reply to Tony Mechelynck [:tonymec] from comment #12) > OTOH Breakpad sends the values of many prefs as part of > the crash report sorry, it doesn't; I confused crash reports contents with about:support contents.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #10) > Johannes, I didn't realize you were proposing opening a page for the > "generic" content. I suspect that in general users just want to get back to > what they were doing brefore the crash and we'd just be annoying them by > popping something in front. On the other hand, if they are crashing > regularly *or* we know how they can fix their problem, we can be more > aggressive about it. That is the thing I'm working on. I thought a generic about:crashed is better than the generic email, but of course should be replaced by more specific pages sometime later. But you're right it might be annoying, and only showing it for frequent crashes or known crash reasons sounds very reasonable. (In reply to [:Cww] from comment #11) > (In reply to Johannes Linke from comment #9) > We actually put this in place because we kept getting a bunch of support > requests along the lines of "I keep telling you about these crashes but you > never tell me if you do anything about them". People interpret adding their > email address as them sending us an email about a problem. The title of the checkbox used to say "Email me when more information is available", which might explain this expectation some users had. I think with the current title "Allow Mozilla to contact me" this might be less of an issue.
Pull request: https://github.com/mozilla/socorro/pull/1896 This will require a configuration change to be resolved, in both our stage and prod config. In file `crontabber.ini`, in namespace [[class-AutomaticEmailsCronApp]]: - email_template='socorro_general_en' + email_template=''
Whiteboard: [config change]
Target Milestone: --- → 75
Commit pushed to master at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/849d97484963f13905caa1ec2364b5cca2375fc8 Fixes bug 965610 - Added an option to not send an email when the email template is empty. Require config change to actually fix the bug. r=peterbe
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
did the config change happen? should this bug stay closed?
The config change will happen during the next release of Socorro (75), probably today. And yes, we close bugs as soon as the fix has reached our master branch, and reopen only if a problem can be seen.
alright, thanks!
$ svn diff Index: files/stage/etc-socorro/crontabber.ini =================================================================== --- files/stage/etc-socorro/crontabber.ini (revision 82769) +++ files/stage/etc-socorro/crontabber.ini (working copy) @@ -53,7 +53,7 @@ #delay_between_emails=7 # Name of the email template to use in ExactTarget. - email_template='socorro_general_en' + email_template='' # ExactTarget API password. # see "secrets.exacttarget.exacttarget_password" for the default or override it here Index: files/prod/etc-socorro/crontabber.ini =================================================================== --- files/prod/etc-socorro/crontabber.ini (revision 82769) +++ files/prod/etc-socorro/crontabber.ini (working copy) @@ -53,7 +53,7 @@ #delay_between_emails=7 # Name of the email template to use in ExactTarget. - email_template='socorro_general_en' + email_template='' # ExactTarget API password. # see "secrets.exacttarget.exacttarget_password" for the default or override it here $ svn commit Sending files/prod/etc-socorro/crontabber.ini Sending files/stage/etc-socorro/crontabber.ini Transmitting file data .. Committed revision 82771.
You need to log in before you can comment on or make changes to this bug.