Wikimedia blog

MediaWiki’s Google Summer of Code students have been busy! We’re more than halfway through the summer, so here’s what they’re up to:

MediaWiki is participating in Google Summer of Code 2011.

• Akshay Agarwal’s “Account Creation, Login Screens and AJAX-ification of everything” (mentor: Brandon Harris). Code, project status.
  The last task I accomplished: “Added source tracking functionality in the account creation API that I am building.”
  Something I’ve learned: “True learning can happen only in an open environment & with a highly supportive community.”
• Kevin Brown’s “Working Archival for Web References/Citations,” “to facilitate the archival of external links used as references in the English Wikipedia” (mentor: Neil Kandalgaonkar). Code, project notes.
  The last task I accomplished: “Adding support for wget local archival, currently working on feed for external archival services.”
  Something I’ve learned: “Where do I start? A lot. I think the biggest thing is probably managing a large project and time management, which I still have a lot to learn on.”
• Devayon Das’s “Improving Semantic Search/Semantic Query usability issues in SMW” (mentor: Markus Krötzsch). Code, project notes.
  The last task I accomplished: “Added RSS links to the results generated by the Query Creator interface I’m building.”
  Something I’ve learned: “A 30 second chat with a community member can save you 30 minutes of scratching your head in frustration.”
• Ankit Garg’s “Semantic Schemas extension” (mentor: Yaron Koren). Code.
  The last task I accomplished: “I finished adding the inheritance support to the PageSchema XML structure.”
  Something I’ve learned: “I have a learned a great deal of PHP; also how to manage a huge project.”
• 

  "A 30 second chat with a community member can save you 30 minutes of scratching your head in frustration."

  
  Salvatore Ingala’s “AMICUS: Awesome Monolithic Infrastructure for Customization of User Scripts” (mentors: Max Semenik and Brion Vibber). Code, project notes.
  The last task I accomplished: “I made a prototypal user interface for editing preferences of an existing gadget, HotCat.”
  Something I’ve learned: “Unit testing is boooooring, but ends up saving you a lot of time!”
• Yuvi Panda’s “Making Offline Wikipedia Article Selection Easier with Mediawiki Extensions” (mentor: Arthur Richards). Code, project.
  The last task I accomplished: “Filter articles based on name, quality and importance.”
  Something I’ve learned: “That spending time talking to everyone involved in the process from start to finish (devs, community maintainers, etc.) saves a truckload of time later on.”
• Zhenya Vlasyenko’s “MediaWiki Extension: SocialProfile – UserStatus feature” (mentor: Jack Phoenix). Code.
  The last task I accomplished: “Internalization of the UserStatus feature with the help of the MakeGlobalVariablesScript hook.”
  Something I’ve learned: “I’ve found out for myself a new ways of data interaction between PHP and Javascript… Convinced that knowing some tricks and hooks can greatly save time.”

Aigerim Karabekova, who was working on extension release management, ran into several delays (including medical issues) and the project has been dropped. We’re glad she made the attempt and wish her the best.

Continued best wishes to Zhenya, Yuvi, Salvatore, Ankit, Devayon, Kevin, and Akshay as they work to make MediaWiki, and the Wikimedia experience, better.  We’re glad to be helping young developers learn how to contribute to our community.

Sumana Harihareswara
Wikimedia Foundation, Volunteer Development Coordinator

In preparation for enabling HTTPS on Wikimedia Foundation sites, we’ve recently enabled protocol relative URLs on test.wikipedia.org. Protocol relative URLs are needed to make the site work properly in both HTTP and HTTPS modes.

What are protocol relative URLs?

Normal URLs look like: http://test.wikipedia.org/wiki/Main_Page or https://test.wikipedia.org/wiki/Main_Page. Both of these URLs define the protocol that will be used. Protocol relative URLs look like this: //test.wikipedia.org/wiki/Main_Page. Dropping the protocol from the URL allows the browser to assign the current protocol to the URL. So, if you are visiting the site in HTTPS mode, links will point to HTTPS, and if you are visiting the site in HTTP mode, links will point to HTTP.

