Jump to content

Wikipedia:Village pump (idea lab): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
No edit summary
Tags: Mobile edit Mobile web edit
Line 626: Line 626:
::As long as you attribute it correctly, you're free to reuse the content of Wikipedia in any way you want—you don't need to ask permission. (See [[Hellingly Hospital Railway]] for an example of a spoken article at Featured Article level—note the discreet link at the top next to the FA star.) I can tell you now that the drawback to what you're proposing—and the reason [[WP:WikiProject Spoken Wikipedia]] never worked—is that the articles in which people tend to be most interested, are precisely those articles which change most often, and nobody wants to commit to re-recording a new version every few days. (Plus, the people who would most benefit from spoken-word Wikipedia—the visually impaired and those who have difficulty reading—generally would prefer to use screen-reader software where they can adjust their preferences to suit regarding the accent, the speed of the reading, how it handles images, and searching for a particular part of the text, rather than a set of spoken-word recordings.) ‑ [[User:Iridescent|Iridescent]] 08:50, 14 January 2021 (UTC)
::As long as you attribute it correctly, you're free to reuse the content of Wikipedia in any way you want—you don't need to ask permission. (See [[Hellingly Hospital Railway]] for an example of a spoken article at Featured Article level—note the discreet link at the top next to the FA star.) I can tell you now that the drawback to what you're proposing—and the reason [[WP:WikiProject Spoken Wikipedia]] never worked—is that the articles in which people tend to be most interested, are precisely those articles which change most often, and nobody wants to commit to re-recording a new version every few days. (Plus, the people who would most benefit from spoken-word Wikipedia—the visually impaired and those who have difficulty reading—generally would prefer to use screen-reader software where they can adjust their preferences to suit regarding the accent, the speed of the reading, how it handles images, and searching for a particular part of the text, rather than a set of spoken-word recordings.) ‑ [[User:Iridescent|Iridescent]] 08:50, 14 January 2021 (UTC)
:{{re|Masterpiece Reader}} as they said above, and you don't need to include donations links (though WMF won't mind donations!) see [[Wikipedia:Reusing Wikipedia content]] for guidelines on how to license and attribute the work. One thing you can do in any links is to specify the version that you dictated, on a page click on the "Permanent link" link on the left sidebar to have a link to a point-in-time version if it will help you. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:56, 14 January 2021 (UTC)
:{{re|Masterpiece Reader}} as they said above, and you don't need to include donations links (though WMF won't mind donations!) see [[Wikipedia:Reusing Wikipedia content]] for guidelines on how to license and attribute the work. One thing you can do in any links is to specify the version that you dictated, on a page click on the "Permanent link" link on the left sidebar to have a link to a point-in-time version if it will help you. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:56, 14 January 2021 (UTC)
:: Thanks Xaosflux, Iridescent and Izno! I'll think about this. @Iridescent, thanks especially for that bit about reading software preference; I'll pivot to focus more on reach than accessibility.
Re-reading entire pages every time they update does sound tedious, but unless large swaths of text are removed or reordered regularly (?), I could just record the new text and patch it in with editing.
Also, I saw some things suggesting that volunteer hours are declining. Should I be concerned? Would it be potentially helpful to plug volunteering to my potential audience? [[User: Masterpiece Reader]]

Revision as of 21:05, 14 January 2021

 Policy Technical Proposals Idea lab WMF Miscellaneous 
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:

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, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57


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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
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)[reply]
You're right. Those banners get scrolled past quickly. Flounder ceo (talk) 21:19, 7 December 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@Moxy: Nominated {{Webcomics refideas}} for WP:CSD#G7 speedy deletion. –MJLTalk 03:57, 13 December 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

@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)[reply]
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)[reply]

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 am 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, but has fallen into neglect without 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 discouraged 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 the Skip to talk 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 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.

Separately, Calm, Not A Forum, etc are often no longer even applicable; that requires manually checking that the talk page has calmed down and removing those templates-- not something we can assign to a bot.

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 and Some Portals. 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.

