864406 - Granular opting in/out of email communication from Webmaker

Status: RESOLVED FIXED

(Webmaker Graveyard :: Login, defect)

Description

[Kieran Sedgwick (:sedge)]

How granular do we need permissions to be about emails to Webmaker users from the Webmaker services?

Comment 1

[Ross Bruniges [:boozeniges]]

I liked the idea of having a flags object that we could add a number of things to personally but there were problems with updating that I remember you mentioning?

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Ryan/Erica: we need to understand the *required* granularity for Webmaker emails. Broadly speaking, there are two categories of email we plan on sending:

 - notifications direct from the Webmaker site & tools to users (ex: claim this make, badge related notifications, etc)

 - engagement emails sent from Blue State Digital (ex: campaigns, re-engagement, etc)

The question is: do we want separate opt-out options for these types of email, do we need even finer grained opt-outs (ie: multiple opt out types for BSD notifications) or is a single "never send me mail, ever" good enough?

Also including cassiemc as this has a UX impact.

Comment 3

[Kieran Sedgwick (:sedge)]

:booze - I fixed that by removing the nesting of all flags under one attribute.

Here's a better description of this bug:

The Webmaker Login SSO will require (to some degree) granular dependancies for all email communications to users.  Perhaps an opt-out system?

Comment 4

[Ryan Merkley]

I'm not sure I understand the question. On sign-up, are we adding people to the general Mozilla mailing list and tagging them, or are we adding them to a user mailing list and tagging them?

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Ryan: on sign up, we are collecting email addresses.

What we're asking is: what granularity of email opt-out do we want (or need, for regulatory or privacy policy or values compliance) to be offering?

What I'm providing as context is that we have various reasons to email users, but broadly they fall into notification purposes (as regards the activities and tools available) and engagement purposes (segmentable by user metrics, but not 1:1 correlated with a specific action or event in the tools and system)

Helpful?

Comment 6

[Ryan Merkley]

Users should be told what they're being signed up for, and they should be able to opt-out completely or in part. Ideally, they can decide to keep their account but not be on the Mozilla mailing list, etc., and do that from a single opt-out dialogue.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Oh, erg, that's another question I hadn't thought of; should we be prompting them to join the Mozillians email list? I'd suggest that be opt-*in* instead of opt-*out* ...

Comment 8

[Ryan Merkley]

Yes, we'd like to offer them the chance to get on our updates list. I also want to balance that against  the amount of things we ask for up front to minimize the drop-out.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

In the interests of moving things forward, here's my proposal:

 * allow users to opt-out of engagement email
 * do not allow users to opt-out of notification email

This implies:

 * from a UI perspective, it's a single "Do not send me email about the Webmaker program" opt-out checkbox when creating an account - when a user opts-out, we won't pass their email address through to Blue State Digital on any future export actions

 * we can, however continue to send re-activation emails as a system notification task with whatever solution we end up using for system notification emails

 * we can optionally prompt users to join the Mozillians email list as a separate task anywhere along the sign-up or user engagement flow, as an opt-in request

Ryan, Cassie, Brett: so say we all?

Comment 10

[Ryan Merkley]

This plan is fine with me. 

For terminology's sake, there is only the Mozilla E-mail List - no separate Webmaker list.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Ryan: help me understand that; are you saying that whenever you pull information for Blue State Digital to use, that would be branded/presented as a "Mozilla List" mail out as opposed to a "Webmaker" mail out? Additionally, would you plan on sending those users (who only signed up via Webmaker) email about non-Webmaker activities?

Comment 12

[Brett Gaylor [:brett]]

works for me

Comment 13

[Ross Bruniges [:boozeniges]]

Going to add Ben Simon - who knows BSD and the legal policy on emails to this thread.

From my understanding if we're proposing adding a user to our BSD list when they sign up:

* we can add them to an additional webmaker group - this provides us the granularity between the all-mozilla list and an additional webmaker list
* we are legally *required* to include the text "Yes, I'd like to receive updates about Maker Party 2013, and I’m okay with you handling this info as you explain in your privacy policy" next to a checkbox

:bsimon - can you confirm those two things for us?

Normally not clicking the checkbox would mean the form can't be submitted but I think in this case we can just not sign the users up to the BSD list we choose.

In addition - just want to confirm that we can't directly enter people into the Mozillians emailer as it requires users to be vouched Mozillian in the Mozillians DB, so yeah, suggesting people join, I believe :beltzner is suggesting is the way to go.

Comment 14

[Ryan Merkley]

Beltzner: There is no "Webmaker" list. We manage the Mozilla list, where we talk about all things Mozilla, including (and to be honest, predominantly) Webmaker and fundraising. That is separate from Mozillians and their list. It's a consumer/supporter list. 

The text for sign-up is something like "Get Mozilla Updates. We will only send you Mozilla-related information." On sign-up, we could segment them as Webmaker users in BSD, but starting a separate "webmaker mailing list" is a can of worms I'd rather not open.

We never do auto-opt-in. Ben is fluent in our procedures, but the basic principle is people know what they're getting into, and we declare what we'll use their information for up front.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Cool; Kate - please see comment 14 here and keep it in your brain case for when you're designing the sign up flow. Looks like the proposal in comment 9 is going forward, and from a UI perspective this will be an opt-*in* request at the point that we create a Webmaker account for someone, expressed as indicated in comment 14

Comment 16

[Ben Simon]

Seems to be well-covered already, but what I think will likely make the most sense is 2 checkboxes (both unchecked):

1) 1, required, the says you agree to privacy policy and will get some webmaker system notifications
2) 1, not required, opting you in to receive Mozilla email updates (what Ryan describes in comment 14).