content_tweets.md

Tweets Content Type

Database

Initially I'd go with ContentRequest -> ContentTweets -> ContentNode -> ContentNodeRevision:

                                     ContentNode     ContentNodeRevision
                                   /               /
ContentRequest --> ContentTweets --- ContentNode --- ContentNodeRevision
                                   \               \
                                     ContentNode     ContentNodeRevision
                                          \
                                           \-- ContentNodeRevision
                                            \
                                             \-- ContentNodeRevision

We could eventually skip one level, but would require a self-reference in the revisions table with something like child_revision_id or parent_revision_id and will be trickier to pick the current / latests revisions. Harder to maintain and keep up with.

Models

ContentTweets

As with any ContentType model, this will hold the specific guidlines for the request:

Field	Description
Handle	Twitter profile where tweets will be published. If available, will be retrieved from Project Profile, so should be in URL format.
Hashtags	Keywords equivalent. Also stored as JSON Array or simple comma delimited strings. Since it's a bunch of tweets, there's no point in limiting amount.
Type	Array with one or more from: link, question, quote, tip
Media	Array with one or more from: none, pictures, GIFs, Videos
Goals	Array with one or more from: retweets, favs, replies

ContentNode

It'll be a mutable node which works as an aggregator for copy and media. To be used later on with listicles, FB Posts and maybe even infographics so the user can approve or reject each node on its own. Anything measured by count rather than length.

ContentNodeRevision

Would be attached to a ContentNode in a 1-n relationship. If reduced down to just a plain-text paragraph, could be used for any and many types of content requests. In this case in particular, I cant't think of a tweet needing extra data but the copy body, where all links and hashtags would be, anyway.

If there's a case where we require specific data, then it'll be better to have specifc content type nodes:

• TweetNodeRevision
• ListicleNodeRevision
• InfographicNodeRevision

But I can't think of any of those requiring anything but the text body.

Just like today, Revisions is where all the judging, noting and commenting will happen.

ContentNodeMedia

Also a 1-n relation to ContentNode. Would allow for revisions on media.

Field	Description
Type	Image, YouTube/Embed, Link?
Description	Useful for early stages, like briefing and concept.
Path	Image URL, YouTube URL, Link URL

Workflows

Workflows should be based on Policies. Since we'd run with generic, reusable models, we could settle on a unified worflow, like first approving copy (ContentNodeRevision) and only then getting into approving images (ContentNodeMedia).

But if custom workflows are required, then, again, we should have specific models for each ContentNode type; or at least extend them from it.

@robclancy

I'm inclined to use ContentTweetsRequest as it holds the data for the requests, specifically.

Also, since we're not doing generic models, maybe it's better to just discard ContentNodeMedia and blend its fields in with ContentTweet.

ContentTweetsRequest sounds fine. I don't understand what the ContentNodeMedia is but yes less tables and more columns is generally better so adding to ContentTweet is good.