LS3

Wikipedia:Village pump (idea lab)
From Wikipedia, the free encyclopedia

Jump to navigationJump to search
Policy Technical Proposals Idea lab WMF
Miscellaneous
Table of contentsFirst discussionEnd of pageNew post
Shortcuts
WP:VPI
WP:VPIL
The idea lab section of the village pump is a place where new ideas or suggestions
on general Wikipedia issues can be incubated, for later submission for consensus
discussion at Village pump (proposals). Try to be creative and positive when
commenting on ideas.
Before creating a new section, please note:
Discussions of technical issues belong at Village pump (technical).
Discussions of policy belong at Village pump (policy).
If you're ready to make a concrete proposal and determine whether it has consensus,
go to the Village pump (proposals). Proposals worked out here can be brought there.
Before commenting, note:
This page is not for consensus polling. Stalwart "Oppose" and "Support" comments
generally have no place here. Instead, discuss ideas and suggest variations on
them.
Wondering whether someone already had this idea? Search the archives below, and
look through Wikipedia:Perennial proposals.
Discussions are automatically archived after remaining inactive for two weeks.
« Archives, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
31, 32, 33
Centralized discussion
Village pumps:policy•tech•proposals•idea lab•WMF•misc

Reliability of Business Insider reporting
Referring to creators credited under a deadname
Meta: Initiatives of recommendations
For a listing of ongoing discussions, see the dashboard.
viewedithistorywatcharchivetalkpurge
Contents
1 Thinking about a radical reduction of talk page banners
1.1 Vital articles WikiProject continues cluttering talk pages
1.2 Summary of talk page clutter issues
1.3 Discussion of talk page cleanup issues
1.4 English variety
2 Unbundling for the millionth time
2.1 A draft
3 Conduct dispute resolution systems
4 Idea for a new protection level
5 "Suggest edit" button
6 Auto-generating list articles from Wikidata?
7 Proposal to change the username policy's section on impersonation
8 Wiki App Idea
9 Making disclaimers more prominent
10 What could be stripped from the side bar?
11 Tools/systems for better catching inappropriate external links within article
bodies
12 Way to track times/dates when an article is listed on Portal:Current Events
13 Navigating within long-winded discussions by way of a visual parsing cue
14 New abuse filter page
Thinking about a radical reduction of talk page banners
I recently noticed how few pageviews the WP:Dispute resolution requests page gets—
less than 2000 per month, despite being linked from {{Talk header}}, which appears
on more than 500,000 pages. My assumption is that this is yet more evidence of
banner blindness, where we try to cram so much poorly-organized information onto
the top of talk pages that no one (most of all newcomers) reads any of it.
If you go to a random high-traffic talk page for a reasonably controversial

subject, like Talk:Karl Marx, there's just so much low-hanging fruit or obviously
non-ideal design.
Going through various things I notice:
The way we present WikiProjects is not ideal, even when {{Banner holder}} is used
to collapse them. Every project doesn't need to have its own banner repeating the
same line about "a collaborative effort to improve Wikipedia's coverage of X" and
giving the same quality rating. It'd be better to just have a single banner
(perhaps we could usurp {{WikiProjects}}, which has only 6 transclusions) that'd
list out each project and its importance rating, and to move the quality rating to
{{Article history}} as something that each page has only one of.
The "this article is written in X English" notice is something that should appear
in the editnotice rather than the talk page. We don't need to tell people to use
British English in their discussions on the talk page; it's enough to have it when
editing the page itself.
There are a bunch of "this is a hot topic" banners, such as {{Controversial}}, {{Be
civil}}, {{Round in circles}} (which also typically duplicates the archive search
box), {{Not a forum}}, the arbitration notice, etc. Each of these does technically
have a distinct purpose, but the cumulative effect of them is just for there to be
a bunch of banners all screaming at you. If I were designing from scratch the ideal
top of a talk page for a controversial topic, I'd want there to be only one "this
is a hot topic" banner that'd cover all of that stuff. It's also already part of
{{Talk header}}, so the emphasis should only be needed in extreme cases.
There are some banners that, while providing useful information, shouldn't require
a banner of their own. {{Vital article}} is one of these; the {{Auto archiving
notice}} is another. I'm not quite sure where the vital article notice should go,
but really all that's needed is for it to say Level-3 vital article in People; all
the rest, including e.g. If you can improve it, please do is unneeded (there's no
reason for reminding about boldness more at VAs than elsewhere). As for the auto
archiving notice, that could be rolled into the talk header, looking something like
this, which would communicate the same info but take up a fraction of the space.
And then there are the junk banners, such as {{OnThisDay}} or {{Top 25 report}},
which communicate something but not anything most people arriving at the talk page
need to be aware of, especially years after the fact. IMO, they should always be
collapsed within {{Banner holder}} anytime a talk page has more than a few other
banners, but that rarely happens.
I realize I'm throwing out a bunch of different thoughts, some of which could be
pursued in isolation, but the larger picture I see is that we ought to move away
from our current modus operandi in which each piece of information gets its own
banner and instead move to a system in which our core banners are able to
incorporate lots of different information and display it in a format where there's
appropriate visual weight and no duplication. {{Article history}} has done a great
job of this for article quality/milestones, but we need that same effort for lots
of different areas. I'd welcome thoughts about how to go about such an initiative,
or anything else that might help us address the problem of talk page banner
blindness. {{u|Sdkb}} talk 04:09, 6 December 2020 (UTC)
WikiProject banners have some affect on a particular database that would need to be
tested against before any movement of anything occurs, and some projects have
intersecting categories (quality vs priority) that you would not be able to
intersect directly any longer if one moved the banners. Many projects additionally
put Other Stuff in their banners besides quality and priority and one might wish to
investigate how widely used those are. --Izno (talk) 05:15, 6 December 2020 (UTC)
Izno, there are certainly some project banners that function in non-standard ways,
but most of these are for non-content-related projects (which are the ones added to
article talk pages). To be honest, what I'm proposing probably would require
ironing out some idiosyncrasies (e.g. if a project wants to call their importance
rating "priority" rather than "importance", that'd probably get lost), but I think
on balance it'd be worth it. {{u|Sdkb}} talk 05:22, 6 December 2020 (UTC)
What about task forces? Settings for "this page needs an infobox"? Transcluding
current activities for GA and such? Etc. Yeah, you're going to iron that part of it
out a lot better if that part is to stand a chance of success. --Izno (talk) 05:24,
6 December 2020 (UTC)
Izno, fair enough. I'm coming at this less from a "I've got all the details figured
out and want this implemented" perspective and more from a "if I were designing
talk pages from scratch, here's what would be different than they look today"
perspective. {{u|Sdkb}} talk 07:39, 6 December 2020 (UTC)
There is room for debate how to fix the problem. but Sdkb is spot on. Banners are
out of control. Look at Talk:Donald Trump. Nobody is going to read all of those
banners. Likewise with Talk:COVID-19 pandemic What is this,
[ http://www.arngren.net/ ]? Or [ https://www.yyyyyyy.info/ ]? --Guy Macon (talk)
08:47, 6 December 2020 (UTC)
For Trump, and articles like it, taking a step back and trying to prioritize
banners sanely and shoving the routine stuff elsewhere can lead to big
improvements. See [1]. Not saying it's perfect, but this is a lot better than that
IMO. Headbomb {t · c · p · b} 02:03, 10 December 2020 (UTC)
Right, I don't disagree that banners are a mess. I just know WPBanners in specific
will be hard to do something about. I think most of the other banners that show up
on the talk page are fairly mundane and could all be merged into some equivalent of
WP banner shell and not much at all would be lost. (Heck, we could stuff everything
into one template, WP banners and all.) As for "are there too many banners on a
specific page", if you see duplication in banner intent, or one more specific than
another, I highly recommend shipping to TFD or removing the ones you find as being
duplicate. --Izno (talk) 18:55, 6 December 2020 (UTC)
Izno, I could try doing a big TfD nom of {{Controversial}}, {{Be civil}}, {{Round
in circles}}, {{Not a forum}}, etc., but I'm not sure it'd succeed. Looked at from
the more narrow "are there meaningful differences between these or potential
separate use cases" criteria we tend to use there, the answer is that there are.
It's only zooming out to the larger picture where it becomes clearer that these are
having a detrimental effect in the way they're applied 99% of the time. {{u|
Sdkb}} talk 00:48, 7 December 2020 (UTC)
could try doing a big TfD nom [...] but I'm not sure it'd succeed But why not?
Anyway, whether it's successful or not, that's probably a quicker way than waxing
over here on WPI. At least one of those banners duplicates (the current) {{talk
page}}; I bet we could get the rest integrated into that one too. (And/or as
options.) --Izno (talk) 15:24, 7 December 2020 (UTC)
Talk pages banners are a dog's dinner. I think we also have an issue with DS
banners, eg Talk:Bill Gates, where people spam multiple DS alerts for the purpose
of aiding with awareness, so some of this is complicated by broken underlying
systems (something I've discussed with L235 - with any luck the next arb committee
might finally fix this particular issue). Further, there's the issue of everyone
thinking their banner is "the one" which is important, so it becomes hard to cut
down on the blindness once a new banner gets created and over time spurted around
everywhere. It's so bad the WMF decided to hide all banners under the small "About
this page" text on the mobile version. TonyBallioni once gave me the advice that
the idea lab is a breeding ground for dying ideas, though, so maybe collecting
together a bunch of interested individuals and figuring out a clear set of
strategies and bot operations to reduce this, then putting it forward as a
proposal, may be a way to proceed if interest flutters here? ProcrastinatingReader
(talk) 11:56, 6 December 2020 (UTC)
I'd love to reduce, or completely eliminate, the WikiEd banners, ("This article was
the subject of a Wiki Education Foundation-supported course assignment, between
[dates]. Further details are available on the course page") which are big, and tell
you nothing. Half of them are on pages which have merely been reviewed by a
student, and even those where the article is supposed to be edited are put on at an
early stage of the course. A high proportion of the students make no edits, or just
minor ones. Some articles have two or more of these. Once there, they never
leave.Johnbod (talk) 02:52, 7 December 2020 (UTC)
@Johnbod: tried that. See
Wikipedia:Templates_for_discussion/Log/2020_November_17#Template:Dashboard.wikiedu.
org_assignment. ProcrastinatingReader (talk) 11:15, 7 December 2020 (UTC)
That result looks workable. You proposed something, someone came up with something
else a bit later, and some chunk of the keeps shifted to message rather than full
keep. Now we just need someone to file the task to change the behavior in the
dashboard... --Izno (talk) 13:35, 7 December 2020 (UTC)
See User_talk:Sage_(Wiki_Ed)#Alteration_of_the_student_editor_template. Let's see
if we can work the feasibility out with Sage. This still leaves the issue of all
the other assignment banners, though, which predated the current dashboard-inserted
template. I guess we can BOTREQ to orphan, and (optionally) add a talk page message
at the same time (although, for some courses that ended years ago that may be
awkward, but still, serves as a record I guess?). ProcrastinatingReader (talk)
13:58, 7 December 2020 (UTC)
Damm - missed that. The argument editors need warning is a reasonable one. But it
should be as a normal talk page section, not forever kept at the top of the page.
Johnbod (talk) 16:42, 7 December 2020 (UTC)
You're right. Those banners get scrolled past quickly. Flounder ceo (talk) 21:19, 7
December 2020 (UTC)
For sanctions, you could have one banner with multiple sanctions (both ARBCOM and
Community-sanctions) coded in , something a bit like {{Sanctions/talk notice|
topic1=blp|topic2=ap|topic3=COVID}} giving something like
The Arbitration Committee and the wider community have authorized uninvolved
administrators to impose discretionary sanctions on users who edit pages related
to:
articles about living or recently deceased people, and edits relating to the
subject (living or recently deceased) of such biographical articles (ARBCOM
decision)
pages related to post-1932 politics of the United States and closely related people
(ARCBOM decision)
pages related to coronavirus disease 2019 (COVID-19) (Community decision)
including this article.
Provided the awareness criteria are met, discretionary sanctions may be used
against editors who repeatedly or seriously fail to adhere to the purpose of
Wikipedia, any expected standards of behaviour, or any normal editorial process.
Headbomb {t · c · p · b} 01:10, 9 December 2020 (UTC)
I proposed something similar to AC in July/Aug. Those things also need bigger