Why are protocol relative URLs needed?

We need to use protocol relative URLs for a couple reasons:

1. All requests are served by our caching layer (squid or varnish). If you are browsing the site in HTTPS mode, and another user is browsing the same pages in HTTP mode, two versions of those pages will be stored in our cache, as the links are different between the two modes. This splits our cache, which makes it less efficient and more expensive to operate.
2. When browsing in HTTPS mode, we want to ensure links point to the correct protocol. When pages are parsed, things like interwiki links are created by the parser. If we do not use protocol relative URLs, then links will point to either HTTPS or HTTP, which will cause users to switch modes randomly.

How does this affect me?

It shouldn’t. Things should continue to work as before. We are currently testing this out on some internal wikis, and have enabled it on test.wikipedia.org so that the entire community will have a couple weeks to test it out before we enable it on all projects.

API users, especially, should test thoroughly. The API, in most cases, will not output protocol-relative URLs, but will continue to output http:// URLs no matter whether you call it over HTTP or HTTPS. This is because we don’t expect API clients to be able to resolve protocol relative URLs correctly, and that the context of these URLs (which is needed to resolve them) will frequently get lost along the way.

The exceptions to this are:

• HTML produced by the parser will have protocol-relative URLs in <a href=”…”> tags etc.
• prop=extlinks and list=exturlusage will output URLs verbatim as they appear in the article, which means they may output protocol-relative URLs

If you are getting protocol-relative URLs in some other place in the API, that’s likely a bug.

If you notice any issues related to protocol relative URLs, in the API or not, please let us know.

Note: we’ve also enabled HTTPS on test.wikipedia.org; so, please do test protocol relative URLs in HTTP and HTTPS modes. There is at least one known bug with regards to HTTPS mode and redirects, which will be fixed soon. More to come on this in a later post.

At the end of June 2011, we had the opportunity to visit Brazil as part of the Wikimedia Foundation’s Brazil Catalyst Project – a project designed to develop open and collaborative approaches by which the Wikimedia Foundation can support the growth of the Wikimedia community in Brazil. Brazil is a priority country for the Wikimedia movement, both for contributions to Portuguese and other Wikimedia projects and for the opportunity to connect with millions of potential readers who are coming online.

Our visit involved a variety of meetings ranging from community gatherings to exploration of business partnerships to presentations at one of the biggest international conferences focused on free software (FISL); the whole agenda and supporting information can be seen on the Brazil Catalyst Project metawiki page. We spent most of the time listening and learning about Brazil and the Brazilian Wikimedia community. It was incredibly valuable to hear from a variety of people and we hope to continue the dialogue.

Sao Paulo: WikiSampa 8
Paulistas have been gathering periodically under the banner of WikiSampa for years, and we were fortunate to get a nice group together on a bank holiday. The group ran the gamut in depth of wiki experience: wiki newcomers sat alongside long time editors,  admins, and community members to share their experiences with Wikipedia and discuss the health and future of Wikipedia in Brazil. We spent about six hours together including a relaxed dinner at a local pizzeria.

As with every community gathering around the world, we were in awe of the positive spirit, dedication and friendliness. We were reminded again that, as Jimmy likes to say, Wikipedians are just “nice people.” We also heard about the struggles in the community. We heard the word “conflito” a lot as the more experienced editors all shared a concern that the Portuguese Wikipedia community has an over-abundance of conflict between editors and that the community needs to find ways to refocus away from fighting. We are not yet clear on the causes of the conflict or if PT:WP is worse that others, but there was a clear sense from those in attendance that they need to find new ways of working together so that new contributors will feel welcome and experienced contributors stay active and energized to continue building a great Wikipedia.

For more pictures see: Category:8_WikiSampa_June_2011, and for the official community page (in Portuguese) see: WikiSampa8.

Rio de Janeiro: first broad community meet-up!

Rio meet-up

