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 [email protected] 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 [email protected]

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 [email protected] 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: [email protected]

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.

By Arturo Borrero González, Site Reliability Engineer, Wikimedia Cloud Services Team

This post continues the discussion of Toolforge updates as described in a previous post. Every non-trivial task performed in Toolforge (like executing a script or running a bot) should be dispatched to a job scheduling backend, which ensures that the job is run in a suitable place with sufficient resources.

Jobs can be scheduled synchronously or asynchronously, continuously, or simply executed once. The basic principle of running jobs is fairly straightforward:

• You create a job from a submission server (usually login.toolforge.org).
• The backend finds a suitable execution node to run the job on, and starts it once resources are available.
• As it runs, the job will send output and errors to files until the job completes or is aborted.

So far, if a tool developer wanted to work with jobs, the Toolforge Grid Engine backend was the only suitable choice. This is despite the fact that Kubernetes supports this kind of workload natively. The truth is that we never prepared our Kubernetes environment to work with jobs. Luckily that has changed.

We no longer want to run Grid Engine

In a previous blog post we shared information about our desired future for Grid Engine in Toolforge. Our intention is to discontinue our usage of this technology.

Convenient way of running jobs on Toolforge Kubernetes

Some advanced Toolforge users really wanted to use Kubernetes. They were aware of the lack of abstractions or helpers, so they were forced to use the raw Kubernetes API. Eventually, they figured everything out and managed to succeed. The result of this move was in the form of docs on Wikitech and a few dozen jobs running on Kubernetes for the first time.

We were aware of this, and this initiative was much in sync with our ultimate goal: to promote Kubernetes over Grid Engine. We rolled up our sleeves and started thinking of a way to abstract and make it easy to run jobs without having to deal with lots of YAML and the raw Kubernetes API.

There is a precedent: the webservice command does exactly that. It hides all the details behind a simple command line interface to start/stop a web app running on Kubernetes. However, we wanted to go even further, be more flexible and prepare ourselves for more situations in the future: we decided to create a complete new REST API to wrap the jobs functionality in Toolforge Kubernetes. The Toolforge Jobs Framework was born.

Toolforge Jobs Framework components

The new framework is a small collection of components. As of this writing, we have three:

• The REST API — responsible for creating/deleting/listing jobs on the Kubernetes system.
• A command line interface — to interact with the REST API above.
• An emailer — to notify users about their jobs activity in the Kubernetes system.

There were a couple of challenges that weren’t trivial to solve. The authentication and authorization against the Kubernetes API was one of them. The other was deciding on the semantics of the new REST API itself. If you are curious, we invite you to take a look at the documentation we have in wikitech.

Open beta phase

Once we gained some confidence with the new framework, in July 2021 we decided to start a beta phase. We suggested some advanced Toolforge users try out the new framework. We tracked this phase in Phabricator, where our collaborators quickly started reporting some early bugs, helping each other, and creating new feature requests.

Moreover, when we launched the Grid Engine migration from Debian 9 Stretch to Debian 10 Buster we took a step forward and started promoting the new jobs framework as a viable replacement for the grid. Some official documentation pages were created on wikitech as well.

As of this writing the framework continues in beta phase. We have solved basically all of the most important bugs, and we already started thinking on how to address the few feature requests that are missing.

We haven’t yet established yet the criteria for leaving the beta phase, but it would be good to have:

• Critical bugs fixed and most feature requests addressed (or at least somehow planned).
• Proper automated test coverage. We can do better on testing the different software components to ensure they are as bug free as possible. This also would make sure that contributing changes is easy.
• REST API swagger integration.
• Deployment automation. Deploying the REST API and the emailer is tedious. This is tracked in Phabricator.
• Documentation, documentation, documentation.

Limitations

One of the limitations we bear in mind since early on in the development process of this framework was the support for mixing different programming languages or runtime environments in the same job.

Solving this limitation is currently one of the WMCS team priorities, because this is one of the key workflows that was available on Grid Engine. The moment we address it, the framework adoption will grow, and it will pretty much enable the same workflows as in the grid, if not more advanced and featureful.

Stay tuned for more upcoming blog posts with additional information about Toolforge.

