Wikitech-l September 2013

wikitech-l@lists.wikimedia.org

137 participants
126 discussions

Re: [Wikitech-l] AbuseFilter error codes and MobileFrontend
by Andrew Garrett 29 Sep '13

29 Sep '13

Apologies, I always forget to hit "Reply All". -------- Original Message -------- Subject: Re: AbuseFilter error codes and MobileFrontend Date: Sat, 21 Sep 2013 10:11:28 +1000 From: Andrew Garrett <agarrett(a)wikimedia.org> To: Juliusz Gonera <jgonera(a)wikimedia.org> Juliusz Gonera wrote: > > After getting some initial information from legoktm, my thoughts are: > > * Probably no changes to AbuseFilter are necessary and we should > implement everything in MobileFrontend. > > * We should display the warning message (edit.warning in API response) > for all codes (edit.code in API response) that start with > abusefilter-warning* and allow the user to resubmit. > * We should display the disallow message (edit.warning in API > response) for abusefilter-disallow and not allow the user to resubmit. > * We should display edit.warning message if present or a general one > and not allow the user to resubmit for all the other error codes > (until now we've got abusefilter-blanking, abusefilter-blank, > abusefilter-imza, abusefilter-blocked-display and > abusefilter-autobiography, but they don't happen too often). You should know about this change[1], which corrects the error messages to be more in line with the general case, as well as adding some metadata. It's not been approved yet, so I'm nudging a few reviewers. You can also determine which mobile edits are hitting filters, by looking for edits in the filter log which have 'user_mobile = 1' set. I'm not sure I quite remember how to search in that way, but I'll look into it. [1] https://gerrit.wikimedia.org/r/#/c/80137/

4 7

Bulk download
by Mihai Chintoanu 29 Sep '13

29 Sep '13

Hi everyone, I have a list of about 1.8 million images which I have to download from commons.wikimedia.org. Is there any simple way to do this which doesn't involve an individual HTTP hit for each image? Many thanks in advance. Mihai

8 10

Can we help Tor users make legitimate edits?
by Sumana Harihareswara 28 Sep '13

28 Sep '13

TL;DR: A few ideas follow on how we could possibly help legit editors contribute from behind Tor proxies. I am just conversant enough with the security problems to make unworkable suggestions ;-), so please correct me, critique & suggest solutions, and perhaps volunteer to help. The current situation: https://en.wikipedia.org/wiki/Wikipedia:Advice_to_users_using_Tor_to_bypass… We generally don't let anyone edit or upload from behind Tor; the TorBlock extension stops them. One exception: a person can create an account, accumulate lots of good edits, and then ask for an IP block exemption, and then use that account to edit from behind Tor. This is unappealing because then there's still a bunch of in-the-clear editing that has to happen first, and because then site functionaries know that the account is going to be making controversial edits (and could possibly connect it to IPs in the future, right?). And right now there's no way to truly *anonymously* contribute from behind Tor proxies; you have to log in. However, since JavaScript delivery is hard for Tor users, I'm not sure how much editing from Tor -- vandalism or legit -- is actually happening. (I hope for analytics on this and thus added it to https://www.mediawiki.org/wiki/Analytics/Dreams .) We know at least that there are legitimate editors who would prefer to use Tor and can't. People have been talking about how to improve the situation for some time -- see http://cryptome.info/wiki-no-tor.htm and https://lists.torproject.org/pipermail/tor-dev/2012-October/004116.html . It'd be nice if it could actually move forward. I've floated this problem past Tor and privacy people, and here are a few ideas: 1) Just use the existing mechanisms more leniently. Encourage the communities (Wikimedia & Tor) to use https://en.wikipedia.org/wiki/Wikipedia:Request_an_account (to get an account from behind Tor) and to let more people get IP block exemptions even before they've made any edits (< 30 people have gotten exemptions on en.wp in 2012). Add encouraging "get an exempt account" language to the "you're blocked because you're using Tor" messaging. Then if there's an uptick in vandalism from Tor then they can just tighten up again. 2) Encourage people with closed proxies to re-vitalize https://en.wikipedia.org/wiki/Wikipedia:WOCP . Problem: using closed proxies is okay for people with some threat models but not others. 3) Look at Nymble - http://freehaven.net/anonbib/#oakland11-formalizing and http://cgi.soic.indiana.edu/~kapadia/nymble/overview.php . It would allow Wikimedia to distance itself from knowing people's identities, but still allow admins to revoke permissions if people acted up. The user shows a real identity, gets a token, and exchanges that token over tor for an account. If the user abuses the site, Wikimedia site admins can blacklist the user without ever being able to learn who they were or what other edits they did. More: https://cs.uwaterloo.ca/~iang/ Ian Golberg's, Nick Hopper's, and Apu Kapadia's groups are all working on Nymble or its derivatives. It's not ready for production yet, I bet, but if someone wanted a Big Project.... 3a) A token authorization system (perhaps a MediaWiki extension) where the server blindly signs a token, and then the user can use that token to bypass the Tor blocks. (Tyler mentioned he saw this somewhere in a Bugzilla suggestion; I haven't found it.) 4) Allow more users the IP block exemption, possibly even automatically after a certain number of unreverted edits, but with some kind of FlaggedRevs integration; Tor users can edit but their changes have to be reviewed before going live. We could combine this with (3); Nymble administrators or token-issuers could pledge to review edits coming from Tor. But that latter idea sounds like a lot of social infrastructure to set up and maintain. Thoughts? Are any of you interested in working on this problem? #tor on the OFTC IRC server is full of people who'd be interested in talking about this. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

