Time/Place

Time: 9am - 3pm Central Daylight Time US (UTC-5)

Place: 

Washington Boulevard Executive Center
4818 Washington Boulevard
St. Louis, MO 63108

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 (teleconference)
• Tom Cramer
• Joanna DiPasquale 
• Jon Dunn
• Karen Estlund
• Maude Francis
• Neil Jefferies
• Mark Jordan
• Steve Marks
• Rosalyn Metz
• Este Pope
• Robin Ruggaber 
• Doron Shalvi (teleconference)
• Jennifer Gilbert
• Tim Shearer
• Dustin Slater (teleconference)
• Erin Tripp
• Jennifer Vinopal
• Evviva Weinraub
• Ben Wallberg (teleconference)
• Jared Whiklo
• David Wilcox
• Andrew Woods
• Maurice York
• Patrick Yott

Agenda

Documents

• Pre-meeting report
• Fedora 6.0 design summary
• LDP and RDF in Fedora

Minutes

Strategic Plan

Report outs and communication plan https://docs.google.com/spreadsheets/d/1YH3uNxFXPgrRlOv3Nh8z6I3bWCVyC2k6jY21DFjzLvI/edit#gid=0

Product Technology - DW

• Replace modeshape

• Release w/OCFL

• Have 6.0 spec’d out

• Document policies for product stability

• Migration support

• Question as to whether migration support is needed for initial release or later - DW

• What’s the lift for migration with multiple versions (Fedora 3, 4, 5)?

• Could potentially convert Fedora 3 objects to OCFL, so that lift would be easier with OCFL implementation

• Migration issues noted at Northeastern are more related to “perception of RDF heaviness”

• So much of community is on Fedora 3, the political and social viewpoint may be to prioritize migration; noting priority for the entire community - MY

• Need to make sure people who are actively engaged, as well

• Or separate out as a sidebar process with migration grant? - EP

• Demonstrate path forward - SC

• Marketing and when to say 6.0 vs beta or 6.1 - JD

• Islandora is built on 3; tooling built in Islandora 8 will take in migration to whatever Fedora is ready without a separate Fedora migration - MJ

• Migration is application dependent and modeling - AW

• Avalon would also provide a migration tool at that level - JD

• Should we call the migration tool, “street cleaner?” ;-) - EP

• Fedora without Islandora or Samvera? - RR

• 260 Islandoras and 80 or so Samveras, custom - DW

• If in the context of Fedora 6, if we can identify Islandora 8 migration and Fedora free pilots with tooling - AW

• One would need to be a Hyrax one, which is embedded with RDF - RM

• Fedora 3-4 is hard, because Hyrax is using RDF (not XML/MODS)

• Because it is using RDF, will anyone moving with Hyrax, they may have to use RDF in ways they disagree with

• Could Hyrax folks who don’t like RDF; Hyrax either needs to change for those folks or they could move to Islandora.  - KE and DW

• If we are prioritizing installations, then Islandora is what we need - ET

• 216 Islandora, 60 Samvera, and 243 unknown Fedora installs (Half in the united states and those using Fedora by itself are mainly in non-US) - ET Link: https://docs.google.com/spreadsheets/d/1cKerrKyryvyoM9SU6Uhdw7ROpreJgwlvSzMm9TQ7GTU/edit?usp=sharing

• Is Samvera’s forward path divergent from Fedora?

• Are people leaving Fedora because they have a false perception that Fedora enforces RDF, but that is in Hyrax? - MY

• Maybe, part of it, but more understanding value add of Fedora - PY

• MODS to RDF Samvera group took 3 years - RM

• But they did it! - EP

• If Samverans are leaving Fedora are they too much of Fedora’s reliant funding? - RM

• What would we need for the next incarnation of Fedora? - RR

• Migration tooling

• Documentation / Sharing knowledge

• We must support our users and what they need

• Islandora is loosely coupled with Islandora 8 - MJ

