...
- 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
RobertCartolanoCartolanoAaron Choate- Stefano CossuCossu
- 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
...
Advanced Tables - Table Plus | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
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