Talk:Copy of Wikipedia:Village pump (policy)

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, no archives yet (create)

RfC: Locality categorization by historical subdivisions[edit]

Template:Atop User:ClueBot III/DoNotArchiveUntil 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).

γηφη

ηξ

φδγδφσγδφγ

φδ

σφφγδσ Geraki (talk) 10:47, 2 June 2020 (UTC)[reply]

Opinion poll: Locality categorization by historical subdivisions[edit]

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]

Template:Abot

RfC: proposed creation of new usergroup[edit]

Template:Closed rfc top

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

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]
Template:Replyto 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)[edit]

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]
ηξηγξγη Geraki (talk) 10:45, 2 June 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]

γφηγηφ Geraki (talk) 10:45, 2 June 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]
- ηξγηξκγκ Geraki (talk) 10:46, 2 June 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]

Template:Closed rfc bottom

RfC: Bureaucrat activity[edit]

Template:Closed rfc top

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: Template:Talkquote TonyBallioni (talk) 21:25, 24 April 2020 (UTC)[reply]

Support (Bureaucrat activity)[edit]

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

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

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[edit]

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[edit]

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]

Template:Replyto 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]

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]

Template:Closed rfc bottom

Paid editing[edit]

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]

Template:Larger

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 [2] 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]
Template:Replyto 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]

DGG, have you seen this thread? Usedtobecool ☎️ 05:37, 27 May 2020 (UTC)[reply]
I think MistyGraceWhite is on to something, although the parameters are certainly negotiable. We have a substantial problem of sockpuppets and SPAs, and we have basically unlimited flexibility to tweak the degree to which new editors may be required to demonstrate their willingness and ability to contribute to the project before receiving specific tools like the ability to create pages in mainspace and pagemover rights. BD2412 T 14:21, 27 May 2020 (UTC)[reply]
The "must" proposal I very strongly support. If we just say "shouldn't", every single paid editor will think they're the exception, since, well, they're being paid to think so. "Must not" doesn't have any such wiggle room, while still leaving space for things like reverting obvious vandalism. No one's going to complain if a paid editor reverts the addition of random strings of profanity anyway. I also see the merit in upping the bar for new article creation. Autoconfirmed is a pretty low bar to clear for someone being paid to do so—make ten minor uncontroversial edits and set up a calendar reminder four days later. (This is not hypothetical; when I delete spam articles, this is often clearly exactly what they did.) Raising the bar to even EC would dramatically raise the amount of effort to create socks and sleepers, and if nothing else that would mean the paid editors will have to charge more, operate slower, and lose more when a sock is caught, which may help to discourage the practice. Creating an appropriate mainspace article is hard; the number of editors who could do so after ten edits is probably quite small. Seraphimblade ^{Talk to me} 21:00, 1 June 2020 (UTC)[reply]

None of it works. Sorry for being such a skeptic, but it's a joke if you think any of these proposals will stop paid editing. See the following: [3] and [4] - and weep. And that's only one site among many. They even predict that volunteers will be a thing of the past and that paid editing will win out. Money talks. How do you silence it? There's only one way and that's registration with validation. Sorry but that's it in a nutshell, and I haven't seen anything that convinces me otherwise, especially not more failed bureaucracy. ^Atsme _Talk 📧 22:36, 1 June 2020 (UTC)[reply]
- Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?
- At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat. Geraki (talk) 10:49, 2 June 2020 (UTC)[reply]

RfC: Source classification process[edit]

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

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]
Oppose needless restrictions on the spam blacklist. I trust User:Beetstra and the other admins at the spam blacklist to know the difference between spammed sites and unreliable sources and to act accordingly. WhatamIdoing (talk) 19:13, 1 June 2020 (UTC)[reply]

Discussion (Source classification process)[edit]

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]

So perhaps a more pointful RFC would says something like "Shall we keep wasting editors' time with sources that aren't widely used? For example, future proposals to add a website to Wikipedia:Reliable sources/Perennial sources should show that there have been at least two discussions at RSN about the source in the past (not counting the current discussion), or that it is currently present in more than 10 articles."

This innovative list of unreliable sources is allegedly for the stuff that gets disputed over and over. That's why editors named it WP:RSP with a "P" for perennial and not Template:Fake link." WhatamIdoing (talk) 19:21, 1 June 2020 (UTC)[reply]

Question Related to WP:CLOSE; One Specific Case[edit]

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[edit]

Template:FYI 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[edit]

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[edit]

Template:Atop

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

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

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]

Template:Ctop

@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]

Template:Cbot

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.Template:ParabrIs 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[edit]

Template:Ctop 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) Template:Cbot[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. I willl 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]

Template:Ul 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]

