A giant wall of text follows, giving a snapshot of work I do. I nurture the software community that supports the Wikimedia movement. So here's a big swath of stuff I did between February 1st and today.

Wrote and posted a blog entry about the San Francisco hackathon. Still need to do more followup with participants.

Handed over the MediaWiki 1.19 deployment communications plan to Guillaume Paumier, WMF Technical Communications Manager. He blogged a summary of the deployment and of our efforts and that's just the tip of the iceberg; he also set up a global message delivery and improved the CentralNotice maintenance message and did even more to make sure that we thoroughly communicate about the upcoming deployment to all the Wikimedia communities. I also shared information with various folks regarding testing of site-specific gadgets on 1.19.

I sent at least 285 work-related emails. That's 41 per workday but I definitely sent some work-related email on weekends.

Some patch queue work, responding to contributors and getting experienced developers to review the patches. I'm just trying to keep our queue from growing while code reviewers are mostly focused on getting MediaWiki 1.19 reviewed, polished, and deployed. But I do want to take care of all parts of the volunteer pipeline -- initial outreach and recruiting, training, code improvement, commit access, continued interest and participation, and debriefing when they leave -- so the patch review queue is a continuing worry.

Some work preparing for the Pune hackathon and for GLAMCamp DC, neither of which I am attending. I wrote or edited some tutorials and made a tutorial category which pleases me. We have more good material for workshops and stuff now, yay! And I helped the GLAMCamp people a bit in talking through what technical goals they wanted to achieve during the weekend.

Got dates from Wikimedia Germany for the Berlin hackathon, 1-3 June, and started trumpeting it. Also worked on planning for it and did outreach. For example, I reached out to about 13 chapters that are pursuing or interested in some kind of technology work like, say, funding or working on the offline Wikipedia reader (Wikimedia Switzerland), or usability and accessibility for Wikisource (Wikimedia Italy), or the Toolserver, a shared hosting service for tools and stuff that hackers use to improve or make use of the Wikimedia sites (for example, Wikimedia Germany & Wikimedia Hungary). We hope they can convene, share insights and collaborate at the WMDE hackfest.

Told at least 30 contributors to apply for Wikimania scholarships because the deadline is 16 February.

Talked to some Wikimedia India folks about planning technical events, and contributed to a page of resources for upcoming events.

Worked on some event planning & decisions for a potential event.

Passed the word to some friends, acquaintances, and email lists about some job openings at the Foundation.

Google Summer of Code has been announced, and I am managing MediaWiki's participation. I have started -- flyers, emails, recruiting potential students, improving the wiki page, asking experts whether they might mentor, and so on. I'm trying to start a thing where every major women's college in North America gets a GSoC presentation by March 15th, to improve the number of GSoC applications that come from women; let's see how that goes. MediaWiki still needs to apply to participate as a mentoring organization and acceptances only go out after that, but I'm comfortable spending time preparing anyway. And the women's college outreach will lead to an increase in the number of applications for all the participating open source projects, instead of just aiming a firehose at MediaWiki; that's fine. Like Tim O'Reilly says, aim to create more value than you capture.

Related to that -- I set up a talk for one of our engineers to give at Mills, a women's college that has an interesting interdisciplinary computer science program (both grad and undergrad, the grad program being mixed-sex) and I think it may end up being a really amazing talk. Ian Baker is going to talk about how CS helps us work in Wikimedia engineering, how we collaborate with the community during the design, development, and testing phases, and what skills and experiences come in handy in his job. I'll publicize more once there's an official webpage to point to.

Had a videoconference with a developer and my boss about our conversion to Git. I prepped for it by collecting some questions and getting preliminary answers, and then after the call we ended up with all this raw material and I sent a fairly long summary to the developers' mailing list. There's a lot left to do, and the team needs to work on some open issues, but we have a lot more detail on those TODOs now, so that's good.

Saw a nice email from Erik Möller publicizing the San Francisco hackathon videos and tutorials/documentation, yay!

Talked with a few people about submitting talks to upcoming conferences. I ought to write some preliminary Grace Hopper, Open Source Bridge, and Wikimania proposals this week.

Various volunteer encouragement stuff (pointing to resources, helping with installation or development problems, troubleshooting, teaching, putting confused people in touch with relevant experts, etc.), especially talking in IRC to eager students who want to do GSoC. Many of them are from India. I wonder how many of them see my name and think I'm in India too.

Commit access queue as usual.

Saw privacy policy stuff mentioned on an agenda for an IRC meeting on the 18th, so I talked to a WMF lawyer a little bit about privacy policy stuff for our new Labs infrastructure. We set up a meeting for this week to iron stuff out.

Helped with the monthly report. I have a colleague who wants to learn more about All This Engineering Stuff, so every month we have a call where I explain and teach the context of the report, and for this month's call I suggested we add another colleague who also wants to learn how the tech side works. Who knows, maybe this will turn into a tradition!

Followed up on the GSoC 2011 students who never quite got their projects set up and deployed on Wikimedia servers, and looks like two of them have some time and want to finish it now, yay! Updated the Past Projects page.

Checked in on the UCOSP students who are working on a mobile app for Wiktionary and told them about Wikimania, new mobile research, etc. Also got some feedback from their mentor, Amgine, on how they're doing.

Started an onwiki thread to discuss the MobileFrontend rewrite question(s).

Talked to Oren Bochman, the volunteer who's working on our Lucene search stuff, and followed up on a bunch of his questions/interests.

Ran & attended meetings.

Suggested to the new Wikimedia Kenya chapter that maybe we could collaborate, since they're interested in helping schools get Wikipedia access via offline reading.

Looked into the code review situation by getting a list of committers with their associated numbers of commits, reviews, and statuschanges. It's just a first pass, but it's a start for discovering who's been committing way more than they review, so we can start efforts to mentor them into more code reviewing confidence. I also saw who's been reviewing way more than they commit, and saw a name I wasn't familiar with -- looks like I've now successfully recruited him to come to the Berlin hackathon. :-)

Put two groups of people in touch with each other: did a group-intro mail to people at various institutions working on Wikimedia accessibility, and another to people who want to work on a redesign of mediawiki.org's front page.

And there was other miscellaneous stuff, but this is already sooooo TL;DR (too long; didn't read). (Which is funny because that's the name of my team.) Monday awaits!

The Cloud Services team is in the process of updating and standardizing the use of DNS names throughout Cloud VPS projects and infrastructure, including the Toolforge project. A lot of this has to do with reducing our reliance on the badly-overloaded term 'Labs' in favor of the 'Cloud' naming scheme. The whole story can be found on this Wikitech proposal page. These changes will be trickling out over the coming weeks or months, but one change you might notice already.

New private domain for VPS instances

For several years virtual machines have been created with two internal DNS entries: <hostname>.eqiad.wmflabs and <hostname>.<project>.eqiad.wmflabs. As of today, hosts can also be found in a third place: <hostname>.<project>.eqiad1.wikimedia.cloud. There's no current timeline to phase out the old names, but the new names are now the preferred/official internal names. Reverse DNS lookups on a instance's IP address will return the new name, and many other internal cloud services (for example Puppet) will start using the new names for newly-created VMs.

Eventually the non-standard .wmflabs top level domain will be phased out, so you should start retraining your fingers and updating your .ssh/config today.

Today, we are writing to share the discovery and squashing of a bug that occurred earlier this year. This particular bug was also one of the rare instances in which we kept a Phabricator ticket private to address a security issue. To help address questions about when and why we make a security-related ticket private, we’re also sharing some insight into what happens when a private ticket about a security issue is closed.

Late last year, User:Suffusion of Yellow spotted a bug that could have allowed an association to be made between logged-in and non-logged-in edits made from the same IP address. Users with dynamic IP addresses could have been affected, even if they personally never made any non-logged-in edits.

Suffusion of Yellow created a Phabricator ticket about it, and immediately worked to get eyes on the issue. The bug was repaired with their help. We’re grateful for their sharp eyes and their diligent work to diagnose and fix the problem. As part of our normal procedure, the Security team investigated once the bug was resolved. They found no evidence of exploit. We are not able to reveal further technical details about the bug, and here is why:

When a Phabricator ticket discussing a security bug is closed, Legal and Security teams at the Wikimedia Foundation evaluate whether or not to make the ticket public. Our default is for all security tickets to become public after they are closed, so that members of the communities can see what issues have been identified and fixed. The majority of tickets end up public. But once in a while, we need to keep a ticket private.

We have a formal policy we use to determine whether a ticket can be publicly viewable, and it calls for consideration of the following factors:

• Does the ticket contain non-public personal data? For example, in the case of an attempt to compromise an account, the ticket may include IP addresses normally associated with the account, to identify login attempts by an attacker.
• Does the ticket contain technical information that could be exploited by an attacker? For example, in discussing a bug that was ultimately resolved, a ticket may include information about other potential bugs or vulnerabilities.
• Does the ticket contain legally sensitive information? For example, a ticket may contain confidential legal advice from Foundation lawyers, or information that could harm the Foundation’s legal strategy.

In this case, we evaluated the ticket and decided that it could not be made public based on the criteria listed above.

Even when we can’t make a ticket public, we can sometimes announce that a bug has been identified and resolved in another venue, such as this blog. In this case, Suffusion of Yellow encouraged us to make the ticket public, and while pandemic-related staff changes have caused a delay, that request reminded us to follow through with this post. We appreciate their diligence. Keeping the projects secure is a true partnership between the communities of users and Foundation technical staff, and we are committed to keeping users informed as much as possible.

Respectfully,

David Sharpe
Senior Information Security Analyst
Wikimedia Foundation