Forgot to add that GOCE almost NEVER rolls their banners in to the {{WPBS shell, and I also have to do a lot of those. They also tend to drop them in anywhere, similar to Vital articles, with little regard to the layout of the talk page. SandyGeorgia (Talk) 21:04, 1 January 2021 (UTC)[reply]

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 entries, 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 their talk page template 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 am having to go back and recover them-- usually by manually looking them up. Could we all get on the same page? A whole separate bot is needed now to go back and replace lost DYK nomination pages in article history. I have found and fixed scores of them already.

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 know how to use the subst template correctly when closing, and fixing a malformed GA pass means a whole ton of digging in to history to find the missing information.

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) 20:50, 1 January 2021 (UTC)[reply]

Thanks, this is a very helpful rundown! It makes it clear that what we have is really two separate problems, each of which is significant: (1) figuring out what design would be optimal for talk pages, and (2) getting everything working on the technical/bot side so that pages end up looking the way we want them to. {{u|Sdkb}}talk 01:15, 2 January 2021 (UTC)[reply]
FWIW, I'm about to start a TfD discussion on collapsing the WPBS by default. Slightly unconventional, but these widely advertised discussions generate more accurate gauging of "consensus" wrt templates imo. Even the "After" image is too much imo, the WikiProject banners take up over half of the image! ProcrastinatingReader (talk) 12:13, 8 January 2021 (UTC)[reply]
See Wikipedia:Templates_for_discussion/Log/2021_January_8#Template:WikiProject_banner_shell. May interest @Sdkb, SandyGeorgia, and Aza24: & @Mathglot, Djm-leighpark, and Tom.Reding: from previous discussion. Slightly nuclear option, but 30 days of talk page discussion didn't work and the WP template talk pages don't have many active watchers, certainly not the average viewer of these templates, people who won't frequent the VPs either. Was effective for participation [last time]. ProcrastinatingReader (talk) 12:31, 8 January 2021 (UTC)[reply]

Discussion of talk page cleanup issues

Okay, this is very helpful, thanks SandyGeorgia! For the record, also going link in Wikipedia:Bot_requests#Article_History_template_script here which has some related info.
Initial questions: first I'd like to know where we're currently at with this:
  • From the BOTREQ, and on GitHub, I see Enterprisey has been working on something related. @Enterprisey: are you still working on this, and if so how much of the stuff above do you intend to cover with your bot?
  • What bots are active in this area? It doesn't help that we have no organised collection of what bots do what recurring tasks. It'd be helpful to know exactly which existing bots are doing things which may overlap with a 'super-bot' to take over GimmeBot's tasks. Which of FACBot's tasks is editing article history? What's the name of the bot doing the OTD stuff?
Some design questions:
  • If a talk page only has a single DYK/GA/etc template (eg 1 DYK nom, nothing else), can we still convert that into {{Article history}}, or do we need multiple templates to do this? eg could this page (only one template - OTD) be converted to {{Article history}}?
  • Can vital article status be indicated in {{Article history}}? e.g. add a sentence "This article is a level 2 vital article in People, Sports." and then delete {{vital article}}?
ProcrastinatingReader (talk) 20:24, 1 January 2021 (UTC)[reply]
Vital articles have nothing to do with article history, and shouldn't be lumped with it. Headbomb {t · c · p · b} 20:32, 1 January 2021 (UTC)[reply]
No one has suggested lumping Vital articles in to articlehistory; this discussion is about talk page clutter, which comprises many different issues, of which Vital articles is one, articlehistory events is another. SandyGeorgia (Talk) 20:54, 1 January 2021 (UTC)[reply]
Oops, sorry, I see PR did suggest that. Bad idea. Vital article status has nothing to do with anything ... at all. It's a passing fad. It doesn't belong in article milestones; it is exactly like any other WikiProject, and belongs in the WikiProject banner shell. SandyGeorgia (Talk) 21:00, 1 January 2021 (UTC)[reply]
I agree vital articles should not be taking up an entire banner by itself, but I wouldn't say it's "exactly like any other WikiProject", and I don't think the project banner holder is really a great place for it either. An article having vital status is a useful indication of its importance, which is different than just saying "this page relates to this content topic". The top-to-bottom overhaul of talk page banners I envision would find some better way to note which non-content projects relate to a page and how they have interacted with it. {{u|Sdkb}}talk 00:58, 2 January 2021 (UTC)[reply]
PR, I am not entirely sure what Bot does what, as they seem to change over time. Cewbot does Vital articles, FACbot does FACs and FARs. Yes, we certainly need a list of who does what, and who does one talk to about what. I struck out with finding any centralized place to pull in either OTD or Vital articles. SandyGeorgia (Talk) 21:00, 1 January 2021 (UTC)[reply]
Yes, one DYK can be converted to articlehistory, but it's not very useful to do (in terms of talk page clutter). I am fairly certain, although I could be wrong, that by hitting all GAs, you get the bulk of the cleanup needed. BUT ... I left out the fact that GImmeBot also processed in AFDs, which are not being done now. SandyGeorgia (Talk) 21:00, 1 January 2021 (UTC)[reply]
I was working on it quite a bit in October, but shinier things distracted me. At the moment, the code looks like it just supports DYK, ITN, OTD, and XFD (i.e. merging them into {{Article history}}). The rest of the templates are totally doable, it's just tedious figuring out precisely how the other templates fit into the {{Article history}} format. I think the remaining templates are DYK, GA, FAC, FAR, PR, and everything else that both has its own template and is supported in {{Article history}}. If an expert on those templates wrote a little guide on how to convert each into the {{Article history}} format, or just linked some diffs showing the conversions being done, that would help. Enterprisey (talk!) 00:20, 2 January 2021 (UTC)[reply]
Enterprisey I do dozens a day. Where do you want me to put samples? Give me a workspace, let me know exactly what you want and where to put it, and take note that I don't get along with the pingie thingie at all. Also, it's not only a matter of samples, because there are boatloads of issues created by all the different bots that will need to be sorted. Gimmebot had gotten things to a point that there weren't so many exceptions to be dealt with, but if you get something going, you are going to initially find a lot of errors kicking out, so we need a place to work together, as I used to have with Gimmetrow. Please post to my talk page. Best, SandyGeorgia (Talk) 00:25, 2 January 2021 (UTC)[reply]
A whole 'nother separate but related issue is that GOCE needs to be removed from Template:Article history. That, too, is a WikiProject, and their template goes in banners. GOCE hitting an article doesn't really belong in articlemilestones. That an editor who happens to be part of one WikiProject goes through and copyedits an article is no different than any non-GOCE editor copyediting an article, and is not a community milestone. SandyGeorgia (Talk) 21:05, 1 January 2021 (UTC)[reply]
Though I suspect most people adding {{skip to talk}} aren't thinking about editors using screen readers, it's an accessibility aid for them. Once they've listened to the headers once, it's helpful to be able to skip to the main content of the page. isaacl (talk) 21:52, 1 January 2021 (UTC)[reply]
  • I dislike the {{Article history}} template. It seems quite fiddly and unfriendly to use and it hides information which editors are supposed to look for in some circumstances, such as previous AfDs per WP:BEFORE. It badly needs an option to display the history with one line per entry, as is commonly done with {{WPBS}}. More generally, the idea that talk page structure should be made uniform seems quixotic. The WMF have technical plans of their own for discussions and talk, as I suppose they still consider it too unfriendly for the general public. And getting editors to agree across six million articles seems unlikely. Andrew🐉(talk) 16:55, 10 January 2021 (UTC)[reply]

English variety

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


I mentioned this above, but am still baffled by it. Is there any reason that the English variety appears on talk pages? I don't know how this could ever be effective, since I'm sure those who are disregarding this the most aren't going to see it on the talk page. Surely these could be converted to an edit notice; which would be significantly more effective? Aza24 (talk) 23:54, 6 January 2021 (UTC)[reply]

Editnotice-only would be the best approach imo. We need to know that information when editing the article, people don't go onto the talk page for it. I usually just infer from the presence of {{use dmy dates}} or something, myself. I note that these cannot be seen on mobiles, but then again talk page banners are hidden too. ProcrastinatingReader (talk) 09:03, 7 January 2021 (UTC)[reply]
I am equally baffled by these on talk. Mostly, it is experienced editors who use talk pages (relative to IPs or drive-by editors, who may not even go to talk or know what it is), and experienced editors know where to find English variety in article templates, so I do not see what purpose these are serving on talk. (That is, I agree with Aza24 that "those who are disregarding this the most areen't going to see it on the talk page".) Especially when they get lost among the clutter. Similar to the proliferating pageviews templates. Similar to the "this article appeared at such-and-such portal". And so many others ... SandyGeorgia (Talk) 16:13, 8 January 2021 (UTC)[reply]
I suspect this simply predates edit notices. Agreed this would be useful as an edit notice, having it on the talkpage is about as much use as a chocolate teapot. ϢereSpielChequers 21:57, 8 January 2021 (UTC)[reply]
I was just thinking this. It seems pretty clear that they are in the wrong place. Aside from the technicalities of implementing this, I can't imagine why anyone would object to shifting this over. --Paultalk❭ 11:54, 9 January 2021 (UTC)[reply]
The way to test this would be to TfD all the talk page notice templates, stating that a bot will add the equivalent editnotice before deletion if not already existing. We do have a tendency to support the status quo, though. ProcrastinatingReader (talk) 12:45, 9 January 2021 (UTC)[reply]
Couldn't the bot just move every instance of the template (assuming consensus to do so), so that was nothing is "getting deleted"? {{British English}} already says may be included on talk pages or editnotices - so the only change being suggested here is a change to how we use the same template. --Paultalk❭ 16:38, 9 January 2021 (UTC)[reply]
It appears, Paul, that these matters are not as simple to resolve as those following this discussion would hope; to wit, ProcrastinatingReader's observation about the "tendency to support the status quo", relative to ongoing discussions about template clutter on talk. When discussions about changing, improving, deleting templates to address the talk page clutter problem have come up, status quo is being supported. ProcrastinatingReader, perhaps a bigger-picture approach to educating more editors about the issues would help? I am thinking of something like Wikipedia:Wikipedia Signpost/2008-03-24/Dispatches. Perhaps the growing clutter is just not something most editors are aware of. SandyGeorgia (Talk) 16:48, 9 January 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Signpost

Responding to SG's Signpost idea, I think that's a great idea. The 2008 piece is very well written and evidence based. I think we can deal with article history with a bot - no need for additional consensus, really, as it's in line with the docs and precedent, and we already have an existant authorised bot (GimmeBot) for this purpose. But I imagine talk page clutter has gotten more disparate and worse since 2008 as well, with a lot more templates being spammed around (just one example: the controversial, round in circles, etc., templates), so there's probably different things to talk about now. Overall I think that's a great idea to raise awareness on all issues relating to this, especially the newer ones, and also get our heads down and think long term and more broadly on this. ProcrastinatingReader (talk) 11:21, 11 January 2021 (UTC)[reply]
The credit for the “very well written” 2008 piece goes to the efforts of one of Wikipedia’s finest writers, User:Tony1. If you want to communicate something well to a broad audience, he is key. The Signpost is not so widely read anymore, so more thought could go in to how to get this message out, but getting something written up first would be a good start. Prose is not my strength, and brevity is not the soul of my wit. With the series I used to run in the Signpost (Template:FCDW), I would lay down facts, and Tony1 would smooth the writing. Or someone else would write them, and then Tony1 and I would go through ... SandyGeorgia (Talk) 14:35, 11 January 2021 (UTC)[reply]
Also, ProcrastinatingReader, I don’t speak bot, but my understanding—since Gimmetrow was chased off by a prolific sockmaster and another habitually rude and ill-tempered FA writer—is that we do not have the code for Gimmebot, and no one has yet replicated it fully, ten years later. SandyGeorgia (Talk) 15:19, 11 January 2021 (UTC)[reply]
Yeah, it appears we do not have the code. It seems based on this someone emailed to ask about it, but didn't get it / Gimme is inactive now unfortunately. This doesn't matter too much, as it seems Enterprisey is working on rewriting it, but the previous approval of Gimmebot helps as a show of consensus for the bot when it goes through BRFA, since GimmeBot is still authorised for the task (its BRFA is not revoked). Prose is not my strength also, but data collection I can do if needed. As for Tony1, I recently stumbled across their essay User:Tony1/How to improve your writing. Looks like they have some other gems in their userspace, too. I wonder if they may be interested in rewriting the DS templates in English :D -- they seem to be in desperate need of simplification and rewriting (one such discussion here) ProcrastinatingReader (talk) 15:42, 11 January 2021 (UTC)[reply]
I don't feel that wordsmithing is dependent on any one editor; I know there are plenty of editors who can polish a draft. The bigger issue is that it's hard to get editors to stop doing something they really like to do, particularly in a tragedy of the commons situation. isaacl (talk) 00:04, 14 January 2021 (UTC)[reply]
Signpost has been doing re runs; that one might be a good one to drop to their tip line. --Izno (talk) 17:39, 11 January 2021 (UTC)[reply]
I would have to do a thorough update; it is more than ten years old, and pieces of it aren't even true anymore. SandyGeorgia (Talk) 18:15, 11 January 2021 (UTC)[reply]
You could, or you can suggest it run and decide later if you want to update it; the point of that column is to rerun them as they were, and since it's topically if not exactly relevant... --Izno (talk) 18:57, 11 January 2021 (UTC)[reply]

Auto expiry

What do you think of having certain talk page banners expire after a long period automatically? For current event, not a forum, calm, controversial etc. Additional fields could be added for when an editor doesn't think that it should expire for whatever reason. --Paultalk❭ 06:55, 11 January 2021 (UTC)[reply]

Paul Carpenter, that's an interesting thought! Something similar came up recently at a recent TfD discussion about the Wiki education banners. Ultimately, the view we came to was that often, when the desired behavior is for a notice to be posted to talk but not to stick around indefinitely, the best solution is to convert it to a talk page message rather than a banner. {{u|Sdkb}}talk 11:14, 11 January 2021 (UTC)[reply]
I like it; as I am cleaning up talk pages on FACs and FARs, those are the ones that require time to investigate as to whether they are still needed. And I find they are still hanging around on pages that have had no posts for months or years. But not WikiEd banners, for the reasons I have laid out elsewhere. Until someone has been able to check for student errors and remove inaccurate medical text, those provide an essential alert, and can then be manually archived. SandyGeorgia (Talk) 14:29, 11 January 2021 (UTC)[reply]
Actually, thinking about it, there's a step before automating this - in that they just need to be dated (in exactly the same way as maintenance banners). Then there'd be a category of Category:Talk pages with a Calm banner since January 2008 and so on. Which would make the task of finding old ones easier: if AnomieBot forced dates on all new ones then after three months the pages remaining in Category:Talk pages with an undated Calm banner would be the ones to either remove or renew. --Paultalk❭ 15:29, 11 January 2021 (UTC)[reply]

Talk header

|hide_find_sources= should probably be enabled by default imo. –MJLTalk 20:17, 12 January 2021 (UTC)[reply]

@MJL: It's somewhat of a compromise; see context here: Wikipedia:Templates_for_discussion/Log/2020_October_4#Reference_search_tools_talk_page_templates. {{u|Sdkb}}talk 10:54, 14 January 2021 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
I support anything that gives us a role called Eliminator. No questions asked. GeneralNotability (talk) 04:12, 9 December 2020 (UTC)[reply]
Now that's a hat to collect. —valereee (talk) 10:37, 9 December 2020 (UTC)[reply]
Looks like we’ve found a name too! ProcrastinatingReader (talk) 10:51, 9 December 2020 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 --Paultalk❭ 14:36, 10 December 2020 (UTC)[reply]
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)[reply]
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)[reply]
I like responder. Bland enough, but not too. —valereee (talk) 20:34, 10 December 2020 (UTC)[reply]
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)[reply]
Ah, okay. For context (since it probably seems out of the blue): I pinged as you proposed these two in 2013: [3][4], which seemed kinda similar (though broader) to this one. ProcrastinatingReader (talk) 13:28, 10 December 2020 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
WSC, great, so back to the analogy: this creates the position of volunteer fire warden. :) —valereee (talk) 15:56, 10 December 2020 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
Just wanted to follow up WereSpielChequers if it'd be possible to get your thoughts/advice on some of those questions above if you have a moment? ProcrastinatingReader (talk) 09:12, 4 January 2021 (UTC)[reply]
Apologies for not getting back earlier. 31 hour blocks for IPs and indef blocks for editors who are not yet extended confirmed would be useful, even if it was limited to vandalism only accounts. I still think that I would oppose the measure as it ignores our real problem which is recruiting more admins. But this would usefully reduce the admin workload. ϢereSpielChequers 21:32, 4 January 2021 (UTC)[reply]
  • @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

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)[reply]

  • 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)[reply]
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)[reply]
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)[reply]
Isaacl, I tend to agree with you, although I'm often surprised by which articles are difficult. Closely watched articles might blow up over nothing, but editors can also provide a moderating influence. I think that having more watchers would make the first situation better, as it wouldn't always be the same couple of people.
I don't know if the second can be resolved without a Wikipedia:Competence is required-type ban. There's no single article or subject. We also send mixed signals to people who believe that they are defending the encyclopedia from garbage. If you post something like "you don't know what you're talking about and I bet you're a paid shill for that company", then you can expect an equal amount of bouquets and brickbats. WhatamIdoing (talk) 03:25, 5 January 2021 (UTC)[reply]
Yes, I prefer editing pages with lots of watchers because there's a better chance of issues getting resolved, one way or another. I have raised the desirability of sorting out uncollaborative editors more rapidly (as have many other editors, such as TonyBallioni). I wrote down one way to do this in my list of ideas to foster collaborative behaviour—active mentorship for new editors who are not adopting community behavioural standards—but I haven't done any further follow up, as I'm not able to construct a plan that would surmount the sizeable challenges. (Due to the large time investment required, multiplied by the rate of new proteges, I think it will require hired staff, which I imagine won't happen without some level of consensus, and that is a showstopper for any significant change, and anything requiring paying people.) Another way would be to empower some group to make decisions about the promise shown by new editors, but I don't see a lot of support for that at present, either. isaacl (talk) 05:24, 5 January 2021 (UTC)[reply]
  • 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)[reply]
  • I'd like to point out that, believe it or not, all of those processes work notably better now than they have in the past. (Especially during the Stone Age of Wikipedia, when there was no WP:AN, WP:AN/I, or ArbCom. I don't know why that is -- except to deny I had anything to do with it. Maybe the community has grown more confident about what Wikipedia is about, what determines an editor who is a net positive, figured out more ways to constructively interact with others, established an unwritten community norm for behavior (by setting examples), & maybe we know where more of the landmines lie that lead to endless bickering.
    That said, there is no easy way to deal with some people. And few of us have the inclination to deal with those people -- either to mentor, or to somehow coerce them to behave.
    Sometimes I think we need to resort to solutions that are not natural for Wikipedia culture. For instance, have an active project director for en.wikipedia who actually leads by herding us cats: directs people to working on higher-priority articles, recruits people to watch flashpoint articles, settles content disputes, & so forth. This would be a short-term position (say a year -- longer would lead to burn out), with no special powers (except status & persuasion), & would refer difficult problems that merit sanctions to the ArbCom. Another idea I had would use the T&S group at the Foundation as paid mentors who would have the time to deal with that second situation WhatamIdoing described -- & other cases where we have productive editors who need special attention to properly interact with other editors. And alternative to blocking or banning people. I doubt any of these suggestions would be acceptable, but figure any durable solution requires thinking outside the box. -- llywrch (talk) 23:16, 4 January 2021 (UTC)[reply]
    Llywrch, this reminds me a bit of a parable on User talk:Iridescent in 2018. I have wondered for years whether a bit of deliberate scheduling at, e.g., ANI would be helpful. (Imagine, e.g., that every sysop had to sign up to be the primary contact for all problem reports that appear at ANI during a four-hour span of your choice once a year, and to patrol four hours' worth of new articles on a different day, and to close CSD or XFD discussions on a third day of your choice each year.)
    On the one hand, rotating duties around reduces burnout, keeps everyone in touch with the everyday problems, and makes sure that decisions, on average, are made according to broadly held standards, because the process won't be dominated by one self-appointed person and his like-minded buddies. On the other hand, we have perverse incentives, and they will still apply. For example, out of one side of our mouths, we all agree that we want to address systemic bias, gender gap, etc., and out of the other side of our mouths, we praise the guy who removes information about, (e.g.,) universities in non-English-speaking countries, because he's Upholding High Standards and Defending the Wiki, when we probably should be telling him to enroll in a class on how to use a web search engine to find information (Step 1: Don't limit your search results to websites that are in English). Even if the admins intentionally rotated into different duty areas, they would still be subject to those incentives. WhatamIdoing (talk) 03:51, 5 January 2021 (UTC)[reply]
    Clay Shirky's talk "A Group is its own Worst Enemy" discussed problems with online communities. Attempts to make them non-hierarchical by replacing human judgement exercised by administrators with rules interpreted by everyone eventually fail as the rules become overly complex. Yes, there are advantages to the mostly flat decision-making framework used by the English Wikipedia community, but they come at a price. The community will one day have to face the question if having all significant changes stalemated, non-stop revisiting of disputes, and an environment that provides incentives for poor behaviour is worth it. isaacl (talk) 05:45, 5 January 2021 (UTC)[reply]
    @WhatamIdoing:, your idea of scheduling time at ANI/CSD/XFD makes good sense. In fact, I'd go one step further: anyone who wanted to be an Admin would need to volunteer first to be a primary contact at one or more of those locations -- which would give everyone at WP:RfA objective data about what kind of job that person would do with the bit. And we all need to broaden our areas of exposure on Wikipedia. (I'll pass on the suggestion about a class about how to find information, since that touches on one of my hobby horses -- no general school system in any country does a satisfactory job of teaching how to perform research -- which few probably want to hear me pontificate about.)
    @Isaacl:, it's been a while since I read Shirky's essay. I could talk about different points he raises in it (e.g. what killed Usenet wasn't that "anyone could join" but that it's flood algorithm failed to scale), but I think the most important point that needs to be remembered is that practically everyone who has been active on Wikipedia for 5-10 years has about as much hands-on experience with Internet communities as he had when he wrote that essay. I don't know if that means we might know as much or more than he on the subject, but it's a datum worth remembering. -- llywrch (talk) 17:00, 5 January 2021 (UTC)[reply]
    Part of the key points was that online communities are like communities in general and so our experience with them carries over. The fundamental problems of scale remain true. isaacl (talk) 18:05, 5 January 2021 (UTC)[reply]
    I think the value is in "more of those locations". We don't need the Wikipedia:External links/Noticeboard to be dominated by two editors (I'm one); we need different voices to show up, so that the advice given there will easily and automatically reflect the actual current views of the whole community. You need 'my' voice at other noticeboards (where I'm not a regular participant) and I need 'your' voices at ELN. WhatamIdoing (talk) 20:02, 5 January 2021 (UTC)[reply]
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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

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)[reply]

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • This has already been rejected multiple times. * Pppery * it has begun... 18:04, 31 December 2020 (UTC)[reply]

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)[reply]

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)[reply]
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. --Paultalk❭ 21:36, 30 December 2020 (UTC)[reply]

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)[reply]

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. --Paultalk❭ 21:59, 30 December 2020 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]

