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
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.
- 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?
- Consider updating LICENSE to Apache2 #227
- Sprint in a little over a week
Notes
browse-everything#227 was merged
Active Fedora release 12.2.0
There was some discussion, James felt like there were some concerns with Hyrax compatibility
James will ping Colvard
Solrizer
Send out reminder next week?
E-Mail went out, and Jim Coble alone responded, felt that it was fine to deprecate the Gem
Trey:
It's probably best to still send out another reminder
Mark: 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
Tom is continuing Valkyrax 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:
Test coverage sufficiency seems to be an open question
What does that mean for the community moving forward?
If we got through the issues and it did not consume the entire week, that might be acceptable
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 them early
Mark:
At last Partners' Meeting, ensuring that components adhere to the latest Rails and Ruby releases was quite well received
If this does not consume the entire sprint, that's still sufficient
Should still be used to indicate where the community might need to add more effort
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
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
The sense was that most were confident enough in the code bases
Also, 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: This might be related to some live calls to WorldCat
Deprecation of om
Not moved out of samvera Organization yet
We will review this
We will not meet next week
Mark: It would be best for DCE to address planning on the Monday of the week
Will 12:00PDT/15:00PM EDT work for everyone for the the week of the sprint?
All agreed, meet Monday 07/29 to address sprint planning
We will be using the same Zoom Channel
Meeting adjourned at 12:30 PDT/15:30 EDT