Seven Cariocas began what we hope is a regular community gathering in Rio de Janeiro. This group brought fresh faces and minds eager to contribute to the sum of all knowledge. The excitement of the possible future of the RJ community specifically and Brazil at large was palpable: one professor in attendance is now planning to incorporate Wikipedia-editing into a university seminar course! She already has a blog just focused on this experience. A long time Wikipedian and self-proclaimed Wiki-addict met other Wikipedians for the first time and shared his experiences as an editor primarily on English Wikipedia.

Our conversation in RJ focused on the potential of Wikipedia as we had a number of newer community members. They were interested in exploring new ways to bring people into the community. One interesting theme was the prevalence of English. Unlike Sao Paulo, the conversation was in English.  We discussed the fact that a significant number of Brazilians apparently prefer to contribute to English Wikipedia to reach a global audience, even though there is plenty of room for growth of the Portuguese Wikipedia. Some also expressed that Portuguese Wikipedia is considered second class vs. English. We all agreed that having a first class Portuguese Wikipedia is vital to meeting our vision and we took away the question of how to encourage bilingual Brazilians to contribute in Portuguese.

Creating an offline Wikipedia
We had some promising conversations about the potential to distribute offline versions of Wikipedia to people who have computers, but do not have regular access to the Internet. This is a large proportion of Brazilians. We are committed to supporting partnerships to do this, but we need to create a selection of the Portuguese Wikipedia to make available offline. We would love it if community members who were interested in contributing to this initiative would connect with Jessie.

General remarks
These specific meet-ups in addition to other interactions with community in Brazil (in Recife, Campinas, and Porto Alegre) on this trip collectively communicated the great need and potential for mobilization behind the Portuguese Wikipedia within Brazil. While there are great obstacles – negative quality perceptions, low numbers of editors, limited admin support in addition to the fact that some editors prefer to edit the English Wikipedia – opportunities to mobilize existing community and engage a broader Brazilian population seem abundant, and there is no better time than now. We’re excited to continue supporting such a dynamic movement within Brazil and will continue to support and encourage outreach activities designed to further catalyze the collection and dissemination of knowledge within Brazil. We continue to seek more opportunities to hear from Brazilian community members and to learn more about opportunities. We’d also like to thank everyone who helped with the visit and who met with us. Muito Obrigado!

- Barry Newstead, Carolina Rossini, Jessie Wild

Since May, the Article Feedback Tool has been available on 100,000 English Wikipedia articles (see blog post). We have now kicked off full deployment to the English Wikipedia at a rate of about 370,000 articles per day and will continue at this rate until deployment is complete.

Ratings interface for the Article Feedback Tool

We wanted to take a moment to briefly recap what we’ve learned so far, what lies ahead, and how we can work with the community improve this feature.   Features like Article Feedback can always be improved, so we will continue to experiment, measure, and iterate based on user and community feedback, testing, and analysis of how the feature is being used.

Rating data from the tool is available for your analysis — please dig in and let us know what you find. Toolserver developers can also access the rating data (minus personal information) in real-time to develop new dashboards and views of the data.

What We’ve Learned So Far

Readers like to provide feedback. The survey we’re currently running shows that over 90% of users find the ratings useful.  Many of these raters see the tool as a way to participate in article development — when asked why they rated and article, over half reported wanting to “positively affect the development of the page.”

Users of the feedback tool also left some enthusiastic comments (as well as some critical ones) about the tool. For example:

The option to rate a page should be available on every page, all the time, once per page per user per day.

As a high school librarian, I want my students to assess the sources of information they use.  This feature forces them to consider the reliability of Wiki articles.  Glad you have it.

Ratings seem like an interesting idea, I feel like the metrics used to determine the overall value of the page are viable, and I’ll be interested to see how the feature fares when it’s rolled out and has some miles under its belt.

The vast majority of raters were previously only readers of Wikipedia.  Of the registered users that rated an article, 66% had no prior editing activity.  For these registered users, rating an article represents their first participatory activity on Wikipedia.  These initial results show that we are starting to engage these users beyond just passive reading, and they seem to like it.

