In January 2022 I published a new Wikimedia tool called WikiCrowd.

This tool allows people to answer simple questions to contribute edits to Wikimedia projects such as Wikimedia Commons and Wikidata.

It’s designed to be able to deal with a wide variety of questions, but due to time constraints, the extent of the current questions covers Aliases for Wikidata, and Depict statements for Wikimedia Commons.

The tool has just surpassed 55k questions, 50k answers, 32k edits and 75 users.

Thanks to @pmgpmgpmgpmg (Twitter, Github) and @waldyrious (Twitter, Github) for their sustained contributions to the project filling issues as well as contributing code and question definitions.

User Leaderboard

Though I haven’t implemented a leaderboard as part of the tool, the number of questions answered, and resulting edits are tracked in the backend.

Thus, of the 50k answers, we can take a look at who contributed to the crowd!

1. PMG: 35,581 answers resulting in 21,084 edits at a 59% edit rate
2. I dream of horses: 4543 answers resulting in 3184 edits at a 70% edit rate
3. Tiefenschaerfe: 3749 answers resulting in 3207 edits at an 85% edit rate
4. Addshore: 3049 answers resulting in 2133 edits at a 69% edit rate
5. OutdoorAcorn: 708 answers resulting in 526 edits at a 74% edit rate
6. Waldyrious: 443 answers resulting in 310 edits at a 69% edit rate
7. Fences and windows: 409 answers resulting in 242 edits at a 59% edit rate
8. Amazomagisto: 328 answers resulting in 211 edits at a 64 % edit rate

Thanks to all of the 75 users that have given the tool a go in the past months.

Answer overview

• Yes is the favourite answer with 32,192 occurrences
• No comes second with 13,473 occurrences
• And a total of 3,818 questions were skipped altogether

In the future skipped questions will likely be presented to a user a second time.

Question overview

Depicts questions have by far been the most popular, and also the easiest to generate more interesting groups of questions for.

• 48,236 Depicts questions
• 776 Alias questions
• 471 Depicts refinement questions

The question mega groups were split into subgroups.

• Depicts has had 45 different things that could be depicted
• Aliases can be added from 3 different language Wikipedias
• Depicts refinement has been used on 19 of the 45 depicted things

Question success rate

Some questions are harder than others, and some questions have better filtering in terms of candidate answers than others.

For this reason, I suspect that some questions will have a much higher success rate, than others, and some with more skips.

At a high level, the groups of questions have quite different yes rates.

• Depicts: 65% yes, 27% no, 8% skip
• Alias: 54% yes, 23% no, 21% skip
• Depicts refinement: 95% yes, 2% no, 2% skip

If we take a deeper dive into the depict questions, we can probably see some depictions that are hard to spot or commons categories that possibly include a wider variety of media around a core subject.

An example of this would be categories for US presidents that also include whole categories for election campaigns, or demonstrations, neither of which would normally feature the president.

The % rate of yes answers could be used to decide the ease of questions allowing some users to pick harder categories, or forcing new users to try easy questions first.

As question generation is tweaked, particularly for depicts questions where categories can be excluded, we should also see the yes % change over time. Slowly tuning question generation to get to a 80% yes range could be fun!

Of course, none of this is implemented yet ;)…

Queries behind this data

Just in case this needs to be generated again, here are the queries used.

For the user leader boards…

Code language: PHP (php)

And the question yes rate data came from the following query and a pivot table…

Code language: PHP (php)

Looking forward

Come and contribute, code, issues or ideas on the Github repo.

Next blog post at 100k? Or maybe now that there are cron jobs for question generation (people don’t have to wait for me) 250k is a more sensible next step.

The post WikiCrowd at 50k answers appeared first on addshore.

Over here in the Release-Engineering-Team, Train Deployment is usually a rotating duty. We've written about it before, so I won't go into the exact process, but I want to tell you something new about it.

It's awful, incredibly stressful, and a bit lonely.

And last week we ran an experiment where we endeavored to perform the full train cycle four times in a single week... What is wrong with us? (Okay. I need to own this. It was technically my idea.) So what is wrong with me? Why did I wish this on my team? Why did everyone agree to it?

First I think it's important to portray (and perhaps with a little more color) how terrible running the train can be.

How it usually feels to run a Train Deployment and why

Here's a little chugga-choo with a captain and a crew. Would the llama like a ride? Llama Llama tries to hide.

―Llama Llama, Llama Llama Misses Mama

At the outset of many a week I have wondered why, when the kids are safely in childcare and I'm finally in a quiet house well fed and preparing a nice hot shower to not frantically use but actually enjoy, my shoulder is cramping and there's a strange buzzing ballooning in my abdomen.

Am I getting sick? Did I forget something? This should be nice. Why can't I have nice things? Why... Oh. Yes. Right. I'm on train this week.

Train begins in the body before it terrorizes the mind, and I'm not the only one who feels that way.

A week of periodic drudgery which at any moment threatens to tip into the realm of waking nightmare.

―Stoic yet Hapless Conductor

Aptly put. The nightmare is anything from a tiny visual regression to taking some of the largest sites on the Internet down completely.

Giving a presentation but you have no idea what the slides are.

―Bravely Befuddled Conductor

Yes. There's no visibility into what we are deploying. It's a week's worth of changes, other teams' changes, changes from teams with different workflows and development cycles, all touching hundreds of different codebases. The changes have gone through review, they've been hammered by automated tests, and yet we are still too far removed from them to understand what might happen when they're exposed to real world conditions.

It's like throwing a penny into a well, a well of snakes, bureaucratic snakes that hate pennies, and they start shouting at you to fill out oddly specific sounding forms of which you have none.

―Lost Soul been 'round these parts

Kafkaesque.

When under the stress and threat of the aforementioned nightmare, it's difficult to think straight. But we have to. We have to parse and investigate intricate stack traces, run git blames on the deployment server, navigate our bug reporting forms and try to recall which teams are responsible for which parts of the aggregate MediaWiki codebase we've put together which itself is highly specific to WMF's production installation and really only becomes that long after changes merge to main branches of the constituent codebases.

We have to exercise clear judgement and make decisive calls of whether to rollback partially (previous group) or completely (all groups to previous version). We may have to halt everything and start hollering in IRC, Slack channels, mailing lists, to get the signal to the right folks (wonderful and gracious folks) that no more code changes will be deployed until what we're seeing is dealt with. We have to play the bad guys and gals to get the train back on track.

Trainsperiments Week and what was different about it

Study after study shows that having a good support network constitutes the single most powerful protection against becoming traumatized. Safety and terror are incompatible. When we are terrified, nothing calms us down like a reassuring voice or the firm embrace of someone we trust.

―Bessel Van Der Kolk, M.D., The Body Keeps the Score

Four trains in a single week and everyone in Release Engineering is onboard. What could possibly be better about that?

Well there is a safety in numbers as they say, and not in some Darwinistic way where most of us will be picked off by the train demons and the others will somehow take solace in their incidental fitness, but in a way where we are mutually trusting, supportive, and feeling collectively resourced enough to do the needful with aplomb.

So we set up video meetings for all scheduled deployment windows, had synchronous hand offs between our European colleagues and our North American ones. We welcomed folks from other teams into our deployments to show them the good, the bad, and the ugly of how their code gets its final send off 'round the bend and into the setting hot fusion reaction that is production. We found and fixed longstanding and mysterious bugs in our tooling. We deployed four full trains in a single week.

And it felt markedly different.

One of those barn raising projects you read about where everybody pushes the walls up en masse.

―Our Stoic Now Softened but Still Sardonic Conductor

Yes! Lonely and unwitnessed work is de facto drudgery. Toiling safely together we have a greater chance at staving off the stress and really feeling the accomplishment.

Giving a presentation with your friends and everyone contributes one slide.

―Our No Longer Befuddled but Simply Brave Conductor

Many hands make light work!

It was like throwing a handful of pennies into a well, a well of snakes, still bureaucratic and shouty, oh hey but my friends are here and they remind me these are just stack traces, words on a screen, and my friends happen to be great at filling out forms.

―Our Once Lost Now Found Conductor

When no one person is overwhelmed or unsafe, we all think and act more clearly.

The hidden takeaways of Trainsperiment Week

So how should what we've learned during our Trainsperiment Week inform our future deployment strategies and process. How should train deployments change?

The known hypothesis we wanted to test by performing this experiment was in essence:

