Hydra Tech Call 2016-10-19

Time: 9:00am PDT / Noon EDT

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

Moderator: Adam Wead

Notetaker: Steve Van Tuyl

Attendees (sorry for the spelling):

Adam Wead (Penn State)
Steve Van Tuyl (Oregon State)
Brandon Straley (Oregon State)
Greg Luis (Oregon State)
Thomas Scherz (Cincinnati)
Glen Horton (Cincinnati)
Casey Robinson (Yale)
Esme Cowles (Princeton)
Stephen Eng (Temple)
Carolyn Cole (Penn State)
Andrew Myers (WGBH)
Justin Coyne (Stanford)
Mike Giarlo (Stanford)
Trey Pendragon (Princeton)
Tom Johnson (DCE)
Anna Headley (CHF)
Lynette Rayle (Cornell)
Peter Binkley (Alberta)

Agenda

Roll call by timezone per following order - ensure notetaker is present
1. folks outside North and South America
2. Eastern timezone
3. Central timezone
4. Mountain timezone
5. Pacific timezone
6. folks who were missed or who dialed in during roll call
Call for additional agenda items (moderator)
1. None
Add Sipity Workflow to CurationConcerns (Esme)
1. PR: https://github.com/projecthydra/curation_concerns/pull/1060
2. This is a 100+ commit PR
3. Esme: Questions arise about the PR and how it should be handled:
  1. Should we rebase etc.?
  2. Do parts of this belong in a separate gem
4. JC: It is kind of helpful to maintain the commit history, but if it makes it easier to review, we can squash it down to a handful of commits, but not sure if this makes it any easier to review it
5. JC indicates that he's happy to make changes as reviewers see need
6. Does this belong in CC?
  1. JC - we've heard that a lot of people want workflows and it will be more complicated if we try to separate this out into another gem, especially given that there are UI components here
  2. AM - how much does this change the use of curation concerns?
  3. ??? - Default workflow is built in that allows CC to function just the way that it does now
7. Backup - What is Sipity and why is this a thing?
  1. Look here: https://github.com/ndlib/sipity
  2. Sipity is a product (that is outside of Hydra) that allows building and tracking workflows
  3. Built this into CC to allow similar functionality (though optionally)
8. Currently, there is no UI for managing workflows and roles
9. AM - How much will a new adopter need to understand Sipity to use CC?
  1. JC - Should work just like CC out of the box, with the option of expanding workflows as the user sees fit
  2. AM - Though there is concern that the additional information needed
10. AM - Does this necessitate a version bump?
  1. JC - Probably a minor version bump
11. MG - The mediated deposit workflow has been the #1 requested feature of the Sufia and CC user base for many years, if the community feels like this should be gemified, we have concerns about where the resourcing comes from to make that happen.
12. TP - concerns about churn in CC
13. TP - what happens if my JSON workflow is malformed?
  1. JC - Sipity has strong JSON validators
14. TP - what happens if i run the database generator against the JSON (<-- help? Trey Pendragon)
15. CC - are we advocating for growing the PR at this point to add features (e.g. UI)?
  1. probably don't want to release without the UI, but should this block the PR?
16. AM - Is there any work being done to build the UI?
  1. Mediated deposit sprints are ongoing until December
17. The reason we're doing this in CC is due to circumstance and history
18. One interpretation of CC is that it is a stripped down version of Sufia, so this adds features...
  1. Though there are features in CC
  2. The problem some identify is that there is no vision/manifesto/curator for CC, so how do we decide what to do with the thing?
    1. Until that management/curation comes, how do we deal with these types of things?
19. TJ - we should probably not block this PR over this dicussion, but the discussion is very important and we need to resolve, probably on future call(s), what CC is, how it should be managed, etc.
20. MG - given how much support we heard for consolidating CC and Sufia into a single entity, we maybe don't want to spend too many hours setting/identifying boundaries around CC with that consolidation in mind
21. JC - for Stanford/Hybox perspective, we don't really care about where this lands, as long as it lands somewhere
  1. SV - same goes for the Dspace-Hydra institutions
22. AM - first inclination is to say "dont make this more complex unless necessary"
23. MG - if we need to wait a bit to review the PR in order to get this "right" then we have flexibility and time to let it lie for a bit
24. AM - if multiple CC users are interested in walking through this PR, maybe a group of CC users should group up and take a look
25. EC - a lot of CC people are interested in workflow (including Princeton) - biggest concern is that this PR is relatively large, but there doesn't seem to be any disagreement about workflow being a thing in CC
26. MG - a little concerned about setting hard boundaries between CC and Sufia
27. TJ - is there a way to scope this so it is smaller for CC and put heavier weight stuff onto Sufia?
  1. JC - difference with Princeton's workflow is that it is hardcoded, but what is in this PR is that everything is configurable which is why it is bigger
  2. MG - based on what Sufia folks have been saying, it is unrealistic for everyone to adopt a single workflow
28. CC - this still needs to be reviewed, and that is the logical next step
29. Action Item:
  1. Trey Pendragon and Andrew Myers and others can review
  2. We'll bring this up at another tech call to discuss further
CfP for Hydra Plugins WG announced. (Andrew Myers)
1. Please read and sign up if interested.
2. Any questions?
3. Take a look at Hydra-Tech for more information
Moderator/notetaker for next time:
1. Moderator: Esme Cowles
2. Notetaker: Mike Giarlo