🕑 48 minutes
It's the 2022 holiday special! Featuring an all-star guest panel (Daisy Chen, Richard Knipel, Trevor Parscal and Denny Vrandečić) weighing in on the current Wikimedia sound logo competition. Hear their informed opinions! And if that wasn't enough, you can then listen to Lex Sulzer reminisce about jumping into snowy lakes.
Intimate portrayals of “home” are exquisitely captured by the prize-winning images and videos of this year’s Wiki Loves Africa competition. The idea of home is an emotive subject and this year’s winners do not disappoint, framing the many factors – intimate, communal, individual, cultural, interior, and exterior – that compel us to return and take comfort.
Each year, Wiki In Africa (www.wikiinafrica.org), the international organisers of Wiki Loves Africa (www.wikilovesafrica.net) sets a thematic challenge for the global photographic community – to submit photographs that present the everyday reality of Africa. The competition has been running since 2014. Since then, the competition has encouraged the contribution of nearly 89,000 images to Wikipedia’s image bank under a free licence. Since January 2017, these images have been collectively viewed 1.15 billion times on Wikipedia articles.
This year, the Wiki Loves Africa competition called for photographers to contribute images that reflected its 2022 theme of Home & Habitat as it exists within the African context. The continent-wide call and events resulted in 16,265 entries from 1,111 media specialists and photographers, 75% of which were entirely new to the Wikimedia projects. Once the competition closed in April 2022, it was the incredible task of the 5 tier jury process to pick out the winners. After an initial review of all the entries by a volunteer team of Wiki Loves Africa organisers and Wikipedians, The Wiki Loves Africa 2022 International Jury is made up of 12 professional photographers from Africa (including past winners) and international Wikimedians who are Commons experts. The quality of images (visually arresting and well framed) was a key criterion in the selection, as was the encyclopaedic value of each image.
The 2022 Wiki Loves Africa winners across five prize categories hail from four different countries.
The 1st prize of USD$2000 (pictured above) goes to Summer Kamal (Egypt) – a return Wiki Loves Africa prize winner – for a gentle image of a man in the later years of his life pausing in contemplation amid the facades of his culture. Announced alongside Kamal are the two additional winners of the top 3 prizes. Two additional prize categories are for the Best Video entry and Special Collection.
Kamal spoke about why she took this particular image:
“I had taken this picture because I was walking in the narrow alleys of Nuba while the night was creeping in to give this charming blue light. House number six and this old man is sitting in front of his house safe and secure, surrounded by a similar group of simple small houses. I liked this picture, so I took the photo right away.”
One of the jury members, Aboubacar Kamaté (and Wiki Loves Africa Best Video prize winner for 2020 and 2021) said about the image:
“I really like the image. Its tint, the decorum is artful and clearly, its author is nothing sheer of a great and master painter with her framework and what’s given to us to feast our eyes upon on her gem”
The second prize (USD1500) went to Home is my Work by Mohamed Hozyen (Egypt), another previous Wiki Loves Africa prize winner:
“I took this picture as it’s part of an ongoing documentary project I’m working on. I think it fits this year’s theme which is Home. It shows what home could mean to some people around the world.”
As International Juror and South African photographer Yazied Kamadien said:
“It’s a natural moment in this family’s life. It is quite busy, as there are many different things happening in the photo, but it is good to show how layered home life is for this family.”
Third prize (USD1000) was awarded to Planning Ahead by Ayorinde Ogundele (Nigeria).
Ogundele took the picture because he wanted: “to document everyday life. To show how people adapted during the pandemic. I wanted to highlight the resilience in people and how they utilise serendipity to their advantage.”
This year’s video prize went to the charming and beguiling, and yet contextually encyclopaedic, story of a boy dreaming of a home for his family as he travels to school through the streets of Port Harcourt, Nigeria.
Videographer Green Wilfred Somoni “drew inspiration from my childhood to make the video, Dream Home. As an only child with a single parent from a poor background, I always dreamed of giving myself and my mother a better life. I entered my video to Wiki Loves Africa not just to satisfactorily resonate with the theme of this year’s contest, but to share a story about the reality of many children from poor homes in Africa.”
Finally, the organisers are excited to announce the winner of an additional prize category. This year a US$750 prize is awarded to a collection of images that tell a story. This year, the jurors felt User:Myousry6666 photo essay Windows Stories was poignant and beautifully executed, and fascinating in the representation of multiple stories framed in each window.
Winner Mohammed Myousry shares the 12-year motivation behind capturing this collection:
“Since I started shooting in 2010 and during many trips and photography workshops in the street, I made this photo collection of windows. Windows always fascinated me.
Different windows and different stories … but each Window has its own story.
‘Behind every window, a story’, I always tell myself when I watch a window at any time. So many windows, so many stories. And behind each window is a person experiencing their versions of reality; each room is the world for someone. It’s mind-blowing if you think about it. Faces leaping over the windows, constantly in search of a world unknown, numerous questions arising out of curiosity about the way life moves on and this world revolves about.
This curiosity is well supplemented with some drama of fairy tale stories, adding some incredible essence to the joy of livelihood. You cannot segregate these moments to any age group, everybody has their own stories to dream about and to share within themselves. Reassuringly, the sea of windows — dark or lit — remains. And behind every window, a story.
This photo collection summarised 12 years of shooting different windows and different stories in my country Egypt.”
Every year, Wiki Loves Africa provides a platform for thousands of Africa’s photographers to take back the visual narrative by celebrating Africa’s cultural diversity and contemporary reality on Wikipedia.
After an initial review of all the entries by a volunteer team of Wiki Loves Africa organisers and Wikipedians, the international jury of twelve professional photographers from across Africa and Wikimedia photographic specialists from around the world considered and deliberated on the collection. The quality of images was a key criterion in the selection, as was the encyclopaedic value of each image, and whether an image was visually arresting and well framed. It was equally important to unearth the unexpected.
At its heart, Wiki Loves Africa is a drive for Africans to document Africa. Both amateur and professional photographers and filmmakers are called to share the world that they view every day; life recorded and observed from within their own communities. Their contributions form a collection of royalty-free images about Africa, a continent that is often subject to a condemning external gaze and many subsequent stereotypes.
Through the competition’s eight editions 88,640 images have been added to Wikipedia’s media library, Wikimedia Commons, by 10,380 photographers from across the continent. The images have a life beyond the competition, with these images being placed in articles on Wikipedia, and thus being viewed over 1.1 billion times since January 2016; with 26 million views of the images in September 2022 alone.
Wiki Loves Africa is a Wiki In Africa initiative that is activated by the Wikimedia community that created Wikipedia in support of the WikiAfrica movement. The competition was conceptualised and is managed by Florence Devouard and Isla Haddow-Flood of Wiki In Africa as a fun and engaging way to bridge the digital divide by rebalancing the lack of visual representations and relevant content that exists about Africa on Wikipedia. The competition is funded by the Wikimedia Foundation and supported in kind by UNESCO and a host of local partners in individual countries. The images donated are available for use on the internet and beyond, under the Creative Commons license CC BY SA 4.0.
Watch a special edition of WikiAfrica Hour where we meet the Wiki Loves Africa 2022 Winners.
IMAGES AVAILABLE AT WIKI LOVES AFRICA 2022/WINNERS
New features on Wikipedia are making it easy for everyone to edit Wikipedia, especially those contributing to the site for the first time.
Every time you read a Wikipedia article, you are reading the work of a volunteer contributor.
Nearly 300,000 people from around the world edit Wikipedia articles each month — they start new pages, fix typos, add images and references, and more. They curate and create the knowledge available on the world’s largest online encyclopedia. It is a massive undertaking and responsibility.
Many Wikipedia editors have been contributing for years, including several who have been around since the site was started 21 years ago. Their familiarity and expertise in applying Wikipedia’s practices and guidelines are essential in more ways than we can count. But equally essential to our shared mission of becoming the sum of all knowledge is adding new contributors to our projects. New contributors from all over the world bring diverse perspectives and knowledge that will carry Wikipedia forward, making sure that Wikipedia’s content represents the full and rich diversity of all humanity.
Over the last four years, the Product Department at the Wikimedia Foundation has been building new ways for people to get into editing Wikipedia for the first time.
Recently, the team rolled out its newest set of features to support “newcomers” (new Wikipedia editors). These features include a newcomer homepage as a dashboard for new editors, a mentor program in which experienced volunteers guide new ones on editing, and a feed of suggested edits that uses machine learning to offer quick and easy first edits. The features were developed in close collaboration with existing Wikipedia volunteers and communities.
To learn more, we talked with Marshall Miller, the Wikimedia Foundation Group Product Manager who worked with the team that developed these new features, and Rita Ho, the Principal Designer who designed them.
Q: What inspired your team to work on this project, and why now?
Rita: We know from data and user research that editing Wikipedia is less popular than it used to be. Many people are too intimidated to edit because they think they don’t have the time, technical expertise, or specialized knowledge to make a contribution. Additionally, new folks are sometimes put off either because they’ve had a negative experience with experienced members of the editing community, or else feel alone due to a perceived lack of community. To advance knowledge equity, we need to encourage people from all walks of life to contribute, no matter how big or small their edits may be.
Marshall: Over the years, the Wikimedia movement has done amazing things to help people learn to edit, from holding events, written documentation, and instructional videos and tools. The Foundation wanted to support this by making a difference in the Wikipedia user experience itself. If we want more kinds of people to edit Wikipedia, we need more kinds of ways to edit Wikipedia.
Q: How would you describe these features to someone new to Wikipedia?
Rita: Previously, the experience for many new editors on Wikipedia was confusing and inaccessible. As a result, many of those people either never edited at all, or edited once and never returned. Our approach to encouraging a more diverse, thriving editor movement is led by these new features. The first two are the “newcomer homepage” and “suggested edits,” described below.
Newcomer Homepage
Some of the main challenges expressed by new editors include
technical ones, such as learning the editing tools, and more
conceptual challenges, like learning the rules, policies, and what
appropriate content on Wikipedia looks like. Another challenge for
many newcomers was understanding the cultural aspects behind
editing on Wikipedia. For example, when you edit and add something
to Wikipedia, other volunteers will validate or cross-check this
content for approval. Actions like those can cause discussions or
debates for people who don’t understand how the process
works.
To respond to these challenges, we implemented
a homepage that greets each new editor when they first join
Wikipedia. This is meant to be a clear starting point on where and
how to begin editing. On the homepage, new editors will find
several features to make the process easier, including an assigned
mentor, who is an experienced Wikipedian that they can go to for
any questions or guidance; and an impact module that shows how many
times articles they edit have been viewed – showing in
real-time that their edits are viewed by the world.
Suggested Edits
Assisted by machine learning, the
suggested edits feature introduces new ways to edit so that
people with all different interests and skills can get started with
editing. We ask newcomers questions about their interests when they
first join; the feature then offers tasks related to those
interests. Then, newcomers are walked through each step of a simple
first task, such as adding a link or image to an article.
These features are all mobile-friendly, making it easy and accessible for many to start editing from their phones—the way the majority of people access the internet today.
Q: How did Wikipedia volunteers collaborate in the development and implementation of these new features?
Marshall: Our team has a philosophy of building new products and features with Wikipedia volunteer communities, not just for them. Volunteers have the best understanding of how their wikis work and what solutions will best improve Wikipedia.
We work with community ambassadors and volunteers who speak multiple languages and have a deep understanding of their communities’ needs. These collaborators bring their communities into the product-development process and create strong communication channels.
Rather than just releasing these changes without warning, we share the decision-making process with volunteer communities, and we give community members some control over how these features function on their specific language version of Wikipedia. For example, the Portuguese Wikipedia might have different homepage features than the Spanish Wikipedia, which they choose according to their community’s needs.
Q: What have been the results of these new editor features so far?
Marshall: Through controlled experiments and conversations with volunteer communities, we’ve seen that this new experience has statistically improved newcomer engagement and editing on Wikipedia.
With all the current features in play, we see a 16 percent improvement in the likelihood that newcomers make the first edit and that they return to continue making edits. Since 2019, when we first started piloting the features, about 700,000 article edits have been made with help of these features by 85,000 people, and about 80,000 questions have been asked to mentors.
Although numbers tell their own story, I think hearing a community perspective can offer a more complete picture of the impact of these features. Ankan Ghosh Dastider, one of our community ambassadors from Bengali Wikipedia, told me:
“Bengali Wikipedia still lacks qualitative content on a
variety of topics, and the main reason is the low number of
contributors compared with other large Wikipedias. After all,
contributing to Wikipedia projects can seem difficult at first for
newcomers – they have to use words that are neutral, support
the added information with proper references, and follow the
policies that are often difficult to understand from their
perspective.
I am thankful for these new editor features, as they have had a
positive impact on my community and Wikipedia so far. The
mentor’s platform, in particular, has had a big impact on
supporting new contributors. The Bangla Wikipedia volunteer
community has good faith in these updates and we are looking
forward to a deeper and more effective involvement of newcomers in
the future days with the introduction of even more
features.”
Q: So, how can we check out these features ourselves and get involved?
Rita: That’s the easy part: just create an account in any language Wikipedia and get started.
The time has come to play a part and help choose The Sound Of All Human Knowledge. From December 6 to 19, 2022, Wikimedians everywhere are invited to vote for their favourite Wikimedia sound logo submissions.
Everyone is invited to participate in the sound of all human knowledge. To vote for the Wikimedia sound logo, you must have a Wikimedia account that is not blocked on any project, is not a bot, and has been created by 5 December, 2022, 23:59 UTC. Accounts opened after this date will require 10 edits to participate. We have created a newcomer page to welcome those unfamiliar with our projects to get going and start contributing.
We’ve been talking about a sound logo for quite some time. Virtual voice assistants are growing in use and popularity around the world. Wikimedia content is everywhere too, but often not correctly or consistently identified. A sound logo is a brief collection of sounds usually between 1 and 4 seconds. Our sound logo will be a new way to identify Wikimedia content across a range of auditory uses and devices.
We have a rich legacy of visual logo contests in the movement, going back to the Wikipedia puzzle globe logo and as recent as the MediaWiki logo change in 2020 and Wikifunctions in 2021. However, sound cues in new and interesting parameters for submission, scoring, and selection. A concept was shared and improved through collaboration for a contest to find a sound logo for Wikimedia.
The contest for The Sound Of All Human Knowledge kicked off on 13 September and ran until 10 October 2022, and the participation was extraordinary. We received 3,235 submissions from 2,094 participants in 135 countries. Every submission was anonymized and reviewed by at least two Wikimedia volunteers for eligibility. The submissions were then scored through multiple rounds by professional audio producers and sound experts from the MassiveMusic global network. Finally, a selection committee comprising Wikimedia community members and sound professionals scored the top 40 submissions to present to the rest of the movement 10 submissions to choose from. The 10 sound logo finalists presented have been reviewed by an independent musicologist and undergone legal due diligence before being released for voting. It is now up to the Wikimedia movement to decide which sound logo will best identify the principles and efforts of the Wikimedia movement on audio devices. Each submission has a corresponding note from the contributor sharing their creation journey. Accordingly, descriptive language attempts to describe the sound in words for those deaf and hard of hearing.
Similar to previous Wikimedia logo votes, we are using the Schulz method and asking Wikimedians to select their top choices by arranging the logos by preference from favourite to least favourite. The submission that is placed as top choice by the largest number of people will be the contest winner. And additionally, we will have a sorted list of the rest of the submissions. Once we have a winning sound logo, the Legal Affairs team at the Foundation will undertake a clearance process to confirm the sound logo is original and distinctive ensuring it can be registered and protected. The winning contestant will then enter into an agreement with the Foundation that they are happy for their submission to represent the Sound of All Human Knowledge.
The TACE WIKI HUB was launched on the 14th of August, 2022 on the TACE campus in lecture room 20. The patron, Mr.Iddrisu Alhassan Sibdow, in collaboration with the executive director of Dagbani Wikimedians User Group, officially launched the hub. Team members of the Dagbani Wikimedians User Group spoke a lot about what can be done in order to succeed in all activities related to this program. Our patron also expressed his gratitude for the program’s successful launch and advised all participants to take Wikipedia seriously because it will help them in their studies and keep them up-to-date.
He also assured the team members that TACE WIKI HUB would be the best ever in the history of Dagbani Wikimedians.
TACE WIKI HUB organized a training and they deliberated on the Dagbani Orthography. The training was led by the hub patron himself, who is a Ghanaian language tutor of Tamale College of Education. He taught the participants the various vowels and consonants in Dagbani and their sounds and combinations to produce specific sounds. They also learn about the vowels and consonants that do not go together in a sentence. The training lasted for almost four hours. Most of the orthography was learned on that day.
TACE WIKI HUB embarked on very serious training. New participants were given an opportunity to create user accounts and also listen to the brief vision and mission of the hub and how Dagbani Wikimedians operate. They were also introduced to our interface; everything on the interface was explained to them and how to use it. They learned how to search for an article, how to create a new article, how to edit an already existing article, and how to use Wikipedia to help themselves with their assignments and other academic work. Participants were given an opportunity to create their own articles from scratch for us to see their level of understanding, and their efforts made massive progress.
We repeated the process of creating a new article and how to search for an article. We also learned how to edit a text; for example, bolding, italicizing, underlining a text, and many more. How to add sections and interlinks The training lasted for almost four hours; it took place from 9:00am to 12:40pm.
Learn more about the Dagbani Wikimedians Group on Meta-wiki and follow on social media to get involved in future events.
Early this week, we received confirmation that Ukrainian writer, activist and long-term Wikipedia volunteer Volodymyr Vakulenko had been killed by the Russian army during its invasion of Ukraine.
Volodymyr Vakulenko was a prominent Ukrainian writer, journalist, interpreter, and poet. He is an author of 13 published books and has received multiple literary awards. He edited and published several literary anthologies, and he organized numerous literary and artistic events across Ukraine.
Volodymyr had also been involved in activism and volunteer work. He participated in the 2014 Revolution of Dignity protests in Ukraine and was wounded there. Volodymyr created around 100 articles on Ukrainian Wikipedia and contributed with almost 4,000 edits since 2010; he was especially interested in coins and postal marks as subjects of his articles. Thanks to his contributions, Wikipedia readers can learn about the medieval coins of Azerbaijan, history of Mexico, or a Ukrainian poet, and many more topics. The articles he had created have been viewed more than 150 000 times.
When the Russian Army occupied Volodymyr’s village of Kapytolivka in the Kharkiv region in northeastern Ukraine, Volodymyr refused to leave – and continued to care for the vulnerable in his village. He was kidnapped by the Russian Army in early March together with his young son. His son was later released and is now safe, but Volodymyr himself couldn’t be found, even after Ukraine’s Armed Forces liberated the Kharkiv region in September.
While his relatives and friends feared Volodymyr had been killed, it was only on Monday, November 28th that DNA tests confirmed his death.
Volodymyr, aged around 50 at the time of his death, is survived by his 7-year-old son Vitalii and his parents.
If you would like to support Volodymyr’s family financially in helping care for his son, please contact info@wikimedia.org.ua
My first Wiki Indaba was held in 2022 at Kigali, Rwanda.
I had planned, for almost a year, to be on-site at this event.
It all started in 2019 when the Indaba was held in Abuja, Nigeria and partly because I was still new to the movement and had no idea what it was about, I didn’t take the opportunity seriously. A few days later, while attending another event at the American embassy in Abuja, the facilitator asked the audience if anyone present was an active contributor to Wikipedia to which I indicated with a raise of the hand (only me in a hall of about 50 people) she proceeded to ask if I had attended the just concluded Indaba to which I responded in the negative. The look on her face was one of terrible disappointment. All the prior excitement disappeared from her eyes and was replaced with a fleeting sadness. I had no idea why at the time. But that wave of emotion struck me and I decided that whatever it was that happens at Indabas, I was going to make it a personal assignment to find out for myself.
COVID-19 happened in 2020 and 2021 was the year of the everything-online. I finally got my chance in 2022 and what you’ll find in the rest of this post is a summary of my experience, observations and suggestions.
Expectations
I didn’t have a lot of them because I hadn’t been to any WikiIndaba. Also, all of the online documentation I came across of previous events weren’t very helpful with creating any meaningful expectations. Hence, I kept an open mind and expected a conference-like experience with its attendant seriousness and networking opportunities.
I had earlier submitted a presentation proposal and had received no response as at 3 days to the event. I also applied for a scholarship and received a regret mail. Honestly, I wasn’t very positive about getting one (only 40 scholars for the entire continent? Wow!) and had already booked my ticket and sorted out accommodation at an Airbnb in Kigali well ahead of time.
The Location
Kigali is beautiful. A truly beautiful African city. There is a view of greenery and mountains in almost every direction one turns to. My Airbnb in Kimhurura was about 10-15 minutes taxi from the Ubumwe Grande Hotel – the selected conference venue. I received a warm airport welcome and quickly made friends with Patty & Pauline. There is a lot more I want to write about Kigali and Rwanda, but this publication may not be best suited for such purposes.
The Organization
Wikimedia Rwanda had such enthusiastic members on ground. I particularly appreciate how the leader kept acknowledging the efforts of all of his team members and co-volunteers. WISCom (WikiIndaba Steering Committee – my first time hearing about this group) made its presence very well noticed all through the conference duration. It’s hard to imagine how the event would’ve gone on smoothly without the experienced input of members of this group. Notable of mention is Bobby (Chief Priest, as he was fondly referred to), he was everywhere.
The Conference
WISCom and the hosts wasted no time in ensuring that we moved from session to session seamlessly, live updates on social media channels, conference timetable updates etc were all happening almost at the same time.
Day 1,2,3 went by quite rapidly and there was a ton of learning and new experiences. However, I noticed that most people knew themselves from previous meetings and were very excited to reconnect, and that there were small pockets of others who didn’t seem to know or experience this palpable excitement. I soon found out that this latter group were the newcomers into the movement. Like me, this was their first Indaba experience but unlike me, they didn’t seem to have much experience with participating in Wikimedia themed events. One of them asked me what he could do to become like us. Strange question really because I didn’t consider myself to be a part of the ‘us’ group. I was emotionally moved and brought this to the attention of all the participants on day 3.
If we must present as an all-inclusive movement, then there is no better place to demonstrate this culture than at events like WikiIndaba and suchlike. Newcomers should be treated like brides in some African cultures – get all the attention they deserve, deliberately get offered help, given the opportunity to visibly participate.
Here’s a short list of suggestions:
I believe these points will greatly improve newbies participation experience at WikiIndaba and similar events.
Another thing that stood out for me was the importance of in-person meetings and the role it plays in building and sustaining a movement like ours. It was great matching faces to names and usernames. It was such a beautiful experience. I expected some people with great online presence to look big, but it didn’t really turn out that way! It doesn’t matter how popular online events have become, I am fully convinced that it’ll never measure up to the effect of seeing, hugging and experiencing colleagues live and in real time.
In all, I had an exciting and fun filled conference and the only thing I wish I did differently was to have included an extra 2–3-day post conference stay to help me recover mentally and see the beautiful country of Rwanda proper as opposed to traveling at midnight of the final day of the conference.
I am now looking forward to future Wikimedia events with excitement. Unfortunately, I’ll never be able to share this experience with my erstwhile American embassy facilitator.
 |
