Jump to content

Wikipedia:Village pump (policy)/Archive 162

Add links
From Wikipedia, the free encyclopedia
< Wikipedia:Village pump (policy)

This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 01:30, 12 January 2021 (Archiving 2 discussion(s) from Wikipedia:Village pump (policy)) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Village pump (policy) archive  

This page contains discussions that have been archived from Village pump (policy). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX, AY, AZ, BA, BB, BC, BD, BE, BF, BG, BH, BI, BJ, BK, BL, BM, BN, BO · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198

RfC: Should we move WP:ONUS to WP:CONSENSUS?

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is an overwhelming consensus against this proposed change, primarily due to concerns that it would undermine verifiability and efforts to remove poorly sourced information. (non-admin closure) (t · c) buidhe 03:47, 29 November 2020 (UTC)


Should WP:ONUS link to a new section at WP:CONSENSUS § Achieving consensus#Onus to clearly define Onus as applying to new additions, removals, and modifications?

WP:V § Verfiability does not guarantee inclusion would remain virtually unchanged. 04:29, 1 November 2020 (UTC)

New section under WP:CONSENSUS § Achieving consensus

Onus

Shortcut
"WP:ONUS" redirects here. For "Verifiability does not guarantee inclusion", see WP:VNOT.

The onus to achieve consensus for changes to longstanding content is on those seeking the change (but verifiability does not guarantee inclusion).

For the analogous sanction, see the Consensus required restriction.

Diff adding Onus to WP:CONSENSUS

Current text of WP:V

Verifiability does not guarantee inclusion

Shortcuts
"WP:ONUS" redirects here. For the responsibility to demonstrate verifiability, see WP:BURDEN.
See also: WP:UNDUE, WP:PAGEDECIDE, WP:PRESERVE, WP:SUMMARY, and WP:IINFO

While information must be verifiable to be included in an article, not all verifiable information needs to be included in an article. Consensus may determine that certain information does not improve an article, and that it should be omitted or presented instead in a different article. The onus to achieve consensus for inclusion is on those seeking to include disputed content.

Proposed change to WP:V

Verifiability does not guarantee inclusion

Shortcut
"WP:VNOT" redirects here. For the onus to achieve consenus for disputed changes, see WP:Consensus § Onus.
See also: WP:UNDUE, WP:PAGEDECIDE, WP:PRESERVE, WP:SUMMARY, and WP:IINFO

While information must be verifiable to be included in an article, not all verifiable information needs to be included in an article. Consensus may determine that certain information does not improve an article, and that it should be omitted or presented instead in a different article. The WP:ONUS to achieve consensus for inclusion is on those seeking to include disputed content.

Added underlined text to WP:CON#Onus proposal. Kolya Butternut (talk) 15:43, 1 November 2020 (UTC)

Survey (onus)

It appears that there is still no consensus on the interpretation of ONUS, so these policies will still need to be clarified in the future even if this proposal is rejected. The interpretation shared by at least Bradv and I is different than others. Kolya Butternut (talk) 11:42, 14 November 2020 (UTC)
  • Oppose. Wikipedia's quality comes just as much from what we keep out as from what we let in. This proposal results in making it much harder to keep some things out. It significantly changes the meaning of WP:ONUS from 'if content doesn't have consensus, it doesn't stay' to 'it has to stay unless we get a consensus to remove it'. It thus makes it much harder to ever remove existing material, and this is a problem because there are very many low-traffic, low-scrutiny articles out there, along with very many WP:POV and WP:Fringe theory pushers. So, here's a scenario to ponder:
    You stumble upon an obscure article on a topic you are familiar with. You notice some content that has sources but that is in some way fringe (synthesis, poor sources, misuse of sources, or some combination thereof), and/or that is undue emphasis on some POV, and remove it. Some editor, either the content's WP:OWNER or someone who happens to have it on their watchlist but doesn't know the topic well, reverts you because you "removed sourced content" and it looked fine to them, and says that per WP:ONUS (the new version being proposed right now), you need to get a full-on consensus to get it removed. (Likely, a new or irregular editor would give up at this point.) Yes, there are ways to do so, but they may not get enough attention to develop a new consensus for removing the material, and even if that did happen, this alternate version of ONUS made it much harder to do so.
    The current setup of everything is fine and does not need changing, because it works. "Don't fix what ain't broke." As these policies are at the heart of what we do, any changes must have very good reasons for them, and there is no evidence that this policy needs changing. Crossroads -talk- 05:36, 1 November 2020 (UTC)
  • The proposal does not result in making it harder to keep things out; the proposal is clarifying what ONUS already means -- otherwise ONUS contradicts WP:NOCON.
  • It significantly changes the meaning of WP:ONUS from 'if content doesn't have consensus it doesn't stay'; the proposal doesn't change this; it clarifies that content which has achieved WP:IMPLICITCONSENSUS (linked from "longstanding") needs consensus to be removed.
  • "[R]emoved sourced content" is not a policy-based reason to restore content; the purpose of WP:VNOT is precisely this. Your interpretation makes it much easier for POV-pushers to make articles POV by removing content.
  • "Removed longstanding content" is not a basis to restore content and the proposal does not change this; we should cite a policy besides consensus when restoring content.
  • The proposal does not change that obviously unverifiable content may be removed without seeking consensus. Kolya Butternut (talk) 12:00, 1 November 2020 (UTC)
If ONUS contradicts WP:NOCON - of which I am not totally convinced - the solution is not to change a content policy but instead to reinstate this edit by WhatamIdoing which clarified NOCON and which stood for weeks until reverted by you.
As for POV pushers, POV problems more often come from WP:Undue weight on material describing a certain POV, with the solution being removal of the excess, rather than the other way around. And in cases where the removal is POV, it is easy to find a consensus in favor of the material, because editors readily revert such bad faith removals.
Content which is "obviously unverifiable" is easily removed by WP:BURDEN; a less obvious problem is content that is superficially verifiable but otherwise unencyclopedic (misrepresents sources, original research by synthesis, undue weight, etc.). In cases where there is not a consensus for material, it should stay out, lest the encyclopedia accumulate garbage. We do not privilege material just for happening to lack scrutiny and sticking around for a while. Crossroads -talk- 22:57, 1 November 2020 (UTC)
You said "editors readily revert such bad faith removals"; by the same token, editors could "readily revert such bad faith additions", so any text which is longstanding must have implicit consensus. I don't know that that's how we should be arguing this. The edit by WhatamIdoing seems to say: In discussions of proposals to add, modify or remove material in articles, a lack of consensus commonly results in retaining the version of the article as it was prior to the proposal or bold edit. However...When the dispute is about whether to include something, [The onus to achieve consensus for inclusion is on those seeking to include disputed content]. That does not clarify things for me. Kolya Butternut (talk) 23:24, 1 November 2020 (UTC)
Editors can readily revert bad additions, yes, but that often does not occur. Think about how huge the encyclopedia is and how little-scrutinized most of it is. Most passing editors are not too familiar with a topic and are biased toward letting through (or not bothering with) something that looks superficially okay. So, some bad material sticks around for a long time and was never reverted, even though in an ideal world, it would have been reverted when it was added. As for "any text which is longstanding must have implicit consensus", in many cases this is only in a very weak type of consensus, per WP:CONLEVEL, such that once someone shows up to challenge it, there can no longer be said to be consensus for it. Changing this is bad, as has been explained. Crossroads -talk- 23:54, 1 November 2020 (UTC)
  • Oppose per Crossroads. Anything can be gamed and people should not make a habit of removing text because they can. However, the point of ONUS concerns what should happen if someone removes an assertion saying that there is no citation or that the source is not reliable. Another editor should not restore the assertion merely on the basis that it has been there a long time. The person removing text does not have to prove that the text should be removed. The onus is on the person restoring the text to say why it should be restored (that is, explain how WP:RS + WP:DUE + any other relevant policies/guidelines are satisfied). That is similar to WP:BURDEN, but BURDEN relates to "Responsibility for providing citations" while WP:ONUS relates to "Verifiability does not guarantee inclusion". Johnuniq (talk) 06:27, 1 November 2020 (UTC)
  • Oppose per Crossroads. The proposed changes would significantly weaken the verifiability policy by prioritizing the length of time a claim remains in an article over whether the claim is actually supported by reliable sources. — Newslinger talk 06:34, 1 November 2020 (UTC)
  • Oppose. See Appeal to tradition. Verifiability is more relevant than age. --Hob Gadling (talk) 07:38, 1 November 2020 (UTC)
  • Oppose Elevates process over content quality and will only increase the friction faced by editors improving content, when faced by POV-pushers playing the "you didn't notice my edit for several weeks so I have consensus and a mighty discussion must ensue" card. Alexbrn (talk) 11:41, 1 November 2020 (UTC)
  • Oppose For all the reasons expressed above.Slatersteven (talk) 11:12, 1 November 2020 (UTC)
  • Oppose: They way we are doing things now is not broken and does not need to be fixed. --Guy Macon (talk) 13:28, 1 November 2020 (UTC)
  • Oppose The proposal contains two different things in it and so is mal-formed. The general idea of shifting process issues from wp:ver to the correct place (WP:Consensus) is a good one, though, but it would take several different steps of changes to do that successfully. This would also force clarifying the pseudo-conflict between the two policies in that area. North8000 (talk) 13:29, 1 November 2020 (UTC)
  • Oppose Whenever the "longstanding" content was first added, it was the ONUS and the BURDEN of the editor(s) adding to comply with content-policy-informed-consensus (even when as is usually the case, it was not discussed, at the time it was added). The ONUS and the BURDEN never shifts, it remains always with the pro argument. In many cases, consensus within policy/guideline is and will be easily achieved and in others more difficult, but the burden and the onus remain on the side that wants the content to be/stay in the article to demonstrate it is within policy/guideline consensus. --Alanscottwalker (talk) 13:36, 1 November 2020 (UTC)
  • Oppose The only thing I have to add beyond what is already above is ONUS applies in the specific case where the content is reliability sourced. If long standing content is poorly sourced then other parts of WP:V and/or RS etc apply. Springee (talk) 13:54, 1 November 2020 (UTC)
  • SNOW Oppose. I genuinely don't wish to denigrate the OP here, but this is quite possibly the biggest non-starter of a policy revision (and the most poorly-considered in terms of the massive negative implications to the project if it did somehow pass) that I have seen here in many years. It would drastically alter (or indeed, outright turn on its head) the basic operation of one this project's most fundamental editorial principles, with implications that are more or less impossible to overstate--it would 1) essentially cripple WP:V in a majority of editorial contexts in which disputes take place, 2) basically reverse the meaning of a common community policy term that editors are used to invoking in a particular fashion (creating massive confusion and issues wherever it is employed, project-wide), 3) make any problem subject matter even more prone to intractable dispute and POV pushing unfathomably more difficult to work in and to remove problem content from, and 4) just generally degrade the quality of our content and the efficaciousness of our processes, making pretty much every kind of editing (in virtually all subject areas) more of a chore, with more subjective bickering and more obstinate, entrenched opposition using the new read on the rule as a pro forma excuse to stonewall to keep content in (or protected from alteration) even where WP:V or another principle policy clearly indicate the opposite approach. Honestly, if someone just outright suggested we just drop WP:V as policy in it's entirety, it would be only be marginally more of a monumentally bad idea. Snow let's rap 15:07, 1 November 2020 (UTC)
Perhaps my proposal was unclear? It is not meant to change anything, only clarify. I read your comment a few times and I don't see an explanation for how it would cripple WP:V and reverse the meaning of ONUS. WP:ONUS will direct to a new section which essentially means the same thing. We could have both WP:VNOT and a new WP:ONUS mirror each other: WP:V states "V does not guarantee inclusion; the ONUS is on those who seek inclusion to achieve consensus", WP:CON#ONUS could state: "The onus to achieve consensus is on those seeking the change, but V does not guarantee inclusion." I added this line to the proposal. Kolya Butternut (talk) 15:29, 1 November 2020 (UTC)Kolya Butternut (talk) 15:48, 1 November 2020 (UTC)
  • Oppose – either this proposal fundamentally undermines our verifiability policy by shifting the onus onto those who want to remove information in certain situations, or it accomplishes nothing other than retargeting a long-standing project-space redirect used in countless talk page discussions and edit summaries. Either way, this is a bad idea. All ONUS says is that just because something is verifiable, that doesn't mean we have to include it. That's a pretty straightforward concept. – bradv🍁 15:59, 1 November 2020 (UTC)
Bradv, what about where IMPLICITCONENSUS functions in the consensus-building process? My proposal was meant to be consistent with your comment here.[1] Kolya Butternut (talk) 18:13, 1 November 2020 (UTC)
In that discussion I was commenting on people misusing ONUS to make demands of other people during the consensus-building process. I know it's somewhat popular to cherry-pick this one line out of the verifiability policy and use it to prevent changes to articles, but that usage is based on a misunderstanding of how our policies work. Verifiability governs content, the consensus policy governs editor conduct. WP:ONUS belongs to the former. – bradv🍁 18:39, 1 November 2020 (UTC)
Bradv, ok. Is there a way to clarify all of this? From my limited experience, that cherry-picked line is almost always what people cite ONUS for, and there's no agreement that the status quo ante remains when longstanding text is challenged by revert. NOCON and the sentence from ONUS seem to contradict, and QUO is only an essay. Kolya Butternut (talk) 18:52, 1 November 2020 (UTC)
They don't contradict – they're talking about different things. Content policies govern what our articles can say, conduct policies govern how we behave, collaborate, and make decisions. The ONUS section is a reference from a content policy to a conduct policy – it says that just because something is allowed according to the content policy doesn't mean it has to be included. And then it refers the reader to the relevant conduct policy describing how we make that decision. – bradv🍁 19:04, 1 November 2020 (UTC)
Bradv, I agree with all of that; it just appears that they contradict. Because the last sentence, "the onus to achieve consensus" describes behavior, I thought the word onus should link to consensus, but which word we use isn't what matters. Is there text in WP:CONSENSUS which already explains the procedure from that sentence from ONUS? NOCON is the only thing that seemed close to me. Kolya Butternut (talk) 19:20, 1 November 2020 (UTC)
WP:CONSENSUS is already linked within WP:ONUS. The whole page describes how we decide what information to include in an article. There isn't just one proscribed procedure – consensus is determined through discussion. – bradv🍁 19:38, 1 November 2020 (UTC)
  • Oppose. And, really, any notion that a person can come along and remove whatever they want and then others have to justify why that material should stay is not quite accurate. Besides vandalism being an obvious case that we don't tolerate, we do get people removing material on an "I don't like it" basis. And we can often simply revert and pay those people no mind. Yes, via an edit summary or on the talk page, we may cite a policy or guideline about why they are wrong. But it's often that the content will not need to stay removed while we argue our case about why it should be retained. And when a proper dispute resolution channel is taken, these people usually will not get their way. Frankly, it is a waste of time justifying "why that should stay" in those cases.
  • The words "it has to stay unless we get a consensus to remove it" are mentioned above. We already engage in this practice. WP:Consensus can change is also a policy. Material that has had consensus in the past may need a new consensus today to get it removed. Content is restored all the time for discussion, with editors often citing WP:BRD or WP:STATUSQUO; both aren't policies or guidelines...but they temper edit warring. Articles are sometimes full-protected until a consensus is reached about whether the material in an article should be removed. Again, it's not like it's automatic that a person can simply come along, remove content while citing WP:ONUS and the content gets to remain removed just because that person said so, or until that person is satisfied with a new version of it, or until others say it should stay. WP:PRESERVE is also a policy, and it states, in part, "as any of the facts or ideas added to an article would belong in the 'finished' article, they should be retained if they meet the three article content retention policies: Neutral point of view (which does not mean no point of view), Verifiability and No original research." Editors are supposed to have valid reasons for removing material. The "just because that person said so, or until that person is satisfied with a new version of it, or until others say it should stay" type of thing does happen, but it's far more justifiable in the case of BLPs...per WP:BLP. Flyer22 Frozen (talk) 00:02, 2 November 2020 (UTC)
I suggest modifying the text of the WP:ONUS proposal to reflect these compromises between the goals of different policies and guidelines. Knowledge Contributor0 (talk) 11:44, 5 November 2020 (UTC)
Knowledge Contributor0, WP:NOCONSENSUS states: In discussions of proposals to...remove material in articles, a lack of consensus commonly results in retaining the version of the article as it was prior to the proposal or bold edit. This makes sense because editors may disagree over whether policies such as NPOV and DUE are violated by keeping the content or removing the content. Kolya Butternut (talk) 12:36, 5 November 2020 (UTC)
Kolya Butternut I am sorry for the mistake in the "Content Deletions/Major Modifications" point, I meant "per WP:Verifiability#Verifiability_does_not_guarantee_inclusion" at the end of the sentence which is where WP:ONUS used to point before. According to WP:Verifiability#Verifiability_does_not_guarantee_inclusion The onus to achieve consensus for inclusion is on those seeking to include disputed content.. While this contradicts the statement you quoted from WP:NOCONSENSUS regarding deletions or major edits, as others mentioned it protects content from all kind of violations to policies/guidelines e.g. WP:BURDEN, WP:OR, WP:POV, WP:Fringe ... etc. Violation of a policy/guideline that is supported by a group of users cannot result in removal of content unless WP:Verifiability#Verifiability_does_not_guarantee_inclusion is invoked. In summary "no content" is better than "disputed content" as the reader expect WP:CONSENSUS not a certain point of view. Knowledge Contributor0 (talk) 09:57, 6 November 2020 (UTC)
You just created your account on October 11,[2] so you may not realize that removing content can also make an article violate POV and DUE. Obvious Fringe will be removed quickly. Kolya Butternut (talk) 11:50, 6 November 2020 (UTC)
The problem is the non-obvious fringe. Even outright hoaxes commonly last for many years; see WP:List of hoaxes on Wikipedia. Material that is fringe can obviously last just as long. And I know from personal experience removing it, and researching how it got there, that it does. Most of Wikipedia lacks much scrutiny. We don't need to make it hard to remove such material. And as I said above, bad faith removals are already much more easily thwarted. Crossroads -talk- 16:54, 6 November 2020 (UTC)
There is no edit-warring exemption for disagreements over fringe material.
This is actually pretty simple; if there is a dispute which cannot be solved through editing then keep the longstanding material pending dispute resolution unless there are WP:Edit warring#Exemptions; if there is no consensus the material stays. If the material is clearly fringe consensus will come quickly. Kolya Butternut (talk) 20:07, 6 November 2020 (UTC)
Kolya Butternut I think many editors with accounts older than mine stated the same problem, so the age of my account is not a factor in discussing this situation. Removing content can't result in fringe view unless the total content after removal achieves consensus. In short any content that after thorough discussion doesn't achieve consensus or wide spread agreement should be removed at the end to avoid WP:POV and other problems. Keeping longstanding content regardless of consensus gives incentive to editors to add their fringe views early on a page on the hope that at some point it will stick if nobody contested for some time. Knowledge Contributor0 (talk) 14:04, 12 November 2020 (UTC)
What was your account before creating this one on October 11? Kolya Butternut (talk) 15:22, 12 November 2020 (UTC)
Kolya Butternut Didn't have an account before. Many many years ago used to make contributions without an account, so I have a pretty good idea of how the editing process works. All I needed was just a few weeks of refreshing about the policies and guidelines to know what changes that happened over the years I missed. Knowledge Contributor0 (talk) 11:17, 13 November 2020 (UTC)
  • Oppose. "WP:ONUS" is a rule invented and added to WP:V, which is OK, because WP:V is a core content policy. WP:Consensus is different, it is not a rules policy, but describes consensus as Wikipedians understand it. Worse, rules like WP:ONUS jar with consensus decision making, much like vote counting. Imposing a rule like WP:ONUS on a discussion is a strategy that is at odds with consensus decision decision making. --SmokeyJoe (talk) 06:16, 17 November 2020 (UTC)

