This wiki space is archived.

The active wiki for the Samvera Community can be found here:

Child pages
  • 2018-04-12 SIGAHR Meeting notes

This wiki space is archived. The active wiki for the Samvera Community can be found here:

Skip to end of metadata
Go to start of metadata




Discussion items


Giarlo to Tom transition?
 Partners Meeting impact Steve, Giarlo, Tom Roadmap Council, etc...

Current workSteve
  • Hyrax Issues Task Force: currently addressing, prioritizing and labelling outstanding issues on Hyrax

Dedication of ResourcesCarolyn Caizzi

Carolyn establishing Hyrax WG

  • IU - 1/2 - full FTE Dev
  • Tom J for Tech lead
  • NU - 1 Full FTE (maybe Chris Diaz on QA)
  • Discussing with Notre Dame and UCSD

Working Groups - Batch EditTom Johnson

Planning Bi-weekly meetings

Hyrax Batch Import-Export WG

A likely early deliverable will be a review of things like WGBH -

Nurax to Hyrax

Concern over issues in Nurax specific to Nurax versus those that need to be elevated to Hyrax Tickets/ are Hyrax issues

SVT: Post release clean-up process that pulls non-blocking bugs from nurax and places tickets in hyrax repo with labels, etc...

(Julie Rudder said she might be able to help)

Metadata IG

Julie Hardesty - reported that the Metadata IG will have metadata issues for Hyrax coming in near future

Hyrax Metadata Ordering Working Group - evaluating options and starting a write-up. No rec's yet, but will decide on recs after next meeting (week of 04/ 16)

OAI-PMHAdding OAI-PMH to the short-term roadmap


made some changes to the way the 2.1.0 release tickets are organized, to avoid overloading between the "milestone" and the release "project". My recommendation (based heavily on what seems to be actual current practice) is to use the "project" feature for specific releases. I'd like to put a formal "release manager" in charge of those projects when they open up in the future (thanks Lynette Rayle for being the de facto release manager on 2.1.0 ).

Additionally, I'm hopeful that we can structure the milestones so that every ticket can be sorted into one of them. 2.1.0 tickets belong in the 2.x Series milestone. This way if tickets get dropped from the *project* they are still sorted into the release series and can be treated as upcoming work by default.

Action items