By: @mmartorana and @sbassett

Some history

For about a decade now, the combination of gerrit, zuul and jenkins have been used as the primary means of code review and continuous integration for most Wikimedia codebases. While these systems have been used successfully and are customized to support various workflows and developer needs, they have not helped facilitate the development of a robust application security pipeline within CI. While efforts have been made within the security space - with phan and the phan-taint-check plugin, libraryupgrader, and an occasional custom eslint rule - Wikimedia codebases have not taken full advantage of the current suite of open-source application security tooling that drives modern security automation. Given the aforementioned deficits and the announcement of Wikimedia migrating to Gitlab as a git front-end and CI/CD system, the Wikimedia Security-Team decided to explore what a modern application security pipeline within Gitlab could look like.

Our development path and roadmap

When the Gitlab migration was announced, the Wikimedia Security-Team saw great potential in the development of a robust application security pipeline to further improve application security testing and to make a concerted effort to shift left (wikipedia, snyk, Accelerate). Gitlab and its modern CI/CD functionality was a great candidate to help us explore the architecture and implementation of an application security pipeline for Wikimedia codebases, as it satisfied a number of desired outcomes including user-friendliness, convenience and impact.

Over the past couple of quarters, members of the Wikimedia Security-Team have created a number of security includes which employ Gitlab’s intuitive CI/CD functionality, particularly their means of including various yaml configuration files as components within different CI/CD stages. We initially focused this work upon several common languages used within Wikimedia projects: PHP, JavaScript, Python and Golang. Though it should be noted that the Gitlab security includes project is open to all contributors and, given Gitlab’s flexibility and simplicity, will hopefully encourage both improving existing include files while also driving support for the creation of new include files to support additional languages.

A basic example

During the aforementioned development cycle, the Wikimedia Security-Team compiled some basic mediawiki.org documentation to help developers get started with the configuration of their Gitlab repositories to run various security-related tests during CI. One specific example we explored was that of the function-schemata codebase, as used for the Abstract Wikipedia project. We migrated a test version of the repository over to Gitlab and set up a simple, security-focused .gitlab-ci.yml. This obviously would not be a complete .gitlab-ci.yml file for most codebases, but let’s focus upon the security-relevant pieces for now. First we see several environment variables defined under the variables yaml key. These serve to configure various docker images, tool cli options, etc. and are documented within the application security pipeline documentation. Then we see a list of included CI files, referenced via raw file URLs and indicating a specific tagged release. These correspond to specific tools to run during the default test phase of a repository’s CI pipeline. We can see that npm audit, npm outdated, semgrep (with certain javascript-specific rules sets) and osv’s scanner cli will all be run. In addition to these included files, we are also including Gitlab’s built-in SAST functionality (currently blocked on T312961) which, while limited in certain ways, can provide for additional security analysis. We can then see some sample pipeline output which displays the output of the tools which were run and indicates passing and failing tests.

Some opinionated decisions and current caveats would include:

1. Only being able to run the tools within the security include files under Gitlab’s test CI stage.
2. Having the security include files run for every branch which triggers the default CI pipeline (we’d definitely like to support custom branch and tag configurations at some point)
3. Only utilizing OSI- and free-culture-compliant tools and databases (likely perceived as a positive for many)
4. Presenting all results publicly as is the default configuration for repositories and pipelines within Wikimedia’s installation of Gitlab, as it currently is within gerrit and jenkins and a value of most FOSS projects.

It should be noted for the last two issues that some discussion did occur within various Phabricator tasks (T304737, T301018) and the current state of the CI includes was determined to be the best path forward at this time.

The future we would like to embrace

The Wikimedia Security-Team is obviously very enthusiastic about our work thus far in developing an application security pipeline for Wikimedia codebases migrating to Gitlab. In the coming development cycles, we plan to address bugs, evaluate and improve current CI include offerings as well as develop (and strongly encourage others to develop) new and useful CI includes. Finally - we welcome any and all constructive feedback on how to best improve upon this initial offering of security-focused CI includes.

References

• Primary project tracking bug: T289290: Design and Build Application Security Pipeline Components for Gitlab

Halloween is a full two weeks behind us here in the United States, but it's still on my mind. It happens to be my favorite holiday, and I receive it both gleefully and somberly.

Some of the more obvious and delightful ways I appreciate Halloween include: busting out my giant spider to hang in the front yard; getting messy with gory and gaudy decorations; scaring neighborhood children; stuffing candy in my face. What's not to like about all that, really?

But there are more deeply felt reasons to appreciate Halloween, reasons that aren't often fully internalized or even discussed. Rooted in its pagan Celtic traditions and echoed by similar traditions worldwide, like Día de los Muertos of Mexico and Obon of Japan, Halloween asks us, for a night, to put away our timidness about living and dying. It asks us to turn toward the growing darkness of winter, turn toward the ones we've lost, turn toward the decay of our own bodies, and honor these very real experiences as equal partners to the light, birth, and growth embodied by our everyday expectations. More precisely it asks us to turn toward these often difficult aspects of life not with hesitation or fear but with strength, jubilation, a sense of humor. It is this brave posture of Halloween's traditions that I appreciate so very much.

So Halloween is over and I'm looking back. What does that have to do with anything here at WMF and in Phabricator no less? Well, I want to take you into another dark and ominous cauldron of our experience that most would rather just forget about.

I want to show you some Continuous Integration build metrics for the month of October!

Will we see darkness? Oh yes. Will we see decay? Surely. Was that an awkward transition to the real subject of this post? Yep! Sorry, but I just had to have a thematic introduction, and brace yourself with a sigh because the theme will continue.

You see this past October, Release Engineering battled a HORDE OF ZOMBIE CONTAINERS! And we'll be seeing in our metrics proof that this horde was, for longer than anyone wishes zombies to ever hang around, chowing down on the brains of our CI.

Before I get to the zombies, let's look briefly at a big picture view of last month's build durations... Let's also get just a bit more serious.

What are we looking at? We're looking at statistics for build durations. The above chart plots the daily 75th, 95th, and 98th percentiles of successful build durations during the month of October as well as the number of job configuration changes made within the same range of time.

These data points were chosen for a few reasons.

First, percentiles are used over daily means to better represent what the vast majority of users experience when they're waiting on CI[1]. It excludes outliers, build durations that occur only about 2 percent of the time, not because they're unimportant to us, but because setting them aside temporarily allows us to find patterns of most common use and issues that might otherwise be obfuscated by the extra noise of extraordinarily long builds.

Next, three percentiles were chosen so that we might look for patterns among both faster builds and the longer running ones. Practically this means we can measure the effects of our changes on the chosen percentiles independently, and if we make changes to improve the build durations of jobs that typically perform closer to one percentile, we can measure the effect discretely while also making sure performance at other percentiles has not regressed.

Finally, job configuration changes are plotted alongside daily duration percentiles to help find indications of whether our changes to integration/config during October had an impact on overall build performance. Of course, measuring the exact impact of these changes is quite a bit more difficult and requires the build data used to populate this chart to be classified and analyzed much further—as we'll see later—but having the extra information there is an important first step.

So what can we see in this chart? Well, let's start with that very conspicuous dip smack dab in the middle.

And for background, another short thematic interlude:

Back in June, @thcipriani of Release Engineering was waiting on a particularly long build to complete—it was a "dark and stormy night" or something, *sighs and rolls eyes*—and during his investigation on the labs instance that was running the build, he noticed a curious thing: There was a Docker container just chugging away running a build that had started more than 6 hours prior, a build that had thought to be canceled and reaped by Jenkins, a build that should have been long dead but was sitting there very much undead and seemingly loving its long and private binge before the terminal specter of a meat-space man had so rudely interrupted.

"It's a zombie container," @thcipriani (probably) muttered as he felt his way backward on outstretched fingertips (ctrl-ccccc), logged out, and filed task T198517 to which @hashar soon replied and offered a rational but disturbing explanation.

I'm not going to explain the why in its entirety but you can read more about it in the comments of an associated task, T176747, and the links posted therein. I will, however, briefly explain what I mean by "zombie container."

A zombie container for the sake of this post is not strictly a zombie process in the POSIX sense, but means that a build's main process is still running, even after Jenkins has told it to stop. It is both taking up some amount of valuable host resources (CPU, memory, or disk space), and is invisible to anyone looking only at the monitoring interfaces of Gerrit, Zuul, or Jenkins.

We didn't see much evidence of these zombie containers having enough impact on the overall system to demand dropping other priorities—and to be perfectly honest, I half assumed that Tyler's account had simply been due to madness after ingesting a bad batch of homebrew honey mead—but the data shows that they continued to lurk and that they may have even proliferated under the generally increasing load on CI. By early October, these zombie containers were wreaking absolute havoc—compounded by the way our CI system deals with chains of dependent builds and superseding patchsets—and it was clear that hunting them down should be a priority.

Task T198517 was claimed and conquered, and to the dismay of zombie containers across CI:

In T198517#4662026, @dduvall wrote:

Two integration/config patches were deployed to fix the issue. The first refactored all Docker based jobs to invoke docker run via a common builder. The second adds to the common docker-run builder the --init option which ensures a PID 1 within the container that will properly reap child processes and forward signals, and --label options which tag the running containers with the job name and build number; it also implements an additional safety measure, a docker-reap-containers post-build script that kills any running containers that could be errantly running at the end of the build (using the added labels to filter for only the build's containers).

Between the deployed fix and periodically running a manual process to kill off long-running containers that were started prior to the fix being deployed, I think we may be out of the woods for now.

Looking again at that dip in the percentiles chart, a few things are clear.

There's a noticeable drop among all three daily duration percentiles. Second, there also seems to be a decrease in both the variance of each day's percentile average expressed by the plotted error bars—remember that our percentile precision demands we average multiple values for each percentile/day—and the day-to-day differences in plotted percentiles after the dip. And lastly, the dip strongly coincides with the job configuration changes that were made to resolve T198517.

WE. DID. IT. WE'VE FREED CI FROM THOSE DREADED ZOMBIE CONTAINERS! THEY ARE TRULY (UN)^2-DEAD AGAIN SO LET'S DITCH THESE BORING CHARTS AND CELEBRA...

Say what? Oh. Right. I guess we didn't adequately measure exactly how much of an improvement in duration there was pre-and-post T198517 and whether or not there was unnoticed/unanticipated regression. Let's pause on that celebration and look a little deeper.

So how does one get a bigger picture of overall CI build durations before and after a change? Or of categories within any real and highly heterogeneous performance data for that matter? I did not have a good answer to this question, so I went searching and I found a lovely blog post on analyzing DNS performance across various geo-distributed servers[2]. It's a great read really, and talks about a specific statistical tool that seemed like it might be useful in our case: The logarithmic percentile histogram.

"I like the way you talk..." Yes, it's a fancy name, but it's pretty simple when broken down... backwards, because, well, English.

A histogram shows the distribution of one quantitative variable in a dataset, in our case build duration, across various 'buckets'. A percentile histogram buckets values for the variable of the histogram by its percentiles, and a logarithmic percentile histogram plots the distribution of values across percentile buckets on a logarithmic scale.

I think it's a bit easier to show than to describe, so here's our plot of build duration percentiles before and after T198517 was resolved, represented as a histogram on a logarithmic scale.

First, note that while we ranked build durations low to high in our other chart, this one presents a high-to-low ranking, meaning that longer durations (slower builds) are ranked within lower percentiles and shorter durations (faster builds) are ranked in higher percentiles. This better fits the logarithmic scale, and more importantly it brings the lowest percentiles (the slowest durations) into focus, letting us see where the biggest gains were made by resolving the zombie container issue.

Also valuable about this representation is the fact that it shows all percentiles, not just the three that we saw earlier in the chart of daily calculations, which shows us that gains were made consistently across the board and there are no notable regressions among the percentile ranks where it would matter—there is a small section of the plot that shows percentiles of post-T198517 durations being slighter higher (slower), but this is among some of the percentiles for the very fastest of builds where the absolute values of differences are very small and perhaps not even statistically significant.

Looking at the percentage gains annotated parenthetically in the plot, we can see major gains at the 0.2, 1, 2, 10, 25, and 50th percentiles. Here they are as a table.

So there it is quite plain, a CI world with and without zombie containers, and builds running upwards of 37% faster without those zombies chomping away at our brains! It's demonstrably a better world without them I'd say, but you be the judge; We all have different tastes. 8D

Now celebrate or don't celebrate accordingly!

Oh and please have at the data[3] yourself if you're interested in it. Better yet, find all the ways I screwed up and let me know! It was all done in a giant Google Sheet—that might crash your browser—because, well, I don't know R! (Side note: someone please teach me how to use R.)

References

[1] https://www.dynatrace.com/news/blog/why-averages-suck-and-percentiles-are-great/
[2] https://blog.apnic.net/2017/11/24/dns-performance-metrics-logarithmic-percentile-histogram/
[3] https://docs.google.com/spreadsheets/d/1-HLTy8Z4OqatLnufFEszbqkS141MBXJNEPZQScDD1hQ/edit#gid=1462593305

Credits

Thanks to @thcipriani and @greg for their review of this post!

//"DOCKER ZOMBIE" is a derivative of https://linux.pictures/projects/dark-docker-picture-in-playing-cards-style and shared under the same idgaf license as original https://linux.pictures/about. It was inspired by but not expressly derived from a different work by drewdomkus https://flickr.com/photos/drewdomkus/3146756158//

Most of the user group affiliates of Wikimedia are specific to languages in their focus, i.e., they focus on developing Wikimedia projects in a specific language. However, there are very few user group affiliates that focus on a theme that transcends all the languages. One among such user groups is the Deoband Community Wikimedia, which, according to its published page on Meta-Wiki, “focuses on Muslim academia and scholarship, spreading from and around the Deoband Islamic seminary, and aims at improving Wikipedia and its sister projects with related knowledge and information, at a global level, in any language.” Often referred to as DCW, the user group believes that the subject on which it focuses has been underrepresented on Wikimedia projects and that there should be strategies and programs that help close this gap.

DCW was established on July 31, 2021, and recognized by the Affiliation Committee on January 16, 2022, after a long review process. In its first year, it has formed collaborations, organized meetups, held training workshops, and hosted photo events. These include its Deoband Yoruba Collaborative Project, which aims to help the theme grow on the Yoruba language Wikipedia. This project began on June 25, 2022. The group also organized the Bhopal Photo Event in October 2022, a photographic event that exceeded its target with more than 140 images.

DCW is struggling to find a growth trajectory. In December, it proposed a research work entitled “Defining methods for the strategic development of the Deoband Wikimedia: increasing quality-oriented knowledge and participation.”

The study, which is supposed to come in about six chapters, aims to define the growth trajectory for this thematic affiliate, which could also help other affiliates of the movement. This research would be carried out under the supervision of Aaqib Anjum Aafi, the user group’s founder and a key figure in its development. Aafi joined Wikipedia in March 2019 and has been an active contributor on several Wikimedia projects ever since. He has been a Movement Charter Ambassador and is a translation administrator on Wikimedia Commons, Meta-Wiki, and Wikidata. He has recently set up the “In the News” system on Urdu Wikipedia, where he is an “eliminator.” Besides all of these technical roles, he is a Volunteer Response Team agent and spends most of his time working on the development of the Deoband Community Wikimedia.

Commenting on the purpose of this research work, Aafi says that, we do not want to waste community resources on events and things that do not bring us fruitful results. We would instead strive to find the best possible ways which bear better results both in terms of “quality participation” and “quality knowledge” alongside “long-time-oriented participation”. The research work aims to define these methods for DCW which could at the same time help in its strategic development and in saving plenty of community resources from getting wasted. 

One day in December, Naven Parthasarathy ran into his professor Diana Strassmann, who, to his surprise, congratulated him. “She was like, you didn’t hear?” Naven recounts. It turns out, the Wikipedia biography that he had written about Kiyoshi Kuromiya as part of Dr. Strassmann’s course at Rice University had been read 800K times in the year since the course wrapped up!

“She mentioned that Kiyoshi was featured as a Google Doodle. I think that that’s really cool because that’s something that I grew up on,” says Naven.

It’s true, on June 4, 2022, Google featured Kuromiya on its front page. 640K internet users flocked to Wikipedia that day alone to read about Kuromiya’s legacy as an activist. What they found was a full story of a man’s life that Naven had stitched together from academic sources. Kuromiya’s activism spanned decades of social issues–from the civil rights movement and anti-war protests to gay liberation and HIV/AIDS education.

“One of the coolest things I found in my research was that he knew all these historical figures,” Naven says enthusiastically. “I saw that he knew people in the Black Panther party and he got inspired by Malcolm X!”

But before Naven’s interventions, the biography only gave broad strokes about Kuromiya’s work. It didn’t tell the story of why he fought so passionately and relentlessly. Nor did it go into depth about his accomplishments. The gaps surprised Naven given how interesting he found Kuromiya to be.

“The more I found out about him, the more I wanted to write. But all the different facets of his activism, which he did through his whole life–from college all the way to the Supreme Court– were left out of the page.”

Thankfully, Naven expanded the biography 6 months before Google featured Kuromiya as one of their Doodles. Naven’s edits give readers a better sense of Kuromiya’s personality, relationships, and values. Instead of simply listing a series of events, the biography now paints a picture of a person committed to helping others be treated as full humans and feel less alone. That’s what Naven connected with most while researching.

“Kiyoshi felt the need to get information out to people, especially about HIV and AIDS. He believed these are resources everyone should have, especially incarcerated people–that’s the last person that’s gonna get the resources they need. That was powerful. You could tell he was saying, If the government’s not going to do it, then I’m going to do it. Him just stepping up was the big message that hit home for me. With all the movements he was involved in, I don’t think that Kiyoshi said oh this affects me personally but he saw it as an injustice anyway. That was something I was able to learn from and use outside the classroom.”

Naven found himself getting inspired by Kuromiya’s life as he filled in the gaps on Wikipedia where he could. He could see parallels: he and Kuromiya are both first generation Asian Americans who ventured outside of their hometown community to go to college in another state. And reading about Kiyoshi’s unique approach to organizing got Naven thinking about how he could make a difference at his own campus for issues he cares about.

“Researching Kiyoshi’s life helped lower the barrier for me to get into activism. At first I saw it as some foreign thing, or something that professionals do. I never really thought about just taking that initial step. Around the time of the World Cup, there was a protest at my school supporting activists in Iran. It was small, but we had picket signs and it was really a powerful thing. I felt really good being there and I didn’t feel like a stranger that I have no ties to Iran. I just felt solidarity was something that was important in that moment.”

The assignment also inspired Naven to focus his sociology degree on social movements. “Before doing this class and writing this article, it wasn’t really something that was on my radar,” Naven says. “But now, learning more about different social movements has been really some of the most interesting work I’ve done in the last semester or two.”

Naven appreciated learning how to write in an encyclopedic style, too, citing every sentence with a reliable source and distilling information into the appropriate tone. “That was the first time I’d ever done something like that so it was cool. Won’t be the last.”

Naven hopes readers of the biography are as inspired as he is. He thinks we have a lot to learn from someone as passionate as Kuromiya.

“I think the last couple years have changed the way people thought about protests. But seeing someone who was doing these things in the 60s, 70s, 80s in a really unique way–that in and of itself is a good story to tell. And hopefully people can take something out of that, because I know I did.”

Visit teach.wikiedu.org to learn about incorporating a Wikipedia assignment into your course with Wiki Education’s free templates, tools, and support.

Welcome to season 2 of the University Students Wikimedians Learning Series! This season, we will be focusing on the second term USW Wiki events for 2023, from January to June. These events are designed to provide students with the opportunity to learn about the power of Wikipedia and other Wiki projects and how they can be used to share knowledge and build community.

In episode 1, we will be focusing on the January event “Judiciary of Tanzania in Wiki“. This event was designed to give students a deeper understanding of the Judiciary of Tanzania and how it can be documented and shared on Wikipedia. We will be exploring the history of the Judiciary in Tanzania, its current structure and function, and the role it plays in shaping the country’s legal system. We will also be discussing the challenges and opportunities of documenting the Judiciary of Tanzania on Wikipedia and how we can improve the existing articles.

In episode 2, we will be discussing “Women in Wiki“. We will be exploring how women in Tanzania can use Wiki projects to share their stories, experiences, and perspectives. We will also be discussing the challenges and opportunities of documenting women on Wiki projects and how we can improve the existing articles.

In episode 3, we will be discussing “Wiki and Social Justice“. We will be exploring how Wiki projects can be used to promote social justice and raise awareness about important social issues. We will also be discussing the challenges and opportunities of documenting social justice on Wiki projects and how we can improve the existing articles.

In episode 4, we will be discussing “Karibu Tanzania“. We will be exploring the history, culture, and geography of Tanzania and how it can be documented and shared on Wiki projects. We will also be discussing the challenges and opportunities of documenting Tanzania on Wiki projects and how we can improve the existing articles.

In episode 5, we will be discussing “My environment my Breath“. We will be exploring the importance of protecting the environment and how Wiki projects can be used to raise awareness about environmental issues. We will also be discussing the challenges and opportunities of documenting the environment on Wiki projects and how we can improve the existing articles.

In episode 6, we will be discussing “Reading Wikipedia in the classroom in Tanzania“. We will be exploring how Wikipedia can be used as a learning tool in the classroom and how it can help students develop research and critical thinking skills. We will also be discussing the challenges and opportunities of using Wikipedia in the classroom and how teachers and students can make the most of this resource.

Each episode of this season promises to be engaging, informative, and thought-provoking. Join us as we explore these important topics and discover how Wikipedia can be used to share knowledge, build community, and promote social change. So, get ready to brush up on your Wikipedia skills, and join us on this exciting journey!

Impact

Some potential impacts that will be achieved include:

1. Increased knowledge and understanding of the Judiciary of Tanzania, women in Tanzania, social justice, the history, culture, and geography of Tanzania, environmental issues, and how Wikipedia can be used as a learning tool in the classroom.
2. Improved Wiki projects contents on the Judiciary of Tanzania, women in Tanzania, social justice, the history, culture, and geography of Tanzania, environmental issues, and how Wikipedia can be used as a learning tool in the classroom.
3. Increased engagement and participation in Wiki editing and community building among university students in Tanzania.
4. Development of critical thinking, research, and writing skills among university students in Tanzania.
5. Increased awareness and understanding of the importance of protecting the environment and preserving the history and culture of Tanzania.
6. Development of a new generation of Wiki editors and community builders in Tanzania who will contribute to the growth and development of Wikipedia and other Wiki projects.
7. An increase in the number of articles and quality of articles in the language of Swahili will help to bridge the knowledge gap and make information more accessible to people in Tanzania.
8. Finally, it will serve as a platform for the students to express themselves and share their knowledge and experiences which will in turn promote social change.

Overall, the University Students Wikimedians Learning Series has the potential to make a significant impact in terms of increasing knowledge and understanding, improving Wikipedia articles, and promoting engagement and social change.

Conclusion.

In conclusion, the University Students Wikimedians Learning Series is an exciting opportunity for university students in Tanzania, editors, wiki community handlers, or any other interested party to learn about and contribute to important topics related to the Judiciary of Tanzania, women, social justice, the environment, and more. We hope that you will join us in this journey and become a part of our community of passionate learners and knowledge sharers.

So, if you’re a university student in Tanzania or any other editor looking to expand your knowledge, improve your research and critical thinking skills, and make a meaningful impact in your community, then we invite you to take action and join us for the first episode of the University Students Wikimedians Learning Series. Don’t miss this opportunity to be a part of something bigger and make a difference!

Don’t just sit there and wait for an opportunity, be the opportunity! Sign up now and be part of the change. Together, let’s make Wiki projects a more inclusive, accurate, and reliable source of knowledge for all.

Write us an email at hello@uswiki.africa or reach us via WhatsApp at +255685261018. Connect with us on our social media platforms: Facebook, Instagram, Twitter, and LinkedIn

This page includes summaries of the Movement Charter community consultations. The summaries are compiled by the Wikimedia Foundation’s Movement Strategy & Governance Team, and are reviewed by the Movement Charter Drafting Committee. In addition, the full detailed feedback from the consultations is shared along with the summaries, for transparency purposes.

November – December, 2022

The main article on Meta-Wiki

This is a brief summary of the overall impressions on three Movement Charter drafts: the Preamble, Values & Principles and Roles & Responsibilities. It highlights only the most recurring and emerging points according to the analysis conducted by the Movement Strategy & Governance Team. Please refer to the full feedback for more context.

The main article on Meta-Wiki 

The main article on Meta-Wiki

The main article on Meta-Wiki

The main article on Meta-Wiki 

Following the initial announcement and project launch in 2021, and first customers in 2022, the Wikimedia Enterprise team is pleased to provide the first financial report, representing the first calendar-year of operations. Also included is an overview of forthcoming product updates.

Wikimedia Enterprise is the API project designed to support the high volume data access requirements from large commercial reusers of Wikimedia’s freely-licensed content. By building a separate API tailored for their specific technical and legal needs, it helps improve the user-experience of people accessing Wikimedia content on third-party platforms, and provides an independent revenue stream for the movement. You can learn more about the reasons behind this project at the Community Essay.

A public meeting will be hosted by the team at 1900 UTC on Friday February 10 to discuss this announcement – details on our project homepage. If you have any other questions please consult the FAQ or ask them on the project’s talkpage.

Financial report

One of the principles of the Wikimedia Enterprise project has been “the publication of overall revenue and expenses, differentiated from those of the Wikimedia Foundation in general, at least annually”. We are therefore proud to present the inaugural “beta” edition of the Wikimedia Enterprise financial report. 

We are actively seeking feedback about how the report’s structure, content, and explanations can be improved for the next edition, which will cover the 2022-23 fiscal year. 

Context

In order to operate this API service – for which customers can pay for high speed/volume data delivery and Service Level Agreement (SLA) guarantees – the Wikimedia Foundation has created a limited liability company (LLC) which operates as Wikimedia Enterprise. This is a standard approach when a non-profit organization operates a for-profit activity. It is this LLC that signs the contracts with the customers of the API service, and it is that LLC’s financial report presented here. The Wikimedia Foundation is the sole owner of the LLC, all the people who work on it are Wikimedia Foundation staff, contractors, and vendors – and it is ultimately subject to the governance and oversight of the Wikimedia Foundation (WMF) Board of Trustees. For more details about this legal structure see the FAQ on the topic.

There are two reasons why this financial report should be considered a “beta” edition – timeframe and structure: 
1. Timeframe. Normally, the Wikimedia Foundation operates on a financial year starting in July and finishing the following June. But, as January 1, 2022, was the official start of commercial operation of the project, this report covers the calendar year of 2022. For future financial reports we intend to align with the normal financial reporting schedule of the rest of the Wikimedia Foundation. The next report will be in late 2023.

2. Structure. As the LLC is wholly owned by the Wikimedia Foundation, all of the financial information presented here will also be included within the Wikimedia Foundation’s audited financial statements and will be in the next Wikimedia Foundation “Form 990” filing as it relates to fiscal year 2021-2022, and future years. A “Form 990” is the annual informational document required for non-profit organizations in the United States by the Internal Revenue Service (IRS). However, there is no equivalent reporting form for a Limited Liability Company (LLC) which is wholly-owned by a nonprofit organization.

Financial performance summary

At the end of the calendar year 2022, the total revenue for Wikimedia Enterprise in the 2022 calendar year is $3.1 million – representing 1.9% of the Wikimedia Foundation’s 2022 total revenue. By comparison for the same period, online revenue (i.e. fundraising via websites, email, mobile app) was ~79%. As this covers only the first year of operation, it is expected that the Wikimedia Enterprise’s revenue amount, and its proportion within the Foundation’s overall revenue will increase by the next report. In accordance with the operating principle of financial independence and associated Board of Trustees statement, income from Wikimedia Enterprise would be capped at 30% of the total Wikimedia Foundation annual revenue.

The cost for a customer is based on the volume of data used, calculated on a per-request or per-gigabyte basis, and includes things like contractually guaranteed uptime requirements. The pricing model is described on the project website. Furthermore, there are also several no-cost access methods for the same dataset. The Wikimedia Enterprise API is an opt-in product. Wikipedia projects (and existing APIs, database dumps etc) remain free for anyone to access and reuse. The commercial use of Wikimedia content has, and remains, permitted under the principles of Free Cultural Works. 

For the first half of the calendar year 2022, the project’s monthly revenue (averaging $260,000 in calendar year 2022) covered the LLC’s monthly operating expenses (averaging $255,000 for the first half of 2022). For the second half of 2022, due to further product investment, monthly expenses grew (averaging $280,000) while revenue remained constant. In 2023, our second year of operations, with the addition of new customers and also new features, both revenue and expenses are expected to increase – but revenue growth is expected to outpace expenses. By comparison to other startup commercial API projects, to reach this stage within one year of operations is extremely rapid progress. The governance of these and all other commercial customer relationships is consistent with how the Wikimedia Foundation treats large corporate donations.

The total expenses (including cost of services) of the Wikimedia Enterprise project since its inception have been $4.5 million. This represents the full calendar years of 2021 ($1.3M) and 2022 ($3.2M) combined.

Expenses have increased by 142% from 2021 to 2022 – this is primarily a reflection of the increase in staffing, customer support costs and hosting charges. At the beginning of 2021 there were three full-time equivalent Wikimedia Foundation staff working directly for the project, plus external contractors. Over the course of the year the balance has shifted towards a larger portion of the work being handled in-house and thus the staff team has grown to 8.5 full-time equivalent employees across five countries at the end of 2022. We expect this trend to continue (we’re hiring!). The list of the current team (staff, as well as external contractors, and LLC board members) is on the project’s Meta-wiki page.

The LLC itself has no staff of its own – the sole purpose and benefit of the existence of the LLC as a legal structure is so that it can sign contracts with commercial customers and take the legal responsibility for those promises. This legal clarity is also the sole motivation or benefit of the LLC having been registered in the state of Delaware: it is the legal system that is most established and most well understood by American corporate law and the lawyers that practice it. 

As defined in the cost sharing agreement, the Wikimedia Foundation charges the LLC for 1) direct business costs such as third-party vendors; 2) staff costs for the Wikimedia Enterprise team; and 3) indirect costs that the Foundation incurs on behalf of the LLC, which is calculated to be 15% of the direct costs from (1). and (2). Item (3) is meant to recover the Foundation’s general and administrative expenses, primarily for the time spent by colleagues from the Legal, Finance, and Talent & Culture departments, ongoing access to office equipment, IT services, etc. 