changes though, and I suspect any change will happen in a bundle.
ProcrastinatingReader (talk) 02:58, 9 December 2020 (UTC)
Agree banner spam as with edit notice spam is a problem all over. First step in my
view would be to purge lots of junk at Category:Article talk header templates like
Template:Editing Friday, Template:Model article, Template:Prone to spam,
Template:Webcomics refideas..etc.--Moxy 🍁 23:46, 9 December 2020 (UTC)
Would it be possible to somehow replace some of those templates with some sort of
empty template so that pages that use them don't end up with red links but rather
simply have the banner disappear?
Another idea: How about a limit on the number of words in all banners combined?
Alternative: How about some sort of bot that goes through every page and creates a
list of all pages with more than X words, with pages with the wordiest template
collections at the top? (what page does have the largest banner section?) --Guy
Macon (talk) 01:09, 10 December 2020 (UTC)
What's the "redlink problem" exactly? The only banners that have redlinks in them,
to my knowledge, is stuff like prompts to create a GA subpage when starting a GA
review. Headbomb {t · c · p · b} 01:37, 10 December 2020 (UTC)
So you are saying that we can just delete a banner and the pages that have that
banner on them will not have redlinks? Let's try:
Template:this is a bogus banner
Looks like a redlink to me.
Again, instead of deleting those banner templates, would it be possible to somehow
replace the templates with empty template so that pages that use them don't end up
with red links but rather simply have the banner disappear? --Guy Macon (talk)
20:54, 12 December 2020 (UTC)
Again, I ask, what exactly is the "red link problem"? If there's a non-existent
banner on a page, just remove it. Headbomb {t · c · p · b} 03:42, 13 December 2020
(UTC)
And again I answer, deleting a banner is easy. Deleting a banner that is used on a
lot of talk pages is an effective way to accomplish a "radical reduction of talk
page banners". Some of these banners are used on 500,000 pages. That makes it a
red-link problem if the banner is deleted. Saying "If there's a non-existent banner
on a page, just remove it" is not a solution unless you, personally, are willing to
make a commitment to "just remove" all 500,000 redlinks. Again I ask, (if you can
please refrain from derailing my question by once again replying with claims that
the problem does not exist when it obviously does), would it be possible to somehow
replace the templates with empty template so that pages that use them don't end up
with red links but rather simply have the banner disappear? Headbomb, please let
someone else answer my question. We are all well aware that you think that the
problem does not exist and that I think it does. --Guy Macon (talk) 18:54, 16
December 2020 (UTC)
And AGAIN, I ask, what exactly is the "red link problem". Where is it? Do you have
examples? You still have to substantiate that there's a plague of redlinks on talk
pages which are somehow problematic. Headbomb {t · c · p · b} 21:23, 16 December
2020 (UTC)
I am going to stop replying to you now per WP:CIR. If you can't grasp the
difference between saying that if certain templates are deleted this will cause a
redlink problem and saying that the redlink problem already exists, I am afraid
that I cannot help you. Feel free to get in the last word. I will not respond.
--Guy Macon (talk) 23:39, 16 December 2020 (UTC)
So wait, your problem is that if hypothetically, you deleted a banner used 500,000
times, it'll have 500,000 links red left behind? The solution to that is to either
to a) not delete a banner obviously in extensive use b) convince the community the
banner shouldn't be used at WP:TFD and use bots to remove it or c) mark the banner
as historical and simply have it display nothing. Headbomb {t · c · p · b} 07:33,
@Moxy: Nominated {{Webcomics refideas}} for WP:CSD#G7 speedy deletion. –MJL ‐Talk‐☖
03:57, 13 December 2020 (UTC)
I don't see this as a problem. I find the banners play a role similar to that of my
unabridged Webster's 2nd, my Columbia Encyclopedia, and my bilingual dictionaries:
I don't pick up one of those tomes every day, or even every month sometimes; I walk
by them all the time without even seeing them; but they are there whenever I need
them, and it's extremely annoying if someone has misplaced one of them and I can't
find it when I need it. Ditto many of the page banners; it's mightily annoying if
they are not there when I want them. Slap a {{skip to bottom}} template at the top
of the Talk page, and you're done. What exactly do you want to do on a Talk page,
other than to view the ToC, go to the bottom of the page, or click a notification
that takes you straight to the discussion in question, for which banners are an
impediment to doing what you want? Mathglot (talk) 08:17, 12 December 2020 (UTC)
This is not a good analogy imo. Partially because the reference books aren’t
impeding the entrance, but mostly because you’re vaguely familiar in your head
where the books are and what they’re for. A new editor seeing this wall of banners
doesn’t even know what they’re missing! Do they click skip, or do they read all the
big alerts saying warning/caution/controversial etc, maybe in them some information
they need? You and I have the knowledge that it’s all junk so we don’t read it, but
they don’t even know yet. Hey, if you want to edit skip to talk with “All the below
is junk. Just skip to talk.” In big bold letters and add it auto to pages, then I
guess the solution is not so bad. ProcrastinatingReader (talk) 09:53, 12 December
2020 (UTC)
It's really great to see that this conversation is taking place. I strongly
disagree with Mathglot because this is a problem that I think ruins the
accessibility of a lot of talk pages, especially the ones where the talk page
matters the most such as many of the examples given above. I agree with the
shortening of the vital articles banner. The template for British vs American vs
Hong Kong vs Indian etc English is utterly useless on the talk page, and has little
to no effect on the vast majority of issues that arise here (random editors coming
in to change a "misspelling"). This definitely needs to be as an edit notice and
not the talk page. In fact, I wonder if this could be configured so that if it's
placed in the talk page it doesn't show up there put shows up as an edit notice on
the article page – so that we wouldn't have to go through and change/remove all of
them, though I suppose a bot could do this. Aza24 (talk) 01:55, 14 December 2020
(UTC)
An ideal banner would a clear importance, audience, and process. Banners detract
from an article; they are at the top, but are not crucial for the reader. Their
purpose is to flag that work needs to be done, but for the majority of readers this
is unimportant; only editors need to be warned about BLP. The process to do with
each banner is unclear; there is not a clear call to action, sometimes "drive by"
editors add them with no explanation on the talk page, no clear ownership of
banenrs, banners suggest talk should take place on pages with no watchers, and the
numbers do not appear on project pages. My preference would be that banners
disappear for all except editors, that banners be clear and simple, and that bots
are used to make them expire Wakelamp d[@-@]b (talk) 08:57, 14 December 2020 (UTC)
Wakelamp do correct me if I'm wrong, but I think you're confusing
cleanup/maintenance templates (see WP:CLEANUPTAG) on the articles themselves with
templates (banners) on the talk pages of articles (the topic of this discussion).
Aza24 (talk) 09:06, 14 December 2020 (UTC)
Aza24 You are correct. I am confused. Excuse my rant about the article template :-)
My suggestion for talk pages. I don't actually read them. Many are advertisements
for projects, or about the status within a project. Wakelamp d[@-@]b (talk) 12:43,
Before the AH and banners templates
After the AH and banners template

Talk:Karl Marx is fine now. Some of the areas causing problems have been missed in
this discussion.
GA drops in templates instead of building articlehistory. DYK drops in templates

without integrating them to the articlehistory template. OTD drops in templates
rather than building articlehistory. ITN drops in templates rather than building
articlehistory. Vital articles drops in templates rather than placing them in the
WikiProject banner shell. I have approached the bot about Vital articles, and that
is being addressed. The problem with the other templates being dropped in is that a
prolific sockmaster hounded the editor off the project who used to run a bot that
processed every single template on talk that related to the articlehistory in to
that template, so I have been running around doing that work manually.
If those issues were addressed, and editors would simply clean up talk pages as I
have been doing now for several months, we would see that the problem isn't as bad
as it appears and not nearly as bad as it was before Gimmetrow and DrPda initiated
the effort to tame talk clutter in 2007. Skip to talk is rarely needed, the
duplicate archive boxes can often be deleted, and the useless templates like WikiEd
and English variety can be rolled in to a banner. The real problem is the need for
a bot to clean up articlehistory items, as I have been doing on FAs. (Karl Marx:
Projects to banners, OTD to article history, banner holder for English variety and
archive info, remove one that is essentially duplicated in talk header, and now
skip to talk is no longer needed.)
The discretionary sanction banners can be dealt with by electing arbs who will deal
with editors with behavioral problems rather than pushing problems off to other
admins via DS. It is astounding that what one bot did over a decade ago to tame
talk clutter is no longer being done; surely our coding ability has advanced since
2007 ? Apparently this work I have been doing for several months now is well
received, as I am not aware of having been reverted even once. Surely some clever
bot or script person can do this work; they once did. SandyGeorgia (Talk) 15:05, 15
December 2020 (UTC)
Vital articles WikiProject continues cluttering talk pages

