Hi Judy & all of you on this list,
the fine-grained authorization plan looks very promising at least from
our University's point of view! I'd say you've summed up the auth needs
really well and we're very much looking forward to get the next version
in our hands. :-) But as you asked for feedback, I'll summarize here
what we'd like to be able to do with our MH installation:
1) We'd very much want to give lecture scheduling and file uploading
permissions to the key members in our Faculties. We have "Educational
ICT support staff" in our Faculties, and we see these people as the key
users of our MH setup.
2) We'd like to let the above mentioned lecture schedulers / file
uploaders to publish the vids so that the _publisher_ would always be
responsible of using our MH setup in a proper way (e.g. from the
copyright point of view). Actually, we'd like to see that NO lecture
recording would ever get public automatically but instead they'd always
have to be reviewed + trimmed and only then published by the scheduler /
file uploader. In other words: I'd very, very much want to make sure
that the MH admin personnel isn't the group of people who have this
publishing + trimming task on their shoulders.
3) We'd like to solve the oh-so-problematic copyright + lisencing
problems with the adoption of MH. Our underlying idea is to ask the
publishing permissions and e.g. possible Creative Commons lisencing
attributes from the person who actually owns the lecture capture / the
uploaded video file. Currently we do this with a separate web form +
database, but I'd like to find one, way more robust solution for this
task. One of the reasons for this attempt is the question: is the
lecture scheduler / file uploader the actual copyright holder or is the
scheduler / file uploader merely an "operator"? I assume that in many of
the cases the scheduler / file uploader isn't the copyright owner. Thus,
if we really want to address this problem thoroughly - and I guess we do
- we may need an extra ROLE_COPYRIGHTHOLDER in MH. If MH could save the
copyright holder data into the db we wouldn't need to deal with the
printed out Terms of Service documents etc. This would save the admins
from so much hassle!
4) In our long term plans we would like to open our MH for all of our
teachers and professors. Our idea is to create a "Univ of Helsinki
MH-Tube"-type of a service which would let the staff members be active
publishers of video content. This is why we see that our teachers should
get a path from our LMS to schedule recording and upload videos from
within the LMS (in our case, Moodle). This way we wouldn't actually make
a pointless detour where the teacher asks the ICT support person to
schedule the lecture capture if the teacher could do it him/herself from
the LMS.
>Basically, what we're interested in is whether there are some
>Matterhorn admin activites that you want some of your users to be able
>to do that you don't want others to do.
Our teachers are asking me if they'll be able to do e.g. the following:
- publishing the videos with a separate password. This is a painful
thing to maintain, I know, but we have teachers who ask it on a daily
basis. They'd like to be able to set a simple password for their videos
so that the vids would show up in their video series but viewing them
would require the password. This use case would help e.g. our Open
University who have lecturers and students with no user account from our
Uni.
- publishing the videos to a range / list of IP addresses
- publishing the videos for only a certain amount of time (e.g. 6/12/18
months). It would be great if the lecture scheduler or file uploader
could set the expiry date at the publishing process. After the vid has
expired the MH server could send a message to the vid owner stating that
the file will be deleted unless the video owner sets the expiry date to
a date and time in future. We've done this with our Moodle and Wiki
installations and would very much want to see a similar approach
possible with MH. After all, within a couple of years the MH servers in
our Universities will become crowded with useful and not so useful data.
We as admins cannot take the burden of separating these vids from each
other but the file owners can. Thus, I think it would be a great idea to
add a garbage collection feature to MH. We just have to make sure it is
our teachers who "take out the carbage". :-)
Yours, Olli Salo from the University of Helsinki
On 13.9.2011 0:52, Judy Stern wrote:
Thanks, Olaf, for responding. Still hoping to hear from others describing their
needs re. levels of authorization for *administering* Matterhorn; I'd hate to
move forward only taking into account the needs of ETH and Berkeley.
Or should I assume that folks are only concerned with authorization as it
pertains to *viewing* published media? (Thanks, Pete, for giving us input on
that side of things.)
Specific responses inline:
On Sep 9, 2011, at 5:00 PM, Schulte Olaf A. wrote:
Changed the "Edit" to "Manage". There is "Make changes" also, is that identical to
"Manage" (cannot edit that mock-up)?
Many thanks for making those edits! (Balsamiq can be quite annoying at times!)
"Make changes" was simply the wording I used in an alternative design. I was using all three
("Manage", "Make changes", "Edit") to mean essentially the same thing and just hadn't
settled on one; it's the kind of thing we can change easily later on.
--Or do you need this to be more fine-grained, e.g. something like
<http://opencast.jira.com/wiki/display/MH/Extended+Series+Authorization>? (This
is only a sketch to demonstrate what more fine-grained authorization might
entail...don't take it too seriously.)
Having a quick look at your mock-ups, I'd say that the extended authorization
is not necessary for us here at ETH. If I understand your distinction
correctly...
Good to know. So far I haven't heard that anybody needs Series permissions to be more
fine-grained than "Manage".
<http://opencast.jira.com/wiki/display/MH/Roles+page> (again just a sketch as
we
begin to play with ideas...these may not be at a useful or realistic level of
granularity). We'll also need to limit access to capture agents (no sketches
for this
yet).
... I would speak in favour of having sophisticated "admin" roles instead in
that
- we would like students to do the trimming, without being able to do anything
else or
- would like to restrict any deletion action (scheduled recordings, recordings)
to the actual admin(s).
If a Roles UI (similar to what I sketched) included "Trim Recordings" and
"Authorize publishing" (or something like that) as privileges that could be checked,
wouldn't that meet your needs? (I realize that the current Review/Trim UI doesn't separate out
these actions, but it seems like it could.) Or am I misunderstanding your needs?
let us know if you'd be
willing to be interviewed!
Sure - makes a change from talking about metadata...
Good! We'll be in touch to set something up.
(But don't assume you're off the hook for talking about metadata! I need to get
back to you on that, too!)
thanks,
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]
_______________________________________________
--
Olli Salo
Tietotekniikkakeskus
Helsingin yliopisto
Tel: +358 9 191 21782
Gsm: +358 50 407 5509
Email: [email protected]
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