1. More frequent deployments will result in fewer changes being deployed each time.
2. Fewer changes on average means the deployment is less likely to fail. The deployment is safer.
3. A safer deployment can be performed more frequently. (Positive feedback loop to #1.)
4. Overall we will: move faster; break less.

I don't know if we've proved that yet but we got an inkling that yes, the smaller subsequent deployments of the week did seem to go more smoothly. One week, however, even a week of four deployment cycles is not a large enough sample to say definitively whether doing train more frequently will for sure result in safer, more frequent deployments with fewer failures.

What was not apparent until we did our retrospective, however, is that it simply felt easier to do deployments together. It was still a kind of drudgery, but it was not abjectly terrible.

My personal takeaway is that a conductor who feels resourced and safe is the basis for all other improvements to the deployment process, and I want conductors to not only have tooling that works reliably with actionable logging at their disposal, but to feel a sense of community there with them when they're pushing the buttons. I want them to feel that the hard calls of whether or not to halt everything and rollback are not just their calls but shared in the moment among numerous people with intimate knowledge of the overall MediaWiki software ecosystem.

Better tooling—particularly around error reporting and escalation—is a barrier to entry for sure. Once we've made sufficient improvements there we need to get that tooling into other people's hands and show them that this process does not have to be so terrifying. And I think we're on the right track here with increased frequency and smaller sets of changes, but we can't lose sight of the human/social element and foundational basis of safety.

More than anything else, I want wider participation in the train deployment process by engineers in the entire organization along with volunteers.

Thanks to @thcipriani for reading my drafts and unblocking me from myself a number of times. Thanks to @jeena and @brennen for the inspirational analogies.

Today I was in a Wikibase Stakeholder group call, and one of the discussions was around Wikibase importing speed, data loading, and the APIs. My previous blog post covering what happens when you make a new Wikibase item was raised, and we also got onto the topic of profiling.

So here comes another post looking at some of the internals of Wikibase, through the lens of profiling on test.wikidata.org.

The tools used to write this blog post for Wikimedia infrastructure are both open source, and also public. You can do similar profiling on both your own Wikibase, or for your requests that you suspect are slow on Wikimedia sites such as Wikidata.

Wikimedia Profiling

Profiling of Wikimedia sites is managed and maintained by the Wikimedia performance team. They have a blog, and one of the most recent posts was actually covering profiling PHP at scale in production, so if you want to know the details of how this is achieved give it a read.

Throughout this post I will be looking at data collected from a production Wikimedia request, by setting the X-Wikimedia-Debug header in my request. This header has a few options, and you can find the docs on wikitech.wikimedia.org. There are also browser extensions available to easily set this header on your requests.

I will be using the Wikimedia hosted XHGui to visualize the profile data. Wikimedia specific documentation for this interface also exists on wikitech.wikimedia.org. This interface contains a random set of profiled requests, as well as any requests that were specifically requested to be profiled.

Profiling PHP & MediaWiki

If you want to profile your own MediaWiki or Wikibase install, or PHP in general, then you should take a look at the mediawiki.org documentation page for this. You’ll likely want to use either Tideways or XDebug, but probably want to avoid having to setup any extra UI to visualize the data.

This profiling only covered the main PHP application (MediaWiki & Wikibase extension). Other services such as the query service would require separate profiling.

Making a profiled request

On test.wikidata I chose a not so random item (Q64) which happens to be a small version of the item for Berlin on Wikidata. It has a bunch of labels and a couple of statements.

I made a few modifications including removing the ID and changing all labels to avoid conflicts with the item that I had just copied and came up with some JSON ready to feed back into the API.

I navigated to the API sandbox for test.wikidata.org, and setup a request using wbeditentity which would allow me to create a fresh item. The options look something like this:

• new = item
• token = <Auto-fill the token using the UI button>
• data = <json data that I am using to create an item>

With the XHGui option selected in the WikimediaDebug browser extension, I can hit the “Make request” button and should see my item created. The next page will also output the full runtime of the request from the client perspective, in this case roughly 3.6 seconds.

Finding the request in XHGui

Opening up XHGui I should find the POST request that I just made to test.wikidata somewhere near the top of the list of profiled requests.

Clicking on the Time column, the details page of the profiled request will load. You can find my request, id 61fc06c1fe879940dbdf4a38 (archive URL just in case).

Profiling overview

There are lots of gotchas when it comes to reading a profile such as this:

• The fact that profiling is happening will generally make everything run slower
• Profiling tends to overestimate the cost of calling functions, so small functions called many times will appear to look worse than they actually are
• When IO is involved, such as caching (if the cache is cold), database writes, relying on the internet, or external services, any number of things can cause individual functions to become inflated
• It’s hard to know what any of it means, without knowing what the classes and methods are doing

Next let’s look at some terms that it makes sense to understand:

• Wall time: also called real-world time, is the actual time that a thing has taken to run. This includes things such as waiting for IO, or your CPU switching to low power mode.
• CPU time: also called process time, is the ammount of time the CPU actaully spent processing instructions, excluding things such as time spent waiting for IO.
• Self: also called exclusive, covers the resources spent in the function itself, excluding time spent in children.
• Inclusive: covers the resources inclusive of all children

You can read some more about different types of time and inclusivity in profiling on the Time docs for blackfire.io.

Reading the profile

The full wall time of the request is 5,266,796 µs, or 5.2 seconds. This is significantly more than we saw from the perspective of the client making the API request. This is primarily because of the extra processing that MediaWiki and Wikibase does after sending a response back to the user.

The full CPU time of the request is 3,543,361 µs, or 3.5 seconds. We can infer from this that the request included roughly 1.7 seconds of time not doing computations. This could be waiting for databases, or other IO.

We can find likely candidates for this 1.7 seconds of time spent not computing by looking at the top of the function breakdown for wall time, and comparing CPU time.

The 4 methods above have a combined difference between wall and CPU time of 1.5s, which accounts for most of the 1.7s we were looking for. The most expensive method call here is actually the single call to GuzzleHttp\Handler\CurlHandler::__invoke which spends 0.3s waiting, as all of the other methods are called many other times. On average Wikimedia\Rdbms\DatabaseMysqli::doQuery only spends 0.001s per method call in this request.

GuzzleHttp\Handler\CurlHandler::__invoke

Lets have a closer look at this GuzzleHttp\Handler\CurlHandler::__invoke call. We have a few options to see what is actually happening in this method call.

1. Click on the method to see the details of the call, navigate up through the parents to find something that starts to make some sense
2. Use the callgraph view (only shows methods that represent more than 1% of execution time)

I’ll choose number 2, and have included a screenshot of the very tall call graph for this method to the right.

At the top of this call we see MediaWiki\SyntaxHighlight\Pygmentize::highlight, which I was not expecting in such an API call.

Another level up we see WANObjectCache::fetchOrRegenerate which means that this was involved in a cache miss, and this data was regenerated.

Even further up the same tree I see SyntaxHighlight::onApiFormatHighlight.

This method is part of the SyntaxHighlight extension, and spends some time making the output of the API pretty for users in a web browser.

So what have I learnt here? Don’t profile with jsonfm. However using the API sandbox you don’t get this option, and thus bug T300909 was born.

Callgraph overview

Having the callgraph open we can see some of the most “expensive” methods in terms of inclusive wall time. You can also find these in the table view by sorting using the headings.

main() represents the bulk of the MediaWiki request (5.2s). This is split into ApiMain::execute taking ~3.4 seconds, and MediaWiki::doPostOutputShutdown taking ~1.7 seconds.

ApiMain::execute

This is where the “magic happens” so to speak. ~3.4 seconds of execution time.

The first bit of Wikibase code you will see in this call graph path is Wikibase\Repo\Api\ModifyEntity::execute. This is the main execute method in the base class that is used by the API that we are calling. Moving to this Wikibase code we also lose another ~0.4 seconds due to my syntax highlighting issue that we can ignore.

Taking a look at the next level of methods in the order they run (roughly) we see most of the execution time.

In the context of the Wikibase stakeholder group call I was in today that was talking about initial import speeds, and general editing speeds, what could I say about this?

• Why spend 0.3 seconds of an API call checking permissions? Perhaps you are are doing your initial import in a rather “safe” environment. Perhaps You don’t care about all of the permissions that are checked?
• Permissions are currnetly checked in 3 places for this call. 1) upfront 2) if we need to create a new item 3) just before saving. In total this makes up ~0.6 seconds according to the profiling.
• Putting the formed PHP Item object into the database actually only takes ~0.15 seconds.
• Checking the uniqueness of of labels and descriptions takes up ~1.2 seconds of validation of ChangeOps. Perhaps you don’t want that?

MediaWiki::doPostOutputShutdown

This is some of the last code to run as part of a request.

The name implies it, but to be clear this PostOutputShutdown method runs after the user has been served with a request. Taking a look back at the user-perceived time of 3.6 seconds, we can see that the wall time of the whole request (5.2s) minus this post output shutdown (1.7s) is roughly 3.5 seconds.

In relation to my previous post from the point of view of Wikibase, this is when most secondary data updates will happen. Some POST SEND derived data updates also happen in this step.

Closing

As I stated in the call, Wikibase was created primarily with the usecase of Wikidata in mind. There was never a “mass data load” stage for Wikidata requiring extremely high edit rates in order to import thoughts or millions of items. Thus interfaces and internals do not tend to this usecase and optimizations or configurations that could be made have not been made.

I hope that this post will trigger some questions around expensive parts of the editing flow (in terms of time) and also springboard more folks into looking at profiling of either Wikidata and test.wikidata, or their own Wikibase installs.

For your specific use case you may see some easy wins with what is outlined above. But remember that this post and specific profiling is only the tip of the iceberg, and there are many other areas to look at.

The post Profiling a Wikibase item creation on test.wikidata.org appeared first on addshore.

I don’t use git-review for Gerrit interactions. This is primarily because back in 2012/2013 I couldn’t get git-review installed, and someone presented me with an alternative that worked. Years later I realized that this was actually the documented way of pushing changes to Gerrit.

As a little introduction to what this workflow looks, and a comparison with git-review I have created 2 overview posts altering a gerrit change on the Wikimedia gerrit install. I’m not trying to convince you, either way, is better, merely show the similarities/difference and what is happening behind the scenes.

Be sure to take a look at the other post “Altering a Gerrit change (git-review workflow)“

I’ll be taking a change from the middle of last year, rebasing it, making a change, and pushing it back for review. Fundamentally the 2 approaches do the same thing, just one (git-review) requires an external tool.

1) Rebase

Firstly I’ll rebase the change by clicking the “Rebase” button in the top right of the UI. (But this step is entirely optional)

This will create a second patchset on the change, automatically rebase on the master branch if possible. (Or it would tell you to rebase locally).

2) Checkout

In order to checkout the change I’ll use the “Download” button on the right of the change near the changed files.

A dialogue will appear with a bunch of commands that I can copy depending on what I want to do.

As I want to alter the change in place, I’ll use the “Checkout” link.

This will fetch the ref/commit, and then check it out.

3) Change

I can now go ahead and make my change to the commit in my IDE.

The change is quite small and can be seen in the diff below.

Now I need to amend the commit that we fetched from gerrit.

If I want to change to commit message in some way I can do git commit --all --amend

If there is no need to change the commit message you can also pass the --no-edit option.

You’ll notice that we are still in a detached state, but that doesn’t matter too much, as the next step is pushing to gerrit, and once that has happened we don’t need to worry about this commit locally.

4) Push

In order to submit the altered commit back to gerrit, you can just run the following command

The response of the push will let you know what has happened, and you can find the URL back to the change here.

A third patchset now exists on the change on Gerrit.

Overview

The whole process looks like something like this.

1. A commit already exists on Gerrit that is currently up for review
2. Clicking the rebase button will rebase this commit on top of the HEAD of the branch
3. Fetching the commit will bring that commit on to your local machine, where you can now check it out
4. Making a change and ammending the commit, will create a new commit locally
5. You can then push this altered commit back to gerrit for review

If you want to know more about what Gerrit is doing, you can read the docs on the “gritty details”

Git aliases

You can use a couple of git aliases to avoid some of these slightly long commands

And you can level these up to provide you with a little more flexibility

Code language: JavaScript (javascript)

You can read more about my git aliases in a previous post.

The post Altering a Gerrit change (git workflow) appeared first on addshore.

Other languages: Bahasa Indonesia, Deutsch, English, français, italiano, polski, suomi, čeština, русский, українська, עברית, العربية, فارسی, ไทย, 中文, 日本語, ꯃꯤꯇꯩ ꯂꯣꯟ

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• There is a simple new Wikimedia Commons upload tool available for macOS users, Sunflower.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 29 March. It will be on non-Wikipedia wikis and some Wikipedias from 30 March. It will be on all wikis from 31 March (calendar).
• Some wikis will be in read-only for a few minutes because of regular database maintenance. It will be performed on 29 March at 7:00 UTC (targeted wikis) and on 31 March at 7:00 UTC (targeted wikis). [1][2]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

The Site Reliability Engineering (SRE) Team is pleased to announce that we’ve launched a new status page that we’ll update during major outages to Wikipedia and other Wikimedia projects.  You can find it at www.wikimediastatus.net.

By “major outages” we mean problems so severe that the general public or the media might notice – issues like wikis being very slow or unreachable for many users.  The status page will definitely be useful for the editor community and others directly involved in the projects, but it won’t be replacing forums for in-depth discussion like Technical Village Pumps or Phabricator – rather, it will supplement them, particularly as a place to check when the wikis are unreachable for you.

Of course, timeliness of information is really important during any large disruption to our services.  A key feature of the new status page is a set of five high-level metrics that give a look into the overall health and performance of the wiki environment.  We wanted a set of indicators that would show widespread issues as obvious deviations from normal, so that non-technical people could look at the graphs and say “ah, yes, something is wrong”.  Automatically publishing these metrics means that users can have some idea that something is wrong for everyone, not just themselves, even before SRE has had a chance to post an update.

Wikimedia previously offered a status page, but it was difficult to read and sometimes inaccurate.  The SRE team officially sunset it in 2018.  We’re pleased to re-launch a status page that we think is easy to interpret by both technical and non-technical folks, and that we’re committing to keep accurate and up-to-date.

Since we didn’t want to use any of our existing hosting infrastructure for the status page – as the entire point is that it must remain accessible when our servers or network connections are broken – we’re using an externally-hosted commercial product.  Do note that the Atlassian privacy policy applies when visiting the status page.

If you’re seeking more background on the project, or curious about technical decisions and implementation details, the project page on Wikitech is a good place to start. There’s also the Phabricator task for the project, which is not only a good place to learn more but also to offer any feedback. We’ll also be checking in on our team’s Talk page from time to time, and of course we’re reachable at our usual team hangout on IRC, #wikimedia-sre on Libera.chat.

Get involved with #WikiForHumanRights 2022 by joining a live launch webinar on 14 April; participating in a month-long Wikipedia writing challenge; attending global events; and more.

We are excited for the launch of the 2022 #WikiForHumanRights campaign, which calls on volunteers to write and improve content on Wikipedia about human rights, environmental health, and the range of communities impacted by environmental issues around the world.  The campaign will run from 14 April – 30 June.

For the first time last year, the UN officially recognized that having a clean, healthy, and sustainable environment is a human right. This key decision highlights how vital it is that people have access to information, including that found on Wikipedia, that helps them better understand their rights, and how to guard them. 

It also comes at a time when our planet is facing what the UN calls a “triple planetary crisis” of climate change, biodiversity loss, and pollution. Access to neutral, fact-based, and current information about climate change topics plays a critical role in our ability to not only understand these interconnected crises, but to mitigate their causes and adapt society to ensure a healthy future for all.  In turn, the role of Wikipedia has never mattered more. 

You can help respond to this global crisis by joining the #WikiForHumanRights campaign. We invite you to the following activities to learn more about the connection between human rights and the environmental crises, and how to share this information on Wikipedia.

Join the Launch Webinar!

On the 14th of April 14:00 UTC, we invite you to join the live event which will mark the launch of this year’s #WikiForHumanRights campaign.  

For the third time, the Wikimedia Foundation, in conjunction with the  United Nations Environment Programme (UNEP) and the United Nations Human Rights Office (UNHCR), will be hosting a special live conversation on how Wikipedia and other public knowledge play a role in understanding the human rights impacts of the triple planetary crisis, of biodiversity loss, climate change and pollution. 

We will have a guest panel of experts working with the UN system to advance the Right to a Healthy Environment. This will include the Special Rapporteur on Toxics and Human Rights, Dr. Marcos A. Orellana; UN Assistant Secretary General and Executive Secretary, Secretariat of the Convention on Biological Diversity Elizabeth Mrema; Women4Biodiversity director Mrinalini Rai; and youth activist Alejandro Daly. To join the event, register to participate here.

