IRC office hours/Office hours 2014-05-21

Language Engineering

Log

Time: 17:00-18:00 UTC

Channel: #wikimedia-office

Timestamps are in UTC.

00:14 <arrbee> #startmeeting Language Engineering monthly office hour - May 2014

00:14 <wm-labs-meetbot> Meeting started Wed May 21 17:00:14 2014 UTC and is due to finish in 60 minutes.  The chair is arrbee. Information about MeetBot at http://wiki.debian.org/MeetBot.

00:14 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.

00:14 <wm-labs-meetbot> The meeting name has been set to 'language_engineering_monthly_office_hour___may_2014'

00:28 <arrbee> Hello, Welcome to the monthly office hour of the Wikimedia Language Engineering team

00:34 <arrbee> Hi santhosh

00:50 <santhosh> Hi arrbee

01:11 <arrbee> My name is Runa. I am the Outreach co-ordinator for our team and will be hosting the session today

01:35 <arrbee> Our office hours are held every 2nd Wednesday of the month

01:53 <arrbee> We delayed it by a week this month as we were traveling

02:28 <arrbee> Before we go further here is an important message:

02:52 <arrbee> The chat today will be logged and publicly posted. It is also mentioned in the channel topic (above).

03:25 <arrbee> Our last office hour was held on April 9, 2014. The logs are at:

03:31 <arrbee> #link https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2014-04-09

04:07 <arrbee> aharoni kart_ divec Nikerabbit pginer santhosh are here today and will be answering questions

04:47 <arrbee> In today's session we would like to talk about our recent work and end with an open session for Q & A

05:37 <aharoni> сәлем

05:57 <arrbee> The Wikimedia Foundation's Language Engineering team builds language features and tools to support our wiki communities across the world

06:18 <arrbee> We are a distributed team and operate from various locations around the globe

06:56 <arrbee> As already mentioned in the mail I sent out earlier, we have been concentrating on the Content Translation tool and intend to make the first release very soon

07:27 <arrbee> We have mentioned the Content Translation project several times in our earlier office hours but we will talk more about it today

07:57 <arrbee> The Content Translation tool is a way to create new Wikipedia articles from existing articles in another language

08:05 <arrbee> Hi alolita

08:45 <arrbee> The tool is designed to have an editing interface and several translation aids like dictionaries, and machine translation support

09:12 <alolita> Hi Runa

09:22 <arrbee> The purpose of the tool is to help create an initial version of an article which can then be published and edited like any other article

09:48 <arrbee> The immediate benefits from this tool are:

10:19 <arrbee> 1.  the relative ease in quick article creation for both new and advanced users

10:46 <arrbee> 2. provide assistance to achieve high quality translations

10:47 <arrbee> and

10:57 <arrbee> 3. prevent errors

11:16 <arrbee> Development on this tool started in February, earlier this year

11:51 <arrbee> The initial phase of development was focused primarily on research and exploration of backend design choices

12:50 <arrbee> Over the past month we have narrowed down on the actual deliverables for the first release and the development plan to support this release

13:43 <arrbee> We do not have a specific release date just yet but are aiming for sometime in the next couple of months when we will be able to present this as a beta feature

14:36 <arrbee> Presently we are fully absorbed in development of key features for the first release (termed as "minimum viable product" or "MVP" in product speak)

15:04 <arrbee> (There was an interesting discussion about MVP in the ECT meeting yesterday) :)

15:40 <arrbee> Alongside we are collaborating with other teams on machine translation support, analytics and performance

16:03 <arrbee> Detailed designs are at:

16:12 <arrbee> #link https://commons.wikimedia.org/wiki/File:Content-translation-designs.pdf

16:32 <arrbee> The workflow we are creating will be:

17:01 <arrbee> 1. Show a red link in the interlanguage area for a missing language version of the displayed article

17:42 <arrbee> 2. Clicking the red link would display the Content Translation editor (for logged-in users only) and users can choose to translate the article or create it from scratch

18:18 <arrbee> 3. The editor displays 3 columns - source article text, target article text, tools column for the translation aids

18:40 <arrbee> 4. Translations are done in the editor by the logged-in user

19:28 <arrbee> 5. Using a publish button from the editor, a new version of the article in the target language is published under the user's namespace on the target language wiki

19:56 <arrbee> ^^ workflow is only for the first release i.e. MVP

20:41 <arrbee> We went for a simple REST style api that can easily be cached by Varnish

21:46 <arrbee> We are using a special presentation of the rich markup called LinearDoc to enable transfer of markup like bolds and links even if the word order is different in machine translation

22:25 <arrbee> We use the Parsoid service to get the translatable content in HTML, then we segment it and when saving we use Parsoid to convert it back to wikitext

22:43 <arrbee> divec: santhosh : would you like to add anything more about this?

23:43 <santhosh> https://www.mediawiki.org/wiki/Content_translation/Documentation has most of these technical details

25:00 <arrbee> Thanks santhosh

25:06 <alolita> that's helpful santhosh

25:29 <arrbee> (writing the link again in a bot-friendly way)

25:32 <arrbee> #link https://www.mediawiki.org/wiki/Content_translation/Documentation

25:55 <arrbee> As we go closer to the release date, we will step up on the communications

26:21 <arrbee> Until then the best place to track the project is:

26:26 <Pavanaja> Does this tool ties with Wikidata?

26:31 <arrbee> #link https://www.mediawiki.org/wiki/Content_translation

26:45 <alolita> Hi Pavanaja

26:51 <arrbee> Pavanaja: we intend to do so

26:51 <aharoni> Pavanaja: yes

26:54 <Pavanaja> Hi Alolita

27:29 <aharoni> Pavanaja: the plan is to release basic wikidata integration in the first deployment

27:32 <Pavanaja> Is this something lik a Translation Memory (TM) tool?

28:09 <aharoni> it will use wikidata to check whether it's possible to insert links to the target article in the target wiki automatically.

28:55 <arrbee> You could view the tool in action here:

28:58 <aharoni> so, for example, if you are translating from English to Telugu, and the English article has a link to Philosophy, and there is an corresponding article in Telugu, then the link to the Telugu article will be automatically inserted into the translation

29:05 <arrbee> #link http://language-stage.wmflabs.org/w/index.php?title=Special:ContentTranslation&page=Food&lang=es

29:16 <santhosh> (you need to login)

29:38 <aharoni> interlanguage links are stored in Wikidata, so this is a kind of Wikidata integration.

29:55 <aharoni> future development may have deeper Wikidata integration.

30:37 <aharoni> about Tranlsation Memory, this is not a translation memory tool; it is a translation tool that will include translation memory as one of its features.

31:08 <arrbee> Thanks aharoni for that neat summary

31:34 <arrbee> The development roadmap and timeline of milestone completion can be found at:

31:42 <arrbee> #link https://www.mediawiki.org/wiki/Content_translation/Roadmap

32:04 <arrbee> (This page is changing very rapidly though)

32:18 <arrbee> More questions?

35:36 <aharoni> just a little announcement

36:41 <aharoni> the "compact interlanguage links list" is currently broken in production because a of an incompatible core change

36:49 <Niharika> Oh.

37:02 <Niharika> I couldn´t figure out what broke it.

37:27 <aharoni> a core change in how the sidebar is handled in the Vector skin.

37:30 <aharoni> I already committed a fix, but it needs review and deployment.

37:42 <aharoni> https://gerrit.wikimedia.org/r/#/c/134592/

37:55 <Niharika> Thanks aharoni.

38:12 <aharoni> (leaving as "aharoni", staying as "aharoni|mobile")

39:20 <arrbee> Just in case there is some interest about the technical architecture of the Content Translation tool, you can find it here:

39:24 <arrbee> #link https://www.mediawiki.org/wiki/Content_translation/Technical_Architecture

39:47 <aharoni|mobile> Pavanaja, any more questions?

41:49 <arrbee> Okay… if there are no more questions we can wrap up early :)

42:38 <Pavanaja> I am waiting for the tool

42:49 <arrbee> #info Our next office hour is scheduled for 11 June 2014

43:01 <aharoni|mobile> Great to hear

43:23 <arrbee> Pavanaja: we will make sure to communicate about its arrival much in advance

43:35 <Pavanaja> Thanks RB

43:49 <arrbee> Meanwhile if you like you can look at the staging instance and give us feedback

43:58 <arrbee> :)

44:08 <aharoni|mobile> We are starting small, but we have further plans

44:47 <arrbee> Our mailing list is mediawiki-i18n@lists.wikimedia.org and IRC channel is #mediawiki-i18n

45:07 <aharoni|mobile> Like a "translation center", which will show suggestions for translation,

45:10 <arrbee> We will be around on #mediawiki-i18n

45:35 <aharoni|mobile> Statistics, management of existing translations, etc.

46:00 <aharoni|mobile> And more wikidata integration.

47:08 <aharoni|mobile> But for a start - a simple translation interface with basic tools.

50:40 <arrbee> Thanks aharoni|mobile

50:53 <arrbee> Thanks everyone for joining

51:13 <arrbee> The office hour ends here today (a tad bit early than usual)

51:29 <arrbee> The logs will be on meta very soon:

51:35 <arrbee> #link https://meta.wikimedia.org/wiki/IRC_office_hours

51:44 <arrbee> #endmeeting

