https://signpost.news — the website of tomorrow, today! in about a week when I am back from my vacation and get around to finishing it!
Over the last twenty years, much effort has been made to provide a wide variety of diverse ways to read The Signpost. Through the diligent work of industrious minds, we've crafted for ourselves the ability to stay in touch with our readers through notifications via email, feeds for RSS, posts on Facebook, tweets on Twitter, toots on Mastodon, glorbs on Kaffr, plovs on Quimbl, zelps on Frangus... kids these days don't know what it was like to while away the days Zelping on Frangus. And that's sad.
But really, must this be the only way to read it? Try showing a Signpost article to someone who isn't an English Wikipedia editor.
My personal experience is that the conversation starts out with explaining the difference between a "Wikipedia page" and a "Wikipedia:" page — by the way, normal pages are called "articles", the term "page" just refers to all namespaces — what do you mean, you don't know what namespaces are? — we will get to that later — anyway, no, these aren't Wikipedia articles — well, they are articles, and they are on Wikipedia, they just aren't Wikipedia articles because they aren't in mainspace — oh, that is just what we call the primary namespace where the page title has no scope specified — no, the stuff in Signpost articles is not the official opinion of the whole English Wikipedia — yes, even though it's hosted there — well, okay, we can get brought to noticeboards or have pages deleted at MfD — that stands for "miscellany for deletion" — yes, M-I-S-C-E-L-L-A-N-Y — no, that's the official name of the process — wait, hold on, let me link you a few more things — yes, you'll be prepared to read
the Signpost article in a few minutes...
In the last few months I have been giving some serious attention to the way that newspapers are run, and the way newspapers are structured — it turns out the answer in 2023 is usually "on the computer". But so long as we're on the computer, it is worth taking a look at the specifics.
Whether it's the New York Times, the Washington Post, Le Monde, Gawker, the Daily Mail, or the Wetumpka Herald, most news sites are easily recognizable as what they are; they provide some basic features like headers, navigational bars, sidebars, and overall purposeful website design to surround their engaging high-quality journalism. Well, okay — to surround their article content. But even if it is trash, it is trash on a fancy plate with shiny utensils.
The Signpost has accumulated a pretty decent collection of flatware over almost the last nineteen years, and — at least in my admittedly-biased opinion — the entreés are top-notch. But there are some shortcomings.
Limitations and woes
This article in the Wetumpka Herald starts with some clearly-indicated navigation links ("About us", "Contact us", "Contests", "Crossword", "TPJ Joboard") and login links, then indicates clearly that it's from the Wetumpka Herald, whose logo is the first thing on the page. There's a navigational header for the newspaper, then the headline and byline that tell you it's an article about some stacks of hay catching on fire.
This article in The Signpost starts with a hamburger menu icon, then the Wikipedia logo, then a search bar for the English Wikipedia. Then it has login links, then "Wikipedia:Wikipedia Signpost/2023-02-04/Section 230" — which isn't the headline of the article — in huge header text, then links to "Project page", "Talk", "Read", "Edit", "View history", and "Tools". After that, we have "From Wikipedia, the free encyclopedia", then "< Wikipedia:Wikipedia Signpost | 2023-02-04". Several inches down the screen, we have the Signpost logo, our own navigation links, the issue date and the article's headline.
That's it: just the page name. Since Signpost pages are in projectspace, we don't even get a snippet of the content in the preview, like normal articles do.
Meanwhile, a Google news search for Fire destroys barn, hay on Redland road returns the Wetumpka Herald as the top result; a Google news search for Twenty-six words that created the internet, and the future of an encyclopedia returns nothing.
Finally, our URLs are highly constrained and baroque, in a way that makes sense from a technical perspective (and believe me, I've become quite familiar with said perspective lately) but makes no sense from a reader's perspective.
Our URL says "Wikipedia" three separate times (and "wiki" four times) for no apparent reason. It's a mouthful to say, an eyeful to look at, and a handful to type.
Why?
These issues are a natural and unavoidable consequence of the extremely unique nature of The Signpost's content management system; as far as I know, it is the only periodical on the entire Internet which uses the specific tech stack of content being served by a combination of pages composed by JavaScript/JQuery publishing scripts, Lua modules maintained by Python scripts, and English Wikipedia template logic to implement MediaWiki markup on a MW PHP/MariaDB backend. Certainly, it is the only such periodical that's been in continuous operation for nearly nineteen years. It's called "Wikipedia:Wikipedia Signpost" because it exists in Wikipedia's projectspace, was named "The Wikipedia Signpost" in 2005, and subsequent discussions that changed its name to "The Signpost" didn't involve actually renaming the pages because nobody wanted to run an unbelievably gigantic AWB mass-move job and afterwards spend a week having every template and thousands of pages be hopelessly broken for the sake of removing ten bytes from the URL.
Website listings in Google News, Apple News and the like require DNS records to be added by the root domain's owner; it would be impossible for us to mess around with the DNS records for all of wikipedia.org, a site in the top 10 of traffic worldwide. Moreover, even if we could, it would be the height of absurdity to claim all of wikipedia.org as exclusive Signpost turf in the eyes of Google News!
Similarly, preview cards for social media sites are very simple, but they are scanned out of attributes in pages' HTML <head> elements. There's no way to specify them in body content, i.e. where all of the visible text goes, which means that with the way MediaWiki is set up it's impossible for us to implement this on The Signpost on Wikipedia. And even if we were able to convince all of the English Wikipedia's top brass to let us mess around with the raw HTML of our pages, it's not really clear how this would happen: it would probably involve shoving some hoopty MediaWiki extension into en.wp's already-heavily-modified MW install, at the risk of busting the whole site for billions of users.
What is to be done?
Well, luckily, your editor-in-chief is a galaxy-brain geniouse [sic] electron wrangler, meaning that fixing these issues in a way that looks cool and doesn't break the current functioning of the Signpost is a simple one-day project.
Two-day project.
Three-day project.
Okay, I am on day eight. But to be fair, I had everything except the domain name working on day six. It wasn't my fault Toolforge's Kubernetes ingress settings don't permit external domain names to resolve to tools, and that I had to reconfigure everything to deploy to my own VPS, and that I had to figure out how to do a reverse proxy through Apache so that it could keep serving normal pages for a different domain while routing signpost.news queries to a different port for the same protocol.
It was my fault that I had to spend a whole night galloping the VPS through six years of procrastinated Ubuntu distribution upgrades before I could get current versions of the application's dependencies to run right.
It's up for debate whether it is my fault that I'm deploying a complicated Web application immediately before taking a four-day out-of-town trip where I have virtually no Internet access; reliable fact-checkers indicate that the answer is a "mixture of true and false".
Anyway, here is what it is:
The signpost.news stack
Since you have already soldiered through quite a lot of text on this page, I will restrain myself here to a brief overview.
What I have running on signpost.news right now is Sinepost, a lightweight Express application I wrote to act as middleware between the client (the reader) and backend (the Wikipedia). Essentially, what happens when you go to a page there — like https://signpost.news/2023-02-04/Section_230 — is this:
The server gets the URL path you are trying to access (in this case, /2023-02-04/Section_230).
It processes this into the appropriate Wikipedia page (in this case, Wikipedia:Wikipedia_Signpost/2023-02-04/Section_230).
It also adds a couple things, like page titles, a favicon link, and various meta tags for search engine indices and preview cards on Twitter, Facebook, Discord and the like. It also adds a sub-header link bar for various departments and pages, as well as a sub-footer row with links to the original en.wp location of the page, the Sinepost source code, and the Creative Commons 4.0 license.
One thing you'll notice about this is that, unlike most webapps, the backend isn't a database stored on the signpost.news server. The backend is this: the existing Signpost pages, as they are right now, here on en.wp (although it's possible that in some disaster scenario, like the often-predicted-yet-never-happened Death of Wikipedia, it could be reconfigured to fetch pages from other MediaWiki sites). This means that, rather than an extremely painful process of replacing the Signpost structure and content and template ecosystem, the application simply augments it with an improved interface and design. This means, further, that this application doesn't require any sort of separate process to write, publish, or maintain pages beyond what we already do. Everything that happens here happens there instantaneously.
Essentially, the application (I will never write an "app") is set up to serve as a presentable frontend for a system which has worked well, continues to work well, and has almost nineteen years of attestation to that fact.
The beauty of choice
"This sucks," you may be thinking: "it looks like crap and I hate it".
First of all, please tell me how, because hitherto the only people who have been able to evaluate this are my friends whose necks I keep breathing on while I look over their shoulders and command them to "keep browsing". If possible link to a screenshot, because I have not tested this on every browser and device yet, and while it looks fine on my computer and my girlfriend's computer, it would be nice to have a broader evaluation.
Well, it is a free country. You will be pleased to hear that the existence of this application changes nothing about the experience of reading the Signpost on Wikipedia, which will always be possible, and if you hate the idea of a slick web interface, you will lose nothing by ignoring it completely. There is not going to be some social media scenario where we cram the .news domain full of ads and user-hostile engagement-maximizing anti-features while slowly pushing the original site's content model behind an increasingly onerous litany of opt-out settings, API restrictions and planned obsolescence.
What is next?
What you see at signpost.news right now is a minimum viable product; it's a start. It's basically what I could get out the door in a week before leaving on a long trip with no Internet service. There is a lot of work that remains to be done.
Design
Most importantly — because this is the most visible thing, and I am sure it will feature heavily in feedback — the current design of the site is not intended to be its final form. The fonts and shades are the best I could come up with in an afternoon of playing around with various things. It could probably do with a bit more color, and the formatting of articles could do with a bit more customization.
Styles
You will note that a few things, like image gallery elements or collapsible boxes or sortable tables, do not render as they do on-wiki. This is not inevitable — there are stylesheets and scripts that can be loaded to make these work — but I have not had time to implement this for everything yet. There are also some things that could (and probably should) be done, but are difficult to do right now because not all Signpost elements have distinct classes and rules sometimes work in unexpected ways.
Code
Should you venture into the Sinepost repository, you will notice that a lot of the code is a dog's breakfast. This is definitely not in its final form; lots of stuff (like base URLs, paths, and header/footer content) is hardcoded because of time constraints. In the future, this stuff will be drawn from templates or files on the webserver, or even from Signpost pages on-wiki (like "external.css" already is). Moreover, the code is just fugly in a lot of places, and stuff like 404 handling is not dealt with very beautifully.
Overall, there are a few things that do not work as they should — one of my favorites is that the search box on https://signpost.news/Archives just dumps you out to a Wikipedia search where if a query gets no results, it defaults to showing results for the query minus its quotation marks, which means that it is easy to get giant walls of irrelevant nonsense. In general, Signpost styling is somewhat inconsistent; while most pages and templates use TemplateStyles, many have inline styles that are declared in div or span tags themselves within the wikitext source. Hunting these down and moving them to more general stylesheets is a long and complicated task.
Moreover, there are a bunch of things that are just strange or busted for no apparent reason; as a trivial example, when trying to get {{Signpost/Number of issues}} (i.e. 701) to work properly, the numbers kept being off by a few, and I discovered there was such a thing as a ghost issue, where an issue page (like Wikipedia:Wikipedia Signpost/2013-06-17) existed but had no subpages (i.e. no articles) and was never actually sent out to subscribers. One of these would be enough of a mystery — but there were twelve!
But that kind of thing is enough for an article of its own, and I did say I would keep this short. So let me know what you think, and I will do my best.
Right now, I am pretty strapped for time, having spent most of my effort this issue on setting up the web frontend at https://signpost.news, and having already delayed publication by a couple days to deal with various issues, I am about to leave for a vacation in which I don't have Internet access for several days.
In the midst of what was supposed to be a final copyediting pass for this issue, I noticed that our draft for News and notes was almost completely empty, and even with the assistance of "leveraging synergies to harness the power of AI" or whatever, there was no way for me to get it done on time.
Therefore, given no other option (other than to miss my ride or to drop the Signpost's longest-running feature) this issue's News and notes will be taken from the freshest news source possible — the lifeblood of Wikipedia. Yes, ladies and gentlemen: we're getting it straight from the horse's mouth. Something that few people pay attention to.
Here are the most recent three entries from Special:RecentChanges. A page so monotonous and so ubiquitous, most people probably don't think about it. But they should — because it's not just about the pleasures of editing and the importance of continually working to improve the project. It's also a personal record of our knowledge itself, and what it means to us.
Typographical fixes are a crucial part of Wikipedia's ability to provide its users with timely, accurate, and reliable information — some may look down on them as trivial or insignificant, but it's important not to take them for granted. Without them, our articles are harder to read, harder to learn from, and sometimes even incorrect (after all, e is not é).
This is another thing that is frequently overlooked; after all, we don't know if MonMothma looked for a citation, or just slapped the tag on. And indeed, sometimes people are too careless in their application of the tags. But so, too, are many people careful and diligent; and it's through their care and diligence that others, later (perhaps even decades later) are able to figure out what needs to be fixed, where, and do something about it.
The Signpost thanks MonMothma for their efforts.
New user account
As of right now, User:Coyote,w,e is the English Wikipedia's newest user. Most new user accounts never edit, and some people think that most accounts don't matter. Indeed, many new user accounts are never logged into again. But I think this is great. I think this is the Wikipedian Dream. Whoever this is, wherever they are, they have a fresh account waiting for them, and they're not subject to any pressure or any data harvesting for doing so. Facebook doesn't know about their Wikipedia account. Google doesn't know about their Wikipedia account. If the government wants to know about their Wikipedia account, they'd better come back with a warrant. Even Wikipedia doesn't know that much — sure, they can be CheckUsered, but CUs need to show probable cause and are subject to recall if they don't, which is more due diligence than even the police need to demonstrate in many places.
The Signpost wishes Coyote,w,e a career of happy editing — or reading — or whatever floats their boat.
Events are events, and reporting is reporting. Some sources are biased in what they choose to cover, some are openly partisan, and some make suggestive innuendo to imply more than they can prove. Indeed, some sources do so with such fervor that they are not considered reliable for general use on Wikipedia.
But things that happened happened, and things that didn't didn't, and sometimes there really is a wolf, and sometimes businessmen really do sleazy stuff on Wikipedia.
The Federalist also links to a copy of the email correspondence between Hunter Biden, his confidant Eric Schwerin, and Ryan Toohey of FTI Consulting, as uploaded to DocumentCloud by Lee Fang. These show the passages Hunter objected to, and his and Schwerin's comments. For example, the Career section of his article began with an unsourced sentence that read:
Biden is a lawyer with insider connections to the financial industry and government.
According to Fang's email document, Schwerin commented:
If there is a way to delete this sentence that would probably be good.
The sentence was duly removed. The relevant edits were performed by the user AmeliaChevalier in May 2014: 1, 2, 3, 4, 5.
The first and third of these edits removed large chunks of content about Burisma, a holding company of Ukrainian energy business Hunter has had associations with in the past.
Some of the other changes look, prima facie, like good-faith corrections of factual errors. Toohey comments in one of the emails:
Thanks.
We will make additional edits once you deliver a revision.
And, yes, some of the misstatements are crazy.
There is another notable deletion. According to the email document, Hunter commented as follows on a sentence claiming that he co-founded the "PARADIGM Global Advisors" fund (along with James Biden and disgraced financier Allen Stanford):
I did not co-found- it was founded in the mid 90s by James Park- I acquired a controlling interest
Stanford had nothing to do with the fund- Paradim was one of hundreds of alternative asset managers that were offered to Stanford clients for investment in their portfolios- any money, which was small relative to our fund's total AUM, invested on behalf of Stanford banking clients was fully returned to those clients at a profit based upon Paradigm's performance. No one from Paradigm ever met Alan Stanford or had any dealings with him.
While the Wikipedia sentence (added in 2013 by EllenCT, citing a 2007 Bloomberg source whose pre-2014 status is not available in the Internet Archive) does appear to have been incorrect as far as the co-founding is concerned, Biden's assertion that "Stanford had nothing to do with the fund" is also contradicted by sources. A 2009 Wall Street Journal report (archive), for example, says:
A fund of hedge funds run by two members of Vice President Joe Biden's family was marketed exclusively by companies controlled by Texas financier R. Allen Stanford, who is facing Securities and Exchange Commission accusations of engaging in an $8 billion fraud. The $50 million fund was jointly branded between the Bidens' Paradigm Global Advisors LLC and a Stanford Financial Group entity and was known as the Paradigm Stanford Capital Management Core Alternative Fund.
Other quality sources commenting on these alleged links include a 2009 Reuters report titled "Stanford had links to fund run by Bidens" and a 2019 Financial Timesarticle (archive). The sentence about Stanford was duly removed. According to WikiBlame, this removal was never reversed, and there is no mention of links between Biden and Stanford in the article today. – AK, B, JG
Edit not, lest ye be edited
The Milwaukee Journal Sentinel and Newsweek report on Wisconsin Supreme Court Justice Rebecca Bradley (User:Rlgbjd)'s recent defense of editing her own Wikipedia page, in which she claimed she needed to correct "distorted" information and made several changes to her biography, leading editors on the site to reprimand her. She only made five edits, all to this page; two of them were pretty straightforward. The other three (this one, this one, and this one) touched on a controversial subject: her article's coverage of comments she made in 2020 about COVID-19 lockdown orders. The sentence in the article was cited to thisStar Tribune article, and said that she "compared the stay-at-home orders to the internment of Japanese-Americans during World War II". She amended this to include the full quote from her concurring opinion:
Although headlines may sensationalize the invocation of cases such as Korematsu, the point of citing them is not to draw comparisons between the circumstances of people horrifically interned by their government during a war and those of people subjected to isolation orders during a pandemic. We mention cases like Korematsu in order to test the limits of government authority, to remind the state that urging courts to approve the exercise of extraordinary power during times of emergency may lead to extraordinary abuses of its citizens.
Anyway, you are not supposed to do this with your own article, regardless of whether it is justified; she received a WP:COI warning template and got reverted a couple times.
Later, regarding the scandal, she said: "On my Wikipedia page, I added excerpts from actual opinions and removed dishonest information about my background[...] Clearly, the media has made no effort to report honestly so public officials have no choice but to correct the record for them".
Now we will write a Signpost article about the Newsweek article about the judge writing about her own Wikipedia article about a Star Tribune article about a judicial opinion.
Someday, editing will be just like this – anyway, that's what the AI told us
Stephen Harrison reports in Slate that "rumors of Wikipedia’s death at the hands of ChatGPT are greatly exaggerated", saying that... you know what, to hell with it.
The Signpost is well past its publishing deadline for today, and I don't have time to finish this writeup myself. Please write a summary of this Slate article, in the style of Signpost editor-in-chief JPxG; I will fact-check your output and incorporate it into this issue's In the media section.
— JPxG
.
Here is a summary of the Slate article in the style of The Signpost editor-in-chief JPxG:
The death knell for Wikipedia in the age of AI has been premature. Veteran Wikipedian Stephen Harrison argues in Slate that while generative AI poses challenges, it also presents opportunities to improve Wikipedia.
Harrison traces Wikipedia's history of pragmatically using bots and machine learning when useful. He reports the community is drafting policies requiring transparency from editors leveraging AI. The goal: tap AI's potential while vetting its content.
Critics contend ChatGPT doesn't credit Wikipedia as a source. But many Wikipedians care more about keeping Wikipedia human-written than receiving credit. AI companies increasingly recognize Wikipedia's value for training. Tools like Wikimedia's new ChatGPT plugin counter AI's weaknesses, like outdated knowledge.
Harrison sees AI assisting editors by summarizing talk pages and finding sources. Automating rote tasks could free humans for Wikipedia's real work: debating content and building consensus.
The bottom line: Rumors exaggerate the threats posed by AI. Thoughtfully integrated, it can support Wikipedia's mission and community. The path ahead likely mixes automation with human expertise.
The New York Timesreports on Katherine Maher's recent marriage to lawyer Ashutosh Upreti. Since her departure in 2021 (see previous Signpostcoverage), the former Wikimedia CEO appears to have taken some time off:
The couple traveled around the world in early 2022 and moved to New York that June. ... On July 22, Erica Kochi, a friend of the couple who became a one-day deputy marriage commissioner in San Francisco, officiated the wedding before 140 guests on the lawn of Willow Camp in Stinson Beach, Calif. The day before, the groom rode in on a white horse for a Hindu ceremony. "It was two days of cross-cultural celebration and community," Ms. Maher said, "and a really big dance party."
The Signpost wishes the happy couple all the best. – AK
Toilet nomenclature is priority number one, and people write a lot of number two about it online
Welcome to Wikimania! Pick whichever accommodations you please.
AsiaOne and SCMP report that some people were making some posts on the darn computer — ain't that the way it always goes?
This time it was because the organizers of Wikimania 2023, getting cozy at the Suntec Singapore Convention and Exhibition Centre, had posted a sign designating one of the banks of restrooms as "gender-neutral toilets". A whopping eight social media posters are quoted as commenting on this, expressing a variety of political opinions.
Was it a radical act of progressive inclusion? Was it performative woke virtue signaling? Was it good? Was it bad? More importantly, can somebody reach over and hand me a couple social media posts? The holder in my stall is empty! – JG
In brief
For legal reasons we can not display the more recent mug shot that we would like to show you; instead, here is Alphonse Bertillon, who developed and standardized this type of photograph.
"Journey to prominence" and/or PR: This article showcases the "Journey to prominence" of a paid editor who "Leverages Wiki and PR Services for Enhanced Notability, Growth, and Fundraising Success" (Z News Service, via MSN [2]).
Do you want to contribute to "In the media" by writing a story or even just an "in brief" item? Edit next week's edition in the Newsroom or leave a tip on the suggestions page.
A monthly overview of recent academic research about Wikipedia and other Wikimedia projects, also published as the Wikimedia Research Newsletter.
"Unpacking Stitching between Wikipedia and Wikimedia Commons: Barriers to Cross-Platform Collaboration"
The vast majority of academic research about Wikimedia projects continues to focus on Wikipedia and (in recent years) Wikidata. Publications about sister projects such as Wiktionary, Wikinews or Wikibooks exist, but are rare. A paper titled "Unpacking Stitching between Wikipedia and Wikimedia Commons: Barriers to Cross-Platform Collaboration"[1] is one of the very first social science publications to examine Wikimedia Commons (albeit still in tandem with Wikipedia). That's despite Commons being, as the authors highlight, "the world’s largest online repository of free multimedia files for anyone to contribute and use. To date, there are more than 10.5 million volunteers and over 77 million media files on Commons."
The term "stitching" in the paper's title refers to an existing concept from the field of CSCW (Computer-supported cooperative work). The authors define it as follows:
Stitching is a framework that has been used to help describe and characterize cross-platform work to build organizations and also build awareness of topical content. There are three processes of stitching, production, curation and dynamic integration that enable resources to be distributed and utilized across different technical platforms and social networks.
The paper examines in detail how these three cross-platform processes work in case of (English) Wikipedia and Wikimedia Commons, considering the role of Commons of hosting images and other media used on Wikipedia (and other Wikimedia projects). It is based an interview study with 32 Wikimedians working on both projects – from newcomers (<1k edits) to "highly active editors" – five of whom self-identified as women. Among many other examples of such Commons-Wikipedia stitching, they describe e.g. the cropping or retouching Commons images to make them more suitable for use on Wikipedia use, or aligning Commons categories with Wikipedia article names. (These contrast with activities that focus on only one of the projects – such as text editing on Wikipedia, and image uploading, image annotating, metadata tagging and categorizing on Commons. Regarding the latter, the authors observe "a large group of Commons focused editors who categorize images. Categories is 'the primary way to organize and find files on Commons'", quoting one of the interviewees.)
While much of this will come as no surprise to Wikimedians familiar with both projects, the paper's second research question provides food for thought to both the involved volunteer communities and the Wikimedia Foundation (or other actors interested in designing better collaboration features in this areas). Here, the authors identify five "barriers that inhibit effective stitching between Wikipedia and Wikimedia Commons", and propose some "design implications" that could mitigate them:
"Barrier 1: Lack of Communication Across Networks"
The paper observes the existence of
networks of photographers focused on producing images of different subjects, a network of Commons admins that handle copyright issues, a network of categorizers that work to sort pictures on Commons, and networks of Wikipedia editors who write articles in specific subject areas. These micro-networks establish their own ways of communicating and organizing their activities. However, participants argued that there was an absence of communication between these distributed micro-networks. For example, there was no formal way for Wikipedia editors and Commons curators to discuss the imagery needs of Wikipedia articles [...] Participants found it
hard to engage in discussions held in other networks to understand their goals and practices [...] Though Commons curators produce images with an intent to support Wikimedia projects and Wikipedia editors rely on the images to illustrate articles, the communication channels between micro-networks and across the platforms are hard to find.
The authors (perhaps wisely) don't propose concrete solutions for this issue, but rather list a few "[p]rior studies in CSCW/HCI [human-computer interaction] [that] investigated similar situations in which stakeholders of a design problem were distributed", and suggest that "WMF could explore these approaches to engage editors distributed across platforms in a participatory design process to address their communication needs."
"Barrier 2: Differing Perspectives"
Out of over 22,000 images of a Boeing 777 on Commons, Wikipedians have selected this one as the current lead illustration for the article Boeing 777
Here, the paper discusses tensions arising from the differing self-perception of each project – Wikipedia as "reference" work vs. Wikimedia Commons as "collection". This manifests e.g. in the question of whether Commons should primarily be seen as a media repository in itself, or as infrastructure for other Wikimedia projects. Specifically, the authors note debates on whether it should aim to host more images of a subject than could conceivably be needed to illustrate pages on other projects: the paper opens with the example of a Wikipedia editor looking to illustrate the article on the Boeing 777 airplane and getting overwhelmed with the search results on Commons: "22,572 images for Boeing 777 with 5,686 categories and multiple pages created by different curators who work to sort images." (As a counterargument illustrating "the difficulties of judging the
utility of Commons resources as a function of their use in other WMF platforms", another interviewee mentioned the example of a particular Boeing 777 becoming notable after an accident: "And suddenly, that photograph of that aeroplane we were hosting on Commons appeared in newspapers and all over the place, because it was the only freely available photograph they could find of that exact aircraft.")
As a solution to such issues, the authors (somewhat vaguely) suggest "a process similar to Wikipedia's notability voting. The process would enable editors from both platforms to figure out whether an image warrants significance in any contexts collaboratively, rather than relying on judgement of editors from one platform or the other."
"Barrier 3: Multilingual Resources"
The authors note that Commons is multilingual in theory (with many documentation pages, templates etc. being translatable and available in multiple language), but in practice mostly "produced and curated by English speakers". In particular, they call out the limitations of the search function:
One problem is that the search engine of Commons is key-word based and is not capable of searching 'in the middle of all the languages.' [...] This issue severely impacted participants from other language editions of Wikipedia who have limited or no English proficiency. They would find 'so little of Wikimedia Commons' was available for them to search and use in their own language. [...] This barrier is not just a one-way street, it impacts English-speaking contributors as well. It is difficult for English speakers to find materials about non-English speaking countries because most of the related content was produced and curated in the language spoken in the respective country [...]
The paper remarks that the WMF-led "Structured Data on Commons" project (launched in 2017 with a $3 million grant from the Alfred P. Sloan foundation) aims to improve this by incorporating multilingual information from Wikidata, but that it has "made little progress on Commons because many contributors simply did not know about it or did not care", or "preferred their 'own' [category-based] system over a new structure designed by the foundation". (Here it is worth noting that the study's interviews took place from April 2020 to January 2021, i.e. shortly before the default search interface was switched to "Media search" which is supposed to eventually integrate such structured information. However, as of this time – August 2023 – it retains the same limitations of text-based search.)
As a possible way out of this conundrum, the authors suggest that
"One potential solution is for the foundation to investigate ways to incorporate Commons existing categories into the Structured Data Project"
"Barrier 4: Cross-Platform Vandalism"
This issue mainly refers to the problem that vandals can overwrite an image on Commons to affect articles on Wikipedia, which is difficult to detect for Wikipedia editors using their existing monitoring processes. And on the other side, "Though Wikimedia Commons can track and detect when an image is overwritten, it is hard to evaluate the legitimacy of the overwrite because the context of reuse is unknown."
The authors note that this is partly a technical issue, as cross-platforms notifications could be implemented to alert Wikipedians of such incidents. However, they argue that "Even if these notifications existed, these platforms would need to collaborate on addressing the problem. In the general case, resolving barriers will require technical and social collaboration across or between platforms."
"Barrier 5: Differing Policies"
Here, the paper gives two examples. The first one is about copyright:
One key misalignment between Commons and Wikipedia is how copyright is treated. Commons
implements a "Precautionary principle" which states that "where there is significant doubt about the freedom of a particular file, it should be deleted." This delete first and discuss it later approach is in contrast to Wikipedias’ "Assume Good Faith" policy that encourages discussion first.
(Contrary to what the authors appear to imply here, the "Assume Good Faith" policy specifically clarifies that "When dealing with possible copyright violations, good faith means assuming that editors intend to comply with site policy and the law. That is different from assuming they have actually complied with either. Editors have a proactive obligation to document image uploads, etc. [...]")
As a second "misalignment", the authors calls out "the differences between Wikipedia and Commons reliance on data
sources":
The practice on Wikipedia is to “citing sources”, and in particular, “reliable sources” all in the service of making statements “verifiable”. Media resources on Commons do not need to satisfy all of these standards and there is no judgement as to the validity or correctness of the media artifact. From one perspective similar versions of something like a map or a deep fake image, might have high utility when contrasted with alternate versions [...] Given this generally inclusionary standard, Commons contributors sometimes produce images without including information about the sources of the data as part of the content metadata. Without this key metadata, media is then suspect under Wikipedia’s stricter policies [...]
Here, the paper doesn't offer solutions, apart from the already mentioned general proposals to improve cross-platform and cross-network communications.
Other recent publications
Other recent publications that could not be covered in time for this issue include the items listed below. Contributions, whether reviewing or summarizing newly published research, are always welcome.
"Evolution of the Coordination of Activities Aimed at Building Knowledge in the Wikipedia Community"
"This paper aims to characterize the variability in creating new concepts of cooperation in selected language versions of Wikipedia and identify the factors of participating in various forms of cooperation. [...] The research conducted was both qualitative and quantitative. A netnographic approach was used, as well as a statistical analysis of user activity records. Thanks to the netnographic research, the stages of Wikipedia’s evolution were identified. Quantitative research has shown a correlation between the number of activity areas (a user’s affiliation to WikiProjects) and their overall activity (the number of edits made). A change in Wikipedians’ activity style was also observed depending on their seniority on the website."
"The Scientific Revolution represents a turning point in the history of humanity. Yet it remains ill-understood, partly because of a lack of quantification. Here, we leverage large datasets of individual biographies (N = 22,943) and present the first estimates of scientific production during the late medieval and early modern period (1300–1850). [...] Finally, we investigate the interplay between economic development and cultural transmission (the so-called ‘Republic of Letters’) using partially observed Markov models imported from population biology. Surprisingly, the role of horizontal transmission (from one country to another) seems to have been marginal. Beyond the case of science, our results suggest that economic development is an important factor in the evolution of aspects of human culture."
From the paper:
"[...] we gathered the Wikipedia pages of all individuals classified as scientists during the early modern period: mathematicians, astronomers, physicists, biologists, naturalists, chemists, botanists, entomologists and zoologists (see Table S1). Then, we estimated the scientific contribution of each of these 6620 individuals through different proxies (the size of the page, the number of translations in other languages and the number of Wikipedia pages containing a link to this page). With such a large dataset, we can go beyond key figures such as Newton and Galileo, and take into account the thousands of little-known individuals who contributed to the rise of science "
"Comparison of metrics for measuring Wikipedia ecology: characteristics of self-consistent metrics for editor scatteredness and article complexity"
"[...] To measure the quality of the editors and articles on Wikipedia, self-consistent metrics for the network defined by the edit relationship have been introduced previously. This scatteredness–complexity measure can evaluate the editors and articles more sensitively than the local characteristics such as degrees of the network and capture well the editors’ activity and the articles’ level of complexity. [...] In addition, the distributions of the editor scatteredness and article complexity become smoother when the network is randomized and loses its detailed local structure eliminating the correlation between the editors and articles. When the degree distributions of the editors or articles are changed and become uniform in the randomized network, the distributions of the editor scatteredness or article complexity become flatter, respectively. This results suggest that the scatteredness–complexity measure reflects not only the degree distribution of the editors or articles but also the local network structure."
"Why a Guideline for Spoilers? A comparison between Spoiler Guidelines, related user comments of Wikis, Newssites and Fan Forums"
This master's thesis includes a chapter about discussions on English Wikipedia. From the abstract:[5]
The aim of this thesis was [...] to understand Spoiler Avoidance (SA) from an Information Avoidance (IA) view, treating it as an example of beneficial IA. [...] a number of Guidelines [about] spoilers were collected from Reddit, Fandom, multiple newssites, Wikipedia and Google. Results were found for multiple levels of abstraction. Firstly, spoiler guidelines exist due to difficulties in defining spoilers, different aims of websites and the different desires for users. Secondly it could be found that SA was not always assumed to be positive, but can be explained through many IA-theories. [...]
In the bright halcyon days of '13, a proposal was put forth at the Village Pump to alleviate the beaucoup backlog at Articles for creation — then at a whopping fifteen hundred. The idea was that "the task of reviewing submissions will be a less fragmented process, and it will be easier for volunteers to collaborate".
Discussion of this proposal, as well as a subsequent discussion on how specifically to implement drafts, ran to about two hundred kilobytes, and was closed as... well, the close note itself was 575 words. Whatever. What matters is that they agreed we should have a namespace for drafts, and so now we have a namespace for drafts.
Many drafts are good, and well-written, and reliably sourced, and make their way into articlespace when a reviewer approves them after a short wait (ha — no — more like six months). Others are obviously crap: unvarnished self-promotion from humanity's roiling sea of Soundcloud rappers, TikTok aspirants, used car salesmen and soi-disant entrepreneurial geniouses[sic].
Somewhere in between, however, lie a treasure trove of digital mushrooms that sprout after the rain. In this magical place, one can find curiosities that defy explanation and texts that challenge the very boundaries of understanding — where the ordinary meets the extraordinary, and the irreverent dances with the absurd.
Some of this stuff is too good to let it disappear after six months untouched! Or, for that matter, too bad. Or too ugly.
When cats are content they have relaxed limbs, their tail isn’t stiff or twitching they just look chill!
Sometimes cats purr when content but they also do this in pain.
When frightened
scared cat
When cats are frightened their fun goes up on end, they hiss or spit, they swipe and arch their back
When in pain
I don’t know much about this so please add on here:
cats purr when in pain. This is seen by vets as a female cat is in labour.
When intriguedIntruigued cat. This doesn’t represent it well but it is the best I have When intrigued their tail twitches and they closely watch whatever is interesting them! Their ears also stand up straight!
Not very representative but the best I have!
When alert
When cats are alert they tense up their body, stay very still and stare at a target/possible threat.
Thank you for reading!
I apologise if I tagged you but I wanted to get the cat community together
and what better to do it then with amazing modern day tech! (Laptops!)
CatLover1137 :)
Bringing the cat community together with the wonders of technology
Sources:
inside the mind of a cat,
cat wiki page
Cat behaviour research
The hidden lives of pets (not the secret life of pets!)
This draft, created on May 30 and given a minor copyedit by Insanecatburger on July 26, is fun and earnest. While it's obviously unlikely to make it into mainspace, one cannot help but root for it anyway — and suspect that we'd be better off if more of our drafts were like this one, written and submitted in a spirit of genuine collaboration.
Candy the cat is a pretty black cat. She sometimes forgets to put her tongue back into her mouth so she just walks around with it out.
Created with the edit summary "Everything" on May 29; submitted on August 9, and declined the same day by Milkk7 as an obvious joke submission.
While this is amusing, remember that thing about the draft queue being four thousand articles long? A human being had to click through this and type out an actual reason for why it didn't meet standards, making it a disgraceful waste of reviewer time. This is part of why AfC is bad.
Code cutting is a method of editing source code by physically printing out lines of code, cutting them with scissors, and then scanning them back into the code program. This method has been used by some developers as an alternative to traditional text editing tools, such as text editors or integrated development environments (IDEs).
Introduction
Code cutting is a unique approach to editing source code that has its advantages and disadvantages. While it may not be suitable for large code projects, some developers may find it to be a helpful technique for small code projects or when they need to make changes to a specific section of code.
Process
The process of code cutting involves the following steps:
Printing out the lines of code that need to be edited.
Cutting out the specific lines of code with scissors.
Scanning the cut-out code into the code program.
Editing the scanned code within the code program.
Saving the edited code and compiling it to check for any errors.
It is important to note that code cutting may not be suitable for large code projects, as it can become time-consuming and difficult to keep track of the changes made to the code. However, some developers find it to be a helpful technique for small code projects or when they need to make changes to a specific section of code.
Advantages and Disadvantages
Advantages
Can provide a more tactile approach to editing code.
Helps to visualize the code and the changes being made to it.
May be helpful for developers who struggle with traditional text editing tools.
Disadvantages
Not suitable for large code projects.
Can become time-consuming and difficult to keep track of changes made to the code.
May result in the loss or damage of the physical code cut-outs.
Conclusion
In conclusion, it is important to weigh the advantages and disadvantages of code cutting and determine if it is the best approach for a given code project.
References
Doe, J. (2019). "The Pros and Cons of Code Cutting." Code Magazine, 56(3), pp. 12-15.
Smith, M. (2018). "An Alternative Approach to Editing Source Code." Journal of Software Development, 44(1), pp. 22-25.
Brown, T. (2017). "Cutting Code: A Unique Method for Editing Source Code." Journal of Computer Science, 33(5), pp. 45-48.
Creating this draft, on February 13, was Officiants12's first and only contribution to Wikipedia. While this seems, on first blush, to be a competent writeup about an intriguing (albeit idiotic) approach to programming, it is complete bullshit.
Searches for all three of the "references" turn up nothing whatsoever on any search engine. "Code cutting" as described has no results in a Google news search, scholar search, or general web search. The draft has since been speedily deleted as a hoax.
In conclusion
Obviously, this is a great bit. It is well-written, concise, and on the precise knife-edge of plausibility; not only a hilarious mental image, but a biting satire of a whole genre of hyped-up programming fads.
So why is it ugly? It is a hoax article, for one; if it's approved, it is an inflamed pus-filled boil on the project and on the edifice of free knowledge itself. If it's rejected, it represents a gigantic waste of time, even more so than the few seconds it takes to identify the obvious joke submission; reviewers must search the article topic, cross-check the references, and scamper between search engines all for the reward of figuring out they are being trolled.
What could have been a great joke was instead forced to be something between a denial-of-service attack on Wikipedia's volunteer corps and a malignant tumor on its face. An active drain on our review processes that, by the way, got close to zero views in the entire half-year it was live in draftspace!
By comparison, this humble paper's humor section does numbers, and our submissions page is always open; there we cherish a good bit like a precious baby.
But if you submit it as a draft we will hunt it to the ends of the earth, with no quarter and no mercy.
We here at the Counter-Fun Unit would like to congratulate the Wikipedia community for choosing the correct option in the Barbenheimer caption discussion. While we dispute our characterization as the "fun police" — we're more of a paramilitary group — the outcome is a wonderful step towards our end goal: removing anything on Wikipedia that could be construed as funny, by anyone, ever.
This incredible progress is why we've decided to finally release our Dehumourification Plan. This 4442-page document outlines our vision for a Wikipedia devoid of all things comical. Some of our proposed solutions include:
We sadly cannot reveal this document to all of you, since its sheer beauty would be too much for you to handle. However, we have sent it to the Foundation — I mean, the Foundation, and they have shown great interest in it. We expect the process will be completed by at most the year 281,474,976,712,644 AD.
During the weekend when his team won Super Bowl XLVII, this American football player requested no questions about The Blind Side, the movie telling the story of how Oher was brought into a rich white family who helped him overcome a turbulent life to finish high school and become a successful athlete. Oher has now sued Leigh Anne Tuohy and her husband (the wife takes precedence, Sandra Bullock won an Oscar playing her...) claiming they made millions off him in a conservatorship. The Tuohys in turn denied the allegations while adding that they will end the thing anyway.
Greta Gerwig's latest film, aside from being a huge commercial success (it hit $1 billion at global box office, became Warner Bros.'s highest-grossing film domestically, surpassing The Dark Knight, which was ironically created by the same guy who directed #4, and also became the studio's second highest-grossing film worldwide, only behind a certain magical boy) and a paradise for those obsessed with the colour pink, turned out to also be incredibly well made, with great jokes, great cast and some important messages regarding patriarchy and feminism. Perhaps the only missed opportunities were a song by Pink and Ken getting hit in between the legs and not being affected by it. Instead, we got Ryan Goslingsinging himself so I believe that's (K)enough.
She'll steal the smile right out of your face (August 20 to 26)
Windham Lawrence Rotunda followed the wrestling legacy of father Mike Rotunda, using the ring names Bray Wyatt, Husky Harris, and The Fiend, and sadly has now joined the list of premature professional wrestling deaths by dying of a heart attack at just 36. Wyatt moved away from the public eye after Royal Rumble in January, and his family has stated that it was the result of COVID-19 worsening a pre-existing heart condition.
On August 23, India became the first country to land a spacecraft near the south pole of the Moon and the fourth country ever to pull off a soft landing on the Moon with this mission. Over the next two weeks, the rover from the mission will gather information about an area of the Moon which is expected to contain water and other resources that could make it a suitable location for a Moon base.
This American entrepreneur and politician who wants to become president next year has been getting more attention in the lead up to the first debate of the Republican primaries.
The Russian leader of the Wagner Group has died following a plane crash which killed nine other people on August 23, just two months after the group's rebellion against the Russian military. Prigozhin was killed on the the flight along with other prominent Wagner figures Dmitry Utkin and Valery Chekalov. Some people believe the plane was deliberately shot down by Russian air defences on the order of Vladimir Putin, who probably would have called it a "special plane landing operation".
Last week's topper continues to pull in money and views. The film stars Sunny Deol in a historical action flick set during the Indo-Pakistani War of 1971.
This action thriller starring Rajinikanth may be behind the above on Wikipedia, but it continues to hold on to its lead at the box office, at least for now.
Five years after her arrest for attacking and killing infants during her time as a nurse, this British serial killer was sentenced to life imprisonment with a whole life order, the most severe sentence possible under English law, becoming the fourth woman in UK legal history to receive such a sentence.
Christopher Nolan's biopic crossed the $700 million mark at the worldwide box office, and then became the fifth-biggest R-rated film worldwide, surpassing a scarier film.
The DC Extended Universe is about to be folded/rebooted, but the DC Universe honchos have stated that they will incorporate the hero of one of its last movies, Xolo Maridueña's Jaime Reyes, a Mexican-American who gets superpowered armor from an extraterrestrial device resembling a scarab. Reviewers responded well to the comedic and family-focused approach, and Blue Beetle ended Barbie's streak atop the box office, albeit now it remains to be seen if the movie will avoid the financial disappointments of Shazam! Fury of the Gods and The Flash (it should at least get a positive response south of the border, as the movie is so Mexican there are references to María la del Barrio and El Chapulín Colorado!).
These lists exclude the Wikipedia main page, non-article pages (such as redlinks), and anomalous entries (such as DDoS attacks or likely automated views). Since mobile view data became available to the Report in October 2014, we exclude articles that have almost no mobile views (5–6% or less) or almost all mobile views (94–95% or more) because they are very likely to be automated views based on our experience and research of the issue. Please feel free to discuss any removal on the Top 25 Report talk page if you wish.
In spite of being overlong and having high content ratings, Christopher Nolan's latest movie has been a box office phenomenon, even leading Mission: Impossible – Dead Reckoning Part One to underperform as it took IMAX screens away from Tom Cruise's latest showcase of death-defying stunts.
Summer in the Northern hemisphere leads to tropical cyclones. The ones that affect Asia are called typhoons, and this year's most damaging has been Typhoon Doksuri.
Hurricane Dora led to dry, gusty conditions in the islands of Hawaii, particularly Maui, leading to wildfires that caused extensive damage and a few hundred deaths.
As mentioned above, on July 26-28 the Nigerien presidential guard detained president Mohamed Bazoum, and presidential guard commander general Abdourahamane Tchiani proclaimed himself the leader of a new military junta. Bazoum and his family are still being held hostage in the presidential palace.
The Pacific cyclones that hit the Americas are hurricanes, with the strongest being Dora (see above) and Hilary. Wonder if next month it'll be time for 2023 Atlantic hurricane season to enter the most edited.
.jpg)
_-_10.jpg)
.jpg)
_(cropped).jpg)
.jpg)
.jpg)
.jpg)
.jpg)
_(17).jpg)