We need your help to test VisualEditor and uncover bugs before we enable it on more wikis.

One of the most important and challenging software development projects at the Wikimedia Foundation right now is VisualEditor: a rich-text editor for Wikipedia that does not require users to learn MediaWiki’s markup syntax. Today, we need your help to make it more robust and reliable.

The alpha version of VisualEditor enabled on the English Wikipedia in December was focused on basic functionality. We’re now moving toward supporting more complex editing operations, notably involving non-Latin characters and character sets.

In order for all language editions of Wikipedia and its sister projects to benefit from VisualEditor, we need to test it extensively, and we need your help to break it (and fix it) before we enable it everywhere.

Non-Latin characters (like math symbols: ⟂) and scripts (like Chinese: 嘗試, and Hebrew: סה) can be more difficult to support than the set of Latin characters we use for example in English.

Starting today (Monday, January 28th, 2013) and continuing all week long, we need your help to test how VisualEditor functions when working with non-Latin characters. We’re relatively confident that VisualEditor can reliably load a wiki page and save that page without losing any information. What is less clear is whether it behaves properly when manipulating non-Latin text, special characters, and other less common aspects of the greater set of Unicode characters.

If you care at all about VisualEditor, internationalization and localization, accessibility, or you simply enjoy hunting down bugs in software, join us this week to identify those issues! You’ll help to improve VisualEditor before it’s enabled more widely.

Our test plan should tell you everything you need to know to get started. We’re also available on IRC for real-time collaboration; all the details are in our coordination page.

The Wikimedia Foundation’s software development model is iterative: we release software early, get feedback, improve it, get more feedback, etc. We’ve set up a dedicated group for this kind of testing that you may want to join. At this time, thoughtful feedback about how VisualEditor manages non-Latin characters is crucial to the next steps of our new editor. We hope to take these steps with you.

Chris McMahon, QA Lead

To keep up with the growth of Wikipedia and its community, one goal of the engineering team at the Wikimedia Foundation for this year is to establish a Quality Assurance (QA) practice for software development, including MediaWiki itself, extensions, and also projects like Article Feedback and Editor Engagement. But how do you establish a QA & Testing practice for a development process that involves so many contributors, with code coming in from so many sources and projects?

In software development, QA is often conflated with software testing, but testing is only a small part of QA in general. The goal of modern software testing is not only to discover defects, but also to investigate software in order to provide valuable information about that software from every point of view, from the user experience to how the software is designed. On the other hand, Quality Assurance is process work, examining the process by which the software is created, from design to code to test to release and beyond.

Dozens of (volunteer and paid) developers contribute code to Mediawiki every month, in areas as varied as MediaWiki’s core, MediaWiki extensions, and localization. Thousands of power users on Wikimedia’s wikis can also contribute code directly on the sites, in the form of JavaScript “gadgets”. With so many entry points for fast-paced development, starting a QA/testing practice is challenging. Our strategy is to focus on two areas: test automation; and building a testing community. We’re hiring people to coordinate these two areas.

As QA Lead, I have created an example of what I believe to be the best available test automation “stack”, to pave the way and start the process of what I intend to be a reference implementation, an industry standard for high-quality browser test automation. We’re now hiring a QA Engineer whose primary responsibility will be to create and maintain browser-level test automation. In the course of creating those automated tests, we will be improving our use of the source code repository recently migrated from Subversion to git, we will be improving the beta labs test environment, and we will be expanding the use of our Continuous Integration in Jenkins.

But test automation isn’t everything, and we also have an opportunity to apply the Wikimedia community’s expertise in online volunteer collaboration to software quality. We’ve already started to explore this path with success: in May, we collaborated with Weekend Testing to validate the new frequent release schedule of MediaWiki to Wikimedia sites. Weekend Testing is an established global group of professional software testers who gather online every month for a different testing project, and testing Mediawiki versions on Wikipedia was a complex effort, executed well. In June, we collaborated with OpenHatch.org to test a near-final version of the new Article Feedback system that will be released to all of Wikipedia in the coming weeks. OpenHatch is an organization
dedicated to matching interested participants in open source software to projects that need participants. This was the first testing project for OpenHatch, and it went well; Article Feedback is much improved because of it.