Generated by MeetBot 0.1.4 (http://wiki.debian.org/MeetBot)

Discussion of square bounding boxes and type safe enums

Time: 21:00-22:00 UTC

Channel: #wikimedia-office

Timestamps are in UTC

[21:00:01] <sumanah>	 #startmeeting Discussion of square bounding boxes and typesafe enums| Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours

[21:00:01] <wm-labs-meetbot>	 Meeting started Wed May 21 21:00:00 2014 UTC and is due to finish in 60 minutes.  The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot.

[21:00:01] <wm-labs-meetbot>	 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.

[21:00:01] <wm-labs-meetbot>	 The meeting name has been set to 'discussion_of_square_bounding_boxes_and_typesafe_enums__channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours'

[21:00:05] <sumanah>	 #chair sumanah brion Tim-away

[21:00:05] <wm-labs-meetbot>	 Current chairs: Tim-away brion sumanah

[21:00:10] <sumanah>	 #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-05-21

[21:00:19] <sumanah>	 First, cscott :-)

[21:00:23] <sumanah>	 since yours should be faster

[21:00:31] <sumanah>	 #topic square bounding boxes

[21:00:39] <sumanah>	 #link https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes

[21:00:42] <sumanah>	 This should be quick

[21:00:45] <sumanah>	 #link https://gerrit.wikimedia.org/r/#/c/123683/ cscott is looking to get this merged :-)

[21:01:03] <sumanah>	 is that right C. Scott?

[21:02:04] <sumanah>	 #chair sumanah brion TimStarling

[21:02:04] <wm-labs-meetbot>	 Current chairs: Tim-away TimStarling brion sumanah

[21:02:14] * brion  double-checks the code�

[21:03:07] <brion>	 cscott: so as i understand this only affects the default case where somethingâ€™s specified as a thumb without a size spec?

[21:03:23] <brion>	 and sets a max height to match with the default thumb width

[21:04:05] <brion>	 iâ€™m pretty happy with that i think

[21:04:06] <brion>	 TimStarling: ?

[21:04:47] <TimStarling>	 I gave it +2 already, but then cscott changed the code substantially and I haven't gotten around to reviewing it again

[21:05:04] <TimStarling>	 if it looks good to you, just give it +2

[21:06:13] <brion>	 ok iâ€™ve done so

[21:06:18] <brion>	 letâ€™s make sure it runs its tests and whatnot :)

[21:06:28] <sumanah>	 Sweet

[21:06:42] <sumanah>	 #agreed to +2 https://gerrit.wikimedia.org/r/#/c/123683/

[21:06:52] <sumanah>	 rock, we can move on I think.

[21:06:56] <sumanah>	 #topic typesafe enums

[21:07:00] <sumanah>	 #link https://www.mediawiki.org/wiki/Requests_for_comment/Typesafe_enums

[21:07:04] <sumanah>	 #info Andrew Russell Green calls this "a facility that I've found really useful so far, and is used in other stuff that we'd like to propose moving to core :)"

[21:07:23] <sumanah>	 #info AndyRussG today seeks "I guess a general path forward for any changes required to merge this to core, or an opinion on the feasability threof"

[21:07:31] <brion>	 ok so i think typesafe enums are cute and sometimes nice, but i donâ€™t have a strong opinion

[21:07:31] <TimStarling>	 it looks slow

[21:07:32] <sumanah>	 #info Andrew says: "I'm sure there are improvements to be made (for example, see MWalker's suggestions on the talk page), so if we can consider what would need to be done, and end up with something really nice that improves MW code quality, I think that'd be fantastic"

[21:07:33] <cscott>	 sorry i'm late, what did i miss? ;)

[21:07:38] <cscott>	 all of my rfc!

[21:07:42] <TimStarling>	 cscott: brion merged your change

[21:07:43] <sumanah>	 yes!

[21:07:45] <brion>	 :D

[21:07:51] <bawolff>	 and then jenkins bot rejected..

[21:08:00] <^d>	 As I said on the list, I'm not a fan of enums. I don't make use of them in languages that have them natively, and implementing them in userspace seems slow per Tim.

[21:08:04] <cscott>	 probably because the release notes conflicted

[21:08:06] <TimStarling>	 quick, rebase before he changes his mind again

[21:08:09] <sumanah>	 #link http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076605.html - there have been some questions/discussion on the mailing list by hashar & ^d  & others

[21:08:27] <cscott>	 James_F thinks i should push to get this in 1.23

[21:08:35] <brion>	 so thereâ€™s a few different kinds of enums in the universe i think

[21:08:37] <cscott>	 but maybe we can return to discuss this after typesafe enums

[21:08:44] <brion>	 one is â€˜i really just need names for a couple flagsâ€™

[21:08:44] <sumanah>	 cscott: yeah, sounds good to me.

[21:08:57] <brion>	 one is â€˜i need user-friendly markers for id numbers that go in some API or databaseâ€™

[21:09:00] <cscott>	 also, https://gerrit.wikimedia.org/r/#/c/133600/ is the more contentious part of this, i'd like to discuss that as well

[21:09:03] <bawolff>	 Personally I'm not a fan of the syntax of having a $ in DayOfTheWeek::$TUESDAY (I know that's really superficial)

[21:09:06] <TimStarling>	 in HHVM, class constants are probably very heavily optimised

[21:09:07] <brion>	 and another is â€˜i need a code-only marker for various extensible enum list'

[21:09:10] * cscott  will shut up while we discuss enums�

[21:09:22] <TimStarling>	 since the JIT knows what the value of the class constant is when it is generating machine code

[21:09:28] <TimStarling>	 so it probably just uses the immediate value

[21:09:56] <TimStarling>	 so I don't think the "$" is superficial, it makes it a hashtable lookup instead of an immediate machine code operand

[21:10:11] <AndyRussG>	 Hmmmm :)

[21:10:21] <brion>	 do we tend to use enums in perf-critical code paths?

[21:10:25] <brion>	 (iâ€™m thinking parser/sanitizer)

[21:10:44] <AndyRussG>	 Also note that in this implementation nothing happens if the class isn't loaded

[21:10:44] <cscott>	 i guess one question is: are we moving to enums for better readability of infrequently used code, or are we moving to enums because we want blazing fast performance on the hot paths through our codebase

[21:10:54] <bawolff>	 I meant superficial from an aesthetic point of view

[21:10:57] <cscott>	 because the SplEnum implementation is almost certainly faster.  but not better for readability.

[21:11:16] <cscott>	 (although it would be nice to get benchmarks to verify my intuitions)

[21:11:34] <^d>	 SplEnum requires people installing a non-default pecl extension as bawolff pointed out on-list.

[21:11:34] <AndyRussG>	 Re: peformance I do think it'd be a matter of a tradeoff, and some benchmarking would be cool

[21:11:35] <cscott>	 i don't remember seeing wide-spread enums in the parser

[21:11:39] <^d>	 That's a -1 from my POV for it.

[21:11:58] <bawolff>	 ^d: I didn't point that out, but I agree I don't like that :)

[21:11:58] <sumanah>	 AndyRussG: https://www.mediawiki.org/wiki/Performance_profiling_for_Wikimedia_code might help you do a bit of benchmarking. Maybe.

[21:12:15] <cscott>	 well, a standalone microbenchmark would be my first pass

[21:12:26] <cscott>	 just to get a rough order of magnitude for the different enums

[21:12:40] <cscott>	 also, a standalone microbenchmark would probably be easier to run on HHVM

[21:12:41] <^d>	 bawolff: Sorry, Tyler, not you.

[21:12:47] <mwalker>	 a common usecase for enums is in function argument -- instead of having a bare TRUE / FALSE / NULL you have some explicit type

[21:12:49] <AndyRussG>	 Definitely ... Still if it's a trade-off between an extremely small performance difference and better and typesafe code, I'd take the latter

[21:13:11] <^d>	 mwalker: Well if you're passing boolean params to a function you're breaking coding conventions anyway :)

[21:13:12] <AndyRussG>	 For me the ability to to typehint is really nice

[21:13:49] <AndyRussG>	 The issue I have with SplEnum is it works quite differently from enums in other languages and is extra verbose

[21:13:59] <AndyRussG>	 #info http://www.php.net/manual/en/class.splenum.php

[21:14:31] <robla>	 I think Antoine may be the only one arguing for SplEnum, but I could be mistaken.  Anyone arguing for it here?

[21:14:41] <brion>	 not i, i donâ€™t like splenum much

[21:14:43] <^d>	 I don't think anyone's arguing for it.

[21:14:53] <AndyRussG>	 Cool

[21:14:55] <^d>	 I think Antoine was just like "hey maybe this?" not so much a strong advocate.

[21:15:05] <brion>	 so i think there are two questions

[21:15:14] <brion>	 one is: do we want to use this sort of facility widely?

[21:15:24] <brion>	 the other is: when folks do want to use it, should they use a common base class from core?

[21:15:31] <brion>	 -or implement separately in every ext?

[21:15:35] <cscott>	 nope, i like the new code.  but i'd like to get a little bit of insight into performance.

[21:15:45] <cscott>	 so that we know whether to recommend it for hot paths or not

[21:16:00] <cscott>	 gwiw, Parser->mOutputType is an enumerated type, but it's not on a hot path

[21:16:44] <cscott>	 Parser::setFunctionHook takes an enumeration too, again now performance-sensitive

[21:16:49] <TimStarling>	 __toString() should probably be included in the benchmark

[21:17:04] <AndyRussG>	 I can do benchmarks and add them to the RFC

[21:17:05] <TimStarling>	 since that suggested case syntax will call it

[21:17:20] <^d>	 brion: We'd have to ask more people if they want to use it widely.

[21:18:15] <AndyRussG>	 I think that most places where you use a class constant you could use something like this

[21:18:44] <TimStarling>	 SplEnum is PECL?

[21:18:47] <brion>	 so iiuc, basically proposal is to copy https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FCampaigns.git/e4714059330ace2c9c8457433919fb90ce1f4af5/includes%2FTypesafeEnum.php into core so people could use it

