https://blog.wikimedia.org/2012/09/25/page-curation-launch/
Please check this out -- there's a video tour, a tutorial, and more --
and ask your wiki communities for their thoughts.
"Every day, thousands of new pages are created on Wikipedia, requiring
hundreds of volunteer editors to check them for quality -- a process
called 'New Page Patrol.' To help these patrollers do their important
work, we are pleased to announce the launch of Page Curation, a new
suite of tools for reviewing articles on Wikipedia.
Current page patrol tools like Special:NewPages and Twinkle can be hard
to use quickly and accurately, and have led to frustration for some
users. Page Curation aims to improve that page patrol experience by
making it faster and easier to review new pages, using two integrated tools:
the New Pages Feed
the Curation Toolbar
...."
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
---------- Forwarded message ----------
From: Tim Starling <tstarling(a)wikimedia.org>
Date: Fri, Sep 21, 2012 at 4:07 AM
Subject: [Wikitech-l] #switch limits
To: wikitech-l(a)lists.wikimedia.org
Over the last week, we have noticed very heavy apache memory usage on
the main Wikimedia cluster. In some cases, high memory usage resulted
in heavy swapping and site-wide performance issues.
After some analysis, we've identified the main cause of this high
memory usage to be geographical data ("données") templates on the
French Wikipedia, and to a lesser extent, the same data templates
copied to other wikis for use on articles about places in Europe.
Here is an example of a problematic template:
<https://fr.wikipedia.org/w/index.php?title=Mod%C3%A8le:Donn%C3%A9es_PyrF1-2…>
That template alone uses 47MB for 37000 #switch cases, and one article
used about 15 similarly sized templates.
The simplest solution to this problem is for the few Wikipedians
involved to stop doing what they are doing, and to remove the template
invocations which have already been introduced. Antoine Musso has
raised the issue on the French Wikipedia's "Bistro" and some of the
worst cases have already been fixed.
To protect site stability, I've introduced a new preprocessor
complexity limit called the "preprocessor generated node count", which
is incremented by about 6 for each #switch case. When the limit is
exceeded, an exception is thrown, preventing the page from being saved
or viewed.
The limit is currently 4 million (~667,000 #switch cases), and it will
soon be reduced to 1.5 million (~250,000 #switch cases). That's a
compromise which allows most of the existing geographical pages to
keep working, but still allows a memory usage of about 230MB.
At some point, we would like to patch PHP upstream to cause memory for
DOM XML trees to be allocated from the PHP request pool, instead of
with malloc(). But to deploy that, we would need to reduce the limit
to the point where the template DOM cache can easily fit in the PHP
memory limit of 128MB.
In the short term, we will be working with the template editors to
ensure that all articles can be viewed with a limit of 1.5 million.
That's not a very viable solution in the long term, so I'd also like
to introduce save-time warnings and tracking categories for pages
which use more than, say, 50% of the limit, to encourage authors to
fix articles without being directly prompted by WMF staff members.
At some point in the future, you may be able to put this kind of
geographical data in Wikidata. Please, template authors, wait
patiently, don't implement your own version of Wikidata using wikitext
templates.
-- Tim Starling
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi everyone,
We've reverted MediaWiki from 1.20wmf11 to 1.20wmf10 in order to fix a
problem with watchlists failing:
https://bugzilla.wikimedia.org/show_bug.cgi?id=40103
The root cause of this problem is a compatibility issue with jQuery
1.7.2. We can't yet cleanly upgrade to jQuery 1.8. There are pending
changes that might make this possible.
We may also try reverting all wikis to 1.20wmf10, and then moving
forward with 1.20wmf12 on Monday. Still all TBD.
Rob