Emma Chow will graduate from Brown in 2021 with a Bachelor of Arts in American Studies. Last academic year, she was assigned to edit Wikipedia as a class assignment, supported by Wiki Education’s Student Program. She reflected on the experience on Brown’s website; her post is re-published here with permission.

For as long as I can remember, I have been told to not use Wikipedia.

I distinctly recall my first lesson about searching the web. In first grade, the school’s librarian taught us about reliable sources.  She projected the website page, “Pacific Northwest Tree Octopus” in front of the entire class. After spending time on our own researching the tree octopus, we reassembled as a group and the librarian asked, “Is the Pacific Northwest tree octopus real?” My tiny hand shot up with the rest of my peers in total belief of its existence. To my dismay, this would be the day that I learned that not everything you read online is true… It turned out that I was not the only one fooled by the tree octopus: Wikipedia currently has an article about the internet hoax that is the Pacific Northwest Tree Octopus. That class concluded, not surprisingly, with the warning to be very wary. The teacher said that anyone can contribute to online databases, including those “not qualified to do so.” The message was clear: the general public is not considered a reliable academic source, or so I thought until I wrote my own Wikipedia entry.

Moving forward fourteen years, I am now in my third year at Brown and enrolled last fall in an American Studies course entitled “American Publics.” The class, taught by Professor Susan Smulyan, examined the public sphere’s historical, cultural, and political dimensions, as well as the challenges of public life in America, all while also discussing the place of Public Humanities within the University. One of the main ​assignments for the course involved writing a Wikipedia page on a local Rhode Island subject. I chose to write on  Mashapaug Pond, the largest freshwater pond in the city of Providence.

Our class worked in partnership with the Rhode Island Council for the Humanities (RICH) and their Arts and Culture Research Fellow, Janaya Kizzie, on a project aimed at contributing Wikipedia pages about Rhode Island’s artistic and cultural leaders, and geo-cultural and historical sites. You can read about the RICH’s goals here and here. This project has an impressive range of goals: to enhance Rhode Island’s reputation as a creative destination, to forge a vital bridge between the past and present, connect arts and cultural communities, represent diverse backgrounds, and catalyze education focused on arts and culture – with all of this to be achieved though the medium of Wikipedia. My article on Mashapaug Pond, written with my classmate Grace DeLorme, is one of the 250 new articles that Janaya Kizzie is curating.

Despite my childhood teacher’s warnings, I use Wikipedia constantly. That said, I have never cited it in any of my academic essays out of concern about its questionable reliability and stature in the scholarly world. Yet we know Wikipedia is an obligatory first stop for many as they begin online research. It makes the complex simple; easily accessible, its language and tone facilitate direct, approachable use. Scholarly articles, in contrast, can seem incomprehensible, with their density of language and reliance, for many, on what are unfamiliar terminologies. Yet, and to my surprise, I had difficulty writing at the level of a 5th grade reader, the requirement for authoring a Wikipedia entry.

Throughout my education, I have always been taught to “pick a side” and make an argument when writing a paper. So, when I sat down to write a Wikipedia page on a local pond, I was lost. Every time I read something controversial about the pond, whether it was the mass genocide of the Native Americans, the forced eviction of the West Elmwood community, or the toxic legacy of the Gorham Silver plant, I found myself spiraling into an argumentative mindset. It was challenging to write for the “public:” I had to force myself to exclude the complex discourse that I would have normally have used in my academic writing. By adding to and completing the Mashapaug Pond Wikipedia page, I learned to be clearer, more concise, and thus accessible in my writing.  As a final source of challenge, my classmates and I sometimes found it difficult to find the Wikipedia-required two primary sources for each entry!

Co-authoring this page connected me to the history and the community of Providence. When I decided to move from my hometown of Boulder, Colorado to go to school at Brown, I knew nothing about the city. Shockingly, after two years of living there, my experience of Providence and Rhode Island was grounded solely within the University, barely extending beyond College Hill. I was locked inside the “Brown Bubble,” and it wasn’t until I wrote this Wikipedia entry that I began to know something about the history and community of my new city.

I learned many local lessons, extending to the Narragansett tribe and their interactions with Roger Williams, to the manufacturing sector, exemplified by Gorham Silver, and the history of urban renewal. In addition, thinking about Mashpaug Pond brought me into contact with a local arts organization, first called the Urban Pond Procession and later UPPArts, and their campaign to raise awareness of the pond’s toxicity. It was incredible that I learned so much about an ever-changing community from one particular location.

I especially appreciated having contact with people around Providence as I talked to them about Mashapaug Pond. One unforgettable person I met was Holly Ewald, artist and founder of UPP Arts.  Beyond talking about the site, she shared with me the stories of the annual parade produced by the Mashapaug Pond community.  I also came to know another community member, Mariani Lefas-Tetens, the Assistant Director of School and Teacher Programs at the Rhode Island School of Design Museum. She discussed her work about the new Gorham Silver exhibit at the Museum and how she met with different community members to find out what they’d like the installation to express.  Researching and writing about a local pond thus enabled me to access a broad range of knowledge about the wider Providence community.

I would definitely describe writing and researching a Wikipedia page as a form of public engagement. This is based not only my own expanded understanding of Providence, but also my deeper thinking about Wikipedia as a public platform. It defines itself as a “multilingual digital encyclopedia generated and preserved as an open collaboration project by a community of volunteer editors.” Indeed, it is THE largest general reference work on the internet. I would go as far to say that Wikipedia is a “public sphere.” Jürgen Habermas, German sociologist and philosopher, gives this definition of such a concept, fittingly written for an encyclopedia:

By “public sphere” we mean first of all a domain of our social life in which such a thing as public opinion can be formed. Access to the public sphere is open in principle to all citizens. A portion of the public sphere is constituted in every conversation in which private persons come together to form a public… Citizens act as a public when they deal with matters of general interest without being subject to coercion; thus with the guarantee that they may assemble and unite freely, and express and publicize their opinions freely.[1]

Wikipedia is organized with ‘talk’ and ‘edit’ tabs that invite participant-editors to converse and share ideas. Even though this is easier said than done on particular pages (don’t even try to add or change anything on the Beyoncé page), in principle, Wikipedia is open to all. It is completely free. So as long as someone has access to the internet, they can fully participate with this resource. Also, because companies cannot write or hire someone else to write their own Wikipedia page, this eliminates coercion. And, as shown by my experience, it also opens the way for college students to contribute to their new communities. By writing about both local history and contemporary life, a place is given a visibility that makes more public opportunities possible.

Now let me ask you: would you write a Wikipedia page? Cite it in one of your academic papers? Assign it as a class project? Today I encourage you to take a leap of faith and join the digital public sphere that is Wikipedia.

Also feel free to check out my Wikipedia page here!

Other pages from our class can be found below:

RI Computer Museum https://en.wikipedia.org/wiki/Rhode_Island_Computer_Museum

Zeinab Kante and Kelvin Yang​

RI State Song https://en.wikipedia.org/wiki/Rhode_Island’s_It_for_Me and here as well, https://en.wikipedia.org/wiki/Music_of_Rhode_Island

Keiko Cooper-Hohn​

Rites and Reason Theatre https://en.wikipedia.org/wiki/Rites_and_Reason_Theatre

Khail Bryant and Mia Gratacos-Atterberry​

Providence Art Club https://en.m.wikipedia.org/wiki/Providence_Art_Club

Sophie Brown and Ava McEnroe​

RI Pride https://en.wikipedia.org/wiki/Rhode_Island_Pride

Evan Lincoln and Juniper Styles

Shey Rivera https://en.wikipedia.org/wiki/Shey_Rivera_R%C3%ADos

Sara Montoya and Santi Hernandez

Donna Freitas https://en.wikipedia.org/wiki/Donna_Freitas

Matthew Marciello

Photo: Wikimedia UK 2019 AGM , by John Lubbock. CC BY-SA 4.0.

We’re gearing up for this year’s Annual General Meeting with just over a week to go until the event! On Saturday 18th July we will be meeting virtually, and though we won’t see each other in person we’re hoping to make the day as interactive as possible.

We’ll be using Zoom, with a conference link sent to all Eventbrite sign ups, so claim your free ticket here. If you’re not sure how to use Zoom, you can watch instructions on this support page, or contact us with any queries. While the AGM is an opportunity for our members to vote on essential governance of the charity, we also encourage participation from volunteers, partners, supporters, and anyone else who’s interested in the Wikimedia community in the UK.

Agenda

11am Welcome and introduction, including technical onboarding

11.15am Keynote talk from Gavin Wilshaw, Mass Digitisation Manager at the National Library of Scotland, on the Wikisource project that the library has been delivering since the March shutdown

11.35am Q&A with Gavin, and contributions from other participants about their work on Wikimedia during and in response to the pandemic

12noon BREAK

12.15pm A global movement – short updates on Wikimedia 2030, the rebranding project, and the Universal Code of Conduct

12.30pm Lightning talks

1pm BREAK (+ social networking)

2pm Start of the formal AGM: reports, questions and announcement of voting results for the Resolutions and Elections

3pm Wikimedian of the Year and Honorary Member Awards

3.30pm Thanks and close

Proxy voting

All voting for this year’s AGM will happen by proxy. Our current Articles of Association require members to be present in person at the AGM to vote on the day, something we’re not able to facilitate this year. This means all votes must be submitted by the proxy deadline which is 2pm on Thursday 16th July. You can find the director candidate statements here, ask them questions here, and read through the resolutions we’ll be voting on here.

Voting packs have been sent to all members by email, but if you haven’t received one and you think you should have, please do get in touch with Katie at membership@wikimedia.org.uk.