Messes like Talk:Transit of Venus created by edits like this continue more than a
full decade after the last successful effort to tame talk clutter. In my months-
long effort to tame the clutter on FA talk pages created by ITN, OTD, GA, DYK, and
WikiEd, I am finding the biggest issue continues to be an unresponsive Vital (sic)
articles WikiProject. SandyGeorgia (Talk) 09:35, 22 December 2020 (UTC)
@SandyGeorgia: interesting, and thanks for your thorough comment above! Is there a
bot proposed to take over the work of GimmeBot, or is anyone working on this atm
that you know of? Have any of GimmeBot's functions been replaced by another bot, or
has it created a void? Regarding Vital Articles, do you think we could get a
consensus to scrap banners for level 4/5, leaving just levels 1/2/3 having talk
page banners (1110 pages I think)? ProcrastinatingReader (talk) 04:18, 30 December
2020 (UTC)
Putting this on my list to give a full accounting ... may take me a day or two as I
am behind everywhere. SandyGeorgia (Talk) 07:58, 30 December 2020 (UTC)
Summary of talk page clutter issues
Responding to ProcrastinatingReader's query above, with a broader summary of what I
have found after several months of working to tame talk page clutter on Featured
articles.
What I have done for several months now is to go through every current FAC, FAR,
PR, TFA or OTD that relates to an FA, to clean up those talk pages. I 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)
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)
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)
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)
See
Wikipedia:Templates_for_discussion/Log/2021_January_8#Template:WikiProject_banner_s
hell. 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].
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}}?
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)
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)
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)
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)
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)
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.
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)
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,
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)
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)
English variety
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)
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.
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)
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)
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. --Paul ❬talk❭ 11:54, 9 January 2021 (UTC)
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.
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. --Paul ❬talk❭ 16:38, 9 January 2021
(UTC)
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)
Unbundling for the millionth time
This current AN discussion had me thinking about a human-powered, not bot-powered,
solution to the occasional case where an IP will hang out at a page for a while,
repeatedly vandalizing, for the hour or so it takes an admin to show up. Add a
group of editors who can add a template to a page that'll cause an adminbot to
protect it for an hour; perhaps also require that the page has a high number of
recent reverts. (Bonus: for a single IP hopping to multiple pages, another template
that'll cause an adminbot to block them for an hour, requiring perhaps that every
edit by that IP has been reverted.) I feel like similar proposals were discussed
recently, but couldn't find any, hence this post. Enterprisey (talk!) 03:54, 7
December 2020 (UTC)
I feel like similar proposals were discussed recently I remember a recent proposal
which was something along the lines of non-admins being able to protect a page for
24 hrs / block IPs for 4 hours, or something along those lines. Can't find it at a
quick check of archives, but then again using Special:Search is too hard for me.
That having been said, I think the AN thread can be mostly handled by the filter
Suffusion of Yellow is working on. ProcrastinatingReader (talk) 11:14, 7 December
2020 (UTC)
ProcrastinatingReader, I think that was this thread I started. It never got
formally closed, but my informal reading was that while it wasn't shot down in
flames, it wasn't riotously supported either. -- RoySmith (talk) 18:56, 8 December
2020 (UTC)
I like this idea I guess, but should be increased to up to 48h for IPs and semi for
a few days, to have it actually be useful. An hour is just insufficient. Blocks to
IPs vandalising should be favoured over protecting a whole page probably.
One hour blocks get rid of the vandal whose just bored while sitting around in a
computer lab or on the train. More intractable vandals should be dealt with by
admins and CU anyway given the larger toolbox they have to shut down the vandals
long term Slywriter (talk) 13:26, 8 December 2020 (UTC)
@Enterprisey: without relying on an enancting bot (and thus making the botop
responsible for their actions) or software changes if we really wanted to some sort
of fast-SPP we could possibly use the edit filter possibly like this: (a) define
who can do this (perhaps all rollbackers) (b) set up an edit filter that only
allows this group to add a special template to a page (possibly only to articles)
(c) set an edit filter to not allow editing of pages with that template on them by
non-confirmed users. (d) Now use a bot, that can run on in batch to go and clear
out any of those templates that has been present for more than x time. (Of course
any rollbacker/admin can manually remove it). — xaosflux Talk 15:07, 8 December
2020 (UTC)
This could be similar to Special:AbuseFilter/803 which provides the base-userpace
SPP functionality, but would be non-blocking by default. — xaosflux Talk 15:16, 8
December 2020 (UTC)
I remember from an IP this morning that I rollbacked, often these people just move
to another article (or roll you back) and rolling back is just clogging up the
article history. I think the core element of this is to be able to temporarily
block an IP address, otherwise some poor bloke is chasing an IP around adding
{{cannotedit}} onto pages the IP hops onto until an admin finally comes around and
dishes out a block. It kinda just wastes time for people chasing an IP around, I
feel, and will create unnecessary protections.
Speaking of that thread, I found where this discussion happened before!
Wikipedia:Village_pump_(idea_lab)/Archive_32#Staying_ahead_of_the_moles_(as_in_whac
k-a) (RoySmith may be interested in this?). Not exactly the same, but similar. It
mostly just died out, rather than explicit consensus against, it seems. On
accountability, a bot could log all actions by this 'group' for manual review.
Concern with adding the perms to rollbacker: it may raise the bar for granting the
perm, and that never seems to end well. ProcrastinatingReader (talk) 17:52, 8
December 2020 (UTC)
BTW regarding the accountability point, you did explain accountability vs
responsibility to me before in an elegant way, but I still feel something is off
about this. That convention on botops, to the extent that it has any practical
effects (given TFD/CFDW/patrol bots), is a social construct rather than a technical
limitation, right? I don't see what the real difference is between having the
MediaWiki software do it (through 2 filters + a bot) vs just one bot. Similarly,
the person who wrote the patch in MediaWiki for the technical block functionality
isn't responsible for someone, who the community gave sysop to, going on a blocking
spree. Surely we can amend WP:BOTMULTIOP to say that bot operators are not
responsible for the edit themselves, minus technical bugs, if the person who can
trigger the bot is decided in a manner set and approved by community consensus in
an RfC (which this feature would need anyway), rather than by a process chosen by
the bot operator, and the triggering editor is disclosed and verified? Surely this
kind of amendment makes sense anyway, if the community are the ones setting the
criteria, and unrelated admins are the ones executing said criteria?
ProcrastinatingReader, Yup, you found it. I'm neutral on the details of the
implementation (new core permission, adminbot, whatever) but ultimately I think
some sort of process is necessary, akin to Citizen's arrest. The idea is that a
(much) larger population of users is empowered to make temporary, scope-limited
interventions to stop vandalism, faster than the much smaller admin corps can
react. There are, of course, lots of details to worry about to prevent abuse: who's
authorized to do it, how long they can protect/block for,
reporting/review/accountability, etc. -- RoySmith (talk) 19:10, 8 December 2020
(UTC)
So, let's talk strategy. This is a proposal that many people (including me) like,
but we have to face the reality that similar proposals have been shot down in the
past. Because of this, IMO any proposal should start very conservative -- ignoring
all cries that it isn't enough -- and then after it shows itself to not cause
problems, we can discuss possible modifications. I would propose:
Stop discussing how to do it until we have a consensus to do it. Early focus on
implementation details destroys good ideas. First decide what you want to do
assuming that you can do anything. Then decide what the closest thing that you
actually can do is.
Six-month Three month limited trial, tool disabled and discussion started on
whether to re-enable at the end of the trial.
Stop the trial early if there is a consensus that it was a bad idea.
Based upon a permissions list.
Editors must request permission. Only given to extended confirmed editors in good
standing.
Limited to one hour of blocking for IPs only. No page protection.
Cannot be used more than 10 times in any rolling 7-day period.
Draconian punishment for abuse. I would suggest a six month block and a two-year
revocation of permission to use the tool on the first strike.
If someone proposes the above and it gets shot down, we will pretty much know that
any proposal that involves any unbundling will be a waste of effort. --Guy Macon
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: making new core permissions will require development time
(see phab:T128328 for the 2016 request that would need to be done for some of this)
- for a trial you may want to use "administrative controls" (i.e. a policy /
"rules") instead of hoping a developer delivers on that and that it gets
incorporated to core. — xaosflux Talk 20:05, 8 December 2020 (UTC)
Ending up with a de-facto "I'll know it when I see it" works just fine for
Wikipedia:IP block exemption, and is sufficient for a tree-month trial. --Guy Macon
I'm not sure I agree. See, eg, this. The people we want having this tool may not be
bold enough to ask if they feel the bar is too high, and granting admins may not
know what to look for. A lack of granting criteria has caused broken permissions
processes every time, and clear criteria (ie, most other perms) has created a
somewhat functional system. IPBE is quite different in that people are forced to
ask for it, or else they literally cannot edit. Nobody is forced to ask for the
block button, they can keep painfully spamming !admin on IRC. Whether "I'll know it
when I see it" is sufficient for a trial, well, perhaps? But I'm not sure it's very
reassuring for people voting on the proposal; I have a picture of the bar in my
mind, but I have no clue if that bar is the same, much higher, or much lower, as
the picture in yours (also note EFH, TPE PMR all proposed criteria). But I see the
point that drafting a clear criteria is just another point to debate on, which may
be equally as tricky as the proposal itself, and should maybe wait till post-trial
review. How about the granting process? Can any admin grant on request, or should
it be like an EFH process where it's advertised on a noticeboard for 3 days of
comments and closed by an uninvolved admin? ProcrastinatingReader (talk) 21:09, 8
December 2020 (UTC)
Alternative limit: at most 10 outstanding blocks at any time (blocks "taken over"
by an admin don't count). Which raises the question of whether admins would even
bother blocking an IP that's already under an hour-long block. Enterprisey (talk!)
11:17, 9 December 2020 (UTC)
Just noting, it is trivial to make an access group that can technically fully use
the Block interface, and make a community rule that says that members of that group
may only use the access in certain conditions and with certain parameters. (Protect
is a bit of a messier situation, but such a group could be combined with the
AFilter info above). — xaosflux Talk 19:19, 8 December 2020 (UTC)
For the more enwiki-focused here, I'll add Meta has the similar concept of "limited
admins" - they have the full toolkit but are only allowed to use it within
$scope_requested_at_rfa (could be time, specific tasks, things like that), straying
out of those bounds is grounds for immediate desysop. So there is precedent for
"here's $permission, you may only use it for $tasks" GeneralNotability (talk)
21:21, 8 December 2020 (UTC)
GeneralNotability, We have some of that on enwiki too. Don't election scrutinizers
get temporary CU rights? Are don't we also have an "event organizer" role that
gives people running edit-a-thons the ability to create accounts and grant them
confirmed access? -- RoySmith (talk) 21:30, 8 December 2020 (UTC)
@RoySmith: the scrutinizers must already be global stewards, so that's really no
big deal; the event coordinator is closest - they are allowed by policy to confirm
accounts - but only for up to 10 days (though the system does not technically
enforce that).
@GeneralNotability: I doubt the m-w "limited admin" style itself would fly here,
but the concept of only being allowed to use permissions for certain things may.
There are some other projects that have a limited-admin-like group that has a
subset of admin tools (like block and delete or other combos) - canonically this is
usually called "eliminator" but can be styled locally however. Rules and control
can be whatever is good for the community and so long as undelete/viewdelete are
not involved it doesn't require an "election" system. — xaosflux Talk 02:50, 9
December 2020 (UTC)
I support anything that gives us a role called Eliminator. No questions asked.
GeneralNotability (talk) 04:12, 9 December 2020 (UTC)
Now that's a hat to collect. —valereee (talk) 10:37, 9 December 2020 (UTC)
Looks like we’ve found a name too! ProcrastinatingReader (talk) 10:51, 9 December
2020 (UTC)
ProcrastinatingReader, I was actually being facetious. It's a great name, but I
think it will attract bad actors because they want that hat and the accompanying
userbox. Sorry, I should have indicated I was being facetious. :) —valereee (talk)
13:22, 10 December 2020 (UTC)
In my opinion -- and I do have quite a bit of experience in the area of technical
proposals -- "I think some technical aspects matter, to relax people" is a common
mistake. Here is the right way to do things:
Step 1: decide what you would like to do without any thought of implementation
details.
Step 2: look at the technical issues, figure out what is possible given the budget
and deadline, and modify what you came up with in step 1.
Step 3: create a concrete proposal and see if it flies.
You don't need "to relax people" until step 3. Every time something like this comes
up in discussion, some well meaning person gets into the weeds of what is and isn't
easy to do before there is agreement as to what to do. I get it. I have the same
tendency and did it that way before I learned a better way. Getting into
implementation details too early kind of sort of works OK, but my way works far
better. --Guy Macon (talk) 21:18, 8 December 2020 (UTC)
Guy Macon, What you're describing is certainly what goes on in the software
development world. Product management comes up with what's often called a PRD
(Product Requirements Document) which describes what they want the feature to do.
Then they get together with the developers who, after they stop laughing, tell
product management what's technically possible. Then, the two sides hopefully
converge on something that's both useful to the user and possible to build. --
RoySmith (talk) 21:35, 8 December 2020 (UTC)
I am guessing the answer to step 1 is currently "create a group which can place
blocks on IPs for up to 1 hour". And we have your bullet-pointed list above as a
start. So, what exactly comes next? ProcrastinatingReader (talk) 21:35, 8 December
2020 (UTC)
Stage one
Confirm that we have a local consensus (just us in this discussion) for 1 hour and
not some other duration (does anyone object?)
Confirm that we have a local consensus for a three month trial (does anyone
object?)
Decide who should be allowed to use the tool during the trial and who will grant
permission.
Decide what happens if someone abuses the right. (I vote for very harsh penalties,
with the penalty made clear to anyone who asks for the user right.)
Come up with a catchy name. (This is actually one of the main things that
determines whether the proposal passes)
Stage two
Take the above and start discussing ways to accomplish this during the trial,
modifying the requirements as needed.
Come to a consensus as to not only what we want to do but how we want to do it.
Stage three
Draft an RfC, giving everyone a chance to criticize/modify it before going live.
Post the RfC.
Populate the early !votes with !votes from those of us who have been working on
this.
Get shot down in flames just like every previous unbundling proposal.
Get very, very, drunk.
--Guy Macon (talk) 22:59, 8 December 2020 (UTC)
Gotcha. On harsh penalties, I feel like we go overboard here. We shouldn’t try to
overly scare competent editors who offer to volunteer their time for free. To that
end, maybe just say that it’s an admin-level permission and so WP:TOOLMISUSE
applies? ProcrastinatingReader (talk) 23:52, 8 December 2020 (UTC)
ProcrastinatingReader, TOOLMISUSE seems like the right standard to apply. A good
(if imperfect) analogy would be WP:NAC. We carved out a process previously reserved
to admins and allowed non-admins to do it. There's limits on what discussions non-
admins can close, questionable ones regularly get reviewed at WP:DRV, and every
once in a while there's somebody doing NACs who is doing a poor job of it, and
they're "encouraged" to not do them any more. I don't know of any cases that got as
far as a formal NAC WP:TBAN being enacted, but I wouldn't be surprised if there
have been some. Overall, it all seems to work.
The only difference is that with NAC, the "only admins can do it" was a convention,
and with blocks and page protections, it's enforced by the software. But, that's a
detail. The software exists to serve the needs of the community. If it's not doing
what we want, we either change it or route around it. -- RoySmith (talk) 03:09, 9
December 2020 (UTC)
For granting, two wild ideas: the usual PERM process, except require two admin
approvals? Or the usual PERM process, except no self-noms? (So I guess candidates
would have to ask someone else to nominate them.) I have done zero thinking through
of the drawbacks of either. Enterprisey (talk!) 09:39, 10 December 2020 (UTC)
Why not both? Must be nominated by some other editor ('surprise nominations' are
okay, encouraged even). Open for a minimum of 48 hours, if two admins agree and
there's a consensus to promote (ie not 10 other admins saying "bad idea!") any
admin can close the discussion and grant the permission?
For revocation, TOOLMISUSE standard: any admin who believes the permission has been
abused (or used outside of its approved scope) may revoke it immediately, and
should start a follow-up discussion at AN for the matter to be discussed.
I like how that sounds. (This is reminding me a little bit of the interface admin
discussions, haha.) Enterprisey (talk!) 09:48, 10 December 2020 (UTC)
What if that "some other editor" nominating is an admin? Do they count for the
admins agreeing? Majavah (talk!) 09:52, 10 December 2020 (UTC)
Hm, I can see both sides. I think it's simpler and more consistent just to say no
(admin nom doesn't count), so that by design at least 3 editors (1 admin/non-admin
nom, plus 2 admins concurring) have agreed on each request.
As an aside, the point of nomination-only in my eyes is: (a) grossly unqualified
candidates won't end up nominating themselves and having to go through the
rejection; (b) candidates too scared to nominate themselves won't be prevented from
getting a right to help their workflow (and consequently, improving the
encyclopaedia). I don't think this has any obvious downside: any competent person
consistently reporting IPs at AIV will have gotten the attention of someone.
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:
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?)
Unbundling proposals based on what might pass, not on what's actually needed.
Backlogs aren't that bad and admins can deal with the workload
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"
Will lead to controversial blocks
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.
Scope so narrow that any benefits aren't worth the developer effort
Some of these maybe can't be defended against in the proposal (eg #4 is just
idealism). And #6 I think misses the point, in that this intends to put a stop to
ongoing vandalism when an admin can't respond fast enough, the time the admin
would've spent blocking before is equal to the time they will spend blocking after
the proposal. The difference is that a vandal-fighter, instead of chasing an IP
around for half an hour, can just press block and submit a report to AIV and move
onto the next person. We can maybe think up stuff to deal with the other concerns,
though? ProcrastinatingReader (talk) 11:19, 10 December 2020 (UTC)
Also, the original 100-person RfC, despite ~50 opposes, nobody raised concerns with
the proposed 48 hour block duration / proposal that non-autoconfirmed can be
blocked as well as IPs. So I think we can loosen those restrictions (1hr is
probably too short, and will create more cases where a normal admin has to issue a
follow-up block, given the normal blocking period is ~31 hours).
I'm not sure I agree with the concept and I don't like the name, maybe moderators
or proctors? Given that many IP blocks are usefully 31 hours - excluding kids from
that school day and the next, I think that if this proposal is going to be of any
use it needs to be 31 hour blocks, or at least something more than an hour. It also
needs to specifically exclude incidents that are disputes between people who could
and could not be blocked by these admin lites. As for the 12 month tenure, you can
pass RFA with not much more than that. How about must have edited in at least 8
different calendar months? ϢereSpielChequers 12:29, 10 December 2020 (UTC)
@WereSpielChequers: I'm not sure I agree with the concept Can you elaborate on this
part too (is there also something fundamentally flawed here)? ProcrastinatingReader
WereSpielChequers, the concept behind one hour is that it gives an editor who is
fully-busy with reverting the vandal time to report and get an admin there to
reblock for 31 hours. I love eliminator but I think it's going to attract bad
actors who want a superhero userbox. Even proctor sounds too "I'm in charge here"
to me. Maybe something like "temp-protect"? —valereee (talk) 13:19, 10 December
2020 (UTC)
Fair. "Moderator" makes me think of censorship or something like reddit, in today's
political climate, so eh. If eliminator etc is too much, maybe we can just be bland
(eg indeed "tempprotect", or name it after the perm - "blocker", or "abuseblocker",
etc). ProcrastinatingReader (talk) 13:34, 10 December 2020 (UTC)
FWIW I don't even like admin. :) Anything with "blocker" in it is probably too
attractive, IMO. Moderator IMO has the same problem. And, yes, blandness in this
case I think is much-to-be-sought-after. —valereee (talk) 13:45, 10 December 2020
(UTC)
Yeah, I really hate the "eliminator" name. Maybe "first responder"? The analogy is
to an EMT who rushes in to provide immediate intervention, gets things stabilized,
then hands off to a more experienced team (Emergency Room doctors) for follow-up
treatment. Keep it positive. -- RoySmith (talk) 14:04, 10 December 2020 (UTC)
If blandness is the goal, how about "support"? Like how it's understood that a
Police Community Support Officer has the official capacity of Just Some Guy --Paul
❬talk❭ 14:36, 10 December 2020 (UTC)
I like that. No one is going to apply for support permissions for the sake of
bragging rights. —valereee (talk) 16:10, 10 December 2020 (UTC)
There's also a mixture of the above, like "medic" (as in stop the 'bleeding' /
first aid). 'responder' also seems okay. ProcrastinatingReader (talk) 16:21, 10
December 2020 (UTC)
I like responder. Bland enough, but not too. —valereee (talk) 20:34, 10 December
2020 (UTC)
I'm in the camp of people who think that the solution to a shortage of admins is to
appoint more admins. ϢereSpielChequers 13:14, 10 December 2020 (UTC)
Ah, okay. For context (since it probably seems out of the blue): I pinged as you
proposed these two in 2013: [3][4], which seemed kinda similar (though broader) to
this one. ProcrastinatingReader (talk) 13:28, 10 December 2020 (UTC)
WSC, this isn't so much an admin shortage problem. It's an "ACK! Emergency!"
problem. I'll make an analogy: The fire department is five miles away, and it takes
them ten minutes to respond to a fire. We may very well need more fire fighters,
but that doesn't solve the problem. So maybe we should consider making sure we have
smoke alarms & fire extinguishers creating the position of fire warden and arming
them with fire extinguishers.. —valereee (talk) 13:31, 10 December 2020 (UTC)
This is similar to things I proposed seven years ago, my views have since shifted.
It is indeed an "ACK! Emergency!" problem, but that makes it a subset of our admin
shortage problem. The Firefighter analogy is a good one, except that firestations
cost money, as do fire-engines and usually firefighters. Since admins are unpaid,
they are the equivalent of deploying smoke alarms and fire extinguishers and
appointing and training people as fire wardens to evacuate office buildings when
the fire alarms go off. Most of us don't want our admins to be paid, or even to be
so busy being admins that we don't have time to do the non admin stuff that may be
the main reason why we are here. The way to prevent that is to have lots more
admins. ϢereSpielChequers 13:54, 10 December 2020 (UTC)
WereSpielChequers, I agree that we need more admins, but that's a bigger and harder
to solve problem. People don't want to subject themselves to the ritual hazing that
goes on at WP:RfA, and honestly I can't blame them. -- RoySmith (talk) 14:09, 10
December 2020 (UTC)
I agree that RFA can be a ritual hazing, but I believe its reputation is worse that
the reality. It is afterall still capable of giving candidates 100% support as has
happened twice in recent months. ϢereSpielChequers 16:30, 15 December 2020 (UTC)
WSC, great, so back to the analogy: this creates the position of volunteer fire
warden. :) —valereee (talk) 15:56, 10 December 2020 (UTC)
I stand corrected, As admins are unpaid we are more akin to firewardens than
firefighters. There is no reason to limit the numbers of such volunteers.
ϢereSpielChequers 16:30, 15 December 2020 (UTC)
@WereSpielChequers: I think the point valereee was trying to make (or at least how
I read it) is less the paid/volunteer distinction and more that people can still be
useful in preventing fires (given the right training and tools) without having all
the knowledge, qualifications and trust it takes to become a firefighter. The
rebuttal is probably that we can just make people firefighters and trust that
they're sensible enough to only respond to the fires they can handle and learn
along the way and then tackle bigger fires. But then we'd have to introduce the
Firefighter Appointments Board into this analogy. ProcrastinatingReader (talk)
12:26, 16 December 2020 (UTC)
Yes. But there are some differences between this proposal and say the unbundling of
template editing. Firstly a lot of editors at RFA care deeply about who gets to
block people, and that makes it unsuitable for unbundling. Template editor was a
successful unbundling because it didn't involve either of the "third rails" that
get most attention at RFA. This proposal involves blocking, one of the "third rail"
issues at RFA. The proposed requirements are pretty close to an RFA minimum
requirement - 12 months tenure, whilst template editor is available for people who
can edit templates, a topic that rarely ever even arises at RFA. Unbundling
template editor actually reduced the admin workload, as indeed would a 31 hour
block for IPs. But a very short block doesn't reduce the admin workload,
complicates IP's block logs because instead of a 31 hour block you will now
sometimes get a one hour block upped to 31 hours by the reviewing admin. Unbundling
the power to block newbies and IPs for the lengths of time that admins do would
actually save admin time, so in that sense it becomes tempting. Though it would be
better to recruit more admins. BTW, you've missed two of the arguments against such
an unbundling. The mop is a toolset, and block is not always the right tool.
unbundle just that hammer and you risk having it be used where page protection
would be the better tool or where both block and revision delete should be used.
Secondly there is the idealistic one that all editors should be equal, and this
means that we would be more ready to block newbies than the regulars (I don't buy
this last reason myself, but I believe others will). ϢereSpielChequers 13:34, 16
December 2020 (UTC)
@WereSpielChequers: I think I get what you're saying overall. On some of the
specifics: the stricter requirements and the 1 hour block I believe was intended to
make the proposal more digestible (and then add on it with time as appropriate),
but do you think in reality it actually does the opposite? Regarding toolset, I
think the idea was that people with this group don't act when the necessary action
is outside of their tools, and in those cases resort to doing what they do now
(report/find an admin).
But I think the overarching idea is whether this functionality should be unbundled
at all? Or if, to the extent that it should be unbundled, those terms will gain
community consensus. Do you think there's a way to remedy this proposal in a way
that makes it both more useful, and more acceptable to the community when it goes
for RfC? If not, and if this is a doomed proposal, what else can be done about the
real problem it tries to address? ProcrastinatingReader (talk) 17:29, 19 December
2020 (UTC)
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?
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)
@ProcrastinatingReader: thanks for failing to live up to your user name by writing
this draft. In particular, thanks for doing the research to find all the earlier
discussions. I can nitpick some details, but overall I think it's workable. It's
certainly good enough for a trial; at the end of 3 months we'll know more and can
evolve the concept based on our experience. My one question is the 1-hour block
window with respect to WP:AIV response time. Do we have any statistics on how long
requests usually sit in the AIV queue before being serviced? I'm looking at it now
and see a couple (one bot, one user) that are 3-1/2 hours old. If that's typical,
then maybe a 3-6-hour block would be more appropriate? -- RoySmith (talk) 14:31, 10
December 2020 (UTC)
I've been intending to slap together some code to answer that and the related
question of "how much time is actually wasted with these constant reverts", but I'm
working on stuff for my wikiconference demo; maybe next week. I agree increasing
the block length might be appropriate. The block length could be increased even
further with additional restrictions on the blocks' usage, such as requiring every
(90%?) edit by the user to have been reverted. Enterprisey (talk!) 02:36, 11
December 2020 (UTC)
That would be an interesting statistic to put into the background section! The
latest RfA (from Hammersoft) also gave me an interesting one (saving me the
digging): WP:AIV has been tagged as backlogged more than 40 times in the past week.
It's worth noting a bot removes 'stale' AIV reports after 4-8 hours, but it's
likely most of these are ones where no action was required. ProcrastinatingReader
One place where you can find these examples, btw, is the history of
User:ProcBot/EW. Ranges from 20 mins to a couple hours till block. At a glance atm,
most are in the middle of that range. ProcrastinatingReader (talk) 23:39, 11
December 2020 (UTC)
@ProcrastinatingReader and Enterprisey: - a couple of bits from me. Was there a
reason that unbundling block, rather than protect, was considered? I would have
thought that objections to ultra-minimal semi-protecting (otherwise in line with
the limits here) would be less controversial. A mis-targeted block is an ultra-
aggressive action to happen to you, whereas protects don't risk losing the user
permanently (at the tradeoff of being broader). Whatever route is taken, it should
note that the same requirements of WP:ADMINACCT will apply to their use by first
responders. I would actually suggest 3 hours - this is particularly key in the
admin inactive bubble (0300-0800 UTC). Nosebagbear (talk) 12:12, 16 December 2020
(UTC)
I think whilst protect may be more acceptable to the community, I think it's a very
bad idea and not in line with the protection policy. One vandal hops across many
pages, and they all end up semi-protected for an hour (or few), repeat until an
admin comes and blocks? Where do we draw the line? 100 pages semi-protected, rather
than blocking the one IP causing trouble? What if they are causing havoc at AN?
Protection stops everyone (not autoconfirmed) from editing, whereas blocks only
stop the vandal from editing. I get the fear of mistargeted blocks, but blocking
solely obvious vandalism is a much lower bar than what admins have to do (block for
disruption / edit warring / content disputes, all that more discretionary stuff),
and the kinds of people I am thinking in my head with this perm would not make this
error in distinguishing. I honestly think the error rate here will be equal, or
lower, than what the error rate by admins is. ProcrastinatingReader (talk) 12:20,
ProcrastinatingReader, Blocks and protection are different shaped tools; the sets
of problems they solve are different, but overlapping. Somebody with a dynamic IP
can vandalize a single page from many different addresses (protect) One person can
vandalize many pages (block). Ultimately, it would be useful to extend both of
these tools (in a limited way) to non-admins. But for an initial proof-of-concept,
we should pick one and see how it goes. At some point in the future, we can come
(presumably) back and say, "This is working. We've figured out authorization,
monitoring, corrective action for abuse, etc, and put processes into place which
solve the problems we discovered as we went. Now, let's give them the other tool as
well". With that in mind, I don't think it's critical which of the two we offer
first. -- RoySmith (talk) 14:35, 16 December 2020 (UTC)
ime the scenario of one account/IP being a problem (on one or multiple pages) is
more commonly seen than multiple IPs on one or more pages. But when I asked a few
people offwiki for thoughts on this idea, I generally got the gist that people are
more favourable towards protection than blocking, so it may well be that's more
appropriate. That said, it would take more judgement to use and more incorrect
usages (or, less usages in general, if used correctly) I fear. The protection of a
page where just one IP is engaged in vandalism would (in most cases, at least) be
contrary to the protection policy I'd think? ProcrastinatingReader (talk) 17:16, 16
December 2020 (UTC)
I originally envisioned it as actually unbundling both; probably just one would be
easier to pass, and as per the above, both have their pros and cons. Protection, of
course, would be the proper tool if a single article is seeing disruption from a
variety of non-autoconfirmed editors, but intuitively this is rarer than the one
editor/many articles case, so unbundling blocking would then have a higher impact.
Enterprisey (talk!) 07:53, 17 December 2020 (UTC)
but intuitively this is rarer than the one editor/many articles case. This is my
experience as well. The two most common cases I encounter are A) An single account
vandalizing a whole bunch of pages and B) An single account continuously
vandalizing an single page. In my personal experience the single article/many
accounts is incredibly rare with the last one I can recount weeks ago. Merry
Christmas! Asartea Talk Contribs! 12:30, 17 December 2020 (UTC)
Conduct dispute resolution systems
How are our conduct dispute resolution systems working for us? How can they be
improved? (This is an opinion-soliciting discussion, not a proposal to vote on.)
List of conduct dispute resolution systems:
Noticeboards: WP:AN, WP:ANI, WP:ANEW, WP:AIV, WP:RFPP, WP:COIN, WP:UAA