[21:18:54] <TimStarling>	 that kind of rules that out doesn't it?

[21:19:19] <brion>	 $ php maintenance/eval.php

[21:19:19] <brion>	 > return class_exists('SplEnum');

[21:19:20] <brion>	 bool(false)

[21:19:27] <^d>	 TimStarling: Yes.

[21:19:29] <brion>	 yeah letâ€™s kill SplEnum itâ€™s not there by default

[21:19:32] <AndyRussG>	 I think we could also add what mwalker suggests on the talk page, about setting a constant integer value for database, and some facilities for bitmask when desired

[21:19:50] <gwicke>	 quick side question: do you plan to discuss square bounding boxes for upright as well in this meeting?

[21:20:26] <^d>	 Already done.

[21:20:29] <^d>	 brion merged.

[21:20:40] <brion>	 gwicke: oh i think we forgot about that case â€” it might make sense to turn uprights into squares if the current patch doesnâ€™t do that

[21:20:44] <TimStarling>	 not for upright, just for default params

[21:20:51] <sumanah>	 gwicke: We're returning to the topic after the enums chat because there's more to discuss, now that cscott is around.

[21:20:52] <^d>	 Oh nvm, ignore me.

[21:21:41] <sumanah>	 it's ok! we were done until we were not :)

[21:22:36] <AndyRussG>	 re: the enums, I looked through a few other folks' implementations, seemed a lot of people are doing something similar, though I imagine it's not enough code to make worrying about an external library worth the effort

[21:22:54] <TimStarling>	 it probably won't be a hashtable lookup in HHVM, btw, I think it will just be dereferencing and Variant unboxing

[21:22:56] <cscott>	 square bounding boxes now?

[21:22:59] <gwicke>	 brion, TimStarling, sumanah: thx

[21:23:05] <cscott>	 i thought i could fix the rebase conflict before we got back to me

[21:23:15] <cscott>	 but i'm multitasking poorly

[21:23:27] <sumanah>	 are we done with the enums topic? can we have a couple #agreed or #action lines?

[21:23:49] <brion>	 #agreed not gonna use SplEnum - itâ€™s not available by default

[21:24:10] <brion>	 i think weâ€™re still kinda undecided on whether to put TypesafeENums class into core

[21:24:20] <brion>	 and even more undecided on whether to change any code to use it

[21:24:22] <AndyRussG>	 Is doing some benchmarks #agree-able?

[21:24:31] <brion>	 sounds good. TimStarling ?

[21:24:50] <TimStarling>	 #action AndyRussG to benchmark setup and access performance

[21:25:00] <AndyRussG>	 cool! :)

[21:25:03] * TimStarling  likes #action�

[21:25:08] <brion>	 \o/

[21:25:12] <sumanah>	 sweet

[21:25:25] <sumanah>	 ok, we can therefore move on to

[21:25:25] <AndyRussG>	 mwalker: you mentioned some other use cases before? should we look at those?

[21:25:25] <sumanah>	 #topic square bounding boxes redux

[21:25:26] <MartijnH>	 from what TimStarling was saying earlier, HHVM benchmarks are also desirable?

[21:26:03] <mwalker>	 well; if we dont want to use this for performance critical code then it doesn't make much sense

[21:26:12] <mwalker>	 but I had suggested use cases of namespaces and permissions

[21:26:32] <AndyRussG>	 MartijnH: I can also try HHVM benchmarks

[21:26:35] <sumanah>	 #info <cscott> also, https://gerrit.wikimedia.org/r/#/c/133600/ is the more contentious part of this, i'd like to discuss that as well

[21:27:01] <TimStarling>	 hhvm is pretty easy, now that they have packages on hhvm.com

[21:27:18] <AndyRussG>	 Ah cool plums

[21:27:22] <TimStarling>	 just run "hhvm -f benchmark.php" instead of "php benchmark.php"

[21:27:47] <TimStarling>	 or "hhvm -v Eval.Jit=true  -f benchmark.php" to be sure the JIT is enabled

[21:27:48] <cscott>	 sigh rebasing fail, i managed to add https://gerrit.wikimedia.org/r/#/c/134734/, boo me

[21:28:06] <gwicke>	 so I'm not convinced that upright has much of a use case left with square bounding boxes

[21:28:29] <AndyRussG>	 TimStarling: thanks

[21:28:30] <gwicke>	 the only use case would be resizing images relative to a user's default thumb size preference

[21:29:18] <TimStarling>	 hmm

[21:29:19] <gwicke>	 which might be better covered by introducing more semantic alternate image types

[21:29:26] <TimStarling>	 you know this change that cscott is merging...

[21:29:36] <TimStarling>	 will that make the site go down when it is deployed?

[21:29:42] <cscott>	 what?

[21:29:44] * TimStarling  always thinks of these things too late�

[21:30:05] <TimStarling>	 well, how many thumbnails do you suppose will be regenerated?

[21:30:11] <AndyRussG>	 mwalker: (aside: still enumish: got more details, maybe to put on the talk page or send elsewhere? thanks btw)

[21:30:42] <cscott>	 TimStarling: the non-square ones, i guess.

[21:30:44] <TimStarling>	 better make sure Greg and Sam know about it I guess

[21:30:49] <cscott>	 we could probably pre-generate them.

[21:30:57] <cscott>	 i could give you exact statistics

[21:31:17] <cscott>	 i have a db of all figure usage on en/fr/it/de/.. wikis

[21:31:31] <TimStarling>	 the question is whether the image scalers or swift backend will fall over when it is deployed to en or commons, due to increased rate of scaling operations

[21:32:28] <cscott>	 ok, patches are rebased, so i can devote brain cells to discussion

[21:32:41] <cscott>	 i think it would be a good idea to pre-scale as many images as possible

[21:33:02] <cscott>	 i can generate a list of all images on enwiki (say) that would change size as well as the new size

[21:33:25] <TimStarling>	 you think it won't be too difficult to generate that list?

[21:33:25] <cscott>	 i should just be able to ask mw for those thumbs in the new size to seed them in swift

[21:33:25] <cscott>	 no, less than an hour

[21:33:27] <AaronSchulz>	 ^d: is mwgrep on the expanded text or the source text?

[21:33:29] <TimStarling>	 ok, sounds good then

[21:33:31] <cscott>	 it's a good segue to the *next* topic

[21:33:48] <^d>	 AaronSchulz: Expanded. We don't store unparsed wikitext.

[21:34:04] <^d>	 (yet. maybe?)

[21:34:12] <cscott>	 since i wrote that code/assembled that db in order to show that https://gerrit.wikimedia.org/r/133600 would be safe

[21:34:25] <cscott>	 see https://bugzilla.wikimedia.org/show_bug.cgi?id=63904 for a link to the code, and statistics

[21:34:33] <cscott>	 that part of the patch affects far fewer images

[21:35:49] <gwicke>	 I gave my opinion on that earlier in this meeting

[21:35:54] <cscott>	 swift stuff lasts forever, right?  so i can start requesting the new sizes for the thumbnails now, regardless of the deployment/merge time of the patch.

[21:36:28] <TimStarling>	 yes

[21:36:34] <cscott>	 let's sync up -- so are we still talking about 'thumbs with no explicit size should use a square bounding box (that's https://gerrit.wikimedia.org/r/123683)

[21:36:41] <cscott>	 let's finish up that part

[21:36:49] <cscott>	 the patch has been rebased

[21:37:17] <cscott>	 my understanding is that someone will +2 it, and i will asap start a process to start requesting thumbs that change size, so that changeover will not be drastic

[21:37:41] <cscott>	 and someone (?) will inform greg and sam, so we all know what's going on before the code goes live?

[21:37:47] <TimStarling>	 last meeting we had "ACTION: cscott to patch upright to have a square bounding box, and use dumpGrepper to see whether this breaks too much (cscott, 21:59:55)"

[21:38:09] <cscott>	 TimStarling: that's the next part.  i'm just trying to make sure we're all on the same page regarding the first part.

[21:38:12] <cscott>	 before we move on

[21:38:51] <cscott>	 first part being "thumbs with no explicit size" (upright flag semantics unchanged)

[21:39:21] <cscott>	 ok?  my summary above is correct for the first part?

[21:39:41] <cscott>	 sumanah: you want to add some # actions?

[21:39:51] <TimStarling>	 greg-g: for changes that need to be deployed carefully, I'm meant to add you as a reviewer, right?

[21:40:28] <gwicke>	 I think we pretty much agree that with the right preparations the move to square bounding boxes for bare thumbs is a good idea

[21:40:46] <greg-g>	 TimStarling: that's good yeah, what are you thinking of?

[21:40:50] <greg-g>	 ie: how carefully? :)

[21:41:21] <greg-g>	 TimStarling: ah, I see in -dev

[21:41:27] <TimStarling>	 load on swift and image scalers needs to be watched, since thumbnailing parameters will change

[21:41:30] <cscott>	 well, at a minimum you should probably check with me to ensure that my job to pregenerate the new image thumbs has completed?

[21:41:39] <AndyRussG>	 be vewy vewy quite

[21:41:56] <AndyRussG>	 quiet

[21:41:58] <TimStarling>	 if there is an overload, it should be rolled back

[21:42:09] <greg-g>	 gotcha

[21:42:35] <greg-g>	 cscott: can we chat post this discussion re deploy details?

[21:42:36] <cscott>	 other than me writing a script to try to pregenerate images, is there any other possible deployment strategy to mitigate?

[21:43:01] * sumanah  wants to leave #action items to others to decide�

[21:43:11] <cscott>	 greg-g: sure.

[21:43:52] <cscott>	 and maybe it should be flagged in the release notes more prominently that this will have affect on scaler load?

[21:44:04] <greg-g>	 cscott: sounds good

[21:44:14] <cscott>	 #action https://gerrit.wikimedia.org/r/123683 expected to be +2'd

[21:44:30] <cscott>	 #action cscott will work with greg-g to ensure no deployment hiccups

[21:44:40] <cscott>	 #action cscott will write a script to pre-generate thumbnails that will change size, to avoid scaler load

[21:45:19] <cscott>	 ok, are we done with that then?

[21:45:52] <gwicke>	 I believe so

[21:45:54] <cscott>	 now we can start the screaming and yelling ;)

[21:46:00] <gwicke>	 let's move on

[21:46:06] <cscott>	 so the second part makes 'upright' simultaneously more and less useful

[21:46:22] <cscott>	 https://gerrit.wikimedia.org/r/#/c/133600/ and https://bugzilla.wikimedia.org/63904 for those following along at home

[21:46:31] <cscott>	 it makes 'upright' also use a square bounding box.

[21:46:49] <cscott>	 so that it actually is useful for upright images, and doesn't require the user to manually specify the aspect ratio of the image

[21:47:17] <cscott>	 Something like 0.75% of the images on enwiki use the 'upright' flag

[21:47:26] <cscott>	 this would change the size of 0.04% of the images

[21:47:42] <gwicke>	 it'd be a mis-named 'scale' option, which scales relative to the user / wikis's default thumb size pref

[21:47:55] <cscott>	 since the number of images whose size changes is so small, it is proposed to reset the scale factor to 1.0 at the same time, which makes upright's semantics much less mysterious

[21:48:19] <cscott>	 (changing the default scale changes about 110 image references on enwiki)

[21:48:57] <cscott>	 yes, the semantics of upright would be pretty much "scale", and one might consider in the future adding an alias.  but i'd rather upright go away entirely the the future. ;)

[21:48:58] <subbu>	 cscott, how many on frwiki use that flag?

[21:49:09] <cscott>	 it's in the bugzilla

[21:49:28] <subbu>	 because i remember reading on ve-feedback page that upright is popular/encouraged on frwiki

[21:49:49] <cscott>	 17,870 of 1,242,985 images use 'upright' and the proposed change would alter the size of 1049 or 1053 of them.  (the latter if the scale factor was changed to 1.0)

[21:50:08] <cscott>	 on frwiki

[21:50:42] <cscott>	 for dewiki, it's 38,624 of 1,786,779 and the size would be altered for 1963/1764

[21:50:52] <cscott>	 while i'm copying numbers into chat ;)

[21:51:06] <TimStarling>	 can anyone explain to me why upright isn't the stupidest thing ever?

[21:51:09] <cscott>	 so deploying this one should be a breeze, at least. ;)

[21:51:17] <subbu>	 :)

[21:51:23] <gwicke>	 TimStarling, that'd be hard

[21:51:30] <cscott>	 TimStarling: i think both gwicke and i agree that upright is stupid.

[21:51:44] <TimStarling>	 who approved it?

[21:51:49] <cscott>	 this patch makes it slightly less stupid.  at least it has some sensible semantics (scales the default thumbnail size)

[21:52:11] <cscott>	 instead of being some completely weird thing that i don't want to write a bunch of special-case code for in parsoid

[21:52:19] <gwicke>	 to me the interesting bit is that there are very few uses of the scale factor

[21:52:26] <cscott>	 (actually, that i've already written a bunch of special-case code for in parsoid, multiple times)

[21:52:32] <TimStarling>	 the help says "When the height of an image in thumbnail is bigger than its width (i.e. in portrait orientation rather than landscape) and you find it too large, you may try the option upright=N, where N is the image's aspect ratio (its width divided by its height, defaulting to 0.75)."

[21:52:39] <gwicke>	 most non-scale factor uses will basically be made unnecessary by square bounding boxes by default

[21:52:50] <cscott>	 gwicke, no i think you are misinterpreting the statistics

[21:53:10] <TimStarling>	 if you do that, calculate the aspect ratio and use that as the upright factor, that is equivalent to a square bounding box, correct?

[21:53:40] <gwicke>	 cscott, you don't break out the explicit factors vs. those using the default

[21:53:54] <gwicke>	 but in my experience the explicit factor is very rare

[21:54:15] <TimStarling>	 but without an explicit factor, upright is just equivalent to multiplying the width by 0.75

[21:54:28] <cscott>	 i think the ones which change size when the default scale factor is tweaked are the ones without an explicit scale factor.

[21:54:28] <cscott>	 that's like 110 images on enwiki.

[21:54:28] <cscott>	 so i think most upright images do actually have a scale factor.

[21:54:28] <cscott>	 i can crunch the exact numbers for you if you like.

[21:54:28] <cscott>	 TimStarling: i wrote that help text, i think.

[21:54:33] <cscott>	 the previous help text was much less helpful, and stated behavior that differed from the implementation

[21:55:01] <cscott>	 TimStarling: yes.  multiplying the width by 0.75 is useful if all your images are either 4:3 or 3:4

[21:55:18] <cscott>	 so upright w/o a scale factor gives you 4:3 images that are 'the right size' next to the rest of your 3:4 images

[21:55:29] <cscott>	 are least that's my reverse-engineering of the logic

[21:55:33] <cscott>	 *at least

[21:55:45] <gwicke>	 afaik the factor was added later

[21:55:48] <gwicke>	 which also explains the weird name

[21:56:30] <gwicke>	 cscott, so I think it would be good to have data on how common the scale is actually set explicitly

[21:56:30] <TimStarling>	 but images are typically not one of those two aspect ratios

[21:56:43] <cscott>	 anyway, i think this patch is worth merging, because it affects very few images, and at least gives us semantics for 'upright' that don't require the user to manually compute aspect ratios.

[21:57:14] <cscott>	 gwicke: i can compute that, but i'm curious why you want to know.

[21:57:26] <gwicke>	 if there are few uses with explicit scale factors then I'd prefer to just deprecate upright

[21:57:44] <gwicke>	 since it'll be much less useful

[21:57:48] <TimStarling>	 upright with a specified width seems kind of pointless

[21:57:51] <gwicke>	 and mis-named as well

[21:57:56] <cscott>	 there are 37,185 uses of upright on enwiki

[21:58:03] <TimStarling>	 since you could just multiply the specified width by the scale factor and omit upright

[21:58:05] <cscott>	 we could deprecate it, but probably not without tool assistance

[21:58:22] <cscott>	 upright is ignored if there is a specified with.

[21:58:24] <cscott>	 *width

[21:58:28] <cscott>	 there are parser tests for that

[21:58:33] <TimStarling>	 right...

[21:58:54] <gwicke>	 the original use case for upright will disappear with square bounding boxes

[21:58:58] <cscott>	 it's only use is scaling the "default size" of the thumbnail (which might be user-specified)

[21:58:58] <TimStarling>	 without a specified width -- at least it does something unique

[21:59:34] <cscott>	 (and by user specified i mean in the user's preferences, not in wikitext)

[21:59:41] <TimStarling>	 well, the question is whether people actually want square bounding boxes or if they want their images to be shrunk by some arbitrary factor

[22:00:04] <TimStarling>	 the rounding to the nearest 10px is pointless, right?

[22:00:25] <cscott>	 TimStarling: i think the real missing feature is a 'scale and crop' option that will give me an exactly XxYpx image if i ask for one, cropping the edges as needed.  but that's a different patch set.

[22:00:29] <TimStarling>	 it doesn't actually reduce the number of generated images, like it claims

[22:00:42] <gwicke>	 the 0.75 default combined with the then-common 3:4 aspect ratio suggests that they wanted the equivalent of square bounding boxes

[22:00:49] <cscott>	 it is probably pointless, yes.

[22:01:38] <TimStarling>	 gwicke: but square bounding boxes already existed

[22:01:45] <TimStarling>	 at least for specified widths

[22:01:56] <gwicke>	 yeah, but not for a bare 'thumb'

[22:02:18] <TimStarling>	 if that's what they wanted, it would have been trivial to implement

[22:02:27] <gwicke>	 remember that upright is only used if there are no explicit dimensions

[22:02:28] <cscott>	 since the user's preferred thumbnail size was variable, it was formerly impossible to get "a square bounding box of the user's preferred thumbnail size"

[22:02:32] <TimStarling>	 at the place where the 0.75 factor is applied, the aspect ratio is loaded and trivially available

[22:02:49] <cscott>	 i believe it was a short-sighted design originally

[22:03:08] <cscott>	 that probably implemented what the user asked for, without pausing to think about what the user actually wanted.

[22:03:17] * gwicke  nods�

[22:04:14] <gwicke>	 if we were to design a scale option relative to the default size from scratch, how would we go about it?

[22:04:33] <cscott>	 (the current patch 133600 includes the 'round width to 10px' behavior, but i would be happy to take that out.)

[22:04:47] <TimStarling>	 well, I would call it "scale", not "upright", for a start

[22:04:51] <cscott>	 gwicke: we wouldn't.  we'd take scaling decisions out of the user's hands and add semantic classes for images instead

[22:05:16] <gwicke>	 TimStarling, cscott: +1 to both of you ;)

[22:05:22] <Cloakedcitizen>	 hey folks

[22:05:33] <TimStarling>	 but I think we would want to consider very carefully whether such a feature is needed at all

[22:05:35] <cscott>	 We can make scale an alias for upright w/o breaking the 37k existing uses

[22:05:53] <cscott>	 even better, i could rename the option to 'scale' in the source and docs, and include 'upright' as the alias

[22:06:07] <TimStarling>	 if someone asked me for it out of the blue, I would probably say no

[22:06:15] <TimStarling>	 I probably did, that's why I don't know anything about it ;)