Sign up

You must register for the AGM on Eventbrite rather than on wiki as we need your full name, not Wikimedia user name, and we’ll be sending out video conference links to all attendees registered through Eventbrite closer to the date.

If you have any questions or more general comments, please do get in touch with Katie at membership@wikimedia.org.uk.

We look forward to seeing you next Saturday!

If you’d like to join Wikimedia UK as a member or renew your current membership, you can do so here. To support free access to knowledge through our programmes, you can support us here.

Earlier today, the 600,000th commit was pushed to Wikimedia's Gerrit server. We thought we'd take this moment to reflect on the developer services we offer and our community of developers, be they Wikimedia staff, third party workers, or volunteers.

At Wikimedia, we currently use a self-hosted installation of Gerrit to provide code review workflow management, and code hosting and browsing. We adopted this in 2011–12, replacing Apache Subversion.

Within Gerrit, we host several thousand repositories of code (2,441 as of today). This includes MediaWiki itself, plus all the many hundreds of extensions and skins people have created for use with MediaWiki. Approximately 90% of the MediaWiki extensions we host are not used by Wikimedia, only by third parties. We also host key Wikimedia server configuration repositories like puppet or site config, build artefacts like vetted docker images for production services or local .deb build repos for software we use like etherpad-lite, ancillary software like our special database exporting orchestration tool for dumps.wikimedia.org, and dozens of other uses.

Gerrit is not just (or even primarily) a code hosting service, but a code review workflow tool. Per the Wikimedia code review policy, all MediaWiki code heading to production should go through separate development and code review for security, performance, quality, and community reasons. Reviewers are required to use their "good judgement and careful action", which is a heavy burden, because "[m]erging a change to the MediaWiki core or an extension deployed by Wikimedia is a big deal". Gerrit helps them do this, providing clear views of what is changing, supporting itemised, character-level, file-level, or commit-level feedback and revision, and allowing series of complex changes to be chained together across multiple repositories, and ensuring that forthcoming and merged changes are visible to product owners, development teams, and other interested parties.

Across all of repositories, we average over 200 human commits a day, though activity levels vary widely. Some repositories have dozens of patches a week (MediaWiki itself gets almost 20 patches a day; puppet gets nearly 30), whereas others get a patch every few years. There are over 8,000 accounts registered with Gerrit, although activity is not distributed uniformly throughout that cohort.

To focus engineer time where it's needed, a fair amount of low-risk development work is automated. This happens in both creating patches and also, in some cases, merging them.

For example, for many years we have partnered with TranslateWiki.net's volunteer community to translate and maintain MediaWiki interfaces in hundreds of languages. Exports of translators' updates are pushed and merged automatically by one of the TWN team each day, helping our users keep a fresh, usable system whatever their preferred language.

Another key area is LibraryUpgrader, a custom tool to automatically upgrade the libraries we use for continuous integration across hundreds of repositories, allowing us to make improvements and increase standards without a single central breaking change. Indeed, the 600,000th commit was one of these automatic commits, upgrading the version of the mediawiki-codesniffer tool in the GroupsSidebar extension to the latest version, ensuring it is written following the latest Wikimedia coding conventions for PHP.

Right now, we're working on upgrading our installation of Gerrit, moving from our old version based on the 2.x branch through 2.16 to 3.1, which will mean a new user interface and other user-facing changes, as well as improvements behind the scenes. More on those changes will be coming in later posts.

Header image: A vehicle used to transport miners to and from the mine face by 'undergrounddarkride', used under CC-BY-2.0.

Wikidata continues to play a more central role on the internet by supplying digital assistants like Siri and Alex with facts. Amplifying Wikidata’s facts through these digital assistants has implications for discovering new ideas, answering questions, and representing history accurately. In a recent Wikidata course, this exact concern came up in the area of criminal justice.

Wrongful convictions have happened consistently throughout history. This is well-documented on Wikipedia and on projects like the National Registry of Exonerations. There is also the Innocence Project, whose mission is “is to free the staggering number of innocent people who remain incarcerated, and to bring reform to the system responsible for their unjust imprisonment.”

In our Wikidata courses we introduce participants to several aspects of the open data repository — how linked data works, how to express relationships between items, and also how to create new ways of structuring information. This last concept is extremely important not only to ensure the completeness of Wikidata for the millions that use digital assistants, but also to ensure content is accurate and able to be queried.

If you consider how foundational structuring information is to the usefulness of Wikidata, then discovering information that has yet to be structured is one of the most important parts of contributing to Wikidata. The way to express these relationships on Wikidata is through properties (“depicts,” “country,” and “population,” for example). In one of our recent courses, a participant discovered a missing property and took the initiative to create it.

Ken Irwin, a trained reference librarian, has a passion for criminal justice reform. While searching Wikidata during our beginner course, he noticed that there were only properties concerning conviction. By only having conviction data, any post-conviction data could not be represented on Wikidata. The Wikidata community, of course, has a process for creating new properties. Irwin proposed an “exonerated of” property, and editors began discussing ways to structure this kind of data. An interesting question about data modeling followed.

Wikidata editors revealed potential ways to model post-conviction data. An “exonerated of” property would cover some of this information, but what about documenting data about pardons, amended sentences, and extended sentences? There is also an ongoing debate as to whether this information should exist as a qualifier, modifying a conviction property (since you cannot have an exoneration without a conviction). Anther school of thought suggested that exoneration data should exist as its own property since that particular person would have been cleared of any conviction.

These kinds of discussions have a direct impact on queries — how to pull this information from Wikidata, and how to associate it with other criminal justice data (i.e., where does this fall in the spectrum of rendering judgement, etc.).

After a period of debate, this property was approved in January 2020. You can see how many items use this property by clicking this link. Once that page loads, click the blue “play button” in the lower left of your screen to run the query.

These query results embody the word “wrong” in the phrase “wrongfully convicted,” and have a far reaching implication when it comes to describing people accurately. The ability to improve accuracy around the representation of information is one of the many reasons why so many people are drawn to working on Wikidata.

Stories like this underscore the importance of editors pursuing their passions, uncovering gaps, and taking steps to address those gaps on Wikidata. It is only in this way that those who choose to get involved in open data will be able to make Wikidata more reliable, equitable, and useful for all users and for anyone represented on Wikidata.

Interested in taking a course like the one Ken took? Visit learn.wikiedu.org to see current course offerings.

Following on from my blog post using OpenRefine for the first time, I continued my journey to fill Wikidata with all of the Tors on Dartmoor.

This post assumes you already have some knowledge of Wikidata, Quickstatements, and have OpenRefine setup.

Getting some data

I searched around for a while looking at various lists of tors on Dartmoor. Slowly I compiled a list that seemed to be quite complete from a variety of sources into a Google Sheet. This list included some initial names and rough OS Map grid coordinates(P613).

In order to load the data into OpenRefine I exported the sheet as a CSV and dragged it into OpenRefine using the same process as detailed in my previous post.

Reconciliation in OpenRefine

This data set doesn’t yet link to Wikidata at all! And that’s where the OpenRefine reconciliation features get used once again.

Column5 represents something that is close to a label for Wikidata items, and that is what I will use for reconciliation alongside matching the type of tor(Q1343179).

Reconciliation took a few minutes and matched the tors that already exists on Wikidata with the names that were loaded into OpenRefine. Depending on the data you’re reconciling with you might want to choose a more general type or even no type at all, but be prepared to do more manual work matching things.

The screenshot below shows the records, with reconciliation applied, filtered by judgement state (on the left hand side). “matched” refers to records that were already linked to a Wikidata item and “none” refer to those that need some manual work.

Note: this screenshot was taken after I performed my data load, hence many are matched, but it still illustrates the manual matching process.

Even the “matches” records should probably be checked, depending on the options that are used for reconciliation. Next, the records with no match need to either be connected to one of the found Wikidata items or set to “Create new item”.

The case described here is very simple, and there are many more details that can be taken into account with reconciliation. You can find more docs here.

Mutating a data element

The grid reference is in the data set is not yet in the correct format for Wikidata which expects a format with no spaces such as SX604940.

To do this the “Edit cells” > “Replace” option can be used to simply replace any whitespace with nothing.

Although the screenshot doesn’t show much, as whitespace is being replaced, this had the desired effect on the data!

There are also many other mutations that can be applied, including regex alterations which open up a world of possibilities.

Mapping to Wikidata

The “Schema” tab is the next one to look at, allowing mapping the simple table of data to Wikidata items and statements.

To get here I clicked “+ add item” and used tor(Q1343179) as the type for the items.

The name of the tor which is in my Column5 can be used as an English label.

Finally, the one data value from my table can be included as a Statement, using OS grid reference(P613) can be added referring to Column9 for the value. The data set also included a URL value in another column which was the source of the grid reference. This was also added as a Reference with a retrieved(P813) date.

Editing with Quickstatements

I’m sure there is a way to create these items within OpenRefine itself, however, I wanted to have try out the Quickstatements integration, which is why I chose this creation method.

Under the “Wikidata” menu there is an item allowing an “Export to QuickStatements”. Clicking this will general a list of Quickstatments commands (sample below).

Q1343179       Len     "Fox Tor (Fox Tor Mires)"
Q1343179        P613    "SX62616981"    S813    +2020-07-08T00:00:00Z/11        S854    "https://someURL"
Q1343179        P613    "SX74257896"    S813    +2020-07-08T00:00:00Z/11        S854    "https://someURL"
Q1343179        P613    "SX70908147"    S813    +2020-07-08T00:00:00Z/11        S854    "https://someURL"
Q1343179        P613    "SX55689094"    S813    +2020-07-08T00:00:00Z/11        S854    "https://someURL"

