(please put notes from any development meetings here, in reverse chronological order)
10 April 2012
- Standup meetings @ 9 daily. Mark will schedule.
- Mark will order codeschool, one person, for a month.
- Nathan has been working on metadata for the first pass. Has been looking at Rock Hall, Variations. PB Core is our working assumption. May need some kind of mapping to MODS, for IU at least.
- Need crosswalks for MODS, EAD, and MARC to PBCore.
- Need to do Fedora data modeling as well. NU Mediashelf work might have impacts/insights here.
- Chris will check about location of IRC logs, so we can keep up to date on Mediashelf work..
- Nathan has been looking at Twitter bootstrap.
- Phuong has been looking at the Matterhorn Engage player, building documentation as he goes. It's on the wiki. They expect you to have a certain structure in your html page. To refactor, he'd make it more independent from the page structure. They have some nice plugins.
- Chris has been working with Steve on getting access to NU Jira.
- 1-pager: mobile, basic via web; change year to 2013;
- Naming seems intractable. Any ideas?
3 April 2012
- Video player call–next steps? Is Engage a fork of mediaelement.js, or do they plan to continue relying on it?
- Sprint planning? When? Ideas for stories to focus on? - 8:30 tomorrow
- Rails 3? Mediashelf suggests this is a better path than using the more legacy Hydra head specific stuff. Mediashelf isn't using hydra head themselves.
- PB core form?
- Chris's trip report
- Chris Beer's workflow management w/ServiceMix & Camel routes; he wondered why we were using Matterhorn; we need to decide which path is better/easier. CB said servicemix was easier to install than Matterhorn. He is also using Puppet to have test sites set things up. Puppet needs Ruby as a base.
- Authn/authz didn't get fully resolved; Jon points out that using LDAP would mean we'd have to support access to 2 LDAP systems, maybe 3, to be minimally useful
- Hull & Stanford and maybe UVA are using admin policy objects
- Lots of talk about RDF as a replacement for MODS; storing data in hydra head using RDF instead of XML. Penn State is doing this.
- Some discussion of Duracloud & how it would fit with Hydra; Duracloud has plans for transcoding
- Look at twitter bootstrap UI framework
- Stanford shared some info about how multiple Hydra heads work
- Hydra partners - not much; code contrib agreements and partners addendum for joining Hydra
- Travel planning for Scrum training?
- April 30th-May 2nd, full days - first two days would be formal scrum training, then a day of backlog grooming and sprint planning; we need to define a half-day before that for a videoconf with 3back
- Thoughts on NU's DIL? Who should track on IRC?
- Product name - Jon now leaning toward calling it Variations something & will talk to the dean about this
27 March 2012
- Nathan is back from the IA Summit - lots of talk about mixing UX and Agile
- Scrum training tentative for week of April 30th in Evanston
- Video player call on Friday - Mark will put in some details about the requirements
- Cancan (Rails-based authz framework) is now working with hydra in our branch; Phuong now working on getting Cantango to work (more flexible; has arbitrary groups w/roles possible w/in); he'll give us a demo when it's working
- Nathan will look at wireframes to see if we want to link any in with the video player requirements page
20 March 2012
- IU watched the NU sprint planning
- We have some questions about the Greenhopper setup and whether it is optimal, with everything having to be a story and we're not sure why they have both size and time estimation
- We will take a look at Pivotal to see other ways of supporting scrum with tools and then talk with Steve about whether Greenhopper can be configured differently
- Chris talked with both Nathan and Phuong about access control; will talk with Mike Stroming. Won't need Michael Starks' help with slides.
- Needs to talk with Mike Durbin about how collections are modeled in (and outside of) Fedora, particularly as it pertains to access control.
- Mark still working on setting up a video player call with Fluid & Opencast
- Reviewed Phuong's player requirement summary; we have questions about what the user experience should be for "forbidden" segments within a larger accessible video.
- We should talk with NU about how they handle crops as new objects (different from how Variations today does playlists of segments)
- We need more user stories about access control that address how faculty get access for their students to items they (the profs) put in a playlist. Is security to the playlist? Or to the items in the playlist?
- There's a new version of the Engage player out; Phuong will take a look, though we're not expecting major changes; putting out 1.4 in early May?
- Phuong has continued working on Cancan and Cantango authorization tools; will talk with Chris about it.
- Chris brought up the possible need for switching audio tracks in a video (e.g., different languages, director's commentary) and switching languages in captioning.
- Nathan will send out a link for his recent wireframe work.
- Nathan has also been working on setting up Hydra and learning about the technology stack. He and Chris will talk, since the documentation is not in great shape.
13 March 2012
- Mark will set up video player summit w/Matterhorn and Fluid people
- Phuong has been working on authenticating embedded player; looking for work this week–should work on specifying player requirements doc which we could use in discussion with other projects
- Can also look at Cancan and Cantango authorization tools (there's a Hydra ticket that talks about switching to Cancan)
- Chris got bamboo builds working, but some are broken
- Nathan has been looking at access authorization from the user point of view–will put things up on wiki
- Mark will send out link to Scott's report on classroom video use
24 February 2012
(IU/NU call to discuss authentication & authorization options, especially for year 1)
- open/public access
- access password for an unauthenticated group
- Hydra authentication - user name and password, with no connection to LDAP or anything; stores it in Fedora
- Hydra authorization, populated from LDAP (Devise Gem?) or SIS
- CMS-based authorization (e.g., Blackboard, Sakai)
- Build our own authorization system (like Variations)
- Hydra model is more role based than group based.
- Permissions given to a role are given on each item & users can be given permission outside of a role on a given item; no notion of permissions granted beyond that; no collection-level access rights; no usage of additional information from the item to determine access
- Variations institutions have taken a broad range of approaches and integrate with a variety of campus authentication systems
- Hydra maybe is not set up to manage all this (thinks Chris)
- Some use cases suggest we will need to provide different access on different parts of the same video, due to intellectual property or ethical concerns
- Hydra security isn't necessarily synched up with Fedora security yet, though there is some work in this area
- Institutions not running Fedora might just use our bundled instance, which could be totally locked down
- Levels of security: streaming server, Fedora, Hydra ...
- Securing Red5, at least, only looks like having to write a few lines of code (to pass a token which the server then validates against a web service)
- Should we use grouper? Chris has looked at it–it's not "overly special"
- NU IT didn't want to use grouper–wanted them to do groups in ADS
- It seems like Hydra and Fedora don't give us what we need, and we can't just use LDAP, so we will almost certainly have to have our own database and management tools.
- Mike will ask a Hydra list how other Hydra heads are handling this
- Hydra has a ticket for switching to cancan authorization. ND video head already has switched.
Tentative decisions for Year 1 release
- we should at least have LDAP authentication and Kerberos or CAS
- do some kind of simple database with an expanded Hydra interface or our own interface to input data and make changes (Chris will think about that)
- get streaming server communication working with Hydra (Red5 and FMS) to secure the stream
- IF NU is going to run it in production after year 1, they will need to be able to lock down their Fedora to prevent access to metadata or any video that is stored within Fedora
22 February 2012
(IU/NU call to discuss year 1 plans, based on user stories prioritization earlier in the week)
A player that works in multiple browsing platforms, is supported without additional software, has playlist capability, has clip making capability, and can be embedded/shared (Stories 4, 11, 13, 12)
- We know how to do all this.
A system that supports batch uploading of video and metadata, batch transcoding (Stories 37, 62)
- may not want to use the more complex Camel route that NU is using for images
- we can probably do via Matterhorn
- we believe Matterhorn was design to distribute processing to multiple machines
- would still need some kind of basic metadata editing capability
- need a way to monitor, troubleshoot, restart batch
A system that supports discovery of content through a search tool (Story 19)
- index nicely and use Blacklight since that's part of Hydra
- need to look at pbcore to see if that has everything we need
- Matterhorn uses mpeg7, which uses dublin core
A system that can be monitored by a system administrator to detect and troubleshoot problems (Story 58)
- basic logging
- support for monitoring
A system that is provided a test environment to try the system (Story 47)
- we provide, for all partners, a test server
Significant investigations and/or decisions needed:
- authentication/authorization - need to have a longer discussion to explore the solution space (meeting scheduled for Friday morning to discuss)
- metadata model (Karen Miller at NU is a metadata person who can help with this)
- playlists & clips - who can make, how stored, what they actually look like; need more user story refinement and some design
What things are we NOT currently planning to do, in year 1?
- streamlined hand ingest
- section 508? transcripts?
6 February 2012
(phone call between IU & NU - Mark, Chris, Phuong; Steve, Mike)
- IU can give NU people accounts on IU's server pawpaw; we'll run the vov app and matterhorn
- for a wiki, we'll use IU's confluence until we can use Duraspace, when we'll export/import
- same for using IU's Jira
- we want to set up a continuous integration server. we have a bamboo license; hydraproject has hudson; we're not sure which we want to use.
- we probably want dev/test/production
- we expect to develop on our own systems and test on pawpaw, though it can serve both; production would be out of our scope and would be handled by each institution
- we may even want to separate test servers (NU/IU) but we'll cross that bridge when we come to it. They'll use pawpaw for now. Chris will talk with Brian about what we need to give them pawpaw access
- we'll create a Jira account
- NU doesn't run a continuous integration server
- We'll use bamboo & do nightly builds for now
- Chris has set up a github organization account; Chris will add them as members; he's put our hydra head there
- Matterhorn uses svn; do we want to do that w/Matterhorn? or keep it all git? Chris will think about this some more, since we do have to modify Matterhorn.
- everyone needs to get a github account
- NU has customized Greenhopper plugin to work with their scrum process; mostly per-project changes
- NU will send IU a list of their Greenhopper customizations and we'll see if we can do those here.
- for communication, IRC channel with logger bot; Steve will work on setting this up.