...

• 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 Cartolano Cartolano
• Aaron Choate
• Stefano CossuCossu 
• Dan Coughlin 
  
• Tom Cramer
• Jon Dunn apologies
• Declan Fleming 
• Maude Francis
• Mike Giarlo
• Wolfram Horstmann 
• Neil Jefferies
• Debra Kurtz
• Susan Lafferty
• Steve Marks
• Tom Murphy
• Sandy Payette 
• Matthias Razum
• Nick Ruest
• Robin Lindley Ruggaber
• Dan Santamaria
• Jon Stroop
• Jim Tuttle
• Keith Webster
• Evviva Weinraub
• David Wilcox
• Andrew Woods
• Maurice York

...

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