Arbitration: WP:ACDS (WP:DSLOG), WP:AE, WP:RFAR, WP:ARCA
WMF: m:T&S, m:UCOC (proposed)
Historical: WP:RFC/U
I think the answer to the first question is "not very well", and I'm not sure of
the answer to the second question, but I think it would be useful to gather
opinions about and discuss what the community can do to improve conduct dispute
resolution. Is there a problem, and if so, where? Levivich harass/hound 21:34, 10
December 2020 (UTC)
As I have written previously, there are challenges with collaborative, online
decision-making:
A small number of voices can dominate conversation, drowning out others.
Circular arguments, repetition of the same points, and irrelevant information,
including overly-emotional appeals and personal criticisms, cause people to lose
attention.
Agreeing upon appropriate criteria to bring the discussion to a conclusion can be
difficult.
English Wikipedia's unmoderated discussions have additional challenges:
Participants can write unduly long responses that in a face-to-face conversation
would be controlled through appropriate interruptions.
At any given time, immediate responses are only possible by those in neighbouring
time zones. This reduces the efficacy of dialogue.
Also the voices heard are only a small, self-selected sampling of the entire
community. Even amongst those who are aware of the conversation and are motivated
to participate initially, there is a large percentage who do not have sufficient
interest to maintain engagement throughout the entire discussion.
I've also written about the problems with using consensus as a decision-making
approach in a large group. When an entire group is strongly aligned in its goals,
consensus decision-making can be effective in maintaining a unity of purpose.
Unfortunately, as a group increases in size, it also becomes increasingly unlikely
that all members will be strongly aligned. Consensus decision-making favours those
who are less accommodating over those who are more accommodating, and so
Wikipedia's discussion environment selects for less collegial editors over more
collegial ones. Asking for proof with on-wiki diffs that it is the more collegial
editors who are leaving is a catch-22: first, it would not be collegial to discuss
someone else's lack of social graces; second, most people who stop posting to a web
site just do so, without bothering to tell anyone about it.
Wikipedia's group-discussion process gives additional weight to the most outspoken
editors and gives incentive for uncollaborative behaviour. As I've discussed at
User:Isaacl/Community/Fostering collaborative behaviour and
User:Isaacl/Community/Content dispute resolution toolbox, we should be trying to
craft our processes and procedures so they reward desired behaviour, and make
undesirable behaviour a losing strategy. For example, providing mechanisms to
resolve content disputes in a semi-binding way (perhaps with a revisit respite)
would encourage everyone to work towards a best-compromise solution, as opposed to
trying to win through repetition and participant attrition. Improving content
dispute resolution so it is more effective and doesn't reward poor behaviour will
reduce the need for conduct dispute resolution. isaacl (talk) 22:22, 10 December
2020 (UTC)
I think "not very well" is a fair summary. I've been looking at two difficult
situations recently. I don't feel like we have a system that handles either.
Situation one: Two editors disagree with each other. Both have been blocked for
edit warring; one has gotten in trouble for socking. The main pattern seems to be
that Editor 1 tries to add content and/or a source to an article, and Editor 2
shows up to revert it and to say that everything Editor 1 does is wrong. For
example, Editor 2 will declare that Editor 1's source is wrong because a different
source holds a different POV, or that Editor 1 misrepresents the source by writing
in his own words instead of posting a copyvio from the cited source. In one recent
dispute, a book was quoted that said something like "<subject> has four parts,
namely 1, 2, 3, and 4", and Editor 2 went on at very great length about how the
source does not say that either 3 or 4 have any connection whatsoever to <subject>.
If he weren't so loud and angry about it, multiple times over, you'd have laughed
over that, because the alternative is to cry and then earnestly recommend that he
talk to his doctors soon. I've started wondering this week whether there is some
real-world professional bad blood between these two people. There doesn't seem to
be a way to make them stop.
Situation two: An editor tries very, very, very, very hard. He is also very, very,
very, very literal-minded. He really, truly, absolutely does not understand why
people are upset with his editing, which mostly seems to involve blanking
verifiABLE, already-cited, and otherwise suitable and appropriate encyclopedic
content on the grounds that the sources are, in his opinion, "unreliable" for
anything at all. His idea of "unreliable" sources includes more than one source
that is listed at Wikipedia:Reliable sources/Perennial sources as being generally
reliable. I think it may be a case of black-and-white thinking: if scholarly
sources and mainstream news media are generally reliable for most/general purposes,
then that means that almost all other sources (e.g., primary sources, government
reports, commercial websites, sources speaking about themselves, etc.) must be
unreliable, right? He genuinely does not seem to understand why people yell at him.
He also seems to expect that if you tell him to stop doing ____, then you will list
absolutely every single possible reason why ____ is bad and against policy. If he
understood and agreed with the reasons, then I think he'd stop, but I haven't
actually seen that yet. I've only seen him tell everyone that they are bad and
wrong and that Policy Says™ that he should keep blanking already-cited content
left, right, and center, and that anyone who wants to restore it needs to cough up
sources that meet his idea of reliability. Also, If you only tell him the top three
reasons, and he doesn't agree with one or more of them, then he'll continue
screwing up articles and will be upset when you point out that there are 97 other
reasons why he should stop it. You're supposed to present all hundred arguments the
first time and repeat all of them each round, as if it were a Lincoln–Douglas
debate format, or they don't count.
In the first situation, I don't know how to stop it. In this specific case, there's
a chance that the two editors know each other, so they might be able to settle this
themselves, off wiki. What we need, however, is something that changes the
incentives.
In the second situation, we may be dealing with the limits of Wikipedia:Competence
is required, and maybe we just need a somewhat less sympathetic or optimistic admin
corps. OTOH, it's never any fun to play the heavy in these situations. Nobody
relishes telling an editor that we know he doesn't understand why people are upset,
we know he has not received an explanation that will ever WP:SATISFY him, we
believe that he'd be willing to change if only he could understand – but he can't,
so we're showing him the door.
Maybe someone else has better ideas. WhatamIdoing (talk) 04:21, 16 December 2020
(UTC)
These situations with recalcitrant editors are why I don't like to edit articles
that don't have a lot of watchers or an active associated wiki project. Every edit
has the sword of Damocles hanging over it: without warning it can turn into a
protracted, seemingly endless discussion, no matter how trivial the edit. And even
when there is an active associated wiki project, if you can't draw their interest
in responding to the discussion, the conflict will remain unresolved. Both of these
cases could bebefit from a revisit respite to reach a semi-binding resolution. This
would free up the other editors, while unfortunately imposing an added burden to
the closing administrator. I know no one like to tell someone a difficult truth; I
don't like to do it either. But uncooperative editors is one of the key reasons I
have difficulty getting motivated for editing articles, and I'm sure I'm not the
only one. If we can't deal with editors unsuitable for collaborative projects, then
we continue to provide incentives for poor behaviour rather than desired behaviour.
isaacl (talk) 20:51, 16 December 2020 (UTC)
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)
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)
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)
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)
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)
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)
@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)
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)
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)
Discussion about the format of this discussion
Idea for a new protection level
I think that Extended Confirmed protection is too over-powered. All it takes is
some random saps to vandalize a Semi-protected page to get it extended confirmed,
which stunts growth, and only lets very active and experienced editors to edit,
which limits the number of editors. I'm thinking of a new protection level, in
between of Semi-protection and Extended confirmed. Is this needed, and what should
be the criteria? Arsonxists (talk) 17:46, 15 December 2020 (UTC)
In most cases like this, pending changes coupled with semi-protection is probably
easier to do that creating a whole new protection level. However, the rules
surrounding pending-changes protection may need to be looked at to see if they meet
the needs. Pending Changes Protection is one of those things you don't really want
to use "out of process" (i.e. by invoking WP:Ignore all rules) if you can help it.
While this "don't invoke WP:IAR unless you absolutely have to (but DO use it when
it's called for)" applies to all policies, the past history of pending changes
makes it even more of a minefield in that area. davidwr/(talk)/(contribs) 🎄 19:18,
I agree with you on the pending changes. About the new protection level, it's not
about taking one single page, and creating a new protection level for it, and just
FOR it, is not what I am saying. I was making this so, with an Extended Confirmed
padlock on it, for a page which could use a lower level lock which doesn't exist
yet, but semi-protection is too low, the new protection level could fix the
problem. I think alot of pages have that problem. Arsonxists (talk) 20:48, 15
December 2020 (UTC)
Arsonxists, I don't see how adding another level between semi and ECP is going to
be useful. The problem is, once you get too many fine gradations, it's dang near
impossible to figure out which is the right one, so application becomes essentially
random, and we're already there. Between semi, pending, ECP, and full, there's more
than enough choices. -- RoySmith (talk) 14:45, 16 December 2020 (UTC)
From my understanding it sounds like y'all are suggesting something like Pending
Changes Level 2 (aka orange lock) which takes the current Pending Changes (formally
known as Level 1) but kicks it up a notch to become a protection level between
Semi-protection and Extended-confirmed protection. Essentially PC Level 2 flagged
every edit on a page as needing reviewed. Only Reviewers & Administrators could
have their edits go live without review after reviewing previous edits on a page.
PC Level 2 could be used in conjunction with Semi-protection & Extended-confirmed
protection. So in the levels of protection (in theory) it would have been PC Level
1, Semi-protection, PC Level 2, PC Level 2 + Semi-protection, Extended-confirmed
protection, PC Level 2 + ECP, Template protection, Full protection if everything
was adopted. This is how it appears in chart form. Again in theory, if PC Level 2 +
ECP was applied then the Reviewer would also need to be Extended-confirmed to
reject a pending change (since that would technically be a revert of the page.)
Since Level 2 never reached a consensus on how to use it, in any configuration, the
setting was removed at the software level so it wouldn't show up as an option to
administrators. While some may argue a need for another level of protection I
highly doubt a consensus could be reached today about using Level 2 of Pending
Changes Protection since a lot of people at the time didn't feel we needed a
protection level between Semi-protection and ECP. Alucard 16❯❯❯ chat? 09:51, 17
December 2020 (UTC)
If I may flip the question around, why not just lower the threshold for Extended
Confirmed user rights?. If 30/500-in-any-space were taken down to say, 24/240-in-
mainspace then high quality editors would be able to prove themselves pretty
quickly and edit semi-protected pages without restrictions getting any more
granular. Would that let through too many people too quickly? If so then I'd object
to a protection level for that reason. If not then I'd opt for lowering the EC
threshold as a simpler solution. --Paul ❬talk❭ 15:07, 30 December 2020 (UTC)
I think this entire argument is predicated on a false assumption; the OP has
claimed All it takes is some random saps to vandalize a Semi-protected page to get
it extended confirmed, which stunts growth, and I can see absolutely no evidence
for this. Here's every page currently under ECP; the overwhelming majority are
articles on Israel/Palestine, the India-Pakistan conflict, and antisemitism &
Poland (on all of which the ECP is mandated by Arbcom and consequently it would
take an arb case to get them lifted). Of the handful of those which don't fall into
one of the arbcom-mandated topics, I'm not seeing a single one that doesn't fall
into "highly contententious topic which people shouldn't be editing until they're
very familiar with Wikipedia's rules" or "under sustained attack from multiple SPAs
over the long term". Can any of the people calling for a lower protection level or
a reduction in the ECP requirements give any actual examples of a page under ECP
where you don't consider the ECP appropriate? (In my opinion, if anything we should
be raising the threshold. 500 edits is trivially easy; just ctrl-f any common typo
and you can rack up that many edits in half an hour.) - Iridescent 16:28, 30
December 2020 (UTC)
I wasn't being particularly serious with suggestion of changing the threshold -
just saying that it'd make more sense than an additional protection level. --Paul
"Suggest edit" button
It'll let you highlight/select some article text, type in what's wrong, add a
source (via URl or whatever), and put an edit request on the talk page (so that
semis, edit filters, spam url list, etc all work). Surely not an original idea.
Proposed location: on Vector, in the tab row, between "Read" and "Edit", maybe with
a tiny icon to get people to click on it; on Minerva, another icon next to the
watchlist star (maybe a lightbulb?). Method of deployment: very slowly, using the
blunt instrument of MediaWiki:Common.js, with only a few high-pageview articles at
first (get consensus from most recent/top page editors?). Thoughts welcome.
Enterprisey (talk!) 06:48, 21 December 2020 (UTC)
Probably should avoid doing something like this in Javascript... --Izno (talk)
08:08, 21 December 2020 (UTC)
It's a prototype, and will probably need to change a lot. Of course, we could go
with the more usual workflow of having an actual "experiment" and doing A/B testing
and other science in PHP over a multi-month period; indeed, if there's a PHP
developer available who would like to step up and shepherd all that through, it
would be a superior solution. I don't think any are available but would be happy to
be proven wrong. Enterprisey (talk!) 08:15, 21 December 2020 (UTC)
I have a feeling this would turn into a turbo-charged variation on the Article
Feedback Tool fiasco, which would end up flooding talkpages with hundreds of
variations on "I love/hate topic" and "you should include obvious libel". The
relatively low barrier to entry of the existing MediaWiki:Protectedpagetext screen
has a dual purpose; as well as the obvious one of telling the person who wants to
propose an edit what they need to do to propose it, it also encourages readers in
this position to create accounts and points them towards assorted help pages that
will (hopefully) help them figure out whether their suggestion is actually going to
be one worth making. If you look at the talkpage of high-pageview articles like
Talk:COVID-19 pandemic or Talk:Taylor Swift they already get hammered with good-
faith cluelessness; if we end up creating a situation where we need to semiprotect
the talk pages to stop them being flooded, the whole exercise would have been
counterproductive.
What I would support without reservation is a change to the tabs such that in
circumstances where the "view source" tab is displayed (semi'd pages to anons,
full-protect pages to logged-ins) a second link to the talk page is displayed next
to "view source", and preferably labeled something unambiguous like "discuss this
page". The way Vector shows the tabs by default to IPs and new accounts (with
"article" and "talk" on their own next to the death star, and everything else next
to the search box) is quite unintuitive. I'm fairly certain most readers who look
for the edit tab and can't see it because the page is protected aren't even aware
that the talk page exists let alone know how to get to it, and that those who do
notice the "talk" link are under the impression that it leads to their own talkpage
and consequently never bother to click on it since they know that as an
unregistered user they're not going to have any messages. (Minerva is such a mess
that I'm fairly certain most readers aren't aware that any of the tabs exist.) -
Iridescent 08:39, 21 December 2020 (UTC)
Yeah, that'll probably happen with a free-form input field. Clearly I ought to
review the Article Feedback data. That's my first talk page entry! What about a
more limited set of options, like radio buttons saying "this fact is wrong and
should be ___" or "this is irrelevant", perhaps not even with text fields? Or we
could have no "what's wrong" section at all, and just an option to contribute one
or more relevant sources in URL/ISBN/DOI/whatever form (which will of course be
restricted client-side to avoid the usual suspects like Facebook/YouTube). The tabs
change sounds like a good idea to me as well. I suppose it's too late to rename it
to "discuss this article". Enterprisey (talk!) 08:57, 21 December 2020 (UTC)
AFT was limited options prior to its free form. Really, go look at AFT. --Izno
I had a look; seems different enough. Enterprisey (talk!) 09:17, 21 December 2020
(UTC)
AFT had multiple iterations; as our page name indicates today, it was version 5
that was finally put to rest. We had 2 or 3 iterations of forms-based options
before that. --Izno (talk) 09:24, 21 December 2020 (UTC)
I had looked at all of them; I suppose I worded my comment imprecisely. I based my
judgment off mw:Article feedback#Project history, which I think shows all of the
versions. Enterprisey (talk!) 09:45, 21 December 2020 (UTC)
Because the WMF intentionally broke the links to the archives to make it hard to
access them it's hard to put across just how much of a mess AFT was, but the very
fact that they had to do this is an indicator. Even the earlier, form-based
versions saw us flooded with variations on "Key fact missing from the article: he
murders children and the international Jewish conspiracy covers it up". (If you're
interested, the AFT archive is hidden here; to give a sense of scale, the limited
experimental rollout of AFT generated 1.5 million comments.) It painted us into a
corner where we had to choose which of "hosting libel indefinitely", "team of full-
time paid moderators" or "literally delete the database" was the least antithetical
to our values. - Iridescent 09:52, 21 December 2020 (UTC)
OK, so no free-form text fields. Enterprisey (talk!) 09:56, 21 December 2020 (UTC)
Iridescent, that's an interesting point about the arrangement of the tabs.
Redesigning that at a very fundamental level seems like something that should
eventually happen, although I'm sure it'd get pushback since design change always
gets pushback. The potential confusion about the fact that "Talk" is page-based
rather than user-based is also very interesting—that's very big if true, and I'd be
curious to see if anyone has looked into that.
Regarding the point about the potential pitfall of this feature, I'm inclined to
agree. It could also end up discouraging more timid new editors from being bold and
create massive backlogs. {{u|Sdkb}} talk 13:58, 23 December 2020 (UTC)
In my view there's a big jump from "this needs changing" to "I'll dig in and edit
this". If we add a middle ground of "I'll suggest an edit", I think it's closer to
the former than the latter (in terms of effort required/"activation energy"). That
is, I agree this'll encourage some people to suggest edits instead of making them,
but I think it'll be more than offset by others suggesting edits who wouldn't
otherwise contribute at all. Enterprisey (talk!) 10:07, 24 December 2020 (UTC)
@Enterprisey: already not loving the idea of running anything heavy via common.js -
perhaps something super tiny that adds a button/tab only - and that button/tab
loads a withJS on-demand that we already have support for? But for something this
big, it seems like you are really only going to be hitting desktop editors when I'd
think a simplified workflow might be better used for mobile editors if you want to
start putting in the effort. — xaosflux Talk 16:08, 23 December 2020 (UTC)
Yup, a button that loads a script was the idea. I agree designing for mobile
editors is essential. I figure the highlighting part should transfer fine to
mobile, but I really think we should collect something beyond that - not just a
choice among "this is inaccurate/unreferenced/irrelevant" - to make the responding
editor's job easier. I think requiring a source would work for that, although I
guess research is a big pain on mobile. Enterprisey (talk!) 10:01, 24 December 2020
(UTC)
Auto-generating list articles from Wikidata?