During the event, we will discuss the role of open knowledge platforms like Wikipedia in addressing the environmental crises. Panelists will share thoughts on how to make the connection between human rights and the environment more clear and accessible to the general public. 

The event will include live translations in Spanish, Portuguese, French, Chinese, and Arabic.  

Join the Global Writing Challenge

From 15 April to 15 May 2022, we are calling on Wikimedians everywhere to join the one-month global writing challenge. The challenge is aimed at bridging content gaps on human rights, environmental health, and the diverse people affected by the convergent environmental crises of climate change, pollution, and biodiversity loss. 

Join Community Events

As part of the campaign, there will be a myriad of synchronous activities and events happening across different regions. Events like, webinars, edit-a-thons, workshops, and local writing contests are taking place around the world, and we encourage you to find an event to join.

Earth Day

In commemoration of Earth Day, we will be hosting an editing workshop on  22 April  15:00UTC which will focus deeply on environment and human rights topic areas as we train participants on how to contribute to these topics on Wikipedia. 

The impact of the environmental crises cannot be understated. We all have a responsibility to ensure that everyone has access to neutral, fact-based, and current information about our shared Right to a Healthy Environment. Be part of this event by joining the zoom call.

Become part of the Human Rights Interest Group by signing up here!

The Human Rights Interest Group (HRIG) is a new group consisting of Wikimedians, individuals, and affiliated organizations interested in human rights as they pertain to Wikimedia projects. It is a movement-wide initiative aiming to create a safe space wherein the human rights concerns of our diverse communities can be heard, discussed, and addressed. 

The HRIG also aims to support the sharing of notable, reliable knowledge regarding human rights ideas, challenges, movements, and actors so our readers are informed of the state of human rights around the globe and in their own part of the world. The mission of the HRIG is to create an equitable and global approach to human rights in Wikimedia projects. Become a member by signing up here. You can read more about the group via meta. 

Share the story and learn more!  

Follow us on Twitter @Wikipedia,@Wikimedia, and @WikiSusDev or join the WikiForHumanRights Telegram Channel for event details and updates as the campaign continues through the 30th of June 2022 and check back for updates on the event page. Use the campaign hashtag #WikiForHumanRights to spread the word. You can also write to campaigns@wikimedia.org if you have questions. 

Let’s talk about relationships — nothing gossip-y — but, rather, how does one thing relate to something else? On Wikidata we talk about relationships using something called properties. Part of the semantic triple (subject, predicate, object — or in Wikidata parlance, item, property, value), properties define how one thing relates to another on Wikidata. Is it a date? A name? A location? An image? An identifier. Here’s an example: for those in the northern hemisphere, we may be thankful that this post is being published as spring (Q1312) follows (P155) winter (Q1311). In that sentence ‘follows’ is the property that explains a relationship between ‘winter’ and ‘spring.’ The Wikidata community uses properties to define any kind of relationship between things. How many properties are there? I’m glad you asked.

As of March 2022, there are around 10,000 properties on Wikidata. Roughly 7,000 of these are external identifier properties (external identifier properties correspond to external collections — museums and libraries — whose collection includes a person, place or concept that also exists in Wikidata). That leaves around 3,000 properties the community uses to describe everything. You can read the discussion page of any property to orient yourself to that property, but there are other ways to understand how properties work too. Knowing where to start with those can be a little overwhelming. This post will profile properties about properties. If that sounds confusing, I get it! I’ll provide plenty of examples to contextualize everything and help you better understand how properties work.

Let’s learn through examples. As you discover properties, wouldn’t it be wonderful if there were a way to see the property in action to know if you were using it correctly? I have good news for you: there IS a property that does this. It’s called Wikidata Property Example (P1855 for super-fans). Click that link, and read all about property examples, including links to queries where you can see thousands of properties — with examples — in the wild on Wikidata. To review: there is a property on Wikidata that exists to give you examples of properties and how they work. Can you focus the query on a specific property? Yes. Can you get multiple examples for one query? Yes. Does the example I shared list all properties with examples? Yes! Is this is one of the best ways you can use properties like a pro? Absolutely.

Now that you’re familiar with one way to learn how a properties works, consider this: maybe the dataset you are working with requires you to describe an inverse relationship — or something that is the opposite of something else. If only there were a property that could express an inverse relationship! Well, today is your lucky day because there is a property called inverse property (P1696) that does exactly that. Please note, and this is very important, that this property describes other properties on Wikidata and their relationship is inverse to each other. For example if what you’re describing follows something or if it is followed by something else, the follows (P1696) property would be connected by the inverse property. Another example would be family relationships like a parent property (mother/father) and the child property is the property for you!

If you’re not talking about relationships (properties), but rather items — concepts, people, places — there is a completely different property called opposite of (P461) that the community uses to describe conceptual opposites. What’s a conceptual opposite? You can think of this as the opposite of the color white is the color black. The opposite of summer is winter. It’s okay if it’s a little confusing. Examples will help distinguish these two. To review: an inverse property is used exclusively with relationships — child/parent, capital/capital of, officeholder/position held, owner of/owned by. Another property “opposite of” is used exclusively to describe opposing concepts. Both of these properties are great for distinguishing related things on Wikidata. Let’s move on to another distinguished property.

You are nearly a property pro. You’re feeling confident, you understand how these descriptive connections relate to each other. The world is your oyster and you want to describe more things with more properties, more accuracy, and more precision. I love the enthusiasm. There’s a property that can help you do this: it suggests related properties on Wikidata. It’s called — you guessed it — related property Property (P1659). You can use this property to see other properties related to the one you are wondering about. You can think of it as a “see also” recommendation for properties. There are MANY location-type properties on Wikidata. Suppose you want to know all of the properties related to P131, which describes where things are geographically located? You could use “related properties” in a query to get a list: just like this! You can think of this property as a way to reveal how properties are related to similar properties. Using this property will help make you a super-describer on Wikidata. There’s nothing you can’t describe now!

These three properties (well, four) should reveal more about how to describe anything on Wikidata. Learning how to use properties on Wikidata is essential for maintaining data quality and usefulness of the data. It is also one of the most effect ways to learn how to query and write better queries. The more familiar you are with properties, the more you will get out of Wikidata (and likely any other dataset you’re working with whether it’s part of Wikidata or not). Now that you know more about properties on Wikidata, consider these two things:

1. Wikidata will always require new properties. If one is missing, you can propose it here. Properties also change over time. If an existing property isn’t working for you (or has never worked for you), you can propose changes on the property’s discussion page. The only way Wikidata will ever be an equitable resource is if property usage and definitions work for all kinds of data and relationships in the world.
2. The properties I’ve shared with you in this post themselves are incomplete. The community could always use more examples, better definitions, and other ways of describing things. Adding statements to items and properties is a very important way you can help improve these resources.

Stay tuned for more Wikidata property exploration posts here. And if you want to learn more, take the Wikidata Institute course I teach!

This post gives a quick introduction to a benchmarking tool, phpbench, ready for you to experiment with in core and skins/extensions.[1]

What is phpbench?

From their documentation:

PHPBench is a benchmark runner for PHP analagous to PHPUnit but for performance rather than correctness.

In other words, while a PHPUnit test will tell you if your code behaves a certain way given a certain set of inputs, a PHPBench benchmark only cares how long that same piece of code takes to execute.

The tooling and boilerplate will be familiar to you if you've used PHPUnit. There's a command-line runner at vendor/bin/phpbench, benchmarks are discoverable by default in tests/Benchmark, a configuration file (benchmark.json) allows for setting defaults across all benchmarks, and the benchmark tests classes and tests look pretty similar to PHPUnit tests.

Here's an example test for the Html::openElement() function:

namespace MediaWiki\Tests\Benchmark;

class HtmlBench {

        /**
        * @Assert("mode(variant.time.avg) < 85 microseconds +/- 10%")
        */
        public function benchHtmlOpenElement() {
                \Html::openElement( 'a', [ 'class' => 'foo' ] );
        }
}

So, taking it line by line:

• class HtmlBench (placed in tests/Benchmark/includes/HtmlBench.php) – the class where you can define the benchmarks for methods in a class. It would make sense to create a single benchmark class for a single class under test, just like with PHPUnit.
• public function benchHtmlOpenElement() {} – method names that begin with bench will be executed by phpbench; other methods can be used for set-up / teardown work. The contents of the method are benchmarked, so any set-up / teardown work should be done elsewhere.
• @Assert("mode(variant.time.avg) < 85 microseconds +/- 10%") – we define a phpbench assertion that the average execution time will be less than 85 microseconds, with a tolerance of +/- 10%.

If we run the test with composer phpbench, we will see that the test passes. One thing to be careful with, though, is adding assertions that are too strict – you would not want a patch to fail CI because the assertion for execution was not flexible enough (more on this later on).

Measuring performance while developing

One neat feature in PHPBench is the ability to tag current results and compare with another run. Looking at the HTMLBench benchmark test from above, for example, we can compare the work done in rMW5deb6a2a4546: Html::openElement() micro-optimisations to get before and after comparisons of the performance changes.

Here's a benchmark of e82c5e52d50a9afd67045f984dc3fb84e2daef44, the commit before the performance improvements added to Html::openElement() in rMW5deb6a2a4546: Html::openElement() micro-optimisations

❯ git checkout -b html-before-optimizations e82c5e52d50a9afd67045f984dc3fb84e2daef44 # get the old HTML::openElement code before optimizations
❯ git review -x 727429 # get the core patch which introduces phpbench support
❯ composer phpbench -- tests/Benchmark/includes/HtmlBench.php --tag=original

And the output [2]:

Note that we've used --tag=original to store the results. Now we can check out the newer code, and use --ref=original to compare with the baseline:

❯ git checkout -b html-after-optimizations 5deb6a2a4546318d1fa94ad8c3fa54e9eb8fc67c # get the new HTML::openElement code with optimizations
❯ git review -x 727429 # get the core patch which introduces phpbench support
❯ composer phpbench -- tests/Benchmark/includes/HtmlBench.php --ref=original --report=aggregate

And the output [3]:

We can see that the execution time roughly halved, from 18 microseconds to 8 microseconds. (For understanding the other columns in the report, it's best to read through the Quick Start guide for phpbench.) PHPBench can also provide an error exit code if the performance decreased. One way that PHPBench might fit into our testing stack would be to have a job similar to Fresnel, where a non-voting comment on a patch alerts developers whether the PHPBench performance decreased in the patch.

Testing with extensions

A slightly more complex example is available in GrowthExperiments (patch). That patch makes use of setUp/tearDown methods to prepopulate the database entries needed for the code being benchmarked:

/**
 * @BeforeMethods ("setUpLinkRecommendation")
 * @AfterMethods ("tearDownLinkRecommendation")
 * @Assert("mode(variant.time.avg) < 20000 microseconds +/- 10%")
 */
public function benchFilter() {
        $this->linkRecommendationFilter->filter( $this->tasks );
}

The setUpLinkRecommendation and tearDownLinkRecommendation methods have access to MediaWikiServices, and generally you can do similar things you'd do in an integration test to setup and teardown the environment. This test is towards the opposite end of the spectrum from the core test discussed above which looks at Html::openElement(); here, the goal is to look at a higher level function that involves database queries and interacting with MediaWiki services.

What's next

You can experiment with the tooling and see if it is useful to you. Some open questions:

• do we want to use phpbench? or are the scripts in maintenance/benchmarks already sufficient for our benchmarking needs?
• we already have a benchmarking tools in maintenance/benchmarks that extend a Benchmarker class; would it make sense to convert these to use phpbench?
• what are sensible defaults for "revs" and "iterations" as well as retry thresholds?
• do we want to run phpbench assertions in CI?
  • if yes, do we want assertions about using absolute times (e.g. "this function should take less than 20 ms") or relative assertions ("patch code is within 10% +/- of old code)
  • if yes, do we want to aggregate reports over time, so we can see trends for the code we benchmark?
  • should we disable phpbench as part of the standard set of tests run by Quibble, and only have it run as a non-voting job like Fresnel?

Looking forward to your feedback! [4]

[1] thank you, @hashar, for working with me to include this in Quibble and roll out to CI to help with evaluation!

[2]

> phpbench run --config=tests/Benchmark/phpbench.json --report=aggregate 'tests/Benchmark/includes/HtmlBench.php' '--tag=original'
PHPBench (1.1.2) running benchmarks...
with configuration file: /Users/kostajh/src/mediawiki/w/tests/Benchmark/phpbench.json
with PHP version 7.4.24, xdebug ✔, opcache ❌

\MediaWiki\Tests\Benchmark\HtmlBench

    benchHtmlOpenElement....................R1 I1 ✔ Mo18.514μs (±1.94%)

Subjects: 1, Assertions: 1, Failures: 0, Errors: 0
Storing results ... OK
Run: 1346543289c75373e513cc3b11fbf5215d8fb6d0
+-----------+----------------------+-----+------+-----+----------+----------+--------+
| benchmark | subject              | set | revs | its | mem_peak | mode     | rstdev |
+-----------+----------------------+-----+------+-----+----------+----------+--------+
| HtmlBench | benchHtmlOpenElement |     | 50   | 5   | 2.782mb  | 18.514μs | ±1.94% |
+-----------+----------------------+-----+------+-----+----------+----------+--------+

[3]

> phpbench run --config=tests/Benchmark/phpbench.json --report=aggregate 'tests/Benchmark/includes/HtmlBench.php' '--ref=original' '--report=aggregate'
PHPBench (1.1.2) running benchmarks...
with configuration file: /Users/kostajh/src/mediawiki/w/tests/Benchmark/phpbench.json
with PHP version 7.4.24, xdebug ✔, opcache ❌
comparing [actual vs. original]

\MediaWiki\Tests\Benchmark\HtmlBench

    benchHtmlOpenElement....................R5 I4 ✔ [Mo8.194μs vs. Mo18.514μs] -55.74% (±0.50%)

Subjects: 1, Assertions: 1, Failures: 0, Errors: 0
+-----------+----------------------+-----+------+-----+---------------+-----------------+----------------+
| benchmark | subject              | set | revs | its | mem_peak      | mode            | rstdev         |
+-----------+----------------------+-----+------+-----+---------------+-----------------+----------------+
| HtmlBench | benchHtmlOpenElement |     | 50   | 5   | 2.782mb 0.00% | 8.194μs -55.74% | ±0.50% -74.03% |
+-----------+----------------------+-----+------+-----+---------------+-----------------+----------------+

[4] Thanks to @zeljkofilipin for reviewing a draft of this post.

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available : Bahasa Indonesia, Deutsch, français, italiano, magyar, polski, português, português do Brasil, svenska, čeština, русский, українська, עברית, العربية, 中文, 日本語, 한국어

New code release schedule for this week

• There will be four MediaWiki releases this week, instead of just one. This is an experiment which should lead to fewer problems and to faster feature updates. The releases will be on all wikis, at different times, on Monday, Tuesday, and Wednesday. You can read more about this project.

Recent changes

• You can now set how many search results to show by default in your Preferences. This was the 12th most popular wish in the Community Wishlist Survey 2022. [1]
•  The Jupyter notebooks tool PAWS has been updated to a new interface. [2]

Future changes

• Interactive maps via Kartographer will soon work on wikis using the FlaggedRevisions extension. Please tell us which improvements you want to see in Kartographer. You can take this survey in simple English. [3]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe on wiki.

The Wikimedia Foundation today announces that all Covid-19 related travel restrictions with Foundation Grant funding will be lifted. Our primary concern in 2020 was community safety as we all grappled with the unknown pandemic.  Two years later, the world is opening up again and travel is resuming in many countries. The Foundation has changed its own travel policy and we recognize the importance of meeting in person, something which many of us have missed over the past two years. 

We will now welcome proposals to support travel again. Following the new Foundation Fund Strategy and the Movement Strategic Direction we recognize we are all partners in our movement and the autonomy of movement entities to be responsible for creating their own travel plans. The Foundation does have a few recommendations in place to consider for safely gathering that would be accepted as costs of proposed travel budgets. 

1. We recommend all attendees to be vaccinated when possible.
2. We advise organizers and participants to check on local restrictions and rules in your own country and in the destination country that is hosting the event. Costs included in the proposal should follow current local COVID guidelines for the travel destination including Airlines requirements such as pre/post travel COVID test and possible limits on attendee number. Should conditions become more stringent closer to the event, you are welcome to submit a cost addendum should it be needed for additional PPE, testing etc.  
3. We also recommend that event organizers include travel booking services and insurance as part of your plans and budgeting proposals. Organizations are able to add these costs or for any other precautions taken as part of your event, such as pre/post testing and masks, can  be included in budgets. 

Event organizers who have been planning online events, can now also consider an in person element. Please reach out to your Program Officer, who can discuss making the relevant adjustments to your plan or budget, when possible, to allow in person events.

The current Risk Assessment protocol is no longer required, but it is recommended for organizers to review the In-person gathering checklist for safety precautions.

We do acknowledge that the pandemic is still present in many places across the world, and vaccines are not accessible to everyone. If this is the case for your community, we ask that you be mindful of community safety and that both local events, and online events, are still welcomed. The World Health Organization is still offering general guidance that you could review.   

For more information please contact the program/ region program officer, or reach out to communityresources@wikimedia.org

Here are a few useful resources for more information on our funding programs: 

Wikimedia Foundation Funds programs

Community Resources team and contact information

Conference and Events Funds program

From Community Resources, on behalf of the Wikimedia foundation.

On Thursday March 24th the trilogue negotiators concluded discussions, dramatic at times, over the Digital Markets Act. The compromise includes some gains on interoperability, a potential changemaker in the online intermediation. What to expect? Where not to hold your breath? We parse out the practical consequences of the trilogue outcome on interoperability.

Winding road to the final compromise

Interoperability has been a point of contention since the European Commission published their first draft in December 2020. The EC drafted it narrowly, obligating gatekeepers to offer interoperability to the so-called ancillary services, like payment or identification services, that wish to operate within closed ecosystems. IMCO Rapporteur MEP Andreas Schwab followed this approach in his draft report. 

That didn’t go well with many MEPs who were disappointed with the fact that an opportunity to open up walled gardens of online intermediation had not been exploited. Many amendments and heated debates later, the final EP report provided that interconnection should be also possible between messaging apps and services (the so-called number independent interpersonal communication services) as well as social networks.

Since the Council’s approach was focused on refining the business-to-business side of interoperability, the trilogues didn’t show much promise in securing the extension of the EC’s scope. Somehow, under pressure of time the delegation of MEPs managed to negotiate some gains that keep the spirit if not the letter of the EP mandate.

Basic rules of becoming interoperable under DMA

As originally devised, the final DMA compromise envisions that only services designated as gatekeepers will be obliged to create conditions for interoperability with other services. This possibility will be, however, accessible on request – meaning that there won’t be any obligation to make a given service permanently and publicly accessible. A gatekeeper will have 3 months to “render requested basic functionalities operational”. 

Contrary to the original proposal by the European Commission, the compromise includes a definition of the functionality enabling opening digital ecosystems that so far have been closed: 

‘Interoperability’ means the ability to exchange information and mutually use the information which has been exchanged through interfaces or other solutions, so that all elements of hardware or software work with other hardware and software and with users in all the ways in which they are intended to function.

The definition is pretty straightforward and covers potential applications of frictionless communication exchange broadly, relating to both hardware and software. It refers to both the provisions already outlined by the European Commission in the original draft and to those worked out during the trilogues. The latter, as explained below in more detail, is an improvement as it encompasses some services that are then accessible to individual users and groups of individuals (the so-called end users).

End users will be able to freely decide whether they want to make use of the interconnected services or rather stay with the provider they had originally chosen. A service that wants to connect with a gatekeeper will need to do so within the same level of security. This means that if a gatekeeper offers end-to-end encryption, a connecting service will also need to provide it.

Messaging

End-to-end text messaging between two end users will be one of the basic functionalities that will become interoperable on request. Within two years after designation, the gatekeeper will also need to make available text messaging within groups of individual users. 

Similarly, sharing of images, voice messages and video attachments between two individuals will be the key available function that, after two years from becoming a gatekeeper, will need to be extended to groups.  

Calling

Voice and video calls will not be immediately available after gatekeepers are designated. They will have 4 years to create technical and operational conditions to make end-to-end video or voice calls available between two individuals and groups. 

Social networking? Maybe…

Social networking should also be one of the functionalities that gatekeepers should make interoperable, but the negotiators were not keen on agreeing to proposals made by the European Parliament team. The obligation for gatekeepers who offer social networking services did not make it into the final text. 

Fortunately, the DMA has a revision clause that binds the European Commission to evaluate the regulation and report to the European Parliament and the Council of the EU. The negotiators agreed to include an assessment if social networking services should be included in the scope of interoperability provisions in the revision clause. So there is no promise, but at least the EC has to look into the issue again and produce some evidence for – or against – extending the scope. 

The art of war compromise

The negotiations over interoperability were indeed dramatic. Apparently the French Presidency was unsure of its mandate from the Council to negotiate extended interoperability provisions and hesitated to negotiate beyond what the Council had included in their draft. Even worse, the European Commission authored a non-paper full of simplified claims pointing at how interoperability is not a feasible solution either for messaging or social networking.

“With the French Presidential elections looming, the incentive to wrap up what is possible to wrap up became greater. This was the chance for the Parliamentary negotiators to defend the mandate bestowed on them by the EP. “

Fortunately for the DMA, the negotiations over DSA were dragging. It became apparent that despite bold promises to deliver the outcome on the two regulations, the French Presidency won’t be able to assign two successes to its account. With the French Presidential elections looming, the incentive to wrap up what is possible to wrap up became greater. This was the chance for the Parliamentary negotiators to defend the mandate bestowed on them by the EP. 

Hence the result that goes along the demarcation line between what the EP wanted and what the Council agreed to give. Yes, end users will enjoy more interconnectivity, but only if service providers request it from the gatekeepers. Yes, private one-on-one messaging will be available first via text and sharing of images, audio and video attachments, but groups will need to wait two years to benefit from that. Yes, calling and video calling others will be possible but within 4 years. Yes, social networking could become interoperable but only if the European Commission sees it as necessary to ensure contestability – and that the soonest 3 years after the regulation enters into force. 

No doubt, the EP delegation fought hard and used available opportunities to secure what they could regarding interoperability. Ideally it would be better and extended to social networking but considering the pressure from the Council and the lobbying of the Big Tech on the issue, we couldn’t realistically count on more.

Stay tuned for the analysis of other provisions of the Digital Markets Act as adopted by the trilogues negotiators!

Last year, I spent $17 on an Aqara cube, and it’s been one of my best purchases for enjoyment per dollar spent.

The Aqara cube is a three-inch square plastic cube that sends gestures over Zigbee to a cheap off-the-shelf dongle.

By pairing this cube with Home Assistant, I have a three-dimensional button with 45 unique interactions to control whatever I want.

And over the last six months, I’ve used it to control a small fleet of antiquated streaming devices to help me discover new music.

🎭 The Tragedy of the Logitech Squeezebox ¶

The Logitech Squeezebox is a bygone streaming device that was too beautiful for this world. Logitech snuffed the Squeezebox in 2012.

But because others share my enthusiasm for Squeezeboxes, there’s still hope. The second-hand market persists. And there are wonderful nerds cobbling together Squeezeboxes from Raspberry Pis.

I built a DIY Squeezebox from a Pi Zero Pimoroni PirateRadio kit and Squeezelite software.

I blanket my humble abode in music by combining a DIY PirateRadio, a Squeezebox Boom, and a Squeezebox Touch.

My Dockerized Logitech Media Server perfectly synchronizes these three devices. Music from Spotify or WQXR is seamless when you walk from bedroom to kitchen to dining room.

Home Assistant is ✨magic✨ ¶

Home Assistant is open-source home automation software, and it’s the only IoT software I don’t find myself screaming at regularly.

And, of course, there’s a Logitech Squeezebox integration for Home Assistant. The integration lets you use Logitech Media Server’s (somewhat esoteric) API to control your devices from Home Assistant.

I also use a community-made Home Assistant Blueprint that automates each of the cube’s 45 unique gestures.

Currently, since my mental stack is tiny, I only use four gestures:

1. Shake: Turn on all players, and start playing a random album from Spotify (that’s right, album – I’m old enough to yearn for the halcyon days of Rdio).
2. Double-tap: Turn off all players.
3. Flip: Next track.
4. Twist: Twist right for volume up; twist left for volume down – like a volume knob.

15/03/2022-21/03/2022

Mapping campaigns

• UN Mappers are going to map building footprints, supporting UNSMIL to ensure peace in Libya, on Wednesday 30 March from 06:00 UTC until 16:00 UTC. The tasks will be distributed via the tasking manager.
• Andrés Gómez Casanova announced that the note-a-thon (a group activity solving local notes in Latin American countries) will be held on the first Saturday of each month from now on. The note-a-thon is registered as an organised activity. See the details > of this activity on the wiki. Events are coordinated > on Meetup.

Mapping

• bgo_eiu reported on his unexpected insights gained while trying to improve the mapping of Baltimore’s public transit in OSM.
• Counter-mapping the City was a two day virtual conference about using mapping as a means of promoting the struggles of marginalised people in the Philippines.
• dcapillae has started > an initiative with authorised mappers to improve the positions of recently imported recycling containers in Malaga (Spain). To support this he has created a special style usable in JOSM showing the different types of goods suitable for recycling.
• User kempelen pointed out > , once again, the importance of separating landuse=* and area=* from highway=*.
• Voting is open until Tuesday 5 April for artwork_subject=sheela-na-gig, for mapping Sheela-na-gigs, stone carvings depicting nude women exposing their genitals, found on churches, castles, other walls and in museums.
• Tjuro has finished their micro-mapping of the rebuilt station square north in Zwolle.

Community

• Edoardo Neerhut is looking for work for Aleks (@Approksimator), who has lost his income due to the war in Ukraine.
• OSMF Japan and Microsoft Corporation will hold a workshop > on Soundscape and OSM on Wednesday 30 March. Soundscape is a 3D voice guidance application based on OSM data.
• Amanda McCann’s February diary is online.
• The Communication Working Group of OSMF has officially announced the new discussion forum for OSM (we reported earlier) in a blog post.
• For International Women’s Day GeoladiesPH had a 3 hour mapathon, focusing on women, called #BreakTheBiasedMap.
• Chinese mapper 喵耳引力波 wrote > a diary entry, in which they list all of the Chinese mappers who gathered to map and refine the mountainous terrain and roads after the MU5735 air crash, and guesses this may have been due to modern media allowing mappers to follow breaking news.

Events

• The 8th State of the Map France (SotM-Fr) will take place at the University of Nantes from 10 to 12 June. The call for papers is open until Thursday 31 March.
• The State of the Map Working Group revealed the logo for SotM 2022 in Firenze (Italy). They also published a number of key dates as follows:
  • Monday 25 April 2022: 23:59:59 UTC: Deadline for talk and workshop submissions
  • June 2022: Talk video production (test video and final video)
  • August 2022: Lightning talk video production
  • 19 to 21 August 2022: State of the Map.

Education

• Corinna John described > in her blog how to create a ‘photo map’ using QGIS.
• Youthmappers published their project results about how to connect volunteered geographic information and crowdsourced spatial data with government cartographers and geographers to better serve the public across the Americas.

Maps

• [1] Sven Geggus has improved his OpenCampingMap. Now sanitary_dump_station, water_point and drinking_water are also displayed at zoom level 19.
• Reporters from franceinfo used > OpenStreetMap’s data for an article about the cost of commuting after the recent rise in oil prices.
• Alex Wellerstein presented his OSM based ‘nukemap’, which allows you to visualise the impact of a simulated nuclear detonation. Start with a tactical bomb (10 kt) and try the advanced options!

Software

• lwn.net reported that there is an OpenStreetMap viewer for Emacs.
• Organic Maps is participating in the Google Summer of Code 2022. Six ideas for projects are already available.
• Kevin is the new maintainer of the Awesome OpenStreetMap list. He invites you to help make this list more awesome.

Releases

• Last week we reported on release 17.0.4 of Vespucci. In it there was a problem with the default templates that can be solved by manually updating the templates.

Upcoming Events

Where	What	Online	When	Country
Perth	Social Mapping Online	✓	2022-03-27
	Open Mapping Hub Asia Pacific OSM Help Desk		2022-03-28
Bremen	Bremer Mappertreffen (Online)	✓	2022-03-28
San Jose	South Bay Map Night	✓	2022-03-30
Ville de Bruxelles – Stad Brussel	Virtual OpenStreetMap Belgium meeting	✓	2022-03-29
	Open Mapping Hub Asia Pacific OSM Help Desk		2022-03-30
Tucson	State of the Map US		2022-04-01 – 2022-04-03
Hlavní město Praha	Missing Maps GeoNight MSF CZ online mapathon 2022 #1	✓	2022-04-01
Burgos	Evento OpenStreetMap Burgos (Spain) 2022		2022-04-01 – 2022-04-03
Região Geográfica Imediata de Teófilo Otoni	Mapathona na Cidade Nanuque – MG -Brasil – Edifícios, Estradas, Pontos de Interesses e Área Verde		2022-04-02 – 2022-04-03
Bogotá Distrito Capital – Municipio	Notathon en OpenStreetMap – resolvamos notas de Latinoamérica		2022-04-02
	Open Mapping Hub Asia Pacific OSM Help Desk		2022-04-04
	OSMF Engineering Working Group meeting		2022-04-04
Stuttgart	Stuttgarter Stammtisch		2022-04-05
Greater London	Missing Maps London Mapathon		2022-04-05
Berlin	OSM-Verkehrswende #34 (Online)	✓	2022-04-05
	Open Mapping Hub Asia Pacific OSM Help Desk		2022-04-06
	Tasking Manager Collective Meet Up – Option 1		2022-04-06
	Tasking Manager Collective Meet Up – Option 2		2022-04-06
Berlin	166. Berlin-Brandenburg OpenStreetMap Stammtisch	✓	2022-04-08
	Open Mapping Hub Asia Pacific OSM Help Desk		2022-04-11
臺北市	OpenStreetMap x Wikidata Taipei #39		2022-04-11
Washington	MappingDC Mappy Hour		2022-04-13
Hamburg	Hamburger Mappertreffen		2022-04-12
San Jose	South Bay Map Night	✓	2022-04-13
	Open Mapping Hub Asia Pacific OSM Help Desk		2022-04-13
	OSM Utah Monthly Meetup		2022-04-14
Michigan	Michigan Meetup	✓	2022-04-14

Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there, will appear in weeklyOSM.

This weeklyOSM was produced by Lejun, Nordpfeil, PierZen, SK53, Strubbl, TheSwavu, derFred, Can.

Why Register to Let’s Connect?

The Let’s Connect Working Group and the Community Resources team are excited to announce the launch of the Peer Learning Program – Let’s Connect. You can register now here.

Let’s Connectcreates spaces for horizontal, flexible, and interactive peer learning spaces and resources. It encourages a learning culture based on curiosity and honest reflection, learning about good practices, but valuing what didn’t work out as expected – the surprises, the “failures”. It encourages learning that is adaptable and flexible to different contexts, levels of development, and needs. 

The Working Group is a joint community-Foundation team that is coordinating Let’s Connect in its initial pilot phase (March to July). This team was built based on an expression of interest during the initial brainstorm discussions, and Introductory blog. There is also an advisory group of community members that are supporting the program by offering guidance and feedback.

“Peer learning in the Wikimedia movement has been an important factor of growth among many volunteers and their communities. A well-structured approach like “Let’s Connect” would go a long way in making sure more communities receive the knowledge they truly deserve to grow their communities.” Justice Allotey, Let’s Connect Working Group Member.

“It’s exciting for me to know that there is now a structured space within the movement for us to gather and learn from each other, I can’t wait to tap in all the knowledge that will be harnessed in Let’sConnect” Winnie Kabintie, Let’s Connect Working Group Member.

How can I participate?

Let’s Connect is directed at Wikimedians in all regions that are part of “organised groups”.  These groups can range from a group of individuals that are not formally organised, Wikimedia affiliates, and mission-aligned organisations, seeking to share their knowledge and learn from others. They can be those that receive funding from Wikimedia Funds or planning to do so in the future.

By filling out the Let’s Connect  registration form, you will express 1) what skills you would like to share, 2) how you would like to do this 3) what skills you would like to learn or further develop and 4)  what financial, methodological, or technological support you may need. If you have difficulties accessing the form you can also email us Letsconnectteam@wikimedia.org or write on the Let’s Connect Talk Page. 

