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

The UNLOCK Accelerator by Wikimedia Deutschland has successfully been running from 2020-2022. In three editions, the program has managed to expand the existing Free Knowledge project landscape and has helped projects that were previously outside of the Wikimedia Movement to gain more access to our community. In total, 17 prototypes were developed by project teams spanning 11 countries. Of these, more than 50 percent are still being further developed and implemented. (Want to dive deeper? Browse through the project results on our landing page.)

Where we are heading in 2023

However, there have also been some challenges faced by the program. These included difficulty in reaching our target audience and supporting the projects in the long-term. 

In light of these challenges, the decision has been made to discontinue the UNLOCK Accelerator in its current form. Instead, throughout 2023, we will explore what the “UNLOCK of the future” might look like in order to create greater impact and be of most value to the Wikimedia Movement.

The ultimate outcome we are working towards is for UNLOCK to become an innovation engine for free knowledge and create an environment in which innovation and innovators from our communities can grow. We aim to encourage people to experiment with and create new Free Knowledge projects and contribute to the development of an innovation culture and thereby strengthen the Movement’s capacity to innovate. In other words, we seek to find effective modes of implementation for the Movement Strategy recommendation number 9, “Innovate in Free Knowledge”. With this in mind, the overall intention of our work will not change from the past few years. Rather, we are considering new modes of implementation. We will test new formats and activities as we build a new program. In this process, of course, we want to incorporate all of our key learnings from running three editions of the UNLOCK Accelerator program.

We want you to join this process

For this re-imagining process throughout the coming months, we are very interested in the exchange with individual community members and affiliate groups. Your perspective will help us to make effective and targeted decisions most beneficial to you, the Wikimedia Movement. 

We will be in touch, or if this is something you already know that you are interested in, the best way to reach our team at Wikimedia Deutschland is unlock@wikimedia.de We are looking forward to kick-starting this process with you!

Need more information?

Head over to our blog post to better understand the reasons for this change, as well as what the process for 2023 will look like more specifically!

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.

Hi everyone – This month marked my official one-year anniversary as CEO of the Wikimedia Foundation. Based on some feedback from this list,  I have tried to send a regular update every few months (see January, April, June, September). I wanted to send another one today to reflect on my first year, and share upcoming work we have planned at the Foundation. 

Some of you may recall that I prepared for joining Wikimedia with a two-month listening tour that led me to talk to a few hundred volunteers and Foundation staff across 55 countries. This shaped the five puzzles and three priorities that I shared with you when I started. These puzzles continue to guide what I believe are the biggest questions we must answer collectively, especially the question of, “what does the world need from us now?”

I also completed the three priorities I outlined last January: (1) reimagining the Foundation’s annual plan to be more firmly anchored in our movement’s strategic direction; (2) recruiting a capable Chief Product & Technology Officer for the Wikimedia Foundation; and (3) starting to refresh the Foundation’s organizational values to guide our ways of working with each other, and with all of you. 

English Fundraising Campaign

As 2022 came to a close, a Request for Comment (RfC) launched on English Wikipedia to propose changes to the messaging of year-end fundraising banners. The Wikimedia Foundation accepted the guidance provided by the RfC, and established a co-creation page to seek volunteer input on banner messaging from community members. Throughout the fundraising campaign, the Foundation team posted regular updates to this co-creation page. In brief, over 450+ banners were tested during this year’s campaign, and 4.7M of revenue was raised compared to the original 10M goal (a shortfall of $5.3 million). During the first few days, the new banners resulted in about 70% less revenue than on the corresponding days in the prior year. Additional information on the campaign results are posted here. The fundraising team will continue to work with all language communities on banner messaging in the year ahead, and we look forward to building on what we learned in this campaign. 

The RfC raised a much wider range of issues than just fundraising banners. While anticipated revenue shortfalls made this a difficult period for the Foundation, I believe we tried to hear these broader concerns, many of which are shared across communities beyond English Wikipedia. 

One concern was about the very rapid budget growth of the Foundation, which has stabilized in the last year. Given the revenue gap from this year’s English campaign, we are reviewing and lowering our expenditure for the current year. And I anticipate we will have a reduced budget and certainly slower growth next year. We will have more information by April on future financial projections. 