The feature brings in editors. One of the main Strategic Goals for the upcoming year is to increase the number of active editors contributing to WMF projects.  The initial data from the Article Feedback tool suggests that reader feedback could become a meaningful point of entry for future editors.

Once users have successfully submitted a rating, a randomly selected subset of them are shown an invitation to edit the page. Of the users that were invited to edit, 17% attempted to edit the page.  15% of those ended up successfully completing an edit.  These results strongly suggest that a feedback tool could successfully convert passive readers into active contributors of Wikipedia.  A rich text editor could make this path to editing even more promising.

While these initial results are certainly encouraging, we need to assess whether these editors are, in fact, improving Wikipedia.  We need to measure their level of activity, the quality of their contributions, their longevity, and other characteristics.

Ratings are a useful measure of some dimensions of quality.  In its current form, the Article Feedback Tool appears to provide useful feedback on some dimensions of quality, while the usefulness of the feedback on other dimensions of quality is still an open research question. Completeness and Trustworthy (formerly “Well-Sourced”) appear to be dimensions where readers can provide a reasonable level of assessment.  Research shows that ratings along these dimensions are correlated with the length and amount of citations, respectively.  We need to determine whether the ratings in “Objective” and “Well-Written” meaningfully predict quality in those categories. We released public dumps of AFT data and would love to hear about new approaches of measuring how well ratings reflect article quality.

We received feedback from community members on how to improve the feature. We’ve received a fair amount of feedback from the community on the usefulness of AFT, mainly through IRC Office Hours and on the AFT discussion page.  There have been many suggestions on how to make the feedback tool more valuable for the community.  For example, the idea of having a “Suggestions for Improvement”-type comment box has been raised several times.  Such a box would enable readers to provide concrete feedback directly to the editing community on how to improve an article.  We plan to develop some kind of commenting system in the near future.

Illustration of a potential "Suggest Improvements" feature

AFT could help surface problematic articles in real time, as well as articles that may qualify for increased visibility. We’ve started experimenting with a dashboard for surfacing both highly rated and lowly rated articles.   Ultimately, the dashboard could help identify articles that need attention (e.g., articles that have been recently vandalized) as well as articles that might be considered for increased visibility (e.g., candidates for Featured Articles).  We will continue to experiment with algorithms that help surface trends in articles that may be useful for the editing community.

Next Steps

Over the coming weeks, we will continue to roll out the Article Feedback Tool on the English Wikipedia.  Once this rollout is complete, we will start planning the next version of the tool.  For those interested in following the discussion, we will be documenting progress on the Article Feedback Project Page.  We would love to get your feedback (pun intended!) on how the feature is being used, what’s working, and what might be changed.  We also encourage folks to dig into the data.  Once the feature is fully deployed, there will be mountains of data to sift through and analyze, which will be a boon to researchers and developers alike.

We’d especially like to encourage members of the community to get involved in the further development of the feature.  If you’re interested in getting involved (e.g., design input, data analysis/interpretation, bug-squashing, etc.), please drop a note on the project talk page.

Howie Fung, Senior Product Manager

Dario Taraborelli, Senior Research Analyst

Erik Moeller, VP Engineering and Product Development

Major news this month include:

• the network setup in our new datacenter, that opened the way to new server setup and backups;
• progress on features to encourage and facilitate participation, like the Visual editor groundwork, and the WikiLove button;
• productive community testing on our now mobile front-end and the Kiwix download manager;
• the release of MediaWiki 1.17.0;
• the first commits by our Summer of Code students;
• major progress on our code review backlog.

Note: This month, we’re trying out a slightly modified format for the report. Hover your mouse over the green question marks ([?]) to see a description of a particular project.
(more…)

We are pleased to announce the launch of the Wikipedia Participation Challenge, a data modeling competition to develop an algorithm that predicts future editing activity on Wikipedia. The competition is hosted by Kaggle, a platform for data modeling and prediction competitions.  The Participation Challenge is open to community members and anyone else who is interested in analyzing Wikipedia data.  This is the first of two data competitions the Wikimedia Foundation will sponsor this year.

