Wikitech-l July 2013

wikitech-l@lists.wikimedia.org

158 participants
163 discussions

Global AbuseFilter testing!
by hoo 09 Jul '13

09 Jul '13

Here's a copy of a mail I just sent to stewards-l about the trial deployment of global AbuseFilters: Hello, after a long time we're finally confident that the AbuseFilter extension is in a state in which it can be used for global filters. Therefore I'm happy to announce that from now on global AbuseFilters can be used on (some) Wikimedia Wikis. The filters can be created and edited by Stewards using the normal AbuseFilter interface on meta ( https://meta.wikimedia.org/wiki/Special:AbuseFilter ) and basically work like local filters (you only have to set the "Global filter" flag). Although global AbuseFilters are already in use on Wikimedia Labs for quite some time we would like you to start using them slowly, preferable with logging-only filters to prevent unforeseeable damage. Global filters are yet enabled on: metawiki, testwiki, test2wiki, mediawikiwiki (They will only filter changes on these wikis... Of course this trial will later be extended to further Wikis and it's planned to cover all Wikis at some point) Please notice that it's not yet possible to create custom warning message for global filters ( https://bugzilla.wikimedia.org/show_bug.cgi?id=45164 ) and that global filters can't yet be enabled/ disabled for certain wikis only ( https://bugzilla.wikimedia.org/show_bug.cgi?id=41172 ). Cheers, Marius Hoch (Hoo man)

3 3

Possibly malicious script inside "United_Kingdom" article
by Sergey Grass 08 Jul '13

08 Jul '13

Dear ladies and gentlemen! Every time when I go to this page: http://en.wikipedia.org/wiki/United_Kingdom, the following script causes my browser (Firefox) to freeze. Script, which causes harm: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&mod… This occured only on aforementioned web page. All other pages work normally. Sort this thing out, please! Sincerely yours, Sergey G

4 3

IRC office hour on Tue July 16th, 1600 UTC, about Bug management
by Andre Klapper 08 Jul '13

08 Jul '13

Hi everybody, on Tuesday 16th 16:00 UTC[1], you are invited to an IRC Office Hour in #wikimedia-office about Wikimedia's issue tracker[2] and Bug management[3] in general. Add it to your calendar and come to ask how to better find information in Bugzilla that interests you, and to share ideas and criticism how to make Bugzilla better! I'm going to answer your questions and discuss ideas about bug management and Bugzilla, plus explain what's on the to-do list[4]. Looking forward to talking to you! andre [1] https://meta.wikimedia.org/wiki/IRC_office_hours [2] https://bugzilla.wikimedia.org [3] https://www.mediawiki.org/wiki/Bug_management [4] https://www.mediawiki.org/wiki/Bug_management/Task_list -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 0

Re: [Wikitech-l] [Xmldatadumps-l] Suggested file format of new incremental dumps
by Ariel T. Glenn 08 Jul '13

08 Jul '13

Στις 07-07-2013, ημέρα Κυρ, και ώρα 21:09 -0700, ο/η Randall Farmer έγραψε: > Sorry, reading back over this thread late. > > > > What I hope for is a format that allows dumps to be produced much > more > > rapidly, where the time to produce the incrementals grows only as > the > > number of edits per time frame grows > > > Curious: what's happening currently that makes the time to produce > incrementals grow more quickly than that? > We don't produce true incrementals now; we produce 'adds/changes' dumps which don't acocunt for deletions, oversights, page moves, etc. And you can't add them onto a full to get a new full. When they are produced, I want them to behave as described above. Ariel

1 0

Bugzilla Weekly Report
by reporter 08 Jul '13

08 Jul '13

1 0

Moving on from Doxygen?
by Yuvi Panda 08 Jul '13

08 Jul '13

Hello! Our current generated documentation[1] uses doxygen, and leaves... a number of things to be desired - such as: 1. Not be tortoise slow 2. Have usable search 3. Prettier interface I was looking around for alternatives, and ran into phpdocumentor2[2]. The project still seems active (latest commit was 3 days ago, and for vagrant support!), and the demo was quite pretty: http://demo.phpdoc.org/Responsive/namespaces/phpDocumentor.html Is there any particular reason we are still sticking with doxygen? Or is it just 'someone needs to find the time to move things over to the new system'? [1]: https://doc.wikimedia.org/mediawiki-core/master/php/html/ [2]: http://www.phpdoc.org/ -- Yuvi Panda T http://yuvi.in/blog

8 10

Proposed RFC process
by Tim Starling 06 Jul '13

06 Jul '13

Rob Lanphier has asked that the WMF architects -- namely Brion Vibber, Mark Bergsma, Asher Feldman and myself -- take a leading role in accepting or rejecting RFCs, or delegating that decision as appropriate. Along these lines, I'd like to add an header template to every RFC indicating its status as determined by one of these architects or the people to whom they delegate authority. The header would indicate not only status (mirroring the index page) but also the name of the person who chose that status. Seeking consensus has always been a key part of my work on MediaWiki. I expect that a large part of assigning a status to an RFC will simply be to evaluate the comments of the participants, or to seek comments from specific domain experts where none have been given. Many RFCs are just "good ideas", often attracting no comment because there is no obvious criticism of the feature at the level of detail given by the proposer. This raises the question of whether an RFC is a feature request (like a Bugzilla enhancement) or a design document. If an RFC is a design document, then we might ask for more detail about feature implementation, and close the RFC if none is given. This may lead to the closure of RFCs which have no interest or support from developers. I'm inclined to think that this is an appropriate path to take, i.e. that RFCs should be design documents, but I am interested to hear comments on the subject. Please comment here or on <https://www.mediawiki.org/wiki/Talk:Requests_for_comment> -- Tim Starling

6 6

Recommending some minimum documentation practices
by Ryan Kaldari 06 Jul '13

06 Jul '13

Please see the proposal at: http://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/PHP#Recommendi… Ryan Kaldari

1 0

Re: [Wikitech-l] [Xmldatadumps-l] Suggested file format of new incremental dumps
by Petr Onderka 04 Jul '13

04 Jul '13

I'm writing it in C++. If you want, you can follow my progress in the operations/dumps/incremental repo, branch gsoc [1] (but there isn't almost anything there yet). And I don't have any computers with non-x86 architecture, so I won't be able to test that. [1]: https://git.wikimedia.org/log/operations%2Fdumps%2Fincremental/refs%2Fheads… On Wed, Jul 3, 2013 at 10:13 PM, Byrial Jensen <byrial(a)vip.cybercity.dk>wrote: > At 03-07-2013 18:29, Petr Onderka wrote: > >> I'm primarily a Windows guy, so I'm trying to write the code in a >> portable way and I will make sure the application works on both Linux >> and Windows. >> > > That sounds good. Just remember that portable not only means that it works > on different operating systems on the same computer architecture, but also > on different architectures. What programming language do you intend to use? > > > > ______________________________**_________________ > Xmldatadumps-l mailing list > Xmldatadumps-l(a)lists.**wikimedia.org <Xmldatadumps-l(a)lists.wikimedia.org> > https://lists.wikimedia.org/**mailman/listinfo/xmldatadumps-**l<https://lists.wikimedia.org/mailman/listinfo/xmldatadumps-l> >

2 2

Proposal regarding a distinct Extension infobox status color for status "unmaintained"
by Thomas Gries 04 Jul '13

04 Jul '13

Someone proposed to have a _distinct color for status "unmaintained"._ Status "unmaintained" is currently signalled with gray color, the same as for status "unknown" The current color scheme can be found at the lower part of page: https://www.mediawiki.org/wiki/Extension_status The proposal was added here: http://www.mediawiki.org/w/index.php?title=Template_talk:Extension&offset=2… and somehow related is https://www.mediawiki.org/w/index.php?title=Template_talk:Extension&offset=… Because such a color scheme change can have a wide impact and unwanted side-effects, I cross-post the proposal here.

3 3

Jump to page:

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 July 2013