Time |
Nick |
Message |
04:04 |
|
kip joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:11 |
|
agoben joined #evergreen |
07:28 |
|
rjackson_isl_hom joined #evergreen |
08:02 |
|
rfrasur joined #evergreen |
08:11 |
|
alynn26 joined #evergreen |
08:35 |
|
Dyrcona joined #evergreen |
08:35 |
|
mantis1 joined #evergreen |
08:36 |
|
mmorgan joined #evergreen |
08:53 |
|
dbwells joined #evergreen |
08:54 |
|
dbwells joined #evergreen |
09:02 |
|
dbwells_ joined #evergreen |
10:05 |
Dyrcona |
Well, 134 updates for the laptop, including the kernel, think I'll install those and reboot. |
10:13 |
|
Dyrcona joined #evergreen |
10:45 |
* mmorgan |
just realized the check_email_notify parameter needs to be added to cloned hold.available notifications :-/ |
10:50 |
Dyrcona |
Yeahp. I have a function for that. |
10:53 |
Dyrcona |
mmorgan: https://pastebin.com/2hcK8Xjj |
10:54 |
Dyrcona |
Works for any event_definition. |
10:54 |
Dyrcona |
Returns the id in case you want to do more updates, like change the name or granularity. |
10:55 |
mmorgan |
Dyrcona++ |
10:55 |
|
collum joined #evergreen |
10:55 |
mmorgan |
That's handy! |
10:57 |
Dyrcona |
Indeed, it is. |
10:58 |
|
Christineb joined #evergreen |
11:03 |
mmorgan |
But it seems like cloning an action trigger in the client should copy parameters as well as copying environment. |
11:12 |
mmorgan |
Anyone newly using hold stalling since libraries started curbside service? |
11:14 |
mmorgan |
Or anyone used it all along, and are happy with the way it works? |
11:14 |
mmorgan |
Looking at ways to delay opportunistic capture so libraries have the best chance of filling holds with their own items. |
11:15 |
|
annagoben joined #evergreen |
11:17 |
Dyrcona |
mmorgan: I don't use the client for that sort of thing. I never have. Others here do. |
11:18 |
Dyrcona |
Filling your own holds with your own items is a perennial issue even under normal circumstances. |
11:18 |
mmorgan |
Right, but moreso these days... |
11:23 |
mmorgan |
I've changed the global flag circ.holds.retarget_interval to 72 hours to keep local holds on pull lists longer, but op capture is still an issue because stuff is being returned. Never used stalling, wondering if we should. |
11:26 |
miker |
mmorgan: a soft boundary will keep holds "here" if there are any copies that could eventually fill it (available or checked out), while still letting the system look elsewhere if here don't have any holdable copies... maybe too heavy handed? but definitely reduces transits! :) |
11:27 |
miker |
here doesn't... edit all the words, miker |
11:57 |
csharp |
soft boundary wasn't working well for us. After the initial targeting, it appears that holds were not being targeted outside the branch (where we scoped it) at all after the initial targeting |
11:57 |
csharp |
I didn't dig very deep after we decided to disable it |
12:01 |
csharp |
after reading what miker just said, that makes sense, though if it assumes you *never* want it to target outside the scope as long as there are eligible copies |
12:01 |
csharp |
might be bugworthy to make it care more about statuses |
12:05 |
* mmorgan |
returns from quick meeting and reads up. |
12:08 |
mmorgan |
Is there a good reference to read on soft/hard boundary and soft/hard stalling? |
12:10 |
mmorgan |
I get hard boundary, but am cloudy on the others. Does soft boundary store data in the individual holds? |
12:13 |
csharp |
mmorgan: it sets selection_depth to whatever the boundary is set to |
12:14 |
csharp |
our desired behavior would be 1) check the branch for eligible (and available) copies. If none 2) check the system's other branches. If none, 3) check all of PINES |
12:14 |
csharp |
soft boundary *almost* does what we want :-) |
12:16 |
csharp |
but literally what the perl does is: grab selection_depth from the hold and using the context of either selection_org (if present) or pickup_lib, it starts at the depth defined by the boundary, then autodecrements the depth until it hits 0 (or a hard boundary, if set) |
12:18 |
csharp |
mmorgan: stalling only affects opportunistic hold targeting - if stalling is in effect, checkin will not grab an eligible copy opportunistically until the end of the stalling period |
12:19 |
csharp |
it's intended to address "wasted" transits where a copy to fill the hold is on the way, only to have the hold ripped out from under it by an opportunistic hold target |
12:20 |
csharp |
it was put in before my time, but my understanding is that it was implemented to account for a courier problem in PINES that caused lots of transits to arrive too late to fill the hold, just to be sent back |
12:21 |
csharp |
that problem has long since been solved, so it's probably not an issue anymore, but we still have 5 day soft stalling in place |
12:21 |
|
mrisher joined #evergreen |
12:31 |
|
collum joined #evergreen |
12:37 |
jeff |
csharp: did you just describe a scenario where a copy was captured to fill a hold, then another copy was checked in and opportunistically captured to fill the hold which already had a copy captured? |
12:38 |
jeff |
i thought that once a hold had a copy captured (or a copy had been captured to fill a hold, however you want to say it), only a manual reset/"find another target" by staff would cause a different copy to be captured to fill that hold. |
12:39 |
jeff |
(though it's possible my understanding is incorrect, or the behavior you describe is long-ago and no longer current) |
12:43 |
jonadab |
That is my understanding as well. When there's more than one copy on the shelf for something that shows up on the pull list, you have to check the barcode and get the right copy. |
12:44 |
jonadab |
Which is mildly annoying in that specific (multiple copies sitting on the shelf available) scenario; but that's not the only possible scenario, so. |
12:47 |
* mmorgan |
is trying to divide attention between irc and phone call ... |
12:47 |
jeff |
in the scenario where you have a single title hold and copy1 and copy2 are both available and suitable to fill the hold, if copy1 is on the hold pull list and you grab copy2 off the shelf and check it in, i would expect it to be captured to fill the hold (because of opportunistic capture), even though it wasn't the current_copy for the hold. |
12:48 |
jeff |
(things get more complicated quickly and there are scenarios where that wouldn't be the case, where copy2 might be captured for another hold, etc.) |
12:48 |
* mmorgan |
is failing, phone call wins |
12:49 |
* mmorgan |
thinks jeff is correct, that once a hold is capture a retarget is required to capture another copy. |
12:55 |
mmorgan |
</phone call> |
12:57 |
mmorgan |
What csharp describes sounds like what we want: "stalling only affects opportunistic hold targeting - if stalling is in effect, checkin will not grab an eligible copy opportunistically until the end of the stalling period" |
12:59 |
mmorgan |
Does stalling set anything in the individual holds? |
13:00 |
* Dyrcona |
switches laptops. |
13:02 |
mmorgan |
jonadab: What you describe about only the copy on the pull list capturing the hold is not what we are seeing. Unless it's a C or P type hold, any holdable copy will get captured regardless of the specific copy listed on the pull list. |
13:03 |
mmorgan |
Does stalling allow only the pull list copy to be captured? |
13:05 |
csharp |
jeff: hmm - maybe I'm not thinking about it correctly |
13:05 |
csharp |
I haven't looked at that lately, code-wise |
13:06 |
csharp |
I have looked at boundaries because we used the pandemic closures as an opportunity to test it |
13:07 |
|
Dyrcona joined #evergreen |
13:17 |
miker |
soft boundary is set per-hold, it starts looking at the setting value (say, branch level) and works it way up the tree until it finds an eligible copy. it stops at the hard boundary or selection_depth=0, whichever comes first |
13:18 |
miker |
so if the pickup lib doesn't have a copy, it'll look in the system, and failing that, the next level up (everywhere in the example org tree) for each hold |
13:20 |
miker |
stalling /will/ still allow op-capture at the pickup library, btw, just not elsewhere |
13:21 |
mmorgan |
miker++ |
13:21 |
mmorgan |
And stalling is not set per hold? |
13:22 |
miker |
but csharp is correct that once selection_depth is set on a hold it will not change on its own in future retargettings, so holds can be orphaned if the local copy goes missing (and is not replaced) |
13:22 |
miker |
mmorgan: correct. boundary is "where will THIS hold look, given initial conditions" ... stalling is for "I have a copy, what hold should I give it to?" |
13:23 |
mmorgan |
So soft boundary sets selection_ou, and hard boundary sets selection_depth, true? |
13:26 |
miker |
not ... really. selection_ou is generally pickup_lib, and _depth is adjusted per settings and logic |
13:27 |
dluch |
FYI - DIG Meeting begins in 33 minutes |
13:32 |
miker |
mmorgan: there's no logic that lets you set the selection_ou to other than the pickup_lib, AFAICT, but I could certainly see a use for it ... a pickup-only location, say, that has a setting that says "use BLAH as my selection_ou" |
13:33 |
miker |
but(!) it looks like if you change the pickup lib after creating the hold, the selection_ou may just stay as the original pickup lib |
13:35 |
mmorgan |
miker: ok, so selection_depth is the field that is set when using either hard or soft boundary? |
13:35 |
miker |
haven't tested, but does look that way |
13:35 |
miker |
mmorgan: right |
13:38 |
mmorgan |
gotcha. Looks like soft stalling might be what we want to try next. |
13:48 |
|
akilsdonk joined #evergreen |
13:48 |
|
drigney joined #evergreen |
14:00 |
dluch |
#startmeeting 2020-07-09 - Documentation Interest Group Meeting |
14:00 |
pinesol |
Meeting started Thu Jul 9 14:00:12 2020 US/Eastern. The chair is dluch. Information about MeetBot at http://wiki.debian.org/MeetBot. |
14:00 |
pinesol |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
14:00 |
|
Topic for #evergreen is now (Meeting topic: 2020-07-09 - Documentation Interest Group Meeting) |
14:00 |
pinesol |
The meeting name has been set to '2020_07_09___documentation_interest_group_meeting' |
14:00 |
dluch |
#topic Agenda |
14:00 |
|
Topic for #evergreen is now Agenda (Meeting topic: 2020-07-09 - Documentation Interest Group Meeting) |
14:00 |
dluch |
#info The agenda can be found here: https://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:dig_meetings:20200709-agenda |
14:01 |
dluch |
Welcome everyone! Today's meeting will be business, followed by collaboration and working on documentation, if there's time. |
14:01 |
dluch |
#topic Introductions |
14:01 |
|
Topic for #evergreen is now Introductions (Meeting topic: 2020-07-09 - Documentation Interest Group Meeting) |
14:01 |
alynn26 |
#info alynn26 is Lynn Floyd, Evergreen Indiana |
14:01 |
dluch |
Please paste "#info <username> is <name>, <affiliation>" to identify who you are and what organization, if any, you represent. |
14:01 |
dluch |
#info dluch is Debbie Luchenbill, MOBIUS |
14:02 |
jweston_ |
#info jweston is Jennifer Weston, Equinox |
14:05 |
dluch |
Well, if it's just the three of us this meeting will probably go quickly! |
14:05 |
dluch |
Stuff for the minutes: |
14:05 |
dluch |
#topic Helpful Information: Documentation contributions and collaboration |
14:05 |
|
Topic for #evergreen is now Helpful Information: Documentation contributions and collaboration (Meeting topic: 2020-07-09 - Documentation Interest Group Meeting) |
14:05 |
dluch |
#info You can find the Documentation Needs List at https://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:documentation_needs |
14:06 |
dluch |
#info DIG Roles can be found at https://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:digparticipants |
14:06 |
dluch |
#topic Old and Ongoing Business |
14:06 |
|
Topic for #evergreen is now Old and Ongoing Business (Meeting topic: 2020-07-09 - Documentation Interest Group Meeting) |
14:06 |
dluch |
#info Check-in - How is everyone doing? |
14:06 |
dluch |
How is working from home or re-opening going? |
14:07 |
alynn26 |
Good, we are mostly reopened. |
14:07 |
alynn26 |
Or doing some form of curbside |
14:07 |
dluch |
Has that been pretty smooth, so far? |
14:08 |
jweston |
Good, working with libraries reopening - inspired by them as always |
14:08 |
dluch |
We are still working from home, but many/most of our libraries are starting back to varying degrees. |
14:08 |
alynn26 |
We are parttime, in house and at home. |
14:08 |
dluch |
jweston: Right?! They're awesome |
14:09 |
dluch |
#info Previous Action Items |
14:09 |
dluch |
I think most of the peoplee involved in these aren't here, but I'll post them again as action items for the minutes: |
14:10 |
dluch |
#action sandbergja will make a video for proof of concept in the Quick Starts section |
14:10 |
dluch |
#action bmagic is writing a script to identify places in Antora docs that need headers raised up a level. DIG will help with making the changes then. |
14:10 |
dluch |
#action dluch will update the style guide to reflect new header stuff |
14:10 |
dluch |
I completely forgot about this. Will keep it. |
14:11 |
dluch |
Gah. I just deleted my next one...hold on a sec |
14:11 |
Bmagic |
I think I worked that out already (and fixed em) |
14:12 |
alynn26 |
I did make some changes to the style guide before the conference. So, There are a some recent changes |
14:12 |
dluch |
Bmagic++ |
14:12 |
dluch |
alynn26++ |
14:12 |
dluch |
So, #4 was We will revisit the topic "#info Should the server-side generation script(s) be in the EG repo?" when scripts are done |
14:13 |
dluch |
Bmagic: are we ready for that, then? |
14:13 |
dluch |
Are scripts done? |
14:14 |
dluch |
Well, I think he left, so |
14:14 |
dluch |
#action We will revisit the topic "#info Should the server-side generation script(s) be in the EG repo?" when scripts are done |
14:15 |
dluch |
#action dluch will start working on an Antora roadmap, with help from Bmagic and remingtron, that we can share with devs and others |
14:15 |
dluch |
I also forgot about this one. I do want to take the chance to give major thanks to remingtron for all his work in DIG over the years and on Antora most recently (he may already be gone, but still...) |
14:15 |
dluch |
remingtron++ |
14:15 |
jweston |
remingtron++ |
14:15 |
alynn26 |
remingtron++ |
14:16 |
dluch |
#info Antora progress |
14:16 |
dluch |
How are things in Antora-land? |
14:16 |
dluch |
What else do we need to be doing? |
14:17 |
alynn26 |
That's a good question |
14:17 |
dluch |
I have not looked at it at all, I must confess |
14:17 |
dluch |
lol |
14:17 |
jweston |
do we know if Antora was updated with 3.5 release? |
14:17 |
alynn26 |
I looked at it some, but not enough to know anything |
14:18 |
jweston |
I obviously haven't look at it recently, either |
14:18 |
dluch |
Antora wasn't in the 3.5 release, if that's what you mean. |
14:18 |
dluch |
I think we're targeting for 3.6 |
14:18 |
alynn26 |
3.6 is the target depending on the scripts |
14:18 |
jweston |
I just wondered if any new stuff from 3.5 that needed to be documented has been Antora-ized |
14:19 |
alynn26 |
Any docs in master are in the the test Antora doc. |
14:19 |
jweston |
alynn26++ thanks |
14:19 |
dluch |
Yep |
14:19 |
dluch |
Okay, let's move on. I'll be sure to get an Antora update before the next meeting. |
14:20 |
dluch |
#info Evergreen International Online Conference! |
14:20 |
dluch |
The conference went very well! Thanks to alynn26 and Bmagic for their docs-related sessions! |
14:20 |
dluch |
alynn26++ |
14:20 |
dluch |
Bmagic++ |
14:20 |
jweston |
Yes! |
14:20 |
jweston |
alynn26++ I'm ready to tackle ascii |
14:20 |
dluch |
Any comments/thoughts? |
14:20 |
jweston |
Bmagic++ |
14:20 |
alynn26 |
Your welcome. It was diffently a different experience |
14:21 |
alynn26 |
jweston, if you ever have any questions let me know. |
14:21 |
dluch |
It was so cool how yours and Bmagics ended up flowing together like a nice big docs block |
14:21 |
jweston |
alynn26 thank you - I definitely will |
14:21 |
alynn26 |
I think they planned it that way. |
14:21 |
jweston |
dluch++ so true, it's like the two presentations were designed that way |
14:22 |
Bmagic |
I could see that if mine were first, it might have flowed better? |
14:23 |
alynn26 |
I think so too. but oh well |
14:23 |
dluch |
Eh, I don't know *shrug* |
14:23 |
dluch |
Next time :-D |
14:24 |
dluch |
Also, I want to thank the planners who did an awesome job in a short time |
14:24 |
dluch |
abneiman++ |
14:24 |
dluch |
outreachcommittee++ |
14:24 |
dluch |
otherconferenceplanners++ |
14:24 |
alynn26 |
outreach++ |
14:24 |
jweston |
outreach++ |
14:25 |
jweston |
allconferencepresenters++ |
14:25 |
dluch |
#info 3.5/Experimental Catalog documentation |
14:25 |
dluch |
At the last meeting, some people were going to be working on these or contributing them. How are we doing with all of this? |
14:25 |
dluch |
I'm also not sure any of those people are here today, lol |
14:26 |
jweston |
I'm supposed to be reaching out to the other jennifer to help with this so it's now on my July to-do list |
14:26 |
dluch |
jweston: great! |
14:26 |
dluch |
jweston++ |
14:26 |
alynn26 |
jweston++ |
14:27 |
dluch |
jpringle++ (I don't remember what her nick is!) |
14:27 |
dluch |
Any other old or ongoing business to discuss? |
14:28 |
dluch |
Okay, moving on... |
14:29 |
dluch |
#topic New Business |
14:29 |
|
Topic for #evergreen is now New Business (Meeting topic: 2020-07-09 - Documentation Interest Group Meeting) |
14:29 |
dluch |
#info Community YouTube invite from Outreach |
14:29 |
dluch |
At the last Outreach Committee meeting, rhamby wanted to let DIG know that the Evergreen Community's YouTube channel, which now has all the sessions from the conference, is also available if we have--or want to create--any kind of videos related to documentation. Some ideas were showing how new features work, workflows, etc. |
14:29 |
dluch |
Does anyone already have something they'd like to contribute, or an interest in creating something? |
14:30 |
jweston |
There are some great videos out there. Should we send out a call for people to contribute existing stuff? |
14:31 |
dluch |
One thing mentioned, for instance, is sandbergja's video about contributing documentation using Github, which I think lives on her own server |
14:31 |
dluch |
jweston: Yes, I think that'd be great. I can send something out to the docs list, to begin with |
14:31 |
alynn26 |
I know we are working internally on some things we may be able to contribute, or link into Youtube. |
14:31 |
jweston |
dluch++ |
14:32 |
jweston |
alynn26++ |
14:32 |
dluch |
#action dluch will send a message to the docs list to ask for video documentation contributions to the community YouTube channel |
14:32 |
dluch |
alynn26++ |
14:32 |
dluch |
We will keep this in mind as we work on future documentation projects! |
14:33 |
jweston |
ooh, wouldn't it be cool if we could embed links to videos in the documentation? |
14:33 |
dluch |
Seems especially good if we're working on screenshots or something for new docs, that we also might make a short video about it |
14:33 |
dluch |
jweston: It totally would! |
14:33 |
dluch |
I wonder if we can do that in Antora |
14:34 |
* dluch |
will have to explore |
14:34 |
alynn26 |
It's doable in AsciiDoc |
14:34 |
alynn26 |
For the Html version of the doc, not necessary print docs |
14:35 |
dluch |
Would AsciiDoc allow you to embed a video that's still on YouTube and not a separate file? Or just a link? |
14:35 |
jweston |
Antora can embed YouTube https://docs.antora.org/antora/2.3/asciidoc/embed-video/ |
14:35 |
dluch |
Sweet |
14:36 |
dluch |
We could do all kinds of fun things, then. ;-) |
14:36 |
alynn26 |
https://asciidoctor.org/docs/user-manual/#youtube-and-vimeo-videos |
14:36 |
dluch |
jweston++ |
14:36 |
dluch |
alynn26++ |
14:37 |
jweston |
action = fun times with videos & Antora, lol |
14:37 |
Bmagic |
:) |
14:37 |
dluch |
Haha, +1 to that! |
14:37 |
alynn26 |
+1 |
14:38 |
dluch |
Is there any other new business we need to discuss? |
14:39 |
dluch |
So, since we are so small in number, what's your preference? Go ahead with collaboration time, or just end early? |
14:39 |
jweston |
end early sounds good today |
14:39 |
alynn26 |
end early is good for me. |
14:40 |
dluch |
Cool, me too. |
14:40 |
dluch |
Next meeting will be August 6. Same bat time, same bat channel. It will be primarily collaboration time. |
14:40 |
jweston |
dluch++ fearless leader! |
14:40 |
dluch |
Thanks for coming! |
14:40 |
alynn26 |
dluch++ |
14:40 |
alynn26 |
Your welcome |
14:40 |
dluch |
#endmeeting |
14:40 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration |
14:40 |
pinesol |
Meeting ended Thu Jul 9 14:40:44 2020 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
14:40 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2020/evergreen.2020-07-09-14.00.html |
14:40 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2020/evergreen.2020-07-09-14.00.txt |
14:40 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2020/evergreen.2020-07-09-14.00.log.html |
14:40 |
alynn26 |
dluch++ |
14:44 |
Bmagic |
dluch++ |
14:52 |
Bmagic |
alynn26: jweston: The docs that have been Antora-ized are strictly the set of docs that exist in that git branch. Any docs that may have been added to the traditional "docs" folder after* we created our branch in October are likely not there. |
14:52 |
Bmagic |
Though, sandbergja did port the carousels documentation to the antora docs branch |
14:52 |
alynn26 |
ok |
14:53 |
Bmagic |
Which brings us to this point again: any docs that we develop "the old way" need to also be included in the Antora repo until we merge the Antora branch. If possible. |
14:53 |
Bmagic |
Antora repo / Antora branch I mean |
15:25 |
|
mantis1 left #evergreen |
15:29 |
|
mantis1 joined #evergreen |
15:37 |
Dyrcona |
Ugh. What a time for EOLI to be down. |
15:43 |
Dyrcona |
Does anyone else want to look at the branch for Lp 1886852, or should I just push it? |
15:43 |
pinesol |
Launchpad bug 1886852 in Evergreen 3.4 "hold-copy map function can be fed non-unique copy lists" [Undecided,Confirmed] https://launchpad.net/bugs/1886852 |
15:51 |
|
sandbergja joined #evergreen |
16:03 |
|
mantis1 left #evergreen |
16:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
16:56 |
|
dbwells joined #evergreen |
17:21 |
|
mmorgan left #evergreen |
18:30 |
|
phasefx_ joined #evergreen |
19:01 |
|
phasefx_ joined #evergreen |
19:01 |
|
mrisher_ joined #evergreen |
19:07 |
|
mrisher joined #evergreen |
19:22 |
|
mrisher joined #evergreen |
21:04 |
|
sandbergja joined #evergreen |
21:22 |
|
mrisher joined #evergreen |
22:08 |
|
sandbergja joined #evergreen |
22:23 |
|
mrisher_ joined #evergreen |