While we surely must not shy away from looking at what develops with and around Open Content and for solutions of harmful effects we must seek beyond the licensing level. We shouldn’t try to leverage copyright as a prohibitive means unless we are willing to sacrifice the idea of the Open Content altogether.

Read the introduction to the debate

Read Anna Mazgal’s take on the issue

New technologies mean new dark sides

The breathtaking potential of automated systems includes a breathtaking danger of abuse. One might argue, however, that facial recognition is not actually an application of artificial intelligence technology, but a rather sophisticated method of pattern recognition combined with an instance of deep learning mechanisms. We should widen the scope to the digital content used for enhancing autonomous systems or automation in general – the term Automated Decision-Making, ADM, comes to mind. 

Nobody interested in digital technology, the internet, and fundamental rights should disengage from the debate around such systems and how to regulate them. At the same time we have to be quite precise about the types of content we are talking about. It’s not only because the property of being open (in the meaning of the open definition and the definition of Free Cultural Works) is key here. Also because the possible means for regulation differ according to the content in question.

Openness isn’t about more leverage, it’s about less control

An openness that means “here’s content that you can use, unless your use is something we don’t approve of” is a very peculiar kind of openness. The friction produced by the infamous non-commercial clause (NC) in some CC licences is a very telling example of that peculiarity. Even though NC can make sense as a means to restrict certain uses (and users), it mostly restricts the wrong ones. 

If you focus your view on a tiny group of potential users you want to control or exclude, restrictions can make a lot of sense. And that, by the way, is the idea behind the classic IP licensing where exclusive rights by default exclude everybody except a tiny group that bought the licence. But if one takes into account all potential users, which is the paradigm behind the Open Content, such restrictions limit a number of users far greater than intended. Depending on the context, the ratio is probably that of 2% reasonably restricted vs. 98% collateral effect, although no conclusive research seems to exist on this point.

What free / libre / open licences usually require as a condition is attribution, as laid down for example in the BY clause of the Creative Commons licences. There is a second condition possible in licences meant to qualify as free / libre / open: the copyleft (or as it is known in Creative Commons licences: Share Alike). Just as the attribution condition, copyleft only requires a positive action of preserving the rights of the original in derivative works following the uses that are allowed in the licence grant. It is still far from prohibiting anything or limiting the licence grant in any relevant aspect. So yes, there is some leveraging in copyleft, but it only serves to sustain the openness. 

“The Open Content was given not to “us”, but to the commons – piece by piece by initial individual rightsholders. The commons is a massive amorphous sphere without a single licensing steward.”

How big of a chunk is it anyway?

Being in the middle of an argument about the use of Open Content for training automated systems through deep learning, one very basic question cannot be avoided: how relevant is the chunk of training data coming from the world of Open Content really?

We can’t directly know the answer, but we can make an estimate. There’s little doubt that people responsible for getting trainable systems in contact with content to train on will try to obtain the maximum amount of content that they can get. Thus, the ratio between Open Content on the one hand and all internet content that is practically if not legally available on the internet, on the other, would be indicative of how much training data is actually Open Content.

Creative Commons estimates on the overall size of the commons surely are impressive. The numbers from 2017 range in the lower one-digit Billions, with an impressive growth rate. Yet, looking for example at the image content that is so very important in general and for the topic at hand in this text, compared to the overall amount of pictures on the internet, including social media platforms and such, the amount of CC-licensed works is tiny.

A Commons is not about ownership

One might say: “But still, we must at least take care of what is done with our content, even if that’s only a small chunk!”. Well, here’s the hard truth that is both wonderful and annoying: Open Content belongs to all and thus to nobody in particular. It was given not to “us”, but to the commons – piece by piece by initial individual rightsholders. The commons is a massive amorphous cloud-like sphere without a single licensing steward. No group of enthusiasts or activists owns the commons, nor can it claim that they are tasked with custodianship of it.

A retroactive change to the notion of Open would be equal to a departure from the existing model into a whole new digital commons through a gigantic fork of code, a schism of Openness. With a sufficient reason for such a schism, it shouldn’t be unthinkable. The question is whether countering undesirable effects of facial recognition technology is a sufficient reason. The author of these lines thinks it’s not, in particular because there in fact are other means beyond the licences that are better adapted to the purpose.

“A retroactive change to the notion of Open would be equal to a departure from the existing model into a whole new digital commons through a gigantic fork of code, a schism of Openness. “

A mandate on the input side, sure, but hardly any on the output side

As the Open Content does not belong to anybody in particular, there’s a question of our political mandate in advocacy. Nobody has a mandate to limit or widen the scope of permission that was chosen by the contributing person at the point when a piece of content joined the commons. And, as stated above, the scope of permission in the Open Content as we know it does not limit or even talk about the purposes for which that content may be used.

It’s thus highly questionable whether it is the job of Wikimedians to purposefully engage in political framing outside of the core purpose of the Wikimedia projects. Working towards “… a world in which every single human being can freely share in the sum of all knowledge” definitely doesn’t extend to influencing what all those humans do with that resource. To have it regulated by the European Union or any other body what others can or cannot do with knowledge means going beyond the objective of free sharing and of our mandate.

Licence proliferation

Finally, there’s one rather legalistic topic that is often pushed aside: licence proliferation. In this context it means that the overall pool of content licensed freely for the purposes of remixing or derivation is made available under various licences. This hinders the objective behind the Open Content due to increased complexity and licence incompatibility. Incompatibility in this sense means that at least one of the licences cannot be adhered to without breaching the terms of the other. 

Open Content is all about enabling non-lawyers to freely engage in creative expression, without the barbed-wire fences that the prohibitive copyright laws erect everywhere. It is about lowering the so-called transaction costs to a level where even non-profit projects and individuals can dare handle copyrighted material in a reasonably safe way. That requires simplicity. 

Solutions beyond licences

Restricting certain purposes of use is alien to the Open Content definitions we have. Unless we want to risk dividing the open world into separate parts and boosting licence proliferation, we are stuck with the liberal definition of Open. 

Instead, we should engage in pushing back against problematic developments around digital content – if we think our mission covers that – in ways that do not touch the core rights granted in open licensing. We should focus on personality rights and privacy law. These fields are more adequate to meaningfully address facial recognition and might prove much more effective than tinkering with a myriad of individual rights grants.

• this article is an abbreviated version of John’s essay – read in full here

John Weitzmann serves as General Counsel of the Wikimedia Chapter in Germany, where he previously also re-built and headed the advocacy team.

The Bombay Natural History Society offers an interesting case in the history of amateur science in India and there are many little stories hidden away that have not quite been written about, possibly due to the lack of publicly accessible archival material. Interestingly two of the founders of the BNHS were Indians and hardly anything has been written about them in the pages of the Journal of the Bombay Natural History Society where even lesser known British members have obituaries. I suspect that this lack of obituaries can be traced to the political and social turmoil of the period. Even a major two-part history of the BNHS by Salim Ali in 1978 makes no mention of the Indians founders. Both the founders were doctors with an interest in medical botany and were connected to other naturalists not just because of their interest in plants but also perhaps through their involvement in social reform. The only colleague who could have written their obituaries was the BNHS member Dr Kanhoba Ranchoddas Kirtikar who probably did not because of his conservative-views and a consequent fall-out with the reformists. This is merely my suspicion and it arises from reading between the lines while editing the  relevant entries on the English Wikipedia. There are some rather interesting connections.

Sakharam Arjun

Dr Sakharam Arjun (Raut) (1839-16 April 1885) - This medical doctor with an interest in botanical remedies was for sometime a teacher of botany at the Grant Medical College - but his name perhaps became more well known after a historic court case dealing with child marriage and women's rights, that of Dadaji vs. Rukhmabai. Rukhmabai had been married off at the age of 11 and stayed with her mother and step-father Sakharam Arjun. When she reached puberty, she was asked by Dadaji to join him. Rukhmabai refused and Sakharam Arjun supported her. It led to a series of court cases, the first of which was in Rukhmabai's favour. This rankled the Hindu conservatives who believed that this was a display of the moral superiority of the English. The judge had in reality found fault with English law and had commented on the patriarchal and unfair system of marriage that had already been questioned back in England. A subsequent appeal was ruled in favour of Dadaji and Rukhmabai was ordered to go to his home or face six months in prison. Rukhmabai was in the meantime writing a series of articles in the Times of India under the pen-name of A Hindoo Lady (wish there was a nice online Indian newspapers archive) and she declared that she would rather take the maximal prison penalty. This led to further worries - with Queen Victoria and the Viceroy jumping into the fray. Max Müller commented on the case, while Behramji Malabari and Allan Octavian Hume (now retired from ornithology; there may be another connection as Sakharam Arjun seems to have been a member of the Theosophical Society, founded by Hume and others before he quit it) debated various aspects. Somewhat surprisingly Hume tended to being less radical about reforms than Malabari.

Dr Rukhmabai

Dr Edith Pechey

Dr Sakharam Arjun did not live to see the judgement, and he probably died early thanks to the stress it created. His step-daughter Rukhmabai became one of the earliest Indian women doctors and was supported in her cause by Dr Edith Pechey, another pioneering English woman doctor, who was a BNHS member went on to marry H.M. Phipson. Phipson of course was a more famous founder of the BNHS. Rukhmabai's counsel included the lawyer J.D.Inverarity who was a big-game hunter and BNHS member. To add to the mess of BNHS members in court, there was (later Lt.-Col.) Kanhoba Ranchoddas Kirtikar (1850-9 May 1917), a student of Sakharam Arjun and like him interested in medicinal plants. Kirtikar however became a hostile witness in the Rukhmabai case, and supported Dadaji. Rukhmabai, in her writings as a Hindoo Lady, indicated her interest in studying medicine. Dr Pechey and others set up a fund for supporting her medical education in London. The whole case caused a tremendous upheaval in India with a division across multiple axes -  nationalists, reformists, conservatives, liberals, feminists, Indians, Europeans - everyone seems to have got into the debate. The conservative Indians believed that Rukhmabai's defiance of Hindu customs was the obvious result of a western influence.

J.D.Inverarity, Barrister and Vice President of BNHS (1897-1923) Counsel for Rukhmabai.

It is somewhat odd that the BNHS journal carries no obituary whatsoever to this Indian founding member. I suspect that the only one who may have been asked to write an obituary would have been Kirtikar and he may have refused to write given his stance in court. Another of Sakharam Arjun's students was a Gujarati botanist named Jayakrishna Indraji who perhaps wrote India's first non-English botanical treatise (at least the first that seems to have been based on modern scientific tradition). Indraji seems to be rather sadly largely forgotten except in some pockets of Kutch, in Bhuj. I recently discovered that the organization GUIDE in Bhuj have tried to bring back Indraji into modern attention.

Atmaram Pandurang

The other Indian founder of the BNHS was Dr Atmaram Pandurang Tarkhadkar (1823-1898)- This medical doctor was a founder of the Prarthana Samaj in 1867 in Bombay. He and his theistic reform movement were deeply involved in the Age of Consent debates raised by the Rukhmabai case. An obituary termed him as a "mild Hindu" (this is essentially code at that point to indicate that he was not a "sanatanist"). His organization seems to have taken Max Muller's suggestion that the ills of society could not be cured by laws but by education and social reform. If Sakharam Arjun is not known enough, even lesser is known of Atmaram Pandurang (at least online!) but one can find another natural history connection here - his youngest daughter - Annapurna "Anna" Turkhud tutored Rabindranath Tagore in English and the latter was smitten. Tagore wrote several poems to her where she is referred to as "Nalini". Anna however married Harold Littledale (3 October 1853-11 May 1930), professor of history and English literature, later principal of the Baroda College (Moreshwar Atmaram Turkhud, Anna's older brother, was a vice-principal at Rajkumar College Baroda - another early natural history hub), and if you remember an earlier post where his name occurs - Littledale was the only person from the educational circle to contribute to Allan Octavian Hume's notes on birds! Littledale also documented bird trapping techniques in Gujarat. Sadly, Anna did not live very long and died in her thirties in Edinburgh somewhere around 1891.

It would appear that many others in the legal profession were associated with natural history - we have already seen the case of Courtenay Ilbert, who founded the Simla Natural History Society in 1885. Ilbert lived at Chapslee House in Simla - now still a carefully maintained heritage home (that I had the fortune of visiting recently) owned by the kin of Maharaja Ranjit Singh. Ilbert was involved with the eponymous Ilbert Bill which allowed Indian judges to pass resolutions on cases involving Europeans - a step forward in equality that also led to rancour. Other law professionals in the BNHS - included Sir Norman A. Macleod and  S. M. Robinson. Justice Herbert Mills Birdwood was a keen botanist. L.H. Bayley was also a BNHS member.

Times of India 7 May 1885. p. 5.

Times of India, 9 July 1885

The Bombay Gazette, 7 November 1884. Note that Kirtikar is present at the early meetings alongside Sakharam Arjun.

Postscript: 18 March 2022 - came across Hugh Fletcher Palin (16 February 1858, Poona - 8 February 1909, Lahore) who wrote a Birds of Cutch (1878). Palin's father Lt-Gen Charles Thomas Palin (6 February 1823- 14 March 1892) also wrote on the birds and plants of Kutch for the Bombay Gazetteer (volume 5, 1880). A sister of Hugh, Ethel Frances, married the son of Herbert Mills Birdwood. A brother of Hugh, Colonel Gilbert Walter Palin (29 September 1862 - 31 December 1946) married Florence, daughter of Charles Swinhoe.

Mark your calendars, everyone! The 2022 Wikimania Core Organizing Team is pleased to announce that Wikimania will take place this year from August 11-14. The conference will be primarily virtual, with support for local gatherings and events where possible. We are excited to bring you all together to connect, learn and celebrate. 

We want to hear from you. We are kicking off our event planning now, looking at things like accessibility, language, topic areas, platforms, and more. We are inviting you to create Wikimania with us. Take this quick survey to give us your suggestions for building an unforgettable Wikimania 2022. The survey will run from now until 31 March. 

We will also be offering some small group discussions in different languages. If you want to attend a small group discussion, keep your eye on the Meta page, where we will be posting information as they are scheduled.

Thank you and looking forward to building Wikimania together!

The survey is conducted via a third-party service, which may subject it to additional terms. For more information on privacy and data-handling, see the survey privacy statement.

By Arturo Borrero González, Site Reliability Engineer, Wikimedia Cloud Services Team

As discussed in the previous post, one of the most important and successful services provided by the Wikimedia Cloud Services team at the Wikimedia Foundation is Toolforge. Toolforge is a platform that allows users and developers to run and use a variety of applications with the ultimate goal of helping the Wikimedia mission from the technical side.

As you may know already, all Wikimedia Foundation servers are powered by Debian, and this includes Toolforge and Cloud VPS. The Debian Project mostly follows a two year cadence for releases, and Toolforge has been using Debian Stretch for some years now, which nowadays is considered “old-old-stable”. In accordance with our operating system upgrade policy, we should migrate our servers to Debian Buster.

Toolforge’s two different backend engines, Kubernetes and Grid Engine, are impacted by this upgrade policy. Grid Engine is notably tied to the underlying Debian release, and the execution environment offered to tools running in the grid is limited to what the Debian archive contains for a given release. This is unlike in Kubernetes, where tool developers can leverage container images and decouple the runtime environment selection from the base operating system.

Since the Toolforge grid original conception, we have been doing the same operation over and over again:

1. Prepare a parallel grid deployment with the new operating system.
2. Ask our users (tool developers) to evaluate a newer version of their runtime and programming languages.
3. Introduce a migration window and coordinate a quick migration.
4. Finally, drop the old operating system from grid servers.

We’ve done this type of migration several times before.  The last few ones were Ubuntu Precise to Ubuntu Trusty and Ubuntu Trusty to Debian Stretch. But this time around we had some special angles to consider.

So, you are upgrading the Debian release

• You are migrating to Debian 11 Bullseye, no?
• No, we’re migrating to Debian 10 Buster
• Wait, but Debian 11 Bullseye exists!
• Yes, we know! Let me explain…

