[00:55:09] jorm2_: http://meta.wikimedia.org/wiki/Meta:Babel#LiquidThreads [12:59:13] Morning ^demon [12:59:20] <^demon> Good morning :) [12:59:33] Seems I need to poke robla and tell him calcey are reporting bugs under one generic email again ;) [12:59:48] At least it's fairly coherent ;) [14:53:48] Block the account. [14:54:48] Is getting / into MediaWiki's output still something we want? [15:28:16] TrevorParscal: Got a nice little styling rev here, probably best if you reviewed this. https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/77836 [15:29:01] *TrevorParscal defends XSL [15:43:23] *TrevorParscal notices that "xsl(t) love" wins a google fight in an order of magnitude over "xsl(t) hate" [15:44:15] I think xslt falls into the category of misunderstood languages [15:44:40] *RoanKattouw <3 ack-grep [15:44:48] people try and make it do stuff it wasn't designed for, and then hate it for not letting them do those things [15:44:56] agreed [15:45:02] I think it's treated with prejudice [15:45:08] based on ignorance [15:45:17] like racism or homophobia [15:45:31] First time I heard about it, I was like "OK so you wanna take an XML document... and transform it into another XML document... with an XML document" [15:45:57] And it kinda sounded like XML hyping / corporate overuse of XML bloat / can't really describe it well but you get what I mean [15:46:24] i.e. Why I Hate SOAP [15:46:40] If you took xslt as a language, and gave it non-xml syntax, it'd probably be more popular [15:46:53] yeah - well have you ever really used XSL? [15:47:07] SOAP has issues [15:47:30] as Neil put it "it's not simple, it's not object oriented, it's not accessible, and it's not a protocol" [15:47:34] I've never used it and I never intend to [15:47:36] whaha [15:48:05] RoanKattouw: why do you never intend to - if I may ask? [15:48:13] Just reading about it gave me an unescapable impression of XML glorification like above [15:48:19] Well it looks godawful [15:48:41] I have to admit I've never used it, but just looking at it, it looks painful [15:49:03] Maybe that's prejudice too; but I'm a "I don't need to try this to know it's horrible" kinda guy [15:49:06] and $thing ): ?> is pretty? [15:49:20] By "looks godawful" I didn't mean code prettiness [15:49:36] I guess I didn't express myself right [15:49:43] I just meant the way it's designed, the way it works [15:49:48] right on [15:49:51] Using XML for absolutely everything, and more [15:50:04] I agree that using XML for everything is bad [15:50:29] Once upon a time, someone requested that api.php support SOAP [15:50:44] And I was like, well, it seems to rely on us parsing XML documents you submit to us [15:51:03] Which 1) is a PITA to code up, request parameters are soo easy and 2) is a DoS vector because we have to parse your XML [15:51:39] *guillom waves. [15:52:03] well, SOAP has more issues than just the fact that you have to parse something to respond to it [15:52:08] Hi guillom. [15:52:12] hi flipzagging - we're just talking about SOAP sucking [15:52:41] I wrote some prototype code that used SOAP [15:53:07] I'm re-adding a section in my name in the etherpad for features engineering weekly meetings -- not sure why it was removed [15:53:23] You are still on our team? [15:53:41] it wasn't meant in offense - I thought you were moving to a different team [15:53:51] Unless someone didn't tell me, yes, I am :) [15:53:55] cool [15:54:03] well, I guess I misunderstood [15:54:06] np [15:54:21] uh huh [15:54:26] well - anyways [15:54:37] where were you for our meeting then? [15:54:57] in a place without internet connection [15:55:07] It's difficult to find one these days [15:55:30] We're supposed to move in a new apartment next week [15:55:55] well - if you can't make next week's meeting, please let me know in advance [15:56:05] Gah, Freudian typo [15:56:14] Meant to grep for WikiError, grepped for WikiEditor instead :D [15:56:34] RoanKattouw: that hopefully has little or no overlap [15:56:38] <^demon> Ew WikiErrors. [15:56:46] I thought WikiError was killed. [15:56:54] <^demon> It's in the process of dying :) [15:56:59] I think it's still got remnenants [15:57:02] Shirley: Yeah I'm verifying that [15:57:21] ialex deprecated the WikiEditor* constructors and ::isError() [15:57:32] But especially the latter is used a zillion times in REL1_17/extensions [15:57:37] Did you just do it again? [15:57:49] <^demon> Yeah he did [15:57:51] <^demon> :p [15:58:42] So there's a patch to add tbody/thead/tfoot support to MediaWiki. [15:58:52] I wonder if it applies cleanly and works. [15:59:01] TIAS? [15:59:28] Aunts in Spain [16:21:36] RoanKattouw: ah, I see ~15 hits to check return values of UserMailer::send() and such and deprecated stuff in extensions/SemanticForms/specials/SF_UploadWindow.php [16:22:04] catrope@roanLaptop:~/mediawiki/branches/REL1_17$ ack-grep WikiError extensions/ | wc -l [16:22:06] 25 [16:22:08] (same in trunk) [16:22:18] Most of it seems to be ::isError() upon casual inspection [16:22:43] Ah yes, you're right, and return new WikiErrorMsg stuff in SF [16:23:53] that file is not used anymore on MW 1.16+ imho [16:24:09] but some people like b/c... [16:26:08] What file isn't? [16:26:18] Well you're right WikiEditor is not called by 1.17 core [16:26:35] But it's still called by extensions we're about to release as 1.17 of [16:26:45] So I don't think a wfDeprecated() is in order just yet [16:26:58] (I might be wrong here, don't remember what was done in the past. ^demon , do you know?) [16:27:33] I was speaking about the SF file ;) [16:27:42] <^demon> wfDeprecated() usage? Depends who you ask :D [16:31:00] slow branch checkout is slow [16:31:14] ^demon: ialex added wfDeprecated() to WikiError::isError(), which is used in ~15 places in extensions/ [16:31:51] RoanKattouw: WikiBhasa doesn't use WikiError, it's javascript code ;) [16:31:58] lol [16:32:04] Fair :) [16:32:04] <^demon> I don't usually but wfDeprecated() until the last call is removed. [16:32:09] I just grepped for it [16:32:11] <^demon> s/but/put/ [16:32:22] <^demon> In trunk, that is. [16:32:31] yeah, we could remove from 1.17 but leave it in trunk [16:32:37] <^demon> If you start mix & matching core and extension versions, I have no pity. [16:32:43] =D [16:33:07] ialex: OK will revert in 1.17 then [16:33:10] <^demon> Then again, I only really care about trunk and the latest stable release anyway :p [16:33:33] RoanKattouw: ok [16:34:02] <^demon> 1.15 and 1.16 are dead to me :p [16:34:10] +1 [16:34:13] +2 [16:34:22] 1.16 is really old :P [16:34:23] ialex: I've tagged it revert1.17, will get to actually reverting it later [16:34:39] <^demon> 1.16 is a pretty buggy branch. [16:34:43] <^demon> 1.15 was way more stable. [16:35:11] there was a lot stuff backported only to wmf branch and not REL1_16 [16:36:18] <^demon> Well our branches don't get nearly as many backports as they should. [16:36:28] <^demon> For being "supported" we rather neglect them [16:36:37] +1 [16:36:50] <^demon> Only when we get a "zomg immediate security release" do they get any attention. [16:37:31] <^demon> I've brought up before having one or two people volunteer to be a "branch manager" for each supported branch to make sure they get appropriate fixes backported. [16:39:32] and we'll have to backport all the fixes in the new installer to 1.17 [16:39:38] and other bug fixes too [16:40:04] <^demon> Not all fixes. [16:40:59] <^demon> Wait, are you talking before or after 1.17 release? [16:43:42] I'm speaking about commits in /trunk/phase3/includes/installer from the branch till now [16:45:01] <^demon> Yeah, all of that stuff will get merged over in a batch commit. [16:46:44] Tag it as 1.17 [16:47:01] I'll merge the first batch of 1.17-tagged commits later today [17:19:35] hey all [17:19:51] Trevor: it is too early in the morning to discuss SOAP, surely [17:19:58] ha ha [17:20:37] (as per backlog - TrevorParscal: as Neil put it "it's not simple, it's not object oriented, it's not accessible, and it's not a protocol") [17:20:48] I think you were quoting someone else at the time as well [17:20:50] I didn't invent that [17:20:52] but yes [17:21:52] I just lived through the period when it had the most hype, 2000-2002 or so [17:22:34] where it went from "this will make the web obsolete" to "OMG this is the worst thing ever, how can we get out of supporting it" [17:24:29] ha ha [17:32:30] anybody in SF know a good chiropractor? [17:32:35] is Priyanka in yet? [17:40:40] morning pdhanda [17:40:59] morning flipzagging, how are you feeling today [17:41:33] well, my brain is coherent, stomach still doesn't work, right arm still not working right [17:42:20] was going to ask you if you knew a good chiropractor. For what it's worth I really hate all the woo-woo around chiro, but it may help in this situation [17:42:58] i think the arm isn't sitting right in its socket or something, maybe they can align it in so the nerves are less pinched [17:43:33] flipzagging: i know a few in the south bay, none in SF unfortunately [17:44:18] pdhanda: thanks anyway [17:44:40] how are you doing? [17:45:24] doing well. finally got a good nights sleep :) [17:45:34] excellent [19:25:33] ohai TrevorParscal [19:26:03] howdy [19:28:10] Are we having a meeting? [19:28:14] My phone is bleeping at me [19:30:38] um [19:30:43] we were going to do a scrum [19:30:46] we can do it online [19:30:51] no big deal [19:39:42] let's push our sync-up back to 1pm is that OK? [19:39:43] hrn. [19:40:00] fine with me. [19:40:03] let's go get lunch, then. [19:41:40] I sent out updates through google calendar [20:23:50] TrevorParscal: Hey I was thinking, maybe you should do a run through CSS stuff and add some /* @embed */ directives [20:23:54] Especially in JUI [20:24:02] yeah [20:24:08] could save lots of requests [20:24:17] Or, if you don't wanna patch JUI CSS to add @embed all over, devise an 'embedByDefault' => true flag [20:31:50] oh [20:31:55] that's a good idea actually [20:32:01] hmm [20:33:31] It'd be a good performance improvement for JUI especially, which was kind of a performance problem child historicall [20:33:32] y [21:02:57] TrevorParscal: AF meeting? [21:03:04] yes [21:03:07] jorm: howdy [21:03:08] Was gonna be on IRC, right? [21:03:10] yes [21:03:18] Sweet [21:03:18] no need to be on the phone [21:03:23] we can just do rounds [21:03:32] Reedy: you there? [21:03:36] jorm: you there? [21:03:46] we can just sync up on IRC [21:04:03] Yus [21:04:56] So, all I want to capture here is what are you working on / do you need more input on what to do / who do you need help with / who will you be working with / general questions - any or all of these things [21:04:59] I will start [21:05:13] here. [21:05:32] I'm nearly done recoding the front-end, we will be making design changes but the code is really flexible so that will be easy to do with very trivial adjustments [21:05:43] i'm groovy right now. spoke with parul at length yesterday to see what we can include from her interviews. [21:06:04] i had an idea to do a totally different, more vertically oriented design for option C. [21:06:37] the new front end still needs several things: call to action content, form submission logic, stale/expired messaging, survey popup and alternative positioning [21:06:46] jorm: with the new code, a vertical layout would be trivial to do [21:06:51] okay. [21:07:27] we can just mock up a vertical version, using the existing layout (or where it lands post Parul's research-based adjustments) as a basline [21:07:32] that's what I'm working on [21:07:48] I need to work with jorm on the design stuff and Reedy on the API interfacing [21:07:56] who wants to go next? [21:08:12] I'll go real quick [21:08:13] jorm: you want to continue where you were going there? [21:08:16] ok [21:08:18] RoanKattouw: go [21:08:21] nope, i'm good. [21:08:26] you know where i am. [21:08:30] cool [21:08:31] I haven't been doing any AF work later, just review and 1.187 [21:08:35] *1.17 [21:08:50] I've decided to not review non-trivial AF revs for now because it's all in flux so much now [21:08:55] I'll do a wholesale review later [21:08:56] awesome [21:09:02] Reedy: ? [21:09:13] http://www.mediawiki.org/wiki/Talk:Article_feedback/Public_Policy_Pilot/Tasks [21:09:19] Just need to get the proper clarification on that [21:09:30] yes [21:09:32] turn to 0. [21:09:32] ie what "clear" means, in their past, current, total, etc ratings [21:09:53] Does that affect the page rating count/total? [21:09:57] guy provides ratings of 1,3,3,5. later he wants to set it to null, 3,3null [21:10:03] it removes them. [21:10:12] but we want to keep their historic ones. [21:10:21] do we have a record for each attribute? [21:10:39] as in, someone submits ratings for all 4 attributes, 4 rows are created...? [21:10:42] so if a guy nulls his rating on something, we want to know that he nulled it, not count it in any calculations, and still save teh old ones. [21:10:47] TrevorParscal: yes. [21:10:48] yus [21:10:55] ok [21:11:11] so what we need is, when a user submits a 0, it is not included in the calculations [21:11:21] it's stored as null maybe - up to you [21:11:35] and we store a timestamp for when it was cleared [21:12:02] if we clear it, we need to knock that off the articles totals then, and decrement the count for that rating? [21:12:05] or just update the timestamp as usual [21:12:12] yes. [21:12:12] yes [21:12:21] *RoanKattouw recommends not storing the row, rather than null [21:12:21] right, i think [21:12:30] well, we'll have the old rows, right? [21:12:36] RoanKattouw, you mean, if they don't submit a rating? [21:12:40] and they may get calculated. [21:12:45] so basically we will just support submitting 0, and adjust the calculations to not include those in the averages, and decriment the totals [21:12:52] Yeah or when they remove/nullify an existing rating [21:12:58] i think (correct me if i'm wrong) the current behavior is to set a row of 0 for non-rated values. [21:12:59] The row for the rating should just be deleted [21:13:11] we want the history, i think. [21:13:19] it's horribly, horribly important right now. [21:13:19] You won't have history eitherway [21:13:22] If you allow overwriting [21:13:32] we don't overwrite; we add new rows. [21:13:34] RoanKattouw: if we delte it, we can't run stats on how often the clearing feature is used... [21:13:35] Trevor suggested a struck type of timestamp [21:13:36] OK so if you want history, there cannot be any overwriting [21:13:38] OK didn't know that [21:13:51] at least, that's my understanding of the behavior. [21:13:51] and then just new ratings, with null timestamp, meaning it's live [21:13:52] Forget what I said then [21:14:23] I guess the thing is, unless we keep everything (append only) it's not going to help us to have those 0 ratings [21:14:30] if we want that data, we should store it somewhere else [21:14:44] and I will let howie decide what extra data he wants [21:14:45] the big value we're trying to get here is to see if we can plot an article's quality over time, and see if the tool's values match the value of the article text itself. [21:14:59] so, in the mean time - just drop the row if the value is submitted as 0 [21:15:24] and we're good [21:15:27] simple [21:15:36] No, we still need the zero row then [21:15:41] Or you'll get mixed results [21:15:54] what about when people "update" their ratings [21:15:57] hmm [21:16:00] Exactly [21:16:08] So if we decide it's append-only [21:16:14] (Which I think it is right now) [21:16:19] yeah, it needs to be [21:16:20] Then every rating *must* be stored, even if it's 0 [21:16:32] right. [21:16:35] So all we'd need to change then is how the aggregates deal with zeros I guess [21:16:37] (backend-wise) [21:16:43] Cause submitting 0s is already possible AFAIK [21:16:53] so if you" "update" your rating, you need to be actually expiring your old rating and presenting a new one [21:17:45] there are already timestamps, i believe. [21:18:01] yeah [21:18:06] TrevorParscal: Right now that's done by adding all ratings regardless of value, and doing LIMIT 4 [21:18:13] k [21:18:18] That'd break if we do sparse storage (i.e. not storing zeros) [21:18:21] http://www.mediawiki.org/wiki/Article_feedback/Public_Policy_Pilot/Technical [21:18:23] So we have to continue storing zeros [21:19:05] well - I'm going to let Reedy and Roan figure out how to make it work [21:19:35] the clearing concept is simply, pretend I never submitted my most recent rating submission [21:19:45] its' "throwing away" your most recent rating [21:19:48] Right, and we (I) will do some proper use cases [21:19:50] whcih is really just striking it [21:19:58] k [21:20:03] Right, so overwriting it with 0 [21:20:32] And zeros need to get special treatment in calculating aggregates in that case; I think this is already done partly, and I guess this has already been figured out [21:20:32] simple [21:20:36] yes [21:20:54] So it's somewhere, just need to tell us what the behavior should be [21:21:30] Like, is the avg rating SUM(ratings)/COUNT(ratings) or SUM(ratings)/COUNT(non-zero ratings) (which equals SUM(non-zero ratings)/COUNT(non-zero ratings) ) [21:22:00] Reedy: you have enough clarity? [21:22:09] sorry - this turned into a bit of chaos [21:22:17] Haha, I'm possibly more confused [21:22:20] I'll sort it with Roan [21:22:24] cool [21:22:24] harh. [21:22:27] Simpler question - "Support bucket-test logging" [21:22:32] You just want a character/digit, right? [21:22:46] yeah [21:22:51] number i suppose... [21:23:02] the bucket test logging is going to have to be tracked per rating, i think [21:23:04] in the click tracking extension we used a tag table and then stored ids [21:23:16] TrevorParscal, jorm: So which is it? Do zero ratings count towards the average or not? [21:23:21] every new incoming string would be looked up, if it wasn't present it would be inserted [21:23:27] 0 ratings do NOT count. [21:23:30] this let us use strings instead of numbers [21:23:33] they should be ignored. [21:23:45] jorm: Noted, thanks. So it's SUM(non-zero ratings)/COUNT(non-zero ratings) then, right? [21:23:52] RoanKattouw: right - it's not a bad rating, it's a non-existent one [21:23:54] yes. [21:23:57] We may be conflating too issues here [21:24:13] We need to track the event of the user having seen a certain version [21:24:23] yeah, those are two different things. [21:24:24] For that we need clicktracking (should work fine, right?) or similar [21:24:35] And there's storing which version the user used when submitting a given rating [21:24:37] Reedy: so, it's fine if we just add a column that stores a numeric ID for the bucket [21:24:39] That's an extra column in the ratings table [21:24:43] i don't know we need to track when the user sees a version, just that they *used* the version. [21:24:56] So you only want the version as a flag in the rating metadata? [21:24:57] but if we had a tag lookup it would be *nice* [21:24:59] we can derive how often versions are shown. [21:25:04] Oh of coures [21:25:09] Fractions of page views [21:25:12] right. [21:25:13] You're totally right [21:26:02] there is one other set of things we're going to want to track - the results of various calls-to-action - but we can table that discussion for now. [21:26:39] the CtA stuff is Serious Business. howie sent a mail about what he wanted to see or be able to derive. [21:26:57] *Shirley dons the :| face. [21:27:12] What's that about exactly? Correlate displayed CtA with edit/acc-create behavior? [21:27:35] Reedy: you can poke me more about the bucket thing -I will help you [21:27:58] - I'm going to say meeting adjourned - of course you can all remain chatting... it's a public channel :) [21:28:25] So is AF realted to the CtA campaign? [21:28:30] Related, even. [21:28:45] I think CtAs are being shoehorned into the AF "Thank you for completing this rating" message [21:29:28] Or at least it's my understanding that's where they'd be put [21:29:51] yes. [21:30:01] i know very little about the call-to-action campaign. [21:31:36] only our bit of it. [21:34:09] Well, it's also going in the CN banners. [21:34:18] Assuming the goal is met before January 15. [21:34:33] But I don't see the correlation between rating articles and a CtA. [21:34:50] Unless we'd like a mountain of new contributors going around rating things and doing nothing else. [21:35:01] Which, to be fair, might be someone's mission. Seems silly, though. [21:35:37] i think you are misunderstanding the purpose of the feature. [21:36:30] ArticleFeedback? [21:36:38] It seems fairly straightforward. [21:36:47] the calls to action part of articlefeedback. [21:37:03] Ah. [21:37:09] Certainly possible. [21:37:41] The whole CtA thing doesn't make much sense to me. Which probably means I'm missing some piece of it. Or it's actually senseless. [21:37:42] It's the other way around [21:37:45] Probably a toss-up. :-) [21:37:58] After they rate an article we go "hey, did you know you could edit this too? Go contribute!" [21:38:10] As opposed to "WE WANTZ UR RATINZ" [21:38:20] On top of every page with Jimmy's face next to it [21:38:21] or "hey, did you know you can make an account?" [21:39:53] There's a more fundamental question of whether it's a good thing to focus on quantity of editors. [21:40:12] Getting a million people to create accounts doesn't do much. [21:41:04] more database rows. [21:41:06] And you're attracting people who like to rate things. [21:41:15] OOOOOH SHINEY [21:41:49] Shirley: You should see our feedback dumps, some people have quite a lot of criticism on individual articles. It's unfortunate we don't store the page they were on when they submitted feedback :( [21:42:08] RoanKattouw: Criticism? On the Internet? [21:42:15] And, again, it's a biased sample... [21:42:16] (The feedback is for the ratings feature, but quite a few people just pour their opinions about the article into it) [21:42:17] haha [21:42:21] Well I guess the point is [21:42:31] If you're like "this article sucks" [21:42:34] You're reading all the people who cared enough to comment. [21:42:46] We hit you with the socially acceptable version of "sofixit" [21:42:57] The en.wiki interface is completely un-user friendly. [21:42:57] Yeah, the feedback thing is biased, I realize [21:43:22] You could get more people involved with a hundred edits to the MediaWiki namespace than any CtA campaign, I think. [21:43:42] But that wouldn't involve features teams and shiny toys. :-) [21:44:03] I would much prefer cleaning up those messages, yes [21:44:19] But it needs a dedicated person to own it, someone who's not a stranger to the enwiki community [21:44:28] Because people will bitch when you change their precious MW: messages [21:44:36] Philippe seems rather free these days. Make him do it. ;-) [21:45:48] Nobody's asked the moral question yet, have they? [21:45:59] "the moral question"? [21:46:02] Is it moral to encourage people to try to edit this: http://en.wikipedia.org/w/index.php?title=Microsoft&action=edit [21:46:02] ( [21:46:04] ? [21:46:06] haha [21:46:21] Seems inhumane. [21:47:08] The bright red box at the top is a nice touch. [21:47:11] Seriously though, I think cleaning up MW: messages is a good idea, and should be proposed to TPTB at WMF. But it's enwiki-specific, folks might not like that [21:47:29] TPTB? [21:47:36] The Powers That Be [21:47:42] lolbbq [21:47:55] Come on, are you from the internet or not :D [21:48:22] en.wiki has the worst messages. [21:48:31] Most sites have the default, which are bland, but unoffensive. [21:48:40] inoffensive? [21:48:48] Defensive. [21:51:03] I wonder if there's a decent solution to the "Microsoft" problem. [21:51:13] Or a half-solution. [22:31:21] maybe the CtA for new registered users could lead towards editing their User:/Sandbox [22:34:26] ... that's an excellent idea. [22:34:57] i have to reboot. [22:59:07] *werdna waves [23:06:22] hey andrew. [23:13:45] TrevorParscal, I'm guessing there is little point doing any code cleanup on the jquery files is htere? [23:14:04] most of them are 3rd party libs [23:14:13] so it's best to just keep them up to date [23:14:16] that's what i'm meaning :) [23:14:30] fix it, bringing in the new version might just bring it back [23:14:36] so not worth the effort :) [23:32:11] wazzap jorm, Reedy, et al [23:32:15] hai [23:38:16] werdna, good sleep? [23:38:24] reasonably [23:38:36] home late again, up till 1:30 making european plans for a change [23:38:50] lol [23:39:12] girl in mannheim that I met on the train after re:publica wants me to visit [23:39:18] haha, really? [23:39:22] got her on facebook? [23:39:25] yeah [23:39:28] well, she found me [23:39:30] lol [23:39:31] andrew the player. [23:39:36] how many Andrews are there that work for Wikipedia? [23:39:39] i guess the "i work for wikipedia" line worked :P [23:39:54] That was a strange evening [23:40:07] the evening we discovered that brion can dance :P [23:40:11] xD [23:40:28] the polish girls want me to say hello as well, but gdansk is a bit further [23:40:39] haha [23:40:55] alcohol gives me super moves [23:41:02] or, i'll continue to believe that at least [23:41:11] I think the evening started with ^demon getting us all tequila shots [23:41:17] well, the re:publica part of it [23:41:46] the day started with me wondering whether I'd spend the evening at re:publica or on a plane [23:41:49] Yeah [23:41:53] Was it tequila? [23:41:59] I remember it being shots of something [23:42:25] I know I didn't get that drunk, but i really can't remember :P [23:43:04] well, it was April [23:43:08] mhmm [23:43:12] I've slept since then [23:43:18] Not well at times, but I've slept [23:43:23] It's hard for me to remember a specific drink that I had in Berlin :) [23:43:30] Haha [23:43:36] I remember weird stuff clearly quite well [23:44:31] werdna: you're going to Europe to visit a girl you met on a train? [23:44:34] daymn [23:44:58] pdhanda: I'm already in europe for fosdem [23:44:59] pdhanda, we followed her around berlin for a bit after :P [23:45:06] no, she followed us! [23:45:15] i thought she was taking us places? [23:45:24] *werdna shrugs [23:45:30] I think she got off at hour stop [23:45:31] our stop [23:45:36] cause we were also with a couple of pediapress staff [23:45:49] eva-mari(a?) [23:46:15] I thought she went somewhere else [23:46:21] ah [23:46:52] They were still there.. As we tried to go into that club over the river from the boat [23:46:59] yes, I remember that bit [23:47:16] es ziemlich kalt war [23:50:22] then I ran into them at Wikimania and it took me a while to remember them