Wikipedia:Village pump (policy): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 01:47, 26 May 2020

Table of contents
First discussion
End of page
New post

Shortcuts

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.

« Archives, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192

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)[reply]

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:

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.
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).
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)
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).

Opinion poll: Locality categorization by historical subdivisions

Please place your !vote here.

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Country and first level division (governorate, state, province, etc). – Sabbatino (talk) 13:05, 24 February 2020 (UTC)[reply]

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)[reply]

@Laurel Lodged: 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)[reply]

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)[reply]

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)[reply]

No Change in View Based on the limitation of scope to the discussion. RevelationDirect (talk) 19:24, 22 February 2020 (UTC)[reply]
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)[reply]
- 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)[reply]
  - 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)[reply]
    - ...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)[reply]
      - @WhatamIdoing:: 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)[reply]
        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)[reply]
        @WhatamIdoing:: The main point is that we're not here to offer that kind of assistance. Dahn (talk) 05:33, 2 March 2020 (UTC)[reply]
        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)[reply]
        @WhatamIdoing: 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)[reply]
        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)[reply]
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)[reply]
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)[reply]
- @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)[reply]
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)[reply]
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)[reply]
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)[reply]
- 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)[reply]
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)[reply]
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)[reply]
Unarchived to request closure at WP:ANRFC. Cunard (talk) 00:58, 5 April 2020 (UTC)[reply]

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

RfC: proposed creation of new usergroup

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

This proposal is unsuccessful. Many editors acknowledged there were legitimate issues that motivated this proposal, including lengthy delays associated with updating and correcting errors on the Main Page. However, there were also a variety of objections. Many editors rejected the idea of giving users full access to the editprotected and protect toolsets without full permission to use them, arguing that it would pose an unacceptable risk to give users more techncial ability than they are trusted to handle. Some editors also believed that such a system would be unnecessarily complex and may lead to "instruction creep", and others voiced security concerns, particularly with respect to increasing the attack vector for account compromises. Additionally, even if it were technically possible to unbundle only the ability to edit the Main Page, there were also editors who argued that, because of the critical importance and high visibility of the Main Page, the ability to edit it should also be limited only to administrators. Respectfully, Mz7 (talk) 07:33, 24 May 2020 (UTC)[reply]

This is a proposal to create a new usergroup, main page editor, as documented at Wikipedia:Main page editor. In brief, members of the new usergroup will be given the editprotected and protect user rights, which allows editors to edit pages transcluded onto the main page through full and cascading protection. This will allow editors with this permission to update content on the main page, and to fix errors on it. Details of the proposed mechanisms to grant and remove the right, and restrictions on its use, are at Wikipedia:Main page editor. If this request is successful, a phabricator request will be initiated, and once completed, Wikipedia:Main page editor will be changed from a proposal to a policy page and appropriately updated.

Note: if phab:T71607 is ever actioned, the protect userright would be replaced with editcascadeprotected.

Vanamonde (Talk) 20:26, 23 April 2020 (UTC)[reply]

Rationale

Wikipedia frequently has a shortage of administrators willing and able to perform tasks related to main page content. This results in updates to the main page being delayed, or in errors on the main page persisting for long periods of time.
A number of non-admin editors have long track records working on content related to the main page. These editors often are experts in project policy, are trusted contributors, and are fully capable of performing administrative tasks related to the main page, but are unable to do so, because editing the main page (and the subpages transcluded onto it) requires administrator permissions. Many of these users are uninterested in running for adminship because they would not use other tools. Many others do not have the wide experience necessary to pass an RFA.
Therefore, allowing trusted, experienced, willing non-admins to hold the rights associated with the new "main page editor" user group would increase the number of editors committed to main page projects who are able to perform these tasks, and also decrease the workload of admins. Updates to the main page can be made in a more timely fashion and errors corrected more quickly.

Technical background

The main page is currently full-protected with cascade protection. This is unlikely to change anytime soon. The various sections of it are transcluded onto the main page, and are therefore also cascade protected. The ability to edit cascade-protected pages requires "protect" permissions due to the current software design. Editing these sub-pages therefore requires the edit-protected and protect permissions, which are currently only locally available to admins. While it is technically possible to split the edit-cascade-protect and protect flags, efforts to do so have been pending developers since 2017.

Addressing potential concerns

Risk to other protected pages. Although users in this group will have the technical ability to protect and unprotect pages, this proposed policy explicitly states that they may not do so, and that using their rights to modify protection levels would be grounds for removal from the group.
Risk to the main page. This right will only be open to editors with a proven track record at the main page, who have proven their commitment to the project and their understanding of policy there. Even if someone should go off the rails or have an account compromised, the main page has over 114,000 watchers, over 4000 of whom have visited recent edits, and the proposal allows for requested revocation by any user in good standing and emergency revocation by any admin. Editors who disrupt the main page are likely to be brought to administrator attention very quickly. Additional risk to the main page is therefore minimal.
Potential difficulty of revocation. Under this proposal, any user in good standing can request revocation of membership in this usergroup from any other user, and administrators may revoke it without prior notice in case of active disruption to the main page. Furthermore, the process for removal intentionally does not require a numerical threshold, but a consensus that the editor in question will not abuse the right; therefore, in the presence of substantive concerns, the removal of membership should be straightforward.

Vanamonde (Talk) 20:26, 23 April 2020 (UTC)[reply]

Survey (proposed creation of new usergroup)

Support, as one of the drafters. Calls for assistance with the main page are frequent, and there are rarely enough admins on hand to address them. Vanamonde (Talk) 20:26, 23 April 2020 (UTC)[reply]
Pinging those users either involved with drafting this, or whose opinions were solicited during workshopping as experienced editors working with the various main page sections, or who came to the page to opine from other venues. I will also post notifications to the discussion pages for the various main page section.@Valereee, Xaosflux, Maile66, Dank, David Levy, Mike Christie, DannyS712, Xeno, Wugapodes, Winged Blades of Godric, MGChecker, Jo-Jo Eumerus, Coffeeandcrumbs, Cwmhiraeth, Mandarax, Tryptofish, BlueMoonset, Yoninah, Amakuru, Gatoclass, Casliber, Sca, Masem, MSGJ, Stephen, Killiondude, Jayron32, and Hut 8.5:; @Bagumba, Kees08, Art LaPella, Floquenbeam, Howcheng, Khajidha, Gerda Arendt, Ravenpuff, Serial Number 54129, Alanscottwalker, Ritchie333, Davey2116, 331dot, Zanhe, LaserLegs, Banedon, Nixinova, Martinevans123, Ad Orientem, SoWhy, Shubinator, Modest Genius, Pawnkingthree, Pawnkingthree, Kusma, WaltCip, and Gog the Mild: Vanamonde (Talk) 20:26, 23 April 2020 (UTC)[reply]
- Vanamonde93, assuming the referenced phab ticket isn’t actioned, would this allow people to edit full protected pages in mainspace from a purely technical point of view? TonyBallioni (talk) 20:36, 23 April 2020 (UTC)[reply]
  - @TonyBallioni: Technically, yes. Policy-wise, using that right for anything other than what it's meant for would be grounds for revocation. Vanamonde (Talk) 20:46, 23 April 2020 (UTC)[reply]