Discussion (onus)

How does this relate to WP:BRD? It looks to me as if the proposed change would remove a current contradiction between BRD and ONUS, but maybe I am just not familiar enough with the rules network. --Hob Gadling (talk) 07:38, 1 November 2020 (UTC)

@Hob Gadling, I'm not sure that there is a clear contradiction between BRD and ONUS. Under BRD, which is optional (read the first sentence!) and not applicable to many situations (read the rest of it!), then either you boldly add, and both BRD and ONUS say someone can revert your addition, or you boldly remove, and ONUS says that's okay, and BRD says "Eh, BRD is optional and not always the best approach, so I guess the other guy isn't doing BRD today".
However, there is IMO contradiction between the WP:QUO/WP:NOCON approach and ONUS. According to ONUS, if you blank long-standing content (e.g., something you think is trivia), then the guy who wants to include that has to demonstrate consensus for it. According to QUO (an essay), you have to demonstrate consensus for its removal. And according to NOCON, if the subsequent discussion is a true stalemate (rare, but it happens), then ONUS says it's out and NOCON says it's in. Whether this would actually resolve that contradiction is unclear to me. (I support resolving the contradiction.) WhatamIdoing (talk) 21:57, 1 November 2020 (UTC)
As I said above to Kolya Butternut, I think the best solution to any seeming contradiction would be to simply reinstate this edit. And regardless, even though it may be (as NOCON says) that a lack of consensus (perhaps at a high-traffic article and after a well-attended discussion) "commonly results" in keeping the prior version (whatever "commonly" means), we should not mandate that no consensus for questionable but old material means it has to stay. Crossroads -talk- 23:14, 1 November 2020 (UTC)

Someone said that anything can be gamed. This is likely the case and I think it applies to the current setup as much as any other. That said, I have long objected to verified properly sourced material being too easy to remove without any good reason other than "I don't like it" and then having to go through all the hoopla to restore it. My 2 cents but I am not going to cast a "vote" on this because I probably need to be on WP another 10 years before I would understand all the procedures.Selfstudier (talk) 10:18, 1 November 2020 (UTC)

If it takes 10 years to figure out how procedures work then something's broken. We need to clarify that if content disputes cannot be solved by editing alone then the WP:STATUSQUO should be in place pending discussion, and if WP:NOCONSENSUS is reached a lack of consensus commonly results in retaining the version of the article as it was prior to the proposal or bold edit, with the standard exceptions. Kolya Butternut (talk) 12:25, 1 November 2020 (UTC)
I think my proposal should have said The onus to achieve consensus for disputed changes to longstanding content... so that it was clearly meant to mirror the existing WP:ONUS. I don't know how much that omission affected !votes. Kolya Butternut (talk) 21:22, 2 November 2020 (UTC)

BLP has exceptions: WP:BLPREMOVE requires poorly sourced information to be removed immediately. WP:BLPREQUESTRESTORE places the burden on those seeking inclusion. --Hipal/Ronz (talk) 22:17, 7 November 2020 (UTC)

WP:BLPREQUESTRESTORE sounds like it applies when editors seek to restore BLP material removed by an administrator? I'm not familiar with that, but it's under WP:BLP#Role of administrators Kolya Butternut (talk) 02:39, 8 November 2020 (UTC)

Call for Snow close... or maybe not

Obvious consensus is obvious. --Guy Macon (talk) 20:59, 6 November 2020 (UTC)

A little more time please. There is obviously no support for this proposal, but there is no consensus on the interpretation of the existing policy. Kolya Butternut (talk) 21:21, 6 November 2020 (UTC)
No problem. Would 14 November be acceptable? --Guy Macon (talk) 22:30, 6 November 2020 (UTC)
Yes, thank you. Kolya Butternut (talk) 23:00, 6 November 2020 (UTC)
About the part of the proposal that refers to "the" analogous sanction (rather than one of multiple sanctions systems), see also Wikipedia talk:Consensus required#Title and Wikipedia talk:Edit warring#WP:Consensus required link. WhatamIdoing (talk) 07:53, 15 November 2020 (UTC)
El C created WP:Consensus required and he said that the discretionary sanction can largely be seen as a more strict (binding) version of WP:ONUS[3] and both ONUS and CR are the same in so far as the burden of establishing consensus rests upon those wishing to introduce the change.[4] Regardless of whether you disagree, this wasn't my idea. Kolya Butternut (talk) 10:20, 15 November 2020 (UTC) Kolya Butternut (talk) 19:55, 15 November 2020 (UTC)
I didn't mention you at all in that comment. WhatamIdoing (talk) 19:44, 15 November 2020 (UTC)

Second call for Snow close

At fourteen oppose, on support, and one support with modifications, obvious consensus is obvious. I see no point in keeping this RfC open any longer. I don't believe in closing RfCs where I have participated, so would someone uninvolved please close this? --Guy Macon (talk) 23:06, 18 November 2020 (UTC)

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

Stale user templates

I am seeking to establish a consensus for the removal of stale transclusion of templates which are intended to be short term, from the user pages and talk pages of editors who re long-term absent.

I have in mind templates such as:

and such like, where it is clearly implausible that they apply for more than a year, or like:

where it implausible that they apply for several years (in some cases, more than a decade - yes, we have such cases); and like:

which promise a reply, when used on the talk pages of users who have been indefinitely blocked (or otherwise absent for a signifiant period), and thus mislead the reader.

Having such templates in use on pages of inactive colleagues makes it impossible to gauge the extent to which those templates are used by active editors. It also dilutes their meaningfulness for users who deploy them in realistic timeframe.

I have been told that having such templates on user pages aids the identification of sock puppets who use boilerplate page design; but they are always available in the page history for those needing to check for them.

I propose to add a note allowing such removals, to WP:TPO. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:41, 29 November 2020 (UTC)

I think there are actually two classes of templates being referenced here. {{Storm}} and {{At school}} seem to reflect this idea of "stale" use, and I would be hesitant to have these removed because of their value in establishing a history. An editor coming back to actively participate in the community after a decade may remember a user they collaborated with, and finding one of these templates on a user page would give them a good idea of what happened to this editor they remembered. It might be worthwhile to add a parameter stale=yes or even date= that enables verbiage along the lines of "This user has now been at school for over 10 years, and does not appear to be returning to actively edit Wikipedia."
On the other hand, {{Usertalkback}} doesn't suffer so much from stale usage as inaccurate usage. If an editor using this template is indeffed, it ends up functioning as active misinformation on their status. A possible suggestion would be a new template {{Indeftalkback}} that instructs users to only leave messages on their talk page or to use the email function that could replace {{Usertalkback}} or even implemented universally for all indeffed users. VanIsaacWScont 14:21, 29 November 2020 (UTC)
How does that establish a history, and how does removing such a templte differ from an editor who spends a few days in storm, and then removes the template and resumes editnig; or who does so at the end of the school term? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:26, 29 November 2020 (UTC)
The history is about the editor missing in action, not one who has come back. If they come back after a wikibreak, there isn't any mystery. It's for those editors that never come back that these templates can give other editors clues about what has happened to a fellow editor they are looking for. VanIsaacWScont 21:43, 29 November 2020 (UTC)
I would consider it better to leave these templates there and instead add some other template that says the user has been inactive since ..whenever.. Then others will get a clue that it may not be worth communicating with the inactive user, and at the same time see what triggered their absence. Graeme Bartlett (talk) 00:53, 30 November 2020 (UTC)
This is well beyond my technical abilities, but would it be possible to create a bot that places a notice at the top of talk pages of editors who have been inactive for greater than 12 months? It could even say when they were last active and be removed when (if) they make another edit. Cavalryman (talk) 01:49, 30 November 2020 (UTC).

Can we please get a wiki home for fictional topics already?

The appropriate forum for this discussion would be at Meta. (non-admin closure){{u|Sdkb}} talk 05:15, 1 December 2020 (UTC)

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

The constant afds and mergers on fictional topics are disheartening and are driving people off the project, especially since it is a vocal minority of deletionists that are doing it. Fandom/Wikia is not a suitible place as it is full of ads and gdpr violations. Wikimedia needs a project where we can have an encyclopedia focused on fictional topics that don’t need to focus on real world notability. Wikiquote is kind of there but it is only for quotes and not an encyclopedia.

A similar project is also needed for minor actors and films (a wiki imdb). 94.175.6.205 (talk) 17:53, 30 November 2020 (UTC)

A) IMDB is already a wiki. B) You may be interested in previous requests, such as meta:Wikifiction (In-universe_encyclopedia). --Izno (talk) 18:06, 30 November 2020 (UTC)
Try Everipedia or start something new, like a mega MemoryAlpha? Disagree that Wikimedia needs this. Gråbergs Gråa Sång (talk) 20:07, 30 November 2020 (UTC)
Trying to manage user-provided content on fictional topics based only on primary sources is near impossible. (See TV Tropes). It's a beast that can't be tamed, and something we've long determined that Wikipedia can't be. We can summarize fictional parts of a work, but we're not going to be having full entries on topics that have no other sourcing but the work itself. --Masem (t) 20:10, 30 November 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Support for editors with disabilities

Withdrawn. ―Mandruss ☎ 20:46, 1 December 2020 (UTC)

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

I've just attempted to answer WP:Teahouse#From WikiBlind.org folks - Is this the Help Desk for wikipedia? - somebody not I think wanting support specifically for themselves, but to know where visually impaired editors can go for support. I went looking, and was shocked, in 2020, that I couldn't find anywhere to send them. There's WP:WikiProject Disability, but that's disability-related articles; there's Disabled Wikipedians, but there's only a dozen or so people who have put themselves in there. There's MOS:ACCESS, but that's about how to edit for people with disability. There have been occasional discussions on VP about specific matters, but there's nowhere that I can find that editors who have a disability can go for any specific assistance, whether technical, or individually from willing volunteers.

I'd be happy to start a page like WP:Assistance for editors with disabilities, but I don't know much about what to put on it: I've no particular knowledge about the subject, and I don't know how to find editors with such expertise (or even better, editors with disabilities themselves, apart from the few in the category).

I've raised this here rather than at the Idea lab because I believe this should be a matter of policy, not just something that concerned editors make happen. --ColinFine (talk) 23:29, 30 November 2020 (UTC)

I'm feeling genuinely puzzled by what you're looking for. People who need help with some random thing can go to the teahouse or VPT or the help desk, the same as anyone else. For an existing group of people interested in ensuring WP:Accessibility is reasonably dated, we have WP:WikiProject Accessibility. Everything else should fall out of WP:ACCESS.... Maybe Graham87 can make an appearance. --Izno (talk) 05:03, 1 December 2020 (UTC)
Yes, exactly this. The teahouse/help desk have a wide variety of users and I've always found them helpful with random queries I've had which would be easy for a sighted person to answer but difficult for a blind person (e.g. what is this image, I think I've broken this table ... etc.). The problem with a specialised noticeboard would be getting a critical mass of people both to ask and answer questions, which given the tiny population we're serving here, doesn't seem viable in the long term to me. DrMel, if you'd asked me this privately, I would've told you exactly the same thing. Graham87 06:38, 1 December 2020 (UTC)
Re: table, it wasn't me ... and it wasn't broken. :-) Graham87 06:46, 1 December 2020 (UTC)
Agree with Graham, such a specialist help desk would very likely end up just ghettoizing the issue. The "mainstream" help venues usually work well enough. Roger (Dodger67) (talk) 10:20, 1 December 2020 (UTC)
As do I; it's better both from our point of view and the readers' that we have as low a number of helpdesks as possible, to maximise the chances that an enquiry is seen. I also don't really understand what's being proposed. A generic "disabilities" help desk makes no sense, since "the disabled" don't form a single group (someone who's an expert on screen readers for the blind is no better qualified than anyone else to comment on how to enter Wikitext markup using a one-handed chorded keyboard, how to add TimedText captioning to audio files, how to enlarge the default font without also enlarging the images so much they dominate the page, etc.) ‑ Iridescent 10:56, 1 December 2020 (UTC)
Thanks for your comments, all. I take the point about "ghettoising". What troubled me was that I expected to find somewhere to direct DrMel to that answered their question in a more helpful way than the first answer did. I did search, but didn't think of trying "accessibility" as opposed to "disability", (my unconscious ableism?) Since I couldn't find anything, I concluded that Wikipedia didn't have a policy on accessibility, which concerned me a lot. I guess this can be closed now. --ColinFine (talk) 12:54, 1 December 2020 (UTC)
In closing I'd just remark that WikiProject Accessibility is more focussed on accessibility for readers rather than editors. Roger (Dodger67) (talk) 18:20, 1 December 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Finished MOS:DIACRITICS merge from MOS:CAPS to WP:MOS

FYI

For details, please see: Wikipedia talk:Manual of Style#Finished MOS:DIACRITICS merge.
 — SMcCandlish ☏ ¢ 😼  02:00, 2 December 2020 (UTC)

See RfC on changing DEADNAME on crediting individuals for previously released works

FYI
 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Biography#RfC: updating MOS:DEADNAME for how to credit individuals on previously released works
This potentially would affect a significant number of articles.  — SMcCandlish ☏ ¢ 😼  02:21, 2 December 2020 (UTC)

Someone edited my User Page??

Someone went through my User Page and edited it. They were sort of tech or coding edits. Mainly, someone went through all my Userboxes and recoded things--also removing underlines I had in spaces between words. The result is, as far as I can tell, they way I had it looking in the first place (although I did go back in the history and look at the previous version; I found that one of them had stopped working while I had my back turned)
Oh, yeah, this someone also changed every <br/> to say <br>, without the slash.
I guess someone went through and updated coding for me, that had been changed without my realizing it. I don't know. Is it usual to go "fixing" someone else's User Page? Why do I feel just slightly violated?? Uporządnicki (talk) 02:47, 2 December 2020 (UTC)

Did you ask them about it? Natureium (talk) 02:50, 2 December 2020 (UTC)
I believe you are referring to this edit by Voidxor at User:AzseicsoK. That looks fine to me—this is a wiki where anyone can fix things. I don't know why the "User:B.D.Will/read or else" stuff is being changed but there is sure to be a good reason. Johnuniq (talk) 02:55, 2 December 2020 (UTC)
It was an AutoWiki Browser edit. It looks like all of the changes are genfixes except for the BD Will username change. I'm sure the AWB run was to update after an account name change, and it just hit every page that links to the old userspace. VanIsaacWScont 03:03, 2 December 2020 (UTC)
Well, as far as fixing things, I fix a lot of things--but I kind of figure I wouldn't touch someone's User Page. But it sounds like it's an automatic thing that goes through and updates when there are changes in the way things are coded. Uporządnicki (talk) 03:16, 2 December 2020 (UTC)

RfC: For biography leads, do we prefer recent images or images from when the subject was most notable?

Opinions are needed on the following matter: Wikipedia talk:Manual of Style/Images#Request for Comment. Flyer22 Frozen (talk) 07:07, 2 December 2020 (UTC)

Using Wikiquote as a back door for POV pushing

Vilho-Veli (talk · contribs · deleted contribs · logs · filter log · block user · block log), who seems to have made a career of adding Wikiquote links to Wikipedia articles (which is usually a Good Thing), recently added one to OpIndia.[5]

Alas, the Opindia page at Wikiquote contains a bunch of material that would be rejected if someone tried to add it to the English Wikipedia.

Example:

  • "We live in a post-truth world where the facts often get lost in the cacophony of emotional wails and motivated narratives. One website which has occupied the driver’s seat in the information-warfare era is Wikipedia. Wikipedia has become the agent of misinformation and propaganda. In a post-truth world where facts are relegated to the ‘right-wing imagination’ and the Left narrative is considered as the Gospel truth, Wikipedia reigns supreme."
23 Nov, 2018. OpIndia CEO, Rahul Roushan in Nupur Sharma, Caravan Magazine asked us about our coverage on Wikipedia and its Left bias – Here is our detailed response][6]
Note: Wikiquote allowed a link to www [dot] opindia [dot] com/2020/11/caravan-magazine-questions-opindia-wikipedia-coverage-full-response/ which I could not quote because that site is on our blacklist.

Compare that with:

By its very nature, Wikiquote is one-sided; pretty much giving free reign for an individual or organization to paint a picture with direct quotes without any inconvenient negative material.

What should we do about this, if anything? Is there some change of policy here on the English Wikipedia that would address this problem? --Guy Macon (talk) 23:04, 27 November 2020 (UTC)

