Page Comparison

...

• LaRita Robinson (Notre Dame)
  
• Julie Allinson (CoSector, University of London)
• Jim Coble (Duke)
• Steve Van Tuyl (oregon state)
• James Griffin (Princeton University Library)
• Michael Klein (Northwestern University Library)
• cam156 (PSU)
• Michael Joseph Giarlo (Stanford)
• Chris Colvard (Deactivated) (Indiana University)
• Lynette Rayle (Cornell)
• Andrew Myers (WGBH)
• Chris Diaz (Northwestern University Library)
• tamsin woo (DCE)
• you! 

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. 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: https://github.com/samvera/hyrax/pull/2655#issuecomment-368589775
   3. Hyrax Analytics (Steve Van Tuyl)
      
      1. Current status
      2. Merge to master
      3. 2.1 release and analytics
         
         1. Is https://github.com/samvera/hyrax/issues/2718 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)
      
      1. https://github.com/samvera/hyrax/issues/2726
         

...

• https://github.com/samvera/hyrax/pull/2655#issuecomment-368589775
• https://github.com/samvera-labs/bixby/issues/23#issuecomment-367458604
• 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 (samvera.github.io)
  • https://github.com/samvera/samvera.github.io/issues/207

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 (https://github.com/samvera/hyrax/issues/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