Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)

Village pump sections

To discuss existing and proposed policies

To discuss technical issues. For wiki software bug reports, use Phabricator

Dialog-information on.svg
To discuss new proposals that are not policy-related. See also: perennial proposals.

Idea lab
To discuss ideas before proposing them to the community and attempt to find solutions to issues

To post messages that do not fit into any other category

View all village pump sections at once

Other help and discussion locations
I want... Where to go using or editing Wikipedia Help desk find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review resolving a specific article edit dispute Requests for comment comment on a specific article Article's talk page view other Wikimedia projects Wikimedia Meta-Wiki learn about citing Wikipedia in a bibliography Citing Wikipedia report sites that copy Wikipedia content Mirrors and forks ask questions or make comments Questions


Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).


RfC about user page guideline WP:POLEMIC

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.


WP:POLEMIC currently states: ‘’Material that can be viewed as attacking other editors, including the recording of perceived flaws. The compilation of factual evidence (diffs) in user subpages, for purposes such as preparing for a dispute resolution process, is permitted provided it will be used in a timely manner.’’

Please select one of the following choices to keep, remove or modify the phrase “timely manner”:

  1. Keep as is
  2. Replace with: ‘’ not permitted as it could be misused or misconstrued as a threat or WP:HOUND
  3. within 30 days
  4. within 45 days
  5. within 60 days

Thank you...Atsme📞📧 14:10, 18 May 2018 (UTC)


  • 2 - history indicates that such compilations have been used (perceived or otherwise) to threaten and/or hound editors who represent “the opposition” in controversial articles. Atsme📞📧 14:10, 18 May 2018 (UTC)
  • 3- although the use of user space to compile a dispute resolution case is legit, leaving it as "in a timely manner" is basically an invitation to let it languish forever. A strict time limit needs to apply. Reyk YO! 14:29, 18 May 2018 (UTC)
  • 3 - Pretty much agree with Reyk, though I would consider more of a 15 days since last substantial edit to the page, 30 days from initial creation. My reasoning is that I think 30 days is a little too long unless you are actively preparing some sort of dispute resolution case. --Kyohyi (talk) 14:38, 18 May 2018 (UTC)
  • 1 - It is better for that drama to just "sit" and die off somewhere in userspace. Do we really want an automatically started incident thread, 30 days after every such thing? wumbolo ^^^ 15:38, 18 May 2018 (UTC)
  • 1 or 60-90 days. These things can take time. Because the target is (in this case) attempting to sabotage the collection of evidence (just as Trump is attempting to dictate the terms of the Mueller investigation), the clock should be restarted and the diff collector given even more time. That should teach the target to not obstruct justice. See my comment below. -- BullRangifer (talk) PingMe 16:11, 18 May 2018 (UTC)
  • 1 "Timely" should not be a hard-and-fast rule. --SarekOfVulcan (talk) 16:14, 18 May 2018 (UTC)
  • 1. What is an appropriate time will vary based on the situation. Natureium (talk) 17:15, 18 May 2018 (UTC)
  • 3 Seems like the best fit, I like the spirit of timely but it is to open to gaming. Perhaps a provision for an extension after 30 days if a good explanation is provided, otherside it festers and creates problems. PackMecEng (talk) 17:40, 18 May 2018 (UTC)
  • 1.5 - I don't like arbitrary time limits, but I also don't see any reason for such material to stay visible outside of when the user is actively working on it. I would add a provision to the current version like A page containing such material should be blanked upon request when not actively in use.. While the user is working on it (in their current session), they can restore it from the edit history of the page, and while they are not working on it, its hidden from view to avoid the polemic nature. -- Netoholic @ 17:52, 18 May 2018 (UTC)
  • 0.5 - remove the "provided..." clause or keep as is. DexDor (talk) 18:53, 18 May 2018 (UTC)
  • 1 or 5+ these things take time. If a case is to go to ArbCom one needs to demonstrate both prior resolution attempts and a long term pattern. There can be months from the time a problem becomes apparent until it can be sufficiently documented for ArbCom to do something about it. Such pages should not be kept on prominent display, e.g. do not collect/post evidence on your user page, but having such a sub-page where others must go looking for it should be OK.
    Beyond that, if there is a long term issue one wishes to document it can take quite a bit of time to dig through various editor and page histories to find diffs and figure out how to properly present the information. Most editors will not want to drop everything simply to research and write up a case but instead will work on it as time permits. Thirty or even sixty days is not very long considering this is a volunteer project and that documenting misbehavior is not why people want to spend their time editing here. Jbh Talk 19:55, 18 May 2018 (UTC)
  • 0.5 per DexDor. Such a list can be a useful thing to have in your back pocket as a way to document and recognize problematic editing patterns, which may or may not lead to dispute resolution etc. It should be kept discreetly on a user subpage without prominent links or polemic commentary.
If such lists are being used problematically, then the problematic behavior should be addressed. In particular they should not be trotted out during talk page discussions unless a formal complaint or accusation is being made. –dlthewave 22:08, 18 May 2018 (UTC)
  • 1 I think such lists can be an element of hounding, but in of themselves they aren't hounding. For example, if you made a list like this and then went around posting links to it on article talk pages or other discussions with the target editor, then that'd be hounding. Not quite the same thing, but some editor took part of a discussion I had with him and featured it prominently on his user page (presumably to make some kind of point) but I only happened to see that by coincidence and we haven't otherwise interacted, so why should I care? Same with a list of diffs like this. If they're just keeping the list on their page, then what harm is it? Just don't go to their user page if you don't like it. Also, there's a very easy solution: if you don't want someone to make a list of diffs of you violating policy, then don't violate policy. Red Rock Canyon (talk) 04:34, 19 May 2018 (UTC)
  • 1 per WP:AINTBROKE and the note at the top of this page about not using this page to settle disputes about implementation of policy. POLEMIC is working just fine. As the discussion bellow is showing, the line between good-faith collection of evidence for dispute resolution versus malicious persecution is not a bright one, and is best decided on a case-by-case basis. Ivanvector (Talk/Edits) 10:53, 19 May 2018 (UTC)
  • 1 It's fine. Dispute resolution can be protracted and subject to changing deadlines/late closures/etc. No need to put a hard deadline on something. As Ivan said, if it ain't broke... ~ Amory (utc) 12:02, 19 May 2018 (UTC)
  • 2 there's no reason for this kind of stuff to be publicly accessible, keep it on your own computer until you're ready to stand behind it. CapitalSasha ~ talk 13:54, 19 May 2018 (UTC)
  • 1 defining hard limits is rarely useful. If it wasn't good on day 31, it also wasn't fine on day 29. 2 would be my second choice. --Jayron32 14:44, 19 May 2018 (UTC)
  • 1 (or 0.5) - There's no need for a strictly-defined time limit. Much wasted time could be avoided if some users would simply refrain from snooping though other user's subpages for whatever drama that they can stir up. We should also stop misusing the word "polemic", which has nothing to do with the compilation of factual evidence (diffs). - MrX 🖋 12:52, 20 May 2018 (UTC)
  • 0.5, remove time constraint completely. Why on earth is this not given as an option? Such apparent bias compromises the credibility of the RFC. The intro says: "Please select one of the following choices to keep, remove or modify the phrase “timely manner”", but there is in fact no remove option. Johnbod (talk) 15:32, 21 May 2018 (UTC)
  • 0.5, remove time constraint completely per Johnbod. I get regularly hounded by people harbouring grudges. Sometimes they turn up on my talk page to complain about something and I tolerate this indefinitely. Maybe they have a point or maybe they don't but it does little good to sweep it under the carpet because it's so easy to repeat or save the details elsewhere. Better to get it all out in the open to understand the grievances and clear the air. Andrew D. (talk) 22:04, 21 May 2018 (UTC)
  • 0.5 per the people above. It's rare I agree with Andrew but he's absolutely right here, sometimes there is a necessity to keep a long string of diffs in your own user area because otherwise it's difficult to prove a persistent problematic issue if it doesn't happen every day. Black Kite (talk) 22:17, 21 May 2018 (UTC)
  • 1 per Ivanvector's WP:AINTBROKE argument. I don't understand the problem that this is intended to fix! Compilation of such info could possibly be construed as Hounding - but I know of no instances where it has been so by the community - in isolation - without other more 'harassing' behaviour. Pincrete (talk) 19:06, 27 May 2018 (UTC)
  • 1 As long as this is in the person's own userspace (preferably with a neutral sub-page name, not the name of the target), and they are not calling attention to it elsewhere, this is a valid and sometimes unfortunately necessary thing to do. We have all seen reports at AN or ANI which were dismissed for lack of diffs, or lack of demonstrating a pattern of disruptive behavior, or whatever. To avoid that kind of result, it may be necessary to collect evidence over a period of time for an eventual complaint - or perhaps no complaint, if the behavior improves or the evidence gathered proves to be insufficient. When I do this kind of thing (and yes, I sometimes do), I do it off-wiki on my own computer, but that is my choice. (BTW I rarely have to use this data, because usually the target gets himself/herself blocked without any help from me.) --MelanieN (talk) 15:19, 31 May 2018 (UTC)
  • Observation: Option 2 doesn't make sense, and would result in a text string of "... is permitted provided it will be used in a is not permitted as it could be misused or misconstrued as a threat or WP:HOUND".  — SMcCandlish ¢ 😼  05:26, 1 June 2018 (UTC)
  • "5+" (e.g. 90 days). I'm vehemently opposed to option 1 and to the "0.5" proposal, having been the victim of someone keeping a "dirt list" on me for something like two years as blatant intimidation tactic, and WP:MFD actually failing to delete it because no one there was sure what "timely manner" meant. I actually stopped editing Wikipedia for several months (other than a few brief visits back in response to direct e-mails) as a result of that person's harassment. The idea of no time limit at all is nuckin' futs; if you want to keep running dirt lists on people for years on end, do it on your own hard drive. But no. 2 (after you parse what it's supposed to mean) is also irrational, since it would make it wiki-illegal to compile and draft any evidence submission on WP at all, even if you intended to use at a noticeboard only 5 minutes from now. Options 3 and 4 are too short, especially for drawn-out processes like WP:RFARB and WP:ARCA, which can take months sometimes. 5 is closer, but even 60 days can be too short.  — SMcCandlish ¢ 😼  05:38, 1 June 2018 (UTC)


  • "Hounding" obviously can't apply. That applies to not only aggressively and pointedly following another editor around, but actually disruptively taunting them and/or disturbing edits they have made which were uncontroversial and proper. (Watching disruptive editors, socks, and vandals and fixing their errors is not hounding, even though it involves following them around. That is actually our duty as editors. We must protect the encyclopedia.) An editor's subpage which is not advertised and only known to a few is not a threat or hounding. -- BullRangifer (talk) PingMe 14:21, 18 May 2018 (UTC)
I disagree - I've known instances where one editor starts the diff page, then follows the target editor to collect "add-as-you-go" diffs each time they "believe" the target editor does something they don't like, especially if the diff collector is a seasoned editor who knows how to game the system. I've even seen diffs collected that were not representative of incivility at all - just content disputes, and even legitimate actions were added to the collection, knowing few admins have/take the time to read them all but it looks bad nonetheless - and that is HOUND. Atsme📞📧 15:34, 18 May 2018 (UTC)
Quietly collecting diffs is not hounding. Hounding involves public action negative to their target, which the target immediately knows about, as described above. And it doesn't include what the target "perceives" as simply negative, but what normal others would perceive as "unjustly" negative. The perceptions of paranoid people, or those with a guilty conscience, don't count. You're misusing the term.
It especially doesn't apply to the situation upon which this whole thread is about, a target going to the diff collector's private userpage and loudly and publicly complaining (Streisand effect!!), and then starting an MfD. That's like Trump complaining about the Mueller investigation, and then getting all his staff to complain as well. (He's supposed to ignore it and never talk about it.) That's what's happening. Trump (and the target here) should not talk to the diff collector about it or mention the investigation (or the diff page). Obstruction of justice is a crime (which can be committed by completely innocent people), and interfering with the collection of diffs for a possible noticeboard or AE case is a form of obstruction. It's wrong to do that. The target needs to stay away from the very topic, and the private userpage, since this was done very discreetly. It was the target who publicized it. They exercised bad faith by making it public.
Having some reasonable time limit is another matter. -- BullRangifer (talk) PingMe 16:05, 18 May 2018 (UTC)
  • There is a difference between privately collecting diffs for a complaint and keeping a bunch of diffs or quotes around to shame, harass or poison the well for others dealing with an editor. The later, which includes keeping unattributed quotes and/or quotes stripped of context on one's user page is much, much worse than collecting diffs on a page which no one who is not looking for it will see it. Jbh Talk 20:04, 18 May 2018 (UTC)
  • I tend to use this template for nearly everything in my userspace:
  • {{NOINDEX|visible = yes}}
I suggest it should be used for the type of page under discussion. -- BullRangifer (talk) PingMe 20:14, 18 May 2018 (UTC)
User pages and subpages already have <meta name="robots" content="noindex,follow"/> in their HTML heads.- MrX 🖋 13:02, 20 May 2018 (UTC)
  • @Atsme and Bullrangifer: I take it this is related to an ongoing dispute involving some sort of "target"? –dlthewave 22:09, 18 May 2018 (UTC)
It's a proposed change for a guideline based on a history of disputes for the same/similar issues and it has become clear that the guideline needs clarity. Read the options and cast your iVote - try to imagine yourself in the shoes of the page owner and the targeted editor, and make your decision. Atsme📞📧 22:28, 18 May 2018 (UTC)
That is nonsense. The issue concerns this MfD. Johnuniq (talk) 23:40, 18 May 2018 (UTC)
Are you considering it nonsense based on your personal experiences as a targeted editor, Johuniq? If the latter is the case, please substantiate your "nonsense" position by providing the diffs so others can weigh-in. It would be quite helpful. Atsme📞📧 03:02, 19 May 2018 (UTC)
That's just a CIVIL auto-response that evades the issue. Someone asked if the proposal here was related to a dispute, and I provided the link to show where the dispute can be seen. The close of the MfD specified a date beyond which the diff-collection will be regarded as polemic and deleted so, once again, Wikipedia's model of not trying to specify rules that precisely cover every situation is shown to be working. Johnuniq (talk) 04:12, 19 May 2018 (UTC)
Your preconceived notions are not helpful. My position is still NO, and your naming that MfD for WP:POINT was not only wrong, it was disruptive. Stop reflecting your POV onto me. This RfC is the product of other incidents I recalled with a measure of trepidation, dating back at least 3 years - an accumulation of incidents that have caused disruption. I’m of the mind that waiting and watching one’s opposition for the purpose of collecting diffs-on-the-fly is the same as HOUNDING, and an impediment to an editor’s ability to express free thought for fear it will be misconstrued or taken out of context and wrongfully used against them. It’s one thing to collect diffs that already exist in preparation of filing at AE or ANI which should not take more than 30 days...not to mention the fact that a simple text program off-WP will serve the same pupose without creating a hostile environment in an effort to rid oneself of the opposition. Atsme📞📧 13:37, 19 May 2018 (UTC)
Your opinion about what is and isn't hounding is far from being a reasonable interpretation of the policy. And frankly, someone who has a history of problematic behaviour refraining from said behaviour because they know it will be recorded is a good thing. There should be a hostile environment for them. Oh and lastly: you have no right to express free thought on Wikipedia. Only in death does duty end (talk) 13:49, 19 May 2018 (UTC)
RfCs don't usually come out of the blue, and anyone proposing a change to a guideline should present a compelling reason to do so. @Atsme: If you're aware of a history of issues related to this, or a particular discussion that your concerns arose from, it would be helpful to post links here. This is usually done as part of opening the RfC. –dlthewave 14:24, 19 May 2018 (UTC)
No one said this RfC came out of the blue, but I’m not going to mislead anyone by saying it was the result of one specific MfD. I already explained my reason...and quite frankly, I see some of these polemic pages as nothing more than “opposition research” but I’m just 1 iVote. The community will decide, and it doesn’t require me providing links to deleted pages or past MfDs that once caused some editors grief. I’m trying to avoid disruption and retain editors, which happens to be my main motivation for this RfC - eliminating the ambiguity by setting a time limit or disallowing the practice all together. Based on my years editing here, it is quite obvious that when an editor is truly disruptive, it won’t be difficult to provide 4 or 5 diffs as evidence without any need for explanation, and that’s something that can be kept in a text file off-WP. If it takes months to collect diffs, and you’re doing it on the fly in an effort to provide evidence that isn’t plainly evident, that’s the first 🚩. It’s a poop or get off the pot process. Atsme📞📧 15:15, 19 May 2018 (UTC)

It seems that I am in the minority but I feel pretty strongly that these sorts of pages should not exist. It cannot be a nice feeling to have a page in existence that is accumulating evidence of your supposed misdeeds, when you have no way of challenging this evidence or otherwise defending yourself. Even if the page is not being publicly waved around, if the editor in question knows of its existence then the effect is nearly the same. Editors who want to complain about other editors' behavior should assemble a case in private, take it expediently through the proper channels, and obtain a swift resolution. They shouldn't be allowed to make public lists of others' behavior that they don't like with the threat of someday using it to lodge a complaint. CapitalSasha ~ talk 21:19, 19 May 2018 (UTC)

Anyone concerned about the existence of polemic pages (aka diff collections or shit lists) can relax because they are prohibited and will be deleted. The only point of contention concerns the period of time allowed before such a compilation is used on a noticeboard, whereupon the original compilation should be deleted (and will be deleted if taken to MfD). Clearly six months is too long, and one week is too short. The closing statement for the MfD that led to this discussion has it exactly correct. Another potential problem concerns someone who makes it known that they have a diff collection, for example, by posting a link to it. That would be a sign of battleground behavior that would encourage deletion of the page. Johnuniq (talk) 00:10, 20 May 2018 (UTC)
I don't really understand the difference between what is being discussed here and a diff collection. Even if someone doesn't advertise that they have a collection, it still shows up in recent changes and so may be noticed by others. These lists should be private, i.e. off-wiki. CapitalSasha ~ talk 04:34, 20 May 2018 (UTC)
Lots of sub-optimal things happen at Wikipedia and collecting evidence in public is one of them. However, such activity is accepted as sometimes necessary because it is important to get the wikitext correct and tested before inflicting it on a noticeboard. If anyone knows of a page like that which is more than a couple of months old, please provide a link for assessment in order to have the page deleted per WP:POLEMIC. Johnuniq (talk) 07:20, 20 May 2018 (UTC)
I don't find this argument at all convincing. Checking that the wiki text is correct is what page preview is for. Fixing the formatting definitely doesn't take weeks or months as is being discussed. It seems to me that the benefit of creating these sorts of public diff lists is the psychological feeling that other people are reading the evidence that one is compiling, even if outwardly one says they aren't advertising it. This strikes me as behavior that should be banned. CapitalSasha ~ talk 19:57, 20 May 2018 (UTC)
Getting the wikitext for complex evidence correct is a lot harder than it appears, however my purpose in posting in this section was merely to report current procedure and I wouldn't mind a speedy-delete category for a page with a diff collection older than 7 days. Johnuniq (talk) 22:51, 20 May 2018 (UTC)
  • Johnbod - see #2. It removes the time frame. Also, MfD is used to delete dubious collections and there appears to be some concern for anything longer than 2 wks to a month is obliquely used to HOUND. Atsme📞📧 16:27, 21 May 2018 (UTC)
No!!! "Replace with: ‘’ not permitted as it could be misused or misconstrued as a threat or WP:HOUND" - it removes the possibility entirely, changing "is permitted" to "is not permitted"! Unbelievable. The !votes so far suggest that "some concern" is restricted to you and one other editor who have between you taken up most of this section. Johnbod (talk) 21:46, 21 May 2018 (UTC)
Yeah...right up until they find their edits being collected on their opposition's user page. Atsme📞📧 15:02, 31 May 2018 (UTC)

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Suspend page move rights for new editors?

This proposal to make page moves EC-only is clearly going nowhere. Closing per WP:SNOW. (non-admin closure) Narutolovehinata5 tccsdnew 01:01, 18 June 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

 Administrator note: The account in question below was autoconfirmed, having been registered for 4 days with at least 10 edits, just noting that "new editors" below the confirmation threshold are already prevented from moves. — xaosflux Talk 14:38, 19 May 2018 (UTC)

L_O_M_G_B_O_Y_E registered 3 days ago and was able to do this. While I appreciate that we don't want to make editing too restrictive for new users I can't think of any good reason why we would want a brand new account to start moving around articles. Is it worth considering suspending page move rights for a month or two until the editor beds in? Betty Logan (talk) 05:36, 19 May 2018 (UTC)

It's still the encyclopedia anyone can edit. I doubt this is necessary just because of occasional vandalism from Milly on Mheels. They'll find other things to do if we block this. (those things not listed per WP:BEANS) power~enwiki (π, ν) 05:40, 19 May 2018 (UTC)
It happens far too often with India-related stuff. No idea about other topic areas. - Sitush (talk) 05:44, 19 May 2018 (UTC)
It's just another form of the low level of vandalism that's inherent in being an open encyclopedia. I don't see any reason to block this particular form of it. CapitalSasha ~ talk 05:47, 19 May 2018 (UTC)
It isn't always low level, eg: articles with few watchers being moved to POV titles. - Sitush (talk) 05:50, 19 May 2018 (UTC)
To add to that it is a specific type of vandalism that sometimes causes massive inconvenience. For example, if they had simply vandalised those pages in the conventional sense then any run of the mill editor could have reverted the edits, but sometimes page moves can be a real hassle to get fixed. Betty Logan (talk) 05:51, 19 May 2018 (UTC)
Betty's is a key point. If page moves were always easy to revert, there would be little problem, but too often these moves create a significant mess, one which an average, even experienced user cannot fix with ease. HiLo48 (talk) 05:56, 19 May 2018 (UTC)
A recent example was Mannanars (Thiyya Dynasty), which was one of several pov moves made at that time. - Sitush (talk) 05:58, 19 May 2018 (UTC)

Some functions should be reserved for experienced editors, and that doesn't impinge on the ability of unregistered and new editors to make actual edits. This is one function which should be off-limits to them. -- BullRangifer (talk) PingMe 05:48, 19 May 2018 (UTC)

Agree. L_O_M_G_B_O_Y_E was able to move 20 pages to nonsense names within 5 minutes, and I guess would have continued if he hadn't been caught and blocked at the end of that time. As Betty says, 'ordinary' vandalism is a nuisance, but page-move vandalism can be a real pain; and as BullRangifer says, there's no particular reason for new users to be instantly able to move pages.
L_O_M_G_B_O_Y_E was presumably autoconfirmed. Perhaps page move rights should be delayed until a user reaches extended-confirmed status? — Stanning (talk) 10:13, 19 May 2018 (UTC)
One user moved a couple dozen pages. Not the end of the world. As has been alluded to above, we've faced far worse and managed to stay afloat. AC is a fine limit, and while EC would certainly be harder to get to, it would stop a lot of good, new editors from contributing. Besides, vandals gonna vandal. ~ Amory (utc) 12:05, 19 May 2018 (UTC)
Amory, let's not use the exact same "logic" the NRA uses to keep AR-15s in the hands of those who can use them to cause much damage. Newbies will not suffer from a lack of the ability to move pages. It will not impinge on their ability to edit and improve the encyclopedia at all. If they really feel the need to move an article, they can ask on the talk page and it will be done, if it's a good idea. -- BullRangifer (talk) PingMe 14:17, 19 May 2018 (UTC)
@BullRangifer: Nice sarcasm. NRA does exactly what Amory opposes. Guns only for the experienced, mature, clean and documented civilians. wumbolo ^^^ 14:32, 19 May 2018 (UTC)
Would you kindly rephrase? You seem to be comparing a silly vandal to mass murderers, with me abetting such crimes. That's inflammatory at best, and insulting at worst, and I do not believe it helps your argument. ~ Amory (utc) 14:39, 19 May 2018 (UTC)
I'm only referring to the logic being used. That's all. Change the names and it becomes a combination of NRA talking points, especially the last do-nothingism because vandals/criminals will always do what they're going to do, so let's not do a thing to prevent it. That type of logic isn't useful when we can easily prevent this type of problem without impinging on their ability to do actual editing. BTW, from what's written below about a filter, this may all be a moot point now. -- BullRangifer (talk) PingMe 14:53, 19 May 2018 (UTC)
Except guns kill people, and page moves don't kill people. power~enwiki (π, ν) 22:28, 19 May 2018 (UTC)
Except guns don't kill people, people kill people. wumbolo ^^^ 22:30, 19 May 2018 (UTC)
Way to parrot an NRA talking point. People kill people, but guns broadly and greatly expand the number of people who can kill other people. Seriously, a bit of critical thinking wouldn't hurt.--WaltCip (talk) 11:11, 21 May 2018 (UTC)
@WaltCip: and therefore minimize the number of people killed, by preventing violence. wumbolo ^^^ 12:39, 21 May 2018 (UTC)

Page moves for the last ten years have been well managed by Filter 68. I suspect the feature is currently experiencing a bug, else it would have been picked up, prevented, AND auto-reported to AIV. In any case the filter is the ideal tool for this as opposed to various blunt restrictions; requested adjustments to the filter can be made at WP:EFR, but like I say, I think it's just experiencing a bug. -- zzuuzz (talk) 14:26, 19 May 2018 (UTC)

OK, having looked a bit deeper there may or may not be a bug, but all that's required is a subtle adjustment to the filter. -- zzuuzz (talk) 14:33, 19 May 2018 (UTC)
I see no reason why page moves can't be pushed to EC, as long as article creation is still at AC. Creating a new page doesn't damage anything, while page moves can screw up a lot if the editor is intent to disrupt. If an AC editor needs a non-controversial page move, that should be handled by a edit request. --Masem (t) 15:11, 19 May 2018 (UTC)
  • I will also totally support upping the ability to move pages to Extended Confirmed. There's no urgent need that can make it necessary to allow a 4-day old account and 10 edits to just start moving pages, some of which cannot be reversed by established editor of 10 years who is not an admin and not a pagemover. "It is encyclopedia, everyone can edit" is a banal cliche which is being far and far from the truth evey day, the reality is "you can only edit what you're allowed". And restricting page-move to EC will not leave us with " hundreds of misnamed pages". –Ammarpad (talk) 11:13, 20 May 2018 (UTC)
  • I agree that mainspace-to-mainspace moving should require EC (moving isn't "editing", so Wikipedia would still the encyclopedia anyone can edit), but limiting draftspace-to-mainspace and userspace-to-mainspace moves would essentially be turning ACREQ into ECREQ, as it would force non-EC users to either create ther articles directly in mainspace (and get them speedied), going through AfC, or doing a copy-and-paste move (which is discouraged for copyright reasons). --Ahecht (TALK
    ) 14:37, 21 May 2018 (UTC)
  • Oppose no real reason for this. Page move vandalism is a pain, but the ability to move pages is key to editing: typos, realizing a page you created could be at a better title, actually knowing more about the MOS and title change policy than established editors and doing uncontroversial moves (this is a thing). Restricting a core function of the MediaWiki software to extended confirmed on all pages is too much for me to swallow. TonyBallioni (talk) 14:42, 21 May 2018 (UTC)
  • Oppose yeah, EC is too much for just the ability to move a page. Also, all this appears to be over an issue that is fixed, at-least according to Zzuuzz, per his comment about "it would have been picked up, prevented, AND auto-reported to AIV" Galobtter (pingó mió) 14:50, 21 May 2018 (UTC)
  • Question: Would those editors opposed to the proposal support a confirmed account being allowed to perform an A->B->C move then? If a new account performs a vandalistic page move isn't the ability to revert the move also "key to editing"? It seems to me that if we are going to permit new editors to make such moves then it is equally reasonable to expect the software not to bar reverting these moves. Betty Logan (talk) 14:58, 21 May 2018 (UTC)
    • So long as the auto-created redirects haven't been edited, anyone can just move it back C->B->A. At least half of the page-move requests I see in Category:Candidates for uncontroversial speedy deletion and never, ever touch (due to bad experiences with people complaining at me about the move afterward, instead of the person who requested it) could have been moved by any autoconfirmed user if they hadn't been tagged with {{db-move}} instead. —Cryptic 15:16, 21 May 2018 (UTC)
      • This. I think perhaps folks don't know about overwriting a redirect? At any rate, it's maddening to see. ~ Amory (utc) 20:11, 21 May 2018 (UTC)
  • Seems to me that the solution we're looking for is to throttle page moves - say, to one per minute (+talk page) for autoconfirmed and five or ten per minute for extended-confirmed - rather than bumping the permission up to EC outright. I had vague recollections of this being made configurable back in the bad old days of WoW, but I can't find any evidence of it now in mediawiki source, alas. —Cryptic 15:16, 21 May 2018 (UTC)
  • Making it part of the EC rights package seems sane. There is very little utility in a user moving a page on their first day. After a month and 500 edits, that would filter out 99% of the vandalism while the overwhelming majority of new users wouldn't even know their right was restricted. Moving pages just isn't something new users do a lot of legitimately. Dennis Brown - 18:31, 21 May 2018 (UTC)
  • Oppose Seems like an ad hoc solution to a nonexistent problem to me. I am also not convinced that there is a benefit, and the attitude that new editors' rights have to be restricted more and more ad nauseam with never any good justification is bothering me. Jo-Jo Eumerus (talk, contributions) 18:34, 21 May 2018 (UTC)
  • Oppose - is seems like a properly configured edit filter resolves this. Endorse Jo-Jo Eumerus's bothersome observation. Tazerdadog (talk) 21:06, 21 May 2018 (UTC)
  • Support have seen 3 hijacking moves in last couple of days, all reverted, user blocked but it is an ongoing problem and no bot recognised it, thanks Atlantic306 (talk)
  • Here's another case of an account doing disruptive moves with just autoconfirm. KyrosFan (talk · contribs). --Masem (t) 23:10, 23 May 2018 (UTC)
  • Oppose A common use case for an autoconfirmed user needing to move a page is the cross-namespace move to article space of something they started in draft or user space. If they've worked on it with anyone else, we want the page history preserved, we don't want to drive them to making cut-and-paste moves. --Worldbruce (talk) 01:10, 24 May 2018 (UTC)

Hello, I think that allowing editors with 4 days and 10 edits to rename articles is an excessively low bar. It could be increased to 7 days and 50 edits at the least. — Preceding unsigned comment added by NaBUru38 (talkcontribs)

  • Oppose I have always gone for higher restrictions on recent discussions, but am strongly against this - it is a vastly higher limit that would remove many good edits. It would also seem out of line to have page creation at a lower level. I suppose articles that would fall into the big delete group (50k edits) could have higher restrictions on their move.
NaBUru38 - while that would make perfect sense as an edit/time requirement, Wiki has been rather staunchly against a proliferation of rights boundaries in the past Nosebagbear (talk) 12:53, 29 May 2018 (UTC)
  • Oppose. As pointed out above, AC users moving a lot of pages in short time can and should be caught by an edit filter. That's no reason to ban all AC users from moving. Regards SoWhy 14:18, 29 May 2018 (UTC)
  • Support because page move vandalism (and clueless non-vandalism) can be more problematic than the usual kinds of non-constructive editing, and because WP itself is taking page moves more and more seriously all the time; people have been blocked, topic banned, "move banned", even indeffed for disruptive page moves, and WP:AT which probably would have been fine as a guideline was elevated to policy level years ago. Either the community has decided page moving is a big deal, or it has not. We have get our story straight. PS: WP is not "the encyclopedia anyone can move stuff around it just for the hell of it". This proposal has no practical implications at all for WP being an open-editing encyclopedia, and our naming policy, naming conventions guidelines, style guidelines, RM precedents, category naming conventions, etc., take a while to absorb. Put it this way, if you're a big-corporation CEO and you just hired someone (with not pilot training), you don't say "Hey, why don't you to the roof and try flying the company helicopter around on your lunch break."  — SMcCandlish ¢ 😼  05:46, 1 June 2018 (UTC)
  • Support moving to EC or otherwise throttling the ability to move stuff. In my experience, good-faith new editors don't even know that moves exist - hence all the requests on the help desk to "rename" articles. Only someone with substantial experience and (for whatever reason) a new account is really looking for this right. There are plenty of good-faith editors in that intersection of user experiences, but my guess is that most of them are not. Matt Deres (talk) 00:03, 3 June 2018 (UTC)
  • Suggestion What if we simply allowed AC users to revert moves, which would move the page back to its original title without leaving behind a redirect? To me, this seems like a good compromise between requiring EC to move pages and requiring a page mover to fix this type of vandalism goose121 (talk) 17:34, 4 June 2018 (UTC)

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

Specific question about COI

Hi, I have no idea whether this is the right place to ask this, but I have a specific question about application of WP:OWN and WP:COI. A WP:BLP that I watch is edited by the subject to remove the date of birth (which is sourced). I restored the info and added a link on their talk page about editing your own article etc. This morning they removed the information again saying they have a right to control what data is publicly available. Who is right? The Conflict of Interest policies that I've read suggest that no-one can control what information is posted on an article, but does that apply in this case? Jdcooper (talk) 09:43, 28 May 2018 (UTC)

UPDATE sorry, false alarm, I found the relevant guidelines. Jdcooper (talk) 10:44, 28 May 2018 (UTC)
(ec) My understanding is that, in general, a BLP's DOB should be retained in the article unless there is a question of accuracy. They certainly have no "right" to control that information on Wikipedia, although we can take their request into consideration. However, because DOB is something that's very relevant to developing an understanding of the subject,there would have to be pretty unusual circumstances for me to favor removing it. Tazerdadog (talk) 10:47, 28 May 2018 (UTC)
Not only does the COI subject of a BLP not have a right to control the information, they are under greater risk of being blocked for OWN behavior than other editors. They must keep their hands off the article if they can't edit collaboratively. They are always welcome to use the talk page and suggest changes. -- BullRangifer (talk) PingMe 05:55, 1 June 2018 (UTC)
I have no comment about this issue directly, but I will note that an alternative method that article subjects can pursue is to contact the Volunteer Response Team and submit an OTRS ticket requesting the suppression of certain information for privacy reasons. I doubt this would work if the information is already widely available in public sources, but I have seen it work before, such as with the suppression of Vermin Supreme's birth name. See the latter article's talk page (permanent link) for more information on that incident. If it can work with birth names, perhaps it would also work with birth dates, too. —Nøkkenbuer (talkcontribs) 15:53, 8 June 2018 (UTC)

ESRB ratings should be on video game pages

I have sometimes wanted to look up ESRB ratings for video games just because I was curious, but I find it annoying that the ESRB's official site is the only place to go to do that, and it is tough to navigate sometimes. So can we add the ESRB ratings of video games to their articles' info table in the top right? — Preceding unsigned comment added by Kylefreed13 (talkcontribs) 20:22, 30 May 2018 (UTC)

We have previously decided against this. This is part to be consistent with the film project which also doesn't include ratings, and also reflects the fact that there are many many ratings systems so if we'd include the ESRB, we'd have to include other ratings systems which would be too much weight. We discuss ESRB ratings (or any others) if they are a subject of note but that's within the body, not in the infobox. --Masem (t) 20:27, 30 May 2018 (UTC)
Why would including ESRB mean that other ratings need to be included too? ESRB is clearly the most common one by far. Benjamin (talk) 12:58, 11 June 2018 (UTC)
In North America maybe. Europe uses PEGI. Other countries have their own rating systems as well. Why pick the NA standard over any other ones? I agree with current practices, ratings are uninteresting unless external sources comment on the ratings themselves, like changing M to AO and stores pulling out the game because of it, or something. Headbomb {t · c · p · b} 13:19, 11 June 2018 (UTC)
Why pick the NA cover image over the others? Anyway, whatever, why not just put both, if it's that big of a deal? Benjamin (talk) 13:41, 11 June 2018 (UTC)
You are going into a "what about...." argument that detracts from the focus of this discussion. To answer your question though, it really depends on copyright issues and image quality for cover images. - Knowledgekid87 (talk) 13:55, 11 June 2018 (UTC)

Seems like something for wikidata.. —TheDJ (talkcontribs) 14:12, 11 June 2018 (UTC)

Definitely a job for Wikidata. There should be no problem putting in PEGI, ESRB ratings, whatever. Then we can let templates/modules sort out what to display, in every language edition of Wikipedia. -- The Anome (talk) 14:15, 11 June 2018 (UTC)
Good idea, but do remember that English is spoken in many places other that North America so language edition alone is insufficient. Martin of Sheffield (talk) 14:36, 11 June 2018 (UTC)
What I envisaged was to display all or any of the relevant ratings, not just the one for a single country based on language: the per-language work is implementing the relevant infobox code, not choosing the ratings to display. Which ratings should be displayed is, of course, up to each Wikipedia's local community to decide. It looks like others have done the work of building the necessary framework already. See for an example of a Wikidata item for a game that is already marked up with the PEGI. ESRB, etc. metadata. Once the relevant infoboxes on enwiki have the necessary code to display these ratings, then all that is needed is to fill in metadata for all the other games. -- The Anome (talk) 14:58, 11 June 2018 (UTC)
There's likely no problem to put these to Wikidata, but as I noted above, the VG approach on is aligned with the film project here too, in that as soon as we add one like ESRB we have to add the rest because is global. And at the end of the day, unless the rating is the subject of discussion, it generally is not talked about within the article to any degree. --Masem (t) 15:05, 11 June 2018 (UTC)

Problem behaviours and rudeness

Some editors are distressed by the aggressive behaviour and rudeness of others, and/or believe that many good editors are being driven away by it. I made some observations and proposals on managing the problem at Wikipedia:Village pump (idea lab)#Best practice, several of which affect our policies. I now think it worth exploring them in more detail and widening the conversation. Would it be best to create a new thread here, create it somewhere else, or just ask folks here to follow the above link? — Cheers, Steelpillow (Talk) 16:28, 4 June 2018 (UTC)

I'll post them again here, then. I have some experience of civility codes in both commercial and public organisations, all in the UK. Here are some of my observations about current best practice and how they might be implemented on Wikipedia:
  • It is becoming increasingly accepted that rudeness and disrespect are in the mind of the recipient; if they feel insulted by you then you have insulted them, whether you intended to or not. WP:IUC needs updating accordingly.
  • Rudeness is about more than just words. Aggressive behaviours can be equally rude, not only in active aggression such as reversions but also in passive aggression such as refusal to acknowledge or discuss an issue or to admit any personal failing. WP:IUC could make this clearer.
  • Overly-detailed prescriptive guidelines are the wrong way to implement policy. An enlightened moderator is absolutely essential in dealing with incidents that escalate. As it stands today, WP:IUC is a classic example of how not to do it and does nothing but provide ammunition for logic-chopping excuses and "I have nothing to apologise for" attitudes. If it is simplified and refocused on perceived intent, that should help the moderating Admins to make better decisions.
  • Apologising for unintended harm, such as a perceived insult, is increasingly becoming mandatory. It is in this respect analogous to a fine for a parking offence, where the parking itself is only a civil offence but failing to pay the fine is a criminal one. Such a forced apology may well be mealy-mouthed and insincere, but it has been seen to be made and that is the crucial thing. Once somebody has been forced to cough up several such, they will begin to get the message. WP:CIVIL is grossly behind the times in this respect. It also needs a shortcut such as WP:APOLOGY (which currently redirects to an essay) to help raise awareness of its critical importance.
  • To be effective and deal with expert wrigglers, moderators also need a generic getout clause allowing, "we just find it unacceptably disrespectful overall" judgement even though specifics may be vague. An example would be an unjustified demand for an apology, where the demand is really just a cynical revenge manoeuvre. I don't know to what extent our Admins have this already.
  • Logging and tracking of escalated incidents is the norm. "You have been called here on three separate occasions already this year" type information should be available to moderators at the click of a button. Typically, the data is time-limited to prevent lifelong black marks. I don't know of our Admins have such tools, but they should.

— Cheers, Steelpillow (Talk) 03:17, 6 June 2018 (UTC)

Without addressing the general validity of these principles there are two issues right off the top which I see with applying them: First; we have no baseline of acceptable behavior. Likely the organizations all had either a basic code of conduct against which transgressions could be measured and addressed or a set of common norms based on shared culture. Here the best we can come up with is "fuck off" is generally OK while "fuck you" almost never is. Second; We have no moderators. Rather there is a self selecting and varying population of editors who opine at AN and ANI. There is only a verybasic consensus of what is OK or not and both outcomes and sanctions vary extensively from case to case.
The very concept of rudeness depends on a set of commonly held norms, or at least a recognition of whose norms should be applied to interprete proper behavior. (e.g. 'When in Rome. Do as the Romans) There are many ways our various editors may intend or take offense because our editors each have differing cultural and personal social capital i.e. the knowledge and social graces one gains when growing up e.g. 'ladies first', what one can and can not eat with one's fingers, and all the bits of knowledge and values one equates with being 'proper' or holds as valuable. Without some common ground it is not possible to even identify transgressive behaviors. (Unfortunately there is no Wikipedia equivalent to Emily Post's Book of Etiquette.)
I am tempted to say the solution is to focus on graciousness rather than rudeness. A gracious host neither takes offense nor gives unintended offense. The problem is graciousness is not a common value either. It does, however, have the advantage of being easily described, whereas rudeness is not. Even the gracious host must address the puppy who keeps pissing on the floor though. </pontificate> Jbh Talk 03:58, 6 June 2018 (UTC) Last edited:Added wikilinks for those interested. 15:07, 6 June 2018 (UTC)
"fuck off" is generally OK And here we see the problem... the puppy who keeps pissing on the floor Ah, the ol' WP:CIR defense. The vast majority of rudeness I've witnessed on Wikipedia has nothing to do with competency and everything to do with WP:OWN, an editor who doesn't want anybody to interfere with their preferred version or outright tries to silence another editor through deleting their on-topic comments. Wikipedia really doesn't need any further rules to deal with this behavior; it's purely an enforcement issue where "well-known" editors are hardly ever held up to the rules, allowing them to violate WP:DE with impunity. "The puppy who keeps pissing on the floor" is blocked almost immediately. The "gracious host" who pisses on the rug after the puppy shampooed it and dusted it, that's the problem. Bright☀ 10:56, 6 June 2018 (UTC)
Let me just say I disagree totally with the first point. I oppose making the alleged offended party the sole arbiter of whether something was rude or not. There will be no modifying WP:IUC to this effect. No way. The reason is that there are plenty of people around here who like to feign outrage and insult as a means of "winning" disputes. Reyk YO! 10:57, 6 June 2018 (UTC)
Like many others, the problem is rooted in the way we make decisions. You have five different viewpoints and 20 variations on those viewpoints, and people rarely change their minds as a result of discussion. You also have grudges, axes to grind, and agendas that determine many editors' contributions to decision-making. All of this is human nature and it is not going to change in the time scales that concern us. Thus it's impossible to get anywhere near the clear consensus required to make significant changes for the better.
In the area of editor behavior, self-selected self-governance is a failed social experiment. Such a thing has never succeeded in the history of civilization, to my knowledge, at least not in communities as diverse as this one. To have any hope of addressing these problems, you would have to change the system of government, and that would require WMF to assume control without asking our permission, which would not be without its own problems. ―Mandruss 11:10, 6 June 2018 (UTC)
Not going to happen. Pointless debate, as have been all of its predecessors. If people don't want to be faced with what they perceive as rudeness then they need to adopt the lifestyle of a hermit. It is the way of the world, perceptions differ and all the WMF blarney about "safe spaces" etc will not change that. As was once said, we're not here to sing Kumbaya. - Sitush (talk) 11:20, 6 June 2018 (UTC)

Thank you all for your comments. In response I should perhaps point out that I made a number of suggestions, not all linked directly to each other, so any simplistic "it won't work" type comment begs the question as to which "it" is being criticised and whether any of the others might be worth pursuing. There can never be a "baseline of acceptable behaviour", as what is acceptable in one context may not be in another. That is why it is important for moderators to be free to exercise their discretion. Someone pointed out that we have no formal Moderators but that Admins are frequently called on to perform in this role: yes, that is indeed who I mean when I talk about a moderator with a small "m". For example I already pointed out the example of someone falsely claiming to be offended and admins need discretion to make judgements about that, there can never be the total "one offended party one judgement" rule that someone misread into one bullet point. It is worth repeating that Wikipedia has a problem with so many editors walking away and I am among those who believe that our excessively abrasive environment must hold some responsibility. The suggestion that our current policies and guidelines cannot be improved is frankly ridiculous. Some degree of incremental change is needed and that is what many of my suggestions are aimed at. Somebody also pointed out that the problem is endemic within the Admin community - yes of course it is and that is precisely why I suggested some changes that might help guide such Admins towards a more considerate attitude. These suggestions do not come from nowhere, I have seen them working elsewhere and if Wikipedia will only blindly reject them wholesale then perhaps Wikipedians need to sit back and consider just why they wish to differ from the way the world is moving. Is it really my suggestions that are out of touch with reality, or is it actually the Wikipedians who are driving their ex-colleagues away? This is what I have come here to try and start a reasoned debate about, not just snap soundbites. I would respectfully suggest that, while we are indeed not here to sing Kumbaya, we are not here to piss in each other's pockets for the sake of it, either. — Cheers, Steelpillow (Talk) 21:42, 7 June 2018 (UTC)

Those will all make me glad not to be in the UK! Damn. "Rudeness and disrespect are in the mind of the recipient?" Um, no. We're not mind readers. The standard should be "knew or should have known", and whether offense would be caused to a reasonable person. If you call someone a fucking moron, you should know most reasonable people will be offended by that. If I'm offended by words containing the letter "z", you can't know that would offend me, nor is it reasonable for me to take offense to you discussing The Legend of Zelda. Far as "refusal to admit personal failings", well, if someone says you have a personal failing and you disagree, they can think what they think and you can think what you think. We already consider guidelines descriptive rather than prescriptive, and lawyering doesn't work. If someone finds a way to misbehave that isn't "technically" covered by a policy yet, they can still be sanctioned for being disruptive in general. And reverts happen, it's part of editing. If someone is too thin-skinned to get reverted sometimes, this probably isn't the right place for them to be. I will tell you right now that I will resign the bit before I use it to force someone to apologize. Absolutely not. I want people to apologize if they are actually sorry. If people are routinely forced to apologize, apologies mean nothing at all to the recipient either! If someone right now says to me "I'm sorry, I was having a bad day and I shouldn't have reacted that way", that actually means something to me. But if I knew they were going to be made to say it they mean that, or are they just getting it out of the way since they'll have to anyway? As above, we already do have that "wiggle room"—if someone's clearly being disruptive, they can be told they need to knock it off, regardless of exactly what it is they're doing. And with "logging and tracking", blocks and sanctions are logged, and noticeboards are all searchable. But the number of times someone's been to a drama board isn't the crucial bit, you need to go read the context. Did they actually do something wrong and receive a warning for it? Was the complaint generally considered to be baseless? That rather does matter. If someone is drug to ANI ten times, and all ten reports are baseless, we shouldn't sanction them anyway on some kind of "where there's smoke there's fire" stupidity. So a couple of these are already the case, and the rest should absolutely never be. Seraphimblade Talk to me 22:03, 7 June 2018 (UTC)
As Sitush said, we're not here to sing Kumbaya. We're here to build an encyclopedia using certain policies and guidelines. If I tell an editor, "no, you can't factually state that your caste is literally descended from the gods and I'll block you if you continue" I'm aware that I might be insulting them but I'm not going to apologize for upholding Wikipedia policies. Similarly, spammers told to stop spamming have offended me by trying to use Wikipedia for their personal financial gain. I respectfully suggest you need more experience with civility codes in both commercial and public organizations because "if they feel insulted by you then you have insulted them, whether you intended to or not" is certainly not the case when the rubber meets the road (performance reviews, code quality reviews, contractor objective fulfillment reviews, promotion reviews, etc.). I use these specific examples because we are essentially reviewing each other's contributions here. We can do so politely but we will give offense to people not here to build an encyclopedia according to our standards and we shouldn't have to apologize for that. --NeilN talk to me 22:35, 7 June 2018 (UTC)
(edit conflict × 2) Well, I must submit that the belief – "There can never be a "baseline of acceptable behaviour", as what is acceptable in one context may not be in another" is why there is not going to be a solution. If there is no consistent behavioral model to judge and be judged against then anything can be either a transgression or acceptable. Simply saying "what is acceptable in one context may not be in another" is pretty much a throw away statement. Of course that is true but, in this instance, the context is editing Wikipedia. The only contexts that arise are subsets of that one, for instance: interactions at articles, interactions in dispute resolution, interactions with new editors, interactions with the public e.g. BLP subjects, informal interactions among peers, etc. All of those are simply more or less strict application of the baseline. This is no different that how office/professional interactions differ from a baseline.
The issue here is that there is no general agreement on what to model the baseline off of. Some want 'professional' while others feel 'mates hanging out at a pub' is more proper. Add to that the ones who think the world should be wrapped in cotton candy and no offense should ever darken their world and you get conflict and grief from a universe of un-managed expectations.
To create manageable expectations; First define the type on online environment is desired; Then examine the values which must be held dear for such an environment to arise and be sustained; Finally identify the type of behavior which expresses and enforces those values. You talk of processes but what are they meant to achieve? How will they identify who is 'right' an who is 'wrong' if no 'right' or 'wrong' behavior prescribed? Who will administer those processes, if they are to provide coercive relief under what authority can they act?
Simply asking people not to be rude is pointless because it requires knowing not only what one considers polite/rude oneself but what each individual one interacts with does as well. Even if that is known how does one judge which set of mores should be observed? In the 'real world' the senior or dominant individual decides c.f. one's boss, one's elder or one's contextual social superior. On Wikipedia though we have no way of negotiating by whose values an interaction should be judged.
There was a long running and very divisive dispute about whether the severity of an editors transgression by the use of a certain "c-word" should be judged based on the American view of the use of that word (very, very, very bad) or the view of the rest of the English speaking world (meh, its even used on the BBC). In that case the editor, who is British, was sanctioned based on how offended Americans were. There was a bit more to it but the situation is illustrative of what happens when there is no common baseline. Jbh Talk 22:45, 7 June 2018 (UTC)
Well, yes, as @NeilN: suggests, I offend people every day, often every hour, of my editing here. A lot of that offence is very severe in nature even on those occasions where I do not name-call nor use words that some people consider to be naughty in some contexts. It frequently invokes serious reactions - legal threats, corresponding attempts at offence, occasionally death threats and in one long-running series of events, things that were so disruptive to my personal life that I had to relocate and get the WMF and police involved. Under the sort of schemes being mooted here, I would have been booted off Wikipedia many years ago and I absolutely guarantee you that the project would have been much worse for it. The same applies to a lot of other people, some of whom have indeed been forced out for Doing The Right Thing. That said, if any sort of snowflake organised monitoring of civility begins, I'll just go anyway: things have to be considered on their own merits and there neither is nor can be any bright line. We are primarily an encyclopaedia, not a social experiment. - Sitush (talk) 03:55, 8 June 2018 (UTC)

These pointless discussions founder because they are not based on any practical examples of how being nice would assist the development of a neutral encyclopedia built on reliable sources. People who are offended by assertions that evolution-is-real-get-over-it or similar in many fields need to use another website. People who civil POV push until good editors are provoked to rudeness need to use another website. The aim is to develop a neutral encyclopedia built on reliable sources, not provide a place for every nitwit to have their say. Johnuniq (talk) 23:48, 8 June 2018 (UTC)

Yes, being on the wrong end of the civil pov pushing thing earned me one of my blocks. Then, soon after, the person was globally banned or something similar by WMF but the block stays on the record. I still maintain that even my response to them was misinterpreted (deliberately) by their supporters and by an admin (also no gone) who didn't understand the context or the idiom. - Sitush (talk) 01:08, 9 June 2018 (UTC)

Indeed, this is a very tricky area so far as definitions and enforcement are concerned. I made a concerted effort to get some clarity in 2013, it accomplished exactly nothing. See Wikipedia:Requests for comment/Civility enforcement. Beeblebrox (talk) 00:20, 9 June 2018 (UTC)

As I opined above, the issue is intractable under our current system of governance. Unless someone can show that the many years of repetitive debate have changed something in this area, an entry should be added at WP:PERENNIAL. That would at least have the benefit of reducing further repetitive debate, if not eliminating it completely. Easy access to the major past discussions should be provided via PERENNIAL so that editors can see that their ideas are anything but new and that many before them have tried and failed. We could create a page devoted to compilation/summary of the relevant policy, guideline, essay, and discussion, if such a thing does not already exist, and that could be linked from PERENNIAL.
Discussion is good. Time-consuming repetitive unproductive discussion is bad. Realism is good. ―Mandruss  10:19, 9 June 2018 (UTC)

Whether or not civility codes can work among employees within a particular geography, here we are volunteers on a global project. Simply implementing something that is "best practice", trendy and possibly workable in California, London, Moonee Ponds or Saudi Arabia will only give you a reminder as to how different the world is. That isn't to say we can't or shouldn't have changes here, and yes we could make the place less bitey to newcomers and regulars alike. But any successful change to a complex system like this needs to be very specific, nuanced and researched against what has been tried before. As a rough guide allow for more work in the design stage than the coding stage. We are currently at a stage analogous to surgery in the Victorian era before gentleman surgeons had been persuaded of the need to wash their hands before operating on patients. Hence the widespread myth that editors biting each other is entirely a behavioural issue. If you do outreach and talk to newbies you soon realise that sometimes it is a software issue and that making a few software changes to reduce edit conflicts would do quite a bit to make this place, and especially newpage patrol, less bitey. But good luck persuading the WMF and especially the developers that when people talk of being bitten by the regulars on Wikipedia sometimes they really mean being on the losing end of an edit conflict. ϢereSpielChequers 11:51, 9 June 2018 (UTC)

@BrightR: I believe your comments hit the nail squarely on the head. That is a major issue. Our one guideline--don't bite newcomers--is clever and colorful but mostly unusable as an actual guide.
Discussion here is going back and forth between "ethics" and "morality". A general humanistic ethic is not difficult to determine. Jonathon Haidt has done so cross-culturally. He has established at least 5 cross cultural ethical principles, and since Jbhunley is right in saying our context is limited to and defined as Wikipedia, that means there is only really one principle of concern to worry about applying here: be considerate of others, make the effort not to do harm. In many ways those are already advocated and should be advocated. If a stronger support of that ethic is the best we can do, then at least that is something.
As for specific rules of practice, first, those who take disagreements over content personally is not the concern here. Set that aside. Disagreements over content already have multiple methods for resolution that work reasonably well. The fact there are no such methods for resolving personal attacks is the issue.
The bottom line here is whether or not editors believe--or don't--that what has been termed "the abrasive environment" of Wikipedia does harm to Wikipedia. That's our only concern defined by our limited environment and limited interaction. Some people are nice. Some people aren't. That too is beside the point. Does the absence of better more specific guidelines concerning personal attacks harm Wikipedia? If you as an editor think possibly yes, or definitely yes, then we should agree to do something about it.Jenhawk777 (talk) 17:08, 9 June 2018 (UTC)
Discussion here is going back and forth between "ethics" and "morality". I read the sentences after that and still have no idea how you came up with that. --NeilN talk to me 18:17, 9 June 2018 (UTC)
Ethics is the big picture issue, morality is its rule based applications. Sorry--jargon. I apologize. Jenhawk777 (talk) 19:29, 9 June 2018 (UTC)
You're arguing from a predetermined position, hence the use of the word "better". An alternative to your questions could be "would the addition of more specific guidelines concerning personal attacks harm Wikipedia ..." But, either way, I refer you to my first response in this thread: it is not going to happen. If you want it to happen then feel free to fork. - Sitush (talk) 17:00, 10 June 2018 (UTC)
we should agree to do something about it The obvious thing which has been raised time and again is abolishing the selective enforcement of rules. The top is definitely not interested in equal and fair enforcement of rules and as has been noted time and again, the hardcore Wikipedia contributors are not interested in equal and fair enforcement either. The only way I see things changing is if the Wikimedia Foundation decides enough is enough and replaces the admins with an army of hired, uninvolved, non-editors who take WP:DISRUPTSIGNS at face value and block anyone who is disruptive. You'll see attitudes being adjusted overnight. Bright☀ 18:15, 10 June 2018 (UTC)
BrightR, what you suggest would indeed cause a very, very rapid shift in attitude. It would be a shift from "This volunteer project I contribute to has its problems, but it's ours, and I'll happily volunteer my time for it", to "Well, that's the last second of my time I ever volunteer for Wikipedia. I guess I'd better help out the people who are forking it to an actual community-based project instead." Wikipedia is run by its volunteer community, not by fiat. That's a feature, not a bug, even when one occasionally does not like the outcome. Seraphimblade Talk to me 00:29, 11 June 2018 (UTC)
You say you will leave if things change and everyone of us here knows people who have already left because things don't change. I am indeed arguing from a predetermined position that civility is preferable to incivility. Since it is already a general principle of Wikipedia's, it doesn't seem necessary to remake the wheel here. Do personal attacks--genuine personal attacks--harm the bigger picture, interfere with quality product, prevent Wikipedia from achieving its goals in any way--however you want to phrase it--does working in a peaceful environment tend to accomplish more? How hard is it to ask people to please simply say, 'I disagree', instead of 'I disagree you stupid ignorant fuckhead?' Jenhawk777 (talk) 04:38, 11 June 2018 (UTC)
A community-run project can still have equal and fair enforcement of its rules. There are already many forks of Wikipedia, how's that working out for them? Bright☀ 10:31, 14 June 2018 (UTC)

Revised suggestions

For all I know this may be just a rehash of previous discussions, but I have certainly learned something useful, notably from Sitush who tackles some of the PoV communities that infest certain areas of life and Wikipedia. Also, it is clear that mandating an apology is never going to happen outside of specific Admin decisions (where I have seen it demanded). I guess my original thought needs some re-orientation: given the concerns over driving valuable editors away, can we strike a better balance between abrasiveness and civility?, so here is a modified set of proposals with greater focus on practical changes to policy and/or toolsets:

  • Rudeness is about more than just words. Aggressive behaviours can be equally rude, not only in active aggression such as reversions but also in passive aggression such as refusal to acknowledge or discuss an issue or to admit any personal failing. WP:IUC could make this clearer.
  • Overly-detailed prescriptive guidelines are the wrong way to implement policy. An enlightened and empowered moderator (i.e. the Admin coimmunity) is absolutely essential in dealing with incidents that escalate. As it stands today, WP:IUC is a classic example of how not to do it and does nothing but provide ammunition for logic-chopping excuses and wikilawyering. If it is simplified and refocused on perceived intent, that should help the moderating Admins to make better decisions.
  • Apologising for unintended harm, such as a perceived insult, can often yield a positive outcome. Such an apology may make no sense to the person apologising, but it has been seen to be made and that is the crucial thing. Once somebody has been asked to deliver several such, they will begin to get the message. WP:CIVIL is grossly behind the times in this respect. It also needs a shortcut such as WP:APOLOGY (which currently redirects to an essay against apologising) to help raise awareness of its value.
  • To be effective and deal with expert wrigglers, moderators (i.e the Admin community) also need a generic getout clause allowing, "we just find it unacceptably destructive overall" judgement even though specifics may be vague. An example would be an unjustified demand for an apology, where the demand is really just a cynical revenge manoeuvre. I don't know to what extent our Admins have this already.
  • Logging and tracking of escalated incidents can help identify destructive individuals, but also raises concerns about retaining such information for too long. "You have been called here on three separate occasions already" type information should be available to moderators (i.e the Admin community) at the click of a button. The data needs to be strictly time-limited to prevent lifelong black marks. Perhaps one calendar year would be about right, perhaps a few months? I don't know if our Admins have such tools, but I would suggest that they should.

— Cheers, Steelpillow (Talk) 20:16, 10 June 2018 (UTC)

Any plan to force civility on a diverse community needs to first determine how to handle civil POV pushers, unemotional SPAs, paid advocates, and those lacking competence. Here is something that might work: in each month, an admin who does any civility blocks must also block a roughly equal number of unhelpful contributors who cause trouble and waste time. Johnuniq (talk) 23:24, 10 June 2018 (UTC)
Any plan to force civility on a diverse community needs to first determine how to handle civil POV pushers, unemotional SPAs, paid advocates, and those lacking competence. Why, may I ask? It seems to me that these two issues are quite orthogonal. They saying "it doesn't cost anything to be nice" comes to mind.... CapitalSasha ~ talk 23:30, 10 June 2018 (UTC)
There is no problem with genuinely uncivil contributors because they are easily blocked. Anyone disagreeing should post a couple of examples. The problem occurs when a good editor gets frustrated with a POV pusher. Blocking the good editor because the POV pusher was civil will damage the encyclopedia. All "normal" editors who build content will eventually be removed as they become overwhelmed by the clueless who have learned to tick all the CIVIL boxes. Johnuniq (talk) 23:36, 10 June 2018 (UTC)
I understand your point but I feel that it is a bit absurd. Surely most "normal" editors can figure out how to not personally attack the POV-pushers? It's not that hard.... CapitalSasha ~ talk 23:39, 10 June 2018 (UTC)
Steelpillow, you reflect the exact problem that Johnuniq raises. You carry on with essentially the same thing as though you didn't even read the answer. That answer, in large, flashing, bold, letters, is NO. It is not "ask again until you get a different answer", it is not "tweak your proposal a little", it is "We read your proposal and we reject it." That is why we have pages like the one about dropping the stick, and when someone gets that showed to them, sometimes their feelings get bruised. Too bad. Wikipedia, as was once stated, is not an ivory tower, it is a shop floor. To get anything at all done, we need to be direct and honest with one another. We shouldn't be needlessly uncivil or abrasive, but some people take bluntness as meanness. The answer to your proposal is NO. I'm sorry if such bluntness strikes you as mean, but some people refuse to see something until it's put in their face, and when that happens, we need to put it in their face so they stop wasting time. Sometimes, that needs to be "Quit asking that question, it's already been answered." Sometimes, that needs to be "If you do that again, I'm going to block you." Sorry if that bruises someone's feelings sometimes, but we're undertaking a very large project here, and we really don't have time to cater to the thin-skinned. Seraphimblade Talk to me 00:43, 11 June 2018 (UTC)
Seraphimblade, that doesn't seem to me to be the clear conclusion from the above discussion. CapitalSasha ~ talk 00:57, 11 June 2018 (UTC)
To add two more substantive points, (1) why on earth should the "thin-skinned" (i.e. those who don't enjoy being told to fuck off all the time) be excluded from editing Wikipedia, when surely they could make many valuable contributions in a less hostile environment, and (2) it doesn't take any additional time to be civil. CapitalSasha ~ talk 01:02, 11 June 2018 (UTC)
Experience tells me that the thin-skinned see offence where the consensus of the community is that none existed. That has wasted a lot of the time of a lot of people over the years. - Sitush (talk) 01:18, 11 June 2018 (UTC)
I believe it's very well-established that the Wikipedia community is not at all representative of the wider population, which is a problem in my view. I think there is a compelling argument for Wikipedians coming to a consensus that we should put aside our consensus of personal opinions about what should be acceptable in favor of a consensus of wiser opinions about what is good for the project in the long run. CapitalSasha ~ talk 01:36, 11 June 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── If we listened to the "consensus of wiser opinions" (and by the way, whose wiser opinions?), we'd never have started this project, because clearly the idea of an encyclopedia that the whole world can edit is laughable and ludicrous. Here we are, coming on twenty years later, and flying in the face of those "wiser opinions", we made the damn thing work. With a community-based, consensus-driven model, not a top-down "wise lawgiver" model. Sorry, that ain't changing, and it had certainly better not. It made this whole crazy experiment work to being with. Seraphimblade Talk to me 02:09, 11 June 2018 (UTC)

By wiser opinions I only meant our own opinions with cooler heads than might prevail in the face of a frustrating situation. I'm definitely not proposing to scrap the community-based model!! As I said, I think it's well-established that Wikipedia's community is highly skewed demographically, and I'm not sure that that's sustainable. But I only seek to advocate within the community structure, obviously. CapitalSasha ~ talk 02:21, 11 June 2018 (UTC)
The community will always be highly skewed demographically. For example, most of my friends would prefer to spend their time in the pub and at the gym than researching and writing. The vast majority of people have no interest in disseminating knowledge and a surprisingly high number have little interest in assimilating it in the pseudo-academic context that Wikipedia presents. - Sitush (talk) 02:27, 11 June 2018 (UTC)
And of the people who are interested in disseminating knowledge in the pseudo-academic context that Wikipedia presents, 90% of them are male? Surprising.... CapitalSasha ~ talk 02:30, 11 June 2018 (UTC)
Yes, that's where I thought you would be going with this. I am not engaging on the female Wikipedian issue: it is mostly bollocks to connect that to perceived civility and I really do not care what surveys may say. I could list a whole load of civil pov-pushers to prove the point and I could list a whole load of women I know in real life who have mouths like gutters. - Sitush (talk) 02:43, 11 June 2018 (UTC)
I don't know that the claim is that women are less happy with incivility; I certainly don't want to make that claim now. Another possible claim could be that rudeness discourages newcomers and members of outgroups in general, and allowing people to be nasty to each other tends to further bias the site towards the people who are already here, who are demographically skewed. I'm not sure. I'm a bit surprised though by your lack of curiosity/interest, and I'm not sure why you value your anecdotes over "what surveys may say." CapitalSasha ~ talk 02:53, 11 June 2018 (UTC)
The claim has been made repeatedly but the surveys are themselves skewed. For example, I edited an article last week about a village in India where the 2011 census reported literacy (this is very basic literacy) among its women was 30-odd percent and that for men was 70-odd per cent. Yes, it is quite probable that the village also has poor internet connectivity but I think there is a systemic issue that goes way beyond Wikipedia when things like that come to light. Similarly, a recent piece I read in, I think, The Signpost reported that many women do not realise anyone can edit this thing. God knows why the literate amongst them can't read the blurb (or choose not to read it), but clearly if correct then that impacts on the skewedness. Perhaps we should be doing more outreach with mumsnet etc. In any event, the world is a rough place and keeping things compliant with our policies etc here means we cannot always treat people with kid gloves. I think Steelpillow has realised that now. - Sitush (talk) 02:58, 11 June 2018 (UTC)
User:CapitalSasha Another possible claim could be that rudeness discourages newcomers and members of outgroups in general, and allowing people to be nasty to each other tends to further bias the site towards the people who are already here, who are demographically skewed. Amen sister. Seems irrefutable to me. bias
User:Sitush Isn't there some middle ground for you between the rough world and kid gloves? Can't keeping things compliant with our policies here be done in a civil fashion? Instead of focusing on the tiny percentage of those thin skinned you abhor how about the rest of the world of Wikipedia? Jenhawk777 (talk) 04:38, 11 June 2018 (UTC)
See, you are doing it again with your presumptions. Abhor? Who said anything about abhorrence? - Sitush (talk) 04:40, 11 June 2018 (UTC)
@Seraphimblade: Which of my five remaining suggestions are you saying "no" to? And what "consensus" are you referring to? I see none here yet. — Cheers, Steelpillow (Talk) 08:53, 11 June 2018 (UTC)

A possibly wise person once said "These pointless discussions founder because they are not based on any practical examples of how being nice would assist the development of a neutral encyclopedia built on reliable sources" so let's get started. Does this comment violate CIVIL? Should the author have been blocked? Would it be desirable to investigate the background first? Johnuniq (talk) 06:10, 11 June 2018 (UTC)

I would say that technically, yes it does breach CIVIL, but that also, yes the background needs to be understood before the scale of the offence can be judged. I have seen rudeness used as a tactic to drive tenacious PoV timewasters away before now, and it always distresses me. Straight bluntness and topic bans are always to be preferred. But we are all only human and exasperation does sometimes win out. I have suffered the odd block on that account myself (exasperated rudeness, not timewasting, in case you are wondering seraphimblade.Face-wink.svg). The example here appears trivial, perhaps deserving at most a "could have been more polite without losing impact", I doubt that it should have earned a block unless the back story is exceptional, e.g. the poster had already been censured and told to desist, hence the suggested utility of a short-term tracking tool. I also believe that WP:IUC is over-prescriptive in such cases, because the more it says, the more it opens the way to endless wikilawyering. The Admin community should be given a little more air to moderate such individual cases as they see fit. But I also believe that other aspects of the policy could be clarified. Hence my suggestions here. — Cheers, Steelpillow (Talk) 09:32, 11 June 2018 (UTC)
User:Johnuniq I appreciate the specific example. That's excellent. While I would say this person is not exactly civil, in my opinion this example does not fall into the category of personal attack. There is disagreement over content. He denigrates the case you make, relevancy, claims there is misunderstanding on your part, references policy, attempts to focus the argument on the issue, and actually compliments you on the rest of your work. He is clearly exasperated, but at no time does he actually make a personal attack. Someone can comment on your writing, your logic, your references, and anything else without it actually being an ad hominem attack. He never says you are stupid. He never actually says anything about you individually at all. His manner and language are in that grey area of incivility in real life, but in the Wiki-world, it does not cross that line. If there was an enforceable rule about "no personal attacks" and the specific example had to be included--there is no example here to give.
So that's a good example of something that might upset someone that is not actually a personal attack. If there was a policy, an admin would suss that out right away I expect. Jenhawk777 (talk) 18:13, 11 June 2018 (UTC)
I gave two examples of rude behavior directly harming the encyclopedia (undoing corrections, deleting a talk page comment that pointed out a mistake). The problem is that there is no enforcement against this behavior. Instead of dealing with hypothetical "does this harm the encyclopedia" you can just put your foot down and block editors who outright harm the encyclopedia and use incivility to get their way. Johnuniq's example may show no immediate damage to the encyclopedia, but at this level of discourse ("FUCK OFF") is counter-productive to consensus building and editors who engage in such behavior should be warned that when it crosses into WP:OWN they will be blocked. Bright☀ 10:40, 14 June 2018 (UTC)
You're right. And you're right again. I had no idea I had the ability to block someone here. (Holy crap Batman!) And then you're right again. Jenhawk777 (talk) 00:02, 15 June 2018 (UTC)

Channel lineups and pricing tiers in articles about Media providers

Question here raised by myself and a COI editor another editor who both were curious to know policy regarding media company providers listing channel lineups and package tier offerings (along with prices) in these articles. I had removed these instances from Sling TV owing to WP:NOTACATALOG and WP:NOTTVGUIDE, but the COI editor the other editor rightly asked why these would be allowed on other media providers' articles and not Sling TV. It's a good question, and I wanted to know what editors thought about this practice. Checking the Pump archives, I found a discussion from 5 years ago at Wikipedia:Village_pump_(policy)/Archive_99#Channel_lineups_in_Wikipedia which touched on the topic, but there did not seem to be a resolution. The talk page discussions around the site regarding pricing in general are numerous, and while I look through many of them, I see a lot of back and forth on what is allowed, although many seem wary of the practice and tread lightly in that area. Would like to get an idea of what current policy/practice is. Currently, Wikipedia:WikiProject Media appears to be a ghost town — which is why I brought my question here. Any input would be appreciated Face-smile.svg spintendo  01:58, 6 June 2018 (UTC)

Channel lineups, pricing tiers and anything which would go on an advert are, well, advertising and not acceptable in an article. See WP:NOTPROMO#5. Much of the Sling TV article should be stripped out. Sections 1-3 are mostly promotionalism and Native advertising. I suggest stubbing. Jbh Talk 02:15, 6 June 2018 (UTC)
I also think it is also an issue with the other streaming providers (Philo (company), PlayStation Vue, YouTube TV and DirecTV Now as well, where packages and prices are listed. So it is not limited to the Sling TV article. Don't think any of the satellite or cable company articles have this issue. Msw1002 (talk) 03:48, 6 June 2018 (UTC)
(Note to Msw1002: I mistakenly referred to you as a COI editor in my post. That has been corrected.) Sorry about that!  spintendo  12:48, 6 June 2018 (UTC)
No problem. :) Msw1002 (talk) 13:27, 6 June 2018 (UTC))
I have removed the worst sections and tagged the articles with {{advert}} but I do not have the stomach to go through and clean them up. Jbh Talk 21:25, 6 June 2018 (UTC)
If independent sources have commentary about pricing this could be there, but it should not be advertising in nature, and not just quoted from the vendor. There is substantial writing on the price of Apple or Samsung products, so that a whole article could exist on that. Graeme Bartlett (talk) 22:49, 6 June 2018 (UTC)
Thank you JBH. And Graeme I agree with you, especially if the price were also a part of the narrative of an item, either because of a price war or some other unique circumstance which made the item's price something that became notable in reporting done upon it. In contrast, the inclusion of the prices in these media services articles seem set on whatever the price is at the moment, and seems to go against the spirit of WP:NOTACATALOG, which focuses on pricing done for the act of comparing prices.  spintendo  23:39, 6 June 2018 (UTC)
There are definitely independent sources out there such as . So those should be used instead of direct from providers if pricing is mentioned (if at all). Msw1002 (talk) 13:23, 7 June 2018 (UTC)

Consistent titles for esports athletes

It seems that there may need to be a policy governing the titles of articles about esports (competitive video gaming) competitors. Some of them use the player's legal name, and some their gaming name. My personal take is that it should probably be their gamer handles. Actual names are rarely if ever used in a lot of those communities.TylerRDavis (talk) 20:06, 6 June 2018 (UTC)

I would think this would be settled by applying our existing WP:Article titles policy, especially provisions such as WP:COMMONNAME. No? Blueboar (talk) 20:52, 6 June 2018 (UTC)
Same approach (whichever is taken) should be applied to socalled "Youtube celebrities" like Markiplier and PewDiePie. Right now I think COMMONNAME is the prevailing approach, using their handle over their real name, which in some cases isn't always known. --Masem (t) 21:43, 6 June 2018 (UTC)
No, their handle is not always the common name. --Izno (talk) 01:47, 7 June 2018 (UTC)
This has already been discussed at some length. The applicable guideline is WP:STAGENAME and the applicable policy is WP:COMMONNAME. --Izno (talk) 01:46, 7 June 2018 (UTC)
So, if someone were to go through all of these articles and change the titles to the name these players are commonly known as, meaning their "gamertag," that would be acceptable?TylerRDavis (talk) 18:17, 7 June 2018 (UTC)
Not necessarily... this needs to be determined on a case by case basis. We have to examine the reliable sources that discuss each individual player, and determine which name is favored by those sources. I suspect that the “gamertag” will be favored in most cases... but there may well be exceptions... cases where the sources indicate that a specific player is best known by his/her real name. Blueboar (talk) 22:50, 7 June 2018 (UTC)
Agreed, COMMONNAME already handles this, there’s no need for topic-specific guidelines. Beeblebrox (talk) 03:37, 8 June 2018 (UTC)
What's probably most sensible to is to update MOS:VG and WP:NCVG with a note about this, i.e. with the professional-videogaming-specific application of WP:COMMONNAME. This is a typical approach for subject-specific MOS and naming conventions pages; their very purpose is to explain how extant system-wide rules apply to the topic in question, not to make up variant rules that conflict with them (or to let recurrent disputes fester and multiply by refusing to provide such clarification).  — SMcCandlish ¢ 😼  23:41, 12 June 2018 (UTC)

RfC Enforcability of logged editing restrictions

An RfC has been opened about whether voluntary editing restrictions logged at WP:Editing restrictions#Voluntary can be enforced in the same was as those logged at WP:Editing restrictions#Placed by the Wikipedia community. Your input would be appriciated.

The RfC is located at WP:Enforceability of logged voluntary editing restrictions Jbh Talk 06:30, 7 June 2018 (UTC)

Including ISSNs in citations

This is from a discussion originating at User talk:Headbomb/Archives/2018/May#ISSNs. Are International Standard Serial Numbers (ISSNs) absolutely unnecessary and do they require removal from citations? Or are they useful and allow users flexibility when other locators like a DOI get broken? Something in between? --Nessie (talk) 19:48, 9 June 2018 (UTC)

ISSNs they serve little to no purpose in citations. Absolutely zero style guides recommended their inclusion, and for good reason: It's the least useful of all identifiers, they are redundant with the title of the publication in nearly all cases, and are made completely obsolete when a DOI (or any similar document identifier) is present. Some people will say "but this tells what the libraries holds the publication" and to that I say this is not how people use libraries. I live in Truro, NS. Knowing that Daedalus (ISSN 0011-5266) is held in 4 libraries in Denmark is completely unhelpful to me. This brings us to another point: the WorldCat catalog is more-often-than-not crap. Many more libraries than those in Denmark hold that journal, some in Cambridge since that's where the American Academy of Arts and Sciences is located. This could mislead someone from Cambridge into thinking it's pointless to go to their own library to get the journal, or someone from Truro from going to the library because they don't know interlibrary loans are a thing. What I do, regardless of where the item is held, I go to my local libary, and get them to order the item if they don't hold it. ISSNs serves a minor purpose when distinguishing between two similarly named journals that are defunct/out of print, when no article identifiers exist, and that's about it. Headbomb {t · c · p · b} 20:00, 9 June 2018 (UTC)
I have never seen the utility in having ISSNs. I'm open to be convinced, but I've yet to find them useful. ~ Amory (utc) 20:22, 9 June 2018 (UTC)
I would follow Hawkeye's view in the original argument. They may not have a lot of utility but they are allowed as an option. I would not go to any great length to add them but I am always very reluctant to delete information.  Stepho  talk  21:24, 9 June 2018 (UTC)
It's not correct that zero style guides recommend their inclusion. Our Australian Style Manual recommends them, and conformance with the style manual is a requirement of the university style guide. Hawkeye7 (discuss) 21:54, 9 June 2018 (UTC)
With respect to the WorldCat catalog, there is an official partnership between WMF and OCLC, both being organisations committed to the goal of free public knowledge. I would caution against assuming your own experience is normative. I live in Canberra, which is an order of magnitude larger than your town. It has aspects of a university town, with two major universities and external campuses of three more. While a Canberran could walk down to the local library and ask for an inter-library loan, for the books and journals we use in Wikipedia articles, they are more likely to look it up online, and cycle (the place isn't that big) down to one of our major government or academic libraries. The same search you ran [1] tells them that paper copies are held by two nearby libraries. It also tells them that their library card gives them electronic access. Like your search, it is flawed in that it isn't comprehensive; a search on a different (non-public) library search engine for which I needed the ISSN as a key revealed more nearby holdings. Hawkeye7 (discuss) 23:18, 9 June 2018 (UTC)
  • I don't see ISSN as any more or less useful than other types of identifiers: most people will read past them, but to a few they're going to be helpful. If a DOI is already present, then I don't think the ISSN is useful (maybe propose a change to the templates that will hide it in such cases if its presence is really that much of a problem?). But then, there are tons of journals that haven't subscribed for doi's, and are unlikely to ever do, and for those, ISSNs can be really helpful. For example, a journal might have undergone several changes in its title over time, and a given library catalogue might not reflect them all: an ISSN on the other hand is persistent, so knowing it could save you the trouble of tracking down and looking up all the title variants. – Uanfala (talk) 15:34, 10 June 2018 (UTC)
This smacks a bit of WP:IDONTLIKEIT. If ISSNs may be useful to some people, that is sufficient to justify their retention. Even Headbomb admits they are sometimes useful ("ISSNs serves a minor purpose..."). They are doing no harm and do not "require removal from citations". Martin of Sheffield (talk) 16:26, 10 June 2018 (UTC)
I've never found them useful. They do no harm but they do not need to be included either. DrKay (talk) 16:48, 10 June 2018 (UTC)
I have always removed them for news sources. I once asked (in an edit summary at a high-activity article) for somebody to make a reader value case for that, and there was no response. If there is no reader value for a citation parameter, it should be omitted, and it should be removed when not omitted. We don't include things just because we can, there needs to be some coherent rationale for what we include, and there is no reason that should not apply to citation parameters. No opinion as to non-news sources. ―Mandruss  16:56, 10 June 2018 (UTC)

ISSNs can be useful when there are multiple periodicals with the same title. – Jonesey95 (talk) 00:05, 11 June 2018 (UTC)

Agreed. They also provide a lookup mechanism, and can be used in various databases like library search systems. They're useful enough, and not any different from all the various other IDs we support (PMC, PMID, ISBN, OCLC, DOI, yadda yadda). If we were to consider expunging one, it would ASIN, which is just one vendor's catalog number, and serves no purpose but to drive customers to in particular. Last I looked, WMF isn't an Amazon subsidiary, so we really shouldn't be doing that. In the rare even of a work released only on Amazon, and actually reliable enough to cite [most such works are self-published e-books], simply linking to the URL of the item page is sufficient; adding the ASIN does nothing useful, since it's just a way to ID the same page.  — SMcCandlish ¢ 😼  04:42, 15 June 2018 (UTC)

MOS:TM minor clarification proposal

FYI: Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Trademarks#Minor clarification to avoid interpretational conflict between MOS:TM and WP:TITLETM.

Abstract: A recurrent interpretational confusion suggests we need a clarification note at MOS:TM.  — SMcCandlish ¢ 😼  23:38, 12 June 2018 (UTC)

Wikipedia:Wikidata/2018 Infobox RfC: closed

Because I know this is of interest to so many people, I'm providing notice here that I have closed Wikipedia:Wikidata/2018 Infobox RfC. (And hoping I got the formatting right.) I apologize that it took me so long to finish this. -- llywrch (talk) 16:51, 13 June 2018 (UTC)

Thanks the closers for the good work. This was almost a suicidal task to accomplish, and though I am sure some users would disagree I think this is the best possible closure given the circumstances.--Ymblanter (talk) 18:35, 13 June 2018 (UTC)
Definitely a difficult close, and I won't personally fault the closers for the conclusions reached, but there are two clear errors in it, one of omission of facts, and one of policy interpretation:
  • "There is clearly a group who are opposed in any way to the use of Wikidata, and who all voted the same identical way: "1A 2A 3A 4A" These 31 Wikipedians (out of the 94 people who participated in the poll part of this RfC) in effect opposed to any use of Wikidata data in infoboxes." This is a factually incorrect assessment; many of those in this diffuse group of commenters (myself included) are not "opposed to any use of Wikidata in infoboxes", only opposed to its use until WikiData has a means of filtering content on a per-project basis so that, e.g., only WD content that has been vetted for compliance with en.WP sourcing policy is imported from WD into en.WP. While the close addressed this policy-related concern later in its wording, the characterization of "the 94 people" is incorrect and sets up a false dichotomy, an "us versus them" that is illusory, but which could cloud later discussions if not addressed.
  • "This reading of the poll is supported by a recurring theme in the discussion portion of the RfC, that individual Wikiprojects should be offered the opportunity to experiment with material from Wikidata. This suggestion may warrant further exploration." That's not even a possible result under en.WP policy. Per WP:CONLEVEL, WP:EDITING, WP:OWN, and WP:NOTWEBHOST policies, no wikiproject has any more claim to control over any piece of WP content than any other editors (and there is virtually no article that could not be within the scope of multiple wikiprojects anyway). Constraining OWN-ish antics by wikiproject is why we have CONLEVEL policy in the first place, and why ArbCom has repeatedly heard cases the central matter of which was wikiprojects' attempt to control topics, and concluding with rulings that they cannot. If there is no consensus for automatically importing WD content into en.WP infoboxes, there is no magical local-consensus power to overturn that on the part of, say, WikiProject Botswana to use wikidata in Botswana-related articles.
 — SMcCandlish ¢ 😼  01:33, 15 June 2018 (UTC)
  • Not the closer nor an admin, but regarding the latter point, I respectfully disagree, SMcCandlish. CONLEVEL determines that lower-level consensus cannot overrule higher-level consensus, certainly; and that WikiProject consensus is in fact a lower- not higher-level consensus. So indeed, if the wider community says "No.", a WikiProject cannot say "yes, for us".
But if the wider community were to say either "no consensus of any kind exists" or "leave it to lower-level consensus to determine what is right for them", a Wikiproject can say "Well, this is what we consider right for us" and can implement it—at least on those articles or pages where said consensus is not challenged.
On those pages where the consensus is challenged, there thus is no actual consensus and matters should be solved the same way as when for whatever other non-policy-bound, non-higher-consensus-bound reason editors disagree with the way an article should be treated: use the talkpage to discuss and attempt to form a consensus or acceptable compromise for that specific page or group of pages, so long as it does not run against global consensus, policy, etc.; if that does not work, follow the relevant steps in solving a content dispute. That this does not always happen as should is sadly a fact, both in cases without and with WikiProject involvement; and that sometimes editors or WikiProjects assign the consensus they've reached a higher status than that of the local consensus it is, if not in word then in action is equally true. However, this does not change the fact that the relevant case specifically states:
"Where there is a global consensus to edit in a certain way, it should be respected and cannot be overruled by a local consensus. However, on subjects where there is no global consensus, a local consensus should be taken into account." (emphasis mine)
"No consensus" is the absence of consensus in either direction, not consensus against. Thus, as there exists no global level consensus other than "whatever WikiData is imported/used must be reliable" (presuming the close is correct in judging consensus), then so long as, say, WikiProject:Botswana does not go against that, said WikiProject choosing to import WD content isn't overturning anything nor runs against CONLEVEL; and so long as said WikiProject keeps in mind that their consensus is not of higher status than the consensus of editors to any particular article even if said article is within their scope, it does not go against WP:OWN either. AddWittyNameHere (talk) 03:28, 15 June 2018 (UTC)
This is not a case of no consensus, it's a case of consensus that "if Wikipedia wants to use data from Wikidata, there needs to be clear assurances on the reliability of this data", to quote the close. That reliability assurance is presently not technically possible and will not be for the foreseeable future, so this is a clear-cut case of "lower-level consensus cannot overrule higher-level consensus". More to the point, it's just "un-wiki", in an important sense, to even suggest that wikiprojects should go around making up their own rules. We've been down this road before, and it's been a trainwreck every single time. Some of our longest-running and most disruptive disputes have been the direct result of it (e.g. over a decade of feuding about [over-]capitalization of the vernacular names of species, as just one example). When multiple policies, ArbCom cases, and RfCs all point in exactly the same direction that is unmistakably a site-wide community consensus against the "wikiprojects are their own little sovereign fiefdoms" nonsense  — SMcCandlish ¢ 😼  03:31, 15 June 2018 (UTC)
(edit conflict)I recognized the consensus on that point ('other than "whatever WikiData is imported/used must be reliable"', although I do recognize that I oversimplified my representation of that. My original drafted sentence was more specific and inclusive but I regretfully cut it down a bit too much in an attempt to shorten my response before posting, which already is long but was significantly longer at one point). I will take you on your word that the technical impossibility of this means that de facto there is no way of ensuring this at this moment and thus no way of using the data without running against the existing global consensus; I do not consider myself well-informed enough to judge this either way though it certainly sounds logical.
My main reason for replying was that such a ruling is not impossible under en.WP policy in general, which your wording suggested to me you meant, in particular the phrasing "That's not even a possible result under en.WP policy". It is certainly well-possible I misunderstood you and you meant it as impossible in this specific case. If that is indeed the case, by all means feel free to collapse the above section (or ask me to if for any reason you'd rather I do so) if you feel it best. AddWittyNameHere (talk) 03:56, 15 June 2018 (UTC)
EDIT: Looks like I edit-conflicted with your addition; my response above was to your original, shorter, reply. Considering I specifically stated WikiProject consensus to be of no higher level than any other local consensus and outright said I feel that when a WikiProject consensus is challenged on a page it should be handled the same way as when any other non-global consensus is challenged, I hardly hold to the "wikiprojects as sovereign fiefdoms" school of thought myself. I do however believe consensus formed through them is a valid form of local consensus in the absence of either conflicting local consensus or global consensus. As I suspect we could both continue about this subject for a fair while—even though I believe our actual stances are not all that far apart—I suspect that it's better if we wrap up our conversation here and either respectfully agree to (slightly) disagree or move it to either your or my talkpage, whichever you prefer. AddWittyNameHere (talk) 04:03, 15 June 2018 (UTC)
Seems we were just talking past each other. I'm not making a general point, but one specific to the case. We use local consensus all the time for things we don't have any broad consensus about. This just isn't one of those cases (even if consensus was not achieved on every single point at issue in the RfC, it was reached on the central matter).  — SMcCandlish ¢ 😼  04:51, 15 June 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Yup, seems like we were indeed talking past each other. You've now answered the point I've raised above prior to my edit, though: you were indeed speaking of this specific case not generally and my original reply was based on a misunderstanding of what you were saying. AddWittyNameHere (talk) 05:06, 15 June 2018 (UTC)

@Llywrch, Swarm, and Fsh and Karate: I have no idea where the 31 1A etc. voters count comes from, if I have counted correctly there are 42 votes of "1A, 2A". Whether these voted for 3A, 3B, or no 3 at all doesn't really matter, as there was no "3" option which really corresponded with 1A and 2A. I'm not claiming that 42 people would constitute a consensus, but to se them reduced to 31, thereby diminishing the percentage of 1A, 2A voters drastically, is not correct. Having 1/3 opposed to any use of Wikidata, or having 45% opposed, is quite different. Fram (talk) 07:13, 15 June 2018 (UTC)

Ping Fish and Karate, on behalf of Fram's failed ping.
I want to thank the closers for tackling this beast of an RFC. But if I may nitpick one line, I too find it poor to cite a figure of 31 out of 94 people. It seems to suggest less than 1/3 really opposed using wikidata. I (softly) object that *I* was excluded from that 31 count. I think a count of 1A-or-equivalent !votes would have been more correct.
Tallying counts can be a bit variable in regard to some debatable edge cases, but my personal tally is 44 wanting wikidata removed, 3 wanting wikidata rolled back to experimental use only, and 46 wanting some level of real wikidata use. That's 47% wanting wikidata removed (44/93), and a majority if you include those who want wikidata rolled back to experimental (47/93). If any of the closers are willing, I'd be extremely interested to compare my tally-calculation to yours. I bet there are differences in opposite directions partially cancelling out. Alsee (talk) 14:14, 15 June 2018 (UTC)
There is a consensus that data drawn for Wikidata might be acceptable for use in Wikipedia - might be acceptable, might not be. if Wikipedians can be assured that the data is accurate, and preferably meets Wikipedia rules of reliability- big if. For the other issues raised within this RfC, there was no clear consensus - complete waste of time in other words, didn't decide a thing, what a surprise.Smeat75 (talk) 16:06, 15 June 2018 (UTC)
  1. I am responsible for the tally. One challenge I faced with tallying up the votes is that many people voted for two or more options on a line, say 3A & 3F; one participant split his vote amongst three possible categories! I felt the best way to allocate the intent of people who split their preference amongst multiple options was to split their vote accordingly. (I should note this was what Mike Peel decided to do too in his tally, independently of me.) If someone else tallying the vote did not split up the votes as we had, they might end up with a different number. (For the record, I also counted 5 people who either voted for 1A alone, or for 1A & 2A. I did not include them in my total.)
  2. To repeat Wikipedia policy, RfC are not closed & a consensus reached based by a vote (or !vote, as some refer to them) total but on strength of arguments. Counting these votes can sometimes provide a shortcut to determining a consensus -- especially in a snowball case -- but should never be relied on alone. So it's not important if the number of people voting "1A 2A 3A 4A" were 31 or 36 or 42. What is important is that a significant portion of the total voted this way. And if it is a good thing for Wikidata content to be used in Wikipedia infoboxes, these are the people who must be convinced it is a good idea. That was my point in mentioning this group in my closing; perhaps I needed to be more explicit.
  3. Further, conclusions based on counting votes need to be supported by what is said in the larger discussion. This is what I tried to do. To say a majority of participants were concerned about the reliability of Wikidata content is admittedly a controversial conclusion, so I supported it by drawing on my reading of the discussion section. Time & again I read complaints about the reliability of the material in Wikidata, not about Wikidata itself -- although a few did complain about its unintuitive interface. Any reasonable person who read that section would conclude that the primary complaint about Wikidata was about the reliability of its content. It would not be improper to then deduce were these concerns addressed, opposition to importing data from it might be lessened.
  4. One point that I wanted to emphasize in the closing is that despite being another Wikimedia project, that project has different goals & policies from Wikipedia. Both want to have accurate & reliable information: Wikipedia is presenting it in the format of an encyclopedia; Wikidata in the format of a database. In many cases, both projects would benefit from working with each other. (Which means each community not only needs to talk to the other, but also listen.) And when working together, there will be friction between the two communities. Consider the chronic friction between Wikipedia & Commons. However, both projects can achieve success without interacting in the way infoboxes would require them to. Both Wikisource & Wiktionary do quite well apart from Wikipedia. (Wikiversity might also, but I've had no real experience with that project.)
  5. What my last point means applies to the consensus I found in the discussion: everyone can agree that if the information on Wikidata is not what the community & policy defines as reliable, then we shouldn't use it. If we ignore the issue that Wikidata is another Wikimedia project, & consider this as an issue whether it is a reliable source, then there would be far less contention over this issue. The barrier to adoption is lower in this case because data can be easily transcluded over -- although while I was working on closing this RfC, people reported issues with this transclusion -- but this concern is paramount. If we can't use Wikidata to our advantage, then we shouldn't use it. Plain & simple. However, we won't know if we can unless someone tries.
  6. One person concluded that this RfC was a waste of time. I obviously disagree. Remember that this RfC was not a contest or a battle, but was supposed to be a discussion. I think all parties would benefit from reading what was written once again, & thinking about what other people wrote. This RfC defined one group who wants to experiment with importing & manipulating content from Wikidata, in hope they can do something useful with it; I didn't see anyone explain how that would be harmful to Wikipedia. (And when one uses the word "experiment", that implies also establishing metrics to determine success or failure.) This RfC also defined another group who are skeptical about Wikidata; they need to be convinced this would be an improvement. Both groups need to figure out how to live with each other while this is happening. Otherwise, this whole matter will drag out like countless other tempests in tea cups that have rumbled endlessly on Wikipedia over the last 15+ years. -- llywrch (talk) 18:23, 15 June 2018 (UTC)

Template:Ping:Llywrch. A couple of (belated) replies.

"(For the record, I also counted 5 people who either voted for 1A alone, or for 1A & 2A. I did not include them in my total.)" Why? There were four different questions, with four possible consensuses. But when people voted either 1A or 1A and 2A, there was no need to vote for 3 and 4 any longer (and looking at the close, it would have been wiser if I hadn't voted for 3 and 4 either). You claim "These 31 Wikipedians (out of the 94 people who participated in the poll part of this RfC) in effect opposed to any use of Wikidata data in infoboxes", but at the very least the 5 people who voted for 1A or 1A and 2A clearly also opposed any use of Wikidata. Basically, your close starts with a wrong count or a wrong interpretation of what people voted for, which gives very little confidence for the remainder of your close.
" So it's not important if the number of people voting "1A 2A 3A 4A" were 31 or 36 or 42. " but still it was important enough to include the lowest possible number into your close. Even worse, you dump all others into the "more numerous" group "willing to consider using Wikidata".
"Time & again I read complaints about the reliability of the material in Wikidata, not about Wikidata itself -- although a few did complain about its unintuitive interface. Any reasonable person who read that section would conclude that the primary complaint about Wikidata was about the reliability of its content. It would not be improper to then deduce were these concerns addressed, opposition to importing data from it might be lessened." The RfC was not about Wikidata, its unintuitive (or horrible) interface, its problematic userbase, its poor policies and application of them (BLP, notability, ...). These complaints were not raised because they are not relevant for the questions asked. To deduce anything from the lack of such complaints about how people feel in general about Wikidata shows a misunderstanding of the purpose and working of the RfC. Furthermore, addressing the reliability issues is hardly possible, since Wikidata is a separate project with separate policies and goals, and they are not bound by our reliability rules (or vice versa).
"However, we won't know if we can unless someone tries." Which we have been doing for 5 years now, since the first RfC.
" This RfC defined one group who wants to experiment with importing & manipulating content from Wikidata, in hope they can do something useful with it; I didn't see anyone explain how that would be harmful to Wikipedia. " No, one group wants to go all out and implement Wikidata-based infoboxes wherever possible. And if you didn't see anyone explain how these things can be and have been harmful to Wikipedia, then you haven't read the same RfC, nor any of the discussions around it. We already have had one Wikidata-based infobox (world heritage sites) which made enwiki so much worse that it was decided to go back to a non-Wikidata infobox, which is now (months later) nearly finished. Such experiments have been going on all over the place, and countless hours have been spent in undoing the damage they have caused (immediately, and afterwards when someone vandalizes Wikidata and the vandalism remains here for days). If you want an example of the kind of damage Wikidata-based infoboxes can do, see e.g. Omar bin Laden. Wikidata description "one of the sons of Almirante General Aladeen" (luckily we have removed the Wikidata description from most enwiki uses and are in the process of eliminating it completely). Wikidata doesn't have the item "Omar Bin Laden", they have, since 10 June, the item Mauricio McCree. And sure enough, 6 Wikipedia languages[2][3][4][5][6][7] now claim since 10 days that one living son of Osama bin Laden is called Mauricio McCree...
"Both groups need to figure out how to live with each other while this is happening. " Indefinitely? The "experiment" has been going on for 5 years, and the results are not remarkably better now than they were then. A have a few days ago checked a dozen pages which had the Wikidata version of the infobox person, and removed it from 4 of them because that infobox gave clearly worse results than the local one. This "experiment" is actively harming enwiki. Fram (talk) 13:45, 20 June 2018 (UTC)

I really need to learn how to ping: @Llywrch:. Fram (talk) 13:46, 20 June 2018 (UTC)

  • I don't understand the close at all but, fair enough, much of the RfC became too complex for me to follow also. I'll just remove it on sight, every time, until WikiData gets its house in order. Sue me. - Sitush (talk) 14:01, 20 June 2018 (UTC)

See Also

There is an issue with wikipedia policies related to "See Also" sections. In [8], it is mentioned "As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes.", and, some contributors tend to take it literally for the time. According to my knowledge "See also" is designed for cross-referencing (e.g., refer: [9]). Shall we modify the policy to imply it is not enforced in such a way?(Note [the sentences in the policy]: "The links in the "See also" section might be only indirectly related to the topic of the article because one purpose of "See also" links is to enable readers to explore tangentially related topics." and "As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes." are contradicting each other too.) Thanks. Shevonsilva (talk) 23:06, 13 June 2018 (UTC)

Short of some further explanation from you, @Shevonsilva:Shevonsilva, i see no contradiction at all between the two portions of the MOS you quote; the See also section is there to allow further exploration, frequently tangential, and since some potential areas for further exploration are already wlinked in the article there is no need for them in the See also. No contradiction. (Further, though perhaps being picky here, i don't understand why you link to a twenty-year-ld Master's thesis about a library in an Ohio county library; we go by our own style and methods here.) Indeed, i do, on occasion, remove wlinks from See also sections, sometimes even the entire section, if they are already in the article; that is simply following the MOS. Happy days, LindsayHello 09:58, 14 June 2018 (UTC)
Thanks. Kindly refer ""See also" may be used to introduce a case supporting the stated proposition which is distinguishable from previously-cited cases." in Citation_signal#See_also. There can be occations where different case is presented throught page which is already hyperlinked to a wikipage in very lengthy article. "See Also" may guide the use to go for the broader or different case which only wlinked in a long article but case is not handled in that article. Otherwise, we are telling the reader click all wlinks (may be 100 links) in the articles.
"to enable readers to explore tangentially related topics" is ment to be enabling related topics (which can be a related topic which is addressed with a different specific case; but, still related to the article in an overway. And, in the other hand by telling "should not repeat links", we are effectively restricting the user from accessing previously mentioned cases by imposing the word "should" there. It is mentioned as "a general rule", it mean may have over 50 percent of cases as I believe.
Better to express it as follows: "Occationally, the "See also" section should not repeat links that appear in the article's body or its navigation boxes. I belive we have to change that guildline. I got a case: some contributors tend use it as a should have rule for everywhere (believing "As a general rule" = should) even thought it break the flow of information an author reality wants to present. Shevonsilva (talk) 17:50, 14 June 2018 (UTC)
But "Occasionally" (which is what I think you mean) is not at all our standard. "See also" sections should usually not repeat a link that already appears in the body of the article. In a longer comment below, I give some examples of when we sometimes depart from this norm.  — SMcCandlish ¢ 😼  01:21, 15 June 2018 (UTC)
I agree with “If it is cited elsewhere in the article, don’t put it in the ‘see also’ section”. The reason is this: The “see also” section is for sources that the reader should ALSO see (in addition to the ones we already tell them to see, which have appeared elsewhere in the article). There is a reason we use “see ALSO” and not simply “SEE”. Blueboar (talk) 21:31, 14 June 2018 (UTC)
But, the "See also" section isn't for sources at all; I suspect you're thinking of the "Further reading" section. MOS:LAYOUT has the details on what these sections are, what order they go in, and what they contain.  — SMcCandlish ¢ 😼  01:22, 15 June 2018 (UTC)
  • It's typical to integrate "See also" items into the main prose and remove them from "See also", when practical; that same MoS page advises this (but it is not a policy, and even if it were, policies are not laws – WP:IAR applies if a divergence would actually improve the encyclopedia). Sometimes an already-used-in-prose item will also appear in the "See also" section intentionally, especially if it was WP:Piped link in the main prose, or if it's an important WP:SPINOFF article and we expect that readers will want an easy quick-reference way to find it. That is, if a reader would be confused into thinking we're missing the article in question if we don't have it in the "See also", it's better to list it there. We don't have a "rule" about that; it's just a common sense matter. It's basically the same as having links to the same side article in the infobox or in a navbox; it's perfectly fine to have multiple forms of navigation to the same article. A good example of an article type often given this "extra 'See also'" treatment is a "List of Foos" article being listed as a "See also" in the "Foo" article. Another common case is "Xography of Foo" (discography, bibliography, etc.), and "List of Foo episodes". We want to get readers to the content they are most likely to be looking for (this is also the purpose of disambiguation pages, and the approximation attempts of our search system, and various other site features). But we also don't want enormous and redundant "See also" sections, so peripherally related subjects should not appear there if already integrated into the main article text. Another great reason to remove one is if an article is already using {{Main}} to point to one from a WP:SUMMARY section.  — SMcCandlish ¢ 😼  01:19, 15 June 2018 (UTC)
Thanks. Exactly what I meant too. For example, in the article Doutsila (department) (note: naming standerd is still under discussion), I am happy to include Departments of Gabon under See Also, in order to give extensive coverage for the user, as, there is no direct wordly phrase for Departments of Gabon, and, as that is only a wlink for the word "Department", otherwise, we are expecting the reader to click all the wlinks and understand to which article those are linked as wording in the articles are differed from the titles in the wlinks (and, the other point is if we go for a bigger article, we cannot expect reader to remember all the wording with wlinks at the end). That is exactly my point. The problem here is the phrase, As a general rule, in the policy is taken as "always should" by some contributors. We might have to find a way to get rid of this impression. Thanks. Wow, you are also nonfiction author, that is great. :) Shevonsilva (talk) 17:11, 15 June 2018 (UTC)
Kindly refer my above comment in the discussion. Thanks. Shevonsilva (talk) 17:11, 15 June 2018 (UTC)

Banned users, sock puppets etc

Is there a policy which says that editing proposals by banned users, sock puppets etc should be abandoned? I have heard this asserted many times, but I don't know if it is official. If so, is it retrospective? For example, if an RfC was found to be influenced by sock puppets, would it be overturned???--Jack Upland (talk) 09:36, 14 June 2018 (UTC)

The cleanest thing is to delete content created and edited entirely by the banned user(s). Where that's not possible, there is no one-size-fits-all guidance from policy. The closest would be this essay: Wikipedia:Dealing with sock puppets. Basically you have to take it on a case-by-case basis. It's totally appropriate in an AFD or talk page discussion to strike from discussion everything that came from the banned editor. If this leaves the entire discussion so fragmented or tiny as to be incomprehensible, it may be worth just closing it out and then starting over, or just pretending it never happened. But if a banned editor started something that has taken on a life of its own, there is not generally a reason to shut down discussion. Someguy1221 (talk) 09:48, 14 June 2018 (UTC)
If you catch an RFC/AFD/talkpage-section/other before it gets any meaningful support, then revert/collapse/close or otherwise nuke it immediately. If legitimate editors have begun supporting or discussing the issue in a potentially constructive manner, then do your best to strike or otherwise neutralize the problem-individual without disrespecting the legitimate users. If only one legitimate user would be affected, you might still be able to shut it down with an explicit note that they may start a fresh discussion if they wish.
A closed RFC could be challenged and potentially overturned if the closer was unaware of socks which may have affected the outcome. Note that the first step should always be to try to discuss any concerns with the closer. Try to assume there's a better than 50% chance that you and the closer can reach an agreeable resolution. Alsee (talk) 02:36, 15 June 2018 (UTC)
Thanks for that. I guess the other question I have is what if the user is banned subsequently. Is this at all relevant?--Jack Upland (talk) 04:29, 16 June 2018 (UTC)
Jack Upland it's getting difficult to answer without a specific case to look at. I'll try to make some general points. If you look at old RFCs, it's not unusual to find one or more participants eventually got banned for some reason or another. We don't go back and redo all of those discussions. It's also usually not significant if the original proposal-author was the one who got banned. That does not delegitimize the other participants in the discussion. If someone was banned during an RFC, or immediately after for behavior directly related to the RFC, there's a more credible case for concern. But it's generally an overreach to suggest that they single-handedly reversed the outcome, unless there are some pretty extraordinary circumstances. And regardless of anyone getting banned or not, it's always possible that Consensus Can Change over time. A future discussion might reach a different outcome because new facts or arguments arise, or because views shift. However repeating discussions can be costly in other people's time, and even disruptive. At least a few months should go by before trying to re-start a closed topic, unless critical new facts arise or there's some similar strong justification. (Merely disagreeing with the original result isn't a good reason, chuckle.) Alsee (talk) 08:31, 17 June 2018 (UTC)
Thanks. I wasn't referring to any particular live discussion, but just wanted to clarify the situation because of a number of comments that other editors have made at various times. Thanks again.--Jack Upland (talk) 08:48, 17 June 2018 (UTC)

MoS section merge discussion

FYI: Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Biographies#Merge MOS:JOBTITLES to this MoS page.

The proposal is to merge WP:Manual of Style/Capital letters#Titles of people (a.k.a. MOS:JOBTITLES) to WP:Manual of Style/Biographies, where the rest of the material about human titles is (academic, post-nominal, honorific, regnal, etc.). A short summary and hatnote pointer would be left behind in MOS:CAPS (about the same as those presently at found at MOS:CAPS#Occupational titles pointing to MOS:CAPS#Titles of people; the relationship would simply be reversed).  — SMcCandlish ¢ 😼  01:08, 15 June 2018 (UTC)

Nationality of television series

The current consensus of the TV wikiproject is that the nationality of a tv series is identified from the production companies listed in its credits, next establishing the nationality of each from reliable sources, and then determining sole or multi-nationality for the series accordingly. There is a proposal to replace this with referencing of sole or multi-nationality directly from reliable sources. You are invited to participate in the discussion at Wikipedia talk:Manual of Style/Television#Proposed MoS change: Nationality MapReader (talk) 19:23, 15 June 2018 (UTC)

The problem of faux neutrality and bias in Wikipedia

This discussion is not really going anywhere, if you want to discuss separate articles and their neutrality then this isn't the place to do so. It would help more if the OP makes a proposal on what to do rather than rant about it. - Knowledgekid87 (talk) 17:29, 19 June 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

It's pretty much undeniable that when it comes to politically charged subjects, there's a great amount of bias in Wikipedia, and this bias tends to be pretty much exclusively heavily left-leaning.

If you want to know how biased an article is, it's usually enough to read the lede of the article. The more biased, especially when it comes to controversial political subjects and people, the article is, the longer the lede will tend to be, and the more stock full of detail and minutia it will be, even though such minutia doesn't belong to a short summary. All this minutia will invariably exist there to paint a certain picture of the subject or the person in question. Most of these details are something that non-controversial articles usually don't have. In the case of the most controversial people and subjects, the lede will essentially be a full-on no-holds-barred attack against that person or subject. And this is pretty much always from an extremist leftist perspective.

As an example, the lede for the article on Milo Yiannopoulos (as of writing this comment) is very long. Its very short first paragraph would be more than enough for the purpose of a short summary. However, it's followed by not one, not two, but three massively long paragraphs, all of which are pretty much in essence a character assassination of this person. For example, the last, excessively long paragraph, is dedicated in its entirety to some paedophilia accusations, as if this were at all something that belongs to the lede of an article. It's quite clear that this entire paragraph, as well as the previous two, exists solely as a character assassination, and shows a clear agenda. This article, starting from its very lede, is heavily biased and lacks neutrality. Anybody who denies this is either delusional or deliberately lying.

Or take, for example, the article on "incel". Again, the lede is excessively long, and a full-on no-holds-barred assault on these people. The lede feels the need to mention, among other minutia, that these people are "mostly white, male and heterosexual". Why does the editor of this article feel the need to bring up, for example, race? What does race have anything to do with anything? Why is it so important to mention in the lede of the article? (It's quite telling that for long this claim had a whopping nine citations shoved into it. Quite clearly the writer really felt the need to justify it by shoving as many citations as he or she could find.) Specifically mentioning "white, male and heterosexual" in the lede is quite clearly pushing a certain socio-political agenda. Anybody who denies this is either delusional or deliberately lying. Anybody who is even slightly intellectually honest will admit that there is a political message being shoved in there. Such minutia doesn't belong in the lede of the article (if anywhere at all), and serves only the purpose of giving a certain picture to the reader, to push an agenda.

And oh boy, do I even need to mention the gamergate controversy article? It's arguably the most biased article in the entirety of wikipedia. It's so biased that it's just ridiculous. It's so bad that it reaches conservapedia levels. I could write an entire book about it, but let me just give one illustrative example: The word "harass" or "harassment" appears in the article a whopping 130 times. There is one paragraph where that word appears a whopping 11 times. In one single paragraph! It appears 8 times in the lede alone. This word alone appears in the article more times than some articles have words in total! This is not an article. It's essentially a conservapedia-style list of bullet points that has been collected as a resource to attack the movement, just formatted a bit more nicely to give the false illusion of it being an actual encyclopedic article. If that word appears that many times in the article, it's not an article. It's a propaganda piece, plain and simple. A normal encyclopedic article wouldn't need to repeat that word that many times. Anybody who denies this is either delusional or deliberately lying.

Which brings me to the subject of faux neutrality: All of these articles are masqueraded as being "neutral", and "sourced", some more cleverly than others. The problem is that in most cases this is just faux neutrality. It's giving the outwards appearance of "neutrality", of giving tons of "sources", but in reality it's just hiding the inherent bias. In most cases, with these articles, there's a selection bias of external sources: Only those sources are cited that affirm the message being conveyed. Almost invariably these citations refer to external sources that are themselves extremely biased (sometimes famously so). Giving the outwards impression of being "well-sourced", "unbiased" and "neutral" is deceptive when those external sources have been carefully selected, and are themselves extremely biased. Even when in a few cases a source is cited that gives an alternative perspective or opinion, it will be cited in a context that reduces its credibility (such as saying something like "source A objects to this notion arguing it to be false, but sources B, C, D, E, F and G refute this." The dissenting source is seldom let speak for itself, and will almost always be immediately countered instead, often with a flood of (biased, of course) other sources, giving the impression that the dissenting opinion is in an overwhelming minority.)

Is there a solution to this bias problem in Wikipedia? Probably not. Wikipedia is mob-controlled. As Wikipedia itself puts it, it has no central authority that would oversee the articles and remove any bias or agenda. Basically, whichever political mob is more numerous and holds more keys to the locks, rules Wikipedia, and is pretty much free to push its agenda, masquerading it as "neutral". This is quite a problem because way too many people, including very influential people (eg. those making decisions on laws), take Wikipedia way too seriously. Wikipedia has way too much influence on society, and thus political agendas being pushed by Wikipedia have a big potential to influence people. And there's pretty much nothing that can be done about it. As said, the largest mob controls the narrative.

Expecting this post to be locked. Perhaps even removed. Because that's how the mob works. It doesn't like being criticized.

Wopr (talk) 08:40, 17 June 2018 (UTC)

"this bias tends to be pretty much exclusively heavily left-leaning." Wikipedia reflects reality, and reality has a well-known liberal bias. --Golbez (talk) 17:49, 18 June 2018 (UTC)
So that means, per WP:BIAS, if we recognize that systematic bias exists, we should try to reduce that bias, right? --Masem (t) 19:05, 18 June 2018 (UTC)
Reality having a bias is not a systemic bias to fight. It is a fact to accept. --Golbez (talk) 02:08, 19 June 2018 (UTC)
It's not a "liberal bias". Liberalism has nothing to do with it. It's a "progressive intersectional feminist" bias. The kind that abuses Wikipedia to make it a platform to attack and character-assassinate people and movements with the "wrong" opinions from their perspective, while people and movements that the intersectional feminists approve of do not get such a treatment. With some articles this bias is so glaring and so obvious that it's outright ridiculous. Even conservapedia doesn't have that much bias. Wopr (talk) 14:31, 19 June 2018 (UTC)
Uh huh. You realize your abrasive tactics are not going to be effective, right? So you obviously have no interest in changing things here, just bitching at us for a little while and then maybe disappearing for another decade, to again fight against the evils of... checks notes... intersectionality. hm. --Golbez (talk) 15:58, 19 June 2018 (UTC)
Of course nothing is going to change. I said as much in my original post. I quote: "Is there a solution to this bias problem in Wikipedia? Probably not." The fact is that articles on politically charged topics on Wikipedia are highly biased, Wikipedia has no neutral central authority and is instead mob-ruled, and the most numerous mob controls the narrative. And this mob is regressive leftist. Why would anything change? The fact nothing is going to change has been quite clear for years and years: People have tried to bring more neutrality and less bias to many of those politically charged pages, to no avail. Their edits have always been reverted, and the biased narrative has been restored, and only made worse. Unfortunately these people are the minority, and the political zealots happen to be the majority, so they have essentially no chance. Wikipedia, by the nature of being mob-ruled, is a political mouthpiece and propaganda platform, no more, no less. The people who have hogged the megaphones are controlling the narrative. And when people point that out, they are just met with ridicule. Wopr (talk) 17:10, 19 June 2018 (UTC)
A systematic bias is specifically a bias of the nature of the reality. We know there's tons more Western media sources available compared to nearly any other region, which obviously leads to more Western topics being covered. So per BIAS, we have to make sure that we don't dismiss non-Western topics because they aren't in Western sources (rather than restrict the other way from Western sources). The problem in the current question is where these biases are coming from, because I will argue there are at least four different biases at work that unfortunately all create a feedback loop that worsens the bias: The normal left-bias of the press, the current bias due to Trump as president (who is, unquestionably, a divisive figure), the bias that the right media has that causes many of their sources to be discounted under our RS policy, and the bias of the editor composition here on WP (which I would personally argue in that the more vocal and established editors on controversial topics like Milo are left-leaning/liberal, whereas the newer editors to these are right-leaning/conservative). Untangling those and figuring out how to remedy those systematic biases is not an easy task but it is one we need to be thinking about and answering. What I've found though is too many "sweep it under the rug" comments, including in this discussion, without any attempt to analyze the problem in the long-term. --Masem (t) 16:09, 19 June 2018 (UTC)
A lot of this relates to WP:Recentism. As long as a person or topic is “in the news” it is difficult to write balanced articles. Editors have a difficulty summarizing information (and presenting the information with a historical tone). Since they can’t summarize, they tend to write overly-detailed articles.
I have found that the solution to this is to have patience, and to take a long term approach. If you find an article on someone/something that is currently “in the news”... and thus overly-detailed... WAIT. Go back to the article after a few years have passed, and rewrite it. At that point we have a better understanding of what is really relevant and what isn’t... and the passions of our own POVs have faded. Blueboar (talk) 13:15, 17 June 2018 (UTC)
Recognizing that some of the above articles have been extreme hotbeds of problematic behavior, the recentism issue is absolutely right, but that also leads into the fact that citogenesis happens. I know that our GG article has been used as a source in other supposed reliable sources to describe the situation, for example. That's the start of circular reporting and creating an echo chamber when we don't consider the larger picture of issues. We need a much better solution particularly on topics that are routine the subject of "character assassination" by the media at large, whether or not those topics actually merit that. The less we include when these cases happen, the better. --Masem (t) 13:37, 17 June 2018 (UTC)
There is indeed a bias on Wikipedia. To my personal opinion, there is a strong USA-centric bias whereby the notability guidelines work favourably of USA-subjects. Another form of bias is the fact that projects can in fact overrule the community-set notability guidelines. The Banner talk 13:24, 17 June 2018 (UTC)
I wonder if the OP can provide instances of articles "biased" for conservative elements to support his point, or whether this is just the tired "Wikipedia is liberally biased" argument with a different skin. --Izno (talk) 13:39, 17 June 2018 (UTC)
The OP's point about "character assassination" is a rather novel issue which I have found to be far too true. Editors want to include anything RS present as a negative against a person (an accusation, a label, etc.); its just going to happen on conservative topics given that the bulk of RSes that would be acceptable for this are on the left. We shouldn't be actively seeking out recent "character assassination" material to stuff in articles, as an encyclopedia, unless it actually becomes key to that topic's notability. Someone might spout racist statements, and the media will jump on that, but until that actually turns into something that creates action in the real world (such as being kick off their job, or being convicted), we should be very caution about including that, even though it can be sourced to RSes. This is very easy to do towards conservative targets from left-leaning media, and given that as an academic work, editors on WP average as liberals, it compounds the problem. --Masem (t) 13:47, 17 June 2018 (UTC)
I don't know if there are any Wikipedia articles that are biased for "conservative elements". I'm not exactly sure why you are even asking this. The most important point is that an encyclopedia shouldn't have any bias at all! The fact that most (if not all) of the bias is towards extremist leftism makes it only worse. There are way too many articles which are clearly biased to favor one political position and/or to paint another political position in a bad light, and it looks to me that the bias is pretty much invariably towards favoring extreme leftism (not even liberalism, but leftism, which isn't the same thing) and against concepts, ideas, phenomena or people who are more "right-wing" or "conservative" (or even "centrists" who are critical of the extreme left.) An encyclopedia shouldn't take stances, and shouldn't have biases. Wopr (talk) 15:58, 18 June 2018 (UTC)
Well, actually this encyclopedia is supposed to be biased in favour of mainstream viewpoints, see WP:NPOV. Mainstreamness as measured by the amount of reliable sources that discuss a topic, that is, not a popularity count. Jo-Jo Eumerus (talk, contributions) 16:06, 18 June 2018 (UTC)
I said something similar to the OP at Talk:Incel: "Is your argument, saying what sources say is bias? Perhaps, but it's not bias as how it is usually defined, which is saying what sources don't say, or ignoring what sources do say because you don't like it. As for your claim that using those words is bias -- they are words, which you seem to have a bias against but that does not mean we would not use them, as the sources do, and not according to your anti-word bias." What we have it appears here is a person who want's to say, 'don't talk about that', regardless of sources - so, their 'don't talk about it', suggests they have bias and an agenda. Alanscottwalker (talk) 16:18, 18 June 2018 (UTC)
Except that as Blueboar notes, we need to avoid recentism. We should be write to a viewpoint that is likely going to stand the test of time. Political goalposts shift, broad moral change. What's the view of mainstream today will not reflect what it will be years down the road. The insistance of many editors to force things like character assassinations repeated ad nasuem by sources now is not going necessarily going to be appropriate in 5 years. Hence why we should be much more middle-ground conservative and avoid giving so much weight to these things now. I know the Lewinsky stuff with Clinton is being used as an example, and actually what we have there for that makes sense - it was a major issue with the Clinton adminstration, but it ended up doing little much, so we don't go excessively overboard with it now, in hindsight. But too many editors want to avoid waiting for hindsight to give the right answer for how to approach current topics. --Masem (t) 17:20, 18 June 2018 (UTC)

The last paragraph of Yiannopoulos's article lead is about the very public affair which led to his departure from Breitbart, and the cancellation of his book deal, over which there was a lawsuit (since dropped). As WP:LEAD says, The lead should stand on its own as a concise overview of the article's topic. It should identify the topic, establish context, explain why the topic is notable, and summarize the most important points, including any prominent controversies. To leave it out would be as if the Monica Lewinsky affair was left out of Bill Clinton's lead.

One can argue about the phrasing and emphasis, sure. But to say that it doesn't belong in the lead at all is a bit of a stretch. Kingsindian   14:04, 17 June 2018 (UTC)

I have to agree. The OP does not get the introduction - if anything our intro's in general need much attention, actually completing them by writing more -- they are simply, WP:UNFINISHED. Alanscottwalker (talk) 16:06, 18 June 2018 (UTC)
Notice how Clinton's impeachment mention is only a couple of sentences in the paragraph, and Lewinsky is only mentioned very briefly and in passing as the reason for the impeachment. The rest of the paragraph has nothing to do with any of this. This is very much unlike the mentioned paragraph in the Yiannopoulos page, which goes to completely unnecessary amount of detail, and delves on it way more than would be necessary. The difference is quite clear: The Clinton lede is not a character assassination, while the Yiannopoulous one is. This is exactly what I'm talking about. It's clearly agenda-driven, and completely faux neutrality. You can deny there being a political agenda in the article all you like, but that doesn't change the fact. And, as some here have commented, they want more character assassination in article leads, rather than less. Wikipedia as a "neutral" encyclopedia is a complete joke. Wopr (talk) 16:58, 18 June 2018 (UTC)

There is no Wikipedia policy that articles need to be objectively neutral. They only need to written from neutral POV while giving due WEIGHT to the reliable sources (with lots of special rules like PRIMARY, BLP, NOTE etc). It is the job of editors to pick sources, to have editorial oversight (or "bias"). As such I think complaining that Wikipedia is not objectively neutral is like calling a horse a pig - it never was so. -- GreenC 17:45, 18 June 2018 (UTC)

The problem is with "reliable". There is no agreed definition. HiLo48 (talk) 20:58, 18 June 2018 (UTC)
It's a continuum of reliability with academic on one side and Daily Mail on the other. It's often context-sensitive as to what fact is being cited. WP:RS discusses. In the end if there is dispute Wikipedia is consensus-based. -- GreenC 21:22, 18 June 2018 (UTC)
Positing academia as the be-all end-all of reliability is also problematic and can lead to the reproduction of biases within academia. That having been said, such biases are usually along the lines of America- and euro-centric chauvinism toward other societies, which would make the bias right-leaning (although the left/right dichotomy doesn't really adequately describe this dynamic: a more accurate portrayal would be to say that there is a bias toward Liberal viewpoints as enshrined in Western academic tradition, over those of other intellectual traditions both to the right and to the left). OP's impression that Wikipedia's bias is "leftist" is a rather ironic byproduct of their own bias that conforms to the Overton window of right-wing American popular discourse.Rosguill (talk) 22:21, 18 June 2018 (UTC)
I always wonder what discussions like this one hope to accomplish, aside from providing some stimulating intellectual conversation. There is not going to be a consensus that Wikipedia has a serious bias problem one way or the other, since consensus is determined by the very same editors who you claim are responsible for bias in the encyclopedia. Even if there were such a consensus, what could we do about it, exactly? There is no higher Neutrality Court at Wikipedia, nor would one be an improvement because it would have its own bias (never mind that its backlog would be measured in years). Bias is human nature, editors who recognize their own biases and make concerted efforts to compensate for them comprise a small minority, and that will forever be true. Policy is unavoidably vague and subject to interpretation, and Wikipedia is edited by ordinary people, not philosophers and ethicists. Write an essay about Wikipedia left-bias and it will be generally supported by right-leaning editors and generally rejected by left-leaning editors. ―Mandruss  00:22, 19 June 2018 (UTC)
@Wopr: To be clear... you're unhappy that the statement about race in the lead of Incel was... too well cited? (For transparency, I created that article and wrote a fairly large chunk of it.) GorillaWarfare (talk) 01:42, 19 June 2018 (UTC)
No. The amount of citations was not the problem, just a symptom. Clearly you felt the need to overly justify your completely unnecessary "white heterosexual male" statement, which exists there solely to push a certain political view and agenda. It's quite clear that you knew perfectly well how controversial, politically charged, biased and "baiting" such a statement in such an article is, and thus you overcompensated that controversiality with a citation flood, trying to give it as much credibility as you could. You know perfectly well how politically charged and biased listing those particular characteristics is on this day and age, and you clearly tried to justify it with a citation flood. In other words, you have a political bias and agenda. Don't even try to deny it. This is the fundamental problem I am seeing in Wikipedia with politically charged and controversial subjects. Bias and agenda-pushing. Wopr (talk) 11:18, 19 June 2018 (UTC)
The claim was repeatedly challenged on the incel talk page by folks such as yourself, who tended to fall into one of three categories: those who said it was incorrect, those who said it was given undue weight in proportion to how often it was mentioned in reliable sourcing, and those who didn't like that it was mentioned. I don't believe the folks in the first group were ever able to provide any reliable sources that discussed the demographics of incel communities as anything other than primarily white/heterosexual/male. Some sources were produced that discuss the existence of non-white/non-heterosexual/non-male incels, but the folks offering up those sources seemed to misunderstand the statement as implying that all incels are straight white men, not that people meeting some or all of those descriptors make up the majority of the communities. As for those in the second group who argued it was not widely mentioned in reliable sourcing, the impetus was less on them to produce evidence, since one can't really prove that negative. Hence why myself and other editors added additional sourcing to show that it is mentioned quite often. As for the third group, well, Wikipedia:I just don't like it.
I understand that you disagree with its inclusion in the lead, but it seems you might be unfamiliar with how these subjects are handled on Wikipedia. The fact that more citations were used for that claim was an artifact of resolving conversations about whether it should be included in the lead—though I do agree with those on the talk page who felt the list of inline notes had grown too long and decided to pare it down.
This particular tangent is perhaps getting a bit long for discussion on the village pump and might be better held over at Talk:Incel, although I will suggest reading WP:TALKNO if you do decide to move it over. I believe your comments have been removed from that page at least once because they were descending into soapboxing about "mob rule" and bias on Wikipedia in general. Your input on how to improve the article is welcome there, but please try to provide sourcing and policy-based reasoning for your suggestions. You might also do well to avoid accusatory statements like "clearly you felt the need...", "you knew perfectly well...", and "don't even try to deny it", but that's your prerogative within the bounds of WP:CIVIL. GorillaWarfare (talk) 16:16, 19 June 2018 (UTC)
As for that last part, are you seriously claiming that you do not consider inserting "white heterosexual male" in such a controversial subject to be politically charged and pushing a certain narrative, and that you did it in complete honesty without any sort of ulterior motives? Well, I suppose you could claim that, but you'll pardon me if I don't believe you. This might possibly be the only article in the entirety of Wikipedia where the race of the majority of the people being discussed is mentioned in the lede. As if race had any sort of significance or importance to the matter in question. Couple it with "heterosexual male", and the message is quite clear. Notice how much of your response you spent once again trying to justify the inclusion of those words. Also notice how much you object making that lede shorter and less politically charged and less agenda-driven. Possibly because of principle? You have a bias, whether you admit it or not. And that's the whole point of this post of mine: The inherent bias in Wikipedia on politically charged subjects. That article is one perfect example. Wopr (talk) 17:22, 19 June 2018 (UTC)
Wah wah. The consensus went against you, and you didn't get your way in an argument on Wikipedia. You're not even pointing to any diffs of so-called "bias" occurring, just blurting out deliberately inflammatory and argumentative prose with vague hints at a left-leaning bias. The fact you chose the "incel" and "Gamergate" articles to make your point speaks volumes. Let's all move on.--WaltCip (talk) 11:43, 19 June 2018 (UTC)
Politically charged or not, anyone writing a neutral and dispassionate article about incels would have to use the phase "white heterosexual male" at one point, because incels are mostly white, heterosexual, and male. That's an WP:NPOV description of incels, even if it triggers rage amongst those who are "anti-social justice/anti-progressive/anti-whatever you want to call it". Headbomb {t · c · p · b} 17:31, 19 June 2018 (UTC)
And the mob has spoken. While you are at it, why don't you just censor my post, or even remove it completely? Because that's how it works. And while you are still at it, why don't you add a few more instances of the word "harassment" to the gamergate article? I don't think it has enough of them. A couple dozen more should do for now. Wopr (talk) 14:24, 19 June 2018 (UTC)
The only thing more pathetic than nailing yourself to a cross is whining that someone else hasn't nailed you to a cross yet. No, that's not "how it works," obviously, since you are still here. (also, congrats WaltCip on becoming a mob!) --Golbez (talk) 16:00, 19 June 2018 (UTC)
Probably not a barnstar-worthy achievement to be sure, but nonetheless, I'll take delight in it, as I'm sure this person takes delight in being the alt-right martyr of the day.--WaltCip (talk) 17:10, 19 June 2018 (UTC)
I have to wonder exactly who you are trying to convince with the mockery and ridicule. The echo chamber, maybe? But please, by all means continue. You two keep patting yourselves in the back. Wopr (talk) 17:25, 19 June 2018 (UTC)

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

Proposal for closing the Simple English Wikipedia

There is currently a proposal on Meta for closing the Simple English Wikipedia at meta:Proposals for closing projects/Closure of Simple English Wikipedia (3). All are invited to participate. TonyBallioni (talk) 17:28, 19 June 2018 (UTC)

The US Wikipedia

Hi all, I've been recently explained that, when it comes to non-free content is only defined with regard to the copyright status in the US. I've been told that the "US Wikipedia" (sic) works in that way and, although I don't have a fundamental objection to that, I wonder where such a definition has been agreed on by the community and especially why it is not clearly stated in Wikipedia:Non-free content (with free content defined as content that does not bear copyright restrictions in the US on the right to redistribute, study, modify and improve, or otherwise use works for any purpose in any medium, even commercially). In the case we're discussing, a 1912 painting by Picasso, it's clearly copyrighted in it source jurisdiction although possibly free in the US. If the statements provided in Wikipedia:Media_copyright_questions are true, why aren't they clearly stated in Wikipedia:Non-free content. Thanks --Discasto (talk) 21:18, 19 June 2018 (UTC)

We have to obey US law because the Wikimedia Foundation and servers are based there. The community can choose to be more restrictive than required by US law, but not less. I'll let someone else answer the other aspects of your question. Dragons flight (talk) 21:24, 19 June 2018 (UTC)
meta:Legal/Legal Policies is a list of official legal policies of the Wikimedia Foundation. The section on compliance with state and national laws is, in a nutshell, exactly what Dragons flight just said. As an official foundation policy the community has no power to change it, but as mentioned by DF and the policy itself, a community is permitted to be more restrictive than required. Someguy1221 (talk) 21:31, 19 June 2018 (UTC)
A notable example is the Japanese Wikipedia, which requires content be legal under the laws of Japan, which means no fair use material. --Golbez (talk) 00:47, 20 June 2018 (UTC)
Not really an exception... Again, the minimum for copyright restriction is based on US laws (since that is where WMF is based)... but the various Language sub-projects can be MORE restrictive if they wish. Blueboar (talk) 11:46, 20 June 2018 (UTC)
Cool, because I said example, not exception. :) --Golbez (talk) 13:11, 20 June 2018 (UTC)
de-wiki, the second largest Wikipedia (I'm not counting sv-wiki and ceb-wiki because their numbers were artificially increased by bots), also conforms to German law despite the fact that it's not hosted there. Regards SoWhy 11:49, 20 June 2018 (UTC)
Note however that Commons does try to conform to the country where an image comes from as well even though it doesn't really have to. The images in Wikipedia therefore that may be problematic have to also follow fair use, it is a bit more strict than just following US law. God knows what will happen if the EU passes its law about checking uploaded content and paying for links - I guess that will be followed by the US at some stage as it is the sort of media company politicking that caused copyright terms to be so long. We really need another Mr Smith Goes to Washington to deal with the stupidity Dmcq (talk) 13:56, 20 June 2018 (UTC)
At least the US Supreme Court has ruled that "public domain in the United States" is irrevocable, even by Congress. Someguy1221 (talk) 21:51, 20 June 2018 (UTC)
In Golan v. Holder (2012) the US Supreme Court ruled that Congress has the power to extend copyright protections to works previously in the public domain. Hawkeye7 (discuss) 22:07, 20 June 2018 (UTC)
Dammit. Someguy1221 (talk) 22:57, 20 June 2018 (UTC)
With regards to English Wikipedia's policy as to non-US copyright, this is covered, in detail, at Wikipedia:Non-U.S. copyrights (this is the policy page just underneath "Non-free content" in the Wikipedia copyright sidebar). The second paragraph of the lead at that policy page says "While Wikipedia prefers content that is free anywhere in the world, it accepts content that is free in the United States even if it may be under copyright in some other countries." While most of the time whether or not a work is protected by copyright in the US is not dependent on whether or not it protected in its country of origin, due to the URAA the U.S. copyright status of a large number of non-U.S. works actually depends upon the laws of the country of origin for these works. See the aforementioned Wikipedia:Non-U.S. copyrights page for details. —RP88 (talk) 00:51, 21 June 2018 (UTC)

Rollback and article sanctions

I'm not sure if this has been discussed before, but if it hasn't, I'm hoping this is the correct place. As a vandal-fighter and rollbacker, it is not typical to manually edit or check the talk page of every page before making a revert (even more rare when using tools like Huggle or similar). If an article is under arbitration remedies, it's easy to be totally unaware, and make a revert that may breach the remedies with no knowledge of them. I'm therefore wondering if rollback should even be technically possible on a page that is under remedies that may limit or prohibit such use. Is it possible that rollback could be disabled, or at least prompt an "Are you sure?" type message on pages under remedies? Home Lander (talk) 19:35, 20 June 2018 (UTC)

The 5 standard reasons for using rollback are exempt from these Arbitration remedies. When you're unsure whether the rollbacking of a particular edit is justifiable with these reasons or not "...use another method of reversion and supply an edit summary to explain your reasoning.".
If you want rollback to prompt Are you sure? dialog (for You), there's a script that can do that. Am I missing something? Everything seems clear to me from the Rollback guideline page.–Ammarpad (talk) 20:31, 20 June 2018 (UTC)
You've got the idea, but for example, say a user removes a large batch of content from a page with no explanation. The standard procedure is to revert the removal and warn the user (Huggle can do this with one click). Then someone else does the same thing, so you repeat the process. But if the article is under sanctions (say 1RR and the typical), you've already blown it right there. Home Lander (talk) 22:02, 20 June 2018 (UTC)
The relevant policy here is WP:3RRNO, which lists types of behavior that are exempt from 3RR, 1RR, 0RR, etc. If the edits are obvious vandalism, of the kind that any well-intentioned user would agree constitute vandalism, such as page blanking and adding offensive language, then you may revert the edits freely as many times as necessary – these are generally the only kinds of edits you should be using Huggle to revert.
On a tangentially related point, if a user removes unsourced or poorly sourced content without an explanation in the edit summary, I typically like to just assume per WP:AGF that the removal was done on the basis that the content was unsourced/poorly sourced, and per WP:BURDEN, it's good practice to just leave it removed in that case. Mz7 (talk) 23:11, 20 June 2018 (UTC)
Another consideration here is that per WP:AC/DS#Awareness, you are required to be aware of the page restriction before you can be sanctioned for violating that restriction. Mz7 (talk) 23:23, 20 June 2018 (UTC)
@Mz7: Thanks. This is exactly what I was looking for. Home Lander (talk) 00:11, 21 June 2018 (UTC)

Trademark mis-use

Do we have any policy about when we will use someone's registered trademark as a generic term, even while they're actively trying to prevent that? E.g. Velcro; see Talk:Hook and loop fastener. Dicklyon (talk) 03:53, 21 June 2018 (UTC)

@Dicklyon: You mean besides MOS:TM? ―Mandruss  04:11, 21 June 2018 (UTC)
MOS:TM actually doesn't cover this. Unless we know a term has become a generic trademark, we should avoid using the trademark term to refer to general usage. A list of such cases are at List of generic and genericized trademarks in the third section. It offers good advice from the AP Manual of Style "use a generic equivalent unless the trademark is essential to the story". As to what are and are not generic trademarks, I haven't been able to find an authoritative list for the US PTO, but we'd should follow US regulations here to determine it in main space. --Masem (t) 04:15, 21 June 2018 (UTC)
Right, not really a style issue. Thanks for that link. The "Velcro" under discussion shows up in the section List of generic and genericized trademarks#List of protected trademarks frequently used as generic terms. So what is our policy for such things that are "actively protected" and also "frequently used as generic terms"? Dicklyon (talk) 04:19, 21 June 2018 (UTC)
Style is the major driver since its a difference of wording choices, but its not the full picture. But we otherwise have no hard advice here. It makes sense to avoid the use of non-generic trademark when not referring to the product specifically. I do note we ignore "(R)" or "TM" symbols with any other trademark, so the request to call "Velcro" as "Velcro (R)" won't happen, but we should seemingly (in the "do the least harm" view), respect the non-generic trademark state, even if the RSes routinely ignore it. --Masem (t) 04:26, 21 June 2018 (UTC)
I tend to agree in the Velcro case, but would feel better if we had more clear guidelines some place about when to respect a trademark and when to treat it as generic. How do we draw the line? Dicklyon (talk) 04:38, 21 June 2018 (UTC)
I've been trying to find an "official" comprehensive list, but cannot find one. (Even searching on marks at USPTO do not easily reveal generic from non-generic). We need a source/list like this to draw that line, and haven't found something of sufficient authority here, yes. --Masem (t) 04:50, 21 June 2018 (UTC)


RfC: Enabling TemplateStyles

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
There is a clear consensus to YesY enable the extension at,WBGconverse 13:38, 18 June 2018 (UTC)

Should Extension:TemplateStyles (help) be enabled on the English Wikipedia as soon as technically possible? Jc86035 (talk) 12:28, 18 May 2018 (UTC)


The TemplateStyles extension will, in brief, allow custom CSS pages to be used to style content without an administrator having to edit sitewide CSS. This will make it more convenient for editors to style templates; for example, those templates for which the sitewide CSS for the mobile skin or another skin (e.g. Timeless) currently negatively affects the display of the template. The extension is already in use on some other Wikipedias, and should not open any avenues for vandalism which are not already possible with existing templates and inline styling. However, it cannot be implemented until HTML Tidy is replaced with RemexHtml, which is scheduled to happen for the English Wikipedia after June 2018.

Currently, TemplateStyles is being enabled for Wikipedias on a case-by-case basis, and if this RfC is successful then a Phabricator task will be made requesting the extension's deployment at the same time as RemexHtml.


  • mw:Template:Stylish (css)
  • mw:Template:ResponsiveAmboxExample (css)


  • Support. Jc86035 (talk) 12:28, 18 May 2018 (UTC)
  • Yesss Galobtter (pingó mió) 16:00, 18 May 2018 (UTC)
  • Yes please. I have lots of templates that i could fix if only I had these capabilities. —TheDJ (talkcontribs) 17:37, 18 May 2018 (UTC)
  • Support - I can think of excellent use cases for this - making templates responsive with media queries is the first one that comes to mind. Richard0612 17:48, 18 May 2018 (UTC)
  • Support, because it will be much easier for any template editor (not that particular user right, but an editor of template) to request a custom styling for certain templates. I, too, can think of places where custom CSS will be very handy. epicgenius (talk) 21:19, 18 May 2018 (UTC)
  • Maybe? I'd like to use an actual use / example before deciding. Headbomb {t · c · p · b} 22:34, 18 May 2018 (UTC)
    • @Headbomb: A small example can be seen at mw:Template:ResponsiveAmboxExample, the image gets hidden if your browser window is narrow enough. Think of doing something similar with navboxes so the mobile site can stop hiding them. Anomie 07:46, 19 May 2018 (UTC)
      • So basically, this can't (at least straightforwardly) change say an existing string to a different string, but would rather apply things like font changes, width changes, and other CSS type of changes on a per-template basis? I think we still ought to have some restrictions on that (Evad37's restrictions/best practices below seem very reasonable) especially for accessibility reasons, but I don't why what that couldn't be rolled out now (i.e. support), with the understanding that people using this are careful/use WP:COMMONSENSE. Headbomb {t · c · p · b} 11:43, 19 May 2018 (UTC)
  • Conditional support, if we get some sort of guidelines and/or best-practices in place first. Stuff like "only style the template's output", "avoid using !important", "use selectors and class names that are highly likely to be unique to that template (i.e. myTemplate-row rather than row)", "only images which don't require attribution can be used as background images". - Evad37 [talk] 02:01, 19 May 2018 (UTC)
  • Support I've been waiting a long time for this. This will allow us to fix a lot of templates for mobile, and also to reduce the size of the HTML we produce by getting rid of duplicated inline CSS. — Mr. Stradivarius ♪ talk ♪ 07:38, 19 May 2018 (UTC)
  • Sure, seems useful. I'd worry about abuse and keeping track of it all — it seems like the potential for pages could be huge — and would definitely support some level of baseline protection status (probably AC default, elevate to TE if heavily used). Basically, if TheDJ and Stradivarius think it'd be good, it's probably good. ~ Amory (utc) 11:58, 19 May 2018 (UTC)
  • Support This sounds great. I was concerned about mal-use but the measures in place look well thought-out. Cesdeva (talk) 07:23, 22 May 2018 (UTC)
  • Support It looks like it would be useful. Guidance will be developed in the usual way. There may be occasional misuses but they will be reversible. I assume changes will show up on watchlists in the usual way? · · · Peter (Southwood) (talk): 08:29, 22 May 2018 (UTC)
  • Support Not having any useful way to code responsively (or even use CSS correctly) is a real pain, it's like trying to build a car with no wheels and the wrong chassis, and it makes everything on wikipedia look like it's from the early 2000's. Because it is. This would be so helpful. JLJ001 (talk) 17:19, 24 May 2018 (UTC) SOCKSTRIKE. Primefac (talk) 18:37, 31 May 2018 (UTC)
  • Support As long as we have guidelines in place to control how this is used. We don't want editors going wild with this. — AfroThundr (tc) 07:48, 27 May 2018 (UTC)
  • Conditional support, per Evad37. I was going to saying something like this myself (and I think I did in a previous round), but Evad37's got the gist of that minor issue. I fully support going forward with this feature implementation, it just can't be dumped on the community without pre-addressing the potential problem points.  — SMcCandlish ¢ 😼  04:24, 2 June 2018 (UTC)
  • Support, it's high time! – Uanfala (talk) 10:42, 9 June 2018 (UTC)

Discussion (TemplateStyles)

Sounds scary - if I understand correctly, a template in one part of an article would be able to completely or partially mangle the display/styling of a different template in a completely different section of the page. And not just from vandalism, but also good-faith edits if they just happen to result in templates with conflicting rules, which might not be obvious at the time of editing. - Evad37 [talk] 15:41, 18 May 2018 (UTC)

Hmm, people who make use of it should I hope make sure their styling does not affect the rest of the page/other templates but only the target template. People who vandalize can perfectly well cover screen-fuls of page with image vandalism so not going to dramatically up the possibilities of vandalism Galobtter (pingó mió) 16:00, 18 May 2018 (UTC)
Correct, but if that becomes unmanageable, we could elevate edit permissions to templateeditor or something. the benefits will outweigh the negatives. Besides. postion:absolute bothers me on half the user pages and that seems perfectly acceptable to the community. —TheDJ (talkcontribs) 17:37, 18 May 2018 (UTC)
+1 for banning position:absolute and other crimes against design. :P Richard0612 17:50, 18 May 2018 (UTC)
@Richard0612: I think a blanket ban on position:absolute wouldn't be very practical, since there are e.g. 26 Lua modules which use it for largely legitimate purposes such as overlaying images. Jc86035 (talk) 17:57, 18 May 2018 (UTC)
@Jc86035: I was being entirely flippant with my comment - of course it does have sensible uses (image overlays, charts, etc.) and shouldn't be banned. I've just seen a lot of user-space z-order abominations (not that I like CSS much as a technology anyway, but it's the best we have). Richard0612 18:05, 18 May 2018 (UTC)
It seems I left my irony–sarcasm meter off. Jc86035 (talk) 18:07, 18 May 2018 (UTC)
Easily done, no harm! :) Richard0612 18:10, 18 May 2018 (UTC)

So for this custom CSS, which namespace would it be hosted in? Would users be restricted from editing these CSS pages (e.g. limiting these pages to administrators/template-editors only)? epicgenius (talk) 21:19, 18 May 2018 (UTC)

It would be in the Template: namespace, and protection could be applied as needed. High-exposure pages will inevitably be TE-protected. Richard0612 21:30, 18 May 2018 (UTC)
Thanks. epicgenius (talk) 22:30, 18 May 2018 (UTC)

I started a draft guideline page at Wikipedia:TemplateStyles; it could do with some expansion and/or discussion - Evad37 [talk] 02:48, 19 May 2018 (UTC)

  • A usage guideline I'm thinking we should have if going forward is that styles should be easily able to be identified and edited by being associated with a specific template or group of templates. In general, this means it should be a subpage related to the such as: Template:xxxx/styleyyyy.css. Explicitly, for articles styles should never be configured to pull from the User: namespace. — xaosflux Talk 21:51, 19 May 2018 (UTC)
    TemplateStyles CSS pages must have the sanitized-css (Sanitized CSS) content model, which is the default for subpages in the template namespace that end with .css (Template:Foo/bar.css). Only users with changecontentmodel (admins only here) can create them elsewhere. — JJMC89(T·C) 23:02, 19 May 2018 (UTC)
    @JJMC89: perhaps that is a side affect of having that extension installed...currently template subpages ending in .css are in model wikitext (e.g. Template:X1/style.css). — xaosflux Talk 23:37, 19 May 2018 (UTC)
    Yes. You should be able to test on testwiki. — JJMC89(T·C) 00:39, 20 May 2018 (UTC)
    Saw it there, sample for anyone watching at testwiki:Template:-/test.css. — xaosflux Talk 01:10, 20 May 2018 (UTC)

If allowed - default protection?

To touch on some points above, by default any confirmed user would be able to create/edit these type of pages. If we want the default to be something else we can implement controls in a few ways. The title blacklist could be used limit creations to templateeditors similar to the way we do editnotices. We could also do various things with the edit filter. As mentioned in the above section, individual pages could always be dealt with via page protections. If moving forward, do we want to establish any technical controls here? — xaosflux Talk 21:47, 19 May 2018 (UTC)

Is there any reason not to restrict these like editnotices? I'm not sure what a usecase would be where it would be necessary to make these visible and frequently edited. ~ Amory (utc) 01:02, 20 May 2018 (UTC)
Why should the styles of a template be harder to edit that the template itself. {{3x|p}}ery (talk) 01:04, 20 May 2018 (UTC)
They should really have the same protection level as their parent template. Otherwise you just encourage styles to remain inline, or get inline styles added on top of the TemplateStyles CSS since the template was editable but not the css. Perhaps an adminbot could do the protections automatically? - Evad37 [talk] 03:32, 20 May 2018 (UTC)
Or just create a category akin to Category:Templates using under-protected Lua modules. {{3x|p}}ery (talk) 03:47, 20 May 2018 (UTC)
If a template is unprotected, presumably its css page would also be unprotected. What would there be to prevent a rule being maliciously added to that css page? For example, one having a selector that is not specific to the template's code, but perhaps matches some other part of a page - maybe as broad as
body { /* ... */ }
- this could potentially compromise all pages using that template. --Redrose64 🌹 (talk) 09:51, 20 May 2018 (UTC)
The styles are scoped to prevent that kind of thing - basically you can't mess with anything that isn't contained in an element with the class .mw-parser-output. There's still potential for abuse, don't get me wrong, but it's not that bad. Richard0612 10:33, 20 May 2018 (UTC)
It says "Styles included by a template can currently affect content on the page outside of the content generated by that template" which is what I am worried about. --Redrose64 🌹 (talk) 20:06, 20 May 2018 (UTC)
Oh that's true, absolutely. If there's (e.g.) a div on the page that the CSS selects, it'll be affected. But the styles couldn't affect the body or any other elements of the interface. Then again, if a vandal could edit the CSS to cause chaos, they could edit the template itself to cause chaos. Hence the logic that the CSS should have the same level of protection as its parent template. Richard0612 20:20, 20 May 2018 (UTC)

Discussion at Wikipedia talk:TemplateStyles#RFC: Adopt as a guideline

 You are invited to join the discussion at Wikipedia talk:TemplateStyles#RFC: Adopt as a guideline. - Evad37 [talk] 08:26, 22 May 2018 (UTC)

Deployment of TemplateStyles

Hey! I'm the current product owner for TemplateStyles. I'm really glad that you're all excited about having TemplateStyles here on the English Wikipedia. The goal is to get TemplateStyles rolled out everywhere, and so far it's been rolled out to the German, Swedish, and Russian Wikipedias as a result of community requests, as well as some other sister projects, and it's working well on those wikis. As others have noted, TemplateStyles is dependent RemexHtml, which isn't being used on this wiki right now, so it can't be turned on here yet. I'll let you all know when RemexHtml is enabled here, so that TemplateStyles can be turned on. In the mean time, I suggest you all keep working on the guidelines, so that TemplateStyles can be turned on as soon after RemexHtml as possible. Thanks! --Deskana (WMF) (talk) 23:12, 16 June 2018 (UTC)

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Cannot remove unread status for "The page ‪Continue?‬ has been reviewed"

At the top right corner of the page, when I click on "The page ‪Continue?‬ has been reviewed", it will not remove the "unread status". --Jax 0677 (talk) 11:36, 9 June 2018 (UTC)

Mobile site broke on Windows Phone

On my WinPho 8.1 (I know, there aren't many of us left, and it's Internet Explorer): I have experienced two new degradations in the past 2+ days, when going to

  1. It keeps forgetting that I am logged in. Each time I go to the front page, it's logged out again. By contrast with on a PC, the "keep me logged in" checkbox isn't displayed.
  2. After I do log in, the hamburger menu greets me by name, but the Nearby and Watchlist buttons are missing. I'd really like the Watchlist back.

Was the mobile site upgraded recently, and has anyone else tried it on WinPho? David Brooks (talk) 00:31, 10 June 2018 (UTC)

Hi David. I don't think you're alone, I'm experiencing similar problems on my Windows Phone too. I have a Lumia 535 running Win10, and I can't get it to work properly on anything using Mediawiki. I've not specifically tried it in Wikipedia, but I suspect it's not limited to WP. Dane|Geld 00:44, 10 June 2018 (UTC)
@DaneGeld: @DavidBrooks: could this be related to Wikipedia:Village_pump_(technical)#Change_coming_to_MonoBook_skin_for_mobile_users? DuncanHill (talk) 13:30, 10 June 2018 (UTC)
@DaneGeld: @DuncanHill: No, as I'm using the Vector skin. Here are the screenshots: phone first, then desktop (on Edge, but Internet Explorer works properly on desktop too). As you can see, the URL is A couple of days ago these menus had the same content.
Problem #1 seems to suggest that at the same time, a couple of days ago, the logged-in cookie started to be created non-persistent (has no expiration date specified) on the phone, and automatically goes away when the browser tab closes. But that's just the symptom; I can't debug cookies on this phone. David Brooks (talk) 03:00, 11 June 2018 (UTC)
ETA overnight- I guess that, although I don't use Monobook so assumed its mobile skin change was not related, the mere fact of tinkering with the mobile interface could have caused some collateral damage? David Brooks (talk) 12:45, 11 June 2018 (UTC)
@DavidBrooks: @DaneGeld: I'm not aware of any changes to the mobile site that would cause this, but I don't know everything. :) I've created a phabricator task to have the engineers take a look. CKoerner (WMF) (talk) 12:53, 11 June 2018 (UTC)
Hey there @DavidBrooks: @DaneGeld:! Could I please ask for which user agent your mobile device has? provides an easy way to copy and paste. Jdlrobson (talk) 20:14, 11 June 2018 (UTC)
@Jdlrobson: Mozilla/5.0 (Mobile; Windows Phone 8.1; Android 4.0; ARM; Trident/7.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; 909) like iPhone OS 7_0_3 Mac OS X AppleWebKit/537 (KHTML, like Gecko) Mobile Safari/537. I never looked at that before; must be pretty confusing. Again, this is Windows Phone 8.1, which of course is no longer supported by MS. David Brooks (talk)
In this context, I should probably point out what I mentioned above: the "keep me logged in" checkbox is also now missing, which probably explains the cookie non-persistence. David Brooks (talk) 15:02, 12 June 2018 (UTC)
Right, so it looks like we dropped JS support for this browser so Nearby is not going to work thus hidden. I think we can restore the watchlist link and display a checkbox to allow you to keep logged in on mobile. We have tasks for both and will hopefully get those addressed soonish Jdlrobson (talk) 18:39, 12 June 2018 (UTC)
Thank you for looking into it! David Brooks (talk) 22:27, 12 June 2018 (UTC)
In case anyone else comes across this thread, I just discovered UC Browser (from Alibaba) which still works. Maybe I'm the last WinPho 8.1 user on the planet to know about it. Although it doesn't display the checkbox, it does persist login, and it does show the missing menu options. Each user will have to decide whether this is worth the reported privacy/security flaws. David Brooks (talk) 12:15, 17 June 2018 (UTC)

Why can't the time in the footer identify the time zone?

I'm not sure what controls the standard footer text at the bottom of articles and pages such as this one. At the moment it reads:

This page was last edited on 12 June 2018, at 20:58.

A reader wrote to Wikimedia to ask which time zone is associated with the time. While veteran editors, especially those who have customized their preferences to select a time zone will know the answer (UTC, unless you specify a different one) why couldn't we include the time zone in the standard message. It doesn't seem to be a space issue, and most of our readers are unlikely to know that UTC is the default.

What's the harm in changing it to read:

This page was last edited on 12 June 2018, at 20:58 UTC.


This page was last edited on 12 June 2018, at 20:58 (UTC). --S Philbrick(Talk) 21:46, 12 June 2018 (UTC

I think that's a very good idea. DuncanHill (talk) 21:59, 12 June 2018 (UTC)
The text is made by MediaWiki:Lastmodifiedat. There is an old suggestion by Jason Quinn at MediaWiki talk:Lastmodifiedat#add " (UTC)" string? The message is called with a time in the default time zone of the wiki (UTC) for unregistered users, and in the time zone at Special:Preferences#mw-prefsection-rendering for registered users. But the message is not told which time zone it is called with, or whether the user is unregistered. I guess we could use <span class="anonymous-show"> UTC</span> to only show " UTC" to unregistered users. PrimeHunter (talk) 22:21, 12 June 2018 (UTC)
Putting UTC in parenthesis would be preferable to not doing so, in order to be consistent with the format used in discussion timestamps. --Redrose64 🌹 (talk) 22:48, 12 June 2018 (UTC)
I've just found that for a few weeks in 2009, we did indeed emit a hardcoded " (UTC)" that was appended to the passed-in time. Admins might like to look at this. --Redrose64 🌹 (talk) 22:52, 12 June 2018 (UTC)
As I suspected, it is moderately complicated. But following up on Primehunter's suggestion, oen can argue that if you affirmatively chose a time zone, you know which one you chose, and if you didn't, you can, so showing (UTC) to unregistered users would always be accurate, and would clarify the time zone for the readers most likely not to know the answer.--S Philbrick(Talk) 00:05, 13 June 2018 (UTC)
This seems useful enough if there are no technical issues with implementation. · · · Peter (Southwood) (talk): 06:24, 13 June 2018 (UTC)
The suggested solution would send <span class="anonymous-show"> UTC</span> to everybody and rely on the browser to hide "UTC" for registered users. If CSS for anonymous-show fails to load from MediaWiki:Group-user.css then registered users will also see "UTC". Pages are occasionally displayed with no or broken CSS but I guess this willl be rare and it's not a serious problem if a few users see "UTC" on a non-UTC time on a page which may look broken. PrimeHunter (talk) 09:55, 15 June 2018 (UTC)
Here is the active code if people want to try viewing it in different circumstances: " UTC". PrimeHunter (talk) 09:59, 15 June 2018 (UTC)
Please can we use <span class="anonymous-show"> (UTC)</span> for consistency with other timestamps? --Redrose64 🌹 (talk) 10:11, 15 June 2018 (UTC)
I support that. 12:00<span class="anonymous-show"> (UTC)</span>. produces "12:00 (UTC)." which renders as "12:00 ." with a space for me in Firefox (not caused by the added parentheses). We could say 12:00<span class="anonymous-show">&nbsp;(UTC)</span>. instead. This produces "12:00 (UTC)." which renders as "12:00." for me with no space. PrimeHunter (talk) 10:47, 15 June 2018 (UTC)
I have created MediaWiki:Lastmodifiedat with the suggestion. It works for me. I only see " (UTC)" when I'm logged out. Hopefully the CSS to hide it works for all registered users. PrimeHunter (talk) 19:33, 18 June 2018 (UTC)

Wikiproject front page displaying bizarrely

Wikipedia:WikiProject Cornwall no longer displays properly. The Noticeboard section in particular. One can no longer edit the different boards (articles needing attention, new articles, etc), and they overlap and straggle on down the page. Can anyone see what has caused this and help to fix it please? DuncanHill (talk) 13:16, 13 June 2018 (UTC)

I see a bunch of redlinks to Portal:Cornwall/box-footer on that page. Was it important? Chris857 (talk) 13:34, 13 June 2018 (UTC)
Not sure. I know the page was displaying correctly in May, when I last updated the "New Articles" box. Could the degradation be in some way related to the changes to Portals that happened recently? DuncanHill (talk) 13:37, 13 June 2018 (UTC)
Portal:Cornwall/box-footer only called {{Box-footer}}. I have called it directly instead.[10] I think Pbsouthwood should have done that before deleting the page. PrimeHunter (talk) 13:42, 13 June 2018 (UTC)
Thanks, that's fixed the overlaps and straggling, but one still cannot edit the noticeboards, and there are no edit links for any of the sections. DuncanHill (talk) 13:47, 13 June 2018 (UTC)
The edit links in the boxes have been restored with [11]. I guess it's intentional that there are no section edit links. PrimeHunter (talk) 14:03, 13 June 2018 (UTC)
Thanks all for the quick responses and action :) Not sure about the lack of section edit links, but still a great improvement. DuncanHill (talk) 14:10, 13 June 2018 (UTC)
Adding |EDIT=yes to Portal:Cornwall/box-header should give section edit links if the project wants it. PrimeHunter (talk) 14:18, 13 June 2018 (UTC)
At the time I deleted it, it had had no content (blank page) for a while, and was on a long list of unused portal subpages for deletion. There were probably no direct links to it, but we have found that some templates and modules are calling subpages of pages where they are transcluded, which can be relatively tricky to track down. If this happens again, please report on the WikiProject:Portals talk page, as there are a few of us who now know how to deal with this problem.
DuncanHill, I don't think the members of Wikipedia:WikiProject Portals were expecting portal boxes to be transcluded into WikiProject pages, though as far as I am concerned it is a reasonable thing to do. If you are maintaining Portal:Cornwall as part of WikiProject Cormwall, please let the portal project know how you prefer to manage it, so we can try to avoid any further problems. Cheers, · · · Peter (Southwood) (talk): 15:12, 13 June 2018 (UTC)
The new articles, articles needing attention, etc, boxes are Wikiproject material that the portal uses, not portal boxes that the wikiproject uses. I also had to fix a link here where a redirect was deleted without incoming links being corrected. DuncanHill (talk) 15:22, 13 June 2018 (UTC)
DuncanHill, Fair enough, they are conceptually project pages which use portal components, which is probably why people were not expecting this kind of side-effect. I cannot speak with certainty for the people who listed the portal subpage for deletion, but I would not have guessed that it was transcluded into a project page through a series of about two templates and a Lua module. It happened, and the important thing is whether it has been fixed. We will try to look out for similar side effects, but often the only way to find them is when they happen. Cheers, · · · Peter (Southwood) (talk): 03:24, 14 June 2018 (UTC)
I agree.    — The Transhumanist   21:32, 15 June 2018 (UTC)

hide watch list message cookies disappearing

Hi, see discussion at MediaWiki_talk:Watchlist-messages#dismissed_messages_keep_appearing_again if you have any feedback about problems with your watchlist cookies not working. — xaosflux Talk 17:45, 13 June 2018 (UTC)

Syntax highlighting will no longer turn off / Forced into 2017 Editor

I just hit the edit button and my editor has gone nuts. There is syntax highlighting; Headers now have increased font size etc. Essentially my 2010 editor has been forced to the 2017 editor even though I have not enabled it. This screws up my entire work flow and prevents me from using my browser based snippet program. I have looked through Preferences to find a way to turn it off but have found nothing. Is there a way to get the old, simple wikitext editor back? The new features are neat but neat is only good if it does not break stuff. Jbh Talk 23:57, 13 June 2018 (UTC)

@Jbhunley: There should be a pencil icon in your editing toolbar, last button before the "Advanced" menu. This will toggle syntax highlighting. Does that work for you? MusikAnimal talk 00:01, 14 June 2018 (UTC)
Sorry, you said you were forced into the 2017 editor, too. That should be in your beta preferences. Uncheck "New wikitext mode". No idea how you got forced into this, though MusikAnimal talk 00:06, 14 June 2018 (UTC)
(edit conflict)}Yes! I do not know whether to feel relieved or stupid. Thank you! I was fearing I would have to go back to writing WikiText by hand…
I assumed it was the 2017 editor since the highlighting scheme looked like the one I saw in the 2017 editor rather than what I remembered the 2010 highlighting to look like ie actually changing the font size and face rather than just different colors. The 2017 version was not toggled in Beta so I thought a new default setting had been pushed out. I was, in fact, still in the 2010 editor. Jbh Talk 00:12, 14 June 2018 (UTC)
Not just you — that pencil thing is new, when did that get added? Nice feature, but wish it wasn't on by default. Was editing a .js page so couldn't turn it off. ~ Amory (utc) 01:13, 14 June 2018 (UTC)
It is has been available as a beta feature for a while, and today it was graduated out of beta. However it definitely shouldn't have turned itself on. I logged into a few alternate test accounts, where I had never used syntax highlighting, and it was not turned on. So not everyone is affected, it seems. At any rate, you can turn it off, and if you do so it should stay that way. Note the JavaScript/CSS syntax highlighting is a different feature that has been around for quite some time. You can also turn that off, though -- click on the "<>" button at the far left of the editing toolbar. MusikAnimal talk 03:00, 14 June 2018 (UTC)
Can somebody please update meta:Community Tech/Wikitext editor syntax highlighting. It claims it is still a beta feature and may be released in July or August. PrimeHunter (talk) 08:45, 14 June 2018 (UTC)
The pencil has been there all along? Didn't notice it. And perhaps it was a "if you've ever turned it on" thing? At any rate, it colors nowiki on js pages, that's how I saw it. As a public service announcement, if anyone uses User:ערן/autocomplete.js, it breaks on this. ~ Amory (utc) 10:31, 14 June 2018 (UTC)
Regarding autocomplete, I may try to adapt it to syntax highlight once phab:T170001 is fixed - but I prefer to not invest time on fixing it as the infrastructure may rewritten (with or without CodeMirror) to properly support all languages. Eran (talk) 17:53, 14 June 2018 (UTC)
And of course the pencil icon isn't there at all if the toolbar is turned off in Preferences, Editing.
If I was inclined to give the syntax highlighting a try, is there a documented way of configuring it?
Mitch Ames (talk) 13:33, 14 June 2018 (UTC)
No, the pencil icon hasn't been there all along. It has been if you had "syntax highlighting" turned on in your beta preferences. Now it is out of beta so everyone gets the pencil. @Amorymeltzer: When you edit a JS page, like User:Amorymeltzer/dashes.js, you see the new syntax highlighting? It has occurred to me that to have the (preexisting) JS/CSS editor, you need "Enable enhanced editing toolbar" turned on in your preferences. I'm guessing you do not. Indeed JS pages don't seem to work well with the new syntax highlighting, because it's not wikitext. I think we can disable this feature on JS/CSS/JSON pages, if you think that's a good idea? (by the way, I definitely recommend the "enhanced editing toolbar" when editing JS!!).

@Mitch Ames: Indeed there is no pencil icon if the toolbar is turned off (because there's nowhere to put it). We could use a link in the sidebar, maybe, but the old toolbar-less editor is going to be phased out anyway, as I understand. MusikAnimal talk 15:55, 14 June 2018 (UTC)

"That pencil icon" has been in the corner of the toolbar for several years, and it switches you to the visual editor. "That highlighter pen icon" just arrived, and it toggles syntax highlighting. It appears that the complaints that the highlighter marker looks too much like the editing pencil are being collected at phab:T174145. Whatamidoing (WMF) (talk) 16:30, 14 June 2018 (UTC)
You are right, thanks for clarifying. I didn't even notice the pencil on the right! I assume we were all talking about the highlighter, though, which indeed looks an awful lot like a pencil. MusikAnimal talk 17:21, 14 June 2018 (UTC)
@MusikAnimal and Whatamidoing (WMF): Yes, indeed, the highlighter. I use the old toolbar, as I only really use it for citation stuff anyway (hence, I only see one "pencil" since visual editor isn't an option) and the highlighter button shows up there. It's not a huge deal, but regardless of toolbar used, this new highlighter button doesn't show up in user js pages. That's good, but when using the old toolbar, js pages mirror the last used highlighting state, and you can't turn it off there since there's no button (or toolbar); you have to go to another page, click edit, turn it off, then reload your js page. With the enhanced toolbar, this isn't an issue. I can file a phab, since that's almost certainly not expected behavior. MediaWiki js pages also show the highlighting, but they also show the old toolbar, so it's reparable. Also, holy shit, thank you, enhanced toolbar for js is amazing! ~ Amory (utc) 17:41, 14 June 2018 (UTC)
  • I personally feel it shouldn't have been graduated from beta just yet. There are still some serious performance issues that I am noticing, especially when I'm on my phone. The syntax highlighter, especially on larger bodies of wikitext, take up to 2 seconds to process sometimes and in doing so blocks key inputs to the text area. If you type regularly, the key inputs queue up and so you sit there waiting for the syntax highlighter to re-process every key stroke. This is even more noticeable on my phone, and as a result auto-correct really messes up my text in those instances. I would like to see the syntax highlighter implement a waiting period before processing. Say like 1.5 seconds after the last keystroke, it should process what's in the textarea, and go to sleep while the user is actively typing. Development IDEs do this already.—CYBERPOWER (Around) 12:40, 14 June 2018 (UTC)
    Concur. I regularly use charinsert for wiki markup, most often to create <code><nowiki></nowiki></code>, two clicks which should leave the cursor inside the <nowiki></nowiki>. But, with the highlighter enabled, the cursor is always moved to the start of the line. The new functionality should not break the old tried and true.
    Trappist the monk (talk) 14:50, 14 June 2018 (UTC)
    I think that is what breaks ProKeys as well. It can not find the current cursor position when the macro proscessing is invoked so it can not tell if the preceding text has a snippet associated with it or where to insert the text if there is one. A brief delay before processing might fix that. It would be nice to be able to use syntax highlighting. The new version is quite nice. Jbh Talk 15:20, 14 June 2018 (UTC)
    @Cyberpower678: I'm not sure what IDE you're referring to, but I assume one that is not within the browser? The syntax highlighting uses a JavaScript library called CodeMirror. This is the same library that GitHub's editor uses, for instance, and also the web inspector that comes with Chrome. The nature of the implementation means very large bodies of content, or a slower devices (like some smartphones), will have a noticeable performance impact. Despite these issues, the time had come that we at least let people decide if they want to use it, and switch it on/off as desired.

    @Trappist the monk and Jbhunley: Your issues with Charinsert and ProKeys sound fixable. I managed to get User:MusikAnimal/responseHelper (which also does cursor placements) to work with the syntax highlighting, maybe I can make the same fix to those scripts. I will look into it! MusikAnimal talk 16:20, 14 June 2018 (UTC)

    If it would be possible that would be great. Thank you for looking into it! Jbh Talk 16:53, 14 June 2018 (UTC)
    @MusikAnimal: When I referred to an IDE, I meant any IDE in general such as PyCharm or PhpStorm. When you make modifications to large chunks of code there, it will generally wait until you have finished typing before processing the text and update the highlighting. What I'm asking for is that this JS do the same. As it stands right now it updates after every keystroke and that produces a major slowdown as the text gets larger, even on a computer. It should be possible to insert a sleep timer that gets reset on every key stroke, and when the timer elapses it updates the highlighting. That would add a major performance improvement, not to mention reduce CPU usage as I am currently observing mine spike to 20% as I type in this window.—CYBERPOWER (Chat) 17:00, 14 June 2018 (UTC)
    I don't know, all of that logic is part of the CodeMirror library. In general we haven't had to many complaints about performance, except on large pages. Your IDE is compiled to assembly and runs directly on your operating system. It will always be faster than your browser (certainly your phone!), which has to interpret the JavaScript. I've actually never used an IDE that doesn't highlight on every keystroke, but I digress. Hopefully we're still looking at a net positive of the syntax highlighting feature being available. All I can recommend is to turn it off if you're experiencing problems. Sorry! MusikAnimal talk 17:21, 14 June 2018 (UTC)
    @MusikAnimal: Then what about giving users the option to have the highlighter not kick in if it takes to long per run, or if the page size exceeds a certain limit?—CYBERPOWER (Chat) 17:31, 14 June 2018 (UTC)
    Interesting idea! Yes I think that is certainly possible. My suggestion would be to make a documented way of configuring this in your Special:MyPage/common.js, such as CodeMirror.maxPageSize = 100000; or something. I don't think we'd want to expose this in the interface, or add more preferences. An initial timeout (takes too long to load) is probably something it should do automatically, and perhaps could be disabled in your user JS (e.g. CodeMirror.timeout = false). Would you mind creating a Phabricator task? MusikAnimal talk 17:36, 14 June 2018 (UTC)

@MusikAnimal: you mentioned above that the WikiText editor is now using CodeMirror. Is that just for syntax highlighting or the editor in general? Is it possible to load CodeMirror alternate keymap files i.e keymap/vim.js? Jbh Talk 20:33, 14 June 2018 (UTC)

Just for syntax highlighting, but that effectively takes over the editor itself. I am not aware of how to load alternate keymaps in CodeMirror, but sounds like it's worth exploring! By the way, the bug with cursor placement is filed at phab:T197263 and we are looking into it. MusikAnimal talk 20:39, 14 June 2018 (UTC)
Yep... Being able to hack the WikiText editor via exposed CodeMirror configuration would be great but that capability seems to go in the opposite direction of what the push to Visual Editor indicates (more technical rather than less). It is a nice wish though.
Thank you for looking into the cirsor issue. Jbh Talk 20:09, 15 June 2018 (UTC)

Potentially related problem

Is this change in syntax highlighting the reason that I am experiencing a strange editing problem? For the last week (or perhaps less), I have found that on occasion an edit window is extremely slow. It does not happen on all pages; it does not happen in every section of an affected page. For example, at Wikipedia:Bot requests, every section that I have tried to edit works just fine - with one exception. If I try to edit the section Wikipedia:Bot requests#Indexing talk page, the edit screen takes noticeably longer than normal to load - and once it has loaded, typing a single character takes ten seconds, so a few words take several minutes to type in. The same happens with the edit summary window. It is replicable: exiting the page and trying the "[edit]" link again produces the same result, as does using Ctrl+F5 to reload the page "clean". It's also persistent: closing the browser and restarting it yields exactly the same issue. In case you are wondering how I made this edit: having found that it was a slow edit screen. I composed my reply in a plain text editor, and copypasted it in. The paste took ten seconds to achieve, so that demonstrates that it is keystrokes and not characters that are the limiting factor. So: is it possible to prevent the syntax highlighting script from loading? --Redrose64 🌹 (talk) 18:16, 19 June 2018 (UTC)

If you want the syntax highlighter off, then I believe that you just need to toggle the button off in the toolbar, and it will remember that state (in a hidden pref or equivalent) until you toggle it back on someday. Whatamidoing (WMF) (talk) 15:16, 21 June 2018 (UTC)

Read-only for 30 minutes on July 18 06:00 UTC

Because of maintenance work, English Wikipedia will be read-only for up to 30 minutes on 18 July (that is in a little bit over a month, not in a few days). Everyone will be able to read it, but you can’t edit. This is just to give you an early warning.

If everything goes well, this should just take a few minutes, but prepare for 30 minutes to be on the safe side. /Johan (WMF) (talk) 14:29, 14 June 2018 (UTC)

You can read more in the tasks linked to from phab:T197134. /Johan (WMF) (talk) 14:34, 14 June 2018 (UTC)

Thanks notifications vanished

At the top, between the links to my user and user talk pages, there are the "bell" and "TV set" icons. The latter has the figure "2" superimposed, implying that I have two unread thanks notifications, but when I click it, I get "There are no notifications." Not even a list of old thanks, which is what I got before today. Clicking the bell icon lists all the old mentions, reverts etc. Is something broken in the thanks system? Oh, it's Thursday - of course it's broken. How silly of me. --Redrose64 🌹 (talk) 20:12, 14 June 2018 (UTC)

Mine seem to be working normally. Have you checked your settings at Special:Preferences#mw-prefsection-echo? DuncanHill (talk) 20:15, 14 June 2018 (UTC)
Something is broken: I click on mine and get the "Our servers are currently under maintenance or experiencing a technical problem." page "PHP fatal error: Class undefined: PageTriageMarkAsReviewedPresentationModel" --Masem (t) 20:16, 14 June 2018 (UTC)
Mine is not working either, the bubble shows up with the number of notifications but when I click on it it says there are none. Home Lander (talk) 20:22, 14 June 2018 (UTC)
Oh dear. Not sure about notifications issue, but the "PageTriage" bug should be fixed within an hour or two. Sorry! MusikAnimal talk 20:41, 14 June 2018 (UTC)
@MusikAnimal: I thanked you for the above post; it might duplicate the issue on your end. Home Lander (talk) 20:53, 14 June 2018 (UTC)
I'm having the same issue. Bringing down the dropdown shows "You have no notifications", but if I click the "All Notifications" button I can see the thanks message at Special:Notifications. --Ahecht (TALK
) 20:54, 14 June 2018 (UTC)

@Redrose64 and Masem: and everyone else... Is it working for you now? MusikAnimal talk 21:45, 14 June 2018 (UTC)

Yes, seems fixed. --Masem (t) 21:50, 14 June 2018 (UTC)
Yes, Face-smile.svg Thank you --Redrose64 🌹 (talk) 23:23, 14 June 2018 (UTC)
Ditto, working here as well. Home Lander (talk) 00:33, 15 June 2018 (UTC)
For the record, MaxSem is the one to thank for fixing it. I get credit for breaking it =p MusikAnimal talk 15:34, 15 June 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── And I get credit for explaining, for the benefit of those who have never seen a typewriter or a rotary telephone, that it's not a TV set but rather an inbox. BTW if someone can explain why some things ring the bell and some go in the inbox, it would take one small load off my tiny, tiny brain. EEng 13:54, 20 June 2018 (UTC)

I have been told (when I have complained that the things were in the wrong list) that the difference is urgent vs non-urgent. I have never found out why good news (e.g., Thanks) is not considered an urgent matter. Whatamidoing (WMF) (talk) 15:05, 21 June 2018 (UTC)
Thanks. That's some weird complication introduced by someone operating in a vacuum. EEng 15:12, 21 June 2018 (UTC)

Potentially untagged misspellings report

Hi! Potentially untagged misspellings (configuration) is a newish database report that lists potentially untagged misspellings. For example, Angolan War of Independance is currently not tagged with {{R from misspelling}} and it should be.

Any and all help evaluating and tagging these potential misspellings is welcome. Once these redirects are appropriately identified and categorized, other database reports such as Linked misspellings (configuration) can then highlight instances where we are currently linking to these misspellings, so that the misspellings can be fixed.

This report has some false positives and the list of misspelling pairs needs a lot of expansion. If you have additional pairs that we should be scanning for or you have other feedback about this report, that is also welcome. --MZMcBride (talk) 03:35, 15 June 2018 (UTC)

MZMcBride, how often will the database report be updated? Is there a tracking strategy? NotARabbit (talk) 05:15, 15 June 2018 (UTC)
Currently the report is updated manually. It could be automated in the future. The tracking strategy is basically the use of the "R from" templates and their associated categories. For example, once a page is marked as a misspelling and gets categorized in Category:Redirects from misspellings, it will no longer appear in future versions of the report. --MZMcBride (talk) 14:59, 15 June 2018 (UTC)
I started tracking my edits at the talk page, as well as posting a couple of notes. It’s a slow process! NotARabbit (talk) 06:34, 15 June 2018 (UTC)
There is a list in machine-readable format at Wikipedia:AutoWikiBrowser/Typos. I wonder if these should be the same list? :) --Izno (talk) 12:12, 15 June 2018 (UTC)
Yes, potentially. :-) --MZMcBride (talk) 14:59, 15 June 2018 (UTC)

Template problem buried somewhere

The template {{San Pablo City}} is transcluded on 17 articles. When I search for hlist, nine of those articles show up in the search results with the template source exposed, even though it does not show on the actual article pages. Can someone who understands templates figure out what is going on? Is there another element on those nine pages but not on the other eight that makes this happen? It’s been like this for days, so it’s not just a lag problem in the search. NotARabbit (talk) 04:56, 15 June 2018 (UTC)

NEVER MIND! I finally thought to try null edits on all the pages, and poof, they’re fine. Sigh. NotARabbit (talk) 06:45, 15 June 2018 (UTC)

Pageview data missing for June 14

I've just been looking at the Pageviews analysis for yesterday and it appears that the bot went down and failed to capture the pageviews for articles. (example here). Are we able to look into this and retrieve the views for yesterday? The C of E God Save the Queen! (talk) 07:08, 15 June 2018 (UTC)

In my experience the most recent data in that tool is often two days old. If you have no other indicator of missing data then data for yesterday will probably come tomorrow or later today. If you request the latest 10 days [12] then you currently get June 4 to June 13. PrimeHunter (talk) 09:20, 15 June 2018 (UTC)
Yes PrimeHunter is correct. My guess is if you check back tomorrow, the data will be there. I have no idea how this works (it happens in the Analytics cluster), but some articles may have data for today/yesterday, others not. I've briefly documented this at [13] MusikAnimal talk 15:32, 15 June 2018 (UTC)
It still hasn't updated for the 14th but has for yesterday, I think there is a problem here. The C of E God Save the Queen! (talk) 06:56, 16 June 2018 (UTC)
There is, or at least there was a problem. No data for 14 June. Lofhi (talk) 13:35, 16 June 2018 (UTC)
Is there likely to be a backfill process so that the 14th will show up relatively soon, or is it likely to be missing forever (or an extended time)? I have some automation that is blocked waiting for the data for the 14th at the moment, and want to know if I should just tell it the 14th is never coming and to skip it, or to just hang on a bit longer expecting it will show up within a few days at the latest... — Preceding unsigned comment added by Abulsme (talkcontribs) 16:46, 16 June 2018 (UTC)
(The C of E here). It's still not showing the stats for the day and I don't have much trust in the alternative view counters. Do we have an explanation for this and can the stats be retrieved? The Royal C (talk) 13:07, 17 June 2018 (UTC)
I've filed a task for this at phab:T197542. My assumption is the "job" failed to run, and they can simply re-run it to populate the data, but don't quote me. MusikAnimal talk 15:04, 17 June 2018 (UTC)
Looks like the backfill happened. At least my application is happy now and got caught up to the present. :-) Abulsme (talk) 18:13, 18 June 2018 (UTC)
Yup, everything should be there now. Rigorous caching on the pageviews API may mean the data is still missing for some, but it will show up eventually. In the meantime you should be able to change the date range, etc., and the data will show. MusikAnimal talk 18:35, 18 June 2018 (UTC)

Visual Editor for Talk pages, Discussion pages, etc

How long do we have to wait for this? Who are the people who are reposible for the API of Wikipedia? :) Shevonsilva (talk) 17:17, 15 June 2018 (UTC)

This is somewhere in the realm of "nope" and "never" because of how talk pages work. Might be something to add to WP:PERENNIAL at this point. --Izno (talk) 18:17, 15 June 2018 (UTC)
Oh dear dear, that might not be too complex. Developers/Software engineers have only to add some special icons for additional functions, and, in mobile version there is already a kind of GUI interface with a textbox. May I know who are the developers of wikipedia and how it works and how can I contact them for this? :) Thanks. Shevonsilva (talk) 20:44, 15 June 2018 (UTC)
No, it is definitely too complex. If you are sincerely interested in submitting a task, which is 100% likely to be declined, contact information can be found at Help:Bug reports. --Izno (talk) 21:05, 15 June 2018 (UTC)
Thanks for the link. Why do you think it is complex? :) We have to allocate new functions to new toolbar bottons and can directly use the existing API through inheritance and polymorphism. This cannot be a big task as I believe. Shevonsilva (talk) 06:35, 16 June 2018 (UTC)
The phab linked here helpfully quotes/links mw:Help:VisualEditor/FAQ, which, near the bottom, answers your questions. In short, The visual editor is designed to edit content, plain pages of text and Talk pages aren't content. ~ Amory (utc) 00:42, 16 June 2018 (UTC)
Thanks, yes, as we have similar text content (in talk pages and discussions) with additional functionalites, we can simply extend the interface for other text contents as simply we can re-use the API and add new functionalities for this. :) Shevonsilva (talk) 06:35, 16 June 2018 (UTC)
If you think that it's simple, then you try to do it; and on no account may you break existing functionality (broadly construed). It will also be your responsibility to explain why you have done this against consensus. --Redrose64 🌹 (talk) 09:01, 16 June 2018 (UTC)
Thanks, yes. I have to properly analyse the set of new sub-features. Will see how it goes. :) Shevonsilva (talk) 17:25, 16 June 2018 (UTC)

@Shevonsilva: I'm definitely of the opinion that the current setup of talk pages is not very good, and I think it's great that you want to help with that! The problem is, talk and discussion pages have a large array of disparate functions, and designing a solution for all of them simultaneously is very hard. The visual editor is designed to edit content pages, and modifying it so that it serves the two totally different needs will end up meaning it serves neither of the functions well. To be totally honest, I think your efforts would be better focused in a different space; if you're interested in MediaWiki development, then more help is always welcome, and I can absolutely point you to places where you could help out. --Deskana (WMF) (talk) 23:00, 16 June 2018 (UTC)

@Deskana (WMF):That is great. What is the best way to contact you? Shevonsilva (talk) 00:28, 19 June 2018 (UTC)
Shevonsilva, I recommend leaving a message for him at mw:User talk:Deskana (WMF).
Also, anyone who is interested in contributing to the movement in a technical capacity may want to read mw:How to become a MediaWiki hacker. Whatamidoing (WMF) (talk) 15:20, 21 June 2018 (UTC)

Little blue arrows in diffs

I this diff I notice a little blue arrow next to Charlie Waite. Is this new? DuncanHill (talk) 19:24, 15 June 2018 (UTC)

Yes, see m:Tech/News/2018/22#Changes later this week Nthep (talk) 19:36, 15 June 2018 (UTC)
Thank you, looks helpful. DuncanHill (talk) 19:39, 15 June 2018 (UTC)
Looks backward to me. Arrow pointing away from the text should mean removal, pointing toward the text should indicate insertion. After a couple of weeks of trying to comprehend the rationale, it still seems counter-intuitive. ―Mandruss  22:47, 18 June 2018 (UTC)

Minor bug in text message for pending changes

When looking at an article with unreviewed pending changes (for example: List of video game developers), the message on top says:

The latest accepted revision was accepted on 9 June 2018. There are template/file revisions awaiting review.

The "template/file revisions" part doesn't fit for an article. Not really a big issue, but the message text should be fixed/tweaked. I am a pending changes reviewer using Vector skin, and have clicked a "Pending changes" tab on top of the article to see the above message. If i remember correctly, the message was different a few days ago and probably has changed recently. GermanJoe (talk) 21:05, 15 June 2018 (UTC)

It has been reviewed now but I saw your quote before the review. Mediawiki used MediaWiki:Revreview-newest-basic-i instead of MediaWiki:Revreview-newest-basic. I don't know why. The edit pending review was [14] which added a link in a table cell. All eight pages currently at Special:PendingChanges use MediaWiki:Revreview-newest-basic without -i, e.g. Jordan Belfort. translatewiki:MediaWiki:Revreview-newest-basic-i/qqq says about the -i message: 'Shown when viewing the latest version of a "checked" page with only template or file changes pending review'. translatewiki:MediaWiki:Revreview-newest-basic/qqq without -i says: 'Shown when viewing a the latest version of a "checked" page with pending changes.' PrimeHunter (talk) 21:29, 15 June 2018 (UTC)
I examined the 20 pages currently at Special:PendingChanges. 19 of them used MediaWiki:Revreview-newest-basic. The last correctly used MediaWiki:Revreview-newest-basic-i for this edit which only makes changes to a template call. Maybe the software mistook the originally reported edit [15] for a template change due to the similar pipe syntax in templates and tables. Another thing is that the default MediaWiki:Revreview-newest-basic-i/qqx says "Template/file changes" while our customized MediaWiki:Revreview-newest-basic-i says "template/file revisions". The latter sounds like edits to a template page and not like changes to a template call in an article. I suggest we say "template/file changes" like the default. PrimeHunter (talk) 09:46, 16 June 2018 (UTC)
Agree. "Changes" would be slightly clearer in this context, when the message is supposed to refer to template and file changes within an article. Thank you for looking into this. GermanJoe (talk) 10:17, 16 June 2018 (UTC)
I made the change.[16] PrimeHunter (talk) 19:20, 18 June 2018 (UTC)

Cross Lang Conflicts

Moved to User:Xinbenlv/Cross_Lang_Conflict_Examples § Comments: As per suggested by @Mathglot. Xinbenlv (talk) 23:17, 20 June 2018 (UTC)

Dear techy Wikipedians,

I am I am experimenting with using programming way to find cross-language fact conflicts in large scale. Here is a small sample of data I was able to produce for now. I like to ask for some early feedback. Do you think these data would be useful, if yes, can you think of any usecase? If not, what other information can I include to make it more useful?

Please leave comments here.

For now I plan to produce EN v FR, EN v DE. I post related data to the related Wikipedias too.

  • fr:Utilisateur:Xinbenlv/Exemples_de_conflits_croisés
  • de:Benutzer:Xinbenlv/Beispiele_für_Langanguage-Konflikte

Xinbenlv (talk) 22:43, 15 June 2018 (UTC)

The sample data.
  • EN v FR: birthdays
FirstSource FirstLang FirstValue SecondValue SecondLang SecondSource en 1980-08-23 1980-08-22 fr en 1966-05-20 1966-11-14 fr en 1967-08-07 1967-08-09 fr en 1980-10-31 1982-02-07 fr en 1962-02-05 1962-03-24 fr en 1942-11-09 1942-12-06 fr en 1988-02-19 1988-02-18 fr en 1880-02-14 1880-02-17 fr en 1962-08-10 1962-04-10 fr en 1950-08-27 1951-08-27 fr en 1994-03-12 1994-02-09 fr en 1968-09-20 1969-09-20 fr en 1993-07-31 1993-01-31 fr en 1964-03-03 1964-03-04 fr en 1983-07-26 1983-07-20 fr en 1925-06-18 1925-06-08 fr en 1897-03-31 1887-03-31 fr en 1996-04-16 1995-04-16 fr en 1954-08-19 1956-08-19 fr en 1934-04-13 1933-04-13 fr
  • EN v DE birthdays
URL1 code1 birthday1(geburtstag


birthday(geburtstag2) code2 URL2 en 1979-08-23 1979-08-29 de en 1992-09-17 1995-09-17 de en 1917-01-30 1917-06-30 de en 1993-03-15 1993-05-13 de en 1983-12-18 1983-02-16 de en 1945-03-28 1948-03-28 de en 1984-04-11 1980-11-04 de en 1966-03-22 1966-03-02 de en 1995-02-09 1993-12-23 de en 1943-01-17 1943-01-27 de en 1893-06-26 1895-06-26 de en 1928-06-21 1928-01-21 de en 1947-03-02 1947-03-03 de en 1984-08-07 1984-07-08 de en 1983-08-23 1983-08-02 de en 1930-10-21 1930-11-21 de en 1975-06-11 1975-06-14 de en 1985-02-23 1985-02-25 de en 1963-06-04 1963-01-04 de en 1896-03-02 1895-03-02 de
This looks like it can be really useful for fixing Wikidata errors. How do you extract the information? Can you show us the code? Roger (Dodger67) (talk) 23:11, 15 June 2018 (UTC)
Hi @Dodger67, Thanks for your encouragement. On a high-level, the steps are: (1) extract facts from a Wikipedia Article. (2) compare the information that should have a unique value (e.g. a personal can only be born once) across languages. (3)turn this comparison into a Map-Reduce-like large scale pipeline. (4) filter the conflicting data with constraints. Not all technologies I used are open-sourced yet, so I still need sometime to get the code to a status of release-able. Other comments, thoughts? I wonder if people will also think it helpful to fix facts on Wikipedia, too? Xinbenlv (talk) 23:31, 15 June 2018 (UTC)
Seeking more comments Xinbenlv (talk) 01:58, 17 June 2018 (UTC)
Xinbenlv, have you asked over at d:Wikidata:Project chat? I think this would be very useful to Wikidata editors (probably much more than Wikipedia editors), as information is routinely imported from smaller projects like the Russian Wikipedia, which might not have data as good as the English Wikipedia's. There are also probably more editors who are used to querying databases, and there are some tools (with a GUI) which I think can import entire infoboxes from groups of articles. Jc86035 (talk) 09:05, 17 June 2018 (UTC)
@Jc86035, sounds good, I haven't but will do! thanks! ! Xinbenlv (talk) 15:48, 17 June 2018 (UTC)
Continue to seek comments Xinbenlv (talk) 02:31, 19 June 2018 (UTC)
@Xinbenlv: Great idea. The first thing to do imho, is to find a stable home for this. VPT is a fast-moving page and this discussion will either get archived and lost, or get too big to live here. In any case, may I suggest finding a new home for it, and moving this discussion there? Ideally for starters, your data, examples and technical material could live on a new Project page, with this discussion moved to the Talk page associated with it. I can offer some suggestions if you like. Mathglot (talk) 03:21, 19 June 2018 (UTC)

Underlines not being removed when linking to an anchor using built-in feature

Not really an actual problem, but just trying to figure out why. Internal links look like this: [[User talk:Amaury#Discussion Archives|My Archives]] However, if I use the built-in link feature to make that a link semi-automatically, the underlines aren't removed for some reason: [[User_talk:Amaury#Discussion_Archives|My Archives]]. Why are the underlines not being removed? Here's a quick step-by-step. [17] and [18]. Clicking Internal Link does not remove the underlines. Amaury (talk | contribs) 01:06, 16 June 2018 (UTC)

The images are from a feature on the chain icon in the default toolbar. I never use it but the url to page name conversion seems very limited. It cannot handle percent encoded url's like for Téa Leoni. I guess the feature was created to make either external links, or wikilinks where the user enters the page name. The conversion option looks like an afterthought with primitive implementation which just removes PrimeHunter (talk) 09:58, 16 June 2018 (UTC)

Editor not redirecting to a display URL after completing

[I'm guessing that this has already been reported, but I don't see it in the contents list, and I can't think what to search for]. I'm frequently finding when I edit a section (generally on WP:HD or WP:TH) after I complete and save, the URL still has "?action=edit" in it - i.e. it is not following normal practice and redirecting to a GET URL after completing.

I started noticing this a couple of weeks ago, when refreshing a page (F5) kept putting me into the editor unexpectedly; but I only remembered to look at the URL a few days ago. I have an example in another tab right now: I have just replied to a question at the Teahouse, and the edit has saved, but the URL in my browser address bar is

I'm using Firefox, but I'm pretty sure I saw this in Opera recently as well. --ColinFine (talk) 10:35, 16 June 2018 (UTC)

What editor are you using? 2017 Wikitext editor? Visual Editor? Another? --Izno (talk) 13:31, 16 June 2018 (UTC)
Dunno, Izno. Looking at my preferences, I have "Always give me the source editor" checked, and "New WikiText Mode" checked on the Beta Features tab. --ColinFine (talk) 23:14, 16 June 2018 (UTC)
Okay, you're using the 2017 wikitext editor. I see this behavior also in Firefox (have for a while) and it probably deserves a task in Phabricator. I don't see one there. I think we need figure out the exacts of when it happens still. --Izno (talk) 13:04, 17 June 2018 (UTC)
@Izno: I think what happens is the page "reloads" with JavaScript and then doesn't change the URL in the address bar. I haven't tested this with VisualEditor. Jc86035 (talk) 11:21, 18 June 2018 (UTC)
I'll just confirm that I also have this issue in Firefox with the 2017 editor. Haven't noticed it in Edge (at work) though. — AfroThundr (u · t · c) 12:04, 18 June 2018 (UTC)
I take that back, Edge is doing the same thing. What's more, sometimes the post-edit URL isn't even the same page I was on; it changes the page URL to 'undefined' like so: This would cause me to edit the page for Undefined if I refresh the page after editing. I've gotten used to clicking on the article or talk tab again to put the correct URL back in the bar. Has anyone opened a phabricator ticket for this yet? — AfroThundr (u · t · c) 12:08, 18 June 2018 (UTC)
I've just opened one. Jc86035 (talk) 16:37, 18 June 2018 (UTC)

WikEd now inserts div tags all over

Hi, WikEd is still giving trouble, but of a different kind from a week or two ago. Then, it was inserting numerous blank lines, creating havoc with list formatting. Now, it closes things up but too vigorously; if one tries to insert blank lines, the result is often paired <div></div> tags instead. This diff illustrates the thing that I mean. It is a new effect not seen until recently. Hope it can be fixed soon. All the best, Chiswick Chap (talk) 14:26, 16 June 2018 (UTC)

This is very annoying indeed. Headbomb {t · c · p · b} 14:39, 16 June 2018 (UTC)
I can't seem to replicate this - does it happen when inserting blank lines under any circumstances? ƒirefly ( t · c · who? ) 22:27, 16 June 2018 (UTC)
What browsers, browser version, operating systems, and skins are ya'll using? --Izno (talk) 12:53, 17 June 2018 (UTC)
Firefox (most recent version), Win10 64 bit, Monobook. Problem seems to be related to find/replaces with WikiEd, but that could be a coincidence. Headbomb {t · c · p · b} 01:16, 18 June 2018 (UTC)

br after template

Using a template inside an article sometimes the next line goes to a new paragraph. It like there is a <br>. Any solution. Xaris333 (talk) 16:02, 16 June 2018 (UTC)

That is usually because the template has a newline at the end of the output. The solution is to remove the newline from the template, e.g. by starting a noinclude part on the same line as the last template output, but you didn't name any template so we cannot examine your situation. PrimeHunter (talk) 18:59, 16 June 2018 (UTC)
@Xaris333: Or even an article where it is happening. Examples almost always help on VPT. --Redrose64 🌹 (talk) 21:45, 16 June 2018 (UTC)
Problem solved. Thanks. Xaris333 (talk) 16:56, 17 June 2018 (UTC)

Tool for mass redirects?

Based on Wikipedia:Articles for deletion/WNG560, I want to redirect a couple hundred articles to NOAA Weather Radio. I did the first batch by opening a bunch of browser tabs and having a copy-pasting. That got old fast. I could write something that goes through the API to automate this, but that's almost more effort than it's worth (and would probably require bot approval). Is there some existing tool to automate the rest of these? -- RoySmith (talk) 22:02, 16 June 2018 (UTC)

  • WP:AWB? Galobtter (pingó mió) 22:05, 16 June 2018 (UTC)
  • AWB is absolutely the way to go - ping me if you want a hand with doing them. ƒirefly ( t · c · who? ) 22:16, 16 June 2018 (UTC)
  • Ah, cool. Yeah, that looks like exactly what I need, thanks. RTFM-ing now. -- RoySmith (talk) 22:20, 16 June 2018 (UTC)
    • Oh, wait. Runs on windows only? Really??? That's like a non-starter for me. -- RoySmith (talk) 22:28, 16 June 2018 (UTC)
      • You can use WP:JWB Galobtter (pingó mió) 22:30, 16 June 2018 (UTC)
        • OK, that's working fine (once I figured out I needed the "s" regex flag). Thanks again. -- RoySmith (talk) 23:11, 16 June 2018 (UTC)

Pending changes reviews and edit summaries

Is anyone aware if there has been a Phabricator ticket yet to address the issue of the UI for inserting an edit summary when rejecting pending changes does not yet allow reviewers to make use of the new maximum character limit for edit summaries? For reviewers reverting just one edit or those of us with rollback rights, there are workarounds to this, but for the average reviewer trying to disentangle multiple vandalism edits or mixed constructive and non-constructive edits, this is a challenge, as the edit summary is the best way to unpack these details in a way which novice editors trying to make changes are most likely see. Indeed, I was more excited for the increased edit summary cap in the context of pending changes reviews than any other single area of maintenance--until I realized the UI was not yet on the same page. Indeed, I think the pending changes process needs an overhaul from top to bottom, but this would a be a good start. I attempted a search in the Fabricator archives, but I go there so infrequently, I am not sure I am using the search functions exhaustively. Has anyone seen this come up anywhere in recent months? Snow let's rap 22:39, 16 June 2018 (UTC)

@Snow Rise: Maybe I'm not understanding quite what you're describing, but I just reverted my own pending change using Twinkle and was able to type a long edit summary. Is that a work-around? Home Lander (talk) 01:24, 17 June 2018 (UTC)
Hi @Home Lander: thanks much for the response and for the head's up about Twinkle; I'll add that to the toolbox of workarounds! To be honest, I've already figured out a few means of sidestepping the limitations of the UI in most circumstances, but I still think a request into Phabricator to cure the UI limitations would be useful, if there is no previous ticket; aside from streamlining the process, there's an argument to be made for this on the basis that some novice reviewers who do not use Twinkle may be unaware that there is any workaround. And as I say, PC reviews often require more complicated edit summaries than just about any other quasi-administrative task. Snow let's rap 02:41, 17 June 2018 (UTC)
The task to watch is phab:T194588. --Izno (talk) 13:09, 17 June 2018 (UTC)
Ah, much obliged! I figured someone must have gotten there ahead of me. Snow let's rap 21:26, 17 June 2018 (UTC)

Indenting ":" doesn't work to right of image: should it?

Please see this edit.

The reason I changed the indenting ":" to a bulleting "*" is that the indent didn't work for me. My paragraph appeared directly below the original question (to the right of the image, because I'm using a wide window) without indentation. I tried multiple colons up to ":::::" and there was still no indentation. After making the change I also tried adding another paragraph with "**" and this was formatted just like the "*" paragaph.

However, if I narrow the window so that the original text occupies more lines and comes down below the picture, then indentation in the later text works correctly. So clearly what's going on is that ":" doesn't indent (and "*" doesn't add indenting) in text that's to the right of an image.

Is this a bug or a documented feature?

(Please reply here, not to my current IP address's talk page.)

-- (talk) 22:12, 17 June 2018 (UTC)

Left-floating images are often problematic. Indentation is measured from the left margin and not from the edge of the image. If there is enough indentation then it eventually leaves the image. Below are examples but don't try that. The result will vary between users. You can just make the image right-floating. That is default for |thumb so you don't have to write anything. PrimeHunter (talk) 22:41, 17 June 2018 (UTC)
20 colons (before image)
Image with |thumb|left

No indentation in this line

  • 1 asterisk
            • 5 asterisks
1 colon
5 colons
20 colons
@ and PrimeHunter: You can fix this by surrounding the text with <div class="flowlist">...</div>. See Special:Diff/846413082 for an example. --Ahecht (TALK
) 16:32, 18 June 2018 (UTC)

Image upright went wrong

Pls see fluorine & talk. My "upright" (image) went wrong, but i am mobile now so cannot revert myself. -DePiep (talk) 22:41, 17 June 2018 (UTC)

I have reverted your edit.[19] Wikipedia:Extended image syntax#Using "upright" says: "The upright option works in combination with the thumbnail or thumb option". PrimeHunter (talk) 22:49, 17 June 2018 (UTC)
ok. -DePiep (talk) 23:21, 17 June 2018 (UTC)
It also works with |frameless. I gave a fuller answer at the original thread. --Redrose64 🌹 (talk) 19:03, 18 June 2018 (UTC)

Left hand column with menu (Main page, contents, languages etc) showing while in edit field stopping me from saving

And they're clickable and across the publish changes button. Luckily hitting return in the edit summary field works as I can't use the publish button. This is even worse than the occasional file image overlaying the corner of the edit window. This seems to be Firefox problem as I don't have it in Chrome. On the other hand when I start a new section I can't save at all, so I had to switch to Chrome in he miffle of writing this. I'm using Vector. Doug Weller talk 11:17, 18 June 2018 (UTC)

I have Firefox and Vector with no problems. Your Firefox cache of interface files may be corrupted. Try to bypass your cache with Ctrl+F5, or clear your entire cache. PrimeHunter (talk) 11:39, 18 June 2018 (UTC)
@PrimeHunter: Thanks, but that had no effect. I rebooted FF as well. Doug Weller talk 12:42, 18 June 2018 (UTC)
Does it happen with safemode=1 or if you log out? PrimeHunter (talk) 14:33, 18 June 2018 (UTC)
@PrimeHunter: It doesn't seem FF related after all, it's WikEd related - it only happens when WikEd is turned on, and Chrome doesn't have it turned on. Turning it off in FF fixes the problem. Doug Weller talk 14:38, 18 June 2018 (UTC)
But only sometimes. And in any case, I don't get the templates box when I use wikEd, I should get it with both. On another page just now I couldn't even change between them. Doug Weller talk 18:28, 18 June 2018 (UTC)
Alt+⇧ Shift+s should save in Firefox. More at Wikipedia:Keyboard shortcuts. I see you posted to User talk:Cacycle/wikEd where bug reports belong, but you didn't follow User talk:Cacycle/wikEd#wikEd Bug reports. Cacycle hasn't edited since February so I don't know whether you will get a reply. PrimeHunter (talk) 19:15, 18 June 2018 (UTC)

Vocea României Junior (season 2)

Hello, can someone edit this page? I tried my best, but it isn't complete. --Monsterofain (talk) 14:10, 18 June 2018 (UTC)

I do not see any technical problems with this page. It has at least two links to disambiguation pages; those should be fixed. I added a References section with a {{reflist}} template. – Jonesey95 (talk) 14:19, 18 June 2018 (UTC)

Small spacing issue with new watchlist filters UI

With the New Filters for Edit Review feature enabled, there's now not enough space above announcements on the watchlist page when using the Vector skin. Here's a screenshot of the old (top) and new (bottom) designs – since the view/edit/clear links got moved in the new design, the annoucement is too close to the page title. (I'm using Chrome 68, in case that's relevant.)

Hopefully this is the right place to report things like this? I mentioned it on the feature's talk page on MW, and got asked to report it on enwiki. An Owl Called Josh 🦉 (talk) 14:22, 18 June 2018 (UTC)

I've offered a possible fix here: add .mw-rcfilters-enabled .mw-specialpage-summary {margin: 1em 0;} to Mediawiki:Commons.css. Trizek (WMF) (talk) 15:56, 18 June 2018 (UTC)
Done with Special:Diff/846412391. I used padding instead of margin, because it would otherwise overlap with the margin of .firstHeading. Merely a minor nitpick =p I assume all wikis have the same issue, so maybe this CSS change should be added to core or wherever the code for the new review filters lives? MusikAnimal talk 16:34, 18 June 2018 (UTC)
Only wikis using the watchlist header to display messages have that, MusikAnimal. Maybe that related ticket would be a good opportunity to express that. :) Trizek (WMF) (talk) 19:05, 18 June 2018 (UTC)

Tech News: 2018-25

21:47, 18 June 2018 (UTC)

Thing to help add incoming links to an article

I seem to remember using some kind of tool that helped to add incoming links to an article. You fed in the article name, it pulled up articles with corresponding text, and added the links very quickly. Can't for the life of me remember what it was called, can anyone point me in the right direction please? DuncanHill (talk) 21:48, 18 June 2018 (UTC)

User:Lourdes/Backlinks searches articles but doesn't help add the link. PrimeHunter (talk) 23:39, 18 June 2018 (UTC)
@DuncanHill: Find link is the tool provided on {{orphan}}. Is that what you were thinking of? NotARabbit (talk) 04:19, 19 June 2018 (UTC)
@DuncanHill: Just using Advanced search in the Article namespace alone does a pretty nifty job, especially if you use Boolean OR to capture possible aliases. Mathglot (talk) 08:24, 19 June 2018 (UTC)
I have a Google search box which I use. The tool I remember was a bit like Find Link, but Find Link doesn't actually open up the edit box and insert the link ready for you to click Publish, which the tool I remember did. DuncanHill (talk) 11:16, 19 June 2018 (UTC)
You can use the search and replace option of AutoWikiBrowser. You can ask someone to do it at Wikipedia:AutoWikiBrowser/Tasks if you don't have access.--Racklever (talk) 13:10, 19 June 2018 (UTC)

Template magic question

Is there a way to make a uw template automatically show different text for anonymous vs registered users, or based on a user's permissions? Specifically, the text at {{uw-incompleteAFD}} has a section about unregistered users, but I most commonly use it for registered users. ansh666 06:51, 19 June 2018 (UTC)

Wrap it in spans with class .anonymous-show or .user-show. For example, this sentence is only shown to registered users.For example, this sentence is only shown to unregistered users. There's similar classes for most user groups; look for .sysop-show in MediaWiki:Common.css. —Cryptic 07:17, 19 June 2018 (UTC)
In this case, wouldn't it be easier to check if the user whose talk page the template is being placed on is an IP or not and subst accordingly? {{3x|p}}ery (talk) 16:05, 19 June 2018 (UTC)
Yes, but I'm lazy (and it's probably better to just have one template for everyone anyways). Thanks, I'll look into it. ansh666 20:19, 19 June 2018 (UTC)
@Ansh666: Note that if you're substing the template (which you really should for anything going on a user talk page), the CSS "hidden" text will still show up in the wikitext editor. A better way would be {{{{{|safesubst:}}}#if:{{IsIPAddress|{{ROOTPAGENAME}}}}|Text for unregistered|Text for registered}} --Ahecht (TALK
) 22:38, 19 June 2018 (UTC)
Yeah, Pppery fixed it up. Thanks, ansh666 22:42, 19 June 2018 (UTC)
Apart from the user interface and omitting some things in the mobile version, we should very rarely show different text to different users. It causes confusion when they edit or discuss the same page, and registered users should be able to see what an IP was told in a warning. Testing the type of user page to display specific content to all readers of the page is fine. PrimeHunter (talk) 22:51, 19 June 2018 (UTC)

Problem with Cyberbot I

There is an issue with the Cyberbot I (BRFA · contribs · actions log · block log · flag log · user rights) task which creates and populates Template:Adminstats subpages for administrators and account creators. It's creating and re-creating adminstats subpages for users who are neither administrators nor account creators and which have been deleted multiple times after discussions at TfD, and also seems to be creating and re-creating adminstats subpages for certain users who have not requested the bot to run. I've already posted on Cyberpower678's talk page, but if anyone more active in bot coding would like to take a look or weigh in, please see the discussion. Thanks. Ivanvector (Talk/Edits) 12:32, 19 June 2018 (UTC)

Template to fetch data from Wikidata

Hello. I am most active in Greek Wikipedia and in Wikidata. Recently, I have added all population history for municipalities and communities for Limassol District in Wikidata. Through a template w:el:Πρότυπο:Πληθυσμός απογραφών Κύπρου, all the data of a place is showing in Greek Wikipedia article of the place, with all the sources. For example, w:el:Πελένδρι#Πληθυσμός. Noticed, that most of the sources are in English and if some of them are in Greek, in Wikidata I have added also the translated titles etc. The problem is that I want to add these informations to English Wikipedia article with the same way, with the template. It's more easier and effective, than try to write them by hand. The problem is that Module:Wikidata and Template:Wikidata are different in each Wikipedia and I need help to create the template W:el:Πρότυπο:Πληθυσμός απογραφών Κύπρου to English Wikipedia. Xaris333 (talk) 13:07, 19 June 2018 (UTC)

The English Wikipedia has plenty of Wikidata templates (Template:Wikidata, Module:Wikidata, Module:WikidataIB). It does not need more. {{3x|p}}ery (talk) 16:06, 19 June 2018 (UTC)
No, I am not telling that. I need help to create my template to English Wikipedia according to Wikidata templates of English Wikipedia. Xaris333 (talk) 16:07, 19 June 2018 (UTC)

I just want to make Template:Population history Cyprus working. Xaris333 (talk) 19:04, 19 June 2018 (UTC)

If you have a technical question about how to make the template work, then you might consider contacting one of the Wikipedia:WikiProject Wikidata#Participants directly. Whatamidoing (WMF) (talk) 15:25, 21 June 2018 (UTC)

Help at WT:CS1

Since the main coder for WP:CS1 templates (Trappist the monk (talk)) is unresponsive, it would be great to have Lua coders to help with long-standing requests

Any help would be greatly appreciated here. Headbomb {t · c · p · b} 14:35, 19 June 2018 (UTC)

Looking for a gadget crafter

One thing which could help to improve article readability is a gadget that would highlight an article's longest sentence and the one with the most punctuation marks. By this simple expedient we could draw editors' attention to where it is most needed. Would anyone be interested in crafting such a tool? Pretty please? LeadSongDog come howl! 17:12, 19 June 2018 (UTC)

That looks like it would be a useful tool. · · · Peter (Southwood) (talk): 19:44, 19 June 2018 (UTC)

MiniveraNeue error messages

Just some time ago I experienced difficulties saving an edit to Wikipedia:Articles for deletion/Vandana Singh (actress) on the Minivera skin... At first the screen just redirected me back to the save form...after scrolling downwards a poorly rendered (It overlapped with my signature) black error message stating something in the effect of "Error:Your edit could not be saved." appeared. After further investigation (in the process of which I lost the source of the edit) I discovered that I had accidentally included a Accelerated_Mobile_Pages link instead of a link to the actual site. This had caused the mw:Extension:SpamBlacklist to blocked it. Can the aforementioned extension's error messages be made compatible with MiniverNeue?— Preceding unsigned comment added by FR30799386 (talkcontribs) 10:26, 20 June 2018 (UTC)

I think this is a known issue. Linked —TheDJ (talkcontribs) 14:17, 20 June 2018 (UTC)

Load different editor toolbars via user js?

I'm trying to figure out how to override my preferences and load different editing toolbars (enhanced in main, old elsewhere, and code editor if page ends in .js or .css). I thought mw.user.options.set would work, but I seem to be calling it too late to make a difference. The options API directly changes the preferences (so requires an API call on every page and a page reload) so what I'd really like to do is directly load the enhanced or old toolbar directly in userjs, but how? ~ Amory (utc) 14:43, 20 June 2018 (UTC)

If "old" means the 2006 wikitext editor (see mw:Editor to figure it out), then it's probably going to be removed from the servers later this year (a long-stalled project that supposedly is back on track now).
That said, I believe that the French Wikipedia has an 2006-like toolbar that is entirely handled in user Javascript (a gadget), so perhaps what you need is enhanced in main, and "nothing" (2003) elsewhere, except to then replace nothing with a user script that happens to duplicate the 2006 toolbar. Whatamidoing (WMF) (talk) 15:31, 21 June 2018 (UTC)
@Whatamidoing (WMF): Thanks, that's it in a nutshell I suppose. I'll be sad to see my old friend go, but being the change-averse community we know it is, I expect I'll find it in a gadget soon after. Face-wink.svg If I opt for "nothing" in my preferences, is there a way to load the enhanced editor via javascript? I suppose the alternative is to actually opt for the enhanced toolbar in the preferences and do $('#wikiEditor-ui-toolbar').hide() everywhere but main and js pages, but that'd be more inefficient. ~ Amory (utc) 19:31, 21 June 2018 (UTC)
I understand that the teams affected would have no objection to the 2006 toolbar being re-created as a gadget (whether now or later). I understand their problem is strictly about whether the dozen-year-old code remains officially supported as part of MediaWiki. If volunteers choose to keep it alive as a gadget for another dozen years, that's no skin off the devs' backs. I wouldn't be surprised if some of them chose to use such a gadget themselves.
I'll leave your questions about how to do that to someone who is more likely to give you useful answers. ;-) Whatamidoing (WMF) (talk) 19:59, 21 June 2018 (UTC)
Didn't mean to suggest they shouldn't! Just some poking fun at myself and our editor colleagues. ~ Amory (utc) 20:10, 21 June 2018 (UTC)

Creating taskforces of WikiProject, getting assessment stats etc

Hi all, I'd previously asked this question over at the Teahouse and was pointed in this direction, hopefully someone here will be able to help!

I've started setting up taskforces for WikiProject Computational Biology, for regulatory and systems genomics and computational biology education so far: I've added a single article to each taskforce just to check that my modifications to the WCB template were successful, more articles will be added in due course.

The WP:USMIL task force cited in the taskforce examples suggests that it should be possible to get separate assessment statistics for each taskforce, I assume as a subset of the assessment statistics for the parent WikiProject - is this correct? And if so, what do I need to do in order to create the assessment statistics tables? I've attempted to update the project data for RegSys as a test, but the assessment tool says that RegSys is not in the database. I get the feeling I'm missing something quite basic, any help appreciated. Thanks! Amkilpatrick (talk) 18:26, 20 June 2018 (UTC)

@Amkilpatrick: This should be covered by Wikipedia:Version 1.0 Editorial Team/Using the bot. --Redrose64 🌹 (talk) 18:55, 20 June 2018 (UTC)
@Redrose64: not sure how I missed this, will check it out. Thanks! Amkilpatrick (talk) 19:26, 20 June 2018 (UTC)

Uploading problem

I'm having trouble getting an image to upload to - I keep getting a 400 Bad Request error. Anybody know if there's a server problem or something? Parsecboy (talk) 10:17, 21 June 2018 (UTC)

Nevermind, I got it to go through - must have been a temporary hiccup. Parsecboy (talk) 11:36, 21 June 2018 (UTC)

Watchlist options

The Watchlist option (period to display, hide various types of user, minor edits, etc) have disappeared from my watchlist on my desktop. They are still there on my phone. Monobook on both, Edge on Win10 on the desktop, Chrome on Android and desktop view on the phone. DuncanHill (talk) 11:20, 21 June 2018 (UTC)

@DuncanHill: check m:Edit_Review_Improvements/New_filters_for_edit_review#Project_updates it could be something to do with that. Nthep (talk) 12:10, 21 June 2018 (UTC)
That page has been deleted as vandalism. DuncanHill (talk) 12:15, 21 June 2018 (UTC)
Sorry, missed a character out, I meant this page at mediawiki mw:Edit_Review_Improvements/New_filters_for_edit_review#Project_updates. Nthep (talk) 12:18, 21 June 2018 (UTC)
Thanks. Bizarrely they have now reappeared on my desktop without me changing anything. DuncanHill (talk) 12:23, 21 June 2018 (UTC)
No deployment has happen for now concerning the watchlists, Nthep. :)
DuncanHill, are you using the Beta feature "New filters for edit review"? Trizek (WMF) (talk) 14:19, 21 June 2018 (UTC)
No, I do not use any Beta features. DuncanHill (talk) 14:28, 21 June 2018 (UTC)
Do you still have your problem when you use safemode? Trizek (WMF) (talk) 14:30, 21 June 2018 (UTC)
No, as I said they have reappeared. DuncanHill (talk) 14:35, 21 June 2018 (UTC)
If you don't have the issue using the safemode link, the problem may be related to your account settings. Can you please follow the steps for a bug report? Thanks! Trizek (WMF) (talk) 15:12, 21 June 2018 (UTC)


RfC: Deletion of drafts

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is a consensus to enact the changes as proposed. Some of the opposition are concerned that this proposal creates a "three strikes" rule for submitted drafts, but the language of the new text does not give a hard number; draft reviewers are encouraged to take heed of the "without any substantial improvement" clause and not nominate simply based on decline count.

As a note, none of the sub-proposals made gained any traction or significant support. Primefac (talk) 19:50, 10 June 2018 (UTC)

The deletion of drafts via MfD was previously discussed over two years ago in this RfC that concluded that drafts should not be subject to the notability criteria, but that there may be other valid reasons for the deletions of drafts. Reading the comments of the RfC and the close, there also seemed to be agreement that drafts should be works in progress, eventually expected to meet mainspace standards. Currently, it is possible to continually resubmit a declined draft to AfC with no changes while not meeting any of the CSD criteria or failing WP:NOTWEBHOST and effectively stay in draft space forever. This has caused some back and forth at MfD as what to do with these articles. To help provide clarity for this situation, I am proposing WP:NMFD be modified to read the following (updated text in red):

Drafts are not subject to article deletion criteria like "no context" or no indication of notability so creators may have time to establish notability. Drafts may be nominated for deletion at Wikipedia:Miscellany for deletion, but not solely based upon a concern about notability. A draft that has been repeatedly resubmitted and declined at AfC without any substantial improvement may be deleted at Wikipedia:Miscellany for deletion if consensus determines that it is unlikely to ever meet the requirements for mainspace and it otherwise meets one of the reasons for deletion outlined in Wikipedia:Deletion policy.

TonyBallioni (talk) 18:39, 11 May 2018 (UTC)

Drafts RfC Survey

  • Support as proposer as it will clarify what has de facto become a delete reason at MfD, deal with cases that will never be G13 or G11 eligible but also have no chance of ever becoming an article, and also provides protection to drafts so that they are still not eligible solely because of notability and requires that they be given more time to develop. This also has the potential to lighten the load on MfD because it would set the standard as repeated resubmissions (read 3 or more times) and would leave the others alone to develop or meet G13. I think this wording is a good way of splitting the baby of protecting drafts from overeager while remembering that at the end of the day, we are ultimately an encyclopedia first and foremost, and that the end goal of the draft space is to build that encyclopedia. Content that doesn't have a chance of meeting that goal shouldn't be kept. TonyBallioni (talk) 18:39, 11 May 2018 (UTC)
  • Support. Drafts that are tendentiously resubmitted without improvement are an unnecessary waste of volunteer time and should be deleted. Some submitters evidently have difficulty in understanding the word "no" (let alone "encyclopedia"). Deletion makes that message clear. I'd like to see some article CSDs (A11 in particular) apply to submitted drafts, as the act of submission indicates that the submitter believes their draft should be treated as an article. MER-C 18:54, 11 May 2018 (UTC)
    • User:MER-C, the resubmitters are never told “no”. Have a look at some. —SmokeyJoe (talk) 22:04, 11 May 2018 (UTC)
      • In some sense, yes -- I strongly agree with you that we waste far too much time sending the wrong message to and accommodating those who aren't here to improve Wikipedia. But having a draft declined stating that further improvement is necessary and not doing that before resubmitting is still failing to understand a very simple concept. MER-C 11:57, 12 May 2018 (UTC)
  • Support per Mer-C & Tony but is not strong enough. I like Robert's idea of A7 for draft articles.-- Dlohcierekim (talk) 19:00, 11 May 2018 (UTC)
  • Oppose As I noted at AN before the thread was closed, resubmitting a draft multiple times is a conduct issue not a content issue and should be handled by sactioning the user in question instead. Once the user has been banned/blocked, the problem posed by the RFC is solved. This proposal would allow a single editor to decline a draft three times and then nominate it for MFD for being declined three times, effectively circumventing the whole reason why we have Draft-space in the first place (which is also why I strongly oppose any attempts to expand A7 to drafts). Regards SoWhy 19:02, 11 May 2018 (UTC)
    SoWhy I would be in complete agreement, except Tony has inserted the phrase "without any substantial improvement". If there is question about what "substantial improvement" here constitutes, an per-case discussion happens at MfD. This is not a "Speedy" process, although I also think there should be such a process for egregious cases. 78.26 (spin me / revolutions) 19:07, 11 May 2018 (UTC)
    I just don't see it as solely a conduct issue. The reason why a draft may be repeatedly declined is because the subject simply isn't suitable for an encyclopedia and has no foreseeable chance at becoming suitable in the future (WP:OVERCOME); that's a valid content issue, if I did hear one. Although it might work, the problem I see with treating it as a behavioral problem is WP:BITE. Threatening to block should be a last resort, and I see deletion as the neatest solution that saves the most time and doesn't unnecessarily personalize the issue for new editors. Mz7 (talk) 00:30, 12 May 2018 (UTC)
    How does deletion stop a user from recreating the same page? BITE problems are a big reason why I don't favor deletion of drafts at all (I see it as a fool's errand to devote energy to pages whose existence does not pose an actual problem in terms of outside visibility) but even BITE has its limits. We block users who don't get the message after being warned multiple times in other areas as well, so how is AFC different? Deleting a page someone has worked hard on is usually as BITEy as blocking them because both send the message that they are not welcome. But only sanctioning the user will actually address the problem posed by Tony. If we agree to sanction users, we could easily create an edit filter that prevents those users from resubmitting drafts (which would be less BITEy than blocking them without being less effective). Regards SoWhy 09:11, 12 May 2018 (UTC)
    Off topic uninformed oppose Vote! on a clarification of policy to match existing practice at MfD from a user with 17 visits to MfD in their last 50,000 edits over a decade. Sanctioning new throwaway accounts is a fools errand and does nothing to remove the bad Draft from the system. Legacypac (talk) 05:18, 12 May 2018 (UTC)
    @Legacypac: An ad hominem argument obscures the points you are trying to make. You should stop attempting to discredit users by who they are or what they've done and instead discredit their points by answering their points directly. --Izno (talk) 12:11, 13 May 2018 (UTC)
  • Support - I appreciate the nuance given here to those editors who make good-faith efforts to improve their draft, even if it takes 3 or more or many more attempts. Tendentious resubmissions with no effort to address the concerns of the declining editor, however, should be cause for deletion. Even speedy per Dlohcierekim. 78.26 (spin me / revolutions) 19:03, 11 May 2018 (UTC)
  • Support as redundant addition. I don't see the slightest effect that this will have on what we currently have. Also agree with SoWhy. Changed to support. As I already made it clear, I am not against the substance of this proposal but the amount of difference it can make to what currently exists. After TonyBallioni's response, I am convinced supporting this will surely be a one step forward and the impact will (hopefully) be seen in the long-term. –Ammarpad (talk) 19:11, 11 May 2018 (UTC)
    • It makes “repeatedly resubmitted with no improvements, has no chance of being in mainspace, and has no sourcing for uninvolved editors to show notability.” an unambiguously valid reason for deletion at MfD. I think it should be already per NOTWEBHOST. This makes that clear. TonyBallioni (talk) 19:33, 11 May 2018 (UTC)
    @TonyBallioni: I generally agree with the principle of any proposal that will hasten deletion of non-notable drafts that otherwise didn't meet any of our extant WP:GCSD. But I would like to support something that will make impact. Many proposals nowadays are just collection of random support without short term or long term effect. Even now, that this proposal is not in effect, one can nominate non-notable, hopeless and repeatedly submitted draft and it will surely be deleted. But considering your points;
    1. repeatedly resubmitted
    2. with no improvements,
    3. has no chance of being in mainspace, and
    4. has no sourcing for uninvolved editors to show notability
    Shouldn't this be clear need for speedy deletion criterion? If a draft meet all these criteria what else people will discuss? How many people participate in MfD these days? –Ammarpad (talk) 08:18, 12 May 2018 (UTC)
    Hi, Ammarpad, thanks for pinging me. The reason I didn't propose those here is because those would be a lot bigger changes than this, I don't think they have consensus at this time, and I hadn't done any work into looking at what a process there might look like.
    My general approach to policy reform is that policy is meant to be descriptive of practice, not prescriptive. That means I typically only propose RfCs where I think there is a pre-existing consensus. Here, I'd heard enough complaints about how we deal with drafts through MfD, I was aware that previous attempts to get a CSD criterion approved had not been successful, and that draft PROD would be more controversial than this and would probably have a 50/50 chance of passing. I think this proposal addresses a concern that people have, already has consensus, and will improve the encyclopedia as a whole.
    There may be other reform ideas in this area that could be successful, such as Kudpung's suggestion for DfD or yours for Draft PROD. I'd likely support those. That's not the intent of this proposal though. This is an attempt to be a first step in making the process easier by documenting what people already bring up at MfD pretty frequently in policy. If you support the idea generally, like Mz7 below, I hope you'll consider supporting. This doesn't pretend to be the perfect solution, just a viable step forward. TonyBallioni (talk) 12:45, 12 May 2018 (UTC)
    Thanks, TonyBallioni, I now understand you better. Hopefully, although this doesn't mean much now (my concern), it is a stepping stop to something more impactful in the future, instead of ignoring/opposing it now and end up discussing it again at the time we ought to be discussing measures beyond it. –Ammarpad (talk) 07:01, 13 May 2018 (UTC)
    MfD receives reasonably high participation actually; for a CSD you'd need an A7-esque standard, as what counts as "no sourcing" for notability and not suitable for mainspace is contentious Galobtter (pingó mió) 12:52, 12 May 2018 (UTC)
    • Indeed, I think if you look at Wikipedia talk:Miscellany for deletion and its archives, you'll see that the current wording of this section has resulted in a lot of confusion and debate. For that reason, I do not see this clarification as redundant, and if you think it is descriptive of current practice, I think you should consider supporting. Mz7 (talk) 20:15, 11 May 2018 (UTC)
    Yes, I see it as that. That means it will have no solid impact. It merely repeats what already exists. Any draft that meet what was described above will surely be deleted at MfD. See my reply to TonyBallioni above. The current problem as described requires only speedy criterion to make sense and for us to know we're moving forward. Or to a lesser extant, to establish special "sticky prod" for drafts. I will shortly describe it in General comment section. comments below. –Ammarpad (talk) 08:53, 12 May 2018 (UTC)
  • Support see User:JJMC89_bot/report/AfC_decline_counts where drafts are declined as many as 11 times! It is a serious waste of effort and gums up AfC. This can help the actually notable draft stuck in AfC as well because it will expose the page to a discussion where someone can make a case for promotion, but mostly it will provide an exit path for the hopeless repeated reviewer free spin of the wheel style resubmissions. I also support applying A style CSDs to submitted drafts. The act of submission is a request to apply mainspace criteria to the page so treat the page as such. Legacypac (talk) 19:10, 11 May 2018 (UTC)
  • Support Why should notability not be considered for drafts? The point of drafts is to develop into articles, and articles require notability. What then is the purpose of allowing drafts on non-notable subjects? Natureium (talk) 19:23, 11 May 2018 (UTC)
  • Oppose - We should not be spending time in deletion discussions about drafts. These discussions and administrative actions take unnecessary resources, are WP:BITEY, and feed trolls. Please let these submissions wait their turn in the queue for a few weeks before rejecting them. Authors will get the message and the drafts will eventually be deleted under G13. ~Kvng (talk) 19:37, 11 May 2018 (UTC)
  • Oppose, per Kvng. This proposal comes across as a punitive measure, too. --Doncram (talk) 19:52, 11 May 2018 (UTC)
    • The other working proposal to deal with this is to block them and let G13 take hold. I consider that much more bitey and puntative. TonyBallioni (talk) 19:56, 11 May 2018 (UTC)
    • @TonyBallioni: I proposed above that we basically put these drafts in timeout. Can we put that on the table too? No change to process is required, just a change to reviewer behavior. ~Kvng (talk) 00:41, 12 May 2018 (UTC)
      • I'm not really sure if there is a way to prevent them from submitting the AfC draft. I'm also not sure what good it does to keep them for 6 extra months if we've already made the determination we don't want them. If the main reason is BITE, I'll somewhat echo Seraphimblade below in noting that most of these are not actually good faith users who are trying to contribute something encyclopedic that they find interesting to Wikipedia. Most of these are people who have a financial incentive to keep resubmitting and take advantage of our good faith. I'm not sure BITE is really a good argument in dealing with people we don't want contributing anyway. TonyBallioni (talk) 01:12, 12 May 2018 (UTC)
  • Support Oppose arguments such Kvng's are admirable in their assumption of good faith, but practical AfC data shows that there are far too many bad-faith article creators. This reality is the reason that we have made ACTRIAL permanent, after all. The proposed language is a common-sense way to address bad-faith resubmitters. The difference between good-faith and bad-faith article creators is often disclosed by their response to AfC rejection. The former will at least query the rejection and its feedback, while the latter will just send the exact same article back into the queue. This proposal only targets the latter behavior, something that should be dissuaded in any event. Eggishorn (talk) (contrib) 19:57, 11 May 2018 (UTC)
    • @Eggishorn: Can you provide some details about this "practical AfC data"? ~Kvng (talk) 00:41, 12 May 2018 (UTC)
@Kvng:, I suggest starting with the meta:Research:Autoconfirmed_article_creation_trial and wp:Autoconfirmed article creation trial/Post-trial Research Report. Eggishorn (talk) (contrib) 04:29, 12 May 2018 (UTC)
@Eggishorn: I've read those and they don't support what you're saying here. There is nothing in the report about draft author behavior. Also the WMF is only now gaining an understanding of how AfC works. The AfC-related conclusions in the report are disputed. There were more submissions to AfC but there is no evidence there was a "struggle" to keep up with it. See Wikipedia_talk:Autoconfirmed_article_creation_trial/Post-trial_Research_Report#AfC_backlog_"struggle". ~Kvng (talk) 14:38, 12 May 2018 (UTC)
  • (edit conflict) Support – It is true that in the wide majority of cases, the notability guidelines that justify the deletion of articles do not automatically justify the deletion of drafts. This is because one of the purposes of the draft space is to serve as an incubator for drafts about non-notable subjects that have a high likelihood of becoming notable in the near future (e.g. film actors who are about to star in a significant role, upcoming films from major studios, athletes who are about to debut in the top tier of their sport). The draft space is the successor to Wikipedia:Article Incubator in this respect. Articles that were in the incubator did not stay there forever, however; they either were moved back to mainspace or were nominated to MFD or userfied (see WP:GRADUATE).
    I've long held the view that there are two general cases where notability should and does factor in as a part of a decision to delete a draft (see this July 2017 discussion). The first is repeatedly submitted AfC drafts with no foreseeable chance at acceptance due to lack of notability, and the second is long-abandoned non-AFC drafts about non-notable subjects with no foreseeable chance at becoming notable in the future. The second case has largely been mitigated with the expansion of CAT:G13 to all drafts, but I see MfD as the natural place where repeatedly submitted AfC drafts should be sent. I don't see blocking or other conduct sanctions as the best solution because the issue is indeed fundamentally with the subject of the article: no amount of editing can overcome a lack of notability. Mz7 (talk) 20:06, 11 May 2018 (UTC)
  • Oppose for a few reasons, although mostly this is just echoing SoWhy. First, AfC doesn't own the entire Draft namespace, so constant submission is a project problem. In that case, I think SoWhy's response (i.e., it becomes a behavior/cluefulness issue) is appropriate. Second, the purpose of draftspace is for folks to work on pages that are inappropriate for mainspace; this would defeat the whole purpose of treating something as a "draft" rather than an article. I've said elsewhere that I am unconvinced of the damage or harm a large draftspace would supposedly cause, and that remains true. Finally, I think the proposed text weakens WP:NMFD to a degree that it will cease to be a barrier. ~ Amory (utc) 20:34, 11 May 2018 (UTC)
Sure, AfC doesn't own the draft namespace, Amorymeltzer, but it was created with them in mind and with the hope that ACTRIAL would take place one of the days. Well, ACTRIAL took place, and has since become ACREQ and there has been the anticipated (but slightly lower than feared) increase in the number of drafts. Nevertheless, SoWhy's argument (i.e., it becomes a behavior/cluefulness issue) is indeed also appropriate, because the reviewing needs to be much improved so that even if they have clue, they will be singing from the same page of the same hymn book, and at the moment they do not appear to be doing either. And that's a much longer story. Kudpung กุดผึ้ง (talk) 20:48, 11 May 2018 (UTC)
I would qualify your description of the purpose of the draft space in this way: the purpose of the draft space is for folks to work on pages that are inappropriate for mainspace but will soon be appropriate for mainspace. The draft space is not a dumping ground for articles about just any topic that doesn't meet mainspace standards to remain indefinitely – that would be using Wikipedia as a web host. We expect drafts to be actively worked on and improved so that they will eventually be a part of the encyclopedia. If a draft is about a topic that is inherently non-notable and has no foreseeable chance at becoming notable in the future, then more community time is wasted when we allow it to be repeatedly submitted at AfC than if we allow it to be deleted at MFD. Fundamentally, it is not just a conduct issue, but an issue with the subject of the draft. If the real solution is to threaten to block a user if they don't stop submitting, and let it be deleted after waiting out 6 months via G13, then isn't that WP:BITEy and perhaps even more time wasting than if we just waited out 7 days at MfD? Mz7 (talk) 23:59, 11 May 2018 (UTC)
  • (edit conflict)(edit conflict) Support strongly - in fact I would go one further and suggest the creation of DfD - Drafts for Deletion. Since ACREQ was rolled out, there are going to be a lot more drafts for deletion. As one of the editors who works a lot in these areas I prefer pragmatic solutions rather than philosophical ones. Being BITEY is not part of the equation , telling a troll his trash is not wanted is not being bitey, nor is telling an obvious paid editor that Wikipedia was not conceived as a platform for blatently making a career from making money out of our volunteer-created encyclopedia; Wikipedia is not a business directory either or a register for rappers. What is really needed are a better set of instructions (without TL:DR, but more than just a quick click-through of four four-line pages) at the Article Wizard, and more consistent reviewing at AfC; and above all, more truly active AfC reviewers Kudpung กุดผึ้ง (talk) 20:35, 11 May 2018 (UTC)
@Kudpung: I would say, personally, I would like a DfD system, but I've heard arguments that it won't have nearly enough traffic to work properly. Jjjjjjdddddd (talk) 03:45, 12 May 2018 (UTC)
  • User:Kudpung, User:Jjjjjjdddddd - I am genuinely puzzled by the idea of Drafts for Deletion. My question is why drafts need a separate deletion process from MFD, especially since MFD is primarily used for drafts anyway. Why do drafts require their own deletion process? Why not do at MFD whatever would be done at DFD? I hope that this isn't considered a stupid question, but I really don't understand why a new process would solve the known problems with cruddy drafts. Robert McClenon (talk) 23:12, 12 May 2018 (UTC)
  • Support In my experience, G13 is just not good enough to deal with this issue. Drafts that are truely not notable, which are just cruft should be able to be deleted rather than going after x months of no edits and instantly undeletable. Additionally, at MfD/DfD/whatever it is called, there will be the chance for more people to look over nominations than one reviewer every few weeks. While I'm an advocate for a more engagement-based approach on paid editing, in cases where companies are non-notable, we do need to be less wishy-washy on the message we send out. Mdann52 (talk) 20:54, 11 May 2018 (UTC)
  • Support but I like Kudpungs idea a lot - Having "DFD" would be a much better place for all of these as IMHO Drafts are unrelated to MFD, Anyway support this proposal. –Davey2010Talk 21:05, 11 May 2018 (UTC)
  • Support (edit conflict) - I understand SoWhy's concern but I think that if the article is undergoing substantial improvements there is no concern with this affecting the draft. -- Dane talk 21:07, 11 May 2018 (UTC)
  • Support - this is a step in the right direction, although it is still insufficient. Blatantly non-notable drafts (one where no reasonable editor can make a case for notability) should be eligible for deletion either as a speedy or through a XfD process without the need to show anything else. Endorse Kudpung's DfD process. Tazerdadog (talk) 21:18, 11 May 2018 (UTC)
  • In-the-end Support but not yet, not when the resubmissions followed a face reading of the saccharine decline template that encourages the author to edit improve and, with a big blue box, “resubmit”. The template confuses the newcomers who think this is how to communicate. The root fault lies with the AfC template and this deletion process does nothing to address it. Support for resubmissions that follow removal of the saccharine resubmit template only. —SmokeyJoe (talk) 21:34, 11 May 2018 (UTC)
The prerequisites to precede are (1) Wikipedia_talk:Criteria_for_speedy_deletion#Applying_A*_criteria_to_submitted_drafts and (2) fixing the AfC practice of the confusing rejection template. —SmokeyJoe (talk) 21:39, 11 May 2018 (UTC)
  • Support. I also wouldn't mind having a Drafts-for-Deletion notice board, but would prefer to save DFD for a Disambiguations for Discussions notice board. Also, if we are going to separate drafts from MfD, we should create a master deletion noticeboard where editors can see all discussions going on at AfD, MfD, CfD, RfD, and any others that are made. bd2412 T 21:42, 11 May 2018 (UTC)
DAB pages are dealt with at MfD. They may need to be deleted occasionally, but rarely for the reasons that junk that is received at AfC needs to specially treated. Kudpung กุดผึ้ง (talk) 22:06, 11 May 2018 (UTC)
Actually, DAB pages are usually dealt with at AfD - if the issue is deletion. More importantly, however, there are a number of non-deletion issues for which disambiguation pages require a central noticeboard, including move requests, and proposals to change an existing article or redirect to a disambiguation page (or to turn an existing disambiguation page into an article). bd2412 T 22:19, 11 May 2018 (UTC)
DAB pages are never dealt with at MfD but are immediately referred to AfD. DAB discussions would be better as RM discussions on the DAB talk page, except if an outcome is deletion the discussion would be deleted. —SmokeyJoe (talk) 22:25, 11 May 2018 (UTC)
In that case you'd better send this to RfD ;) Kudpung กุดผึ้ง (talk) 22:53, 11 May 2018 (UTC)
With four incoming links, and before today an average of less than one view per ten days, rfding it would be busywork. —SmokeyJoe (talk) 03:39, 12 May 2018 (UTC)
  • Oppose per Kvng and SoWhy. I don't agree with deleting drafts that are declined multiple times after many resubmissions since it may come off as WP:BITEY and completely unnecessary. Just undo/revert the submitter to solve the issue easily instead of MFD-ing which is a waste of time or reviewers should just leave them alone for a few weeks before declining since no one outside the community cares about the draft space and keeping the drafts around will not be detrimental to WP. What is already written is sufficient and the proposed addition could actually make it more confusing rather than give clarity. KingAndGod 22:02, 11 May 2018 (UTC)
    You are free to vote bow you like but basing your vote on the reasoning of an editor with no AfC and extremely limited MfD experience is less convincing. Legacypac (talk) 08:01, 13 May 2018 (UTC)
    @Legacypac: See above your comment to SoWhy re ad hominem. --Izno (talk) 12:13, 13 May 2018 (UTC)
  • Support, absolutely, per Tony. Volunteer time is our most precious resource; we should not be forcing wasting it on reviewing and declining drafts that are tendentiously resubmitted by people not acting in good faith. ♠PMC(talk) 23:37, 11 May 2018 (UTC)
  • Oppose - Resubmitting the same draft over and over is a behavioral issue. Deal with the user. If it's a recurring problem, disallow it via AfC processes. If AfC allows resubmitting the same draft over and over again, don't defer to another process to fix it by deletion. — Rhododendrites talk \\ 23:53, 11 May 2018 (UTC)
Sanctioning new throwaway SPA accounts does not solve much. MfD is no more a seperate process from Draft space than AfD is a seperate process for Mainspace. I am unaware of any way to prevent someone from adding the AfC submit code to any page other than to block them. Legacypac (talk) 05:18, 12 May 2018 (UTC)
  • Support, draft space should be used for things for which there's a reasonable likelihood that they can one day be an article. It should not be a dumping ground for people to write about their pet dog, nor (and I've seen this tried on multiple occasions) for an undisclosed spammer to see just how much promotional language they can get away with by making small changes and resubmitting. We either need this, or a "______ strikes, you're out" speedy criterion. At some point, repeated failed resubmissions indicate that either the author is not acting in good faith, or lacks the competence to write an article. In either case, there comes a point at which we need to say we've spent enough time on it. Seraphimblade Talk to me 00:02, 12 May 2018 (UTC)
  • Support – this is a no-brainer: this is an encyclopedia devoted to articles on notable subjects – if a draft has been determined to insufficently notable at something like AfC multiple times, and is unlikely to ever be notable, it does not belong as part of this project, even in Draftspace. WP:NOTAWEBHOST. --IJBall (contribstalk) 01:16, 12 May 2018 (UTC)
  • Support - While I understand the good faith aspect here, and indeed whenever possible, if a draft has potential to become an article, they should be kept as long as they're being worked on. But unfortunately, there are many drafts on subjects that simply would be deleted quickly if they were an article. It would be better to put them out of their misery quickly as opposed to keeping them in the limbo of waiting for them to become G13 eligible. This is especially with ACTRIAL becoming permanent after all. With that said, perhaps MfD would be a better compromise as opposed to extending certain CSD criteria to drafts, since many drafts are still potential articles, and it's necessary to see which is workable and which needs to go. Narutolovehinata5 tccsdnew 01:48, 12 May 2018 (UTC)
  • Support Most people that repeatedly submit the same bad submission are either not acting in good faith, or are ignoring the decline reason. AfC is already heavily backlogged as it is, and besides, the MfD discussion will either have the bad-faith trash deleted, or give the (presumably somewhat good-faith) submitter a push to improve their draft. Jjjjjjdddddd (talk) 03:58, 12 May 2018 (UTC)
  • Support. We are WP:NOTWEBHOST for material unsuited to our project. Sandstein 07:46, 12 May 2018 (UTC)
  • Support this seems reasonable, it allows for people to try to bring a draft up to acceptable standards without turning draftspace into a webhost for pages which will never become articles. Hut 8.5 10:05, 12 May 2018 (UTC)
  • Support per Hut 8.5. This doesn't stop people from using user space for longer term storage, but it does give us the appropriate tool to deal with the few drafts that need to be cleaned up. Dennis Brown - 10:08, 12 May 2018 (UTC)
  • Oppose This proposal makes a very bold assumption: that AFC reviewers are infallible and that if a draft has been rejected by them three times then "obviously" the draft must be worthless. the problems with AFC's lack of accountability have been discussed many times on Wikipedia and I fail to see how this does anything bu increase the lack of accountability.

    AFC reviewers are declining articles for incredibly petty reasons like not formatting a reference correctly, or "this looks notable, but can you make the article perfect", or the most obnoxious, which is the dreaded copy-pasted boilerplates that say the draft is not good, but do nothing to advise the draftee on how to improve it.

    Something many older reviewers don't realise is that new users are corralled into AFC. AFC is not mandatory for creating a page, but if you are a new user, the instructions you receive to everything to convince you that the only way to create a new page is to make a draft and submit it for review. This has given the reviewers of AFC an incredible amount of power, in a way that goes against the entire spirit of the Wiki (Collaboration). Many AFC reviewers instead of looking to improve articles, have appointed themselves unilateral quality editors and continually reject drafts that AFD would never delete. This proposal seeks to increase the power of AFC editors, but I suggest that this is a solution to a problem that doesn't exist. Egaoblai (talk) 10:23, 12 May 2018 (UTC)

Egaoblai this isn't a CSD so they aren't automatically deemed worthless. Having an MfD for those drafts declined spuriously means that they'll get attention from multiple editors and more accountability and an accept in those cases where the declines are spurious Galobtter (pingó mió) 12:13, 12 May 2018 (UTC)
At MfD we can discuss and save if the AfC reviewers are wrong Legacypac (talk) 08:01, 13 May 2018 (UTC)
I agree with your concerns Egaoblai but a timely MfD is likely to be an improvement on the draft ageing out and being quietly deleted G13 after 6 months. Espresso Addict (talk) 00:26, 15 May 2018 (UTC)
  • Support. I see this as a genuine problem and this seems like a practical way to solve it. WP:MFD will get extra eyes on them in case there's a consensus that the AFC reviewers have erred, and there's always WP:DRV as a backup as with other deletion processes. Boing! said Zebedee (talk) 10:26, 12 May 2018 (UTC)
  • Support per Tony and Mer-C; blocking the accounts is hard to do when they are likely in good faith etc; you'd need first need to leave specific warnings rather than encouraging AfC messages and it is basically much more effort overall. Galobtter (pingó mió) 12:52, 12 May 2018 (UTC)
  • Support - this seems like a measured solution to the problem. Richard0612 13:47, 12 May 2018 (UTC)
  • Oppose Per WP:NOTPAPER, there is no physical limit requiring deletion. If resubmission is an issue, it is better to retain drafts as a record of previous versions. If you start deleting versions, then further submissions will seem to be starting afresh, so causing the process to loop indefinitely. So, just as we keep our discussions and archives indefinitely, we should keep draft versions too. If they don't seem to be going anywhere, then use a category or other tag to mark their status. Andrew D. (talk) 21:23, 12 May 2018 (UTC)
  • Measured oppose "Repeatedly" is an interesting word, and the criterion should not be "repeatedly" but "repeatedly without prospective changes in notability" - that is, we ought to avoid burning up a draft where the notability of the topic or person has a decent chance of being altered substantially. Collect (talk) 21:29, 12 May 2018 (UTC)
if that is true for a draft that can be discussed at MfD. Legacypac (talk) 08:01, 13 May 2018 (UTC)
  • Support - a measured proposal that doesn't try to go too far. — Insertcleverphrasehere (or here) 23:04, 12 May 2018 (UTC)
  • Support - Something needs to be done about tendentious resubmission. Either the drafts can be deleted, or the resubmitters can be blocked, or both. Something needs to be done. I don't see a practical way to request that the fools and flacks be blocked, because WP:ANI isn't worth the drama and will probably wind up with a warning anyway, and they aren't vandals. I don't think it goes far enough, but it is better than nothing. I would like to be able to speedy drafts that have no credible claim of significance, but I know that I am in the minority there. Robert McClenon (talk) 23:28, 12 May 2018 (UTC)
  • Oppose - The issue of a draft being submitted too many times would be better addressed at Wikipedia:Articles for creation/Wikipedia:WikiProject Articles for creation. For example, a process of barring a draft from resubmission for a certain period of time or barring a user from submitting draft(s) to be considered for a certain period of time could be established. Let the AfC process govern itself; the problem should not be thrust directly on MfD. If AfC establishes a guideline that such drafts should be deleted (as opposed to my examples above which I believe are better options), they can cite it at MfD. WP:NMFD is not the place for such guidance to reside. All drafts inducted into the AfC process become eligible for speedy deletion per G13 after 6 months of inactivity anyhow, so I fail to see the necessity of early deletion. — Godsy (TALKCONT) 00:21, 13 May 2018 (UTC)
If they get repeatedly resubmitted they never get to G13 Galobtter (pingó mió) 06:35, 13 May 2018 (UTC)
  • Support - per User:Robert McClenon Smallbones(smalltalk) 15:09, 13 May 2018 (UTC)
  • Support a separate "drafts for discussion" page, as well as a CSD for drafts that have been declined more than 3 times without any plausible improvement. Lojbanist remove cattle from stage 19:07, 13 May 2018 (UTC)
  • Support a working solution to a real problem of NOTWEBHOST content that otherwise falls between the cracks. – Finnusertop (talkcontribs) 22:42, 13 May 2018 (UTC)
  • Support just formalizing my own personal view. If the same submission gets repeatedly submitted without correcting the problem I go from friendly to not-so-friendly in my comments with the last comment being to the effect of Do not resubmit this without correcting the issues already raised otherwise I will nominate this for deletion at MFD. It doesn't threaten the user directly, it simply explains what the consequence of them failing to read/understand/correct will be. Hasteur (talk) 01:38, 14 May 2018 (UTC)
  • Oppose per SoWhy and Amory. Besides, draftspace is exactly the place to put not-article-worthy-yet drafts. This would defeat the whole purpose of it. Besides, there are some AfC reviewers that will acept draft with lower standards, while others will wait for them to be GA-class to accept them. L293D ( • ) 02:24, 14 May 2018 (UTC)
  • Support, but only under a specific set of criteria. I agree that drafts that aren't likely to go anywhere need to be shown the door, but I'm not sure just doing it by MfD'ing everything that gets power-submitted is the way. I'd actually think a valid case could be made for drafts that fit all of the following criteria:
    1. The draft has been rejected at least five times, or has been resubmitted and rejected with no substantial edits to it three times. If someone is working on a draft and at least trying to make it work out, the likelihood of it getting rejected five times is slim to nil. On the other hand, someone who's just spamming the submit button is likely doing it for Google exposure, not to build an encyclopaedia.
    2. The draft's sources are unacceptable, and no acceptable sources are available online or off. Oftentimes the biggest hurdle to a draft is finding usable third-party sources, and newer users are less likely to understand what we deem acceptable. I would also suggest amending the decline message for lack of notability to include a link to a plain explanation of acceptable sources (which I'll probably dope up soon, since this is almost universally THE main sticking point as far as helpees in -en-help go).
    3. The draft, in addition to the above, has not been (substantially) edited for at least three months since the last decline or edit. Given that the usual backlog for AfC at present is in the neighbourhood of months (as an acknowledged consequence of ACTRIAL and ACPERM) this gives time for sources to come into existence and thus subvert the second bullet above. This is also why a WP:BEFORE check must be done before a draft gets taken to MfD. While I suggest three months (as a fair chunk of drafts are made in anticipation of a topic) this should be considered a suggestion and not a hard-and-fast rule, but it should be no less than ten weeks and no more than 6 months (when G13 kicks in anyways). —Jeremy v^_^v Bori! 03:30, 14 May 2018 (UTC)
  • Support - This is not an area where I have a great deal of experience, but it seems to me that the "support" !votes present better arguments than do the "oppose" !votes. Having no strong personal reason to oppose, and trusting in TonyB's judgment, I support. Beyond My Ken (talk) 03:54, 14 May 2018 (UTC)
  • Support – Regardless of whether resubmitting a draft repeatedly is a behavioural issue as some argue it should be treated as, this will make it easier to get rid of problem drafts via MfD. If it is a substantive draft that is actually worth keeping, MfD will see it as such. Draftspace has been a mess for a while, and the problem isn't with the potentially publishable drafts; it's with the repeatedly resubmitted corporate spam and self-published non-notable bios. I don't see the issue here. (talk) 14:39, 14 May 2018 (UTC)
  • Support - I will ask a going further, for those where consensus is at MFD that there is no clear case at mainspace WP:SNOW - then admins should be able to SALT the page. I have been seeing people recreating their useless drafts and then repeatedly recreating. Banning individual users may be in need, but we need warnings, final warnings and etc. And the user maybe able to contribute in other areas, so sometime can't ban also. Therefore, to solve the content issue, SALT the page. --Quek157 (talk) 21:16, 14 May 2018 (UTC)
  • G4 is applicable if they blindly re-create it after an XfD debate without fixing any of its issues. We shouldn't salt the earth unless and until they prove themselves unwilling or incapable of listening to criticism of their article by repeatedly growing a new one from the ashes. —Jeremy v^_^v Bori! 19:18, 15 May 2018 (UTC)
  • @Jéské Couriano:, I declined a draft with 2 - 3 can't remember previous deletion, CSD G11 (Advertising) with G4 (SALT). The admin who process initially did G4, but then said "unnecessary for draft" so then reallow creation for G4. G4 can only be used for mainspace, not draftspace, I am thinking to extend it to here. --Quek157 (talk) 21:20, 15 May 2018 (UTC)
"It excludes pages that are not substantially identical to the deleted version, pages to which the reason for the deletion no longer applies, and content that has been moved to user space or converted to a draft for explicit improvement (but not simply to circumvent Wikipedia's deletion policy). This criterion also does not cover content undeleted via a deletion review, or that was only deleted via proposed deletion (including deletion discussions closed as "soft delete") or speedy deletion."(emphasis in italics). This is the big problem NOW at the draftspace which is this entire RfC is for. It is quite protected and is not like others. I just came back after a long hiatus and apparently it is now like that, FYI too =) --Quek157 (talk) 21:25, 15 May 2018 (UTC)
  • Support- I'd personally go further, in terms of Notability as a criterion, but the proposal would certainly be an improvement on the current position. KJP1 (talk) 05:39, 15 May 2018 (UTC)
  • Support. I do think that this would address a need. What makes it work for me is that it is directed at drafts that keep getting resubmitted without "getting the message", and that it makes it possible to decide that a draft should be deleted, as opposed to saying that a draft must be deleted. In other words, it still leaves discussion and editorial judgment in place. --Tryptofish (talk) 19:25, 15 May 2018 (UTC)
  • Support. This is already how discussions at MfD are turning out: the community (or, at least, the portion of the community that regularly votes at MfD) feels that it is appropriate to delete tendentious resubmissions that utterly fail to address the reasons for their rejection as a way of communicating to the user that their disruption won't be tolerated without going to the extreme of bans or blocks. Compassionate727 (T·C) 21:18, 15 May 2018 (UTC)
  • Support. Anything not in one of the "normal" namespaces can already be nominated for MFD, and any such page will be deleted if consensus favor deletion. This isn't adding any new ideas or procedures to policy; it's simply saying what's already happening. WP:PPP. Nyttend (talk) 11:29, 16 May 2018 (UTC)
  • Support, also support Drafts for Deletion. Having drafts with no hope of becoming articles is helpful to no one; having a dedicated drafts for deletion space will allow people specializing in drafts to watch it, as shepherding a draft into an article is a skill. --GRuban (talk) 20:30, 16 May 2018 (UTC)
  • Support per Kudpung. Amorymeltzer is exactly wrong; draft space only exists as the location for AfC's backlog. SoWhy is correct insofar as problem editors are behind the repeated submissions. Because these drafts are of interest to businesses or fan collectives where meatpuppetry or sockpuppetry is likely, deleting the draft is a more efficient practice. Chris Troutman (talk) 16:44, 20 May 2018 (UTC)
  • Support: no chance of ever becoming an article & tendentious resubmissions which take up volunteer time. This is a suitable approach to addressing the issue. K.e.coffman (talk) 01:30, 22 May 2018 (UTC)
  • Support: well, a decision should be taken based on a statistic (in available). I agree that if a draft gets declined 3 times (ofthen for the same reason) further resubmissions for AfC is just time wasting. I believe that if a WP:RENOM style policy would be implemented for drafts would be a good step forward. We all know that a new editor, not familiarised with all the policies needs some time to know that there are some fair rules. So a time frame to improve an entry between two resubmissions would be a viable solution as well. However, if the draft keeps getting declined by different reviewes several times during, let's say, 6 months or a year... we all know what that means. As a NPP reviewer and page mover - sometimes, when I felt like an article has potential - I draftified those articles and some of then giving advice to its creator how to improve the draft. Robertgombos (talk) 23:07, 24 May 2018 (UTC)
  • Oppose This feels like we are trying to make a crystal ball to predict if a subject will become notable or not. I do not agree with the wording and what it can imply. I could get on board for an "abandoned" guideline, that any draft that has not been improved in X amount of days is deleted or userfied.--Paul McDonald (talk) 23:17, 24 May 2018 (UTC)
  • Support per Tony and K.e.coffman. Could not have said it better myself. JTP (talkcontribs) 15:41, 31 May 2018 (UTC)
  • Support IF ANSWERED - it is codified how much and how frequently is going to trip the tendentious resubmissions bit. I'd like just being able to userfy etc, but if those who endlessly resubmit would presumably do the same in AfC.
TonyBallioni the latter part of your proposal "otherwise meets one of the reasons for deletion". AfC pass requirements are stricter than those for an article to remain. Most notably on issues such as verification (AfD can be stopped by sheer possibility of finding sources) and promo levels (AfD articles have to be completely promo). Would a strict following of this proposal not risk us having a group of articles that would continually fail AfC but not be deleted under WP:DEL-REASON? Nosebagbear (talk) 14:54, 6 June 2018 (UTC)
I'm obviously not Tony, but I would imagine that in such a case if an MfD is closed as keep, then the article fails AfC again or just sits there for a while, then that very fact can be used as an argument to delete at a second MfD. And, of course, if the draft is left unedited for 6 months then it'll get G13'd. ƒirefly ( t · c · who? ) 09:34, 7 June 2018 (UTC)
Nosebagbear, sorry for the late response. AfC's acceptance criteria is "is likely to survive AfD", which means they are substantially lower than the mainspace requirements. Also, if the reviewer has made mistakes, MfD will likely suggest booting it to mainspace with no prejudice against sending to AfD. TonyBallioni (talk) 14:21, 7 June 2018 (UTC)
  • Support per above. Seems sensible, and already appears to be the case at MfD anyways. -FASTILY 23:05, 7 June 2018 (UTC)

Drafts Discussion

TBD, the whole Draft system itself, should be abolished. IMHO, it's best to let an editor create an article as a stub, then let the community gradually evolve that article. Meanwhile, individual editors can use their own sandbox to construct what they want to put into an article created by themselves or somebody else. The Draft system is just an extra layer, for editors to fight over. GoodDay (talk) 19:17, 11 May 2018 (UTC)

I do not think that is an appropriate suggestion at all. Coming from a user who has a very high count of minor edits and not in the areas under discussion here, I wonder on what experience you actually base your comment. Kudpung กุดผึ้ง (talk) 20:59, 11 May 2018 (UTC)
Up until a few weeks ago, there were quite a few Draft-related disputes concerning behavior being brought to ANI. This wouldn't have occurred, if there were no Draft system. GoodDay (talk) 21:20, 11 May 2018 (UTC)
'Quite a few' is quantitively subjective. I'm no friend of statistics where concrete empirical evidence exists, but I would like to see that claim supported by some numbers. Are you an admin? Do you frequent ANI regularly? I do. Those issues would probably have been brought to ANI under some other reason. — Preceding unsigned comment added by Kudpung (talkcontribs)
Abolish the Draft system & the community just might be happier for it. GoodDay (talk) 22:17, 11 May 2018 (UTC)
Heh, I remember the days when AfC drafts were stored in the "Wikipedia talk" namespace because the draft namespace just did not exist. Let us not return to those days. Mz7 (talk) 09:56, 12 May 2018 (UTC)
Re: "Up until a few weeks ago, there were quite a few Draft-related disputes concerning behavior being brought to ANI. This wouldn't have occurred, if there were no Draft system." On those grounds, if we abolish article space we'll have no article concerns brought to ANI, and if we abolish User space we'll have no User space concerns... perhaps we should just abolish Wikipedia? Boing! said Zebedee (talk) 10:35, 12 May 2018 (UTC)
  • Comment - the interpretation of the RfC that "notability criteria don't apply to draft space" continues to be tone-deaf, overly simplistic, and harmful. Of course drafts should be on notable topics; anything else fails WP:NOTWEBHOST. Deciding which is which is a task for MfD (or perhaps drafts should be handled at AfD since they're supposed to be articles) but just setting another completely arbitrary draft working limit (like "six months") is not going to do anything to address the problems identified by this proposal (which are real problems which should be addressed). It's just inviting fights about what constitutes meaningful improvement. Ivanvector (Talk/Edits) 19:20, 11 May 2018 (UTC)
(edit conflict) I also endorse GoodDay's comment. Ivanvector (Talk/Edits) 19:20, 11 May 2018 (UTC)
I agree but 1) I never propose RfCs that I don’t think have pre-existing consensus, and I think making N apply to all drafts at the beginning doesn’t have a chance of passing. 2) This actually expands the force of N to drafts more than it is now, while still shielding them from the brunt of it initially. It can’t be the sole reason for deletion, but a repeatedly deleted draft that fails the notability criteria and doesn’t have a chance of being in mainspace. TonyBallioni (talk) 19:30, 11 May 2018 (UTC)
I just think the implementation of the RfC has been very poorly done; I get the intent, but, ugh. The notion that the draft space should be an incubating space for content intended to form part of an article, and not a junk space to hold whatever bits of writing anyone wants to drop there, seems to be a minority opinion. It's absurd to me that we allow editors to post basically anything they want in draft space, like the thousands of drafts that are nothing more than SEO listings for entirely non-notable businesses. We keep telling the authors of these articles that they "don't demonstrate notability" but our AfC messages encourage them to try again by adding more references, as though we'll decide to accept their article that's just a list of directors of their tech startup if they just pay for enough copies of their own press release, and so of course they resubmit over and over again with no meaningful improvement. There's no meaningful improvement to be made, the topic is not notable. We should empower our AfC reviewers to just come out with it and say, "this isn't notable" and punt the drafts to MfD immediately. And we can word that response as gently as we need to, we've been rejecting and deleting articles on non-notable topics for, oh, 17 years now? But if everyone who's been here a month can see that a draft on a non-notable topic is going to end up being deleted, is it more bitey to string an editor along for months and possibly years with messages telling them they just need to improve the draft a bit more before it can be an article when it never will be, or just delete it outright and say "thanks, but no"? I realize I'm ranting here and I'm probably not even really addressing the proposal at this point, but if anyone wants to really consider this, my talk page is probably a good place to respond.
Tony, to reply to your comment more briefly, a draft that doesn't have a chance of being in mainspace shouldn't need to be repeatedly [declined] before we pull the plug and delete it. In my opinion we should be able to make that determination much earlier in the process. To GoodDay's point, when a draft is reviewed we should be able to determine its article-worthiness on the first go-round, and either promote it or delete it. If it's notable but poor quality, promote it and let the usual community improvement process proceed. If it's not notable, delete it. Somehow AfC has evolved into a highly arbitrary quality pre-screening process, and I'm pretty sure that was never the intent. Ivanvector (Talk/Edits) 20:39, 11 May 2018 (UTC)
Ivanvector, The notion that the draft space should be an incubating space for content intended to form part of an article, and not a junk space to hold whatever bits of writing anyone wants to drop there, seems to be a minority opinion, is in fact very much a majority opinion. Our CSD criteria are very strict and narrow but there is no catchall for cases that don't completely match a criterion. I agree entirely that when a draft is reviewed we should be able to determine its article-worthiness on the first go-round, and either promote it or delete it. But we don't even do that in the harsh reality of the front-line trenches at at NPP where there are borderline cases that have to be sent to AfD, or inappropriate CSDs that admins have to decline and send to AfD. Contrary to GoodDay's point, it's not the Draft namespace that should be deprecated - it's more likely that AfC should be abolished or merged into NPP - but we're trying to come up with a compromise that will prevent that happening). Kudpung กุดผึ้ง (talk) 21:38, 11 May 2018 (UTC) Kudpung กุดผึ้ง (talk) 21:38, 11 May 2018 (UTC)
User:Kudpung, User:Ivanvector - I honestly didn't know that the common sense stated above was a majority opinion. It often seems that I am in the minority in thinking that draft space should be kept free of crud that will never be ready for mainspace. I don't mean to be sarcastic, but it does appear that Ivanvector and Kudpung and I are in the minority in wanting to apply common sense to what can be in drafts. Perhaps the problem is that AGF and BITE are carried to such extremes that they are allowed to override judgment about drafts. As User:Legacypac said today at my talk page, there is a culture of busybodies who have no practical experience at AFC or MFD but show up to express opinions. This is unfortunately part of a larger Wikipedia culture that it is a good idea to dump on the reviewers for not being sufficiently welcoming to new editors (even if they are fools or flacks). I honestly didn't know that Ivanvector and Kudpung and I were in a majority, when there is a culture of editors who preach platitudes about AGF and BITE without seeing the fools and flacks. (Of course new editors who have clues should be welcomed. Some do, many don't.) Robert McClenon (talk) 23:24, 12 May 2018 (UTC)
  • I disagree. When reviewing pages at NPP, there are a lot of articles that could potentially be articles with a lot of work, but aren't good enough for article space. For example, an "article" of thoughts in bullet form with a list of references. Without the option to move this to draft space, are you suggesting that this be kept in article space or be deleted? Natureium (talk) 19:26, 11 May 2018 (UTC)
Userspace. —SmokeyJoe (talk) 21:44, 11 May 2018 (UTC)
  • Support, or at least extending ACTRIAL to DraftSpace. On the whole it is a big negative, mostly due to the silent cold reception given to the newcomers. They should edit mainspace before starting new topics. —SmokeyJoe (talk) 21:42, 11 May 2018 (UTC)
Of course it would be better extend it to all users. We could do away with AfC altogether then, but that would defeat 50% of the object of having ACTRIAL - allowing IPs and non-confirmed user to create drafts was part of the plea bargain in order to get ACTRIAL approved at all. Kudpung กุดผึ้ง (talk) 04:32, 12 May 2018 (UTC)
  • Wouldn't it be a possible idea to have a ClueBot NG style bot monitoring drafts and reverting resubmissions without substantial changes? I guess an edit filter won't work because it probably can't detect resubmissions but a bot could and that would be a potential time saver if human editors weren't forced to check those pages manually. Regards SoWhy 10:27, 12 May 2018 (UTC)
    Hmm, this is beyond AI at this time. SoWhy. "What is substantial changes"? Lot of text? Lot of references?. Number of sections?. –Ammarpad (talk) 10:37, 12 May 2018 (UTC)
      • Well, ClueBot NG is pretty good at spotting vandalism. But that's why I asked. A bot could at least handle cases where no changes were made, couldn't it? Regards SoWhy 11:55, 12 May 2018 (UTC)
        • Actually, this isn't a bad idea. There's one draft currently being debated at MfD, where it was rejected for the seventh time for notability with the note that the Daily Mail isn't a reliable source, so the person removed the Daily Mail and then re-submitted. I've also seen drafts where it was re-submitted immediately after the rejection with literally no changes. It would very easy for a bot to detect and reject these submissions. Compassionate727 (T·C) 21:33, 15 May 2018 (UTC)
  • I don't really have any idea what this is all about. But from a purely technical viewpoint I could quite easily train an AI program to scan for substantial changes to an article, measured by a weighted quality score rather than using any one measure. Such a program could be programed to automatically detect whether sources have been added or just slightly altered. And it would be feasible for it to detect and warn reviewers of policy violations in the text. The only reservations I have is that since no program is perfect I would not recommend you have an AI editing articles all on it's own. JLJ001 (talk) 11:10, 17 May 2018 (UTC)
  • The more I read these debates, the more I feel the ability to ban/block users from any form of article creation process is inevitable. Junkcops, aka FMecha (mail box|what I did) 05:41, 23 May 2018 (UTC)

Regarding MfD of drafts and G13

I've heard that G13 is supposed to delete the junk from draftspace, but there's a better way. I propose that we repeal G13 and expand *some* CSD to draftspace, possibly write up new draft-specific CSD and PRODs, without actually expanding the normal PROD to draftspace (because it wouldn't be patrolled enough). Why? First off, G13 is simultaneously too fast and too slow. Too slow to delete the obvious garbage (and does nothing for repeat, unchanged, AfC submissions), and too fast to accommodate an abandoned-but-workable draft. Second, G13 is arbitrary. 6 months means nothing (see also WP:NODEADLINE). In a nutshell, more specific deletion criteria, less G13 dragnet. Thoughts? Jjjjjjdddddd (talk) 03:58, 12 May 2018 (UTC)

Keep G13 and extend PROD to drafts. After all, it's no worse than PRODing a new article at NPP. Again, however, I come back to what I've been saying several times: Improve the Wizard so that it provides some useful instructions for new users. Kudpung กุดผึ้ง (talk) 04:27, 12 May 2018 (UTC)
G13 actually sorks in favor of good drafts. A non-AfC Draft gets the attention of an experienced user working the G13 elegable list and, if tagged for deletion, an Admin's attention. I've sent many pages to mainspace from the G13 list (but 99% that reach G13 need to go in the dust bin). Rejected AfC Drafts may be bot nominated.
MfD can function as an advertised PROD for Draftspace. If no one objects a week after nomination an Admin deletes. Legacypac (talk) 04:55, 12 May 2018 (UTC)
How would some sort of PROD be helpful for drafts if they're being resubmitted? That just sounds like you want to take G13 down from 6 months to 1 week. Nobody but the occasional AfC participant looks at any given draft, so any PROD-like system is just an attempt to mass-delete drafts. I don't think we have a rash of people who take a week or two off from their draft but come back and "ruin" G13 five months later. Either these pages are resubmitted to the point of disruption or they're not. ~ Amory (utc) 13:17, 12 May 2018 (UTC)
G13 is one of the most bizarre rules on Wikipedia. I still don't know the reason it was instituted. These arguments about "clogging" the wiki are bizarre when you consider that it's all online. Also many of the deleting admins at g13 don't even look at what they are deleting, which to me is ludicrous for a wiki that claims to be a repository of the world's knowledge. Again, what exactly is the problem here and why are people looking for ever more unilateral ways to delete potential content?Egaoblai (talk) 10:43, 12 May 2018 (UTC)
I agree with you on G13, but I think it should be easier to delete drafts without potential, and other junk, so there are less junk drafts to get in the way of viable drafts. Jjjjjjdddddd (talk) 23:41, 12 May 2018 (UTC)
Egaoblai, Also many of the deleting admins at g13 don't even look at what they are deleting, which to me is ludicrous, that's a strong claim. Please state on what experience you base your assumption. Provide concrete examples. Kudpung กุดผึ้ง (talk) 02:37, 13 May 2018 (UTC)
I was looking through the G13 pages in December and saw one that I thought might be worth looking at, or at the very least not deleted without a conversation. The next day I went back to find it, but it had gone. I posted on deleting user's talkpage and asked them what the reason for deletion was, they said that it was because it hadn't been edited in 6 months and that was the only reason needed to delete an article.
I posted on the admin board about this as I believed that this was not the spirit of the rule and that deleting admins at g13 were supposed to check the articles before deleting them. The incident was closed and I messaged the closing admin about it, which actually led to this discussion: whereI was told that deleting admins can and do delete articles at g13 without looking at them. Winged Blades of Godric even stated that "even a GA-standard article, that for some reason has been lingering for over 6 months in draft space, could be G13-ed." Not that they neccesarily agreed with that, but that is the system that is happening right now. Do we really want the same lack of oversight to be applied to PROD too? Egaoblai (talk) 16:16, 13 May 2018 (UTC)

This is commonly known, Kudpung. It may be that most admins who patrol G13 are diligent, but – as often happens – the vast majority of G13 deletions are carried out by the minority of admins who aren't. – Uanfala (talk) 14:47, 13 May 2018 (UTC)
On the contrary when I nominate G13 I save the occasional useful page and the Deleting Admins occasionally save a page I nominated so they are looking at them. We have a G13 postponed category too. We definately need G13 or the rejected and abandoned would pile up. G13 sweeps up all kinds of problematic pages, including link spam. Legacypac (talk) 04:06, 13 May 2018 (UTC)
Wow... just wow... Time for a history lesson. G13 was originally created when we had One hundred and thirty thousand pages in the space Wikipedia talk:Articles for Creation/ that had been created by 15-minutes-of-fame editors that had zero interest in coming back and correcting the issues raised with their submission. G13 was originally written to address AfC pages that had been 100% unedited for 6 months. Editors went through and did bulk nominations causing admins to be upset with the amount of pages G13 nomination category and with the overall size of the CSD nominations set. I developed a bot script that would procedurally go through all the pages and warn the author that the page was in danger of being deleted under G13, how they could prevent the deletion, how they could get the page back with a very low effort, and if they were a user the option of WP:USERFICATION. The bot limited the number of pages in the G13 sub-category to 50 pages at once so as to not overflow the admins. Over time the backlog was addressed, AfC moved to Draft space, Incubator moved to draft space, the G13 rule got finessed to be "unedited for 6 months (barring bot edits or trivial changes)" (which I think opens it up to discretion and uphold the more strict interpertation of the rule), and finally G13 got expanded to encompass all of Draft space. G13 was written to be a binary question Has this page been unedited for at least 6 months? If so, you may nominate for CSD:G13. The amount of Good will that is expended towards the authors whose pages get swept up by G13 is far more than any other area in Wikipedia for the simple reason that these authors are supposedly the newbies and shouldn't be bitten by not knowing all the esoteric rules of mainspace. Abolishing G13 will only create more MFD nominations. Hasteur (talk) 01:56, 14 May 2018 (UTC)
  • G13 was logically required, and still is. G13 cannot be repealed for as long as newcomers are encouraged to start drafts. --SmokeyJoe (talk) 07:58, 14 May 2018 (UTC)
  • G13 is certainly required but I've found ~5% of G13-ed abandoned drafts are on notable topics which might be salvageable with work but aren't ready for mainspace. I wish there were some way of dealing with these and bringing them to the attention of a wider editor base. Robotically deleting G13s because they are eligible feels wasteful to me. Espresso Addict (talk) 12:00, 15 May 2018 (UTC)

Sticky PROD for drafts (idea)

TonyBallioni expressed these 4-points in the above proposal.

  1. repeatedly resubmitted
  2. with no improvements,
  3. has no chance of being in mainspace, and
  4. has no sourcing for uninvolved editors to show notability

There are many, many drafts that currently possess the above characteristic squarely. However, I (previously) largely opposed because, it just repeats what exists, and will not make any solid difference to how MfD is run now. Because any draft that clearly possess these characteristics, it will surely be deleted at MfD. Now we are looking for way to move forward. To agree on more process that will hasten deletion of utterly non notable drafts that otherwise didn't met any of our CSD criterion and at the same time be courteous to these new users. One of the option can be clear need for Speedy criterion for them, which has been repeatedly discussed but lacked support. So I think why should we not try special PROD for that kind of drafts?. I know something like this was discussed before, but I am outlining it more explicitly below for more thought.

  1. A draft meet all the above four characteristics.
  2. A special sticky Draft Proposed Deletion tag (DPROD) is placed by user.
  3. Once draft is tagged with DPROD tag, then it cannot be removed unless if the person wishing to remove it has thoroughly rewrote the article and moved it to mainspace. (This will serve two purposes: It will be an incentive to save salvageable drafts and at the same time any non-notable draft moved to mainspace without development will now be subjected to both WP:ACSD and AfD.)
  4. If the tag, remains in the draft after say 1 week, 2 weeks or 1 month at most; then it will be summarily deleted as expired DPROD. Any recreation is subject to rule of G4 since it is determined not notable at all and no one is willing to explain why it should stay here.

Through this method, a large number of these hopeless draft will be easily shown the way out without exhausting editors' time at MfD and at the same time ample chance is given for anybody to prove why they should stay here.

Of course, this can be tweaked and refined. –Ammarpad (talk) 10:24, 12 May 2018 (UTC)

  • Strongly Oppose Every single time someone makes a proposal to increase deleting things, the argument is always "but we'll only do it for the ones that are really non notable, we swear", and every single time, the dragnet is increased and increased until you have uninvolved editors, who have zero knowledge or interest in the subject of an article or draft declaring "this will never be notable". At least with the jury system of AFD these decisions have a fighting chance, but increasing the scope of what are basically unilateral deletions is not helping the Wiki with collaborative editing. Just the other week I dePRODded an article, which the nominator then sent to AFD instead, to which the community decided that the article was notable. How many articles that the community would have seen as notable have been wiped from the Wiki because of PROD? It's undemocratic and goes against the spirit of consensus, which is supposedly how this Wiki is run.Egaoblai (talk) 10:49, 12 May 2018 (UTC)
Again Egaoblai you are making some very strong assumptions. The way Wikipedia is run, some examples would be needed to give weight to your opinions. Our PROD systems were introduced on very strong consensus - are you suggesting PROD is 'undemocratic' just because you found one that was kept at AfD? Kudpung กุดผึ้ง (talk) 02:47, 13 May 2018 (UTC)
So, I have looked at your editing history and your user page and checked out the articles. I admit that more 'BEFORE' should have been done prior to listing them for deletion. But this is not a fault of the system, it's a problem of educating the users who tag them. In the case of the school article on which your arguments were excellent, your adversary has a clear pattern of singling out schools for deletion. They generally lose the school AfDs they nominate or vote on. Kudpung กุดผึ้ง (talk) 03:11, 13 May 2018 (UTC)
A system should be evaluated by how it works in practice, not in theory. Furthermore, just because a system is established by consensus does not mean the system itself is democratic. — Godsy (TALKCONT) 04:57, 14 May 2018 (UTC)
  • Support in principle, but perhaps a normal PROD would suffice. I am reminded of recent discussions somewhere about a 3-Strike rule, but I don't recall the outcome. Perhaps a PROD following the 3rd rejection? Kudpung กุดผึ้ง (talk) 02:51, 13 May 2018 (UTC)
  • Support Prod for drafts but I prefer simply sending them to MfD as a form of advertised Prod If no one votes keep and adopts the page in a week it gets deleted without fanfare. Legacypac (talk) 07:49, 13 May 2018 (UTC)
  • Support I am surprised there is not already some guideline providing for the deletion of drafts resubmitted after being rejected for non-notability, and where the draft has been changed little if at all since the last rejection. I certainly think this would be helpful in helping the community delete some of these drafts that clearly have no chance of becoming actual articles. But I wonder: the proposal uses the word "repeatedly"--does that mean that a draft that was rejected once, resubmitted, and then rejected again would immediately become eligible for deletion? Does "repeatedly" mean "2 times or more" here? (BTW what the answer to this question is doesn't really matter as far as my support for this proposal is concerned.) Incidentally, I might even support the use of a new CSD criterion for drafts repeatedly rejected as non-notable, where the lack of notability is obvious. Every morning (there's a halo...) 21:08, 13 May 2018 (UTC)
  • Comment Do you realise how BITEY this sounds? "Hey your draft sucks and we've put a label on that means if you don't improve it in one week it's getting deleted!" If you wish to frustrate new users or people that can't afford to spend hours a day on Wikipedia, then this is the proposal for doing that. AFC reviewers are not gods and their opinion on what is notable should not supercede the community at large. Currently drafts can be deleted through MFD, which at least puts things to a public discussion. There is also G13 which is mostly hidden and allows drafts to be deleted without discussion after 6 months. Now you want to increase that power and allow drafts to be deleted after a week? based on the opinion of one person at AFC? What is with this paranoia and hand wringing about drafts. What problems are there that this is a solution to that G13 or MFD don't already solve? Please consider that for many many users here, writing a draft is a learning process and so is submitting it for review. Not every draftee is out to try and scam the wiki, many are good faith contributers, often with English as a second language who need guidance and help and community. What ever happened to that on this wiki? As far as I can tell this proposal does not allow any chance for the community to help the draftee improve the page, nor does it offer any space for the community to discuss the merits of the draft. According to the proposal one or two AFC editors could effectively blackball a topic from wikipedia and this would go unnoticed by the majority of editors, unless they were also AFC editors who happened to look in, or people who browsed Prod. This is really unacceptable for anyone who sees this as a community project. Egaoblai (talk) 00:06, 14 May 2018 (UTC)
  • Oppose So you'd rather take the consensus discussion that happens at MFD to individual draft pages and put a arbitrary stickey prod on it? PROD is "I propose a uncontraversial deletion". The only exception is BLPPROD, and that is foundation policy. Hasteur (talk) 01:58, 14 May 2018 (UTC)
    That is not true. BLPPROD was not created by fiat because of "foundation policy" as you're wrongly implying. It was created after community consensus was found for it. Your first point doesn't make sense either. It is still uncontroversial PROD, if you object to any DPRODDED draft, then simply develop the draft to become meaningful article, move it to mainspace and remove the tag, the same way it is done for sources in BLPROD. –Ammarpad (talk) 07:06, 14 May 2018 (UTC)
  • Oppose for drafts that, if they were articles, would not fall under BLPPROD; support ONLY for drafts on living people that would otherwise fail BLPPROD. There's absolutely no reason to apply a sticky PROD to all drafts, and as noted above it's fairly BITEy to users for whom English may not be a language they can communicate well in. (There have been a few instances in -en-help where users seeking help have "keyworded", missing most of what was being said and responding only to certain words in the message.) That said, biographical drafts do still fall under WP:BLP, and so those can and probably should be allowed to be sticky PRODded if they have absolutely no sources (or ELs that can be made into sources) whatsoever. —Jeremy v^_^v Bori! 03:11, 14 May 2018 (UTC)
    @Jéské Couriano: You missed the requisite points raised above. This is not meant to apply to all drafts. It is meant only for draft that:
    • is repeatedly resubmitted
    • with no improvements,
    • has no chance of being in mainspace, and appears to
    • has no sourcing for uninvolved editors to show notability. –Ammarpad (talk) 07:16, 14 May 2018 (UTC)
    To which I'm saying that those limitations are bullshit. In essence, I'm saying "apply BLPPROD standards to biographical drafts instead of making a sticky PROD standard for all drafts". Note that my argument in favour of MfD'ing unacceptable drafts above comes with caveats more along the line of those suggestions you just threw at me. I agree with the other Opposes in that this is something that seems too half-baked and, as pointed out below, the time period the grace period provides is ludicrously short, considering most drafts tend to get abandoned due to real-life concerns. The only sticky PROD debate we should be having is whether to apply BLPPROD to drafts, not whether to BITE newcomers who may not speak very good English or who (almost invariably) have real-world commitments that make this sort of PROD so bitey. —Jeremy v^_^v Bori! 08:48, 14 May 2018 (UTC)
  • Oppose - 3.Once [a] draft is tagged with DPROD tag, then it cannot be removed unless if the person wishing to remove it has thoroughly rewrote the article and moved it to mainspace. is fairly self-evidently ridiculous, but I'll explain the fundamental flaw (among the many flaws): Deletion bar improvement should not be turned into a unilateral decision by a single editor but should remain a community decision that is made through a discussion to determine consensus. — Godsy (TALKCONT) 04:47, 14 May 2018 (UTC)
  • Oppose - Sticky and PROD don't belong together, especially not in draft which is supposed to be a safe space for article development. ~Kvng (talk) 12:57, 14 May 2018 (UTC)
Draft is for article development - you got that part right. Deletion procedure is for junk/promo that is not going to be an acceptable article. Legacypac (talk) 15:12, 14 May 2018 (UTC)
  • Oppose for this to work it would have to have objective criteria, things like "no chance of being in mainspace" and no evidence of notability are very subjective. The process doesn't make any sense at all. If I take a draft which has been sticky PRODed and add two sources which demonstrate that the subject is notable then I can't remove the tag. Not unless I'm also prepared to completely rewrite the article and get it ready to move it to mainspace before the clock expires. Having recreations subject to G4 doesn't make any sense either, and we don't apply it to other types of PROD. MfD is not being inundated with deletions of hopeless drafts and if it was then something closer to normal PROD would make more sense. Hut 8.5 18:22, 14 May 2018 (UTC)
  • Oppose. I appreciate the good intent of this idea, but I think it has the problem of setting a deadline for something that doesn't need a deadline. The main proposal above is in large part about the problem of drafts that keep getting resubmitted, but the proposal here is about drafts that are just sitting there. --Tryptofish (talk) 19:18, 15 May 2018 (UTC)
  • Oppose draft means draft.--Paul McDonald (talk) 23:22, 24 May 2018 (UTC)

The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.
  • Noting here for reference that I intend to question the detail of the close, with a view to challenge the close if it says the proposed text exactly has consensus to be locked in. It has problems. The exact text was not carefully considered by anyone that I can see. Main discussion at WT:Drafts. —SmokeyJoe (talk) 09:38, 11 June 2018 (UTC)

American English Wikipedia

No. TonyBallioni (talk) 16:47, 18 May 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Split American English Wikipedia (let's say and use British English on English Wikipedia as British English is the original dialect of English. That would solve all debates on which dialect of English should be used on which article. Erkinalp9035 (talk) 16:36, 18 May 2018 (UTC)

Articles currently in American dialect would be moved to American English Wikipedia. Articles written Australian, NZ and Indian varieties would be converted to British English. Erkinalp9035 (talk) 16:38, 18 May 2018 (UTC)

Extremely bad idea. Lots of work without any gain whatsoever. Also, Australian and New Zealand Englishes are perfectly legitimate and separate varieties of English. Mr KEBAB (talk) 16:40, 18 May 2018 (UTC)
@Erkinalp9035:, you may want to see this. The wild impracticality also applies equally to this. I also suggest reading the Manual of Style on English varieties. Good luck. Eggishorn (talk) (contrib) 16:43, 18 May 2018 (UTC)
WP:ENGVAR is already quite adequate to deal with it. Splitting projects would be a massively excessive "solution" to an already solved problem. Seraphimblade Talk to me 16:45, 18 May 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Sorry for necroposting, but MediaWiki already has a separate "en-gb" language option, so we could theoretically have a "". Lojbanist remove cattle from stage 23:29, 29 May 2018 (UTC)
It'd be better to have someway to convert articles between the two (actually all) English dialects within the same Wikipedia. I think that was originally planned for the Serbian Wikipedia (for ekavski and ijekavski dialects) using lookup tables or something.Details on that plan here. I'm pretty sure that part wasn't implemented and they only got the Latin/Cyrillic script converter. Anyway, the ekavski/ijekavski problem is a headache (go read about it) but doing English "dialects" should be really simple. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)[ᴛ] 15:38, 6 June 2018 (UTC)
There are some quirks that make it a non trivial exercise, but it could be done, it would be appreciated by some of our readers. I've argued in the past that we should go down the Chinese wiki route and let the readers choose the version of English they want displayed to them. But I now think we should first find out what proportion of English Wikipedia users would benefit. ϢereSpielChequers 11:24, 12 June 2018 (UTC)
Some words and idiomatic phrases are completely different (consider an article on torches, for example). Thus the onus would fall on editors to markup the source appropriately. I suspect this would face issues in practice. isaacl (talk) 16:17, 14 June 2018 (UTC)

WP:NOTMEMORIAL Victim lists in mass tragedy articles - Round 2

The issue of victim lists in mass tragedy articles was adressed before and the consensus was that these scenarios should be handled on a case-by-case basis. I believe the issue needs to be addressed again to finally reach global consensus due to the fact that each mass tragedy articles become a constant struggle amongst editors supporting or opposing the inclusion of a victim list. There is also another issue where outcomes of a consensus on a specific article does not count as consensus for later articles, so the back and forth edits and fights never end. Current RfC

Current language of WP:NOTMEMORIAL: Memorials. Subjects of encyclopedia articles must satisfy Wikipedia's notability requirements. Wikipedia is not the place to memorialize deceased friends, relatives, acquaintances, or others who do not meet such requirements.

I propose that we add a line to WP:NOTMEMORIAL that would either allow or prohibit listing individual victims of mass tragedies if they do not meet our notability guidelines and/or WP:BLP and they are covered in the media as part of the story of the mass tragedy event. This proposal, if approved, would also override any local consensus and precedents. Long lists containing more than 20 names should be contained in a collapsed section.

   Support = Will allow inclusion
   Oppose = Will prohibit inclusion

Cheers, --Bohbye (talk) 21:52, 23 May 2018 (UTC)


  • Support as nominator. --Bohbye (talk) 21:53, 23 May 2018 (UTC)
  • Support - I continue to say that the victims are notable in the context of the given event. This isn't just someone creating an article in order to remember their deceased loved one or friend. - Knowledgekid87 (talk) 04:04, 24 May 2018 (UTC)
  • Support — I'm reading this proposal as "allow" not "require," since that's what it says. I don't expect adding a line to WP:MEMORIAL stating this will end all disputes over victim lists. However, right now these disputes often boil down to
Proponent: I think we should have a victim list due to X, Y, and Z.
Opponent: I don't think we should have victim lists because of WP:MEMORIAL
Proponent: That's not my reading of WP:MEMORIAL.
Admin closer: No consensus.
This is simply not a helpful pattern. If WP:MEMORIAL included something like the following it would help: "This policy does not prohibit the inclusion of lists of victims of tragic events, if they serve an encyclopedic purpose, appear in reliable sources, and are compliant with other Wikipedia policies. These lists should be written to provide relevant information, rather than memorialize the lives of the victims."--Carwil (talk) 18:46, 24 May 2018 (UTC)
Proponent: I think we should have a victim list due to X, Y, and Z.
Opponent: I oppose per WP:MEMORIAL.
Proponent: MEMORIAL says we can have the list if it serves an encyclopedic purpose, appears in reliable sources, and is compliant with other Wikipedia policies.
Opponent: I disagree that the list serves an encyclopedic purpose.
Uninvolved closer: No consensus. (or the closer counts votes and calls it a consensus) ―Mandruss  17:58, 11 June 2018 (UTC)
I think the revised conversation is better, since the opponent has to explain how it serves no encyclopedic purpose. Of course there will still be disagreements but there is room for compromise and consideration of the page at hand.--Carwil (talk) 22:53, 11 June 2018 (UTC)
It it easy to "explain how it serves no encyclopedic purpose" convincingly enough for your argument to count as much as any other in the eyes of the closer. Many editors have done exactly that. There is no clear Wikipedia definition of encyclopedic purpose. Therefore your suggestion would change nothing. ―Mandruss  23:06, 11 June 2018 (UTC)

Support as 2nd choice. A mandatory rule that overrides local consensus and past precedent is a horrible idea that will require absurd and illogical outcomes. However, if the community decides to create a mandatory rule, I’d prefer for it to be inclusion for two reasons. First, this is more in-line with common practice on Wikipedia (particularly with school shootings) and will require less clean-up. Second, many tragedies are notable because of the specific victims (such as the 1943 Gibraltar B-24 crash, which killed many leaders of the Polish Government in Exile). In these cases, it is incredibly important to know the names of at least some of the victims. Further, many notable people (particular those from non-English speaking countries) do not have articles, so we’d have to hold a pre-emptive AfD for many entries into the victim list. Spirit of Eagle (talk) 19:40, 2 June 2018 (UTC)

I realized that a mandatory inclusion rule would require victim lists for pandemics such as the 1918 flu pandemic (50 million deaths, minimum), natural disasters such as the 2004 Indian Ocean earthquake and tsunami (230,000 deaths, minimum), and genocides such as the Rwandan Genocide (500,000 deaths, minimum). Most commenters in this RFC agree that victim lists are appropriate in some articles but not others; the main dispute here is over the proportion of articles in which victim lists are appropriate, not whether they are appropriate period. I think this RFC would have been more helpful if it proposed a default rule that could be overruled with local consensus instead of a mandatory rule that must be obeyed even in illogical situations. Spirit of Eagle (talk) 20:47, 2 June 2018 (UTC)


  • Oppose, policy is meant to be descriptive, not prescriptive. As it stands, this type of information gains consensus to be included in some articles and fails to in others, so there is clearly no consensus that this should always or never be added. Therefore, case by case discussion, as is current practice, is the proper way to settle it. Seraphimblade Talk to me 22:17, 23 May 2018 (UTC)
    • Seraphimblade, I'm not sure that your response matches the description above for what "oppose" is supposed to mean. WhatamIdoing (talk) 02:55, 24 May 2018 (UTC)
  • Oppose, the victims of mass tragedies are (generally) not notable, they are simply the people who happen to be in the area when the event occurs. Even in the case of mass shootings (where this debate keeps popping up), most of the perpetrators are not targeting specific people, they are simply killing anyone in the way. Obviously there are some minor exceptions. The vulcanologist who was killed by the eruption of Mount St. Helens while collecting data, a newscaster who is blown away by a tornado while on air, a passenger on a jet who attempts to stop hijackers, a shooting victim who was called out by name in the perpetrator's manifesto. But notice that these are highly specific things. For most victims of these tragedies the story would have been exactly the same if anyone else had been there and their names give us no real extra data. --Khajidha (talk) 11:58, 24 May 2018 (UTC)
  • Oppose but with appropriate exceptions. We should encourage editors to avoid these, unless there are reasonable circumstances, notably that if discussing the event that it is impossible to do so without mention some of these people. --Masem (t) 02:30, 25 May 2018 (UTC)
  • @Masem: My understanding is that this is about complete lists of names and ages, not prose about selected notable victims. They are separate issues and I think most opponents of the former do not oppose the latter outright, although we might disagree on the meaning of "notable". In my opinion your !vote is the same as mine in the following subsection. ―Mandruss  02:36, 25 May 2018 (UTC)
  • Oppose, lack of notability. — Preceding unsigned comment added by Edibobb (talkcontribs) 02:08, 27 May 2018 (UTC)
  • Oppose, with appropriate exceptions per Masem and Khajidha. The status quo, however attractive it may seem to !vote for, has not served as well, and provides a justification for battleground that is really unnecessary. The wording should at least strongly discourage the practice of inclusion. No such user (talk) 13:35, 31 May 2018 (UTC)
  • Oppose. For the normal reader it is an utterly meaningless and worthless list of names randomly pulled out of the phonebook (with my apologies to the family and friends of the deceased). For the normal reader, it serves absolutely no encyclopedic purpose. Name(s) should only be included where it provides some identifiable and distinctive purpose for a generic reader. If it's a relative of the perpetrator, or a celebrity who gets individualized news coverage, or one of Khajidha's examples, it makes sense to have a textual-discussion of those individuals. To make the point reducio ad absurdum, there's no reason we should treat the victims of a mass shooting any differently than the victims of 9/11. A list of 20 random names is just as useless as a list of 2,996 random names. Alsee (talk) 00:53, 1 June 2018 (UTC)
  • Oppose - 2nd choice because there should be explicit provision for exceptions. Superior to status quo, however, per my comments elsewhere in this proposal. ―Mandruss  01:25, 1 June 2018 (UTC)
  • Oppose a list of the names of non-notable people who were killed in an event has no point other than to memorialize the victims in question. While I feel for the people involved, that is not the point of an encyclopedia. Cataloging the victims of various of events is a noble pursuit, but is more suited to another venue. My conclusion would be to prohibit victim lists unless the victim meets general notability requirements. It is either that or we have to decide where to draw the line. Does every soldier who died during a battle get listed in an article about the battle? How about everyone killed by the Nazis at Auschwitz in it's article? The list could do on. {{u|zchrykng}} {T|C} 05:39, 5 June 2018 (UTC)
  • Oppose, If for no other reason then who gets to decide what is deserving of such memorials? Victims of Terror, Mass shootings, collateral damage? Too much room for edit warring and POV pushing.Slatersteven (talk) 15:41, 6 June 2018 (UTC)


  • Status quo Continue deciding ona case-by-case basis. Beeblebrox (talk) 01:38, 24 May 2018 (UTC)
  • Status quo One-size-fits-all policies are rarely useful at Wikipedia. --Jayron32 02:28, 24 May 2018 (UTC)
  • Status quo, since apparently "oppose" doesn't actually mean, well, "oppose", but I oppose making such a change. Policy is meant to be descriptive, not prescriptive. As it stands, this type of information gains consensus to be included in some articles and fails to in others, so there is clearly no consensus that this should always or never be added. Therefore, case by case discussion, as is current practice, is the proper way to settle it. Seraphimblade Talk to me 22:17, 23 May 2018 (UTC)
  • Status quo - 2nd choice. - Knowledgekid87 (talk) 04:04, 24 May 2018 (UTC)
  • Default to omit, exceptions by local consensus - There was a minor but distracting outcry of "Not this again!" when the list was disputed at Santa Fe High School shooting, and the RfC for that case is underway. If "Status quo" or "no consensus" is the result here, it must be stressed that "Not this again!" is inconsistent with that result and thus an invalid complaint. If the community kicks this decision down to article level, despite the fact that the relevant factors and circumstances are essentially the same in each successive case, then the community is saying it must be re-litigated at each successive case. I oppose that as a waste of editor time, and I support omission as default with provision for exceptions by local consensus. The difference between that and the simple "decide case-by-case" is that any arguments for exception would be required to show what is unusual about the case that justifies exception to the default. My rationale for supporting omission rather than inclusion as default is found here (first !vote). ―Mandruss  04:09, 24 May 2018 (UTC)
  • Status quo. Continue deciding on a case-by-case basis. One-size-fits-all policies are rarely useful at Wikipedia. Case by case basis with no default rule. Some take WP:NOTAMEMORIAL way out of context. It is meant to shut down stand alone bios on deceased friends and family. It is not meant to exclude the mention of a murder victim name within the context of a page about a notable crime. Bus stop (talk) 05:38, 24 May 2018 (UTC)
  • Omit excepting strong local consensus I'm not entirely sure what adding a comprehensive list of victims adds to an article, and as some users commented at the last RfC, it may be seen as disrespectful to mention people purely for how they died (WP:BLP1E). If some victims are notable for other reasons, sure it may make sense to list them. However, there may well be cases where listing all victims makes encyclopedic sense, and local consensus should be sovereign where it exists. Richard0612 12:46, 24 May 2018 (UTC)
  • Generally Support Inclusion I think generally murder victims names and often ages (which helps distinguish the victum from other people with the same name) are an important part of every murder story that are almost always covered by reliable sources repeatedly. We have almost always covered the victim names for other notable murders like Golden_State_Killer#Original_Night_Stalker There is a trend in the media to even deemphasize the killer's name and emphasize the victims for notoriety reasons. Some take WP:NOTAMEMORIAL way out of context. It is meant to shut down stand alone bios on deceased friends and family. It is not meant to exclude the mention of a murder victim name within the context of a page about a notable crime. Do to privacy and accuracy reasons I do not support releasing victim names before they are released by law enforcement and published in RS or the listing of all wounded victims, which needs to be considered on a case by case basis. If child Mary Jones is shoot in the leg and survives she does not need to be named on wikipedia but if Jane Smith gets shot and earns an award for heroism we may well name her. Legacypac (talk) 12:48, 24 May 2018 (UTC)
  • Status quo. The current wording, which in general would appear to prohibit the mass listing of names, but would allow for it if there were a good reason (mainly notability), seems fine.  — Amakuru (talk) 12:59, 24 May 2018 (UTC)
  • Status quo - Case by case basis with no default rule. I have supported inclusion on the two most recent mass shooting pages I have participated in, but I see examples where it was decided to exclude the names, and if there is another situation where that is what the consensus is decided to be I have no problem with it. WikiVirusC(talk) 13:22, 24 May 2018 (UTC)
  • Status quo - Should be done on a case-by-case basis, Seems the logical answer..... –Davey2010Talk 14:10, 24 May 2018 (UTC)
  • Status quo - There are some cases where setting notability as a threshold would be a good idea. But, there are other cases, like where there are seven or so victims, and one notable person among them, when including the names of all killed would be a fine idea. Overall, having a guideline to cite isn't very good when that guideline has lots of good exceptions. RileyBugz私に叫ぼう私の編集 20:13, 24 May 2018 (UTC)
  • Status quo I'd suggest that it mostly depends on the number of names, if there are only a handful then it makes some sense to include them, if there are hundreds then it probably isn't a good idea. There are other factors that could affect the decision though. Hut 8.5 20:30, 24 May 2018 (UTC)
  • Default to include, allow exclusion per local consensus After every major shooting, we seem to have the exact same debate about whether to include a list of victims. The debatealmost always centers around the same general arguments rather than the details of the specific shooting. Having to debate the same point again and again is a waste of time and is starting to ware on the nerves of many editors. Establishing a default rule instead of continuously debating the same point would be in the best interest of Wikipedia. I would prefer for the default rule to be inclusion of the lists for the reasons I explain here. Spirit of Eagle (talk) 01:51, 25 May 2018 (UTC)
  • Status quo These are the type of articles where the need for editorial judgement is the greatest. Drawing lines in the stand is rarely useful. Cullen328 Let's discuss it 07:32, 25 May 2018 (UTC)
  • These local discussions are never about the characteristics of the case. They are regurgitations of the same general arguments about victim lists, over and over. The result depends merely on the mix of the editors involved in the local decision. And there are always many editors who !vote based largely on precedent, as if that showed a community consensus, when in fact it does not. If there were such a community consensus, it would be affirmed in discussions like this one. The status quo is a mess, and the only way to resolve it is to reach a community consensus for something other than status quo. ―Mandruss  08:09, 25 May 2018 (UTC)
  • Status quo Bearing in mind that WP:BLP1E still applies in the "breaking news" phase. I know that's aimed at articles, but the last thing I want to happen is for us to repeat an innaccurate list, potentially causing great distress to an affected family. There are some articles that a list of the victims just doesn't make any sense - e.g. The Holocaust. At the same time, sometimes it makes sense. Bellezzasolo Discuss 20:03, 2 June 2018 (UTC)
  • Status quo Going to squeeze in just under the wire to note that a case-by-case basis simply seems the most logical to me. — Javert2113 (talk; please ping me in your reply on this page) 18:43, 6 June 2018 (UTC)
  • Depends. Do what the historical secondary sources say — if they report a list of names, that's reasonable, but if not, don't. And don't go advocating the fringe theory that news reports are secondary sources: I'm talking secondary sources as defined by professionals. Nyttend (talk) 02:17, 9 June 2018 (UTC)


Memorial:General discussion

The two suggested "votes" may be confusing people. The options might be better framed like this:

  1. Require victim lists (if verifiable; WP:SPLIT to a stand-alone list if large)
  2. Decide separately for each article (permitted with consensus; status quo)
  3. Prohibit (no lists, except in extraordinary situations)

If people can be clear about what they mean in their comments, that would probably be more helpful than "support" or "oppose". WhatamIdoing (talk) 03:05, 24 May 2018 (UTC)

Victim lists have long been an issue. I was involved in a related local discussion nearly 5 years ago which had some interesting points raised. Cesdeva (talk) 11:47, 24 May 2018 (UTC)

Well it appears that nothing has come out of this discussion, the issue is going to continue to be fought out and re-discussed to death. Sorry if I sound pessimistic here but I have seen it play out now many times from both sides presenting the same arguments. Why would one school shooting for example be different than another with the same talking points presented? - Knowledgekid87 (talk) 17:28, 29 May 2018 (UTC)

Remarkably, at least one editor—an editor with extensive experience—has declined to help form a consensus with the rationale that there is no consensus. Apparently, avoiding pointless expenditure of editor time is seen by many as an improper use of community consensus. ―Mandruss  23:48, 29 May 2018 (UTC)
Are you seeing something above that implies anything other than the status quo (no change)? This has been discussed in one way shape or form for years now, something is going to have to give eventually. - Knowledgekid87 (talk) 17:42, 4 June 2018 (UTC)
@Knowledgekid87: I'm not sure I understand the question. If you're asking how I read the consensus to date, of course it leans toward status quo. If the trend holds, I know WP:how to lose and I'm resigned to the continued waste of time, but I will respond negatively to further "Not this again!" protests at article level. This will be the clear will of the community, and every editor should respect it. ―Mandruss  18:21, 4 June 2018 (UTC)

I suggest the closer apply extra care evaluating individual responses. We have a striking situation where there are !votes in three different sections all saying the exact same thing: names can be included if they serve an encyclopedic purpose. People are just coming at it from different angles. If we get stuck with yet another RFC on this same question I suggest extra effort to more clearly articulate that position. The current drafting looks too much like "Always include all names" vs "Never include any names". Alsee (talk) 01:08, 1 June 2018 (UTC)

Agree that the framing is poor, as might be expected from a very-low-time editor. I offered to collaborate on framing and my offer was ignored. But to me the drafting looks like "prohibit lists" (Oppose) vs "don't prohibit lists" (Support). In any case, I think it was clear from the start that the question is about complete lists of names and ages; that's what "victims list" means. It is not about prose about selected notable victims, and I'm pretty sure that some !voters have missed that essential point. It certainly is not about lists of names and ages of selected notable victims with no explanation for what makes them notable; that should never be on the table for obvious reasons. ―Mandruss  01:47, 1 June 2018 (UTC)
@Alsee:, @Mandruss:: I think Alsee has the correct read of responses posted here and Mandruss has the correct read of the proponent's intent in writing the RfC. Above, I tried to offer a succinct clarification of the policy that summarizes when victim lists are appropriate: ""This policy does not prohibit the inclusion of lists of victims of tragic events, if they serve an encyclopedic purpose, appear in reliable sources, and are compliant with other Wikipedia policies. These lists should be written to provide relevant information, rather than memorialize the lives of the victims." I could offer this as the basis for a future RfC, or we could refine it here, and then have an RfC about it. What do people think?--Carwil (talk) 19:30, 12 June 2018 (UTC)
Most of the opposition to victims lists is that they inherently do not "serve an encyclopedic purpose", so I don't know what that would accomplish. Victims lists either generally serve an encyclopedic purpose or they generally do not, and that is something that can and should be decided, at community level, for all victims lists in mass killing articles (with provision for rare exceptions).
Further, closers cannot read the minds of the participants, and forgive me for believing that many supporters whose desire was to memorialize the victims would say that their aim was to serve an encyclopedic purpose, if that's what it took to get a list included. Ends justify means, very often. ―Mandruss  20:24, 12 June 2018 (UTC)
Carwil if the closer has trouble extracting a clear result here, then I agree with your suggested followup RFC. However I think your text needs adjustment. When writing policies&guidelines it's often key to write for the audience who is motivated to not-find the answer we're trying to provide. You essentially wrote that uncontroversially-good content is permitted, and an over-enthusiast-list-maker can argue that your text says nothing against their list. I suggest starting with a default that victim names are generally inappropriate, then add "unless..." to allow names with a genuine purpose. I think consensus is that, in a disputed case, the person adding names is expected to offer a credible rationale beyond "listing victims". Alsee (talk) 01:35, 13 June 2018 (UTC)
Agree with Mandruss. The entire point is that these lists of names are not encyclopedic content. Individual names may serve an encyclopedic purpose, but the burden of proof should be to show that mention of each name (individually) serves an encyclopedic purpose. --Khajidha (talk) 15:53, 14 June 2018 (UTC)

Making widely-used icons consistent and modern

Look into most used files. We have four different information icons in the top thirty images. Most of them are also really old designs with lots of details (which was a thing in mid 2000s but not anymore) and they don't scale down to the size that they are being used. Most used icons are mostly in three categories:

  • Portal icons
  • *-stub template icons
  • *mbox templates

I hereby suggest using more modern set of icons that are more abstract (for example see Template:Astronomy-stub) or more specificity from these five sets: c:OOjs_UI_icons (icons used in the interface of mediawiki), Wikipedia 15 icons, c:Category:Material Design icons (because of the similarity), and c:Category:Emoji One BW (because of the diversity of the inventory). If not, at least putting some style guide for the icons. Ladsgroupoverleg 23:58, 26 May 2018 (UTC)

Yeah, I agree. Another icon-related thing: does anyone want Wikimedia to implement some form of HTML5 Canvas? Lojbanist remove cattle from stage 02:14, 27 May 2018 (UTC)
  • While on the subject, I would really like a new set of icons for Portal:Contents to represent the categories, they all have to be SVG and the same size, so anything in the way of better / more modern CC0 / PD icons would be great. JLJ001 (talk) 14:36, 27 May 2018 (UTC)sockstrike Galobtter (pingó mió) 17:02, 3 June 2018 (UTC)
  • All those icons look rather flat, one toned, and overall meh. —Farix (t | c) 16:30, 27 May 2018 (UTC)
  • Whole-hearted support. Ladsgroup, I think you're a hero for proposing this. A lot of our visual iconography around here is a product of the trends early-2000s that birthed Wikipedia, and it's hugely overdue for a facelift. A flatter look like that represented by those material design icons would go a long way towards updating the look and feel. However, this is the most subjective matter imaginable, so I'm not sure how far this will get. But I'll with you all the way. A Traintalk 23:44, 27 May 2018 (UTC)
  • This is something worth looking into, but of all the possible arguments in favor of changing some of the icons, saying that they're no longer fashionable is really the bottom of the barrel, in my opinion.
    Anyway, let's put together some examples of the icon set. To compare:

Some current icons:

Warning icon Please stop disruptive blah blah blah.

Compared to icons from the proposed sets:

Warning icon Please stop disruptive blah blah blah.

--Yair rand (talk) 03:09, 28 May 2018 (UTC)

The proposed icons are mostly horrible and not inline with the aesthetics of the project. The puzzle piece especially, which loses the Wikipedia logo entirely. I don't mind the new scales however. Do it on a case by case basis, but remember that most of the use of the 'bad' icons (like some assy .jpg version) is due to the substitution of old templates that have long been updated to look better. Headbomb {t · c · p · b}
I agree about the puzzle logo but other ones look way better. Specially having consistency in the look seems great to me. We can use more blue in the icons to give the sense of ink Ladsgroupoverleg 04:41, 28 May 2018 (UTC)
  • I am with Headbomb here. Most the icons look crap on Wikipedia, but there are some improvements that can be made with the icons that do look good, so by all means. JLJ001 (talk) 19:42, 28 May 2018 (UTC)sockstrike Galobtter (pingó mió) 17:02, 3 June 2018 (UTC)
  • Mixed - I would say the same - the new scales look nice, but the others are less so, especially the puzzle piece as noted. Consistency all well and good, but some consideration on whether the older or more modern design is better in each case would be advisable Nosebagbear (talk) 12:24, 29 May 2018 (UTC)
  • Support. It should be noted that the French Wikipedia is attempting something similar. Lojbanist remove cattle from stage 23:26, 29 May 2018 (UTC)
  • Ladsgroup, I genuinely have no opinion on this topic, but do you think it would be better to wait until this discussion is finished before changing all the icons? Primefac (talk) 16:59, 3 June 2018 (UTC) (please ping on reply)
    Primefac The last edit on the discussion was about four days ago and I mostly wanted to be bold and change things gradually (changing everything in one go would be complicated and I don't want to do that.) Ladsgroupoverleg 17:06, 3 June 2018 (UTC)
    Fair enough, guess I wasn't paying that much attention to the timestamps, more the fact that there's about 50/50 for/against so far. Primefac (talk) 17:10, 3 June 2018 (UTC)
    I don't think you should be changing the icons. I don't see a consensus for changing, with many complaining about the OOUI icons being flat/bad, and personally I don't like the new information icon that much; I don't hate it though, and could be convinced on it. Probably need an RfC if you want to change things; and IMO either use the new OOUI information icon or the old one, but mixing seems horrifying. At the very least, all the warning templates should use the same icon. I've reverted the changes since they don't seem to have any consensus. Galobtter (pingó mió) 17:16, 3 June 2018 (UTC)
    There is a design style guide that explains why icons have been designed this way. This is a good read. Let's make subsections to move forward Ladsgroupoverleg 17:25, 3 June 2018 (UTC)
    I've posted a link to this discussion at Template talk:Ambox. I think notices should probably be posted on talk pages of all templates that will have icons changed. --Yair rand (talk) 23:27, 3 June 2018 (UTC)
  • Oppose I *do* think it's time to change the icons somewhat, and the proposed ones do look modern and nice, but I don't think these would be best for the message we're trying to send with these icons. Jjjjjjdddddd (talk) 16:08, 7 June 2018 (UTC)
  • I support the general idea; this has long been overdue. I do not support some of the proposed replacements, because they might miss the point ("neutrality icon", see below). We should not blindly take these icons from a library. We should modify these SVGs (one reason why SVGs are awesome) to match our requirements. I'll go ahead with the black exclamation mark. Give me a few minutes, I hope. ~ ToBeFree (talk) 01:10, 10 June 2018 (UTC)
  • Oppose: I agree with Jjjjjjdddddd and ToBeFree: it's time for a change, but let's not borrow these icons wholesale. We're Wikipedia, after all, and SVGs give us a chance to add our own mark to the icons and, perhaps more importantly, discuss the changes. (Mostly the discussion, I suppose, but I digress.) Moreover, the icons presented could use some modification to suit our needs, though I do like their sleekness. — Javert2113 (talk; please ping me when you reply) 01:27, 10 June 2018 (UTC)
  • Oppose all. No need to change it all. Take it on a template per template basis. – Finnusertop (talkcontribs) 03:45, 11 June 2018 (UTC)
  • Oppose: That puzzle piece looks terrible compared to the one we have now. - Knowledgekid87 (talk) 14:23, 11 June 2018 (UTC)
  • Oppose all so far. The single-color ones are harder to discern with bad eyesight. DaßWölf 19:36, 11 June 2018 (UTC)
  • I use the desktop interface, and on that interface I don't see a need to change. If people using smartphones would benefit from the mobile interface displaying simpler icons then I have no objection to something that serves simpler icons on mobile or very low resolution display options. But if this is about replacing the fad of fifteen years ago for a current fad then please don't. Wikipedia has its own style and there is an advantage in being consistent in that, not doing change for the sake of change. ϢereSpielChequers 11:34, 12 June 2018 (UTC)
  • Since it somehow didn't get mentioned below, Oppose the new version of the puzzle piece for the reason given by Headbomb.--Khajidha (talk) 14:28, 13 June 2018 (UTC)
  • Late to the party oppose because there seems to be no need for what is being suggested. Happy days, LindsayHello 14:54, 18 June 2018 (UTC)
  • Oppose the suggestion of these specific icons, but a Strong Support for the general idea of a more unified icon system. Miss on execution, but I'd love to see a better formulated attempt at this suggestion. Lusotitan (Talk | Contributions) 18:10, 18 June 2018 (UTC)

Changing information icon

This is proposal to replace blue information icons (Information.svg Information icon4.svg) with the OOjs one (OOjs UI icon info big progressive.svg) Ladsgroupoverleg 17:27, 3 June 2018 (UTC)

  • Support as proposer. Ladsgroupoverleg 17:27, 3 June 2018 (UTC)
  • Oppose - this icon is less visible to me. --Khajidha (talk) 00:19, 5 June 2018 (UTC)
  • Support: This is not a warning icon. It doesn't need to be big, red and visible. ~ ToBeFree (talk) 01:06, 10 June 2018 (UTC)
  • Oppose: Admittedly, it may be my poor eyesight, but this icon is less visible to me, as well. The lack of a shadow effect, I believe, is what's causing this. Or the light effect. Not really sure how to describe it. — Javert2113 (talk; please ping me when you reply) 01:27, 10 June 2018 (UTC)
  • Oppose - The ones we have now are more visible and get the job done. - Knowledgekid87 (talk) 14:20, 11 June 2018 (UTC)
  • Oppose. I like the blue background. Maybe something like one of these Emojione 2139.svg Breezeicons-emblems-8-emblem-information.svg (although ideally darker)? — pythoncoder  (talk | contribs) 19:23, 12 June 2018 (UTC)
  • Oppose Less striking or visible or obvious. This seems like a solution in search of a problem. Happy days, LindsayHello 14:54, 18 June 2018 (UTC)
  • Oppose There is nothing wrong with the old one. We don't need to be changing things to one solid color MS paint-style icons that stand out less. Natureium (talk) 18:35, 18 June 2018 (UTC)

Changing alert icon

This is proposal to replace red alert icons (Ambox warning pn.svg Nuvola apps important.svg) with the OOjs one (OOjs UI icon alert destructive.svg) Ladsgroupoverleg 17:30, 3 June 2018 (UTC)

New proposal

With a black exclamation mark and a darker red triangle: Change Ambox warning pn.svg and Nuvola apps important.svg to OOjs UI icon alert destructive black-darkred.svg

  • Support as proposer. ~ ToBeFree (talk) 01:39, 10 June 2018 (UTC)
  • Weak support: I still like the lighting effects. — Javert2113 (talk; please ping me when you reply) 01:56, 10 June 2018 (UTC)
  • Support: nice, clean separation between triangle and exclamation point. --Khajidha (talk) 10:52, 10 June 2018 (UTC)
  • Only if other icons are changed to have a similar flat-coloring scheme — pythoncoder  (talk | contribs) 14:23, 11 June 2018 (UTC)
    • What is more important than style is having some amount of consistency. — pythoncoder  (talk | contribs) 19:24, 12 June 2018 (UTC)
  • Neutral because there doesn't really seem (to me) to be any point to it; the original and the (second suggested) replacement are very similar, so why bother? As mentioned earlier, if this is about changing and old style for a new style/fad, it's not worth it. Happy days, LindsayHello 14:54, 18 June 2018 (UTC)
  • Oppose - I wouldn't be devastated, but the lighting/texture effect is pleasant on this one and I wouldn't say the new one is any nicer. While the proposal is clearest, the current ones are more than clear so I don't think any change is beneficial. Nosebagbear (talk) 15:11, 18 June 2018 (UTC)
  • Oppose The new one looks less modern and more like the simplest shape someone could make on MS paint. The old one is already clean enough. Natureium (talk) 18:34, 18 June 2018 (UTC)

Changing scale icon

This is proposal to replace scale icons (Unbalanced scales.svg) with the emoji one version (Emojione BW 2696.svg) Ladsgroupoverleg 17:33, 3 June 2018 (UTC)

  • Support as proposer. Ladsgroupoverleg 17:33, 3 June 2018 (UTC)
  • Oppose - this icon is used to signal a lack of neutrality, for that the unbalanced scale seems more appropriate. --Khajidha (talk) 00:22, 5 June 2018 (UTC)
  • Oppose an unbalanced scale should be used to show lack of balance or neutrality. Graeme Bartlett (talk) 02:40, 5 June 2018 (UTC)
  • Oppose per above. Jjjjjjdddddd (talk) 16:06, 7 June 2018 (UTC)
  • Oppose per above: The replacement is missing the point. ~ ToBeFree (talk) 01:06, 10 June 2018 (UTC)
  • Oppose per above. Not really what we need. — Javert2113 (talk; please ping me when you reply) 01:27, 10 June 2018 (UTC)
  • Oppose per Graeme Bartlett. — pythoncoder  (talk | contribs) 14:03, 11 June 2018 (UTC)
  • Snow Oppose The one we have now not only looks better but is also unbalanced as per above. - Knowledgekid87 (talk) 14:22, 11 June 2018 (UTC)
  • Oppose Clearly, as pointed out above, the replacement is inferior. Happy days, LindsayHello 14:54, 18 June 2018 (UTC)


Please suggest replacements for the following icons as well.

  • Information orange.svg
  • Stop hand nuvola.svg

Thanks ~ ToBeFree (talk) 01:06, 10 June 2018 (UTC)

Wouldn't the replacement for the orange information icon simply be the same as the blue one but with the color changed? And what is the point of having the hand up as well as the Stop sign? Wouldn't one part or the other be sufficient on its own? --Khajidha (talk) 13:21, 13 June 2018 (UTC)

Revise WP:NPOL so that someone who wins primary qualifies for more information in Wikkipedia

In any election, the incumbent has a great advantage over a challenger. Wikipedia's NPOL policy means that incumbent is by default notable but challenger isn't. As a service to our readers, instead of just re-directing from name of challenger (who at least in the US got some coverage running in primary election) to district race URL, could we not give more information about the race as exemplified for example here?[26] I understand reasoning behind our current model. I do not propose that, after general election, we continue to host info on challengers who are not otherwise notable. I do not propose to change notability criteria for any other categories such as NACTOR etc. But I think we can do better for general elections. What do others think? HouseOfChange (talk) 19:35, 27 May 2018 (UTC)

"I do not propose that, after general election, we continue to host info on challengers who are not otherwise notable." That seems to make the proposal a WP:NOTNEWS violation. We don't temporarily host information just to make races more fair; that's simply not Wikipedia's thing. Huon (talk) 19:39, 27 May 2018 (UTC)
(ec)In an article on the race you can say as much as sources and WP:DUE allow about any candidate, and balanced coverage is good. As to biographical articles, you seem to be suggesting a form of temporary notability, which we don't do. Johnbod (talk) 19:42, 27 May 2018 (UTC)
OK so for example, if you search for Texas candidate Lizzie Pannill Fletcher you end up at page for Texas 7th district, which has zero info about challenger Fletcher but a link to incumbent she will challenge. I am suggesting that such a page (for election) has a section for some links or info about positions of both candidates. I agree with Huon that it will be unnecessarily tricky to create a new category of "temporary notability." I am searching for a way to benefit our readers without requiring painful contortions of Wikipedia principles. HouseOfChange (talk) 20:03, 27 May 2018 (UTC)
The best solution in such a situation is to add neutral, well-referenced information about each of the candidates to the redirect target, describing the race neutrally. Articles about unelected candidates tend to start out as campaign brochures masquerading as encyclopedia articles, and then are often loaded up with cherry-picked negative information added by supporters of rival candidates. It is a mess. Cullen328 Let's discuss it 20:08, 27 May 2018 (UTC)
I agree 100% with the lively description of Cullen328 about articles of politicians. Cullen, if you can give an example, on any page you like of what and WHERE such info might go, that would be a great help. Sleepily, from Sweden, HouseOfChange (talk) 20:15, 27 May 2018 (UTC)
In the current case, HouseOfChange, the information can go in the District 7 section of United States House of Representatives elections in Texas, 2018. If you look at sections for other districts, you will see that some have information about various candidates. There could be 36 neutral spinoff articles about the races in all 36 Texas Congressional districts. Cullen328 Let's discuss it 20:28, 27 May 2018 (UTC)
Thanks, Cullen328, I do not propose to write 36 spinoff articles, but I will try to wrie one or 2 and see what reception is for them. HouseOfChange (talk) 21:07, 27 May 2018 (UTC)
  • Comment generally there haven't been stand-alone articles on US House races, but based on the discussion at Wikipedia:Articles for deletion/California's 39th congressional district election, 2018 it seems that it is permitted, at least for races that generate national-level coverage (normally well-correlated with competitive races).
    As far as notability of candidates: I'm not happy with the current system, but don't see a better alternative yet. Notability is not temporary, and proposals that suggest current candidates are notable but will not be notable after the election are exceptionally unlikely to find consensus. Some candidates (Kara Eastman, Mark Walker) have been kept at AfD recently.
    Finally, as a procedural note, this is a fairly good time to have this discussion; there's enough time before any election that there's no obvious benefit for any political group associated with any policy change, but enough activity to give specific examples rather than hypotheticals. power~enwiki (π, ν) 22:35, 27 May 2018 (UTC)
  • Oppose In the case of the U.S. House of Representatives, there are very few competitive seats in any election cycle. Cook estimates that less than 100 of 435 seats are competitive [27] in 2018, for instance. That means that in three-quarters of all U.S. congressional races, the general election challenger candidate will often be either a perennial candidate or someone simply running as a party standard-bearer with no hope or intent of election and no organized campaign. Over the next six years, that means we could potentially accumulate hundreds of biographies of individuals notable for no other reason than they once spent 15 minutes filling out a certificate of candidacy. Further, many general election candidates for congressional office already are usually able to meet notability standards absent this proposal as they will frequently be former state legislators who are inherently notable, or in some other way pass the WP:GNG. Candidates for competitive house seats are rarely unknowns. Chetsford (talk) 04:56, 5 June 2018 (UTC)
  • Credible candidates in competitive House races are usually notable—Rather than try to generate a temporary rule, I want to suggest that in a polarized political environment, virtually every credible candidate in a swing district is getting "significant coverage in reliable sources that are independent of the subject of the article." Shortly after the primary, you should be able to defend them using the GNG, which NPOL specifically directs you to do.--Carwil (talk) 19:43, 12 June 2018 (UTC)
  • Oppose. I understand the intent is good... so I apologize in advance... but I'm about to cast this in the ugliest light possible. The proposal here is for Wikipedia to give non-notable individuals temporary free campaign advertising, because Wikipedia wants to alter the outcome of elections. I know, the intent is to be "more fair", but I subscribe to a rather purist view of Wikipedia policy. We write policies for strictly encyclopedic purposes, not trying to fix issues out in the world. Individuals who are already notable(Donald Trump cough cough) have an inherent advantage in elections. That is true no matter what we do. We shouldn't screw up our policies trying to fight that inevitable fact. The world isn't fair, we can't solve that. We're also already overloaded with work to do without having to try to manage a highly politicized category of "temporary" articles, especially when they lack the sort of sourcing we require to handle them properly. In some cases we'd have little more than campaign-adverting&attack-counter-advertising as sources to work with. We don't want to cross those streams. It would be bad.(Try to imagine all life as you know it stopping instantaneously, and every molecule in your body exploding at the speed of light.) Alsee (talk) 02:25, 13 June 2018 (UTC)
  • Oppose Wikipedia is not in the business of being a voter's guide. Winning a primary is a pretty low bar, and it is not much higher if, in the US, you restrict that to the two main parties' primaries. In the best of times these articles would be partisan battlegrounds and an attractive nuisance for off-wiki trolls and partisans. In short, if they were not notable enough for an article before then simply being successful in their party's selection process does not make them more so. Jbh Talk 02:54, 13 June 2018 (UTC)
  • Hopefully not needed per Carwil. It really is concerning that Wikipedia might be magnifying the advantages of incumbency (the concern is not so much "fairness" to individual challengers as it is having a realistic prospect of dismissing incumbents). But as others have noted, as encyclopedists per se, that's not really our problem. But hopefully GNG will suffice. --Trovatore (talk) 03:07, 13 June 2018 (UTC)
  • Oppose - as a one-time major party nominee myself, I feel this is falsifying our concept of notability. Think of it as the political equivalent of BLP1E. --Orange Mike | Talk 03:14, 13 June 2018 (UTC)
  • Oppose per all of the above, and biasing our rules to advantage subjects from one country is flat-out not acceptable. This proposal is tailored to suit the peculiarities of the US election system, and that makes it prima facie unacceptable, this website is not the Yankopedia. Roger (Dodger67) (talk) 15:24, 18 June 2018 (UTC)
  • Comnent I don't believe we should change policy. What we need to do is actually follow what's written. Many editors seem to discount any national coverage about unelected candidates as not being able to satisfy GNG, though that's not anywhere in the official guidelines. I believe the regular GNG requirements are already specific enough to determine whether unelected political candidates are notable. I can understand desiring some amount of non-local coverage for unelected candidates, but I disagree with the idea that well sourced and useful national coverage about candidates should be deleted just because the person is unelected or loses their election. It would be far more difficult to fully document elections and get a complete view of the election when all the coverage for the losing side always gets deleted. We had an extremely widely covered district attorney race recently, and the information about the losing candidate is historically important to understand the race and some of the actions of the winning candidate, even if the loser never does anything else notable. Second, I can understand that Wikipedia shouldn't be used as a campaign brochure, but I think the regular policy guidelines are enough to fight cases like that. Third, it seems against the purpose of Wikipedia to delete well sourced information and national coverage about candidates right as people are looking for and need that information the most. Lonehexagon (talk) 22:24, 20 June 2018 (UTC)

Throttle edits adding excessive disambiguation links

In my long experience as a disambiguator, I have observed that the larger the number of disambiguation links added in a single edit, the more problematic that edit is likely to be in other respects as well, such as containing copyvios, overlinking, creating a sea of non-notable red-links, adding walls of text, or indiscriminate data dumps. I think an edit that adds more than, say, links to twenty different disambiguation pages should probably at least bring up a notice advising the editor to review Wikipedia's policies and MOS and consider whether they need to adjust their writing before saving the edit. I will add that, out of the hundreds of thousands of edits made on Wikipedia per day, only a handful have this characteristic. Nevertheless, it would quite often save a lot of work if the editor adding the disambiguation links (and likely other issues) would get a heads up, rather than other editors needing to puzzle them out afterwards. bd2412 T 03:36, 28 May 2018 (UTC)

bd2412, that sounds like an excellent idea. The next step would be to put in a request on phabricator. If that doesn't get results, drop me a line on my talk page and I will create a proposal and push them until I get a yes or no answer. --Guy Macon (talk) 08:30, 30 May 2018 (UTC)
  • This is in the same vein as various semi-perennial proposals for alerting users before they save certain types of edits: ones that introduce unsourced text, spelling mistakes, etc. In fact, there was a proposal in 2016 for similarly alerting editors when their contributed text contains links to dab pages. To rehash in the current context some of the reasons why these have all failed: 1) they introduces additional hoops for good-faith new editors to jump through (not good in the context of declining new editor numbers), 2) the presence of many dablinks by itself is only a minor problem that can easily be fixed afterwards, and 3) the real problem is the presence of copyvios etc, and these might or might not come along with the type of edit that would get picked up: the software will have no way of telling which edits are problematic and which aren't.
    Also, worth remembering that articles with more than 8 dablinks get swiftly tagged by DPL bot, which places them in Category:Pages with excessive dablinks (which currently has three members), where they can be examined by experienced editors. And the user who introduced any number of dablinks will promptly receive a talk-page notification (unless their edit count is below 100 or they have specifically opted out). – Uanfala (talk) 22:26, 30 May 2018 (UTC)
    • The previous proposal was to throttle the addition of any new dab links. This is for edits adding a relatively high number. To add one or two disambiguation links in an edit is easy. To add more than ten takes a special kind of absence of forethought. I would add that very frequently the sort of editors who add masses of text laden with disambiguation links are the sort who have fewer than 100 edits. Suppose for the sake of argument we were to say that we would do this for edits adding 20 new links to disambiguation pages? Or 50? Or 100 (since I have seen that happen on rare occasion)? bd2412 T 11:52, 31 May 2018 (UTC)
      • I have a lot of sympathy this goal, but AIUI throttling can only be done through the edit filter, which means that it has to be computed on every single edit at the time of saving, and that's expensive (slow) for every single edit. I don't think that the rest of the community would love having every single edit slowed down. WhatamIdoing (talk) 19:42, 8 June 2018 (UTC)
        • Isn't that what the edit filters are already doing? bd2412 T 16:51, 10 June 2018 (UTC)
        • Also, can we at least do something to catch obvious disambig-linking vandalism like this? bd2412 T 16:10, 11 June 2018 (UTC)

RfC: Delete IABot talk page posts?

A previous RfC halted new talk page posts by InternetArchiveBot.

This RfC is to see if there is consensus to delete the posts. It affects about 1 million talk pages. An example post that would be deleted.

There are two options for deletion:

#1 - a bot edits the 1 million pages deleting posts. Archived talk pages will be left alone. Bot operator User:GreenC has volunteered.
#2 - the wording of the post is modified to give users permission to delete posts if they want to. Since talk page posts normally can't be deleted by other users, it would remove that restriction. The wording can easily be changed via the {{sourcecheck}} template, it would not require every page be edited.

Please !vote support or oppose. Clarify choice of method #1 and/or #2 in order of preference.

- Rod57 (talk) 16:02, 29 May 2018 (UTC)


  • Support as nominator. Prefer #1 but would be happy with #2 - Rod57 (talk) 16:02, 29 May 2018 (UTC)
  • Oppose for now, as the nominator has not explained what benefit (if any) there would be in doing this. Compassionate727 (T·C) 16:14, 29 May 2018 (UTC)
Because the posts clutter talk pages and confuse editors. They won't be archived in most articles, most have no automatic archiving or enough traffic to warrant archiving. If you still oppose why not support choice #2? -- GreenC 18:23, 29 May 2018 (UTC)
  • Oppose making another million edits here. Looks like these mostly all use {{sourcecheck}} - just add some verbiage there. — xaosflux Talk 16:47, 29 May 2018 (UTC)
Choice #2 says this. Are you then in support of #2? -- GreenC 18:17, 29 May 2018 (UTC)
I'm pretty indifferent to option 2, just strongly opposed to option 1. If going for option 2, certainly need to check if there are other uses outside of this use case that could lead to unintended impacts. — xaosflux Talk 19:42, 29 May 2018 (UTC)
  • Option 2 per the {{sourcecheck}} argument. Just change the text. In most cases it'll get archived anyway. — AfroThundr (tc) 17:05, 29 May 2018 (UTC)
Choice #2 says this. Are you then in support of #2? -- GreenC 18:17, 29 May 2018 (UTC)
  • Comment - See choice #2  :-) -- GreenC 18:26, 29 May 2018 (UTC)
  • Oppose everything — literally not a single reason to make a million edits to remove once-useful things. Unless there's a good reason, we need not retroactively remove material. I don't see a need to change the template to encourage folks to delete them, they're not hurting? What's the need here? ~ Amory (utc) 19:45, 29 May 2018 (UTC)
  • Support deletion Option #1 or any deletion plan is fine. This text is spam and information pollution which wastes huge amounts of time by continually distracting users to read this text. It is of no use to anyone. This text never should have been posted and for as long as it persists it is actively spoiling the Wikimedia user experience. At least archive it all; preferably delete it outright. Blue Rasberry (talk) 19:59, 29 May 2018 (UTC)
  • Oppose option #1 as something that could cause more harm than good, especially if a new bot has to be designed to handle this workload. I just don't think it's worth the time and effort just to create more page revisions that don't do anything constructively. I would be okay with rewording, per option #2, but again, I don't see a need to do it retroactively to past posts. Surely, if anyone cared, I'm sure after rewording the post others would interpret that as being safe to remove past posts if they wish, and no one would find a problem with that. Red Phoenix talk 21:44, 29 May 2018 (UTC)
  • Oppose The posts get archived on active talk pages and lend meatiness to article talk pages that otherwise have seen little activity. I've actually used IABot's messages to do some close checking and don't want to see my work deleted, if it still exists where it hasn't been archived. Dhtwiki (talk) 21:55, 29 May 2018 (UTC)
  • Oppose option 1, indifferent on 2 as long as the template isn't used elsewhere. That said, this seems to be a solution in search of a problem - has the fact that the messages exist been raised as a problem before now? ƒirefly ( t · c · who? ) 22:15, 29 May 2018 (UTC)
@Firefly: Yes, below in the discussion, I have raised the existence of the messages as a problem. Blue Rasberry (talk) 22:51, 29 May 2018 (UTC)
@Blueraspberry: You say that the messages 'consume human time', but what evidence is there for this, or for this being a problem? Tone doesn't come across well in text, so please rest assured that I'm genuinely interested in this - do you have any data to back up that such messages eat up reader time (unnecessarily), or are they just scrolled past in a second or two. ƒirefly ( t · c · who? ) 23:01, 29 May 2018 (UTC)
@Firefly: This is spam. Spam consumes small amounts of time and attention from large groups of people giving benefit to almost none. Which of these premises do you dispute? - there are millions of these messages, tens of thousands of people read them, they have a life of years, the talkpages show tens of millions of views, there is a body of research publication which describes how spam / advertising consumes time and spoils an environment, these messages ask for minutes of time from all readers, people prefer to moderate their environment's level of spam, this kind of messaging is unprecedented in Wikimedia projects. Most people scroll past in 2 seconds but even that is unacceptable multiplied times millions. Many people read the messages the first few times and some people actually respond. Blue Rasberry (talk) 13:11, 30 May 2018 (UTC)
  • Oppose all Please do not edit one million pages (or even one hundred pages) without a clear benefit. The watchlist turmoil alone is not worth it. A worse problem is the wasted effort as puzzled editors check what happened on the talk pages they monitor. I would scratch my head if I saw a bot modify another bot's message. Johnuniq (talk) 23:09, 29 May 2018 (UTC)
  • Option 2 requires editing ONE page. Not a million. Can you re-evaluate Option 2? -- GreenC 18:25, 30 May 2018 (UTC)
  • Please make a proposal with precise wording, preferably brief. However, you don't need an RfC to edit a single template. I don't see a need to add a "you have permission to delete this" message. If someone is too inexperienced to know they can delete a bot's message if it's a nuisance they should not be fiddling with talk pages. Johnuniq (talk) 00:52, 31 May 2018 (UTC)
  • @Johnuniq: I agree that permission isn't actually needed on any given single article, but Rod57 initially proposed something roughly reflecting your position on the template's talk page and ended up running this RfC at least in part because I asserted that mass removal of the messages, regardless of whether done by bot or by encouraging human editors to do so, is something that would require community approval (mea culpa). Even (especially?) experienced editors are indoctrinated to never ever mess with others' talk page comments, so I think adding such a message to the (already transcluded) template would have an effect beyond just "stating the obvious". I suspect the "precision" you find missing in the framing of this RfC is due to an attempt at brevity and neutrality from someone who has never constructed an RfC before. I hope that tradeoff won't make necessary restarting it entirely. --Xover (talk) 06:16, 31 May 2018 (UTC)
  • oppose; per above. This has the potential to waste users time by alerting them to the automated change. Also possible is wasted editing hours as people discuss the issue during the fallout. In any case, particularly with regard to the example given above, we would almost certainly appreciate a human user leaving such a TP summary after making a non-minor edit affecting sourcing, why should a bot's contribution be less valid/useful. Agree with discussion points below - that brevity should be considered and would support improved brief messages if they can be shortened. Edaham (talk) 08:25, 30 May 2018 (UTC)
  • Oppose Solution 1 per cost benefit; would
  • Weak Support number 2 per User:GreenC . GenQuest "Talk to Me" 11:46, 30 May 2018 (UTC)
  • Oppose making edits to every talk page with such a message, there's no point in flooding watchlists for that. Don't care if the solution is changing the wording of a transcluded template, as implied might be the case in option 2. Anomie 12:17, 30 May 2018 (UTC)
  • Oppose Option 1, meh for Option 2. Don't see the point in removing the notices systematically, especially many of those were made at a time when IABot wasn't super reliable. I've removed IABot messages before myself, so if you want to add a message to a template IABot used to mentioned this is an option, sure. I don't think it's going to make much of a difference, but I'm not oppose to that. Headbomb {t · c · p · b} 12:34, 30 May 2018 (UTC)
  • Support Option #2 and Would not oppose Option #1. I manually remove these on "my" articles if they happen to annoy me (clutter), and see no reason why others should not feel free to do the same, with or without "permission" from the template message. Changing the message to explicitly allow this (subject to normal local consensus), provided it is backed by community consensus in this RfC, has effectively zero cost and mainly reaffirms the status quo. Mass removing them by bot seems excessive for the problem: they're just a bit of clutter, and we have a ton of that in various other forms. Better to avoid the watchlist noise and potential for wikidrama such mass edits can engender. I would not, however, be opposed if consensus was to bot-remove them: I just don't think it's a big enough deal either way to feel strongly about it. (PS. Kudos to Rod57 for setting up this RfC. It's good to have a community consensus as guidance, either way.) --Xover (talk) 13:11, 30 May 2018 (UTC)
  • Support #2, neutral on #1 I hear the arguments against 1 on the basis of the many edits, although I'm not sure how much of a problem it would be. However, it would be sensible to allow users to remove notices in areas where they constitute clutter. Tamwin (talk) 16:42, 30 May 2018 (UTC)
  • Oppose Option 1 and Support Option 2 which pretty much lets sleeping dogs lie. The posts are spam and were a nuisance when made, but make further nuisance only to those readers who read old posts. Waking this sleeping dog will make a new, similar nuisance to my fellow talk page stalkers. Yes, my opinion is based on a guess that the new nuisance will be bigger than the remaining nuisance value of the old spam posts. No use complaining when other guesses lead to other opinions. Jim.henderson (talk) 18:46, 31 May 2018 (UTC)
  • Support option 2: the messages are useless, but not worth the trouble of performing a million of edits. Option 2 seems like a good choice in addressing the perceived issue. --K.e.coffman (talk) 20:26, 31 May 2018 (UTC)
  • Oppose All - There is no benefit to editing over a million pages just to delete a bot message ..... They can and will be archived eventually, I and others archive talkpages and most talkpages have the archive bot .... if they're not archived then who cares ? ..... The proposal IMHO does not in any way, shape or form help with the goals of Wikipedia. –Davey2010Talk 20:53, 2 June 2018 (UTC)
  • Oppose option 1, indifferent to option 2 I'm just not seeing the problem with letting old Archivebot messages stick around: they aren't causing any harm and they'll eventually go away on their own through talk page archiving. I strongly oppose option 1 since it will require a ton of work for little benefit. Option 2 only requires a single edit, so I have no objection to it. I don't think it will accomplish much, but if the community wants it I won't oppose. Spirit of Eagle (talk) 23:11, 2 June 2018 (UTC)
  • Support option 2, to clarify that one doesn't really need to check the bot's edits nor to edit any talk page template. Those requests were just terrorism imposed by users who didn't believe in the success of the bot. Neutral on option 1: the whole message should have been a template, but the subst-worshippers would have opposed that; the real solution for the future is to avoid adding so much text in talk pages, changing Wikipedia:Substitution if necessary, to make it clear that it's vastly better to insert boilerplate text via templates. --Nemo 07:01, 3 June 2018 (UTC)
  • Oppose option 1 - the benefit doesn't justify the volume of talk spam. No opinion on Option 2; I have WP:OneClickArchiver enabled which can remove them from the talk page already. power~enwiki (π, ν) 23:52, 4 June 2018 (UTC)
  • Oppose both options. This is unnecessary, will clutter watchlists and history, and remove slightly useful posts. Graeme Bartlett (talk) 02:50, 5 June 2018 (UTC)
  • I will add that option 2 will be much worse than the original posting of messages on the talk page, since all the talk pages will be changed, and will waste so much time in people finding out what happened, for no benefit at all. Graeme Bartlett (talk) 22:57, 6 June 2018 (UTC)
  • Oppose both options, per Davey2010 and Johnuniq. — Javert2113 (talk; please ping me in your reply on this page) 21:50, 5 June 2018 (UTC)
  • Oppose Option 1 because mass edits like that would be immensely unnecessary but support Option 2, so that the messages can be removed where they are actually an obstruction. BegbertBiggs (talk) 15:04, 9 June 2018 (UTC)
  • Oppose option 1 and support option 2. If people need to be told that removing trivial and deprecated bot messages does not breach WP:TPO, then let's tell them. – Finnusertop (talkcontribs) 10:33, 14 June 2018 (UTC)


The persistence of advertising and spam messages consume a huge amount of human time and attention and bring no benefit. The Wikipedia community currently does not anticipate or measure the costs of mass messaging millions of discussion posts to hundreds of thousands of readers. If a message has a life of years, then if great numbers readers spend their time considering great numbers of messages, then this wastes hundreds of hours of Wikimedia community time in an unsatisfying user experience. We have to keep Wikipedia clean of unproductive distractions! See my previous rants on this topic:

No bot should be allowed to consume hundreds of human hours about its automated activities! Remove these messages immediately and avoid ever allowing this again! Blue Rasberry (talk) 21:47, 29 May 2018 (UTC)

No evidence any significant amount of time is spent on these. They were turned off precisely because everyone just ignores them. On active talk pages they'll be archived quickly, on inactive pages they won't get seen. ~ Amory (utc) 00:46, 30 May 2018 (UTC)
I'm in general agreement with Bluerasperry on the principle, but must note that I consider the concern somewhat overblown on this particular instance of the issue. In general we should strive to be mindful of editor attention, including both article and user talk page messages, and "noise" in people's watchlists; but not to the exclusion of useful functionality or information. There is certainly wasted attention caused by these messages, but they are not entirely devoid of compensating value (how much is a subjective call). And excessive effort expended on them, relative to all the other more pressing issues the project faces, is likewise not a good use of the same limited resource (editor attention). --Xover (talk) 13:00, 30 May 2018 (UTC)
@Xover: I really appreciate your acknowledgement that editor attention is a limited resource. I can understand and accept that different people will calculate cost/benefit in time in different ways, but I find it challenging to understand how anyone could say that the cost is zero or immeasurable. Thanks for the reply. Blue Rasberry (talk) 14:08, 31 May 2018 (UTC)
No one said the cost was zero, just that what the exact cost is is at best a guess that depends on a lot of assumptions, which ultimately yields little to no insight on anything. Headbomb {t · c · p · b} 17:11, 31 May 2018 (UTC)
@Bluerasberry: Per Headbomb, I don't think anyone is asserting that the cost of editor attention is zero. But they may disagree that leaving the old messages in place affects (uses) editor attention to any degree worth mentioning, or they may care so much more about the editor attention wasted by noise in watchlists and possibly discussions and wikidrama arising from the removal as to consider the other to be insignificant. Or they just think other factors are more important. An RfC !vote is the distilled result of the conclusion drawn after considering the various factors and assigning them your particular relative merit: it is not an expression of ignorance of, or active dismissal of, other concerns. It's "Here's what I think is important", not "What you think isn't important", if you'll pardon the simplification. --Xover (talk) 05:19, 1 June 2018 (UTC)
I would not criticize others. For myself, I fail to understand the other side, and for myself, I feel a lack of ability to express what I see in a way that makes me feel understood. Thanks for the encouragement. Blue Rasberry (talk) 10:35, 1 June 2018 (UTC)
I'll note that we have a reasonably accurate proxy of the attention gains by the bot's activity, namely clicks on its userpage. --Nemo 07:19, 3 June 2018 (UTC)
  • Can they at least be put under 1 <h2/> tag titled == "External links modified" == and then each time the bot runs it just adds the date as an <h3/> (===6 June 2018===)?  Nixinova  T  C  04:28, 6 June 2018 (UTC)

Nutshell templates

I am proposing that the nutshell templates be used in Wikipedia's encyclopedic articles to provide a quick summary about a particular subject. Please let me know what you think of this proposal.
Example: United States

--2601:183:101:58D0:B420:71FD:AA18:2464 (talk) 21:54, 3 June 2018 (UTC)

No. That’s what the lead section is for. Beeblebrox (talk) 22:29, 3 June 2018 (UTC)
The first sentence at United States reads: "The United States of America (USA), commonly known as the United States (U.S.) or America, is a federal republic composed of 50 states, a federal district, five major self-governing territories, and various possessions." We think our readers are capable of reading and comprehending a 33-word sentence; 10-year-olds are not our target audience. What reader benefit does your nutshell add that justifies the added clutter? ―Mandruss  22:31, 3 June 2018 (UTC)

Why do policy and guideline pages use the nutshell template? Why not use the first sentence of the article? --2601:183:101:58D0:B420:71FD:AA18:2464 (talk) 23:03, 3 June 2018 (UTC)

See WP:SHORTDESC. This is a project that does almost exactly what you are looking for. Bradv 23:28, 3 June 2018 (UTC)
Nutshell banners work well when the page is a lengthy set of instructions and the reader needs help to understand what they should do or focus on. For an encyclopedia article, what Brad noted. A database of 5 million short descriptions on any topic is quite useful on its own, can be used on mobile apps, book reading apps, Google search result page, etc.. but when landing on the encyclopedia page itself, it's redundant with the lead section. -- GreenC 14:04, 7 June 2018 (UTC)
  • Many pages already have an info box that serve that purpose. A "nutshell" box across the top seems redundant.--Paul McDonald (talk) 21:35, 12 June 2018 (UTC)

It has been twelve days since the start of the discussion, and as of this closure, there are about 26 supporting comments versus 30 opposing comments. Supporters argue that the proposed filters could result in difficulty in accessing or uploading to Wikipedia and its sister projects, with one user comparing it to SOPA. Opposers argue that Wikipedia should not be used for political advocacies, or that the site should generally remain neutral in political affairs. Even if you ignore the !vote count, taking into account the discussion and the amount of feedback generated here (about half that of the ultimately unsuccessful NN banner RfC), there is at best no consensus to put up a banner as proposed. With that said, the WMF and Jimbo have stated that they have raised concerns about the proposed directive, particularly Article 13, and their position is noted.

There was also a proposal to put up a neutrally-worded banner that would provide information about the directive without pushing any particular position of it. It was supported by some users from both the support and oppose sides, but ultimately there was not enough discussion on it to have any sort of consensus of approval either.

With that said, the discussion leaves open the possibility towards proposing a neutrally-worded banner, which would then be the topic of a new discussion.

(non-admin closure) Narutolovehinata5 tccsdnew 00:51, 18 June 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Background: please see this discussion started by Jimbo Wales on his talk page.

I propose that a site-wide banner be displayed through June 20, 2018, on all language Wikipedias including the English Wikipedia, when geolocation indicates that the reader is in an EU jurisdiction, explaining the upcoming June 20 European Parliament vote on the copyright law changes being considered there which could severely impact all Foundation projects, including a link directly to

Note that the Wikimedia Foundation already has an official position on this issue: Doctorow (talk) 03:13, 6 June 2018 (UTC)

Background information

Collated information on the effects of the law on Wikipedia

  • The EU's Copyright Proposal is Extremely Bad News for Everyone, Even (Especially!) Wikipedia, EFF
  • 70+ Internet Luminaries Ring the Alarm on EU Copyright Filtering Proposal Update to EFF by Danny O'Brien and Jeremy Malcolm, June 12, 2018, including link to protest letter text

Filtering proposal

(taken from @Doctorow:'s message on Jimmy's talk page)

  • Sites that make material available to the public are required to filter according to rightsholder-supplied lists of copyrighted content
  • Even if they do filter, they are still liable if infringing material is uploaded and made available
  • If you believe that you have been unfairly blocked, your only remedy is to contest the block with the host, who is under no obligation to consider your petition
  • There are no penalties for falsely claiming copyright on material -- I could upload all of Wikipedia to a Wordpress blocklist and no one could quote Wikipedia until Wordpress could be convinced to remove my claims over all that text, and Wikimedia and the individual contributors would have no basis to punish me for my copyfraud
  • There was a counterproposal that is MUCH more reasonable and solves the rightsholders' stated problem: they claim that they are unable to convince platforms to remove infringing material when the copyright rests with the creator, not the publisher (e.g. Tor Books can't get Amazon to remove infringing copies of my books because I'm the rightsholder, not them); under this counterproposal, publishers would have standing to seek removal unless creators specifically objected to it
  • There is a notional exception for Wikipedia that carves out nonprofit, freely available collaborative encyclopedias. This does get WP a lot of latitude, but Article 13 still has grossly adverse effects on WP's downstream users -- anyone who mirrors or quotes WP relies on the safe harbours that Article 13 removes. Think also of all the material on EU hosts that is linked to from Wikipedia References sections -- all of that could disappear through fraud or sloppiness, making the whole project (and the whole internet) more brittle

Position of Wikimedia organisations


Please post any questions about the law and how it might affect Wikimedia projects:

  • Do we currently make use of copyrighted material in a way that would be affected by being in violation of this "law"?Slatersteven (talk) 18:26, 7 June 2018 (UTC)
    • @Slatersteven: yes, "it could also require Wikipedia to filter submissions to the encyclopedia and its surrounding projects, like Wikimedia Commons. The drafters of Article 13 have tried to carve Wikipedia out of the rule, but thanks to sloppy drafting, they have failed: the exemption is limited to "noncommercial activity". Every file on Wikipedia is licensed for commercial use." ref.
    • @Slatersteven: No, no direct impacts on Wikimedia projects as the text currently stands in both Council and Parliament. All non-for-profit projects would be excluded, which means all our projects. If our content is used commercially this would happen on another, non-Wikimedia service. That being said, the wording is not final and sloppily written, so no guarantees it will stay this way. But there is a clear political will to exclude all Wikimedia projects. --dimi_z (talk) 20:20, 7 June 2018 (UTC)
I asked how we would be in violation of it, maybe I was not clear. If this rule was in place now what do we do that would mean we would could be prosecuted for being in breach of it (assuming that it does not have an exemption)?Slatersteven (talk) 09:21, 8 June 2018 (UTC)
  • What effect would this law likely have on sources Wikipedia uses for references? E.g academic journals and newspapers. John Cummings (talk) 18:31, 7 June 2018 (UTC)
    • "Under Article 11, each member state will get to create a new copyright in news. If it passes, in order to link to a news website, you will either have to do so in a way that satisfies the limitations and exceptions of all 28 laws, or you will have to get a license."refJohn Cummings (talk) 19:44, 7 June 2018 (UTC)
  • What effect would this law likely have on websites that Wikipedia sources open license media content from? e.g Flickr John Cummings (talk) 18:31, 7 June 2018 (UTC)
    • Flickr would have to filter all uploads. --dimi_z (talk) 20:20, 7 June 2018 (UTC)
  • Does this law effect Wikimedia Commons? John Cummings (talk) 19:13, 7 June 2018 (UTC)
    • Yes, see answer to question 1.
    • No it doesn't affect Commons, as commons is also a non-for-profit service (but compromises not final).--dimi_z (talk) 20:20, 7 June 2018 (UTC)


  • Support as proposer. EllenCT (talk) 23:20, 4 June 2018 (UTC)
  • Oppose for similar reasons as not doing anything about net neutrality and not coming off as political. TonyBallioni (talk) 23:24, 4 June 2018 (UTC)
  • Oppose. No using banners to advocate for or against political policies unless there's an existential threat involved. --Yair rand (talk) 23:30, 4 June 2018 (UTC)
    Further, even if this is an existential threat, the correct way to act against it would not be to link to an external site, and certainly not one like that. "The European Commission and the Council want to destroy the Internet as we know it and allow big companies to control what we see and do online." That's not a sentence Wikipedia can be associated with. --Yair rand (talk) 00:23, 5 June 2018 (UTC)
  • Oppose As with the last time someone suggested a political banner, I see no reason that this is appropriate for wikipedia. Natureium (talk) 23:36, 4 June 2018 (UTC)
  • Apparently there is an existential threat, see the post by Doctorow at 19:44, 4 June 2018 here. This proposal should not have been made without clear information. Johnuniq (talk) 23:39, 4 June 2018 (UTC)
The first link in this section includes that description. I agree it certainly does represent an existential threat to the freedom of content re-use, even if the exception for encyclopedias was carved out to prevent direct legal attacks on the existence of the wikipedias. Other projects such as Wikisource would certainly be directly at risk, but they don't reach as many EU citizens as enwiki banners would. EllenCT (talk) 23:47, 4 June 2018 (UTC)
  • Support:
    • European Copyright Law Isn't Great. It Could Soon Get a Lot Worse.
    • Updated position paper: Article 13 remains a terrible idea and needs to be deleted
    • Copyright wars are damaging the health of the internet
    • Article 13 could "destroy the internet as we know it": What is it, why is it controversial and what will it mean for memes?
    • EU censorship machines and link tax laws are nearing the finish line
    • European Copyright Leak Exposes Plans to Force the Internet to Subsidize Publishers
    • Text of the proposal: English Other languages and formats
--Guy Macon (talk) 23:43, 4 June 2018 (UTC)
  • Support. According to [28], "France, Italy, Spain and Portugal want to force upload filters on not-for-profit platforms (like Wikipedia) and on platforms that host only small amounts of copyrighted content (like startups). Even if platforms filter, they should still be liable for copyright infringements of their users under civil law, just not under criminal law." There is a time to panic, and unless someone can come through and show that all this is not true, then this is that time. If the EU enacts this, we should immediately and permanently block all access to Wikipedia from the EU, globally lock EU-linked editors on all WMF projects, and disband all EU Wikimedia chapters and liquidate any assets there. For a start. We should do that in two weeks. Or we can do a banner now. Your choice. Wnt (talk) 23:53, 4 June 2018 (UTC)
    European chapters have no legal responsibility whatsoever for Wikimedia sites, IIRC. Does the WMF even need to listen to European copyright laws at all? What we need now is an analysis by WMF Legal on what the ramifications of this would be. Panicking isn't helpful. --Yair rand (talk) 23:57, 4 June 2018 (UTC)
    There is a duty of care. If the above comes to pass, anyone participating in a European chapter would be subject to very extensive legal harassment and it is not reasonable to pass that responsibility on to them. Johnuniq (talk) 00:07, 5 June 2018 (UTC)
  • Comment It's not reasonable to claim that the WMF is not subject to EU law and thus action is not necessary. I'm skeptical about some of the claims made by opponents of this measure, but if they are accurate I would support an EU-wide blackout in response. I'd like to hear whether the WMF or their lawyers have an opinion before !voting. power~enwiki (π, ν) 00:06, 5 June 2018 (UTC)
  • It may not appear reasonable, but it is the case the the WMF servers are in the US, and US opyright law is controlling, not EU copyright law. There may be personal risk for individual editors, but there's no more risk to the WMF's projects than if China changed its copyright laws, or Melanesia. Beyond My Ken (talk) 01:28, 5 June 2018 (UTC)
    • Beyond My Ken: I’m going to take the opportunity to point out that Wikimedians are already individually liable for every action we take on WMF projects, so if the concern here is that individuals will be held more accountable for stealing the intellectual property of others, well, good for the EU in my book. If there is actually an existential threat to the WMF, I’m sure their legal team would be on it. TonyBallioni (talk) 01:46, 5 June 2018 (UTC)
    • US copyright law is (fortunately for us) not all-controlling. Local copyright law is also important. WMF does need to comply. The point is the opposite; individual editors are not affected; WMF is. But it's not complaining. Hawkeye7 (discuss) 02:28, 5 June 2018 (UTC)
  • I think you have it backwards, but I'm not prepared to mount a detailed exegesis. My understanding is as my comment above. Beyond My Ken (talk) 04:25, 5 June 2018 (UTC)
  • Support This has wide-ranging implications for the sources WP relies on, for downstream users of WP, and for WP itself. It's an unworkable and dangerous proposal that it antithetical to WP and any future project founded on similar principles. [Wikimedia has already taken an official position in opposition to this] a year ago when the proposal was first mooted. Now it's on the brink of passing and it's actually gotten worse in the intervening year. Note that I'm a consultant to the Electronic Frontier Foundation which has opposed this since the start, so I'm hardly impartial, but WMF and EFF are on the same side here, and I think Wikipedians should be too. This is a real problem for the whole project and needs to be averted. Doctorow (talk) 00:19, 5 June 2018 (UTC)
  • Comment added to Template:Centralized discussion. Holding off on a !vote per Power. TeraTIX 01:19, 5 June 2018 (UTC)
  • Support absolutely flabbergasted with the mountain of oppose votes solely on the grounds of "political bias". The proposed law has wide-ranging implications, which at worst could mean closing Wikipedia in the EU. It doesn't help that the proposal was made so soon after the net neutrality one was closed. Net neutrality was arguably harmless, but I just can't see how this law could possibly not have substantial negative effects on Wikipedia. We can't afford to gamble on Wikipedia exceptions being added to the final bill. The one political cause we should campaign for is our own. (see Headbomb) TeraTIX 23:30, 8 June 2018 (UTC)
  •  Question: Is there a Wikipedia article on this topic? Thanks. Mike Peel (talk) 01:28, 5 June 2018 (UTC)
I've created Directive on Copyright in the Digital Single Market. It's fairly difficult to find "neutral" sources here, and I'm not even sure how the EU makes legislation. Hopefully the magic of collaboration will improve it. power~enwiki (π, ν) 06:16, 5 June 2018 (UTC)
  • Oppose per TonyBallioni's concerns about being perceived as politically biased. — BillHPike (talk, contribs) 01:31, 5 June 2018 (UTC)
  • Oppose Unless the WMF is supporting such a banner (Jimbo != WMF) we have generally decided that politically-oriented banners are not appropriate. If the WMF want to enforce one, if they feel the issue is significant enough, they have ways to push that themselves. --Masem (t) 01:49, 5 June 2018 (UTC)
  • Oppose: While I'm sympathetic to the arguments here, I am somewhat weary of requests for politically-oriented banners. If the Foundation wishes to do it themselves, they can (and, by all means, they should, if they feel that strongly about this issue), but the voters of Europe have made their choices, and it's not our place, as a worldwide community of editors, to browbeat, cajole, or even attempt to persuade them otherwise, through the usage of Wikipedia. So, just as I voted on net neutrality (twice), I vote again: please, no more political banners/alerts/whatever on Wikipedia. — Javert2113 (talk; please ping me in your reply on this page) 02:40, 5 June 2018 (UTC)
  • Oppose for many of the reasons stated above. While I can see the harm to the wider internet if this passes, I'm not convinced that this poses an existential threat to Wikipedia which I believe is the only case where such banners are appropriate. Winner 42 Talk to me! 02:55, 5 June 2018 (UTC)
    • @Winner 42: this article outlines the direct threats of the law to Wikipedia, thanks, John Cummings (talk) 19:54, 7 June 2018 (UTC)
      • Wow, that reads like it was written in response to this thread. I did find one factual error though. Doctorow states, "Every file on Wikipedia is licensed for commercial use." A relatively large amount of copyrighted content is already used under fair use doctrine and is not licensed for commercial reuse. That said, this hardly rises to an existential threat. Worst case, some European sources get harder to find. I think Wikipedia could reasonably ignore most of what this is because it is US based and I seriously doubt that Europe has the political capital to block or fine Wikipedia. Winner 42 Talk to me! 17:18, 8 June 2018 (UTC)
  • Oppose any political banners, as always. — Godsy (TALKCONT) 03:44, 5 June 2018 (UTC)
  • Oppose As above and echoing the oppose votes for net neutrality banner further up. We should be careful with political banners. doktorb wordsdeeds 04:38, 5 June 2018 (UTC)
  • Oppose per TonyBallioni and oppose Political banners and this is a political issue and feel there other fora are better for this.Pharaoh of the Wizards (talk) 05:49, 5 June 2018 (UTC)
  • Oppose Though I'm sure the proposal is with good intent, ultimately this is an encyclopedia and not a campaign rally. Chetsford (talk) 07:27, 5 June 2018 (UTC)
  • Oppose and suggest some plan to formally document somewhere that generally politically-themed banners from any country will not be run, to save editors time in discussions like this. It is all evident from recent proposals, that consensus cannot be reached on issues like this. –Ammarpad (talk) 07:35, 5 June 2018 (UTC)
  • Oppose. I don't think we should be in the business of championing political causes, and adding a guideline to that effect sounds like a good idea. If the WMF decided this was a threat to the movement and wanted to campaign against it, that would be a different matter. That is part of their job, after all. – Joe (talk) 10:59, 5 June 2018 (UTC)
  • Oppose. On June 11, net neutrality will be adopted as official U.S. policy, and if internet can survive in America, it can survive in Europe too. wumbolo ^^^ 11:48, 5 June 2018 (UTC)
  • Oppose, at this point we should ask WMF for more information and advice about this situation instead of speculating based on opinion pieces and advocacy sites (such sites may very well be correct, but they do not offer an unbiased perspective on controversial topics). Also, as already pointed out by others: it would be helpful to discuss a more general guideline about prohibiting political (and other) advocacy on English Wikipedia and to clarify the handling of possible exceptional cases (if any). GermanJoe (talk) 12:27, 5 June 2018 (UTC)
  • Comment Not an existential threat as Wikipedia can easily exist without the EU, see also the Turkey block. While bad for editors in the EU (including myself), if this comes to pass we might as well fork the encyclopedia, it seems a saner strategy at this point. I find it interesting btw. how people point at WMF whereas WMFs strategy has been to ask the community. Seems a bit circular. :) —TheDJ (talkcontribs) 14:01, 5 June 2018 (UTC)
    • Sure, for that matter Wikipedia can continue existing even if tomorrow a biological attack kills the entire humanity. It just won't have any user. --Nemo 21:09, 5 June 2018 (UTC)
      • Well it's clear that the community is fine with that, isn't it ? The ideals have eroded to the point where we effectively ARE the Encyclopaedia Brittanica that we replaced. —TheDJ (talkcontribs) 10:19, 6 June 2018 (UTC)
  • Support, we need to be able to address laws that directly affect Wikipedia. (Note that I am not thrilled by the not very informative nature of ). We regularly have banners claiming Wikipedia will die if users don't donate -- the potential threat from bad legislation seems worse than two years without donations. —Kusma (t·c) 14:07, 5 June 2018 (UTC)
  • Oppose, the community is here to build an encyclopedia, not for political campaigning. Proposals like this are on their way to WP:PERENNIAL. – Finnusertop (talkcontribs) 18:45, 5 June 2018 (UTC)
  • Support compared to net neutrality, this appears to actually have a direct and major effect on wikipedia in the EU, closer to WP:SOPA. Hope to get a statement from the WMF on how exactly this would affect us though. Galobtter (pingó mió) 21:05, 5 June 2018 (UTC)
  • As Galobtter and Kusma say, this is legislation which directly affects our copyleft and wiki model: not only it directly affects Wikipedia, but of all possible topics in the world it's the one where we can't avoid having an opinion and can't avoid being the most competent to talk (copyleft is the third pillar, folks). On the other hand, it's a bit hard for a community like ours to give a clear and short message among stacks of open letters signed by hundreds of organisations, piles of papers by hundreds of academics, hundreds of competing amendments. Realistically, the true menace will be clear after the JURI vote and the final call to arms will be before the vote in the European Plenary, like last time. After the committee vote, it's certainly too late to have a good law, but it won't be too late to stop a bad one. If we use all our bullets now, we will be harmless when the lobbies come up with yet another trick against Wikipedia. --Nemo 21:30, 5 June 2018 (UTC)
  • Support great idea. Nocturnalnow (talk) 21:45, 5 June 2018 (UTC)
  • NEUTRAL Oppose yet ANOTHER PROPOSED WIKI-BANNER CRYING WOLF about the end of civilization as we know it. When can these well-intentioned—but badly conceived proposals—and the accompanying Wiki lawyering, just stop? If the WMF speaks out on the issue, ping me... GenQuest "Talk to Me" 23:17, 5 June 2018 (UTC)
Ping. This is highly relevant for everyone to read.--Jimbo Wales (talk) 14:04, 7 June 2018 (UTC)
I agree the article makes a good point. Particularly about how difficult this would make editing for our average users, per:

...Third, the broad and vague language of Art. 13 and the compromise amendment would undermine collaborative projects that rely on the ability of individuals around the world to discuss controversial issues and develop content together. Free knowledge that is inclusive, democratic, and verifiable can only flourish when the people sharing knowledge can engage with each other on platforms that have reasonable and transparent takedown practices. People’s ability to express themselves online shouldn’t depend on their skill at navigating opaque and capricious filtering algorithms. Automatic content filtering based on rightsholders’ interpretation of the law would—without a doubt—run counter to these principles of human collaboration that have made the Wikimedia projects so effective and successful.

For that reason alone, I would not condemn action by the site regarding this issue regarding Article 13, and change my opinion to Neutral for this activity if it is deemed by consensus that either a Banner or Blackout to be necessary by the WMF. Thanks for the input, Jimbo. Regards, GenQuest "Talk to Me" 23:04, 14 June 2018 (UTC)
  • Oppose per all the oppose comments - Exactly as the opposition to the US net neutrality banner. Also this would mean identifying from cookies/IP adresses the location of our users/readers. Our encyclopedia is international and it must remain apolitical. Kudpung กุดผึ้ง (talk) 07:42, 6 June 2018 (UTC)
@Kudpung: "Also this would mean identifying from cookies/IP adresses the location of our users/readers" eh. we already do that for almost every single banner.. Since at least 2009. —TheDJ (talkcontribs) 10:24, 6 June 2018 (UTC)
TheDJ, I have no idea. I'm an editor not an IT expert. Kudpung กุดผึ้ง (talk) 14:23, 6 June 2018 (UTC)
Apolitical? LOL. I have a list of articles I would like you to make apolitical.... HiLo48 (talk) 08:12, 6 June 2018 (UTC)
HiLo48 then as a Wikipedia editor there are things you can do about it. Hope your list is not too long...Kudpung กุดผึ้ง (talk) 14:23, 6 June 2018 (UTC)
Kudpung Some I can work on. Give me time. Some are owned by unprincipled Admins who would rather see me banned forever. There is no hope there. (For those articles or those Admins, and maybe Wikipedia.) HiLo48 (talk) 21:48, 6 June 2018 (UTC)
  • Oppose Not appropriate to push that POV, even though many of us might agree with it. HiLo48 (talk) 08:14, 6 June 2018 (UTC)
  • Oppose per GenQuest. Wikipedia is not for righting great wrongs, in articles or otherwise. --Joshualouie711talk 15:13, 6 June 2018 (UTC)
  • Oppose We are not a forum, and that must just as much apply to this as anything else. Wikipedia must not and should not engage in advocacy. Once we do that then any claim of neutrality goes out of the window, we play into the hands of those who say we are not neutral.15:17, 6 June 2018 (UTC)Slatersteven (talk)
  • Support. Like the net neutrality proposal, this is not inherently political. Like net neutrality, this also has to do with something that threatens the very premise of WMF's purpose. But unlike net neutrality, this law may prevent EU users from accessing Wikipedia because Wikipedia doesn't pay the appropriate fees to news sources for using short snippets of text, and so forth.
    I initially thought this was about the image copyright law that banned images of certain structures in the EU, but this is much, much worse. Talk about heavy-handed... epicgenius (talk) 15:58, 6 June 2018 (UTC)
  • Oppose We are not a forum, and that must just as much apply to this as anything else. Wikipedia must not and should not engage in advocacy. Once we do that then any claim of neutrality goes out of the window.Slatersteven (talk) 14:58, 6 June 2018 (UTC)
    • Too late. clpo13(talk) 17:06, 6 June 2018 (UTC)
      • The whole point of the project and the foundation is advocacy for free and open knowledge, for everyone to contribute, share and make money off. A highly radical concept in 2001 and still in most parts of the world. —TheDJ (talkcontribs) 19:33, 6 June 2018 (UTC)
        • Completely wrong. Not right at all. 100% wrong and 0% right. The point of the project is to provide that free and open knowledge. Not to advocate for it, or for anything else whatsoever. --Trovatore (talk) 19:36, 6 June 2018 (UTC)
  • Support: this law will have very serious consiquences for Wikimedia projects as outlined by the proposer, Julia Reda, WMF, WMDE and others. John Cummings (talk) 15:48, 7 June 2018 (UTC)
  • Support although I doubt a proprosal on en-wiki can affect all other language wikis, so probably just here. I'm quite flabbergasted whenever I hear the "we shouldn't be doing advocacy"-line. Obviously we shouldn't be advertising for political parties or recommending the next big dietary supplement, but there's absolutely nothing wrong with telling our readers whenever a proposed policy would severely **** with our editing model. I wonder if one would get the same reaction if the proposal was more obviously authoritarian. It's also incorrect that the WMF hasn't said anything about this as explained above, and various elements of the WMF-affiliate ecosystem has been working against this, such as the WM EU-group (full disclosure, WMDK, which I'm a part of, has done so as well). Despite the carveouts for online encyclopedias in the proposal, it would still impact some of our other projects, as well as the general free-knowledge infrastructure, such as forced remuneration. Sincerely, InsaneHacker (💬) 16:28, 7 June 2018 (UTC)
I absolutely agree. This is not just a vague human rights thing, this is something that may well have direct financial consequences for WMF. On that bases I'd go as far as to support WMF overriding whatever consensus happens here to make the blackout happen. DaßWölf 02:49, 9 June 2018 (UTC)
  • Oppose – Wikipedia is not a soapbox, whether political or not. But wait, why would we think this is a bad idea anyway? Isn't a robust and effective filter to prevent copyright violations one of the things we've repeatedly asked the Foundation for in the various community wishes consultation exercises? Isn't it exactly what we desperately need and want for this project, instead of relying on a script written by a user and the one dedicated admin who monitors it? Since the vote is imminent, can we take it that the WMF has already dedicated substantial human and financial resources to preparing an effective filter in case it turns out to be needed? Will it be ready in time? Justlettersandnumbers (talk) 17:17, 7 June 2018 (UTC)
  • Support I agree with Kusma, including caveat that the saveyourinternet link is not ideal. Mike Linksvayer (talk) 17:22, 7 June 2018 (UTC)
  • Support Before it is too late. Yann (talk) 20:42, 7 June 2018 (UTC)
  • Strong oppose - Copied from the recent proposal for a Net Neutrality banner, after reading much of this discussion (I can't say it any clearer than this). I'll note that something does not need to be "partisan" to be political by my understanding and use of the word. First definition at "of or relating to government, a government, or the conduct of government".
    Wikipedia is an encyclopedia, not a platform for political statements supported by a majority of the few editors who happen to show up in a discussion on this page. That's regardless of the merits of the issues or how Wikipedia might be affected by them. We are Wikipedia editors, not political activists (although each of us is free to be a political activist off-wiki). In my view, this proposal should go the way of the proposal to show an anti-Trump statement before the U.S. presidential election. Furthermore, I think we should consider an explicit policy against using the encyclopedia as a platform for political statements. ―Mandruss  21:13, 7 June 2018 (UTC)
  • Support per Guy Macon and Wnt. Jc86035's alternate account (talk) 06:43, 8 June 2018 (UTC)
    • I will abstain from voting. But just to point out that if we do it, we should have our own banner, as we did on de.wp and bg.wp. We are in a particular situation where Wikimedia projects have been carved out from the proposal as the text currently stands. We need to explain why we still worry with a little bit more nuance, at least on the landing page. --dimi_z (talk) 08:22, 8 June 2018 (UTC)
  • Support Wikimedia projects and the Wikimedia commununity get involved in any political issue which is an existential threat to Wikimedia projects. There is a preponderance of evidence that this political issue is an existential threat to Wiki and for that reason it is fine for us to take a political position. It is true that Wiki is "neutral" but neutrality is relative and rational and aligns with an ethical code. Our ethic code includes values like "publishing an encyclopedia" and "making the encyclopedia accessible". I feel that we have met an appropriate standard of evidence in this case, and I agree that WP:reliable sources say that Wikimedia projects are facing an existential threat with this political issue. It is fine for us to advocate, lobby, and demand our right to develop and provide access to the encyclopedia we are sharing. I also feel that it is not necessary to settle any political controversy around this issue. I am willing to acknowledge the legitimacy of critics' concerns about our incomplete information on the law and lack of total certainty that this law is bad. For me, it is enough that we are diligent to cite reliable sources which confirm that some authorities have identified a danger.
I see "oppose" !votes which suggest that Wikipedia should avoid reacting to any country's legislative process as a way of achieving neutrality. I feel that this is misguided, because while Wikipedia is neutral about many topics, we always take a position that every country should allow Wikipedia, access to information, and the educational resources we provide. I will not entertain anyone's arguments that restricting access to Wikipedia should be part of the Wikipedia mission. There is no reason why we should expect that the law of every country is best for Wikipedia. It is fine for us to say that Wikipedia is basically good, and to expect that the laws conform to the existence of Wikipedia. Citizens like us make laws for the public good. People do not exist to conform to laws which fail to consider the public good. It is right to start with the assumption that Wikipedia is good and that good laws will encourage its development. Blue Rasberry (talk) 21:31, 8 June 2018 (UTC)
  • Strong support A lot of the oppose votes seem to come from editors who won't be affected by this legislation, which makes me question if they truly understand the potential consequences. Speaking as someone who will be, from what I understand of it (correct me if I'm wrong), it will make it nigh-on impossible to do anything more than trivial edits. We would no longer be able to upload fair use images, cite web sources, or even quote copyrighted material. How on Earth are we supposed to write decent articles with those restrictions? This could be detrimental to Wikipedia and those in the EU who wish to edit it. The WMF may not be bound by this legislation, but my ISP will be. This is not just a political crusade. Adam9007 (talk) 22:03, 8 June 2018 (UTC)
  • Comment: Then do something about your law makers. Do you understand the current legislative actions affecting internet, copyright law, and legality of use for our users in China? How about Turkey? Spain? Thought so. Wikipedia is here for people to access—or not. They can do so, as best they can from the countries they live in. These are countries where they have –politically– elected the officials who then propose, debate, and enact the laws they deem necessary. We are not here to advocate for or against any such laws, any such country, or any such lawmakers. That's politics. We're here to build an encyclopedia. Period. GenQuest "Talk to Me" 00:13, 9 June 2018 (UTC)
Remember that proposed copyright legislation a few years back? It would have made many, many free images used here subject to copyright. We had a banner about that, because it would have directly and adversely affected us. I don't see how this is any different. Adam9007 (talk) 15:23, 9 June 2018 (UTC)
Yep. And I was against that action too, but consensus was against me. I stopped editing for about year afterwards, too, because I saw that these kinds of political actions would become perennial requests. Judging from, counting this one, three discussions so far just this year, I guess I wasn't far wrong. GenQuest "Talk to Me" 16:57, 9 June 2018 (UTC)
  • Conditional moot. This discussion will probably be closed after 20 June 2018. Steel1943 (talk) 22:38, 8 June 2018 (UTC)
  • Oppose - Just like the net neutrality discussion we had a while back: I'm sympathetic to the ideals, but I'm opposed to Wikipedia being used as a political platform regardless of ideology. Unless of course, the Wikimedia Foundation itself decides to release a statement themselves, but in any case, there are alternative outlets for statements like these to be expressed. Narutolovehinata5 tccsdnew 23:18, 8 June 2018 (UTC)
  • Strong oppose Direct advocacy on a political matter is about the farthest you can get from maintaining neutrality. "Please do not add commentary, your own point of view, or your own personal analysis to Wikipedia articles", to quote {{uw-npov2}}. Go start a blog if you want to publicize your opinions about political matters, whether in your own country or another. Nyttend (talk) 22:58, 8 May 2018 (UTC) This is intentionally copy/pasted from my vote on net neutrality. Nyttend (talk) 02:20, 9 June 2018 (UTC)
  • Strong support. The oppose voters must be missing the fact that a major part of fair use methodology that is absolutely essential for Wikipedia's functioning will be rendered effectively illegal unless Wikipedia tithes to every news source it cites and quotes. If we're not going to protest for the sake of the internet, then do it for the sake of Wikimedia's budget. DaßWölf 02:37, 9 June 2018 (UTC)
  • Support. If the legislation passes, it would almost certainly be illegal to access most Wikipedia articles from the EU, and Wikimedia and/or individual contributing editors might be found liable for copyright violation. Certainly downstream commercial users would be found liable if they did not block access from the EU, even if Wikipedia and individual contributors were exempt. We need a banner within 3 days. — Arthur Rubin (talk) 04:48, 10 June 2018 (UTC)
  • Support: SOPA is a precedent, but this actually is much worse. Wikipedia is a name synonymous with open content online, and if they try to assert the "it applies to any website which serves European users regardless of where its being run from" card like GDPR is, this is an existential threat that goes much farther than just Wikipedia. ViperSnake151  Talk  15:28, 10 June 2018 (UTC)
  • Support per Blue Rasberry. Double sharp (talk) 03:20, 11 June 2018 (UTC)
  • Support for the convincing reasons given in the proposal. Kevin (aka L235 · t · c) 03:21, 11 June 2018 (UTC)
  • Strong possible support Being apolitical does not mean being blind to threats to Wikipedia. The Red Cross is apolitical. That doesn't mean they can't take a stand against a proposed law that would make it harder to give blood. Headbomb {t · c · p · b} 03:53, 11 June 2018 (UTC)
  • Comment: Let me share you a Wikipedia [Hungary] story, happened a few years ago and handled by yours truly: a large number of Wikipedia editors (image uploaders) got email from a large lawyer firm which stated that they have violated the rights of a LargeImagePublisherHouse™ since they have illegally used their imagery without their permission and they are commanded to immediately remove the image (from WM Commons) and immediately pay a large sum of money or they will be brought to courts. Possibly hundreds of such. The users got really scared, and I tried to figure out what was going on. After contacting the lawyering gang it took a weird turn: turned out they have used a company specialising in content filtering to scan millions of web images against their image catalog and flag copyvio [and have paid a helluva lotsa dinero for that], then started sending out harrassing mail en masse. The problem was, however, that their library ("accidentally") have included lots of images from Wikimedia Commons! So they have "claimed" their copyright, matched against, well, the originals then sent out the pay-or-get-sued mail. Obviously when they've been shown this they were hugely embarrassed and apologised and sent out correctional mail in the following weeks. Nevertheless, the harm's been done: some people left Wikipedia immediately and disappeared for ever. This is the same principle and technology They™ would like to enforce on Wikimedia Commons, Wikipedia, and apart from that basically everyone around your internet cable. Whether this is existencial or not… decide for yourself. Compulsory monitoring by copyright owners (not the authors, mind you)? Veto right for them? And we have to pay for that technology, implementation, and by the way accept all responsiblity for misfiltering, either way? I do not think that would get unnoticed in Wikipedia and Wikimedia operations. --grin 07:57, 11 June 2018 (UTC)
  • Support. Unlike the US net neutrality issue, this impacts Wikipedia as a project much more immediately and negatively, and it is legitimate to oppose it from this operational perspective. Sandstein 12:53, 11 June 2018 (UTC)
  • Support very clearly something that negatively supports our community's direct mission and activity, Sadads (talk) 16:11, 11 June 2018 (UTC)
  • Support This is an instance where being "political" is unavoidable: the political aspect is baked into the very idea of a free encyclopedia. XOR'easter (talk) 18:34, 11 June 2018 (UTC)
  • Oppose Wikipedia is not a political platform, even if the policy issue impacts (to some) our continued existence. Chris Troutman (talk) 21:58, 11 June 2018 (UTC)
  • Oppose For the same reasons I've opposed other similar proposals, we shouldn't be using banners to urge action in a particular way. That said, the issue is quite important and under-reported. I could support a neutrally worded banner that linked to some neutral information sites, but not one that advocates opposition or support. I think most readers are smart enough to make up their mind, if they are given information.--S Philbrick(Talk) 21:30, 12 June 2018 (UTC)
  • Oppose because Wikipedia should not be using its position to influence the way the world is run. Our founding principles stated in Wikipedia:Five pillars include that "Wikipedia is not a soapbox" and that "We avoid advocacy and we characterize information and issues rather than debate them." SilkTork (talk) 10:04, 14 June 2018 (UTC)
It's worth pointing out that we already use edit filters on Wikipedia: Edit filter management and MediaWiki talk:Spam-blacklist. The concerns raised in last year's WikiMedia blog do not appear to have considered our own existing filters and the way we operate them. SilkTork (talk) 10:25, 14 June 2018 (UTC)
  • Support per Blue Raspberry. --Carwil (talk) 16:45, 14 June 2018 (UTC)
  • Support Has a significant risk of impacting our ability to function. Agree with User:Sandstein. Doc James (talk · contribs · email) 19:46, 14 June 2018 (UTC)
  • Support per my comments below. — Insertcleverphrasehere (or here) 07:43, 16 June 2018 (UTC)
  • Oppose a banner linking to a page explicitly in opposition to Article 13, Neutral on a banner linking to a NPOV summary of the facts. --Joshualouie711talk 00:44, 17 June 2018 (UTC)

WAIT, how is this political?

WAIT. before you oppose on 'not-political' grounds, be aware that this is not something that it politicised in the EU, it is something that has not been reported on in the media, and the public are largely not aware of. This EU proposal is far more dangerous than any of the net neutrality debates, in a direct way to Wikipedia. Net Neutrality doesn't directly affect Wikipedia, but the changes to copyright that article 13 contains may make it impossible for Wikipedia to operate in the EU; the 'link tax' might completely shut down access to Wikipedia in Europe if enforced, and the rules for copyright basically eliminate fair use, making all the European branch language Wikis largely impossible. That is way more of a big deal than a bit of political activism. Please do not bandwagon this one, THINK. I was against the other net neutrality banners, but this is NOT THE SAME THING. I urge you guys to please reconsider, because this is not a partisan political issue in the EU, and that this is actually a potentially huge existential threat to Wikipedia itself. Even Jimbo Wales has said so over on his talk page.Insertcleverphrasehere (or here) 20:39, 5 June 2018 (UTC)

  • It is being done through the political process, thus it is political. The WMF isn't worried about it, so why should we be? TonyBallioni (talk) 21:01, 5 June 2018 (UTC)
Where have you been told that the WMF isn't worried about it? It is not a partisan issue like net neutrality, so Wikipedia wouldn't be 'taking sides'. This is trying to be snuck through the political process with nobody noticing. — Insertcleverphrasehere (or here) 21:09, 5 June 2018 (UTC)
Regardless, if this is a threat to the WMF model, then the WMF should be clearly issuing a statement against it and/or issuing something to say they support a message. (WMF supported the Protests against SOPA and PIPA). If we had this, I would see no problem then including a banner message to warn about this. --Masem (t) 21:16, 5 June 2018 (UTC)
Err, they already did: wmfblog:2017/06/06/european-copyright-directive-proposal/. Judging from the statement, WMF seems rather worried about article 13, which would probably make the WMF subject to some kind of liability. The European users and associations originally cared about other things, necessary for our copyleft wikis: freedom of panorama, public domain, orphan works. But then, maybe that's considered "political" too. --Nemo 21:17, 5 June 2018 (UTC)
  • I detest hidden pings; if you're going to ping me, at least make it so I can see my name. Anyway, I agree with Tony and Masem; if it's an existential threat in the view of the whole of the Foundation, not just Jimbo, something will be done. Moreover, it's not our place to attempt to sway the minds of voters regarding the proposed policies of their lawmakers. (Hint: contact your lawmakers and spread the word about this.) — Javert2113 (talk; please ping me in your reply on this page) 21:22, 5 June 2018 (UTC)
@Javert2113:Sorry about the hidden ping, I pinged everyone that had made a 'political' oppose above, and it was a long list of names. — Insertcleverphrasehere (or here) 21:51, 5 June 2018 (UTC)
It's fine. I'm just a bit grouchy today, to be honest. Thank you for the ping; I probably wouldn't have seen this otherwise. — Javert2113 (talk; please ping me in your reply on this page) 21:52, 5 June 2018 (UTC)
  • Whether or not the WMF is worried about it, or whether or not I'm personally worried about it, I still oppose. While I understand the proposed banner would not be encyclopedic per se, I think the general spirit of WP:NPOV should still apply to publicly-facing content and the proposed banner - linking to a site that says a specific piece of legislation "threatens everything you do" - is not in line with that. That said, I appreciate the spirit in which the banner is proposed. Chetsford (talk) 22:11, 5 June 2018 (UTC)
  • Is there anyone here who would change their position if the banner was worded differently or linked to another page such as [ ]? I am guessing that the answer is no. --Guy Macon (talk) 22:23, 5 June 2018 (UTC)
  • I think your guess is probably a good one. I'd be opposed to any type of persuasive banner regardless of the specific words used or the topic referenced. Chetsford (talk) 22:35, 5 June 2018 (UTC)
  • I think the issue is that it isn't clear exactly what consequences this might have, particularly for Wikipedia. Article 13 is pretty broad in its language, which makes it a bit unclear where it will be enforced and where it won't. When similar laws passed in Spain I know that google news shut down in that country (at least linking to Spanish publishers). A lot of these links are pretty fearmongery, and I am not sure anyone really knows what consequences this might actually have. Everyone seems to agree that it will be bad to some degree however. If a Lawyer from the WMF could give us confirmation on this (can someone ping somebody?) that would be the best. I'm not sure if wmfblog:2017/06/06/european-copyright-directive-proposal/ represents a WMF position on the topic or not... — Insertcleverphrasehere (or here) 22:44, 5 June 2018 (UTC)
  • The worst case scenario, it seems, is that Wikipedia in the EU goes the way Google News did in Spain. That, in the future, Wikipedia will be inaccessible to EU citizens. However, I oppose the persuasive banner regardless of the consequences. If the citizens of the EU, acting through their MEPs, decide WP is not welcome in the EU we should respect their decision, not chain ourselves in the guest bedroom and demand to stay. Again, though, I do appreciate the spirit in which the banner is proposed and agree it would be unfortunate if the worst came to pass. Chetsford (talk) 22:52, 5 June 2018 (UTC)
  • Meh, the WMF is not worried about it. They are insulated by being (as an entity) based in the US, the material based in the US etc. This will not impact Wikipedia or any of the major encyclopedias in any significant manner. It will be an issue for editors in the EU but as to how much - that remains to be seen. What it is highly likely to totally fuck right up is Wikia - a site that routinely (and is in fact built around) violates copyright. And since Wikia is a for-profit cash-generating machine of a certain someone, who happens to live in the EU and so is subject to EU law, its not surprising they are 'concerned' about legislation that will directly impact that. Only in death does duty end (talk) 10:10, 6 June 2018 (UTC)

Julia Reda AMA

For those few interested, tomorrow Julia Reda (one of the few defenders of the Internet within the EU politics), is doing an AMA tomorrow at 12:00 CEST on reddit (talkcontribs) 14:03, 5 June 2018 (UTC)

Looks like it has started: --Nemo 11:29, 6 June 2018 (UTC)

Article outlining the threats of the law to Wikimedia projects

Cory @Doctorow: has written an article for Electronic Frontier Foundation that outline the threats posed by the law to Wikimedia projects and what can be done to oppose it:

  • The EU's Copyright Proposal is Extremely Bad News for Everyone, Even (Especially!) Wikipedia.
Insertcleverphrasehere (or here) 21:31, 7 June 2018 (UTC)

Wikipedia article on the subject

Directive_on_Copyright_in_the_Digital_Single_Market has been started, it is currently not very comprehensive, please help expand it. John Cummings (talk) 21:20, 8 June 2018 (UTC)

According to the (fairly critical) de:Leistungsschutzrecht für Presseverleger Germany has already such legislation, maybe that is something worth inspecting? Jo-Jo Eumerus (talk, contributions) 21:34, 8 June 2018 (UTC)
Germany already has the link tax aka article 11, see Google News (it failed miserably, so the EU lobbies are now proposing an even worse version). The biggest danger for Wikimedia is probably article 13 (mandatory upload filters and liability). --Nemo 08:31, 9 June 2018 (UTC)
It also appears to be poised to but some real teeth in the EU right to disappear, with hefty daily fine if a US website like Wikipedia refuses to delete a BLP article on demand. --Guy Macon (talk) 08:11, 12 June 2018 (UTC)

WMF position

Hi everybody, since some people have been asking about it, I wanted to confirm our position very briefly: the Wikimedia Foundation is deeply concerned about requirements for mandatory upload filtering to fight copyright violations or other problematic content that could appear in the future. Therefore, we oppose Art. 13 of the proposed Copyright Directive due to its potential harm to freedom of expression, user privacy, and collaboration on the internet. We believe that a general monitoring obligation for platforms would threaten user rights. Best, --JGerlach (WMF) (talk) 06:16, 12 June 2018 (UTC)

JGerlach (WMF), As I pointed out at User talk:Jimbo Wales/Archive 229#How about a far less controversial EU Copyright law proposal? the WMF position you just linked to is over a year old, and the proposed regulation has changes significantly since then. See Talk:Directive on Copyright in the Digital Single Market# Timeline of the proposal (prepared by Cory Doctorow) for a list of the changes. The leaked secret proposal to make the upload filter in Article 13 more extreme especially troubling and might require an additional WMF comment.
May I request an updated position statement? If there are no updates, may I request a simple republishing with a comment to the effect of "in the year since this was published, our position has not changed"? --Guy Macon (talk) 08:08, 12 June 2018 (UTC)
Guy Macon, I can confirm that our position has not changed and we oppose Art. 13, in its amended version too. Even with the recent changes and the exception for non-commercial purposes, we oppose this proposed norm because it would establish a dangerous precedent and threaten user rights on the internet. --JGerlach (WMF) (talk) 17:34, 12 June 2018 (UTC)

Mass ping

@TonyBallioni, Yair rand, Natureium, Power~enwiki, Billhpike, Masem, Javert2113, Winner 42, Godsy, Doktorbuk, Pharaoh of the Wizards, Chetsford, Ammarpad, Joe Roe, Wumbolo, GermanJoe, Finnusertop, Kudpung, HiLo48, Joshualouie711, Slatersteven, Justlettersandnumbers, Mandruss, Narutolovehinata5, Nyttend, Chris troutman, SilkTork, and Sphilbrick:--Apologies for the mass ping.But, I feel it might be prudential to inform you of the WMF 's stand on this issue, which has been clarified at this thread, since it has the potential to affect your !votes.Best,WBGconverse 04:58, 17 June 2018 (UTC)

  • Still oppose as bringing politics into Wikipedia. TonyBallioni (talk) 04:59, 17 June 2018 (UTC)
  • I would still think that if the WMF felt this needed to be known, they can force a banner across all projects. limiting to just is not a good idea. --Masem (t) 05:26, 17 June 2018 (UTC)
  • Same view with Masem. If the Foundation felt it is "necessary," just run banner across all projects as non-overridable Office action. But waiting for en-wiki crowd to agree first means it is not as "dangerous" as pro-banner camp are making it to look like. –Ammarpad (talk) 06:01, 17 June 2018 (UTC)
  • Still oppose. To be clear: the WMF statement contains many valid thoughts and concerns (although a bit vague in some parts), but it does not demonstrate an immediate threat to Wikipedia's core mission. GermanJoe (talk) 06:18, 17 June 2018 (UTC)
  • I remain opposed to a banner of any kind. Regardless of the WMF's position, I remain unconvinced that Wikipedia should be used as a platform for programs such as this. This would violate NPOV and other related policies, including the Five Pillars. Narutolovehinata5 tccsdnew 06:29, 17 June 2018 (UTC)
  • Still oppose. We have to be careful about hosting political banners. Think of the unintended consequences... doktorb wordsdeeds 08:04, 17 June 2018 (UTC)
  • Still oppose It is not an issue of the rights and wrongs of this directive, but out commitment not only to the concept the the principle of neutrality. I believe that you should obey not just the letter of the law (or you should stop using commitment to the law as a kind of Moral VC to tell people how great you are).Slatersteven (talk) 09:45, 17 June 2018 (UTC)
  • Not one bit different; WMF's stand does not change the fact that this would put political advocacy atop every page. Nyttend (talk) 11:31, 17 June 2018 (UTC)
  • Thanks for the ping, but I already commented on that year old blog article in my oppose. I'm not sure that the Foundation is aware that we already use edit filters created by our users, some of which are designed to combat copyright violations. But even if they are, I think it's OK for the Foundation to say that they are opposed to stuff which they feel impacts on Wikipedia. What is wrong is for anyone to use Wikipedia as that platform. Those folks who are opposed to this (and that includes our blessed Jimbo) should use legitimate platforms to express their concerns or disagreements. SilkTork (talk) 12:12, 17 June 2018 (UTC)
  • No change, if the WMF wants to take an office action to run a banner I could tolerate that but I wouldn't be incredibly happy about it. That said, I have already been mass pinged twice to this discussion and would appreciate it if this was the last one. W42 13:18, 17 June 2018 (UTC)
  • Continue to oppose: Thank you for the ping, but this has not affected my position, either, nor the ones of my fellow editors, I daresay. My position may best be summed up as a combination of Ammarpad's thoughts, Narutolovehinata5's beliefs, and Winner_42's hope to not be pinged again. If you care to read it all, it's below.
    First, the Foundation may say whatever it likes, naturally, but they don't post their (inherently political) statement on English Wikipedia: neither should we. As it stands, there are other platforms that should be used to political lobbying and discussion instead of our collaborative encyclopedia. Moreover, of course, the Foundation could force Wikipedia to run a banner, and there'd be bobkes we could do about it, but they haven't; whilst one may see that as respecting the autonomy of our efforts here, I see that much in the same way GermanJoe and Ammarpad do: this isn't something that is wholly inimical to Wikipedia as a core threat to our mission and our future. Finally, as a standard matter of policy, we do not engage in political campaigning on the encyclopedia, and we do not allow campaigning or WP:ADVOCACY (our stance against SOPA and PIPA being a notable exception). It would behoove us, in my opinion, to continue such a policy. —Javert2113 (Let's chat!|Contributions) 15:21, 17 June 2018 (UTC)
  • WMF's opinion never made any difference to me; I find them despicable. I still oppose this political jousting being hosted on Wikipedia. Chris Troutman (talk) 15:59, 17 June 2018 (UTC)
  • I concur with the comments on this matter made above by TonyBallioni, Doktorbuk, and Nyttend. — Godsy (TALKCONT) 17:10, 17 June 2018 (UTC)
  • continue to oppose If WMF wants to influence EU legislation, they should hire a lobbyist. — BillHPike (talk, contribs) 20:13, 17 June 2018 (UTC)
  • Reaffirming oppose per TonyBallioni. --Joshualouie711talk 21:30, 17 June 2018 (UTC)
  • I had reasoned that my !vote would stand unless I modified it, but a large number of editors appear to feel that it would be effectively withdrawn if I didn't re-affirm it here. Shrug. Still oppose as there has been no counter to my argument, let alone a persuasive one. ―Mandruss  22:45, 17 June 2018 (UTC)

Time to close?

Reading the discussion above, while of course voting is not consensus, as of this comment, there are 27 26 support comments versus 30 oppose comments. Even if the support comments were more numerous, considering the amount of participation here (far less than the unsuccessful net neutrality proposal a few months ago) and the narrow gap in numbers, it's becoming clear that there really doesn't seem to be consensus at this point to implement the banner as proposed. With that said, some users from both sides have stated that they are open to either a neutrally worded banner that merely discusses the proposal and its details, or a WMF-implemented banner. But from the looks of things, with discussion having slowed down over the past few days, it seems unlikely that the numbers are going to change. As such, I would suggest that this proposal be closed, albeit without prejudice against continuing discussion of the EU proposal itself elsewhere. Narutolovehinata5 tccsdnew 06:56, 17 June 2018 (UTC)

Yes time to close I think. —TheDJ (talkcontribs) 08:32, 17 June 2018 (UTC)
Agree, clearly there's no consensus. TeraTIX 11:24, 17 June 2018 (UTC)
A neutrally-worded banner, moreover, still announces to the world that we believe it a really important thing about which tons of people need to know; the details of the wording wouldn't affect the fact that its mere presence is non-neutral. Nyttend (talk) 11:34, 17 June 2018 (UTC)
Also support close at this time. A "neutrally worded" banner would need a separate new discussion—that was not the topic of this one, so absence of comment cannot be fairly interpreted as absence of opposition. To avoid unnecessary confusion, the close should be clear that the "neutrally worded" option remains unresolved. ―Mandruss  14:36, 17 June 2018 (UTC)

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

Post-closure discussion

Post-closure comments, including discussion of the EU directive, can continue in this section. Thanks. Narutolovehinata5 tccsdnew 00:51, 18 June 2018 (UTC)

How to/should we add a Wikidata item link to Authority control

Currently, there is no link from the {{Authority control}} navbar template to the Wikidata item page, where the information displayed is gathered. The Wikidata item page is where an editor may add/remove/correct authority information on a person/entity. A common complaint against {{Authority control}} is that the template (and thus Wikidata) contains information on the wrong subject, or that the links are useless, or the associated link is broken, or frustration from how/where to correct it (there are other complaints as well, but they are outside the scope of this discussion). This proposal/survey seeks to allow editors to more easily access the Wikidata item linked to the Wikipedia page to make such additions/removals/corrections. While gaining some support, it has been suggested at Template talk:Authority control#Adding Wikidata item link to aid navigation to poll a larger audience, so voilà.

A 'Wikidata item' link exists on the left hand margin of any Wikipedia page which currently has a Wikidata item associated with it, similar to commons, wikiquote, wikisource, wikispecies, etc. Also similar is our placement of a 2nd link to commons, wikiquote, wikisource, wikispecies, etc. at the bottom of the page in the external links, to aid navigation and visibility. So the addition of a 2nd link to Wikidata would be in line with current behavior.

This will not affect dormant transclusions of {{Authority control}}; i.e. those which do not display on the page.

Option 1 - RHS in-line 'Wd: Q2144892' links as the first item:

Pros: it's short, so the chances of adding an extra vertical increment to the height of the {{Authority control}} template is also small. After scanning all ~690k transclusions, 59.5% of {{Authority control}} templates display 3 or fewer links from Wikidata, and 90% display 7 or fewer, so at least those 60% would very likely retain their current height. Also, parameter suppression of some kind will probably happen in the next 1-few months, making even more templates 1-liners.
Cons: it's lumped together with the other authorities so it (Wikidata) might run the risk of being misidentified as an authority (which it isn't), but I've only seen this concern raised once (part of the reason I'm here). This hasn't been a problem with a sister template, {{Taxonbar}}, which has about ~50% of the transclusions of {{Authority control}}.

Option 2 - LHS 'Q2144892' link on a separate line:

Pros: less chance of being misidentified as an authority, and more obvious linkage to the corresponding Wikidata item than Option 1.
Cons: will force all {{Authority control}} templates that are 1 line tall (~50%) to be 2 lines tall.

Option 2Wd - LHS 'Wd: Q2144892' links on a separate line:

Pros: lowest chance of being misidentified as an authority, and more obvious linkage to the corresponding Wikidata item than Option 1 and Option 2.
Cons: same as Option 2, and slightly wider.

Option 2Q - LHS 'Q2144892' links on a separate line (stylistic variant of Option 2Wd; Q and 2144892 link to different pages):

Pros: same as Option 2, plus the additional link describing what Wikidata is, and is "cleaner looking" than Option 2Wd.
Cons: same as Option 2.

Option 2Wikidata - LHS 'Wikidata' link & RHS links display ID names instead of numbers:

Pros: same as Option 2, but much more reader friendly, and LHS is constant width regardless of Q# size, and the RHS (with this example) is slightly shorter than any Option 2.
Cons: same as Option 2.

Option 2pencil - LHS ' ' link:

Pros: same as Option 1, and widespread use elsewhere, so intuitive.
Cons: less descriptive than Option 2Wikidata, and hard to see for users who invert browser colors.

Option 2edit - LHS '[edit on Wikidata]' link:

Pros: same as Option 2 and Option 2Wikidata, and widespread use elsewhere, and maximally intuitive.
Cons: possibly too enticing?

Option 3 - any of the above.

Pros: various.
Cons: various.

Option 4 - no change.

Pros: status quo.
Cons: less mobility to Wikidata, and thus less potential for editors to add/remove/correct information.

AC Wikidata item link survey

  • Option 2edit, 2Wikidata, 2pencil, 2Wd/2Q, 2, 1, in that order, as nom.   ~ Tom.Reding (talkdgaf)  23:18, 5 June 2018 (UTC)
  • Option 2Wikidata, if not, 2Wd, failing that, 2. I feel 2Wd is the best here, or failing that option 2. 2Q is bad and confusing. Option 1 is baaaaad. Personally, I'd just add the full Wikidata:Q2144892. The objectings (below) to this are silly, since it makes editing what is presented harder if there are errors, and presents Wikidata as authoritative.Headbomb {t · c · p · b} 23:52, 5 June 2018 (UTC)
  • Options 2edit/2pencil, 2Wikidata, 2Wd, and 2, in order. We shouldn't add it to the authority field, so option 1 is a no-go, and 2Q is confusing for the user. Option 2Wd gives the best indication of what the Q link is for, although just calling it "wikidata" would suffice. Option 2edit is probably the most clear, but the pencil reduces the template back to one line, which is nice. — AfroThundr (u · t · c) 00:47, 6 June 2018 (UTC)
  • Options 2 or 2Wd in that order. Oppose 1 as very bad. Oppose 2Q as too difficult for mobile users to navigate. I also oppose 2pencil and 2edit. IMO we should not be including calls to action such as "edit this" or "edit that" since it seems to encourage the least competent drive-by readers to start editing things and, while WMF projects do not demand much in the way of competence, Wikidata is not a good jumping off point. Chetsford (talk) 02:40, 6 June 2018 (UTC)
By that reasoning, the "V · T · E" in every navbox template should also be removed. There haven't been significant issues of navboxes getting messed up because of the edit links being displayed. We need to give readers some indicator of where the data is drawn from and how to make corrections or additions. — AfroThundr (u · t · c) 20:24, 8 June 2018 (UTC)
"V · T · E" isn't an overt call to action since none of those abbreviations will necessarily be obvious to the drive-by reader. "Edit" or "Edit here" or "Edit this" are all calls to action; it's an announcement to the reader that we want them to edit it. I don't really want every rando reader to start editing a Wikidata entry. "This Can Be Edited" would be a descriptive indicator that was not a call to action but space considerations would obviously preclude that. Chetsford (talk) 23:19, 8 June 2018 (UTC)
  • Option 4. There is no need for a WikiData link, especially since we now transclude most from WD (at least up to 22 per subject are transcluded, up to 43 possible). WD is NOT an authority, and anyway it is already linked from the toolbox. There is no ‘one size fits all’, on many articles, both the in-AC link ánd the link in the toolbox will be visible at the same time on one physical computer landscape oriented screen. No objection agains a ‘sisterlink’ like template at long articles (but no standard inclusions there either, it does need merit). —Dirk Beetstra T C 04:05, 6 June 2018 (UTC)
    • As it is relevant here, today I did this. The link to Commons is in the toolbox, anddisplaying it so prominently in this case suggests that there is more to get on Commons. However, commons in this case has just three other cropped immages of the same as in the article - nothing to ADD. For much of WD (we are set to transclude 43, we sometimes display up to 22), the WD link has NOTHING TO ADDin terms of authority control (and there are enough requests to have more parameters to be added ...). The inclusion at the bottom should be a choice, not a standard for the 10s of thousands of articles that have an AC. If WD really has more to offer, include a sister link. —Dirk Beetstra T C 00:12, 7 June 2018 (UTC)
    • On a short page like David H. Sanford the link in the lefthand box ánd on the AC would be almost next to each other, hence there is no easier access. —Dirk Beetstra T C 10:21, 8 June 2018 (UTC)
      • Beetstra, can you explain how Wikidata is not an authority? Are you referring to the possibility that there might be more than one authorized heading for the same topic? By that token, we ought to remove WorldCat, because it's quite common to have multiple OCLC numbers for the same book because a cataloguer wasn't paying attention. Nyttend (talk) 11:40, 17 June 2018 (UTC)
        • @Nyttend: WikiData is not a reliable source, and therefore it is not an authority on any subject. Subjects get, within its capabilities, assigned a unique number, but anyone can create a subject, anyone can put whatever they want in it. By that datamodel, without proper authorized peer review, it is not an authority. That is fully in line with discussions going on elsewhere. Note: if we call WikiData ID as an authorative number, then The PageID of every page here on en.wikipedia is, by that same reason, an authorative ID. In short, not everything that assigns an ID is an authority. And that we need to link the WikiData ID because we use its data is, to me, a rather circular reasoning. —Dirk Beetstra T C 19:16, 17 June 2018 (UTC)
          • Beetstra, do you even know what an authority file is? If so, why are you contradicting yourself by describing an authority file and promptly telling me that WikiData isn't one? Hint: reliability is completely unrelated to whether it's an authority. Please tell me, in depth, what an authority file is and why your definition is superior to the definion that we professional librarians use, to which your description of WikiData is quite close. Then, get it published in JASIST or a similar journal. Until you can prove that people who spend 40 years learning everything they can about representation and organization are wrong, don't waste everyone's time with a fringe definition of "authority file". Nyttend (talk) 19:44, 17 June 2018 (UTC)
            • So, go include all PageIDs for all other Wikipedia pages, it must be useful as they are full of info. —Dirk Beetstra T C 07:09, 18 June 2018 (UTC)
            • But simply, we do not need to include any possible identifier that is publicly available, especially not ones to open wikis and any other unreliable source and randomly assigned list. option 4. —Dirk Beetstra T C 07:15, 18 June 2018 (UTC)
            • After reading a bit more, I stand with my initial comment. WikiData is an open wiki, it does not have the necessary control measures. —Dirk Beetstra T C 14:18, 18 June 2018 (UTC)
  • Option 4. The reason given as a "con" is actually a "pro". We don't have the WD link in other templates that are filled way too often from Wikidata (official website, commons cat, ...). AC is already a poorly designed reader-unfriendly template, and efforts are under way to drastically change it. Adding yet another link and another undecipherable code after a meaningless abbreviation is not the way to go. If not option 4, then whatever, but definitely not option 1. We shouldn't put IDs from unreliable wikis into our "authority control" templates (not just Wikidata, but also musicbrainz and so on). If any option 2 is chosen, then don't add the Q-number, just add "Wikidata", so readers have a better chance of knowing what the link means (something that should be done for all the others as well, give the short "name" of the site instead of the meaningless ID, so people know that they are looking at a link to a Czechian, Swedish, US, ... repository). Fram (talk) 06:56, 6 June 2018 (UTC)
    • I've added the 2 - names to give an idea of what I mean. Fram (talk) 07:07, 6 June 2018 (UTC)
      • I've renamed Option 2Names to Option 2Wikidata following convention & updated subsequent references to it.   ~ Tom.Reding (talkdgaf)  11:23, 6 June 2018 (UTC)
  • Option 4 per Beetstra and Fram. To be honest, I'd be quite happy if Wikidata folded but since that is unlikely to happen any time soon, the less connection there is, the better. - Sitush (talk) 07:12, 6 June 2018 (UTC)
  • Option 3 Adding the Wikidata link/ID is useful. Option 1 has the benefit of (almost) matching what is used in this template on other wikis (e.g., commons). I quite like the last Option 2Wikidata with the full display of the names rather than the acronyms and numbers. But any of the options would work aside from option 4. Thanks. Mike Peel (talk) 09:51, 6 June 2018 (UTC)
  • "No link to Wikidata" is painful. I think we've generally established that a template pulling from Wikidata should provide in the context of the template a way to edit the content at Wikidata (this is how Module:Wikidata functions broadly). OTOH, I don't think any of the options above provides the call to action in the way that Module:Wikidata does presently (the little pencil icon). I would prefer to see that here rather than the Wikidata ID or even the nomenclature for Wikidata.

    Regarding the specific proposals: Some Pencil Icon Version > 2Wikidata > 2. I'm partial to 2Wikidata for a non-Wikidata-specific related improvement. That said, I believe the intent is for the template to provide the links internally so that people who are curious about any particular identifier can understand (with some level of encyclopedicity) what it is they would end up looking at without taking up oodles of space with the template where it is provided (by use of the abbreviations). I'm not sure if those links are so valuable in fact or not, and I might suggest the general link to authority control/help:authority control suffices for "hey, what is this template doing? what are these links here for?" rather than specific links to each of the authority controls. That leaves me somewhere in the realm of option 2 as a last resort. Flat rejects: 2Wd for previous comments, 2Q per sea of blue rationale, 4 per first paragraph, 1 per con listed, and 3 because I have a specific preference. --Izno (talk) 13:14, 6 June 2018 (UTC)

  • Option 2pencil (per Izno) or Option 2edit . This has become the standard way of indicating "edit this on Wikidata". All of the presented options betray into thinking that Wikidata is one of the authority control files. It's not (is it?). The problem this proposal wants to fix is not that readers want to use Wikidata as an authority control; it's that editors can't find how to edit the actual authority files stored on Wikidata. – Finnusertop (talkcontribs) 16:23, 6 June 2018 (UTC)
    • Could you provide some examples of this standard? Also, is your second choice then Option 4 - no change?   ~ Tom.Reding (talkdgaf)  16:29, 6 June 2018 (UTC)
      • Many of these templates (though not all of them). For representative examples see {{Twitter}} (live example: Cristiano Ronaldo#External links) and {{Infobox astronomical event}} (live GRB 970228). Yes, my second choice is Option 4. – Finnusertop (talkcontribs) 17:05, 6 June 2018 (UTC)
        • Created Option 2pencil.   ~ Tom.Reding (talkdgaf)  17:41, 6 June 2018 (UTC)
          • Thank you, Tom.Reding. As for its con, it's something we should definitely check against MOS:CONTRAST, but I don't think we're married to this particular blue pencil. Your Option 2Wikidata is close to what the rest of the WD templates do (see e.g. {{Infobox anatomy}}): [edit on Wikidata] in brackets. That would be the clear, and standard, way to phrase what this option is trying to do. I don't mean to be critical, but there would have been no need to reinvent the wheel here when standard options already exist. – Finnusertop (talkcontribs) 17:50, 6 June 2018 (UTC)
            • Yes, the color used doesn't appear to match those at the top of phabricator ticket M82 (the pencil is ~2 years old and needs updating).
I think you're the first person to enter this conversation that was aware (or at least vocal) about such standards!
I guess Option 2edit needs to be made for "[edit on Wikidata]"?   ~ Tom.Reding (talkdgaf)  18:04, 6 June 2018 (UTC)
  • Anything but 2Q Option 2pencil I disagree with the arguments for Option 4 that another wikidata link would be redundant, as it's not obivious in any way that the wikidata link in the sidebar had any connection to the data presented in the authority control template. The only option I am really opposed to us 2Q. It seems like an WP:EASTEREGG, is likely to be confusing when editors don't realize why they're not always being sent to the page they expected, and the single-character "Q" link is a small target to hit. --Ahecht (TALK
    ) 16:46, 6 June 2018 (UTC)
  • Option 4 Per Sitush. Only in death does duty end (talk) 12:04, 7 June 2018 (UTC)
  • Option 4 - we already have a wikidata link in the toolbox. I agree with Sitush here. Ealdgyth - Talk 13:05, 7 June 2018 (UTC)
    • Then we should eliminate {{commons}}, {{wikiquote}}, {{wikisource}}, {{wikispecies}}, etc. too.   ~ Tom.Reding (talkdgaf)  13:42, 7 June 2018 (UTC)
    • The links to commons, wikiquote, wikisource, wikispecies etc are NOT STANDARD in the toolbox, as opposed to WikiData. As I said above, I did this. That template did, on that page, not ADD anything (not even in the toolbox). On most pages where AC is transcluded it does not necessarily add anything (especially since we have up to 22 identifiers transcluded, what is it supposed to do, even more identifiers to be found?). And I would not necessarily oppose careful use of a sister link to WD where it adds something. A blanket transclusion with AC is distinctly different from having a chosen sisterlink. —Dirk Beetstra T C 15:15, 7 June 2018 (UTC)
      • If the only concern against adding a WD link to AC is the presence of the same link elsewhere on the page, then it's an irrelevant concern due to the ubiquitous existence of the above templates, as described in the opening paragraphs of this proposal. Please read them.   ~ Tom.Reding (talkdgaf)  15:26, 7 June 2018 (UTC)
      • I'd also argue that "I don't like Wikidata, and/or I want it to go away, and/or I don't want to do anything to improve it nor Wikipedia" is antithetical to all involved Wikis, and also not a valid point, unless there are plans to dismantle the project.   ~ Tom.Reding (talkdgaf)  15:34, 7 June 2018 (UTC)
  • Option 4: per Beetstra and Fram; but Sitush raises the best argument. I've never seen the use of Wikidata, to be frank. But that's a conversation for elsewhere. — Javert2113 (talk; please ping me in your reply on this page) 15:50, 7 June 2018 (UTC)
    • I've never seen the use of Wikidata, to be frank. This is precisely what this proposal seeks to improve.   ~ Tom.Reding (talkdgaf)  16:10, 7 June 2018 (UTC)
      • Unless you meant figuratively seen, which I now suspect was the case, then yes, a conversation for elsewhere.   ~ Tom.Reding (talkdgaf)  16:14, 7 June 2018 (UTC)
  • Option 2 (indifferent among them)—Editable and on the left-hand side of Authority Control to differentiate it. People should know where this information comes from and have a way to edit it.--Carwil (talk) 19:56, 12 June 2018 (UTC)

AC Wikidata item link discussion

Please keep the discussion focused on the merits of the available options.   ~ Tom.Reding (talkdgaf)  23:18, 5 June 2018 (UTC)

I added some text to clarify 2Q. Johnuniq (talk) 23:34, 5 June 2018 (UTC)

Can we please promote this to an RfC, that attracts more editors and will get independent closure with a bit mere authority? —Dirk Beetstra T C 04:09, 6 June 2018 (UTC)

Why are the options confusingly numbered 1, 2, 2Wd, 2Q, 2, 3, 4? Could we change to having them as 1, 2a, 2b, 2c, 2d, 3, 4 - or something else that's more straightforward? In particular, we shouldn't have two that are just "option 2"! Mike Peel (talk) 09:53, 6 June 2018 (UTC)

I renamed the second option 2, that was my mistake. Fram (talk) 10:03, 6 June 2018 (UTC)

Pinging Headbomb & Chetsford, just to inform you that Option 2pencil and/or Option 2edit were created after your vote (and since you didn't vote Option 3 nor Option 4), in case you wish to amend. The available options appear stable now...   ~ Tom.Reding (talkdgaf)  11:32, 8 June 2018 (UTC)

Misleading opening statement

@Tom.Reding: you state: A 'Wikidata item' link exists on the left hand margin of any Wikipedia page which currently has a Wikidata item associated with it, similar to commons, wikiquote, wikisource, wikispecies, etc. Also similar is our placement of a 2nd link to commons, wikiquote, wikisource, wikispecies, etc. at the bottom of the page in the external links, to aid navigation and visibility. So the addition of a 2nd link to Wikidata would be in line with current behavior.

There s NO STANDARD LINK to commons, wikiquote, wikisource, wikispecies, etc. There IS a standard link to WikiData on all pages with an associated WikiData item. But as a list of non-exhaustive examples:

All have A WIKIDATA LINK in the toolbox, and NO LINK to commons, wikispecies, wiktionary, wikitravel etc.

At the time of my removal here, the article Giovanna Fletcher had a commons link at the bottom (IMHO useless as it did not provide significant material), and NO link to commons in the toolbox at the left.

Adding this link leads, by definition, to duplication, as opposed to other ‘sisterlinks’. —Dirk Beetstra T C 05:50, 8 June 2018 (UTC)

And anyway, also for those sisterlinks - since they can now be linked from the toolbox, barring exceptions those templates are, in my opinion, then excessive and should be removed, but that is not for here. —Dirk Beetstra T C 05:58, 8 June 2018 (UTC)

Just so we clearly understand the argument: we had sisterlinks in the document (e.g. through {{commons cat}}). Through WikiData coding that now sometimes results in duplication on the page as a second link to e.g. commons appears in the left hand box. Now, because we duplicate commons at the bottom in the article ánd in the top-left box, it is argued here that the duplication of the existing WD link in the left hand top box is fine. —Dirk Beetstra T C 07:34, 8 June 2018 (UTC)

@Beetstra: A link is shown in the sidebar to commons, wikispecies, etc. in the left-hand side-bar where it is available (defined as an interwiki link in the Wikidata entry, or as a manual interwiki). There is a large overlap between those links being shown and the sister project templates also being included (far from 100%, since there are many cases where those templates have not been added even if the link does exist, and there are templates that provide a link where it's not an interwiki on Wikidata). Of course, if a link doesn't exist, then it can't be shown, which is the case in the examples you have given here. Meanwhile, nearly every Wikipedia entry has a corresponding Wikidata entry, so you see that link in the sidebar far more often. So there is nothing wrong or misleading with the opening statement here. Mike Peel (talk) 11:09, 8 June 2018 (UTC)
P.S. a commons link now appears for the first item in your list as I just created it. Up to you if you want to add the photo that's on commons into the article. Mike Peel (talk) 11:19, 8 June 2018 (UTC)
Be careful, the photo is clearly of a different person than the subject of the article.--Ymblanter (talk) 14:25, 8 June 2018 (UTC)
@Ymblanter: Is it? Did de:Wladimir Michailowitsch Sobolew get it wrong? Thanks. Mike Peel (talk) 12:27, 17 June 2018 (UTC)
Sure. The guy was born in 1924 and the photo is recent; even of the photo were historic, there is no way a Soviet diplomat in the 1940s or 1950s could be dressed like that.--Ymblanter (talk) 12:30, 17 June 2018 (UTC)
Aah, I found your deletion proposal now at commons:Commons:Deletion requests/File:Sobolev.jpg. Thanks for that. Mike Peel (talk) 13:43, 17 June 2018 (UTC)
If a commons cat exists for the page, a link will appear in the margin. If a Wikispecies entry exists for the page, a link will appear in the margin. If a Wikidata item exists for the page, a link will appear in the margin. Lo, if a <another wiki> entry exists for the page, a link will appear in the margin. If there's Wikidata item associated with the Wikipedia page (and no forced params in {{Authority control}}), then both the template and the link in the margin are 'dormant'. You've done an excellent job at finding variation on this theme, but not to prove the point you think you're making. The example pages above have Wikidata entries associated with them, but none of the other Wikis. Clearly you've misunderstood the system and need to reevaluate.   ~ Tom.Reding (talkdgaf)  11:12, 8 June 2018 (UTC)
No, I did not misunderstand. Your argument is still that duplication is fine because we do that elsewhere. I disagree, I would even oppose the other duplication - especially in cases where the corresponding commons cat does not add anything extra over what is already in the article, or just has limited content. —Dirk Beetstra T C 11:35, 8 June 2018 (UTC)
I would say we should get rid of {{commonscat}}, especially since it pulls data out of Wikidata anyway.--Ymblanter (talk) 14:30, 8 June 2018 (UTC)
@Ymblanter: I was indeed considering that we could get rid of all sisterlinks-type cats, as they are all in the tools. It is just duplication. —Dirk Beetstra T C 14:46, 8 June 2018 (UTC)
I personally would be fine with that, but I know some people feel very strongly about the sister links.--Ymblanter (talk) 15:01, 8 June 2018 (UTC)
I can see arguments for some cases to be there, but not general. There are indeed strong feelings there, would likely need an RfC. —Dirk Beetstra T C 15:11, 8 June 2018 (UTC)

Proposal to change "on the article's talk page" for deleted articles

If one goes to Wikipedia: Articles for deletion, one can often see notices after a discussion has closed saying "The following is preserved as an archive of the debate. Please do not modify it". This notice then says that subsequent comments can be added to a deletion review or to the article's talk page. However, making comments on an article's talk page is difficult if the article has been deleted here. My proposal is that we change the wording if an article has been deleted. Vorbee (talk) 19:12, 6 June 2018 (UTC)

Conversely, the talk page is the single best place for subsequent comments if the article hasn't been deleted.
(I'm going to preemptively oppose any suggestion that Template:Afd top and Template:Afd bottom change to require additional parameters, either the article's name or whether it's been deleted. People do still close discussions with just the edit button.) —Cryptic 19:50, 6 June 2018 (UTC)
  • If the article has been deleted, then the appropriate venue to go is Deletion review not talkpage and this has already been linked. Nothing requires change here. –Ammarpad (talk) 12:34, 7 June 2018 (UTC)
  • Yes, we can go to Deletion review but that still means that the phrase "on the article's talk page" remains for deleted articles. All I am really proposing is that we remove this phrase if an article has been deleted, as it might confuse new users of Wikipedia. Vorbee (talk) 15:16, 7 June 2018 (UTC)
  • Just for clarity, here is what it actually says: The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page. So no, it doesn’t just say to use the article’s talk page, it says to use th appropriate page, which may or may not be the article’s talk page. Beeblebrox (talk) 19:53, 11 June 2018 (UTC)

Minor visual update to access locks

Following a an old RFC, the current access lock scheme for CS1|2 template is

  • (current) Freely accessible / Free registration required / Paid subscription required

The first icon is meant to convey open access, the second one is meant to convey limited access, the third one is meant to convey closed access. This scheme has as a few problems.

First, the red lock is not very recognizable as a lock. To fix this, I propose a more recognizable red lock

  • (new1) Freely accessible / Free registration required / Paid subscription required

However, an additional problem is that Green/Blue/Red makes does not convey progression, and was picked over a more logical Green/Yellow/Red by a non-statistically significant 1 vote, mostly because the yellow didn't look very yellow. It also tends to get lost in the sea of blue, e.g. (JSTOR 01234 Free registration required)

  • (old1) Freely accessible / Free registration required / Paid subscription required

To fix this, I propose a better intermediate level lock: grey

  • (new2) Freely accessible / Free registration required / Paid subscription required

Some people also didn't like the red, feeling it was too aggressive, so we could stick to green and grey:

  • (new3) Freely accessible / Free registration required / Paid subscription required

The "new2" scheme only has advantages compared to the current scheme: It has more recognizable icons, better accessibility, and better conveys levels of access. "new3" loses easier distinctions between limited and closed access, but is also less aggressive.

Which of the proposed schemes should we use?

  • new2 > old1 > new3 > new 1 > current. Headbomb {t · c · p · b} 02:45, 7 June 2018 (UTC)
  • new2, failing that new1, failing that current. Both of these have sufficient distinction in color and shape, with grey as a more intuitive color progression than blue thus my preference for new2. Current is not particularly intuitive but the different symbols are nonetheless quite distinct and thus recognizable enough once their meaning is learnt. Not a fan of new3: these symbols are displayed at a small size and the two different grey symbols are sufficiently "similar-ish" (very similar shape, fairly similar ratio of grey-vs-white even if the *pattern* in which it is used differs) that I suspect they may be hard to distinguish for people with limited vision. AddWittyNameHere (talk) 03:04, 7 June 2018 (UTC)
  • I'm going to rank these, if you don't mind, as well. I concur wholly with AddWittyNameHere. new2 looks best to me, though I really do object somewhat to the grey; then new1 and current, and finally, new3 (like AddWittyNameHere said, two grey locks are hard to distinguish, and that's bad for accessibility reasons). Great work, by the way! — Javert2113 (talk; please ping me in your reply on this page) 03:08, 7 June 2018 (UTC)
  • new2, and failing that, new1. Gray and gray doesn't help distinguish anything, especially when there aren't three right next to each other. New red lock looks nice. ~ Amory (utc) 10:29, 7 June 2018 (UTC)
  • new2 looks fine. Grey conveys "no information really", which is right for the middle lock (once you require login, restrictions have an almost infinite granularity) but not when we know for sure that something is paywalled. --Nemo 10:44, 7 June 2018 (UTC)
  • old1, new1, current, in that order, because progression/streetlights, and grey is more ambiguous than blue. ~ Tom.Reding (talkdgaf)  12:21, 7 June 2018 (UTC)
  • new4, old1, new3 Some people will only be able to visually distinguish a single element; color, lock body (open, partial, filled) or intensity (light, shaded, dark) so each icon needs to be distinguishable by a single element. I would suggest a new4 which makes the distinction between the open, half-filled and filled body of the lock more crisp and varies the color intensity/tone in a noticeable way between the three. I would also suggest a slight increase in size since some will not be able to resolve the body of the lock; removing the dot in the 'open' making the body white; and removing the dot in 'locked' making it solid. This should result in a more crisp image which is easier to resolve. Jbh Talk 15:44, 7 June 2018 (UTC) Last edited: 15:55, 7 June 2018 (UTC)
The problem with Lock-green-alt.svg is that it looks like an lowercase a. This is particularly bad when printed, or in grayscale. Headbomb {t · c · p · b} 18:44, 7 June 2018 (UTC)
You are right! Maybe using a different shaped lock body … like the keyed padlocks that are shaped more like an upside-down Ü See second and fourth pictures in gallery vs the first one at Master Lock. Jbh Talk 15:13, 8 June 2018 (UTC)
@Jbhunley: those get confused with HTML security locks like this one. Headbomb {t · c · p · b} 15:15, 8 June 2018 (UTC)
Ahh... I had not thought of that. Jbh Talk 15:19, 8 June 2018 (UTC)
  • new1 - That's the only one I think is the best option, To me the gold lock doesn't convey "Limited access" and the grey ones could be confused with something being hidden ? ... Not sure on the that but yeah I prefer new1. –Davey2010Talk 15:51, 7 June 2018 (UTC)
  • new1 per Davey. --Ahecht (TALK
    ) 18:15, 7 June 2018 (UTC)
  • new 3. I don't think the red is necessary, and draws unwarranted attention. Natureium (talk) 18:20, 7 June 2018 (UTC)
  • new 2, new 1, current (in that order). @Davey2010 and Ahecht: Doesn't limited access usually mean that it's partially hidden (such as you can view the first few paragraphs or something)? LittlePuppers (talk) 23:14, 7 June 2018 (UTC)
@LittlePuppers: The mouseover text says it means "free registration required". --Ahecht (TALK
) 23:27, 7 June 2018 (UTC)
Ah, okay, I see that now. Thanks, Ahecht! LittlePuppers (talk) 23:38, 7 June 2018 (UTC)
  • comments: If this topic is supposed to be, or to act like, an RFC (as proposer described it here), shouldn't it be treated as if it were an RFC? Shouldn't proposer add {{RFC}} so that editors who don't watch this page can know that it exists?
    I question the notion that there is a problem here to be solved. Where is the evidence that readers are confused by the shapes/colors of the current lock definitions? So far, all we have is proposer's opinion that the the red lock is not very recognizable as a lock and that Green/Blue/Red makes does not convey progression and that some people also didn't like the red.
    Where is the evidence to show that the red lock with a transparent opening is more recognizable as a lock than the current red lock? GBR isn't necessarily intended to 'convey progression'; just difference. The individual locks could be any color as long as the chosen colors meet the accessibility guidelines against both white and black backgrounds. People are comfortable with GYR but shades of Y that are accessible against both white and black are rather more bilious than yellow so blue was suggested as a more palatable option. Doesn't seem like a problem that needs fixing. Yeah, so some people don't like the red; some people don't like the blue (the sea-of-blue argument) and some people don't like the bilious yellow. Ok, we will never please all of the people all of the time so without a significant uprising to indicate that the red is disliked by most people, doesn't seem like a problem that needs fixing.
    In the original RFC, Editor NMaia suggested emojis as a possible option. That suggestion wasn't taken up but, upon reflection, I think it should be. The emojis are standardized Unicode characters: U+1F513 🔓 , U+1F510 🔐 , and U+1F512 🔒 . With a bit of css, these characters can be manipulated: Example title link⁠🔓. Further, because the emojis are characters, the no-wrapping issue for url access signalling might be resolved by the simple insertion of a word joiner character (&#8288; U+2060) between the url's marked-up title text and the emoji (see this discussion about why the current url access signals are allowed to independently wrap to the next line). —Trappist the monk (talk) 14:10, 8 June 2018 (UTC)
If you want data, I asked about 10-12 non-Wikipedian their opinions of the red lock, and about half recognized the dial-less lock as a lock. Everyone recognized the dial lock as a lock. Additionally every single one was confused by the Green/Blue/Red scheme ("why blue/what does blue mean", or made a comment "why don't you use yellow?"), but no one was confused by Green/Yellow/Red or Green/Grey/Red scheme. Headbomb {t · c · p · b} 14:17, 8 June 2018 (UTC)
• Building something off emoji may be the best idea. They are the most 'standard' icons and people across the world will be familiar with the iconography even if the visual details vary from implementation to implementation. Jbh Talk 15:18, 8 June 2018 (UTC)
I could support this idea, I think, so long as the free-to-read Unicode character could be differentiated somehow: maybe a white background? The opened lock might be hard to see. (As you can tell, I don't know anything about Unicode characters, or if they could be changed.) — Javert2113 (talk; please ping me in your reply on this page) 15:23, 8 June 2018 (UTC)
Emojis are by far the worst of ideas. Their appearances varies, they often look downright awful, and are often barely distinguishable, even to those with perfect vision, and aren't simply designed to convey information and meaning. And we also lose the association with the PLOS Open Access icon (this one meaning free to re-use). Headbomb {t · c · p · b} 15:24, 8 June 2018 (UTC)
Oh, and here I thought it was my terrible eyesight. Yeah, emojis might not be the best idea after all. — Javert2113 (talk; please ping me in your reply on this page) 15:40, 8 June 2018 (UTC)
  • new1 ~nmaia d 14:33, 8 June 2018 (UTC)
  • new2. I applaud Headbomb for conducting the study, which found that every one of the dozen or so participants were confused by the blue lock. We need more of this: ask the readers when you are making decisions that affect them. – Finnusertop (talkcontribs) 18:47, 8 June 2018 (UTC)
  • Not new2 or new3; it doesn't particularly help to have two items the same color, whether two red (new2) or two grey (new3). I share the concern about "doesn't look like a lock"; why not just use the same padlock as we're currently using for ordinary pages? Or we could just abandon the locks-only system entirely. Use an open padlock, some sort of intermediate character, and a non-lock thing like a big X. Go to JSTOR and look for anything (example), and see their icon for "you can't access this resource". Nyttend (talk) 21:29, 10 June 2018 (UTC)
@Nyttend: new2 doesn't have two red icons. What are you talking about?Headbomb {t · c · p · b} 23:14, 10 June 2018 (UTC)
Aren't left and right the same color? They look the same to me. Nyttend (talk) 02:12, 11 June 2018 (UTC)
Only if you're red/green colorblind. But you'd see that in every other scheme as well. Headbomb {t · c · p · b} 02:21, 11 June 2018 (UTC)
Not every scheme. I designed the main chart at WP:CANCER to be red-green-colorblind-friendly after I realized that the original red/green (chosen by a previous editor) was a problem. --Guy Macon (talk) 02:35, 11 June 2018 (UTC)
every scheme above is green/something/red save for new3 which is green/grey/grey. Headbomb {t · c · p · b} 02:41, 11 June 2018 (UTC)
Maybe we could mix some blue and orange into those? It wouldn't be the worst idea: blue-green for open-access, orange-red for closed access. Not sure if it's been implemented already. —Javert2113 (Let's chat!) 02:42, 11 June 2018 (UTC)
If you did that, you'd lose the association between progression of access and progression of color for 95% of people. Headbomb {t · c · p · b} 03:44, 11 June 2018 (UTC)
Yes, I am red-green colorblind, and I see the same thing in every other scheme; I just thought I should respond to the new ones, since seemingly they're the only ones under discussion. Sorry for the disruption; I didn't realise that they weren't the same colors. Can't we just scrap the whole color issue and use completely different icons, and the colors either wouldn't matter or they'd all be the same? Use an open padlock for "you have access" (similar to the one next to "Get online access" at [29]), use a closed padlock for "you don't have complete access", and an X on background (like File:Octagon-warning.svg) for "you have no access at all". Nyttend (talk) 03:08, 11 June 2018 (UTC)
Well, that's the reason why the icons are different, empty body + open shackle, half body + half shackle, full body + closed shackle. An X would be very unclear in meaning (broken link? not working? disabled? don't go there? hide/close citation? hide/close identifier?), and could also be confused with the character X. Headbomb {t · c · p · b} 03:32, 11 June 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Yes, I'm worried about the semiotic differences between a closed shackle and an X. They're different, sure, but as Headbomb notes, folks might not be able to immediately distinguish the two, insofar as instant understanding of access to information is concerned. But that's not the proposal at hand, so please pardon my digression. —Javert2113 (Let's chat!) 03:46, 11 June 2018 (UTC)

By the way, what does "limited access" mean in this context? No authentication needed, but issues not related to authentication (e.g. technical issues; maybe the website goes down a lot) may prevent access? As far as "X", how would you ever get that confused with the letter X in running text? Who's going to confuse my proposed image with a simple character? Nyttend (talk) 23:33, 11 June 2018 (UTC)
See Help:Citation Style 1#Registration or subscription required (current blue locks [registered/limited]). Headbomb {t · c · p · b} 00:40, 12 June 2018 (UTC)
  • old1 > new2 > new1 > current > new3. Old1 looks plenty yellow to me, but barring that, gray is fine — pythoncoder  (talk | contribs) 14:29, 11 June 2018 (UTC)

Polling templates

I suggest including the polling templates on Commons to Wikipedia. It would look better on Requested moves, Articles for deletion, and Proposed mergers and other Wikipedia proposals.
-- (talk) 14:03, 7 June 2018 (UTC)

Remove default subject for "Email this user"

Can we please remove the default "Wikipedia email" subject for "Email this user" and force editors to add their own custom subject? It would make my Inbox much easier to navigate and I imagine the same would be true for others. --NeilN talk to me 14:38, 11 June 2018 (UTC)

Follow up at MediaWiki talk:Defemailsubject. — xaosflux Talk 15:13, 11 June 2018 (UTC)

Proposed mergers

A discussion at the village pump in 2013 overwhelmingly concluded the current proposed mergers system (the process & templates) to be inadequate. A consequent discussion on implementation of an automated system similar to requested moves was archived after 2 months of inactivity. The latter discussion had 6 participants; no conclusion was reached. I would like to see if there is a change in consensus to see if we can reach a conclusion. — Preceding unsigned comment added by (talk) 20:54, 11 June 2018 (UTC)

Proposal to make Uw-Unsourced warning more user friendly Suggestion

I have been posting (subst'ing) this message User:DBigXray/ref as a Twinkle Welcome message for newbies who are not aware how to add sources. I have posted this on hundreds of talk pages of newbies and several editors have copied this subst and modified this to their own version with this image, I propose to update the Template talk:Uw-unsourced1 with a screenshot image and text as as below. Based on my experience and positive feedback I have recieved, I believe this will help Wikipedia's acute problem of unsourced editings. --DBigXray 12:11, 14 June 2018 (UTC)

(updated) proposed text and the image to be added at the end of the template

Just follow the steps 1, 2 and 3 as shown and fill in the details

Adding a well formatted references is very easy to do.

  1. While editing any article or a wikipage, on the top of the edit window you will see a toolbar which says "cite" click on it
  2. Then click on "templates",
  3. Choose the most appropriate template and fill all relevant details,


I wouldn't support fill as many details as you can, but I'd support fill all relevant details. Also, the toolbar should support other {{cite xxx}} templates and order them alphabetically. Headbomb {t · c · p · b} 13:38, 14 June 2018 (UTC)
  • The proposal is open to any Copy Editing of the said text, if others feel it can be improved. I had written as many so that at least the Title publisher dates etc are available for a google search in case of WP:LINKROT. --DBigXray 14:12, 14 June 2018 (UTC)
  • I have updated the text with your suggestion --DBigXray 17:12, 14 June 2018 (UTC)
  • The main question I have at this point is is the RefToolbar enabled by default?, especially for IPs and the like? Otherwise we'd be giving a screenshot of something they don't have access to. I do like the idea though. Headbomb {t · c · p · b} 18:13, 14 June 2018 (UTC)
  • @Headbomb: Did a quick check from a different browser, where I'm not logged in, and it appears to be at least enabled for IPs on desktop. Don't know about new accounts or mobile, though. AddWittyNameHere (talk) 18:34, 14 June 2018 (UTC)
  • @Headbomb: I am quite sure, it is also enabled for the newbies. I am saying this from the confidence of experience, None of the hundreds of newbies who got this template from me ever complained about not seeing the refToolbar. I did recieve many thanks from them. Since it is enabled for IPs it is safe to say it is also enabled for new users. --DBigXray 20:52, 14 June 2018 (UTC)
If it's on by default, then there's no possibility of confusion. So I say add it to the warning. Headbomb {t · c · p · b} 21:51, 14 June 2018 (UTC)
Note that we have lots of editors that a user can potentially encounter, not just WikiEditor 2010. Also note that the reftoolbar is currently not supported by a single person, so any changes will require it finds a new maintainer. —TheDJ (talkcontribs) 09:37, 15 June 2018 (UTC)
  • WikiEditor 2010 by its name now appears to be 8 years old. Do you have any wise estimation or numbers of users editing wikipedia and not using WikiEditor 2010. I believe those numbers will be far less in comparison to users of WikiEditor 2010. This proposal does not need any source code edits in the Reftoolbar. Just a suffix in the warning template is all it needs. The image is self explanatory and does need any reading of wikilinks or policy pages. The links would still be there for people interested to know more on policies. Based on my experience we cannot slap the template and then expect the said newbie or IP to go through the wiki policies and understand HTML tags so that he can make a sourced edit. --DBigXray 16:38, 16 June 2018 (UTC)
Support in principal. I'm sure the debate about what screenshot to use can be resolved. — BillHPike (talk, contribs) 23:06, 17 June 2018 (UTC)

Proposal for closing the Simple English Wikipedia

There is currently a proposal on Meta for closing the Simple English Wikipedia at meta:Proposals for closing projects/Closure of Simple English Wikipedia 2. All are invited to participate. TonyBallioni (talk) 17:29, 19 June 2018 (UTC)

Idea lab

Problem behaviors

Wikipedia is generally a wonderful place to write and connect. Problem solving techniques such as Rfc's and third-party really do work pretty well most of the time. But there are some things--some people--that do seem to fall through the cracks fairly dependably. I would like to see a 'Be nice-Be respectful' policy that when violated can be reported, and if nothing else, that Wikipedia would keep track of the number of violations the same person gets over and over, so I would like to see a policy for consequences for repeatedly biting, not only newcomers, but anyone that disagrees with them. People just get away with that here because it isn't about consensus on content. I have seen more than one editor driven completely off Wikipedia because of personal attacks, slanders, insults, and various kinds of bad behavior by the same person. Nothing ever happens about it. I think that's wrong. Something should happen. It violates Wikipedia's stated policy and that policy should be better enforced. Jenhawk777 (talk) 22:56, 29 April 2018 (UTC)

  • We do have Wikipedia: Etiquette but I am not sure what happens to Wikipedians who violate the policies listed here. Vorbee (talk) 17:00, 30 April 2018 (UTC)
I don't know about 'solutions'; but I and a few others are actively exploring if we can figure out if we can make it easier for admins and others to 1. find problematic comments (assuming that's part of the challenge): Feedback very welcome. Some more ideas we've experimented with some are at Iislucas (talk) 18:44, 24 May 2018 (UTC)
Nothing. Nothing happens to them. They move on claiming they do it all for the good of Wikipedia. That's the problem. Instant reverts, threats, insults based on ideology, point of view, differences of opinion, not based on consensus--things where one person is not clearly "right"--but the one person is asserting their "position" by domineering and intimidating. Nothing happens. They get you to leave. That's all that happens--at least that is all I have seen so far. I have been on Wikipedia about a year and a half, I have observed this one editor have just over a dozen of these types of conflicts, and people repeatedly contact Admin. about him and nothing happens. He seems bullet-proof. And that's just wrong. What are the chances more than a dozen people are in the wrong instead of him? Wikipedia needs to do a better job at this. What are the options? I would take any improvement at all. Jenhawk777 (talk) 22:54, 30 April 2018 (UTC)
Behaving like a dick can, and does occasionally get people blocked (you've probably already seen Wikipedia:Civility#Dealing with incivility). If the problematic behaviour has been gross, and you have recent examples of it that you're willing to present succinctly, and with diffs, then you can start a thread at WP:ANI. – Uanfala (talk) 23:11, 30 April 2018 (UTC)
I suppose I can start keeping a record since Wikipedia doesn't, but I am afraid of retribution if nothing comes of it. This person is vindictive. I was looking for a more proactive approach from Wikipedia.Jenhawk777 (talk) 16:00, 1 May 2018 (UTC)
this is an example right now. Not sure what idea can come out of this thread though; I would like to see civility enforced more, however we do already have a policy (two, WP:NPA and WP:CIVILITY) which are in the range of "Be nice-Be respectful' policy". I think it is not as much as there being a lack of policy but people unwilling to enforce for whatever reason. Galobtter (pingó mió) 16:07, 1 May 2018 (UTC)
Thank you for acknowledging the issue is real. Yes, we have perfectly good policy, but what good is policy without enforcement? I completely agree that is the problem. Disputes over content are solvable. Wikipedia cares about its content and has made good provision for multiple pathways toward resolution. Not so with personal abuses and attacks. Wikipedia does not keep a record of how often any individual gets called for a mediation dispute or watch for other signs of problem behavior and as far as I know, there is no special path for reporting that particular kind of problem--and certainly no enforcement of the policies we have. I simply want that person to stop. I personally have no ability to enforce the minimum behavior requirements of the larger group--that we all agree to--onto the group's few misanthropes. I can't see how this can be improved without some kind of policy change. Jenhawk777 (talk) 05:39, 2 May 2018 (UTC)
Yes, the issue is very real. Extreme perpetrators can be reported at WP:ANI and its related noticeboards, where administrators will decide what to do about it. But usually, rudeness is tolerated and you have to be grossly insulting or disruptive to be sanctioned. The reporting process is also quite bureaucratic and needs good understanding of it to be effective: where else would someone reporting abuse be told, "You haven't reported it properly, so we will ignore you"? I believe that this sad state of affairs is one of the biggest reasons why our community struggles to keep high-quality editors. You and I are not the only ones to have brought it up in one forum or another before now, but as long as the majority of the more vocal editors (especially administrators) are prepared to tolerate it, nothing will be done.
@Jenhawk777: However, from what you say it sounds like you have an abuser who may be overstepping the mark. If you drop me a private email with their username (let us know here if you need help with that), I will take a look and see if anything can be done — Cheers, Steelpillow (Talk) 14:38, 3 May 2018 (UTC) [updated 14:49, 3 May 2018 (UTC)]
DID overstep--not happening right now; we are no longer working on the same article. I am so grateful for the offer, but it just isn't enough to protect myself in one instance. Everyone should be protected. I have watched this person run several people off of Wikipedia. If it hadn't been for one of the good ones stepping in and saying, 'come work with me over here in a corner for awhile', I wouldn't have known Wikipedia could actually be rewarding and fun. I have tried to do that for some of the others, but they are so discouraged from the experience--and the fact it seems to them that no one cares--that they just leave. I know there are people here who care. The responses here are evidence. But Admin needs to do a better job at this. It is a problem for Wikipedia even if they don't recognize it. When people go away in this manner, they say bad things about Wikipedia. And frankly, there isn't an endless supply of people who want to write for free who are willing to put in the time to develop enough experience to actually be any good at it. Even factoring in inevitable losses, this should still be seen as an issue. Thank you again for the kind offer, but what I really need is a suggestion for a workable policy change. Jenhawk777 (talk) 18:42, 3 May 2018 (UTC)
Policy is not at issue. The problem is enforcement, it is too hard to get things done. For reasons I cannot understand, the further up people are in the hierarchy, the less they seem to want to recognise that. This is about winning hearts and minds, not policy. And sadly, I am no good at that. — Cheers, Steelpillow (Talk) 19:17, 3 May 2018 (UTC)
Well, apparently, I am even worse--I can't even get agreement here among people who actually agree with me. :-) Whatever the problem is, those with some actual influence need to act. Jenhawk777 (talk) 07:29, 7 May 2018 (UTC)
Agree to a point. But I don't think enforcement will work, for exactly the reasons you say. See comments below. Andrewa (talk) 21:26, 7 May 2018 (UTC)

Following the threads of this section I came across the Wikipedia:Kindness Campaign to which I've now signed up and which I recommend. Perhaps just promoting this WikiProject is what is needed.

I certainly think there's a problem. We cannot expect to attract and keep new editors, and particularly the sort of editors on which Wikipedia depends, in the current environment.

And I think something specifically focused on restoring no personal attacks to general acceptance might be the key here. See User:Andrewa/gentle editor for some of my ideas on that, and comments on its talk page or (far better) here (or even both) of course very welcome!

There has been no consensus to abandon (or even modify) NPA, but it seems to have happened anyway. I guess the other possibility is an RfC to modify or abandon the policy, and regard these behaviors as acceptable, but I myself believe that would be the beginning of the end for Wikipedia. I could be wrong. Andrewa (talk) 05:51, 9 May 2018 (UTC) Andrewa (talk) 21:26, 7 May 2018 (UTC)

Okay, so if enforcement isn't the answer--what is? I am a member of Wikipedia:Kindness Campaign and practice that--even with the person who kept attacking me--they criticized me for my "excessive civility" too! I don't think joining up is high on their list. You know, I need to add here that most of the people on Wikipedia are great--helpful, patient, kind--but when there is one whose behavior is so egregious, for so long, it can color everything. I'm trying not to let that happen. That's why I'm here. We have a lot of different kinds of people here with lots of different views and need to treat everyone with respect even if they have the audacity not to think like we do! Perhaps this is a personality thing that can't be fixed. IDK. I admit I'm feeling a little discouraged about all this. Jenhawk777 (talk) 20:33, 9 May 2018 (UTC)
I think we need to demonstrate (and perhaps first build) consensus among Wikipedians in general and admins in particular and perhaps even within ARBCOM that NPA is important. Enforcement might follow in some cases, but demonstrating that consensus might be enough without enforcement being necessary, and without demonstrating that consensus enforcement will not help, IMO, and won't happen anyway. Interested in other ideas, and ideas as to how to best do this. I've linked above to my own best attempts so far.
The only other possibility I can think of is an appeal to the founder. I'm almost concerned enough to give that a go.
Hang in there. If enough people give up on NPA, IMO it's the end of Wikipedia. Hard to imagine? Where did Kodak go?
If it did happen, the world would not end, and thanks to copyleft neither would most of our work so far. Citizendium (which ruthlessly enforces NPA) or another fork (well, currently it's not strictly a fork, but might become one again) would take over. But far better to fix Wikipedia IMO. Andrewa (talk) 22:54, 9 May 2018 (UTC)
We've been trying to build said consensus pretty much continuously for the 5 years I've been around, with no success. We are self-governed, and those participating in the self-governance are a self-selected few who are not representative of the whole. The way we decide things is not likely to change in the foreseeable future.
Over the years I have watched the ongoing debate and given the problem much thought, and I've come to believe that (1) it is intractable in the current environment, and (2) the only hope is through gradual attrition and evolution. As stated, the policy is already in place, and it is routinely ignored with various rationales for ignoring it. Any new initiative to stop ignoring it would fail for the same reasons as the many others that have come before; nothing has changed sufficiently to make the difference. More at the essay WP:DISRESPECT.
The only other possibility I can think of is an appeal to the founder. Good luck. The founder no doubt has his opinions, but they don't carry any more weight than those of any other editor. Those opposing stricter enforcement of behavior policy are not going to withdraw their opposition because of a statement by him.
I promise you that this thread is a dead end and a waste of time. ―Mandruss  23:26, 9 May 2018 (UTC)
Cancelled process mini.svg
I guess we sometimes need to dismiss what's not possible, but the purpose of this page is to incubate and encourage new ideas rather than assess them.
Jimbo is the only member of the founder user group, and has some other privileges as well. He's been understandably reluctant to use them but they are still there for the moment at least.
Agree that Those opposing stricter enforcement of behavior policy are not going to withdraw their opposition because of a statement by him. I'm one of them, so I should know! I'm hoping we can find a more effective way.
In fact one of the key problems I see is the common assumption (which I think you may be making too) that the only way to encourage adherence to NPA is by stricter enforcement. My hope for this thread is that we can brainstorm some other ways.
The other key mistake is to assume that violations of NPA are also violations of civility. In fact NPA is far, far broader then that. That's probably where I think ARBCOM and WP/ANI (on which I lurk from time to time) have gone wrong... once we give up on NPA and fall back to mere civility, we tend to fall back from encouragement to enforcement too. Andrewa (talk) 02:02, 10 May 2018 (UTC)
Mandruss--ouch. I hope you're wrong--but I'm afraid you're right. This could be a waste of time, but as I see it, we can't know till we've spent it. I have to try. I love Wikipedia--but using a colorful but descriptive metaphor--I think it keeps stepping on its own foreskin.
I went and read WP:DISRESPECT since I had never seen it before. Forgive my straightforwardness at this point, but in my POV, that is not a good or helpful article. It's not hard to identify disrespect--anyone on the receiving end of it can do so. I was recently reading an article on the neuroscience of making friends; basically, treating people with respect boils down to being as cooperative as possible and as pleasant as possible: correct others as you would like to receive correction. That's pretty much it. It's not difficult to understand, and there is no value that I can see in trying to make it more complicated than it is. If someone feels disrespected that should be addressed; period. It should be that simple.
Perhaps I simply haven't been around long enough and I don't understand how complicated this problem can become. Even if we used the same steps for personal attacks that we have for content disputes--what would be the end goal? To force an apology? No, that would not only never work--it would be disrespectful! But if there is no recognition of violation of existing policy, and there is no clear consequence--something like the three revert rule--three attacks in a row and you're blocked--then in my view this is not a real policy--this is just hypocrisy. We either stand up for what we claim to believe in or we don't. If we don't, let's take down the policy and admit it's a free for all here. Jenhawk777 (talk) 04:11, 10 May 2018 (UTC)
Perhaps I simply haven't been around long enough and I don't understand how complicated this problem can become. Perhaps. ―Mandruss  05:10, 10 May 2018 (UTC)
Well, I've been around for a while, and I think you're hitting some nails squarely on the head. But yes, it's complicated. We're not going to make Wikipedia perfect here, but we can make progress IMO.
WP:DISRESPECT is an essay not an article, and it's not obvious to me how much of it is the opinion of the person citing it but they're one of three contributors and mentioned by the creator. I don't find it helpful either, but one trap to avoid is assuming that if you treat others the way you want to be treated, they'll be happy. They may not want to be treated that way just because you do! See this off-wiki essay of mine. So that essay is well worth reading if only to understand the other mindset.
And that's the problem with having something like the 3RR for personal attacks. What's good vigorous discussion for one person can be offensive to another. That's one reason that NPA is so sweeping. Any idiot can understand it, and most of them do. (;->
You might also find User:Andrewa/Rules, rules, rules helpful. It's another essay, quite recent, trying to point out how radical and interrelated some of our rules are. Or wp:creed is another of mine, older but a favourite.
Hang in there! Andrewa (talk) 06:27, 10 May 2018 (UTC)
I wrote the essay two years ago and it has been on my user page since then. Recently others decided it should be in WP space. No, it's not my opinion, it's my understanding of the prevailing consensus position, with which I disagree. It ends with "Do you buy it?" Just thought I should clarify that, since it's not clear to me that it's clear to you. ―Mandruss  07:34, 10 May 2018 (UTC)
It's still there on your user page I see, and that explains its history. It would have been helpful IMO if a talk page entry had been created when the essay was copy-and-pasted from your user page. As it is, it's arguably a copyvio... the enigmatic reference to your user page in the edit summary doesn't satisfy the copyleft requirements. I'll fix it.
Fixed. Andrewa (talk) 15:50, 10 May 2018 (UTC)
It still doesn't seem any help to us in incubating ideas on this page. But let us move on. Andrewa (talk) 11:22, 10 May 2018 (UTC)
Mandruss, thank you for explaining--and for not taking offense! I apologize if my statement did offend in any way. I agree with you that treating others the way I want to be treated doesn't always make people happy. My assertion is that they should be treated the way they want to be treated--as long as it is within reason. But let's be real. Some people are just bad-tempered. That's just the way it is. Some people won't apologize or admit to an error if their lives depended on it. So what to do about the uncooperative? Is there anything we can do?
Andrewa, vigorous discussion is not the issue. Just today I saw a discussion where one User was attempting to ask the editor I had the problem with to be patient with newcomers, that teaching is a better response than ridicule, that it's easy to forget what it was like when you were new, that threatening and belittling someone with 190 edits for what they don't know yet is counterproductive, that what appears a point of view in a newcomer is often just an interest (Amen!) and more in that vein--it was wonderful--absolutely respectful and kind. His response was "I'm not talking about this" and he deleted the discussion.
This kind of thing happens with him about every four to six weeks--someone has a problem with him, calls for some kind of arbitration with him--it's a pattern. It's easy to see why: his first response to anything he doesn't like is a mass revert without explanation or discussion. If you ask why, you get insulted. If you had a brain you would know you're a crap writer. If you try to adapt it to what you think the problem is and put it back, you get threatened. You can ask for compromise till you're blue in the face. Mostly you'll get ignored. There is no discussion--vigorous or otherwise. I can't tell you how many times I tried to discuss. I ended up with an Rfc where every single vote was in my favor--and it made him so angry he put his point of view in long, long "notes" to counter that. Consensus was against him--he didn't care. He's been doing this for years apparently and is basically bulletproof because of longevity. And because Wikipedia makes no effort to keep track of how many conflicts an editor is involved in or how frequently the same editors are involved in them. That's what I have seen. Jenhawk777 (talk) 19:24, 10 May 2018 (UTC)
The NYRM2016 fiasco had some similar issues. Several of those determined to prevent the move made repeated personal attacks on me and others. (And succeeded somehow in getting a no consensus decision despite the policy and facts both being clear and undisputed. The only change when NYRM2017 succeeded a year later was that we'd had an RfC that clarified that NYS wasn't the primary topic, which surely was clear before the RfC, but the 2016 closers firmly refused to confirm or deny this. I doubt the full story will ever be told. But what concerns us here is just the behaviour.) I reported these personal attacks twice at ANI, with diffs. The first time several non-admins agreed it was clearly a personal attack, but there was no evidence any admin even looked at it, and it was auto-archived through lack of further discussion. The second time, nobody even commented.
If that's not busted I don't know what is.
The "idea" we're supposed to be discussing is to have a policy prohibiting personal attacks. There seems to be no question that we already do have one! Andrewa (talk) 03:16, 13 May 2018 (UTC)
I don't see this discussion as limited to policy only, it has also included discussion of some kind of follow through and/or increased enforcement of the policy we already have. Though I do have to say that any policy without any enforcement is a policy in name only-- in my opinion.
Oh man! Been there! You have all my empathy! Any suggestions for monitoring/enforcement/policy changes/fire-bombing--anything? Jenhawk777 (talk) 20:03, 17 May 2018 (UTC)



This is kind of a weird idea, but I would like it if some of you considered improving the article Rudeness, with a particular emphasis on instrumental rudeness and the difficulty of determining what counts as "rude". I think that a clearer understanding of the incentives and the complexities would help us all. WhatamIdoing (talk) 02:00, 25 May 2018 (UTC)

I agree. That's kind of a weird idea. Face-smile.svgMandruss  02:06, 25 May 2018 (UTC)
Ha ha! The line between humor and rudeness is a little smudged isn't it? Thanx for the invite. I will take a look there, but I think I am probably done here. Wikipedia is, apparently, mostly happy with the status quo. The policy should read "Wikipedia is not for the faint of heart. Edit here at your own risk." It would at least be honest. Jenhawk777 (talk) 02:46, 25 May 2018 (UTC)
More accurately, a majority of the tiny fraction of editors who determine practice concerning these matters are happy with the status quo. They are self-selected, not elected representatives, and are therefore not "Wikipedia". The distinction is crucial. ―Mandruss  02:53, 25 May 2018 (UTC)
It's a rather weird situation. WP:NPA is a policy, and if any other policy is openly flouted, say at WP:RM, then many editors will descend in enthusiastic defense of the need to comply with say the WP:AT policy just because it is policy, because it reflects wider community consensus, etc.. NPA is extreme: Personal attacks harm the Wikipedia community and the collegial atmosphere needed to create a good encyclopedia... Insulting or disparaging an editor is a personal attack regardless of the manner in which it is done. (emphasis as in the original, omitted text indicated by ellipsis) It presumably represents consensus. None of the editors (and sysops) who regularly violate it have raised an RfC or even a discussion to have it weakened. How has it come to be so widely ignored? Andrewa (talk) 07:06, 25 May 2018 (UTC)
How has it come to be so widely ignored? The venues where practice is actually determined, such as WP:ANI, are downright nasty environments, and they are widely avoided by editors with milder dispositions who don't care to be around that unpleasantness. That leaves the controlling group highly skewed in the direction of editors who are either (1) combative and hostile, or (2) relatively unbothered by combativeness and hostility—so we have (quite naturally) ended up with a culture that tends to tolerate and excuse combativeness and hostility. That means widely ignoring written behavior policy. My question, not that it matters at this point, is how that managed to become written policy in the first place.
If we had a representative system of government with wide participation in elections, the "milder majority" would for the first time be fairly represented in decisions regarding editor behavior. I have little doubt that the resulting culture would be quite different, and Wikipedia would be a very different place at which to volunteer one's time. But the odds of that happening in our lifetime approach zero, as we would never reach the clear consensus required for such a change. Hence, intractable. ―Mandruss  07:40, 25 May 2018 (UTC)
I'm not sure the article is all that relevant. The lead there reads Rudeness (also called effrontery) is a display of disrespect by not complying with the social norms or etiquette of a group or culture. But that's too general... what is rudeness in our particular group or culture ie English Wikipedia? To make the article relevant, we'd need to find sources that described Wikipedia culture in particular, and cite these. Our own opinions as to what should be considered rude don't belong in the article namespace. They do however belong in the project namespace (here) and the project talk namespace (eg WT:NPA). Andrewa (talk) 07:06, 25 May 2018 (UTC)
I don't think that editing anything in main space can help. For a start it can be challenged over a lack of reliable sourcing, and then it irrelevant if you don't think you are being rude, with "I am just speaking plainly - and anyway they deserve it," kind of self-excuses. Nor do I think that a direct appeal to our founder can go anywhere. I once disagreed with him and he responded with exactly the kind of deliberately offensive insult we are complaining about here. Wikipedia needs a change of its corporate culture and that is extremely difficult if the head honcho is blind to their own failings and therefore themself part of the problem. But I am not wholly dispirited, see the next subsection. — Cheers, Steelpillow (Talk) 10:27, 25 May 2018 (UTC)
I think that a lack of understanding is a problem in these discussions, and when editors don't know anything about a policy-related issue, they often look at relevant articles. (See, e.g., Review article, which is linked in more than 3,000 pages outside the mainspace – 12 links in messages to editors for each link in the mainspace. People use that article to understand Wikipedia's rules.)
I don't think that we can deal with the civility problem when most editors conceptualize the source of rudeness as "Poor guy, he lost his temper" instead of "Hey, that guy chose to be rude. Why would a rational person do that? Oh, I get it: editors choose to be rude because being rude helps you win disputes in this community".
The smaller problem is the difficulty of defining rudeness: it's not just how the recipient feels, it's not just what the speaker intended, and it's definitely not what the speaker later claims to have intended when someone complains about it later. Think about the wikilawyering we see with NPA – the guy who claims that "You're stupid" is a personal attack, but "Everything you've posted on this page is stupid" is not a personal attack. Guess what? They're both personal attacks. They're both uncivil. They're both rude. They're both the kind of thing that we don't want in this community. But until we understand the difficulty of defining this, we won't get very far. And, yes, I do believe that reading some high-quality sources that discuss the subject of rudeness directly will help improve these discussions. (And if you're going to consult some sources, you might as well improve the article while you're at it...  ;-) ) WhatamIdoing (talk) 05:27, 29 May 2018 (UTC)

Best practice

I think the only way ahead is to look at best practice in the wider world and see if there is anything there we can learn from. I have some experience of civility codes in both commercial and public organisations, all in the UK. Here are some of my observations:

  • It is becoming increasingly accepted that rudeness and disrespect are in the mind of the recipient; if they feel insulted by you then you have insulted them, whether you intended to or not. WP:IUC needs updating accordingly.
  • Rudeness is about more than just words. Aggressive behaviours can be equally rude, not only in active aggression such as reversions but also in passive aggression such as refusal to acknowledge or discuss an issue or to admit any personal failing. WP:IUC could make this clearer.
  • Overly-detailed prescriptive guidelines are the wrong way to implement policy. An enlightened moderator is absolutely essential in dealing with incidents that escalate. As it stands today, WP:IUC is a classic example of how not to do it and does nothing but provide ammunition for logic-chopping excuses and "I have nothing to apologise for" attitudes. If it is simplified and refocused on perceived intent, that should help the moderating Admins to make better decisions.
  • Apologising for unintended harm, such as a perceived insult, is increasingly becoming mandatory. It is in this respect analogous to a fine for a parking offence, where the parking itself is only a civil offence but failing to pay the fine is a criminal one. Such a forced apology may well be mealy-mouthed and insincere, but it has been seen to be made and that is the crucial thing. Once somebody has been forced to cough up several such, they will begin to get the message. WP:CIVIL is grossly behind the times in this respect. It also needs a shortcut such as WP:APOLOGY (which currently redirects to an essay) to help raise awareness of its critical importance.
  • To be effective and deal with expert wrigglers, moderators also need a generic getout clause allowing, "we just find it unacceptably disrespectful overall" judgement even though specifics may be vague. An example would be an unjustified demand for an apology, where the demand is really just a cynical revenge manoeuvre. I don't know to what extent our Admins have this already.
  • Logging and tracking of escalated incidents is the norm. "You have been called here on three separate occasions already this year" type information should be available to moderators at the click of a button. Typically, the data is time-limited to prevent lifelong black marks. I don't know of our Admins have such tools, but they should.

Phew! I had no idea this list was going to be so long. I just want to re-emphasise that all this is established best practice that I have seen working well in the outside world, it is not my personal rant. No wonder we Wikipedians are in such a pickle! — Cheers, Steelpillow (Talk) 10:27, 25 May 2018 (UTC)

It is becoming increasingly accepted that rudeness and disrespect are in the mind of the recipient; if they feel insulted by you then you have insulted them, whether you intended to or not. I feel insulted by that assertion!

Actually, I find that assertion problematic because such a subjective criterion makes it very easy for someone to claim insult and demand apology as a method to derail the discussion or to harass an opponent. Or, worse, for someone to find insult in an accusation that they have insulted someone, which could then repeat //ad infinitum//. You mention this, saying An example would be an unjustified demand for an apology, where the demand is really just a cynical revenge manoeuvre, but that directly contradicts the assertion that the insult is in the ear of the hearer rather than in the intent of the speaker or the judgment of a neutral party. Anomie 16:44, 25 May 2018 (UTC)

Haha, cute. But the ear of the hearer is not the same as their scheming. You have provided an excellent illustration of why moderators need to be free to exercise their common sense, thank you. — Cheers, Steelpillow (Talk) 19:00, 25 May 2018 (UTC)
I think that "the ear of the hearer" isn't the whole story. That approach suggests that if you sweetly smile while cussing at someone in a language that they don't understand, then you've not been rude. I cannot agree with this. On the other side, according to this model, if you do something that is widely accepted as being polite or even deferential, such as a strong young man holding open a heavy door for an elderly woman, and she says that anyone who holds a door open for an elderly woman is either sexist or ableist or both, then he's being rude.
That's not how it works. Cussing at someone who doesn't understand your disrespect is still rude, and holding a door open for someone who might need the help is still civil, even if the targets of these behaviors don't see it that way. WhatamIdoing (talk) 05:40, 29 May 2018 (UTC)
Such a forced apology may well be mealy-mouthed and insincere, but it has been seen to be made and that is the crucial thing. It seems not everyone agrees that forced apologies accomplish anything useful.[30][31][32][33] We even have an article about the non-apology apology. Anomie 16:44, 25 May 2018 (UTC)
Yes, and utterly ineffective it has all turned out to be. The real world has discovered that this approach does not work, maybe it's time Wikipedia grokked that too. — Cheers, Steelpillow (Talk) 19:00, 25 May 2018 (UTC)
If Wikipedia had the wisdom to take lessons from the real world, we wouldn't have self-selected self-governance, which is the root of most of its problems in my view. ―Mandruss  03:08, 26 May 2018 (UTC)
@Steelpillow: I find your list brilliant, and just what I was looking for when I first came here, and I agree with each of your suggestions--especially logging and tracking. The objections are addressable.
Anomie In my experience subjectivism is already present in this issue. Recognizing that won't make it worse and might make it better. WhatamIdoing If there is a misunderstanding of intent, it is easy enough to say so. I did just this past week. "I meant no disrespect" generally works. Steelpillow You could be right that forced apologies may not be the best approach, but the real question is whether it would be better than what we have. If Admins had that logging feature, compliance could be considered to demonstrate good faith overall. Accepting that everyone screws up occasionally, it is the repetition of negative behaviors that demonstrate a pattern and without evidence of remorse that could all be weighed to determine overall good faith. Sort of a systemic approach. Mandruss I disagree with your conclusion.
I personally think Steelpillow is on to something. The suggestions are specific and doable. Jenhawk777 (talk) 18:30, 30 May 2018 (UTC)
"I meant no disrespect" is meant to change the mind of the target. The workflow you're talking about is this:
Do something respectful (e.g., use the word "sir" when addressing a man 40 years older than yourself) > Target felt insulted > Try to change the target's mind > If target insists that the respectful behavior was rude, then you actually were rude?
That's not reasonable. Respectful behavior does not become insulting just because someone is feeling grumpy about getting old or being addressed in a formal fashion by a stranger. IMO a more accurate and civilized flow looks much closer to this:
Do something respectful = You were being polite, even if the other person has a problem with the culture that both of you live in. WhatamIdoing (talk) 01:45, 31 May 2018 (UTC)
Agree (with Jenhawk777). All well worth a try. I still think it would be less trouble for more effect to just reinstate wp:NPA, but there seems no immediate prospect of doing that. (I'd love to be proven wrong on that.) Andrewa (talk) 01:50, 31 May 2018 (UTC)
WhatamIdoing > "I meant no disrespect" is not intended to change the mind of the target--at least not when I say it. It is merely meant to inform. People do jump to conclusions about intent, but they can't actually read minds and know for certain what my intent was--unless I inform them. I have found it helps generally.
I also find acknowledging the other point of view is sometimes all it takes. For example, your scenario is not wrong even though it is not the same as mine. It is a perfectly legitimate approach that gets to basically the same place I do--(accept differences)--without all the steps in between. Perfectly okay, (but I like my steps).
If they still insist I was rude, then in their minds, that is their reality, so for them the answer to "was I actually rude?" is yes. They certainly have as much right to define their reality as I do to define mine. In my mind, my only legitimate approach at that point is to say I am sorry they have been distressed--because I care about other people's feelings. It isn't about one point of view being right--my intent was still my intent--so much as it is not assuming that just because my intent was to be polite that it actually came off that way to the recipient. An apology in this scenario simply acknowledges the legitimacy of other points of view.
At that point, if they are still upset, I would say there is reason to believe there are other issues going on. That is when we need some way to get Admin or something involved. So what do you think about Steelpillows suggestions? What about a logging program that keeps track of the number of conflicts an editor regularly gets into? What about inventing a conflict resolution protocol from scratch? That's one extreme to the other, I know, but throwing all the possibilities out there seems legitimate here. I would love to hear your ideas. Jenhawk777 (talk) 09:06, 31 May 2018 (UTC)
If I may add to that, how often have I heard the phrase, "I was trying to be polite" after some misunderstanding arose. Trying to be polite and managing to be polite are different things. For example in some cultures it is polite to stick your tongue out in greeting, in others it is rude. Get it wrong and you have committed a deadly insult, whether you intended to or not. So yes, it is very possible to be rude without intending to be. Furthermore, telling the offended party that they need to change their ways only rubs salt in the wound. "I am so sorry, I meant no disrespect, please can you forgive me", is a far more constructive response. — Cheers, Steelpillow (Talk) 10:06, 31 May 2018 (UTC)
Jenhawk777, when someone misinterprets your intention, why do you want to inform that person of your intention? Could it be that you are hoping to change his mind, away from his erroneous conclusion about your intention and towards an accurate understanding of your intention? WhatamIdoing (talk) 15:23, 31 May 2018 (UTC)
I am hoping to cast oil upon troubled waters, to soothe, and calm the storm of offended feeling. They may continue to think my behavior was rude, but they may also feel less inclined to pursue beating me up for it because intent--motives--matter, generally as much as actual behaviors for most people.Jenhawk777 (talk) 15:36, 31 May 2018 (UTC)
@Steelpillow: Is there some way to make the recommendations you suggested to Wikipedia? Jenhawk777 (talk) 19:19, 3 June 2018 (UTC)
I don't know the best way. People at Wikipedia talk:Policy have been saying that there is no formal process. Perhaps Wikipedia:Village pump (policy) would be a good place to take them next and get some more focused feedback. Or maybe it is better to post a link there back to this discussion? — Cheers, Steelpillow (Talk) 20:39, 3 June 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I don't think it's appropriate for me to copy your ideas and post them there for you, but if you do decide to do that, please tell me and I will go there and participate in discussion there too. Thank you! Jenhawk777 (talk) 14:46, 4 June 2018 (UTC)

OK. I have started a thread there by asking much the same question as in my last post. — Cheers, Steelpillow (Talk) 16:31, 4 June 2018 (UTC)
Awesome. Jenhawk777 (talk) 01:52, 5 June 2018 (UTC)

It seems that this discussion discussion can be summarized with one question - how are policies enforced?Vorbee (talk) 11:21, 16 June 2018 (UTC)

Expert review

Moved from WP:Village pump (miscellaneous): --Pipetricker (talk) 08:06, 1 June 2018 (UTC)

I'd appreciate feedback on an idea. I'm thinking of establishing a free expert review service for Wikipedia featured articles on academic topics - topics well-covered by reliable journals, such as medicine and astronomy. Once an article meets the FA criteria, the world's leading experts on the topic would fact-check it and tell you what they think of its comprehensiveness and neutrality.

I can only offer this service if I'm allowed to put two prominent links at the top of the current article version, one linking the reader to the version that passed review, and the other linking to a simple diff between the current version and the fact-checked version.

The world's topic experts aren't going to review an article if the version they endorse disappears into the article's history in a day or a month. They will if we link to the reviewed version. And the "simple diff" is a service to the reader: it shows them at a glance how the article (and topic) has evolved since the expert-review.

I've thought deeply on this for a long time. I asked BMJ, the publisher of The BMJ, to recruit experts to review Parkinsons disease, and they obliged. One of the reviewers was a main author of the current PD diagnostic criteria and another is the most-published author on the illness. This was a very high quality review. That's the standard of review I intend to maintain.

Do you think rigorous independent expert-review of featured articles is a good thing, and would you support prominently linking to the reviewed version and the diff? --Anthonyhcole (talk · contribs · email) 13:34, 30 May 2018 (UTC)

  • I'd be in favour of this, for what would inevitably be a rather limited number of articles, with some kind of simple control/approval process. In line with WP:MEDRS principles, I think there should a time-limit of up to 5 years set on the links, unless there's some kind of re-review. Johnbod (talk) 13:58, 30 May 2018 (UTC)
  • Not sure who will recall, but there were 2 similar proposals offered back in 2016: User:Atsme/WikiProject_Accuracy, which was presented at meta:Grants:IdeaLab, and a similar project was presented at the same time by another editor: Academic Reviewers. There's also Proposal:Expert review which is along the same lines. Atsme📞📧 14:08, 30 May 2018 (UTC)
How do you feel about those two prominent links at the top of the current version, Atsme? --Anthonyhcole (talk · contribs · email) 16:48, 30 May 2018 (UTC)
I'm fine with it. When I was researching for Project Accuracy, I spoke to quite a few academics (various teaching levels) and explained the significance of the GA & FA symbols on articles. Their responses are what inspired me to design the Seal. I still believe that once an FA goes through the drill of expert/academic review, they should be afforded some protection which makes that "seal" worth something. Atsme📞📧 16:59, 30 May 2018 (UTC)
  • Thank you, Atsme. I'm not sure where I stand on universal automatic protection for articles that have passed expert review. I think I'm against it but need to do more thinking about it. --Anthonyhcole (talk · contribs · email) 17:14, 30 May 2018 (UTC)
  • You're quite welcome, AHC - and if I may briefly explain why I feel some level of protection is needed...once an article has been reviewed to top level, any additions that follow will not have been reviewed; therefore, any newly introduced inaccuracies may be read/cited before the err is caught. The onus will fall on the promoting reviewers (presumably whose links are at the top). At least with some level of protection, it will allow the time needed to review & clear the new material. It is not that we are changing "the encyclopedia anyone can edit", it's simply a brief delay from time of edit to time of publication, but only for those promoted articles. Atsme📞📧 19:45, 30 May 2018 (UTC)
  • I think Dengue fever has been semi-protected since it was published in a peer-reviewed journal in 2014 and that hasn't ruffled any feathers. I see your point about protection. It may further encourage expert collaboration, too. As I say, I'm still making up my mind on this. But it's something for later, anyway. It's by no means a deal-breaker for me. Before I start spending my time and money on this, though, I need to know whether the community will let me do it. --Anthonyhcole (talk · contribs · email) 02:53, 31 May 2018 (UTC)
  • Hmm, the prominent links could be a hatnote, like the one we have linking to introduction articles, e.g like on General relativity. I think that at-least would be accepted by the community, and having a reviewed version does seem good; I'm just thinking - if we're not using the reviewed version as the default, we're sort of un-endorsing it; at the same time the fact that the reviewed versions would get out of date +general principles means we can't keep articles fixed on that. Not precisely related to this, but looking at the Project Accuracy pitch; most readers are not really critically looking at Wikipedia, and thus I don't think having reviewed versions would somehow make Wikipedia more reliable in the eyes of people Galobtter (pingó mió) 17:29, 30 May 2018 (UTC)
  • We have the WikiJournals which offer precisely this: WikiJournal of Medicine; WikiJournal of Science. --Jens Lallensack (talk) 05:56, 31 May 2018 (UTC)
    I agree; isn't this what the WikiJournals do? Mike Christie (talk - contribs - library) 10:33, 31 May 2018 (UTC)
    Agreed. Pull up, say, Rotavirus; you'll see a book icon next to the Featured Article star. - Dank (push to talk) 14:15, 31 May 2018 (UTC)
Was also here to say this, we already have Wikijournal where people can send FAs to get peer reviewed by professionals. Having one more similar process would drain the reviewer man-power. FunkMonk (talk) 14:16, 31 May 2018 (UTC)
It doesn't have to be separate - it can be coordinated in those topic areas. There's more to WP than just meds and science. Atsme📞📧 14:24, 31 May 2018 (UTC)
I've added more info lower down, but I thought I'd note here that I like the idea of coordinated mechanisms. I think that scholarly journals are an efficient way of incentivising expert engagement (whether WikiJournals or other journals), but I think that multiple mechanisms can work. E.g. an article gets written via WikiEdu, then undergoes GA, then expert review, then journal publication, then FA... etc. NB, There is also a WikiJournal of Humanities in the works. T.Shafee(Evo&Evo)talk 03:20, 15 June 2018 (UTC)

Jens, Mike, Dank and FunkMonk, I've been watching the development of Wikijournal of Medicine since its inception. My model differs in several important ways from Wikijournal of Medicine. The quality of the reviewers I'm offering is the highest possible. That's not the case with Wikijournal of Medicine. I won't be using the same pool of reviewers as Wikijournal of Medicine so I won't be draining that resource. I'm proposing we offer the Wikipedia reader a link to a simple diff showing them clearly the difference between the last reviewed version and the current version; Wikijournal of Medicine doesn't have anything like this in its model. My proposal includes a prominent link to the "reliable" version. The Wikijournal of Medicine model uses a tiny, essentially meaningless little book icon that no readers will understand without clicking and few will click. The names of all my reviewers will be published and prominently displayed on the reliable version; in the WikiJournal model the reviewers may remain anonymous. I'm not proposing to start a new journal to host the reliable version - the reliable version of an article that has passed review simply sits in the history of the article, available to readers who click the prominent link. There are other important differences too but this list should make it plain these are not the same product.

Let me emphasise this important distinction: The traditional academic publishing model relies on the reputation of the publisher, whom the reader trusts to run a high quality review by anonymous peers/experts, and the reputation of the authors, whose names are all disclosed. Both elements - the reputations of the publisher and the authors - are essential to rigorous science publishing. Wikipedia permits authors to remain anonymous and Wikijournal of medicine allows the reviewers to remain anonymous - leaving only the reputation of the publisher as a guarantee of reliability. That's not enough. WikiJournal has no reputation to speak of yet; in my model we use highly esteemed journal editorial boards with an already-established strong reputation for reliability to select only the very best reviewers. But even if WikiJournal were to develop a reputation rivalling Lancet and BMJ the WikiJournal model would still be inadequate. Humans - with careers and personal reputations and egos to protect - need to put their name behind the article. In my model the experts stake their reputations on the reliability of the reviewed article. I can't stress enough how important this particular difference between the two models is. (Although several of the other differences are very significant too, in terms of epistemology.) ---Anthonyhcole (talk ·