2022-12-06 Discovery Integration Subgroup Meeting notes

Uwe Reh proposed a "reality check" – assign investigators to associate our feature requests with existing tickets/functionality, to determine what future improvements are realistic and to open new tickets if needs are not already captured. Then we can report up to the SIG, discuss with POs, etc.

There was some discussion about how this fits with FOLIO community standards. There's a feeling that it's best to work through JIRA tickets and POs where possible.

Brooks Travis: The timeline for the working group is flexible – initial "deadline" was set to convey urgency but does not mean that we cannot continue our work as long as it continues to be productive.

Magda Zacharska expressed a desire to keep the #discovery Slack channel open so that there is a place to have a deeper discussion of OAI-PMH; this might lead to the creation of a subgroup in the future.

Demian Katz suggested tagging relevant tickets in JIRA with some standard tag to indicate that they are of interest to (or were discussed by) the Discovery subgroup. He also suggested that we could use meeting time for review/ticket creation if volunteers are not able to find time between meetings.

kristin.olofsson pointed out that many requested features may already exist in APIs, and we should filter out things that already exist to avoid wasting time discussing work that is already completed. Uwe Reh expressed caution that there is a possibility that some features are implemented, but have some specific details that still need to be refined/expanded.

Owen Stephens explained that in order to get actual work done within the project, we would need to either use existing resources (which requires engagement with the product owner to get work prioritized), or we would need to find new resources. When taking the product owner route, it's important to convey the relative importance of the feature in order to get it prioritized.

Uwe Reh asked for Owen Stephens ' opinion on whether it's preferable (from a PO perspective) to receive tickets directly, or to meet and discuss prior to having tickets entered. Owen suggested that his preference would be for the requirements to be discussed in the relevant SIG first (though not every PO will have the same opinion). Magda Zacharska agreed with this perspective.

Possible decision point: do we come up with agendas to take to SIGs, or do we become a Discovery SIG in our own right? Owen Stephens suggests that the latter approach might make things more complicated because of overlap with other existing SIGs.

Discussion about known shortcomings of existing APIs – Jenn Colt mentioned some specific problems encountered by Cornell's Blacklight implementation; Demian Katz suggested that if the VuFind community can find time to build a FOLIO-EDGE driver to replace the current FOLIO-Okapi driver, that will likely reveal other gaps if they still exist. Some discussion of Cornell's use case to get real time bib updates, and possible gaps in OAI-PMH/RTAC for their use case.

Circled back to question of "what next?" – general consensus in favor of reviewing what we have done with an eye to practical next steps. Demian Katz suggested as a possible first step in this analysis, the identification of any obvious low-hanging fruit of definite issues/feature gaps/etc., if any exist. Owen Stephens supported this idea of making sure that major things are captured as a way of starting useful conversations.

There was discussion about who the product owner is for patron empowerment features. There was some uncertainty about whether the PO matrix is currently up to date (possibly Khalilah Gambrell?) .Owen Stephens suggested that if there is a gap, that may be something to take to product council. If there is an active PO, we should invite that person to a future meeting. But first we need a workable agenda – can we pull things from the brainstorm list that definitely apply to mod-patron, mod-rtac.

Next step: Owen Stephens will talk to Khalilah Gambrell and see if she is willing/able to participate. We can coordinate further next steps over Slack.