The goal of this competition is to gain a better understanding of the factors that encourage or discourage people from editing Wikipedia. Increasing the number of active editors is one of our strategic priorities. Both the Wikipedia communities and the Wikimedia Foundation stand to benefit from models that quantify the factors that determine whether a Wikipedia editor is likely to continue contributing. The competition asks contestants to develop a model to predict the number of edits a given editor will make in six month’s time.

The data used in this competition comes from the publicly available English Wikipedia XML data dump.  An anonymous donor has generously contributed $10,000 as prize money. There will be a Grand Prize for the best prediction, as well as special prizes awarded for the use of open source software. The Grand Prize winner will also be given the opportunity to present their prediction model at the 2011 IEEE International Conference on Data Mining.  The competition starts today and will continue until September 20, 2011.

Head over to our competition portal, download the data, and start crunching the data! And don’t forget to follow us on Twitter: #wikichallenge and @dvanliere.

Howie Fung
Senior Product Manager, Wikimedia Foundation

Diederik van Liere
Research Consultant, Wikimedia Foundation

We all like to feel valued. According to the 2011 survey of Wikipedia editors (see top-line data), among 17 variables, “being looked down on by more experienced editors” is the most likely to cause people to say they will edit less frequently (69% agreement), while “having others compliment you on your edits/articles” is the most likely to cause people to say they will edit more frequently (78% agreement).

On the other hand, editing Wikipedia has tended to become harder over time, and the likelihood that new users will receive correction/criticism has increased. This is reflected by various efforts to code and analyze the experience of new users, such as the recent Newbie teaching strategy research sprint undertaken within the scope of our Summer of Research.

Warnings, teaching and criticism tend to dominate the experience of new users

This chart shows the relative increase and decrease in warning messages, praise/thank you messages, criticism and teaching messages over time.

The drive for quality and reliability has led to the development of sophisticated automation mechanisms that aid in socializing new users to Wikipedia’s norms, policies and conventions. The act of expressing appreciation for other users, by contrast, is a largely manual effort. Whether it’s welcoming new users, inviting users to participate in specific topics or discussions, recognizing effort using barnstars and trophies, or just sending a whimsical note, expressing appreciation is not an activity that is facilitated by the software — in spite of its known importance for people’s likelihood to want to edit.

WikiLove is a simple experiment in appreciation. It makes it easy and fun to send barnstars or whimsical messages of appreciation to other users. The tool was first built by Wikimedia Foundation developer and Wikimedian Ryan Kaldari as a small gadget, and the new editor engagement team at the Wikimedia Foundation has developed it into a full feature over the last few weeks.

WikiLove is invoked from a user page by clicking the "Heart" icon.

How you can help

Currently, the Wikilove extension is only deployed on our prototype site.  While it’s a simple feature, we would still appreciate your help in testing and evaluating it.  To do so, create a test account on prototype (please remember to check the “remember me for 30-days” box — sorry, there is a known bug on prototype that requires the box to be checked).  Once your test account created and you are logged in, visit any userpage or user talk page.  You will notice a red heart icon to the left of the search box.  Click on the icon, send WikiLove, and let us know what you think by providing feedback on the WikiLove talk page.

WikiLove comes with different forms of appreciation, and can be customized further by every wiki community

What’s next

Our plan is to enable WikiLove on the English Wikipedia on June 29 (we may push the date depending on any issues surfaced). Users will be able to disable the WikiLove feature by going to My Preferences → Editing → Labs Features and unchecking the box that is labeled “Enable showing appreciation for other users with the WikiLove tab (experimental)”.

The tool has built-in tables that will help us measure how frequently WikiLove is used, and allow us to understand whether its usage actually affects (new) editor activity. Irrespective of that, we’re also interested in exploring tools specifically built for welcoming new users and inviting them to edit articles related to their expressed interests.

