The Signpost

Technology report

Bugs, Repairs, and Internal Operational News

Contribute  —  
Share this
By Jarry1250

February Engineering Report published

(Due to a change in titling, this is in fact the second February update to be published. In future, all reports will cover the events in the month named in the title.) The Foundation's Engineering Report for February was published last week on the Wikimedia Techblog, giving a brief overview of all Foundation-sponsored technical operations in the last month. It summarised the developments:

The update also noted that a job opening had been posted for a contractor in the Netherlands to support the Operations team in designing and maintaining the Wikimedia network(s), and perform on-site work in the data centre facilities in Haarlem and Amsterdam. The Foundation also noted its intention to hire a "Rich Text Editor Engineer", an indication that the Foundation is serious about its desire to provide its own WYSIWYG in-place functionality, a project for which research has begun (for context, see previous Signpost coverage). This might entail a move away from Wikimedia's traditional revise-and-save model to a more Google Wave-like approach, added developer Trevor Parscal. (On a related note, the report also discussed a new JavaScript parser for wikitext using parsing expression grammar.) In other news, Sumana Harihareswara was hired as a contractor to help out with Google Summer of Code 2011 and the Berlin Developer meeting.

In reference to the new Virginia data centre, the Foundation noted that all that was left was "finishing touches" to the hardware arrangement, as well as the initial setup of the software, "configuration of the first clusters of servers and services" and "network transport and transit services to be installed". In addition, contractor Russell Nelson has installed and deployed Swift on a test cluster of three machines. This forms part of the WMF's intent to improve the media storage architecture; the next steps are "fixing some bugs and doing some preliminary testing". The area of backups and general data redundancy has also seen significant developments: the operations team "have purchased a dedicated storage solution which will arrive in March... Once servers in the new data centre are online, and our private connection between Tampa and Ashburn is up, we will be able to replicate all data between the two data centres as well." Discussing the LiquidThreads project, the report also explained that "documentation on upcoming back-end and architecture changes [and] design specifications have been published".

The Foundation also announced the start of work done on two projects that have traditionally generated a great deal of debate: a system to allow users to censor their own visits to Wikimedia sites, and a mechanism for allowing expert reviews of articles. For the former, the report noted that initial UI design recommendations had been drawn up; on the latter, the report noted that a set of "draft requirements" had been drawn up for an "open review system for Wikipedia, as well as an API and user interface for quality indicators". The report, the Foundation's Engineering update to date, also noted work in a number of other areas not covered in this summary.

Brion Vibber rehired

The WMF's current Chief Technical Officer (CTO), Danese Cooper, has announced the rehiring of former CTO Brion Vibber to the post of Lead Architect. The post will be in the second layer of the current employee hierarchy, and Brion will start on March 31, 2011, she reported (Wikimedia Techblog).

Brion's name will be familiar to many Wikipedia regulars; indeed, in acronym form he gives it to this very report. The author of much of the original code in MediaWiki, and, as Wikimedia's first paid employee, having been among its most involved programmers for a number of years, Brion left the Foundation in 2009. He joined StatusNet, an open source startup focused on microblogging, while remaining active as a Wikimedia volunteer (see previous Signpost coverage). Danese explained Brion's new role:


In a blog post, Vibber outlined this "next-generation parser work" briefly, saying that it will involve separating "weird template edge cases" from those that can be treated more easily.

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.

+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.

Dear Lord... Please tell me WYSIWYG will not be the default. If it is I it will basically turn us into WikiaPedia. 184.168.192.27 (talk) 03:29, 9 March 2011 (UTC)[reply]

My concern is that "rich text editor" (as in, avoiding wiki markup when bolding some text) has very little to do with the most serious editing problems for novices: templates, footnotes, and tables. For these three things (and to a much lesser extent the text for categories and images), what is shown in the editing window bears very little resemblance, in almost all cases, to what is visible to the reader. A really good editing interface would move the text for templates, tables, and footnotes out of the main editing window (regardless of how that text is physically stored in the database); for tables, there should be a separate WYSIWYG editor (as is the case in a number of wikis that don't use MediaWiki software). -- John Broughton (♫♫) 05:48, 9 March 2011 (UTC)[reply]
I don't know / can't remember if you've been party to the discussions on the various mailing lists, John, but I'm pretty sure tables, references, templates are what everyone's been thinking about here. Not just bold and italics, you'll be relieved to know. - Jarry1250 [Who? Discuss.] 21:08, 11 March 2011 (UTC)[reply]
Dear Lord... Please tell me that people complaining that "OMG! We shouldn't allow people not as L33T as me to edit Wikipedia" will not derail the process of making wikimarkup simpler. Witty Lama 02:27, 11 March 2011 (UTC)[reply]
I'm with Liam (Witty Lama) on this one: although I don't think that easier editing will boost the number of new editors a lot, I'm convinced it's worth a go. (I try not to let my own views creep into the articles, but it is hard: please call me up on any perceived biases.) - Jarry1250 [Who? Discuss.] 21:08, 11 March 2011 (UTC)[reply]
Witty, I don't think 27 is trying to derail it, but there are concerns that WYSIWYG would encourage edits not to improve the encyclopedia and other projects, but to increase unsourced non-encyclopedic edits from people who refuse to read other articles, instruction pages, policy pages, etc.. We just don't want wp to turn into post-September Usenet. Make it easier to edit sure (as an option?), especially if it's a barrier to good content being added, but also be prepared to undo do it if it causes an avalanche of crap which the bots and patrollers can't handle. -- Jeandré, 2011-03-13t22:32z



       

The Signpost · written by many · served by Sinepost V0.9 · 🄯 CC-BY-SA 4.0