• Can we participate with more of this conversation in the streams instead of twice a year? We are too smart to not figure this out! - MY on soapbox. :-)

• This feels like a last chance effort; 6 must hit the ball out of the park - SC

• Budgets are in flux at many institutions and member decisions under scrutiny - SC

• Northwestern moved off of Fedora, because it has been scattered and has meant that resources have been put in things where everyone wants something different; we’re getting there; we need to niche that we are going to work on; AWS issues; own tooling for import/export - EW

• We want this to work! - EW, RR, SC, probably others

• Careful about membership erosion and DPN warning (loss of 30% of membership): could we lose 30% of Fedora members in 2019”? Will 6 be ready? - ET

• Have to plan a migration path either way?

• OCFL may fit both Fedora 6 being successful or migration away from Fedora - KE

• Fedora has had 20 years of success where many good things have grown and has been more and more minimized, which i sa good thing  - PY

• Product loyalty is so strong in this community, it often gets ahead of solving problems - ET

• Fedora has name recognition (Declan) and community - EW, ET

• Community is more than an actual product that we have - PY

• I don’t care what Fedora is! I want the Fedora community to solve the problem.  - TS

Community - EP

• A lot of waiting for product position and what will come

• Community around product and using it; making sure we’re getting enough voices; more developers

• Community getting more people with different skills involved in needs

• Stepping back and looking at role that community plays. Who’s here? Who’s not here? We are a homogenous group.

• Also want to merge with Communications Group workstream

• Not that many of us trying to do a lot of work

• Next steps: what it means to be a community?

• Readings:

• http://www.inthelibrarywiththeleadpipe.org/2019/digital-libraries-critical-practice-in-communities/

• https://jhupbooks.press.jhu.edu/title/generous-thinking

• Update spreadsheet

Can we talk about what we want from Fedora and product position, rather than talk around it? - RM

If we don’t have use cases, then we don’t need it - RR

If this group can’t generate use cases, then we can’t expect if from others - SC

Use cases discussion and communicating what we are doing to our stakeholders, too. - so many folks

Open Platform? - MY

Need something for people to react to  - ET

Do we have to look more vertically at the stack and see where Fedora plays a role? (Star in constellation) - TS

If you can pull a thing out and nothing changes, then that is one less thing to worry about or pay for? - PY

How to build and articulate role? - TS

Can we develop use cases that don’t devolve to technical parts for Fedora (not the stack) - MJ

Collection folks can see what then see whole role in stack - SC

Communications and Outreach - MY, JD, DS

• Developing a mechanism to identify events and venues to target for outreach

• Adjacent Communities

• Survey instrument to assess training needs

• Discussion

• Would site visits be more important than events, especially for pilots (pre-sales)? - ET

• Can also use leaders group not just Andrew and David

• Help moving/ migration to 6

• Islandora is looking at an adoption manager for a similar thing (maybe not travel budget) -- grant application

• Could also look at other funding opportunities?

Position

Product position white paper

Product position discussion

Trying to get to consensus on product position. We need to see where we agree or disagree and come up with questions.

RM - Wanted to make sure people read it. If you didn’t we can take 5 minute to do that. We can take page from David’s framing and Julia’s VIVO governance and instead of debating merits we can just do a round table approach. We can just let people say their piece. We could do the ecosystem role first. One min per person to say concerns or what they like. I will say roles first.

Ecosystem Role.

Stefano - Sounds great to me.

Doron - I like that paragraph

Ben - Quick question - vision and strategy - these are vision statements not where we are now, right? RM - Yes they’re aspirational. If you have concerns with aspiration or how we get there pls say so. If it’s aspirational, it’s fine. The flexible part I’m not sure. I may comment on that lower

Dustin - It’s fine. We know so much about Fedora. Who’s the audience? If I’m not one of us will I know what a cultural heritage ecosystem. Can we list what problems we’re solving?

Karen - I like it. Thanks.

Evviva - I like it too

Patrick - no negative comments

