Discussion: dynamic newsletters

[slifty]

Right now newsletters are implemented through code; each newsletter we want to create requires a new newsletter template, queue, and updated constants. This was OK before since we only had two newsletters, but we always knew there would be the potential for an arbitrary number of newsletters.

It is time to rethink this, and make the concept of unique newsletters data driven. We'll want newsletters to fit a common template with sections that are enabled or disabled depending on the content for a given day. We'll need to be able to have custom sources for claims as well (e.g. unique lists of twitter account, and eventually unique TV streams, known speakers, or keyword matches).

We don't have to boil the entire ocean yet, and can probably start with the following parameters:

1. Database driven (a new table that represents the newsletter configurations)
2. Custom fields would include:

• Destination (mailing list)
• Newsletter description
• Is TV enabled / disabled
• Twitter account list google doc
• List name (internal)
• List display name
• Send cadence (needs specification here)
• Subject line

Things that are NOT being engineered around yet:

• Multiple TV sources
• Keyword filtering
• Custom claimbuster score levels

Next Steps

I'm creating the issue for actually working on this and am starting along that path. In the mean time, some questions:

1. What other fields / customizations should newsletters have?
2. What kinds of schedules do we think newsletters might have? Could we imagine hourly? Sending at different times of day? Multiple times of day? etc.

[reefdog]

This all sounds good and I'll give more substantive feedback later, but some quick feedback:

1. Re: "List name" and "List display name", is this the mailing list or the Twitter account list?
2. I would make both TV and social media sections independently enablable/disableable.
3. Right now we have the capacity for fairly rich newsletter preflight validation rules; that wouldn't be so easy with this new model, but I think that's okay and was probably over-engineered anyway. A simple "are there any claims?" is a good universal preflight check.

Re: Next Steps:

1. I'll think on this! (other fields)
2. The strongest desire is for per-subscriber schedules, but that would require a huge change to our subscription model. In any case, this is more of a question for @ericaryan or @markstencel of course.

[reefdog]

Add to dynamic data, unless it's captured by "newsletter description": the opening and closing text (which I called "boilerplate" in the templates). It differs slightly between NC/National list. I think a large chunk of it is shared, but it differs in slight ways between newsletters.

[ericaryan]

Yeah, just adding on to @reefdog - if "newsletter description" refers to the top text, then we should also have "newsletter footer text" or something to capture the bottom text (unless "description" is meant to encompass both).

Also, for the "things that are not being engineered around yet" list, I would include "multiple social media sources."

Otherwise, this looks good to me and Mark!