Time/Place

• Time: 11:30am Eastern Daylight Time US (UTC-4)
• Dial-in Number: (712) 775-7035
  • Participant Code: 479307#
  • International numbers: Conference Call Information

Attendees

• Chris Awre 
• Ginny Boyer
• Robert Cartolano
• Aaron Choate
• Sayeed Choudhury
• Stefano Cossu 
• Dan Coughlin
  
• Tom Cramer
• Joanna DiPasquale 
• Jon Dunn apologies
• Declan Fleming
• Maude Francis
• Mike Giarlo
• Wolfram Horstmann 
• Neil Jefferies
• Debra Kurtz
• Susan Lafferty
• Steve Marks
• Rosalyn Metz
• Tom Murphy
• Este Pope
• Matthias Razum
• Nick Ruest
• Robin Ruggaber
• Tim Shearer
• Jon Stroop
• Jim Tuttle
• Keith Webster
• Evviva Weinraub
• David Wilcox
• Andrew Woods
• Maurice York

Agenda

Previous Actions

Minutes

Fedora technical plans - gain consensus, highlight vision for technical work and how the pieces fit together. 

1. Finalize API spec - June 20th deadline for initial public working draft, five person editorial team with weekly, Wednesday meetings has ensured we stay on schedule. There is a delta between specification and current implementation, a certain amount of work needed to move the implementation forward to align with spec. Ideally this summer work will begin. We want to encourage community who have use cases that current implementation isn't addressing or isn't addressing well, that we try to address in newer spec. Given diversity of use case it's conceivable that there won't be a single specification that addresses all needs. Another set of work around test suite. Regardless of the implementation chosen, priority number one is to move outliers to chosen version. Have already made significant progress towards import/export tooling. Support for plan voiced. Are there ways to name implementations for easier identification? Part of branding conversation. Leadership needs to put more thought into this, as reference and community implementations evolve. Don't have a clear plan for branding questions. How do we want to position Fedora brand and implementations? Communicate dependability and avoid fracturing efforts. On agenda for leaders meeting at OR.
2. Align ModeShape implementation with the spec
3. Foster alternate implementations
4. Move off ModeShape if a better alternative is identified
5. Bring along anyone who is currently on ModeShape to the next implementation

Scheduling a code sprint to align the current Fedora implementation with the API spec - align community implementation with API spec, need at minimum three institutions who can commit resources to the sprint, lay ground work to open up to broader community. Need to have specific dates to engage with committers on those dates. For the leaders who might be interested in the broader plan and this specific work towards API spec, we need commitments from leaders. Call for participation. Will also send a note to Fedora leaders to approach institution. Question: Do we have a sense for timeline of work? Start work after OR, July, August, and September. Amherst voiced interest, need to confirm resources and commitment. Sprint just completed with import/export succeeded because there was a diverse work team, developers, testers, documenters. The ask isn't just exclusively for developers. Question: When API goes out in June will there be a solicitation for feedback? Getting feedback will lengthen timeline. Need to review for accuracy and to confirm they meet clients' needs. Server side feed back, those implementing. Context for specification work can be found here: https://github.com/fcrepo/fcrepo-specification/wiki/Fedora-API-Specification-Charter

First public working draft June 20th. As new people come onto leaders are they invited to the channel on Slack? Several voiced this is not happening. Need to operationalize. When a request goes out to leaders, would be helpful if it was contextualized, verified.

Moving towards institutional developer commitments - In Fedora 3.x era commitment more personal, did not seem like this was written into job descriptions and responsibilities. Ppl worked on this after office hours. Contributing to single projects vs. a suite of OSS. Would be helpful if 'on the ground contributions' development/testing, also helpful to have some time allocated to Fedora and other OSS projects of value to the community. Andrew notes some institutions reserve Friday for "Open Source Day".  Majority of contributors are ad hoc. Need to operationalize this at your institutions. How can we increase time contributions at your institutions? Support voiced for "Open Source Day". Each institution needs to figure how they can contribute. Northwestern mandates that each developer has to participate in at least one sprint annually, ensures long-term sustainability of projects. What are the barriers to such approaches? Harder at institutions with fewer human resources. More organizations like this than not. Have to make this an institutional priority. Public universities may have the advantage making it part of the ethos. If you are a consumer but not a contributor, limits the reach of the project. Smaller institutions - how do we get orgs that don't have developers to contribute? Who is doing testing? How do we know it's working? How can these orgs help without contributing development? QA, testing?, can we have other ppl deploy in production. Support for this voiced. Hackdoc model, consortial approach getting help with testing, documentation. Need to articulate how orgs can contribute without coding - will lead to coding. Need to clarify non-developer roles: dev ops, testing, documenting, contextualize around how to engage. Open question around tactics of how to make these roles known, communicated. Maybe add to monthly newsletter. If such clarity exists, then might be easier to allocate time (weekly/monthly) to project support. Where is development time most relevant, useful? Maybe a manager component, a campaign to ppl who manage development group. Advise managers on how to coordinate and prioritize work at their institutions? Have been some obstacles that have discouraged some of the community. Have addressed these issues and hope that community is more welcoming. 

Agenda for OR2017 Fedora LG Meeting - Please have a look and provide feedback! 

Membership ideas from Task Force

• Merging Fedora, Islandora, and Samvera site information into a master list - use this to figure out who uses Fedora 'writ large', need to a more definitive list. Who can we in leadership reach out to? If you know where some of these lists are report to David, Rosy, and Chris.
• Allow individuals to declare their support (similar to DORA) - Our membership model is geared to institutions and soliciting financial contributions. How can we get institutions and/or individuals to highlight broader use of Fedora and to highlight the institutions that use Fedora. DORA initiative, research analytics. Anyone can sign up. Model for drumming up. understanding interest. Powered by Fedora, might be an option but you can use this badge without being affiliated
• Develop corporate sponsorship model (ideally based on the VIVO model) - Incorporate corporate memberships, Triple I bought VTLS, Vital is a Fedora based project. They could be/should be a corporate sponsorship. May be others. Also relates to the Registered Service Provider (RSP) program most used by DSpace (but also VIVO and some interest voiced in Fedora). 

Vote on Fedora/Islandora/Hydra proposals for DLF!

Actions

• Andrew Woods - Add new ppl to Slack leaders, Ginny, Este, Rosaline, Joanna. 

Need to clearly define roles for contributors, new leaders should be able to see how to engage with a minimum amount of knowledge. Clarifies commitment for manager = understands and can align work with their institution's mission.