Este - I echo Dustin. I don’t have a suggestion about how to make it better. But I think if the audience is us it’s fine. But maybe we need to mention repository.

From medical library perspective the cultural heritage terminology don’t fit for me.

KE - Does GLAM work?

Maybe. We want to bring in data and that’s not cultural heritage.

KE - maybe we should talk about knowledge management and data science. Or maybe just data.

MJ - I like it a lot. For clarity - indicate that Fedora s usually a hidden component and there’s usually a user facing application. Not sure if API wording captures that. User facing or front facing.

JD - good paragraph. Depending on audience we could wordsmith. “ecosystem” can be a eye rolling term for people outside of tech. We could clarify it’s about technology.

DW - Look at word ecosystem

SC - Good. Trying to think about how to incorporate data management (data science is diff.). and can we talk about Fedora’s position in term of broader preservation framework. It is a component and not all of the preservation framework.

MJ - can we test this wording with CIOs or Deans a subset before we publish it?

DW - Yes we need to take it beyond this room

I like it. Others have voiced concerns but no other feedback

TS - ‘enables” instead of ‘part of” would be better. Linked to what SC said.  

EW - if we created a system where people don’t feel like they can ask questions.

RM - Maybe we should say it supports preservations instead of enables.

TS - just need to clarify what enables means

RR - We can wordsmith but this provides the basis for messaging to deans, CIOs, technologists, etc.

Ben - I have more thoughts. Ecosystem role and we’re talking about audience. Tied to future of who our target issue and who will support it. I don’t want to move on from audience. Fedora is back end tech. For it to succeed the people diving the front end tech need to be part of it. Fedora is targeting to tech people because the people who touch it are software engineer. But I see why we’re having problems.

DSpace running here for 16 years. It’s not flexible. Simple CM. But it’s a complete package. It does what it does pretty well and provides easy upgrade path and it’s low cost. People want it to do more but it does what it needs to. As a product manager, it ties in to earlier conversation, if the front end tech people if they’re not using Fedora. I don’t know if I expressed this well. Seems like a key issue. Will it be a back end that supports and ecosystem or is that not going to be success.

MY - I like the articulation and the words. I see the gap between ecosystem and interoperability. My question is how and what is that again? I spoke to Tom and he said ‘so what do you think Fedora is?” I had to think about that. And I described Fedora 3.

ACTION - Maurice  will send me the whole statement. “Fedora provide extensible store for

RM - The words I heard are throughout this document. There are words missing some words that we need to dive into when we talk about modelling support.

AW - I like the description. I’m getting snagged on the overlap of the sections and clarity. It seems like there’s overlap and maybe it’s intentional. It takes away from clarity.

Could we ask, ‘are these the right 4 sections?” I could imagine a sentence like what Maurice said and name it product position.

RM - these were the heading on here and we removed some sections and we merged some sections. That’s good feedback. Maybe we can take some time to talk about that. It’s valid. If there’s a section missing, what is that?

KE - yeah let’s go through and then ask this question.

Integration/Interoperability: Community Applications.

Stefano - this is where we address the people who say “I don’t need Fedora I can just use a DB”

Dustin - it’s great.

Ben - this statement is now? Or aspirational?

DW - this isn’t true now.

AW - except for tools work. It’s not true of Islandora or VIVO.

Doron - Seems fine. To step back. I think the whole doc is heavy on preservation. I think it’s important but there are applications that are focused on access and not preservation.

RM - since you all aren’t members of those communities did we not address your concerns (Doron).

RR - if we have archivematica and

Doron - I think it would be nice if there was higher integration with other preservation tools.

RR- York University is funding this type of integration.

ACTION - expand the list of integrations like ArchiveSpace and Archivematica.

KE - The question - I know we’re not debating - I didn’t have the save reaction as Stefano about the DB. I think we need more to answer that DB question.

RM - so you like the aspiration but we need more details.

KE - this doesn’t answer whether I use Valkrye or not.

DW - next 2 sections get into that.  

EW - nothing to add

