Facilitating the use of Wikidata in Wikimedia projects with a user-centered design approach

A lot of students learn the ropes as an intern working on Wikidata. They do their thing, write a thesis and the good news is that their work is appreciated and used. 

Charlene Kritschmar is the latest to write a thesis and it is on an approach to the use of Wikidata in other Wikimedia projects. The central question is how to manage Wikidata data from a Wikipedia. I like what I have read, there are a few things that need to be considered.

Wikidata notability and the thesis have it that "everything that has an entry in Wikipedia can also be an entry in Wikidata". Technically it is the other way around; every item in Wikidata may have an article in a Wikipedia. The difference is profound because a new article in a Wikipedia may have a pre-existing item on the topic in Wikidata.  It follows that statements may already be present. It makes it less cumbersome to write an article and fill an info box with data. 

Wikidata includes 17,677,925 items and the biggest Wikipedia knows about 5,164,030 articles. This makes Wikipedia centric thinking problematic. What any Wikipedia offers Wikidata is a big community who may improve the data quality on Wikidata and by inference improve the quality of all Wikipedias. The flip side of this coin is that there is no Wikipedia leading on what Wikidata has to say on any given subject.
Thanks,
       GerardM

#Wikimedia - the #adoption and #development of #functionality

If there is one chasm between developers and the "community" it is how functionality is perceived. A well known graph explains much of the pain. Software once developed, goes live. When it does for software like MediaWiki everybody in the community will be confronted with the new functionality at the same time. Adoption according to the graph is very much absent.

Some software can be implemented without much opposition. Great examples were the implementation of functionality that improves performance or the implementation of Wikidata to replace the old interwiki links. It is rather obvious because the average Community Joe does not really notice either. When they hear that things improved they are mostly happy for a job well done.

When Community Joe hears about new functionality is relevant. Development is discussed in its own environment but for most people new software is news at the time of deployment. For developers production is end of the line; time to move on. In a typical process from moving from design to a working product, things change. It will not work completely as anticipated even when the best user interface experts were involved. People expect magic and they get what humans can make.

When the community is involved in architecture, there is an even bigger chasm. Many community members are well qualified to argue their case. There are many of them and typically they get disappointed.

After the recent upheavals, it is time to move on. I have participated in the "Inspire campaign" with two ideas. I do not expect much but by expressing these ideas in a place where they are likely to be seen they have a better chance.

What is your idea? What does it take for you to be "inspired"?
Thanks,
       GerardM

Animated #SignWriting

I learned today about animated SignWriting. It is very much alike to an audio recording. The difference is that an animated gif like this will make it easier for someone who signs to learn SignWriting. The gif is an abstraction of real life movements and SignWriting is fixed, not animated, and uses the same symbols.

If it were possible to have gifs for all the words used, you could present them in the order of a book, an article.
Thanks,
     GerardM

The distribution of page views for #Wikipedia

More people are reading Wikipedia than ever before. The year on year growth for all Wikipedias is 35% and the prognosis for October is that this will at least continue.

At the bottom of the page view statistics you will find the distribution of the page views grouped by the size of the Wikipedia.

What is really interesting is that this last year the Wikipedias that are not in the top ten by size are growing faster than the 10 biggest Wikipedias. This change is around 2%.

So far the most attention has been going to the English Wikipedia. It has grown 28% YoY. When you compare this to the growth of all Wikipedias combined (35% YoY), it is obvious that the numbers suggest to put more effort in the other projects for best effect.

The most obvious and cheapest effort the WMF could take is by making sure the developers take their responsibility for the internationalisation of the software they write. The backlog of support requests is here.
Thanks,
     GerardM

#WMhack - About #Gerrit, #GIT and #SVN

When there is still so much noise about GIT and GERRIT more than a year after the transition from SVN, you can wonder if the move from SVN was the right one to make.

At the Amsterdam hackathon there was expert help available for everyone who wanted/needed to learn more about using GIT and Gerrit and as I was curious to the answer, I asked the question.

The most important reason to move was because of Git. Using Git many new functionalities became available that made the MediaWiki developers more productive. Gerrit is something of a pain but it is usable and it is improving. So much so that the conversation of dropping Gerrit has subsided.

When you wonder about the question "was it worth it", you also have to consider the TCO or, the total cost of ownership. I came up with the question if the increased productivity had to be offset with the cost of one person supporting Gerrit. I learned that SVN also required a lot of tweaking. The CodeReview extension was written by the Wikimedia  staff.

A hackathon isn't a hackathon if it is not for showing off things that are in the works.. GitBlit is as I understand it one tool that is intended to make things easy.. More about GitBlit here.
Thanks,
      GerardM

