en.planet.wikimedia

By Lucy Crompton-Reid, Wikimedia UK Chief Executive

I was delighted to be part of planning and delivering Wikimedia UK’s Education Summit in partnership with Middlesex University in February and wanted to share some notes, insights and presentations from that event with a broader audience than the 45 or so students, educators, academics and Wikimedians that were able to attend in person. This is something of a long read so please feel free to dip in and out, to look at the tweets from the day and to explore the excellent slides produced by a range of speakers.

Melissa Highton, Director of Learning, Teaching and Web Services and Assistant Principal for Online Learning at the University of Edinburgh, gave a rousing start to the summit, using her keynote speech to advocate for Wikimedians in Residence at universities. With digital capabilities now a key component in student employability, and driving innovation in the economy, Melissa’s argument was that higher education institutions can’t afford not to have a Wikimedian on their team! The work in Edinburgh has improved the quality and quantity of open knowledge, embedded information literacy skills in the curriculum and made it easier to develop authentic learning experiences for larger bodies of students. For Edinburgh undergraduates, the opportunity to edit Wikipedia means that they are part of a worldwide open source software project, which Melissa sees as a significant authentic learning opportunity. The work enables students to understand sources and copyright and also “leads into discussions about the privilege and geography of knowledge”, as well as questions about neutrality.

Melissa also spoke about gender inequality in science and technology, and the role that working with Wikimedia can play in tackling structural barriers for women working in academia, particularly in relation to Athena Swann initiatives. She noted that the kind of work a Wikimedian in Residence will do can deliver successful, measurable outcomes on gender equality; and added that she feels “academics are missing a trick if they are not factoring Wikipedia into public engagement and understanding”.

To close, Melissa touched on some of the challenges inherent in working with the Wikimedia community, and the need for a resident to help negotiate and navigate the challenges of editing Wikipedia as a structured group activity. As she put it, “Wikimedians will save you from Wikimedians.”

Melissa’s high-level overview of the university wide impact of and strategic case for a Wikimedian in Residence was complemented brilliantly by Stefan Lutschinger’s more practical but no less compelling keynote speech focused on his own approach to Wikipedia in the curriculum. Stefan is Associate Lecturer in Digital Publishing at Middlesex University with whom Wikimedia UK worked closely in planning the event. He gave a detailed account of how the module he has developed and run for three years – with input from volunteers Ed Hands and Fabian Tompsett – is building digital literacy and confidence amongst his students and enhancing academic practice. He also touched upon Wikidata, as a resource that enables undergraduates to “understand the architecture, the anatomy, of data”, and ended his speech by sharing his ambition to make editing Wikipedia a mandatory part of the curriculum for first year students at Middlesex.

Following these excellent speeches the summit broke into three workshop spaces, with the volunteer Nav Evans and Wikimedian in Residence at Edinburgh University, Ewan McAndrew, running a practical workshop on Wikidata; Wikimedia UK’s Richard Nevell and Hephzibah Israel, Lecturer in Translation Studies at Edinburgh, giving a presentation on Wikipedia in the Classroom and the use of the Outreach Dashboard; and an unconference space facilitated by Andy Mabbett. I attended the latter and participated in a wide-ranging discussion with a group of established Wikimedians and one or two people from the university sector, which explored instructional design and materials for developing editing skills, the challenges of adapting resources for different learning styles and the need to be explicit about the benefit of editing in terms of research and analytical skills, plus next steps and potential partners for the UK Chapter.

After the morning workshops we moved into Lightning Talks, with Fabian Tompsett kicking us off by talking about his residency at the May Day Room. In particular he highlighted the potential offered by Wikisource. This is sometimes seen as a repository for older materials but we should be encouraging more academics to upload their materials and papers.

It was fantastic to have a number of presentations from Stefan’s students, including Behlul, Adrianna and Lauryna, who talked about their experiences of working on Wikimedia as part of their Media Studies course. Behlul shared the creation of a pirate pad to edit articles as a group, and noted that he now views Wikimedia as a platform for different learning opportunities rather than just somewhere to gain information. Adrianna focused on Fake news vs Wikipedia and was “fascinated by what a reliable source of information Wikipedia actually turns out to be…contributions can be traced and authors are accountable. Tens of thousands of Wikipedia editors act as watch dogs”. She also quoted the Wikimedia Foundation’s Executive Director, Katherine Maher, who describes the projects as a “public park for knowledge.”

Educator and Wikimedian Charles Matthews gave a presentation on a new online learning resource that he is currently developing, with input from Wikimedia UK trustee Doug Taylor, based on the idea of questions as data. He is interested in annotation, collaboration and translation of educational materials, with robust metadata that tells you more about the resource such as to what extent it has been tested in the classroom and how has it been used successfully. To make this project work will require a big database of questions that Charles and Doug are hoping to crowd source, with the aim of having a link to relevant questions from the sidebar on any given Wikipedia article.

Clem Rutter also highlighted the potential to make better use of existing technologies to support the use of Wikimedia as a tool for teaching and learning. He gave a short introduction to his Portal for Learning, which draws on his substantial experience as a secondary school teacher and his existing links and relationships with the formal education community.

Ewan McAndrew gave an energetic and comprehensive account of his work at Edinburgh University, focusing on the successful introduction of Wikipedia in the Classroom assignments in a number of departments. He sees Wikipedia as a powerful tool for educators and not something that has to be additional to their practice and described the work of Translation Studies MA students contributing in one language and translating into a different language using the content translation tool, noting how allowing students to take ownership of this work was a critical motivating factor. He also shared outcomes from the World Christianity course, in which students edited Wikipedia to present a more holistic, broader worldview of Christianity, which otherwise tends to be written about with a western bias.

Ewan is very pleased that 65% of event attendees have been women, a key target audience for his events given the gender gap highlighted by Melissa earlier in the day. He feels that “we need to demystify Wikipedia and make it accessible, share good practice and not reinvent the wheel” when working across universities. With this in mind Ewan is in the process of creating and sharing resources, videos and lesson plans for educators.

Judith Scammell closed the lightning talks by giving her perspective as a librarian based at St George’s University in London. She is in the early stages of getting staff and students to use Wikipedia but feels that it is ideal for building the 21st century learning skills of enquiry, creativity, participation and digital Literacy. Judith has been inspired by fellow librarian Natalie Lafferty, based at Dundee university, who is involving technology in learning and shares her insights through her blog e-LiME.

Following lunch and networking, the attendees of the summit again broke into three workshop sessions, with another unconference space, a presentation by Dr Martin Poulter and Liz McCarthy on working together on a Wikimedian in Residence programme at Bodleian Libraries and now across the University of Oxford, and Josie Taylor and Lorna Campbell leading a session on curating Wikimedia’s educational resources. I very much enjoyed hearing from Wikimedian in Resident Martin and Liz – Web and Digital Media Manager at Bodleian Libraries – about the success of the residency in terms of correcting bias. In his initial residency, Martin focused on sharing the 8000 files that he felt were of most interest and that represented hidden histories, with these now having had nearly 50 million page views. In the new phase of the residency he is working across the whole university, building relationships at an early stage with a dozen big research projects to build in openness from the start, and linking research outputs and educational materials. They are now thinking more about interdisciplinary practice and feel there is potential benefit for every department of the university, with Liz commenting that hosting a Wikimedian in Residence is “an obvious path on the way to public engagement”.

Finally, we gathered together at the end of the day in a plenary discussion to share key points from each session, and to start thinking about future developments. Martin Poulter encouraged everyone to take the next step in implementing any new ideas that have emerged from the summit, and Nav Evans encouraged people to create their own Histropedia timeline. I hope that everyone who attended was able to take away at least one thing that they can do at an individual level and that those in positions of influence are thinking about how they can create change at an institutional level. For Wikimedia UK, some key action points emerged, including the need to:

• Develop and share our thinking in terms of education, particularly how we prioritise this work and what support we can offer teachers and learners
  Support existing Wikimedia education projects and nurture new ideas.
• Build on the work that’s been started in terms of curating and creating resources and redeveloping the education pages on the Wikimedia UK site.
• Continue to provide opportunities for people working within education and Wikimedia to come together virtually and in person to share practice.
• Share models of good practice, case studies and learning.

If you’re interested in how Wikimedia can play in role in education and support learners to contribute to the Wikimedia projects, please email us at education@wikimedia.org.uk.

Photo by gnuckx, public domain/CC0.

Ever started searching for something on Wikipedia and wondered—really, is that all that there is? Does it feel like you’re somehow playing hide and seek with all the knowledge that’s out there?

Wouldn’t it be great to see articles or categories that are similar to your search query and maybe some related images or links to other languages in which to read that article?  Or, perhaps you just want to read and contribute to projects other than Wikipedia but need a jump start with a few short summaries from sister projects.

Even if you simply enjoy seeing interesting snippets and images, based off of your search query, then you’ll really like what we have in store. We’re starting to test out some really cool features that will enable some fun and fascinated clicking—down the rabbit hole of Wikipedia. But first, let’s look at what we’ve been doing over the last couple of years.

Back end search

The Discovery Search team has been doing tons of work creating, updating, and finessing the search back end to enhance search queries. There have been many complex things that have happened, things like: adding ascii-folding and stemming, detecting when a visitor might be typing in a language that is different than the Wikipedia that they are on, switching from tf-idf to BM25, dropping trailing question marks, and updating to ElasticSearch version 5. Whew!

We have much more planned in the coming months—machine learning with ‘learning to rank’, investigating and deploying new language analyzers, and, after doing an exhaustive analysis, removing quotes within queries. We’ll also be interacting closely with the new Structured Data team in their upcoming work on Commons to make freely licensed images accessible and reusable across the web.

Front end search

After all that back end search awesomeness, we needed to spruce up the part that the majority of our readers and editors actually interface with: the search results page! We started brainstorming during the late summer of 2016 on what we could do to make search results better—to easily find interesting, relevant content and to create a more intuitive viewing experience. We designed and refined numerous ideas on how to improve the search results page and received lots of good feedback from the community.

Empowered by that feedback, we began testing, starting with a display of results from the Wikimedia sister projects next to the regular search results. The idea for this test was to enable discovery into other projects—projects that our visitors might not have known about—by displaying interesting results in small snippets. The sidebar display of the sister projects borrows from a similar feature that is already in use on the Italian, Catalan and French Wikipedias. We’ve run a couple tests on the sister project search results with detailed analysis completed and, after a bit of final touches to the code, we will release the new functionality into production on all Wikipedias near the end of April 2017.

The sister projects are an integral part of the Wikimedia family and the associated links denoting each project are often found near the footer of the front page of each Wikipedia. The Wikimedia sister projects are:

Our next test will be to add in additional information and related results for each search query. This will be in the form of an ‘explore similar’ link that, when someone interacts with the link, an expanded display will appear with related pages, categories and links to the article in other languages—all of which might lead to further knowledge discovery. We know that not every search query will return exactly what folks were looking for, but we feel that adding links to similar, but related information would be helpful and, possibly, super interesting!

We also plan on doing a few more tests in the coming year:

• Test a new display that will show the pronunciation of a word with its definition and part of speech—all from existing data in Wiktionary. Initially, this will be in English only.
• Test placing a small image (from the article) next to each search result that is displayed on the page.
• Test an additional feature that will use a new metadata display in the search box that is located on the top right of most pages in Wikipedia, similar to what happens on the Wikipedia.org portal page when a user starts typing into the search box.

For the more technical minded, there is a way to test out these new features in your own browser. For the sister project search results, it will require a bit of URL manipulation; but for the explore similar and Wiktionary widget, you’ll need a Wikipedia account and be able to create (or edit) your common.js file. Detailed information is available on Mediawiki.

Once the testing, analysis and feedback cycle is done for each new feature, we’d like to slowly implement them into production on all Wikipedias throughout the rest of the year. We’re really hoping that these enhancements will deepen the usefulness of search results and enable our readers and editors to be even more productive and inspired!

Deborah Tankersley, Product Manager, Discovery Product and Analysis
Wikimedia Foundation

tl;dr: I wrote a quiz interface on top of a MediaWiki/WikiBase installation. It ties together material from Wikidata, Commons, and Wikipedia, to form a new educational resource. I hope the code will eventually be taken up by a Wikimedia chapter, as part of an OER strategy.

The past

There have been many attempts in the WikiVerse to get a foot into the education domain. Wikipedia is used extensively in this domain, but it is more useful for introductions to a topic, and as a reference, rather than a learning tool. Wikiversity was an attempt to get into university-level education, but even I do not know anyone who actually uses it. Wikibooks has more and better contents, but many wikibooks are mere sub-stub equivalents, rather than usable, fully-fledged textbooks. There has been much talk about OER, offline content for internet-challenged areas, etc. But the fabled “killer app” has so far failed to emerge.

Enter Charles Matthews, who, like myself, is situated in Cambridge. Among other things, he organises the Cambridge Wikipedia meetup, and we do meet occasionally for coffee between those. In 2014, he started talking to me about quizzes. At the time, he was designing teaching material for Wikimedia UK, using Moodle, as a component in Wikipedia-related courses. He quickly became aware of the limitations of that software, which include (but are not limited to) general software bloat, significant hardware requirements, and hurdles in re-using questions and quizzes in other contexts. Despite all this, Moodle is rather widely used, and the MediaWiki Quiz extension is not exactly representing itself as a viable replacement.

A quiz can be a powerful tool for education. It can be used by teachers and mentors to check on the progress of their students, and by the students themselves, to check their own progress and readiness for an upcoming test.

As the benefits are obvious, and the technical requirements appeared rather low, I wrote (at least) two versions of a proof-of-concept tool named wikisoba. The interface looked somewhat appealing, but storage is a sore point. The latest version uses JSON stored as a wiki page, which needs to be edited manually. Clearly, not an ideal way to attract users these days.

Eventually, a new thought emerged. A quiz is a collection of “pages” or “slides”, representing a question (of various types), or maybe a text to read beforehand. A question, in turn, consists of a title, a question text (usually), possible answers, etc. A question is therefore the main “unit”, and should be treated on its own, separate from other questions. Questions can then be bundled into quizzes; this allows for re-use of questions in multiple quizzes, maybe awarding different points (a question could yield high points in an entry-level quiz, but less points in an advanced quiz). The separation of question and quiz makes for a modular, scalable, reusable architecture. Treating each question as a separate unit is therefore a cornerstone of any successful system for (self-)teaching and (self-)evaluation.

It would, of course, be possible to set up a database for this, but then it would require an interface, constraint checking, all the things that make a project complicated and prone to fail. Luckily, there exists a software that already offers adequate storage, querying, interface etc. I speak of WikiBase, the MediaWiki extension used to power Wikidata (and soon Commons as well). Each question could be an item, with the details encoded in statements. Likewise, a quiz would be an item, referencing question items. WikiBase offers a powerful API to manage, import, and export questions; it comes with build-in openness.

The present

There is a small problem, however; the default WikiBase interface is not exactly appealing for non-geeks. Also, there is obviously no way to “play” a quiz in a reasonable manner. So I decided to use my recent experience with vue.js to write an alternative interface to MediaWiki/WikiBase, designed to generate questions and quizzes, and to play a quiz in a more pleasant way. The result has the working title Comprende!, and can be regarded as a fully functional, initial version of a WikiBase-driven question/quiz system. The underlying “vanilla” WikiBase installation is also accessible. To jump right in, you can test your biology knowledge!

There are currently three question types available:

• Multiple-choice questions, the classic
• “Label image” presents an image from Commons, letting you assign labels to marked points in the image
• Info panels, presenting information to learn (to be interspersed with actual questions)

All aspects of the questions are stored in WikiBase; they can have a title, a short text, and an intro section; for the moment, the latter can be a specific section of a Wikipedia article (of a specific revision, by default), but other types (Commons images, for example) are possible. When used in “info panel” type questions (example), a lot of markup, including images, is preserved; for intro sections in other question types, it is simplified to mere text.

Live translating of interface text.

Wikidata is multi-lingual by design, and so is Comprende!. An answer or image label can be a text stored as multi-lingual (or monolingual, in WikiBase nomenclature) strings, as a Wikidata item reference, giving instant access to all the translations there. Also, all interface text is stored in an item, and translations can be done live within the interface.

Questions can be grouped and ordered into a quiz. Everyone can “play” and design a quiz (Chrome works best at the moment), but you need to be logged into the WikiBase setup to save the result. Answers can be added, dragged around to change the order, and each question can be assigned a number of points, which will be awarded based on the correct “sub-answers”. You can print the current quiz design (no need to save it), and most of the “chrome” will disappear, leaving only the questions; instant old-fashioned paper test!

While playing the quiz, one can see how many points they have, how many questions are left etc. Some mobile optimisations like reflow for portrait mode, and a fixed “next question” button at the bottom, are in place. At the end of the quiz, there is a final screen, presenting the user with their quiz result.

To demonstrate the compatibility with existing question/quiz systems, I added a rudimentary Moodle XML import; an example quiz is available. Another obvious import format to add would be GIFT. Moodle XML export is also on the to-do-list.

The future

All this is obviously just a start. A “killer feature” would be a SPARQL setup, federating Wikidata. Entry-level quizzes for molecular biology? Questions that use Wikidata answers that are chemicals? I can see educators flocking to this, especially if material is available in, or easily translated into, their language. More questions types could emphasise the strength of this approach. Questions could even be mini-games etc.

Another aspect I have not worked on yet is logging results. This could be done per user, where the user can add their result in a quiz to a dedicated tracking item for their user name. Likewise, a quiz could record user results (automatically or voluntarily).

One possibility would be to live for the questions, quizzes etc. in a dedicated namespace on Wikidata (so as to not contaminate the default namespace). That would simplify the SPARQL setup, and get the existing community involved. The Wikitionary-related changes on Wikidata will cover all that is needed on the backend; the interface is all HTML/JS, not even an extension is required, so next to no security or integration issues. Ah, one can dream, right?

I've submitted a talk to Wikimania titled apt install mediawiki. It's about getting the MediaWiki package back into Debian, and efforts to improve the overall process. If you're interested, sign up on the submissions page :)

Lindsey Kuper asked:

I’m interested in hearing about [open source software] projects that have successfully adopted an "only insiders use the issue tracker" approach. For instance, a project might have a mailing list where users discuss bugs in an unstructured way, and project insiders distill those discussions into bug reports to be entered into the issue tracker. Where does this approach succeed, and where does it fail? How can projects that operate this way effectively communicate their expectations to non-insider users, especially those users who might be more accustomed to using issue trackers directly?

...sick of "just file a bug with us through github!" You realize that's offputting to your average users, right?

If you want actual, average users to submit bugs, you know what you have to do: You have to use email. Sorry, but it's true.

Oh, and that goes especially for high-risk users. Give them easy ways to talk to you. You know who you are, devs.

Both Kuper and York get at: How do we open source maintainers get the bug reports we need, in a way that works for us and for our users?

My short answer is that open source projects should have centralized bug trackers that are as easy as possible to work in as an expert user, and that they should find automated ways to accept bug reports from less structured and less expert sources. I'll discuss some examples and then some general principles.

Dreamwidth: Dreamwidth takes support questions via a customer support interface. The volunteers and paid staff answering those questions sometimes find that a support request reveals a bug, and then file it in GitHub on the customer's behalf, then tell her when it's fixed. (Each support request has a private section that only Support can see, which makes it easier to track the connection between Support requests and GitHub issues, and Support regulars tend to have enough ambient awareness of both Support and GitHub traffic to speak up when relevant issues crop up or get closed.) Dreamwidth users and developers who are comfortable using the GitHub issue tracker are welcomed if they want to file bugs there directly instead.