The sort of math that starts with ", and a large number, if not a majority," of 1.8 billion, calculates that this number is a bit north of 900 million, divides by the world pop of 7.8 billion to get 11.5% and decises that 10% is an acceptable approximation of such an uncertain number. My personal guess is a little south of that. There are certainly some ignorant people who think the prohibition on pictures is found in the Koran (it isn't) and they tend to be vocal, so I think the actual proportion is in the 3 to 5% range.--S Philbrick(Talk) 21:54, 2 January 2021 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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). --Paultalk❭ 09:01, 31 December 2020 (UTC)[reply]
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 (talkcontribs) 14:07, 31 December 2020 (UTC)[reply]
TheDJ, I agree. The people who object to images will not be placed placated by a larger disclaimer. S Philbrick(Talk) 21:56, 2 January 2021 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
Make it say "the free uncensored encyclopedia that anyone can edit" Dullbananas (talk) 18:57, 11 January 2021 (UTC)[reply]
  • Vorbee, I'm sympathetic to the goal but not persuaded that the solution will be effective. Just check out the wp:ANI page. It has a disclaimer that is:
    • big
    • bold
    • and in red, with underscores
    Telling editors they must leave a notice on the editors talk page. This is ignored dozens of times every week. I don't think the solution is to make it bigger. S Philbrick(Talk) 20:27, 7 January 2021 (UTC)[reply]
  • "The free encyclopedia that anyone can edit (tfetace)" is generally interpreted by unsophisticated users as "Oh good, if I don't like it, I can change it", or else as "Yay, wet cement! a dusty car window! a clean toilet wall!". To imagine that the average reader reads into tfetace that content is uncensored and may concern anyone, any idea, any practice, ever, regardless of the reader's own standards, may be a bit, umm, "unsophisticated".--Quisqualis (talk) 04:00, 6 January 2021 (UTC)[reply]

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. --Paultalk❭ 09:31, 31 December 2020 (UTC)[reply]

Link useful to a reader? useful for most editors?
What links here maybe? Yes
Related changes No Yes
Special pages No Yes
Permanent link for someone accessible in history
Page information No Yes
Cite this page I guess I guess
Wikidata item for someone Yes
Download as PDF I guess I guess
Printable version I guess I guess
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. --Paultalk❭ 09:48, 31 December 2020 (UTC)[reply]
"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)[reply]
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. --Paultalk❭ 10:04, 31 December 2020 (UTC)[reply]
  • 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)[reply]
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. --Paultalk❭ 10:36, 31 December 2020 (UTC)[reply]
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)[reply]
@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)[reply]
  • In case this goes anywhere, it occurs to me that the binary choice between readers and editors is overly simplistic. I can think of a third category that is neither fish nor fowl — re-users of content. In addition to the people who are pure readers — they are reading Wikipedia articles to learn something about the subject matter but plan to do no editing or reuse of the material, there are many people who write articles or books and might wish to incorporate excerpts from or links to Wikipedia articles. This happens quite often, and these people are not editors, but they are more than just readers. In many cases they will simply provide a link to the article, but if they know what they're doing, they will also provide a permanent link. Some people do know enough to do this in the existence of the permanent link makes this easy. My point is this class of people are probably not editors in the sense that they never contribute content to Wikipedia, but they would find this sidebar functionality very useful.--S Philbrick(Talk) 21:44, 2 January 2021 (UTC)[reply]