PY - I get concerned when I use the word stack. We need the right language that fits with different audiences.

EP - we should say something about the API because it’s the mechanism for integration. Do we want to include integration and interoperability. Can we select one? Or should we leave both. Are we using them interchangably.

Jennifer I don’t have anything new.

MJ - I echo Este I think we should just use integration.

JD - no concern about this as aspiration statement. I have concerns down later. I think the role the various users want Fedora to play is not the same.

PY - maybe it needs to say it can be anything

Crowd reaction aahhh

JD - depending on how many communities and how varying the role it could be a problem.

SC - voice of clarity. It’s great statement. Second paragraph we refer to ‘the group’ It’s an editorial note.

DW - as aspirationa; it’s well aligned with our messaging. We encourage communities to use the latest version.

TS - 2 thumbs up.

RR - good ideas around the table. Clarification of interoperability there is a clear difference between parts or components.

MY - Integrations are specific to tech and interoperability is about standards.

In general I like the statement. I appreciate it is an aspiration beyond Fedora. It’s like the open platform conversation. It provides a leadership position for the ecosystem.

Erin - echo MY’s integration and interoperability distinction.

AW - if we can turn vendor discussion into a clear aspiration.

RM - Clarify Jon’s comment. Will communities see Fedora as the same thing serving the same role? Do you have recommendations? We talked about getting feedback. How can we get clarity in the document on how to help with that?

JD - Some of the communities don’t speak with one voice. It’s not a simple voice. Not sure. I will mention this bc I need to leave at noon. If Fedora tries to be all things to all people - e.g. if Samvera sees it in the preservation role - is the extra baggage carried along to serve the other communities become too much trouble?

RM - it goes back to Doron’s comments too. In some respects we identified Fedora as preservation component and the other things are discovery and access.

JD - I don’t know. I can’t speak for Isalndora.

MY - bc of that complexity we might not be able to express that in this document. In the roadmap we can build in the relationship building and the communications to those communities. If it doesn’t do something we need to be clear about that. So we could add a few words here

DW - we can’t be everything to everyone. We need to say what it does and doesn’t do

PY - meta question. It’s aspirational. Or is it present and future.

MY - written in a way that envisions a future condition. These are aspirational. And in 2 yrs we can revise what we aspire to as we get closer to these.

RR - Could this lead to a service.

TS - some of these are way outside of the control of Fedora and DuraSpace. It is dependent on others.

DW - we’re not powerless. We have relationships.

TS - I’m all for the aspirational parts. Some of it is for Fedora and some of it is for other communities.

EW - do these need to be SMART goals

EP -

Flexible Modeling Support.

Ben - why the focus on extract?

KE - extraction (with regard to models) has been a repeated community concern.

EW it can’t be a black box .

RR - Repo manager expects to get out of Fedora that he puts into Fedora

DW - so this is different from CRUD operations.

TS - this is part of a preservation capability.

Ben - that’s that a good point but that wasn’t clear to me.

AW we should change the word extract.

Stefano - +1 Ben. My only concern is we should be more explicit that Fedora has no modelling by itself.

Dustin - +1 wordsmithing around word extract

Doron - We want CRUD and extraction. That’s management and not modelling. I would split it. Object management is CRUD operations. I don’t think this sentence should be under modelling.

Stefano made good point. Can we elaborate on what we mean about flexible modelling. Does it mean relationships, attributes, add some meat there.

KE - I think it’s great.

TS -it’s neutral in a way DSpace isn’t. I don’t know how to say that.

EW - if we believe in the value of agnostic maybe that needs to be in the ecosystem role? Put it higher in the document and not bury it.

PY - + 1 Extract in diff section.

EP - +1 Doron about what flexible models look like. +1 EW. Extract could be export? And I think transparency too. But maybe that’s OCFL.

Jennifer -  I like diversity and repository. It’s the first time repo shows up. I think that should be included at the top. I don’t understand what you mean about shared standards and custom modelling. More clarification like examples of shared standards.

