Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

• Discussions of technical issues belong at Village pump (technical).
• Discussions of policy belong at Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61

Colorize the black & white photos and replace existing photos with colorized copy of it

With the recent advancement of the automated tools that will allow editors to colorize the photos in just a minute, I am thinking of an idea where to colorize the historic photos that are not in color and replace the original black and white photo in article with the colorized copy of the photo inside the Wikipedia article, but not sure if it's a good idea to do or not.

FYI due to copyright restrictions, only colorize the photo that are published in public domain, Creative Commons CC-BY-2.0, CC‑BY‑SA‑2.0 or Flickr "No known copyright restrictions" WPSamson (talk) 01:50, 3 December 2020 (UTC)

WPSamson, My inclination would be not. The idea of images in articles is to add useful information. Colorization generally makes a photo prettier, but doesn't really add any information.

It's certainly possible that adding color makes it easier to understand the photo and/or identify details, and if that's the case, I don't see why it shouldn't be allowed. I post-process my photos using tools like crop, exposure adjustment, sharpening, white balance, perspective correction, horizon rotation correction, etc. Maybe colorizing is just another tool which, if used with care, is a useful addition to the toolset. But I wouldn't just do a blanket "Colorize all the things" to every B&W photo we've got. -- RoySmith (talk) 02:05, 3 December 2020 (UTC)

Some photos have been colorized but the process generally involves original research (bad) in that an editor gets to make up colors which the article then implies are known to be valid. Johnuniq (talk) 02:47, 3 December 2020 (UTC)

Johnuniq, Ah, I didn't realize the process involved the user making color decisions, I assumed it was some sort of A/I which figured it out. Yeah, that would be WP:OR and/or WP:SYNTH. -- RoySmith (talk) 03:12, 3 December 2020 (UTC)

• I think this proposal would be unlikely to garner support due to the WP:OR issues. {{u|Sdkb}} ^talk 06:52, 3 December 2020 (UTC)
• I remember this being discussed years ago, and the conclusion back then if I remember correctly was.. no (for similar reasons as discussed above), BUT ok when showing both versions in the article side to side. —TheDJ (talk • contribs) 09:15, 3 December 2020 (UTC)
• Absolutely Not. However advanced the technology and however well crafted the result might be, we should not be creating fake images — GhostInTheMachine ^{talk to me} 11:16, 3 December 2020 (UTC)
• Color restoration is a different matter. If there is a public-domain or freely-licensed accurate color reference to work from, it's plausible that a "color restoration" can be done without "original research," but this will need to be handled on a case-by-case basis, preferably outside of Wikipedia. The best case scenario would be for the person who does the color restoration to explicitly disclaim any copyright interest in the "restored work" just to avoid having the "legal what-iffers" start a never-ending copyright discussion about it. That way, if the underlying images were already freely-licensed or in the public domain, his restoration could would be eligible for upload to the Commons.

The same applies if the black and white image contains "information" about the original colors, as was the case for at least one episode of Doctor Who, which was broadcast in color, converted to black-and-white using a process that unintentionally preserved color information, "lost," "found" in the black-and-white version, then restored to the color version. Granted, this is not in the public domain, but my claim holds: A color restoration, which adds no creative content, should be treated the same as a "mechanical copy" for copyright purposes until the law or a court clearly says otherwise. davidwr/(talk)/(contribs) 16:27, 3 December 2020 (UTC)

• c:Commons:Colorization. In scope for Commons, can be useful for popular science/history video presentations and magazines where historical accuracy is less important than providing a more attractive picture that grabs the attention of the public (which Commons caters to as it's educational), but (unless an accurate color reference was used) not for Wikipedia. — Alexis Jazz (talk or ping me) 23:37, 3 December 2020 (UTC)

Why do you assume black and white photos are less attractive?--Khajidha (talk) 14:36, 7 December 2020 (UTC)

• So, in light of the above discussion, what do people think about File:Arecibo message.svg? As the caption at Arecibo Telescope says, "The Arecibo message with added color to highlight the separate parts. The actual binary transmission carried no color information." So, colorized, WP:OR, and a Featured Image. -- RoySmith (talk) 03:33, 5 December 2020 (UTC)

The Arecibo message is not a photo, it can be thought of as a political map. In a map it doesn't matter which country has which color, the important part are the frontiers. In the Arecibo message the important parts are the "squares" and their color doesn't really matter. As I understand it this thread is about photography colourisation as in Film colorization not vector graphics or other images. josecurioso ❯❯❯ Tell me! 15:26, 5 December 2020 (UTC)

I'd agree with this - that image is very different from a negative which is then colourised, as that has been colourised in order to highlight the different components of a binary message. It's more of a diagram. SportingFlyer T·C 15:06, 7 December 2020 (UTC)

I just want to say I think colorization of historical images is not in line with being an encyclopedia. When people come to Wikipedia and read a quote in an article, they expect that the quote was accurately copied from the cited source. Similarly, when people see a historical image, they expect that what they are seeing hasn't been significantly altered by Wikipedia. Colorization would be the visual equivalent of intentionally misquoting a historical source in order to make their phrasing sound more modern: a well intentioned change, but not one which is appropriate for an encyclopedia. 李艾连 (talk) 04:13, 21 December 2020 (UTC)

Thinking about a radical reduction of talk page banners

I recently noticed how few pageviews the WP:Dispute resolution requests page gets—less than 2000 per month, despite being linked from {{Talk header}}, which appears on more than 500,000 pages. My assumption is that this is yet more evidence of banner blindness, where we try to cram so much poorly-organized information onto the top of talk pages that no one (most of all newcomers) reads any of it.

If you go to a random high-traffic talk page for a reasonably controversial subject, like Talk:Karl Marx, there's just so much low-hanging fruit or obviously non-ideal design.

Going through various things I notice:

• The way we present WikiProjects is not ideal, even when {{Banner holder}} is used to collapse them. Every project doesn't need to have its own banner repeating the same line about "a collaborative effort to improve Wikipedia's coverage of X" and giving the same quality rating. It'd be better to just have a single banner (perhaps we could usurp {{WikiProjects}}, which has only 6 transclusions) that'd list out each project and its importance rating, and to move the quality rating to {{Article history}} as something that each page has only one of.
• The "this article is written in X English" notice is something that should appear in the editnotice rather than the talk page. We don't need to tell people to use British English in their discussions on the talk page; it's enough to have it when editing the page itself.
• There are a bunch of "this is a hot topic" banners, such as {{Controversial}}, {{Be civil}}, {{Round in circles}} (which also typically duplicates the archive search box), {{Not a forum}}, the arbitration notice, etc. Each of these does technically have a distinct purpose, but the cumulative effect of them is just for there to be a bunch of banners all screaming at you. If I were designing from scratch the ideal top of a talk page for a controversial topic, I'd want there to be only one "this is a hot topic" banner that'd cover all of that stuff. It's also already part of {{Talk header}}, so the emphasis should only be needed in extreme cases.
• There are some banners that, while providing useful information, shouldn't require a banner of their own. {{Vital article}} is one of these; the {{Auto archiving notice}} is another. I'm not quite sure where the vital article notice should go, but really all that's needed is for it to say Level-3 vital article in People; all the rest, including e.g. If you can improve it, please do is unneeded (there's no reason for reminding about boldness more at VAs than elsewhere). As for the auto archiving notice, that could be rolled into the talk header, looking something like this, which would communicate the same info but take up a fraction of the space.
• And then there are the junk banners, such as {{OnThisDay}} or {{Top 25 report}}, which communicate something but not anything most people arriving at the talk page need to be aware of, especially years after the fact. IMO, they should always be collapsed within {{Banner holder}} anytime a talk page has more than a few other banners, but that rarely happens.

I realize I'm throwing out a bunch of different thoughts, some of which could be pursued in isolation, but the larger picture I see is that we ought to move away from our current modus operandi in which each piece of information gets its own banner and instead move to a system in which our core banners are able to incorporate lots of different information and display it in a format where there's appropriate visual weight and no duplication. {{Article history}} has done a great job of this for article quality/milestones, but we need that same effort for lots of different areas. I'd welcome thoughts about how to go about such an initiative, or anything else that might help us address the problem of talk page banner blindness. {{u|Sdkb}} ^talk 04:09, 6 December 2020 (UTC)

WikiProject banners have some affect on a particular database that would need to be tested against before any movement of anything occurs, and some projects have intersecting categories (quality vs priority) that you would not be able to intersect directly any longer if one moved the banners. Many projects additionally put Other Stuff in their banners besides quality and priority and one might wish to investigate how widely used those are. --Izno (talk) 05:15, 6 December 2020 (UTC)

Izno, there are certainly some project banners that function in non-standard ways, but most of these are for non-content-related projects (which are the ones added to article talk pages). To be honest, what I'm proposing probably would require ironing out some idiosyncrasies (e.g. if a project wants to call their importance rating "priority" rather than "importance", that'd probably get lost), but I think on balance it'd be worth it. {{u|Sdkb}} ^talk 05:22, 6 December 2020 (UTC)

What about task forces? Settings for "this page needs an infobox"? Transcluding current activities for GA and such? Etc. Yeah, you're going to iron that part of it out a lot better if that part is to stand a chance of success. --Izno (talk) 05:24, 6 December 2020 (UTC)

Izno, fair enough. I'm coming at this less from a "I've got all the details figured out and want this implemented" perspective and more from a "if I were designing talk pages from scratch, here's what would be different than they look today" perspective. {{u|Sdkb}} ^talk 07:39, 6 December 2020 (UTC)

There is room for debate how to fix the problem. but Sdkb is spot on. Banners are out of control. Look at Talk:Donald Trump. Nobody is going to read all of those banners. Likewise with Talk:COVID-19 pandemic What is this, [ http://www.arngren.net/ ]? Or [ https://www.yyyyyyy.info/ ]? --Guy Macon (talk) 08:47, 6 December 2020 (UTC)

For Trump, and articles like it, taking a step back and trying to prioritize banners sanely and shoving the routine stuff elsewhere can lead to big improvements. See [1]. Not saying it's perfect, but this is a lot better than that IMO. Headbomb {t · c · p · b} 02:03, 10 December 2020 (UTC)

Right, I don't disagree that banners are a mess. I just know WPBanners in specific will be hard to do something about. I think most of the other banners that show up on the talk page are fairly mundane and could all be merged into some equivalent of WP banner shell and not much at all would be lost. (Heck, we could stuff everything into one template, WP banners and all.) As for "are there too many banners on a specific page", if you see duplication in banner intent, or one more specific than another, I highly recommend shipping to TFD or removing the ones you find as being duplicate. --Izno (talk) 18:55, 6 December 2020 (UTC)

Izno, I could try doing a big TfD nom of {{Controversial}}, {{Be civil}}, {{Round in circles}}, {{Not a forum}}, etc., but I'm not sure it'd succeed. Looked at from the more narrow "are there meaningful differences between these or potential separate use cases" criteria we tend to use there, the answer is that there are. It's only zooming out to the larger picture where it becomes clearer that these are having a detrimental effect in the way they're applied 99% of the time. {{u|Sdkb}} ^talk 00:48, 7 December 2020 (UTC)

could try doing a big TfD nom [...] but I'm not sure it'd succeed But why not? Anyway, whether it's successful or not, that's probably a quicker way than waxing over here on WPI. At least one of those banners duplicates (the current) {{talk page}}; I bet we could get the rest integrated into that one too. (And/or as options.) --Izno (talk) 15:24, 7 December 2020 (UTC)

Talk pages banners are a dog's dinner. I think we also have an issue with DS banners, eg Talk:Bill Gates, where people spam multiple DS alerts for the purpose of aiding with awareness, so some of this is complicated by broken underlying systems (something I've discussed with L235 - with any luck the next arb committee might finally fix this particular issue). Further, there's the issue of everyone thinking their banner is "the one" which is important, so it becomes hard to cut down on the blindness once a new banner gets created and over time spurted around everywhere. It's so bad the WMF decided to hide all banners under the small "About this page" text on the mobile version. TonyBallioni once gave me the advice that the idea lab is a breeding ground for dying ideas, though, so maybe collecting together a bunch of interested individuals and figuring out a clear set of strategies and bot operations to reduce this, then putting it forward as a proposal, may be a way to proceed if interest flutters here? ProcrastinatingReader (talk) 11:56, 6 December 2020 (UTC)

• I'd love to reduce, or completely eliminate, the WikiEd banners, ("This article was the subject of a Wiki Education Foundation-supported course assignment, between [dates]. Further details are available on the course page") which are big, and tell you nothing. Half of them are on pages which have merely been reviewed by a student, and even those where the article is supposed to be edited are put on at an early stage of the course. A high proportion of the students make no edits, or just minor ones. Some articles have two or more of these. Once there, they never leave.Johnbod (talk) 02:52, 7 December 2020 (UTC)

  @Johnbod: tried that. See Wikipedia:Templates_for_discussion/Log/2020_November_17#Template:Dashboard.wikiedu.org_assignment. ProcrastinatingReader (talk) 11:15, 7 December 2020 (UTC)

  That result looks workable. You proposed something, someone came up with something else a bit later, and some chunk of the keeps shifted to message rather than full keep. Now we just need someone to file the task to change the behavior in the dashboard... --Izno (talk) 13:35, 7 December 2020 (UTC)

  See User_talk:Sage_(Wiki_Ed)#Alteration_of_the_student_editor_template. Let's see if we can work the feasibility out with Sage. This still leaves the issue of all the other assignment banners, though, which predated the current dashboard-inserted template. I guess we can BOTREQ to orphan, and (optionally) add a talk page message at the same time (although, for some courses that ended years ago that may be awkward, but still, serves as a record I guess?). ProcrastinatingReader (talk) 13:58, 7 December 2020 (UTC)

