According to Deputy Director of the Wikimedia Foundation Erik Möller, the foundation's Engineering Department will be reorganised with immediate effect. The department, which handles the technical side of the WMF's operations, will now be split into four sub-departments (wikitech-l):

• Technical Operations, led by CT Woo, who will be responsible for "keeping Wikimedia Foundation sites and services running, increasing uptime and performance, supporting code deployments, and ensuring recoverability of data and services".
• Platform Engineering, headed by Robert Lanphier, whose area will be "maintaining and supporting the MediaWiki platform" and related operations.
• Features Engineering, led by acting head Alolita Sharma, who will be responsible for "specific feature projects"
• Mobile and Special Projects, headed by Tomasz Finc, who will manage the mobile platform and "projects with strong overlapping requirements (e.g. offline delivery of Wikimedia content)".

These four departments will be augmented by three special "architect" roles, representing "an additional career path for our distinguished engineers beyond 'become a manager'". Two new roles will therefore be created to accompany the existing position of Lead Software Architect held by newly returned ex-CTO Brion Vibber: Lead Operations Architect (Mark Bergsma) and Lead Platform Architect (Tim Starling). Möller also acknowledged the current positions of Senior Product Manager (held by Howie Fung) and Senior Research Analyst (Dario Taraborelli) to help the Engineering Department to integrate with other stakeholders in the wider movement.

Möller added that he will be taking on the role of overall head of the Engineering Department, at least on a temporary basis. As such, no new CTO will be recruited to replace Danese Cooper, who announced her resignation a fortnight ago (see previous Signpost coverage).

In theory, all changes to the MediaWiki software should be run against an automated test suite, incorporating parser tests, unit tests (tests of individual actions, such as page deletions); since May's Berlin Hackathon, this list has included JavaScript tests. However, in practice MediaWiki has not run as tight a ship as some of its larger counterparts such as Mozilla. For example, before October last year, the system for automating parser tests was considered broken. When that system was replaced in favour of an automated test system known as "CruiseControl" (implemented as part of the phpUnderControl suite), hopes were high that MediaWiki could move to a more rigorous system of speedily reverting any changes that broke the software. Nonetheless, the system immediately suffered from the fact that tests took so long to run that the results were out of date by the time of their publication. In May this year the decision was announced to exclude these long-running tests. Even so, though tests were now quicker, the consistent failure of a number of tests hurt the ideal of a fast revert for all bad code.

On 15 June, developer Chad Horohoe announced that work on reducing the number of permanently failing tests to zero had been successful (wikitech-l mailing list). This has delivered two benefits: firstly, it means that the current bleeding edge code (known as trunk) is free of the many bugs tested for by the suite (check its current status). Secondly, if a test fails in the future, it will be possible to pinpoint the revisions that broke the software, and revert them or otherwise fix the problem within minutes. "From here on out", wrote Horohoe, "I'm going to take the stance that if you break a test, it must be fixed or reverted on sight". Those who follow the MediaWiki development cycle will no doubt hope that this will significantly reduce the time needed to get code from trunk to production, and so help MediaWiki towards a faster release cycle. In a separate announcement, developer User:Krinkle noted that a parallel set of JavaScript-based tests are now also functioning (also wikitech-l).

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.

• Google's "Safe Browsing" security checks of the Wikipedia domain will now be automatically monitored (bug #28898).
• Editor and blogger Amir Aharoni posted about the need for translating the call for assistance that went out to the Right-to-Left developer community recently.
• WMF developers forewarned of a move that will see any HTTP-based URLs hardcoded into the interface change to pointers that are protocol-insensitive. This will allow users who prefer to use HTTPS (potentially all users in the future) to retrieve both text and images from the secure servers (wikitech-l mailing list).
• A developer for the Okawix project, a Wikipedia reader not currently supported by the Wikimedia Foundation, blogged about the inclusion of the reader in a Linux distribution specially aimed at school-age children. It will ship with a censored version of the French Wikipedia. Its main competitor, Kiwix, is currently preparing to integrate itself with the translatewiki.net localisation service.
• With the resolution of bug #29443, trying to invert the checkbox selection on Special:Undelete will no longer force a page refresh if the admin has JavaScript enabled.
• Developer Jeroen De Dauw noted his release of an updated version of the "Live Translate" extension, which helps multilingual authors quickly machine-translate articles from one language Wikipedia to another before manual polishing. The update allows for Microsoft rather than Google to be used as the translation provider, and comes after news that Google is controversially retiring the API version of its translate service.
• After an RfC (Signpost coverage) revealed consensus, the English Wikipedia's oversight and checkuser group permissions have been made more self-sufficient and less reliant upon the pre-supposition that all oversighters and checkusers are also administrators (bug #28440).