We are now hiring a Volunteer QA Coordinator, who will be working to create a culture of quality testing and investigation of software related to Wikimedia, both within the Wikimedia community itself, and in collaboration with the greater software testing culture. And we are already planning future activities with both Weekend Testing and OpenHatch.

My first few months as QA Lead at the Wikimedia Foundation have been devoted to creating an environment where the QA Engineer and the Volunteer QA Coordinator will thrive. I am really looking forward to collaborating with the talented people we will hire for these roles. My own role will be shifting as these new practices start to take hold. I will be looking to the future, to bring in innovative and creative approaches to software QA and testing of the highest possible quality.

Chris McMahon
QA Lead Engineer

On May 5th, 2012, the Weekend Testing Americas group were invited to focus on testing Wikimedia sites during their monthly two-hour session.

The objective was to identify issues related to the new faster deployment schedule of MediaWiki to Wikimedia sites. The timing was excellent, as version 1.20wmf2 of MediaWiki had been deployed to all non-Wikipedia sites (like Wikisource and Wikimedia Commons), while all of the Wikipedias were still running 1.20wmf1.

Weekend Testing is “a platform for software testers to collaborate, test various kinds of software, foster hope, gain peer recognition, and be of value to the community”.

In less than two hours, the Weekend Testers reported fourteen issues in Bugzilla, based on a test plan I had prepared. In general, the quality of the reports was quite good. The WTA team posted an experience report of the session, as well as a full transcript (PDF, 142 KiB).

Building on the success of the Weekend Testing event, we will be collaborating with OpenHatch on another community testing event on June 9th, 2012, with the aim of discovering issues with the new Article Feedback Tool (AFT). As with MediaWiki 1.20, the timing for testing AFT is particularly opportune, as the software will be nearly in its final state, and the AFT team will be in a position to address issues found in the final stages of AFT development.

Collaborative software testing by the community is in an early, experimental stage at the Wikimedia Foundation, but based on the success so far, we expect to see more such events in the future. And you are welcome to join us and OpenHatch on 9 June to help test the Article Feedback Tool!

Chris McMahon
QA Lead

When you look at the “sprint backlog” in mingle (guest, guest), you may notice that even though we have been slowed down because of the slush, the feature freeze because of the imminent MediaWiki release, we are not sitting on our hands. Documentation, testing, code review and outreach is on our agenda.

Because of the way we are planning, it is apparent how much code review actually gets done. This sprint we added a review of the ArticleFeedback extension for its internationalization and localization aspects. This is a logical development considering that, with 280+ languages, we are not developing for one language. Our objective for this job is: “As a user I can use the functionality of the ArticleFeedbackv5 so that nothing looks odd in my language from an internationalization and localization perspective”. Reviews like this have been performed informally in the past by translatewiki.net staff. This review, however, will be done during Wikimedia hours and reported through Wikimedia channels.

One old open bug is about EasyTimeline.  It started its life in 2005 and it is finally getting the attention it deserves. The bug explains the lack of support for languages like Arabic, Hebrew and Farsi that are written from right to left. The software has Ploticus as a dependency and for a long time the waiting was for a version of this software that does support RtL languages. We are not waiting any longer and you can read in our story 230 about the complexities involved.

You could say that implementing a translation memory for page translation is a bit more adventurous; it is however debatable if that functionality is new; a translation memory has for a long time been functional at translatewiki.net. It is also very much a feature that makes people more productive. Our team has always had the goal of making life easy and productive for our editors and translators.

The “grammar” functionality for JavaScript is part and parcel of the i18n tooling for our developers. It was not ready before the “slush” and it does make our lives difficult not having it available in the code. When you are building tests for “gender” and “plural”, it is so obvious to create them for “grammar” as well. In this sprint, “grammar” will be included in the code for all these good reasons.

