Why It Was Dissolved

Scope Creep

While the initial solution was effective in automating some parts of the content pipeline the project seemed to grow. Spreaker was an addition that was only partially implemented. The messages page, got a redesign which is fine but changed the frontend to a degree. This gave the project moving goal lines. Nobody's fault, just as each step was worked through, next obstacles presented themselves. Turned into a never-ending project.

This was undesirable.

YouTube and Website Misalignment

YouTube doesn't easily reflect the end result of the frontend UI.
There was a misalignment both with how YouTube was being archived (name of playlist = ? ) and the UI for the website that created a few hurdles / guesswork. Also, YouTube as a CMS left some elements of the UI under represented e.g..
There is no "Speaker" input on YouTube to then send the speaker name through and then pull up on the frontend. So, the new UI ends up looking underwhelming despite having been automated. (Note the new Messages page doesn't denote "Speaker")

This is undesirable.

100 or nothin'

It might make sense to some degree to combination of automate what you can and manually work the rest but that plan/option was disregarded. Automate with all of the elements of the youtube as a CMS and for whatever elements are missing, step in and manually input that data into the content channel - let's call it 80% automated.

This was undesireable and exhausted under the 100% automated or nothing guideline.

Radiant and Mens

Eventually we realised that both of these pages were also quasi "Messages" pages and would need to be implemented into this solution BUT* they were not on YouTube ... only on Vimeo.

This was undesireable.

Use Case: Destroy

A new question arose: What is the procedure for deleting an asset?

A user story developed that was too tall an order.

If as a user, I go to YouTube and delete a video, it should automatically delete the video from the frontend of the website.

I don't know how to do that. The webhook is a one-way street. Data comes from YouTube into the Rock system and prints data. If you delete something on YouTube the data is still sitting, printed, on Rock.

So, as best I can figure, deleting something would be a 2-step system

• Delete the content on YouTube
• Delete the asset on the Rock content channel

That was undesireable.

Standardization and Rules

It would take some standard operating procedures and rules. For example: Some content, like the, "Minute Message". Not sure if that should be bucketed per it's campus/playlist/community, opted to have it shovel in, greenlight. But, that was determined to be undesireable. So, the webhook would need to be revisited to disern between that and other vidoes to be bucket the "Minute Message" into some other place that doesn't get rendered to the page. Definitely doable but would cost more time OR training / standardization on the YouTube input. And people would have to then follow said Rules.

This was undesireable.

Code Complication

Not the simplest of solutions.

Maintanace became a question as the codebase was much more than a single api fetch => webhook. It was nested conditionals of loops w abstractions and logs + datastores w a GCP cloud server running. If I were to leave, the system would be unmaintanable at my pay rate.

It is much cheaper to have someone manually input the same data to multiple platforms. I think this became the most difficult tradeoff to make.

This was undesireable.

End Result

In the end, the project suffered from too many negative tradeoffs. A decision was made by way of the sunk cost fallacy frameworked to err on the side of confirming the bias and end the project to avoid investment into diminishing returns.