These commands can be pasted into a “New batch” on the quickstatments tool.

Clicking “Import V1 commands” and then “Run” will start making your edits.

The edits

You can see the initial batches of edits in the editgroups tool (which indexes this sort of batched editing) here and here. The first was a small test batch, the second completing the full run.

The post Creating new Wikidata items with OpenRefine and Quickstatements appeared first on Addshore.

(reposted with minor edits from https://lists.wikimedia.org/pipermail/labs-l/2017-July/005036.html)

TL;DR

• Tool Labs is being renamed to Toolforge
• The name for our OpenStack cluster is changing from Labs to Cloud VPS
• The prefered term for projects such as Toolforge and Beta-Cluster-Infrastructure running on Cloud-VPS is VPS projects
• Data Services is a new collective name for the databases, dumps, and other curated data sets managed by the cloud-services-team
• Wiki replicas is the new name for the private-information-redacted copies of Wikimedia's production wiki databases
• No domain name changes are scheduled at this time, but we control wikimediacloud.org, wmcloud.org, and toolforge.org
• The Cloud Services logo will still be the unicorn rampant on a green field surrounded by the red & blue bars of the Wikimedia Community logo
• Toolforge and Cloud VPS will have distinct images to represent them on wikitech and in other web contexts

In February when the formation of the Cloud Services team was announced there was a foreshadowing of more branding changes to come:

This new team will soon begin working on rebranding efforts intended to reduce confusion about the products they maintain. This refocus and re-branding will take time to execute, but the team is looking forward to the challenge.

In May we announced a consultation period on a straw dog proposal for the rebranding efforts. Discussion that followed both on and off wiki was used to refine the initial proposal. During the hackathon in Vienna the team started to make changes on Wikitech reflecting both the new naming and the new way that we are trying to think about the large suite of services that are offered. Starting this month, the changes that are planned (T168480) are becoming more visible in Phabricator and other locations.

It may come as a surprise to many of you on this list, but many people, even very active movement participants, do not know what Labs and Tool Labs are and how they work. The fact that the Wikimedia Foundation and volunteers collaborate to offer a public cloud computing service that is available for use by anyone who can show a reasonable benefit to the movement is a surprise to many. When we made the internal pitch at the Foundation to form the Cloud Services team, the core of our arguments were the "Labs labs labs" problem and this larger lack of awareness for our Labs OpenStack cluster and the Tool Labs shared hosting/platform as a service product.

The use of the term 'labs' in regards to multiple related-but-distinct products, and the natural tendency to shorten often used names, leads to ambiguity and confusion. Additionally the term 'labs' itself commonly refers to 'experimental projects' when applied to software; the OpenStack cloud and the tools hosting environments maintained by WMCS have been viable customer facing projects for a long time. Both environments host projects with varying levels of maturity, but the collective group of projects should not be considered experimental or inconsequential.

I have long known about OpenRefine (previously Google Refine) which is a tool for working with data, manipulating and cleaning it. As of version 3.0 (May 2018), OpenRefine included a Wikidata extension, allowing for extra reconciliation and also editing of Wikidata directly (as far as I understand it). You can find some documentation on this topic on Wikidata itself.

This post serves as a summary of my initial experiences with OpenRefine, including some very basic reconciliation from a Wikidata Query Service SPARQL query, and making edits on Wikidata.

In order to follow along you should already know a little about what Wikidata is.

Starting OpenRefine

I tried out OpenRefine in two different setups both of which were easy to set up following the installation docs. The setups were on my actual machine and in a VM. For the VM I also had to use the -i option to make the service listen on a different IP. refine -i 172.23.111.140

Getting some data to work with

Recently I have been working on a project to correctly add all Tors for Dartmoor in the UK to Wikidata, and that is where this journey would begin.

This SPARQL query allowed me to find all instances of Tor (Q1343179) on Wikidata. This only came up with 10 initial results, although this query returns quite a few more results now as my work has continued.

SELECT ?item ?itemLabel ?country ?countryLabel ?locatedIn ?locatedInLabel ?historicCounty ?historicCountyLabel
WHERE 
{
  ?item wdt:P31 wd:Q1343179.
  OPTIONAL { ?item wdt:P17 ?country }
  OPTIONAL { ?item wdt:P131 ?locatedIn }
  OPTIONAL { ?item wdt:P7959 ?historicCounty }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

And I used the download CSV file option for my data set to load into OpenRefine.

This may not be the best way to work with SPARQL and OpenRefine, but after reading the docs this is where I ended up, and it seemed to work quite well.

Loading the data

One of the first options that you’ll see is the option to load a file from your computer. This file can be in multiple formats, CSV included, so this loading process from the query service was straight forward. It’s nice to see how many options there are for different data formats and structures. Even loading data directly from Google sheets, or from the Clipboard is supported.

I picked a project name, hit the “Create Project” button, and my data was loaded!

Connecting to Wikidata

After a quick look around the UI I found the Wikidata button with the menu item “Manage Wikidata account”. Clicking on this prompted me to log in with my Username and Password.

In most cases you probably don’t want to enter your password into any 3rd party application, OpenRefine included. MediaWiki, and thus Wikidata, allows you to create separate passwords for use in applications that have slightly restricted permissions. You can read the MediaWiki docs here and find the page to create them on Wikidata here.

I created a new “bot” with the name “OpenRefine”, and a few basic rights that I figured OpenRefine might need, including:

• Basic rights
• High-volume editing
• Edit existing pages
• Create, edit, and move pages

This new account, with the username and password that is generated as part of this process, could then be used to log into OpenRefine without sharing the password of my main account.

Reconcile & Edit

This basic example does not use OpenRefine at a high level, and there is still a lot of cool magic to be explored. But as a first step, I simply want to make a couple of basic edits.

Looking at the list of tors I could see some that I knew that had a historic country value set, but did not include a value for located in. So this is where I started, manually filling the gaps in the locatedIn column (you can see this below where locatedIn has a value, but the locatedInLabel does not.

Next to connect this currently arbitrary collection of data that I have loaded from a CSV to Wikidata in some way with a bit of simple ID based reconciliation. OpenRefine has a handy feature for just this case that can be found in the “Reconcile” >> “Use values as identifiers” option of the column that you want to reconcile. In my case, this is the item column and also the locatedIn column that I had altered, both of which are needed for the edits.

Next I tried the “Upload edits to Wikidata” button, which brought me to a page allowing me to map my table of data to Wikidata statements. For this first batch of edits, this involved dragging the item field into the item space on the page, and then filling out the property used for my data, and dragging locatedIn into place.

Once finished it looked something like this:

One of the next pages allows you to review all of the statements that will be “uploaded” when you hit the button for review, and also a page provides you with any warnings for things you may have missed.

For my current case that stated that I wasn’t adding references yet, which I was aware of, but chose to skip in this case.

Then a small edit summary is needed and you can hit the “Upload edits” button!

The edits

You can see the initial batches of edits in the editgroups tool (which indexes this sort of batched editing) here and here.

The edit groups tool is helpfully linked in the edit summary of the batch of edits.

One issue (not editing / logged out)

With version 3.3 I ran into one issue where my Wikidata session would apparently get logged out and OpenRefine and the Wikidata Toolkit (which OpenRefine uses) would choke on this case.

I already filed a bug here and the ability to logout and log back in again should be fixed with the next OpenRefine release! (It look less than 3 hours for the patch to get written and merged)

Further

I have already continued editing with OpenRefine beyond this first basic batch and hope to continue writing some more posts, but for now I hope this very basic example serves someone well for a small set of initial edits.

I’d love to see more integration with the Wikidata Query Service and OpenRefine. I’m sure it is probably in the pipes. But with the workflow followed in this blog post there is a lot of back and forth between the two, creating a CSV, downloading it, uploading to OpenRefine, making changes etc. And in order to then continue an existing project with fresh data, you need to repeat the whole process.

The post Using OpenRefine with Wikidata for the first time appeared first on Addshore.

Jennie Choi is the General Manager of Collection Information at the Met Museum. She recently took two of Wiki Education’s courses on Wikidata and reflects on her experience with the Wikimedia community in this guest blog post.

Partnering with leading members of the Wiki community has been invaluable. We’ve learned a lot from their experience and expertise, but I wanted to expand my skill set and become more self-sufficient in editing and uploading images. My contributions started modestly at edit-a-thons hosted by the museum. During these events I learned the basics about statements, properties, and references. I filled out some items where properties were missing and manually uploaded a handful of images. Given the size of our collection (500,000 records online), and the large number of new images added since the Open Access launch (roughly 60,000). I needed to learn how to make contributions more quickly and at scale.

The Metropolitan Museum began working with the Wiki community in 2017 when we launched our Open Access program. Led by our Wikimedian-in-Residence, Richard Knipel, over 375,000 public domain images were uploaded to Wikimedia Commons that year. This resulted in a huge increase in visibility for images in our collection. Wikipedia articles on a wide range of topics including Henry VIII, Vincent Van Gogh, pineapples, Down Syndrome, and the economy of Japan have all used images from The Met’s collection. We have seen incredible growth in Wikipedia page views containing our files. Between April 2017 and April 2020 views increased by 576%.

With the launch of our public API in 2018 we expanded our collaboration with the community. During an AI hackathon with Microsoft and MIT that year we worked with Wikimedian strategist Andrew Lih who worked to create a Wikidata game that allowed users to validate depicts statements generated by an AI algorithm. We have continued working with Andrew as he has led the effort to create Wikidata items for works in our collection. Because of its structured data schema, links to other items, language independence, and reliance on Wikidata by internet search engines and voice assistants, we see great benefits in extending the reach of our collection by contributing to this important resource. Most rewarding is being able to reach new audiences and seeing our objects in new contexts. With Andrew’s guidance, over 14,000 items have been created for our objects. 

My first project was to enhance our existing Wikidata items wherever possible. Many of our items were missing images, dates, depicts, and other statements important for describing artworks. Using the Quick Statements tool I was able to add over 1,000 images to our public domain records. Earlier this year I mapped all our subject keywords to their corresponding Wikidata items using Open Refine and stored the Q numbers in our cataloguing database. This made it very easy to add depicts statements to over 4,000 Wikidata items where this was lacking. My next project will be to continue creating new items for works in our collection. We are fortunate to be building on Andrew’s work. He has made tremendous progress in developing a data model for the GLAM community and has also developed a crosswalk database mapping our thousands of object names to Wikidata items. While we do have a significant number of records on Wikidata, there are large areas of the collection that have not been added yet, like British satirical prints, Civil War photographs, African textiles, and our large baseball card collection, which many people probably don’t know we have. Tools like Quick Statements make creating items much easier but we still face challenges in creating items for more complex artworks. Many objects have multiple creators like the tapestry room Croome Court, which has several designers and makers who worked on portions of the room, as well as a manufacturer, and a workshop director. Most of the qualifiers for these names like “Room after a design by” and “Plaster ceiling and cornice moldings by” do not exist on Wikidata. Other objects like suits of armor may consist of different components created during different and approximate time periods. Sword scabbards can have multiple dimensions and will often include weights. More work is needed in developing a data model that will allow us to more accurately describe our collection, which we can then share with other art museums.

In addition to enhancing and creating new Wikidata items I’ve started uploading more of our public domain images to Wikimedia Commons. During the past three years we have acquired more works and digitized thousands of new objects. We want to continue sharing our open access content with the world. Using the Patty Pan tool I uploaded over 5,000 images during the past month. I’m hoping the development of new tools will make it easier to add structured data statements to our Commons images, which will make our collection even more discoverable.

We’re still in the early stages of our work with Wikidata. There are many more areas I look forward to exploring, including creating records for all our artists, using queries to generate compelling data visualizations, adding translated content from our printed guidebook, and working with other museums to further the development of data models for complex artworks. I’d like to develop a strategy to improve accessibility to our images on Commons. With hundreds of thousands of available images, how can we help users find our files more easily? I’d also like to explore ways to keep our records up to date in an automated manner. Our staff make cataloging changes everyday, how can we ensure these changes are reflected on Wikidata? 

Contributing our content to Wikimedia Commons and Wikidata has allowed the Met to further fulfill our mission to connect people to creativity, knowledge, and ideas. We are seeing our works used in new contexts that go well beyond art history while hopefully creating some inspiration along the way.

Interested in taking a course like the one Jennie took? Visit learn.wikiedu.org to see current course offerings.

Header/thumbnail image by Sailko, CC BY-SA 3.0 via Wikimedia Commons.

Before I was paid to work on code for a living, it was my hobby. My favorite project from when I was young, before The Internet came to the masses, was a support library for my other programs (little widgets, games, and utilities for myself): a loadable graphics driver system for VGA and SVGA cards, *just* before Windows became popular and provided all this infrastructure for you. ;)

The basics

I used a combination of Pascal, C, and assembly language to create host programs (mainly in Pascal) and loadable modules (linked together from C and asm code). I used C for higher-level parts of the drivers like drawing lines and circles, because I could express the code more easily than in asm yet I could still create a tiny linkable bit of code that was self-sufficient and didn’t need a runtime library.

High performance loop optimizations and BIOS calls were done in assembly language, directly invoking processor features like interrupt calls and manually unrolling and optimizing tight loops for blits, fills, and horizontal lines.

Driver model

A driver would be compiled with C’s “tiny” memory model and the C and asm code linked together into a DOS “.com” executable, which was the simplest executable format devisable — it’s simply loaded into memory at the start of a 64-KiB “segment”, with a little space at the top for command line args. Your code could safely assume the pointer value of the start of the executable within that segment, so you could use absolute pointers for branches and local memory storage.

I kept the same model, but loaded it within the host program’s memory and added one more convention: an address table at the start of the driver, pointing to the start of the various standard functions, which was a list roughly like this:

• set mode
• clear screen
• set palette
• set pixel
• get pixel
• draw horizontal line
• draw vertical line
• draw arbitrary line
• draw circle
• blit/copy

Optimizations

IIRC, a driver could choose to implement only a few base functions like set mode & set/get pixel and the rest would be emulated in generic C or Pascal code that might be slower than an optimized version.

The main custom optimizations (rather than generic “make code go fast”) were around horizontal lines & fills, where you could sometimes make use of a feature of the graphics card — for instance in the “Mode X” variants of VGA’s 256-color mode used by many games of the era, the “planar” memory mode of the VGA could be invoked to write four same-color pixels simultaneously in a horiz line or solid box. You only had to go pixel-by-pixel at the left and right edges if they didn’t end on a 4-pixel boundary!

SVGA stuff sometimes also had special abilities you could invoke, though I’m not sure how far I ever got on that. (Mostly I remember using the VESA mode-setting and doing some generic fiddling at 640×480, 800×600, and maybe even the exotic promise of 1024×768!)

High-level GUI

I built a minimal high-level Pascal GUI on top of this driver which could do some very simple window & widget drawing & respond to mouse and keyboard events, using the low-level graphics driver to pick a suitable 256-color mode and draw stuff. If it’s the same project I’m thinking of, my dad actually paid me a token amount as a “subcontractor” to use my GUI library in a small program for a side consulting gig.

So that’s the story of my first paying job as a programmer! :)

Even more nostalgia

None of this was new or groundbreaking when I did it; most of it would’ve been old hat to anyone working in the graphics & GUI program library industries I’m sure! But it was really exciting to me to work out how the pieces went together with the tools available to me at the time, with only a room full of Byte! Magazine and Dr Dobb’s Journal to connect me to the outside world of programming.

I’m really glad that kids (and adults!) learning programming today have access to more people and more resources, but I worry they’re also flooded with a world of “everything’s already been done, so why do anything from scratch?” Well it’s fun to bake a cake from scratch too, even if you don’t *have* to because you can just buy a whole cake or a cake mix!

The loadable drivers and asymmetric use of programming languages to target specific areas of work are *useful*. The old Portland Pattern Repository Wiki called it “alternating hard and soft layers”. 8-bit programmers called it “doing awesome stuff with machine language embedded in my BASIC programs”. Embedded machine code in BASIC programs you typed in from magazines? That was how I lived in the late 1980s / early 1990s my folks!

Future

I *might* still have the source code for some of this on an old backup CD-ROM. If I find it I’ll stick this stuff up on GitHub for the amusement of my fellow programmers. :)