I communicated previously that I have started frank conversations with the Board of Trustees and Foundation staff about what roles the Foundation should grow (like support for technology) and what activities we should hand over to others or stop altogether. Looking ahead, the size of our budget should be driven by what the Foundation should be doing and can actually do well. The 2030 movement strategy provided guidance (and motivated much of our historic growth), but was short on specifics. I await the Movement Charter to provide further clarity, but believe the Foundation may need to make some decisions sooner. 

A second concern was about the Foundation’s responsiveness to editors and other technical contributors. We collectively have to respond to decades of growing technical debt, poor processes for maintaining software, and staying relevant in a world where technology keeps going faster. There is no quick fix to most of our technical challenges. 

That said, our Chief Product and Technology Officer Selena Deckelmann, who comes with experience supporting online communities and collaborating with technical contributors, has made meaningful progress in her first six months. She has shared the following update: 

“We’ve made progress on PageTriage issues raised by New Page Patrollers in an open letter. In the last 120 days, 141 patches have been reviewed through collaboration between the Foundation and the community. There have also been several meetings between community members and staff to talk about the future of PageTriage and the newcomer experience, and there is now work planned in Q4 to update the extension. We continue to engage with Commons as we are making critically needed software upgrades to community prioritized tools. The Foundation’s Wishathon (leading up to the community wishlist kickoff for 2023) involved about 40 staff contributing time over a week in December to deliver 71 patches and 4 wishes granted. We are working with communities to make Vector 2022 the default skin, after 3 years of development work, feedback and continued iteration with wiki communities.” 

In March, Selena will be ready to host forums to share what she thinks are needed improvements to the Foundation’s processes, including technical support and collaborative product development. Beginning next week, the Foundation’s product and technology teams will start posting their planned objectives to solicit input and guidance from contributors. 

And, finally, comments were made in the RfC about the unclear role of Tides in managing the Knowledge Equity Fund. Over the next few months, we will be moving the remainder of the Equity Fund from Tides back into the Foundation. Relatedly, the Wikimedia Endowment has received its 501(c)(3) status from the US Internal Revenue Service. We are in the process of setting up its financial systems and transitioning the Endowment’s funds out of Tides as well. 

Looking Ahead

In my 9-month update, I shared that my top three priorities will remain strategy, leadership and culture. 

On strategy, the Board of Trustees will meet this March in New York to consider a few topics that require taking a multi-year view: 

(1) Wikimedia’s financial model and future projections for revenue streams in online fundraising (which we anticipate will not continue to grow at the same rate), the next phase of the Wikimedia Endowment, and the lessons we have learned so far from Wikimedia Enterprise‘s first year in operation. 

(2) Re-centering the Foundation’s responsibility in supporting the technology needs of the Wikimedia movement by understanding the needs of our contributor communities, as well as emerging topics like machine learning/artificial intelligence and innovations for new audiences. 

(3) Beginning more focused conversations to establish frameworks and principles for understanding the Foundation’s core roles and responsibilities. This is intended to help to provide inputs into the movement charter deliberations and broader movement strategy conversations. 

Members of the Movement Charter Drafting Committee and Wikimedia Endowment Trustees will join in the March discussions, and we will share a report with you after the meeting. 

This strategic planning will happen concurrently to our annual planning cycle. Annual planning is being led this year by the needs of our Product & Technology departments. This will be the first time since about 2015 that these two departments will undertake joint planning. Our intent is to repeat the two-way planning processes we experimented with last year, both on-wiki and off-wiki. Finally, we intend to provide more granular information about the Foundation’s staffing, team structures, and specific budgets as an outcome of these planning efforts. 

On leadership, we have welcomed new Trustees to the Board following the last community-and-affiliate election. I also made a few senior staff appointments: Lisa Gruwell was named Deputy to the CEO alongside her responsibilities as Chief Advancement Officer; Anusha Alikhan became the head of communications at the Wikimedia Foundation; Nadee Gunasena was appointed Chief of Staff; and as of this week, Stephen LaPorte formally begins as the next General Counsel. 

I believe that values and culture will matter the most for any real reset to occur in how the Wikimedia Foundation relates to communities, and vice-versa. This is especially true when trust has to be built and maintained; and when any kind of change has to be catalyzed and sustained. The Board and Foundation tried to model this in how we heard and responded to the request for changes in fundraising banners. And we will continue to spend more time reflecting on what the world and our global communities need from us now. 

