Attendees

1. Laurie Gemmill Arp 
2. Jon Dunn (first ~45 minutes only)
3. Jennifer Gilbert 
4. Arran Griffith 
5. Scott Prater
6. Robin Lindley Ruggaber 
7. Oliver Schöner 
8. Timothy Shearer 
9. Terry Reese 
10. Kate Dohe 
11. Rosalyn Metz  
12. Heather Greer Klein 
13. Maria Esteva
14. Alexander Berg-Weiß 
15. James Alexander 
16.  Nicole Scalessa 
17. Dan Field 

() Indicates Note Taker

Agenda

Notes:

1. Budget proposal (Arran)

• Proposed budget approved for FY24-2025
  • An investment will be made in order to increase in staff resources to support technical objectives.

Goal: increase technical resources for Fedora (increased adoption, tech debt to pay off)
Tech investment: updating outdated dependencies

Q: Will this investment dip in to rainy day funds to spend this year?  
A: Yes. May not need to spend that much, if member income turn out better.  Keep in mind that developer resources shifting to full time will be expense beyond next year.  But good return on investment.
*Budget approved.*

2. Tech update (Dan Field)

Fedora 7: upgrade libraries (Spring, Java, Apache, Postgres, ActiveMQ, Jetty)
No API changes -- build dependencies changes
Q: Major version change necessary? Strong signal to community.
A: Build dependency, integrations a major, possibly breaking change.

Comments: Major version change a pressure point; may create a perception change that Fedora is not stable.  Fedora 6 intended to be stable, long-term, to calm the community after churn around Fedora 4 and 5. Fedora 6 was a complete rewrite, designed to be more like 3. Fedora 3, 4 and 6 fundamentally different products.  Will 7 be another fundamental change? Perception in community that 7 will be another major breaking change. Fedora 6 is a good use story, with great branding. Fedora community is not a fast-moving community, change is perceived as
cumbersome.  Security changes is important, but want it to be perceived as not a source of anxiety.
So:  do we want to reserve major version changes for big changes, or start making community comfortable with smooth major changes?
Are we ready yet?  Good place to get to, but maybe not there yet. 
We should make a roadmap of the future, make it public, so people can plan.
Perhaps take a long-term-support plan, with a common release pattern of time-bound support for a given version, while new versions are released.
We do need to deprecate support older libraries, too, which can be done by version-by-version.
We should think about our versioning plan, then, come up with a release plan and a communication plan.  We should use historic perceptions to determine what we want to do going forward, but not necessarily adhere to them slavishly.  We have the opportunity to change the narrative on what a major release looks like, what it means for our community.
Fedora version 7 has not been decided on definitively; next could be a minor release, but may be a year or two out.
Intention is that upgrade will be seamless and transparent as possible.

Progressive testing for performance: recording test results, realized that memory and CPU are not being stressed;  writes are expensive, as are ingesting many small files (problematic for some kinds of file systems)
Focused on high-performance computing environment, but has uncovered some generic problems
Goal: working on parallel ingests, to shift load back to CPU and memory
Thanks to TACC team and Maria Esteva for discussions around performance
Variety of storage systems, options much more varied than originally understood; improving performance is an onion, taking into account the entire stack, and costs with each solution (time, money, maintenance...)
Q: Is OCFL a bottleneck?
Comment:  Fedora needs to be performant and efficient, but doesn't need to scaled to high-volume real time requests
A: Current bottleneck is write operations; sheer writing of large number files is primary concern.
Comment:  This is a great use case, and time spent addressing it is well-spent. If we can offer users tips on tuning their architecture, that is a really big win.

Removal of one-click option.  Designed for testing, not for production.
Relies older version of Jetty; relies on older version of Java.  People now use docker.  Currently broken; nobody in community seems to miss it.

3. Membership funding campaign

Goal: get it out in advance of membership renewals
Ties to budget proposal – Looking to raise at least $25,000

Arran has messaging created, asks community/governance help getting the word out.
Buys us a year to continue to work on a long-term sustainable financial model.
$500 more from each member would meet our goal.
Membership level increases: higher levels bring more benefits, some new Lyrasis benefits may be introduced
Messaging calls out concrete technical deliverables funds will cover
Arran showed her draft poster.  Arran will take feedback on it.  Scott and Arran working on more formal targeted message for executive decision-makers.
Is it a one-time ask, or an indefinite increase?  Whatever we can get.

4.  Tech Survey results

Posted on Lyrasis now blog.
Goal: priorities for next 18 to 24 months
After months of internal work and discussion, determined these projects in priority order:

1. Performance improvements
2. Fedora Technical Documentation Upgrades
3. Migration support
4. Network of shared implementations
5. HTML UI Facelift

Resources for Fedora support is challenging; most cannot contribute to code, but may be able to tackle concrete tasks (testing, documentation, etc.)
Much of the work is already in progress; no surprises about priorities
expressed by community.
Plan:  use this prioritized list of projects to create and publish a community roadmap, tied to messaging and funding
Q: Can community roadmap be published in time for funding campaign?  A:  Arran is planning on it, yes.

5. Website working group

Contracted outside designer to help design it.  New site slated to be released
in June.
Website working group activity: challenging to organize info across
Duraspace, Lyrasis, wiki, Google docs, and Github.  Staging work with website
first, then wiki.
Thinking about information architecture, different user audiences, user
experience (DRY, etc.), and accessibility (part of what contractor is
delivering).
Where we are: info architecture, audiences, design pretty strong, in QA stage.
Arran will release website for governance review soon.
After website, working group will turn towards redoing the wiki, probably from scratch.
Goal:  come up with same terms, images, etc -- brand identity kit -- for everyone to use when talking about Fedora.

6. Community Participation update

Islandora update: scramble to upgrade to Drupal 10.  Now in testing phase.  Unexpected update was a big hit to budget.
Area for improvement: make community projects that rely on Fedora more aware of what Fedora is, its value.  Perhaps a presentation to Islandora community?  Next Islandora GLAMmeeting will focus on infrastructures.

Hyrax Fedora 6 Working Group: following on work with Sirenia (Hyrax 5, Valkyrie, and Fedora 6), uncovered some bugs (one Fedora-related, now squashed).  Reissued scope and deliverables, to investigate path to fully-functional Sirenia, and performance testing of it.  Due to Hyrax data modelling, approach to migrate is to export Fedora data, then reimport into Sirenia test stack.

7. Future discussion topic: in-kind contributions.  Path to Fedora governance, and how it translates to membership level? Currently offered on ad hoc basis.

Next activity: membership funding campaign. Volunteers welcome