Details
-
Type:
Sub-Task
-
Status: Closed
-
Priority:
Major
-
Resolution: Duplicate
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: #openquestion, Administrative Tools
-
Labels:None
Description
Converse with Olaf and Allison to identify the best method of updating metadata in media packages that already exist, then update the wiki service definitions for ingestion that include methods to do this.
Gliffy Diagrams
Issue Links
- duplicates
-
MH-166
As an admin, I want to know what metadata is required to execute a given workflow.
- Resolved
Activity
I think one of the biggest use cases is that lecture titles will be added later (after the initial scheduling) to a recurring course recording.
Show
Allison Bloodworth
added a comment - I think one of the biggest use cases is that lecture titles will be added later (after the initial scheduling) to a recurring course recording.
Allison: Is there metadata associated with the recurrence that might be important? e.g. changing a single recording is one thing, but changing a whole series might take a completely different approach technically.
Show
Christopher Brooks
added a comment - Allison: Is there metadata associated with the recurrence that might be important? e.g. changing a single recording is one thing, but changing a whole series might take a completely different approach technically.
I think the biggest question is *when* are we talking about making these changes? Is this bug addressing the situation before the recording takes place, or is it also addressing situations where there is "hold" of the media before processing (e.g. so it can be edited). There are different use cases in each of these situations. I think it's very possible that metadata associated with the recurrence could change before the semester starts--it's less likely after the semester begins, but possible. E.g. What if the instructor changes, or the instructor doesn't get the description of the course to the admin before the semester starts?
Show
Allison Bloodworth
added a comment - I think the biggest question is *when* are we talking about making these changes? Is this bug addressing the situation before the recording takes place, or is it also addressing situations where there is "hold" of the media before processing (e.g. so it can be edited). There are different use cases in each of these situations. I think it's very possible that metadata associated with the recurrence could change before the semester starts--it's less likely after the semester begins, but possible. E.g. What if the instructor changes, or the instructor doesn't get the description of the course to the admin before the semester starts?
Times we may need to change metadata:
1. Pre-capture
2. During capture
3. Post-ingest
3. Post-processed
4. Post-distributed
Right now I think we can fold post-processed and post-distributed together into one category. Pre-capture is "easy" as we can change the data in the scheduler. During capture is hard, because the capture client is the one who has the metadata by now, and changing it on the client isn't really feasible (because of the "broken network" assumption we are taking with the agent). Post-ingest is straight forward, but we require a UI in the job controller/workflow manager to do this.
MH-1138 seems like it would be related.
1. Pre-capture
2. During capture
3. Post-ingest
3. Post-processed
4. Post-distributed
Right now I think we can fold post-processed and post-distributed together into one category. Pre-capture is "easy" as we can change the data in the scheduler. During capture is hard, because the capture client is the one who has the metadata by now, and changing it on the client isn't really feasible (because of the "broken network" assumption we are taking with the agent). Post-ingest is straight forward, but we require a UI in the job controller/workflow manager to do this.
Show
Christopher Brooks
added a comment - Times we may need to change metadata:
1. Pre-capture
2. During capture
3. Post-ingest
3. Post-processed
4. Post-distributed
Right now I think we can fold post-processed and post-distributed together into one category. Pre-capture is "easy" as we can change the data in the scheduler. During capture is hard, because the capture client is the one who has the metadata by now, and changing it on the client isn't really feasible (because of the "broken network" assumption we are taking with the agent). Post-ingest is straight forward, but we require a UI in the job controller/workflow manager to do this.
MH-1138 seems like it would be related.
I have additionally assigned Tobias as he should be able to comment better than I could.
Show
Olaf A. Schulte
added a comment - I have additionally assigned Tobias as he should be able to comment better than I could.
Chris, I agree that we should combine "post-processed" and "post-disributed" into one item. That leaves us (since you said that "pre-capture" is easy with two items, "during capture" and "post-ingest", and I would argue that we should take these as *one* item as well. The reason for this is that there is no handle to the job while it is being captured: it has left the scheduler and is not yet part of the backend's job controller.
I am in favor of implementing a hold state for review, which will allow to watch a preview encoded version of the recordings (to detect the need for trimming etc.) as well as to edit/enhance metadata and upload attachment such as the presentation in pdf/powerpoint/keynote/...
I am in favor of implementing a hold state for review, which will allow to watch a preview encoded version of the recordings (to detect the need for trimming etc.) as well as to edit/enhance metadata and upload attachment such as the presentation in pdf/powerpoint/keynote/...
Show
Tobias Wunden
added a comment - Chris, I agree that we should combine "post-processed" and "post-disributed" into one item. That leaves us (since you said that "pre-capture" is easy with two items, "during capture" and "post-ingest", and I would argue that we should take these as *one* item as well. The reason for this is that there is no handle to the job while it is being captured: it has left the scheduler and is not yet part of the backend's job controller.
I am in favor of implementing a hold state for review, which will allow to watch a preview encoded version of the recordings (to detect the need for trimming etc.) as well as to edit/enhance metadata and upload attachment such as the presentation in pdf/powerpoint/keynote/...
I believe pre-capture is already being handled by the Edit Recordings screen. Ideally, the metadata would be editable during capture, post-ingest and post-processed as well, but since Tobias and Josh said this would be a costly function to add, currently we are OK with it being editable only in the hold state. Later, we can consider adding edit functionality at these other stages.
Editing post-distribution seems to me to be a separate state that can't be combined with post-processed, as to have any affect it would require that you can redistribute the media with edits, so it is a lot harder. You could more easily edit the metadata post-processing (e.g. when it is in a hold state) and have the new metadata sent to the distribution channel, couldn't you? I think it's still undecided for the project whether any editing post-distribution (with subsequent redistribution) will happen in year one.
Editing post-distribution seems to me to be a separate state that can't be combined with post-processed, as to have any affect it would require that you can redistribute the media with edits, so it is a lot harder. You could more easily edit the metadata post-processing (e.g. when it is in a hold state) and have the new metadata sent to the distribution channel, couldn't you? I think it's still undecided for the project whether any editing post-distribution (with subsequent redistribution) will happen in year one.
Show
Allison Bloodworth
added a comment - I believe pre-capture is already being handled by the Edit Recordings screen. Ideally, the metadata would be editable during capture, post-ingest and post-processed as well, but since Tobias and Josh said this would be a costly function to add, currently we are OK with it being editable only in the hold state. Later, we can consider adding edit functionality at these other stages.
Editing post-distribution seems to me to be a separate state that can't be combined with post-processed, as to have any affect it would require that you can redistribute the media with edits, so it is a lot harder. You could more easily edit the metadata post-processing (e.g. when it is in a hold state) and have the new metadata sent to the distribution channel, couldn't you? I think it's still undecided for the project whether any editing post-distribution (with subsequent redistribution) will happen in year one.
Tobias, are we still considering having a hold state *after* processing as well as *before* processing (we'd talked about this so the Admin could review the media that was actually going to each distribution channel)? If so, are there any issues with adding attachments or metadata after processing? We know it may mean that attachments aren't used for media analysis, but we still don't think we should prevent the Admin from uploading them at that time if they need to. We'd also really like them to be able to edit metadata after processing if they need to --are there any similar issue with metadata (e.g. is the lecture title ever encoded into the media or something like that)?
Show
Allison Bloodworth
added a comment - Tobias, are we still considering having a hold state *after* processing as well as *before* processing (we'd talked about this so the Admin could review the media that was actually going to each distribution channel)? If so, are there any issues with adding attachments or metadata after processing? We know it may mean that attachments aren't used for media analysis, but we still don't think we should prevent the Admin from uploading them at that time if they need to. We'd also really like them to be able to edit metadata after processing if they need to --are there any similar issue with metadata (e.g. is the lecture title ever encoded into the media or something like that)?
Allison, I hope I'm not misinterpreting what you're saying, but it seems to me that there is too much emphasis on pre-distribution editing and too little on post-distribution editing. The litmus test for metadata is when they hit the customer, i.e. after distribution. Names spelled wrong, speakers to be added, titles having changed two minutes before the presentation - things you wouldn't know with the conference program you received two weeks before the conference. That's the main reason here for updating metadata.
Show
Olaf A. Schulte
added a comment - Allison, I hope I'm not misinterpreting what you're saying, but it seems to me that there is too much emphasis on pre-distribution editing and too little on post-distribution editing. The litmus test for metadata is when they hit the customer, i.e. after distribution. Names spelled wrong, speakers to be added, titles having changed two minutes before the presentation - things you wouldn't know with the conference program you received two weeks before the conference. That's the main reason here for updating metadata.
Olaf, you won't get any argument from us ba/ux people that editing of metadata is important post-distribution. We've been arguing that it should be available at *any* time--we've heard of use cases for adding/editing metadata during each phase--but understand there are currently technical limitations that make some difficult.
Post-distribution metadata editing wouldn't rely on a "hold state" because presumably the workflow is completed by this time (i.e. in her last post Allison was focusing on metadata editing during workflow which is why post-distribution wasn't on her mind.)
Our designs, however, would handle post-distribution metadata editing without much modification (just add edit links to recordings in "Finished" that have been distributed to channels that allow editing.) Question is what it takes to do it technically? (Tobias?)
Post-distribution metadata editing wouldn't rely on a "hold state" because presumably the workflow is completed by this time (i.e. in her last post Allison was focusing on metadata editing during workflow which is why post-distribution wasn't on her mind.)
Our designs, however, would handle post-distribution metadata editing without much modification (just add edit links to recordings in "Finished" that have been distributed to channels that allow editing.) Question is what it takes to do it technically? (Tobias?)
Show
Judy Stern
added a comment - Olaf, you won't get any argument from us ba/ux people that editing of metadata is important post-distribution. We've been arguing that it should be available at *any* time--we've heard of use cases for adding/editing metadata during each phase--but understand there are currently technical limitations that make some difficult.
Post-distribution metadata editing wouldn't rely on a "hold state" because presumably the workflow is completed by this time (i.e. in her last post Allison was focusing on metadata editing during workflow which is why post-distribution wasn't on her mind.)
Our designs, however, would handle post-distribution metadata editing without much modification (just add edit links to recordings in "Finished" that have been distributed to channels that allow editing.) Question is what it takes to do it technically? (Tobias?)
Hi Olaf, I definitely think post-distribution editing would be an important feature for the Admin. It sounds like it might be pretty complicated, though, and Adam has always felt pretty strongly that it should be scoped out for year 1. However, I think this is something that should probably be discussed again in a PO meeting given our shifting priorities.
Show
Allison Bloodworth
added a comment - Hi Olaf, I definitely think post-distribution editing would be an important feature for the Admin. It sounds like it might be pretty complicated, though, and Adam has always felt pretty strongly that it should be scoped out for year 1. However, I think this is something that should probably be discussed again in a PO meeting given our shifting priorities.
Tobias wrote:
>Chris, I agree that we should combine "post-processed" and "post-disributed" into one item.
When you say "post-processed", do you mean after the entire workflow completes, i.e. "processing" as you're using the term includes publishing/distribution? I'm assuming you don't mean "pre-distribute" because it was my understanding that we could insert a "hold" operation between any other operations--though in the default workflow we'd probably just want one pre-compose and pre-distribute--and those hold states provide the opportune time for metadata editing. (In later iterations we'd be able to do metadata even during other operations, but there's no mechanism for saving the edits right now.) Please correct me if I'm wrong.
>I am in favor of implementing a hold state for review which will allow to watch a preview encoded
>version of the recordings (to detect the need for trimming etc.)
Seems like this hold state *needs* to be before Compose.
> as well as to edit/enhance metadata and upload attachment such as the presentation
but this calls for a 2nd hold state just before publish/distribute (last chance to add that stuff before the public sees it).
I'm pretty sure the answer is that the default workflow just provides optional hold states in both places (but UI possibly limits what one can do in each hold), but let me know if I'm still misunderstanding.
(I miss having you here to answer these questions in person!)
>Chris, I agree that we should combine "post-processed" and "post-disributed" into one item.
When you say "post-processed", do you mean after the entire workflow completes, i.e. "processing" as you're using the term includes publishing/distribution? I'm assuming you don't mean "pre-distribute" because it was my understanding that we could insert a "hold" operation between any other operations--though in the default workflow we'd probably just want one pre-compose and pre-distribute--and those hold states provide the opportune time for metadata editing. (In later iterations we'd be able to do metadata even during other operations, but there's no mechanism for saving the edits right now.) Please correct me if I'm wrong.
>I am in favor of implementing a hold state for review which will allow to watch a preview encoded
>version of the recordings (to detect the need for trimming etc.)
Seems like this hold state *needs* to be before Compose.
> as well as to edit/enhance metadata and upload attachment such as the presentation
but this calls for a 2nd hold state just before publish/distribute (last chance to add that stuff before the public sees it).
I'm pretty sure the answer is that the default workflow just provides optional hold states in both places (but UI possibly limits what one can do in each hold), but let me know if I'm still misunderstanding.
(I miss having you here to answer these questions in person!)
Show
Judy Stern
added a comment - Tobias wrote:
>Chris, I agree that we should combine "post-processed" and "post-disributed" into one item.
When you say "post-processed", do you mean after the entire workflow completes, i.e. "processing" as you're using the term includes publishing/distribution? I'm assuming you don't mean "pre-distribute" because it was my understanding that we could insert a "hold" operation between any other operations--though in the default workflow we'd probably just want one pre-compose and pre-distribute--and those hold states provide the opportune time for metadata editing. (In later iterations we'd be able to do metadata even during other operations, but there's no mechanism for saving the edits right now.) Please correct me if I'm wrong.
>I am in favor of implementing a hold state for review which will allow to watch a preview encoded
>version of the recordings (to detect the need for trimming etc.)
Seems like this hold state *needs* to be before Compose.
> as well as to edit/enhance metadata and upload attachment such as the presentation
but this calls for a 2nd hold state just before publish/distribute (last chance to add that stuff before the public sees it).
I'm pretty sure the answer is that the default workflow just provides optional hold states in both places (but UI possibly limits what one can do in each hold), but let me know if I'm still misunderstanding.
(I miss having you here to answer these questions in person!)
Just to throw something in from the day-to-day work with REPLAY. There is almost daily need to edit metadata after an episode was published to the multimedia portal. With the amount of metadata you gather chances are pretty good to get something wrong here and there. For examples see Olaf's post before.
Show
Christoph E. Driessen
added a comment - Just to throw something in from the day-to-day work with REPLAY. There is almost daily need to edit metadata after an episode was published to the multimedia portal. With the amount of metadata you gather chances are pretty good to get something wrong here and there. For examples see Olaf's post before.
Yep, I'm sure we all have similar stories. The parent story for this card is not about post-distribution metadata editing at all, so, even though Allison points out that Adam said this was out of scope for 1.0, I've created a story card (MH-2781) for this and put it on the product backlog so it gets discussed in PO. Okay? (Olaf, Christoph: feel free to write story cards for functionality you feel is missing!)
Show
Judy Stern
added a comment - Yep, I'm sure we all have similar stories. The parent story for this card is not about post-distribution metadata editing at all, so, even though Allison points out that Adam said this was out of scope for 1.0, I've created a story card ( MH-2781 ) for this and put it on the product backlog so it gets discussed in PO. Okay? (Olaf, Christoph: feel free to write story cards for functionality you feel is missing!)
Judy, I thought this task was agnostic with respect to the status in the workflow as it included references to post-distribution changes of metadata. However, given it is a sub-task to MH-458 ("hold-status"), it makes sense to single out the way you suggest.
Show
Olaf A. Schulte
added a comment - Judy, I thought this task was agnostic with respect to the status in the workflow as it included references to post-distribution changes of metadata. However, given it is a sub-task to MH-458 ("hold-status"), it makes sense to single out the way you suggest.
Yeah, it's not entirely clear to me, either, when it matters what the parent of a task is and when it doesn't. But I just figure we're better off having a story in jira than not; makes it less easy to ignore.
Show
Judy Stern
added a comment - Yeah, it's not entirely clear to me, either, when it matters what the parent of a task is and when it doesn't. But I just figure we're better off having a story in jira than not; makes it less easy to ignore.
changed me mind. going to keep this around. good requirements discussion.
Show
Adam Hochman
added a comment - changed me mind. going to keep this around. good requirements discussion.
(What are the use cases by which we would need to change metadata?)