I think we are heading more in the right direction and continue to welcome your feedback either on my talk page or at miskanderwikimedia.org. 

Maryana 

Maryana Iskander
Wikimedia Foundation CEO

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.

As the movement charter relates to and impacts all Wikimedia communities, groups, and individuals, all these parties are considered partners in composing the required movement charter. The MCDC’s responsibility is to draft the content and the communities hold the responsibility of reviewing it and suggesting improvements. This is a collaborative process that requires some effort and time to do it. Because we believe in this mission, we were happy to join the Ambassadors for Movement Charter Draft Committee to build a bridge between MCDC and the Arabic-speaking communities.

The ambassadors’ team that supported the Arabic community consisted of three volunteers: Ali from Iraq, Sandra from Syria, and Donia from Egypt. Let’s first introduce ourselves:

Ali: I’m a member of the Iraqi Wikimedians user group and Wiki world Heritage user group. During 2022, I organized some Wikipedia workshops in different cities in Iraq which targeted diverse groups of people around the country.

Ending 2022 as an ambassador for the MCDC was a great choice to reconnect with all groups and individuals I worked with during the year and introduce them to the movement charter, where I reached out not only to Arabs but also to Kurds whom I got to know through the workshops.

Working with a team is always a great opportunity to gain experience where I could share, discuss and implement ideas to reach out to as many people as we can in the middle east and deliver their thoughts to the MCDC.

I know we are making it harder for the MCDC to deal with all feedback we received and collected, and it’s just the first consultation cycle, but we believe that through these efforts, we can ensure that the Movement Charter truly reflects the needs and aspirations of the global Wikimedia community.

Sandra: I am Syrian, the projects coordinator of Wikimedians of the Levant user group since June 2022, a regional coordinator for WikiForHumanRights 2023, and a member of Wiki World Heritage User Group. 

I am also an active editor and reviewer on Arabic Wikipedia since August 2019. Being a volunteer at Wikipedia added a lot to me and helped me to improve connections with people all over the world. I also edit Wikidata and Wikisource and add multimedia to Wikimedia commons.

While volunteering in Wikimedia projects, I have organized (alone or with teams) many workshops, editing, and photo competitions.

Donia: Member of Leadership development working program, Editor at Arabic Wikipedia since 2019, Founder of Wikipedian Editor Project, Organiser of many wide-scale edit-a-thons and local photo competitions, Member of Egyptian Wikimedia User group and Arabic Wikimedia User Group, and been an invited member at the Levant User Group. 

All these diversities allowed us to have a wide-scale connection inside and outside the Arabic community. 

The Ambassadors program allowed us to engage as Arabic volunteers with the organizing team in the Wikimedia foundation and gave us the formal name to communicate with the Arabic community and increase engagement in the MCDC process.  

It was not easy, we made multi reunions to set the plan. The best way we followed to connect with the community was to conduct meetings for different Arabic-speaking countries, then we found that we need to hear every voice in our community, believing in “equity” in decision-making for all. According to this, we turned into one-to-one meetings, where we met people from the community, and spent hours in meetings to get their feedback and vision about the initial charter drafts.

For people who did not have time for online meetings, we sent them the online survey to document their feedback.

At the same time, along with conducting meetings, we worked on translating all documents and pages related to the charter and MCDC on Meta to Arabic to make them available for Arabic readers, so that they can read, discuss and provide their feedback with more confidence.

It was a great experience for us to have discussions with many people in the community and document their feedback, and we hope it was a great experience for the community as well. 

The next time we become ambassadors, we hope that we will have more time to collect feedback so that we can reach more and more people. 

Other languages: Bahasa Indonesia, 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.

Problems

• Last week, for ~15 minutes, some users were unable to log in or edit pages. This was caused by a problem with session storage. [1]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 31 January. It will be on non-Wikipedia wikis and some Wikipedias from 1 February. It will be on all wikis from 2 February (calendar).

Future changes

• Wikis that use localized numbering schemes for references need to add new CSS. This will help to show citation numbers the same way in all reading and editing modes. If your wiki would prefer to do it yourselves, please see the details and example CSS to copy from, and also add your wiki to the list. Otherwise, the developers will directly help out starting the week of February 5.

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

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

For us at OFWA we kickstarted the year with our first in-person program by hosting the annual Train the Trainer workshop (TOT). In our pursuit to extend our reach beyond just the capital of Ghana, we work hand in hand with community volunteers by creating wiki hubs in their respective regions and empowering them to facilitate open activities there. 