Dreamwidth also has a non-GitHub interface for feature suggestions: the suggestions form is the preferred interface for people to suggest new features for Dreamwidth. Users post their suggestions into a queue and a maintainer chooses whether to turn that suggestion into a post for open discussion in the dw-suggestions community, or whether to bounce it straight into GitHub (e.g., for an uncontroversial request to whitelist a new site for media embedding or add a new site for easy cross-site user linking, or at the maintainer's prerogative). Once a maintainer has turned a suggestion into a post, other users use an interface familiar to them (Dreamwidth itself) to discuss whether they want the feature. Then, if they and the maintainer come to consensus and approve it, the maintainer adds a ticket for it to GitHub. That moderation step has been a bottleneck in the past, and the process of moving a suggestion into GitHub also hasn't yet been automated.

Since discussion about site changes needs to include users who aren't developers, Dreamwidth maintainers prefer that people use the suggestions form; experienced developers sometimes start conversations in GitHub, but the norm (at least the official norm) is to use dw-suggestions; I think the occasional GitHub comment suffices for redirecting these discussions.

Zulip: We use GitHub issues. The Zulip installations hosted by Kandra Labs (the for-profit company that stewards the open source project) also have a "Send feedback" button in one of the upper corners of the Zulip web user interface. Clicking this opens a private message conversation with feedback-at-zulip.com, which users used more heavily when the product was younger. (We also used to have a nice setup where we could actually send you replies in-Zulip, and may bring that back in the future.)

I often see Tim Abbott and other maintainers noticing problems that new users/customers are having and, while helping them (via the zulip-devel mailing list, via the Zuliping-about-Zulip chat at chat.zulip.org, or in person), opening GitHub issues about the issue, as the next step towards a long-term fix. But -- as with the Dreamwidth example -- it is also fine for people who are used to filing bug reports or feature requests directly to go ahead and file them in GitHub. And if Tim et alia know that the person they're helping has that skill and probably has the time to write up a quick issue, then the maintainers will likely say, "hey would you mind filing that in GitHub?"

We sometimes hold live office hours at chat.zulip.org. At yesterday's office hour, Tim set up a discussion topic named "warts" and said,

I think another good topic is to just have folks list the things that feel like they're some of our uglier/messier parts of the UI that should be getting attention. We can use this topic to collect them :).

Several people spoke up about little irritations, and we ended up filing and fixing multiple issues. One of Zulip's lead developers, Steve Howell, reflected: "As many bug reports as we get normally, asking for 'warts' seems to empower customers to report stuff that might not be considered bugs, or just empower them to speak up more." I'd also point out that some people feel more comfortable responding to an invitation in a synchronous conversation than initiating an asynchronous one -- plus, there's the power of personal invitation to consider.

As user uptake goes up, I hope we'll also have more of a presence on Twitter, IRC, and Stack Overflow in order to engage people who are asking questions there and help them there, and get proto-bug reports from those platforms to transform into GitHub issues. We already use our Twitter integration to help -- if someone mentions Zulip in a public Tweet, a bot tells us about it in our developers' livechat, so we can log into our Twitter account and reply to them.

MediaWiki and Wikimedia: Wikipedia editors and other contributors have a lot of places they communicate about the sites themselves, such as the technical-issues subforum of English Wikipedia's "Village Pump", and similar community-conversation pages within other Wikipedias, Wikivoyages, etc. Under my leadership, the team within Wikimedia Foundation's engineering department that liaised with the larger Wikimedia community grew more systematic about working with those Wikimedia spaces where users were saying things that were proto-bug reports. We got more systematic about listening for those complaints, filing them as bugs in the public bug tracker, and keeping in touch with those reporters as bugs progressed -- and building a kind of ambassador community to further that kind of information dissemination. (I don't know how well that worked out; I think we built a better social infrastructure for people who were already doing that kind of volunteer work ad hoc, but I don't know whether we succeeded in recruiting more people to do it, and I haven't kept a close eye on how that's gone in the years since I left.)

We also worked to make it easy for people to report bugs into the main bug tracker. The Bugzilla installation we had for most of the time that I was at Wikimedia had two bug reporting forms: a "simple" submission form that we pointed most people to, with far fewer fields, and an "advanced" form that Wikimedia-experienced developers used. They've moved to Phabricator now, and I don't know whether they've replicated that kind of two-lane approach.

A closed-source example: FogBugz. When I was at Fog Creek Software doing sales and customer support, we used FogBugz as our internal bug tracker (to manage TODOs for our products,* and as our customer relationship manager). Emails into the relevant email addresses landed in FogBugz, so it was easy for me to reply directly to help requests that I could fix myself, and easy for me to note "this customer support request demonstrates a bug we need to fix" and turn it into a bug report, or open a related issue for that bug report. If I recall correctly, I could even set the visibility of the issue so the customer could see it and its progress (unusual, since almost all our issue-tracking was private and visible only within the company).

An interface example: Debian. Debian lets you report bugs via email and via the command-line reportbug program. As the "how to use BTS" guide says,

some spam messages managed to send mails to -done addresses. Those are usually easily caught, and given that everything can get reverted easily it's not that troublesome. The package maintainers usually notice those and react to them, as do the BTS admins regularly.

The BTS admins also have the possibility to block some senders from working on the bug tracking system in case they deliberately do malicious things.

But being open and inviting everyone to work on bugs totally outweighs the troubles that sometimes pop up because of misuse of the control bot.

And that leads us to:

General guidelines: Dreamwidth, Zulip, MediaWiki, and Debian don't discourage people from filing bug reports in the official central bug tracker. Even someone quite new to a particular codebase/project can file a very helpful and clear bug report, after all, as long as they know the general skill of filing a good bug report. Rather, I think the philosophy is what you might find in hospitable activism in general: meet people where they are, and provide a means for them to conveniently start the conversation in a time, place, and manner that's more comfortable for them. For a lot of people, that means email, or the product itself.

Failure modes can include:

• a disconnect among the different "places" such that the central bug tracker is a black hole and nothing gets reported back to the more accessible place or the original reporter
• a feeling of elitism where only special important people are allowed to even comment in the main bug tracker
• bottlenecks such that it seems like there's a non-bug-tracker way to report a question or suggestion but that process has creaked to a halt and is silently blocking momentum
• bottlenecks in bug triage
• brusque reaction at the stage where the bug report gets to the central bug tracker (e.g., "oh that's a duplicate; CLOSE" without explanation or thanks), which jars the user (who's expecting more explicit friendliness) and which the user perceives as hostile

Whether or not you choose to increase the number of interfaces you enable for bug reporting, it's worth improving the user experience for people reporting bugs into your main bug tracker. Tedious, lots-of-fields issue tracker templates and UIs decrease throughput, even for skilled bug reporters who simply aren't used to the particular codebase/project they're currently trying to file an issue about. So we should make that easier. You can provide an easy web form, as Wikimedia did via the simplified Bugzilla form, or an email or in-application route, as Debian does.

And FLOSS projects oughta do what the Accumulo folks did for Kuper, too, saying, "I can file that bug for you." We can be inclusive-or rather than exclusive-or about it, you know? That's how I figure it.

* Those products were CityDesk, Copilot, and FogBugz -- this was before Kiln, Stack Overflow, Trello, and Glitch.

Thanks to Lindsey Kuper and Jillian C. York for sparking this post, and thanks to azurelunatic for making sure I got Dreamwidth details right.

As you probably already know, Wikipedia is a website. A website has content—the articles; and it has user interface—the menus around the articles and the various screens that let editors edit the articles and communicate to each other.

Another thing that you probably already know is that Wikipedia is massively multilingual, so both the content and the user interface must be translated.

Translation of articles is a topic for another post. This post is about getting all of the user interface translated to your language, as quickly and efficiently as possible.

The most important piece of software that powers Wikipedia and its sister projects is called MediaWiki. As of today, there are 3,335 messages to translate in MediaWiki, and the number grows frequently. “Messages” in the MediaWiki jargon are strings that are shown in the user interface, and that can be translated. In addition to core MediaWiki, Wikipedia also has dozens of MediaWiki extensions installed, some of them very important—extensions for displaying citations and mathematical formulas, uploading files, receiving notifications, mobile browsing, different editing environments, etc. There are around 3,500 messages to translate in the main extensions, and over 10,000 messages to translate if you want to have all the extensions translated. There are also the Wikipedia mobile apps and additional tools for making automated edits (bots) and monitoring vandalism, with several hundreds of messages each.

Translating all of it probably sounds like an enormous job, and yes, it takes time, but it’s doable.

In February 2011 or so—sorry, I don’t remember the exact date—I completed the translation into Hebrew of all of the messages that are needed for Wikipedia and projects related to it. All. The total, complete, no-excuses, premium Wikipedia experience, in Hebrew. Every single part of the MediaWiki software, extensions and additional tools was translated to Hebrew, and if you were a Hebrew speaker, you didn’t need to know a single English word to use it.

I wasn’t the only one who did this of course. There were plenty of other people who did this before I joined the effort, and plenty of others who helped along the way: Rotem Dan, Ofra Hod, Yaron Shahrabani, Rotem Liss, Or Shapiro, Shani Evenshtein, Inkbug (whose real name I don’t know), and many others. But back then in 2011 it was I who made a conscious effort to get to 100%. It took me quite a few weeks, but I made it.

Of course, the software that powers Wikipedia changes every single day. So the day after the translations statistics got to 100%, they went down to 99%, because new messages to translate were added. But there were just a few of them, and it took me a few minutes to translate them and get back to 100%.

I’ve been doing this almost every day since then, keeping Hebrew at 100%. Sometimes it slips because I am traveling or I am ill. It slipped for quite a few months because in late 2014 I became a father, and a lot of new messages happened to be added at the same time, but Hebrew is back at 100% now. And I keep doing this.

With the sincere hope that this will be useful for translating the software behind Wikipedia to your language, let me tell you how.

Preparation

First, let’s do some work to set you up.

• Get a translatewiki.net account if you haven’t already.
• Make sure you know your language code.
• Go to your preferences, to the Editing tab, and add languages that you know to Assistant languages. For example, if you speak one of the native languages of South America like Aymara (ay) or Quechua (qu), then you probably also know Spanish (es) or Portuguese (pt), and if you speak one of the languages of the former Soviet Union like Tatar (tt) or Azerbaijani (az), then you probably also know Russian (ru). When available, translations to these languages will be shown in addition to English.
• Familiarize yourself with the Support page and with the general localization guidelines for MediaWiki.
• Add yourself to the portal for your language. The page name is Portal:Xyz, where Xyz is your language code.

Priorities, part 1

The translatewiki.net website hosts many projects to translate beyond stuff related to Wikipedia. It hosts such respectable Free Software projects as OpenStreetMap, Etherpad, MathJax, Blockly, and others. Also, not all the MediaWiki extensions are used on Wikimedia projects; there are plenty of extensions, with thousands of translatable messages, that are not used by Wikimedia, but only on other sites, but they use translatewiki.net as the platform for translation of their user interface.

It would be nice to translate all of it, but because I don’t have time for that, I have to prioritize.

On my translatewiki.net user page I have a list of direct links to the translation interface of the projects that are the most important:

• Core MediaWiki: the heart of it all
• Extensions used by Wikimedia: the extensions on Wikipedia and related sites
• MediaWiki Action Api: the documentation of the API functions, mostly interesting to developers who build tools around Wikimedia projects
• Wikipedia Android app
• Wikipedia iOS app
• Installer: MediaWiki’s installer, not used in Wikipedia because MediaWiki is already installed there, but useful for people who install their own instances of MediaWiki, in particular new developers
• Intuition: a set of different tools, like edit counters, statistics collectors, etc.
• Pywikibot: a library for writing bots—scripts that make useful automatic edits to MediaWiki sites.

I usually don’t work on translating other projects unless all of the above projects are 100% translated to Hebrew. I occasionally make an exception for OpenStreetMap or Etherpad, but only if there’s little to translate there and the untranslated MediaWiki-related projects are not very important.

Priorities, part 2

So how can you know what is important among more than 15,000 messages from the Wikimedia universe?

Start from MediaWiki most important messages. If your language is not at 100% in this list, it absolutely must be. This list is automatically created periodically by counting which 600 or so messages are actually shown most frequently to Wikipedia users. This list includes messages from MediaWiki core and a bunch of extensions, so when you’re done with it, you’ll see that the statistics for several groups improved by themselves.

Now, if the translation of MediaWiki core to your language is not yet at 18%, get it there. Why 18%? Because that’s the threshold for exporting your language to the source code. This is essential for making it possible to use your language in your Wikipedia (or Incubator). It will be quite easy to find short and simple messages to translate (of course, you still have to do it carefully and correctly).

Getting Things Done, One by One

Once you have the most important MediaWiki messages 100% and at least 18% of MediaWiki core is translated to your language, where do you go next?

I have surprising advice.

You need to get everything to 100% eventually. There are several ways to get there. Your mileage may vary, but I’m going to suggest the way that worked for me: Complete the easiest piece that will get your language closer to 100%! For me this is an easy way to strike an item off my list and feel that I accomplished something.

But still, there are so many items at which you could start looking! So here’s my selection of components that are more user-visible and less technical, sorted not by importance, but by the number of messages to translate:

• Cite: the extension that displays footnotes on Wikipedia
• Babel: the extension that displays boxes on userpages with information about the languages that the user knows
• Math: the extension that displays math formulas in articles
• Thanks: the extension for sending “thank you” messages to other editors
• Universal Language Selector: the extension that lets people select the language they need from a long list of languages (disclaimer: I am one of its developers)
  • jquery.uls: an internal component of Universal Language Selector that has to be translated separately for technical reasons
• Wikibase Client: the part of Wikidata that appears on Wikipedia, mostly for handling interlanguage links
• VisualEditor: the extension that allows Wikipedia articles to be edited in a WYSIWYG style
• ProofreadPage: the extension that makes it easy to digitize PDF and DjVu files on Wikisource
• Wikibase Lib: additional messages for Wikidata
• Echo: the extension that shows notifications about messages and events (the red numbers at the top of Wikipedia)
• MobileFrontend: the extension that adapts MediaWiki to mobile phones
• WikiEditor: the toolbar for the classic wiki syntax editor
• ContentTranslation extension that helps translate articles between languages (disclaimer: I am one of its developers)
• Wikipedia Android mobile app
• Wikipedia iOS mobile app
• UploadWizard: the extension that helps people upload files to Wikimedia Commons comfortably
• Flow: the extension that is starting to make talk pages more comfortable to use
• Wikibase Repo: the extension that powers the Wikidata website
• Translate: the extension that powers translatewiki.net itself (disclaimer: I am one of its developers)
• MediaWiki core: the base MediaWiki software itself!

I put MediaWiki core last intentionally. It’s a very large message group, with over 3000 messages. It’s hard to get it completed quickly, and to be honest, some of its features are not seen very frequently by users who aren’t site administrators or very advanced editors. By all means, do complete it, try to do it as early as possible, and get your friends to help you, but it’s also OK if it takes some time.

Getting All Things Done

OK, so if you translate all the items above, you’ll make Wikipedia in your language mostly usable for most readers and editors.

But let’s go further.

Let’s go further not just for the sake of seeing pure 100% in the statistics everywhere. There’s more.

As I wrote above, the software changes every single day. So do the translatable messages. You need to get your language to 100% not just once; you need to keep doing it continuously.

Once you make the effort of getting to 100%, it will be much easier to keep it there. This means translating some things that are used rarely (but used nevertheless; otherwise they’d be removed). This means investing a few more days or weeks into translating-translating-translating.

You’ll be able to congratulate yourself not only upon the big accomplishment of getting everything to 100%, but also upon the accomplishments along the way.

One strategy to accomplish this is translating extension by extension. This means, going to your translatewiki.net language statistics: here’s an example with Albanian, but choose your own language. Click “expand” on MediaWiki, then again “expand” on “MediaWiki Extensions”, then on “Extensions used by Wikimedia” and finally, on “Extensions used by Wikimedia – Main”. Similarly to what I described above, find the smaller extensions first and translate them. Once you’re done with all the Main extensions, do all the extensions used by Wikimedia. (Going to all extensions, beyond Extensions used by Wikimedia, helps users of these extensions, but doesn’t help Wikipedia very much.) This strategy can work well if you have several people translating to your language, because it’s easy to divide work by topic.

Another strategy is quiet and friendly competition with other languages. Open the statistics for Extensions Used by Wikimedia – Main and sort the table by the “Completion” column. Find your language. Now translate as many messages as needed to pass the language above you in the list. Then translate as many messages as needed to pass the next language above you in the list. Repeat until you get to 100%.

For example, here’s an excerpt from the statistics for today:

Let’s say that you are translating to Malay. You only need to translate eight messages to go up a notch (901 – 894 + 1). Then six messages more to go up another notch (894 – 888). And so on.

Once you’re done, you will have translated over 3,400 messages, but it’s much easier to do it in small steps.

Once you get to 100% in the main extensions, do the same with all the Extensions Used by Wikimedia. It’s over 10,000 messages, but the same strategies work.

Good Stuff to Do Along the Way

Never assume that the English message is perfect. Never. Do what you can to improve the English messages.

Developers are people just like you are. They may know their code very well, but they may not be the most brilliant writers. And though some messages are written by professional user experience designers, many are written by the developers themselves. Developers are developers; they are not necessarily very good writers or designers, and the messages that they write in English may not be perfect. Keep in mind that many, many MediaWiki developers are not native English speakers; a lot of them are from Russia, Netherlands, India, Spain, Germany, Norway, China, France and many other countries, and English is foreign to them, and they may make mistakes.

So report problems with the English messages to the translatewiki Support page. (Use the opportunity to help other translators who are asking questions there, if you can.)

Another good thing is to do your best to try running the software that you are translating. If there are thousands of messages that are not translated to your language, then chances are that it’s already deployed in Wikipedia and you can try it. Actually trying to use it will help you translate it better.

Whenever relevant, fix the documentation displayed near the translation area. Strange as it may sound, it is possible that you understand the message better than the developer who wrote it!

Before translating a component, review the messages that were already translated. To do this, click the “All” tab at the top of the translation area. It’s useful for learning the current terminology, and you can also improve them and make them more consistent.

After you gain some experience, create a localization guide in your language. There are very few of them at the moment, and there should be more. Here’s the localization guide for French, for example. Create your own with the title “Localisation guidelines/xyz” where “xyz” is your language code.

As in Wikipedia, Be Bold.

OK, So I Got to 100%, What Now?

Well done and congratulations.

Now check the statistics for your language every day. I can’t emphasize how important it is to do this every day.

The way I do this is having a list of links on my translatewiki.net user page. I click them every day, and if there’s anything new to translate, I immediately translate it. Usually there is just a small number of new messages to translate; I didn’t measure precisely, but usually it’s less than 20. Quite often you won’t have to translate from scratch, but to update the translation of a message that changed in English, which is usually even faster.

But what if you suddenly see 200 new messages to translate? It happens occasionally. Maybe several times a year, when a major new feature is added or an existing feature is changed.

Basically, handle it the same way you got to 100% before: step by step, part by part, day by day, week by week, notch by notch, and get back to 100%.

But you can also try to anticipate it. Follow the discussions about new features, check out new extensions that appear before they are added to the Extensions Used by Wikimedia group, consider translating them when you have a few spare minutes. At the worst case, they will never be used by Wikimedia, but they may be used by somebody else who speaks your language, and your translations will definitely feed the translation memory database that helps you and other people translate more efficiently and easily.

Consider also translating other useful projects: OpenStreetMap, Etherpad, Blockly, Encyclopedia of Life, etc. Up to you. The same techniques apply everywhere.

What Do I Get for Doing All This Work?

The knowledge that thanks to you people who read in your language can use Wikipedia without having to learn English. Awesome, isn’t it? Some people call it “Good karma”.

Oh, and enormous experience with software localization, which is a rather useful job skill these days.

Is There Any Other Way in Which I Can Help?

Yes!

If you find this post useful, please translate it to other languages and publish it in your blog. No copyright restrictions, public domain (but it would be nice if you credit me and send me a link to your translation). Make any adaptations you need for your language. It took me years of experience to learn all of this, and it took me about four hours to write it. Translating it will take you much less than four hours, and it will help people be more efficient translators.

28/03/2017-03/04/2017

The OSM April fools of 2017

• The map editor is now also available in a variant for companies with optimized look and feel.
• weeklyOSM was first to report how OSMF managed to sell our OSM-Data to Google
• OSM uses WGS84 as a geodetic reference system, which is not coupled to the motion of the earth plates. In order to compensate for the differences between the most recent reference systems, such as the ETRS89 introduced/implemented in Europe, the coordinates in the OSM database are now being corrected. New versions are not created. This was reported on the official OSMF blog.

Mapping

• In an answer to a beginner’s question on the German forum, user Galbinus shows very succinctly, how to create a new roundabout using iD. User Polyglot shows how to get the job done using JOSM.
• A blog post by Marc Gemis on how to add data about immovable heritage structures in Belgium to crowdsourced projects such as OSM (HistOSM and Historic Places) and Wikidata.
• Multiple German mappers criticize (automatic translation) the app StreetComplete for creating too many changesets. The app aims to add missing tags, but creates one changeset for each changed tag (2 new tags on one object = 2 changesets). Their author is already in touch with the community. See also the bug report on GitHub.
• John Whelan asks how to deal with landuse=residential within landuse=residential areas that are probably an artefact of the often very rural but nevertheless flatly populated areas, for example in Africa and are reinforced by certain HOT tasks.
• Grant Slater’s experiments continue with highly accurate GPS measurements based on the OpenSource tool RTKLIB and he inquires if there are other mappers who experiment with Real-time Kinematic (RTK) or offer or need an RTCM stream (GPS correction signals).

Community

• This week saw the start of phase 2 of the School of Free Geomatics (EGL) in Senegal and Burkina Faso. An IRD project in partnership with the free geographers (LLG) and CHALA for the training of doctoral students in the free mapping around the OpenStreetMap ecosystem.
• On the OSM subreddit, people discuss how they use OSM (other than for navigation).

Imports

• Approximately 9.8 million building footprints are made available by Microsoft under ODbL licence. On the Talk-US mailing list, there was a discussion on whether this data could be imported into OSM.
• Christoph Hormann discovered a very questionable MapRoulette challenge for the location correction of islands in polar regions, which degrades data quality. In his user blog (numerous comments) he asks whether such challenges should be treated as mechanical edits.

Events

• The State of the Map Asia 2017 is looking for a logo.
• The SotM Working Group starts early to search for venues for the State of the Map 2018.

Humanitarian OSM

• A letter from Mocoa, Colombia: – Thank you for the collaboration, 48 hours later we have the first results on the map for the work of humanitarian teams on the ground. Now we need your help to sustain our humanitarian mapping unit (UMH) that raises post disaster data on the ground through donations.
• Benjamin Herfort from the University of Heidelberg has published an article in the GIScience News Blog titled “10 Million Contributions: It’s time for MapSwipe Analytics!”. He refers, among other things, to several activities:
  • MapSwipe Analytics website
  • MapSwipeTools
  • MapSwipe Data Repository

  and a scientific article
  “Towards evaluating the mobile crowdsourcing of geographic information about human settlements.” AGILE 2017 International Conference on Geographic Information Science. ” written by Herfort, B., Reinmuth, M., Porto de Albuquerque M.J. and Zipf, A.

• The OpenAerialMap project now has a much simpler way to upload new images.
• Russell Deffner alerts us of the second round of the mapping challenge to eradicate malaria.

Maps

• [1] Michael Schön showed an updated version of the Geopedia in a lightning talk at the FOSSGIS conference, which now also integrates Youtube and contains some new interesting features.
• Alexander Matheisen explains on the OpenRailwayMap mailing list, why he will remove the experimental support of vector tiles from openrailwaymap.org.

switch2OSM

• Mapbox writes about the new feature launched by Twitter that will enable businesses on it to privately share and request locations from their customers.

Software

• Osmconvert can now also perform simple tagging changes on OSM extracts. See the changed documentation for more information.
• Robin Boldt and Emux worked together to create a mobile app for Kurviger route planner. Users can test a public beta release for Android systems.

Programming

• David Valdmann writes in the Mapzen blog about the curved lettering, which were introduced with Tangram.js 0.12.

Releases

Provided by the OSM Software Watchlist. Timestamp: 2017-04-03 16:21:53+02 UTC

(*) unfree software. See: freesoftware.

Did you know …

• … the Luftlinienkarte (air line map) can calculate distances?

OSM in the media

• A Slate article tries to show why burgers have become so expensive in Paris, using many different maps and visualizations based on OSM and the list of French companies, recently published as open data.

Other “geo” things

• Google Map Maker is history since the end of March. TURN ON also reported about it and thinks about an alternative if one does not want to provide their information to Google.
• According to Heise online, the camera vehicles are on the road again in Europe.
• The flight simulator X-Plane-11 is now available. The terrain is based on a current OpenStreetMap.

Upcoming Events

Where	What	When	Country
Fribourg	SOSM Annual General Meeting and mapping party	08/04/2017
Popayán	#MappingPartyTulcan (Scout Mappers)	08/04/2017
Rennes	Atelier de découverte	09/04/2017
Rennes	Mapathon Missing Maps à Bréteil, Montfort	09/04/2017
Rennes	Réunion mensuelle	10/04/2017
Rome	Incontro Mappatori	10/04/2017
Lyon	Rencontre mensuelle libre	11/04/2017
Nantes	Rencontres mensuelles	11/04/2017
Munich	Münchner Stammtisch	11/04/2017
Taipei	OSM Taipei Meetup, MozSpace	11/04/2017
Essen	Stammtisch	13/04/2017
Paris	Paris Mapathon Missing Maps	13/04/2017
Manila	MapAm❤re #PhotoMapping San Juan, San Juan	13/04/2017-16/04/2017
Berlin	106. Berlin-Brandenburg Stammtisch	14/04/2017
Tokyo	東京！街歩き！マッピングパーティ：第７回 小石川後楽園	15/04/2017
Manila	FEU YouthMappers Mapillary Workshop, Manila	17/04/2017
Bonn	Bonner Stammtisch	18/04/2017
Scotland	Edinburgh	18/04/2017
Lüneburg	Mappertreffen Lüneburg	18/04/2017
Nottingham	Nottingham Pub Meetup	18/04/2017
Moscow	Schemotechnika 09	18/04/2017
Karlsruhe	Stammtisch	19/04/2017
Portland	Portland Mappy Hour	19/04/2017
Osaka	もくもくマッピング！ #05	19/04/2017
Leoben	Stammtisch Obersteiermark	20/04/2017
Zaragoza	Mapeado Colaborativo	21/04/2017
Kyoto	【西国街道#03】桜井駅跡と島本マッピングパーティ	22/04/2017
Misiones	Charla Mapas Libres en FLISoL, Posadas	22/04/2017
Bremen	Bremer Mappertreffen	24/04/2017
Graz	Stammtisch Graz	24/04/2017
Kinmen Shang Yi Airport	Do mapping Kinmen by youself	24/04/2017-25/04/2017
Avignon	State of the Map France 2017	02/06/2017-04/06/2017
Kampala	State of the Map Africa 2017	08/07/2017-10/07/2017
Champs-sur-Marne (Marne-la-Vallée)	FOSS4G Europe 2017 at ENSG Cité Descartes	18/07/2017-22/07/2017
Curitiba	FOSS4G+State of the Map Brasil 2017	27/07/2017-29/07/2017
Boston	FOSS4G 2017	14/08/2017-19/08/2017	USA
Aizu-wakamatsu Shi	State of the Map 2017	18/08/2017-20/08/2017
Boulder	State of the Map U.S. 2017	19/10/2017-22/10/2017
Buenos Aires	FOSS4G+State of the Map Argentina 2017	23/10/2017-28/10/2017
Lima	State of the Map LatAm 2017	29/11/2017-02/12/2017

Note: If you like to see your event here, please put it into the calendar. Only data which is there, will appear in weeklyOSM. Please check your event in our public calendar preview and correct it, where appropriate.

This weeklyOSM was produced by Nakaner, Peda, Polyglot, Rogehm, Spec80, SrrReal, YoViajo, derFred, jinalfoflia, keithonearth, wambacher.

Photo by Aubrie Johnson, public domain/CC0.

There is no end to examples of fake news cited by Wikipedia articles. The list of premature obituaries,for example, has grown considerably since the dawn of internet hoaxes thanks to how easily misinformation can promulgate.

Upworthy, KQED, Snopes, the Trust Project, and even the U.S. Department of Homeland Security all recently convened in Boston to answer one monumental question that’s been quietly looming over our heads: in a world bursting with free-flowing content, how do we stop the spread of misinformation?

In February, the Wikimedia Foundation joined a handful of media organization at the MIT Media Lab to lend their expertise at MisinfoCon, a summit and hack-a-thon dedicated to addressing the ever-growing problem of fake news online.

Propaganda, though often considered a bygone tool of marketing, is nothing new. Native advertising presents ads disguised as legitimate news articles. Clickbait disseminates through consumers trading false facts that appear to the naked eye to be true and verified. Seemingly innocuous memes go viral on social media, some containing falsehoods that churn furiously through news feeds. With more people getting their news from the internet than anywhere else, these are the problems most MisinfoCon attendees came to solve.

Media literacy organization First Draft demonstrated their new Google Chrome extension, NewsCheck, which lets viewers investigate an image or video’s authenticity together by completing a survey checklist and assessing the results. The Berkeley Institute for Data Science (BIDS) designed software to help anyone on the internet collaborate and fact check with others. During the summit, they referenced Wikipedia’s community of volunteer editors to better inform their workflow.

First Draft and BIDS already have credibility indicators in place, as do Wikipedia’s editors. While more educators, librarians, scientists, and engineers chipped away at their projects, a small cohort broke away to look at what makes content credible for online news as we know it.

All digital content contains some type of metadata—timestamps, file sizes, meta tags, etc. If we could attach metadata to any online content that would indicate its credibility, what would that include? We asked this and many other questions during the breakaway session, and came to several rough conclusions vaguely similar to Wikipedia’s guidelines for verifiability:

• Origin and motivation: Who provided the claim, and when?
• Byline: Who is taking credit for the claim’s research and writing?
• Sourcing: Is it possible to track down the writer’s sources? Are they clearly attributed?
• Cost of verification: Who does this article benefit financially?
• Tone and typology: Does the content intend to inform, or convince? Is it descriptive or prescriptive?

Prototyping the “metadata of news” is still in the works. Wikipedians have been refining indicators for credibility for sixteen years, laying solid groundwork for the rest of the web at large. Organizations like the News Literacy Project are training middle and high school students to utilize media literacy skills, giving them the tools to investigate dubious claims, and encouraging them to teach older generations.

Although nearly every project revolved around social media, representatives from the two biggest platforms in the game were noticeably absent: Facebook and Twitter. Despite this, many tools unveiled at MisinfoCon have be used across platforms and across nations. Some projects proposed ideas to cut off revenue and incentives to sites promoting fake news, instead rewarding organizations that prioritize newsroom diversity. Another, Hypothe.sis, essentially adds a “Talk page” layer to every accessible page, from academia to memes allowing critical analysis of all the web has to offer. Even the fake bits.

Aubrie Johnson, Social Media Associate (Contractor)
Wikimedia Foundation

ogv.js 1.4.0 is now released, with a .zip build or via npm. Will try to push it to Wikimedia next week or so.

Live demo available as always.

New A/V sync

Main improvement is much smoother performance on slower machines, mainly from changing the A/V sync method to prioritize audio smoothness, based on recommendations I’d received from video engineers at conferences that choppy audio is noticed by users much more strongly than choppy or out of sync video.

Previously, when ogv.js playback detected that video was getting behind audio, it would halt audio until the video caught up. This played all audio, and showed all frames, but could be very choppy if performance wasn’t good (such as in Internet Explorer 11 on an old PC!)

The new sync method instead keeps audio rock-solid, and allows video to get behind a little… if the video catches back up within a few frames, chances are the user won’t even notice. If it stays behind, we look ahead for the next keyframe… when the audio reaches that point, any remaining late frames are dropped. Suddenly we find ourselves back in sync, usually with not a single discontinuity in the audio track.

fastSeek()

The HTMLMediaElement API supports a fastSeek() method which is supposed to seek to the nearest keyframe before the request time, thus getting back to playback faster than a precise seek via setting the currentTime property.

Previously this was stubbed out with a slow precise seek; now it is actually fast. This enables a much better “scrubbing” experience given a suitable control widget, as can be seen in the demo by grabbing the progress thumb and moving it around the bar.

VP9 playback

WebM videos using the newer, more advanced VP9 codec can use a lot less bandwidth than VP8 or Theora videos, making it attractive for streaming uses. A VP9 decoder is now included for WebM, initially supporting profile 0 only (other profiles may or may not explode) — that means 8-bit, 4:2:0 subsampling.

Other subsampling formats will be supported in future, can probably eventually figure out something to do with 10-bit, but don’t expect those to perform well.

The VP9 decoder is moderately slower than the VP8 decoder for equivalent files.

Note that WebM is still slightly experimental; the next version of ogv.js will make further improvements and enable it by default.

WebAssembly

Firefox and Chrome have recently shipped support for code modules in the WebAssembly format, which provides a more efficient binary encoding for cross-compiled code than JavaScript. Experimental wasm versions are now included, but not yet used by default.

Multithreaded video decoding

Safari 10.1 has shipped support for the SharedArrayBuffer and Atomics APIs which allows for fully multithreaded code to be produced from the emscripten cross-compiler.

Experimental multithreaded versions of the VP8 and VP9 decoders are included, which can use up to 4 CPU cores to significantly increase speed on suitably encoded files (using the -slices option in ffmpeg for VP8, or -tile_columns for VP9). This works reasonably well in Safari and Chrome on Mac or Windows desktops; there are performance problems in Firefox due to deoptimization of the multithreaded code.

This actually works in iOS 10.3 as well — however Safari on iOS seems to aggressively limit how much code can be compiled in a single web page, and the multithreading means there’s more code and it’s copied across multiple threads, leading to often much worse behavior as the code can end up running without optimization.

Future versions of WebAssembly should bring multithreading there as well, and likely with better performance characteristics regarding code compilation.

Note that existing WebM transcodes on Wikimedia Commons do not include the suitable options for multithreading, but this will be enabled on future builds.

Misc fixes

Various bits. Check out the readme and stuff.

What’s next for ogv.js?

Plans for future include:

• replace the emscripten’d nestegg demuxer with Brian Parra’s jswebm
• fix the scaling of non-exact display dimensions on Windows w/ WebGL
• enable WebM by default
• use wasm by default when available
• clean up internal interfaces to…
• …create official plugin API for demuxers & decoders
• split the demo harness & control bar to separate packages
• split the decoder modules out to separate packages
• Media Source Extensions-alike API for DASH support…

Those’ll take some time to get all done and I’ve got plenty else on my plate, so it’ll probably come in several smaller versions over the next months.

I really want to get a plugin interface so people who want/need them and worry less about the licensing than me can make plugins for other codecs! And to make it easier to test Brian Parra’s jsvpx hand-ported VP8 decoder.

An MSE API will be the final ‘holy grail’ piece of the puzzle toward moving Wikimedia Commons’ video playback to adaptive streaming using WebM VP8  and/or VP9, with full native support in most browsers but still working with ogv.js in Safari, IE, and Edge.

Take the drop of knowledge that you want, how you want it, when you want it. Photo by José Manuel Suárez, CC BY 2.0.

The Wikimedia REST API (try it on the English Wikipedia) offers access to Wikimedia’s content and metadata in machine-readable formats. Focused on high-volume use cases, it tightly integrates with Wikimedia’s globally distributed caching infrastructure. As a result, API users benefit from reduced latencies and support for high request volumes. For readers, this means that content in apps and on the web loads more quickly. Editors have a more fluid and intuitive VisualEditor experience. Researchers and bot authors can work with Wikimedia content at volume, using formats that are widely supported.

The release of version 1 officially sees the REST API ready for stable production use. After two years of beta production, serving approximately 15 billion requests per month, we are now publicly committing to the stability guarantees set out in our versioning policy. Each entry point has a stability level ranging from experimental to stable. Experimental end points are subject to change without notice, while changes to unstable end points will be announced well in advance. Stable entry points are guaranteed to keep working for the lifetime of the v1 API as a whole. To allow for minor changes in the returned content formats without breaking clients, content types are versioned, and content negotiation using the HTTP Accept header is supported.

———

The API documentation and sandbox is auto-generated from a specification, and makes it easy to discover and try out API end points.

Case study: Structured article HTML

The REST API simplifies working with content using structured and standardized formats. For article content, the Parsing team developed an HTML and RDFa specification exposing a host of structured information inside a regular HTML page. This information makes it possible to easily and correctly process complex content using regular HTML tools.

The VisualEditor WYSIWYG editor (see below) takes advantage of this information to power editing of complex content like template transclusions, media, and extension tags such as citations. The edited HTML is then saved via Parsoid, using its unique ability to cleanly convert edited HTML back to Wikitext syntax. Easy access to the full content information combined with the ability to edit is a huge simplification for anyone interested in working with Wikipedia and other Wikimedia projects’ article contents.

The VisualEditor edit environment uses the REST API to fetch structured HTML, switch to wikitext edit mode, and finally save changed HTML without introducing spurious wikitext diffs that would make reviewing changes difficult.

The REST API endpoints used for this are:

• GET /page/html/{title}: Get the latest HTML for a title. Example: https://en.wikipedia.org/api/rest_v1/page/html/Tahiti
• GET /page/html/{title}/{revision}: Get the HTML for a specific revision of a title. Example: https://en.wikipedia.org/api/rest_v1/page/html/Tahiti/771800853
• POST /page/html/{title}: Save the modified HTML for a title. If you only want to convert HTML to wiki markup, you can use the lower level HTML to Wikitext transform end point.

Case study: Page summaries

The upcoming page preview feature shows a brief summary of linked articles on hover. It fetches the data powering this preview from the REST API page summary end point.

One frequent need is compact summary information about an article in a structured format. To this end, the REST API offers a page summary end point. This endpoint is used to show quick previews for related articles in the Wikipedia Android App. Using the same API, the Reading web team is currently rolling out a similar page preview feature to the desktop web experience.

Other functionality

The Wikipedia Android app has more than eight million users across the globe, and is almost entirely powered by the REST API. The main screen shows a feed of the most interesting and noteworthy articles powered by a set of feed endpoints. Mobile-optimized content is loaded through the mobile-sections endpoints. In an article, the user can get definitions for for words using the definition endpoint offering structured Wiktionary data.

Since 2011, mobile hardware has improved faster than networks.

Some cross-project information is available at the special wikimedia.org domain. This includes mathematical formulae rendered by Mathoid to SVG, MathML or PNG (also available in each project’s API), as well as historical page view statistics for all projects in the metrics hierarchy.

Technical background

Over the last years, mobile client hardware and platform capabilities have improved at a faster pace than network bandwidth and latency. To better serve our users, we have reduced network use and improved the user experience by gradually shifting more frontend logic to clients. Starting with our Android and iOS apps, content and data is retrieved directly from APIs, and formatted on the client. As we gradually apply the same approach to the web by taking advantage of new web platform features like ServiceWorkers, our APIs are set to serve most of our overall traffic.

Wikimedia’s globally distributed caching network, with radio towers indicating the locations of datacenters. Colors of small circles indicate which datacenter clients are mapped to via GeoDNS. The asia presence is planned, but not yet operational.

Large volume at low latency is the speciality of our globally distributed caching network. Over 96% of 120k-200k requests per second are served straight from caches, typically from a caching data center geographically close to the client. However, achieving such hit rates requires a clean and predictable URL structure. Our classic action API uses query strings and offers a lot of flexibility to users, but this flexibility also limits the effectiveness of caching. In contrast, the REST API was designed to integrate with the caching layers from the start. Today, over 95.5% of REST API requests are served directly from cache. This directly improves the user experience, shaving dozens to hundreds of milliseconds off of the response time by fully processing most requests in the geographically closest caching data center.

Caching works extremely well to speed up the delivery of popular resources, but does not help with less popular ones. Expensive resources can take dozens of seconds to re-generate from scratch, which ties up server-side resources, and is very noticeable to users. Furthermore, some use cases like visual editing also need guaranteed storage of matching metadata to complete an edit. After using only caching for a while, we soon realized that we needed more than caching; we actually needed storage with explicit control over resource lifetimes. This storage would ideally be available in both primary data centers at the same time (active-active), scale well to accommodate relatively large content types like HTML, and have low operational overheads. After some research and discussion we chose Cassandra as the storage backend, and implemented a fairly flexible REST table storage abstraction with an alternate backend using SQLite.

HyperSwitch: OpenAPI (Swagger) spec driven implementation

The OpenAPI specification (formerly Swagger) is widely used to clearly document APIs in a machine-readable manner. It is consumed by many tools, including the REST API documentation sandbox, our own API monitoring tool, and many of our API unit tests. Typically, such specs are maintained in parallel with the actual implementation, which risks inconsistencies and creates some duplicated effort. We wanted to avoid those issues, so we decided to drive the API implementation entirely with OpenAPI specs using the hyperswitch framework. This move has worked very well for us, and has allowed us to easily customize APIs for 743 projects driven by a single configuration file. A variety of modules and filters implement distributed rate limiting, systematic metric collection and logging, storage backends, content-type versioning, and access restrictions.

Next steps

The v1 release is just the beginning for the REST API. Over the next year, we expect traffic to grow significantly as high-volume features are rolled out, and public adoption grows. Functionality will expand to support high-volume use cases, and experimental endpoints will graduate towards first unstable and then eventually stable status as we gain confidence in each endpoint’s usability.

One focus area over the next year will be preparing a more scalable storage backend for efficient archiving of HTML, metadata and wiki markup. Eventually, we would like to reliably offer the full edit history of Wikimedia projects as structured data via stable URIs, ensuring that our history will remain available for all to use, enabling use cases such as article citations.

We look forward to learning about the many expected and unexpected uses of this API, and invite you to provide input into the next API iteration on this wiki talk page.

Gabriel Wicke, Principal Software Engineer, Wikimedia Services
Marko Obrovac, Senior Software Engineer (Contractor), Wikimedia Services
Eric Evans, Senior Software Engineer, Wikimedia Services
Petr Pchelko, Software Engineer, Wikimedia Services
Wikimedia Foundation

Like a submarine far below the surface sends intelligence to stations on land, a web of scholarly citations underlies and connects our world of knowledge. Photo by Lt. Ed Early/US Navy, public domain/CC0.

Citations are the backbone of scholarly knowledge. They help researchers verify information, build on the existing knowledge we already know, and generate opportunity for new discoveries.

Citations are not only relevant to academia. They are the foundation for how we know what we know.

Until recently, the idea of creating a freely accessible repository of open citation data—i.e. data representing how scholarly works cite each other—has been hampered by restrictive and inconsistent licenses and by the lack of machine-readable reference data.

Today, we are proud to announce a key milestone toward unlocking the potential for open citation data.

———

The Wikimedia Foundation, in collaboration with 29 publishers and a network of organizations, including the Public Library of Science (PLOS), the Internet Archive, Mozilla, the Bill & Melinda Gates Foundation, the Wellcome Trust, and many others, announced the Initiative for Open Citations (I4OC), which aims to make citation data freely available for anyone to access.

Scholarly publishers deposit the bibliographic record and raw metadata for their publications to Crossref. Thanks to a growing list of publishers participating in I4OC, reference metadata for nearly 15 million scholarly papers in Crossref’s database will become available to the public without copyright restriction.¹ This data includes bibliographic information (like the title of a paper, its author(s), and publication date), machine readable identifiers like DOIs (Digital Object Identifier, a common way to identify scholarly works), as well as data on how papers reference one another. It will help draw connections within scientific research, find and surface relevant information, and enrich knowledge in places like Wikipedia and Wikidata.

Unlike scholarly articles, citation data are not subject to copyright in the same way that articles themselves may be. Citation data typically rest in the public domain — free for anyone to access. Until recently, however, much of the citation data in the scientific research world has been difficult to find, surface, and access. “It is a scandal,” wrote David Shotton in Nature in 2013, “that reference lists from journal articles—core elements of scholarly communication that permit the attribution of credit and integrate our independent research endeavours—are not readily and freely available.”

Before the I4OC started, publishers releasing references in the open accounted for just 1% of the publications registered with Crossref.  As of the launch of the I4OC initiative, more than 40% of this data has become freely available.

As of March 2017, the fraction of publications with open references has grown from 1% to more than 40% out of the nearly 35 million articles with references deposited with Crossref (to date). Image by Dario Tarborelli, public domain/CC0.

Like sources cited within a Wikipedia article, references cited within a scholarly article can help build powerful discovery tools and a stronger foundation for open knowledge.

Volunteer contributors and software developers in the Wikimedia movement have been curating and incorporating scholarly citations into the Wikimedia projects for quite some time. The GeneWiki project has been linking reference sources to information about genes, proteins, and diseases in Wikipedia and Wikidata. Initiatives like WikiCite aim to create a bibliographic database in Wikidata to serve all Wikimedia projects. The LibraryBase project is building tools to better understand how information in Wikipedia is referenced and guide how editors identify and use references on Wikipedia. The WikiFactMine project is helping connect Wikidata statements in the field of biomedical sciences to scholarly literature.  Programmatic initiatives such as 1lib1ref are engaging librarians to add missing citations to Wikipedia, and services like Citoid are simplifying the discoverability and creation of citations for free knowledge.

These projects depend on the availability of open bibliographic and citation data. We expect I4OC will substantially contribute to all these initiatives.

Example of a partial citation graph for Laemmli (1970), one the most cited scholarly journal articles of all time. Graph generated from open citation data in Wikidata via a SPARQL query. Image by Dario Taraborelli, public domain/CC0.

Over the coming months, the organizations involved in I4OC will be working with different stakeholders to raise awareness of the availability of open citation data and evaluate how it can be reused, analyzed, and built upon. We  will provide regular updates on the growth of the public citations corpus, how the data is being used, additional stakeholders and participating publishers, and new services that are being developed.

Any publisher can freely license and share their reference data by enabling reference distribution via Crossref. For more information and details on how to get involved, please visit the I4OC website: https://i4oc.org or follow @i4oc_org on Twitter.

A joint press release about the announcement is available on the I4OC website.

Dario Taraborelli, Director, Head of Research, Wikimedia Foundation
Jonathan Dugan, WikiCite organizing committee

[1] As of March 2017, nearly 35 million articles with references have been registered with Crossref. Citation data from the Crossref REST API will be made available shortly after the announcement.

Founders

• OpenCitations
• Wikimedia Foundation
• PLOS
• eLife
• DataCite
• Centre for Culture and Technology, Curtin University

Participating publishers

• American Geophysical Union
• Association for Computing Machinery
• BMJ
• Co-Action Publishing
• Cambridge University Press
• Cold Spring Harbor Laboratory Press
• Copernicus GmbH
• eLife
• EMBO Press
• Faculty of 1000, Ltd.
• Frontiers Media SA
• Geological Society of London
• Hamad bin Khalifa University Press (HBKU Press)
• Hindawi
• International Union of Crystallography
• Leibniz Institute for Psychology Information
• MIT Press
• PeerJ
• Pensoft Publishers
• Portland Press
• Public Library of Science
• Royal Society of Chemistry
• SAGE Publishing
• Springer Nature
• Taylor & Francis Group
• The Rockefeller University Press
• The Royal Society
• Ubiquity Press, Ltd.
• Wiley

Stakeholders

• Alfred P. Sloan Foundation
• Altmetric
• Association of Research Libraries
• Authorea
• Bill & Melinda Gates Foundation
• California Digital Library
• Center for Open Science
• Coko Foundation
• Confederation of Open Access Repositories
• ContentMine
• Data Carpentry
• Dataverse
• dblp: computer science bibliography
• Department of Computer Science and Engineering, University of Bologna
• Dryad
• Figshare
• Hypothes.is
• ImpactStory
• Internet Archive
• Knowledge Lab
• Max Planck Digital Library
• Mozilla
• Open Knowledge International
• OpenAIRE
• Overleaf
• Project Jupyter
• rOpenSci
• Science Sandbox
• Wellcome Trust
• Wiki Education Foundation
• Wikimedia Deutschland
• Wikimedia UK
• Zotero

Glenn Dolphin is Tamaratt Teaching Professor in the Department of Geoscience at the University of Calgary. In this post he talks about assigning students to contribute to Wikipedia in his fall 2016 Introductory Geology course.

My name is Glenn. I was hired by the University of Calgary, in the Department of Geoscience, almost four years ago. My position is Tamaratt Teaching Professor in Geoscience. I have a Bachelor’s and Master’s degree in geology, but my PhD is in Science Education. I research learning in geology classrooms, and especially how to utilize the history of science to teach about science content and the process of science. The classes I teach are large enrollment (300-400 students) introductory classes. In response to the literature claims that lecture-only courses are not very effective at facilitating student learning, I decided to reconfigure my introductory geology course for non-science majors into a more active learning environment. I incorporated a number of strategies to achieve this, viz. breaking the entire class into small groups, using class time for small group writing exercises and discussions, a short Wikipedia project as well as a long-term Wikipedia project.

I completely restructured the traditional “rocks for jocks” course to highlight three storylines: The earth is a historical entity, that history is very, very long, and the earth is a dynamic system. In general, I presented content in a historically contextualized manner. In doing research for the course, it became quite obvious that though there was plenty of contributions by women to geology, the record of those contributions was sorely lacking.

During the course generation phase, I read a post concerning the Wikipedia “Year of Science”. I contacted the Wiki Education group and asked how I might incorporate Wikipedia into my class. I have found that when students are producing something for the “real world” as opposed to just the instructor for a grade, they work much harder to ensure quality. I spoke with Samantha about how to have students produce something that would be bigger than the course. Her confidence and energy convinced me that though the entire course was new, adding this particular project would not be onerous. It wasn’t.

I mapped out two different projects, one mandatory for all small groups in the course to contribute in a small way to the Wikipedia page of a “woman in geology”. The second was a long-term project with the same focus, but would incorporate a more substantial contribution. I was hesitant, at first, to incorporate these new projects, as I had no familiarity editing in Wikipedia, and I really did not want a lot of extra work and worry. This was also the biggest class that Wiki Ed would have had experience with (355 students). They were actually eager to see if they could support such an effort. I (virtually) met with Helaine and Ian who assured me that they would be my resource people in case I ran into difficulties. They did not disappoint.

They helped me build my Wikipedia course structure, which trainings to post, how to manage the timing of the projects and how to evaluate them. When it came time for the projects to run, I just directed the students to the Wikipedia course page and the rest was taken care of. During the running of the projects, Wiki Ed also instituted a mechanism making it possible to view each student’s contributions to the various Wiki pages. This was incredibly useful for evaluating the students’ work for each of the projects.

I received a lot of positive feedback on the assignments, because despite the few constraints, they were left pretty open. The course was mainly for non-science majors, so if they wanted to, students could focus on the science of the woman geologist, or some other aspect of the woman’s biography, related to the science (e.g. social or political forces, gender bias, etc.). One woman in the class, a communications major working in the media, took it upon herself to find one of the women in geology who was still living. She called her and interviewed her for the project. The student said it was a great experience to integrate her media training with a science course (of all things), and to create this new piece of knowledge for a much broader audience than one would normally expect from an introductory science course.

By the end of both projects we had edited over 80 different pages for women in geology and created almost 40 pages that didn’t exist before. Students were very excited about these aspects; first, that they were doing something that anyone in the world could see, and second, that they could actually create something that never existed before that was also available for the whole world to see. As of the writing of this blog post, those 83 articles have had close to 300 thousand views. When our science faculty got wind of the project, and its success, they ran a story about it in the University news.

Image: The Wikipedia project.jpg, by Susan Cannon, CC BY-SA 4.0, via Wikimedia Commons.

Image by Bowman Gum, public domain/CC0.

At the end of the long and tiring 1948 baseball season, the Cleveland Indians found themselves in a tie with the Boston Red Sox for first place. Both teams had the same win-loss record, and in 22 games against each other, each had won 11 games.

The stage was set for the first one-game playoff in the history of the American League (AL), one of baseball’s two top leagues. It would be a simple tiebreaker. One team would win the AL pennant, advance to the World Series, and play for the overall championship. The other would go home.

The Indians were a charter member of the AL in 1901, but had seen relatively little success in many of the years since. In 1948, they were fighting to win their first pennant and championship in nearly three decades.

To face the Red Sox, the team selected rookie pitcher Gene Bearden. Bearden had won 19 games that season, including two against the Sox, but one might assume that his arm would be tired after pitching a game just two days earlier. But he didn’t play like it. Bearden pitched the entire game, allowing 3 runs on 5 hits, while his teammates knocked home 8 on 13 hits.

The Indians went on from the tiebreaker to win the World Series. They have not won another one in the nearly seventy years since then.

———

Wikipedia editor, Cleveland native, and baseball fan Wizardman, who admits to being “spoiled” by the Indians’ success when he was growing up in the 1990s, is hoping that the Indians will win another title this season, which starts on April 3. They had a great chance as recently as last year, when they “heartbreakingly” fell exactly one win short to the Chicago Cubs.

In the meantime, Wizardman is focusing on the Indians’ 1948 season and its 45 related articles on Wikipedia, many with surprisingly fascinating storylines.

“Now that I’ve delved fairly deep into it, it has shocked me just how many stories make up each individual player,” Wizardman said. “Significant events certainly weren’t limited to just Bob Feller‘s wartime service or Larry Doby breaking the American League color barrier. You’ve got a guy who was later banned from the minor leagues, a guy who suffered a cerebral hemorrhage on the field, and one of the rare ballplayers who hit four homers in a game.”

And that’s not even getting into nicknames. Feller, the ace on Cleveland’s pitching staff, was known as “The Heater from Van Meter”, “Bullet Bob”, and “Rapid Robert.” Al Gettel went by “Two Gun.”  And Mike Garcia was affectionately called as “Big Bear,” giving a name to Wizardman’s ongoing mission to improve all of the articles related to the team in that year: Operation Big Bear.

The operation’s mascot is a literal bear (above) that Wizardman has named “Dwight,” a reference to The Office character and a conversation he once had. Photo by Simm, public domain/CC0.

Of all the articles he has or plans to write about the team, Wizardman says that Don Black is probably his favorite. It was the first article he worked on that related to the 1948 Indians, and the surprising details he found—a sobriety-fueled career turnaround, the cerebral hemorrhage—helped him decide to create Operation Big Bear. “Had I picked a boring ballplayer first,” he said, “who knows if I would have continued.”

Remaining interested and engaged with the content you’re writing about is important, because It can be difficult to write Wikipedia articles about this time period. The site’s content is built on the concept of verifiability, meaning that information added needs to be cited to reliable sources. “Readers must be able to check that any of the information within Wikipedia articles is not just made up,” the page says.

But many of the reliable sources from the 1940s are still copyrighted in the United States, so they are rarely available through free resources like Google Books, HaithiTrust, or the Internet Archive. That’s a major reason why, Wizardman notes, Wikipedia has a “recentist bend” that includes baseball, like the several Indians players from the 1990s with “good” articles written about them. For those in more recent times, there are more available reliable sources about their lives and career, many for free. For the opposite reason, “the same caliber of pre-Internet player is probably a stub [article],” he says.

Wizardman has found tricks to help him get around these difficulties. One major help has been access to the archives of Cleveland’s primary newspaper (the Plain Dealer) and Newspapers.com, the latter through the efforts of the Wikipedia Library. Another has been the lack of difficulty in writing what he calls “decent” baseball articles, as “the game is naturally very stat-based,” he says.

But on the other hand, “making the leap from relying on stats and telling the ballplayer’s story is much more difficult.” For example, Wizardman may have access to the Plain Dealer, but it is rare for a player to have stayed in Cleveland for his entire career. “Tackling other aspects,” he said, “such as being traded to another team where sources are harder to come by, … can be challenging.” With limitations like that, Wizardman has been forced to concede that at least 19 of his 45 planned articles will never be finished to the standards of Wikipedia’s highest “featured” quality level.

Wizardman has had help in Operation Big Bear from Zepppep, a editor who according to Wizardman “didn’t edit on Wikipedia long, but did do a few of the articles on the 1948 Indians, and helped to re-kickstart [Operation Big Bear] after I had moved on to other things.” Of special importance to Wizardman was Zepppep’s work on Bob Feller’s article, “the one player more than any I wanted to get to [featured status], both due to his significance and the shape of the article when I first read it 10 years or so ago (it was bad).”

You too can help Wizardman on his mission, lest it take until 2030 to finish. Head over to Operation Big Bear and start working on one of the red, orange, or yellow articles.

Ed Erhart, Editorial Associate
Wikimedia Foundation

• there is an API informing about authors and their books at Open Library based on the Open Library identifier.
• an app can now be build that shows this information
• this app could use identifiers of other "Sources" like Wikidata, VIAF or whatever on the assumption that Wikidata links these "Sources".
• this app could show information based on Wikidata statements in any language using Wikidata labels.
• this app may download the book (maybe not yet but certainly in the future)

• investigate the JSON and see what we already can do with it
• publish the results and iterate
• Add more identifiers of authors known to Open Library to Wikidata
• there are many OL identifiers in the Freebase information; they need to be extracted and a combined list of Wikidata identifiers and OL identifiers allows OL to curate it for redirects and we can then publish.
• Raffaele Messuti pointed to existing functionality that retrieves an author ID for Wikidata and VIAF using an ISBN number.
• Open Library knows about ISBN numbers for its books. When it runs the functionality for all the authors where it does not have a VIAF identifier it can enrich its database and share the information with Wikidata.
• Alternatively someone does this based on exposed information at Open Library.. :)
• We add a link to Open Library in the {{authority control}} in Wikipedia
• We could add information for nearby libraries like they do in Worldcat [1].
• We can measure how popular it is; how many people we refer to Open Library or to their library.

Hamble, the Humble Bundle mascot, enjoys a vintage reading experience through a monocle with a printout of Wikipedia. Photo by Whitney Stutes

There are about 5.4 million articles on the English-language Wikipedia. That can be impressive – and a little overwhelming. It’s empowering to know that at any time you can—for free!—peruse lists of songs, and delve into the list of songs about vehicle crashes, and then read about the song “30,000 Pounds of Bananas,” and the real incident it is based on, and wow that’s actually kind of tragic, and did you know bananas are actually berries, and you can make beer out of them? And… wait, it’s 3 a.m.?

Rabbit hole. Gets ya every time. That’s where inspiration struck Humble Bundle, the San Francisco-based company that lets gamers buy a bundle of games while helping their favorite charities. Humble Bundle has long been a supporter of the Wikimedia Foundation, the nonprofit that supports Wikipedia and its sister projects.

A few weeks ago, the folks at Humble Bundle wondered, what if – instead of endless rabbit holes – people could get a little divet of Wikipedia, or maybe a pothole of Wikipedia, or a small ditch of their very own they could fall into? What if people could pay for a download of Wikipedia in staggeringly massive DRM-free text files?

“On a laserdisc!” suggested our forward-thinking Executive Director Katherine Maher. “Or a VHS tape!” Or a papyrus scroll! Or a thing where the whole encyclopedia is spelled out with Stonehenge-like tablets!

It turns out some of that wasn’t feasible.

Print shop. Photo by Daniel Chodowiecki, public domain.

But you can—you really, truly can—buy yourself a chunk of Wikipedia via Humble Bundle. You can download it for use whenever you want to look something up. You can even buy a slender printed volume! (Printing is a way of reproducing text and images using a master form or template.)

Dog in top hat. Photo by Bonque & Kindermann photography, public domain.

Humble Bundle is producing handsome bound volumes on topics including “Encyclopedia of English Language Metaphors,” “Encyclopedia of Commonly Misspelled Words,” (see what they did there?), and “Encyclopedia of the Metal Umlaut.”

Think of the vintage experience of perusing a volume of Wikipedia through your monocle before a crackling fire. In the article on the use of the umlaut in the name of heavy metal bands you read the explanation from Spın̈al Tap’s rocker David St. Hubbins: “It’s like a pair of eyes. You’re looking at the umlaut, and it’s looking at you.” Satisfied, you lay the book upon a doily on your oaken desk and pour a glass of sherry.

From now through Monday, you can order the Wikipedia bundle from Humble currently being featured.

The Wikimedia Foundation and open-license applications

Happy April Fool’s Day! If you get volume A from Humble Bundle, you can read all about the origins of this day on your own Wikipedia. Otherwise, you can look it up with everybody else online.

This offer, however, is very real, as is our sincere appreciation for Humble Bundle. This is their great idea, and the kind of creative generosity that makes the company a real gift to gaming and the internet.

Downloading and printing Wikipedia are possible because of free and open licenses that allow for other fantastical applications. Want to see a 4.9′ wide and 43′ tall representation of the complete text and images of the Wikipedia article for Magna Carta? Check out Magna Carta (An Embroidery), a 2015 work by English installation artist Cornelia Parker. Our licenses enable “Histography,” an online visualization of world history on a sliding scale. Print Wikipedia is an art project by Michael Mandiberg. It was displayed at the at Denny Gallery in New York City, where 106 of the 7,473 volumes of English Wikipedia were printed, providing a small snapshot of what Wikipedia looked like on April 7, 2015. In addition to enabling these creative ventures, we believe free and open licenses—like the Creative Commons license utilized for Wikipedia’s content—are an important tool in making knowledge available to every human being.

About Humble Bundle

Humble Bundle sells digital content through its pay-what-you-want bundle promotions and the Humble Store. When purchasing a bundle, customers choose how much they want to pay and decide where their money goes – between the content creators, charity, and Humble Bundle. Since the company’s launch in 2010, Humble Bundle has raised more than $95 million through the support of its community for a wide range of charities, providing aid for people across the world. For more information, please visit www.humblebundle.com.

Jeff Elder, Digital Communications Manager
Wikimedia Foundation

This post was written by Dr Pedro Telles, Senior Lecturer in Law at Swansea University and originally published on his website.

For the last couple of years with my colleague Richard Leonard-Davies I have been teaching competition law here at Swansea University and doing so in a very traditional and straightforward way: lectures focused on plenty of case law and seminars where we drilled down the details. As competition law is one of those topics that can be eminently practical, there was plenty of scope for improvement. As we run two separate Competition Law modules in different semesters (Agreements in the first, Dominance in the second) it is possible to make changes in only a part of the year.

About a year ago I found this blogpost by Chris Blattman on getting students to draft a Wikipedia article as part of their assessment. Blattman called this the creation of a public good while my preferred description is getting them to pay forward for the next lot. Immediately I thought, “hmmm let’s see the entries for competition law” and they were very underwhelming.

Fast forward a year, a few hoops and plenty of support from Wikimedia UK and we’re now in the position of starting the module with a new assessment structure that includes the (re)-drafting of a Wikipedia entry. Here’s the nitty gritty:

Assessment 1 (2,000 words)

For the first coursework you will have to choose from the topics covered this semester and check if it has a Wikipedia entry or not. Once you have selected a topic you will need to submit it for approval to either member of the teaching team. If an entry already exists you will critically analyse the entry by providing a report which encompasses the following:

–       Why you have chosen this topic

–       What is covered in the Wikipedia entry

–       What the entry does well

–       How the entry could be improved in your view (ie, caselaw, different perspectives, more recent doctrinal developments, context)

–       What aspects of the topic were not covered but should have been included

–       What sources (academic/case-law) you would use to reference the entry

We expect the piece to be factual on its description of the area of the law you decided to analyse but at the same time critical and reflective, basing yourself in good quality academic sources for the arguments you are presenting.

Assessment 2 (1,000 words)

For Coursework 2 you will be expected to put in action the comments and analysis from Coursework 1, ie you will be drafting an actual Wikipedia entry that improves on the strong points identified and addresses the weaknesses as well. This entry will be drafted on your Wikipedia dashboard (to be discussed in the Coursework Workshop in March) and will have to be submitted both on Turnitin and also uploaded to Wikipedia itself before the deadline.

Regular plagiarism rules apply, so if you pick an entry that already exists you are advised to re-write it extensively, which, to implement the changes from Coursework 1 you should be doing nonetheless. It is fundamental that you make the Turnitin submission prior to the Wikipedia one

The drafting style for this entry will be very different from the first one (or any academic coursework for that matter) as you are no longer critiquing a pre-existing text, but creating an alternative one. As such, it is expected to be descriptive and thorough, providing a lay reader with an understanding of the topic at hand. For an idea, please check Wikipedia’s Manual of Style: https://en.wikipedia.org/wiki/Wikipedia:Writing_better_articles

What we are hoping for with this experiment is to get students out of their comfort zone and used to think and write differently from the usual academic work. Instead of padding and adding superfluous materials, they will be expected (and marked) to a different standard.

But that is not the only thing we’re changing as the seminars will also be quite different from the past. This year we will use WhatsApp as a competition law case study.

Why WhatsApp?

Well, when considering what company/product to use as a case study there had been no investigations into WhatsApp so that made it a clear frontrunner as a potential case study. It’s a digital product/service which may or may not be tripping EU Competition Law rules with enough of a grey area to get people to think. So we will apply the law to WhatsApp and try to figure out if:

– It has a dominant position (and if so, in what market)

– It has abused its putative dominant position

– Its merger with Facebook is above board

– it’s IP policy/third-app access policy is compliant with competition law requirements

To this end, students will have to find information by themselves (incredible the amount of statistics freely available these days online…) and be prepared to work together in the seminar to prepare the skeleton arguments in favour/against any of those possibilities. The second half of the seminar will be spent with the teams arguing their position.

We’ll see how it goes and will comment on the whole experiment in four months or so. In the meanwhile, if you want to know more drop me a line in the comments.

21/03/2017-27/03/2017

Mapping

• At the FOSSGIS conference, data privacy on OSM was discussed. Frederik Ramm summarizes (automatic translation) some relevant aspects in the German forum. There was also a brief discussion on Talk-de mailing list. Personally identifiable data, such as mapping activities, is still visible to anyone.
• Voting window for the new tag amenity=courier is open until April 7th.
• Martijn van Exel is working on a monthly newsletter for MapRoulette. Take a look at the March edition.
• Following Harry Wood’s idea to upload OSM notes in MAPS.ME, Noémie Lehuby generated a file to spot bus stops with missing names around Paris.
• Telenav’s mapping team members disappoints the Canadian community by armchair mapping of turn restrictions.
• Areas tagged landuse=farm won’t be rendered (automatic translation) any longer in our standard map style. In re-tagging these legacies, the NoFarm map might be a great help.
• Martin Koppenhoefer explained where the center of Berlin is defined, after having recently looked at the history of the city center of Rome.

Community

• Harald Hartmann asks in the German forum, whether there should be more “gamification” at OSM, for example in the form of virtual awards and rewards. (automatic translation)
• [1] Carlos F. Castillo aka kaxtillo runs a scout group called ScoutMappers in Popayán, Colombia. The scouts should be enabled to know and apply useful tools in emergency cases and to share data with rescue workers. The group from Popayán will publish their experiences from the past six years on REME to share their knowledge with all the scouts around the world so that every scout can do a good deed every day.
• According to Spanish OSM, there are many mazes mapped in OpenStreetMap.

OpenStreetMap Foundation

• In Belgium, there is currently an OSM local chapter in formation. The charter is still being elaborated.

Events

• The organizers of the 2018 FOSS4G Conference in Dar es Salaam, Tanzania, are looking for a logo and have launched a competition.
• This year’s international State of the Map conference will take place in Aizu-Wakamatsu, Japan. This is a gentle reminder to send in your proposals for talks and/or workshops if you have not already done so. The deadline to submit your session proposal is Sunday, 2nd April.
• Vincent de Château-Thierry asks (automatic translation) for submissions to SotM France on the talk-fr mailing list. It takes place in June from 2nd to 4th at Avignon.

Humanitarian OSM

• HOT is currently redeveloping the “Export Tool“ and hosted a community text chat on their Slack #export-tool channel on March 30th at 15:00 UTC.
• Kate Chapman explained the importance of OpenSource software and the need for developers for humanitarian purposes.
• Joost Schouppe is looking for validators after the successful Belgian National Mapathon. The more than 300 participants completed the last few gaps in the map of Sierra Leone, which had been mapped in several previous HOT projects. A novelty as MapSwipe was used beforehand to find those spots, so mappers could concentrate on them. They also made a dent in the monster project #1396 in Nigeria, which has been ongoing for more than a year now. Also several tasks to help MSF fight malaria.
• The flood disaster in Peru is still ongoing. (We reported last week). The tasks that need your help – mapping or validation:
  • #2719 – Chosica, Peru: Flood Prone Communities Mapathon 2017
  • #2677 – Peru Flood Support 2: Cayma
  • #2679 – Peru Flood Support 4: Huarmey
  • #2709 – Peru Flood Support 5: Cajamarquilla
• Russell Deffner has published a first task in the OSM Tasking Manager to support the elimination of malaria in Zimbabwe.

switch2OSM

• Local authorities from Digne, France, proudly announced that their new printed tourist map is based on OSM data. The design process will be presented at the SotM France in June in Avignon. (automatic translation)

Software

• The OpenStreetMap location monitoring app OsMo is now using MapZen vector tiles.
• OsmAnd+ offers a 50% discount for the app.

Programming

• Lukas Martinelli, one of the two guys behind OSM2Vectortiles is now a part of Mapbox.

Releases

Provided by the OSM Software Watchlist. Timestamp: 2017-03-27 18:15:39+02 UTC

(*) unfree software. See: freesoftware.

Other “geo” things

• Web developer and artist Hans Hack created a map of London and Berlin with collapsed buildings to compare it to the situation in Aleppo.
• At the National Library of Scotland in Edinburgh, researchers have pieced together a 17th-century Dutch map that has spent part of its life up a chimney, and part under the floorboards at a Scottish castle.
• London scientists found (automatic translation) that using navigation aids has a deep effect on brain’s activity.

Upcoming Events

Where	What	When	Country
Mazzano Romano	Workshop 2	31/03/2017
Kyoto	【西国街道#02】山崎蒸溜所と桜マッピングパーティ	01/04/2017
Rome	Walk4Art	01/04/2017
Rostock	Rostocker Treffen	04/04/2017
Stuttgart	Stuttgarter Stammtisch	05/04/2017
Helsinki	Monthly Missing Maps mapathon at Finnish Red Cross HQ	06/04/2017
Dresden	Stammtisch	06/04/2017
Zaragoza	Mapeado Colaborativo	07/04/2017
Mazzano Romano	Workshop 3	07/04/2017
Fribourg	SOSM Annual General Meeting and mapping party	08/04/2017
Popayán	#MappingPartyTulcan (Scout Mappers)	08/04/2017
Rennes	Atelier de découverte	09/04/2017
Rennes	Réunion mensuelle	10/04/2017
Lyon	Rencontre mensuelle libre	11/04/2017
Nantes	Rencontres mensuelles	11/04/2017
Munich	Münchner Stammtisch	11/04/2017
Essen	Stammtisch	13/04/2017
Manila	MapAm❤re #PhotoMapping San Juan, San Juan	13/04/2017-16/04/2017
Berlin	106. Berlin-Brandenburg Stammtisch	14/04/2017
Tokyo	東京！街歩き！マッピングパーティ：第７回 小石川後楽園	15/04/2017
Avignon	State of the Map France 2017	02/06/2017-04/06/2017
Kampala	State of the Map Africa 2017	08/07/2017-10/07/2017
Curitiba	FOSS4G+SOTM Brasil 2017	27/07/2017-29/07/2017
Aizu-wakamatsu Shi	State of the Map 2017	18/08/2017-20/08/2017
Boulder	State Of The Map U.S. 2017	19/10/2017-22/10/2017
Buenos Aires	FOSS4G+SOTM Argentina 2017	23/10/2017-28/10/2017
Lima	State of the Map – LatAm 2017	29/11/2017-02/12/2017

Note: If you like to see your event here, please put it into the calendar. Only data which is there, will appear in weeklyOSM. Please check your event in our public calendar preview and correct it, where appropriate.

This weeklyOSM was produced by Hakuch, Nakaner, Peda, Polyglot, Rogehm, Spec80, SrrReal, YoViajo, derFred, jcoupey, jinalfoflia, kreuzschnabel, vsandre.

Our Wikipedia Content Experts are experienced Wikipedians who play a vital role in the Classroom Program, providing support to students as they contribute to Wikipedia for the first time. I’m pleased to announce that Shalor Toncray has joined Wiki Ed on a short-term contract to provide extra support to students as Content Expert in the spring 2017 term.

Shalor is a long-time Wikipedian who has edited as User:Tokyogirl79 since 2006, and became an administrator in 2013. Her experience with Wikipedia led her to an interest in digital archiving, working with the Library of Virginia, and also to earn a Master of Library and Information Science from Drexel University. A recent profile on the Wikimedia Blog highlighted the work she’s done the improve Wikipedia’s coverage of important but overlooked historical figures.

Before diving into archiving and library science, Shalor attended Virginia Commonwealth University, where she received a bachelor’s degree in religious studies. When she’s not working, Shalor likes to read, watch movies, play video games (especially tactical RPGs), and, of course, edit Wikipedia.

Photo by Subhashish Panigrahi, CC BY-SA 4.0.

Odia Wikisource turned two in October 2016. Started in 2014, the project has over 500 volumes of text including more than 200 books from different genres and publication eras. There are about 5-10 active contributors to this project who are geographically dispersed. To celebrate the anniversary, the Odia Wikisource community is starting a batch of activities to help grow it.

On January 29, a day-long event was organized in the Indian city of Bhubaneswar, the capital of the state of Odisha, where a majority of Odia-language speakers live. The event aimed to provide training for those who wanted to learn more about Wikisource, assess the work done so far, and develop strategies for the future.

Forty Wikimedians from different backgrounds participated in this event, including six active contributors on the project: Pankajmala Sarangi, Subas Chandra Rout, Radha Dwibedi, Sangram Keshari Senapati, Prateek Pattanaik, Chinmayee Mishra, and Aliva Sahoo along with Mrutyunjaya Kar, the project administrator.

The event marked the beginning of several new community-led projects: Pothi, a project to digitize old and rare public domain Odia books; an initiative at the Utkal University library to digitize public domain books; another project that aims at digitizing palm leaf manuscripts that are hundreds of years old at a temple in Bargarh; in addition to an open-source project to record pronunciation of words for Wiktionary.

Several small workshops were organized to cover topics like low-cost setup for large-scale digitization of books, communications management for small or large events, uploading scanned works on Commons, dealing with OTRS-related issues, OCRing scanned pages, using images on Wikisource, general guidelines for proofreading, and tips for promoting digitized works on social media and other platforms.

“Books like Odishara Itihasa, Ama Debadebi, Manabasa Laxmipurana, and Sabitri Osa haven’t been available on the internet,” says Wikisourcer Sangram Keshari Senapati, “even though many search for them. That makes me proud to contribute to their digitization.

Pothi: a project to collect, archive and digitize old rare Odia books

“Odia Wikisource is run by Wikimedia volunteers,” explains Mrutyunjaya Kar, an administrator of the project. “This project is a storehouse of out-of-copyright books. In addition old books, we try to reach out to well-known authors and publishers with the aim of including some of their books in this free library. This way, the new generation won’t become oblivious to the invaluable pieces of Odia literature available in this digital age.” Prateek Pattanaik, a 12th-grade student in Delhi Public School Damanjodi, has started a project called “Pothi” to collect out-of-copyright and rare books and make them available in digital form on Wikisource. Many scholars and researchers joined the program.

Palm leaf manuscripts

Shree Dadhibaman Temple, a 400-year-old temple in Bargarh, a city in the Indian state of Odisha, has an archive of over 250 ancient Odia manuscripts that date back to the sixteenth century. These palm leaf manuscripts include Mahabharata, Ramayana, Skanda Purana, and the history of the temple, all in Odia.

Many of the manuscripts from the collection are at risk of erosion. The temple administration and trust have preserved the manuscripts with available preservation techniques. The preservation started a couple of years back when the student volunteers of different colleges of Bhatli, a nearby town, helped the temple administration identify manuscripts in dire need of preservation.

The Odia Wikimedia community is planning to collaborate with the temple administration to organize a three-day-long digitization camp for the students of two colleges in Bhatli. Participating students will be informed about Wikisource and the digitization process and some of the temple manuscripts will be digitized during this camp. After scanning the manuscripts, the Odia Wikimedia community will help the students upload, digitize and proofread the manuscripts on Odia Wikisource.

Digitizing books in the Utkal University library

Utkal University is one of the oldest universities in Odisha and the 17th oldest university in India. The central library of Utkal University, named after its first Vice Chancellor, Professor Prana Krushna Parija, hosts many old rare books and manuscripts. The library was set up in 1946 in Cuttack, and was then transferred to the Utkal University campus in Bhubaneswar in 1962. Odia Wikimedians are working closely with the university to set up a structure where the Wikimedians in Bhubaneswar (WikiTungi participants) will be involved in the scanning process. This collaboration with the university will enable the Wikimedians to use the public domain books for Wikisource where the university will host the e-books on their website.

Kathabhidhana

Kathabhidhana is a community-led project to record the pronunciation of words and upload them under open licenses to be used on projects like Wiktionary. The project is led by Odia Wikimedian Subhashish Panigrahi, drawing its inspiration largely from open-source software created by Wikimedian Shrinivasan T. The source code of the software used for Kathabhidhana is written in Python and over 1,200 audio recordings have been conducted so far using the tool.

Odia Wikimedian Prateek Pattanaik is developing workflow software using a proprietary iOS-based app that can record about 5 words per minute using an iPad or iPhone to facilitate contribution to the project. More than 1,000 recordings have been added to Odia Wiktionary so far. Odia Wiktionary, which usually lacks notable contributions, has undergone some great activity by Shitikantha Dash, a sysop of the project. The project hosts over 100,000 words, mostly from Bhashakosha, a public domain lexicon digitized by nonprofit Srujanika.

Subhashish Panigrahi
Bikash Ojha
Prateek Pattanaik
Sailesh Patnaik
Chinmayee Mishra
Odia Wikimedians

In brief

Deadline for Wikimania submissions extended: Submissions for Wikimania, the annual conference of the Wikimania movement which will be held this year in Montreal, Canada, has been extended. Proposals for presentations, (lectures, workshops, roundtables and tutorials) will be accepted until 10 April, 2017 while the proposals for lightning talks, posters and birds of a feather will be accepted until May 15, 2017. More information and submitting applications on Wikimania 2017 wiki.

Wikimedia Tunisia holds their first annual meetup: Wikimedia Tunisia user group has held a meetup for the user group members. Participants were informed about event planning, grantmaking, Wikimedia affiliations, and the next strategy for the user group. More information about the meetup can be found on Meta, and photos from the event can be found on Commons.

Fourth edition of WikiMed courses wraps up at Tel Aviv University: The Wikipedia Education Program course that started in 2013 at Tel Aviv University, has celebrated its fourth edition last January. The course has presented over 200 new articles to the Hebrew Wikipedia so far. Shani Evenstein, the Wikipedia Education Program leader in Israel wrote a post on This Month In Education newsletter about the organizer motivations and the program objectives.

Wikimedia Germany publishes 2016 impact report: Wikimedia Germany (Deutschland), the independent chapter supporting the Wikimedia movement in Germany has published their impact report for 2016. The report drops shade on the learnings and experiences from the last year with special coverage to the projects supported by the chapter. More information on Wikimedia-l.

New filters for edit review beta filter release: This week, the New filters for edit review beta option will be released on the Portuguese and Polish Wikipedias, and also on Mediawiki. The beta option adds an improved filtering interface and powerful filtering and other tools to the “recent changes” and “recent changes linked” pages. More information on Wikimedia-l.

Amical Wikimedia share their partner survey results: Amical Wikimedia, the independent thematic organization that supports Wikimedia in the Catalan-speaking region, has shared the results of a survey they conducted on over 100 of their partners to see what they think of their work with the Wikimedia movement. The survey result report is available on the Amical Wikimedia website.

Compiled and edited by Samir Elsharbaty, Digital Content Intern
Wikimedia Foundation

This post has been edited to correct the reach of WikiProject Pothi.

I really like Magnus Manske’s WikiShootMe tool. It visualises Wikidata items, Commons photos and Wikipedia articles on an OpenStreetMap. Wikidata items are shown as red if they have no photo and green if they do have one. For the past few months, I’ve been spending my lunch hours walking around the area near the Wikimedia UK offices, trying to turn red data points into green ones.

The biggest concentration of data items near our office was in Bunhill Fields, a famous cemetery just outside the old city walls of London. It opened in the 17th century, and had over 100,000 people buried there before it closed in the middle of the 19th century. Because of its location, it became a home for many nonconformist Christians, especially Methodists, as it is just over the road from the the Methodist Chapel of John Wesley. Daniel Defoe, William Blake and John Bunyan are buried there, along with Wesley’s mother Susanna.

Bunhill fields is a beautiful place to walk through, and now, thanks to the linked data I’ve attached to the Wikidata items for the listed graves in the cemetery, you can view images of all of the graves to identify which one is which as you walk around the site. I’ve also created a hyperlapse video showing a walk around the cemetery which is CC licensed.

Most of the gravesites are enclosed, but I could take photos of many of the graves from the paths, and on some days, groups of volunteer gardeners manage the enclosures, and are happy to let you enter to take photos. The park attendant was also very helpful, and let me look at his book showing the locations of graves whose inscriptions had become illegible, which helped to identify many of them.

Eventually, I ticked all the graves off the list, and I have to say that it was quite fun and satisfying. I’ve always felt that there is an underlying element of gamification within the Wikimedia projects. People take pride in having lots of edits or uploads, completing tasks and being the person who started particular articles. If these elements could be made more satisfying within the overall user experience of editing Wikimedia projects, it could encourage many more editors to participate.

In May, there are two hackathons taking place for developers working on Wikimedia projects in Prague and Vienna, and there will be a particular focus on the Wikimedia Commons Uploader, an android app that will make uploading easier. Currently, the web browser is a pain to use, and you can only upload 50 photos at a time. With millions of people in the developing world becoming connected to the internet through their mobiles, we need to improve the user experience for the projects, especially on mobile phones.

Imagine a Pokemon style application which took you on a walking tour of you nearby location, pointing out historical heritage and showing you the geolocated data that exists and encouraging you to fill in the gaps, taking photos or adding descriptions or other fields. Rewarding the editors with points for valuable edits and uploads could make the whole experience much more enjoyable and encourage people to edit who would never normally consider it.

We have a long way to go in developing our open source community, but there are exciting possibilities ahead as our movement evolves to meet new challenges and fix old problems.

____________________________________________________________________________

If you’re interested to get involved and learn more about Wikidata and how it works, you can sign up here to attend our Wikidata hackathon on Saturday April 8 at the Wikimedia UK offices near Old Street.

The new adventure I was mentioning few days ago is the Design Research Lab, a joint initiative of University of Trento, Confindustria, Art Institute Artigianelli and Bruno Kessler Foundation.

We are currently recruiting and now there are 3 open positions as research fellow in the Design Research Lab. The duration of the contract is for 12 months. The gross amount is 19.668 euros.
All the details are in the call.
The broad goals of the Design Research Lab (and the tasks of the research fellows) are to effectively promote in public and private organizations the culture of services and their design as levers of product creation and central factors of local development.

The deadline for applying is 12 April 2017 (hurry up!)
Feel free to ask me any question. We might end up working together ;)