#Wikimedia Commons, a relevant history

A long long time ago when Commons the wiki was created, it was only a dream. The dream was to have one place where all the images could be shared freely among all the Wikimedia Foundation projects.

It was a dream with really practical implications. At that time sharing a picture meant uploading the same picture to another wiki. At that time removing a picture because of a copyright violation was removing it on one wiki and perhaps on one or more wikis as well. This was an inexact process with inadequate results. The dream of Commons was to store a file once and use it on any wiki. The dream of Commons was that administrative procedures would be significantly enhanced because everything could be done once and everything could be done right.

Commons was created and it took several months before pictures on Commons were available on the WMF projects.

Today Commons fulfils much of this promise. Media files are shared on all the WMF projects, you can even enable this functionality on external MediaWiki wikis. Most of the duplicate files have been deleted and a single copy only exist on Commons. Nowadays the administrative procedures are much more effective. Everybody involved in Commons will agree it is not perfect, far from it but, Commons is thriving nonetheless.

This notion of adventure that existed in the Wikimedia Foundation seems dead. I am convinced it should be revived. There are some signs that it is possible ... in things like moving towards agile development ...

More later
Thanks,
     GerardM

Can everybody read #Wikipedia?

A lot of effort goes into making "Wikipedia the encyclopaedia everybody can edit". The result is wonderful; there are Wikipedias in over 280 languages, a big effort is under way to make editing even easier and as so many people do edit, it became a rich almost authoritative resource. When Wikipedia goes off-line, students despair.

People do read Wikipedia, it is very popular but the notion that Wikipedia is hard to read is not really considered. Take for instance today's featured article.There are too many words on a line. For many people this makes it hard to read, some give up on an article or on Wikipedia.

Yes, you can change the way content is displayed on a computer screen. The problem is that people who have problems read websites in the default format.

The Wikimedia Foundation does have the expertise to consider these issues. The people who do have already too much on their plate to support the current software development. However, the proof of the pudding that is Wikipedia is in people READING its content and that makes this a key concern.
Thanks,
       GerardM

What will be the global benefit of using #Git for #MediaWiki

Git is a version control system. The Wikimedia Foundation is going to use it and frankly, I have no clue why. What I do understand is that the waving around of hands and the exclamation of buzz words looks good. I am not aware of the existence of a cost benefit analysis, something that would make things understandable.

My impression is that because of the introduction of git, the quality of the localisations and the internationalisations of MediaWiki and its extensions will be negatively impacted.

As it is, changes committed to Subversion, the current version control system, result in new messages in translatewiki.net within a day. These new messages become available to the twn community and as a result there is a steady stream of messages that need textual improvement and/or an explanation. As development progresses, the messages improve and the localisation is under way. At the time new functionality is ready for deployment it is localised in many languages.

With Git, there is no such thing as new messages that make their way to translatewiki.net. As I understand it this will only happen when the developer is done, the software is reviewed and is moved into "production" status. This means no internationalisation review, no textual improvements, no help texts and no localisations once software goes into production.

When a translator costs one hundredth part of a developer and we support three hundred languages then reducing the cost of development is not necessarily where we make our big wins. Our language support benefits from the current model and I fail to see why we should git going.

Really, what is the global benefit from using git over Subversion ?
Thanks,
      GerardM

The #Wikia translation jam

Wikia has projects in more then 100 languages and they have many people working on the localisation of their software at translatewiki.net. In order to make this possible, it is vitally important that the developer write code that is both translatable and well documented.

To make this point to their developers, the developers at the Polish office were all invited to join in a "translation jam". This resulted in 253 translations in just an hour. The comments by the developers were really interesting:

• "Wow, the interface is nice!"
• "This is fast..."
• "Oh, so that's the qqq documentation?"
• "We should give people links to trac in docs."

Translations, documentation and awareness of the internationalisation process; this is indeed the kind of activity that makes Wikia more effective and responsive.
Thanks,
      GerardM

The #agile #bugmeister

The #Wikimedia bugmeister works in an environment where increasingly more development teams adopt agile for their project management. As the function of a bugmeister is not defined in agile, the question was raised during the training for the localisation team what a bugmeister is in an agile environment.

We love our bugmeister and, we want to fit him in. The short answer is that a bugmeister represents aspects of both business analysis and quality control. The long answer has it that software is accepted based on the compliance of a "user story" in the software. For a reported bug to be a bug in the understanding of agile, it does not comply and it results in a user story explaining the breakage. The existence of a bug may also indicate that a "user story" exists where the existing functionality does break. The analysis of such a situation is what a business analyst does. The resulting user stories are presented to the "product owner" for inclusion in a next sprint.