Each year, we host a two-day workshop aimed at equipping hub and club leads with the knowledge and skills required to improve their effectiveness in their respective roles. The main objective for the workshop is to equip hub leaders with basic knowledge on how to manage their hubs as well as how to effectively deliver training to their members.

Also, the workshop was designed to be a platform for new hub leaders to draw inspiration and learn from the experienced ones through their shared stories, ordeals, and knowledge in their journey as hub leads.

The session entailed courses on Wikipedia,  Wikidata tools and games, Wikimedia Commons, Hub Management, Movement Strategy and other courses. This gave new hub leads the opportunity to be introduced to learn new skills and tools that could enhance their impact in their respective communities. 

We acknowledge our team at OFWA,  Eugene Makafui Masiku, Ruby D- Brown and Gameli Kofi-Bediako for the excellent training sessions  and moderation of the workshop. We also acknowledge and are super grateful to DnShitobu for delivering a superb training on Wikidata and Max Beganim for also leading a great  session on Kiwix.

The trainees were drawn from some of our hubs in Ghana namely Walewale, Tamale, Bono East, Kumasi, Ho, UHAS club and Accra Wiki Hub. 

On the last day of the workshop, trainees were treated to a short tour of the historical Black Star Square in the capital of the city.  Trainers from outside Accra were amazed to learn about the history of the square for the first time. 

Follow us on all our social media platforms for all the activities our vibrant hub leads have planned out for the year!

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.

It has been an extraordinary journey for the Igbo Proverbs, Idioms, and Phrases podcast in the past year. Despite only releasing five episodes, the show has made a significant impact, ranking in the top 50% of all Buzzsprout podcasts with a staggering 694 downloads across 37 countries. The podcast has particularly resonated with audiences in Nigeria, the United States, the United Kingdom, India, and Canada, with these countries leading the way in terms of downloads. This is a testament to the power of the show’s content and the impact it has had on listeners everywhere.

I would like to express my deepest gratitude to the Wikimedia Foundation and the Igbo Wikimedians User Group for their support in the birth and release of the Igbo Proverbs, Idioms, and Phrases podcast. The preservation and promotion of the Igbo language and culture is a task that is near and dear to my hearts, and I am profoundly grateful for the support.

The Igbo Proverbs, Idioms, and Phrases podcast aims to help preserve the language and culture by providing a platform for sharing proverbs, idioms, and phrases in the Igbo language. The podcast is designed to be quick and easy to listen to, with each episode featuring one proverb, idiom, or phrase, along with its literal meaning, figurative explanation, and the most applicable English language equivalent.

You can see the 2022 recap when you click here and enjoy the podcast anywhere you listen to podcasts when you visit www.igbopip.com today.

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.

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

Tim Berners-Lee, W3C Director and inventor of the World Wide Web

Last week the Wikimedia Foundation Web team deployed a new desktop experience to English Wikipedia under the Desktop Improvements project, introducing the largest change to Wikipedia in over a decade. In addition to a refreshed design and a variety of new features, this experience also represents a large shift in Wikipedia’s accessibility. Web accessibility means that web resources are designed and developed so that they are usable to all people regardless of ability. This inclusive practice is essential to the Wikimedia Foundation’s mission to provide free and equitable access to information. 

In this post we’ll explore how the Web team tackled accessibility challenges and share opportunities for us to better address the needs of disabled people and other historically marginalized groups.

Modernized experience, more accessibility challenges

In many ways, the new experience pushed the boundaries of Wikipedia’s former design and codebase. It focused on making the site more welcoming and usable for new readers and editors by adding interactivity and rich experiences to a site that was a relic of an older, simpler internet. While we have ample research and testing showing that these changes improve usability, they also presented many new accessibility challenges, especially for keyboard and assistive tech users.

Custom widgets

Features like the improved search and language switcher introduced more complex JavaScript-based widgets, which need to include appropriate semantics and keyboard/mouse interactions.

For example, the new search features an ARIA enriched component that is text zoomable by user preference. In contrast neither assistive technology exposure nor text scalability were available in the old interface.

Menu restructure