Photo by Zachary McCune, CC BY-SA 4.0.

For nearly 16 years, Wikipedians have been presenting the facts. Now, we are proud to release our ninth annual report, which focuses on that important work.

As a way into our communities and our work, we offer 10 facts. They are introductions to stories about Wikimedians who document climate change, increase the number of women’s biographies, offer language and learning to refugees, or add new languages to Wikipedia.

We care about facts. Contributors work hard to systematically source and review them. Readers return to our projects to find and share them. Donors stand up to support and expand access to them. At the Wikimedia Foundation, it’s our job to backup the people who backup the facts.

Fact: Wikipedia is updated nearly 350 times a minute.

Those updates are offered by thousands of volunteers writing in over 280 languages. This year, 70,000 volunteers added 5 million articles to Wikipedia, and more than 1 billion devices visited our sites—every month—to read them. We measure our impact based on the communities of knowledge we support, and the ways the world uses Wikimedia’s free knowledge projects to learn.

Fact: Most Wikipedia articles are in a language other than English.

Indeed, we have encyclopedias active in 23 languages in India alone. The vitality of these communities is supported by volunteers, Foundation staff, developers, donors, and advocates for free knowledge everywhere. An estimated 239 million people used the internet for the first time in 2016, and we intend to meet their needs by asking how they learn and what they need.