Wikipedia:Fringe_theories/Noticeboard/Archive_69#Bryan_Caplan. fiveby(zero) 20:40, 1 June 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 news article even in places like F_x, 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 nothing negative., and in all cases they start out by saying something polite about the author. Technical literature is more sutle about these things, but it does 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]
Acting on the principle that a good defense is a good offense, I went ahead & proposed my own draft for a Universal Code of Conduct over at Meta. The important points are simple: except for defined & currently accepted areas, the Foundation will not intervene where the communities have a functioning governance system; if they do intervene, they must provide a justification for their action; & that there be a model Code of Conduct that applies to communities where none exist. I don't know how the PTB will respond to my proposed draft, but I hope it is in the spirit it was offered. -- llywrch (talk) 18:16, 26 May 2020 (UTC)[reply]
A friend of mine correctly pointed out that in situations like this, you should always summarily oppose to start and have your support won. Then, if things make sense, maybe it gets adopted. But without significant buy in, the answer is no, and should be anticipated to be no, unless the WMF convinces us they present us with a set of rules we agree with, and convince us they are capable of enforcing them without overstepping. My answer would have been no before FRAMGATE. It's even more no after FRAMGATE. I'm open to have my mind changed, but the WMF needs to do the legwork here. Headbomb {t · c · p · b} 14:34, 27 May 2020 (UTC)[reply]
The WMF has a severe case of cranial rectal inversion, demonstrated not only with Framgate, but their tone deaf response to most everything (including private correspondances). Frankly, we need less WMF involvement, not more. Let them stick to what they do best, raise money, and blow money unnecessarily. They have the reverse Midas touch. Dennis Brown - 2¢ 16:43, 27 May 2020 (UTC)[reply]

En.wikipedia would be much better served by somebody who just keeps the servers and software running. Maybe we should replace WMF.North8000 (talk) 18:58, 27 May 2020 (UTC)[reply]

- Any editor (indeed, any person) can start a new website cloning all of Wikipedia's content and running it under whatever rules they like. However, since WMF owns the trademark registrations, the name "Wikipedia" can not be used outside the structure of the WMF without their permission. BD2412 T 19:24, 27 May 2020 (UTC)[reply]
Wasn't this already rejected by the community on Meta? GMG ^talk 12:24, 28 May 2020 (UTC)[reply]
I have to agree with Tony. Any RfC or set of RfCs here is unlikely to be helpful. WMF has made mistakes but that doesn't mean they're always wrong, and often the first instinct here on enwiki seems to be "If it came from WMF, I'm agin' it." WMF aren't our enemies. —valereee (talk) 14:19, 28 May 2020 (UTC)[reply]
Well, Valereee, I think it's more a question of "I've seen what happened before." In the past, vague statements like this were followed by disastrous, heavy-handed moves from WMF, be that in the form of software or Framgate. Yes, we always try to assume good faith, but when someone's already abused that assumption repeatedly, we don't keep blindly doing it. So in this instance, I certainly understand why the reaction is "Good God, not this again." Seraphimblade ^{Talk to me} 18:43, 1 June 2020 (UTC)[reply]

Toxic[edit]

Every time they say "toxic" in a document, a little part of me wants to scream inside. I have proposed on Meta that the term be avoided. — Pelagic ( messages ) Z – (02:59 Sat 30, AEST) 16:59, 29 May 2020 (UTC)[reply]

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

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[edit]

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]
Can the page be renamed to something less ambiguous? I thought it was going to be a page on internal Wikipedia awards like Wikipedia:Awards. -- King of ♥ ♦ ♣ ♠ 03:11, 26 May 2020 (UTC)[reply]
I agree it depends upon fields, and also that a good start towards rationality would be a mass removal of "and Accolades" . One guideline I have support is to not use minor or junior awards when major awards are present--but even this could be useful to show the development of a career. DGG ( talk ) 19:04, 26 May 2020 (UTC)[reply]
Depreciate the use of "and accolades" and simply go with awards, which is more concise. ~ Dissident93 ^(talk) 19:58, 26 May 2020 (UTC)[reply]
- WP:Awards is already used for another subject. Maybe you'd prefer something more obviously descriptive, like WP:Determining which awards are trivia? WhatamIdoing (talk) 19:39, 1 June 2020 (UTC)[reply]
Agree with the sourcing criteria - awards that haven't been reported on by anyone but the awarding body and the recipient are fairly useless from an encyclopedic point of view. Disagree with most of the rest - if an award has been reported on widely in the media, just because it lacks its own page on the wiki doesn't mean that it's not worthwhile including in the particular instance in which it's being reported IMO. I do think it is a good idea to have a policy specifically on the requirement to have independent sourcing of awards being given, though - it gives something easy and concrete to use for future decisions in the area. Naypta ☺ | ✉ talk page | 20:11, 26 May 2020 (UTC)[reply]
I'm not sure why we're seeing this strange backlash to the word "accolade", which is actually useful. The two words are similar but not the same. An "award" is a thing which is formally bestowed as a symbol of praise or recognition, an accolade is simply an expression of praise or recognition. Awards are a form of accolade, but you can have notable accolades other than awards. For example, a movie being included in a notable "top 10" list is an accolade. A notable critic calling an album the "best album of the decade" is an accolade. An artist's design winning a contest to represent the olympics is an accolade. There are endless relevant non-award accolades that can, should be and are included in articles. I'm just as eager to jump on the Eeng bandwagon as anyone else, but can we please cool it a bit? Like no one's even providing an argument, Eeng just thinks it's "dopey", whatever that means. ~Swarm~ ^{sting} 03:08, 27 May 2020 (UTC)[reply]
Accolade is like kudos. In the context of an article it's a strained way of saying recognition or something. It sounds like applause; in your mind's eye you can almost see the audience in evening dress with their tiaras and top hats, politely accolading. Call it a linguistic prejudice of mine. E Eng 05:37, 28 May 2020 (UTC)[reply]

