Kuma: Allow user to opt-in to MDN news and promotional emails

[nickbrandt]

User story

As a user, I want to be able to opt-in to emails about MDN news and promotions, so that I can be up to date on what's happening on MDN if I choose.

Acceptance criteria

• [ ] Display checkbox on Create MDN Profile page
• [ ] Display checkbox on MDN Profile page (in personal section)
• [ ] If this option is checked on the Create MDN Profile page, this is reflected on the MDN Profile page after the account has been created
• [ ] This option is stored as a flag in the db that we can reference when sending out emails
• [ ] check box copy says: "Get updates on what’s new with MDN to your inbox."

Tasks

• [x] Finalize copy (Kadir)

Design

Create MDN Profile Page:
InVision: https://mozilla.invisionapp.com/share/Y8SGMKQBCW3#/368129372_Create_Account_-_MDN_Profile
Zeplin: https://zpl.io/2jYxqKp

Profile Page (personal section):
InVision: https://mozilla.invisionapp.com/share/Y8SGMKQBCW3#/372750124_Account_-_Profile_-_Filled
Zeplin: https://zpl.io/adN5yJE

[jmswisher]

To be continued in next sprint.

[schalkneethling]

I am going to transfer this issue to Kuma or else I am totally going to forget about it ;)

[schalkneethling]

Hey @escattone,

Should I add a newsletter checkbox to the current sign-up form, I assume there is some back-end work that needs to happen before the data will actually be handled properly correct?

Is this work blocked on https://github.com/mdn/kuma/issues/5792 or, does it makes sense to do the front-end work but, hide it behind a Constance setting?

Thanks!

[escattone]

Should I add a newsletter checkbox to the current sign-up form, I assume there is some back-end work that needs to happen before the data will actually be handled properly correct?

Is this work blocked on #5792 or, does it makes sense to do the front-end work but, hide it behind a Constance setting?

I think @Gregoor is taking this work on the back-end, so he'll have the final word, but I think you could go ahead and add a checkbox to the current sign-up form, but include/exclude it based on a simple python-decouple/environment variable in kuma/settings/common.py, something like:

ENABLE_NEWSLETTER_SIGNUP = config('ENABLE_NEWSLETTER_SIGNUP', default=False, cast=bool)

that you'll then have access to settings.ENABLE_NEWSLETTER_SIGNUP in the Jinja template.

[schalkneethling]

Thanks, @escattone. That was my thinking as well. Total tangent but, now I hear you speak of a third mechanism for these things 🙈 😸

I get that Constance is essentially an on-off switch and Waffle is an on-off switch on low-grade steroids ;p Where does python-decouple fit into this picture? i.e. when should we use which option?

The distinction between Constance and Waffle seems clear to me, but what is the difference between Constance and python-decouple?

[atopal]

@schalkneethling I don't see it in the invision deck, the language of the check box has to be changed, it's now: "Get updates on what’s new with MDN to your inbox."

[schalkneethling]

@schalkneethling I don't see it in the invision deck, the language of the check box has to be changed, it's now: "Get updates on what’s new with MDN to your inbox."

Hmmm, that reads a little odd to me. How about:

Get updates on what’s new with MDN delivered to your inbox.

or,

Get updates on what’s new on MDN delivered to your inbox.

Thoughts @atopal?

[atopal]

That's the wording proposed by our legal counsel. I do like yours a bit better, Schalk, and would normally just go with that, but I don't think it's worth holding back and the several day long back and forth with legal to optimize that.

[escattone]

@schalkneethling

I get that Constance is essentially an on-off switch and Waffle is an on-off switch on low-grade steroids ;p Where does python-decouple fit into this picture? i.e. when should we use which option?

I think a python-decouple/environment variable (i.e., something like ENABLE_NEWSLETTER_SIGNUP = config('ENABLE_NEWSLETTER_SIGNUP', default=False, cast=bool)) is the best option going forward, certainly for anything that changes infrequently (perhaps on the order of once a month at most?). On the one hand, it's much simpler (no dependencies other than the very simple config from python-decouple) and faster (the code references a simple variable rather than making calls to the Redis cache and/or the database to get the value on every request). On the other hand, changing the value involves submitting an infra PR to change a setting (simple though) and then deploying, which isn't a big deal but definitely more involved than changing the setting via the Django admin console.

I'd like to avoid using Waffle or Constance going forward, mainly because it doesn't really fit with the future JAMStack approach of Yari/Stumptown, but there may be specific use cases where it still makes sense.

[schalkneethling]

Thanks so much for the detailed feedback @escattone, much appreciated!

[Gregoor]

Note from working with the basket/salesforce API before: They don't like us to manage the actual subscription state on our side, hence after setting that checkbox initially we should either disable it or completely hide it. Users are then able to manage their subscription status through the "footer"-link in the newsletters mails.

You can see that flow in action by signing up at voice.mozilla.org and visiting profile/settings.

[schalkneethling]

Note from working with the basket/salesforce API before: They don't like us to manage the actual subscription state on our side, hence after setting that checkbox initially we should either disable it or completely hide it. Users are then able to manage their subscription status through the "footer"-link in the newsletters mails.

You can see that flow in action by signing up at voice.mozilla.org and visiting profile/settings.

:+1: Thanks for the info @Gregoor. It will then only be shown once during the sign-up flow. And then it will be managed, as you mentioned, via the emails themselves.

I guess if a user did not choose to sign-up for the newsletter during sign-up, we might provide them a second opportunity to do so via their profile. Even then though, once they have subscribed, we will have no UI to manage subscriptions.

[Gregoor]

I assume this was closed accidently, so I reopened it

[Gregoor]

Oh I shouldn't only view things on ZenHub, it didn't show that this was closed by a commit 🙈 I think the backend issue is enough to track this now (where I'll also wire up the frontend with it), so closing it again