I recently came across List of people named David, which has over 2000 people
(including disambiguation pages) linked. It seems to me that this might be easier
created and maintained using Wikidata. Well, is it possible with Wikidata now, or
do we need to wait for Abstract Wikipedia / Wikifunctions to be ready to do so? If
it is possible, how concerning are the Wikidata accuracy issues for a list like
this; references aren't really necessary to prove that the articles named "David
so-and-so" are about people named David. power~enwiki (π, ν) 22:54, 22 December
2020 (UTC)
Generating a page can be done today out of mainspace using ListeriaBot, but there
is at least one consensus on the books specifically banning the practice of
automatic upkeep. --Izno (talk) 23:33, 22 December 2020 (UTC)
Regarding the specific example, why do we need a page for List of people named
David at all? It seems the only purpose it'd serve would be as a navigational aid,
but no one is actually going to use it for that. Looking at WP:LISTN, people who
share nothing but the same first name aren't really discussed as a group. There are
26 pages in Category:Lists of people by given name, and I'd be interested to see
what'd happen if they got AfDed as a group. {{u|Sdkb}} talk 13:33, 23 December 2020
(UTC)
It's a split for size from David (name); for less common names (Millicent, Arnold
(given name)) they're included on a page about the name itself. Having these lists
also decreases the number of WP:ORPHAN articles, though it's arguable whether doing
so in this way is a good thing. power~enwiki (π, ν) 22:41, 23 December 2020 (UTC)
Sure but we could also create an article List of all orphaned articles which would
also decrease the number of WP:ORPHAN articles. — GhostInTheMachine talk to me
22:47, 23 December 2020 (UTC)
I've got a draft in my #6 sandbox, User:Davidwr/sandbox6 (permalink) Face-smile.svg
davidwr/(talk)/(contribs) 🎄 00:06, 24 December 2020 (UTC)
Regarding the more general point, yes, absolutely. I was recently wondering about
building lists off of a combination of categories and Wikidata, but if the category
system will eventually get migrated to Wikidata, as I've seen Rhododendrites
predict, then it's better to just go directly there. There's a lot of editor effort
wasted doing things that bots are perfectly capable of—the problem is that it's
easier to get 10,000 people to spend a minute each to list a page they care about
(=150+ hours) than it is to find someone with the requisite technical skill willing
to spend a few hours to set up a system to automate everything. {{u|Sdkb}} talk
13:33, 23 December 2020 (UTC)
This has already been rejected multiple times. * Pppery * it has begun... 18:04, 31
December 2020 (UTC)
Proposal to change the username policy's section on impersonation
Alright, so I found out that the user by the name Billie Eilish - Baby Shark was
indefinitely blocked due to a username violation, however I do not believe that
that was justified. Not that the block itself was unjustified, but that the reason
was unjustified. I believe that it is clear that this user's username implies that
it means "Baby Shark by Billie Eilish", as opposed to an attempt to impersonate
Billie Eilish, and their user page attested to that fact, but they were still
blocked due to the fact that their username merely contained the name of a famous
person. I would like to ask for your thoughts on if this username block was
justified, and if the policy should be changed to more explicitly prohibit blatant
attempts to impersonate a person. Please note that I am not requesting an unblock
for the user, but I am requesting a change in the policy, in order to make it more
accurate to its intention: to prevent impersonation. JJP...MASTER![talk to] JJP...
master? 02:16, 25 December 2020 (UTC)
Looks like a good block to me. We couldn't change this aspect of the username
policy even if we wanted to, since it's a legal issue and as such comes from the
WMF rather than the community. The purpose of that section of the username policy
isn't to prevent "blatant attempts", it's to prevent potential confusion; even if
the username is entirely in good faith we still block. Even if this person's name
genuinely was "Billie Eilish" we would still block unless there was something to
make it clear they're unrelated, and that's how it should be. - Iridescent 17:39,
Wiki App Idea
Hi,
This might be a bit if a stretch or currently already underway, but...
What if there was a way you could mix the camera on your phone (like how live
cameras translation of another language operates) with wikipedia's vast database of
information to help people identify things of the unknown should they stumble
across it and think "I wonder what that is"?
Basically it would be like the Pokedex from pokemon which is used to identify a
pokemon unknown to that person but would be of use with things on earth here today,
plants, animals, items, the works! Everything!
If a user stumbled across something completely original with no information then