When the previous paragraph sounds like gobbledygook, it is very much because of the specific terminology used by agile. Having specific terminology is a good thing because it forces an agile newbie to consider and reconsider his understanding of what is expected of him or her.
Thanks,
      GerardM

Q&A with the #MediaWiki #bugmeister

As more developers are working on the MediaWiki software, keeping a grip on the outstanding issues becomes more then a day job. Mark Hershberger has as its task to manage the needs of the community and does this in a hands-on fashion by bringing focus to the bugs reported in Bugzilla.

He has been doing it for a while now and this interview may give you an idea why having a bugmeister is a great idea.
Enjoy,
      GerardM

Can you explain what a bugmeister does
The main idea of a bugmeister, is clear from the posted job opening. This basically says that the bugmeister acts to bring the community's issues to the attention of WMF Project Managers and Developers. In addition to making sure the community's needs are heard, I've also worked recently to get the developers from the community involved in WMF activities. For example, I'll be hosting a fund-raising-focused triage in a few weeks where community input is wanted.

There seems to be more work then can be done by one bugmeister, is it true that by focusing on what needs the most tender love and care, you pick from the low hanging fruit ?
There are a lot of bugs in Bugzilla (over 6000 open issues right now) so I admit that bug-solving is driven somewhat by the squeaky wheel since those are the issues the community has shown the most interest in.  I do want to chew through those other bugs but I think that focusing on the new bugs and most-often referenced old bugs will get a lot of these bugs handled.

WMF is very much into agile development, is a bug triage something that you do at the beginning or at the end of a sprint

Good question.  I'm not sure I have an answer, but let me try.

Part of the purpose of triage -- at least how we're using it at the WMF -- is to understand problem reports and how to solve them and, after that, to assign them to a team or a person to work on.

So, as far as I understand sprints, triage would happen at the beginning.

Identifying and assessing the new bugs is what I understand you do. How does this fit into the process of fixing bugs
This varies with how high a priority the bug gets. For a quick overview of the time-line of my involvement time-line see the documentation on MediaWiki.org.

For example, bugs that are "highest" priority get very close attention. "high" priority bugs less so, and so on.

Every week there are more new bugs then there are bugs that are marked as fixed, how significant is this?

First, the weekly bug report isn't completely accurate -- it has some bugs.  For example, I noticed recently that it had reported 594 bugs created in one week when a query shows only 122 were created that week.

Second, it is normal for projects with open bug reporting tools to have more bugs created in a given period than closed.  I'm having trouble finding the report at the moment, but I recall seeing Mozilla Firefox had more bugs opened in a year then closed.

There is a perceived lack of people working on the review of software, can you comment
Over the past year Rob Lanphier has worked to get more people reviewing the code since, yes, we had too few people doing code review. We're in a lot better position now, but we still do not have the resources to review every bit of code that is in subversion.  I'd rather make the code repository and code distribution available to anyone who wants to extend MediaWiki, since this is better than telling people "We can't review your code, so it isn't welcome!"

As an example of how code review has gotten better, Rob Lanphier and I have been doing a lot of work on getting code reviewed faster and code marked FIXME fixed faster as we ramp up to a 1.18 deployment. This is a big pain point since we want to make more frequent releases of MediaWiki and become, as you pointed out, more agile.  And we don't want to release un-reviewed code.

I think, though, that if you look at the way FIXMEs have been resolved, or how new revisions have been reviewed, that you'll see some very good trends. In the past few weeks we've really been driving unreviewed code down pretty hard.  I'm confident that we can continue to keep unreviewed code low.

Code not written by WMF employees is certainly reviewed -- especially if it is going to be deployed on the site or released as part of MediaWiki. Since we only have limited resources, we cannot review all code in our Subversion repository.

For example, we host Semantic MediaWiki and extensions, but this code is not used on any Wikimedia website and is not distributed as part of MediaWiki, so, in order to make sure that the code we do release reviewed, we have to ignore Semantic MediaWiki for the most part.

An example of MediaWiki code that is not used on the cluster, but that is reviewed is the new Installer for MediaWiki or code that supports databases other than MySQL (such as PostgreSQL).  But, when it comes to Database code we're somewhat limited in our ability since we're so focused on MySQL, so we are looking to recruit volunteer reviewers who use and are familiar with the other databases that MediaWiki can use to help review this code.

Siebrand indicated that the presence of people from many disciplines was why the recent i18n bug triage was so successful. How does this mix with the small teams typical of agile?

Triages are more successful when more people are involved, true. Since a basic part of the Bug Triage, at least in the way I've been running them, is open community involvement -- I hold the triages on IRC and everyone is invited -- I don't think we're limited by small teams.