[22:06:18] <gwicke>	 cscott, thumb|upright could just become a no-op with square bboxes

[22:06:24] <cscott>	 but my personal preference is *not* to add scale, because i think the long term plan is to get rid of upright, not legitimatize it

[22:06:50] <gwicke>	 the only interesting case would be upright with an explicit factor

[22:07:06] <TimStarling>	 what about deprecating and ignoring the parameter to upright?

[22:07:06] <cscott>	 gwicke: actually, with upright's scale factor set to 1.0 by default, making upright a no op would probably be not too different.

[22:07:37] <cscott>	 i can re-run the numbers for (a) what if we just ignore 'upright entirely' and (b) what if we ignore the scale factor -- but isn't (b) equivalent to (a)?

[22:07:45] <TimStarling>	 we should find out who requested this feature and who implemented it

[22:07:52] <cscott>	 i think upright already requires 'thumb' to also be specified, or it has no effect.

[22:08:03] <cscott>	 git blame will tell you that, i bet.

[22:08:25] <gwicke>	 cscott, at the minimum we should probably ignore a bare upright with thumb

[22:08:38] <gwicke>	 as the square bbox should take care of that

[22:08:41] <cscott>	 i think setting the default upright scale factor to 1.0 has that effect.

[22:08:44] <TimStarling>	 whoever it was should be included in the discussion

[22:08:58] <cscott>	 (with my patch.  without my patch, thumb|upright gives you a non-square bbox)

[22:09:13] <gwicke>	 yeah, it works out to the same

[22:10:17] <gwicke>	 so I think we'd all prefer to get rid of upright if possible, at least in the longer term

[22:10:19] <TimStarling>	 we could deprecate upright completely, and start discussions with whoever requested the feature in the first place about what they really need

[22:10:44] <TimStarling>	 but like I say, they should be included

[22:10:48] <cscott>	 i'm trying to determine who that is from git-blame, but it's been hidden by layers of patches

[22:11:01] <cscott>	 it was added before oct 2010, that's all i can say at the moment

[22:11:42] <TimStarling>	 let's end this meeting, since we're out of time, we can talk about it later

[22:11:55] <cscott>	 in the interest of moving things forward, i think that merging my patch would still be a good first step to deprecating upright. ;)

[22:12:14] <TimStarling>	 noted

[22:12:15] <cscott>	 since the scale=1.0 feature then makes bare upright a no-op

[22:12:21] <gwicke>	 #action cscott to do some git archeology to figure out the original author of upright, so that we can include him/her in the discussion

[22:12:47] <TimStarling>	 #endmeeting

Executive director

[23:29:27] <philippe>	 OK, folks... it's about that time, shall we get started? :-)

[23:30:09] <philippe>	 Welcome to office hours... today we have with us Lila Tretikov, who is the incoming Executive Director of the Wikimedia Foundation, and therefore my (and many of the people here) new boss. :-)

[23:30:35] <lilatretikov>	 Hi everyone -- really excited to be here and meet all of you!

[23:30:37] <philippe>	 Lila, you wanna hello, or impart sage words or anything like that? :)

[23:31:06] <philippe>	 I think we'll be casual and informal as much as possible today, so I'm not going to queue up questions for Lila... so if you have them just shout them out.

[23:31:26] * Krenair  waves�

[23:31:39] * karma  says hi�

[23:31:41] <lilatretikov>	 hihi... cool to be back on IRC again. it has been a while :)

[23:31:57] <philippe>	 So, Lila.... since they're being shy today....

[23:32:06] * lfaraone  welcomes lilatretikov , and congratulates philippe on coming back to IRC, if only for a brief time.�

[23:32:09] <philippe>	 What do you think about the WMF after your first couple of weeks with us? :)

[23:32:17] * philippe  thwaps lfaraone  :-)�

[23:32:18] <Risker>	 what have you found most exciting so far, and and the most worrisome?

[23:32:28] <sDrewth>	 Suppose an opening question is about your approach: transactional or transformational?

[23:32:34] <marktraceur>	 lfaraone: You tell 'im

[23:32:35] <lilatretikov>	 i love the people and the community -- i just started meeting some of you

[23:32:54] <lilatretikov>	 and i cannot stop talking about it

[23:33:02] <lilatretikov>	 i think people think i am too excited

[23:33:19] <lilatretikov>	 but it is trully incredible to see how passionate people are about wikipedia first-hand

[23:33:23] <karma>	 :P

[23:33:43] <karma>	 Yeah, wikimedia has dedicated editors. :)

[23:33:45] <lilatretikov>	 that said there are some adjustments i am going through as well :)

[23:33:58] <philippe>	 Risker's question first....

[23:34:05] <philippe>	 MOst exciting, and most worriesome :)

[23:34:08] <lilatretikov>	 exciting: the people, both at the wmf and the community

[23:34:47] <lilatretikov>	 worrysome: trends, diffeculty of maintaining focus with a mission this large, some community dynamics

[23:35:28] <philippe>	 sDrewth is up next

[23:35:30] * marktraceur  would like to hear more about what trends are most worrisome but thinks it would count as a separate question�

[23:35:42] <lilatretikov>	 Hi sDrewth... I think it depends on what we are talking bout

[23:35:47] <philippe>	 Mark you're up next then.  :)

[23:35:51] <marktraceur>	 Righto

[23:36:12] <lilatretikov>	 some things will be transwormational as we embark on our strategy development in the different part of the lifecycle of our project

[23:36:56] <lilatretikov>	 others are highly operational/transactional... for example improving how we improve software manufacturing process :)

[23:37:12] <lilatretikov>	 i think we need to think at both levels

[23:37:32] <philippe>	 marktraceur asks about worrisome trends...

[23:37:45] <lilatretikov>	 hi marktraceur -- it's a bit early for me to tell -- i am coming up to speed and digging into the data.

[23:37:48] <lilatretikov>	 but at the high level

[23:37:52] <marktraceur>	 I imagine the "Oh shit" graph is one, but I'm curious if there are more

[23:38:05] <marktraceur>	 (the editor decline)

[23:38:17] <lilatretikov>	 i don't like seing the drivative on our editor and uniques chart flat or negative

[23:38:52] <lilatretikov>	 but i stil need to understand more

[23:39:01] <philippe>	 That's all the questions so far.... anyone else have any thoughts?  Or are we going to be forced to listen to Risker sing for us?

[23:39:16] <Risker>	 I sing very well, Philippe

[23:39:20] <marktraceur>	 There are worse fates

[23:39:23] <chrismcmahon>	 lilatretikov:  apropos of software delivery, I imagine you are involved in the search for the new Vice President of Engineering, and I'd be interested in your opinion of that role and how we're filling it (btw, we haven't met, I'm the QA guy in Tucson AZ)

[23:39:27] <lilatretikov>	 the way we are looking at the data needs to be more wholistic -- i.e. include mobile for example

[23:40:08] <philippe>	 thanks, Chris, she's working on that one now :)

[23:40:23] <lilatretikov>	 hi chrismcmahon -- i am involved, but it needs to be the team's decision.

[23:40:38] <RichardNevellWMU>	 Holistic in what way, may I ask? (aside from mobile)

[23:40:41] <lilatretikov>	 i am looking to provide guidance and clarity on what that role's primary focus needs to be

[23:40:52] <lilatretikov>	 so we evaluate against the same criteria

[23:41:40] <lilatretikov>	 RichardNevellWMU -- we need to look at all of the channels that contribute towards the number individually and together

[23:41:43] <Guest38632>	 Lila, could you please define the Wikipedia community? Thanks.

[23:42:08] <lilatretikov>	 so for example...

[23:42:12] <philippe>	 Guest38632: nothing like an easy one, huh?  That's maybe the hardest question around.... I've been trying for years :)

[23:42:18] <brion>	 :)

[23:42:53] <lilatretikov>	 if we look at the contribution funnel we want to make sure we account for: regions/locations, form factors.

[23:43:07] <lilatretikov>	 types of contributions

[23:43:09] <lilatretikov>	 etc.

[23:43:37] <philippe>	 Moving on to the question from Guest28632, the definition of the Wikipedia community.

[23:44:41] <lilatretikov>	 hi Guest38632 -- to me wikipedia community as a whole represents all of our audiences: both readers and editors, both contribute to our mission

[23:44:58] <SB_Johnny>	 "lilatretikov: if we look at the contribution funnel we want to make sure we account for: regions/locations, form factors" What does that mean? (Feeling buried by jargon)

[23:45:14] <philippe>	 SB_Johnny: thanks, you're up next :)

[23:45:21] <lilatretikov>	 but each group has unique perspecitves and needs... and within those two there are differences as well

[23:46:21] <lilatretikov>	 SB_Johnny sorry: where people are, what devices are they using, what browsers, how do they get to the point at which they make an edit -- is that better?

[23:46:44] <SB_Johnny>	 lol. yes, much better!

[23:46:45] <kmaher_>	 hehe I understood it better. :)

[23:47:04] <lilatretikov>	 sorry -- it's hard for me to tell -- some questions are pretty technical!

[23:47:17] <lilatretikov>	 so here are some questions for you:

[23:47:49] <lilatretikov>	 what do you love most about wikipedia, what are you troubled by most

[23:47:59] <lilatretikov>	 where do you think is our biggest opportunity

[23:48:11] <philippe>	 OK, the lady asked some questions, who's gonna take a stab at some answers? :)    c'mon lfaraone, you're being quiet, which usually means you're plotting something....