Damm - missed that. The argument editors need warning is a reasonable one. But it should be as a normal talk page section, not forever kept at the top of the page. Johnbod (talk) 16:42, 7 December 2020 (UTC)

You're right. Those banners get scrolled past quickly. Flounder ceo (talk) 21:19, 7 December 2020 (UTC)

For sanctions, you could have one banner with multiple sanctions (both ARBCOM and Community-sanctions) coded in , something a bit like {{Sanctions/talk notice|topic1=blp|topic2=ap|topic3=COVID}} giving something like

Headbomb {t · c · p · b} 01:10, 9 December 2020 (UTC)

I proposed something similar to AC in July/Aug. Those things also need bigger changes though, and I suspect any change will happen in a bundle. ProcrastinatingReader (talk) 02:58, 9 December 2020 (UTC)

Agree banner spam as with edit notice spam is a problem all over. First step in my view would be to purge lots of junk at Category:Article talk header templates like Template:Editing Friday, Template:Model article, Template:Prone to spam, Template:Webcomics refideas..etc.--Moxy 🍁 23:46, 9 December 2020 (UTC)

Would it be possible to somehow replace some of those templates with some sort of empty template so that pages that use them don't end up with red links but rather simply have the banner disappear?

Another idea: How about a limit on the number of words in all banners combined?

Alternative: How about some sort of bot that goes through every page and creates a list of all pages with more than X words, with pages with the wordiest template collections at the top? (what page does have the largest banner section?) --Guy Macon (talk) 01:09, 10 December 2020 (UTC)

What's the "redlink problem" exactly? The only banners that have redlinks in them, to my knowledge, is stuff like prompts to create a GA subpage when starting a GA review. Headbomb {t · c · p · b} 01:37, 10 December 2020 (UTC)

So you are saying that we can just delete a banner and the pages that have that banner on them will not have redlinks? Let's try:

Template:this is a bogus banner

Looks like a redlink to me.

Again, instead of deleting those banner templates, would it be possible to somehow replace the templates with empty template so that pages that use them don't end up with red links but rather simply have the banner disappear? --Guy Macon (talk) 20:54, 12 December 2020 (UTC)

Again, I ask, what exactly is the "red link problem"? If there's a non-existent banner on a page, just remove it. Headbomb {t · c · p · b} 03:42, 13 December 2020 (UTC)

And again I answer, deleting a banner is easy. Deleting a banner that is used on a lot of talk pages is an effective way to accomplish a "radical reduction of talk page banners". Some of these banners are used on 500,000 pages. That makes it a red-link problem if the banner is deleted. Saying "If there's a non-existent banner on a page, just remove it" is not a solution unless you, personally, are willing to make a commitment to "just remove" all 500,000 redlinks. Again I ask, (if you can please refrain from derailing my question by once again replying with claims that the problem does not exist when it obviously does), would it be possible to somehow replace the templates with empty template so that pages that use them don't end up with red links but rather simply have the banner disappear? Headbomb, please let someone else answer my question. We are all well aware that you think that the problem does not exist and that I think it does. --Guy Macon (talk) 18:54, 16 December 2020 (UTC)

And AGAIN, I ask, what exactly is the "red link problem". Where is it? Do you have examples? You still have to substantiate that there's a plague of redlinks on talk pages which are somehow problematic. Headbomb {t · c · p · b} 21:23, 16 December 2020 (UTC)

I am going to stop replying to you now per WP:CIR. If you can't grasp the difference between saying that if certain templates are deleted this will cause a redlink problem and saying that the redlink problem already exists, I am afraid that I cannot help you. Feel free to get in the last word. I will not respond. --Guy Macon (talk) 23:39, 16 December 2020 (UTC)

So wait, your problem is that if hypothetically, you deleted a banner used 500,000 times, it'll have 500,000 links red left behind? The solution to that is to either to a) not delete a banner obviously in extensive use b) convince the community the banner shouldn't be used at WP:TFD and use bots to remove it or c) mark the banner as historical and simply have it display nothing. Headbomb {t · c · p · b} 07:33, 17 December 2020 (UTC)

@Moxy: Nominated {{Webcomics refideas}} for WP:CSD#G7 speedy deletion. –MJL ‐Talk‐^☖ 03:57, 13 December 2020 (UTC)

I don't see this as a problem. I find the banners play a role similar to that of my unabridged Webster's 2nd, my Columbia Encyclopedia, and my bilingual dictionaries: I don't pick up one of those tomes every day, or even every month sometimes; I walk by them all the time without even seeing them; but they are there whenever I need them, and it's extremely annoying if someone has misplaced one of them and I can't find it when I need it. Ditto many of the page banners; it's mightily annoying if they are not there when I want them. Slap a {{skip to bottom}} template at the top of the Talk page, and you're done. What exactly do you want to do on a Talk page, other than to view the ToC, go to the bottom of the page, or click a notification that takes you straight to the discussion in question, for which banners are an impediment to doing what you want? Mathglot (talk) 08:17, 12 December 2020 (UTC)

This is not a good analogy imo. Partially because the reference books aren’t impeding the entrance, but mostly because you’re vaguely familiar in your head where the books are and what they’re for. A new editor seeing this wall of banners doesn’t even know what they’re missing! Do they click skip, or do they read all the big alerts saying warning/caution/controversial etc, maybe in them some information they need? You and I have the knowledge that it’s all junk so we don’t read it, but they don’t even know yet. Hey, if you want to edit skip to talk with “All the below is junk. Just skip to talk.” In big bold letters and add it auto to pages, then I guess the solution is not so bad. ProcrastinatingReader (talk) 09:53, 12 December 2020 (UTC)

It's really great to see that this conversation is taking place. I strongly disagree with Mathglot because this is a problem that I think ruins the accessibility of a lot of talk pages, especially the ones where the talk page matters the most such as many of the examples given above. I agree with the shortening of the vital articles banner. The template for British vs American vs Hong Kong vs Indian etc English is utterly useless on the talk page, and has little to no effect on the vast majority of issues that arise here (random editors coming in to change a "misspelling"). This definitely needs to be as an edit notice and not the talk page. In fact, I wonder if this could be configured so that if it's placed in the talk page it doesn't show up there put shows up as an edit notice on the article page – so that we wouldn't have to go through and change/remove all of them, though I suppose a bot could do this. Aza24 (talk) 01:55, 14 December 2020 (UTC)

An ideal banner would a clear importance, audience, and process. Banners detract from an article; they are at the top, but are not crucial for the reader. Their purpose is to flag that work needs to be done, but for the majority of readers this is unimportant; only editors need to be warned about BLP. The process to do with each banner is unclear; there is not a clear call to action, sometimes "drive by" editors add them with no explanation on the talk page, no clear ownership of banenrs, banners suggest talk should take place on pages with no watchers, and the numbers do not appear on project pages. My preference would be that banners disappear for all except editors, that banners be clear and simple, and that bots are used to make them expire Wakelamp d[@-@]b (talk) 08:57, 14 December 2020 (UTC)

Wakelamp do correct me if I'm wrong, but I think you're confusing cleanup/maintenance templates (see WP:CLEANUPTAG) on the articles themselves with templates (banners) on the talk pages of articles (the topic of this discussion). Aza24 (talk) 09:06, 14 December 2020 (UTC)

Aza24 You are correct. I am confused. Excuse my rant about the article template  :-) My suggestion for talk pages. I don't actually read them. Many are advertisements for projects, or about the status within a project. Wakelamp d[@-@]b (talk) 12:43, 14 December 2020 (UTC)

Before the AH and banners templates

After the AH and banners template

Talk:Karl Marx is fine now. Some of the areas causing problems have been missed in this discussion.

GA drops in templates instead of building articlehistory. DYK drops in templates without integrating them to the articlehistory template. OTD drops in templates rather than building articlehistory. ITN drops in templates rather than building articlehistory. Vital articles drops in templates rather than placing them in the WikiProject banner shell. I have approached the bot about Vital articles, and that is being addressed. The problem with the other templates being dropped in is that a prolific sockmaster hounded the editor off the project who used to run a bot that processed every single template on talk that related to the articlehistory in to that template, so I have been running around doing that work manually.

If those issues were addressed, and editors would simply clean up talk pages as I have been doing now for several months, we would see that the problem isn't as bad as it appears and not nearly as bad as it was before Gimmetrow and DrPda initiated the effort to tame talk clutter in 2007. Skip to talk is rarely needed, the duplicate archive boxes can often be deleted, and the useless templates like WikiEd and English variety can be rolled in to a banner. The real problem is the need for a bot to clean up articlehistory items, as I have been doing on FAs. (Karl Marx: Projects to banners, OTD to article history, banner holder for English variety and archive info, remove one that is essentially duplicated in talk header, and now skip to talk is no longer needed.)

The discretionary sanction banners can be dealt with by electing arbs who will deal with editors with behavioral problems rather than pushing problems off to other admins via DS. It is astounding that what one bot did over a decade ago to tame talk clutter is no longer being done; surely our coding ability has advanced since 2007 ? Apparently this work I have been doing for several months now is well received, as I am not aware of having been reverted even once. Surely some clever bot or script person can do this work; they once did. SandyGeorgia (Talk) 15:05, 15 December 2020 (UTC)

Vital articles WikiProject continues cluttering talk pages

Messes like Talk:Transit of Venus created by edits like this continue more than a full decade after the last successful effort to tame talk clutter. In my months-long effort to tame the clutter on FA talk pages created by ITN, OTD, GA, DYK, and WikiEd, I am finding the biggest issue continues to be an unresponsive Vital (sic) articles WikiProject. SandyGeorgia (Talk) 09:35, 22 December 2020 (UTC)

@SandyGeorgia: interesting, and thanks for your thorough comment above! Is there a bot proposed to take over the work of GimmeBot, or is anyone working on this atm that you know of? Have any of GimmeBot's functions been replaced by another bot, or has it created a void? Regarding Vital Articles, do you think we could get a consensus to scrap banners for level 4/5, leaving just levels 1/2/3 having talk page banners (1110 pages I think)? ProcrastinatingReader (talk) 04:18, 30 December 2020 (UTC)

Putting this on my list to give a full accounting ... may take me a day or two as I am behind everywhere. SandyGeorgia (Talk) 07:58, 30 December 2020 (UTC)

Summary of talk page clutter issues

Responding to ProcrastinatingReader's query above, with a broader summary of what I have found after several months of working to tame talk page clutter on Featured articles.

What I have done for several months now is to go through every current FAC, FAR, PR, TFA or OTD that relates to an FA, to clean up those talk pages. I an unsure if my observations will apply equally to non-FAs, for example GAs, as I have not attempted to clean those up. My guess is that talk pages of non-FAs are in much worse shape since we lost Gimmebot, because no one is building articlehistory at all on GAs (Gimmebot once did).

In terms of the specific questions asked, no, I don't believe that scrapping levels 4/5 will solve the Vital articles problem, because the problem is simply a failure of Vital articles to wrap their templates in the Banner shell, just like every other project does. Independent of the number of articles where they have done this, the issue of dropping the template anywhere, not reviewing the talk page for the mess made (see this talk page after Vital articles template added), and not using the WikiProject banner at all is the one that should be addressed, whether on hundreds of articles or thousands.

