Hello Judy > Today, in our Product Owner meeting it was tentatively agreed that we would > work > on Delete in this next iteration; the user story that we voted on was > http://opencast.jira.com/browse/MH-6018, but this is too big and needs to be > split > into more reasonably scoped stories, of which we presumably would work on only > one or two. > So, I kindly request that you take a look at > http://opencast.jira.com/wiki/display/MH/1.2+Delete+Options > Here we list the various stages in the life of a recording in which users > would want > to delete or remove recordings and/or media, along with relevant current user > stories (and use cases). > My instinct is to NOT tackle anything in the Finished column. Sticking to > providing > them options in the On Hold stage would be my vote. What about yours?
Agree with restricting the options for the iteration, but going beyond the "On hold" state for a moment as discussed: With respect to the "slug" (I assume we're talking about a dummy episode à la http://fwd4.me/xAf), I think we might have to clarify what "Replacing media with slug" means: You would probably have to update metadata as well, if only for dcterms:extent for the video duration, maybe dcterms:title also for people to identify the missing episode immediately without having to click on it ("Chemistry IV: Lecture 4 - unpublished"). Also, I seem to remember there was a technical reason (checksum being built?) you couldn't just easily swap media tracks, but maybe that's a REPLAY phantom pain. As far as "Publication without media" is concerned, I'm not sure that is a good option in that the MMM as well as the embedded player or any other video player you use to present your episode won't have anything to display. While this might work in a portal (or even the MMM) where the additional metadata informs people the episode hasn't been published, this information would not be displayed in a "pure" video player - it would be a blank, suggesting technical failure. So I would argue for always having some slug/dummy episode to replace de-/unpublished media. The downside being that they also make it to RSS and iTunes (U) as you can see from the example above. Thoughts? We actually accept that in order for people not to worry why March 23 was not recorded. Finally, you're asking about metadata for ordering the episodes of a series: That of course is dcterms:created which should be "YYYY-MM-DDThh:mm" in order to make sure you can order episodes from the same day (conference). As discussed, an additional option to order episodes "anti-RSS" (where the oldest recording is first in the list) would be handy at some stage in the workflow to display episodes from a one-day workshop in the order they were recorded - not the other way round... Regards Olaf A. > > Judy > > > > > Judy Stern > Educational Technology Services, UC Berkeley [email protected] > > > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
