Report any major changes in availability / circumstances
15
Chairs
Today’s motto: In the Vanguard there is no try. Only do.
Reminder: There’s a slack channel for the ELUNA Regional User’s Group of California that could be useful for posing questions. Jeremy and a few others are already using it. (ecaug.slack.com)
Formal round robin: how’s it going with your current implementation activities?
UCB: “Furlough Fridays!” suddenly announced, but it’s causing problems for scheduling, obvs. Otherwise SILS wise things are going better than expected. The backslash at the end of data fields was really causing problems with the tool. Now that it’s fixed, it’s going well. Pushing to get decisions made – going well. Working on processor to munge things before going into Alma. In good shape to meet the deadlines.
Not doing a test submission. Aiming to submit July 29.
UCLA: going pretty well, working closely with IT guru who does most of the data work. There are a few questions out on Basecamp. Acquisitions had experienced turnover in past year so doing their best and will tweak as needed.
Internal target is the July 25th for final data deadline (no draft, since we have different tool)
UCSD: submitted draft form on Friday with a few things of feedback from Laurie. Our “final” version is ready for July 17th. Final two extract files (suppressed bibs, and P2E) are validated and dropped into shared folder. July 17th: Greg will run all of them through a single validation tool session, and create the mapping form for everything.
Should be able to post tomorrow July 17th as DRAFT.
CDL: After our SCP folks were reporting feeling anxious about not enough time, they produced everything today! Then ExL changed the P2E formats… So we’re halfway done. Migration form was not painful, and exempt from mapping form.
ExL has asked us to wait on submitting, until Tuesday July 21 and so might submit later that week
UCSF: A lot done so far. Most things are ready to go, but we’re getting rid of 70% of bound journal collection. The good news is that we have less to validate, but it means that time has been divided between projects. Generally think we’re okay.
Hoping to do everything by July 24th. Hope we only have to do it once!
UCSB: We’re not really doing much, so doing well! We are trying to get some stuff cleaned up at the last minute. Struggling a little bit on time - leadership is adding a lot of COVID stuff as well as SILS. We have a local implementation group now!
Aiming to have everything done by July 28th.
SSM update: communication to ExL → migrate to SalesForce ticket after your data deadline. For now Basecamp is okay.
Basecamp is great to see other people’s questions which often sparks some issue you need to deal with yourself. It’s better than SalesForce which is siloed.
We could ask for SalesForce responses to come to our IC listserv so everyone could see the response.
Lena Zentall (Unlicensed) will add to PM meeting with Marci today about SaleForce and being able to see each others comments/responses.
PPC: On vacation from meeting this week, but coming back to focus on testing and assessment.
ILSDC: We published our second blog post as a follow-up to some decisions that were made recently. We’ve begun gathering / brainstorming what kind of testing and QA guidelines we’re going to be putting together → focus is on local SILS groups, and maybe FGs. Guidelines coming mid-August
Proposing a Confluence page with 3 levels of testing data - is the system working? did you have a data loss? how do you see the problems that your own esoteric data created in the system (no advice from Ex Libris on this one). Divide the page into these 3 categories. It’s easy to check if the system worked, but it’s challenging to determine where your own data failed.
Covering data validation, and other key areas.
Provide access to spreadsheets used by Alma campuses in their migrations if useful.
Lakshmi at UCI will help us get this up for review!
Draft Confluence page by July 23rd, and aim to finish Confluence testing page by end of July
ILSDC testing will come out in August: Catherine and TJ will coordinate with noname group to avoid overlap.
Acq/ERM is also working on a testing model.
It would be good to have some level of coordination to bring the various test plans together and ensure we have covered all areas.
Noname group will Draft Confluence page by July 23rd, and aim to finish Confluence testing page by end of July
6
Vanguard testing
Start to set expectations for vanguard testing by non-vanguard campuses
25
Caitlin
ExL on 7/9:
One sysadmin account per VG who can then make other accounts as needed
Not everyone needs NZ access, because NZ data is populated out to the IZ Almas and Primo - so better to see it there, not in the actual NZ.
Moving forward:
Note that there’s a patron data / acq data privacy group started in WG for examining how do we address privacy issues in testing and in consortial work.
What is the best “Default” thing to do → make a shared view-only account for Sept, then set up meetings / Q&As for Oct?
Guidelines:
make as few accounts as necessary
Give VG campuses some space to assess in Sept
Set up some template for asking who wants access and why
Plan the culmination of Vanguard and how to show the results of what we learned
Decouple “having access” from “learning lessons”
PMs check in with ExL about what they have planned for lessons learned time at the end of the Vanguard phase
Who does the “lessons learned”? → The VG ICs and the relevant PPC/FG folks. Scope minimum expectations for lessons learned.
People want to see NZ data within an IZ instance.
UCSC: Is the VG going to be making decisions about the NZ that might affect everyone going forward? If so, how can the Alma campuses be a part of good decision-making at this point in time?
Not asking for a “login” - but more ability to explore. If you gave us one limited login, that might do it!
Also someone zooming or screen-sharing might be good, if someone has time!
This is an issue now because FGs want to make good decisions and non-vanguard reps may feel like they are missing something (being excluded) if they don’t have access to the vanguard NZ.
Lynne pointed out that’s how non-Alma campuses have felt all along – that they don’t have all the info. that Alma campuses do and are catching up.
UCM: We’re not an Alma campus and we’re really interested in going on. My campus is saying we want to see “what data was before, and how it turned out after” - we’re definitely have some vanguard regret. This could be helped by having a “vanguard buddy” - maybe a non VG can have a VG buddy who can work together to see what kind of access / sharing is best.
But what is the requesting campus actually looking for? Will you get the answer you’re looking for, depending on what you’re looking at?
UCB: There’s also a psychological aspect of the non-Alma campuses also feel like we’re behind, because we haven’t had this technology before. So we do need to rely on each other to share and help each other see it.
Can we agree at least “view only” accounts should be created for non-vanguard campuses to vanguard IZs so they can see the NZ data? (pending patron data privacy question)
Sarah manages user roles at UCSC - “selector role” might be good to use.
Patron data question: what is okay to see or not see? Name, address, user type, etc.
Or can people sign some sort of NDA?
What’s the deal with coming together as “one”? We already talked about a shared patron database back when, so wasn’t this covered at the time?
Lynne’s concern is UCB is doing a lot of testing and she doesn’t want people to come to the wrong conclusion about the data if it looks wonky. It’s a test run.
Setting expectations is important. Knowing the use case is important. Roles may need to be tweaked to address use cases.
Proposal to ask at each campus, who needs access to a vanguard IZ/NZ and why (use case): List of names with use case for each person, so the right access can be given.
Use the sandbox to view the NZ data!!!! (check with Ex Libris)
Greg suggested vanguard buddies for asking questions of existing Alma campuses