This information will allow us to match you with peers interested in similar topics for One-to-One connections, invite you to Learning clinics as well as keep you updated on other peer learning and training opportunities within the Movement. In the following weeks, we will be updating this calendar of Learning Clinics, and matching you with your peers! 

Peer learning can happen around a number of different skills, such as organizational and funding-related issues, programmatic tactics, or Wikimedia project-related tools. 

For Let’s Connect to be community-led and expand, we need lots of community members proposing Learning Clinics. If you want to take on this role as a Learning Ambassador please register this interest in the registration form! The Working Group will reach out to you to support you in planning the session, provide technological and financial support to cover the time taken to do this, as well as other needs such as translation, connectivity, etc.

“It’s important to register for the Let’s Connect Peer Learning program because it gathers and showcases capacities, and skills of various community members within our Movement. The program will provide resource sharing opportunities via the skills directory, (an aggregate) resource center, and connections to the amazing people that make Wikimedia what it is today, and what it will be in the future”. Douglas Ssebaggala, Let’s Connect Working Group Member.

The information gathered during the registration will be used to build Let’s Connect’s “Skills Directory” on Meta (link to the skills directory). This directory will be an open directory for everyone to know who is doing what and where and proactively reach out to each other. The information will be updated monthly by the Let’s Connect Working Group and Let’s Connect registered members will also be able to edit their information.

What is in for me? Incentives to participate!

Apart from being able to make connections with people in the movement and offer mutual support, participating will also be a way of networking and making visible your work to others and the wider movement. Let’s Connect will award you a certificate of participation, barnstars, and visibility in movement communications as a means to recognise your contribution. 

Finally, you can ask for financial support to participate in sharing your work or organising learning spaces as a Let’s Connect Ambassador. There will be two different types of funding support:

• For individuals and organizations with existing grant agreements: an amendment to existing grant agreements to provide financial support for sharing in Let’s Connect.  
• For individuals or organizations without existing grant agreements: a stipend that will provide financial support for sharing in Let’s Connect.  

These financial resources can be used for any needs related to participating in the program, this can include the time taken to organise sharing material, translation, connectivity, design pieces, childcare, amongst others. 

“I think it is important to register for the program, since it is a meeting space for peers from the entire community where we can generate great encounters for collaborative learning,” Florencia Guastavino. Let’s Connect Advisory Group Member

Learn More about the Let’s Connect Program Here.

Any questions

If you have any questions registering or any suggestions, please write to us at: Letsconnectteam@wikimedia.org

Thank you! – From the Let’s Connect Working Group.  

1. Peer learning is one of many collaborative forms of learning. It differs from formal training, which generally seeks to build and transfer knowledge in a structured and more formal setting. Peer learning can complement and not replace formal training.

2. This is a very basic directory in a google sheets format. We hope to transition to more user-friendly and technological tools developed by the Capacity Exchange team and Community Development WikiLearn platform. 

In Wiki Education’s Wikipedia Student Program, college and university instructors assign their students to edit Wikipedia as part of the coursework. For most courses, this replaces a research paper or the literature review section of a longer analytical paper, related to the course topic. But for some courses, Wikipedia also becomes an object of study for students.

That’s the case for New York University Clinical Associate Professor David Cregar, who teaches in the Expository Writing Program. His course, “We are not in a post-fact world”: Wikipedia & the Construction of Knowledge, focuses on both having students contribute to Wikipedia and contextualizing Wikipedia in the broader knowledge landscape. Student Audrey Yang fulfilled the second part of the assignment in a creative way — by creating what looks like a Wikipedia article, called “Wikipedia & the Structure of Knowledge” (but, it notes, “From Fake Wikipedia, not a real encyclopedia (but still free)”). Audrey’s reflection of how Wikipedia compares to the Library of Babel contains all the hallmarks of a Wikipedia article: a table of contents, edit buttons on section headers, citations, wikilinks, and even a talk page, complete with notes from her thought process as she wrote the essay!

This example of an end-of-term reflective essay is particularly fun and creative. Download this PDF to see Audrey’s work. And many thanks to Audrey and Professor Cregar for sharing it with us!

In 2020, we welcomed Turkey back to Wikipedia. Following a nearly three-year block affecting both readers and editors in the country, in December 2019, the Turkish Constitutional Court ruled the block unconstitutional and ordered access restored. Although the block was lifted, work continued behind the scenes. The Foundation moved forward with a petition we filed in 2019 with the European Court of Human Rights, an international court that enforces the European Convention on Human Rights, of which Turkey is a party. We argued that the law that was used as the basis for the block violated fundamental rights of the people of Turkey. 

Today, the European Court of Human Rights announced that it is dismissing the case. It cited three reasons for this dismissal: 1) the block was lifted in 2020; 2) the block was effectively deemed a human rights violation by the Turkish Constitutional Court in its December 2019 ruling; and 3) the Court believes the Turkish Constitutional Court capable of addressing future problems related to violations of free expression online. The Court did provide guidance that the over two years taken by the Turkish Constitutional Court to address the violation may, in the future, be seen as an excessive delay for governments to take action in cases of website blocking.