they could somehow be involved on the information that would pop up,
I.E discovered by John Doe 11/11/2020 and it would bring up or update areas where
they were found,
The camera would also have the geotagging function should users want to share the
location of their findings,
Anything unknown would automatically send location information to the wiki/app who
could send out someone capable of investigating/studying the unknown.
A reward of some kind for original discoveries would see increased use of the app
and encourage others to share the app to explore and find other things.
The app itself would cost roughly $20 to download which would really be no huge
cost considering the ease of identifying things you aren't familiar with, unless
it's a new discovery which would put them first inline for the information
discovered after examination and analysis.
Chemicals and probably a few other things would be tricky to identify considering
it would rely on the camera talking to wiki to recognize what the user is seeing
but 3d objects and most other things with distinct colors/patterns/shapes should
work well,
With roughly 7 billion people on the planet and an ad on the site encouraging
people to download the new app i reckon there would be at least 1 billion users in
the first 5 years based on word of mouth and the constant daily searching from
users who would see the ad encouraging them to download it.
Is this a possibility?
Thanks for your time,
Nathan. M — Preceding unsigned comment added by 122.62.77.220 (talk) 21:36, 29

December 2020 (UTC)
What reason would there be for someone to pay for this, when anyone can just use
Google Lens for free, which runs on servers that are orders of magnitude faster
than anything we could hope to achieve, and which has the overwhelming advantage of
being operated by a company that already has every image on the internet archived,
tagged and sorted, and where anyone who for whatever reason objects to Google can
use the (inferior, but still better than anything we could do) CamFind for free? -
Iridescent 22:15, 29 December 2020 (UTC)
Aside from this being just generally redundant, 7 billion people doesn't mean 7
billion smart phone users, let alone that many people willing to drop $20 on any
app no matter how good. --Paul ❬talk❭ 21:36, 30 December 2020 (UTC)
Making disclaimers more prominent
Is there any way that the Disclaimers, which are now at the very bottom in small
font, can be made more prominent, particularly on the main page? I think this is
perhaps the most important information for readers to see about Wikipedia,
particularly the Content disclaimer. Many readers and drive-by editors will
complain about spoilers, blasphemy, obscene images, and similar things. They are
often referred to the disclaimers as a reason this is okay, but few readers will
ever see the disclaimers unless they are specifically directed to them. Readers
should have the option to turn away from Wikipedia if, for some reason, there is
content which they do not want to see. This is particularly important given that
Wikipedia is a global encyclopedia; although many of us in the Western world are
used to seeing such content and are not particularly disturbed by it, people from
other cultures may have other reasons, such as religious obligations, to avoid such
material. We need not just our content, but also its presentation to benefit all
our readers. As for better placement of the disclaimers, I would suggest going as
far as putting a link under "The free encyclopedia that anyone can edit". If not
placed there, the disclaimers could go lower on the main page, or on the sidebar. —
Naddruf (talk ~ contribs) 21:42, 30 December 2020 (UTC)
Hmmm, I think one could argue that "The free encyclopedia that anyone can edit"
essentially is the disclaimer, whereas The Disclaimer merely elaborates on it. I
don't know if making it more prominent will necessarily encourage that many more
people to read it. Plus I think it's worth presenting Wikipedia "as is": we don't
advertise, we don't look flashy, we don't really do anything to draw people in, any
decision to use wikipedia is very freely made - I'd be concerned that any degree of
dressing, even in the form of a reader's advisory would detract from our dry
intentionally-boring vibe that makes us kind of unique. --Paul ❬talk❭ 21:59, 30
December 2020 (UTC)
I'm sceptical that many people bother with disclaimers (wherever we place them),
but hopefully, some do, and we won't know because if so they don't complain about
stuff in the disclaimers. Some obviously complain even if they've read the
disclaimers, because higher truths. "The free encyclopedia that anyone can edit"
(on the mainpage) is like Paul says something of a disclaimer in itself, but
putting them under Other areas of Wikipedia wouldn't hurt I guess. As for sidebar,
there's a "About Wikipedia" there. Gråbergs Gråa Sång (talk) 22:30, 30 December
2020 (UTC)
@Paul Carpenter and Gråbergs Gråa Sång: I am very specifically talking about the
WP:Not censored aspect, which comes with the content disclaimer. The fact that
there may be errors or misinformation is a given from "The free encyclopedia that
anyone can edit". However, readers need to be aware that they may see images of
naked people, they may see criticism of their religion, they may see things that
children should not see; and that if they don't want to see this, they should avoid
Wikipedia or be careful what they look at. It is common for certain types of
material in public view to be censored in some way, and the fact that Wikipedia
doesn't do this needs to be pointed out. For example, there are 1.8 billion Muslims
worldwide, and a large number, if not a majority, believe that Muhammad should not
be pictured. Nevertheless, there are pictures of him at our article Muhammad. Over
the years, hundreds of people have commented asking that the pictures be removed,
but they are still there. So if Wikipedia is going to do something that goes
against the beliefs of 10% of the world population, it should make it more clear
that this is allowed on Wikipedia by making the policy about this more visible. —
Naddruf (talk ~ contribs) 22:44, 30 December 2020 (UTC)
One wonders which sort of math would lead one to conclude that 1.8 billion Muslims
equal only 10% of the world population.
M Imtiaz (talk · contribs) 22:49, 30 December 2020 (UTC)
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)
@M Imtiaz: Not all Muslims think images of Muhammad are that bad, I don't know how
many do. —Naddruf (talk ~ contribs) 23:43, 30 December 2020 (UTC)
And I think the number of complaints will be about the same regardless of where we
put the disclaimers. Presumably, in this day and age, many people are told about
this by parents and teachers. Yes, WP has all kinds of stuff on it, it's like the
rest of the internet in that way. Gråbergs Gråa Sång (talk) 23:17, 30 December 2020
(UTC)
Isn't that already covered by the fact that this is an encyclopedia? Encyclopedias
cover the world: good, bad, and indifferent. They describe reality. If the reader
can't handle reality, that is their problem, not ours. And, as far as things that
go against religious beliefs, why would anyone think that anything that is not run
by their religion would be constrained by it? --Khajidha (talk) 22:59, 31 December
2020 (UTC)
The people who are upset that we insulted their religion or that they see an
obscene image aren't going to stop complaining just because a legalese disclaimer
is shown more prominently. This will not solve the problem you mention, but what it
will do is make the UI even more bloated and inaccessible. ProcrastinatingReader
@ProcrastinatingReader: If it is useful, it does not make the page more
inaccessible. This would be more useful than the side links to "related changes"
and "page information", and it could be easily added on the main page under "Other
areas of Wikipedia" without making anything more bloated. —Naddruf (talk ~
contribs) 23:43, 30 December 2020 (UTC)
I click "page information" lots of times each day. I don't recall the last time I
clicked disclaimers. I couldn't tell you from memory what they say. I have an idea
of what it says, and I don't really care, it's functionally useless to me and it
appears to exist just to cover legal's backside. ProcrastinatingReader (talk)
23:48, 30 December 2020 (UTC)
I cannot imagine why a casual (not-procrastinating) reader would ever click on Page
Information, but that is a separate issue. Anyway, that side bar is already more
than long enough without adding another thing that no-one is going to read. If this
were going to solve any kind of problem, then you'd need a way to prompt them to
read it, but for 99% of users that would just be getting in the way. And I honestly
don't think that a few people occasionally complaining is representative of the
almost 10,000 people a day who view the Muhammad article (of whom I would guess a
sizeable portion are from a Muslim background). --Paul ❬talk❭ 09:01, 31 December
2020 (UTC)
Naddruf, many things can be useful on the main page (and in many other places). The
better question is: "is it effective". And that seems highly doubtful. —TheDJ (talk
• contribs) 14:07, 31 December 2020 (UTC)
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)
I think it's worth discussing how to make the make the disclaimers a little more
prominent. Putting it somewhere on the main page might get support if you come in
with a well-articulated argument and a sandbox design in hand so people can see
what it'd look like. However, asking for it to be added to the left sidebar or to
the top of the main page just below the tagline is not likely to succeed. {{u|
Sdkb}} talk 19:03, 31 December 2020 (UTC)
Overall, I have sympathy with the idea of making disclaimers more prominent. This
might be especially valuable for medical articles - there is a Wikipedia:
Medical_disclaimer, but one does not see it on many articles on medical topics.
Vorbee (talk) 11:52, 1 January 2021 (UTC)
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)
"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)
What could be stripped from the side bar?
In the spirit of having less stuff on every page, I think that the tools section of
the sidebar could be stripped down. Especially for logged-out readers. This small
change would then allow for a tiny bit more whitespace, but every little helps.
I've marked in red below the items that I think we can do without from the 'Tools'
section. --Paul ❬talk❭ 09:31, 31 December 2020 (UTC)
Link useful to a reader? useful for most editors?

