Time/Place

Time: 9am - 3pm Eastern Standard Time US (UTC-5)

Place: Congressional B room, Omni Shoreham Hotel

URL: https://duraspace.zoom.us/my/fedora

Or iPhone one-tap :

• US: +14086380968,,8128353771#  or +16468769923,,8128353771#

Or Telephone:

• US: +1 408 638 0968 or +1 646 876 9923 or +1 669 900 6833
• Canada: +1 647 558 0588
• Australia: +61 (0) 2 8015 2088
• United Kingdom: +44 (0) 20 3695 0088

Meeting ID: 812 835 3771
International numbers available: https://duraspace.zoom.us/zoomconference?m=dLuIIwXLUv5-UK4kIXYkkH9mryRETY08

Attendees

• Chris Awre 
• Danny Bernstein
• Aaron Birkland
• Robert Cartolano
• Aaron Choate
• Sayeed Choudhury
• Stefano Cossu
• Tom Cramer
• Joanna DiPasquale 
• Jon Dunn (need to leave around 1 PM)
• Karen Estlund
• Maude Francis
• Neil Jefferies
• Mark Jordan
• Steve Marks
• Rosalyn Metz
• Tom Murphy
• Este Pope
• Robin Ruggaber 
• Doron Shalvi
• Tim Shearer
• Dustin Slater
• Roger Smith
• Erin Tripp
• Jennifer Vinopal
• Evviva Weinraub
• Ben Wallberg
• Jared Whiklo
• David Wilcox
• Andrew Woods
• Maurice York
• Patrick Yott (leaving at 2:00)

Agenda

Documents

• Pre-meeting report
• Google doc for minutes

Previous Actions

Minutes

Pre-meeting report topics/observations

• Interest in discussing why people leaving Fedora in the afternoon part of the meeting.

• Loaded terminology around preservation - what do we mean about this from a product position standpoint, ie, what are the preservation expectations? Means different things to different people.

Strategic plan overview

• Strategic Planning spreadsheet
  • Make spreadsheet a kind of living document - review and update every six months.  At this point, the SOON moves to the NOW, if it is ready, or adjust if needed. Can save a current version as a snapshot and save for evidence of where we were at today. Maurice can help to team leads to set up spreadsheet for next 6 months, review next steps.
  • Draft some communication for community after this meeting, use items from spreadsheet (past and going forward) to help populate outreach.
  • Ageing concept - if a NOW statement doesn’t change, we can identify it and determine whether we should actually do it if it sits for 18 months.

• Fedora Vision/Strategy Guiding Principles

Report from the Strategic Plan Working Groups

• Highlight important areas the groups need input on

Governance

• Articulating current governance process

• Reorganized Wiki pages

• Will review and make sure all information is accurate

• Metrics will become the NOW

• Michele (very draft) report - analysis of current membership and users and recommendations for structure moving forward.

• Internationalize board, change governance to bring in more international voices into the conversations. 46 members in US and a whole lot elsewhere not represented in governance. Fedora is very North American-centric right now.

• How do we adapt as we become more global, change strategically?

• How to let voices who can’t spend as much money be part of the conversation and how does that look?

• All membership growth happened outside of US and most outside of North America in $500-$5000 range.

• How to engage? Teaching people about how we are governed, also bringing in other voices. Internationalization as a priority is something we have to agree on…

• How good is our data on institutions? (registry data needs some clean up).

• Unlinking fiduciary and governance from strategic governance - a distributed network model might be helpful for this.

• European involvement in reorganization of Fedora - issues with language around invoices needed changing. Sponsorship vs. Membership. We want to be international.

• Repository work outside of North America has a different model - might need to think geographically about where touchpoints are to get engagement. Mic has done a lot with consortial memberships. Consortial models are more fiscally stable, shock tolerant.

• EYEBALLS 👁- things worth following, dependencies, further clarity on this to follow

Technology

• API Spec 1.0 finalized! - done

• Validate test kit against Modeshape - not sure about others yet. (move soon into NOW)

• Release 5.0 to API spec - finished this month

• Community supported Fedora impl - replace Modeshape - some work on this, draft doc tech team is creating, not a full report yet. Good priority to focus on next year.

• Long-term preservation and access - investigate and support OCFL spec, soon is protoyping OCFL compliant Fedora. Is OCFL the appropriate spec to focus on to make Fedora more a preservation solution. Dovetail with product position conversation.

• Persistence layer - already captured in other categories, move this to a hidden section/offstage to hide from view.

• Support and stability - not yet fully documented on the Wiki - just a little more to do.

• Ease of installation - gaps in documentation, challenging concepts identified - talking to Mark J, about someone who had run a documentation sprint, setting up doc sprint

• Ease of hosting as an installation - Service providers possibility to lead charge on this? CANARIE funding from UPEI to help with this (Mark will reach out to them about this)? Reach out to the grant about this. VTech running Fedora in cloud based environments. PASS in container in AWS. Hosted solutions for PASS, not sure about multitenancy. Need real world use cases for this. UMich data repository - share code base but distribute storage. Would Avalon or Hybox be interested in this?? Need a champion for this perhaps who is actively tryng to do this? Cloud storage is more and more happening in campus communities - this is more near term than multi-tenancy. As we consider modeshape alternative this is a principle we want to be thinking about. How many service providers to we want to encourage/expand, and would this make it more attractive? What can we do now, and what do we need to do to make it function the way we want? Hack meeting to gather developers to explore, whether specifically this topic or additional/other priorities.

Maurice resets spreadsheet for next period.  Fresh template.

Community

• Syncing calendars presented challenges based on time zones.  Este managed this by doing one-on-ones.

• Call for new members