Because our primary goal when we filed the case was to restore access to Wikipedia in Turkey, we understand the Court’s decision. However, we also recognize that this ruling comes at a time when access to knowledge continues to be under threat around the world, including in Russia where authorities recently demanded the removal of Wikipedia content related to the Russian government’s invasion of Ukraine. We will continue to work with you all to defend the right of everyone to freely access and participate in knowledge, today and into the future.

Help us amplify the message to protect free knowledge around the world.

• Click to tweet me: The European Court of Human Rights has dismissed a @Wikimedia petition to lift the block of @Wikipedia in Turkey, as the block was lifted in 2020 and considered a human rights violation in another court. More #ForFreeKnowledge https://wikimediafoundation.org/news/2022/03/24/european-court-of-human-rights-case-dismissed/
• Share the Wikimedia Foundation’s social media posts on Facebook, Twitter, and LinkedIn presenting our statement.

Today, the European Court of Human Rights announced that it is dismissing the Wikimedia Foundation’s 2019 petition to lift the block of Wikipedia in Turkey. The case was dismissed because access to Wikipedia was restored by the Turkish government in January 2020 and the block was already determined to be a human rights violation in the Turkish Constitutional Court’s December 2019 ruling. The Court believes that the Turkish Constitutional Court can for now effectively address future problems related to violations of free expression online. 

“We respect the Court’s decision given that our primary goal of restoring access to Wikipedia in Turkey has already been achieved,” said Stephen LaPorte, Associate General Counsel of the Wikimedia Foundation. “We thank the Court for their attention on this issue and would like to once again celebrate that Turkey’s more than 80 million people have unrestricted access to Wikipedia.” 

In its decision, the Court emphasized that governments must acknowledge (explicitly or in substance) violations to the European Convention on Human Rights and then address the issue accordingly. The Court did find that the Turkish government had effectively done so in this case by restoring access to Wikipedia after the Turkish Constitutional Court’s 2019 ruling and, in combination with its other past cases, had outlined clearer criteria for addressing website blocking in the future. Additionally, the Court provided guidance that the over two years taken by the Turkish Constitutional Court to address the violation may in the future be seen as an excessive delay for governments to take action in cases of website blocking.

The ruling comes following a petition filed with the Court in April 2019 by the Wikimedia Foundation, the nonprofit that operates Wikipedia. Established in 1959, the Court is the international human rights court which enforces the European Convention on Human Rights. Turkey is a long-standing party to the Convention.

In April 2017, the Turkish government blocked all language editions of Wikipedia in Turkey. The move denied more than 80 million people in the country access to free knowledge and prevented them from sharing their history, culture, and experiences with the world. After exhausting domestic efforts to restore access, the Wikimedia Foundation turned to the European Court of Human Rights in April 2019. The Foundation contended that the blanket ban of Wikipedia violated fundamental freedoms, including the right to freedom of expression, as guaranteed by Article 10 of the European Convention. The case was granted priority by the Court.

In January 2020, access to Wikipedia was restored in Turkey, following a ruling by the Constitutional Court of Turkey acknowledging in substance that the block of Wikipedia violated both the Turkish Constitution and the European Convention on Human Rights. The European Court of Human Rights was asked to evaluate the Turkish law that was used as a basis to block access to Wikipedia and examine whether that law violated free expression.

The European Court of Human Rights’ decision comes at a time when access to knowledge continues to be under threat around the world, including in Russia where authorities recently demanded the removal of Wikipedia content related to the Russian government’s invasion of Ukraine. The Wikimedia Foundation will continue to defend the right of everyone to freely access and participate in knowledge.

Wikipedia is built on the idea that knowledge belongs to everyone—that information should be freely accessible, without restriction, and that everyone should be able to freely participate in the creation of our historical record. 

Today, Wikipedia is read more than 6,000 times every second by people around the globe. Its more than 55 million articles across over 300 languages provide knowledge across a wide array of topics, from major current events to the history of ancient civilizations. More than 280,000 volunteers around the world work together to write, edit, and update articles in real time, using reliable sources to verify the facts. Through this open, editorial process, articles become more neutral and reliable over time, ensuring topics are covered from all sides and established in fact-based sources.  

Since the block has been lifted in Turkey, Turkish Wikipedia is thriving again. It has grown to include more than 474,000 articles, edited by a community of 8,000 Turkish-speaking volunteers every month. Wikipedia and Wikimedia projects are viewed more than 150 million times a month in Turkey. Thanks to efforts led by a local group of volunteers, students across several Turkish universities are contributing Wikipedia articles as part of their course requirements, and museum professionals in Turkey are learning how to add their knowledge to Wikipedia.

The Wikimedia Foundation is represented by Can Yeginsu of 3 Verulam Buildings in London, and Gönenç Gürkaynak at ELIG Gurkaynak Attorneys-at-Law in Istanbul. We wish to express our enthusiastic appreciation for their counsel over the last five years.

Avrupa İnsan Hakları mahkemesi bugün, Vikipedi’ye erişim engelinin kaldırılması için Wikimedia Vakfı’nın 2019 tarihli dilekçesini reddettiğini duyurdu. Dava, Türk hükûmeti tarafından Vikipedi’ye erişimin Ocak 2020’de tekrar sağlanmış olması ve engelin bir insan hakları ihlali olduğunun Türk Anayasa Mahkemesi’nin Aralık 2019 tarihli kararında zaten belirlenmiş olması nedeniyle reddedildi. Mahkeme, Türk Anayasa Mahkemesi’nin artık çevrimiçi ifade özgürlüğü ihlalleri ile ilgili gelecekteki sorunları etkin biçimde ele alabileceğine inanmaktadır.

Wikimedia Vakfı Baş Hukuk Müşaviri Stephen LaProte, “Türkiye’de Vikipedi’ye erişimin tekrar sağlanması ana hedefimize zaten ulaşılmış olduğunu göz önüne alarak Mahkemenin kararını saygıyla karşılıyoruz” dedi. “Mahkemeye bu konuya gösterdiği ilgiden dolayı teşekkür ediyor ve Türkiye’nin 80milyondan fazla insanını, Vikipedi’ye sınırsız erişim sağlayabilmlerinden ötürü tekrar kutlamak istiyoruz.”

Mahkeme kararında, hükûmetlerin Avrupa İnsan Hakları Sözleşmesi ihlallerini (gerek açık gerek örtük ihlaller) tanımaları ve ardından konuyu buna göre ele almaları gerektiğini vurguladı. Mahkeme, bu davada Türk hükûmetinin bunu, Türk Anayasa Mahkemesinin 2019 tarihli kararının ardından Vikipedi’ye erişimi yeniden sağlayarak etkin biçimde yapmış olduğunu ve geçmişteki diğer davalarla birlikte, gelecekte web sitesi engelleme konusunu ele almada daha net kriterler belirlediğini tespit etti.

Karar, Vikipedi sitesini işleten, kâr amacı gütmeyen bir kuruluş olan Wikimedia Vakfı tarafından Nisan 2019’da Mahkeme’ye sunulan bir dilekçenin ardından geldi. 1959’da kurulan Mahkeme, Avrupa İnsan Hakları Sözleşmesi’ni uygulayan uluslararası insan hakları mahkemesidir. Türkiye, uzun süredir Sözleşme’ye taraftır.

Türk hükûmeti Nisan 2017’de Vikipedi’nin tüm dil sürümlerine Türkiye’den erişimi engelledi. Bu, ülkedeki 80 milyondan fazla insanın özgür bilgiye erişimesini ve tarihlerini, kültürlerini ve deneyimlerini dünyayla paylaşmalarını engelledi. Wikimedia Vakfı, erişimi yeniden sağlamak için başvurduğu iç hukuk yolları tükendikten sonra Nisan 2019’da Avrupa İnsan Hakları Mahkemesi’ne başvurdu. Vakıf, Vikipedi’nin tamamına erişimin engellenmesinin, Avrupa İnsan Hakları Sözleşmesi’nin 10. maddesi tarafından garanti edilen ifade özgürlüğü hakkı da dahil olmak üzere temel özgürlükleri ihlal ettiğini iddia etti. Mahkeme tarafından dava öncelikli olarak ele alındı.

Ocak 2020’de Türkiye Anayasa Mahkemesi’nin, Vikipedi’ye erişim engellinin gerek Türk Anayasasını gerekse Avrupa İnsan Hakları Sözleşmesini ihlal ettiğini kabul eden kararının ardından, Türkiye’de Vikipedi’ye yeniden erişim sağlandı. Avrupa İnsan Hakları Mahkemesi’nden Vikipedi’ye erişim engelinin dayandırıldığı Türk yasasını değerlendirmesi ve bu yasanın ifade özgürlüğünü ihlal edip etmediğini incelemesi istendi.

Avrupa İnsan Hakları Mahkemesi’nin kararı, dünyada bilgiye erişimin, kısa süre öne yetkililerin Rus hükûmetinin Ukraynayı işgali hakkındaki Vikipedi içeriğinin kaldırılmasını talep ettikleri Rusya da dahil olmak üzere, tehdit altında olmaya devam ettiği bir zamanda geldi. Wikimedia Vakfı, bilgiye herkesin özgürce erişme ve katılma hakkını savunmaya devam edecektir.

Vikipedi, bilginin herkese ait olduğu fikri üzerine inşa edilmiştir; bilgi, kısıtlama olmaksızın özgürce erişilebilir olmalıdır ve tarihimizin kaydınıın tutulmasına herkesin serbestçe katılabilmesi gerekir.

Günümüzde Vikipedi, dünyanın dört bir yanındaki insanlar tarafından saniyede 6.000’den fazla kez okunmaktadır. 300’den fazla dilde 55 milyondan fazla maddesi, önemli güncel olaylardan eski uygarlıkların tarihine kadar çok çeşitli konularda bilgi sağlıyor. Dünyada 280.000’den fazla gönüllü, olguları doğrulamak için güvenilir kaynakları kullanarak maddeleri anlık olarak yazmak, düzenlemek ve güncellemek için birlikte çalışıyor. Maddeler bu açık editoryal süreç sayesinde zamanla daha tarafsız ve güvenilir hale gelmekte ve konuların her yönüyle ele alınması ve olgulara dayalı kaynakları temel alması mümkün olmaktadır.

Türkiye’de engel kalktığından bu yana, Türkçe Vikipedi yeniden büyüyor. Her ay Türkçe konuşan 8.000 gönüllüden meydana gelmiş bir topluluk tarafından geliştirilen maddelerin sayısı, 474.000’i geçmiştir. Vikipedi ve Wikimedia projeleri Türkiye’de ayda 150 milyondan fazla kez görüntüleniyor. Yerel bir gönüllü grubun öncülük ettiği çalışmalar sonucu, çeşitli Türk üniversitelerindeki öğrenciler ders yükümlülüklerinin bir parçası olarak Vikipedi makalelerine katkıda bulunuyor ve Türkiye’deki müzeciler, bilgilerini Vikipedi’ye nasıl ekleyebileceklerini öğreniyor.

Wikimedia Vakfı, Can Yeğinsu (3 Verulam Buildings, Londra) ve Gönenç Gürkaynak (ELIG Gurkaynak Attorneys-at-Law, İstanbul ) tarafından temsil edilmektedir. Son beş yıldaki hukuki hizmetleri için takdirimizi hararetle ifade ederiz.

This article was originally published on March 2nd, 2022 on the Unesco Bangkok Asia and Pacific Regional Bureau for Education.

Photographic contribution to the Brao people Wikipedia article by youth trainee Pem Peak (19 years old, Brao Indigenous community, Ratanakiri Province, Cambodia). CC-BY-SA Pem Peak

On this year’s International Mother Language Day (21 February 2022), UNESCO and Bophana Audiovisual Resource Center (Bophana Center) kicked off a five-day, capacity-building workshop in which Indigenous youth from Cambodia’s Ratanakiri Province learned how to use wiki tools and platforms to create an Indigenous Audiovisual Archive.

Part of the wider UNESCO–Bophana Center project ‘Build Capacity for Indigenous Youth and Create Indigenous Audiovisual Archives Using Wiki Tools in Cambodia’, with support provided by the Wikimedia Foundation, the capacity-building activity was held at the Bophana Center in Phnom Penh from 21 through 25 February 2022.

