2023-05-04 Metadata Management Meeting notes

• Technical Council is discussing a draft on browser support and would welcome questions or comments
• Changes to hot fix release process from Oleksii in Slack: 

  I want to inform you, that started from Orchid release (R1 2023) we are replacing Hot Fix process with Critical Service Patch (CSP) process.
  You can find detailed presentation about it by link - https://folio-org.atlassian.net/wiki/display/REL/Critical+Service+Patch+Process.
  Benefits

  • 1. Provide a clear and documented process for requesting a service patch
    2. Reduce number of changes for post GA releases
    3. Reduce time to market for post GA changes (will be released and announced once ready)
    4. Helps to reduce context switching for development teams
    5. Formal process helps to ensure the reliability and stability and minimize the risk of service disruptions
  • Product council and other hosting service providers should gage and report on the impact of this change as releases are deployed.
• PC returned to the discussion of Role and discussed the reality of PC role in the FOLIO project: Action items are: 
  • Clarification of PO to development team- some POs do not have a development team to report to
  • Think about a coordination role of PO or some other role to bring in PO resources/development resources
  • Figure out a process to onboard and have development resources in the community pick up some of the development work-blocked JIRAs, bug work, sprint development needs?
  • More closely align FOLIO roadmap priorities with development teams and PO work
  • PO have lots of responsibilities realign some work and have SIG do more initial testing before bugfest testing?
• Workflow SIG: Martina S. will be writing a draft proposal for this SIG-last week Jeremy Huff from Texas A&M talked about development of workflows in FOLIO using Camunda as the workflow engine

What is PC doing about the lack of functionality in regards to metadata functionality? PC would like to have fruitful meetings with the SIG groups. Are there critical needs from MM that need to be discussed with PC? Critical needs should be aware of critical needs. In the cross-app group, there was mention that FOLIO is like working in a siloed LSP. This is an important comment that should be communicated.

Having representatives of this SIG talk to PC makes sense. We need to put the critical needs in contact with each other and create a picture of what are needs at the high level. There are performance issues, product being developed in a way we didn't envision, authority control, etc. These have roots in how the product was developed.

Several have noted that this isn't the first time we've raised concerns on issues and critical needs. We need to know how these are being addressed and the steps being taken. Some of the needs are not just critical, they are not allowing us to do our jobs.

FOLIO is failing in certain aspects. Many are not able to do aspects of our job. We continue to develop and fix bugs in a broken system. If some of the bugs are fixed, it doesn't resolve the core issues. So much time is spent on finding workarounds around functionality that isn't working. We can't tell our institutions that we won't do certain amount of work. We can't tell people that we won't do this in a couple of years. We need to find solutions now. These issues that are being raised aren't new. The process isn't changing. We are concerned about the project and issues being resolved.

We also continue to develop new features.

Recommending FOLIO & role of PC: Many feel this tension and desire to recommend FOLIO. We want to recommend FOLIO. But we need PC to be advocates for the community and the goal to solving the problems instead of silencing them in order to market FOLIO.

PC has a voice that it can use to advocate for the community.

FOLIO is sometimes inconsistent. For example, the truncation character is different between apps which causes confusion. In cross apps, this was put back on the SIGs to discuss searching. We need some ground rules that all Apps conform to and follow. Maybe this is Technical Council's role to ensure that there is consistency with FOLIO. Or is this PC's role?

Who is in charge of the development? Why don't we have pooled money to pay for developers? It is confusing how FOLIO is developed and who pays for what.

Sharon will relate this to the PC and get feedback.

We will post the meeting recording in slack asking people to watch.

Should we also have part of the meeting that relates impacts of bugs or lack of functionality? Some people understand. But if we don't contextualize it, then it would make sense to others.

Would it be helpful to have a wiki page outlining impact on libraries because of lack of functionality or bugs? Yes, this would be helpful to PC.

https://folio-org.atlassian.net/wiki/x/qg0b

Different German libraries have a request to change the call number element to be repeatable. This applies to both holdings and item call number.

There are some use cases for German libraries where multiple call numbers are necessary. For example, a resource is moved from open to closed stacks and one call number is primary (current closed stacks) and the secondary one is for the open one. Another example is with serials where the current issue is shelved in one area and the back issues are shelved elsewhere (stacks).

Having multiple call numbers is also a use case at Duke.

All call numbers should be in the search. In the filter there should be a box for primary to search all the primary call numbers.

When we add new filters, is there a follow-up with the query search that the appropriate search term is provided? If there's a change, this will be applied for all areas. We should ensure that when we add to the filter, that we provide the query search for that filter. As soon as some supported it is supported by query search.

The effective call number should be the primary one.

For Browse: 

Browse already has to handle multiple call numbers per title, when we have multiple holdings on an instance.

Check me on this, but there is a bit of a gotcha in call# browse.  If the call#s are very different (Dewey & LC) then you'll see each call# when you are browsing in that range.  If the call#s are close and are in the same group of returned results, you will only see the "first" call#.  Just something to keep in mind if we are adding to the pool of possible call#s that are feeding into browse.