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:

Rick Johnson, University of Notre Dame (presenter)
Katherine Lynch, Temple University (notetaker)
Declan Fleming, UCSD
Terry Reese, Ohio State
Julie Rudder, NWU
Hannah Frost, Stanford Libraries
Kevin Rice, Princeton University
Ray Lubinski, University of Virginia
Susan Pyzynski, Harvard??
David Trujillo, UCSD
Glen Horton, University of Cincinnati
Claire Stewart, Northwestern
Christen Hedegaard, Royal Library of Copenhagen
Linda Newman, University of Cincinnati
Thomas Sherz, University of Cincinnati
Jeremy Friesen, University of Notre Dame
Robin Ruggaber, University of Virginia
Mark Bussey, DCE
Giulia Hill, UC Berkley
Stacy Konkiel, Indiana University
Steven Ng, Chinese Historical Society of Southern California
Patricia, Hswe, Penn State
Sebastian Korner, University of Michigan
Jen Green, University of Michigan
Colin Brittle, Virginia Tech
Jimmy Tang, Trinity College Dublin
Patricia Díaz,
Sandra Castillo, DuocUC
Jon Dunn, Indiana University
Carolyn Cole, Penn State
Matt Mihalik, George Washington University
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.

Browser not supported