[00:00:30] <Reedy>	AaronSchulz: going to review Niklas' from september again? :p
[00:00:57] <AaronSchulz>	I'm waiting on tim's rev to get OKed
[00:01:17] <Reedy>	heh
[00:01:49] *AaronSchulz 	gives r110922, r110960 to reedy
[00:01:50] <werdna>	raindrift: so what's this about wikieditor click tracking?
[00:05:18] <raindrift>	well, actually, maybe we don't need to do it in wikieditor...
[00:05:31] <raindrift>	basically, we need to keep track of the page titles that are being edited using the new workflow.
[00:05:49] <raindrift>	we could actually log that when the user clicks the button to go to wikieditor, so we don't have to instrument the wikieditor itself.
[00:06:17] <werdna>	nod
[00:06:25] <raindrift>	the important thing is that, when we load up the wikieditor via the ACW interstitial, we log the page title in question.  that'll let us find out later the survival rate of those pages
[00:06:28] <werdna>	so we need to log the *pages*
[00:06:31] <raindrift>	(which is, presumably, our metric for quality)
[00:06:32] <werdna>	okay
[00:06:42] <werdna>	let me think about this a bit
[00:06:48] <werdna>	not sure what the best approach is
[00:06:49] <raindrift>	okay.
[00:06:55] <raindrift>	yeah.  i'm not either.
[00:07:05] <werdna>	do we want to create a whole new table? eee
[00:07:10] <werdna>	or can we stick them in clicktracking?
[00:07:11] <werdna>	is that weird?
[00:07:19] <raindrift>	i think we may want to make a new table for this.
[00:07:34] <werdna>	in which case we need to create a whole new API module, etc
[00:07:47] <raindrift>	it'll be really handy, i think, for the page title to live in its own dedicated column.  i know that's what i'd want if i was trying to get answers later.
[00:08:07] <raindrift>	if clicktracking is flexible enough to store it in a way that's useful, we should use that just because it sounds like the path of least resistance.
[00:09:58] <werdna>	mmm, joining
[00:10:00] <werdna>	I get it
[00:10:58] <RoanKattouw>	I think there's precedent for sticking the page title in the additional_info field
[00:11:21] <RoanKattouw>	There's a namespace field in the clicktracking table, but no title field, so that's what people have been doing :S
[00:15:15] <werdna>	RoanKattouw: oo
[00:15:17] <werdna>	we could do that
[00:15:19] <werdna>	but then joining is harder
[00:15:45] <werdna>	raindrift: how do you feel about that?
[00:15:50] <RoanKattouw>	Depends on which direction you're joining in
[00:16:02] <werdna>	Plus: No new table, no new API module
[00:16:06] *aude 	waves
[00:16:28] <RoanKattouw>	If you're doing queries that say "here's a bunch of clicktracking rows, now find the page table rows for these", you'll be fine
[00:16:48] <werdna>	Minus: it's stored in a different format to it would be in the page table, so you can't use a natural join UNLESS the page is in the main namespace
[00:17:11] <RoanKattouw>	werdna: There is a namespace field in the clicktracking table
[00:17:31] <RoanKattouw>	Use that and you'll be fine
[00:17:44] <werdna>	ahhhhhhhhhhhh
[00:17:45] <werdna>	\o/
[00:17:55] <RoanKattouw>	Doing queries that say "here's a bunch of (namespace,title) pairs, find me the clicktracking rows for these" will not be fine because there's no index
[00:17:59] <raindrift>	werdna:  i'd say if there's a precedent, let's do it that way.  we're not building any sort of persistent reporting interface, so queryability is a pretty low priority.
[00:18:00] <werdna>	nod
[00:18:10] <werdna>	raindrift: With RoanKattouw's caveat
[00:18:21] <RoanKattouw>	Also, you should be aware that, in production, the clicktracking table isn't written to at all
[00:18:29] <werdna>	oh?
[00:18:40] <RoanKattouw>	Instead, it goes through the UDP log collection system
[00:18:43] <raindrift>	right.
[00:18:47] <RoanKattouw>	Because it turns out the latter is a tad more scalable :)
[00:18:47] <werdna>	ahh
[00:18:51] <werdna>	nod
[00:18:57] <werdna>	so how do we get the data then?
[00:19:06] <werdna>	I assume it all goes through intact, though?
[00:19:11] <raindrift>	so, one way or another, we have to pull the data into some script and intersect it with the article data outside mysql.
[00:19:37] *RoanKattouw 	remembers when he crashed the site by accidentally logging a few hundred thousand clicktracking events in a few minutes' time
[00:20:41] <RoanKattouw>	Back then, it melted the enwiki master by burying it in write load. Nowadays, it would just cause emery to drop a bunch of packets
[00:20:50] <raindrift>	so, yeah.  werdna, let's use clicktracking for storing the article titles since it scales well, and we can do the work of building reasonable stats with some script that can grind away on that data for a few hours later.
[00:21:10] <werdna>	raindrift: definitely
[00:21:16] <werdna>	that's like a 3 line change
[00:21:18] <werdna>	\o/
[00:21:20] <werdna>	I approve of this
[00:21:53] <werdna>	RoanKattouw: where does the data go?
[00:22:30] <RoanKattouw>	Currently, emery:/var/log/aft
[00:22:46] <RoanKattouw>	Longer term, we want to put in a multiplexer that can split data from different sources
[00:22:59] <RoanKattouw>	We're already mixing AFTv4, AFTv5 and edit toolbar data there
[00:23:00] <werdna>	RoanKattouw, you are the fount of all knowledge
[00:24:20] <RoanKattouw>	I'm sometimes amazed that I do things like tell people about our UDP-based analytics logging setup while simultaneously telling someone that IE's stupidity won't break their CSS anymore
[00:25:05] <RoanKattouw>	(IE limits the number of <style> tags to 31, and refuses to apply CSS in the 32nd or subsequent tag. This is a known issue, even in IE9. Like seriously?!?)
[00:25:10] <werdna>	RoanKattouw: I saw that
[00:25:11] <werdna>	like, wtf
[00:25:12] <werdna>					'namespacenumber': mw.config.get( 'wgNamespaceNumber' ),
[00:25:14] <werdna>	ugh
[00:25:17] <werdna>	we can't specify the namespace
[00:25:19] <werdna>	that is a pain
[00:25:36] <RoanKattouw>	Sounds like that code needs to be fixed
[00:25:57] <RoanKattouw>	Feel free to patch jquery.clickTracking.js to be nicer to you
[00:27:39] <raindrift>	werdna:  bucketing code now buckets
[00:28:36] <raindrift>	(you only have a 1% chance of seeing it work.  otherwise you'll have to change your cookie to get into the 'test' bucket)
[00:29:57] *werdna 	is really lazy
[00:29:57] <werdna>	$.trackActionWithInfoAndNamespace = function( id, info, namespace ) {
[00:34:55] <werdna>	maybe not
[00:36:13] <werdna>	hmm, Fatal error: Cannot redeclare class FakeMaintenance in /Users/andrew/wm-svn/phase3/maintenance/Maintenance.php on line 1253
[00:37:01] <RoanKattouw>	werdna: You could just add an optional namespace parameter to each function, and then use namespace || mw.config.get( 'wgNamespaceNumber' )
[00:37:07] <RoanKattouw>	(literally; you can use || in JS that way)
[00:37:10] <werdna>	:/ ( ! ) Fatal error: Call to undefined function getUserEditCountSince() in /Users/andrew/wm-svn/extensions/ClickTracking/ApiClickTracking.php on line 41
[00:37:23] <RoanKattouw>	You need UserDailyContribs
[00:37:32] <RoanKattouw>	Thank you for reminding me that I want to stab that extension to death
[00:37:37] <RoanKattouw>	(UDC that is)
[00:38:38] <werdna>	do I have to populate the udc table?
[00:38:51] <RoanKattouw>	No
[00:39:05] <RoanKattouw>	Just install UDC and run update.php
[00:39:56] <werdna>	| event_id            | int(11)        | NO   | MUL | NULL    |       |
[00:39:57] <werdna>	um?
[00:39:58] <RoanKattouw>	There is no population script, in fact, it just tracks edits by date
[00:39:59] <werdna>	it's an integer?
[00:40:04] <RoanKattouw>	Aye
[00:40:15] <RoanKattouw>	For some daft reason, the actual event name is in the click_tracking_events table
[00:40:18] <werdna>	ah, i have to join
[00:40:24] <werdna>	database normalisation!!!!11
[00:40:44] <RoanKattouw>	Of course that table is just (event_id, event_name) so there's no reason for it to exist
[00:41:19] <Amgine>	CREATE TABLE redundant_data...
[00:41:50] <werdna>	maybe you want to change an event name!!
[00:42:42] <RoanKattouw>	heh, in practice you can't even do that nicely
[00:43:03] <RoanKattouw>	Anyway that's all moot for UDP logging, the event_id isn't used in UDP mode
[00:44:45] <Reedy>	Yay, no fixmes on phase3 now
[00:46:17] <RoanKattouw>	YAY
[00:47:57] <Reedy>	14 news
[00:48:20] <Reedy>	Think it might not be a bad idea to take the plunge
[00:49:39] <RoanKattouw>	I did everything I wanted to do
[00:49:48] <RoanKattouw>	No more commits from me for 1.19
[00:49:53] <RoanKattouw>	At least for now
[00:50:11] <Reedy>	only 3 from 2011
[00:50:15] <Reedy>	but they've been back and forth anyway
[00:53:20] <Reedy>	robla, TimStarling Any objections to branching?
[00:53:41] <robla>	WHAT, YOU'RE BRANCHING?!?!?!?!
[00:53:45] <robla>	no, none from me
[00:53:47] <TimStarling>	I think you can branch
[00:54:04] <TimStarling>	if there are any more issues with trunk we can always backport the fixes
[00:54:31] <Reedy>	Seems to be a reasonable place to start from
[00:54:31] <Reedy>	0 fixme, 14 new
[00:55:00] <AaronSchulz>	meh
[00:55:14] <Reedy>	meh?
[00:57:43] <TimStarling>	just assume he's being sarcastic and is actually extremely excited
[01:02:35] <Reedy>	Well, we can't have MediaWiki 2.0 now
[01:11:23] <robla>	heh...having zero fixmes I think broke my graphing code  :)
[01:11:47] <robla>	http://toolserver.org/~robla/crstats/?report=trunkphase3 ...check out the end of the red line
[01:12:53] <RoanKattouw>	haha
[01:13:20] <robla>	I mean come on...why would I ever test for zero fixmes?
[01:26:32] <binasher>	AaronSchulz: TimStarling: can you review https://www.mediawiki.org/wiki/Special:Code/MediaWiki/111014 for me?
[01:27:34] <RoanKattouw>	binasher: Ideally that script would be in the WikimediaMaintenance extension, because it's WMF-specific
[01:27:34] <binasher>	when doing the 1.18 migrations, one of the alters on a dewiki db failed due to a lock timeout and it wasn't noticed til code deploy, hence the extra checking after each migration and $missing in this version
[01:27:41] <RoanKattouw>	I'd really like to stop adding WMF-specific stuff to phas3
[01:28:01] <RoanKattouw>	+		$rootPass = trim( wfShellExec( '/home/wikipedia/bin/mysql_root_pass' ) );
[01:28:09] <RoanKattouw>	Should come from /usr/bin instead
[01:28:36] <binasher>	there isn't a /usr/bin/mysql_root_pass
[01:28:52] <RoanKattouw>	local/bin then
[01:28:55] <RoanKattouw>	You also don't need this
[01:29:09] <RoanKattouw>	Let me find you a code example of something that loops through wikis properly
[01:29:14] *robla 	looks up the bug report about /home/w/bin
[01:29:33] <binasher>	wow, /home/wbin/mysql_root_pass isn't the same as /usr/local/bin/mysql_root_pass
[01:29:42] <robla>	https://bugzilla.wikimedia.org/show_bug.cgi?id=34136
[01:30:05] <RoanKattouw>	extensions/WikimediaMaintenance/clearMessageBlobs.php line 51-57
[01:30:10] <RoanKattouw>			foreach ( $wgConf->getLocalDatabases() as $wiki ) {
[01:30:16] <RoanKattouw>				$lb = wfGetLB( $wiki );
[01:30:18] <RoanKattouw>				$db = $lb->getConnection( DB_MASTER, array(), $wiki );
[01:30:22] <binasher>	this is all based off of tim's script used for 1.17
[01:30:30] <RoanKattouw>		# Do what you need with $db
[01:30:37] <RoanKattouw>	$lb->reuseConnection( $db );
[01:30:38] <RoanKattouw>	}
[01:30:45] <RoanKattouw>	heh, this is also based on something Tim wrote for 1.17
[01:31:05] <RoanKattouw>	Oh, hm, I think I see
[01:31:10] <RoanKattouw>	You need DB conns to specific servers
[01:31:45] <binasher>	and expressly don't want DB_MASTER
[01:32:07] <robla>	binasher: this shouldn't go into REL1_19.  it probably needs to wait for 1.19wmf1
[01:32:08] <binasher>	yeah, the logic here is to iterate through each slave for each wiki
[01:32:12] <RoanKattouw>	Huh:
[01:32:15] <RoanKattouw>	+						while ( $db->getLag() > 10 ) {
[01:32:16] <RoanKattouw>	+							echo "Waiting for $server to catch up to master.\n";
[01:32:18] <RoanKattouw>	+							sleep( 20 );
[01:32:19] <RoanKattouw>	+						}
[01:32:28] <AaronSchulz>	heh
[01:32:29] <RoanKattouw>	Why would you not do what wfWaitForSlaves() does
[01:32:29] <binasher>	robla: i needed it to go somewhere for a review
[01:32:41] <robla>	fair enough
[01:32:52] <binasher>	wfWaitForSalves() doesn't operate on one single slave, does it?
[01:32:56] <RoanKattouw>	Hmm, that uses LB
[01:32:58] <RoanKattouw>	Yeah
[01:32:59] <RoanKattouw>	But lemme dig down
[01:33:15] <Reedy>	I'll tidy it all up when I branch
[01:33:21] <binasher>	thanks reedy
[01:33:28] <Reedy>	np
[01:33:54] <RoanKattouw>	See Database::masterPosWait()
[01:34:44] <RoanKattouw>	Get a master conn, then do $pos = $dbw->getMasterPos(); , then $db->masterPoswait( $pos, $timeout );
[01:34:56] <binasher>	that isn't going to be all that helpful
[01:35:14] <binasher>	as in some cases, a slave with be several hours behind at that point
[01:35:16] <RoanKattouw>	Why not?
[01:35:20] <RoanKattouw>	Oh, lol
[01:35:34] <RoanKattouw>	Well
[01:35:44] <RoanKattouw>	You're waiting till it drops down below 10s anyway
[01:36:40] <RoanKattouw>	But it's probably fine
[01:37:00] <AaronSchulz>	 //$this->sourceUpgradeFile( $db, dirname( __FILE__ ) .'/schema-changes-1.19wmf1-1.sql' );
[01:37:04] <RoanKattouw>	Hmm, echo should be $this->output()
[01:37:35] <RoanKattouw>	Hmph, although that buffers output
[01:37:44] <RoanKattouw>	Actually, PHP itself may buffer output
[01:37:52] <RoanKattouw>	You may want to  check that
[01:38:29] <binasher>	i don't think it does for echo
[01:40:00] <binasher>	AaronSchulz: heh, forgot to delete that.. that was before i decided not to group migrations together as was done previously
[01:41:14] <TimStarling>	I'm sure there was a good reason for not using wfWaitForSlaves
[01:41:59] <TimStarling>	as for $this->output() versus echo, they both do the same thing
[01:42:21] <TimStarling>	but it's a lot easier to work out what echo does
[01:42:28] <Joan>	Oh.
[01:42:29] <TimStarling>	for someone reading the code
[01:44:14] <binasher>	wfWaitForSlaves() wouldn't work too well here as it only waits til all slaves reach the master pos at the time its called.  after that, the just migrated slave could still be well behind
[01:47:38] <AaronSchulz>	seems ok otherwise
[01:47:38] <TimStarling>	the two versions of mysql_root_pass have the same password in them
[01:48:09] <TimStarling>	maybe the /usr/local/bin one is puppetized, it has mode 440
[01:48:12] <binasher>	i went ahead and changed it to use the /usr/local/bin/ version
[01:48:52] <binasher>	now when should i start running this monster
[01:49:11] <TimStarling>	wfWaitForSlaves() and any other LB function won't use db-secondary.php whatever that is
[01:49:21] <RoanKattouw>	True
[01:49:31] <RoanKattouw>	Yeah I dropped all my concerns except the path to root_pass
[01:49:39] <RoanKattouw>	And yes, the /u/l/b one is in puppet, I put it there
[01:49:50] <RoanKattouw>	 /h/w/b is deprecated and should be removed some time
[01:50:09] <binasher>	db-secondary is a mirror of db.php containing the eqiad and analytics slaves
[01:50:33] <TimStarling>	what are these index missing warnings for?
[01:50:57] <TimStarling>	if ( ! $db->indexExists( 'page', 'page_redirect_namespace_len' ) ) {
[01:50:57] <TimStarling>	93 	$missing .= " page_redirect_namespace_len";
[01:50:57] <TimStarling>	94 	}
[01:51:10] <binasher>	when i did the 1.18 migrations, one of them got a lock timeout on a dewiki db but everything continued along
[01:52:25] <TimStarling>	you would think it would throw an exception in that case
[01:52:43] <binasher>	i just want to be paranoid and loudly know to re-run on a db if that should happen again instead of finding out after a wiki is deployed to
[01:53:03] <binasher>	without having to do any additional checking after
[01:54:08] <binasher>	its entirely possible an exception was logged and i missed it
[01:54:29] <TimStarling>	if an exception is thrown then your missing warning won't get shown
[01:54:36] <TimStarling>	it'll just exit the whole script
[01:54:44] <binasher>	that definitely didn't happen last time
[01:55:13] <binasher>	is there exception handling in the db classes?
[01:55:44] <TimStarling>	they throw exceptions, if that's what you mean
[01:56:06] <binasher>	hrm
[01:56:12] <TimStarling>	there's a mode in which they don't, but it's deprecated
[01:56:32] *AaronSchulz 	didn't know it was deprecated
[01:56:45] <TimStarling>	I should say disliked
[01:56:47] <TimStarling>	like on lua-l
[01:57:06] <binasher>	what seemed to have happened then, is the script ran through and exited 0 after a couple days, and after the third or so round of migrations a dewiki db was found with the updatelog row inserted but only some of the migrations applied
[01:57:43] <TimStarling>	have you run this script on a local test wiki?
[01:57:53] <binasher>	not yet
[01:58:01] <binasher>	i'll do that tonight
[01:58:07] <TimStarling>	well, you can easily test error handling when you do that
[01:58:09] <AaronSchulz>	dep??re??cate: 1. to express earnest disapproval of.
[01:58:14] <TimStarling>	just edit one of the queries to have a syntax error in it
[01:58:23] <AaronSchulz>	sounds deprecated then ;)
[01:58:39] <TimStarling>	ah yes, deprecated as of now, because I just said I don't like it
[01:59:08] <binasher>	should all error handling behave the same way regardless of mysql error code?
[01:59:52] <TimStarling>	no
[02:00:18] *AaronSchulz 	looks at deadlockLoop()
[02:00:20] <AaronSchulz>	$oldIgnore = $this->ignoreErrors( true );
[02:00:39] <TimStarling>	see DatabaseBase::query()
[02:01:01] <TimStarling>	and DatabaseMysql::wasErrorReissuable()
[02:01:15] <TimStarling>	maybe that's the case you hit
[02:01:58] <TimStarling>	error 2013 and 2006 will cause it to reconnect and reissue the query rather than throw an exception
[02:04:41] <TimStarling>	a lock wait timeout wouldn't do that though
[02:04:56] <TimStarling>	and the query would have been reissued, not skipped
[02:05:31] <TimStarling>	and if there was an error the second time, it would have caused an exception
[02:06:28] <binasher>	would DBQueryError really exit the script?
[02:07:06] <TimStarling>	yes
[02:07:14] <binasher>	getting the updatelog row without getting all migrations doesn't seem like it should be possible
[02:07:26] <TimStarling>	you wouldn't think so
[15:46:36] <varnent>	guillom: ping
[15:49:27] <guillom>	varnent, pong
[15:49:42] *varnent 	gets the pads out and sets up the table
[15:50:18] <varnent>	sorry I missed you the last couple days - was sidetracked with all the Prop 8 stuff here in the US
[15:51:51] <guillom>	No problem ??? and yay Prop 8 stuff :)
[15:52:04] <varnent>	yay - it's going to be appealed - but eh - a win is a win
[15:52:34] <guillom>	True.
[15:52:36] <varnent>	okay - so got a few minutes to chat about various items?
[15:52:43] <guillom>	sure
[15:54:36] <varnent>	okay - so 2-3 items - MW.org stuff, Wikimania programming and an outside project I wanted to run past you as well  :)
[15:55:14] <guillom>	I'm all ears
[15:55:21] <varnent>	curious if you had any thoughts on these WikiProject style approach we're playing around with for the page drive and tweaking to extension pages
[15:55:37] <varnent>	then related to that wanted to chat a bit about the extension pages and templates to pick your brain about that
[15:56:34] <guillom>	Can you give me a link to the wikiproject stuff?
[15:56:57] <varnent>	sure
[15:57:14] <varnent>	https://www.mediawiki.org/wiki/Project:WikiProject_Extensions
[15:57:18] <varnent>	https://www.mediawiki.org/wiki/Project:WikiProject_SysAdmins
[15:57:42] <guillom>	thanks
[16:01:04] <guillom>	varnent, do you have specific questions about those? Looking at them, my only comment so far would be "it's a nice initiative whose success can only be assessed with time" :)
[16:01:35] <guillom>	I'm not so much in the whole barnstars thing myself, but if it helps motivate people, then I'm all for you using them.
[16:01:40] <varnent>	that works - mostly wanted to run it past for any "well that's obviously an aspect of it that's not going to work"  :)
[16:01:57] <varnent>	yeah - I'm not a barnstar person myself - but WikiLove suggests ppl like them..so..whatever works
[16:02:09] <varnent>	one idea that has come up is tweaking the extensions template
[16:02:41] <varnent>	I've heard ideas ranging from just slight tweaks to a more page-wide type template that formats a large portion of the page for extensions
[16:03:49] <varnent>	any thoughts on if that's just too big a pain to undertake, slight tweaking is good, etc.
[16:04:03] <guillom>	My only wish for extension pages so far is to convert everything to SMW, but we know that's not going to happen anytime soon :)
[16:04:21] <varnent>	yeah - lol - I have a hunch that won't happen
[16:04:49] <varnent>	some ideas make sense - like standardizing how release notes are posted and maybe trying to setup some RSS feed style setup for those
[16:05:13] <varnent>	others involved far more elaborate tweaks that seemed less likely
[16:05:24] <guillom>	Not sure ??? My only piece of advice would be to keep in mind who the users are. There are obviously different audiences for Extensions page: third party sysadmins, for example, but also other developers, new developers, random Wikimedians, etc.
[16:05:41] <varnent>	there's also been a discussion that Erik entered into about soliciting donations via extension pages - either to the developer or WMF then for grants
[16:05:55] <varnent>	one thing that's come up with those pages is what the expectations are for folks that post
[16:06:00] <guillom>	Interesting concept
[16:06:26] <varnent>	https://www.mediawiki.org/wiki/Thread:Project:WikiProject_Extensions/Ideas/Link_within_Extension_to_allow_developers_to_solicit_donations
[16:07:50] <varnent>	we came up with some expectations:  https://www.mediawiki.org/wiki/Manual:Developing_extensions#Publishing
[16:08:22] <varnent>	we're already starting to archive older extensions and in about a month may start posting notices to move extensions code to the code repo and off the wiki
[16:08:37] *guillom 	reads.
[16:09:12] <varnent>	this is sort of a precursor to all of that - figuring out where we're at with extensions now - https://www.mediawiki.org/wiki/Project:WikiProject_Extensions/Projects/Page_Drive
[16:11:11] <guillom>	I'm impressed by your courage :)
[16:11:40] <varnent>	lol
[16:11:57] <varnent>	ignorance is bliss and being bold can be easy  :)
[16:12:11] <varnent>	but thank you  :)
[16:12:41] <varnent>	so from a template perspective - all of the headers - loading them dynamically via the main template so it controls when an extension is incompatible and loads the appropriate headers?
[16:13:27] <varnent>	most of this is out of some sense of personal annoyance or necessity - lol - I do enough 3rd party wiki work that extension pages not clearly telling sysadmins if it'll work on the newest release is a problem  :)
[16:14:15] <varnent>	so spending a few months setting this up now vs. repeatedly troubleshooting the same "oh you downloaded an old extension that clearly won't work now" problem is worth it
[16:14:22] <guillom>	True
[16:14:26] <sumanah>	:)
[16:15:47] <varnent>	so as the number of headers for extension pages grows - https://www.mediawiki.org/wiki/Project:WikiProject_Extensions/Templates - my pondering is if that should be more "automated" or if that's just a parsing headache not worth undertaking
[16:16:22] <varnent>	I'm told you're a template ninja  :)
[16:16:41] <guillom>	Hah!
[16:16:48] *guillom 	eyes sumanah suspiciously.
[16:17:01] *sumanah 	is guilty
[16:18:00] <varnent>	sumanah: TOTALL unrelated (and not to digress..but..) - Steve Job's full FBI file was released - interesting read - Bush Sr. was rather worried about his former pot use (ha!) - http://vault.fbi.gov/steve-jobs/steve-jobs-part-01-of-01/view
[16:18:01] <guillom>	varnent, so, is your goal to integrate those banners into the extension template based on some of its parameters?
[16:18:16] <varnent>	guillom: I suppose my question is should that be a goal
[16:18:24] <guillom>	Ah.
[16:18:44] <varnent>	or is the current setup fine enough that it doesn't need to be a part of the equation
[16:18:44] <varnent>	b
[16:19:04] <varnent>	basically - if we're going to do surgery on the extensions template - should automating those headers be a part of the equation
[16:20:10] <guillom>	varnent, if we had SMW, I'd suggest to automate everything. But for now, I think it's better to keep them separate ???  even if only because it's easier to add a simple template than to find what the right parameter is for the already monstruous extension template.
[16:20:21] <varnent>	makes sense
[16:20:51] <varnent>	maybe tweak the pre-load for new extension pages a bit more to help standardize things
[16:21:24] <varnent>	is there any reason to keep the Usage stats on the extensions template?  it doesn't really appear that wikistats is doing anything with that so it barely works
[16:21:48] <guillom>	Then I guess you just answered your question :)
[16:21:51] <varnent>	lol
[16:22:29] <varnent>	related question - any thoughts on how to do templates for files on MW.org better?
[16:22:42] <guillom>	Can you be more specific?
[16:23:13] <varnent>	I've been playing around with (took a break and need to get back to finishing it) having language bars inside the templates for use on file description pages - where it's less likely we'd have language subpages and conveying legal messages seems important enough to find a better solution
[16:23:38] <varnent>	https://www.mediawiki.org/wiki/Project:File_copyright_tags
[16:24:41] <guillom>	I'd generally encourage to upload everything to Commons except for Fair use. I don't think it really makes sense to duplicate their existing template translation magic.
[16:24:58] <varnent>	there was a listserv discussion about this
[16:25:04] <varnent>	I'm basically on the fence to be honest
[16:25:28] <varnent>	but the consensus seemed to be that enough developers didn't trust Commons admins enough that they wanted MW specific documentation images to remain on MW.org
[16:25:38] <varnent>	which leaves that wiki with a growing unmanaged images problem (of sorts)
[16:25:58] <varnent>	not like "OMG crisis problem" but you know "hmm???what's the mildew in the corner?" type problem   :)
[16:26:44] <varnent>	lol - even getting any remote type of consensus on something like this - https://www.mediawiki.org/wiki/Project:Image_policy - was tricky
[16:28:01] <guillom>	So, basically, developers can't be bothered to upload to Commons cleanly, so they want to continue to upload to MediaWiki with dubious licenses. I fundamentally disagree with this, so personally I won't spend any time working on things to accommodate local uploads. You're of course free to do what you want :)
[16:28:19] <varnent>	lol - well that's one way to phrase it  :)
[16:28:53] <varnent>	I think it was more like developers are too paranoid to trust an outside wiki project - and 3-4 shared experiences of overzealous deletion of images they were using for documentation, extensions, etc.
[16:29:09] <varnent>	it's not a problem I've faced personally - and I tend to favor Commons - but accept that not everyone will jump onboard
[16:29:30] <sumanah>	varnent: guillom's general philosophy is "everyone should just be orderly and follow the rules! why aren't they doing that?" :-)
[16:29:59] <guillom>	That's not entirely true. I've come to terms a while ago with the world not conforming to my ideal vision of it.
[16:30:01] <varnent>	my therapist has done wonders for me in lowering my blood pressure when others don't follow the rules I think they should  :)
[16:30:44] <varnent>	so Wikimania
[16:30:57] <guillom>	Oh, my stress levels also visibly decreased when I realized it all didn't matter in the grand scheme of things :)
[16:31:13] <varnent>	yeah - it's an exciting revelation in one's life
[16:31:25] <varnent>	that and when you realize the level to which you actually care what others think
[16:31:38] <varnent>	but I digress  :)
[16:31:49] <sumanah>	varnent: oh no, this is totally applicable to extensions docs
[16:31:58] <varnent>	lol
[16:32:20] <sumanah>	especially re uploads
[16:32:23] <varnent>	the posting code on the wiki has been a particularly puzzling thing to me
[16:32:52] <varnent>	that and the fear of other developers touching other ppl's extensions
[16:32:59] <sumanah>	varnent: it is WAY EASIER than any other method
[16:33:08] <sumanah>	varnent: click, click, done
[16:33:13] <sumanah>	don't have to wait for anyone else
[16:33:20] <varnent>	eh - once we start to move their code to the repo for them - ppl may change their tune
[16:33:23] <sumanah>	true
[16:33:37] <varnent>	lol "click, click, done - wait where'd my code go?"
[16:33:39] <sumanah>	but I am guessing this is why it's happened. also, people see it on other pages and thus think it is ok
[16:33:47] <varnent>	true
[16:34:09] <varnent>	after the page drive - I'll be starting to just move extensions to either svn or git - depending on where we are
[16:34:31] <varnent>	I thought about ppl's comments about if we should vet them - if that'll upset ppl - but I think we just have to bite the bullet and do it already
[16:34:58] <sumanah>	hey, especially if you are taking the heat for it, I will defer to you
[16:35:05] <varnent>	lol - exactly
[16:35:30] <varnent>	"it was the crazy volunteer's fault" - sort of setting it up so folks can just be pissy with me about it - which I'm fine with  :)
[16:35:40] <varnent>	at least a broken extension has a chance of salvation on the repo rather than dying in the wasteland of wiki code space
[16:36:20] <varnent>	guillom: so I'm on prog committee for wikimania - need to figure out if there'll be any COI for submitting a proposal as well - but wanted to pick your brain on any proposals that are often missing / overlooked
[16:36:38] <varnent>	especially in regards to social media, 3rd party developers and 3rd party wiki sysadmins
[16:37:12] <guillom>	Hmmm.
[16:37:56] <guillom>	I don't think there's been a lot of focus in previous Wikimanias about 3rd party developers and 3rd party wiki sysadmins
[16:38:08] <guillom>	sorry, bad copy/paste, I meant sysadmins
[16:38:16] <guillom>	what do you mean by "3rd party developers" ?
[16:39:02] <varnent>	folks developing things for use outside the WMF umbrella
[16:39:52] <guillom>	So, basically, we could have a track for "Enterprise MediaWiki" ?
[16:39:54] <varnent>	for example - during the solicit donation discussions - it became clear (at least to me) that we have some developers that safely stay within the WMF umbrella (extensions that stand a chance of use on a WM project site) and others who venture into extensions and development that will never see a WM project, but are still a part of the MW effort
[16:40:01] <varnent>	lol
[16:40:03] <varnent>	oh that term
[16:40:22] <varnent>	well a track for "3rd Partyers" I guess
[16:40:50] <varnent>	I'll spare you the details - but there was a debate weeks ago on IRC about if "Enterprise MediaWiki" means all non-WMF wikis or just a niche of them
[16:40:56] <guillom>	"3rd party" sounds like we explicitly exclude them. I think they're part of our community.
[16:41:05] <varnent>	much to my dismay - "Third party wikis" won the day
[16:41:22] <varnent>	I tend to agree that a friendlier term is better
[16:41:54] <varnent>	but "3rd party" is generally accepted - and "Enterprise" is apparently too specific a type of wiki (I wasted about an hour of my life arguing otherwise)
[16:42:23] <guillom>	But yes, generally, I think such a track is a good idea. Especially since we'll be in D.C., and I expect there are many folks there who could talk about interesting stuff.
[16:42:45] <guillom>	I seem to recall the Diplopedia folks presented at WikiSym 2010.
[16:43:05] <varnent>	https://www.mediawiki.org/wiki/Project:Glossary#cite_note-EnterpriseIRC-0   -  because we're just that documentation oriented  :)
[16:43:19] <guillom>	And many other orgs/companies probably use MediaWiki internally as well.
[16:43:28] <varnent>	guillom: do you think there'd be enough interest/proposals for a 3rd party wiki / or whatever / track?
[16:44:06] <varnent>	it sounds like yes you do on the participant side - wondering about the presentation side
[16:44:46] <guillom>	I think it's possible to find a few people to submit interesting presentations about that topic, yes. It'll probably need dedicated outreach, though.
[16:44:52] <varnent>	although, we could use DC to help build momentum for a 3rd party track - I've already been talking with aude about keeping the developer/tech track alive
[16:45:14] <varnent>	hmm - I'll put some thought into that - might you be willing to help with some of that outreach?
[16:46:28] <guillom>	I'm not sure what I could bring ??? I don't know that world much. But if there are small tasks specific to my expertise, I guess I can.
[16:47:11] <varnent>	cool - maybe brain search the mental rolodex of any folks you think might be interested as well  :)
[16:47:18] <guillom>	ok
[16:47:28] <varnent>	doing outreach in general is a sort of unique topic I've discovered
[16:47:55] <varnent>	sumanah and I have been chatting about how to recruit non-core developers to volunteer - I imagine we'll face the same problem recruiting 3rd party folks
[16:48:31] <varnent>	there seems to be a disconnect between how WMF folks actually feel about 3rd party projects and how 3rd party projects think WMF folks feel about them
[16:49:01] <guillom>	Ah, assumptions...
[16:49:09] <varnent>	exactly
[16:49:42] <varnent>	I nudged Erik about some intentional 3rd party wiki outreach - will probably nudge again about it in a few months or weeks
[16:50:25] <varnent>	my general feeling is WMF is doing the work to be nice to 3rd party wikis - but not getting the credit for it - sometimes a visible sign that something is happening helps bridge the void between reality and perception  :)
[16:50:43] <varnent>	last Wikimania question - other than 1/8 of the enWP editors heads exploding - any reasons to have or not have a discussion about social media at Wikimania?
[16:51:05] <varnent>	btw - the enWP heads exploding is not necessarily a deal breaker - maybe more of an incentive depending on my mood
[16:52:14] *varnent 	has a love/hate relationship with some enWP editors
[16:52:27] <guillom>	Can you be more specific about "a discussion about social media"?
[16:52:56] <varnent>	that's a fair question - I could see one about social media on wikis to target the broader topic
[16:52:57] <guillom>	I know there's going to be a panel / discussion about the use of social media by Wikimedia orgs (WMF, chapters, etc.), but that's probably not what you're talking about, is it?
[16:53:25] <varnent>	yeah - more like a broader non-WMF specific chat - but maybe with the WMF specific panel it's too mucky for this year?
[16:53:51] *varnent 	hasn't decided if he wants to somehow be a part of the panel on social media or just buy popcorn and watch from the sidelines
[16:53:54] <guillom>	Do you mean the integration of social media and wikis?
[16:54:29] <varnent>	I suppose the broader questions of social media and wikis - how do the play together - are they related - how can wikis benefit social media outlets like blogs, etc.
[16:54:47] <varnent>	but that may be too broad - sort of a free floating thought at this point
[16:54:58] <guillom>	Ah. I don't think I have a lot of thoughts on the subject.
[16:55:13] <varnent>	maybe a discussion on the technical aspects of social media integration?
[16:55:20] <varnent>	although I feel like we'll have that resolved before July
[16:56:19] <varnent>	yeah - as we're talking about this and I'm thinking about it more - knowing more about the panel than I did when the idea first got on my blip screen - it may just be better to focus on that panel and not give the crazies too many more chances to continue the argument from there
[16:56:50] <varnent>	last question is outside the WM world altogether  :)
[16:57:09] <guillom>	:)
[16:57:17] <varnent>	the 3rd party wiki I'm the lead admin for is having our Inauguration (public launch) later this month (2/29)
[16:58:09] <varnent>	we're doing a last minute push for advisors - and I'm keen on finding some folks within WMF and WM who can bring that perspective and help us show that we're playing nice with WMF by having folks with WM in their "descriptions" to show on the board (the more self-serving reason)
[16:58:58] <varnent>	primarily though I want some folks that know wiki cultures and wiki tech (not necessarily all in one person) to help with our long-term chats and brainstorming - 1-2 hours a month - here's more info:  http://www.wikiqueer.org/w/WikiQueer:Advisor_Invitation   &   http://www.wikiqueer.org/w/WikiQueer:Global_Advisory_Board
[16:59:17] <varnent>	it's a LGBT project - but we're seeking broad base of advisors - so no LGBT assumptions made about advisors  :)
[16:59:32] <varnent>	something you may have any interest in or know folks that might?
[16:59:50] <guillom>	sorry, got distracted; reading
[16:59:55] <varnent>	np  :)
[17:00:36] *varnent 	has been a nominee for poster child of adult ADD - so I know distractions  :)
[17:01:07] <guillom>	ok, reading the pages now
[17:02:36] <varnent>	sumanah: did I tell you we put up a "no really - we like Wikimedia" page?  http://www.wikiqueer.org/w/WikiQueer:Wikimedia
[17:04:21] <Nemo_bis>	varnent, do you use scary transclusion?
[17:04:34] <varnent>	Nemo_bis: indeed we do
[17:04:39] <Nemo_bis>	so basically that means that you mainly contribute to Wikimedia projects directly?
[17:04:55] <varnent>	not exactly
[17:05:08] <Nemo_bis>	what pages on that wiki are from a LGBT perspective aka nNPOV?
[17:05:17] <varnent>	once the project is in full swing - I think only about 1/8 or less will come from or be tied into WM content
[17:06:06] <varnent>	Nemo_bis: we're working on a couple now - for the time being we've been pretty NPOV as we focus on the technical development of the wiki - but with the launch later this month - lots of content work happening this month
[17:06:34] <Nemo_bis>	ok, varnent, so what role will transclusion have?
[17:06:52] <varnent>	Nemo_bis: although this is a light example of what some would call a more LGBT vs neutral POV - http://www.wikiqueer.org/w/Campus_Pride
[17:07:08] <varnent>	Nemo_bis: this might be a good example:  http://www.wikiqueer.org/w/Massachusetts
[17:07:44] <varnent>	keeping in mind that content development has only recently taken priority - so I wouldn't characterize any of the articles as "done" or ready for display just yet  :)
[17:07:56] <Nemo_bis>	hm I see
[17:08:07] <Nemo_bis>	yes, I like this approach much more than the usual one
[17:08:18] <varnent>	thanks - we like it  :)
[17:08:37] <Nemo_bis>	too bad that you can't to scary-LabeledSectionTransclusion
[17:08:41] <Nemo_bis>	*do
[17:08:51] <Nemo_bis>	(that would be twice as scary)
[17:08:55] <varnent>	http://www.wikiqueer.org/w/Transgender is an example where we started with what could have been a direct transclusion - but wound up being revised enough that it split off for various LGBT POV reasons - http://www.wikiqueer.org/w/Transgender
[17:10:32] <varnent>	we transclude from other wikis as well - namely http://www.wikiqueer.org/w/WikiQueer:OutHistory
[17:10:35] <Nemo_bis>	where do I see the diff? :)
[17:11:30] *aude 	waves
[17:12:15] <sumanah>	btw Nemo_bis you know there are only 7 days left to apply for Wikimania scholarships?
[17:12:21] <aude>	varnent: 3rd party stuff is totally good for wikimania
[17:13:02] <Nemo_bis>	sumanah, yes, not interested
[17:13:07] *aude 	and other folks want to learn from wikihow, wikia, diplopedia, intellipedia, etc. ;)
[17:15:18] <varnent>	Nemo_bis: sorry - distracted - OutHistory is less "wiki" and more "exhibits" - so articles that only a small group can tweak rather than an open edit model
[17:15:53] <varnent>	Nemo_bis: so WikiQueer is where you document history as it's being made - OutHistory is where we document our collected thoughts afterward - so to speak
[17:16:23] <Nemo_bis>	ah ok
[17:17:00] <aude>	varnent: sumanah: is there a list somewhere of sites using mediawiki, besides wmf projects?
[17:17:13] <sumanah>	aude: unfortunately there are problems
[17:17:26] <sumanah>	aude: if we let people just add any site to such a list it turns into a spam haven
[17:17:26] <varnent>	aude: sort of
[17:17:40] <sumanah>	aude: but mediawiki.org and wikimatrix and some other such sites/places have some lists
[17:17:56] <varnent>	aude:  https://www.mediawiki.org/wiki/Sites_using_MediaWiki
[17:18:05] *varnent 	is a fan of wikiindex.org - the wiki of wikis
[17:18:24] <aude>	sumanah: i want to know some of the bigger ones
[17:18:37] <aude>	obviously, wikihow, wikitravel, wikia.... and my brain freezes :o
[17:18:48] <aude>	varnent: thanks
[17:21:32] <aude>	uncyclopedia, of course ;)
[18:07:29] <raindrift>	hey, werdna_, bsitu, are you guys around?
[18:07:52] <bsitu>	raindrift, yes we are
[18:08:11] <werdna_>	raindrift: I am
[18:08:29] <raindrift>	oh, good.  what are we doing today?  i'm not actually sure...
[18:08:53] <werdna_>	good question
[18:09:04] <gwicke>	guillom: ping
[18:09:08] <werdna_>	did you see howie's email?
[18:10:16] <raindrift>	oh, yes.  this email.
[18:10:45] <raindrift>	the one about how the logged-out page should create some visual distinction between login/create and request article.  that makes sense.  we should do that.
[18:11:04] <raindrift>	i think it makes sense to ask brandon what that should look like, unless one of you has a design in mind.
[18:11:43] <werdna>	yeah
[18:11:45] <werdna>	let's do that
[18:11:48] <werdna>	I'll wait till he gets in
[18:11:54] <raindrift>	sounds good.
[18:12:02] <bsitu>	sounds good
[18:12:03] <bsitu>	:)
[18:12:41] <werdna>	in the meantime, are we short on anything?
[18:12:46] <werdna>	or should I call this my 20% time?
[18:12:49] <raindrift>	aside from that, i think there's a few small js tweaks we might want to implement.  i'll write them down.  is there anything else that's still unfinished?  are we logging the page name in clicktracking?
[18:12:59] <werdna>	yep, we are
[18:13:02] <raindrift>	awesome
[18:13:38] <raindrift>	oh, yeah.  we should review all this code we checked in.  we can cross-review eachother's code, or we can ask someone else to look at it.
[18:14:20] <RoanKattouw>	I'd recommend cross-reviewing and bringing in someone else for things you're unsure about
[18:15:00] <raindrift>	RoanKattouw:  yeah, that sounds good.  it's not a super complex extension, so i bet we can just do it.
[18:15:27] <RoanKattouw>	Frontend stuff is typically fine
[18:15:45] <RoanKattouw>	just keep an eye out for XSS in the JS code
[18:15:57] <raindrift>	werdna, bsitu, do you want to call today a code review day mostly, and just start it off with the code we checked in?
[18:16:07] <RoanKattouw>	In the kind of extension you guys are writing, the DB schema is usually the most sensitive part
[18:16:14] <werdna>	which there is none
[18:16:19] <werdna>	\o/
[18:16:22] <RoanKattouw>	But from what I've seen I think raindrift knows a thing or two about MySQL query performance
[18:16:22] <raindrift>	RoanKattouw: will do.  since this accepts no user input, I expect little XSS exposure.  :)
[18:16:27] <RoanKattouw>	haha
[18:16:33] <RoanKattouw>	No user input, no DB tables? :O
[18:16:42] <raindrift>	pretty much, yeah.
[18:16:58] <raindrift>	it's basically a bunch of fancy hyperlinks and some clicktracking.
[18:17:02] <werdna>	I just had a massive neural timeout in which I forgot what the extension actually does.
[18:17:15] <bsitu>	:-D
[18:17:17] <RoanKattouw>	lol
[18:17:54] <RoanKattouw>	hmm, I guess this explains how 3 people wrote it in just 3 days
[18:18:40] <robla>	hiya AaronSchulz ...what're you planning to do today?
[18:19:03] <robla>	hexmode: what looks like the most urgent thing
[18:19:20] <AaronSchulz>	a few CR things, not much
[18:19:32] *AaronSchulz 	was looking at r111028
[18:20:52] *sumanah 	listens interestedly
[18:21:08] <robla>	!r 111028
[18:21:08] --elephant--	http://www.mediawiki.org/wiki/Special:Code/MediaWiki/111028
[18:22:55] <robla>	we're going to have to start tagging revisions for backport now, aren't we?
[18:24:06] <howief>	raindrift: sorry to hear you're not feeling well
[18:24:55] <raindrift>	howief:  i'm not doing that bad???  mostly sneezy, and i don't want to come down there and sneeze all over everything.  :)
[18:25:09] <howief>	sure
[18:25:11] <RoanKattouw>	robla: I already tagged the first this morning
[18:25:32] <howief>	were you guys able to chat about article creation today?
[18:26:03] <werdna>	howief: so our evil plan is code review today (hi sumanah) and then jorm will look at those design issues you pointed out
[18:26:19] *gwicke 	ponders what 'user interface design documents' for a parser might look like
[18:26:19] <howief>	sounds good
[18:26:41] <sumanah>	gwicke: as I am sure guillom would say, those templates should be adjusted per your best judgment
[18:26:49] <howief>	when do you guys plan to push something to prototype?
[18:27:02] <gwicke>	sumanah: ok ;) still amusing..
[18:27:16] <sumanah>	:)
[18:27:46] <hexmode>	robla: did I miss the 20%?  I changed my password and Linux isn't liking me now :(
[18:29:05] <werdna>	howief: well currently we're ready except for the design issues you brought up yesterday with the non-logged-in page
[18:29:28] <howief>	ok
[18:29:44] <howief>	have you guys given any thought to the A/B testing?
[18:29:57] <werdna>	testing between what and what, specifically?
[18:30:11] <howief>	putting the user though the new flow vs. not
[18:30:23] <werdna>	Well, we are indeed bucketing it to 1% of users
[18:30:26] <howief>	awesome
[18:30:34] <werdna>	and we're storing the titles of pages that are created with it
[18:30:35] <howief>	how is this being done?
[18:30:38] <howief>	nice
[18:30:45] <sumanah>	hexmode: AaronSchulz is looking for important things to do today
[18:30:46] <werdna>	which means we can compare survival rates
[18:30:50] <howief>	that's great
[18:31:09] *robla 	is off to next meeting now
[18:31:14] <hexmode>	AaronSchulz: found anything yet?
[18:31:21] <howief>	werdna: is the bucketing tied to the preference system?
[18:31:46] <robla>	hexmode: he's looking through the code review backlog
[18:31:57] <hexmode>	ah ... :)
[18:32:14] <werdna>	howief: no
[18:32:18] <werdna>	it's done with a cookie
[18:32:23] <werdna>	the same way moodbar bucketing was done
[18:33:06] <howief>	but existing users will have "speedy page creation" (not that we're going to use that verbiage) as a preference, correct?
[18:33:34] <werdna>	no, there isn't currently a way for an existing user to decide whether or not they are bucketed in
[18:33:43] <howief>	hmmm
[18:34:07] <howief>	so how are we going to implement the feature whereby existing users don't get the new flow?
[18:34:12] <guillom>	gwicke, sumanah , yes, feel free to remove anything that isn't relevant to this specific project. I usually don't remove them myself because I'm not the subject matter expert.
[18:34:13] <werdna>	is that a feature?
[18:34:18] <howief>	yes
[18:34:25] <werdna>	My impression was that we were giving it to a 1% cross-section of *all* users
[18:34:29] <werdna>	existing or not
[18:34:37] <howief>	actually no
[18:34:45] <gwicke>	guillom: ok
[18:34:59] <howief>	i think this may have been decided before you started working on the project
[18:35:11] <werdna>	raindrift:
[18:35:12] <gwicke>	I have commented it all out for now, but might use some of it later
[18:35:20] <howief>	we had decided on an implementation similar to moodbar
[18:35:39] <raindrift>	ahh, right.
[18:35:51] <raindrift>	i believe we discussed this, but we haven't added it yet.  we should do that.
[18:36:03] <howief>	awesome
[18:36:27] <howief>	so given that we need this feature, i'm wondering if it makes sense to tie the A/B split to preferences instead of cookie
[18:36:56] <raindrift>	howief:  we can't tie it only to the user pref, because we'll end up showing it to *way* too many people for a test.
[18:37:13] <howief>	(werdna the goal here is to not piss off our existing users who may be used to the existing flow)
[18:37:18] <howief>	raindrift: why?
[18:38:01] <raindrift>	howief:  i guess maybe i'm not sure how many 404's we return to new accounts + anons each day, but my impression was that it was a lot.
[18:38:42] <werdna>	raindrift's point is that we need to give it to a percentage of users who sign up after we deploy
[18:38:55] <werdna>	not all of them
[18:38:59] <werdna>	in other words, the bucketing needs to stay
[18:39:15] <werdna>	I don't think howief is saying otherwise, I think you've just confused each other
[18:39:18] <werdna>	:)
[18:39:25] <howief>	yeah i'm confused right now
[18:39:33] <raindrift>	okay.  lemme see if i can explain:
[18:40:13] <werdna>	Don't stress out too much about the exact implementation, but if that's a requirement then we can sort it out
[18:40:20] <werdna>	(howief)
[18:40:46] <raindrift>	we set the user pref, which means no existing users (actually, no autoconfirmed users) see the interstitial.  this leaves all new users, and all anonymous users.  presumably that's a lot of people.  then, we use the bucketing to run a test against a percentage of those remaining (non-autoconfirmed as of launch) users to see how their behavior changes with the interstitial.
[18:41:36] <raindrift>	but yeah, if we decide we don't want the bucketing, it's simple to turn it off.
[18:42:39] <raindrift>	We should have the user pref, though.  basically, if it's set, Special:ArticleCreationLanding should just redirect to the wikieditor.  Only applies to logged-in users, of course, since anons don't have userprefs.
[18:43:01] <howief>	ok that sounds right
[18:43:28] <howief>	and to be clear, what's the workflow for anon users as it relates to bucketing?
[18:44:59] <raindrift>	the way the bucketing works, it rewrites the link in the noarticletext template.  so, 1% of users (or whatever % we want) get linked to Special:ArticleCreationLanding/pagename, while the rest get a link to the wikieditor (which is the current behavior).  logged-in state doesn't matter, and a cookie keeps their bucket consistent.
[18:45:12] <raindrift>	when we do a real deployment, we turn off the bucketing code and change the template.
[18:45:20] <howief>	got it
[18:45:40] <bsitu>	besides that, I think we still need to change the article-missing page, there is no way for a logged-out user to get to the landing page or edit page
[18:45:54] <howief>	will there ever be a conflict between the cookie and the user preference?  It doesn't seem like there should be, but just thought I'd check
[18:46:14] <raindrift>	i don't think so.  they work differently???  the user pref should cause the special page to issue a redirect.
[18:46:30] <werdna>	oh okay, I see
[18:46:35] <werdna>	that's one way of doing it
[18:46:42] <raindrift>	bistu: we're changing the article-missing page with javascript at the moment.
[18:46:52] <raindrift>	werdna:  is there a better way?
[18:47:11] <werdna>	well, I had visions of magic words dancing in my head
[18:47:12] <raindrift>	bsitu, rather, not bistu.
[18:47:22] <werdna>	but I think your way is uglier but actually simpler than anything else
[18:47:30] <raindrift>	that's a good point.  we could do it with magic words.
[18:47:33] <jorm>	is this deployed anywhere?
[18:47:37] <werdna>	nope
[18:47:50] <raindrift>	err, it's deployed on my laptop.  :)
[18:47:53] <bsitu>	jorm, you can look at my screen, :-D
[18:48:02] <werdna>	http://andrew-macbook.local/article-creation/index.php?title=Special:ArticleFeedbackLanding/Foo
[18:48:03] <jorm>	coming over.
[18:48:41] <werdna>	http://andrew-macbook.local/article-creation/index.php?title=Special:ArticleCreationLanding/Foo
[18:48:44] <werdna>	that second one
[18:58:05] <werdna>	hey raindrift if I want to overlay two images in a background-image I need two elements right?
[18:59:53] <werdna>	slash jorm slash bsitu slash RoanKattouw
[19:00:09] <RoanKattouw>	I ... *think* so?
[19:00:15] <jorm>	i believe so, yes.
[19:00:19] <raindrift>	werdna:  yeah.  i'm pretty sure you do.
[19:00:23] <RoanKattouw>	Contrary to popular opinion, I'm not actually a CSS expert
[19:00:37] <werdna>	I still hassle you about it on a regular basis
[19:00:57] <raindrift>	werdna:  if it'd let you specify two images, which i don't think it will, it'd still be impossible to specify what goes on top.
[19:01:21] <RoanKattouw>	Well, I know more about CSS than you; I guess expertise is relative
[19:01:26] <AaronSchulz>	RoanKattouw: then pretend to be one
[19:02:25] <raindrift>	werdna: actually, there's a hack where you specify a background style for an <img> element, but it's sorta janky.
[19:07:00] <werdna>	jorm went on an orange juice safari
[19:08:07] <werdna>	seeing all the <s>animals</s> programs staff upstairs
[19:17:51] <werdna>	hey raindrift, are you working on preferences/bucketing or am I?
[19:18:45] <werdna>	in other news, if we have a preference, how do we explain it to users who try to turn it on and find that it doesn't work because they're not bucketed in?
[19:18:54] <werdna>	something I just thought of
[19:18:59] <werdna>	chrismcmahon: client trouble? :)
[19:19:17] <chrismcmahon>	werdna: just Colloquy doing what it does.
[19:19:30] <werdna>	yay
[19:19:42] <werdna>	are you in the office?
[19:20:26] <raindrift>	werdna:  hm, that's a good question.  we can throw a bit of text that says "experimental" next to it or something for now, which at least means "if this doesn't work, it's because we broke it"
[19:20:29] <werdna>	I don't remember if you're local from the welcome email
[19:20:37] <werdna>	raindrift: or we can have three options
[19:20:45] <chrismcmahon>	werdna: no, I'm remote.  I have some WMF hardware on the way RSN, too
[19:20:57] <werdna>	exciting!
[19:21:02] <raindrift>	werdna:  that's true, as long as it's possible to access the userprefs from javascript.  it is, yeah?  i'm just not sure where...
[19:21:05] <werdna>	are they pulling you in soon
[19:21:20] <werdna>	raindrift: um, it may or may not be, but in either case we can expose that information through ac.config
[19:21:33] <werdna>	usually when you start you end up visiting for a bit
[19:21:52] <chrismcmahon>	werdna: yes, a lot of remote people will be in SF first full week of March (including me)
[19:22:02] <werdna>	ahhh, I leave on the 24th
[19:22:09] <werdna>	of feb
[19:22:12] <raindrift>	sounds good.  so, do you want to make the userpref, or should i do it?  if i'm not doing that, i'll be doing CR
[19:22:18] <werdna>	raindrift: in fact, here's a thought
[19:22:37] <werdna>	For ANONYMOUS users, we use the bucketing code
[19:22:45] <werdna>	For LOGGED IN users, we use a preference exclusively
[19:23:11] <RoanKattouw>	chrismcmahon: Yay, I'll get to meet you then
[19:23:11] <werdna>	the only thing is, if they're bucketed in, we'll have to transfer that to a preference
[19:23:14] <werdna>	which means an ugly hook
[19:23:15] <werdna>	yay
[19:23:29] <werdna>	RoanKattouw: do you have a plane ticket over here yet? is your crazy dutch ski race happening?
[19:23:32] <chrismcmahon>	!b 1697
[19:23:32] --elephant--	https://bugzilla.wikimedia.org/show_bug.cgi?id=1697
[19:23:38] <chrismcmahon>	reported 2005 :)
[19:24:20] <RoanKattouw>	werdna: Plane ticket is being arranged, getting it approved is slow if the person buying the ticket and the person needing to approve it are on opposite sides of the worl
[19:24:39] <werdna>	ah
[19:24:45] <werdna>	Laura will get you sorted out :)
[19:24:49] <werdna>	she's good.
[19:24:52] <RoanKattouw>	And the skating race is off, at least for now. There's thaw coming in on Monday, and it wouldn't have been safe on Sunday
[19:24:54] <RoanKattouw>	Yeah
[19:25:00] <RoanKattouw>	She's also really busy right now so I did all the research :)
[19:25:26] <RoanKattouw>	There's a chance the frost will come back later next week but it's <50%
[19:25:37] <werdna>	your country is totally insane
[19:25:39] <werdna>	when are you coming?
[19:25:53] <werdna>	I'm at the giving-up point on A380 first-class with my FF miles
[19:25:55] <RoanKattouw>	Saturday or Sunday (18 or 19)
[19:26:02] <RoanKattouw>	Oh, which airline?
[19:26:05] <werdna>	QF
[19:26:08] <werdna>	for Wikimania
[19:26:08] <RoanKattouw>	ah
[19:26:34] <RoanKattouw>	Right, via LAX
[19:26:36] <werdna>	raindrift: I don't mind either way. You probably have more code to review than I do?
[19:26:52] <werdna>	RoanKattouw: well, a change in LAX has always been out. My options are:
[19:26:57] <RoanKattouw>	(PM?)
[19:27:01] <werdna>	yeah
[19:28:52] <raindrift>	werdna:  yeah, maybe.  if you don't mind making the pref, let me know what it's called and i can work it into the bucketing.
[19:29:21] <raindrift>	also, do we want a db script that sets it for all autoconfirmed users on deploy?  that seems like it should be just one query...
[19:29:31] <werdna>	yeah we can do that in mysql
[19:37:26] <jorm>	wait.  we want this thing to show up for new users, even if they get autoconfirmed.
[19:59:35] <werdna>	raindrift: committed
[20:00:11] <raindrift>	werdna:  awesome. i'll check it out.
[20:00:48] <raindrift>	jorm:  i believe the plan is to set the pref once ever.
[20:01:25] <werdna>	as in INSERT INTO user_properties (up_user,up_value) SELECT user_id,1 FROM user WHERE user_id > X;
[20:01:42] <werdna>	where X is max(user_id) as of a few days ago
[20:01:50] <werdna>	wait no
[20:01:53] <werdna>	the opposite
[20:02:18] <werdna>	WHERE user_id < X
[20:02:24] <werdna>	and set it to 0
[20:02:26] <raindrift>	werdna:  i think it's a little more complicated.  i don't think we want this for all users, just autoconfirmed???  if someone created an account last year that they never once used, we should still show them the interstitial.
[20:02:30] <RoanKattouw>	That's a lt of users
[20:02:58] <RoanKattouw>	You might want to flip the default if you're thinking about inserting millions of up rows
[20:03:22] <werdna>	it's supposed to be one default for new users and one for existing
[20:04:13] <werdna>	lunch in a sec
[20:04:58] <raindrift>	ya.  lunch.  i'll add the pref to the bucketing stuff when i return.  werdna, what's the revision # of that commit?  i can't seem to find it.
[20:50:50] <werdna>	raindrift: sorry, I missed a conflict
[20:50:57] <werdna>	raindrift: all done
[20:51:03] <raindrift>	heh.  np.  thanks!
[21:00:33] <werdna>	raindrift: where are we at?
[21:02:20] <werdna>	speaking of, TrevorParscal, where are you at today?
[21:02:23] <werdna>	WFH?
[21:02:33] <raindrift>	just finished lunch.  um, i think i need to get the bucketing to see the pref, and that's about it???  i guess we should go over it, maybe test in some browsers that are old and stuff.
[21:02:46] <werdna>	old and stuff indeed
[21:02:59] *TrevorParscal 	is wfh w/ sad tummy
[21:03:09] <werdna>	and the final remaining question is how we deal with people who actively enable/disable it
[21:03:36] <werdna>	TrevorParscal: :(
[21:03:48] <TrevorParscal>	i will be in tomorrow i think
[21:03:56] <TrevorParscal>	was just playing it safe
[21:04:04] <werdna>	nod nod
[21:05:16] <raindrift>	i wonder if we could make the default be a third value???  so, like, we have 'enabled', 'disabled', and 'never enabled'.  then always turn it on if it's enabled?
[21:05:38] <werdna>	we could have three options
[21:05:45] <raindrift>	we could also just ignore this problem, since it'll go away once we're done testing.
[21:05:49] <werdna>	"Enable", "Default", "Disable"
[21:06:16] <raindrift>	i dunno.  that sounds differently confusing, but still confusing.
[21:07:11] <raindrift>	oh, heh, we also still need code that *uses* the preference.  :)
[21:07:31] <werdna>	that too
[21:07:51] <werdna>	hmm, is there a howie about?
[21:08:06] <raindrift>	howief: ^
[21:08:56] <werdna>	Maybe a preference is not the best solution
[21:09:06] <werdna>	What we did for MoodBar was a bit different
[21:09:11] <werdna>	we had an account creation cutoff
[21:09:40] <werdna>	if the account was created after X date, it might have ended up with MB
[21:11:13] <raindrift>	totally, but we still want existing accounts that never use wikipedia to see this flow.  but maybe for now we leave the pref out and just show it to accounts created after a certain date, then switch it when we're not doing the bucketing anymore and the pref always makes sense?
[21:12:07] <jorm>	that seems fair.
[21:12:14] <raindrift>	then again, there's also that part where creating preferences is like UI design failure.  :)
[21:12:18] <jorm>	but mention this to dario so he has the opportunity to call you on it.
[21:12:29] <jorm>	if it goofs with his analytics.
[21:12:36] <jorm>	fewer preferences.
[21:12:51] <raindrift>	jorm: good point.  i'll write up this plan and send it around.
[21:34:39] <TrevorParscal>	RoanKattouw: you around?
[21:37:36] <raindrift>	werdna, bsitu: which way shall we go with the redlinks?  js redirect, double-redirect, implement bucketing in php?  my current thought is double-redirect since it keeps all the kludge inside the extension.  of course, when we're not bucketing we can remove it.
[21:37:52] <werdna>	bucketing isn't that hard to implement
[21:37:56] <werdna>	I'm tempted to implement it in PHP
[21:38:08] <werdna>	it's the clean, proper solution
[21:38:43] <raindrift>	that's true???  and it could be useful later.
[21:38:57] <werdna>	let's see if I can write it in the next 10 minutes
[21:39:03] <werdna>	if I can make some decent progress, let's go witht hat
[21:40:22] <raindrift>	okay.  sounds like a plan.
[21:41:09] <raindrift>	right now the bucket config is in the js directly, but we can move it into a php variable so we only have to keep one copy (see ArticleFeedback for an example of that sort of thing)
[21:54:27] <werdna>	raindrift: I have a prototype
[21:54:29] <werdna>	let me just test it
[21:54:54] <raindrift>	werdna:  that's amazing.
[22:14:02] <werdna>	RoanKattouw: who wrote clicktracking?
[22:14:11] <RoanKattouw>	Nimish
[22:14:44] <nimish_g>	werdna: to my defense, it was the very very first thing I wrote for mediawiki ever
[22:16:17] <werdna>	:D
[22:16:21] <werdna>	DarTar has some questions
[22:16:53] <RoanKattouw>	He's asking me in PM now
[22:17:17] <RoanKattouw>	nimish_g: Incidentally, I think UserDailyContribs must've been the second thing you wrote for MW ever?
[22:17:38] <RoanKattouw>	I was talking to Timo and I plan on killing it soon provided the stats people say no one's using it
[22:18:20] <werdna>	isn't it needed for CT?
[22:19:10] <RoanKattouw>	Well yeah, but only if you care about the edit count data for the past N months
[22:19:28] <RoanKattouw>	I guess I should ask the analytics people if they still do, if in fact they ever did
[22:24:22] <werdna>	raindrift: so we now have bucket code
[22:24:23] <werdna>	\o/
[22:27:40] <werdna>	raindrift: I'll modify the current code to use it
[22:29:08] <nimish_g>	RoanKattouw: haha yes it was. there's a bunch of editor survey stuff that uses the API calls in it
[22:30:08] <RoanKattouw>	Oh, right, Timo mentioned that
[22:43:43] <raindrift>	werdna:  awesome!  (sorry i was away ??? got a phone call)
[22:45:37] <werdna>	raindrift: no worries
[22:48:51] <werdna>	raindrift: so what do we have left? cross review and redesign of the anon page?
[22:50:10] <raindrift>	i think so, yeah.  i keep thinking there's other stuff, but it's not actually relevant anymore.
[22:50:15] <werdna>	sweeet
[22:50:25] <werdna>	let's find jorm and get the rest of that code reviewed
[22:50:46] <raindrift>	totally.  i'll continue looking through it.
[22:51:10] <raindrift>	oh.  also, we may want to add a click handler that closes the warning tooltip when you click outside button/tooltip.
[22:54:39] <werdna>	yeah, or at least a close button
[22:54:41] <werdna>	or something
[22:55:26] <raindrift>	yeah???  also, when you hover over the other buttons, the tooltips pop up underneath the warning one.
[23:02:54] <werdna>	do we want the grey effects to persist if the warning interstitial is present on another button>
[23:05:21] <werdna>	raindrift: I have those first two bits implemented (killing tooltips if anything's selected, and killing interstitials if somebody clicks outside them)
[23:06:48] <werdna>	raindrift: oh yeah, one other thing. The interstitial currently has a message in the middle. It's localised using jQuery.localize(), which won't allow HTML or even Wikitext, which means we can't do bullet points
[23:08:54] <raindrift>	do you have wfMsg available?  it should be in mediawiki.jqueryMsg
[23:09:28] <raindrift>	it should let you do a pretty significant subset of wikitext
[23:17:22] <werdna>	oooo
[23:18:10] <petan>	oooo
[23:18:40] <werdna>	raindrift: hmm, though I do like jQuery.localize()
[23:18:51] <raindrift>	It's a PEG-based wikitext parser that neilk wrote for uploadwizard.  it's moving into core as of 1.19, I believe.
[23:20:34] <raindrift>	err, not wfMsg.  that's the old php thing.  i'm confused.  the functions i'm thinking of are $.msg() and gM()
[23:20:42] <werdna>	mmm
[23:21:22] <raindrift>	used to be in an extension.  here are docs: https://www.mediawiki.org/wiki/Extension:JQueryMsg
[23:22:44] <raindrift>	anyway, the other option for doing nice formatting is to pull parsed wikitext from a Template, or make some HTML that pulls strings from multiple messages with $.localize()
[23:22:56] <werdna>	raindrift: that's what I've done (the latter)
[23:23:08] <werdna>	but the trade-off is that it won't let me insert the messages as wikitext or pure HTML
[23:23:11] <werdna>	I want to put a bullet list in
[23:23:24] <werdna>	but also to be flexible enough to allow anybody to put something else in
[23:23:36] <raindrift>	right.  i think if you just switch to $.msg from $.localize, you'll be able to do what you want.
[23:23:48] <raindrift>	(and tell RL that you need mediawiki.jQueryMsg)
[23:24:18] <raindrift>	(except, no capital Q???  mediawiki.jqueryMsg)
[23:25:01] <werdna>	The advantage of .localize() is I pass HTML from the server to the client with message key placeholders inside it
[23:25:04] <werdna>	and then localize() on the client
[23:25:08] <werdna>	it's incomparably convenient
[23:26:12] <werdna>	so I need to basically write an equivalent either for the server side or on the client side, but allowing raw HTML and wikitetx
[23:26:18] <raindrift>	oh.  i see.
[23:26:22] <raindrift>	you're right.  that is convenient!
[23:26:30] <werdna>	It's convenient for customizability
[23:26:44] <werdna>	you put the HTML with placeholders intact in the button configuration
[23:27:02] <werdna>	and then the client adds the appropriate stuff
[23:27:15] <raindrift>	right.  i understand now.  that's totally not what i thought it was.
[23:27:35] <raindrift>	but???  you'd like those messages to also be able to contain wikitext?
[23:28:41] <werdna>	or just HTML
[23:28:42] <werdna>	whatever.
[23:32:23] <raindrift>	hm.  yeah.
[23:34:54] <raindrift>	$.localize() is pretty straightforward.  it could be extended to use the other $.msg() pretty easily.  right now it appears to use its own internal $.msg() which just runs mw.msg.apply()
[23:35:59] <raindrift>	alternately, we could add a separate localize (or name it something else for clarity) to mediawiki.jqueryMsg
[23:36:52] <raindrift>	also, the comment in $.localize about IE6/7 makes me sad.
[23:48:31] <werdna>	raindrift: I fixed up .localize() so it works
[23:48:40] <werdna>	that *should* pass code review muster
[23:51:57] <raindrift>	heh.
[23:52:05] <raindrift>	what'd you end up doing?
[23:53:27] <raindrift>	i see.  that's totally a solution.
[23:54:23] <raindrift>	i can't immediately see any attack vectors there???  wait???  is it possible to override a message with wikitext?
[23:55:54] <raindrift>	yeah, you could conceivably replace the message with something in the MediaWiki namespace.  would that be a problem?  I don't think it would.
[23:56:02] <werdna>	There are a lot of XSS vectors in the MW namespace
[23:56:13] <raindrift>	yeah.  in a way, that's what it's for.
[23:56:43] <raindrift>	so, i guess if we've previously made the decision to trust the MW namespace, we're good.
[23:57:16] <werdna>	yeah
[23:57:22] <werdna>	worst case we can extend .localize() again
[23:58:01] <werdna>	speak of the devil
[23:58:25] <werdna>	hey jorm, are we going to do any redesigning of this anonymous user page to separate login / create account from everything else?
[23:58:54] <raindrift>	I put a comment to that effect in CR, but I feel like someone else should look at it too before I OK it.
[23:59:04] <raindrift>	just to verify that our assumptions are correct...