As part of our effort to help new users better understand the details of Wikipedia, its navigation, and editing tools, the new interface updates many of the menus and navigation links. Related links were grouped together, and certain links were moved to declutter the interface and provide focus for the most important actions. This restructure also impacts how screenreader users discover and navigate links on the site, so we had to consider how to best update accessible labels, the heading structure, and navigation methods like landmark regions along with these changes. 

Dynamic, customizable interface

Users now have the ability to customize their experience by pinning and unpinning important menus into the sidebars next to article content. In order to support this customization, we had to consider how focus management and the HTML source order will be impacted when elements are pinned and unpinned.

Inclusive product development

Going into the redesign, our team aimed to maintain and improve the existing standards for accessibility. To accomplish this, the Web team worked to embed accessibility into our product development process.

Inclusive values and processes

The Web team was an early adopter of the Inclusive Product Development Playbook, a new framework aiming to build inclusive practices into product development across the Wikimedia Foundation. The playbook helped us implement new processes for staying accountable to accessibility, including checks throughout the different stages of product development and improved testing methods. For example during the initial design stage of each feature, our designer created working HTML prototypes for testing and feedback. For the table of contents feature, this prototype was even expanded to a browser extension, which allowed testers to try out new features as they browsed Wikipedia naturally. These prototypes were useful for design iteration in general, but were also a helpful tool for surfacing early accessibility considerations – i.e. starting discussions around the expected behavior for keyboard interactions.

We were also able to leverage help from users and volunteers who generously contributed accessibility-related feedback and bugs on the wikis and in our public issue tracking board. Community feedback throughout the project helped us prioritize accessibility bugs and enhancements.

Accessibility-first development

During development, the engineers were proactive about implementing new features with accessibility in mind from the beginning. One example of this was when the team reordered the DOM to ensure a logical source order near the beginning of the project. This effort involved extensive research and discussion, as it was a large change to the underlying HTML structure of Wikipedia and would have large implications on new features, existing extensions and gadgets, and of course accessibility.

We also utilized Foundation-wide accessibility and design standards with features like the improved search, which was implemented with the new Codex design system. Codex is a design and component library that has accessibility features built in, and it plays an increasingly important role at the Foundation for scaling accessibility. The Web team plans to further integrate Codex into our work in the near future.

Accessibility testing

The Web team relied on a variety of tools and testing methods to catch accessibility issues, including automated tests and manual testing by engineers and quality assurance testers. Our automated tests run daily accessibility reports and report data to a dashboard to track errors over time, helping the team measure impact from our efforts and making it easier to spot new errors at a glance.

The Web team also conducted two rounds of accessibility testing with experts from the American Foundation for the Blind in September 2022 and October 2022. These tests evaluated the new interface across several screen reader and browser combinations against WCAG (Web Content Accessibility Guidelines) 2.1 Level AA Conformance. Overall, the results were positive, and we saw noticeable improvements comparing the original experience with the new. Any unresolved issues that were discovered from testing have been prioritized, and we are working diligently to resolve them this month.

Future opportunities

Accessibility is a living, iterative process that requires ongoing effort; it isn’t a checklist or set of compliance that can be “done”. Similarly, the accessibility of the Wikipedia experience and our team’s approach to inclusive product development needs to continue to evolve, too.

Even after the launch, there are still many opportunities for improvement that are being addressed.

1. Continued education for building accessibility awareness and expertise within the team and the Wikimedia Foundation.
2. Need for better authoring practices and tools so that editors are empowered to create accessible wiki content. The accessibility changes discussed in this post are limited to the user interface around the content, as most of the page content is user generated.
3. Address accessibility technical debt, particularly with features that were built in the past or have cross-team dependencies that make prioritizing that work more difficult.
4. Continued research with under-served groups to better understand the impact of our ongoing changes, especially with assistive tech users and other groups like users with ASD/ADHD.

While we still have a long way to grow, we are proud of our progress so far. We were able to prioritize and iterate on accessibility throughout the project and contributed to a longer process of building up accessibility expertise and best practices. If you would like to help, we welcome and appreciate your feedback on the Desktop Improvements project page or on the Web team’s issue tracker. Thank you for following our journey!

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.

We released Semantic MediaWiki 4.1. Learn what changes it brings.

As maintainers of Semantic MediaWiki (SMW), we are responsible for releasing new versions. Today we released version 4.1, the 65th release of SMW. This release follows SMW 4.0.2, which was released on July 21st 2022.

