Attending
Time:12:00PM PDT/03:00PM EDT - 01:00PM PDT/04:00PM EDT
Zoom: https://princeton.zoom.us/j/397525264
Participants
- Trey Pendragon (Princeton University Library)
- Mark Bussey (Data Curation Experts)
- Benjamin Armintor (Columbia University Libraries)
- Noah Botimer (U. Michigan Libraries)
- James Griffin (Princeton University Library)
Agenda
- Planning for Sprint 2
Notes
Waffle Board for Sprint 2
There were repositories missing from the Waffle Board
Moved items from repositories
Drag everything over which is specified in the Sheet
rubydora needs templates
Uncertain why we are supporting rubydora
Who had some interested?
Armintor: Wouldn't mind as deprecated, but team contributes patches; Product Owner is Justin, so Armintor cannot
Pendragon:Next time, contact Justin, see if there are sufficient people to keep it around
Armintor: Stanford might keep it around until SDR3 released
solrizer#45: Seemed like maintenance, deprecation issue "don't use me"
Not dragged over
noid-rails and active_fedora
Test Coverage Sufficient tickets: should we contact product owners or assume that they are sufficient?
Botimer: Supports contacting the product owners
Armintor: Might be best to e-mail the product owner
Opening the ticket sometimes isn't clear to the product owner (or others on the GitHub repository)
Bussey: What is a community standard for what is sufficient?
If we're going to accept this into the community...would there be enough test coverage for others to continue development?
Armintor: This is there in order to ensure that product owners could explicitly request contributions for increasing test coverage
Pendragon: If there are three instititutions who care about it, how do they feel about the current test coverage?
Botimer: Does a single number for a coverage threshold help significantly?
Bussey: Better to increase this to 85% by explicitly requesting this of the product owner; also congratulate them if it is higher
A single number doesn't provide directional influence
Is our general sense that this is good enough in the WG? Or should this be raised?
This might not be set by the developer team or the product owner
How do we ensure that unexpected regressions don't occur
Botimer: WG does not have a specific number...but what is the shape of the question for outstanding questions
Bussey: Unknown...just raises questions on the project
Pendragon: Just close everything which is over 95%
Request: If you feel like it would be useful for the developers to get it to 100%, please make another ticket
Pendragon: For lower than 95%, issue a gentle reminder to the product owner
hydra-pcdm: Build is failing due to Rails 5
Griffin: Needs to confirm this, notes that we will need to return to requesting an active_fedora release
CLA question for hydra-pcdm open pull request
questioning-authority is at 88%, Pendragon will ask about this
hydra-derivatives has 84%
Pendragon: Other maintenance issues?
Botimer: Proposes that VCR replacement be an issue
Setting an updated precedent
Pendragon: Deprecation warnings for solrizer?
Warnings are issued when adopter attempts to use the Gem
When one runs the methods, instantiates the constant, installing it...
Bussey: What would it take to deprecate Hydra?
grant_revoke_gem_authority.rb is still in the repository
Can we find a place to create an issue? See about creating a deprecation proposal?
Armintor: References on the Sheet should be cleaned up
Bussey: Looking at the release history, the need for the project is gone
Supports deprecating this
Pendragon: Steps to move towards deprecation, specifically references the community's preference towards Hyrax
Add this to the agenda for the Samvera Tech. Call on 09/12/18, wait for decision from the community and create tickets in response to that
Pendragon added this as an agenda item
Pendragon: Should there be any other tickets added for the sprint?
Botimer: Would prefer some more technical tickets for this sprint
Armintor: om has some significantly dated issues
What has a dependency on om?
hydra-works
Bussey: This should be prioritized
Pendragon: Pull request #346
Armintor: It might not save us labor to switch to happymapper
Pendragon: Why don't we just use Nokogiri?
Bussey: Agrees that XML using Nokogiri is probably the best approach, does not use OM
Armintor: Does not use OM, better off using XPath
Bussey: It was useful for Fedora 3 Datastreams, never added much if just parsing XML
Armintor: FITS only requires reading the Document
Bussey: Confirms that this is the case, will proceed by contacting Colvard
Pendragon: WG can spike on what is needed to replace OM
Armintor: Try and separate whether or not OM should be deprecated is separate discussion
hydra-works should not depend on OM
Avalon can just use OM without hydra-works using it
Pendragon: happymapper also might not be the optimal solution
All agree that using Nokogiri without happymapper should be explored
Review the Spreadsheet