| https://en.wikipedia.org/wiki/Samuel_B._Fairbank |
 |
| Incorporating Wikipedia into normal learning practice - should only need a small incremental effort. |
tl;dr: What are our options in php to make SQLite not write files when given malicious SQL queries as a hardening measure against SQL injection?
One of the most famous web application security vulnerabilities is the SQL injection.
This is where you have code like:
doQuery( "SELECT foo1, foo2 from bar where baz = '" . $_GET['fred'] . "';" );
The attacker goes to a url like ?fred='%20UNION%20ALL%20SELECT%20user%20'foo1',%20password%20'foo2'%20from%20users;--
The end result is: doQuery( "SELECT foo1, foo2 from bar where baz ='' UNION ALL SELECT user 'foo1', password 'foo2' from users ;-- ';" );
and the attacker has all your user's passwords. Portswigger
has a really good detailed explanation on how such attacks
work.
In addition to dumping all your private info, the usual next step is to try and get code execution. In a PHP environment, often this means getting your DB to write a a php file in the web directory.
In MariaDB/MySQL this looks like:
SELECT '<?php system($_GET["c"]);?>' INTO OUTFILE "/var/www/html/w/foo.php";
Of course, in a properly setup system, permissions are such that mysqld/mariadbd does not have permission to write in the web directory and the DB user does not have FILE privileges, so cannot use INTO OUTFILE.
In SQLite, the equivalent is to use the ATTACH command
to create a new database (or VACUUM). Thus the SQLite
equivalent is:
ATTACH DATABASE '/var/www/html/w/foo.php' AS foo; CREATE TABLE foo.bar (stuff text); INSERT INTO foo.bar VALUES( '<?php system($_GET["c"]);?>' );
This is harder than the MySQL case, since it involves multiple commands and you can't just add it as a suffix but have to inject as a prefix. It is very rare you would get this much control in an SQL injection.
Nonetheless it seems like the sort of thing we would want to disable in a web application, as a hardening best practice. After all, dynamically attaching multiple databases is rarely needed in this type of application.
Luckily, SQLite implements a feature called run time limits. There are a number of limits you can set. SQLite docs contain a list of suggestions for paranoid people at https://www.sqlite.org/security.html. In particular, there is a LIMIT_ATTACH which you can set to 0 to disable attaching databases. There is also a more fine grained authorizer API which allows setting a permission callback to check things on a per-statement level.
Unfortunately PHP PDO-SQLITE supports neither of these things. It does set an authorizer if you have open_basedir on to prevent reading/writing outside the basedir, but it exposes no way that I can see for you to set them yourself. This seems really unfortunate. Paranoid people would want to set runtime limits. People who have special use-cases may even want to raise them. I really wish PDO-SQLITE supported setting these, perhaps as a driver specific connection option in the constructor.
On the bright side, if instead of using the PDO-SQLITE php extension, you are using the alternative sqlite3 extension there is a solution. You still cannot set runtime limits but you can set a custom authorizer:
$db = new
SQLite3($dbFileName);
$db->setAuthorizer(function ( $action, $filename ) {
return $action ===
SQLite3::ATTACH ? Sqlite3::DENY : Sqlite3::OK;
});
After this if you try and do an ATTACH you get:
Warning: SQLite3::query(): Unable to prepare statement: 23, not authorized in /var/www/html/w/test.php on line 17
Thus success! No evil SQL
can possibly write files.
| previous | 2022, week 49 (Monday 05 December 2022) | next |
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
The Wikisources use a tool called
ProofreadPage. ProofreadPage uses OpenSeadragon which is an open
source tool. The OpenSeadragon JavaScript API has been
significantly re-written to support dynamically loading images. The
functionality provided by the older version of the API should still
work but it is no longer supported. User scripts and gadgets should
migrate over to the newer version of the API. The functionality
provided by the newer version of the API is documented on
MediaWiki. [1][2]Changes later this week
The new version of MediaWiki will be on
test wikis and MediaWiki.org from 6 December. It will be on
non-Wikipedia wikis and some Wikipedias from 7 December. It will be
on all wikis from 8 December (calendar).Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
22/11/2022-28/11/2022
Flight paths of some birds [1] | © Benjamin Becquet, Data source: GBIF.org: BirdMap Data – GPS tracking of Storks, Cranes and birds of prey, breeding in Northern and Eastern Europe (09 May 2022) Bird pictures: WikiMedia Commons | map data © OpenStreetMap contributors
crossing:signals=*, a proposal to deprecate
crossing=* in favour of
crossing:signals=* and
crossing:markings=*.parking:lane=* and parking:condition=*
schema for mapping street parking spaces, until Thursday 8
December.
@lucasdestrem@mapstodon.space @LucasDestrem *
Carte
des rues du Raincy || Where | What | Online | When | Country |
|---|---|---|---|---|
| Cojata | POSPUESTO: Reunatón Latam  |
2022-12-03 |  |
|
| 加古川市 | State of the Map Japan 2022 in Kakogawa |
2022-12-03 |  |
|
| 京都市 |
京都！街歩き！マッピングパーティ：第34回
渉成園 |
2022-12-04 | |
|
| 臺北市 | OpenStreetMap x Wikidata 月聚會 #47 |
2022-12-05 |  |
|
| OSMF Engineering Working Group meeting |
2022-12-05 | |||
| Monthly MapRoulette Community Meeting |
2022-12-06 | |||
| City of Westminster | Missing Maps London Mapathon |
2022-12-06 |  |
|
| San Jose | South Bay Map Night |
✓ | 2022-12-07 |  |
| Berlin | OSM-Verkehrswende #42 (Online) |
✓ | 2022-12-06 |  |
| HOT Tasking Manager Monthly Meet Up |
2022-12-07 | |||
| Brest | Mapathon en partenariat avec Infini |
2022-12-07 |  |
|
| Rio de Janeiro | Workshop Mapeamento Participativo e Cartografia Social 2022 /
Participatory Mapping and Social Cartography Workshop 2022 |
2022-12-07 – 2022-12-08 |  |
|
| Stuttgart | Stuttgarter Stammtisch |
2022-12-07 | |
|
| München | Mapping Party: Christmas Edition |
2022-12-08 | |
|
| Žilina | Missing Maps mapathon Slovakia online #8 |
2022-12-08 |  |
|
| München | Münchner OSM-Treffen |
2022-12-08 | |
|
| Budapest | Corvin Mall in-person survey, Grund: NextCloud Maps,
StreetComplete, Snap, IPv6 |
2022-12-09 |  |
|
| Zürich | OSM-Stammtisch |
2022-12-09 |  |
|
| Berlin | 174. Berlin-Brandenburg OpenStreetMap Stammtisch (hybrid
– Test für FOSSGIS 2023) |
2022-12-09 | |
|
| [Online] 16th Annual General Meeting of the OpenStreetMap
Foundation |
2022-12-10 | |||
| København | OSMmapperCPH |
2022-12-11 |  |
|
| HOT Open Tech and Innovation Session – Option 1 |
2022-12-13 | |||
| HOT Open Tech and Innovation Session – Option 2 |
2022-12-13 | |||
| City of Nottingham | OSM East Midlands/Nottingham meetup (online) |
✓ | 2022-12-13 | |
| Salt Lake City | OSM Utah Monthly Meetup |
2022-12-15 | |
|
| Rio de Janeiro | Workshop Mapeamento Participativo e Cartografia Social 2022 /
Participatory Mapping and Social Cartography Workshop 2022 |
2022-12-14 – 2022-12-15 | |
|
| Michigan Meetup |
2022-12-15 | |||
| Stainach-Pürgg | 7. Virtueller OpenStreetMap Stammtisch Österreich |
2022-12-14 |  |
|
| IJmuiden | OSM Nederland bijeenkomst (online) |
✓ | 2022-12-14 |  |
| Roma | Incontro dei mappatori romani e laziali |
2022-12-14 |  |
|
| Brugge | OpenStreetMap meetup in Bruges |
2022-12-15 |  |
|
| Toulouse | Réunion du groupe local de Toulouse |
2022-12-17 | |
|
| Bruxelles – Brussel | OpenStreetMap meetup in Brussels |
2022-12-20 | |
|
| 158. Treffen des OSM-Stammtisches Bonn |
2022-12-20 | |||
| Lüneburg | Lüneburger Mappertreffen (online) |
2022-12-20 | |
|
| Karlsruhe | Stammtisch Karlsruhe |
2022-12-21 | |
Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there,
will appear in weeklyOSM.
This weeklyOSM was
produced by MatthiasMatthias,
PierZen,
Strubbl,
TheSwavu,
derFred,
Can,
快乐的老鼠宝宝.
We welcome link suggestions for the next issue via this
form and look forward to your contributions.
The event held at Nnamdi Azikiwe University, Anambra State, Nigeria recorded over 100 participants who were willing to contribute to Wikimedia projects. The statistics are shown on the event dashboard which registered 141 editors with a total of 2,003 articles created, 4,502 articles edited and a total of 12,500 edits. The event was done in a hybrid format to accommodate participants who couldn’t make it in-person.
However, the event ended with a contest, 41 editors participated and at the end of the contest, more than 1,480 articles were created on the Igbo Wikipedia. Prizes were given to top editors (about 13 in number). See details on contest dashboard and scoresheet. At the end of the event, we sought feedback from participants via a survey to get their opinion on the event and ways we could do better. There were a total of 28 responses from the survey. Below is the summary of findings and discussions.
The event was held at the university targeting the university
staff and students. However, some people within the University
community who were neither staff nor students also attended the
event following the outreach and awareness created. From the
responses, Nnamdi Azikiwe University Staff participated more,
followed by the students and other participants from different
works of life. Other participants who were not in Anambra state as
at the time of the event, participated online. See chat below for
elaborate details.
Most participants indicated that they were satisfied with the
event; content, facilitators, communication, follow-up, practical
sessions, venue, and contest. A few were not satisfied with the
contest. Most of the respondents agreed that the event was
very relevant.
Respondents were asked to grade their level of understanding of Wikimedia projects. Most participants ticked ‘good’, followed by excellent for Wikipedia, Wikicommons and Wikidata. See chart below for more details.
Some additional feedback regarding knowledge of Wikimedia projects
were that some respondents need continuous training and practice
for mastery; the unfavorable network of some participants affected
them badly; the experienced Wikimedians alongside the facilitators
were helpful. Generally, it was a wonderful experience.
Most participants contributed the most to Wikipedia. See chart below.
Additionally, participants gave overall feedback regarding the
sessions’ content. Some respondents noted that the contents
were excellent and superb, the instructions should be patiently
detailed, distance and other issues were barriers to
learning.
Most participants stated that they acquired new skills and gained useful experience, especially editing Wikipedia. Wikidata and Wikicommons; gained knowledge of how to add pronunciation audio to Wikidata items; respondents also indicated the translation skill acquired; others loved the experience of contributing and editing Wikimedia projects, some have tried to edit on their own but was not successfully, this event served as a good learning platform; equally important is the language diversity of Wikimedia project, giving opportunity for users to contribute to their native languages (Igbo). Other key takeaways to some participants were the content, contest, and refreshments.
In conclusion, this event was a period of learning for
facilitators and participants. Participants appreciated the
experience they had as editors, they were grateful to Wikimedia
Foundation for inclusion and diversity; also the facilitators and
experienced Wikimedians for teaching effectively. For follow-up and
more practice, these participants were added to the Igbo
Wikimedians User Group, librarians amongst them were encouraged
to join the Ig Wiki
Librarians Hub, also, others joined the Ig Wikidata
Hub and Ig Wiki Commons Hub respectively.
The Wiki Loves Monuments team just published the 2022 DEI report. In response to what the team shared and learned, the Taiwan local campaign would like to share our experience with everyone.
There have been 7 Wiki Loves Monuments held in Taiwan: first in 2013, and from 2017 ever since to 2022. The Taiwanese community organizers had tried several formats of the campaign, such as the composition of the COT, composition of the jury, and evaluation methods, as well as different types of partnerships. Many changes made were related to what the 2022 DEI report had pointed out. This is why we like to share our experiences.
First, in the recent campaigns, the 5 people jury team was composed of specific backgrounds: 2 professional photographers, 2 monument & heritage researchers, and 1 community representative. This is not a perfect composition, but it is beneficial to a more multi-aspects evaluation process through experts from different backgrounds. Heritage researchers can identify the detail of some images which have more historical value, the Wikimedia community representative will consider if the images are clear enough to elaborate certain knowledge or if the image content was taken lesser in the past.
This composition could avoid the problem of over-emphasizing the aesthetics that were pointed out in the DEI report. It is obvious that, from 2020 to 2022, there are at least one image about “ruins buildings“ that obviously under maintenance can goes in the top ten. These buildings were being shotted and were recognized with prize. Each year, when we announced the top ten photos, we will also report the juries’ comments and point out the highlight of these winning photos. It gave these types of the monument a reason not be kicked out by other participants.
Furthermore, different types of partnerships may strengthen diversity too. For example, in 2021, we collaborated with “Hakka Public Communication Foundation”(客家公共傳播基金會) and set up a special award for Hakka heritages. We also organized Hakka photography workshop. In 2022, we collaborated with “The Cultural Association of Gangshan Military Dependents’ Village (岡山眷村文化協會) ”and set up a “Residential heritage” special award, also organized the “Military Dependents’ Village” photography workshop. These two partnerships sequentially attracted the Hakkanien and Chinese immigrants from 1949. They are considered as the second and third large population group in Taiwan. Those partners were included in the discussion of the campaign rules, propagandas, and event format, hence fewer negative voices from the community. This problem was also pointed out by the DEI report.
The content of the 2022 DEI reported by the Wiki Loves Monuments team is highly valued and opens up more conversation. We hope the reflection from Taiwan would encourage all the campaign organizers.
On November 26, 2022, Dr. Sae Kitamura (a.k.a. Saebou), Student Wikipedian Community in Waseda Uni Tokyo and Toumon Wikipedian Club Japan held a Malaysia themed editathon at Tokyo Univeristy of Foreign Studies (TUFS). This article describe the details.
On November 2022, Wikipedians in Malaysia decided to hold an editathon themed on Japan in commemoration of Wikipedia Asia Month and the 40 anniversary of Look East Policy. Dr. Kitamura heard about this event and also decided to hold similar editathon in Japan in corporation with a staff of TUFS.
TUFS students and veteran Wikipedians joined this editathon. Moreover, the members of Student Wikipedian Community in Waseda Uni Tokyo and Toumon Wikipedian Club Japan also joined as support staff. To prevent the spread of the coronavirus infection, this editathon was held with limited numbers of people.
This editathon is one of the events which Ministry of Foreign Affairs of Japan supported. It is introduced on the web page of Embassy of Japan in Malaysia.
| 13:00-13:05 | Opening |
| 13:05-13:30 | Wikipedia Lecture by Dr. Kitamura |
| 13:30-13:45 | Preparation |
| 13:45-17:30 | Research and Edit |
| 17:30-18:00 | Wrap up |
Firstly, Dr. Kitamura had a lecture on Wikipedia editing. She introduced Five pillars and policies. She also explained that the number of female Wikipedian is small and that Wikipedia articles related to Asia are not rich in content.
After the lecture, participants were divided into beginner team and veteran team.
Dr. Kitamura and I supported beginners. It almost went well, but there were some troubles about copying. When they tried to properly copy and paste source code to their draft (see [[Wikipedia:Copying within Wikipedia]]), it was blocked.
Veteran Wikipedians edited articles using books they brought. When they had a question about Malay language or the culture of Malaysia, they asked the researcher who joined this event.
Students of TUFS often went to the library to borrow the books they can use for Wikipedia. When participants got tired to edit, they enjoyed Malaysian board game “Congkak.”
Finally, participants shared the articles they had edited and what they felt after editing.
Some participants made new articles and the others (including an Wikipadian who joined online) added sentences with source. All the article edited at this event are listed on the project page on Wikipedia.
A beginner said that though it takes a lot of time to edit Wikipedia articles, it feels very rewarding. A veteran Wikipedian also said that if there was something they didn’t understand, it was reassuring to be able to immediately confirm it with the researcher.
This editathon was meaningful. For Wikipedia editor, it was an opportunity to do outreach, and for Malaysia and TUFS, it was an opportunity to showcase their own appeal.
This event also revealed some issues in Japanese Wikipedia. We found that articles on Malaysia in Japanese Wikipedia are not of high quality, and some of them have problems with place names and so on.
I believes that exchanges between universities and Wikipedia editors are beneficial to both parties. I hope that there will be more opportunities in the future for both parties to interact under a specific theme.
This post is the first part of a three-part series on proxy blocks, covering an introduction and history.
Open proxies – shared IP addresses accessible anywhere through free or paid services – have been blocked on Wikimedia projects for over 16 years.
Since its inception the policy has remained unchanged, with growing costs to accessibility and equity that insofar has not seen widespread discussion.
In early 2004, the question of anonymizing proxies was discussed on the English Wikipedia’s mailing list, with few objections to prohibiting their usage.
Arguments in favor noted that proxies were often used by vandals to evade blocks placed on their previous IP addresses and accounts. (On Wikimedia projects, accounts and IP addresses (or ranges of IP addresses) can be blocked to prevent editing from them; this is the primary anti-abuse tool that administrators have.)
Arguments against the proposal discussed the necessity of users subject to censorship, specifically China’s “Great Firewall”, to use proxies to safely access the internet.
Consensus developed, among the dozen or so participants on the mailing list thread, to block editing from open proxies. This was enacted on the English Wikipedia, and in 2006 was created as a global policy, enshrined on Meta-Wiki’s “No open proxies” page.
In the 18 years since that first discussion, the dynamics of open proxies and the problems associated with blocking them have changed significantly.
For the purpose of Wikimedia blocks, a proxy is generally anything that allows a user to connect to Wikimedia projects through an IP address other than that assigned to them by their Internet Service Provider (ISP). Instead of a usual residential or cellular IP address, which has some degree of consistency and is often based on location, Wikimedia servers see the IP address of the proxy service.
Today, various types of proxy connections, and connections often affected by proxy blocks, exist:
*The latter two are not technically proxies, but are often caught up in proxy-type blocks.
T-Mobile IPs present a problem very similar to proxies, where any customer can switch their cellular connection off and back on again, and be assigned a new IP on a different range. This allows users to easily evade a block placed on a previous IP address. All T-Mobile ranges are blocked for this reason.
CGNAT IPs suffer from an opposite issue; instead of one person having access to hundreds of IP ranges, hundreds of people have access to only one IP address. Because there are so many people on very few IP addresses, if one person vandalizes or connects using a peer-to-peer proxy, this can result in the IPs being blocked, affecting everyone who was connecting through that IP.
These are reflected here:
These types of connections vary in ease of identification, from traditional VPNs almost always being evident in IP lookups, to peer-to-peer proxies being difficult to distinguish from normal residential connections.
The predominant reasons for blocking proxies have not changed since the initial discussion in 2004: their anonymizing effect prevents IP-based anti-abuse systems from working.
When someone connects to a proxy, they funnel their internet traffic through the servers of that proxy service. This means that Wikimedia servers see the IP address of that proxy service rather than the IP address assigned to them by their ISP.
Most proxy services provide dozens or hundreds of available connections, often in different countries (to evade geo-blocked content), to their customers. This is opposed to most residential ISPs, who assign singular IPs or relatively narrow ranges to their customers.
For example, my ISP assigns me a single IPv6 /64 subnet, which has been static for roughly 4 months. Searching it through Bullseye, a community-developed IP lookup tool, returns information about roughly my location, my ISP, and range. Were I to turn on a VPN, I could connect to servers in any region or country; and if one IP is blocked, I can switch to another. This makes static identification, and thus effective anti-abuse blocks, next to impossible for people using proxies.
Bad actors can use and rotate between open proxies to prevent identification of sockpuppets, evade IP address and range blocks, avoid scrutiny of contentious edits, or harass good faith editors. Where some websites may rely on cookies and other methods of tracking, MediaWiki anti-abuse tools nearly exclusively rely on IP addresses. Blocking open proxies is a necessity for functioning anti-abuse mechanisms on Wikimedia projects.
Though standard VPNs/proxies can be used to evade anti-abuse mechanisms, it is easy to identify when someone is using one, and to prevent editing from those IP ranges. Peer-to-peer proxies, however, evade this identification by funneling a user’s traffic through another user’s connection. This means that someone using a proxy in one country can appear to be connecting from a residential IP in another country. The next post in this series discusses the responses to the increasing prevalence of peer-to-peer proxies.
What if instead of telling students not to cite Wikipedia, you had them write it? Kaylea Champion has experienced the “Wikipedia assignment” as both student and teacher, and to rousing success. Her PhD coursework has included Wikipedia editing and her students nominated her for a graduate teaching award for her work supporting them in completing the Wikipedia assignment!
“Writing for Wikipedia as part of a class challenged me to write for a general audience about the sometimes abstract and complex topics we were discussing so intensely in seminar,” said Kaylea, who was first exposed to the assignment in Benjamin Mako Hill and Ralina Joseph’s Communication Theory course at the University of Washington a few years back. Now, as a graduate teaching assistant for one of Professor Hill’s undergraduate courses, she’s bringing her own passion to it.
“I never thought about the pedagogical potential of the platform until I started my PhD. Instead of locking away my synthesis efforts in a paper no one but my instructors would read, the Wikipedia assignment pushed me to address the public.”
Although Kaylea had made a few modest edits to Wikipedia before, the assignment lit a fire for her. She even passed the part of her PhD qualifying exams on Communication Theory by rewriting the Wikipedia article on Communication Theory! (Additional students—supported by Wiki Education’s Wikipedia Student Program but from different universities—have followed in Kaylea’s footsteps and made edits to the article since).
“Knowing the audience I would reach, I worked much harder on every sentence than I would on an ordinary class essay. That experience catalyzed my thinking as a scholar about the importance—and challenge—of engaging with the general public about our work. When my article draft went live and other contributors pitched in and made it better, I was thrilled—and it turned me from a casual contributor into a committed Wikipedian.”
As a teaching assistant, Kaylea had the chance to pass along some of these lessons. In doing so, she utilized Wiki Education’s free teaching tools and platform to facilitate the assignment.
“Accomplishing my teaching goals through Wiki Education let me put into practice the kind of teaching that research has told us is most effective: challenging, meaningful, personal, project-based assignments, with both high standards and high levels of support.”
Students worked on a wide range of topics, including the USDA’s current nutrition guide and the potential harmful effects of quinine in tonic water.
Together, those two pages have received 84,520 pageviews on Wikipedia since the class in the first quarter of 2022. The results of the course were not only great for Wikipedia’s readership, but students loved Kaylea’s approach.
A communications major in the course liked that he could customize the assignment to fit his interests. He worked on Wikipedia’s article about Manchester, Washington, adding historical context, recent census data, and education information.
“Kaylea helped me work out how to approach the project in order to satisfy both the actual assignment and the research question I was interested in,” the student shared. “Her contribution to the course was invaluable—she helped me not only learn the course matter but also apply it in practical work.”
Students admired Kaylea for her compassion and focused support. “Kaylea was the best TA I have ever had during my education time at UW,” said a fourth-year communication major also in the course. The students even nominated Kaylea for the Department of Communication’s Graduate Teaching Award, which she received in June 2022! This kind of support from students is particularly meaningful because recent years have been an extremely difficult time for teaching. Kaylea acknowledged the term wasn’t easy.
“We tackled a wide range of theories and case studies over the course of 10 weeks, and the ongoing pandemic forced us to interact primarily online. At the same time, many students were facing exceptional personal challenges: illness, the deaths of family members due to Covid-19, and the isolation of lockdown. They persevered through the quarter, writing and expanding articles on topics they cared about, sharpening their critical thinking skills, and grappling with questions of epistemology, censorship, and bias—all while making real contributions to public knowledge.”
“Teaching with Wiki Education’s tools helped me to activate my own potential as a teacher. I am so proud of what my students accomplished, and I was honored to receive our department’s award for outstanding teaching this year.”
The Wikipedia assignment works for courses across all disciplines. Sign up for Wiki Education‘s free tools and assignment templates by December 16th to ensure your spot for your spring term.
By Dr Richard Nevell, Programme Coordinator for Wikimedia UK
I’m a big fan of the Archaeology Data Service (ADS). Its online library is packed with digitised articles, books, and reports. Looking in from the outside I have seen its content grow and become ever more useful.
The ADS hosts a lot of data about people, places, and publications. Wikidata is an open source database in the Wikimedia network of websites; founded in 2012 it has grown to include a huge amount of information. Both sites continue to grow, and there are some points where they can complement each other.
Back in 2020, I got in touch with the ADS to ask if they could share a spreadsheet of their identifiers for individuals so that I could add them to Wikidata. Adding ADS identifiers to Wikidata entries on individual archaeologists means it would be possible to find out what information Wikidata has on these people. For the ADS, it means they can import other identifiers such as Open Researcher and Contributor IDs (ORCIDs – maintained by researchers) and International Standard Name Identifier (ISNIs – used by libraries and archives). The process of reconciling the two datasets would help with the quality of both, highlighting inconsistencies or duplications.
As a (slightly late) celebration of Wikidata’s 10th birthday, below I’ve explained some of the ways in which Wikidata has helped illuminate the ADS, and the process I followed to add the information.
If you’ve not come across Wikidata before, the obvious question is how is it meant to be used? The website is designed to be machine readable, so rather than containing information in prose it’s broken down into discrete ‘statements’. This means the information in Wikidata can be picked up by the likes of Google, and Wikidata can be a centralised hub for standardised information for the Wikimedia projects.
Wikipedia is available in 300+ languages which presents a maintenance challenge. For example, when a census is released Wikipedia editors have to update thousands of pages; if the data is stored centrally that makes the process dramatically easier. That’s just one application of Wikidata, other possible uses include creating interactive timelines, like this one showing folks in the ADS with a known birth and death date, and automating brief summaries of topics.
Whereas Wikipedia has articles, Wikidata has ‘items’. Each one is about an individual topic. For this blog post, that means a person can have an item about them, and a publication can have an item. They can then be linked together. Wikidata’s inclusion criteria are broader than Wikipedia’s, so you don’t need to have a Wikipedia article to end up in Wikidata. Crucially, people with Wikipedia pages will have more detailed items in Wikidata. Just take a look at the item for Ian Hodder (who has Wikipedia articles about him in 19 languages) compared to the one for Peter Arrowsmith (no Wikipedia page).
The ADS hosts scans of reports from a host of archaeological service providers in the UK and articles in county journals. Even when documents aren’t available, they still host some meta-data about the publications. As a result their data leans heavily towards British archaeologists.
You can see that when querying Wikidata’s country of citizenship data. The above buddle chart shows the citizenship for people in the ADS with an article on the English Wikipedia. 733 people are citizens of the United Kingdom, and 506 are citizens of the United Kingdom of Great Britain and Ireland, though there is undoubtedly a lot of overlap. The next most common countries are the USA (115), Great Britain (65), and France (43) [full results]. You can look more widely to include anyone in the ADS dataset on Wikidata, even if they don’t have an article about them. The pattern is very similar, with the same five countries at the top.
Wikipedia’s content has a gender gap: as of 24th October 2022 the English Wikipedia has 1.9 million biographies and 19.36% are about women. This is based on what is recorded in Wikidata – it’s all interconnected. Narrowing it down to archaeologists, the English Wikipedia has 5,129 biographies and 22.15% are about women. So archaeology isn’t doing too badly in the context of English Wikipedia. 1,869 of these archaeologists with biographies on the English Wikipedia have an identifier in the ADS and 22.79% are about women. The actual number will increase over time as further matches are made and new articles are created, but this likely represents the majority of the matches that can currently be made.
If we widen the search to include all the people in the ADS with a Wikidata item, 4,641 have a gender and 24.09% are female.
Given the UK focus of the dataset, it’s not surprising that the ten most common places of education from people in the ADS (where Wikidata has information, for people with articles in English) are all in the UK. You have to go down to 18th to find a university from outside the UK (Harvard).
Where people work is heavily skewed towards universities. Looking at just people in the ADS who have articles on the English Wikipedia, universities account for nineteen out of the twenty most common workplaces. Archaeologists in universities are more likely to end up with Wikipedia articles than folks in commercial archaeology or the museum sector. If we drop the requirement of having an article on the English Wikipedia, the results have more variety. Because people outside academia are less likely to have articles, the data available for people in commercial archaeology will be much poorer.
The ADS doesn’t just have entries for archaeologists. Historians, geneticists, and numismatists all appear in their dataset. The ADS even has an entry for Billy Bragg. Yes, that Billy Bragg. I double checked just in case. So aside from archaeologists, what professions do people in the ADS dataset have? For this bit, let’s look at everyone in the ADS with a Wikidata entry, not just people with articles on the English Wikipedia. It’s not surprising that a historian is the most common job amongst the dataset.
Back in 2020 the ADS provided a spreadsheet of their data, with columns for given name, surname, initials, date of birth, date of death, ORCIDs, ISNI, and the ID in the ADS database. For most people in the data set, it was a matter of name and ID in the ADS database.
The first step was adding this data to a tool called Mix’n’match. It’s a staging area before Wikidata, where information can be matched to what already exists. The idea is to add a new ID to Wikidata items where they already exist and to create new items where they don’t exist yet. If in doubt, create a new item in Wikidata. They can always be merged later if it turns out there is a duplicate.
Mix’n’match does some automated matching based on IDs such as ORCIDs or ISNIs, and then suggests some possible matches based on names and information such as dates of birth and death.
With more than 55,000 people in the spreadsheet, there is a lot to get through. There were some 1,500 matches that were low-hanging fruit but it has taken more than two years to get nearly 7,000 matches. The approach has been to use Mix’n’match to confirm suggested matches and to manually add ADS IDs to Wikidata items; the latter is done when I’m confident I’ve found a match. The Mix’n’match suggestions were very, well, mixed so I came up with some custom searches to try to narrow things down. I looked for people who published in the field of prehistoric archaeology but who don’t have an ADS ID, antiquarians with no ADS ID, French archaeologists with no ADS ID, people who published in the Sussex Archaeological Collections with no ADS ID (and other journals with an extensive back catalogue on the ADS), and variations thereof. As it turns out, there are quite a few of each who don’t appear to be in the ADS.
Soon, there will be the decision about what to do with the remainder. Should 48,000 names be imported to Wikidata with little more than an ADS ID and we trust that they may be enriched over time? It’s a possibility, but I’ve not considered it much yet. It has the most value for Wikidata where it can be linked to another item. For now at least, the ADS have a bunch of new ORCIDs, INSIs, and Wikidata IDs they can enrich their site with, and a few entries they may want to merge.
The more information there is in Wikidata – the more sourced statements about where people went to school or university, where they worked, and so on – the more useful it becomes, and you can help add information. New to Wikidata? The University of Edinburgh have a short introductory video to get you started.
The post The Archaeology Data Service and Wikidata appeared first on WMUK.
One accurate measurement is worth a thousand expert opinions
– Grace Hopper
As I meandered around our new house, it was apparent some rooms were sweltering, others were freezing, and the thermostat was lying about everything.
I could feel it.
But I felt compelled to measure it. I was struck by the need to know:
And I fulfilled my weird compulsion with a few simple tools:
I have a handful of AcuRite sensors sprinkled throughout my house.
These sensors are $16 today, but I bought mine around 2017 for $12 each at Home Depot.
I know I could cobble together a cheaper temperature sensor:
| SHT30 temperature/humidity sensor | $1 |
| WeMos esp8266 | $5 |
| D1Mini OLED screen | $2 |
| Shipping | ~$2 |
| A month of waiting for shipping | priceless |
So for like $10 + solder + a weekend fiddling, you could make a craptastic internet-equipped temperature/humidity sensor.
But I dreaded building it.
Tinkering with electronic doodads is a fun hobby. But I just wanted something cheapish that would work.
And the AcuRites work.
Plus, the AcuRites work forever on a couple AAAs because they eschew power-hungry wifi in favor of squawking data on 433 MHz.
Even though 433.92 MHz sits squarely in the 70cm ham band, tons of electronic junk spews signals on that frequency.
And with a $25 USB dongle and free software, it’s easy to decode messages chirped out by your AcuRite temperature sensors.
So far, this project had been cheap and simple. But the next step, gathering the data into a time-series database, required more fiddling than I’d expected.
It was a pain to get rtl_433 data into Home
Assistant.
Maybe I’m missing something. But I ended up with a more complex system than I wanted:
rtl_433 -F syslog:127.0.0.1:1433After endless fiddling, the relay has an uptime measured in months—it’s stable.
From there, pushing data to Home Assistant, exposing it via the Prometheus plugin, and graphing it with Grafana was a breeze.
Given all this work I’m happy to confirm what I’d long suspected: some rooms in my house are hot while others are cold.
Our team has started to plan our goals for 2023. This has been a great opportunity to wear my systems analyst hat. Traditionally, we’re taught to see the world through the lenses of reductionism thinking. That paradigm defends that the world can be split in small parts, and that analyzing those small parts are the simplest way to understand what we comprehend as the whole. This rationalization and compartmentalization of makes it difficult to visualize relationships and the effect those relationships have on the whole.
College is an important time in a student’s life. Many are figuring out what they think of the world and their place in it, and considering their future career. Classwork that gives students autonomy, empowers them to take part in important conversations on a global scale, and gives them a voice in their own schooling really resonates.
Madeline Utter had such an experience in Elizabeth Guffey’s “Performance and Disability Studies” course at UCLA last term. Students discussed the presentation and treatment of disability within film, theater, and performance. Then, Professor Guffey assigned them to choose a Wikipedia article about a film, TV show, or play they discussed in class and make sure it represented the latest disability research.
Madeline and a partner chose the Wikipedia article about the 1988 film Rain Man, which receives more than 2,000 page views a day. After doing a close reading of the article to figure out where they might rewrite or add to content, they noticed an important omission.
“At times, the film erroneously portrayed Savant Syndrome and autism spectrum disorder in order to advance the film’s agenda,” Madeline says. “Unfortunately, this misrepresentation has led to widespread, incorrect beliefs about both Savant Syndrome and autism spectrum disorder. While the film was revolutionary for its time in portraying developmental disability on screen, it left many holes and potentially caused false ideas about developmental disabilities to spread among viewers.”
So the students decided to correct the public record. They added information to the Wikipedia article about screenwriter Barry Morrow’s inspiration for the film’s main character, Raymond Babbitt, as well as Morrow’s unawareness of the intricacies of the neurodivergent conditions he was portraying. The students also detailed some of Dustin Hoffman’s decisions in playing the character of Raymond Babbitt that have led to public misunderstanding around the connection between autism spectrum disorder and Savant Syndrome. Readers of the article will also find a new section detailing the movie’s legacy, namely that funding for autism research and autism diagnoses increased after its release. The article has now been viewed 465,000 times since the students made these changes.
“I feel that this assignment was more well-rounded and timely than a traditional assignment,” Madeline reflected. “It forced us as students to take a critical look at many of the films and TV shows that shaped America through a lens of disability representation, which isn’t something you get to do for every assignment.”
Madeline graduated in June and says she plans to take what she learned from the assignment into her career in Los Angeles’ film and television industry.
“I feel that I learned many skills from writing this Wikipedia article that I’m already applying in my career. For example, looking at projects through a critical eye, analyzing material through a specific lens (in this case, disability), and applying those ideas to something that can inform others in the future.”
Join the movement and incorporate the Wikipedia assignment into your 2023 course. Visit teach.wikiedu.org and register by December 16th to ensure your spot. We look forward to supporting you and your students.
The Wikimedia Foundation, the non-profit that hosts and provides other support for Wikipedia and its sibling projects, has been under fire recently for the messaging it uses in the infamous donation banners and the disconnect with how that funding is used. These criticisms are not particularly new, but the tension rose to a new level last month with a "Request for comment" on the English Wikipedia on whether the planned fundraising campaign banners were appropriate.
I didn't end up participating in the RfC because it coincided with a heavy travel period for me and I just didn't have time to read through it all. I also don't find arguing about random parts of the WMF's fundraising strategy to be super useful, I think it's all part of a larger picture on how the WMF allocates resources, and whether those goals and projects are inline with what editors want. (There is also the question of whether editors solely should be deciding what the WMF works on, or whether someone needs to speak up for the silent readers. So like I said, much larger picture.) I used to work at the WMF, and I'd like to think that most of the work I did was valuable and that my compensation was appropriate. A bunch of my former coworkers and friends still work there and I do think that the work they do is also valuable, and they should be compensated appropriately for it.
Anyways, there is one point I want to make, and that's the title of this post: the best way to support Wikipedia is with your time. Yes, if you give $5 or whatever to the Wikimedia Foundation, it's a reasonable investment in humanity's collective future...and there are way worse ways to spend $5. But if you give 30 minutes of your time to Wikipedia by contributing to articles, that's worth significantly more than any cash donation!
You can look through the English Wikipedia's backlog for yourself. There are currently 442,000+ articles tagged as needing more references, 98,000+ that need geographic coordinates, etc. This doesn't even include articles that have fallen out of date and need someone to update them. Over the weekend I was looking up demographics on various U.S. cities and noticed that the majority of articles I looked at were still using 2010 census data instead of the newer 2020 dataset! It was frustrating.
One major criticism of the fundraising banners tends to be that they say your money is going to supporting Wikipedia, when it's actually going to a non-profit that does support Wikipedia[1], in addition to doing some other things.
So if you want to be sure your contribution is going directly to Wikipedia, donate your time. You will see firsthand where your efforts go, and it'll be way more valuable than any financial donation.
P.S. Editing Wikipedia can become addicting; you've been warned.
[1] Critics tend to downplay how much money is actually needed to support Wikipedia on a regular basis. And the WMF has done itself no favors by being less and less transparent over the years on what it's up to!
| previous | 2022, week 48 (Monday 28 November 2022) | next |
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
Changes later this week
The new version of MediaWiki will be on
test wikis and MediaWiki.org from 29 November. It will be on
non-Wikipedia wikis and some Wikipedias from 30 November. It will
be on all wikis from 1 December (calendar). Some wikis will be in read-only
for a few minutes because of a switch of their main database. It
will be performed on 29 November at 07:00 UTC (targeted
wikis) and on 1 December at 07:00 UTC (targeted
wikis).Future changes
How media is structured in the
parser's HTML output will change early next week at group1
wikis (but not Wikimedia Commons or Meta-Wiki). This change
improves the accessibility of content, and makes it easier to write
related CSS. You may need to update your site-CSS, or userscripts
and gadgets. There are
details on what code to check, how to update the code, and where to
report any related problems. [6]Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
the short of it is: they’re cool for appending notes from automated systems (like ticket or build systems) but not really for having interactive conversations with other developers (at least not yet)
– Scott Chacon, GitHub.blog, Aug. 2010
Git notes are almost a secret.
They’re buried by their own distressing usability.
But git notes are continually rediscovered by engineers trying to stash metadata inside git.
Git notes are powerful tools. And they could solve so many problems—if only they were better known and easier to use.
A common use of git notes is tacking metadata onto commits.
Once a commit cements itself in git’s history—that’s it. It’s impossible to amend a commit message buried deep in a repo’s log1.
But git notes enable you to amend new information about old commits in a special namespace. And they’re capable of so much more.
Notes stow metadata about anything tracked by git—any object: commits, blobs, and trees. All without futzing with the object itself.
You add notes to the latest commit in a repo like this:
git notes add -m 'Acked-by: <tyler@tylercipriani.com>'And then it shows up in git log:
commit 1ef8b30ab7fc218ccc85c9a6411b1d2dd2925a16
Author: Tyler Cipriani <thcipriani@gmail.com>
Date: Thu Nov 17 16:51:43 2022 -0700
Initial commit
Notes:
Acked-by: <tyler@tylercipriani.com>The git project itself offers an example of git notes in the wild. They link each commit to its discussion on their mailing list.
For example:
commit 00f09d0e4b1826ee0519ea64e919515032966450
Author: <redacted>
Date: Thu Jan 28 02:05:55 2010 +0100
bash: support 'git notes' and its subcommands
...
Notes (amlog):
Message-Id: <1264640755-22447-1-git-send-email-szeder@ira.uka.de>This commit’s notes point intrepid users to the thread where this patch was discussed.
Other folks are using notes for things like:
Here is a plea for all forges: make code review metadata available offline, inside git.
The reviewnotes plugin for Gerrit2 is an example of how to do this well. It makes it easy to see who reviewed code in git log:
git fetch origin refs/notes/review:refs/notes/review
git log --show-notes=reviewThe command above shows me all the standard git log info alongside information about what tests ran and who reviewed the code. All without forcing me into my browser.
commit d1d17908d2a97f057887a4afbd99f6c40be56849
Author: User <user@example.com>
Date: Sun Mar 27 18:10:51 2022 +0200
Change the thing
Notes (review):
Verified+1: SonarQube Bot
Verified+2: jenkins-bot
Code-Review+2: Reviewer Human <reviewerhuman@wikimedia.org>
Submitted-by: jenkins-bot
Submitted-at: Tue, 14 Jun 2022 21:59:58 +0000
Reviewed-on: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/774005
Project: mediawiki/core
Branch: refs/heads/masterMotivated hackers can knead and extend git notes. Using them as distributed storage for any madcap idea.
Someone at Google cobbled together a full-on code review system teetering atop git notes called git-appraise.
Its authors have declared it a “fully distributed code review”—independent of GitHub, GitLab, or any other code forge.
This system lets you:
And you can do all this from your local computer, even if GitHub is down.
Plus, it’s equipped with an affectedly unaesthetic web interface, if that’s your thing.
Git notes are a pain to use.
And GitHub opted to stop displaying commit notes in 2014 without much explanation.
For commits, you can make viewing and adding notes easier using fancy options in your gitconfig3. But for storing notes about blobs or trees? Forget it. You’d need to be comfortable rooting around in git’s plumbing first.
So, for now: git notes are relegated to obscurity. Forever hamstrung by an obscure and clunky interface and limited adoption—I often forget they’re there.
Git is a distributed code review system. But much of the value of git repos ends up locked into forges, like GitHub.
Git notes are a path toward an alternative.
Git distributes the history of a piece of code. Git notes could make it possible to distribute the history of an entire project.
Without having to endure the perils of a force push, anyway.↩︎
The code review system used for a couple of bigish projects.↩︎
Noteably by automagically fetching notes and displaying them in
git log via:
$ git config --add \
remote.origin.fetch \
'+refs/notes/*:refs/notes/*'
$ git config \
notes.displayRef \
'refs/notes/*'15/11/2022-21/11/2022
A Braille & ASCII world map renderer [1] | © Michael Straßburger | map data © OpenStreetMap contributors
addr:housenumber have been incorrectly tagged as
name.office=power_utility to replace
office=energy_supplier for tagging the office of a
power utility company.emergency=lifeboat_station for tagging the
buildings and base areas of those groups that are dedicated to the
rescue of vessels and sailors in distress.fountain:design=*, to specify what type of
fountain an amenity=fountain is, until Monday 5
December.
►
on how this challenge, started by a Finnish geographer in 2019, has
become a worldwide event.
@andrewdc_nz * For All
Moon Time | Andrew Tyrrell * Platonic
Earth @SouthArrowMaps@mapstodon.space |
►
that InDrive.Tech launched a mapping campaign to map small
settlements in Kazakhstan from 16 to 23 November, coinciding with
the International Geographic Information System Days.| Where | What | Online | When | Country |
|---|---|---|---|---|
| Bremen | Bremer Mappertreffen (Online) |
2022-11-28 | |
|
| Natal | Mapeamento de Comunidades no Brasil / Mapping Communities in
Brazil. |
2022-11-29 – 2022-11-30 | |
|
| Daerah Khusus Ibukota Jakarta | OSMGeoWeek Indonesia 2022 |
2022-11-30 |  |
|
| Łódź | UN Mappers and OSM Poland Mapaton |
2022-11-30 |  |
|
| Düsseldorf | Düsseldorfer OpenStreetMap-Treffen |
✓ | 2022-11-30 | |
| Budapest | OSM Weaving: Remote help, Corvin Mall preparation, Mapvent of
December (online) |
2022-12-01 | |
|
| Cojata | Reunatón Latam |
2022-12-03 | |
|
| 加古川市 | State of the Map Japan 2022 in Kakogawa |
2022-12-03 | |
|
| 京都市 |
京都！街歩き！マッピングパーティ：第34回
渉成園 |
2022-12-04 | |
|
| 臺北市 | OpenStreetMap x Wikidata 月聚會 #47 |
2022-12-05 | |
|
| OSMF Engineering Working Group meeting |
2022-12-05 | |||
| Monthly MapRoulette Community Meeting |
2022-12-06 | |||
| City of Westminster | Missing Maps London Mapathon |
2022-12-06 | |
|
| San Jose | South Bay Map Night |
✓ | 2022-12-07 | |
| Berlin | OSM-Verkehrswende #42 (Online) |
✓ | 2022-12-06 | |
| HOT Tasking Manager Monthly Meet Up |
2022-12-07 | |||
| Brest | Mapathon en partenariat avec Infini |
2022-12-07 | |
|
| Rio de Janeiro | Workshop Mapeamento Participativo e Cartografia Social 2022 /
Participatory Mapping and Social Cartography Workshop 2022 |
2022-12-07 – 2022-12-08 | |
|
| Stuttgart | Stuttgarter Stammtisch |
2022-12-07 | |
|
| München | Mapping Party: Christmas Edition |
2022-12-08 | |
|
| München | Münchner OSM-Treffen |
2022-12-08 | |
|
| Budapest | Corvin Mall in-person survey, Grund: NextCloud Maps,
StreetComplete, Snap, IPv6 |
2022-12-09 | |
|
| Zürich | OSM-Stammtisch |
2022-12-09 | |
|
| Berlin | 174. Berlin-Brandenburg OpenStreetMap Stammtisch (hybrid
– Test für FOSSGIS 2023) |
2022-12-09 | |
|
| [Online] 16th Annual General Meeting of the OpenStreetMap
Foundation |
2022-12-10 | |||
| København | OSMmapperCPH |
2022-12-11 | |
|
| City of Nottingham | OSM East Midlands/Nottingham meetup (online) |
✓ | 2022-12-13 | |
| Rio de Janeiro | Workshop Mapeamento Participativo e Cartografia Social 2022 /
Participatory Mapping and Social Cartography Workshop 2022 |
2022-12-14 – 2022-12-15 | |
|
| Salt Lake City | OSM Utah Monthly Meetup |
2022-12-15 | |
|
| Michigan Meetup |
2022-12-15 | |||
| Stainach-Pürgg | 7. Virtueller OpenStreetMap Stammtisch Österreich |
2022-12-14 | |
|
| Toulouse | Réunion du groupe local |
2022-12-17 | |
Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there,
will appear in weeklyOSM.
This weeklyOSM was
produced by Elizabete, PierZen, Sammyhawkrad,
Strubbl,
TheSwavu,
derFred,
erenozdemir,
rtnf.
We welcome link suggestions for the next issue via this
form and look forward to your contributions.
Mediawiki developers, have you ever thought, “I wish I could deploy my own code for Mediawiki”? Now you can! More deploys! More fun!
Next time you want to get some code deployed, why not try scap backport?
scap backport is one command that will +2 your patch, deploy to mwdebug and wait for your approval, and finally sync to all servers. You only need to provide the change number or gerrit url of your change.
You can run scap backport on patches that have already merged, or re-run scap backport if you decided to cancel in the middle of a run. scap backport can also handle multiple patches at a time. After all the patches have been merged, they’ll be deployed all together. scap backport will confirm that your patches are deployable before merging, and double check no extra patches have sneaked into your deployment.
And if your code didn’t work out, don’t worry, there’s scap backport —revert, which will create a revert patch, send it to Gerrit, and run all steps of scap backport to revert your work. You’re offered the choice to give a reason for revert, which will show up in the commit message. Just be aware that you'll need to wait for tests to run and your code to merge before it gets synced, so in an emergency this might not be the best option.
You can also list available backports or reverts using the —list flag!
If you'd like some guidance on deploying backports, please sign up here to join us for backport training, which happens once a week on Thursday during the UTC late backport window!
For comparison, the previous way to backport would require the user to enter the following commands on the deployment host:
cd /srv/mediawiki-staging/php-<version>
git status
git fetch
git log -p HEAD..@{u}
git rebaseThen, if there were changes to an extension: git submodule update
[extensions|skins]/<name>
Then, log in to mwdebug and run scap pull
Then, back on the deployment host: scap sync-file php-<version>/<path
to file> 'Backport: [[gerrit:<change no>|<subject>
(<bug no>)]]' for each changed file
List backports
scap backport --list
Backport change(s)
scap backport 1234
scap backport
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1234
scap backport 1234 5678
Merge but do not sync
scap backport --stop-before-sync
1234
List revertable changes
scap backport --revert
--list
Revert change(s)
scap backport --revert
1234
scap backport --revert 1234
5678
That's all for now, and happy backporting!
Are you looking for an assignment where students:
If you answered yes to any of the above, hear what Hannah Yang, a third-year student at Northwestern, has to say about the Wikipedia assignment. Through Aaron Shaw’s spring course, Hannah answered the following question on a worldwide stage: “What does it mean to design with inclusivity in mind?” What began as a class research project has become a potential blueprint for anyone with an internet connection and an interest in design.
Hannah chose to overhaul the Wikipedia article about inclusive design, the process by which a designer considers a diversity of users and user experiences when developing a project. It’s a topic that has gained some traction in recent years, which was both exciting and daunting for Hannah as she considered making edits.
“I really wanted to provide a meaningful level of detail and clarity regarding what inclusive design looks like–that is, how it could be put into practice,” Hannah says. She was also particularly interested in distinguishing “inclusive design” from accessible or universal design. “I find that these three ideas are often used interchangeably, but I think that inclusive design is a broader, and perhaps more powerful philosophy, especially when applied not just to products, but also to policies and infrastructure. I think that a crucial idea behind inclusive design is that when a design is inclusive, the experience is better for everyone.”
In the new and improved article, Hannah has made the distinctions between the terms clear. She also added some real-world examples, which weren’t there before, and cited an additional 23 sources.
Given that Professor Shaw let students choose which article to work on (as long as it was related to the course topic), Hannah was able to integrate her long-time interest in design with her coursework.
“Throughout middle school, I ran a site where other website owners could request a review from me regarding their site’s design and content. So I’ve always been discerning about things like navigability and readability, long before I learned any design principles or theories to explain why some sites felt better-designed than others,” Hannah shares. But it wasn’t until she was a college student taking courses on human-computer interaction and design principles that Hannah encountered the concept of inclusive design.
“The topic is something I will certainly carry with me into my career, regardless of what I pursue. I’ve already sought to bring inclusive design into the student organization I lead, both when thinking through our internal processes (such as recruitment and our new member experience) and directly presenting on the topic in our educational programming. Whether thinking about internal company policies in an inclusive manner or producing work that reflects inclusive design principles, researching for this article has provided me with some core considerations to look out for.”
Considering how much Hannah now relies on inclusive design principles in various facets of her life, looking back, it surprises her that the original Wikipedia article wasn’t fully fleshed out. Hannah hopes that now others can benefit from the changes she and her classmates have made.
“Overall, I hope people will come away from the article with a greater sense of the potential scope of inclusive design, and some concrete processes that they could apply to their own lives and work,” she says.
With 10,000 page views since Hannah made edits in February, plus the recent research showing Wikipedia’s effect on real-world behavior, there’s a good chance that Hannah’s hope has already become a reality.
In a Wikipedia assignment, not only do students add academic content to Wikipedia that might not otherwise be included, they also bring their unique perspectives as students of a particular discipline, geographic region, or identity. Hannah, for example, is a Communications major at Northwestern with minors in Entrepreneurship and Integrated Marketing Communications. She was born in Connecticut, grew up in Shanghai, and currently calls Austin, Texas, home. If not for the Wikipedia assignment in Professor Shaw’s course, her interest in design, and her drive to produce well-researched work for the benefit of others, we likely wouldn’t have such a detailed page to learn from. She joins the worldwide community of Wikipedia volunteers (only 22% of whom identify as women), as well as the community of students who have completed a Wikipedia assignment through our Dashboard (70% of whom identify as women and nonbinary).
The assignment also fosters digital literacy and critical media skills at a time where these skills are increasingly important. Students learn about standards for clear, unbiased, and well-sourced writing.
“For me, it was really helpful to practice narrowing down my research into the most important and relevant points,” Hannah says. “I’ve always been quite verbose, so I appreciated the chance to develop a more concise style.”
The majority of students have grown up online and many are transitioning to majority-online universities. An assignment that prepares students to think critically about the information they encounter online and is a good fit for virtual learning too? That’s huge.
In a Wikipedia assignment, students partake in a worldwide ecosystem of volunteers who devote their time to curating, creating, and correcting the largest collection of free knowledge ever. Students bring a valuable perspective to distilling complex topics into plain language and freeing up the plethora of pay-walled knowledge that they can access through their institution. Wiki Education makes this form of teaching digital literacy accessible through our free assignment templates and tools, thereby making more knowledge accessible to the world.
Join the movement and incorporate the Wikipedia assignment into your 2023 course. Visit teach.wikiedu.org and register by December 16 to ensure your spot. We look forward to supporting you and your students.
Цей пост
також
доступний
українською
мовою.
Этот пост
также
доступен
на русском
языке.
On 22 November 2022, a Moscow Court rejected a case filed by the Wikimedia Foundation (“Foundation”) challenging a court verdict to impose a fine on the Foundation for failing to remove “prohibited” information from the Russian Wikipedia article about the Russian Invasion of Ukraine (2022). The Wikimedia Foundation, the non-profit organization that hosts Wikipedia and other free knowledge projects, will continue to explore all legal options to challenge this decision before higher Russian Courts. The information at issue remains fact-based, verified and improved by Russian speaking volunteers from all over the world.
“Accurate and reliable information is critical for people, especially in a time of crisis. Russian-language Wikipedia is a crucial second draft of history, written by and for Russian speakers around the world. We will challenge any attempts to control and restrict this access to knowledge,” said Jacob Rogers, Legal Director at the Wikimedia Foundation. “When governments attempt to suppress all points of view other than their own, they violate the human right to free expression and education and contribute to disinformation. We will continue to stand against such action.”
This case is one of several others pending before the Russian Courts including an appeal against a verdict where the Foundation was fined a total of 5 million rubles (the equivalent of approximately USD $82,000/-) for refusing to remove information from several Russian Wikipedia articles: Russian Invasion of Ukraine (2022), Battle for Kyiv, War Crimes during the Russian Invasion of Ukraine, Shelling of Hospital in Mariupol, Bombing of the Mariupol Theater, and Massacre in Bucha. On 1 November 2022, the court fined the Foundation an additional 2 million rubles (the equivalent of USD $33,000/-) objecting to content in two other Russian Wikipedia articles related to the ongoing invasion: Evaluations of Russia’s invasion of Ukraine (2022) and Non-violent resistance of the civilian population of Ukraine during the Russian invasion. These articles continue to be reviewed and improved via volunteer led content moderation processes.
The Foundation argued in its case that information on Wikipedia does not constitute disinformation, as found by the initial order, and should be protected under the freedom of expression. The information in the articles aligns with Wikipedia’s standards of neutrality, verifiability, and reliability, citing valid secondary sources. Its removal would therefore constitute a violation of people’s rights to free expression and access to knowledge.
The ongoing escalation of takedown requests, fines and tactics to influence access to Wikipedia on Russian search engines are part of an ongoing effort by the Russian government to limit the spread of reliable, well-sourced information that runs contrary to government’s narratives. We have not complied with any orders from the Russian government to date, and are committed to stand by our mission to deliver free knowledge to the world.
Once we receive the court’s reasoning in the coming weeks, the Foundation will evaluate what arguments are available to us and prepare a filing with the higher Russian Courts to review the case. For more information, please see our previous statements on 13 June 2022,1 March 2022 and 3 March 2022.
This statement was updated on 25 November, 20:30 UTC.
🕑 36 minutes
Nathan Brewer is the archival and digital content manager at the IEEE (Institute of Electrical and Electronics Engineers) History Center. He manages the IEEE's Engineering and Technology History Wiki.
Links for some of the topics discussed:
Each year, I tell myself I’m going to write a useful guide for this fun little event, and each year I fail to do so. So instead, as a treat, you get to see what my self-nomination statement would have been! Exciting. /s
It appears that ill-advised ArbCom runs seem to be a habit of mine — my standing for election in 2015 was destined to fail, but coincidently may have prompted me to run for adminship the year after, so silver linings and all that…
This year, my hat finds itself ambling to the ring after an ArbCom case in which I lost my functionary permissions, having held them on and off since 2017.
To say this puts me “on the back foot” in an election may be the understatement of the year, but I do wish to make it clear this is not a “protest candidacy” — on the contrary, this experience has highlighted to me a number of areas where improvements could and should be made, as others have already begun to point out in their statements.
My strengths lie in the areas of investigation & prevention of harassment and abuse, and in the reduction of bureaucracy and its attendant overreach — I have very little interest in policy wonk work, and would instead strive to see a slimmed-down Arbitration Committee which can focus on important local issues, whilst building on how we as a project work with the global community. I believe my position as a steward (since ~2018) lends itself to further bridge this gap to the English Wikipedia’s ArbCom.
Yeeeaaah, I didn’t think it would go down so well either…
The post 2022 Arbitration Committee Elections appeared first on TheresNoTime.
This post is also available in English.
Этот пост
также
доступен
на русском
языке.
22 листопада 2022 року суд міста Москви відхилив справу Фонду Вікімедіа (далі — «Фонд»), в якій оскаржувалося рішення суду про накладення штрафу на Фонд за те, що він не видалив «заборонену» інформацію зі статті російської Вікіпедії про російське вторгнення в Україну (2022). Фонд Вікімедіа, некомерційна організація, яка здійснює хостинг Вікіпедії та інших проєктів вільних знань, продовжуватиме вивчати всі правові можливості для оскарження цього рішення у вищих російських судах. Інформація у статті, про яку йдеться, залишається такою, що ґрунтується на фактах і є перевіреною та покращеною російськомовними волонтерами з усього світу.
«Точна та достовірна інформація є надзвичайно важливою для людей, особливо під час кризи. Російськомовна Вікіпедія — це ще один важливий проєкт історії, написаний російськомовними людьми в усьому світі, і написаний для них самих. Ми будемо оскаржувати будь-які спроби контролювати та обмежувати доступ до знань», — сказав Джейкоб Роджерс, директор з юридичних питань Фонду Вікімедіа. «Коли уряди намагаються придушити будь-яку точку зору, що відрізняється від їхньої власної, вони порушують право людини на вільне вираження поглядів і освіту, а також сприяють поширенню дезінформації. Ми й надалі будемо протистояти таким діям».
Ця справа є однією з кількох інших, які знаходяться на розгляді в російських судах, включаючи апеляцію на рішення, згідно з яким Фонд був оштрафований на загальну суму 5 мільйонів рублів (еквівалент приблизно 82 000 доларів США/-) за відмову видалити інформацію з кількох статей російської Вікіпедії: Російське вторгнення в Україну (2022), Битва за Київ, Воєнні злочини під час російського вторгнення в Україну, Обстріл лікарні в Маріуполі, Бомбардування Маріупольського театру та Різанина в Бучі. 1 листопада 2022 року суд оштрафував Фонд ще на 2 мільйони рублів (еквівалент 33 000 доларів США/-) за вміст двох інших статей російської Вікіпедії, пов’язаних із триваючим вторгненням: Оцінки вторгнення Росії в Україну (2022) і Ненасильницький спротив мирного населення України під час російського вторгнення. Ці статті продовжують переглядатися та покращуватися через процеси модерації вмісту під орудою волонтерів.
Фонд у своїй справі стверджував, що інформація у Вікіпедії не є дезінформацією, як було встановлено первинним рішенням, і що ця інформація повинна бути захищена з огляду на свободу вираження поглядів. Інформація в цих статтях відповідає стандартам Вікіпедії щодо нейтральності, можливості перевірки та надійності, з посиланнями на дійсні вторинні джерела. Тому її видалення означало б порушення прав людей на вільне вираження поглядів і доступ до знань.
Неприпинна ескалація запитів на видалення, штрафи, а також тактика впливу на доступ до Вікіпедії в російських пошукових системах — є частиною постійних зусиль російського уряду, спрямованих на обмеження поширення надійної і підтвердженої авторитетними джерелами інформації, яка суперечить наративам уряду. На сьогодні ми не виконали жодних розпоряджень російського уряду та зобов’язуємося продовжувати виконувати свою місію з надання світові вільних знань.
Як тільки ми отримаємо найближчими тижнями обґрунтування суду, Фонд оцінить, які аргументи нам доступні, і підготує позов до вищих російських судів для перегляду справи. Для отримання додаткової інформації, будь ласка, перегляньте наші попередні заяви від 13 червня 2022 р., 1 березня 2022 р. та 3 березня 2022 р.
Subscriptions
| Feed | RSS | Last fetched | Next fetched after |
|---|---|---|---|
| Ø | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| [[WM:TECHBLOG]] | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| All Things Linguistic | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Andy Mabbett, aka pigsonthewing. | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Anna writes | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| BaChOuNdA | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Bawolff's rants | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Between the Brackets: a MediaWiki Podcast | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Blogs on Santhosh Thottingal | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Bookcrafting Guru | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| brionv | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Catching Flies | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Clouds & Unicorns | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Cogito, Ergo Sumana tag: Wikimedia | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Cometstyles.com | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Commonists | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Content Translation Update | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| cookies & code | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Damian's Dev Blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Design at Wikipedia | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| dialogicality | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Diff | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Doing the needful | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Durova | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Ed's Blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Einstein University | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Endami | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Fae | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| FOSS – Small Town Tech | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Free Knowledge Advocacy Group EU | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Gap Finding Project | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Geni's Wikipedia Blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| http://ad.huikeshoven.org/feeds/posts/default/-/wiki | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| http://blog.maudite.cc/comments/feed | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| http://blog.pediapress.com/feeds/posts/default/-/wiki | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| http://blog.robinpepermans.be/feeds/posts/default/-/PlanetWM | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| http://bluerasberry.com/feed/ | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| http://brianna.modernthings.org/atom/?section=article | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| http://magnusmanske.de/wordpress/?feed=rss2 | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| http://moriel.smarterthanthat.com/tag/mediawiki/feed/ | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| http://terrychay.com/category/work/wikimedia/feed | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| http://wikipediaweekly.org/feed/podcast | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| http://www.greenman.co.za/blog/?tag=wikimedia&feed=rss2 | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| http://www.phoebeayers.info/phlog/?cat=10&feed=rss2 | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| https://blog.bluespice.com/tag/mediawiki/feed/ | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| https://blog.wikimedia.de/tag/Wikidata+English/feed/ | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| https://logic10.tumblr.com/ | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| https://lu.is/wikimedia/feed/ | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| https://mariapacana.tumblr.com/tagged/parsoid/rss | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| https://medium.com/feed/@nehajha | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| https://thoughtsfordeletion.blogspot.com/feeds/posts/default | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| https://wandacode.com/category/outreachy-internship/feed/ | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| https://wllm.com/tag/wikipedia/feed/ | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| https://www.residentmar.io/feed | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| in English Archives - Wikimedia Suomi | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| International Wikitrekk | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Laura Hale, Wikinews reporter | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Leave it to the prose | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Make love, not traffic. | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Mark Rauterkus & Running Mates ponder current events | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| MediaWiki – Chris Koerner | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| mediawiki – Hexmode's Weblog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| MediaWiki – It rains like a saavi | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| MediaWiki – Ryan D Lane | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| MediaWiki and Wikimedia – etc. etc. | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| MediaWiki Archives - addshore | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| MediaWiki Testing | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Ministry of Wiki Affairs | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Musings of Majorly | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| My Outreachy 2017 @ Wikimedia Foundation | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| NonNotableNatterings | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Notes from the Bleeding Edge | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Nothing three | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Okinovo okýnko | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Open Codex | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Open Source Exile | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Original Research | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Pablo Garuda | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Pau Giner | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Personal – The Moon on a Stick | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Planet Wikimedia – OpenMeetings.org | Announcements | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Planet Wikimedia Archives - Entropy Wins | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| planetwikimedia – copyrighteous | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Political Bias on Wikipedia | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Professional Wiki Blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| project-green-smw | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| ProWiki Blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Ramblings by Paolo on Web2.0, Wikipedia, Social Networking, Trust, Reputation, … | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Rock drum | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Sam Wilson's Website :: Wikimedia | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Score all the things | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Semantic MediaWiki – news | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Sentiments of a Dissident | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Stories by Megha Sharma on Medium | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Sue Gardner's Blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Tech News weekly bulletin feed | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Technical & On-topic – Mike Baynton’s Mediawiki Dev Blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| The Academic Wikipedian | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| The Ash Tree | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| The Lego Mirror - MediaWiki | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| The life of James R. | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| The Speed of Thought | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| The Wikipedian | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| TheDJ writes | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| This Month in GLAM | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Timo Tijhof | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Ting's Wikimedia Blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Tyler Cipriani: blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Vinitha's blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| weekly – semanario – hebdo – 週刊 – týdeník – Wochennotiz – 주간 – tygodnik | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| What is going on in Europe? | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wiki – David Gerard | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wiki – Gabriel Pollard | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wiki – Our new mind | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wiki – stu.blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wiki – The life on Wikipedia – A Wikignome's perspecive | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wiki – Wiki Strategies | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wiki – Ziko's Blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wiki Education | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wiki Loves Monuments | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wiki Northeast | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wiki Playtime - Medium | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wiki-en – [[content|comment]] | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikibooks News | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wikimedia – andré klapper's blog. | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wikimedia – apergos' open musings | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wikimedia – Bitterscotch | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia – DcK Area | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia – Guillaume Paumier | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wikimedia – Harsh Kothari | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wikimedia – millosh’s blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia – Open and Free Source! | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wikimedia – Open World | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wikimedia – Thomas Dalton | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia – Tim Starling's blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia – Witty's Blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia (en) – Random ruminations of a ruthless 'riter | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wikimedia Archives - Kevin Payravi's Blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia Archives - TheresNoTime | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia Commons – Frank Schulenburg | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia DC Blog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia Foundation | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia on Taavi Väänänen | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia Security Team | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikimedia | ഗ്രന്ഥപ്പുര | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikinews Reports | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikipedia & Linterweb | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikipedia – Aharoni in Unicode | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wikipedia – Andrew Gray | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikipedia – Andy Mabbett, aka pigsonthewing. | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikipedia – Blossoming Soul | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikipedia – Bold household | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wikipedia – Going GNU | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikipedia – mlog | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikipedia – ragesoss | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wikipedia – The Longest Now | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikipedia - nointrigue.com | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikipedia Notes from User:Wwwwolf | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikipedian in Residence for Gender Equity at West Virginia University | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| WikiProject Oregon | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikisorcery | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Wikistaycation | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wikitech – domas mituzas | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| wmf – Entries in Life | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| WMUK | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Words and what not | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| Writing Within the Rules | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| XD @ WP | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |
| {{Hatnote}} | XML | 00:01, Wednesday, 07 2022 December | 01:01, Wednesday, 07 2022 December |