Hydra Tech Call 2016-05-11

Time: 9:00am PDT / Noon EDT

Call-In Info: 1-641-715-3660, access code 651025

Moderator: Adam Wead

Notetaker: Esmé Cowles

Attendees:

Agenda:

Call for additional agenda items
projecthydra-labs group shuffle
1. Mike: I was adding someone to projecthydra-labs and noticed there was one big group with everyone as owners
  1. Thought it would be good to create smaller group of owners and larger group of people with write permissions
  2. If you have lost permissions, let me know
Everything in beta release
1. active-fedora 10
  1. Release beta 2?
  2. A ton of deprecations were removed. Update to 9.13 and fix deprecations to upgrade.
2. hydra-head 10
  1. Justin: Aligning WebACLs with Fedora — you will need to rewrite your ACLs to be compatible
  2. Do we need to add read access when you get edit access?
    1. Trey: I think it's implied by Write in Fedora
  3. Anyone want to test this with Fedora?
    1. Trey: There is still stuff not aligned in Fedora (URIs for users/groups
    2. Esme: There is a PR to fix this, but it hasn't been merged, even though there is support
      1. Action: Esme will comment on the PR encouraging moving forward
    3. Trey: And there is also something in Tomcat to get the username from a header?
      1. Esme: Yes, there is a Tomcat module to do this
      2. Action: Trey will create a ticket for docs to support this
  4. Who wants to write a permissions migration script? (possible implementation at https://github.com/projecthydra/hydra-head/releases/tag/untagged-25364fefde9999139f5b )
    1. Justin: Probably premature, but someone should do this and share their work
3. curation-concerns 1.0 beta
  1. Justin: One more change (moving tech metadata from FileSet to File description), then there will be a beta 2
  2. Trey: Concerned about stability with Parts discussion, which would require a big migration from CC 1 to CC 2 - do we want to encourage adoption if that's the case?
  3. Justin: inclined to release as-is and accept that things will change
  4. Mike: Haven't done full community engagement yet, and are short on modeling team staff, so focusing on features
    1. Can let community process play out and not try to rush it
    2. OK with doing migrations, though do want to limit how many are required
  5. Esme: Maybe just a warning in the release notes?
  6. Justin: Trey and Esme should get more involved in the modeling
    1. Trey and Esme: We are involved – and we thought there was a consensus
  7. Mike: There may be consensus among small group of actively-engaged people, need to vet that among the broader list
    1. Action: Esme will write up the current consensus and send to Mike and others for comments
4. soon (sufia)
  1. JustIn: beta coming in the next week or so
Merge Sufia and CurationConcerns (in a year?)
1. Justin: there are not many feature differences between CC and Sufia, and it's hard to bring new developers into a stack with so many layers.
2. Make Sufia have a feature flipper.
  1. Justin: Short term: merge Sufia and CC, and make it easier to disable Sufia-specific features
3. Sufia needs to not hard-code assumptions about its data model (Works, FileSets) and instead use CC machinery.
4. Trey: Not a big objection, but Sufia has a pre-defined workflow, and CC lets you define your own
5. Mike: Sufia will ultimately support multiple workflows and let you enable/disable them, and fully support CC features and functionality
  1. There's a tradeoff between architecture and capacity, this may help.
  2. Re: capacity, effective product ownership and maintenance is hard, and takes a lot of time. It requires release management, backlog grooming, documentation, testing, an upgrade path, release notes, talking with prospective users, representing your product on calls and at conferences, responding to "support" email on mailing lists, and more. How many products can we as a community afford to do this for?
6. Trey: Want to make sure we keep the functionality and flexibility that Hydra's big strength
7. Mike: Agree, and need to work
8. Esme: Want to see alignment with GeoConcerns/BookConcerns and other plugin-type modules, maybe Sufia could be one of those?
9. Mike: Interest at Power Steering level, and there will be a Working Group to explore this
10. Adam: Like the configurability of CC, and want to make sure we keep that, might be able to extend that to Sufia-specific features
11. Mike: Agree people want that flexibility (from Sufia too), should be able to keep that in CC and bring it to Sufia if we get a merge right
  1. Have a (broken) branch to make Sufia use more of CC, that could be a good way to explore the merge
IIIF manifest gem. To be extracted from https://github.com/projecthydra-labs/hybox/pull/118
1. Justin: At a previous Dev Congress, Trey started extracting functionality from Plum into BookConcerns
  1. I'm interested in pulling just the IIIF manifest functionality out

Next Call

Date/Time: 2016-05-18 9:00am PDT / Noon EDT
Moderator: justin
Notetaker: bibliotechy