Financial performance detail for calendar year 2022

The Wikimedia Foundation incurs costs which are eligible for capitalization (expensing the value of an asset over its useful life, rather than all at once) – primarily personnel expenses and outside professional service costs for software development.^[1] The amount capitalized for Wikimedia Enterprise was about $1.9 million at the end of 2022, of which $380,000 has been amortized (depreciated) so far since 2021.

Taxation

Based on advice from our external tax advisors, the revenue derived from the API subscription itself is not taxable. By contrast, income derived from unrelated business activities may be taxable to non-profit organizations.^[3] This unrelated business income is income from a trade or business, regularly carried on, that is not substantially related to the purpose that is the basis of the organization’s tax exemption. For Wikimedia Enterprise, taxable income includes professional service revenue, net of expenses. In this context, “professional services” is the small portion of revenue Wikimedia Enterprise engineers spend consulting with customers at their request, to provide expert technical advice to a specific customer about their own systems and setup.

As such, Wikimedia Enterprise’s federal tax liability for the professional services revenue is estimated to be $6,300 for the 2022 financial [not calendar] year. However, as the Wikimedia Foundation’s merchandise store had a prior-year net operating loss which can be offset, we expect this to result in $0 taxes payable to the IRS for FY22. This will be recognised in the Wikimedia Foundation’s 2022 federal tax filing, currently in the process of being prepared.

Wikimedia Enterprise may also be subject to state and local taxes. Certain business activities, including reaching a certain sales threshold to customers located in that state, may invoke a state and local tax obligation within the state. In FY22, Wikimedia Enterprise only sold to customers within the state of California and thus was subject to California state tax requirements. However, no California state income taxes were due as our gross taxable revenue in the state was under the $250,000 threshold for taxation. 

There is no state tax return to file for LLCs that are formed in Delaware if they have not conducted any business there – which Wikimedia Enterprise has not. As an LLC which is wholly-owned by a 501(c)(3) non-profit, there is no difference in our federal tax liability by being registered in Delaware compared to being registered in any other state in the US. Equally, the federal tax reporting requirements remain functionally the same regardless of which US state the LLC is registered in.

Product updates

The following is an overview of the new updates that will become available via the API service over the next few weeks. These details will be covered in greater depth in an upcoming post on the Enterprise news page. Technical documentation will also be updated accordingly and ongoing updates for the community can be found via the project’s MediaWiki page. 

While the Enterprise API features are designed with large commercial reusers in mind, other kinds of reusers – including individual volunteer Wikimedians – can also benefit. There are several access methods to the datasets available at no cost/no registration, including a free Wikimedia Enterprise account via the project’s homepage.

First and foremost this update includes substantial architectural improvements that are required to build more advanced API features in the future. Alongside these foundational changes are some general overall improvements. We’ve introduced response filters and added endpoints to save time and hassle in procuring the data reusers need across projects. We have ensured complete parity in the response data structure across the Enterprise API suite, in order to assist reusers parsing response data in the same manner regardless of API. 

The “Realtime streaming” API has received some further improvements on top of the aforementioned optimizations. This update lowers event latency increasing the overall speed. It now provides a reliable unified event stream which ensures a linear timeline for reusers which eliminates any confusion with the order of events.

The “Credibility Signals” feature is our ongoing effort to incorporate the API with some of the public information that Wikimedia editors use to make their editorial decisions. This update adds a handful of new fields, such as date_created and date_previously_modified, with more coming soon. These help contextualize the data and allow reusers to make better informed decisions.

“Summaries” is also a new data field within the API which provides a concise description of Wikipedia article content (similar to the existing page-preview hover cards) without the need for reusers to parse the entire Wikitext or HTML article body themselves. This saves a lot of time and compute power, and lowers technical barriers for reusers to understand the content within articles.

————

We look forward to continuing to provide updates, primarily via the Enterprise news page. In particular we are seeking feedback about how the structure, content, and explanations of this “beta” edition financial report can be improved for the next edition. We are pleased to answer any questions you may have on the project’s Meta-wiki talk page or at the forthcoming public meeting – details of which are on the project homepage. 

^[1] Accounting Standards Codification (ASC) Subtopic 350-40, Intangibles – Goodwill and Other – Internal Use Software of the Financial Accounting Standards Board (FASB). 
^[2] ASC 606, Revenue with Contracts with Customers.
^[3] IRS Publication 598

In the last four editions, we saw a wonderful progression of the world’s intangible cultural heritage with a photography contest organized from February to March annually at Wikimedia Commons, which is a media repository of free-to-use images, sounds, videos and other media. Let’s have a look back at the beautiful winning photographers of Wiki Loves Folklore 2022, as they take us to the heart of local traditions, rituals, and customs from around the world. These captivating images transports us to remote villages, bustling cities, and everything in between, showcasing the beauty and diversity of folklore in all its forms. Through these photographs, one can discover the traditional practices of communities from around the world, from the vivacious sounds and colors of folk festivals, to the vibrant displays of folk dances. Read further to know more about the expert view of our Jury and the story behind these winning photographs.

First Winning Image

This photo was taken by Michol Sanchez from the Philippines. According to Michol, he has always loved taking images of cultural festivals, with a focus on the natural candid shots. This photo describes the annual fluvial procession which is a solemn tradition that marks the commencement of the official Sinulog Festival. This event is a tribute to St. Niño, who is sent to visit his foster father, St. Joseph, at the St. Joseph Parish in Mandaue City. It is a time of reverence and celebration, as the people of Cebu come together to honour the patron saint of the city. Our jury comments about the good contrast between light and dark and, figuratively speaking, between the world of adults and the world of children. They describe this photo as a very powerful image that tells a story about a squatting child feeling insecure about itself where the standing soldiers in the surrounding give a glimmer of hope for a bright future. The quality of the image is also outstanding: the child is in focus as the primary subject, whereas the legs of the soldiers create an infinite row on its both sides. The contrast of this image illustrating strength and humanity in the face of adversity, an uncertain future, innocence in the face of interests, and vulnerability and beauty in the face of violence is shocking. Festivals have a special value in the Philippines, being known for their incredible diversity – wonderful costumes, glorious processions, varied dance, a sea of colours and shapes.This was the fourth consecutive year for submissions from Philippines making it to the winning images of the year. This photo shows a very different, more intimate view: at the edge of the procession, a child kneels, full of trust and hope in the help of the Holy Child. The child is effectively highlighted by the contrast in brightness and colours to the dark uniforms of the soldiers. This is an impressive photograph. It has also gained an urgent, worldwide topicality through the suffering that is happening even to innocent children right now in the horrific war against Ukraine – and in countless other conflicts around the world. Michol Sanchez was also interview on GMA Regional TV, watch his TV interview in Filipino language here

Second Winning Image

This stunning photo was taken by Diego Lopez in Morocco, a land of extremes and great beauty. The Berber people of Morocco inhabit the vast Sahara Desert, and have adapted to the harsh environment, developing a unique culture and lifestyle that has endured for centuries. From their traditional clothing to their music and cuisine, the Berber people have created a vibrant culture deeply rooted in the desert. From the bustling markets of Marrakech to the remote oases of the Sahara, the Berber people are a living testament to the resilience of the human spirit. Our jury commented that the reduction to seemingly only two colors and the integration of the landscape has succeeded excellently. This image depicts a man in his home environment, welcoming strangers with his widely open left hand and holding his unfolded litham with his right hand. The yellowish color of the litham perfectly matches the color of the sand in the desert, and the people in the background witness human activity in the most extreme areas of the world. The colors seem to be in synchronization with each other. Juror Roman commented that this is a funny, cheerful picture, and it’s also very well done. The traditional dress of the Moroccan Berbers includes a headscarf, which is made the subject here in a very refreshing way – the man has partially unwound it and now it forms a beautiful shape in the wind that harmonizes with the shapes of the sand dunes. Added to this is the harmonious color palette of the picture and the very balanced composition. The photographer Diego Lopez likes to document his journey to different countries and capture different cultures with his camera, and this photo is a perfect example of his success.

Third Winning Image

This photo, taken by Camelia Banerjee (User:Euphoric Captures) in the small village of Raghurajpur, Odisha, India, captures a woman creating stunning Pattachitra paintings and other captivating works of art. Her creations are proudly displayed throughout the village, showcasing her remarkable talent and skill. Our jury comments on the beauty of the traditional dress and the obvious joy of the activity creates a good mixture with the light and the outside world indicated on the wall. They add that the picture abounds in vividness, dynamics, and colorfulness. The female artist pays careful attention to the painting, resulting in beautiful Pattachitra artworks all over the place. A very important detail is the woman’s smile, which shows that she is content with her work. Appreciating the harmony of the colors, they add that it is an excellent environmental portrait which shows the female artist at work together with her products. The photo depicts the joy and concentration with which the artist works on her art – it appears harmonious in that the woman herself is wearing a dress patterned in a similar style to her artwork. The light and composition of this photo are beautiful. This photo was taken with a normal smartphone, yet the details are well depicted, showing that it is now possible to take excellent pictures of many subjects even with smartphones. The photographer of this image, Camelia, states that she went to Puri, Odisha in November 2022 with her family. During their last day of stay, one of her cousins suggested visiting the village of Raghurajpur. Upon arriving, they were amazed by the beauty of the village, with folk art on the walls of every house. The people were so welcoming, and Camelia Banerjee states this image creates a feeling of serenity. The woman in the image seems to be enjoying her work, and despite the fact that most of their income depends on the visits of tourists, they always have a smile on their face.

Top 10 Images

This photo, taken by WAVRIK in Ethiopia, captures a captivating display of vibrant colors and intricate designs. For centuries, traditional body painting has been used to express cultural identity and to celebrate special occasions in Ethiopia. It is a unique way for children to express themselves and explore their creativity. Juror Reinhold remarked, “Wonderful body painting that contrasts with the tattoos of the civilized world from which the flip flops have already penetrated to here. The impression of the people acting at dizzying heights is well brought out by the photographer.” Juror Roman added, “The photo of the children walking on stilts in Ethiopia is exciting because it was taken from a low perspective: the ground is not visible, the children seem to be standing straight in the sky on their stilts. At the same time, it is a dignified portrayal: the photographer is not looking down at the children, but up at them, and they appear full of pride and self-confidence. The traditional body painting is clearly visible and appears even more striking against the blue sky.” Juror Famberhost commended the representation of old tradition in this image. This stunning image of Ethiopian children adorned in traditional body paint, standing tall on stilts, is a powerful reminder of the beauty and resilience of their culture.

This stunning photograph, taken by Tapas Kumar Halder in India, captures the essence of the traditional Peacock Dance. During the harvest festival of Thai Pongal, girls in the Indian states of Tamil Nadu and Kerala dress up in vibrant makeup and costumes to perform the centuries-old ritual, celebrating the bounty of the harvest and the beauty of nature. Juror Reinhold praised the photo, noting its “successful representation of body painting on a picture-perfect face,” while Famberhost commented on the “magnificent perspective” of the dancer’s head. Juror Roman added that the photo was “beautiful in excellent technical quality,” with the dancer’s face appearing vivid and three-dimensional against the softly blurred background. The colors of her makeup glow like peacock feathers, perfectly complementing the Peacock Dance. The dancer’s gaze is expressive and speaks to the deeper meaning of the ritual. The crop is also just right, creating a harmonious composition.

This stunning photograph, taken by Varvara Kless-Kaminskaya in Thailand, captures a Karen tribal woman dressed in her traditional attire, sitting and sewing in an ethnic village in Pattaya. Her vibrant clothing stands out against the quaint backdrop of the village, providing a unique insight into the culture of the area. Juror Reinhold praised the image, noting the traditional craftsmanship was well represented and the seemingly floating thread enlivened the picture. Juror Roman commented, “Another environmental portrait of an artist at work, this time taken in a Karen ethnic village in Thailand. The artist looks up from her work and smiles at the viewer, drawing them directly into the picture. In the background, we can see the artist’s products, and her clothing further emphasizes the craftsmanship of the area. The technical quality is excellent, the indirect light is beautiful, and the colors are vivid yet not exaggerated.”

This stunning photograph was taken by Gabideen in Mongolia during the Golden Eagle Traditional and Folk Festival Competition, an annual event held in Bayan Ulgii Province, Western Mongolia. This unique competition celebrates the region’s rich cultural heritage, featuring traditional music, dance, and art from participants from all over the world. It is a great opportunity to experience the vibrant culture of Mongolia and to connect with people from different backgrounds. The image captured at the event showcases a lively hunting scene in a seemingly vast and inhospitable landscape. Juror Reinhold noted that the landscape provides habitat, while juror Roman highlighted the riders in traditional costumes, with their bright red caps and dark clothes standing out against the muted colors of the barren landscape. Juror Famberhost remarked that the image was beautifully captured of an old tradition, with the riders riding directly towards the viewer and the high splashing water indicating their speed.

This stunning photograph was taken by Benny Gross in the ancient city of Cusco, Peru. Capturing the rich history and culture of the region, the image depicts a man dressed in traditional robes emerging unexpectedly from a narrow door in the wall and playing his instruments. Juror Reinhold praised the photographer for finding a good representation of historical architecture, costume and music, while Juror Roman noted the effective use of the uniform background in muted colors to emphasize the scene. The picture appears three-dimensional and is well lit, allowing one to study every detail of the clothing and musical instruments. The story behind the photograph is just as captivating. Benny and his wife were walking through the streets of Cusco when they heard the sound of ethnic music coming from a wall. As they approached, the impressive Indian came out through a narrow opening and without hesitation, Benny captured the moment. The couple enjoy taking long trips around the world to experience different and authentic cultures, and Benny’s photos aim to present the look as it is, without interference.

This stunning work was photographed by Sir Amugi in Ghana’s Northern Region. It captures the joy and enthusiasm of a child mastering the intricate rhythms and melodies of traditional drums. This image highlights the importance of cultural heritage and the valuable lessons that can be learned through music, such as collaboration, discipline, and creativity. The photo was praised by the jury for its ability to capture the essence of the moment.

Photographer Sir Amugi revealed that the photo was taken during a walkathon organized by Dagbani Wikimedians User Group. Through their travels and photography across Ghana, they were able to capture this special image. It is this unique ability to capture the beauty of the moment that makes Sir Amugi’s work so remarkable.

This stunning photograph, taken by Sir Bhupendra Singh in India, captures the mesmerizing beauty of the traditional Dhunuchi Dance. As the dancer gracefully moves in a rhythmic fashion, the incense burner is waved in the air, filling the atmosphere with its sweet and calming aroma. This ancient Bengali ritualized dance of worship is a reminder of the power of faith and devotion, and is a beautiful way to honor the divine. Our jury, Reinhold and Roman, praised the photograph for its excellent depiction of smoke in incident light and dancers moving in the semi-darkness. The muted colors, the smoke highlighted by the oblique light, and the play of sharpness and blur all result in a very atmospheric image. As the winner of the photo competition, photographer Sir Bhupendra Singh said he was honored to have captured this moment during his pandal hopping during the Durga Pooja, and believes the image truly captures the tradition of Bengal culture. 

This captivating photo, taken by SPeterSzabo83 in China, showcases the traditional Miao folk dance of Guizhou. Characterized by its intricate movements and vibrant costumes, often adorned with intricate embroidery and beading, this dance has been performed for centuries and is a beloved part of the Miao culture. Accompanied by traditional instruments such as drums, gongs, and flutes, the atmosphere is festive and alive. Juror Reinhold commented that the photo of the dance performance shows everything to be traditional and the cobblestones seem to reflect the rhythm. Juror Roman added that the photo is a beautiful shot that not only captures the traditional dance of the Miao, but also their garments and the architecture in the background. The ornate paving of the square corresponds to the round positioning of the dancers, creating a sense of unity in the image. Witnessing the Miao folk dance is a unique way to experience the culture of Guizhou, and it is sure to leave a lasting impression on all who see it.

This stunning photo was captured by photographer Rares Andrei Sandru în Romania. The Romanian teenagers, dressed in traditional garb, were joyfully dancing at the Hora Bucovinei Folk Festival in Frasin, Romania, showcasing the vibrant colours of their costumes and the lively music. The festival is a celebration of the culture and traditions of the region, and it provides a great opportunity for the youth to come together and express their heritage through dance. The jury member Reinhold commented on the image saying,” The clothing of the happy people creates a bridge to the seemingly wild environment in which these people live through the fur they use.” Juror, General Bassett, another jury member, noted, “La festa del poble.” When asked how they obtained the images used in this year’s campaign, the photographer Rares Andrei Sandru said, “Participating at the folk festival and that they believe authenticity is what distinguishes their images.”

Natasha Geleva captured a stunning image at the internationally renowned Festival of Folk Instruments and Songs Pece Atanasovski in the village of Dolneni, near Prilep, Macedonia. Since its inception in 1974, the festival has brought together talented musicians from around the world to celebrate the traditional music of the region. The vibrant display of Macedonia’s unique culture, from the haunting sounds of the gajda to the lively rhythms of the tapan, is a sight to behold. The fusion of the wide landscape and traditional clothing has been highly praised by jurors Reinhold and Roman, and the evening light gives the photo a special mood. Natasha Geleva, the winner of the photo campaign, said that she obtained most of the images from the festival for folklore music in the village Dolneni in Macedonia.

Best Video

The winning video of this year’s competition shines a light on the timeless tradition of Yoruba storytelling in Nigeria. As the Juror Reinhold pointed out, the entry effectively captures a tradition that has been passed down through generations and will hopefully continue to be preserved in this way. Juror Roman also praised the clever and endearing nature of the video, noting how it demonstrates how to tell a story and honor a tradition with minimal resources. The film emphasizes the beauty of Yoruba storytelling, and how it motivates people, links generations, conveys experiences, and enriches our lives. It serves as a reminder of the significance of safeguarding our cultural traditions for future generations to appreciate and learn from.

Best Audio

Recorded by Shagil Kannur in Kerala, India, the Chenda Melam is a traditional instrument used in the folk festivals of the state. This cylindrical drum, made of wood and animal skin, is played with two sticks and creates a vibrant and energetic atmosphere during celebrations. It is an integral part of the traditional music of Kerala. In order to capture media for this event, the winner of the event attended numerous folk events in their region. All of their contributions to the event were purely folklore, captured from live events, often crowded and in low light. Despite the sensitivity of the people towards their ritual functions, which often resulted in irritation towards photography, the experience was still interesting. Reinhold, one of the jury members, commented that the rhythm and singing carried the listener into a foreign world. Roman, another jury member, added that the audio gave a good impression of the traditional Chenda drum and of the music it is used for, thus capturing the exciting atmosphere at a folk festival of Kerala.

Top Uploaders

AmanAgrahari and Sumolari were the top uploaders during the contest. AmanAgrahari shared images of his culture and everyday life, including traditional wedding ceremonies. Sumolari, on the other hand, explored the streets of Fallas, capturing anything that caught his eye – from monuments to people dressed in traditional costumes, fireworks, musicians, and more. It was a great opportunity to experience the ever-changing atmosphere of the city.

2023 Edition

We hope you have been inspired by the beauty and diversity of global folklore captured in these photographs. The participating photographers have done an excellent job in showcasing the cultural heritage of their countries and communities.

The 2023 edition of Wiki Loves Folklore has begun and we invite you to join us in this celebration of cultural heritage by participating as a photographer or simply by sharing your own local traditions and customs. Whether you’re a professional photographer or an amateur with a passion for capturing the essence of folklore, your contributions will be a valuable addition to the Wikimedia Commons. By participating in Wiki Loves Folklore 2023, you’ll have the opportunity to share your own unique perspective on the heritage of your community with the world. So grab your cameras and start exploring the folk culture of your country, and let’s create a comprehensive and free media library for the world to appreciate and learn about different cultures. 
Stay tuned as we continue our journey of celebrating folk culture with you. Upcoming next is the journey towards Feminism and Folklore, an article writing contest organized in over 35 languages in Wikipedia, a free online encyclopedia, in the theme of folk cultures and women in folk professions.

This Blog was reposted from Medium

Did you miss part 1 of this post? Read it here

In today’s digital age, the internet has become an essential tool for connecting people and sharing information. One powerful way to do this is through building a Wikimedia community. A Wiki is a platform that allows users to come together, collaborate and create content together, making it an ideal platform for building a community of knowledge and engagement. Building a community in Tanzania can be a powerful way to document local history, share knowledge about health and education, and create a platform for community engagement.

The goal of this blog post is to explore what it takes to build a Wikimedia community in Tanzania, from setting goals and objectives to recruiting and training community members to contribute. We’ll also discuss some of the challenges that may arise and strategies for overcoming them, as well as the resources and support centers that are available to help you build a successful and sustainable community.

What should I expect?

Building a Wikimedia community in Tanzania requires a lot of hard work and dedication, so it’s important to have realistic expectations. Here are a few things you should expect:

1. A steep learning curve: it requires a variety of skills, including writing, editing, and community organizing. You may have to learn new skills as you go, so be prepared for a steep learning curve.
2. Time commitment: it takes a lot of time and effort, so be prepared to devote a significant amount of time to the project.
3. Challenges: it may come with its own set of challenges, such as lack of internet access, limited resources, and cultural differences. Be prepared to face these challenges and find creative solutions.
4. Community engagement: it requires engagement with the local community. You will need to work with local partners, organize events and workshops, and encourage community members to contribute to the Wiki.
5. Collaboration: it is a collaborative effort, so be prepared to work with a team of like-minded individuals.
6. A sense of accomplishment: it is a challenging but rewarding endeavor. When you see the positive impact, your community is having, you will feel a great sense of accomplishment.

Overall, building a Wikimedia community in Tanzania is a challenging but rewarding endeavor that requires a lot of hard work and dedication. But by working together and sharing knowledge, we can empower our fellow citizens to make informed decisions and take control of their futures.

My checklist

Here is a checklist of things to keep in mind when building a Wikimedia community in Tanzania:

1. Set clear goals and objectives for the community.
2. Identify and engage with local partners and stakeholders.
3. Develop a plan for recruiting and training community members to contribute to the Wiki.
4. Create and edit articles on the project, focusing on topics relevant to the local community.
5. Organize events and workshops to promote the project and engage with the community.
6. Regularly evaluate the progress of the community and make adjustments as needed.
7. Establish a system for monitoring and maintaining the project to ensure the accuracy and relevance of the content.
8. Develop strategies for promoting the project and encouraging community members to use it as a reliable source of information.
9. Create a budget and plan for sustaining the community in the long term.
10. Celebrate successes, acknowledge challenges, and keep track of the impact the community has on the local community.

Remember, building a Wikimedia community in Tanzania is an ongoing process, so be ready to adapt and evolve as you go along and you’ll be able to create a vibrant and valuable community.

What challenges might I face in the future and how can I overcome them?

Building a Wikimedia community in Tanzania can come with a variety of challenges. Here are a few potential challenges you may face and some strategies for overcoming them:

1. Limited internet access: Many areas in Tanzania may have limited internet access, which can make it difficult for community members to contribute to the project or access its content. To overcome this challenge, consider partnering with local organizations that have internet access and can host workshops and events.
2. Limited resources: Building a Wikimedia community can be costly, especially when it comes to training community members and organizing events. To overcome this challenge, consider seeking funding from organizations and foundations that support community development projects.
3. Cultural differences: Tanzania is a diverse country with different cultures, languages, and dialects which can make it challenging to create a project that is inclusive and relevant to all community members. To overcome this challenge, consider involving community members from different cultural backgrounds in the planning and implementation of the community.
4. Lack of community engagement: Without the active participation of community members, the wiki community may struggle to get off the ground. To overcome this challenge, consider organizing community events and workshops to promote the project and encourage community members to contribute.
5. Maintaining the content: Keeping the project up to-date and accurate can be a big challenge. To overcome this challenge, establish a system for monitoring the wiki and ensure the articles are checked for accuracy by other community members in the field.
6. Sustainability: Sustainability is a crucial aspect of building a Wikimedia community. Make sure to have a long-term plan for funding and maintaining the community.

Overall, building a Wikimedia community in Tanzania can be challenging, but with a dedicated team and a willingness to adapt and overcome obstacles, it is possible to create a vibrant and valuable community.

Is there a support center that I can rely on when needed?

There are several organizations and resources that you can rely on when building a Wikimedia community in Tanzania. Here are a few examples:

1. The Wikimedia Foundation: The Wikimedia Foundation is the organization that runs Wikipedia and other Wikimedia projects. They have a variety of resources available to support communities, including training materials and community support.
2. The Wiki Education Foundation: The Wiki Education Foundation is a non-profit organization that supports wiki communities in education. They offer training and support for educators and students who want to contribute to Wikipedia and other Wikimedia projects.
3. Local NGOs and Community-based organizations: Local NGOs and Community-based organizations can be a valuable resource for building a Wikimedia community in Tanzania. They often have knowledge and experience in the local culture, language, and context, which can be very useful.
4. Local libraries: Local libraries can be a great resource for building a community. Many libraries have internet access and can host events and workshops to promote the wiki.
5. Online communities: There are many online communities of Wikimedia enthusiasts and experts that you can rely on for support. Joining these communities can provide a wealth of information and resources for building a community.
6. Consultancy firms: There are consultancy firms that offer services to support communities, such as training, development, and technical support.
7. Local Wiki Communities: Tanzania has 4 wiki communities to date (Jenga Wikipedia ya Kiswahili, Wikimedia Community User Group Tanzania, Wikimedians of Arusha User Group, and University Students Wikimedians) covering over 5 regions in the country. Before starting any community, it is best to consult them earlier to collect their views and keep/establish collaboration.

It’s always a good idea to keep an open mind and be ready to take the initiative to reach out to the resources that can support you in building a Wikimedia community in Tanzania.

Conclusion

In conclusion, building a Wikimedia community in Tanzania is a challenging but rewarding endeavor. With the right team, a clear vision, and a willingness to adapt and overcome obstacles, it is possible to create a vibrant and valuable community. Whether you’re looking to document local history, share knowledge about health and education, or build a platform for community engagement, a Wikimedia community can be a powerful tool for making a positive impact in Tanzania.

To make it happen, you need to set clear goals and objectives, identify and engage with local partners and stakeholders, and develop a plan for recruiting and training community members to contribute to the wiki. You also need to create and edit articles on the project, focusing on topics relevant to the local community, and organize events and workshops to promote the project and engage with the community.

Sustainability is key, so it is important to establish a system for monitoring and maintaining the wiki to ensure the accuracy and relevance of the content, develop strategies for promoting the project and encouraging community members to use it as a reliable source of information, and create a budget and plan for sustaining the Wikimedia community in the long-term.

The challenges are many, but with the help of various resources and support centers available, you can overcome them. The journey is not easy, but the rewards are great. Building a Wikimedia community in Tanzania can have a lasting impact on the local community and provide a valuable resource for generations to come.

Disclaimer: This post is for educational purposes only! All the provided information is based on my own research, experience, and perspective. It is best to seek assistance than just relying on this blog post.

Write us an email at hello@uswiki.africa or reach us via WhatsApp at +255685261018. Connect with us on our social media platforms: Facebook, Instagram, Twitter, and LinkedIn

Other languages: Deutsch, English,Tiếng Việt, español, français, italiano, polski, 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 Vector 2022 skin, logged-out users using the full-width toggle will be able to see the setting of their choice even after refreshing pages or opening new ones. This only applies to wikis where Vector 2022 is the default. [1]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 February. It will be on non-Wikipedia wikis and some Wikipedias from 8 February. It will be on all wikis from 9 February (calendar).
• Previously, we announced when some wikis would be in read-only for a few minutes because of a switch of their main database. These switches will not be announced any more, as the read-only time has become non-significant. Switches will continue to happen at 7AM UTC on Tuesdays and Thursdays. [2]
• Across all the wikis, in the Vector 2022 skin, logged-in users will see the page-related links such as “What links here” in a new side menu. It will be displayed on the other side of the screen. This change had previously been made on Czech, English, and Vietnamese Wikipedias. [3]
• Community Wishlist Survey 2023 will stop receiving new proposals on Monday, 6 February 2023, at 18:00 UTC. Proposers should complete any edits by then, to give time for translations and review. Voting will begin on Friday, 10 February.

Future changes

• Gadgets and user scripts will be changing to load on desktop and mobile sites. Previously they would only load on the desktop site. It is recommended that wiki administrators audit the gadget definitions prior to this change, and add skins=… for any gadgets which should not load on mobile. More details are available.

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

2022 was a good year, and 2023 promises to be an even better one. For the start of the year, the Global Open Initiative Foundation (GOIF) met with its volunteers and team members to discuss the various projects to be embarked on in 2023. Outstanding members were recognised and given the necessary accolades. There was also a discussion on the ways in which volunteers can be motivated; highlights included the need for personal contact beyond social media pages. That means reaching out to participants via personal messages and calls. The other motivation was the provision of support in the form of data and transportation allowances. We went on to collect ideas about how providing support in the form of data and transportation allowances might affect the caliber of volunteers recruited to the movement. The response was that as long as assistance was provided as a need-based measure rather than to attract volunteers, it should be maintained. Another suggestion was to support volunteers based on their contributions. Concerning our plans for 2023, we intend to foster community spirit by continuing with our biweekly calls, engaging volunteers beyond edit-a-thons, and taking cues from initiatives like Wikimedian of the Month from the community in Estonia and Wikimedia Poland Support Architecture. 

Keep an eye on the Ghanaian Fabric Project

The Wikimedians of the Twi language group have spearheaded a documentation of Ghanaian fabrics dubbed Ghanaian Fabric, 2023 Phase I. Ghanaians have a rich cultural tradition of proverbs, metaphors, and symbolism. This aspect of tradition has been incorporated into the names of Ghanaian fabrics and textiles. The names are created by designers, fabric manufacturers, market women, and vendors. The fabric project would result in the contribution of entries on both the English and Twi Wikipedia, the uploading of fabric design photos and the pronunciation of fabric names onto Wikimedia Commons, as well as the creation of items on Wikidata.

Curation of the titles and graphics for the various designs began in January of this year (2023). A team went to fabric marketplaces in Kumasi and Accra to gather the names, photos, and any other information about the textiles from the traders. They also went to the Ashanti Regional Branch of the National Cultural Center to learn more about the history and manufacturing processes of fabrics and textiles. The Fabric project’s English Wikipedia and Wikimedia Commons parts are set to launch in February 2023. 

Our team at GOIF welcome comments, suggestions, questions, and collaborations concerning any of our projects via our email or social media pages.

24/01/2023-30/01/2023

Mapping

• As part of a series on how to generalise OSM data, Jochen Topf shared his insights about the generalisation of river networks.
• In Cochabamba, Bolivia, the Trufi Association is encouraging users of their app to contribute informal transport routes using a simplified mapping feature.
• Bobropiton has made three videos(1, 2, 3) about mapping bus routes and finding mislabelled routes.
• HOT’s Open Mapping Hub – Asia Pacific has compiled a list of the most common data quality errors in OpenStreetMap by country and found some trends.
• Christoph Hormann outlined a method of choosing what to render for compound names based on the default_language tag.
• Valerie Norton (valhikes) reported about her mapping activities based on field trips from February to September 2022 in Calico. See also her other ‘Moments in Dirt and Ink’, for example about Fort Narraguinnep or the Dangerous Park.
• Voting for the proposal to consistently extend the usage of utility=* to service and industrial landuses, buildings and cabinets has closed. The proposal was approved with 19 votes for, 4 votes against and 1 abstention.

Community

• OpenCage published an interview with the OpenStreetMap Somalia Team on their blog.
• Grant Slater shared his insights about the development and benefits of OSM, making reference to volunteers mapping South Africa’s power grid, among other aspects.

Imports

• watmildon showed how the US National Address Database can assist in cleaning up TIGER tagging.

OpenStreetMap Foundation

• Board members of the OpenStreetMap Foundation shared their personal visions for 2023 and promised in the comments that a collective vision will follow soon.

Maps

• [1] Andy Townsend wrote that his Garmin maps are coming along nicely. You can download pre-made files for Great Britain or roll your own.
• dcz had a dream of the perfect map for their cycling trip. Using TileMill and OSM data the dream became reality but the cycling trip didn’t.

Open Data

• Adrion explained how to download, convert and import the National Heritage List for England into Vespucci or Orux Maps to use for mapping.
• The Câmara Municipal da Horta, a municipality on Faial Island in the Azores, Portugal, is notifying ► of traffic direction changes using OpenStreetMap, including a credit to contributors.
• Kai Johnson blogged on how he and watmildon analysed changes in GNIS data to find potential additions and corrections for OpenStreetMap in the US.

Software

• Anthon Khorev’s ‘osm-note-viewer’ can now be used with other OpenStreetMap website-based projects. He explained more in his blog.
• Pieter Vander Vennet has compiled some statistics about Open Reviews. Besides the official demonstration application, Mangrove, MapComplete’s implementation is the most popular.
• Planet Lite, the copyright-free map of the entire world from MapTiler, has been upgraded with enhanced features. Some issue fixes in the lite version of MapTiler Planet complete the update.

Programming

• Hans Thompson shared an R script to query elements from OSM and show them on a browser map using the Leaflet JavaScript tool. He used farmer market POI’s (amenity=marketplace) in his example.
• Hungerburg explained ►
  how he used jq (a Linux command-line JSON manipulation utility) to parse and get an overview of a very large GeoJSON data file (in this case, a government open dataset of roads in Tirol).
• Do you ever get confused by Overpass QL’s syntax? Now, you can highlight syntax elements in some editors: Visual Studio Code and other vscodium compatible editors, and KDE’s Kate.
• Inspired by a video (we reported earlier), rtnf decided to make his own self-hosted vector tiles.

Releases

• osm2pgsql 1.8.0 has been released. Thanks to PostgreSQL 15 osm2pgsql is even faster than before.
• OrganicMaps has released a new version with improvements to KML importing, and elevation handling for hiking and cycling.

Did you know …