There is always more to do. Just 17% of English Wikipedia biographies are about women. We think that number should be much higher. So we are supporting and celebrating Wikimedians who want to change the ratio.

Fact: Half of refugees are school-aged.

That means more than 10 million would-be students are away from their homes, families, and places of learning. We believe that learning is a lifelong pursuit, so we look for ways to bring our free knowledge across boundaries. This year, German Wikimedians collaborated to translate phrasebooks for refugees so that newcomers to European countries could ask for the help they need.

About the theme

We chose the theme “facts matter” in early October 2016 as a way to remind the world how Wikipedia works and why our movement matters. By that time, the state of fact-based information had become a highly-discussed topic internationally. We received questions from the media about how and why Wikipedia was able to avoid the fake news phenomenon, while many other companies had become amplifiers. We heard from donors about the importance of Wikipedia in a world where verifiable information is not promised. We saw, as always, an unwavering commitment from volunteer community members to presenting and verifying the facts.

When we launched the site, we received feedback from many voices in our community. There were thoughts and concerns, change requests and ideas to improve the report. It was a complex and detailed conversation and we updated the report in places to reflect this feedback

Facts are vital. Facts help us understand our world. Our contributors take pride in systematically sourcing and evaluating facts so that the world of knowledge grows, and curious readers can find original sources.