We’re migrating the grid from Debian 9 Stretch to Debian 10 Buster, but perhaps we should be migrating from Debian 9 Stretch to Debian 11 Bullseye directly. This is a legitimate concern, and we discussed it in September 2021. 

Back then, our reasoning was that skipping to Debian 11 Bullseye would be more difficult for our users, especially because greater jump in version numbers for the underlying runtimes.  Additionally, all the migration work started before Debian 11 Bullseye was released. Our original intention was for the migration to be completed before the release. For a couple of reasons the project was delayed, and when it was time to restart the project we decided to continue with the original idea.

We had some work done to get Debian 10 Buster working correctly with the grid, and supporting Debian 11 Bullseye would require an additional effort. We didn’t even check if Grid Engine could be installed in the latest Debian release. For the grid, in general, the engineering effort to do a N+1 upgrade is lower than doing a N+2 upgrade. If we had tried a N+2 upgrade directly, things would have been much slower and difficult for us, and for our users.

In that sense, our conclusion was to not skip Debian 10 Buster.

We no longer want to run Grid Engine

In a previous blog post we shared information about our desired future for Grid Engine in Toolforge. Our intention is to discontinue our usage of this technology.

No grid? What about my tools?

Traditionally there have been two main workflows or use cases that were supported in the grid, but not in our Kubernetes backend:

• Running jobs, long-running bots and other scheduled tasks.
• Mixing runtime environments (for example, a nodejs app that runs some python code).

The good news is that work to handle the continuity of such use cases has already started. This takes the form of two main efforts:

• The Toolforge buildpacks project — to support arbitrary runtime environments.
• The Toolforge Jobs Framework — to support jobs, scheduled tasks, etc.

In particular, the Toolforge Jobs Framework has been available for a while in an open beta phase. We did some initial design and implementation, then deployed it in Toolforge for some users to try it and report bugs, report missing features, etc.

These are complex, and feature-rich projects, and they deserve a dedicated blog post. More information on each will be shared in the future. For now, it is worth noting that both initiatives have some degree of development already.

The conclusion

Knowing all the moving parts, we were faced with a few hard questions when deciding how to approach the Debian 9 Stretch deprecation:

• Should we not upgrade the grid, and focus on Kubernetes instead? Let Debian 9 Stretch be the last supported version on the grid?
• What is the impact of these decisions on the technical community? What is best for our users?

The choices we made are already known in the community. A couple of weeks ago we announced the Debian 9 Stretch Grid Engine deprecation. In parallel to this migration, we decided to promote the new Toolforge Jobs Framework, even if it’s still in beta phase. This new option should help users to future-proof their tool, and reduce maintenance effort. An early migration to Kubernetes now will avoid any more future grid problems.

We truly hope that Debian 10 Buster is the last version we have for the grid, but as they say, hope is not a good strategy when it comes to engineering. What we will do is to work really hard in bringing Toolforge to the service level we want, and that means to keep developing and enabling more Kubernetes-based functionalities.

Stay tuned for more upcoming blog posts with additional information about Toolforge.

Other languages: Bahasa Indonesia, Deutsch, English, français, ikirundi, italiano, magyar, polski, português, português do Brasil, suomi, svenska, č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

• In the Wikipedia Android app it is now possible to change the toolbar at the bottom so the tools you use more often are easier to click on. The app now also has a focused reading mode. [1][2]

Problems

• There was a problem with the collection of some page-view data from June 2021 to January 2022 on all wikis. This means the statistics are incomplete. To help calculate which projects and regions were most affected, relevant datasets are being retained for 30 extra days. You can read more on Meta-wiki.
• There was a problem with the databases on March 10. All wikis were unreachable for logged-in users for 12 minutes. Logged-out users could read pages but could not edit or access uncached content then. [3]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 15 March. It will be on non-Wikipedia wikis and some Wikipedias from 16 March. It will be on all wikis from 17 March (calendar).
• When using uselang=qqx to find localisation messages, it will now show all possible message keys for navigation tabs such as “View history”. [4]
• Access to Special:RevisionDelete has been expanded to include users who have deletelogentry and deletedhistory rights through their group memberships. Before, only those with the deleterevision right could access this special page. [5]
• On the Special:Undelete pages for diffs and revisions, there will be a link back to the main Undelete page with the list of revisions. [6]