Semantic MediaWiki 4.1 is a minor release. It contains new features, improvements, and bug fixes. Because it is a minor release, it does not contain any breaking changes, does not require running the update.php script, and does not drop support for older versions of MediaWiki.

Credits

Over 20 people contributed to this release. We would like to thank all contributors.

Special credits go to Abijeet Patro (and TranslateWiki), Bernhard Krabina from KM-A, Sébastien Beyou from WikiValley and Alexander from gesinn.it.

tl;dr: [[WP:IDONTLIKEIT]]

Yesterday, a new version of the Vector skin was made default on English Wikipedia.

As will shock absolutely no one who pays attention to Wikipedia politics, the new skin is controversial. Personally I'm a Timeless fan and generally have not liked what I have seen of new vector when it was in development. However, now that it is live I thought I'd give it another chance and share my thoughts on the new skin. For reference I am doing this on my desktop computer which has a large wide-screen monitor. It looks very different on a phone (I actually like it a lot better on the phone). It might even look different on different monitors with different gamuts.

So the first thing that jumps out is there is excessive whitespace on either side of the page. There is also a lot more hidden by default, notably the "sidebar" which is a prominent feature on most skins. One minor thing that jumps out to me is that echo notifications look a little wonky when you have more than 100 of them.

On the positive though, the top bar does look very clean. The table of contents is on the left hand side and sticky (Somewhat similar to WikiWand), which I think is a nice change.

When you scroll, you notice the top bar scrolls with it but changes:

On one hand, this is quite cool. However on reflection I'm not sure if I feel this is quite worth it. It feels like this sticky header is 95% of the way to working but just not quite there. The alignment with the white padding on the right (I don't mean the off-white margin area but the area that comes before that) seems slightly not meeting somehow. Perhaps i am explaining it poorly, but it feels like there should be a division there since the article ends around the pencil icon. Additionally, the sudden change makes it feel like you are in a different context, but it is all the same tools with different icons. On the whole, I think there is a good idea here with the sticky header, but maybe could use a few more iterations.

If you expand the Sidebar menu, the result feels very ugly and out of place to me:

idk, I really hate the look of it, and the four levels of different off-whites. More to the point, one of the key features of Wikipedia is it is edited by users. To get new users you have to hook people into editing. I worry hiding things like "learn to edit" will just make it so people never learn that they can edit. I understand there is a counter-point here, where overwhelming users with links makes users ignore all of them and prevents focus on the important things. I even agree somewhat that there are probably too many links in Monobook/traditional vector. However having all the links hidden doesn't seem right either.

On the fixed width

One of the common complaints is that the fixed width design wastes lots of screen real estate. The counter argument is studies suggest that shorter line lengths improve readability.

As a compromise there is a button in the bottom right corner to make it use the full screen. It is very tiny. I couldn't find it even knowing that it is supposed to be somewhere. Someone had to tell me that it is in the lower-right corner. So it definitely lacks discoverability.

Initially, I thought I hated the fixed-width design too. However after trying it out, I realized that it is not the fixed width that I hate. What I really hate is:

• The use of an off-white background colour that is extremely close to the main background colour
• Centering the design in the screen

 I really really don't like the colour scheme chosen. Having it be almost but not quite the same colour white really bothers my eyes.

I experimented with using a darker colour for more contrast and found that I like the skin much much better. Tastes vary of course, so perhaps it is just me. Picking a dark blue colour at random and moving the main content to the left looks something like:

 Although I like the contrast of the dark background, my main issue is that in the original the colours are almost identical, so even just making it a slightly more off-white off-white would be fine. If you want to do a throwback to monobook, something like this looks fine to me as well:

I don't really know if this is just my particular tastes or if other people agree with me. However, making it more left aligned and increasing the contrast to the background makes the skin go from something I can't stand to something I can see as usable.

This past weekend at Wikipedia Day I had a discussion with Enterprisey and some other folks about different ways edit counters (more on that in a different blog post) could visualize edits, and one of the things that came up was GitHub's scorecard and streaks. Then I saw a post from Jan Ainali with a SQL query showing the people who had made an edit for every single day of 2022 to Wikidata. That got me thinking, why stop at 1 year? Why not try to find out the longest active editing streak on Wikipedia?