• … Lorenz Matzat’s 2017 article ‘How OpenStreetMap can be used for journalism‘ ►? The article is still relevant today and deserves more coverage.
• … ivanbranco has a list ► of his favourite OSM tools? He has recently updated the list.

Other “geo” things

• OpenCage has published the question and the results for January’s Geotrivia on their website. Would you have managed a chain of 10 countries like Ciarán Ferrie and rubpec? On Friday 24 February Ed will set the next task.
• -karlos- has created two puzzles from an OpenStreetMap map using the tool Jigidi. You can find some other puzzles on Jigidi if you search for OpenStreetMap.
• On 25 January it became apparent that the source code for various Yandex services had been leaked. The source code for Yandex.Map was included, in which users have found code to work with OpenStreetMap data (but with a note about the incompatibility of OSM data with other sources).

Upcoming Events

Where	What	Online	When	Country
Hannover	OSM-Stammtisch Hannover		2023-02-06
	MapRoulette Monthly Community Meeting		2023-02-07
	OSMF Engineering Working Group meeting		2023-02-07
Strasbourg	Mapathon CartONG		2023-02-07
City of Westminster	Missing Maps London Mapathon		2023-02-07
Stuttgart	Stuttgarter Stammtisch		2023-02-07
Berlin	OSM-Verkehrswende #44 (Online)	✓	2023-02-07
Zürich	OSM-Stammtisch		2023-02-08
London	London social pub meet-up		2023-02-08
Salt Lake City	OSM Utah Monthly Map Night		2023-02-09
München	Münchner OSM-Treffen		2023-02-08
IJmuiden	OSM Nederland bijeenkomst (online)	✓	2023-02-08
Neufchâteau	OpenStreetMap – Réunion à Neufchâteau		2023-02-09
Berlin	176. Berlin-Brandenburg OpenStreetMap Stammtisch		2023-02-10
Budapest	Hiking by the pipeline from Barosstelep to the shooting range		2023-02-11
左京区	京都！街歩き！マッピングパーティ：第36回 金地院		2023-02-12
København	OSMmapperCPH		2023-02-12
臺北市	OpenStreetMap x Wikidata 月聚會 #49		2023-02-13
San Jose	South Bay Map Night	✓	2023-02-15
Zürich	Missing Maps Zürich Mapathon		2023-02-15
Karlsruhe	Stammtisch Karlsruhe		2023-02-15
Olomouc	únorový olomoucký mapathon		2023-02-16
Budapest	Hiking by the pipeline towards Százhalombatta		2023-02-18
Toulouse	Réunion du groupe local de Toulouse		2023-02-18
	160. Treffen des OSM-Stammtisches Bonn		2023-02-21
Berlin	Missing Maps – DRK & MSF Online Mapathon		2023-02-22
Karlsruhe	Karlsruhe Hack Weekend February 2023		2023-02-25 – 2023-02-26

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 MatthiasMatthias, Nordpfeil, PierZen, SK53, Strubbl, TheSwavu, TrickyFoxy, YoViajo, barefootstache, derFred, rtnf.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

As part of the desktop improvements project we spent time investing in the core code that powers skins. With support from volunteers (the majority of this support coming from the prolific @Ammarpad), we identified code patterns and made changes to the MediaWiki-Core-Skin-Architecture to retroactively define a data layer API for generating a skin.

Once this was in place, we updated the legacy MediaWiki skins Monobook, Modern, CologneBlue to use Mustache to bring them in line with how Vector and Minerva were built.

The rationale for doing this was as follows:

1. We wanted to centralize code into core, and standardize markup, to make it easier to roll out changes to all skins. Often developers found ourselves updating every skin every time we wanted to make a small change or forced to use specific classes to markup elements (e.g. T248137, T253938).
2. We wanted to move away from server-side technologies to client-side technologies to play better to the strengths of frontend engineers and designers who worked on skins.
3. Since many of these skins do not see active development, we wanted to support them better by reducing lines of code
4. Many of the skins didn't support certain extensions because they used different code (for example certain skins didn't run hooks that were used by certain features) e.g. 6ce3ce1acb68f0a3fdf1bd8824f6d0717bffa320 T259400
5. Stop supporting features in core that were never widely adopted e.g. T97892

This process reduced 106,078 lines of code to 85,310 lines of code - a 20% decrease.
Before the change around 45% of skin code was PHP. After the change PHP only accounted for 15% of the code.

It would be great to in the future migrate Timeless too, but Timeless using the legacy skin platform does help keep us accountable for ensuring we continue to support skins built on this platform.

Methodology for result

To measure code makeup we can run github-linguist before and after the change.

Monobook

Before:

46.53%  22713      Less
36.83%  17981      PHP
16.53%  8071       JavaScript
0.10%   50         CSS
Lines of code: 48815

After change (abe94aa4082dbc4f8b9060528a1b4fea2d0af0f1)

59.28%  22831      Less
20.96%  8071       JavaScript
11.67%  4496       Mustache
7.96%   3066       PHP
0.13%   50         CSS
Lines of code: 38514

Modern

Before:

52.25%  13752      CSS
40.99%  10790      PHP
4.16%   1094       Less
2.61%   686        JavaScript
Lines of code: 26322

After change (c74d67950b6de2bafd9e3b1e05e601caaa7d9452)

68.87%  13877      CSS
18.22%  3672       Mustache
5.43%   1094       Less
4.07%   821        PHP
3.40%   686        JavaScript
Lines of code: 20150

Cologne Blue

Before:

62.00%  19183      PHP
34.82%  10773      CSS
2.22%   686        JavaScript
0.97%   299        Less
Lines of code: 30941

After change (bf06742467f6c6c2bb42367f2e073eb26ed5d495)

40.40%  10765      CSS
31.87%  8491       PHP
24.04%  6405       Mustache
2.57%   686        JavaScript
1.12%   299        Less
Lines of code: 26646

PHP

The total number of lines of PHP before the change: 47954
After the change: 12378 lines of PHP
(This is a 74% decrease in lines of code)

WikiConference India 2023 (WCI 2023) is a national-level conference that provides a common platform for Wikimedians and stakeholders interested in Indic-language Wikimedia projects and other aspects of the movement in India and a few South Asian regions. This is a space to meet, connect, share stories, learnings, best practices, and challenges, and discuss the future strategy of our region. The conference will take place in Hyderabad from 28 to 30 April 2023. 

This conference is of great importance, interest, and impact on the communities in India as it will bring together the Wikimedia movement from India and other Indic communities from South Asia to improve cross-community connections and exchange knowledge and experience. In the past, WikiConference India was first organized in 2011 in Mumbai and then again in 2016 in Chandigarh. Although the third conference was planned to occur in 2020, it had to be called off due to the COVID-19 pandemic. Hence, we are excited to host this year’s conference as we know that conferences play a crucial role in boosting collaboration and strategy and driving progress in the movement. More importantly, it provides a common platform for knowledge sharing.

Our Central and Supporting Themes 

The central theme of WCI 2023 is Strengthening Bonds, which was selected for the conference to highlight the importance of forming and maintaining strong connections between our communities. This theme reflects the belief that a robust support system and cross-learning platforms are essential for collective success. By bringing together community members from different groups, this conference aims to facilitate discussions on fostering and enhancing these critical bonds, ultimately leading to a more connected and supportive movement.

Furthermore, we decided to take the central theme forward by creating specific sub-themes relevant and representative of the region. These themes have been incorporated into our conference logo and will be incorporated into the design of the conference and the attendees’ experience.

India is a land of vibrant colors seen through our culture, biodiversity, regions, and food, similar to our community in the region. One of the most recognized symbols of vibrance is the Peacock, the National Bird of India, known for its cultural, historical, and religious significance and resplendent colors.

One of the conference’s main objectives is to build bonds, collaboration, and a growing sense of unity and togetherness. We have taken the globally recognized Unity symbol to drive this objective forward.

India is undoubtedly a diverse country with one of the largest and youngest populations in the world and several languages, cultures, and traditions. But India is also home to a rich flora and fauna, our biodiversity. Our community works on various projects, languages, technologies, and cultures and is a diverse movement. We have taken the Banyan tree, the National Tree of India, to symbolize our diversity due to its sacred and scientific significance.

We are stronger together: this is one of the main objectives for hosting WCI 2023. To symbolize this, we adopted the Bengal Tiger, the National Animal of India, on our logo as a symbol of the nation, the region and representative of the theme of Strength.

To access the Logo files, please click here.

Have an idea you want to share? We are open to ideas on how to enhance the conference; write them here.

Keep In Touch! If you want to keep in touch with the updates on the conference, you can visit our Meta Page, email us contact@wikiconferenceindia.org  or join our Telegram Channel

Update: On February 6, 2023, the Wikimedia Foundation was made aware that the Pakistan Telecommunications Authority (PTA) had been directed to restore access to Wikipedia in Pakistan. Our internal traffic team has confirmed that the traffic on Wikimedia websites from Pakistan has resumed as before. Wikipedia was blocked by the PTA on February 3, 2023.  The people of Pakistan rely on Wikipedia both as a knowledge resource and as a pathway to share their knowledge with others. They make Wikimedia projects richer and more representative of the world with their culture, history and perspectives. Wikipedia is available in more than 300 languages; its 55 million articles bring together information from news, research, and other publications to create a living record of history. Lifting this ban means that the people of Pakistan can continue to benefit from and participate in its growth within a global movement that strives to spread and share knowledge that is verified, reliable and free. The Wikimedia Foundation believes that knowledge is a human right. We welcome the support of governments everywhere in upholding it. 

3 February 2023 — On Friday, February 3, 2023, Pakistan’s Telecommunications Authority blocked Wikipedia and Wikimedia projects. The Wikimedia Foundation calls on Pakistan to restore access to Wikipedia and Wikimedia projects in the country immediately.  

The Wikimedia Foundation received a notification from the Pakistan Telecommunication Authority on February 1, 2023, stating “the services of Wikipedia have been degraded for 48 hours” for failure to remove content from the site deemed “unlawful” by the government. The notification further mentioned that a block of Wikipedia could follow, if the Foundation failed to comply with the takedown orders.  As of Friday, February 3, our internal traffic reports indicate that Wikipedia and Wikimedia projects are no longer accessible to users in Pakistan.

The Wikimedia Foundation believes that access to knowledge is a human right. Wikipedia is the world’s largest online encyclopedia, and the main source of trusted information for millions. It’s an ever-growing record of history, and gives people from all backgrounds the opportunity to contribute to everyone’s understanding of their religion, heritage, and culture. 

In Pakistan, English Wikipedia receives more than 50 million pageviews per month, followed by Urdu and Russian Wikipedias. There is also a sizable and engaged community of editors in Pakistan that contribute historical and educational content. A block of Wikipedia in Pakistan denies the fifth most populous nation in the world access to the largest free knowledge repository. If it continues, it will also deprive everyone access to Pakistan’s knowledge, history, and culture.

Wikipedia is written by nearly 300,000 volunteer editors. Together, this global community of volunteers has designed robust editorial guidelines that require strict citations and references to verified sources of information. Content on Wikipedia is mined from secondary sources; it does not allow original research. The community is guided by values of neutrality, reliability, and equitable access to information. 

The Wikimedia Foundation does not make decisions around what content is included on Wikipedia or how that content is maintained. This is by design to ensure that articles are the result of many people coming together to determine what information should be presented on the site, resulting in richer, more neutral articles.  We respect and support the editorial decisions made by the community of editors around the world. There are dedicated response channels available to individuals, organizations, or governments that would like to raise concerns about the site’s content directly with volunteer editors for their consideration and review. This contributes to Wikipedia’s transparency and upholds its collaborative model.

We hope that the Pakistan government joins with the Wikimedia Foundation in a commitment to knowledge as a human right and restores access to Wikipedia and Wikimedia projects promptly, so that the people of Pakistan can continue to receive and share knowledge with the world.    

For media inquiries, please contact press@wikimedia.org.

I landed file upload support in the mwapi (docs) and mwbot (docs) crates yesterday. Uploading files in MediaWiki is kind of complicated, there are multiple state machines to implement and there are multiple ways to upload files and different options that come with that.

The mwapi crate contains most of the upload logic but it offers a very simple interface for uploading:

pub async fn upload<P: Into<Params>>(
        &self,
        filename: &str,
        path: PathBuf,
        chunk_size: usize,
        ignore_warnings: bool,
        params: P,
) -> Result<String>

This fits with the rest of the mwapi style of simple functions that try to provide the user with maximum flexibility.

On the other hand, mwbot has a full typed builder with reasonable defaults, I'll just link to the documentation instead of copying it all.

A decent amount of internal refactoring was required to make things that took key-value parameters now accept key-value parameters plus bytes that should be uploaded as multipart/form-data. Currently only uploading from a path on disk is supported, in the future I think we should be able to make it more generic and upload from anything that implements AsyncRead.

Next steps for mwapi

This is the last set of functionality that I had on my initial list for mwapi, after the upload code gets some real world usage, I'm feeling comfortable calling it complete enough for a 1.0 stable release. There is still probably plenty of work to be done (like rest.php support maybe?), but from what I percieve a "low-level" MediaWiki API library should do, I think it's checked the boxes.

