...
- 2015 Targets
Migration - next six months
Andrew
4.0 release greenfield
4.1 release - targeted for OR - get Fedora 3 to Fedora 4
Migration Discussion
4.1
squash bugs
new features
Migration
Establish pilots
which features need to be migrated
get many Fedora 3 institutions involved
documentation needs
tooling needs
approach - in terms of objects
use a connector, helps eliminates concerns
connector talks to Fedora 3 REST API
regardless of some configuration variables
will simplify the transfer of assets
need for parallel systems
will need servers and storage
can't do an in-place upgrade
it's a content migration
it's a software upgrade
What do we tell people who want to stay with XML vs. RDF?
You can't keep all forms of XML, like inline XML
Fedora 3 audit trail, can become XML data stream, but not inline
Break out Fedora 3 features
do some early analysis, what is going to be possible
requirements for Fedora 3 to Fedora 4
in training, documented considerations for upgrades
security policies
versioning
disseminators
how data and functionality map from 3 to 4
Migration Scenarios
Greenfield installation
upgrade to Fedora 4 and replace functionality over time
Hydra
could have made Fedora 4 look like Fedora 3
strategic decision to move to Fedora 4 approach
continuum of migration options
consensus - quick analysis to determine migration needs
find common needs
migration working group - consensus
Migration Complexity
consensus it will take time to determine scope
Systems Administrators
Application Functionality, Compatibility, Refactoring
Content Migration
Hydra and Islandora - will be easiest community to migrate
Penn State - looking at using Hydra as migration tool
What is possible in the next 6 months?
Moving Content to a new system
can play with content, even if you haven't moved to a new system
Have pilots
working through migration
specific features and capabilities
content
After 6 months
have a few examples of sucessful migration
Documentation
Identify Migration Types
Greenfield
Hydra/Islandora
Custom
Wild West
Rebuild/Refactor - rewrite and ingest
New functionality - incorporate back into Fedora/Hydra
Promote the concept of community development when appropriate, recognize and respect the need for institutions to locally customize when required.
What if there are significant issues related to Fedora 3 migration?
at some point the community will have difficulty in supporting
Fedora 3 beyond security patches
Migration consultancy - At OR2015, have a room for migration support
"Upgration" - Software Upgrade and Content Migration - a new term
ACTION ITEMS
Survey
collect information, quickly canvas the community
identify use cases, common services and approaches
keep as simple as reasonably possible
some demographic data
geography, size of installation
intended for leadership group
ship out after Monday January 12th
get responses back by February 1, 2015 (??? to be finalized by David and Andrew)
2. Establish Migration Working Group
Code4Lib - awareness booth
OR2015 - upgration booth
Fedora 4.1 Release
- Fedora 3 to 4 migrations
- Bug fixes
- Features
- Which priorities (established last year) are still relevant?
- What will be the process for prioritizing feature development?
- Engage the community
- Technical use cases - need to have some tie to Fedora 4 development
- Connect to leadership and strategic priorities
- Some evolution in software development
- rotating group of developers
- need to balance priority needs with developer resources
- Discussion setting priorities
- New Candidate features/discussion
- Migration - Rob/Columbia
- Remote/Asynchronous storage - discussion and consensus, Jon/Indiana & WGBH funded project
- Hydra/Islandora Content Modeling - Declan/UCSD - community engagement, reach consensus
- Hydra development coordinated with specific Fedora 4.x feature development - Tom/Stanford
- LDP-Paging
- Audit service
- API partitioning
- Web Access Control
- How to support feature development from staffing/leadership perspective
- Which priorities (established last year) are still relevant?
- Fedora 3 to 4 migrations
- Bug fixes
- ACTION ITEMS
- Product Manager
- will engage community and leadership to prioritize features
- consensus will come with commitment for effort
- gather additional resources from community
- Educate managers and decision makers to bring on board potential developers
- Continue to grow and expand mailing list
- Product Manager
- Hydra & Islandora Development Impact toward Fedora 4 Feature Development - discussed earlier
Development Resources (current commitments)
Background
No committer model (just contributors)
Lack of continuous engagement from developers
Challenges establishing a developer community
Discussion
Dollars not available today additional developer resources
Link to institutional context is important
Short-term efforts could address specific problems
Opportunistic developer resources
align development to solve local needs and community needs
grant-funded initiatives
Cultivating new developers and contributors when possible
Adapting to the institutional development cycles
2-week sprints
Migration to Jira to engage developers for bug fixes
Training and documentation
Define profile of Fedora contributor - Andrew
- profile for managers and leaders
- Possible multiple contributor (developer, debugger)
- Community Development & Cohesion
- Cohesion
- Development
- Training to raise Fedora awareness to both developers and leaders
- Discussion about separate events as well as events tied to existing conferences
- Training Strategies
- In Person (proposal)
- 3-day training pilot is effective - consensus that we will create a 3-day training
- Regional meetings
- DC meetings coupled with training effective
- New England, UK, Wolfram proposed Germany/Europe
- Co-location training opportunities (devs and managers)
- Other training discussion
- get managers on board - DLF, OR, CNI
- Review Conferences for potential dates
- 1-day training opportunities in 2015
- ACTION ITEM
- Leadership voted to spend up to $10,000 for developing 3-day training curriculum
- Tim to reach out to potential person who could develop training
- David Wilcox will coordinate next steps
- Leadership voted to develop curriculum using CC-0 licensing
- sense that little market potential for training materials
- we want to encourage the dissemination and training for Fedora 4
- we don't want to restrict the re-use of training materials
- Robin will send follow-up note to Fedora Leaders to allow non-attendees to provide feedback
- Leadership voted to spend up to $10,000 for developing 3-day training curriculum
- In Person (proposal)
- Communications strategy
- Conference attendance
- Near-term scheduling
- DuraSpace Summit
- RDA
- PA-SIG
- Fedora Leaders should indicate conference attendance - Robin will send out note to all Leaders
- In-person meetings - try to meet about every six months
- OR 2015 conference - Indianapolis
- December CNI
- David and Matias leading user group track, get out more announcement for call for proposals for OR2015
- Near-term scheduling
- Outreach
- webinars
- successful beta pilots - 30 to 40 people attended
- working group webinars
- migration, content modeling, hydra, Islandora,
- webinars
- Conference attendance
- Finance
- 2014 Summary
- review of fiscal year
- budget surplus
- discussion of building fund reserve, 25% target discussed
- 2015 Goals
- Consensus that we will grow the membership in 2015
- Discussion about using some funds to subsidize training in 2015
- 2014 Summary
Actions