2025-06-04 Data Import Subgroup Meeting Notes

Announcements

ALL

Reminder to vote for issues that you are important to you.

We have moved to our new space. Our channels have been renewed (and thanks to Yael and Jenn C for catching the error). We also have a new Google Drive. If you go to our main page, there are links to all of this.

Should we cancel July 2nd as many might be out for the US holiday? This is also when ALA ends. We will cancel this one.

Data Import Documentation on FOLIO docs

@Alissa Hafele

Alissa is on the Documentation SIG for DI and DE. For today, the question is about how things are organized for DI. Currently DI is nested under Metadata Management (Cataloging). In the Documentation SIG meeting, everyone thought they needed to ask. Many thought it would be a good idea to pull it out to become a top level heading. Another idea is to have DI split and be under Acquisitions and Metadata Management.

Jeanette: I don’t think it should be split unless it goes to the same page.

Christie: It shouldn’t be split. This could result in extra work.

Jennifer: One of the comments from the Acq SIG is that being under MM people thought DI had nothing to do with acquisitions.

What about Data Export? The Documentation SIG didn’t think about about moving this as you export just MARC.

Christie: Right now it is only inventory and MARC data. It’s unknown if there are plans to change this.

Jennifer: it would be nice to centralize all export functionality in the Data Export App. But this working group is orphaned.

Alissa: Showcase of new documentation. Autumn shared the draft. This new documentation covers how to create job profiles. This new documentation will live in “Additional Topics” under the new DI section.

Jennifer: How will you reconcile what is on the wiki with what is on FOLIO docs? This topic keeps coming up in the Docs SIG. There is no clear guidance about where that line is. The additional topics is a new type of documentation. Each section of the Documentation site is owned by the person who maintains it.

Jeanette: Is there anything surrounding the idea of documentation of “see more” and point to the wiki? There are no clear guidance for that. Some might not even know about the wiki. We could point to a top level page.

If people have comments or questions, just ping Alissa.

Import orders from MARC - prep for 6/11 meeting

@Christie Thomas

Christie will share the link to the survey after this meeting. Christie will use the responses to structure the meeting for the next meeting. The hope with the 1st meeting is a community consensus on how to proceed.

How do we prioritize our issues? We have these below and also ones from our implementers' topic spreadsheet.

Christie/Jennifer

There’s been an organic approach to adding issues to the agenda.

We have issues that come from a variety of places (implementers spreadsheet, slack, and jira). We are maintaining multiple locations. Would it be helpful to have a label on the tickets in jira? What about labels like DISIGreviewed or DISIGneedsreview. These could be used to provide reports. We could work in some recurring session to review oldest tickets.

Christie: reviewing spreadsheets isn’t idea. Doing a review of Jira is good. Jira shouldn’t be the starting place for gaps or new issues. Where do emergent issues fit into the picture? How do we decide what are our guiding principles especially for something isn’t a bug? What is the difference between a bug and feature enhancement?

Ryan: It is nebulous in that gray area on how we get to emerging issues to something in Jira that can be actionable. There is room for coming up with a recurring process that we can do as a group. As a PO, no action will be taken unless it is in jira. The goal is to have something in jira.

Christie: I see the value of diving in and reviewing jiras. There’s a lot of value in establishing a process that provides equitable access to everyone. If we just focus on everything in jira, there will be gaps. Having clarity about our current tools. What if we crowdsource the implementers spreadsheet. We look there first for issues for the meeting.

Bugs will have jiras. But not all bugs have issues. These come up in lab and especially in slack.

Timothy: Sometimes it’s unclear if it is a bug or something one can’t figure out why it isn’t working. The lab helps people determine that.

Christie: This is a great discussion because it highlights a lot of uncertainty about how to raise issues and the pathways to do this. How do we wrangle this into a pipeline?

Yael: I agree with this. What happens is that someone has an issue which may or may not be a bug. Sometimes we can’t make a call. Somtimes it is the developers make that call.

Ryan: In my experience, it’s ok to not have all the answers just the details. Ryan the development team can help with this. It is a fine line sometimes.

Christie: That is refreshing to hear. Is there a label to assign to bugs that can be assigned so that we can look at them? We need something that we can have a filter.

Jeanette: There’s an undiscussed label. di-discussed.

Jennifer: Will create a slack poll for a new label for needs review and has been reviewed.