Except....

Future of mwapi_errors

It took me a while to get comfortable with error handling in Rust. There are a lot of different errors the MediaWiki API can raise, and they all can happen at the same time or different times! For example, editing a page could fail because of some HTTP-level error, you could be blocked, your edit might have tripped the spam filter, you got an edit conflict, etc. Some errors might be common to any request, some might be specific to a page or the text you're editing, and others might be temporary and totally safe to retry.

So I created one massive error type and the mwapi_errors crate was born, mapping all the various API error codes to the correct Rust type. The mwapi, parsoid, and mwbot crates all use the same mwapi_error::Error type as their error type, which is super convenient, usually.

The problem comes that they all need to use the exact same version of mwapi_errors, otherwise the Error type will be different and cause super confusing compilation errors. So if we need to make a breaking change to any error type, all 4 crates need to issue semver-breaking releases, even if they didn't use that functionality!

Before mwapi can get a 1.0 stable release, mwapi_errors would need to be stable too. But I am leaning in the direction of splitting up the errors crate and just giving each crate its own Error type, just like all the other crates out there do. And we'll use Into and From to convert around as needed.

At Wiki Education, we spend a lot of time working to make Wikipedia and Wikidata more representative of the world we live in. Many of our courses focus on content gaps about historically marginalized communities, so that our programs and the greater Wikipedia editing community can systematically tackle them at scale. Unfortunately, there have been few tools to assist in addressing this issue at scale – until now. Thanks to the Nielsen Foundation’s generous support through their 2022 Data for Good grants program, we are designing a portal focused on equity that will identify representation gaps on Wikipedia and Wikidata, and allow us to use our courses to help close them.

The instant availability of knowledge on your personal devices has revolutionized how we learn about the world around us. When you ask Google about a topic or pose a question to a virtual assistant like Alexa, the answer you get will likely come from Wikidata. That makes the open data repository an essential resource that we must make sure reflects the fullness of human knowledge. Limited coverage on Wikipedia and Wikidata of historically excluded populations and notable women has not reflected their historical importance. One of the potential causes of these gaps is that the majority of Wikipedia’s editing community are white and male. Wiki Education is committed to addressing these opportunities for growth and expanding both the editing population and coverage of historically marginalized communities on Wikidata and beyond.

Currently, groups of Wikipedia editors surface content gaps on Wikipedia manually, often through online common spaces called WikiProjects. We are inspired by the massive success of Women in Red, a WikiProject focused on expanding and adding articles about women on Wikipedia. Thanks to dedicated volunteer editors, the number of biographies about women has increased from 15% of all Wikipedia biographies to 19% since October 2014. Considering that there are almost 2 million biographies today on the English Wikipedia, 4% is quite a jump. While more progress needs to be made, the project has helped add much-needed visibility and credibility to women’s accomplishments that will inspire generations of leaders.

Using Wikidata in concert with Wikipedia provides a place to build a tool that can scale this important work further. Using Women in Red as a model, our online portal will allow the Wikipedia community to use information queried from Wikidata to tackle the gaps in knowledge in an organized way. Women in Red relies heavily on Wikidata queries to generate lists of women who do not yet have Wikipedia articles. With this approach, we will scope the queries to different demographics and create new lists of articles that do not exist on Wikipedia. We will leverage our portal to provide insights into the types of courses that we offer in our Scholars & Scientists Program.

We will also add this portal to the “Finding your article” training module on our Dashboard’s library of resources for student editors participating in our Wikipedia Student Program. This tool would guide students to edit Wikipedia articles that need the greatest amount of attention. We believe that the broad community who looks to Wiki Education for tools and resources will also benefit from this portal for their own initiatives and across languages.

Wiki Education’s new transformative portal will deepen the engagement of new and current program participants by empowering them to quickly assess the topics and communities most in need of improvement and representation on Wikipedia.

At the same time, we want to acknowledge that data about the personal identity of prominent figures is extremely sensitive and personal. We want everyone to know that in order for this kind of data to exist on Wikipedia, it must have a reliable source backing up that fact. It’s our hope that this portal will help encourage better sourcing, correcting errors, and a better ability to identify inaccurate or potentially harmful data from winding up (and staying) on Wikidata and Wikipedia.

Throughout this year, I’ll be developing a working prototype of the online portal and gathering feedback from the Wikimedia community. I’ll use Wikidata to test the functionality of the portal and add demographic properties that can be selected by Wikipedia editors to identify gaps in coverage of historically marginalized communities. We’re excited to leverage this portal to improve Wikipedia’s coverage of underrepresented groups and help volunteers provide millions of readers with more equitable information.

🕑 1 hour 44 minutes

Waldir Pimenta is the co-founder of Wikimedia Portugal, and an active translator of core MediaWiki and extensions. He has also been involved in developing various Wikimedia-related tools.

Links for some of the topics discussed:

• Wikimedia Portugal
  • Timeline of founding
• Cape Verdean Creole ("kea") translation statistics
• Unicode CLDR Project
• "Geeks and Nerds" xkcd comic
• tldr pages application
  • Community roles document
