Attending

Time:12:00PM PDT/03:00PM EDT - 01:00PM PDT/04:00PM EDT

Zoom: https://princeton.zoom.us/j/281265700

Participants

• Trey Pendragon (Princeton University Library)
• Mark Bussey (Data Curation Experts)
• Noah Botimer (U. Michigan)
• James Griffin (Princeton University Library)

Agenda

• Check out the GitHub Board Review Column
  • Consider updating LICENSE to Apache2 #227
    • DONE
  • Deprecate Solrizer #19
    • Is it worth putting out a final call for Solrizer deprecation before next Wednesday's Samvera Tech call, or just let it quietly fade away?
      Only 1 response to the e-mail thread giving a qualified thumbs up.
• Sprint in a little over a week

Notes

browse-everything

• https://github.com/samvera/browse-everything/pull/289 was merged

Active Fedora

• Release 12.2.0
  • There was some discussion, James felt like there were some concerns with Hyrax compatibility
  • James will request that Chris Colvard review this

Solrizer

• Deprecation notice was sent to the community
• Should Mark send out a reminder next week?
• The initial e-Mail went out, and Jim Coble alone responded (they felt that it was fine to deprecate the Gem)
• Trey:
• It's probably best to still send out another reminder
• Mark: Will plan to send a reminder on Tuesday, and will offer an agenda item for the Tech. Call on Wednesday

Next Sprint

• Bess and Mark are looking to contribute to up to 0.5 FTE each
• Noah will see if they are available, but would like to participate
• Tom is continuing Hyrax-on-Wings work during that week, but does intend to run on both sprints
• Our board is very empty
• If Product Owners don't fill the board, we can address this in a few ways:
  • We can populate the board ourselves
  • We can cancel the sprint
  • We can address what issues there are and take less than one week
• Mark
  • Advocates for continuing with what issues we identify even if the sprint consumes less than one week
  • Test coverage sufficiency seems to be an open question regarding community standardization
    • What does that mean for the community moving forward?
•  Trey:
  • Product Owners aren't necessarily responsible for ensuring that the code coverage is high enough for a component

• Noah:
  • Agrees with holding the sprint, should we always wait for the Product Owners to identify issues?
• Trey:
  • Product Owners will or will not add the issues, but we may end the sprint early if we close all of the issues on the board in less than one week
• Mark:
  • At last Partners' Meeting, ensuring that components adhere to the latest Rails and Ruby releases was quite well received
    • Even if this work does not consume the entire sprint, that's still sufficient
    • This should still be used to indicate where the community might need to add more effort for maintenance
• Trey:
  • Are there Ruby releases coming up which we should be ready for?  Rails 6 is still in beta, but will there be a stable release soon?
    • Created maintenance/issues/20

Discussing Test Coverage

• What do others consider "good enough coverage"?
  • Trey: Without 100%, continuous integration becomes difficult if coverage falls below a certain non-100% threshold
  • Some years ago, this point was discussed in the community
    • The sense was that most were confident enough in the code bases without needing consisent, 100% coverage
  • Also, many want to ensure that the test suite does not consume too much time
    • Ideally, we can have both good coverage with fast test suites
  • Even with 90% was the goal, there are many at or above this threshold
• questioning_authority was failing on master
  • After further inspection, an issue was created in response to this
    • Noah: These failures might be related to some live calls to a WorldCat service endpoint

Deprecation of om

• What is the status of this?  Was there any opposition to it being deprecated?
  • GitHub repository has not yet been moved out of Samvera Organization
• We will review this during the sprint

Sprint Planning and Next Meetings

• Trey will not be available meet at 15:00EDT on 07/26
• Mark: It would be best for DCE to address planning on the Monday of the week of the sprint
  • We will not meet next week
• Will 12:00PDT/15:00PM EDT as a daily standup/check-in time work for everyone for the week of the sprint?
  • All agreed with this proposal
  • All plan to meet Monday 07/29 to address sprint planning at 12:00PDT/15:00EDT
• We will be using the same Zoom URL (https://princeton.zoom.us/j/281265700) for the standup

Meeting adjourned at 12:30 PDT/15:30 EDT