Oppose Groups that have far greater technical permissions than social permissions are a bad idea. * Pppery * _{it has begun...} 20:50, 23 April 2020 (UTC)[reply]
@Pppery: Please explain. Chris Troutman (talk) 22:51, 24 April 2020 (UTC)[reply]
I don't think this really needs much explanation, given that so many other users have opposed, but I'll answer anyway: I've seen several times that the social permissions of a group tend to drift to match their technical permissions. Here's one example, I view the problem as more widespread. * Pppery * _{it has begun...} 23:02, 24 April 2020 (UTC)[reply]
Oppose sorry to do this, but this would defeat the entire point of full protection existing. The reason this proposal always fails is that the unbundling of full protection is a bad idea because it enables people who care a lot about content and are extremely unlikely to be blocked for edit warring to edit through full protection. Unbundled permissions are extremely difficult to remove, probably harder than desysoping, and if there is abuse I don’t have confidence it will be removed and not restored, especially because of how small the number of people who work in this area are. If someone is trusted enough to edit through full protection on the main page, they should be trusted enough to pass RfA. We’ve had people in the last year pass with this as a rationale, so I see that as a valid avenue that would be preferred. TonyBallioni (talk) 21:11, 23 April 2020 (UTC)[reply]
@TonyBallioni: You don't really have to apologize; as I see it this is the best way to deal with the chronic delays at ERRORS, ITN, DYK, etc; if the community doesn't want it, I'm satisfied in the knowledge that I've done my best to fix the problem. But FWWI: I agree that editors who could be trusted with this permission generally ought to be admins. The trouble is they don't want to.. You're more than welcome to try to persuade them, but I doubt very much that you'd be successful. Vanamonde (Talk) 21:23, 23 April 2020 (UTC)[reply]
Weakly oppose. Per my comments below I can see the justification for this proposal, but I think it will create more problems than it solves. The difficulty in getting changes made to the main page is a feature, not a bug. Most editors don't particularly care about the main page, so the sort of people who are likely to want to apply for this are going to be either self-taught grammar pedants demanding that Wikipedia apply some rule they're misremembering from school, the more disruptive elements from DYK upset that those pesky admins slow things down by fact-checking their errors before we let the queues go live, and nationalists on a crusade to "correct the bias" at ITN. These are exactly the people we don't want having the ability to edit through protection. As per Izno and TonyBallioni, the ability to edit a page that averages 10 million readers per day isn't a relatively trivial feature like rollback but one of the most sensitive tasks on the entire project, and while I do support the principle of unbundling this is one of the jobs which should be left to admins. (I would actually be much more likely to support the unbundling of protect and editprotected if we excluded the main page from it.) ‑ Iridescent 21:37, 23 April 2020 (UTC)[reply]
Strong support It fills a very clear need and will help reduce serious backlogs. The main bottleneck at WP:DYK is moving preps (unprotected) to queues (full and cascade protected). At WP:ITN this permission would increase the number of regulars who can action discussions. The downside is we have to trust the granted editors not to do prohibited things. This should not be a big barrier because we do this all the time with user groups. We already have to trust that extendedmovers will not use suppressredirect contrary to deletion policy; we already trust that templateeditors will not be reckless in editing high-risk templates; we already trust that editors will act in good faith and not vandalize. Like many other parts of this encyclopedia, this proposal relies on meatball:SoftSecurity, and so we should evaluate whether the criteria can meatball:LimitDamage effectively. I believe it will. The criteria for granting are appropriately strict, requiring a request and consensus (and importantly not at admin discretion). The criteria for revoking are appropriately lax, requiring a single unauthorized act or community consensus. The prohibitions on use are bright lines, making ambiguous cases resulting in an untrustworthy person retaining the right unlikely.
The checks and balances of the proposal are well constructed to make this a clear net positive on its own merits, but if it goes well, it creates the possibility for further improvements in other areas of policy. For example, template protection was created as an alternative to full protection for high risk templates. It is in the projects interest to have technically capable editors able to edit high-risk templates, but the proliferation of protection levels has been a consistent problem. If this proposal is enacted and goes well, it presents the opportunity to consider consolidating our protection schema by extending editprotected to template editors and thus eliminating the need for template protection. Another example is that it may help recruiters identify more strong RFA candidates and resolve the low number of admin recruits while simultaneously reducing the demand for admins in certain areas. It tackles the problem from both sides. The proposal would be a big change, and big changes are scary, but they also create opportunities for us to reconsider long-held assumptions and catalyse improvements elsewhere. On its own merits, it is a solid proposal, and it brings with it the possibility for future improvements in other areas. For me, that is the hallmark of a good idea, and so I support the proposal as a net positive. — Wug·a·po·des 21:45, 23 April 2020 (UTC)[reply]
Oppose any regular at ITN who wants to be an admin can simply apply, and except for the occasional RD that dies on the vine that section doesn't have a backlog to contend with. No comment on DYK I have no idea how that section works. --LaserLegs (talk) 22:25, 23 April 2020 (UTC)[reply]
Weak oppose as I'd rather see this get fixed with phab:T71607 - and then we can have a group that is allowed to edit protected pages. — xaosflux ^Talk 22:36, 23 April 2020 (UTC)[reply]
To expand on this, I'm not opposed to creating a group that has the ability to edit protected pages, without being able to actually manage the protection; but with cascading protection this isn't currently possible. I'm not very worried about someone with such a new group being able to "protect" something be nature of transcluding it on a page with cascade - and this would be more of a positive than a risk I would think -- as inappropriate use could swiftly lead to access removal. — xaosflux ^Talk 16:13, 24 April 2020 (UTC)[reply]
Weak Support: Full protection is "sysop protection". This is counter-intuitive. The only solution I see to the counter-intuitiveness is to create a new protection level designated for main page and this purpose. {{replyto}} Can I Log In's (talk) page 00:17, 24 April 2020 (UTC)[reply]
Oppose I generally don't think we need more usergroups, and in particular, if we want to "unbundle" protection from sysop, I don't think this is the right way to do it. (And I don't think we should do it at all.) ST47 (talk) 00:59, 24 April 2020 (UTC)[reply]
Oppose per WP:CREEP as this would be additional complexity. As the issue is particular to the main page, it would be more sensible to try adjusting the protection level for that page, such as reducing the protection level to ECP with pending changes. Those are existing features and so no development would be required. Andrew🐉(talk) 10:27, 24 April 2020 (UTC)[reply]
Oppose - I am extremely uncomfortable with any change which includes phrasing to the effect of "this will let you do (X) but we're telling you not to do it" - as Pppery mentioned above, that's a social control on a technical capability. creffett (talk) 12:34, 24 April 2020 (UTC)[reply]
Additionally: I'm also very uncomfortable that this would give users in the "main page editors" group the ability to edit any fully-protected page. Again, a case of "you can do it but we're telling you not to" - goes against the principle of least privilege (thanks for linking that below, Pppery, I couldn't remember the name) as a privilege that is way too broad compared to the small task it's needed for. creffett (talk) 23:20, 24 April 2020 (UTC)[reply]
Support as one of the drafters. There are multiple workers at main page who don't want to be admins, they just want to help. —valereee (talk) 13:41, 24 April 2020 (UTC)[reply]
Oppose. It's not supposed to be easy to edit through full protection. Also, people will regularly cite WP:IAR to violate the policy. NinjaRobotPirate (talk) 13:53, 24 April 2020 (UTC)[reply]
Oppose primarily for two reasons: unbundling should be based on the technical right itself, ad-hoc rights will be very prone to misuse given that even technical permissions are abused for which a need was already established. By granting ad-hoc rights with "please don't do this attached" is almost a sure-shot way or shooting ourselves in the foot — especially because Main Page is the most important and public-facing page that we have. Compromised accounts frequently tend to have some kind of fascination with the Main Page and opening up more accounts to edit through full protection (who are only supposed to edit the Main Page) is an inherent security risk. --qedk (t 愛 c) 17:11, 24 April 2020 (UTC)[reply]
Oppose – this is a problem specific to DYK and ERRORS. As for ERRORS, clearly proposed and non-contentious changes tend to get acted on quickly. I have seen some suggestions get ignored if the change is not clearly necessary and if the proposer has a reputation for being argumentative and unwilling to compromise (this is not meant to say that you fit in this group if you have ever had this happen). Iridescent summarizes this concern better than I did. DYK does have a problem where there is not enough admin time available to meet the admin demand. I think there are better solutions than throwing more people at the issue, such as reducing the number of approved hooks in some way (disallowing GA entries, increasing minimum size, increasing minimum expansion, a 'selection pool' with more hooks in the pool than will be selected so the least interesting get dropped off after X period of time), reducing what we expect of admins when moving to queue (if another check is still desired, a second approver can be added to the prep process; better tools; better instructions), and improving the workflow (dynamic preps/queues so we can get further than 6 days ahead). While many of those possible solutions will have opposition to them, I firmly believe that the DYK process needs a large overhaul and not a bandaid solution. I understand not wanting to do an RfA, but if you cannot handle the stresses/criticism of an RfA, I am not sure you would be able to handle the stresses/criticism that come with main page work. At least in my experience, the latter is much more stressful. I would consider this proposal if other solutions to solve the issues at DYK are attempted. Kees08 (Talk) 17:16, 24 April 2020 (UTC)[reply]

You bring up a good point about WP:ERRORS. Not all of them are exactly errors, but sometimes style, sometimes MOS:ENGVAR, or a suggested rewriting of the hook itself. And at times ... and this has happened to me as an admin ... if you quickly correct what has shown up on WP:ERRORS, someone else posts with an opposing opinion of whether or not the change should have been made. — Maile (talk) 18:21, 24 April 2020 (UTC)[reply]

Support There are frequent backlogs at ITN and DYK, and a number of experienced editors at both projects who would be unlikely or unwilling to become admins, but nevertheless could be trusted with these limited responsibilities.-- P-K3 (talk) 17:58, 24 April 2020 (UTC)[reply]
Oppose Per QEDK; risk of compromises to other pages outweighs the benefits IMO. We need more admins to assist with main page items, but I don't think the level of trust required to give people these technical abilities is less than the trust needed to become an admin. Spencer^T•C 20:04, 24 April 2020 (UTC)[reply]
Support Un-bundling is always a good idea. Adminship is the ban-hammer and hence RfA is very political. Gnomish editors working Main Page to have this need for tools but might not be well-rounded enough to please the folks at RfA. I can see why some admins don't want to lose the power of full protect that they currently enjoy but that's the price for not working the backlog fast enough. Chris Troutman (talk) 22:49, 24 April 2020 (UTC)[reply]
I ran for RfA specifically stating that I intended to help with the DYK admin work, duties which people are now complaining that there are not enough admins to perform. That argument was rejected by the RfA, as is what you are saying, and using an unbundled bit would be prohibited as doing an end run around RfA. RfA is political and I was nor rejected for not being well rounded. Hawkeye7 (discuss) 23:36, 24 April 2020 (UTC)[reply]

With respect, Hawkeye, anyone can look at the opposition in your RfAs and see they failed because of concerns about your behavior. It's disingenuous to say the community rejected your request to help at DYK as invalid. ~Swarm~ ^{sting} 04:41, 25 April 2020 (UTC)[reply]

Support – In the past few months, especially on the weekends, the main page has come to down to minutes away from a complete disaster. Situations in which there have been many experienced non-admins that know how to solve the problem and none of the available admins know how. There are also instances in which an admin makes an error that leaves the main page at risk of serious vandalism for several minutes because of an admin's action and I have avoided reporting to ERRORS for fear of exposing the vulnerability. (Note that the ITN image right now is not at WP:CMP, which means that for up to 10 minutes it was open for vandalism.) These are the minuscule things that most admins do not understand but experienced main page contributors do. --- C&C (Coffeeandcrumbs) 23:23, 24 April 2020 (UTC)[reply]
Weak oppose While I respectfully disagree with Iridescent's concerns and Kees08's seconding thereof, I don't think the possible technical hurdles counteract the benefits, nor is this a particularly needed unbundling. – John M Wolfson (talk • contribs) 00:21, 25 April 2020 (UTC)[reply]
Oppose: When I read the title, I thought this is about reducing the security risk of >1000 administrators having the unused but dangerous permission to edit the most frequently visited page on one of the most frequently visited websites in the world. On the contrary, the proposal is about increasing the risk. Never. ~ ToBeFree (talk) 00:49, 25 April 2020 (UTC)[reply]
Support, in principle. The Main Page does not have enough contributors with the knowhow, and the requirements for adminship are too high and broad. But we shouldn't give the new group the permission to protect pages, or to edit fully-protected pages; rather, we should create a new cascade-like protection level specifically for the Main Page and its subpages, perhaps bearing a light yellowish-orange color. The end result would be a user group similar to the template editor permission, who edit high-risk templates like {{Infobox}} that likely receive just as much exposure, if not more, than the Main Page. –LaundryPizza03 (d c̄) 03:03, 25 April 2020 (UTC)[reply]
Oppose - I'm a generally a big proponent of creating more extended privileges, but not in this case. Unacceptable risk vs reward. We're talking about the front page of one of the largest and most important websites of all time. It could be argued that the ability to edit the main page is the most importantly-restricted privilege an admin has. If the community cannot deem someone trustworthy enough to pass RfA they should sure as hell not be able to edit the main page. Secondly, I don't see the need. I monitor ERRORS, it has ample participation and is never backlogged. I haven't worked at ITN/C in many years, but looking at it now, it still has ample participation and no backlog issues. ~Swarm~ ^{sting} 04:35, 25 April 2020 (UTC)[reply]
I think the problem is not that users run RFA and fail, the problem is that they refuse to run RFA.--Ymblanter (talk) 17:26, 25 April 2020 (UTC)[reply]

You won't find anyone who acknowledges this more than me; I once led an RfA reform project. However, even given the flaws of RfA that dissuades participation, I entirely reject the notion that editors wishing to modify the main page should be subjected to anything less than the standard community confirmation process for administrator permissions. I would sooner advocate for unbundling the block tool. ~Swarm~ ^{sting} 04:51, 28 April 2020 (UTC)[reply]

Weak Support for the reasons described by Coffeeandcrumbs and the nom. That said, I'm observant of the concerns raised by Swarm. Chetsford (talk) 05:07, 25 April 2020 (UTC)[reply]
Oppose there are no ‘chronic' delays at ITN or Errors for unambiguous errors. We don’t need more people rushing in and fixing more nuanced issues that warrant extended discussions. Step hen 09:18, 25 April 2020 (UTC)[reply]
Oppose per the above arguments of this increasing the risk for vandalism of probably one of the most-visited pages on the Internet. SemiHypercube 19:18, 25 April 2020 (UTC)[reply]
Support. I'm someone who comments on a problem that I see on the Main Page maybe once or twice a month. There is often a delay of several hours before anyone acts on or responds to my comments, sometimes nobody responds, or only some other non-administrator adds an agreement. I don't mind too much, and perhaps sometimes my comment really is too trivial to bother with, but it is frustrating and does incline me not to bother next time. I know that one solution is to check a day in advance, which I do sometimes, but even then the problem may remain unaddressed until the page is live (particularly with POTD). There do seem to be other non-administrators around with the necessary skills and sense of balance who could solve this issue very well if they were given the tools. It wouldn't need that many more sets of eyes, perhaps 10 or 20, to make a huge difference. Jmchutchinson (talk) 21:35, 25 April 2020 (UTC)[reply]
Oppose primarily per TonyBallioni, xaosflux and Swarm. Callanecc (talk • contribs • logs) 06:24, 26 April 2020 (UTC)[reply]
Oppose It just adds another bureaucratic layer and duplicates what already exists. How do you find this small handful of GF main page nominees, who are going to stick around when the going gets rough, or until they just get bored? How many have run for admin only to eventually shift their efforts away from the reason they originally wanted the tools? People are people, and a new user right is not going to guarantee they would be more effective, or stick with it, any longer than the current admins. — Maile (talk) 14:19, 26 April 2020 (UTC)[reply]
Oppose: We already have a means of allowing users to edit the main page: RfA, where the community exercises its right to examine a candidate. I don't see a reason to change this. Sadly, if this proposal passes, it would just contribute to an ever-increasing bureaucratic bent on this site. — Javert2113 (Siarad.|¤) 18:02, 26 April 2020 (UTC)[reply]
Support: there are not enough eyes on the technical maintenance of the main page. While I believe ERRORS and co are often overzealous in their aim to interfere with content that has passed normal approval processes, and I understand the damage that edits with this right could do were they to act maliciously, I am much more worried by the realistic prospects of a DYK queue minutes away from being loaded onto the main page being empty, or an objective factual error being present on the main page for hours. With a community process required, and only trusted editors experienced in Main Page content standing a chance of passing it, I do not believe we have any non-trivial risk of a user misusing these permissions, which would be a bright-line situation that could be remedied as soon as anyone noticed it; rather, it is admins who abuse their protection privileges because they have much more subtle ways to do so. — Bilorv (talk) 20:32, 26 April 2020 (UTC)[reply]
Oppose I understand the reasons behind this proposal, however, the main page has hundreds of millions of views per month. The more accounts who can edit the main page only increases the risk that one (or many) of these accounts will be compromised and the main page then vandalised etc. As it has been said above, the main page is probably the most important page on this site. It is the primary gateway to any visitor who does not use a search engine to access Wikipedia, and is the page which probably most people looking to browse or visit for the first time go to. RfA is the best way we have to determine the trustworthiness of a user and whether they should be given advanced rights, including editing protected pages. Although editing fully protected pages is probably less of a big deal than the block button (for the purposes of editors), editing fully protected pages in my opinion is the right that a administrator has which would cause the most damage for the reader. A reader won't probably notice or care that they if they are blocked by a compromised account, but will most likely notice a vandalised main page. Therefore users who can edit the main page and transcluded subpages should be trusted by the community enough that they could become sysops. Therefore, I would argue, any process for granting this right should be similar to RfA as the community would want to trust the user as much as they would if they were going to support them for adminiship. So, having this user right seems a bit moot, as the user might as well go for RfA. Therefore I would argue that editing the main page and by extension editing fully protected pages is something which should remain only possible by sysops. Dreamy Jazz 🎷 ^{talk to me | my contributions} 21:02, 26 April 2020 (UTC)[reply]
Oppose per Tony and NJP - IMHO it'll create more problems than it solves and like NJP says someone somewhere will invoke IAR, If you want to edit the main page then start an RFA. –Davey2010^Talk 12:27, 27 April 2020 (UTC)[reply]
Strong opppose - while a good idea in principle, the implications make this a no-go. I'm fairly certain everyone else who has opposed has already hit on points I would have brought up, so I won't reinvent the wheel here - but in short, having non-administrators being able to edit the Main Page is a bad idea, as if that isn't bean bait I don't know what is. Kirbanzo ^{(userpage - talk - contribs)} 16:57, 27 April 2020 (UTC)[reply]
Support it's pretty obvious we have limited resources, more so these days than ever before, and in my mind there's a clear delineation in regular editors who would risk the integrity of the project and those who most certainly would not. I speak from personal experience as someone who has tried (and failed often) to keep the main page up to snuff, both as an admin and a regular editor. Some admins like the technical stuff, deletions, blocking etc. But many admins shy away from content related issues, and the main page is just where that kind of oversight is required. This proposal looks doomed to fail, but those opposing it perhaps aren't as acutely aware of the issues as some of the rest of us. I see no problems with this approach ... how many admins have gone rogue and deleted the main page? None. How many errors, poor links or unprotected redirects have been featured on the main page? Daily. A class of user between full admin and template editor is a no-brainer. It can be switched on and off at will by admins. If someone (like me, for example) can demonstrate a complete 100% dedication to the content aspects of Wikipedia yet still can't be trusted to fix chronic errors on the main page, the community has been corrupted. The Rambling Man (Stay indoors, stay safe!!!!) 21:55, 27 April 2020 (UTC)[reply]
how many admins have gone rogue and deleted the main page? One. —⁠烏⁠Γ ^(kaw) │ 04:40, 28 April 2020 (UTC)[reply]
more than 1... see [1] Mdaniels5757 (talk) 01:33, 2 May 2020 (UTC)[reply]
Support Per lots of wise people above. --Dweller (talk) Become old fashioned! 12:26, 28 April 2020 (UTC)[reply]
Oppose for as long as editprotected controls not only editing protected pages, but also creating salted articles and moving move protected titles. These need to be unbundled, and then we can create user groups for those who need only one of these privileges (anyone who needs 2 or more should go here instead). Iffy★Chat -- 12:56, 28 April 2020 (UTC)[reply]
Oppose for many of the reasons above, especially the technical overhead and instruction creep involved for such a niche set of tasks, and the lack of a rigorous vetting or oversight process for "unbundled" permissions like this. We have over a thousand administrators, and most admin processes are rarely backlogged. If DYK and ERRORS are experiencing problems, perhaps it's because there is something about those processes that put people off, rather than a lack of warm bodies with the right bits? – Joe (talk) 14:13, 28 April 2020 (UTC)[reply]
Oppose - While I might support editprotected as part of a user-right group of various other editing tools, after several community-wide discussions, I find I don't disagree with those who suggest that protect and block are intrinsically linked when it comes to handling disruption. This should not be split out as a separate user-right group. - jc37 06:42, 29 April 2020 (UTC)[reply]
Oppose per TonyBallioni, Iridescent and others. As an admin regularly involved with the main page myself, I do acknowledge the issues that the nomination here raises, and yes admins do have a lot of work to do and there are sometimes longish gaps between error reports and things being fixed. It's also true that there is a group of editors highly versed in main-page lore who regularly groom the queues and request changes at ERRORS - their work is highly valued. However I don't think the problem is a big enough one to warrant lowering the bar. This in turn means a much larger group involved with editing the main page, and would IMHO bring more problems than it solves. As Iri notes, keeping this group small avoids petty disputes and main page edit wars flaring up. The level of frivolous and POV edits would likely go up too. I've seen two main reasons why these editors don't go for RFA - one is that they don't want the additional workload and pressure, for example DYK prep builders who prefer to leave the queue promotion and checking to someone else; and the other reason is people who don't think they'd pass an RFA for one reason or another. The first group presumably don't need or want main page rights for precisely the reason they don't want adminship, while with the second group, unfortunately for me if someone wouldn't pass an RFA, then I don't personally think that person should be editing the main page. — Amakuru (talk) 09:17, 29 April 2020 (UTC)[reply]
Oppose per TonyBallioni and Iridescent.Pharaoh of the Wizards (talk) 08:30, 30 April 2020 (UTC)[reply]
Oppose, no evidence that this is an actual problem. Stifle (talk) 09:24, 30 April 2020 (UTC)[reply]
Oppose per pretty much all the opposes above. Unbundling is mostly a good thing, but it's not always a good thing, and it certainly isn't in this case. Editing the main page is definitely something that needs the two step process of proposal and review. Boing! said Zebedee (talk) 01:36, 2 May 2020 (UTC)[reply]
Strong Support mainly per Wugapodes; there are only two or three admins active at dyk to my knowledge -- as the most viewed page, we should have everything be up to date there. --Puddleglum ^2.0_{(How's my driving?)} 02:05, 2 May 2020 (UTC)[reply]
Oppose with regret, an obviously good faith proposal. I salute the many editors who worked on the idea, but there are just too many potential pitfalls here. Most have been covered by others but among those that stand out in my mind, are enlarging the pool of editors with the ability to edit one of the most trafficked pages in the world with inadequate vetting. It increases the potential for serious disruption to an unacceptable degree. I am also not wild about the idea of handing someone a very broad tool that would allow them to edit even fully protected pages in the mainspace and then saying "but you aren't allowed to do that." -Ad Orientem (talk) 02:06, 2 May 2020 (UTC)[reply]
Oppose someone trustworthy at this level (editing the main page) should have to pass RFA. Royal broil 03:25, 2 May 2020 (UTC)[reply]
Oppose per TonyBallioni and Royalbroil. I simply fail to see a need for this. Anarchyte (talk • work) 05:02, 2 May 2020 (UTC)[reply]
Oppose as unnecessary. Anyone I would trust with this I would also trust for admin, so they might as well be vetted properly and go for the whole toolset in order to be even more helpful without the risks. -- Tavix ^(talk) 05:17, 2 May 2020 (UTC)[reply]
Oppose. The main page is our face to the world. If there is one place editors should go through an RfA-type process before they're allowed to mess with it, this is it. As I understand this proposal, the procedure for obtaining this right is very lightweight, and therefore inadequate. It needs scrutiny by the community in depth before granting, and that's what you get at RfA. If RfA is a problem for this task, then it has wider problems as well and it's RfA that needs improving, not yet another unbundling of user rights. SpinningSpark 08:13, 2 May 2020 (UTC)[reply]
Oppose, per lots of wise people above, especially TonyBallioni, Iridescent, Swarm, and Boing! said Zebedee to name but a few. One of the reasons Vanamonde93 omits in their Many of these users are uninterested in running for adminship because they would not use other tools. Many others do not have the wide experience necessary to pass an RFA, is that a large number of trusted users of the right calibre won't come forward because they are not prepared to run the gauntlet of the RfA system that is partially run by users who are determined to maintain it as the one venue where they can be as abusive as they like with total impunity.This ad hominem at a respected and trusted group: it is admins who abuse their protection privileges because they have much more subtle ways to do so by Bilorv probably does not foster good spirit where Wikipedia's working environment is beginning to show noticeable cracks. Kudpung กุดผึ้ง (talk) 08:23, 2 May 2020 (UTC)[reply]
Support. There is a clearly stated and evidenced problem that needs fixing, and this proposal would fix it. I've read the oppose votes and of those that are not philosophical oppositions to unbundling (not something that is really related to this proposal) or based on problems with RFA (not really relevant) there are none that I've seen that would not be solved or prevented by just not giving this right to anyone who is not suitable for it. e.g. if you don't trust someone who requests this not to push their POV then simply oppose their getting the right. There is no reason why the requests need not be as thorough as RFA. Thryduulf (talk) 11:40, 2 May 2020 (UTC)[reply]
Oppose, everybody who is trustworthy enough to edit the Main Page is trustworthy enough to be a sysop. Alternatively, automatically promote all Main Page editors to sysop if they have kept the right for a month. —Kusma (t·c) 11:52, 2 May 2020 (UTC)[reply]
Oppose. I understand the perceived need behind this proposal but I agree that it would probably create more problems than it solves. Granting such a right to essentially be able to deface the Main Page should require a discussion whether the editor is trustworthy enough but then why not have them run for RFA instead? The only area where I can see a reason to have non-admins be able to influence the main page is DYK but for that area, there is a more practical solution (which I had previously suggested) by having a queue that non-admins can edit ("emergency queue") but which the DYK Updater bot will only process if it detects the signature of someone on its allowed-list in the {{DYKbotdo}} template. It's a far easier solution than creating a new userright and a potential process to grant it. Regards So Why 15:58, 2 May 2020 (UTC)[reply]
Oppose To echo many of the comments above, the benefit is not worth the risk. To echo many of the other comments above, I'm not convinced that there's a benefit to begin with. The Squirrel Conspiracy (talk) 00:36, 5 May 2020 (UTC)[reply]
Oppose I do not feel that there is a great need for this right. The English Wikipedia has 1,140 Administrators at this time and one of the main responsibilities of a sysop is to protect pages. As many users above have said, the benefit is not worth the risk. -Examknow ^talk 21:22, 8 May 2020 (UTC)[reply]
Oppose Just leave the task to the admins. While the user right seems reasonable, it may be prone to abuse. There are several places where other users may propose changes to the content of the templates that are transcluded in the Main Page. It is more important that concerns on such places are acted upon as soon as possible in order to avoid backlogs. LSGH (talk) (contributions) 17:26, 10 May 2020 (UTC)[reply]
Oppose per WP:CREEP. The solution to the "we don't have enough admins." problem, if there is such a problem, is obvious and is not this. UnitedStatesian (talk) 03:16, 16 May 2020 (UTC)[reply]
Oppose until there's a way to edit cascade protected pages without having the protect right. Such tool should only be restricted to admins who is trusted by the community. Don't have enough admins (despite having a thousand of them)? Recruit more! --Pandakekok9 (talk) 05:04, 17 May 2020 (UTC)[reply]

Discussion (proposed creation of new usergroup)

I can see the merits of this, but I'm highly sceptical of requirement 1g (Working to fix mistakes on the main page at WP:ERRORS) as one of the grounds for this being granted. While there are a lot of fine people there, WP:ERRORS has traditionally been one of the parts of Wikipedia most infested with POV-pushers, cranks and people obsessed with pushing some prescriptive form of grammar or other. (For decency's sake I won't name names, but anyone who's had the page watchlisted for any time will be aware of the issue.) I have a suspicion this is going to set up potential for a lot of bad feeling, as we either give out this new right to people who we know are likely to abuse it, or have a lot of awkward "thank you for your service but everyone thinks you're untrustworthy" conversations which in turn leads to resignations (or even grant-strip wheel-warring which will understandably upset the editor involved even more). Has any consideration been given to a more thorough process than "post at Wikipedia talk:Main page editor—a page which currently has only 22 watchers—and try to time it such that in 24 hours one of your friends will be watching and waiting to flip the bit?" We already have a perfectly good Wikipedia:Requests for permissions page which gets the eyes of considerably more neutral parties. ‑ Iridescent 20:43, 23 April 2020 (UTC)[reply]
@Iridescent: I agree with your first concern, but that is among the reasons there's a more elaborate process being proposed for granting and removal than a request at WP:PERM. And that's also a reason not to leave it to the discretion of a single admin who would have to make an awkward decision; concerns can be raised by anyone. Yes, WT:MPE has 22 watchers, but the process requires cross-notifications at noticeboards that between them probably have in excess of two thousand watchers. Vanamonde (Talk) 20:50, 23 April 2020 (UTC)[reply]
So, I understand your argument about people being reluctant to undergo RfA, but how is this much different? You’re advertising something for community comment and the people with enemies will have them show up just like at RfA. TonyBallioni (talk) 21:26, 23 April 2020 (UTC)[reply]
@TonyBallioni: Two reasons; first, RFA has a bad reputation, deserved or otherwise, that's somewhat unique; second, the skillset is much narrower, and main-page specialists don't have to worry about being questioned on their knowledge of deletion or blocking policies. Vanamonde (Talk) 21:37, 23 April 2020 (UTC)[reply]
Can we move everything to the template space and have template editors who would be able to edit it? — Preceding unsigned comment added by Ymblanter (talk • contribs)
@Ymblanter: Technically, I believe so. I don't know that that proposal has any greater chances of success than this one, because it would be assigning two very different functions to that usergroup and require downgrading protection on the main page. I would probably support such a proposal, but I am not willing to propose it myself. Vanamonde (Talk) 20:56, 23 April 2020 (UTC)[reply]
I tend toward "if we trust them enough to update the main page, we trust them enough to have the tools", especially if we're giving them protect/editprotected. --Izno (talk) 20:52, 23 April 2020 (UTC)[reply]
@Izno: we may trust (many of) them; but there's a lot of reluctance to enter the snake pit that is RFA. Vanamonde (Talk) 20:56, 23 April 2020 (UTC)[reply]
One of the issues with lack of admins is actually down to timezones. The majority of our admins are in North America, so when it is the early hours of the morning there, obviously fewer admins are available. It also doesn't help that these hours correspond to late morning/early afternoon in Europe (where we also have a number of admins), when a lot of people are at college or work (not so much at the moment, obviously). I suspect this would also be the case with the majority of anyone we recruited as MP editors, as well. Black Kite (talk) 21:37, 23 April 2020 (UTC)[reply]
When I ran for RfA, I pointed out that being in time zone kilo gave me an advantage. You didn't regard that as relevant then. Hawkeye7 (discuss) 23:41, 24 April 2020 (UTC)[reply]
While I can't speak for Black Kite, that seems a perfectly reasonable view. "It would be good if we have more admins the upper UTC+5 to 12 or so time zones" does not mean "I should consider someone's timezone in deciding whether I think someone should be an admin" since for many or most editors, it comes down to trust rather than whether the admin may do some useful admin work. I mean people may oppose an RfA if they feel the editor is unlikely to ever actually use the tools, or even if they will rarely use the tools. But it doesn't mean the fact someone is likely to regularly use the tools, or will help in areas currently underserved, will make up for a lack of trust. Or even that it will come into the equation at all. Note that I make no comment on your RfA, other than that having skimmed through it sometime in the past, and having read your comments here, I would suggest you're still a way from being ready for another one. Nil Einne (talk) 14:30, 25 April 2020 (UTC)[reply]
Sure, but if we were only talking about the front page update, would that alter the equation? Would such factors become more relevant? Hawkeye7 (discuss) 01:03, 26 April 2020 (UTC)[reply]
I was made an admin in 2006, stating that I planned to use it only for typos and such on the Main Page. I don't think such a person would pass RFA these days, so I don't assume that a good Main Page editor could pass RFA. Art LaPella (talk) 03:38, 24 April 2020 (UTC)[reply]
@Art LaPella: Wikipedia:Requests for adminship/Kees08 looks to me like a recent example of what you describe, and it passed fairly easily. Personally I would always support someone at RFA who isn't a jerk, is experienced with content, and has a demonstrated need for the tools. And I suspect most Wikipedians would be the same. — Amakuru (talk) 22:38, 29 April 2020 (UTC)[reply]
@Vanamonde93:, was consideration into a narrower set of authorised responsibilities considered - while they are fall into the same zone (so there's an immediate inclination to add all), there's two potential differences: some might be more (potentially) controversial, such as ERRORS, and others might be more unnecessary to expand the workforce (those not so dependent on 1 or 2 admins). My concerns on potential security issues (both wilful misuse and attack surface are separate) but I wanted to consider unnecessary risks of issues first. Nosebagbear (talk) 09:22, 24 April 2020 (UTC)[reply]
I'm not sure entirely what you're asking, Nosebagbear. Are you asking if the set of appropriate uses was intentionally narrow? Yes, it was. The point of this thing isn't to end-run around unbundling the protect tool. Vanamonde (Talk) 15:58, 24 April 2020 (UTC)[reply]
@Vanamonde93: - it was actually a query on whether an even narrower update was considered (Errors seems to have a bit of concern above, for example)? Nosebagbear (talk) 18:55, 24 April 2020 (UTC)[reply]
@Nosebagbear: We considered it; but speaking for myself I think the skillset we're discussing is either relevant to just one main page venue, or to all of them + errors; I don't see how someone can be trusted enough to deal with the DYK queues but not with error reports about DYK. So I don't see the benefit to removing ERRORS from the scope of the proposed usergroup. I also don't see that addressing the concerns of very many users, with the possible exception of Iridescent; most folks seem to be saying that the security risk is too high (which is reasonable, though I disagree) or that the people who could make use of this should run at RFA (which isn't, because most of them have refused repeatedly). Vanamonde (Talk) 00:34, 25 April 2020 (UTC)[reply]
If going through the relentless gauntlet of RFA is a precursor to doing substantive volunteer work of this sort on the project, then maybe I'm just not cut out to be a volunteer.--WaltCip (talk) 14:40, 24 April 2020 (UTC)[reply]
In theory, one could enforce the restriction "main page editors can't edit fully protected pages other than <whitelist>" using the edit filter, but I would oppose the proposal regardless because (a) this proposal necessarily gives them the right to protect pages as well, which I don't think can be stopped by the edit filter and (b) this is an ugly hack. * Pppery * _{it has begun...} 00:09, 25 April 2020 (UTC)[reply]

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

RfC: Bureaucrat activity

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

The result of this request for comment is no consensus. Supporters of this proposal argued that these were reasonable activity expectations for bureaucrats and that the current activity requirements are insufficient, noting the importance of having bureaucrats who remain in touch with the evolving Wikipedia community. A few editors also voiced security concerns—if a bureaucrat is inactive, they may not notice if their account is compromised. Opponents to the proposal argued that the proposed activity requirements were unnecessary, stating that there is insufficient evidence of bureaucrat inactivity leading to problematic decisions. Other concerns included the thought that this proposal may lead to ill-considered or rushed decisions for the purpose of fulfilling the activity requirements, particularly given the relative scarcity of matters requiring bureaucratic attention. Respectfully, Mz7 (talk) 06:43, 24 May 2020 (UTC)[reply]

Since there's a thread at BN about bureaucrat activity, and I've told people the way to solve the problem is by creating an RfC, I'll go ahead and start one. I'm proposing the activity policy for bureaucrats be updated to the following:

Bureaucrats who do not have qualifying bureaucrat activity within the last two years before will have the bureaucrat permissions removed for inactivity, and may only have the bureaucrat permission restored by a new successful request for bureaucratship. Users will be notified one month prior to removal of their permissions. Qualifying bureaucrat activity shall consist of the following:
Granting or removing permissions that can only be done by a bureaucrat

Closing of discussions that are restricted by policy to bureaucrats

Participation in bureaucrat discussions either as a part for requests for adminship or bureacratship or as a part of ordinary discussions at the bureaucrats' noticeboard.
Simply expressing willingness to participate as a bureaucrat without activity is not considered activity for the purposes of maintaining permissions. Bureaucrats who have their administrator permissions procedurally removed for inactivity will also have the bureaucrat permissions removed, but may request them back if they return to activity and would otherwise qualify as an active bureaucrat.

TonyBallioni (talk) 21:25, 24 April 2020 (UTC)[reply]

Support (Bureaucrat activity)

As proposer. The bureaucrat user group isn't one we have a particularly strong need for currently, and while I'm all for having people around who remember things from earlier in the projects years and can provide wisdom when they are needed, having them currently be active members of the project who are familiar with the wishes of the community in the area that they serve is important. So, I lowered this to two years because three years is excessive, got rid of the "I want it still" clause, and also removed renames as those are handled by global renamers now. We had a thread on the renamer portion at BN earlier and it was still considered activity, but I think opening that discussion for wider comment from the community is ideal, especially as any administrator can basically become a renamer on request at meta.
The idea here is that the community has expressed a desire for bureaucrats who are familiar with how Wikipedia currently operates in the areas they serve both by promoting more active users to the permission and by complaining about inactivity. Proposing this as a way of seeing if there is a consensus for that view and because it is a view I hold myself. TonyBallioni (talk) 21:25, 24 April 2020 (UTC)[reply]
Merely expressing a willingness to take part should not be enough in my view – it's the equivalent of archiving your talk page once a year to remain an administrator. Taking part in active discussions at BN, or a crat chat, at least every two years is not too arduous a step up. I agree that renaming is largely redundant now and should be removed.-- P-K3 (talk) 21:39, 24 April 2020 (UTC)[reply]
This is a reasonable modification. After an extended period of inactivity, people lose touch with the community, the ongoing issues, and awareness of important discussions. Schazjmd (talk) 21:45, 24 April 2020 (UTC)[reply]
As amended. If we truly end up in a situation where we have so many crats and so few RfAs that qualifying actions are rare, we can revisit the policy at that point. --AntiCompositeNumber (talk) 22:06, 24 April 2020 (UTC)[reply]
Support. We need a decent number of crats for the occasional crat chat, but it is important that those participants be active members of the community, so that their decisions better reflect consensus. ST47 (talk) 22:31, 24 April 2020 (UTC)[reply]
Support In any endeavor, a majority of the work will always be done by a small number of people; that's unchangeable. Raising the expected minimum activity, however, will help trim the fat. Why editors becoming inactive don't just resign the flag and pick it up later is proof of a hatshop mentality. Chris Troutman (talk) 22:41, 24 April 2020 (UTC
Ultimately I think crats should be reconfirmed every so often (every 1 - 4 years) rather than some bare bones activity policy. However this is better than what we had before so I'll support it. But I really do think reconfirmation should be where we head. Best, Barkeep49 (talk) 22:53, 24 April 2020 (UTC)[reply]
Please count me as opposed if in the view of the closer this edit would satisify the revised criteria. If that edit does then there's effectively no change to the criteria and this proposal fails WP:NOTBURO. Barkeep49 (talk) 00:16, 25 April 2020 (UTC)[reply]
Support - I like Barkeep49's idea above, but this is a good first step. creffett (talk) 23:11, 24 April 2020 (UTC)[reply]
Support Principle of least privilege * Pppery * _{it has begun...} 23:13, 24 April 2020 (UTC)[reply]
Support It is a bit silly that a bureaucrats could pop up now and again to keep the hat. How does that benefit the 'pedia? Natureium (talk) 23:24, 24 April 2020 (UTC)[reply]
Support as useful. Beyond My Ken (talk) 00:16, 25 April 2020 (UTC)[reply]
Support per above. imo two years is still too long, but this is absolutely a step in the right direction. -FASTILY 00:37, 25 April 2020 (UTC)[reply]
Support We don't need hangers-on in any role that requires advanced permissions. I don't wish to pick on anyone but the BN thread that prompted this discusion was of a use who had not actually used any of their advanced permissions in 12 years and barely edited in 8 years, having already lost adminship once for inactivity. You leave for that long, you're starting over, not returning to exactly where you were. Beeblebrox (talk) 00:53, 25 April 2020 (UTC)[reply]
Support per proposer ~ ToBeFree (talk) 00:55, 25 April 2020 (UTC)[reply]
Support - it makes sense to me. ^Atsme _Talk 📧 00:58, 25 April 2020 (UTC)[reply]
Agree these should be tighter, and these are quite reasonable to keeping the tools sharp. The one caveat I will add, though, is that technically (ever so slightly) there is a legacy consultation role for bureaucrats at WP:USURP; that does not appear to be covered by these criteria. Not to be taken as aimed at any one individual, who I hope can and will return to activity. ~ Amory (u • t • c) 01:01, 25 April 2020 (UTC)[reply]
Support If we do it for admins, then there is no reason not to do it for the next level up. The trouble is determining the right level of activity; I'd suggest 1 year since that matches the level for admins. –LaundryPizza03 (d c̄) 03:08, 25 April 2020 (UTC)[reply]
Support - This is still far too lax, but at least it's something. ~Swarm~ ^{sting} 04:08, 25 April 2020 (UTC)[reply]
Support per above.Pharaoh of the Wizards (talk) 04:46, 25 April 2020 (UTC)[reply]
Support per all the above. Lugnuts ^{Fire Walk with Me} 07:58, 25 April 2020 (UTC)[reply]
Support The nomination is sound. It's our usual policy for permissions, advanced or otherwise, to expire through under use, so this proposal merely brings cratship further inline with other permissions (Noting and agreeing with Swarm's point about incremental change.) Bbrox and Fastily also highlights important points. ——SN 54129 08:43, 25 April 2020 (UTC)[reply]
Support the amount of bureaucrat work is small but I think this is sufficiently generous. As with admins bureaucrats who aren't active are likely to fall out of step with changing standards. Hut 8.5 09:10, 25 April 2020 (UTC)[reply]
Support. These are not requirements that are excessively hard to fulfil but would allow the removal of crat permissions from editors who are not acting as a crat. Thryduulf (talk) 09:26, 25 April 2020 (UTC)[reply]
Support. Looks reasonable and very easy to meet – Ammarpad (talk) 09:35, 25 April 2020 (UTC)[reply]
Support with the proviso that this not be applied retroactively. That is, for currently inactive arbitrators the clock starts ticking from the moment this proposal passes, not from their last action. Reyk _YO! 09:33, 25 April 2020 (UTC)[reply]
Support - as per proposer, but it's also still far too lax. Kudpung กุดผึ้ง (talk) 10:38, 25 April 2020 (UTC)[reply]
Support. It can always be tightened further in the future, but we need a baseline and this proposal provides that. Britishfinance (talk) 13:47, 25 April 2020 (UTC)[reply]
Support. - Not all crats but some are IMHO hatcollecting which really does need to be stopped, I agree with Kudpung this is still too lax however this is by far better than what we currently have and am happy to support it. –Davey2010^Talk 13:51, 25 April 2020 (UTC)[reply]
Support I would prefer to see a term limit of ~5 years. Crats need to be in touch with the current expectations of the community. If a re-sysop request appears, the "under a cloud" perception changes from time to time, and it takes only one quick-draw crat to make an irreversible mistake. Crats are bound by policy, but also have the option to not act at all. I would prefer crats to be very active in the community. Rgrds. --Bison X (talk) 18:38, 25 April 2020 (UTC)[reply]
Support If the tools aren't used for a while, you probably don't need them. SemiHypercube 19:14, 25 April 2020 (UTC)[reply]
Support per proposer. Wikipedia is not a millinery supply store, and those who hold advanced permissions should use them or lose them. Boing! said Zebedee (talk) 20:27, 25 April 2020 (UTC)[reply]
Support any strengthening of the policy is an improvement, we need crats that are both active and aware of current community normals. Govindaharihari (talk) 14:16, 26 April 2020 (UTC)[reply]
Support Very reasonable and not over-onerous criteria for retention of role Kees08 (Talk) 17:41, 26 April 2020 (UTC)[reply]
Support: Perfectly reasonable and an excellent suggestion to boot. I agree with Swarm that this is just a first step, but this is a very good start. — Javert2113 (Siarad.|¤) 17:55, 26 April 2020 (UTC)[reply]
Support: our legacy 'crats (and admins) are in their position because of their exceptional contributions to Wikipedia, which I thank them for, but this is not technical justification for having more privileged accounts than necessary. Not only is there a risk of accounts being compromised (given increases in security threats and our early lax attitudes to requiring strong passwords), there is also a risk of users not possibly being able to keep up with prevailing standards and practices when the majority of their experience was on a project with a different culture to it. Crats should be highly active in recent years. If personal circumstances prevent this then there are thousands of tasks they can do here that don't involve any commitment or activity requirements. — Bilorv (talk) 20:57, 26 April 2020 (UTC)[reply]
Support - the more measures to stop a compromised bureaucrat account from wreaking havoc, the better. And bureaucratship is a commitment, much like adminship - they need to maintain said commitment. Kirbanzo ^{(userpage - talk - contribs)} 17:29, 27 April 2020 (UTC)[reply]
Support as this is security 101 folks. spryde | talk 11:54, 28 April 2020 (UTC)[reply]
Support crats need to be active at least semiregularly to remain in touch with community norms. – Teratix ₵ 01:48, 29 April 2020 (UTC)[reply]
Support use the tools or lose the tools. LEPRICAVARK (talk) 12:05, 29 April 2020 (UTC)[reply]
Support. Seems a good proposal to me. — Amakuru (talk) 22:26, 29 April 2020 (UTC)[reply]
Weak support It's a pretty infrequent problem, but the fact is, having out-of-touch crats making decisions is a bad idea. I'm not sure I understand all the opposition; how is it mean-spirited to say we need our decisions to be made by bureaucrats who are staying up to date? How is it chasing people away when they're already gone? And what possible reason can there be to retain tools you aren't using, aren't planning to use anytime soon, and are quite likely to misuse if you did use them because their uses have changed since you last paid attention? That said, I'd prefer a more nuanced solution. —valereee (talk) 14:13, 2 May 2020 (UTC)[reply]
Support. No need to keep those dangerous rights if they are not used. – Majavah ^(t/c) 06:22, 8 May 2020 (UTC)[reply]
Support - Seems like a reasonable first step. While chances to use crat tools are not terribly common, two years should be more than enough time. PackMecEng (talk) 17:46, 10 May 2020 (UTC)[reply]
Support of course. Crats are elected because they have a high commitment to the community they serve. They always need to be up to date with the community's norms. Are we seriously going to wait until an out of touch crat makes a poor decision? Speaking from experience, we had a crat on Wikimedia Commons who granted back the mop to a former controversial admin, despite the latter's many mistakes and problems before their bit was removed. The crat had to resign due to community pressure. I'm also concerned about crats gaming the system by doing only the minimum amount of admin activity every year just to retain their sysop and crat bits. The Commons community also removed another crat for that. --Pandakekok9 (talk) 08:38, 13 May 2020 (UTC)[reply]
Per nom. However, the two years is a bit long until de-crat, since if the advanced tools haven't been used over 6 months to a year they're probably not needed. I would also like to see a term limit of 4 or 5 years. comrade waddie96 (talk) 08:44, 14 May 2020 (UTC)[reply]

Oppose (Bureaucrat activity)

Oppose this particular requirement. From my understanding the job of a bureaucrat is both stable and well-defined. There are very few bureaucrats and as we are volunteers I would expect some to move in and out of activity. I think it's better for our encyclopedia and editors if there are more bureaucrats, increasing responsiveness and increasing the liklihood of a request being answered quicker. I think the well-defined and stable scope makes this different to activity requirements for admins. For this reason I oppose the proposal. --Tom (LT) (talk) 23:46, 24 April 2020 (UTC)[reply]
Weak oppose I'm not convinced that this would make Wikipedia better. Have there been any serious problems caused by rusty bureaucrats? b uidhe 09:16, 25 April 2020 (UTC)[reply]
Oppose The opportunities for such activity are quite sporadic and limited now as there are few RfAs and most of them don't have a close result requiring a chat. The proposal might therefore result in a unseemly rush to act in haste, in order to secure a rare opportunity to retain the position. Or the bureaucrats might start expanding the threshold for chats, in order to look busy. To avoid perverse incentives, it should be sufficient if the bureaucrat is active in the project in other ways – as an editor, patroller or admin. Or just have a fixed-term limit, as is done for arbcom. Andrew🐉(talk) 09:19, 25 April 2020 (UTC)[reply]
Oppose. (most strong possible) The proposal does not present any problem that will be solved by this. We can not impose random rules, for no reason. BTW, links to the current policy and clearly stating the changes, instead of making us search, read and compare texts, would be much helpful - Nabla (talk) 10:36, 25 April 2020 (UTC)[reply]
Oppose per all above, Creffet's comment below, and Cecropia's section below. Solution in need of a problem as it stands. --Puddleglum ^2.0_{(How's my driving?)} 14:15, 25 April 2020 (UTC)[reply]
Puddleglum2.0 - A solution to a problem is a proposal that is proposed just for the sake of change and do not offer any practical advantages, This proposal wasn't done out of pure boredom and this proposal has advantages like more active 'crats and 'crats who actually put the work in and who don't simply treat it as a "badge of honour" whilst doing absolutely nothing 'crat/admin related. –Davey2010^Talk 15:10, 25 April 2020 (UTC)[reply]
But there's very little work for bureaucrats to do. It's quite possible that there will not be an RFA discussion that finishes within the discretionary range for more years than this would allow, so the only activity that they would do would be to rubber-stamp community decisions. Do we want our bureaucrats to share out the rubber-stamping work so as to avoid this situation? If the real intent of this proposal is to do away with the position of bureaucrat, and leave this to stewards or arbcom members or someone else, then it should be open about saying so. Phil Bridger (talk) 17:58, 25 April 2020 (UTC)[reply]
Oppose - Base cases make for bad law. This is rushed and not fully thought out. We don't want Crats acting simply out of filling a quota. Dennis Brown - 2¢ 23:56, 25 April 2020 (UTC)[reply]
Oppose. Solution in search of a problem. Ruslik_Zero 20:59, 26 April 2020 (UTC)[reply]
Oppose. Why do we so often chase people away from the project instead of concentrating on making people feel welcome? And what everyone else said, above. --Dweller (talk) Become old fashioned! 10:02, 27 April 2020 (UTC)[reply]
Oppose - per Dweller and all of the above. OhKayeSierra (talk) 13:15, 27 April 2020 (UTC)[reply]
Oppose per Buidhe and Dweller, but I am open to supporting a future proposal that is more effectively written. This specific proposal is still able to be gamed and unlikely to make a serious improvement to the project. Let's assume this proposal passes, and Crat A has been inactive for 728 days. By day 730 they need to "Grant[] or remov[e] permissions that can only be done by a bureaucrat" which is either intadmin or admin. All crats (currently) happen to be administrators and may have their bit removed or restored by request. So on day 729, Crat A removes their own administrator bit voluntarily. They are thus no longer inactive under this proposal and the clock restarts. Crat A remains inactive for another 728 days. They are no longer an administrator and on day 1458 they request their admin bit be restored. Having been inactive for nearly 4 years at this point, Crats B-Z are not "reasonably convinced that the user has returned to activity or intends to return to activity as an editor" (Wikipedia:Administrators#Restoration of adminship) but during the 24 hour holding period, Crat A participates in the discussion of their own userrights which is "part of ordinary discussions at the bureaucrats' noticeboard." They are thus no longer inactive. Crat A has thus extended their cratship for 6 years under this proposal with no substantial increase in activity. — Wug·a·po·des 17:26, 27 April 2020 (UTC)[reply]
Oppose. A solution in search of a problem. Bureaucrats have demonstrated their trustworthiness, their clue, their competence for judging consensus (however community consensus evolves), having the best interests of the project at heart...and generally being boring. Absent pretty strong evidence to the contrary, I would assume they are capable of continuing to all this at whatever level of engagement they choose. If they choose that level to be zero, they are harmless, so I fail to see reason to remove the bit due to arbitrary activity/inactivity rules. In contrast, inactive bureaucrats returning to activity will either be due to again finding the time and enthusiasm to do so, and then that's a win and we should encourage it. Or they will have been encouraged to chime in during some tricky situation or where enough uninvolved bureaucrats are unavailable, where their voice may be valuable. In either case, even more than for a random admin, I'd expect they will nuance their participation to reflect their familarity (or not) with current community norms, as well as with timeless ones. Martinp (talk) 22:29, 28 April 2020 (UTC)[reply]
Oppose Having an activity requirement for admins makes sense. The tools are widely used, and can be used any day of the year in a myriad of ways. There is never a shortage of admin tasks. But bureaucrat tasks come up only rarely. Having bureaucrats rush to try to do a task to not lose their perms seems foolish, and like a good way to create edit conflicts and wheel warring, as well as encourage bad decisions. Unlike the problem of inactive admins, I'm not seeing a serious problem of inactive 'crats that needs a solution. CaptainEek ^{Edits Ho Cap'n!}⚓ 01:26, 29 April 2020 (UTC)[reply]
Oppose - First of all, since the criteria listed include non-logged action, I wonder who will be expected to plumb every Bureaucrat's edit history to determine if they qualify as "active". Second, Bureaucrats do more than the items listed. Third, I honestly do not believe that we really want Bureaucrats arbitrarily taking some action out of attempting to meet these criteria. Rather that they are instead doing so in service to Wikipedia. Such service of which I, at least, am wholeheartedly appreciative. - jc37 06:58, 29 April 2020 (UTC)[reply]
I wonder who will be expected to plumb every Bureaucrat's edit history to determine if they qualify as "active". Well, other bureaucrats of course- probably xaosflux! Bureaucrats do this already, and in the current proposal this activity ironically doesn't count as bureaucrat activity. That said, since the above proposal further limits what is considered bureaucrat activity, it would be a slightly easier task than it is presently (not an endorsement). –xeno^talk 11:46, 30 April 2020 (UTC)[reply]
@Xeno: probably, though while updating something like Wikipedia:Bureaucrat activity doesn't appear to count itself, participating in an ordinary discussion at WP:BN - such as about the status of the activity check does. — xaosflux ^Talk 13:02, 30 April 2020 (UTC)[reply]
Solution looking for problem. So many times on the bureaucrats' noticeboard we have a discussion where someone is unhappy with the various inactivity criteria, starts a long discussion over it and wants to change the policy; it's changed, tightened and it's still not good enough, apparently. A lack of activity doesn't mean keeping out of step with community norms; I can go months without any bureaucrat-related activity but I still read every RfA; we don't have a lot to do and sometimes we trip up over ourselves as is. No need to make that worse. Agree with Dweller, too, as we spend far more pushing people away than retaining them. Also, since there is at least one mention above of "some" current bureaucrats "hat collecting", I'd like to see evidence of this. Acalamari 22:29, 29 April 2020 (UTC)[reply]
I don't see a genuine issue that needs fixing and the attitudes shown in some of the comments makes me sad. Spartaz ^Humbug! 05:50, 30 April 2020 (UTC)[reply]
Oppose. I agree with CaptainEek that crat tasks are not frequent enough to allow any crat to definitely meet these "quotas". If there are no RfX to close or others are faster, that does not mean this crat doesn't want to be active, there just is nothing to do. And the more crats we have, the smaller the amount of work any of them has to do (which is not a bad thing). Unlike with admins, there is no basically infinite pool of stuff to do to demonstrate activity. As such, since all crats are also admins, it seems sufficient to remove cratship for inactivity at the same time as adminship is removed for inactivity (or, more radically, we could consider using the es-wiki model to combine adminship and cratship into one, eliminating this problem completely). I do agree with Davey2010 on WP:HATCOLLECTING problems in general but this proposal would consider crats inactive that explicitly denoted that they want to be active but lack stuff to do. Regards So Why 06:21, 30 April 2020 (UTC)[reply]
Oppose, even if we have too many bureaucrats, I don't see why we should drive them away. —Kusma (t·c) 08:57, 30 April 2020 (UTC)[reply]
Solution in search of a problem. Stifle (talk) 09:23, 30 April 2020 (UTC)[reply]
Oppose The criteria seem wrong; I'd rather not see unnecessary bureaucrat activity increased just to meet these criteria. The net effect of these criteria seem that they would encourage more crat chats and more pushing towards quickly closing RfAs so as to meet these metrics. PaleAqua (talk) 19:59, 30 April 2020 (UTC)[reply]
Leaning oppose. It seems to me that the grant of the 'crat bit is a statement by the community that the recipient is trusted to exercise that power. Mere absence of use should not diminish that trust. BD2412 T 20:09, 30 April 2020 (UTC)--[reply]
Oppose I don't want bureaucrats doing bureaucrat things for the sake of appearing active. Better to go with project activity levels although with rather higher standards than we currently use for admins (which also need to be raised but that is a separate problem).©Geni (talk) 00:07, 1 May 2020 (UTC)[reply]
Oppose per many of the above. Respect or trust or whatever it is we give to bureaucrats when they pass RfB doesn't seem to me to be worth much if we then say "We'll withdraw it if you don't keep busy". When i trust someone, i trust them until i have reason not to, not only as long as i can see they're still worthy of my trust; trust, in other words, is in character, which is not something that often radically and rapidly changes. Happy days, Lindsay^Hello 07:45, 1 May 2020 (UTC)[reply]
Oppose - For one, it strikes me as a solution in search of a problem, but more than that, it seems to motivate bureaucratic actions, either on the part of 'crats (showing up to add a "me too" comment to a discussion at BN, as a way to show they're involved maybe?) or on the part of whoever is tasked with deciding whether a given 'crat is active. This proposal doesn's streamline the way we do things, it doesn't seem to fix a problem with current processes and it encourages people to do work for the sake of doing work. Guettarda (talk) 13:13, 1 May 2020 (UTC)[reply]
Oppose this particular variant, although I would support periodic reconfirmation RffBs for crats. It would serve the same presumed purpose of weeding out people who either weren't interested in continuing or have lost community trust, and unlike admins the numbers are low enough that we wouldn't be flooding the process, and the crat role doesn't involve as many contentious actions so there's less likelihood of a torrent of grudge-opposes. ‑ Iridescent 14:05, 1 May 2020 (UTC)[reply]
Oppose. The activity requirement for administrators is reasonable, there are always things that need editing so a period of inactivity can be remedied with short notice. However, with the low number of RFAs per year, months may pass between each time bureaucrat activity is needed there. There is no benefit to having bureaucrats racing to close RFAs in order to satisfy activity requirements. Sjakkalle (Check!) 16:34, 1 May 2020 (UTC)[reply]
Oppose Per Geni. Spencer^T•C 01:32, 2 May 2020 (UTC)[reply]
Oppose I don't see a particularly pressing problem that this solution aims to address. If there is no abuse by inactive bureaucrats, then no issue. If there are an insufficient number of bureaucrats to handle the job, the solution is to make more bureaucrats. Ergo Sum 01:41, 2 May 2020 (UTC)[reply]
Oppose Still more of this "let's find a solution to a problem that doesn't exist". The crats have continually and consistantly proven to be the most responsible and dependable users we have. This constant need to change the rules in the middle of the game is offfensive. It's been done to death with "Admin." rules, and now we're on about the 'crats.
Perhaps this is all simply young lions trying to make their bones. Everyone wants to have a "look what I did" moment that they can take pride in. But my feeling is that even if the 'old guard' is getting long in the tooth - there's absolutely no reason they can't work side by side with the 'young guns'. Or perhaps I just had some bad 'shrooms' on my pizza and I'm imagining things.

Perhaps some folks feel we have too many crats. How anyone would come up with that is reasoning that I can't follow. I'd love to work hand-in-hand with 20, 30, 40 'crats that have 70, 80, 90% approval from the RfX process. Why the 'unwashed' would feel threatened by it is beyond me.

In short? No. It's a fool's errand, and there's no need for it. I know there are tons of discussion about these "requirements" about, so I certainly not calling any individual a fool. Someone bringing this up can be a good thing if it quiets the chatter, and lets folks get back to actually building an encyclopedia. Thanks for your time. — Ched (talk) 02:04, 2 May 2020 (UTC)[reply]
Oppose well intentioned proposal, but I tend to agree that this is a solution in search of a problem that doesn't currently exist. I also share the concern that there may not be enough opportunities to perform crat related functions. -Ad Orientem (talk) 02:15, 2 May 2020 (UTC)[reply]
Oppose... concur with Ad Orientem, this is a solution in search of a problem. Jason Quinn (talk) 03:39, 2 May 2020 (UTC)[reply]
Oppose as long as the bureaucrat doesn't leave the site completely, I see no need for this. SportingFlyer T·C 08:02, 2 May 2020 (UTC)[reply]
Oppose I share the concern about not having enough opportunities to perform bureaucrat-only functions. I'd prefer a rule based on overall project activity. kcowolf (talk) 20:54, 2 May 2020 (UTC)[reply]
Weak oppose - I don't see the point in this. Dark Knight 2149 15:24, 6 May 2020 (UTC)[reply]
Oppose per Andrew Davidson. the wub "?!" 17:18, 7 May 2020 (UTC)[reply]
Oppose - There are currently less than 20 bureaucrats and, as others have stated, the chance to perform actions related to the role is far and few between (and we should not expect it on every available occasion). — Godsy^(TALK_CONT) 01:16, 8 May 2020 (UTC)[reply]
Oppose Thism seems like a solution in search of a problem. I see no evidence that out-of-date crtats are causing difficulties to anyone, or making incorrect decisions. Use the same standards as for removing admin rights for inactivity. DES ^(talk)_{DESiegel Contribs} 18:11, 10 May 2020 (UTC)[reply]
Oppose—I don't mind 'cratship being removed for inactivity, so long as it's simply a matter of requesting "reactivation" of their permissions if and when these contributors return, just as it is with the administrator permission. Removing the advanced permissions of inactive accounts is a good security practice. However, requiring a new RfB for returning 'crats is needless, and requiring specific bureaucrat activity encourages needless actions or discussion just to retain the bit. I can't support the proposal with those elements present. {{Nihiltres |talk |edits}} 18:55, 16 May 2020 (UTC)[reply]
Oppose - I don't see what problem this would solve. Is there an issue with old bureaucrats causing trouble? If the goal of this proposal is to simply get crats to be more active, why don't we just promote more crats instead? Forcing them to perform 1 action every two years isn't going to make any difference. Kaldari (talk) 22:03, 17 May 2020 (UTC)[reply]
Oppose +1 to "solution in search of a problem." ZettaComposer (talk) 15:49, 18 May 2020 (UTC)[reply]

Discussion (Bureaucrat activity)

Requests to join the Bot Approvals Group must be closed by a bureaucrat, but aren't included in these requirements because there is no associated user right. The proposed requirements also leave out RfB crat chats (which, while rare, are possible). --AntiCompositeNumber (talk) 21:38, 24 April 2020 (UTC)[reply]

AntiCompositeNumber, good catch. Updated. Courtesy ping to Pawnkingthree. TonyBallioni (talk) 21:44, 24 April 2020 (UTC)[reply]

Anyone have a rough guess at how often these "qualifying bureaucrat actions" occur? What I'm concerned about is that the current one-month warning might not be enough warning time - unlike admin tasks, where there's always something to do, the need for 'crat actions is more intermittent, so I think that it would be possible for someone to get to the 23 month inactivity mark, get the warning, genuinely want to continue contributing as a 'crat, but then there are no 'crat chats/requests for (de/re)sysop/etc. for the next month. creffett (talk) 23:00, 24 April 2020 (UTC)[reply]

Every time there’s a resysop request. Just commenting “no issues” without acting would qualify. The two changes to what counts as activity are: getting rid of renames and getting rid of the “I am available for service” clause. The other change is moving three years to two. TonyBallioni (talk) 23:05, 24 April 2020 (UTC)[reply]

If commenting like that is sufficient, then no further complaints from me. creffett (talk) 23:07, 24 April 2020 (UTC)[reply]

Yep. Worded that way on purposes so as to make it easy while getting rid of some of the oddities of the existing policy. TonyBallioni (talk) 23:08, 24 April 2020 (UTC)[reply]

The new minimum qualifying activity can be fulfilled by typing four characters every 24 months, so I don't think the proposed changes address the primary motivation for the change.

Ironically, one of the most complicated and tedious bureaucrat activities - tending to bureaucrat inactivity - isn't considered a qualifying action unless it results in a log action. –xeno^talk 14:12, 25 April 2020 (UTC)[reply]

Would this take effect immediately? Assuming this passes, every crat who has not participated in a crat discussion or used their crat tool within the past 2 years will be given a 1-month notice on the closure of this RfC, right? How many will this affect? How many RfAs will we need to launch in order to give them all a fair chance? – bradv🍁 23:20, 24 April 2020 (UTC)[reply]
Just one, but it has to go to crat chat, so they all can participate. Natureium (talk) 23:22, 24 April 2020 (UTC)[reply]
So just one controversial candidate. Maybe someone who likes to make weird jokes that some people don't get, but is otherwise an excellent well-rounded editor with lots of experience. Any ideas? – bradv🍁 23:24, 24 April 2020 (UTC)[reply]
I can't think of anyone who fits those criteria. Natureium (talk) 23:26, 24 April 2020 (UTC)[reply]
EEng? creffett (talk) 23:34, 24 April 2020 (UTC)[reply]
I was thinking of Natureium, but that might work too. – bradv🍁 23:40, 24 April 2020 (UTC)[reply]
I'm thinking you lot have lost your minds. E Eng 00:31, 25 April 2020 (UTC)[reply]

(edit conflict) I would assume so, but for the record the "oldest" crat as far as days-since-activity goes is late-2019, so at the very earliest the first notices would be given in July 2021. Primefac (talk) 23:23, 24 April 2020 (UTC)[reply]
Depends on how you count the recent comment at BN. I would be inclined to grandfather it for simplicity’s sake. TonyBallioni (talk) 23:24, 24 April 2020 (UTC)[reply]
I'm going off the list, which has been updated following said discussion at BN. Primefac (talk) 23:25, 24 April 2020 (UTC)[reply]

Well that's what I'm asking. If we grandfather them in just because they expressed interest in retaining the hat, that kind of takes the teeth out of this proposal. – bradv🍁 23:26, 24 April 2020 (UTC)[reply]
(edit conflict) Yeah. I think Bradv’s question is asking whether or not it’d be retroactive. This would not count under the proposal as activity. I was saying that for the sake of simplicity we’d grandfather the current table and make it 2 years from those dates under the new policy, both for fairness and ease. I wasn’t aiming this at one person, but was trying to have a new policy that would prevent the awkwardness of the current BN thread. The “I want it” once every three years clause is ridiculous so the responses are understandable, but you also can’t blame someone for following it. TonyBallioni (talk) 23:31, 24 April 2020 (UTC)[reply]
When we established the administrator inactivity policy, hundreds of people were desysopped at the conclusion of the RfC. We didn't only apply that to new administrators – it was applied retroactively. This should be handled the same way. – bradv🍁 23:37, 24 April 2020 (UTC)[reply]
Another question: One of the crats replied to the latest BN thread with the comment "Good to hear from you." Would that still count as activity under this proposed change? – bradv🍁 23:49, 24 April 2020 (UTC)[reply]
IANAB but I would interpret that not to qualify under ...part for requests for adminship or bureacratship or as a part of ordinary discussions at the bureaucrats' noticeboard. ~ Amory (u • t • c) 00:53, 25 April 2020 (UTC)[reply]
Question: Bureaucrat activity and logged actions aren't the same thing right? Because if they are, then we have conflicting activity requirements for restoration and/or removal. {{replyto}} Can I Log In's (talk) page 02:16, 25 April 2020 (UTC); edited 02:19, 25 April 2020 (UTC)[reply]
- I think what you’re referencing is for admins, but it also wouldn’t apply here. If the bureaucrat flag is removed for inactivity as a bureaucrat they have to pass RfB again. TonyBallioni (talk) 02:23, 25 April 2020 (UTC)[reply]
  I've linked the related pocedure in the small text. Inactive bureaucrat accounts. {{replyto}} Can I Log In's (talk) page 03:16, 25 April 2020 (UTC)[reply]
The RFC talks about updating a policy. TonyBallioni, could you please provide a wikilink to the policy that is meant to be updated? —⁠andrybak (talk) 09:02, 30 April 2020 (UTC)[reply]

Implementation if this passes

So I think the elephant in the room here is that we’d have one or two recent crats who are still crats by virtues of the current policy that says they can stay bureaucrats if they say they want to. From a human perspective I personally have a very hard time implementing this immediately for people who thought this month they were fine. My thought would be that it makes sense to have some sort of grace period after this passes to allow them reasonable time to return to activity beyond the 30 day notice. Maybe 60 days or something of that sort. Not opposed to longer or shorter, I just really want to avoid the feeling we are changing the policy on specific individuals, which I don’t think is something we want to be seen as doing. TonyBallioni (talk) 01:10, 25 April 2020 (UTC)[reply]

I'm not quite sure what you mean here; I thought you said we'd grandfather in previously qualifying activity so the first potential de-crat would be in 2021? -- King of ♥ ♦ ♣ ♠ 01:24, 25 April 2020 (UTC)[reply]

That was my original thoughts but I think the point above Bradv makes is good so this was in a way in a response to that. There’s a really difficult balance to walk here between being fair to individuals while also implementing what the community wants. I think grandfathering would be the easiest, but it’d also be the one that puts off community consensus for two years. Figuring out how to thread that balance is something we need to discuss. TonyBallioni (talk) 01:29, 25 April 2020 (UTC)[reply]

I think the clear precedent is what we did after we passed the stricter activity requirement for sysops. Following that we dropped 230 sysops. Best, Barkeep49 (talk) 01:46, 25 April 2020 (UTC)[reply]

(edit conflict) In my mind there’s a fairly large difference between an initial implementation when there was no previous criteria existed and there was a way to request back and one that happens after a criteria has been in place and that would only affect one or two people with no way to request back without an RfX. The latter is something that we should try to handle in a way that gives them a clear opportunity to show that they actually are available for service. TonyBallioni (talk) 01:58, 25 April 2020 (UTC)[reply]

The simplest solution here is to make the policy change take effect 30 days after the close of this RfC. That would allow 60 days for inactive crats to resume activity, and makes sure that the change the community wants actually takes effect in a reasonable time frame. – bradv🍁 01:49, 25 April 2020 (UTC)[reply]

Why 60 days? I would just give them 30 days, as if their last activity now-qualifying activity was exactly 2 years before the RfC passed. This is a RfC about setting consistent standards; all of this grandfathering is counterproductive. * Pppery * _{it has begun...} 02:14, 25 April 2020 (UTC)[reply]

Because you don’t want to lose good people who might actually be trying to return but don’t have that much of a chance to contribute. Finding a middle ground where everyone can live with the timeframe is ideal. TonyBallioni (talk) 02:18, 25 April 2020 (UTC)[reply]

I agree with Tony and Brad, 60 days is good compromise between two years and immediately. Thryduulf (talk) 09:30, 25 April 2020 (UTC)[reply]

I'd back the 30+30 rule. 2 years seems excessively long, but I also feel immediate just risks damage with no appreciable upside. Nosebagbear (talk) 09:45, 28 April 2020 (UTC)[reply]
Question: What is the purpose of removing permissions to people who have not used them? What is the advantage of doing that? I mean, having more people with permissions is better than having less people. --NaBUru38 (talk) 20:06, 10 May 2020 (UTC)[reply]

Cecropia is Amazed

Back when the Bureaucrat role was first created by Jimbo for have an orderly way to handle Sysop requests, he said that he chose the term "Bureaucrat" because he felt it wouldn't be a title that people would find attractive, so there wouldn't be great competition to obtain it.

But maybe I suppose I shouldn't be amazed, nearly two decades down the road that some 'crats would become more bureaucratic in the traditional sense.

I'm not here to defend myself but one comment on my Talk Page from Chris Troutman is a little much (excerpted):

All userrights exercised on wiki are for the maintenance of the encyclopedia and are not trophies for once winning a popularity contest many years ago. The fact that your 'crat hat was removed for inactivity in 2014 and you asked for it back only to perform no work as a 'crat evinces your dishonesty. Please let me know if I'm wrong in my statement of facts. I now implore you to revert your edit at BN and ask for your admin hat to be removed until such time as your real life allows you to regularly contribute. I welcome your contributions and if you could actually be an active bureaucrat, that would be great. As it is, I ask that (per WP:HATSHOP) you not bring contempt upon the title "bureaucrat" in this manner. Chris Troutman (talk) 19:44, 24 April 2020 (UTC)[reply]

Trophies? Popularity Contest? "bring contempt." Do I really deserve these ad hominem attacks and violation of the principles of collegiality we had in the early days of Wikipedia. I'm disappointed. Cecropia (talk) 13:11, 25 April 2020 (UTC)[reply]

You do not deserve that and Silk Tork's suggestion of a way to honor with you and editors like you has sat very well with me. One of the most important sources of "new editors" we will have in the coming year are editors who were once active. I do hope you return to activity on the project as we need all the good editors we can get. Best, Barkeep49 (talk) 14:43, 25 April 2020 (UTC)[reply]

I don't think you need to worry too much about what that guy thinks. Reyk _YO! 15:03, 25 April 2020 (UTC)[reply]

No you of course do not deserve such attacks. Speaking for myself (but I believe others are in the same camp) I would have wanted this two days or two years ago; you may have been a catalyst but no individual is the target for the good folks supporting this. ~ Amory (u • t • c) 16:49, 25 April 2020 (UTC)[reply]

Heh! Since some people have been throwing around figures, I can say that I did a lot in the early days of Wikipedia, including being a driving force in policies the community adopted. Since the issue came up, by 2011 I actively participated in and completed 411 promotions and closed additional RfAs and RFBs. The closest I know of was Taxman:Taxman, who promoted 170.

If I weren't 74 years old and still having to work full time I would be still be engaging actively in the community I enjoy. I'm pleased that after all this time there are still Wikipedians who remember me well. The way some are spinning their wheels on this subject you'd think I was asking for a pension. LOL! Cecropia (talk) 18:49, 25 April 2020 (UTC)[reply]

@Cecropia: One small point: criticism of your actions is not ad hominem. But yes, the evidence I presented brings your motives into question. Chris Troutman (talk) 01:09, 26 April 2020 (UTC)[reply]

Specifying what you think those motives are and turning them into specific accusations is ad hominem. Or playing with libel. It is one thing to bring up issues of opposition. To attack my character and attempt to bring me into disgrace is another thing entirely. Cecropia (talk) 14:01, 26 April 2020 (UTC)[reply]

Collapsing off-topic discussion. Mz7 (talk) 16:07, 27 April 2020 (UTC)[reply]

The following discussion has been closed. Please do not modify it.

Is that like, a legal threat? Govindaharihari (talk) 14:05, 26 April 2020 (UTC)[reply]

Quit stirring the pot. If Cecropia were making a legal threat, he would say as much. WaltCip (talk) 16:08, 26 April 2020 (UTC)[reply]

It looks like a legal threat to me, or at the least using a legal threat to quiet objections and I feel it is not stirring the pot to request him to clarify, thanks Govindaharihari (talk) 16:11, 26 April 2020 (UTC)[reply]

I do not think it helpful or respectful to suggest someone who served the project ably and is already under criticism whether they are making a legal threat because they happened to have mentioned the word libel. Best, Barkeep49 (talk) 15:40, 27 April 2020 (UTC)[reply]

Criticism of actions is not necessarily ad hominem, but doing so with accusations of "dishonesty" and using language like "I ask ... you not bring contempt" is unquestionably ad hominem, uncivil, and needlessly incendiary. I would love to be part of a community where people who happen to phrase their strongly-felt concerns in such a way realize on further reflection such discourse is damaging and withdraw it, rephrase their concerns, and apologize. Martinp (talk) 22:42, 28 April 2020 (UTC)[reply]

We should just grandfather Cecropia from this new policy due to how long he has edited Wikipedia Tsla1337 (talk) 00:38, 28 April 2020 (UTC)[reply]

No, the entire point of this policy change is to not grandfather users. * Pppery * _{it has begun...} 00:48, 28 April 2020 (UTC)[reply]

No, That really would be a stupid idea and I would go as far as to say that would make this whole proposal utterly pointless. If you fail the requirements set out above then you should be booted. –Davey2010^Talk 01:27, 29 April 2020 (UTC)[reply]

If this is voting on a policy change and I have been at the center of some of this it seems to me to be an exercise in ex post facto policy. Cecropia (talk) 18:59, 29 April 2020 (UTC)[reply]

Perhaps some individual with the authority to do so will let me know what the Star Chamber decides. (Before we have another uproar, that was sarcasm, if I'm allowed) Cecropia (talk) 19:02, 29 April 2020 (UTC)[reply]

Cecropia, I remember you fondly, not least for the +sysop back in 2005. Hope to see you around more, in any capacity. Best wishes, El_C 23:19, 29 April 2020 (UTC)[reply]

Thanks much El_C. Kind words are appreciated now. After reading some more on WP:BN Cecropia (talk) 19:28, 30 April 2020 (UTC)[reply]

Regardless of whether this proposal is successful or not, you're objectively unqualified to be a sysop by current standards, much less a bureaucrat. You are merely grandfathered in. This is the most highly-privileged and highly restricted permission on one of the most significant websites of all time. You have not logged an admin action since 2008. You have not logged a bureaucrat action since 2008, with the exception of one 2017 crat chat comment, and one BN comment replying to the objection of your crat chat participation, stating that you're not sure why your "participation on Wikipedia is of current interest". Are you kidding me? At that time, you were defended on BN based purely on your 2016 statement that you would return to activity. Well how great did that turn out! You have literally not been active since 2008, not even as of this year. Get real, you're not a crat after a decade of inactivity based on merit, but because of lax activity requirements that allow you to game your retention of the tools, nothing more. The fact that you have the hubris and brazenness to create a subthread stating your shock at the backlash you caused just reflects how completely out-of-touch you are with the community. No one on this site is afforded the unenforceable shoulder-shrugging that the few remaining "relic crats" are. But hell, the fact that you can start a thread complaining about how much of a victim you are is pathetic. Have some pride. Have some honor. Go re-run RfB if you're so convinced you're worthy of it. Don't provoke a policy change proposal purely in reaction to your own cratship, and then have the audacity to start a subthread about how you're "amazed" by the response. No apparently-unqualified "relic crat" has ever proved my concerns about them wrong, and you're upholding that legacy spectacularly. ~Swarm~ ^{sting} 02:46, 7 May 2020 (UTC)[reply]

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

Redirect Disputes

I am not a principal to any of these disputes but would like the opinion of other editors on a policy matter that comes up from time to time. An editor offers a reasoned argument that an article topic is not notable and that the article should be redirected to a parent article. This most frequently happens in music, but also elsewhere. In music, commonly there is an article on a song, and the argument is that the song is not notable and should be redirected to the album. Sometimes the argument is that an album is not notable and should be redirected to the artist. An opposing reasoned argument is made that the topic is notable and the article should be kept. The question is how this dispute should be resolved. One option is a deletion discussion, but often the proponent of redirection says that they are not requesting deletion, so that AFD is not the appropriate forum, and that the article should simply be redirected. I have occasionally seen this lead to edit-warring, and we know that edit-warring is the wrong answer, regardless of what the right answer is. So is there a different right answer? My thought, after looking at the policies and guidelines once, but not reviewing them in depth, is that a deletion discussion is the appropriate answer, even if no one is actually proposing deletion, because redirection is an alternative to deletion and is a side-door deletion; but maybe there is another procedure that is preferred. I realize that discussion is the preferred first step, but what is to be done if the discussion is inconclusive? Is there a first-mover advantage? Is there a second-mover advantage? A Request for Comments is another way to resolve a content dispute, but the only real differences between an RFC and an AFD are the length of time, with AFD being quicker, and that AFD is specialized to deletion-like disputes.

Should redirection disputes be resolved by AFD, or is there a different answer? Robert McClenon (talk) 23:41, 1 May 2020 (UTC)[reply]

Having been brought up on this very topic several times in the past (yes, the majority being music-related), I am glad for this opportunity to get some wider input.

I am firmly of the opinion that AfD is the suitable forum for these discussions. My main argument is that almost all of the send-to-AfD-for-redirect cases I have kicked off stem from NPP, and concern newly created articles. That means that there are practically no watchers of these pages - in many cases it will be just the author and the new page reviewer. It is pointless to start a "redirect discussion" on the articles talk page under these circumstances; no one will comment. This is also the very situation in which an obvious redirect won't "stick", because there are only two people involved, one of them heavily invested. - Now, one could address that by creating a list of redirect proposals for people to monitor. But that would have to be publicized and editors would have to get into the habit of watching it (maybe that even exists already? If so, I don't know where - which would illustrate the problem). In contrast, most experienced editors keep the occasional eye on AfDs, and at least some good input is rarely hard to come by. So we already have a well-visited forum to invite discussion of these cases.

Are intended-redirect AfDs sucking up too much time and energy from AfD commenters? I doubt it - there's generally some amount of such cases in evidence, but they are hardly swamping the venue. Is some functionality of AfD being abused because it is employed for discussions that don't have an intial target of "have an admin push the delete button"? Nope - because "delete" is not an uncommon outcome in these cases, and "redirect" is a rather common outcome in intended delete cases. It seems a rather finicky distinction to regard the latter ones as suited to AfD and the former as in the wrong venue. Looked at from a different angle, would the average non-notable song nomination suddenly be welcome at AfD if I nominated it for deletion up front, in the expectation that the outcome would instead be a redirect (as is the usual treatment)? Yeah, if done with intent that would be gaming the system, but don't tell me that very scenario doesn't happen innocently as well. And policing whether the intention of nominators equals the likely outcome would seem positively kafkaesque.

Tldr - sending an intended redirect to AfD for decision is functional and doesn't hurt. If we formally disallow the practice, some replacement infrastructure will have to be created, spun up and popularized. Let's not. --Elmidae (talk · contribs) 22:34, 1 May 2020 (UTC)[reply]

I think my perspective is similar to Elmidae's: converting to redirect is valid as a bold change, but further dispute should be handled at AfD. The only gray area in my mind are situations where one, usually inexperienced, editor is trying to prevent an article from being converted to a redirect despite there being a consensus among other editors that the page should be a redirect. _signed,Rosguill ^talk 23:18, 1 May 2020 (UTC)[reply]
I agree; AfD is the best venue, both because of all of the reasons Elmidae explained and because this would essentially be one added purpose of an expanded "Articles for Discussion". If the talk page goes unseen, and it's not currently a redirect (or consensus for it to be one is unknown or nonexistent), AfD is the only logical choice. I personally would add the caveat from WP:NOTBURO that A procedural error made in a proposal or request is not grounds for rejecting that proposal or request, and that it shouldn't matter where the discussion takes place. —⁠烏⁠Γ ^(kaw) │ 00:48, 02 May 2020 (UTC)[reply]
New page is poorly created and needs to be redirected elsewhere. Especially true when a user tries to convert a redirect into a new article. NPP patroller boldly redirects, page creator reverts. If I see another experienced NPP patroller has redirected once, I may try to boldly redirect one more time to see if the creator takes the hint - if it's already been redirected a couple times, I would send the article to AfD for further discussion. If the page has been around for awhile, AfD is definitely the proper forum. So I would send it to AfD in all instances, if the dispute cannot be mediated between the edit warring users. SportingFlyer T·C 01:13, 2 May 2020 (UTC)[reply]
AfD is the appropriate location, if there is a discussion (that's can't be settled by BOLD/internally), making sure to ping everyone. Nominator should bold right at the start of their nomination that it's a redirection AfD, otherwise it defaults in interpretation to a redirect. Nosebagbear (talk) 09:01, 3 May 2020 (UTC)[reply]
I'm not sold on AFDs for redirect-or-standalone discussions. Redirect/don't redirect isn't just a notability question, it's also about WP:PAGEDECIDE. Deletion is about whether we have an entry or not; redirecting is about where the content should go. For example, one reason to put content about a song on the album page instead of its own page is if there isn't much content about the song. And a redirect discussion doesn't require an admin to close (no one is pressing the delete button). All of this pushes me to thinking that an RFC is better for redirect-or-standalone discussions than AFD. Though RFCs usually take 30 days as opposed to AFD's 7, that strike me more as a reason to close "redirect RFCs" sooner, rather than hold them in another venue. Levivich ^{[dubious – discuss]} 05:53, 10 May 2020 (UTC)[reply]
What is the problem with WP:Redirects for discussion? Thincat (talk) 08:46, 11 May 2020 (UTC)[reply]
- @Thincat: RfD deals with pages that are currently redirects or soft redirects, and whether or not they should be deleted or retargetted. It is not a forum for discussing article content, so these sorts of discussions are completely out of scope. It's not a perfect fit for AfD but in the absence of a dedicated venue that is by far the best. Thryduulf (talk) 10:02, 11 May 2020 (UTC)[reply]
I agree that AfD would be the usual and best place to discuss whether an article should be redirected to a parent topic when article talk page discussion has failed -- I think the article talk page should usually be tried first. I would also note that music is not the only area to have this sort mof issue. Articles about primary schools are often but not always redirected to the article about the school district. Articles about neighborhoods are often redirected mto the articvel about the city or other larger area which contains them. Articles about TV episodes are sometimes redirected to an article about the series. Articles about individual books in a series are sometimes redirected to articles about the whole series. These are all similar judgement calls and simialr procedures should be followed for each of them. DES ^(talk)_{DESiegel Contribs} 15:47, 11 May 2020 (UTC)[reply]

More Thoughts

I have a few comments. First, the music area has these debates because there can be different reasonable views as to how many articles to have at what level of granularity. With biography, for instance, the choices are delete or keep, no or yes. Merge/redirect is an occasional issue with biographies; it is the issue with music. There are strong inclusionist feelings by some editors and strong mergist or redirectionist feelings by some editors.

Second, I have also seen these debates after the article was in place for a while, although maybe that was because NPP was backlogged.

Third, I don't see any gaming of the system, but, to the extent that anyone is trying to use the system to their advantage, it may be the redirectionists, who argue against using AFD because they are not advocating deletion. I think that occasionally a redirectionist doesn't want to use AFD because it is likely to result in Keep, and they would prefer to win. There is good faith, but sometimes there is stubborn good faith.

Fourth, if there is consensus to redirect (merge) except for one editor, why not use AFD anyway? The alternatives are edit-warring or WP:ANI, and the alternatives are likely to take a few days to resolve, and AFD only takes a week. There is a commonly expressed view that formal closure is not always necessary because sometimes consensus is apparent, but if it isn't apparent to one person, formal closure is less messy than edit-warring.

Fifth, is there any reasonable reason not to use AFD for a deletion-like process?

Sixth, I will check to see whether the deletion policies and guidelines need to be clarified to establish that AFD is the proper forum for redirect disputes.

Robert McClenon (talk) 03:09, 2 May 2020 (UTC)[reply]

Imho, the WP:MERGEPROP procedure can be used unless one of the two articles is likely too un-WP:GNG to exist separately (which should then probably be rather discussed at WP:AfD). The WP:MERGEPROP procedure is somewhat less formal than WP:AfD, but is definitely a bit more structured than a mere "talk page discussion". It might be a good alternative when the article that is a candidate for being turned into a redirect is not wholly without merit, and a MERGEPROP discussion can possibly, for instance, be somewhat more suitable to concentrate on discerning whether the to-be-merged article merits a separate section in the article where the resulting redirect would go to (instead of only on the to-be-or-not-to-be question). --Francis Schonken (talk) 18:18, 11 May 2020 (UTC)[reply]

From the Deletion Policy

It says: "Suitable venues for seeking a consensus if a redirection is challenged include the article's talk page and Wikipedia:Articles for Deletion." So the claim that AFD is not appropriate for a redirect discussion is not just silly, it is just plain wrong. Robert McClenon (talk) 05:33, 2 May 2020 (UTC)[reply]

I agree, as seemingly has every editor to weigh in so far, that guidelines and precedent all support AfD as a place to deal with non-notable entries. One way to deal with lack of notability is to redirect/merge. Another way is to delete.There are others too. AfD is the correct venue to deal with articles that lack notability. Best, Barkeep49 (talk) 19:59, 2 May 2020 (UTC)[reply]

I have added clarifying language to WP:BEFORE. -- King of ♥ ♦ ♣ ♠ 21:34, 2 May 2020 (UTC)[reply]

Yep, the policy at WP:ATD-R says that AfD is a suitable place for such questions, this was decided in a 2018 RfC. – Uanfala (talk) 15:32, 15 May 2020 (UTC)[reply]

WP:RSOPINION and source quality

This is a lingering issue I tried to open discussion at the main policy page WT:RS but got little input, following an earlier discussion at [2] (under "Daily Mail and RSOPINION").

The short background: Obviously works like the Daily Mail are deprecated and should not be at all used for statements of facts. But they also do have staff writers that are reviewers for films and televisions, and thus their writings would seem to fall under WP:RSOPINION , and thus should be removed necessarily due to the DM's deprecation. This led to the whole intent of RSOPINION, which lacks the clarity that needs better resolution for works broadly, not just Daily Mail nor other deprecated works.

Does RSOPINION allow for the use of sources that are not reliable for fact, including those that are deprecated? The first statement of RSOPINION suggests this Some sources may be considered reliable for statements as to their author's opinion, but not for statements asserted as fact. but others argue that the line A prime example of this is opinion pieces in sources recognized as reliable. means RSOPINION is restricted to reliable sources.
Assuming RSOPINION does allow for the use of sources normally considered unreliable or deprecated. Should there also be a factor in RSOPINION related to expertise/recognition or similar authorizativeness of the author or the work to separate journalism from fan blogs or the like? For example, there are noted reviewers at the Daily Mail that have a history in reviewing UK television, so they would by a valued voice compared to some excited Doctor Who fan writing on their blog. I do note that if we take the interpretation about limiting to only reliable sources, this question becomes a non-starter on the presumption an RS is only going to publish opinions from people it considers authoritative to start.
Is there anything else of clarity that could be added to this point in RSOPINION? What we don't want is to open the floodgates to allowing random opinions to be used, and either by sticking only to reliable sources, or making sure that expertise/authority is sought here, we should be good, but there may be other facets I'm missing.

This is seeking input, as the discussion at WT:RS got little to add to that.--Masem (t) 14:58, 5 May 2020 (UTC)[reply]

What statement are you trying to source? If the statement is "In such-and-such a newspaper, so-and-so stated "The sky is green"", then that statement can be sourced to the original source where the quote came from. That's what RSOPINION is stating; if you need to establish that someone has stated something themselves then it's fine. It is not, never in any context, fine to use that statement to assess the veracity of the statement itself. That is, you cannot use such sources to verify that the sky is green, merely that the person who said "the sky is green" actual said those words. --Jayron 32 18:12, 5 May 2020 (UTC)[reply]

Shoot, I should be explicit. The specific question was around things like critic's reviews of contemporary media like film, television and books, and if that is needed to tune the the use of RSOPINION better, so be it. I can see RSOPINION being more restrictive in some topic areas like political commentary, for example. Actually even moreso for political commentary given why sources like Breitbart have been strongly deprecated. But again, if we need to focus this specifically on critic reviews, that's might make this an easier discussion for that "carve out". --Masem (t) 20:15, 5 May 2020 (UTC)[reply]

If we're asking about critic reviews of media, that's an issue of WP:UNDUE and not reliability. A critic is a reliable source for what they said themselves. That's always true. The issue is "why should we care that the critic in question said it?" not "Do we believe they actually said the thing we're saying they did?" I mean, I'll take Robert Christgau and David Fricke over "Joe Schmoe from random local newspaper's" review of a particular album, even if the local newspaper is a reliable source, and we can believe that Joe Schmoe actually wrote that particular review. That's not a reliability issue. It's a recognized expertise and acclaim issue; opinions are not reliable or unreliable, opinions have weight and importance based on who the person who has the opinion is, and their reputation and area of expertise. --Jayron 32 05:36, 9 May 2020 (UTC)[reply]

Blanket treatment of organs such as the Daily Mail is silly because they are typically have numerous sections written by many different writers in a variety of styles. Recognised staff critics such as Jack Tinker typically have a byline and their opinions will tend to be personal rather than just parroting a party line or house style. When I cite or quote such notable critics in a reception section, I would usually attribute them inline and link to their article, saying something like "Jack Tinker, writng for the Daily Mail, thought that the work was..." Andrew🐉(talk) 20:59, 5 May 2020 (UTC)[reply]
Part of the issue was the blanket Daily Mail review removal but I want this to focus on the general RSOPINION though as I pointed out above, if we have to narrowly focus on critic reviews to distinguish from political commentary, that's fine. Reviews are far less contentious issues than political commentary from sources not normally RS for fact. --Masem (t) 03:57, 6 May 2020 (UTC)[reply]
I can see the temptation to allow critic/review pieces but I see two counterpoints. First, it would be a bit messy distinguishing acceptable review-pieces from other, unacceptable, opinion-pieces. Second, if the editorial management of that source is so thoroughly disreputable then it casts significant doubt on their choice of critic-staff and on their oversight of such content. No one Reliable is certifying that this critic's opinion is worth hearing. The critic is no better than a random blogger for our purposes. Alsee (talk) 02:34, 10 May 2020 (UTC)[reply]
I agree with Jayron32. When the Daily Mail says the UK government is about to lift lockdown we cannot use that as a source to support a statement that this is indeed the government’s plan. If their cinema reviewer says a film is boring that’s not a statement of fact it’s a statement of opinion. There’s no reason I can see why that shouldn’t be cited. Even a broken clock is right twice a day. Mccapra (talk) 02:55, 10 May 2020 (UTC)[reply]

So I'm wondering if it makes sense that we have what would be an "RSEXPERT" section, rather than modifying RSOPINION, which would allow statements (opinion or otherwise) from established experts regardless from where they are published but with a whole host of caveats:
1. That who is an expert has to be established by consensus: not just someone notable (eg Alex Jones is not an expert on politics) but who editors that know the field are aware is a recognized voice in the field. In the area of media reviews, this would be notable film critics even those that write for a deprecated work like the Daily Mail. (As a corollary, an expert does not need to be notable, but if they have never been attached to a notable organization at all, that raises several questions).
2. There has to be some verifyability that the expert is the one posted/writing the work. This is like the Twitter checkmark purpose.
3. Key sourcing policies must be respected. BLPSPS still cannot be violated; an expert's commentary piece on its own cannot be used for talking about another BLP. MEDRS absolutely must be respected: An expert medical doctor writing to a common-man level about a new drug in his blog would not be allowed to be used on the page about that drug (though there may be other pages this could be applicable) A similar stance would be for SCIRS topics.
4. This should be used for content that has general encyclopedic value, keeping in mind facets like WP:NOT#NEWS, WP:RECENTISM, WP:UNDUE, and so forth. This generally means that there are few areas where a single person's opinion, absent any other sources that call to that opinion, has weight to be used in WP. Reviews of media like television and film are one notable exception, another may be in analysis of court cases after they have been decided by legal experts, as in normal coverage of these types of topics, there is usually an accumulation of such reviews or analyses as to give the reader a broad idea of what experts have said about the topic.
Does this make sense? --Masem (t) 03:39, 13 May 2020 (UTC)[reply]
We currently have an exception for subject-matter experts' self-published sources: "Self-published expert sources may be considered reliable when produced by an established subject-matter expert, whose work in the relevant field has previously been published by reliable, independent publications." It looks like your proposal would extend this exception to all questionable sources, instead of just self-published sources. If the publication is considered unreliable because it does not exercise adequate editorial control, your proposal would make sense. However, like Alsee said above, if the publication is considered unreliable because its editorial team has a reputation for curating content that is considered disreputable by reliable sources, then the opinion would still be questionable. Using the Alex Jones example, all of InfoWars would fall into the latter category regardless of author. — Newslinger talk 04:38, 13 May 2020 (UTC)[reply]
That's why, in part, who is a subject-matter expert is going to be driven by consensus and based on where they are publishing from among other factors. Definitely don't the case that would allow Alex Jones to be considered a subject matter expert for a topic, for example. But I'm also wanting to make sure that if we have a UK reviewer who maybe has only written for the Daily Mail for their entire career, is known in other RS works talking about the UK reviewing scene as a top and important critic, that we can allow them as a subject-matter expert despite their lack of publication in an "reliable" source; consensus should be able to judge from the RSes talking about the person that they are an expert and can use them in this "RSEXPERT" manner. --Masem (t) 17:12, 13 May 2020 (UTC)[reply]

How should we deal with false versions of Wikipedia articles being spread on social media?

File:Blood irradiation misleading screenshot.png

A false manufactured screenshot of an article that has been shared on Facebook. (Ultraviolet blood irradiation redirects to Blood irradiation therapy.)

We recently encountered a somewhat novel situation: Blood irradiation therapy, an article that had previously seen less than 50 views a day, suddenly spiked to over 30,000. We learned thanks to Beorhtwulf that it was because of a manufactured screenshot being shared on Facebook to try to give credence to Donald Trump's statement that ultraviolet light might be a cure for COVID-19. After a discussion at WikiProject Medicine, I whipped up a template, {{False version}}, and placed it on the article. It looks like this:

The pageviews for the page have since dropped back down to a healthier level, although they're still ~10x the baseline, meaning that roughly 90% of current readers are there because of the hoax. The template was brought to TfD by ToBeFree with the rationale that it wasn't appropriate to use a maintenance template for something that isn't a maintenance issue. It easily survived there, but several participants rightfully noted that we should probably have some broader discussion, so I'd like to bring up the general issue here. The next time we encounter misinformation of this sort, how should we handle it? {{u|Sdkb}} ^talk 20:23, 7 May 2020 (UTC) ^{Courtesy pings to previously involved @Mark viking, WhatamIdoing, Mdaniels5757, and TheTVExpert: {{u|Sdkb}} ^talk 20:23, 7 May 2020 (UTC)}[reply]

I think some may find the "please verify" language confusing. Verify with whom? It sounds like an instruction to specifically seek verification somewhere. BD2412 T 20:26, 7 May 2020 (UTC)[reply]

@BD2412: Would "confirm" or "check" be better word choice? {{u|Sdkb}} ^talk 20:45, 7 May 2020 (UTC)[reply]

Perhaps something more passive like "please take care". BD2412 T 22:04, 7 May 2020 (UTC)[reply]

I agree with the use of "Please take care" comrade waddie96 (talk) 11:25, 16 May 2020 (UTC)[reply]

Thank you very much, Sdkb, both for creating the template and this discussion. I do appreciate any attempt to combat fake news by facts, and I do see this as one. I just believe that, ironically, you're adding original research to the top of an article if there is no reliable source other than "Wikipedia user Beorhtwulf" and personal interpretation of statistics for placing the template in the first place. ~ ToBeFree (talk) 20:36, 7 May 2020 (UTC)[reply]
Yeah, I don't really know how we could address that other than deciding that this is a valid exception to WP:OR, which wasn't drafted with a situation like this in mind. I certainly would have felt less confident placing the notice if Beorhtwulf had been an IP, had a talk page filled with warnings, or had ignored the request to upload a screenshot. It also would have complicated things if blood irradiation therapy had been getting steady normal traffic. This particular case was pretty clear-cut in my view, but part of what I'm hoping to accomplish by bringing this up here is to figure out how we might want to approach cases with more complicating factors. Some brainstorming is needed. {{u|Sdkb}} ^talk 20:52, 7 May 2020 (UTC)[reply]
There is no requirement that project notices comply with WP:OR. It's always been just an editor's opinion that an article needs to be cleaned up, has an excessively long lead, or is difficult to understand. -- King of ♥ ♦ ♣ ♠ 23:28, 7 May 2020 (UTC)[reply]

I wouldn't say this was a case of OR. An unsourced claim in the article text that a misleading version of it was circulating would be both OR and a questionable self-reference, but a template on a top is an out-of-band editorial communication aimed at helping the reader contextualise and understand what they are looking at. It's no more OR than a cleanup tag. For the record I was not the creator of the template and don't have a clear view on its retention. Neither did I seek to include 'research findings' or personal interpretations of statistics in the article. My involvement in this was to mention the article on a couple of talk pages in the hope of getting it some expert attention. Beorhtwulf (talk) 02:23, 10 May 2020 (UTC)[reply]
Thanks for starting the discussion, Sdkb. I can understand ToBeFree's concern--this seems like a real-world assertion that would need a verifiable source. But I am more sanguine about a warning template like this because there is already precedent for article lead templates making assertions that are not verifiable in RS--this article is written like an advertisement, that article is non-neutral, those articles have topics that are not notable. All of these tags caution the reader to read with a more critical eye and warning about fake offsite copies seems to be in the same vein. More generally, templates like this occupy an intermediate place between article content, which should be verifiable, and communications with the readers and fellow editors about the articles and the encyclopedia, which do not need verification, just consensus. --{{u|Mark viking}} {Talk} 21:09, 7 May 2020 (UTC)[reply]
Yes, I don't see the big difference compared to if I, purely based on my own judgement, add another warning template. /Julle (talk) 22:23, 7 May 2020 (UTC)[reply]

I agree that maintenance and warning templates don't (or at least shouldn't) fall under OR. They're, by definition, a result of our editors making judgment calls on the content of the articles and sections they're placed on. I believe that incorporating this template is a good idea, and as for the wording, I would go with something closer to instructing the reader to make sure they're reading this page rather than trusting a screenshot, but I'm unsure of the specifics on how to word that properly. —⁠烏⁠Γ ^(kaw) │ 22:54, 07 May 2020 (UTC)[reply]
I don't think I understand the need. So a reader sees a fake screenshot of a given Wikipedia article, then opens the real article on Wikipedia. Would the reader not, at that point, see that the screenshot is a fake? --Bsherr (talk) 21:58, 8 May 2020 (UTC)[reply]

Someone could easily think the screenshot was real, but since it no longer confirms biases it raises suspicions in their mind. Damaging Wikipedia credibility, which is what they are trying to achieve ie. nothing is true and everything is possible. Such are the goals of disinformation. -- GreenC 22:18, 8 May 2020 (UTC)[reply]

That would involve them parsing the article to check whether it matched what they had been told it said. We should not underestimate the deficiencies in reading comprehension, critical thinking and ability to assess of sources of some of the morons who weigh in on current affairs by sharing viral images of unknown provenance around Facebook (I don't know if your feed is as full as mine with utter nonsense about 5G, the whole pandemic is a conspiracy, etc). No doubt some of the spike in traffic was made up of visitors who wanted to look into the technology themselves, and hopefully they read the article, although I must say it was in a significantly poorer state at that point, which is why I brought it to the attention of editors (I wasn't the instigator of the template). Beorhtwulf (talk) 02:19, 10 May 2020 (UTC)[reply]

Don't such templates usually go on the talk page instead? Elizium23 (talk) 07:03, 17 May 2020 (UTC)[reply]

If the sole point of this template is as a response to File:Blood irradiation misleading screenshot.png, then I think the whole thing is based on a false premise. It's not the text that's being attributed to Wikipedia, it's the accompanying image (this one), and that's what people reusing our images are supposed to do. (They haven't done it quite correctly—they should be attributing the creator rather than "Wikipedia"—but they're definitely trying to comply.) Is there any evidence that whoever posted this is claiming that Wikipedia is responsible for the text, rather than just the image? ‑ Iridescent 13:48, 10 May 2020 (UTC)[reply]

My concern in initially raising this (again, I didn't make the template, though I think that was a reasonable thing for another editor to do) was the effect, not the intent. The social media post included both our photo and the text beneath it, within the same image as if from a screenshot. The text is written in something resembling a Wikipedia style: bolded term, abbreviation in brackets, definitional sentence followed by more detail. Obviously those of us familiar with Wikipedia spot that second-person wording in the second sentence and know this is not a quote from one of our articles, but given the Wikipedia domain as the image credit just above it looks to the uninformed like a screenshot from Wikipedia, maybe as viewed on a mobile device. I agree that it is not necessarily the case that whoever created this image did so to deliberately impersonate Wikipedia: maybe they just did an image search and got our image, and combined it with some ######## text, but the effect on uninformed readers is potentially the same. Whatever the intent here, page views on that article (the term as stated in the social media post redirects to the article in question) jumped overnight from 50 a day to tens of thousands, so people were looking this up. At the time the article was in a worse state, containing plenty of unsourced statements, although was not as egregious as the text in the screenshot. Beorhtwulf (talk) 10:53, 12 May 2020 (UTC)[reply]

Paid editing

The behavioural guideline at WP:PE reads:"you are very strongly discouraged from editing affected articles directly;" same as the general WP:COIEDITING guideline. Both are without inline citations/notes, so I am not sure how unlikely it is that anything can be done about it, but I think it should be changed to "you must not edit affected articles directly;" The exemptions are already listed at WP:COIU on the same page. A Partial block from the affected article seems an appropriate remedy to address violations.

Occasionally, paid editors do take the option of not being discouraged by the very strong discouragement, which presents an awkward situation. This would remove all confusion and make handling paid contributions a lot more efficient and straightforward. The community should decide once and for all, whether or not it is okay with paid editors making substantial non-urgent direct edits to affected articles.

Obviously, we'd need an RFC to actually discuss it; first, I wanted to make sure I am not missing something obvious that would end this proposal speedily. Usedtobecool ☎️ 10:48, 9 May 2020 (UTC)[reply]

Clarification One:

The proposal is not to outright prohibit all mainspace contributions from paid editors, just the ones that are both significant && non-urgent. This means they are still allowed to make the edits exempted by WP:COIU, as that section is not being changed, and the new articles would be forced to go through AFC, as creating a new article would be a non-urgent significant mainspace edit. This proposal also leaves the WP:COIEDIT section as is.

So, let me reformulate: At WP:PE, let's change the bullet-points:

you are very strongly discouraged from editing affected articles directly;
you should put new articles through the Articles for Creation (AfC) process instead of creating them directly;

to:

you must not edit affected articles directly, except as provided by WP:COIU;
you must put new articles through the Articles for Creation (AfC) process instead of creating them directly;

And, optionally, let's add after the last sentence of the last paragraph—You may be technically restricted from editing the affected articles for failing to adhere to these guidelines.

Thank you! Usedtobecool ☎️ 08:50, 12 May 2020 (UTC)[reply]

Our policies on paid editing are already a joke, and making them stricter would do nothing but make people feel good about "doing something". After blocking 300 socks in one case at SPI some years ago (yes, 300) I came to the conclusion that simply outlawing paid editing isn't going to work. It is so painfully easy to sockpuppet, to create multiple accounts without getting caught, tightening the rules would only overburden the already overburdened SPI system. Creating 100 sock puppets that are difficult to link to each other does not require much skill, just patience, and a little monetary motivation. "Outlawing" paid editing makes as much sense as the War on Drugs, and has the same effect; makes it more profitable, thus alluring to those looking to make a profit. As I'm sure this will fall on the collective community's deaf ears, I will just leave it at this. Dennis Brown - 2¢ 19:08, 9 May 2020 (UTC)[reply]
Dennis Brown, I have added a clarification to my original proposal above. I am not proposing outlawing it, but, yes, it seeks to tighten the rules a bit. User-centred policing is less effective, true; and perhaps, UPE is more of a problem than some wikilawyering DPEs, but it's the latter this proposal is concerned with, and I do believe the proposed amendments would clarify the matter a bit without changing the status quo for the good faith DPEs. Regards! Usedtobecool ☎️ 08:50, 12 May 2020 (UTC)[reply]
I would generally support this. See Special:PermanentLink/946560078#Conflict_of_Interest_Editing for one example of a paid editor arguing that "peer review is not mandatory" because of the current wording. However, it must be clear that removing incorrect information about living persons is always allowed, and that doing so is exempt from both the edit warring policy and the discussed COI guideline bullet point. ~ ToBeFree (talk) 23:40, 9 May 2020 (UTC)[reply]
ToBeFree, yes, non-controversial edits as provided by WP:COIU would not be prohibited. I have added a clarified version of the proposal below my original post. Best, Usedtobecool ☎️ 08:50, 12 May 2020 (UTC)[reply]
The last big thing related to COI editing I'm aware of was WP:TOUSL in January, in which the community very resoundingly asked the WMF to take legal action against Status Labs. @Doc James: you mentioned that you planned to share that discussion with the WMF board; if you feel like taking a break from COVID-19 stuff, could you catch us up on how that went? There is also some recent stuff happening at AFC (from Sulfurboy) and the Article Wizard (from me) about paid COI disclosure. I'm not well-informed enough on the policy to make a judgement here, but Dennis Brown's comments above seem reasonable; my general sentiment is that we may be close to reaching the limit of what we can do on-wiki, and that the more productive path may now be through WMF legal. {{u|Sdkb}} ^talk 00:11, 10 May 2020 (UTC)[reply]
- User:Sdkb Was raised, no formal response at this time in time that I am aware of. Apologies... Doc James (talk · contribs · email) 05:18, 10 May 2020 (UTC)[reply]
- Sdkb, I have added a hopefully clearer version of my proposal just below my OP. I don't think there is much else to miss other than the very small few sections linked in the proposal. So, I do believe you can form an informed opinion from reading the proposal alone. Best, Usedtobecool ☎️ 08:50, 12 May 2020 (UTC)[reply]
(Also, this is not about policy, but would there be any objections to me going and improving the usability of the disclosure instructions, adding a link that preloads the disclosure rather than making editors copy and paste? It'd look kinda like the process for adding a trophy userbox I recently implemented at our tutorial conclusion page. {{u|Sdkb}} ^talk 00:15, 10 May 2020 (UTC))[reply]
Although a lot of paid editing is problematic, paid editing isn't necessarily problematic. I think the current disclosure requirements adequately mitigate the risks, and that our existing policies are as good as they will ever be for handling problematic paid editing (unfortunately, not very effective, but no better than any alternative). --Bsherr (talk) 00:22, 10 May 2020 (UTC)[reply]
- I disagree. That is the equivalent of saying "Although a lot of dictatorships are problematic, dictatorships aren't necessarily problematic". We must avoid conflicts of interest even if they may do some good faith edits, just like we must avoid dictatorships even if they may do some good faith policies. --NaBUru38 (talk) 20:15, 10 May 2020 (UTC)[reply]
- Bsherr I am not proposing any sweeping changes with any ambition to fix the larger issues. I am seeking to clarify a rather, in my opinion at least, simple point, that nonetheless creates an awkward situation with paid editors who seek to wikilawyer instead of working within general community expectations. I have added a clarification to my original post, hoping it helps. Best, Usedtobecool ☎️ 08:50, 12 May 2020 (UTC)[reply]
I would endorse a proposal to change wording to unequivocally require paid editors to go through the AfC process when submitting new articles. I'm on the fence as to whether an outright ban on mainspace editing is likely to help much. _signed,Rosguill ^talk 03:37, 10 May 2020 (UTC)[reply]
@Rosguill: I'd support that. Even with NPP, I cannot imagine a situation where I'd be okay with a paid editor creating a page without going through the additional scrutiny of the AfC process. {{u|Sdkb}} ^talk 03:52, 10 May 2020 (UTC)[reply]

Rosguill, that is also my intention. Added a clarification to my original post above. Best, Usedtobecool ☎️ 08:50, 12 May 2020 (UTC)[reply]
I have zero issues with paid editing. I have a lot of issues with paid editors that bring serious WP:COATRACK or WP:NPOV issues. And since a lot of my time is dedicated to the AfC project, I've become particularly bitter towards said editors. The aforementioned reference by Sdkb was my suggestion that for AfC articles that are created by PEs that there be an easily visible temporary notice on the draft page that would be removed if and when an article is accepted. As it stands now a PE or COI editor only has to disclose on their userpage, and that can go unseen in the typical AfC process. I also have issue with some language in policies, particularly the word "should". See my convo with DESiegel [3] Sulfurboy (talk) 03:41, 10 May 2020 (UTC)[reply]
- Sulfurboy it does get tedious having to check the draft talk, then the creator's user and talk pages and then other significant contributors too. Yes, exactly, not all, but I am seeking to change a few of those fuzzy imperatives to definitive ones. Added my proposal Mark II at the end of my OP above. Best, Usedtobecool ☎️ 08:50, 12 May 2020 (UTC)[reply]
Paid editors who are making apparently good-faith efforts to comply with our disclosure and other policies should not be demonized, and marking their contribution in this way will only increase the pressure to omit disclosure and just hope to avoid being detected. I think it is counterproductive, and I oppose any such marking. I agree that COATRACK and NPOV violations need to be addressed and corrected, but this is true whether the editor is an employee or merely a fan of the subject. Indeed fans may well be more intransigent in POV-pushing. I think that Sulfurboy's proposal if I have understood it correctly, would be a mistake. DES ^(talk)_{DESiegel Contribs} 16:14, 10 May 2020 (UTC)[reply]
- DESiegel, in case yours was not wholly a response to Sulfurboy's proposal (indenting), I would like to clarify that I do not seek to change the status quo for good faith paid editors who are already complying with the community expectations. Here, by community, I am largely referring to WP:NPP and WP:AFC folks; it is widely understand in that area that paid editors are supposed to put their articles through AFC and propose substantial non-urgent mainspace edits at the talk page, but because the actual guideline is worded weakly, paid editors who don't want to, don't have to adhere by those expectations. My proposal seeks to eliminate that loophole for wiki-lawyering. I have added a clarification to my original proposal to hopefully make that clearer. Regards! Usedtobecool ☎️ 08:50, 12 May 2020 (UTC)[reply]
  - Usedtobecool, It is my viewm that to make an AfC review mandatory, for any editor or group of editors, under any circumstances at all, would be to damage what reputation AfC has left, and to harm its value for its actual purposes, helping inexperienced editors to create valid pages. At hte very lest, paid ewditors should have the option of seeking an individual non-paid editor in good standing to do a one-on-one review of a draft outside the AfC framework as an alternative to going through AfC. Any proposal, which makes AfC mandatory I oppose as strongly as i can. DES ^(talk)_{DESiegel Contribs} 12:19, 12 May 2020 (UTC)[reply]
The only realistic way to remove paid editing and the problems associated therewith is to increase the limit of edits required for new article creation to mainspace. 1500 mainspace edits and 6 months time (above extended) should be used. The number of articles that are being added by ~10 edits and go COI accounts will become zero. There are no VITAL articles that have not been written. So if an article incubates in Draftspace, there is no emergency need to create it at once. It is not like we are lacking the articles on the states of USA that need to be created asap. Most vital work is done and we have prolific article creators. The argument that we need new editors does not work on this scenario as most (99%) of these ~10 edits and go writers just create one article and then leave, so leaving the bar low is not inviting new editors, it is just creating a mess. MistyGraceWhite (talk) 19:33, 10 May 2020 (UTC)[reply]

+1 to User:MistyGraceWhite. — Preceding unsigned comment added by Mccapra (talk • contribs) 15:55, 10 May 2020 (UTC)[reply]

I can think of no better way to ensure that we cease to get new editors than to adopt the above proposal by MistyGraceWhite. I would strongly oppose it if it were seriously proposed, and I doubt that the Foundation would allow it to be enacted and take effect. It would certainly mean that Edit-a-those, many of which are focused on creating new articles, (and for which I routinely grant confirmed status on the spot) would have to cease or drastically change. DES ^(talk)_{DESiegel Contribs} 00:31, 11 May 2020 (UTC)[reply]

@User:DESiegel I may be wrong. I have not seen any data from editathons. Is there any data which is available for non admin editors to see from editathons. I would like to specifically see the number of new editors with >2000 mainspace edits that have started editing from editathons. I find it odd that an editor MUST get their article onto mainspace at once. What is the rush? Anyhow, can you give out the data from editathons on new editors who have become part of the project? MistyGraceWhite (talk) 00:37, 11 May 2020 (UTC)[reply]

MistyGraceWhite most edit-at-hons, or at least the ones I have attended, (which are linked on my user page) record the list of attendees, and the articles created or changed. But if there is a central compilation of these results I do not know where it is. It would be possible to use individual event reports to compile such data, but rather tedious. So no, I cannot provide such data off-hand. DES ^(talk)_{DESiegel Contribs} 00:45, 11 May 2020 (UTC)[reply]

@User:DESiegel without this data, how can we actually evaluate the impact of editathons on the project? I mean if editathons in their current form are not bringing in any new editors who help wikipedia, then why fight to keep that form intact? MistyGraceWhite (talk) 00:50, 11 May 2020 (UTC)[reply]

That is a different question, MistyGraceWhite, and one more properly addressed to those who organize such events. It is my belief, without having attempted to analyze data, that such events are good for our overall reputation and a better understanding of what Wikipedia is, whether they bring in large numbers of new editors or not. I also suspect that the editors they do bring in are valuable, but again i can't prove this. DES ^(talk)_{DESiegel Contribs} 02:21, 11 May 2020 (UTC)[reply]

I think the question misses the boat in another way as well, by focusing on new-editor-at-editathon retention. Even if zero of those newbie editors ever return, let alone reach several K mainspace edits (lack of gain for our long-term editor pool), and even if there is no reputational aspect (lack of gain for Wikipedia site and movement), edit-a-thons often create viable new articles (gain for our readers). DMacks (talk) 04:20, 11 May 2020 (UTC)[reply]

I disagree in the strongest possible terms about Misty's suggestion. It seems a real case of cutting off your nose to spite your face. Given we'd have to create a new userright, I can't imagine the WMF would be particularly obliging. I wouldn't even support EC. If there was some intermediate option I might consider that, but the community has indicated a firm opposition to expansion of protection/permission levels Nosebagbear (talk) 08:24, 11 May 2020 (UTC)[reply]

I agree completely with every comment DESiegel has made in this discussion. The problem is not paid editing or paid editors, the problem is breaches of the content policies (NPOV, etc). The two groups "editors who are paid to edit" and "editors who make harmful changes to the encyclopaedia" are overlapping sets, one is not a subset of the other (and the same is true for more specific types of harmful edit). We should never prohibit any editor from reverting obvious vandalism, correcting obvious BLP errors, etc. Thryduulf (talk) 10:11, 11 May 2020 (UTC)[reply]
@Thryduulf: I have added a clarification to my original post above. Sorry for the misunderstanding; the proposal doesn't seek to outright prohibit all mainspace paid contributions, just the non-urgent substantial ones. Best, Usedtobecool ☎️ 08:59, 12 May 2020 (UTC)[reply]

pinging Thryduulf. Usedtobecool ☎️ 09:07, 12 May 2020 (UTC)[reply]
@Usedtobecool: I still oppose that. While it is right to discourage paid editors from making substantial contributions to mainspace, outright prohibiting it in all circumstances will not benefit the encyclopaedia. Examples include implementing a discussed consensus, clearly non-controversial changes such as accessibility improvements, reference fixing, etc. that might be regarded as "substantial". Paid editing is not synonymous with POV editing. Thryduulf (talk) 09:56, 12 May 2020 (UTC)[reply]
I would support a wording change from "you are very strongly discouraged from editing affected articles directly" to "you must not edit affected articles directly, except when your edits are unambiguously uncontroversial", which would draw a far clearer distinction between acceptable and unacceptable edits (and there is always WP:IAR for edge cases).

I am strongly opposed to Misty's proposal to raise the editing threshold for article creation, which is far too broad and would cause too much collateral damage to good-faith article creation. However, if it were modified to solely focus on a narrow subject area which proves overwhelmingly likely to contain poor article creations by new editors with a COI, I might support it. For example, if it could be shown that 95 of every 100 articles by new editors on, for instance, live businesses that began operating under three years ago were excessively promotional, then a requirement for AfC review before an article on a topic meeting the criteria could appear in mainspace would make sense. – Teratix ₵ 12:36, 11 May 2020 (UTC)[reply]

Teratix that is exactly what I intended to convey. I am not seeking any changes to WP:COIU. I have added a clarified version of my proposal to the bottom of my original post. Regards! Usedtobecool ☎️ 08:50, 12 May 2020 (UTC)[reply]
The problem with the modified wording is that it gives the impression WP:COIU is a comprehensive list of scenarios where paid editing in mainspace is acceptable, which, as Thryduulf's above examples of acceptable paid editing in mainspace not technically covered by COIU show, is not actually the case. – Teratix ₵ 01:42, 13 May 2020 (UTC)[reply]
I would support both proposals under "Clarification One". The current phrases, "you are very strongly discouraged" and "you should", are functionally equivalent to "you may" when it comes to enforcement. The proposed phrases, "you must not" and "you must", actually have teeth. — Newslinger talk 11:27, 12 May 2020 (UTC)[reply]
- The current wording is correct: there are circumstances in which they may make those edits, because doing so improves the encyclopaedia. Completely prohibiting all such editing would be to the strong detriment of the project. Thryduulf (talk) 13:23, 12 May 2020 (UTC)[reply]
  - I disagree with respect to the first bullet point ("...editing articles directly") and strongly disagree with respect to the second bullet point ("...Articles for Creation (AfC) process instead of creating them directly"). {{Request edit}} is available for paid editors who wish to make changes to articles, although Teratix's suggestion ("except when your edits are unambiguously uncontroversial") is reasonable and resolves most to all of the circumstances you're referring to. I see no reason that paid editors should create articles directly in mainspace, instead of having them vetted through AfC. The AfC process works very well for maintaining article quality in the presence of a conflict of interest. — Newslinger talk 02:37, 13 May 2020 (UTC)[reply]
    - Once again though you seem to be conflating "paid editing" and "POV editing". They are not the same thing - while paid editors have a clear COI regarding the person or organisation who paid them, that doesn't necessarily translate to POV editing or that the conflict extends to every edit (e.g. when a paid editor reverts obvious vandalism their and our interests align perfectly). Additionally, I'm not sure where you get the idea that I'm opposed to AfC, given that I've never mentioned it? My opposition is to blanket prohibitions that will not only not help the encyclopaedia and actually hinder it by making it more likely that paid editing will be undisclosed. Deal with the problem content, not the method used to create it. Thryduulf (talk) 11:13, 14 May 2020 (UTC)[reply]
The larger point, and one that seemed to be missing, is the fact that the stricter you make the rules, the more you push paid editing into the shadows, where you have NO control. If anything, it makes it more profitable. No rule or rule change will make paid editing go away, there is simply too much financial interest in it. Again, making rules so we can say "so at least we tried" tend to backfire, badly, and in this case will overload SPI even more than it is. Dennis Brown - 2¢ 14:27, 12 May 2020 (UTC)[reply]
We can accept that unwelcome practices such as vandalism and sockpuppetry will never be totally suppressed while still endorsing and enforcing policies and guidelines which prohibit such practices. Why not for unacceptable paid editing? – Teratix ₵ 01:42, 13 May 2020 (UTC)[reply]
We already have policies and guidelines prohibiting unacceptable paid editing, nobody is proposing to remove them. The problems we have currently are from those that do not follow the existing rules so making it harder for those to be followed will just mean fewer people follow them while doing nothing about those that already don't - i.e. it would make things worse. Thryduulf (talk) 10:15, 13 May 2020 (UTC)[reply]
I can't see how the proposed changes will make it any harder to follow the paid editing policies. – Teratix ₵ 03:15, 14 May 2020 (UTC)[reply]
Upon reflecting on this more, I think it's chasing after the wrong problem. COI-related difficulties generally come from the editors that don't self-disclose, so changing the rules for the ones that do doesn't help (and I'm not sure paid editors are significantly worse than editors who are self-promoting or writing about their friends). _signed,Rosguill ^talk 03:27, 13 May 2020 (UTC)[reply]

Smartest thing I've heard in this discussion. Dennis Brown - 2¢ 19:42, 13 May 2020 (UTC)[reply]

@Rosguill and Dennis Brown: We seem to be on similar wavelengths. I'll highlight in case it got buried that Doc James replied to me above that WMF does not seem to have delivered any response to the 100+ editors who asked nearly unanimously for WMF Legal to take action against Status Labs back in January. How about we head over to our new WMF pump page and start talking about that? {{u|Sdkb}} ^talk 10:48, 17 May 2020 (UTC)[reply]

Update: I've started a discussion at the WMF page. {{u|Sdkb}} ^talk 19:35, 22 May 2020 (UTC)[reply]

I strongly oppose MaisyGraceWhite's proposal. First, it will immediately drive new editor retention down to near zero. Second, it goes against the basic principles of Wikipedia as an encyclopedia that anyone can edit, which includes creating new pages. Third, coverage on Wikipedia is still frightfully thin or even nonexistent especially in topics affected by systemic bias. CJK09 (talk) 15:40, 24 May 2020 (UTC)[reply]

Notability beauty pageants

There is no guideline for notability of beauty pageants. Wikipedia:WikiProject Beauty Pageants/Notability (beauty pageant participants) was an attempt to create such a guideline, but I am not sure why it fizzled out. As of now a huge number of pages in this category have been created which may or may not meet GNG as it is entirely a matter of perspective. Specific concerns in this matter are;

Is a person notable just for participating in a pageant? If so what type of pageant confers notability, a national level? or a state level? or an international level pageant?
What defines a national level pageant? or an international one? Who establishes the fact that a certain pageant is truly international? There are dozens of pageants that have international attached to their name, yet they are of not noteworthy.
Is a single time winner of a national/international pageant considered to have passed GNG according to the AWARD guideline or should they be classed under SINGLEEVENT?
what type of pageants can have their own articles?

I would like to invite the community to discuss this and come up with a policy WP:PAGEANT that can be quoted in discussions as an inclusion criterion for pageants and contestants. MistyGraceWhite (talk) 19:24, 10 May 2020 (UTC)[reply]

From my limited understanding of beauty pageants (which comes mostly from patrolling articles about them, and not due to any off-Wikipedia familiarity), there's "international" pageants that are nevertheless small-scale productions with limited notability. I think that if an SNG were to be drafted for this subject, the criteria would likely need to name specific pageants that actually represent the most prestigious competitions. _signed,Rosguill ^talk 20:39, 10 May 2020 (UTC)[reply]
It looks like Wikipedia:WikiProject Beauty Pageants/Notability (beauty pageant participants) was located in draftspace and marked as a failed policy proposal until a little over a week ago, when Zanimum removed that tag without edit summary and moved the page out of draftspace. What's up with that? I also recall there being some other discussion on beauty pageants not too long ago, but I forget where. Is there other context we should have here? {{u|Sdkb}} ^talk 20:57, 10 May 2020 (UTC)[reply]

That draft was created after a series of AfD discussions about individual pageant contestants, winners and pageants themselves. Discussion at the Wikiproject level tended toward the opinion that there shouldn't be a pageant-specific SNG and that SNG's were a bad idea anyway. This meant that the proposal failed to gain consensus and was abandoned. I marked the proposal as failed and left it in draft for historical reasons. Hasteur apparently saw an abandoned draft and marked it for speedy deletion seven months later but it was not removed at that time. Zanimum apparently saw an over two-and-a-half CSD tag and took the actions they thought appropriate. It is still a failed proposal but new discussion may reach a different consensus. The previous discussion can be found at the project talk page archives. Similar older discussions include this one and this one. The end result is that beauty pageant contestants and pageants tend to get held to the general notability guideline at AfD. I hope this helps. Eggishorn (talk) (contrib) 17:08, 11 May 2020 (UTC)[reply]

Proposals should be drafted in user or project space (moved to the latter when ready for discussion if not there already) and failed ones left there appropriately marked. Draft space is for the drafting of articles, and anything that isn't one will likely get speedily deleted and the history lost. Thryduulf (talk) 19:33, 11 May 2020 (UTC)[reply]

Absent further discussion, I'm going to mark this as historical. It never was broadly accepted as a guideline for usage and leaving it as-is might cause confusion that this is a valid standard. Eggishorn (talk) (contrib) 18:22, 13 May 2020 (UTC)[reply]

Preventing Wikipedia's Misuse as a Military Propaganda Engine

Duplicate of Wikipedia talk:Featured article candidates#Preventing Wikipedia's Misuse as a Military Propaganda Engine –Deacon Vorbis (carbon • videos) 17:39, 11 May 2020 (UTC)[reply]

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.

As a community we must raise vociferous objections to topics of militarism, atrocity, and warfare, given their misuse for warmongering, propagating history over herstory, chronicling institutions of murder over the societies they massacre, and the glib transformation of Wikipedia into a military propaganda engine for white westerners. Given that Wikipedia is suffering a verifiable deluge of military propaganda (8 Featured Articles in January, and 5 Featured Articles each in the months of February, March, and April 2020 alone), I propose that we as the Wikipedia community limit Featured Articles on military subjects to absolutely no more than one per month, if not one per year, and that if an article on a military subject is permitted in a given month, the Wikipedia community will mandate the inclusion of at least one Featured Article on a major global peace movement in that given month. I exhort the Wikipedia community to be vigilant and not let this treasure of public knowledge be misused by white supremacists, western militaries and institutions of death, nor extend the reach of their propaganda. — Preceding unsigned comment added by Herantifastory (talk • contribs) 17:14, 11 May 2020 (UTC)[reply]

Well, I, for one, welcome our new white westerner overlords. –Deacon Vorbis (carbon • videos) 17:23, 11 May 2020 (UTC)[reply]

Well, Herantifastory, you could improve some other articles to FA status rather than posting the same rant on 10 different talk pages (most of them archives). That would be more effective. Cabayi (talk) 17:30, 11 May 2020 (UTC)[reply]

(edit conflict)See WP:RIGHTGREATWRONGS. I believe that there are potential conversations to be had about NPOV issues relating to military issues on Wikipedia (for instance, militaries seem inclined to release a lot of COVID-19 photos under free licenses, so a disproportionate number have been making their way into COVID-19 articles), but that's not likely to happen here. Someone speedy close this, please. {{u|Sdkb}} ^talk 17:42, 11 May 2020 (UTC)[reply]

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

Indefinite Blocking Policy

I agree with the need to have the option of indefinitely blocking a user from using the website. However, I feel that after five years has gone by, the block is no longer needed, especially in the case of users who made massive contributions to the website. Let's let some of the old users out of the cage. They probably won't be expecting their release and may not even realize it. But the point of Wikipedia is not to exercise the power to block people- the point of Wikipedia is to make an encylopedia. In 2015, User:Billy Hathorn was blocked for massive copyright violations. The user is also in the top 300 editors by number of edits on Wikipedia. Let's imagine that the person is still interested in editing Wikipedia one day: do you think the person has learned their lesson? I don't know all the details of this user's case, but I'm just saying that a permaban may be "justified" but it is not necessarily conducive to producing the best encylopedia. If you let some of the blocked users that made massive mistakes but also some good contributions out of their cages, they might be able to make productive contributions. If they mess up again, just ban them again- simple as that! That's my opinion. I know it probably won't get anywhere, but I think the concept of permabanning people here is excessive except in the case where every edit a user makes is reliably deleterious to the goal of making an encyclopaedia. Geographyinitiative (talk) 12:06, 12 May 2020 (UTC)[reply]

"Indefinite" does not mean "permanent". Anyone subject to an indefinite block can explain why they should be unblocked and if that explanation is judged to be acceptable they will be unblocked. And what makes you think that doing loads of edits is a way to produce the best encyclopedia? In some cases it has been that the user in question has made loads of edits that make the encyclopedia worse. Such thinking led to one editor only being desysopped recently by Arbcom even though it had been obvious for well over a decade that this person's prolific admin actions were detrimental to Wikipedia. Let's look for quality rather than quantity. Phil Bridger (talk) 12:22, 12 May 2020 (UTC)[reply]

Putting that aside, with any case that's 5 years old, it would hardly be that difficult to make an unblock request if they were interested in doing so. It seems a very niche group of editors who: were an appreciable positive; have a 5-year old indef; at some stage will want to edit again with that account; can't/don't want to make an unblock request. Nosebagbear (talk) 13:23, 12 May 2020 (UTC)[reply]

No one is blocked from using this website by us, the only people blocked from using this website are people who live in or access the internet through countries, households or organisations that ban access to Wikipedia. We block people from editing this site, not from using it. Everyone is welcome to use this site as a reader, but we reserve the right to withdraw editing privileges. Most indefinitely blocked accounts are never going to be unblocked, even if the editor wanted to edit within the rules, why expect a twenty something to resume with an account that was banned for vandalism when they were a child? If there was one change to the policy that I would most strongly support it would be to say that if you were blocked before your 18th birthday, you are welcome to create a new account two years after your previous edit. Ϣere SpielChequers 11:43, 13 May 2020 (UTC)[reply]

WereSpielChequers, I generally agree, but there is at lease one minor who in my opinion should be talking to law enforcement based on some of their actions here. There’s the idiot kids making penis jokes that frankly I don’t care about, and then there are the really messed up kids who engage in cyberstalking their “enemies” on this site. I don’t want the latter back, no matter how long it’s been. TonyBallioni (talk) 16:24, 13 May 2020 (UTC)[reply]

The relevant policy you seek to amend is Wikipedia:Blocking policy#Indefinite blocks, which states in its entirety:

An indefinite block is a block that does not have a definite (or fixed) duration. Indefinite blocks are usually applied when there is significant disruption or threats of disruption, or major breaches of policy. In such cases an open-ended block may be appropriate to prevent further problems until the matter can be resolved by discussion. It is designed to prevent further disruption, and the desired outcome is a commitment to observe Wikipedia's policies and guidelines, and to stop problematic conduct in future.
Indefinite does not mean infinite: an indefinitely blocked user may later be unblocked in appropriate circumstances. In particularly serious cases in which no administrator would be willing to lift the block, the user is effectively banned by the community.

Looking at the text of this policy, I think it provides a pretty clear avenue for how indefinitely blocked users may return. If they appeal their block and manage to convince us through discussion that the block is no longer necessary to prevent disruption, they will be unblocked. Other relevant essays on this include Wikipedia:Guide to appealing blocks and Wikipedia:Standard offer. Mz7 (talk) 18:55, 13 May 2020 (UTC)[reply]

Mass enabling of talkpage archiving

Please see Special:Contributions/Philoserf (example). Thoughts on this? Those talkpages will probably have 1 or 2 threads for years to come, I don't see why the need for such forced archiving. This is not a complaint, and I'm posting here because I couldn't find any policy for/against this (but I certainly am against). Ping to User:Philoserf; please hold those edits until there is feedback? Reh man 02:42, 13 May 2020 (UTC)[reply]

Rehman, will do —¿philoserf? (talk) 02:45, 13 May 2020 (UTC)[reply]

Rehman, now there is someone following me deleting conversations. Weird. —¿philoserf? (talk) 03:48, 13 May 2020 (UTC)[reply]

Mass changes of any kind without prior discussion is highly undesirable. Infrequently used talk pages should be left alone until a central discussion says otherwise. Johnuniq (talk) 04:32, 13 May 2020 (UTC)[reply]

Should those edits be reverted? Reh man 06:04, 13 May 2020 (UTC)[reply]

In my opinion it's a non-issue. Leave the already modified talk pages as they are but inform Philoserf that archiving shouldn't be done for infrequently used pages (a new post every few months or so would be the bare minimum for me). Anarchyte (talk • work) 06:14, 13 May 2020 (UTC)[reply]

True. Although I'm leaning towards reverting as they look cluttered. I.e. in the example above, the talkpage already has {{Talkpage header}}, which would display the archives if available. And I've just noticed {{Friendly search suggestions}} and {{Annual readership}} has also been mass added. While it may be useful to some articles, I don't see the practicality of mass adding those to talkpages in this manner. Reh man 06:40, 13 May 2020 (UTC)[reply]

I was deleting "External links modified" sections from otherwise empty talk pages, which I'm allowed to do, to prevent them from being archived and creating useless archived pages. * Pppery * _{it has begun...} 17:36, 13 May 2020 (UTC)[reply]

If archiving is set up, it should leave a minimum number of threads on the page like at least 3–5. For that archive client, it would be set by |minkeepthreads=.—Bagumba (talk) 08:59, 13 May 2020 (UTC)[reply]

Thank you all for the feedback. I learn each time I encounter an editor with an opinion.

Context

As I learn my way around, I have been visiting as many pages as possible. Observing the condition of the page, the talk page, and editorial interactions on these. I often make some small improvement and watch the page for editorial reactions. In this way I have learned a lot in just a little bit more than two active months here.

What I was finding in talk pages

I had seen a lot of pages with leading comments without title, often without signature. These, of course, acted as a lede and blew up the TOC. I had seen a jumble of talk page headers, warnings, markers, and other cruft in various mixed orders and styles. I also found misconfigured archive bot settings too.

What I intended

I thought that by adding friendly search suggestions and page views a new editor’s experience could have a bit of guidance and information about the article. I thought a conversation archive would help by moving crufty old conversations out of the way. Finally, I thought that by adding these as a prophylactic to pages that have been rarely updated we might get editors engaged.

Lesson learned

There are more views of what a talk page should be than I imagined.

Result

I will be more careful in any talk page updates I may offer and I will set retention so that a few old conversations remain when I do setup archiving. —¿philoserf? (talk) 17:55, 13 May 2020 (UTC)[reply]

Usage of the UserboxCOI template

Template in question: {{UserboxCOI}}

So far, this has been a good little tool for dealing with COI users. However, a routine search revealed that there are about 260 transclusions outside of userspace. I glossed through most of them, and it seemed that a good amount of these are in user talk space. Some of these are in the COI editor's user talk, while some are in more experienced users', when the COI editor was corresponding and put a COI tag there. Most of the remaining are in draftspace; I am working on removing them. I am raising a few questions:

should the COI template categorize userpages into, for example, Category:User pages with Conflict of Interest declarations?
should the COI template warn users when placed in the wrong namespace (like the {{Afd}} template)?
should the COI template categorize such templating mistakes into a tracking category, with an option to exempt (to keep an archive of past discussions)?

Thanks. Eumat114 formerly TLOM (Message) 14:00, 14 May 2020 (UTC)[reply]

Should we bring back the in wrestling section?

I mean it been there for years now — Preceding unsigned comment added by The Awesome Guy in the world (talk • contribs) 10:40, 15 May 2020 (GMT)

@The Awesome Guy in the world: Did you mean to post this elsewhere? Anarchyte (talk • work) 09:38, 15 May 2020 (UTC)[reply]

@Anarchyte: I just seen the archives and I saw the should we remove the in wrestling section? I’m sorry if this the wrong section to post The Awesome Guy in the world (talk • contribs) 10:40, 15 May 2020 (GMT)

If you're referring to this little discussion Wikipedia:Village_pump_(policy)/Archive_145#Should_the_"In_wrestling"_section_be_removed_from_professional_wrestling_articles? I'd say HECK NO. Consider Fandom (website) or something. Gråbergs Gråa Sång (talk) 15:26, 15 May 2020 (UTC)[reply]

Considering the discussion had a clear consensus I see no reason to restore it unless there is an extremely compelling reason to do so.--69.157.254.64 (talk) 05:30, 16 May 2020 (UTC)[reply]

Template:Infobox person, Net Worth and Death

This may be in the wrong place, so bear with me and advise where to post if it is with my apologies.

I have tried searching around but cannot locate any good consensus regarding a matter which I recently got reverted for five times.

In regards to {{Infobox person}}, a category exists Category:Infobox person using certain parameters when dead which is added to an article when the {{{death_date}}} or {{{death_place}}} params exist but also a {{{salary}}} or {{{networth/net_worth/net worth}}}. Net worth states In personal finance, net worth (or wealth) refers to an individual's net economic position; similarly, it uses the value of all assets (long term assets) minus the value of all liabilities. - a dead person doesn't have any assets or liabilities.

Even the documentation for the template states Current estimated net worth, if relevant. for that parameter. Looks like there was some attempt to gain consensus on the talk page for the template, but that didn't get far.

Therefore the question I'm looking to gain consensus on here is should {{{salary}}} and/or {{{networth/net_worth/net worth}}} be removed if {{{death_date}}} and/or {{{death_place}}} exists and is a valid entry?

- Rich^T|C|E-Mail 22:22, 16 May 2020 (UTC)[reply]

FWIW, I noticed an infobox for death was created late last year. Template:Infobox death —¿philoserf? (talk) 22:28, 16 May 2020 (UTC)[reply]

Perhaps it would be better if salary or net worth mentioned the date of that particular reporting in the infobox? If it's cited well, it should be in reference to a specific time in which that salary or net worth was current. bibliomaniac 1 5 22:32, 16 May 2020 (UTC)[reply]

The net worth being cited is another can of worms which I'm not going to get in to here - Rich^T|C|E-Mail 23:10, 16 May 2020 (UTC)[reply]

No Even if a person is dead their last known net worth before perishing is still worth noting in the infobox. For example it is worth noting that John D. Rockefeller was worth US$418 billion (in 2019 dollars; inflation-adjusted) in 1913 whilst he was alive. Regards Spy-cicle💥 ^Talk? 22:40, 16 May 2020 (UTC)[reply]
No in addition to what I said here, one's earnings can be a defining trait whether dead or alive. People like John Jacob Astor (one of the reverts I made that was linked above), John Davison Rockefeller (who Spy-cicle mentioned), Andew Carnegie, and Cornelius Vanderbilt are all well known for being highly wealthy. SNUGGUMS (talk / edits) 00:34, 17 May 2020 (UTC)[reply]
No though editors should try to find the sourced value that is closest to the date of death, and consider applying standard WP inflation adjustment to current dollars. UnitedStatesian (talk) 04:16, 17 May 2020 (UTC)[reply]
No. As always, we are summarising what is reported in reliable sources, and for billionaires and other wealthy individuals, their networth is the subject of considerable media attention. For example, today sees the publication of the 32nd edition of the Sunday Times Rich List, a 100+ page report on the 1000 wealthiest people in the UK. Rich_Smith, as it looks unlikely that you will get support to remove "net worth" from infoboxes, please stop removing it, and restore it to any articles where you have taken it out. Edwardx (talk) 11:27, 17 May 2020 (UTC)[reply]

@Edwardx: I think you are missing the point of this, I'm only concerned with net worth with a person that has died (and where {{{death_date}}} and/or {{{death_place}}} is present and valid in the infobox)... not those still alive which I believe is what your reply was aiming at - - Rich^T|C|E-Mail 13:17, 17 May 2020 (UTC)[reply]

Rich_Smith, I do get that you are only seeking to address the infobox net worth issue for those no longer living (ie non-BLPs). Mention of the Sunday Times Rich List was only to highlight the media coverage that net worth matters receive more broadly. And you do appear to be missing my point that one should not seek to make changes (ie removing "net worth" from infoboxes of non-BLPs) BEFORE getting consensus to do so, rather one should wait and only do so if and when such a consensus is achieved. Edwardx (talk) 18:47, 17 May 2020 (UTC)[reply]

@Edwardx: I was working under the impression that as Category:Infobox person using certain parameters when dead exists and is displayed on the bottom of Template:Infobox_person/doc#Tracking_categories that consensus was reached at some point... albeit not able to find it when I was reverted, although someone did ask but got no response - Rich^T|C|E-Mail 21:13, 17 May 2020 (UTC)[reply]

A couple of things stand out in this post. Firstly, it is not true that "a dead person doesn't have any assets or liabilities". The whole procedure of probate is concerned with a dead person's assets and liabilities, known as their estate. Secondly we usually only get a reliable figure for anyone's net worth after they have died. I would have thought that it would be obvious that these fields were for the figures at the time of death (or maybe at some previous time for salary of people who retired before they died), but as it doesn't seem so obvious to everyone then maybe something like "at death" needs to be added to their titles. The net worth of a dead person is just as much encyclopedic content as that of a living person. Phil Bridger (talk) 13:47, 17 May 2020 (UTC)[reply]

In which case maybe the suggestion that Pigsonthewing suggested here will be better? A "Value of Estate"? Of course the other question there is should there be a requirement for a source for that figure - Rich^T|C|E-Mail 21:13, 17 May 2020 (UTC)[reply]

No per Snuggums and UnitedStatesian, although the net worth should be accompanied by a date (whether the person is dead or alive), the most encyclopaedic point in time is not necessarily always going to be the date of death (or the current year if living), so I'd be opposed to hard coding anything specific in the label. The use of {{inflation}} where relevant should be encouraged but not mandated. Sourcing should always be highly encouraged. Thryduulf (talk) 22:35, 17 May 2020 (UTC)[reply]

Notable or noted?

FYI Wikipedia_talk:Notability#Notable_or_noted? — A question about the practical usage of the definition of 'notable' on Wikipedia — GhostInTheMachine (talk) 13:16, 17 May 2020 (UTC)[reply]

RfC: Source classification process

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following list:

Wikipedia policies and guidelines

When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

To increase transparency and robustness of the process for classification of sources, increase the review requirement for actions that prevent use of a source. This affects the list of perennial sources at the reliable sources noticeboard and also the spam blacklist. Guy (help!) 19:55, 17 May 2020 (UTC)[reply]

Add the following to the instructions for admins at MediaWiki talk:Spam-blacklist:

A project-level RfC is required when blacklisting any entry that is widely used as a cited source in articles (per {{insource|$SOURCEDOMAIN}}) other than those added by the spammer(s). The RfC may be initiated after addition to the blacklist where there is ongoing abuse, with the expectation that it will be removed if the RfC decides against blacklisting. RfCs should be registered using {{rfc|prop}} at Wikipedia:Reliable sources/Noticeboard

Opinions (Source classification process)

Support as proposer. Guy (help!) 19:55, 17 May 2020 (UTC)[reply]
Oppose as needless bureaucracy. If blacklisting will obviously be very controversial then have a big RfC, if the domain is only used by spammers just blacklist it already without any palaver. If it's somewhere between then just have a normal discussion and only move to a formal RfC if it is actually needed in that specific circumstance. As the proposal stands you're just asking for arguments about whether a source is "widely used" and whether any particular uses were technically "spammers" or not. Thryduulf (talk) 22:29, 17 May 2020 (UTC)[reply]

Discussion (Source classification process)

This RfC follows on from text suggestions made in Wikipedia:Reliable sources/Noticeboard/Archive 293 § RfC: Deprecation and blacklisting process, which closed on 10 May 2020. Guy (help!) 19:55, 17 May 2020 (UTC)[reply]

Oh christ, no. RSN gets enough RfCs as it is - at one point late on 15 May, there were no fewer than eighteen open RfCs at that one board alone. People are going to acquire what I might term "RfC blindness" so that they no longer either care or even notice. --Redrose64 🌹 (talk) 20:16, 17 May 2020 (UTC)[reply]

Redrose64, that's partly because people are opening RfCs for sources that someone used once, rather than for sources where it's worth having a serious discussion. Guy (help!) 09:34, 18 May 2020 (UTC)[reply]

Question Related to WP:CLOSE; One Specific Case

I have a specific example of which I am unsure if a non-admin archiving a discussion is appropriate. In this scenario on the spam whitelist talk page, an editor asked for one link to be whitelisted to use on an article that was recently deleted via RfD consensus. Since the spam whitelist talk page is primarily frequented by admins, is it appropriate for a non-admin to archive this discussion, as it is clearly unneeded now that the article has been deleted? Was just curious and thought this would be the appropriate forum to inquire on. Nanophosis (talk) 01:23, 18 May 2020 (UTC)[reply]

If the closure doesn't require admin action, and the closure is otherwise appropriate by that user, then yes, there's definitely no problem in a non-admin closing such a discussion. {{Nihiltres |talk |edits}} 19:31, 20 May 2020 (UTC)[reply]

The home_town parameter of Template:Infobox_person

FYI

– Pointer to relevant discussion elsewhere.

Please see: Template talk:Infobox person#Proposal: Repurpose and redocument the home_town parameter.

As I know that changes to major infoboxes are often controversial (and many to that template in particular have been WP:VPPOL RfCs in their own right), it seemed pertinent to notify this board of the proposal.

Summary: We removed |residence=, but kept this parameter for childhood non-birthplace residence, despite that being usually trivia. The proposal would repurpose this parameter for long-term residency places during the subject's period of notability.
— SMcCandlish ☏ ¢ 😼 21:11, 19 May 2020 (UTC)[reply]

Use of Infobox port

It seems that {{Infobox port}} has been used in what I would consider an incorrect manner. The template is deigned for ports but it seems to have been used on many multiple occasions for places such as Peace Arch Border Crossing which is not a port, but a port of entry, a subset of which may include some (many? most?) ports. One solution to this may be to fork the current template into a new one for ports of entry, remove the port-related parameters (draft/depth being the most obvious one) and then swap them over either manually, or using a bot if a list or category of them can be identified. Is that a reasonable approach to take? Could/should I be bold and do that? Or should it be discussed somewhere first? Fob.schools (talk) 13:38, 20 May 2020 (UTC)[reply]

Based on a quick look, I think those instances should be changed to {{Infobox border}}. Also, this discussion might be better off at a WikiProject talkpage. Reh man 14:06, 20 May 2020 (UTC)[reply]

Yeah, but which project?Fob.schools (talk) 14:30, 20 May 2020 (UTC)[reply]

If there's nothing more suitable, I'd post at Wikipedia talk:WikiProject Infoboxes. Reh man 15:00, 20 May 2020 (UTC)[reply]

Clarifying common practice ref inclusion

There's certainly consensus against the implementation of these proposals as a group in this way here, along with what I think is a moderately clear consensus against part 1 of the proposal (i.e. adding a suggestion to users that they might be able to either write themselves or facilitate an external source being written, then subsequently write an article based on that source). The response to the other two parts of the proposal is less clear-cut, but they should be discussed as separate proposals in the relevant venue(s) as discussed below, with clarity on what exactly is being proposed. Naypta ☺ | ✉ talk page | 22:26, 25 May 2020 (UTC)[reply]

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.

A group of editors and I have been discussing the issue of subjects which are already notable in their field, but have yet to be sufficiently noted as per our criteria.

I'm proposing three inter-connected clarifications of what I understand to be common practice here: someone complains that no article exists about a thing, we explain how it works - and that person happens to be in a position where they can legitimately help to make significant coverage happen to the satisfaction of our guidelines.

This clarifying of common practice:

facilitates simplicity of process
requires only small additions
does not seek to redefine any terms

My three-part proposal is that:

the WP:N page, under the "Notability requires verifiable evidence" section, should state:
Users who are in a position to encourage such independent recognition may be able to facilitate an already notable subject meeting the Wikipedia noted criteria where insufficient verifiable evidence currently exists, and could subsequently provide that new evidence by writing or requesting an article.
the main Help page should have a clear invitation to Request an article, either as its own section, or as a new section under Create a new article, pointing users directly at the Request an article page. It could offer additional encouragement:
You can request that one of our editors creates an article on a subject you feel meets our criteria for Notability. If you can provide evidence of this from reliable sources, that can help to faciitate a successful outcome.
the Request an article page could also make a statement as per #1, for those who only see this page, and be tweaked to do more to encourage proposers to provide evidence of notability. The current statement just doesn't go far enough, in my opinion, and propose this change:
Give a brief description, with links if possible, for the proposed topic, to aid others in ~~understanding your request~~ confirming that the subject should have an article of its own. Note that some subjects are more appropriately placed within the article of another subject for which they have significance.

The discussion which led to this proposal is on the Notability talk page. I've brought it here because it pays regard to three separate pages. (NB: I have not suggested editing Verifiability because it seems to me to be addressed to the people who will do the actual article creation, rather than those who are simply proposing an article. Happy to hear if anyone feels something should go in there too.)

For inclusion, I am tagging @GhostInTheMachine: whose observation of the difference between 'notable' and 'noted' instigated the discussion, and administrator @Masem: who made a significant contribution to the shaping of the resulting proposals. I am equally grateful to all who have already engaged and contributed, and will link to this proposal in our original discussion, and on the pertinent pages above. -- BessieMaelstrom (talk) 13:55, 22 May 2020 (UTC)[reply]

This looks like a non-starter to me, because it is based on a false premise. It is impossible for any subject to be notable if it doesn't meet the lower standard of verifiability. There seems to be a confusion here between the current state of an article, which is not an issue with either notability or verifiability, and the sources that exist, which are relevant to both. Phil Bridger (talk) 15:24, 22 May 2020 (UTC)[reply]
Hey Phil, thanks for this. I'm not sure I understand what you mean ref the current state of an article etc... can you say it another way, please? I see what you mean about the false premise, which I think was just me explaining it badly. I've edited to hopefully clarify the initial premise. -- BessieMaelstrom (talk) 15:38, 22 May 2020 (UTC)[reply]
I don't think I can put in in another way, because it's a very simple concept if you will only listen to what other people are telling you rather than stick to the same ideas, but I will try different words. Neither notability nor verifiabilty depends on what is currently written within an article. They are both concepts that apply to things (such as article subjects) that exist in the outside world rather than just in Wikipedia. Phil Bridger (talk) 16:11, 22 May 2020 (UTC)[reply]
I'd appreciate it if you can avoid making this be personal, Phil. I get that it's about being worthy of note in the outside world. Can I ask what is making you think I don't get that? I'm specifically talking about articles that do not yet exist, so I didn't understand your point about "the current state of an article". BessieMaelstrom (talk) 18:14, 22 May 2020 (UTC)[reply]
I don't think this is a good idea. A large proportion of people who come here to request an article or attempt to write one on a non-notable subject are trying to promote something; we don't want to encourage the idea that they can manufacture notability by writing their own sources. The minority of people who are in a position to write reliable sources on subjects that aren't currently notable (academics, journalists, etc.) presumably don't need our encouragement to continue doing their jobs. – Joe (talk) 15:44, 22 May 2020 (UTC)[reply]

I agree. We have enough spammers trying to get us to accept articles about topics that have only been written about by people with a conflict of interest. We certainly shouldn't be encouraging even more of this practice. We should cover topics that have been covered independently of any Wikipedia concerns. Phil Bridger (talk) 16:11, 22 May 2020 (UTC)[reply]

Joe, Phil, you're quite right, there will be people who think they can just write a blogpost about themselves. We should absolutely make clear that the WP:GNG still apply. Plus I didn't write it in a very accessible way. How about this?

Users who are in a position to encourage an independent article or review from a reliable source may be able to help a noteworthy subject meet the Notability Guidelines, and could then write or request a Wikipedia article.

We already have this very simple system whereby people can request an article, but it's pretty hidden to the uninitiated. As with everything, the more complex the path, the greater the impact on underrepresented groups.

As I said in the original discussion, small changes like this could give some a fighting chance against such things as the complexity of the user interface, or not being confident enough in your belief that the article belongs and worrying about experiencing rejection, or simply not having the time to figure it all out. It's no coincidence that these are also the top three in Sue Gardner's list of possible causes for gender disparity on Wikipedia.

I'm not suggesting that journalists and others need any encouragement to do their job, but their choices of subject matter can legitimately be influenced. Reviewers can be invited, journalists approached. The veil we are currently drawing to mask the doorway of article requests is also masking it from those who might just need that extra nudge.

Also, what's the worst that could happen? The requested articles list gets longer, but we already neatly divide it up into subject areas on several levels. Editors are likely to consider their smaller area of expertise, and suddenly those lists are a lot smaller.

Some people who found that simple doorway a far less intimidating way into Wikipedia might see their proposals not moving from the list, and look into it all a bit more, and maybe be inspired to edit. It could also be a doorway for that.

We are encouraged to be bold. We could be bold with this, and see what happens. Joe, Phil... who's with me?! --BessieMaelstrom (talk) —Preceding undated comment added 16:59, 22 May 2020 (UTC)[reply]

BessieMaelstrom, a minuscule proportion of our articles come through the article request system. The way to get more articles about under-represented topics on Wikipedia, such as those about women, non-Western topics, or "untrendy" topics that are not part of Anglophone popular culture, is for people to simply create the millions of such articles that can be done on the basis of reliable sources that already exist. That will be a much more productive approach than encouraging people to suggest topics for articles that will never be created anyway. BE BOLD. Phil Bridger (talk) 17:55, 22 May 2020 (UTC)[reply]

This isn't a proposal with the specific intention of solving that problem. It's a proposal to take a thing we already have and make it more visible, because it will help some people, an example of whom is underrepresented people whose work is on the edge of inclusion. A small amount of articles come through that doorway at least partly because we hide it. More people might follow the advice to be bold if we made the simpler path more visible. There are many ways to begin to address this complexity of problems, and this is one very easy one. I'm not suggesting we take out an ad in the Daily News. I'm suggesting we just make a bit more obvious than you can request an article, and that those who could invite someone to review work that isn't in here yet could think about doing that. -- BessieMaelstrom (talk) 18:25, 22 May 2020 (UTC)[reply]

Just wanted to add a quick note to all that I don't see this as a yes-or-no subject. We have a simpler doorway, and we also have the risk of flooding. My proposal is an attempt to make the doorway more visible and also help those who could be here to get here more easily. If my proposal doesn't hit those marks, let's talk about how we could hit those marks. BessieMaelstrom (talk) 18:42, 22 May 2020 (UTC)[reply]

I actually think that we would do better to remove any suggestion that requesting an article will actually lead to anything, because it will hardly ever do so. If someone wants there to be an article about a topic then the only way to get it is to do the work themselves, rather than ask some non-existent other editor to write it. Phil Bridger (talk) 19:46, 22 May 2020 (UTC)[reply]

This thread seems hopelessly muddled to me. Early on it states "Users who are in a position to encourage such independent recognition..." but later it suggest pointers to writing creating requesting a Wikipedia article. It says it's about "person happens to be in a position where they can legitimately help to make significant coverage happen to the satisfaction of our guidelines."

This makes a mishmash of the timeline of a proper Wikipedia article. Step 1, someone does something, something exists, or something happens. Step 2, reliable sources write about the topic. Step 3, the reliable sources come to the attention of a Wikipedia article. Step 4, the editor writes a Wikipedia article.

This proposal seems to be saying that if a Wikipedia article exists about a person, then the person is notable, so a Wikipedia article can be written about the person.

I feel this thread is so hopelessly confused that it should be closed. If there is any merit to the ideas hidden in the fog, a new proposal should be started. Jc3s5h (talk) 18:44, 22 May 2020 (UTC)[reply]

Hey Josh, thanks, that was helpful. I'm happy to clarify:

Step 1 - someone does something, something exists, or something happens that is actually worthy of note by somebody connected to a reliable source
Step 1a - that thing is in a state of being worthy of note (as considered by the World At Large), but not having been noted yet (in the World At Large)
Step 1b - a person nudges someone who can create a reliable source, possibly because we said "Hey, if you're really sure this is a thing the World At Large would think noteworthy, maybe you could nudge someone to look at it?"
Step 2 - they do nudge, and as it happens, they were right, and said reliable source writes about the topic
Step 3... etc

This is about the liminal space between notable and noted. (The original discussion is likely to be helpful too. Masem was very eloquent in describing this common practice.) -- BessieMaelstrom (talk) 19:06, 22 May 2020 (UTC)[reply]

Bessie, please just stop responding immediately to everything and have the courtesy to read and understand what everyone is telling you. We are not a bunch of chauvinists trying to slap down ideas from outsiders, but people trying to help you. On a minor point, what you describe in your last post is far from a common practice. I've been editing Wikipedia for well over a decade and have never seen anything like that happen. Phil Bridger (talk) 19:46, 22 May 2020 (UTC)[reply]

That's no minor point, Phil - it's about what I am actually proposing. I was empowered to make this proposal by the person who had observed that practice, but even if it's not common practice, my proposal still stands. This is about stuff happening pre-Wikipedia, so it's kind of impossible to know how much appropriate stuff might get through a more opened door until we more-open the door. I understand that there is a risk of flooding with inappropriate articles. If my proposal doesn't hit the marks, then I'm inviting collaborative suggestions for ways to encourage more qualifying requests without also exacerbating the COI problem... and maybe for ways to convert a Requestor into an Editor? Very happy to be pointed at the appropriate place for discussion, if this is not it. I'd really appreciate it if this didn't become personal, though. I have nothing but respect for all who attempt to do the impossible work that is caretaking this incredible archive of world knowledge, and even more challenging given that it is so fully collaborative. To my mind, the only thing that is personal here is how admirable it is to take that on, and I'm grateful for all contributions to this miniscule part of it. -- BessieMaelstrom (talk) 20:23, 22 May 2020 (UTC)[reply]

It does seem to me as though these are separate proposals that could be considered separately. Most of the discussion here seems to be about (1), and I oppose that per Joe Roe's first comment here. Wikipedia's role is to document knowledge that already exists, and guidance on how to establish new knowledge (i.e. get journalists to write about important topics that are not yet notable in Wikipedia's sense of the term) is firmly outside its scope. (okay, I guess I'll link to WP:RIGHTGREATWRONGS if I must) Proposals (2) and (3) seem fine to me, though. One question related to that that I've been wondering: how many articles listed at WP:Requested articles actually get created, and how long does it tend to take? My mostly uninformed hunch is that it may be largely a bottomless pit. {{u|Sdkb}} ^talk 20:04, 22 May 2020 (UTC)[reply]

Hey Sdkb. I was in there today whilst considering all this, and during that time I removed one blue link for something that had had an article created about it in my specialist subject. Looking through the rest, I can see a couple at a quick glance that I would have a go at converting into an actual article, and quite a few that I'd want to at least research. It's on my list as one of the areas in which I would like to do some maintenance. -- BessieMaelstrom (talk) 20:23, 22 May 2020 (UTC)[reply]

Of course, the list of requested articles may well include some objectionable / ridiculous / amusing / crazy suggestions, but it should also be seen as a rich source of input from the outside world. The request process needs to be simplified so that it is more available to non-editors. A way forward would be a wizard much like the Article wizard that captures extra detail such as a possible lead sentence and one or more sources. — Ghost in the machine ^{talk to me} 20:00, 23 May 2020 (UTC)[reply]

That's a great idea. Fancy sketching something out? I will happily work on it with you. -- BessieMaelstrom (talk) 22:51, 23 May 2020 (UTC)[reply]

@BessieMaelstrom and GhostInTheMachine: Revamping WP:Requested articles for usability sounds like a great task. Please feel free to ping me or post at WT:WikiProject Usability if you delve into that. The folks at WP:WIR might have some insights. {{u|Sdkb}} ^talk 22:14, 25 May 2020 (UTC)[reply]

I've really had enough of this discussion. My last words are that the "requested articles" feature will never be the source of more than a handful of articles, and I stand by my comment that any people who are serious about wanting articles should simply write them themselves, and that any generation of sources for the purposes of enabling a Wikipedia article has a vanishingly small chance of producing anything that is truly independent and reliable. Phil Bridger (talk) 12:19, 24 May 2020 (UTC)[reply]

I think this is opposed and done now, with thanks to all who responded. Two of you opposed the idea of making the current Submit an article section more prominent, and two of you supported that idea, with one suggesting it might benefit from a Wizard. So I guess that will be a different proposal. -- BessieMaelstrom (talk) 18:31, 24 May 2020 (UTC)[reply]

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

WMF Board Authorises Universal Code of Conduct and non-local sanctions of those who breach them

The WMF Board has just authorised the creation of a UCOC by the Foundation (presumably T&S) to create a UCOC, purely in consultation with the local communities, along with various other related facets, which are summarised below.

Developing and introducing, in close consultation with volunteer contributor communities, a universal code of conduct that will be a binding minimum set of standards across all Wikimedia projects;
Taking actions to ban, sanction, or otherwise limit the access of Wikimedia movement participants who do not comply with these policies and the Terms of Use;
Working with community functionaries to create and refine a retroactive review process for cases brought by involved parties, excluding those cases which pose legal or other severe risks; and
Significantly increasing support for and collaboration with community functionaries primarily enforcing such compliance in a way that prioritizes the personal safety of these functionaries.

Whatever our respective views on the issues are, I believe we've now reached the point where a co-ordinated Community viewpoint, rather than that of a few interested editors on meta, needs to be created so we are in a position to engage, or react, rather than attempting to coordinate on the fly.

I've just created a general discussion part below for an initial discussion, but I imagine it'll need spinning off into aspects and so on and so forth. Nosebagbear (talk) 22:23, 22 May 2020 (UTC)[reply]

Whatever our respective views on the issues are, I believe we've now reached the point where a co-ordinated Community viewpoint, rather than that of a few interested editors on meta, needs to be created so we are in a position to engage, or react, rather than attempting to coordinate on the fly
I disagree with this sentence basically in it's entirety. I've been in the minority on this project in regards to global/meta/Foundation issues in the past, and I think the local en.wiki community tends to overreact to things that aren't big deals and post-last year tries to turn everything into FRAM2.0. Because non-en.wiki specific stuff includes people from a lot of different projects it is often very nuanced, and I don't think having a single coordinated response that would inevitably have some broad strokes would do whatever the idea is justice. That includes not being able to identify any valid criticisms and address them in a fair way because of an overarching position.
So no, I do not want there to be an official en.wiki position. To my knowledge, I am still an active member of this community who is generally trusted by others. I also think that the tendencies of some on this project to see every move of the Foundation as the boogeyman coming to get us is over the top and unhelpful. I don't want to be associated with that.
If people want to raise their voices on meta, they can, but we absolutely should not be giving the weight of the entire English Wikipedia community behind a position that:

most active editors will never see or care about (most people don't care about this level of inside baseball)
that will have significant opposition on either side regardless of what the position is.

This project and community is not monolithic. We are a group of individuals and that is what makes us work. If people care deeply about this (as I'm sure many do), comment on meta. If you don't care enough to comment on meta. I don't want to be stuck with a coordinated position of driveby voters who don't actually engage long-term. TonyBallioni (talk) 22:36, 22 May 2020 (UTC)[reply]

This is a side issue, and not particularly relevantr to the primary issue

@TonyBallioni: I won't comment on Meta because of the homophobic behaviour of a WMF account I tried to deal with there. As they were defending homophobic behaviour by the Foundation, I saw little point in complaining. DuncanHill (talk) 22:41, 22 May 2020 (UTC)[reply]

That's a very strong accusation, and I'm sorry you feel that way. Could you please diff so those of us who aren't familiar with what you are discussing can evaluate the situation for ourselves? I'm also pretty confident many at the Foundation would want to address abuse from a Foundation account. TonyBallioni (talk) 22:41, 22 May 2020 (UTC)[reply]

(ec) It was an email. And if you want another strong accusation, then dismissing editors on this board as "driveby voters who don't actually engage long-term" is pretty poor too. DuncanHill (talk) 22:45, 22 May 2020 (UTC)[reply]

If your really interested, you could just look at my contributions on Meta. DuncanHill (talk) 22:48, 22 May 2020 (UTC)[reply]

Tony, I just had an alert from Meta. You've made your position pretty clear. I don't trust you to deal with this matter. DuncanHill (talk) 23:02, 22 May 2020 (UTC)[reply]

Yes I reverted sensationalism that you posted on a research page because you didn't like a bad piece of software with good intentions. Per the above, I've checked your meta history and found this. What I see is you being rude to WhatamIdoing for explaining to you that m:Research:Detox, which I agree was a horrible project, was intended well and that once it was discovered it was corrected. I haven't seen what they emailed you, but I suspect it was similar and likely was trying to explain that detox was trying to detect homophobic abuse and that the people who were creating the algorithm did it wrong. TonyBallioni (talk) 23:14, 22 May 2020 (UTC)[reply]

She sent me an email full of links to homophobic abuse, and told me to read them. I expect you'll tell me that was "well-intentioned" too. DuncanHill (talk) 23:35, 22 May 2020 (UTC)[reply]

I'm sorry you were offended by that material. In my childhood and young adulthood I faced similar bullying in school where people just assumed things and didn't actually care what my sexuality was or who I was as a person. I was just stereotyped. I care deeply about this issue as well.

At the same time, yes, if you're dealing with a tool that was intended to identify things such as homophobic abuse, then yes, I would expect emails about the tool to include links to homophobic abuse. That's how you build and deal with something like this. I'm not privy to the emails, but I've been a part of many discussions about identifying abuse on Wikimedia projects using automated tools. I've never once had someone think what you're describing is a tool behaving properly, but yes, people are going to try to dive through previous abusive content to see what the tool should be preventing. TonyBallioni (talk) 23:43, 22 May 2020 (UTC)[reply]

It wasn't material identified by the tool. She had a very limited knowledge of the tool, and indeed was (or seemed to be) getting more information about it from me than she was from WMF. It was just a random list of homophobia she had found when trying to say that classifying "I am gay" as an aggressive statement was not homophobic. I didn't ask to be sent it, and to be frank nobody with any sense of decency would have sent it. Do you send unsolicited links to anti-Semitic content to Jewish people who have raised a concern with you? I hope not, indeed I'm sure you don't and never would. "I'm sorry you were offended" is a textbook non-apology apology. DuncanHill (talk) 23:50, 22 May 2020 (UTC)[reply]

I don't see the point in continuing this conversation here. I won't be going to Meta and I have said why. It's a toxic environment. DuncanHill (talk) 23:52, 22 May 2020 (UTC)[reply]

This isn't inside baseball. It will affect everyone. SarahSV ^(talk) 22:57, 22 May 2020 (UTC)[reply]
- I get that view, but I also doubt it will have much if any impact on existing processes. I think anti-harassment is important, but after FRAM the foundation is very hesitant to do anything (for good reason.) Likely what you're going to see is a formalization of the norms they already use to global lock people who are already blocked on multiple projects. TonyBallioni (talk) 23:14, 22 May 2020 (UTC)[reply]
I think it's important for the range of views of enwiki editors to be made clear to the Foundation. I know that many weren't happy with the way Framgate happened, and I was one of them, but I'm currently trying to support a victim of bullying on another project, and I can see the value of the principles in that announcement. The likely problems aren't in the goal of a universal code of conduct (UCoC), but in the way that it gets implemented, and the more we can influence that to match our needs and expectations, the more likely it will turn out to be an improvement, not a burden. --RexxS (talk) 23:21, 22 May 2020 (UTC)[reply]
I don't think we're at the point where a co-ordinated Community viewpoint is necessary. As far as I'm aware, the WMF has not even proposed what a universal code of conduct would look like. Trying to discuss this now puts the cart before the horse, and prevents anyone from actually working toward a positive result. I think there is a real need for a baseline code of conduct for all Wikimedia wikis, because very few wikis have the codified conduct policy that enwiki does. This makes it more difficult to deal with even blatant incivility and harassment (see the amwiki situation last year). There are some things that are unacceptable on any wiki, and I think a global policy to handle that is important. I do think that the WMF could greatly improve Foundation-community relations during this discussion by committing to allowing wikis to replace the code of conduct with a sufficient policy and strong community consensus. --AntiCompositeNumber (talk) 23:28, 22 May 2020 (UTC)[reply]
Agree with AntiCompositeNumber. What exactly is the purpose of this VP thread? As far as I can tell the "UCOC" hasn't even been drafted yet. -FASTILY 00:37, 23 May 2020 (UTC)[reply]
@TonyBallioni: Tony, this may be one time I might have to disagree with you, if I understand what you're saying (and it's far from impossible that I haven't). I am personally very concerned about the WMF handing down diktats from above, when they're not on the front lines, actually editing on a day-to-day basis and facing the trials and tribulations that almost every Wikipedian has to confront. It's very easy to look down from on high and pontificate in a vacuum about ideal behavior, without experiencing what it's actually like to try to protect and improve a Wikipedia project from the onslaught of vandals, SPAs, CPOVs, not-at-all-civil POVs, children, jerks, assholes, and well-meaning fans. In the trenches, behavior is going to be a lot more brusque and direct than might be considered ideal in a utopian world, as we attempt to deflect these forces, while at the same time not running afoul of our community-based policies on civility and other behaviors. To have yet another layer of behavioral proscriptions imposed on us from a bunch of people even further removed from the realities of editing is a real concern for me, and -- I would think -- for other Wikipedians as well.
Is it your concern that we shouldn't respond to the WMF about their Universal Code of Conduct ("Universal"? Is conduct in Nepal really the same as conduct in Detroit?) or that we shouldn't coalesce around a single "community response" too soon? I, too, would like to avoid another Framgate, but not at the cost of having my views and those of others like me being ignored by the WMF. If I'm mistaken about what you're proposing, please straighten me out. Beyond My Ken (talk) 05:21, 23 May 2020 (UTC)[reply]
- Beyond My Ken, I have a more pro-WMF view than many on en.wiki because I have seen them do positive things both in terms of software (WP:ACPERM) and in their global actions (User:Til Eulenspiegel was globally banned by both the community and the foundation. After his community ban he socked and urged acts of violence against LGBT people. Basically the posterchild for Foundation action.)
  What I'm saying is that people like you and many other in this community do have legitimate concerns. I respect that, even if they are different from my views, and think that you and others should respectfully voice those concerns as individuals in dialogue with the Foundation to try to find a ground everyone can live with, but we've seen that this community can sometimes react rather kneejerk to anything the Foundation proposes (the recent rebranding thing on meta is probably the best recent example.) You'd likely get a consensus that was built of fear rather than an intent to work together, which is not something I want, nor do I think many reasonable community members. Letting people express their views individually can help make it so the largest Wikimedia Project doesn't have a statement like that, which I think would be a good thing.
  On the universal code of conduct and different geographies, as I said to Sarah, my gut tells me this is more about codification of things that have been ad hoc and isn't going to affect any major projects with the possible exception of pt.wiki, where there are other issues. The other thing is that on some small projects, this is 100% needed. See TI above: he basically owned a project and blocked a steward for telling him he couldn't block a user for having "Queer" in their username and then went on a socking spree cross-wiki. Abuse on small-wiki is not uncommon and stewards are very reluctant to do much about it for a variety of reasons. It has to get to the level where someone blocks a minority and then blocks a steward for intervening for something to be done. Giving the WMF more power to act when small wikis go haywire is a very good thing. TonyBallioni (talk) 05:48, 23 May 2020 (UTC)[reply]
  - Tony: I can see where the UCOC would be useful for smaller projects without community enforcement capabilities, but I think larger projects with a history of community-based policing of behavioral problems should be exempted, as long as that project's local policies generally follow the UCOC. Just as global sysops don't operate in the larger projects, and the role of stewarts is minimal in larger projects and more fundamental in smaller ones, T&S should concentrate on UCOC-enforcement on smaller projects, and not in larger projects, such as en.wiki. As projects become larger and more self-sufficient, they too can do their own behavioral policing and T&S/WMF can back off. Beyond My Ken (talk) 01:57, 24 May 2020 (UTC)[reply]

Discussion

Again, not relevant
As one of the worst pieces of abuse I've ever had was from a WMF account, and led to me abandoning Meta, I cannot "collaborate" with the Foundation. DuncanHill (talk) 22:34, 22 May 2020 (UTC)[reply]

RexxS, just to clarify, I agree with your statement generally. I'm just opposed to there being one en.wiki response. We should absolutely engage, but I think the diversity of our views on this topic are best reflected by individually commenting rather than a "community position" TonyBallioni (talk) 23:28, 22 May 2020 (UTC)[reply]
- I respect that view, Tony, but I disagree with it in some ways. If we were to seek consensus for a united response and found one that almost everybody could live with, then I think a single response would be appropriate. If we found a range of views that couldn't reach a single consensus, then maybe we could present a selection of the views that had the most approval. Of course, individuals are always going to be able to respond, but that method of self-selection isn't likely to lead to a representative view, IMHO. As a community, we're surely grown-up enough now to encourage participation from a much broader spectrum of editors and work out what we can agree on. --RexxS (talk) 00:41, 23 May 2020 (UTC)[reply]
  - A real consensus (something everyone can live with) is likely not feasible with so many people. However it may be feasible to compile lists of pros and cons that have significant support. isaacl (talk) 20:06, 23 May 2020 (UTC)[reply]
I feel that there are two paths: A) One where enwiki engages in good faith and with the expectation of compromise and people walk away mostly happy-or-unfulfilled, and then B) One where enwiki refuses to engage or assumes bad faith or assumes that the WMF will bow to their demands and no one on enwiki is happy because the WMF lays down some hammers and fingers get smashed and people wail and gnash their teeth and bans and blocks get handed out and there's lots of drama about it but the grinder continues on, unpurturbed. A is productive; B is not. I think the best thing is for the English Wikipedia to draft a statement of support for the WMF's efforts and thus be part of the team writing the rules rather than reacting to them.--Jorm (talk) 23:53, 22 May 2020 (UTC)[reply]
- Thing is, Jorm, nobody's going to disagree about what the rules should be: be nice to each other; no bullying; respect minority opinions, etc. The conflict will come when we try to figure out how to police those rules, and for enwiki, it's going to take a real effort to balance doing as much as we can in-house with the stress of being a volunteer asked to carry out that role. Giving way a little, and making better use of each other's strengths is how the WMF and the enwiki community are going to be able to achieve that balance. That's going to need a genuine partnership, not a hierarchical approach where each side thinks they know best and wants to run the whole show. --RexxS (talk) 00:41, 23 May 2020 (UTC)[reply]
  - Oh, I agree - and I think you and I are actually in furious agreement. I was using "rules" more metaphorically in the context of "we can be part of the people who drive the discussion" as "writing the rules".--Jorm (talk) 01:00, 23 May 2020 (UTC)[reply]
The Foundation has given itself a very powerful weapon, and I am afraid this is wishful thinking to assume it would only be applied to small projects where nobody can read the language and is unwilling to take action. If stewards are unwilling to take action, the Foundation will not do anything either, because nobody can understand what users on Amcharic Wikipedia tell to each other, unless Google translate of a given sentence would provide something like "I promise to murder you". I was once blocked for half a year on a project I had zero edits, I took it to Meta and nobody was willing to do anything, until Millosh, a steward at the time, went to the project and negotiated an unblock with the admin. And, if I am not mistaken, the guy is still an admin there. On the other hand, WP:FRAM happen at the English Wikipedia, not at thew Amcharic or Acenese one. I am really worried about damage they can inflict, not even necessarily intentianally misusing the tool, but just applying it without sufficient care.--Ymblanter (talk) 07:10, 23 May 2020 (UTC)[reply]
It is noteworthy that the BBC is now reporting that harassment would include edit warring. Now, whether this comes about as a simple misunderstanding on the part of the BBC, or whether this is being directly briefed by the WMF, is not clear. That being said, I think it's uncontroversial to state that common-and-garden edit warring is not a matter for which WMF centralised sanctions would be appropriate, and if that's the direction that this is moving in, then that is problematic.
I think it is a fundamentally good idea to have a minimum standard of behaviour across all WMF projects, and I'd argue that that point shouldn't be controversial, even if perhaps it is; "don't be sexist, racist, homophobic; don't personally attack other editors; etc" all seems like a perfectly reasonable minimum baseline. The problem strikes me as coming when that baseline starts turning into other rules being enforced by WMF sanctions rather than by the local wiki procedures, as would be the case with simple edit warring as suggested by the BBC.
I'm uncomfortable with the phrasing of "the Board is directing the Wikimedia Foundation to directly improve the situation", too, I have to say, and I hope that the "in collaboration with the communities" that follows is genuinely taken into account. Where local sanctions can be placed, that's almost always preferable in my view to WMF sanctions as a port of first call.
Overall, though, I think it's too early to form "a position" on this one way or another; we need to see what, concretely, is being proposed. Naypta ☺ | ✉ talk page | 09:17, 23 May 2020 (UTC)[reply]
I am not sure that even a minimum standard you mention is enforceable. For example, we know that Iran and Pakistan are deeply sexist societies, sexism is part of the culture, and, whereas it might be changing, it will take decades to have a noticeable change. It is deeply rooted in culture. It would be unreasonable to expect that Persian and Urdu Wikipedias are free from sexism, because their users are just part of the society. And whereas it would be great if anti-sexism measures are enforced, I just do not see how it could be done - hiring native speakers to monitor all the discussions? I have some (though a pretty old one) experience on the Russian Wikipedia, and WMF were at the time considered there as aliens from a different galaxy. They just can not enforce anything there in any consultation with the society. They can randomly block a bunch of users, it would be perceived that the user have been removed randomly by aliens. It would not change the project culture.--Ymblanter (talk) 09:33, 23 May 2020 (UTC)[reply]
@Ymblanter: I understand the point you're making, and to some extent agree with it - it may come to pass that such a set of standards are not, in fact, proactively enforceable in all cases. However, that doesn't mean they wouldn't be helpful in reactive enforcement; if someone brings a complaint, there is then at least a policy to deal with it. Naypta ☺ | ✉ talk page | 11:45, 23 May 2020 (UTC)[reply]
I’m fine with this in theory but I’d need to see a draft of the text first to have a more informed opinion. What I don’t want to see is the WMF using this for more Fram-like bans, as that would be bad for everyone involved. —pythoncoder (talk | contribs) 12:22, 23 May 2020 (UTC)[reply]
There are certainly toxic aspects to our culture. But the Wikimedia Foundation has, by way of hamfisted and tone-deaf decisions, lost the community's confidence. We have of course already discussed and rejected the idea of a binding code of conduct that applies to en.wiki.—S Marshall T/C 14:22, 23 May 2020 (UTC)[reply]
What matters in this is the implementation, not the statement. As is typical for Board statements, almost everything about the implementation is too vague too discus directly--what needs discussion is our views on what the specific standards ought to be-- and once they are announcement, how we are going to deal with them. But there is one part that even as broad policy very much concerns me, the second point,"Take actions to ban, sanction, or otherwise limit the access of Wikimedia movement participants who do not comply with these policies and the Terms of Use;" - ifthe sentence refers to groups, such as individual projects which insist upon maintaining rules that justify harassment, then there's a point to it, and a role for theFoundation, because they are the only ones who have control over such groups. If it refers to individual editors, then it's a disaster, anda violation of all agreed working arrangements between enWP and the foundation. O'll have more to say on this when I know what meaning they intend. DGG ( talk ) 15:28, 23 May 2020 (UTC)[reply]
- I have just become aware of the BBC version. If it is correct, andt he WMF intend to regulate edit warring, they will find, as we have found, that there is no way of doing it without regulating content. .Most truly difficult conduct problems arise from content disputes. (others arise from relatively arcane points of style, such as the infoboxes war, which in no rational organization would warrant either edit warring or harassment, and yet others from plain ordinary interpersonal hostility without rational motivation, which certainly requires regulation). In enWP, and presumably elsewhere, harassment is in fact a common way of settling content disputes, usually with hostility directed to those with particular points of view. This does need regulation -- I think in fact it is our greatest ongoing problem -- but what it absolutely doe not need is regulation from the foundation. To the extent we have biased content , we're to that extent a lower quality encyclopedia, but remain capable of improvement, the continual improvement that most of us came here to engage it; to the extent that others than the participants here regulate content, we 're not a open project, but the sort of directed project most of us came here to avoid. DGG ( talk ) 15:41, 23 May 2020 (UTC)[reply]
  DGG, the resistance to any authoritative body to rule on content disputes has always been a source of strife. Once civil POV-pusher can in theory drive off multiple frustrated editors if civility is the only standard - and that's my worry with what WMF appear to be proposing. It looks, in short, like a sealion's charter. Guy (help!) 16:56, 23 May 2020 (UTC)[reply]

JzG We are I think in complete agreement about the extent and nature of the problem, and the need to solve it. It is however very difficult to actually do this within our basic structure. Certainly and almost everyone in enWP would reject an outside authority here; I can imagine ways of setting an internal authority, but not one that would be generally accepted. Nor can I think of a set of rules that would not be capable of manipulation. The only way forward is to decrease the intensity of the disputes by not using the necessarily harsh sanctions for them that would be used for bad-faith disruption. The current procedure for winning a dispute is to try to get one's opponents removed from the topic, and our currrent DS rules provide that this can be done in a way very difficult to reverse. These are things we can improve. DGG ( talk ) 17:15, 23 May 2020 (UTC)[reply]

DGG, agreed. The closest we've ever come was probably the pseudoscience arbitration case. And that really was quite transformative. Guy (help!) 20:54, 23 May 2020 (UTC)[reply]

JzG. yes, that case and its followups need to be re-analyzed. The original motivation was good--to prevent the take over of scientific topics by true-believers, (the way Citizendium was taken over by a belief in homeopathy). The fundamental ideas, of distinguishing between various levels of scientific confidence, and providing for proportional coverage , remain valid. The way these standards can be misused, by overconfidence in what individuals here think scientific results, and the manipulation of the Reliable Sources standard to invalidate references showing the reality of coverage of things you rather didn't exist, was not really predicted. At a more fundamental level, it comes from the naïve reliance of WP upon sourcing, without the necessary critical examination of the actual sources. The worst part currently is the attempt to use standards that are applicable to the natural sciences to judge matters in the social science, and more recently to judge matters in the field of politics. Scientists have always known the extent of uncertainty--public reporting of the sciences is much less knowledgable; I instance the realization of the unreproducibility of results in fields such as psychology, or the disagreement between good controlled especially over time, and of evolving standards of practice. Or, most recently, the statistical blunders made by even the best analysts and most authoritative centers respecting Covid. The first step will be to convince WPedians in general of the problems; the much more difficult one will be how to solve it without destroying out principles. DGG ( talk ) 00:54, 24 May 2020 (UTC)[reply]

DGG, well, yes, but on the other hand we're not experts so we're supposed to take sources more or less at face value, depending on their quality. Where are you seeing the pseudoscience arbitration misapplied in politics? Guy (help!) 06:36, 24 May 2020 (UTC)[reply]

The difference between the natural sciences and politics derives from the difference in the way the word "fringe" is used in the fields. In the natural sciences any serious researcher at least pays lip service to the scientific method, in which unfalsifiable claims are rejected as unscientific and so fringe, or falsified claims are rejected as such. In the field of politics, where the term "political science" seemed to take hold many decades ago in the US and has now spread to the UK, very few claims are actually falsifiable, so the word "fringe" simply means "unpopular". Phil Bridger (talk) 12:30, 24 May 2020 (UTC)[reply]

Phil Bridger, and specifically? Guy (help!) 00:10, 26 May 2020 (UTC)[reply]

If there's anything we learned for m the RS discussions of the past 10 years, it's that sources cannot be taken at face value. We may not be experts, but we're expected to be intelligent. Our editing here should make us more intelligent yet, and particularly skillful about the nature of writing and publishing. Critical reading is a skill, it can be taught, and I've taught librarians how to do it. . We should as a minimum know enough to recognize that headlines are generally written by the editor , not the author, and that selective quotation is deceptive. Rare is the new articlem even in places that Fix, that does not have some wording that pretends to give a balance. Rare is the book review that says nothing positive to be quoted; equally rare the one which says nojhing negative., and in all cases they start out by saying something polite about the author. Technical literature is more sutle about these things,b ut it doe not necessarily require great subject expertise beyond knowing the technical language of the subject. DGG ( talk ) 09:21, 24 May 2020 (UTC)[reply]

DGG, I aqgree here: it has to meet RS *and* it has to pass the sniff test. Guy (help!) 00:11, 26 May 2020 (UTC)[reply]

Meh I don't think we can do much beyond wait and see at this point. One obvious plus is that after they translate it into every language we have a project in it will at least provide a widely translated non religious text.©Geni (talk) 17:41, 23 May 2020 (UTC)[reply]
There is already the Universal Declaration of Human Rights though. It's very widely translated. TryKid ^{[dubious – discuss]} 01:05, 25 May 2020 (UTC)[reply]
I know others are taking a 'wait and see' approach, but I find it impossible to be optimistic about this. The WMF has recent history of heavy-handedness in its dealings with our community and I am not aware of any reason to believe they have changed their methods. A code of conduct is a good idea in theory, but making it work in practice will be a nightmare given the current state of WMF-community relations. I'm concerned for the future of this project now that we are likely to fall under further regulation from people who aren't actively involved in the task of building an encyclopedia and, given how they use their donation money, don't really seem to care. LEPRICAVARK (talk) 18:40, 23 May 2020 (UTC)[reply]
No confidence. —Cryptic 18:58, 23 May 2020 (UTC)[reply]
After Framgate, I don't have any confidence in the WMF's capability to levy sanctions for behavioural conduct that isn't over a bright line, and especially not with a one-size-fits-nobody UCoC. —A little blue Bori v^_^v ^{2020's a bust; thanks SARS-CoV-2} 20:32, 23 May 2020 (UTC)[reply]
I see that civility is being added to the code of conduct (now civility is mentioned in the summary of the terms of use, but it's not part of the legally-binding part). When the chat in Counter-Strike is more friendly and civil than Wikipedia, it's not surprising that the WMF has to step in, for legal reasons as well (the "Fuck off" RfC etc). What is especially embarassing about how AN/I handles incivility is that most users don't realize that Wikipedia has 148,477 active editors – being friends with a popular admin shouldn't grant you any special privileges not to follow policies of the site. That absolutely does not belong to a site of this scale. Unblockables, pitchforks and torches, factionalism... The downside is that the private WMF investigations might not be equally fair to all participants, either, if we judge by the Framban. --Pudeo (talk) 22:17, 23 May 2020 (UTC)[reply]
Pudeo, you're absolutely spot-on about Wikpedia's chronic problem of cronyism. This problem has long been in need of a resolution, and ideally the WMF would be able to 'help' in a manner that would actually be helpful. But Framgate, to which you alluded, clearly demonstrated that the WMF is also susceptible to fairly blatant corruption. Moreover, I think it's fair to say that the community had little confidence in the WMF even before that fiasco. Regardless of how the rules are enforced, the system will always be somewhat corrupt. It's just a question of whether we want our community matters to be (mis)handled by people who are part of our community and thus somewhat accountable to us or by people who have few meaningful connections to our work and absolutely no accountability when they makes mistakes. LEPRICAVARK (talk) 22:47, 23 May 2020 (UTC)[reply]
I join the general group that we are unlikely to disagree much on the base rules (assuming EW isn't in there), but the implementation mechanisms. However, what I'd like to focus more in, is that several above are saying "let's wait for a full copy, then discuss it". At that point, changes are going to be much harder to bring in. Instead, having a better idea for when they initially come to us "what would the communities like to add in", is helpful. I did like @RexxS:'s suggestion of offering a range of community group viewpoints if no single one got consensus. I have a suspicion the WMF may pick the one they like more and completely ignore the other(s), but if we can't get a clear-cut viewpoint, that option has some major positives to it. Nosebagbear (talk)
In terms of what I'd like to see specifically, ideally I'd prefer implementation by communities with ARBCOMs and active conduct boards, and where their current policy covers everything within the minimums within a UCOC, be provided by the Community. There would need to be a corrective mechanism for communities which run out of control, conduct-wise, despite an ARBCOM, but that would need to be a general tool (rather than them just pulling out individual cases). Nosebagbear (talk) 09:18, 24 May 2020 (UTC)[reply]
A minimal (basic) global set of moral rules (i.e. rules of behavior) is necessary. Tgeorgescu (talk) 21:30, 25 May 2020 (UTC)[reply]
I have no confidence whatsoever in the WMF even to consider points raised by those who actually work on creating an informative and neutrally worded encyclopedia. The notion that they can or should even seek to impose a uniform code of conduct defining civility for volunteers worldwide is an affront, and their stated basis for so doing: that some female editors have complained that having their contributions edited by others inhibits their attempts to slant our coverage and is inherently biased—demonstrates their contempt for us and what we do that enables them to draw their salaries. There are conversations to be had about entrenched bias. There's research to be done to replace the WMF's woeful assumptions about percentage of female editors, which at this point I believe are deliberately alarmist (I am not male just because I don't have a pink userbox). Yes, there are double standards on civility and we could do better; WMF employees are among the worst offenders when it comes to sarcasm and dismissiveness, and the canard that not using four-letter words is a universal requirement to be treated with respect is classist and parochial even in the US. But the WMF don't listen to editors' wishes or show respect for the editing community. No, we should not try to meet them partway, and beg for them to understand, or hops they don't mean en.wikipedia as well. We should refuse to accept that they have any right whatsoever to dictate to us, and call them on their own intolerance and intolerable rudeness. Yngvadottir (talk) 21:58, 25 May 2020 (UTC)[reply]
I won't mince words here. This is bad. Wikipedia is not the first project on the Internet to have a code of conduct imposed on it, and these things are typically social justice takeovers that make everyone guilty but are enforced selectively. The Fram case (accompanied as it was by vague accusations of harassmeent) makes this more obvious. So does the list of social justice groups in the Signpost article that the WMF consulted with in April 2019. Ken Arromdee (talk) 01:47, 26 May 2020 (UTC)[reply]

Explicitly prohibiting the removal of copyright violation tags by the authors of copyvio-tagged articles

You are invited to join the discussion at Wikipedia talk:Copyright violations#Making it clear that copyvio tags should not be removed. Naypta ☺ | ✉ talk page | 11:49, 23 May 2020 (UTC)Template:Z48[reply]

Wikipedia:Awards and accolades

Please review Wikipedia:Awards and accolades and refine it, with a view to eventual promotion to guideline., The idea is to set expectations about the use of non-notable awards and listicles in articles. Guy (help!) 21:16, 23 May 2020 (UTC)[reply]

This has been attempted before but it's not a good idea to delete red-linked awards across the board. It would create bias against fields that are not mass media (sports, film, TV). For example, enwiki does not have many French academic awards, but there are many prestigious if boutique/local recognitions for academic authors writing in French. Imagine transwiking an academic bio from frwiki and discovering 3/4's of the awards are red link, it would not be an accurate bio. As always, a reliable secondary source demonstrates it was notable enough for coverage by the wider world, should anyone raise concerns this is sufficient. -- GreenC 21:56, 23 May 2020 (UTC)[reply]
And for God's sake get rid of that stupid word accolade. See User:EEng#Dopey_words_that_should_never_appear_in_articles. E Eng 02:52, 24 May 2020 (UTC)[reply]

GreenC, ok, so have a look at List of awards and nominations received by Beyoncé. Example: the Latina Beauty Award for Styling Product for Holding your Style. Really? I already removed the Vh1 Bikini Award for Best Celebrity Bikini Body. Guy (help!) 06:45, 24 May 2020 (UTC)[reply]
This feels like a situation where what WP:LISTCRITERIA to use can be decided case by case, and I don't see the need for a guideline. For a French academic including French academic awards is reasonable while for someone like Beyonce the criteria can be notable award and or reported in a independent reliable source. Galobtter (pingó mió) 06:57, 24 May 2020 (UTC)[reply]

Pop culture mass media, particularly music/film/acting, is problematic. The world is bigger there are awards for just about every field of study and most of them are acceptable. A general guideline that tried to resolve the mass media problem can create new problems in other fields. -- GreenC 18:48, 24 May 2020 (UTC)[reply]

@@ Line 872: / Line 872: @@
 *A minimal (basic) global set of moral rules (i.e. rules of behavior) is necessary. [[User:Tgeorgescu|Tgeorgescu]] ([[User talk:Tgeorgescu|talk]]) 21:30, 25 May 2020 (UTC)
 *I have no confidence whatsoever in the WMF even to consider points raised by those who actually work on creating an informative and neutrally worded encyclopedia. The notion that they can or should even seek to impose a uniform code of conduct defining civility for volunteers worldwide is an affront, and their stated basis for so doing: that some female editors have complained that having their contributions edited by others inhibits their attempts to slant our coverage and is inherently biased—demonstrates their contempt for us and what we do that enables them to draw their salaries. There are conversations to be had about entrenched bias. There's research to be done to replace the WMF's woeful assumptions about percentage of female editors, which at this point I believe are deliberately alarmist (I am not male just because I don't have a pink userbox). Yes, there are double standards on civility and we could do better; WMF employees are among the worst offenders when it comes to sarcasm and dismissiveness, and the canard that not using four-letter words is a universal requirement to be treated with respect is classist and parochial even in the US. But the WMF don't listen to editors' wishes or show respect for the editing community. No, we should not try to meet them partway, and beg for them to understand, or hops they don't mean en.wikipedia as well. We should refuse to accept that they have any right whatsoever to dictate to us, and call them on their own intolerance and intolerable rudeness. [[User:Yngvadottir|Yngvadottir]] ([[User talk:Yngvadottir|talk]]) 21:58, 25 May 2020 (UTC)
+*I won't mince words here.  This is bad.  Wikipedia is not the first project on the Internet to have a code of conduct imposed on it, and these things are typically social justice takeovers that make everyone guilty but are enforced selectively.  The Fram case (accompanied as it was by vague accusations of harassmeent) makes this more obvious.  So does the [https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2019-06-30/Discussion_report list of social justice groups in the Signpost article] that the WMF consulted with in April 2019.  [[User:Ken Arromdee|Ken Arromdee]] ([[User talk:Ken Arromdee|talk]]) 01:47, 26 May 2020 (UTC)
 ==Explicitly prohibiting the removal of copyright violation tags by the authors of copyvio-tagged articles==