In 2015 I noticed git fetches from our most active repositories to be unreasonably slow, sometimes up to a minute which hindered fast development and collaboration. You can read some of the debugging details I have conducted at the time on T103990. Gerrit upstream was aware of the issue and a workaround was presented though we never went to implement it.

When fetching source code from a git repository, the client and server conduct a negotiation to discover which objects have to be sent. The server sends an advertisement that lists every single reference it knows about. For a very active repository in Gerrit it means sending references for each patchset and each change ever made to the repository, or almost 200,000 references for mediawiki/core. That is a noticeable amount of data resulting in a slow fetch, especially on a slow internet connection.

Gerrit originated at Google and has full time maintainers. In 2017 a team at Google went to tackle the problem and proposed a new protocol to address the issue, and they closely worked with git maintainers while doing so. The new protocol makes git smarter during the advertisement phase, notably to filter out references the client is not interested in. You can read Google introduction post at https://opensource.googleblog.com/2018/05/introducing-git-protocol-version-2.html

Since June 28th 2020, our Gerrit has been upgraded and now supports git protocol version 2. But to benefit from faster fetches, your client also needs to know about the newer protocol and have it explicitly enabled. For git, you will want version 2.18 or later. Enable the new protocol by setting git configuration protocol.version to 2.

It can be done either on an on demand basis:

git -c protocol.version=2 fetch

Or enabled in your user configuration file:

[protocol]
    version = 2

On my internet connection, fetching for mediawiki/core.git went from ~15 seconds to just 3 seconds. A noticeable difference in my day to day activity.

If you encounter any issue with the new protocol, you can file a task in our Phabricator and tag it with git-protocol-v2.

23/06/2020-29/06/2020

About us

• To strengthen our teams, we are urgently looking for volunteer native speakers to help us with proofreading.Okay, I want in. What do I have to do? Just:
  1. visit https://osmbc.openstreetmap.de/ – then we already have your OSM nickname and an email address for the invitation to our MatterMost instance.
  2. then please write an email to theweekly[.]osm[at]gmail[.]com, so we know that you want to participate. Then we will send you a link to our internal wiki page where we try to explain how OSMBC works.

Mapping

• Bkil would like your help in improving the definition of a venue mostly serving artisanal desserts made in-house: a cukrászda. He would like some input from mappers in other Central European countries where they also have such amenities. An extensive discussion followed but we would recommend that you don’t read it if you are feeling peckish.
• Joseph Eisenberg asked the tagging list how boundaries of national parks and other protected areas are determined in people’s countries. This was a follow up to Joseph’s question about mapping national forest boundaries on the Talk-us mail list.
• German cities are redrawing road markings to create ‘pop-up’ cycle lanes for the duration of the COVID-19 lockdown, as cyclists demanded more space to physically distance on their commutes to work. Rogehm asked (automatic translation) the German forum for advice on how to map them.

