Time/Place

This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:

• Time: 11:00am Eastern Daylight Time US (UTC-4)
• Audio/Video Conference Link:   https://lyrasis.zoom.us/j/88068382811
  
  • Meeting ID: 880 6838 2811
  • Find your local number: https://lyrasis.zoom.us/u/ad6Xb7q3ia

  • Join fedora-project.slack.com on the "tech" channel

  • Self-register at: http://slack.fcrepo.org/

Attendees 

1. Danny Bernstein  
2. Arran Griffith  
3. Jared Whiklo  
4. Peter Winckles 
5. Ben Pennell 
6. Calvin Xu 
7. Michael Ritter 
8. Demian Katz  
9. Thomas Bernhart
10. Robin Lindley Ruggaber  
11. Jennifer Gilbert 
12. Timothy Shearer 

Agenda

1. Announcements
2. Leaders and Committers On How to Encourage Fedora Users to Register
   1. Why the registry is important
   2. The state of the registry now
   3. What can we do?
      1. In the UI
      2. on the Command line
      3.  On our ecosystem projects (camel toolbox, migration utils, etc)
         1. Islandora
         2. Samvera
3. NLM Migration Update
   
   1. New Tickets
      1. 
      2. 
4. 6.2.0 Release
   1. PRs that need to be resolved
5. Jira, Slack, Github integrations

Notes:

• All of Leaders and Steering was invited.
• Governance wants to take action on enhancing our registry.
• We can't legally reach out to registered users due to GDPR concerns.
• We need a better understanding of our installed base.

Without an accurate registry we can't make the case for Fedora:

• we can say who is using it
• we can't say how many people are using
• we can say where in the world it is deployed
• we're missing use cases
• we're missing diverse voices
• which is to say we're missing the critical feedback loop to grow the community

At stake in how we can connect users to the registry:

1. theres's law
   1. privacy issues
2. there's community perception

How would we get information about Fedora's that are part of a prefab tech stack?

• Samvera
• Islandora

To bring the tech team to this problem is vital.

We have an existential threat to our project because we don't know have data: we are not creating spyware, we are trying to help our community.

From Jakov:

OJS has a beacon feature which we might consider replicating in Fedora

• Has an opt out - perhaps we should consider opt in
• generate unique id
• send information to Fedora
  • What information:
    • Fedora Version
    • IP
    • Institution
    • Country
    • Contact Email
    • Periodically send stats (object count, byte count)

Provide ability to offer different levels of information 

Possibly remind folks when they upgrade the software?

What data does not present risk?  

Scott's Notes:

Many Fedora 3's have been inherited from the original implementers by IT groups, digital archivists and  collections managers who may not be plugged into the community via email lists, etc.

• So I'd recommend an outreach effort that focused on publicizing Fedora 6 and migration help outside the usual channels
  • posting to forums like code4lib, the dspace forum (many institutions that run DSpace also run Fedora), NDSA lists, PASIG lists, Samvera, Islandora, etc

• Digital curation listserv as well