This wiki space is archived.

The active wiki for the Samvera Community can be found here:

Child pages
  • Samvera Tech Call 2018-02-28

This wiki space is archived. The active wiki for the Samvera Community can be found here:

Skip to end of metadata
Go to start of metadata

How to connect: (link will launch Zoom client – if you do not have Zoom, expand the instructions below)


Meeting ID: 613 720 745

+1 646 876 9923 (US Toll)
+1 669 900 6833 (US Toll)
+1 408 638 0968 (US Toll)
International numbers available:


Meeting ID: 613 720 745 (US West) (US East) (China) (India) (EMEA) (Australia) (Hong Kong) (Brazil) (Canada)


Time: 9:00am PDT / Noon EDT

Moderator: Jennifer Lindner (DCE)

Notetaker: James R. Griffin III



    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. Welcome all newcomers!
    2. Agenda (moderator)
      1. Call for new agenda items (moderator)
      2. Error handling: Always raise from lower levels in the stack, like services? Log and re-raise? Catch StandardError or require more specific errors? What might a best practice be in this topic? see:
      3. Hyrax Analytics (steve van tuyl)
        1. Current status
        2. Merge to master
        3. 2.1 release and analytics
          1. Is a blocker for 2.1.0? (Conor)
        4. More hands on deck?
      4. Hyrax 2.1 beta Testing (Chris Diaz)
        1. QA Testers had a brief meeting on Monday to discuss the testing procedures (link to shared google sheets)
        2. NURAX is currently on 2.1.0 Beta
        3. Testing is expected to begin this afternoon and continue into next week
        4. There are 13 open issues on the 2.1 milestone – any help you can provide is greatly appreciated!  (sign up or just grab an issue)
      5. Parent collection list format (LaRita Robinson)

2.1 milestone

  1. Notetaker and moderator for next time
    1. Notes:
    2. Moderate:
  2. After call, this week's notetaker should create the agenda for the next call.
  3. If desired, stay after the call to assist in grooming PR backlog


Agenda Items

Error Handling

  • Related to Rubocop
  • Discussion for the best way to handle errors
  • Do we log? Do we raise exceptions?
  • Prefer to catch StandardError
  • Establish best practices for moving forward
  • Raising from lower in the stack: Services might not have an interface directly exposed to users
  • Catch and handle these closer to the user interface logic
  • Summary of positions on the issue:
  • Started with a Rubocop PR
    • Johnson and Jonathan Rochkind discussed this
    • Whether or not to catch errors at all became a point of dispute
    • Coyne: Avoid raising a StandardError if possible
    • Not clear which error was expected by the author of the code
    • Prefer to have people specify which errors they are expecting...
    • Cole: Capturing StandardError down in the stack can hide more specific errors
    • Lindner: In defense of StandardError (they don't have a strong position on this issue) ensures that the App doesn't blow up entirely
    • Johnson: There is an older Rubocop rule felt that rescuing StandardError (or rescue without a specified Class) wasn't acceptable
      • Rule is gone - now, instead of enforcing that you never rescue StandardError, you now must explicitly specify that you want to rescue StandardError
      • *This is now the state of Bixby*
      • That seems find (to Johnson)
      • #266 where Coyne was trying to remove the handling...
      • Johnson prefers to leave the logging in place
    • Cole: Is there a test for this where the exception isn't raised
    • Headley: Johnson's proposal is a good one, catch any error and pass it along again
    • Coyne: Should be a community practice - write a comment outlining why you are using StandardError
    • Rayle: It would be wise to have this added to the best community practices documentation (

Hyrax Analytics

  • Van Tuyl
  • Most of the work on the background for integrating support for Google Analytics or Motomo
  • Questions which have arisen
  • Many discussions around not having lengthy feature branches
  • Analytics is now on a feature branch...and the WG is looking to move this off of the branch
  • Perhaps discuss this process with the Collection Extensions WG
  • #2718 (
    • Should this be a blocker for release 2.1?
    • O'Malley identifies this as affecting the master branch
    • URL's are now nested, creating problems for analytics
      • NestedWorks leads to problems
    • Rayle: Will inspect in order to determine it came in with Collection Extensions contributions, but suspects that it's related to NestedWorks
    • Should verify that it is in 2.0 before determining whether or not it is a blocker
    • Van Tuyl can help coordinate determining when it was actually broken
    • If this is finished by next Wednesday, then better context will provide the community with the ability to determine if this is blocking a release
    • Also, should aim to document precisely how to avoid generating difficult, nested URL's from the app. routing
      • Release QA testing should encompass testing this for future releases
    • Diaz: There is not currently extensive testing around analytics
  • Walker
    • Crossroads with deciding to create new tables which model the new reports, or extend the old tables
      • Old analytics tables are one table per stat
      • Perhaps consolidate this more efficiently?
      • Use flipflop to provide backward compatibility and ease of upgrade
    • Coyne
      • Has also wanted to consolidate these tables, but there was concern over migration pain
    • (No objections were raised to this consolidation proposal)

Hyrax 2.1 Beta Testing

  • Testing is going to begin today
  • There is an invitation for contributors to ensure that remaining issues can be resolved
  • Rayle invites all interested to contact them for easier issues (if they are less experienced with the codebase)

Parent Collections

  • Massive duplication in pagination logic for parent collections
  • Calling attention to this in response to these concerns
  • Giarlo:
    • Perhaps before and after screenshots
    • UI/UX designer feedback can be solicited
  • Rayle:
    • Agreeds, have someone propose a refactor
    • Perhaps 2.1.1 timeframe would provide enough time to reduce the clutter on the interface design
    • Also may apply to Work nesting
  • LaRita is invited to offer a WIP pull request in response to these
    • Want to avoid feature specs (consuming too much time)
    • Perhaps View tests?
    • LaRita invites more feedback over Slack

Moderator: Van Tuyl

Notetaker: Griffin

  • No labels