Community

• Rory McCann reported on his OSM activities during the month of May, with much of the work on the OSMF Board of Directors.
• Unfortunately the State of the Map US Planning Committee has had to postpone their November conference. The Committee is currently exploring the possibility of holding a hybrid conference in 2021 with a live track and a virtual track, so that those who cannot attend in person are still able to participate, share their talks, and socialise with those in Tucson. In the meantime they invite you to join one of their many Mappy Hours or find a local event near you.
• Julien Minet writes in his user diary that he, despite having advertised for Mapillary in the past, will no longer contribute to Mapillary, now that it was sold to Facebook. He does not want to support a company earning money from neo-nazis.
• Bryan Housel, who had been working for Mapbox, now works for Kaart, a contractor of Apple and Facebook, on RapiD, a fork of iD which can import features automatically traced from satellite imagery into OSM.
• The Kerala (India) Government has made a documentary on Mapathon Keralam, an initiative to edit OpenStreetMap in the state.
• OSM India volunteer Arun Ganesh has given a demo of Indic map rendering (original tweet).
• User Supaplex030 analysed (automatic translation) the parking situation in Berlin’s Hermannstraße using existing OSM data and found interesting insights into the consumption of space by different transport modes.

Imports

• The Maine Address Import (#492) is finished! Alex Hennings added a Mistakes Were Made section to the import’s wiki page, so others might avoid the same traps. It took nearly a year and he wrote a brief reflection on his experience.

OpenStreetMap Foundation

• FOSSGIS e.V. and FOSSGIS-OSMF-Stammtisch have released a position statement in response to the OpenStreetMap Foundation plans for hiring additional paid staff. The OSMF had explicitly asked for feedback from local chapters. They argue that both the general principles of personnel policy and the concrete creation of new jobs based on a job description should be subject to approval by OSMF members.
• OSMF has a new bank account, as Barclays Bank had terminated the business relationship.
• Joost Schouppe wrote about his life as an OSMF Board member and the reality has far surpassed his expectations. Joost notes that the Board, in his experience, is more productive than previous boards and puts a big part of this down to the new Chair, Allan Mustard.
• Since 1 July the standard style map tiles from OpenStreetMap have been licensed as an ODbL ‘Produced Work’ with no additional terms applied. Simon Poole explains the background and history of this change in the licence in a blog post.

Humanitarian OSM

• SIGenBici has been selected as the #map2020 project of the year. HOT revealed that the project from Medellín, Colombia had been chosen from the 28 groups that participated in #map2020. This project was led by Natalia Arruda and focused on mapping cycling infrastructure within the city. Rebecca Firth and Edoardo Neerhut give more details on the criteria used to select the project of the year and the other seven projects that were finalists.
• Are you a member of a mapping community that is looking for funding to expand your mapping activities? Do you have ideas about how to engage more people and train your community in how to use OpenStreetMap? If so, you can apply for a HOT Community Impact Microgrant.

Maps

• ÖPNVKarte, a map for public transport, will be available as a map layer on openstreetmap.org soon.

switch2OSM

• Proximity_13 reports on reddit that the K9 SAR (rescue dog) teams in the USA are now also using OSM-based maps. He also writes about Map attribution: ‘I was so happy to see that OSM contributors tag’, which should be self-evident, even for ‘big players’.

Open Data

• Since 1 July 2020 the INSPIRE spatial polygon dataset has been available under the Open Government Licence. This dataset maps more than 23 million property title extents across England, Wales and Scotland.

Software

• Sarah Hoffmann announced the release of osm2pgsql version 1.2.2. This is a bugfix release which updates the bundled libosmium only. It fixes an issue where osm2pgsql updates stalled on a large multipolygon relation.
• Release of Nominatim version 3.5.1 has bug fixes for two important issues with osm2pgsql (see osm2pgsql new release above):
  • osm2pgsql might get stuck during updates when running with Postgresql 12;
  • osm2pgsql might hang when processing extremely complex multipolygons.
• The Heidelberg University’s GIScience Research Group announced that documentation for version 1.0 of the ohsome API has been released.
• The new QGIS 3.14 version adds support for the native loading of vector tiles. Adam Laza’s blog post gives more details.

Programming

• Frédéric Rodrigo wrote (automatic translation) a detailed article on an approach for automatically reconstructing the geometry of polling station catchments. In France electors are required to vote at specific polling stations. If the catchment areas of these polling stations were known, then maps of electoral results could be produced.
• Alex Hennings made a tool to help with bulk tag modifications, expressing them as SQLite queries. Alex created it to help with translation while working on OSM imports and he hopes others find it useful.

Did you know …

• … that RapiD, Facebook’s iD fork to load automatically traced features into OSM, does not offer automatically traced features in Iran and North Korea because they are not allowed to do so under US sanctions?

OSM in the media

• Accenture estimates the value of OSM data at USD 1.67 billion.

Other “geo” things

• Marcel Reinmuth wrote about a method for comparing physical access to healthcare across Sub-Saharan Africa. HeiGIT used hospital locations and the ORS Isochrone service to calculate travel-time distances from hospital locations and the respective reached population per country.
• Steven Feldman reflected on the minor spat that broke out in the Twittersphere between Amber Bosse and Kenneth Field, over Kenneth’s ironic #cartofail decision tree.
• OSGeo:UK ran a one day online FOSS4G event on 17 June 2020. Videos of the presentations are available here.
• Michael Spencer has created a map of the density of public toilets across Scotland. The map is based on public toilet data from OpenStreetMap and the Ordnance Survey’s coastline data.
• Cartography is an extension of political power. China wants to counter the US military aircraft present in the South China Sea and Taiwan Strait, so publicises the tracks of US military aircraft. The SCS Probing Initiative, established by the Peking University Institute of Ocean Research, is monitoring the presence of US military aircraft. They recently showed US military plane activities on a map that complies with Chinese regulations, that is displaying the eleven-dash line, which also includes Taiwan.
• Dustin Carlino released the alpha version of A/B Street, a traffic simulation game built on Seattle OSM data. GeekWire carried a story about Dustin, his game, and what inspired him to build it.

Upcoming Events

Where	What	When	Country
Taipei	OSM x Wikidata #18	2020-07-06
London	Missing Maps London	2020-07-07
Lyon	Rencontre mensuelle pour tous	2020-07-07
Berlin	145. Berlin-Brandenburg Stammtisch (Online)	2020-07-09
San José	South Bay Virtual Hack Night & Map Night	2020-07-09
Munich	Münchner Stammtisch	2020-07-14
Nottingham	Nottingham pub meetup	2020-07-21
Lüneburg	Lüneburger Mappertreffen	2020-07-21
Kandy	2020 State of the Map Asia	2020-10-31-2020-11-01

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

This weeklyOSM was produced by Nakaner, NunoMASAzevedo, PierZen, Polyglot, Rogehm, TheSwavu, derFred, naveenpf.

A new version of Manjari typeface is available now. It adds Vedic Anuswara letter ഄ - 0D04 encoded in Unicode 13.0 It is available at SMC website. To learn more about Vedic Anuswara, you may refer the encoding proposal

Today, we’re sharing Wiki Education’s 2020–21 Annual Plan. The plan, and budget, were approved by the Board of Trustees at its June meeting. We’re sharing the plan here as part of Wiki Education’s commitment to sharing information about our goals and spending. It’s a report on our work last year, and a look ahead to what we’re aiming to achieve during the coming fiscal year (July 1 through June 30).

I’d like to take this opportunity to reflect on what we’ve achieved last year, and what we will do in the year ahead.

The last year has been a time of great achievement for Wiki Education:

• Our Student Program supported more than 16,000 student editors as they improved Wikipedia articles on academic topics, supported by our staff. Wiki Education’s student editors represent an impressive 20% of all new active editors on the English Wikipedia. Although we saw a drop in editing activity after COVID-19 hit the United States, this has been one of the best years of “Teaching with Wikipedia” ever.
• We launched a popular new Wikidata course. Participants from a wide range of important cultural institutions like the Smithsonian, the Met, and the Frick participated in the course, learning the technical skills needed to make edits, create items, and query items as well as the underlying concepts required to connect their collections to Wikidata. Most importantly, participants in these courses started thinking about how to use Wikidata as a means to interpret, share, and grow their own data collection. 
• Our Wikipedia course program for empowering subject-matter experts to share their knowledge with the general public has also grown this year, bringing partnerships with organizations like the Society of Family Planning, the American Physical Society, and the WITH Foundation to improve the quality of information on Wikipedia. 
• Wiki Education’s Communicating Science initiative had a banner year, improving the availability of scientific information on Wikipedia through all our programs, and giving science communication skills to thousands of early career scientists. 

In the coming year, we will continue to support the Wikipedia Student Program and our Scholars & Scientists Program, with courses on editing both Wikipedia and Wikidata, just with smaller participant numbers. Over the last several years, our staff has done incredible work developing technical tools, support materials, and processes that have set us up to be able to more than double our programmatic impact compared with five years ago, when we last had a staff this size. We anticipate continuing to develop our model for selling services as well as forming an Advisory Board to support our ongoing fundraising work. Through this work, we are confident we will be able to make a meaningful difference to Wikipedia and Wikidata, on our three strategic pillars of equity, quality, and reach.

This is a difficult time, and to survive it, Wiki Education has needed to significantly reduce expenses. We believe our plan will enable us to continue to achieve substantial programmatic impact, while also ensuring the financial sustainability of the organization, not just for this year, but for many years to come. 

We are grateful for the support of our board, staff, funders, and community as we navigate these turbulent times together.

The COVID-19 pandemic is causing severe economic disruption across the United States and around the world, and is negatively impacting nearly all nonprofits, educational institutions, and cultural organizations.

It’s true for us too. This week, Wiki Education reluctantly says goodbye to seven staff members. This is a significant number of people for such a small organization, and it is painful.  

I will personally and professionally miss everyone who is leaving. But the sad truth is that Wiki Education needs to significantly cut costs, in order to ensure it can continue to exist and do its work.

Given the severity of disruption to the nonprofit sector, the philanthropic sector, and to our partner and stakeholder organizations, as well as the uncertainty about what will happen next, we can’t expect to generate the revenue we would need to keep our operations at the levels they have historically been.

And so, we have had to cut costs. In March, we closed our office in the Presidio in San Francisco, and going forward we expect to be a fully remote organization. We will save some money because we will travel less, and have fewer face-to-face events. We have cut hours for some staff, including myself. But in the end, to reduce expenses to a point that would safeguard the organization’s survival, we needed to eliminate seven positions. That’s the reality of this moment.

I am deeply grateful to the people who are leaving Wiki Education, for their dedication and their hard work. Most have been with us for years, and each one has made innumerable contributions to our mission. We are heartbroken they are leaving.

Their work with Wiki Education will continue to benefit millions of people who read Wikipedia on a daily basis. I want to thank them for everything they have accomplished in their time with us, and I wish them all the best.

By Michael Große, WMDE

Modern websites are expected to be accessible for as many users as possible. Universal design includes aspects such as color contrast, keyboard navigation, or input methods. Blind users and users with visual impairments often also use screen reader software which renders text and images as speech or Braille output.

Hence developers need to design and implement websites that work well with assistive technology such as screen readers. The best way to ensure this is to actually use a screen reader yourself.

This tutorial covers how to install, set up and use Orca on Linux systems, with sighted developers, product managers, and user experience designers in mind. Orca is a screen reader available on Linux which is being continuously developed as part of the GNOME project. It is probably the best choice to test screen reader conformance when developing on Linux.

In addition to this tutorial, I also found a video with Orca installation, setup and usage instructions on Youtube for those who prefer a video format.

Installing Orca

If Orca is not available by default on your system, you need to install the packages orca and espeak-ng as provided by your distribution. The espeak-ng voices aren’t great at all, but so far they seem to be the only thing that works.

Setting it up

You can open the Orca settings dialog by pressing Alt+F2 (the application launch menu) and typing “orca -s” and then pressing Enter. The most important setting is in the top left: Keyboard Layout. This switches between two sets of key bindings suitable for either the narrow laptop keyboards or wide external keyboards with a dedicated Numpad. That keys on that Numpad will be referred to as “KP”, e.g., KP Plus for the plus key on the Numpad. Note that the num-lock must be disabled.

Select what is appropriate for you. This article will always mention both key bindings if they differ.

One of the important keys is the Orca Modifier key, which enables some meta commands for Orca.

• Desktop: Insert or KP 0
• Laptop: Caps Lock

You can open the settings again while Orca is running with Orca Modifier+Space.

Starting and stopping Orca

When Orca is not running you can start it by bringing up your application launch menu with Alt+F2 and type “orca” and press Enter. You can stop it similarly: in the application launch menu type “killall orca” and press Enter.

When Orca is running it replaces many of your normal keyboard letters with commands for navigating the document by structure (more on that below). You can toggle this behavior with Orca Modifier+z.

Having Orca talk all the time can be pretty annoying. You can silence it with Orca Modifier+s. But note: Orca’s structural navigation commands affecting many of your keyboard keys (mentioned above) are not disabled by this and might still be active. This can lead to behavior that is confusing and tricky to debug, so take care.

Reading

Use Arrow Left and Arrow Right to go forward/backward by one character and Ctrl+Arrow Left and Ctrl+Arrow Right go forward/backward by one word. Arrow Up and Arrow Down read the previous/next line. You can use the Tab (and Shift+Tab) key to move between focusable elements (links, buttons, inputs, etc.).

Say All

Orca’s Say All command will cause Orca to speak the entire document beginning from your current location.

• Desktop: KP Plus
• Laptop: Orca Modifier+Semicolon

Structural Navigation

Listening to a document from start to finish is likely not the usual use case. Screen readers offer a variety of commands to navigate the document’s structure. A full list is available at the official documentation on structural navigation. Below is a selection of commands to get you started.

As mentioned before, these commands can be toggled on or off with Orca Modifier+z. By default, they are on.

Moving by headline

• Next and previous heading: H and Shift+H
• Display a list of headings: Alt+Shift+H

You can use 1 to 6 to go to the next headline of the respective level and Shift+1 to Shift+6 to go to the previous one. Alt+Shift+1 to Alt+Shift+6 gives a list of all headlines of that level

Moving by landmark

Different regions of a webpage have different functions, like navigation, main content or search. The regions are ideally marked up as so-called landmarks to help with navigation.

• Next and previous landmark: M and Shift+M
• Display a list of landmarks: Alt+Shift+M

Moving by link

• Next and previous link: K and Shift+K
• Display a list of links: Alt+Shift+K

Moving in lists

• Next and previous list: L and Shift+L
• Display a list of lists: Alt+Shift+L
• Next and previous list item: I and Shift+I
• Display a list of list items: Alt+Shift+I

Interacting

You can follow links by pressing Enter, push buttons by pressing Space or Enter.

When navigating forms, you can use Tab/Shift+Tab to go to the next/previous focusable object, regardless of type or you can use Orca’s structural navigation commands for forms to move to the next or previous form field. In order to use the structural navigation commands to exit a form field, you must be in browse mode. If you are in focus mode, you can switch to browse mode by pressing Orca Modifier+A.

Next steps

You should now be able to move around the document in some basic ways and have the screen reader tell you its contents. More useful commands can be found in the Orca command reference and Orca preferences documentation. More information on high-level concepts can be found in the Orca documentation. Guidelines for how to ensure accessibility issues can be found in Mediawiki’s Accessibility guide for developers.

Try to get more familiar with your screen-reader, then start to use it with your eyes closed or wearing a blindfold or with your computer monitor turned off. It is surprising how different one’s product can appear when one can’t see what is going on.

About this post

Featured image credit: Orcas & humpbacks, Christopher_Michel, CC BY 2.0

Dr. Pratima Gupta (she/her/hers) is an Obstetrician/Gynecologist. She recently completed one of our Wiki Scholars courses sponsored by the Society of Family Planning, in which she learned how to add content to Wikipedia pages in her area of expertise. She practices in California with a professional emphasis on medical education and reproductive health rights, justice, and advocacy. When not doctoring, she can be found exploring outdoor adventures with her children.

“Is Wikipedia always right?” queried my ever-curious seven year old. I was selected to be a participant in a weekly 12 session Wiki Scholar program sponsored by the Society of Family Planning. The somewhat intimidating goal was to learn the process of updating and curating reproductive health articles on Wikipedia. Our virtual sessions were scheduled on Mondays at 11am PST- an ideal time for my focus and solitude… until the global COVID-19 pandemic hit. Despite my best efforts of privacy and attempts at hiding, my Wiki Scholar Zoom sessions were frequently interrupted by my seven year old requesting assistance with his homeschool journal or wanting to say hi to my cohort of scholars. Finally, he asked me,  “what exactly is YOUR job at Wikipedia?”

I am a board-certified Obstetrician/Gynecologist and I provide abortion care — I was excited and a bit nervous about the perceived impact of updating family planning articles on Wikipedia. I explained to my child that Wikipedia is the go-to resource for millions of individuals for just about anything. But I also cautioned him that just because it was on Wikipedia, didn’t make it true. So, in answer to his questions, I informed him that Wikipedia is not always right and my “job” was to try and find the sections in health care (my expertise), where updates were needed.

Together we Wikipedia’d his favorite things like Darth Vader and Harry Potter to the things he dreads like flu shots and tomatoes. I showed him the updates that I had contributed to transgender sex work, abortion restrictions during COVID-19, and types of abortion restrictions in the United States. He was impressed that I was an “author” on Wikipedia. This mainstream integration of Wikipedia has persisted in his world when he squealed in excitement that Wikipedia was being utilized in the cartoon Smurfs movie.

Recently, we went on a bicycle ride through some trails near our home and spotted a two foot striped snake on the side of the path. We observed it from a distance in awe and trepidation as it slithered away into the underbrush. My son looked at me with a glimmer of intrigue in his deep hazel eyes and said, “I’ll race you home. We need to Wikipedia that snake!” Another committed user is born!

To see our open Wikipedia training courses, visit learn.wikiedu.org.

June was a surprisingly good month—it’s been great to witness the growth of our interns every two weeks when we sit down to talk to each other. They are always very kind and eager to learn and to share, so it’s really reinvigorating to pass time with them. It makes me reconnect to the person I was during my own Outreachy internship—and, in retrospect, be amazed by own past work whenever I need to help someone by referencing it.

I’ve been working more closely with Sage to address a few gaps we have related to feedback. They’ve opened issue #390 in response to a few concerns I raised after hearing about the experiences of one of our former interns.

As Sage works to solve some technical debt we have, I’ve been focusing a lot of my time to exploring the results of our 2019 longitudinal survey. There’s a lot of interesting data to unveil—data that, I hope, will help us improve a multitude of processes inside Outreachy. It turns out that the timing for improving processes and documentation is perfect—we’ve been getting some very interesting feedback from current and former interns. Even better, we have a lot of data available to guide our decisions and work towards improving Outreachy just in time for the next round. 🎉

Lastly, I’ve been preparing for a presentation I’ll give this Saturday about making your first contribution to open source projects. I’m going to present that at the III Workshop ADAs — Mulheres conectADAs, an online conference organized by a group of women in technology in my faculty, and it will be streamed live on my faculty’s YouTube channel. I’m hoping this will introduce Outreachy to a larger audience and encourage more people from my state (and maybe even from Brazil as a whole) to apply.

I’ve been aware of Pinchbeck for some years after seeing an example of a Pinchbeck hairband at Bristol Museum & Art Gallery. The Wikipedia article on the alloy has needed a pic since 2005. Unfortunately my pictures from Bristol sucked due to missing focus and simply not holding the camera still (in my defence I was running on about 2 hours sleep and trying to visit all the museums in Bristol).

Getting a photo of Pinchbeck suffers from a problem of being sure what you are photographing is actual Pinchbeck. The term seems to be used to label 3 different things. You have true kvlt pinchbeck from the original Pinchbeck family, approximately contemporary imitations and then a random collection of vintage brass.

To be on the safe side I wanted a photo of the first option. This rules out simply buying some since the well provenanced stuff is expensive and for the rest I don’t have the expertise to dig through. Museum materials seem a better option but being somewhat reflective it tends to photograph poorly under museum light. Birmingham museums has some but the lighting in that section isn’t the best (although that can be countered to a fair extent).

Finally I tried a commons search. I don’t usually do this because a lot of the time you don’t get anything and the quality can be rather mixed (the best commons search engine remains the english wikipedia). On this occasion though After a lot of photos relating to the pumping station and the village in Lincolnshire I found this clock made by the son of the original Christopher Pinchbeck. Definitely rue kvlt Pinchbeck

16/06/2020-22/06/2020

About us

• Since issue #516 we have been publishing in the Chinese language, more precisely Taiwanese Mandarin and Traditional Chinese as it is spoken and written in Taiwan. We are very happy and hope that by reaching new readers in Asia we can increase the enthusiasm for OpenStreetMap.

Mapping

• Chuck Sanders is seeking a consensus for suggestions on rail tagging, in particular how to use reporting_marks=* and operator=*.
• After the discussion of providing a pre-upload warning to users about edits with large bounding boxes, a ticket was created for JOSM. The idea was well-received on the Talk mailing list. The availability of the warning is scheduled for the next release of JOSM.
• Florian Lohoff has made (automatic translation) some interesting visualisations which show differences between OSM and public data in the Cologne area. He is showing not just missing buildings, but also differences in classification, such as garages or substations with just a building=yes tag.
• Voting on Garry Keenor’s proposal to tag railway tracks with electrification systems using third or fourth rails has started.
• Pelderson’s proposal for new roles in recreational route relations, namely alternative, excursion, approach and connection has been approved with 36 votes for, 1 vote against and 1 abstention.
• Joseph Eisenberg has updated the existing proposal for man_made=qanat, a type of underground aqueduct constructed by traditional methods, found predominantly in the Middle East, and asks for comments.
• Martijn van Exel found a TIGER import artifact and offered a live stream of him ‘trying to untangle this mess’. According to his blog post live mapping in JOSM with an audience was fun. In the end he found it was easier to delete the mess and start again.
• The German community has launched a wiki page for the ‘Focus of the week‘ (automatic translation). There, weekly changing tasks are listed and edited. In the past week, for example, the postal codes were checked. The group organises itself on Telegram.

Community

• Geomob Podcast published an interview with Harry Wood of OpenStreetMap London.
• OpenStreetMap US has implemented a code of conduct and defined a process for moderation for violations. The code of conduct applies to communication channels specific to OSM-US, such as Slack, OSM-US Github, the OSM-US Facebook group, and OSM-US events, but not to OpenStreetMap and OpenStreetMap’s worldwide and local communication channels in other regions.
• Various comments have been made about the acquisition of Mapillary by Facebook:
  • In an article on medium.com Joe Morrison asks why Facebook took over Mapillary. In his article he also sheds light on Mapillary’s products, which are not well known in the OSM community. Joe presents three reasons for the acquisition in the article.
  • Harry Wood compares the acquisition with Microsoft’s purchase of GitHub.
  • Ilya Zverev discusses (automatic translation) the consequences of the purchase for Mapillary’s future and sustainability. He guesses that Facebook might repeat the same ‘mistakes’ in Western countries as it did with AI-based tracing of satellite imagery in developing countries.
• Requests for features to be added to OSM’s main map are as regular as Groundhog Day. This time a user asked, on Reddit, why points of interests aren’t clickable.

OpenStreetMap Foundation

• OSM’s Data Working Group has released its activity report for the first quarter of 2020.

Events

• OSGeo, FOSSGIS and OpenStreetMap will be present (automatic translation) at the virtual AGIT 2020, Austria’s largest yearly geoinformation conference and fair.
• This year’s SotM is looming and the State of the Map Working Group is looking for help. In a blog post the working group suggests ways volunteers can help with the online event, to be held on 4 and 5 July 2020.
• The Heidelberg University, in cooperation with Amnesty International Heidelberg, will host a mapping event ‘Mapping Human Rights’ on 30 June 2020.

Humanitarian OSM

• The Audacious Project has announced that it will support five projects as part of its programme, including HOT. HOT aims to map ‘a total of 1 billion people’ in 94 of the most vulnerable countries of the world over the next five years. On the Talk mailing list, Christoph Hormann reminded us that OSM does not map people but rather maps their environments. On the Mapbox blog, Mikel Maron looks back on the history of HOT, which he co-founded. A long FAQ, released by HOT, is worth a read as it includes some details about funding, HOT’s plans, and the impact on OSM.

Maps

• Well-known Taiwanese mapper Jidanni mentioned that an environmental NGO has made a map of illegal factories on farmland (automatic translation). They ask citizens who know of such factories to report these, as there is a serious problem of factories outside industrial areas in Taiwan, which violate zoning laws and regulations.

Open Data

• The UK Government’s Geospatial Commission launched its much-awaited national Geospatial Strategy on 16 June. Well-known commentators on geospatial open data were underwhelmed. Initial thoughts have come from: Jeni Tennison (head of ODI), Owen Boswarva, and Leigh Dodds. Richard Fairhurst wonders if the commission has ever heard of OpenStreetMap. At least Ordnance Survey OpenData continues.

Releases

• The API for the OpenStreetMap history analysis platform, which has been developed by Heidelberg University’s GIScience Research Group, has reached version 1.0.
• QGIS 3.14 and 3.10.7 LTR (long-term release) are now available for download.

Did you know …

• … that you could feast on crowdsourced sarcasm and focused nerd wrath by following @Anonymaps?
• [1] … the Mozilla (or Chrome) browser extension to help the OpenStreetMap community easily access different maps and tools to analyse OSM data?
• … Blender-OSM, an add-on that adds OSM and terrain data to the Blender?

OSM in the media

• John Stanworth wrote an introduction to OpenStreetMap for Now Then, a local arts and culture magazine in Sheffield (the magazine is being published through an app during the COVID-19 epidemic).
• OpenStreetMap India’s contributions have been well covered in this article.

Other “geo” things

• Tom MacWright, a familiar name to many in OSM, writes about ‘Ethics in Geo’ in his blog. As ever, there’s a discussion at hacker news, including the suggestion, from another prominent OSMer, that WTFPL licensing has the effect of dissuading ‘bad guys’ from using software licensed that way.
• Garmin has released details of its new Edge-series devices ‘Edge 1030 Plus’ and ‘Edge 130 Plus’. The new devices have received some feature updates but do no offer any groundbreaking new functions.
• meinGrün, a webapp for finding green spaces, launched (automatic translation) with two pilot areas, Dresden and Heidelberg, on 19 June.
• The BBC reported about efforts to map the seabed. The article assumes that crowdsourcing will also play a role in mapping the seafloor, which is still 81 percent unknown territory.
• High-definition (HD) map data is important for those interested in developing self-driving cars. Supported by the government of Taiwan, the National Cheng Kung University has founded (automatic translation) the High Definition Maps Research Center (HDMRC). The centre will help government and industry work on developing standards, processing map data, and verification of HD mapping in Taiwan.

Upcoming Events

Where	What	When	Country
Guarda	EuYoutH OSM Meeting (cancelled)	2020-06-24-2020-06-28
Düsseldorf	Düsseldorfer OSM-Stammtisch	2020-06-26
Rennes	Atelier découverte	2020-06-28
Prague	Pražský mapathon	2020-06-30
Montrouge	Réunion des contributeurs locaux	2020-07-01
Stuttgart	Stuttgarter Stammtisch (online)	2020-07-01
Cape Town	HOT Summit (To Be Rescheduled)	2020-07-01-2020-07-02
Taipei	OSM x Wikidata #18	2020-07-06
London	Missing Maps London	2020-07-07
Lyon	Rencontre mensuelle pour tous	2020-07-07
Berlin	145. Berlin-Brandenburg Stammtisch (Online)	2020-07-09
Nantes	Rencontre mensuelle	2020-07-09
San José	South Bay Virtual Hack Night & Map Night	2020-07-09
Munich	Münchner Stammtisch	2020-07-14
Kandy	2020 State of the Map Asia	2020-10-31-2020-11-01

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

This weeklyOSM was produced by AnisKoutsi, Nakaner, NunoMASAzevedo, PierZen, Polyglot, Rogehm, SK53, Guillaume Rischard (Stereo), SunCobalt, Supaplex, TheSwavu, YoViajo, derFred, geologist, jinalfoflia, mOlind.