A nomination is an accolade as well. That's why sections on this subject on film articles are generally called Accolades, which is more concise than Awards and nominations El Millo (talk) 03:36, 27 May 2020 (UTC)[reply]

The way to get rid of fluff like the Bikini body or hair styling award isn't to throw the baby out with the bathwater by entrenching systematic bias. We don't have articles on some or even all of the most notable awards in many fields or locations - e.g. Category:Gabonese awards contains only one article (Miss Gabon). Thryduulf (talk) 08:10, 27 May 2020 (UTC)[reply]
Thryduulf, which, in an ideal world, would be deleted along with all other pageants. Guy (help!) 17:37, 29 May 2020 (UTC)[reply]
Template:Replyto If you think it isn't notable then send it to AfD. If your objection is to the concept of pageants then WP:NPOV is relevant. Thryduulf (talk) 18:06, 29 May 2020 (UTC)[reply]
Thryduulf, no, I think that we should not have articles on pageants because they objectify women. We should take a stance against the morally repugnant world of beauty contests. But as I said, that's an ideal world. A world where the punishment for driving while black can be summary execution, clearly isn't ideal. Guy (help!) 18:18, 29 May 2020 (UTC)[reply]
@JzG: I suspect that many people share your view, enough for it to be discussed in reliable sources. That would mean that it should be covered here too. If Wikipedia can help raise awareness of this issue, wouldn’t that help bring us closer to an ideal world? You can’t fix a problem that you don’t know about.

Oh, but of course someone beat me to it: Beauty pagent#Criticism. Brianjd (talk) 08:49, 31 May 2020 (UTC)[reply]
I made this point at Wikipedia_talk:Manual_of_Style/Video_games#Clarification_of_"notable"_awards_bodies but I think it bears repeating here to help shape this guideline. Awards are made up all the time, often with the goal of profiting/riding the coattails of the popularity of the nominees. In advertising, there's certainly a perverse symbiotic relationship between awards-givers and awards-receivers. The latter gets to pump their numbers ("over 100 awards and nominations!") while the former earns ad revenue while providing nothing at all other than 'recognition'. So what is recognition? The Oscars are prestigious because people in the industry agree that it is and respect people who win one, not because tiny golden statues are inherently prestigious. Another film award that's voted on by just as many people (let's say by people named Jim) that awards an equally golden statue would not confer the same prestige in the film industry because the people in that industry don't agree that it does, no matter how many cameras you point at it and press releases you throw onto the internet. I think reliable sourcing is key to establish this. It should be verifiable that an industry or academic award confers prestige in a field. It's easy to be dazzled by the shininess of an Award With a Proper Title (who doesn't love a gold star in elementary school, right?), but just because it has a name and a website doesn't make it automatically notable. Otherwise reliable sources regurgitating press releases about nominees and winners doesn't either (that's churnalism). If an award is notable, there should be reliable sourcing about the award itself and its esteem in the community. Axem Titanium (talk) 06:27, 31 May 2020 (UTC)[reply]
I had made this comment on the talk page of the draft but I think the first bullet needs a bit more tuning. Obviously where the individual award is notable that's fine, but there are cases where the awards as a whole are notable, their nomination/presentation process each year may or may not be notable on its own, and the individual catagories may not be notable; a prime example is the British Academy Games Awards (And while some of the individual pages have been created, I can tell you they would not survive an AFD in contrast to the individual ceremony articles. We'd still clearly want these awards as a group, but the current way the first bullet is presented would not allow for that. --Masem (t) 07:01, 31 May 2020 (UTC)[reply]
I'm not as negative on the word "accolades" as some others are, but I do understand the reaction. However, it should not be simply removed. As someone else pointed out, some awards are sufficiently prestigious that a nomination is worth noting, and that is not an award. I tend to use "Awards and honors" as a section heading, and a quick glance suggest that is quite common. You probably don't need additional examples, but in Jill_Hutchison, I include some items that are clearly awards, but some things that are clearly not. Induction into a Hall of Fame belongs (IMO) in such a section but it is not an award. Perhaps changing the title to "Awards and honors" would make everyone (ok, many people) happy.S Philbrick (Talk) 14:23, 31 May 2020 (UTC)[reply]
Awards and honors or Honors and awards or Recognition and awards all sound great. Just not accolades. Anyone who writes accolades, I'll unfriend them. E Eng 22:21, 1 June 2020 (UTC)[reply]

