Time/Place

Time: 12:00pm Eastern Standard Time US (UTC-5)

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 
• Robert Cartolano 
• Aaron Choate
• Sayeed Choudhury
• Stefano Cossu
  
• Tom Cramer
• Jon Dunn
• Karen Estlund
• Maude Francis
• Neil Jefferies
• Mark Jordan
• Danny Lamb
• Steve Marks
• Rosalyn Metz 
• Este Pope 
• Robin Ruggaber 
• Doron Shalvi 
• Tim Shearer
• Dustin Slater
• Roger Smith 
• Erin Tripp
• Jennifer Vinopal
• Ben Wallberg
• Evviva Weinraub Carolyn Caizzi 
• Jared Whiklo
• David Wilcox
• Andrew Woods
• Maurice York
• Patrick Yott
  
  

Agenda

Previous Action Items

• All: Explore how to bring better cross-effort alignment between Fedora and other repository efforts.
• Robin Lindley Ruggaber take discussion back to Samvera SG to gain commitment for implementing Samvera over Fedora5.

• Stefano Cossu: Draft letter about Strategy and Vision (may want to wait until after leaders at CNI Fall 2018). 
• All: Raise the topic of how to get better data on who is installing/using what versions of Fedora with the Communication and Community strategy groups.
• Governance Group - Review subgroups and organization.
• Rosalyn Metz  will use some of the language in the pre-meeting report to contribute to a Samvera roadmap white paper; David Wilcox will provide some usage/implementation statistics and read through before submission
• Who?? Possible survey of community use of faculty profiling/reporting systems
• Rosalyn Metz and Robin Lindley Ruggaber will add Integrations into the Ecosystem part of Product Position

Minutes

1. Fedora 6 Face to Face
   1. Identified what dates can work, but as the dates are soon so if more foundation needs to be laid then we can wait.
   2. Seems like we can't wait, but if we put out a call to the community we are confident we would be able to get responses before the end of February face-to-face meeting.
   3. We have the use cases that were needed for moving to Fedora 4, we can review them along with new use cases to try and mitigate loosing the current users.
   4. The Fedora API has fans and detractors, but a strategic direction we took was to move to this API. We can review that decision but we have created the Fedora API and moved the community implementation to support this API and are hearing that "durable" is what Fedora needs to do. Performance and other priorities falls in to the middle of these two goals.
   5. We need to define what "durable" means to end users so developers can work towards this. OCFL has been working towards this, but how does OCFL work within Fedora so we can define this and what are the issues related to this.
   6. Looking at what we have done (ie. the spec and technical objectives) and mapping them up to particular use cases from particular institutions. Just gathering the use cases is great but leaves us with a lot of data, so we need to map them to the existing priorities to see how we are or are not covering the use cases and fulfilling our technical priorities. This can be hard to describe to non-technical users, but we want people to have confidence that we are fulfilling their use case and so that the next version of Fedora will be.
   7. We should be prioritizing the use cases that map to the items already in the technology strategy map.
   8. Contextualizing the request for use cases so we avoid making the ask too large (ie. "What is everything you ever wanted for Fedora?") We need ways to measure these things by scoping somehow, perhaps with some sort of feedback loop, (ie. "If I am understanding correctly, you would like Fedora to do X").
   9. Hard to define the performance needs as hard numbers and we don't have those particular metrics and the goal numbers yet.
   10. Some see perform-ant as "it just works".
   11. Those clamouring the loudest are those that are not seeing their use cases covered by Fedora 4.x. But those for whom Fedora 4.x does work, how do we not loose sight of the features/needs or reduce the priority of the features that they are making the most use of.
2. Cost to version upgrades
   1. Not loose focus on the cost to migrate/upgrade but also that the product will continue to iterate and improve/change over time. Keeping in mind that all these versions are still just "Fedora".
   2. There may be some conflict between LDP and OCFL, and where they are located in the stack. So necessary to tease out the individual institution needs for these core areas and determine what do we need to support in both of these areas.
   3. Who would represent the Islandora and Samvera communities at the face-to-face meeting. UVa could support Samvera. The Islandora Foundation doesn't run an instance currently but we could send this out the Islandora lists to find users that could bring forward their OCFL use cases/needs.
   4. Samvera may have a need of preservation but also have a need for a narrower set of Fedora actions. So there are probably a lot of folks that like the preservation ideas of OCFL, but may not as interested for the LDP services that Fedora provides. As a leadership group how does OCFL fit into our mandate and how do users that value LDP but maybe not the OCFL work (or vice versa) how do they fit in the Fedora community. The values that they place in certain features are high and Fedora is a match to those services.
   5. What is the conflict between linked data and preservation in Fedora? Do we consider pulling linked data out of core and is that complementary to the idea of adding OCFL into Fedora. Andrew does not see conflict between these two ideas in Fedora. The tension that Andrew sees is at the API level, so not at core but at the transport level. (ie. a user that might say "Fedora can do whatever it wants to do under the covers, OCFL for example, but I don't want to deal with the RDF.")
3. Technical priorities
   1. Steps to success
      
      1. Collecting use cases in a scoped way and map them into the technical priorities and strategy map.
      2. Reviewing the initial Fedora 4 use cases and map them into the technical priorities and strategy map.
      3. The above work is an input to the face-to-face meeting, should it go ahead in the short term or be delay.
   2. Are there other users that could/should attend from other institutions using Fedora and/or Samvera/Islandora.
   3. Funding is a question for many institutions. Plan is that Duraspace will fund the accommodations (one big house) and food for during the meeting time.
   4. Who else would like to attend? A possible conflict between Fedora Camp and the face-to-face meeting was identified. Danny Lamb could call in for some parts of the discussion or find someone from the East Coast to represent Islandora.
   5. Consensus was that use cases could be collected and the face-to-face meeting will move forward as planned (pending funding for some attendees).
4. Fedora Budget Proposal
   1. Effort to be conservative in resource allocation when putting together this budget.
   2. Balanced the needs for resources but also with the need to be conservative.
   3. Would normally have leadership vote but might need to send this out to the wider leadership group rather than proceed with the vote now.
   4. Forecasting further reduced membership income, but is being offset by grant funding.
   5. The core grant is a planning grant and that we will apply for an implementation grant in September. This is in direct alignment with project priorities and see it directly funding staff.
   6. Seeing some increased international membership which leads to a diversification of the membership would could make us more stable.

Action Items 

1. Robin Lindley Ruggaber to lead gathering the use cases.
2. Maurice York and Robin Lindley Ruggaber to ask their teams how things are currently structured on disk to compare against the OCFL spec.