Slight sidebar, I find streaks fascinating. They require a level of commitment, dedication, and a good amount of luck! And unlike sports where if you set a record, it sticks, wikis are constantly changing. If you make an edit, and months or years later the article gets deleted, your streak is retroactively broken. Streaks have become a part of wiki culture, with initatives like 100wikidays, where people commit to creating a new article every day, for 100 days. There's a new initiative called 365 climate edits, I'm sure you can figure out the concept. Streaks can become unhealthy, so this all should be taken in good fun.

So... I adopted Jan's query to find users who had made one edit per day in the past 365 days, and then for each user, go backwards day-by-day to see when they missed an edit. The results are...unbelievable.

Johnny Au has made at least one edit every day since November 11, 2007! That's 15 years, 2 months, 9 days and counting. Au was profiled in the Toronto Star in 2015 for his work on the Toronto Blue Jays' page:

Au, 25, has the rare distinction of being the top editor for the Jays’ Wikipedia page. Though anyone can edit Wikipedia, few choose to do it as often, or regularly, as Au.

The edits are logged on the website but hidden from most readers. Au said he doesn’t want or need attention for his work.

“I prefer to be anonymous, doing things under the radar,” he said.

Au spends an average 10 to 14 hours a week ensuring the Blues Jays and other Toronto-focused Wikipedia entries are up to date and error-free. He’s made 492 edits to the Blue Jays page since he started in 2007, putting him squarely in the number one spot for most edits, and far beyond the second-placed editor, who has made 230 edits.

...

Au usually leaves big edits to other editors. Instead, he usually focuses on small things, like spelling and style errors.

“I’m more of a gatekeeper, doing the maintenance stuff,” he said.

Next, Bruce1ee (unrelated to Bruce Lee) has made at least one edit every day since September 6, 2011. That's 11 years, 4 months, 14 days and counting. Appropriately featured on their user page is a userbox that says: "This user doesn't sleep much".

It is mind blowing to me the level of consistency you need to edit Wikipedia every day, for this long. There are so many things that could happen to stop you from editing Wikipedia (internet goes out, you go on vacation, etc.) and they manage to continue editing regardless.

I also ran a variation of the query that only considered edits to articles. The winner there is AnomieBOT, a set of automated processes written and operated by Anomie. AnomieBOT last took a break from articles on August 6, 2016, and hasn't missed a day since.

You can see the full list of results on-wiki as part of the database reports project: Longest active user editing streaks and Longest active user article editing streaks. These will update weekly.

Hopefully by now you're wondering what your longest streak is. To go along with this project, I've created a new tool: Wiki streaks. Enter in a username and wiki and see all of your streaks (minimum 5 days), including your longest and current ones. It pulls all of the days you've edited, live, and then segments them into streaks. The source code (in Rust of course) is on Wikimedia GitLab, contributions welcome, especially to improve the visualization HTML/CSS/etc.

I think there is a lot of interesting stats out there if we kept looking at streaks of Wikipedians. Maybe Wikipedians who've made an edit every week? Every month? It certainly seems reasonable that there are people out there who've made an edit at least once a month since Wikipedia started.

Of course, edits are just one way to measure contribution to Wikipedia. Logged actions (patrolling, deleting, blocking, etc.) are another, or going through specific processes, like getting articles promoted to "Good article" and "Featured article" status. For projects like Commons, we coud look at file uploads instead of edits. And then what about historical streaks? I hope this inspires others to think of and look up other types of wiki streaks :-)

When women are exposed to women role models in science, they are more likely to pursue STEM careers and feel a greater sense of belonging in them–a key indicator for career longevity. Reading just one story of a woman in a successful career makes a difference for the confidence and performance of undergraduates in the same field. From this exposure, men too can understand that women thrive with careers in science just as much as men. So imagine 100,000 people reading that same story. What could that do for inequity in STEM at large? You may ask, how could anyone (beyond the rare celebrity scientist) reasonably get that much exposure? Ah, well we have a tale for you.

On November 21, 2022, Google’s Doodle of the day featured Marie Tharp, whose discovery led to the acceptance of continental drift theory. Tharp’s impressive career as an oceanographic cartographer was on full display that day as more than a hundred thousand internet users swarmed to her Wikipedia biography. Thankfully, the biography was robust—touting her contributions to her field and the barriers she overcame as a woman geologist in the ’40s and ’50s. Not all women on Wikipedia are as lucky. Only 19% of the biographies on the site are even about women. When they do have a page, bias mirroring gender inequities in STEM and journalism can creep up in the content. Today, Marie Tharp’s biography is comprehensive and an excellent summary of her contributions to science. But just 6 years ago, it told a very different story.

