Date
Apr 12, 2018
Attendees
@rsteans
Goals
Discussion items
Time | Item | Who | Notes |
|---|---|---|---|
|
|
|
|
Giarlo to Tom transition | ? | ||
| Partners Meeting impact | Steve, Giarlo, Tom | Roadmap Council, etc... |
| Current work | Steve |
|
| Dedication of Resources | Carolyn Caizzi | Carolyn establishing Hyrax WG
|
| Working Groups - Batch Edit | @tamsin 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... (@jrudder said she might be able to help) |
| Metadata IG |
| @Juliet 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 | @jrudder | Adding OAI-PMH to the short-term roadmap |
| Operational | @tamsin johnson | 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. |