We are proud to support them.

Zack McCune, Global Audience Manager
Heather Walls, Interim Chief of Communications
Wikimedia Foundation

Environmental history is one of the most rapidly growing academic fields. The number of history departments employing an environmental historian has grown from just 4.3% in 1975 to 45% in 2015. The field focuses on the ways humans have shaped and have been shaped by their environment. With recent events like those in Standing Rock and Flint, and the trend among local government planners to replace “climate change” with “resilience” in policy documents, this relationship between humans and our environment is as important as ever to study and understand.

But it’s not just important for academics to study and understand these issues. It’s also imperative that the general public become aware and informed as well. That’s why Wiki Ed is so excited to be attending this year’s American Society of Environmental History conference. The theme for this year, “Winds of Change: Global Connections across Space, Time, and Nature”, emphasizes points that Wikipedians, and we here at Wiki Ed, know well: that knowledge and understanding can change and transform, and that when it does, it’s important to adapt and to click that “edit” button.

During the conference I’ll be in the exhibit hall talking to interested university instructors about the many opportunities that a Wikipedia assignment can bring to their classrooms. From research engagement to critical thinking, to science communication and other skills, we think that what students learn while working to improve Wikipedia is crucial to their ability to become informed citizens. If you’re in Chicago next week attending the ASEH conference, I hope you’ll come by the booth. And if you or any other instructors you know are interested in learning more about Wikipedia assignments, visit teach.wikiedu.org or reach out at samantha@wikiedu.org – I’d love to chat!

Exhibit Hall Hours

• Wednesday, March 29: 6:00 pm – 8:00 pm (Opening Reception)
• Thursday, March 30: 8:00 am – 5:00 pm
• Friday, March 31: 8:00 am – 12:00 noon
• Saturday, April 1: 8:00 am – 2:00 pm

Photo by Elsie Wright, public domain in the United States.

One hundred years ago, two young cousins took a camera down to a stream in northern England and came back with a controversy that lingered almost magically in the air for decades. Five photographs taken by the girls appeared to show them engaging with fairies, the mythical small, graceful female creatures with wings.

This might seem like a prank that—no matter how well-executed—would be only briefly considered before being decisively and permanently dismissed. Not in this case. Sir Arthur Conan Doyle, one of the most popular authors of his (or any other) time due to his detective Sherlock Holmes, wrote about the fairies: “The recognition of their existence will jolt the material twentieth century mind out of its heavy ruts in the mud, and will make it admit that there is a glamour and mystery to life.”  Experts examined the photos and toured the site. (One clairvoyant who visited the scene “saw them [fairies] everywhere”.) The world, it seemed, wanted to know more.

Photo by Elsie Wright, public domain in the United States.

Media including the British Broadcasting Corp. interviewed the photographer cousins, Elsie Wright and Frances Griffiths, in the 1960s, ‘70s, and ‘80s. Eighty years after the girls’ photo shoot, two movies were made about the events, and they were not cheap productions: one featured Harvey Keitel and Peter O’Toole, and another Ben Kingsley.

Why did the Cottingley Fairies photos—which were actually of cardboard cutouts—impress so mightily? The relatively recent novelty of photography fueled curiosity, according to the Wikipedia article about the photos. Doyle consulted experts at Kodak, which helped to popularize photography when it introduced the Brownie box camera in 1900. The photos were enhanced and transported around the United Kingdom by their admirers on lecture tours. “Spirit photography” was becoming a fad, and Doyle posed for a double-exposure photo with a supposed ghost in 1922. (Doyle’s friend and later foe, Harry Houdini, mocked the fad and created a photo of himself with the supposed ghost of Abraham Lincoln as part of his debunking of spiritualism.)

Photo by Elsie Wright, public domain in the United States.

In 1983, 66 years after their prank went viral, Elsie and Frances admitted they copied illustrations of dancing girls from a  children’s book and drew wings on them. They posed with the cardboard cutouts, producing the fairy effect.

But even then Frances insisted that one of the photos—which shows only misty images of the fairy figures without the girls—was real. “It was a wet Saturday afternoon and we were just mooching about with our cameras and Elsie had nothing prepared. I saw these fairies building up in the grasses and just aimed the camera and took a photograph.”

Elsie at times said the fairy figures were figments of her imagination that was able to photograph. The photographers themselves had a hard time letting go of the fairies, despite some discomfort that came with their faked photos fame.

In 1985 Elsie said that she and Frances were too embarrassed to admit the truth after fooling Doyle. “Two village kids and a brilliant man like Conan Doyle—well, we could only keep quiet.” In the same interview Frances said: “I never even thought of it as being a fraud—it was just Elsie and I having a bit of fun and I can’t understand to this day why they were taken in—they wanted to be taken in.”

Jeff Elder, Digital Communications Manager
Wikimedia Foundation

Very interesting conversation with Joe Gebbia, co-founder of Airbnb. I share some insights I got by watching the 2013 video.

• First insight: they were 3 founders in California with a stagnating company (Airbnb), they could have kept staying in their office trying to improve the site, write more software code and instead what did they do? Realising that apartments in New York all had horrible photos, they took a flight (from California to New York!), rented a camera, knock on doors of Airbnb users in New York, took better photos of their apartments and replace them on the site. As Joe says in the interview, “for the first year, we sat behind our computer screens trying to code our way through problems”, instead going to meet their users is one of the pillars of design thinking, its very human-centred focus. Just after this intervention, revenues which were stagnating at 200 dollars per week went up to 400 dollars per week. Near the end, Joe says “if you ever want to understand your product, go stay in the home of your customer” (well, this applies only to Airbnb … and maybe also to Couchsurfing ;)
• Actually the previous suggestion was given to Airbnb founder by Paul Graham (of Ycombinator, I loved his “hackers and painters” essay!) which suggested it’s okay to do things that don’t scale. What is the meaning? I think it’s again about being very human-centred, going out of the building, develop empathy with specific persons and really understand him/her. So that you can make improvements that really satisfy real needs (of at least one real person!). Scaling to millions of persons will come later, if needed.
• Another suggestion by Paul Graham was go meet the people which again is the very human-centred side of design thinking. The interviewer asks “what if your company is not for < go out and meet people?> and Joe replies “well, be pirate”, a sort of “do it anyway” but then I asked my self how do you get it accepted? This reminded me of the pragmatic book Undercover User Experience Design.
• And what can the employee bring back from this “go out and meet people” to the company? Joe replies “visible, tactical, tangible insight that came from somebody is consuming your product or your service”
• Joe suggests to become the patient (of your service/product). For example, every new employee at Airbnb, during the first week, makes a trip (using Airbnb of course), document it and share insights with his/her new department. Wow!
• Joe also cites the stars vs heart icons story: when you start as new employee at Airbnb, you ship (a new small feature, something) on day one, so that new employees can experience shipping on day one. A newly hired designer was given the task of looking at the star functionality (an icon you click in order to save a listing you find interesting). After few hours he or she comes back with something like “I think the stars are the kinds of things you see in utility-driven experiences. Instead Airbnb is so aspirational. Why don’t we tap into that? I’m going to change that to a heart.” And Joe “Wow, okay. It’s interesting” and they just shipped the new feature, to the entire userbase (not a/b testing or just shipping it to 10% of the users)! They also added some code in it in order to track it and see how behavior change. And the next day they checked the data and the engagement with the icon increased by over 30%, that simple change from a star to a heart increased engagement by over 30%! In short, let people be pirates, ship stuff and try new things.

