Jump to content

Wikipedia:Village pump (miscellaneous)/Archive 71

From Wikipedia, the free encyclopedia

Interesting question about edit counts

Most of us know that Steven Pruitt is the editor with the most edits, but which (legitimate, not spam or vandalism) IP user has the most edits? – Ilovemydoodle (talk) 08:04, 26 June 2022 (UTC)

It might have been the editor we called 64.40. The editor was on a dynamic IP (e.g., User talk:64.40.54.88 and Special:Contributions/64.40.54.88, but also dozens of others). Special:Search/prefix:User talk:64.40 turns up 276 pages, so if every IP was got a message (doubtful) and there were an average of 20 edits each (I've not made a systematic search), that would be more than 5000 edits. WhatamIdoing (talk) 18:03, 27 June 2022 (UTC)
Total of 13644 live and 529 deleted edits from ips in 64.40.0.0/16. 64.40.230.100 has the most live edits among them at 505. —Cryptic 19:16, 27 June 2022 (UTC)
24.143.224.15 has 47224 live edits. Still looking, as least through IPv4. —Cryptic 19:46, 27 June 2022 (UTC)
OK, can't speak to legitimacy without looking at the actual edits, but the five individual ips with the most edits are 84.90.219.128 (52984), 208.81.184.4 (50079), 24.143.224.15 (47224), 50.26.172.216 (39563), and 204.153.84.10 (28507). Another 53 have 10000 or more, including - amazingly - two individual IPv6 addresses, 2601:188:180:B8E0:65F5:930C:B0B2:CD63 (15229) and 2001:569:70DD:7500:39EA:19D8:DF90:EF4D (10810). I'll run another query for IPv6s grouped by /64 subnet. —Cryptic 22:05, 27 June 2022 (UTC)
quarry:query/63562. The highest edit-count IPv6 /64 subnet is 240D:1A:4B5:2800::/64, at 76605. —Cryptic 23:01, 27 June 2022 (UTC)
@Cryptic: Could you make a list like this but for IPs? – Ilovemydoodle (talk) 12:15, 28 June 2022 (UTC)
Special:Contributions/70.29.210.242 also is relatively high. – Ilovemydoodle (talk) 07:24, 5 July 2022 (UTC)

Change the Story

Hi folks,

I'm writing here to let you know that there is a banner campaign for the Change the Story campaign. It is a collaboration between WikiProject Women in Red, Wikimedia UK, and CHANGE International. The banner is intended to draw attention to the representation of women and efforts to improve it. As part of that the banner will appear to people in the UK (anon and logged-in editors) between 6 July and 31 July. Richard Nevell (WMUK) (talk) 19:27, 6 July 2022 (UTC)

see meta:CentralNotice/Request/Change_The_Story_(July_2022). — xaosflux Talk 01:44, 7 July 2022 (UTC)

Interview study: request for interview those who have knowledge of Flagged Revisions or TorBlock extension

Hello everyone, my name is Chau Tran. I am a PhD student in the United States. We are conducting an interview study about moderation policies in Wikipedia, regarding the use of FlaggedRevs (https://meta.wikimedia.org/wiki/Flagged_Revisions) and TorBlock extension (https://www.mediawiki.org/wiki/Extension:TorBlock) in a number of wiki languages. I would like to contact those who knowledge of or experience with at least one of these softwares to ask more questions. The interview study will take approximately an hour and as a token of our gratitude, we will send you a $25 giftcard (from Amazon or a company of your choice) to compensate for your time. Please contact me at via Email User feature if you are interested. For more information about our study, you can take a look at this meta research page: https://meta.wikimedia.org/wiki/Research:Understanding_Wikipedia_Moderation_Policies. Thank you in advance! — Preceding unsigned comment added by Chautrannyu (talkcontribs) 15:00, 7 July 2022 (UTC)

Election compass

The WMF has invited community members to propose statements to use for an "Election Compass" to support the 2022 board selection.

Quoting the WMF email:


An Election Compass is a tool to help voters select the candidates that best align with their beliefs and views. The community members will propose statements for the candidates to answer using a Lickert scale (agree/neutral/disagree). The candidates’ answers to the statements will be loaded into the Election Compass tool. Voters will use the tool by entering in their answer to the statements (agree/disagree/neutral). The results will show the candidates that best align with the voter’s beliefs and views. Here is the timeline for the Election Compass:

July 8 - 20: Community members propose statements for the Election Compass

July 21 - 22: Elections Committee reviews statements for clarity and removes off-topic statements

July 23 - August 1: Volunteers vote on the statements

August 2 - 4: Elections Committee selects the top 15 statements

August 5 - 12: candidates align themselves with the statements

August 15: The Election Compass opens for voters to use to help guide their voting decision

The Elections Committee will select the top 15 statements at the beginning of August. The Elections Committee will oversee the process, supported by the Movement Strategy and Governance team. MSG will check that the questions are clear, there are no duplicates, no typos, and so on.


Also see the Meta page on the Election Compass. Statements can be proposed here. Andreas JN466 11:41, 10 July 2022 (UTC)

Everscale article moved to draft.

Hello dear moderators. I saw that Everscale article was moved to draft, the reason given was that the article had few authoritative sources, however on https://wiki.riteme.site/wiki/Wikipedia:Reliable_sources/Perennial_sources pages I see some of reliable sources which have publications/articles/news about Everscale. For example, Bloomberg, Insider, Kommersant, Forbes, Entrepreneur etc. You can read more about it on Draft_talk:Everscale page. Please help solve the issue. Sebirkhan 💪🏿💪🏾Sebirkhan💪🏿💪🏾|talk 20:59, 17 June 2022 (UTC)

You can move this advertisement back to main space if you want, but don't be surprised if it is then nominated for deletion at WP:AFD. Do you really think that being in the top two hundred blockchains is an indication of notability? Maybe being in the top two is. Phil Bridger (talk) 21:12, 17 June 2022 (UTC)
I can tell you about other projects that are on wikipedia and have less citations and media coverage. But I know what you will say about Wikipedia not being an argument. On the other hand, it's weird. Sebirkhan (talk) 10:43, 18 June 2022 (UTC)
If you tell us about these other offending articles we can see that they get deleted, too. This would remove the oddity you mention.--User:Khajidha (talk) (contributions) 19:16, 19 June 2022 (UTC)
Ok, for example MazaCoin, Namecoin, Peercoin, Kin (cryptocurrency) and so on.
Also, lots of reliable sources writes about Everscale, for example CNBC:
Sebirkhan (talk) 07:53, 23 June 2022 (UTC)
Hello again, can you solve this problem? Sebirkhan (talk) 07:41, 30 June 2022 (UTC)
If the "problem" can be solved then you are the best person to solve it. Just find some proper independent reliable sources following the advice given on your talk page, add them to the draft and submit it for review. Phil Bridger (talk) 08:13, 30 June 2022 (UTC)
Is CNBC independent reliable source? Sebirkhan (talk) 11:16, 1 July 2022 (UTC)
Article by CNBC
https://www.cnbcindonesia.com/tech/20220705141521-37-353103/begini-cara-blockchain-tetap-berkembang-saat-market-down Sebirkhan (talk) 09:04, 5 July 2022 (UTC)
Let's stop talking about Praxidicae's actions behind her back. * Pppery * it has begun... 13:27, 5 July 2022 (UTC)
I mean, I stand by my draftification, it's complete non-notable crypto spam. PRAXIDICAE🌈 14:08, 5 July 2022 (UTC)
Hi there! @Praxidicae, @Phil Bridger I'm sysop from tr:wiki there is also an article about this coin Turkish Wikipedia and we are still examining the conflict of interest. Check what we found: [1] also turkish article created by same user on tr:wiki. 𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 17:10, 11 July 2022 (UTC)
I think it's probably the same issue in any language. :) PRAXIDICAE🌈 17:11, 11 July 2022 (UTC)
By the way the forbes source is not reliable because created by contributer and there is a warn about this "Opininons expressed by Forbes Contributors are their own". 𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 17:35, 11 July 2022 (UTC)
I don't think there's much to discuss here. This is obvious spam, and the only possible complaint is that spammers of some other cryptocurrencies haven't been caught so quickly. Phil Bridger (talk) 18:17, 11 July 2022 (UTC)
I understood you all, we can come back to this question later, In addition, Everscale is starting a week of hackathons in Eastern Europe from tomorrow. I'm sure a lot of independent media will write about it. We will post when we have enough. However, You still have not written a clear answer about CNBC article. Sebirkhan (talk) 10:48, 13 July 2022 (UTC)

Mainly sports-related: "Qualify/qualifies/qualified/[a/the] qualification to" not "for" ?

I have seen too many or thousands of, mostly sports-related, articles or tables with the following, before a name of competition or tournament rather than an action verb like do: "To" instead of "for" after "qualify/qualifies/qualified automatically/directly"; "[a/automatic/direct/the] qualification(s) to" which isn't preceded by certain nouns like give or grant, e.g. "automatic qualification(s) to [a certain cup or league]"; they're more than a grammatical matter, it could be difficult if not arduous to replace such instances on each of those pages. Why were they created or expanded with such syntax?! Santiago Claudio (talk) 09:22, 12 July 2022 (UTC)

There is always a lot of variation in how a language is actually used. As long as communication is not significantly impacted, there is no problem. Are there cases that you are aware of where the constructions you are complaining about have hindered understanding of articles? I know I have been surprised in the past to learn that my understanding of what a word or a sequence of words meant was not shared by a significant number of other (native) English speakers. - Donald Albury 14:40, 12 July 2022 (UTC)
Always be aware that there are different varieties of English. Are you seeing "qualify for" in articles about, say, American athletics, and "qualify to" in articles about British or Indian athletics? ~ ONUnicorn(Talk|Contribs)problem solving 15:56, 12 July 2022 (UTC)
Whether in Britain or India or the US of America, it's grammatical to express "qualify/qualified for a thing" and "(has been/is/was) qualified to do a thing"! Santiago Claudio (talk) 12:14, 14 July 2022 (UTC)

Wikimedia Foundation Human Rights Impact Assessment

<translate> Human Rights Impact Assessment (English)

On 12 July, the Wikimedia Foundation announced the publication of its Human Rights Impact Assessment. (Production of the public version of this 2020 report was delayed by Covid.)

This is the document that has driven a number of recent developments over the past couple of years, like the UCoC, Human Rights Policy, etc. It also includes a number of other priority recommendations, the status of which is indicated on the Meta talk page. A number of them will require community input. Andreas JN466 18:56, 15 July 2022 (UTC)

Why always feature articles about West ? Why don't show things from Asia, Africa or South America as well ? Tired of seeing featured things about England, Europe and America. Bring some diversity. Don't be racial or western aligned biased . Does Wikipedia cater just to White people ? — Preceding unsigned comment added by Kiddo Learner (talkcontribs) 04:15, 11 July 2022 (UTC)

There are many fewer editors & sources interested in these areas, so fewer FAs get written about them. It has little to do with racism per se, I think. Jo-Jo Eumerus (talk) 08:11, 11 July 2022 (UTC)
Also, not so much individual bias as the relative lack of accessible reliable sources about subjects outside the English-speaking world and of editors interested in finding such sources. Like many editors in the U.S., I am not fluent in any other language, and so rely on sources that are available in English. - Donald Albury 15:03, 11 July 2022 (UTC)
@Kiddo Learner: how about you improve an article to FA standard. If someone complains something is missing, the answer is that they didn't put it there. Graeme Bartlett (talk) 11:07, 12 July 2022 (UTC)
This is a volunteer-run project, so has all the biases that exist among us self-appointed volunteers. It would be great for people to write featured articles about things from Asia, Africa or South America, but that takes work from the people who are interested in those subjects and are familiar with the reliable sources that write about them. If that describes you, then please get to work addressing our biases - the articles won't write themselves. If, however, you have any evidence that our procedure for promoting articles to featured status is at all racist then such evidence should be presented here and taken seriously. Phil Bridger (talk) 16:50, 12 July 2022 (UTC)
If you're interested in reading more about the state of bias on Wikipedia, Wikipedia:Systemic bias lays out various structural biases present in Wikipedia and how they manifest themselves, as well as efforts to reduce them. signed, Rosguill talk 17:06, 12 July 2022 (UTC)
@Kiddo Learner Make sure you check the TFAs for July 18 (Khalid ibn al-Walid) and July 28 (Thalassodromeus - from Brazil). Not everything is about England, Europe, and America. Although looking at the TFA queue for July, England Europe and America are certainly disproportionally represented.
As others have pointed out, there is a big problem with systemic bias on Wikipedia. Part of it is due to the availability of sources, and part of it is because Wikipedia is written by volunteers in their spare time who tend to write about things they either know something about or want to learn more about and have ready access to sources about. TFA is intended to feature the best quality articles produced by this community, and such articles are invariably a labor of love. It seems kind of glib to respond to complaints such as yours by saying "if you want to see articles about X featured, write them!" but ultimately, that's what needs to happen. If articles about, say, fungus species in caves in south Asia, or the traditional beliefs of tribal societies in the Amazon, or major construction projects in Africa are to become featured, someone needs to care enough to take the time to 1. learn how to edit Wikipedia, 2. do the research, 3. write the article 4. submit the article to the featured article process 5. improve the article based on the feedback from the FA reviewers 6. continue to maintain the article after it has become a FA. If you care about these things and want to see them on the main page - write them. Be warned, the journey is difficult, but you will learn and grow along with the encyclopedia. ~ ONUnicorn(Talk|Contribs)problem solving 17:29, 12 July 2022 (UTC)
I don't think that most people (even most editors) understand how an article becomes Wikipedia:Today's featured article. I suspect that they assume that the process is something like you would see in a newspaper or magazine:
  • Alice decides that _____ would be a good topic for the front page.
  • Alice assigns Bob to write a great article about _____.
  • Alice and Carol review Bob's article, and if they decide that it's good enough, they put _____ on the front page.
Alternatively, they might imagine something like this:
  • There are so many great articles on Wikipedia already.
  • Alice decides that it would be a good idea to have an article about food.
  • Alice looks through the hundreds of great articles about food and picks out her favorite articles.
  • Alice puts Gumbo on the front page.
The actual process is more like this:
  • Bob decides, of his own free will and without consulting anyone, to write a great article about his favorite subject (and actually has the knowledge, skills, time, images, sources, etc. to be successful at it).
  • Bob has heard of this Wikipedia:Featured articles thing and chosen to make his article fit the Wikipedia:Featured article criteria.
  • Bob submits his article to FAC and spends weeks talking to other people about it. He eventually convinces enough of them that it's a great article, and wins his FA star.
  • Alice and Carol look over the (short and shrinking) list of pre-approved FAs, and say "Well, it's either Bob's hobby or another one on hurricanes, so we might as well run Bob's tomorrow and the hurricaine next week."
Think about how surprising this process must be to people who are expecting a more normal, curated approach to a website. WhatamIdoing (talk) 17:57, 12 July 2022 (UTC)
I think a part of the surprise is in the name. We say "featured" but mean "top quality", and there is no indication for outsiders that we only feature top quality articles on the Main Page instead of, say, interesting and diverse articles of decent quality. —Kusma (talk) 18:25, 14 July 2022 (UTC)
@Kusma I think I raised this point before (probably as a different IP) but I'll say it again - the entire Wikipedia content grading process is a confusing mess of jargon and is completely inaccessible and incomprehensible to people who are not active members of the editing community. Go ask some random person "which is better, a start class Wikipedia article or a stub class Wikipedia article?", it isn't obvious. Ditto for "Featured" vs "Good" articles, it isn't even obvious that "Featured" is a quality grade. Then you get into the whole mess of the alphabetical quality ratings, the confusing "A class is better than good article" setup despite it not having any kind of formal review process, different wikiprojects using different selections of grades etc. Really the whole system needs a rethink, but it's probably one of those things that is too ingrained into the site to change now. 163.1.15.238 (talk) 14:09, 15 July 2022 (UTC)
"Today's Featured Article" looks like it means "the article featured on the Main Page today", not "today's selection from the list of articles that are classified as 'featured articles'". —Kusma (talk) 18:30, 14 July 2022 (UTC)
  • Kiddo, if you think the lack of broad coverage is troubling, grab a computer and some books and join us in writing. Most of my FAs concern non-Western things, and I've only written 10 and it took me 6 years to get there. -Indy beetle (talk) 11:11, 15 July 2022 (UTC)
As a TFA coordinator, I can say we are entirely dependent on what articles the community chooses to write as we do not have discretion to run non-featured articles. Perhaps the foundation could motivate the writing of FAs on the Global South through grants.--Wehwalt (talk) 12:07, 15 July 2022 (UTC)
I'll never apologise for the amount of cue sports FAs there are to choose from. There are really three options available:
  1. Make TFA simply be a choice of a random page to feature. Perhaps "Today's Random Page", or similar. There is an argument for "Today's Good Article" if quality is the issue, it would make the pool larger.
  2. Promote articles on under represented topics
  3. Appreciate the work that has been put in by those creating FAs. Realise that people aren't writing about the topic you want, but rather the topic they want.
I see this argument a lot, and then the FAs are never created in those areas, just a lot of complaining about those creating the FAs currently. I always welcome helping out those writing on other topics, just don't suggest the current work isn't suitable.Lee Vilenski (talkcontribs) 12:22, 15 July 2022 (UTC)
Nor do I for the large number of numismatic articles. Nor should others for hurricanes, or battleships, or fungi, or birds. I simply suggest a way in addition to "write it yourself" that the complainers can act, if they. want to.--Wehwalt (talk) 12:41, 15 July 2022 (UTC)
  • A different problem in getting some topics featured is the lack of qualified reviewers with non-English proficiency to be able to do an adequate source review. In the Spanish-language area-- and not only at FAC, but also at DYK and GA-- I am frequently shocked at what is slipping through when reviewers can't or don't read non-English-language sources. SandyGeorgia (Talk) 14:34, 15 July 2022 (UTC)
    I agree. I noticed a while ago few (now forgotten) EN living person articles that quoted ES sources, and didn't have an equivalent ES article. I don't spea Spanish, but the babelfish translations showed them as being non-notable. Wikipedia:Verifiability - Wikipedia states a preference for sourced vs EN speaker vs machine translation,
    So having a featured article from non EN sources, where the weighting of importance is made by non-native speakers could lead to embarassmentWakelamp d[@-@]b (talk) 12:53, 16 July 2022 (UTC)
    If the language involved is one frequently known by English Wikipedia editors (the major European languages and a few others) then the only obstacle is that it takes a bit longer to find someone who can look at the sources, but when the language is more obscure (to us, of course no language is obscure to the people brought up using it) the problem gets difficult, because more than one person should be involved in determining whether an article becomes featured. Phil Bridger (talk) 18:29, 17 July 2022 (UTC)

Please discuss at Talk:Main Page#Formal proposal to add "About" link to TFA blurb on main page. SandyGeorgia (Talk) 12:10, 17 July 2022 (UTC)

Thoughts on feature request originally made on phabricator

Moved from WP:VPR

What are your thoughts on this feature request? – Ilovemydoodle (talk) 19:55, 14 July 2022 (UTC)

@Ilovemydoodle: moved from VPR as this isn't a proposal for something that the English Wikipedia has anything specific to do about at this point. — xaosflux Talk 20:08, 14 July 2022 (UTC)
Good idea in theory, but it's an idealistic goal that was first requested in 2006 and will most likely never be implemented. * Pppery * it has begun... 20:10, 14 July 2022 (UTC)
Well, if we get enough consensus here, they will probably add it. – Ilovemydoodle (talk) 11:04, 16 July 2022 (UTC)
@Ilovemydoodle there is nothing blocking this on community consensus right now. You can try to get traction for it in the next wishlist, drop a note at meta:Community Wishlist Survey/Sandbox. — xaosflux Talk 12:45, 16 July 2022 (UTC)
@Xaosflux: I know this is unrelated, but, do you know any importers? I really need one for a discussion. – Ilovemydoodle (talk) 12:51, 16 July 2022 (UTC)
If you need help with imports you can post at WT:RFPI. — xaosflux Talk 16:58, 16 July 2022 (UTC)
Importers, not imports. – Ilovemydoodle (talk) 11:43, 17 July 2022 (UTC)
@Xaosflux: I mean, who are the importers? (I am looking for technical information about import) – Ilovemydoodle (talk) 16:41, 17 July 2022 (UTC)
Special:ListUsers/import - we don't use this function extensively on this project. The best place to ask questions about how import is used here on the English Wikipedia is WT:RFPI; For general technical help with import you may want to start at mw:Help:Import. — xaosflux Talk 17:24, 17 July 2022 (UTC)

When were the 5 WP pillars first stated?

The earliest verion is 2007 on WP. Is there an early history of WP? I am particulalry interested in who put in the word 'Meciless' Wakelamp d[@-@]b (talk) 15:42, 16 July 2022 (UTC)

Special:Permalink/13207659 is a version of Wikipedia:Five pillars dated 2005-05-04 with the edit comment, "New simple policy page". -- RoySmith (talk) 15:48, 16 July 2022 (UTC)
Look like "mercilessly" was added a few weeks later in Special:Permalink/14525251 by Lethe. -- RoySmith (talk) 15:57, 16 July 2022 (UTC)
The idea of content being edited "mercilessly" has a very long history here. It was in the first editable version of the copyright warning in December 2003 and was on the edit toolbar until September 2009. With the assistance of an old database dump I found out that the word "mercilessly" was on the "Be bold" page from March 2002 until September 2006. The earliest use of the word I can find in the context of discussion about Wikipedia from this search on the Nostalgia Wikipedia is a user essay from 2001 that is best read in its original form on that site. Graham87 04:24, 17 July 2022 (UTC)
This is related to this idea lab discussion. Graham87 04:50, 17 July 2022 (UTC)

Movement Strategy and Governance News – Issue 7

Movement Strategy and Governance News
Issue 7, July–⁠September 2022Read the full newsletter


Welcome to the 7th issue of Movement Strategy and Governance News! The newsletter distributes relevant news and events about the implementation of Wikimedia's Movement Strategy recommendations, other relevant topics regarding Movement governance, as well as different projects and activities supported by the Movement Strategy and Governance (MSG) team of the Wikimedia Foundation.

The MSG Newsletter is delivered quarterly, while the more frequent Movement Strategy Weekly will be delivered weekly. Please remember to subscribe here if you would like to receive future issues of this newsletter.

  • Movement sustainability: Wikimedia Foundation's annual sustainability report has been published. (continue reading)
  • Improving user experience: recent improvements on the desktop interface for Wikimedia projects. (continue reading)
  • Safety and inclusion: updates on the revision process of the Universal Code of Conduct Enforcement Guidelines. (continue reading)
  • Equity in decisionmaking: reports from Hubs pilots conversations, recent progress from the Movement Charter Drafting Committee, and a new white paper for futures of participation in the Wikimedia movement. (continue reading)
  • Stakeholders coordination: launch of a helpdesk for Affiliates and volunteer communities working on content partnership. (continue reading)
  • Leadership development: updates on leadership projects by Wikimedia movement organizers in Brazil and Cape Verde. (continue reading)
  • Internal knowledge management: launch of a new portal for technical documentation and community resources. (continue reading)
  • Innovate in free knowledge: high-quality audiovisual resources for scientific experiments and a new toolkit to record oral transcripts. (continue reading)
  • Evaluate, iterate, and adapt: results from the Equity Landscape project pilot (continue reading)
  • Other news and updates: a new forum to discuss Movement Strategy implementation, upcoming Wikimedia Foundation Board of Trustees election, a new podcast to discuss Movement Strategy, and change of personnel for the Foundation's Movement Strategy and Governance team. (continue reading)

Xeno (WMF) (talk) 00:27, 17 July 2022 (UTC)

Reducing steps required to contribute

I've recently noticed a pattern in my own actions where for every extra step required to do something, I become roughly half as likely to complete the task, even if each individual step is simple. Unfortunately, many tasks essential to Wikipedia editing require multiple steps, often in a seemingly unnecessary manner. I'm thinking right now about the AFC process (from the perspective of new editors), uploading images to Commons, figuring out template parameters, etc., but those are just examples quickly coming to mind, and there are a lot more where that came from. What can we do to reduce the number of steps required to do basic actions, for both beginners and experienced editors? Yitz (talk) 20:51, 12 July 2022 (UTC)

These are necessary steps though, this is why WP:ACPERM was enacted. As far as commons, well, that's a matter to be dealt with there. PRAXIDICAE🌈 20:56, 12 July 2022 (UTC)
@Praxidicae I doidn't intend to imply that we should get rid of the AFC process; it's there for a reason! That being said, most of the steps within and leading to the AFC process are quite convoluted, and can be dramatically improved, imo. See my comment(s) below for more details. Yitz (talk) 05:48, 14 July 2022 (UTC)
I've been creating and editing articles for a long time, and I guess I'm just used to the requirments. I will admit that it can take me an hour to add a paragraph to an article, and several days to create a new article (I have been working on expanding one article for over a month, now, off-and-on, and am maybe half-way through). The problem I see is how would we streamline the process without short-cutting the requirements for verifiability, notability, reliable sources, proper formatting, etc?. - Donald Albury 21:04, 12 July 2022 (UTC)
Both creating articles and uploading images involve some amount of specialist understanding of Wikipedia to do correctly; that there is some friction in the process for people who don't have that understanding is perhaps no bad thing. Making templates easier is possibly a more valuable thing to prioritize – I don't know if that's something which the visual editor could do more to help with for people who aren't comfortable with wikitext? Caeciliusinhorto-public (talk) 11:46, 13 July 2022 (UTC)
Both creating articles and uploading images involve some amount of specialist understanding of Wikipedia to do correctly...
hi @Caeciliusinhorto-public! This is just a quick note to say: what you shared in the bit I've quoted above resonates with me! In fact, the issue I understand you to be naming about how difficult it can be for people who are new to understand, let alone become aware of, the policies/guidelines that ought to guide how they make a particular change is something the Editing Team is planning to work on in the coming months.
Seeing this conversation (thank you, @Whatamidoing (WMF)) was the reminder I needed to prioritize publishing a project page on mediawiki.org about the work the Editing Team is planning to do so that insightful volunteers like you, @Donald Albury, @Praxidicae, and @Yitz can help us shape it.
In the meantime, I've added what you said above to the ticket in Phabricator where we are starting this work: phab:T265163#8075893. PPelberg (WMF) (talk) 18:48, 13 July 2022 (UTC)
@PPelberg (WMF) Thanks for the great work you do! I look forward to seeing what comes of this... :) I'm going to try to go through the AFC process roleplaying as if I were a beginner, and will narrate that experience below; hopefully I'll be able to pick up on some specific trouble areas that way. Yitz (talk) 19:25, 13 July 2022 (UTC)
Okay, so as a newcomer let's say I start at the main page, and I want to write an article about someone I know who's mildly famous (using this example because it's the most common topic non-wiki friends ask me about). I'll use my father (Rabbi Gershon Litt) for specifics, since he's on the edge of notability, I have a genuine conflict of interest there (both very common for topics beginners are attracted to), and I won't be throwing away a topic others are likely to create a page for.
The first thing I do is probably click on the "Help" link, or maybe "Learn to edit," looking for a way to add an article.
If I start with the latter, I'll almost certainly click on the big blue "Get Started" button, which leads to Help:Introduction to Wikipedia—which has no information on creating a new page, so I'll head back. Maybe instead I'll click on one of the two "Editing" buttons, which leads to Help:Introduction to editing with VisualEditor/1 or its markup editor equivalent. Both have a link to a page titled "Creating new articles"—now we're getting somewhere, four steps in! That page (finally) has a link to the Wikipedia Article Wizard, which seems pretty simple to work with, so I'll pause here for now.
Let's say I start with the "Help" link instead. This is a lot better: there's the clearly-labeled section "Create a new article or upload media," which prominently links to Help:Your first article and the Wikipedia Article Wizard. Far fewer steps with no obvious decrease in readability!
[My take here so far is that the "learn to edit" link should be taken off the left tab by default, as it seems to be an actively frustrating experience to navigate if you don't already know the material, and the "help" page links to the same stuff already. The redundency just gives me decision fatigue / analysis paralysis.]
So we've finally stumbled upon the Wikipedia Article Wizard, after our difficult journey. What then? I go through the steps it presents me, answering as accurately as I can for the goal of writing about my father. I'm led to this page on disclosing COI editing, which tells me to "Edit your user page by clicking here." I click the link, and BOOM—I get a "Permission error"! I'm editing as an IP address, you see, because I'm a newcomer who was told on the main page that "anybody can edit" Wikipedia. And IP addresses can't make user pages. Okay, no problem, that's just a simple extra step (or steps) of creating an account for myself. I do all that, and return to the article creation Wizard (assuming I can find it again). I still need to disclose on my user page, but at this point I'm feeling lazy and I haven't written a single word yet, so I decide to skip that for now and hope nobody cares enough to call me out on it. I falsely press the "I have disclosed" button (while cackling like the supervillian I am), to be greeted with this page, which gives me three options:
If you haven't tried option 1 before, it's worth pointing out here that such article requests almost never get made, and even if they do, it can be a period of months or even years before anyone bothers to reply. This is pretty much a graveyard of unanswered requests for articles. For my father, who's a Rabbi, I found myself going to Wikipedia:Requested articles/Biography/By profession#Judaism, where I was told to instead head to Wikipedia:Requested articles/Biographies/Jewish figures#Jewish philosophers, rabbis, cantors, where I see a few dozen redlinked Rabbis, and a page where the revision history shows edits from 2014 on its first page. In short, a dead end.
If I press the link on option 2, I'm directed towards Wikipedia:Edit requests, a page that's pretty impenetrable for an unexperienced editor. If I manage to make it all the way through that page, I find myself being directed to the Edit Request Wizard, which honestly looks pretty helpful! [why wasn't I linked directly to this from the other Wizard?] I go through the Wizard until I reach Wikipedia:Edit Request Wizard/COI, where I insert "Gershon Litt," the name of the page I want to see created, into one of the two input boxes given. No matter which one I use, the result is the same. I'm led to a talk page for a currently non-existent article, containing this helpful warning that the page will shortly be deleted by an administrator.
(I need to leave for an event, will add more here later) Yitz (talk) 20:44, 13 July 2022 (UTC)
Continuing where I left off...
Clearly, requesting someone else to make a page about my beloved father isn't going to go anywhere. I go back to where I left off in the article creation Wizard, and press the "Next" button. I enter "Gershon Litt" into the textbox, and finally...I arrive at a blank draft page, with a few basic instructions on top. Nice!
I may be [role-playing as] a beginner to Wikipedia editing, but I'm not stupid. I go try to find a Wikipedia page that looks similar to what I'm going to want mine to look like, to be able to reference the writing style and markup used there. I find a page on Rabbi Joshua Berman; looks close enough. Using the visual editor (which I got a pop-up asking if I wanted to use, though it was unclear what it was), I quickly add some info I think is relevant, and use the "cite" button to add citations. I also threw in a questionable citation to a website with an obvious COI (it's the first citation on the page), because I've never seen a beginner not make that mistake at least once. I admit I wasn't super careful to keep things to what I'd expect a beginner to write here, though I tried to be looser than I normally would, with some lightly promotional language (another common and usually honest mistake) at the end of the first paragraph. I decided to publish the draft page here to allow for reference, though I won't submit it to AFC and clog up the backlog unless others want me to do that for some reason. What I would expect to happen if I were to submit the draft for review is that I would be rejected for the flaws I included in the draft, even though those flaws are probably resolvable by future editors, and likely wouldn't get the page removed if it were already an article in Mainspace. Perhaps I'm wrong about that, but that is my intuition.
I hope this role-play is helpful in illustrating some flaws of the current system, and I remain hopeful that with some effort we can make this process much easier and less stress-inducing than it currently is. All the best, Yitz (talk) 05:45, 14 July 2022 (UTC)
I agree the AFC process is awful for new editors. It's not succinct, and the help is not provided where needed, they aren't told that there is nearly no chance their article will survive. They spend a few hours creating a page, save it, an then it's reviewed by the NPP using automated tools (which the new editor does not have access to) and marked for deletion within 5 minutes.
If a new editor does create a page that satisfies WP criteria then they are very suspect. Yes they right about their mum, but we should head them off. There was a WMF analysis that showed that most never edit agai after their article is deleted Wakelamp d[@-@]b (talk) Wakelamp d[@-@]b (talk) 13:16, 16 July 2022 (UTC)
Perhaps the default should be to move such articles to drafts (along with a friendly message giving access to further help) instead of deleting them..? It wouldn’t solve the problem, but it might help mitigate it somewhat. Yitz (talk) 03:15, 17 July 2022 (UTC)
Research also says the Draft: namespace is basically where articles go to die. (I assume – but am unaware of any research on this point – that the same effect is true for userifying the article.)
If it's a notable subject and left in the mainspace, then other editors are more likely to edit the page. This editing can feel aggressive (e.g., blanking 90% of content, adding a stack of maintenance tags) but it might be better at editor retention than the available alternatives. Whatamidoing (WMF) (talk) 20:44, 18 July 2022 (UTC)

Cross-wiki post

Could any help here? – Ilovemydoodle (talk) 08:56, 18 July 2022 (UTC)

Announcing the six candidates for the 2022 Board of Trustees election

You can find this message translated into additional languages on Meta-wiki.

Hi everyone,

The Affiliate voting process has concluded. Representatives from each Affiliate organization learned about the candidates by reading candidates’ statements, reviewing candidates’ answers to questions, and considering the candidates’ ratings provided by the Analysis Committee. The selected 2022 Board of Trustees candidates are:

You may see more information about the Results and Statistics of this Board election.

Please take a moment to appreciate the Affiliate Representatives and Analysis Committee members for taking part in this process and helping to grow the Board of Trustees in capacity and diversity. These hours of volunteer work connect us across understanding and perspective. Thank you for your participation.

Thank you to the community members who put themselves forward as candidates for the Board of Trustees. Considering joining the Board of Trustees is no small decision. The time and dedication candidates have shown to this point speaks to their commitment to this movement. Congratulations to those candidates who have been selected. A great amount of appreciation and gratitude for those candidates not selected. Please continue to share your leadership with Wikimedia.

Thank you to those who followed the Affiliate process for this Board election. You may review the results of the Affiliate selection process.

The next part of the Board election process is the community voting period. You may view the Board election timeline here. To prepare for the community voting period, there are several things community members can engage with in the following ways:

Best,

Movement Strategy and Governance

This message was sent on behalf of the Board Selection Task Force and the Elections Committee

MNadzikiewicz (WMF) (talk) 18:50, 19 July 2022 (UTC)

Employment opportunities with Wikimedia Foundation as a Community Facilitator

Hello all,

As you may know, I've been working as a community facilitator: for the Universal Code of Conduct Project starting in January 2021, and for the Movement Strategy and Governance team since June 2021. I found these roles to be challenging and fulfilling, and have had wonderful collaborations and built great friendships within the movement during this time. I want to thank everyone who has engaged with the various projects for which I've facilitated over these past 19 months.

Today I am inviting qualified community members to consider applying for this position, as a fresh hiring process has just begun. Among other things, the work will involve engaging with English Wikimedia communities and affiliates, organizing community conversations, gathering feedback, and addressing community questions or requests (escalating feedback as needed).

If you are interested, here is a direct link to this particular role on Greenhouse. If you speak and write Japanese, there is also a role for a Japanese community facilitator. You can visit https://wikimediafoundation.org/about/jobs/ to see other positions as well.

Feel free to let me know if you have any questions.

Sincerely,
Xeno (WMF) (talk) 23:30, 18 July 2022 (UTC)

Hint: Put your username in your cover letter and/or résumé. Whatamidoing (WMF) (talk) 21:11, 21 July 2022 (UTC)

About archiving sources used in article

I am using the journals available at JSTOR in writing some articles. Usually, i see that Bihar related articles are in poor state on Wikipedia and nobody takes care of broken url and dead sources. Many articles also remain there without much sources and lot of grammar related issues. I have a habit of saving the Sources in Wayback Machine, while editing. I do this because, i know if in future that source becomes inaccessible for any reason, nobody is going to correct that. I just want to know that , do we need to use Wayback Machine in case of journals at JSTOR, as per my knowledge, they are there for always? We don't need to care about them (journal at JSTOR) becoming inaccessible to the reviewers in future? Admantine123 (talk) 15:37, 20 July 2022 (UTC)

There is no requirement ("need") to put any reference in to "Wayback Machine" to use it in an article here. — xaosflux Talk 15:44, 20 July 2022 (UTC)
If we're talking about the usual JSTOR situation where the link goes to the entry page for a journal article (i.e. an HTML page with an embedded preview), I don't think the Wayback Machine is going to add much value. Even if the journal article disappears from JSTOR for some reason, the archived page is only going to tell the reader "yes, there used to be a journal article by this name at this URL". That could be useful in some cases, but it still won't allow the reader to check the citation as they could with a Wayback Machine archive of a normal web page. So in general, while there's nothing wrong with archiving those pages, I think it's OK not to. (There would be a stronger case for archiving, I think, in the case of a publicly downloadable PDF hosted on JSTOR.) -- Visviva (talk) 16:13, 20 July 2022 (UTC)
This may be a bit of thread drift, but I was musing on how the real citation is to the paper publication, and, even if the article were no longer available on JSTOR, at least some libraries would have retained the paper issue of the journal, making it theoretically verifiable. Then it occurred to me, have any journals that we regard as reliable sources gone solely digital? - Donald Albury 17:02, 20 July 2022 (UTC)
I would imagine quite a few of those at Category:Online-only journals would qualify, but I'm not sure which if any of those are on JSTOR specifically. -- Visviva (talk) 18:27, 20 July 2022 (UTC)
This may become complicated and costly, and in general perhaps not worth the trouble. JSTOR is a repository, so what is proposed here is 2nd-level archiving, which I don't think exists in Wikipedia, at least formally. Repositories are considered stable archives, and even when repository metadata change (such as a JSTOR id) there may be background redirects to the edited data or the item may be found by searching other JSTOR fields (such as title). It would be very rare for JSTOR items to disappear for reasons other than legal, copyright or the item being given exclusive repository rights on another repository. At least according to their published retention guidelines [2], which partly use a proven digital preservation infrastructure (from Portico). Note the items may be available even if JSTOR ever ceases operations (contingent on funding-at-hand, I suppose). In contrast Wayback Machine/Internat Archive retention policies are unclear, and in rare cases items have been known to disappear without any explanation. JSTOR also includes vast swaths of subscription/registration-only information; preemptively archiving that material in an open access platform, if it can be done, could be a copyvio. 67.247.99.116 (talk) 23:07, 20 July 2022 (UTC)
Thanks to all of you, for giving your precious time here. I am satisfied with the explanation of ip. So, can i conclude that, JSTOR being a repository itself, items are not gonna disappear and i shouldn't care for archiving them. Untill recently, i have used those journal as citation, which have open access via login. Anyone of you, who is interested to check to give any other advice may look at 1970 Bhojpur uprising.Admantine123 (talk) 23:54, 20 July 2022 (UTC)
I note that you create fairly full citations, which is the best insurance against link rot (and you don't unnecessarily link to archive snapshots, which is good). Your full use of quotations is also a plus (you should know that there's a "quote" parameter for citation templates; you also don't need to quote journal article titles, as that is done automatically by the "cite journal" template). I see that you've heavily cited some names in the infobox, which is often considered part of the lead and thus doesn't need so much citing. More of that should be in the article body (note that Ram Naresh Ram and Ramnaresh Dusadh seem to be one and the same, but that isn't made clear). Dhtwiki (talk) 06:02, 21 July 2022 (UTC)
Thanks for your feedback Dhtwiki, i will create a seperate section on leaders of the uprising. This article will take time to expand, as i am busy in my real life too, and working on it in free time. In that section, i will describe that both are same. Also Ram Naresh Ram has a seperate article too, and as i say, it's a stub, nobody had tried to expand it. The guy is a three time Member of legislative assembly.Admantine123 (talk) 09:45, 21 July 2022 (UTC)
At least some JSTOR entries have already been archived at the Internet Archive, such as this one. All that is archived is the index page, so there is no danger of a copyvio. In any case, an index page is useful only for confirming the citation. The information in the citation is what matters. - Donald Albury 00:48, 21 July 2022 (UTC)
Can any one of you help me here with this journal
  • Charvaka (1978). ""No Check on Managements". ” Economic and Political Weekly. 13, no. 1: 8–10. JSTOR 4366261.
Actually the last page of this journal has another article which is named as Class war in Bhojpur 1. But for citing it, when i clicked the citation link at JSTOR, it gave this title and author name. If anyone of you have time. Please edit the 1970 Bhojpur uprising (Source 14). I don't know whether the issue and volume also need to be changed in citation or not . Thanks in advance. The correct title should be class war in Bhojpur and author too is different.Admantine123 (talk) 13:22, 21 July 2022 (UTC)
Are you trying to cite the "Class War at Bhojpur: I" article? It is JSTOR 4366262. 50.75.226.250 (talk) 18:22, 21 July 2022 (UTC)
Yupp brother, btw i corrected it. Admantine123 (talk) 03:24, 22 July 2022 (UTC)

Help needed

In article, which i will be expanding for month, i found a cite error at reference number 8. Someone pls fix it. See here Dalits in Bihar.Admantine123 (talk) 18:28, 23 July 2022 (UTC)

I have fixed the error. Please check that I have done so correctly.
The problem was that there were two separate uses of the ref name HRW ('<ref name="HRW">'). When someone enters '<ref name="HRW"/>', MediaWiki doesn't know which source they are trying to cite, so it generates the error message. The problem is, I also don't know which source was intended. But I have assumed that the refs before the second HRW ref are meant to refer to the first one, and the refs after the second HRW ref are meant to refer to that second ref (which I have renamed "HRW-pattern"). To avoid the problem in the future, I would recommend using more specific ref names. -- Visviva (talk) 21:28, 23 July 2022 (UTC)

Database dump with the very beginning of 9/11's edit history

I'd like a link to a database dump which includes the very first edits to the article about 9/11. 103.166.10.57 (talk) 08:30, 24 July 2022 (UTC)

A comprehensive database dump from that time period is not publicly available and probably doesn't exist, but the earliest history of that article can be found at World Trade Center/Plane crash. I've just imported the redirect edit there from the Nostalgia Wikipedia. Graham87 08:52, 24 July 2022 (UTC)

Creating a new page

Wanting to create a redirect page for a common term, I find we have a new layer of bureacratic form-filling; it has to be a draft, am I a lizard, how many false teeth does my grandmother have? No, I do not do that shit, you will never get another page from me if this is to be the bright New World of conformant droids. — Cheers, Steelpillow (Talk) 07:58, 25 July 2022 (UTC)

Maybe the issue would become more obvious if you reformulated this without the allusions to Little Red Riding Hood and lizardpeople (?), but none of the obvious steps necessary for the creation of the redirect (go to page, paste #REDIRECT [[XY]], click "Publish changes") would seem to involve the draft namespace – certainly not if your account is autoconfirmed, which it is. Dr. Duh 🩺 (talk) 08:42, 25 July 2022 (UTC)
Thanks for the prompt reply, but you misread the problem. The page (in this case, Minus number) is not there to be redirected, it has to be created. That used to be straight forward, now it is not - even for autoconfirmed users. Sorry, wrong grandmother too. ;-) — Cheers, Steelpillow (Talk) 09:41, 25 July 2022 (UTC)
I'm afraid I still don't get it. To my personal embarrassment, I have to admit that I've never actually written an article myself (one of my reasons for finally creating an account, but have yet to get around to it) – however, when testing for any unexpected roadblocks by momentarily breaking my recently created redirect Peri Rossi and technically turning it into a normal, non-redirect article, I didn't get as much as a warning, much less a cabal-mandated trip to draftspace. We might have to wait for someone less clueless to drop by, because I'm stumped. Dr. Duh 🩺 (talk) 12:10, 25 July 2022 (UTC)
The trouble has now vanished and I have happily turned my red link above here blue. For what it's worth, your creation of Peri Rossi predates the trouble which sparked this thread. Let us hope it does not recur. Thanks for engaging, anyway. — Cheers, Steelpillow (Talk) 12:51, 25 July 2022 (UTC)
@Steelpillow Were you having a technical problem? There shouldn't be anything that is preventing you from creating new pages the way you have been. If this isn't a problem now, that's good to hear; if you are can you please give us the exact steps you are following, what you expect to be happening, and what is happening instead - so we can look in to this further. Best regards, — xaosflux Talk 14:02, 25 July 2022 (UTC)
Your description above sort of sounds like you were logged out, if so - non-logged in and confirmed users are actually prevented from creating new articles or article redirects. — xaosflux Talk 14:04, 25 July 2022 (UTC)
@Xaosflux: As I said above, all is now back to normal. I was logged in all right - my IP address is currently blocked from editing if I am logged out, and it was the first thing I checked. One of life's little mysteries. — Cheers, Steelpillow (Talk) 15:37, 25 July 2022 (UTC)
@Steelpillow thanks for the update, if it happens again and you can get a screen shot that could help, it shouldn't be that hard and if it is a recurring problem fixing it would be a good idea! — xaosflux Talk 15:47, 25 July 2022 (UTC)
If it does happen again, it probably won't be to me. But if it is, I'll be back. — Cheers, Steelpillow (Talk) 16:11, 25 July 2022 (UTC)

Let's talk about the Desktop Improvements

Join an online meeting with the team working on the Desktop Improvements! It will take place on 26 July 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location.

Read more. See you! SGrabarczuk (WMF) (talk) 16:19, 25 July 2022 (UTC)

Is "speed of light" misleading?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.



Is it misleading to use the phrase "speed of light" in an article such as "International System of Units" when what is really being referred to is the speed of electromagnetic radiation in a vaccum? Is "speed of causality" more appropriate? Jc3s5h (talk) 18:38, 26 July 2022 (UTC)

No. See also WP:COMMONNAME. Also, why is this here? This belong on the article talk page. Headbomb {t · c · p · b} 18:41, 26 July 2022 (UTC)
The important qualification is "in a vacuum", which seems to be used in that article where needed. Phil Bridger (talk) 20:40, 26 July 2022 (UTC)
The constant being refereed to is 'C' which literally stands for causality. Marrew (talk) 21:49, 26 July 2022 (UTC)
c comes from the latin celeritas, which simply means speed. It does not stand for causality. Headbomb {t · c · p · b} 22:47, 26 July 2022 (UTC)
Either way, c does not stand for speed of light, and calling the speed of light a constant is misleading, and more confusing. Marrew (talk) 23:10, 26 July 2022 (UTC)
Celeritas, meaning speed, of what? The answer is still the celeritas of causality, not the speed of light. Marrew (talk) 23:13, 26 July 2022 (UTC)
"of what?" Of light. Duh. Headbomb {t · c · p · b} 23:23, 26 July 2022 (UTC)
Ad hominem aside (no need to insult my intelligence here), the issue is listing the speed of light as a constant, when it is not a constant. Whether c stands for celeritas or causality is not really the issue here. This is confusing to people studying optics, which relies on the existence of refraction, a phenomenon that relies on the fact that the speed of light is not a constant. The table should include "in a vacuum" at the very least, as the paragraph talking about it does, to avoid this confusion.
The speed of causality, also known as the fastest speed that any one point in the universe can communicate any data to any other point in the universe that is separated in space, is far more specific, and could lead people to reading further on the topic rather than being misinformed.
https://wiki.riteme.site/wiki/Speed_of_light#Upper_limit_on_speeds is a better part of the article to link to in this regard, and is what a link for "speed of causality" automatically corrects/scrolls to. Marrew (talk) 00:09, 27 July 2022 (UTC)
The speed of light is NOT a constant. If it were, the field of optics would not exist. This is more confusing. Marrew (talk) 21:50, 26 July 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Vote for Election Compass Statements

You can find this message translated into additional languages on Meta-wiki.

Hi all,

Volunteers in the 2022 Board of Trustees election are invited to vote for statements to use in the Election Compass. You can vote for the statements you would like to see included in the Election Compass on Meta-wiki.

An Election Compass is a tool to help voters select the candidates that best align with their beliefs and views. The community members will propose statements for the candidates to answer using a Lickert scale (agree/neutral/disagree). The candidates’ answers to the statements will be loaded into the Election Compass tool. Voters will use the tool by entering in their answer to the statements (agree/disagree/neutral). The results will show the candidates that best align with the voter’s beliefs and views.

Here is the timeline for the Election Compass:

  • July 8 - 20: Volunteers propose statements for the Election Compass
  • July 21 - 22: Elections Committee reviews statements for clarity and removes off-topic statements
  • July 23 - August 1: Volunteers vote on the statements
  • August 2 - 4: Elections Committee selects the top 15 statements
  • August 5 - 12: candidates align themselves with the statements
  • August 15: The Election Compass opens for voters to use to help guide their voting decision

The Elections Committee will select the top 15 statements at the beginning of August

Best,

Movement Strategy and Governance

This message was sent on behalf of the Board Selection Task Force and the Elections Committee

MNadzikiewicz (WMF) (talk) 21:22, 27 July 2022 (UTC)

History of article on Bernard Cribbins

If one goes to the article Bernard Cribbins, and then looks at its history, you will see that some of its revisions are not in wikilinks, and have been crossed out, making it impossible to compare them. Why is this? YTKJ (talk) 17:46, 29 July 2022 (UTC)

They have undergone revision deletion. It seems like there was a copyright violation in that article. Revision deletion makes sure it cannot be easily put back. Femke (talk) 17:51, 29 July 2022 (UTC)
Per Femke, while Wikipedia maintains a database copy of every version of every page, sometimes those versions need to be hidden from public view for any number of reasons. In the case of the Bernard Cribbins article, some of the text in an earlier version was a blatant copyright violation, and needed to be removed. There are actually two levels of removal we have; there's simple reversion deletion, whereby admins remove the versions, but admins still have access to those versions. Given there are many hundreds of Wikipedia admins, sometimes versions are so egregious, even they shouldn't be allowed to see them, and in those cases higher level functionaries have access to oversight, which even admins cannot view. WP:CRD contains reasons why information may be removed from an article history. --Jayron32 18:13, 29 July 2022 (UTC)

Try out the new edit wizard

User:Ankit18gupta/Editwizard is a new script aiming to make it easier for beginners to edit. It is a step-by-step form for filing an edit request. Please try it out; your feedback would be greatly appreciated.

The goal is to show this to logged-out editors on select articles soon, and maybe on every article eventually; a VPPR discussion will be opened about that once there's enough feedback here. Enterprisey (talk!) 21:04, 29 July 2022 (UTC)

@Enterprisey: Installed it on my alt account common.js. While using vector 2022 on desktop version on a smartphone, clicking on the "Edit Wizard" button at the top produces a pop-up above that button. The pop-up is mostly not visible because it exceeds the the page's top margin. Only the two blue buttons, "Verify" & "Next" could be seen. Thanks! CX Zoom[he/him] (let's talk • {CX}) 07:10, 30 July 2022 (UTC)
@Enterprisey Haven't debugged it completely, but looks like it is having to funnel something through toolforge, that does not seem to be documented as a tool (c.f. wikitech:Category:Toolforge tools)? Is this really necessary for an edit request script? — xaosflux Talk 14:25, 30 July 2022 (UTC)
Looks like it only works on vector and vector-2022, the landing page needs more documentation. — xaosflux Talk 14:36, 30 July 2022 (UTC)
Got it to run in Vector. Tried to use it, went out and found a source and a quote - then loaded the wizard. It wanted the source URL (so assuming this is useless for off-line references?) - gave it; clicked next - it said I had to Verify, so clicked Verity - it just hung at "Loading..." : END OF TEST - dead end of the workflow there. — xaosflux Talk 14:46, 30 July 2022 (UTC)
FWIW my reliable source url was: http://www.jstor.org/stable/40681013 ( <ref>{{cite journal|last1=Tonry |first1=John L. |last2=Burke |first2=Barry E. |last3=Schechter |first3=Paul L. |title=The Orthogonal Transfer CCD |url=http://www.jstor.org/stable/40681013 |access-date=30 July 2022 |work=Publications of the Astronomical Society of the Pacific |date=1997 |pages=1154–1164}}</ref> ) — xaosflux Talk 14:49, 30 July 2022 (UTC)
@Xaosflux, that bug is fixed now. Enterprisey (talk!) 04:12, 31 July 2022 (UTC)
I haven't tried it yet, but my first thought was that anything which requires you to go through a multi-step installation process is going to be a non-starter for beginners. I do see that "The hope is to eventually deploy this as a part of the regular interface shown to logged-out users", so I guess all I'm saying is, "Yes, please do that". -- RoySmith (talk) 15:00, 30 July 2022 (UTC)
As a more productive comment, I tried this out, attempting to add "http://wiki.riteme.site" as a source URL, and was informed that I couldn't do that because it's an unreliable source. This seems like a good thing, thanks for making it available! -- RoySmith (talk) 15:06, 30 July 2022 (UTC)
@RoySmith the notes above suggest this would either be some sort of click-to-load (using a url parameter to load the script) or a default gadget (ehhh.... that's gonna take some convincing!). — xaosflux Talk 15:09, 30 July 2022 (UTC)
Likely can be done as a click-to-load in Module:Submit an edit request without needing a default gadget. But that's putting the cart before the horse. * Pppery * it has begun... 16:02, 30 July 2022 (UTC)
Thanks everyone for the comments. @CX Zoom, the tool was not originally developed with mobile users in mind but that will be fixed at some point. In the meantime I've filed a bug for the popup location thing. @Xaosflux, the backend is for bypassing the same-origin policy: we can't make requests to URLs provided by users from the script. wikitech:Tool:Edit Wizard created. Bug with the URLs filed. @RoySmith, thanks, and yes that's right. @Pppery/xaosflux, hopefully people will think this is useful enough that we can finagle it into MW:Common.js - putting it in that module will be a bonus, but the main goal is to add it as a tab next to the current edit tab. Enterprisey (talk!) 19:49, 30 July 2022 (UTC)

Wikimedia Foundation fundraising campaign in Denmark, Israel, Malaysia, Norway, and Portugal starts tomorrow, 2nd of August

Dear all,

This is just a brief reminder (see previous announcement) that the Wikimedia Foundation fundraising banners will go live in Denmark, Israel, Malaysia, Norway, and Portugal on Wikipedia tomorrow, the 2nd of August. The campaign will finish on the 30th of August.

Generally, before and during the campaign, you can contact us:

Please let me know if you have any questions.

Thanks you and regards,

Julia JBrungs (WMF) (talk) 10:29, 1 August 2022 (UTC)

@JBrungs (WMF): I suggest posting these at Wikipedia:Village pump (WMF) instead or in addition. * Pppery * it has begun... 13:09, 1 August 2022 (UTC)

Insects, athletes?

Has anyone else noticed, in the course of magnanimously contributing editing ideas to random WP articles, that insects and athletes seem to outnumber everything else on Earth? – AndyFielding (talk) 11:34, 29 July 2022 (UTC)

Easy to resolve, just feed the insects to the athletes (or perhaps vice versa). Blueboar (talk) 11:42, 29 July 2022 (UTC)
Well, at least in terms of insects, they DO outnumber everything on earth. Over 50% of all described eukaryotes...are insects. As J.B.S. Haldane is said to have noted versions of on several occasions, "the Creator, if he exists, has a special preference for beetles." It would appear it's their planet, we just live on it... --Jayron32 17:38, 29 July 2022 (UTC)
Or, it used to be theirs: The decline in insect populations is pretty scary. WhatamIdoing (talk) 19:47, 1 August 2022 (UTC)
Also, note the qualification of "described eukaryotes". Prokaryotic lifeforms are, and always have been, much more numerous. --User:Khajidha (talk) (contributions) 20:37, 3 August 2022 (UTC)

Wikimedia Foundation English fundraising campaign - further pre-test dates

Dear community members,

I wanted to give you a quick update on further pre-test dates around the English campaign (see my previous message for more background).

As part of the English campaign we test our infrastructure on a regular basis throughout the next few months. Currently I can share with you when we will be running banner tests in August.

In August we will be running short banner tests for a few hours on the 3rd and 8th of August. We will add more August dates as the month progresses and I will inform you here, once we know more about the next testing phase. These tests mean that you might see banners, if you are logged out of your Wikipedia account.

Generally, before and during the campaign, you can contact us:

Please let me know if you have any questions.

Thanks you and regards,

Julia JBrungs (WMF) (talk) 07:48, 2 August 2022 (UTC)

Dear all,
I wanted to let you know about further testing we are doing for the English campaign in August.
In order to gain insights from a more representative sample of readers, we are planning a 1 week, low-traffic test. During the test, a banner will only be shown to anonymous/non-logged-in users 5% of the time until the maximum of 10 impressions (1 big and 9 small banners) is reached. This test will run from the 8th - 15th of August. We also have a further three hour test on the 18th of August.
I will continue to inform you here about test dates. If you have any questions, please address them to our talk page.
Thank you and regards, JBrungs (WMF) (talk) 06:07, 4 August 2022 (UTC)

Updated contributor study?

Howdy hello folks. A friend had been telling me about how male dominated the open source community is, and it made me look up the gender breakdown of Wikipedians. As far as I could tell, our data is almost comically outdated at this point: the most recent data is from 2013, when we were 84% male (see Wikipedia:Wikipedians). Does anyone know of any more recent data? If not, anyone know how we could get that number updated? I think it would be very good to track our progress (or lack thereof) of diversifying the community. CaptainEek Edits Ho Cap'n! 19:27, 27 July 2022 (UTC)

Hi CaptainEek, thanks for drawing attention to this. A couple of recent sources:
However, there are many more. For some lists of data sources on the gender breakdown of Wikipedians:
I hope this helps a bit! -TAndic (WMF) (talk) 10:34, 29 July 2022 (UTC)
Executive Summary: It hasn't changed much, and 84% is actually "better" than many figures. But as far as I'm aware, there's no research that produces by gender figures for actually useful edits, rather than fiddling with templates, navboxes, and short descriptions, surely predominately male activities. I've long suspected that the female contribution to additions of actual prose is a good deal higher than the figures suggest. Johnbod (talk) 03:53, 4 August 2022 (UTC)
  • I suspect it also contributes to the gender bias here, where more articles are about males than females. Women in Red tries to fix this. All I can suggest is to keep that in the back of your mind as you create new articles and look for interesting/notable females about which we can create articles! Oaktree b (talk) 16:52, 4 August 2022 (UTC)

A Wikipedia creation page service

Hi there,

I'm a french wikipedian, so excuse me for my bad english. This afternoon (GMT time) I discover an commercial spam for a wikipedian page creator named Wikiproficiency ( dot com). As it is a company that work on english pages, I think you appreciate to meet them. If you need more precision, don't hesitate to ask me. Soon, --Gpesenti (talk) 14:55, 3 August 2022 (UTC)

Hello. More info here: Bulletin des patrouilleurs. There is for instance a list of articles on en. on which they claim to have contributed. VateGV Discuss?Discuter ? 15:00, 3 August 2022 (UTC)
Always take these lists with a grain of salt. These marketers are notorious for falsely claiming responsibility for articles. BD2412 T 15:14, 3 August 2022 (UTC)
Well this analysis looks accurate givent the results of the sockpuppet investigations on fr. VateGV Discuss?Discuter ? 15:32, 3 August 2022 (UTC)
  • I've seen these pop up every so often. It's too hard to try and shut them down, they pop up again on another website. Easiest is to debate articles in AfD (Articles for Discussion/Deletion) where we can discuss why or why not an article should get deleted. Oaktree b (talk) 16:47, 4 August 2022 (UTC)

Central discussion on editor retention and recruitment?

I periodically see comments, essays and articles about Wikipedia's desire to retain and recruit editors (e.g. Why Aren’t There More Wikipedia Editors? and WP:Why is Wikipedia losing contributors). I am wondering if there is a single location here or at Meta-Wiki for discussion of the issue. Thanks. —  AjaxSmack  03:33, 3 August 2022 (UTC)

Wikipedia:WikiProject Editor Retention might be of interest. -- Visviva (talk) 03:19, 4 August 2022 (UTC)
Thanks. I don't know how my search failed to turn up that obvious one.  AjaxSmack  04:03, 4 August 2022 (UTC)
As someone who's been involved with the retention project from the start, I didn't bring it up initially, because in truth the discussion page may not have the right mix of active page watchers to collaborate on new initiatives. There's no harm in starting a discussion there, though, and followup discussions can be brought to another venue if necessary. isaacl (talk) 02:57, 5 August 2022 (UTC)

Ken C Griffin "Mayonnaise incident".

I was just wondering if we could add the Mayonnaise incident to https://wiki.riteme.site/wiki/Kenneth_C._Griffin aswell as the recent news of his supoponea? I know wikipedia only includes factual evidence and so if anyone at the event would be able to vouch it would be great. I know other people's articles have this sort of thing but the story looks legit aswell as the subopena (tesla subopena), is 100% facutal. https://www.reddit.com/r/Superstonk/comments/n8tvrx/my_friend_had_dinner_with_kenny_g/ Nexxotic (talk) 03:51, 4 August 2022 (UTC)

Shall we count the policies that would violate? Wikipedia:Verifiability, Wikipedia:Biographies of Living Persons, Wikipedia:What Wikipedia is Not, for starters. - Donald Albury 15:29, 4 August 2022 (UTC)
I personally vote we skip with the formality of adding that the man does not share his mayonnaise, according to renowned historian and journalist niandra__lades7, and move to have him publicly executed. Iazyges Consermonor Opus meum 15:08, 5 August 2022 (UTC)

Seeking recent editor stratification research

Does anybody know of recent work that updates the findings of m:Research:Editor classes or strategy:Editor Trends Study? I have poked around a bit but haven't found anything that works on the same issues; stats.wikimedia.org doesn't quite get into those issues AFAICT. Doesn't need to be formal research; I'd be interested in anything that people have found from just tooling around on toolserver or diving in the dumps. -- Visviva (talk) 18:06, 20 July 2022 (UTC)

As an update, I have been doing some initial poking around in the latest stub-meta-history dump. One thing that jumps out at me is that something odd was happening in 2014: that year saw a dramatic jump in new users in the 1-9 mainspace edits band (>70k absolute, >15% YoY), but also saw sharp drops in the absolute number of edits being made by editors in the 1k-9k and 10k+ mainspace-edit bands (which were largely reversed in subsequent years). I looked through the Signpost archives but didn't see anything that would indicate a titanic shift in wiki practice that year. But I wasn't very active at that time, so I don't really know what might have been happening that would have made 2014 special. Any ideas? -- Visviva (talk) 21:38, 23 July 2022 (UTC)

Interesting work. The only thing I can think of re 2014 was that it was the first full year when both the VisualEditor and the notifications feature were enabled, though I'm not sure how much effect either of these things might have had. Mobile viewing and editing were becoming more popular as indicated by this, but once again, that probably wasn't a seismic shift. Graham87 08:42, 24 July 2022 (UTC)
Ooh, thanks, good thought. Intuitively, that makes a lot of sense: barriers to editing come down so long-tail activity picks up, while "power users" get annoyed and their activity drops. (I recall having some rather cranky things to say about the VisualEditor myself, although my power user days were long behind me at that point.) And that same annoyance could explain the subsequent reversion to trend: annoyed power users make changes to policy and practice that push the balance back toward exclusion. Will be interesting to see if this holds once I've cleaned up the data a little better. -- Visviva (talk) 22:09, 24 July 2022 (UTC)
@Visviva, is that the all-wikis database? If so, then I believe you will see a quite dramatic effect at the Portuguese Wikipedia, which (if memory serves) had unusually stringent CAPTCHA rules in place until December 2013. Whatamidoing (WMF) (talk) 20:55, 25 July 2022 (UTC)
@Whatamidoing (WMF): I've never heard of a database dump for all wikis and I can't find it on the relevant page. Can you point me to such a thing if it exists? Graham87 05:34, 26 July 2022 (UTC)
I don't know how the dumps are arranged. I just saw on the page that there were 16,666,393 pages in the mainspace, which is 10 million more than our current 6,906,590 mainspace articles, and it sounded approximately plausible to me as the number of articles if you added all the Wikipedias together. Whatamidoing (WMF) (talk) 18:09, 26 July 2022 (UTC)
It's just the EN database. I believe 16.7M is accurate as the approximate total number of pages in mainspace (i.e. including redirects and other very short pages that NUMBEROFARTICLES excludes.) I found a version of that number ... uh, somewhere ... that jibed with my result, which was a nice feeling at the time -- although now I can't seem to find it. -- Visviva (talk) 22:00, 26 July 2022 (UTC)
It's at Wikipedia:Database reports/Page count by namespace. We have a grand total of about 59,000,000 articles on all Wikipedias. Graham87 12:53, 27 July 2022 (UTC)
  • In case any of my fellow randos wander across this conversation, I'll note for posterity that after removing bots, there is still something of an anomaly, but it can be further qualified by two things: (1) the increase in long-tail registered user edits was only a small fraction of the decrease in IP edits during the same year, so it may just reflect an interface change that nudged people away from anonymous editing; (2) with bots removed, it is clearer that the drop in power user activity in the four-digit band was a continuation of a long-term downward trend from 2007 to 2014 (subsequently partially reversed), while the five-digit band didn't really move much (this was obscured by the 2013 surge in bot activity in relation to the transition of interwiki links to Wikidata, which made 2014 look like a sharp drop). There were clearly some significant shifts happening around 2014, but exactly what they were remains unclear to me. -- Visviva (talk) 18:23, 3 August 2022 (UTC)
    The 2007 trend was probably due (at least in part) to a declining need for anti-vandal patrolling. In 2005, obvious vandalism was reverted manually. By 2007, the bots would revert it before you could even get the diff open.
    As for things leveling off around 2014 trend, I think you'd want to investigate the rise of the visual editor, and the introduction of Wikidata (which should decrease local edits).
    The research that I've long wished for is about the difference between "edits" and "writing articles". I can make copyedits like this one in my sleep. But this content-heavy edit likely benefits the world more. Whatamidoing (WMF) (talk) 00:31, 11 August 2022 (UTC)

News about Wikipedia in Lokmat

There is a change of cabinets in the state of Maharashtra, India. Today in Lokmat there is a negative media regarding vandalism of MLA's article on Wikipedia. (Read news here). Requesting Admins to take note and take appropriate actions if necessary. Thanks and regards --✝iѵɛɳ२२४०†ลℓк †๏ мэ 04:11, 11 August 2022 (UTC)

The article is in Marathi and Google Translate doesn't work on it, but I dug a bit and think I found the issue. A rogue editor (Sahil193319) changed the party affiliation of several politicians; the articles in question can be seen in their contribs. I think they're all fixed, but if any were missed, please link them, as again that article is in Marathi and Google Translate isn't working on it. Curbon7 (talk) 06:37, 11 August 2022 (UTC)

Discord ban

I got banned from the Wikipedia Discord with no reason, my username is h moment#9731 UnnamedWasTaken (talk) 18:07, 11 August 2022 (UTC)

That's run by different people. See Wikipedia:Discord#How is Wikimedia Community Discord related to Wikipedia?. If you're asking to be unbanned, you need to address that to the people who run the Discord server. -- RoySmith (talk) 18:15, 11 August 2022 (UTC)
But there is no dicussion board there, if you have no answer, don't give an reply. UnnamedWasTaken (talk) 18:33, 11 August 2022 (UTC)
User was banned for trolling immediately after joining Discord. Nothing further to add. Ponyo has blocked on-wiki. -- ferret (talk) 22:40, 11 August 2022 (UTC)

New Upload Tool - Sunflower

Hey folks, I recently created a new upload tool for Commons called Sunflower. If you have a Mac, I'd greatly appreciate it if you could try it out and share your feedback. Thanks! -FASTILY 08:27, 12 August 2022 (UTC)

@Fastily, have you talked to the GLAM folks about this? Batch upload tools are usually interesting to them. Whatamidoing (WMF) (talk) 18:54, 15 August 2022 (UTC)
And have you listed it at m:Toolhub? Whatamidoing (WMF) (talk) 18:55, 15 August 2022 (UTC)
Thanks for the suggestions! I've listed the tool on Toolhub. Do you have any recommendations on how to go about talking to GLAM folks? Is it the mailing list? Thanks, FASTILY 04:05, 16 August 2022 (UTC)

Look at your list of created articles with the Xtools Page API

I've created a new tool which gives insights about your list of created articles using xtools page prise API : https://observablehq.com/@pac02/look-at-your-list-of-created-articles-with-the-xtools-page-ap. It provides statistics about the actual number of words, references and sections in each article you've created.

Your feedback would be greatly appreciated.

Do you know if there is some page in Wikipedia where we could list this kind of tools? PAC2 (talk) 05:19, 15 August 2022 (UTC)

There's Wikipedia:Tools ... Graham87 11:02, 15 August 2022 (UTC)
Thanks --PAC2 (talk) 05:56, 16 August 2022 (UTC)

Wikimedia Foundation English fundraising campaign - further pre-test updates

Hi everyone,

As previously mentioned here, I will continuously inform you of pre-tests on English Wikipedia as the Wikimedia Foundation prepares for the English fundraising campaign later this year. As part of the English campaign we test our infrastructure on a regular basis throughout the next few months and you might see banners every now and then on Wikipedia if you are not logged in.

The next scheduled dates are:

  • The 17th of August - a 100% traffic three hour test
  • The 22nd to the 29th of August - a low level week long test (During the test, a banner will only be shown to users 5% of the time until the maximum of 10 impressions (1 big and 9 small banners) is reached.)
  • The 1st of September - a 100% traffic three hour test
  • The 8th of September - a 100% traffic three hour test
  • The 16th to the 18th of September - a 10% traffic weekend test — Preceding unsigned comment added by JBrungs (WMF) (talkcontribs) 06:38, 16 August 2022 (UTC)
  • The 22nd of September - a 100% traffic three hour test

Generally, before and during the campaign, you can contact us:

Please let me know if you have any questions.

Thanks you and regards, JBrungs (WMF) (talk) 07:35, 15 August 2022 (UTC)

Thanks. Please note there is also a community review of the Wikimedia Foundation's English fundraising emails ongoing at Wikipedia:Village_pump_(proposals)#Review_of_English_Wikimedia_fundraising_emails. This has the complete wording of the sample emails provided by the WMF to date. These emails go out to millions of existing donors, widely shaping perceptions of Wikipedia and our financial situation. Please have a look and comment. (The email campaign will kick off soon; it is scheduled to run from 6th of September to 20th of November.) Best, --Andreas JN466 10:05, 15 August 2022 (UTC)

Input needed

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Please comment in the RfC about the first sentence in Jimmy Savile sexual abuse scandal. Cheers! Thinker78 (talk) 23:54, 14 August 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Hello, I have a question regrading Wikipedia:Changing username/Usurpations. I have found that there is a local page for usurpation. However, all the other languages listed (d:Q4615956) are closed or inactive. Moreover, like Global locks, users are globally renamed. As a result, I would like to ask why Wikipedia:Changing username/Usurpations is currently still available on making requests and would it be possible to merge the requests to the the same page on metawiki (i.e. Stop allowing making requests in enwiki). 132.234.112.11 (talk) 04:11, 16 August 2022 (UTC)

Makes sense. We now have single unified login and follow the global usurpation rule anyway. CX Zoom[he/him] (let's talk • {CX}) 04:46, 16 August 2022 (UTC)
Because we are huge and host many only-one-wiki users; this allows for a quicker process when only enwiki is involved (1 week vs 1 month). — xaosflux Talk 14:09, 16 August 2022 (UTC)

phabricator requested I report this

Report it in a support forum of English WP. If this isn't the right place (I'm not the most knowledgeable WP-editor), I assume/hope somebody here will send it to the right place. You can read the problem here:
https://phabricator.wikimedia.org/T314837 Dutchy45 (talk) 07:51, 16 August 2022 (UTC)

Resolved
CapnZapp (talk) 18:48, 17 August 2022 (UTC)

#WPWP

It looks as if someone is running a campaign to add images to enwp articles with edit summaries containing #WPWP or #‎WPWPNG. This also occurred in August 2021, with the good-faith addition of many images, some of which were inappropriate. Does anyone know who is behind this campaign? Are there any opinions as to whether it's useful and what, if anything, we should do about it? Certes (talk) 00:58, 18 August 2022 (UTC)

WP:Administrators' noticeboard/Archive344#WPWP query. —Cryptic 01:10, 18 August 2022 (UTC)
@Certes: any diffs or links or other ways to see what's happening? BrownHairedGirl (talk) • (contribs) 01:59, 18 August 2022 (UTC)
https://hashtags.wmcloud.org/?query=WPWP&project=wiki.riteme.site. The most recent edit as of now (other than this discussion) is typical. —Cryptic 02:12, 18 August 2022 (UTC)
Thanks for the clues. A little more digging brings up m:Wikipedia Pages Wanting Photos 2022. It seems I'm late to the party and it's already been discussed at AN. Cryptic's examples contain #WPWPRW, and I saw NG (ISO code for Nigeria), so there may be a particular drive to improve our African articles. Contest ends 31 August. Certes (talk) 08:38, 18 August 2022 (UTC)
There's a CentralNotice banner running in Albania, Belgium, Benin, Cameroon, Ghana, India, Italy, Nigeria, North Macedonia, Philippines, Sudan, Switzerland, and Turkey. [3] What the logic is behind those country choices, I have no idea. In any case it does seem less disruptive than last year, though worth keeping an eye on. The banner is due to end on 31 August. the wub "?!" 09:14, 18 August 2022 (UTC)
I hadn't noticed this was happening again, so that's a good sign. I ended up writing a standard talkpage message last year, in case anyone encounters a new user needing guidance. CMD (talk) 17:35, 18 August 2022 (UTC)
In case it's of any use to anyone reading this, Special:AbuseFilter/1073 is currently tagging these edits, see [4] for a realtime list of edits. 86.23.109.101 (talk) 22:03, 18 August 2022 (UTC)

Invitation to join the Movement Strategy Forum

The Movement Strategy Forum (MS Forum) is a multilingual collaborative space for all conversations about Movement Strategy implementation. We are inviting all Movement participants to collaborate on the MS Forum. The goal of the forum is to build community collaboration using an inclusive multilingual platform.

The Movement Strategy is a collaborative effort to imagine and build the future of the Wikimedia Movement. Anyone can contribute to the Movement Strategy, from a comment to a full-time project.

Join this forum with your Wikimedia account, engage in conversations, and ask questions in your language.

The Movement Strategy and Governance team launched the proposal for this MS Forum in May. After a 2-month review period, we have just published the Community Review Report. It includes a summary of the discussions, metrics, and information about the next steps.

We look forward to seeing you at the MS Forum! Qgil-WMF (talk) 11:47, 19 August 2022 (UTC)

Qgil-WMF you say you are inviting all Movement participants, that the goal is to be inclusive, and that anyone can contribute. However the website denied me access. A substantial percentage of all editors will similarly be denied access. Specifically, the OAUTH process explicitly denies access to any user who has not filled in an email on their Wikimedia account. I would also like to specifically quote Foundation Privacy Policy:

Because we believe that you shouldn’t have to provide personal information to participate in the free knowledge movement, you may:

  • Read, edit, or use any Wikimedia Site without registering an account.
  • Register for an account without providing an email address or real name.
Could you please clarify whether this website is going to be corrected, to allow established community members to participate under the terms of the Foundation Privacy Policy, without requiring an email address or real name? Alsee (talk) 23:37, 20 August 2022 (UTC)
The Movement Strategy Forum operates under the Wikimedia Foundation’s Non-wiki Privacy Policy. (source) Users have to log with their Wikimedia login and they don't need to provide their real name. Discourse (the software used for the MS Forum) relies on email addresses as user ids. The emails are not shown but the software needs them, and administrators can access them. Any throwaway email address would do. There is a discussion about the requirement for an email address on the forum that contains more details. Qgil-WMF (talk) 23:52, 20 August 2022 (UTC)
After thinking a bit more... Technically it is possible to allow anonymous users to post on a Discourse forum. The setting is disabled by default and there hasn't been any thought or discussion about enabling this. I understand that this would be different than what you request, @Alsee, but it's the only other technically feasible solution we have at hand. Or users in your situation create a single-purpose email address on a privacy-friendly service like Tutanota or ProtonMail , which also would solve the problem technically. Qgil-WMF (talk) 23:59, 20 August 2022 (UTC)
Qgil-WMF, Discourse is open source software. It shouldn't take undue work to enable access for OAUTH-without-email by generating an arbitrary unique string in the email-as-id field. In particular the domain of example.com is defined not to exist. If necessary that could be used as the base for a not-a-valid-email ID value. If Discourse requires email verification, that step would also need to be skipped. Note that somewhere between 20% and 45% of all of our users have no email set on their Wikimedia account, and a majority have no verified email on their Wikimedia account. (I saw those figures posted by the WMF somewhere recently.) This clearly impacts a large number of our users, and many of our users have good reason to be averse to anything that might remotely facilitate surveillance by certain governments. Alsee (talk) 00:38, 21 August 2022 (UTC)
Sure, as maintainers of the MS Forum we have no interest in requiring users to have a verified email address. Having one improves the user experience with email notifications and the periodical digest (that users can tune in their user settings) but we agree that this should be an optional feature, not required. Other people have asked before at the Discourse forum, and the implementation of this feature isn't trivial according to the Discourse developers. I have asked about the specific setting you are suggesting, @Alsee. Qgil-WMF (talk) 10:10, 21 August 2022 (UTC)

Articles for Deletion

As many of you probably know, there's been an influx of deletion nominations at AfD recently. For example, August 18's log contains nearly 100, with some relisted and many others lacking votes. It is somewhat surprising that with so many Wikipedians active on so many different projects, AfD is an area where participation is minimal. And when there is enough consensus, and the nominated article is either kept, redirected, deleted (or some other option), the consensus is sometimes composed of only three or four votes. That is problematic, and AfD isn't functioning very well. I don't seem to have a specific solution for this. NytharT.C 02:47, 20 August 2022 (UTC)

  • I don't know if it's related but a bunch of editors who regularly voted Keep have been blocked from participating in AfD over the prior 6 months or so in various ANI and Arbcom. There is a balance of power in AfD: it's easy for anyone to nominate tons of articles for deletion. It's also easy to vote Keep, the GNG guidelines have a low bar. However if people are not participating for whatever reasons, the balance will turn in favor of increased deletion rates. -- GreenC 03:02, 20 August 2022 (UTC)
    But the number of participants at AfD itself is low. NytharT.C 04:17, 20 August 2022 (UTC)
    You linked to August 18 meaning just started it doesn't tell much. Why not look at the cases about to end and see what percentage have low participation. Either way, AfD can always use more participants to get better results. -- GreenC 04:49, 20 August 2022 (UTC)
    If you scroll through August 13's log, you'll see discussions relisted multiple times and, around the center, several discussions with 1-2 votes. How many users regularly vote at AfD? 15-30? My point is these discussions could hypothetically have between 5-10 votes within as little as 2-3 days if more users were interested in AfD. Having to relist the same discussion 2-3 times slows down the process. NytharT.C 05:39, 20 August 2022 (UTC)
I don't usually monitor AfD, and might make it more of a habit to do so, but just wanted to note that the List of victims of the September 11 attacks AfD had 38 participants. So it may be the case that people are monitoring it, but don't generally feel like chipping in on topics they're not close to. — Guarapiranga  08:01, 20 August 2022 (UTC)
The high participation in that example I think is due to the fact that a larger number of people were probably monitoring List of victims of the September 11 attacks than the typically nominated article rather than that large numbers were monitoring the AfD page. It's almost always through my watchlisted articles that I take part. - R. S. Shaw (talk) 06:09, 21 August 2022 (UTC)
Perhaps inevitable, because only one person without discussion or consultation is needed to make an article, but in deletion, multiple volunteers have to be called on to spend time analysing/debating something they may have no interest in. Alanscottwalker (talk) 23:53, 20 August 2022 (UTC)
I haven't been by AFD in quite a while, but when I do tag any article(s) for AFD I generally make a point of voting on enough other AFD's so that I contribute more votes than my AFDs consume. It may help to add instructions around AFD strongly encouraging AFD-creators to cast votes too. It might be worthwhile to direct individual vote-requests to individuals who regularly create AFDs, if they're not significantly voting. Alsee (talk) 00:04, 21 August 2022 (UTC)
Whilst editors who initiate deletions are welcome to !vote on other AfDs, targeting such editors for invitations might risk creating a bias in favour of deletion. Certes (talk) 00:14, 21 August 2022 (UTC)
One thing you can do to increase participation is to make sure the articles are tagged with WikiProject banners. This will put notify the projects of the deletion discussion via WP:AALERTS.00:38, 21 August 2022 (UTC) Headbomb {t · c · p · b} 00:38, 21 August 2022 (UTC)
@Certes, one could equally theorize that AFD-nominators may correlate positively with experience in this area of work, relevant policy knowledge, and due concern for policy compliance, potentially correlating with above average accuracy in AFD-votes vs AFD-outcomes. It would be interesting to see actual stats on that.
One could also raise keep-bias concerns in encouraging notification of the article creators, in notification to related wikiprojects, and in category tagging. All of which are common in the AFD process.
I would suggest dealing with AFD improvement based on a general presumption of AGF for participants, until demonstrated otherwise. Although I would like to see a greater willingness to discourage or topic-ban people from AFD for behavious such as generating an undue rate of failed AFD-nominations or spamming frivolous keep votes. I have no idea how much of a problem there is with people generating excessive failed AFDs, but I have memorably witnessed people spamming frivolous keeps while brazenly declaring disregard for policy. But as I said, I haven't been over at AFD in quite some time. Alsee (talk) 01:39, 21 August 2022 (UTC)

Help for CSVLoader

Hi, can anyone help me for using CSVLoader? I want to create articles using this plugin in Azerbaijani Wikipedia. I followed the steps, but couldn't get any result. Surə 🗯 07:01, 21 August 2022 (UTC)

Help for grammer check

Hey all, can any native speaker of English check this articles: Muhyi al-Din Faris, Idris Jamma'. I will learn from your reforms, and i will not repeat requesting this kind of my own problems. Thank you. Ruwaym (talk) 22:23, 18 August 2022 (UTC)

Just for your information: you can consider asking for writing assistance on the talk page for Wikipedia:WikiProject Guild of Copy Editors. isaacl (talk) 22:39, 18 August 2022 (UTC)
@Isaacl Oh, thank One who laughs. Ruwaym (talk) 12:59, 19 August 2022 (UTC)
I copyedited the Muhyi al-Din Faris article, however I am going to review it again in the morning along with the Idris Jamma' article for the first time. I did have several questions while reviewing, though.
  • 1) The article mentioned he studied at Al-Azhar, with the mosque wikilinked. Was that intentional, or did you mean the university of the same name?
  • 2) The article describes him as "Emerging" in the 1950's. Does this mean he started publishing during the '50s, or started to get attention during that time frame?
  • 3) The article quotes Mahmoud Amin Al-Alam. If the quote was word-for-word, than it should be in a quote box for clarity.

I would appreciate of someone like @User:Ruwaym could review my edits and make sure I did not change the text's meaning. Ruwaym, there is nothing wrong about asking more questions in the forums, even if they are similar. You did a good job! GGOTCC (talk) 05:20, 21 August 2022 (UTC) (talk)

@GGOTCC Thank you. I fixed what you mentioned. Reviewers of newly created articles are strict, so after you finished, please remove the related templates. You know, those two articles are related to Kateb Maktub, a competition, and I don't want to lose points! So i asked here, but i guess they will reply lately. Anyway, I want to continue to write more biographies; It would be great if I could translate the articles I wrote on my ex-homewiki to English, feels like you eat a cake twice! Ruwaym (talk) 14:20, 21 August 2022 (UTC)

Looking for B&S, an American tyre company

Hello,
I've written an article on the French Wikipedia about fr:Torrilhon, a former French tire manufacturer, active between the second half of the 19th and the first half of the 20th centuries. In 1902 this company obtained a product license for a car wheels rubber band (solid or pneumatic?) from an American manufacturer that I only known by its initials B&S. Looking on the en:WP desambigueous page B&S, there are only two industrial companies but they don't seem to have worked with rubber or made tires. Any ideas?
Thanks
TCY (talk) 11:12, 21 August 2022 (UTC)

@TCY You'll probably get better responses at the WP:Reference desk. 86.23.109.101 (talk) 20:17, 22 August 2022 (UTC)
Thanks, I move it there. TCY (talk) 06:06, 23 August 2022 (UTC)

About a draft of a LTA page of a cross wiki abuser

Hello, I had created draft of a LTA page of a cross wiki abuser who have a LTA page in zhwiki yesterday but it has been rejected in AFC. I would like to know the procedures of creating a LTA page. Thank you. 132.234.228.244 (talk) 04:38, 23 August 2022 (UTC)

WMF Board of Trustees Elections election compass

A nice tool to help you understand the positions of the candidates: https://board-elections-compass-2022.toolforge.org/ -- RoySmith (talk) 17:57, 23 August 2022 (UTC)

The 2022 Board of Trustees election Community Voting period is now open

You can find this message translated into additional languages on Meta-wiki.

Hi everyone,

The Community Voting period for the 2022 Board of Trustees election is now open. Here are some helpful links to get you the information you need to vote:

If you are ready to vote, you may go to SecurePoll voting page to vote now. You may vote from August 23 at 00:00 UTC to September 6 at 23:59 UTC. To see about your voter eligibility, please visit the voter eligibility page.

Best,

Movement Strategy and Governance

This message was sent on behalf of the Board Selection Task Force and the Elections Committee

MNadzikiewicz (WMF) (talk) 12:57, 24 August 2022 (UTC)

Mass addition of Cleanup bare URLs template

The task of encyclopaedia cultivation generates vast amounts of paperwork that, if left unaddressed by volunteers, accumulate into enormous backlogs.

{{Cleanup bare URLs}}

The community will never keep-up with this mass spamming (63,051 pages)....sometimes 2000 are added a day. .this banner has zero benefits for readers at the top of articles.....perhaps add this to the top of the "References" section for editors. Is there going to be any effort to actually fix the problem .....that in many cases is just a few sources? Moxy- 16:53, 15 August 2022 (UTC)

First off, you seem to have made no attempt to notify the person who is doing it. Second, Is there going to be any effort to actually fix the problem -> yes, she's personally fixed tens of thousands of bare URLs. Third, 63,051 pages is a massive overestimate, as {{cleanup bare URLs}} is only transcluded on 17K pages * Pppery * it has begun... 17:04, 15 August 2022 (UTC)
Yup many have raised concerns....only one person has done all this? Is the bot approved?Moxy- 17:07, 15 August 2022 (UTC)
See also the cross-post at Template talk:Cleanup bare URLs#Mass spamming - you shouldn't start discussions in multiple places * Pppery * it has begun... 17:07, 15 August 2022 (UTC)
No reply to last few post...moved here now......lets assume we are trying to start a good talk. Any reply to the proposal made? Again is there a plan to go back and fix the articles now tagged?Moxy- 17:08, 15 August 2022 (UTC)
Most likely yes, but does it matter? These tags will likely succeed in turning the task of fixing the longstanding backlog of bare URLs into something other than an near-Herculean effort by one editor. Why is this a problem, and why should the existence of bare URLs be swept under the rug? * Pppery * it has begun... 17:27, 15 August 2022 (UTC)
We are getting banners added to the top of article all over..for just a few bare urls....these deter readers...as we know most only scroll one time. Why not add it to the ref section? Should be doing what is best for readers ...not editors. Moxy- 17:30, 15 August 2022 (UTC)
I think putting the banner in the ref section is an excellent idea. That narrowly targets it to the type of reader/editor most likely to be inclined to act on it. EEng 19:11, 15 August 2022 (UTC)
@Moxy's conduct here is very poor: they opened in two places a discussion about my edits, without making any attempt to notify me about either discussion. No ping, no mg on my talk, no email. Nada.
But despite this, Moxy complains No reply to last few post.
WTAF??? How on earth does Moxy expect a reply when then chose to not notify the editor who they know is doing most of these edits? Is this a display of cluelessness, or some sort of game?
Note that Moxy has bad history on this issue of bare URLs. Back in March, Moxy objected to me adding the inline tag {{Bare URL PDF}} to thousands of articles; but they did so by sniping in edit summaries rather than starting a discussion. So I started a discussion on Moxy's talk, but Moxy was not interested in anything I had to say. Instead, they deleted[5] the discussion with the edit summary "back to content", so our unfruitful exchange is available only in the page history: https://wiki.riteme.site/w/index.php?title=User_talk:Moxy&diff=1077213739&oldid=1077213451
So I am sadly unsurprised to find the deplorable antics displayed here: no notification, and a WP:ABF prejudicial heading which describes WP:V-related cleanup as {{spamming}}. BrownHairedGirl (talk) • (contribs) 21:52, 15 August 2022 (UTC)
Anyway you can adrdress the proposal raised here. As per your post on my page and a few others.....people have some concerns about the editor's adding these all over.... or more specifically their placement. looking for more fruitful talk than my talk page where I'm told what to do .Moxy- 22:18, 15 August 2022 (UTC)
A decent, civil editor would have taken this opportunity to apologise for the lack of notification, for the prejudicial WP:ABF heading, and for deleting a discussion.
But no, @Moxy does none of those. Quelle surprise. BrownHairedGirl (talk) • (contribs) 22:30, 15 August 2022 (UTC)
We will simply have to move forward without your input on this point. Moxy- 22:43, 15 August 2022 (UTC)
@Moxy: thank you for clarifying that your failure to notify was an intentional attempt to exclude me from a discussion about my work.
And no, you will not proceed without my input. (I see no "we"; just you with that attitude). I have added my substantive comments below, but judging by our previous discussions and your misconduct here, I expect that you will not be interested in anything I have to say. BrownHairedGirl (talk) • (contribs) 22:53, 15 August 2022 (UTC)
What do you think about moving the banner? Moxy- 23:06, 15 August 2022 (UTC)
@Moxy: I oppose moving it.
And you should already know that I oppose it, because you have already replied to the discussion following my comment opposing it. So what game are you playing by asking me? BrownHairedGirl (talk) • (contribs) 23:13, 15 August 2022 (UTC)

I raised moving this template to the "References" section on the talk page of the template. It's great that cleanup work is being done, and I don't mind tracking this. However, as I brought up on the talk page, this isn't appropriate for the top of the article. Cleanup banners are meant for readers first and foremost (as a warning), with the fact that they encourage editors a happy byproduct. This template is 100% editor-focused, and furthermore, only on a subset of editors. Readers don't care if citations are properly formatted. Readers might care if the citations are "bad", but that isn't what this template is about: it's entirely possible for a bare URL to be an accurate and sufficient reference for the content. Sticking it in References will ensure editors notice, but don't trouble readers who both don't care and can't fix the problem. (And more generally, as anyone who has gone to edit-a-thons aimed at attracting new editors can tell you, stuff like "how to format your references" is the absolute last priority when teaching someone how to Wikipedia - it's not what we expect most newbie editors to do, and "use a bare URL or text, someone else will fix it later" is fine.)

As for the comments by *Pppery* above on "why is this a problem", the problem is banner blindness. A bunch of irrelevant-to-readers banners teaches them to ignore the content warning templates more than they already do. Even worse, a reader who gets a vague sense of distrust of articles when seeing cleanup banners (but doesn't closely read / understand this one to realize it's no big deal) might conclude that the banner means the article is unreliable, when in fact an article could well be featured-article quality but have one random bare URL added 6 months ago. This is definitely bad. For example, if a citation template has an error, there'll be a warning to editors in "preview" mode, but it won't show in normal display after saving, because regular readers do not and should not care if somebody misspelled a parameter in their citation template or whatever, while editors capable of fixing the problem can be casually warned at the next opportunity.

Do we need an RFC for this, or can we just convince BHG & others to move this template to References? It seems like an obvious win-win that leaves each side happy. SnowFire (talk) 19:31, 15 August 2022 (UTC)

EEng: I am concerned about that phrase the type of reader/editor most likely to be inclined to act on it
WP:V is a core policy of Wikipedia, and high-quality references are the core of what we do here. Bare URLs are bad for readers, because they make it hard to identify and assess the source without opening the links, and because they are prone to WP:Linkrot.
As I have worked my way through the backlog of over 470,000 articles with bare URL which we had in May 2021 (now down to ~100,000, with a much higher proportionate reduction in the total number of individual bare URLs), I have been heartbroken to find how many refs were dead and irretrievable, and now effectively useless. The URL alone often gives little or no clue as to the actual content of the web page, and many webpages are not archived the Wayback Machine and other tools. As a result, many older articles are in large part unverifiable, because the sources used are unavailable. If we were really serious about WP:V, we'd be systematically ripping out all the content which can no longer be verified, unless we can find another sources; and we be flagging up with much greater prominence the article text which is not verifiable.
This is a huge problem. We are serving up to our readers content which fails our core policies. Our readers rely on us to assert facts which they can verify, and by tolerating bare URLs we deprive them of that chance ... because most URLs eventually rot and die.
After huge progress in the last year, there are now two issues with bare URLs:
  • The backlog of old bare URLs; there are about 150,000 individual bare URLs on about 100,000 articles
  • The flood of new bare URL refs, added at a rate of over 300 per day. Using various tool, about 80% of those are filled within a month, but tool-filing of refs is in most cases mediocre, and that leaves about 2,000 articles every month getting new bare URLs.
This is time-critical work. The longer a URL is left unfilled, the more likely it is to have rotted and become unfillable, or to have changed its content. Some URLs, such as those based on news agency reports, are systematically removed by their publishers after a fixed time period (usually a few months, sometimes much less); some because the website retains only fresh content; others are lost because websites die or are restructured.
That's why a prominent notice is valuable: because unless a ref is filled soon, it may not be fillable.
So, yes, it would be possible to add the banner to the references section. But I think that doing so would be a very bad idea, because it would give the false impression that crap referencing is not important enough to flag up prominently. I strongly oppose @SnowFire's view that bare URLs are no big deal. WP:V is very clear: good referencing is not just a big deal; it is the absolute core of what we all do here. --BrownHairedGirl (talk) • (contribs) 21:37, 15 August 2022 (UTC)
I'd like to see some actual statistics on the kinds of URLs typically found being used as article references. I suspect a substantial proportion of them are Googlebooks, Jstor, and similar links not reasonably subject to rot. If a particular article's bare URLs are entirely of that kind, then cleaning up that article is due much lower priority, and maybe doesn't call for the banner -- perhaps such articles should just go in a category. I wouldn't be suprised if this cuts the banner-ing substantially. EEng 14:46, 16 August 2022 (UTC)
That may have been true originally, but in the specific case of JSTOR and Google Books, Citation bot has likely handled the bare URLs to those websites months ago. See the comment about the 80/20 rule below. * Pppery * it has begun... 16:12, 16 August 2022 (UTC)
@EEng: @Pppery is right about progress. e.g. All new JSTOR refs are filled every day, because I use them in the daily set of ~100 searches which I use to make worklists for @Citation bot.
As to the wider sets: about a month ago, I made a list of all the then extant bare URLs, and then turned that into a spreadsheet listing the number by domain.
The results surprised me: much less clustered than I expected. The biggest set at the time was WaPo (washingtonpost.com), with just over 900 entries. I was expecting that, 'cos @Citation bot doesn't handle WaPo, so I wrote and deployed a tool to automatically fill (most) WaPO refs.
AFAICS, that lack of clustering makes analysis-by-quality of website near-impossible; it would take far too much work, and the effort would be much better placed into filling/tagging-dead/removing/replacing the bare URLs. However, if you (or anyone else) would like a copy of my data, pls just send me an email with the subject line "bare URL website distribution spreadsheet". BrownHairedGirl (talk) • (contribs) 18:50, 17 August 2022 (UTC)
I've seen these coming up on multiple watchlisted articles and have been going along behind and fixing. For me these are helpful. Valereee (talk) 21:55, 15 August 2022 (UTC)
That's great, but you'd have seen it on your watchlist if it was added to the "References" section too, right? SnowFire (talk) 21:59, 15 August 2022 (UTC)
I have also been fixing these as they come across my watchlist. Most take a minute or two of work. Often the tag signifies a permanently dead link, meaning that a new source must be found. I don't see this as materially different from a "more sources needed" tag, which would always go at the top of the page. BD2412 T 22:32, 15 August 2022 (UTC)
Thanks, @BD2412. That's how I view it too.
Straightforward dead URLs are not too hard to deal with: a HTTP 404 or 410 response can be detected by tools and tagged wit {{dead link}}. In February & March this year I added that tag to bare URLs on about 80K articles.
At this stage, a high proportion of the remaining bare URLs are various forms of "dead": soft 404s, site usurped by one of the domain-reseller parasites, or requests time out, or DNS fails. It's very difficult to reliably detect many of those with tools, so most of them need manual attention ... which is why a prominent tag is so helpful, to encourage more editors to take that minute or two. BrownHairedGirl (talk) • (contribs) 22:49, 15 August 2022 (UTC)
Re BHG: To be clear, let me state again that it's great you're doing this clean-up work. I don't think fixing citations is bad. I don't think adding this template is bad when they can't be fixed. However, there exist many problems which are important but only solvable by a very small subset of people - and further, we'd only even really want that small subset to do it. We don't post nuclear reactor safety procedures on highway billboards, because there is simply no expectation random passerby drivers will decide to drop everything and become atomic technicians. Learning the intricacies of the Wikipedia citation system is simply not something we expect most people to know - I would wager most editors (by number, not edit count) don't know it (the people who post on Village Pump are the hardest of the hardcore, we're not a good sample set here). Basically, even if we accept for a moment that this is of towering importance, merely being important doesn't have anything to do with the proper way to flag the problem, in the same way that important software bugs need to be filed against the devs who can do something about it, not to random readers. I will again my raise my example of errors in citation templates from misspelled parameters and the like. Serious question - if you were emperor of Wikipedia for a day, would you make it so that a bad citation template caused a warning seen by everyone, rather than just editors in preview mode? Because it seems like the exact same argument could be used to highlight this kind of problem. But it simply isn't important for readers, and editors can notice and fix it on their time.
On my earlier comment, let me be precise: when I say that bare URLs are no big deal, I mean that an edit that adds content with a bare URL is no big deal. Obviously, for Wikipedia-as-a-whole, it'd be good to fix it. But an individual contributor can contribute how they like or is convenient for them, and they shouldn't be shamed for it. The important thing is that it is an accurate reference as far as content - a simple URL or piece of text that's helpful is great, and a perfectly formatted citation that does not really reflect the source is a big problem. This edit added an extraordinarily vague text reference... but it was enough for me to find it, and confirm it was real, and format it all nicely (diff). The original edit that added this absolutely helped Wikipedia. It wasn't a "problem" or a big deal. That's what I'm saying. SnowFire (talk) 21:59, 15 August 2022 (UTC)
@SnowFire: Thanks for your kind words. They are v much appreciated, because this year of bare URL filling an tagging has been lonely work, with far more angry outbursts directed at me than thanks or encouragement.
But we still disagree radically, over your comment there exist many problems which are important but only solvable by a very small subset of people.
I really really really hope that you are completely wrong about that, because adding decent refs is the core task of any content editor. If that really is the preserve of a tiny minority, we should all just give up pretending that this is an encyclopedia. BrownHairedGirl (talk) • (contribs) 22:37, 15 August 2022 (UTC)

Searches by Guarapiranga

Funny, I got here searching for mentions of {{Cleanup bare URLs}} at WP:VPT (I don't usually come to WP:VPM), and didn't expect to find such a debacle about it. I'm one that takes great satisfaction in calling ref fix tools on pages that BrownHairedGirl tags for ref cleanup. I like first running BrandonXLF's fast and easy ReferenceExpander for basic expansion, then WP:REFILL, which is particularly good at eliminating duplicate refs, and finally WP:Citation bot for the finishing touches. I'm indifferent as to whether the tag should be up top or at the reference section; the important thing is that the article be included in the Category:All articles with bare URLs for citations. But the actual reason I came here is bc I think +63K pages is nowhere near enough (let alone 17K!)—I find over 657K articles with bare url refs—and wanted to go about mass tagging them all. — Guarapiranga  07:25, 16 August 2022 (UTC)

I think that BHG is right when it comes to verifiability. If we call this effort useless just because some don't like it, it brings into question other policies. I agree the average Wikipedia reader might not care for it - so maybe make it so only editors can see the banner. But the general idea of bringing it to peoples attention is abosuletly necessary. Rlink2 (talk) 23:06, 16 August 2022 (UTC)
  • For a year now, I have been working every day with regexes to identify bare URLs. It's a bit wearing to find someone coming to a discussion like this and repeatedly posting as fact nonsense data which they clearly have not even tested.[1]
    No need to get twisted about it, BrownHairedGirl; just best me. Care to share your estimates and regexes? I'm still getting over half a million untagged articles with bare url refs (regex times out).
  • Your revised search is still broken, because it is far too simplistic.
    For examples, your search will not recognise inline tagged bare URLs: <ref>http:/foobar.com/foo {{Bare URL inline|date=June 2022}}<ref>.[1]

    Right. How about 196 then?
  — Guarapiranga  04:31, 18 August 2022 (UTC)
@Guarapiranga: the reason that I am annoyed is that three times you disrupted the discussion by asserting as fact figures which are wholly wrong, because they are based on crude assumptions which you did not test. That false data misleads other editors, and thereby disrupts consensus formation.
You could and should have struck out the false numbers, but you have chosen not to do so.
The reality is that any regex which matches all bare URLs will time out when run through the web interface. I get my definitive numbers from scanning the twice-monthly WP:Database downloads, but the most recent of those was 17 days ago, on 20220801. Since then, huge progress has been made (>15,000 articles which then had untagged bare URLs no longer meet that criterion), so those numbers are way out of date.
Explaining this in full is quite involved, and it would take me about 30 minutes to write it up. Instead, I will give you a few quick pointers.
  • Regex search to match all bare URL refs: insource:/\<ref( [^\>]*)?\> *\[? *https?:\/\/[^ \<\>\{\}]+ *\]? *(\{\{bare *url[^\}]*\}\} *)?\<\/ref/i
    Note: it will timeout
  • Simplified regex search to match all untagged, unbracketed bare URL refs: insource:/\<ref( [^\>]*)?\>https?:\/\/[^ \<\>\{\}]+ *\<\/ref/i
    That will run, and currently gives 55,094 untagged, unbracketed bare URL refs (note that it includes commented-out bare URL refs, of which there are a few hundred). I use that regex many times per day to track progress.
  • Articles with inline-tagged bare URL refs: a Petscan search gives 51729 results
However, the two sets overlap significantly. Based on experience of the database scan, I estimate that the combined set of unique entries will be about 90,000 articles, +/- 5,000. I will have more accurate data when I have analysed the forthcoming 20220820 database dump; I should have generated numbers by 20220822.
But that estimate of ~95K remaining articles with one or more bare URLs is down from ~470K when I started work on this in May 2021. That's 80% fewer articles, and about 95% fewer bare URLs (because many articles had multiple bare URLs, but remain on the list until all bare URLs are removed).
Note that all these sets are rapidly changing, because:
  • New bare URLs are added at a rate of over 300 per day
  • Citation bot is filling bare URLs every day, and a new extra-thorough bare-URLs-only-mode has massively increased its productivity. In the last 24 hours alone, it has filled a few thousand bare URL refs.
  • My inline-tagging processes (e.g. User:BrownHairedGirl/No-reflinks websites) apply inline bare URL tags at a rate of over a hundred per day.
  • I personally fill or tag a few hundred bare URLs every day. Other editors also do great work on bare URLs.
As a result of all that ongoing work, my daily removal of redundant {{Cleanup bare URLs}} banners this morning (based on an overnight scan) removed 241 "Cleanup bare URLs" banners.
See also the history of User:BrownHairedGirl/Articles with new bare URL refs, which explains some of the regexes and numbers. The current version shows the progress on the 20220801 database dump. BrownHairedGirl (talk) • (contribs) 10:14, 18 August 2022 (UTC)
@Guarapiranga, I clicked your regex search link, which you say finds 657K articles. I opened the first ten search results. Seven of them contained no bare URLs at all. (Also, it only found 488K for me.) But I want you to look at the results that you're finding: Psychology#cite note-18, Jews#cite note-105, and Renaissance#cite note-75. The refs say:
  • T.L. Brink. (2008) Psychology: A Student Friendly Approach. "Unit One: The Definition and History of Psychology." pp 9 [1] Archived 24 July 2012 at the Wayback Machine.
  • The people and the faith of the Bible by André Chouraqui, Univ of Massachusetts Press, 1975, p. 43 [1]
  • "Scientific Revolution" in Encarta. 2007. [1]
Do you know what those [1] links are? They are not bare URLs. From the first sentence of Wikipedia:Bare URLs: "A bare URL is a URL cited as a reference for some information in an article without any accompanying information about the linked page" (emphasis in the original). When the ref includes "accompanying information" like the author's name, the publication date, the publisher, etc. "about the linked page", that is not a bare URL. That's just a WP:CITEVAR situation, not a bare URL.
I mention this because I think you should either drop this entirely, or spend a while validating your claims. You started off claiming that 10% of all Wikipedia articles ("over 657K" out of our current total of 6.571 million articles) have bare URLs, but when people told you that you were wrong, you don't seem to have tried to check your estimates. For example, you could have clicked on Special:Random 10 or 20 times to see whether your results made any sense. You could have checked the pages in your search results, like I just did. You claimed 10% of articles might contain bare URLs; I'm telling you that 0% of the ones I checked in your list actually contain bare URLs, and only 30% of them even contained something that could have been mistaken for a bare URL. I can't tell you how to get a complete and accurate list, but I can tell join the chorus of people telling you that your original method is producing wildly inaccurate results. If you don't want to just wash your hands of the whole mess, then maybe ask for help at Wikipedia:Village pump (technical) or at Wikipedia:Request a query. WhatamIdoing (talk) 19:05, 18 August 2022 (UTC)
  • When the ref includes "accompanying information" like the author's name, the publication date, the publisher, etc. "about the linked page", that is not a bare URL. That's just a WP:CITEVAR situation, not a bare URL.
    Right, I see. Indeed I was searching for refs without citation templates.
  • I clicked your regex search link, which you say finds 657K articles. I opened the first ten search results. Seven of them contained no bare URLs at all. (Also, it only found 488K for me.) But I want you to look at the results that you're finding
    So, tbh, I only looked at what the search function showed as detail under each result; I didn't verify each article (and the regex times out; it throws different numbers each time I run it, but they're all in the hundreds of thousands).
I still find +250K untagged articles with bare url refs, even after making some of the corrections BrownHairedGirl suggested above):
  • Islamic State [[Misogyny]]<ref>[https://www.theatlantic.com/international/archive/2017/09/isis-female-suicide-bomber/539172/ The Myth of the ISIS Female Suicide Bomber]</ref><ref>[https://www 299 KB (24,648 words) - 07:43, 11 August 2022
  • Taiwan Coordinates: 24°N 121°E / 24°N 121°E / 24; 121 Taiwan, officially the Republic of China (ROC), is a country in East Asia, at the junction of the East 294 KB (30,919 words) - 03:24, 16 August 2022
  • Napoleon little besides this untruth about him.<ref>[https://www.britannica.com/story/was-napoleon-short Was Napoleon Short?]</ref> At {{convert|5|ft|2|in|m|order=flip}} 226 KB (24,856 words) - 08:07, 17 August 2022
  • Brazil Coordinates: 10°S 52°W / 10°S 52°W / -10; -52 Brazil (Portuguese: Brasil; Brazilian Portuguese: [bɾaˈziw]), officially the Federative Republic of Brazil 258 KB (23,699 words) - 02:47, 16 August 2022
  • Panama Papers and Josh Baazov.<ref>[https://joshbaazov.ca/how-josh-baazov-made-of-david-a-criminal-jonah/ The Criminal Story Of Josh Baazov | AMF]</ref> While offshore 157 KB (14,246 words) - 10:13, 17 August 2022
  • Colombia [[beef]] and [[chicken meat]]. <ref>[http://www.fao.org/faostat/en/#data/QCL/ Agriculture and Livestock in Colombia, by FAO]</ref><ref>[https://revistacafeicultura 243 KB (20,507 words) - 12:20, 10 August 2022
  • Wales 1981.<ref name=":03">[http://www.statistics.gov.uk/CCI/nugget.asp?ID=445 Results of the 2001 Census: Country of birth (www.statistics.gov.uk)]</ref> The 213 KB (21,290 words) - 11:55, 17 August 2022
  • Amazon Prime Video Amazon Prime Video, or simply Prime Video, is an American subscription video on-demand over-the-top streaming and rental service of Amazon offered as a 46 KB (4,001 words) - 17:05, 4 August 2022
  • Lyndon B. Johnson Lyndon Baines Johnson (/ˈlɪndən ˈbeɪnz/; August 27, 1908 – January 22, 1973), often referred to by his initials LBJ, was an American politician who served 197 KB (23,239 words) - 14:05, 15 August 2022
  • Papua New Guinea infrastructure.<ref>[http://www.inapng.com/pdf_files/Private%20Sector%20Report%20Final%2012Feb.pdf] Institute of National Affairs (2013)</ref> === Land tenure 115 KB (11,697 words) - 10:52, 12 August 2022
  • Genghis Khan Mongols.<ref name="guide">[http://www.travelchinaguide.com/intro/history/yuan/index.htm Yuan Dynasty: Ancient China Dynasties, paragraph 3.]</ref>{{failed 111 KB (12,814 words) - 18:23, 13 August 2022
  • Gibraltar --number only--> | HDI_ref = <ref>[https://en.populationdata.net/rankings/hdi/] Rankings – Human Development Index (HDI)</ref> | HDI_rank = 3rd | currency 119 KB (11,430 words) - 10:05, 14 August 2022
  • Assumption of Mary up to heaven.<ref>[http://www.ewtn.com/faith/teachings/maryc3c.htm] ''More on the Assumption of Mary'' by Fr. William Saunders, EWTN</ref>}} ==History== 46 KB (4,970 words) - 07:55, 17 August 2022
  • Zeus Hecalesius and [[Hecale]].<ref>[https://www.perseus.tufts.edu/hopper/text?doc=Perseus:text:2008.01.0067:chapter=14 Plutarch, Theseus, 14]</ref> *'''Hetareios''' 162 KB (14,263 words) - 05:14, 15 August 2022
  • Irish people | ref9 = <ref>[http://www.europeanirish.com/germany/an estimated 35,000-more than 1 million enjoy Irish culture]</ref> | region10 93 KB (9,555 words) - 13:24, 14 August 2022
  • Shopping mall A shopping mall (or simply mall) is a North American term for a large indoor shopping center, usually anchored by department stores. The term "mall" originally 83 KB (5,791 words) - 08:03, 13 August 2022
  • Ashkenazi Jews Ashkenazi Jews (/ˌɑːʃkəˈnɑːzi, ˌæʃ-/ AHSH-kə-NAH-zee, ASH-; Hebrew: יְהוּדֵי אַשְׁכְּנַז, romanized: Yehudei Ashkenaz, lit. 'Jews of Germania'; Yiddish: 145 KB (17,056 words) - 06:02, 17 August 2022
  • Economy of India global supply of generics by volume.<ref name=":0">https://www.ibef.org/download/pharmaceuticals-jan-2019.pdf<br /></ref> The Indian pharmaceutical sector 251 KB (22,764 words) - 16:37, 14 August 2022
  • Java = 407| isbn = 9792624996}}</ref><ref>[https://books.google.ch/books?id=VNgUAAAAIAAJ&pg=PA237 Modern Times, p.237]</ref> According to Chinese record ''[[History 59 KB (6,179 words) - 03:56, 12 August 2022
  • Charles Dickens Charles John Huffam Dickens FRSA (/ˈdɪkɪnz/; 7 February 1812 – 9 June 1870) was an English writer and social critic. He created some of the world's best-known 171 KB (18,259 words) - 01:02, 18 August 2022
Are these not bare url refs either?
  • I don't understand the litigious and disputatious tone here. Quite WP:UNCIVIL. Yes, I know you and BrownHairedGirl work relentlessly at tagging and removing bare url refs. As I said above, I'm one that takes great satisfaction in calling ref fix tools on pages that BrownHairedGirl tags for ref cleanup. Including your WP:Citation bot! WP:AGF, pls. I didn't intend to make any claims; just reporting what I'm finding. I'm just trying to help (but it sounds like you gals don't want any; WP:OWN much?).
Guarapiranga  01:44, 19 August 2022 (UTC)
@Guarapiranga: if you want to help, then the first step would be to check whether any figures you assert are accurate.
You failed repeatedly to do that, and you have still not struck your false assertions, leaving them live to mislead other editors. Striking falsehoods would be a good way of demonstrating your good faith, which would be advisable before you throw accusations of incivility at others.
But instead you post yet another set of bogus numbers, from yet another broken search. Sigh. BrownHairedGirl (talk) • (contribs) 01:55, 19 August 2022 (UTC)
  1. figures you assert are accurate.
    I didn't; it's just what I found. You corrected me, and I stand corrected.
  2. You failed repeatedly to do that
    Sure, trial and error. Isn't that the wp:cycle of life?
  3. you have still not struck your false assertions, leaving them live to mislead other editors.
    Editors following this discussion can see how we refined our estimates in the conversation.
  4. Striking falsehoods would be a good way of demonstrating your good faith
    I don't have to. If you believe I'm acting in bad faith, it is you have to demonstrate it. That's what WP:AGF means.
  5. you throw accusations of incivility at others.
    It's not an accusation; I'm not throwing anything; I'm simply asking to return to a wp:civil tone.
  6. But instead you post yet another set of bogus numbers, from yet another broken search.
    Happy to be corrected. And where's that? All this energy on wp:behavioural issues, and very little on the actual issue at hand (bare url refs). This time: none.
I sigh too. — Guarapiranga  04:19, 19 August 2022 (UTC)
Based on the extracts in the produced table, the following do not appear to have bare URLs: Islamic State, Panama Papers, Wales, Papua New Guinea, Genghis Khan, Gibraltar, Assumption of Mary, Zeus, Irish people, Java. That is not to say that these are particularly good reference tags though, as several look like they need significant cleanup.
The following appear to have bare URLs; Napoleon, Economy of India
Additionally the following extracts appear to have no URLs or ref tags; Taiwan, Brazil, Amazon Prime Video, Lyndon B. Johnson, Shopping mall, Ashkenazi Jews, Charles Dickens.
That is not to rule out that any or all of these articles may have bare URLs within their citations, I am merely commenting on the extracts provided in the table. However if those articles do not have any bare URLs within, then based on those extracts, your search parameters appear to be faulty on multiple levels and are returning a lot of false positives. Sideswipe9th (talk) 02:13, 19 August 2022 (UTC)
the following do not appear to have bare URLs: Islamic State, ...
Isn't that a bare url ref?
<ref>[https://www.theatlantic.com/international/archive/2017/09/isis-female-suicide-bomber/539172/ The Myth of the ISIS Female Suicide Bomber]</ref>
I just ran BrandonXLF's ReferenceExpander on that article, and it seemed to think it was, bc it expanded it. — Guarapiranga  03:56, 19 August 2022 (UTC)
Same with
<ref>[https://joshbaazov.ca/how-josh-baazov-made-of-david-a-criminal-jonah/  The Criminal Story Of Josh Baazov | AMF]</ref>
in Panama Papers, which ReferenceExpander just expanded as well. — Guarapiranga  04:08, 19 August 2022 (UTC)
Nope, as was previously explained by Whatamidoing per Wikipedia:Bare URLs these are not bare URLs, because they include accompanying information about the linked page. In this case, the accompany information is the article title. What ReferenceExpander has done is convert it from one WP:CITEVAR to a Citation Style 1 template. Bare URLs are citations like <ref>http://www.example.com</ref> or <ref>[http://www.example.com]</ref>, which contain a URL with no accompanying information.
These examples are insufficient citations, but that is for reasons other than a potential bare URL issue. Sideswipe9th (talk) 04:12, 19 August 2022 (UTC)
(edit conflict) A bare URL is a URL cited as a reference for some information in an article without any accompanying information about the linked page - Wikipedia:Bare URLs. The fact that some tool runs on things that aren't bare URLs does not make them bare URLs. * Pppery * it has begun... 04:12, 19 August 2022 (UTC)
One of the examples of bare url there is:
Some text [http://support.nikontech.com/app/answers/detail/a_id/14083 Nikon] more text
Isn't that the same? Or are you saying that by simply including <ref> tags, it is no longer bare? — Guarapiranga  04:31, 19 August 2022 (UTC)
That example is explained in the page you quoted it from: the "text" provides only the name of the company, which is already present in the domain name of the URL itself.
I had a quick look at the first 10 in your list. Brazil#cite note-44 and Papua New Guinea#cite note-92 are IMO lousy, but I found no actual bare URLs in any of the 10 articles that I looked at.
Looking at your excerpts, I think the point that you're missing is that a link that contains the title of the source is not a bare URL.
This is checkY good enough: [https://www.example.com Title of Article]
This is ☒N a bare URL: [https://www.example.com]
If you were trying to identify the difference between the "good enough to not count as a bare URL" version and "it has a label but the label is just the website's name", you'd need to set up a regex that finds [https://www.example.com Example] and subsets such as [https://www.example.com Exam] and [https://www.example.com Exam Ple] but not [https://www.example.com Any other string]or [https://www.example.com Any other string plus Exam or Example or Exam Ple].
You might try to focus on just one type of absolutely unambiguous, completely indisputable bare URL. Start with the easier stuff, and get that right first. WhatamIdoing (talk) 05:27, 19 August 2022 (UTC)
I think the point that you're missing is that a link that contains the title of the source is not a bare URL.
Indeed I was. Looks pretty bare to me, but now I get it that the wp:bare url definition is barer still. So this hoopla and shoe throwing—with me at least—has been down to semantics. And all the number shouting was bc I was searching for lousy refs, or lato sensu bare, and you and BHG were speaking of stricto sensu bare ones. And I get it that you've got yours hands full with the sensu stricto ones already, but perhaps we need a second process to deal with the lousy ones. Do we already have a template notification for that? — Guarapiranga  22:29, 20 August 2022 (UTC)
Ah, we do—{{Full citations needed}}—but it's barely used. And I can't find a category for it either. Found it! 8K?? Yeah, that's vastly undercounted. — Guarapiranga  23:30, 20 August 2022 (UTC)
Imagine that the tags were all perfectly attached to every article. What do you hope that would accomplish? WhatamIdoing (talk) 04:47, 23 August 2022 (UTC)

Analysis of new articles

I looked at the last 10 articles in Special:NewPagesFeed (an easy way to get a random sampling of articles by random editors):

  1. Krapopolis has properly formatted refs
  2. Shelley, Victoria has no refs at all
  3. Draft:Killing of Christian Obumseli has non-bare, but incompletely filled, refs
  4. Karambalangan has properly formatted refs
  5. 2022–23 Xavier Musketeers men's basketball team has non-bare, but incompletely filled, refs
  6. Alternative Mitte has properly formatted refs, although it also has a bunch of "Cite error: reference named X was invoked but never defined".
  7. Club Leoncio Prado has a non-bare, but incompletely filled, ref.
  8. Mamma, 'k wil 'n man hê has no refs at all
  9. List of countries by net reproduction rate has properly formatted refs.
  10. Justin Garza High School has properly formatted refs.

So, overall, 5 articles with properly formatted refs, two with none at all, and three with incompletely filled refs (and no bare URLs, although I certainly have seen bare URLs at New Page Patrol elsewhere). Each of these was created by a different editor. I'd say that refutes SnowFire's claim.

While I was composing this comment, Anne-Sophie Lavoine was created with bare URLs. But it's still the case that from that sample that most editors can fill refs properly. * Pppery * it has begun... 22:50, 15 August 2022 (UTC)

Re * Pppery * and "this refutes SnowFire's claim": first off, let's not get distracted on a side matter. The exact proportion isn't really that important and it doesn't solve the other issues I brought up, most pertinently that of the reader experience (e.g. articles with no active editors whatsoever, but that has readers who are warned that 1 of the 20 references is a bare URL). But if we're going to discuss it - no, it doesn't refute it. You're saying that 3/8 of the articles with references don't have properly formatted citations. That is a huge amount. Even if a larger sample size shows it's less, say 20%, that is still a gigantic amount! Remember, we are hypothetically talking about informing editors who A) view a page, but B) don't have this page already watchlisted. Many of these will be people who edit very rarely and don't show up in new page patrol anyway, because IP editors can't create new articles directly. So we're talking about the least active of active editors (in the sense of people, not accounts). Surely, surely you've run into such editors who clearly aren't that familiar with Wikipedia and stop by for the occasional edit. These editors are unlikely to fix a bare URLs cleanup request, whether they're 20% or 50% or some other amount of the total editor base. The editors who will fix it are hardcore editors who have the article on their watchlist, and they'll see the notification regardless of where it's placed, on top, in references, even if it was placed on the talk page. SnowFire (talk) 00:20, 16 August 2022 (UTC)
@SnowFire, I don't agree with your analysis of incidence, but let's set the numbers aside for mo.
It seems to me that you are asking for those editors who are unaware of a problem with their edits to be shielded from notices which show them that bare URLs are a problem.
And that seems to me to be the precise opposite of that we should be doing. Obviously, we should not be rude or hostile, but a polite and non-personal notice warning of a problem on a page attributes no blame and is no way the "shaming" which you referred to above. BrownHairedGirl (talk) • (contribs) 00:29, 16 August 2022 (UTC)

You consider the addition of bare URLs a problem, BrownHairedGirl. I consider their addition a valuable contribution. The encyclopedia has survived very long without so severely increasing the visibility of bare URLs. Nothing in your work requires a topside banner. All in all, I think your chosen approach is overly confrontative. CapnZapp (talk) 17:47, 16 August 2022 (UTC)

Conduct allegations

So to the point at hand about this good work. Should we move the non reader warning out of the lead and to the ref section. Not one person here has claim this work is a problem.....but accessibility and reader retention is the concerned raised about Banner placement. Wonderful to see the work being done.....just the approach could have some amendment to it .Moxy- 22:55, 15 August 2022 (UTC)
Sigh. That is a bare-faced lie by @Moxy, in their assertion that not one person here has claim this work is a problem.
On the contrary, Moxy opened[6] this discussion with a headline complaint that it is Mass spamming, and used that same phrase in the first para.
And in their discussion on their talk, Moxy called tagging mass bare URLs simply crazy.
I don't see why we should tolerate having any discussion polluted by an editor who brazenly lies about their conduct.
If Moxy has changed their mind and recognised the value of this work, then they should says so. BrownHairedGirl (talk) • (contribs) 23:10, 15 August 2022 (UTC)
It is crazy to add thousands of these to the top of articles like a bot. Working of fixing refs is great....but banner spam is a problem....as outlined by a few here. Moxy- 23:16, 15 August 2022 (UTC)
Yet again, @Moxy's reply is simply to insult my work as crazy, instead of explaining in civil terms why they think that it is a problem.
And of course, Moxy makes no effort to retract their lies. Instead they try to limit their use of the word crazy to the top of articles. But in March, on their talk, Moxy used the phrase simply crazy to describe my addition of the inline tag {{Bare URL PDF}}.
Other editors are discussing this with reasoned civility, and without denying their own stance. Please, Moxy, either stop lying and stop insulting ... or leave this discussion. BrownHairedGirl (talk) • (contribs) 23:27, 15 August 2022 (UTC)
Never said anything personal about you here. More then willing to leave the talk to others as its clear you can't communicate normally with me.... it's a long standing problem with me and others. Good luck..... hoping that we favor reader retention and accessibility as the outcome over this. Moxy- 23:37, 15 August 2022 (UTC)
@Moxy: you have lied repeatedly, and now you lie again, by denying that calling an editor's work crazy is a personal attack.
If you regard that sort of conduct as normal, then god help us. BrownHairedGirl (talk) • (contribs) 00:04, 16 August 2022 (UTC)
Jesus have you seen the above. 204.237.48.146 (talk) 01:40, 17 August 2022 (UTC)

Bot request process

One thing that's clear is if this is being added in a bot-like manner, this is covered by WP:MEATBOT. If the mass addition of bare URL banners are considered desirable, the community should consider having an actual bot handle things and have all the benefits this entails. Headbomb {t · c · p · b} 23:41, 15 August 2022 (UTC)

@Headbomb: a bot might be desirable in theory, but it is unlikely in practice, since WP:BRFA is so massively dysfunctional.
My last BRFA was for a bot to remove {{Cleanup Bare URLs}} banner when it was no longer needed. That BRFA derailed by your extreme aggression, abuses of process and repeated counter-factual assertions. It was a hideous, horrible experience, and after that I decided not to open a BRFA again. Instead, I took the code that I had written, modified it slightly, and have been running it repeatedly for 8 months without a single objection from anyone.
If BRFA can be reformed to be more responsive (it's horribly laggy) and to exclude your appalling conduct, then I will consider a BRFA for this task. But I have had two very unpleasant experiences in which BAG members have just piled on to endorse your aggressive misjudgements. BrownHairedGirl (talk) • (contribs) 00:01, 16 August 2022 (UTC)
Funny how everyone is wrong and that you get no single issues except multiple comments on your talk page and elsewhere asking you to stop, and the community asking for alternatives to what you're doing. There was no abuse of process, you just decided not to comply with the requirement for bots because you didn't agree with them. You had your review, which concluded with

The discussion seems to be going round in circles a bit. To summarise: 5 BAG members have now reviewed the situation, along with other community members, and those opining on the issue overall seem to support the declining BAG member's rationale. Feedback has been provided on how a future bot request could be modified to address the concerns and gain approval. BHG's 14:56, 23 December 2021 comment indicates to me she understands what these steps are, even if she doesn't agree with them. Alternatively, an editor can put the question to the community via RFC. If the community decides the bot task is acceptable as-is, without any modifications, then the bot request can be looked at again. ProcrastinatingReader (talk) 20:47, 23 December 2021 (UTC)

If you don't want to code such a bot for whatever reason, then you can always make a WP:BOTREQ and let someone else handle it.
Headbomb {t · c · p · b} 00:08, 16 August 2022 (UTC)
On the contrary, @Headbomb, the problem was simply that you read the bot's purpose literally, and missed the key point that the purpose of the bot was to remove the {{Cleanup Bare URLs}} banner from pages where it was no longer needed.
You throw a massive wobbly over the code ignoring refs which have already been tagged as inappropriate, as if there was some purpose in retaining a big banner asking editors to fill refs where the required action is to remove or replace them. And the rest of BAG weighed in behind you, which looks like a very unfortunate episode of groupthink.
And yes, there was abuse of process. After I had asked for input from other BAG members, you kept on piling on, and you made counterfactual assertions which you failed to retract, and then you closed the BRFA before other BAG members could offer input. That, my friend, is multiple abuses of process.
And the aftermath is that in the last 8 months I have made well over 10,000 edits using a slightly-modified version of that code, with lots and lots of thanks notifications from editors, and not a singe complaint. So no, I will not take that back for another hazing at BRFA.
If you want to open an RFC, then feel free to do so. But I think that 8 months of objection-free removal of redundant {{Cleanup Bare URLs}} banners is good evidence that the community does not endorse your view. BrownHairedGirl (talk) • (contribs) 00:22, 16 August 2022 (UTC)
"that the purpose of the bot was to remove the {{Cleanup Bare URLs}} banner from pages where it was no longer needed"
Indeed. And your bot would have removed the tag from pages where it was still needed (i.e. pages with bare urls remaining), and therefore was declined because it failed to behave in line with its purpose. You may disagree with it, but you haven't shown that the behaviour you're seeking (the removal of cleanup tags from pages with bare URLs tagged with other cleanup issues) has consensus, and so the bot remained unapproved.
As mentioned several times, you could at any time have made an RFC demonstrating consensus for your bot's proposed behaviour, or modify the bot to behave as one would expect. You haven't, so here we are. Headbomb {t · c · p · b} 00:30, 16 August 2022 (UTC)
And where we are is that after 8 months of use and over 10,000 edits there has bot been a single objection to my AWB job.
Nobody at all, not even one person, has commented to me that we should retain at the top of an article a big banner about filling bare URLs which should actually be replaced or removed. Nobody. Nada. Zilch.
And even after 8 months, it seems that you still do not comprehend that simple issue. Which is one of the reasons why I am bot going back to BAG to face more such absurdities. BrownHairedGirl (talk) • (contribs) 00:38, 16 August 2022 (UTC)
PS just to clarify: I don't want to code such a bot for the simple reason that it would be superfluous to the AWB job which I have been running for 8 months since my BOTREQ was hazed out, with zero objections.
And I also do not want to make a BOTREQ, because I see no purpose in your vision of a hobbled bot doing a subset of tasks which are already in hand. BrownHairedGirl (talk) • (contribs) 00:33, 16 August 2022 (UTC)
PS @Headbomb: if you still cling to your view, then please you go open that RFC you talk of.
The RFC question is simple: "Should we retain at the top of an article a big banner about filling bare URL refs which have already been tagged as unsuitable, and which should therefore be replaced or removed".
Lemme know how you get on. BrownHairedGirl (talk) • (contribs) 00:45, 16 August 2022 (UTC)
Fine, you want an RFC, I'll give you an RFC. Headbomb {t · c · p · b} 00:59, 16 August 2022 (UTC)
But not on the topic where I challenged you. The TFC below looks time very much like you playing games out of revenge, because you lack the confidence to ask for community input input on the stance which I did suggest you hold an RFC.
Instead, you open another RFC with a loaded question in which you don't even acknowledge the reason why I have not opened an RFC for adding the banner tags. Very poor conduct, Headbomb, BrownHairedGirl (talk) • (contribs) 01:07, 16 August 2022 (UTC)
I agree an RfC on "Where should the Cleanup bare URLs template be placed? 1. At the top of the page (current practice) 2. At the top of the references" would be better than the offerings below. If people want we can have a "3. Template should be depreciated" but I don't see anyone advocating for that in this discussion. Best, Barkeep49 (talk) 01:10, 16 August 2022 (UTC)
@Barkeep49: such an RFC might have some merit, but it's going to cause overload if this page also contains Headbomb's two disruptive revenge-RFCs. BrownHairedGirl (talk) • (contribs) 01:26, 16 August 2022 (UTC)
There is a reason I suggested it instead of the two RfCs below. It's a question in one of the RfCs but I'm not sure how much actionable feedback we'll get for a close. Best, Barkeep49 (talk) 02:01, 16 August 2022 (UTC)

Alternate technical solution possibilities? Requesting input

Alternate technical solution possibilities? Requesting input @ Wikipedia:Village pump (technical)#Color differentiation in reference numbering

Thanks

Bookku, 'Encyclopedias = expanding information & knowledge' (talk) 04:18, 16 August 2022 (UTC)

@Bookku: this an accessibility issue. See MOS:COLOR: "Ensure that color is not the only method used to communicate important information".
So the use of color in problematic refs may be an a helpful addition (if technically possible; I can see some difficulties), but it cannot replace textual notifications. BrownHairedGirl (talk) • (contribs) 04:57, 16 August 2022 (UTC)

RFC: Should the mass ADDITION of Cleanup bare URLs be done by bots or meatbots?

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Speedy close Upon reviewing this RfC, the related one below, and the related talk sections above, it seems unlikely that there could be any valid consensus outcome based on the question asked. That is not to say of course that consensus could not be found around a different question, and further discussion is encouraged along those lines.


I realise that this is a controversial speedy close, and I gladly welcome any comments, challenges, or requests for clarification at my talk page as a result. (non-admin closure) Sideswipe9th (talk) 03:50, 18 August 2022 (UTC)


There are two questions.

  1. Should the mass ADDITION of {{Cleanup bare URLs}} be done by bots or meatbots?
  2. At what location in articles should these be added? At the top of the page, or in the reference section?

Headbomb {t · c · p · b} 01:01, 16 August 2022 (UTC)

Discussion (mass addition of Cleanup bare URLs)

  1. It would be highly preferable to do this by bot IMO. Additionally, these should be at the top of the page since you can have bare URLS in many place other than reference sections. These bare URLs could be in a further reading section, external links section, in the main text, or anywhere else. Headbomb {t · c · p · b} 01:14, 16 August 2022 (UTC)
  • Speedy close this blatantly bad faith RFC. This is a deliberately disruptive exercise, opened as revenge for the fact that I explained above to Headbomb how his objection to removal had no support, and how his aggressively process-abusing closure of WP:BHGbot 9 had not prevented me from removing redundant banners from over ten thousand articles over the last 8 months, without a single objection from anyone. --BrownHairedGirl (talk) • (contribs) 01:24, 16 August 2022 (UTC)
    I rather tire of these WP:ABF accusations. You wanted an RFC, I gave you one. There is no 'revenge'. The wording is neutral, and covers all relevant issues. Headbomb {t · c · p · b} 01:26, 16 August 2022 (UTC)
    @Headbomb: your bad faith is as plain as a very plain thing.
    This is just an exercise in wasting my time, motivated by revenge. BrownHairedGirl (talk) • (contribs) 01:29, 16 August 2022 (UTC)
    Listen to yourself for a second. Revenge? For what? For doing cleanup work? For wanting clear guidance on an issue where there is disagreement? For wanting a productive path forward? Again, read what you wrote in light of WP:AGF. Headbomb {t · c · p · b} 01:32, 16 August 2022 (UTC)
    No, you listen to yourself.
    This is transparent revenge for the fact I explained to you how your tantrums and process abuse at BRFA did not prevent me from doing valuable and uncontroversial cleanup work by ignoring your absurdist demands. BrownHairedGirl (talk) • (contribs) 01:38, 16 August 2022 (UTC)
  • Note that I suggested to Headbomb that they open an RFC on the substantive issue in his dispute with me: "Should we retain at the top of an article a big banner about filling bare URL refs which have already been tagged as unsuitable, and which should therefore be replaced or removed".
    Sadly, Headbomb has chosen not to ask this question, and also makes no attempt to explain tye reasominh for his demand that editors should be faced with a big banner asking them to fill a bare URL ref which actually be removed or replaced.
    This reminds me of the Kerryman joke about the Kerryman who wrote a book which was so bad that the publisher rewrote it before binning it. Except that in this case, Headbomb is not joking: he genuinely wants editors to waste their time filling refs to unreliable sources ... which will then be removed.
    Why on earth would anyone demand that? ---BrownHairedGirl (talk) • (contribs) 01:50, 16 August 2022 (UTC)
  • Already had a bot at Template:Cleanup_bare_URLs/bot which had BRFA approval. It was made for this reason: there are so many pages with bare URLs, adding banners automatically is too disruptive. So we came up with this tagbot solution. It worked well. However once the banners started being added at a mass rate, it broke the model. Tagbot will only run if there are less than 5 or so existing banners, they need to be fixed before new ones are added. That was the idea. Fix em before you add em. But with 60k+ unresolved banners, the tagbot model is rendered useless. -- GreenC 02:07, 16 August 2022 (UTC)
    ... and the tagbot model didn't work. Template:Cleanup_bare_URLs/bot has 407 revisions, half of which are the bot setting the page to STOP and the other half of which are a human requesting a run. That means around 200 * 5 = 1000 pages with bare URLs have been tagged by GreenC bot. For comparison, BrownHairedGirl has filled thousands of pages with bare URLs in a matter of days or weeks. * Pppery * it has begun... 02:23, 16 August 2022 (UTC)
    Probably because you can't run it if there are > 5 in the tracking cat so once things got too large no one could use it. -- GreenC 03:09, 16 August 2022 (UTC)
    Not true. Tagbot ran from May 2019 to May 2021, which is about 2 years. It's been less than 2 years since tagbot last ran, so if BrownHairedGirl had not done bare URLs one can extrapolate and say tagbot would have run on at most another 1000 pages. That would not change my conclusion meaningfully. * Pppery * it has begun... 03:15, 16 August 2022 (UTC)
    @GreenC, you are missing @Pppery's point. In all the months that Tagbot ran, before it was displaced by wider tagging, it identified only 1,000 bare URLs in need of filling.
    As Pppery has noted, I fill more than that on many individual days, and much more than that every week. And the wider tagging allows many more editors to see that an article's URLs need filling.
    As I wrote below, tagbot was an honourable effort done in good faith, but the whole concept of only ever tagging a tiny subset of the problem was misguided. BrownHairedGirl (talk) • (contribs) 03:17, 16 August 2022 (UTC)
    Ok ok followed up below. (Tagbot was only as useful as people willing to use it, which was largely one person occasionally.) -- GreenC 03:35, 16 August 2022 (UTC)
    Yes @GreenC, that's it. And if I had listened to that one person's sniping at me, the last year's progress on bare URLs would never have happened.
    Thankfully, because this place is not a bureaucracy, I was able to find other ways to get most of the job done. That's why I am annoyed by Headbomb's vengeful attempts here to tie me up in bureaucracy about issues which he doesn't understand, and which I have learnt over the last year are rarely understood by editors who have not actually worked on these issues at scale. BrownHairedGirl (talk) • (contribs) 03:54, 16 August 2022 (UTC)
    @GreenC: there are not 60,000 banners. After my latest addition of a batch of 14,700 banners in thye last few days, there are about 18,000 banners. The other articles in Category:All articles with bare URLs for citations are there because of inline tags, e.g, {{Bare URL inline}} and {{Bare URL PDF}}
    Tagbot was made for a very different purpose, in a very different context.
    When Tagbot last ran, there were about 470,000 articles with bare URLs. Now, after a year of intensive cleanup by me, there are about ~100K. Many of the remaining articles with bare URLs have had one more URLs either filled or tagged as dead, so the actual progress is much greater than the article count implies.
    Tagbot was an honourable idea, but it was fundamentally flawed. It was designed to serve the needs of a small group of editors who worked slowly to fill a few bare URLs per day, and basically it just used tags to give that wee group a job list. Their work was of course valuable, but it was on far too small a scale to even keep up with the flood of new bare URLs, let alone dent the backlog. The problem was steadily getting worse. Evert day, new bare URLs were being added about ten times faster than others were filled.
    That is why I set about a different approach. After some trial and error, the method I developed was fourfold:
    1. Feed endless streams of huge lists to Citation bot to fill as many refs as possible
    2. apply inline tags where they would not impede other tool: i.e. non-HTML pages, and those which cannot be filled by WP:ReFill (see User:BrownHairedGirl/No-reflinks_websites)
    3. Develop other tools to identify dead links, and tag them with {{dead link}}.
    4. Identify sets of URLs which I could easily fill manually, and work on them.
    After a year of this. my approach has been a proven success. We now have ~90% fewer bare URLs than a year ago, and the widespread inline tagging of bare URLs helps any editors to identify bare URLs in articles within their interest. The small group of pioneers can still do their work, but now far more editors can find articles with bare URLs.
    Until the start of August 2022, I refrained fro systematically adding the {{Cleanup bare URLs}} banner, because some editors find it too intrusive. However, by this month the reduced bare URL count a massive increase in the capacity of Citation bot allowed me to do multiple passes of lists each month. Until May, I could not in any one month get Citation bot to process the full list of articles with HTML-format bare URLs, but after the upgrade I made a lot more progress and was able to process not just the whole set, but to do multiple passes on big lists.
    In July, I took my list of new bare URLs and processed the set 10 times (see User:BrownHairedGirl/Articles with new bare URL refs), until Citation bot could do no more. After some thought, I reckoned that we are now into the mopping-up phase of bare URLs, where manual input is needed: so I then applied the {{Cleanup Bare URLs}} banner to the articles in that set which still had one or more untagged bare URL refs (there were about 1150 articles remaining from July's two database dumps). I did not use the {{Bare URL inline}} tag, because that would prevent the use of WP:REFILL.
    Then I did the same thing with the new bare URLs from the 20220801 database dump. And when that was done, I made a list of 20,000 randomly-selected articles with bare URLs, and I got Citation bot to process that whole set 7 times.
    After those 7 passes by Citation bot (plus any other work on the set), that left 14,700 articles in the set which still had one or ore bare URLs. That's the set which I have just finished tagging.
    Please please let's not go back to the bad old days when most bare URLs were untagged and uncategorised, and where bare URL cleanup was the preserve of a small and formal group as the problem grew bigger and bigger.
    And please please, don't tie my work down in bureaucracy. WP:NOTBURO, and my approach is delivering results. Headbomb has twice abused BRFA as a hazing process against me, and I don't want my work to again be impeded by bureaucracy. BrownHairedGirl (talk) • (contribs) 03:02, 16 August 2022 (UTC)
    Sounds right, the volume of incoming bare URLs was larger than tagbot users were willing or able to keep up with. Maybe tagbot could be done a different way, would have to think about it. Your method of breaking the problem down into steps using various tools seems to be working for you. At some point you got all the low+medium hanging fruit and whatever left is a hard problem. The 80/20 Rule, I guess somewhere around 20% remaining? Generally Wikipedia follows the 80/20 Rule. The last 20% is harder than the first 80%. So we banner the 20%. I think that's important to understand this is the final step representing the hard cases. -- GreenC 03:31, 16 August 2022 (UTC)
    Thanks, @GreenC. I think we are on the same page now.
    Depending on whether we count bare URLs or articles with bare URLs, we either 95% done or 80% done. But either way, we are at the hard cases stage, where Citation bot's efforts now consist mostly of long waits for HTTP requests which timeout after a 45 second limit. (See User_talk:BrownHairedGirl#Zotero_only, where I talk to @AManWithNoPlan about his wonderful work in developing a bare-URLs-only mode which I suggested for Citation bot. That man's work is brilliant, and he deserves heaps more praise than he gets!)
    So yes, this is tagging the hard cases. BrownHairedGirl (talk) • (contribs) 03:45, 16 August 2022 (UTC)
    Headbomb has twice abused BRFA as a hazing process against me
    This is an utterly ridiculous and incorrect claim, and I would ask that you stop making it. There was unanimous agreement in the review that my closure was correct. Headbomb {t · c · p · b} 08:03, 16 August 2022 (UTC)
  1. Yes, absolutely. I find over +640K articles with bare url refs without the tag.
  2. Top, but only to editors, not readers. There's a lot of things that shouldn't be shown to readers; redlinks for a start (but I digress).
Guarapiranga  08:08, 16 August 2022 (UTC)
Utter nonsense, @Guarapiranga. There are not 640K articles with bare URLs, and AFAIK there never has been.
You got that nonsense number because your search is broken: it wrongly assumes that bare URLs (and only bare URLs) are wrapped in square brackets, e.g. [http://example.com/foo].
Neither assumption is true: almost zero bare URL refs use square brackets; and most refs which do use square brackets are filled, e.g. [http://examplew.com/balagan Balagan Today]
You might have spotted your error if you had checked your search results. For example, the first result in your broken search is [[Midfielder], which has no bare URL refs. BrownHairedGirl (talk) • (contribs) 11:20, 16 August 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RFC: Should the mass REMOVAL of Cleanup bare URLs be done by bots or meatbots?

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Speedy close Upon reviewing this RfC, the related one above, and the related talk sections above, it seems unlikely that there could be any valid consensus outcome based on the question asked. That is not to say of course that consensus could not be found around a different question, and further discussion is encouraged along those lines.


I realise that this is a controversial speedy close, and I gladly welcome any comments, challenges, or requests for clarification at my talk page as a result. (non-admin closure) Sideswipe9th (talk) 03:50, 18 August 2022 (UTC)


There are two questions.

  1. Should the mass REMOVAL of {{Cleanup bare URLs}} be done by bots or meatbots?
  2. Should bare URLs tagged with issues, like <ref>https://example.com {{deadlink}}</ref> be ignored in this mass removal? Meaning that the {{Cleanup bare URLs}} tag would be removed in those cases.

Headbomb {t · c · p · b} 01:04, 16 August 2022 (UTC)

Discussion (mass removal of Cleanup bare URLs)

  1. It would be highly preferable to do this by bot IMO. I don't have any real objection to having this done semi-automatically, but in all cases the removal should only be done when all bare URLs have been taken care off. Headbomb {t · c · p · b} 01:15, 16 August 2022 (UTC)
(edit conflict × 3)
  1. I have, in one case (List of Polish mathematicians), seen {{cleanup bare URLs}} from an article that did in fact contain bare URLs. But some sort of automated process should do this anyway, since (a) bare URLs are often filled in using bots/scripts (b) confirming an article does in fact contain bare URLs is tedious work when done manually. (c) I'm not seeing any real harm this bot task causes. I don't really care whether this is a bot or a meatbot.
  2. Yes at least in the case of {{dead link}}, as the dead link tag effectively supersedes the bare URL tag since as one cannot fill in a dead link any further. For other maintenance tags such as {{user-generated source}}, the case is less clear, and I have no strong position.
* Pppery * it has begun... 01:17, 16 August 2022 (UTC)
as the dead link tag effectively supersedes the bare URL tag since as one cannot fill in a dead link any further You can certainly fill dead links further. I do so routinely. For example
can be fixed to
This also would apply to non-dead links like
Headbomb {t · c · p · b} 01:23, 16 August 2022 (UTC)
This is absurdist nonsense:
  1. A dead link cannot be filled. How hard is that to understand?
  2. A dead link may be rescued by a link to an archive. If that archive link is bare, the ref can be filled ... but until and until it is rescued, it cannot be filled.
  3. For the love of al that is highly, what on earth is the pint of retaining at the top of an article a big banner asking editors to fill a ref to a URL which has already been identified as unreliable source?
Why is my work being disrupted by such utter folly? BrownHairedGirl (talk) • (contribs) 01:34, 16 August 2022 (UTC)
A dead link cannot be filled.
See above for how it can be filled. See also below for why bots cannot assume that links tagged by maintenance tags need to be removed. Headbomb {t · c · p · b} 08:04, 16 August 2022 (UTC)
Yet again, @Headbomb, your stubbornness blinds you the details. So you are wrong, and yet again you are doubling down on your wrongness.
Those details have already been explained to you, but I will repeat:
  1. A dead link bare URL ref cannot be filled, because no info is available with which to fill it
  2. If an archived copy is found, that archived copy is not dead and cannot be filled.
So, the response to a dead link bare URL is to try to find that archived copy. Unless and until that archived copy is found, it is pointless asking editors to fill the ref. The {{Dead link}} tag is sufficient. BrownHairedGirl (talk) • (contribs) 11:13, 16 August 2022 (UTC)
A dead link bare URL ref cannot be filled, because no info is available with which to fill it
Which is demonstrably wrong, as evidenced above. Headbomb {t · c · p · b} 12:01, 16 August 2022 (UTC)
No, @Headbomb. I am right, and you are wrong again
This is very very simple.
A dead link cannot be filled.
An archived copy of a dead link can be filled.
You are unable or unwilling to understand that crucial distinction, and your stubbornness is turning into disruptive timewastasting. BrownHairedGirl (talk) • (contribs) 12:20, 16 August 2022 (UTC)
It can sometimes be filled, but it's a two-stage process. Sometimes organisations will restructure their website so that all the old links either take you to the website's main page, to a generic landing page, or fail entirely. Stage 1 is to identify where the page has gone to; as an example, consider http://curvebank.calstatela.edu/newmath/newmath.htm - clicking that link actually takes you to http://web.calstatela.edu/curvebank/ - a landing page. Acting on the advice there, and using the search facility at nationalcurvebank.org, yields http://old.nationalcurvebank.org/newmath/newmath.htm with which I was able to make this edit. If that dead URL had been inside ref tags, stage 2 would have been to fill it in with title, author, date etc. --Redrose64 🌹 (talk) 14:32, 16 August 2022 (UTC)
  • Speedy close this blatantly bad faith RFC. This is a deliberately disruptive exercise, opened as revenge for the fact that I explained above to Headbomb how his objection to removal had no support, and how his aggressively process-abusing closure of WP:BHGbot 9 had not prevented me from removing redundant banners from over ten thousand articles over the last 8 months, without a single objection from anyone. --BrownHairedGirl (talk) • (contribs) 01:23, 16 August 2022 (UTC)
    Same as above. Headbomb {t · c · p · b} 01:27, 16 August 2022 (UTC)
    @Headbomb: your bad faith is as plain as a very plain thing.
    This is just an exercise in wasting my time, motivated by revenge. BrownHairedGirl (talk) • (contribs) 01:29, 16 August 2022 (UTC)
  • Note that I suggested to Headbomb that they open an RFC on the substantive issue in his dispute with me: "Should we retain at the top of an article a big banner about filling bare URL refs which have already been tagged as unsuitable, and which should therefore be replaced or removed".
    Sadly, Headbomb has chosen not to ask this question, and also makes no attempt to explain tye reasominh for his demand that editors should be faced with a big banner asking them to fill a bare URL ref which actually be removed or replaced.
    This reminds me of the Kerryman joke about the Kerryman who wrote a book which was so bad that the publisher rewrote it before binning it. Except that in this case, Headbomb is not joking: he genuinely wants editors to waste their time filling refs to unreliable sources ... which will then be removed.
    Why on earth would anyone demand that? --BrownHairedGirl (talk) • (contribs) 01:52, 16 August 2022 (UTC)
    Because bots are dumb, and cannot determine if a source is reliable or not, nor if it should be removed or not. This is something that requires human review. If there are bare URLs remaining, the bare URL tag should remain. That's a rather simple thing to understand. Headbomb {t · c · p · b} 02:44, 16 August 2022 (UTC)
    @Headbomb: it seems that not only bots are dumb.
    Bots do not determine whether a source is reliable or not. Those tags are added manually by humans.
    My approach to those tags is to respect the judgement made by those human editors. The Headbomb approach is to disregard those judgements, and to ask human editors to devote some of their limited time on this earth to filling a ref which another human has assessed as unreliable, and to fill the ref even if they agree that it is unreliable. That is a spectacularly dumb stance, and it is a sad reflection of BAG's tendency to herd-like groupthink that several other BAG members supported this spectacularly dumb stance. BrownHairedGirl (talk) • (contribs) 03:09, 16 August 2022 (UTC)
    "Those tags are added manually by humans." And humans can be wrong for a plethora of reason. Some random person can add, in good faith, [unreliable source?] to anything. That doesn't make the source reliable, or even improperly cited. Bots cannot determine that context, and cannot assume that just because there is some sort of maintenance tag, that the correct outcome is the removal of the source. Headbomb {t · c · p · b} 08:00, 16 August 2022 (UTC)
    Again, @Headbomb, your binary logic and refusal to listen blinds you to the simple explanations offered by an editor who has worked on this stuff every day for a year.
    Consider these two examples:
    1. Article1 has one bare ref: a ref to a flaky blog tagged as unreliable.
      My AWB job removes the {{Cleanup bare URLs}} banner, correctly
    2. Article1 has one bare ref: a ref to a highly-cited academic journal which some IP vandal has tagged as unreliable.
      My AWB job removes the {{Cleanup bare URLs}} banner, correctly.
      However, when someone else spots the bogus tag and remove the unreliable tag, my other job will add the banner back again.
    So there is no need to retain the banner just on the outside chance that a ref has been wrongly tagged.
    Note too, that you have contradicted yourself. Here you say that Bots cannot determine that context ... but up above, you wrote Feedback has been provided on how a future bot request could be modified to address the concerns and gain approval.
    You are facing both ways, and the only consistency in your antics is your transparent determination to impede my work. BrownHairedGirl (talk) • (contribs) 11:08, 16 August 2022 (UTC)
    In both cases the removals are inappropriate because bare URLs remain. It really is that simple. Headbomb {t · c · p · b} 12:02, 16 August 2022 (UTC)
    Again, @Headbomb, after 8 months you still stubbornly refuse to acknowledge the core purpose of {{Cleanup bare URLs}} banner.
    It is not some sort of linnean classification system.
    It is a request to editors to fill one or more bare URL refs.
    And I repeat: it is absurd to ask editors to fill a ref which has been identified as being unsuitable, an which should be removed or replaced.
    Your conduct is like the dumb as a brick tag which you rudely applied to my code in BhGbot9: you completely refuse to grasp the simple point that the purpose {{Cleanup Bare URLs}} is to ask editors to fill a ref. What is so hard to understand? BrownHairedGirl (talk) • (contribs) 12:28, 16 August 2022 (UTC)
  1. Yes, absolutely. I find +13K articles with the tag without bare url refs. Not sure what reliability has to do with it.
  2. No, leave them, and let editors remove them manually, along with the dead refs.
Guarapiranga  07:59, 16 August 2022 (UTC)
@Guarapiranga: your number of 13k+ is utter nonsense.
You got that nonsense number because your search is broken: it wrongly assumes that bare URLs (and only bare URLs) are wrapped in square brackets, e.g. [http://example.com/foo].
Neither assumption is true: almost zero bare URL refs use square brackets; and most refs which do use square brackets are filled, e.g. [http://examplew.com/balagan Balagan Today]
See e.g. the first article in your search results: Manchester Airport, which has three inline-tagged bare URLs.
Before you make snarky comments about reliability, please check your own data. BrownHairedGirl (talk) • (contribs) 10:54, 16 August 2022 (UTC)
  1. No need to be wp:uncivil, BrownHairedGirl. I didn't mean to be snarky; I genuinely did not understand what reliability has to do with any of this. It seems to me a completely separate issue; there are perfectly formatted refs that are unreliable, and bare url refs that are at the top of wp:reliability.
  2. You're right; correcting the search to exclude articles with refs without braces (instead of refs with brackets), yields 455 tagged articles without bare url refs.
  — Guarapiranga  02:52, 18 August 2022 (UTC)
@Guarapiranga: your comment about reliability was in a sentence about numbers, so I read it as being about the reliability of the numbers. Please do not call me uncivil for responding to what you actually wrote, instead of whatever you actualy meant.
Your revised search is still broken, because it is far too simplistic.
For examples, your search will not recognise inline tagged bare URLs : <ref>http:/foobar.com/foo {{Bare URL inline|date=June 2022}}.
There are articles with multiple inline-tagged bare URLs, and a {{Cleanup bare URLs}} banner. I don;t remove the banner unless the total number of bare tagged URLs is less than three.
For a year now, I have been working every day with regexes to identify bare URLs. It's a bit wearing to find someone coming to a discussion like this and repeatedly posting as fact nonsense data which they clearly have not even tested. BrownHairedGirl (talk) • (contribs) 03:22, 18 August 2022 (UTC)
  • Speedily close per BHG and others. Rlink2 (talk) 22:58, 16 August 2022 (UTC)
  • Leave no reason to remove, unless the problem has been fixed, which should be done by the person doing the fix. As per other tags which remain in place until the problem is deamed fixed. Keith D (talk) 17:32, 17 August 2022 (UTC)
    @Keith D: the fixes may be done manually, or by a tool, or by a bot such as @Citation bot.
    For example,
    • an editor may fill the ref manually, or may use a tool such as WP:ReFill or WP:Reflinks
    • the ref may be filled by Citation bot
    • the ref may be tagged as a {{dead link}} (and hence unfillable)
    • the ref may be tagged with {{Bare URL inline}} by my regular AWB job User:BrownHairedGirl/No-reflinks_websites, making the banner redundant in some cases
    • the ref may be converted by InternetArchiveBot to the "Archived copy" format using {{cite web}}, and hence be no longer bare. (Those cases are automatically tracked in Category:CS1 maint: archived copy as title; we don't need the banner as well)
    • the ref may be tagged with of the many inline tags which mark it as unsuitable: unreliable, nonspecific, user-generated, self-published, circular ref, primary source etc. In such cases, the banner is no longer needed, because the remedy with those refs is not to fil them: it is to remove or replace them.
    Note that only the first of those six scenarios necessarily involves an actual human, and humans do not always know when to remove a banner. See e.g. User talk:BrownHairedGirl#Michael,_Row_the_Boat_Ashore (permalink), where an editor does a great job of filling cite templates, but doesn't know whether to remove the banner, and misses one bare URL.
    So if we leave it to humans to remove the banners, we will retain a lot of un-needed banners, and have some inappropriate removals. In the last 8 months, I have used my AWB Custom Module to remove well over 10,000 redundant {{Cleanup bare URLs}} banners, without a single objection from anyone at all. This semi-automated removal is working. BrownHairedGirl (talk) • (contribs) 18:32, 17 August 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Moving the template to the references section

This worthy suggestion has all but drowned in all the discussion (and sniping) going on above.

EEng was one editor suggesting it, BrownedHairGirl opposed it. Then discussion veered elsewhere.

Lets get back on track: I agree tucking the banner away from the article header is a really good thing, and placing it in the references section is as good as any suggestion. CapnZapp (talk) 17:40, 16 August 2022 (UTC)

It's not, because the bare links could be anywhere in the article: references, external links, body of the article, footnotes, bibliography section, etc... The only sure way to have it apply correctly is to have it at the top. Headbomb {t · c · p · b} 00:27, 17 August 2022 (UTC)
In some of the cases under discussion (bare URLs tagged with some additional cleanup template) we have a big problem (say, "user generated source" or "dead link") that is shown only with a tiny inline template while the comparatively small "bare URL" problem gets extra attention by a top-of-the-article banner. This seems a bit backwards. —Kusma (talk) 09:59, 19 August 2022 (UTC)
@Kusma, I agree that it's not ideal.
Ideally, all bare URLs would be inline-tagged, and the {{Cleanup bare URLs}} banner would be used only when there are multiple bare URLs on the page (e.g. more than 4). However, inline-tagging all bare URLs impedes filing them, because WP:Reflinks does not support {{Bare URL inline}}. For a longer explanation, see above, in the replies to Barkeep49's post timestamped "13:36, 18 August 2022 (UTC)".
That's why for the past 13 months of working full-time on bare URLs, I refrained from indiscriminate tagging with {{Bare URL inline}} (after an initial error at the end of June 2021),. I began mass-tagging with the {{Cleanup bare URLs}} banner only when the cleanup entered the mopping-up phase earlier this month, as we reached the limits of what Citation bot can do and need more manual input. BrownHairedGirl (talk) • (contribs) 18:06, 20 August 2022 (UTC)

I think it should stay at the head of the article, where it is more likely to provoke action on clearing the problem. - Donald Albury 18:12, 16 August 2022 (UTC)

How about we just put this energy into fixing the URLs, rendering the tag obsolete? BD2412 T 23:05, 16 August 2022 (UTC)
A) This logic could be used to stick every issue ever as a cleanup issue on top of the article. Yet we don't highlight many similar maintenance tasks and instead track them in-line, or with maintenance categories, or with talk page notifications. There needs to be an affirmative case for how sticking this on top helps compared to the other options - that it's really attracting random passerby to fix the issues. B) BD2412, even in the unlikely scenario of fixing all of the bare URLs on Wikipedia, new ones will get added. So this is an on-going policy concern as to how to handle this kind of a problem. C) As I've mentioned before, even if we grant for a moment bare URLs are catastrophic (I don't), cleanup templates on top of a page are generally reader focused, not editor focused. And bare URLs aren't really a concern for readers. ("Bad sourcing" tags might be, but that's a separate issue, and such cleanup templates already exist.) This template has been added to the top of perfectly valid, well-sourced articles that happen to have a single bare URL in them somewhere. Now, if an editor fixes that, great, but if no such fix happens, why are we marking the article as a whole unreliable to readers? SnowFire (talk) 05:35, 17 August 2022 (UTC)
Thumbs up icon CapnZapp (talk) 12:17, 17 August 2022 (UTC)
@SnowFire, I am still horrified that you place such a low priority on good citations. This is an encyclopedia, not a collective blog, and good quality references are the absolute core of why were are here.
There are two parts to that concept of "good quality references":
  1. that the source itself should be of a high-quality: reliable, scholarly, and supporting the assertions in the articles.
  2. that the citation should identify that source in a clear and informative and consistent way, in accordance with the citation style in use.
A bare URL ref may meet the first criterion, but if it fails the second test, or clear presentation, then it is much harder for a reader to assess whether it meets the first criterion, i.e. of being a suitable source.
So I am horrified that you say bare URLs aren't really a concern for readers. The reality is entirely the opposite: references are the way by which our readers can verify what we publish, and bare URLs make it harder for them to do that. BrownHairedGirl (talk) • (contribs) 16:42, 17 August 2022 (UTC)
@SnowFire: Two of the issues you raise are technical points, which I reckon are better separated from the issues of principle.
The first is your assertion that we don't highlight many similar maintenance tasks and instead track them in-line. In principle, I partly agree: where possible, single instances should be tagged inline. However, there is a technical problem with that: WP:REFLINKS does not support the {{Bare URL inline}}, and it is in my experience the best tool (or rather the east worst) for filling bare URLs. A I discovered painfully at the end of June 2021, mass adding {{Bare URL inline}} has the undesired effect of being a barrier to actually filling the refs. Yes, ideally the tool would be fixed; but it is unmaintained.
So that is why I apply the inline tags only to refs which I know that RefLinks cannot fill: see User:BrownHairedGirl/No-reflinks_websites. For the other refs, banners are all that is available.
If WP:Reflinks supported inline tags, then I would add the banner only to articles with three or more bare URLs. But I see no chance of an upgrade for Reflinks. BrownHairedGirl (talk) • (contribs) 17:00, 17 August 2022 (UTC)
@SnowFire: another separate reply, for ease of threaded discussion.
You write: even in the unlikely scenario of fixing all of the bare URLs on Wikipedia, new ones will get added. So this is an on-going policy concern as to how to handle this kind of a problem.
So what would that scenario look like? Actually, after 13 months of work on this, I have already collected and published good data sets which allow me to describe quite accurately what that situation would look like.
  • new bare URLs are added every day to an average of about 300 articles. (the daily number can fluctuate wildly, and there are some glitches in the counting, but 300/day is a fairly stable long-term average) I call these "Articles With Bare URLs" (ABURs), so we are looking at about 9,000 "New ABURs" per month.
  • About 20% of those New ABUR have all their bare URLs filled with in a week or so by normal editing processes.
  • Currently, I am using various methods to track New ABURs on a daily basis, and filing about 30% of them using @Citation bot. That is labour-intensive work, and I am won't be able to sustain it for long.
  • The remaining 50% (and the 30% currently tackled on a daily basis, whenever I stop doing that) are picked up in my scans of the twice-monthly WP:Database downloads.
    Those new ABURs from each database dump are repeatedly-processed by me through Citation bot until progress stalls. This has all been documented publicly for 9 months, in the hundreds of revisions of User:BrownHairedGirl/Articles with new bare URL refs. See for example the results from July, which left only 1,069 new ABURs (excluding any which are inline-tagged):
    1. 8 passes of the New ABURs from the 20220801 database dump: 2,675 new ABURs, 443 remaining.
    2. 7 passes of the New ABURs from the 20220720 database dump: 2,671 new ABURs, 626 remaining.
  • While writing this post, I just re-scanned those 1,069 new ABURs from July, and found that only 677 of those 1,069 New ABURs still have untagged bare URLs.
However, @AManWithNoPlan's diligent development work on Citation bot has just in the last few days increased the bot's cleanup rate. I will feed these remaining 677 New ABURs from July to the bot, and report back on the results. BrownHairedGirl (talk) • (contribs) 17:50, 17 August 2022 (UTC)
BHG, you would likely not experience so much blow-back had you not come across as ultimately uncompromising. What made you start this crusade against bare URLs I will never know. At the very least, please consider all the voices telling you you're making a mountain of a molehill - might it be that your stance is not the only reasonable to take? Why not take a moment to ask yourself WHY you are horrified when so many of your fellow editors aren't? CapnZapp (talk) 18:46, 17 August 2022 (UTC)
@CapnZapp: I do indeed believe your assertion that what made you start this crusade against bare URLs I will never know. In this and in two other venues, you have made it abundantly clear (at great length) that you have no interest in or understanding of the importance of referencing techniques, and that you are actively hostile to efforts to improve refs.
Luckily, most editors do not support your disdain for good citations, and you wholly misrepresent the discussion: you are in fact the only editor here to make a stand in favour of bare URLs. Otherwise the disagreement is imply about how and where to tag the remaining bare URLs after over 90% of them have been resolved.
There seems no possibility that you will desist from opposing good referencing, but other editors can find plenty of established guidance on why it matters: see e.g. WP:HOWTOCITE and WP:Bare URLs. BrownHairedGirl (talk) • (contribs) 19:04, 17 August 2022 (UTC)
You believe yourself a good neutral cool-headed editor, but in reality you are trying to crush your way through. If you were cool and levelheaded you'd realize this is blown out of all proportions, just look at this page! It's a full on wikipedia war, and YOU are the instigator. Please stop and reconsider your relentless barrage. You're in full-on defensive move where nothing anyone tells you gets through. If you only could realize everybody likes your actual work, just not the way you insist on billboarding your every move. If you could just drop the idea every single bare URL must be announced to the world as if somehow it turns its article into shit. Articles with bare URLs are fine, just not perfect. There is zero reason to suggest otherwise to readers. CapnZapp (talk) 21:15, 17 August 2022 (UTC)
@CapnZapp: nobody else on this page agrees with your view that Articles with bare URLs are fine. Nobody.
So I will go back to ignoring you and your nasty personalised commentary, and your bogus allegations of "war". BrownHairedGirl (talk) • (contribs) 21:22, 17 August 2022 (UTC)
You take everything personal, @BrownHairedGirl. Didn't you see me writing everybody considers your work valuable - the point of contention is instead making it so damn visible! You might ignore me (because I was one of the first editors to object to your "overly visible" approach?), but editors whose opinions I hope you consider valid have all objected to the way you lash yourself at the mast combining A) valuable cleanup work and B) broadcasting this to the world. Do you also ignore @EEng, @SnowFire, @Pppery and possibly more level-headed editors? Why not stop to listen? Everytime somebody says "topside banners are too much for this issue" you deflect by the nonconstructive "I'm personally attacked", and sure, behavior like Moxy's doesn't help. Why not entertain the thought you would gain much more praise for your efforts if you showed some compromise on the topside banner issue? You blowing your top each time somebody disagrees with you overshadows your contribution! If you only could accept someone like me has no beef with A) even though we think B) is much too much! CapnZapp (talk) 09:11, 18 August 2022 (UTC)
What evidence do you have that BrownHairedGirl is ignoring me? * Pppery * it has begun... 14:03, 18 August 2022 (UTC)
Also, note that far from ignoring @EEng and @SnowFire, I have replied at length to all of them. BrownHairedGirl (talk) • (contribs) 14:13, 18 August 2022 (UTC)
  • As a Twinkle programmer, I'd be inclined to keep all maintenance tags together at the top. This is easier programatically, and also allows the use of the {{Multiple issues}} template. It also follows the principle of least astonishment, since almost every other full article maintenance tag goes there. The only exceptions are {{Uncategorized}} and {{Improve categories}}, which go second from the bottom. Those two exceptions have been a pain and required an RFC over at MOS:ORDER to sort out. The lesson I learned from that is that when we have a standard place for things, it is usually best to use the standard place, rather than making a bunch of exceptions. Just my two cents though, don't take it too seriously :) –Novem Linguae (talk) 05:57, 17 August 2022 (UTC)
  • I suggested keeping it up top, but only to editors, not to readers. This, in fact, could be applied to various notifications (not all, but some, or even many). Is that possible? I tried finding a template or trick to identify whether the user was logged in or not, but failed. I'm sure someone smarter (or more tech savvy) than me has a way. — Guarapiranga  04:55, 18 August 2022 (UTC)
    Everyone is an editor even when not logged in. Only blocked IPs or other special situations can not edit. I'm not aware of a way to communicate the log-in status to a template, never seen that. User-specific info is usually guarded for privacy reasons. -- GreenC 05:11, 18 August 2022 (UTC)
    I don't think it'd be practical. I think you'd have to place two templates per page. I also don't see a getUsername() or mw.config.get('wgUserName') or isLoggedIn() function in Lua, but perhaps I am missing it. It would probably be on this page somewhere. –Novem Linguae (talk) 07:19, 18 August 2022 (UTC)
    I can confirm that no way of branching based on username in Lua exists, although you can use the user-show CSS class to only show content to logged in users. * Pppery * it has begun... 14:03, 18 August 2022 (UTC)
  • I am for banner up top. It's cleaner and more likely to work. Banners in-article are sometimes useful ie. <bannername-section> but I think they carry a higher interference factor. Also when you go down the road of mid-article it could go in the ref section, the section it's located, the external link section etc.. and programming and tracking and maintaining that is difficult. -- GreenC 05:06, 18 August 2022 (UTC)
  • Keep at top as per above. This seems like the both visually, spatially and logically cleanest option. And I think it's best we try to see our way through to winding down this rather needlessly contentious discussion.--🌈WaltCip-(talk) 11:45, 18 August 2022 (UTC)
  • I am of the mind that maintenance banners at the top of the page should serve our readers, while Wikimedia editors can have other ways of learning about issues. Our readers should know that the article has unreliable information, needs proofreading, and the like. I think there is a case, but a much weaker one than the examples I gave, that our readers need to know about bareurls. Perhaps this should be converted to an in-line use like Template:According to whom where the tag is attached next to the bareurl that needs fixing so that the reader understand exactly what information is at risk and needs fixing (as do editors who need to fix it). Best, Barkeep49 (talk) 13:36, 18 August 2022 (UTC)
    {{bare URL inline}} already exists, and BrownHairedGirl mentioned why she didn't use it earlier in this section: WP:REFLINKS does not support the {{Bare URL inline}}, and it is in my experience the best tool (or rather the east worst) for filling bare URLs. A I discovered painfully at the end of June 2021, mass adding {{Bare URL inline}} has the undesired effect of being a barrier to actually filling the refs. Yes, ideally the tool would be fixed; but it is unmaintained * Pppery * it has begun... 14:03, 18 August 2022 (UTC)
    Thanks for re-posting that, @Pppery.
    @Barkeep49: I agree that inline tagging is usually preferable, but flawed tools mean that in this case its use has to be restricted. I use {{Bare URL inline}} where I can. It currently has 10,790 transclusions. Nearly all of those have been added by me: mostly by my big and regular AWB job User:BrownHairedGirl/No-reflinks websites, and most of the rest by a javascript which I run on individual pages if WP:Reflinks fails to fill all the bare URLs. I put in many dozens of hours of work making these tools, to maximise use of {{Bare URL inline}} without impeding WP:Reflinks.
    In addition to {{Bare URL inline}}, there are several other inline templates for bare URLs devoted to various types of non-HTML content: {{Bare URL PDF}}, {{Bare URL image}}, {{Bare URL DOC}}, {{Bare URL spreadsheet}}, {{Bare URL plain text}}, and {{Bare URL AV media}}.
    {{Bare URL PDF}} was created by the wonderful @Rlink2; the others were created by me. In all cases, nearly all uses of the inline tags were added were by me, mostly from lists made by scanning the WP:Database dumps, and from some Perls scripts which I wrote to check HTTP content types for each of what were then about 400K unique bare URLs.
    The reason for having these specific tags is that a) no tools can fill bare URLs to non-HTML content, so using a different tag prevents @Citation bot etc from wasting time on them; b) some of them may be best be filled with specific types of cite template, and differentiating them by content type helps any editor who wants a batch of e.g. video files.
    Between them, these 6 inline templates for non-HTML content are used on a total of 40,198 pages (see https://petscan.wmflabs.org/?psid=22666654). That is about 45% of all the remaining articles with bare URLs.
    The overwhelming bulk of these non-HTML inline tags are {{Bare URL PDF}}, which has 29523 transclusions.
    In all, 51,704 articles have an inline bare URL tag: see https://petscan.wmflabs.org/?psid=22666660. That's about 55% of all remaining articles with bare URLs.
    I don't add the {{Cleanup bare URLs}} banner to articles where all the bare URLs are tagged, unless there are at least 5 bare URLs on the page.
    Hope this helps. BrownHairedGirl (talk) • (contribs) 14:46, 18 August 2022 (UTC)
    This is all logical. But there are a lot of judgements of values - including why for Twinkle reasons putting it in references are hard- leading to decisions in that analysis. I'm not sure I share all of those judgements, but also I'm not sure that I don't. I am sure that I don't like the idea of putting editor useful, rather than reader and editor, useful banenrs at the top of the page. If the judgements above are correct - and here I'm going to reiterate I haven't thought about this deeply enough to have an opinion either way other than they're reasonable judgements - then that could be enough to be an exception to the rule for me. But that's a very conditional statement. Best, Barkeep49 (talk) 16:42, 18 August 2022 (UTC)
    Thanks for that thoughtful reply, @Barkeep49.
    I don't agree that this is just editor-useful. Readers who check refs will find it helpful to be warned that this this page includes unhelpfully-styled refs.
    Personally, I find the dates on cleanup banners esp useful when reading. A banner which has remained there for long is a good indicator that the article is neglected.
    And philosophically, I strongly favour placing cleanup banners in a prominent position. Where a work-in-progress has unresolved issues, I favour being upfront about those issues. BrownHairedGirl (talk) • (contribs) 16:54, 18 August 2022 (UTC)
    @Pppery pointed out that there is a user-show class that can allow us to easily hide templates from readers and not editors. Perhaps a discussion should be started somewhere about applying this class to certain maintenance tags. If consensus develops, it'd be super easy to add. Just need to confirm that there is a consensus, and pick our maintenance tags. –Novem Linguae (talk) 19:59, 18 August 2022 (UTC)
    @Novem Linguae, I think that would be a great idea for certain templates. I'd consider Template:Uncategorized, Template:Infobox requested, and maybe instances of Template:Cleanup that don't have a |reason= parameter as potential candidates. These are problems that logged-out editors are not necessarily likely to be able to solve. WhatamIdoing (talk) 21:27, 18 August 2022 (UTC)
Readers who check refs will find it helpful to be warned that this this page includes unhelpfully-styled refs. And you have pretty much by yourself, User:BrownHairedGirl, decided that bare URLs are so particularly bad that readers must be "warned", ignoring the many voices asking you dial back on this approach, meeting every criticism by either very aggressive defensive comments (taking everything extremely personal; goading talk discussions to blow out of proportion, which I not deflect from the core issue of whether to keep allowing you these topside banners), or complete silence, not giving a single inch in considering alternatives. Again, where is the discussion where the community concluded bare URLs are so bad a topside banner is required, and you were asked to perform this invasive and unpopular measure on behalf of the community consensus? Nowhere, it seems. Why are you given the leeway to basically rewrite the Bare URL policy single-handedly, without discussion, from a position of quiet acceptance (which can be interpreted in a lot of ways, from "technically disapproving" to "unstated encouragement") to aggressive discouragement, which likely will lead to a drop in engagement from casuals who will see their references get shamed up top? Sigh. CapnZapp (talk) 17:42, 23 August 2022 (UTC)
Why would casuals who [...] see their references get shamed up top be inclined to disengage? It to me like that a more likely response if someone points out a problem with one's behavior is to do one's best to fix the problem. My fifth edit (when I was clearly still a casual, almost two years before I created my account) was to remove an inapplicable maintenance tag from an article, so I see nothing discouraging about the process. * Pppery * it has begun... 17:58, 23 August 2022 (UTC)
CapnZapp's choice to radically misrepresent the balance and tone of the discussion is one of the reasons I have been ignoring him. No viable alternatives have been proposed, excerpt possibly placing the banner in the refs section, which has some support but far from consensus.
Most exchanges have been friendly, apart from those with two editors: the editor who opened this discussion with pejorative terminology and lack of notification, and proceeded to lie repeatedly; and the BAG member who resumed his shameful campaign of disruption.
Other reasons include Zapp's choice yet again to engage in blatant assumption of bad faith by misrepresenting a "Cleanup this article" banner as an attempt to shame individual editors. Zapp has repeated that disgraceful ABF at three venues now, and I have had enough of it. BrownHairedGirl (talk) • (contribs) 18:07, 23 August 2022 (UTC)
Some editors do experience maintenance banners as a badge of shame. Some editors do get discouraged and give up. It's a big world. Each month, we have more than 100,000 registered editors. To give you an idea of what that means, we probably have at least 300 registered editors each month who are dealing with severe anxiety (and thousands with milder versions). More than 1000 who are on the autism spectrum. More than 4000 who speak at least four languages, with English probably not being the strongest. It would be extraordinary indeed if, out of this diverse and sometimes struggling group of humans, nobody reacted negatively to an official-looking complaint about their work.
Few editors are as confident as Pppery and willingly remove outdated or incorrect banners, even when they know that the problem has definitely been fixed. That's why we decided to add explicit requests for people to do this to so many of the maintenance banners (coincidentally, in the same month that Pppery started editing). Getting outdated banners off pages is still a problem.
I'd like to push back on the idea that maintenance banners exist to "warn the reader". That's not the point (except possibly for {{hoax}}). They exist primarily to tell people how they can help. A maintenance banner should be considered successful to the extent that it gets the problem solved, not to the extent that it accurately describes a flaw in an article. WhatamIdoing (talk) 05:19, 24 August 2022 (UTC)
Thanks, @WhatamIdoing.
That issue of outdated banners on pages is indeed a problem, which is precisely why I proposed WP:BHGbot 9, and why I was so frustrated that it was so aggressively and rudely declined by Headbomb.
I agree with your comment that A maintenance banner should be considered successful to the extent that it gets the problem solved. (There is a secondary function of warning readers, but that's secondary). That primary purpose of solving the problem is why I object to Headbomb's bizarre view that a maintenance banner should be retained even when the primary problem with a bare URL is something other than bareness: e.g. that the link is already tagged as dead or as unreliable or as nonspecific: in such case the banner does not assist editors to identify and fix the primary problem. Sadly, Headbomb stubbornly insists that purpose is to tag bare URLs, rather than to assist fixes.
Thankfully, WP:NOTBURO is policy. So despite BAG's disgracefully perverse groupthink endorsement of Headbomb's bullying antics and shameless disregard of WP:CLEANUPTAG. I have been removing these redundant banners almost daily for about 8 months, without a bot flag. (I estimate over 10,000 removals in all; yesterday alone, I removed ~280 of them). In that time there has been not a single objection from anyone, apart from Headbomb's objections here, and I note that nobody on this page has endorsed Headbomb's disruptive stance. Yes, I would prefer that his job was done with a bot flag; but since that is not gonna happen until BAG becomes less dysfunctional, it is better that his job wis done without a bot flag than not done at all.
I take your point that those who live with anxiety may feel challenged by cleanup tags and banners. They may also feel uncomfortable with processes such as WP:AFC, WP:AFD and WP:PROD. However, these are all necessary (and often vital) parts of collaboratively building an encyclopedia. That's why we need to stress that these processes are our quality control system: their purpose is to help improve Wikipedia, and they are not to intended to disparage or shame anyone. Of course, we should always review these processes to see how they can be made less daunting ... but I think the bottom line is that these quality control processes are essential, and that however much we take are not to bite, sadly some people may not find this form of collaborative working to be part of their comfort zone. BrownHairedGirl (talk) • (contribs) 11:38, 24 August 2022 (UTC)
The maintenance templates are a badge of shame, and they bar an article from DYK, ITN, GAN, FAC and TFA. The bare URL (and the other citation improvement) templates are used to prompt change. So when one appears on my watchlist, as has happened recently, I immediately move to rectify the situation and remove the template. But at least they have clear criteria. Most of the other cleanup templates though, have no criteria, and are placed purely in order to make a WP:POINT, to disrupt the work on the article, or halt it completely. They are not used to initiate discussion, only to block it. I'm talking about templates like Template:Too long, Template:Overly detailed, Template:Summary style, Template:NPOV language, Template:Tone, Template:Term paper etc. These have no meaning whatsoever except through discussion and consensus. Most of the time they are placed without prior discussion or with any intention to engage in one. Often they are placed by editors who disagree with the consensus reached on the talk page. I will remove any that I come across where there is no ongoing discussion. These templates should be deleted; discussions should occur on the talk pages, not the article pages. Hawkeye7 (discuss) 23:03, 24 August 2022 (UTC)
How on earth does any cleanup template block discussion? BrownHairedGirl (talk) • (contribs) 02:38, 25 August 2022 (UTC)
Many editors treat the placement of a cleanup template as final, and are discouraged from doing further work. Usually they are placed by an editor who believes that their personal opinion suffices to place a maintenance template. If no discussion has been initiated (or it has been placed in defiance of the outcome of the discussion), the assumption is that the editor who placed it is not willing to engage. Hawkeye7 (discuss) 00:53, 26 August 2022 (UTC)
Hawkeye, so no, you do not actually believe your own assertion that a cleanup banner blocks discussion.
If an editor chooses to treat the placement of a cleanup template as final, that is their choice.
Wikipedia is a collaborative exercise, which necessarily involves working with others to fix quality issues and to resolve disagreements. If an editor is unwilling or unable to fix problems or to engage in discussion, that is a personal issue for them which limits their ability to collaborate.
In many cases the problem noted in the banner requires no explanation. But if an editor adds a banner which requires further explanation, but doesn't supply that explanation, the solution is simply to ask them to explain, and remove the banner if they don't reply.
However, bare URLs is a fairly clearcut issue, so I don't see what your points have to do with this discussion. BrownHairedGirl (talk) • (contribs) 02:19, 26 August 2022 (UTC)

Examples of addition and removal of the Cleanup bare URLs banner

For transparency, here are my most recent contribs lists for addition and removal of the {{Cleanup bare URLs}} banner.

Both examples are from today, after using WP:AWB in pre-parse mode to scan some huge lists.

  • Addition of the {{Cleanup bare URLs}} banner to 966 "List of foo" articles. The set had been processed by @Citation bot 7 times in the last 3 days. After that was done, I added the {{Cleanup bare URLs}} banner to the articles in the list which still have untagged bare URLs.
  • Removal of redundant {{Cleanup bare URLs}} banners this morning from 241 articles, after an overnight scan of the ~18,000 articles which transclude the banner. Note that in each case, the edit summary explains why the banner was removed: no bare URLs, or all bare URLs inline-tagged.

Hope this helps. --BrownHairedGirl (talk) • (contribs) 15:03, 18 August 2022 (UTC)

Evidently not, since [7] removed {{Cleanup bare URLs}}, despite two bare URLs remaining. One tagged as a dead link, the other as user-generated source. This fixed the bare URLs and should have been done before removing the tag. This is why your script/bot needs adjustment. Headbomb {t · c · p · b} 21:09, 18 August 2022 (UTC)
Yes, it's clear you and BrownHairedGirl disagree on the matter. Both of you seem to be commenting in nearly every section to restate the same disagreement, which is not helpful. * Pppery * it has begun... 21:23, 18 August 2022 (UTC)
Compare the lengths and number the comments, and you'll see this is a false balance situation. I got one or two comments per section at most (save for the RFC). BHG has like zillions. Headbomb {t · c · p · b} 21:35, 18 August 2022 (UTC)
For goodness sake, man. It is MY work which is being discussed. BrownHairedGirl (talk) • (contribs) 22:12, 18 August 2022 (UTC)
Sigh. As I have explained to @Headbomb a zillion times, this is exactly what my tool is designed to do.
  1. A dead link cannot be filled. The required action is try to rescue it, and if it is rescued, the archived copy may be filed. But that relies on other tools and other work flows
  2. The user-generated source should have been replaced with an independent reliable source. You took the wrong action, Headbomb.
Give it a rest, Headbomb. You are not doing any of this work, and are simply trying to disrupt those of us who actually do the work. BrownHairedGirl (talk) • (contribs) 22:11, 18 August 2022 (UTC)
"But that relies on other tools and other work flows" Indeed it does. Which is why we have the saying 'when all you have is a hammer, everything looks like a nail'. Except here a hammer is the wrong solution, and the banner needs to be left in place so people with screwdrivers can fix things. Headbomb {t · c · p · b} 01:06, 19 August 2022 (UTC)
@Headbomb, as I pointed out to you at WP:BRFA/BHGbot 9, the advice at WP:CLEANUPTAG is clear
  • "Don't insert tags that are similar or redundant"
    The bare URLs tag is redundant when the ref should be removed.
  • "If an article has many problems, tag only the highest priority issues".
    Again, that is what my AWB job is doing.
You entirely ignored that at BRFA, where you repeatedly used your usual tactics off aggressive hyperbole and streams of falsehoods to try to bully me into silence. You multiply abused your position on BAG to try to enforce your own offbeat view over established guidance.
Now you have resumed your disruption on this page, with your two revenge-RFCs (thankfully now closed) and your nonsense in this section.
If you do not like what WP:CLEANUPTAG says, then go open an RFC on whether to change it. But your continued harrying of me following the guidance now feels to me like a campaign of harassment to add your sordid history of bullying me, insulting me, and abusing your position on BAG to impede my work and promote your own quirky views.
Enough already of your toxic antics. Back off. BrownHairedGirl (talk) • (contribs) 18:21, 20 August 2022 (UTC)
I have neither abused my position as a BAG member (I'll remind you that my closure was unanimously endorsed at the BRFA review), nor have been aggressive/insulting/harrying towards you, nor have sought 'revenge' on anything (revenge for what even?). Please stop making these WP:ABF claims of complete nonsense. Headbomb {t · c · p · b} 19:28, 20 August 2022 (UTC)
On the contrary, @Headbomb: all my assertions about your conduct are both true and verifiable. Per WP:AGF I am not required to sustain an assumption of good faith in the face of clear evidence to the contrary, and I have a pile of diffs in evidence.
Since will you not back off, and since you continue to deny the history of your aggression and of your abuse of process, I will escalate.
Note that the fact that your misconduct was endorsed by WP:BAG does not make your misconduct disappear. It merely makes those other BAG members complicit in your misconduct. BrownHairedGirl (talk) • (contribs) 07:13, 21 August 2022 (UTC)