...

1. 2015 Targets
   

   1. Migration - next six months

      1. Andrew

      2. 1. 4.0 release greenfield

         2. 4.1 release - targeted for OR - get Fedora 3 to Fedora 4

      3. Migration Discussion

         1. 4.1

            1.  squash bugs

            2.  new features

         2. Migration

            1.  Establish pilots

               1. which features need to be migrated

               2. get many Fedora 3 institutions involved

                  1. documentation needs

                  2. tooling needs

            2. approach - in terms of objects

               1. use a connector, helps eliminates concerns

               2. connector talks to Fedora 3 REST API

               3. regardless of some configuration variables

               4. will simplify the transfer of assets

            3. need for parallel systems

               1. will need servers and storage

               2. can't do an in-place upgrade

               3. it's a content migration

               4. it's a software upgrade

            4. What do we tell people who want to stay with XML vs. RDF?

               1. You can't keep all forms of XML, like inline XML

               2. Fedora 3 audit trail, can become XML data stream, but not inline

         3. Break out Fedora 3 features

            1. do some early analysis, what is going to be possible

               1.  requirements for Fedora 3 to Fedora 4

               2. in training, documented considerations for upgrades

                  1. security policies

                  2. versioning

                  3. disseminators

               3. how data and functionality map from 3 to 4

   2. Migration Scenarios

      1. Greenfield installation

         1. upgrade to Fedora 4 and replace functionality over time

      2. Hydra

         1. could have made Fedora 4 look like Fedora 3

         2. strategic decision to move to Fedora 4 approach

            1. continuum of migration options

               1. consensus - quick analysis to determine migration needs

               2. find common needs

      3. migration working group - consensus

      4. Migration Complexity

         1. consensus it will take time to determine scope

            1. Systems Administrators

            2. Application Functionality, Compatibility, Refactoring

            3. Content Migration

         2. Hydra and Islandora - will be easiest community to migrate

            1. Penn State - looking at using Hydra as migration tool

      5. What is possible in the next 6 months?

         1. Moving Content to a new system

            1. can play with content, even if you haven't moved to a new system

               1. Have pilots

                  1. working through migration

                  2. specific features and capabilities

                  3. content

            2. After 6 months

               1. have a few examples of sucessful migration

               2. Documentation

   3. Identify Migration Types

      1. Greenfield

      2. Hydra/Islandora

      3. Custom

         1. Wild West

         2. Rebuild/Refactor - rewrite and ingest

         3. New functionality - incorporate back into Fedora/Hydra

   4. Promote the concept of community development when appropriate, recognize and respect the need for institutions to locally customize when required.

   5. What if there are significant issues related to Fedora 3 migration?

      1. at some point the community will have difficulty in supporting

      2. Fedora 3 beyond security patches

   6. Migration consultancy - At OR2015, have a room for migration support

   7. "Upgration" - Software Upgrade and Content Migration - a new term

   8. ACTION ITEMS

      1. Survey

         1.  collect information, quickly canvas the community

         2. identify use cases, common services and approaches

         3. keep as simple as reasonably possible

         4. some demographic data

            1. geography, size of installation

            2. intended for leadership group

         5. ship out after Monday January 12th

         6. get responses back by February 1, 2015 (??? to be finalized by David and Andrew)

      2. 2. Establish Migration Working Group

         1. Code4Lib - awareness booth

         2. OR2015   - upgration booth

2. Fedora 4.1 Release

   1. Fedora 3 to 4 migrations
   2. Bug fixes
   3. Features
      1. Which priorities (established last year) are still relevant?
         1. What will be the process for prioritizing feature development?
         2. Engage the community
         3. Technical use cases - need to have some tie to Fedora 4 development
         4. Connect to leadership and strategic priorities
      2. Some evolution in software development
         1. rotating group of developers
         2. need to balance priority needs with developer resources
         3. Discussion setting priorities
      3. New Candidate features/discussion
         
         1. Migration - Rob/Columbia
         2. Remote/Asynchronous storage -  discussion and consensus, Jon/Indiana & WGBH funded project
         3. Hydra/Islandora Content Modeling - Declan/UCSD - community engagement, reach consensus
         4. Hydra development coordinated with specific Fedora 4.x feature development - Tom/Stanford
         5. LDP-Paging
         6. Audit service
         7. API partitioning
         8. Web Access Control
      4. How to support feature development from staffing/leadership perspective
   4. Fedora 3 to 4 migrations
   5. Bug fixes
   6. ACTION ITEMS
      
      1. Product Manager
         
         1. will engage community and leadership to prioritize features
         2. consensus will come with commitment for effort
         3. gather additional resources from community
         4. Educate managers and decision makers to bring on board potential developers
         5. Continue to grow and expand mailing list
3. Hydra & Islandora Development Impact toward Fedora 4 Feature Development - discussed earlier

4. Development Resources (current commitments)

   1. Background

      1. No committer model (just contributors)

      2. Lack of continuous engagement from developers

      3. Challenges establishing a developer community

   2.  Discussion

      1. Dollars not available today additional developer resources

         1. Link to institutional context is important

         2. Short-term efforts could address specific problems

      2. Opportunistic developer resources

         1. align development to solve local needs and community needs

         2. grant-funded initiatives

      3. Cultivating new developers and contributors when possible

      4. Adapting to the institutional development cycles

         1.  2-week sprints

         2. Migration to Jira to engage developers for bug fixes

      5. Training and documentation

      6. Define profile of Fedora contributor - Andrew

         1. profile for managers and leaders
         2. Possible multiple contributor (developer, debugger)
5. Community Development & Cohesion
   1. Cohesion
   2. Development
      1. Training to raise Fedora awareness to both developers and leaders
      2. Discussion about separate events as well as events tied to existing conferences
6. Training Strategies
   1. In Person (proposal)
      1. 3-day training pilot is effective - consensus that we will create a 3-day training
      2. Regional meetings
         1. DC meetings coupled with training effective
         2. New England, UK, Wolfram proposed Germany/Europe
      3. Co-location training opportunities (devs and managers)
   2. Other training discussion
      1. get managers on board - DLF, OR, CNI
      2. Review Conferences for potential dates
      3. 1-day training opportunities in 2015
   3. ACTION ITEM
      1. Leadership voted to spend up to $10,000 for developing 3-day training curriculum
         1. Tim to reach out to potential person who could develop training
         2. David Wilcox will coordinate next steps
      2. Leadership voted to develop curriculum using CC-0 licensing
         1. sense that little market potential for training materials
         2. we want to encourage the dissemination and training for Fedora 4
         3. we don't want to restrict the re-use of training materials
      3. Robin will send follow-up note to Fedora Leaders to allow non-attendees to provide feedback
7. Communications strategy
   1. Conference attendance
      1. Near-term scheduling
         
         1. DuraSpace Summit
         2. RDA
         3. PA-SIG
      2. Fedora Leaders should indicate conference attendance - Robin will send out note to all Leaders
      3. In-person meetings - try to meet about every six months
         
         1. OR 2015 conference - Indianapolis
         2. December CNI
      4. David and Matias leading user group track, get out more announcement for call for proposals for OR2015
   2. Outreach
      1. webinars
         1. successful beta pilots - 30 to 40 people attended
         2. working group webinars
            1. migration, content modeling, hydra, Islandora,
8. Finance
   1. 2014 Summary
      1. review of fiscal year
      2. budget surplus
      3. discussion of building fund reserve, 25% target discussed
   2. 2015 Goals
      1. Consensus that we will grow the membership in 2015
      2. Discussion about using some funds to subsidize training in 2015

Actions