Photo by Zack McCune, CC BY-SA 4.0.

Alangi Derick comes from Buea, Cameroon. He joined the Wikimedia movement to develop his skills in coding, and was quickly hooked by the movement’s values and its community culture, eventually becoming a staunch advocate for it in his university.

As a computer science student at the time, he joined the movement a year and a half ago, and his work booked him a place at the 2016 Google Summer of Code as one of the Wikimedia Foundation’s students. Derick passed the program, helped mentor teenage participants in Google Code-in for two consecutive years, and has helped fix bugs in the MediaWiki software. He is now trying to pass this experience onto other potential contributors in his country.

In 2015, Derick was looking for an extracurricular activity where he could practice and boost his coding skills. That’s when he learned about the Wikimedia Foundation projects and their participation in Google Summer of Code (GSoC), an annual project where students spend the summer working on a free open-source project of their choice mentored by one of the participating organizations.

“I felt like I was lagging behind and wanted to explore a little bit by working on a project that will be used by millions of people,” Derick said. “With this idea in mind, I searched for open source organizations with active projects and a strong community that would be willing to help me out if I faced problems. I found that the Wikimedia Foundation and its MediaWiki project perfectly matched my skill set, so I decided to join them.”

Every year, students who wish to join GSoC can apply to participating organizations proposing a new project idea or claiming one of their ready-to-pick-up tasks. When their project is approved, they spend a whole month learning about and integrating into the community they will be working with. Starting in June, students start working on their coding projects and are mentored by the participating organization and its community.

To prepare for the GSoC, Derick talked to Wikimedia developers on their IRC channel, where they directed him to areas of need that he could work on. In a few months, Derick was able to create over 25 patches (codes that fix bugs in software) on the MediaWiki code base and its extensions.

Derick has been one of the six students to complete the program in his GSoC round and was the first African GSoC student for Wikimedia.

In addition to GSoC, and even prior to joining it, Derick was a mentor to Google Code-In Wikimedia participants in 2015 and 2016. Participants in Google Code-In are pre-university students aged 13 to 17, who are introduced to the world of free and open-source coding as they practice on very small coding tasks. Like in the GSoC, participants in the Google Code-in are mentored by the participating community members.

“I wanted to share what I learned,” Derick explained. “I found myself trying to build a Wikimedia community in Cameroon, but there was an active group supporting the activities there already. The group helps both writers and developers.”

Last January, Derick attended WikiIndaba, the regional conference of Wikipedians from the African region. The conference was another opportunity to share his thoughts on “contributing to open-source communities,” learning about “capacity building, Wikimedia grants, improving Wikipedia’s content,” and many other topics.

For the future, Derick is planning to expand his efforts to support the Wikimedia movement and its community in his country.

“Wikimedia’s goal is to make knowledge free to everyone, and this is what I want to do in my community,” he said. “I’m trying to get the knowledge to people free of charge, and this allowed me to work on software that proliferates free content.”

Samir Elsharbaty, Digital Content Intern
Wikimedia Foundation

• English Wikipedia - All articles about someone who is known as an author of any kind gets the template.
• Wikidata - For all the items for someone who is known as an author of any kind we seek the VIAF identifier.
• OCLC - All the libraries in the world will be updated with a link to Wikidata within a month. This will make it easy for a librarian to find Wikipedia articles in any language.
• Open Archive - It has a project called "Open Library" and it has freely licensed e-books. Wikidata includes Open Library identifiers. OCLC and OL have links combined with Wikidata identifiers. As these numbers include, people in libraries or from Wikipedia could find authors with free books.
• other Wikipedias - they could include VIAF and OL identifiers as well. Open Library has books in languages other than English..

Musical event at Dar Lasram, Medina of Tunis. Photo by TAKOUTI, CC BY-SA 4.0.

MedinaPedia is a project in Tunisia that aims at documenting the monuments of Tunis’ ancient city center on Wikipedia. Their passion for that historical part of their country encouraged the participants to add over 400 articles to Wikipedia in five languages over the past three years. The organizing group is currently planning to extend their efforts to include other cities and towns in Tunisia.

The idea of MedinaPedia started at Carthagina, a local movement concerned with preserving the heritage of Tunisia, in 2014. Three Wikimedians (Émna Mizouni, Yamen Bousrih and Brahim Bouganmi) had a vision and took the lead on making it a reality. In 2015, Carthagina partnered with The Association of Preservation of the Medina of Tunis (ASM Tunis) to start the project.

At that time, MedinaPedia planned to document 150 selected historical monuments in the Medina of Tunis, the city’s ancient core, for people to have easy access to information about them. The Medina of Tunis is a particularly apt place to start; Wikipedia states that “it has been a UNESCO World Heritage Site since 1979 … [containing] some 700 monuments, including palaces, mosques, mausoleums, madrasas and fountains dating from the Almohad and the Hafsid periods.”

The first part of the MedinaPedia project was to write articles about these monuments on Wikipedia. The second, called QRpedia, was to attach QR codes to the monuments so that tourists and locals could easily access the articles.

The project was kicked off in September 2015 with a group of motivated volunteers who had been selected through an open application process. They were students from different fields, young doctors and engineers who all had one thing in common: curiosity and passion for the Medina.

We met on the first Sunday of every month in Dar Lasram, the office of our partner: ASM Tunis. We would discuss what we had achieved in the previous month, write some more articles, and make plans for the following month.

Throughout the year, we had a lot of help from our partners in Wikimedia Tunisia Yassine, Mounir, and Wael, who guided us through the process of writing, editing, and publishing the articles on Wikipedia. Jamel Ben Saidane (Wild Tunis) helped us with anything related to the Medina.

The first workshops were very interesting for us. We left each one having learned something new about the Medina and the world of Wikimedia. However, as time went on, knowledge and discovery were not the only things we looked forward to from our workshops. We wanted to see each other. The strictly professional environment turned into a monthly reunion of friends.

Brahim, the project coordinator and one of the authors of this post, kept track of what we achieved at the end of every set of workshops. On the one hand, he was aware of the large amount of articles we would write, translate, or edit within a certain timeframe. On the other hand, he (like every member of the team) was so busy planning meetings, writing more articles, and setting the next steps that none of us realized the amount of work we had done until the first part of the project came to end.

Our goal at the beginning was to cover about 150 monuments. We thought it was a long shot but we were hopeful nonetheless. Now, as the project is coming to an end, we are proud to say that our team has written over 400 articles in 5 languages. According to the team members, Yamen Bousrih and Sami Mlouhi who counted the results, we have uploaded over 5000 pictures so far on Wikimedia Commons. More than half of the articles that were created in French about Tunisia in 2016 were written by MedinaPedia members. Moreover, we are going to attach the first set of QRpedia codes by the end of April.

Even though we have not reached the end of the MedinaPedia Tunis project, we have already started expanding to other cities and towns. By the end of February we held the first workshop of MedinaPedia BeniKhalled, in partnership with ASM Beni Khalled, and now we are getting ready to start MedinaPedia Sfax. This is just the beginning as we are planning to cover other places across the country.

We hope that what used to be a small project in the beginning will inspire people to start a series of successful global projects.

Youssef Ben Haj Yahia, member
Brahim Bouganmi, coordinator
MedinaPedia project of Wikimedia Tunisie user group

———

Three years of weekly editathons

Photo by Hannibal, CC BY-SA 4.0.

In 2014, a small group of Swedish Wikipedians started holding weekly editathons in Gothenburg, Sweden. There are many other Wikimedia meetups and regular editathons around the world, but this group has been at it each week for over three years.

Litteraturhuset (The House of Literature) in Gothenburg, is where the Wikipedians gather every week for a simple but fun program: Participants meet, edit Wikipedia articles, and have some coffee.

We have met nearly 150 times, edited several hundred articles about female authors and literary figures, and improved the quality of 20 of these articles, two of which became featured articles, the highest quality level determined by the Wikipedia community. The editathons attracted great female participation, which inspired male Wikipedians to edit female profiles on Wikipedia.

Some of the participants shared their thoughts about this experience:

• “Thanks to the editathons, I’ve become bolder in writing long entries and creating my first article! It was a good opportunity for me to keep editing Wikipedia along with other nice and interesting people.”
• “I always had a good time when I was there. Everyone is helpful and pleasant. I’ve learned so much more than before attending the weekly editathons.”
• “I came into contact with the Wikimedia group during the Gothenburg Book Fair in 2016. I got help writing an article about my father, Viktor Tesser (an artist). Since then, I’ve written about a science fiction trilogy, expanded the definition section of the article about families, and now I’m writing an article about a female scientist who’s researching girls with autism. We talked about symbols, female warriors, the early photographs, manga artists, ghost nets, famous female TV personalities, manors in the Bohuslän area, and much more.”

Different media outlets featured the project and the small group behind it, which encouraged other Wikipedians to host a similar activity. Over the past three years, a few other regular editathons have cropped up in Stockholm, Jönköping, and another one has recently started in Gothenburg.

We are not done yet

In 2016, two organizers of the weekly editathons hosted a Wikipedia camp. Inspired by the Armenian Wikicamps, the Swedish camp helped increase female participation on the Swedish Wikipedia as the newcomers were all women. They were invited by Wikimedia Sweden (Sverige) to attend a free week at a folk high school. The new participants continued editing for long time after the event.

The impact of our 2016 camp encouraged us to host a new one in 2017. Applications for the new camp are now open. More information about the camp is available on the Swedish Wikipedia and photos from the camp can be found on Commons.

In the meantime, the weekly editathons are being held on a regular weekly basis and new people join this effort every time. One of our participants comments on this saying:

“For me, the editathons are now a weekly habit, with nice people, interesting discoveries and much to learn. What started with the goal of “20 recommended articles” has grown to much more. We meet new faces nearly every week. We had annual meetings with the Swedish Wikimedia chapter and celebrated Wikipedia’s 15th anniversary, organized the Gothenburg Book Fair and wikicamps, made plans for International Women’s Day, and some attendees joined us from Svenshögen (quite far for weekly trips) as well as British Columbia. Our group doesn’t consist of females only and we don’t only write about women, but a clear focus has its own value. Our Tuesdays at Litteraturhuset are probably like Wikipedia—not perfect, but fantastic.”

Photos from the weekly editathons are available on Wikimedia Commons.

Lennart Guldbrandsson, Swedish Wikipedian

In brief

Photo courtesy of Wikimedia Ghana user group.

Art + feminism workshop in Ghana: Last weekend, Wikimedia Ghana user group hosted an Art + feminism workshop in Accra Ghana where the participants edited African women profiles on Wikipedia. Photos from the event on their Facebook page.

2016 picture of the year competition is now open: Hundreds of images that have been rated Featured Pictures by the international Wikimedia Commons community will run for 2016’s picture of the year competition. Two rounds of voting will be held: In the first round, users can vote for as many images as they want. The first round category winners and the top ten overall will then make it to the final. In the final round, each voter needs to pick one image only. The image with highest votes becomes the picture of the year. More about the competition and voting are on Wikimedia Commons.

Workshop on fake news and new journalism by Amical Wikimedia: Amical Wikimedia, the independent thematic organization supporting Wikimedia in the Catalan-speaking countries, is holding a workshop on new journalism. The workshop will be held between 15 and 30 May 2017, where the journalist participants will be informed about the human rights related to access to information, how to maintain and encourage critical thinking, and more. The workshop will be organized in collaboration with Faber, the Arts, Sciences, and Humanities residency of Catalonia in Olot. More information and how to apply on Faber’s website.

Hindi Wikipedia presentation at Rashtriya Sangoshthi: The Bhabha Atomic Research Center, Mumbai (BARC) and the directorate of culture and archaeology in the governorate of Chhattisgarh, India organized a presentation at the Rashtriya Sangoshthi (national event) to share their editing experience with the event attendees.

WikiJournal user group getting ready for piloting a new platform: WikiJournal is an idea for an open peer-reviewed academic journal where the participants can publish research, peer-reviewed Wikipedia articles (such as the featured articles), etc with the main author’s name. The organizers are now getting ready for their website pilot. More about WikiJournal on Wikimedia-l.

The Netherlands and the world exchange platform kicks off: Wikimedia Netherlands, the independent chapter supporting Wikimedia in the Netherlands, has launched this platform to encourage global use of Dutch collections on non-European cultural heritage. The platform will particularly encourage sharing collections from countries with historical ties with the Netherlands including Indonesia, Sri Lanka, Brazil, Ghana, Suriname, South Africa, and others. More about the new website on Wikimedia-l.

Bay Area WikiSalon meets next week: San Francisco Bay Area’s WikiSalon will be held on Wednesday 29 March at 6 PM local time. The meetup will be held at Noisebridge makerspace/hackerspace followed by guided tours of Noisebridge. More about the event on Wikipedia.

Conflict of interest confusion on the English Wikipedia: A request for comment on the future of the conflict of interest policy and investigations related to it is ongoing on the English Wikipedia after an attempted close, which would have established “a task force of trusted editors to act as referees in matters related to conflict of interest and outing,” was reversed.

Compiled and edited by Samir Elsharbaty, Digital Content Intern
Wikimedia Foundation

The Wikimedia genealogy project now has a mailing list.

Photo by ArielGlenn, CC BY-SA 4.0.

The 2017 Wikimedia Developer Summit took place on January 9–11 at the Golden Gate Club in San Francisco, California. Coordinated with support from the organization team, around 179 participants from 30 countries participated in the summit, out of which 29% were from outside of the Wikimedia Foundation.

The summit provides a platform to developers both volunteer contributors and staff members to meet and have conversations around projects and technologies supporting the Wikimedia movement. Developers come together to gather feedback on current approaches from the technical community and have an in-depth discussion on problems that are technically challenging, and identifying practical solutions for them. The overall goal of this meetup was to push the evolution of technologies that falls under the umbrella of Wikimedia, thereby addressing the high-level needs of the movement.

The program consisted of two days of pre-scheduled and unconference sessions, and an unscheduled day for people to self-organize and get stuff done for their projects. At this year’s event, some of the topics focused on were planning for the Community Wishlist 2016 top results, brainstorming ideas to managing our technical debt and growing our developer community. The highlight was the keynote from Ward Cunningham, the inventor of the wiki, titled: “Has our success made it hard to see your own contribution?”

Photo by Ckoerner, CC BY-SA 4.0.

There was a Questions & Answers (Q&A) session about Wikimedia Foundation’s Technology and Product department, with Victoria Coleman (Chief Technology Officer) and Wes Moran (now-former Vice President of Product). For the Q&A, 40 questions were collected before the event that got a total of 1840 votes. In parallel to the pre-scheduled sessions, there were unconference tracks for which participants were invited to submit topics on the fly on a physical wall using sticky-notes.

For each session, there were 1 or 2 note-takers(s) collaboratively taking notes, moving them onto a Wiki page, and copying the action items into the Wikimedia’s Phabricator later. Some selected sessions were streamed live for remote participants who also joined the discussion via IRC. The full program schedule was updated all throughout the event by organizers, participants, and session hosts!

On the third day of the summit, which had a pretty flexible agenda, participants got some stuff done: programming, project-planning, and meetings! This day was utilized for making concrete plans on the topics that emerged from the day 1 and 2 of the summit. Folks spent the day writing code with people who they normally communicate with online, getting their code reviewed by peers present in the room, and submitting patches for ideas that were brought up in their session. There was a project showcase at the end, in which some participants demoed the projects they built and shared the action items for which they took responsibility. Ward Cunningham exhibited a plugin that he developed for tabular data and presented it being fetched on the federated wiki. The full showcase is available on Commons.

Photo by Ckoerner, CC BY-SA 4.0.

Besides three full days of productive discussions with actionable items on various topics, one immediate outcome from an unconference session lead by Gergő Tisza, was the announcement of the Developer Wishlist Survey at the summit. The Developer Wishlist is an effort to seek input from developers for developers, to create a high-profile list of desired improvements for MediaWiki platform, Wikimedia server infrastructure, contribution process, documentation, etc. The survey was concluded in February with 76 proposals that received a total of 952 votes from 144 editors. The proposals that received most votes are are now ready to be promoted to our volunteer developers, teams within the foundation, and through our various outreach and hackathon events.

The exploration has begun for investigating potential directions for addressing questions that were brought up in the Q&A session with Victoria and Wes. Hopefully, there will be more tangible updates to share from this discussion in a few months from now. A feedback survey was conducted for both in-person and remote participants, results of which are summarized on Mediawiki.org. One of the participants said “Keep doing this, if you can, for it opens up possibilities that would not otherwise be open.”

It is a great boost for the developer community that events like these provide a space for long-term contributors to meet with each other and reflect on their collaborations.

Srishti Sethi, Developer Advocate, Technical Collaboration team
Wikimedia Foundation

Our next developer event is the Wikimedia Hackathon, held from May 19–21, 2017, in Austria. If you’re interested in attending, please register on Mediawiki.org.

14/03/2017-20/03/2017

Mapping

• The Costa Rican community photomapped the trails in the natural forest reserve of Bosque del Niño in Poás volcano.
• The Mexican OSM community proposes the use of the hashtag #CallesVioletas to visualize and map the public spaces. This is done by using an inclusive methodology that empowers citizens by generating participatory data from georeferenced photos.
• User kreuzschnabel asks (automatic translation) in the German user forum how to tag scenery frames.
• Christoph Hormann cleans up defective multi-polygons and data garbage in the Antarctica region. He wonders why there are so many nodes created with the iD editor.
• In his draft proposal, user dieterdreist suggests that the key emergency be supplemented by the collection of “dry riser inlet”.
• Ever wondered why OSM hasn’t adopted a review procedure yet? Read the discussion on responding to vandalism thread in the Talk mailing list. Proponents and opponents share their thoughts.
• The proposal for drying rooms for sports equipment is under way and Thilo Haug asks for comments.
• Yuri Astrakhan suggests some features for editors to improve the usage of tags.
• Tod Fitch thinks that the direction=* tag is used for too many unrelated conventions. The mailing list Tagging discussed some of them.
• Charlie Loyd from Mapbox, writes a blog about the high-resolution images that are made available in India and can be used for mapping.

Community

• User mueschel has published the visualisation service OSM Destination Signs, for relations of type destination_sign. See also the discussion (automatic translation) at the German forum.
• Phase 2 of the School of Free Geomatics has just been launched at Benin with a lot of reuse of the OpenStreetMap data.

Imports

• An import of trees in the West Midlands of England that has mostly ignored the import guidelines has sparked some difficult discussions – some highly respected members of the GB community spoke up against it.
• There was a discussion about Facebook’s proposed import (based on automatically recognising streets) on the “import” mailing list. It also continues to be discussed on the Thai forum.

OpenStreetMap Foundation

• The minutes of the board meeting held on 21 February 2017 were published in the wiki of the Foundation. There was a discussion about the transparency of the Data Working Group among other working groups, the necessary profit from SotM and furthermore, the status of the Corporate Membership was presented.

Events

• Simon Poole invites to the Annual General Meeting of the Swiss OpenStreetMap Association followed by a Mapping Party. This takes place on Saturday, April 8th at the University of Fribourg.
• The enrollments for SotM France from 2nd to 4th June in Avignon are open.

Humanitarian OSM

• On the HOT mailing list, Johnattan Rupire asks for help in dealing with the flood disaster in Peru which caused many casualties. This wiki page was created for more information.Here the recent tasks to work on:
  • #2701 – Peru Flood Support 5: Pampa Pacta, Punta Hermosa
  • #2677 – Peru Flood Support 2: Cayma
  • #2679 – Peru Flood Support 4: Huarmey
• Johnattan Rupire (@johnarupire) publishes an article in his blog about the importance of open data and participatory collaboration to save lives in time of emergencies and disasters.
• Jochen Topf asks on the HOT mailing list for support in the repair of defective multi-polygons. Background and tools can be found in his website. The current status can be seen here.
• Violaine from CartONG requests participation in a survey.
• In Belgium you are invited to the second National Mapathon next Saturday, 25th of March, which will be organised at 8 different university campuses simultaneously. “More than 200 mappers will be trained by OpenStreetMap Belgium volunteers to work on MSF/Missing Maps tasks”, says Joost Schouppe.
• Pjstewart1984 describes in his blog, how the results from MapSwipe can be used in OSM Tasking Manager.
• HOT is hiring a part-time developer for the OpenAerialMap project.

Maps

• [1] The “Neue Westfälische” presents a new city map of Bielefeld. This map is based on OSM, cadastral and other sources. It is to be further expanded.
• Frikart.no offers Garmin Maps with different Norwegian map styles.

Open Data

• Christian Quest reported that the RTE (the French electricity network operator) published all network data (overground 45 kV to 400 kV, Underground, etc.) and declared it as open data.

Licences

• Update: There is now an official common statement by The OpenStreetMap Foundation and Creative Commons for the compatibility of the CC-BY 4.0 with OSM. If you want to use sources that are under the CC-BY 4.0, you must obtain a waiver from the data provider as to 1) DRM restrictions and 2) format of attribution. Here’s a link to a template waiver form, as well as a link to template waiver forms for CC BY 2.0 and 3.0 data sources.

Programming

• Ilya Zverev proposed a pull request that allows OSM users to communicate their email address to external programs via OSM verification.
• Michael Spreng tests a new routing frontend at the swiss server. He asks for feedback.
• Frederik Ramm suggests in the Geofabrik blog, what to do if osm2pgsql crashed on your servers due to the huge collective relation uploaded in Brazil a few days ago. (Reported in our last issue)
• Mapbox checks the instructions of the navigation software OSRM. They use a tool that translates ASCII art of an intersection to a valid OpenStreetMap extract, then pushes the data for that scenario through the entire engine to make sure it behaves correctly.
• Rob H. Warren is looking for volunteers regularly fetching planet dumps of OpenHistoricalMap as a backup.
• Naoliv will distribute gifts to anyone who writes a notification tool, that will notify when there is a change in street name in a particular area.