16 25

Advance notice: I'm taking a sabbatical October-December
by Sumana Harihareswara 27 Sep '13

27 Sep '13

I've been accepted to Hacker School <https://www.hackerschool.com>, a writers' retreat for programmers in New York City. I will therefore be taking an unpaid personal leave of absence from the Wikimedia Foundation via our sabbatical program. My last workday before my leave will be Friday, September 27. I plan to be on leave all of October, November, and December, returning to WMF in January. During my absence, Quim Gil will be the temporary head of the Engineering Community Team. Thank you, Quim! I'll spend much of September turning over responsibilities to him. Over the next month I'll be saying no to a lot of requests so I can ensure I take care of all my commitments by September 27th, when I'll be turning off my wikimedia.org email. If there's anything else I can do to minimize inconvenience, please let me know. And -- I have to say this -- oh my gosh I'm so excited to be going to Hacker School in just a month! Going from "advanced beginner" to confident programmer! Learning face-to-face with other coders, 30-45% of them women, all teaching each other! Thank you, WMF, for the sabbatical program, and thanks to my team for supporting me on this. I couldn't do this without you. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

5 7

Deployment Highlights - week of September 30th, 2013
by Greg Grossmeier 27 Sep '13

27 Sep '13

Hello and here's your latest edition of the deployment highlights email! Full schedule here: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_September_30th == Monday == * VisualEditor will be enabled by default for Logged-in users on the following wikis: Bulgarian (bg), Catalan (ca), Cebuano (ceb), Czech (cs), Danish (da), Estonian (et), Basque (eu), Finnish (fi), Galician (gl), Croatian (hr), Hungarian (hu), Indonesian (id), Latvian (lv), Malay (ms), Norwegian - Nynorsk (nn), Norwegian - Bokmål (no), Simple English (simple), Slovak (sk), Slovenian (sl), Turkish (tr), Ukrainian (uk), Volapük (vo), Waray-Waray (war), Modern Greek (el), Neopolitan (nap), Venetian (vec), Sicilian (scn) See: https://www.mediawiki.org/wiki/VisualEditor#Timeline * MediaWiki 1.22wmf19 will deployed to all non-Wikipedia wikis (eg: Commons, Wikitionary, Wikisource, etc) == Wednesday == * MobileFrontEnd: Of note: the Mobile Team will be transitioning to simply 'riding the MW Core train' soon. This means there will not be a separate Mobile Team deploy window each week but instead all of their changes will ride along with the MediaWiki 1.22wmfXX version update. == Thursday == * MediaWiki 1.22wmf19 to group2 (all Wikipedias) * MediaWiki 1.22wmf20 to group0 (test/test2/testwikidata/loginwiki/mediawiki/) * Growth Team deploy window consisting of: https://etherpad.wikimedia.org/p/Growth_Deployment_2013-10-03 Let me know if you have any questions, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

