...
Stefano due to take over as chair September 1.
1) Strategic Plan
Draft is https://docs.google.com/document/d/12Nu5mFFqltrUg5J4MpuNzTVtqaVwEApqfQVQ0y3SxRw/edit#
Came from a discussion at OR about long-term vision for Fedora
Goals today: finalize list of stakeholders, discuss structure/content of document as it stands
One struggle has always been defining the need that Fedora meets. Need a concise statement of the niche FC fills.
SC: does Inward Facing | Target Audience address this?
Maybe, but it doesn’t help answer questions about concrete decisions in development direction.
Would be really useful for this to be the canonical version of the Fedora Elevator Speech
Could we discuss this fruitfully at CNI, with an eye toward presenting it at the next CNI?
How much is this a Strategic Directions document vs. a Strategic Plan?
Stefano will send out a Doodle poll to schedule a meeting of the stakeholders group.
2) Code of Conduct
Recap: General support for Duraspace CoC but changing notification to Fedora specific group. Some policy documentation - e.g. membership, process, issue handling paths - needed..
Need to formalize this group before the latter work can begin.
Folks who are interested in participating should contact Rosalyn.
3) 4.7 as LTS release
Is there agreement that selecting certain versions of Fedora as LTS releases is a good thing?
Does this include upstream developments - e.g. new versions of Modeshape?
AW: There’s a bit of discussion to be had here. Another example of this issue is Java version.
Important that the statement of what the LTS provides is API stability.
Do we have an idea of the adoption rate?
refer to Fedora 4 deployments page on the wiki
What are the implications for other non-LTS versions of Fedora?
There exists a policy of support for major releases, incl. critical bug fixes.
not release more than 1 major release/year
critical fixes to latest major release
Does the creation of LTS carry certain expectations about ease of migration?
Why 4.7 as candidate for LTS?
two upcoming dev sprints to align core functionality with API specs
Concern to address: if developments in upstream applications necessitate premature (i.e. less than 3 years) change to the LTS
General support for this idea, if taking into account the above issues.
AW will bring back to LG before this goes more public.
4) Samvera/Fedora technical alignment discussions
Discussion spawned by OR OR2017 conversation re: Valkyrie - backend to switch backend filestore/indexes easily. Provides Samvera community an opportunity to not be tied to specific components, e.g. Fedora- a new, proof-of-concept component that will allow Samvera-basd applications to more easily swap out persistence back-ends for metadata and files. Provides Samvera community flexibility, so folks can use the back-end that best fits their needs in a way that does not preclude a shared UI. In the Fedora Leadership context, this means that Samvera applications could be based on a back-end other than Fedora.
Held two calls between Samvera community, Fedora API editors, and Islandora Tech Lead two weeks ago and ultimately decided on the following next steps
Begin specifying query requirements in a sidecar Fedora API Specification
Put cycles towards Modeshape implementing the Fedora API Specification
Put cycles towards Cavendish implementing the Fedora API Specification, and other bits Samvera would need from Cavendish
Continue Valkyrizing Hyrax
Create Valkyrie adapter that relies on the Fedora API Specification (including the query sidecar)
There are
Meeting between Samvera community and Fedora API editors.
Next steps for Samvera: NEED FROM MIKE G
May be pressures from institutions to switch to different backends for performance reasons, even if it's a short-term change while work on performance in Fedora implementations continues.
How do things depend then? Some Samveras
Hard to say now because it's early days. It seems reasonable to say that some Samvera applications will depend on Fedora
and some won’t.
MG: if there is widespread adoption of Valkyrie, then that is likely to happen. Note that much upcoming Samvera work is Fedora-centric, so this is a commitment to Fedora but allows Samvera users flexibility in how to persist their backend data stores.
General agreement that this conversation should continue here.
Will be a continuing topic for next call.
5 & 6) Everything went great!
...