What links here maybe? 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
Have you tried turning off "Use Legacy Vector" in your preferences ? Cabayi (talk)
09:42, 31 December 2020 (UTC)
Me personally, or the reader being discussed? The latter doesn't have a preferences
screen unless they make an account. Either way changing the skin doesn't change
amount of items in the Sidebar. --Paul ❬talk❭ 09:48, 31 December 2020 (UTC)
"changing the skin doesn't change amount of items in the Sidebar" - so that's
obviously a No then. Cabayi (talk) 09:58, 31 December 2020 (UTC)
It really doesn't! I just tried a couple of times to it to make sure. The contents
of the side bar is the same with any choice of skin. --Paul ❬talk❭ 10:04, 31
December 2020 (UTC)
There was a large, recent RfC seeking to strip and reorganise the sidebar. I
believe its results are the perfect example of how active editors' needs – a tiny
minority of Wikipedia's users – tend to be disproportionately favoured over
readers' needs, because active editors, almost by definition, are the only ones who
contribute to these discussions. Thus links virtually useless to readers (Permanent
link) were retained, mostly because experienced editors didn't want to lose a
precious click, and links that might be of interest to readers (Featured content)
were removed instead. However, as part of mw:Reading/Web/Desktop Improvements, the
Tools section is proposed to be moved out of the sidebar into a dropdown tab, akin
to View history, which I think would be a good compromise. – Teratix ₵ 10:32, 31
December 2020 (UTC)
Yeah that does sound like a good compromise. And a very precise description of the
issue at hand, the reader does get forgotten way too easily, see above. --Paul
Yep, I think the RfC moved us forward, but overall I very much agree with Teratix.
Here's the specific section where I proposed collapsing the tools section by
default, which failed.
Also, if we're on the topic, there were some consensuses reached at the RfC that
haven't been implemented yet. The ordering of the tools section is one; it has long
bugged me that "Page information" isn't the first link as would seem logical, and
we agreed to change it here. There's also moving the "cite this page" to the
print/export section, which I think got stuck when T255381 was incorrectly closed,
the section ordering switch, and some other stopgap measures that need adjustment
as they don't work on all pages. All of these things are just stuck somewhere in
the backend, and getting them done would be at least a small plus. {{u|Sdkb}} talk
19:19, 31 December 2020 (UTC)
@Sdkb: last I checked, the ordering of the items in the "tools" section is not
customizable here without ugly javascript hacks (c.f. mw:Manual:Interface/Sidebar)
so changes would be for everyone, not just enwiki - and an enwiki want to change
something like this isn't usually enough to force a global change. An better option
may be to request that the software be updated regarding MediaWiki:Sidebar,
allowing the subsections of TOOLBOX to be configured locally. You could request
something like that at phab (WP:BUG). — xaosflux Talk 16:45, 1 January 2021 (UTC)
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)
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)
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)
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)
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)
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)
@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)
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)
Pinging @Beetstra, who has doubtless thought about this problem. WhatamIdoing
(talk) 20:58, 4 January 2021 (UTC)
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)
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)
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)
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)
Will adding the script enable any notification when a new version comes out?
No, but telling me you want to be notified hasFace-smile.svg — GhostInTheMachine
talk to me 20:04, 6 January 2021 (UTC)
Well thank you!--Quisqualis (talk) 20:06, 6 January 2021 (UTC)
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)
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)
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)
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)
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)
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)
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)
Categories: Wikipedia village pumpWikipedia proposals
Navigation menu
Not logged in
Talk
Contributions
Create account
Log in
Project pageTalk
ReadEditNew sectionView historySearch
Search Wikipedia
Main page
Contents
Current events
Random article
About Wikipedia
Contact us
Donate
Contribute
Help
Learn to edit
Community portal
Recent changes
Upload file
Tools
What links here
Related changes
Special pages
Permanent link
Page information
Wikidata item
Print/export
Download as PDF
Printable version
Languages
Deutsch
डोटेली
‫گیلکی‬
‫لۊری شومالی‬
မြန်မာဘာသာ
தமிழ்
తెలుగు
4 more
Edit links
This page was last edited on 9 January 2021, at 22:02 (UTC).
Text is available under the Creative Commons Attribution-ShareAlike License;
additional terms may apply. By using this site, you agree to the Terms of Use and
Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation,
Inc., a non-profit organization.
Privacy policyAbout WikipediaDisclaimersContact WikipediaMobile
viewDevelopersStatisticsCookie statementWikimedia FoundationPowered by MediaWiki

LS3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LS3

Uploaded by

Copyright:

Available Formats

Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia

Village pumps:policy•tech•proposals•idea lab•WMF•misc

If you go to a random high-traffic talk page for a reasonably controversial

Going through various things I notice:

I proposed something similar to AC in July/Aug. Those things also need bigger

Before the AH and banners templates

After the AH and banners template

GA drops in templates instead of building articlehistory. DYK drops in templates

Vital articles WikiProject continues cluttering talk pages

Skip to talk. Related to DS template.

Why are these there at all?

List of conduct dispute resolution systems:

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

Auto-generating list articles from Wikidata?

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

If a user stumbled across something completely original with no information then

Thanks for your time,

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

Link useful to a reader? useful for most editors?

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

Today, I met my match in the form of a visually unparseable Arbitration discussion.

I'm open to any comments or suggestions on how to accomplish my aim.--Quisqualis

23:00, 7 January 2021: Example (talk | contribs) triggered filter (number),

You might also like