Releases

Provided by the OSM Software Watchlist.

(*) unfree software. See: freesoftware.

Did you know …

• … the possibility to access the David Rumsey Map Collection via Luna Browser with more than 75,000 historical maps?
• … Map Compare?
• … Maps on the Web?
• … the Android app StreetComplete? It allows you to easily find and add missing data in your environment.

Other “geo” things

• A collection of community created maps of India sourced from different government websites is freely available to all Indians.
• Boston schools ditch Mercator-based maps for Gall-Peters. (via TeachOSM). The world maps of Arno Peters provide a true to the surface projection and the distortions of the Mercator projection are avoided.
• An article about Arun Ganesh’s involvement in Wikipedia and OpenStreetMap.

Upcoming Events

Where	What	When	Country
Passau	FOSSGIS 2017	22/03/2017-25/03/2017
Zaragoza	Mapping Party #Zaccesibilidad (Mapeado Colaborativo)	24/03/2017
Louvain-la-Neuve	Bar meeting	24/03/2017
Vancouver	Vancouver mappy hour	24/03/2017
Mazzano Romano	Workshop 1	24/03/2017
Ayacucho	Workshop of Mapbox Studio	25/03/2017
Bremen	Bremer Mappertreffen	27/03/2017
Graz	Stammtisch Graz	27/03/2017
Viersen	OSM Stammtisch Viersen	28/03/2017
Montpellier	Rencontre mensuelle	29/03/2017
Mazzano Romano	Workshop 2	31/03/2017
Kyoto	【西国街道#02】山崎蒸溜所と桜マッピングパーティ	01/04/2017
Rome	Walk4Art	01/04/2017
Rostock	Rostocker Treffen	04/04/2017
Stuttgart	Stuttgarter Stammtisch	05/04/2017
Helsinki	Monthly Missing Maps mapathon at Finnish Red Cross HQ	06/04/2017
Dresden	Stammtisch	06/04/2017
Zaragoza	Mapeado Colaborativo	07/04/2017
Mazzano Romano	Workshop 3	07/04/2017
Fribourg	SOSM Annual General Meeting and mapping party	08/04/2017
Rennes	Atelier de découverte	09/04/2017
Avignon	State of the Map France 2017	02/06/2017-04/06/2017
Kampala	State of the Map Africa 2017	08/07/2017-10/07/2017
Curitiba	FOSS4G+SOTM Brasil 2017	27/07/2017-29/07/2017
Aizu-wakamatsu Shi	State of the Map 2017	18/08/2017-20/08/2017
Boulder	State Of The Map U.S. 2017	19/10/2017-22/10/2017
Buenos Aires	FOSS4G+SOTM Argentina 2017	23/10/2017-28/10/2017
Lima	State of the Map – LatAm 2017	29/11/2017-02/12/2017

Note: If you like to see your event here, please put it into the calendar. Only data which is there, will appear in weeklyOSM. Please check your event in our public calendar preview and correct it, where appropriate.

This weeklyOSM was produced by Nakaner, Peda, Polyglot, Rogehm, SeleneYang, SomeoneElse, Spec80, SrrReal, TheFive, YoViajo, derFred, jinalfoflia, keithonearth, kreuzschnabel, vsandre, wambacher.

Video by Victor Grigas, CC BY-SA 3.0. You can also view it on Vimeo or Youtube.

Last January, Iraqi Wikimedians held a Wikipedia meetup in Baghdad where they helped attendees understand how Wikipedia works and taught them basic editing skills. “Iraqis’ participation on Wikipedia is limited,” said Mahmoud Alrawi, one of the workshop organizers. Consequently, “there is a lack of coverage about Iraqi topics on Wikipedia.”

Alrawi and his fellows in the Iraqi Wikimedians user group wanted to share their experience on Wikipedia with new users. They used their Facebook page to invite interested followers to join the workshop. Many people from Baghdad and other places in Iraq registered to attend the workshop, but the number of interested users greatly exceeded the number of spots available in the workshop. Participants included educators, students, senior citizens, and others from different backgrounds.

“Our priority in the near future will be to follow up with those newbies who need attention,” Alrawi explained. “For example, the concept of notability was not very clear to everyone. We had to address this first. After that, we may want to hold similar workshops in other cities and towns in Iraq, so that attendees don’t need to travel far to learn about Wikipedia.”

You can get in contact with them on the Iraqi Wikimedians meta page.

Samir Elsharbaty, Digital Content Intern
Wikimedia Foundation

When students bring a critical eye to Wikipedia, comparing its available content to their course readings, academic studies, and personal experiences, they’re often surprised at what information is missing. During their assignment to research a topic and write about it on Wikipedia, they remedy that information disparity.

In Annette Nierobisz’s course on Women, Crime, and Criminal Justice at Carleton College in spring 2016, students identified missing information about criminology and the justice system, then created articles on those overlooked topics. For example, students started the article about reproductive health care for incarcerated women in the U.S.. As more women are incarcerated in the United States, prisons must develop systems to care for pregnant women and their babies. But most prisons lack the proper resources to make this necessary shift. If Americans don’t know about issues like this plaguing incarcerated women, they are less likely to prioritize criminal justice reform as a political platform. By contributing information about the subject to Wikipedia, students brought Americans a step closer to understanding the research behind the issues.

Similarly, students adding accurate, accessible, and comprehensible legal information to Wikipedia are empowering citizens to understand the legal rights that impact their everyday lives. After all, most people don’t have access to law books, and, even if they do, they lack the legal prowess and education to understand the details. Most Americans do, however, have access to Wikipedia, which can summarize case law relevant to their communities. This is the power of a public resource like Wikipedia and why we need more criminology students to make sure as many communities as possible are represented.

This week, I’m at the Academy of Criminal Justice Science‘s annual meeting in Kansas City, MO. ACJS promotes criminal justice research and education, and the attendees are the ideal collaborators to bring their expertise and students to Wikipedia. If you are attending the conference, stop by the Wiki Education booth in the exhibit hall to find out how criminology and law students are working to inform citizens about their rights and laws.

Exhibit hall hours

• Wednesday, March 22, 2017, 9:00am–5:00pm
• Thursday, March 23, 2017, 9:00am–5:00pm
• Friday, March 24, 2017, 9:00am–2:00pm

If you’re interested in joining our program, email us at contact@wikiedu.org.

Photo by LoggaWiggler, public domain/CC0.

Suppose there is an alternate reality in which you own an apartment building and your biggest worries are the security of your apartments and the well-being of goldfish, respectively.

In this reality, that of apartment building ownership without profit motive, there exists a startup, “GLDFSH,®” that allows tenants to summon others to feed their goldfish. Sometimes folks will set up a trust with GLDFSH to take care of their goldfish after they pass away.

As you care about security (even more than goldfish), if a tenant no longer inhabits one of your apartments, you change the locks as a matter of course—regardless of circumstance. There have been times (dark times) when a goldfish being cared for in trust has missed a meal because you didn’t get GLDFSH an updated copy of a key in a timely manner.

So what if you made a special GLDFSH-only key that opened all the apartments where there were goldfish?  You could keep that key under the watchful eye of a security minion 24/7/365.  That minion wouldn’t allow anyone to use the key, but would allow anyone with an active and valid GLDFSH employee ID (very secure) to enter an goldfish-containing apartment by using that single special key.

———

Keyholder, a newly open-sourced project from the Wikimedia Foundation, is a bit like that ever-watchful security minion. For us, it allows authorized developers to access remote servers using an ssh key, to which it is the only user that has access. More specifically, Keyholder is an ssh-agent proxy that allows a group of trusted users to share an SSH identity without exposing the contents of that identity’s private key.

We have been using Keyholder for several years, and we’re now releasing it as a standalone project.

Wikimedia and SSH

Secure Shell (SSH) is a cryptographic network protocol and client-server architecture that is used to provide a secure communication tunnel over an insecure network. The SSH protocol is defined across a series of requests for comments, an Internet standards-setting publication, and its OpenSSH implementation is broadly used wherever you find Linux on a server.

Over here at Wikimedia, we use SSH everywhere! If you interact with a shell account, chances are you authenticate yourself (and the server to which you’re connecting) via SSH.

SSH is also the tool we turn to for deployments of MediaWiki and other software. Our deployment software, stripped to its nuts and bolts, sends a command over SSH to all of our application servers to tell them that new code is available and that they should fetch it.

Secure secure shell

SSH is not a perfect technology; there are various means by which malicious actors may exploit SSH, and we do our best to mitigate the ability of those malicious actors to do harm to our infrastructure.

For instance, there are several ways in which SSH may authenticate a client – passwords and public keys being the most common. Using password-based authentication is insecure for all the normal reasons that passwords may be compromised – everything from using easy-to-guess passwords to rubber-hose cryptanalysis.

Alternatively, public key cryptography is a technology that is indistinguishable from magic (a.k.a, “math”) that enables a server to authenticate you by validating that you have some secret (a private key) based on a public piece of information (a public key).

Public key cryptography is awesome; however, there are ways in which you can be bad at public key authentication.

Photo by bastique, CC BY-SA 2.0.

ssh-agent forwarding considered harmful™

ssh-agent is a program that allows a user to hold unencrypted private keys in memory for use in public key authentication. ssh-agent is neat – it means you only need to enter the password for your private keys once per login session. ssh-agent is also a way you can be bad at public key authentication.

A common use of the ssh-agent is to “forward” your agent to a remote machine (using the -A flag in the OpenSSH client). After you’ve forwarded your ssh-agent, you can use the socket that that agent creates to access any of your many (now unencrypted) keys, and login to any other machines for which you may have keys in your ssh-agent. So, too, potentially, can all the other folks that have root access to the machine to which you’ve forwarded your ssh-agent.

While some folks may pick-and-choose keys to keep in one of many ssh-agents, it’s entirely possible to keep your Wikimedia production SSH key in the same ssh-agent that you forward to your second-cousin’s friend-of-a-friend’s shared-hosting provider. For this reason, forwarding your ssh-agent is Considered Harmful™.

And even though we know no one would ever be reckless enough to try to forward SSH keys, we discourage bad practice by not allowing anyone to forward their ssh-agent to production.

Deployment hosts considered useful™

Keeping track of the two deployed versions of MediaWiki, the nearly 2000 files in the MediaWiki configuration repository, and the correct version of the other 169 extensions we branch every week is a heavy burden.

To lighten the load on our deployers, we use a handful of deployment hosts from which we are able to easily script deployments.

This means you can login to a deployment host, pull in the latest updates, and get new code running on the Wikimedia sites in under a minute (if you’re a quick-draw with git).

A perfect storm

So let’s review.

1. Publickey SSH authentication is magic, let’s use that!
2. To keep access to our production machines secure and to encourage best practice, we won’t allow anyone to forward their ssh-agent to production.
3. For ease of use, we’ll deploy from a special host in production.
4. We’ll use SSH to deploy from our special deployment host.

But how do we grant deployers SSH access from the deployment host without using passwords, without allowing agent forwarding, without having to manage SSH keys for every. single. deployer, and without creating the administrative mess of every deployer sharing a single deployment key?

With Keyholder, of course!

Several years ago there were some folks around here who pondered this exact problem and came up with a pretty novel solution that we’ve finally made into a standalone project!

Keyholder began life as a gleam in the eye of principal operations engineer Faidon Liambotis, who conceived of its core requirements and gave a basic operational sketch. From there, Ori Livneh did the hard work of reading the source and RFCs that make ssh-agent work and turned that into the initial version of Keyholder. Tyler Cipriani added support for multiple keys and separate user groups. Riccardo Coccioli added support for OpenSSH SHA256 fingerprints. And, finally, Mukunda Modell liberated Keyholder from the depths of our Puppet repository where it was previously languishing in obscurity.

Keyholder makes it possible for deployers to share a key without complicated administrative overhead. When a user needs to use SSH to connect to an application server from our deployment host they point ssh-agent requests to a UNIX domain socket created by Keyholder. If a user’s group membership allows them to use a particular key protected by Keyholder, then Keyholder will sign an application server’s authentication request, otherwise authentication will fail and they will not be able to login to the remote machine.

The actual SSH private keys are encrypted on disk and only readable by root users. When a user’s shell account is removed from the deployment host there is no need to rotate the SSH public/private keypair because the user has never had direct access to it, rather they’ve simply been using the mystical magic of Keyholder.

The magic of Keyholder is in its ability to proxy the ssh-agent socket as a privileged user. Keyholder creates a UNIX domain socket that is a readable and writable by anyone with shell access; however, Keyholder will only respond to requests to list identities and sign requests – users cannot add new keys or accidentally remove keys from the agent. Keyholder will only sign requests after verifying that the requesting user is authorized to make a signing request using a particular key.

We’ve been using Keyholder for several years at this point, and it’s a solution that works well for us. Still, it’s not a perfect approach. The increase in security comes at a price of increased complexity both for users and administrators. When the need to add new keys arises, the means by which those keys are generated and stored can be opaque for end-users. Further, utilizing and troubleshooting Keyholder as an end-user is not obvious. Many of our uses of Keyholder are scripted, so that Keyholder’s use on our servers is largely (hopefully) transparent. On the administrative side, storing separate keys and passwords for every group using Keyholder has its own difficulties.  Also, the need to add keys to the ssh-agent being proxied by keyholder means that the servers on which Keyholder are running require some kind of manual intervention on reboot to ensure that Keyholder is, in fact, holding all the necessary keys.

Despite the added complexity, we’ve found that Keyholder is a very useful tool. We’re excited to unlock its potential on the world! We hope that it will be useful to other organizations faced with similar challenges, of managing many servers that a large number of users are accessing via ssh. It’s a small step towards improving the security of our shared online infrastructure.

Tyler Cipriani, Software Engineer, Release Engineering
Mukunda Modell, Software Engineer, Release Engineering
Wikimedia Foundation

Highlights

• Local and remote staff connected for an all-staff meeting in San Francisco’s Presidio. Staff shared Year of Science reflections, celebrated last year’s successes, and kicked off the annual planning process for the next fiscal year.
• Wiki Ed staff attended the annual meeting of the American Association for the Advancement of Science in Boston. Director of Programs LiAnna Davis and Wikipedia Content Expert for the Sciences Ian Ramjohn discussed using Wikipedia as a platform for science communication with attendees in the exhibit hall and in a workshop with the Simons Foundation’s Greg Boustead and the Wikimedia Foundation’s Dario Taraborelli.
• NPR and Pacific Standard ran major news pieces about how assigning students to edit Wikipedia through Wiki Ed’s program provides much-needed media literacy skills for students.
• We announced a new Wikipedia Visiting Scholar, User:Czar, partnered with Smithsonian Libraries and the National Museum of African Art. Czar has already produced a number of high-quality articles about African art and artists.

Programs

Educational Partnerships

At this year’s annual meeting of the American Association for the Advancement of Science (AAAS), Boston played host to thousands of scientists, policy makers, and journalists. In a workshop at AAAS entitled “Mind the Gaps: Wikipedia as a Tool to Connect Scientists and the Public”, Greg Boustead of the Simons Foundation pointed out that the coverage of women scientists on Wikipedia is less complete than that of their male colleagues (and what coverage does exist tends to speak less about the significance of their contributions to science). When scientists assign their students to create biographies of women scientists, they aren’t engaging in activism; they’re merely working to ensure that the facts that are out there “speaking for themselves” are representative of reality. In the same workshop, LiAnna discussed the role that students can play in translating scientific knowledge into something that’s more understandable to general audiences.

LiAnna and Ian also joined attendees in the AAAS exhibit hall, where conversations about using Wikipedia’s platform to communicate science were lively. Mark Sarvary and Kelee Pacion also presented about their experience in our program in their class at Cornell.

As of February 28, we have brought 143 new courses into the Classroom Program for the spring 2017 term — 53 more than this time last year. The numbers prove our efforts to raise awareness about teaching with Wikipedia have been working, and we have been spent the month helping new instructors prepare their Wikipedia assignments.

Classroom Program

Status of the Classroom Program for Spring 2017 in numbers, as of February 28:

• 270 Wiki Ed-supported courses were in progress (126, or 47%, were led by returning instructors)
• 4,882 student editors were enrolled
• 58% were up-to-date with the student training
• Students edited 2,630 articles, created 93 new entries, and added 554,000 words.

As we approach the middle of the term, students are beginning to delve deeply into their Wikipedia assignments. They’re choosing articles to improve, drafting bibliographies, and making those first edits to Wikipedia’s main article space. We’re closing out February with 270 courses in progress, already just shy of the 276 we supported throughout all of last term. We expect to exceed our Fall 2016 record shortly, a feat we’re very proud of.

As more students engage in Wikipedia-based assignments, they have the chance to participate in the production of public knowledge, and in doing so become more adept consumers of knowledge as well. They take on the great responsibility that comes with contributing to Wikipedia, and have the chance to produce work with a lasting impact. At the same time, Wikipedia gets better coverage of topics ranging from immunology to Hawaiian linguistics, and from chemical engineering to Renaissance art.

In February, we again hosted Wiki Ed Office Hours. During this program, instructors were able to drop in and speak with members of the Wiki Ed staff about their Wikipedia assignments as well as learn what others are doing in the classroom. We’ll continue running this program throughout the term. This month, we also sent out the inaugural edition of the Wiki Ed Newsletter to both current and past program participants. Wiki Ed is engaged in a variety of programs, and we want to make sure that our instructors know about the many ways they can engage with us outside of the classroom. As the program continues to grow, we see the newsletter as a way to stay in touch with our instructors, even when they’re not teaching with Wikipedia, and to expand their involvement in the project of connecting Wikipedia and academia.

At the end of the month, Classroom Program Manager Helaine Blumenthal and Educational Partnerships Manager Jami Mathewson visited Dr. Amin Azzam’s class at the University of California, San Francisco. As Amin puts it, his group of fourth year medical students are uniquely positioned to contribute to Wikipedia. Their knowledge is robust, and they are still able to communicate their medical knowledge to a non-expert audience. As Helaine conveyed to the students, hundreds of millions of people go to Wikipedia on a monthly basis for medical information, so their contributions could potentially save lives. We’ve been working with Amin since Fall 2014, and we look forward to a continued partnership as we attempt to improve medical content on Wikipedia.

Student work highlights:

A zeotropic mixture is a mixture of components which have different boiling points. Separating these compounds through distillation is an important industrial application, and understanding the nature of these mixtures and their components is crucial for the design of the distillation columns used in the separation process. Before students in Elizabeth Nance’s Communication in Chemical Engineering class started working on it, Wikipedia’s zeotropic mixture article was short, saying little about the nature of zeotropic mixtures and almost nothing about their separation by distillation. A student in the class expanded the article substantially, adding not only sections on these topics but also ones on the use of zeotropic mixtures as refrigerants and cleaning solvents.

Another student in the class has been working on the capillary pressure article, which was surprisingly short before they started editing it. In addition to fleshing out the theory and equations of capillary pressure, the student also added applications both in the petrochemical industry and in natural processes, such as the formation of needle ice. Other students expanded a range of articles including those on inviscid flow, eddies, and the enthalpy of mixing. One student created a new article on minor losses in pipe flow.

Various insects have symbiotic relationships with fungi; many wood-boring insects, for example, depend on fungi to break down wood into something the insects can digest. Some of these carry their symbionts with them in a specialized structure called a mycangium. A student in Emily Sessa’s Principles of Systematic Biology class expanded the short article to add details about mycangia in a host of beetles and a group of wasps. They also added information about some of the types of fungi that insects carry in their mycangia.

Bats are the only mammals capable of true flight. Another student in the class created a stand-alone article on bat flight. The article discusses topics including the evolutionary origins of flight, and the relationship between wing morphology and the ecology of various species. Other students created articles about Euwallacea fornicatus, an ambrosia beetle that carries fungal spores with it in its mycangium, while others created articles about Amoebidium and Paramoebidium, a pair of genera of unicellular organisms formerly known as protists.

To many people, nanotechnology is something just this side of science fiction, dealing, as it does, with objects between 1 and 100 nanometers in size (or as little as a billionth of a meter). Students in Katherine Mirica’s Functional Nanomaterials class have been expanding articles in this area. One student expanded the nanofiber article, adding information about the history of nanofibers (they were first produced over 400 years ago), modern means of manufacture, and a range of applications including tissue engineering, drug delivery, cancer diagnosis, batteries, sensors, and air filtration. Nanobatteries are batteries made with of nanoscale particles. The existing Wikipedia article on this topic was expanded substantially by a student in the class, adding information about the advantages and disadvantages of nanotechnology in batteries as well as current and past research on the topic. Other students in the class created an article about the photolabile protecting group and made major additions to the articles on supramolecular polymers, molecular solids and 2D materials.

Community Engagement

Community Engagement Manager Ryan McGrady spent February working with several new and prospective Visiting Scholars and sponsoring institutions. Ryan worked with our partners at the Association for Women in Mathematics to review Visiting Scholars applicants who responded to our January call for applications. The response to the call was very strong, and as a result we are looking forward to working with two AWM Visiting Scholars, starting in March.

February also saw the announcement of a new Visiting Scholar with Smithsonian Libraries. User:Czar is a long-time Wikipedian with more than 70,000 contributions since 2005 and an impressive number of high-quality articles. One of the reasons we like the Wikipedia Visiting Scholars program so much is its ability to focus on a particular subject area on Wikipedia that needs improvement by forming a relationship between a Wikipedian and institution with shared interests. This is an excellent example of such a collaboration. Czar will be working with the Smithsonian Libraries and the National Museum of African Art to concentrate on African art and artists.

There are several examples of high-quality work from current Visiting Scholars this month:

University of Pittsburgh Visiting Scholar Barbara Page worked to bring the article about the Whiskey Rebellion, a tax protest in the United States beginning in 1791, up to Good Article status. It was also featured in the Did You Know section of Wikipedia’s Main Page with the fact “[Did you know] that only two men who participated in the Whiskey Rebellion were convicted of treason, but were later pardoned by President George Washington?” Barbara’s work on women’s health topics was also recognized in the Spring 2017 issue of Pitt Med magazine.

Another Did You Know this month came from Jackie Koerner, Visiting Scholar at San Francisco State University, who created an article about the Superfest International Disability Film Festival. Did you know “that the Superfest International Disability Film Festival is the longest-running disability film festival in the world?”

