Samvera Tech Call 2020-07-22

How to connect: https://notredame.zoom.us/j/94030214208 (link will launch Zoom client – if you do not have Zoom, expand the instructions below)

Time: 9:00am PDT / Noon EDT

Moderator: @tamsin woo(UC Santa Barbara)

Notetaker: @James Griffin(Princeton University Library)

Attendees:

• @Jeremy Friesen (University of Notre Dame)

• @Collin Brittle (Emory University)

• @Lynette Rayle (Cornell University)

• @Chris Colvard (Deactivated) (Ubiquity Press)

Agenda

1. Roll call by timezone per following order - ensure notetaker is present (moderator)

   1. folks outside North and South America

   2. Eastern timezone

   3. Central timezone

   4. Mountain timezone

   5. Pacific timezone

   6. folks who were missed or who dialed in during roll call

   7. Remind everyone to sign in on agenda.

   8. Welcome all newcomers!

2. Agenda (moderator)

   1. Call for new agenda items (moderator)

   2. Hyrax Telemetry? (@tamsin woo )

   3. Hyrax 3.0.0.rc2 release notes (@Jeremy Friesen)

      1. I have a pass for adding all of the PRs and fixed issues since https://github.com/samvera/hyrax/releases/tag/v3.0.0-rc1

      2. I need guidance on what the tag should be (so I can upload the release notes, which have some todo items for review)

   4. <add open agenda items here>

   5. Samvera help follow-up

   6. Pull request review

      1. PR/4463 - allow for extensions of valkyrie indexer's to_solr that depends on resource custom metadata (Lynette)

3. Moderator & notetaker for next time

   1. Moderator:

   2. Notetaker:

4. After call, this week's notetaker should create the agenda for the next call:

   1. Open template agenda titled "Samvera Tech Call 2020-xx-xx"

   2. Click on ... in the top right corner, and select copy.

   3. Popup will open for location. It should contain: 

      1. Space: Samvera

      2. Parent page: 2020

   4. Select copy. New page should be created.

   5. Modify the title to remove "copy of", update it with the next date, add moderator, notetaker, and any carry-over agenda info. Click Publish.

5. PR Review

   1. Review issues:

   2. PR review coordinator for next time: 

Notes

• Hyrax Telemetry

  • How we can gather real data for how our Gems are used?

  • Problem is that we have a lot of community-maintained tooling

    • Any maintainer has one or two sources of data for how the data is used

    • There hundreds of installs in production

      • Many different versions are used

      • Also, we are not tracking performance issues

  • Open Telemetry

    • We maintain an endpoint, and analytical tools for maintaining that endpoint

    • Instrument the Hyrax code with calls to that endpoint for collecting that data

    • ActiveSupport Notifications support instrumentation in Rails

      • Registering listeners on the fly

      • There is also some capacity for capturing data

  • If this went into the code base, would anyone turn this on? Might there be concerns regarding what kind of data is collected?

    • 2012/2013 Notre Dame Partner Meeting

      • This was discussed, and there was some Partner pushback

      • Some of this related to privacy, and also for exposing vulnerabilities

    • There may need to be some Partner discussions before this can be adopted

    • When publishing Gem sets on the Wiki, the telemetry data must be anonymized enough in order to ensure that institutions are not exposing that they have Samvera repositories with outdated Gems in production

  • Need to obfuscate data detailing the content itself also (e. g. the title of a work should not be captured, particularly if the work is access-restricted)

  • We should be interested in submission rates, the numbers of objects which exist in instances, whether or not a feature flipper is turned on, workflow configurations...

  • This sounds like a proposal document which we should be looking to share with the community

  • Ubiquity Press is generally favorable to telemetry if the data is anonymized enough and free of proprietary information

  • Need to have a one page proposal detailing this policy

    • This needs to be the first step before any code is offered

    • How appropriate would a Working Group be?

    • It is appropriate, particularly given that it ensures visibility amongst the Partners

    • Tom will raise it to the Core Components WG

      • Is this a Hyrax policy? A Samvera Community policy?

    • Tom will request for participation with a co-chair and look to charter the Working Group

• Hyrax 3.0.0.rc2

  • Jeremy looked for the latest tag, and found the commit and queried against GitHub

  • Proceeded to map the pull requests to either /dev/null or the different topics in rc1

  • Document consisting of todo items which we want to verify

    • This identifies potential deprecations

    • Should Jeremy tag the 3.0.0.rc2 next?

      • This will ensure that there will be a tag from which to query as discussions emerge

    • Agree with tagging rc2 next

    • The release notes are not yet online

      • Tom proposes that these notes be posted to https://github.com/samvera/hyrax/releases/tag/untagged-9d1c45b88984ac0834b0

  • Jeremy will work off of this commit and proceed with tagging this release

  • Question: draft release notes are only visible to those with certain privileges on the repository

    • If someone is wanting to look at it who does not have the necessary access privileges, they are not visible

    • How do we render these as publicly visible, but mark them as a work-in-progress?

      • We do have an rc1 tag as well, Jeremy can copy the 3.0.0rc1 release notes and publish them for the rc2 release notes

    • Prereleases and drafts can both exist on GitHub publicly

      • We just need to ensure that it clearly marked as a prerelease and publish it publicly on GitHub

      • The commit hash is not actually what is going to be released if this is the approach taken

        • This should still be handled by GitHub, the releases don't have fixed links

    • Normal workflow: Tom submits a PR, that gets merged, and then somebody `rake release`, and then the release notes are published manually in the browser

    • Jeremy will submit a PR and publish the draft release notes

• IIIF Manifest Generation for Hyrax

  • Chris has been backporting work to 2.x releases

    • Should there be another 2.x release?

    • Tom: IIIF Manifest order is still broken

• Next Scheduled Call

  • Moderator: @Jeremy Friesen

  • Notetaker: @James Griffin

Pull Request Review

• https://github.com/samvera/hyrax/pull/4463 by Lynette

  • Introduces improvements to the shared specs for Valkyrie

    • If you add anything to `to_solr`, then the shared specs will fail

    • The way that the shared specs are processed, `let` calls can be overridden outside of the scope of the shared specs

  • Custom metadata is introduced into the test suite for modeling cases where Hyrax adopters who index custom metadata fields using the Solr indexer

  • One can pass in a custom indexer without a problem, and then the metadata is pulled from a fixed Resource, rather than one set by the user

  • Should introduce the `thumbnail_id` handling for `nil` values in a different pull request

    • This blocks the tests from passing

    • Lynette could not find why `thumbnail_id` was created with a blank string for the test

    • One should also be able to simply invoke `thumbnail_id.present?`

      • If not, that is a Valkyrie bug

  • `let(:resource)` needed to be added in order to ensure that these shared specs are not breaking for Hyrax adopters with customized applications

  • For anybody using this test suite as written, it is currently broken

  • Prefer not to parameterize the test suites

    • Want to avoid replication with `let` calls

  • If I pass in a `Resource` to the shared spec, the shared spec shouldn't know the permissions on the `Resource`

    • Hence, the permissions are set within the scope of the shared spec

  • `VisibilityWriter` needs to be removed, this was just copied from a factory

  • Each Indexer is tied to a specific type of Resource

    • Perhaps they shouldn't be

    • If something more generic without requiring Indexer customization were introduced, then `to_solr` would include many `#try` calls

• Call concluded at 09:58 PDT/12:58 EDT