MY - shared standards would be like METS and custom model would be NC state and makes NC state core and they think it’s good but no one else will use it.

KE - we had PCDM in there but we took it out.

EP - shared community standards or domain or organizational specific modelling for metadata and. content.

TS - we might say existing and emerging standards would work if we need to sell this to CIO.

MJ - I would remove 2nd sentence. I would put it in previous section.

JD - back to Stefano’s point. “modelling’ means an active process. “model’ could be better.

MY - ‘support for flexible models”

SC - nothing to add

DW - “”

TS - Confused by “integration” could we say support instead? Not sure.

MY - it’s alignment

Crowd YAAAAAAY!

RR - +1 to changes to lang already discussed.

MY - I had Spiderman moment when reading this.  I want to add the community provides a variety of templates for modelling

ACTION - MY will paste the statement in. Doc as suggestion.

ET - +1 maurice.

AW - Tim and others raised - when I think about flexible content models - maybe this is a habit - when talking about content and metadata - the other habitual bits would be to include agnostic files. Those are key components of this type of language.

Object Management & Preservation Infrastructure.

Doron - Separate out object management from preservation. Object mgmt is CRUD. When we say preservation we may not be doing what other consider preservation. We’re not doing format migrations or preservation planning. Transparency and fixity is there. I don’t want to oversell the preservation.

RM - We combined two sections because they were small but we can separate them again.

Stefano - +1 Doron to separation. Preservation is tricky topic. We might want to be generic here to avoid triggering opinions about what preservation is. We can indicate a strong aware of the preservation issue.

RM - how do we not go into details.

Stefano - I think of it in 2 senses. String back end that supports crashes and the other supports transparency.

Ben - Fedora APi and there will be multiple. When we say Fedora here are we talking about the Fedora community implementation.

DW - good point. We need to be specific. We probably mean Fedora Community implementation.

KE - No comment. I think this answers the DB question.

EW  - no comments.

PY 0 nothing to add

EP- referencing OCFL is good.

• no changes

MJ - Is it correct to say preservation actions is stored by Fedora?

DW it is aspirational

AW - we should make clear that people actually want that functionality eventually

Group - Yup!

SC - good

DW - I generally think this is good. Wonder about specify of fixity and if we want to get into expanding fixity. Specifics about which preservation actions. Should we include examples?

TS - I wonder did you take fixity out from the original draft.

RM - Yes, I think it was in there. But we talked about how it could be added in.

TS - Not sure if it should be in there. Some sections are specific others aren’t

RR- preservation is a hot topic and ppl think about it as a larger  thing and Fedora doesn’t do all of it so I want to be more specific about what it does and doesn’t do.

MY - I think I helped write this statement. I’m not sure what this says from an administrative perspective. As a technologist I get it.

I have concerns with the phrase “preservation actions” if I was a super fan of PREMIS I would think it’s going to that. And the addition of the word “execution” - we want to avoid getting into philosophical wars we don’t want to get into. Argument for more generalization.

RR - if we say fixity and persistence and machine readable output. Would that limit us?

MY - My issues are around human failure and fixity isn’t going to address that. The second to last sentence doesn’t add value. Under that preservation actions phrase we should revisit that language and find a more accurate language.

SC - will this doc stand on its own? Or point to other documents.

DW - we can point to other documents. This is more about position and we can point to fact sheets.

RM - this was an attempt to have this conversation.

MY - if this was about detecting unexpected disruptions in information differences between instances I would be okay with that.

Be able to measure the distance between 2 things.

TS - 3 things I heard - why wouldn’t I use a DB, bring focus to Fedora to know what to build and sell this to CIOs and a topic of conversation for ourselves. If we’re trying to do all that with this doc that’s hard to do.

RR -it’s for us and to clarify what we value even at an aspiration level.

EP - you could have a more simplified version for admin.

Stefano - it would be useful to add an FAQ to our website for each topic make it public.

ET - supports execution preservation actions was confusing for me.

