Confirmed users, Bureaucrats and Sysops emeriti
1,531
edits
PostCrash: Difference between revisions
→Questions
No edit summary |
ChrisHofmann (talk | contribs) |
||
| Line 44: | Line 44: | ||
==Questions== | ==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)? | * 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. | ** the period of when bugs get fixed to when the crash happens might be very long. bugs being fixed on the trunk now might not be available in a final release until end of q3 or q4. It doesn't make much sense to e-mail users now about fixes that won't appear in a final firefox 4.0 until then, or e-mail them at the end of the year about that that crash they had 6 months ago. A single signature with many bugs makes it nearly impossible to correlate if any one of the bugs might have fixed the specific bug that the user just crashed on. we would need to start storing the full stack trace(s) of the bugs that we have fixed and map them to the full stack trace that the user experienced. -chofmann | ||
* 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. | |||
** Also depend on what events we send e-mails for. (see below: expect to send about 12k e-mails per day for just incoming reports where we are auto responding when a user sends us an e-mail address, and around 5k per day if we e-mail when there is a bug on file associated with the signature) -chofmann | |||
** 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. | |||
"from your recent crash we detected that you need to upgrade to Skype X.X to fix the crash." | |||
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. | |||
* sending e-mails with technical instructions on how to fix or mitigate crashes, and espcially instructions that involve downloading and installing software is open to impersonation, and phishing. we need build in ways for users to authenticate that the message came from mozilla and that the same instructions are available on an "offical" mozilla hosted website. | |||
<pre> | |||
some numbers on: | |||
-count of reports that have e-mail address, | |||
-total crashes per day, | |||
-ratio of e-mails to total crashes | |||
-signature has e-mail and an assigned bug | |||
-ratio of signatures with emails and assigned bugs to total crashes | |||
-ratio of reports with e-mails to reports e-mails with bugs. | |||
date email=yes #crash email/crash w/bug email/w-bug email/email-wbug | |||
20100530-crashdata.csv 12596 341229 0.0369136 4319 0.0126572 0.342887 | |||
20100531-crashdata.csv 13567 372037 0.0364668 4784 0.0128589 0.35262 | |||
20100601-crashdata.csv 13941 378282 0.0368535 5053 0.0133578 0.362456 | |||
20100602-crashdata.csv 13806 379287 0.0363999 4793 0.0126369 0.347168 | |||
20100603-crashdata.csv 12353 332924 0.0371046 3855 0.0115792 0.31207 | |||
-chofmann | |||
</pre> | |||