[23:48:13] <sDrewth>	 lilatretikov:  some of us prefer other parts than the P 'wikiPedia'

[23:48:20] <marktraceur>	 Yeah

[23:48:37] <sDrewth>	 the WP become too much of a bitch fight :-/

[23:48:48] <sumanah>	 The thing I love most about the Wikimedia movement is that I can help everyone and that everyone can help me

[23:48:49] <marktraceur>	 I was about to say something like "I'm a little worried that you're only asking about Wikipedia"! But I'm biased :)

[23:48:50] <lilatretikov>	 sDrewth tell me more.. what do you mean?

[23:48:51] <Risker>	 I think that could be described as "almost everyone can find their niche", sDrewth

[23:48:55] <Guest38632>	 OK, then let me please to rephrase my question. Lila, how many members of the Wikipedia Community should take a part in voting (any voting) to call the result of this voting "the action of the community"? Thank you.

[23:49:00] <karma>	 lol billing

[23:49:00] <lilatretikov>	 remember I am new -- need context

[23:49:31] <sDrewth>	 <- primarily  a wikisourcer (and a steward)

[23:49:31] <philippe>	 So, Guest39632, thanks, I've got that lined up.... as soon as weve seen some answers to Lila's questions, we'll get to that one. : )

[23:49:41] <karma>	 lilatrettikov: I think he means that there's more to the wikimedia than wp

[23:49:45] <karma>	 yeah

[23:50:30] <Risker>	 I think that Wiki(p)(m)edia is becoming increasingly conservative and inflexible in its community, which is the antithesis of the founding principles

[23:51:13] <MileSR>	 my loving is opportunity to do something to the word. to share and help as well to learn thinks

[23:51:15] <philippe>	 She's typing away :-)

[23:51:27] <lilatretikov>	 sDrewth -- yes i agree... i still use it a bit interchangebly, but i am learning how different parts of the commnity identify with the projects

[23:51:29] <RichardNevellWMU>	 In response to Lila's question, what I love most about Wikipedia is the positive feedback article writers get sometimes from readers. For me, one particular  occasion comes to mind, and I hope that other article writers have had that moment where they feel they're people learn. Few things are more motivating.

[23:51:51] <RichardNevellWMU>	 *they're helping

[23:52:02] <sDrewth>	 lilatretikov: don't take me wrong, I have broad rights and broad contributions. I just prefer the lesser politics of the smaller communities

[23:52:19] <lilatretikov>	 my question is relevant to the movement as a whole, our biggest potential may be with one of the sister-projects

[23:53:32] <lfaraone>	 lilatretikov: I love that we have a community that is so driven to create high-quality content, as showcased by the featured articles/pictures that serve as a constant reminder that I could always be a better writer.

[23:53:32] <lfaraone>	 In terms of troubles, my focus has been mostly from a process standpoint; I worry that the processes that require participants with community trust (administrators, functionaries, ArbCom etc) will simply fail to scale, and the process quality will decline. (I'm speaking from looking at the English Wikipedia; I admit I'm not familiar with how backlogged e.g.

[23:53:32] <lfaraone>	 Commons is, but every time I look things seem to have mostly kept in check)

[23:53:32] <Krenair>	 I quite dislike the 'wikipedia vs. sister-projects as a group' thing. Wikipedia should be given equal weight to each of the 'sister projects' :/

[23:53:54] <marktraceur>	 ++Krenair

[23:54:10] <Jasper_Deng>	 (++ too)

[23:54:28] <chrismcmahon>	 Wiki(m/p)edia has a remarkable mission, that is remarkably easy to share with others and that others recognized immediately, only if superficially.  OTOH, academics and such recognize and promote the mission in highly sophisticated ways.

[23:54:47] <philippe>	 We're furiously reading over here, folks, thanks for your opinions.... for those who are just joining us, Lila is asking what we lovea bout the projects, and what the biggest risks are...

[23:54:47] <Jasper_Deng>	 Being part of it is just a cool feeling

[23:54:51] <lilatretikov>	 Krenair, marktraceur , Jasper_Deng -- if everything is equal weight -- how would you prioritize?

[23:55:03] <sDrewth>	 while they are the flagship as the public votes, they tend to fix the poicy, sometimes to the detriment of the sister projects

[23:55:11] <sDrewth>	 policy

[23:55:23] <sDrewth>	 paid editing policy was one example

[23:55:24] <Jasper_Deng>	 What seems to be happening is that enwiki seems to get the most attention because I'd imagine most of our donations are because we're known for enwiki

[23:55:33] <marktraceur>	 lilatretikov: Prioritise things that have broad effect, then things that have the most effect in order, IMO - there's a much longer definition to be laid out, but it's definitely possible

[23:55:34] <lilatretikov>	 Guest38632 -- not sure yet, and I think probably depends on a specific project in question and its audience

[23:55:44] <lfaraone>	 Jasper_Deng: granted, it also has the pageviews.

[23:56:15] <lfaraone>	 (Not saying that is the correct approach, I just don't think its purely a donation-generation prioritisation)

[23:57:48] <Andreas_>	 Improvement potentials: 1. WMF is not doing enough to measure content quality. 2. Volunteers have asked for help with child protection; nothing has been done.

[23:58:46] <Guest38632>	 Lila, you do understand that  the actions of that community of mostly anonymus users  have great potentials to destoy people lives both the editors and the subject of BLPs?

[23:58:50] <lilatretikov>	 marktraceur -- i agree with broad effect/reach. but prioritization by definition means that something gets attention, and something else does not. just want to be clear on that.

[23:58:58] <Jasper_Deng>	 Another thing I think should be done is more reach out to high schools and colleges about how to use Wikipedia to do research.

[23:59:35] <marktraceur>	 lilatretikov: Sure, I think there's enough to go around that WP doesn't wind up looking like our only priority, but at the same time I'm aware that WP is a huge part of our priorities for good reason :)

[23:59:48] <marktraceur>	 Whether equal weight means equal prioritisation, I'm not sure

[00:00:01] <Andreas_>	 3. Problems with biographies of living people/revenge editing (opt-out for marginally notable people? pending changes?)

[00:00:22] <Guest38632>	 Philippe, would transcript of that communication be availabale online, and if so where? Thanks.

[00:00:35] <Jasper_Deng>	 Guest38632: the channel is logged

[00:00:45] * Jasper_Deng  doesn't remember where�

[00:00:48] <karma>	 Jasper_Deng: I know for a fact that doesn't work in my school, seeing some teachers (this may apply for more than one school) find wikimedia (Mainly Wikipedia) unreliable. This is because it's open-source and everyone can edit.

[00:00:50] <bawolff>	 http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140521.txt

[00:00:58] <Andreas_>	 4. Ensuring movement resources are spent in a way that benefits the projects/end users

[00:01:04] <lilatretikov>	 Andreas_ -- thanks, helpful for me to look into more and understand

[00:01:09] <Risker>	 I think sDrewth has a very good point about the paid editing stuff, which can actually be quite harmful to some of the sister projects - Commons in particular, where we have a huge number of professionals who share their images there, complete with link to their commercial sites

[00:01:11] <philippe>	 Guest38632, what communication?

[00:01:12] <jamesofur>	 they will be posted at the link in the topic

[00:01:18] <Andreas_>	 (4. is something something Sue has commented on before)

[00:01:20] <Jasper_Deng>	 karma: My feelings are that Wikipedia can be used for research if done properly

[00:01:22] <jamesofur>	 (the meta IRC Office hours page)

[00:01:29] <Jasper_Deng>	 specifically, people should only rely on reliably cited statements

[00:01:39] <Guest38632>	 Evrything that we are discussing now of course

[00:01:43] <karma>	 Jasper_Deng: I agree, but some people don't realize that.

[00:01:57] <Jasper_Deng>	 more reachout needed that means

[00:01:57] <marktraceur>	 Guest38632: Yeah, see https://meta.wikimedia.org/wiki/IRC_office_hours

[00:02:09] <marktraceur>	 We'll post the logs from this meeting there afterwards.

[00:02:17] <Andreas_>	 5. Some problems with the way NSFW material pops up, and consent issues concerning people depicted (see this month's Wikimedia-l discussions)

[00:02:34] <Jasper_Deng>	 NSFW and paid editing are loaded topics

[00:02:35] <sDrewth>	 lilatretikov: you will see that the WPs have the prominence in lots of things, including problems.  We have social and technical issues, and a very disparate approach to how they are handled.

[00:03:40] <sDrewth>	 resources seem to follow a squeaky wheel (social or technical), and no clarity against a master plan

[00:04:13] <lilatretikov>	 Jasper_Deng there are education efforts in flight + the Wiki Education Foundation in NA that focus on ed, both higher and K-12

[00:04:37] <AnnaKoval>	 @lilatretikov: indeed! :) @jasper_deng: agreed @karma: you might share this page with your teachers : https://en.wikipedia.org/wiki/Wikipedia:Researching_with_Wikipedia

[00:04:54] <philippe>	 AnnaKoval: I wondered if you were here and would weigh in on that :)

[00:05:00] <AnnaKoval>	 ;)

[00:05:16] <Aranda56>	 Do you agree that the foundation should have more involvement with centers of institutions/news corporations about donating quality source material or a subscription for all established editors to use like the New York Times or LexisNexis

[00:05:25] <lilatretikov>	 sDrewth -- i think social and technical need to be considered in tandem, one cannot be successful without the other

[00:06:04] <karma>	 AnnaKoval: Alright.

[00:06:14] <karma>	 If they're willing. :P

