Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/527543204. The meeting password can be found here.
Date
Attendees
~58
Note taker: Laura Daniels, Lynne Fors, Alissa Hafele, Natascha Owens
Recordings
Recordings of meetings can be found in the Metadata_Management_SIG > Recordings folder on AWS from 2022 onwards: https://recordings.openlibraryfoundation.org/folio/metadata-management-sig/
Discussion items
| Announcements | The Folio wiki space has been changed over from Confluence to Atlassian. The base location changes are:
For the time being, old links are being auto-redirected to the new links (no idea how long this will last). If you are having issues with logging in, finding previously used pages, or missing functionality, please post in the #folio-atlassian-migration Slack channel. | |
| Discussion of the 3 part item state | Joint meeting with RA SIG. Will discuss the original plans for the 3 part item state and future possibilities. 3 parts: Item Status; Process; Needed For UX-374 - Getting issue details... STATUS UXPROD-1590 - Getting issue details... STATUS UXPROD-1530 - Getting issue details... STATUS TT: Trying to rework this for the current FOLIO environment. No bandwidth in developer time at the moment since this is so complex. In order to do customizable item states would mean changes across entire Folio ecosystem. Possibility of having these as separate elements on the item? DB: Came out of the desire to support workflows that other systems do. Flagging things for cataloging review for example (avoiding creating dummy patron accounts/workarounds). Also would support workflows (moving from different areas of technical services, for example). Other missing features that would help make items states useful is a customizable Workflow engine–to automate the processes within the item states. TT: Why are there three item states? What about having an item status and a process state instead? Incorporate checklist app instead of needing a workflow engine. You could reorder the processes instead of the "needed for." RW: Never understood the 3 parts either. Smaller institutions would not have the problem of figuring out where an item is in the process. We do need some kind of flag at time of check-in if it needs to go to cataloging for instance (Check-in notes are sometimes overlooked). Why are process and needed-for separated? The less requirements we have, maybe the faster we might get something. It would be easy to look up things that are flagged (instead of just having a check in note). TT: Larger institutions might have more complicated workflows with more people involved. SC: We have no way to say that status is never received or is claimed. We do create items for all of our periodicals and we don't want to have a gap in holdings but want to reflect if one has been claimed. Are we talking to the Serial group (newly created group). DB: That does raise a lot of interesting questions. We had to get the first part of item state out as a thin thread–it wasn't supposed to be hard coded in this way. You would need to be able to create customizable item states which we can't do now. worth exploring if Needed for is actually a separate item state or falls under process. TT: How to get them out of hard coded area into a customizable area? Are item states part of Inventory, circulation or its own separate app? It kind of makes sense that it is its own separate entity. JE: For larger institutions, our in-process there are many hands that are touching a record/item and it is not possible to know which unit it might be found. Not the in-process that is the issue but not having an audit trail is the problem. Likes the idea of needed-for–they are needed for digitization, repair, reserves, ILL rush, etc. And for these we create a bunch of dummy users and maybe instead we can leverage item state for this. DB: Originally envisioned to be customizable to see where in the process an item might be. JE: Five Colleges has items on all of their e-resources and they all say available that doesn't necessarily make sense as an item state. Not sure if this is an edge case. SC: Previous system had a state "library use only"–have been trying to figure out how to have this in Folio. DB: What shows to public is dependent on discovery layer. Customizable item states would help with this situation. [Discussion about how various institutions use current item states with discovery layer] TT: 3 part item states can probably be split and done separately. Extra data hanging off the item that don't effect requests or circulation rules. DB: Danger of that is you end up orphaning them from each other. You want the system to tell the staff person what they have to do with the item but you also want the item to change to the appropriate status. Could be done in parallel. Automated workflow is still desired – otherwise it is creating more work for everyone. Staff in Tech Services should not have to check an item in so that they can manually change an item from in-process to available. CM: Questions whether "needed for" would not affect circulation -- there are scenarios where it would. DB: If something is need for three different things, where would it go first? Institutions should be able to set their own priorities and do manual overrides. Part of needed-for is that it was intended to encompass both staff process needs as well as patron requests. TT: Was there a point where the requests app was going to be reflected in the process of needed for? DB: That was the original intent. To view and control the hierarchy of needs. TT: Going back to having states and processing (with needed for merged into those) – if there are multiple needs they would have to be re-ordered based on priorities (automatic re-ordering?). DB: If you had to pick between custom item states or process, which do you do first? TT: Sees adding the process first as the path of least resistance. It would be adding another element to the item. Changing to customized items states would require many different releases and would have to be across every single app. Would it make sense to add more filters to circulation rules - circulation rules dictate what can be done in the system. BT: Item status still governs as it exists now. The way that the current statuses effect circulation behavior, do they represent all of the possible behaviors in circulation? TT: So a way forward to customize item states would be to map custom states to existing circ rules. DB: Existing rules were a compromise within RA. Long term we need to tear out the hard coding and figure out where the logic should live. CM: Main objection-- you would just be pushing getting true customizable items statuses down the road again. A big hole in FOLIO compared to what other systems can do. DB: Need to let developers figure out the best way to do this based on our needs. TT: A lot more to be discussed. Will probably put out a call for a working group so people from RA and MM can come join if interested. JF: Proposes the idea of meeting again as a joint session between RA and MM. | |
| PC updates | Charlotte Whitt | 2024-02-08 Product Council Agenda and Meeting Notes Announcements: Asian-Pacific meeting - to be held on 2/21 (2/22) Evaluation Process for New FOLIO Functionality: The PC had a good discussion on the evaluation process for new functionality. The PC aims to offer a recommendation and works in concert with the TC and CC for new functionality. With that in mind, many felt that clarifying what is needed to present to the PC was necessary. You can see the Easy RetroBoard for more details. |
| BELA (Bulk Edit and Lists App) | In last Tuesday's meeting, 2024-02-06 BELA Meeting Notes, the working group worked more on how to handle warnings and errors especially when no changes were made to a field and changes were made to a different field. | |
| Data Import Working Group | In last Wednesday's meeting, 2024-2-7 Data Import Subgroup meeting, the issue of MODDICONV-361 and 365 came up. 361 is a bug where action profiles are unlinked from job profiles post migration. 365 is a bug where action profiles are unlinked from job profiles during migration. Issue 361 is under review and 365 is being investigated. The hope is that CSP #1 for Poppy will address 361. MODDICONV-361 - Getting issue details... STATUS MODDICONV-365 - Getting issue details... STATUS |
Chat
11:35:47 From Joe Reimers (EBSCO) to Everyone:
Steph is running behind and sends her apologies
11:36:18 From Steph Buck (EBSCO) to Everyone:
Here now! (Thanks @Joe Reimers (EBSCO) !)
11:43:01 From Felix Hemme to Everyone:
The current implementation of item status as String field is causing issues with internationalization. Some apps are checkin on the English value, e.g. "on order" and stumble about translated values. If we address the status, we should change this as well and implement them as reference values.
11:43:21 From Jennifer Eustis to Everyone:
Reacted to "The current implemen..." with 💯
11:43:26 From Laura Daniels to Everyone:
Reacted to "The current implemen..." with 💯
11:44:32 From Jana Freytag | VZG to Everyone:
Reacted to "The current implemen..." with 💯
11:46:13 From David Bottorff (UChicago) to Everyone:
200 or so
11:46:16 From Charlotte Whitt to Everyone:
Reacted to "The current implemen..." with 💯
11:48:06 From Charlotte Whitt to Everyone:
Maybe if a Circulation Dashboard could gather all the check in note actions?
11:48:28 From Charlotte Whitt to Everyone:
Dashboard similar to what has been developed for the ERM suite of apps
11:48:49 From Jana Freytag | VZG to Everyone:
Some reading material on 3-Part-Item-Status: https://folio-org.atlassian.net/browse/UX-374 https://folio-org.atlassian.net/browse/UXPROD-1590 Needed for: https://folio-org.atlassian.net/browse/UXPROD-1530 The concept: https://docs.google.com/presentation/d/1DRMg3KPnOnZsw0CUqaJr58tYRJRE-EbjlYDTFKKJbaY/edit?usp=sharing
11:48:52 From Brooks Travis to Everyone:
Having a “needed for” object that is related to an item and could be incorporated into the check-in/check-out process where an operator selects a “workflow” from a list and a service point to route to could work, perhaps?
11:50:07 From Steph Buck (EBSCO) to Everyone:
Reacted to "Some reading materia..." with ❤️
11:50:36 From Thomas Trutt to Everyone:
Reacted to "Having a “needed for..." with 👍🏻
11:50:44 From Thomas Trutt to Everyone:
Reacted to "Maybe if a Circulati..." with 👍🏻
11:50:59 From Brooks Travis to Everyone:
That wouldn’t require modifying the current item schema. You could even have check-in set the actual item status to “in process” when it’s “received” by the service point and clear the “needed for” record.
11:54:52 From Felix Hemme to Everyone:
In Sara's example, wouldn't the item status be "unavailable"? Plus a place where she could record the fact that it never reached the library collection.
11:55:28 From Charlotte Whitt to Everyone:
Important to keep in mind that availability is important for the discovery
11:55:33 From Brooks Travis to Everyone:
There are the check-in records, too
11:55:55 From Brooks Travis to Everyone:
You could look at those to figure out who touched it last, but folks have to check it in when they touch it.
11:55:59 From Felix Hemme to Everyone:
Replying to "There are the check-..."
Do you mean the pieces in Receiving?
11:56:20 From Brooks Travis to Everyone:
Replying to "There are the check-..."
No, there is a record created every time an item is “checked in” via Check in
11:56:20 From Felix Hemme to Everyone:
Replying to "There are the check-..."
nvm
11:58:36 From scolglaz to Everyone:
Replying to "In Sara's example, w..."
That is what we do currently: we make the Status: unavailable and then add ALL CAPS that will show to the public as part of the Volume/Issue info, like e.g., v.25:no.2(2017:Autumn) NEVER RECEIVED
11:59:25 From Laura Daniels to Everyone:
if you want to have item records for E-Resources, the system should accommodate that!
11:59:45 From Brooks Travis to Everyone:
Getting back to the approach I had in mind, there could be a similar “Process” record that the user is prompted to set when checking in an item with a “needed for” record, along with setting an underlying item status to present for the item while that “process” object is “active”
12:01:11 From Brooks Travis to Everyone:
Does “restricted” not work for that?
12:02:25 From Raegan Wiechert to Everyone:
We discussed "restricted" before, but a lot of people think that means that use is restricted to only certain people, not that the use is restricted to being in the library
12:02:51 From Brooks Travis to Everyone:
I guess I’m just odd. That was never how I interpreted it.
12:02:52 From Charlotte Whitt to Everyone:
Replying to "Getting back to the ..."
Where does that Process record live as source of truth? Circulation storage?
Why I ask is in the context of the App and Platform consolidation work
12:03:00 From Laura Daniels to Everyone:
+100 David!
12:03:13 From Anya to Everyone:
Reacted to "+100 David!" with 👍
12:03:15 From Rebecca Henning (Five Colleges) to Everyone:
Reacted to "+100 David!" with 💯
12:03:20 From Amanda Scott to Everyone:
Replying to "We discussed "restri..."
Like the restricted section in the Hogwarts library.
12:03:21 From Jennifer Eustis to Everyone:
Reacted to "+100 David!" with 💯
12:03:27 From Jana Freytag | VZG to Everyone:
Reacted to "+100 David!" with 💯
12:03:34 From Anya to Everyone:
We are folio folks :)
12:03:34 From Lynne Fors to Kara Hart (she/hers)(direct message):
You're unmuted
12:04:04 From Charlotte Whitt to Everyone:
+1 David
12:04:28 From Charlotte Whitt to Everyone:
Reacted to "+100 David!" with 👍
12:04:52 From Lynne Fors to Everyone:
It's doesn't always work with student workers reapplying the Restricted flag
12:05:10 From David Bottorff (UChicago) to Everyone:
Reacted to "It's doesn't always ..." with 👍🏻
12:05:25 From Jana Freytag | VZG to Everyone:
Reacted to "Like the restricted ..." with 😁
12:05:55 From Charlotte Whitt to Everyone:
Reacted to "Like the restricted ..." with 😁
12:06:10 From Anya to Everyone:
I recall the states were also going to drive an automated workflow process- is this still a desired outcome?
12:06:53 From Jennifer Eustis to Everyone:
Reacted to "I recall the states ..." with 👍??
12:06:57 From Anya to Everyone:
Reacted to "I recall the states …" with 👍🏻
12:06:59 From Anya to Everyone:
Removed a 👍🏻 reaction from "I recall the states …"
12:07:00 From David Bottorff (UChicago) to Everyone:
I think without an automated workflow process, I don't know they have as much value, but they could still be implemented
12:10:33 From Brooks Travis to Everyone:
Replying to "Getting back to the ..."
It could live in either, really
12:11:55 From Anya to Everyone:
Thinking about migration to folio, what status/state would items be in for day one …
12:14:49 From Anya to Everyone:
Apologies- I have to go, excited this topic is coming back up !!
12:15:19 From David Bottorff (UChicago) to Everyone:
For migration, you should be able to map current system item states to FOLIO states
12:15:20 From Cheryl Malmborg to Everyone:
@Anya We mapped our item status in the old system to the equivalent status in folio.
12:15:27 From scolglaz to Everyone:
We talked here (MM SIG) about a visible flag/indication on the item overview view that it had a request on it, since otherwise one has to click and find that tiny barely seeable 1 or other number on the item part of the way down!
12:15:38 From David Bottorff (UChicago) to Everyone:
not always a one-to-one, of course
12:15:51 From Brooks Travis to Everyone:
I think we could make that work
12:16:27 From David Bottorff (UChicago) to Everyone:
Reacted to "We talked here (MM S..." with 👍🏻
12:16:36 From Charlotte Whitt to Everyone:
Just an idea, but maybe a joint MM-SIG and RA-SIG meeting again in 1 month to resume the talk, and help us keep the focus on this very important enhancement of FOLIO
12:16:46 From Laura Daniels to Everyone:
Reacted to "Just an idea, but ma..." with ➕
12:16:52 From Jana Freytag | VZG to Everyone:
Reacted to "Just an idea, but ma..." with ➕
12:16:52 From David Bottorff (UChicago) to Everyone:
Reacted to "Just an idea, but ma..." with 👍🏻
12:16:55 From Steph Buck (EBSCO) to Everyone:
Reacted to "Just an idea, but ma..." with ➕
12:16:55 From David Bottorff (UChicago) to Everyone:
Reacted to "Just an idea, but ma..." with ➕
12:17:00 From Raegan Wiechert to Everyone:
Reacted to "Just an idea, but ma..." with 👍🏻
12:17:05 From David Bottorff (UChicago) to Everyone:
I like that idea Charlotte
12:17:20 From scolglaz to Everyone:
Will the patron/user be notified that they have been bumped?
12:17:25 From Charlotte Whitt to Everyone:
Reacted to "I like that idea Cha..." with 🌸
12:17:43 From Jennifer Eustis to Everyone:
Reacted to "Just an idea, but ma..." with ➕
12:18:12 From Brooks Travis to Everyone:
That’s an argument for the management of these states living in circulation, rather than inventory.
12:18:28 From Brooks Travis to Everyone:
I think this is a separate conversation from the built-in statuses
12:19:19 From Laura Daniels to Everyone:
Replying to "Will the patron/user..."
I think that should be a local decision, but FOLIO should allow for it
12:20:36 From Brooks Travis to Everyone:
And you could accomplish a lot of the “workflow” parts of this through circulation and pop-up modals.
12:21:21 From David Bottorff (UChicago) to Everyone:
circulation and request rules
12:21:30 From Brooks Travis to Everyone:
To me, the item status still governs.
12:21:38 From Brooks Travis to Everyone:
(As it exists now)
12:21:45 From Charlotte Whitt to Everyone:
+1 Thomas
12:23:16 From Charlotte Whitt to Everyone:
Yes, the thin thread implementation of item states was never intended to live for 7 years - but here we are …
12:25:30 From Brooks Travis to Everyone:
The status in inventory could even pull from the “status” object.
12:27:14 From Thomas Trutt to Everyone:
https://docs.google.com/spreadsheets/d/1QCniCrdOHgiR2RMh6tO7JPKjv9RfR0oiD1lCwaT261w/edit#gid=0
12:28:15 From Charlotte Whitt to Everyone:
Reacted to "https://docs.google...." with 🙏🏻
12:29:09 From Brooks Travis to Everyone:
I thought we were booked until the hour?
12:29:25 From David Bottorff (UChicago) to Everyone:
I thought so too
12:29:31 From Raegan Wiechert to Everyone:
No, just an hour, although if we go over, we should be okay
12:29:41 From David Bottorff (UChicago) to Everyone:
The meeting invite runs until noon
12:29:43 From Brooks Travis to Everyone:
The RA invite is 90 minutes 🙂
12:29:46 From Jana Freytag | VZG to Everyone:
Me too - sorry if I misinterpreted it.
12:30:05 From Felix Hemme to Everyone:
We used to met for 90 minutes but moved back to 60 last year
12:30:13 From Raegan Wiechert to Everyone:
We used to be an hour and half, but switched back to an hour a few months ago. I'm willing to stay if others are
12:30:55 From Charlotte Whitt to Everyone:
The PC updates can be read in the MM-SIG agenda/notes from today, and also the link to the PC meeting notes.
12:31:04 From Felix Hemme to Everyone:
Reacted to "The PC updates can b..." with 👍
12:31:06 From scolglaz to Everyone:
Thanks for coming and talking about this with us! Ii really appreciated it!
12:31:32 From Steph Buck (EBSCO) to Everyone:
Thanks so much, everyone. This was really enlightening
12:31:44 From Joe Reimers (EBSCO) to Everyone:
Yes, thanks so much!