Getting shared environment set up for development, Duraspace wiki, github, etc.
Image/Media head abstractions (DIL, VoV) 30 min
Variations on Video (60 min)
Argo / PSDS (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.
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.
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
Drag & Drop...
sharing workflow-driven view code & flow
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?