I'd imagine these users' purposes are most usefully served by the Cite this page link (which provides a permanent link in addition to other bibliographical information). – Teratix 11:53, 5 January 2021 (UTC)[reply]
Teratix, Exactly, but as I understand the original proposal, it is to remove links that are useful only to editors but not to readers. The Cite this page and permanent link options are not explicitly on the proposed chopping block but potentially could be. My point is those functions are valuable to people who are not editors. S Philbrick(Talk) 20:12, 7 January 2021 (UTC)[reply]
Teratix, After looking closer, I noticed something I had not noticed before, namely that the Cite this page does include Permalink, so if there really is a consensus that the sidebar is too busy, perhaps permanent link is redundant, but that only works if we are sure that people looking for permanent link will realize that Cite this page provides that option. That assumption isn't obvious to me. S Philbrick(Talk) 20:16, 7 January 2021 (UTC)[reply]
Yeah personally Perm Link is on my keep list, it's a bit redundant but not as redundant as some of the others. --Paultalk❭ 06:59, 11 January 2021 (UTC)[reply]

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)[reply]

I'm trying to figure out how to interpret the silence here. Do others agree that this is a problem? {{u|Sdkb}}talk 11:23, 4 January 2021 (UTC)[reply]
@Sdkb:, I have also run across this, and I agree that it would be good to detect and flag this. Maybe you'd get better uptake on WP:BOTREQ. The only issue I can see is that it would be technically tricky, as I believe the only way to detect this would be to have a bot crawling every article. Vahurzpu (talk) 18:11, 4 January 2021 (UTC)[reply]
Thanks for the reply. Yeah, BOTREQ is probably where this is headed. I'm not sure if this should be a bot or a filter, though. (By "filter", I mean the tags like "possible COI" that I sometimes see next to edits; I'm not too sure how these work.) {{u|Sdkb}}talk 18:49, 4 January 2021 (UTC)[reply]
Pinging @Beetstra, who has doubtless thought about this problem. WhatamIdoing (talk) 20:58, 4 January 2021 (UTC)[reply]
Sdkb, I remove them from sentences, but the problem is that there are some cases where the community adopted reasons to have them included in sentences (links to bible texts are one example, links in tables are another). One could try to write an edit filter (I may have a stab at it) to at least flag them. Dirk Beetstra T C 04:03, 5 January 2021 (UTC)[reply]
Beetstra, sounds good! Lmk if you need any help pushing the initiative forward. {{u|Sdkb}}talk 14:24, 11 January 2021 (UTC)[reply]

