@mention a person to add them as an attendee and they will be notified.
|5min||Giarlo to Tom transition||?|
|Partners Meeting impact||Steve, Giarlo, Tom||Roadmap Council, etc...|
|Dedication of Resources||Carolyn Caizzi|
Carolyn establishing Hyrax WG
|Working Groups - Batch Edit||Tom Johnson|
Planning Bi-weekly meetings
A likely early deliverable will be a review of things like WGBH - https://github.com/IUBLibTech/hyrax-ingest
|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)
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-PMH||Adding 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.