[00:06:38] <lilatretikov>	 sDrewth -- re: resourcing -- this is something that needs to follow high-level priorities, which i think need to be addressed as we do our next strategy development

[00:07:34] <lilatretikov>	 Aranda56 -- we are trying a few things there, like http://en.wikipedia.org/wiki/Wikipedia:The_Wikipedia_Library

[00:07:44] <sDrewth>	 lilatretikov: no dispute, I was more pointing to a disparate approach

[00:07:54] <harej>	 lilatretikov: What can the Wikimedia Foundation do to reach out to contributors who are not, shall I call them, the stereotypical Wikipedia editor?

[00:08:32] <Aranda56>	 litatretikov but the foundation isn't involved with The Wikipedia Library however, only volunteers as far as I know

[00:08:32] <lilatretikov>	 Aranda56 in general i beleive programs need to support our mission

[00:08:36] <RichardNevellWMU>	 Ocaasi in particular has done fine work with the Wikipedia Library

[00:08:45] <Guest38632>	 Lila, do you consider hiring paid professionals to handle arbitration? Thank you.

[00:09:03] <lilatretikov>	 Aranda56 -- the library is supported byt the WMF (funding) AFAIK

[00:09:09] <Aranda56>	 oh ok

[00:09:24] <philippe>	 (Yeah, that's an IEG - individual engagement grant - supported project)

[00:09:42] * philippe  waves to harej�

[00:09:46] <jamesofur>	 https://meta.wikimedia.org/wiki/Grants:IEG/The_Wikipedia_Library

[00:10:02] <harej>	 Hi Philippe!

[00:10:27] <lilatretikov>	 harej -- do you mean any specific group? what are the characteristics of the contibutors you'd like to see?

[00:11:01] <AnnaKoval>	 following up with @karma i understand. it may not be easy, and you may not succeed at convincing your teachers that wikipedia's not bad, but i hope you'll try. :) you can also send them to: education.wikipedia.org or have them email education@wikimedia.org  -- and we'll try to change their minds, too. ;)

[00:11:02] <Jasper_Deng>	 On a related note, what do you believe about current editor demographics?

[00:11:27] <philippe>	 Jasper_Deng: Do you wanna narrow that down a little?

[00:11:31] <philippe>	 That's pretty broad :)

[00:11:38] <AnnaKoval>	 @karma: that's coming from someone who

[00:11:47] <AnnaKoval>	 is a teacher herself

[00:11:53] <AnnaKoval>	 oops hit enter too soon :\

[00:12:05] <Jasper_Deng>	 Do you believe that there are some regions where we don't have enough editors from?

[00:12:10] <harej>	 lilatretikov: Representing non-Western countries and non-Western points of view, but even within Western nations, more women, more people of color. My organization Wikimedia DC is trying to tackle some of these challenges but I want to hear your thoughts.

[00:12:30] <lilatretikov>	 Jasper_Deng -- what I have learned so far is what our data shows around the contributor join year

[00:12:42] <karma>	 AnnaKoval: I'll try, thanks for the info. :)

[00:13:39] <bawolff>	 lilatretikov: How independent do you think wikimedia projects should be from the foundation in terms of technical things, software deployments, etc ? Or even just in general

[00:13:42] <philippe>	 (she's typing more to you, Jasper)

[00:14:24] <lilatretikov>	 contributors that joined earlier stay longer (and newer ones leave faster) -- and if that is indeed the case -- we clearly have an issue we need to understand better

[00:14:37] <AnnaKoval>	 @karma: :) and <3

[00:15:05] <philippe>	 harej: working on yours now : )

[00:15:21] <lilatretikov>	 harej -- gotit -- yes we have more data on this... in fact we know that fewer women even show intent

[00:15:27] <Jasper_Deng>	 What about the stereotype of the public that Wikipedia editors tend to be nerds? It might not be the general public's but that's the impression I've got from my peers outside of Wikimedia

[00:15:47] <lilatretikov>	 educational programs are actually good for targeting those things specifically and have shown some results

[00:16:12] <marktraceur>	 Heh, not sure how much time we have, but: What about the technical contributor pipeline? Do you have any ideas about how to improve on-ramping and retention of our volunteer programmers?

[00:16:28] <marktraceur>	 (I hope philippe is keeping up!)

[00:16:31] <Cloakedcitizen>	 Is the floor open for anyone's questions to Ms. Tretikov, or is one supposed to get in a queue?

[00:16:40] <philippe>	 Im on it, marktraceur

[00:16:42] <philippe>	 :)

[00:16:46] <sDrewth>	 Jasper_Deng: what would be interesting is to see that data side by side with the sister sites, not just WPs

[00:16:48] <bawolff>	 +1 to marktraceur's question

[00:16:49] <philippe>	 Cloakedcitizen: shout it out :)

[00:16:50] <marktraceur>	 Cloakedcitizen: We're just shouting things out; philippe is being the air traffic controller

[00:16:55] <Cloakedcitizen>	 Jimbo claimed yesterday to have been "harassed" by an incredibly prolific Wikipedia content creator "Kumioko"   meaning only that Kumioko had evaded his inexplicable ban to contact Jimbo. Should Jimbo so casually position   himself as victim of "harassment?"

[00:17:09] <Seth_Finkelstein>	 *wince*

[00:17:20] <lilatretikov>	 bawolff -- if you are asking about operations, i think it would be hard for anyone to run at the scale of what we do today

[00:17:27] <philippe>	 Seth_Finkelstein, okay, I lol'd at your wince :)

[00:17:37] <bawolff>	 lilatretikov: More thinking in terms of new feature deployments

[00:17:42] <lilatretikov>	 in terms of new experiements, i think it is critical that they are coming from everywhere

[00:17:48] <Andreas_>	 Hi Seth! :)

[00:17:50] <QueenOfFrance>	 Cloakedcitizen: local matters to enwiki and jimbo, nothing really to do with the foundation or our ED :)

[00:18:15] <bawolff>	 lilatretikov: Or more generally how disputes are resolved when devs and other projects "disagree"

[00:18:26] <sDrewth>	 and Cloakedcitizen: the person that you speak about implored to be locked, and vandalised to get it to happen

[00:18:27] <Cloakedcitizen>	 QueenOfFrance, I believe I asked Ms. Tretikov on an open floor. Not you.

[00:18:39] <lfaraone>	 Cloakedcitizen: no need to be rude about it, though.

[00:18:46] <philippe>	 Cloakedcitizen: what QueenOfFrance said :)  That's not a "lila" question, it's specific to an enwiki dispute

[00:18:51] <Krenair>	 Cloakedcitizen, rude.

[00:19:03] <Seth_Finkelstein>	 Andreas_ - I'll tell you guys my philosophy of questioning later 1/2 :-)

[00:19:04] <Cloakedcitizen>	 Let her answer.

[00:19:25] <Krenair>	 lilatretikov, So I think what bawolff is talking about is - basically we often get situations where MediaWiki devs make some change to the software, and WMF sysadmins come along and deploy it to wikis on schedule

[00:19:25] <lilatretikov>	 Jasper_Deng -- are you asking if the stereotype is true or how we should be dealing with it?

[00:19:33] <Jasper_Deng>	 the latter

[00:19:56] * Jasper_Deng  sees the connection to the learning curve required to edit�

[00:20:04] <lilatretikov>	 Jasper_Deng i am a proud nerd :)

[00:20:10] <bawolff>	 Whoo!

[00:20:10] * marktraceur  notes that based on research into the gender gap in CS, the "nerd" image may contribute to our own gender gap...�

[00:20:12] <Krenair>	 But often local wiki communities disagree with the changes. I've even seen some particularly nasty people on enwiki threads who expect the devs to defer to enwiki's community for whether each change should be made

[00:20:21] <philippe>	 (Math people, sigh.  Math was fine, til it started to include letters)

[00:20:35] <lilatretikov>	 i think we need to understand if that is an issue if that keeps people out. i don't have an answer yet.

[00:20:55] <lfaraone>	 Somewhat related to Krenair's comment, what do you feel is the best way to approach balancing the introduction of new features required for editor retention with avoiding disruption of the experiences of the projects' highly active participants? Many projects have been introduced lately that generated a lot of controversy, and some still are.

[00:21:12] <bawolff>	 nerdiness is often (not always) associated with intellectuals. And wikipedia is an intellectual endeavour

[00:21:35] <lilatretikov>	 Krenair -- do you think that process is broken then?

[00:21:39] <Krenair>	 Right, and there's also official WMF changes to the software (e.g. new big features) and whether the Wikimedia communit(y|ies) should have more control over that

[00:21:43] <sDrewth>	 bawolff: are you claiming to be a nerd or an intellectual? :-P

[00:21:45] <Krenair>	 lilatretikov, no, but some people do

[00:21:49] <marktraceur>	 Illustrative: "I edit Wikipedia" --Weird Al, "White and Nerdy" (cc mindspillage.)

[00:22:00] <marktraceur>	 Aw.

[00:22:01] <Finnegan>	 "nerdiness" and "Geekiness" are often perceived as boys' clubs (by women) and treated as them (by men)

[00:22:01] <sumanah>	 bawolff: there's something more specific here - "Unlocking the Clubhouse" is a good resource on this

[00:22:02] <Cloakedcitizen>	 I have another one, Ms. Tretikov: Wikipedia has great influence representing the definitions of its articles, because of its prominence in  web-searches. What do you think about the ide of allowing those who are the human subjects of its articles (in the   vernacular "BLPs") to opt out of articles and define themselves?

