Versions Compared

Old Version 19

changes.mady.by.user David Wilcox

Saved on

compared with

New Version Current

changes.mady.by.user Arran Griffith

Saved on

Key

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

...

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