• Worked on a document, sees strong relationships with other work (e.g. membership)

• Potential for document sprint?  Other ways for folks to engage?

• EP: discussion topic...How to recognize/celebrate membership?

• How do we engage with folks who may be leaving?  Get and trap feedback.

• RM: Proposes an idea of doing a leaders membership analysis.  Both to understand and support moves to improve diversity on Leaders.

• RR: Discussion of meritocracy?  How to highlight contributions.

• KE: Product position used as a way to identify ways to contribute?

Communication

• MY: we are tracking conferences, but have no information on impact.  Looking for intentionality.

• KE...how doe we know what defines success?  Great question.

• DW: Has a sense of high v low value for some of this.

• JD: We should connect events to community.

• RR: When a community reinvents itself...do we explore new/alternative communities to engage with?  How do we become active? Character of the community. MY: DLF for example...look at their mission and show up relevant to that.

• EW: sidebar: LITL (Library IT Leadership group).  New community. See this website.

• Transparancy should be part of this.  Acknowleging potential shortalls...but also react to them in ways that are honest and accurate.

• DS: Training.  Gap analysis.

• *DS (nlm).  Improve web front end...add to marketing/strategy group.

Product Position

• RM: gives overview.

• Going with a white paper approach for now.  Still very mutable.

• JD discusses “persistance layer”

• Interesting discussion/breakdown of potential to recommend (toaster v. viking stove):

• Fedora yourself: configurable, agnostic, needs resourcing (viking)

• Fedora via a service: vendor? (restaurant)

• Recommend DSpace (toaster)

• MY: Discussion of Academy supported...should we start doing this?

• See white paper for group editing outcomes…

• RR: we need to maintain relationships with related communities.

• KE: looking for a modular suite of tools.  So that they can be swapped in and out. Committment is not to a version of a tool.  But to the cause.

• Good discussion about web as part of fedora.

• Good discussion about models as part of fedora.

• Long discussion about preservation and linked data and the future of Fedora and its relative position inside the ecosystem.

After Lunch Session

• Maurice identifies “Reasons for attrition of support” as a topic we shouldn’t lose sight of.
• Tim S suggests periodic phone calls where we meet to deep dive on specific issues.
• Proposed: We should identify Fedora’s role in a preservation infrastructure as a starting point for product positioning and technology efforts.
• There are many views on preservation, and no concrete view coming from Fedora leadership.
• Some institutions have preservation librarians, and it would be of value to get their perspectives to bring back to the group. What do they expect Fedora to do? What are the gaps between their expectations and what Fedora currently offers?
• The reason that OCFL is being considered is because of current preservation perspective that saved files be usable. OCFL would help describe what files would be available in the persistence layer.
• What should default features be?  What additional easy-to-implement and support features could also be offered?
• Suggestions: Use an external framework (NDSA?) to communicate what level of preservation features/function Fedora provides. Two benefits:

  • We may be able to use these results to identify features we may wish to include/support in the future.

  • Institutions can use this to help assess their own level, and how Fedora may help them increase their preservation infrastructure maturity

• We should measure the extent to which our level of preservation support leads to people leaving the platform. Are we over/understating the issue? Can we debrief some of those that left via exit interviews?
• Suggestion: Use OR as the deadline to have the positioning document ready for a vote by this committee.
• Questions: who at Duraspace performs an assessment/UX role? Is this Erin? Should we have an external standard by which we measure ourselves?
• MJ: Suggests technology group takes a high-level look at the various preservation frameworks and report back to next leadership call.
• Big 10 Digital Preservation Interest Group - could be used as a test group prior to broader communication
• Product Technology group to review use cases/feedback from Strategy doc

  • Also to take up the question of mapping to existing preservation frameworks of other communities (e.g. NDSA levels of preservation?) to see which make sense, which we could map to

DISCUSSION OF TECHNICAL PRIORITIES FOR NEXT SIX MONTHS

Would be nice to see a Fedora that could:

1. Write to OCFL
2. Have a turnkey fixity service (easy to do--there right now, can make sure it stays there)
3. Performant

• There will be an ongoing tension between “nicely laid out on file system” (preservation capacity, like Fedora 3, OCFL) and performance.
• Might we be talking about two different implementations? One based on OCFL, slower, focused on preservation; one that is tuned for high delivery/throughput.
• But--can we meet a definition of performant for preservation purposes--able to ingest millions of objects in a reasonable amount of time without blowing up
• Some aspects of Modeshape are uniquely terrible for performance. Removing modeshape and replacing with OCFL might take care of some of those performance issues.
• Could this be the guiding star for technology development for the next six months: Replace modeshape, and tool implementation of OCFL, with an institutional demonstration project (possibly at Emory?). Get a test implementation to demonstrate.

  • This needs to be taken up with committers in conversation.

  • Would it be feasible to pool money to bring on contractors who could help make this happen? Penn State, Emory, Michigan, others may be able to bring money to this. But can we identify contractors who could accomplish it and make it a priority for next 6-12 months? Can we make it into a contractable thing?

• Another major question to take up: Whether the RDF issue is causing people to leave the community. The API is all built on/premised on RDF. How do we understand the priority/balance of tackling the RDF issue vs performance/OCFL? Seems to be an agreement to focus on the performance/OCFL question?

TECHNOLOGY ACTION PATH FOR NEXT SIX MONTHS

1. Committers to come up with a design that uses commodity components--for how to implement OCFL. That then could be contracted out--

2. Group of funders brought together to join in the conversation of what that would cost, how to assemble the money, and how to get the contract out.

3. Identify the institution that will host the test bed implementation once the contractors get to work (Emory? JHU? Michigan?)

Actions