If you read Tharp’s Wikipedia article in 2017, it might escape you that the Library of Congress considers her one of the four greatest cartographers of the 20th century. The page focused more on the work of her colleague Bruce Heezen than it did on her, painting him as the more experienced scientist, rather than her collaborator. At the time, women weren’t allowed on board research vessels, so Tharp relied on Heezen’s sonar data to create her maps of the seafloor. This earlier version of Tharp’s biography contextualized her discovery of an oceanic rift valley in terms of what Heezen thought about it. He was skeptical, calling her theory “girl talk” and even going so far as to erase her work. Once he was convinced she was right, Heezen took credit for Tharp’s discovery for more than 10 years until her contribution was finally acknowledged. The 2017 version of Tharp’s Wikipedia biography hinted at the injustice, noting that her name was mysteriously missing from publications, but it didn’t explain why. A reader might assume Heezen simply did more of the work.

It was a group effort through Wiki Education’s programs, spanning years, that corrected the narrative.

First, in 2017 an undergraduate student completing a Wikipedia assignment in a Wiki Education-supported course added the barriers that Tharp overcame in pursuing geology, namely that only 4% of all earth sciences doctorates at the time were obtained by women. The student also noted the Library of Congress’ honoring of Tharp’s legacy.

Then, in 2018 a geoscience graduate student trained as a Wiki Scientist came along and detailed how Tharp’s discovery of a rift valley supported the theory of continental drift, which was new and controversial at the time. By adding this point, the Wiki Scientist focused the biography more on Tharp’s findings than on Heezen’s skepticism. They also added the reason Heezen finally came around—a male colleague confirmed Tharp’s work. Perhaps most poignantly, the Wiki Scientist replaced the page’s photograph with one of Tharp herself, rather than one of Heezen “showing” her a map of her own creation.

In 2019, another undergraduate student in a Wiki Education-supported geology course gave more context about Tharp’s map of the ocean floor in the introductory section, adding that it specifically charted the ocean’s topography and multi-dimensional geographical landscape. The student found a preliminary manuscript sketch that Tharp and Heezen made and included that too. The student added an award that Tharp received in 2001 and also updated the section about Tharp’s early life, noting that joining her father in his field work as a soil surveyor sparked her initial interest in cartography. Considering that narratives about women scientists (on Wikipedia and off) are more likely than a man’s to focus on their personal life over their career accomplishments, including the origin of Tharp’s passion for science is a great addition to the information about her upbringing.

Where before, the biography passively mentioned that Tharp’s name wasn’t included in publications of her work, this student made the language more active, noting that it was Heezen who took the credit for Tharp’s discovery in 1956 and that the discovery was not attributed to her for more than a decade. There are plenty of historical instances where discoveries made by women were credited to men at first: from the existence of dark matter to the invention of wireless communication and the first computer language compiler tools. Women scientists are still less likely to be credited for their work than men. Given the persistent barriers women face to being recognized, it’s important to accurately document the contributions from women scientists and Wikipedia is a great place to tell the real story in real time.

When we don’t tell the full story of women scientists’ achievements, we miss the opportunity to positively influence future generations of scientists. Instead, young people may be exposed to pervasive negative stereotypes suggesting that they don’t belong in STEM, which change the way they talk about their dreams and negatively affect confidence and test performance. Sustained over time, this undermining of confidence can lead to women abandoning careers that don’t align with expectations of their gender, race, or class.

We have the chance to change the story–not only for pioneers like Tharp, but for scientists working now. A Wikipedia biography recognizes a scientist’s contributions in real time. It surfaces her expertise to journalists and panel organizers, humanizes her beyond her CV or university profile, and shows young people interested in STEM what career paths are possible for them. Considering women and people of color are chosen less often for speaking opportunities, are contacted less often by journalists, and aren’t recognized for their work in equal measure to white male peers, exposure on Wikipedia can help turn the tides.

We’re proud to see that the work of students and scientists in our programs lives on, and this process worked exactly as Wikipedia was designed to: building upon itself over time as contributors uncovered more of the real story. Together, we’re helping correct the narrative of women’s place in the advancement of STEM, and there’s one thing we know for sure: a woman’s place is in Wikipedia.