AW - splitting out this into 2 sections would be good. We can tie to specific NDSA levels of preservation or the new one.

RM - I want to echo Karen. This answers the DB question. It’s an important part of helping get past that argument.

ACTION - We will have a review of the notes

ACTION - For after review as ‘are these the right 4 sections?” What are we missing. Let’s not wordsmith.

TC - our institution has goals and individuals have goals. Do we want to add Fedora Goals like “I want Fedora to be performant?”

DW it’s in the design goals.

RM - we don’t mention linked data in the doc at all.

EP - it’s referenced in interoperability and content modelling. I’m comfortable with it. It’s not letting go of linked data

SC - I feel strongly linked data could be referenced.

DW - linked data is the means by which we provide some of this functionality.

KE - LDP not being reference gets us away  from zealotry

PY - this gets to the perception issue.

DW - we have general agreement that this is heading in the right direction. I think we can move on. We will test this to other people and see what additional comments we receive.

ACTION- RM and RR and DW WILL go through and incorporate feedback and send it back out to rest of LG. Need to talk about how to solicit feedback from broader community (e.g. those nto represented here). Timeline is: have it ready for OR and present this at OR and DLF.

RM - we need feedback from beyond the Islandora and Samvera communities.  I want to know that if there a barrier since we got rid of the flash interface.

Technical Roadmap

Release API spec

Andrew, representing the API editors, making request to release

Consulting wiki and charter: candidate rec goes out, 3 month period of review and input, and that the recommendation (1.0) comes out if accepted by Fedora Leadership group as sufficient quality to become a recommendation

Ben: Would like to have two fully implemented implementations before we do this?

Andrew: yes, some was test suite and implementations – is this in the charter/hard requirements or is it realistic if that we will get two implementations? The spec is stable, there is no churn in what is going on with the spec.

Ben: if it isn’t a hard target it is okay, but would be good to have some impls that fully work that recognize the spec is fully valid.

Stefano – aligning lakesuperior to Fedora specs – in roadmap stage. Could become a full implementation of spec at some point, no timeline. By hamburg possibly?

Mark: Islandora 8 a fully functional consumer implementation (end of May) – Jared a committer, Danny on editor team. If we’d found anything wrong with the spec by now, we would know.

Ben: release 1.0, work on Fedora 5 and Drastic, if discover there are needs for change, then would go to 1.1

Ben – motion to accept

Approval in the room. David will send it out for a vote on the Leadership group email.

Technical Roadmap for 6.0

Design summary – in response to what the perceived areas are lacking.

High level summary

Rosy- can you talk a little more about the query service – native query service on Fedora to ask a handful of questions – what objects updated within a certain time frame?

Question: does this design adequately respond to the concerns/needs of Fedora moving forward? Need consensus on a direction.

Mark: how does this summary translate into a roadmap and a sprint plan?

Andrew: essentially: fedora API, no modeshape, ocfl comes in, and the addition of a query service, and notes about migration, more robust fixity. Does this sound reasonable? And if it sounds reasonable, how to reconcile with conversations about the interplay between the API and OCFL.

Rosy: Memory that whether or not 3 was part of the migration plan. Concern is that 3 needs to be able to migrate to 6. Didn’t see this in the initial documentation.

David: need to be made more explicit, but it is there about migrations. Transforming objects on disk rather than import export.

Rosy: concern about those not in Islandora/Samvera – making sure that people understand they don’t need to use RDF.

David: more info has been added about how you can use Fedora without RDF.

Patrick: sharing this design doc with his team, he is feeling positive about the data.

Mark: versioning on summary and is it part of 6 plan? (Andrew: yes)

David: everything in the API is coming along.

Ben: mapping between LDP and OCFL – still some challenging issues. Still the case?

Andrew: convo hasn’t advanced since leaving Virginia Beach.

Ben: what about the questions between OCFL and LDP?

Andrew: fear that LDP was driving too much how we are implementing OCFL, persistence.

Ben: question: if there are still outsanding challenges, are they the type that could still derail the implementation (if we approve the design doc today), or that we can make them work?

Andrew: there is the possibility that there are some ‘sticky stickies’. Agreeing on these higher level aspects, we need to commit in participating in validating the software as it is being produced. We need pilots, partnerships, engagement in the process throughout the development process. Either now, or the very soon future, can we establish some pilot partnerships to validate the development towards Fedora 6?

Karen: Or can we pay for pilots? (Some institutions are short staffed or developers have other tasks)

Tim: want to empower Andrew in role to have someone to work with on this development. Could we use funds to hire someone to identify reasonable datasets and do performance testing.

Andrew: likes the idea of hiring testers. Less confidence that hired testers would meet specific needs.  

Tim: consultant, do site visits, get content?

Patrick: timing? Could be a good time to test if it is in the fall when they will have some capacity.

Andrew: timing – key question. Great core set of developers. But they are very stretched. It is hard to figure out the timeframe with the current trickle approach to development.

Maurice: on-ramp for developers. How much do you need to know to test? Is it just testing, or do you need to parse what is wrong? Maurice has  good shop with expertise in ingest, but no one with Fedora development.

Andrew: junior folks – it is harder to ramp up on Fedora. With a skilled team they can be productive in a short amount of time.

Robin: tricky situation, working on selling the idea to work on this.

Erin: Q: is the goal testing specific use cases, or the partnership have an outcome that is more than just testing.

Andrew: would like it to be more than just testing. “ergonomics” of the project. Preferences between Fedora urls and ids and how it translates into the pear tree path. Feedback beyond just core developer  team.

Patrick: Get code to test, give feedback.

Tim: could we engage with a consulting firm adjacent to our culture to get help.

Rosy: can she pay consultants to do the migration – but would be a couple hundred thousand dollars.

Mark: Lyrasis – heard ‘deploying staff’ on particular projects. Could organizational change interfere with our time frames?

Erin – junior staff could get trained but not an immediate thing – building a deep bench but not possible right away.

David – we have a number of ways we could make this happen. On some level, working with institutions who have use cases. We don’t want to build a bridge to nowhere. We need adoption. Commitment to say we’ll use it.

Sayeed – in that spirit, if, JHU has time to help, it will come in July. That is the good as it will get.

Andrew: aaron birkland’s ocfl client is a critical part of Fedora 6.

Tim: Lyrasis funds – put on projects (catalyst funds). Commitment to Fedora 6 would engender some trust? (Erin: they put out the call in January)

Karen – Lyrasis has a stake in Islandora

Erin – could be a collaboration between Fedora and the board to work on Fedora 6. Would need to justify this. Some avenues if we can create a strong business case and what the investment is.

Mark: also other interests – Fedora 6 on OCFL – strengthens preservation interests.

Erin – look at multiple components in the workflow Can discuss scope.

Evviva – Avalon – not hosted through Lyrasis, not where they are headed.

Este – would like to discuss the idea of a Lyrasis angle in regards to the Islandora Collaboration Group and use cases.

David – does anyone reject to the design plan?

Tim – angst is with testing, not with design plan. We need to involve the community. Needs to hear a commitment to do the work that Andrew needs to get this done.

Maurice – Path to adoption seems to lie with Fedora 3 users.

David – we have Fedora 3 folks who want to test/adopt

Este – still follow the mapping OCFL to LDP

David: Will put a vote out to the list for the design plan

Maurice: didn’t finish the activity streams – call for participation in the groups. Ready to go on some other streams now that we have the Product Position done.

David: clean up product position and put out a call for folks to join the groups.

Actions

• David Wilcox Rosalyn Metz Robin Lindley Ruggaber review product position doc, incorporate/resolve comments, and share with the rest of the LG.
  
• David Wilcox  Ask for vote on approval to release Fedora API Spec 1.0
  
• David Wilcox  Ask for vote to approve high-level Fedora 6.0 design
  
• David Wilcox  Put out a call for more Vision and Strategy group members