Hydramata session notes

Action Items from this meeting:

• sending out release announcements (Claire and Julie will make sure this gets added to the next sprint)

• determined that the best distribution layer for these announcements are hydra-tech and hydra-partners groups.

Attendees:

1. Rick Johnson, University of Notre Dame (presenter)

2. Katherine Lynch, Temple University (notetaker)

3. Declan Fleming, UCSD

4. Terry Reese, Ohio State

5. Julie Rudder, NWU

6. Hannah Frost, Stanford Libraries

7. Kevin Rice, Princeton University

8. Ray Lubinski, University of Virginia

9. Susan Pyzynski, Harvard??

10. David Trujillo, UCSD

11. Glen Horton, University of Cincinnati

12. Claire Stewart, Northwestern

13. Christen Hedegaard, Royal Library of Copenhagen

14. Linda Newman, University of Cincinnati

15. Thomas Sherz, University of Cincinnati

16. Jeremy Friesen, University of Notre Dame

17. Robin Ruggaber, University of Virginia

18. Mark Bussey, DCE

19. Giulia Hill, UC Berkley

20. Stacy Konkiel, Indiana University

21. Steven Ng, Chinese Historical Society of Southern California

22. Patricia, Hswe, Penn State

23. Sebastian Korner, University of Michigan

24. Jen Green, University of Michigan

25. Colin Brittle, Virginia Tech

26. Jimmy Tang, Trinity College Dublin

27. Patricia Díaz,

28. Sandra Castillo, DuocUC

29. Jon Dunn, Indiana University

30. Carolyn Cole, Penn State

31. Matt Mihalik, George Washington University

32. Jim Tuttle, Duke

 Notes from introductions:

• Understanding more about the legos vs. the lego kits -- Hydramata seems like a "kit of kits."

• Looking for a good kit of Hydra tools to get started with

• Understand the new direction that Hydramata is taking us into with Hydra.

• Get as granular as possible in your work so that the "kits" you develop can be leveraged and reused in other projects.

• Interest in a shared experience of saying "is it possible to make this a lego kit at a higher level than small gems?"

• Where do the legos vs. lego kits fit?  Is there a way to use this to develop consistent patterns for reusable development?

• What tools are available in Curate that is different from what is already there in other heads?

• Interest in moving to a common backend to Fedora, with various interfaces to that repository

• What does it mean to have products and solution bundles in the Hydra community?  How can the lego kit facilitate not just developers but also those who use and support IRs?

Links:

Vanilla application that we can go to and sign up for it, kick the tires:

• https://curatevanilla.library.nd.edu/ 

2 steps to play -- put your name in, then Jeremy has to approve.  You must agree to "do no harm."

Github link:

• https://github.com/projecthydra/curate 

Project Structure Overview:

• https://wiki.duraspace.org/display/hydra/Shared+IR+project 

• 1- 6 partners (5 universities + DCE)

 High-level Summary:

• Lead Project Directors - what we're doing

• Lead Product Owner - why we're doing it

• Technical Lead - how we're doing it

 Key roles:

• Lead project directors set goals and priorities for a given release

• Product Owners write user stories, engage subject matter experts to figure out what is needed on the ground

• Technical Lead - makes sure the development stays true to the original vision, giving an overall architecture perspective to any sprint's priorities

• Scrum Master - manages developers' reporting out on what they're working on, addressing and clearing blockers

• Developers - ~12 developers, not all FTE

• UX Lead

• QA Lead - not yet rolled in, but soon.  High-level QA already being done, just not automated.

 Non-partner participation:

• https://wiki.duraspace.org/display/hydra/Non-partner+participation?src=contextnavchildmode 

Non-partners welcome to participate, cannot contribute to user stories in order to keep user stories tightly focused, can however contribute use cases at a minimum. 

This is a refactoring phase, so this is a great opportunity to begin to contribute, jump in, and work cooperatively.

Many ways to learn more/get involved: committer calls, IRC channel, project's public JIRA instance

Sprints:

• 2-week sprint cycles

• PDs talk once a sprint, POs talk twice a sprint

Recorded demo to show progress once per sprint.  Retrospectives once per sprint, but not recorded. 

Maybe releasing a high-level list of what has been accomplished on a per-sprint basis via a textual message (email?) -- has been well-received on other projects.  May be more digestible, users can dig into JIRA and demos if they want to learn more. (TURNED INTO ACTION ITEM AT TOP OF NOTES)

Aim of this coordination and development:

A coherent product that would help to bring in people from outside the Hydra community because such a product does not yet exist, AND a very skinny baseline IR with many pluggable elements -- any one piece can be taken and used elsewhere, discrete.

What is a Hydramaton?:

Vanilla application -- going to be able to deposit something, RDF-based storage, very rudimentary process to get it into Fedora.  This may grow larger later.

Along the way, there are pieces in the workflow and stack that need to be changeable, i.e. extractable models as in Sufia.  Each Hydramaton can work with other Hydramata.

Trying to develop something without gemifying or shredding it later on.

 How we envision the community coming in:

- 1, groups like DCE, who want to contribute, they want to leverage what they're doing.  

- 2, folks on the side who don't want to contribute but who want to be kept abreast, to be engaged with the core project roadmapping, based on the core project stories

Next step:

For those who want to fork the repo/develop on the code, their work may happen to map to things that need to be done on the main project:

Github pull request model with slight variation -- have developers and also project leads review, pull in what is desired, made generalized as needed.

Before we get to that point, communication should be good with developers and groups that want to fork/develop on the code.

Staying apprised of progress:

- posting a sprint summary to hydra-tech (not done currently, seems useful as of this talk) -- this would also be helpful for partner institutions to share with their stakeholders to show progress

- quarterly reporting, release reporting (different from the sprint summaries, less technical)

Upgrading:

Recognizing that users cannot continuously upgrade, back porting of fixes is still TBD for this product, too soon to tell.

Suggested better deprecation messages if back porting of fixes is not guaranteed.

Realistically won't be able to determine a clear upgrade path for every port release, but will attempt for more major releases.

Sufia vs. Curate:

Sufia vs. Curate as it stands -- from the absolute base core that uses Sufia models.

Sufia was built as a very, very file-centric, file-agnostic IR.  Curate is an intellectual work-centric IR, files may not even exist.  Long term goal of modularization -- it won't be an either/or (file or intellectual work) choice, but a flavor of IR choice that can be added to if needed as one gets up and running.