• Indeed's FOSS Contributor Fund guidebook
• Emma Irwin and [Microsoft's] FOSS Fund Program (Sustain OSS podcast)
• GitHub Accelerator
• GiveDirectly Wikipedia article
• The Giving Pledge Wikipedia article
• Open Collective Foundation
• Toolforge abandoned tool policy
• Wikimate MediaWiki API wrapper
• "Non-Hierarchical Management", Aaron Swartz, 2009
• Guido van Rossum on stepping down as Python's BDFL (YouTube video)
• DoOcracy (CommunityWiki)
• Teal organisation Wikipedia article
• Sortition Wikipedia article

The WS Contest tool was breaking on Index pages that don’t yet have any (existing) pages. The problem was in the usage of the dflydev/dot-access-data, which is a thing for pulling values out of deep arrays. It’s sort of useful, but not widely used so does feel a bit weird. Maybe we should remove it from wikisource/api.

Actually, scratch that: I just went to look, and it’s got eighty-three million installs on Packagist. So I guess it’s more widely used than I’d thought. I’ll leave it in for now.

There’s a scene in AMC’s “Breaking Bad” where Gail Boetticher explains to Walter White how to make the perfect cup of coffee. And it all sounds so plausible—there’s a perfect coffee, and science will magic it for us.

That whole idea, scene, and contraption are, of course, wrong.

But there are real ways to experiment your way towards a more perfect cup.

🗺️ The quest for good coffee

In 1957, a professor of food science at MIT forever changed what we think of as good coffee.

E.E. Lockhart posited that coffee flavor is the result of two variables:

1. How much coffee you use
2. How much of that coffee dissolves into the final cup (total dissolved solids—TDS%)

Lockhart surveyed a bunch of people to suss out the ideal range for these values, creating the “Coffee Brewing Control Chart,”—which is still in use today.¹

And you can use Lockhart’s data to better your own brew.

🔬 Coffee science at home

When he was developing the Aeropress, Alan Adler was a frequent poster on the coffeegeek forums. There he shared the results of his experiments measuring coffee using a simple brix refractometer.

And, unfortunately for everyone in my immediate family—I own one of those, too!

🧪 An experiment: finding the ideal grind for the Hario v60

Over Christmas, I got a Hario v60 pour-over brewer. And I used science to zero-in on what I think is the perfect grind size.

Materials

• Hario V60 plastic dripper
• Baratza Virtuoso
• Bonavita electric kettle
• Escali Primo gram scale
• Ethiopia Refisa dry process from Ozo coffee
• Tap water—the miracle of modernity

Methods and Results

I tried to brew two cups of coffee the exact. same. way. Except for one variable: the grind.

Variable	Course grind	Fine grind
Grinder dial setting	22	17
Water temperature	95°C	95°C
Water amount	320g	320g
Coffee used	20g	20g
Coffee brewed	277g	271g
TDS%	1.4%	1.7%
Extract%	20%	23%

This measured difference is obvious, but can I taste a difference?

Taste and preference

A widely used protocol for figuring out if you can discern a difference between two products is the triangle test.

In a triangle test, you present three cups of coffee: two are identical, one is different. The goal is to pick out the odd cup consistently (better than random change; i.e., 1/3).

So, I took my two coffees and split them into 3 cups:

• 3 cups: A, B, and C
• Cups A & C – fine grind (“17”)
• Cup B – course grind (“22”)

And, then I mixed up the cups and tried to pick the odd one out:

Result	Trial	Different cup	Cup I picked
✅	1	B	B
✅	2	B	B
❌	3	B	A
❌	4	B	A
✅	5	B	B

As dramatic as the chart above looks, picking the “different” cup was tricky. I encourage you to try it—it was a fun experiment.

In the end, I preferred the course grind—it seemed sweeter and fuller vs. the fine grind. The fine grind coffee was astringent: sharp and tannic.

Getting ready to travel again I haven’t traveled in four years. My last trip happened in 2019 when I spoke at a local Google Developers Group event in Brasília. As a disabled person, I’ve been quite cautious about returning to all in person activities—the lack of testing and masking discourage me from attending most conferences and meetings. CZI reached out to me by the end of December asking me if I had interest in attending a workshop in Buenos Aires in April (thanks for the recommendation, Karen!

17/01/2023-23/01/2023

Mapping

• User bradrh consulted the US Forest Service Motor Use Maps to update motor vehicle access restrictions on forest roads and trails in several national forests.
• Bryce Cogswell (bryceco) listed every OpenStreetMapper that has managed to map for more than a thousand days without a break.
• Lejun described ► how to merge data from different sources into OpenStreetMap. He explained the different tools and methods, including the JOSM plugin UtilsPlugin2.
• Christoph Hormann wrote a blog post describing the problems with the name key and promised to try to propose a possible solution in his next post.
• Tomas_J has provided ►
  pictures and suggested tagging for a few Slovak-specific features.
• Valerie Norton (valhikes) has summarised her mapping activity around Gunnison, Colorado between February and September 2022. Details of each hike, with lots of photos, are posted on her blog.
• Voting on the suggestion to announce proposals on the OSM Community forum, as well as the tagging mailing list, has closed. It was approved with 48 votes for, 5 votes against and 0 abstentions.

Community

• OpenStreetMap recently hit a milestone with more than 10 million user accounts. The milestone was discussed on r/openstreetmap. It should be noted that only about 1.9 million of these accounts have been used to make a map edit.
• Daniel Capilla (dcapillae) has created ► a tutorial on how to make a metrominuto (a schematic map of a municipality or city that represents the distances between its main points and the average time it takes to walk between them) of your area of interest.
• Mevesscarto gave ► us an update on their progress to armchair map the French department Côtes d’Armor.
• watmildon explained the JOSM and MapWithAI workflow that they are using to add missing street addresses to OSM.

OpenStreetMap Foundation

• Get to know the new OSMF Board. In December 2022, four new members were elected to the OpenStreetMap Foundation Board, complementing the three members already serving. The new members, Arnalie Vicario, Craig Allan, Mateusz Konieczny, and Sarah Hoffmann, have joined Guillaume Rischard, Mikel Maron, and Roland Olbricht.

Local chapter news

• Nominations for the OpenStreetMap US 2023 Board Elections are now open. The OSM US blog has more details if you are interested.

Education

• UN Mappers has launched the UN Maps Learning Hub, a self-learning platform accessible to anyone interested in the OpenStreetMap project. Courses will be available in several languages and will cover aspects of topographic and humanitarian mapping. The OSM Basics course is already available.

OSM research

• With the release of the OSHDB (OpenStreetMap History Database) Version 1 for spatio-temporal analysis, the HeiGIT team at Heidelberg University has reached an important milestone. The data is open to everyone, whether they belong to journalism, science or humanitarian organisations. The ohsome dashboard allows you to analyse OSM temporal data for any region. A significant enhancement is the new OSHDB filters that allow practitioners to filter entities by the shape of the geometry (one measure of quality often discussed by the OSM community).
• GeoObserver has published ► the third part of its ‘Meierloch’ trilogy on the distribution of surnames and their visualisation on a map.

switch2OSM

• Roberto Brazzelli described ► how the municipality of Limone (Piemonte, Italy) provides a map of amenities using uMap. Data is maintained in OSM by council staff, but updates are quality controlled via QGIS with data cached in Google Sheets from Overpass queries.

Software

• Kshitij Raj Sharma has created ‘OpenStreetMap Stats Generator’, which uses osmium to analyse the change files from OSM and generate statistics in different file formats such as csv, json, and jpg. Results are also being tweeted. A second bot follows the recent trends on OSM and retweets the findings with hashtags #osm, #openstreetmap and #hotosm every three hours.
• rtnf asked why the OpenStreetMap Stats Generator needs an OpenStreetMap login and proposed a lightweight version without the need for credentials.

Programming

• [1] rtnf, inspired by posts on imagery collected by MapComplete (we reported earlier), has created a web app that randomly samples MapComplete images. In his blog, he explained how to visualise tagged imgur images on OSM.
• Jake Coppinger reported on his efforts writing a vector tile server for osm2streets to provide lane-accurate street maps with OpenStreetMap. Jake also revealed that his Safe Cycling Map now works for the entire world.
• Tobin Bradley recorded a screencast video that captures how protomaps is used to create a PMTiles file, a single file vector tiles format, and integrate it into a MapLibre demo map. This setup allows you to create vector tile maps with static infrastructure.
• starsep explained how Bing StreetSide imagery can be used for mapping with JOSM.

Did you know …

• … about the shop suffix for repair? You can use this to specify services available for computers, bicycles, shoes and more, as tooted by OSM Tourism.
• … Thomas Gratier’s comprehensive listing of map-related things?
• … the OSM Welcome tool, hosted by OSM-Belgium? This app helps identify new contributors to OSM in a given area, how many edits they’ve made, and their preferred editor. It also keeps track of which users have been sent a welcome message via the site.
• … the comparative overview of possibly every OSM-related Android app?

Other “geo” things

• The Equal Earth physical map of the world is now available in German, thanks to the work of Simon Scherrer.
• Devin Lea has started a new weekly social media hashtag #MapPromptMonday with a different theme each week. Last week the theme was using colour-blind friendly symbology. Upcoming themes have been listed.

Upcoming Events

Where	What	Online	When	Country
IJmuiden	OSM Nederland bijeenkomst (online)	✓	2023-01-28
南区	京都！街歩き！マッピングパーティ：第35回 六孫王神社		2023-01-29
Windsor	OSM Windsor-Essex Monthly Meetup		2023-01-31
San Jose	South Bay Map Night	✓	2023-02-01
Hannover	OSM-Stammtisch Hannover		2023-02-06
	MapRoulette Monthly Community Meeting		2023-02-07
	OSMF Engineering Working Group meeting		2023-02-07
Strasbourg	Mapathon CartONG		2023-02-07
City of Westminster	Missing Maps London Mapathon		2023-02-07
Stuttgart	Stuttgarter Stammtisch		2023-02-07
Zürich	OSM-Stammtisch		2023-02-08
Salt Lake City	OSM Utah Monthly Map Night		2023-02-09
London	London social pub meet-up		2023-02-08
München	Münchner OSM-Treffen		2023-02-08
Neufchâteau	OpenStreetMap – Réunion à Neufchâteau		2023-02-09
左京区	京都！街歩き！マッピングパーティ：第36回 金地院		2023-02-12
København	OSMmapperCPH		2023-02-12
San Jose	South Bay Map Night	✓	2023-02-15
Karlsruhe	Stammtisch Karlsruhe		2023-02-15
Olomouc	únorový olomoucký mapathon		2023-02-16

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 ChristopherGS, Kasey2, MatthiasMatthias, Nordpfeil, PierZen, SK53, SeverinGeo, Strubbl, TheSwavu, barefootstache, derFred.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

I’ve been working on linking Commons items to Trove. It’s not complicated, on the surface, but of course once you get into it things get more annoying. I’m trying to just figure out the basics, and not get too deep into the weeds.

Basically what we want is for every file on Commons, that has been sourced from an institution that’s aggregated in Trove, to have a P10044 statement (‘Trove Work ID’), and for that to be displayed in the |source= parameter of the Information template. But we also want to say which library (etc.) it came from, and to link to that library’s catalogue (because that’s where the actual image file is stored). This means, I think, that we’ll want to stick to the SLQ, SLWA, SLSA, AWM-image, etc. templates that have institution-specific information and links, and just add a simple line to those that explains that the file’s metadata is also on trove and what its ID there is.

I was intending to write a pretty different blog post about progress on mwbot-rs but...ugh. The main dependency of the parsoid crate, kuchiki, was archived over the weekend. In reality it's been lightly/un-maintained for a while now, so this is just reflecting reality, but it does feel like a huge setback. Of course, I only have gratitude for Simon Sapin, the primary author and maintainer, for starting the project in the first place.

kuchiki was a crate that let you manipulate HTML as a tree, with various ways of iterating over and selecting specific DOM nodes. parsoid was really just a wrapper around that, allowing you get to get a WikiLink node instead of a plain <a> tag node. Each "WikiNode" wrapped a kuchiki::NodeRef for convenient accessors/mutators, but still allowed you to get at the underlying node via Deref, so you could manipulate the HTML directly even if the parsoid crate didn't know about/support something yet.

This is not an emergency by any means, kuchiki is pretty stable, so in the short-term we'll be fine, but we do need to find something else and rewrite parsoid on top of that. Filed T327593 for that.

I am mostly disappointed because have cool things in the pipeline that I wanted to focus on instead. The new toolforge-tunnel CLI is probably ready for a general announcement and was largely worked on by MilkyDefer. And I also have upload support mostly done, I'm just trying to see if I can avoid a breaking change in the underlying mwapi_errors crate.

In short: ugh.

The Community Wishlist Survey starts today. This is an annual survey that my team at the Wikimedia Foundation runs, to figure out what we should work on for the following year. It’s always so interesting to see what features and bugs are felt to be the most important. Quite often I agree, and get excited about working on them; sometimes I’ve never even heard of the software components in question! The Wikimedia universe is wide and varied.

So if anyone Wikimedians out there have ideas, please come and propose them!

The (fairly terrific) locator-tool now has aerial imagery available as a map layer, making geolocating photos even more fun.

A new extension this week: CopyCreds

The CopyCreds extension registers two new tags and , which make the text inside them visually distinctive, and allows for click-to-copy. The goal is to make life easier for those who document usernames and passwords in MediaWiki.

I like the idea of a simple click-to-copy system for a wiki, but I’m not sure it warrants two new tags. Personally I’d prefer something like foo or something like that, with a means to customize the colour etc. of the displayed value. Actually, maybe that’s what CopyLink does. There used to be one called CopyToClipboard which also did something similar.

Maybe someone should write the Copyencabulator 2000, to unite them all…

10/01/2023-16/01/2023

Breaking news

• The next public OSMF Board meeting will be held in the online boardroom on Thursday 26 January at 13:30 UTC.
  The preliminary agenda is on the Board/Minutes/2023-01 wiki page and this is also where the draft minutes will be added.The topics to be covered are:
  • Treasurer’s report
  • Provisional 2023 budget
  • Strategic plan – formal structure report
  • Advisory Board – monthly update
  • Monthly presentation – YouthMappers
  • Guest comments or questions.

  Find out on the Monthly Board Meetings wiki page how to have future board meetings automatically added to your calendar.

About us

• Do you read our blog in English?
  Do you want to read the new issue two days earlier?
  Do you want to help prepare weeklyOSM?
  Are you a native English speaker?
  Then we are looking for you!
  Write us a short email to info at weeklyosm dot eu and we will let you know how you can help.
• From this issue we are publishing our weeklyOSM articles under the CC0 licence instead of CC-BY-SA. You can link, cite, reuse or rephrase our articles without restrictions. Nevertheless we are of course happy if you still attribute us.

Mapping

• One culture’s profanity may be another’s street name. Meta’s #ProfanityCleanup edits triggered a discussion on Talk-GB about this topic.
• Andy Townsend (SomeoneElse) documented how he followed a path that existed only on a map and concluded that it doesn’t belong in OSM.
• Mateusz Konieczny is seeking the community’s view on the difference between surface=fine_gravel and surface=compacted.
• Voting is underway on the proposal to extend the usage of utility=* to apply consistently to service/industrial buildings and cabinets, until Thursday 26 January.

Community

• In the Geomob Podcast #164 Ed Freyfogle chatted with Simon Poole, OSM mapper since 2010, former chair of the OSMF, and maintainer of Vespucci, about his perspective on OpenStreetMap.
• The OpenStreetMap Ops Team gave an update on the status of the migration of the old forum content to the new OSM Community forum.

Local chapter news

• The OpenStreetMap Polska Association is ► proud to announce the signing of an agreement with CloudFerro, the operator of the Creodias platform to enable, but not limited to, further development of the www.openaedmap.org project.

Events

• @dukera, in a video, explained how Overpass can be used in geospatial intelligence.
• Edward Betts is going to talk at the upcoming FOSDEM about linking OpenStreetMap and Wikidata.

OSM research

• A paper from HeiGIT and GIScience at Heidelberg University, on improving the accuracy of OSM missing building detection in sub-Saharan Africa, was featured on the May 2022 cover of Transactions in GIS. The team proposed a novel few-shot transfer learning method (FSTL) to improve humanitarian organisations’ mapping workflows in the Global South. Further details on the approach, and its current limitations, is available on the HeiGIT site.

Licences

• Pieter Vander Vennet investigated, using Overpass, what licences MapComplete users are applying to their uploaded pictures. The vast majority are uploaded with the default licence, being CC0/public domain. Power users, though, often change the licence to CC-BY or CC-BY-SA. As a by-product of his investigation, a ranking of MapComplete’s most active users has been compiled, led by ‘legendary mapper’ Awo.

Software

• Anne-Karoline Distel spotted that Field Papers was not working (see also a Reddit thread). Ciarán (DeBigC) reported it on GitHub and, fortunately, Alan Maconchie restarted the server. However, as with other Stamen services, they are looking for others to take on support.
• James Milner found that ChatGPT is pretty good at generating GeoJSON.
• GeoDesk reported a new feature: stats queries. The thread includes various examples of typical queries, from the opening hours of pubs in Scotland, to the length of rivers in Colorado.

Programming

• MTRNord tooted that they have created a script to quickly build transit maps using the Cartes tool, after it was reported on weeklyOSM.

Releases

• QA tool Osmose has introduced a new check for buildings on agricultural land that appear to be too large.

Did you know …

• … there are special phrases that cause Nominatim to search for a specific key=value pair?
• … if you mix up latitude and longitude, Alvin Bryan has some tips to remember them correctly?

OSM in the media

• Carey Davies, writing in The Great Outdoors magazine, provided in-depth analysis of recent mountain rescue incidents in the English Lake District, which were occasioned by the use of outdoor hiking apps based on OpenStreetMap data. Earlier, The Guardian and online magazine Grough had also covered this topic. It is these reports that led to SK53’s path analysis, which we reported earlier.
• Alex Roddie, quoted in The Great Outdoors article above, published his own detailed analysis of the use of OpenStreetMap by a range of outdoor hiking applications. He received a lot of feedback from experienced UK-based mountain guides on both Twitter and Mastodon.
• Netzpolitik recommended ► installing StreetComplete and other FOSS tools to rid yourself of GAFAM.

Other “geo” things

• Google Maps has introduced a visual positioning system ‘to provide location and navigation services for users of its AR “Live View” feature’.
• Giorgia Tolfo blogged on how the Living with Machines project is digitising 19th century Ordnance Survey maps from the British Library. The work is complementary to the well-known historical maps hosted by the National Library of Scotland, as the focus is on maps not already available digitally. Living with Machines is the flagship Digital Humanities project of the Turing Institute, the UK national AI research institute.
• The American Geographical Society published its ‘Map of the week’ with the title ‘What does the land under Antarctica’s ice sheet look like?’.
• Christoph Hormann wrote about the open licensing of map designs.
• Abhishek Nagaraj and Scott Stern have written an essay on the distinctive economic properties of maps and the role that geographic information plays in economic geography.
• Astronomers also create maps. See the universe from above!

Upcoming Events

Where	What	Online	When	Country
Dar es Salaam	State of the Map Tanzania		2023-01-19 – 2023-01-21
Budapest	Hiking by the pipeline between Normafa-Stop Shop-Aranyvölgy		2023-01-21
Toulouse	Réunion du groupe local de Toulouse		2023-01-21
	Downtime		2023-01-22
Bremen	Bremer Mappertreffen (Online)		2023-01-23
	OSMF Engineering Working Group meeting		2023-01-24
Düsseldorf	Düsseldorfer OpenStreetMap-Treffen	✓	2023-01-25
	[Online] OpenStreetMap Foundation board of Directors – public videomeeting		2023-01-26
IJmuiden	OSM Nederland bijeenkomst (online)	✓	2023-01-28
南区	京都！街歩き！マッピングパーティ：第35回 六孫王神社		2023-01-29
Windsor	OSM Windsor-Essex Monthly Meetup		2023-01-31
San Jose	South Bay Map Night	✓	2023-02-01
Hannover	OSM-Stammtisch Hannover		2023-02-06
	MapRoulette Monthly Community Meeting		2023-02-07
Stuttgart	Stuttgarter Stammtisch		2023-02-07
City of Westminster	Missing Maps London Mapathon		2023-02-07
Zürich	OSM-Stammtisch		2023-02-08
München	Münchner OSM-Treffen		2023-02-08
Salt Lake City	OSM Utah Monthly Map Night		2023-02-09
Neufchâteau	OpenStreetMap – Réunion à Neufchâteau		2023-02-09

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 MatthiasMatthias, Nordpfeil, PierZen, SK53, Strubbl, TheSwavu, YoViajo, derFred.
We welcome link suggestions for the next issue via this form and look forward to your contributions.