Followup: I suppose it could be worse: we could be talking about felicitations [5]. E Eng 02:27, 2 June 2020 (UTC)[reply]

Interface admin and view deleted access[edit]

Tracked in Phabricator
Task T202989

I raised this as a thread on checkuser-l, but WP:INTADMIN currently restricts the ability to view deleted interface pages to IADMINS not as a feature of policy or intent, but as a bug in the system. There’s a patch that’s been proposed since August 2018, but is stalled at the review stage. I’ve debated asking for the permission for view access to deleted pages, since I doubt it’s going to be fixed anytime soon and there are several sockmasters where having the access to their deleted common.js, etc. would be very helpful to me.

The glitch in that is that our local activity policy requires use every six months. I have zero interest in using it for anything other than view deleted access. I think adding a line to the activity policy such as the interface administrator indicating that they still need access to the right to view deleted content would be fine. If people are overly concerned about the security risk here, we could possibly restrict activity for that reason counting to the CU team, but I don’t really think we’re talking about more than a handful of people who would want it for this reason.

Anyway, is there a consensus here for a quick change to the policy to allow for this? If not I can start an RfC, but I’m hoping this will be non-controversial. TonyBallioni (talk) 14:03, 31 May 2020 (UTC)[reply]

TonyBallioni, This sounds like a sensible change. S Philbrick (Talk) 14:08, 31 May 2020 (UTC)[reply]

I think you should just push to get this worked on, having to constantly check for people with no logged use that just "say" they want this constantly is going to be a headache. Suppose to keep automation checks working you could just indicate your need by updating something like User:Example/test.css. — xaosflux ^Talk 15:00, 31 May 2020 (UTC)[reply]

A patch has been in the works for two years and has stalled. I don’t really have any faith this is going to be fixed within the next decade even with poking. I don’t really think the automation issue is actually an issue. There’s 11 people with this now. One talk page message to check every six months for 1-2 people isn’t that much work. TonyBallioni (talk) 15:27, 31 May 2020 (UTC)[reply]

Also, xaosflux a link to the actual gerrit: [6] TonyBallioni (talk) 15:37, 31 May 2020 (UTC)[reply]