Future changes

• The Wikimedia Foundation has announced the IP Masking implementation strategy and next steps. The announcement can be read here.
• The Wikipedia Android app developers are working on new functions for user talk pages and article talk pages. [7]

Events

• The Wikimedia Hackathon 2022 will take place as a hybrid event on 20-22 May 2022. The Hackathon will be held online and there are grants available to support local in-person meetups around the world. Grants can be requested until 20 March.

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

When people learn new facts, they should know where those facts come from. Imagine reading a book with no obvious author or publisher, or watching a film with no opening or closing credits. These details are there so that everyone has the ability to discern and understand how a work came to be. Indeed, when people are able to identify where their information comes from, they can better evaluate whether that information should be trusted. It also helps shape their views about where the information comes from, what values that source of information stands for, and what influence it has in the world.

Yet more and more, people are learning information sourced from Wikimedia projects and they don’t even know it. Voice activated devices, user-generated videos, podcasts and other sound-based media often do not inform their users when they are sharing information sourced from Wikimedia. One recent study found that Wikipedia content was used to answer between 81 and 84% of common desktop knowledge queries through Google’s search engine, and those rates were similar for searches on Bing and DuckDuckGo https://nickmvincent.com/static/wikiserp_cscw.pdf. There is already some evidence that in the absence of identification of Wikimedia content, users often assume that knowledge from Wikimedia actually comes from the search platform itself, particularly Google https://www.scholars.northwestern.edu/en/publications/the-substantial-interdependence-of-wikipedia-and-google-a-case-st. Wikimedia content should be both easily recognized and valued when content is used in these newer spaces and formats. 

One way to help users who find information from Wikimedia on other platforms recognize where it comes from is through the use of logos. By definition, a logo is “…a graphic mark, emblem, or symbol used to aid and promote public identification and recognition.” Logos do not provide formal attribution, especially because Wikimedia projects are not an original source, but they do help people understand the connection between Wikimedia and our content. 

Wikimedia already uses known graphic logos like the Wikipedia puzzle globe logo, which has evolved its design and license over time and is visible on every desktop Wikipedia page. These logos are intended to communicate what Wikipedia is all about – a never ending work-in-progress, trustworthiness, neutrality, freedom from cost and advertising, openness, and multilingualism, among other concepts. They also change and adapt over time as we build new logos and update old ones. 

While existing graphic logos could be used in videos, graphic logos don’t work with audio podcasts or voice activated devices because they are sound based. Sound logos are the audio equivalent of graphic logos (examples: Intel, TED, American Public Television). The Wikimedia Foundation is currently exploring how to create a sound logo in partnership with the Wikimedia movement that will represent all Wikimedia content.

Designing the sound logo will be new and unique because of the psychoacoustic considerations to be made. Sounds can elicit strong emotional feelings, in ways that images or text sometimes can’t. For example, seeing a photo of a tiger may elicit a very different feeling (and corresponding psychological associations) than hearing that tiger roar. 

Once we have a sound logo, we can explore partnerships with outfits who reshare and reuse Wikimedia content in audio form to encourage them to use it in a variety of ways. Additionally, a sound logo may help strengthen Wikimedia’s identity and what information we communicate about ourselves on our own platforms and channels. Today, 30% of all searches globally are being done using devices without a screen. We don’t yet have all the answers about what a sound logo could achieve and all the ways that it could be used, but are confident that trends in knowledge consumption mean that it will be both useful and strategic. 

The sound logo project is designed to move thoughtfully. The project team has been reaching out to global Wikimedia communities since October 2021 to sharpen our concept and discuss ideas around a sound logo in public. Since the beginning of February 2022, the team has started thinking through how to create a sound logo in an open and participatory way, building off of what has been done in the past with other Wikimedia logos while adapting for the context of sound and broader use cases outside of our own platforms. We will share these ideas for community input before putting a plan into place. 

We warmly invite Wikimedia volunteers to be involved in the next evolution of the logo of Wikimedia; to read more here and discuss and ask questions on the project’s talk page here.