With live in-person and online support provided by Bophana Center and the Wikimedia Foundation, 24 youth from Brao, Jarai, Kachok, Kreung and Tampuan Indigenous communities were instructed in how to create user accounts, upload their own audiovisual works to Wikimedia Commons, and contribute to existing Wikipedia pages on their affiliated communities. A total of 69 audiovisual documents, including 47 photographs and 22 videos, were uploaded during the course of the project. (The documents are currently being organized on Wikimedia Commons with categories and project pages.) Additionally, five Wikipedia pages were edited and updated.

Video: Mouen Ramich, A Tasty Drop, CC BY-SA 4.0

Notably, five of the youth participants made information history by being the first contributors of audiovisual resources to Wikipedia pages on Brao people and Kaco’ (Kachok) language, which up to that time lacked photographic or video contributions. Moreover, youth participants created a community of Indigenous users in Cambodia and provided original documentation of their languages and cultures as open-access resources for future users to learn from, and re-use and adapt for research, professional, or creative purposes.

These achievements are in keeping with the objectives of the Global Action Plan for the UN’s International Decade of Indigenous Languages 2022–2032 on digital empowerment, media development, access to information and language technology, and artistic creation among indigenous language users.

In addition, the training took an unexpected, happy turn when it also became a ‘Training of Trainers’ activity, when a second group of 13 trainees managed to join the last day of the workshop. On the arrival of the second group, the inaugural 11 trainees took the opportunity to train their colleagues, enthusiastically demonstrating notable leadership skills as the new set of trainees swiftly learned new archival skills from their peers.

Some of the Indigenous youth were paid a surprise visit from actress Angelina Jolie and her daughter Shiloh Jolie-Pitt on the evening of 24 February, following a film screening held at the Bophana Center that same evening.

The following evening, new trainees were awarded certificates at a graduation ceremony held at Bophana Center, which was opened by His Excellency Mr Som Sokun, Secretary of State of the Cambodia Ministry of Culture and Fine Arts, and by Mr Masanori Nagaoka, UNESCO Phnom Penh Programme Specialist for Culture. Both representatives warmly congratulated the trainees on the audiovisual documentation of Indigenous languages and cultures that had been created, as well as the information and media skills all workshop participants had newly acquired. Future plans are to continue toward the collaborative realization of a consolidated Indigenous Audiovisual Archive as a learning, teaching and research tool for regional and global audiences.

Digital Services Librarian Brandon Katzir wanted to learn how to edit Wikidata and build queries using SPARQL — so he signed up for Wiki Education’s Wikidata Institute class.

“The class gave me a foundation in things like Wikidata data structures, and it also taught me how to query and use different kinds of tools in Wikidata,” he says. “Most importantly, the class points you to a lot of great resources and projects to get involved with or learn from even after the class is over.”

Brandon, who works at Oklahoma State University, added some information on Oklahoma government to Wikidata. His research interests including Jewish studies in literary studies, so he also edited some items related to Yiddish authors and their books. Even though the course has wrapped up, Brandon has continued to edit more in these topic areas.

“Editing Wikidata is really a pretty enjoyable process, and there’s a great community of editors on the site if you get stuck,” he says.

His favorite part of Wikidata is (unsurprisingly for a librarian) adding solid references to things he cares about. He also enjoys using Recoin, which was introduced in the Wikidata Institute curriculum, to fill in missing information. Recently, he’s been doing more SPARQL queries to find answers to interesting questions.

Brandon encourages other library professionals to learn more about Wikidata, and says the Wikidata Institute was a great first step for him.

“Wikidata challenges me to think about connecting library collections to Wikidata and the (ideally) reciprocal relationships between libraries and Wikidata,” he says. “Other professionals should engage because Wikidata is a massive dataset, but it’s still only as good as the contributions made. The more contributions, the better, more representative, and more precise Wikidata can be.”

The class taught him what he wanted to know — and also sparked an interest in Wikidata’s lexemes. While much of Wikidata is focused on documenting concepts, Wikidata also contains a structured database of words, their parts, and phrases — lexicographical data. (Want to see one in action? Click on the Random Lexeme link in the left column of Wikidata.)

“I have a longstanding interest in dictionaries and lexicography,” Brandon says. “I think there’s a very human impulse to try and catalog and describe the entirety of a language. A century ago, people were doing this with massive, multi-volume books. It makes sense that today we’d try and do this with datasets that can, ideally, aid with translation, AI, natural language processing, etc. It’s a huge task, obviously, but I’m very interested in seeing how it develops and the applications that arise from lexemes.”

Overall, the course exceeded Brandon’s expectations, and left him encouraging more people to take it.

“The class was great, I highly recommend it, you’ll learn a lot about Wikidata and get valuable resources to continue your knowledge after the class,” he says.

To sign up for the Wikidata institute, visit wikiedu.org/wikidata.

Image credit: Brandon Katzir, CC BY-SA 4.0, via Wikimedia Commons

Before the pandemic, Wikimedia Ukraine regularly provided scholarships for Ukrainian community members to attend major international events like Wikimania. In 2021, as Wikimania returned in the online format, we ran scholarship programs for two online conferences – Wikimania itself and CEE Meeting.

The scholarships could cover small expenses that enabled people to participate in online events – such as data plans, childcare, or technical support.

In this article, we summarize how we organized these programs and what we learned by providing online participation scholarships for the first time.

How we structured scholarship programs

Expenses covered

Within the scholarship programs, we offered to cover all reasonable expenses directly related to virtual Wikimania / CEE Meeting participation, such as technical equipment or care services.

The most popular request was purchasing technical accessories that enable online participation – for example, one scholarship recipient bought headphones so as not to distract other family members when participating in the conference.

The second most popular category was covering a reserve data plan for applicants who feared their existing internet connection wouldn’t be sufficient to participate in online events.

As examples in the call for applications, we also offered to cover the cost of renting technical equipment like laptops, as well as childcare. However, we received no requests for these two items.

Promotion

We spread the word about the scholarship opportunity on Ukrainian Wikipedia’s Village Pump and various UkWiki noticeboards, as well as on Wikimedia Ukraine’s social media channels.

We also reached out directly to members of Wikimedia Ukraine NGO, as well as to community members who participated in international events before. For Wikimania, we also ran a two-day SiteNotice banner campaign on Ukrainian Wikipedia.

Application & approval process

Application for scholarships opened a few weeks before the event and closed a few days before the conference started.

The scholarships were available to all community members in good standing. The formal prerequisite was having either at least 100 edits in Ukrainian-language Wikimedia projects or demonstrated non-edit contribution, such as event organizing.

To apply, people had to fill out a brief Google Form, which took about 5 to 10 minutes to complete, as well as sign up for the conference itself.

For scholarships to in-person Wikimanias, we used to create a scholarships committee that would review and grade all applications, choosing winning ones. However, for online scholarships, given that the monetary amounts were much lower, the process was considerably simpler – the applications were reviewed by Wikimedia Ukraine’s programs coordinator, with final approval by the Board member responsible for the community support direction.

We ended up approving all applications that were filled according to the rules of the program. (Only one application was rejected; the applicant there asked for an expensive item not related to online event participation).

Reporting process

As a general rule, scholarship recipients had to make the expenses themselves before or during the conference – and get reimbursed after submitting the report after the conference.

Scholarship reporting consisted of submitting documents certifying the expenses, such as receipts, as well as a brief narrative report detailing most interesting ideas the participant heard during the event in general and during one specific session of their choosing.

Reports were checked and approved by Wikimedia Ukraine’s programs coordinator, with the financial part additionally checked by the accountant.

Observations and lessons learned

Relatively few people used the opportunity

In the end, we saw relatively few people actually using the scholarships – in 2021, Wikimedia Ukraine granted four scholarships for Wikimania and five scholarships for CEE Meeting.

We ended up spending just over $100 on all individual scholarships in 2021, which is considerably less than we could have committed had there been more requests.

Perhaps the main reason for the scholarships’ relative unpopularity is that most community members already have the technical conditions to participate in online events. Particularly, internet connection is generally cheap and ubiquitous in Ukraine, so expensive data wasn’t an issue.

The biggest obstacle from participating in international online events isn’t strictly technical but rather a broader one. While it’s natural to take a leave for work or studies, or family commitments while traveling to a conference in another country, it’s less so when you can join via Zoom or Remo from your bedroom. (Wikimedia Ukraine’s scholarships didn’t compensate for taking unpaid leave from work, though we did offer to cover care services).

Even when other commitments aren’t an issue, online events obviously don’t create the same in-depth environment that helps leave everything else behind and focus on the conference.

However, scholarships helped popularize international events

Although few people applied for a monetary scholarship, the Ukrainian community’s participation in both conferences was much higher. It would be safe to say that more people from our community attended Wikimania and CEE Meeting than ever before.

That’s partly just because of the online nature of the events and partly because both conferences were interpreted in Russian, a language many Ukrainians know. However, we noticed that Wikimedia Ukraine’s communications around these events for the community played a big role in attracting more people.

Scholarship programs were a good opportunity to remind people about the events – even if they didn’t actually need a scholarship to participate.

For example, thanks to a banner campaign about Wikimania scholarships, Wikimedia Ukraine’s blog post about the conference became one of the most popular entries of the year, attracting 500 page views in a few days.

The upshot

Having run two scholarship programs in 2021, we learned that providing scholarships for online events isn’t a panacea, and organizing local in-person meetups around international online conferences like Wikimania when possible is probably a more efficient way to engage people (Wikimedia Ukraine organized two in-person meetups around Wikimania 2021, a local meetup in Kharkiv during Wikimania and a conference in Kyiv after Wikimania). At the same time, scholarships for online conferences do play an important role, whether directly by enabling people to participate in the events they otherwise couldn’t attend or indirectly by helping spread the word.

• This article was previously published as Wikimedia Ukraine’s learning story for its 2021 grant report.
• Learn more how you can support Ukraine in its struggle against the Russian invasion here and here.

08/03/2022-14/03/2022

Mapping campaigns

• OSM Ghana tweeted statistics of their #28DaysMappingChallenge. In February OSM Ghana started a campaign to motivate people to make contributions to OSM on each day of the month. They garnered 598,386 edits from 69 contributors.
• Becky Candy wrote about live validation during a mapathon.
• Flanders Tourism launched a website to gather data on tourism POIs, such as: charging points for electric bikes, playgrounds, picnic tables and benches. This project, built upon MapComplete, entails a public campaign with a video presentation and a data import . The developer gave a quick overview in his diary.
• raphaelmirc presents > MapSãoFrancisco, an initiative of Canoa de Tolda and InfoSãoFrancisco that aims to develop collaborative mapping projects throughout the São Francisco river basin (Brazil).
• The new UMBRAOSM event will be held > on Saturday 2 April, from 00:00 to 23:59 (UTC-3). It will be a mapathon focusing on buildings, roads, POIs, and green areas.

Mapping

• Christoph Hormann presented his ‘TagDoc Project’, which is intended to offer an alternative to the OSM Wiki with the focus on the de facto use of tags.
• The following proposals await your comments:
  • opening_hours:autism=* to facilitate people looking for autism friendly opening hours.
  • artwork_subject=sheela-na-gig to tag ‘Sheela-na-gigs’, stone carvings depicting nude women exposing their genitals, found on churches, castles, other walls and in museums.

Community

• The Korea OSM community has decided > to change Ukrainian OSM place names in Korean from Russian notation (e.g. 키예프 – as same ‘Kiev’, 하리코프 – as same ‘Kharkov’) to Ukrainian notation (e.g. 키이우 – as same ‘Kyiv’, 하르키우 – as same ‘Kharkiv’) and is currently editing OSM. The revision of the notation is based on the National Institute of Korean Language’s Ukrainian Geographical Names and Personal Information Collection (2022-03-11) .
• The OpenStreetMap Ops Team tweeted that the new Discourse based Community Forum has launched. The community is invited to participate in the next steps.
• The OSM community of Burgos, Spain, is planning several activities, including a mapathon and talks on 1 and 2 April. More information on the event is available on the wiki page.
• OSM Fukushima members have released videos introducing weeklyOSM 603 and 604 . After introducing weeklyOSM, they interviewed Hokkosha, one of the most active mappers in Japan.

OpenStreetMap Foundation

• Paul Norman explained: the usage polices for Nominatim and OSM Map Tiles, automatic blocking, and how to fix too frequent requests.

Events

• On Saturday 19 March, Maptime Bogota brought together > mappers virtually to update the representation of bike paths in OSM for the Colombian capital.
• Thanks to C3VOC, video recordings from FOSSGIS 2022 are now available .
• Save the date for Open Belgium 2022, which will be held on Friday 29 April at De Krook, in Ghent, as a real-life event. If you have an idea for a talk or workshop, submit it yourself or ask for advice on how to (deadline is Monday 21 March).