This is the first time that there is a story for outreach. We are reaching out to all the Wikipedia language communities to have their own language support team. It will make a difference when all our language communities have been asked to provide their expertise to us. We already have found that many people show an interest and issues do get raised as a result.

Thanks,
Gerard Meijssen
Internationalization / Localization outreach consultant

Every month, hundreds of thousands of people press the edit button on Wikipedia for the very first time. And for many of these new users, the first (and sometimes only) message that appears on their user talk page is a template rather than a human response. This is especially true on our larger, older projects.

User talk page templates were developed by the community because of the tremendous volume of contributions that began pouring in as Wikipedia grew more and more popular. Today, with the focus of our movement shifting to openness and attracting new editors, it’s time to rethink the message we’re sending via templates.

That’s why Steven Walling and I have started a project to A/B test many of the template messages received by new users, such as warnings and deletion notices. In collaboration with over 20 members of the Wikimedia community, including the English and Portuguese Wikipedias so far, we’ve designed a number of experiments that will give us tangible data to improve communication on the projects.

How it works

With the help of tools developed by our summer researchers, different messages we want to test are randomly delivered to different groups of users. Tracking the data from these two groups, we can assess the efficacy of different kinds of messages, based on whether users continue to edit constructively after receiving them.

Our working hypothesis, which we are continuing to test and refine, is that making templates more personal will help retain the good-faith editors who receive them, while continuing to detract vandals, spammers, and other bad-faith editors. For both groups, showing them that the encyclopedia is built through the hard work of other people like them is key.

What you can do

There are thousands of different user talk page templates on Wikimedia projects. We need your help to construct and carry out more tests, especially in non-English communities!

Please visit our task force page on English Wikipedia or our interlanguage hub on Meta and sign up. You can add your project to the list if you’re interested in starting new tests.

This is the first time that the Wikimedia Foundation has devoted resources to helping test and improve the template infrastructure the community uses every day to function. We hope that together, we can significantly improve the way Wikimedia projects communicate with editors.

Thank you,
Maryana Pinchuk and Steven Walling

Calling all mobile Wikipedia users! We’re happy to announce that the new Wikimedia Mobile prototype is ready for testing. Before enabling it, we need your help to test functionality and uncover bugs.

Please point your mobile browser over to our prototype sites, e.g. Wikipedia in English, in Japanese, or in Hebrew.

We have also imported a few stories from Wikinews for testing, in English ([1], [2], [3], [4]), Japanese ([1], [2], [3]) and Hebrew ([1], [2], [3], [4]).

When you’re done browsing, head over to our feedback page and let us know how it went.

Please keep in mind that our prototypes only contain a small subset of our content; you’re likely to see a lot of missing pages and templates (red links).

If you’re feeling especially brave and have found technical glitches, please file them directly in our bug tracker.

There are three possible experiences when loading the mobile gateway:

• We detect that you have a well-featured smart phone and show you the site exactly as m.wikipedia.org would;
• We detect that you have a WAP/WML-only phone and show you a paginated view;
• We don’t identify your phone as having a mobile browser and show you the PC version.

Our detection is based on the WURFL library; so if you find that your phone is not redirecting properly to the mobile version, please contribute your phone’s details to the WURFL project so that it is recognized in the future.

The new mobile prototype is a replacement for our current Ruby-based gateway; the prototype is implemented directly as a MediaWiki extension.

You can learn more about our mobile projects and future work by visiting our Mobile Projects page. If you are a developer and would like to get involved, check out the page detailing our work. And if you just want to say hello or give us some super quick feedback then join us on irc through freenode #wikimedia-mobile

Thank you for helping us test our mobile prototype!

Tomasz Finc
Engineering Program Manager — Mobile
Patrick Reilly
Senior Software Developer — Mobile

