Workflow conversation group - Erin, Darcy, Andrea, David agree to take into a subgroup.
First topic - anonymizing loans at check-in. Question about libraries doing the anonymizing right at check in.
Questions about anonymizing at scan, versus anonymizing with an end-session. Questions about performance issues at transaction level, as opposed to end-session. Is it Important to still see patron details on screen as part of this.?
Q: what would happen if someone navigated away? Emma: we would want to have it anonymize when you navigated away. Or maybe a timeout.
David: Is this a Cornell issue? Joanne: No, we anonymize at end of session.
Darcy: What about notices? Emma: Yah, that's also an important question.
Erin: So maybe this isn't needed. Lots of negative, not much positive. Is someone from GDPR nation on the call?
Kai: Yes, but not sure about details. He thinks the End session button would be sufficient, but he's not entirely certain. Seems like end session would work best when thinking about notifications. We have to remove the data on check in, he does know that.
Emma: So do you send bundled emails?
Kai: No, there are receipts.
Darcy: Important - notices are being built right now, assuming that sending notices at end session was the path.
Emma: Kai - is the patron details in the check-in transaction menu a problem?
Kai: At the moment, we can't see patron details when item is checked in. But if there are fees to pay, we can see the book that created the fees.
Andrea: So if GDPR folks are able to be OK with this, maybe we can just let this go.
Emma will summarize conversation to the RA mailing list.
This feeds into the capacity plan. They will then run it, see how things shake out, and then come back to SIGs.
This particular filter is blended together for Cate's epics - requests and service points.
JIras that are in progress right now - she bumped them way up to the top. EG, releases in Q3.1
In general, Cate's PO rank, tried to follow the SIG rank, but has bumped things up or down if other considerations.
Example - UXPROD-498 - making sure APIs are available for remote storage.
UXPROD-113 - fulfilling delivery requests - attempting to thin-thread this, but still really need as basic support for MVP.
UXPROD-1808 - Basic CRU - note that cancelling is a separate feature. Note that cancelling feature is at the bottom of ranking - did not mark it as PO/MVP. So ability to cancel would be controlled by ability to edit request. So Edit / Cancel is kind of like one feature, in workaround.
UXPROD-1242 - manually reordering request queue. Only workaround would be to cancel and reorder requests in order you want them. Manual work, and confusing notices.
This point on ranking is where Cate drew the line for MVP. Focused on features done by end of this calendar year - won't mean more features won't be available by Summer 2020.
So continuing below the line.
UXPROD-4 - patron service point. Workaround would be to ask patron for choice.
Discussion - at Chicago, patron default is stored in VUFind.
UXPROD-928: Requests in-app report. There are ways we can thin-thread this with requests.csv existing feature.
Andrea - so there would be additional data points in the CSV?
Mark: Date sort in CSV could work.
David: This could be an LDP report. Day-old data, not great, but liveable.
Five Colleges - we have an in-transit patron.
Cate - we don't have the date it went in transit in the CSV.
Andrea - right, that's why that needs to be added. Date it went, and from location and to location.
David: So we can't get this from the LDP?
Erin: We'd need to ask the LDP. Cate: I don't know.
Erin will ask Duke LDP rep - Angela Zoss - about availability of this in LDP.
Cate will follow the tech question about adding the three columns to the thin-thread CSV.
FLO will not have things in transit - each library has their own location (so sends like a multi-tenancy installation.)
UXPROD-1800. and UXPROD-1801 -- everyone needs to rank these.
Question about whether "thin thread" could be 1800 (patron note) but staff could also use that field.
Displaying patron note would be a discovery-layer choice.
UXPROD-1629 - filter by pickup service point.
Workaround would be exporting the CSV and filtering there.
Export to CSV - exports what you see on the screen.
Hold shelf clearance report CSV is a separate report.
UXPROD-1636 - Hold shelf expiration date respect closed library days. pickup date is not looking at whether library is closed.
Workaround would probably be in notice - link to library calendar in notice.
UXPROD-923 - Requests pick list - high rank, bumped down, because of availability of requests CSV file.
Darcy has separate uxprod for pickup slips.
UXPROD-1320 - downgraded until custom item statuses are implemented.
UXPROD-925 - hold shelf expired - there is already a hold shelf clearance csv implemented, so this might be meant.
UXPROD-1056 - this has a lot of overlap with the circ log. Emma is the PO for that feature, and having initial developer convos.
UXPROD-926 - same thing as others - everything needed for this is in requests.csv, so ranking bumped down.
UXPROD-985 - auto-generate location codes and configure location display options.
Locations are not the most user friendly right now, but they are functional. So this seemed to be nice to have.
More scanning.........
swag label means estimate was done by non-developer.
UXPROD-1412 - customize text on check-in modals. Important to some, but not others.
This group is going to have to come up with language we can agree on for existing modals. They have pretty generic language. Andrea - can someone send us the language for review.
UXPROD-1630 - pre-check request policy when requests are created and/or moved.
System does not check request policy until you are creating the actual request.
UXPROD-1416 - location and service point CRUD enhancements.
Really highly ranked. Mostly little enhancements.
We'll have some must-fix enhancements, but these may not be the right ones.
Five Colleges has a spreadsheet to do the logic and JSON conversion.
=====
Emma - features to rank from 7/8 meeting - reminder to institutions to do this.
Question about needed for and process item state. 1590 is ranked a lot lower than needed for.
Thin thread possibilities for the three-pronged item state.
Focus on Needed for, not process.
Needed for field, with values.
When item is checked in, check for requests.
If Needed for, fill in desired order.
But no Process field.
Focus on Process, not Needed for.'
Add process field with several values
Manually set process through Inventory
BUT use notes or dummy patrons to indicate need for items
Focus on automating Needed for & Process, but not for varying types of need.
Add one Needed for and one process.
When item is checked in, check for requests & needed for
Set Availability & Process, if it has Needed for
BUT, no ordering of needed for.
Andrea - hard because this really isn't the model. Erin - option 2 might be best since notes would give flexibility, as long as circ staff have the ability to edit these things. Andrea - new people probably don't have context.
Joanne - am I correct, if we have in process, we could eliminate dummy patrons? Emma - yes. Joanne - so maybe needed for could be in the notes, I don't know.
Emma - this does not need a quick answer. Andrea - we need to flesh this out. Emma, can you share your earlier decks to help the newbs get more oriented. Then we can revisit discussion. Emma - yep, that's a good idea.
============
Darcy - introducing Andy Horbal (Access Services Director.)