In terms of taking over the work that Gimmebot once did for every template on every article, I'll give an area by area summary of what I know below. What I don't know how to deal with is the problem that we need one bot to clean up after the messes now made by quite a few other bots, so some level of bot coordination will be needed here. I am unwilling to take that on, as I have found many of my interactions with bot operators to be highly frustrating and often unproductive. MOST of my cleanup work has involved putting Vital articles in the {{WPBS banner and merging OTD, DYK, GA and ITN templates (dropped in by different bots) to the consolidated Template:Article history, which was designed over a decade ago for this very purpose, and has fallen into neglect with Gimmetrow/Gimmebot.

WikiEd banners.

Yes they are a problem, but no where near the scope of the other problems I have seen. (It is possible that my sample is distorted, because students are discouraging from editing FAs, so I may be missing the extent of that problem.) WikiEd Banners provide an essential function wrt medical editing at least, and are easily dealt with. I left my feedback on that at the talk page of Sage (Wiki Ed).[2] Basically, I have (literally) never encountered medical editing from a student that did not have considerable errors, and we need to keep those templates on talk until someone has had the opportunity to check the work and remove the errors. When I encounter an old student editing template on talk, I check to see if they actually edited the article (most of the time, they didn't). If they didn't, I just remove the template. If they did, and the errors were later corrected by someone else, I just either archive the template as a talk page section, or move it into a banner. If the errors need attention, the banner needs to stay.

Skip to talk. Related to DS template.

In my experience with cleaning up, there are extremely few (a couple maybe?) instances where this template is needed post-cleanup. The few occasions where I have left it are typically when there are multiple discretionary notices on the talk page, resulting in considerable bloat and length. And yet ... it seems quite odd to me that we are encouraging possibly new readers to skip over a discretionary sanctions template, as it is so important that new editors understand them. On the other hand, in my own editing, I find that new editors rarely read the DS templates anyway, and have no idea what they mean. And, in my own editing area, an Arbcase resulted in sanctions being applied to an entire content area (drug prices), only because the Arbs were reluctant, for understandable reasons, to fully the sanction only three editors who were not editing according to policy. An entire content area subjected to DS ... for three editors. So, solving the problem with Discretionary sanction templates involves addressing what measures the community believes are most effective in dealing with disruptive users, and how that is reflected in their ArbCom voting. In terms of the talk page templating, this is beyond my pay scale, but DS sanctions add considerable bulk to talk pages, that can't be rolled in to a banner, and may be lost in the clutter, or missed because of skip to talk.

Why are these there at all?

There is a whole list of useless banners whose purpose escapes me. Variety of English is flagged in articles, why also on talk? Pageviews are available on articlehistory tag, yet result in some of the most unsightly templates ever on talk. Who is adding this stuff ? I roll them in to {{banner holder|collapsed=yes| so that if they are serving some purpose (categorization?), they are still there.

Talk header and duplicates

The talk header template now includes searchable archive by default, and how to find sources. So, unless they are highly customized, I delete duplicate archive boxes and duplicate find sources templates. And I move the talk header template to the top of the page.

Projects

Not only Vital articles, but some other projects have rarely been rolling their templates in to the {{WPBS shell and can be ... for example, Spoken Wikipedia and the old WP Version 1 templates. A bot should be able to go back and get all these things and stick them in a WPBS shell, and by the way, collapse that shell, since WikiProjects simply don't have the prominence they once did, and talk pages need room for more significant templates (like DS). Here is where things stand with Cewbot run by Kanashimi. The Vital articles project is so decentralized that there appears to be no there there. To such an extent that right now I am unable to even locate the conversation I had with User:Sdkb somewhere recently about how to get this problem addressed. Apparently there is not even a centralized talk page, because I can't find where we had the conversation. If this can be addressed, it will probably need to be part of the whole problem of getting all of these bots on the same page.

The number of problems requiring a new and centralized bot effort, akin to what Gimmebot did, get worse when we got in to GA, DYK, ITN and OTD, as I will lay out next.

FAs

In general, FAs are in a bit better shape than others probably, because Hawkeye7's bot, FACBot, does convert FAC and FAR templates to articlehistory. But, best I can tell, there was a time period when that bot did not convert all other templates, and it still doesn't convert all other process templates, so miscellaneous cleanup is often needed. Gimmebot rolled ALL content review processes, AFDs, ITNs, OTDs, etcetera in to one template. That is what we are missing today.

ITN

I don't have enough samples to go by there; I just roll their templates in to articlehistory when I find them. If we somehow replace Gimmebot, they can all be addressed.

OTD

Is The Worst. Best I can tell, the bot procedures have changed over time, so one finds all kinds of inconsistencies in terms of what is added to the articlehistory template and what is not, and fixing these is hugely time consuming and no fun, partly because of the infuriatingly frustrating disconnect between how Template:Article history handles multiple entires, and how the OTD bot adds them. Article history uses the parameters ... otd1date, otd1oldid, otd2date, otd2oldid, and so on, while OTD uses otddate1, otdoldid1, otddate2, otdoldid2, etc. Imagine the work to convert those to articlehistory manually! WHY can't we use the same convention on the number x? Again, lack of centralization in how we handle content processes that were once routinely handled by Gimmebot. In attempting to figure out to whom one speaks to get this addressed, I've discovered there is also no overall OTD process or page, rather one goes to Howcheng on this.

DYK

The second worst. Why oh why do they use the parameter nompage= for the link to the nomination page, while Article history uses dyknom= ?? This means the DYK nomination page has been lost in many article history templates, and I having to go back and recover them. Could we all get on the same page?

GA

Not rolled in to article history at all, best I can tell. GimmeBot once did. This can be hard work because not all GA reviewers now how to use the subst template correctly when closing.

PR

Exactly the same as GA.

FAC, FAR

While FAC and FAR templates are converted by daily bot runs to articlehistory, the formatting is inconsistent and confusing. I clean up every one of them every day; my hope is that if we make the articlehistory entries consistent, clear and less confusing to the average editor, others will begin to understand how to use that template to do their own cleanup. So, just as Gimmebot did, I make sure the events are in order, there is a space between each event, and the current status is listed at the head of a section at the bottom which is then followed by dates (maindates, OTDs, ITNs, etc). I believe that consistency will make the article history more understandable to more editors. Also, FACbot for some reason is not adding |currentstatus= FFAC .

So, to get ALL of this cleaned up will require someone to get all the bot operators to talk to each other, and for someone to write a bot that does what Gimmebot was doing more than a decade ago ... rolling every process in to the articlehistory template, while also rolling projects into collapsible banners. SandyGeorgia (Talk) 19:16, 1 January 2021 (UTC)

High-importance articles are rife with possibly unofficial non-free depictions

As an example, the image on Pluto (Disney) was File:Plutodog.gif that is sourced to "The Walt Disney Company". That's it! No URL, no comic book or movie title, nothing at all! For reference (as this image will disappear in a week or so), it is the same as w:sco:File:Plutodog.gif, [3] and [4]. For the same reason we are discussing the lead image for Donald Duck. And there is more. 625 non-free images from Fandom alone. I see too many such images that are either unsourced or sourced to Fandom and the like. Perhaps an edit filter or bot or something could be considered to at least tag these if not outright block uploading them. — Alexis Jazz (talk or ping me) 10:30, 6 December 2020 (UTC)

We definitely should not be pulling images from Fandom even though we know the sourced image originally came from Disney, especially when there are clear alterations beyond resizing done (such as the transparency here) that could possibly make it a work from a non-Disney fan artist. --Masem (t) 15:20, 8 December 2020 (UTC)

@Masem: Any idea how this could be moved forward? I think an edit filter would be rather helpful here. I was hoping for input from more users. — Alexis Jazz (talk or ping me) 12:03, 22 December 2020 (UTC)

Image clutter in articles is a huge problem ... which WMF is looking to make even worse. SandyGeorgia (Talk) 12:10, 22 December 2020 (UTC)

Unbundling for the millionth time

This current AN discussion had me thinking about a human-powered, not bot-powered, solution to the occasional case where an IP will hang out at a page for a while, repeatedly vandalizing, for the hour or so it takes an admin to show up. Add a group of editors who can add a template to a page that'll cause an adminbot to protect it for an hour; perhaps also require that the page has a high number of recent reverts. (Bonus: for a single IP hopping to multiple pages, another template that'll cause an adminbot to block them for an hour, requiring perhaps that every edit by that IP has been reverted.) I feel like similar proposals were discussed recently, but couldn't find any, hence this post. Enterprisey (talk!) 03:54, 7 December 2020 (UTC)

I feel like similar proposals were discussed recently I remember a recent proposal which was something along the lines of non-admins being able to protect a page for 24 hrs / block IPs for 4 hours, or something along those lines. Can't find it at a quick check of archives, but then again using Special:Search is too hard for me. That having been said, I think the AN thread can be mostly handled by the filter Suffusion of Yellow is working on. ProcrastinatingReader (talk) 11:14, 7 December 2020 (UTC)

ProcrastinatingReader, I think that was this thread I started. It never got formally closed, but my informal reading was that while it wasn't shot down in flames, it wasn't riotously supported either. -- RoySmith (talk) 18:56, 8 December 2020 (UTC)

I like this idea I guess, but should be increased to up to 48h for IPs and semi for a few days, to have it actually be useful. An hour is just insufficient. Blocks to IPs vandalising should be favoured over protecting a whole page probably. ProcrastinatingReader (talk) 10:18, 8 December 2020 (UTC)

One hour blocks get rid of the vandal whose just bored while sitting around in a computer lab or on the train. More intractable vandals should be dealt with by admins and CU anyway given the larger toolbox they have to shut down the vandals long term Slywriter (talk) 13:26, 8 December 2020 (UTC)

@Enterprisey: without relying on an enancting bot (and thus making the botop responsible for their actions) or software changes if we really wanted to some sort of fast-SPP we could possibly use the edit filter possibly like this: (a) define who can do this (perhaps all rollbackers) (b) set up an edit filter that only allows this group to add a special template to a page (possibly only to articles) (c) set an edit filter to not allow editing of pages with that template on them by non-confirmed users. (d) Now use a bot, that can run on in batch to go and clear out any of those templates that has been present for more than x time. (Of course any rollbacker/admin can manually remove it). — xaosflux ^Talk 15:07, 8 December 2020 (UTC)

This could be similar to Special:AbuseFilter/803 which provides the base-userpace SPP functionality, but would be non-blocking by default. — xaosflux ^Talk 15:16, 8 December 2020 (UTC)

I remember from an IP this morning that I rollbacked, often these people just move to another article (or roll you back) and rolling back is just clogging up the article history. I think the core element of this is to be able to temporarily block an IP address, otherwise some poor bloke is chasing an IP around adding {{cannotedit}} onto pages the IP hops onto until an admin finally comes around and dishes out a block. It kinda just wastes time for people chasing an IP around, I feel, and will create unnecessary protections.

Speaking of that thread, I found where this discussion happened before! Wikipedia:Village_pump_(idea_lab)/Archive_32#Staying_ahead_of_the_moles_(as_in_whack-a) (RoySmith may be interested in this?). Not exactly the same, but similar. It mostly just died out, rather than explicit consensus against, it seems. On accountability, a bot could log all actions by this 'group' for manual review. Concern with adding the perms to rollbacker: it may raise the bar for granting the perm, and that never seems to end well. ProcrastinatingReader (talk) 17:52, 8 December 2020 (UTC)

BTW regarding the accountability point, you did explain accountability vs responsibility to me before in an elegant way, but I still feel something is off about this. That convention on botops, to the extent that it has any practical effects (given TFD/CFDW/patrol bots), is a social construct rather than a technical limitation, right? I don't see what the real difference is between having the MediaWiki software do it (through 2 filters + a bot) vs just one bot. Similarly, the person who wrote the patch in MediaWiki for the technical block functionality isn't responsible for someone, who the community gave sysop to, going on a blocking spree. Surely we can amend WP:BOTMULTIOP to say that bot operators are not responsible for the edit themselves, minus technical bugs, if the person who can trigger the bot is decided in a manner set and approved by community consensus in an RfC (which this feature would need anyway), rather than by a process chosen by the bot operator, and the triggering editor is disclosed and verified? Surely this kind of amendment makes sense anyway, if the community are the ones setting the criteria, and unrelated admins are the ones executing said criteria? ProcrastinatingReader (talk) 18:16, 8 December 2020 (UTC)

ProcrastinatingReader, Yup, you found it. I'm neutral on the details of the implementation (new core permission, adminbot, whatever) but ultimately I think some sort of process is necessary, akin to Citizen's arrest. The idea is that a (much) larger population of users is empowered to make temporary, scope-limited interventions to stop vandalism, faster than the much smaller admin corps can react. There are, of course, lots of details to worry about to prevent abuse: who's authorized to do it, how long they can protect/block for, reporting/review/accountability, etc. -- RoySmith (talk) 19:10, 8 December 2020 (UTC)

So, let's talk strategy. This is a proposal that many people (including me) like, but we have to face the reality that similar proposals have been shot down in the past. Because of this, IMO any proposal should start very conservative -- ignoring all cries that it isn't enough -- and then after it shows itself to not cause problems, we can discuss possible modifications. I would propose:

• Stop discussing how to do it until we have a consensus to do it. Early focus on implementation details destroys good ideas. First decide what you want to do assuming that you can do anything. Then decide what the closest thing that you actually can do is.
• Six-month Three month limited trial, tool disabled and discussion started on whether to re-enable at the end of the trial.
• Stop the trial early if there is a consensus that it was a bad idea.
• Based upon a permissions list.
• Editors must request permission. Only given to extended confirmed editors in good standing.
• Limited to one hour of blocking for IPs only. No page protection.
• Cannot be used more than 10 times in any rolling 7-day period.
• Draconian punishment for abuse. I would suggest a six month block and a two-year revocation of permission to use the tool on the first strike.

If someone proposes the above and it gets shot down, we will pretty much know that any proposal that involves any unbundling will be a waste of effort. --Guy Macon (talk) 19:15, 8 December 2020 (UTC)

Maybe lower the trial to a 3 month period? Ideally after a successful trial we can ditch the Cannot be used more than 10 times in any rolling 7-day period.

We're also going to need a better criteria for Editors must request permission. Only given to extended confirmed editors in good standing. Ending up with a de-facto "I'll know it when I see it" is untenable imo. A good criteria for admins to assess grant requests by, and for users to assess their own suitability with, is required. Also, I think some technical aspects matter, to relax people. Granting the "block" perm may be different to granting a new "blockip" perm + bots logging actions by group, certainly may have an effect on the criteria. ProcrastinatingReader (talk) 19:40, 8 December 2020 (UTC)

@ProcrastinatingReader: making new core permissions will require development time (see phab:T128328 for the 2016 request that would need to be done for some of this) - for a trial you may want to use "administrative controls" (i.e. a policy / "rules") instead of hoping a developer delivers on that and that it gets incorporated to core. — xaosflux ^Talk 20:05, 8 December 2020 (UTC)

Ending up with a de-facto "I'll know it when I see it" works just fine for Wikipedia:IP block exemption, and is sufficient for a tree-month trial. --Guy Macon (talk) 20:59, 8 December 2020 (UTC)

I'm not sure I agree. See, eg, this. The people we want having this tool may not be bold enough to ask if they feel the bar is too high, and granting admins may not know what to look for. A lack of granting criteria has caused broken permissions processes every time, and clear criteria (ie, most other perms) has created a somewhat functional system. IPBE is quite different in that people are forced to ask for it, or else they literally cannot edit. Nobody is forced to ask for the block button, they can keep painfully spamming !admin on IRC. Whether "I'll know it when I see it" is sufficient for a trial, well, perhaps? But I'm not sure it's very reassuring for people voting on the proposal; I have a picture of the bar in my mind, but I have no clue if that bar is the same, much higher, or much lower, as the picture in yours (also note EFH, TPE PMR all proposed criteria). But I see the point that drafting a clear criteria is just another point to debate on, which may be equally as tricky as the proposal itself, and should maybe wait till post-trial review. How about the granting process? Can any admin grant on request, or should it be like an EFH process where it's advertised on a noticeboard for 3 days of comments and closed by an uninvolved admin? ProcrastinatingReader (talk) 21:09, 8 December 2020 (UTC)

Alternative limit: at most 10 outstanding blocks at any time (blocks "taken over" by an admin don't count). Which raises the question of whether admins would even bother blocking an IP that's already under an hour-long block. Enterprisey (talk!) 11:17, 9 December 2020 (UTC)

Just noting, it is trivial to make an access group that can technically fully use the Block interface, and make a community rule that says that members of that group may only use the access in certain conditions and with certain parameters. (Protect is a bit of a messier situation, but such a group could be combined with the AFilter info above). — xaosflux ^Talk 19:19, 8 December 2020 (UTC)

For the more enwiki-focused here, I'll add Meta has the similar concept of "limited admins" - they have the full toolkit but are only allowed to use it within $scope_requested_at_rfa (could be time, specific tasks, things like that), straying out of those bounds is grounds for immediate desysop. So there is precedent for "here's $permission, you may only use it for $tasks" GeneralNotability (talk) 21:21, 8 December 2020 (UTC)

GeneralNotability, We have some of that on enwiki too. Don't election scrutinizers get temporary CU rights? Are don't we also have an "event organizer" role that gives people running edit-a-thons the ability to create accounts and grant them confirmed access? -- RoySmith (talk) 21:30, 8 December 2020 (UTC)

@RoySmith: the scrutinizers must already be global stewards, so that's really no big deal; the event coordinator is closest - they are allowed by policy to confirm accounts - but only for up to 10 days (though the system does not technically enforce that).

@GeneralNotability: I doubt the m-w "limited admin" style itself would fly here, but the concept of only being allowed to use permissions for certain things may. There are some other projects that have a limited-admin-like group that has a subset of admin tools (like block and delete or other combos) - canonically this is usually called "eliminator" but can be styled locally however. Rules and control can be whatever is good for the community and so long as undelete/viewdelete are not involved it doesn't require an "election" system. — xaosflux ^Talk 02:50, 9 December 2020 (UTC)

I support anything that gives us a role called Eliminator. No questions asked. GeneralNotability (talk) 04:12, 9 December 2020 (UTC)

Now that's a hat to collect. —valereee (talk) 10:37, 9 December 2020 (UTC)

Looks like we’ve found a name too! ProcrastinatingReader (talk) 10:51, 9 December 2020 (UTC)

ProcrastinatingReader, I was actually being facetious. It's a great name, but I think it will attract bad actors because they want that hat and the accompanying userbox. Sorry, I should have indicated I was being facetious. :) —valereee (talk) 13:22, 10 December 2020 (UTC)

In my opinion -- and I do have quite a bit of experience in the area of technical proposals -- "I think some technical aspects matter, to relax people" is a common mistake. Here is the right way to do things:

Step 1: decide what you would like to do without any thought of implementation details.

Step 2: look at the technical issues, figure out what is possible given the budget and deadline, and modify what you came up with in step 1.

Step 3: create a concrete proposal and see if it flies.

You don't need "to relax people" until step 3. Every time something like this comes up in discussion, some well meaning person gets into the weeds of what is and isn't easy to do before there is agreement as to what to do. I get it. I have the same tendency and did it that way before I learned a better way. Getting into implementation details too early kind of sort of works OK, but my way works far better. --Guy Macon (talk) 21:18, 8 December 2020 (UTC)

Guy Macon, What you're describing is certainly what goes on in the software development world. Product management comes up with what's often called a PRD (Product Requirements Document) which describes what they want the feature to do. Then they get together with the developers who, after they stop laughing, tell product management what's technically possible. Then, the two sides hopefully converge on something that's both useful to the user and possible to build. -- RoySmith (talk) 21:35, 8 December 2020 (UTC)

I am guessing the answer to step 1 is currently "create a group which can place blocks on IPs for up to 1 hour". And we have your bullet-pointed list above as a start. So, what exactly comes next? ProcrastinatingReader (talk) 21:35, 8 December 2020 (UTC)

Stage one

• Confirm that we have a local consensus (just us in this discussion) for 1 hour and not some other duration (does anyone object?)
• Confirm that we have a local consensus for a three month trial (does anyone object?)
• Decide who should be allowed to use the tool during the trial and who will grant permission.
• Decide what happens if someone abuses the right. (I vote for very harsh penalties, with the penalty made clear to anyone who asks for the user right.)
• Come up with a catchy name. (This is actually one of the main things that determines whether the proposal passes)

Stage two

• Take the above and start discussing ways to accomplish this during the trial, modifying the requirements as needed.
• Come to a consensus as to not only what we want to do but how we want to do it.

Stage three

• Draft an RfC, giving everyone a chance to criticize/modify it before going live.
• Post the RfC.
• Populate the early !votes with !votes from those of us who have been working on this.
• Get shot down in flames just like every previous unbundling proposal.
• Get very, very, drunk.

--Guy Macon (talk) 22:59, 8 December 2020 (UTC)

Gotcha. On harsh penalties, I feel like we go overboard here. We shouldn’t try to overly scare competent editors who offer to volunteer their time for free. To that end, maybe just say that it’s an admin-level permission and so WP:TOOLMISUSE applies? ProcrastinatingReader (talk) 23:52, 8 December 2020 (UTC)

ProcrastinatingReader, TOOLMISUSE seems like the right standard to apply. A good (if imperfect) analogy would be WP:NAC. We carved out a process previously reserved to admins and allowed non-admins to do it. There's limits on what discussions non-admins can close, questionable ones regularly get reviewed at WP:DRV, and every once in a while there's somebody doing NACs who is doing a poor job of it, and they're "encouraged" to not do them any more. I don't know of any cases that got as far as a formal NAC WP:TBAN being enacted, but I wouldn't be surprised if there have been some. Overall, it all seems to work.

The only difference is that with NAC, the "only admins can do it" was a convention, and with blocks and page protections, it's enforced by the software. But, that's a detail. The software exists to serve the needs of the community. If it's not doing what we want, we either change it or route around it. -- RoySmith (talk) 03:09, 9 December 2020 (UTC)

For granting, two wild ideas: the usual PERM process, except require two admin approvals? Or the usual PERM process, except no self-noms? (So I guess candidates would have to ask someone else to nominate them.) I have done zero thinking through of the drawbacks of either. Enterprisey (talk!) 09:39, 10 December 2020 (UTC)

Why not both? Must be nominated by some other editor ('surprise nominations' are okay, encouraged even). Open for a minimum of 48 hours, if two admins agree and there's a consensus to promote (ie not 10 other admins saying "bad idea!") any admin can close the discussion and grant the permission?

For revocation, TOOLMISUSE standard: any admin who believes the permission has been abused (or used outside of its approved scope) may revoke it immediately, and should start a follow-up discussion at AN for the matter to be discussed. ProcrastinatingReader (talk) 09:44, 10 December 2020 (UTC)

I like how that sounds. (This is reminding me a little bit of the interface admin discussions, haha.) Enterprisey (talk!) 09:48, 10 December 2020 (UTC)

What if that "some other editor" nominating is an admin? Do they count for the admins agreeing? Majavah (talk!) 09:52, 10 December 2020 (UTC)

Hm, I can see both sides. I think it's simpler and more consistent just to say no (admin nom doesn't count), so that by design at least 3 editors (1 admin/non-admin nom, plus 2 admins concurring) have agreed on each request.

As an aside, the point of nomination-only in my eyes is: (a) grossly unqualified candidates won't end up nominating themselves and having to go through the rejection; (b) candidates too scared to nominate themselves won't be prevented from getting a right to help their workflow (and consequently, improving the encyclopaedia). I don't think this has any obvious downside: any competent person consistently reporting IPs at AIV will have gotten the attention of someone. ProcrastinatingReader (talk) 10:26, 10 December 2020 (UTC)

A draft

I think I have roughly summed up what we have above so far, and taken some considerations/concerns from the previous discussions on this. Rough draft at User:ProcrastinatingReader/draft. Thoughts? Reading over past discussions (linked there, also pinging some previous proposers/commentors for advice @WereSpielChequers, Jackmcbarn, Oiyarbepsy, Hut 8.5, and Dank). Reading over the previous RfC, I can extract the following main concerns, with varying prominence:

1. Blocking anyone is a right that should be subject to full community approval. Or: Block should not be unbundled. (maybe the 48h hold and multiple admin requirement addresses this, somewhat?)
2. Unbundling proposals based on what might pass, not on what's actually needed.
3. Backlogs aren't that bad and admins can deal with the workload
4. This creates 'admin-lite'. Anyone who can be trusted with "block" can be trusted with "sysop" / "I'll support you at RfA if I trust you with this right"
5. Will lead to controversial blocks
6. Won't decrease the workload, because an actual admin has to come along and make the protection / lengthen the block anyway. 1 admin > 1 admin + 1 non-admin.
7. Scope so narrow that any benefits aren't worth the developer effort

Some of these maybe can't be defended against in the proposal (eg #4 is just idealism). And #6 I think misses the point, in that this intends to put a stop to ongoing vandalism when an admin can't respond fast enough, the time the admin would've spent blocking before is equal to the time they will spend blocking after the proposal. The difference is that a vandal-fighter, instead of chasing an IP around for half an hour, can just press block and submit a report to AIV and move onto the next person. We can maybe think up stuff to deal with the other concerns, though? ProcrastinatingReader (talk) 11:19, 10 December 2020 (UTC)

Also, the original 100-person RfC, despite ~50 opposes, nobody raised concerns with the proposed 48 hour block duration / proposal that non-autoconfirmed can be blocked as well as IPs. So I think we can loosen those restrictions (1hr is probably too short, and will create more cases where a normal admin has to issue a follow-up block, given the normal blocking period is ~31 hours). ProcrastinatingReader (talk) 11:22, 10 December 2020 (UTC)

I'm not sure I agree with the concept and I don't like the name, maybe moderators or proctors? Given that many IP blocks are usefully 31 hours - excluding kids from that school day and the next, I think that if this proposal is going to be of any use it needs to be 31 hour blocks, or at least something more than an hour. It also needs to specifically exclude incidents that are disputes between people who could and could not be blocked by these admin lites. As for the 12 month tenure, you can pass RFA with not much more than that. How about must have edited in at least 8 different calendar months? ϢereSpielChequers 12:29, 10 December 2020 (UTC)

@WereSpielChequers: I'm not sure I agree with the concept Can you elaborate on this part too (is there also something fundamentally flawed here)? ProcrastinatingReader (talk) 12:36, 10 December 2020 (UTC)

WereSpielChequers, the concept behind one hour is that it gives an editor who is fully-busy with reverting the vandal time to report and get an admin there to reblock for 31 hours. I love eliminator but I think it's going to attract bad actors who want a superhero userbox. Even proctor sounds too "I'm in charge here" to me. Maybe something like "temp-protect"? —valereee (talk) 13:19, 10 December 2020 (UTC)

Fair. "Moderator" makes me think of censorship or something like reddit, in today's political climate, so eh. If eliminator etc is too much, maybe we can just be bland (eg indeed "tempprotect", or name it after the perm - "blocker", or "abuseblocker", etc). ProcrastinatingReader (talk) 13:34, 10 December 2020 (UTC)

FWIW I don't even like admin. :) Anything with "blocker" in it is probably too attractive, IMO. Moderator IMO has the same problem. And, yes, blandness in this case I think is much-to-be-sought-after. —valereee (talk) 13:45, 10 December 2020 (UTC)

Yeah, I really hate the "eliminator" name. Maybe "first responder"? The analogy is to an EMT who rushes in to provide immediate intervention, gets things stabilized, then hands off to a more experienced team (Emergency Room doctors) for follow-up treatment. Keep it positive. -- RoySmith (talk) 14:04, 10 December 2020 (UTC)

If blandness is the goal, how about "support"? Like how it's understood that a Police Community Support Officer has the official capacity of Just Some Guy --Paul ❬talk❭ 14:36, 10 December 2020 (UTC)

I like that. No one is going to apply for support permissions for the sake of bragging rights. —valereee (talk) 16:10, 10 December 2020 (UTC)

There's also a mixture of the above, like "medic" (as in stop the 'bleeding' / first aid). 'responder' also seems okay. ProcrastinatingReader (talk) 16:21, 10 December 2020 (UTC)

I like responder. Bland enough, but not too. —valereee (talk) 20:34, 10 December 2020 (UTC)

I'm in the camp of people who think that the solution to a shortage of admins is to appoint more admins. ϢereSpielChequers 13:14, 10 December 2020 (UTC)

Ah, okay. For context (since it probably seems out of the blue): I pinged as you proposed these two in 2013: [5][6], which seemed kinda similar (though broader) to this one. ProcrastinatingReader (talk) 13:28, 10 December 2020 (UTC)

WSC, this isn't so much an admin shortage problem. It's an "ACK! Emergency!" problem. I'll make an analogy: The fire department is five miles away, and it takes them ten minutes to respond to a fire. We may very well need more fire fighters, but that doesn't solve the problem. So maybe we should consider making sure we have smoke alarms & fire extinguishers creating the position of fire warden and arming them with fire extinguishers.. —valereee (talk) 13:31, 10 December 2020 (UTC)

This is similar to things I proposed seven years ago, my views have since shifted. It is indeed an "ACK! Emergency!" problem, but that makes it a subset of our admin shortage problem. The Firefighter analogy is a good one, except that firestations cost money, as do fire-engines and usually firefighters. Since admins are unpaid, they are the equivalent of deploying smoke alarms and fire extinguishers and appointing and training people as fire wardens to evacuate office buildings when the fire alarms go off. Most of us don't want our admins to be paid, or even to be so busy being admins that we don't have time to do the non admin stuff that may be the main reason why we are here. The way to prevent that is to have lots more admins. ϢereSpielChequers 13:54, 10 December 2020 (UTC)

WereSpielChequers, I agree that we need more admins, but that's a bigger and harder to solve problem. People don't want to subject themselves to the ritual hazing that goes on at WP:RfA, and honestly I can't blame them. -- RoySmith (talk) 14:09, 10 December 2020 (UTC)

I agree that RFA can be a ritual hazing, but I believe its reputation is worse that the reality. It is afterall still capable of giving candidates 100% support as has happened twice in recent months. ϢereSpielChequers 16:30, 15 December 2020 (UTC)

WSC, great, so back to the analogy: this creates the position of volunteer fire warden. :) —valereee (talk) 15:56, 10 December 2020 (UTC)

I stand corrected, As admins are unpaid we are more akin to firewardens than firefighters. There is no reason to limit the numbers of such volunteers. ϢereSpielChequers 16:30, 15 December 2020 (UTC)

@WereSpielChequers: I think the point valereee was trying to make (or at least how I read it) is less the paid/volunteer distinction and more that people can still be useful in preventing fires (given the right training and tools) without having all the knowledge, qualifications and trust it takes to become a firefighter. The rebuttal is probably that we can just make people firefighters and trust that they're sensible enough to only respond to the fires they can handle and learn along the way and then tackle bigger fires. But then we'd have to introduce the Firefighter Appointments Board into this analogy. ProcrastinatingReader (talk) 12:26, 16 December 2020 (UTC)

Yes. But there are some differences between this proposal and say the unbundling of template editing. Firstly a lot of editors at RFA care deeply about who gets to block people, and that makes it unsuitable for unbundling. Template editor was a successful unbundling because it didn't involve either of the "third rails" that get most attention at RFA. This proposal involves blocking, one of the "third rail" issues at RFA. The proposed requirements are pretty close to an RFA minimum requirement - 12 months tenure, whilst template editor is available for people who can edit templates, a topic that rarely ever even arises at RFA. Unbundling template editor actually reduced the admin workload, as indeed would a 31 hour block for IPs. But a very short block doesn't reduce the admin workload, complicates IP's block logs because instead of a 31 hour block you will now sometimes get a one hour block upped to 31 hours by the reviewing admin. Unbundling the power to block newbies and IPs for the lengths of time that admins do would actually save admin time, so in that sense it becomes tempting. Though it would be better to recruit more admins. BTW, you've missed two of the arguments against such an unbundling. The mop is a toolset, and block is not always the right tool. unbundle just that hammer and you risk having it be used where page protection would be the better tool or where both block and revision delete should be used. Secondly there is the idealistic one that all editors should be equal, and this means that we would be more ready to block newbies than the regulars (I don't buy this last reason myself, but I believe others will). ϢereSpielChequers 13:34, 16 December 2020 (UTC)

@WereSpielChequers: I think I get what you're saying overall. On some of the specifics: the stricter requirements and the 1 hour block I believe was intended to make the proposal more digestible (and then add on it with time as appropriate), but do you think in reality it actually does the opposite? Regarding toolset, I think the idea was that people with this group don't act when the necessary action is outside of their tools, and in those cases resort to doing what they do now (report/find an admin).

But I think the overarching idea is whether this functionality should be unbundled at all? Or if, to the extent that it should be unbundled, those terms will gain community consensus. Do you think there's a way to remedy this proposal in a way that makes it both more useful, and more acceptable to the community when it goes for RfC? If not, and if this is a doomed proposal, what else can be done about the real problem it tries to address? ProcrastinatingReader (talk) 17:29, 19 December 2020 (UTC)

• @ProcrastinatingReader: thanks for failing to live up to your user name by writing this draft. In particular, thanks for doing the research to find all the earlier discussions. I can nitpick some details, but overall I think it's workable. It's certainly good enough for a trial; at the end of 3 months we'll know more and can evolve the concept based on our experience. My one question is the 1-hour block window with respect to WP:AIV response time. Do we have any statistics on how long requests usually sit in the AIV queue before being serviced? I'm looking at it now and see a couple (one bot, one user) that are 3-1/2 hours old. If that's typical, then maybe a 3-6-hour block would be more appropriate? -- RoySmith (talk) 14:31, 10 December 2020 (UTC)

  I've been intending to slap together some code to answer that and the related question of "how much time is actually wasted with these constant reverts", but I'm working on stuff for my wikiconference demo; maybe next week. I agree increasing the block length might be appropriate. The block length could be increased even further with additional restrictions on the blocks' usage, such as requiring every (90%?) edit by the user to have been reverted. Enterprisey (talk!) 02:36, 11 December 2020 (UTC)

  That would be an interesting statistic to put into the background section! The latest RfA (from Hammersoft) also gave me an interesting one (saving me the digging): WP:AIV has been tagged as backlogged more than 40 times in the past week. It's worth noting a bot removes 'stale' AIV reports after 4-8 hours, but it's likely most of these are ones where no action was required. ProcrastinatingReader (talk) 11:02, 11 December 2020 (UTC)

  One place where you can find these examples, btw, is the history of User:ProcBot/EW. Ranges from 20 mins to a couple hours till block. At a glance atm, most are in the middle of that range. ProcrastinatingReader (talk) 23:39, 11 December 2020 (UTC)

• @ProcrastinatingReader and Enterprisey: - a couple of bits from me. Was there a reason that unbundling block, rather than protect, was considered? I would have thought that objections to ultra-minimal semi-protecting (otherwise in line with the limits here) would be less controversial. A mis-targeted block is an ultra-aggressive action to happen to you, whereas protects don't risk losing the user permanently (at the tradeoff of being broader). Whatever route is taken, it should note that the same requirements of WP:ADMINACCT will apply to their use by first responders. I would actually suggest 3 hours - this is particularly key in the admin inactive bubble (0300-0800 UTC). Nosebagbear (talk) 12:12, 16 December 2020 (UTC)

  I think whilst protect may be more acceptable to the community, I think it's a very bad idea and not in line with the protection policy. One vandal hops across many pages, and they all end up semi-protected for an hour (or few), repeat until an admin comes and blocks? Where do we draw the line? 100 pages semi-protected, rather than blocking the one IP causing trouble? What if they are causing havoc at AN? Protection stops everyone (not autoconfirmed) from editing, whereas blocks only stop the vandal from editing. I get the fear of mistargeted blocks, but blocking solely obvious vandalism is a much lower bar than what admins have to do (block for disruption / edit warring / content disputes, all that more discretionary stuff), and the kinds of people I am thinking in my head with this perm would not make this error in distinguishing. I honestly think the error rate here will be equal, or lower, than what the error rate by admins is. ProcrastinatingReader (talk) 12:20, 16 December 2020 (UTC)

  ProcrastinatingReader, Blocks and protection are different shaped tools; the sets of problems they solve are different, but overlapping. Somebody with a dynamic IP can vandalize a single page from many different addresses (protect) One person can vandalize many pages (block). Ultimately, it would be useful to extend both of these tools (in a limited way) to non-admins. But for an initial proof-of-concept, we should pick one and see how it goes. At some point in the future, we can come (presumably) back and say, "This is working. We've figured out authorization, monitoring, corrective action for abuse, etc, and put processes into place which solve the problems we discovered as we went. Now, let's give them the other tool as well". With that in mind, I don't think it's critical which of the two we offer first. -- RoySmith (talk) 14:35, 16 December 2020 (UTC)

  ime the scenario of one account/IP being a problem (on one or multiple pages) is more commonly seen than multiple IPs on one or more pages. But when I asked a few people offwiki for thoughts on this idea, I generally got the gist that people are more favourable towards protection than blocking, so it may well be that's more appropriate. That said, it would take more judgement to use and more incorrect usages (or, less usages in general, if used correctly) I fear. The protection of a page where just one IP is engaged in vandalism would (in most cases, at least) be contrary to the protection policy I'd think? ProcrastinatingReader (talk) 17:16, 16 December 2020 (UTC)

  I originally envisioned it as actually unbundling both; probably just one would be easier to pass, and as per the above, both have their pros and cons. Protection, of course, would be the proper tool if a single article is seeing disruption from a variety of non-autoconfirmed editors, but intuitively this is rarer than the one editor/many articles case, so unbundling blocking would then have a higher impact. Enterprisey (talk!) 07:53, 17 December 2020 (UTC)

  but intuitively this is rarer than the one editor/many articles case. This is my experience as well. The two most common cases I encounter are A) An single account vandalizing a whole bunch of pages and B) An single account continuously vandalizing an single page. In my personal experience the single article/many accounts is incredibly rare with the last one I can recount weeks ago. Merry Christmas! Asartea ^{Talk Contribs!} 12:30, 17 December 2020 (UTC)

Conduct dispute resolution systems

How are our conduct dispute resolution systems working for us? How can they be improved? (This is an opinion-soliciting discussion, not a proposal to vote on.)

List of conduct dispute resolution systems:

Noticeboards: WP:AN, WP:ANI, WP:ANEW, WP:AIV, WP:RFPP, WP:COIN, WP:UAA

Arbitration: WP:ACDS (WP:DSLOG), WP:AE, WP:RFAR, WP:ARCA

WMF: m:T&S, m:UCOC (proposed)

Historical: WP:RFC/U

I think the answer to the first question is "not very well", and I'm not sure of the answer to the second question, but I think it would be useful to gather opinions about and discuss what the community can do to improve conduct dispute resolution. Is there a problem, and if so, where? Levivich ^harass/_hound 21:34, 10 December 2020 (UTC)

• As I have written previously, there are challenges with collaborative, online decision-making:
  • A small number of voices can dominate conversation, drowning out others.
  • Circular arguments, repetition of the same points, and irrelevant information, including overly-emotional appeals and personal criticisms, cause people to lose attention.
  • Agreeing upon appropriate criteria to bring the discussion to a conclusion can be difficult.
• English Wikipedia's unmoderated discussions have additional challenges:
  • Participants can write unduly long responses that in a face-to-face conversation would be controlled through appropriate interruptions.
  • At any given time, immediate responses are only possible by those in neighbouring time zones. This reduces the efficacy of dialogue.
• Also the voices heard are only a small, self-selected sampling of the entire community. Even amongst those who are aware of the conversation and are motivated to participate initially, there is a large percentage who do not have sufficient interest to maintain engagement throughout the entire discussion.
• I've also written about the problems with using consensus as a decision-making approach in a large group. When an entire group is strongly aligned in its goals, consensus decision-making can be effective in maintaining a unity of purpose. Unfortunately, as a group increases in size, it also becomes increasingly unlikely that all members will be strongly aligned. Consensus decision-making favours those who are less accommodating over those who are more accommodating, and so Wikipedia's discussion environment selects for less collegial editors over more collegial ones. Asking for proof with on-wiki diffs that it is the more collegial editors who are leaving is a catch-22: first, it would not be collegial to discuss someone else's lack of social graces; second, most people who stop posting to a web site just do so, without bothering to tell anyone about it.
• Wikipedia's group-discussion process gives additional weight to the most outspoken editors and gives incentive for uncollaborative behaviour. As I've discussed at User:Isaacl/Community/Fostering collaborative behaviour and User:Isaacl/Community/Content dispute resolution toolbox, we should be trying to craft our processes and procedures so they reward desired behaviour, and make undesirable behaviour a losing strategy. For example, providing mechanisms to resolve content disputes in a semi-binding way (perhaps with a revisit respite) would encourage everyone to work towards a best-compromise solution, as opposed to trying to win through repetition and participant attrition. Improving content dispute resolution so it is more effective and doesn't reward poor behaviour will reduce the need for conduct dispute resolution. isaacl (talk) 22:22, 10 December 2020 (UTC)

I think "not very well" is a fair summary. I've been looking at two difficult situations recently. I don't feel like we have a system that handles either.

• Situation one: Two editors disagree with each other. Both have been blocked for edit warring; one has gotten in trouble for socking. The main pattern seems to be that Editor 1 tries to add content and/or a source to an article, and Editor 2 shows up to revert it and to say that everything Editor 1 does is wrong. For example, Editor 2 will declare that Editor 1's source is wrong because a different source holds a different POV, or that Editor 1 misrepresents the source by writing in his own words instead of posting a copyvio from the cited source. In one recent dispute, a book was quoted that said something like "<subject> has four parts, namely 1, 2, 3, and 4", and Editor 2 went on at very great length about how the source does not say that either 3 or 4 have any connection whatsoever to <subject>. If he weren't so loud and angry about it, multiple times over, you'd have laughed over that, because the alternative is to cry and then earnestly recommend that he talk to his doctors soon. I've started wondering this week whether there is some real-world professional bad blood between these two people. There doesn't seem to be a way to make them stop.
• Situation two: An editor tries very, very, very, very hard. He is also very, very, very, very literal-minded. He really, truly, absolutely does not understand why people are upset with his editing, which mostly seems to involve blanking verifiABLE, already-cited, and otherwise suitable and appropriate encyclopedic content on the grounds that the sources are, in his opinion, "unreliable" for anything at all. His idea of "unreliable" sources includes more than one source that is listed at Wikipedia:Reliable sources/Perennial sources as being generally reliable. I think it may be a case of black-and-white thinking: if scholarly sources and mainstream news media are generally reliable for most/general purposes, then that means that almost all other sources (e.g., primary sources, government reports, commercial websites, sources speaking about themselves, etc.) must be unreliable, right? He genuinely does not seem to understand why people yell at him. He also seems to expect that if you tell him to stop doing ____, then you will list absolutely every single possible reason why ____ is bad and against policy. If he understood and agreed with the reasons, then I think he'd stop, but I haven't actually seen that yet. I've only seen him tell everyone that they are bad and wrong and that Policy Says™ that he should keep blanking already-cited content left, right, and center, and that anyone who wants to restore it needs to cough up sources that meet his idea of reliability. Also, If you only tell him the top three reasons, and he doesn't agree with one or more of them, then he'll continue screwing up articles and will be upset when you point out that there are 97 other reasons why he should stop it. You're supposed to present all hundred arguments the first time and repeat all of them each round, as if it were a Lincoln–Douglas debate format, or they don't count.

In the first situation, I don't know how to stop it. In this specific case, there's a chance that the two editors know each other, so they might be able to settle this themselves, off wiki. What we need, however, is something that changes the incentives.

In the second situation, we may be dealing with the limits of Wikipedia:Competence is required, and maybe we just need a somewhat less sympathetic or optimistic admin corps. OTOH, it's never any fun to play the heavy in these situations. Nobody relishes telling an editor that we know he doesn't understand why people are upset, we know he has not received an explanation that will ever WP:SATISFY him, we believe that he'd be willing to change if only he could understand – but he can't, so we're showing him the door.

Maybe someone else has better ideas. WhatamIdoing (talk) 04:21, 16 December 2020 (UTC)

These situations with recalcitrant editors are why I don't like to edit articles that don't have a lot of watchers or an active associated wiki project. Every edit has the sword of Damocles hanging over it: without warning it can turn into a protracted, seemingly endless discussion, no matter how trivial the edit. And even when there is an active associated wiki project, if you can't draw their interest in responding to the discussion, the conflict will remain unresolved. Both of these cases could bebefit from a revisit respite to reach a semi-binding resolution. This would free up the other editors, while unfortunately imposing an added burden to the closing administrator. I know no one like to tell someone a difficult truth; I don't like to do it either. But uncooperative editors is one of the key reasons I have difficulty getting motivated for editing articles, and I'm sure I'm not the only one. If we can't deal with editors unsuitable for collaborative projects, then we continue to provide incentives for poor behaviour rather than desired behaviour. isaacl (talk) 20:51, 16 December 2020 (UTC)

• I think that ANI could benefit from more structure. Rules like those used at DRN and AE would make it easy to clamp down on unproductive cross-talk and mudslinging, as well as making discussions easier to parse at a glance and thus reducing the amount of discussions that go stale without resolution. It can sometimes be unclear whether an admin is a party to a conflict or offering opinions as a neutral arbiter: a more formal demarcation of roles in a given discussion would help clarify the process for editors with grievances and save potential closers from potential flak. _signed, Rosguill ^talk 05:58, 17 December 2020 (UTC)

Discussion about the format of this discussion

Er, surely the purpose of VPI is to formulate a proposal by throwing ideas around? Once you've got your proposal beyond the draft stage, you can transfer it to WP:VPR (or similar) for the actual RfC. Therefore, an RfC shouldn't be held yet, and when it is, it won't occur here. --Redrose64 🌹 (talk) 08:43, 11 December 2020 (UTC) An RFC doesn't have to be a proposal; it can be just a request for comments. I thought this was the best place to have this discussion. If you want to remove the RFC tag or move this elsewhere, I don't mind. Levivich harass/hound 21:23, 11 December 2020 (UTC) I didn't say that an RfC couldn't be just a request for comments. But under #Questions to consider you ask two questions, and the purpose of VPI is to discuss what questions should be asked, and how they should best be worded - but these have all the appearance of being the actual finalised questions for the RfC; if they are, it's a VPR matter. Also, WP:RFCBEFORE advises that a preliminary discussion be held before the RfC tag is placed, since it may be resolvable without making it formal. I can't find where that preliminary discussion took place. --Redrose64 🌹 (talk) 00:09, 12 December 2020 (UTC) I don't understand what you're saying. Feel free to change it to whatever you think it should be. Levivich harass/hound 00:24, 12 December 2020 (UTC) I'm saying that if you have already decided what the questions should be, this is the wrong place to invite answers to those questions; but if you are still formulating the questions, it's too early for an RfC. --Redrose64 🌹 (talk) 08:07, 12 December 2020 (UTC) Personally, I think the idea lab is a reasonable place for brainstorming,(*) and seeding brainstorming with some open-ended questions is a commonly-used approach. As to whether or not using the RfC notification process is desirable for brainstorming discussions: well, it might become unwieldy if there were too many of these types of discussions. (*) I appreciate why some feel that other venues such as user space pages are more suitable for collating people's thoughts and focusing them into more concrete proposals, and that even initial brainstorming could be done that way. But it's also hard to keep discussions going in more obscure locations, so I wouldn't want to insist that all brainstorming must take place elsewhere. isaacl (talk) 20:38, 12 December 2020 (UTC) I removed the RFC tag and seed questions, updated the headers and my comment, and collapsed this part of the discussion. Levivich harass/hound 07:34, 14 December 2020 (UTC)

Should the scope of G6 be limited?

According to WP:CSD, G6 is for articles that have to be deleted for "uncontroversial maintenance," but I have seen in various instances G6 being used as a sort of catch-all. I have seen it used to delete pages that would better fit deletion by G3 (such as Wikipedia:Articles for deletion/Sun (2nd nomination)), R3 (Neelix's redirects; technically deleted per X1 an extension of G6), used because a "joke is getting stale" (see Wikipedia:Articles for deletion/Wikipedia:Articles for deletion/Wikipedia:Articles for deletion/Wikipedia:Articles for deletion/Wikipedia:Articles for deletion/Wikipedia:Articles for deletion/Wikipedia:Articles for deletion) and used as an IAR extension. I'd like to ask for your opinions on limiting the scope of G6 in order to make it more accurate to its name: "technical deletions," by restricting it to articles that have to actually be deleted for maintenance reasons. JJP...MASTER!_{[talk to] JJP... master?} 15:33, 13 December 2020 (UTC)

Are there any pages that are being deleted that shouldn't have been? If not, I'm not sure I see the point of this proposal. While in an ideal world we'd always get the summary right on speedy deletions, because they're uneditable once made (other than blanking them as a last resort) and because speedy deletion means selecting reasons from a fiddly drop-down menu where even the most experienced admin sometimes clicks the wrong item, the occasional speedy deletion with an incorrect code in the log is just a fact of Wikipedia life; it makes no actual difference whether a piece of obvious disruption like Wikipedia:Articles for deletion/Sun (2nd nomination) shows G3, G2 or G6 in the log. ‑ Iridescent 15:51, 13 December 2020 (UTC)

by restricting it to articles that have to actually be deleted for maintenance reasons how do you propose doing this? Restricting to articles is bad, I’ve made many G6 tags for other pages, indeed most of my G6 tagging is in other namespaces. But assuming you meant page, not article, isn’t this just a technical rewording? G6 has a large scope, it is not really possible to make any tangible change in the way you suggest, at least not that I can think of. ProcrastinatingReader (talk) 16:31, 13 December 2020 (UTC)

If you are requesting that G6 be split into two new criteria, one for uncontroversial technical deletions and one for uncontroversial deletions not covered by another criteria, that might be fair to discuss. But as long as admins put the actual reason in the deletion log, I'm not seeing a problem here. On the other hand, if you are saying that some deletions now done under G6 shouldn't be done under any speedy-deletion category, this will require a longer discussion. On the third hand, if you are saying that sometimes administrators "push the G6 button" when the meant to push a different one, well, admins are only human, or at least a human is responsible for their actions if they are bots. davidwr/(talk)/(contribs) 🎄 18:58, 13 December 2020 (UTC)

Exactly. Since the two examples you give were unquestionably correct deletions (no sane person is going to claim that The Sun magically exploded into a planetary nebula 29.5 days ago. Even if it did not explode, it would not be notable per WP:NSTAR and WP:NOTSTARGUIDE. Maybe a redirect to Star or Supernova is the only solution is something we somehow need to keep), it doesn't really matter what the entry in the deletion log says provided it's not actively misleading; it's not like we have quotas of each deletion criterion to meet and mislabelling two deletions as G6 is preventing G3 from reaching its target. If you're claiming there's an issue, you really need to provide examples of pages being deleted under G6 that didn't qualify for speedy deletion. ‑ Iridescent 19:10, 13 December 2020 (UTC)

• I comment on this perennial proposal every time it’s raised, but no, it shouldn’t be split. My personal favorite use of G6 is to delete SPIs like Wikipedia:Sockpuppet investigations/175.116.243.212 (an SPI listing a bunch of dynamic IP addresses), and anyone who is active in the more behind the scenes areas likely has encountered something similar in the area where they work where there is no reason to send something to MfD and deletion would be appropriate.
  Also, as an aside about one of the examples, deleting unfunny April Fools AfDs under G6 has become a tradition just as much as the day itself... TonyBallioni (talk) 06:38, 14 December 2020 (UTC)
• I echo some of the "so what?" mentality noted above. There's some overlap among CSD rationales, which is a feature, not a bug, of the system. The OP has failed to show how G6 is being used to delete pages that should otherwise have never been deleted, which means there is no problem to solve as far as I can tell. If it could have been deleted under another rationale, but G6 was cited instead, who cares? --Jayron32 12:45, 22 December 2020 (UTC)

Idea for a new protection level

I think that Extended Confirmed protection is too over-powered. All it takes is some random saps to vandalize a Semi-protected page to get it extended confirmed, which stunts growth, and only lets very active and experienced editors to edit, which limits the number of editors. I'm thinking of a new protection level, in between of Semi-protection and Extended confirmed. Is this needed, and what should be the criteria? Arsonxists (talk) 17:46, 15 December 2020 (UTC)

In most cases like this, pending changes coupled with semi-protection is probably easier to do that creating a whole new protection level. However, the rules surrounding pending-changes protection may need to be looked at to see if they meet the needs. Pending Changes Protection is one of those things you don't really want to use "out of process" (i.e. by invoking WP:Ignore all rules) if you can help it. While this "don't invoke WP:IAR unless you absolutely have to (but DO use it when it's called for)" applies to all policies, the past history of pending changes makes it even more of a minefield in that area. davidwr/(talk)/(contribs) 🎄 19:18, 15 December 2020 (UTC)

I agree with you on the pending changes. About the new protection level, it's not about taking one single page, and creating a new protection level for it, and just FOR it, is not what I am saying. I was making this so, with an Extended Confirmed padlock on it, for a page which could use a lower level lock which doesn't exist yet, but semi-protection is too low, the new protection level could fix the problem. I think alot of pages have that problem. Arsonxists (talk) 20:48, 15 December 2020 (UTC)

Arsonxists, I don't see how adding another level between semi and ECP is going to be useful. The problem is, once you get too many fine gradations, it's dang near impossible to figure out which is the right one, so application becomes essentially random, and we're already there. Between semi, pending, ECP, and full, there's more than enough choices. -- RoySmith (talk) 14:45, 16 December 2020 (UTC)

From my understanding it sounds like y'all are suggesting something like Pending Changes Level 2 (aka orange lock) which takes the current Pending Changes (formally known as Level 1) but kicks it up a notch to become a protection level between Semi-protection and Extended-confirmed protection. Essentially PC Level 2 flagged every edit on a page as needing reviewed. Only Reviewers & Administrators could have their edits go live without review after reviewing previous edits on a page. PC Level 2 could be used in conjunction with Semi-protection & Extended-confirmed protection. So in the levels of protection (in theory) it would have been PC Level 1, Semi-protection, PC Level 2, PC Level 2 + Semi-protection, Extended-confirmed protection, PC Level 2 + ECP, Template protection, Full protection if everything was adopted. This is how it appears in chart form. Again in theory, if PC Level 2 + ECP was applied then the Reviewer would also need to be Extended-confirmed to reject a pending change (since that would technically be a revert of the page.) Since Level 2 never reached a consensus on how to use it, in any configuration, the setting was removed at the software level so it wouldn't show up as an option to administrators. While some may argue a need for another level of protection I highly doubt a consensus could be reached today about using Level 2 of Pending Changes Protection since a lot of people at the time didn't feel we needed a protection level between Semi-protection and ECP. Alucard 16_{❯❯❯ chat?} 09:51, 17 December 2020 (UTC)

If I may flip the question around, why not just lower the threshold for Extended Confirmed user rights?. If 30/500-in-any-space were taken down to say, 24/240-in-mainspace then high quality editors would be able to prove themselves pretty quickly and edit semi-protected pages without restrictions getting any more granular. Would that let through too many people too quickly? If so then I'd object to a protection level for that reason. If not then I'd opt for lowering the EC threshold as a simpler solution. --Paul ❬talk❭ 15:07, 30 December 2020 (UTC)

• I think this entire argument is predicated on a false assumption; the OP has claimed All it takes is some random saps to vandalize a Semi-protected page to get it extended confirmed, which stunts growth, and I can see absolutely no evidence for this. Here's every page currently under ECP; the overwhelming majority are articles on Israel/Palestine, the India-Pakistan conflict, and antisemitism & Poland (on all of which the ECP is mandated by Arbcom and consequently it would take an arb case to get them lifted). Of the handful of those which don't fall into one of the arbcom-mandated topics, I'm not seeing a single one that doesn't fall into "highly contententious topic which people shouldn't be editing until they're very familiar with Wikipedia's rules" or "under sustained attack from multiple SPAs over the long term". Can any of the people calling for a lower protection level or a reduction in the ECP requirements give any actual examples of a page under ECP where you don't consider the ECP appropriate? (In my opinion, if anything we should be raising the threshold. 500 edits is trivially easy; just ctrl-f any common typo and you can rack up that many edits in half an hour.) ‑ Iridescent 16:28, 30 December 2020 (UTC)

I wasn't being particularly serious with suggestion of changing the threshold - just saying that it'd make more sense than an additional protection level. --Paul ❬talk❭ 18:24, 30 December 2020 (UTC)

"Suggest edit" button

It'll let you highlight/select some article text, type in what's wrong, add a source (via URl or whatever), and put an edit request on the talk page (so that semis, edit filters, spam url list, etc all work). Surely not an original idea. Proposed location: on Vector, in the tab row, between "Read" and "Edit", maybe with a tiny icon to get people to click on it; on Minerva, another icon next to the watchlist star (maybe a lightbulb?). Method of deployment: very slowly, using the blunt instrument of MediaWiki:Common.js, with only a few high-pageview articles at first (get consensus from most recent/top page editors?). Thoughts welcome. Enterprisey (talk!) 06:48, 21 December 2020 (UTC)

Probably should avoid doing something like this in Javascript... --Izno (talk) 08:08, 21 December 2020 (UTC)

It's a prototype, and will probably need to change a lot. Of course, we could go with the more usual workflow of having an actual "experiment" and doing A/B testing and other science in PHP over a multi-month period; indeed, if there's a PHP developer available who would like to step up and shepherd all that through, it would be a superior solution. I don't think any are available but would be happy to be proven wrong. Enterprisey (talk!) 08:15, 21 December 2020 (UTC)

I have a feeling this would turn into a turbo-charged variation on the Article Feedback Tool fiasco, which would end up flooding talkpages with hundreds of variations on "I love/hate topic" and "you should include obvious libel". The relatively low barrier to entry of the existing MediaWiki:Protectedpagetext screen has a dual purpose; as well as the obvious one of telling the person who wants to propose an edit what they need to do to propose it, it also encourages readers in this position to create accounts and points them towards assorted help pages that will (hopefully) help them figure out whether their suggestion is actually going to be one worth making. If you look at the talkpage of high-pageview articles like Talk:COVID-19 pandemic or Talk:Taylor Swift they already get hammered with good-faith cluelessness; if we end up creating a situation where we need to semiprotect the talk pages to stop them being flooded, the whole exercise would have been counterproductive.

What I would support without reservation is a change to the tabs such that in circumstances where the "view source" tab is displayed (semi'd pages to anons, full-protect pages to logged-ins) a second link to the talk page is displayed next to "view source", and preferably labeled something unambiguous like "discuss this page". The way Vector shows the tabs by default to IPs and new accounts (with "article" and "talk" on their own next to the death star, and everything else next to the search box) is quite unintuitive. I'm fairly certain most readers who look for the edit tab and can't see it because the page is protected aren't even aware that the talk page exists let alone know how to get to it, and that those who do notice the "talk" link are under the impression that it leads to their own talkpage and consequently never bother to click on it since they know that as an unregistered user they're not going to have any messages. (Minerva is such a mess that I'm fairly certain most readers aren't aware that any of the tabs exist.) ‑ Iridescent 08:39, 21 December 2020 (UTC)

Yeah, that'll probably happen with a free-form input field. Clearly I ought to review the Article Feedback data. That's my first talk page entry! What about a more limited set of options, like radio buttons saying "this fact is wrong and should be ___" or "this is irrelevant", perhaps not even with text fields? Or we could have no "what's wrong" section at all, and just an option to contribute one or more relevant sources in URL/ISBN/DOI/whatever form (which will of course be restricted client-side to avoid the usual suspects like Facebook/YouTube). The tabs change sounds like a good idea to me as well. I suppose it's too late to rename it to "discuss this article". Enterprisey (talk!) 08:57, 21 December 2020 (UTC)

AFT was limited options prior to its free form. Really, go look at AFT. --Izno (talk) 09:03, 21 December 2020 (UTC)

I had a look; seems different enough. Enterprisey (talk!) 09:17, 21 December 2020 (UTC)

AFT had multiple iterations; as our page name indicates today, it was version 5 that was finally put to rest. We had 2 or 3 iterations of forms-based options before that. --Izno (talk) 09:24, 21 December 2020 (UTC)

I had looked at all of them; I suppose I worded my comment imprecisely. I based my judgment off mw:Article feedback#Project history, which I think shows all of the versions. Enterprisey (talk!) 09:45, 21 December 2020 (UTC)

Because the WMF intentionally broke the links to the archives to make it hard to access them it's hard to put across just how much of a mess AFT was, but the very fact that they had to do this is an indicator. Even the earlier, form-based versions saw us flooded with variations on "Key fact missing from the article: he murders children and the international Jewish conspiracy covers it up". (If you're interested, the AFT archive is hidden here; to give a sense of scale, the limited experimental rollout of AFT generated 1.5 million comments.) It painted us into a corner where we had to choose which of "hosting libel indefinitely", "team of full-time paid moderators" or "literally delete the database" was the least antithetical to our values. ‑ Iridescent 09:52, 21 December 2020 (UTC)

OK, so no free-form text fields. Enterprisey (talk!) 09:56, 21 December 2020 (UTC)

Iridescent, that's an interesting point about the arrangement of the tabs. Redesigning that at a very fundamental level seems like something that should eventually happen, although I'm sure it'd get pushback since design change always gets pushback. The potential confusion about the fact that "Talk" is page-based rather than user-based is also very interesting—that's very big if true, and I'd be curious to see if anyone has looked into that.

Regarding the point about the potential pitfall of this feature, I'm inclined to agree. It could also end up discouraging more timid new editors from being bold and create massive backlogs. {{u|Sdkb}} ^talk 13:58, 23 December 2020 (UTC)

In my view there's a big jump from "this needs changing" to "I'll dig in and edit this". If we add a middle ground of "I'll suggest an edit", I think it's closer to the former than the latter (in terms of effort required/"activation energy"). That is, I agree this'll encourage some people to suggest edits instead of making them, but I think it'll be more than offset by others suggesting edits who wouldn't otherwise contribute at all. Enterprisey (talk!) 10:07, 24 December 2020 (UTC)

@Enterprisey: already not loving the idea of running anything heavy via common.js - perhaps something super tiny that adds a button/tab only - and that button/tab loads a withJS on-demand that we already have support for? But for something this big, it seems like you are really only going to be hitting desktop editors when I'd think a simplified workflow might be better used for mobile editors if you want to start putting in the effort. — xaosflux ^Talk 16:08, 23 December 2020 (UTC)

Yup, a button that loads a script was the idea. I agree designing for mobile editors is essential. I figure the highlighting part should transfer fine to mobile, but I really think we should collect something beyond that - not just a choice among "this is inaccurate/unreferenced/irrelevant" - to make the responding editor's job easier. I think requiring a source would work for that, although I guess research is a big pain on mobile. Enterprisey (talk!) 10:01, 24 December 2020 (UTC)

Merging WP:Move review and WP:Deletion review

Before I consider an RFC on the idea of merging WP:Move review and WP:Deletion review I'd like to get some input on the idea. In my opinion, Move review just doesn't work. Discussions there stay open for months -- see Wikipedia:Move_review#Coronavirus_disease_2019_(closed) which was opened Oct. 1 and closed Dec. 9 for one example -- meaning that the previous requested move becomes stale in the process. Participation at move review is also very limited. By my estimation, at least half of all participants in a typical move review also were involved in the previous request move and just rehash the same arguments again; for an extreme example, see Wikipedia:Move_review#Telephone_(game), which has been open more than a month and attracted a single uninvolved participant. To me, both those issues could be solved by merging move review to a page that gets more attention. WP:Deletion review seems obvious but there might be other suggestions as well. I'd like to hear what others think about the idea before going further. -- Calidum 21:24, 21 December 2020 (UTC)

• There certainly is some overlap (a retargeted redirect may end up an either review) and lack of participation issues but move and deletion review but I'm not sure if merging would be sensible (though I wouldn't really object) since more often than not DR and MR are different issues (deletion/merging involve inclusion policies while titling/primacy is very different) that said maybe it should be a discussion review in general? What about other discussions such as RFCs? Maybe discussions involving splitting/merging pages belong at DR though there is no guidance on that. Crouch, Swale (talk) 21:39, 21 December 2020 (UTC)
• Oppose. WP:DRV is concerned with the proper application of deletion policy, and as such plays a role as the highest court for content. WP:MRV is not close to that importance, and a merge would damage the standing and function of DRV. The low attendance at MRV could be read as a reflection of the unimportance of WP:RM, and if low attendance there is a problem, the answer is Wikipedia:Publicising discussions. If anything, WP:MRV could subsume the Close Review function of WP:AN. —SmokeyJoe (talk) 01:42, 22 December 2020 (UTC)
• Participation is one aspect, but DRV and MR involve application of, and thus expertise in, two different sets of policies that really don't overlap much (except WP:CONSENSUS and WP:CCPOLs I suppose?). So participants in one won't necessarily be interested in or helpful in the other. That said, I could see an arrangement where there is a "close review" page (pulling that function out of AN), and DRV and MR are sub-pages of that page. But that seems like re-arranging deck chairs to me; I'm not sure if it's more than a cosmetic change. Separate and apart from that, I am totally in favor of outright banning participants in RMs/AFDs from participating in resultant MRs/DRVs, to reduce the re-hash. Levivich ^harass/_hound 08:00, 22 December 2020 (UTC)
  • The advantage of pulling close reviews out of WP:AN is a structured archive of the reviews. —SmokeyJoe (talk) 10:11, 22 December 2020 (UTC)
• Oppose Think it's a really bad idea that we should not really develop into anything further for reasons I will elucidate shortly, but I definitely and in no way am voting Oppose because I was told we don't do that here Article titling concerns and article existence concerns are mostly orthogonal. Fail to see the need for this or the problem it hopes to solve, other than "low participation". --Jayron32 12:42, 22 December 2020 (UTC) slight edit per comment below --Jayron32 20:09, 22 December 2020 (UTC)
  • I just felt I had to compliment you for sneaking orthogonal into a message Nosebagbear (talk)
• Firstly, guys, this is the IDEAS section, and we're specifically asked not to go in with the oppose/support thing. I do think the responsibilities are distinct enough that I would not like DRV (covering a field I am very experienced in) being cluttered with Move Review issues. I imagine the few who are very active in MR might share that issue. I am perhaps less worried by the "deck chair" bit on bringing them under a central umbrella - that isn't me saying it's a good idea, but I think it's a possibility warranting additional discussion Nosebagbear (talk) 17:10, 22 December 2020 (UTC)

  Sorry. I have amended my comment so it is no longer in contravention of the rules of this board. Mea culpa. --Jayron32 20:09, 22 December 2020 (UTC)

  • If this is about “ideas”, then the OP should discuss the problem, and not lead with a single suggested solution, let alone title the section with that idea. If the problem is low participation, then WP:Publicising discussions is the answer. —SmokeyJoe (talk) 22:09, 22 December 2020 (UTC)

• Popping move issues into DRV may garner more participation, but not necessarily more valid participation. Many DRV regulars are not familiar with RM-related policy, so it may not lead to good outcomes. DRV is pretty much only capable at handling article deletion reviews. Even when straying outside that into other namespaces DRV's weaknesses start to shine (eg DRV regulars aren't really well placed to address module deletion issues), so adding in move discussions is a bit of a stretch imo. ProcrastinatingReader (talk) 20:15, 22 December 2020 (UTC)

Auto-generating list articles from Wikidata?

I recently came across List of people named David, which has over 2000 people (including disambiguation pages) linked. It seems to me that this might be easier created and maintained using Wikidata. Well, is it possible with Wikidata now, or do we need to wait for Abstract Wikipedia / Wikifunctions to be ready to do so? If it is possible, how concerning are the Wikidata accuracy issues for a list like this; references aren't really necessary to prove that the articles named "David so-and-so" are about people named David. power~enwiki (π, ν) 22:54, 22 December 2020 (UTC)

Generating a page can be done today out of mainspace using ListeriaBot, but there is at least one consensus on the books specifically banning the practice of automatic upkeep. --Izno (talk) 23:33, 22 December 2020 (UTC)

• Regarding the specific example, why do we need a page for List of people named David at all? It seems the only purpose it'd serve would be as a navigational aid, but no one is actually going to use it for that. Looking at WP:LISTN, people who share nothing but the same first name aren't really discussed as a group. There are 26 pages in Category:Lists of people by given name, and I'd be interested to see what'd happen if they got AfDed as a group. {{u|Sdkb}} ^talk 13:33, 23 December 2020 (UTC)
  • It's a split for size from David (name); for less common names (Millicent, Arnold (given name)) they're included on a page about the name itself. Having these lists also decreases the number of WP:ORPHAN articles, though it's arguable whether doing so in this way is a good thing. power~enwiki (π, ν) 22:41, 23 December 2020 (UTC)
    • Sure but we could also create an article List of all orphaned articles which would also decrease the number of WP:ORPHAN articles. — GhostInTheMachine ^{talk to me} 22:47, 23 December 2020 (UTC)
      • I've got a draft in my #6 sandbox, User:Davidwr/sandbox6 (permalink) davidwr/(talk)/(contribs) 🎄 00:06, 24 December 2020 (UTC)
• Regarding the more general point, yes, absolutely. I was recently wondering about building lists off of a combination of categories and Wikidata, but if the category system will eventually get migrated to Wikidata, as I've seen Rhododendrites predict, then it's better to just go directly there. There's a lot of editor effort wasted doing things that bots are perfectly capable of—the problem is that it's easier to get 10,000 people to spend a minute each to list a page they care about (=150+ hours) than it is to find someone with the requisite technical skill willing to spend a few hours to set up a system to automate everything. {{u|Sdkb}} ^talk 13:33, 23 December 2020 (UTC)
• This has already been rejected multiple times. * Pppery * _{it has begun...} 18:04, 31 December 2020 (UTC)

Proposal to change the username policy's section on impersonation

Alright, so I found out that the user by the name Billie Eilish - Baby Shark was indefinitely blocked due to a username violation, however I do not believe that that was justified. Not that the block itself was unjustified, but that the reason was unjustified. I believe that it is clear that this user's username implies that it means "Baby Shark by Billie Eilish", as opposed to an attempt to impersonate Billie Eilish, and their user page attested to that fact, but they were still blocked due to the fact that their username merely contained the name of a famous person. I would like to ask for your thoughts on if this username block was justified, and if the policy should be changed to more explicitly prohibit blatant attempts to impersonate a person. Please note that I am not requesting an unblock for the user, but I am requesting a change in the policy, in order to make it more accurate to its intention: to prevent impersonation. JJP...MASTER!_{[talk to] JJP... master?} 02:16, 25 December 2020 (UTC)

Looks like a good block to me. We couldn't change this aspect of the username policy even if we wanted to, since it's a legal issue and as such comes from the WMF rather than the community. The purpose of that section of the username policy isn't to prevent "blatant attempts", it's to prevent potential confusion; even if the username is entirely in good faith we still block. Even if this person's name genuinely was "Billie Eilish" we would still block unless there was something to make it clear they're unrelated, and that's how it should be. ‑ Iridescent 17:39, 25 December 2020 (UTC)

Wiki App Idea

Hi, 

This might be a bit if a stretch or currently already underway, but...

What if there was a way you could mix the camera on your phone (like how live cameras translation of another language operates) with wikipedia's vast database of information to help people identify things of the unknown should they stumble across it and think "I wonder what that is"? 

Basically it would be like the Pokedex from pokemon which is used to identify a pokemon unknown to that person but would be of use with things on earth here today, plants, animals, items, the works! Everything! 

If a user stumbled across something completely original with no information then they could somehow be involved on the information that would pop up, 

I.E discovered by John Doe 11/11/2020 and it would bring up or update areas where they were found,

The camera would also have the geotagging function should users want to share the location of their findings, 

Anything unknown would automatically send location information to the wiki/app who could send out someone capable of investigating/studying the unknown.

A reward of some kind for original discoveries would see increased use of the app and encourage others to share the app to explore and find other things.

The app itself would cost roughly $20 to download which would really be no huge cost considering the ease of identifying things you aren't familiar with, unless it's a new discovery which would put them first inline for the information discovered after examination and analysis. 

Chemicals and probably a few other things would be tricky to identify considering it would rely on the camera talking to wiki to recognize what the user is seeing but 3d objects and most other things with distinct colors/patterns/shapes should work well, 

With roughly 7 billion people on the planet and an ad on the site encouraging people to download the new app i reckon there would be at least 1 billion users in the first 5 years based on word of mouth and the constant daily searching from users who would see the ad encouraging them to download it. 

Is this a possibility? 

Thanks for your time, 

Nathan. M — Preceding unsigned comment added by 122.62.77.220 (talk) 21:36, 29 December 2020 (UTC)

What reason would there be for someone to pay for this, when anyone can just use Google Lens for free, which runs on servers that are orders of magnitude faster than anything we could hope to achieve, and which has the overwhelming advantage of being operated by a company that already has every image on the internet archived, tagged and sorted, and where anyone who for whatever reason objects to Google can use the (inferior, but still better than anything we could do) CamFind for free? ‑ Iridescent 22:15, 29 December 2020 (UTC)

Aside from this being just generally redundant, 7 billion people doesn't mean 7 billion smart phone users, let alone that many people willing to drop $20 on any app no matter how good. --Paul ❬talk❭ 21:36, 30 December 2020 (UTC)

Making disclaimers more prominent

Is there any way that the Disclaimers, which are now at the very bottom in small font, can be made more prominent, particularly on the main page? I think this is perhaps the most important information for readers to see about Wikipedia, particularly the Content disclaimer. Many readers and drive-by editors will complain about spoilers, blasphemy, obscene images, and similar things. They are often referred to the disclaimers as a reason this is okay, but few readers will ever see the disclaimers unless they are specifically directed to them. Readers should have the option to turn away from Wikipedia if, for some reason, there is content which they do not want to see. This is particularly important given that Wikipedia is a global encyclopedia; although many of us in the Western world are used to seeing such content and are not particularly disturbed by it, people from other cultures may have other reasons, such as religious obligations, to avoid such material. We need not just our content, but also its presentation to benefit all our readers. As for better placement of the disclaimers, I would suggest going as far as putting a link under "The free encyclopedia that anyone can edit". If not placed there, the disclaimers could go lower on the main page, or on the sidebar. —Naddruf (talk ~ contribs) 21:42, 30 December 2020 (UTC)

Hmmm, I think one could argue that "The free encyclopedia that anyone can edit" essentially is the disclaimer, whereas The Disclaimer merely elaborates on it. I don't know if making it more prominent will necessarily encourage that many more people to read it. Plus I think it's worth presenting Wikipedia "as is": we don't advertise, we don't look flashy, we don't really do anything to draw people in, any decision to use wikipedia is very freely made - I'd be concerned that any degree of dressing, even in the form of a reader's advisory would detract from our dry intentionally-boring vibe that makes us kind of unique. --Paul ❬talk❭ 21:59, 30 December 2020 (UTC)

I'm sceptical that many people bother with disclaimers (wherever we place them), but hopefully, some do, and we won't know because if so they don't complain about stuff in the disclaimers. Some obviously complain even if they've read the disclaimers, because higher truths. "The free encyclopedia that anyone can edit" (on the mainpage) is like Paul says something of a disclaimer in itself, but putting them under Other areas of Wikipedia wouldn't hurt I guess. As for sidebar, there's a "About Wikipedia" there. Gråbergs Gråa Sång (talk) 22:30, 30 December 2020 (UTC)

@Paul Carpenter and Gråbergs Gråa Sång: I am very specifically talking about the WP:Not censored aspect, which comes with the content disclaimer. The fact that there may be errors or misinformation is a given from "The free encyclopedia that anyone can edit". However, readers need to be aware that they may see images of naked people, they may see criticism of their religion, they may see things that children should not see; and that if they don't want to see this, they should avoid Wikipedia or be careful what they look at. It is common for certain types of material in public view to be censored in some way, and the fact that Wikipedia doesn't do this needs to be pointed out. For example, there are 1.8 billion Muslims worldwide, and a large number, if not a majority, believe that Muhammad should not be pictured. Nevertheless, there are pictures of him at our article Muhammad. Over the years, hundreds of people have commented asking that the pictures be removed, but they are still there. So if Wikipedia is going to do something that goes against the beliefs of 10% of the world population, it should make it more clear that this is allowed on Wikipedia by making the policy about this more visible. —Naddruf (talk ~ contribs) 22:44, 30 December 2020 (UTC)

One wonders which sort of math would lead one to conclude that 1.8 billion Muslims equal only 10% of the world population.

M Imtiaz (talk · contribs) 22:49, 30 December 2020 (UTC)

@M Imtiaz: Not all Muslims think images of Muhammad are that bad, I don't know how many do. —Naddruf (talk ~ contribs) 23:43, 30 December 2020 (UTC)

And I think the number of complaints will be about the same regardless of where we put the disclaimers. Presumably, in this day and age, many people are told about this by parents and teachers. Yes, WP has all kinds of stuff on it, it's like the rest of the internet in that way. Gråbergs Gråa Sång (talk) 23:17, 30 December 2020 (UTC)

Isn't that already covered by the fact that this is an encyclopedia? Encyclopedias cover the world: good, bad, and indifferent. They describe reality. If the reader can't handle reality, that is their problem, not ours. And, as far as things that go against religious beliefs, why would anyone think that anything that is not run by their religion would be constrained by it? --Khajidha (talk) 22:59, 31 December 2020 (UTC)

The people who are upset that we insulted their religion or that they see an obscene image aren't going to stop complaining just because a legalese disclaimer is shown more prominently. This will not solve the problem you mention, but what it will do is make the UI even more bloated and inaccessible. ProcrastinatingReader (talk) 23:19, 30 December 2020 (UTC)

@ProcrastinatingReader: If it is useful, it does not make the page more inaccessible. This would be more useful than the side links to "related changes" and "page information", and it could be easily added on the main page under "Other areas of Wikipedia" without making anything more bloated. —Naddruf (talk ~ contribs) 23:43, 30 December 2020 (UTC)

I click "page information" lots of times each day. I don't recall the last time I clicked disclaimers. I couldn't tell you from memory what they say. I have an idea of what it says, and I don't really care, it's functionally useless to me and it appears to exist just to cover legal's backside. ProcrastinatingReader (talk) 23:48, 30 December 2020 (UTC)

I cannot imagine why a casual (not-procrastinating) reader would ever click on Page Information, but that is a separate issue. Anyway, that side bar is already more than long enough without adding another thing that no-one is going to read. If this were going to solve any kind of problem, then you'd need a way to prompt them to read it, but for 99% of users that would just be getting in the way. And I honestly don't think that a few people occasionally complaining is representative of the almost 10,000 people a day who view the Muhammad article (of whom I would guess a sizeable portion are from a Muslim background). --Paul ❬talk❭ 09:01, 31 December 2020 (UTC)

Naddruf, many things can be useful on the main page (and in many other places). The better question is: "is it effective". And that seems highly doubtful. —TheDJ (talk • contribs) 14:07, 31 December 2020 (UTC)

• I think it's worth discussing how to make the make the disclaimers a little more prominent. Putting it somewhere on the main page might get support if you come in with a well-articulated argument and a sandbox design in hand so people can see what it'd look like. However, asking for it to be added to the left sidebar or to the top of the main page just below the tagline is not likely to succeed. {{u|Sdkb}} ^talk 19:03, 31 December 2020 (UTC)
• Overall, I have sympathy with the idea of making disclaimers more prominent. This might be especially valuable for medical articles - there is a Wikipedia: Medical_disclaimer, but one does not see it on many articles on medical topics. Vorbee (talk) 11:52, 1 January 2021 (UTC)

What could be stripped from the side bar?

In the spirit of having less stuff on every page, I think that the tools section of the sidebar could be stripped down. Especially for logged-out readers. This small change would then allow for a tiny bit more whitespace, but every little helps. I've marked in red below the items that I think we can do without from the 'Tools' section. --Paul ❬talk❭ 09:31, 31 December 2020 (UTC)

Link	useful to a reader?	useful for most editors?
What links here	maybe?
Related changes
Special pages
Permanent link	for someone	accessible in history
Page information
Cite this page	I guess	I guess
Wikidata item	for someone
Download as PDF	I guess	I guess
Printable version	I guess	I guess

• Have you tried turning off "Use Legacy Vector" in your preferences ? Cabayi (talk) 09:42, 31 December 2020 (UTC)

Me personally, or the reader being discussed? The latter doesn't have a preferences screen unless they make an account. Either way changing the skin doesn't change amount of items in the Sidebar. --Paul ❬talk❭ 09:48, 31 December 2020 (UTC)

"changing the skin doesn't change amount of items in the Sidebar" - so that's obviously a No then. Cabayi (talk) 09:58, 31 December 2020 (UTC)

It really doesn't! I just tried a couple of times to it to make sure. The contents of the side bar is the same with any choice of skin. --Paul ❬talk❭ 10:04, 31 December 2020 (UTC)

• There was a large, recent RfC seeking to strip and reorganise the sidebar. I believe its results are the perfect example of how active editors' needs – a tiny minority of Wikipedia's users – tend to be disproportionately favoured over readers' needs, because active editors, almost by definition, are the only ones who contribute to these discussions. Thus links virtually useless to readers (Permanent link) were retained, mostly because experienced editors didn't want to lose a precious click, and links that might be of interest to readers (Featured content) were removed instead. However, as part of mw:Reading/Web/Desktop Improvements, the Tools section is proposed to be moved out of the sidebar into a dropdown tab, akin to View history, which I think would be a good compromise. – Teratix ₵ 10:32, 31 December 2020 (UTC)

Yeah that does sound like a good compromise. And a very precise description of the issue at hand, the reader does get forgotten way too easily, see above. --Paul ❬talk❭ 10:36, 31 December 2020 (UTC)

Yep, I think the RfC moved us forward, but overall I very much agree with Teratix. Here's the specific section where I proposed collapsing the tools section by default, which failed.

Also, if we're on the topic, there were some consensuses reached at the RfC that haven't been implemented yet. The ordering of the tools section is one; it has long bugged me that "Page information" isn't the first link as would seem logical, and we agreed to change it here. There's also moving the "cite this page" to the print/export section, which I think got stuck when T255381 was incorrectly closed, the section ordering switch, and some other stopgap measures that need adjustment as they don't work on all pages. All of these things are just stuck somewhere in the backend, and getting them done would be at least a small plus. {{u|Sdkb}} ^talk 19:19, 31 December 2020 (UTC)

@Sdkb: last I checked, the ordering of the items in the "tools" section is not customizable here without ugly javascript hacks (c.f. mw:Manual:Interface/Sidebar) so changes would be for everyone, not just enwiki - and an enwiki want to change something like this isn't usually enough to force a global change. An better option may be to request that the software be updated regarding MediaWiki:Sidebar, allowing the subsections of TOOLBOX to be configured locally. You could request something like that at phab (WP:BUG). — xaosflux ^Talk 16:45, 1 January 2021 (UTC)

Tools/systems for better catching inappropriate external links within article bodies

I make fix edits like this fairly frequently, removing external links that have been inappropriately placed within an article body. Do we have any tools or filters that patrol for this sort of thing? If not, could we develop them? {{u|Sdkb}} ^talk 20:20, 31 December 2020 (UTC)