My time as a Fellow of the Wikimedia Foundation has been divided between the Bookshelf Project and the Account Creation Improvement Project. But now my Fellowship has taken a new and exciting turn.

Since I started, the Bookshelf Project has grown steadily. We have more and more people helping out, and the number of translations is increasing every week. The brochure “Welcome to Wikipedia,” for instance, has been translated into five languages, most recently French, and it has been a popular handout for the newcomers in the Public Policy Initiative.

The Bookshelf pages have also become more easy to navigate. I have filled the pages with many of the videos and books and handouts that have been created previously, beside the new materials. In total, around 100 different works have been collected and organized on those pages. Hopefully these pages will become the go-to library for anyone who wants to find out more about Wikipedia and its sister projects. The address is easy to remember: http://bookshelf.wikimedia.org. If you have more material that you think fits in the Bookshelves, feel free to add to them.

But most exciting is this third piece of news:

Starting today, we will help you spread the Bookshelf materials. Go to the Bookshelf pages, select any material that you want to give out at a conference or event – and apply for printing money from the Wikimedia Foundation! We have a simplified grants process. See more details here: http://meta.wikimedia.org/Bookshelf Grants. With this grant we hope to help you reach out to many new individuals and inspire them to edit.

Lastly, in the upcoming weeks, the new Wikipedia Cheat Sheet will be finished. It is right now being designed and printed. If you want to translate it, we will make it very easy for you. Then you can get a grant and have it printed in just a few weeks.

This marks the end of my full-time engagement in the Bookshelf project, but I will still check in on it now and then, and I love to see what happens with it in the future.

What happens next?

One of the proposed designs for the new account creation processes.

With all of these milestones reached, my Fellowship changes. I will concentrate fully on the Account Creation Improvement Project. After having performed surveys and tests of the account creation process, we have discovered that this project can have a real impact on the number of people with new accounts that actually start to edit. So with a few volunteers and support from the tech staff, I have started working on an approach to the next tests. First we have set up a new tracking system. Now we are working on creating two high-quality account creation processes that are significantly different from the existing process. We will start testing these very soon and see how many more new users we can get to the point of starting to edit.

After about a month of testing, this will lead to an increased understanding of what we can do to get the new users to stay. Of course, we would love to have your input and ideas.

Lennart Guldbrandsson
Community Fellow

Preview of the second set of usability features, Babaco, are available through user preferences. The first feature is the article outline in the right hand side of the editing area. The outline updates itself in real-time as you type the headers in the articles and provides links which when clicked will jump you to the start of each section in the article. The second feature is the assisted way to insert links and tables. Instead of inserting wiki syntax, a dialogue box pops up when you hit the link icon in the toolbar. For internal links, link suggest features offers auto-complete options and validate the existence of articles. A click of the table icon in the toolbar will also assist define the number of rows and columns without modifying table rows and columns in the wiki syntax. Thirdly, new search and replace dialogue is added to the advanced toolbar. These features are released in the stealth mode, which means users need to turn them on by going to user preferences. To enable these features, please go to “My Preferences”, select ‘Editing’ tab and enable the features listed under ‘Experimental features’. We, the usability team, is still refining look and feel, but we wanted to invite active users to start using these features and provide us feedback.
Known Issues: Accuracy of cursor positions using the article outline feature (aka Navigable Table of Contents) degrades in long articles and significant so if you use Firefox. We are also still working on the display issue of NTOC in Firefox2 on Vista. Bug 20669
The release details and discussion can be found in the Babaco discussion page of the usability project wiki. Looking forward to receiving your feedback.

Naoko Komura, Project Manager, Usability Initiative

Navigable Table of Contents

Inserting link using link dialogue

I’m very excited to announce that LiquidThreads, the next-generation discussion system that I’ve spent the last few months developing for the Wikimedia Foundation, is now in beta testing on liquidthreads.labs.wikimedia.org.

Sample of the LiquidThreads interface

(more…)