Hi Olaf
I agree that however we implement media replacement, it will require updates to
the mediapackage. (I think the reality is that it actually has to be a whole
new workflow, though the UI can hide this fact from the user).
And, yes, we are on the same page re. "Publication without media". (i.e. if you
don't want the recording of the event to go out, it gets replaced with the
dummy episode/slug). As I mentioned in our conversation, folks here at
Berkeley don't agree on whether anything should be published to iTunes and
YouTube (e.g. when the class is cancelled or the media is bad), but I
definitely heard a similar concern ("...in order for people not to worry why
March 23 was not recorded") from Ben Hubbard here. So I think it's okay for the
same thing to go out beyond MMM. Would like to hear from others on this list,
though.
Re. ordering, I've added http://opencast.jira.com/browse/MH-7099. Please edit,
add details, etc.
thanks,
Judy
p.s. given that the "replacement" story (MH-5507) was not voted on to be worked
on in this next iteration, I'm not sure *what* we can do re. deletion. I've
asked Adam to add this as an agenda for the PO meeting tomorrow
On Mar 8, 2011, at 10:49 AM, Schulte Olaf A. wrote:
> 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]
> _______________________________________________
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]
_______________________________________________
