Time/Place
- Time: 11:30am Eastern Standard Time US (UTC-5)
- Dial-in Number: (712) 775-7035
- Participant Code: 479307#
- International numbers: Conference Call Information
Attendees
- Chris Awre
Robert CartolanoAaron Choate- Stefano Cossu
- Dan Coughlin
Tom CramerJon DunnapologiesDeclan Fleming- Maude Francis
- Mike Giarlo
Wolfram Horstmann- Neil Jefferies
Debra Kurtz- Susan Lafferty
Steve MarksTom MurphySandy PayetteMatthias Razum- Nick Ruest
- Robin Lindley Ruggaber
Dan SantamariaJon StroopJim TuttleKeith Webster- Evviva Weinraub
- David Wilcox
- Andrew Woods
- Maurice York
Agenda
Topic DuraSpace Summit breakout topics (need to choose two) Agenda planning for strategic meeting on April 6 after DuraSpace SummitLead David David Establishing a policy for previous version support Andrew Import/Export sustainability and engagement Nick Update on alternate Fedora implementations Andrew Organizing a code sprint to work on Fedora API Test Suite Andrew
Previous Actions
Minutes
- Preservation survery
- Survey is closed: 36 responses
- More details will follow
- Duke will summarize results before sharing with the group
- Duraspace Summit Breakout topics
- Will gather some more ideas and send out a survey soon
- We want to decide rather quickly
- re: point #2, would that include integration with Islandora and Hydra?
- Probably a better fit for the following leaders meeting
- re: point 3: establishing a code of conduct is important to guarantee sustainability
- Strategic planning meeting topics
- We should be looking beyond 2017
- regardless of concrete goals, see ourselves in X years
- API spec finalization will drive most of the strategy
- Value proposition
- Consolidate raw data gathered along Fedora4 evolution into a vision plan
- Previous version support policy
- Which level of support do we want to provide?
- How many resources do we want to dedicate to support?
- Explain how we intend semantic versioning
- Regardless of details (how many previous versions, for how long, etc.) we need to formalize a legacy support policy
- Look at other examples and at least match similar products, considering that Fedora is preservation software
- We have 4.7.1 instances running in production, we need to answer the question: how long will it be supported?
- We can articulate a more detailed policy after the API specs have been formalized and TCK tests are developed
- It is hard to predict how long we can support something that has been just released
- We want to avoid being a moving target—we want to give guarantees of stability
- We cannot force implementers to jump on the next version as soon as it is released
- On the other hand there are concerns over resources; we may not be able to guarantee support for previous versions without chipping at current version support and new development
- This seems to boil down to finding more engagement & more resources
- This is a leadership question and a key conversation point for next post-CNI
- Import/export
- Had a good start
- A lot of time and effort was put into it
- It's ready for stakeholders to test but no response has been heard
- We need to stop import/export work until stakeholders are engaged
- Also some work will be needed to align to API specs when these are finalized
- Some further work is needed
- Create API - Tests for API specs - Import/Export
Actions
1 Comment
Stefano Cossu
Just an additional comment on the previous support policy. The issue seems to be not as much agreeing on the importance of a support policy, but rather on finding adequate resources to enact it.
That said, I think that previous version support should be regarded as a key factor to determine the quality of a software product, along with features and documentation. When defining the budget needed to run the "Fedora shop" we should include this point, hence the importance of formalizing this policy at least internally as a target until we have the resources to make guarantees about it.