Way to track times/dates when an article is listed on Portal:Current Events

So dozens of articles are listed daily on the Portal:Current events. I am thinking about a proposal to make some format, similar to how the daily page view is tracked, to show the dates (or number of times) an article was listed on the Current Event Portal. Not every article would have it, only if people add the “track” will it display the information.

One problem I am thinking of with this is all the COVID articles. If this was proposed, that would be an entirely separate discussion of how to handle all of that messy formalities.

Does anyone else think this could be a good idea to propose? Please feel free to drop any insight (positive or negative) you have about this idea. Thank you (Lead coordinator of WikiProject of Current Events) Elijahandskip (talk) 17:58, 5 January 2021 (UTC)[reply]

Navigating within long-winded discussions by way of a visual parsing cue

If this qualifies as a technical proposal, please let me know, and I will move this post to VPT. My proposal is that some means of visually parsing a long, back-and-forth or round-robin, relatively free-ranging discussion on Wikipedia ought to be developed. I often have trouble visually parsing long discussions on the WP:Help desk, for example. Sometimes, a discussion will involve three or more people and/or have five or more posts. Spacing between posts is not standardized, nor are signatures, nor is indentation, nor is the length of posts. Sometimes, people become confused and respond as if one person is the author of what another user has written. My heuristic (and I hope, permanent) solution, which would work wherever posts are begun on a fresh line, would be to have a marker (anything from an asterisk to an arrow head) automatically appear in the left margin, next to the start of a new post. That way, posts will be harder to miss or misattribute.

