...
1. Budget proposal (Arran)$24,334 over
- 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
Funding for Mike Ritter will cease
Q: $25K of 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 Dan going developer resources shifting to full time will be expense beyond next year. But good return on investment.
*Budget approved.*
...
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.
...
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