December 2011 Agenda and Notes


Dates: Dec 7-9, 2011
Location: Meyer 182



Wednesday: 9 AM arrival, set up, caffeinate. 9:30 AM start - 5 PM
Thursday: 9:00 AM - 5 PM
Friday: 9:00 AM - 5 PM

Wednesday: 8 - 9 AM
Thursday: 8 - 9 AM
Friday: 8 - 9 AM

Agenda, Schedule & Notes

Wednesday ( Notes ),  Afternoon Notes

  • Demos & Institutional Updates – 15 min per institution / major head.
    • 5 min Q&A
    • HARD STOP at 20 min
  • MOU & CLA - walk through as a group 30 min



  • Communications: Supporting a Hydra community across 24 hours worth of time zones 10 min
    • How do we try to ensure that US-centric meetings and calls are accessible to Hydra users whose working day does not overlap with them comfortably? The current committers' call at 8:30PST is at the extreme of what can be achieved in the UK - it's not good for mainland Europe (or Singapore!)
  • Release schedule. How does quarterly releases look, one quarter later? 15 min
    • ActiveFedora 4.0's timing as an entry to this question: When to make this change?
      • Cf. Blacklight: No SemVer, because it's difficult to identify what the public API is. What is HyHead's public API?
      • The Rails 3.1 upgrade will require a major version bump for AF
      • What are the basic principles for releases?
        • Bug releases should be as frequent as possible (weekly)
        • Feature releases should not be held hostage to arbitrary quarterly releases
        • Major releases should be...
          • Decided by partners?
          • Executed in consideration to the calendar
        • It may make sense to document the stability of released gems- clarify that there are no released "edge" builds unless the release version indicates beta or release candidacy.
  • Data Set Collaboration: sharing mechanism (5 min)
  • Geo - framing discussion (10 min)
  • Hylandora 15 min
    • four levels of interoperability (On Slides 4-7)
    • solrizer
    • plans / opportunities for shared models, code, objects
  • Community Roadmap 60 min, Fri
    • Dissemination: publicity - is all publicity good publicity? Or should we attempt some coordination? UNIS conference?
      • Should there be coordination in publicity materials for partners/adopters to use in presentations, etc.?
        • There are some examples on the website
        • Is it appropriate to request a kind of "sanity check" for presenters with the steering group?
        • Should we ask for posting of materials on the wiki after presentations?
        • How can we ensure that promises/descriptions of the roadmap are accurate
        • Is there a concise version of the technical roadmap that can be consulted?
          • Perhaps a wiki page that describes current state of the project, a concise technical roadmap, and contact info for further questions.  Richard will do all of this, promptly. 
    • Dates of next meetings q1 and q2 (and q3 and q4, I guess) 2012
      • Don't expect a quorum at OR for a partner meeting
      • Proposal: Post-libdevconx partners' meeting at Stanford (Mar 26)
      • Proposal: UVa meeting June 4-6, or December if there's a partner's meeting at OR2012
        • Q2 meeting may be necessary to plan the OR presentations
      • Proposal: Some yet-to-be-named partner in the midwest in Sept. ND and NU will fight it out. And Rockhall. Which is not a university.
      • These dates will be finalized by the steering group and the prospective hosts.
      • Richard wonders how many email lists there should be? Announcements to the users list as well as the tech list.
    • OR12 - Plans, Messages, Proposal Outreach
      • Expecting representatives from NU, Ms, ND (?), Stan, Va.  Which is pretty much all of them. Maybe there should be a partners' meeting?
      • What will be the partners' agenda for OR presentations/meetings?
        • Compatibility with Islandora? Why Hydra and not Islandora?
        • The conceptual distinctions between hydra and islandora may change as heads begin to sprout
        • The FUG in Austin suggested another venue for outreach and demonstration- should there be a hydra panel in the FUG at OR2012?
        • Eddie suggests that jruby may make hydra-heads a viable replacement for some parts of the core fedora distro.
        • What is the message about what hydra is- libraries? Forks of hyhead?
          • The breadth of hydra apps as they stand
          • Strategies for adoption
          • "Local-in, global-out": Hydra's relevance to syndication/publication
        • Outreach to gov't institutions?
    • How to publicize Matt's Office hours?? Matt will email the list. Maybe Wednesday afternoons, unless Simon reaches out.
      • Bess: Maybe a shared gcal with the office hours, relevant presentations, etc.
    • Anticipating communities of adopters-not-creators per-hydra-head in the broader Hydra community
      • Brad and beer say: "RHEL's great strength is never shipping anything less than 5 years old.  Adopters, unlike creators, look for this kind of stability." (not intended to be an actual quote)
      • Is there a way to gauge the install-and-go-ability of different hyheads, versus those that work but require developer intervention?
        • "Our goals for community growth were still targeted at solution creators, but we will soon have to revisit that strategy." says Matt. 
  • Richard will send a message to hydra-users soliciting interest in a series of skype conferences about modelling different media types
  • Hypatia (60 min)
    • Some AIMS partners would like to know how to assist ongoing Hypatia development
    • Finding Aids in BL, Hydra


  • Data Set Deposit (Dinner on Thurs)
  • One Week, One Head (dinner)
    • good idea?
    • who?
    • when?
    • what? DIL, conference deposits, Hypatia extensions?


  • The Hydra stack 60 min
    • As a manager, I'm not clear about the boundaries between Rails, HydraHead, Active Fedora and Rubydora. Likely there are people out there with the same lack of clarity: we should explore this and establish a web or wiki page? prezi from OR11
    • What is the 'approved' procedure for adding or deprecating (removing?) functionality in the Hydra code?
      • bug fixes and minor releases should be done among the developers, as part of the normal course of development. major releases should be aired and vetted with 1) the project as a whole, and 2) with the Steering Group in particular, which needs to greenlight the change. This is to ensure consistency between the architecture/code and the public profile and stated directions of the project and collaboration.
      • removal of functionality is backwards incompatibility and always results in a major release
    • Similarly, what is a "head" (Naomi prefers "application") vs. the framework.
    • other questions at
    • How do we share heads and/or code?
    • Proposed Target Deliverable: Up to date and accurate diagram of all components
    • Walk through of Hydra wiki/website checking 'advertised' functionality against what is in the code, including
      • support for simple/compound and atomistic objects
      • support for disseminators
    • separate MODS editor from HydraHead core (from combined BL/Hydra committers call) 15 min
    • Sharing view-level code & javascript – what should be in hydra? what should be its own project? what should simply be recommended practice? What is duplicating rails convention or projects? (15 min with the point below)
      • Drag & Drop...
    • sharing workflow-driven view code & flow
  • MODS <subject>
    • Matt says that the current code is badly suited to dealing with a MODS <subject> node that can contain none, one or many instances of each of <topic>,<geographic>,<temporal> etc. Can we agree a common approach to fixing this? Has someone already fixed it?
  • FESL & rightsMetadata 30 min, Friday
  • propagating metadata datastreams (e.g. rightsMetadata) to child objects ?? (5 min)
    • Matt: this is big picture architecture issue, this was something that was never implemented (therefore it hasn't been removed)
  • Technology Roadmap 30 min, Friday
    • Next steps, action items
  • Sets Modelling (including order) – framing patterns, conventions, best practices (15 min Fri)


  • Production Deployment, Scalability (60 min)


Community Framework (Process, Procedures, Working Together)
Technical Framework (Proposals, Issues, Architecture, Data Modeling)
Head-Specific Development