| Time |
Nick |
Message |
| 00:15 |
|
dac joined #evergreen |
| 00:20 |
|
csharp_ joined #evergreen |
| 00:22 |
|
pmurray` joined #evergreen |
| 00:23 |
|
jcamins joined #evergreen |
| 03:17 |
|
b_bonner joined #evergreen |
| 03:43 |
|
ktomita joined #evergreen |
| 03:43 |
|
ktomita_ joined #evergreen |
| 03:43 |
|
tater joined #evergreen |
| 04:03 |
|
BigRig_ joined #evergreen |
| 04:05 |
|
jventuro_ joined #evergreen |
| 04:05 |
|
zxiiro_ joined #evergreen |
| 04:07 |
|
edoceo_ joined #evergreen |
| 07:01 |
|
timf joined #evergreen |
| 07:56 |
|
rjackson-isl joined #evergreen |
| 07:58 |
|
jboyer-isl joined #evergreen |
| 08:05 |
|
Dyrcona joined #evergreen |
| 08:11 |
|
kbeswick joined #evergreen |
| 08:19 |
|
csharp joined #evergreen |
| 08:28 |
|
akilsdonk joined #evergreen |
| 08:37 |
|
collum joined #evergreen |
| 08:40 |
|
Shae joined #evergreen |
| 08:50 |
|
mmorgan1 joined #evergreen |
| 08:50 |
|
mmorgan1 left #evergreen |
| 08:56 |
|
mmorgan joined #evergreen |
| 08:59 |
|
ericar joined #evergreen |
| 09:20 |
|
mrpeters joined #evergreen |
| 09:37 |
pinesol_green |
[evergreen|Remington Steed] Fix a broken link in the holds docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dbe0bf6> |
| 09:51 |
|
Dyrcona joined #evergreen |
| 10:00 |
|
RoganH joined #evergreen |
| 10:02 |
|
mllewellyn joined #evergreen |
| 10:16 |
|
jboyer-isl joined #evergreen |
| 10:21 |
|
Dyrcona joined #evergreen |
| 10:42 |
|
ningalls joined #evergreen |
| 10:46 |
|
yboston joined #evergreen |
| 10:49 |
|
kmlussier joined #evergreen |
| 11:05 |
|
jboyer-isl joined #evergreen |
| 11:36 |
jeff |
hrm. i've forgotten if hold shelf expiry dates include closed days. |
| 11:36 |
* jeff |
looks |
| 11:36 |
bshum |
I think it skips them |
| 11:36 |
bshum |
jeff: but while you're looking, if you can confirm that for me, that'd be great :) |
| 11:36 |
jeff |
heh |
| 11:40 |
kmlussier |
I didn't think it included closed days. |
| 11:40 |
jeff |
based on my notes and not on code, shelf expiration date will not fall on a closed day. |
| 11:40 |
bshum |
That sounds correct. |
| 11:41 |
jeff |
confirming. :-) |
| 11:41 |
bshum |
I vaugely recall seeing code that calculated that |
| 11:41 |
jeff |
i wrote javascript to calculate it for spreadsheet modeling in google docs. |
| 11:41 |
jeff |
which is the "notes" i just consulted. |
| 11:43 |
kmlussier |
Oh, okay. I wasn't thinking about whether it fell on a closed day, but whether the closed day was was skipped when calculating the the shelf expiration date. |
| 11:45 |
|
pmurray joined #evergreen |
| 11:51 |
jeff |
at least as far back as 2.2, through master, hold shelf expire times that fall on a closed date will be bumped to 23:59:59 on the next open date for the pickup library. |
| 12:00 |
|
smyers_ joined #evergreen |
| 12:01 |
|
dMiller__ joined #evergreen |
| 12:26 |
|
ktomita__ joined #evergreen |
| 12:26 |
|
ktomita___ joined #evergreen |
| 12:32 |
|
linuxhiker left #evergreen |
| 12:44 |
|
smyers__ joined #evergreen |
| 12:52 |
|
kbeswick_ joined #evergreen |
| 12:52 |
|
Laura__ joined #evergreen |
| 12:53 |
Laura__ |
Hello |
| 12:54 |
Laura__ |
Can the staff client catalog font be changed? We've tried using the global font and sound settings to change to a larger font but it will not change the staff catalog font size. Does anyone know a work around? |
| 12:54 |
kmlussier |
Laura__: In 2.5 you will be able to change it. I don't think that code was backported to previous versions. Let me check... |
| 12:55 |
Laura__ |
We've got a library that has installed new monitors. With the higher resolution it is making things difficult for the staff to read in the catalog. |
| 12:56 |
dbs |
kmlussier: should be in 2.4 |
| 12:56 |
kmlussier |
Laura__: I understand. It was a big problem for our staff too. But it looks like it was only put into 2.5 https://bugs.launchpad.net/evergreen/+bug/1084758 |
| 12:56 |
pinesol_green |
Launchpad bug 1084758 in Evergreen "tpac: no toggle to increase/decrease font size" (affected: 5, heat: 26) [Wishlist,Fix released] |
| 12:56 |
kmlussier |
dbs: 2.4? |
| 12:57 |
Laura__ |
we're on 2.3.5. |
| 12:57 |
dbs |
Mmm, I was thinking Open-ILS/src/templates/opac/parts/css/fonts.tt2 to bump the base size up to 16px or whatever |
| 12:57 |
dbs |
but that would affect all clients, not just individual staff client preferences |
| 12:58 |
mmorgan |
Laura__: Have you tried decreasing the screen resolution on the workstations? This has helped some of our users. |
| 12:58 |
jeff |
dbs: i think you could check ctx for is_staff and make it "just staff", but not "just these staff". |
| 12:59 |
dbs |
opac/parts/css/fonts.tt2 is in 2.3 as well, fwiw; you have to imagine that it's not just staff who are having trouble with small fonts on high resolution screens |
| 12:59 |
jeff |
(well, you might be able to go that far, but that might be a bit much) |
| 12:59 |
Laura__ |
I don't know what the current resolution is. They are working with 24" monitors. |
| 12:59 |
dbs |
jeff++ |
| 12:59 |
dbs |
changing resolutions on modern monitors (LCD / LED) often causes more problems, because the pixel approximations make things fuzzy |
| 13:00 |
dbs |
kmlussier++ # for the 2.5 bug link |
| 13:00 |
kmlussier |
I like the suggestion from dbs to increase the font size globally. Because the tpac font size really can use a boost for all users. |
| 13:03 |
Laura__ |
Would that change be at the server level? When you are talking about the folders with the font. We're part of a consortium of many libraries. |
| 13:05 |
dbs |
Laura__: yes, server level, but it can be changed per skin, if desired |
| 13:07 |
Dyrcona |
Welcome to the future: Everything is a cell phone. |
| 13:07 |
Laura__ |
Thanks for the suggestions. :) |
| 13:21 |
|
ktomita joined #evergreen |
| 13:22 |
|
ktomita_ joined #evergreen |
| 13:23 |
|
ktomita__ joined #evergreen |
| 13:25 |
|
Dyrcona joined #evergreen |
| 13:29 |
|
ktomita joined #evergreen |
| 13:29 |
|
ktomita___ joined #evergreen |
| 13:31 |
|
ktomita_ joined #evergreen |
| 13:31 |
|
ktomita__ joined #evergreen |
| 13:33 |
|
Shae joined #evergreen |
| 13:52 |
|
rsoulliere joined #evergreen |
| 14:30 |
Dyrcona |
RoganH++ |
| 14:32 |
RoganH |
Dyrcona: thanks |
| 14:32 |
Dyrcona |
Thank you! |
| 14:32 |
Dyrcona |
rangi and I were discussing that email last night and wondering what if, anything, either of us should reply. |
| 14:33 |
RoganH |
Well, my thoughts are only my own. Anyone is welcome to chime in. |
| 14:33 |
RoganH |
I hesitated to mention the Koha aspect since I'm not really part of that community but it rankled me enough I decided to anyway. |
| 14:36 |
Dyrcona |
I won't speak for rangi, but I think that rankled him quite a bit. |
| 14:36 |
RoganH |
Obviously I can't speak for him either but in his position I think it would me. |
| 14:36 |
Dyrcona |
http://kohadevreactions.tumblr.com/image/68930259566 |
| 14:37 |
kmlussier |
Heh |
| 14:37 |
RoganH |
lol |
| 14:38 |
RoganH |
that's good |
| 14:38 |
dbs |
there was so much to reply to that it seemed crazy to try. RoganH++ for being crazy |
| 14:39 |
dbs |
My takeaway is that there _are_ people who take PR verbiage at face value. |
| 14:40 |
RoganH |
dbs: it's a strange, strange world |
| 14:45 |
Dyrcona |
http://www.ptfs.com/ptfs-awarded-prime-contract-for-the-u-s-federal-government-ils-next-program3?journal=68 |
| 14:45 |
Dyrcona |
I don't know what's on Marshall Breeding's site, but I imagine he took whatever he said from the above. |
| 14:46 |
gsams |
I'm going to pull out an older system here that is migrating away soon, but they still need access for about 5-6 more days |
| 14:46 |
|
ericar joined #evergreen |
| 14:46 |
gsams |
They are running 2.0.9, they went stand alone after a long story and have little to no support |
| 14:47 |
gsams |
I've looked at their system along with another and we've narrowed it down to a power outage |
| 14:47 |
gsams |
Evergreen will not start up properly, scripts/settings-tester.pl shows no errors |
| 14:47 |
gsams |
it appears that the routers start, but the Perl processes do not |
| 14:48 |
Dyrcona |
lock files? |
| 14:48 |
gsams |
I can't say that I checked it, and I'd probably be an idiot for assuming that the other did |
| 14:48 |
gsams |
so I think I'll check that |
| 14:48 |
Dyrcona |
gsams: Look in /openils/var/lock and delete any files you find. |
| 14:50 |
gsams |
Dyrcona: As soon as I get a chance I will do that, thanks a lot |
| 14:50 |
gsams |
Dyrcona++ |
| 14:50 |
bshum |
RoganH++ |
| 14:51 |
RoganH |
bshum: thanks |
| 14:52 |
paxed |
koha what? |
| 14:53 |
Dyrcona |
heh |
| 14:53 |
paxed |
dish! |
| 14:53 |
Dyrcona |
No, I think it means "gift." :) |
| 14:54 |
bshum |
Dyrcona++ |
| 14:54 |
bshum |
Ha! |
| 14:54 |
paxed |
gift in swedish means "poison" |
| 14:54 |
paxed |
:P |
| 14:54 |
* Dyrcona |
is not making fun of Koha. |
| 15:10 |
gsams |
Dyrcona: No files present in that directory |
| 15:10 |
Dyrcona |
gsams: Anything in the opensrf subdirectory? |
| 15:10 |
bshum |
gsams: Anything in the logs? |
| 15:11 |
bshum |
Heh |
| 15:11 |
gsams |
Dyrcona: nothing in opensrf either |
| 15:11 |
* bshum |
lets Dyrcona take it |
| 15:12 |
gsams |
bshum: any particular log I should look at specifically, when I looked through it I thought it was a DB connection issue, but that turned out to be a red herring |
| 15:13 |
bshum |
gsams: That was my gut reaction to be some sort of DB connection issue like a bad password. |
| 15:13 |
bshum |
Since that would scream into the logs plenty, but show as "running" |
| 15:14 |
gsams |
bshum: I thought that was it, becuase when I ran the settings tester it through an error on postgres user |
| 15:14 |
Dyrcona |
gsams: I don't really know. I never really ran 2.0, just released a couple of the tarballs. |
| 15:15 |
bshum |
I try to forget we ever ran 2.0 as long as we did :( |
| 15:15 |
gsams |
bshum: ditto |
| 15:19 |
gsams |
Yeah the logs show no indication as to why Perl isn't running properly |
| 15:19 |
dbs |
osrf_ctl started with or without --localhost ? |
| 15:19 |
Dyrcona |
dbs++ |
| 15:19 |
bshum |
Or it could be the opensrf.xml is configured funky |
| 15:20 |
bshum |
And localhost isn't defined in there |
| 15:20 |
Dyrcona |
yeah, see how opensrf.xml is configured. |
| 15:33 |
jeff |
i wonder how often patrons intentionally vary notification options on holds. |
| 15:34 |
rangi` |
RoganH++ |
| 15:35 |
jeff |
from a user perspective, i think that there's room for improvement. |
| 15:35 |
* csharp |
just got around to reading the "next gen" email :-/ |
| 15:36 |
csharp |
marketing_speak-- |
| 15:36 |
* jeff |
muses |
| 15:37 |
|
sseng joined #evergreen |
| 15:37 |
jeff |
currently, the default notification prefs are consulted at hold request time, and if your phone number or similar changes, each outstanding hold would need to be individually updated. |
| 15:37 |
jeff |
likewise if someone decides they no longer wish to receive phone calls about holds. |
| 15:38 |
jeff |
i suspect that even with patrons that vary their notification method per hold, it's an unusual thing. |
| 15:39 |
|
misilot joined #evergreen |
| 15:39 |
jeff |
so might be an improvement to have "notify me in the usual way" vs "notify in an unusual way" at hold placement time... |
| 15:39 |
csharp |
"for these three holds, call me at *this* number - for these other four, email me at the following four separate email addresses" |
| 15:40 |
jeff |
we don't offer different e-mail addresses, and i'm okay with sticking with that. |
| 15:40 |
csharp |
"then leave a red flag in the flower pot at the rear of the library" |
| 15:40 |
jeff |
i'd actually be happy to have an org setting removing the freeform phone entry options. |
| 15:41 |
jeff |
Special Instructions: "Please include a Goonies' bookmark in my hold item" |
| 15:41 |
csharp |
heh |
| 15:42 |
csharp |
jeff: I'd support that setting |
| 15:42 |
senator |
i'd support goonies bookmarks |
| 15:42 |
csharp |
I don't know how much it affects our patrons - I do remember several tickets about "wrong" numbers entered for hold requests |
| 15:42 |
jeff |
having to explain to staff/patrons that they may need to edit all outstanding holds if a patron's phone number changes, or if a patron wishes to change their "default" notification options and have it take effect for their current holds just doesn't pass my ridiculousness test. |
| 15:43 |
csharp |
jeff: I agree with that |
| 15:43 |
jeff |
if i feel absurd / ridiculous trying to explain it to staff or a patron, I tend to try to see what I can do to make it better. |
| 15:43 |
csharp |
the word "default" is usually a conversation killer with non-technical people ;-) |
| 15:44 |
mmorgan |
jeff: but if their email address changes, they don't need to do anything. Because THAT gets pulled at notification. Adds to the confusion. |
| 15:44 |
jeff |
mmorgan: yep. |
| 15:45 |
csharp |
I suppose one of the original PINES feature requests was per-hold notification settings |
| 15:45 |
csharp |
but I've never heard anyone really talk about it |
| 15:45 |
jeff |
possible. |
| 15:46 |
gsams |
apparently the .pid files didn't get cleaned up. I ran through the "checking for errors" troubleshooting guide on the dokuwiki and got everything back up and running properly |
| 15:46 |
jeff |
gsams: hooray! |
| 15:46 |
jeff |
gsams++ |
| 15:46 |
gsams |
Dyrcona++ |
| 15:46 |
gsams |
bshum++ |
| 15:46 |
mmorgan |
I think the per hold notification is a great feature, but maybe just needs some refinement. |
| 15:46 |
gsams |
jeff++ |
| 15:46 |
gsams |
dbs++ |
| 15:47 |
mmorgan |
Like maybe instead of presenting all the hold notification fields with each hold, a way to call them only when the patron needs to change them? |
| 15:47 |
mmorgan |
and consistency in the way the notification methods are stored would be good. |
| 15:49 |
csharp |
gsams: it could be that the version of opensrf they're running doesn't automatically clean up its pids |
| 15:49 |
tsbere |
mmorgan: aside from "we don't pull the email address into the hold itself" what are you thinking for storage? |
| 15:49 |
csharp |
that was added.... sometime between 1.6 and 2.1 |
| 15:52 |
mmorgan |
tsbere: Not sure I have a good answer for that yet :-( |
| 15:53 |
jeff |
huh. i just found a hold from yesterday by looking at the last half dozen holds on the patron from question and recognizing the hold id. |
| 15:53 |
jeff |
that's... weird, right? |
| 15:53 |
jeff |
:P |
| 15:53 |
csharp |
kohadevreactions++ |
| 15:54 |
tsbere |
jeff: Not really all that weird. I have done that with copy ids, barcodes, patron ids, hold ids, and even notification ids |
| 15:54 |
rangi |
that ncip one is so how i feel everytime i work on that more :) |
| 15:54 |
|
misilot left #evergreen |
| 15:54 |
csharp |
rangi++ |
| 16:00 |
jeff |
tsbere: for storage, i think i was thinking a boolean on action.hold_request for "special notification options", default to false. |
| 16:01 |
jeff |
the individual fields might then be maintained by a trigger, or become normally unused and filled by a view or otherwise at runtime. |
| 16:02 |
tsbere |
jeff: My only "plans" for some of the issues were adding a checkbox (or checkboxes) when changing your defaults in TPAC. "Apply these new options to all of my holds" |
| 16:03 |
tsbere |
Which I think might work better than a "flag the hold that it should be using your defaults" routine, especially when considering all the other stuff that interacts with the things |
| 16:04 |
* tsbere |
figured that teaching tpac to update all of a given user's holds would be trivial by comparison to most other things he could think of |
| 16:07 |
|
mrpeters left #evergreen |
| 16:07 |
jeff |
i had considered giving an option for different notification groups / profiles, but that might be overkill. |
| 16:08 |
mmorgan |
jeff: I was just actually pondering that ... |
| 16:09 |
mmorgan |
Were you thinking a patron could set up notification profiles like "email me", "send me a text", etc? |
| 16:10 |
jeff |
more like "normal" and "notify me via every means possible" or something. |
| 16:11 |
tsbere |
I was thinking maybe more like "email me" and "email my secretary that picks my 'work' holds up for me" (though that would require multiple emails to be available for holds) |
| 16:11 |
jeff |
because i can see patrons who place lots of holds being interested in hearing via text that that one thing they want/need is in, vs the other dozen things they requested that they pick up on their normal weekly trip in. |
| 16:12 |
tsbere |
jeff: If done correctly you could even tie pickup location in. "Notify me by text so I can pick it up at the branch near work on my way home, or by email so I can stop by on Saturday at the branch near my house" |
| 16:13 |
jeff |
yeah. i don't want to get carried away, though. |
| 16:13 |
jeff |
teaching tpac and the patron editor to offer to update existing holds might be a good start. |
| 16:14 |
jeff |
and maybe making the placement UI summarize the defaults but not in an editable form by default. |
| 16:14 |
tsbere |
not sure I want to put that in the patron editor |
| 16:14 |
jeff |
"We'll notify you at X email and Y phone" with a link/button to specify otherwise. |
| 16:15 |
tsbere |
I wouldn't put it past library staff to get in the habit of *always* checking the box when editing a patron, without regard to whether the patron wants them updated... |
| 16:15 |
jeff |
arguably the patron editor is where the phone number will change most often. |
| 16:15 |
jeff |
tsbere: could make it implicit -- if there are any outstanding holds that had the old phone number, change it to the new. |
| 16:16 |
tsbere |
jeff: I had considered something like that. Gets more complicated when the phone number in question is still on the account, though... |
| 16:16 |
jeff |
which then loops me right back around to not populating the fields by default when they don't differ. :-) |
| 16:17 |
tsbere |
jeff: Perhaps add bools for phone and sms notification on/off, and if the non-bool fields are null teach things to load the patron's defaults when those fields are true? |
| 16:17 |
tsbere |
(instead of a blanket "use or don't use defaults" flag) |
| 16:18 |
jeff |
right. that would be the option that doesn't involve a trigger to maintain the fields, but would mean a little more work in the way of a view or similar. |
| 16:18 |
jeff |
tsbere: moving away from a blanket "use or don't use the defaults" means that you'd almost need a tri-state... |
| 16:18 |
jeff |
er, scratch that. |
| 16:20 |
jeff |
would you expose the bool per field to the user, in that they could override one but leave the rest at default? |
| 16:20 |
jeff |
first i'm interested in finding more examples of users who make use of this. |
| 16:22 |
tsbere |
jeff: I figure the bool would, to the user, be represented by the checkboxes we already show them. Just add a note in the catalog saying "If you don't provide an alternate number we use your default notification number, or if that isn't set your daytime phone number" and remove the "populate the phone numbers" code from the place hold screen. |
| 16:22 |
jeff |
hrm. random other holds-related question... should a hold with cancel cause "Untargeted expiration" also have an expire_time? |
| 16:23 |
jeff |
tsbere: strikes me at initial glance as too complex -- also, i see benefit in displaying the numbers at confirmation / request time. |
| 16:24 |
mmorgan |
I agree re: the complexity. I'd like things to look simpler to the user. |
| 16:24 |
tsbere |
jeff: So include what said default *is* in said notification. As for the cancel stuff, I think that some options cause non-expiring holds to be canceled due to no holdable copies as well, and staff can probably choose that if they cancel things manually should they not be lazy about picking options... |
| 16:25 |
jeff |
i dislike that hold requests can be uncancelled. better imo for it to create a new hold. |
| 16:26 |
jeff |
can't do stats on holds (for example, abandoned holds) when some have been uncancelled |
| 16:40 |
jeff |
taken to extremes, i suppose that would mean creating a new hold whenever a hold's pickup library was changed after capture, or retargeted, etc... |
| 16:43 |
mmorgan |
jeff: what sort of statistical issues would there be with changing pickup libraries and retargeting? |
| 16:44 |
jeff |
fewer than with uncancelling, but some. |
| 16:45 |
jeff |
if you were looking at time from request to capture, capture time is reset when you force retarget. |
| 16:45 |
jeff |
i think you can retarget an available hold also |
| 16:45 |
jeff |
anyway, i'm not too interested in taking that to extremes. :-) |
| 16:46 |
jeff |
but i do suspect that a non-trivial number of uncancelled holds are uncancelled after expiring on the shelf, and that of course makes reporting on shelf expired holds potentially inaccurate. |
| 16:46 |
mmorgan |
jeff: Oh good :) Looks liek I'll need to look closer at uncancelled holds, though! |
| 16:47 |
jeff |
only you can't, because they aren't called out as such. ;-) |
| 16:47 |
mmorgan |
Is there no easy way to identify them? |
| 16:49 |
mmorgan |
Do staff members uncancel them? To give patrons more time? I guess I'm not sure of the circumstances where you'd do that. |
| 16:49 |
jeff |
an uncancelled hold shows no sign at the database layer that it was ever cancelled or uncancelled. you can consult logs or you can enable auditing on action.hold_request, but i think that's it. |
| 16:50 |
jeff |
staff uncancel holds, and i believe it's most often done when a patron has forgotten to pick something up, but wants another chance at getting the item. |
| 16:51 |
jeff |
configurably, you can either have uncancelled holds get a new request date, or retain their old request date. this means that the patron can essentially be "first in line" to get the item again. |
| 16:51 |
jeff |
in some rare cases it's used when a hold was cancelled by mistake, etc. |
| 16:52 |
mmorgan |
Hmm. I think staff at our libraries are more likely to put off clearing the holdshelf, so may not happen a lot. |
| 16:52 |
jeff |
if you had a configuration where the request time was reset on uncancellation, then you could have a clue if the request_time was out of order vs the hold id before and after it -- assuming nothing like a migration. |
| 16:54 |
mmorgan |
seems like there ought to be a permission associated with uncancelling, but I don't see one. |
| 16:55 |
|
hbrennan joined #evergreen |
| 16:55 |
|
kmlussier joined #evergreen |
| 17:02 |
hbrennan |
Since it's the end of the day everywhere else, and appears quiet in here, I'll take a minute to shout: I'm attending the conference! Woohoo! Just got approval yesterday. |
| 17:02 |
kmlussier |
hbrennan++ |
| 17:03 |
kmlussier |
I'm very happy you can make the trip. I know it's a long distance. |
| 17:04 |
hbrennan |
It will be fun. Surprisingly, it will be less travel time than Alaska to Vancouver (which was three flights) |
| 17:04 |
kmlussier |
Indeed, that is surprising. |
| 17:04 |
hbrennan |
I'm very excited to see everyone, and actually have knowledge to share. In April we had only been live with Evergreen for two weeks! |
| 17:05 |
kmlussier |
Are you staying for any extra time to see the city? |
| 17:05 |
hbrennan |
Yes, a little before and after (My sister is tackling her PhD at BU) |
| 17:05 |
hbrennan |
and a side trip to NY to see family there |
| 17:05 |
hbrennan |
It will be very eventful! |
| 17:06 |
* kmlussier |
is an alum of BU. |
| 17:06 |
kmlussier |
Dyrcona is too |
| 17:07 |
hbrennan |
Awesome! I plan on taking her out with me on the dinner adventures whenever possible |
| 17:10 |
|
mmorgan left #evergreen |
| 17:11 |
|
phasefx2 joined #evergreen |
| 17:11 |
|
gdunbar joined #evergreen |
| 17:11 |
|
goooood joined #evergreen |
| 17:13 |
* kmlussier |
always thinks of Dr. Jekyll and Mr. Hyde when goooood arrives in this room. |
| 17:18 |
|
dcook joined #evergreen |
| 17:27 |
|
senator joined #evergreen |
| 17:44 |
|
wjr joined #evergreen |
| 18:23 |
|
ktomita joined #evergreen |
| 19:07 |
|
rangi joined #evergreen |
| 19:26 |
|
dcook joined #evergreen |
| 19:33 |
* csharp |
thinks of Dr. eeevil |
| 19:34 |
csharp |
of course, in that case, the nick would be "riiggght" |
| 19:34 |
hbrennan |
* hbrennan loves the 2 hour lapse in this conversation |
| 19:35 |
csharp |
hbrennan: happens a lot on IRC ;-) |
| 19:35 |
hbrennan |
haha, I obviously don't know how to format a thought |
| 19:35 |
hbrennan |
without having my name there |
| 19:36 |
hbrennan |
I also don't understand how to talk to pinesol so I'm okay with it |
| 19:37 |
csharp |
@help |
| 19:37 |
pinesol_green |
csharp: (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin. |
| 19:37 |
csharp |
@list |
| 19:37 |
pinesol_green |
csharp: Admin, Assorted2, Blame, Bugtracker, Channel, ChannelLogger, Config, Dunno, Encyclopedia, Games, Git, Herald, Insult, Karma, Later, LoveHate, MARC, Math, MeetBot, Misc, Note, Owner, Praise, Quote, RSS, Reply, Seen, Status, Time, Todo, Twitter, User, Weather, and Xkcd |
| 19:38 |
csharp |
hbrennan: you just do "/me loves the 2 hour lapse in this conversation" |
| 19:40 |
hbrennan |
ohhh |
| 19:40 |
hbrennan |
thanks! Always wondered about that |
| 19:40 |
hbrennan |
I want to be cool too |
| 19:40 |
csharp |
hbrennan++ |
| 19:41 |
csharp |
^^that increments your karma with the channel bot |
| 19:41 |
csharp |
@karma hbrennan |
| 19:41 |
pinesol_green |
csharp: Karma for "hbrennan" has been increased 6 times and decreased 0 times for a total karma of 6. |
| 19:41 |
hbrennan |
ha, I think this is my biggest karma day |
| 19:41 |
hbrennan |
I got one for saying I was attending the conference too |
| 19:41 |
hbrennan |
I have 6?! Sweet |
| 19:41 |
csharp |
:-D |
| 19:48 |
hbrennan |
so with pinesol, you just tell it to blame something, and it randomly picks something? I always find it so whitty |
| 19:49 |
* hbrennan |
is taking advantage of the slow chat day to get really important questions answered |
| 19:49 |
hbrennan |
ha, it worked |
| 20:15 |
|
berick joined #evergreen |
| 21:20 |
|
kbeswick joined #evergreen |
