Time/Place

Attendees

  • Chris Awre 
  • Robert Cartolano
  • Aaron Choate
  • Sayeed Choudhury
  • Stefano Cossu
  • Tom Cramer
  • Joanna DiPasquale 
  • Jon Dunn
  • Karen Estlund
  • Declan Fleming
  • Maude Francis
  • Neil Jefferies
  • Debra Kurtz
  • Susan Lafferty 
  • Steve Marks
  • Rosalyn Metz
  • Tom Murphy
  • Este Pope 
  • Nick Ruest
  • Robin Ruggaber 
  • Tim Shearer
  • Jon Stroop (star)
  • Jennifer Vinopal
  • Carolyn Caizzi
  • Ben Wallberg
  • Jared Whiklo
  • David Wilcox
  • Andrew Woods
  • Maurice York

Agenda

Topic

Lead

Vision and Strategy spreadsheet review

  • Is column A correct and complete?
  • What about column G?

Proposal: Islandora and Samvera technical liaisons

  • Non-voting representatives similar to Ambassadors
  • Facilitating close alignment with Islandora and Samvera from a technical perspective

Fostering greater adoption of Fedora 4+


Project priorities for the coming year

  1. Fedora API Specification
  2. Aligning Fedora Modeshape implementation with the specification
  3. Fedora API Specification test suite
  4. Increased preservation sensibilities: Oxford Common Filesystem Layout?
  5. Design recommendations/tools for migration?
    1. Adopters guide (https://github.com/fcrepo/fcrepo-adopters-guide)

Next Leaders/Committers meeting on March 19


Drafting a 2017 Fedora annual report

David


RoundtableAll

Previous Actions

  • Vision and Strategy group: debrief CNI meeting: identify work to be brought back to Leaders.
  • All: Explore how to bring better cross-effort alignment between Fedora and other repository efforts.
  • All: contribute to generating content for, and formatting Fedora annual report.
  • DuraSpace staff/All: Generate and share articulation of benefits of moving to Fedora 5.

Minutes

Vision and Strategy Discussion: Next steps of working with roadmap, will build in lenses, perspectives of our home orgs. The sub group meets on Friday, want to check in at different points to collect feedback along the way. Call for comments, add them on the spreadsheet. Comment, don't update it will get confusing. If cell is blank add text, if it is populated, add a comment. Remind leadership of spreadsheet to get feedback. The roadmap isn't complete, but want to make leadership aware and give opportunity for feedback. Group meets every two weeks on Fridays at 3PM EDT. Change log tab, second tab, to capture major adjustments to the roadmap. Please review and comment at your convenience. Could build a round of 'what's missing exercises' into process.

Proposal: Islandora and Samvera technical liaisons. Discussed at Steering (9 rotating members, subset of leadership). Facilitate closer, tech alignment in related communities. Nurture good existing relationships by inviting representatives from each in a non-voting capacity. Do we think this is a good idea and if so, are the criteria good? What is the right number of representatives from each related community? In principle, good idea, should use inclusive language to allow for emerging technologies/communities. How will the reps be selected? Having multiple Samvera reps not appealing to many. There are many R1s at the table but that isn't necessarily the user base. Samvera has the same representation of R1s and we could (unsittingly) reinforce practices that are not inclusive. Discovery Garden has decided not to upgrade to Fedora 4, many orgs might follow. Might want multiple Islandora orgs for this reason.

How can we accommodate this equitably? If there is a tech liaison why aren't they on Fedora tech calls? Don't want to create a community structure 'bolted' on to leadership/steering. How do we manage the size of leadership and maintain focus? How many Samvera ppl are already in leaders? Already members of both communities but not at the level of the code. There is an open invitation to each group's tech calls but no one really exploits these opportunities. Are there members already identified in each group? Islandora, yes, there is governance in place that allows for this. No one in Samvera designated at tech lead. Samvera is fairly fragmented, that and no formal governance make it more challenging to identify a single person. If there isn't a way to represent Samvera, it's hard to accommodate, coordinate, and communicate. No harm in trying and evaluating. Do we kick back to Samvera and say we have only a small number of seats, whom do they recommend? Co-facilitators of governance group are on leadership and can convey need to governance. LDCX - Samvera governance to be on agenda. Fedora should come up with criteria and allow/encourage communities to nominate reps based on the criteria. Can work with Samvera community, even as they organize and address governance. Likely someone who has broad enough tech knowledge to be a good participant. Could have a 'one-at-a-time' participant policy.

Question: would a technical person feel comfortable in leadership? Are the agenda topics relevent to them. There are some technical issues addressed, need technical voices at discussions. Why not talk with committers to address issues instead of leaders. Is there need for a user group community - give feedback on product. Tech roadmap - may or may not be in alignment with roadmaps of other products, need someone who understands code but isn't necessarily a developer. Someone who can speak to the alignment of respective roadmaps.

Group agreed on the following:

One-person-at-a-time, someone who meets these criteria:

  1. Have broad technical knowledge of their community’s application framework

  2. Understand the roadmap for the application framework

  3. Understand how technical changes in Fedora may impact the application framework, and vice-versa

Fostering greater adoption of Fedora 4+. How can we realize potential of large group of Islandora/Fedora users? Jared summary of CLAW project:

https://docs.google.com/document/d/11Jjwl96HyO9XkrGSuGTnM5sidPo_ChIU3cC0D8dpoTc/edit

Spent a lot of time on installation because the stack is quite large. Now have something that will take resources from Drupal to F4. Simple but syncs nicely. Flexible, can build your own content modules. Using APIx and can share microservices. Would like to have Fedora repository at end that can be populated by Drupal. Have a good core community of 4-5 developers/non-devs testing and bringing up use cases. 

CLAW presents an opporunity to get devs, testers, early adopters. Is this something we want to prioritize this year? Should we contribute resources to CLAW. Can we get map of technology that identifies areas in most need of development? Islandora CLAW is Drupal-based: PHP, Drupal, Java middle ware, on APIx something called Alpaca, Apache Camel handles fault tolerance well. Fedora on the backend, used as-is. Have so much work on front-end, not ready to investigate doing more with Fedora. RDF metadata module currently only works with schema.org, limiting, want to takeover existing module to expand to take on ontologies of choice. All objects going into Fedora go in with Drupal identifiers, would like Fedora objects to use their Fedora IDs when referencing each other. The Git queue used to document issues. What can Fedora do help CLAW dev? Have a large community of devs who sometimes do their own thing. Need to get more people involved, might be more interest in things like Oxford Common File System. Right now, might not be much with which the Fedora community can help. Sayeed is interested in contributing some of Aaron B's time. We can/should think about directing some of our institutional resources towards the CLAW effort. David has asked Danny Lamb where the Fedora might get the most bang for our buck if we direct resources to the CLAW efforts. 

THANKS to Jared for the review. Whole other world going on with Islandora, the point at which orgs move over to CLAW difficult to tell - no clear path. Important to think about how we can help chip away at the path to CLAW. How much are things aligned with CLAW efforts will benefit Fedora users? Migration path - University of Manitoba has millions of newspapers that will require migration to another system. Lots of concern about migrating resources. 

Actions