GSoC2013 Summary: Right to Left Support in VisualEditor
by Moriel Schottlender 27 Sep '13

27 Sep '13

Hello everyone! Google Summer of Code 2013 came to an official end today with final reviews and code submissions. I wrote a blog post summarizing the summer internship, the deliverables, and the thank-yous: http://moriel.smarterthanthat.com/tips/google-summer-of-code-2013-summary/ I'd like to thank my great mentors, Amir Aharoni and Inez Korczyński and the whole of the VisualEditor team! Thank you all who were involved, and everyone who kept me company in late-late-late-night documentation-hunting. This summer has been a blast! Moriel (aka mooeypoo) -- No trees were harmed in the creation of this post. But billions of electrons, photons, and electromagnetic waves were terribly inconvenienced during its transmission!

1 0

Backport policy
by Mark A. Hershberger 27 Sep '13

27 Sep '13

We've come up with another document for interested people to review: the Backport policy[1]. Just as a process for reviewing RFPs was introduced this year, we've also set up a way to review requested backports. The first meeting to review these requests is in 2 weeks. In the meantime, have a look at the backport requests that we'll be reviewing[2]. [1] https://www.mediawiki.org/wiki/Project:Release_management/Backporting_policy [2] https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&name… -- Mark A. Hershberger NicheWork LLC 717-271-1084

1 0

[RFC]: Clean URLs- dropping /wiki/ and /w/index.php?title=..
by Gabriel Wicke 27 Sep '13

27 Sep '13

Hi, while tinkering with a RESTful content API I was reminded of an old pet peeve of mine: The URLs we use in Wikimedia projects are relatively long and ugly. I believe that we now have the ability to clean this up if we want to. It would be nice to * drop the /wiki/ prefix https://en.wikipedia.org/Foo instead of https://en.wikipedia.org/wiki/Foo * use simple action urls https://en.wikipedia.org/Foo?action=history instead of https://en.wikipedia.org/w/index.php?title=Foo&action=history The details of this proposal are discussed in the following RFC: https://www.mediawiki.org/wiki/Requests_for_comment/Clean_up_URLs I'm looking forward to your input! Gabriel

20 50

architectural granularity
by JFC Morfin 27 Sep '13

27 Sep '13

The granularity of my project is down to an open number (they will probably span on multiple servers) of small groups (mainly of one individual) of protected, *wiki pages* of which the presentation may be associated under various thematic gateways. I am interested in community advices concerning: - the existence of similar deployments I could study. - the most appropriate solution between MySQL, Postgres and SQLite. Also to know if NoSQL ports have been investigated? - the most appropriate extension for individual/small group page protection at author level (no fancy cross protection scheme). - the best way to associate the page skin, logo and footers link to the access gateway. Deep thanks jfc

1 0

A message for all everyone on the Wikitech mailing list
by Arcane 21 26 Sep '13

26 Sep '13

Sumana Harihareswara recently provided me assistance with some code I wanted to write and invited me to join the wikitech mailing list, and she also suggested I share my response to her with the rest of the list subscribers, which I have reproduced (with some mild alterations) below: Thanks for the mailing list link, Sumana, just submitted a subscription request. As for those links you provided, I have bookmarked them and will be studying them extensively, your assistance is greatly appreciated :) As for my wiki (https://mediawikitesters.orain.org/wiki/Main_Page), I like to test gadgets, user scripts, and extensions, and the wiki is basically for me and anyone else who is interested to display useful code, test it in a live environment, and hopefully swap notes with each other on how to improve it it. The wiki is still rather new, but anyone interested is welcome. As for the gadgets section of my wiki, I find gadgets to be incredibly useful and am trying to compile as many gadgets as I can that can be used by anyone with MediaWiki that I find universally useful and adaptable to any wiki, as I prefer code that works out of the box and is compatible as possible, especially with the more recent versions of MediaWiki, and my goal is to make it available to anyone for any wiki. Most are from WMF projects or have been adapted from them to be useful on any wiki.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l September 2013