Today, I met my match in the form of a visually unparseable Arbitration discussion. One post was in excess of 12,000 bytes. Finding that post's author took looking up the longest post in the page's History, then searching within the discussion until I found that post's author's signature. At that point, what the post said had lost its significance.

Alternatively, time stamps could have background coloration to identify the nearby presence of a signature, although this would not work where users don't sign their post and have not opted to have SineBot do it for them. On the Help desk, such people are frequently the original poster.

I'm open to any comments or suggestions on how to accomplish my aim.--Quisqualis (talk) 03:25, 6 January 2021 (UTC)[reply]

Give my TalkHelper user script a try? It highlights the posts for yesterday and today and builds a TOC for them in the sidebar. It is a bit rough and still evolving, so feedback would be welcome. — GhostInTheMachine talk to me 10:23, 6 January 2021 (UTC)[reply]
Will adding the script enable any notification when a new version comes out?
No, but telling me you want to be notified hasGhostInTheMachine talk to me 20:04, 6 January 2021 (UTC)[reply]
Well thank you!--Quisqualis (talk) 20:06, 6 January 2021 (UTC)[reply]

New abuse filter page

We need an abuse filter for detecting socializing on talk pages, especially article talks. Like this:

23:00, 7 January 2021: Example (talk | contribs) triggered filter (number), performing the action "edit" on Talk:Example. Actions taken: Tag; Filter description: Socializing/chatting irrelavantley (details | examine | diff)
--🔥LightningComplexFire🔥 18:41, 7 January 2021 (UTC)[reply]

