- Time: 11:30am Eastern Daylight Time US (UTC-4)
- Dial-in Number: (712) 775-7035
- Participant Code: 479307#
- International numbers: Conference Call Information
- Doug Blair
- Ginny Boyer
- Aaron Choate
- Stefano Cossu
- Tom Cramer
- Joanna DiPasquale
- Jon Dunn
- Karen Estlund
- Declan Fleming
- Maude Francis
- Mike Giarlo
- Neil Jefferies
- Debra Kurtz
- Susan Lafferty
- Steve Marks
- Rosalyn Metz
- Este Pope
- Nick Ruest
- Robin Ruggaber
- Tim Shearer
- Jon Stroop
- Jennifer Vinopal
- Evviva Weinraub
- Jared Whiklo
- David Wilcox
- Andrew Woods
- Maurice York
- Jim Tuttle
Code of Conduct, suggestions for moving forward:
|Samvera / Fedora technical alignment discussions|
Michael J. Giarlo (or Andrew, if Giarlo is out)
|Successful Texas/Oklahoma Fedora User Group meeting last week||No discussion needed|
Fedora at the IFLA WLIC last week
|David and Evviva|
Stefano due to take over as chair September 1.
1) Strategic Plan
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 OR2017 conversation re: Valkyrie - 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 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?
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.
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!
Adjourned at 12:31pm.