[00:00:03] ori-l: that is correct [00:00:12] danke [03:27:44] T13|needsCoffee: you couldnt make a more fucked up example could you? [03:31:51] example of what... do-dee-doo.. [03:32:08] T13|needsCoffee: blacklist bug [03:32:29] yes, lets totally post ways to circumvent the blacklist on a public bug [03:32:37] its best to pick a page that isnt a mile long and cluttered with 1000 other things [03:33:40] legoktm: I'm suprised it hasn't been marked security bug yet... that's up to wmf to do, no? [03:33:46] no [03:33:50] you dont file the bug in the first place [03:33:55] you send it to security@wm.o [03:34:06] security bugs are fine in BZ [03:34:08] Then again, I won't be able to contribute once done. [03:34:16] you just place them in Security [03:34:23] I didn't file bug.. just comment on it. [03:34:30] you can still move it [03:34:47] p858snake|l_: I'll move it if I can. [03:34:53] p858snake|l_: who can see/comment on the bug at that point? [03:35:14] Betacommand: anyone in cc or the staff group on bz [03:35:14] Betacommand: anyone cc'd on it + people who signed NDA [03:38:32] Signed NDA? How do I do that? [03:39:02] you prick your thumb and mash it against the page [03:40:06] ori-l: dint work you jerk. Now my thumb hurts.. [03:40:13] :p [03:41:23] T13|needsCoffee: by going though the initiation one night at a wikimania [04:18:50] ori-l: <3 [04:19:25] <3 <3 <3 <3 [04:23:38] False [05:02:22] (Mobile) Content is available under CC BY-SA 3.0 unless otherwise noted. | (Desktop) Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply… [05:02:36] ugh, we really should clean that up so they both have the same text and link [05:02:54] /cc Elsie [05:03:09] File a bug. [05:03:10] Also, [05:03:12] copyright is evil. [05:03:51] no, there's a bug already [05:04:18] that bug is for something else iirc [05:05:27] which one? :) [05:06:05] https://bugzilla.wikimedia.org/53595 [05:06:19] * jeremyb runs away [09:45:46] thumbnails of [[File:WiktionaryPt.svg]] not updating since yesterday :( [09:46:45] can someone somehow force its regeneration? [10:03:13] malafaya: purge it ? :-) [10:03:39] malafaya: get to https://commons.wikimedia.org/wiki/File:WiktionaryPt.svg , press [Edit] [10:03:47] malafaya: then in the URL bare replace action=edit by action=purge [10:03:59] might just work [10:04:41] hashar: you could've just said 'click https://commons.wikimedia.org/wiki/File:WiktionaryPt.svg?action=purge' [10:04:47] lazy [10:07:08] you typed out 4 extra lines instead! [10:07:13] hashar: not lazy enough :PP [10:07:59] i already tried that 10 times, without success :) [10:08:10] since yesterday [10:09:44] what is the problem? [10:10:19] ahh [10:10:26] the logo is not set to that file: hashar@tin:~$ mwscript eval.php --wiki=ptwikisource [10:10:27] > return $wgLogo [10:10:28] /upload.wikimedia.org/wikipedia/sources/b/bc/Wiki.png [10:10:56] err [10:11:07] this is going to be the logo for *wiktionary* [10:11:15] hashar@tin:~$ mwscript eval.php --wiki=ptwiktionary [10:11:16] > return $wgLogo [10:11:17] /upload.wikimedia.org/wiktionary/pt/b/bc/Wiki.png [10:11:17] but at 200px the image does not correspond [10:11:17] same :-) [10:11:48] malafaya: your logo is local to the wiki at https://pt.wiktionary.org/wiki/Ficheiro:Wiki.png [10:11:53] malafaya: we can change it to commons though [10:12:23] or just generate a png out of the svg file and send it on https://pt.wiktionary.org/wiki/Ficheiro:Wiki.png [10:12:39] hashar, that is already underway [10:12:44] that is not the problem :) [10:12:46] malafaya: you can upload https://upload.wikimedia.org/wikipedia/commons/thumb/c/cc/WiktionaryPt.svg/140px-WiktionaryPt.svg.png :-) [10:13:15] it's already there as WiktionaryPt-png [10:13:19] .png [10:13:32] only the cached thumbnails is the problem [10:13:49] which thumbnail? do you have a link please ? [10:13:58] https://commons.wikimedia.org/wiki/File:WiktionaryPt.svg [10:14:05] the image you see is wrong [10:14:22] what is wrong in it ? [10:14:24] at 200px, it's also wrong: https://upload.wikimedia.org/wikipedia/commons/thumb/c/cc/WiktionaryPt.svg/200px-WiktionaryPt.svg.png [10:14:35] at 500px, it's the correct image: https://upload.wikimedia.org/wikipedia/commons/thumb/c/cc/WiktionaryPt.svg/500px-WiktionaryPt.svg.png [10:14:56] ahhh [10:14:58] unvinersal [10:15:00] I got it [10:16:33] purging does not work :-( [10:17:53] right [10:20:57] sorry no clue [10:21:26] paravoid: we got a purge issue of some sort with the Wiktionary logo :/ [10:21:58] the file is https://upload.wikimedia.org/wikipedia/commons/c/cc/WiktionaryPt.svg , at the bottom is "o dicionario unvinersal liver" [10:22:10] the 391px version has it [10:22:28] the 392px as an old version of the sentence (O dictionario livre) https://upload.wikimedia.org/wikipedia/commons/thumb/c/cc/WiktionaryPt.svg/392px-WiktionaryPt.svg.png [10:22:51] the 500px is outdated as well [10:22:58] I tried purgeList but that did not do the trice :/ [10:23:00] trick [10:23:05] hashar it's the other way [10:23:11] 500px is right, 200px is not [10:23:26] the shorter text is the current one [10:24:09] If I download the SVG https://upload.wikimedia.org/wikipedia/commons/c/cc/WiktionaryPt.svg , it show the long sentence with "unvinersal" [10:24:21] yes, but that is also wrong [10:24:29] i already tried uploading it 4 times and no change [10:24:35] or reverting [10:26:15] i can try again reverting to the 1st revision (without "unvinersal") but that didn't work in other times [10:26:58] (btw "unvinersal" is "universal" mistyped) [10:27:55] Steinsplitter had a similar problem yesterday around the same time [10:28:07] i don't know if it's solved for him [10:28:36] the files served from US and Europe are different :/ [10:29:01] the one served by the US cache is fine [10:29:06] the one from Europe are stalled huhu [10:29:12] I guess the purges are not send to amsterdam [10:29:20] malafaya: you need to wait [10:29:30] cache is evil [10:29:37] hmmm, so i now understand why we couldn't understand each other in the discussion at the Beer Parlor [10:29:56] I see an image, and the guys from Brazil see another one... :S [10:30:14] Steinsplitter: i already slept on it :) [10:30:14] a other user has reported a similar problem on my disk yesturday. [10:30:40] i guess we will have to celebrate Xmas on it :) [10:33:29] malafaya: depending on your region, you will use different servers [10:33:43] the user from Brazil is most probably redirected to a cache server in our US datacenter [10:33:47] hashar: https://ganglia.wikimedia.org/latest/?c=Swift%20pmtpa&m=cpu_report&r=hour&s=by%20name&hc=4&mc=2 [10:33:59] while European uses are send to a cache server in Amsterdam (i.e. in europe) [10:34:12] the caches have different versions, apparently the one serving european traffic has an old copy :-) [10:34:45] hashar: red = slow / down^^? [10:35:06] Steinsplitter: == busy :-] [10:35:12] Steinsplitter: it has been like that for at least a week [10:35:23] even more in fact [10:36:09] commons = trafficmonster :P [10:37:14] bottom line, it will eventually catch up, no intervention is needed, right? [10:37:25] malafaya: or it might be broken [10:38:50] hashar: short questio, why in November 200G and now in September 700+ o_O ? https://ganglia.wikimedia.org/latest/?r=year&cs=&ce=&m=cpu_report&s=by+name&c=Upload+caches+esams&h=&host_regex=&max_graphs=0&tab=m&vn=&sh=1&z=small&hc=4 [10:39:26] malafaya: please file a bug in Wikimedia>Media storage for the broken esams purges (again) [10:39:27] Steinsplitter: I hvae no idea [10:39:35] Steinsplitter: I guess swift started being used in april ? [10:39:51] hashar: thanks for filing https://bugzilla.wikimedia.org/show_bug.cgi?id=54628 , am I supposed to do something about it? :[ [10:40:01] Nemo_bis: reproduce the issue and fix it ? :-D [10:40:14] hashar: erik has writed a mail on mailinglist becose of too much traffic (scripts), we hav enabled HotCat for all users erc. :/ this jear [10:40:23] Nemo_bis: maybe the GlobalBlockingBlockedIpMsg hook has been changed in core, I haven't looked [10:40:39] hmm its is not a core hook err [10:40:44] hashar: it was added by my patch [10:40:48] morning, all. I am importing some tables from the database. i use "mysql nlwiki --user=root --password=""< c:\www\nlwiki-latest-pagelinks.sql". but it takes forever. is there a way to speed this up? is the xml faster? should i have a complete mediawiki install to use the xml? [10:41:36] Nemo_bis: apparently wfRunHooks expect an array as a second parameter but you are passing a string [10:41:40] + $blockedIpMsg = 'globalblocking-ipblocked'; [10:41:41] + wfRunHooks( 'GlobalBlockingBlockedIpMsg', &$blockedIpMsg ); [10:42:02] function wfRunHooks( $event, array $args = array() ) { [10:42:06] hashar: it's my first experience with hooks; it's probably very easy and quick to fix if one knows how, so if someone else does it it's best otherwise I'll have to get some headaches [10:42:25] hmm that was just copied from the example above it on WikimediaMessages iir [10:42:25] Nemo_bis: potentially you "just" have to wrap the string in an array() statement [10:42:28] c [10:42:31] yeah [10:42:39] I am not familiar with hooks though [10:43:15] Z5: that is quite a big file, so that definitely takes a long time :) [10:43:33] Z5: a possible speed up is to have the source file on a disk which is not the one used by mysql [10:43:40] Z5: or use two computers. [10:43:59] (one to read the .sql, the other being the db) [10:44:02] #1: check, mysql runs on E: #2. doesnt the network slow it down? [10:44:18] yeah network might be a bottleneck [10:44:34] but disk I/O is most probably what is slowing down the import [10:44:40] +mysql processing [10:44:41] not have gigabyte fibreglass here ;-) [10:45:12] yes, the mysql data files are on the same disk as the import file. see if i can change that around. [10:45:25] malafaya: do you hav opened a bug about the cacheproblem? if no i go to open a bug? [10:45:29] but i can't expect the xml import to be faster? [10:45:42] Steinsplitter: just finished: bug 54629 [10:45:47] https://bugzilla.wikimedia.org/show_bug.cgi?id=54629 [10:47:52] thx [10:48:01] np [10:48:14] the xml import would be much slower, orders of magnitude slower in fact. [10:48:52] thanks both hashar & apergos [10:49:31] Z5: so you have a process reading the .SQL and another writing in the database. Both racing for I/O on the disk :/ [10:49:38] Z5: different disks will definitely help [10:50:10] thx. i'll try that for the next import. dont want to lose last day's processing ;-) [10:51:37] Z5: we also have database replications which are made "publicly" available to virtual instances [10:51:52] Z5: you can get an instance created there and use those database, that will save you the import work [10:51:58] hey that sounds interesting hashar [10:52:04] let me find the llink [10:52:27] ah Z5 https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools [10:52:30] hope its not a hassle like getting a toolserver account :-) [10:52:56] that is the replacement of the toolserver [10:53:08] shell requests are handled in a timely manneer usually [10:53:18] thx. i'll have a look....... [10:53:21] you can get more information by joining #wikimedia-labs , though it is quiet right now [10:53:25] I have one. It was not difficult. [10:53:29] Z5: there is a bunch of doc at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help [10:53:57] Z5: once connected, you will be able to access the databases views: https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help#Connecting_to_the_database_replicas :-D [10:54:20] Z5: which is updated continuously from production. So whenever something change on the nlwiki site, it is available to your tool "instantly" [10:56:13] that looks very nice. i may apply for an account soon. thanks again, hashar [10:57:22] Z5: and make sure to join #wikimedia-labs :-] [10:58:38] :) [11:08:57] weird that wikitech.wikimedia.org doesnt use SUL [11:09:20] It doesn't? [11:09:51] I've never noticed. [11:09:57] had to create a new account https://wikitech.wikimedia.org/w/index.php?title=Special%3ALog&type=newusers&user=Zanaq&page=&year=&month=-1&tagfilter= [11:10:34] Huh, I don't remember having to. [11:10:46] weird [11:27:00] its not part of the normal cluster [11:27:09] its actually a labs instance [11:36:00] hashar, Steinsplitter, the bug was fixed [11:36:11] but I still see the same result even after purging [11:36:40] Thanks to Mark and Bawollf [11:36:49] and Hashar :) [11:36:50] and faidon [11:37:29] so now we need to wait for it to update, or what? [11:39:01] i'm not sure it's the right data, but i'm looking for "vhtcpd_inpkts_dequeued " to decrease [13:41:28] p858snake: wikitech is most certainly not a labs instance [13:42:48] anomie: ping [13:42:58] jeremyb: pong [13:43:10] moin moin [13:43:18] https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&diff=prev&oldid=574559454#http_login_issue [13:44:09] hashar: please use kick powers:) [13:44:17] was gonna say [13:44:20] just saw you have them [13:44:33] i had a msg to him preloaded for when he's back. but then i looked away [13:45:37] mutante: I am not an admin on wikipedia [13:45:47] hashar: he wants you to op this channel [13:45:53] and /kick [13:46:22] robertknight: fix your connection [13:46:32] mutante: you are op now [13:46:34] /query chanserv access #wikimedia-tech list [13:46:43] I wish we had autoop [13:46:58] ewwww, why? [13:47:08] hashar: see that access list, wikimedia cloak gets +V but +o is individual [13:47:09] this way we don't have to query chanserv [13:47:14] hashar: can you add me to the list? [13:47:14] and can directly /kick :D [13:47:33] jeremyb: gerrit 85776 is merged. However, see bug 54513, there may be a caching issue going on too [13:47:39] +V is autovoice [13:47:42] that's not a wikimedia cloak [13:47:54] anomie: i thought maybe we were waiting for a branch to cut [13:48:11] mutante [~mutante@wikimedia/mutante] [13:48:24] anomie: anyway, want to comment there? :) [13:48:32] I requested we grant auto op to some people [13:48:42] jeremyb: I meant to say "gerrit 85776 is deployed", sorry. I just checked on tin and it's showing in both 1.22wmf17 and 1.22wmf18 [13:48:51] shouldn't be auto, just want to use op command when needed [13:49:06] jeremyb: Not really, but I suppose I should [13:49:42] * jeremyb also would like a place on that list :) [13:49:51] anomie: :P [13:50:38] I don't have the +f flag so can't tweak the access lists :D [13:51:10] you don't need that to tweak access lists [13:51:18] hashar should maybe read the freenode docs on channel guidelines :) http://freenode.net/channel_guidelines.shtml [13:51:28] and this channel does not even use templates :-( [13:51:30] > Don't keep channel operator privileges. [13:53:20] it's alright, as long as somebody is there to do it, not like we need it every day [13:54:36] and seems it also made him stay out of -operations, thanks hashar [18:08:24] manybubbles: if you have a moment, updated https://gerrit.wikimedia.org/r/#/c/86003/ per your comments [19:15:02] chrismcmalunch: looks good to me. I'm happy to +2 if you think it is my place to +2 VE tests. (in other words, if there isn't anyone better:) [19:24:45] Hello [19:25:13] Hi! Some users are reporting getting the error "Fatal exception of type MWException" on the Dutch Wikipedia. [19:25:16] There is currently (new since earlier today) an error when I log in [19:25:37] [5dade818] 2013-09-26 19:25:31: Fatal exception of type MWException [19:25:53] seems to be something with centrollogin [19:26:05] https://login.wikimedia.org/wiki/Special:CentralLogin/start?token=....... [19:26:19] that's where it takes me to, althought I logged in at nl-wiki [19:26:46] then when I go back I'm simply logged in. [19:27:07] Reedy: ^^ [19:27:13] Yes [19:27:17] There's only so much I can do at once [19:27:53] URL: http://login.wikimedia.org/wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=nlwiki&proto=https&type=script&returnto=Lijst_van_Nederlandse_muziek&returntoquery= [19:27:53] Backtrace: [19:27:53] #0 /usr/local/apache/common-local/php-1.22wmf19/includes/DefaultSettings.php(3331): unknown() [19:27:54] Sigh [19:28:18] same issue, yes? [19:29:36] Hmm [19:29:45] They're all old timestamps on nlwiki [19:29:46] [26-Sep-2013 18:47:24] [19:30:10] manybubbles: I'd take a +2, it's better than self-merging. :-) I reviewed it with Zeljko this morning but he's out tomorrow traveling to the CITCON conference [19:32:14] merged [19:32:20] chrismcmahon: merged [19:32:31] manybubbles: thanks [19:33:56] * Reedy waits for scap to finish before doing anything else [19:34:09] * greg-g nods [19:34:14] if Brion's fix worked, why did we have to revert to 18? [19:34:47] reedy@fluorine:/a/mw-log$ grep 5dade818 exception.log [19:34:47] 2013-09-26 19:25:31 mw1169 loginwiki: [5dade818] /wiki/Special:CentralLogin/start?token=49a1dd0d3f532de45b7919ab7066a360 Exception from line 316 of /usr/local/apache/common-local/php-1.22wmf19/includes/MagicWord.php: Error: invalid magic word 'revisionsize' [19:34:56] ah. [19:34:59] Scap done [19:35:14] let's see if mediawikiwiki and the test wikis are less broken [19:35:29] I'm somewhat disoriented by not having my standard work computer, sorry. [19:35:49] mw.org is slow but works.. [19:36:44] {{REVISIONSIZE}} works [19:40:12] greg-g: Something we should query with csteipp - Should loginwiki still be a phase1 wiki? [19:43:04] We moved it there because with CentralAuth, we were getting weird things happening when the attached wikis were running newer code that the central wiki.... but we could switch it to a later phase now that we've switched entirely to sul2 [19:58:24] https://en.wikipedia.org/wiki/Wikipedia_talk:Special:DoubleRedirects#Are_double_redirects_still_being_fixed_by_bots.3F in case someone here can do something about it [19:59:08] Reedy, mutante, is it ok to ask for a manual special page update? [19:59:27] last one was on 10th Sept [20:00:16] Why do them manually? [20:00:29] rather, why isn't it being done automatically? [20:00:31] cause they're still not running automatically [20:00:40] is this a known issue? [20:00:48] Why doesn't someone fix the problem then? [20:00:50] as far as i was told, yes [20:00:56] dont know [20:01:05] Rather than asking every 2 weeks for it to be done manually [20:01:09] Nemo_bis? you know why? [20:01:21] yes, i would much prefer that! [20:01:23] Seems like a better use of effort [20:01:29] As we'll be in the same place in 2 weeks again [20:01:30] Reedy: do you know why it's happening? It's been crossposted to AN; it would help if you could explain what's going on there. [20:01:57] What does posting to WP:AN do for anyone? [20:02:02] Nothing [20:02:11] it stops a bunch of nontechnical people running around spreading misinformation? [20:02:16] i recall someone saying that the cron jobs would have to move away from server X to server Y [20:02:16] that tends to help. [20:02:59] it also stops people like me from bothering you folks every other day because we don't know it's a known issue already :) [20:03:34] please? [20:03:36] what's AN [20:03:43] to me it's just a post-fascist party [20:04:14] update_special_pages has already moved server [20:04:15] or you could tell me and I could post there. So long as people get to know what's going on. >.< [20:04:47] i last discussed this problem here on Sept 9, 21:53:32. so some info is available at http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-tech/20130909.txt [20:04:56] some things you can do include 1) checking the code on puppet, 2) locate logs, 3) ask someone to check them up [20:05:49] empty log file is log [20:05:51] *empty [20:07:31] malafaya: so is the issue the same one as https://bugzilla.wikimedia.org/show_bug.cgi?id=53227 ? [20:07:37] if so I'm just going to link to that [20:07:51] i believe so, yes [20:08:01] okay, I'll comment then. [20:08:16] the dates more or less match my observations with 24 hours tolerance [20:09:09] oh, yes, i even commented it. that's correct [20:10:17] command => "flock -n /var/lock/update-special-pages /usr/local/bin/update-special-pages > /var/log/updateSpecialPages.log 2>&1", [20:10:42] reedy@terbium:/var/log$ ls -al [20:10:42] total 198220 [20:10:42] drwxr-xr-x 19 root root 4096 Sep 26 06:25 . [20:12:18] mutante: https://gerrit.wikimedia.org/r/#/c/83574/ [20:12:22] nooooooo rebase fail [20:13:50] oh, month additions.. [20:15:50] wctaiwan: malafaya - thank you for bringing our attention to this issue and communicating with the wider world as well [20:16:08] np [20:16:18] you are Ambassadors :-) https://meta.wikimedia.org/wiki/Tech/Ambassadors [20:16:28] Or removed.. [20:17:13] sumanah, cool. i wasn't aware of that concept :) [20:17:17] :) [20:17:35] it's super useful to have folks translating & bridging [20:19:54] if you post anything about this to en.wikipedia.org , could you perhaps ensure it does get posted to https://en.wikipedia.org/wiki/Wikipedia:VPT and perhaps linked to at WP:AN or something like that? Village Pump-Technical seems to be where a lot of people look for info about this kind of thing [20:20:09] and if you felt like updating https://meta.wikimedia.org/wiki/Tech/News as well, that would be super bonus [20:22:01] I'll do VPT. I'll leave meta to someone who's actually active there. [20:23:08] i'm not very active on EN:WP [20:23:17] wctaiwan: with the meta tech news, it is acceptable to just leave a raw link to the VPT post in the raw draft of the next issue, and then someone else will happily shape it into useful prose. (Also okay to not do it, of course ) [20:25:25] Reedy: just so I'm clear, is the issue fixed, and we're just waiting for the fix to propagate, or is the issue still not fixed? [20:25:29] Reedy, so the changeset you made was still not live? [20:25:38] :) [20:25:44] It's not merged so of course it's not live [20:25:45] same time [20:25:54] ok [20:25:57] and now stupid kafka [20:31:03] * sumanah silently erases the "of course" :-) [20:31:32] greg-g: if you wanna come in and play interference, you're welcome to; I gotta pack up & leave my coworking space [20:51:02] Reedy, so what's the status now? Awaiting review? [21:24:18] Reedy: when is MassMessage getting deployed? [21:43:24] Hey WMF-Staff: Would it be possible to apply certain templates, like Template:!, with a level of protection so high that only WMF staff / developers could edit it? [21:47:16] Sven_Manguard: "WMF Staff/developers" isn't really a group that is maintained easily. We have people with shell access, which tend to predominately be WMF employees, but there are others as well [21:47:25] they could do anything they want, basically [21:47:33] okay [21:47:47] the important thing is that it becomes uneditable by all but those given very well guarded keys [21:47:54] * greg-g nods [21:48:03] why not just add a comment to the template that says "if you touch this, your admin rights will be revoked immediately and globally"? [21:48:03] I'm not sure on the right way of going about that [21:48:09] because enWiki looks to be giving out template editng to non-admins [21:48:21] wait. really? that's insanity [21:48:38] for all templates? even those that are protected? [21:49:14] templates are already editable by normal users, as far as I know [22:00:28] Ryan_Lane: what they're actually doing is creating a protection level between autoconfirmed and sysop [22:00:41] Ryan_Lane: and going to use it for most templates that are fully-protected now [22:00:53] Ryan_Lane: yes [22:00:56] Ryan_Lane: and going to give the relevant right without the RFA fuss [22:01:02] Ryan_Lane: https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Template_editor_user_right [22:01:06] (that's the gist, as i understand it) [22:01:50] Sven_Manguard: responding to your initial question – technically it might be possible [22:01:55] The issue is that some templates that are protected, like those that underpin the DYK nomination process, make sense to allow some people to edit, while others, like those that make the main page work, make much less sense to give people the right to edit [22:02:19] Sven_Manguard: but you'd need to assing all people who can set this protection level and editp ages protected by it in to a separate user group [22:02:22] MatmaRex: Good, because if that thing I linked to passes, which it very well might, the DEVs might want to start locking down pages [22:02:31] Sven_Manguard: and that would kinda suck and not make any sense [22:02:43] Sven_Manguard: since there'd have to be someone who could assing people to that group [22:03:04] also, wat [22:03:12] why would the devs "want to start locking down pages" [22:03:17] also, define \devs\ [22:03:19] 'devs' * [22:04:00] MatmaRex: I mostly worry about templates that are in use several million times, where an edit will cause cache issues and drag the site to a halt (theoretically) [22:04:23] Hell, I worry about many /admins/ having the right to touch those [22:04:24] don't edit them, then [22:04:45] ops will be there to fix wikipedia if you break it [22:04:55] Why do we even *allow* people to edit Template:! in the first place. It will never need to be edited [22:05:00] (just try not to exercise them needlessly :P) [23:12:04] Nemo_bis: who needs to review this now: https://gerrit.wikimedia.org/r/#/c/85516/