Building a Wikidata Tool – Behind the Scenes

, .

At 35C3, I held a one-hour presentation (talk page, recording) where I built a simple Wikidata tool from scratch and deployed it on Wikimedia Toolforge. To avoid giving the impression that I can just churn out tools like it’s no big deal, this blog post describes how I practiced the presentation and which problems I encountered at the time (so that I wouldn’t have to encounter them live during the presentation), as well as the problems that still occurred during the presentation despite my practice.

Basic idea

The general idea for this tool was suggested by Jonas during some conversations a while ago: while Wikidata’s mobile interface currently doesn’t let you edit, and fixing that will probably be a lot of work, one way for people to contribute while mobile, e. g. on the train to work or in similar situations, would be a kind of “patrolling Tinder” – swipe right to mark an edit as patrolled, swipe left to undo it or roll it back, or something like that.

Since I don’t have any experience working with touch devices or gesture inputs, I decided to go with three simple buttons for the first version: skip an edit (very important – never force users to make a contribution just to move forward when they might not understand the current task!), mark as patrolled, or rollback. People without rollback rights would simply not have the option to rollback – undoing one edit is not very helpful, since vandalism often happens in series of edits, and I didn’t want to reimplement rollback functionality for people without proper rollback rights. (Also, I couldn’t use “Tinder” in the name, so it was unimaginatively to be called “SpeedPatrolling”.)

I also asked Lydia if she was okay with this idea (all this was going to be a private activity, but still, I don’t want to do things that she thinks are a bad idea, probably for good reasons that I can’t think of). We looked through the list of self-contained tasks around Wikidata for something else to do, but couldn’t find much that fit the bill of this presentation (Toolforge tool, uses OAuth, can be built in one hour), so she said I could go ahead with this project.


Lots of things changed during the preparation phase. I didn’t keep track of all of them, so the following list, recalled from memory, is likely incomplete.

During the presentation

Despite my practice, some things went wrong during the presentation as well. You can watch those in the recording, of course, but I might as well list them here, too:

And there we go! I hope this makes me seem less like, I don’t know, some kind of wizard? It’s completely normal to run into problems while building a tool (or doing any kind of software development, I suppose) – what matters is that you can find ways overcome those problems (including but not limited to solving them), and get help when you need it. Try it out, it’s a lot of fun!