What is the measure of your success; is it in the volume of work done on bugs or is it in a changed way or working of the developing community or is it a mix of things

I think it is still too early to answer that question definitively. I'm actually working with a researcher to find out what sort of metrics we can find in the bug database to draw good conclusions about community involvement, # of bugs solved, and the like.

A function like a bugmeister seems far removed from the community editing on the projects, do you and how do you keep informed on what happens in the projects

I work with different community members to enable editing on the projects. Extending the functionality of a project like we did with the Google News Site Maps (GNSM) extension on wikinews is a big part of that.

This coming Wednesday, I am having a WikiBooks-focused triage with some people from that community that I met in the Collection extension triage. During this time we'll be able to find out how we can help their project succeed more.

What is your favourite MediaWiki project, what is the most challenging project
I admit a soft spot for WikiSource, but this is mostly because I think we could use it to provide a community-driven replacement for ReCaptcha. Google is using ReCaptcha to help the New York Times scan in old newspapers, but, as far as I can tell, they aren't making the result publicly available. I think we can do better.

Thanks,
Mark.

#Agile the process works !!

The "stand-up meetings" of the Wikimedia L10N team are great. Every day in the European morning we learn briefly about the latest developments, the work done, the work planned for the day. .

Stand-up meetings are part of the agile / scrum software development. They are great because you learn about what the current issues are.

What you are looking for is how things like stand-up meetings are worth their time. We wrestled with support for Narayam in the Chrome browser. Amir was fixing an issue with searching strings and was struggling with Chrome as well. Thanks to the stand-up meeting we learned early on that both Narayam and WikiEditor Search are likely to suffer from the same underlying issue.

The amount of time saved is a benefit. The real benefit is that it helps us to become more of a team. A team that understands that everyone in the team is a resource that can be drawn upon.
Thanks,
       GerardM

#Google supports the latest browsers

Supporting old old browsers is expensive. Not only are many old browsers less compatible with standards, they also do not support emerging standards like HTML5. The continued support for IE6 in MediaWiki prevents the adoption of new technology.

People who blog using Blogger have been informed that only the latest two releases of Chrome, Firefox, Internet Explorer and Safari will be supported from August 1. It also states that this will also affect popular Google applications like Gmail, Google Calendar, Google Talk, Google Docs and Google Sites.

Let us hope that Google will be able to force people to use an up to date browser; this will make the development of MediaWiki a lot easier and a lot less expensive.
Thanks,
       GerardM

#Wikia is a #MediaWiki powerhouse

#MediaWiki needs to evolve. It needs to become more usable, social and global. The good news for the Wikimedia Foundation is that it is not the only user of MediaWiki. Wikia has also invested deeply in extending MediaWiki and giving its MediaWiki wikis a much more modern experience.

It is wonderful news that four Wikia developers received SVN commit rights. By involving Wikia developers in the development process, Wikia will have less work to integrate all the bits and bobs in the future while WMF will benefit from the knowledge and code that already scales for Wikia.

It is a win-win situation and I hope we will learn more as this story develops.
Thanks,
      GerardM

Get ready for next gen #Wikipedia #Mobile

It is easy to check if your #Wikipedia is ready for the next generation mobile support. What is extremely good information is that the first iteration will be the replacement of the Ruby engine with a PHP engine.

The consequence is that initially, the user interface will not change. This means that you can check here at translatewiki.net if your language has its user interface completely localised.

When all the messages are translated, you need to request for the localisations to be brought into production. This is done by adding a bug to bugzilla. This is needed for the current Ruby interface.

Another step that you can take is the creation of a mobile main page for your language. Without a mobile main page and the localisation it will look like this example for the Pontic language.

With a mobile main page, sections of the main page will be provided by clicking on a button like in this example for the Indonesian language. This is particularly friendly on those people for whom the use of bandwidth comes at a premium.

Apparently bandwidth in the Netherlands is not considered much of an issue; its mobile main page shows more of the main page.

Given that the mobile use of Wikipedia is where most of its growth in traffic is, it is also growth where your language may benefit. When the result is less then successful, it is good to remember to post a bug in bugzilla because once the next generation PHP mobile engine kicks in, it will get attention.
Thanks,
        GerardM

Getting under your skin

When you use #MediaWiki, chances are that you personalised your wiki by developing a skin. Many wikis rely heavily on the monobook or vector skin. Some have been more adventurous and developed a skin of their own.

When you invested a lot of effort in a skin, it can be tricky to upgrade to a later version of MediaWiki. With work under way on the skin system, there is a call out to give us your skin.

