Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Advanced Tables - Table Plus
autoNumbertrue


Topic

Lead

DuraSpace Summit breakout topics (need to choose two)

  • Policy for previous version support (see below)
  • Integrations with third party applications
  • Sustainability; Aligning our goals with the reality of resources 
David

Agenda planning for strategic meeting on April 6 after DuraSpace Summit

David
Establishing a policy for previous version supportAndrew
Import/Export sustainability and engagementNick
Update on alternate Fedora implementationsAndrew
Organizing a code sprint to work on Fedora API Test SuiteAndrew
  



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