| “ | [The Wikimedia Foundation's] strategy is to focus on two areas: [testing] automation; and building a testing community. We’re hiring people to coordinate these two areas. | ” |
—WMF QA Lead Engineer Chris McMahon | ||
This week a blog post by WMF engineer Chris McMahon put the spotlight on an area that does not often reach the pages of the Signpost: quality assurance (QA), a diverse remit spanning interface testing, process improvement, and project monitoring.
McMahon is currently the only employee of the foundation with specific responsibility for quality assurance; the WMF is currently seeking a volunteer QA coordinator and a QA engineer to work alongside him. Their work will centre not only on discovering defects, McMahon writes, but investigating software to provide valuable information about that software from every point of view [and] examining the process by which the software is created, from design to code to test to release and beyond". If recent experience is anything to go by, McMahon and the two new hires will have their work cut out: many, if not all, Wikipedians can recite a list of bugs that have affected them in the recent past.
What makes QA across MediaWiki (the software that powers Wikimedia wikis) and the day-to-day running of those sites so difficult? "The development process involves so many contributors, with code coming in from so many sources and projects," writes McMahon, who also hints at the problems of being leader rather than follower in the world of rapid website testing. When finished, the processes currently being formulated are "intended to be a reference implementation, an industry standard for high-quality browser test automation".
According to the blog post, the foundation is also cultivating two relationships in the world of QA: the first with crowdsourcing website Weekend Testing; the second with technology non-profit OpenHatch.org, for whom MediaWiki testing constitutes their first foray into the world of software testing (the WMF is also employing OpenHatch in an area closer to its expertise – technology education (previous Signpost coverage). With the WMF QA department still in its infancy, the long-term utility of the measures they are now embarking on are not yet known.
Version 5 of the HTML standard may once again be enabled for use on Wikimedia wikis, well over a year after the first attempt to flick the switch was abandoned almost immediately (see previous Signpost coverage). WMF Director of Platform engineering Rob Lanphier this week expressed renewed interest in the switchover, suggesting a late July date for what would be the second attempt to implement the increasingly common standard (wikitech-l mailing list).
Fundamentally, the change is not a difficult one, requiring only the simple replacement of a single line of code. However, as the Signpost reported in February 2011, changing even that one line has the potential to break any tool reliant on so-called "screen-scraping" – reliant, in other words, on reading a page's HTML rather than a more machine-friendly version, such as that provided by the MediaWiki API. Then, even major tools like Twinkle were vulnerable to such problems; thankfully, all of the big-name tools are now far less reliant on the exact code used to generate the page, and as such will almost certainly survive the switchover. But other less well-maintained tools may not be so lucky, requiring the change to be well-trialed. The other bug raised at the time, relating to citation IDs, looks to have been resolved since, making a July switchover look all the more feasible.
Enabling HTML5 mode signals to browsers that they should display Wikimedia wikis in HTML5 mode, complete (once MediaWiki's own support is improved) with <video> tags, canvases and native support for form validation. Users should note that certain, long-deprecated markup will cease to function, most notably <font> and <center> tags, which are common in user signatures and on user pages, despite not being officially supported by MediaWiki itself.
.png)
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for several weeks.
{{PAGEID}} magic word and the recapitalisation of the language names used in the sidebar. A release to external sites including the same selection of bug fixes and new features is not expected for some time.
Discuss this story
The cite bug is one thing, but surely tools that screen-scrape get what they deserve. How many years have people been told to use the API? - David Gerard (talk) 11:27, 3 July 2012 (UTC)[reply]
<span style="font-family:'Old English Text MT',serif;">foo</span>thus: foo. The wordseriftells the browser what type of font to use if it does not have one matching the exact name of the other font(s) preceding it. Similarly,<div style="text-align:center;">bar</div>. Use<span>...</span>to affect only part of the text within a block (such as a signature), and<div>...</div>to affect the text or layout for an entire block (such as a paragraph or table cell). — Richardguk (talk) 13:42, 3 July 2012 (UTC)[reply]Citation?
What's the citation for this? Is there a reason HTMLTidy couldn't fix this (as it does all kinds of bad HTML from user input)? Has someone (a reliable source) said these tags are going to stop working somewhere? --MZMcBride (talk) 06:05, 11 July 2012 (UTC)[reply]
- Yeah, you got me, I was probably exaggerating slightly. Here's how it stands:
- Those tags are not just deprecated under HTML5 but literally don't exist in the doctype
- Thus, to my mind, there's a reasonable chance that browsers in strict mode won't render them.
- However, as you say, Tidy could probably resolve this by fudging them into spans (as The Anome suggests above). Or we could rely on browsers to continue supporting them even in strict mode. Or drop down to quirks mode. But none of them really look like nice options to me.
- Hope that helps explain, - Jarry1250 [Deliberation needed] 16:14, 11 July 2012 (UTC)[reply]
𝑓𝑓𝑣, 𝑥 114.122.164.239 (talk) 02:45, 31 May 2024 (UTC)[reply]