Page tree
Skip to end of metadata
Go to start of metadata


Time: 10:00am Eastern Time (US)

Please see the calendar invite for the Zoom link.


  1. Melissa Anez
  2. Chris Awre 
  3. Thomas Bernhart
  4. Danny Bernstein 
  5. Robert Cartolano 
  6. Dan Coughlin
  7. Jon Dunn 
  8. Dan Field
  9. Raman Ganguly
  10. Jennifer Gilbert
  11. Mark Jordan
  12. Danny Lamb
  13. Rosalyn Metz 
  14. Este Pope 
  15. Scott Prater
  16. Robin Ruggaber 
  17. Tim Shearer
  18. Andrew Woods 
  19. Dustin Slater 
  20. Jennifer Vinopal 
  21. David Wilcox
  22. Arran Griffith
  23. Maurice York
  24. Laurie Arp 
  25. Robert Miller
  26. Ben Wallberg




Introductions and Welcome to New Members (10 minutes)

Welcomes and introductions to all new and returning members of the 2020 Leadership Group. 


Financial Update (10 minutes)

The detailed Quarterly Financial Report was distributed via email.


  • Negative variances include membership revenue. Note that in the original budget, we estimated that memberships would be down approximately 15% for 2020, however it is closer to a 22% decrease.
  • Positive variances include being slightly under-spent in salaries/benefits and IDC. 

Goal: Review the quarterly financial report and answer any questions.


Fedora 6 - Beta and Production Release Criteria (30 minutes)

Following the November sprint, the team released Fedora 6.0 Alpha-1. We are now seeking institutions to download and test the software and provide feedback.

The focus is now on addressing all issues required for the Beta release. The expectation for the Beta release is that the core software and migration tooling be feature-complete. 

Form for collecting performance and scale expectations.

Goal: Agree on a set of criteria for both Beta and Production release.


IMLS Fedora Migration Grant Progress (10 minutes)

$249,859 over 18 months (September 2020 - February 2022)

This grant (lg-246264-ols-20) is focused on developing, piloting, and documenting migration tools and paths for upgrading Fedora 3 repositories to Fedora 6. Fedora staff and the grant partners have been working hard on this project and will share their most recent updates.

Goal: Review current grant work progress.


Membership Model Proposal (30 minutes)

With the current state of membership renewals, it has been proposed that changes need to be made to the current membership model to ensure recurring income. Through extensive discussion, 3 proposals were generated to assist with short, medium, and long-term actions. We will break into smaller groups to discuss the recommendations with the goal of approving short-term actions and refining the proposed medium-term actions.

Goal: Approve short-term actions to take for the upcoming membership renewal year and refine proposed medium-term actions.


Strategy Sub-Group Reports (15 minutes)

Product Technology

Communication, Outreach, Marketing & Community

Governance & Business Model




Wrap-up (Remaining time)David

Previous Action Items


Financial Update

  1. Quarterly Financial

    1. membership is a little lower, budgeted 15% but are at 22%

    2. Grant started in Sept 1, and that makes up a bit for the lower membership

    3. This isn't unexpected, we are planning to be spending a bit more than taking in throughout the year

    4. There are less than 10K of outstanding membership fees that we are awaiting, a vast majority have come in already

  2. Budgeting Forecasting for Next Year 2021-22

    1. We are working with universities on timing, if that is helpful to send it early or late in the year

    2. Discussions has begun on what do we need to do to absorb anticipated losses

      1. as a leadership group only dipped into a portion of the reserves, in the hope of getting the grant that would cover up for losses as well.



    1. Started planning for this prior to COVID because there were concerns on the existing membership model for the last 12-18 months

    2. Broad view of Membership

    3. Membership breakdown

    4. Most folks that cancelled did so because of budget issues related to COVID, there are some technical issues, but the vast majority are budget cuts related to COVID.

Fedora 6

  1. Continuing to make progress towards Fedora 6

    1. first alpha release is out, not feature complete, but very close

      1. any features missing are likely not used features

      2. please pull it down and test

      3. next version of alpha will be out next week

    2. what is the criteria for putting out beta release

      1. proposed

        1. feature complete

        2. migration tooling (3, 4, 5 -> 6)

        3. validation tool

          1. initially this will only exist for Fedora 3 and development will begin next week

          2. If we need further validation tooling, we can create it, but based on surveys this didn't seem to be necessary (migration tooling for Fedora 4, 5)

        4. documented expectations performance/scale criteria

          1. rates for migration (size of content should migrate in ___ time)

          2. collections of ____ size should get a response time of _____

          3. need collaboration to get people to run these tests and create the expectations for these tests

        5. documentation complete

      2. Jira items


        2. All priority flagged red are prioritized for beta,

        3. All priority flagged blue are prioritized for production

    3. what is the criteria for putting out 6.0 production release

      1. proposed

        1. Stakeholder sign-off

        2. Migration tooling - stakeholder sign-off

        3. Validation tool stakeholder sign-off

        4. Validation of integration -

          1. samvera

          2. islandora

        5. F6 documentation complete

        6. Performance/Scale results documented

      2. Discussion on configuration of F6

        1. new version created with any change to the file, version is created automatically

        2. new version created only when it's told to create a new version by the application sitting on top of it

          1. If this is the configuration there is an outstanding pull request to define this extended functionality within the context of OCFL


            2. We could use a review and feedback on this pull request, please encourage team to look at this.

            3. Not positive on the level of desire of this feature and what makes the most sense. We need feedback on this to understand the level of interest to the priority.

            4. We need comments and feedback on the extension and pull requests and a particular focus on the technical details on this PR

    4. Four Actions coming out of this:

      1. Review and provide feedback and signing off on criteria for the beta release

      2. Review and provide feedback and signing off on criteria for the production release

      3. Look at google doc linked in the agenda and put in expectations for performance and scale

        1. Existing performance tests and results:

      4. Providing feedback on the mutable head pull request:

IMLS Fedora migration grant

  1. David: good progress. Starting migration tooling next week with sample data. Full production set up next year. Noting dependency on Fedora 6 development - delays in Fedora 6 might affect meeting grant deadline. We can continue working on other grant-related things while we wait for Fedora 6 dev to advance.

Membership Model Proposal

  1. summary "With the current state of membership renewals, it has been proposed that changes need to be made to the current membership model to ensure recurring income. Through extensive discussion, 3 proposals were generated to assist with short, medium, and long-term actions. We will break into smaller groups to discuss the recommendations with the goal of approving short-term actions and refining the proposed medium-term actions."
  2. Rosy: motivated by concerns about reduction in members and member $$.
    1. Revenue ops: looking at value-added initiatives, membership levels, services related to migration. What do our users need and want?
    2. if you need receipt language changed to say something to meet your orgs needs, let us know
    3. medium-term: looking to understand fedora installations and what data we have and could collect. Who is using fedora? Where are they? Can we collect this data in a more automated way? This data will help us better understand what users need/want and what we might charge for.
    4. Data will be handed off to Governance group - please join us in that group to help with this work. Rosy will send an email reminder.
      1. Emily will join the governance group
  3. Small group discussions about what data we want to collect about installations, to help us better understand our membership - report outs:
    1. group 1 (forthcoming from David)
      1. Transparency

        1. Need to know the data Fedora is sending

        2. Maybe a reward for sending the data

        3. Needs to be opt-in, maybe at the point of installation

      2. Here is the data we want to collect, select which data you want to send

        1. Might need a form to collect data - what can be collected auto vs. manual

        2. Real-time data - can we collect automated stats?

        3. Technical data - software version information

          1. Only collect what we need - don’t need to profile the entire system

        4. Front-end - Islandora/Samvera, etc.

          1. This is a shared problem - maybe the communities can coordinate

      3. Are there other examples of server-side OSS that does this?

        1. Drupal may do some of this reporting

        2. GraphDB triplestore product does this as part of the registration process

      4. How to incentivize

      5. Get on a list for security fixes

      6. Might be a good way to get contact information

      7. Dashboard with statistics

    2. group 2 - is a way to communicate to the community, update them about updates/bugs. Need to make it opt-out, have it be part of installer process. Need to explain to the community this change ahead of time. SHould be an ongoing process (not just at installation) - could continue to collect ongoing info about their installations.
      1. Rob: institutions should not be allowed to opt out of sharing this info (even though we need to allow individuals to opt out).
      2. Types of data to potentially collect
        1. Nature of installation - test, production
        2. Fedora version
        3. Geo location
        4. Fedora and system config
        5. Institution name
          1. Contact info
          2. URL
          3. Frontend application
      3. On-going reporting
        1. Repository size over time
      4. Potentially tie-in with Islandora and Samvera
      5. Automated? or opt-in? - interest in "opt-in"
        1. Hit a button to submit, or not
        2. Ability to include user-input data, details that can not be auto-collected
      6. Application download stats
        1. Also can build from source
      7. Skepticism about how it may work and how it may be received
        1. Although, not an uncommon pattern
        2. Need to provide transparency on when info is being sent
      8. Enables support for upgrade and security patch messaging
      9. Need clear community messaging
    3. group 3 (more forthcoming from Rosy) - mandatory: institution name and institutional email address; Opt-in: financial and technical contact. Need language to say why we're collecting this info. Also should collect ongoing data, including number of objects in the repo when updates are applied. Not sure how this would be received by the community and also discussion about technical feasibility. Big discussion about GDPR and how we would remove personal contact info when needed.
    4. This would require development by the team.
    5. Is ArchiveSpace a model for us: low-cost way to become member ($300?). Could be a good way to expand the membership base, total number of participants. Should link with releast of Fedora 6 (a kick-the-tires membership approach).

Last topic, Reports, ran out of time - David will follow up via email

Action Items