[00:22:03] <Emufarmers>	 mindspillage did not approve. :-(

[00:22:04] <Krenair>	 (As a MediaWiki volunteer and WMF VE dev I'm totally bias though)

[00:22:10] <PiRSquared>	 marktraceur: but he was vandalizing an article

[00:22:30] <Guest38632>	 Lila, could you please respond Andreas's question? Thank you.

[00:22:33] <philippe>	 I think we're going to start the process of wrapping things up, given that we're within the ten minute mark now...

[00:22:46] <marktraceur>	 Emufarmers: She does a great rendition of that song.

[00:22:55] <bawolff>	 Krenair: Or the recent dispute with flow on meta is an interesting case

[00:22:57] <marktraceur>	 But then it's a great song.

[00:23:06] <lilatretikov>	 lfaraone -- i think there needs to be a robust process by which concepts are vetted as they are being created and developed. i dont' think we are at the point where that process is in place yet

[00:23:19] <philippe>	 Guest38632, I didn't see a question from Andreas?

[00:23:26] <bawolff>	 sumanah: I imagine the situation is rather complicated. Not to mention on how the meanings of those words probably differ in different places

[00:23:30] <lilatretikov>	 it is hard to keep up with you guys... stuff scrolling off, sorry!

[00:23:39] <sDrewth>	 lilatretikov: are you going to Wikimania, and what are your plans for there?

[00:23:50] <sDrewth>	 if you are going of course

[00:24:00] <Guest38632>	 It is here: "[16:57] <Andreas_> Improvement potentials: 1. WMF is not doing enough to measure content quality. 2. Volunteers have asked for help with child protection; nothing has been done."

[00:24:13] <philippe>	 Those were responses to Lila's question, actually I think :)

[00:24:22] <Seth_Finkelstein>	 Ms ED-to-be, do you have any thoughts about improving the relationship of the WMF with its critics? Wikipediocracy can be harsh at time, but many important issues have been raised there, for example.

[00:24:38] <lilatretikov>	 marktraceur -- i have not dug into that yet, you want to tell me more about that in our 1-1?

[00:25:03] <marktraceur>	 lilatretikov: That sounds like a good plan - I imagine it will be on the minds of most of the ECT as well :)

[00:25:11] <marktraceur>	 (Engineering Community Team)

[00:25:27] <PiRSquared>	 Seth_Finkelstein: Well, Wil seems to agree with you about that

[00:25:42] <philippe>	 OK, I think Lila is going to do one more answer here, and then we're going to need to be off to keep her on schedule...

[00:26:27] <sDrewth>	 ^ Wikimania ^

[00:26:29] <Cloakedcitizen>	 WMF employee Phillipe Beaudette shreds or otherwise destroys the "identifications" of those community officials WMF accords access to personally-identifying information of editors. Do you approve?

[00:26:47] <bawolff>	 really?

[00:26:49] <Jasper_Deng>	 Cloakedcitizen: we're implementing a new policy

[00:26:57] <Jasper_Deng>	 so I'd think sDrewth's question is more important

[00:27:03] <Risker>	 Cloakedcitizen, please see the updated access to private information policy, where nobody identifies

[00:27:19] <sDrewth>	 I heard that he ate it sprinkled on his toast like 100s and 1000s

[00:27:24] <lilatretikov>	 Seth_Finkelstein RE: critique --  I embrace it -- when productive it helps me improve my thinking

[00:27:26] <Cloakedcitizen>	 Risker, I believe I addressed that to Ms. Tretikov.

[00:27:28] <Finnegan>	 lol sDrewth

[00:27:29] <Seth_Finkelstein>	 PiRSquared: Indeed. But Wil has also made it clear he's not his partner.

[00:27:37] <philippe>	 Cloakedcitizen: that's enough, now.  You've made your point.

[00:27:38] <bawolff>	 om nom nom

[00:28:17] <Cloakedcitizen>	 Ms. Tretikov, you haven't answered any of my questions: would you read my article ?

[00:28:37] <lilatretikov>	 PiRSquared Wil is his own person, he does not represent me

[00:28:43] <Seth_Finkelstein>	 PiRSquared: By which I don't mean to imply anything, but it's why the question is very relevant to the new Executive Director

[00:29:02] <PiRSquared>	 lilatretikov: I didn't mean to imply that he did, sorry

[00:29:06] <lilatretikov>	 sDrewth -- I will be at Wikimania. Can't wait!!!

[00:29:11] <bawolff>	 Cloakedcitizen: If that was meant as satire, it would kind of be funny

[00:29:15] <sDrewth>	 nice

[00:29:39] <Cloakedcitizen>	 I'm on a two-minute timer here. If one of the ban-hammerers doesn't kick me, I haven't asked critical enough questions.

[00:29:46] <lilatretikov>	 Thanks everyone -- this has been great. See you in a few weeks!!!

[00:29:52] <philippe>	 Thanks, everyone :-)

[00:29:55] <Seth_Finkelstein>	 lilatretikov: To be fair, I think PiRSquared was noting that there's some social credibility.

[00:30:08] <QueenOfFrance>	 lilatretikov: thank you for the Q&A session and best of luck in the job.

[00:30:12] <RichardNevellWMU>	 +lilatretikov: We can guarantee the weather in London will be good (probably)

[00:30:12] <Jasper_Deng>	 Thanks!

[00:30:15] <Andreas_>	 Cheers, and best to all.

[00:30:38] <sDrewth>	 RichardNevellWMU: will there be a cricket match?

[00:30:38] <Cloakedcitizen>	 Curses, have a nice day, Ms. Tretikov and all.

[00:30:40] <bawolff>	 lilatretikov: Thanks for answering our questions

[00:30:40] <PiRSquared>	 Thanks for doing this lilatretikov :)

[00:30:41] * marktraceur  gives lilatretikov a "Not Feeding the Trolls" barnstar�

[00:31:00] <sDrewth>	 hehe marktraceur

[00:31:01] <Keegan>	 :)

[00:31:08] <Jasper_Deng>	 that was very nice

[00:31:16] <lfaraone>	 Could've been worse.

[00:31:18] <Jasper_Deng>	 She still has some ropes to learn

[00:31:23] <Jasper_Deng>	 but I think she'll do fine

[00:31:29] <harej>	 Honestly, it's amazing if she still wants to be ED after this :P

[00:31:34] <Keegan>	 I must say, it was a change of pace from the VisualEditor office hours of the past nine months :)

[00:31:34] <bawolff>	 lol

[00:31:41] <Seth_Finkelstein>	 Andreas_ - I don't believe in the "Killer Question". I point people to this http://www.thisamericanlife.org/radio-archives/episode/257/transcript

[00:31:42] <RichardNevellWMU>	 sDrewth: there's been talk of one. Having followed England's recent exploits, part of me hopes it goes no further, but if folks want to raise a team I'm sure they'll find someone to play against ;-)

[00:31:53] <sDrewth>	 love them when they want openness to align with their cloaked behaviour

[00:32:12] <James_F>	 Keegan: Are you saying I feed the trolls?

[00:32:35] <sDrewth>	 RichardNevellWMU: as long as we have beer afterwards

[00:32:35] <Finnegan>	 Keegan: you mean in that people talked for once? Or have VE hours gotten more lively?

[00:32:35] <Keegan>	 James_F: No, you're just boring now. Old hat.

[00:32:35] <sDrewth>	 James_F: you'd eat the trolls if they were baked or made of chocolate

[00:32:35] <RichardNevellWMU>	 It would be mandatory. Regardless of the result.

[00:32:44] <quiddity>	 And sliced oranges at halftime.

[00:32:45] * philippe  likes chocolate trolls.�

[00:32:47] <Keegan>	 Finnegan: they have not gotten more lively

[00:32:59] <James_F>	 Keegan: Yup, boring, that's me.

[00:33:10] <James_F>	 sDrewth: I generally don't eat humans.

[00:33:26] <marktraceur>	 James_F: Too much cool software, not enough emotional breakdowns

[00:33:30] <heatherw>	 sDrewth: I found that ironic, myself.

[00:33:34] <marktraceur>	 Stop being s'damn productive

[00:33:45] <Keegan>	 marktraceur: exactly. He's never rage quit. Lame.

[00:33:58] <marktraceur>	 <James_F> GOD

[00:33:59] <Finnegan>	 James_F: want me to show up to your next VE hours and tell you how horrible you are?

[00:34:03] <James_F>	 marktraceur: Sorry! Will go break things now.

[00:34:04] <marktraceur>	 -!- James_F has quit

[00:34:32] <James_F>	 Finnegan: That'd be great! I'm always looking for people to have difficult questions. It makes them more interesting.

[00:34:35] <sDrewth>	 heatherw: all mouth, alll look at me

[00:34:39] <Keegan>	 Finnegan: He's English. That helps him.

[00:34:56] * James_F  laughs.�

[00:35:09] <James_F>	 Has anyone actually ever rage-quat an office hours?

[00:35:10] <Finnegan>	 James_F: unfortunately, since I haven't used VE in months, it'll have to literally be, "You're horrible. Also horrible, and a bit horrible. Also you suck." rather than anything interesting or useful

[00:35:24] <James_F>	 Finnegan: Plus ça change, right?

[00:35:28] <Finnegan>	 hrh

[00:35:30] <Finnegan>	 *heh

[00:36:19] <Finnegan>	 see, You made me misspell my meaningless laugh, you're horrible

[00:37:44] * James_F  nods.�

[00:37:46] <James_F>	 That's me.

[00:38:19] <sDrewth>	 Finnegan: and that is one of his good points

[00:38:53] <Seth_Finkelstein>	 Andreas_: One is practically never going to get a "Sir, have you NO SHAME?!" moment - and that goes double for *IRC* (any no chance even to posture for video :-)).