The easiest thing to do is grant interface administrator access as part of the checkuser toolset (whether it's done by bundling the actual permissions, or just by granting the flag concurrently with the checkuser flag) and then ignoring all checkusers who have interface administrator access from the activity monitoring stuff. I don't suppose anybody can explain why WMF is hell bent of making life as difficult as possible for those of us who have volunteered our time to behind the scenes management stuff. Why can't they just fucking fix the IADMINS stuff and stop trying to find new ways to make life impossible for the rest of us (such as the hiding anonymous users IP data) ? Nick (talk) 15:41, 31 May 2020 (UTC)[reply]

Some CUs here and on other projects have valid reasons not having 2FA, so that wouldn’t work from a WMF security standpoint. If you want a quick way to automate it, you could exempt CUs who have it from the activity requirements of IA. TonyBallioni (talk) 15:50, 31 May 2020 (UTC)[reply]

Adding editinterface to the CU group is silly and really not the point of the entire thing; I certainly agree the primary viewing problem should be fixed (I'm the one that authored the request afterall!) - a dev did update it a couple of months ago - just poked them on phab:T202989 - where this really is a global problem. — xaosflux ^Talk 15:53, 31 May 2020 (UTC)[reply]

As far as "indicate you have an ongoing need", it would be just as easy to indicate that at a dummy page like the one I put above as anywhere else, and would not require any extra work. — xaosflux ^Talk 15:55, 31 May 2020 (UTC)[reply]

I think it’s less complicated just to have a bureaucrat ask the question 1-2 times a year. Gaming the system isn’t something that I think is a good thing. People shouldn’t have to make a dummy edit to keep this if they’re using it. You could also look at it from a security standpoint that people who don’t need it are more likely to give it up if asked if they still need it rather than being told how to keep it. TonyBallioni (talk) 16:32, 31 May 2020 (UTC)[reply]

@TonyBallioni: oh all the dummy edits made by +sysops every year........ This wouldn't be a "twice a year" thing specifically, the policy has these rights continually expire - we don't do a twice a year review of everyone. In practice, we only review the rights holders monthly though. Looks like the activity at the phab task has given some renewed interest in the fixing though (which is really where it belongs). — xaosflux ^Talk 01:36, 1 June 2020 (UTC)[reply]

Is it not just easier to flip user:TonyBallioni’s Iadmin bit with a note that the 6 month term does not apply to him in a fully automated way, but that he just needs to confirm the need every 6 months? —Dirk Beetstra ^{T C} 17:40, 31 May 2020 (UTC)[reply]

Beetstra, That also sounds like a workable solution. S Philbrick (Talk) 18:18, 31 May 2020 (UTC)[reply]

If he's the only one with this issue/concern, then I'd support that. Primefac (talk) 21:21, 31 May 2020 (UTC)[reply]

I would prefer the view and edit permissions be split; Template:Strike give Tony IAdmin since he has a clear need. — Wug·a·po·des 21:20, 31 May 2020 (UTC)[reply]

@Wugapodes: FWIW, there is no IAR needed for Tony to get this, he requested it at BN and I doubt there will be any cause to not issue it. — xaosflux ^Talk 01:32, 1 June 2020 (UTC)[reply]

I thought the criteria were more restrictive than that, but I read them again and clearly I misremembered. Good to know there's enough room for this in the existing policy. I trust Tony with IAdmin regardless, but I still think view and edit should be split for the reasons given in the phab task. — Wug·a·po·des 03:29, 1 June 2020 (UTC)[reply]

First item
Second item
Third item Geraki (talk) 10:50, 2 June 2020 (UTC)[reply]
- Not a list! Geraki (talk) 10:51, 2 June 2020 (UTC)[reply]

Does the community still approve of NOTHERE blocks?[edit]

Since there's a TfD over this for some reason, I'll raise the question here: does the community still approve of blocks per WP:NOTHERE? I think we should still use them for a few reasons:

We're not a bureaucracy- if we stopped using them they'd just be replaced with indefinite disruptive editing blocks since disruptive editing is another catch-all category that means "we can block or sanction you if you're causing issues regardless of the exact policy reference."
It is actually a part of policy by reference- see Wikipedia:Blocking_policy#"Not_here_to_build_an_encyclopedia"
It's use as a block reason is an accepted part of our practice that has been around for ages and retraining people to just say disruptive editing, POV pusher, etc. would take substantially more work than it would produce benefit.

Those are my thoughts. I think it's worth seeing if the rest of the community is still on board. TonyBallioni (talk) 20:51, 31 May 2020 (UTC)[reply]

DE and NOTHERE block indeed overlap. I have no particularly strong feelings on the matter as I use the two rather interchangeably, but sometimes it does feel like there is a somewhat nuanced distinction between the two. Removing NOTHERE blocks for purely bureaucratic reasons is not something I agree with, however. And as I mention already several times, starting with a TfD was POINTy and actively disruptive to the project. I recommend that the TfD be speedy closed and that the discussion shifts here. El_C 21:02, 31 May 2020 (UTC)[reply]
I consider them reasonable interpretations of policy, and I philosophically really like NOTHERE blocks compared to "disruptive editing" blocks when it comes to dealing with the "I'm here to push an incendiary point" or "I'm here to do whatever I like" editors. It pushes the concept of them appealing it from "my editing wasn't disruptive" to "I am here to build an encyclopedia because...". It's a far better theoretical point to start people thinking constructively. ~ mazca ^talk 21:16, 31 May 2020 (UTC)[reply]
Last discussion in 2015. The mention in Wikipedia:Blocking policy#"Not here to build an encyclopedia" is descriptive, not prescriptive. It briefly states that this is an often used block reason. That's an odd piece of policy. As mentioned in the TFD, WP:NOTHERE itself is a supplemental page, and as such "is not one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community". Many of the NOTHERE things are mentioned in policy itself, like WP:MEAT and WP:DISRUPT, but not all, such as WP:SPA which is an essay. Especially who is a SPA can be pretty controversial, and this block reason has been used for such editors. If I was blocked, I'd like a strictly policy-based reason which can potentially be appealed. This is giving too much leeway to blocking admins, even if the individual blocks can be brought to AN. "You are not here to contribute to Wikipedia", while appropriate for outright trolls, is an opinion that should be derived from policy. And those policy violations should be the block reason. --Pudeo (talk) 21:21, 31 May 2020 (UTC)[reply]
- All of our policies are descriptive, not prescriptive. They document practice agreed upon by the community, which is ultimately what consensus is. TonyBallioni (talk) 21:38, 31 May 2020 (UTC)[reply]
  - Tony: I really wish more Wikipedians would remember that. Beyond My Ken (talk) 06:10, 1 June 2020 (UTC)[reply]
Blocks should be justified on specific grounds that focus on clearly identified behaviours, such as listed under "Protection" and "Disruption" at WP:WHYBLOCK. WP:NOTHERE works fine as a general philosophy, but I think it falls short as a grounds for blocking. It is very broad and focusses on inferences about the editor rather than specific actions. Shifting NOTHERE blocks to cite more specific DE grounds would increase the procedural fairness of our block and block review process.--Trystan (talk) 21:32, 31 May 2020 (UTC)[reply]
WP:5P1 says we're an encyclopedia. If your actions don't support advancing that goal, then you're WP:NOTHERE. -- RoySmith (talk) 21:41, 31 May 2020 (UTC)[reply]
A user can be NOTHERE well before having become disruptive. If a user's first few edits include any attempt to politely suggest that InfoWars is "just as good" as the "fake news liberal mainstream media", or that QAnon or the Pizzagate conspiracy theory are "not debunked", a single stern warning (if that) followed by an indef NOTHERE block if their response is anything but "Oh, sorry, I'll find a different topic" is totally fine. If any of their first few edits is to to politely ask where's the proof the Holocaust happened or why we let black people edit, an immediate indef NOTHERE is totally fine. These blocks aren't hypothetical, either, they've happened. Ian.thomson (talk) 22:19, 31 May 2020 (UTC)[reply]
If a user is "clearly not here to build an encyclopedia", then irrespective of whether or not a chapter-and-verse policy can be recited that they've broken, it strikes me as sensible that they not be allowed to continue editing in a way that is clearly not helpful to the encyclopedia. So yes, I approve of NOTHERE blocks at the moment. Naypta ☺ | ✉ talk page | 22:25, 31 May 2020 (UTC)[reply]
Around for ages? Yes, and I still approve of it. My impression is that User:Fred Bauder (who is still around, though not very frequently, and no longer an admin) started using it as a block reason, and it caught on. Then, later, it was formalized into being mentioned in the policy. I too like it philosophically and, as Tony says, "practice agreed upon by the community" is what consensus is. Ancient Institutional Memory | talk 22:30, 31 May 2020 (UTC).[reply]
I often patrol WP:UAA and frequently encounter new accounts with clearly profane and confrontational usernames who immediately engage in gross and severe vandalism. I block them rapidly using the NOTHERE template and move on. I use it only in obvious cases. Cullen³²⁸ Let's discuss it 23:53, 31 May 2020 (UTC)[reply]
Not keen on this rationale and you won't see me using it. What's the problem with blocking that clearly profane and confrontational username engaging in gross and severe vandalism for Template:Underline and Template:Underline? Why do you need to use "not here" instead? wbm1058 (talk) 00:20, 1 June 2020 (UTC)[reply]
- Wbm1058, I mention the profane username and the vandalism in my block notice as well. I see the NOTHERE template as an umbrella tool to speed and summarize the process, especially when I see zero potential for redemption. Cullen³²⁸ Let's discuss it 08:02, 1 June 2020 (UTC)[reply]
Yes. Some editors are plainly a drain on community time and energy. If they have no significantly positive attributes that build the encyclopedia then they are NOTHERE and should be blocked to reduce the burden on others. Sometimes we need to support established editors rather than hope that helpless cases might reform. Johnuniq (talk) 01:42, 1 June 2020 (UTC)[reply]
I recall having used this on users whose edits do not fall obviously afoul of our more specific policies, but whose edits show quite clearly that their purpose is not to build an encyclopedia. Even if this were not already codified in the blocking policy, common-sense and WP:NOTBURO support this approach. Vanamonde (Talk) 02:25, 1 June 2020 (UTC)[reply]
I don't see how we have this conversation without first reviewing data: who is being blocked for NOTHERE and why. Anecdotes are no substitute. Levivich ^{[dubious – discuss]} 02:36, 1 June 2020 (UTC)[reply]
Levivich, You can run this query to find all (633) of the NOTHERE blocks for April 2020. -- RoySmith (talk) 03:11, 1 June 2020 (UTC)[reply]
RoySmith, thanks!! Levivich ^{[dubious – discuss]} 03:20, 1 June 2020 (UTC)[reply]

I didn't look at all the blocks on that query list, but I checked some random examples, and all the ones I checked could have been described as something else, e.g. POV pushing, vandalism, incivility, web host, trolling. I really don't perceive of "not here" as distinct from our other PAGs. It also strikes me as not useful to have "not here" as a block rationale. (Why "not here"?) That said, it also seems to me that having a block rationale of "not here" is not harming anything; it just doesn't strike me as particularly useful. Levivich ^{[dubious – discuss]} 02:55, 2 June 2020 (UTC)[reply]
Regarding DE vs NOTHERE, the latter implies less than good-faith (explicitly commenting on the user's goal) and likely immediately indef, whereas the former is possibly just a temporary drain despite good intentions (overlapping with CIR). I think of NOTHERE as a useful catchall especially when there are multiple problems without any one specific being bad enough alone to merit the length/strength of the block. Common case might be a pattern of low-level vandalism or semi-advertising that then responds to mid-level warnings with some abuse or trolling. That's exactly a bad-faith disruption with a block for more than one reason, rather than a good-faith disruptive effect or for excluvely one policy reason. DMacks (talk) 02:56, 1 June 2020 (UTC)[reply]
- OK, but NOTHERE also covers good faith but unhelpful activity. Essentially it's for someone who is not compatible with Wikipedia. Johnuniq (talk) 03:37, 1 June 2020 (UTC)[reply]
  - Not really, per WP:NOTNOTHERE. Template:TQ If they are acting in good faith but are misguided it is not a NOTHERE situation and should be dealt with differently. PackMecEng (talk) 03:08, 2 June 2020 (UTC)[reply]
    - The Clearly not being here section lists a dozen ways a user could be good faith, yet be unhelpful. If an editor engages in almost nothing else, they should be NOTHERE blocked regardless of whether they personally believe their edits improve the encyclopedia (which is the definition of good faith). Johnuniq (talk) 07:10, 2 June 2020 (UTC)[reply]
I've seen NOTHERE threatened against users who have made minimal contributions to the encyclopedia and instead go to discussion pages and treat them like forums for things that aren't directly benefiting the project. It's not disruptive editing, but it is something that needs to be discouraged and I think NOTHERE fills that role nicely. -Indy beetle (talk) 03:13, 1 June 2020 (UTC)[reply]
WP:NOTHERE blocks are unfortunately suited to certain users who make it plain they have a purpose other than building the encyclopedia. And they can be here with the best of intentions in purely editing to serve that agenda. They may be proselytizers of The Truth, or righting great wrongs, or correcting Wikipedia's (insert adjective here) bias, and more. To a certain degree, there is overlap between this and other block rationales, but it remains a useful tool especially for users whose problems are multi-dimensional. --Deep fried okra User talk:Deepfriedokra 03:42, 1 June 2020 (UTC)[reply]
I'm not an admin, but I believe this is a good tool, and I fully agree with the reasoning given by Mazca, Naypta, and Vanamonde. —⁠烏⁠Γ ^(kaw) │ 04:17, 01 June 2020 (UTC)[reply]
NOTHERE blocks are a great tool when used for relatively new accounts (or sleepers) who clearly aren't operating within the same headspace as the rest of the community (that weird intersection between spammers, vandals, POV-pushers, trolls, bad actors, etc. - the cases where it's hard to tell what their goal is but where it's plainly obvious that they aren't here to improve things). However, sometimes I find they can be misused for newbies who still haven't quite gotten how things work here yet and just need some more rope. I mean the block would technically be appropriate due to the fact these types of users are frequently given advanced warning of their behavoir, but they never sit right with me. –MJL ‐Talk‐^☖ 05:10, 1 June 2020 (UTC)[reply]
User talk:Broadwood-park is a good example of what I mean with this latter thing. The user is clearly trying to improve Wikipedia in their own way, so calling them WP:NOTHERE doesn't feel right with me. It's a sound block, yes.. but should it be? Idk maybe. Template:Shrug –MJL ‐Talk‐^☖ 05:19, 1 June 2020 (UTC)[reply]
I could not have said it better than Deepfriedokra. NOTHERE blocks are a perfectly reasonable general descriptor for users who are...well, not here to contribute to the project in good faith. I am not sure why the community would have a problem with us blocking users with that rationale. Such users are a common problem. It is not the same as DE. There may or may not be overlap. You can have a nondisruptive NOTHERE user, and you can have a disruptive good faith user. The important aspect of NOTHERE is intent. ~Swarm~ ^{sting} 05:43, 1 June 2020 (UTC)[reply]
Deepfriedokra has it spot on, and TonyB is correct as well: the user behaviors which lead to NOTHERE blocks will inevitably lead to a block under whatever rationale seems to the blocking admin to fit. In other words, those folks are going to get blocked, so why would be get rid of a rationale which is so useful and has widespread support, judging from the number of admins who utilize it. Beyond My Ken (talk) 06:09, 1 June 2020 (UTC)[reply]
As one of the few non-admins chiming in, I agree that NOTHERE is perfectly in line with blocks that I would want admins to enact. Fundamentally every edit to this project should be to build the encyclopedia. If someone is not editing towards that end, they should not be here. Van Isaac_WS^cont 06:57, 1 June 2020 (UTC)[reply]
Blocking is all about preventing a user from damaging/disrupting Wikipedia, and encouraging a more productive behavior. By blocking a WP:NOTHERE user, you prevent them from encouraging users to not build an encyclopedia, and if we don't prevent that, that will damage and disrupt our editing, collaboration, and productivity. So WP:NOTHERE as a block reason is perfectly acceptable. Pandakekok9 (talk) 07:17, 1 June 2020 (UTC)[reply]
Recently we had an editor who was using their userspace to run a Covid lockdown fantasy Eurovision game for their friends with no other contributions to the wiki. It wasn't very disruptive, but clearly NOTHERE. NOTHERE serves a purpose separate & distinct from Disruptive Editing. Cabayi (talk) 08:38, 1 June 2020 (UTC)[reply]
So blocked for violating the Wikipedia:User pages § What may I not have in my user pages? project content guideline, then. Why not just say so? Also, under WP:NOTHERE, specify "Template:Underline". wbm1058 (talk) 11:35, 1 June 2020 (UTC)[reply]
Because most admins couldn’t tell you what that policy says and shouldn’t have to in order to block someone for acting in a way that obviously shouldn’t be allowed. Also, that policy exists because we don’t allow people to do these things, not the other way around. Even if there was nothing in any policy about people running a game in their user space, it’d be a 100% valid block. Wikipedia does not have due process or prohibitions on ex post facto laws. People are judged on how their actions impact the project, not based on rules that don’t exist. Our policies document accepted norms, but they don’t capture everything that could be harmful to an encyclopedia or collaborative project. If someone is incompatible with the project, they will be shown the door even if there’s not a policy line they are violating. TonyBallioni (talk) 16:00, 1 June 2020 (UTC)[reply]
As others have suggested, Deepfriedokra has summed it up pretty well. NOTHERE is perhaps something of an umbrella term, but it does cover a number of policies and can be appropriate where more specific block reasons are not. And if it's too vague in specific circumstances, a blocking admin can (and should) include additional information. Boing! said Zebedee (talk) 11:44, 1 June 2020 (UTC)[reply]
Copied from my my response at the TfD discussion that preceded this FfC The NOTHERE rationale is useful when "there are multiple or nuanced reasons for a block not captured by single-reason block templates. If I believe the reason for a "not here" block may not be obvious to the blocked editor or reviewing admins, I will also include the specific points of WP:NOTHERE the block pertains to, either in the block log or as a supplement to the template on the editor's talk page". -- Jezebel's Ponyo^{bons mots} 16:53, 1 June 2020 (UTC)[reply]
Here's a recent example of a NOTHERE block that probably should have been vandalism-only. But, does any of this really matter? Is the blockee going to use this information for anything? Is anybody else going to use this information for anything? Do we keep statistics on how many of each kind of block is handed out? -- RoySmith (talk) 18:29, 1 June 2020 (UTC)[reply]
NOTHERE currently has a status of an explanation page which is, if I get it correctly, a kind of an essay. Would it be a good idea to elevate it in status? --Ymblanter (talk) 19:00, 1 June 2020 (UTC)[reply]
- I support its use, but that's a good point. The recent nomination of the template for deletion and the existence of this thread indicate that a more formal basis might be a good idea. Meters (talk) 19:25, 1 June 2020 (UTC)[reply]

I agree, I've long thought we should elevate it to the status of policy, though such a process would likely be contentious. But it is already treated as de facto policy and is very widely used. CaptainEek ^{Edits Ho Cap'n!}⚓ 06:37, 2 June 2020 (UTC)[reply]

One can be disruptive but still intend on building the encyclopedia—such an editor just has a disruptive way of doing so, be that edit warring, bludgeoning discussions, pushing unreliable sources, whatever have you. Fundamentally, the goal of every editor here should primarily be to build and improve the encyclopedia. If that's clearly not what you're here to do, this is the wrong place for you to be, even if you're not being overtly or intentionally disruptive. NOTHERE serves a purpose different than blocks for disruption even though there is often some overlap. Seraphimblade ^{Talk to me} 20:11, 1 June 2020 (UTC)[reply]
- ghfdhfgh Geraki (talk) 10:37, 2 June 2020 (UTC)[reply]
I think it serves an important purpose as a block reason in situations where a user's violations of policy would normally be borderline or would be approached more slowly and cautiously, but are pushed over the edge to an immediate indef by the fact that there is no indication that the user has any intention of contributing to our purpose, on top of their other violations. While their other violations could theoretically be given as the reason, in many cases WP:NOTHERE is the overriding reason why they are being indeffed, with the individual violations just being examples of that; that makes it useful to put NOTHERE front and center. --Aquillion (talk) 03:16, 2 June 2020 (UTC)[reply]
I think it remains a valuable tool, especially in edge cases, or in saving time in trying to categorize exactly what a user did wrong. It cuts down on bureaucracy, and allows us a catchall for new and innovative forms of nonsense. We can't create a blocking policy that forsees every possible malfactor, that's why we give admins NOTHERE discretion. If we removed NOTHERE, those blocks would still happen, but they would be ramrodded into other blocking reasons, such as DE or vandalism, and it would take up additional time and bureaucratic morass. CaptainEek ^{Edits Ho Cap'n!}⚓ 06:44, 2 June 2020 (UTC)[reply]

Blacking out Wikipedia in Support of Black Lives Matter[edit]

Template:Moved to