Bugzilla

To figure out how Mozilla uses the email address, we have a few options:

1. we could send a survey to a mailing list
   * pros: easy to set up and run and doesn't require engineering work
   * cons:
     * Travis and I don't think this is likely to be conclusively helpful since it's easily ignored; we could preface the survey with "We're considering removing this field ..." to increase the likelihood the survey isn't ignored
     * this only surveys people at a specific point in time
2. we could require an additional permission to see the email field
   * pros:
     * this increases the security of that data and reduces the unintentional usage of it
     * this tells us who uses it since they'll have to request permission
   * cons:
     * requires engineering work that we've avoided doing in the past (adding new permissions, adding new group)
3. we could change the webapp to hide the field by default and require a click to reveal
   * pros:
     * we get metrics on who's using it and how often
   * cons:
     * requires engineering work
     * we don't get usage metrics for people seeing the email address via the API or super search

I think item 2 is the most "we definitely get the data we want", but there's a bunch of risk around making changes to permissions and groups in the current codebase.

Item 2 seems doable. It catches the case where someone is looking at individual crash reports and goes to email the user, but doesn't catch other cases.

To figure out how Mozilla uses the email address, we have a few options:

1. we could send a survey to a mailing list
   * pros: easy to set up and run and doesn't require engineering work
   * cons:
     * Travis and I don't think this is likely to be conclusively helpful since it's easily ignored; we could preface the survey with "We're considering removing this field ..." to increase the likelihood the survey isn't ignored
     * this only surveys people at a specific point in time
2. we could require an additional permission to see the email field
   * pros:
     * this increases the security of that data and reduces the unintentional usage of it
     * this tells us who uses it since they'll have to request permission
   * cons:
     * requires engineering work that we've avoided doing in the past (adding new permissions, adding new group)
3. we could change the webapp to hide the field by default and require a click to reveal
   * pros:
     * we get metrics on who's using it and how often
   * cons:
     * requires engineering work
4. we can add metrics gathering to supersearch for when the user requests the email field

I think item 2 is the most "we definitely get the data we want", but there's a bunch of risk around making changes to permissions and groups in the current codebase.

Item 3 seems doable. It catches the case where someone is looking at individual crash reports and goes to email the user, but doesn't catch other cases.

Item 4 is doable, but the supersearch code is used both by users and heavily by Socorro itself. We'd need to distinguish the two cases somehow.