We’re not presupposing that we know how appreciation can best be expressed in the many different languages and cultures that make up the Wikimedia community. The selection of barnstars and other forms of appreciation that we’re starting with is just that — a selection. Wiki administrators will be able to modify the user interface by following the instructions for customization — so that whether you want to award gifts of chocolate or stroopwafels or baklava, you can do so!

Howie Fung
Senior Product Manager, Wikimedia Foundation

Erik Moeller
Deputy Director, Wikimedia Foundation

We are proud to announce the first stable release of the 1.17 series.

• Download MediaWiki 1.17.0

MediaWiki 1.17 is a very large release that contains many new features and bug fixes. This is a summary of the major changes of interest to users. You can consult the release notes for the full list of changes in this version.

What’s new?

PHP 5.2.3

We now require PHP version 5.2.3 or later. Why? Well, it brings with it some tools for your beloved developers. It was released on June 1, 2007, so we believe this requirement will not be a hassle for administrators. Be sure to check your PHP installation and contact your host if it runs an outdated PHP version.

New installer

The installer now supports many languages!

MediaWiki 1.17 is shipping with a completely redesigned installer to fix a lot of outstanding bugs, clean up the code quality, and make it easier to use. Notably, you can now run upgrades from the web without having to move LocalSettings.php. A couple of other notable changes:

• The installer can now be fully localized like the rest of the software and contains numerous help dialogs.
• The installer script directory has been renamed from config/ to mw-config/.
• You now download your generated LocalSettings.php at install completion, rather than writing it straight to the configuration directory. The previous behavior was a security risk.
• IBM DB2 and MSSQL support were dropped from the installer.

ResourceLoader

As web browsers have become more capable, the software that MediaWiki runs on them has become more complex. This trend has resulted in developers needing an efficient way to package and deliver code to web browsers.  To address this, MediaWiki 1.17 ships with ResourceLoader: a framework which combines and minifies CSS and JavaScript before delivering them to the web browser.  ResourceLoader improves performance, while also making it easier to write client-side features.  ResourceLoader allows developers to organize scripts, styles, and messages into named modules. Any number of modules can be loaded through a single request, improving page load times. Code is minified automatically and loaded when needed, reducing unnecessary downloads. Other advanced features include the ability embed images in style sheets using data URIs, or automatically flipping horizontal information in style sheets for right-to-left user interfaces.

Category sorting

Category sorting has been drastically improved.

• Sorting is now case insensitive.
• Sub-categories, pages and files can now be paged separately.
• When several pages are given the same sort key, they sort by their names instead of randomly.

Language support

As with every release, MediaWiki 1.17 brings improved support for languages in MediaWiki, with improved translation and features for the many supported languages.

New languages:

• Moroccan Spoken Arabic (ary)
• Banjar (bjn)
• Kabardian (Cyrillic) (kbd-cyrl)
• Latgalian (ltg)
• Minangkabau (min)
• Dutch (informal) (nl-informal)
• Rusyn (rue)

API

API bug fixes and new features have been added to 1.17, providing more options for input and output.

• API output can now be formatted by PHP’s var_export() (format type is dbg/dbgfm).
• An API module was added to list page properties.
• PARAM_REQUIRED can now be used on parameters, to have the API enforce existence before code even reaches the module.
• The API now has a Really Simple Discovery module, useful for publishing service information by the API.

API breaking changes

The API contains 3 breaking changes against previous releases:

• action=patrol now requires POST.
• The patrol token is no longer the same as edit token.
• Session keys returned by ApiUpload are now strings instead of integers.

Other

• Interwiki links in articles are now recorded in a separate table.
• Users can now add CSS and JS to all skins by using User:<name>/common.css and User:<name>/common.js.
• Oracle Database support has been improved, and is now ready for beta testing. If you work in an environment where Oracle is readily available, and you can’t get access to MySQL, this may be a useful alternative for you. Please try it out and let us know if it works for you. Oracle support is not yet recommended for use in production.

This blog post is based on the MediaWiki 1.17 wiki page on www.mediawiki.org, which was collaboratively edited. Please see the page history for credits.