Well, I don't have opinions of the texts, just inform that there's an article on Wikiquote. Others can write it better.--Vilho-Veli (talk) 23:10, 27 November 2020 (UTC)
Just to be clear, I did not mean to criticize you in any way. 99.9% of the time adding Wikiquote links is helpful and an improvement. It just happens in this case (which you had no way of knowing) that Opindia has pretty much declared war on the English Wikipedia and is using Wikiquote as an attack page. The reason I brought it up here is that if it works for them we might start to see other groups (scientologists, holocaust deniers, alt-med quacks...) use the same backdoor to get their propaganda into Wikipedia. --Guy Macon (talk) 23:20, 27 November 2020 (UTC)
Guy Macon you describe a troubling scenario, but thankfully it looks like a primarily theoretical problem. I expect approximately 0% of readers click through a Wikiquote link at the bottom of the article, making such a strategy a rather ineffective in general. Regarding the current OpIndia example, the Wikiquote link appears to have been added innocently, the opening sentence at Wikiquote identifies OpIndia as "right-wing", and the Wikiquote page appears to contain no more than an incidental passing smear against Wikipedia. I don't think anything currently needs to be done. If anyone were to actively attempt a strategy like you describe, we could consider removing the specific Wikiquote link and we could ask Wikiquote editors to consider whether the Wikiquote page was being stacked with improper content for an improper purpose. (I assume Wikiquote has some sort of policies on the subject.) Alsee (talk) 00:15, 28 November 2020 (UTC) Struck apparently-innocently part of my comment. The situation is now extremely unclear, and I am seeing significant indications to warrant further investigation. Alsee (talk) 22:48, 28 November 2020 (UTC)
The links are neutral and important. Otherwise you perhaps wouldn't have noticed the problem. The improvements should be done at Wikiquote in my opinion.--Vilho-Veli (talk) 01:27, 28 November 2020 (UTC)
I happen to be a Wikiquote admin. The site has standards for inclusion, at Wikiquote:Quotability. Pages can be nominated for deletion, and individual entries on pages proposed for removal from the page, in much the same way that such actions can be taken on Wikipedia. BD2412 T 01:56, 28 November 2020 (UTC)
I can see a plethora of problems with this. Even assuming, only a tiny minority would see the link to wikiquote and even bother clicking, it still violates the core policies on neutral point of view and that anyone can edit. I'm somewhat surprised that opindia isn't under a global blacklist after the doxxing incident. Not to mention, doesn't most of the wikiquote entry violate its specific content guidelines? Of the 6 external links in them, 5 of them are self-referential cited to themselves. The quotes as captions of images are unsourced and the entire entry displays them as some sort of glorious resistance leaders.
I don't agree that wikiquote is one-sided by its very nature, the quotes can of course be displayed in context while citing to reliable sources. Since it's a website, I assume it should include both quotes from them as well as about them? The only quote which is about the website is a sort of "challenge to the establishment". Unless this is fixed on wikiquote, it shouldn't be linked on the English wikipedia. I'm of the opinion that if the entry isn't neutral then the link isn't neutral either. Tayi Arajakate Talk 02:35, 28 November 2020 (UTC)
@BD2412:, is the above accurate? Can a Wikiquote page about an individual or organization contain quotes by other people critical of the subject? (Assuming of course that the quotes meet the other requirements). Or is a John Smith Wikiquote page only for quotes by John Smith? --Guy Macon (talk) 03:03, 28 November 2020 (UTC)
A Wikiquote page can absolutely contain quotes about the subject. Most of our pages are "about" subjects in the first place, since many of the subjects are abstractions, but there are countless examples of pages with quotes both by and about individuals (for example both q:Donald Trump and q:Hillary Clinton have quotes about the subject making up a substantial portion of the page). BD2412 T 03:12, 28 November 2020 (UTC)
Though in contrast to en.wiki, we use a measure to avoid "unduly self-serving" material. If a BLP says something about themselves, we generally only include it in en.wiki if a third-party source republishes it (there are other circumstances too). That doesn't seem to be a factor at WQ, which thus allow editors to potential include POV that's not the same as reflected in reliable sources, which seems to be the situation here. --Masem (t) 03:31, 28 November 2020 (UTC)
I initially misunderstood its guideline on avoiding self-references to mean that quotes shouldn't be solely sourced from the author. I couldn't find anything on Wikiquote which explicitly mentions this but I think quotes which have not received coverage by sources independent of the author would fail the policy on quotability going by the section on "Fame factor". Tayi Arajakate Talk 04:01, 28 November 2020 (UTC)
I don't use WQ enough but the way I read the criteria is that they are not "all must be satisfied" but that they all add to general appropriateness if a quote should be included. While the "fame" criteria is akin to how we avoid self-serving material, it doesn't appear to be a requirement for inclusion, so this would allow quotes from people or organizations which the editors of WQ feel is important to include. Which could lead to POV pushing if one wanted to go that route. Now with this specific case Opindia if they have a beef with Wikipedia and that is well known in other sources, then a few quotes to reflect that could be argued (in the en.wiki mindset) but seems very much weird at WQ as is. --Masem (t) 05:34, 28 November 2020 (UTC)
  • I'm sure that much of Wikiquote, as a smaller wiki, lacks scrutiny comparatively speaking, thereby making it easier for some of their pages to be hijacked by POV pushers. So maybe we should allow or make clear, if it isn't already, that editors on English Wikipedia can remove links to Wikiquote if our editors are concerned that a Wikiquote page has serious neutrality issues. (Of course, in such a situation, one could also try to fix it, but I can see that meeting opposition from a page's WP:OWNer, and it would be a pain to figure out how to get that addressed over there, and who knows how long it would take.) Crossroads -talk- 05:06, 28 November 2020 (UTC)
    • Wikiquote has an Administrators' noticeboard, and though things are a bit slower there (days instead of minutes for responses, and weeks instead of days to reach a resolution), these issues do get raised and resolved. I would consider removal of a Wikiquote link to be a last resort rather than an opening step. BD2412 T 06:12, 28 November 2020 (UTC)
      • Agree 100%. Links to Wikiquote are good, and Vilho-Veli is improving the encyclopedia by adding them. If someone else doesn't raise the issue on Wikiquote next week (this is a long holiday weekend for many in the US) I will do so. --Guy Macon (talk) 10:14, 28 November 2020 (UTC)
  • Well, I disagree. I am fed up of seeing indiscriminate spamming of WQ in WP articles. I have raised this issue in the past, and am fairly sure it involved the same person responsible for this latest example. Linking requires a bit of nous and if you don't have it, don't do it. It is frequently said here that care needs to be taken with using the "broken" Commons and WQ is no different. - Sitush (talk) 20:02, 28 November 2020 (UTC)
In every case wikidata links.--Vilho-Veli (talk) 20:25, 28 November 2020 (UTC)
Not true, unless things have changed in recent months. There have been lengthy discussions about how a small group of people have been trying to impose the poorly controlled WD on WP. Which seems to be exactly what you are doing with WQ. I remember now, though, that it was RistoHot sir who I previously noted as spamming, and their command of English also didn't always aid their judgment IIRC. I can't really check stuff easily on mobile, sorry. - Sitush (talk) 20:46, 28 November 2020 (UTC)
I see Risto hot sir (talk · contribs) was blocked for socking. I am fairly sure they were from Finland, as you say you are V-V. Can you please save us all some time here and confirm that you are not them? - Sitush (talk) 21:00, 28 November 2020 (UTC)
And this from 2018 is interesting. - Sitush (talk) 21:03, 28 November 2020 (UTC)
Look, I'm really not interested whether you keep the links or not.--Vilho-Veli (talk) 21:08, 28 November 2020 (UTC)
Then why add them? Still waiting for your confirmation, BTW. - Sitush (talk) 21:10, 28 November 2020 (UTC)
I have boldly removed the WQ link per Vilho-Veli's indifference to it stated above, and pending some sort of discussion outcome at WQ. - Sitush (talk) 21:59, 28 November 2020 (UTC)
I have also just removed their recent addition at 1998 Coimbatore bombings, which has similar issues of backdoor pov pushing. - Sitush (talk) 22:19, 28 November 2020 (UTC)
SPI now filed under the name of Risto hot sir. See [7]. - Sitush (talk) 22:44, 28 November 2020 (UTC)
@Guy Macon and Sitush: I am still waiting for any editor involved in this discussion to raise an issue at Wikiquote. There are numerous venues there where asserted deficiencies in a page of quotations can be addressed. BD2412 T 22:57, 28 November 2020 (UTC)
I think Guy M said they would raise it if no-one else does. I have no desire to get involved with WQ policies/bureaucracy etc because I consider it to be a project beyond redemption, sorry. - Sitush (talk) 23:00, 28 November 2020 (UTC)
Wikiquote is no more "beyond redemption" than Wikipedia. Both face the same issues of vandalism and POV-pushing, and both respond to them to the extent that participants have the bandwidth to contribute to that effort. Wikiquote also has some excellent content, including very good work calling out misattributions (see, e.g., q:Benjamin Franklin and q:Mark Twain), and thoroughly cataloguing the most notable quotes on basic topics (e.g., q:Peace and q:Fishing). BD2412 T 23:18, 28 November 2020 (UTC)
I wasn't expecting you to agree with me, merely telling you why I am not raising the issue there. - Sitush (talk) 23:21, 28 November 2020 (UTC)
Re: "I am still waiting for any editor involved in this discussion to raise an issue at Wikiquote", I intend to do so on Tuesday. That will [A] give this thread time to let everyone have their say, and [B] be past the long holiday weekend in the US. None of this is an emergency that needs to be dealt with today. --Guy Macon (talk) 03:41, 29 November 2020 (UTC)
Just as a general suggestion, en.wiki should not be including links to Wikiquote automatically unless we are talking about a topic that has well been out of the news (and thus "stable") for many decades (eg wikiquotes of anyone pre-1950 should be reasonably fine). For newer topics - particularly ones that we know are playing into any type of long-term controversial area, inclusion should be based on general consensus that the WQ page is adding valid material for the en.wiki page. --Masem (t) 06:31, 29 November 2020 (UTC)
The devil would be in the detail. It takes no time at all for a pov pusher to "turn" an article. On WP, there is often scrutiny to a much greater degree than on WQ but it could mean having repeatedly and frequently to scrutinise the WQ entries from the WP article and get to grips with another set of policies etc. If WQ were akin to a dictionary of quotations, ordered in the traditional manner under the name of the person being quoted, then it would be much less of an issue. But instead it is often quotes assembled by subject and the scope for meaningfully disruptive changes is much higher, eg for subjects related to Indian castes even in a fairly tangential way. The likes of James Tod are long dead but the scope for creating a significant POV is considerable. - Sitush (talk) 10:13, 29 November 2020 (UTC)
Given this and the amount of spamming that goes on, might it be better to say that WQ links should be "opt in" consensus rather than "opt out"? Would that help at all? - Sitush (talk) 10:24, 29 November 2020 (UTC)
Every article in Wikipedia is subject to potential spamming. Why not make all links subject to "opt in" consensus, on that basis? BD2412 T 17:25, 29 November 2020 (UTC)
absolutely agree with "opt-in" consensus. My brief look at NY Daily News on WQ concerned me (and WQ link likely should be removed from their en.wiki page) because the only connection to NYDN was publishing the Op-ed containing the quote. That standard of inclusion could be problematic in the BLP and other controversial topic areas.
Not sure if policy treats it this way, but interwiki links are a little more sacred than external links for the reader. They are seen as continuing the dialogue in wikipedia.
I also wonder if a transclude of specific, notable quotes would be better for readers than the blind link currently used. Slywriter (talk) 17:30, 29 November 2020 (UTC)
Every article in Wikipedia is subject to potential spamming. Why not make all links subject to "opt in" consensus, on that basis? But that is the consensus for WP:External links. Our default without a consensus is "no link". --Izno (talk) 17:39, 29 November 2020 (UTC)
Most external links do not contain content that can be edited by Wikipedians. If you can edit here, you can edit at Wikiquote, and address whatever problems are perceived to exist on the corresponding Wikiquote page. It would be rather absurd for us to get to a point where we can't automatically link pages like Thomas Edison and q:Thomas Edison, or Hesitation and q:Hesitation, or Smile and q:Smiles. BD2412 T 01:50, 30 November 2020 (UTC)
Not a persuasive argument.
1. Wikiquotes standards appear to be lower than En-wiki. Whether that's a function of the project's standards or limited userbase, it still stands that potentially irrelevant quotes are added and survive.
2. Adding wikiquote blindly to pages means that editors now need to monitor a secondary project to ensure readers are getting proper information
3. A generic link that says "wikiquotes has quotes related to: X" adds limited value to the page especially when the quotes may be about the person, may be tangentially related or in the case of prominent people like Donald Trump include a laundry list of quotes and then a section of quotes about DJT which are just a kitchen sink inclusion of everything someone said about DJT that some editor felt NEEDED to be captured. Joe Biden's page is no better.
4. The more I dig, the more I see WQ is absolutely a dumping ground for POV quotes with almost no curation.
5. The WQ project is great for collecting quotes but it seems to be a place an editor would go to find more information and potential new sources, not a place to direct a reader looking to learn more Slywriter (talk) 02:34, 30 November 2020 (UTC)
Most external links do not contain content that can be edited by Wikipedians. - sources cannot be edited by Wikipedians either. Why is this alleged "feature" of WQ important when they can edit Wikipedia provided they comply with its policies and guidelines? WQ seems to have virtually no content policies that are meaningfully enforced. As with anything, if enough exists then some bit, somewhere, will have some merit ... but that doesn't mean it is a generally meritorious thing. Slywriter's opinion coincides with mine but is far better expressed. WQ is everything WP:QUOTEFARM would seem to deprecate but we seem to accept it, absolving ourselves by passing the reader to another bit of the WMF universe and indeed enshrining that with a mention of it in QUOTEFARM itself. - Sitush (talk) 05:43, 30 November 2020 (UTC)
Of course Wikiquote does not abide by WP:QUOTEFARM, in the same way Wiktionary does not abide by WP:DICDEF and Wikisource does not abide by WP:NOTREPOSITORY. These are the functions each project fulfills within Wikimedia. Did you know that Wikiquote was one of the first Wikimedia projects to be created after Wikipedia itself? Or that it incorporates the content of a half dozen public domain compilations of quotations on a variety of themes? A substantial proportion of Wikiquote pages reflect mostly this curated content. I would also note that Wikiquote has fewer than 39,000 pages, compared to Wikipedia's 6.2 million articles. It would be trivially easy for Wikipedians to address the relatively small proportion of actually problematic Wikiquote pages. BD2412 T 06:17, 30 November 2020 (UTC)
The onus for fixing WQ does not lie with WP contributors. - Sitush (talk) 06:41, 30 November 2020 (UTC)
And my point about QUOTEFARM was not that WQ should abide by it but that by pointing WP readers to WQ we are sending them to exactly the sort of mess that we want to avoid here. Yes, I am sure that there are a few decent articles at WQ but just clicking the Random Article link there, plus the detailed India stuff I have mentioned, tends to confirm what Slywriter has said - it is mostly useless to the general reader who has travelled from a WP article. - Sitush (talk) 14:43, 30 November 2020 (UTC)
I should add that it bothers me just how many WQ articles comprise little more than quotes of notorious figures such as Koenraad Elst and David Frawley with seemingly little context except a link to their bio. Perhaps this is normal - does the same apply for, say, David Irving? - Sitush (talk) 06:05, 30 November 2020 (UTC)
I raised some of this at WQ Village Pump. The "moderation team" is apparently small and both exhausted and confused with what are actually blatant attempts to promote Hindu nationalism and Islamophobia across a large number of articles even after specific accounts have been reported. - Sitush (talk) 13:25, 30 November 2020 (UTC)
Yikes, the list of the articles on WQ created by the sock/tag-team is an impressive exercise on POV pushing. I checked out a few of them and all of them had serious neutrality issues, a bunch of de-contextualised cherry-picked quotations. I was thinking of venturing into that project but now that the extent of the damage is put into perspective, we probably need a blanket removal of their contributions for starters.
In any case, I'd support a free hand to remove WQ links from WP pages at this point. Tayi Arajakate Talk 14:09, 30 November 2020 (UTC)
I happen to have personally created over 1,300 Wikiquote pages, primarily seeded with quotes from curated public domain collections, and in each instance I have added these to the corresponding Wikipedia article. In fact, in some instances, I have created articles on Wikipedia to correspond to topics or individuals for which there were collections of quotes. Is there any basis to remove links to Wikiquote in articles like those? BD2412 T 17:51, 30 November 2020 (UTC)
I assume one would have to provide some reason to remove a WQ link and that the addition of unproblematic WQ links wouldn't be contested in the first place. There are too many articles on WQ which do have neutrality issues so I can't support making it more difficult to remove links. If there is a dispute over inclusion or not of a WQ link then they can be treated as akin to how we treat other verifiable material à la WP:ONUS. Tayi Arajakate Talk 05:37, 1 December 2020 (UTC)

I'm with Masem: we should err on the side of not including Wikiquote links and primarily consider them for older subjects. At a most basic level, we shouldn't allow Wikiquote links in BLP because Wikiquote does not have the same BLP requirements. My main experience with Wikiquote POV pushing was a few years ago now, but the problem is still there. After Khizr Khan came to prominence, a bunch of extremist conspiracy theory sites started going through his old law journal publications and cherry picked some quotes to build conspiracy theories on (that he wants to impose Shari'ah law in the United States, that he's a secret Muslim Brotherhood agent, etc.). We kept those quotes out of the Wikipedia article, of course, because they fail to come anywhere close to our BLP and RS standards, but there they sit at his Wikiquote page. When I brought this up in the past, there was never any appetite to remove it as it technically didn't violate any Wikiquote rules once he had been determined "quotable". — Rhododendrites talk \\ 15:27, 30 November 2020 (UTC)

  • I would agree to not add wikiquote links to wikipedia. A while ago I found that after a user failed to push their POV on an article, Vilho-Veli soon after added a wikiquote link where someone had pushed the exact same POV in a similar time frame (I tried documenting the similarities here). I was then shocked to learn how lax the standards are at wikiquote, where basically anything goes. I agree with backdoor concerns. Only silver lining is that most readers wouldn't click on it.VR talk 04:32, 1 December 2020 (UTC)

There seems to be a consensus so far that something needs to be done because WikiQuote has issues which are incompatible with Wikipedia's ethos. It is also evident that these issues have been raised at WQ previously and there has been no appetite at WQ to address them. That may change in time but we have to deal with the here and now. - Sitush (talk) 07:46, 3 December 2020 (UTC)

Update

Vilho-Veli has not only been been sock-blocked,[8] the account has been Globally locked[9] and a swarm of other sock accounts are either already globally locked or soon to be globally locked. WP:ROLLBACKUSE #4 appears to invite reverting their edits. Alsee (talk) 06:22, 29 November 2020 (UTC)

And now a new account created by the same person has been blocked here, although the folks at WQ don't seem to be concerned that the account is active there. [10]. - Sitush (talk) 16:06, 2 December 2020 (UTC)
Please provide diffs to support the assertion that "folks at WQ don't seem to be concerned" about that account. BD2412 T 15:59, 3 December 2020 (UTC)
I raised it at WQ Village Pump and nothing was done. I don't particularly want to go back to that cesspit any time soon. - Sitush (talk) 16:18, 3 December 2020 (UTC)
Your comment above links to User:Minä muka. I see no instance of you raising any concern about that user on Wikiquote. If I am mistaken, please provide the diffs. BD2412 T 19:50, 3 December 2020 (UTC)

Note:I've struck all the comments from User:Vilho-Veli which were made in violation of their previous block. Tayi Arajakate Talk 18:51, 2 December 2020 (UTC)

Is disambiguation appropriate for puns?

This came up in 2019 with respect to Shepard's Citations and Sherardizing (which I opposed and still oppose) and more recently, I was thinking about this when I attempted to set up disambiguation between Iran (disambiguation) and I Ran (So Far Away) (and then decided to take the question here first). Is disambiguation appropriate between article titles that are or could be misheard as puns on each other? If there's a policy or guideline on point that I'm unaware of, please let me know. --Coolcaesar (talk) 23:56, 5 December 2020 (UTC)

The test is, does the disambiguation help? Variations of "I ran" and "Iran" probably belong in the "see also" section of each other's disambiguation pages. Unless the pun is common or there is another reason to think people might mix the terms up, "Shepard" and "Sherard" are different enough in meaning, pronunciation, spelling, and keyboard-key location that it's quite unlikely to cause confusion. On the other hand, if some comedian has made this part of his gag, and the mix-up has entered the popular culture, then yes, a disambiguating hatnote may be warranted. davidwr/(talk)/(contribs) 00:20, 6 December 2020 (UTC)
I can't remember the specific articles right now, but there is a pair of articles with similar sounding titles that (last I knew) have hatnotes to each other. Not remembering the topics makes it very hard to dig up, though. Chris857 (talk) 02:04, 7 December 2020 (UTC)
I don't think we should do this for puns specifically, unless the pun itself is well documented as a standalone/its own section and needs a redirect/disambig. But, not being an expert in this area, there is a question related to accessibility (eg if a blind user using speech-to-text conversion wants to search on "I Ran" the song, should "Iran" account for the close verbal match? This I don't know at all or how many cases it would be. --Masem (t) 15:28, 7 December 2020 (UTC)

Linking to Wikidata from lists of artworks

Last couple weeks I am working on List_of_woodcuts_by_Albrecht_Dürer. Most of the work is cleaning and organizing several thousand files on Commons and unifying, checking and cleaning data on Wikidata. It is still work in progress as I still run into woodcuts on Commons and in Wikidata not on the list. However I run into rather shocking issue, apparently as I was informed we are no longer allowed to link from articles to Wikidata, as I did using {{Wikidata icon}}. I am linking to wikidata as there is a ton of additional information about each print, like all the sources and references needed to verify the correctness of the information, links to commons categories for each woodcut, list of museums that have them, etc. Reading more I learned in Wikipedia:Templates_for_discussion/Log/2018_January_16#Template:Wikidata_icon that the current preferred method is use {{Interlanguage_link}} template to link to wikidata. I changed the article to use the template, but now the page takes 7 seconds to load since I have "394 expensive parser functions", which I guess are calls in the template to see if wikipedia page exists. I think the version of the page with {{Wikidata icon}} looks much better (see here) than the current version, without all the red links. Is there some better way to link to the source data on Wikidata without those ugly redlinks? I have seen [] links used with URLs at some pages like List of paintings by Camille Pissarro, but I also think that is ugly. --Jarekt (talk) 23:36, 11 November 2020 (UTC)

I'd like to be more sympathetic, but really the extra information on wikidata is so useless it isn't worth making a fuss about not being able to link to the wikidata pages. The ones I looked at listed 3 or 4 museums (all American or German it seems), when few of Durer's woodcuts are really rare, & the great majority will be in several dozen museums, in some cases over a hundred I expect. I didn't see either the British Museum or the Albertina, which must both have all but complete collections. Likewise the Metropolitan in NY. The odd few catalogues listed will mostly contain almost all the prints, that's the point of them. The more useful ones, especially for English-speakers, were not listed. Better to summarize all this on the list page here. The Commons categories (in the usual Commons mess) should be findable by clicking a couple of times on the images. Johnbod (talk) 00:16, 12 November 2020 (UTC)
It is not useless if you are trying to figure out which source thought the work was created at what date or which thought it was made by Durer and which by his school. Everything in that table come from Wikidata, and per Wikipedia:Verifiability we should be able to follow the sources and be able to verify it or at least see where the information come from. --Jarekt (talk) 03:43, 12 November 2020 (UTC)
There's no reason not to do that by normal footnotes - how many sources have been using? Wikidata isn't really suitable for that sort of thing. It doesn't really tell you that as the links don't take you to the catalogues. Normally it's more like none of the sources are sure, within a year or two. Btw, i get a warning on all the NGA links - via "purl.org" - what's that? Johnbod (talk) 03:46, 12 November 2020 (UTC)
Johnbod, In my experiencea lot of URLs are still OK even a decade after adding them, and the one which are dead often can be found in Wayback Machine. There is even some bot which scrapes all the URL from Wikimedia projects and adds them to Wayback Machine catalog and replaces dead ones with URL to archived pages. About the warnings about purl.org: I do not what that is all about Those URL's were added by "Digital Projects Coordinator" of NGA. They gave me less issues if I change https to http in the URL. As for adding sources to footnotes that would be a BIG task to scrape 300-400 wikidata pages and figure out which fact is supported by which source. A date or an author might have several sources. If I get 3 sources per woodcut that would be over thousand sources to be added to the article. A simple link to a single wikidata page with all the sources for each woodcut seems much simpler and cleaner solution. That is, I think, why we have almost no artwork level sources in any of the "list of artworks" articles. And the last thing I would like to do would be to invest my time to add artwork level sources, just so they are all removed by the next user because they violate some mostly undocumented "policy", like what happen to the article I was improving. --Jarekt (talk) 20:15, 12 November 2020 (UTC)
You miss my point, I meant (and said, I thought) that none of the sources are sure of the date a work was produced, within a year or two. I'm going to copy most of this discussion to talk at the Durer list, before it vanishes into the archives. Johnbod (talk) 15:59, 19 November 2020 (UTC)
Yes most sources have different opinion about approximate dates. Sometimes even the same institution or the same author in different publications. --Jarekt (talk) 03:37, 20 November 2020 (UTC)
Jarekt, in terms of relevant guidelines, mainspace links to Wikidata usually fall under Wikipedia:External links. You might find it useful to look at WP:ELLIST in particular. It is, in limited circumstances, acceptable to include external links in a list. This might be most common when a link has some value both as an external link (e.g., to get more information than can comfortably be included in an article or to provide an official link to a named person or entity) and also as a way of verifying some of the content in the specific list entry (e.g., that Alice's Restaurant is a restaurant, or that Alice was a candidate in the election – or that source X gave this date for that woodcutting).
One of the reasons that editors use this "inline" formatting, which seems relevant here, is because adding 200+ ref tags might make the citation/link less useful to readers, and nobody wants articles to contain a thousand citation templates. WhatamIdoing (talk) 21:20, 14 November 2020 (UTC)
This seems like a useful way to go about it. {{u|Sdkb}} talk 21:42, 15 November 2020 (UTC)
WhatamIdoing, Thanks for your input. WP:ELLIST is a good guide. So external links from individual items, are allowed in the list articles; however according to User:Pppery at Talk:List of woodcuts by Albrecht Dürer, one should not use Template:Wikidata icon or create links using [[d:Q....|title]] format. However it seems like links using [https://www.wikidata.org/wiki/Q...] are OK. Also I just noticed that Template:Wikidata entity link is used on 30k pages, so that format seems to be acceptable in article namespace. Format adopted by Template:Wikidata entity link is used by similar templates in great many projects across wikiverse and would be my preference here. This is my first "list" article I worked on, so some of those "rules" seem hard to comprehend or navigate. --Jarekt (talk) 19:44, 16 November 2020 (UTC)
"According to Pppery" is a misnomer; it is according to Wikipedia:Templates for discussion/Log/2018 January 16#Template:Wikidata icon (which is prominently linked to at Template:Wikidata icon) and Wikipedia talk:Manual of Style/Archive 204#New RFC on linking to Wikidata (which is listed at Wikipedia:Wikidata#Appropriate usage in articles). By that latter RfC, Template:Wikidata entity link should not be used in articles either. The 30k transclusion figure is misleading since most uses of Template:Wikidata entity link are via Template:Wikidata redirect which, as the name implies, is used on redirects, which are not articles despite being in the main namespace. * Pppery * it has begun... 20:18, 16 November 2020 (UTC)
Pppery, Sorry I am just trying to understand the strange policies related to the format of Wikidata links. What I am gathering is that:
Any opinions about [https://www.wikidata.org/wiki/Q1 Q1] or [[d:Q1|Q1]] style links which are almost the same as [https://www.wikidata.org/wiki/Q1] only a bit more readable in wikitext? --Jarekt (talk) 22:19, 16 November 2020 (UTC)
You know, you two have been around long enough to know that this isn't a game of Mother May I? The goal isn't to see who can follow the rules the best. If these rules (if we call an archived discussion from a couple of years ago "rules") are interfering with improving the encyclopedia, then ignore them. Just figure out what's best for this article/list and do that.
I'm currently thinking that linking to sources via Wikidata is better than either no way to find sources or putting the estimated ~thousand citations on the page (which will almost certainly break the page). Are we agreed on that? If so, the only thing left to settle is how to format the links ...which is just not that important. Get a functional link on the page, and move on. WhatamIdoing (talk) 17:18, 17 November 2020 (UTC)
WhatamIdoing, I agree with you, about linking to wikidata, and yes I have been editing Wikipedia projects for great many years. One think I really do not like is, when I invest my time into a project, like improving an article or uploading a batch of images, and then my edits or uploads are deleted. That is what happen with this article, when Pppery deleted all the links to the source data citing "archived discussion from a couple of years ago". I do not want to start an edit war, but I do want to understand what are the rules governing per-item sources in link articles. I agree that format of the links should be irrelevant, but in this case it seems to be important, because linking with {{Interlanguage_link}} seem to be OK, while use of {{Wikidata icon}} template which looks much better and does not use expensive parser functions is "prohibited". --Jarekt (talk) 03:14, 19 November 2020 (UTC)
@Jarekt, at the risk of sending you on a wild goose chase, you might get better advice on formatting links to Wikidata (or any other sister project) at Wikipedia talk:External links. WhatamIdoing (talk) 05:09, 19 November 2020 (UTC)
Regardless of any other issues, the [https://www.wikidata.org/wiki/Q1] format should never be used; the correct format is [[:d:Q1]] (piped to provide suitable link text if needed). That said, the suggestion that [[:d:Q1]] is permissible but {{Q|Q1}} is not is asinine. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:36, 22 November 2020 (UTC)

I think you're approaching this from the wrong direction, @Jarekt:. I'd like to be more sympathetic, but really the way that enwp normally maintains lists is so useless it isn't worth making a fuss about. It's better to maintain the information on Wikidata, then you can use {{Wikidata list}} to maintain the list here and on other language wikis. You can include as many references there as you like. You also won't be accused of linking to an external link when it's a link within the Wikimedia projects. Thanks. Mike Peel (talk) 21:57, 16 November 2020 (UTC)

Mike I agree that Wikipedia's way of dealing with list articles is prehistoric and supper hard to maintain and Template:Wikidata list is much better approach. I just found that there is so much disagreement between different scholars, (or even the same scholar who changes his opinion with each publication) about the prints (authorship, date of creation, etc.) that it is hard to create a query which captures all the works in logical order. I have used Template:Wikidata list to clean up the data on Wikidata and Commons, but I feel like hand created list (actually SPARCL->spreadsheet->wikitext which is than manually altered) is better here. Also I am not sure if Template:Wikidata list is allowed in article namespace. --Jarekt (talk) 22:17, 16 November 2020 (UTC)
Theoretically it is not disallowed, but every instance has been deleted after a few AfDs found clear support for their deletion. If you want to source a list, add reliable sources to the list, not another wiki which may or may not have reliable sources in it, somewhere. Basically, your whole list needs reworking to meet the guidelines here. Fram (talk) 08:37, 18 November 2020 (UTC)
It doesn't seem to be a matter of referencing, List of people killed by and disappeared during the Brazilian military dictatorship was generated via Wikidata (after a lot of work by the Brazilian Portuguese community) and is #2 on Wikipedia:Articles with the most references. On ptwp it continues to be maintained by listeria and editors on Wikidata, here it's been turned into a manual list, people messed around with formatting a bit, then everything went quiet... Mostly it seems to be WP:IDONTLIKEIT. Mike Peel (talk) 09:09, 18 November 2020 (UTC)
You misread my reply. I didn't say that Wikidata lists were disallowed because of referencing issues. I said that Wikidata lists were disallowed after AfDs. And I said that sourcing can be done by adding sources in the list here, not by adding (wikidata) links after an entry. The two statements were not linked by a "because" or anything similar. Fram (talk) 09:19, 18 November 2020 (UTC)
Ah, that would have been clearer if you'd used an 'also' in the middle or similar. Anyway, "every instance has been deleted" is definitely wrong, there are a number of cases that have been converted to manual lists rather than deleted. Mike Peel (talk) 10:38, 18 November 2020 (UTC)
Yeah, I should have used "removed" instead of "deleted" there. Fram (talk) 11:21, 18 November 2020 (UTC)
@Mike Peel: Sadly, every time I've experimented with Wikidata lists in mainspace, somebody has quickly come along to disable it, and edit war to keep it disabled. So while the guidelines say there is "no consensus" on its use in mainspace, in practice it seems to be disallowed because the anti-Wikidata crowd is extremely persistent. I guess you can substitute the template to generate a list as a starting point, but their major advantage (automated updates) is nullified on enwiki under the status quo. – Joe (talk) 13:12, 20 November 2020 (UTC)
@Joe Roe: Indeed, it's really daft. It's like insisting on keeping the internet in its 1990s state, with static webpages, rather than using databases to generate them. Really shortsighted. Thanks. Mike Peel (talk) 21:12, 20 November 2020 (UTC)

Nice list. It would be better, from an accessibility point of view, to display unique text for each link, rather than repeating the word "Wikidata". The unique text should probably be the QID. I'd also suggest putting the Wikidata links in a separate column, rather than appending them to the names of the artworks. That would have an added advantage of allowing a link to Wikidata in the column heading, for the benefit of those not yet aware of what that project is about. I'd also suggest replicating the list, using {{Wikidata list}}, on a talk page or sub-page (linked from the talk page), so fellow editors can compare the two versions and see for themselves the advantages of automated list generation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 22 November 2020 (UTC)

Andy, You have a lot of good points. About "wikidata" links I agree with you those links were generated by {{ill}} which is according to some archived discussion a preferred way to link to Wikidata instead of {{Wikidata icon}}. I agree they were ugly, but I was trying to do things by the book (even if it does not make much sense). I switched to different style links as suggested by WP:ELLIST. I also created Talk:List of woodcuts by Albrecht Dürer/dynamic list which uses {{Wikidata list}}. It is not optimal as I can not control the order of the images, and which images to exclude since I will list them later in the book illustrations section. Also {{Wikidata list}} does not handle dates well, while my table uses {{Wikidata date}}, which can handle many nuanced dates. So this data set might not be the best example of superiority of wikidata-based dynamic lists, as it is wikidata-based lists after manual clean up. --Jarekt (talk) 03:07, 24 November 2020 (UTC)

As people noted above, there is a consensus against external links to Wikidata in the body. The guideline on external-links has a section WP:ELWD explicitly stating "Wikidata should not be linked to within the body". Formatting is irrelevant when the link itself is inappropriate. Anyone can of course open a new debate on the topic if they wish, but I suggest reading the RFC before doing so. I expect a new RFC would have the same outcome, for largely the same reasons. Unless someone is opening a new RFC, all of the discussion above amounts to an excessively wordy way of saying "Nope, don't try to link Wikidata in the body". Alsee (talk) 23:38, 22 November 2020 (UTC)

Alsee, guideline Wikipedia:External links you are quoting (WP:ELWD) has the following disclaimer on the top: that it " is a generally accepted standard that editors should attempt to follow, though it is best treated with common sense, and occasional exceptions may apply". As people noted above, this restrictions make no sense when applied to list articles, especially the ones generated by a Wikidata database query. That is because it contradicts Wikipedia:Verifiability policy, which in the nutshell states that "Readers must be able to check that any of the information within Wikipedia articles is not just made up", so we need to link to the source data, which just happen to be Wikidata, and WP:ELLIST guideline suggests the format. I was thinking about copying the sources from Wikidata to the article but since this is a list of several hundred prints and for each print we have several statements and each statement has several references, the number would be in 1-2 thousand range, and I was advised not to import couple thousands references, especially since current guidelines allow per items links to the source data. --Jarekt (talk) 03:36, 24 November 2020 (UTC)

I did a bit of rewrite with the help of the Template:Woodcuts by Albrecht Dürer table/row and SPARQL] query. This time I used external links following WP:ELLIST suggestion. I also corrected confusing or missing dates. --Jarekt (talk) 01:48, 24 November 2020 (UTC)

Jarekt policy section WP:SELFPUBLISH directly addresses "open wikis" like Wikidata. You can't link a Wikipedia page, a Conservapedia page, or a Wikidata page, as a ref. They are not Reliable sources (unless it is being cited as a primary source about itself). Policy section WP:CIRCULAR mainly focuses on the most common case where people try to link Wikipedia as a ref. However it explicitly covers cites "Wikipedia (or a sister project)", explaining the primary-source exception for such cites. If such a page happens to mention sources, then those sources need to be cited directly.
There is no formatting issue or question here. The problem here is that, for some reason, you want to shove lots and lots of inappropriate links into the article. You can't use Wikidata as a ref. You seriously shouldn't be trying to stick Talk space(!) links in the article. You shouldn't be linking to Wikidata in the body. And why oh why do you even stick Wikidata-book-item-links on the book refs?? Alsee (talk) 11:13, 25 November 2020 (UTC)
Yeah I am a bit confused as the meat of that list is the table, which includes the reference column - all of which are reference links to wikidata. Wikidata isnt a valid reference for anything, and on top of that, as lists are still articles, it fails the 'must not link to wikidata in the body of the article' etc. The reference column needs to be removed in its entirety or replaced with actual references. Only in death does duty end (talk) 10:12, 26 November 2020 (UTC)
@Alsee and Only in death: In many other lists of artworks each artwork has a dedicated Wikipedia page, where all the information about that painting is bundled. The Wikipedia:Verifiability policy, (one of the 3 Core content policies, is satisfied because you can click on the link to that page and find all those references. At the moment we have only 2 articles for individual woodcuts (out of 350+), so I doubt we will have articles for most those woodcuts. Pages on Wikidata are also wikimedia pages that group all the published verifiable information about each woodcut. That is why I link to them, so if someone wants to see where the information come from they can track it back to the source.
Durer had about 350+ woodcuts, each woodcut has four or five pieces of information, and each piece of info can have have up to several references. The rough estimate of number of references used is between one and two thousand and I was asked in the discussion above NOT to add thousands of references to this article.
Alsee, you mention WP:SELFPUBLISH policy, but I am not sure how it applies to this case as the policy is about the user created webpages, which can be used to add any unsourced made-up information and nobody can correct it. The pages on Wikidata are just like any other wikimedia page, yes anybody can edit it, but they follow similar stringent verifiablility guidelines and statements that do not have proper sources they are often removed. --Jarekt (talk) 04:56, 28 November 2020 (UTC)
Jarekt it doesn't appear you even read it. The second sentence of WP:SELFPUBLISH says it applies to self-published material such as [] open wikis. WP:USERGENERATED sites like Wikidata are not remotely Reliable Sources. Any editor with your apparent experience should already be aware of that. And you're still battling against the consensus not to put external links to Wikidata in the body. As you should also know, we expect people to respect policy and consensus once they've been cited. Alsee (talk) 12:01, 28 November 2020 (UTC)
Alsee, I totally agree with you that wikidata or wikipedia pages should not be used as referenced sources. The issue is that we have too many items with too many references to add them directly so we need to rely on pages aggregating all the info and all the references about an item, and link to them for each item in the list. Many list articles list objects which have independent English wikipadia articles, so one can follow the link to that page to get more information and references. However, we do not have links to wikipedia articles for Durer's woodcuts, so originally I was linking to pages on Wikidata to satisfy WP:LISTVERIFY guideline. After all, all the information in the list were generated using Wikidata query so I know that those pages have all the info to back up the claims in the table. After the links to the source data were removed from the article (seemingly in violation of Wikipedia:Verifiability policy), I followed WP:ELLIST guideline to format my links to pages with references as "external link [] at the end of stand-alone lists" recommended by that page. Those are not ideal, so perhaps a better approach would be to use Template:Sister-inline to add links to pages on other projects (like Wikidata or Commons), related to a given woodcut. --Jarekt (talk) 20:03, 1 December 2020 (UTC)
Jarekt each cell in the table generally only needs to be covered one ref, if there is a conflict in dating you can cover earliest and latest dates with two refs. I expect in many cases a single ref can cover all or much of a row or column, or a single ref may be re-used in scattered places. If Wikidata mentions multiple sources for something, we only need one. I don't think I'm saying anything particularly interesting here - Wikipedia has lots of tables and this is all routine practice. Alsee (talk) 04:00, 2 December 2020 (UTC) P.S. Not all cells necessarily need to be directly covered by a ref, such as empty cells, image column, and title column. Alsee (talk) 04:06, 2 December 2020 (UTC)
But that is a little like saying: go through 350 articles and pick a single good reference that best covers most of the info in the article, and copy it into a list article. However not include direct links to the wikimedia pages combining all this info. --Jarekt (talk) 02:53, 8 December 2020 (UTC)

Professional critics

Comment: This discussion has been linked to from:

Cheers, CapnZapp (talk) 10:15, 6 December 2020 (UTC)

What even qualifies someone to be a "professional" film or television critic? Who gives out the certifications/awards in film criticism? I'm questioning the guideline as outlined at MOS:TVRECEPTION. Aggregator sites such as Rotten Tomatoes are overwhelmingly biased towards mainstream white male baby boomers. Not that their perspectives are invalid, just that it's only one perspective. Not calling anyone a racist, but if you've never been stopped in the street by police just for being Black in public you're not going to understand what it's like. Trying to introduce alternative perspectives is an uphill battle on wikipedia; people question the source's reliability and/or the person's qualification to make a criticism. I'm not only talking about race (or "skin color" as I have been misrepresented as saying), I'm talking about all alternative perspectives.

The popular Netflix series The Queen's Gambit is what brought this to my attention. On aggregator sites like Rotten Tomatoes they're almost universally raving about it, 100% approval or close. However several non-white writers have criticized the series' use of the "sassy Black woman" and "magical negro" tropes. Problem is, most of these writers are not published in mainstream newspapers or sources wikipedia has agreed are "reliable", and are rejected by many wikipedia editors on this basis. (See the article's talk page). Do the current MOS and guidelines on film and TV criticism contribute to a systemic bias in wikipedia? Thoughts? And please don't just link me to WP:RIGHTGREATWRONGS or any other WP links, Wikipedia policies and guidelines can evolve and always have. I want your own thoughts. Pinging @YoungForever, Anywikiuser, Intforce, CapnZapp, and Drovethrughosts: MaxBrowne2 (talk) 04:59, 5 December 2020 (UTC)

Controlling policy is still basically WP:UNDUE. When we are looking to consider the critical reviews of a work, we're going to look at the type of sources that are typically considered reliable for the same types of works in that media, once that have been identified over and over as mainstream or top critics. Could they be a male-dominated or other similarly racial/gender-skewed perspective? Maybe, and that would be a systematic bias but beyond the scope of WP. What we can't start doing is including every random review or criticism just because it may go against the grain of mainstream. A wholly separate example in the world of video games is when we find games raved about by the common review sites, but there is a loud set of user complaints that we simply cannot talk about unless they get documented in third-party sources. And the sources I'm seeing so far brought up for this aspect of the Queen's Gambit are similarly weak sources that fail the UNDUE test. That said, this WAPost article touches on the issue, it seems, but I'm not seeing much yet out there. There could be an argument if this consideration related to the sassy Black woman trope was something in multiple weaker RSes, but given there really only seems to be one weak RS making the call, that really suggests it fails UNDUE. --Masem (t) 06:21, 5 December 2020 (UTC)
I see another site I linked to on the talk page, by Gloria Oladipo on Bitch Media, has been added to Rotten Tomatoes as the only negative review. Clearly an intelligent woman with some cogent arguments, but she's a 20 year old college student and it's a minority interest site. MaxBrowne2 (talk) 07:17, 5 December 2020 (UTC)
Sorry if some one feels I am digressing; but irrespective of rest of the discussions User:MaxBrowne2 has a valid point when he says,"... Trying to introduce alternative perspectives is an uphill battle on wikipedia; people question the source's reliability and/or the person's qualification to make a criticism. I'm not only talking about ...XXX..., I'm talking about all alternative perspectives..." (any rational fellow would happily read again).
I do wonder in last 20 years how come Wikipedians didn't get reasonable number of experts in pointing out (List of fallacies) in those 'self point of view serving' status quo.
Considering something as mainstream and rejecting something as fringe is technically original research. Unlike old printed encyclopedias there is no space limit to Wikipedia then finding reasons to exclude lot of content sitting behind range of rules has more to do with Political religious and nationalistic etc point of views which want to suppress other views rather than logical reasoning. IMHO. And that really makes ...introduce alternative perspectives is an uphill battle on wikipedia...(Pl. do read again 1000 times)
Sorry for expressing non mainstream views which questions status quo.
Bookku (talk) 08:01, 5 December 2020 (UTC)
Ultimately, there has to be a requirement that reviews mentioned in an article should come from professional critics in mainstream news sources. There is indeed a downside that we exclude the opinions of the many gifted amateurs who are out there. But it's also the only way to make sure that our articles do not become a free-for-all in which anyone in their bedroom can self-publish reviews that get featured on Wikipedia. That's not to say that professional critics in mainstream news sources are always great. Instead, it ensures that in order to be included in Wikipedia, reviews have to meet a threshold for both journalistic standards (made possible through the news source's hiring process, editorial oversight and other checks) and notability.
There is another reason why I was opposed to the OP's proposed edit on The Queen's Gambit: it was not an opinion that was widely held by critics. The article does include a 3/5 star review from Rolling Stone that praised the visuals and acting but felt it was too padded. That feels reasonable — some the less favourable reviews recorded on Rotten Tomatoes had a similar opinion. On the other hand, I didn't notice many reviews that felt that stereotyping was a significant problem. It would be like including a review that described The Deer Hunter, Schindler's List or The Irishman as a film that "feels rushed". Anywikiuser (talk)
A lot of any WP editor's work involving summarization and the like is original research, but it is an accepted type of original research needed to distill sources to reflect them. This type of situation (determining when an alternate viewpoint should be brought in and what minimum sourcing is required for it) is such a case. It's original research around how we summarize, not what the information is about the topic.
And one factor here - and nothing against the reviewer making this complaint about the stereotyping in the work - is that when you have a situation where a one-off work in a side RS makes a point that is arguing about a social faux pas made by a work, you do have to ask if that is really a true consideration or something that that one writer had an issue with and is trying to fight that issue on their own. And this actually might take time in terms of days and weeks or even years to find others that start to agree. It might be an idea that simply takes time to percolate through other media critics to see it as well. Or it just may be one person's personal idea and no one else sees the issue and that makes it FRINGE. So there's a wait-and-see matter to consider as well. --Masem (t) 15:20, 6 December 2020 (UTC)
User:Anywikiuser: I don't agree that there is only the choice between "professional critics in mainstream news sources" and "anyone in their bedroom". If you look below, I am a) questioning this as a false binary, and b) asking where our policy requires this or where consensus has arrived at this as the only interpretation of policy. CapnZapp (talk) 14:19, 10 December 2020 (UTC)
User:Masem: As I've stated elsewhere, if the consensus is that a particular viewpoint is UNDUE, that's totally fair. I'm just questioning the automatic exclusion of sources that appear to fulfill all the criteria of WP:R just because it's not "mainstream" enough or doesn't fulfill some nebulous criteria of "professional"... CapnZapp (talk) 14:22, 10 December 2020 (UTC)
  • I mean, you ask not to be linked to WP:RGW, but that's a very pertinent page to your comment. I haven't looked at the talk page, but if you're having trouble finding reliable sources supporting a given perspective about the show, that's an indicator it's a fringe perspective that probably doesn't warrant a mention in an encyclopedic account of the show's reception. If your view is that the perspective should be included anyways because it's meritable, that's trying to make Wikipedia a tool of activism rather than an encyclopedia, which is what RGW speaks to; it would be a change to our fundamental purpose that would rob us of our credibility. If your view is that the sources discussing the show's reception have not picked up on a view that's actually quite popular, that's trying to make Wikipedia a secondary source rather than a tertiary source, which is another non-starter—we have enough difficulty agreeing about what reliable sources say, let alone if we gave ourselves license to override them if we feel they don't do a good job. And if your view is that there are sources that are deemed unreliable but should be considered reliable, that's something to take up at the reliable sources noticeboard, not here, but you will have to argue that they meet our standards for reliability, as there's (rightly) not going to be consensus to lower those. {{u|Sdkb}} talk 21:21, 5 December 2020 (UTC)

Opinion Sources

I understand MaxBrowne2's sentiment, but feel we risk getting sidetracked if we focus on the bias/minority issue. Or maybe I'm just asking a completely separate question? Let me put up a subheader - we can discuss two things :)

Anyhow - my question is very simple: where does it say we can only include critics from aggregator sites or even "mainstream sites"? If I'm allowed to rant a bit, this reliance on aggregators is a plague on Wikipedia. It's so easy to just post up RT/MC stats and nobody can complain or edit war since it's all so "objective". Bull I say. If I wanted Rotten Tomato scores I'd visit Rotten Tomato. But I'm not. I'm visiting the premiere online encyclopedia and want, expect and deserve a human-curated selection of really good quotes! The RT/MC scores can live at the end of the Reception sections as a complement but should never replace a "real" Reception section...!

Hrrm. Anyhow. My question. Yes - it's the same as MaxBrowne2's but with no specific angle:

What even qualifies someone to be a "professional" film or television critic?

I'm reading our policy as any magazine can be reliable when it isn't amateurish or self-published, and we're not forced to first anxiously check with our overlords at MC or RT for approval "did they include this or that critic". When we verify a claim about rocket science, we don't use an entertainment magazine, but when we verify opinions like "I liked it" or - in this case - "criticizing it as being misogynoir and biphobic" what says a specialist (but little known) magazine isn't reliable?

Specifically

  1. 1 An argument was made the source wasn't notable. But I thought notability related to article subjects - not sources.
  2. 2 Next argument was "written by a contributor, not a staff writer". I can't find where the policy makes this distinction either. Related is Per WP:SELFPUBLISH, she is not an expert in writing reviews which just don't even... Talk about elitism!
  3. 3 UNDUE I do get; the argument "if nobody else complains maybe this source is an outlier that should be ignored". Sure. Except if only RT/MC sources are considered as "inliers" then we're back to effectively banning every other publication...? We must at least be able to have a discussion in each particular case and not just shut down discussion with "RT/MC defines this series to handle racism and bisexuality well because they're not complaining".

I guess I'm asking for specific pointers to policy, to guidelines, to community consensus discussions, RFCs anything that puts our consensus in writing so it can be analyzed and criticized.

I openly declare I'm partly driven by suspicion that people just don't like including sources that crap all over their nice new Netflix show, and remind them of whether its depiction of Jolene and Cleo might be cliched or not. But in order to contest their officious-sounding policy quotes, I must first ascertain if that really IS policy.

Thank you CapnZapp (talk) 00:01, 6 December 2020 (UTC)

I think looking for "awards" or "certifications" is doing a dance around the word "engaged in a specified activity as one's main paid occupation rather than as a pastime." Now, it can he hard judging precisely when one hit's "main", but we can be pretty sure that the guy who's reviewing TV for the Washington Post is making a living, someone writing a review for Bitch is probably getting paid and at least making it past gatekeepers, and the guy who blogs his opinions at Nat's TV or Not TV is not likely making income worth detecting from it.
This isn't to say that someone cannot establish themselves as a valuable critic in some non-financially-remunerative way, but if we're looking for "professional", then pay is the matter at hand. --Nat Gertler (talk) 00:32, 6 December 2020 (UTC)
where does it say we can only include critics from aggregator sites or even "mainstream sites"? It doesn't say that anywhere. Is someone making that argument? I haven't seen it here in this discussion. That would appear to be a strawman you have put up. What we do require are sources published by reputable organizations with evidence of fact-checking, and it usually helps if the primary author also has a good reputation for such. "Contributors" (such as at Forbes) are usually not included because they are rarely or not-often providing fact-checked work; as in, they are published as-is, without editorial overview.
Notability of the organization can help us decide whether it is reasonable to provide them WP:WEIGHT, so I would suspect that is where that comes into play. --Izno (talk) 03:37, 6 December 2020 (UTC)
I intend no strawmen. If you have read the original debate and still feel I'm misrepresenting the opinions of others, please tell me so I can improve. CapnZapp (talk) 10:17, 6 December 2020 (UTC)
Technically, WP:RSOPINION allows opinions for any source, not just those RS for fact (opinions from known RSes are one example but RSOPINION is not limited to those). But as been argued in the recent discussions around the Daily Mail and deprecated sources, the inclusion of RSOPINION from sources not normally considered RSes better be weighted per UNDUE - how much of an "expert" is the writer of the piece and how germane is the piece to the topic in question? While UNDUE doesn't specifically say this, this is how the practice of UNDUE + RSOPINION is applied to avoid inclusion of every random blog's comment.
Now on the bigger picture, when it comes to contemporary media like films, books, etc, I think the individual Wikiprojects that handle that may have their own internal systems but all them have determined that while there may be numerous possible review sources out there, there are clearly some that are more key to have over others, and this does discount some of the critics that may be listed in RT or MetaCritic. (And nearly all cases, these are expert sources from those RS known for fact, not those that only fit RSOPINION). If a work gets 40+ reviews from RSes, we can't include all 40 reviews - that's why we usually rely on RT or MC to aggregate - and we're going to focus only on the most "expert" of critics that these projects have determined from experience to document in WP. This will usually try to include major outliers when it is appropriate so that the spectrum of reviews are covered. (eg the Rolling Stone review for Queen's Gambit would be included as one of the lower scores from a major review). But if one of the "off" mainstream reviewers gives a low score while everyone gives it a high review score, that is usually ignored, again per UNUDE. --Masem (t) 15:06, 6 December 2020 (UTC)
  • First: do we by "professional" mean "paid" or "of high quality"? Asking editors to make sure money exchanged hands seems unreasonable, so I'm going to assume the latter.
  • Second: there is considerable MC/RT creep and Wikipedia editors should definitely be able to (encouraged even) to use reviews from other publications. (At least until policy makes it clear Wikipedia is only a subservient website which I obviously hope never happens)
  • Third: Again I absolutely acknowledge UNDUE (except the idea that we should evaluate DUE-ness from only RT/MC-included sources) as a valid argument against including Wear Your Magazine in a specific case. (That is, including it should be possible if it can be shown its sentiments have a notable spread). But I absolutely protest against dismissing that magazine as SELFPUBLISH - again, as far as I can see this source has more in common with Washington Post or Bitch (or The Tufts Daily for that matter), than Nat's TV or Not TV (which is clearly a BLOG - it's even using Wordpress as a platform).
  • Fourth: I have seen the notion that we should accept "staff writers" but not "contributors". When asked to base this on specified policy or consensus I got no reply. As I understand it, this needs to be evaluated on a case by case basis. (=Just because it's true for Forbes doesn't mean you can nix every "contributor" source). Can someone shed light on this, please?
CapnZapp (talk) 12:22, 7 December 2020 (UTC)
There are two aspects here:
  • Perhaps on the point about Contributors vs staff, if we take the few sites where we know they document their practice, like Forbes, Contributors posts do not go through any type of editorial oversight before they are posted, unlike staff where things are double checked (more than just spell checking and grammar) by an editor; the editor is making sure, particularly for opinion pieces, that nothing in the review is grossly offensive or slanders/libels anyone or the like, and that ultimately, while the piece is still the work of the author, it fairly represents the work's position. Contributors are generally told to stay in line, but if you read the fine print at Forbes, Forbes clearly distances itself from any POV stated by any Contributor compared with Staff op-eds.
    This means when we talk about reviews (and we'll stick to films for the time being) that high quality RSes like the New York Times, Rolling Stone, Chicago Sun-Times, etc. all have reviews by staff, reviewed by an editorial board, and thus while opinion of one person, are still implicitly representative of the work itself. (Eg while we should say "Robert Ebert of the Chicago Sun-times said..." specifically, we can also get away with "The Chicago Sun-Times said..." as well) Whereas for some of the less reliable sources, we are not sure of these editorial policies - they may, they may not have them. But without clarity, that usually means the review is only one person's stance and we can't implicitly assume the work it was published in stands behind it (this is the SELFPUBLISH issue)
  • The other factor is simply just knowing the field and who are "experts" in it. If we were in the medical field, there's hundreds of journals one could pull information from, but we have a policy WP:MEDRS that actually limits such information to top-quality peer-reviewed journals, since there are numerous fly-by-night non-peer reviewed sources as well as "predatory journals". We (both the scientific community and Wikipedia) have come to know what are the top quality sources over time and thus MEDRS reflects that knowledge. What main review sources are used for WP articles on films is from a similar understanding of the history of film criticism and what reviewers/sources have percolated to the top as the best. Those are the reviews that are considered the ones that we want to include. This may cause us to focus heavily on RT/MC but we know these sites are industry leaders in review aggregation, and since we are a tertiary source, we "follow the leader" rather than forging new paths.
That does make it difficult to include reviews from weaker RSes, no question, but at the same time, most of the time they are simply saying the same thing as the top-tier reviewers. We also simply can't take any random armchair critic on the Internet as there are a million of them; we want at least sites and reviewers with some history recognized n third-parties as a possible expertise. We have a special case here where there's a unique point of criticism brought up by a weaker RS, and that's basically now where we have to let UNDUE be the judge. If 5 or 6 of those lesser-tier RS brought it up, I may be inclined to say yes. But when it is down to one or two of these, we're basically where UNDUE becomes FRINGE and we sorta have our hands tied. --Masem (t) 15:21, 7 December 2020 (UTC)
The comparison falls down in that scientists and medical professionals have to go through a rigorous qualification process to be taken seriously. On the other hand, literally anyone can have an opinion on a film, and write about it. Film criticism is not a science. Calling out a film for recycling a problematic trope is not a WP:FRINGE position, like for example the anti-vax movement. It's a valid criticism. MaxBrowne2 (talk) 23:13, 7 December 2020 (UTC)
It can be a FRINGE issue if no one else is talking about that same issue. Particularly if we have a work that would be, to be terse, a strong interest to push that narrative. Eg the source that seems to be behind this is a source that seems to be very attuned to women's rights and matters, so there is a bias concern here. (We'd have a similar issue if a movie that involves gay people was considered to misrepresent gay people by a LGBT-focused work and only that work). And while film criticism is not science, sourcing in WP is. As you say, anyone can have an opinion, but we obviously can't include the potential 8 billion opinions out there. We have to be purposely selective and starting with what has been determined as experts in reviewing films sets a key line. --Masem (t) 23:26, 7 December 2020 (UTC)
And there is no "bias concern" when the critics deemed "reliable" are overwhelmingly white and male? *All* critics are biased, that's why they're critics. MaxBrowne2 (talk) 23:38, 7 December 2020 (UTC)
I decided to see if there was data on gender bias in film criticism. A report covered in this New York Times article found that films with a female protagonist do worse among male critics than female critics, with male critics giving those films an average rating of 62% in the study's time period compared to an average of 74% from female critics. For films with a male protagonist, those figures are respectively 70% and 73%. 68% percent of the critics were male.
While this offers evidence that gender can affect reviews, it also suggests that the effect is not huge. As the report notes, a film with a female protagonist will usually have a higher share of female critics. Furthermore, by my own calculations, a radical change to the number of female critics would have only a modest effect on their average ratings. The study is suggesting that the average film with a female protagonist would get an average rating of 65.8% if 68% of its reviewers are male, 68% if the genders are evenly split and 70.2% if 68% of its reviewers are female. Anywikiuser (talk) 19:23, 8 December 2020 (UTC)

First off, if an article's editors agree a particular opinion is UNDUE, then it's totally fair to exclude it. (And no, that's not OR since it's what editors are supposed to do). In that case. On that page. That said, I totally agree the comparison to medical journals is flawed. We should totally not restrict our pool of possible opinion sources to only those "vetted" by RT/MC (or any other "authority"), the way we totally should in the field of facts (including medical journals). And, more to the point than me just voicing my personal opinions, if the community would go counter to my wishes here, then this needs to be clearly communicated by relevant policies and guidelines (otherwise the decision is impossible to question). Regards, CapnZapp (talk) 14:29, 10 December 2020 (UTC)

An aspect of contemporary film reviews is that these arguably focus mostly on the film making process - acting, writing, directing, production, etc as a whole. More recently (with more web-based sources) another aspect of film reviews but these non-professional sources tends to be their focus on the ideological nature of a film through the eyes of those reviewers, and this can create "pet" issues that these reviewers may focus on that would not be considered - at least initially - by the professional reviews. That is, to not try to be too blunt, this is akin to WP:RIGHTGREATWRONGS in film criticism. Not that these don't have effects: the Bechdel test is one of those things that I think many professional reviewers do keep in the back of their heads in reviewing films given the growth of the feminist movement over the last decade + change, but its application to films likely started with more "armchair reviewers" than professional critics.
But not every ideological-driven review is necessary of the same weight here, and that's the situation I'm seeing with the Queen's Gambit situation here. The "sassy Black woman" stereotype has all the makings of a new Bechdel test in terms of racial representation, but it certainly doesn't have the weight of reliable sources behind it to make it equivalent to the power and volume that the actual Bechdel test has. Maybe it will in time, I can't say. But that only one or two of these non-major reviewers have identified this issue that is outside the realm of typical film criticism does put it in the "UNDUE" area for the time being. If there was more volume from other non-major reviewers on this point, then there would be better reason to include so it didn't look like one person's gripe with the film. And again, passage of time may help; if this "sassy Black woman" stereotype becomes more and more an issue, we may get retrospective reviews that are more critical of this film to add. --Masem (t) 14:59, 10 December 2020 (UTC)

Unverifiable fair use media and other data included in mainspace

I thought that this:

Already covered this. But the first doesn't specifically mention files (and files exist in the File: namespace, not mainspace) and the second can be freely ignored apparently.

I didn't want to start a discussion for this, but after being told to "go and tell that to anyone who cares" I guess I should. Perhaps we could specifically add files to Wikipedia:Verifiability or tweak the wording so it isn't restricted to mainspace? Besides files, information can be fetched from Wikidata ({{Infobox video game}} for example does this) or the Data: namespace on Commons 😀 . That emoji is hosted on Commons, and it isn't an image. I suppose all these sources (files, Wikidata, tabular data and possibly structured data in the future) should also be verifiable, despite existing outside mainspace? — Alexis Jazz (talk or ping me) 10:55, 12 December 2020 (UTC)

WP:NOR#Original images Jheald (talk) 11:26, 12 December 2020 (UTC)
Jheald, doesn't that apply for free images only, not fair use? Enjoyer of World — Talk 11:36, 12 December 2020 (UTC)
@Enjoyer of World: That's true. But WP:NFCC #8 is quite a test for non-free content. Jheald (talk) 13:56, 12 December 2020 (UTC)
@Jheald: Please tell me Original images created by a Wikipedian are not considered original research, so long as they do not illustrate or introduce unpublished ideas or arguments does not mean "upload your fan art with a fair use rationale, seems legit". — Alexis Jazz (talk or ping me) 12:56, 12 December 2020 (UTC)
I think more like "feel free to create your own illustrative diagram of cited data". Assuming by fan art you mean art based closely on copyrighted images, it's not original research, but it's still a copyright violation. isaacl (talk) 22:18, 12 December 2020 (UTC)
Perhaps not original research, but certainly not genuine either. — Alexis Jazz (talk or ping me) 23:29, 12 December 2020 (UTC)
The verifiability policy starts with In the English Wikipedia, verifiability means other people using the encyclopedia can check that the information comes from a reliable source. In the context of media files, to me this means the file must be attributed correctly, with a citation to the source so that the integrity of the file can be verified, or some other way of validating the file should be available (such as a digital signature). In practice, though, particularly for older media, it's hard to enforce, as media doesn't come with a chain of custody embedded within it. So while I agree that we ought to provide information to validate integrity, I don't know how to feasibly require it in all cases. isaacl (talk) 22:12, 12 December 2020 (UTC)
@Isaacl: Where no alternative exists, this may be excusable. (the whole reason courtroom sketches exist) I could even understand not deleting files before they have been replaced with properly sourced files to avoid massive disruption. But when an unsourced file is replaced with a properly sourced one, getting a ton of resistance was not what I expected. And the comment that was made: Nowhere in the WP:NFCC criteria states that files must come from the official provider. They only need to come from a previously published source. should probably worry us a lot as that's using policy to validate the removal of sourced material and reinstating unsourced material. — Alexis Jazz (talk or ping me) 23:29, 12 December 2020 (UTC)
I'm not sure "excusable" is the term I'd use. Preserving integrity to me is part of adequately citing a work, even if there are no alternatives. (I think citing a drawing to a courtroom sketch artist sets expectations that the proof of integrity ends at the artist.) The problem is that we don't have a great way to do this in cases where the original is not publicly documented. In the case of a cartoon drawing, it's not obvious (absent some kind of embedded watermarking that is digitally signed, perhaps) how to distinguish between an image claimed to originate from the creator and one of uncertain provenance. In cases where two files are on an equal basis regarding their integrity, it might not be desirable to always prefer files from the creator of the original work, if files from another source are better at providing information about the subject. I suspect even when one file has a greater degree of integrity in tracking its origin, many editors give more consideration to the file they believe illuminates the subject more clearly, but I'm not sure. isaacl (talk) 00:08, 13 December 2020 (UTC)
In terms of non-free, the source for the image file should be a source that we have reasonable assurance can be traced to one that is a valid copyright "route". For example, if I were to take a screenshot from a DVD, I'd cite the DVD and approximate timestamp, and that would be fair. Using video games as an example, most screenshots come from sites like IGN or GameSpot, and while they are not the originally publisher, we are reasonable sure by their past reliability that these are either works provided via press kits from the publisher to these sites, or taken by the sites themselves and thus have a reasonable source trace. The image of Pluto the Dog take from Fandom doesn't have any of those qualities - while it certainly looks like it has been an image cut out of a still from a Disney short (which is a reasonable step to do to get to a non-free image), we don't know about this step based on the fact that Fandom is a user-generated site. It could be a really good vector-trace image, for example, and that would be problematic. It would be far better if we had this image that the uploader did the work to "cut" it out from the frame and fully explained the original work they pulled it from and what processing they do to make the clean image, as that gives far better line of copyright sourcing. Otherwise, we are in dangers of the same types of problems of "flickrwashing" and other problems when we don't provide good sourcing. --Masem (t) 00:35, 13 December 2020 (UTC)
Exactly. I only just realized I could have used CSD F4 {{Di-no source}} or F7 {{Dfu}} but Twinkle had me confused, so for now I'm stuck at FFD. But with several users reverting me, even mistakenly citing policy as an excuse, the policy should be clarified in some way. — Alexis Jazz (talk or ping me) 01:26, 13 December 2020 (UTC)

Oversight RFC proposal

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

I started a proposal to remove a criterion from Oversight that I believe to be redundant at Wikipedia_talk:Oversight#Remove_criterion_5_from_the_policy_list. What is your honest opinion of this criterion? 4thfile4thrank (talk) 02:55, 10 December 2020 (UTC)

4thfile4thrank, honest opinion… WP:SNOW Gwen Hope (talk) (contrib) 18:53, 12 December 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:Merging has an RFC

Wikipedia:Merging has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. — Preceding unsigned comment added by Mdewman6 (talk • contribs) 23:56, 13 December 2020 (UTC)

URL accessdate and time zones

Which date should we provide when the country of the news in question and the user who accessed the related URL are in different time zones (e.g. when the news is timestamped 15 December local time, but it's still 14 December in the country of the user who accessed the URL)? Help:Citation_Style_1#Access_date currently doesn't specify this. Brandmeistertalk 23:30, 13 December 2020 (UTC)

As it's unlikely the source would change before midnight your time, and change in a way that affects the verifiability of your content, you could code 15 December as the accessdate and call it a day. Or, if you're uncomfortable with that, you could wait until midnight your time (or later) and access the source then. I'm guessing the doc doesn't specify this per WP:CREEP; i.e. because it isn't a significant enough problem for the doc to do so. In any case, you're in the wrong venue; this should have been at Help talk:Citation Style 1. ―Mandruss ☎ 23:58, 13 December 2020 (UTC)
I tend to use access-date based on UTC, but that's still a problem for sources in the Western Hemisphere. Of course, the problem goes away if we don't use sources which are less than 24 hours old - a method which would be it's own reward. (cf. WP:RECENTISM) - Ryk72 talk 02:10, 14 December 2020 (UTC)
Well, a bit after 5PM EST (2200 UTC) tomorrow, someone is going to update the official United States Electoral College vote within minutes of Biden crossing the 270 threshold when California's electors cast their votes.[11] It might be awkward if the Wikipedia editor cites a news source from a place where it is already Tuesday. If the Tokyo Olympics are held as [re-]scheduled, expect a lot of "tomorrow's news, today" situations. davidwr/(talk)/(contribs) 🎄 02:20, 14 December 2020 (UTC)
Agree that it's almost certain that someone will immediately add the official US EC vote; also agree that it looks somewhat strange if the access date precedes the published date. And concur that in cases like the Olympics, we will likely be adding a great deal of factual content shortly after the event. As a generalisation, however, it would be of benefit to the project if we were to think of ourselves as less of a newspaper; and make less haste to include breaking news. As for the specific question, I think either using the timezone of the publication, or of the editor, or UTC are all valid approaches - even though some cause awkward results. Concur with Mandruss that it may not be a significant enough problem to warrant specific instructions. By contrast, changing the publication date would not be a good thing. - Ryk72 talk 02:59, 14 December 2020 (UTC)
The only uses of the access date that I can think of is to find the specific snapshot that was viewed, whether it be for validation or recovery purposes. But unless an external archiving site is taking snapshots that line up with the access times, precision beyond a day isn't going to matter. isaacl (talk) 05:53, 14 December 2020 (UTC)

Update and simplification of MOS:FRENCHCAPS proposed

FYI
 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia talk:Manual of Style/France and French-related articles § Proposed simplification of MOS:FRENCHCAPS, which is more than a decade outdated
 — SMcCandlish ☏ ¢ 😼  07:10, 14 December 2020 (UTC)

Short descriptions - appearance of incongruent policy between mobile and desktop editing

Doing some recent review of Wikipedia:Short description led me to realize there's explicit instructional differences between that and information about short descriptions in the mobile Wikipedia app. A significant part of the contribution solicitation on the app is the Suggested Short Description additions. Here we state start with a capital letter, and avoid a final full stop however the app instead says Start with a lowercase letter unless the first word is a proper noun.. Additionally, here we state be brief: aim for no more than about 40 characters (but this can be exceeded when necessary) however the app instead provides no length guidance and accepts submitted short descriptions between 2 and 250 characters in length. Even though the app specifically states "Wikipedia", the app's guidance seems to come from Wikidata instead. This is bolstered by a few bug report I've previously had with the WMF app developers which say when the app says you're editing Wikipedia, you're actually editing Wikidata or the Commons instead, which I find a tad misleading personally. Anyway, I would like to hear community thoughts on this. Gwen Hope (talk) (contrib) 19:19, 12 December 2020 (UTC)

On 13 October 2020, the English Wikipedia switched to using only local short descriptions — not any short description taken from Wikidata. The iOS app is currently being changed to match – see T257867. It is not clear when the Android app will change – see T257488 — GhostInTheMachine talk to me 23:22, 12 December 2020 (UTC)
GhostInTheMachine, good to see someone else recognized this discrepancy. However it seems that for display purposes, en-wiki does use Wikidata descriptions when no local short description exists. At least, that's what occurs during my editing. Gwen Hope (talk) (contrib) 01:33, 13 December 2020 (UTC)
Also see Wikipedia talk:Short description#Description editing in the iOS app — re viewing vs editing — GhostInTheMachine talk to me 16:14, 14 December 2020 (UTC)

Three-way category intersections

Using an egregious example, there's a discussion about limiting 3-way category intersections at Wikipedia:Categories for discussion/Log/2020 December 14#(Dis)Establishment three-way intersections. Disestablishment is particularly confusing, as there is no consistency in application. But Establishment is even more contentious, as folks argue about what part of a country or empire or kingdom or principality or province or region or state actually controlled the place in that year (or fraction of a year). Compounded by country and year, then also by year and country.
William Allen Simpson (talk) 17:34, 14 December 2020 (UTC)

William Allen Simpson, I came across the WP:Category intersections requested feature recently, which seems relevant. Do we know what the status of that is, or if it's something that's just going to be handled by Wikidata? {{u|Sdkb}} talk 02:48, 15 December 2020 (UTC)
Sdkb, we've been talking about it over on the technical list for a long time (August 2006 was the first mention I've quickly found). Once upon a time, there was an external tool.
William Allen Simpson (talk) 20:11, 15 December 2020 (UTC)

We really should ban multi-way intersection edits in the category tree itself, as every change for a 3-way intersection requires 6 (3! for the math inclined) CfD discussions. And they conflict. And there is an awful lot of incomplete tagging, so these trees are poorly populated. And contentious.
William Allen Simpson (talk) 20:11, 15 December 2020 (UTC)

Notability of political stunts with no legislative action

There's a current discussion taking place on Talk:Mike DeWine#RFC for the Impeachment Resolution Section that may result in additional language for WP:BLP.

For those of you not following the news, the Republican Governor of Ohio had a small number of fellow Republicans file a set of grievances about his handling of the coronavirus. However, it was widely panned, and the legislature refused to take it up.

The question is whether a press release is notable enough to add in perpetuity to our encyclopedia. There was significant coverage of the press release. But the filing went nowhere. It was never assigned to a committee. There was no Impeachment. There were no hearings. There was no Resolution passed by the legislature.

It is probably important to formulate a policy or guideline, as this RFC will likely be followed by another for Gretchen Whitmer, where a Democratic Governor of Michigan had a small number of Republicans file a set of grievances about her handling of the coronavirus.

On the other hand, finding these filings by a small number of legislators to be notable, there will need to be a half dozen new sections added to the Trump articles (plural), as there were several variant articles of impeachment filed prior to action by the US House. This could become a thing.
William Allen Simpson (talk) 22:36, 17 December 2020 (UTC)

  • Obviously, first would have to be coverage in reliable third-party sources. You can probably source the complaints to the proceedings of Congress but if no sources picked up on that, that immediately tells us its probably not important to include.
The second test, if it is covered to some degree, would be if it fits a larger narrative around criticism of the politician or government over a topic, which reflect the WP:UNDUE factor. Say in the DeWine case there were Ohio papers that did report on this filing, but there is zero other coverage of any criticism about DeWine's handling of COVID. Then this would be undue to include. On the other hand, if there are numerous other cases of criticism towards DeWine already, this would be adding onto those, and would at least be appropriate to consider per UNDUE. I'd still use caution to consider the overall "narrative" developed by the summary, but this is a much fuzzier line that needs talk page discussion. (This idea is comparable to what BD2412 suggests, that if we've already cataloged several similar cases, adding to that would make sense). --Masem (t) 23:54, 17 December 2020 (UTC)
  • Thanks for the WP:UNDUE factor, I'd forgotten about that policy. In neither case was the impeachment "considered". Just a few legislators who filed a grievance. I'm not as familiar with the DeWine Ohio legislative process, and it happened earlier. In Whitmer's case, the heads of both the state house and senate called it "shameful", and never even allowed a "first reading" on the calendar. The effect is that it never existed, as far as the official legislature was concerned. But it got lots of coverage, including at a national level. Compounded by coverage of the militia kidnapping arrests. And earlier the armed protesters who shut down the capitol.
    William Allen Simpson (talk) 17:08, 19 December 2020 (UTC)

AFD Template Wording

This question is about the wording of the template that is displayed on an article that has been nominated for Articles for Deletion. The template says that the template may not be removed while discussion is in progress, and that the article may not be blanked. The template does not say that the article may not be moved. The template that is displayed on a miscellaneous page that has been nominated for Miscellany for Deletion, by contrast, says that the page may not be moved or blanked, and the template may not be removed. Is this difference intended, or unintentional? I asked a related question three weeks ago, but now I noticed that the wording on the AFD template does not contain the instruction not to move the article. Sometimes the author of an article moves the article into draft space after it has been nominated for deletion, perhaps in order to avoid deletion. So my question is: Should the notice on an article that has been nominated for deletion say not to move it? Robert McClenon (talk) 06:14, 20 December 2020 (UTC)

  • No. AfD templates are commonly put on new creations that may require some amendment of their title. For example, see Widnes Laboratory where the nomination immediately starts by suggesting a title change. Such action should not be forbidden because pages at AfD are not frozen – improvements are explicitly encouraged because these may help in the discussion per WP:HEY.
Now there was a time when moves were forbidden during AfD but that was a long time ago and was for technical reasons because AfDs were then done using substitution. That limitation was then explicitly removed. See AfD page moves for details. It could be that the MfD wording is a relic of those early days but I'm not sure as I try to avoid that process.
As for draft space, that is a new kludge which isn't working out and so should probably be deprecated. Its current existence does not seem a significant issue for this and the OP does not provide any examples.
Andrew🐉(talk) 08:17, 20 December 2020 (UTC)

Huggle & Rollback

Huggle is a fantastic tool for MediaWiki counter-vandalism. Despite being stuck in read-only mode on enwiki, using it in combination with Twinkle to take actions is a far better workflow than alternatives I'm aware of; however, it's unnecessarily laborious with several more clicks required to get anything done.

My personal experience with RFP/R
I've actively edited since November 2019, my first request for rollback was declined[12] due to removal of one PROD tag (as I was unaware of the policy at the time) and reverting one edit I misunderstood for humor. These were two small-fish mistakes within a sea of successful counter-vandalism actions & were not repeated; I was asked to re-apply in 3 months by the declining administrator.

Several months after the previous request, I re-applied[13]. This time, it was declined with the reason of not providing sufficient edit summaries. I explained Twinkle was my primary counter-vandalism tool which supplies edit summaries automatically & by default doesn't request any additional details for vandal rollback. In response to this, I was scrutinized fairly for one incorrect MOS revert. The declining administrator also raised two 3RR reverts and a test edit revert which they found concerning (none of these, or indeed any other edits, had been raised on my talk page or otherwise as concerns prior to this), I stood by these edits as accurate and have not yet recieved a follow-up.

Any mistakes or inaccuracies in my work are acknowledged and are learning experiences, I have yet to repeat the same concern twice; any issues which have been raised to me are seemingly minor and infrequent.

I've rolled up the comments above as the focus in the responses is primarily on these specific instances rather than opinions on the RFP/R process as a whole - the discussion I'd like to have. My concerns circulate around RFP/R being used as a vehicle for those who only wish to access Huggle (which inherently doesn't need the rollback user right).

You'd be hard-pressed to find an editor which hasn't made mistakes at some point. The criticism from administrators on declined requests, as welcome as it is, I don't believe has anything to do with trusting a person has the judgement to do a thing. As Twinkle and other tools provide editors with exactly the same outcome as a rollback, the user right effectively serves to gatekeep tools which could potentially be disruptive if used inappropriately.

Compiling Huggle without the check for rollback
As per WP:IAR I've now compiled my own version of Huggle (skipping the artificial client-side check for the rollback right by adding a single character to the source code, inverting the logic (site->GetProjectConfig()->RequireRollback to !site->GetProjectConfig()->RequireRollback). To allow Huggle to revert edits; I enabled the Use software rollback option in preferences which simply uses reverts instead of rollback, mirroring Twinkle's behavior. This is not in bad faith, nor is it tool misuse as my intention is merely to be more efficient at fighting vandalism and functionally my usage of Huggle over Twinkle will be no different. As per Huggle's licensing, you're entitled to make this type of change. If there's a policy which you believe this violates, please let me know.

The assisted editing policy allows the use of Twinkle and other tools which require human interaction to assist with repetitive tasks. Huggle is no exception here as it requires human interaction. After a single edit with my version of Huggle following this change I was blocked. I followed the block with an appeal which was declined. The block was overturned due to this technicality; so, I don't want to encourage this specific behavior, but I hope it highlights the contention around the use of this software.

This brings me to the discussion I'd like to have with other editors: do we believe the requests for rollback permission process is neutral? This may be a biased opinion, but I believe the requirements for permissions are vague at best and rest with an administrator's opinions which are - from my experience - inconsistent and not particularly aligned. I struggle to see the value of a privillege granting exercise & lifting of an artificial restriction which requires the discretion of a single person without consensus. I don't believe the RFP/R process is fit for purpose to permit editors use of a "more powerful" counter-vandalism tool which is already permitted by policy for all editors (performing exactly the same operations as Twinkle and RedWarn). I hope we're all here to build an encyclopedia, not to hold the keys to some special club.

Thanks for reading through this, feel free to tell me I'm completely wrong, and I look forward to any and all opinions. ~ Chip🐺 20:25, 16 December 2020 (UTC)

Your second request for rollback was declined for more reasons than not providing edit summaries. The fact that you have characterised it as such here can only count against you. You are clearly technically competent enough to change Huggle, but that is totally unrelated to the skills needed to write an encyclopedia or pass judgement on other's efforts to write it, as shown by your even contemplating doing so, let alone actually going through with it. Phil Bridger (talk) 21:18, 16 December 2020 (UTC)
Hi @Phil Bridger: I did elaborate on the other concerns above and acknowledged the declined request was not only due to edit summaries. I'm not here to discuss these specific instances, moreso the process in general. Thank you otherwise for your comments. ~ Chip🐺 19:53, 18 December 2020 (UTC)
No you didn't. You said "This time, it was declined with the reason of not providing sufficient edit summaries", which is simply not true. You may wish to limit the discussion to the process in general, but I prefer to focus on the fact that anyone who changes Huggle to get around the restriction placed on it is pretty obviously not someone who is prepared to collaborate on buidling an encyclopedia, including passing judgement on others' efforts to do so. Phil Bridger (talk) 21:03, 18 December 2020 (UTC)
@Phil Bridger: I see your perspective and I did over-summarize. I encourage any editors reading this to follow the hyperlink to RFP/R rather than relying on my recount here ~ Chip🐺 00:23, 19 December 2020 (UTC)
The "in 3 months" recommendation was after 3 months of active editing. You only have about 1 week of active editing since your last request. You stopped arguing about it on January 14, and then made only a handful of edits until December 1. Your next request was on December 3. I will gladly tell you: You are completely wrong. I'm not sure how you're sure Huggle is so much better if you've never used it, anyhow. power~enwiki (π, ν) 02:49, 17 December 2020 (UTC)
@Power~enwiki: agree. Hopefully we can discuss the concerns regarding the request for permission process in general rather than these specific instances. (to address your last point; I've deployed Huggle on the a large non-profit wiki farm, I've used it there unrestricted for quite some time) ~ Chip🐺 19:53, 18 December 2020 (UTC)
This one is kind of funny. An editor who had his rollback request declined multiple times forked Huggle and removed the RequireRollback restriction. In their unblock request, they argue that there is nothing wrong with this because they're just using open source software that doesn't require rollback. This is like a burglar who made a copy of a house key arguing in court that it wasn't unauthorized copying because the key is out of patent so anyone can make a key, and it wasn't breaking and entering because, after all, he had a key! 😂 Levivich harass/hound 00:30, 18 December 2020 (UTC)
Well, since a "rollback" can be done "manually" by even non-logged-in editors by opening an old revision and saving it, that might not be the best analogy. Besides, there are other tools out there that provide rollback-like functionality without having the rollback user-right. Rollback is nothing more than a time-saver. Well, it does give you one more thing: An easy way to edit without thinking then be called to account for it later. davidwr/(talk)/(contribs) 🎄 01:07, 18 December 2020 (UTC)
@Levivich: I'm glad this was amusing. I've modified the content above to clarify some points. I was within my rights take those actions. The issue I'm trying to highlight is the gatekeeping of software which is technically permitted by policy. I don't believe a barely relevent process as a vehicle to lift this artificial restriction is fit for purpose. ~ Chip🐺 19:53, 18 December 2020 (UTC)
Well, Huggle is open source software. No policy explicitly prohibits doing exactly that. One could call it GAMING but I would say that's a stretch, personally. If we want to make a general policy prohibiting usage of any fast-acting anti-vandalism tool from non-rollbackers we should do that. imo this is equivalent to one making their own anti-vandalism software that is just as fast as Huggle without having RBer. That having been said, one should do some self-reflection on why they haven't been granted rollbacker (afaik pretty much a 'shall grant unless reason given not to' right). Usually it's for a good reason and a person should address those issues. As for Huggle, there's a very good reason why it's limited to rollbackers: it's very easy to cause a real mess if using it without having an understanding of WP:VAND and WP:NOTVAND. I think filtering for Huggle/SWViewer is only real point of rollbacker now, given its software functionality is now part of Twinkle.
As for the PERM process, requesting perms anywhere on Wikipedia (except to an admin individually) is too awkward. It really shouldn't be, since people (at least those not primarily motivated by the hat) are volunteering to give up their time, for free, to help in another perpetually backlogged area in which they either have some skill, or a brain + the ability to gain some skill. That I don't think is fixable. Relating to your rollbacker request specifically, if I were you I would probably just contact some kind, knowledgeable admin individually on their talk page and ask for feedback on your anti-vandalism work. They'll either give feedback, or they'll say you're doing good enough and give you rollback. If they give feedback, catch up with them in 3-4 weeks and see if they think you've improved. Plenty of admins around that will be happy to help out. Unless you're sure you're blatantly overqualified (ie someone will  Done within 15 minutes) my current view is not to touch the PERM process unless necessary, simply because the focus there is not editor improvement but to evaluate single requests and get them off the board. ProcrastinatingReader (talk) 20:46, 18 December 2020 (UTC)
A stretch? No, it's one of the most blatant examples of gaming you can get. This is nothing to do with copyright, so the licence under which Huggle is released is irrelevant. Phil Bridger (talk) 21:32, 18 December 2020 (UTC)
Whilst this may be questionable, it's quite illogical to enforce and it's also explicitly not a violation of any PAGs. No community consensus documented in a PAG states that high-speed anti-vandalism tools (or simply any semi-automated anti-vandalism editing) are restricted to RB. This argument is akin to saying the existence of WP:Twinkle or similar tools is WP:GAMING because they replicate userright-limited rollback functionality. Rollback at least has consensus behind it, afaik the Huggle limitation does not. There is this but this is the developer choosing to implement feedback, not a consensus creating an onwiki limitation in PAGs. Absent such policy, there is no tangible distinction between Huggle, Twinkle, or a custom-coded tool. ProcrastinatingReader (talk) 00:09, 19 December 2020 (UTC)
I agree with Phil. The license does not matter in this case. Say I download Kali Linux, which is licensed under the GPL. I modify the software contained inside to, for example, DDOS a website. Just because I modified the software doesn't mean that my DDOS was legal. It still breaks laws that are put in place to prevent DDOSing. ―sportzpikachu my talkcontribs 03:05, 19 December 2020 (UTC)
This is not the same thing at all. There are actually laws that make DDoS attacks illegal. There is no PAG which makes what was done here wrong, as made clear at WT:BOTPOL, and trying to shoehorn PAGs into a situation which is not covered by one is just, no? ProcrastinatingReader (talk) 11:19, 19 December 2020 (UTC)
As per Huggle's licensing, since you've added that in, is irrelevant. You may be permitted to modify the software without restriction, but it is also the case that your onwiki activities related to that software may be curtailed until you meet the social requirements on the wiki in question, in this case having rollback permission on English Wikipedia (which is the software's default state). I would decidedly call running it here WP:GAMING the permissions check and think your block in that regard was quite within that administrator's right. That Wugapodes unblocked you on a so-called 'technicality' is stretching it in my view without considering the right policy (which is indeed WP:GAMING), and his opinion espoused at your talk page really should have been posted here, not there. That said, I am glad you have realized after the unblock that it was a bad idea to circumvent the check and am also glad that you agreed not to run the software until you have the permission (again, after the unblock).
I will probably be starting a discussion at WT:BOTPOL about this basic loophole, since that is the controlling policy in this case.
As for the presumed main thrust of this thread, you might consider starting a new thread or hiding away anything related to the specific issues you have experienced since it detracts and distracts from your pain point, which is that WP:PERM sucks in some way or another. A simple {{collapse}} should suffice. --Izno (talk) 21:35, 18 December 2020 (UTC)
That discussion now at WT:BOTPOL#Removing restrictions in software. --Izno (talk) 21:45, 18 December 2020 (UTC)
I don't think this is a BOTPOL matter. This is localised to the rollback perm, which de facto serves as a user perm to restrict access to third party software. Indeed, no other perm does this. If this is the intention, WP:ROLLBACK (the guideline) should be amended to make clear that non-rollbackers are not permitted to use fast-acting anti-vandalism tools, whether they are Huggle/SWViewer, modified, or completely self-coded. Because all three of these things are, technically speaking, equivalent. In the meantime, I think it's a stretch to call this GAMING and sanction an editor for it, because we haven't even created this "social restriction", despite this not being the first time someone has done this. ProcrastinatingReader (talk) 21:44, 18 December 2020 (UTC)
The reason I selected BOTPOL was because WP:MEATBOT is in that policy, and I would suggest all of the above tools fall into being controlled by MEATBOT. We don't have a separate "use of tools" policy anywhere otherwise. --Izno (talk) 21:47, 18 December 2020 (UTC)
I think this is really problematic to add into BOTPOL. How much modification of AWB is acceptable until it's no longer considered AWB & I can use AWB without requesting access to AWB? What if I make my own script from scratch to do the same thing (a particular semi-automated edit)? What if I base this script off AWB's regexes? Similar to the Huggle situation. Lines can't be drawn here, which is why making a BOTPOL restriction for this is difficult. If the issue is with rollback, apply the restriction to that guideline, but honestly I think nothing should be done unless it can be shown that the edits themselves are disruptive, problematic anti-vandalism edits. This is also the only enforceable remedy. Also, if the edits aren't problematic I don't see what the big issue is. And it's quite rare that someone is actually capable of, and does, edit the source of a tool and recompile it, so it's not the kinda thing worth legislating over I think - more harm than good will come of it. ProcrastinatingReader (talk) 21:53, 18 December 2020 (UTC)
You should discuss adding it to BOTPOL at the thread I started there, not here. --Izno (talk) 21:54, 18 December 2020 (UTC)
I didn't realise you started one -- I'll copy this there. ProcrastinatingReader (talk) 21:56, 18 December 2020 (UTC)
@Izno: I don't really know where to put this response since there's a lot of threads on this, but hopefully here's sufficient. WP:GAMING requires that the gamester be circumventing a policy, quite literally it says Gaming the system means deliberately using Wikipedia policies and guidelines in bad faith to thwart the aims of Wikipedia. No one has said what policy prohibits running modified versions of Huggle. No one has said that Chip was doing this in bad faith. No one has said that Chip was thwarting the goal of building the encyclopedia. This isn't gaming. Even if it were, that policy says A warning from an administrator is usually the best way to prevent gaming, because a clear warning should help correct both good-faith mistakes and bad-faith games Where was the warning? Chip just got an indef block for running software that no policy says he is forbidden to run. Even if this were gaming, we didn't even follow the policy-documented best practice to prevent disruption.
Huggle's authors may want to check for particular permissions but (1) they allow anyone to remove them and (2) Huggle's documentation doesn't magically become policy. In contrast, we do have a community ratified policy on semi-automated tools and no one, and I really mean no one, has said what part of that policy requires that editors only run official versions of software or that editors must seek approval before using semi-automated tools that they wrote. No one has even claimed that the "spirit" of BOTPOL was to require those things because that claim is absurd. Anyone who has ever written a user script knows that the reality is exactly the opposite: we modify semi-automated tools all the time and do not need permission from anyone to run them. If that's not allowed, then it's weird that Chip is the first and only person to be blocked for it.
The reason in the block log was, verbatim, "Using Huggle without approval" which simply is the exact opposite of what our policies allow. If you want to say Chip is gaming the system, you need to point me to a policy or discussion that demonstrates a community consensus that running a modified version of Huggle is forbidden. If you cannot do that (and I firmly believe no one can because it doesn't exist) then WP:GAMING is a completely invalid reason to block someone. As multiple editors have said at the BOTPOL discussion (and as I said in my unblock rationale) unless an editor is harming the encyclopedia, the specifics of their software are immaterial. That software-agnostic-disruption-sensitive spirit is in WP:MEATBOT, it's in WP:ASSISTED, and it's founded in WP:PREVENTATIVE. If Chip has been disruptive or harmed the encyclopedia, go ahead and block for that. But the biggest row I've seen is not due to Chip's editing but from people mistaking Huggle's source code for community policy when it isn't. — Wug·a·po·des​ 06:31, 19 December 2020 (UTC)

Separate from the user at hand, I do think a discussion of how Rollback is handled is in order. With Twinkle, the only additional power I've found that Rollback gives (apart from the ability to use Huggle) is the ability to revert changes that removed URLs on the blacklist. "Rollback" is an important permission for historical reasons, but it's largely a societal one rather than one gate-keeping powers of note today. power~enwiki (π, ν) 03:09, 19 December 2020 (UTC)

  • I said my bit about Chip on their user talk, so won't repeat that. I do want to agree with Power~enwiki that I think rollback is a largely useless permission. I'd prefer we just deprecate it as a user group and distribute the rights to other user groups like page mover or autopatrolled. Beyond that, I think using MediaWiki permissions to limit use of external software is a bad idea since it gets into the realm of scope creep. — Wug·a·po·des​ 05:21, 19 December 2020 (UTC)
    Page movers and autopatrollers aren't necessarily competent with anti-vandalism patrol, nor are many anti-vandalism workers going to be entitled to other user rights. The merging of Rollback with unrelated user rights doesn't make sense to me. You're right, Rollback by itself is a low-stakes tool that isn't particularly useful on its own, but Power's passing mention that it grants the ability to use Huggle is far more significant. It's a pretty powerful tool that certainly should be restricted to users who are screened and approved as competent anti-vandalism patrollers. ~Swarm~ {sting} 05:55, 19 December 2020 (UTC)
  • If editors are permitted to fork Huggle and remove the rollbacker requirement (which requires changing one character in the code, as described above), then rollbacker is no longer needed to use Huggle. We might as well remove that requirement from the main Huggle script. If rollbacker is no longer needed to use Huggle, then rollbacker more or less has no purpose (since the one-click revert can be done with scripts). If rollbacker has no purpose, we might as well get rid of rollbacker. Levivich harass/hound 06:13, 19 December 2020 (UTC)
    I agree. I never understood why rollbacker is still here in the first place, when there's Twinkle which can be as fast as the original rollback tool, and is just better since you can provide an edit summary (which the original rollback tool doesn't have, and if you want that, you will need userscripts, which just brings us back to Twinkle). Huggle also doesn't seem to be as too powerful to require permissions. I'd say that VisualFileChange from Commons is more dangerous and powerful. And the Commons community doesn't require any special permission to use it. pandakekok9 (talk) 07:05, 19 December 2020 (UTC)
Agreed, but editors are not permitted to use workarounds to bypass the Rollback requirement for Huggle or similar software. This gets into WP:NOTBUREAU and WP:COMMONSENSE. IIRC last time I tried to even raise this question with the community, the community rejected the premise of the question, saying that obviously the restriction applied to Huggle clones and that even bringing it up for debate was stupid. ~Swarm~ {sting} 07:26, 19 December 2020 (UTC)
pandakekok9, Swarm as a regular user of the tool, I disagree with the assertion that Huggle also doesn't seem to be as too powerful to require permissions. While the core functionality is similar to tools like Twinkle or Redwarn, it is significantly faster. Twinkle requires multiple, deliberate clicks to revert and warn someone; Huggle requires nothing but pressing "Q". From a purely technical standpoint, the hypothetical maximum revert rate is probably 10+ times faster. While it is correct that the outcome of a Huggle revert is no different than with any other means of reversion and warning, the pace is such that I'd be very uncomfortable with indiscriminately granting access. I don't think it should be used by anyone who doesn't have significant antivandalism experience. We already have occasional problems with inexperienced patrollers being too trigger-happy with reverts and warnings – access to Huggle would only exacerbate that problem. Access to fast-paced tools requires that people know when to slow down, and that's something you only learn with experience. It's true that PERM/R is mostly PERM/H (either "hat" or "Huggle") at this point, but I don't really see the problem with that. Sure, we could go with an AWB-like whitelist system, but, considering that existing processes prevent tools like Huggle from becoming a net negative to the encyclopaedia, why bother? The only real change I can see is that the tool will be marginally slowed down because it can't use the native API call anymore. Blablubbs|talk 10:47, 19 December 2020 (UTC)
@Blablubbs: if the issue is with rate, the revert change API method should be rate-limited with explicit permission (bot flag) to request removal or extension of the limit. ~ Chip🐺 19:52, 19 December 2020 (UTC)
@ChipWolf: the issue is with pace and function more generally. Huggle is inherently a fast-paced tool, no matter the technical limits on revert rate, and it should stay one – allowing indiscriminate access to Huggle only to then modify the Rollback API and require people to be bot-flagged creates a problem just in order to solve it by expending unnecessary time and effort. I fail to see what's wrong with the current system; just like we do with AWB and bot operation, we require that users demonstrate some level of understanding of how to use them correctly. Blablubbs|talk 20:07, 19 December 2020 (UTC)
@Blablubbs: You're 100% right, Huggle is one of the most powerful tools on the project due to the speed and simplicity in which it lets you execute tasks. That's a feature, not a bug. That's what makes it one of the best tools. Huggle does not need to be fixed, it simply needs to be limited to highly competent users. And that is what we already do. The fact that this user apparently raged that they couldn't get Rollback, for simple, obvious straightforward reasons, tried to WP:GAME our rules, got blocked for it, and is now trying to make it seem like they're a victim and that we're the problem is kind of sad. ~Swarm~ {sting} 02:19, 20 December 2020 (UTC)
@Swarm: this is uncalled for; I'm not playing victim, I'm highlighting a concern. Nor were my actions WP:GAME; Gaming the system means deliberately using Wikipedia policies and guidelines in bad faith to thwart the aims of Wikipedia. Despite this, I agree with you in part; Huggle is a powerful tool, and it is indeed one of the best tools. I also agree with Blablubbs in that users should probably demonstrate some level of understanding, however the RFP/R process is not fit for that purpose, and determining that understanding in such a way which doesn't undermine the use of WP:TWINKLE and WP:REDWARN is difficult. ASSISTED and BOTPOL as they stand allow the use of reverts and semi-automated assisted editing, providing they are not DE or MEATBOT, no policy does or should restrict the use of specific software or modifications to open-source as these tools don't define policy ~ Chip🐺 19:13, 20 December 2020 (UTC)
Editors cannot use the pagemove script without being a page mover because it utilises restricted perms so it literally can’t work properly without the right. Huggle doesn’t need to use software rollback, heck the software literally adds in undoafter for ‘rollback-like functionality’ which anyone can use. Ergo, the requirement Huggle developers choose to add is not policy. You can’t shoehorn BURO into this — it’s either policy or it isn’t, and it isn’t. It’s like me doing something someone else doesn’t like, then getting sanctioned under “I think this is silly, a policy doesn’t exist for me to block you but NOTBURO block because this is silly”. You will agree with me that would be unfair, yes? Also WP:COMMONSENSE supports what this editor did: The principle of the rules—to make Wikipedia and its sister projects thrive—is more important than the letter. - that revert improved, not caused harm to, the encyclopaedia. A good a use of IAR as any. ProcrastinatingReader (talk) 11:24, 19 December 2020 (UTC)
saying that obviously the restriction applied to Huggle clones and that even bringing it up for debate was stupid not a stupid question at all. If the community wants to limit WP:ASSISTED and the fundamental right of free software development by making it so that all derivatives, even if substantially changed, must carry over access requirements set by the prior developer, that is a significant change which should definitely actually be codified into policy if it’s to be enforced. Probably at WP:ASSISTED. ProcrastinatingReader (talk) 11:34, 19 December 2020 (UTC)
PR, what a radically purist interpretation of IAR to apply it to software restrictions! It's invigorating to consider. But then what is to stop me from writing scripts that mimic restricted functions? It's possible to write a script (like the "nuke" script that was deleted by consensus) that partially blocks an editor from a page (or sitewide), or that protects a page by automatically reverting edits based on who made the edit. If the reverts that the script does are valid standing on their own, then they improve the encyclopedia and ergo it's OK to use the script? So I can write a "page protection script" and then go respond to RFPP requests (which are backlogged) on the theory that using scripted page protection improves the encyclopedia at least until the RFPP backlogged is cleared. Same with a blocking script and responding to AIV reports when it's backlogged. And if I can do that... I mean, I might actually do that, if it were allowed. In which case, we could almost deprecate the admin group along with rollbacker. But the nuke script raised holy hell, as I remember, so I'm not sure IARing around software restrictions is a concept that has consensus? And it seems to come down to unbundling. If an editor can fork Huggle and remove the rollbacker requirement, there is no reason to have a rollbacker requirement in Huggle at all. Similarly, if an editor can use a "page protection script", there's no reason to bundle protect right into the admin group; might as well just give it to everyone. But then if we did that with protect, or block, it would be chaos. I mean what I'm describing sounds even to me like some form of wikiterrorism, but I guess one person's wikiterrorist is another person's wikifreedom fighter? There must be a line somewhere? Levivich harass/hound 20:04, 19 December 2020 (UTC)
Well this is the thing: an editor is always accountable for their actions. Script or no script, disruption is disruption, and bad admin actions are bad admin actions. The community can impose restrictions on any editor's activity at AN/ANI. or that protects a page by automatically reverting edits based on who made the edit this is really automated editing, as you're not reviewing it, so it has to go through BRFA. Even if it's semi-automated (you have to click 'OK') you'll probably end up foul of WP:MEATBOT at some point, if not WP:HOUNDING. Hence, assuming semi-automated, you're responsible for the nature of the actions themselves (which are problematic). Similarly, the nature of an automated script that auto-reverts on a particular article is subject to BRFA; in the semi-automated form if you reverted a good edit you'd be sanctioned for a variety of things, not least misuse of rollback, edit warring and general disruption -- and WP:MEATBOT still applies.
The difference here is that the Huggle editor is using a tool and making the correct actions (presumably). If they made disruptive reverts, those would incur sanctions just like any other disruptive or otherwise problematic edit. If they showed a pattern of poor judgement and disruption, rollback is yanked / they're told to stop using their tool. If they fail to adhere, they get blocked for disruptive editing. If however they're doing good reverts and improving the encyclopaedia, well, nothing to see here... ProcrastinatingReader (talk) 20:35, 19 December 2020 (UTC)
As an aside, I'm curious what this nuke script situation is about? ProcrastinatingReader (talk) 21:17, 19 December 2020 (UTC)
@PR: OIC... the automated/semi-automated distinction is a good place for that line. Re the nuke script: I was thinking of the super-rollback scripts like Twinkle Meganuke [14] [15]. Levivich harass/hound 03:00, 20 December 2020 (UTC)
@Levivich: I'm in agreement here, if the editor doesn't violate some other policy (MEATBOT/HOUNDING etc, as PR mentions) the line should be under clearly automated tools which require little to no human input ~ Chip🐺 18:24, 20 December 2020 (UTC)
The line can be drawn anywhere that consensus decides it should be drawn, but it is totally unrelated to the specific technical mechanism by which edits are undone. This is a restriction related to encyclopedia-building, not something to be blatantly gamed by those with the technical know-how. Building an enclyclopedia is not a branch of computer science. Phil Bridger (talk) 18:50, 20 December 2020 (UTC)
@Phil: I'm not sure what this adds, but again I don't disagree with you ~ Chip🐺 19:17, 20 December 2020 (UTC)
This is where WP:NOTBUREAU and WP:GAME comes into play. If the community places restrictions on a tool, you can't just clone the tool and run the clone instead. That's just basic, obvious Wikipedia norms. We've accounted for this. You can't circumvent rules by finding loopholes and exploits. The rules continue to apply. I don't get your fixation on "free licenses", it's literally so irrelevant. Just because you can legally do something doesn't mean you're automatically allowed to do it on Wikipedia, where we have our own rules. This entire thread is one of the more bizarre things I've seen in a while. ~Swarm~ {sting} 02:19, 20 December 2020 (UTC)
That's the thing: the community didn't create a PAG prohibiting this - it could cover all of these cases with a sentence to BOTPOL or RB, and it didn't. It's certainly not mentioned in any PAG that I can find. Some editors requested the Huggle dev add controls, and the dev did, and that's a totally separate thing. If I add an access limitation to User:ProcBot and open source it, can I request an admin block whoever uses it without obeying my limitations? Similarly (assume I don't have rollback) if I create my own anti-vandalism tool can I not use this? If I add a limitation of rollback to my tool and open source it and someone removes that, is this suddenly now worth a gaming block? I (as the developer) cannot unilaterally set policy. Either the community needs to prohibit this, or if they don't (and there is opposition to doing so at WT:BOTPOL) nobody should be blocked for not actually making a single disruptive edit. ProcrastinatingReader (talk) 03:08, 20 December 2020 (UTC)
xaosflux sums this up better than I can: if someone is being disruptive that is already enough reason to step in, and if they are not then why care? ProcrastinatingReader (talk) 03:16, 20 December 2020 (UTC)
Did the community establish the rule that Huggle is restricted to Rollbackers? If so, then you're wrong, per WP:BUREAU and WP:GAME. If not, then an RfC is needed. ~Swarm~ {sting} 03:43, 20 December 2020 (UTC)
I linked the Huggle thread above. Some editors made a feature request to the Huggle dev, who implemented it. See WT:BOTPOL for the generic change proposed by Izno to make this formally a violation of BOTPOL, with multiple editors (not just me) pointing out the issues against this change. Equally, I do not get what the big issue here is. If the person makes a problematic edit with the tool, block them for that? If they don't, why are we trying to spend community time to block good faith editors who have done nothing wrong? ProcrastinatingReader (talk) 04:10, 20 December 2020 (UTC)
The discussion about whether someone has the right to clone a tool are irrelevant. A rollbacker is not someone authorized to use a certain tool—they are someone the community believes has the judgment required to know when an edit should be reverted without edit summary (or when a meaningless and automated boiler-plate edit summary is sufficient). Johnuniq (talk) 04:13, 20 December 2020 (UTC)
A rollbacker is someone who has the user right "rollback". Any editor may do semi automated editing per WP:ASSISTED, whether that be anti-vandalism editing or anything else. If we want to limit that, WP:ROLLBACK should add wording stating "use of anti-vandalism tools is limited to editors with the 'rollback' user right". iirc Twinkle core has a button that allows people to revert without summary, so we may want to start there. ProcrastinatingReader (talk) 04:18, 20 December 2020 (UTC)
That's simply, objectively, not true. A rollbacker is someone who has the technical authorization to the "rollback" tool, but they are also, by extension, authorized to use a much more powerful tool that most users will never have access to. Saying that rollbackers are merely users with access to a stupid, worthless MW software feature does not and will never make it so. ~Swarm~ {sting} 04:35, 20 December 2020 (UTC)
It's not entirely worthless, I use it all the time. What you say is contrary to the guideline: The Rollback user right provides users with a button that will revert, with a single click, the last edit to a given page, along with any consecutive previous edits made by the same editor to that page. - even if that is how we choose to use it currently. Why not propose changing the wording of WP:RBK? If it's so obvious to some then adding it in will cause no harm, yes? But no admin should enforce their own version of the guideline without adding the change in with due process and adequate community scrutiny. ProcrastinatingReader (talk) 04:42, 20 December 2020 (UTC)
Because the longstanding status quo is perfectly appropriate and will continue to be perfectly appropriate. Huggle requires Rollback, that's just the way it is, and if you don't like that, I'm sorry. It's not some procedural irregularity. ~Swarm~ {sting} 04:56, 20 December 2020 (UTC)
Of course, it's not just me. Multiple admins have disagreed with this kind of enforcement, here, at the user talk, and at WT:BOTPOL. It should be obvious that this is controversial enough that it should actually be passed by RfC to enforce. That a block for this was undone by another admin should be evidence enough. ProcrastinatingReader (talk) 04:59, 20 December 2020 (UTC)
Consider an unprivileged editor who found a flaw in MediaWiki and wrote a tool that allowed them to patrol new pages, or to change page protection, or block vandals. By the above reasoning, we would be arguing whether any of the editor's actions were inappropriate—if not, carry on, nothing to see here. I'm not saying that such an editor should be indeffed—indeed, we should thank them for finding a vulnerability. The point is that procedures are based on principles, not the particular words that appear in a policy, and the editor would have to stop using their tool. Johnuniq (talk) 05:59, 20 December 2020 (UTC)
Sure, but that’s exploiting a software vulnerability to take privileged actions. Reverting is not privileged (the software basically provides rollback in the form of the “undoafter” param, available to all), distinct from "rollback" which is privileged but (as xaosflux said) has a very specific meaning in the MediaWiki software. Reverting with undoafter ≠ rollback. If it were, Twinkle would be banned. ProcrastinatingReader (talk) 14:02, 20 December 2020 (UTC)
  • I haven’t looked too closely at this; but the reason we usually say that people can’t use mass anti-vandal tools without rollback is that they become extremely annoying because of the MMORPG aspect if there isn’t some barrier to entry (I’ll go ahead and call out using WP:REDWARN earlier this year when it first premiered as the most recent memory of large scale vandal fighters who were more annoying than the vandals they were fighting.)
    I see Wugapodes has unblocked, which I don’t really disagree with, and I have also disagreed with people on the social vs. license bits of anti-abuse work, but I think both the Red Warn fiasco earlier this year where a bunch of absolute newbies were being targeted for a semi-automated tool in order to make it popular, and this show that there is a general consensus that semi-automated tools that allow one to engage in mass rollback beyond what Twinkle does should have some barrier to entry. I don’t think putting this at the bot policy makes sense as that tends to be frequented to a small group of people, but I think amending WP:ROLLBACK to specify that tools designed to rapidly revert edits from a large amount of pages in less than a minute require a barrier to entry of some sort before use would be in line with the general frustration that occurs every time this happens. I’ll also ping Iridescent as he typically has sane views on stuff like this. TonyBallioni (talk) 06:22, 20 December 2020 (UTC)
    When Gurch originally wrote Huggle it didn't have an entry requirement, and very quickly had exactly the problem RedWarn had; it acted as a magnifier for overenthusiastic new editors who didn't really understand what they were doing and reverted too many good faith edits without explanation, so he added the "requires rollback" to allow us to take the permission away from editors without blocking them altogether. (There's no 'consensus' as such as he made the change unilaterally and nobody objected.)

    Wikipedia precedent is that what we appear to have here—forking mass-changes scripts as a way to grant oneself access to a tool one normally wouldn't be allowed to use—is considered "unauthorised bot use" and dealt with as such. See the histories of Rich Farmbrough and Magioladitis for the precedents. ‑ Iridescent 07:51, 20 December 2020 (UTC)

    @TB: rate should be covered by BOTPOL, @Iridescent: tools and the developers for those tools don't define wiki policy, even if they did; the Huggle developers explictly grant a license to allow users to modify the tool. As mentioned several times in this thread, Huggle is a semi-automated tool which requires human intervention and is covered by MEATBOT and ASSISTED; unless policy is changed, enforcing this loosely defined decision by a developer undermines the use of other semi-automated assisted-editing tools and indeed, development of new tools. PR frames this better than I can: this is the developer choosing to implement feedback, not a consensus creating an onwiki limitation in PAGs. Absent such policy, there is no tangible distinction between Huggle, Twinkle, or a custom-coded tool. ~ Chip🐺 19:42, 20 December 2020 (UTC)
    The issue with going off bot policy is that a significant number of people who think this type of behaviour is disruptive couldn’t care less what the bot policy says. It’s a fairly limited group of people who pay attention to it until there is some major catastrophe where a bot operator single-handidly manages to anger the entire community.
    There is widespread agreement that there should be a limit to these tools, and while it’s not a policy because our community (wisely) doesn’t dictate the specifics of what can and can’t be done for every piece of software, inevitably a check system is always put into these tools because of the aspect Iridescent and I mentioned: overeager new editors who have appointed themselves Guardians of the Wiki without understanding how the project functions.
    While you are free to fork open source software and use it, this community is also free to make the ad hoc decision that what you are doing is disruptive to how we function. Disruptive editing is a catch-all that covers people acting in a way outside of our behavioural norms. One of those norms is seeking input from the community when attempting to do something controversial. You have received input from the community that what you want to do is not welcome, and you’re arguing that you can do it anyway because of the license, which ignores the point that no one is discussing the license, but is instead discussing how you edit the English Wikipedia. That is disruptive, regardless of what any policy says. Part of working on a collaborative project is being willing to stop and slow down when people point out a concern to you, especially if that concern is shared by many people from varying backgrounds. I’m totally fine documenting this somewhere since we’ve apparently entered the age of people forking stuff when they’re told they can’t do something, but the fact that we haven’t documented it yet doesn’t mean it’s not a generally agreed standard of behaviour. TonyBallioni (talk) 21:13, 20 December 2020 (UTC)
    @TonyBallioni: there's very clearly opposing opinions on the topic; I see no consensus this was DE and have also recieved input from some of the community that what I did is welcome. The license is only a small part of the conversation; I think it's the smallest and least relevant factor. You say part of working on a collaborative project is being willing to stop and slow down when people point out a concern to you, especially if that concern is shared by many people from varying backgrounds. What's most confusing to me here is I did stop and expressed that I had no intention to continue - until there's a formal change - immediately following the unblock, I said as much and have continued this discussion in attempt to reach some consensus on the topic. I'm here to point out one of my concerns - which I'd hope we're all entitled to do - and there's clearly still discussion to be had; the fact a unblock denial was reverted by another admin should be enough to highlight the clear controversy surrounding this topic. Collaboration does not imply one should accept the status quo. ~ Chip🐺 22:47, 20 December 2020 (UTC)
    Yes. That you offered to stop is a good thing. I appreciate it. In terms of the “not seeing consensus”, depending on how you count it: there are roughly 9 editors saying what you’re proposing is disruptive and is outside of community norms and 4 saying it’s okay. That’s a greater than 2:1 ratio of this is not okay. Just because there’s some disagreement doesn’t mean that there isn’t a sense of don’t do that in this discussion. Consensus is not unanimity, and just because you and some others are vocally disagreeing doesn’t mean that the majority position isn’t the majority position. TonyBallioni (talk) 23:11, 20 December 2020 (UTC)
    @TB: Agree. This isn't yet a proposal or a discussion regarding if or not I should be blocked any longer (I hope). In regards to rollback and Huggle as a whole, I'm seeing 21 editors between here and BOTPOL with 14 leaning towards changing rollback/policy or leaving situations like this unenforced (8 of which stated they had no issue, 4 found concern with my actions), and 7 additional editors against these actions altogether with some discussion of implementing it in policy. I might've miscounted as that was gathered rapidly, but I think there's likely still enough of a split to begin either a new focused discussion or an RfC (perhaps holding off for a little while WP:MULTI). Would you agree? ~ Chip🐺 01:17, 21 December 2020 (UTC)
    From what's been posted publicly, I think "welcome" is overstating a bit. There are those who don't think a block was warranted (and accordingly it was lifted), but I don't think anyone said that modifying Huggle is a welcome approach. isaacl (talk) 23:15, 20 December 2020 (UTC)
    @Iridescent: Are there specific discussions you're thinking of? Looking at the block logs for Rich and Mag, it seems like their blocks were for disruptive editing using (semi-)automated tools. The findings of fact in Rich's ArbCom case mention disruptive editing, but not script modification as reasons for banning him from using automated tools. The discussion on Magioladitis' talk page seem to focus on violations of WP:COSMETICBOT and previous problematic editing. Unlike the present case, both seem to involve making bad edits with tools and neither seems to show tool modification. — Wug·a·po·des​ 03:34, 21 December 2020 (UTC)
    @Wugapodes:, the events themselves are something of a mess in both cases, unless you have a blinding urge to wade through very lengthy disputes spread across multiple pages. The basic principles were codified by Arbcom here; the key points for this particular issue are Principle 4 (anyone using an automated tool is deemed to have a heightened responsibility to the community and will lose the right to use that tool if they're deemed not to respect the community's wishes regardless of whether they're acting in good faith), Principle 5 (someone who looks like they're running a script will be treated as if they're running a script) and FoF 5 (modifying a script to run without the requisite bot flag will be treated as a bot even though it doesn't have the bot flag), but the whole thing is worth a read. Wikipedia:Arbitration/Requests/Case/Magioladitis 2 is even more of a mess; the key part is from FoF 8 ("continuing to make semi-automated edits after being asked not to by community members [is] disruptive"). ‑ Iridescent 18:24, 21 December 2020 (UTC)

There are two aspects to this scenario: security from destructive actions, and designating certain sequences of actions to be limited to specific users. Regarding the first, leaving authorization to the client is not secure, and so if this is deemed to be a significant risk, the server will have to be enhanced to try to prevent harm (for example, it could throttle risky sequences of requests through delays, by requiring the user to solve a CAPTCHA (yes, there are accessibility issues that would have to be resolved), or something else).

Regarding the second, we should focus more on what sequences of actions should be limited rather than a specific tool or client. In other words, writing any script/tool/client to perform rapid reverts (or, perhaps more generally, any rapid sequence of edits) is a problem, whether or not you started with an existing tool. The problem is that many editors tend to think safety guards are for someone else. That's a policy problem to be resolved. Should anyone seeking to make edits quickly (through tools, scripts, or just clicking submit on many tabs in a row) be required to have rollback privileges? (This would effectively make rollback privilege a proxy for allowing all rapid sequences.) isaacl (talk) 21:20, 20 December 2020 (UTC)

  • I've opened a discussion at WT:ROLLBACK about explicitly limiting high-speed reversion software to rollbackers. – Teratix ₵ 23:39, 20 December 2020 (UTC)
  • My views on this align with TonyBallioni's. I'll add that, in my view, the community has already had the expectation for years that the rollback permission should be required for Huggle specifically. This is because it allows its user to make very rapid reverts that, when used incompetently, can result in an inordinate amount of damage to the project. Frankly, since Twinkle already provides the same onwiki-level functionality that rollback provides, I would go as far to say that WP:PERM/R is commonly understood nowadays as a gatekeeper for Huggle. The relevant question for admins who work there is: do we trust this user's ability to distinguish good-faith edits from vandalism to the extent that we can allow them to make hundreds of these reverts per hour? Against this backdrop, I do think it was improper to circumvent the WP:PERM/R review process by modifying and recompiling the source code. As far as a policy/guideline solution to this, I would support codifying the rollback requirement for Huggle and any tool that would provide Huggle-like rapid revert functionality. Mz7 (talk) 08:29, 21 December 2020 (UTC)

Are ABC News, BBC News, CBS News, NBC News, and Reuters publishers or works?

There is a discussion at User talk:Citation bot#BBC News et al (again) over the question of whether ABC News, BBC News, CBS News, NBC News, and Reuters should be referenced in {{Cite news}} with |publisher= or |work=. Interested wikipedians are encouraged to discuss it there. —Anomalocaris (talk) 06:06, 27 December 2020 (UTC)

Naming convention for sports stadia

A request for comment is open regarding the use of parenthetical disambiguation in relation to articles on sports stadia here: Wikipedia talk:Article titles#RfC Naming convention for sports stadia. Input is welcome. Stevie fae Scotland (talk) 20:15, 28 December 2020 (UTC)

Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Village_pump_(policy)/Archive_162&oldid=999803347"