Wikipedia:Village pump (policy)

 Policy Technical Proposals Idea lab WMF Miscellaneous
 .mw-parser-output .module-shortcutboxplain{float:right;border:1px solid #aaa;background:#fff;margin:0 0 0 1em;padding:0.3em 0.6em 0.2em 0.6em;text-align:center;font-size:85%;font-weight:bold}.mw-parser-output .module-shortcutlist{display:inline-block;border-bottom:1px solid #aaa;margin-bottom:0.2em;font-weight:normal}.mw-parser-output .module-shortcutanchordiv{position:relative;top:-3em}.mw-parser-output li .module-shortcutanchordiv{float:right} The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines. If you want to propose something new that is not a policy or guideline, use Village pump (proposals). If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards. This is not the place to resolve disputes over how a policy should be implemented. Please see Wikipedia:Dispute resolution for how to proceed in such cases. Please see this FAQ page for a list of frequently rejected or ignored proposals. Discussions are automatically archived after remaining inactive for two weeks. « Archives, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159

RfC: Locality categorization by historical subdivisions

While there is significant support for limiting the categorization of current localities by historical subdivisions in some way, no clear criterion emerges to do so systematically.

The consensus is to stick with the status quo (option C), by using common sense to assess on a case-by-case basis whether the categorization of a page reflects a relevant historical fact rather than a cataloguing attempt.

Pintoch (talk) 11:50, 2 May 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.

Question: What should the general rule/principle/guideline be for categorizing current localities by historical administrative subdivision in Central and Eastern Europe? There are quite a few articles of cities and towns that have been categorized not only in which administrative subdivision they currently are in, but also by the former subdivisions.

Typical example: Eišiškės, a small town in Lithuania, is in these categories: Category:Cities in Lithuania, Category:Cities in Vilnius County, Category:Šalčininkai District Municipality, Category:Vilnius Voivodeship, Category:Lidsky Uyezd, Category:Nowogródek Voivodeship (1919–1939). The first 3 categories reflect the current administrative subdivision. Vilnius Voivodeship was a subdivision in 1413–1795. Lidsky Uyezd was a 2nd-level subdivision sometime between 1795–1915. Nowogródek Voivodeship (1919–1939) was an inter-war subdivision.

General options:

• A: categorization should be limited - by what? Whether it is referenced in the article? How long the subdivision lasted? How large the subdivision was? To the 1st-level former subdivision? To how recent subdivision was? Etc?
• B: categorization should not be allowed (i.e. current localities should be removed from the former subdivision categories; historical information could be preserved in a different venue like a separate list or an addition to the locality article or something similar to the "historical affiliation" box as in Görlitz#History)
• C: status quo; no general rules; specific issues with individual categories should be addressed at WP:CfD

22:24, 21 February 2020 (UTC)

Major concerns with such categories:

1. WP:OR/WP:V: many of the locality articles do not even mention or reference former subdivisions. In Eišiškės example above, only Nowogródek Voivodeship is mentioned in the article body (added by me 12 years ago without a reference). What is the basis to claim it was in the Lidsky Uyezd? An editor looking at a map? Finding out former subdivisions is not always straightforward, particularly for smaller towns or for older subdivisions – some medieval regions did not have well defined borders, while in more recent years administrative border adjustments are frequent.
2. WP:NONDEF: if many of the articles don't even mention the historical subdivision, it cannot be the defining characteristic (which is the central goals of the categorization system).
3. Confusion for readers: in the example of Eišiškės above, could you tell which of the 6 categories is for the current and which is for the former subdivision? (this could be somewhat alleviated by better category names)
4. Clutter/maintainability: Görlitz lists 23 different countries/states (not to mention subdivisions) that it was a part of. Should all of these be represented in a category? If not all, then which ones?

Examples of categories: just some samples from different countries. Category:Kingdom of Galicia–Volhynia (did not have well-defined borders), Category:Republic of Central Lithuania (has other valid historical articles mixed in with current localities), Category:Telshevsky Uyezd and Category:Minsky Uyezd (2nd-level subdivision), Category:Lithuania Governorate (subdivision that lasted 5 years), Category:Ținutul Nistru (existed for 2 years), Category:Belastok Region (short-lived WWII subdivision), Category:Province of Catania (subdivision renamed in 2015), Category:Localities in Western Moldavia (without digging, can't tell whether current or historical subdivision), Category:Province of Westphalia.

Why this RfC? There were some CfD discussions over the years (ones that I am aware Aug 2015 (delete), Sept 2015 (delete), Oct 2015 (no consensus), Apr 2017 (no consensus)) but they did attract much attention (unlike AfD, CfD rarely attracts outsider attention), yielded inconsistent results, and did not hash out what should be done with these categories in general. And these categories keep proliferating. Therefore, looking for a broader principle-based discussion here, rather than individual consideration of specific categories at CfD.

Side note: some locality articles have "historical affiliation" boxes (example: Görlitz#History), though in some others it was removed as "nightmares" or "LISTCRUFT". And a user got blocked for adding them (and refusing to communicate).

Pings to users I came across editing related categories/CfD discussions (some might be inactive): User:Pamrel, User:Sabbatino, user:The-, User:Poeticbent, user:Lekoren, User:Biruitorul, User:Marcocapelle, User:Oculi, User:Peterkingiron, User:RevelationDirect, User:Dahn, User:Carlossuarez46, User:Laurel Lodged, User:Ejgreen77, User:Hugo999, User:Aleksandr Grigoryev, User:Piotrus. Notices posted to Wikipedia talk:WikiProject Categories, Wikipedia talk:Categories for discussion, Wikipedia talk:WikiProject Cities, Wikipedia talk:WikiProject Former countries, Wikipedia talk:WikiProject Poland, Wikipedia talk:WikiProject Germany, Wikipedia talk:WikiProject Ukraine, Wikipedia talk:WikiProject Romania, Wikipedia talk:WikiProject Moldova. Apologies if I missed anyone or any project. Renata (talk) 22:24, 21 February 2020 (UTC)

Opinion poll: Locality categorization by historical subdivisions

A: definitely should be limited to may be current immediate subdivision and may be the historical in which a populated place was established. For the "historical affiliation" box mentioned above for Gorlitz, it should be avoided as a spam as it simply fails the Manual of Style for flags WP:MOSFLAG and infringes on original research WP:OR due to political speculations. Aleksandr Grigoryev (talk) 22:59, 21 February 2020 (UTC)
Aleksandr Grigoryev: I thought about it, and I don't think it's a workable solution. Many places don't have a specific founding date and they are just mentioned in written sources in year x, or even more broadly in century y. Plus what makes the first subdivision so special? Further, I don't think it's maintainable. If you think about it, it still means that there will have to be categories for all historical subdivisions of that region as localities were founded/mentioned in different times. So, for example, there will have to be a category for Vilnius Voivodeship that contains localities founded/first mentioned in 1413-1795 and for Lidsky Uyezd that contains localities founded/first mentioned in 1795-1915. But then, it's likely that someone will decide that the category on Lidsky Uyezd is not comprehensive and start adding articles purely by geographic location. Renata (talk) 03:15, 24 February 2020 (UTC)
A (Current Subdivision and Historical One at Founding) I'm with Aleksandr above, the current geographical subdivision and the original seems reasonable. So Marseille would be both in the current French subdivision and be noted as a former Greek colony. (I don't want this approach to throw out all historical/former city categories beyond subdivisions though: Category:Former national capitals and Category:Populated places along the Silk Road both seem defining.) RevelationDirect (talk) 00:31, 22 February 2020 (UTC)
C. This is far too broad a question and these things badly need to be determined on a case by case basis. Some of the above shouldn't have locality categorisation in this way. Some of them should. The idea that we can answer them on a global basis with reference to a handful of subdivisions in eastern Europe is the sort of discussion that leads to all kinds of ridiculous situations when applied to local situations in places nobody was giving thought to. The Drover's Wife (talk) 00:54, 22 February 2020 (UTC)
The Drover's Wife: not really looking to write any policy here, but just to get a rough idea/consensus from the wider community on what categories should or should not be present in locality articles. It would be very helpful if you could expand on your comment "Some of the above shouldn't have locality categorisation in this way. Some of them should." -- which should (not) and based on what criteria? Even if just considering the examples listed above. Renata (talk) 01:46, 22 February 2020 (UTC)
I am woefully under-educated about the history of this specific region and I'd hate to give pronouncements on things I don't understand well enough to have a sensible opinion. I'm just extremely cautious of a discussion like this creating a rule that then gets applied to completely different circumstances in other places. The Drover's Wife (talk) 03:23, 22 February 2020 (UTC)
B (A if we have to): Limited to current subdivisions only, as has been the long established practice; bio articles relevant to the polity itself are also currently placed in the category named for that polity -- it is Category:People of medieval Wallachia, but not Category:People from Saac County (i. e. a defunct county in said Wallachia). This avoids a massive overcrowding. I don't see when populated places would be placed even in articles pertaining to those polities, let alone their subdivisons; only nostalgia and irredentism can be the driving factors here, and neither is encyclopedic. Current subdivision also establishes a neutral standard: populated places that were once in Romania are categorized by their current subdivision in Ukraine, but the same standards would apply to localities in Romania that were once in Hungary. Dahn (talk) 05:46, 22 February 2020 (UTC)
A or B, one could say "A, because we should allow this if a historical subdivision is a defining characteristic of a locality", but in practice it never is a defining characteristic, so A and B are very similar. Marcocapelle (talk) 08:47, 22 February 2020 (UTC)
A. Current and historical are enough. Historical division/subdivision should at least be mentioned in prose before including it. In addition, as already noted by other editor, the "Historical affiliations", including the mentioned problems, should be removed, because it is unsourced, trivial, and just takes up unnecessary space of the page. – Sabbatino (talk) 11:13, 22 February 2020 (UTC)
Sabbatino: Can you clarify which "historical" is enough? All of the examples above are "historical" so you are not actually limiting to anything. Renata (talk) 15:56, 22 February 2020 (UTC)
Country and first level division (governorate, state, province, etc). – Sabbatino (talk) 13:05, 24 February 2020 (UTC)
C I'm with The Drover's Wife on this. It's unwise to make policy decision on such a broad front. Examples can be listed of multiple short-lived political entities to which a city may have been attached over many centuries; it would probably be excessive to make the city a child of all of them. Cities changed hands multiple times in the Holy Roman Empire. On the other hand some administrative sub-divisions, while practically defunct, nevertheless remain on the statute books. For example Thurles (civil parish) is in the ancient barony of Eliogarty. While Eliogarty no longer has a practical administrative function, it has never been legally abolished. I would not like to see Thurles being removed from Category:Eliogarty. In summary, such thingsare best decided on a case-by-case, CFD basis. Laurel Lodged (talk) 11:36, 22 February 2020 (UTC)
As per your own comment, the barony in question still exists, in some definition, and the first verb in Eliogarty is "is". This is therefore an irrelevant example to this particular discussion, equivalent at best to including cities and towns in their traditional or cultural region. Dahn (talk) 10:03, 23 February 2020 (UTC)
C Per The Drover's Wife above. I believe handling this on a case-by-case basis and category-specific CFDs is the way to go.--Darwinek (talk) 16:01, 22 February 2020 (UTC)

Ok, I have narrowed down the geographic focus of the RfC just to Central and Eastern Europe (because that's really where the issues are). Ping to editors who already commented, in case that changes their thoughts: Aleksandr Grigoryev, RevelationDirect, The Drover's Wife, Dahn, Marcocapelle, Sabbatino, Laurel Lodged, Darwinek. Renata (talk) 16:09, 22 February 2020 (UTC)

• No Change in View Based on the limitation of scope to the discussion. RevelationDirect (talk) 19:24, 22 February 2020 (UTC)
• Comment - CFD Piecemeal Approach A CFD discussion is just as likely to suggest a global approach as this discussion might suggest a case-by-case approach. The area I have concern with is the subcategories of Category:Districts of East Germany, where we categorize literally every populated place that used to be part of the GDR by former region, which doesn't seem remotely defining to me. If I nominated that tree for deletion, it's likely to come up why I'm not nominating the Lithuania examples Renata provided. Does anyone see a difference between those two examples? RevelationDirect (talk) 19:24, 22 February 2020 (UTC)
• I'm not sure why it would come up. It doesn't follow that that what might be appropriate in one situation must be appropriate to another in a completely different geographical, political and historical context because they're both abolished institutions. If you think the German and Lithuanian ones you've both mentioned are equivalent and that they suck, nominating them both is a much better outcome than attempting to make global policy affecting thousands of situations you haven't considered. If you're preferring the few-heads global policy attempt because you think you're going to lose a CfD on the two (I don't know, this is emphatically not my area of knowledge in the world), that should tell you something. The Drover's Wife (talk) 20:23, 22 February 2020 (UTC)
• I'm not sure anyone can name a situation when categorizing by past subnational entity would benefit anyone. Mind you, we're not talking about examples such as "Ancient Greek colonies" or "Former capitals of...", none of which actually refer to a subdivision. We are talking about subdivisions for all purposes defunct, and the type of info one would be able to recover from the article and/or a map. Nobody would benefit from having Places in modern-day Turkey grouped under their former Ottoman vilayets, though the article on both the place and the vilayet should include references to one another, at least once theyre both developed. Dahn (talk) 09:59, 23 February 2020 (UTC)
• ...unless someone was trying to find out what happened to the cities that were once within a particular Ottoman vilayets. I'd expect that to be unusual, but I can imagine it happening (at least for larger cities). (That sounds like a great school assignment: "Pick one of the Ottoman vilayets we've been talking about this week, figure out what it's biggest city was, and find out what's happened to that city since then.") WhatamIdoing (talk) 18:59, 25 February 2020 (UTC)
• : Except we are not a teaching aide (leaving aside that "go on wikipedia and click two links" isn't really a proper assignment at all). Dahn (talk) 14:02, 1 March 2020 (UTC)
• Whether it's "proper" is going to depend on the context (e.g., age of the students and whether this is meant to be an important assignment or just a few minutes' homework). I do not say that we have to accommodate that reader. I only say that when billions of people have access to Wikipedia, the odds are high that at least one reader would sincerely appreciate whatever seems unimportant to any given editor. WhatamIdoing (talk) 03:02, 2 March 2020 (UTC)
• : The main point is that we're not here to offer that kind of assistance. Dahn (talk) 05:33, 2 March 2020 (UTC)
• We should be here to provide every type of encyclopedic information. Some of our tools for doing this are pretty awful at the moment (consider, e.g., the necessity of Category:18th-century British women writers, when it'd be better to have a way to record the simple facts of "18th-century", "British", "women", and "writers" and let the software combine them). The same general type of system could be used for geography: Here is the location, and now give me a list of every relevant Wikipedia article. It'd be clunky to do this with just categories, but I hope that in the future, people will be able to look up any the patch of dirt and see all of its history, from well before being absorbed into the Ottoman empire, through the creation of the province/vilayet system, to the end of the Ottoman empire, and what's happened since then. I think that helping people understand history is consistent with our goals. WhatamIdoing (talk) 06:10, 2 March 2020 (UTC)
• One can understand the point of having women who lived in the 18th century and practiced a certain trade, and were of a certain nationality, in a standalone category, however: the encyclopedic relevance of having articles placed in defunct administrative divisions is entirely unproven, and unargued -- beyond "it would help hypothetical students perform a hypothetical inane assignment with even more ease". What we do have from the above is your hope that we should all embark on this "patch of dirt" pet project (which, btw, is an immense task you unload on anyone writing articles on such topics, without offering them the option to refuse -- since once this is a standard, everyone will be expected to follow it). Instead of simply dreaming of how interesting it would be to have that goal materialized, you could consider that it has no objective use, while demanding a lot of work from "someone else". Dahn (talk) 06:38, 2 March 2020 (UTC)
• I don't think so. We already put {{coord}} in articles about geographical areas, and Special:Nearby already lets you find articles within a certain distance of your location. Wikivoyage (and other projects) is using Wikidata, Commons, and/or OpenStreetMap to mark territories (e.g., Alpine County#Communities – the region, not just a single point within it). It doesn't seem impossible to take that existing data and using something similar to Special:Nearby to find all the articles that are within that arbitrary shape, rather than all the articles that are within a certain radius of a single point. None of this would require any extra work from editors. WhatamIdoing (talk) 16:30, 2 March 2020 (UTC)
• I'd go with B, with the usual allowance for exceptions in exceptional cases. This is a classic list role. All the problems that afflict using a category for this information would disappear if using a list. A list is also much easier to maintain and add any necessary qualifiers to (as might be needed for example if administrative boundaries shifted during the relevant historical period). As a bonus, a list is also much more likely to attract the attention of contributors with relevant historical expertise. I can see no reason why the approach would be different from one geographical area to the next; the arguments with respect to Central and Eastern Eurperiodically I ope would seem to apply equally well in any other geographical context. -- Visviva (talk) 04:33, 24 February 2020 (UTC)
• C. I'm not sure why this is such a contentious issue. If the town existed in the past as part of a former subdivision, why would it be inappropriate to note that? It actually sounds fairly useful; if I were trying to find out what was the extent of and former municipalities in, such-and-such of a now-defunct province, the categorization of places into such categories seems like a natural way to do that. --Jayron32 18:53, 25 February 2020 (UTC)
• @Jayron32: Because it adds a million categories that could be simply replaced by lists in/alongside articles, and because it serves no purpose other than to satisfy dreams of lost glory? Dahn (talk) 14:04, 1 March 2020 (UTC)
• I'm leaning C (no particular rules). I'm not sure that every little village that was once part of the Roman empire should be categorized that way, but Vienna was the capital of multiple empires/nations, and it seems odd to limit its categorization to only the most recent. WhatamIdoing (talk) 19:00, 25 February 2020 (UTC)
• C. Should be treated case-by case basis, and the text must support categorization, with valid refs. In fact it is often important to know who belong where at a particular time, and periodically I am thinking about adding a kind of timeline template to articles about locations. Staszek Lem (talk) 20:07, 25 February 2020 (UTC)
• C (A if we have to): Definitely not B. When talking specifically about Central and Eastern Europe, some places actually have more connection to their former subdivision in terms of historical importance than their current one, so it would be strange not to categorize them by their former subdivision. Ejgreen77 (talk) 11:43, 26 February 2020 (UTC)
• Ejgreen77: can you give an example of "some places actually have more connection to their former subdivision"? Renata (talk) 18:21, 3 March 2020 (UTC)
• A/C Some of these categorisations (and not only for former east European areas, it goes for the whole of the world) are utterly confusing (at least in my opinion). There are objects that are categorised by current areas where the organisation never existed in that current area (organisations (in the most broad sense of the word) that have been discontinued well before the current area where they would have been if the organisation still existed existed (intentionally confusing sentence)). I had to look, but 1962 Northern Rhodesian general election was once categorised in Category:1962 in Zambia where Northern Rhodesia was renamed in 1964 to Zambia (this one has since been fixed: Wikipedia:Categories_for_discussion/Log/2013_June_18#1935_establishments_in_Zambia; however, there is still Category:Elections in Zambia on the article ...). Within the volatility of the 'countries' in Europe in the past, there are many cases where things happen to an organisation while they are in A, then country changes to B and something else happens, country changes again, to C, and they stop existing, and if they would now still have existed they would now be in D ... Categorisation in these cases should be limited (A) and well thought through (which is basically what should happen now: C). --Dirk Beetstra T C 06:24, 2 March 2020 (UTC)
• C I'm with User:Staszek Lem on this one: if referenced text in the article supports the historic categorization (and thus it's presumably appropriate text that does not violate WP:UNDUE), then the cat should stay. But if no referenced article text supports the category, then the categorization is the result of original research and should be removed. UnitedStatesian (talk) 19:16, 6 March 2020 (UTC)
• Unarchived to request closure at WP:ANRFC. Cunard (talk) 00:58, 5 April 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.

Is it time to place greater restrictions on AfD?

Deletion discussions remain one of the most hotly controversial parts of the project, but the bar for participation is lower than most other controversial parts of the project.

Bad faith nominations are a common form of harassment or POV-pushing, and while such nominations are rarely successful, there are no protections in place to prevent it from taking a toll on the victim (in cases of harassment) or taking a large amount of volunteer time (for harassment or for POV-pushing). Starting a deletion nominated currently requires autoconfirmed status (4 days + 10 edits).

Once the nomination is started, it's common for people associated with the subject to use social media channels to influence the discussion (whether to support or oppose deletion). New users who sign up just to advocate a position in a deletion discussion rarely take the time to familiarize themselves with Wikipedia's deletion-related policies and guidelines, leading to large numbers of low quality !votes that complicate discussions. In very rare cases, after discussions are already severely affected by canvassing, we semi-protect them. Canvassing creates a lot of drama, rarely helps a deletion discussion, and wastes a huge amount of time and energy.

Is it time to place greater restrictions on AfD? Three inter-related questions for the community. Please note that this is not a proposal, but a discussion to see if a proposal makes sense.

1. Should there be stricter requirements to start a deletion discussion?

2. Should deletion discussions be semi-protected by default?

3. If yes to either of the above, what is the best way to allow new users to participate productively (for example, using AfD talk pages)?

Rhododendrites talk \\ 22:10, 9 June 2020 (UTC)

Discussion (AfD restrictions)

• Some context for why I started this thread: For years I've participated at AfD and have seen the problems caused by canvassing over and over again. So question #2 has long been on my mind.
What has me thinking about question #1 took place over the weekend: a Wikipedian created an illegitimate sock puppet for the sole purpose of nominating for deletion three related articles: Anna Gifty Opoku-Agyeman, Corina Newsome, and Earyn McGee. It's not the first time I've seen people use AfD to nominate groups of related articles in bad faith, nor the first time I've seen it used to to target biographies of women or people of color in particular. It didn't take long to cause a stir on Twitter, etc., perceived as yet another example of systemic bias on Wikipedia.
Of course, those of us insiders know that this was actually an example of process working in the end -- that this was just one illegitimate sock puppet causing trouble, and the articles had little chance of being deleted because it's "not a vote" and whatnot. Here's the thing, though: it's still damaging. Bad faith nominations are not only a huge time sink to the community, requiring people to make sure process does win out; it's also a terrible experience for the article creator/editors, it's a terrible experience for the article subject, and it's a terrible experience for anyone else who looks in and cannot be expected to see what we see. They see Wikipedia working on deleting a topic they care about, and cannot be expected to understand the "don't worry, it's not a vote, and process will win out" part that we might say to ourselves while grumbling.
So I, for one, do think it's time to raise the bar a bit. How much to raise it is the big question as far as I'm concerned. — Rhododendrites talk \\ 22:10, 9 June 2020 (UTC)
On the last two of those, unless I'm missing something, that was an empty nomination ? I would say that admins should feel empowered to close empty or bad faith nominations, especially if they believe they may draw external involvement (Which should be taken as a given for any BLP for anyone of an underpresented minority on WP). If an experienced editor believes the article does merit deletion, let them open a fresh deletion discussion with proper rational (and there should be no penalty here if that's opened even the same day as the rapid closure of the previous one). We may not catch all the bad faith ones, if they are nominated with a reasonable cause (as the first of your three appears to be on a first quick read), but at least we shouldn't let the clear bad ones linger for the 7 required days and cause long term problems --Masem (t) 22:26, 9 June 2020 (UTC)
Right. Like I said, process usually wins out, but why is this permitted to begin with? How often do you see successful, good faith, policy-based nominations from new users, as compared to the kind of problems caused in this example? How many of those positive examples could be handled through other means (e.g. requesting an AfD at WT:AFD, PROD, etc.)? My central point about question #1 is about new users' nominations being a net negative, and that the negative effects probably reach further than most people would think, because we tend to think of AfDs as being behind-the-scenes projectspace business. — Rhododendrites talk \\ 22:32, 9 June 2020 (UTC)
I think the deep problem is identifying bad faith nominations. I worry that closing empty nominations is not a robust solution to the problem, because it doesn't take much for disruptive editors to learn how to give the appearance of a rationale. Just quickly looking back over the (all presumably good faith) AfDs I've participated in this year, the modal deletion rationale is typically one sentence along the lines of "This article does not meet the notability guidelines", and (very reasonably) nobody blinks an eye when that's written by an editor with a few hundred edits who stacked a dozen pages in AfD in one afternoon with identical rationales -- most of the time, that sort of deletion is just a user who spent a few hours helping to build the encylopedia by patrolling for non-notable pages, and decided they found several. So I worry that resting everything on an idea like "admins should delete any rapid string of AfDs by a new editor with empty/totally trivial deletion rationales" just moves the problem to a question of how to tell the difference between good faith (but perhaps rather lazy) tagging on the one hand, and disruptive trolling on the other. In this situation, for example, it seems reasonable to guess that with a bit more effort the person who started this AfD might have been able to write a persuasive appearance of a sincere deletion rationale, since they openly admitted to being a sockpuppet during the AfD (as was noted at AN). And that same AfD but with a policy-motivated deletion rationale would still have been subject to all the same canvassing, spam, and trolling. - Astrophobe (talk) 23:06, 9 June 2020 (UTC)
Empty nominations are easy. And given that most experienced editors know of the BEFORE process and how to nominate, I could see that when we have a sub-par nomination (no sign of prior research, maybe just claimed "person is non-notable", and a quick check of the target AFD page shows 20+ sources with clear reliable sources being used, they can do this rapid close and add something in their close "Any experienced editor, believing this was a valid AFD, may reopen/restart this". Heck, that's even better, just have the rapid close if the admin thinks it is a bad faith AFD, but if an experienced editor thinks it is valid, they can ask to have the nomination opened again on the admin's talk page, mimicking the process one uses to question the standard admin closure process.--Masem (t) 23:49, 9 June 2020 (UTC)
@Masem and Astrophobe: we need to be more nuanced instead of immediately calling this a "bad faith nomination" just because the nominator chose a sock-puppet account rather than their established Wikipedia identity. As someone who has recently been singled-out and targeted by a right-wing website for my involvement in blacklisting The Epoch Times, I can understand why someone wanted to shield themselves from the backlash of a self-righteous Twitter mob crying racism and sexism. --bender235 (talk) 13:57, 10 June 2020 (UTC)
I would never base a "bad faith nom" on the basis of the account only, unless I know that editor has some type of block/warning or the like specific on using AFD in that topic area or in general. (eg, someone that I know has a AP2 DS on them that they are not to make any edits in that area, and they nominate a topic clearly in the AP2 topic area, that's a bad faith). Barring knowledge of that, the only assessment of "bad faith" is the nature of the nomination and the actual sate of the page - is there a massive disconnect that indicates that this may be a POINTy or nonsense AFD that AFD doesn't need to waste its time with. I agree we should not judge the editor - IP, new editor, or experienced - otherwise in evaluating whether an AFD is good or bad faith normally. --Masem (t) 14:07, 10 June 2020 (UTC)
That is good to know, but I felt like having to emphasize it because the general conclusion in WP:ANB seems to have been along the lines of "three AfDs were started by sockpuppets accounts with a vengeance," i.e. not worth being taken seriously (I'm quoting Silver_seren specificly, but it was more or less the general opinion). --bender235 (talk) 16:20, 10 June 2020 (UTC)
I mean, if this solution I suggest is implemented, and one finds that a single user has been submitting several AFDs in a row that have been quick closed as these bad faith noms and suspects possible sock activity, by all mean then check to see if the editor is a sock. But the editor should not be pre-judged outside of any known DS/bans attached specifically to that editor's name if we all for evaluating bad faith noms. --Masem (t) 16:28, 10 June 2020 (UTC)
• First off, I would be against semi-protection by default because many articles listed for deletion are from new editors, and they should be able to participate in the deletion discussions of their articles. While this doesn't always wind up for the best, I imagine locking them out of the discussion or bunting them to an unseen talk page would have even worse outcomes. However, I would be in favor of raising the bar for filing a deletion to extended confirmed, as virtually all new page patrollers will meet that standard easily, and it will create a significantly higher hurdle for bad-faith actors. This won't stop PROD or CSD tagging - but that's a feature, not a bug. Both are easily removed in cases of abuse, and let people that are not extended confirmed and still want to help address the worst new articles. The Squirrel Conspiracy (talk) 23:03, 9 June 2020 (UTC)
• This is a good point. I actually intended to be less specific than "semi-protection by default" in order to allow for that one exception (article creators/editors weighing in), but forgot when it came time to hit save. — Rhododendrites talk \\ 23:35, 9 June 2020 (UTC)
• Thanks for starting this discussion Rhododendrites, and I think it's worth reinforcing that this problem of targeted and high-profile bad faith deletion spam is not at all new, and that with the growth of conversations about Wikipedia across other major platforms, I expect this sort of canvassing to only grow more severe. Per the opening paragraph of the discussion and per The Squirrel Conspiracy, I expect that I would agree with a proposal to require a higher bar to begin AfDs. But requiring a higher bar to contribute to AfDs is, to my mind, much more complicated. On the one hand, I am really sympathetic to the argument that it would be dangerously discouraging to new editors. I remember vividly my early experience editing Wikipedia: I believed that about ${\displaystyle 3/4}$ of whatever you do on this website will get rapidly undone for completely opaque reasons, with lots of giant paragraphs full of incomprehensible acronyms and links and all sorts of emphatic italics about how astonishingly bone-headed you must have been to write that content (I'm not saying that's the impression people were trying to give, just that that's how it often feels to very new editors). People absolutely should be encouraged to WP:BB from their very first edit, including writing pages from scratch, and if their page comes up for deletion they should be allowed to participate in the discussion on it. From personal experience I believe that good faith participation in AfDs by brand new editors who don't yet have a clue is a huge net good for the project, especially as a hugely important (if often unpleasant) learning experience for them. Nothing motivates you to wade deep into notability policy like trying to come up with an argument for why your afternoon of work shouldn't be undone. Having said all of that, not raising the bar for AfD participation leaves half of the problem we're talking about unaddressed: it means that canvassing good faith and constructive deletion discussions is still just as easy, whether you're trying to sway the discussion towards keep or delete. It's very easy to imagine a good faith editor questioning the value of a page about someone with tens of thousands of twitter followers and that person reacting by canvassing support, just as happened in this instance, in which case we would be in the same exact position that we're in now. So I would be very interested in discussing further policies that would allow people with a sincere connection to the page to participate, while ruling out the kind of canvassing that is already a very serious problem and that looks like it will only get more serious over the next few months and years. - Astrophobe (talk) 23:44, 9 June 2020 (UTC)
• I honestly don't see it as a problem. Most of the time canvassing is obvious and the topics are notable. I actually got stuck into the project because I wasn't specifically canvassed, but I read something about whether something should be on Wikipedia off of Wikipedia. Not being able to participate may create a "walled garden" effect for the entire community. That being said, there is a bad faith nomination issue, it was obvious in the cases you mentioned, and we need to do a better job of a community of not defaulting to "no consensus" when a deletion discussion goes off the canvassing rails, but I don't really support increasing the standard threshold. For instance, this should be very unlikely, but there may be instances where a low profile BLP realises there's an attack page written about them here and needs to deal with it. I might be willing to support a specific action item, though, such as a flag when a non-extended confirmed user starts an AfD. SportingFlyer T·C 01:47, 10 June 2020 (UTC)
• I would oppose these type of changes. Its hard enough to delete an article as it is. Think about it, it only takes one person to create a bad article, but many to have it deleted. And when we can't agree and the AfD is closed as "no consensus", it gets kept by default. This actually contradicts WP:ONUS where the person adding the material must get consensus, not the person proposing deletion. As for sockpuppets, that is not a issue exclusive to AfDs. They can show up in any discussion anywhere.--Rusf10 (talk) 02:07, 10 June 2020 (UTC)
• can show up in any discussion anywhere sure, but in structured discussions they can be more disruptive. it's also a place where it's much less likely they'll be able to contribute positively. in an article talk page, there's at least an argument from the perspective of knowing the subject; arguing about notability is a bit more, well, technical from a procedural standpoint. — Rhododendrites talk \\ 23:52, 13 June 2020 (UTC)
• Right, canvassing for keeps is a huge problem. And isn't that what Rhododendrites's suggested point 2 addresses? The way I read it, the problem you describe is a big motivation for that remedy. - Astrophobe (talk) 04:52, 10 June 2020 (UTC)
I would even equate off-line canvassing by a subject or by a connected contributor to COI editing. Point 2 of the proposal would not take care of the issue (most of these accounts were autoconfirmed, just dormant), and probably has zero chances to pass at any RfC anyway.--Ymblanter (talk) 05:51, 10 June 2020 (UTC)
• Bender, are you suggesting that the three articles in question should have been deleted? That they are "Wikipedia shrine[s] for their personal vanity" in your book? Axem Titanium (talk) 07:39, 10 June 2020 (UTC)
• I do agree with you that offline canvassing is essentially just COI editing. What I do not think is clearly true that most of the accounts in the recent spate of canvassed AfDs were autoconfirmed editors -- look at the two rapidly closed (and therefore actually readable) AfDs at Corina Newsome and Earyn McGee. Both of them were absolutely overrun by IPs and single-purpose accounts. It's easy enough to say that the suggestion as written here so far wouldn't perfectly solve the problem or is pretty much guaranteed to fail at RfC, both of which I agree with. More interesting is asking how we can tweak AfD to make it robust to these sorts of multi-front attacks from the outside, which have already been seriously disruptive and I believe will only grow more severe. It could very well be that the answer is there is no possible reform and we just have to live with this issue, but I don't think that's possible to conclude without some more discussion. - Astrophobe (talk) 08:14, 10 June 2020 (UTC)
• I think if every instance of canvassing on twitter would result in a COI template appearing on top of the article, and potentially in an appearance of a paragraph explaining how he subject was canvassing on twitter then they will start thinking twice before starting canvassing. I agree that semi-protecting AfD would generally help (though not entirely) to this issue, however, it is not really desired from other points of view, and this discussion so far shows a clear opposition to this proposal. In addition, I have no idea what to do if (i) a Wikipedia editor canvasses other sympatheric Wikipedia editors outside Wikipedia (which happend a lot and in the past resulted in keeping clearly non-notable articles) and (ii) people are showing upat AfD and it is clear that they are correlated but the source of canvassing could be found. --Ymblanter (talk) 10:02, 10 June 2020 (UTC)
• The really harmful perception that encourages canvassing seems to be that it's a straight up or down vote that everyone in the world has an inherent right to participate in. We already have Template:Not a ballot, but it's clearly highly ignorable for motivated people. I wonder if there is a template that is garish and intimidating enough to actually persuade people that canvassed votes won't work. Maybe a pop-up like some web sites have to discourage ad blockers, and an mp3 that autoplays a siren noise when you load the page ;) - Astrophobe (talk) 18:31, 10 June 2020 (UTC)
• as Ymblanter correctly pointed out, a lot of the Wikipedians canvassed to those AfDs were inactive but established accounts. A rule limiting the participation of newly created accounts therefore wouldn't help. Of course, generally restricting sporadically active Wikipedians for !voting isn't a viable solution, either. After all, we are a project of volunteers and clearly not everybody finds time and means to contribute on a regular basis. It's just that in those particular three AfDs the canvassing was so blatantly obvious, with person after person basically copy-pasting the same rational referencing the rarely cited WP:BASIC over and over again. When I was looking for fellow veteran Wikipedians to intervene on the evening when all of this unfolded, Sulfurboy reassured me that "any admin worth their salt will see past meat and spa votes." Unfortunately that never happened. --bender235 (talk) 13:05, 10 June 2020 (UTC)
• XfD is already biased too heavily towards indiscriminate inclusionism. We smile benevolently on keep vote canvassing, and allow personal attacks on nominators to pass without comment. Now here is a proposal to skew the conversation even further away from discussion of article subjects and contents and further towards lawyerly rules about who is allowed to talk. I am not in favour. Reyk YO! 08:42, 10 June 2020 (UTC)
I'm not sure I've ever seen an indiciation of AfD being a hotbed of indiscriminate inclusionism, nor indeed community encouragement (or at least, lack of notice or reticence) on canvassing of Keep votes. Nosebagbear (talk)
This suggests that there are areas where pretty much everything nominated gets kept, does not matter whether or not material is compliant with WP:GNG. Not that I strongly oppose this, and in some areas (such as localities) it probably makes sense, but this definitely backs up the inclusionism claims.--Ymblanter (talk) 09:51, 10 June 2020 (UTC)
Well, by its nature XfD tends to attract pages that ought to be deleted so in that sense it leans towards deletionism. But what I mean is that the lenience we show to misbehaving editors correlates directly with whether they voted keep. For instance, I once objected when some pretty blatant keep vote canvassing was allowed to determine the outcome of an AfD/DRV. All I got in response was blank looks and a (hopefully not serious) suggestion to counter-canvass if it bothered me so much. That's not advice I intend to take because, even if I felt like being unethical, a delete voter could never get away with it. I could give other examples of keep voters free to make insulting personal commentary and delete voters getting in trouble for backchat but of course if I did it would only be dismissed as a list of personal grievances. Reyk YO! 10:26, 10 June 2020 (UTC)
I could understand this position regarding #1, but #2 is much more likely to apply to canvassed keep !votes than canvassed delete !votes (at least in my experience). — Rhododendrites talk \\ 23:52, 13 June 2020 (UTC)
Call me a cynic if you like, but I don't see that ever being enforced consistently. Reyk YO! 12:22, 14 June 2020 (UTC)
• So, I get both the base concern(s), but also the issue with SP - that the creator in particular is disadvantaged. On the thought of Extended-Confirmed to start an AfD - does anyone know what % of good-faith AfDs are started by non-EC users? That seems relevant here. It's a shame we don't have PC2 - this would be a great area for it. Nosebagbear (talk) 09:44, 10 June 2020 (UTC)
• AfD needs improvement, for certain. Some kind of competency requirement for nominating articles could help, so could a quicker closing process for bad nominations. Unfortunately, it's hard for me to come up with a good way of accomplishing...Jacona (talk) 12:58, 10 June 2020 (UTC)
• AFD will never be perfect and it is 100x more "friendly" than it was 10 years ago. Participation is lower as well. I see no benefit to suppressing participation any further and that is what more rules will do. Dennis Brown - 13:48, 10 June 2020 (UTC)
• This would be solved if we had more mechanical and less subjective notability rules. Then it wouldn't matter who was being canvassed. We should repeal WP:N altogether and just amend WP:V to require two independent, in depth, reliable secondary sources for every article. Then AFDs will just be about whether there are two qualifying sources or not. If there are, it can have a stand alone page. If there aren't, no stand alone page. Simple and no need to discuss whether or not something is "notable". No SNGs to argue about. Basically, make GNG a hard policy and be done with it. Levivich[dubiousdiscuss] 16:21, 10 June 2020 (UTC)
• We've seen editors try to work with more mechanical/objective application of notability "rules" , claiming things like "I have three sources, that's enough", but this makes things worse because now you have people gaming the system worse than what we see now. Also, this underminds the purpose of notability on WP, which is to reflect topics that are likely to be able to be fleshed out to fuller articles but need sourcing work to help get there, and because we have no DEADLINE, require the flexibility of judging what sourcing exists at AFD rather than rote rules to keep them. --Masem (t) 16:34, 10 June 2020 (UTC)
• @Levivich: I disagree, because that would only further muddy the distinction between what's verifiable and what's notable. Those two are not the same, and while the existence of reliable sources (i.e., verifiable facts) is necessary for someone or something to be notable, they aren't sufficient. --bender235 (talk) 16:50, 10 June 2020 (UTC)
• Going to echo Masem here and agree that this would be susceptible to gaming the system. Axem Titanium (talk) 16:57, 10 June 2020 (UTC)
• @Masem, Bender235, and Axem Titanium: Thanks for your comments. To clarify, I am indeed proposing something radical: far more than "blurring the lines" between V and N, I'm talking about getting rid of that line altogether. That's why I'm not worried about "the purpose of notability", because I advocate getting rid of the entire concept of "notability". Let's face facts: 6,000,000 articles, and they're not all about important topics. We have hundreds of thousands of articles about athletes, songs, Pokemon characters, and all the rest. If the purpose of notability is to reflect topics that are likely to be fleshed out, well, then WP:N has failed miserably at that purpose.
It's the entire concept of "notability" that is to blame: the notion that a topic has some property, "notable", that determines whether or not it should be in the encyclopedia, and we, as editors, are tasked with examining the topic and determining if it has this property or not. We act like notability is something we discover. It's not. It's something we invent. "Notability" is whatever we say it is; literally, whatever we agree to write at WP:N. If the purpose is to identify topics that can be fully fleshed out, there is no better way to do that than to identify if there are two good sources that we can use in the article. If there are two good sources, we can write an article about it that complies with V, NPOV, and NOR. If there aren't, we can't. This is the principle behind GNG, WP:THREE, WP:42, etc.
We should embrace the fact that an AFD is not about a topic's inherent property of notability, but really just about whether to have a stand-alone page or not. We should have a stand alone page if we have the sources to support it. By making the "notability" simply a matter of "sufficient available sourcing: yes or no" and not about anything else, it will be harder, not easier, to game. Every keep !vote, to "count", would have to identify the two sources, and the entire discussion would be about whether the two sources meet WP:GNG criteria. The current system is already being gamed, and has been gamed, for a long time. Gaming is what led to this thread in the first place. Restricting the conversation to just be about the quality of sourcing and nothing else, will lead to less gaming, nor more. Levivich[dubiousdiscuss] 17:30, 10 June 2020 (UTC)
• @Levivich: that's a radical idea, to put it mildly, and I'm afraid that completely eliminating the notion and threshold of notability would turn Wikipedia into somewhat of a repository for everything that was ever written, and every person that ever existed. I mean, I might be able to find a census entry and a birth announcement (two reliable sources!) of some 19th-century John Smith of Iowa, but what's the point of writing up an article recounting his dull biography of plowing the corn field from the cradle to the grave? At some point we have to be firm and say Wikipedia is just not the place for this. --bender235 (talk) 17:39, 10 June 2020 (UTC)
Bender235, 6,000,000 articles says to me that Wikipedia already is a repository for everything that was ever written. Please note that I didn't say "two reliable sources", I said "two independent, in-depth, reliable secondary sources" (in other words, same as WP:GNG), so no, a census entry and birth announcement wouldn't cut it. Requiring two GNG sources for every article will reduce, not increase, the number of stand-alone pages. Of this much, I'm sure. What makes my proposal radical is that if it were implemented, millions of articles would be eligible for deletion, which are not currently eligible for deletion, because meeting GNG isn't currently universally seen as a requirement. Levivich[dubiousdiscuss] 17:57, 10 June 2020 (UTC)
(sorry for the multiple pings), as one concrete example, under "my" suggested system, this AFD would have resulted in "delete" because there aren't two qualifying sources. Levivich[dubiousdiscuss] 18:27, 10 June 2020 (UTC)
No matter how you slice it, WP:PROF almost certainly needs to remain a standalone rule. Many academics are worth having an article written about them despite never having appeared in a newspaper. Significant coverage in secondary sources is not a requirement; merely having one's research (a primary source, albeit a reliable one due to peer review) cited heavily by other papers is sufficient to meet the bar. And we can write an article on their work using mostly those primary sources, with the reassurance that they are reliable because they have been thoroughly vetted by the academic community. -- King of ♥ 19:01, 10 June 2020 (UTC)
King of Hearts, if we did this, I would support having exceptions (specifically to the "independent" and "secondary" requirements), including PROF exception, as well as for other specific areas where there is a lack of independent or secondary sourcing, but where the community feels non-independent or non-secondary sourcing is nonetheless reliable enough to satisfy V.
Instead of asking, at an AFD, "is it notable?", we ask, "is there enough verifiable information to support a stand-alone page?" A statement, to be verified, needs to come from a reliable source (a source with a reputation for accuracy), it needs to come from an independent source (or else there's a bias concern, usually), and it needs to come from a secondary source (to avoid OR interpretation of primary sources). For an entire page to be verified (or in other words, for a topic to be verified), we also need in-depth sources: enough content to fill a page.
Even if the community adopts this view of verification, it can still decide that there are some topics, like PROF, where a "reliable source" need not be independent or secondary, and so exceptions could be made. This is also the sort of exception that could be made to address under-coverage of historically marginalized people and topics. Thinking of whether to have a stand-alone page as a matter of V instead of N is a better framework all around. And then, in AfD discussions, the only keep !vote that would count would look like "keep - [source 1] [source 2]", and it wouldn't matter if people were canvassed or IP editors or socks or whatever, because instead of counting votes, or assessing votes, we would just be counting sources and confirming that they meet "the test" and that there's two of them. Levivich[dubiousdiscuss] 20:26, 10 June 2020 (UTC)
• I agree with those who argue that an uninterpreted WP:V is not enough of a basis for deletion policy, but I agree that notability has not served us well. The problem that deletion policy is there to solve is that there are forces out there that aim to undermine the encyclopedia, so we need to choose the ground that we can defend. The notability criterion is a solution: it says the topics we should have articles for are those on which good articles could be written. I have thought since 2006 this is wrong: the criterion we should apply is maintainability, not notability, and we should deal with articles as they are, not as they might be (although I am all for editors who transform bad articles into good ones during the AfD process). The events that convinced me of this led to this AfD: Wikipedia:Articles for deletion/Stephen Schwartz (journalist), an example of something then unmaintainable that I thought should have been deleted, although the subject was notable. More recently I have been bothered by how the WP:INHERIT criterion has frequently been used to delete high-quality, well-maintained, encyclopediac content; cf. Wikipedia:Deletion review/Log/2020 June 8 for the most recent example I aware of; there are have been better exmples. We should drop the abstract ideal of notability as the criterion we use and adopt the pragmatic criterion of maintainability that I think in time would lead to a more intuitive deletion policy. — Charles Stewart (talk) 06:45, 11 June 2020 (UTC)
Speaking as a proud simpleton who loves hyper-minimalist rules, I would support this, but it seems like a different (though of course related) proposal. - Astrophobe (talk) 18:37, 10 June 2020 (UTC)
• I think one of the issues is that AFD, unlike a lot of other Wikipedia processes we think of as happening "in the background", slaps a big red notice on top of an article in articlespace. I'm not suggesting that we change this at all, but it is worth keeping this fact in mind when we discuss solutions. The notice demands your attention when you're on an article and even invites you (yes, you!) to participate in the deletion discussion. You can imagine that a new/IP user would feel confused if they're not allowed to participate at all at this point. Axem Titanium (talk) 16:57, 10 June 2020 (UTC)
If a change were made, we could update the template accordingly. Levivich[dubiousdiscuss] 18:02, 10 June 2020 (UTC)
This is a good point, thanks. If we enacted some sort of restriction like this, at very least the wording of that notice should be changed, but I'm not sure in what way. — Rhododendrites talk \\ 23:52, 13 June 2020 (UTC)
I'm sure that banner is responsible for a good chunk of the hollow "keep" votes that show up for pop-culture articles. It stands to reason that if you're looking up the article for a particular thing, you beleive that particular thing should have an article. (Even if there's no particular policy-based reason for it to.) ApLundell (talk) 14:52, 18 June 2020 (UTC)
• Personally I would support automatically adding extended confirmed protection (30 days/500 edits) to all AfDs as they are created. Positive contributions from editors not meeting these criteria are incredibly rare IMO, and it would stop SPAs, socks, IPs called from social media etc. Number 57 17:46, 10 June 2020 (UTC)
I agree with this suggestion. Article creators who are not EC can make their case on the talk page (along with other non-EC editors). EC editors can read those talk page arguments and take them into consideration in their AFD !votes. The closer can also take into consideration arguments made on the talk page. But it'll help keep the discussion more focused if only EC editors participated on the AFD page. Frankly, non-EC editors do not have the experience necessary to meaningfully contribute at an AFD, even if they wrote the article. And I say this as an editor who participated in AFDs before I was EC (and I shouldn't have, because I had no understanding of notability guidelines then [or now really]). Levivich[dubiousdiscuss] 18:01, 10 June 2020 (UTC)
• I would like to see some facts here. How many AFDs in the past month/year can we reasonably classify as being disruptive in the senses concerned in this proposal? I would say that if that number is less than 5 or 10%, I don't see a need for systemic change. --Izno (talk) 18:13, 10 June 2020 (UTC)
• What happened in the AfDs mentioned above is being repeated at Wikipedia:Articles for deletion/Capitol Hill Autonomous Zone now. What happens on Wikipedia doesn't stay on Wikipedia. With every AfD like this, someone on Twitter will be more emboldened to post their vanity shrine on Wikipedia. EC protection will really help in cases like that. TryKid[dubiousdiscuss] 22:21, 10 June 2020 (UTC)
• Will editors who are not admins be able to nominate articles for deletion? Hawkeye7 (discuss) 23:52, 10 June 2020 (UTC)
Under these suggestions anyone who is extended confirmed could nominate AFDs. Personally I would support limiting nominations and participation to extended confirmed users and the article creator because it would give more time to block the sockpuppets who seem to zero in at AFD whether they are nominating or voting, imv Atlantic306 (talk) 00:20, 11 June 2020 (UTC)
I agree with Atlantic306. Mccapra (talk) 12:01, 11 June 2020 (UTC)
• Under normal circumstances I think our AfD process works fine and don't need adjustment - usually no or minimal disruption and no need to protect the AfD until something problematic happens. For example, I recently dealt with an case where an article creator was blocked during an AfD of their article and suddenly brand-new accounts showed up to !vote. SPI, checkuser, semi-protected just because of the sockpuppetry, bam - dealt with. What we need to have a process for is cases like these, which are the exception rather than the rule - demonstrable and widespread off-wiki canvassing that turns the AfD into chaos (a flood of mostly-new users using non-policy-based arguments). I think semi-protection is the right call in most cases, but what do we do if there's demonstrable canvassing of experienced editors, for example? creffett (talk) 00:45, 11 June 2020 (UTC)
• Some of the examples listed above are quite extraordinary, I agree with bender235 that “something” needs to be done before this becomes the normal. Whilst it would not deal with bad-faith nominations and canvassed inactive users, perhaps upon presentation of evidence of off-Wiki advocacy, !votes be restricted to extended confirmed users and !votes already cast by non-XCON users be struck/deleted. Cavalryman (talk) 03:42, 11 June 2020 (UTC).
• actually what upset me the most in these Twitter canvassing campaigns is the piggybacking on a social justice cause. People weren't just told to vouch for the notability of some hashtag activists, they were sent here to fight supposedly systematic sexism and racism in Wikipedia and its entire community (see [1], [2], [3]). And sure enough the majority of canvassed !voters came waltzing in crying racism right away without even bothering to consider the arguments presented up to this point. That's what concerns me the most. Apart from slandering the Wikipedia community unjustly, it makes certain subjects and topics toxic to a point where our usual (bureaucratic) processes can no longer be applied. Who wants to be the Wikipedian permanently branded as a racist in the Twitterverse simply for questioning the notability of a social media starlet? The nominator of AfD/Anna Gifty Opoku-Agyeman stated that he/she created a sock puppet rather than use his/her established account to avoid online harassment, and perusing the comments and replies of the self-righteous Twitter mob above, I don't think that was a stretch. To me, this whole incident and its likely future copy-cat versions are worrisome. (And just to show that I am not exaggerating, here is a now-deleted tweet by MethanoJen singling me out by name, simply for questioning whether her newly created Category:Black geoscientists doesn't fit our existing category pattern.) --bender235 (talk) 16:39, 11 June 2020 (UTC)
Please write to T&S about the tweet, this is a cleart wiki-harassment. I have warned her in the morning (qand may be this is why the tweet has been deleted), but if I have seen this I might have indeffed.--Ymblanter (talk) 17:41, 11 June 2020 (UTC)
bender235, I agree completely, aside from the utterly appalling conduct of that editor the broader trend in identity politics is to brand anyone who presents a rational and articulate counterpoint a racist/bigot/Nazi etc, thankfully not a common issue in the dog articles I tend to edit and to be honest one of the reasons I usually give anything political on Wikipedia a very wide berth. I tend towards supporting the idea of BLUELOCK for AfD discussions (less article creators), I suspect SILVERLOCK would be no impediment. One of the reasons I proposed a middle ground above is to protect closers from the inevitable social media targeting that would follow from a close that went against canvassed IP & SPA opinion. Kind regards, Cavalryman (talk) 22:48, 11 June 2020 (UTC).
• Wikipedia has already strayed too far from being the encyclopedia anyone can edit. Keeping that in mind, further restrictions on editing abilities for newer users should only be implemented when absolutely necessary. I think our admins are pretty good at recognizing canvassing and meatpuppetry by SPAs and the like. Since AfD isn't a vote, closing admins are expected to throw out !votes that are frivolous and/or not based in our policies and guidelines. Even if that weren't possible, I'm not convinced it happens often enough to justify such drastic action. We also have to consider the effect this would have on editor retention. Wikipedia is already confusing enough to newbies, with its byzantine policies, litany of jargony acronyms, and Kafkaesque bureaucracy-that-isn't-a-bureaucracy. I'm convinced this would be a net negative. AfD has far more pressing concerns to deal with anyway. The biggest two that come to mind are careless nominations where WP:BEFORE clearly didn't happen (especially wrt non-English sources), and nationalistic or politically motivated bloc voting by established editors. Established editors know how to make their !vote look like a valid policy-based rationale even when their real motivations are ILIKEIT/IDONTLIKEIT. Freshly recruited meatpuppets don't know how to do this, and so closing admins can safely disregard them per WP:NOTAVOTE. In particularly extreme cases, admins should semi-protect the page as they sometimes do now. That's far better than the current proposal which throws the baby out with the bathwater. −−− Cactus Jack 🌵 05:11, 11 June 2020 (UTC)
• While I appreciate the argument on principle, I don't know if being an encyclopedia that anyone can edit is the same as being "the encyclopedia that anyone can edit, and anyone can jump into the behind-the-encyclopedia technical processes without spending time learning about them first". As for WP:BEFORE, I don't necessarily disagree; don't you think that requiring more experience would make it more likely that someone is familiar with (and follows) that guidance? — Rhododendrites talk \\ 23:52, 13 June 2020 (UTC)
• We need to remember that AFD is just one of our deletion processes, if we were to restrict people from filing AFDs we shouldn't be surprised if they tag more articles for Speedy deletion or simply draftify them. That said I'm OK with the idea that we restrict some people from deletion generally. Over the years I have seen a number of editors who didn't realise they were overly deletionist until they ran an RFA and had their deletion tagging checked and criticised. So I would be OK with 6 month bans from the deletion process where people were only allowed to participate in the deletion process re articles that they had started. I really really don't like the idea of restricting people from a deletion debate where it is their work that we are considering deleting. So restrict the people who have been making mistakes in their deletion tagging, not a blanket restriction on new or newish editors. ϢereSpielChequers 13:32, 11 June 2020 (UTC)
• I don't know how we've escalated past the early suggestions of SP for participation to ECP, which is seriously, seriously OTT. While their average edit quality is certainly worse, I've seen many legitimate !votes from editors in that group. Shifting to talk page for all of them brings multiple issues: that's fiddly to spot, so some just won't note to participate there (that is, they'll know the TP exists, but not that they'll be read) & also massively drops that chances that every person in the AfD will read the !votes or comments, which disrupts and weights the discussion inappropriately. We also should be using the least disruptive method, and disrupted AfDs are relatively rare. We aren't implementing a "have more experienced participation" restriction. Nosebagbear (talk) 14:49, 11 June 2020 (UTC)
• AfD is infested with socks. You can see it with old AfDs (a few years back) and seeing how many participants have a strike-through (with that userscript installed). They get busted eventually, somewhere else, and leave behind fossil evidence. I would support reasonable moves to address this problem. -- GreenC 16:51, 11 June 2020 (UTC)
• Yes, there is a problem, but it is only a problem with a very small percentage of AfD discussions. Far more discussions have the problem of a lack of participation, which this proposal would only exacerbate. Maybe we need to encourage people to be less tolerant of canvassing, or of other abuses of this process, but I don't think this is the right way to go about it. I remember that my very first logged-in edit to Wikipedia 13 years ago was made to an AfD discussion in response to canvassing on another site, but it was not supportive of the canvasser. Phil Bridger (talk) 19:50, 11 June 2020 (UTC)
• I wonder how typical my own experience is. I began editing in any serious way in 2013. I think it was late 2017 or early 2018 before I even knew AfD existed. Once I discovered it I spent many weeks just observing it before I commented. It was months before I put my first article up for deletion. How many people in this discussion have a completely different experience? I simply don’t assume good faith for ‘new’ editors who show up and are busily nominating articles for deletion in the first couple of weeks. There are all kinds of productive ways new editors can contribute to the project but sitting on your hands for a while before you start nominating articles for deletion seems entirely appropriate. Mccapra (talk) 20:02, 11 June 2020 (UTC)
• @Mccapra: I had a similar experience. My first participation in a AfD was in AfD/Jamaal Anderson in 2007, only after having made hundreds of contributions over the years. AfDs—or any Wikipedia backroom bureaucracy—are almost naturally intimidating to the uninitiated, due to the various cryptic acronyms that are casually thrown around by the regulars. Unfamiliar with these, inexperienced or canvassed editors tend to copy-paste these acronyms in AfDs without actually understanding them, which makes them easy to spot for the trained admin eye. To his credit, creffett immediately spotted the unusual frequency of WP:BASIC citations in AfD/Anna Gifty Opoku-Agyeman. --bender235 (talk) 20:37, 11 June 2020 (UTC)
• A couple of points worth mentioning here. Other language wikis It would be great to both explicitly encourage editors to look at other language wikipedias for sources and to encourage editors from other language wikis to participate in AfD's, especially in situations where there is the likelihood of sources being in non-English languages. Draft namespace Draft namespace is relatively new compared to AfD and moving good-faith contributions to draft to enable relatively slow-moving editing to occur should be encouraged, particularly for topical subjects. SPAs and paid editing my feeling is that a large numbers of the SPAs involved in articles that end up at AfD are undeclared paid editors. This is a larger issue than AfD, but it may be worth thinking about what can be done in this specific context. The best I can think of is a bot that creates a table on the talk page listing all the AfD participants and editors involved in the article and gives edit counts, how many are related to the issue at hand, and also scans for their names in sockpuppet investigations and other administrative actions. Stuartyeates (talk) 21:21, 11 June 2020 (UTC)
• I am very against default ECP. I'm open to reasonable suggestions for how to resolve the identified problems, but ECP is not one of those. To comment on Rhododendrite's questions: (1) I think this is reasonable. We have technical restrictions on who can move pages, so I think it's reasonable to have slightly more stringent requirements to nominate for deletion. (2) I'm not a fan, but am open to it. I would prefer the first option and see how that goes before default protection. Perhaps more practical is expanding the protection policy to allow protecting AFD discussions for sock/meatpuppetry or obvious canvassing. (3) I think just encouraging use of the talk page by everyone would work, but why have newbies go to talk just to be ignored? We're basically telling them to send their emails to /dev/null. 23:31, 11 June 2020 (UTC)
• 2. Should deletion discussions be semi-protected by default? Can I suggest some alternatives?
• Grouped edit notice for Template:Editnotices/Group/WIkipedia:Articles for Deletion
• Some type of edit filter warning for non-(auto)confirmed users
• Something similar to Wikipedia:GettingStarted, but it pops up when you enter `WIkipedia:Articles for Deletion/*****` for the first time; if for non-(auto)confirmed users, it pops up something similar to {{Not a ballot}}.
If the above aren't going to work in any circumstances, okay then go ahead and semi- protect it and hope those SPAa and canvassed users don't gets 10 edits after 4 days. This will prevent new users from participating, but 99.999% of the time, they think it's a ballot. Nobody uses the AfD talk pages, so let's direct them there. With that comes with more very complicated ideas, like moving policy based votes into the actual AfD by experienced AfDers, and considering if the talk page will be additionally used to addresss the consensus outcome. {{reply to|Can I Log In}}'s talk page! 05:34, 12 June 2020 (UTC)
• I'm certainly not against less restrictive interventions like these; I'm just pessimistic they would be helpful. I've seen {{notavote}} added to lots of AfDs, and [just based on anecdote of course] I've not really seen it help much. Call me cynical, but when I add it, I'm really just trying to signal to other experienced editors (and the closer) that there may be canvassing/SPAs going on here. — Rhododendrites talk \\ 23:52, 13 June 2020 (UTC)
• Thanks for starting this, Rhododendrites. Something that deletion discussions and move requests have in common is that, because they have a mandatory period and appear to readers, they can do damage when bad ones are launched. For move requests, we're trying to help by making the notice less prominent, but for deletions, it needs to be prominent. I wish there was a way we could signal to readers "this article is currently nominated for deletion, but it's very unlikely to pass", but we can't exactly just have it display the running !vote total (either technically or editorially). Still, there might be some changes we could make to Template:Article for deletion to help make it clearer what being up for deletion actually means. {{u|Sdkb}}talk 08:06, 12 June 2020 (UTC)
• We already have strict requirements for starting an AfD: WP:BEFORE. The problem is that they are not enforced. From what Uncle G has said, AfD was deliberately made rather difficult as a barrier to frivolous nominations. The tool Twinkle has subverted this to make a deletion nomination much easier than other, more productive actions such as searching for sources, working on the article or starting a discussion on its talk page.
Another problem is that the readership tends to be excluded from these discussions. An article may be read hundreds or thousands of times while it is at AfD but we rarely see these readers joining the discussion. I myself got started on Wikipedia when I saw a deletion notice on an article that I had been reading. Perhaps I have more aptitude for the Wikipedia interface than the average reader but if there had been greater barriers in place, then I too might not be here now and the hundreds of articles that I have started might not have been written. Wikipedia is the encyclopedia that anyone can edit and so we should freely accept comments rather than engaging in voter suppression by restricting discussions to a dwindling number of incumbents and insiders.
Andrew🐉(talk) 11:01, 12 June 2020 (UTC)
• It strikes me as odd that we have concluded that the project is best served by creating some filters around article creation for new editors (I don’t know, maybe that’s still controversial?) but we continue to treat AfD as a free for all. It’s true that the best barrier we have is WP:BEFORE but I guess we’re having this discussion because it doesn’t seem as effective as it once was. Mccapra (talk) 11:15, 12 June 2020 (UTC)
• Quite frankly, I think concerns over this matter are completely overblown. People have constantly been predicting doom and gloom over small problems, but it seems to me that AfD is more sturdy and capable of dealing with sockpuppeteering and canvassing than many give it credit for. New editors do not find AfD and immediately start making bad edits. It takes a lot of time for the average editor to even build up the confidence to start making proper edits, never mind contributing to AfD. There are really only two ways in which a new editor will even get exposed to AfD, either an article they created was nominated, or they were canvassed there. The former is an important learning experience, and being able to contribute gives a new editor valuable insight into how the process works. Stopping these editors from contributing will just further the image of Wikipedia as a bureaucratic nightmare where decisions are made by elitists in ivory towers. In the second case, such instances are isolated and so painfully obvious that dealing with it really does not require pre-emptive punitive measures. This sort of goes without saying, but default ECP is a terrible idea and I am opposed to it in the strongest possible terms. Devonian Wombat (talk) 05:02, 13 June 2020 (UTC)
• Not doom and gloom. More about tons of wasted time, harassment, and possible external influence on our process (whether in good or bad faith). One of my original points was that we're typically able to deal with this, but there's so little benefit in forcing good faith participants to do so. Lots of wasted time, lots of attempts to influence the outcome. I don't disagree that the article creators/editors themselves should be allowed to participate, though. — Rhododendrites talk \\ 23:52, 13 June 2020 (UTC)
• Follow-up - apologies to start this thread and only come back a few days later. Several good points here. If these were actual proposals, it seems like were firmly in "no consensus" territory here, at this point. One thing that I think would make sense for me (or someone else) to do if formally proposing these measures would be to gather some data. My perception is that, putting aside the article creators/contributors themselves, new users almost never make valuable, policy-based contributions to AfD. That applies to nominations especially, and !votes slightly less. But I appreciate that not everyone may have the same perception. One open question for me is how to allow article creators/contributors to participate while preventing other new users? Maybe the only way is to direct them to the talk page, and to rework the notifications to be very clear about how to do so (i.e. to do everything we can to encourage participating there). Not sure. — Rhododendrites talk \\ 23:58, 13 June 2020 (UTC)
As somebody said above (or elsewhere, I do not remember), there are only three categories of IP / new users taking part in AfD discussions: (i) they have been affected (created or significantly contributed to an article being discussed, typically by getting a template on their talk page); (ii) they have been externally canvassed to the discussion; (iii) they evade a block. If this correct (and research probably could be made about this - canvassing is difficult to detect but it must be visible by clusterization of new votes in the same discussion), then these issues probably should be separated -canvassing is not just about new users, and we certainly want creators of the articles participate in the AfD on the articles they created.--Ymblanter (talk) 09:15, 14 June 2020 (UTC)
• I strongly support reforms to streamline the AfD process. In my time I have closed well over a thousand XfD discussions, and have observed two key patterns of sockpuppet manipulation. The first is where novices desperate to keep an article create numerous obvious sockpuppet accounts; the second is more sophisticated, typically connected to paid advertising, where the sockpuppet accounts are crafted with a veneer of legitimacy through the creation of nominal user space pages and through perhaps commenting on a handful of other AfDs or making a handful of other minor edits before engaging in the AfD of concern. Nevertheless, it should not be possible for an account created after the initiation of an XfD to participate in that XfD. I don't think that this is at all problematic for new users, who should expect that some time and experience is required to obtain certain rights. This should also not be a problem with respect to editors creating new pages. Quite frankly, editors should not be able to create new pages at all until they meet some minimal threshold of activity, so the ability to comment in XfDs should coincide with the ability to create new pages at all. BD2412 T 19:00, 14 June 2020 (UTC)
• These concerns raised seem pretty well addressed by WP:AFD, WP:AFDEQ, and WP:DISCUSSAFD in that legitimate AfD debate cannot be drowned out by obvious manipulation (sock-puppeting) or poor quality commentary, as AfDs are not a poll (consensus is not based on a tally of votes, but on reasonable, logical, policy-based arguments) and those processing the AfD are required to adhere to this (and if they do wrong, the article does not disappear, and can be recalled through the deletion review process WP:DRV). It also appears some of the generalisations about new users (who may or may not be new, given some new registered users have previously been editing Wikipedia for years as non-registered users) has some undertones not in keeping with the spirit that Jimmy Wales had for Wikipedia (that the value of an editor was not in how long their registered account had been in use, or even how many edits they had made, but in the quality of their contributions to Wikipedia, which may come from registered editors both new and old). Some form of artificial class system based on seniority/tenure/clique would seem contrary to that - even the auto-confirmed class (which has been deliberately set at the low threshold of just a few days) isn’t really such a class system. Like Devonian Wombat stated, New editors do not find AfD and immediately start making bad edits... There are really only two ways in which a new editor will even get exposed to AfD, either an article they created was nominated, or they were canvassed there. Therefore, there does not appear to be an issue with the current framework for AfDs that requires re-invention in my view. Kangaresearch 08:16, 18 June 2020 (UTC)
• What Dennis Brown said: AfD is one part of WP that really works well, participation at AfD is down, newcomers who are there are apt to be defending pieces they personally have a stake in, there is no better way to learn the notability standards than to actually participate in deletion debatese, there would be nothing gained and much risked by tightening standards for participation there. Carrite (talk) 14:08, 18 June 2020 (UTC)
• Perhaps all that's needed is a guideline that says that it's acceptable for an experienced editor to move the banner to the talk page in cases where it doesn't seem likely the AFD will pass. Or perhaps BLP shouldn't have the banner at all? It's not hard to see how it can be percieved as an officialy endorsed slight against the BLP subject. ApLundell (talk) 15:02, 18 June 2020 (UTC)
• Remove AfD from Twinkle. You used to have to go and create the deletion page yourself and copy and paste the correct templates in. This was fine. Some things shouldn't be made easier. It takes two separate people turning two separate keys to launch a nuclear misslile. This could be streamlined, but would that be an improvement? I haven't seen any evidence that either way that adding AfD to Twinkle was a net improvement. It's not helping, so end it. Herostratus (talk) 02:22, 22 June 2020 (UTC)
• 1. Should there be stricter requirements to start a deletion discussion? What kinds of requirements? At a glance, imposing more requirements would just make it so some deletion-worthy articles remain on the wiki. A lot of stuff can't go through PROD, and isn't eligible for the strict CSD criteria, but is clearly deletion-worthy and should go to AfD. I don't see stricter requirements helping the process.
2. Should deletion discussions be semi-protected by default? Canvassing is a problem, but I've seen less active Wikipedia users contribute helpfully to AfDs before, particularly AfDs that would benefit from more niche knowledge, particularly AfDs for some non-Western topics. I don't know if making discussions semi-protected would help in that sense. An experienced closer can deal with arguments from SPAs and effects due to canvassing, but the process does not benefit from suppressed views of the kinds of users I mentioned.
AfD has problems, but I'm not sure these are solutions. ProcrastinatingReader (talk) 17:16, 23 June 2020 (UTC)
• Stricter requirements: Yes. Notification of the article creator and any other editors who have edited the article significantly should be required, not recommended, in the instructions. Some people don't use their watchlists, some have watchlists so long that an AfD can slip by, some are inactive but have preferences set to notify them of edits to their user talk page, and it is a basic courtesy that also increases the chance of participation by people who know the topic. I'm not sure how it would be enforced, but WP:BEFORE should be required. Deletion nominations by editors who don't know the topic and haven't looked to discover it is, in fact, a topic, or who simply don't like the topic, are an increasing problem as the number of articles grows and participation at AfD dwindles. They waste other editors' time and risk our losing useful articles. Restricting participation, for example by semi-protection: No. Apart from the principle of minimizing barriers to participation by unregistered editors, on which I am firm—they include not only potential new editors but also experienced editors whose wisdom and knowledge we should value, and it's their own business if they choose not to register an account—many people are first drawn into the discussion and collaboration aspect of Wikipedia editing through AfD. I saw an AfD on recent changes and was able to provide the rescuing source, and hadn't realized till then that such discussions, where we might lose a valid article because someone didn't have access to a book, were happening. And that is indeed the venue where most of us learn the ropes of notability. In any case, COI editors would be far more likely able to bypass restrictions than good faith newbies, including subject-matter experts. So attempting to restrict AfD participation would do more harm than good. Yngvadottir (talk) 00:58, 6 July 2020 (UTC)
• Just noting yet another brand new account nominating yet another biography of a woman for deletion. Created an account, made exactly enough edits to be autoconfirmed, then came back a few days later and nominated here: Wikipedia:Articles for deletion/Sarafina Nance. Like the examples that immediately preceded my opening this section, and like the many other new accounts nominating/proposing articles by Jesswade88 and others, it's awfully hard to see this as something other than harassment by deletion process and demonstration of how easy our very low bar for creating these nominations is to game. — Rhododendrites talk \\ 18:31, 7 July 2020 (UTC)
• Mm. As a frequent AfD flyer over the last fifteen years, there are many changes I would want to make. I would love to stipulate that articles cannot be taken to AfD until at least three days after creation. I would love to stipulate that closing admins cannot make headcount-over-policy closes, nor consider the opinions of any Keep voter stating that there are sources out there, who does not then put those sources into the article. I would love to stipulate that editors who haven't been auto-confirmed for at least a month cannot participate in the process, either filing or voting. Hell, I would love to stipulate that any editor who votes Keep based on a perceived flaw in one element of the nomination, while ignoring the valid elements that remain, should be taken out and shot.

But other than requiring extended confirmation in order to file -- a harmless enough stipulation -- I don't see that there's a lot we can (a) do about it, (b) agree upon, or (c) enforce, given our obvious competing interests. This is an area where our respective hobby horses clash skulls as hard and often as anywhere on Wikipedia. Ravenswing 02:28, 21 July 2020 (UTC)

• Comment on process it seems like there are lots of different things happening in this discussion around highlighting issues and solutions but its all getting mixed together so its difficult to know if there are common themes and agreements on ways forward. Is there a way to collate comments into different themes or something to 'see what's going on'? I'm not sure if there is an established process for this? John Cummings (talk) 15:36, 6 August 2020 (UTC)

Notability in AFD

Not sure if this discussion is still active, but thought it worth adding my perspective/experience.

First, just as I've seen stacked IWANTIT discussions, I've also seen IDONTWANTIT steamroll discussions as well. (I'm avoiding the "inclusionisn/deletionism" labels, as, in my experience, most people do not tend to completely reside in black/white boxes.)

I remember a long while back, when blp first started being an issue, and around that time, "notability" really came to the fore.

That quote pretty much was undermined by the apparent necessity of blp.

I even remember a discussion about forking blp's to a separate Wikimedia wiki (WikiBio, or some such).

So to bring it back around to this discussion, What if we just restrict "notability" rationales for deletion, to biography articles (article named for a real person or a group of persons, living or not)?

I welcome discussion on it, but I think WP:V / WP:NOR / WP:RS should easily take care of the rest, thus addressing concerns about the "subjectivity" of the application of "notability" in a particular discussion.

pinging user:Rhododendrites, user:Masem, and user:Astrophobe - the first 3 to comment in this discussion.

I hope this helps as a way forward. - jc37 03:15, 24 July 2020 (UTC)

You cannot restrict notability rationales at AfD without first changing the notability and deletion policies. The former says stand-alone articles must be notable and the latter says they can be deleted if they are not. If an article cannot be nominated for notability reasons at AFD, that leaves no practical way of deleting it. Contrary to your claim, there are numerous articles that go through AfD that have verifiable information, but not enough to meet WP:N. What you propose goes way beyond a change to the AfD process. SpinningSpark 15:41, 24 July 2020 (UTC)
Do you want any old completely non-notable company, product and theory to have an article? We have policies of deleting due to notability for obvious reasons. Best Wishes, Lee Vilenski (talkcontribs) 15:50, 24 July 2020 (UTC)
To be clear, I'm not resolutely against a fundamental rethink of our inclusion criteria (in fact I think that would be highly beneficial), but I'm not in favour of the (implied) change in this proposal. SpinningSpark 16:40, 24 July 2020 (UTC)
I think there are problems with our notability standards that I won’t expand on here. However I don’t see a reason why we would restrict notability to BLPs only. I think our fundamental problem is that we aspire to collect and share the sum of all human knowledge but we’re not completely clear about what ‘knowledge’ is. Is it the same thing as ‘stuff’ or some kind of subset? Personally I’m very relaxed about small town mayors and other people we currently AfD out of existence so I don’t have a problem with significantly widening our definition of notability. But we also need to recognise that there is a tidal wave of rubbish pushing its way onto Wikipedia - promotional material about every pizza restaurant in Akron, Ohio, every ‘AI startup’, and all sorts of bizarre POV stuff about history and nationality. If we let all of that in we’ll rapidly become Opinionopedia. If we’re the world’s intellectual junkyard that’s a significant change of mission and why we should continue to require notability for BLPs but not for other articles doesn’t seem consistent to me. Mccapra (talk) 18:37, 24 July 2020 (UTC)

An XFD Idea to Toss Around - Discretionary Sanctions

This is an idea that has occurred to me from time to time, and then sometimes I have thought it was a good idea, and sometimes I have thought that it wasn't such a good idea. That is to impose Community General Sanctions (or ArbCom Discretionary Sanctions) on XFDs. General Sanctions are imposed on areas in which there is a high tendency to disruptive editing, such as areas that are real battlegrounds (e.g., Israel-Palestine, India-Pakistan), or where there is a high incidence of fraud (cryptocurrency), or where there is a special need to deal with disruptive editing (e.g., BLPs, to protect, you guessed it, living persons). There are a few editors who make a nuisance of themselves either nominating things for deletion or defending things from deletion. Perhaps general sanctions would help deal with troublesome editors by allowing an uninvolved administrator to initiate sanctions that would otherwise require WP:ANI. Comments? Robert McClenon (talk) 02:46, 30 July 2020 (UTC)

Requiring alternatives to deletion be exhausted before nominating an article for deletion

Hi all

I spent a while looking at what is going wrong with AfD because of several issues I had with articles being deleted (mainly of biographies of women). One way that I think would reduce the issues with articles being nominated for deletion is that currently the rules do not require contributors to explore the alternatives to deletion before nominating an article for deletion. If nominators had to show they had exhausted alternatives for deletion before nomination this would both provide additional motivations to improve the quality of articles (e.g more references to improve notability) and take most of the 'fun' out of malicious and low effort nominations.

John Cummings (talk) 15:23, 6 August 2020 (UTC)

On this basis how would you suggest we modify WP:BEFORE? There are times when nominators are too quick to put an article up for deletion, but if there are decent sources it does not take long for other editors to flush them out. If there are articles you think we should be keeping that are actually being deleted (as opposed to being wrongly nominated and then kept following discussion) this suggests that nobody at AfD is doing their job properly, not just the nominator, but this isn't a pattern I recognise. Mccapra (talk) 16:41, 6 August 2020 (UTC)
WP:BEFORE clearly says that alternatives to deletion should be considered before nominating an article at AfD. The problem is that we have some editors who don't consider themselves to be subject to the instructions that apply to other people (I suppose they regard them as the little people as opposed to the Übermenschen that they are themselves), and actually boast of not following them. Phil Bridger (talk) 18:07, 6 August 2020 (UTC)
That may be true, but if it is a behavioural pattern there are ways of addressing it that don’t require us to change the AfD guidelines. Ultimately if editors active at AfD do their job collectively, then nominators who haven’t done a proper WP:BEFORE won’t get very far. There’s a case that such nominations waste other editors’ time, but not that we lose decent articles because of bad nominations, AFAICS. Mccapra (talk) 18:33, 6 August 2020 (UTC)
I disagree. Many AfD discussions are closed with a couple of "me too" votes, without anyone actually considering alternatives to deletion. Phil Bridger (talk) 19:12, 6 August 2020 (UTC)
Phil Bridger, that is dishonest, offensive claptrap and you know it. Instead of calling people names, how about you try characterising your opponents' positions accurately and fairly, and debate them on their content instead of wild speculations as to their motives? Or is that too hard for you? Reyk YO! 18:39, 6 August 2020 (UTC)
Please link to any AfD discussion where I have not done as you ask. Phil Bridger (talk) 19:09, 6 August 2020 (UTC)
I want to say that this (BEFORE required before launching an AFD) has been a WP:PEREN but its not listed there, but I can tell at WT:AFD that the idea has been proposed and rejected many times. What I will say is that if you see any AFD nominated, and keeping in mind the history of the editor nominating it, that you do not believe in good faith that they have executed a proper BEFORE search appropriate for the topic, mention and call this out. (This would be the case for where we're talking topic pre-Internet, where sources more local to the event may be needed in print and thus not easily found just be a google search). --Masem (t) 18:23, 6 August 2020 (UTC)
@Masem:, exactly, WP:BEFORE says they should be considered but doesn't require it, either of the nominator or anyone taking part in the process or to use them to reject deletion nominations if its clear alternatives are possible. Making it a requirement would put the onus on nominators to explore alternatives and save the time for people taking part in AfDs discussing articles that shouldn't have been nominated in the first place, it would cause no change for people already following the recommendation. I've thought about this quite a lot and cannot think of a downside to this change, am I missing something?
I'm unclear how exactly this could be implemented in practice, my suggestion would be the nominator would be required to show they have exhausted alternatives in nomination process, not just say 'have you considered the alternatives to nomination = yes' but to actually show the work e.g showing there aren't enough reliable sources in common places for that topic e.g Search results, Google Books, Scholar and News etc. John Cummings (talk) 18:40, 6 August 2020 (UTC)
I think you may be missing WP:CREEP which, ironically, is seemingly the favoured link for one of the WP:ARS stalwarts across a broad swathe of discussions such as this. - Sitush (talk) 18:40, 6 August 2020 (UTC)
@Sitush: thanks, this change would wouldn't include much new instruction, my guess would be one change and one new line. It would mainly be a change in the wording on WP:BEFORE from 'Consider whether the article could be improved rather than deleted' to something like 'Exhaust opportunities to improve rather than delete the article' (that wording needs some work) and then an extra line in the AfD nomination form asking the nominator to show they've actually done this. John Cummings (talk) 18:50, 6 August 2020 (UTC)
First, I would recommend reading the WT:AFD archives because again, making BEFORE mandatory, while not a perennial suggestion, has been asked many many times. Also, not all AFD requests are based on lack of notability, which BEFORE is specifically about. There's also reasons that may be based on notability that BEFORE can't address, like if the sources available - maybe established in a previous AFD as exhaustive - still don't give significant coverage per the nominator, and they seek deletion. BEFORE is not a one-size-fits-all approach prior to all AFD, basically. --Masem (t) 18:58, 6 August 2020 (UTC)
But this discussion is not about notability. It is about looking for alternatives to deletion, which are also addressed by WP:BEFORE. Phil Bridger (talk) 20:56, 6 August 2020 (UTC)
The problem with BEFORE is that making it a strict requirement turns the discussion away from the article, it content, and its sources and towards a lawyerly checklist and procedural shutdowns. It's best to regard BEFORE as advice on how to write a convincing nomination. That it keeps getting used as the delivery mechanism for personal attacks on deletion nominators doesn't help either. Reyk YO! 18:44, 6 August 2020 (UTC)
A much better way of reducing the load at AfD would be to create a new permission called article_creator or something like that, give it to every editor who has shown that they can create articles that don't have notability or other serious issues, and require that every new article created by editors without the permission goes through AFC. Black Kite (talk) 18:46, 6 August 2020 (UTC)
Since 2018, we've already had article creation restricted to autoconfirmed accounts, after the Foundation reversed its unilateral prohibition on implementing the plan which had been first approved in 2011. (See WP:ACTRIAL for the full history of this long contentious issue). Based on my experience with the issue, I believe that 1) The restriction to autoconfirmed accounts is sufficient in keeping the worst abuses to a minimum and 2) It took the Foundation 7 years to come around to what was a WIDELY supported community initiative. I think your proposal is dead in the water, as I see no way the Foundation would support any additional restrictions on article creation, given how hard the fought against the community on this one. --Jayron32 19:00, 6 August 2020 (UTC)
Oh, I didn't think it would. But I can't think of any other way to at least restrict the large amounts of spam, cruft, paid editor creations and other crap which isn't coming through AFC. Black Kite (talk) 19:58, 6 August 2020 (UTC)

I think that the balance needs to be tipped a bit in the opposite way. A significant part of creating a article in Wikipedia is to find and include references. That's why they are called editors and not title generators.North8000 (talk) 20:09, 6 August 2020 (UTC)

Going back to the original proposal to require alternatives to be exhausted, I’ve been giving it some more thought. First of all my question is do we think that articles on decent, notable topics are getting deleted at AfD constantly? Regularly? Occasionally? Very occasionally? Because I think to make a major revision of WP:BEFORE we’d need to agree that there is a problem of sufficient magnitude to warrant it. For my own part, I’m not persuaded. I look at AfD every day though I don’t scrutinise each individual discussion closely, and my impression is that overall, it’s doing fine. Yes there are nominations what are not grounded in policy, but other editors contributing to the discussion deal with that. I’d support some thresholds for allowing editors to make an AfD nomination at all in order to reduce the number of pointless nominations but I know that doesn’t enjoy support here.
The main alternatives to deletion, other than just leaving the article alone, are going to be redirect or merge. If we’re going to say that we won’t allow an AfD nomination until both redirect and merge have been tried and failed, I don’t support that. Often articles nominated at AfD don’t have suitable merge or redirect targets anyway. Also I think this will impose much too high a burden on the nominator. Merge proposals can take months, and any time we’d save at AfD we’d lose in hugely expanded merger discussions.
To me the main benefit of an AfD over alternatives is that it gives us to opportunity to reach consensus. If I find a BLP that I think doesn’t belong in Wikipedia I don’t want to engage in a potentially endless ping pong of doing and redoing redirects while the article creator undoes them before I’m allowed to seek consensus on what should be done. We should be able to seek consensus quickly, not only as a last resort. If the conclusion of an AfD is to redirect then there is a good chance that can be made to stick, and that is less of a waste of everyone's time than expecting an individual editor to doggedly pursue alternatives for days, weeks or months before being allowed to nominate at AfD. Incidentally I would expect one unintended outcome of taking this approach would be to increase incivility and edit-warring. AfD is a formal, rule driven process where we can air differing views on notability dispassionately and without making it personal. Only letting editors into that forum after they’ve done a dozen rounds of slugging it out one to one with the article creator isn’t really going to help us build the encyclopedia any better. Mccapra (talk) 04:58, 7 August 2020 (UTC)

Past images in articles

I would like to discuss what the policy is, or should be, on images that were once used in articles but no longer are. To my mind, such images should be retained, either here or on Commons, because they form part of the history of the page. Deleting old images breaks old versions of the page. It also removes some of the attribution, which becomes a licensing and legal problem for any reusers of old versions of the page relying on hyperlinks for attribution. In my view, we should also retain images used as part of talk page discussions. Sometimes, the discussion makes no sense without the image.

Some background; I deprodded around one thousand images back in May that had been mass proposed for deletion on the grounds that they were not used in any article (although the vast majority of them had once been so used) and the "poor quality" made them unsuitable for Commons. These deprods went largely unchallenged, but there is still a steady stream of simmilar cases turning up in CAT:PROD and the deprod sometimes gets challenged at Files for discussion, the latest case being Wikipedia:Files for discussion/2020 June 21#File:Null-balance voltmeter.png. SpinningSpark 10:37, 21 June 2020 (UTC)

I dunno, how important is it for images to display in old versions of the page? In practice it may also be difficult to know about a file's past usage. Jo-Jo Eumerus (talk) 11:42, 21 June 2020 (UTC)
The importance of old images is exactly the same as importance of old text for precisely the same reasons (which are in my opening statement). If you think this is unimportant you need a better rationale than "dunno". As for "difficult to know", on the contrary, in the vast majority of cases it is very easy to find out. One has only to check the edit history of the uploader; the image is often used in an article in the very next edit. Not checking this is just pure laziness on the part of the nominator. SpinningSpark 13:08, 21 June 2020 (UTC)
Not sure I understand why old images need to be deleted. If the image was good enough for an article at some point, then it should be moved across to Commons. If the quality is seen as poor, then tag it somehow as "needing a better version". If the image is re-used and somebody is motivated by the poor quality, then a new version will happen. — GhostInTheMachine talk to me 12:39, 21 June 2020 (UTC)
I'm assuming this is about fair-use images? One of the fair use conditions is for images to be used on pages. We can't be an image gallery for copyrighted materials. If items are free, they should be moved across to commons anyway, so I'm not sure what the policy change here is being proposed? Best Wishes, Lee Vilenski (talkcontribs) 13:18, 21 June 2020 (UTC)
No, this is not about fair use. The images being discussed here were all nominated for quality reasons. They were all uploaded with a free license, usually self-created. SpinningSpark 13:38, 21 June 2020 (UTC)
• Depends on WHY the old image was removed. If it was simply because editors thought that a new image was better, then we have no problem with maintaining the old image somewhere (such as commons). However, if the old image was removed for cause (such as violating copyright), then we MUST purge it completely. Case by case situation. Blueboar (talk) 13:30, 21 June 2020 (UTC)
Agreed, of course, we should not keep copyrighted images. You say "we" have no problem keeping but the NFF FFD page is absolutely causing such a problem. Its reasons for nominating include orphaned, obsolete, low quality, and unencyclopedic, all without any reference to policy or guidelines. All of these can include files that appear in article histories. And on the last criterion, I have created files in the past to clarify a talk page discussion. These are clearly unusable in an article but are open to deletion (some have been) under these criteria. SpinningSpark 13:47, 21 June 2020 (UTC)
• I believe that how we handle files is outside the rest of all parts of the other contributions to the history of a article page, and thus retention of older, unused files is not necessary, though we retain the file: space history aspects related to that file that relate to who had uploaded the file and the source/other details. All of our disclaimers to users, and our upload notifications all suggests that the hosting of images (and other AV file types) is wholly separate contributions from mainspace contributions, and while you are still agreeing to make your contribution to the project, it is not being tracked as part of the contribution of the article it will belong to. When looking at contributions to an article, it is not the image that we look at as the contribution, but the text/code that puts the image in place as the contribution, since that image can change independently after that text is added to the article (by a file update). A reuser of an article that is taking images would be required (if they are following the letter) to point to the histories of both the article and all used images to track contributions. So no, I don't think we're required to keep old images. That said, obviously we delete unused NFC, but I see no reason why we need to delete unused free images unless its clear they are completely unusable or otherwise clearly violate other policies (eg: graphic nudity beyond what's necessary for articles on human anatomy). Poor but not unusable is not a good reason to delete a free image --Masem (t) 13:57, 21 June 2020 (UTC)
• The argument is not that old images are needed for attribution, it is that old images allow inspection of previous versions of an article, including meaningful diffs. We don't purge revisions with unused text on the basis of "orphan" or "unnecessary". That's because it can be useful to view old revisions, for example, if wondering why a certain section is the way it is—has an edit from long ago accidentally damaged or omitted an important point? Johnuniq (talk) 04:00, 22 June 2020 (UTC)
• But we do have to reconcile that we are required to delete unused non-free images from a copyright and WMF standpoint. When the unusued image is free (for the stuff that can't go to Commons) I fully agree, lets keep it to help with previous revisions of articles, but my point is that if the old image was a proper non-free but since replaced, the file: page should be present that a user checking an old revision can see from the source on the file: page to get an idea of what it is (and even if that's not the case, the description should be sufficient to get an idea, this is why we have this information). We need to delete the "pixels" from the File: page and while we need to "delete" the non-free file page to remove that from being included in scope in article scope, we shouldn't purge the deleted text revisions on the file: for this reason. --Masem (t) 15:53, 22 June 2020 (UTC)
• Images not currently in use that are of lower quality than others that do not have any other (offsetting) added educational value are not in scope for commons. A recent dicussion on commons concluded that "image was formerly in use in a wikipedia article" was not a reasonable basis for keeping an image tagged for deletion. One of the reasons mentioned there is an important one unrelated to images directly...we routinely make widescale changes that make previous revisions of a page no longer "as they were at the time" when viewed in article-history. A simple example is a change to a template that makes some formerly-used field no longer visible (same effect as if an image in use at the time were deleted). Images solely for discussion of wikipedia issues and brainstorming (no encyclopediac or educational content) obviously aren't in scope for commmons...they should be tagged {{Keep local}} with some rationale so others will be less likely to mis-handle them. DMacks (talk) 14:13, 21 June 2020 (UTC)
I also note that WP:CSD F1 and F8 have existed for a looooong time. Some deletion...speedy, not even discussed, of some free images that were once in use, making the old revisions of articles that once had them no-longer-render-as-they-did, is currently a policy. DMacks (talk) 02:36, 22 June 2020 (UTC)
@DMacks: F1 and F8 apply to duplicated images, the former on Wikipedia, the latter on Commons, and what "unused" means is here is open to interpretation. Virtually none of the thousand files I deprodded was a duplicate — that's why they weren't speedied. Of files that are duplicated on Commons, the vast majority are moved there with the same name as Wikipedia. There is thus only a speedy problem with a tiny minority of a tiny minority of files, and in any case, they are probably an oversight of the original policy draft. The original proposal for F8 is here. This was clearly controversial as the proposal had failed multiple times previously. Part of the agreed compromise says "If the image is available on Commons under a different name than locally, it must not be used on any local page whatsoever." In other words, don't delete the local copy if our article uses a different name from Commons. I also note that the original version of F8 – then I9 says "bit-for-bit identical", in line with the original version of F1. It got changed in this edit as a result of this discussion with poor participation. I don't think any of this shows consensus for these deletions. In fact it shows that we have got where we are largely through undiscussed scope creep. SpinningSpark 14:00, 22 June 2020 (UTC)
It's a policy that supports deletion of currently-unused files in a way that breaks layout of old revisions of an article. DMacks (talk) 15:15, 22 June 2020 (UTC)
We strongly discourage (if even recommend against) image placement layout on articles ("pixel perfect placement") over placing images at relevant text in the document with minimal hints guiding sizing and location. That deletion of images causes these "layouts" to be broken that are not supported by policy is not something we should be worried about. --Masem (t) 15:26, 22 June 2020 (UTC)
That is entirely not the issue in hand. SpinningSpark 15:40, 22 June 2020 (UTC)
Perhaps "layout" was an imprecise term on my part. Better would be "display" or "content" (whether the image is present at all) let alone the pixel positioning of objects. DMacks (talk) 15:59, 22 June 2020 (UTC)
• Deleting old images because anyone can prod is ridiculous. It makes looking at old article revisions very hard; it does not save space; it does not save anything; it's a waste of time. Sure, put some energy into deleting old dick pics and similar because discouraging people from using Wikipedia for non-encyclopedic self gratification is useful. However, File:Null-balance voltmeter.png is part of the history of an encyclopedic article. If that should be deleted, why not permanently delete old revisions of text that are no longer used? Johnuniq (talk) 00:10, 22 June 2020 (UTC)

Response from FFD nominator: User:Spinningspark says they deprodded a thousand images in May. I believe that I have nominated two of those and File:Null-balance voltmeter.png from June at Wikipedia:Files for discussion. I believe that it might be useful for other editors to see more than this one cherry-picked example of what they think is valuable to keep. I notice that while at least two people from this discussion have !voted on the image mentioned above, nobody appears to have found reason to !vote on File:Roodog2k-roo1.jpg that is also being discussed currently.
Wikipedia:Files for discussion/heading was created more than 10 years ago (and I believe that something similar was in use before that, but ten+ years is a lot around here) and listed "Obsolete, Orphan, Unencyclopedic, and Low quality" as four of the five common reasons for nomination, which are still the first four in the header today. At some point in the last few years, images were added to the Proposed Deletion process (at a time when I was less active). There are a few of us who look through the orphaned images from fifteen years ago and try to process them; If they have reasonable source and license and a chance at reuse, we move them to commons; Occasionally, we find one that we can reuse in an article immediately; A lot of them are things that may or may not have ever been used in an article and we make a decision on whether or not we think it will be reused.
We could leave it behind and hope that when someday someone decides to create Null-balnce voltmeter, they will look back at a 15-year old version of voltmeter and see the perfect image instead of creating a new one themselves, but most of us who do the work have been around here long enough to doubt that will happen. The other problems with leaving the image behind are (a) that it will sit in the swamp of orphaned images that we slog through and we will have to look at it each time we pass through and make the same decision repeatedly and (b) that the various ways to look for orphaned images will not actually display all 75000, but only the oldest ones. If any of you hearty souls who feel that these old images really belong over at Commons would like to help out with moving old orphaned images to Commons, I would love to have the help.
As long as WP:FFD continues to describe many of these ancient images as common reasons for nomination, I will continue to nominate them through whatever process avails itself.  ★  Bigr Tex 23:07, 23 June 2020 (UTC)

You will notice that (a) I have not voted for keeping the roodog image, even though was aware of the nomination, and (b) it has not actually ever been used in an article so is irrelevant to this discussion. It is easy enough to template images that have been reviewed once so that they need not be looked at again. That's a really poor jsutification for mass deleting images. SpinningSpark 23:33, 23 June 2020 (UTC)

The policy justification for these deletions is WP:NOTWEBHOST. Images with no potential to be used in article or project space in the present or the future (for reasons including "obsolete, unencyclopedic, low quality") don't need to be here, even if they have been used in articles in the past. Being orphaned is not enough. The text of Template:Orphan image puts it well, I think. (Full disclosure, I placed a handful of those PROD tags, and I've made delete votes based on this reasoning at FFD.) Wikiacc () 01:44, 24 June 2020 (UTC)

This. I've previously PROD'd such files as well. The choice to use PROD over FFD was deliberate; if someone *really* wants to maintain old page histories, then I'm not going to stop them, the file may be restored without fuss. But IME, this is neither a common want nor need. -FASTILY 00:04, 25 June 2020 (UTC)

Proposal on images in page histories

So let's make a definite proposal to focus this and bring it to a conclusion. I'm deliberately not proposing a definite wording to guidelines so we don't get bogged down in the minutia and address the principle, but the pages that might need editing if this passes include, but are not limited to;

I'll make a separate proposal for article and talk pages as I suspect there will be a difference in attitude to the two. Note that the example I raised at the beginning is heading for keep at FFD, so there is prima facie evidence that this has consensus for at least some images. SpinningSpark 11:45, 26 June 2020 (UTC)

• pinging previous participants in this discussion to try and finally get some consensus on this. SpinningSpark 10:25, 10 July 2020 (UTC)
• I disagree with your proposal, but have spent the last two weeks declining to participate because there was no discussion (which implied to me that there is not great interest or support for your proposal) and because there are no instructions for how to participate.  ★  Bigr Tex 15:16, 10 July 2020 (UTC)

Should files be retained so that the appearance of a historical page can be preserved? 17:56, 12 July 2020 (UTC)

Proposal on retention of images in article histories

Proposal: That images that have appeared in past versions of an article should generally be retained. SpinningSpark 11:45, 26 June 2020 (UTC)

• Support. Images that were used in articles should be retained unless there is a specific reason to delete them. I'd make an exception for images that were exclusively used for vandalism, but that's the sort of thing that can be worked out when we get to the detail stage. Thryduulf (talk) 13:04, 10 July 2020 (UTC)
• Support as nom. SpinningSpark 13:08, 10 July 2020 (UTC)
• Oppose because there's usually an alternative or other reason. If an image has novel educational value, it should be moved to commons. That's what happened with the image that started this discussion (Wikipedia:Files for discussion/2020 June 21#File:Null-balance voltmeter.png), so there is no precedent created for "keep because was formerly used" (more than half of the !votes for some sort of keep did not mention that as a basis). Commons is a collection of realistically-educationally-useful images even if they are not in current use, and they get lots of categories there to help future editors find existing images for new article content (maybe another language has been looking for an image of something we already have?). That's true equally if the image is a novel aspect of an article-topic that isn't covered in enough detail to merit an image, or got removed because of NOTGALLERY concerns. However, if an image is simply poorer than an alternative (someone makes an illustration in higher resolution, fixes a typo or other factual mistake, etc) at an alternate filename, then the original file does not have value except for article-historical reasons and I would delete. If it were moved to commons, it would likely be deleted there. Having images of lower-than-alternatives quality or with mistakes makes it harder to find the good stuff to write as best we can. If an image is wrong, then it's too easy for someone not to know that and reuse it (especially external users), in which case we fail our WP:V role.

We routinely make changes that cause "old revisions" of large swaths of articles to no longer look the way they did at the time, including being completely broken, content missing, etc, especially in the world of templates, and the site-wide CSS and rendering engine itself. Now that we have section-transclusion and pulling content from wikidata (and have always had embedding of images from commons), there even are tons of "regular edits" (not just widespread things) that make looking at an old revision of page not the same at a later date (or even looking at the current version of a page). Therefore, I don't accept "to see how it was" as a generally valid reason to keep. DMacks (talk) 15:37, 10 July 2020 (UTC)
There is WP:NODEADLINE. If old images should be moved to Commons, then why not actually do so before deleting them locally, instead of leaving a redlink behind? If you can't be bothered to do that, then you shouldn't be cleaning up unused local files. -- King of ♥ 18:22, 12 July 2020 (UTC)
The question is "should we keep", which I assume because we're here on enwiki means keep on enwiki. That's why I opposed the question as written based on giving alternatives such as moving to commons. DMacks (talk) 03:53, 14 July 2020 (UTC)
Importing another thought I mentioned in the previous discussion but forgot to include here in the formal RFC... "delete enwiki images, leading to redlinks in previous revisions" is a fundamental effect of CSD#F8 when commons has a different name for it and of CSD#F1 in general. That's a consensus policy for speedy without discussion, so the proposed policy-change here (keep if formerly used in good faith) seems like it would require abolishing those criteria. That policy talkpage should be alerted. DMacks (talk) 04:03, 14 July 2020 (UTC)
@DMacks: I interpret the proposed policy in a completely different way from you. To me, the fact that images can be speedied locally under F8 after transfer to Commons is so untouchable that I can't imagine a new policy changing that, and any proposal which does not explicitly overturn F8 should be read in a way that does not imply that. So for me, the only effect of opposing this policy would be to allow deleting images without transferring to Commons, which seems counterproductive to me. Regarding Commons potentially having a different name for it, we can always create redirects on Commons. -- King of ♥ 14:31, 28 July 2020 (UTC)
• Oppose - I find the supposed need to be able to see exactly what a page used to look like doesn't match the history of how page history is primarily used (for crediting edits toward the existing version, and for tracking editing problems), nor with how we treat anything else here. There are a number of things we do that make looking at an historic (say, 2010) edit different from seeing it exactly as it appeared at the time (for example, we don't subst every template, so the templates all have their modern appearance when we look at the historic edit.) And the upshot of such a policy would be to incentivize putting in pointless photos, because any picture you once put into an article stays on forever, relevant or not. --Nat Gertler (talk) 16:26, 10 July 2020 (UTC)
• Support if they are free images, with some clear encyclopedic value (no random pics of people's genitalia for example). If they can be moved to commons, they should be. If not, kept on WP. But considerations should be made for when improvements have been made and otherwise keeping an equivalent image (eg say a line-and-text drawing at 300x300px is reuploaded at 2400x2400 for better resolution, the 300x300 version is clearly not needed). Oppose for any non-free unused image as per the WMF resolution, we simply can't do that. Comment that I don't see the need to distinguish between image use on mainspace or talk space, because this is near impossible to track when starting from the image page, and would make for an admin nightmare. --Masem (t) 16:42, 10 July 2020 (UTC)
• Support strongly per m:keep history. MediaWiki was designed as an improvement over UseModWiki, and one of the main features was keeping all history, not just some. It's important that we keep our history in a useable state because editors may want to go back to find images to re-use, figure out how a page's appearance has changed over time, or revert to a previous stub. There's little value in deleting free images, and a potential for harm. Having been used (and stable) in an article should be a sufficient reason to keep a file. 20:51, 10 July 2020 (UTC)
• Support Keeping history is important. Deletion does not save space and only wastes time and energy in pointless discussions. It is useful to delete images uploaded for non-encyclopedic reasons in order to discourage self-gratification. That does not apply to images that were useful in articles and which might have some detail that would throw light on article wording. Johnuniq (talk) 23:47, 10 July 2020 (UTC)
• Support (for free images) as long as the image has remained in the article for a significant time (say, at least a month). Storage is cheap, and having an old revision look as close to it used to is very helpful to editors who want to compare an article throughout its history. -- King of ♥ 00:19, 11 July 2020 (UTC)
• Oppose per DMacks globally, and oppose for non-free images per Masem. --Izno (talk) 17:53, 12 July 2020 (UTC)
• Support Images that were part of an article and still meet the tests in WP:MTC should be moved to Commons so that the article history is preserved. (Otherwise, why not just purge old article versions as well??). — GhostInTheMachine talk to me 20:35, 12 July 2020 (UTC)
• Oppose - As others have said, there are already a variety of changes that make pages in the history distinct from how they were at the time. Images form a relatively small proportion of this perceptual gap; the logic that deleting images "breaks" old versions of the pages is incorrect - they are already "broken". I also don't see any convincing reason why images should be retained, apart from "it's part of the history", which in my opinion isn't a convincing reason on its own. Many sites like the Internet Archive already retain a lot of these images anyway. - Axisixa 01:03, 14 July 2020 (UTC)
• Oppose We should move to commons any image has proper source and licensing information and a possibility of future encyclopedic use, here or elsewhere. If it doesn't, we've listed that we are not a File Storage area for more than 10 years and it should be deleted. We have existing processes in place to determine into which of those categories an image belongs and some of which have been in place for even longer. I also find arguments about other history-breaking changes compelling.  ★  Bigr Tex 03:38, 14 July 2020 (UTC)
• Support for free images. Keeping a non-free image is problematic as per minimal use. Whether it is on commons or en.Wikipedia makes not difference. But commons really doesnot care to keep this old stuff for en.Wikipedia, so if deleted off commons it should be restored back here. Graeme Bartlett (talk) 04:46, 14 July 2020 (UTC)
• Oppose per DMacks' excellent analysis above. To underline a few additional points: we are not a hosting service. When files get deleted, it happens for a reason. The purpose of revision histories is not to serve as facsimiles of how pages used to appear. We delete unused/deprecated templates as well. Orphaned pages would be nothing more than a maintenance (and watch) burden. But above all: images deemed realistically useful not just in the past but for the future should, can, and are habitually transferred to Commons under current policy. If a need truly arises to see a deleted image in a revision history, you can always ask an admin and a copy will be provided to you. (talkcontribs) 20:38, 15 July 2020 (UTC)
• Oppose - Images are deleted for a reason. "We used it before" is not a sufficient rationale for countering our deletion reasons. -Indy beetle (talk) 02:45, 16 July 2020 (UTC)
• this proposal will not override other deletion criteria such as licensing. It is for when "unused" is the only deletion rationale. That is why the proposal says "generally" and not "always". In other words, images previously used should not be considered "unused" but can still be deleted for other reasons. SpinningSpark 07:15, 16 July 2020 (UTC)
• Support File space is not a problem and the images don't actually get deleted anyway. What's most important is maintaining our audit trail as the years pass so that we can fully understand earlier versions of articles which may get munged or distorted. Copyright is not a long-term issue because all copyrights expire as the years pass. We should be planning for Wikipedia to last for centuries and it will then be interesting to study the evolution of its content. Consider the state of content from classical history which is now fragmentary as a result of attrition, decay and malicious destruction. Andrew🐉(talk) 17:42, 25 July 2020 (UTC)
• Oppose per above. We are not a file hosting service. If necessary, useful images can always be copied to Commons. Without an obvious way to check if an image was previously used in an article, this is not enforceable. -FASTILY 22:47, 28 July 2020 (UTC)
• Oppose Solution without a problem that's likely to cause new problems. --AntiCompositeNumber (talk) 17:04, 6 August 2020 (UTC)

Proposal on retention of images in talk page histories

Proposal: That images that formed part of a meaningful talk page discussion (in any namespace) should generally be retained. SpinningSpark 11:45, 26 June 2020 (UTC)

• Support. If an image has been used on a talk page in any meaningful way then it should be retained unless there is a specific reason to delete it. Thryduulf (talk) 13:05, 10 July 2020 (UTC)
• Support as nom. SpinningSpark 13:09, 10 July 2020 (UTC)
• Support. If the loss of images makes a discussion in a talk page archive unintelligible, it may be necessary to hold the discussion all over again, which is likely to be a waste of everyone's time. If an editor who provided a useful image in the past is no longer a participant, the results of the redundant discussion may be inferior to the result of original discussion. Jc3s5h (talk) 13:14, 10 July 2020 (UTC)
• Semi-support as long as two tagging processes are used:
• An image whose discussion reveals a mistake gets clearly tagged as having a mistake (comparable to c:Template:Disputed diagram) to alert anyone who stumbles across the image (for example, looking at an older version of an article!).
• An image that is incorrect, clearly lower quality than alternatives, or created solely for discussion and workshopping gets tagged {{Do not move to Commons}}. License-compliant images are generally moved to commons for benefit of all, but if there's no benefit for anyone else to have or it's not in their scope, they will just delete it and we'll have lost what we wanted to have.
And this is all predicated on discussion/image itself being in good faith and seeing the image likewise being useful (per one of Nat Gertler's concerns in previous section). We routinely remove talkpage content for NOTSOAPBOX or spam purposes, so a discussion of such an image might be valid but the image itself in bad faith (bad-faith content even of images should be removed). DMacks (talk) 15:46, 10 July 2020 (UTC)
• Oppose only because from the file: space standpoint, we cannot easily tell when images have been used elsewhere after they have been removed. It doesn't make sense to create distinctly different policies here. --Masem (t) 16:43, 10 July 2020 (UTC)
• Support per above. If a discussion centers around an image, deleting it removes the context of the discussion and makes it more difficult to understand if not completely useless. 20:53, 10 July 2020 (UTC)
• Support It is sometime necessary to dive into history to understand why an article is the way it is, and what might be done to improve the article. Deletion does not save space and only wastes time and energy in pointless discussions. Johnuniq (talk) 23:49, 10 July 2020 (UTC)
• Support Images used on talk pages are often central to the conversation, which cannot be easily understood otherwise. -- King of ♥ 00:21, 11 July 2020 (UTC)
• Oppose per DMacks globally above, and oppose per Masem specifically for talk pages. --Izno (talk) 17:54, 12 July 2020 (UTC)
• Support Images that are part of a meaningful talk page discussion and meet the tests in WP:MTC should be moved to Commons so that the talk page history is preserved. (Otherwise, why not just purge all talk archives??). — GhostInTheMachine talk to me 20:35, 12 July 2020 (UTC)
• Oppose An image that is in use on a talk page or it's archive is not what is being discussed here. We are talking about an image that was used on a talk page but at some point in time was removed from that talk page. In either case, we have deletion processes that allow for review and movement to Commons for images with valid source and licensing information. The idea that an editor is going to find a deleted discussion in the history of a talk page to save time from repeating that discussion without understanding how to obtain access to the deleted image or mention it to someone who might feels somewhat far-fetched to me.
If an image has a possibility of future encyclopedic use, here or elsewhere, we should move it to commons. If it doesn't, we've listed that we are not a File Storage area for more than 10 years.  ★  Bigr Tex 03:04, 14 July 2020 (UTC)
If an image is moved to Commons, it already can be speedied under F8. So opposing this is pointless unless you explicitly want to delete such images without taking the few minutes to move them to Commons, in which case: why? -- King of ♥ 14:25, 28 July 2020 (UTC)
King of Hearts Is that question to me? If so, can you rephrase it?
I'll try to address it, but I may be answering something different than you were asking: I have no desire to spend time to move an image to Commons if it is going to result in a deletion discussion on Commons because the image has no expected future encyclopedic use; That is a waste of my time, the nominator's time at Commons, the admin's time at Commons, and more of my time when I have to try to remember and justify why I moved it. I prefer using the Proposed Deletion process for those images, but am also happy to use the Files for Deletion process if necessary. Again, I am talking here about orphaned talk page images that someone uploaded in the (generally distant) past for use on some talk page and is no longer in use on that talk page and for which the discussion in which it was used has not been permanently archived.  ★  Bigr Tex 03:25, 29 July 2020 (UTC)
I see, I think we are interpreting the proposal differently. I assumed that it was referring to images used in talk page archives, because almost all talk page discussions get archived (unlike mainspace edits, which I suggested a separate set of rules for). If an image is part of a legitimate talk page discussion and somehow didn't get archived, then that is an oversight and the discussion should get archived. If an image was used on a talk page and quickly reverted, then I agree that it can be deleted. -- King of ♥ 03:37, 29 July 2020 (UTC)
I am basing my understanding off of the beginning of the discussion that led to the proposal (above), "I would like to discuss what the policy is, or should be, on images that were once used in articles but no longer are."
I suspect that this part of the proposal was prompted in part by Wikipedia:Files for discussion/2020 June 12#File:Essjay 666.gif where one former editor posted a screenshot of a memorable edit count on another former editor's talk page (edit link). It remained there for four days and then was archived by the recipient. It lived in the archive for almost a year before I lose track of it; the recipient asked for all of their userspace content to be deleted when they left the project.  ★  Bigr Tex 04:14, 1 August 2020 (UTC)
• Oppose per my comment in the above section and Masem's comment in this. (talkcontribs) 20:38, 15 July 2020 (UTC)
• Oppose per above and per my comments above. -FASTILY 22:47, 28 July 2020 (UTC)
• Oppose If they're currently used in an archive, that still counts as in use. If they got blanked off the talk page, they're probably not that important anyway. --AntiCompositeNumber (talk) 17:05, 6 August 2020 (UTC)

RfC: Make Biting Newcomers A Blockable Offense

REJECTED
This discussion concerns the question of whether the blocking policy or banning policy should explicitly mention biting newcomers as a rationale for blocking (presumably in the section "WP:BLOCK#Common rationales for blocks"). The community rejects this proposal. Many editors pointed out that the blocking policy already mentions gross incivility as a valid block rationale, and a user who is persistently biting newcomers may already be dealt with under that policy. Some editors felt that adding biting may unnecessarily complicate the policy and inadvertently encourage administrators to use blocks more frequently in situations where alternatives to blocking might have resulted in a better outcome. Respectfully, Mz7 (talk) 00:38, 28 July 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 noticed that on the WP:BLOCK/WP:BAN there is no rationale that allows a user to block another user because of biting. Biting newcomers is just as bad as attacking or harrasing another user, as both can lead to the victim possibly leaving Wikipedia. As said in WP:BITE: "New members are prospective contributors and are therefore Wikipedia's most valuable resource. We must treat newcomers with kindness and patience—nothing scares potentially valuable contributors away faster than hostility." A user that scares away newcomers should not be allowed to continue to do the same to other new users. The point of blocking is to be preventative; this would prevent future attacks. I also suggest that we increase number of levels of warnings for Template:Uw-bite (we could make the template a multiple level template [eg. Template:Uw-bite1, Template:Uw-bite2, etc.]). P,TO 19104 (talk) (contributions) 15:28, 25 June 2020 (UTC)

• Comment: I don't really see why this needs to be a separate block reason. If someone is doing this to the extent that it merits a block it would fall under harassment or general disruptive editing. Spicy (talk) 15:30, 25 June 2020 (UTC)
Do we want to wait until it gets to that point, though? P,TO 19104 (talk) (contributions) 15:38, 25 June 2020 (UTC)
P,TO 19104, do we want to invent a new bureaucracy to beat people over the head with if they are trying to manage abuse? It is trivially easy to see how your proposal would be exploited by trolls, and difficult to see what it adds to existing policy. Guy (help!) 16:08, 25 June 2020 (UTC)
• Comment: Are we talking about blocking or banning? They're two different things. DonIago (talk) 16:12, 25 June 2020 (UTC)
@Doniago: Mainly blocking... sorry for the confusion with the title.
• Oppose - we already have systems in place for systematic abuse. These things go to ANI or another suitable venue for a block or a topic ban. A three-strikes policy for being poor to new editors isn't helpful, and likely get used to get experienced users in hot water over what could be a declined AfC nomination Best Wishes, Lee Vilenski (talkcontribs) 18:36, 25 June 2020 (UTC)
• Oppose - the last thing Wikipedia needs is even more bureaucracy. −−− Cactus Jack 🌵 18:39, 25 June 2020 (UTC)
• Oppose - indeed, support eliminating BITE entirely. There's no indication we are in need of new editors, and cleaning up after incompetent newcomers who have no desire to learn, or even improve Wikipedia is a significant factor in the burnout of solid competent editors. Most times when I see BITE cited it is by either PAID or SPA editors. We make a product here; this isn't a social club. John from Idegon (talk) 18:57, 25 June 2020 (UTC)
I think the proposal is 100% wrongheaded, but I can't let pass There's no indication we are in need of new editors. Everything else you said I completely agree with, but that's just absurd. EEng 15:18, 7 July 2020 (UTC)
• Oh, and just a question for the OP: Am I in your opinion bite-ing you for pointing out that despite your title, this ISN'T an RfC? John from Idegon (talk) 18:57, 25 June 2020 (UTC)
• Oppose - Any offense which would rise to the level of "blockability" for biting the newcomers would fall under patent incivility.--WaltCip-(BLM!Resist The Orange One) 18:57, 25 June 2020 (UTC)
• Oppose per JzG's comment and per WP:CREEP, but with that said note that I already do block users who go out of their way to be uncivil to newcomers. Ivanvector (Talk/Edits) 18:59, 25 June 2020 (UTC)
It is not just those who go out of their way to just be uncivil, it is also the people who show repeated patterns of being harsh or mean to newcomers. P,TO 19104 (talk) (contributions) 22:45, 25 June 2020 (UTC)
• Oppose obviously; the last thing Wikipedia wants or needs is yet another layer of weaponised bureaucracy. "Biting newcomers" is something alleged a lot more often than it actually occurs, and in most cases translates as "one of those mean admins wouldn't let me insert my favourite conspiracy theory"; on those occasions that it doesn't, we already have perfectly adequate complaints procedures. ‑ Iridescent 19:19, 25 June 2020 (UTC)
• Rather senseless - If someone is continually biting newbs, it can be handled under existing policy. More policy doesn't reduce a problem, it just adds more bureaucracy. I'm certainly not going to block someone for a single instance of BITE, whether or not policy allows it. Dennis Brown - 20:41, 25 June 2020 (UTC)
• I am not sure that "New members are ... Wikipedia's most valuable resource.", but we need all the new editors that we can get and really do need to treat them as welcome and valuable. In theory, plain good manners should be enough of a rational, but we have WP:AGF and WP:BITE to spell it out. Of course, if any user exhibits regular bad manners, to new editors or anywhere else, then there are already ways to comment and intervene. — GhostInTheMachine talk to me 20:23, 25 June 2020 (UTC)
• Support Support idea, needs better proposal - I think there is already a consensus that WP:BITE specifically refers to aggression or being unnecessarily rude to newbies who are not evidenced to be acting in bad faith. This is one reason why talk page warnings start off light and begin to escalate in the first place. If we ignored every policy or guideline that users (occasionally even a tag-team of users) are likely to game or deliberately misuse, then there would be no warning templates left. If users start claiming that they are being "bitten" just because someone made a valid reversion, that in itself constitutes a spurious allegation and is already considered bad faith behaviour. I see no issue with creating a user template for WP:BITE, though it is a valid point that it could be seen as ground already covered by pre-existing incivility templates. Though, it is unfortunate how common dishonesty is on Wikipedia, especially on noticeboards like WP:ANI. Darkknight2149 20:47, 25 June 2020 (UTC)
• Moral support We should block or topic ban editors who show a pattern of biting good faith newcomers. As others have said, we do not need to change policy to do so, and taking action against newbie biters should be handled by our existing processes. I agree with the spirit, but am opposed to the proposal. If OP or others think more warning levels for biting would be useful, you're free to make them and ask Twinkle devs to add them. 21:53, 25 June 2020 (UTC)
• Ehhh While I do think there should be more action against routinely uncivil editors (which it looks like Wikipedia:Arbitration_Committee/Anti-harassment_RfC#7._"Unblockables" will address), there are some content areas where most new editors are by default WP:NOTHERE to help but to WP:RGW right off the bat. If that wasn't the case, discretionary sanctions and WP:ECP wouldn't exist. Some of these areas attract users who only know how to use intellectually dishonest tactics that could appear to be civil if you don't look directly at it but are fundamentally incompatible with a productive environment for an encyclopedia. In some extreme cases, such as QAnon and InfoWars, you have new users who have flown so far beyond the Overton window that they can only assume that anyone who doesn't believe that the Democratic party is running a pedophile ring in the non-existent basement of a DC pizza parlor for the glory of Satan is just pushing a political opinion and we should give their "facts" a fair shot, too. These sort of users do not need a welcome. The only guidance they need is to get off the site until they've rejoined reality. Ian.thomson (talk) 22:23, 25 June 2020 (UTC)
I will clarify that this isn't the case for all contentious topics. Even though there's DS for pseudoscience, we have to put up with the RGWs at evolution and creationism related articles because even if the majority of drive-by young earth creationists are simply never going to be productive, they're not peddling anything that's inspired people to shoot up family restaurants. Ian.thomson (talk) 22:53, 25 June 2020 (UTC)
• Moral support (but opposed to this proposal) We need to do better, but this is not a step along that path.S Philbrick(Talk) 22:30, 25 June 2020 (UTC)
• Comment I think most biting falls below the level of blocking or banning. Trying to use those tools to counter it would only lead the biter to dig in and ultimately claim vindication. More constructive would be providing feedback: "Hey, maybe you were over-the-top in the way you responded to that new editor." It's easy to reinforce the view that biting is justified because it makes the bad editors go away. It's a lot harder to see the good editors we are losing because they just needed a bit of civility and guidance.--Trystan (talk) 23:27, 25 June 2020 (UTC)
• Oppose this is like using a sledgehammer to crack a peanut. There are plenty of bad faith newcomers where I edit who would try to weaponise this. Plus WP:CREEP. Peacemaker67 (click to talk to me) 00:24, 26 June 2020 (UTC)
• Oppose, surely this would be covered under WP:CIVIL anyway, and I feel as if this could easily be misinterpreted and result in unjust blocks. Ed6767 talk! 00:36, 26 June 2020 (UTC)
• Support idea, oppose proposal - Yes, biting newcomers should be taken seriously. But in those situations where a block is the right move, one can already be applied under existing policy (civil). Levivich[dubiousdiscuss] 06:11, 26 June 2020 (UTC)
• Support idea, oppose proposal. We do need to take biting newcomers more seriously than they do, but this well-intentioned proposal is not going to get achieve that. Bitiness needs to be taken to AN/I sooner than it is and admins there need to act on it more harshly but if blocks are necessary they can already be applied - we just need to be better at doing so. Thryduulf (talk) 13:23, 26 June 2020 (UTC)
• Support idea, oppose proposal, per Thryduulf. The big story of the past year is that we need to take WP:CIVIL more seriously. We're making progress there, but more needs to be done. As Thryduulf and others have pointed out, we've already got the tools, we just need to use them. It's more of an cultural education thing than needing more rules. -- RoySmith (talk) 15:29, 26 June 2020 (UTC)
• Oppose. Often you can't tell someone is a newcomer. The ones that aren't really new would use this as a club to promote...whatever they're promoting.Jacona (talk) 15:57, 26 June 2020 (UTC)
I definitely agree that we need to take civility more seriously! Jacona (talk) 16:00, 26 June 2020 (UTC)
• Oppose we need to worry far less about civility and far more about toxicity. That's especially true of new users who, in a significant number of cases, aren't really new,b but are here to cause trouble, promote causes or advertise shit. We need to be kind and pleasant, but sometimes telling them forcefully they're wrong, they're being stupid or their proposal is idiotic is the only way to get through to them that they're, well, wrong, being stupid or their proposal is idiotic. Sugar coating stuff just gets people addicted to the coating. So no, no more bureaucracy. But be nice to other people, or fuck off. Nick (talk) 17:23, 26 June 2020 (UTC)
• Oppose as the classic solution putting out a small ad for a problem. If someone BITEs so often that we need a policy on it, then, well, we have that already. And if it's not frequent enough to draw attention to it then a policy probably wouldn't address it. And that's before the opportunities for wikilawyering over who qualifies as a newb begin: 6 weeks? 6 months? With less than X-edits? Etc... ——Serial # 17:25, 26 June 2020 (UTC)
• Oppose and Nick put it better than I could. It's just going to be weaponised and make it harder to deal with actual problems. The proposal has my moral support, though. ProcrastinatingReader (talk) 17:43, 26 June 2020 (UTC)
• Oppose first-time offenses can be generally admonished without using the block button, and any further incidents can be treated as normal incivility, up to and including an ArbCom case. – John M Wolfson (talkcontribs) 05:52, 29 June 2020 (UTC)
• Oppose, Nick sums up my thoughts exactly. Cavalryman (talk) 08:04, 29 June 2020 (UTC).
• ANI levels only—defined as urgent, chronic or intractable—c'mon, give 'em a break for first or minor offenses. Long-term? Okay that's a CIVILITY issue. I oppose the idea of a 4 level uw for BITE; I rather see something like {{uw-ew}} and {{uw-ewsoft}} where the soft one is for first time or minor offense and the uw-ew, the "hard one", is for ones that would be a general warning or for borderline ANI level biting. {{reply to|Can I Log In}}'s talk page! 20:20, 2 July 2020 (UTC)
• Oppose Despite claims to the contrary this would be a punitive block since there is no way to know how a given editor will treat the next newbie that they come into contact with. If there is an ongoing pattern then a report an AN/I with evidence will lead to a block. MarnetteD|Talk 15:58, 7 July 2020 (UTC)
• Oppose But biting the newbies is fun, their knees always seem tasty. -Roxy the elfin dog . wooF 16:03, 7 July 2020 (UTC)
• Oppose - We already have WP:Civility for intractable rudeness and I don't want to be sanctioned for occasionally chomping on a new editor who is clearly WP:NOTHERE. -Indy beetle (talk) 01:48, 16 July 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.

RfC on warning level template categorization of talk pages

Should the tracking categories left by "lower" level warning templates (example below) be included when a "higher" level/order warning template of the same base template are already present on a talk page? Should a bot remove "lower" order warning categories (but limited to the same base template)? --TheSandDoctor Talk 18:48, 22 July 2020 (UTC)

To be clear, this isn't intended as something that would be mandatory, I am just asking if it would be acceptable for a bot to clean this up.

Example:

Oppose

1. I prefer them not being removed. This let's me see whether an editor followed a reasonable warning path Nosebagbear (talk) 12:20, 23 July 2020 (UTC)
2. Per Nosebagbear. It is imperative that a user knows what path of editing the user to be warned has been on. Bingobro (Chat) 12:51, 4 August 2020 (UTC)
3. Per Nosebagbear. I'd like to add that some warning templates use a generic warning for their level 4, and if categories were removed like the proposal suggests, that's some useful information lost. Bowler the Carmine (talk) 04:58, 6 August 2020 (UTC)

Discussion

• In my opinion on this, this is rather moot duplication that isn't necessary. --TheSandDoctor Talk 18:47, 22 July 2020 (UTC)
• I can see the advantage of keeping it this way; for instance, automated detection of whether a l4 warning was issued after a l2 warning, or whether someone went straight to l4. I can also see, however, that it'd make navigating those categories a bit of a pain. I'm not seeing an obvious way of reconciling those two immediately, without some horrifically complicated system of categories like "users with l1, l3 and l4 warnings from July 2020". Anyone who has more of a clue might well be able to come up with one, though! Naypta ☺ | ✉ talk page | 19:55, 22 July 2020 (UTC)

RfC on whether certain sources are considered to have a conflict of interest

There is a request for comment on whether certain sources ("articles by any media group that [...] discredits its competitors") are considered to have a conflict of interest. If you are interested, please participate at Wikipedia talk:Verifiability § Does Footnote 9 still have consensus? — Newslinger talk 06:41, 24 July 2020 (UTC)

Proposal to mass-create category redirects to resolve ENGVAR variation in the spelling of "organi[sz]ations"

Discussion at Wikipedia talk:WikiProject Categories#Organi[SZ]ations_category_redirects. --BrownHairedGirl (talk) • (contribs) 13:48, 25 July 2020 (UTC)

RfC: if a list exists in a non-English Wikipedia the corresponding English list should be allowed to use Wikidata for its tables - withdrawn as badly worded

WITHDRAWN
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 propose that if a list exists in a non-English Wikipedia the corresponding English list should be allowed to use Wikidata for its tables. This would have the advantage that the same structured data would not have to be updated in several different places. I would use it on List of active coal-fired power stations in Turkey. Chidgk1 (talk) 06:10, 27 July 2020 (UTC)

Is this table in tr.wikipedia drawing its information from Wikidata? Is the information in that table drawn from reliable sources that can be verified? Those are two questions that I would need answered before offering my opinion on the matter. -- llywrch (talk) 20:51, 27 July 2020 (UTC)
The table in tr.wikipedia is not currently drawing its info from Wikidata but it is tagged as not meeting standards (probably accessibility for a start) and also has the tag "Bu maddenin daha doğru ve güvenilir bilgi sunması için güncellenmesi gerekmektedir." which means that it needs updating. I hope reasonably soon to have the Wikidata in a better state than the tr.wikipedia table. I believe the sources are generally reliable (I will be checking details later) except the CO2 emissions which are much too generalised estimates. So before adding the carbon footprint to Wikidata I need to think more about that particular point. Chidgk1 (talk) 05:39, 2 August 2020 (UTC)
To echo the above, different language wikipedia's have different sourcing requirements. Lists on ENWP are required to be sourced in line with ENWP's policies and guidelines, not tr.wikipedia's. So while the list *may* satisfy the requirements, we cant automatically say 'yes we can use wikidata' since wikidata is even more unreliable than the various language-wikipedias when it comes to reliable sourcing. It routinely contains information imported from the various wikipedia's that may be reliably sourced in one language, but not another. Only in death does duty end (talk) 20:57, 27 July 2020 (UTC)
Perhaps I wrote the proposal too vaguely. I am not proposing 'yes we can use wikidata' for every international list in English - that should be for editors to judge and argue the case on the English talk page for a particular international list. Can I now amend it to read "if a list exists in a non-English Wikipedia the corresponding English list should not be technically blocked from using Wikidata for its tables" or would I have to submit a new RfC? Chidgk1 (talk) 06:37, 2 August 2020 (UTC)
Thats actually an entirely different question that can suffer from the same core issues. If a list article is notable on ENWP, and another wiki has the same list whose data is on wikidata, you can use the information from wikidata, but you have to check it conforms to ENWP's policies. You can use something like User:ListeriaBot to pull the data to your sandbox then verify it before putting it in the article. What you cant do is automatically pull the Wikidata list directly to articlespace - due to the issues with reliability, sourcing etc already mentioned. If you want to propose a change to allow pulling data directly from wikidata into articlespace, I very much doubt you will get consensus to do that. Ever. Only in death does duty end (talk) 07:48, 3 August 2020 (UTC)
• Oppose using wikidata for anything. Very unreliable. Smeat75 (talk) 21:04, 27 July 2020 (UTC)
• Oppose Independently of the merits of using Wikidata, I don't see why the existence of a page in another language's Wikipedia makes using Wikidata in the English Wikipedia any more reliable. * Pppery * it has begun... 00:04, 28 July 2020 (UTC)
I am not saying that Wikidata has to be used just that we should have the option. The data should be more reliable in some cases as it should be less effort to keep up to date. In many cases, as many say, the Wikidata will be unreliable - editors can judge for particular lists which is best.Chidgk1 (talk) 05:51, 2 August 2020 (UTC)
• 'Oppose ... and can we please have a moratorium on suggested uses for Wikidata, on this page and indeed throughout the site. They're popping up all over the place eg: one recent proposal to integrate in citations is/was open. It isn't fit for purpose and will not be for years at the rate it is progressing, plus there is no commonality of standards. - Sitush (talk) 00:20, 28 July 2020 (UTC)
• Oppose, I am generally a proponent of Wikidata, but there are so many issues with this proposal (among non-yet-named ones: what prevents me to create any list on the Lak Wikipedia where there are no regular users ) that the proposal is a complete non-starter.--Ymblanter (talk) 07:06, 28 July 2020 (UTC)
Perhaps I wrote the proposal too vaguely. I want editors to use human judgement - so in the case above another editor would presumably revert your change if you were trying some kind of trick. Can I now amend it to read "if a list exists in a non-English Wikipedia the corresponding English list should not be technically blocked from using Wikidata for its tables" or would I have to submit a new RfC? Chidgk1 (talk) 06:46, 2 August 2020 (UTC)
• Support The manually updated lists here are often poorly maintained, using Wikidata to maintain them would significantly improve their completeness and reliability. That's particularly the case for international topics where the Wikidata content is in use in those language Wikipedias and being expanded by those language communities. Thanks. Mike Peel (talk) 08:34, 28 July 2020 (UTC)
• Oppose, Sitush summed up my thoughts. Cavalryman (talk) 09:07, 28 July 2020 (UTC).
• Oppose we need to be reducing, not increasing, our reliance on Wikidata. LEPRICAVARK (talk) 10:14, 28 July 2020 (UTC)
• Conditional support - i.e. support if the data is sourced, either at Wikidata (ideally), the other wiki or here (I don't know how this would work, but if it does it should be allowed). It should also be noted that this is entirely independent of the notability of the list: the existence of a list on another wiki and/or presence of data on Wikidata does not demonstrate notability for en.wp purposes any more than the absence of such a list demonstrates non-notability. Thryduulf (talk) 10:24, 28 July 2020 (UTC)
I will be sourcing on Wikidata Chidgk1 (talk) 05:59, 2 August 2020 (UTC)
• Conditional moral support, if the Wikidata item references meet en-WP sourcing guidelines. This is basically me objecting to the consensus the consensus not to link to Wikidata from within Wikipedia article bodies, though, and it would only make sense to overturn that in a more systematic way, since at Ymblanter pointed out above, carving out an exception in this way doesn't really make sense. {{u|Sdkb}}talk 06:43, 1 August 2020 (UTC)
I believe this exception makes sense because it is only about tables in multi-language lists. I don't want to waste my time trying to argue a general case. In this case I will ensure the sourcing meets both tr and en guidelines. Chidgk1 (talk) 06:04, 2 August 2020 (UTC)
• Oppose as a watering down of en-WP sourcing requirements, which are stricter than those at either wikidata or most other language wikipedias. Cross-wiki collaboration and research-sharing is good in principle, but unfortunately there's so many wikipedias with so many different standards of referencing and content that blindly pulling data between them will tend us all towards a lowest common denominator. -- Euryalus (talk) 08:11, 1 August 2020 (UTC)
I am certainly not suggesting doing anything blindly - editors need to check the quality of sourcing very carefully before using Wikidata for any particular list. Chidgk1 (talk) 06:22, 2 August 2020 (UTC)
• Oppose- Wikidata is riddled with inaccuracies and I would be very wary about using it for anything. Reyk YO! 10:03, 1 August 2020 (UTC)
• Oppose - Wikipedias (whether English or other languages) are not reliable sources - neither is Wikidata - there is no shortcut for editors actually evaluating and checking the sources themselves. Wikidata does not know whether lists on other Wikipedias are sourced, it does not know whether any sources that are used meet en:wiki's requirements for reliable sourcing, and it does not know whether the source has been correctly used (and data has not been changed since the reference was added). All this requires human editors to check.Nigel Ish (talk) 10:18, 1 August 2020 (UTC)
I absolutely agree that human editors are needed to check refs - I am a human. Chidgk1 (talk) 06:03, 2 August 2020 (UTC)
• Oppose - WD is a very useful tool, but this isn't how you use it. If for example, we were interested in filling out information on rivers in Gabon, it may stand to reason that French Wikipedia, and in-turn Wikidata, are more complete in their coverage than the English Wikipedia. In that case, a tool like PetScan is extremely helpful in using WD to quickly identify missing articles and/or list entries, where we can then find sources and include the information here. In many cases, without these kinds of cross-wiki comparisons using WD, we would often not be at all aware that we are missing coverage of particular notable subjects. Women in Red for example has been doing this kind of thing for a long time now.
But merely using WD as a source for blindly copying information just doesn't fly. That's not anything particular about WD. We do similarly for all sister projects where information is unsourced, or where we cannot as individuals read and verify the sources that are provided. GMGtalk 11:31, 1 August 2020 (UTC)
I understand what you are saying but I am not talking about "blindly copying information". Editors still need to use their human judgement and in many cases will judge that the Wikidata is not good enough. Of course the quality of Wikidata may change over the years but most lists need to be checked every few years anyway, so at that point the editor can check whether the Wikidata has improved enough to be used or deteriorated enough to be removed. Chidgk1 (talk) 06:12, 2 August 2020 (UTC)
Forgive me if I misunderstood then. If you're just talking about "storing" the information in WD...I mean...you do still have the problem of people using sources in languages they don't speak. We've also had problems with this sort of thing before. In a more perfect world, where WD is maybe more integrated and more people were comfortable working across projects...In the real world? It has tended to mainly open up avenues for clever vandalism.
Foreign language sources can be difficult without Wikidata - when I was reviewing an English article about an event in Mexico I could easily read the Spanish language sources with Google Translate but had no idea if their publishers were reliable as I don't know the country.Chidgk1 (talk) 06:19, 3 August 2020 (UTC)
Probably no way to put this with out offending somebody, but the English Wikipedia has a bit of a reputation for being project-centric, and not necessarily always playing nice with others. It sometimes feels like pulling teeth just trying to get English editors to upload their images to Commons instead of storing them locally. You wanna talk about the proportion of editors that are comfortable with WD to do anything more than bare-bones linking the articles they create?..The "pool of people" there starts to get pretty small pretty quick. In the court of public opinion, people just aren't going to trust WD, and there's likely little to nothing anyone can do to change that in the near term.
So the best way to use WD tends to be "whatever way people can't tell you're using WD even though you are." GMGtalk 11:30, 2 August 2020 (UTC)
• Oppose per GMG. There's no issue with using either Wikidata or other-language Wikipedias to identify potential reliable sources or as a double-check that an English Wikipedia article hasn't missed something out, but there are no circumstances in which another wiki should ever be used as a source in its own right. ‑ Iridescent 05:55, 2 August 2020 (UTC)
• Oppose As Iridescent says, we can reuse useful sources from Wikidata or other language Wikipedias, but the mere existence of information in Wikidata or other Wikipedias has nothing to do with whether it should be acceptable in English Wikipedia. Meters (talk) 06:12, 2 August 2020 (UTC)
I am not saying that if data exists in Wikidata it is acceptable - that should be for editors to judge for each list. The problem is that reuseing sources and keeping them up to date across languages can be very time consuming. Chidgk1 (talk) 06:30, 2 August 2020 (UTC)
But that is exactly how this RFC is worded. If it's in Wikipedia in another language then English Wikipedia can use the Wikidata. Period. No mention of evaluating sources on a case by case basis. That would be an absolute nightmare. Meters (talk) 06:43, 2 August 2020 (UTC)

Oppose Hell no. Wikidata can't even be trusted to get the short descriptions right. Importing information without a citation is a terrible idea and even worse is allowing it to be changed through edits on another wiki which aren't on our watchlists. SpinningSpark 08:52, 2 August 2020 (UTC)

• oppose - it sounds like someone trying to automate creating lists articles. Whilst using wikidata to update lists might be sometimes something worth looking into - this suggests that we should create lists because they exist on other projects. That doesn't fly, because we still have notability guidelines for lists.
I entirely agree that a list might be notable in a foreign language but not English. In no way am I suggesting automating creation of new list articles.Chidgk1 (talk) 06:32, 3 August 2020 (UTC)
Surely this also runs into a paradox, in that if an article doesn't exist we create with wikidata... But then the list exists, where we wouldn't usually base on wikidata. Best Wishes, Lee Vilenski (talkcontribs) 06:28, 3 August 2020 (UTC)
Perhaps I phrased my proposal badly - I am not proposing any change to creation of new list articles. Chidgk1 (talk) 06:35, 3 August 2020 (UTC)

I HEREBY WITHDRAW THIS PROPOSAL AS BADLY WORDED - it seems some people misunderstand what I am trying to do. I may try again with a better worded proposal in a few months time.Chidgk1 (talk) 06:44, 3 August 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.

RfC: Admin activity grandfather clause/grace period

It's highly unlikely that consensus to add a grandfather clause or grace period to the admin inactivity policy will emerge in favour of the proposal. (WP:SNOW) --qedk (t c) 09:32, 31 July 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.

Should the following sentence be temporarily added to Wikipedia:Administrators#Restoration_of_adminship (in the "over two years with no edits" bullet)?

Adminstrators desysopped on or before November 4, 2019 may be resysopped if they have made at least one edit in the last three years (rather than two years), as long as they file their resysop request before 00:00 UTC on October 1, 2020. This means that admins that meet these criteria and were desysopped for inactivity may be resysopped if they have edited in the past two years (rather than one year).

In addition, admins that would have been eligible for resysop under the pre-2019 rules should be notified of the 2019 rule change and the existence of this grace period.

This is in response to a question raised at a resysop request on WP:BN. Hopefully this RfC will clear up confusion on this and any future similar cases. Feel free to suggest wording changes. —pythoncoder (talk | contribs) 21:59, 27 July 2020 (UTC)

• Support idea, don't add to policy. While we can argue over whether admin activity requirements should be stricter or looser, when we do implement them we need to make sure we do so properly and fairly. In this case, there was simply no discussion of a grace period or what would happen to existing ex-admins. As the bureaucrat activity RfC (where there was discussion about a grace period) showed, how and whether to implement a grace period can be highly contentious, so it is unreasonable to assume that everyone who !voted in favor of the proposal would also be in favor of having the policy apply immediately and retroactively with no grace period. When we desysopped those users we told them of the prevailing policy at the time, and to change that with no notification feels sneaky. Defending it with "the wording said so" feels like fait accompli to me, since that's not what everyone explicitly !voted on (the exact implications were not presented to them for consideration). This notification/grace period should have been done in November/December 2019, but better late than never. We don't need to add it to policy explicitly, we can just ping the affected users with a relevant message on their talk page and email. -- King of ♥ 22:14, 27 July 2020 (UTC)
By the way, I support replacing the current requirements (which are arbitrary and easy to game) with 500 actions of any kind every 5 years, of which 100 must be admin-related, to be evaluated at the end of every month. At the 4-year mark, we would notify any admin who did not make 500/100 in the last 4 years to increase their activity in the next year or risk losing their adminship. We would begin implementation of this policy with a mass notification to all current and former admins so that everyone is aware, and anyone who is currently non-compliant has a year to make it up. This would be the perfect solution for admins affected by the November 2019 RfC as well, because we'll just give them their bits back upon request and they will have a year to demonstrate that they really deserve the tools. If they really increase their activity, they'll keep the tools, and if they don't, they'll lose them. -- King of ♥ 22:20, 27 July 2020 (UTC)
@King of ♥: That argument is fallacious: it is equally true that it is unreasonable to assume that everyone !voting were in favour of a grandfather clause. Even more so in fact, since it is in direct contravention of the actual text of the policy as enacted, and you need much stronger evidence to support inventing policy not authorised by the actual text than to merely apply it as written. Especially when there was no discussion there supporting "some kind of grandfather clause" and merely a failure to reach consensus on the specific terms. --Xover (talk) 06:00, 28 July 2020 (UTC)
It contravenes the actual text of the message that was sent to affected users in 2018-19. I'm not saying that everyone would have supported a grandfather clause; rather, if there is no explicit discussion of something, we default to the interpretation that results in the least change. -- King of ♥ 06:04, 28 July 2020 (UTC)
@King of ♥: Refresh my memory… Was the text of that message discussed by and !voted on by the community in an RFC? --Xover (talk) 06:35, 28 July 2020 (UTC)
It reflects previous policy which was of course enacted in an RfC. I consider it a duty to notify users when things we told them are no longer true. As Ched said at WP:BN, "Of course I'm from a day and age where a person's word was his/her bond; and that's kind of an obsolete concept these days." -- King of ♥ 06:41, 28 July 2020 (UTC)
It is quite literally an obsolete concept. "My word is my bond" is fine if you're mediæval feudal nobility; but on a 21st-century global collaborative project, "Ched"'s word binds nobody to nothing. Not even "Ched" themselves, because such personal-honour based rationales are in direct conflict with a consensus-based project. Don't get me wrong, I understand the intent and appreciate the sentiment (thus why the user name is in scare quotes); but when the community enacts a new policy, "Ched" will have to break their word if it conflicts with that policy. Blindly honouring your word under those circumstances is actually disruptive. If the policy change was insufficiently or misleadingly communicated to those affected then that's an opportunity for learning, but otherwise tough noogies. --Xover (talk) 07:07, 28 July 2020 (UTC)
Per Xover: dictum meum pactum is indeed a noble concept: but it is just that—a concept. And while it may have/had standing in real life, it's not an "obsolete concept" on Wikipedia for the simple reason that it could never apply or have applied to a crowd-sourced community. ——Serial 10:11, 28 July 2020 (UTC)
• Like the sentiment, but don't add to policy. Jack doesn't seem to be gaming, but there are some sysops that will game it. That those gaming it mess up and forget to do a qualifying action, then get desysopped, is a blessing, and they should not be resysopped. Some show what I feel is blatant contempt for the community, especially in the presence of vocal opposition to their resysopping. Just give crats some discretion on the inactivity rules. If it's an admin who made no attempt to game the rules (although they easily could have), and they say they're back, crats should be able to AGF and give it to them. If it's someone who has been making token edits/admin actions since '07 just to retain their admin status, tell them to go to RfA instead. Any codified exemptions will just be gamed. As will a grandfathering clause, especially considering most admins who will be desysopped under that criteria will be pre-nov 2019 admins, so this explicit grandfathering makes that policy change slightly moot. The intention of that inactivity RfC was probably not to make requirements immediately harder for admins confirmed under the current, harder RfA process, and give existing admins a free pass for a few more years. ProcrastinatingReader (talk) 22:28, 27 July 2020 (UTC)
• Oppose the RfC didn’t include a grace period and likely would have failed if it had included one. The intent was to prevent admins from returning under these circumstances, not to allow older admins an opt out for a year after the proposal passed. This defeats the entire point of the RfC. Additionally, as this was in the admin newsletter at the time, no further notice is needed. TonyBallioni (talk) 22:32, 27 July 2020 (UTC)
• Oppose per TonyBallioni. It's regrettable that some inactive admins were counting on the ruleset they were familiar with and have not kept up with community policy changes during their inactivity, and I'm not intending to imply any malice on anyone's part, but the RfC was settled how it was specifically to prevent inactive admins not keeping up with policy changes from getting their tools back and inadvertently running amok. If we're going to carve out an exception to policy any time someone who wasn't notified falls on the wrong side of it, why bother having a policy at all? Ivanvector (Talk/Edits) 22:44, 27 July 2020 (UTC)
• Oppose. I don't see why we would need different rules for different people. The admin tools are not an entitlement; they belong to the community and are entrusted only to those who use them for the benefit of the project. – bradv🍁 22:52, 27 July 2020 (UTC)
• Oppose I may have supported this if it had taken place at the same time as the imposition of the new rules, but it's too late to correct a perceived error in a November 2019 policy change in July 2020 * Pppery * it has begun... 23:01, 27 July 2020 (UTC)
• Oppose as well. I agree with Bradv above that we do not need different rules for different people. Let us also remember that we are not barring these returning editors from re-acquiring the tools, merely that they no longer meet the requirements for automatic restoration. They are welcome to avail themselves of the usual process at any time, just like any editor. CThomas3 (talk) 23:15, 27 July 2020 (UTC)
• Oppose I don't agree that some admins are more equal than others. Admins are expected to keep abreast of policies governing their position. That some of them do not is not evidence that the system is flawed, but to my mind reinforces the very reason these controls were put into place to begin with. Beeblebrox (talk) 23:22, 27 July 2020 (UTC)
• Oppose per TonyBallioni ,Bradv and Beeblebrox.Pharaoh of the Wizards (talk) 23:23, 27 July 2020 (UTC)
• Oppose while this is a volunteer project, it is nevertheless incumbent upon those with advanced permissions to stay up to date on the policies that govern their ability to hold those permissions. LEPRICAVARK (talk) 23:54, 27 July 2020 (UTC)
• Oppose basically along the lines of Tony/Ivan/Brad. We need to find ways to welcome back editors and reinvest them in the project. We do not need that way to be by giving them administrative toolset. Best, Barkeep49 (talk) 00:45, 28 July 2020 (UTC)
• Oppose & Snow Close This was supportable months ago, but is a little stale at this point. -- Dolotta (talk) 02:44, 28 July 2020 (UTC)
• Oppose Indeed the present state of affairs is regrettable but I think that making this change so many months after the policy was changed would be inherently unfair. --Rschen7754 02:47, 28 July 2020 (UTC)
• Oppose The ongoing gaming of the system is bad enough as-is. Why should we make it any easier? -FASTILY 05:13, 28 July 2020 (UTC)
• Oppose The mere fact that we now need a new RFC to enact the policy from the last RFC as written demonstrates clearly why we can't keep grandfathering in the old regime. By all means bring up perceived negative consequences of the enacted policy to check whether they were actually intended or if the community wants to modify the wording; but when the `crats and sysops (who were the overwhelming majority of those discussing this at WP:BN) resorts to counting angels on the heads of pins to avoid applying the policy as written to a specific case it is a clear sign we can't permit anything less than a bright-line rule.
Dear mop wielders: I love you all to death for the work you do for the project, and all the crap you wade through so the rest of us don't have to. That gets you my deepest gratitude and respect. That gets you a sympathetic hearing when you occasionally mess up, as we all do from time to time. It does not give you any special treatment: having the bit is not a "privilege" that it would be "unfair" to take away. If I am inactive and policy changes while I am not paying attention, I get no notification or grace period, and there is no grandfather clause for me. Why in the world would there be one for admins? Activity requirements are there to make sure those with the tools are up to date, and removal of the tools for inactivity is not "punishment". "Fairness" is not a relevant factor unless they started paying admins while I wasn't looking.
Here's a hypothetical for you: what'd happen if you withdrew your resysop request at BN and instead filed an RFA? I'd support you. --Xover (talk) 06:33, 28 July 2020 (UTC)
@Xover: At this point, it definitely looks like I am going to end up doing a second RfA. (Though certainly not now; I'd definitely wait a few weeks before doing that.) As for withdrawing my original request, I feel like at this point enough discussion has happened that it's probably better to let it conclude with a real consensus one way or the other, so that we don't have to start this all over again if another inactive admin returns in my same situation. Jackmcbarn (talk) 20:39, 28 July 2020 (UTC)
• Oppose per the above. I'm not sure why we are going to such great lengths to rollback progress that has been made. Nihlus 06:57, 28 July 2020 (UTC)
Someone must have accidentally clicked that darn "rollback" button on our progress, isn't it annoying how easy it is to hit? GeneralNotability (talk) 20:23, 28 July 2020 (UTC)
• Oppose. The intent of the RFC was to ensure that only administrators who were at least reasonably familiar with the current rules and norms of en.wp were automatically able to return without a new RFA. That intent is not served by this proposal. Thryduulf (talk) 09:31, 28 July 2020 (UTC)
• Oppose. The fact that the an admin hasn't edited in almost 3 years is exactly why this policy is in place. --Gonnym (talk) 09:51, 28 July 2020 (UTC)
• Oppose as, notwithstanding the near- Wikilaywering of Ironside proportions :) and however unintentionally, this flies in the face of the spirit of the previous RfCs which deliberately restricted barely or inactive admins from automatic restoration. ——Serial 10:11, 28 July 2020 (UTC)
• Note: The proposer had closed withdrawn this proposal at 12:18 UTC today, however I think that letting it remain open for at least 48 hours before declaring precipitation would be appropriate, and re-opened it. –xenotalk 12:44, 28 July 2020 (UTC)
• Note to the note: the proposer withdrew the proposal at 12:18 UTC (permalink). Ivanvector (Talk/Edits) 13:11, 28 July 2020 (UTC)
• Right, I was uncomfortable at the short runtime before however at this point it can probably be closed or re-withdrawn as unsupported now that other parties to the BN thread have been given the opportunity to comment. ( Are you still okay with withdrawl?) –xenotalk 18:47, 29 July 2020 (UTC)
• Oppose If anyone thinks anyone else needs a notice than do it, don't stand around saying someone else should give them notice of public discussions and policy they should be intimately familiar with, especially for a group of users, who are expected and entrusted to be on-the-ball. It's largely a trust issue and on the pedia trust is demonstrated in the doing. Trust is not built by carving out this or that special user treatment. But more so, yes, welcome back, it's great of you to rejoin -- trust the community, as you are asking the community to trust you, and please, put your application to them as the community has requested. -- Alanscottwalker (talk) 13:44, 28 July 2020 (UTC)
• Oppose the RfC which passed this had no grandfather clause and I don't see any good reason to add one. The view of the RfC was that people who had been inactive for this long shouldn't have administrator tools granted without a new RfA. This applies regardless of whether the admin was notified or not, and if someone needs the notification in order to make the tiny number of edits to avoid a desysop then that is an example of the type of case the rule is intended to deal with. The resysop criteria are already both very complicated and very generous. Hut 8.5 20:02, 28 July 2020 (UTC)
• Oppose - It was an honest oversight to not consider either grandfathering or notifying all potentially affected admin. This happens frequently, so we depend on Crats or admin (in other situations) to use their best judgement. In the middle of a slightly heated (but very productive) discussion with Jack at BN, that makes this the wrong time to change. I'm not fixed as to whether the Crats should or should not resysop, I trust them to do whatever prior consensus would say to do. I am against muddying up the policy with language that only applies for a short time, for a handful of people. Dennis Brown - 21:55, 28 July 2020 (UTC)
• Oppose - Absolutely not. ~Swarm~ {sting} 03:58, 29 July 2020 (UTC)
• Oppose. As others have suggested, I think it was a mistake to not directly inform potentially affected inactive admins when the change was made. But the bigger mistake, which some people still don't seem to have grasped, is that we changed the rules in a way that made it immediately impossible for some affected inactive admins to do anything about it even if they had been informed. As a way around that, I think a grace period (or something similar) should have been included. But with so little time left before it becomes moot anyway, and the very small number of admins potentially affected (I think Jackmcbarn is the only one who's been caught like this, in the seven months it's been in force), I don't think we should go back and change it now. If there are any more similar cases, the crats can deal with them. Boing! said Zebedee (talk) 14:48, 29 July 2020 (UTC)
• I understand that you want to withdraw this proposal but the reasoning should be more clear in doing so. I've amended this to a SNOW close, hope that's fine with you. --qedk (t c) 09:32, 31 July 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.

Undermining WP:NPOV through Wikipedia:Reliable sources/Noticeboard

Please participate in this discussion.--Seyyed(t-c) 05:11, 28 July 2020 (UTC)

Proposal to demote Wikipedia:Anarchism referencing guidelines to essay

Consensus to Delist as guideline and convert to essay which can now be found at Wikipedia:WikiProject Anarchism/Referencing. General consensus was most frequently based on insufficient community vetting. There were also concerns about nicheness (including some rebutting statements) and conflicting with overriding verificability requirements. The essay may be resubmitted for consideration as a guideline so long as clear notification to the broader community was made (most generally done either by Village Pump and/or WP:CENT listing). Nosebagbear (talk) 12:47, 31 July 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.

Formerly Found a niche guideline that was never widely vetted

In an ongoing discussion, I was pointed to Wikipedia:Anarchism referencing guidelines. Upon investigation, I cannot find any evidence that this purported guideline was ever approved by a community-wide consensus. Quite the opposite.

The page was upgraded from a proposal to a guideline here in 2009. The "statements on talk page" referred to must be this discussion. It's a very short and local discussion of 3 editors. One says, It's been in at least unofficial use for a long time now, and another says, I tagged it as official then. See what happens from there. And so it has sat with seemingly little scrutiny for over 10 years (although there were some complaints last year on its talk page here).

Some concerning quotes from the supposed guideline:

• dictionaries and encyclopediae should not be considered authoritative on anarchism (Encyclopedias are not authoritative?)
• If a source is a scholarly work and is not contradicted by similar or primary sources, it should be considered trustworthy, and may be represented as fact. (Letting primary sources overrule scholarly work?)
• Reference works that deal specifically with politics, philosophy, or other areas related to anarchism often suffer from the same problems as general reference works. (So reference works about politics are somehow a problem about a political philosophy?)
• though many of the websites listed below are operated by credible organisations, have editorial oversight and publish material authored by third parties. (But no one outside the topic area has verified this.)
• Because the vast majority of anarchist writings are published online and in zines, articles on anarchism are likely to rely more heavily on these sources than would be acceptable for most other Wikipedia articles. (Sounds like inappropriate exception-making. If good sources cannot be found for material it should not be included at all.)

I tend to think that this should be delisted as a guideline and turned into an essay (as well as moved to a title that does not imply it is a guideline), much as other WikiProjects have similar essays, absent evidence of wide approval. Same as was done with WP:POG (although that later became a big discussion to be properly listed IIRC, which failed). Use by Support from people within a niche topic area alone is too much of a WP:LOCALCONSENSUS to call it a guideline, on par with, say, WP:RS. Crossroads -talk- 17:04, 29 July 2020 (UTC) clarified Crossroads -talk- 17:45, 29 July 2020 (UTC)

• Support. "Use by people within a niche topic area alone" isn't necessarily a disqualifying factor, nor is the location of the discussion which certified it as a guideline. What is important is for any such discussion to be widely advertised (e.g. WP:RFC, WP:CENT, talk pages of major Wikipedia pages, major noticeboards, etc.) and to be widely attended, and this clearly wasn't met here. -- King of ♥ 17:36, 29 July 2020 (UTC)
• I clarified the "use by" bit. What I meant by that is that in that tiny discussion it only had support from a few editors in that topic area; i.e. no wide scrutiny. Crossroads -talk- 17:45, 29 July 2020 (UTC)
• Just to clarify... no need to delete, simply mark as essay and be done with it. -- King of ♥ 15:11, 30 July 2020 (UTC)
• Support delisting: I was also astonished to see this was a guideline when I saw someone mention it at Talk:A.C.A.B.. I don't see any massive issues with it but it hasn't had the scrutiny and input expected of a 2020 guideline page. — Bilorv (talk) 18:05, 29 July 2020 (UTC)
• I remember seeing this guideline being quoted many years ago (sorry, but I don't remember which discussion was involved) and saying at the time that we shouldn't have a guideline that targets such a narrow topic. I still think the same. We need general referencing guidelines, not narrow subject-specific ones. Phil Bridger (talk) 18:35, 29 July 2020 (UTC)
• Support Parts of this guideline seem to conflict with more widely known sourcing guidelines, such as WP:RS. Quoting from the guideline: "In the case of articles which chronicle a developing current event it is not a violation of Wikipedia policy to temporarily include links to blogs which contain contemporary opinion and observations about the event. A diverse mix is recommended, but the extent and selection of specific blogs is a matter of content to be determined by the editors of the article." — if this was ever common practice on WP, it certainly isn't anymore. (t · c) buidhe 19:14, 29 July 2020 (UTC)
• Support delistiing - per Buidhe. Beyond My Ken (talk) 20:16, 29 July 2020 (UTC)
• Support delistiing - makes me wonder if anything else like this has slipped through the cracks - er the memory bytes - here at the 'pedia over the years. MarnetteD|Talk 20:21, 29 July 2020 (UTC)
• Delist. No apparent need for lower threshold sourcing requirements for this topic area that I am able to immediately discern. El_C 20:24, 29 July 2020 (UTC)
• Support delisting Sounds like special pleading that could equally be urged for many other fields, but isn’t. Mccapra (talk) 21:12, 29 July 2020 (UTC)
• Delist Directly contradicts several key Wikipedia principles. --Jayron32 21:34, 29 July 2020 (UTC)
• Question - if delisted, what happens to it? Deleted? demoted to essay? Userfied? Blueboar (talk) 21:43, 29 July 2020 (UTC)
Thanks... I agree with DELIST. Blueboar (talk) 22:10, 29 July 2020 (UTC)
• Delist - As no need for special requirements that I can see. Also there was not broad community support for promotion. I agree with the idea of demoting to an essay in WikiProject Anarchism. PackMecEng (talk) 04:09, 30 July 2020 (UTC)
• WP:SNOW support. No broad community vetting in (or at least advertised at) a central project discussion space = nothing that qualifies as (or should be tolerated to purport to be) a guideline or other policy page. Hard stop, end of story. This is a good catch and follow-up on the part of Crossroads regarding this. In a converse light, whoever made this illegitimate promotion needs to be made aware of how inappropriate and out accordance with our most basic policies (those pertaining to codifying community consensus into policy itself) this action was. Snow let's rap 04:37, 30 July 2020 (UTC)
• Support delisting - Master Of Ninja (talk) 10:09, 30 July 2020 (UTC)
• Oppose deletion. Delisting OK I don't think the problems Crossroads identifies with the content are really problems once read in context and would oppose deletion. Articles on anarchism-related topics that become newsworthy (e.g. Antifa (United States) or A.C.A.B.) often suffer because of the issues these guidelines identify, and so I think the material is useful. However, if the text has not been through the rigorous community process required for guideline status, delisting makes sense. BobFromBrockley (talk) 11:05, 30 July 2020 (UTC)
• Delist and convert to essay. This was proposed and became a guideline on Sept 1 2009, and the process seems legitimate (although more of a local consensus than general consensus). This kind of fine grained guidelines is really not needed when existing policy is all that is needed to determine sourcing. Dennis Brown - 11:12, 30 July 2020 (UTC)
• Comment Crossroads notes that 3 editors were involved in the discussion leading to its listing. In case people have the impression just 3 editors were involved in the writing of the page, it is worth having a look at the page stats which show 33 editors, the main ones being Skomorokh, Richard Blatant, Aelffin, NTox, Malik Shabazz and Netoholic, some of whom are still active editors, hence my pinging. BobFromBrockley (talk) 11:17, 30 July 2020 (UTC)
• Comment: the consensus to delist seems clear, so I don't feel the need to weigh in on that, but I oppose deletion (which, to be fair, I don't think anyone has proposed) and support maintaining as an essay. An additional point in favour of delisting, which I'm surprised hasn't been raised, is that academic work on anarchism has become much more prominent and voluminous since 2009. The guideline's points about mainstream media coverage of anarchism may still hold true, descriptively if not prescriptively, but there are many more good scholarly sources available now than when it was written. – Arms & Hearts (talk) 12:33, 30 July 2020 (UTC)
• Note: I've re-titled this section and notified the Anarchism WikiProject, especially as it has been suggested to move the page under their project. –xenotalk 12:48, 30 July 2020 (UTC)
• Demote per nom and lack of community endorsement, but leave it where it is unless WP Anarchy wants to move it themselves. There are nearly 2,000 pages in Category:Wikipedia essays (not counting its 44 subcategories) and the vast majority of those are top-level Wikipedia: space pages (not user or WikiProject subpages). No reason to move it unless WP Anarchy wants to. Ivanvector (Talk/Edits) 15:34, 30 July 2020 (UTC)
If demoted, the present title might give the mistaken impression that someone is linking a guideline when referencing it. –xenotalk 15:43, 30 July 2020 (UTC)
Yes, and most essays aren't WikiProject-specific like this one is. Crossroads -talk- 17:10, 30 July 2020 (UTC)
• Delist and I'd suggest moving it to a subpage of Wikipedia:WikiProject Anarchism. As noted several parts of it contradict widespread consensus and practice. Although WP:ARGH is a nice shortcut. Hut 8.5 17:50, 30 July 2020 (UTC)
• Delist Per Demote, a guideline may be re-classified as an essay if it no longer conforms with editorial practice. In this case it conflicts with Reliable sources. TFD (talk) 19:11, 30 July 2020 (UTC)
• Delist per all. Too niche (without adequate justification) for a guideline to begin with, and with concerning content per above. – John M Wolfson (talkcontribs) 06:16, 31 July 2020 (UTC)
• Delist. While I'm not entirely against an SNG here, the fundamental premise for the existence of this one is fake. It is not true that there is a shortage of reliably published sources on the topic in the early days of Wikipedia; gbooks has literally hundreds of results from 20th century books.[4] and there are quite a few from the nineteeth century also.[5]. There can sometimes be a basis for an SNG setting special criteria for notability (WP:PROF is the classic example) but anything that tries to weasel out of the reliable sourcing guidelines has to go. SpinningSpark 09:58, 31 July 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.

Move request discussion: Title for the Suicide of Kurt Cobain article

Opinions are needed on the following: Talk:Suicide of Kurt Cobain#Requested move 27 July 2020. One thing it concerns is interpreting the WP:Article title policy. Flyer22 Frozen (talk) 02:47, 30 July 2020 (UTC)

Note that there are two things going on with respect to this title, one being a conspiracy theory that the subject didn't kill himself, and the other being a broader question of whether the ~40 "Suicide of..." titles in Wikipedia are appropriate. BD2412 T 03:20, 30 July 2020 (UTC)
As I mentioned in the move request, I think there should be a guideline on this. I note that there is an article, Death of Adolf Hitler, who committed suicide. There was speculation after his death that he was still alive, although it was soon relegated to the fringe. TFD (talk) 19:27, 30 July 2020 (UTC)
There is related discussion on this at Wikipedia talk:Requested moves#"Shooting of" or "Killing of". Lev!vich 16:42, 7 August 2020 (UTC)

Am having problems logging in

Not the purpose of this page. ―Mandruss  21:27, 31 July 2020 (UTC)

Hyphens and African Americans

I'm asking here because I don't know where else to ask. The AP style guide has removed the hyphen this year in African American and other hyphenated dual identities.AP tackles language about race in this year’s style guide Columbia Journalism Review Why has not Wikipedia followed this practice? I thought Wikipedia followed the AP style guide, but no? Such articles as the one on Barack Obama and virtually every other article using African America as a descriptor use the hyphen, e.g. African-American history. Thanks, Krok6kola (talk) 13:30, 3 August 2020 (UTC)

Wikipedia has its own Manual of Style (MoS), which is certainly influenced by AP and other well-known style guides, but does not necessarily follow them completely. In this case, per MOS:IDENTITY, the term most often employed by recent reliable sources should be used. You might try asking at WT:MOS to see whether there is consensus that the unhyphenated variant meets this criterion already, but it may be necessary to wait and see which style is most commonly adopted. But if AP has switched its guidance I'm sure there will be more institutions that follow. – Teratix 14:07, 3 August 2020 (UTC)
(edit conflict)Wikipedia has its own style guide, the front page of which you'll find at Wikipedia:Manual of Style. That style guide, like Wikipedia itself, is built by consensus, and is influenced by other style guides but not dependent upon them. I'm not quickly finding guidance on this specific question; MOS:HYPHEN talks about our use of hyphenation in general but doesn't delve specifically in the -American issue. If you think this should be changed, the best place to suggest a change would be Wikipedia talk:Manual of Style, which is where such things get thrashed out. Please be aware that even if we change the guide, it will likely take a long time for that change to be absorbed into the existing articles (one cannot just blanket search-and-replace the term, as there are things like quotes from printed works or proper names like National Association of African-American-Owned Media which we would not want to change.... but eventual change is created by starting now. --Nat Gertler (talk) 14:10, 3 August 2020 (UTC)
Honestly I'm a bit surprised that we're using "African-American", as in my experience the unhyphenated form is much more common and thus would satisfy the requirement of following RS's usage. I do note that we appear to use "African-American" when we're describing African American things, such as African-American literature, whereas for people and the ethnic group as a whole we appear to use African American. I don't know if this speaks to a particular trend within style guides or if this is just an idiosyncrasy that we adopted. Searching on Google trends, the unhyphenated form is far more common. I unfortunately wasn't able to do a particularly thorough search on Google Scholar because their search engine appears to automatically interpret the hyphen as equivalent to a space, but there appears to be plenty of use of the unhyphenated form, even when used as an adjective. signed, Rosguill talk 14:26, 3 August 2020 (UTC)
Another data point: surveying the titles in the citation section of African-American literature and doing my best to avoid double counting, I see 4 "African-American" vs 10 "African American", as well as 11 "Black" and 1 "Black American". signed, Rosguill talk 14:33, 3 August 2020 (UTC)
I've gone ahead and notified WikiProject African diaspora of this discussion. signed, Rosguill talk 14:36, 3 August 2020 (UTC)
Why is this an issue? This is hardly an issue over appropriate naming. I'm open to evidence to the contrary, but whether or not to use a hyphen seems unlikely to be a sensitive issue in racial matters. Rather, it is just a matter of style, and on style issues we should follow our own style guide whatever the sources are doing. We wouldn't, for instance, start writing article titles in title case instead of sentence case just because that's what a source is doing. MOS:HYPHEN isn't prescriptive on this, but it seems quite keen to hyphenate compound modifiers. SpinningSpark 14:53, 3 August 2020 (UTC)
hm, looking at MOS:HYPHEN, the instruction never insert a hyphen into a proper name (Middle Eastern cuisine, not Middle-Eastern cuisine) would seem to suggest that we shouldn't hyphenate African American. signed, Rosguill talk 15:12, 3 August 2020 (UTC)
Well, that's seeing "African American" as a single proper name, rather African as an adjective modifying American, which is one way of viewing things, but not the only way. --Nat Gertler (talk) 16:27, 3 August 2020 (UTC)

Thanks for all the responses! AP style guide, MLA style guide, and Chicago Manual of Style add call for no hyphen.[6][7][8] And I never see African American hyphenated in real life. But there seem to be strong positions on Wikipedia to keep it, even though, as you say above, there is no actual policy about this specifically. Barack Obama is called the first African-American president, which redirects to African American but those that control the article prefer to keep the hyphen. I don't want to get embroiled in discussion on the manual of style pages here on Wikipedia as I don't have the stomach for that kind of thing anymore, but thanks so much for providing feedback on my question. Krok6kola (talk) 17:17, 3 August 2020 (UTC)

So this was WP:FORUMSHOPPING? 16:12, 4 August 2020 (UTC)

RFC: Multiple roles for active arbitrators

Background:

• In July 2020, the Wikimedia Foundation began seeking volunteers for the Trust and Safety Case Review Committee. The role of this committee is to serve as a sort of safety valve, allowing a small group of community members to help review decisions regarding office actions taken by the Foundation, adding an appeals procedure to what was previously not subject to appeal of any kind. Membership in this group will be secret as well as all internal discussions and processes. This committee will report only to the Foundation Trust and Safety department.
• There is another body known as the Ombudsman commission which investigates issues regarding advanced permissions such as checkuser, oversight, and other issues involving the Access to nonpublic personal data policy. This group's membership is not secret, but its proceedings are. Other than occasional public reports with anonymized data, they report only to the WMF Board of Trustees.
• The goal of this proceeding is to determine whether membership in either of these bodies constitutes a conflict of interest for current members of the English Wikipedia Arbitration Committee, as they may be asked to review cases in which they were involved in their role as arbitrators, or even to review the actions of fellow arbitrators, and there is no way for the community to know if they are doing so, and if there is a conflict, to determine whether active arbitrators should be barred as a matter of policy from simultaneously serving on either of these other bodies.

Case review committee

Should currently serving arbitrators be barred from concurrently serving on the Trust and Safety Case Review Committee?

It should be noted that a question regarding whether the foundation would respect such a restriction was posed, and a foundation representative indicated they would respect it. [9]

Support (Arbs and case review)

• Support as proposer. I fully understand the need for this committee to be so secretive, but I feel there is an inherent conflict with the possibility that someone banned by arbcom may later be subject to banning by the office, and an active arb would likely already have a pre-formed opinion on the matter that could deny the appellant a fair hearing. We could ask that they recuse in such cases, but since we wouldn't even know who is on the committee there would be no way to know if they really did. Beeblebrox (talk) 16:23, 3 August 2020 (UTC)
• Or conversely, such a recusal would surely have the potential to out them as a member of the committee. — Bilorv (talk) 19:30, 7 August 2020 (UTC)
• Support as reasonable proposal per Beeblebrox and with the confirmation of meta:Special:Diff/20262061 in mind. ~ ToBeFree (talk) 17:44, 3 August 2020 (UTC)
• Support Makes sense to me. While I don't generally like creating unenforceable rules, I feel the linked confirmation from the foundation addresses that concern. * Pppery * it has begun... 18:18, 3 August 2020 (UTC)
• Support - alliances and prejudices are difficult to overcome, even for the best of the best. T&S must be completely detached, although I have no objection to (and encourage) ArbCom seeking input from T&S when they are faced with difficult decisions that may be influenced by alliances or preconceived notions about someone in the community. Atsme Talk 📧 20:29, 3 August 2020 (UTC)
• Weak support While I understand the need for the membership of this committee to be secret, I don't like the idea of creating rules that can't be enforced by the community. That being said, while I believe that any current arb would act with integrity and recuse themselves if they believe a conflict-of-interest exists, it's far better to remove the issue entirely with this proposal. OhKayeSierra (talk) 21:14, 3 August 2020 (UTC)
• Support—ok, it's difficult to enforce, but I do think that WMF will hold to its promise. This will act as a failsafe against COI issues and help keep the committee fully independent. (t · c) buidhe 21:20, 3 August 2020 (UTC)
• Support It is a conflict of interest to hear an appeal to a case you've already heard. Because the T&S committee membership is secret, it is impossible to know who would have such a conflict of interest and when. If the committee membership were not secret, I think we could afford to be more lax since we could handle conflicts of interest on a case-by-case basis, but if that is not possible, we should not create an opportunity for conflicts of interest to appear. Enforcable or not, we should make clear that this is the community expectation and trust that our arbitrators will respect our local policies even if the WMF does not. 01:08, 4 August 2020 (UTC)
• Support, just makes sense. --SarekOfVulcan (talk) 01:13, 4 August 2020 (UTC)
• Support our elected Arbs could be compromised if brought into secret WMF cooperation. 13:58, 4 August 2020 (UTC)
• Support, though more on the grounds of the weight of caseload and availability. Stifle (talk) 14:01, 4 August 2020 (UTC)
• Support per COI concerns. ——Serial 14:34, 4 August 2020 (UTC)
• Support wholeheartedly. Arbs are already overloaded and stressed. Even if there were no COI issues I would support most anything to limit Arbitrator workload and stress. EllenCT (talk) 21:14, 4 August 2020 (UTC)
• Support. First for the obvious reason that it's unenforceable. More particularly, because this is intended to be a small group, and the Arbitration Committee regularly refers certain user issues to the WMF. This could potentially give someone who is a member of both groups two kicks at the can in relation to user management. As well, I really wonder about any arbitrator who feels they have an extra 5-10 hours a week to take on this task. Many arbitrators would be excellent candidates once they have completed their term on the Arbitration Committee. This overlap is undesirable and unnecessary. Risker (talk) 22:26, 4 August 2020 (UTC)
• Support Per Risker. It's an obvious conflict of interest, and with no transparency for the T&S committee (which is understandable, given the issues that they address) it would be easy for an arb to gain too much power over users. ThePlatypusofDoom (talk) 23:51, 4 August 2020 (UTC)
• Support per Risker, especially due to the conflict of interest it presents. 0qd (talk) 23:59, 4 August 2020 (UTC)
• Support Unlike my !vote for OC - because this relates to users that often have made edits to English Wikipedia (as the largest wiki), it is harder to determine when recusal should happen. What do we do with editors who were WMF banned for edits across several wikis including enwiki? What if ArbCom received complaints or internally discussed the user's behavior but chose not to act? With this combination it would be harder to compartmentalize. --Rschen7754 02:41, 5 August 2020 (UTC)
• Support Makes sense on the merits, not convinced by arguments over unenforceability. While my trust in the WMF is not particularly high, I do not think they would blatantly lie when they said they would respect a community prohibition. -- King of ♥ 03:08, 5 August 2020 (UTC)
• Support due to possible COI, I disagree that it is unenforceable (The T&S committee would know who its members are anyway). I can see a strong case for cooperation and communication between the entities however Cas Liber (talk · contribs) 03:32, 5 August 2020 (UTC)
• Support for conflict of interest relating to cases referred to WMF by Arbcom, cases made by others against Arbcom members, and cases made under the Office Action catch-all clause that "community actions have not been effective." Presumably "community actions" includes Arbcom actions, forcing any sitting arb on this review committee to evaluate actions taken on the basis that they and their colleagues weren't up to the job. Better for both arbcom and future complainants to keep the processes separate. -- Euryalus (talk) 05:31, 5 August 2020 (UTC)
Without getting overly conspiratorial there's also the prospect of people seeking office actions because they feel that "community actions will not be effective," which is effectively their vote of no confidence in Arbcom's ability to handle the complaint. It would raise unnecessary conflict of interest concerns to have a sitting member of Arbcom reviewing an office action which only occurred because the complainant didn't want Arbcom to deal with it or even know it had been made. Can't say I support this kind of application of office actions - on any wiki with a functioning dispute system, office actions should be restricted to substantive cross-wiki and/or legal matters (eg. child protection). But we seem to be on a path toward more WMF involvement in community disputes, so there it is. As above, while new processes evolve its better for all concerned if the en-wiki Arbcom and the WMF's alternative structure can communicate with each other while avoiding direct overlaps in personnel. -- Euryalus (talk) 07:34, 6 August 2020 (UTC)
• Support per the obvious conflict of interest. I might add that I don't like the super-secret nature of this new committee. Just tell us who they are. LEPRICAVARK (talk) 03:05, 6 August 2020 (UTC)
• Support. The Arbitration Committee this year alone has given itself way too much power and way too much overreach in terms of how to handle administrators' conduct and what the consequences should be. The last thing we need is them tag-teaming with T&S in overreaching even further. Softlavender (talk) 07:37, 6 August 2020 (UTC)
• Support - The WMF says they'll respect this local rule, and the OC will be able to verify whether it was been complied with (unclear how this could be communicated back to ArbCom, but there will be independent verification). Makes sense to me, per what Risker says. -- Ajraddatz (talk) 15:33, 6 August 2020 (UTC)
• Strong Support per Atsme and Softlavender, although per the opposes by TonyBallioni ad Andrew Davidson would probably be unenforceable, and because history has shown that both the WMF and Arbcom members sometimes have personal vested interests. This still leaves the entire movement with the conundrum Quis custodiet ipsos custodes? Kudpung กุดผึ้ง (talk) 22:40, 6 August 2020 (UTC)
• Support: the reasons above seem to make this quite a common-sense approach. The only objection I could think of myself is that hypothetically, what if there weren't enough people qualified, experienced and responsible enough to be on the T&S Committee that were not current arbs? I concluded that this is very far from being true because the whole structure of Wikipedia eschews such monopolies on power. Someone on both committees would have a huge amount of power for a site that I see as fundamentally decentralised. The main strength of Wikipedia's community is that most people who do good stuff are not admins, most admin actions are heavily tied to community consensus and there are very few rules imposed from up on top. It is also a major weakness in many ways, but that's another story. — Bilorv (talk) 19:30, 7 August 2020 (UTC)

Oppose (Arbs and case review)

• Oppose as unenforceable since the membership will be private and the WMF would be free to ignore this if they felt they had a good reason. TonyBallioni (talk) 16:40, 3 August 2020 (UTC)
That's why (as noted above) I got them on record saying they would respect any such local rule well before proposing this. [10] Beeblebrox (talk) 16:45, 3 August 2020 (UTC)
Thanks. I’m still generally skeptical of unenforceable rules from a community perspective. If we can’t verify that the rule is being followed; I don’t really like the idea of having it. TonyBallioni (talk) 16:47, 3 August 2020 (UTC)
• Oppose This committee is appointed by the WMF and their legal staff in particular. The solicitation expects volunteers to have credentials and "Credentials in this case refers to community background - have you been an administrator? A member of an arbitration committee?" In other words, they seem to be specifically looking for people like admins and arbs. If other people don't think that's a good idea then that's just too bad as the people who are appointing this committee will be deciding. Anyway, anyone who is active on Wikpedia in any capacity might have a conflict of interest and so the issue is unavoidable. I suppose they will be looking for the sort of respectable and responsible people who will recuse when appropriate. People like arbs, who commonly recuse from cases already. Andrew🐉(talk) 20:11, 3 August 2020 (UTC)
• Oppose largely per TonyBallioni: a rule that cannot be audited cannot be enforced, and an unenforceable rule is pointless. Overall I don't understand the value of a reviewing body so secretive that we can't even know who is a member; frankly I think the community should demand that at least one (maybe more) current arbitrators should be on this secret committee, for some measure of accountability, even if we can't know which specific arbitrators are selected. Otherwise this all reads as sinister to me, like the WMF is going to start disappearing editors they have dirt on, and point to review by this secret review board as justification for whatever actions they take. I don't like it. Ivanvector (Talk/Edits) 14:31, 4 August 2020 (UTC)
that we can't even know who is a member I guess the idea is that some people may not be willing to sign up to possible personal abuse for controversial decisions. Second concern is a good point, but I'd note that regardless of whether this proposal passes or fails, it won't stop that. Even if arbs are allowed on the committee, if what you say is the foundation's goal, they'd just not pick any arbs to be on the committee. Since the membership is private, nobody would know if an arb is on it or not. ProcrastinatingReader (talk) 14:50, 4 August 2020 (UTC)
• Oppose utterly unenforceable because a member of the review committee can't even tell you if they have ever been on the committee in their lives --Guerillero | Parlez Moi 19:47, 4 August 2020 (UTC)
• Oppose. This proposal is too much enwiki centered. In fact, the vast majority of cases this committee will be dealing with are not going to be much related to enwiki. In a small number of cases, in which a committee member has participated as a member of ArbCom, they can just recuse themselves. Ruslik_Zero 20:36, 5 August 2020 (UTC)
• Support idea, oppose proposal. I don't care if they're on both committees. However, we should have a policy that if they dealt with a case on one committee, they recuse from duties involving it in another. —Mdaniels5757 (talk) 20:15, 6 August 2020 (UTC)
• Strong Oppose - case review members who are ARBCOM members should have to recuse themselves from any case they've already handled (most likely recusing as ARBCOM members), but an absolute severance reduces a valuable pool unnecessarily. There's likely to be very few cases where this is an issue so a small overlap is causing a major consequence. Since the WMF has stated they'd respect such a restriction, I'd suggest making a policy that required recusal, with failure to do so grounds for removal from the case review committee. I believe Ombudsmen will know the identities, they could be tasked with overseeing if there are concerns about the WMF lying, for some reason. Nosebagbear (talk) 13:26, 7 August 2020 (UTC)

Discussion

So this committee reviews T&S decisions? Have there been cases of T&S taking action against active arbitrators before? If not, realistically, the only conflict of interest would be if this committee is reviewing a case that was also heard before ArbCom? So, have there been cases of T&S overriding ArbCom decisions before? Since this temporary body only reviews T&S actions, the scope of COI seems limited to me. As a matter of principle, I don't see why ArbCom itself isn't able to review T&S decisions, but since it isn't I don't immediately see the issue with an arbitrator serving on this committee too. It doesn't seem like the majority of their cases would be reviews of arbitrator action / cases previously heard at ArbCom. Aside from that, this would cause competent candidates to have to choose between that committee and ArbCom. I think there's an overlap in skills that would make a person competent to serve on either body, so is this limitation not an issue? ProcrastinatingReader (talk) 17:02, 3 August 2020 (UTC)

I don't know that there has been a case of T&S overriding arbcom, but there have certainly been cases where arbcom has banned someone and they later went on to get an office ban as well. That's where the concern comes in, when that person appeals to this top-secret committee it could be a case of an arb reviewing their own decision. I'd like to think they would have the integrity to recuse in sucha case, but with the committee being a total black box, the only way to even be kind of confident it won't happen is to prohibit dual membership. Note that former arbs are not included in this proposal, so there'd still be a large body of qualified people who could apply. It is a global group so it's not as if everyone has to be from en.wp. Beeblebrox (talk) 18:20, 3 August 2020 (UTC)
Speaking of former arbs, there's automatically a problem there too? Of possible COI scenarios, there's a decent chance the arb on the original case was from a previous term. This proposal wouldn't fix that issue? Short of a proposal to disallow allocating cases to people who were arbs on the case (whether current or former) I think this COI issue would still exist ProcrastinatingReader (talk) 14:43, 4 August 2020 (UTC)
I am puzzled by this concern. Arbitrators hear appeals all the time as part of their work. We see Arbs accept appeals from banned users who they voted to ban. The CRC is different in that it's reviewing foundation work and seemingly only for error (rather than WP:SO type appeals) but arbs review their own decisions on the regular. So I can appreciate the separation of power type argument but the idea that arbs would have an insurmountable bias seems at odds with what we normally expect of arbs (and how, on the whole, I see them act). Best, Barkeep49 (talk) 14:55, 4 August 2020 (UTC)
• Going on from my oppose above, why not just require recusing in crossover cases. The WMF have said they'd respect a restriction, so why not make one that has people removed from the CRC if they fail to recuse when hearing it as an arb? If we think that simultaneously both an arb and T&S will lie on the matter, the Ombudsmen have sightline into both, and I think between those three things, and the seemingly small overlap, that should mitigate any issues without bringing in problems. Nosebagbear (talk) 13:35, 7 August 2020 (UTC)

Ombudsman commission

Should currently serving arbitrators be barred from concurrently serving on the ombudsman commission?

Support (Arbs and Ombuds)

• Support as proposer. Really, even more so than than with the case review committee, because the Ombuds may, at any time and without our knowledge, be reviewing the actions of functionaries or even arbitrators here. As their proceedings are entirely secret, we have no way of knowing if and when conflicts between the two roles arise, so it seems best to simply eliminate even the possibility. Beeblebrox (talk) 16:23, 3 August 2020 (UTC)
• Support they’d have to recuse anyway (or should) on an en.wiki matter since dual oversight roles is less than ideal. TonyBallioni (talk) 16:39, 3 August 2020 (UTC)
• Support an individual shouldn't be serving on two bodies with overlapping oversight purposes with presumably 'equal' authority. Not to mention each arb has access to OS/CU, and (notwithstanding ARBCOND) they can't/shouldn't really be the final community port of review of their own OS/CU actions, which leaves the Ombuds. ProcrastinatingReader (talk) 16:46, 3 August 2020 (UTC)
• (edit conflict) Support. The requirement to recuse oneself notwithstanding, being on the body that is also tasked with overseeing ArbCom is imho not compatible with being an ArbCom member. We want OmbCom to be as effective as possible and that cannot be achieved if one or more of its members have to regularly recuse themselves from any cases regarding ArbCom. It also does not seem fair to the other members of OmbCom who will have to do more work in those cases because the recused members can't participate. Last but not least, requiring people to choose one or the other ensures more individual editors are involved and decreases the risk that people might think that an OmbCom member is trying to influence their proceedings in favor of their ArbCom colleagues. Regards SoWhy 16:53, 3 August 2020 (UTC)
• Support as a reasonable proposal per Beeblebrox. ~ ToBeFree (talk) 17:46, 3 August 2020 (UTC)
• Support - clearly a conflict as presented by SoWhy. Atsme Talk 📧 20:33, 3 August 2020 (UTC)
• Support per TonyBallioni and SoWhy. OhKayeSierra (talk) 21:17, 3 August 2020 (UTC)
• Support don't appoint people to watch over themselves, end of. (t · c) buidhe 21:22, 3 August 2020 (UTC)
• Support Just makes sense. --SarekOfVulcan (talk) 01:13, 4 August 2020 (UTC)
• Support per Beeblebrox and ProcrastinatingReader. Best, Barkeep49 (talk) 03:29, 4 August 2020 (UTC)
• Support per SoWhy. -- Euryalus (talk)
• Support - sensible separation of duties. Ivanvector (Talk/Edits) 14:21, 4 August 2020 (UTC)
• Support Seems to me an ombudsman role should hold ARBCOM responsible. We have other editors from whom to pick, folks. 16:09, 4 August 2020 (UTC)
• Support per SoWhy & Ivanvector. 0qd (talk) 23:59, 4 August 2020 (UTC)
• Support - summed up well by SoWhy and nom Cas Liber (talk · contribs) 03:28, 5 August 2020 (UTC)
• Support obvious conflict of interest. LEPRICAVARK (talk) 03:06, 6 August 2020 (UTC)
• Support - AGK resigned from ArbCom when he was appointed to the OC, which I think was the right move. I did the same with my steward rights. I think it makes sense to avoid holding multiple oversight functions, particularly when one is at a higher level of appeal. -- Ajraddatz (talk) 15:31, 6 August 2020 (UTC)
• Support per SoWhy. —Mdaniels5757 (talk) 20:17, 6 August 2020 (UTC)
• Support unlike the case review proposal, this makes much more sense. The overlap is greater (indeed, it's actually targeted, whereas the CR people aren't overseeing ARBCOM) Nosebagbear (talk) 13:30, 7 August 2020 (UTC)

Oppose (Arbs and Ombuds)

• Meh meta:Ombuds commission says As a general guideline, it is best that ombuds avoid conflicts of interest as much as possible, particularly by avoiding routine use of CheckUser or oversight access and not processing complaints on the projects on which they are very active editors. To me, that would mean that Ombuds-arbs would only have to recuse from cases involving (ab)use of CU/OS tools. I don't see any problem with Arb-buds telling people to stop edit warring over tree shaping or whatever. Arbitrators often have wide experience with CU/OS tools and how they're supposed to be used, so I think their input on Ombudscom is useful, and we shouldn't discourage it. It's also my understanding that the ombuds don't actually do that much. --AntiCompositeNumber (talk) 16:38, 3 August 2020 (UTC)
• Oppose All of us would need to recuse from all EN Wikipedia-related business anyways, so this is based on a flawed sense of how the OC works --Guerillero | Parlez Moi 19:44, 4 August 2020 (UTC)
• Oppose per Guerillero - enwiki is not the only wiki so there is likely enough work to do with handling complaints from other wikis. I don't think this is a wise decision because of the workload of the combined committees - but not something for us to legislate from enwiki. We also risk going into WP:CREEP territory here - should we make a policy saying that current arbitrators cannot be stewards? enwiki crats? etc. --Rschen7754 02:42, 5 August 2020 (UTC)
The key difference in my mind is that we can see what stewards and crats are doing. We have no way of knowing what ombuds are doing. Beeblebrox (talk) 04:41, 5 August 2020 (UTC)
I also think a sitting arb wouldn’t pass a steward election even if they wanted to run. Both from the anti-en.wiki crowd and by en.wiki people who don’t like the idea of someone being both. That’d get you to 79.9% or less pretty fast. I know that’s not the same as a policy against it, but it’d be very hard to overcome. TonyBallioni (talk) 04:45, 5 August 2020 (UTC)
I'm not so sure about this for stewards - a global lock of an account with a fairly bland summary might not be noticed, and CU/OS actions are generally not visible. They also have a private mailing list (where there are discussions on borderline cases) and escalation route to WMF. --Rschen7754 06:18, 5 August 2020 (UTC)
• Oppose per my opinion above. Ruslik_Zero 20:37, 5 August 2020 (UTC)

General discussion of multiple roles for arbitrators

Just a general note that there was some internal discussion among the committee members regarding this, and the consensus was that it would be best if the community decided this issue. If these proposals pass, they could be implemented by adding a few lines at Wikipedia:Arbitration Committee/Procedures describing the new restrictions. Beeblebrox (talk) 16:23, 3 August 2020 (UTC)

Umm... Wouldn't this constitute an amendment to ArbCom policy which would require majority endorsement by the committee, majority support with at least 100 editors participating, and exactly one partridge in a pear tree? GMGtalk 16:37, 3 August 2020 (UTC)
I think if we do it through procedures instead it doesn't have to go through all that. That's my read anyway. Beeblebrox (talk) 16:41, 3 August 2020 (UTC)
Selection and recusal are ARBPOL. Procedures are only changed by committee majority anyway, not community consensus. --AntiCompositeNumber (talk) 16:43, 3 August 2020 (UTC)
I think you only need a committee majority or community majority with 100+ supports. And 12 partridges in 1 pear tree. --AntiCompositeNumber (talk) 16:42, 3 August 2020 (UTC)
Yeah, doing this as an amendedment to ARBPOL via the 100 support method is probably best. Beeblebrox, do you have an objection if I change the votes to numbers instead of billets? TonyBallioni (talk) 16:45, 3 August 2020 (UTC)
Could we not just yet? I really didn't set it up that way, maybe we take the temperature here, and if it seems like it has a reasonable chance of passing through that rather arduous process, then we go that route, probably with a dedicated subpage. Not much here gets 100 votes, up or down. We'd probably need a sitenotice in addition to using CENT. Beeblebrox (talk) 18:15, 3 August 2020 (UTC)
The committee is free to make up whatever procedures it wants, including limiting committee members from assuming other roles, but then of course it can rescind them whenever it wants, too. isaacl (talk) 19:40, 3 August 2020 (UTC)
That's more or less why I went this route and not the full policy amendment route, which is far more involved. There was some talk of just doing this ourselves but in the end more arbs were in favor of soliciting community input first. Beeblebrox (talk) 00:25, 4 August 2020 (UTC)
Comes down to whether or not the community is willing to leave the documentation of the restriction to the discretion of the committee. In both cases, as long as the Wikimedia Foundation knows and respects community consensus, then the Arbitration policy is moot, anyway. We should ensure that the Wikimedia Foundation is aware of any agreed-upon restrictions and that it is documented in their procedures in an appropriate location. isaacl (talk) 20:21, 4 August 2020 (UTC)

I don't understand why this is a question for EN wiki. Shouldn't the prohibition (or not) apply to all Wikipedias? Otherwise we get a situation where EN arbcom members cannot be on the committe but members of a different language arbcon can be? Please clarify. RudolfRed (talk) 23:04, 3 August 2020 (UTC)

forgot to ping proposer RudolfRed (talk) 23:05, 3 August 2020 (UTC)
The short answer is that each project makes its own rules. Beeblebrox (talk) 00:22, 4 August 2020 (UTC)
(And most projects don't have ArbComs. GMGtalk 14:19, 4 August 2020 (UTC))

Update on Status Labs from Foundation Legal Team

RoySmith (talkcontribs) 15:03, 5 August 2020 (UTC)

What is the current status of moving Wikipedia to CC BY-SA 4.0?

Hi all

I'm trying to find where Wikipedia (not sure if this would be different for different language version) is with moving from CC BY-SA 3.0 to 4.0. I remember a few years ago the WMF board agreed or decided (I'm struggling to remember the details and cannot find anything written) that Wikipedia should move to the new license, but that there were legal issues to work out. Does anyone know:

• What stage the process is at, if there is a page describing it or a Phabricator ticket or something
• Where the board agreement might be
• Any other relevant info

I'm really interested in this because there a re large number of organisations publishing text under the 4.0 license which currently cannot be used on Wikipedia.

Thanks very much

John Cummings (talk) 15:12, 6 August 2020 (UTC)

John Cummings, There was a community consultation on a proposed TOU ammedment at meta:Terms of use/Creative Commons 4.0. The board was updated a few days after the discussion closed, but I could find no further developments. JSutherland (WMF), you were involved in that process; did anything happen after the 2016 discussion? --AntiCompositeNumber (talk) 17:20, 6 August 2020 (UTC)
thanks very much for the info. is there a phabricator ticket or something that explains the progress? John Cummings (talk) 08:39, 7 August 2020 (UTC)
John Cummings, for those of us not in the loop, what are the pertinent differences between 3.0 and 4.0? {{u|Sdkb}}talk 06:35, 7 August 2020 (UTC)
https://creativecommons.org/version4/#:~:text=Version%203.0%20included%20a%20provision,verbatim%20reproductions%20of%20a%20work John Cummings (talk) 08:39, 7 August 2020 (UTC)
The most important "change" is that CC BY-SA licenses only allow distribution under the current or newer license. So, 3.0 material can be imported to a 4.0 work, but 4.0 material can not be imported to a 3.0 work (which is the current unfortunate situation alluded to in the opening post). (talkcontribs) 12:26, 7 August 2020 (UTC)