Jump to content

Wikipedia:Village pump (proposals): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Line 159: Line 159:
*'''Support'''. Everything in this proposal is already covered by existing policy, since [[WP:DEPS|deprecated sources]] are [[WP:QS|questionable sources]] that have been identified through an [[WP:RFC|RfC]] on the [[WP:RSN|reliable sources noticeboard]]. Of course, [[WP:ABOUTSELF]] and [[WP:CONTEXTMATTERS]] apply to deprecated sources as well as any other source. Aside from rare and unusual cases, the 5 listed responses are what editors commonly use for any unreliable source, and deprecated sources are no exception. I agree with {{np|Reyk}}'s order of preference for the responses, from highest to lowest: #3, #5, #2, #4, then #1. However, if the affected content is fully supported by at least one [[WP:RS|reliable source]], then #1 is the preferred option. I've described the process that I personally use for removing citations of unreliable sources at {{slink|Wikipedia talk:Reliable sources/Archive 61|Removal of sources}}. —&nbsp;'''''[[User:Newslinger|<span style="color:#536267;">Newslinger</span>]]'''&nbsp;<small>[[User talk:Newslinger#top|<span style="color:#708090;">talk</span>]]</small>'' 01:55, 7 December 2019 (UTC)
*'''Support'''. Everything in this proposal is already covered by existing policy, since [[WP:DEPS|deprecated sources]] are [[WP:QS|questionable sources]] that have been identified through an [[WP:RFC|RfC]] on the [[WP:RSN|reliable sources noticeboard]]. Of course, [[WP:ABOUTSELF]] and [[WP:CONTEXTMATTERS]] apply to deprecated sources as well as any other source. Aside from rare and unusual cases, the 5 listed responses are what editors commonly use for any unreliable source, and deprecated sources are no exception. I agree with {{np|Reyk}}'s order of preference for the responses, from highest to lowest: #3, #5, #2, #4, then #1. However, if the affected content is fully supported by at least one [[WP:RS|reliable source]], then #1 is the preferred option. I've described the process that I personally use for removing citations of unreliable sources at {{slink|Wikipedia talk:Reliable sources/Archive 61|Removal of sources}}. —&nbsp;'''''[[User:Newslinger|<span style="color:#536267;">Newslinger</span>]]'''&nbsp;<small>[[User talk:Newslinger#top|<span style="color:#708090;">talk</span>]]</small>'' 01:55, 7 December 2019 (UTC)
* '''Support''', the proposal is spot on and covers all possibilities. The deprecated sources need to be removed, but whether to retain or delete the associated text depends on what reliable sources say about the text cited, and is a matter of editor consensus already covered by policy. It is rare to find reliable sources that back text typically cited to deprecated sources, and the BURDEN should be on the editor wanting to retain the text to produce a reliable source. [[User:SandyGeorgia|'''Sandy'''<span style="color: green;">Georgia</span>]] ([[User talk:SandyGeorgia|Talk]]) 16:20, 14 December 2019 (UTC)
* '''Support''', the proposal is spot on and covers all possibilities. The deprecated sources need to be removed, but whether to retain or delete the associated text depends on what reliable sources say about the text cited, and is a matter of editor consensus already covered by policy. It is rare to find reliable sources that back text typically cited to deprecated sources, and the BURDEN should be on the editor wanting to retain the text to produce a reliable source. [[User:SandyGeorgia|'''Sandy'''<span style="color: green;">Georgia</span>]] ([[User talk:SandyGeorgia|Talk]]) 16:20, 14 December 2019 (UTC)

* '''Oppose'''. I tend to agree with Andrew Davidson's opinion above about the concept of deprecated sources being flawed. A nutty incident I came across was a source being removed on the grounds that it was deprecated, when its author was the topic of the article. I have also seen sources with embedded videos allowing television news broadcasts to be viewed being similarly deleted. <span style="font-family: Perpetua, serif; font-size:120%">&nbsp;&nbsp;&nbsp;&nbsp;←&nbsp;&nbsp;[[User talk:ZScarpia | ZScarpia]]&nbsp;&nbsp;</span> 02:29, 24 December 2019 (UTC)
* '''Oppose'''. I tend to agree with Andrew Davidson's opinion above about the concept of deprecated sources being flawed. A nutty incident I came across was a source being removed on the grounds that it was deprecated, when its author was the topic of the article. I have also seen sources with embedded videos allowing television news broadcasts to be viewed being similarly deleted. <span style="font-family: Perpetua, serif; font-size:120%">&nbsp;&nbsp;&nbsp;&nbsp;←&nbsp;&nbsp;[[User talk:ZScarpia | ZScarpia]]&nbsp;&nbsp;</span> 02:29, 24 December 2019 (UTC)

*'''Support'''. As is usual for these discussions, comments along the lines of "sometimes a deprecated source should be used" are already accounted for because deprecation does not prevent a source from being used, as described in detail at [[WP:DEPS]]. In fact, this proposal specifically (re)states that use of a deprecated source is permitted whenever consensus supports it. It may also be useful to reiterate, in response to objections based on disagreement with deprecation as a general concept, that the practice has been repeatedly endorsed by consensus across multiple discussions.
*'''Support'''. As is usual for these discussions, comments along the lines of "sometimes a deprecated source should be used" are already accounted for because deprecation does not prevent a source from being used, as described in detail at [[WP:DEPS]]. In fact, this proposal specifically (re)states that use of a deprecated source is permitted whenever consensus supports it. It may also be useful to reiterate, in response to objections based on disagreement with deprecation as a general concept, that the practice has been repeatedly endorsed by consensus across multiple discussions.
:I also think it’s important to note that even if the outcome here is inconclusive, it's likely that much of it would be supported by consensus regardless (e.g. some of the opposing arguments are focused on objections to specific points rather than the proposal as a whole). I would especially point out the implications of the apparent consensus against proposal 3 below: given the rationales, there appears to be consensus against any restriction that makes removing deprecated sources more difficult than removing any other source (or, as some have put it, giving them "protection"), which is a key point because of its relation to the issue that originally led to this discussion being opened. [[User:Sunrise|''<b style="color:#F60;font-family:Times New Roman">Sunrise</b>'']] <i style="font-size:11px">([[User talk:Sunrise|talk]])</i> 05:12, 24 December 2019 (UTC)
:I also think it’s important to note that even if the outcome here is inconclusive, it's likely that much of it would be supported by consensus regardless (e.g. some of the opposing arguments are focused on objections to specific points rather than the proposal as a whole). I would especially point out the implications of the apparent consensus against proposal 3 below: given the rationales, there appears to be consensus against any restriction that makes removing deprecated sources more difficult than removing any other source (or, as some have put it, giving them "protection"), which is a key point because of its relation to the issue that originally led to this discussion being opened. [[User:Sunrise|''<b style="color:#F60;font-family:Times New Roman">Sunrise</b>'']] <i style="font-size:11px">([[User talk:Sunrise|talk]])</i> 05:12, 24 December 2019 (UTC)
::If it weren't for the fact that [[Wikipedia:Nobody reads the directions]], and that people on a righteous mission don't always slow down to consider details, like whether a specific deprecated source should be used, I might agree with [[User:Sunrise|you]]. What do you say to [[User:ZScarpia]]'s example? Just someone not following the directions, so nothing to worry about? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 06:00, 2 January 2020 (UTC)

*'''Support''' We have people removing predatory journal articles from WP and replacing them with <nowiki>{{CN}}</nowiki> tags. These predatory journals are generally still more reliable than what we are discussing removing here. We of course want to allow a small number of exceptions such as we do for withdrawn journal articles like Wakefield's paper when we are discussing said paper. [[User:Doc James|<span style="color:#0000f1">'''Doc James'''</span>]] ([[User talk:Doc James|talk]] · [[Special:Contributions/Doc James|contribs]] · [[Special:EmailUser/Doc James|email]]) 10:10, 24 December 2019 (UTC)
*'''Support''' We have people removing predatory journal articles from WP and replacing them with <nowiki>{{CN}}</nowiki> tags. These predatory journals are generally still more reliable than what we are discussing removing here. We of course want to allow a small number of exceptions such as we do for withdrawn journal articles like Wakefield's paper when we are discussing said paper. [[User:Doc James|<span style="color:#0000f1">'''Doc James'''</span>]] ([[User talk:Doc James|talk]] · [[Special:Contributions/Doc James|contribs]] · [[Special:EmailUser/Doc James|email]]) 10:10, 24 December 2019 (UTC)
** I saw an instance of that recently. It was the ''Journal of Pakistan Nutrition'', which is now hosted by the less-than-stellar academic publishing house SciAlert. It was cited to support some numbers (e.g., the amount of [[carotenoid]]s present in a colorful oil that is mostly used in the cosmetics industry). Those numbers are now uncited, as if some editor just made them up. This breaks the [[Wikipedia:Text-source integrity]] and makes the article worse. But apparently their fear of being seen citing a mediocre academic journal is bigger than their fear of having uncited material in articles. I'd feel a lot more respect for the removal if the editors who want to remove mediocre journals made any significant effort to replace the sources with ones they approve of, rather than leaving the rest of us with a bunch of unsourced text and no idea where it originated from. (Hope we don't accidentally cite the same source that was just removed, because they're not leaving future editors any information about what they've deemed unacceptable.) [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 06:00, 2 January 2020 (UTC)


==== Discussion on Proposal 1 ====
==== Discussion on Proposal 1 ====

Revision as of 06:00, 2 January 2020

 Policy Technical Proposals Idea lab WMF Miscellaneous 

New proposals are discussed here. Before submitting:


RfC: Appropriate notifications

WP:CANVASS should list some notifications as best practice to send, as well as its current 'An editor who may wish to draw a wider audience...' for the appropriate notifications it lists. Dmcq (talk) 01:53, 27 November 2019 (UTC)[reply]

Changed to definitive RfC and reworded slightly. The main impetus is to help support what WP:Consensus#Pitfalls and errors says. The discussion above #Discussions about articles on Noticeboards should leave a note on the relevant talk page shows I think there are real problems which might "generate suspicion and mistrust". Dmcq (talk) 17:25, 26 November 2019 (UTC)[reply]

Notifying users when there is a discussion about them has become obvious best practice but I don't know where or if that is written down anywhere, Also putting a note in a discussion when a question is put to a noticeboard has become fairly standard practice and is required on some noticeboards. I think WP:CANVASS is the right place for such notifications as not informing obviously interested and easily contacted parties can be considered as biasing a discussion.

I propose to add the following to WP:CANVASS#Appropriate notification to document notifications which should normally be done:

At the beginning put:

It is best practice to have a message left about a discussion at:

  • The talk page of a user mentioned if there is a behavior concern.
  • The talk page of one or more named aricles which might be affected.
  • A relevant project page, noticeboard or other Wikipedia page if it might affect their remit.
  • Another discussion if it follows closely from the other discussion.

Neutral notifications are not counted as discussions nor are straightforward questions which don't extend further.

This would be followed by the current text

An editor who may wish to draw a wider range of informed, but uninvolved, editors to a discussion can place a message at any of the following: ... Dmcq (talk) 12:42, 22 November 2019 (UTC)[reply]

Regarding the requirement to notify users; there's a big box at the top of pages like WP:ANI that states, and I quote, "When you start a discussion about an editor, you must leave a notice on the editor's talk page." It's in red. The word "must" is underlined. Short of broadcasting the requirement directly into people's brains using the secret government chip we've all been implanted with, I'm not sure what else should be done to let people know of such a requirement. --Jayron32 16:13, 22 November 2019 (UTC)[reply]
I know about that box - was putting that box there based on a policy or guideline? If so I think the business here about articles and other transparency should probably go in the same place. Dmcq (talk) 19:15, 22 November 2019 (UTC)[reply]
It was based upon being a thing we should always do.--Jayron32 04:21, 27 November 2019 (UTC)[reply]
Would't it be wonderful (or dull!) if we all agreed on things that we should always do! Dmcq (talk) 11:32, 27 November 2019 (UTC)[reply]
  • !votes from discussions As far as I can see there is myself, @Blueboar, Nil Einne, and Jayron32: supporting, and @Alexbrn, Guy Macon, jps, and Agricolae: opposing in the discussion above. I'd like a few more contributing to get a wide consensus so I'm making this an RfC. Are you in favor of being able to have a quiet discussion about changing an article free from the drama of having editors from an article being discussed, or do you think it is good practice to involved them in all such discussions to avoid canvassing type problems? Dmcq (talk) 01:24, 27 November 2019 (UTC)[reply]
FYI - my “support” is marginal, at best, and hedged with caveats... I don’t object to adding a brief note in policy encouraging editors to leave notifications... but would oppose any language that would imply that doing so is required. Blueboar (talk) 15:15, 30 November 2019 (UTC)[reply]
  • Or to state it in an equally 'neutral' manner, would you insist that discussion to change a page be intentionally diverted away from the Talk page so that it metastasizes to anywhere else on Wikipedia that the page has been mentioned, or would you prefer discussion remain focused on the Talk page of the article it concerns. Or, and here is a novel thought - we actually state it neutrally rather than only pretending to: Do you think that notification on a Talk page when that article page is being discussed in other fora be made preferred practice, or do you oppose making that policy? That is neutrally stating the question. Agricolae (talk) 02:23, 27 November 2019 (UTC)[reply]
    Discssions about improving articles do occur on noticeboards, and often for very good reason. As far as I can make out you want to deprecate the current practice of leaving a note on an article talk page and only leave one if editors at a discussion think there is a good reason to invite editors of an article. I think it would be better you raise a proposal to that effect rather than just implementing it personally as what you say is not common practice on most noticeboards. That would give you a good opportunity too to show why there would be no consensus or canvassing issues with what you say. Dmcq (talk) 11:12, 27 November 2019 (UTC)[reply]
    And as far as I can make out, you are utterly incapable of neutrally summarizing the position of anyone with whom you disagree. It is just one absurd strawman after another. The only question that remains is whether you aren't even trying, or if you are trying hard not to. Agricolae (talk) 15:28, 27 November 2019 (UTC)[reply]
    Well lets see if some more more editors can come along and give their opinion on the matter. Dmcq (talk) 15:41, 27 November 2019 (UTC)[reply]
  • PLEASE - comment on the proposal, not other editors. Blueboar (talk) 15:43, 27 November 2019 (UTC)[reply]

Oppose, generally on WP:CREEP and WP:COMMONSENSE and WP:NOT#BUREAUCRACY grounds. Whether something is canvassing or not has at least as much to do with exact wording and with personal rationale for exactly which pages were picked/excluded, as it has to do with which pages actually were notified. Furthermore, I strenuously object to the wikiproject-related language in here. Wikiprojects have no "remit". They are not stand-alone organizations, they do not have any authority, they are not walled gardens. They are simply pages at which editors with common interests assemble some resources; the primary purpose of wikiprojects is article assessment and peer review. The abuse of them as "canvassing farms" – places to gin up support for (or opposition to) this proposal or that among editors that one hopes will be like-minded has already gone too far for too long. The idea of enshrining this anti-WP:CONSENSUS lobbying and wikipolitical activism as something explicitly sanctioned by policy is not going to fly. Sometimes it is useful to notify a wikiproject's talk page of a discussion that seems like it's within the declared scope of the project, and this is generally when expert or at least topically knowledgable input is needed. And sometimes wikiprojects on "side B" of an issue need to be notified if someone has been lobbying projects on "side A" already, to ensure that a WP:FALSECONSENSUS doesn't result. But broadly and generally, no. If we really notified wikiprojects of every relevant discussion, every wikiproject's talk page would be a firehose of nothing but thread pointers, few of them ever neutral. WP:WATCHLISTs exist for a reason. WP:RFCs and the WP:FRS exist for a reason. When it comes to important matters that will affect many articles, WP:VPPOL (or WP:VPPRO, depending on the nature of the discussion) and WP:CENT exist for a reason. Aside from the wikiprojects stuff: There is no need to codify "canvassing exceptions" for notice to the talk pages of clearly affected users or articles; that's standard practice and we already know it is not canvassing. Nor do we need to mention noticeboards. Noticeboards are not internal-discussion "link farms"; they are for dispute resolution between small subsets of editors. So, most discussions should never be "advertised" at them. And "Another discussion if it follows closely from the other discussion"? That's backwards. If, say, an RfC opened last week leads to a new discussion this week, the new discussion does not need to be notified of the old one. And if the old one is actually old, it needs no notice of the new one, though people are free to make one. If it's not really old, then the new discussion should probably be closed and redirected back to the original, unresolved one, per WP:MULTI and WP:TALKFORK.  — SMcCandlish ¢ 😼  20:05, 27 November 2019 (UTC)[reply]

I quite explicitly said it was not about notifying about every mention, only discussions about changing named pages. And I haven't the foggiest how informing editors who watch a page about discussions which may result in changes to it can be counted as canvassing! The notifications mentioned are the commonsense ones! The bureaucracy is needed because as you say and I believe some places have become anti-consensus lobby groups and don't do them. The effect of this RfC would be to say to them that if they start discussing changing a page they should put a notification on the associated talk page. No it won't get rid of the lobby groups - but it will expose them to some light. They probably were set up for a good reason originally and still do some good - exposure to outsiders would help reduce the groupthink that infests such places and led to them becoming anti-consensus lobby groups. Dmcq (talk) 20:57, 27 November 2019 (UTC)[reply]
The business about direct follow-on discussions is to help deal with forum shopping. At the moment we can complain about forum shopping - but editors who have just yesterday discussed the business should be notified if the discussion then moves elsewhere. Complaining that something is forum shopping is not enough to tell interested editors what is happening. Dmcq (talk) 21:16, 27 November 2019 (UTC)[reply]
BTW this would not affect boards where just a neutral notification is placed like the various RfC or AfD lists. They might be used to canvass editors but the problem of forming like-minded in-groups is far less when there is no discussion on the board. Dmcq (talk) 21:59, 27 November 2019 (UTC)[reply]
  • Oppose. I agree with SMcCandlish that it just is not needed, per WP:CREEP and the like. The existing guidance about canvassing is sufficient to delineate the difference between canvassing and appropriate notification, and that's what we need. We don't need to put unavoidably incomplete lists of examples on top of it, and there are always going to be cases where it will come down to common sense. Users who cannot figure it out probably shouldn't be here. By the way, I came to this RfC from the message at WT:CANVASS, which I think was a reasonable way to notify interested editors. --Tryptofish (talk) 23:59, 27 November 2019 (UTC)[reply]
Well I can see this RfC is starting to lose. So you came here via a short notice at WP:CANVASS which is the talk page of the page for which a change is proposed. That is exactly what this proposal describes as best practice and you say is a reasonable way to notify interested readers. There are noticeboards which engage in dscussions like this and where they quite adamantly refuse to give such a notice as standard and in fact hardly ever do. And we have discussions on this page about boards having such discussions and the effects being described as bad. But you say trying to do something which migh ameliorate the effect is creep? That what they do is fine by you? That you would have been quite happy if no note like that had been placed in WT:CANVASS and the same for for other pages you are interested in? Is CREEP really a good and sufficient reason for not trying to fix such boards instead of editors just uselessly complaining at them without any clear backup in a policy or guideline? Dmcq (talk) 09:49, 28 November 2019 (UTC)[reply]
I'd have to see evidence that such possible misunderstandings of appropriate notifications are a genuine and pervasive problem, as opposed to clueless comments or comments made in bad faith that are readily dismissed. For example, are editors getting blocked for making appropriate notifications? --Tryptofish (talk) 21:52, 29 November 2019 (UTC)[reply]
I know your noticeboard has to deal with a lot of crap, and that's probably why you and a few others from there are opposing this proposal, in fact I see only one who isn't from there. But so do lots of other places dealing with China or Israel or Donald Trump or lots of other subjects. But your lot have gone rogue, the guideline is fine but they go far beyond it and seem to think Wikipedia should only have true things rather than being an encyclopeaedia of notable topics. I believe if they followed the norms in the rest of Wikipedia it would curb the in-group mentality characterized by talk of being adults and not having the children disrupt your conversations and having jokes disparaging the topics and the actions of going off as large group to tidy up or delete topics and practically ignoring the editors there and listing lots of policies against them without saying in what way they actually violate a policy or guideline. Saying creep is just a way of dismissing any idea of reforming the noticeboard and denying the problem. Dmcq (talk) 13:08, 30 November 2019 (UTC)[reply]
Here's the thing. No actual evidence of any problem has been presented, just vague grumbling which seemed rooted in upset about the consensus at this AfD. Alexbrn (talk) 13:23, 30 November 2019 (UTC)[reply]
I don't expect you to disagree with all the other people who came along with you to that or see a problem with what you do there or elsewhere. I am pointing out what you do and WP:CONSENSUS says about off-wiki conversations " Consensus is reached through on-wiki discussion or by editing. Discussions elsewhere are not taken into account. In some cases, such off-wiki communication may generate suspicion and mistrust." I consider it wiki-lawyering to say that what is done at that noticeboard is fine and dandy because it is on-wiki even if the people there are very opposed to putting a notice onto an article's talk page about a discussion about changing an article the editors there are working on. Dmcq (talk) 13:47, 30 November 2019 (UTC)[reply]
Discussion on a community noticeboard is not (and is not like) "off-wiki communication". Still no evidence of a problem has been presented. Evidence would take the form of specifying an instance where something problematic happened, with some supporting diffs. Alexbrn (talk) 13:53, 30 November 2019 (UTC)[reply]
And you don't thingk the next point in WP:CONSENSUS is applicable either "Any effort to gather participants to a community discussion that has the effect of biasing that discussion is unacceptable. While it is fine—even encouraged—to invite people into a discussion to obtain new insights and arguments, it is not acceptable to invite only people favorable to a particular point of view, or to invite people in a way that will prejudice their opinions on the matter"? Dmcq (talk) 14:45, 30 November 2019 (UTC)[reply]
Dmcq, WP:CONSENSUS is correct. But (for about the sixth time) there is no evidence of any problem to fix. Getting noticeboard attention is a really excellent way to improve and broaden consensus and benefit from the editors' wisdom on offer there. I am beginning to suspect the reason you are not providing evidence of a problem having occurred, is because there is no such evidence. Alexbrn (talk) 14:57, 30 November 2019 (UTC)[reply]
So you'd be happy if you were working on an article and then a bunch of people descened on it with fixed ideas because they'd been discussing it elsewhere without you having any straightforward way of finding out about it or contributing? You think that is perfectly okay? Dmcq (talk) 17:32, 30 November 2019 (UTC)[reply]
In the hypothetical case I'm being fooled into citing a shit source, I would be very happy to be told I was using shit sources. This way I could take corrective action and write based on reliable sources. Headbomb {t · c · p · b} 22:48, 24 December 2019 (UTC)[reply]
Dmcq, Has this ever happened? You have produced no evidence whatsoever. It would seem incredibly arrogant to claim to see into editors' minds and know that had a "fixed opinion" of any kind. Alexbrn (talk) 17:42, 30 November 2019 (UTC)[reply]
Now you're wanting me to raise this to ANI to prove a case before you'll acknowledge a problem. Editors from articles are kept away because the noticeboard does not want their input. How can anybody expect the editors from the noticeboard to then go along and have their minds changed by these editors at an article? Dmcq (talk) 17:49, 30 November 2019 (UTC)[reply]
I'm not asking you to prove a case but to provide evidence. You've not done that: no diffs, nothing. Alexbrn (talk) 19:48, 2 December 2019 (UTC)[reply]
Another couple of editors from that noticeboard opposing editors from articles being in their discussions. I raised this here and deliberately did not mention it to see what the wider opinion in Wikipedia is but a bunch of you come along and stack it with opposes. Dmcq (talk) 17:49, 30 November 2019 (UTC)[reply]
  • Oppose This sounds like one of those things which seems reasonable in broad strokes but upon closer inspection becomes a bureaucratic exercise in rule proliferation. (This !vote might get me labeled as a running dog of The Noticeboard, because I read and comment there occasionally, but I noticed this discussion because I was checking the Village Pump in order to procrastinate on the day's work.) XOR'easter (talk) 16:36, 2 December 2019 (UTC)[reply]
@XOR'easter: Why do you think this is just a bureaucratic exercise? What do you see as going wrong with it? Do you disagree with me when I see a definite consensus and groupthink problem when people talk about not having people from an article along so the adults can discuss it, and then go along as a group to change it? Or do you think that is okay in this case? Dmcq (talk) 21:32, 2 December 2019 (UTC)[reply]
Because you've been pushing this line in multiple venues for literally years with no traction - David Gerard (talk) 23:25, 2 December 2019 (UTC)[reply]
I did push for something to be done about ten years ago when the noticeboard make a complete messof another article and not since. By your reasoining no AfD's should be done for ten years after the last one failed. I notice the article has recovered from the attentions of the noticeboard but they still try and do stupid things there which go far beyond the guidelines and try and make Wikipedia only have truth not notable things. Dmcq (talk) 12:08, 3 December 2019 (UTC)[reply]
Do you disagree with me when I see a definite consensus and groupthink problem ... um, I suppose I do, because I find no solid evidence of an actual groupthink problem, just an assertion that one exists. (I am doubtless influenced on this point by the fact that a lot of my interactions on The Noticeboard have been me disagreeing with other editors there.) XOR'easter (talk) 00:12, 3 December 2019 (UTC)[reply]
If you see no problem with discussing changing articles without letting the regular editors know about it and then going along with the people you discussed it with to edit the article? And despite that you think you are open to consensus on the artcle discussing it with theose editors? You really think that follows the policies outlines in WP:5P4 "Wikipedia's editors should treat each other with respect and civility"? Dmcq (talk) 12:23, 3 December 2019 (UTC)[reply]
In order to see a problem, I have to see a problem. Sweeping generalities without evidence don't cut it. XOR'easter (talk) 15:13, 3 December 2019 (UTC)[reply]
It would be really nice if somebody actually gave a good reason rather than 'creep' for not documenting something that is done pretty much as standard everywhere else. Or pointed at something they thought wasn't standard or should be phrased differently. Dmcq (talk) 12:08, 3 December 2019 (UTC)[reply]
I know that your proposal is a good-faith one, and I know from experience how disappointing it can be to have one's proposal regarded negatively by other editors. Of course, it's nothing personal. But I honestly think that editors have given substantive reasons beyond "creep", and it doesn't help your case to badger everyone who responds to the RfC. --Tryptofish (talk) 22:38, 4 December 2019 (UTC)[reply]
@David Gerard:, you are one of the few editors in a while at that noticeboard I've noticed who've left a notification at an artice talk page. Why do you do this thing that you oppose having documented as good practice? Dmcq (talk) 00:06, 4 December 2019 (UTC)[reply]

Well I can see this is not going anywhere. I'm sorry about that. I'll continue using WIkipedia sometimes as it is useful but it is no longer something I can identify with or cotribute to so bye folks. Dmcq (talk) 14:59, 14 December 2019 (UTC)[reply]

On the use of deprecated sources

There has been a long-brewing war over what to do with deprecated sources at Wikipedia. Several ANI threads have been spent, lots of accusations of bad-faith have been leveled at both sides of the dispute, and it's clear we need some clarification on how to handle the situation in general. I'd like to have a clean discussion on what to do going forward on these matters. I definitely do not think we need to have any discussion here on what has happened earlier, on individual user behavior, and on personal attacks, which is where most of these discussions have gone. I'd like to set this up as a "proposal and support/oppose" format. Users should feel free to add their own proposals to the list if they are significantly different than other proposals, and we can use the proposals with the most support as guidance for clarifying Wikipedia policy on these matters. I'll get the ball rolling with a proposal of my own, with no prejudice against others creating their own proposals.

(Proposed by User:Jayron32 on 26 November 2019.)

For info on what sources are deprecated and how they become that way, see Wikipedia:Deprecated sources -- Beland (talk) 16:22, 6 December 2019 (UTC)[reply]

Proposal 1: Deprecated sources should be handled as follows

Text which is cited to deprecated sources should be not usually be treated differently than unsourced text. What that means for how to deal with them is as follows:

  • No distinction is made in policy between adding a source new or keeping an existing source. For the purpose of policy, adding a source which is deprecated is treated exactly the same as keeping an existing source after it is deprecated, and WP:BURDEN applies equally in both cases. No person may be required to provide a source in the place of deprecated source; if a person wishes a new source to be added, it is the burden of that person to provide their own source.
  • Deprecated sources can be removed, with an edit summary "removing deprecated source".
  • If a deprecated source is to be used or kept, as an exception (either IAR or because a specific exception is noted in the relevant discussion that deprecated the source), then WP:BURDEN applies to the person who wants to use or keep the deprecated source, and they should start a talk page discussion explaining their desire for the exception. Consensus is required to use or retain the deprecated source, for the specific use, and if the addition or retention of the deprecated source is contested, it is to be removed unless and until consensus explicitly allows for its use.
  • Any text that is only sourced to a deprecated source is treated as though it had no source to begin with.
  • Removal of deprecated sources should not be done with fully automated tools/bots.
  • The person who finds a deprecated source being used in the article has several options for how to deal with the text that was cited to the source. No preference is given to ANY of these options, and no accusations of misbehavior or bad faith should be leveled against anyone who does any of the following responses.
    1. Remove the source and leave the text. The information that was formerly cited to a deprecated source just does not have that source anymore; the rest of the text is left unchanged.
    2. Tag the deprecated source with the {{better source}} tag and leave it in the article.
    3. Replace the deprecated source with a better source.
    4. Remove the deprecated source and add a {{cn}} tag.
    5. Remove the deprecated source along with the text it is citing.
  • The guidance for when to tag, and when to remove text, is already given in existing policy, and text which has a deprecated source is treated no differently from any uncited text otherwise, that includes policies and guidelines such as WP:V, WP:CITE, WP:BLP, WP:BURDEN and the like.
  • The fact that an editor has taken any one of the above actions does not preclude later editors from taking other ones; for example if one editor removes a bit of text along with the source, another editor may add it back with an appropriate source. Or, for example, if one editor tags the deprecated source with the {{better source}} tag, another editor may remove it entirely. Normal proscriptions against edit warring exist for disputes over removal/retention. WP:BRD should be used, and when there is a dispute, the disputed text and source are to remain removed unless consensus exists to return it, just as with any disputed text that has no source.

Support/oppose on Proposal 1

  • Support as proposer. --Jayron32 19:30, 26 November 2019 (UTC)[reply]
  • Support with changeOppose I believe proposal 3 is much more in line with what I'd like. If a deprecated source is found to be reliable for a particular citation there should be a way of marking it as such - e.g. to link to a talk page discussion where there was a consensus saying it was okay for the purpose. This is to stop people just removing things that others think are fine. Dmcq (talk) 19:39, 26 November 2019 (UTC)[reply]
  • Support I can add nothing really to the OP.Slatersteven (talk) 19:40, 26 November 2019 (UTC)[reply]
  • Support proposal 1 - David Gerard (talk) 19:41, 26 November 2019 (UTC)[reply]
  • Opposed - there is no such thing as a “non-source”... just limits to a source’s use. While deprecated sources are GENERALLY not reliable, there are SPECIFIC circumstances where they are. As an example, the RFC that deprecated the Daily Mail noted that it was reliable in the past, and so historical usage might be an exception. Hell, even Mein Kamph is reliable in very limited situations. If nothing else, deprecated sources are reliable for direct quotes taken from the source (ie when used as a primary source). Blueboar (talk) 20:35, 26 November 2019 (UTC)[reply]
  • Support, but should be summarized more effectively.
Unless special circumstances applies (such as WP:ABOUTSELF), a statement backed by a deprecated source should be treated as no different than a statement backed with no source.
Headbomb {t · c · p · b} 21:31, 26 November 2019 (UTC)[reply]
  • Tentative support - I think this proposal is thorough, well-written, and well thought out. The only reason I hesitate to fully embrace it is because there are some scenarios where a 'bad' source might be acceptable. For example, there is some debate about whether a Daily Mail article is valid as a source for a topic closely related to the Daily Mail (e.g. "XXX is the new chief editor of the DM"). Michepman (talk) 01:51, 27 November 2019 (UTC)[reply]
  • Support if and only if editors who find untagged text cited to deprecated sources are not allowed to remove the source or the text themselves solely on the ground that the source is deprecated (1 or 5 in the list above). No objections to 2, 3 or 4 on the list as these either improve the encyclopedia, or give other editors the chance to improve the encyclopedia before removal. Text cited to deprecated sources is NOT unsourced and shouldn't be treated as such. IffyChat -- 18:53, 27 November 2019 (UTC)[reply]
  • Oppose - (5) is, in my opinion, just leaves the current problem present so we still end up with the same edit wars as we have been seeing on this subject. I think we need a solution that gives a strong preference to content staying on Wikipedia at least for a time when the only problem with it is a previously non-deprecated source becoming deprecated. I do not like givining editors authority to do mass deletions of content (which is the current modus operandi of some editors) that other users have taken time to craft when the content was not originally problematic. (1) is _effectively_ the same as (5) since an editor can simply remove the citation, then come back a day or two later and remove the content for having no citation. For the same reason as I dislike (5), I dislike (1). We should not be deleting content without strong reasons, and using a previously fine source that has since been deprecated is not a legitimate reason for summary deletion of content. I have created Proposal 3 to try to address these issues. — Preceding unsigned comment added by MicahZoltu (talkcontribs) 08:12, 28 November 2019 (UTC)[reply]
  • Support, although I feel automated removal should be allowed when there's a clear pre-existing consensus for it. This is in-line with the current meaning of depreciation and would fit our normal editing procedures. Individual removals can be tweaked by people who are watching the article (eg. by replacing the content using a better source, if it was removed); if there are not enough people watching the article who care, it is better to err on the side of caution and stick with removal of content with an unreliable source anyway, since articles without many people watching them can become dumping-grounds for nonsense if we're not careful. --Aquillion (talk) 14:07, 28 November 2019 (UTC)[reply]
  • Oppose of no benefit to the readers of the encyclopedia, in many cases useful material is being completely lost or incorrectly modified during mass rapid edit sprees. The Rambling Man (Staying alive since 2005!) 15:17, 28 November 2019 (UTC)[reply]
  • Oppose This gist of this seems to be that statements supported by deprecated sources are worse than having no source at all. Maybe true sometimes, but I suspect that if I were to make a large number of edits removing uncited material I would be quickly told to slow down, use some judgement, and engage on the talk page despite WP:BURDEN. Also, the best place to determine if use of a deprecated source is appropriate is on the talk page, knowing and having the option to change the cited material, not a generalized RFC.—eric 19:44, 28 November 2019 (UTC)[reply]
  • Support. I would suggest three changes, however:
  1. Introduction of a new tag: {{deprecated kept}}, where the rationale for keeping a deprecated source can be documented.
  2. Allowing for a source to be kept without TP discussion if an editor reviewed it, tagged it and provided a Policy-based justification within the tag for keeping it.
  3. Guiding editors toward deletion + tagging instead of just deletion, and towards {{deprecated inline}} instead of {{cn}}. François Robere (talk) 20:17, 29 November 2019 (UTC)[reply]
  • Support in general. Obviously there should never be any bar to simply replacing a poor source with a better one, whether or not the poorer source is deprecated. Even if this has consensus it would not change my current practice of tagging rather than removing in the first instance if the content is probably encyclopaedic and unlikely to be controversial. It would allow for bot removal at some later date, which is an interesting idea. Guy (help!) 01:03, 30 November 2019 (UTC)[reply]
  • Strong oppose number 1 and 4 are dumb ideas. They are almost never going to make an article any better but will instead make it worse, making it harder to find an actual source. I have no objections to 2, 3 and 5, although of course we need to take consider carefully how their interact with our other norms on challenging uncited content including mass removals etc. I'm also unsure why this proposal doesn't consider the use of templates like {{deprecated inline}} or even new tags to better emphasise it's a better source. As I've remarked before, if editors are really that worried about readers being confused even by tagging, we could always remove the link, or completely hide the source to readers without messing around with editors by making it difficult for them to fix an article, for no apparent reason. Whatever the case, it would be better if this doesn't pass if it's going to suggest 1 and 4 is okay when they're clearly not, and have never been supported by any policy or guideline, or simple common sense. Nil Einne (talk) 16:47, 30 November 2019 (UTC)[reply]
  • Oppose Because it is unclear, in particular it doesn't account for timescales. "Deprecated sources can be removed, with an edit summary "removing deprecated source". could be interpreted in two distinct ways (at least): either "Careful consideration of the source and the article is made by an editor, doing some editing. If nothing better can be achieved (which then raises the question of why we'd keep content which is not merely unsourced, but unsourceable.) then remove it. Maybe remove the content too. But this proposal, and that statement can also be interpreted as "Run a 'bot across the whole corpus, and just strip the lot immediately. (With WP:MEATBOT if there's a proscription against literal automation.) Because one editor thinks they don't like a particular domain name, or the string /blog/ in a URL. That's unacceptable. Andy Dingley (talk) 20:40, 30 November 2019 (UTC)[reply]
  • Support in principle, but I would rearrange the five recommendations in order of preference, ie 3,5,2,4,1. Reyk YO! 06:57, 2 December 2019 (UTC)[reply]
  • Oppose The concept of deprecated sources is fundamentally flawed because our citation of sources is context-dependent and so each case has to be judged on its merits. Also, it is our general policy that Wikipedia is itself not reliable and so a straw poll cannot be relied upon to determine the validity of sources in a broad-brush way. See also WP:NOTLAW. Andrew🐉(talk) 08:58, 4 December 2019 (UTC)[reply]
  • Support, mostly. In general, deprecated sources should be removed immediately, on sight. I'm not sure whether it's better to leave the unsourced text or not. I would support some sort of automated removal, with a proper scope and protections in place. Levivich 03:12, 5 December 2019 (UTC)[reply]
  • Support -ish? Only insofar as this is kind of a do-nothing proposal (in a good way), in that it hews pretty close to WP:Editing policy. WP:FIXTHEPROBLEM and WP:CANTFIX sum up what to do and not do in more or less the same way as this proposal, just without so many words. The verifiability policy is at the root of it: "Whether and how quickly material should be initially removed for not having an inline citation to a reliable source depends on the material and the overall state of the article" via WP:UNSOURCED. Barring BLP violations, copyright violation, or other urgent problems requiring action, we need to think about the fact that we're building an encyclopedia, and that's why we have the editing policy. It says to make forward progress we have to keep salvageable content and give it time to be improved by someone after you. We can't establish any rule more specific than "context matters" because unsourced material on a hot topic with hundreds of editors, like Impeachment inquiry against Donald Trump, could have a half-life of minutes, deleting unsourced material after one quick search. Problematic parts of an article on an obscure, slow-developing topic in the distant past or in a fictional universe could wait years for each tick of the editing clock to advance. If you're interpreting this proposal in a way that contradicts editing policy, the no, no support for that from me. Follow editing policy; it's a good policy that has stood the test of time because it is robust and flexible. --Dennis Bratland (talk) 17:29, 6 December 2019 (UTC)[reply]
  • Support. Everything in this proposal is already covered by existing policy, since deprecated sources are questionable sources that have been identified through an RfC on the reliable sources noticeboard. Of course, WP:ABOUTSELF and WP:CONTEXTMATTERS apply to deprecated sources as well as any other source. Aside from rare and unusual cases, the 5 listed responses are what editors commonly use for any unreliable source, and deprecated sources are no exception. I agree with Reyk's order of preference for the responses, from highest to lowest: #3, #5, #2, #4, then #1. However, if the affected content is fully supported by at least one reliable source, then #1 is the preferred option. I've described the process that I personally use for removing citations of unreliable sources at Wikipedia talk:Reliable sources/Archive 61 § Removal of sources. — Newslinger talk 01:55, 7 December 2019 (UTC)[reply]
  • Support, the proposal is spot on and covers all possibilities. The deprecated sources need to be removed, but whether to retain or delete the associated text depends on what reliable sources say about the text cited, and is a matter of editor consensus already covered by policy. It is rare to find reliable sources that back text typically cited to deprecated sources, and the BURDEN should be on the editor wanting to retain the text to produce a reliable source. SandyGeorgia (Talk) 16:20, 14 December 2019 (UTC)[reply]
  • Oppose. I tend to agree with Andrew Davidson's opinion above about the concept of deprecated sources being flawed. A nutty incident I came across was a source being removed on the grounds that it was deprecated, when its author was the topic of the article. I have also seen sources with embedded videos allowing television news broadcasts to be viewed being similarly deleted.     ←   ZScarpia   02:29, 24 December 2019 (UTC)[reply]
  • Support. As is usual for these discussions, comments along the lines of "sometimes a deprecated source should be used" are already accounted for because deprecation does not prevent a source from being used, as described in detail at WP:DEPS. In fact, this proposal specifically (re)states that use of a deprecated source is permitted whenever consensus supports it. It may also be useful to reiterate, in response to objections based on disagreement with deprecation as a general concept, that the practice has been repeatedly endorsed by consensus across multiple discussions.
I also think it’s important to note that even if the outcome here is inconclusive, it's likely that much of it would be supported by consensus regardless (e.g. some of the opposing arguments are focused on objections to specific points rather than the proposal as a whole). I would especially point out the implications of the apparent consensus against proposal 3 below: given the rationales, there appears to be consensus against any restriction that makes removing deprecated sources more difficult than removing any other source (or, as some have put it, giving them "protection"), which is a key point because of its relation to the issue that originally led to this discussion being opened. Sunrise (talk) 05:12, 24 December 2019 (UTC)[reply]
If it weren't for the fact that Wikipedia:Nobody reads the directions, and that people on a righteous mission don't always slow down to consider details, like whether a specific deprecated source should be used, I might agree with you. What do you say to User:ZScarpia's example? Just someone not following the directions, so nothing to worry about? WhatamIdoing (talk) 06:00, 2 January 2020 (UTC)[reply]
  • Support We have people removing predatory journal articles from WP and replacing them with {{CN}} tags. These predatory journals are generally still more reliable than what we are discussing removing here. We of course want to allow a small number of exceptions such as we do for withdrawn journal articles like Wakefield's paper when we are discussing said paper. Doc James (talk · contribs · email) 10:10, 24 December 2019 (UTC)[reply]
    • I saw an instance of that recently. It was the Journal of Pakistan Nutrition, which is now hosted by the less-than-stellar academic publishing house SciAlert. It was cited to support some numbers (e.g., the amount of carotenoids present in a colorful oil that is mostly used in the cosmetics industry). Those numbers are now uncited, as if some editor just made them up. This breaks the Wikipedia:Text-source integrity and makes the article worse. But apparently their fear of being seen citing a mediocre academic journal is bigger than their fear of having uncited material in articles. I'd feel a lot more respect for the removal if the editors who want to remove mediocre journals made any significant effort to replace the sources with ones they approve of, rather than leaving the rest of us with a bunch of unsourced text and no idea where it originated from. (Hope we don't accidentally cite the same source that was just removed, because they're not leaving future editors any information about what they've deemed unacceptable.) WhatamIdoing (talk) 06:00, 2 January 2020 (UTC)[reply]

Discussion on Proposal 1

  • I suggest the discussion should happen at the WP:RSN - we've already seen editors declare that WP:LOCALCONSENSUS on a talk page means they can keep a deprecated source, and then it goes to the RSN and their sourcing is rapidly shown to be terrible, e.g. this discussion. To overcome a broad general consensus achieved at RFC, we need an equivalently general countervailing level of consensus - e.g., four people on a talk page shouldn't be able to override two RFCs deprecating the Daily Mail. But that's a minor modification, and broadly it's a good proposal - David Gerard (talk) 19:44, 26 November 2019 (UTC)[reply]
I left a notice at WP:RSN for the discussion to happen here. I wanted to have it here to specifically avoid issues with "local consensus" matters; this is a page with a broader reach than RSN, and is better as a "neutral ground" where the discussion would not be colored or influenced by existing discussions at RSN. That is why I considered this venue the best option. --Jayron32 19:49, 26 November 2019 (UTC)[reply]
Oh, you mean the discussion on the deprecated source usage specifically; I think the article talk page is the best place to house it because it should be in close proximity to where the source is being used; that way people who are unaware of the discussion can find it easier. I would not be averse to leaving a notice at WP:RSN pointing to the discussion, but a specific usage of a specific source SHOULD be discussed on the article talk page (different from the use of a source in general) RSN should be used for notifications rather than for discussions in those instances. --Jayron32 19:51, 26 November 2019 (UTC)[reply]
Talk page discussion, with notification to RSN, works for me 100%. And yes, this is the very best place for broad general consensus on this issue - David Gerard (talk) 19:54, 26 November 2019 (UTC)[reply]
  • Blueboar's objection seems covered by the provisions to allow deprecated sources by consensus - David Gerard (talk) 20:41, 26 November 2019 (UTC)[reply]
  • @Blueboar:: (edit conflict) I believe you may have missed some of the text in the proposal; your specific objection to it has already been addressed in the bullet point that begins with the text "If a deprecated sources is to be used or kept..." The proposal already assumes that even deprecated sources will have appropriate uses, and allows for such use. Can you please elaborate where you think that bullet point is lacking in addressing uses you may have in mind? --Jayron32 20:41, 26 November 2019 (UTC)[reply]
  • On the bot restriction - if this includes AWB, then the proposal would discriminate against editors with physical disabilities. e.g., for JzG, AWB is needed for an accessibility issue related to physical disability, per [1]: I use AWB, largely because the regex makes it vastly easier but also because I have C7 radiculopathy and it maximises the ability to work by keyboard rather than mouse. This strikes me as 100% a reason to use a given tool for editing - and, of course, an editor using AWB accepts all responsiblity for every click of the "save" button in any case - David Gerard (talk) 20:53, 26 November 2019 (UTC)[reply]
@David Gerard: AWB is generally considered a semi-automated tool. As long as you personally review and accept responsibility for every edit, and don't edit like a mindless 'save' machine, you're in the clear. WP:MEATBOT and WP:AWBRULES still applies, of course. Headbomb {t · c · p · b} 21:35, 26 November 2019 (UTC)[reply]
My only concern would not be for the use of tools such as AWB per se but on the writing of routines and bots for the blind removal of sources. If AWB is being used in a way that makes it clear the user is considering each usage, and responding accordingly, that's fine. If they are just blindly setting up a routine to mass remove all uses, that's a problem. It's the automated nature of removing sources without considering each use, and the use of tools to do it so rapidly that quality control cannot be checked, that is the issue. Otherwise, I would think there wouldn't be a problem. --Jayron32 21:00, 26 November 2019 (UTC)[reply]
  • I would tweak the "fully automated" bit to add "without prior consensus." There are cases where fully-automated removal might be required (especially in the case of spam or if a WP:COI editor was adding an unusable source they have a COI with everywhere or something of that nature), and I'm concerned that this could be used to argue that a consensus at eg. WP:RSN can't allow such edits based on the consensus for this proposal being broader and prohibiting it. --Aquillion (talk) 16:46, 27 November 2019 (UTC)[reply]
  • Suggestion - Jayron32, would it be within the scope of this proposal to add a section about how new deprecated sources should be agreed upon? (E.g. should it be here, at the Village Pump, or on an article talk?) The reason I ask is because I saw an issue on WP:ANI the other day where there was a debate about whether Mail on Sunday was deprecated as it is an offshoot of The Daily Mail Michepman (talk) 02:01, 27 November 2019 (UTC)[reply]
Would that be covered by the case-by-case exception mechanism, or are you after something broader? - David Gerard (talk) 08:42, 27 November 2019 (UTC)[reply]
  • Michepman, I think we already know how deprecation works (via RfC at RSN). It's legitimate to ask whether such discussions should also be advertised via CENT. I would not be opposed to that. The Sunday Mail is an edge case and not particularly informative in forming a wider consensus - I don't know of any other instances where two sources of differing reliability share the same website, though I am sure it happens. My view there would be a qualified exception for the print edition of the MoS, but that's just me. Guy (help!) 11:17, 6 December 2019 (UTC)[reply]
David Gerard, JzG - OK thanks for clarifying. I am comfortable with tbe current process and don't have any suggestions for changes on my end. In terms of the Daily Mail issue I wasnt sure how widespread of an issue it was but if you're confident that it's an edge case then I think we can leave it as is. Michepman (talk) 16:06, 6 December 2019 (UTC)[reply]
  • I'm a bit worried about fleshy bots going around deleting stuff based on this, I'd like to make certain editors at an article got a decent chance to do any work needed first. A bot could go around and put a note on the talk page and give some decent timeout for them to mark the use as okay or replace before open season was declared. Dmcq (talk) 11:50, 27 November 2019 (UTC)[reply]
  • Many deprecated sources are used on thousands or even tens of thousands of pages at the time of depreciation, partially because depreciation is an extreme step reserved for cases where a source that is clearly generally unreliable is being used constantly and widely in an unworkable manner. It is simply unreasonable to expect a discussion to occur before every single removal, or to give that sort of chance on so many pages when the usages are often obviously and clearly against the broader consensus - even a bot like you describe would often be tagging simply unworkable numbers of pages. And, after all, the nature of Wikipedia means that even if they go for completely removing the cited text, anyone watching the page can immediately restore it with a better source anyway. --Aquillion (talk) 16:40, 27 November 2019 (UTC)[reply]
I'm not certain what you're objecting to. Bots are quite good at going around the whole of Wikipedia marking things, surely it is a good idea for them to mark deprecated sources as deprecated? And if they can do that they can for instance put a time on and if that time is expired put a tag on showing no-one has attempted to fix the problem in a reasonable time? And then wikignomes can look around for those tags if they want to and do what they think is fit knowing that the normal editors haven't bothered to deal with the problem.. Dmcq (talk) 18:35, 27 November 2019 (UTC)[reply]
I'm also a bit worried about this opposition to "give that sort of chance on so many pages when the usages are often obviously and clearly against the broader consensus". I believe we should treat the editors of articles with more respect and this is very much against WP:5P4 "Wikipedia's editors should treat each other with respect and civility" and especially against 'Be open and welcoming to newcomers'. If there is a decent time interval like a month for holidays before the dogs are let loose then a large proportion will have the assurance that editors at the article have not shown enough love for the cite and it can be open season. I would support something like this for all dated article warnings. Dmcq (talk) 21:25, 27 November 2019 (UTC)[reply]
Think of it more as "we have 23,000 references that look like they're to a source readers can trust, but actually it's the Daily Mail." Keeping the little blue number when it's deceptive to the reader is bad. Taking out bad sources we literally can't trust does not in any way imply bad faith in the editor who put them there - but they're still bad sources that should be removed forthwith - there is no reason to deliberately leave a bad source in. There is especially no reason to make an assumption of WP:OWNership of the bad source, such that it has the privilege of staying in a month, when a merely "generally unreliable" source wouldn't get that privilege. Bad sourcing is as un-WP:OWNed and editable as any other edit covered in the edit notice - David Gerard (talk) 22:08, 27 November 2019 (UTC)[reply]
You can't automatically remove all the dependent text using a bot. But you can mark all the citations as deprecated. And that is far better than just removing the citation because it shows the status of the reason for the text. What I'm suggesting would cut down the work involved in checking the citations - the text may have another citation, and editor there may give a good reason why the citation is okay in that context, any number of things. What is the sense in trying to do all that oneself if editors on the articles can do it? And involving editors is a good thing, ignoring them is bad. Dmcq (talk) 23:11, 27 November 2019 (UTC)[reply]
Nothing I've said there implies using a bot, and nothing in your proposal implies using a bot - "fleshy bot" appears to be a term for removals you don't like - David Gerard (talk) 12:41, 28 November 2019 (UTC)[reply]
  • It should be clarified that the rule would only apply when the source has been disallowed for the specific usage in question. The word "deprecation" gets thrown around a lot as if it has some sort of meaning, but I'm unaware of any formal policy or guideline that defines the term; the exact restriction is written in the closing of each source's RfC and common practices are outlined at the Wikipedia:Deprecated sources information page. Usually the source will be disallowed for statements of fact but may be acceptable for attributed opinions and WP:ABOUTSELF. –dlthewave 13:11, 27 November 2019 (UTC)[reply]
    Dlthewave, yes, and where there is clear consensus to retain a source we could create a template called something like {{deprecated source exception}} to avoid any bot or semi-automated removal. Guy (help!) 11:23, 6 December 2019 (UTC)[reply]
  • Might I make a suggestion, if there is a concern about people not being given enough time. We only do this to source over (say) six months old, when there has been plenty of time to find a better source.Slatersteven (talk) 17:49, 27 November 2019 (UTC)[reply]
We still get a flood of incoming Daily Mail and Sun cites in new and recent articles. I would recommend against a requirement to keep these around for six months, rather than just removing them, pointing out that these sources are deprecated - David Gerard (talk) 18:37, 27 November 2019 (UTC)[reply]
Six months does seem too long to me, I'd say one month in case an interested editor is on holiday, and the cite should be marked as deprecated as soon as possible. However I think it very important to allow editors at an article time to fix problems themselves to encourage participation in Wikipedia rather than have editors with no interest except cleaning Wikipedia come along and blast at the article without anything more than a templated comment. It shows disrespect. Dmcq (talk) 21:35, 27 November 2019 (UTC)[reply]
It has the danger of being bitey, but I've found it works quite well if I link them to WP:RSP - so they know there's a reason. (Also, TV editors are delighted to find that Digital Spy has been considered actually quite a good source for TV stuff.) - David Gerard (talk) 22:02, 27 November 2019 (UTC)[reply]
  • I'm not sure why Remove the source and leave the text is on the list of possible, generally acceptable courses of action (and in the first position, at that). I would expect that in pretty much any circumstance, it would be better to replace a deprecated source with one of our famous {{cn}} tags than just to leave the text there. XOR'easter (talk) 22:33, 27 November 2019 (UTC)[reply]
    Removing a deprecated source while leaving the text intact is appropriate when there is at least one reliable source that fully supports the affected text. For example, if [1] were a deprecated source and [2] were a reliable source that supports the entire sentence, both The quick brown fox jumps over the lazy dog.[1][2] and The quick brown fox[1] jumps over the lazy dog.[2] would be reduced to The quick brown fox jumps over the lazy dog.[2] — Newslinger talk 00:36, 7 December 2019 (UTC)[reply]
  • I could probably be talked into supporting 1 - 4. 5 is a tough one for me though. — Ched (talk) 23:31, 27 November 2019 (UTC)[reply]
  • Support with revision - "Text which is cited to deprecated sources should be not usually be treated differently than unsourced text." should be, "Text which is cited to deprecated sources should be treated similarly to unsourced text." In which case I would support. EllenCT (talk) 10:30, 12 December 2019 (UTC)[reply]

Proposal 2 - create a “Deprecated sources review board”

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.


When an editor comes upon a deprecated source, and can not quickly find a better source to replace it... the editor can submit the source (and context) for review by the board. The board will review, discuss, and determine whether the source is used appropriately (given the context), or not. Review will last for a limited time (say one week... but I am flexible on this). And will recommend an appropriate action (remove the source, remove the source and material, etc.)

Please share your thoughts Blueboar (talk) 18:18, 27 November 2019 (UTC)[reply]

  • This seems entirely compatible with Proposal 1, as a place for removals that have been disputed to go. If you mean keeping the source in until a consensus is reached, this just creates a non-scaling bureaucratic blockage on removal of statements sourced solely to known-bad sources. Remember, we're talking about statements attributed solely to a source that we know we can't and don't trust - removal then review before putting back, per Proposal 1, seems obviously the correct treatment for claims with that little support - David Gerard (talk) 18:33, 27 November 2019 (UTC)[reply]
actually, yeah, oppose as redundant - this is called WP:RSN - David Gerard (talk) 17:13, 28 November 2019 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 3

  1. A bot automatically marks all deprecated sources as {{better source}} (with a note/timestamp in the template that this was a deprecation removal, so we can track it).
  2. 6 months after deprecation a bot updates all instances of {{better source}} to {{cn}} (with a note/timestamp in the template that this was a deprecation removal, so we can track it).
  3. 12 months after deprecation editors are free to remove content that is only supported by a {{cn}} with the appropriate tracking note in it. This can be done without discussion and with a an edit reason of "Unreliable Source" or "Deprecation Cleanup".
  4. During those 12 months, an editor may replace the source with a better source.
  5. During those 12 months, an editor may remove the content for normal editing reasons other than "Unreliable Sources" (e.g., if the content doesn't fit within the article, or the article is being rewritten in a way that doesn't include the content).
  6. During those 12 months, concensus on the talk page for the article can agree on removing the content.
  7. During those 12 months, concensus on the talk page for the article can agree to re-add the original source because WP:CONTEXTMATTERS.
  8. During those 12 months, reverts without discussion and only citing a reason of "Unreliable Source" would be treated as vandalism (same as deleting any other content without discussion or valid reason).
  9. From the time of deprecation, no new content can be added that references a deprecated source without prior talk page discussion and concensus.
  10. From the time of deprecation up to 12 months after deprecation, if content referencing a deprecated source is removed by vandalism (see above), it can be re-added as part of normal vandalism reversion process (this is not considered adding new content).
  11. After the 12 month window, a deprecated source effectively becomes a blacklisted source by nature of the ban on adding new content, and the fact that all old content should have been removed by now outside of limited WP:CONTEXTMATTERS cases.

Support/Oppose on Proposal 3

I believe the above strategy aligns with the connotative meaning of deprecated, and doesn't result in deprecated just being another word for blacklisted. It also gives very clear guidelines for what is acceptable editor behavior so there should be minimal edit warring outside of outright vandalism (which Wikipedia already has ways of dealing with). The fixed timelines make it so everyone has plenty of time to address the issues, and changes do not come as a surprise to any users.
The 6/12 month timelines could be adjusted if that is desired. I don't personally believe that deprecated sources are so intrinsictly bad for Wikipedia that they need to be immediately removed (that is what blacklisted sources are for) and I think that the editing process should tend to favor the assumption that other editors are acting in good faith and the content that was added is generally reasonable. I also think that bot-like deleting of content other users took time and energy to add to the site is very hostile, especially to newbies, and should be avoided/limited/telegraphed as much as possible. Deletion of content added by others should generally be a last resort, and we should strive to always give the author plenty of opportunity to improve before we delete their work so we can be a welcoming community to new editors. Micah71381 (talk) 08:03, 28 November 2019 (UTC)[reply]
  • SupportOppose It gives users time to find better sources. However I missed the part about vandalism, I support the autobot part, but not restrictions on human users.Slatersteven (talk) 09:18, 28 November 2019 (UTC)[reply]
  • Support Bit long winded and the time period is long but overall yes I can stand firmly behind this. Deprecated definitely desn't mean fire and brimstone should immediately be rained down on all uses. Dmcq (talk) 10:15, 28 November 2019 (UTC)[reply]
  • Oppose This literally gives deprecated sources more protection than merely bad sources. And new links to deprecated sources are added all the time - there's really no justification for protecting those known-bad additions for six to twelve months - David Gerard (talk) 11:41, 28 November 2019 (UTC)[reply]
  • Strong oppose per David Gerard, and invalid RFC in that this seeks to undermine WP:V, WP:RS and WP:BLP. This is patiently absurd and would defeat the purpose of deprecation, which is to allow generally unreliable sources to be rapidly removed in large amounts without individual discussion when they've been used extensively; in practice this proposal amounts to eliminating deprecation entirely; it is not to provide special protection for such sources, which this proposal suggests. There are, in many cases, thousands or tens of thousands of uses for deprecated sources, and the idea that we could wait six or even twelve months before doing anything systematic about them after a broad RFC on the source is unworkable. I would even go so far as to question the validity of this RFC, since it effectively seeks to overturn every RFC that has ever deprecated a source by redefining "deprecated" to the point of uselessness and seems, in practice, unlikely to get anywhere near the response that the RFCs it is undermining had. Unreliable sources should be fixed (including by removal, if necessary) on sight. Always, without exception. The nature of the fix requires some sensitivity to individual situations, but waiting six to twelve months to fix a glaring problem after an RFC clearly decided that it needed to be fixed is absurd. Note that regardless of the outcome of this RFC, WP:V / WP:RS will always allow editors to remove unreliable sources on sight with an edit reason of "unreliable source" - no consensus here can change that. Even a consensus on the talk page for WP:V / WP:RS cannot allow the continued usage of a definitely reliable source. We can disagree over whether a source is usable in a particular context, or how to handle it if it is, but once it's established that a particular usage of a source is not reliable W:RS always means users removing it with a reason of "unreliable source" are correct to do so. The waiting period for this RFC cannot be enforced; anyone who removed a definitely unreliable source would be correct to do so, and anyone persistently restoring it in the face of a clear consensus declaring it unreliable in that context would still get blocked. EDIT: Note that this proposal also contravenes WP:BLP in that it doesn't make an exception for unreliable sources used to source negative claims about a living person; we are required to remove those on sight, and, again, this invalid RFC cannot change that because the core principle of BLP is not subject to consensus. --Aquillion (talk) 13:58, 28 November 2019 (UTC)[reply]
  • Support seems like the least bad option. Pelirojopajaro (talk) 15:10, 28 November 2019 (UTC)[reply]
  • Support this would protect material being summarily removed for which other sources (once checked) can be used. It would also reduce the risk of good faith editors not understanding why sources are being removed with misleading summaries, the tag will give them time to understand the true meaning of deprecation in the Wikipedia sense, which in actuality is very different from the kind of wholesale bans we've seen being implemented. The Rambling Man (Staying alive since 2005!) 15:34, 28 November 2019 (UTC)[reply]
  • Strong oppose #5 alone is a dealbreaker. If a shit source is used, people should be entirely free to remove said shit source, alongside the shittely sourced content. Just like everywhere else. Headbomb {t · c · p · b} 15:57, 28 November 2019 (UTC)[reply]
  • Oppose all except #1 - A "better source bot" would make it easier to locate and remove or improve bad sources. The rest of it adds unnecessary bureaucracy and arbitrary timeframes that would make it harder to address bad sources and open the door to process-based wikilawyering. "Deprecated source" has no official meaning and sources marked as such should be treated just like any other unreliable source. –dlthewave 18:45, 28 November 2019 (UTC)[reply]
  • Oppose per Aquillion's (core policies) argument.—eric 20:59, 28 November 2019 (UTC)[reply]
  • Oppose because of A/ its incompatibility with core policy, B/ its complexity, in turning what is usually a simple discussion on a talk page into multiple steps and C/ an attempt to replace human judgment with automated tools in an area where judgment and nuances are essential. DGG ( talk ) 20:58, 29 November 2019 (UTC)[reply]
  • Oppose. This would prevent valid removals of BLP violations and other problematic content drawn from terrible sources. Guy (help!) 00:58, 30 November 2019 (UTC)[reply]
  • Oppose. Incompatible with core policy and goes to the heart of what Wikipedia is (or should be). Alexbrn (talk) 03:56, 30 November 2019 (UTC)[reply]
  • Oppose as others have said, this proposal is simultaneously complex, while going against our policy and guidelines. For example although technically it could be argued that removing an unreliable source for reason 'unreliable source in a BLP' doesn't come under number 5, it's way to unclear to me. Nil Einne (talk) 16:54, 30 November 2019 (UTC)[reply]
  • Strong oppose per all the above. See note below on automation. François Robere (talk) 17:44, 30 November 2019 (UTC)[reply]
  • Oppose this and any other proposal that introduces bureaucratic hurdles to the prompt removal of deprecated sources. Cullen328 Let's discuss it 20:48, 30 November 2019 (UTC)[reply]
  • Mostly support I like the idea in general as a reasonable compromise. However the tags should be separate and distinctive (although similar), just for clarity. Also "a deprecated source effectively becomes a blacklisted source" at the conclusion is against WP:DEPS. This should be a cleanup measure to encourage the implementation of policy, not a back-door change to that policy. Andy Dingley (talk) 09:50, 1 December 2019 (UTC)[reply]
FYI there's no policy or guideline on deprecation. It's something that we just sort of started doing one day, and WP:DEPS attempts to document that practice. –dlthewave 12:36, 4 December 2019 (UTC)[reply]
  • OPPOSE Un-reliable sources need to be killed on sight. Debate, if any, can follow, the controversial information can always be added back later if a reliable source presents itself. GenQuest "Talk to Me" 10:15, 1 December 2019 (UTC)[reply]
  • Oppose The concept of deprecated sources is fundamentally flawed because our citation of sources is context-dependent and so each case has to be judged on its merits. Also, it is our general policy that Wikipedia is itself not reliable and so a straw poll cannot be relied upon to determine the validity of sources in a broad-brush way. See also WP:NOTLAW. Andrew🐉(talk) 08:59, 4 December 2019 (UTC)[reply]
  • Oppose. There's no such thing as a fully deprecated source; there are plenty of occasions on which we (e.g.) will need to cite the Daily Mail when the contents of one of their articles is the topic of the article and we want to ensure readers are able to verify the exact wording for themselves. Unless and until a bot is capable of understanding the difference between primary and secondary sourcing, any attempts at automated removal will lead to large-scale disruption. ‑ Iridescent 09:12, 4 December 2019 (UTC)[reply]
  • MORAL support for all but 8 Most of the above seems reasonable, and I'm a little surprised that many people are oppose to the proposal as a whole based primarily on a problem with this one bullet point. Automating much of this process seems reasonable enough, but I'm not much of a techie, and I find it hard to believe that MicahZoltu, who three weeks ago had only 20 edits to his name, would know much more than I do. All that being said, with the inclusion of bullet point 8 I don't think we can allow this proposal to pass and place even more of a burden on those seeking to remove poorly sourced content. Hijiri 88 (やや) 13:13, 4 December 2019 (UTC)[reply]
  • Oppose- bullet point 8 automatically rules this out. No prejudice against considering a version that omits this it in favour of something more sensible. Reyk YO! 13:15, 4 December 2019 (UTC)[reply]
  • Oppose per Aquillion and DGG's reasoning. I support some of the bullets but am strongly opposed to others; this is too many things lumped into one proposal. Levivich 03:09, 5 December 2019 (UTC)[reply]
  • Oppose per David Gerard and Aquillion. Deprecated sources are questionable sources that have been explicitly identified by the community through an RfC. Bullet points #8 and #10 are extremely problematic because they prevent the removal of questionable sources, which contradicts our core content policies. It would be inconsistent to extend special protections to deprecated sources that are not extended to other sources. Bullet points #3–7 describe actions that are already available to editors. — Newslinger talk 00:50, 7 December 2019 (UTC)[reply]
  • Oppose because marking worse sources as better is likely to be confusing. EllenCT (talk) 10:36, 12 December 2019 (UTC)[reply]

Discussion on Proposal 3

Good, reliable sources don’t NEED a “pause before removal”, because no one is likely to remove them. Unreliable sources don’t need a “pause before removal”, because we agree as a community that they are not appropriate. Deprecated sources DO need a “pause before removal” because they are neither fish nor fowl... They are neither reliable nor unreliable. It depends on context. The pause is to examine that context, and to determine if that context is one of the limited situations where the use of the deprecated source is appropriate. Blueboar (talk) 14:28, 28 November 2019 (UTC)[reply]
Well said. Andy Dingley (talk) 19:46, 1 December 2019 (UTC)[reply]

Deprecated sources are a subset of questionable sources: every deprecated source has been confirmed to be generally unreliable by the community through a noticeboard RfC. I don't see any valid reason to specially protect deprecated sources when questionable sources are usually considered inappropriate. — Newslinger talk 01:03, 7 December 2019 (UTC)[reply]

It is extremely simplistic to say "Deprecated sources are those listed on a wiki page. All content from such sources is equally bad." Andy Dingley (talk) 13:17, 24 December 2019 (UTC)[reply]
Content can be removed for normal content removal reasons, just not for "Unreliable Source" during the window. This effectively treats the source as "fine for now, will become blacklisted eventually". There is no additional protection given to the content or the source beyond the protection from being removed as "unreliable source" (which a good source would also have). If the content is inappropriate for the article, if it is vandalism, if it violates other policies, etc it can still be removed per normal Wikipedia editing policies. Basically, treat the source as "fine" for pre-existing content during the transitionary period, but with a warning to users that the source is going to become blacklisted after a time and they should take measures to address the situation if they want the content to remain. Micah71381 (talk) 12:53, 28 November 2019 (UTC)[reply]
Not long ago, someone removed one of these so-called "known bad" sources and modified content, replacing the "known bad" source with a "not-known bad source". Thing was, the so-called "known bad" source was absolutely 100% accurate, and the replacement was wrong, and factual inaccuracies were literally added to Wikipedia. This is why we can't get even close to automating this process, particularly when the use of these sources is contextual and even per DEPS, agreed reliable in some circumstances. The Rambling Man (Staying alive since 2005!) 15:19, 28 November 2019 (UTC)[reply]
  • But I can currently remove any source I feel is unreliable with "unreliable source", with the content cited to it if I don't think finding a source for that content is likely to happen. I can even do so on a dozen articles or a hundred articles, if I want to be fairly WP:BOLD about it or am extremely confident that the source is unreliable, without any discussion or RFC of any sort in advance. This proposal would redefine "deprecation" to give such sources special protection for months on end, which is extremely misleading - I would still be able to mass-remove sources that haven't been discussed, but sources that the community has agreed are severely unreliable in all cases would be specially protected? Absurd. --Aquillion (talk) 14:01, 28 November 2019 (UTC)[reply]
And new links to deprecated sources are added all the time - there's really no justification for protecting those known-bad additions
  • User:David Gerard Per (9) in the above list, new content from a deprecated source is disallowed, effectively treated like a blacklisted source where only WP:CONTEXT can override it. During the transitionary period, any new additions would be treated as though they came from a blacklisted source, so there would be no protection for them like there would be for pre-existing sources. Micah71381 (talk) 12:57, 28 November 2019 (UTC)[reply]
  • As I mentioned in my response, I feel that this proposal is invalid (as in, it cannot be implemented even if it obtains consensus here.) It would redefinine "depreiated" in a way that would effectively overturn every RFC that has ever used the term, and I would even argue that it wouldn't apply to any future RFCs that use the term unless they specifically incorporate its text in the RFC proposal, since its meaning is idiosyncratic to the point of meaningless. "We want to deprecate this source" does not mean "we want to provide special protections for existing usages of this source", and, therefore, any RFC that decides on deprecation would override this RFC unless the response here is extremely high (as most of the RFCs this seeks to undermine were.) --Aquillion (talk) 14:12, 28 November 2019 (UTC)[reply]
User:Aquillion In your opinion, what is the difference between deprecated and blacklisted? When you say, "Unreliable sources should be fixed (including by removal, if necessary) on sight. Always, without exception." that makes me think of how blacklisted sites should be handled. To me, the difference between deprecated and blacklisted is that deprecated sources in existing articles (prior to the deprecation) are not in need of speedy deletion/removal, while blacklisted sources should be purged with prejudice from Wikipedia. Micah71381 (talk) 15:13, 28 November 2019 (UTC)[reply]
Blacklisting a source adds an edit filter to prevent people from using it, and requires that it be removed as soon as possible. Deprecation merely establishes a consensus that it can be removed on sight, raising the burden of anyone who wants to object to a removal by requiring that they answer the consensus in the RFC. Note, even without formal deprecation, and even without any existing discussion, any unreliable source can be removed on sight with an edit reason of "unreliable source" - in fact, WP:RS establishes this (and that will remain true, for all unreliable sources, regardless of the outcome of this RFC and regardless of deprecation, since WP:RS is not subject to consensus.) Deprecation just speeds up this process by avoiding the need to discuss the source every time someone objects to a removal and therefore making it easier to rapidly remove it from many articles at once (since if you do so before it's deprecated, you'll have to answer each objection individually, and may face trouble if your decision that it was unreliable turns out to be sufficiently contentious.) But "remove unreliable sources on sight", with a reason of "unreliable source", is the default - and appropriate behavior required by WP:RS, with the caveats just being disagreement over whether a source is reliable in that context and whether to remove / replace. It is not something an RFC is required for, and certainly not something this RFC could restrict. --Aquillion (talk) 20:19, 28 November 2019 (UTC)[reply]
User:Aquillion This quote of yours, "we could wait six or even twelve months before doing anything systematic about them", makes me think that perhaps you have misunderstood this proposal slightly. During the 6-12 months, you can take action to address the issue of sourcing. The only thing you cannot do is remove the source/content for the reason of "Unreliable Source". As soon as the deprecation occurs the source will be marked as {{better source}}, potentially by a bot, so there would be an even more immediate and systemic action taken than the current procedure. Along with that, any editor may freely replace the source with a more reliable source without discussion. The content itself is also not protected other removal reasons due to "Unreliable Source", so there are still a number of reasons you can remove a source from an article during this transitionar period. Micah71381 (talk) 15:13, 28 November 2019 (UTC)[reply]
The only thing you cannot do is remove the source/content for the reason of "Unreliable Source". Incorrect. WP:RS is core policy and not subject to consensus; therefore, you can always remove an unreliable source on sight with the reason of "unreliable source", no matter what, without exception, and will always be able to do so regardless of the outcome of this RFC. This policy cannot and will not change that; if people believe incorrectly believe that it would have such an effect, it should be hatted immediately. There is room to debate what sources are reliable and how to handle unreliable ones, but if anyone contributing to this RFC thinks that it will delay the removal of a source that an RFC has found to be unreliable in a particular usage from situations where it is being misused, they need to back down immediately. That directly contradicts the requirements of WP:RS and is therefore not possible - unreliable sources are always at least potentially subject to immediate removal. --Aquillion (talk) 20:19, 28 November 2019 (UTC)[reply]
  • Nitpick, but an important one I think for this particular conversation: WP:RS is a Guideline, not a Policy. WP:VERIFY is the policy that underpins WP:RS.
I'd support users being able to use deprecated sources provided they mark the use as such and it gives their justification. Normal talk page discussions can deal with anything beyond that. Not that it is blacklisted like spam. Dmcq (talk) 15:21, 28 November 2019 (UTC)[reply]

We can add a "none grandfather" clause that says this only applies to cites 12 months old, after this new proposal comes into effect. Any source added after this date is still subject to summery removal.Slatersteven (talk) 15:25, 28 November 2019 (UTC)[reply]

I did not say it was easy, but I thought this was a bot? Would it not be possible to have that bot only mark cites added before a certain date?Slatersteven (talk) 17:44, 28 November 2019 (UTC)[reply]
  • As mentioned above, this proposal cannot "come into effect" as written. WP:RS always allows the immediate removal of an unreliable source, fullstop, and is not subject to consensus. There is room to disagree over whether sources are unreliable and how to use them, but "we have agreed that this source is unreliable in this context, but people are not allowed to remove it for the next twelve months" contravenes core policy and is therefore unenforceable regardless of the outcome of this RFC. It is flatly not acceptable, under WP:RS, to say "this source is not reliable, but we are going to use it here for twelve months anyway." --Aquillion (talk) 20:37, 28 November 2019 (UTC)[reply]
Again I think this is just about an automatic bot.Slatersteven (talk) 14:01, 29 November 2019 (UTC)[reply]
Nil Einne Would you be more amenable to this proposal if BLP was specifically called out (as is common in many guidelines and policies)? Or does the complexity of the guideline still leave you in the oppose camp? Micah Zoltu (talk) 17:13, 30 November 2019 (UTC)[reply]
  • A note on automation: I generally support more automation on Wikipedia (see §1-2 in the proposal). I think there's place for a separate discussion on automated scan-and-tag (with {{deprecated inline}}) upon source deprecation, possibly with automated removal and re-tagging (with {{cn}}) after 12-24 months of inactivity. François Robere (talk) 17:52, 30 November 2019 (UTC)[reply]
I am strongly opposed to automation for this. The simple fact is, there are nuances to dealing with deprecated sources that a bot simply can not handle. It has to be done the hard way... case by case and by hand. Blueboar (talk) 17:02, 3 December 2019 (UTC)[reply]

Deeper Problems: Deletion of arbitrary content citing "Unreliable Source"

Reading over this discussion, I think we may actually have a deeper seated problem than deprecation. Above User:Aquillion says, "But I can currently remove any source I feel is unreliable with "unreliable source" with the content cited to it if I don't think finding a source for that content is likely to happen" and this seems to mirror the behavior that some editors exhibit. My understanding of reliable sources (following the ethos of WP:DONTREVERT) is that individual editors do not get to assert that some particular source is unreliable and delete content just because they think it is unreliable. There is a process for getting a source marked as unreliable both for a single page/citation (talk page), or more broadly (Wikipedia:Reliable sources/Noticeboard). Am I misunderstanding policy here and anyone can delete anything citing "Unreliable Source" and that is acceptable behavior of an editor? I have been operating under the understanding that the first step if you believe a source is unreliable and it isn't listed on Wikipedia:Reliable sources/Noticeboard is to either replace the source with a more reliable one, or bring it up on the talk page and engage with other editors to either find a better source, or remove the content if the talk page consensus is that the source is unreliable.

Throughout the Wikipedia editor behavioral guideline pages it repeatedly talks about how we should be WP:BOLD but also prefer to to add content rather than remove content. This feels like a situation where if someone added something and the only issue an individual editor has with it is reliability (meaning one editor thinks the source is reliable, and one thinks it is unreliable), then we should default to siding with the party who wants to add content, rather than siding with the party who delete content. — Preceding unsigned comment added by MicahZoltu (talkcontribs) 18:49, 28 November 2019 (UTC)[reply]

You profoundly misunderstand policy, yes. WP:RS requires that all sources be reliable; therefore, removing a source with a reason of "unreliable source" is always valid in the same way that eg. removing uncited material or unencyclopedic content or things that plainly violate WP:TONE is always valid. Individual cases can be more complex and require more discussion; particularly in contentious cases it might be worthwhile to have discussions in advance to establish a consensus on how a source can and can't be used (or if it is usable at all outside of the highly-restrictive usage that allows almost anything, eg. WP:ABOUTSELF.) And certainly if there are substantial objections, anyone making mass edits to remove a source should slow down and go to WP:RSN to obtain a consensus before continuing (deprecation, of course, is such a consensus.) There's no strict default on who to side with in such a dispute for most situations - once there's disagreement it becomes necessary to talk things out; but note that in WP:BLP situations policy unambiguously sides with people removing the source. In other situations, deprecation is a way to settle those disputes by allowing a source to be rapidly removed with objections directed back to the RFC; without deprecation, you can absolutely remove sources (and even boldly remove it on multiple articles), but must stop and answer individual objections or stop and hold a centralized RFC if it's clear that there's substantial disagreement. The idea that sources would be presumed reliable (ie. removing them is not permissible without established consensus) is absurd and goes against Wikipedia's standard editing policies - WP:BOLD absolutely allows removal (if anything it slightly favors removal, especially of recent material, since adding an unreliable source without estrablishing its reliability in advance is itself bold. And of course, as mentioned, in WP:BLP situations you are required to remove unreliable sources on sight, and restoring them is not permissible without a clear consensus supporting restoration.) --Aquillion (talk) 20:35, 28 November 2019 (UTC)[reply]
So (lets give you are scenario) someone (using a deprecated or dare I say it even banned source) uploads say "Slaves in the south were happy being slaves" that should stay because it is sourced? Or "NASA never landed on the moon" or "Kennedy was killed by Tuffty club assassins to demonstration how dangerous roads are"?Slatersteven (talk) 14:00, 29 November 2019 (UTC)[reply]
  • Great examples Slatersteven. I think what I would like to see in such a situation is at least a claim made by the person removing the content that the information is likely untrue. Part of the problem I'm witnessing both in the issues that lead to this thread and throughout other parts of Wikipedia is that editors are just saying "Unreliable Source" and deleting content without trying to find an alternative source, and for content that is largely undisputed. As an example, if you have 100 unreliable (but not deprecated/blacklisted) sources that all say that X happened, and 0 reliable sources that say otherwise, and little to no reason to believe that the data is incorrect, I think we should err on the side "keep the content". Of course, such a strategy applied without thought has its own set of problems such as people creating 100s of unreliable sources to make some claim no one would report contrary to (e.g., celebrity X was an extra in movie Y, no one will report that celebrity X was not an extra in movie Y). Regardless of which side we land on on this issue, editor judgement needs to play a larger role than is being employed currently.
  • TL;DR: I think the root problem that people are frustrated with is that some editors do not appear (not implying bad faith) to be applying judgement to their editorial strategy. They appear (not implying bad faith) to be doggedly adhering to policy/guidelines without regard to context. This thread, I believe, is essentially other editors trying to formalize a set of rules that will protect Wikipedia from such edits, but in reality I think the core problem is that context and judgement are either not being used or there is disagreement on context and judgement (likely), and disputing context/judgement is really hard and will very often result in an edit war. I don't think I have a good solution for how to deal with editors who don't apply judgement/context, and even less of a solution for dealing with editors who disagree on context/judgement. I don't think any proposed solutions to the problem, including the status quo, will actually resolve this core problem. This problem is particularly bad since a WP:DISRUPTive editor (not implying anyone here is disruptive) can lean on the fuzziness of context/judgement to WP:GAME. Micah Zoltu (talk) 15:09, 29 November 2019 (UTC)[reply]
Which I agree with, because everyone things their loony theory is logical, factual and not disproved (often because RS cannot be bothered to even look at it). Moreover this also reds a bit ORy, "well I think this sounds reasonable, so lets keep it". NO, our cornerstones are verifiable in reliable sources, not logic or reason or persuasive argument (I have recently seen a block for just this sort of argument). Also we do have wp:undue, if no one who is significant gives a damn why should we?Slatersteven (talk) 15:39, 29 November 2019 (UTC)[reply]
  • people are frustrated with is that some editors do not appear (not implying bad faith) to be applying judgement to their editorial strategy. They appear (not implying bad faith) to be doggedly adhering to policy/guidelines without regard to context. It is remarkably forthright of you to admit that you find our core policies to be frustrating, but they are, nonetheless, core policies. If you're in a disagreement with someone who you think is misapplying WP:V, find a better source or produce a consensus that the source is reliable in that context. Those are your options. (For the record, I am sure many of them find you to be failing to apply judgment when adding or restoring sources, and many of them feel you are mindlessly ignoring policy / guidelines without regard to context. But we settle this sort of dispute with our policies and guidelines, not by saying "I find it really annoying when people cite WP:V and WP:RS at me, so let's make WP:V unenforceable." Even if you, personally, feel that an unsourced statement you added to an article is "largely undisputed", the WP:ONUS is on you to demonstrate that by producing a reliable source. I know it can be frustrating and time-consuming to produce such a source, and it can be dispiriting to see the stuff you added to an article repeatedly removed, but when something is legitimately challenged it should always be removed immediately (and will always be removed immediately, especially in WP:BLP situations); if you want to restore it, grit your teeth and put in the effort to find that source rather than wasting time and energy on terrible suggestions like this one. No matter how strongly you feel that a statement is so self-evident that it doesn't require a source, nobody is going to give you a blank check to put or keep essentially unsourced material in the encyclopedia just because you strongly feel it to be true (outside of the limited scope of WP:BLUE, I suppose.) --Aquillion (talk) 18:35, 30 November 2019 (UTC)[reply]
  • Existing methods work quite well on loony theories. The problems arise when there is genuine disagreement between responsible editor on wha controversial matter, because the general (and appropriate) way of conducting an argument on disputed content is to attack the reliability of the sourcing. Any attempt to set up a complicated procedure here will provide more opportunities for those WPedians who are in the majority here to decrease the amount of coverage of other views or even remove them entirely. (I almost always agree myself with the majority position here in most such questions, but the proper way of explaining it is to give every view a proportionate coverage, not try to decrease it by focussing on deprecating every source used while ignoring the possible dubiousness of some of thes ources that agree with the majority.) NPOV requires active measures to counter the inevitable tendency to want content to support what one thinks ought to be the case. DGG ( talk ) 21:08, 29 November 2019 (UTC)[reply]
    DGG, that's a risk, but I'd be interested in specifics. Normally I have not found it difficult to document genuinely significant insanity from reliable sources. We've learned how to deal with this through long experience with Truthers. MONGO is particularly good at it. Guy (help!) 11:37, 6 December 2019 (UTC)[reply]
  • Suggest a two-step process to avoid excess abruptness. First, tag content {{better source needed}} to give heads up on problematic source. In a few weeks, remove bad source, change tag to {{citation needed}}. In a few weeks more, if no better citation given, then delete content. Hyperbolick (talk) 21:20, 29 November 2019 (UTC)[reply]
  • This is the same as Proposal 3 above I believe, just with shorter time frames. If you agree with that, I would encourage you to express your support above with a caveat that the timeframes should be shorter. I would personally be fine with shorter time frames. — Preceding unsigned comment added by MicahZoltu (talkcontribs) 21:28, 29 November 2019 (UTC)[reply]
  • Reading back over Proposal 3, I think I poorly phrased the last step in the process. My intent with the last step in the process is that any content referencing a deprecated source would be "open season" by editors for removal with prejudice. This wouldn't override Wikipedia policy by demanding that the sky is blue is deleted because no one updated the source to a non-deprecated source, it would just move the onus from the person removing the content to strongly back up their claim (which would be the operating procedure during the 12 month window) to the person wanting to retain it to strongly back up their claim. The purpose of Proposal 3 is give people time to fix pages they care about before editors come in and do mass deletions with minimal editorial research. Micah Zoltu (talk) 21:55, 29 November 2019 (UTC)[reply]
  • The phrasing isn't the issue. Material without a reliable source can be removed at any time by any editor, and a reliable source must be produced to restore it. You cannot change that, fullstop. --Aquillion (talk) 18:35, 30 November 2019 (UTC)[reply]
  • As I already said above, we cannot set the process you're requesting. It is a violation of WP:V to require that material without a reliable source remain in place for even a single minute, and it is a violation of WP:BLP to leave such material up at all. We can sometimes disagree over whether a source is adequate, and it is appropriate to request that editors be cautious in situations that they know to be controversial; but when, for instance, a source is clearly unreliable and is being used to cite an WP:EXCEPTIONAL claim, it should always be removed quickly; discussion is not necessary. This is core policy and cannot be changed by discussions here, so I will continue to edit in accordance with that policy (ie. removing things that are exceptional and indisputably sourced to unreliable sources, immediately and without discussion) regardless of discussions here - and I fully expect that anyone who restores such removals without obtaining a clear consensus to do so will get blocked, while my removals will be appropriate. Again, I can understand some of the angst over rapid-pace removals, especially in situations that are not so clear-cut; I could support a loose, optional essay suggesting voluntary guidelines for when to discuss things, and plainly things like careless removals causing disruptions are a separate issue that need to be handled on an individual basis. But the hard, sweeping restrictions people are proposing here directly contravene WP:V and are therefore utterly unenforcable - no matter what happens with this discussion, things that plainly lack a reliable source would still be removed immediately, and anyone who repeatedly restores such material would still be subject to a block for violations of WP:V. Proposal 3 should be hatted immediately; thankfully seems to be heading to the well-deserved dismissal such a terrible proposal deserves, it would remain unenforceable even if supported by unanimous consent. WP:V cannot be changed by editorial consensus and, therefore, any material lacking a reliable source directly supporting it may be removed and should not be restored without an inline citation to a reliable source. --Aquillion (talk) 18:29, 30 November 2019 (UTC)[reply]
  • I largely agree with you at this point, see my TL;DR above. I think the real underlying problem here (which it sounds like you agree is a problem if it is occurring) is that there is the appearance/belief that some editors are not trying to find alternative sources, are not using judgement to decide whether the claim is exceptional or not, or are doing mass reverts/deletes rather than precise deletions. This sort of behavior is hard to prove since the editor can just say "the claim seems exceptional to me" or "oops, didn't mean to delete that" over and over again and it becomes exhausting to cleanup after such a person and debate them over and over again, even if you are winning the exchanges. On top of that, since following someone around and fixing their mistakes is generally not allowed, you may end up getting in trouble for trying to protect Wikipedia from such an editor. This is what leads to proposals like these, where people are trying to figure out a way to protect Wikipedia from a perceived problem. Micah Zoltu (talk) 18:44, 30 November 2019 (UTC)[reply]
  • Exactly... the issue is that, as a community, we really do not like it when editors make mass edits (even when those edits are totally in line with policy ... people have been sanctioned for going on policy “enforcement crusades”). Go through a series of articles, one at a time over the course of several months, and remove/replace poor sources and iffy content... no one gets upset. Do the same all at once, and the edits appear unthinking (even when they are not), and the edits are deemed disruptive.
The community agrees that certain sources should be deprecated... and that in most (but NOT all) situations they should either be replaced or removed. But we ALSO want that done carefully (because there ARE exceptions to deprecation). And THAT means we have to do it the hard way... one citation at a time... slowly and by hand. Blueboar (talk) 19:26, 30 November 2019 (UTC)[reply]
This is literally what I do - you're battling a straw man - David Gerard (talk) 20:04, 30 November 2019 (UTC)[reply]
Blueboar, what you're saying - and it's absolutely true - is that you can get away with purging all references to a crap source (a predatory journal, say) as long as you do it in a way that nobody notices.
We have strong support for identifying sources that are generally unreliable, super-strong support for RS as a principle, but no documented consensus around the inevitable corollary that once a source has been identified as unreliable it should be removed, despite a long history of having done exactly that (e.g. with Breitbart).
So while you're right that removing over a period of time is certainly less likely to cause drama, that arguably introduces a policy that you can only remove sources as long as nobody notices, which is unsatisfactory and more or less guaranteed to result in drama. Guy (help!) 11:34, 6 December 2019 (UTC)[reply]

Proposal: Procedural removal of admin rights who have not used the admin tools for a significant period of time (maybe 5 years)

This reduces the number of administrators that probably have no use for the tools. Interstellarity (talk) 00:48, 18 December 2019 (UTC)[reply]

@Interstellarity: just for reference, the following 62 admins have not made a "log entry" in over 5 years:
List of admins without recent logs
user_name user_editcount user_registration Last edit Last log user_group
Cecropia 12514 20031226204625 20191022150441 20080116071815 sysop
Wrp103 7568 20040707133428 20191112160840 20080725032125 sysop
SpuriousQ 17821 20050605102221 20191207061429 20090109162447 sysop
Morven 18628 20030217073253 20190826065552 20090310163226 sysop
Wassupwestcoast 12006 20060906233639 20190228005532 20090906232236 sysop
XDanielx 4227 20070714072421 20190325204656 20091107065713 sysop
Ramitmahajan 10153 20060413080259 20191020121100 20100106163958 sysop
Camembert 18980 20020225154311 20191123190341 20100107024947 sysop
Nixdorf 7257 20021125001815 20191030081008 20100213130534 sysop
MrDarcy 7619 20050118204417 20190528232918 20100316023857 sysop
Frazzydee 8083 20031108025139 20190218235834 20100419025606 sysop
Chairboy 8128 20040816075811 20190407231616 20100620140434 sysop
K1Bond007 25919 20030805032410 20181216220208 20100819063220 sysop
Cyrius 19544 20031224195156 20191116053720 20100915033929 sysop
Deiz 16055 20051227160345 20190803124709 20101108100031 sysop
Sn0wflake 7221 20040716065200 20190831191726 20101226235035 sysop
Eliz81 15671 20061011183314 20191013012235 20101227032204 sysop
Zoicon5 24862 20030716184616 20191024020920 20110307203217 sysop
Grue 6498 20040828134246 20191008070242 20110325203151 sysop
Where 7158 20051225023642 20190601001131 20110810012028 sysop
Butseriouslyfolks 16742 20070104201720 20190921211035 20111011054725 sysop
Wickethewok 16435 20060119092227 20191213044304 20111013041227 sysop
XJaM 11297 20020225170337 20190825020524 20111110175229 sysop
Ilyanep 6912 20030507214927 20191002160608 20111111212023 sysop
RG2 13297 20050828070336 20190829133416 20111130043959 sysop
David.Monniaux 17008 20030913115900 20191129114207 20111203144756 sysop
TheoClarke 7495 20050115211715 20191015124008 20120205000347 sysop
Thatcher 28285 20060208173441 20191107202508 20120208195226 sysop
Saravask 21952 20050924041106 20191020094040 20120303213457 sysop
Oliver Pereira 5880 20020225155115 20190804195141 20120424152352 sysop
Dbenbenn 19217 20040113200123 20190811084109 20120430033021 sysop
Hawstom 4771 20030903223732 20191117225231 20120507020802 sysop
MarkGallagher 9530 20041104161518 20190206004550 20120808080955 sysop
Kotra 8949 20051122065114 20190903033759 20120821001625 sysop
Stevenj 14746 20030201213757 20191212180342 20120908204551 sysop
GeeJo 25989 20050614000131 20190929175402 20121213005056 sysop
Berig 20774 20060818154821 20191025140412 20130225124844 sysop
Kaisershatner 17296 20040727151618 20190307214736 20130319161302 sysop
Marianocecowski 19921 20041116131605 20191206094100 20130417122210 sysop
Ryan Norton 12338 20050301062750 20190717062946 20130424031459 sysop
InShaneee 15944 20041110060942 20191204082928 20130513102952 sysop
Ortolan88 10334 20011116235623 20191203032312 20130630192102 sysop
Chris G 20244 20060827072922 20190518074733 20130801113933 sysop
MattWade 23192 None 20190508203016 20130816163708 sysop
Evercat 16369 20030416021703 20190809175834 20130829000244 sysop
Caltrop 3569 20020605160936 20190930014319 20130830211814 sysop
Sethant 4501 20061218000947 20191115235547 20130916030709 sysop
WAvegetarian 7422 20050531090821 20191001063657 20131212024446 sysop
Drilnoth 51237 20081025231019 20190806041058 20140303022300 sysop
DanielCD 31536 20040620130607 20191211134320 20140303144106 sysop
Ev 12895 20050329053116 20190924015323 20140311154438 sysop
BozMo 14039 20040405151455 20190809144049 20140630075330 sysop
Faithlessthewonderboy 31588 20070717014639 20190718172849 20140703144520 sysop
Atama 17307 20061122234324 20190910124251 20140710234952 sysop
Aqwis 5680 20061021144019 20190902140353 20140731212735 sysop
Jeepday 27568 20061029134933 20191202222909 20140806091020 sysop
Oren0 7324 20060906205054 20190721063208 20140809195528 sysop
Refdoc 3141 20030104001937 20181216200355 20140810175513 sysop
Gwalla 8644 20040114014814 20190929233348 20141001204457 sysop
Mindspillage 10665 20040622061129 20181208052138 20141009171655 sysop
Gimmetrow 45176 20060503140850 20190705233811 20141016184922 sysop
JohnOwens 8117 20021009035258 20191113154346 20141124000904 sysop
Resolved sidebar about bureaucrat activity
xaosflux Talk 01:16, 18 December 2019 (UTC)[reply]
Regarding 'crats, we do proactively track these (as unlike admins 'crats have a "use it or loose it" rule) - see Wikipedia:Bureaucrat activity (there are no current issues). — xaosflux Talk 01:18, 18 December 2019 (UTC)[reply]
@Xaosflux: I also found one bureaucrat, Cecropia, has not used their bureaucrat permissions for a while. Interstellarity (talk) 01:24, 18 December 2019 (UTC)[reply]
@Interstellarity: yes the 'crat activity policy calls for crat activity (not necessarily a logged action) at least once every 3 years (it is trivial to meet if you are participating in that facet) - we have 2 'crats potentially up for removal next april unless they re-engage. — xaosflux Talk 01:27, 18 December 2019 (UTC)[reply]
@Xaosflux: OK, that's clear. I have changed my proposal so it affects only admins, not bureaucrats. Interstellarity (talk) 01:31, 18 December 2019 (UTC)[reply]
  • Support, and it's about time we implemented such a rule. BD2412 T 01:47, 18 December 2019 (UTC)[reply]
  • Support, five years is reasonable. Randy Kryn (talk) 02:02, 18 December 2019 (UTC)[reply]
  • Comparing this to WP:INACTIVITY, is this also temporary thing, to be reversed upon request? Or, "You need to run the WP:RFA gauntlet again"? I assume we'd want the same one-month/several-days alerting. And, if we do this, I'd certainly update WP:INACTIVITY so all this information is on one place. And, Five years is too long. -- RoySmith (talk) 02:40, 18 December 2019 (UTC)[reply]
  • This needs some detail: per RoySmith, is this reversible on request?; is the admin notified beforehand and what about gaming the system? Johnuniq (talk) 03:10, 18 December 2019 (UTC)[reply]
  • I am sure there is a definitive number somewhere, but a quick look at https://en.wikipedia.org/w/index.php?title=Special:ListUsers&limit=500&group=sysop turns up between 1000 and 1500 admins. There are 63 on the inactive list above. That amounts to around 4 to 6 percent of the total number of admins. Personally, that is too small a slice of the population to be concerned above considering the goal here is to reduce the # of admins who have no use for the tools. Now, if the % was up around 15% or 20%, I'd be on-board. --User:Ceyockey (talk to me) 04:10, 18 December 2019 (UTC)[reply]
    We have 855 current admins. — xaosflux Talk 04:26, 18 December 2019 (UTC)[reply]
  • Worth considering is that there are certain administrator-restricted actions that don't create a log entry. I recall that there are some Main Page tasks that can only be carried out by administrators (as I recall, because they involve editing through full protection of some kind), which are not logged actions; however, there are several administrators who specialize in this area and probably don't have a lot of (or possibly any) logged admin actions. There are also some "actively editing" admins who may be using other aspects of the admin permission (e.g., looking at deleted revisions for appropriate purposes, such as rescuing useful references). I think probably more value would come from increasing the minimal total activity level (edits + admin actions) per year in order to maintain admin tools. On the other hand, when looking at compromised admin accounts (which is the main justification for removing the bit), there was no particular correlation between activity of the account and likelihood of compromise. Risker (talk) 05:27, 18 December 2019 (UTC)[reply]
    The "the only admin thing I ever do is look at deleted versions" admin seems to be a bit of a unicorn, I've heard of this, but can't recall ever meeting one. — xaosflux Talk 05:31, 18 December 2019 (UTC)[reply]
    There are at least two that I know of, one of whom is on the list above. I'd also suggest it's the primary use of admin tools of a bunch of others (including a certain Mr. Wales). I do recall at least two admins who temporarily gave up the bit saying that the only thing they really missed when they continued editing without the bit was not being able to see deleted stuff; they didn't mind not feeling obligated to do the general mop work. Risker (talk) 06:17, 18 December 2019 (UTC)[reply]
    Admins who only want tool access to do non-logged actions should probably not have the tools in the first place. They are called 'tools' for a reason. The expectation and obligation is that they will be used to do the general mop work. Only in death does duty end (talk) 09:56, 18 December 2019 (UTC)[reply]
    @Only in death: - that seems dubious. The system could have been set up to record any fully protected edit as a logged action, but it would still be the same work. More relevantly, I would count handling the administrative bit around DYK as as general mop work as my closes in AfD. There is more than one way to serve. Nosebagbear (talk) 10:11, 18 December 2019 (UTC)[reply]
    FWIW editing through protection is recorded by Special:AbuseFilter/942, created by xaosflux for this very purpose, I believe. ~ Amory (utc) 18:10, 18 December 2019 (UTC)[reply]
  • Oppose so as long as we don't have ways to count unlogged admin actions. Which include (but not only that) edits to protected pages and denials of admin actions. Jo-Jo Eumerus (talk) 09:14, 18 December 2019 (UTC)[reply]
  • Oppose- What Jo-Jo Eumerus said. Editing protected pages, investigating deleted articles, and such are admin actions but if they're not logged it's misleading. I'm also not a fan of pressuring admins to make a token action every now and then just to hang on to the tools. Reyk YO! 10:08, 18 December 2019 (UTC)[reply]
  • VPI? - this is a good idea, but perhaps should have a stint in VPI to resolve potential issues. There'd be a single initial irksome bump, but we could handle this by communicating to any admin getting close and either they can just make that action, or if they can point to non-logged admin work, then they can just be strained out of the list to remove. Nosebagbear (talk) 10:14, 18 December 2019 (UTC)[reply]
  • Oppose All admins have a use for the tools ie building an encyclopaedia. Since we are talking about users who are active, no harm is done by therm possessing them, even though they may not be actively engaged in admin work. There is no cap on the number of admins. Hawkeye7 (discuss) 18:37, 18 December 2019 (UTC)[reply]
  • Support any time frame. My prefernce would be 6 months. The admin flag isn't a trophy, it's a tool. If the user stopped being admin, for any reason, then they should not have the flag. I've also seen admins who actively log in once a year around the same date and do 1-3 edits. I'd even support a clause that prevents gaming the system, which can be verified on a case-by-case bases. --Gonnym (talk) 18:46, 18 December 2019 (UTC)[reply]
  • Oppose per Reyk and Hawkeye. Perhaps gently ask people to help out with some backlogs that require admin tools, but no need to force them. The only use for the proposal I can see is that we wouldn't overestimate the number of admins willing to block, protect, or delete, but I don't see anyone using the admin number for anything serious anyway. —Kusma (t·c) 20:14, 18 December 2019 (UTC)[reply]
  • Striking for now as I did not understand the proposal, and now that I do, I would like more time to think about it. Wug·a·po·des 13:13, 26 December 2019 (UTC) Oppose If the users are active, find a backlog and ask if the admin would mind chipping away at it. Odds are, if they are still active, they are using the tools, just not taking logged actions. If the editor is not active, I think this is moot because inactivity requirements would kick in before this. Wug·a·po·des11:42, 26 December 2019 (UTC)[reply]
    @Wugapodes: I think this is aimed at admins that are making trivial edits-per-year just to stay admins, those that may no longer meet the requirements for restoration if they were to have access removed. — xaosflux Talk 12:54, 26 December 2019 (UTC)[reply]
    They'll have to make one edit and delete/undelete a user subpage if this proposal passes. Won't make a substantial difference to people who do the minimum required to stay admins, but will de-admin those who refuse to game the system. —Kusma (t·c) 11:03, 27 December 2019 (UTC)[reply]
    Ironic, considering I would rather retain the admins who refuse to game the system even if they aren't making a ton of logged actions. I think I'm still leaning oppose at the moment. People who game the current system will probably continue to do so if we change the requirement from X edits in Y days to X logged actions in Y days. The only casualties of such a change will be people who have some kind of moral conviction against gaming that new system. That's the opposite outcome from what I would want. Wug·a·po·des 00:16, 28 December 2019 (UTC)[reply]
    Apply this immediately, with no warning period. Then there can be no gaming. * Pppery * it has begun... 03:25, 28 December 2019 (UTC)[reply]
  • Support Except the waiting period is too long. I actually like the idea of 6 months, proposed by Gonnym. Puddleglum 2.0 04:33, 29 December 2019 (UTC)[reply]
  • Oppose Per Jo-Jo. Galobtter (pingó mió) 04:38, 29 December 2019 (UTC)[reply]

WikiProject: prefix

There should be a page prefix exclusively possible for WikiProjects. They clutter the search for “Wikipedia:” and need to be separated. E Super Maker (😲 shout) 00:30, 21 December 2019 (UTC)[reply]

Agree....policy and gudlines should aswell....so we can search them like the MOS.--Moxy 🍁 03:14, 21 December 2019 (UTC)[reply]
Not sure what the problem is. Project namespace seems to be correct for all of this. (And, of course Project: is an alias for Wikipedia:, so Project:GERMANY redirects to Wikipedia:WikiProject Germany). Or do you want to remove all WP: shortcuts for Wikiprojects? That would break 15 years' worth of links, no thanks. —Kusma (t·c) 08:36, 21 December 2019 (UTC)[reply]
No, It wouldn’t remove WP: shortcuts, because some of them redirect to mainspace pages. E Super Maker (😲 shout) 00:29, 22 December 2019 (UTC)[reply]
Yes it would, WP: is a redirect to Project: (localized as Wikipedia:). We would have to keep every single page and turn it in to a cross-namespace redirect to maintain that (or retarget WP: and that is even worse). — xaosflux Talk 14:08, 22 December 2019 (UTC)[reply]
@E Super Maker: can you be more specific? Here is an example project: Wikipedia:WikiProject Military history. What are you proposing it be renamed to? — xaosflux Talk 01:56, 22 December 2019 (UTC)[reply]
Think he is proposing it to be WikiProject:Military history. Happy Festivities! // J947 (c) 03:30, 22 December 2019 (UTC)[reply]
Correct! E Super Maker (😲 shout) 13:48, 22 December 2019 (UTC)[reply]
  • Any prefix can already be created in any namespace. It seems they're proposing to create WikiProject "namespace". I am not convinced this is a good idea though. – Ammarpad (talk) 05:12, 22 December 2019 (UTC)[reply]
  • I assume the idea is to be able to more easily sort thorough policies or other pages in the "wikipedia:" namespace? It would be helpful to understand why the proposal concerns wikiprojects in particular (would you want separate namespaces for essays, policies, etc?). Is the "clutter" making it difficult to find a specific kind of page? I think the proposal would benefit from a bit more explanation/specifics. Forbes72 (talk) 07:01, 22 December 2019 (UTC)[reply]
  • OPPOSE Poorly thought out and explained proposal. For what I do understand, I see no need. GenQuest "Talk to Me" 13:24, 22 December 2019 (UTC)[reply]
  • Strong Oppose now that this has been clarified that this isn't about a naming convention, but about creating an entirely new namespace just for "wikiprojects". Not to mention having to move at least many thousands of pages (these) and breaking the WP: namespace shortener. — xaosflux Talk 14:06, 22 December 2019 (UTC)[reply]
I’m not really seeing how this would break WP:. E Super Maker (😲 shout) 14:24, 22 December 2019 (UTC)[reply]
@E Super Maker: "WP:" goes to "Project:" which goes to "Wikipedia:" So WP:MILHIST goes to Wikipedia:MILHIST, so at the very least you'd have to leave all those pages in Wikipedia space (thus not shrinking the pages in it at all) and make redirects to this new namespace - or break things. — xaosflux Talk 14:38, 22 December 2019 (UTC)[reply]
This sounds like a really good thing for a bot to do. E Super Maker (😲 shout) 15:28, 22 December 2019 (UTC)[reply]
  • Oppose I do not, really, understand why projects would be deemed important enough to deserve their own namespace; while some—MILHIST, mentioned above for example—are superlative, "industry-leading", of their kind, many projects are effectively moribund. ——SN54129 14:10, 22 December 2019 (UTC)[reply]
  • Oppose per others. No real need. Happy Festivities! // J947 (c) 19:19, 22 December 2019 (UTC)[reply]
  • Support CNR – We don't have to move anything anywhere, we can have a namespace alias WP:CNR like MOS:. And it would be very useful to have one (WikiProject:), though I'm not sure what the abbreviation should be (PJ:? WPJ:?). There are so many confusing shortcuts. For example, WP:TERRORISM goes to WP:WikiProject Terrorism, but WP:TERRORIST goes to WP:Manual of Style/Words to watch#Contentious labels. WP:RACIST points to the same section, but WP:Racism goes to WikiProject:Discrimination. WP:MUSIC goes to a notability guideline; MOS:MUSIC to the MOS section; what's the shortcut for WP:WikiProject Music? It's WP:WPMU... not exactly the first think you'd think of, eh? But unlike WP:MUSIC, WP:ALBUM doesn't go to the notability guideline; instead it goes to the WikiProject; the notability guideline is WP:NALBUM. I think it's technically possible to have a namespace alias so I'd support a CNR like WikiProject:Foo (or WPJ:Foo or something for short) that would point to "Wikipedia:WikiProject Foo", and then we could have WPJ:TERRORISM, WPJ:MUSIC, WPJ:RACISM, and it wouldn't be confused for the WP: (policy or guideline, including notability guideline) or MOS: (manual of style) prefixes using the same shortcut. So WPJ:MUSIC would point to the WikiProject, WP:MUSIC to the notability guideline, and MOS:MUSIC to the MOS section. Levivich 19:24, 23 December 2019 (UTC)[reply]
    @Levivich: please note, MOS: is not a "namespace alias" it is a collection of CNRs and are all in the article namespace. I have a feeling that some wiki-technical phrases are getting confused in this discussion. — xaosflux Talk 02:29, 24 December 2019 (UTC)[reply]
    Xaosflux, thanks for clarifying. I thought a CNR and a "namespace alias" was the same thing. What's the difference? We could probably all benefit from an education in the terminology. But semantics aside, replace "namespace alias" in my comment with "CNR"-what do you think? Levivich 03:17, 24 December 2019 (UTC)[reply]
    @Levivich: so, the main name for pages that are in namespace 4 (NS_PROJECT) is Project:, for example you can go to Project:Administrators' noticeboard. "Wikipedia" is a namespace alias that also goes to NS_PROJECT, and is also our localized name for NS_PROJECT. Additionally "WP" is another namespace alias for NS_PROJECT. All those "MOS:" pages are in the main namespace, and are just standard redirects that redirect the link back in to the project namespace. You could create more mainnamepace redirects such as WPJ:MILHIST that go to Wikipedia:WikiProject Military history - but it will still be the same target - in the same namespace. It is possible to create new custom namespaces, and localized names and aliases for them - that appears to be what Sophivorus is proposing here. — xaosflux Talk 03:52, 24 December 2019 (UTC)[reply]
    P.S. namespace aliases such as WP=>Project are done automatically and are fixed, whereas things like MOS: are just normal redirects and must be created and maintained as pages. — xaosflux Talk 03:54, 24 December 2019 (UTC)[reply]
    Ahh I see, thanks for the explanation, I've updated my !vote. It seems CNRs are a very easy way for any WikiProject that wants to to create a shorter or clearer shortcut. I just created WikiProject:Music and WPJ:Music redirects to WP:WikiProject Music. I would support that becoming a convention (with WPJ: being for WikiProjects, MOS: for MOS pages, and WP: for policies, guidelines, and essays). Levivich 04:15, 24 December 2019 (UTC)[reply]
    There's a consensus as mentioned in WP:CNR for no new mainspace CNRs. Galobtter (pingó mió) 04:20, 24 December 2019 (UTC)[reply]
    From six years ago; consensus can change, etc. Levivich 04:28, 24 December 2019 (UTC)[reply]
  • Oppose I see no indication of any problem this proposal is attempting to solve. * Pppery * it has begun... 05:35, 24 December 2019 (UTC)[reply]
  • Support Namespaces are actually pretty cheap; we've got about 10 currently on enWiki (Portal, Book, Draft:, TimedText:, Module:, and their talk namespaces) and another 6 defined-but-unused namespaces. Why would we want to create a new namespace? mw:Manual:Using_custom_namespaces#Why_you_would_want_a_custom_namespace gives the main reasons, but some use cases I see here:
Search all and only WikiProjects; useful for new editors (or old editors trying to find the Domestic Pigeon Task Force)
No more conflicts between shortcuts; just as H:R and WP:R go different places, we could have PJ:M go to MilHist and WP:M go to Wikipedia:Mediation.
Links will be categorically shorter; WikiProject:Linguistics is shorter than Wikipedia:WikiProject Linguistics
They aren't life changing gains, but there are tangible benefits to this idea. I don't see any real downside either besides the set-up cost of migrating the existing pages. Xaosflux seems to think that's more trouble than it's worth, and usually they know better than me on things like this. However I don't think the goal is shrinking Project:, but reducing shortcut conflict among other stuff I mentioned above. So if we get the benefits of a new namespace, I'm not concerned about leaving redirects behind to prevent breakage because we've done it a number of times before: we left CamelCase redirects behind after switching from UseModWiki (see {{r from CamelCase}}), and we kept redirects from Wikipedia:Wikiportal/* after the move to the new Portal: namespace until an RFD 5 years later found consensus to delete the redirects. I'm opposed to handling this using CNRs from mainspace like MOS: pages because that's a mess that honestly should also be fixed by adding a new namespace. This may actually be an opportunity to figure out how we would do that. Wug·a·po·des11:25, 24 December 2019 (UTC)[reply]
  • Support per Wugapodes explanation above. I always dislike seeing arguments for not doing something because "a lot of pages will move". We do that every day; we also have moved thousand of articles when needed (such in a recent election NC change). If that is the only reason not to do something, that is a pretty weak reason. I also agree with Leviv that the current project namespace is a mess with similar redirects using MOS/WP and being inconsistent to where they redirect. This too can be easily solved with the move proposed. --Gonnym (talk) 11:44, 24 December 2019 (UTC)[reply]
  • Oppose cross-namespace redirects, we don't need to clutter mainspace with more of them. For that matter, the cross-namespace redirects WikiProject:Music and WPJ:Music created during the course of this discussion should be deleted. Very weak oppose about an actual new namespace; I don't think it'd be wrong, it just seems rather pointless. When it comes to search clutter, I find much more of that from archives of old deletion discussions and such than I do from WikiProject pages. In practice I've seldom seen confusion over whether a shortcut refers to a policy or a project, as context is usually sufficient. But if confusion really is a concern, you could as well encourage the use of shortcuts like WP:WPVG over WP:VG instead of asking for a whole new namespace with associated shortcut when the existing WP shortcuts will need to hang around for some time anyway to avoid breaking links in old discussions and edit summaries. Anomie 14:10, 24 December 2019 (UTC)[reply]
  • Oppose solution in search of a problem. Headbomb {t · c · p · b} 15:45, 24 December 2019 (UTC)[reply]
  • Oppose new namespace as the saved keystrokes don't justify the overhead of a new namespace (with associated guidance etc) - there are already 30+ namespaces to select from when using Advanced Search, having "Project" namespace and "WikiProject" namespace would confuse newbies (we already see confusion of portals vs wikiprojects), we'd potentially get forks of wikiproject in other namespace, there would be questions about whether task forces belong in that namespace ... DexDor (talk) 22:22, 24 December 2019 (UTC)[reply]
  • Just a heads up that there is a discussion at RfD concerning the redirects that Levivich created. Merry Christmas! // J947(c), at 23:44, 24 December 2019 (UTC)[reply]
  • Strong support per Wugs. Soumyabrata (talksubpages) 07:54, 25 December 2019 (UTC)[reply]
  • Support. I've often wished I didn't have to type all of "WP:WikiProject". And, having it broken out as its own namespace means I can search just in that namespace. Makes sense to me. -- RoySmith (talk) 16:04, 25 December 2019 (UTC)[reply]
  • Super hard oppose. WikiProjects are dying (like Portals) and we're proposing to give them their own space? It's not like they need the room to grow. People who want to search in that namespace can do something like Special:Search/Wikipedia: intitle:WikiProject. We also do not need an XNR for this, as previously agreed (no new XNRs). Most WikiProjects, if they need it, have a shortcut. Inconsistencies in shortcuts can and should be remedied at WP:RFD, not by adding another new namespace. In short, I really don't see a problem here that needs a solution. --Izno (talk) 16:36, 25 December 2019 (UTC)[reply]
  • oppose as the Wikipedia space is supposed to be for things like wikiprojects. You don't have to type all of "WP:WikiProject" as normally when you have to type it is a template that point to a project, and that is in template space. Anyway the prefixes are already excessively cluttered with useless things that make life difficult when you do a rename. (for draftification, userfication) Graeme Bartlett (talk) 05:03, 29 December 2019 (UTC)[reply]

Proposal for a section called "Wikipedia: Articles for merging"

I wonder whether it is worth putting in a proposal "Wikipedia: Articles for merging"? At Wikipedia: Articles for deletion, there are sometimes proposals for merging, rather than deleting. I have been wondering whether the Tanita Tikaram singles Yodelling Song and Wonderful Shadow are worthy of their own articles, but I would support a merge with the article on the album Lovers in the City rather than a full deletion. Vorbee (talk) 07:45, 23 December 2019 (UTC)[reply]

We already have that. See Merger Notice Board. GenQuest "Talk to Me" 08:28, 23 December 2019 (UTC)[reply]

Thank you User: GenQuest - I do not think I had seen that. Vorbee (talk) 08:51, 23 December 2019 (UTC)[reply]

New approaches to "Simple English Wikipedia"

I recently stumbled upon this seemingly wonderful invention. I see great potentials in it. I see shortcomings in it, also - but not ones like the complaints that pollute its article's Talk Page. There, the complaints all seem to center around a kind of "English Language Bias". This is not helped by the fact that use-of-language seems to be Simple's only expressed selling point;

I believe it's a disservice to limit Simple's described audience to that. (It also opens up Simple to unwarranted criticism - particularly from those with a kind of English-only prejudice.)

I would argue that additional stated benefits should include concision and convenience. Its articles, nor writing guidelines don't need to change - they already appeal to these benefits. My first suggestion is that these benefits be put right on its front page, as well as the main Wikipedia article.

I'm highly technical and language-fluent, yet there are some articles in English's main Wikipedia that are so laborious and/or highly technical that it's a difficult read. This is not a complaint. This is, of course, what one wants from an encyclopedia! But sometimes I don't want to attain a PhD on a subject, but instead just a general perusal.

Doubtless Simple would benefit from more articles, ergo: more authors. For this, I don't think the challenge is a lack of people willing to write for it, but rather a lack of people aware of it. A decade and a half after its creation, and I only just stumbled upon it - and not from Wikipedia. I inadvertently found an article from a search engine. I should have seen a reference to it long ago on Wikipedia, itself.

This leads to my next suggestion, and this is an admittedly bold one; a "Simple" tab right next to the |Article|Talk| tabs. Right on top. Obviously, only for main-English articles for which there is a corresponding Simple article.

My fervent belief is this would create a massive wave a new awareness of Simple's existence, and a concomitant flood of new authors. Only then could Simple reach its potentials, therefore its true value.

     —  BoringJim (talk) 21:14, 25 December 2019 (UTC)[reply]

This has been discussed before (a quick search shows Wikipedia:Village_pump_(proposals)/Archive_66#Examples_TAB_beside_Article_tab_and_discussion_tab as an example). It could be possible to add at least a local script to include "Read on Simple English Wikipedia" or something if the interwiki to simple: exists. I doubt this would get integrated to mediawiki core. Problem at least for non-logged in users, we really wouldn't want to run a script an reformat the page every single time a page was read - and this wouldn't be effective for mobile readers. This could possibly be done as a gadget for logged in editors. — xaosflux Talk 23:04, 25 December 2019 (UTC)[reply]

RFC on decorative quotes

 – Pointer to relevant discussion elsewhere. New RfC at RfC: Use of Decorative Quotes in article space, and the Cquote template

DES (talk)DESiegel Contribs 00:32, 29 December 2019 (UTC)[reply]

Please check your link as this is going off wiki for me. Graeme Bartlett (talk) 05:05, 29 December 2019 (UTC)[reply]
The correct link is Wikipedia talk:Manual of Style#RfC: Use of Decorative Quotes in article space, and the Cquote template. Outriggr (talk) 05:20, 29 December 2019 (UTC)[reply]

Could make an antivirus bot here

what about this? 2804:14C:5BB5:8076:15B7:1E14:F2A4:5174 (talk) 02:23, 30 December 2019 (UTC)[reply]

Hi 2804... can you point to some specific examples of what you would want it to do? — xaosflux Talk 03:20, 30 December 2019 (UTC)[reply]
Have there been any instances where a virus has affected Wikipedia, or has affected readers because of something they have downloaded from Wikipedia? Certainly the former case, and probably the latter, should be dealt with at the level of MediaWiki development rather than by a bot. Phil Bridger (talk) 10:04, 30 December 2019 (UTC)[reply]

Article introductions

I’m first time here, and no expert. In my search, I didn’t find a discussion of this issue.

I’m a regular user of Wikipedia, but have only contributed once before this. My issue is article introductory paragraphs, which frequently are so precise that, for the average reader of an unfamiliar topic, the summary point is lost. My issue is well summarized by this comment I found in a thread on a technical website:

@MontyHarder, actually, I liked the simplicity of the explanation before, without getting so deep into terminology. This is the problem with community edited solutions like Wikipedia: simple explanations that get the idea across get mangled to the point of unreadability for beginners simply because experts aren't satisfied with the technical precision. – Wildcard Mar 29 '17 at 23:53

Or more simply: the perfect is the enemy of the good.

IMHO, when someone starts or edits a wiki entry, I would hope such a reminder would be the first guideline they see.

Comprehension is the key to the introduction. When I comprehend the overview, I’m much more likely to explore its nuances.

Many thanks for your consideration.Urbanist27 (talk) 16:48, 30 December 2019 (UTC)Urbanist27[reply]

We try to provide a readable lead but sometimes we miss the boat. If you have an article in mind, you are welcome to provide feedback on the talk page or at one of the WikiProjects tagged in the talk page. --Izno (talk) 17:50, 30 December 2019 (UTC)[reply]
Most articles in Wikipedia could do with improvement, and the lead sections of articles about technical subjects need lots of improvement. As an example, I am a postgraduate student of mathematics, but I find many of the leads of our articles on mathematical topics impenetrable, because they appear to be written like advanced text books rather than provide an introduction for the interested and intelligent reader who is not an expert in the particular sub-field. Technical experts in such fields do not tend to be particularly good writers of English at the appropriate level. I don't know that there is much we can do about this apart from edit articles to improve the situation. Phil Bridger (talk) 18:03, 30 December 2019 (UTC)[reply]

Thank you for your encouraging comments. Looks like I’ll start editing leads for readability. Urbanist27

There are sometimes tags at the tops of articles saying things like "This article needs additional sources for verification". I am sure I have, on occasion, seen tags saying something to the effect of "This article's introduction may not summarize its key points clearly" - if the introduction is unclear, this tag could go at the top of the article. Vorbee (talk) 09:02, 31 December 2019 (UTC)[reply]

The relevant templates are listed at Wikipedia:Template messages/Cleanup#Introduction. Of course, if you have the time and ability to fix things yourself, and wish to do so, it is better to do that, but the templates should prompt someone else to do so eventually (maybe after many years) if you do not. Phil Bridger (talk) 09:49, 31 December 2019 (UTC)[reply]