Cool, when would it make sense to discuss this further? Happy to outline
our expectations and see what might work within the constraints of our
system.

So this is the form at https://www.mozilla.org/en-US/newsletter/ ?

That looks a lot like our opt-in form, plus HTML/text and country/language preferences. Would we want to add those to the opt-in form?

Here it is! https://www.mozilla.org/en-US/newsletter/existing/8813b665-cfa8-495b-ada5-9c0a9c011522/. Feel free to play with my preferences if you want--I'm opted into this list with multiple email addresses 🤓

Spec doc for the preference center here: https://docs.google.com/document/d/1wKtGxJn06bs6OGAFV7DKUfVw2salKdU_NAUn5SMGks0/edit#

@DStrine can you update the task description accordingly? And feedback most welcome on the presentation of this info!

@NNichols @MBeat33 @kaythaney @LeanneS I'd love any of your thoughts on this as well. Any ideas of what could be missing here? Suggestions for preference types? Think it over! Please add in suggestion mode or make comments. Thanks!

@XenoRyet are you taking a look at this? @Ejegg thought he remembered you saying you might.

Note definition of done, with Phab tasks listed, but not created.

@mepps Yea, this is on my list. Sick kids have kept me from getting too far yet, but I believe the plan for this sprint was to do enough investigation to scope it out, decide on an approach, and see where we'd want to slot it into the schedule.

Possible tasks:

Finish decommissioning old unsubscribe and move that functionality to the new system

• Should really get this squared away before we start expanding the system.

Create the preferences center form

• We can use opt-in as a start, but this one will obviously be more complex.
• Seems like we're ok with the non-public link and contact ID plus hash being secure enough, can borrow that logic from opt-in as well.
• Will need some front end design work.

Create the queue consumer to get the data to civi

• This bit should be fairly straightforward as long as we nail down the form and the civi DB changes first.

Civi database changes

• New fields will be needed to provide this level of granularity
• Current functionality of the opt-in and unsub fields will probably need rethinking and reworking. Do those fields override fine grain preferences or not?

Civi UI changes

• This data will need to be displayed in civi, and could pretty quickly get cluttered. We'll need UI changes if we want to do more than just cram this all in the communications section.

IBM export changes, possibly more IBM work

• The export will need to accommodate the new data by having a seperate file for each kind of preference.
• Also might require a seperate file for donors opting in to specific lists, rather than opting out if we go for that functionality. I think we should.
• This might end up being a near total rewrite of the exporter.
• Changes to the import process on the IBM side. This seems like the bit with the most unknowns.
• Possible other IMB work to properly make use of these new fields.

Create a button in civi to generate links.

• Nice to have, but shouldn't be too hard.

Create variants on the preferences form

• Not necessary for minimum viable product, but probably necessary before too long.

Thanks for scoping this out, @XenoRyet, seems like a pretty thorough
approach to me!

For the front-end design work required, sh ok old we have our designers get
working on that, or wait until we have some sort of prototype to work with?
I could see it going either way and mostly want to prevent us designing
something that feels hard to implement. If that doesn't feel like a concern
to you, we can start putting something together soon.
Le mar. 20 août 2019 à 1:49 AM, XenoRyet <no-reply@phabricator.wikimedia.org>
a écrit :

XenoRyet added a comment. View Task
https://phabricator.wikimedia.org/T125272

Possible tasks:

Finish decommissioning old unsubscribe and move that functionality to the
new system

• Should really get this squared away before we start expanding the system.

Create the preferences center form

• We can use opt-in as a start, but this one will obviously be more complex.
• Seems like we're ok with the non-public link and contact ID plus hash being secure enough, can borrow that logic from opt-in as well.
• Will need some front end design work.

Create the queue consumer to get the data to civi

• This bit should be fairly straightforward as long as we nail down the form and the civi DB changes first.

Civi database changes

• New fields will be needed to provide this level of granularity
• Current functionality of the opt-in and unsub fields will probably need rethinking and reworking. Do those fields override fine grain preferences or not?

Civi UI changes

• This data will need to be displayed in civi, and could pretty quickly get cluttered. We'll need UI changes if we want to do more than just cram this all in the communications section.

IBM export changes, possibly more IBM work

• The export will need to accommodate the new data by having a seperate file for each kind of preference.
• Also might require a seperate file for donors opting in to specific lists, rather than opting out if we go for that functionality. I think we should.
• This might end up being a near total rewrite of the exporter.
• Changes to the import process on the IBM side. This seems like the bit with the most unknowns.
• Possible other IMB work to properly make use of these new fields.

Create a button in civi to generate links.

• Nice to have, but shouldn't be too hard.

Create variants on the preferences form

• Not necessary for minimum viable product, but probably necessary before too long.

*TASK DETAIL*
https://phabricator.wikimedia.org/T125272

*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

*To: *XenoRyet
*Cc: *mepps, XenoRyet, LeanneS, NNichols, kaythaney, Ejegg, DStrine,
jrobell, Ppena, MBeat33, spatton, CaitVirtue, CCogdill_WMF, Aklapper,
EBjune, Dinoguy1000

I pulled this out of the sprint due to availability of some people and the fact that we're not actually working on this right away. I'll schedule a meeting about this in September.

I would also like to point out that we have mapped all the communication fields in civi here:
https://www.mediawiki.org/wiki/Fundraising_tech/CiviCRM

per: T227498

This should help us decide what to expose to a user on the preferences page.

One nice-to-have on a preferences page:

• Do you prefer in emails to be addressed formally (Dear Mr. Smith), or by your first name (Dear John)?

Email sends pulling this data would be a nice customization to please the more formal of our donors.

Cool suggestion! I like it.

The task list from @XenoRyet looks pretty good!

Regarding the way to store the mailing list subscriptions in Civi: the standard way to do it is to create groups, but for our DB those might have too much overhead.

Before we start doing a mountain of work, should we review the reasons we think it's impossible to show donors their existing subscriptions? I know I'd be a little frustrated to get to a form showing multiple email lists and not be shown which of them I'm actually on.

I added a current use case to the Preference Center spec document:

(donor 741442) “I will continue to support Wikipedia, which I admire very much. But I am NOT interested in making a legacy gift. Please would you correct your list of prospects for such gifts accordingly.” This is from a test email before April 2020’s 3MIL Planned Giving outreach send.

The big Planned Giving outreach email in April will likely generate many more cases where having this feature would be helpful.

@DStrine Is this phab the right one to get updates on the preference center status?

@MSuijkerbuijk_WMF yes, welcome! :)

@DStrine We had a call with MG&E team yesterday, and seems like we need to first clarify if the option of having a separate version of the preference center for Major Gifts would be doable or not. That'll guide their specs and briefing of preferences. Would you be able to let us know about that?
Thanks!

Checked in with David and Dylan today and bumped Mariana's question above
re: hosting multiple versions of the form for small dollar and major
donors. Dylan said fr-tech was aware this was a desired feature and are
hoping to be able to support it. fr-creative will proceed assuming we can
maintain multiple versions of the form, and fr-tech will let us know if
that changes.

Change 690053 had a related patch set uploaded (by Dwisehaupt; author: Dwisehaupt):

[operations/puppet@production] Monitor services for new donor_prefs flow

https://gerrit.wikimedia.org/r/690053

Change 690053 merged by Jgreen:

[operations/puppet@production] Monitor services for new donor_prefs flow

https://gerrit.wikimedia.org/r/690053