Decision made in PO today: we will scope Delete story for this iteration to
MH-6899 (As an admin, I want to delete a Failed recording, so that it no longer
clutters the UI nor takes up disk space.)
I have changed the voting spreadsheet accordingly (i.e. replaced story number
and summary, leaving votes as they were).
Just being transparent,
Judy
On Mar 8, 2011, at 11:22 AM, Judy Stern wrote:
> 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]
> _______________________________________________
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]
_______________________________________________
