Versions Compared

Key

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

...

  • Quarterly Financial

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

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

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

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

  • Budgeting Forecasting for Next Year 2021-22

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

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

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

      • 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.

  • Broad view of Membership
  • Membership breakdown

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

    • Broad view of Membership

    • Membership breakdown

    • 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.

...

    • 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."
    • Rosy: motivated by concerns about reduction in members and member $$.
      • Revenue ops: looking at value-added initiatives, membership levels, services related to migration. What do our users need and want?
      • if you need receipt language changed to say something to meet your orgs needs, let us know
      • medium-term: looking to understand fedora installations and what data we have and could collection. 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.
      • 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.
        • Emily will join the governance group
    • Small group discussions about what data we want to collect about installations, to help us better understand our membership - report outs:
      • group 1 (forthcoming from David)
      • group 2 (more forthcoming from Andrew) - 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.
        • Rob: institutions should not be allowed to opt out of sharing this info (even though we need to allow individuals to opt out).
        • 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
            • Contact info
            • URL
            • Frontend application
        • On-going reporting
          • Repository size over time
        • Potentially tie-in with Islandora and Samvera
        • Automated? or opt-in? - interest in "opt-in"
          • Hit a button to submit, or not
          • Ability to include user-input data, details that can not be auto-collected
        • Application download stats
          • Also can build from source
        • Skepticism about how it may work and how it may be received
          • Although, not an uncommon pattern
          • Need to provide transparency on when info is being sent
        • Enables support for upgrade and security patch messaging
        • Need clear community messaging
      • 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.
      • This would require development by the team.
      • 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).

...