Education

• raphaelmirc presented / the Drought Monitoring Map > for Brazil.

OSM research

• Datenschatz has written a detailed tutorial on how one can systematically identify and visualise missing data points in OSM data with the help of Pandas and a bit of geo-datascience. The data he is using to compare are health departments in Germany.
• Transport researchers are studying how open data (such as OSM) stimulates digital civic engagement. One of them has asked mappers to participate in a five minute survey.

Maps

• K. Sakanoshita has developed an online map to show historic objects in Ukraine.
• [1] The Fédération française des Usagers de la Bicyclette (French National Cyclists Association) has published > the results of the 2021, and third, edition of the ‘aromètre Parlons Vélo‘ which is a nationwide survey about bicycle usage. A general map shows > the multiple cities ranking, while a second one shows > locations perceived as problematic, improved or where a parking solution is needed.
• Liveuamap has made an OSM based interactive map showing the latest news in Ukraine.

Open Data

• On the occasion of the NYC Open Data Week, mapper jmapb gave a short introduction to the Building Information Search Tool of the NYC Department of Buildings.

Software

• yuiseki has developed an online tool to assist in editing building address data. Currently, only Japanese addresses are supported, but he plans to support the entire world in the future. The source code is available on GitHub.
• The Technical University of Darmstadt presented the ‘Intermodal Travel Information’ Motis-Project on media.ccc.de. A demonstration application and the sources are available.
• RouteXL is a web appplication using OpenStreetMap data for road itinerary planning, with optimisation for multiple stops to save travel time and cost. It is free to use for routes of up to 20 stops. Various geocoders can be selected including Nominatim.
• Strasbourg launched its mobile application StrasApp > , which provides a map view to users through OpenMapTiles. Unfortunately, as has been noted > , with a complete lack of attribution of either OpenMapTiles or OpenStreetMap as requested by the OpenMapTiler group.

Programming

• Geofabrik presented ‘Shortbread‘, a basic, lean, general-purpose vector tile schema for OpenStreetMap data, CC0/FTWPL licensed.
• Sarah Hoffmann pointed out > that OpenStreetMap is participating in the Google Summer of Code as an organisation and the first project ideas for it have been made.

Releases

• Vespucci’s March 2022 maintenance release 17.04 is now available in the Play Store.

Did you know …

• … BBBike Map Compare for comparing maps? You can use it find out if Waze uses OSM without attribution, for example.
• … the new Twitter account OSMChangesets?

OSM in the media

• Robert Goedl described > how to use Maperitive to edit OpenStreetMap maps on Linux.

Other “geo” things

• In the era of phones and online navigation maps, the police emergency response to a shooting in rural Nova Scotia (Canada) showed that the police local units did not have a rapid and reliable backup system for road navigation and aerial images. They consulted an online map that provided road navigation results that seemed unreliable to people that knew the area.
• contrapunctus asked on OSMIndia: ‘Does anyone know of any opportunities to be a full-time, professional OSM mapper?’. They received a number of accurate answers.

Upcoming Events

Where	What	Online	When	Country
臺北市	OpenStreetMap街景踏查團工作坊1		2022-03-19
Ciudad de Guatemala	Primer mapatón YouthMappers en Guatemala (remoto)		2022-03-19 – 2022-03-20	gt
City of Subiaco	Social Mapping Sunday: Shenton Park		2022-03-20
Habay-la-Neuve	Réunion des contributeurs OpenStreetMap, Habay-la-Neuve		2022-03-21
	OSMF Engineering Working Group meeting		2022-03-21
	Why Open Data Matters for Cycling: Visualizing a Cycling City		2022-03-22
Barcelona	Geomob Barcelona		2022-03-22
City of Nottingham	OSM East Midlands/Nottingham meetup (online)	✓	2022-03-22
Decatur County	OSM US Mappy Hour		2022-03-24
	[Online] OpenStreetMap Foundation board of Directors – public videomeeting		2022-03-24
IJmuiden	OSM Nederland bijeenkomst (online)	✓	2022-03-26
06060	Reunión Bimestral OSM-LatAm		2022-03-26
Perth	Social Mapping Online	✓	2022-03-27
Bremen	Bremer Mappertreffen (Online)	✓	2022-03-28
San Jose	South Bay Map Night	✓	2022-03-30
Ville de Bruxelles – Stad Brussel	Virtual OpenStreetMap Belgium meeting	✓	2022-03-29
Tucson	State of the Map US		2022-04-01 – 2022-04-03
Burgos	Evento OpenStreetMap Burgos (Spain) 2022		2022-04-01 – 2022-04-03
Stuttgart	Stuttgarter Stammtisch		2022-04-05
London	Missing Maps London Mapathon		2022-04-05
Berlin	OSM-Verkehrswende #34 (Online)	✓	2022-04-05

Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there, will appear in weeklyOSM.

This weeklyOSM was produced by Lejun, Nordpfeil, PierZen, SK53, Sammyhawkrad, SomeoneElse, Strubbl, Ted Johnson, TheSwavu, YoViajo, derFred, jcr83, muramototomoya.[

How’d we do in our strive for operational excellence last month? Read on to find out!

Incidents

3 documented incidents last month.

2022-02-01 ulsfo network
Impact: For 3 minutes, clients served by the ulsfo POP were not able to contribute or display un-cached pages.

2022-02-22 wdqs updater codfw
Impact: For 2 hours, WDQS updates failed to be processed. Most bots and tools were unable to edit Wikidata during this time.

2022-02-22 vrts
Impact: For 12 hours, incoming emails to a specific recently created VRTS queue were not processed with senders receiving a bounce with an SMTP 550 Error.

Figure from Incident graphs.

Incident follow-up

Remember to review and schedule Incident Follow-up work in Phabricator, which are preventive measures and tech debt mitigations written down after an incident is concluded. Read about past incidents at Incident status on Wikitech.

Recently conducted incident follow-up:

Create a dashboard for Prometheus metrics about health of Prometheus itself.
Pitched by CDanis after an April 2019 incident, carried out by Filippo (@fgiunchedi).

Improve wording around AbuseFilter messages about throttling functionality.
Originally filed in 2018. This came up last month during an incident where the wording may've led to a misunderstanding. Now resolved by @Daimona.

Exclude restart procedure from automated Elasticsearch provisioning.
There can be too much automation! Filed after an incident last September. Fixed by @RKemper.

Outstanding errors

Take a look at the workboard and look for tasks that could use your help.

View Workboard

I skip breakdowns most months as each breakdown has its flaws. However, I hear people find them useful, so I'll try to do them from time to time with my noted caveats. The last breakdown was in the December edition, which focussed on throughput during a typical month. Important to recognise is that neither high nor low throughput is per-se good or bad. It's good when issues are detected, reported, and triaged correctly. It's also good if a team's components are stable and don't produce any errors. A report may be found to be invalid or a duplicate, which is sometimes only determined a few weeks later.

The below "after six months" breakdown takes more of that into consideration by looking at what's on the table after six months (tasks upto Sept 2021). This may be considered "fairer" in some sense, although has the drawback of suffering from hindsight bias, and possibly not highlighting current or most urgent areas.

WMF Product:

• Anti Harassment Tools (3): 1 MW Blocks, 2 SecurePoll.
• Community Tech (0).
• Design Systems (1): 1 WVUI.
• Editing Team (15): 14 VisualEditor, 1 OOUI.
• Growth Team (13): 11 Flow, 1 GrowthExperiments, 1 MW Recent changes.
• Language Team (6): 4 ContentTranslation, 1 CX-server, 1 Translate extension.
• Parsoid Team (9): 8 Parsoid, 1 ParserFunctions extension .
• Product Infrastructure: 2 JsonConfig, 1 Kartographer, 1 WikimediaEvents.
• Reading Web (0).
• Structured Data (4): 2 MW Uploading, 1 WikibaseMediaInfo, 1 3D extension.

WMF Tech:

• Data Engineering: 1 EventLogging.
• Fundraising Tech: 1 CentralNotice.
• Performance: 1 Rdbms.
• Platform MediaWiki Team (19): 4 MW-Page-data, 1 MW-REST-API, 1 MW-Action-API, 1 MW-Snapshots, 1 MW-ContentHandler, 1 MW-JobQueue, 1 MW-libs-RequestTimeout, 9 Other.
• Search Platform: 1 MW-Seach.
• SRE Service Operations: 1 Other.

WMDE:

• WMDE-Wikidata (7): 5 Wikibase, 2 Lexeme.
• WMDE-TechWish: 1 FileImporter.

Other:

• Missing steward (7): 2 Graph, 2 LiquidThreads, 2 TimedMediaHandler, 1 MW Special-Contributions-page.
• Individually maintained (2): 1 WikimediaIncubator, 1 Score extension.

Trends

In February, we reported 25 new production errors. Of those, 13 have since been resolved, and 12 remain open as of today (two weeks into the following month). We also resolved 22 errors that remained open from previous months. The overall workboard has grown slightly to a total of 301 outstanding error reports.

For the month-over-month numbers, refer to the spreadsheet data.

Thanks!

Thank you to everyone who helped by reporting, investigating, or resolving problems in Wikimedia production. Thanks!

Until next time,

– Timo Tijhof

What is a Wikimedia Hackathon?

A Wikimedia Hackathon is a space for the technical community to come together and work together on technical projects, learn from each other, and make new friends. 

When is the Hackathon?

May 20-May 22. The schedule will be announced soon. We are trying to plan events so that people in all time zones can participate comfortably. There will be core hours several times a day when most events will occur, and online social and hacking spaces open 24 hours a day throughout the three days.

Who should participate?

The Hackathon is for anyone who contributes (or wants to contribute!) to Wikimedia’s technical areas – as code creators, maintainers, translators, designers, technical writers and other technical roles. You can come with a project in mind, join an existing project, or create something new with others. The choice is yours! Newcomers are welcome.

How to participate?

To help out as a volunteer, see “How to Participate“. Add yourself to the participants list, and mention if you would like to help with tasks such as facilitation or welcoming newcomers.

Information on how to schedule a session will be available later. For now, use this Talk page or other communication channels to express your interest and discuss ideas for sessions.

Grants for local meetups

Technical community members and affiliates can apply for Rapid Fund grants to host local meetups during or around the Hackathon! Grants can be between 500 and 5,000 USD. The deadline to apply is March 27, 2022. This is a quick turn-around, so note that proposals do not have to be extensive or complex. Get all the info about how to apply on the Hackathon MediaWiki.org page.

Scholarship stipends

The Wikimedia Foundation provides stipends to support individuals attending the 2022 Wikimedia Hackathon. You can apply to cover Hackathon-related expenses such as:

• childcare services (or similar family services)
• data packages
• administrative or operational costs to distribute funds to community members
• small hardware expenses to support access
• other relevant purchases.

All stipends are $100 USD, with an added $25 USD for related bank fees. Applications are due April 1. For more information, and how to apply, visit the Hackathon MediaWiki.org page.

More information

You can find more information on the Hackathon MediaWiki.org page, which will continue to grow over the next few weeks.

About this post

Featured image credit: File:Martha_-cat_reads_up_on_aquariums.jpg, Paulo O, CC Attribution 2.0 Generic License

Wiki Education welcomes Peter B. Kaufman to our Advisory Board as its newest member helping to raise our profile to potential supporters.

“I am excited to join the Advisory Board of Wiki Education because their work is critically important, especially for knowledge institutions, such as universities, museums, and archives,” Peter says.

Peter is a writer, teacher, and film producer, who works at MIT Open Learning and is the author of The New Enlightenment and the Fight to Free Knowledge. A sample of Peter’s prestigious positions previously held include: associate director of Columbia University’s Center for Teaching and Learning; president and executive producer of Intelligent Television; co-chair of the JISC Film & Sound Think Tank in the United Kingdom; co-chair of the Copyright Committee of the Association of Moving Image Archivists; president and publisher of TV Books at Broadway Video; and a consultant to the Library of Congress’s National Audiovisual Conservation Center.

He is a member of the editorial board of The Moving Image and the editorial advisory board of the Russian Library at Columbia University Press. He has worked with media and nonprofits for 35 years and is at work on a new book about the new responsibilities of knowledge institutions during our time of epistemic chaos.

“For my entire professional life, I have been an advocate for increasing access to information and the tools to disseminate it. I’m honored to be invited to play a role for Wiki Education,” Peter adds.

We are delighted to have Peter’s extensive experience on our Advisory Board as we strive to realize our vision of the sum of all human knowledge on Wikipedia.