We want to learn if your skins or ideas for skins can be realised in the new skin system. Particularly the skins that define things beyond the current restrictions is what we are looking for to break open the rigid structure of our current skins.
Thanks,
     GerardM

About #FOSS and #Telephony in #India

I found Mr Atul Chitnis on Twitter. He was retweeted and what he had to say makes sense. It also proved to be a find introduction on the subject of telephony and FOSS in India.

Some choice quotes:

A simple test: buy/borrow a phone used by your target audience. Point its browser at your site and try to use it. If you can't, weep.

If you are getting a website developed, ask the developers about mobile support at launch time. If they say "later", fire them instantly.

Almost ALL new Internet users in India will come online with mobile devices in 2011. If they can't read/use your site, shut shop and go home

PC penetration in India sucks ostrich eggs, but mobile device penetration is a different ball game - India leads the world there.

I can guarantee loss of visitors and business (and valuation) for any website in 2011 that is unusable in a mobile browser.

Saying "all mobile browsers show my site correctly" is a clear sign that you don't understand the issues

My take home lesson: if India is to be a strategic market, support for mobile telephones must be equally strategic.
Thanks,
      GerardM

#Katla is looming on the horizon for #mwhack

The last hack-a-thon in Berlin was great, except for the shadow hanging over Europe thanks to the volcano with the impossible name to spell correctly.. It had people stay longer and hack more..

Katla is the bigger sister of Eyjafjallajökull (cntrl-c cntrl-v) and it has a reputation to keep up that when the little sister blows its top, it does follow suit. With a hack-a-thon coming up in the USA, the question is not only if "documentation is not needed as the code makes it obvious" but also if European coders will get there and will get back as scheduled.

Doom scenarios have been considered:

• taking the boat back
• finishing university by correspondence
• finding a job in the USA
• all MediaWiki bugs get squashed

Thanks,
     GerardM

Introducing: the "nightmare star"

nightmare barn star

#Wikipedia has its barnstars, #MediaWiki does not have a way of showing appreciation. At translatewiki.net we show our appreciation for LiquidThreads for instance by using it. We care about supporting software by running its bleeding edge.

The value of localisation can be appreciated by giving it a value. For instance when the work of a developer is 100, the work of a localiser can be thought of as 1. Some simple arithmetic has the value of much of the localisation done higher then the development itself..

Siebrand makes it its policy to quietly work behind the scenes to get best results and only when this fails he will let his displeasure be known. Given that FlaggedRevisions is on trial at the English Wikipedia, given that there will be a vote to continue the use of the software this is surely an argument against the software.

Source

Prior to the process of publishing localisations there is a lot of Quality Control work done. When people no longer care, the quality will suffer even more.

Thanks,
      GerardM

Community vs planned software development

#MediaWiki development is of interest to many people. There are people who hack the functionality they need and there are people who work for an organisation. An organisation that may be the Wikimedia Foundation, but more people work for other organisations.

When Wikipedia was young, things were simpler. Everybody volunteered. There was less code, there were fewer systems and there was less traffic. MediaWiki is truly open source so you could still scratch your own itch and it was likely for the new or changed functionality to go live.

Hacking days in 2005

Then things started to scale. Wikipedia traffic grew exponentially, more servers were installed in multiple locations, down time became less acceptable, security became vitally important and the number of projects that needed support did not stop growing. To scale support, Brion and Tim were the first hired to do what they did best. After that they stopped scaling and that became really obvious because many issues refused to go away as the work left to do did not stop scaling.

Dilbert.com

Working with the community of developers was high on the list of priorities. As a result the ability to run "big projects" became complicated. As grants were accepted promising results in a set time frame and Brion left for StatusNet things reversed and it became more difficult for community developers to get their code assessed.

The office 2010

My own experience with extensions like the LocalisationUpdate may help to understand. The software worked fine but it was not optimal for the WMF as it updated one wiki at a time. Making it more efficient gobbled up time from several developers before it worked satisfactory. LocalisationUpdate proved itself because since its implementation the motivation of the localisers at translatewiki.net led to improved language support. Other extensions like the Babel extension and the Translate extension are still waiting for a keen eye that may make them WMF ready, both are translatewiki.net ready :)

As Brion was so crucial and did not scale and left for pastures green, a different, scalable approach had to be found. His job was split into pieces and first Danese was hired as a CTO. It is now her job to build an organisation that will do all the things Brion worked at and make it scale too. As the organisation did not stop growing and as there are plenty of projects making their way towards production it is not a sinecure.

At the same time people are clamouring for improved language support; this will enable people to edit Wikipedia and make it fun too; this will motivate them..
Thanks,
        GerardM