LightningComplexFire, that seems like it would be difficult to detect with a filter—what sorts of keywords or other criteria would you want to have? Additionally, there are context concerns: I don't really see anything wrong with, say, two editors running into each other on a very inactive talk page, and adding as part of a reply "hey, it was great to see you at Wikimania the other week". {{u|Sdkb}}talk 19:23, 7 January 2021 (UTC)[reply]
Sdkb, I'm talking about any talk except User talk. And I'm talking about edits like this --🔥LightningComplexFire🔥 19:29, 7 January 2021 (UTC)[reply]
The question remains: how do you propose that this filter could feasibly work? Filters can't just automatically detect what "socializing" is without it being defined. {{u|Sdkb}}talk 19:55, 7 January 2021 (UTC)[reply]
Well, I don't know how to make abuse filters, that's why I'm suggesting this idea --🔥LightningComplexFire🔥 19:59, 7 January 2021 (UTC)[reply]
It would be computationally difficult without something like an AI, which isn't currently available to us for customized filters, at least not as far as I know. Even with a "well-trained" AI, there will be false positives and false negatives. So, even if it were desirable, something like this is a few years away at best. davidwr/(talk)/(contribs) 21:04, 7 January 2021 (UTC)[reply]
Socializing on article talk pages happens for a variety of reasons. It is not a crime. It is important to remember WP:AGF. It is also worth noting WP:IAR. The post can be removed (I've done that many times over the years) with an appropriate edit summary. In my experience, often times, it is someone trying to find out or impart info. Editors can be pointed towards the appropriate ref desk or wikiproject talk page or a help page. IMO, in the grand scheme of things, this is not a huge problem. MarnetteD|Talk 17:07, 9 January 2021 (UTC)[reply]
Defining socialising would have problems even if such an AI existed. The editors of wikipedia are mostly white US men, so the norms it'd be learning off of would be that of white US men. This could lead to disproportionate tagging of anyone else's posts as socialising because their norms for what isn't socialising may be different. For a very loosely related example, one of my parents is an immigrant. Where she is from, it is not considered a "friend" (or socialising) interaction to chat to a retail worker about each other's personal lives, whereas in our current country this is very much a friend interation.
Further, it is not necessarily bad to socialise - people are social. Therefore, we are more likely to remain in communities where we have social ties, we are better at collaboration when we have those ties, AND we find it difficult to not slip in small amounts of socialisation into any of our interactions. --Xurizuri (talk) 12:50, 12 January 2021 (UTC)[reply]

Major revision of (important) articles - guidelines and practices?

Over at the Donald Trump article, we have discussed significant revisions to the article, particularly given its excessive size. The article, with an eye on its many many related articles, would seem to need a major revision, reorganization to downsize it. Happens all the time with writing, one starts over and recycles material already developed, as appropriate. I am unsure of quite how to do that in Wikipedia, how to tear apart and reassemble an article, particularly one as important as Donald Trump. Once such a process begins the article could remain in a terrible state of construction, perhaps for a long time, with no guarantee that the result would be better than the original. Does/should Wikipedia have a policy/guidelines for major article revision? Once a revision is started, should an old article have a tag warning away new revisions and redirecting editors to the revised version? On the Donald Trump talk page, I sketched a process of (1) agree on a revised outline and philosophy, (2) start (offline) subpages for article sections, (3) once a decent revised state has been achieved, replace the old article. Seems to me wikipedia ought to have some guidelines and tools, advice on avoiding dangers, etc. for a major revision of an article. (I once attempted a major revision of a different article...I got all the "spinning plates" up in my head, had the plan in mind, had undisputed agreement on the Talk page...but then some change watcher reverted me halfway through the revision...Arrrgggh!) Bdushaw (talk) 02:06, 11 January 2021 (UTC)[reply]

For articles edited more rarely, spinning off a sandbox article (and posting a link on the talk page) is a common method, but as indicated, not viable here (on its own). For something as major as Trump's article, you'd likely want consensus on the talk page prior to making what would be a huge string of major edits (remember, many of the inclusions actually had short RfCs about their inclusion on T's page), and gather buy-in for not just the change occurring but your proposed methodology. I'd be inclined to think that any guidelines we tried to create on how to handle a re-write of such a large article would end up honoured more in the breach than in the observance - local consensus and wildly different circumstances would make different methods suitable at different times. I'd personally be inclined to take an elephant approach and handle it one section at a time, because your change is going to impact not just the article you're trimming but potentially the various sub-pages (e.g. the presidency of Trump) that already exist. Trying to do that all at once would require an ability to make editing freeze for a couple of weeks while you did the work. Nosebagbear (talk) 11:42, 11 January 2021 (UTC)[reply]

Add a new type of WikiMoney

I think re-implementing WikiMoney and the related services could be cool. What if you could use WikiMoney to buy some cool things like a "Golden Barnstar" to give to exceptional work. — Preceding unsigned comment added by Education-over-easy (talkcontribs) 14:25, 11 January 2021 (UTC)[reply]

Was that really ever a thing? --Paultalk❭ 15:43, 11 January 2021 (UTC)[reply]
Wikipedia:WikiMoney says it was created in 2003. By early 2006, it was marked "historical". davidwr/(talk)/(contribs) 20:22, 11 January 2021 (UTC)[reply]

Dystopian Topics

there should be a category/list of dystopian topics Dullbananas (talk) 19:00, 11 January 2021 (UTC)[reply]

@Dullbananas: for its use in fiction, we do have: Category:Dystopian fiction and it covers most of the topics. Conversely, we do have Category:Utopias but I don't think it is a very high quality category. You may certainly create Category:Distopias if you think there are some articles that you could classify as such. — xaosflux Talk 14:42, 12 January 2021 (UTC)[reply]

New Name For Wikipedia

I Need A New Name For Wikipedia! — Preceding unsigned comment added by NicVivo (talkcontribs) 20:25, 11 January 2021 (UTC)[reply]

If someone gave a coherent reason why Wikipedia needs a new name then this might be the place to dicuss it, but your own personal need is irrelevant here. Phil Bridger (talk) 21:21, 11 January 2021 (UTC)[reply]

Tool for Designing Electric Circuits

Hello,

For the sake of standardizing and improving the quality of all electric schematics on Wikipedia, please add tool for designing electric circuits under the "Insert" tab. This QA website has a very cool tool for creating any kind of electric circuit while making up a question.

Thank you, Marino 21:59, 11 January 2021 (UTC) — Preceding unsigned comment added by Marino108LFS (talkcontribs)

Making FA, GA, FL status visible in mobile view

It would be helpful if we could have an icon on FL, FA, and GA pages in mobile view like we do in desktop. ~ HAL333 00:32, 12 January 2021 (UTC)[reply]

@HAL333: see phab:T75299 for the years-long discussion on this, looks like it may be getting some movement. — xaosflux Talk 00:41, 12 January 2021 (UTC)[reply]

Editnotice namespace?

I saw this comment from Izno which got my thinkpan in motion. Why do we have edit notices in the template namespace? Wouldn't it be easier for us just to have a legit editnotice namespace. The way we do it now (subpages of template:Editnotices) is pretty weird. –MJLTalk 19:07, 12 January 2021 (UTC)[reply]

Once they were in MediaWiki namespace but were disabled by the developers due to performance concerns. Ruslik_Zero 20:29, 12 January 2021 (UTC)[reply]
@Ruslik0: Well, that is a special namespace afterall. –MJLTalk 01:49, 13 January 2021 (UTC)[reply]
  • It's something technical, and I'm not in the weeds enough to know precisely what, but I agree that the current system is not optimal. Particularly, having them all be template-protected is a big impediment to their use, and we need them to be used/refined more on order to meet WP:ENDURE. {{u|Sdkb}}talk 10:59, 14 January 2021 (UTC)[reply]
    • They're protected via the blacklist, not by page protection, so page movers (who have tboverride) can also edit them. I don't think anyone should be able to edit the editnotices. Talk page clutter is bad enough, and many mistakes have been propagated even by template editors making mistakes (eg {{COVID19 GS editnotice}}). If editing editnotices was common-place they'd quickly become littered with crap, and it's an uphill battle to remove stuff on here. Actually, it's an uphill battle to do many changes; people are more scared of what they can't see than the status quo of what they can. I imagine this phenomenom has a name, and indeed a Wikipedia article on it, but I don't know what it's called. ProcrastinatingReader (talk) 12:34, 14 January 2021 (UTC)[reply]
  • I wouldn't want to have yet another namespace just for this, would prefer they were attached to their page instead like we do with userpage editnotices (e.g. User:Xaosflux/Editnotice) - that being said if there was going to be a wholesale improvement attaching them more formally to the page (e.g. Example, Talk:Example, Notice:Example) maybe, and attach them all together more formally (those this breaks down for noticed FOR talk pages.... or notices FOR notices.... or notices for notices for notices .......) — xaosflux Talk 14:51, 14 January 2021 (UTC)[reply]
    I'm wary of spamming the article namespace with editnotices, to be honest. It would mess up searching, for one. Currently, I think, (mostly) everything in the article namespace is article content. We're even often wary of using article-namespace templates (eg Template:Infobox Syrian civil war for a one-time use at Syrian civil war) ProcrastinatingReader (talk) 15:31, 14 January 2021 (UTC)[reply]

Verbatim wikipedia pages read & posted

I had a concept for a media channel project and wanted to hear some wikipedia community feedback before I get too far along.

Put simply, I'd like to record verbatim readings of wikipedia pages and post them to video sharing and social media sites. I would link to the source page, list references, and plug donations to the foundation at the end of videos.

I appreciate wikipedia so much, and especially the amazing work done behind the scenes to make content as coherent and reliable as possible.

At best, I feel this project will extend the reach of wikipedia to some people who either cannot or prefer not to read the English text themselves. At worst, I'll get some practice as a reader.

I know this kind of use is generally permitted, provided that licensing and attribution are observed. I'm posting here to gather ideas and (especially) concerns/objections. — Preceding unsigned comment added by Masterpiece Reader (talkcontribs) 02:05, 14 January 2021 (UTC)[reply]

We have a long-inactive WikiProject for this called WP:WikiProject Spoken Wikipedia. --Izno (talk) 05:16, 14 January 2021 (UTC)[reply]
As long as you attribute it correctly, you're free to reuse the content of Wikipedia in any way you want—you don't need to ask permission. (See Hellingly Hospital Railway for an example of a spoken article at Featured Article level—note the discreet link at the top next to the FA star.) I can tell you now that the drawback to what you're proposing—and the reason WP:WikiProject Spoken Wikipedia never worked—is that the articles in which people tend to be most interested, are precisely those articles which change most often, and nobody wants to commit to re-recording a new version every few days. (Plus, the people who would most benefit from spoken-word Wikipedia—the visually impaired and those who have difficulty reading—generally would prefer to use screen-reader software where they can adjust their preferences to suit regarding the accent, the speed of the reading, how it handles images, and searching for a particular part of the text, rather than a set of spoken-word recordings.) ‑ Iridescent 08:50, 14 January 2021 (UTC)[reply]
@Masterpiece Reader: as they said above, and you don't need to include donations links (though WMF won't mind donations!) see Wikipedia:Reusing Wikipedia content for guidelines on how to license and attribute the work. One thing you can do in any links is to specify the version that you dictated, on a page click on the "Permanent link" link on the left sidebar to have a link to a point-in-time version if it will help you. — xaosflux Talk 14:56, 14 January 2021 (UTC)[reply]
Thanks Xaosflux, Iridescent and Izno! I'll think about this. @Iridescent, thanks especially for that bit about reading software preference; I'll pivot to focus more on reach than accessibility.

Re-reading entire pages every time they update does sound tedious, but unless large swaths of text are removed or reordered regularly (?), I could just record the new text and patch it in with editing. Also, I saw some things suggesting that volunteer hours are declining. Should I be concerned? Would it be potentially helpful to plug volunteering to my potential audience? User: Masterpiece Reader