How granular do we need permissions to be about emails to Webmaker users from the Webmaker services?
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?
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.
: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?
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?
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.
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* ...
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.
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?
This plan is fine with me. For terminology's sake, there is only the Mozilla E-mail List - no separate Webmaker list.
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?
works for me
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.
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
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: u=dev c=login p=1 → see comment 9 and comment 14 for decisions
You need to log in before you can comment on or make changes to this bug.