George Mason University Visiting Scholar Gary Greenbaum added another excellent Featured Article to his impressive list of work with the Coinage Act of 1965, which was promoted this month.

Finally, Czar, our newest Visiting Scholar, has already been very active in developing high-quality content. He worked to improve articles on Angolan photographer Edson Chagas and the National Museum of African Art, both of which reached B-class quality, and both of which are currently moving through the Good Article Nominations process.

Program Support

Communications

Working with media firm PR & Company, LiAnna did interviews with reporters from NPR and Pacific Standard, resulting in two major news pieces about how assigning students to edit Wikipedia through Wiki Ed’s program provides much-needed media literacy skills for students. The reporters also spoke to participating instructors in our program. The resulting press (especially the NPR article) was widely shared and resulted in several new instructors reaching out about potentially joining our program.

Helaine and Ryan put together the first edition of the Wiki Ed newsletter, sent to past and current program participants. The newsletter is a way to keep in touch with instructors, share news about the Dashboard, highlight student work or other successes, and communicate opportunities to connect with Wiki Ed or to get more involved in the community of people who understand that Wikipedia belongs in education. We look forward to sending out newsletters on a monthly basis moving forward.

Blog posts:

• Opening a can of bookworms (February 14)
• Join us at AAAS! (February 16)
• Students Illustrate and Explain Wikipedia’s Microbiology Articles (February 22)
• Monthly Report for January 2017 (February 23)
• Students, Sources, and Sentinels at AAAS (February 27)
• Introducing the Smithsonian Libraries Wikipedia Visiting Scholar (February 28)

External media:

• Wiki Woman, Christine Schauer and Sharon Blake, Pitt Med (Spring 2017)
• Students Bolster Wikipedia’s Pet Nutrition Content with Science, Stephanie Craig, University of Guelph (February 1, 2017)
• Students bolster Wikipedia pet nutrition content, Feedstuffs (February 3, 2017)
• How Wikipedia Is Cultivating an Army of Fact-Checkers to Battle Fake News, Jared Keller, Pacific Standard (February 13, 2017)
• What Students Can Learn By Writing For Wikipedia, Anya Kamenetz, NPR (February 22, 2017)
• What Students Can Learn By Writing For Wikipedia, Anya Kamenetz, WAMC (February 22, 2017)

Digital Infrastructure

In February, Product Manager Sage Ross kicked off an experimental grant-funded project with Agile Ventures, a nonprofit software development education community that focuses on building web applications for other nonprofits. With funding from a Wikimedia Foundation Rapid Grant, Sage is working with an Agile Ventures project manager to guide more new code contributors to the Dashboard development project and help them get started. The project will last for two months, with the goal of determining the potential for systematically working with the Agile Ventures community as a way to continue developing the Dashboard.

Intern Sejal Khatri continued her work on user profile pages, rolling out several major updates that bring better cumulative statistics along with customizable bios to the user profile pages. See Sage’s profile, for example. Sejal also added a new visualization to course pages: an edit size graph that shows the magnitude of each edit to an article. To see it in action, visit the Articles tab of a course, zoom in on one of the edited articles, and click ‘Article Development’.

We began beta testing a real-time chat feature on the Dashboard with a handful of classes. The feature will allow students and instructors to easily discuss their projects and ask or answer questions, and will be rolled out more widely once we fix the usability problems uncovered with the first few classes. As part of the preparation for this beta test, Sage also created a framework for enabling and disabling features on a course-by-course basis. This will make it easier to gradually roll out and test new features in the future, and may also be useful for A/B testing alternative features and conducting similar research.

Behind the scenes, we took the first steps connecting the Dashboard with Salesforce. This effort is aimed at streamlining the way Wiki Ed staff uses and updates course data, automating some of the necessary but tedious data curation tasks that help us track and analyze our programs and outreach efforts. Staff can now easily open a Salesforce record from the Dashboard, and up-to-date course data is automatically pushed to Salesforce on a regular basis.

User interface design work kicked off on the upcoming authorship highlighting feature in late February, which we hope to launch sometime in March. This is the first stage of a design sprint with Iván Cruz, the design lead during the Dashboard’s initial development. This design sprint is aimed at refining and polishing many of the features that have been developed in-house in the last year without a dedicated designer involved.

Research and Academic Engagement

During February, Research Fellow Zach McDowell and Research Assistant Mahala Stewart continued analyzing the research data. We have compiled numerous findings from the data, allowing us to connect with multiple researchers and potential conferences for dissemination purposes. In particular, there was significant evidence to support the case that students and instructors find Wikipedia-based assignments more valuable than traditional assignments for learning about writing for a general audience, learning about the reliability of online sources, and for learning digital literacy. Zach is in the midst of assembling a preliminary report to be released soon.

Zach has been collaborating with instructors Alexandria Lockett, Cecelia Musselman, Katherine Freedman, and Matthew Vetter on four different writing projects using Wiki Ed’s student learning outcomes data in various ways. Topics include digital literacy, skills transfer, writing contexts and attitudes, and digital citizenship. Zach is also working with another instructor, Joseph Reagle, to submit a proposal to the New Media Consortium summer conference.

Finance & Administration / Fundraising

Finance & Administration

Remote staff traveled to San Francisco to join local staff in a four-day All Staff meeting. We celebrated successes of the last four years, reviewed the learnings and accomplishments from the Year of Science initiative, and kicked off the annual planning process for next fiscal year. On the final day, staff visited The Crucible, an arts education center in Oakland, where they created clay sculptures.

For the month of February, expenses were $154,332 versus the approved budget of $181,390. The majority of the $27k variance continues to be due to staffing vacancies ($20k); as well as the timing of travel ($7k) expenses.

Our year-to-date expenses of $1,210,393 was also less than our budgeted expenditures of $1,588,364 by $378k. Like the monthly variance, the year-to-date variance was also impacted by staffing vacancies ($136k). In addition, there were timing and savings of expenditures within professional services ($76k); travel ($85k); marketing and cultivation events ($22k); board and all staff meeting ($44k); and printing ($17k) expenses.

Fundraising

In February, Tom Porter accepted a job offer from the Pacific Forest Trust and left Wiki Education. Tom has done a tremendous job, securing multiple grants for Wiki Ed and setting our organization’s fundraising efforts onto a good path for the future. We wish him well for the future.

Office of the ED

• Current priorities:

• Finding a replacement for Tom Porter
• Securing funding
• Developing the next annual plan

• In February, Frank started the process of re-filling the open development position. After the job description got posted, Frank reviewed applications and conducted a couple of first interviews with the most promising candidates.
• Frank also prepared an outline for a major programmatic campaign to start in the second half of calendar year 2017 and connected with a number of new prospects (both foundations and individuals) to investigate their level of interest in providing funding.
• Frank started preparing for the second round of the direct mail campaign (targeting high net-worth individuals) that Wiki Ed had started in late 2016.
• Also in February, Frank started work on streamlining the process for organizing Wiki Ed’s in-person board meetings.
• Frank had an initial meeting with board member Ted Yang for preparing the next iteration of Wiki Ed’s strategic planning process that’s expected to start in the second half of 2017.

Visitors and guests

• None

I was recently interviewed by Luciana Lima for an story about FOMO in Brazil's Você S/A ("Tudo ao mesmo tempo agora," March 2017). The story is print only, and in Portuguese, so I asked to include the original interview here; we are discussing my article "Following the Joneses: FOMO and Conspicuous Sociality."

In your article you say that the FOMO is a new word for an old concept and that the media has an important role in the construction of this terminology. Why does it happen?

"Social comparison" is a core feature of human behavior: we look to others to discern how we are doing and what we should do. Popular media changed the scope of our social comparison from our neighborhood to images on pages and screens. It's hard to compare yourself to the polished images seen in ads and among celebrities. Social media amplifies this.

You also state that FOMO and FOBO are opposing forces that can drive the person into a state called FODA. Could you explain a little more about what this third stage would be?

Patrick McGinnis coined all these terms in 2004 in response to the intense social and professional networking scene at Harvard Business School. Whereas FOMO ("Fear of Missing Out") leads to anxiety about missing something, FOBO ("Fear of Better Options") is the fear of committing to something in case something better came along. McGinnis lamented that all of this ultimately leads to FODA ("Fear of Doing Anything").

You claim that people mistakenly associate FOMO exclusively with social networks. Could we say that there is a human predisposition to blame technology for their bad behavior?

Social comparison is innate to being human; media and technology can lead to distortions, but FOMO is a very human phenomenon.

You also affirm that in the contemporary eye wanting what we see and being seen has fused. Would that not be pure vanity? And are they not two things that have always completed each other?

I believe the term FOMO conflates two distinct feelings: missed experiences (fear of missing out) and belonging (fear of being left out): to want what we see and to be seen have fused. Lone envy and social exclusion are both facilitated by ubiquitous screens.

Don't you believe that having more access to the other's daily life (trips, parties, restaurants, relationships) intensifies the envy we already felt? And that maybe this was a new modality, different from the one our parents could feel, for example?

I think the feeling is the same, media simply changes its circumstances, like its intensity and how often it occurs.

Is FOMO also just related to envy? Or is there a correlation with low self-esteem, for example?

You are right, social comparison, the behavior that drives envy, is also a factor in self-esteem.

Finally you say that the FOMO is related to a fear of "disappearing" and that it should be understood as a continuation of centenary issues. What would this "disappear" be and what are the issues that are closely related to it?

Here I was speaking about the term "FOMO" itself. Fear and envy have always been around; but, in the past two centuries, things like the telegraph and television led to people to speak about the malady of neurasthenia and the anxiety of "keeping up with the Joneses." So I wonder how long "FOMO" will stick around, or will it one day disappear and be replaced by a new term or expression?

International Fact Checking Day is April 2, 2017 — and we at Wiki Education have joined the initiative! We encourage you to participate by helping check facts on Wikipedia.

Participating is easy:

1. Log in to your Wikipedia account.

2. Go to the Citation Hunt tool. This will give you a sentence from a Wikipedia article with the dreaded “Citation Needed” tag.

3. Do some research to determine if the sentence in question is accurate according to sources.

4. If it is not accurate, click the “Edit” button on the section, delete the fact in question, and put in your edit summary, “Remove uncited claim I cannot find literature to support #FactCheckIt” — or edit the sentence to be true, and then follow step #5.

5. If it is accurate, find a source that meets Wikipedia’s Reliable Sources guidelines. Click the “edit” button on the section where the fact is listed, then click “Cite” and follow the directions to cite a source. Save the page. When you’re prompted to add an edit summary, say “Added citation #FactCheckIt”.

Adding the #FactCheckIt hashtag will enable us to track the impact of this initiative — so be sure to include it!

Feel free to repeat the steps to add more citations to facts. While we encourage you to participate specifically on April 2, facts can be updated any time, so don’t feel restricted to just participating then.

For more events related to International Fact Checking Day, visit http://factcheckingday.com/.

Photo by Alchemist-hp, Free Art License 1.3.

In the eighth grade, I was introduced to the new subject of chemistry. Most my classmates found it incredibly difficult, while I found it easy. My problem was that the next step up were university textbooks, which I couldn’t handle at the moment.

Instead, I gradually turned to Wikipedia to obtain the knowledge I wanted. Eventually, I realized that I could write Wikipedia articles, to give back to the site I’d taken so much from. I’d still be learning, but I’d also be helping anyone in a similar position to where I was.

I chose to take a narrow scope to my contributing: the elements of the periodic table. These form a set of articles that can be reasonably taken on—not finished by just one person, of course, but some tangible progress could be made by one.

And, of course, elements are the building blocks that, when combined, constitute the full diversity of chemistry. That made the choice clear.

Photo by Alchemist-hp, Free Art License 1.3.

I’m from Russia, so I first tried to break into the Russian Wikipedia, but I found it difficult to collaborate with the editors there. So I instead decided to move to the English Wikipedia, as I’d been wanting to improve my English anyway. Moreover, the English site had an entire “wikiproject” dedicated just to the elements.

I chose fluorine as my first article-project because I thought it would be the easiest one. It only assumes only one oxidation state in its compounds, was not a major influence on history or industry (like, say, iron or oxygen), and was in pretty bad condition.

I finished the article in January 2011, and nominated it for “featured article” (FA)—a quality marker reserved for Wikipedia’s best work—status in April. As it turned out, I was wrong about how easy it would be, as the nomination failed. Still, it wasn’t all bad: the article had gained some support, and I gained a lot of knowledge about how to write Wikipedia articles. A lot of that came from TCO.

TCO was a great editor to get in contact with. I can’t thank him enough for giving so much of his time. He certainly delayed my attempts to get the article featured, but he also offered a lot—and that turned out to be a far better thing. Part of what he had for me was a new understanding of the importance of things and how I needed to do work beyond was needed for that “featured” status. This would allow to have the star and enjoy the great article I’ve produced. That’s not to say I didn’t want to write great articles, but there were moments when you think, “aah, it’ll pass the FA review anyway, they won’t notice.”

Nowadays, I’ve become my own measure of quality. It was that that mattered most, not the stars. This didn’t happen too quickly. I nominated fluorine for featured article again, albeit somewhat prematurely, in September. More and more work was being put into it, and I was becoming more and more disillusioned with it, so I’ve decided to diversify my work.

Photo by Tmv23 and Dblay, CC BY-SA 3.0.

I produced a number of GAs, two of which became so complete by the time I submitted them that I decided keep going and aim for FA as well. I had dove into the interesting topics of heavy and superheavy elements, producing a good, detailed, and Soviet-styled (as I based it on a Soviet book) article on astatine, plus a nice short beautiful article on ununseptium (now tennessine), which only lacked one thing—prose quality. Had it not been for this, we would’ve gotten it on the first try; but it had, and we didn’t.

But soon enough I entered university in 2013 and immediately lost most of my free time. This made rewriting Wikipedia articles rather difficult. Eventually, with lots of work put into them, all three articles ended up as FAs in late 2014 and 2015. But this happened only after TCO’s influence hit me one more time.

Back in 2011, TCO wrote a report titled “Improving Wikipedia’s Important Articles,” which advocated for focusing Wikipedia’s editors on vital topics, ones read by the most people. While panned by other editors at the time, I discovered it in 2014 and believe that it’s an absolutely great masterpiece. When writing ununseptium back in 2011–12, I tried to write it in a way that was fascinating but accessible. This challenge helped hook me into editing Wikipedia. You need to be immerse yourself in the topic, but you also need to make sure you’re delivering the information you’ve learned in a way that others can understand. Reading TCO’s report helped galvanize just how important this is.

Sadly, TCO left Wikipedia a few months before fluorine got its featured article star. The article would’ve gotten the star far earlier if it wasn’t for him, but it wouldn’t be as good, either. Besides, this taught me about writing articles in general and changed my perception of the topics I write about.

Photo by Alchemist-hp and Richard Bartz, CC BY-SA 3.0.

I was mostly inactive in 2015–16, though able to help with a few other projects like thorium, with User:Double sharp. In 2016, I decided to go for an important article once again. Wikipedia’s readers have been the top priority for a long time for me now, and after all I’ve been through, it didn’t only matter how I serve the information on the topic I’ve chosen, but also how I choose the topic.

So, I started work on lead, a good choice indeed. Never would I think an element could be so interesting in human life and so important in history. I’ve absolutely enjoyed that and want to go on. After it’s done, it will be aluminium, iron, and—if I ever to get to it—gold.

I may even go further after that, picking an even more important article, not even necessarily about chemistry. I’m currently considering rewriting the article on the continent of Europe, but it’s still so far away I can’t tell if this will ever happen.

But I definitely want it to.

Mikhail Boldyrev (User:R8R Gtrs), Wikipedian

Last week, I had the privilege of traveling to São Paulo, Brazil, giving two presentations at the University of São Paulo (USP), meeting with the Grupo de Usuários Wikimedia no Brasil (Wikimedia Brasil User Group), and attending a neuroscience and mathematics edit-a-thon for the Portuguese Wikipedia.

The group in Brazil is already having an incredible impact on Wikipedia. In particular, a group of Wikimedians based at USP’s Research, Innovation and Dissemination Center for Neuromathematics (RIDC NeuroMat), led by Professor João Alexandre Peschanski, has dramatically improved information available on the Portuguese Wikipedia on topics in neuroscience and mathematics. With a grant funded by São Paulo Research Foundation (FAPESP), they’re working hard to bring more science information to the Portuguese Wikipedia. For example, check out the Portuguese Wikipedia article on the mathematical term average, which includes extensive written content added through their work — as well as animated illustrations of concepts and a sound file of the article read aloud, to make it easier for people with vision impairments who speak Portuguese to understand mathematical formulas. João, Celio Costa Filho, David Alves, and the rest of the team at NeuroMat have long been engaged in our work as well, translating many Wiki Ed blog posts for their blog.

Thanks to travel funding from FAPESP, I was able to come give two talks about connecting Wikipedia and academia at USP. The first was an informal talk to students, professors, Wikipedians, and other people interested in what we at Wiki Education are doing to connect Wikipedia and academia. We spent some time talking about how our program works, the importance of media literacy skills in the digital age, and more. I encouraged attendees to get involved in the Wikimedia movement, whether through editing articles, adding photos to Commons, translating articles, or playing the WikiData game. The result of this first meeting is that one of the two journalists who attended the talk has already published an interview with me in Carta Educação, and a Brazilian Wikipedian in the room was inspired to create the article on media literacy on the Portuguese Wikipedia.

For the second talk, representatives from the Research, Information, and Dissemination Centers of FAPESP attended to hear more specifically about Wiki Ed’s Year of Science initiative. Many attendees were not very familiar with the inner workings of Wikipedia, so it was an excellent opportunity to explain more about how Wikipedia works, the community involved in it, why it’s something worth contributing to, why Wiki Ed’s participating professors see Wikipedia assignments as key for teaching media literacy and science communication, and what we did during the Year of Science. In particular, I encouraged the group to work toward engaging with Wikipedia in hopes of seeing a Year of Science in Brazil in the coming years.

I was incredibly inspired by the enthusiasm and energy of the Wikimedians in Brazil, and I am confident that good things will continue to come from this group in the future! Many thanks to João and the rest of the team for inviting and welcoming me to Brazil!

Image: Wiki Edu presentation and the 3rd Neurociência e Matemática edit-a-thon (08), by RIDC NeuroMat, CC BY 4.0, via Wikimedia Commons.

Photo by Mikey Tnasuttimonkol, CC BY-SA 4.0.

We are happy to announce EventStreams, a new public service that exposes live streams of Wikimedia events.  And we don’t mean the next big calendar event like the Winter Olympics or Wikimania.  Here, an ‘event’ is defined to be a small piece of data usually representing a state change. An edit of a Wikipedia page that adds some new information is an ‘event’, and could be described like the following:

{
'event-type': 'edit',
'page': 'Special Olympics',
'project': 'English Wikipedia',
'time': '2017-03-07 09:31',
'user': 'TheBestEditor'
}

This means: “a user named ‘TheBestEditor’ added some content to the English Wikipedia’s Special Olympics page on March 7, 2017 at 9:31am”.

While composing this blog post, we sought visualizations that use EventStreams, and found some awesome examples.

Open now in Los Angeles, DataWaltz is a physical installation that “creates a spatial feedback system for engaging with Wikipedia live updates, allowing visitors to follow and produce content from their interactions with the gallery’s physical environment.” You can see a photo of it at the top, and a 360 video of it over on Vimeo.

Sacha Saint-Leger sent us this display of real-time edits on a rotating globe, showing off where they are made.

Ethan Jewett created a really nice continuously updating chart of edit statistics.

A little background—why EventStreams?

EventStreams is not the first service from Wikimedia to expose RecentChange events as a stream. irc.wikimedia.org and RCStream have existed for years.  These all serve the same data: RecentChange events.  So why add a third stream service?

Both irc.wikimedia.org and RCStream suffer from similar design flaws.  Neither service can be restarted without interrupting client subscriptions.  This makes it difficult to build comprehensive tools that might not want to miss an event, and hard for WMF engineers to maintain. They are not easy to use, as services require several programming setup steps just to start subscribing to the stream.  Perhaps more importantly, these services are RecentChanges specific, meaning that they are not able to serve different types of events. EventStreams addresses all of these issues.

EventStreams is built on the w3c standard Server Sent Events (SSE).  SSE is simply a streaming HTTP connection with event data in a particular text format.  Client libraries, usually called EventSource, assist with building responsive tools, but because SSE is really just HTTP, you can use any HTTP client (even curl!) to consume it.

The SSE standard defines a Last-Event-ID HTTP header, which allows clients to tell servers about the last event that they’ve consumed.  EventStreams uses this header to begin streaming to a client from a point in the past.  If EventSource clients are disconnected from servers (due to network issues or EventStreams service restarts), they will send this header to the server and automatically reconnect and begin from where they left off.

EventStreams can be used to expose any useful streams of events, not just RecentChanges.  If there’s a stream you’d like to have, we want to know about it.  For example, soon ORES revision score events may be exposed in their own stream.  The service API docs have an up to date list of the (currently limited) available stream endpoints.

We’d like all RecentChange stream clients to switch to EventStreams, but we recognize that there are valuable bots out there running on irc.wikimedia.org that we might not be able to find the maintainers of.  We commit to supporting irc.wikimedia.org for the foreseeable future.

However, we believe the list of (really important) RCStream clients is small enough that we can convince or help folks switch to EventStreams.  We’ve chosen an official RCStream decommission date of July 7 this year.  If you run an RCStream client and are reading this and want help migrating, please reach out to us!

Quickstart

EventStreams is really easy to use, as shown by this quickstart example in JavaScript.  Navigate to http://wikimedia.org in your browser and open the development console (for Google Chrome: More Tools > Developer Tools, and click ‘console’ on the bottom screen, which should open on the browser below the page you are visiting). Then paste the following:

// This is the EventStreams RecentChange stream endpoint
var url = 'https://stream.wikimedia.org/v2/stream/recentchange';

// Use EventSource (available in most browsers, or as an
// npm module: https://www.npmjs.com/package/eventsource)
// to subscribe to the stream.
var recentChangeStream = new EventSource(url);

// Print each event to the console
recentChangeStream.onmessage = function(message) {

//Parse the message.data string as JSON.
var event = JSON.parse(message.data);
console.log(event);

};

You should see RecentChange events fly by in your console.

That’s it!   The EventStreams documentation has in depth information and usage examples in other languages.

If you build something, please tell us, or add yourself to the Powered By EventStreams wiki page.  There are already some amazing uses there!

Andrew Otto, Senior Operations Engineer, Analytics
Wikimedia Foundation