Bugs, Repairs, and Internal Operational News
Pending Changes development update
Rob Lanphier ( User:RobLa) this week posted an update on the development of pending changes to the foundation-l mailing list. He put out a request for specific feedback on the pending changes user interface. Developments that will be incorporated into the next release include a reject button, and the faster display of old revisions.
Pending changes is a new protection tool that allows administrators to apply "Pending changes" protection to a page. Under this setting, the page can be edited as normal, but only the most recent accepted version of the page will be visible to readers. This allows administrators to open up the editing of semi-protected pages to all editors, including those who edit anonymously. The technical work follows a request by Jimbo Wales that the Wikimedia Foundation developers keep Pending changes live (see earlier Signpost coverage), and the conclusion of an interim poll on the matter (see early Signpost coverage). Currently, the improved version of the Pending changes interface is in development at its own test wiki; developers are aiming to roll out an improved version of pending changes in November. Changes are based on feedback provided by users participating in the straw polls and discussions; for example, pending changes was the primary topic addressed by Sue Gardner's IRC meeting last week (see Signpost story).
In a separate development, Lanphier also called for collaboration on a list of "roadmap" bugs which the (paid) development team had been discussing. User:MZMcBride highlighted the post facto nature of the request, and asked that in the future the community be more involved in those discussions, rather than being invited to comment on conclusions alone. David Goodman ( User:DGG) added that it was "more consultation than was had for some previous changes", before touching on the key tensions in the community about to what extent Pending changes was being developed for the English-language Wikipedia only.
Code review version updated
The internal installation of the "CodeReview" MediaWiki extension has been upgraded. The extension, which aids in the review of proposed changes to the MediaWiki software itself, has had the following changes implemented ( wikitech-l mailing list):
- New statistics on code review have been added, specifically a "wall of shame" for fixmes (changes which have been sent back to the developer to fix as soon as possible)
- There is now a new 'old' status for revisions, designed for anything that is two or more years old and still unreviewed (for example, those from before CodeReview was implemented).
- The broken parser tests results system was removed, in favor of the phpUnderControl software.
Getting the code review software and process working efficiently again is one of the acknowledged priorities of the Wikimedia engineering department.
In brief
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.
- The official "October" WMF Engineering update was published, with the summary having few major changes from the draft published by The Signpost last week. In addition, it includes substantial in-depth detail on those activities.
- With the closing of bug # 23819, bureaucrats will be able to suppress the redirects created when a user is renamed.
- As part of a breaking change to the API, integer inputs will now be validated to make sure they are within a given range (bug # 25303, fix still in progress).
- Pywikipedia interwiki bots will now respect a greater range of possible indications that a page is a disambiguation page (revision # 8613).
- Developer Chad Horohoe reminded wikitech-l subscribers about the " Hack-a-Ton", to be held in Tyson's Corner, Virginia (in the Washington DC area) on October 22-24.
- The Wikimedia installation of the jQuery Javascript library was upgraded from version 1.3.2 to the newer 1.4.2 ( wikitech-l mailing list).
- On 10 October (UTC) all Wikimedia wikis experienced a brief outage due to an apparent bug in the software used for balancing the many millions of requests Wikimedia receives between its servers. It was fixed after around 90 minutes ( Wikimedia techblog).
Discuss this story