Samvera Tech Call 2018-02-28
How to connect: https://psu.zoom.us/j/613720745 (link will launch Zoom client – if you do not have Zoom, expand the instructions below)
Time: 9:00am PDT / Noon EDT
Moderator: @Jennifer Lindner (DCE)
Notetaker: @James Griffin
Attendees:
@LaRita Robinson (Notre Dame)
@Julie Allinson (CoSector, University of London)
@Jim Coble (Duke)
@Steve Van Tuyl (oregon state)
@James Griffin (Princeton University Library)
@Michael B. 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)
@Nestor Walker (UVA)
@Trey Pendragon (Princeton)
you!
Agenda
Roll call by timezone per following order - ensure notetaker is present (moderator)
folks outside North and South America
Eastern timezone
Central timezone
Mountain timezone
Pacific timezone
folks who were missed or who dialed in during roll call
Welcome all newcomers!
Agenda (moderator)
Call for new agenda items (moderator)
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
Hyrax Analytics (@Steve Van Tuyl)
Current status
Merge to master
2.1 release and analytics
Is https://github.com/samvera/hyrax/issues/2718 a blocker for 2.1.0? (Conor)
More hands on deck?
Hyrax 2.1 beta Testing (@Chris Diaz)
QA Testers had a brief meeting on Monday to discuss the testing procedures (link to shared google sheets)
NURAX is currently on 2.1.0 Beta
Testing is expected to begin this afternoon and continue into next week
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)
Parent collection list format (@LaRita Robinson)
Notetaker and moderator for next time
Notes:
Moderate:
After call, this week's notetaker should create the agenda for the next call.
If desired, stay after the call to assist in grooming PR backlog
Notes
Agenda Items
Error Handling
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)
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
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