Evergreen ILS Website

IRC log for #evergreen, 2015-11-20

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
01:28 * bshum needs to work on cutting back on the number of words he uses in emails.
01:28 bshum And sleeping.
01:31 jeff work on sleeping. don't work on cutting back on sleeping.
02:39 Callender_ joined #evergreen
07:35 rjackson_isl joined #evergreen
07:38 ericar joined #evergreen
07:41 jboyer-isl joined #evergreen
07:52 mrpeters joined #evergreen
07:54 collum joined #evergreen
08:42 mmorgan joined #evergreen
08:42 Dyrcona joined #evergreen
08:42 Dyrcona @weather 01845
08:42 pinesol_green Dyrcona: North Andover, MA :: Overcast :: 54F/12C | Friday: Chance of a morning shower. Mostly cloudy early, then sunshine for the afternoon. High 56F. Winds WNW at 10 to 20 mph. Friday Night: Mainly clear skies. Low 32F. Winds NW at 5 to 10 mph. | Updated: 48m ago
08:43 Dyrcona Gotta love Spring in New England.
08:46 jeff yeah. cold morning here.
08:46 jeff @weather ktvc
08:46 pinesol_green jeff: Cherry Capital, MI :: Overcast :: 36F/2C | Wind Chill: 28F/-2C | Friday: Scattered snow flurries and snow showers this morning. Becoming partly cloudy later. Temps nearly steady in the mid to upper 30s. Winds W at 10 to 20 mph. Chance of snow 30%. Friday Night: Cloudy skies with late-night snow showers. Low 29F. Winds light and variable. Chance of snow 40%. | Updated: (1 more message)
08:47 jeff that forecast of snow is obviously wrong, though. we're not done raking leaves yet.
08:47 * mmorgan loves it when spring makes a surprise appearance in the fall :)
08:49 csharp @weather 30033
08:49 pinesol_green csharp: Decatur, GA :: Clear :: 46F/8C | Friday: Abundant sunshine. High 66F. Winds light and variable. Friday Night: Mostly clear. Low near 40F. Winds E at 5 to 10 mph. | Updated: 56m ago
09:14 collum joined #evergreen
09:29 remingtron joined #evergreen
09:31 yboston joined #evergreen
10:12 Dyrcona Whee! Another circ matrix ticket.
10:13 Dyrcona This time they want to set the load period for cake pans.
10:13 berick awesome
10:13 Dyrcona A different library from the member who already circulates cake pans.
10:13 Dyrcona berick++ # For pointing out EDI Reader and friends.
10:14 berick probably a busy time for cooking implements
10:14 Dyrcona Yes, indeed.
10:14 berick Dyrcona: glad it's helpful
10:14 Dyrcona Well, it shows me that the JEDI doesn't match the EDI, so now I have to figure that out.
10:15 Dyrcona I was going to ask if its possible to delete the stuff from the database and process the EDI again.
10:15 Dyrcona I imagine yes, but it won't be simple.
10:15 Dyrcona Anyway, back to cake pans...
10:16 * berick confirms it's possible
10:19 berick well, hmm
10:19 berick no, that's only possible for ORDERS, that go through A/T
10:19 Dyrcona cake pans: item_type: r, circ_as_type: o, so looks for circ rules for kits.
10:19 berick inbound messages all happen in one action, read the remote file and process in one go
10:19 berick so, not so easy to reproduce
10:20 Dyrcona Well, I was hoping there was some back end call or stuffing the message into webrick
10:20 berick plus if it created data (e.g. an invoice), it would not recreate it
10:20 berick webrick is totally skipped on inbound messages
10:20 berick it's perl all the way down
10:21 berick edi_fetchter -> edi.pm -> insert into db
10:21 Dyrcona Sounds like I'll be learning more than I probably wanted to know. :)
10:21 Dyrcona Thanks, berick, I now know where to look.
10:24 dbwells hopkinsju: I added you to the libraries.json.  I did change your directory name to conform to the others (State, Country (Name)), but please let me know if that's not alright.
10:25 hopkinsju That's groovy. I didn't notice that was a convention.
10:25 hopkinsju Thanks dbwells!
10:25 dbwells No problem.  Anyone else have an entry to add while I am in here?  I'll keep it open a minute or two.
10:26 krvmga joined #evergreen
10:27 krvmga it's a real puzzle to me how the catalog's search return order works
10:27 krvmga i thought it was by active/create date
10:27 krvmga seems no
10:27 jeff krvmga: when ordering by what?
10:27 krvmga i thought it might be tcn
10:27 krvmga also seems no
10:28 krvmga jeff: for instance, a title search for sinatra the life
10:29 krvmga http://bark.cwmars.org/eg/opac/results?qu​ery=sinatra+the+life&qtype=title&​fi%3Asearch_format=&locg=1&sort=
10:29 dbwells default sort is "relevance"
10:29 krvmga the order of the first four returns in the catalog
10:29 dbwells Ah, you mean when they are all the same-ish.
10:29 krvmga dbwells: so record density
10:29 krvmga i didn't check to see if they all had the same density
10:30 jeff there is a tie breaker, i forget if it's date1 or something else.
10:30 jeff (and of course, that's not a guaranteed tie breaker -- i don't recall if there's a final)
10:30 dbwells I think jeff is right, pubdate is at least one tie breaker.
10:31 krvmga pubdate...
10:32 krvmga what can we understand about the order?
10:32 krvmga first = relevance
10:32 krvmga second = ?
10:32 krvmga tiebreakers = pubdate and/or ?
10:33 krvmga over here, this discussion originated in complaints over large print copies of books appearing ahead of regular print
10:34 krvmga this was causing inattentive patrons to place holds on LP materials and not noticing the regular print a few returns lower in the return list
10:34 krvmga so i was trying to investigate so i could come up with some "definitive" answer for them
10:35 jeff ah. we fixed that by displaying (LARGE PRINT) in the catalog. :-)
10:36 jeff i.e., http://catalog.tadl.org/eg/opac/results?qu​ery=the+help&qtype=keyword&locg=22
10:37 krvmga jeff: lol, that'll get their attention
10:37 jeff answering your original question may not help, but Open-ILS/src/perlmods/lib/OpenILS/Appli​cation/Storage/Driver/Pg/QueryParser.pm has an ORDER BY on fields 4 ("rank"), 5 (FIRST(pubdate_t.value) AS tie_break, and 3.
10:38 jeff er, paste hit enter for me.
10:38 jeff 3 is "rel"
10:38 krvmga how did you get (LARGE PRINT) to display. i don't see it in the record.
10:39 krvmga jeff: thanks. i'll look at that code.
10:40 krvmga jeff: did you put some tt code in that if x then print (LARGE PRINT)?
10:40 jeff https://github.com/tadl/Evergreen_templates_tadlsk​in/commit/28cedb7d1a2f475d69ebeb09771a80e96d87759f
10:40 jeff and somewhat related are several of the other commits in Dec 2014 here: https://github.com/tadl/Evergreen_​templates_tadlskin/commits/rel_2_7
10:41 jeff I think that's before we rebased our templates to 2.7.
10:41 krvmga jeff: we have a lot of admiration for your catalog at cwmars.
10:43 krvmga jeff++
10:43 dbwells krvmga: beyond (or within) what jeff posted, the only things I am aware of which affect the "relevance" sort order are preferred language settings and search.relevance_adjustment bumps (if enabled).  The built in bump types wouldn't help in this case, I don't think.
10:43 krvmga dbwells: interesting
10:44 dbs maybe the large print catalogue records have less text, so the term frequency/inverse document frequency kicks the butt of the more complete non-large print records?
10:44 krvmga dbs: i'm going to check that next
10:44 * dbs looks at the actual results
10:46 jeff dbs: that's what we've typically found -- the non-large-print records have more things like abstracts, etc.
10:46 dbs "Sinatra" appears way more times in the higher ranked records than in the large print record
10:47 dbs (at least for the example krvmga provided)
10:47 krvmga dbs++
10:47 dbs and "life" appears twice, instead of just once in the large print record
10:47 dbs and "the" appears a bunch of times in the higher ranked records because of the summary
10:49 * dbs didn't notice that krvmga's search was on title, bah
10:49 dbs switching to keyword, I think TF/IDF kicks in bigtime
10:54 krvmga dbs: important note!
10:59 Dyrcona Nothing's ever "simple," is it?
11:00 krvmga Dyrcona: you can say that again
11:00 * krvmga is off to a meeting. back later.
11:00 Dyrcona Nothing's ever "simple," is it?
11:02 miker krvmga: there's a penalty on "long" documents -- that is, in this case, shorter combined title index rows rank higher. if you want to lessen that penalty (allow longer titles to gain more from cover density) then you could consider swapping #CD_documentLength with #CD_logDocumentLength in the <default_CD_modifiers> part of opensrf.xml. or, even, remove  #CD_documentLength completely from that element.  but caveat emptor ... push one thing down, anothe
11:02 miker pops up...
11:03 miker krvmga: (and, after your meeting) you can also empty out that whole element in opensrf.xml and experiment with different CD normalizers directly in the search box
11:04 miker (one of the caveats to keep in mind: searches like, say, "title:it" may (probably will) suffer)
11:20 Dyrcona @marc leader
11:20 pinesol_green Dyrcona: unknown tag leader
11:21 Dyrcona @marc ldr
11:21 pinesol_green Dyrcona: unknown tag ldr
11:21 Dyrcona Figures.
11:30 jeff the marc leader should always be set to '48151nam a2262342 a 4500'
11:30 bmills joined #evergreen
11:34 Dyrcona jeff: Not if that is incorrect for your record, and really, I just wanted to refresh my memory on what o and k stand for.
11:35 Dyrcona o is Kit and k is Two-dimensional nonprojectable graphic, naturally.
11:36 * Dyrcona has some crazy circ matchpoints.
11:36 bshum Crazy, or CRAZY??!
11:36 bshum :)
11:36 tsbere bshum: All of the above?
11:36 Dyrcona fractal.
11:36 jeff Dyrcona: i'm just trying to follow DHARMAACR2 here. ;-)
11:36 Dyrcona :)
12:03 jihpringle joined #evergreen
12:23 bmills joined #evergreen
12:43 krvmga miker: thanks very much.
12:43 krvmga miker++
12:48 bmills joined #evergreen
12:51 gsams jeff++ #implemented the LARGE PRINT in my catalog because that's great.
13:17 krvmga jeff: i just put it out to my opac discussion group and everyone's loving (LARGE PRINT) atm. will probably implement it next week.
13:18 dbs It's like a GMD!
13:20 Dyrcona dbs: Don't say that in an airport, at least not in the USA.
13:23 jeff local hack escapes confinement: [videorecording] at eleven.
13:28 dbs Dyrcona+++
13:28 dbs Dyrcona++ even
13:28 dbs jeff++
13:30 jeff If others are going to adopt something based off of that, I wonder what can be done to make it 1) easier and 2) less of a hack. I'll have to look and see if I did the right thing with regard to schema.org when we did it in our 2.7 rebase.
13:30 dbs I still think wrapping the pertinent record in style="font-size: 3em" would be more appropriate :)
13:30 Dyrcona hah
13:30 Dyrcona dbs++
13:31 jeff hrm. not sure how to do this "better": <h1 id="rdetail_title" property="name">The Help (LARGE PRINT)</h1>
13:33 dbs jeff: you would have to do something like: <h1 id="rdetail_title"><span property="name">The Help</span> (<span property="bookFormat">LARGE PRINT</span>)</h1>
13:33 dbs For some definition of "better"
13:35 dbs jeff: or <h1 id="rdetail_title"><span property="name">The Help</span> (LARGE PRINT)</h1> with <meta property="bookFormat" content="largePrint"> appearing somewhere else in the description
13:35 dbs argh, not bookFormat in that case, accessibilityFeature
13:35 dbs <meta property="accessibilityFeature" content="largePrint">
13:39 dbs It's not clear whether that attribute has any real impact on search engines, though. Maybe yandex, as chaals was one of the hard workers on the accessibility schema.
13:54 jeff dbs++ thanks!
13:59 bmills joined #evergreen
14:04 jeff oh hey. our mobile apps are using elasticsearch now and nothing exploded.
14:04 berick jeff: i'm listening...
14:05 jeff we tend to put experiments into production.
14:05 kmlussier jeff++
14:06 jeff i have an indexer that inserts things into an Elasticsearch cluster.
14:06 jeff There is a rails app that queries that: https://github.com/tadl/elastic_evergreen
14:07 jeff There was an existing rails app that backs our mobile app, mostly did a lot of screen scraping. We shifted that over to querying the "elastic-evergreen" app for searches, instead of scraping: https://github.com/tadl/ilscatcher2
14:08 jeff So, without needing to update the mobile apps (and that was good, because we did have to roll back once for a Ruby version issue), searching on mobile apps is fast and more... elastic-y.
14:09 jeff I need to slap a license on the indexer and push that to github (slide 12 rule). currently it's only in our internal gitlab instance.
14:10 jeff We're using Elasticsearch 1.7 (looking to upgrade to 2.0 -- "breaking changes" list is long but mostly doesn't impact us)
14:10 berick ah, was looking for the indexer
14:10 berick jeff++ indeed
14:11 jeff I still consider all of this an experiment, and the approach we used was influenced by that. This isn't something that can be treated as a QueryParser backend or anything, for example...
14:12 kmlussier I hate missing search discussions in the #evergreen channel.
14:12 * berick chuckles at ruby's "rescue" keyword
14:12 berick jeff: indeed.  just like seeing how others are using it
14:12 * jeff nods
14:13 kmlussier krvmga: A little more info on the CD modifiers miker mentioned earlier. Back before the C/W MARS migration, we tried removing documentLength from the opensrf.xml file. But shorter records continued to appear high in results.
14:13 kmlussier There's an email thread on it at http://markmail.org/message/ykzdejpb735t33t2
14:13 krvmga kmlussier: very interesting. thanks!
14:13 krvmga kmlussier++
14:14 kmlussier miker then suggested that we try removing uniqueWords in addition to documentLength. And we did.
14:14 kmlussier krvmga: That's what you went live with.
14:14 * krvmga adds opensrf.xml file to watch list
14:15 kmlussier It didn't work out very well. Coverage density didn't come into play at all. So we restored them.
14:15 kmlussier krvmga: I think the lesson is, don't touch those settings unless you do a lot of testing ahead of time. I personally have been scared away from touching them ever again.
14:15 krvmga lol
14:16 kmlussier krvmga: If you think back to the phrase search bug we discovered this week, search relevance in your early days were very similar to those results.
14:16 miker kmlussier: removing all is effectively the phrase bug I just fixed, BTW.
14:16 miker heh
14:16 kmlussier miker: yup!
14:16 krvmga heh
14:16 kmlussier miker: Not sure why removing documentLength on its own didn't do anything for us, because it is a question that has come up time and time again at all of our sites.
14:18 miker kmlussier: part of it is that "document" really means "each individual field indexed, on its own" in evergreen
14:19 kmlussier Yeah, but IIRC, we were testing it on keyword searches at the time. And it's back before we had added additional indexes before the blob.
14:20 miker which, for titles especially, is a pretty narrow range of lengths
14:21 miker tuits, but it wouldn't hurt to analyze in detail
14:21 kmlussier We've generally found that the preference for shorter documents also leads to older records coming up high, because apparently we didn't catalog as much detail decades ago.
14:22 krvmga yes, we have seen that is so.
14:22 kmlussier Yeah, it might be worth taking another look at again since I don't have the pressure of two upcoming migrations as I did the last time we looked at it.
14:23 krvmga i'm up for it. what i'm trying to do is document and test and document...
14:23 * krvmga has to run to another meeting. back in a while.
14:24 kmlussier Yes. One thing I want to do is put some of the search configuration for C/W MARS and NOBLE on the Evergreen wiki as examples of what they have done for adding indexes and improving relevancy. Maybe putting failed experiments there would be worthwhile too.
14:36 gmcharlt dbs: looking at bug 1516867, and a quick question: any objection if sortable were moved to under Open-ILS/web/js/ ?
14:36 pinesol_green Launchpad bug 1516867 in Evergreen "HTML reports should be dynamically sortable" [Wishlist,Confirmed] https://launchpad.net/bugs/1516867 - Assigned to Galen Charlton (gmc)
14:37 * berick bites the bullet and updates to 15.10 on the laptop
14:39 dbs gmcharlt: no particular objections; I had avoided it largely because everything under web/js/ appeared to be dojo, but there's always a first :)
14:40 dbs gmcharlt: would you like me to refactor and push a revised branch?
14:41 gmcharlt dbs: that would be great; meanwhile I'll finish testing its functionality
15:23 * dbs suspects a Google Form might help the "CC gmcharlt" barrage (then either working with a google sheet backend to generate the JSON, and/or store the JSON in git for pull request delight)
15:24 gmcharlt yeah, we'll certainly want something of the sort by the time it goes from beta to production
15:27 dbs Oh right, it was the disturbing nature of having a CSS file located under a /js/ directory that gave me pause :)
15:27 gmcharlt cats and dogs, living together...
15:29 gmcharlt but not unprecented; lots of CSS files accompanying the Dojo stuff under /js/
15:30 dbs gmcharlt: I've pushed the branch with a second commit; you can squash it if you like
15:31 gmcharlt thanks
15:31 dbs thanks for testing!
15:31 gmcharlt speaking of which, my substantive feedback from said testing
15:31 gmcharlt 1. looks nice and necessary
15:32 gmcharlt 2. the time it takes to render the table and sort it can really bog down after a certain point. with some emperical testing I've done in the XUL client and Chrome, up to 10,000 rows or so is fine
15:33 gmcharlt but 100,000 can be a browser-killer
15:33 dbs I think 100,000 rows is a killer without any javascript, isn't it?
15:33 gmcharlt since the average # of rows in report output I've measured for a large consortium today is 4,300, on average things are fine as is
15:34 gmcharlt but I'm thinking that perhaps picking a magic row count number, after which the JS isn't loaded, might be good
15:34 * dbs avoids creating or looking at any massive reports in HTML
15:34 dbs sounds like it would be a nice add
15:34 dbs steel toes
15:35 gmcharlt yeah
15:39 gmcharlt dbs: I'll make a signoff branch that squashes your patches + adds such a limit
15:43 miker kmlussier: re failed experiments, yes please, along with the context of EG version and PG version, that will help us avoid going down forgotten blind alleys (I do that approximately monthly...)
15:47 jlitrell joined #evergreen
15:49 gmcharlt miker: but sometimes you find such interesting stuff in blind alleys! ;)
15:49 miker "interesting" he says... ;)
15:50 miker but, when the {EG|PG} context changes, yes you certainly do, sometimes!
15:52 kmlussier miker: Thanks, I'll do that! I'm planning to explore this particular blind alley again, so I'll add those versions. Can't say I recall what the PG version was when we tried it earlier and I only know the eg version because I noted it in that long-ago email thread.
15:52 kmlussier 2.2alpha. Those were the days.
15:59 Bmagic Hey yall! Exciting news - Our bib deduplication software just finished on the production database. There was a 16.9% dedupliation, removing 169k bibs. Resulted in filling 1129 holds.
16:01 jeff Bmagic: sounds exciting! code shared anywhere yet?
16:09 Bmagic jeff: sure  https://github.com/mcoia/mobius_eve​rgreen/tree/master/seek_and_destroy
16:10 Bmagic jeff: it's sort of a "manual" code edit for each of the tasks right now
16:11 * jeff nods
16:11 jeff Bmagic++
16:12 Bmagic The cataloging comittee and I spent the last 12 months moving through all of the formats in the catalog and automatically/manually editing the marc to make the format icons correct
16:12 Bmagic and finally, dedupe
16:12 kmlussier Bmagic++
16:16 Bmagic I think that asset.merge_record_assets should melt the 856's natively.
16:20 jeff berick: indexer is here: https://github.com/tadl/marc-indexing-for-es
16:21 berick jeff++
16:21 jeff many rough edges and undocumented TODOs
16:21 berick understood
16:23 jeff off the top of my head: holdings fetch is very inefficient in what's currently committed. this is very apparent in the add_due_date branch.
16:23 jeff pending commit greatly improves that by fetching all holdings for a "page" worth of bibs in one query.
16:25 jeff also, the holdings field in particular needs to (i'm pretty sure) be mapped as a nested object, because the implicit flattening makes it impossible to query for records with an available copy that is ALSO at a given library.
16:26 berick makes sense
16:28 berick i always imagined the data separated as bib stuff and holdings stuff.  worked well in my (limited) parent/child experiments.  nested should be faster for searches, though.
16:30 berick jeff: if you haven't already, this is a handy index navigator / search tool: https://github.com/mobz/elasticsearch-head
16:30 Dyrcona Well, this can't be good: Can't locate object method "retrieve_all_actor_org_unit_type" via package "OpenILS::Utils::CStoreEditor" at /usr/local/share/perl/5.18.2/O​penILS/Application/AppUtils.pm line 1392.
16:30 Dyrcona And, no, I've not hacked AppUtils.pm.
16:30 Dyrcona Nor CStoreEditor.
16:31 jeff Dyrcona: broken IDL?
16:31 Dyrcona I don't think so, but maybe.
16:32 berick Dyrcona: i usually see stuff like that when there are startup problems.  like a syntax error in a perl dependency
16:33 berick jeff: in that plugin, there's a browser w/ a handy index auto-complete search
16:34 Dyrcona Well, this will be fun.
16:34 jeff here's the WIP on the holdings optimizations: https://github.com/tadl/marc-indexing-for-es/c​ommit/ac5eb1526b0c1ac3fe7bfd4e49b0ded0435edcba
16:34 jeff i'll likely rebase that before final merge/commit.
16:36 Dyrcona Well, the IDL is valid XML.
16:36 Dyrcona All the services are running.
16:39 Dyrcona Lots of warnings about subroutines being redefined, but no syntax errors in AppUtils or CStoreEditor.
16:45 Dyrcona Hmm... AppUtils.pm has undergone some changes in the past few weeks, including some from a test branch of my own, so guess I did modify AppUtils. :)
16:47 Dyrcona So, I added a new subroutine that looks good and self-contained.
16:48 Dyrcona I would almost think if this failed that the staff client would be unusuable.
16:54 vlewis joined #evergreen
16:57 Dyrcona I just don't see anything....
16:57 vlewis kmlussier:  If you have time, could you take a look at the comment from jschrader on https://bugs.launchpad.net/evergreen/+bug/1502292 to see if I answered the question adequately?
16:58 pinesol_green Launchpad bug 1502292 in Evergreen "web client: Need ability to add volumes from the bib record" [Undecided,New]
16:58 bmills joined #evergreen
17:02 jeff berick: alas, elasticsearch-head seems at least partially broken on 1.7
17:02 jeff berick: good excuse for me to continue the experiment with 2.0
17:02 kmlussier vlewis: Yeah, I think so, but I can follow up with her just to make sure. I think knowing it is in the record summary pane answers the question.
17:02 kmlussier vlewis++
17:02 vlewis kmlussier: Thanks
17:05 Dyrcona Ooh. I bet I know what it is, now.
17:07 Dyrcona Yep... I had to init CStoreEditor. I'm not using it directly in my script, just via AppUtils.
17:09 Dyrcona Time to go home. No one should stay late at the office on their birthday.
17:09 jeff berick: https://github.com/mobz/el​asticsearch-head/pull/218 should fix it.
17:12 kmlussier Birthday? And Dyrcona left before I had a chance to send him bday cake.
17:12 kmlussier @dessert search cake
17:12 pinesol_green kmlussier: 8 found: #14: "Coconut Cream Cake", #20: "Red Velvet Cake", #23: "Pineapple Upside Down Cake", #24: "Carrot Cake", #34: "pineapple coconut cheesecake", #38: "Lemon Cupcakes", #39: "Key Lime Cheesecake", and #5: "of mllewellyn's Cupcakes"
17:13 kmlussier @dessert add birthday cake with lots of candles
17:13 pinesol_green kmlussier: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command).
17:13 kmlussier Oh yeah. Forgot about that.
17:14 kmlussier @dessert add birthday cake with lots of candles
17:14 pinesol_green kmlussier: The operation succeeded.  Dessert #41 added.
17:14 berick jeff: huh, i'm using 1.7.2.  didn't even notice.  good to know
17:14 kmlussier @dessert 41 Dyrcona
17:14 * pinesol_green grabs some birthday cake with lots of candles for Dyrcona
17:14 mmorgan left #evergreen
17:15 gmcharlt Dyrcona++ # keep on incrementing... :)
17:47 berick twice today i've made nontrivial C code changes and they worked on the first run.  I should play the lottery.
20:33 bmills joined #evergreen
21:02 jeff berick: 1.7.2 here also. since there are no branches or releases, you may have just installed the plugin before the breaking changes were made.
21:18 phasefx__ joined #evergreen
21:18 dbs_ joined #evergreen
21:18 jeffdavi1 joined #evergreen
21:18 csharp_ joined #evergreen
21:18 edoceo_ joined #evergreen
21:18 berick_ joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat