You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have a few hacky video providers which technically aren't really video providers:
scheduled
not_recorded
not_published
child
parent
I think most of them aren't really necessary and could be solved differently.
Now after we merged #616 would could use date to figure out if a date is in the future/past to determine the scheduled status. If the date is in the past and we don't have a recording it could automatically transition into not_published.
If a talk actually wasn't recorded we can set a recorded: false in the YAML file. If we know this upfront we could also set this field to let people know if the talk will get recorded or not. That would also help up from automatically transitioning from scheduled -> not_recorded.
I think we could even get rid of back video_provider and video_id from the talk itself, and have a recordings: Array in the YAML file which possibly gets mirrored in a Model/Database table.
With this approach, it's always additive and doens't need to be touched again to update the status of a talk. If we get a recording we can just add it to the recordings array, which can hold the raw_title, video_provider, and published_at, which is technically also where these fields belong.
Additionally, this would allow #579 to be realized.
The text was updated successfully, but these errors were encountered:
Currently we have a few hacky video providers which technically aren't really video providers:
scheduled
not_recorded
not_published
child
parent
I think most of them aren't really necessary and could be solved differently.
Now after we merged #616 would could use
date
to figure out if a date is in the future/past to determine thescheduled
status. If thedate
is in the past and we don't have a recording it could automatically transition intonot_published
.If a talk actually wasn't recorded we can set a
recorded: false
in the YAML file. If we know this upfront we could also set this field to let people know if the talk will get recorded or not. That would also help up from automatically transitioning fromscheduled
->not_recorded
.I think we could even get rid of back
video_provider
andvideo_id
from thetalk
itself, and have arecordings:
Array in the YAML file which possibly gets mirrored in a Model/Database table.With this approach, it's always additive and doens't need to be touched again to update the status of a talk. If we get a recording we can just add it to the recordings array, which can hold the
raw_title
,video_provider
, andpublished_at
, which is technically also where these fields belong.Additionally, this would allow #579 to be realized.
The text was updated successfully, but these errors were encountered: