Wikipedia:Village pump (proposals)/Archive 198

Project-independent quality assessments
See Village pump (idea lab) for discussion on this concept.

Quality assessments define how close we are to a distribution-quality article in terms of completeness, organization, prose quality, sourcing, wikilinks etc. Most projects follow the general guidelines at Content assessment, but some large projects have specialized assessment guidelines. This is to propose adding a |class= parameter to WikiProject banner shell, which can display a general quality assessment, and letting project banner templates "inherit" this assessment. WPBannerMeta will look after the details, so the project banner templates will not have to change.

Projects with specialized quality assessment approaches, which will be recognized by WPBannerMeta using a new custom parameter, can continue to record these assessments on their project banners and link to their specialized quality assessment scales.

Importance assessments are project-specific, showing how important the article is in providing complete coverage of the project subject area. An article may be high importance for one project, low importance for another, and irrelevant to most projects. This proposal does not affect importance assessments.

Banners using article-level general quality assessment are illustrated below:


 * [[File:Article-level assessment example.jpg]]


 * WikiProject banner shell may now accept, validate and display an optional |class= parameter as shown above.
 * WikiProject banner shell may be added to an article talk page with no wikiproject banners, in which case it will populate a general category like Category:C-Class articles
 * If a new WPBannerMeta parameter QUALITY_CRITERIA has the value "custom", the project class will be displayed and used to create categories as at present. The project class will be displayed even if it is the same as the article class. Projects will be canvassed to set this parameter if they want to use custom quality assessment criteria.
 * Otherwise, the project is assumed to follow the general assessment approach, which is true of most projects today
 * WPBannerMeta will retrieve the article-level |class= value (if present) using:
 * If no article-level class value is found, the wikiproject banner will be processed as at present
 * If the wikiproject banner does not supply a |class= value to WPBannerMeta, or if it supplies a value the same as the (non-blank) article-level class, the class will not be shown in the project template, since that would be redundant. The article class will be used to form categories like Category:C-Class Linguistics articles
 * If the wikiproject banner supplies a class value that differs from the (non-blank) article class value, the talk page will be placed in a tracking category and the project class will be used to form categories like Category:C-Class Linguistics articles
 * A future project may consider bulk change to remove |class= values from wikiproject banners where the value is the same as the article level class, and where the wikiproject uses the general Content assessment approach. That is outside the scope of this proposal.
 * A future project may consider bulk change to remove |class= values from wikiproject banners where the value is the same as the article level class, and where the wikiproject uses the general Content assessment approach. That is outside the scope of this proposal.

Project-independent quality assessments comments
Comments? Aymatth2 (talk) 17:58, 6 February 2023 (UTC)
 * @Aymatth2, it might be worth notifying major WikiProjects, especially ones with non-standard assessment criteria. — Qwerfjkl  talk  18:08, 6 February 2023 (UTC)
 * Not sure how to find active WikiProjects - perhaps the top 50 from Database reports/WikiProject watchers? &mdash; Martin (MSGJ · talk) 18:24, 6 February 2023 (UTC)
 * The first on the watchers list is inactive! But I will start working through the active projects on the list. Aymatth2 (talk) 18:33, 6 February 2023 (UTC)
 * I'm a bit confused as to what this is proposing. ― Blaze WolfTalkBlaze Wolf#6545 20:29, 6 February 2023 (UTC)
 * It is a way to put a general assessment of an article quality at the top of the article talk page, and let the project banners "inherit" that assessment. It saves space on the page, and makes it easier to update the general assessment. Projects can opt out and use specialized ways of assessing articles if they prefer. Aymatth2 (talk) 16:06, 7 February 2023 (UTC)
 * Oh ok. Thanks for clarifying. ― Blaze WolfTalkBlaze Wolf#6545 20:42, 7 February 2023 (UTC)
 * Strongly support. This is a long-overdue simplification. There's no need for article-class to be project specific, when the assessment criteria are overwhelmingly not project specific (with a handful of notable exceptions). I especially like the fact that MILHIST can continue using its own assessment standards. I'll also note that this approach has been done on French Wikipedia for more than a decade, and always felt more "modern" to me. DFlhb (talk) 18:21, 6 February 2023 (UTC)
 * Very strong support from me too. This will simplify talk pages and reduce redundancy. &mdash; Martin (MSGJ · talk) 18:25, 6 February 2023 (UTC)
 * Strong support. The current quality assessment structure is an overly-complicated mess; the fact that there are individual assessments given for each project is just one of many ways.  The vast majority of projects just copy-paste the generic criteria into their project space, which adds no value.  Those with legitimate reason to continue to maintain their own criteria (for example: WikiProject Highways/Assessment specifies A list of the road's junctions and landmarks, if appropriate), can still do that.  -- RoySmith (talk) 18:35, 6 February 2023 (UTC)
 * Strong support. I think this is a great improvement. Updating assessments will be quicker for editors (change once, rather than for each project). The banner looks good and communicates clearly. Schazjmd   (talk)  18:39, 6 February 2023 (UTC)
 * Support. Seems like an obvious change to centralize something that's almost universally the same across WikiProjects. Practical considerations: It might also be worth considering how this would affect the WP:RATER tool and whether this should affect Template:Vital article. Thebiguglyalien (talk) 19:06, 6 February 2023 (UTC)
 * Support iff the ability of certain WikiProjects to choose their own assessment is retained if they so desire. But there are many that don't seem to care and there's no need to make those projects assess everything. --Rschen7754 19:09, 6 February 2023 (UTC)
 * Support as the best of both worlds: a default which should pool resources well, with the facility to opt out when necessary. Certes (talk) 20:08, 6 February 2023 (UTC)
 * Support, right now there's generally no difference between different project's ratings, so it's superfluous to mark it in each template. I hope, though, that the technical implementation allows for easy per-project overrides; the video games project, for example, stopped using A-class 8 years ago, so it would be convenient if the template would put those articles into the GA-class video games articles category automatically instead of the deleted A-class one if another project wants to mark an article as A-class. -- Pres N  21:00, 6 February 2023 (UTC)
 * The categorisation should not be affected by this proposal at all &mdash; Martin (MSGJ · talk) 21:05, 6 February 2023 (UTC)
 * Support with an opt-out for projects that have their own criteria. I also propose integrating things better with tools like Rater.js, which makes assessment and proper tagging much easier.  Sounder Bruce  21:25, 6 February 2023 (UTC)
 * Support, strongly. Fundamentally, having each project evaluate an article independently is a fork, generating significant additional work for essentially no benefit. I would further support an opt-out implementation, in which projects are assumed to be okay with the project-independent assessment unless they specifically request to have their own system. I have mixed feelings about whether any projects should be allowed to have their own system. But this is unquestionably a good step along the path to unification. &#123;{u&#124; Sdkb  }&#125;  talk 21:27, 6 February 2023 (UTC)
 * Support: this aligns with common practice, where an article is rated the same class across each project banner, even if the editor who makes this assessment is only a member of a proper subset of those WikiProjects. I think things like Milhist's BL-class are reasons for allowing projects to have custom assessments, not because this is how you'd design a system from scratch but because there are active communities that find these ratings helpful. — Bilorv ( talk ) 21:36, 6 February 2023 (UTC)
 * Support - I think this is a good idea as long as WikiProjects with their own more specific assessment scales are allowed to retain them, such as WP:USRD/A and WP:HWY/A.  Dough   4872   21:55, 6 February 2023 (UTC)
 * Support – This seems like a sensible simplification, and a reflection of how (in my experience) assessments work. I don't think any project I'm involved in uses project-specific criteria, but it's good to keep the opt-out (which, as I read it, is there in the proposal) for projects that do. Robminchin (talk) 22:02, 6 February 2023 (UTC)
 * Support – I think this is a good change per above, and WikiProject-specific ratings could still be kept. Additionally, it solves the issue of topics that do not fall under the scope of any WikiProject not having a class assessment. DecafPotato (talk) 23:54, 6 February 2023 (UTC)
 * Support I don't see how article quality would vary like importance does, so this seems like a pure upgrade to me. I've never really seen an instance of quality differing across projects. ᴢxᴄᴠʙɴᴍ (ᴛ) 00:47, 7 February 2023 (UTC)
 * Strongly Support – This proposal does a lot in an elegant way! I firmly believe this consolidation opens up an easier learning curve for newer editors: We can get comfortable with "the standard" in an incremental way, without always being pulled by multiple (competing? hard to understand?) WikiProjects. Further, as a mobile view reader and editor, I appreciate anything that 1) means less code overall for my thumbs to screw up and 2) clears up space on my tiny screen. Happy, happy all around. — LumonRedacts 01:18, 7 February 2023 (UTC)
 * Support with an opt-out if a project wants it as mentioned above. –Fredddie™ 01:20, 7 February 2023 (UTC)
 * Strong support, long overdue. CMD (talk) 01:30, 7 February 2023 (UTC)
 * support--Ozzie10aaaa (talk) 02:33, 7 February 2023 (UTC)
 * Support, definitely. Abductive  (reasoning) 04:15, 7 February 2023 (UTC)
 * Support, standardization is good. EpicPupper (talk) 04:42, 7 February 2023 (UTC)
 * Comment I can see the advantages on this, with articles rated B or better being the minimum acceptable standard for DYK and ITN. The criteria do differ slightly from those that the MilHist Project is currently using. The main differences are criterion 5, where we require an infobox or images (not hard to do), and 6, which we rejected years ago. I trust that everyone understands that classification up to B is handled by our MilHistBot, so that if this proposal passes, then the MilHistBot will assign a global assessment whenever the article falls under WP:MILHIST (with criterion 6 being always assessed as true). Hawkeye7   (discuss)  05:48, 7 February 2023 (UTC)
 * @Hawkeye7 I don't know what they do at ITN, but I can assure you, having a B rating or better is not a DYK requirement. All we require in the way of quality assessment is that the article isn't a stub. -- RoySmith (talk) 14:52, 7 February 2023 (UTC)
 * DYK Supplementary Rule D2 requires that the article be fully sourced, which is required of a B class article or better. Hawkeye7   (discuss)  18:59, 7 February 2023 (UTC)
 * All articles that rate B or better will meet D2, but there's a lot of other things that B requires which DYK doesn't. -- RoySmith (talk) 20:05, 7 February 2023 (UTC)
 * True, but note that DYK already has certain requirements: A1 requires a 1,500 character minimum, and D7 requires and article "to be complete and not some sort of work in progress". It is likely that if this proposal for project-wide classification is accepted, there will be a proposal to set the bar for DYK articles at B class. It is pretty much the minimum acceptable standard now anyway. Hawkeye7   (discuss)  00:26, 8 February 2023 (UTC)
 * While I've for a while been a member of the "assessments don't matter" school of philosophy, I feel compelled to point out that an article can be fully sourced without meeting other B class requirements such as comprehensiveness, and that doesn't disqualify an article from DYK eligibility. Trying to require all DYK submissions to be B class is also a non-starter when different projects have very different requirements for what B class means. Trainsandotherthings (talk) 16:14, 8 February 2023 (UTC)
 * Start-class articles that are fully sourced but not broad enough in their content coverage are allowed to run at DYK. I think this is a good thing; DYK isn't a mini-GA review, nor should it be. People who produce a good number of well-referenced C-class articles that fail B-class only for their breadth of coverage provide substantial value to the encyclopedia, and we need some system to reward creators while evaluating that sort of work (which is what DYK functionally is). —  Red-tailed hawk (nest) 16:56, 8 February 2023 (UTC)
 * Theoretically yes, but in practice articles that are fully referenced but fail one of the other B-class criteria are quite rare. Hawkeye7   (discuss)  22:49, 8 February 2023 (UTC)
 * Agree (with everyone except Hawkeye7); this will never fly. Except for the GA ones, very very few DYK articles are assessed as B (although I think we have a general problem of under-rating in assessments). I'm appalled that Milhist seem (per Hawkeye7) to insist on an infobox for B-class. This should never be done.  There's no chance of this being accepted at DYK. Johnbod (talk) 19:05, 8 February 2023 (UTC)
 * I may have misled you. Our B5 criterion requires that an article "contains appropriate supporting materials, such as an infobox, images, or diagrams." My own article on Singapore strategy (for example) does not contain an infobox. Hawkeye7   (discuss)  22:49, 8 February 2023 (UTC)
 * Phew! Glad to hear it. Johnbod (talk) 05:18, 9 February 2023 (UTC)
 * From the Content assessment/B-Class criteria, I can say that B1 is enforced at DYK (DYK's rules are possibly a bit more strict). The similarities do kind of end there, though: bolded articles regularly fail B2 and B5. B3, B4, and B6 are... not requirements per se, but there are a lot of cases where a reviewer rightfully wants the nominator to take the article vaguely in that direction if it's too far away, and DYK will generally uphold those requests. I mean, you could make the case that all DYK articles are B-class if you stretch them broadly enough, just because of how much hedging this guideline does. theleekycauldron (talk • contribs) (she/her) 10:09, 9 February 2023 (UTC)
 * Support – While importance can vary by project, class is one parameter that should be universal across the board. InfiniteNexus (talk) 06:22, 7 February 2023 (UTC)
 * Comment French Wikipedia does this, project independent quality setting with project dependent importance, I support this. I think this should be done as a general quality assessment, while each project should have a separate topic specific quality assessment for the topic area of each wikiproject, which generally would not be the same until it reaches A-class or FA-class, where all assessments would need to reach A-class or FA-class to meet that level. -- 64.229.90.199 (talk) 06:25, 7 February 2023 (UTC)
 * Support, yes please. Some projects will probably also want to simplify their criteria (WikiProject Germany has a B-Class checklist but doesn't have the manpower to use it properly); I guess projects should explicitly opt out of using the standard rating scale. —Kusma (talk) 09:12, 7 February 2023 (UTC)
 * I wouldn't shy from opposing this if I felt it deserved it just because 20-odd users all voted 'support' before me, but there's a good reason for that; this is a very sensible improvement, and it does deserve it. It's got my Support, too. I'll have to go find some other Rfc where I can buck the trend, but this is not the one. Mathglot (talk) 10:10, 7 February 2023 (UTC)
 * Support Absolutely. I've same reply InfiniteNexus as above. Articles and individual projects can have their own requirements if need be, but a general guideline would suffice — DaxServer (t · m · c) 15:16, 7 February 2023 (UTC)
 * Support Almost all articles I see have the same assessment for all wikiprojects anyway so this makes sense Terasail [✉️] 17:01, 7 February 2023 (UTC)
 * Some editors just unify the quality assessments across wikiprojects... so that isn't a proper indication of individual topic-area-specific quality (as opposed to general article quality) on Wikipedia right now; unless it's a few missing classes (ie bottom/low/C/A) that some projects have that others don't -- 64.229.90.199 (talk) 03:26, 8 February 2023 (UTC)
 * Strong support May we also standardise the "This article has been checked against the following criteria for B-Class status" from Template:WikiProject Film?-- Laukku  TheGreit (Talk•Contribs) 18:45, 7 February 2023 (UTC)
 * Can we save that discussion for later please? Baby steps ... &mdash; Martin (MSGJ · talk) 20:20, 7 February 2023 (UTC)
 * Support - Crying tears of joy. This will save untold hours of manpower. Support per User:DFlhb. Schierbecker (talk) 19:13, 7 February 2023 (UTC)
 * Strongest support possible This will make things so much easier. And some wikiprojects seem to not have some levels of criteria, leading to articles being rated as, for example, Start Class and C class at the same time. ― Blaze WolfTalkBlaze Wolf#6545 20:46, 7 February 2023 (UTC)
 * A better example is that some projects still don't have Redirect-class or Disambig-class, which are shockingly still considered "Non-standard grades" (I'll propose standardization posthaste on WT:Content assessment). But newbies who don't use the Rater tool would never know it, and would be confused why 3 projects say "Redirect", and one project says "NA". DFlhb (talk) 21:22, 7 February 2023 (UTC)
 * Question How will this affect the unassessed article categories? eg. Category:Unassessed military history articles Will they still be correctly populated? Hawkeye7   (discuss)  00:15, 8 February 2023 (UTC)
 * An interesting question, including the issue of what is "correct". I think the default should probably be that articles are in the "unassessed" categories if the main banner doesn't have an assessment. It shouldn't be too hard to code a category for articles that have a global assessment but not a local one (if the banner says B-Class but the checklist hasn't been filled out, perhaps you would prefer to be in an "unassessed" (or perhaps "half-assed" or something) category for MILHIST). —Kusma (talk) 09:28, 8 February 2023 (UTC)
 * For projects that opt out, presumably including military history, the article will be categorized as unassessed if the project banner does not have an assessment. For other projects, if there is also no article-level assessment. Aymatth2 (talk) 14:43, 8 February 2023 (UTC)
 * Speaking now as the project's lead coordinator, I am not presuming that at all; discussion is ongoing, and if the proposal passes, I will put it to the project for a vote. But this is a make-or-break criterion. ! Every project that opts in will require changes to WikiProject banner shell and to its own project banner template in order for this proposal to work. We  know how many and what articles are covered by the project and what their classifications are. Unless we have a volunteer to preform a great deal of work, I strongly recommend that this be "opt-in" and not "opt-out", as someone from each project will have to work on the template. Start with WPBannerMeta. But WikiProject Military history does not use it (maybe it should) and I don't know how many projects do or do not.  Hawkeye7   (discuss)  22:49, 8 February 2023 (UTC)
 * Opt-in poses a problem since so many WikiProjects are inactive. Couldn't a bot deal with this effectively, avoiding the need for manual intervention? I also agree that Category:Unassessed military history articles should only show articles that have been unassessed by MILHIST (even if the WPBannerShell contains an assessment).
 * BTW, I'd strongly support WP:Content assessment being replaced by the MILHIST criteria, rather than the opposite, but would support MILHIST opting-out if that isn't done. Perhaps a discussion on the enWiki-wide criteria should precede the MILHIST vote? DFlhb (talk) 10:28, 9 February 2023 (UTC)
 * The opt-in projects do not have to do anything. As pointed out above, a bot could at some point run through the articles taking out the class value for opt-in projects when the same as the article-level class value. The opt-in projects could also change their banner templates to stop passing the class value to WPBannerMeta, or this could also be done by a bot, but there is no urgency for such a change. Aymatth2 (talk) 14:58, 9 February 2023 (UTC)
 * The change can be coded within WPBannerMeta without requiring changes to individual banners templates afaik, except if a project opts-out. Ofcourse, there's no rush. If/when the proposal succeeds, every WikiProject should be given ample time to discuss (de)merits of opting-out and making a decision. I have a proposal on how to move forward, but of course necessary adjustments may need to be made as per the wishes of the stakeholders:
 * If a WikiProject decides to opt out: All of its quality ratings, including unassessed remain independent.
 * If a WikiProject does not decide to opt out:
 * If all banners (of the WPs that didn't opt-out) show same quality rating, run a bot to introduce it directly at the article-level.
 * If some banner(s) are unassessed, but all else(WPs that didn't opt-out) have same quality rating, run a bot to introduce that quality rating directly at the article-level, so the unassessed are no longer unassessed.
 * If banners(of the WPs that didn't opt-out) differ between their quality ratings, categorise them for human review, and assign them a proper class at the article-level.
 * If all banners(of the WPs that didn't opt-out) are unassessed, it remains so, even at the article-level.
 * [Slightly unrelated]: I have also seen WP:WikiProject India to have a parameter for last assessment date, which in my opinion should be introduced more globally at the article-level, to have a rough idea of what articles among the millions may have improved/degraded in quality over periods of time. This one probably requires separate discussion, but if it gains support, it would be easier to implement both proposals together. &#8212;CX Zoom[he/him] (let's talk • {C•X}) 16:56, 9 February 2023 (UTC)
 * @Hawkeye7, re WikiProject Military history does not use it (maybe it should) and I don't know how many projects do or do not. see Category:WikiProject banner templates not based on WPBannerMeta. Only 3 WikiProjects don't use it. These should probably all be converted. — Qwerfjkl  talk  18:58, 9 February 2023 (UTC)
 * I don't think WP Vital Articles needs to switch, since it's always outside the WPBannerShell, so that leaves two. I'm only decent at template editing, but I'll try to help for the MilHist banner if Hawkeye7 agrees on the change. DFlhb (talk) 19:08, 9 February 2023 (UTC)


 * That is a generous offer. This would need to be carefully tested in the sandbox; the number of articles is large, and the template is complicated. A Bot run may be needed to aid the conversion. Hawkeye7   (discuss)  20:04, 9 February 2023 (UTC)
 * Support long overdue. HouseBlastertalk 01:13, 8 February 2023 (UTC)
 *  weak support  as it will make it easier for project assessors. But it is not that important to get right. Graeme Bartlett (talk) 11:35, 8 February 2023 (UTC)
 * Support and hopefully this would include a new tracking category for globally unassessed articles, whether they have a Wikiproject attached or not.  Pinguinn     🐧   12:35, 8 February 2023 (UTC)
 * Support Ajpolino (talk) 15:20, 8 February 2023 (UTC)
 * Support This will eliminate a massive "backlog" which attempting to clear manually would be a massive waste of time. Trainsandotherthings (talk) 16:09, 8 February 2023 (UTC)
 * Weak support. So long as there is some ability for individual WikiProjects to maintain individual quality assessments that are uncommon but nonetheless useful (such as A-Class), then I would support this. I do not support giving MilHistBot a veto power over global quality assessments; global quality assessments should be given by the global criteria, and MilHist should be free to separately list its own rating if the WikiProject dissents from the quality assessment performed by the community. That being said, this will save editor time, and I look forward to the implementation of this across EnWiki. —  Red-tailed hawk (nest) 16:36, 8 February 2023 (UTC)
 * I want to assure you that I have no intention of that. This proposal is on that basis of Content assessment and any project that opts in will need to accept that. Hawkeye7   (discuss)  22:49, 8 February 2023 (UTC)
 * Weak support echoing almost entirely the comment above, it's fine as long as Wikiprojects such as Military History can still set their own classes for only their WP where they disagree e.g. they want A-class, which isn't commonly used, and therefore the general rating should never be A-class. It will benefit articles with many WPs listed, and only half of the WPs have been assessed for quality rating, even though generally it should be the same for all WPs. Joseph2302</b> (talk) 16:48, 8 February 2023 (UTC)
 * I don't understand why there's a dozen or so comments which assume that there's any doubt as to whether MILHIST can keep its own grading criteria, when that's a fundamental part of this proposal. The WP:VPI discussion that preceded this proposal extensively discussed ways to let WikiProjects retain their own criteria. DFlhb (talk) 16:54, 8 February 2023 (UTC)
 * It may make wikiprojects with their own quality assessment criteria a bit more visible, so an editor making a change to the general assessment may leave it to a project member to change the project assessment. Not sure if that is good or bad. A bot could perhaps be developed to flag articles with wide variants in assessment values such as "stub" in general and "B" for milhist, or vice-versa.. Aymatth2 (talk) 18:06, 8 February 2023 (UTC)
 * Support Looks good, no real concerns with the proposed set-up. 74.73.224.126 (talk) 21:36, 8 February 2023 (UTC)

I think you can go ahead and implement this; I have removed it from WP:CENT as it's clear enough at this point. ~ ToBeFree (talk) 22:18, 8 February 2023 (UTC)
 * I think the discussion should be allowed to run a bit longer. Don't want anyone saying it was rushed through. Aymatth2 (talk) 14:58, 9 February 2023 (UTC)
 * Would you think the same if all support had been opposition instead? ~ ToBeFree (talk) 18:24, 9 February 2023 (UTC)
 * No. If there had been solid opposition there would be no point wasting time. But a weekend editor may identify a roadblock. I would be surprised, but this has waited more than 15 years so a few more days will not hurt. Aymatth2 (talk) 00:00, 10 February 2023 (UTC)


 * Support, I have thought this was a good idea for years. -- Jayron <b style="color:#090">32</b> 19:14, 9 February 2023 (UTC)
 * Support with a question: how will this affect the situation of articles that are currently asssed for inactive Wikiprojects only? Will those assessments be automatically restored and piped to the general assessment scheme? --<sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; reply here 05:30, 11 February 2023 (UTC)
 * This is apparently a quite common thing with around 25000 pages impacted according to my quick PetScan. Definitely something that should be considered while implementing. --Trialpears (talk) 13:50, 11 February 2023 (UTC)
 * Support in principle, Will there be any way to see what changes are made relating to a specific project?, like which B-classes get downgraded to C or start and which C or start end up as B? &middot; &middot; &middot; Peter Southwood (talk): 14:59, 11 February 2023 (UTC)
 * See my comment above: Special:Diff/1138422273/1138428686. If all projects assign same class, that class will be made the global-class by a bot. If projects differ among themselves, they will be categorised for human review, and a human will decide what happens with it. &#8212;CX Zoom[he/him] (let's talk • {C•X}) 15:25, 11 February 2023 (UTC)
 * Support. Long overdue. If there are many ratings per article, there ends up being a de facto/consensus rating anyway, such as what is used in Metadata gadget. To whoever ends up implementing this, we should consider using the mw:Extension:PageAssessments improvements that were made in recent years, if they haven't been fully implemented. czar  17:58, 11 February 2023 (UTC)
 * Very strong support. Overdue change, making assessment much more streamlined. Clyde!Franklin! 12:17, 13 February 2023 (UTC)

Collapse hide certain notification boxes at the top of an article
Some boxes like notifications that an article may be merged or split might not be something a passing user would want to know. Perhaps having those contained within a pre collapsed box would be better. Or maybe a generic notification that there are administrative (or something) things to be aware of and going to the article talk page gives more information.

2600:6C4E:1200:1E85:B409:AC04:8255:CFA1 (talk) 16:26, 15 February 2023 (UTC)


 * Every reader is a potential editor, and if they don't know what might need fixing in an article, they can't do it. 331dot (talk) 16:38, 15 February 2023 (UTC)
 * Also, this would be in violation of MOS:COLLAPSE. Collapsed content can often be harder to access for readers on mobile devices and particularly on screen readers. <b style="color:#0033ab">Joseph</b><b style="color:#000000">2302</b> (talk) 16:43, 15 February 2023 (UTC)

Strip Draft prefix from 'Possible backlinks'
The 'Possible backlinks' link (left sidebar under 'Tools') is very useful for helping to integrate new articles into the encyclopedia, as is recommended by the lead sentence at MOS:LINK and at WP:Orphan, but it doesn't work while an article is still in Draft space. I often develop in Draft space, and one part of my launch plan is the preparation of a set of articles from which backlinks should be added. I still use the tool anyway, but the default result set is always zero results, and I have to manually delete the 'Draft' prefix in two places. That shouldn't be necessary, and may leave some editors persuaded that there really are no useful article backlink candidates. Can we get this useful tool updated to drop the prefix, so users can more easily prepare their backlink article set? Thanks, Mathglot (talk) 21:56, 15 February 2023 (UTC)


 * I assume you're referring to User:Lourdes/Backlinks. You should ask Lourdes directly. Nardog (talk) 22:03, 15 February 2023 (UTC)
 * Oh my gosh, you're right; I've had that script installed for so long, I completely forgot, and thought it was part of the standard mw installation (it ought to be!). I'll move this request to her TP; thanks for the heads-up! Mathglot (talk) 22:13, 15 February 2023 (UTC)

Adding 'Use ... English' maintenance templates
Hello all. Myself and User:Ser Amantio di Nicolao have been adding 'Use ... English' maintenance templates (e.g. Template:Use British English) to articles that deserve them en masse utilising AutoWikiBrowser, however another admin has suggested that we gain consensus before continuing doing this. I believe the argument against was that it's [neither] necessary or desirable to place that tag on tens of thousands of articles (see this short discussion). A bot was suggested to carry out this purpose, however I believe that the nature of these tags, i.e. garnering context from the article itself, requires a human edit. Neither of us see anything undesirable about adding this maintenance template per se, however we both paused our efforts until some sort of discussion had been had. Any comments on this would be most welcome. Thank you and best wishes. SɱαɾƚყPαɳƚʂ22 (Ⓣⓐⓛⓚ) 19:58, 6 February 2023 (UTC)
 * I would tend to agree that these edits are unnecessary, and making thousands of unnecessary edits is undesirable. Unless there has been some kind of editing history on a particular article that would suggest this template is needed, then it is probably better not to add it. PS, I note that it seems to be classified as a maintenance template, but it really is not a maintenance template because no maintenance is required on these articles. &mdash; Martin (MSGJ · talk) 20:24, 6 February 2023 (UTC)
 * To be frank, I think the problem is with the template. What purpose does the template serve? Perhaps the idea is so discrepancies like a Use British English article containing "color" (not "colour") are automatically identified, but I'm not convinced that this is worth the wikitext it takes up at the top of the page. There must be a better way to do this. I can't really fault the editors here for adding a tag to applicable articles, but I don't think their actions are useful. — Bilorv ( talk ) 21:41, 6 February 2023 (UTC)
 * I see the value in having an explicit statement that a given variety of English is used on an article when it is not obvious which should be used (Seattle and Tony Blair are obvious, Acre isn't), especially if the article has had to be actively cleaned up from multiple varieties. I think bots can (or at least would have the capability to) standardise in some cases, e.g. adding or removing the spell=us parameter from . Thryduulf (talk) 22:42, 6 February 2023 (UTC)
 * Over half the audience won’t care either way, as they are neither British nor American….. ;) —Th e DJ (talk • contribs) 00:02, 7 February 2023 (UTC)
 * If only there were a way to make everyone happy. There could be a setting in your preferences asking what your preferred ENGVAR is and words like,  , etc. were templated to conform to your ENGVAR regardless of the topic's ENGVAR.  Number templates could default to lakh and crore instead of thousands and millions for our Indian readers.  To me, that is more useful than slapping  on top of a page. –Fredddie™ 01:13, 7 February 2023 (UTC)
 * Not a bad idea, but only if it could be done via some widget or script in your browser, and not if it's visible in the Wikicode, which would pollute the code in a way making it harder to maintain, and likely would have other knock-on effects. Mathglot (talk) 02:02, 7 February 2023 (UTC)
 * Because of things like torch/flaming torch/flashlight, or truck/bogie, it's difficult to do an automated straight substitution without additional markup in the source text in some fashion. Variations like "licence/license" are tricky too, since the spelling depends on whether or not the word is a noun or verb. isaacl (talk) 17:40, 7 February 2023 (UTC)
 * Years ago we had a system (date preferences) in which you could set the format in which dates would be shown in your preferences. It required that all dates be wikilinked in a specific pattern. It was deprecated because it was clumsy, and only worked if you were logged in. Remember, users who are not logged in (most of our readers) do not have preferences available. Donald Albury 02:08, 7 February 2023 (UTC)
 * If the only downside is that "it doesn't work for IP users", then I think that's not a major problem. IP users already miss out on all sorts of benefits, and it's by their own choice. If they are "forced" to view articles in whatever the default English is, I would say that is extremely minor inconvenience. Specifically: implementing Fred's idea would not make any IP user's viewing experience worse than it is now; it would only improve the experience of other users. I don't see a downside to this. Mathglot (talk) 02:15, 7 February 2023 (UTC)
 * It works perfectly on the Chinese Wikipedia, where you do not need to log in to switch between simplified and traditional Chinese (and a few sub-varieties). —Kusma (talk) 09:10, 7 February 2023 (UTC)
 * I thought it was deprecated because of MOS:OL and, on the developer side, concerns over cache-splitting. Anomie⚔ 14:29, 7 February 2023 (UTC)


 * Disagree A number of articles have popped up on my Watchlist, with edit summaries saying, "Use Ghanaian English". Now, I'm not surprised that Ghana has its own variety of English, but honestly, that notice on the page does only one thing wrt my editing at the article: it discourages it, and waves me off, since I haven't a clue about Ghanian English, and even if it's pretty close to Commonwealth or some other English, as soon as I have it under my belt, then the next article that hits my list is going to say, "Use Liberian English", and now I'm going to have to start using that? I've got about all I can handle dealing with US, UK, OZ, NZ, Canadian, and Oxford English, and I'm willing to go out on a limb once in a while for a worthy article in Caribbean or maybe Nigerian English. But as for articles in Ghanaian English and Liberian English and Pitcairn English and all the rest, count me out; someone else can go edit those articles in that case; it's more effort than I'm willing to offer. Mathglot (talk) 01:54, 7 February 2023 (UTC) Clarifying: agreeing with the STOP sign from the admin; disagreeing with placing any more of these. Place the bot in reverse, and have it undo all the ones it did. Mathglot (talk) 01:57, 7 February 2023 (UTC)
 * Lol, I thought that was a joke but Use Ghanaian English is real and is used in 2402 pages, for example Accra added on 29 January 2023. That is beyond crazy. I would like the wikitext to tell me whether to use color or colour (or whether to revert an edit that changed that spelling), but adding stuff like Use Ghanaian English has no point beyond increasing one's edit count. Johnuniq (talk) 02:30, 7 February 2023 (UTC)
 * Not a joke. Most of them have scrolled off my Watchlist but I found this recent one at Kwame Nkrumah. Worse, are these two recent examples:
 * rev. 1136291731 at Accra, with the edit summary, "Use Nigerian English" (Accra is the capital of Ghana), and
 * rev. 1136292968 at Cape Coast, with the edit summary, "Use Nigerian English" (Cape Coast is a major port in Ghana).
 * That's just carelessness. Can someone help me set up an AWB run, so I can place one Trout on Ser Amantio's Talk page for each incorrect edit summary, and a big, golden mega-trout for starting this without consensus? That could be eight thousand trouts, but it's healthy protein, and could help the global supply. Mathglot (talk) 02:45, 7 February 2023 (UTC)
 * I've long wished that the people who have the idea that every country in the world needs to be flagged for its own variety of English would include in these templates' documentation an explanation as to how exactly those varieties actually do vary from American or Commonwealth English when written in an encyclopedic register . I see no need to care about varieties that differ only in slang, or in colloquial registers, or in spoken pronunciation (at least until "SpeakGPT" exists to make natural-sounding spoken versions of articles in an appropriate accent), or the like. Anomie⚔ 14:38, 7 February 2023 (UTC)
 * The issue is that documenting all of the differences would be tedious and no one is interested in doing the work (true for documentation in general). Most of the time this probably isn't a big deal if someone puts "color" or "lorry" into an Australian article there are enough Australian editors that they will be converted to "colour" and "truck" with no documentation needed; there's probably also enough Kiwis around that instances fjord will be converted to fiord without us needing to document that peculiarity of NZ English anywhere. On the other hand I'd be surprised if we had even a handful of regular Ghanian editors so without documentation changes will happen only slowly.
 * It's also best to remember that some national varieties of English are tagged separately solely to be polite. There's no functional difference between British and Irish English when written in an encyclopedic register; Likewise for Indian and Pakistani English, but the shitstorm that would ensue from trying to replace all transclsuions of the Irish template with the British one, or the Pakistani one with the Indian one far outweighs any benefit. As a practical matter tools can be instructed to treat the two identically, and it's actually easier for new editors to manually tag correctly per TIES when tag names directly match country names anyway. 74.73.224.126 (talk) 16:14, 9 February 2023 (UTC)
 * I'm not sure that even that isn't a solution in search of a problem. Surely it's better to have sourced content with Us and Zs in incongruous places than to not have the content at all? <b style="color: teal; font-family: Tahoma">HJ Mitchell</b> &#124; <span style="color: navy; font-family: Times New Roman" title="(Talk page)">Penny for your thoughts? 17:46, 9 February 2023 (UTC)
 * Agree, in fact I suspect most pages are not fully MoS compliant, and in general MoS issues are pretty far down the priority list of editorial standards. 74.73.224.126 (talk) 17:56, 9 February 2023 (UTC)
 * I like my articles to look pretty and be neatly formatted and consistent throughout. But most of all I like them to be informative. <b style="color: teal; font-family: Tahoma">HJ Mitchell</b> &#124; <span style="color: navy; font-family: Times New Roman" title="(Talk page)">Penny for your thoughts? 17:59, 9 February 2023 (UTC)
 * Disagree, not seeing what the value of these templates is. The dmy and mdy templates actually have purpose, interacting with the citation templates. The documentation of Template:Use British English says that all it does is add a category, in which case all it does is duplicate the talkpage notices (themselves not always a great use of screen space). CMD (talk) 06:29, 7 February 2023 (UTC)
 * Playing Devil's advocate here a bit: there is a legit value, imho, in having some of them, some of the time: for cases where MOS:TIES doesn't apply but MOS:RETAIN does apply, it's useful to have had someone else go through the article history before me and figure out what the stable usage was at the beginning or has been up till now, so I don't have to figure it out for myself for every article. I wonder if those templates, in articles where there's consensus that they really do help, would work better in an WP:EDITNOTICE, than as a inline template in the article? We don't really need to know what version of English it is, unless we decide to edit it. Mathglot (talk) 10:05, 7 February 2023 (UTC)
 * There is some value some of the time, but that is already provided for by the talkpage templates (which are indeed sometimes put in edit notices). CMD (talk) 15:41, 7 February 2023 (UTC)
 * I think these are mostly make-work edits and aren't helping editors. Unless a page has had a recurring issue that has since been resolved about dialects this isn't helping editors - and may actively discourage casual editors who should be most concerned with adding relevant verifiable content, not which spelling their prose used. Further, most any massive templating shouldn't be done except by a bot - it just annoys watchers and recent change patrollers. — xaosflux  Talk 14:45, 7 February 2023 (UTC)
 * Deciding on a variant of English to use, and harmonizing a whole article onto it, is good practice when you're trying to bring an article to GA or FA class, but I don't see the point of doing it en-masse. As a side note, while I have no interest in telling anyone what to do, I just don't understand why so much of Wikipedia has turned into menial busywork. Why is it that the vast majority of articles I come across are substantially unchanged from ~2010-2013, save from Wikignoming? Surely article expansion is more rewarding? DFlhb (talk) 19:30, 7 February 2023 (UTC)
 * Exactly. Ppl seem very busy 'standardizing' things to a level that is never achievable (for long) in a public editing model by thousands of (imperfect and untrained) people. It is better to accept certain imperfections and mistakes of the users. It is part of what makes it a wiki. —Th e DJ (talk • contribs) 21:58, 7 February 2023 (UTC)
 * Disagree, per Xaosflux. I can sympathise with the intent, but mass changes can very easily become disruptive and there's no pressing need that justifies it in this circumstance. XAM2175  <i style="color:darkslategrey">(T)</i> 12:33, 8 February 2023 (UTC)
 * No mass addition, although the templates can be useful on a case-by-case basis. Like Mathglot above, if I see "Ghanaian English" I would be quite reticent about touching the article. And FWIW, our Indian articles are generally dreadful, not just for lack of sourcing, but because of the abysmal strings of characters which I understand are supposed to pass for "Indian English". I think the weird capitalisations are mistakes, but they're so predominantly "wrong" (to my USian eyes), that I wonder if there's not actually a system. The grammar, meanwhile, just seems sloppy. Summary: templates are useful, added individually and selectively, but would be even more useful if, as above, there were some clue about what they mean. Stop adding these by bot. &mdash; JohnFromPinckney (talk / edits) 14:36, 8 February 2023 (UTC)
 * We have a long article on Indian English, which in most cases is like British English, but this is a second language to most users, and exists in several registers. Academic Indian prose is virtually the same as British, or intended to be so, but most of our Indian editors aren't academics, and lean towards the colourful Indian form of journalese, just as huge numbers of American editors do towards their local version. Johnbod (talk) 15:49, 8 February 2023 (UTC)
 * No mass addition. Whilst I did appreciate Use British English being added to 5-10 articles I started (as I usually add them myself), I don't see a general need to add them, particularly when it's not clear to the majority of people what the differences between some of these are. E.g. Despite being English, I'm not really sure what the differences between British, Indian, South African English would be (other than Indian articles might use lakh/crore). <b style="color:#0033ab">Joseph</b><b style="color:#000000">2302</b> (talk) 16:32, 8 February 2023 (UTC)
 * a tiny point but I believe that you shouldn't use lakh/crore per MOS:COMMONALITY, the idea being (correct me if I'm wrong) that an Indian reader will still understand "100 million" but a non-Indian reader is unlikely to be familiar with "10 crore". — Bilorv ( talk ) 11:08, 16 February 2023 (UTC)
 * No mass addition, especially for the more specific variants. I agree with Xaosflux's comments about these are mostly make-work edits and aren't helping editors and may actively discourage casual editors who should be most concerned with adding relevant verifiable content, not which spelling their prose used.  Among other things, some of these templates such as Use Trinidad and Tobago English strike me as not helpful - our article on Trinidadian and Tobagonian English seems to be describing it as essentially a dialect more than a standard variety.  I don't think anyone would consider Use Southern American English to be useful, and several of these strike me as a similar level of over categorization. Hog Farm Talk 19:41, 8 February 2023 (UTC)
 * Oppose Far too nuanced a matter to use any mass addition method. -- Jayron <b style="color:#090">32</b> 14:14, 10 February 2023 (UTC)
 * Insufficient data How is the decision made as to which language template is added?? &middot; &middot; &middot; Peter Southwood (talk): 15:13, 11 February 2023 (UTC)
 * No mass addition because as per the templates run a risk of deterring editors who feel they can't write Pakistani English, so their use should be kept to an absolute minimum. They should only be used to relay the result of discussion where there has been disagreement and it's been resolved. Elemimele (talk) 15:57, 13 February 2023 (UTC)

Make some car manufacturer logos available for use on different Wiki languages when creating articles
Hi dear Wikipedians!

I am a car fanatic and I have a request. Please can you make some car manufacturer logos available for use on different Wiki languages when creating articles:


 * Cadillac: Cadillac_(logo).svg
 * Chevrolet: Chevrolet_(logo).svg
 * Donkervoort: Donkervoort_1.jpg
 * Lancia:
 * Land Rover:

Since these logos are the best logos for each of these companies and are with the highest quality and when an user of a different Wiki wants to create an article about these car manufacturers, which is missing on that Wiki and wants to use these logos, can't use them.

Thanks FLORIKRUJA (talk) 19:37, 15 February 2023 (UTC)
 * FLORIKRUJA Non-free images cannot be used cross-wiki, but nothing is stopping you from uploading a local copy if the home wiki allows non-free media. Der Wohltemperierte Fuchs  talk 19:39, 15 February 2023 (UTC)
 * What you are proposing would be a violation of copyright laws. We are not about to leave ourselves open to lawsuits like that for cross-platform convenience. As Der Fuchs points out, different language Wikipedias have different rules about non-free media use in certain limited circumstances. -- Orange Mike &#124;  Talk  21:33, 15 February 2023 (UTC)
 * Also, WP is not for advertising. YTKJ (talk) 21:55, 16 February 2023 (UTC)
 * The reason copyrighted media cannot be uploaded cross-wiki, is that their use is subject to local laws, not American law. For example, "fair-use" provisions don't exist in many countries. On the French Wikipedia, copyrighted logos can be used, but copyrighted screenshots are illegal with no exception (even low-resolution). There may be jurisdictions where the use of copyrighted logos is illegal too. That's why these files are local to each language-specific Wikipedia. DFlhb (talk) 22:12, 16 February 2023 (UTC)
 * I think that’s just covered by fair use Dronebogus (talk) 01:13, 17 February 2023 (UTC)

Make quality ratings of list pages in Wikipedia more specific
I wonder whether it is worth making a proposal for WikiProjects to make their assessments of list articles more specific? If one goes to the article "List of pastries", one can see it was rated "List class" by WikiProject Food and Drink. This tells us WHAT this article is, but does not tell us its quality. My proposal is to introduce the following ranking for Wikipedia lists:

Q. Contains Questionable Entries Start class. Needs to be more comprehensive C. Reasonably comprehensive and accurate, but still requires more work B. A very good list A. Contains accurate information, covers a good range of entries and provides parameters for information that would not normally be accessible from categories or articles.

I shall look forward to hearing thoughts on this proposal. YTKJ (talk) 21:02, 14 February 2023 (UTC)


 * WP:MHA has something like this already. The reason it's not more widely adopted is probably because other WikiProjects don't see the need and/or there's not enough interest. — python coder (talk &#124; contribs) 02:30, 15 February 2023 (UTC)
 * I'd strongly support adopting the MILHIST List ratings wholesale (and frankly, that's more likely to obtain consensus than this proposal; I wish this had been brought up at WP:VPI first, to obtain consensus on which list-ratings to propose).
 * MILHIST's approach just makes far more sense: lists and articles are both subject to the same flaws (sourcing, completeness, comprehensiveness, writing quality), so there's little reason to only have two assessment grades for lists. DFlhb (talk) 22:20, 16 February 2023 (UTC)
 * I can second this proposal. Now that we are working on globalising ratings, we should definitely consider ways to standardise as many quality ratings as possible. &#8212;CX Zoom[he/him] (let's talk • {C•X}) 11:26, 19 February 2023 (UTC)

Thank you User:pythoncoder. I see that there are some lists, such as List of songs recorded by Adele or List of works by Dorothy L. Sayers that have been give the distinction of being "Featured Lists". This is a step in the direction of what I am proposing, but I wondered whether other lists should also be ranked. This might help WikiProjects see which lists require more work. YTKJ (talk) 18:08, 15 February 2023 (UTC)

Creating a preference for skipping to the top/bottom buttons
Earlier this year, I opened up a discussion at the Idea Lab to create buttons that would automatically skip to the top or bottom of a page if you pressed them. It seemed that it should be made into a preference based on the discussion, and I think that this should now be made into a formal proposal, and that is to create a preference for skipping to the top/bottom buttons. Should this be made into a preference? <b style="border-radius:3em;padding:4px;background:#FF67CF;color:white;">‍ ‍ Helloheart ‍ </b> ‍ <span style="display:inline-block;margin-bottom:-0.3em;vertical-align:-0.4em;line-height:1.2em;font-size:80%;text-align:left"> 01:37, 23 February 2023 (UTC)


 * @Helloheart we can't just "create a preference". We can make an opt-in gadget, but step one is writing it. Good news: you (or anyone) can start on that now as a userscript. Once it is ready, we can look in to making a test gadget run with it. —  xaosflux  Talk 01:55, 23 February 2023 (UTC)
 * Note, there are several "to top" and "to bottom" scripts you can try already listed at User scripts/List. — xaosflux  Talk 15:09, 23 February 2023 (UTC)

RFC - restore "talk" from drop down
Ok, so for me, there's a lot not to like about the new layout.

But someone else can start that eventual RfC : )

I just want to focus on one very specific thing: the talk link being moved to a drop down.

Hiding the talk link is a very very bad idea.

We operate on the consensus model here.

Hiding the talk link just reinforces that edit-warring is the way to go.

And no, I really don't care what some off-site discussion was - so I don't need to hear an WMF employee breezily tell me that a talk page link was determined to not be important on Wikipedia. I'm happy to engage in discussion, but don't blow us off by referring elsewhere as if this project does not matter please. (As an aside, and this goes far beyond this simple RfC - But just thought I'd mention that while I respect the WMF in general - I think it's very important - but I'm really not happy about how things seem to be being pushed through, with fewer and fewer discussions being allowed to be "open" for anyone to participate.)

Anyway, if we weigh importance, I think it's easy to agree that the talk link is more important than the watchlist link. So if space really is the issue argued, then swap them. Or maybe combine "alerts" and "notices" to save space. Or whatever other ideas people may have.

Whatever the case, un-hide the talk link. - jc37 19:30, 19 January 2023 (UTC)

RfC Discussion

 * @Jc37, I'm not sure what you mean. The talk page link is just below the page title.<span id="Qwerfjkl:1674160647481:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — Qwerfjkl  talk  20:37, 19 January 2023 (UTC)
 * I think they mean the link to their own user talk page, which is indeed now in a dropdown (unless you have new talk page messages, in which case it's more prominent like before). Matma Rex talk 21:13, 19 January 2023 (UTC)
 * @Matma Rex, I see. But people still get the big yellow notification that they have messages, so I don't see the problem.<span id="Qwerfjkl:1674163330837:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — Qwerfjkl  talk  21:22, 19 January 2023 (UTC)
 * anything - anything that reduces the visibility and/or ease of accessing the talk page is a bad idea. We want people to discuss. We want people to respond to talk page concerns about their editing. Not to get frustrated because they can't find the link, and thus not engage. There are innumerable reasons that hiding the talk page link is really bad. Even just from the optics of suggesting that talk pages are uninportant. I understand that this may seem an innocuous change for some, but when I consider years - decades - worth of dispute resolution, among many other things, this just really really seems an incredibly bad idea.- jc37 21:46, 19 January 2023 (UTC)
 * @Jc37, so your problem is that people might get talk page message, dismiss that notification, and then not know how to find their user talk page and respond?<span id="Qwerfjkl:1674165549494:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — Qwerfjkl  talk  21:59, 19 January 2023 (UTC)
 * One, of several. Anything we can do to get people using talk pages, the better. We've repeatedly seen that initial talk page usage helps bridge the learning curve gap for people to turn into regular editors. It's part of why we encourage the community aspect of Wikipedia. Learning how to thread discussions on a talk page can lead to being confortable to add to lists, to add references, and just merely feeling comfortable to edit a paragraph on a page. These are called "gateways" for a reason. - jc37 22:14, 19 January 2023 (UTC)
 * Most newcomers are using the Reply button, so they don't have to count colons any longer. The learning curve is essentially flat.
 * The Editing team, as a result of Talk pages consultation 2019, considered ways to make talk pages more visible, but it's tricky, and I don't think that they got very far. You don't want the "Talk" tab at the top to be more prominent than the article tab.  You also don't want it to be more prominent than the Edit button.  So at best, it's in third place.  In terms of your own User_talk: page specifically, I think that Growth's Newcomer homepage work has made some difference there. Whatamidoing (WMF) (talk) 23:37, 19 January 2023 (UTC)
 * I appreciate all that. I do. But all I need do is look at the default signature for editors to see that Wikipedia sees the value of a talk page link. (And yes, I'm aware that mine isn't there - user pages are important too : )
 * But anyway, if it's in third place, then watchlists decidedly aren't. And while I may have done some looking around to find out the difference between notices and alerts, I doubt the average person would know, or care.
 * tried and failed doesn't = push through anyway. I understand the idea of the perfect is the enemy of the good - Wikipedia is a work in progress after all.  but something like this is different, we're being asked to swallow the watermelon whole, with no changebacks allwed due to fait accompli." what's done is done" and all that.
 * I'm not merely complaining to the air, I've actually proposed some suggestions and welcome others. (not adding "support/oppose" sections was intentional). So if you have any ideas for a way forward, I'd be happy to hear them. - jc37 23:54, 19 January 2023 (UTC)
 * I don't think that I want to get in the middle of whether the talk page or the watchlist is the more important thing to show. I imagine that most editors want both.
 * But now I'm not sure that we're talking about the same thing. At the top of an article, volunteer-me sees these options:
 * Article – Talk – Read – Edit – Edit source – View history – Watchlist star – More menu – Twinkle menu
 * This is what I see in the new Vector 2022. Are you seeing something different?  Are you not seeing the "Talk" item right next to "Article"? Whatamidoing (WMF) (talk) 21:45, 20 January 2023 (UTC)
 * @Whatamidoing: I think is referring to one's personal user talk page (OOjs UI icon userTalk-ltr.svg), which is in the dropdown menu for OOjs UI icon userAvatar.svg, rather than a page's talk page (OOjs UI icon speechBubbles-ltr.svg). — Tenryuu 🐲  ( 💬 • 📝 ) 22:30, 20 January 2023 (UTC)
 * Yes I do. Levivich (talk) 16:54, 21 January 2023 (UTC)
 * I think that in the end, anything that improves or makes more efficient the talk page in a non-obnoxious manner should be implemented. In particular, I believe that the talk page is one of the biggest catalysts for recruiting new editors, and if they see a place where not only their voice matters but they can participate in a discussion with consequences they can see, I think we've done a good job at recruiting a new editor. Put another way, to know that the change you helped to support 10 years ago can still be found on the website is, for lack of a better term, a magical feeling.  Invading Invader  (userpage, talk) 21:46, 31 January 2023 (UTC)
 * Very few editors make their first edit on a talk page. Whatamidoing (WMF) (talk) 01:11, 1 February 2023 (UTC)
 * Let editors have the option to unhide the Contributions link, too. Some1 (talk) 01:32, 20 January 2023 (UTC)
 * @Some1 and @Anarchyte - see Village_pump_(technical) for a userscript an editor can use to add contributions to the page top. — xaosflux  Talk 01:03, 21 January 2023 (UTC)
 * The userscript is better than nothing I guess, thanks xaosflux! Some1 (talk) 01:14, 21 January 2023 (UTC)


 * Support - adding the ability to choose which buttons appear outside of the user dropdown menu would be a drastic improvement. Anarchyte  ( talk ) 08:08, 20 January 2023 (UTC)
 * This RFC is a bit misleading in the title, "Talk" in general is not in any menu, this is only about the link to someone's own usertalk page. This is also something that is skin-wide, so would really need to be changed upstream. I don't see this as severely breaking the consensus building model, as most consensus building discussions don't take place on personal user talks, but on article talks or project pages, both of which are already accessible. — xaosflux  Talk 12:32, 21 January 2023 (UTC)
 * The title is: "restore "talk" from drop down" - that is exactly what this is about. the talk link in the drop down. Nothing there misleading at all. - jc37 08:32, 22 January 2023 (UTC)


 * FWIW, started talking about maybe making a gadget for this (see Village_pump_(technical)). However it would be opt-int. — xaosflux  Talk 15:38, 21 January 2023 (UTC)
 * Should not require Javascript. - jc37 08:32, 22 January 2023 (UTC)


 * Support: There is a huge gap between search box and "CX Zoom" at the top, which could've been utilised in better ways. Talk pages should absolutely be visible on up there in order to assist new editors find a link to there. &#8212;CX Zoom[he/him] (let's talk • {C•X}) 16:17, 21 January 2023 (UTC)
 * This is exactly what I was saying about the "log in" button for unregistered users. Whether logged in or not, the WMF seems intent on wasting that space and forcing us to live with it. — python coder (talk &#124; contribs) 17:56, 1 February 2023 (UTC)
 * Support, per CX Zoom. Also support restoring a link to an editors contributions. BilledMammal (talk) 07:38, 2 February 2023 (UTC)
 * As someone who has been using Timeless, I can say that having the user links in a dropdown does not cause me any issue today, and it's second nature to click these links through a dropdown. (I'll move to Vector22 on desktop probably Soon, just have to get off my preferences butt, and mobile Whenever it actually supports mobile.) Oppose accordingly. "Supports" and "opposes" aren't really valuable here. Discussing why you want a link in X or Y position might be, but is still squarely in the realm of design, especially (as I'm sure they will) as they start turning to making the skin friendly(er) for mobile. It might be valuable to decide on what the most valuable links are in the dropdown, rather than having RFCs for this that and the other thing, and see if there can't be some thought put into displaying certain links at certain widths (perhaps as icons, though I know the group that hates the dropdown is probably a concentric set with the group that hates icons). In general though, this dropdown is provided for the set of people who already do have access to scripts, so they always have a workaround to what is/isn't displayed. Izno (talk) 21:08, 4 February 2023 (UTC)

Approval of Enforcement Guidelines without first approving a Code of Conduct
The Wikimedia Foundation has announced that January 17 begins voting on a second attempt to obtain approval of Enforcement Guidelines for the Universal Code of Conduct. There has been no such voting on the content of the Universal Code of Conduct itself.

Does the community Endorse or Oppose approval of Enforcement Guidelines prior to, or in the absence of, any community approval of a Code of Conduct itself?

This RFC is intended to determine and communicate a consensus position. Editors may consider this during current or future Enforcement Guideline votes, and the Wikimedia Foundation may consider it when evaluating how to proceed if the second Guideline vote turns out worse than the first vote. Alsee (talk) 07:53, 14 January 2023 (UTC)

Responses: Approval of Enforcement Guidelines

 * Oppose. I will never approve Enforcement without approval of a code itself. The current Code of Conduct is botched, and without consensus the Code has no legitimacy. Consensus is especially NECESSARY as the Code is almost entirely worthless and ineffectual without active community support for it. Repeated attempts by the WMF to "improve" and re-vote the Enforcement Guidelines can never fix those fatal flaws. The WMF needs to stop trying to steamroll forwards, it is necessary to back up and let the community develop a new Code which actually gets consensus approval. Alsee (talk) 08:07, 14 January 2023 (UTC)
 * This RfC seems founded on a rather narrow understanding of "approval". The UCoC was approved by the WMF Board of Trustees, the legal custodians of this project, who we play a part in selecting. Not all decisions are subject to consensus of editors and local policy specifically recognises acts of the WMF Board as one of those exceptions. The UCoC isn't the first policy to come via this route and we can enforce it with or without guidelines, just like we enforce the Terms of Use, for example. –&#8239;Joe (talk) 10:12, 13 January 2023 (UTC)
 * It's also worth pointing out that the (global) community has already approved the enforcement guidelines – the first vote was 56.98% in favour. –&#8239;Joe (talk) 07:44, 16 January 2023 (UTC)
 * Oppose I didn't participate in this before and I haven't really looked into it all in any depth but it seems to me that if the foundation position is that they must have the code whether community approved or not, then they can impose the enforcement as well and see what occurs. I would not personally approve the enforcement guidelines since by doing so that is in fact approving the code of conduct retrospectively. Selfstudier (talk) 08:18, 14 January 2023 (UTC)
 * Oppose. I agree with everything said earlier, except the conclusion. If it was a mistake and you don't want the mistake repeated you have to speak up. Frederick Douglass expressed it like this: If there is no struggle there is no progress … Power concedes nothing without a demand. It never did and it never will. Find out just what any people will quietly submit to and you have found out the exact measure of injustice and wrong which will be imposed upon them. Following his crystal-clear logic, there is no choice but to oppose. There is another reason to oppose as well: subject the UCoC to community vetting, and it will become a more robust, less ambiguous document. It will become better, more fit for purpose. --Andreas  JN 466 09:21, 14 January 2023 (UTC)
 * I see that an abolitionist's words on fighting against racial inequality are being compared and applied to a code of conduct that prohibits name calling, using slurs or stereotypes, and any attacks based on personal characteristics...like...race . 🐶 EpicPupper (he/him &#124; talk) 00:57, 15 January 2023 (UTC)
 * Oppose. It would be grossly improper for the en.Wikipedia community to in any way endorse a 'code' being imposed without consensus by an outside body. AndyTheGrump (talk) 10:02, 14 January 2023 (UTC)
 * Oppose. The UCoC is well intentioned and contains many sensible rules. However, a similar and more tailored set of rules is already approved and enforced by the English Wikipedia community. The UCoC provides a model which smaller communities may choose to adopt, perhaps even by default, but neither the code nor the new police force that comes with it would be helpful to enwp. The WMF will impose UCoC anyway, but they need to understand that this is a power grab without consensus which conflicts with the community's needs rather than satisfying them.  Certes (talk) 10:59, 14 January 2023 (UTC)
 * Oppose as it is inappropriate to enforce something that is not approved. Current codes and practice handles inappropriate behaviour here. Graeme Bartlett (talk) 21:41, 14 January 2023 (UTC)
 * Oppose Graeme Bartlett said it perfectly. it is inappropriate to enforce something that is not approved. Current codes and practice handles inappropriate behavior here. Adding to that, if WMF insists on pushing guidelines invented by them without community approval, its time to fire WMF and replace them with an organization that has not gone astray and revised the bylaws that allowed that to happen. <b style="color: #0000cc;">North8000</b> (talk) 22:05, 14 January 2023 (UTC)
 * Oppose per all of the above (and more). Paul August &#9742; 22:17, 14 January 2023 (UTC)
 * Alternative - drop the facade of this being something was in any way “approved” by the community, and admit that it is something imposed by the WMF. Let them figure out how to “enforce” it. Blueboar (talk) 22:38, 14 January 2023 (UTC)
 * I am not sure what this vote is about, but I am personally going to vote on Meta to adopt the enforcement. I opposed it last time and raised a specific concern. From what I see, the problematic part was eliminated, and I do not see any further issues with the enforcement.--Ymblanter (talk) 23:39, 14 January 2023 (UTC)
 * Oppose per Alsee. I'm confused how we enforce a thing that has not, itself, been approved. Somehow I misunderstand. Chris Troutman  ( talk ) 03:53, 15 January 2023 (UTC)
 * I voted against the first enforcement guidelines as I thought there were enough flaws that nothing was better than those. I will be supporting the enforcement guidelines when they come up for a vote again, as enough has changed to tip me over. One concern noted above is something we don't have to worry about. No one is going to be compelled to enforce the UCoC, in the same way no one is compelled to enforce UPOL, BLP, Harassment, or any other policy (or guideline) now. In fact this removes a requirement for admin to agree to the UCoC at risk of losing their adminship and that change is one of the reasons I can support the revision. In the end this is a non-neutrally worded advisory RfC about a Wikimedia wide advisory vote to the Board who will make an actual vote. I suspect that this RfC will attract the people who are most opposed to the UCoC and I think it is important for their voices to be heard, in particular their frustration (which I share) about the lack of community ratification of the original guidelines. I also suspect this RfC will be less likely to attract the people who are mildly supportive of the guidelines but who might vote to approve them in the final vote. So I hope everyone takes note of whatever consensus is reached here - because if a consensus is reached it's worth taking very seriously - but at the same time those participating realize the limitations of what that consensus will mean. Best, Barkeep49 (talk) 05:16, 15 January 2023 (UTC)
 * I generally agree with Barkeep's perspective here. — Wug·a·po·des​ 20:43, 19 January 2023 (UTC)
 * Support - I might be the only editor on this project who voted for the enforcement guidelines last time and is looking forward to voting for it again. Yeah, it would have been better for the UCOC to be put to a community ratification vote, but that doesn't bother me so much because that decision was made by different WMF leadership than the one that is handling (well, IMO) the enforcement roll-out (cf. it passed with like 55% or so but they didn't implement it, sort of the opposite of how the UCOC itself was handled). The other reason it doesn't bother me is because the UCOC is such a vanilla document--like, it's beyond me what objections anyone could have to those provisions that aren't nitpicky--other than that it's way longer than it needs to be. But overall, put me down for being glad that there's a UCOC and hopeful that enforcement provisions will be put in place soon. That's been long overdue on this website, which has a terrible, terrible record of self-regulating user conduct over the past two decades. It's long past time for English Wikipedia to grow up and start behaving like the rest of the world and not like the wild west... which means a UCOC, and at least some method of UCOC enforcement by impartial professionals rather than volunteer members of the community. Cf. Twitter, which was improved significantly when they started being more serious about regulating user conduct on that website, and has backslid since those regulations were recently relaxed. Cf. all other social media. Levivich (talk) 20:19, 15 January 2023 (UTC)
 * this is going to come off like snark, but I mean this sincerely: if you believe this you should vote against the UCoC Enforcement Guidelines. The Enforcement Guidelines have the Principle of subsidiarity as a major tenet which means that nearly all enforcement, including all new enforcement enabled on other projects that don't have policies and guidelines that already cover the tenets of the UCoC (unlike us), will continue to be done by volunteers (both in the sense that it's people willing to enforce the UCoC and that they are not impartial professionals). There's a path not taken where professional enforcement of the UCoC is what happens but that was not what either of the committees that drafted the UCoC Enforcement Guidelines chose. Best, Barkeep49 (talk) 02:21, 16 January 2023 (UTC)
 * Oh I know, but I disagree that one should vote against the UCOC Enforcement Guidelines if one believes in professional enforcement... I see UCOC and the Enforcement Guidelines as incremental steps. My prediction: both the UCOC and the Enforcement Guidelines will work, and work well. I think we will perceive no change on enwiki (for the reasons you point out: it's set up to not 'mess' with our developed self-government), and that in and of itself will be a big deal, as the enwiki community will come to realize that this is not a "power grab" or anything like that. I think, give it a few years, but it will help develop trust between enwiki and the WMF, and I hope that trust makes enwiki more comfortable with the idea of professional enforcement, which, btw, I pitched today at the idea lab in case anyone is interested (don't forget to hit that like and subscribe button). Levivich (talk) 04:32, 16 January 2023 (UTC)
 * My own expectation is that there will mostly be "no change" until someone decides to try for another WP:FRAMBAN. And then the UCoC will be used to counter the opposition that ultimately resulted in the WMF's attempted ban being overturned. They've got the overbroad language that can be selectively interpreted, they've got the "protect the victim" language to justify not giving any details, they've got the language allowing them to override local processes if they think local processes "refuse to enforce the UCoC" or "lack will to address issues", they've got language mandating the committee be "diverse" in a bunch of ways (but not viewpoints) that could allow for disqualifying troublesome candidates for not being "diverse" enough, etc. Anomie⚔ 00:05, 17 January 2023 (UTC)
 * In the current proposed enforcement guidelines, there is no requirement that the Universal Code of Conduct Coordinating Committee be diverse. That being said, the process for electing this committee is still to be determined by a yet-to-be formed group. isaacl (talk) 00:40, 17 January 2023 (UTC)
 * There is a requirement that the building committee reflect the diversity of the movement and there is a requirement that the work of the building committee be ratified by vote. So while it's true that there is no requirement for the U4C to be diverse, but I would be amazed if there isn't a requirement by the time the U4C comes into existence. To give a peek behind the scenes, the way that the U4C building committee came to be was because I proposed some diversity requirements for the U4C and the original Enforcement Guidelines drafting committee quickly realized just how much time it would take to hammer those and other fundamental U4C questions out. Best, Barkeep49 (talk) 00:45, 17 January 2023 (UTC)
 * Yes, for brevity I omitted discussion of the building committee. If the entire coordinating committee membership is elected, I can only imagine mandated diversity that covers certain broad characteristics, like geographical region. We'll see what the building committee comes up with. isaacl (talk) 00:56, 17 January 2023 (UTC)
 * It says The U4C’s membership shall be reflective of the global and diverse makeup of our global community. True, the current "such as but not limited to" list is only in connection with the building committee, but I'd be surprised if they didn't wind up with basically the same thing for the committee itself. Anomie⚔ 10:17, 17 January 2023 (UTC)
 * I don't broadly disagree with the intent of creating a UCoC, but I think that it's important to observe that the rest of the internet is (on the whole) even worse at this than Wikipedia, at least aside from smaller communities that are easier to moderate in a hands-on manner. Compared to eg. Facebook or Twitter we are vastly better at handling issues even on talk - I definitely don't agree that (even prior to their current issues) they were doing better than we are. Twitter and Facebook, for the most part, still allow, and have always allowed, things like the aggressive promotion of fringe theories or even "dogwhistle" racism, sexism, transphobia, blatant trolling and so on as long as it doesn't trip one of the few red lines they've set; similarly, aggressive harassment occurs on those platforms quite regularly as long as it doesn't cross one of their few red lines. Wikipedia isn't perfect but I feel that it has generally done better than those, and part of the reason is because of the limitations that come from trying to solve complex social issues via a set of rigid rules established from above with no input or buy-in from the community. I absolutely do not think we should be looking at Facebook or Twitter as the model for how to handle anything, ever, and I'm baffled that anyone would say otherwise - they are examples of what not to do. --Aquillion (talk) 04:24, 16 January 2023 (UTC)
 * is how I'd describe Wikipedia I don't really think that Twitter or Facebook (or any other social media, or reddit, or 4chan, etc.) is any better or worse than Wikipedia, especially not Wikimedia as a whole. I don't have any statistics or way of measuring it, but in my admittedly anecdotal experience, I just don't perceive a difference between the people here, the people on any other social media I've used, and the people out there in "the real world". It's all filled with racism, sexism, -phobias, etc. If anything, I think we're a little bit worse, because we let people vote other people off the website, which gives Wikipedia more of a Lord of the Flies vibe than other sites, IMO...and I say that as a participant in many such votes. It's a YMMV situation I think. Levivich (talk) 04:36, 16 January 2023 (UTC)
 * I suspect we're better than those other sites you name. One reason I suspect this is that none of them have published how many of its users feel safe, unlike us. Best, Barkeep49 (talk) 00:48, 17 January 2023 (UTC)
 * You're not the only one. One of the (many) problems of us only discussing the UCOC in negative RfCs like this one is that we tend not to hear from people who think the UCOC sounds like an okay idea and/or aren't into playing power games with the WMF. That in turn gives the impression that the UCOC is being imposed an an enwiki community that largely opposes it (seemingly taken as writ by many above), which we don't actually have any evidence of. The results of the last vote on the enforcement guidelines (57% in favour) would suggest that a majority are supportive – unless you think enwiki is out of step with the rest of the movement on this, which again we have no evidence of. –&#8239;Joe (talk) 07:59, 16 January 2023 (UTC)


 * Oppose. I don't think that this sort of top-down approach is workable on a site as large as Wikipedia is. We function, to the extent that we do, because of our collaborative culture, and while a UCoC is something we could benefit from, it is completely unworkable to try and impose or enforce one from above without the consensus of the community. --Aquillion (talk) 04:24, 16 January 2023 (UTC)
 * Regardless of the provenance of the code of conduct, I agree with giving the community the opportunity to support or oppose the enforcement guidelines. Those who wish to oppose based on who approved the code of conduct are free to do so. Those who want to ensure that the enforcement guidelines defer to existing enforcement structures and existing guidelines (as per UCoC violations that happen on a single wiki: Handled by existing enforcement structures according to their existing guidelines..., from the revised enforcement guidelines) have a way to influence the process. isaacl (talk) 04:40, 16 January 2023 (UTC)
 * Oppose acting on them, neutral on actual voting on the EGs - I will join the gang in saying that I don't plan on ever (at least, in my role as an en-wiki admin - and I'm not planning on running for any other position in the next few years!) executing a sanction based on the UCOC here. I opposed the last set of enforcement guidelines, but am probably a weak support for the new set - although they *still* lack sufficient bits on the two aspects of right to be heard (evidentiary access and actually being heard). But while the EGs are much improved (and presumably passed by vote) the reasoning everyone else has given for the original UCOC holds true. I don't accept as a reasoning "you could always oppose the EGs if you don't like the UCOC", because that splits the reasoning with everyone who thinks it's already in place.
 * The base policy text is unacceptably vague at multiple aspects, unacceptably blurs necessary and desired actions, and imposes a scope that covers every action any of us will take on this planet. It also lacks a sufficiently codified amendment structure. Per - this technically is a just a community position RfC, with the issues he raises. I suppose we could do another one that would prohibit any on-en-wiki UCOC-based action that doesn't have an underlying (overlying?) en-wiki PAG as well, which could reasonably be viewed as causing quite a lot of conflict for not much practical difference. Nosebagbear (talk) 14:30, 16 January 2023 (UTC)


 * Oppose per all the above. Just because the WMF is intent on imposing this, there is no reason we have to approve it. As has been pointed out, it's so vague anything we do could be an offence, or not, or it could be different based on how we identify, and they could call it anything they want and deal with it however they want. After all, they own the servers. It wasn't meant to be this way.--Wehwalt (talk) 16:46, 16 January 2023 (UTC)
 * I think Barkeep49 has put it in a much better way than I could (see above): In the end this is a non-neutrally worded advisory RfC about a Wikimedia wide advisory vote to the Board who will make an actual vote. Also I'm somewhat skeptic about how to interpret whatever result comes out of this RFC, given there is a community consultation about EG approval via vote, which I'd expect to have higher participation than this RFC. MarioGom (talk) 20:11, 16 January 2023 (UTC)
 * Oppose, per (all) the other opposes. Lectonar (talk) 12:10, 17 January 2023 (UTC)
 * Oppose I have to laugh at the WMF looking to take 'enforcement' action against ENWP users while simultaneously Rebecca MacKinnon (WMF VP, Global Advocacy) is deliberately attempting to interfere in UK legislation that would (potentially) hold tech executives liable for their organisation's misdeeds by mischaracterizing it as an attack on free speech. Only in death does duty end (talk) 13:15, 17 January 2023 (UTC)
 * Support I don't find anything strongly objectionable in the UCOC or the Enforcement Guidelines, nor do I think they will have a significant impact on the way the English Wikipedia is run. Their influence is likely to be stronger on smaller Wikis, giving the WMF more tools to fight institutional capture by bad faith actors. The process was and is imperfect. However, the WMF is holding multiple community-wide ratification votes on these guidelines and has given many clear opportunities for us to be heard over a period of years. They have responded seriously to feedback and made changes as a result. Simply put, I think this is a net benefit for the Wikipedia movement as a whole and probably largely irrelevant to the English Wikipedia specifically. I echo what Barkeep and Levivich have said. —Ganesha811 (talk) 13:32, 18 January 2023 (UTC)
 * Oppose I've seen little effort by the Foundation -- & especially the employees who were driving its adoption -- to discussing why their draft of the UCoC was a good thing. Instead, they engaged in patting themselves on the back for getting the board to adopt it (whom I doubt fully understood the document or how it would be implemented) & how it would be such a good thing. Considering the hostile acts the Foundation have taken against the volunteer communities in the past, I can't support this document without serious reservations & doubts about how it will be applied. One of the features about ruling by consensus is that one has to engage in dialogue with all parties so they know their concerns are heard, & hopefully addressed; there has been little effort by the Foundation to do exactly that. -- llywrch (talk) 21:24, 18 January 2023 (UTC)
 * Oppose even being on the Arbitration Committee and hearing WMF talk about the early parts of the UCOC, I still don't really understand how it is particularly an improvement on the English Wikipedia's current mechanisms, and beyond that the fact that it was foisted upon the community and we're doing all these quasi-democratic showpieces around the thing treated as a fait accompli is beyond insulting, and against the pillars Wikipedia is supposed to operate on. The reality is regardless of what "votes" say about the UCOC, the first high-profile time someone tries to actually sanction someone based on it, we're going to get into a huge pissing contest the likes of the Fram debacle or similar WMF overreach showdowns. If they're so confident in their product, how about the community gets to decide? Der Wohltemperierte Fuchs  talk 20:06, 19 January 2023 (UTC)
 * Comment. I have very mixed feelings, and will make a "comment" instead of a support or oppose. It's very clear that the UCoC is going to be implemented and enforced regardless of what editors say here. The UCoC actually has been approved, just not by us. I will also say that I am actually pleased that the enforcement proposal being voted on now has removed, in response to community feedback, the implied requirement that all admins here would have to sign some sort of loyalty oath. So, on the one hand, I, like many other editors above, would like my opinion here to be heard as finding it offensive that the UCoC is being put into effect without clear community support, and that, as such, it feels wrong to ask us to approve its enforcement. But, on the other hand, I think that the proposed enforcement guidelines are as good as we are going to get, and could have been a lot worse. I'm going to say those two things, hope that both messages are heard, and accept that this RfC will be treated as advisory no matter what. And, more likely than not, en-wiki will adjudicate disputes as we choose to do, and when the day comes that we and the WMF disagree, we will have to fight that out regardless of what the WMF will have done with the input they are getting from us here. --Tryptofish (talk) 20:55, 19 January 2023 (UTC)
 * Oppose I think it is quite evident how little regard WMF has for the community, and pushing though the CoC without community vote and then trying to add the associated enforcement guideline only goes to continue the pattern of disregard. It is not clear to me how another layer of rules changes or improves the situation for the enwiki community. We already have plenty of policy, rules, ToS, consensus and enforcement mechanisms as it is, and the complexity of engaging with Wikipedia already drives people away. I have never seen a serious case of disregard for community standards from any established editor, and the community has plenty of ways to police itself.  Mel ma nn   20:37, 20 January 2023 (UTC)
 * Oppose This word might be used too often, but this is Orwellian. ~ HAL  333  02:40, 21 January 2023 (UTC)
 * Oppose. Nonsensical to discuss how to enforce a policy without first deciding if the policy should be enforced. I plan to propose that we hold an enwiki-only securepoll vote or RfC to determine whether there is a consensus here for either the policy or the enforcement guidelines. BilledMammal (talk) 07:35, 2 February 2023 (UTC)

Discussion: Approval of Enforcement Guidelines
Note: There was a previous version of this RFC, above, with non-trivial discussion. Pinging previous participants: Joe Roe Certes Andrevan Barkeep49 Isaacl Andreas North8000 Red-tailed hawk FunIsOptional HouseBlaster Alsee (talk) 08:06, 14 January 2023 (UTC)


 * @Alsee you should have a single neutral RfC question followed by a signature. But right now this RfC has neither. You could after the question then have background and then responses. Best, Barkeep49 (talk) 15:57, 14 January 2023 (UTC)
 * I think it was poor form to simply discard the responses you received so far and start again. The question posed here is essentially the same as above. –&#8239;Joe (talk) 07:32, 16 January 2023 (UTC)

I am going to copy my statement from above, given I feel it is still applicable despite the improved RfC format: HouseBlastertalk 23:31, 14 January 2023 (UTC)

I am not sure what this vote is about - Ymblanter. I'll try to clarify for anyone unsure what this is about. The issues are (1) the Code of Conduct itself has not been approved by the community, with the predictable result that (2) many people have issues with the contents of the Code of Conduct. It is impossible to "fix" either of those issues by revising the Enforcement Guidelines. The contents of the Enforcement Guidelines are irrelevant here. An "Oppose" vote here presumably indicates an intent to vote against any version of Enforcement Guidelines unless&until we have an approved Code of Conduct. That essentially says to the Foundation that it needs to back up and get an approvable and actually-approved Code first. Alsee (talk) 01:19, 15 January 2023 (UTC)


 * No. ToU has also never been approved by the community, so what? Ymblanter (talk) 08:30, 15 January 2023 (UTC)

Chris_troutman I suspect your confusion/misunderstanding may be sarcasm, but in case it wasn't: The WMF took charge of producing the Code, the Board accepted it, and neither the WMF nor Board felt there was any need for community approval. I believe(?) it was pressure from various ArbComs that persuaded the WMF to graciously grant us permission to vote on the Enforcement Guidelines. They weren't originally planning on that. Praised-be the WMF, for they have so vastly improved relations and respect for the community as a partner. Oops, I think I just sarcasmed. Alsee (talk) 04:17, 15 January 2023 (UTC)

this removes a requirement for admin to agree to the UCoC at risk of losing their adminship Again with the proviso that I have not looked at this in any real depth, that something like this was included to begin with is, I think, concerning, and makes me even less disposed to approve the guidelines. If anyone thinks that not approving them is misguided because of a lack of understanding/appreciation for the situation, I would appreciate a pointer to the relevant material.Selfstudier (talk) 13:58, 15 January 2023 (UTC)


 * The first version of the enforcement guidelines included a section stating that all advanced rights holders should be required to affirm [that] they will acknowledge and adhere to the Universal Code of Conduct. There's nothing in there about what would happen if someone refused to affirm it. –&#8239;Joe (talk) 07:40, 16 January 2023 (UTC)


 * Houseblaster correctly notes that the WMF and the BOT has shown genuine, highly positive steps with their ultimate actions in the fundraising banner dispute. The UCOC issues however, rather significantly predate those. When the WMF finally started discussing ratification for EGs (and they at least were quite clear in those meetings it was the cross-arbcom letter that drove those), they seemed to feel that no-one had raised the desire for ratification on the policy text. When I provided the diff of I and another asking for it during the phase 1 consultations, that particular staffer seemed to ghost me for the remaining discussions - before the WMF just decided to opt for 50%+1 as a ratification margin. No adequate reason has ever been given for why, say, the policy text couldn't undergo ratification attempt alongside the EG's. Nosebagbear (talk) 14:37, 16 January 2023 (UTC)

- continuing this discussion on the effectiveness of Wikipedia's community-based moderation vs. Facebook and Twitter's from-above, since it seems central. Maybe we (or the WMF) should focus on producing those statistics, since we need to understand the problem we're trying to solve. But there's definitely massive volumes of studies on the problems Facebook and (even pre-Musk) Twitter have:   - in comparison, multiple studies have praised Wikipedia's community-based approach - caveat that many of them focus more on content, because that's what we're famous for, but:    Generally speaking, sources that discuss Wikipedia, Twitter, and Facebook's handling of content moderation together describe Wikipedia as a model for getting it right. I think the reason why it feels, anecdotally, like we don't is partially because our community-based system (the "Lord of the Flies" process you mentioned) tends to be loud, especially when dealing with longstanding editors - we just had that a massive incident with Athaenara, say. But that's partially because we do these things out in the open, which IMHO is necessary to catch things that more top-down systems don't and for the moderation system to scale in a way that keeps up with our size. I also think that, as "power-users" who are deep within Wikipedia, we're more familiar with the details of the places where it does fail. My concern is that if we shift to relying more on top-down rules, we'll have less big discussions like that, yes, but that will be because a lot of things slip through the cracks - I think that top-down approaches don't actually work at the scale we operate on. The sometimes riotous discussion is actually necessary for us to consider context and nuance and handle edge-cases that eg. a list of forbidden words wouldn't capture. It's also easier for a blunt top-down system to be abused - yes, sometimes we have issues here where someone is harassed and then snaps and gets in trouble themselves, but at least our processes give us some leeway to observe and understand that context; boomerangs are not uncommon. A more blunt and rigid code of conduct won't necessarily allow for that, leading to victims getting reported and banned by the very people abusing them (not uncommon on Facebook and Twitter.) --Aquillion (talk) 20:09, 16 January 2023 (UTC)
 * I don't feel that Facebook and Twitter are good comparisons to Wikipedia, because whereas they are explicitly for chatter about anything, Wikipedia discussions must be related to Wikipedia editing and thus ultimately to improve Wikipedia. This provides a central guiding purpose that can be used to filter unrelated discussion. De-centralized enforcement of process can allow for more consideration of context, and that is what the code of conduct enforcement guidelines are proposing: disruption on English Wikipedia will continue to be handled by English Wikipedia's policies and enforcement procedures.
 * On a side note, the problem with English Wikipedia's decision-making process is that it's a mass, unmoderated conversation amongst everyone, and that doesn't scale well to more than a small number of people. As a result, we don't necessarily get full consideration of context, as a small number of people can dominate discussion and drown out others, leading to attrition in participants. With no bar to participation, it's easy for anyone to chime in without taking time to become familiar with all aspects of the situation. It's also inefficient, taking up the time of a lot of people, and inconsistent, relying on whoever shows up on a given day. Without refinement, it's not a model for social networks to follow. isaacl (talk) 21:46, 16 January 2023 (UTC)
 * @Aquillion: Yeah, I think as you say because I'm a "power user", I'm more familiar with inner workings, and that's why I beleive "the last great place on the internet" media narrative is more myth than reality--plus, as you mention, they (the studies, the media) focus on content dispute resolution (where I agree we are better than social media), but I'm talking exclusively about conduct dispute resolution (subject of the enforcement guidelines). I don't think there have been many (any?) studies of how well ANI has worked (or AE, or Arbcom, etc.). I freely concede that much of this is very subjective. In the recent massive RFA incident you mention, whether one sees that as a failure or success depends very much on one viewpoint: a block, and an unblock, and a reblock, but not a siteban. It's a glass-half-full-or-half-empty situation.
 * The thing is, I don't see UCOC and UCOC enforcement as a "top-down" situation, mostly because I see us (the community) as being on top. I fully and always will support the community being the ultimate decider of policy, even though I think we should delegate some day-to-day stuff to paid professionals since we have the money. The enforcement guidleines are coming from the community: multiple votes, plus the drafting committee has community members on it, and the trustees who ultimately approve it are elected by the community. It's our document, written by our people, approved by our people. The UCOC was essentially the same except for the community ratification part. To me, neither document are "top-down" (imposed on us by the WMF).
 * While I believe professional first-line-of-enforcement would reduce abusive reporting, the UCOC/enforcement guidelines don't do that, and they leave first-line-of-enforcement to enwiki, so in that sense, it's not changing, which means I don't believe that it'll have an effect on abusive reporting. However, I think the possibility for appeal to the U4C (or whatever it's called) would reduce abusive reporting by allowing another level of review, one of the things I like about the enforcement guidelines. Levivich (talk) 22:14, 16 January 2023 (UTC)


 * Note, voting has opened on the UCOC-REG, I've added it to the Watchlist Notice per the precedent of the last notice. — xaosflux  Talk 00:58, 17 January 2023 (UTC)
 * After 3 days this RfC has, at the time I write this, attracted 22 participants who've given a topline comment in "responses". After less than 1 day of voting, the official ratification has had 151 participants whose homewiki is English Wikipedia. It appears that there will be a consensus of some kind reached here and it should be respected for what it is. But what it is not is a consensus of people interested in the UCoC on English Wikipedia. Best, Barkeep49 (talk) 15:50, 17 January 2023 (UTC)
 * I agree completely. I still tend to think this RfC was created to serve as a fait accompli, and struggle to see how this could be interpreted by WMF in any way other than "micro-consensus". 🌈<span style="color: white; font-weight: bold; background: linear-gradient(red, orange, green, blue, indigo, violet)">WaltCip - (talk)  13:33, 19 January 2023 (UTC)
 * Quick question: Isn't there already a mechanism for users to vote on the enforcement guidelines? Why this second vote?  Surely, anyone can go vote in the SecurePoll vote and have their voice heard that way.  Why are we having a second vote here? -- Jayron <b style="color:#090">32</b> 18:43, 19 January 2023 (UTC)
 * If I understand correctly, the point of this RfC is to discuss whether the SecurePoll is about the right question. ~ ToBeFree (talk) 20:07, 20 January 2023 (UTC)

Enforcement guideline results posted
The results of the vote across all projects has been posted on meta. 76% of editors voted in favor with 3097 editors participating in this second vote. In terms of enwiki participation Best, Barkeep49 (talk) 19:32, 13 February 2023 (UTC)

Desired... a commercial web hosting division of Wikimedia Foundation that allowed wikilinking to Wikipedia
While the Wikimedia Foundation does not offer web hosting services, it does provide free and open source software, including the MediaWiki platform, which powers Wikipedia and many other wikis. Anyone can download and install MediaWiki on their own web server or hosting provider, allowing them to create their own wiki.

Additionally, there are many web hosting companies that specialize in hosting MediaWiki and other wiki software. These hosting providers often offer one-click installs and other tools to make it easy to set up and manage a wiki.

It would be nice if Wikimedia Foundation had a commercial web hosting division that allowed one-way direct wikilinking to Wikipedia's articles. -- Valjean (talk) (PING me) 17:43, 25 February 2023 (UTC)
 * My understanding is that the default install of MediaWiki includes mw:Manual:Interwiki link support for English Wikipedia, and a language prefix can be also be specified which will allow for redirecting to any language (see meta:Help:Interwiki linking for details). This doesn't guarantee, of course, that any given MediaWiki installation will choose to keep this default enabled. isaacl (talk) 18:02, 25 February 2023 (UTC)
 * isaacl, if I understand you correctly, it sounds like there is already a wikilinking function that works from a private installation of the MediaWiki software. Is that correct?
 * It's many years since I had my own free website hosted at Yahoo! GeoCities (yes, I'm that old!). I'd like to start one up again, now that I'm retired. That would be an outward-facing effort visible to the public.
 * I also wonder if it's possible to download the MediaWiki software to one's own PC and just develop content there, then later copy it to one's own website or Wikipedia (if it's compatible with PAG). -- Valjean (talk) (PING me) 19:08, 25 February 2023 (UTC)
 * Yes, the same function that allows editors on Wikipedia to use prefixes such as commons:, meta:, and w: (for Wikipedia) is part of the default MediaWiki software, and there is a default interwiki link configuration. Not sure what policy and guidelines you are thinking of? No one can stop you from writing your own web pages, whether or not you are using MediaWiki software. (If you copy text from anywhere or are deriving your work from someone else's, of course, you are subject to copyright considerations and the licenses offered by the sources.) You can see mw:Manual:Installing MediaWiki for information on installing MediaWiki. isaacl (talk) 19:15, 25 February 2023 (UTC)
 * When I wrote "or Wikipedia (if it's compatible with PAG)", I was referring to content that would go into any article here. They are of course governed by PAG. Thanks so much for the good info. -- Valjean (talk) (PING me) 20:45, 25 February 2023 (UTC)
 * This is not a direct concern of the English Wikipedia. You would be better off suggesting this at . Phil Bridger (talk) 19:24, 25 February 2023 (UTC)
 * That makes sense. Thanks. Is there a specific "village pump" type of place that would be best? -- Valjean (talk) (PING me) 20:45, 25 February 2023 (UTC)
 * See Comparison of wiki hosting services for some places which will host a wiki for you. I use Miraheze; it's free, no ads and uses MediaWiki.- gadfium 19:41, 25 February 2023 (UTC)
 * gadfium, does it allow wikilinks to work between your website and Wikipedia? If so, do red wikilinks work in the same way as here? -- Valjean (talk) (PING me) 20:48, 25 February 2023 (UTC)


 * There is no legitimate excuse for the Wikimedia Foundation, a not-for-profit educational corporation, to run such an operation. It has no relationship to the corporation's purpose for existence. -- Orange Mike &#124;  Talk  01:02, 26 February 2023 (UTC)

Community-authorized sanctions for gender identity
Proposal: Apply extended-confirmed restriction and one revert restriction through general sanctions to all topics relating to gender identity, including transgender and non-binary gender

There are currently ARBCOM sanctions on topics related to gender and sexuality as described at WP:GENSEX. This allows uninvolved administrators to apply and enforce restrictions on related articles and editors in this topic area. Unfortunately, it seems that this is not sufficient to prevent widespread disruption in the topic area. Gender identity is highly contentious and causes significant disruption, and that's unlikely to change any time soon. Furthermore, this topic area is among those most capable of causing real world harm. For these reasons, I'm proposing the creation of community-authorized WP:ARBPIA-equivalent restrictions for this subject. This would entail:


 * Standard contentious topics sanctions as previously established
 * Extended confirmed restriction that disallows IP editors and new accounts to edit articles on these topics or participate in discussions on them outside of the "Talk:" namespace
 * One revert restriction that limits all editors to a single revert in 24 hours (unless it's to enforce the previous point or remove clear vandalism)

It would not replace or change the ARBCOM GENSEX sanction, but it would supplement it in this specific area with ECR and 1RR. To my understanding, this is the highest level of restriction in use under general sanctions, and it currently applies to Palestine–Israel, the Syrian Civil War and ISIL, and cryptocurrency. Before any RfC is created, I'm posting this proposal here to determine:


 * Whether support for this exists
 * If so, at what scope; whether a more limited scope such as transgender BLPs, or more broadly into LGBT topics
 * If there are any stipulations or other considerations that would need to be addressed in a hypothetical RfC
 * That I didn't completely misinterpret how all of this works

If there is support for this proposal, then the next step would be to create an WP:AN RfC to formally authorize these sanctions. Thebiguglyalien ( talk ) 19:59, 22 February 2023 (UTC)


 * WP:WikiProject LGBT studies has been notified of this discussion. Thebiguglyalien  ( talk ) 23:41, 22 February 2023 (UTC)
 * Note, saw this before the notification went out, though I am active in that WikiProject. I'm a pretty active editor across many GENSEX articles, if I'm not patrolling recent changes for any sort of vandalism or disruptive editing, you'll likely find me on a talk page somewhere hashing out content. I've some remarks on each of the three proposals:
 * This seems largely redundant. GENSEX is already a CTOP area through the past ArbCom cases and motions listed on WP:GENSEX.
 * On the surface this isn't a bad idea. As you've alluded to, it would prevent drive-by article space disruption by both IP editors and new accounts, which would certainly cut down on certain types of disruption like inserting deadnames or mass pronoun changes of BLPs, or spurious accusations based on typical anti-LGBT+ canards. However I'm not sure it would actually solve the current overall problems in the content area. From my perspective, one of the biggest problems is that we have a set of established behaviourally problematic editors in this content area, all of whom to my knowledge are extended confirmed, that this restriction would not directly affect.
 * A blanket 1RR seems overly draconian to me. As a tool to prevent disruption, it has its uses on a targeted per-article basis, but as a blanket "all articles are now subject to 1RR". 1RR has by its nature a stabilising effect on articles sure, but that also has the effect of making rewrites, and major additions or removals significantly harder for all involved.
 * In terms of actually fixing what's currently broken in GENSEX, I don't think that this would have the desired effect. I'd also be concerned at the unintentional side effect of scaring off good faith new editors from this area. Maybe I'm wrong though, and I'd be interested to hear from editors in the other content areas you've identified that have these restrictions if they find that those restrictions have actually helped that content area, or if they've just moved the trouble spots elsewhere. Sideswipe9th (talk) 00:17, 23 February 2023 (UTC)
 * @Thebiguglyalien, here's how I'm understanding your proposal.
 * You believe that 99.75% of all registered editors should be banned from editing or writing articles about trans people.
 * 99.75% of all registered editors should be banned from joining this discussion, or any discussion like it, because it's not in the Talk: namespace.
 * If a celebrity reveals a different gender identity today, then only the top 0.25% of editors should be allowed to make our articles comply with MOS:GENDERID. The other 99.75% of editors should be warned and blocked if they try to help out.
 * Editors attending edit-a-thons (such as Art+Feminism) and students in organized classes (there are more 4000 students in more than 300 classes running right now) should be banned from editing anything even remotely related to gender. We should definitely cancel any groups that want to write about women's health or women's politics, because someone might have to decide whether to write "the woman's uterus" or "the uterus", and that's gender-related.
 * And the justification for this is: People who have already achieved not only ECR, but Wikipedia:Unblockable status, can and do perpetuate gender-related disputes for years, while an IP can be blocked out of hand and pages can be protected to prevent them from editing entirely.  Right? WhatamIdoing (talk) 18:55, 27 February 2023 (UTC)


 * The OP has asserted that WP:GENSEX restrictions are inadequate to stop disruption, but there are no diffs or links to anything to back up that assertion. If we're going to supercede the existing ArbCom sanctions scheme, shouldn't we at least have evidence that the current sanctions are not working?  -- Jayron <b style="color:#090">32</b> 19:26, 27 February 2023 (UTC)


 * I'd support adding WP:ARBECR to WP:GENSEX. ARBECR has helped in the WP:PIA and WP:APL and the community recently authorized it for WP:RUSUKR, WP:KURDS, and WP:ARBAA. GENSEX has the same problem with socking/drive-by/inexperienced editors as the other topic areas. For examples of current sanctions not working, just look at the two ANI threads in the GENSEX topic areas right now (which, in my view, have been disrupted by non-ECR editors, on both "sides" of the issue). I think the "99.75%" figure is a lark; most registered accounts never edit; we have 40 million registered accounts; half of them (20 million) never made any edits; only 2 million made 10 edits; only 450k made 100 edits; only 100k hit ECR. And yes, I think it's a good idea to not allow new editors to edit in our most-contentious contentious topics. I'm much less sure about 1RR being effective or necessary; I think I'd only be in favor of that upon a showing that there is so much edit-warring in this topic area that the usual 3RR isn't working. Levivich (talk) 19:34, 27 February 2023 (UTC)


 * Looking at both discussions at ANI (One involving Newimpartial and one involving Tranarchist), and neither has significant disruption from anyone that wouldn't already qualify for ECR. Well over 90% (and possibly vanishingly close to 100%) of the text in those two ANI discussions, involve well experienced editors.  I have spent 5+ minutes paging through them, and while I'm sure a small number of comments in those discussions may be from new or "drive-by" editors, I can't at first glance identify any obvious ones, the vast bulk of the text in those discussions is from very experienced Wikipedia editors.  You're going to need better examples than that.  If nothing else, your examples have served to show places where it isn't a problem; it's clear evidence against needing any ECR sanctions, since so little of those discussions is taken up with any such people.   -- Jayron <b style="color:#090">32</b> 20:22, 27 February 2023 (UTC)
 * @Jayron32: OK, look here (whole page, top to bottom), perhaps a better example of significant timesink from multiple non-XCs. Levivich (talk) 23:36, 27 February 2023 (UTC)
 * Here's a complete list of the edit counts for every person who's ever edited that talk page, in order by the number of edits made to that page (which, BTW, they would all still be allowed to do under this proposal):
 * 22K edits + 14 years
 * 350 edits + 6 years
 * 1300 edits + 1 year
 * 19K edits + 4 years
 * 7K edits + 15 years
 * 250 edits + 1.75 years
 * (sock)
 * 31K + 5 years
 * (IP) 1 edit
 * 300 edits + 2 years
 * 3800 edits, 7 years
 * 95K + 13 years
 * 5K edits + 1 year
 * That's 13 editors. Ignoring the sock, there are only three registered accounts and one IP that would be banned from editing, and all of them could reach extended-confirmed by spending a couple of hours doing some kind of trivial high-volume editing mindless, like removing dead links from ==External links== sections.  Also, the IP and one registered account has made just one edit to the talk page, and another has made only three, so if your goal is to reduce the number of comments, I suggest that excluding the people who don't post much anyway is not going to make much difference.  WhatamIdoing (talk) 23:55, 27 February 2023 (UTC)
 * That's missing the forest for the trees. The edits by the non-XC editors on your list prompted the edits by the XC editors on your list, and wasted their time. There are 8 threads on that talk page:
 * Started by a sock with 14 edits who argues with several editors before getting blocked
 * different non-XC 1AM with poor understanding of sourcing
 * same
 * same
 * productive thread by XC editors
 * different non-XC with poor understanding of sourcing
 * IP general complaint about bias
 * Third non-XC with poor understanding of sourcing
 * All but one thread wasted editor time. It was a lot of time wasted. Levivich (talk) 00:03, 28 February 2023 (UTC)
 * Unless I'm missing something, if ARBECR was applied to the GENSEX content area we'd still have to respond to those threads on article talk pages in some way. ARBECR would only prevent article space disruption, and to a lesser extent related discussions in the project namespace. Sideswipe9th (talk) 00:07, 28 February 2023 (UTC)
 * Yes, this is true. ARBECR would not actually prevent this particular type of disruption (unproductive talk page discussions). I'm just pointing to this as an example of disruption in the topic area by non-XC editors. But look at the article history and you see non-XC editors also having to be reverted there (even by you in some cases, lol), which seems like most of the last six months of edits to that page. I think they're wasting your time Sideswipe but I would take your word for it (and that of other regulars in the topic area) if you thought different. Levivich (talk) 00:13, 28 February 2023 (UTC)
 * I've already put forward my thoughts on the initial proposal above. ARBECR is not a bad suggestion per say, we do get a lot of disruptive drive-by article space edits that need some sort of cleanup and this would put an instant stop to that. But for actually fixing what I see as broken in the GENSEX content area, I don't think it would actually address any of the root problems. Sideswipe9th (talk) 00:20, 28 February 2023 (UTC)
 * You're right, that it doesn't stop all, maybe not even most, disruption. But I see the success of ARBECR in, for example, the Holocaust topic area right now. This controversial high-profile paper comes out, it's all over Twitter and such, it should be bringing in a bunch of new editors and IPs POV-pushing from all angles, but it's not, because all those pages are ECP'd. So if you look, for example, here, here, or here, you still see editors arguing about stuff, maybe disruptively maybe not, but it's experienced editors. What you don't see is the non-XC wasting people's time on talk pages, even though the talk pages aren't ECP'd, but the articles are, and that makes the difference. I think ARBECR is noticeably reducing the amount of disruption there otherwise would be in that topic area right now. Compare with Seymour Hersh or Killing of Tyre Nichols--both high profile but not ECP'd--and you see a lot more disruption there. Levivich (talk) 00:38, 28 February 2023 (UTC)
 * Maybe it's because I'm too tired right now, but it seems like you're saying that ECPing all of the mainspace pages in a contentious content area also has a measurable decrease in disruption in the related talk space? Is this something specific to the examples you've provided, or is it also reflected in other ARBECR areas? Sideswipe9th (talk) 00:44, 28 February 2023 (UTC)
 * Yeah you've got me right: mainspace ECP reduces talk page disruption. I've also seen it in WP:ARBPIA, like Israel. There you see the same thing as in the Holocaust articles: a long, often quite contentious, content dispute on the talk page amongst a number of experienced editors, but not really any disruption by non-XC editors. The article is protected, the talk page is not, and there has been a major escalation in violence in that conflict in the real world in the past month or two, and you'd expect this big influx of new editors, but it's just not there. Which lets the experience editors focus. To my eyes, when I look at Holocaust or Israel/Palestine talk pages, they look very different from gensex talk pages, it's a more focused and productive form of disruption :-D Levivich (talk) 00:48, 28 February 2023 (UTC)
 * Interesting! In that case, I would be open to at least trailing it for 6 to 12 months to see what sort of effect it has. If it does result in the same lessening of disruption on talk pages as well as in articles, I wonder if perhaps it might bring some of the other behavioural problems from other long term editors into sharper focus. As if it does, then it would also indirectly help solve what I see to be one of the root problems in the content area.
 * There's a few procedural niggles that I and probably a few other editors would need some clarification on. Because GENSEX deals with identities, the delineation between when an article is or is not covered under it is a bit more fluid than other content areas. For example how do we handle BLPs where notable person John/Jane Doe comes out as trans or non-binary and changes their name? Sure I can now slap a GENSEX alert onto the talk page, but would I also be able to go to RFPP and say "BLP subject, came out as trans, article now covered under GENSEX ARBECR" and straightforwardly get the page protected? And how would we handle articles that contain or could contain GENSEX content, but where GENSEX isn't the primary topic? For example man, woman, pregnancy, vaginoplasty, phalloplasty. Sideswipe9th (talk) 01:03, 28 February 2023 (UTC)
 * Articles that are in, or that enter, the topic area scope can be tagged. I don't think ECP is applied just as a matter of course, but if/when there is disruption, the RFPP request will get approved as a no-brainer, and often will be indef instead of temporary so you only have to ask once. For articles that aren't mostly in-scope but have some in-scope content, those I don't think usually get indef ECP'd, sometimes temporary ECP, but reverting a non-XC editor is a 3RRNO, so it's still very easy to enforce. Similarly, non-XCs can post "constructive comments and make edit requests" on article talk pages, but they can't vote in RFCs, RMs, AFD, RSN, BLPN or any other project discussion. It also stops non-XCs from creating new articles in scope (in theory, NPP catches it, but if not, it can be CSD'd). Levivich (talk) 01:14, 28 February 2023 (UTC)
 * In re "I think the "99.75%" figure is a lark; most registered accounts never edit" for @Levivich: If you want to count only registered editors who have successfully completed an edit (a number that is smaller than the number who tried), then extended-confirmed excludes about 99.2% of all registered editors.  That still excludes a lot of editors. WhatamIdoing (talk) 00:00, 28 February 2023 (UTC)
 * That's no more convincing than pointing out the pool of XC editors is over 64,000. There are lots of editors. Most are not extended confirmed. Even more are not autoconfirmed. Even more have never made an edit. That doesn't mean anything, and portraying it in terms of "percentage of editors excluded" is rhetoric, not logic. The logic is to exclude inexperienced editors; that fact that 99% of registered accounts are inexperienced is besides the point, since 87% of registered accounts don't currently edit anyway. We have like 50k active editors out of 40+ million accounts, so that's 87.5% (I think) of editors do not currently edit. It's just an example of "lies, damned lies, and statistics." Levivich (talk) 00:16, 28 February 2023 (UTC)


 * I have to agree with Levivich… the proposal is overkill, and would result in many editors (who are not editing disruptively) being restricted from contributing. I see no evidence that our current restrictions and cautions are not working. Therefor, I must Oppose. Blueboar (talk) 20:16, 27 February 2023 (UTC)
 * Yup, overkill. What is actually needed is broader enforcement of Wikipedia policies (e.g. WP:NPOV, WP:RS etc) in BLPs generally, and firmer action against those who use such articles as political battlegrounds. Picking out specific topics to police such content over misses the point - we shouldn't be allowing it to happen anywhere. At some point, I suspect Wikipedia will be obliged to implement restrictions on editing biographies of living persons generally, but until that happens, we should be enforcing existing policy consistently, which this proposal clearly won't do. AndyTheGrump (talk) 01:18, 28 February 2023 (UTC)
 * Everything GENSEX-related reminds me of the hand-wringing that occurred around 2007 over intelligent design (which seemed to take over the entire 'pedia), and then a few years later, the hand-wringing that occurred over climate change, a content area brought well under control by the dedication of and Co.  The problematic editors make the headlines (ANI), but we have a bevy of very experienced editors holding down the fort.  Editing in this area is no better and no worse than in any other areas.  Deal with problematic editors as they come up; don't paint the entire topic area with too broad of a brush. No need to freak out because we happened to have two threads at once at ANI. Sandy Georgia  (Talk)  01:46, 28 February 2023 (UTC)

Statistics
Within articles covered by WP:WikiProject LGBT studies: BilledMammal (talk) 01:26, 28 February 2023 (UTC)
 * 68.7% of edits are by extended-confirmed editors
 * 5.3% of edits by extended-confirmed editors are reverted
 * 32.3% of edits by non-extended-confirmed editors are reverted
 * 78.3% of edits are by auto-confirmed editors
 * 7% of edits by auto-confirmed editors are reverted
 * 18.5% of edits by auto-confirmed but not extended-confirmed editors are reverted
 * 38.4% of edits by non-auto-confirmed editors are reverted.


 * How does that compare to BLPs, and to Wikipedia articles generally? AndyTheGrump (talk) 01:36, 28 February 2023 (UTC)
 * To compare it to BLP's I either need a template or category that marks them as those; unfortunately, I haven't been able to find one. If you know one then I can get those figures for you. For all Wikipedia articles, see this query. It hasn't returned yet, and note that it doesn't cover as long a period of time as the LGBT studies one in order to keep the run time reasonable. BilledMammal (talk) 01:58, 28 February 2023 (UTC)
 * Category:Living people? Levivich (talk) 02:07, 28 February 2023 (UTC)
 * Thank you, query/71867. BilledMammal (talk) 03:01, 28 February 2023 (UTC)
 * BLPs
 * 69.5% of edits are by extended-confirmed editors
 * 3.7% of edits by extended-confirmed editors are reverted
 * 20.2% of edits by non-extended-confirmed editors are reverted
 * 78% of edits are by auto-confirmed editors
 * 5% of edits by auto-confirmed editors are reverted
 * 14.5% of edits by auto-confirmed but not extended-confirmed editors are reverted
 * 39.7% of edits by non-auto-confirmed editors are reverted.
 * All Articles
 * 69.3% of edits are by extended-confirmed editors
 * 3.6% of edits by extended-confirmed editors are reverted
 * 18.3% of edits by non-extended-confirmed editors are reverted
 * 78.9% of edits are by auto-confirmed editors
 * 4.8% of edits by auto-confirmed editors are reverted
 * 13.8% of edits by auto-confirmed but not extended-confirmed editors are reverted
 * 37.6% of edits by non-auto-confirmed editors are reverted.
 * BilledMammal (talk) 03:01, 28 February 2023 (UTC)
 * Are you still taking requests? Could I interest you in running that for articles that are tagged as specific CT topics, like maybe AP2? I'm curious how other CT topics look. Levivich (talk) 03:17, 28 February 2023 (UTC)
 * I don't know a category that would allow me to determine AP2, but I've done:
 * Afghanistan, Pakistan, and India
 * Kashmir
 * Kurds
 * The Troubles


 * If there are any others you want me to run, or category that would be suitable for AP2, I can run those as well. BilledMammal (talk) 05:07, 28 February 2023 (UTC)
 * Thanks! I guess talk pages for all CTs are in Category:Wikipedia pages about contentious topics, but I don't see categories for specific topics, which is too bad, the template could subcategorize by topic. Levivich (talk) 05:22, 28 February 2023 (UTC)
 * I've run one for that category, but I wouldn't consider it a reliable baseline because that template isn't used consistently; it is more likely to be included on contentious articles within the topic than less contentious ones, and because of this the results will overestimate how contentious these topics as a whole are. BilledMammal (talk) 05:39, 28 February 2023 (UTC)
 * (60% of Pakistan edits reverted??) Thanks for this. If I'm summarizing all of the above correctly:
 * For all articles on Wikipedia, edits by WP:XC editors (>500 edits) are reverted ~4% of the time, editors between WP:AUTOC and WP:XC (10-500 edits) 14%, non-AUTOC (<10 edits) 38%
 * For WP:BLPs, that breakdown is XC 4%, AUTOC-XC 15%, non-AUTOC 40%
 * For (some but not all) WP:CTs, XC 8%, AUTOC-XC 28%, non-AUTOC 59%
 * For Kashmir, Kurds, Afghanistan, Pakistan, and India, XC 5-9%, AUTOC-XC 23-34%, non-AUTOC 40-57%
 * For WikiProject LGBT studies, XC 5%, AUTOC-XC 19%, non-AUTOC 38%
 * Does "non-AUTOC" include IP edits? Levivich (talk) 06:11, 28 February 2023 (UTC)
 * Oh, that was an error; 60% of edits are made by extended confirmed editors, 18% are reverted.
 * non-AUTOC includes IP edits, and your summary looks correct to me. BilledMammal (talk) 06:45, 28 February 2023 (UTC)
 * Be careful or they're gonna ban us again Levivich (talk) 07:07, 28 February 2023 (UTC)
 * And what dark magic are you using to conjure these statistics? Levivich (talk) 01:38, 28 February 2023 (UTC)
 * Quarry; the query for the above is here. BilledMammal (talk) 01:58, 28 February 2023 (UTC)

A better way for dealing spam
Hello everyone, I have dealt with spams on newly created pages for a while. I believe they are in the likely patterns,
 * 1) a new user registered
 * 2) shortly added spam links, email address and something like that on their user pages, user sandboxes or user talk pages.

Could we add a filter for tagging them with specific edit summary? For example, new users adding links contain their own usernames or new users adding links on their subpages. It will be better for us to deal with spams. -Lemonaka‎ 18:24, 3 March 2023 (UTC)
 * We already do this sort of stuff. Edit filter 80 is a spam throttle for adding the same link over and over, Edit filter 149 flags edits where the link matches the username.  If you have a specific type of spamlink that a regex-based filter may catch that these aren't, Edit filter/Requested is the place to go.  -- Jayron <b style="color:#090">32</b> 19:32, 3 March 2023 (UTC)
 * @Jayron32 Hi, thanks. I have checked logs of 149 and found they are focused on article namespace, however, most spams are coming from user namespace and subpages of that. Could we expand this filter? Or shall I request on Edit filter/Requested -Lemonaka‎  09:44, 4 March 2023 (UTC)
 * Oh, I found that, [] -Lemonaka‎  09:54, 4 March 2023 (UTC)

Requesting permission to engage in mass-creation
Per MASSCREATION and WP:SEMIAUTOMATED, I request permission to mass-create articles pertaining to villages and municipalities in Turkey, including templates and categories. After creating many articles, was advised to seek permission for such semi-automated creations. Discussion here here. Semsûrî (talk) 17:40, 28 February 2023 (UTC)

Arbitrary break

 * I think you're in the wrong location. Per WP:MASSCREATION, the correct venue to request the right to mass-create articles in a semi-automated fashion is at WP:BFRA.  -- Jayron <b style="color:#090">32</b> 18:50, 28 February 2023 (UTC)
 * It is sort of a chicken/egg scenario. Yes, this will need a BRFA - but the BRFA will want to see that there is community support for the activity. That can occur beforehand (such as here), as part of the BRFA, or separately prior to the BRFA closing. The BRFA will primarily focus on the technical aspects, but will also be looking to see that there is consensus for the activity at all. If this is a completely inappropriate activity for a bot, the proposed operator could just stop now. 18:59, 28 February 2023 (UTC) —  xaosflux  Talk 18:59, 28 February 2023 (UTC)
 * Based on the discussion on their talk page, I don't think they want to use a bot; they're using a boilerplate template to create new articles. Thus discussion at the village pump may be more appropriate. isaacl (talk) 19:04, 28 February 2023 (UTC)
 * Gotcha, so unless a bot-flagged account is going to be used to make "likely good" edits that are autopatrolled, etc - no BRFA will be involved. "Mass-creation" is certainly subjective, if it is going to flood recent changes - bot is the way, else may not be needed. — xaosflux  Talk 19:15, 28 February 2023 (UTC)
 * WP:MASSCREATE says (emphasis added) Maybe we should update that to say that non-bot semi-automated mass creation should be approved at VPR, if BAG doesn't want semi-auto to go to BRFA. Levivich (talk) 20:58, 1 March 2023 (UTC)
 * This! I'm not interested in a bot but to continue my boilerplate template if possible. Semsûrî (talk) 19:43, 28 February 2023 (UTC)
 * Semsuri, can you expand a little bit about the proposed creations, like how many are you planning to make, based on what sources, and give a few examples of what they look like when done? I assume we're talking about articles like Altınbaşak, Üzümlü and Gökçe, Artuklu, in the same form, using the same sources?
 * Also, how is this related to your earlier effort to redirect existing village articles, if it's related at all? (I saw the discussion on your talk page.)
 * I would support either redirecting villages to other articles (that can contain the information about villages), or creating new village stubs (if redirecting is not desirable), I'm just not sure what is the best way, and maybe it's redirecting some and having stand-alone pages for others. Levivich (talk) 19:31, 28 February 2023 (UTC)
 * I can give a very specific estimate by counting the number of villages and towns in the provinces that I haven't gotten around to yet (I'm not planning on creating an article for every notable settlement in the country!).
 * The two primary sources that are recurring in all of the pages are TUIK and e-icisleri - the former gives me info on population history from 2007 to 2022 while the other gives me info on the administrative status of the entity and whether there are hamlets attached to the entity. Ofis, Kızıltepe is an example of an article with the bare minimum. In many cases, however, I have secondary references that allows me to expand the pages to various degrees as seen with these:
 * Bağlar, Şemdinli
 * Ayranlı, Şemdinli
 * Gelinkaya, Midyat
 * Hancıçiftliği, Erzincan
 * The issues with the articles that I redirected last year were plenty including lack of primary references that confirmed their status (some quarters in a town had their own article claiming to be villages), no coordinates, no population, and so on, so I just believed that the easiest thing to do was to redirect them (which was also very cathartic for me). Since then (and having in mind that I had plenty of secondary and reliable references in my library), I believed I could create better articles — even the stubs that I have created are of better quality than the ones we were used to.
 * I'm going to do my calculations now. Semsûrî (talk) 20:23, 28 February 2023 (UTC)


 * My advice… take your time. Go slowly. Do say 5 articles… wait to see if there are any problems… if none, then do 10 and wait… If after a few iterations of this no one is stating a problem, you can ramp up the pace further. Blueboar (talk) 19:36, 28 February 2023 (UTC)
 * You didn't say much about the amount of content within the articles. The worst case scenario that is covered by your request would be a zillion content free stubs with just an "it exists" statement with one reference which supports "it exists"  I took a look at 2 of your articles and they have a lot more content and sourcing than that.  Looking at that and you saying SEMI-automated, you have real articles each with a few sources and a few sections and text covering a few areas and a moderate amount of time invested in each one. .  If so, we're talking about a moderate amount of real articles, not a zillion geostubs. If so, perhaps you could describe that in a few sentences and then I think it would receive affirmation / support here. Sincerely <b style="color: #0000cc;">North8000</b> (talk) 20:13, 28 February 2023 (UTC)
 * What is the overall scope of your endeavor (e.g. 500 articles over 3 months)? — xaosflux  Talk 20:31, 28 February 2023 (UTC)
 * 2,004 since 15 December. Semsûrî (talk) 21:13, 28 February 2023 (UTC)
 * So from my quick calculations, there are around 2.7K articles left. Semsûrî (talk) 20:50, 28 February 2023 (UTC)
 * Articles created so far seem good. I'd suggest Blueboar's approach to start, but this is a good endeavour. DFlhb (talk) 21:08, 28 February 2023 (UTC)
 * The first three articles on that list have 5+ references and material derived from them, multiple sections and represent at least a moderate investment of time on each one. I support continuation of that (or even articles a bit skimpier) and thank you for your work. Sincerely,  <b style="color: #0000cc;">North8000</b> (talk) 21:19, 28 February 2023 (UTC)
 * Looking at the table some of these are appropriate, but the majority appear to be the sort of stub that got Lugnuts into trouble (for example, 100. Yıl, Adıyaman). If Semsûrî limits themselves to the more expansive articles that would be fine, but the majority of the articles are not. BilledMammal (talk) 03:28, 1 March 2023 (UTC)
 * I believe the Lugnuts problem involved mass-use of unreliable sources (as opposed to here, government sources), and violations of WP:GEOLAND; but the article you link above seems to suffer from neither problem. DFlhb (talk) 03:59, 1 March 2023 (UTC)
 * I was referring to the broader Lugnuts problem, that resulted in him being topic banned from creating articles of less than 500 words; the articles listed above are the same sort that resulted in that sanction, and the rate of creation is very similar. I think you are referring to the narrower Lugnuts Turkish village problem, that resulted in him losing autopatrolled and having all the relevant articles deleted. BilledMammal (talk) 04:06, 1 March 2023 (UTC)
 * All of the articles will be expanded with info added to the template:historical populations as you can see at 100. Yıl, Adıyaman expanding these articles a bit. Semsûrî (talk) 09:06, 1 March 2023 (UTC)
 * In some ways that is better, but it makes other things worse; when an article consists of little but a table showing population growth by year it introduces WP:NOTDATABASE issues. What is needed is additional prose, giving information on the history, geography, economy, etc of the location. BilledMammal (talk) 09:12, 1 March 2023 (UTC)
 * I don't disagree that additional prose would make the article better, but the addition of the population chart does not make anything worse, nor does it introduce "WP:NOTDATABASE issues." That guideline is concerned with "excessive listings of unexplained statistics" that "lack context or explanation can reduce readability" and further suggests that "statistics should be placed in tables to enhance readability, and articles with statistics should include explanatory text providing context." In the case of 100. Yil, the population statistics are not excessive and do not reduce readability. Moreover, they are placed in a table (as the guideline suggests), and the article includes explanatory text explaining that there has been a recent decline in population due to climate issues. This seems to be exactly what NOTDATABASE suggests. Cbl62 (talk) 12:29, 1 March 2023 (UTC)
 * The explanatory text providing context and rectifying the WP:NOTDATABASE issues was added after my comment. I would still prefer additional prose and a second source providing WP:SIGCOV, but considering the locations are currently covered by WP:GEOLAND I wouldn't object to Semsûrî's creations if they were all like the current status of 100. Yıl, Adıyaman. For the moment, they aren't, but I understand Semsûrî intends to bring them up to that status; once they do so for the current 2000 I would support the creation of the final 3000. BilledMammal (talk) 13:17, 1 March 2023 (UTC)
 * Yes, I've created a database for myself (User:Semsûrî/Turkeyplaces) where I can keep track on my work. There are many articles that are at the same level or more voluminous than 100. Yıl like Kayalık, Çukurca and Anadağ, Derecik but it would be great to have clear criterias so I don't have to guess whether I've reached a sufficient volume at each article. I'm planning on adding the historical population template to all of the articles and moreover expand the prose based on secondary references. Semsûrî (talk) 19:48, 1 March 2023 (UTC)
 * @Semsûrî: Thanks for answering all these questions. If I understand correctly, for every article you have created (about 2000 so far) and plan to create (about another 2700), there is at least one secondary source (in addition to the databases TUIK and Icisleri). I understand that creation of the stubs with the database sources can be done semi-automatically (with a template), but expansion of those stubs with the secondary source cannot, that requires manual work, and so will take longer.
 * Assuming I understand correctly, here is my question: can you create these articles so that when they are created, the secondary source is listed in a "Further reading" section (even if it hasn't yet been worked into the article as a source)? That way, every article created will have at least one secondary source in the Further reading. Is it possible/reasonable to do? Levivich (talk) 20:00, 1 March 2023 (UTC)
 * Sometimes a secondary reference is used in multiple articles where I change the prose + page in the citation template. So, at times a secondary reference is included in my boilerplate template. I see the point in adding a 'Further reading-section' if there are none utilized as sources and it shouldn't be an issue. Semsûrî (talk) 20:38, 1 March 2023 (UTC)
 * WP:MASSCREATE says, so I think if you are including the secondary source in "Further reading" then that's good enough (even if the source isn't yet cited for prose). That way, anyone looking at the article knows the village has at least one GNG source (the one in Further reading), plus anyone else who wants to expand the article will have at least one source listed they can use to expand it, so I think it would encourage expansion. Levivich (talk) 21:02, 1 March 2023 (UTC)
 * The articles are covered by GEOLAND, and having checked a dozen or so I'm not seeing issues. They appear better than many such stub location articles. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:57, 1 March 2023 (UTC)
 * Support after the discussion above. It isn't a ridiculous amount (2k created, 2.7k to go, <5k total), it's not like 100k of villages in Turkey. Each article would be supported by at least one non-database source (included at least in Further reading, as I understand it), so it's not like an indiscriminate collection (not like every village in Turkey), and it's not just scraping a database and copy/pasting it to Wikipedia. Because of the secondary source, I think it's reasonable to believe the articles will be expanded (at least there exists one source that can be used for expansion, which is more than we can say about other mass-created articles from other users in the past). I don't think redirects would be a good alternative; I think it would make articles like Üzümlü District unwieldy if we merged every village (e.g. Altınbaşak, Üzümlü) into the district article. I'm generally more inclined to see the value in populated, legally-recognized place stubs than other types of stubs (obscure athletes). Finally, WP:SYSTEMICBIAS encourages me to support; we have articles about every abandoned train stop and dirt road in the US; because Wikipedia is so heavily Western, we don't have as many editors who are going to manually create articles about populated/legally-recognized villages in Turkey, as compared to editors who will write about places in the US, so I'm more inclined to say yeah, let's do some mass-creation of expandable stubs about non-Western notable topics to even out systemic bias. Levivich (talk) 21:18, 1 March 2023 (UTC)
 * Conditional Support I would strongly suggest asking a bot coder to include more information upon creation than just population. I would also support the deletion and recreation of ones I started over 10 years ago without much information. It would be much more beneficial for Wikipedia to have near start class articles on these villages than short stubs sitting around which nobody is working on. Much better to do this than redirect to districts as the proposer did in the past. I would oppose a proposal to mass create one or two line stubs like Gökçe, Artuklu. I generally don't like what bots do on Swedish and Cebuano wiki etc but I'm of the opinion that English Wikipedia would benefit massively for a bot to create missing populated settlements which are near start class upon creation and consistent. I did propose something back in 2008 in fact with Fritz. ♦ Dr. Blofeld  14:31, 2 March 2023 (UTC)
 * I'm of the opinion that English Wikipedia would benefit massively for a bot to create missing populated settlements which are near start class upon creation and consistent In theory I would support this; I suspect it can be done well, and if it is the result would be both the creation of new articles and the improvement of existing articles. BilledMammal (talk) 14:43, 2 March 2023 (UTC)
 * In the case of Turkey, I would even include depopulated settlements due to the violent history of the Kurdish region. Kovankaya, Beytüşşebap is unpopulated but still notable enough to have its own article. Semsûrî (talk) 18:33, 2 March 2023 (UTC)
 * CONDITIONAL support Conditional on them having the amount of content and sourcing in the first three of the 4 listed examples, or close to it. <b style="color: #0000cc;">North8000</b> (talk) 14:50, 2 March 2023 (UTC)
 * Conditional support per North8000. I had many of these watchlisted and up until now, it looks like the vast majority have been based purely on lists and statistics like Saray, Nizip, Kilis, Sason and Kulaksız, Sason. Any further creations would ideally include in-depth secondary sources like Gelinkaya, Midyat, Ayranlı, Şemdinli and Bağlar, Şemdinli. Question for : As someone who doesn't read the language, could you explain the political status of these villages? Are they self-governing municipalities, census tracts or something else? I just want to make sure we don't make the same mistakes as past mass creators. –dlthewave ☎ 00:05, 4 March 2023 (UTC)
 * On the village politically, I think Jongerden explains it best: ""The center-village model is best understood against an administrative background. Administration in Turkey is strong in centers, but weak in peripheries. The villages are formally headed by the village-chief (muhtar), who is supposed to implement the law in village affairs and act upon directives of the governor and district officer. In practice, the governor and district officer do not take much notice of village affairs (as long there is no urgent need), and the village headman does not take much notice of the law (so long as he is not forced to), particularly if village custom already provides an accepted alternative method of dealing with a problem". The administrative status of the hamlets, which outnumber villages by almost a third, is unclear. In some occassions the muhtar of a neighboring village has authority over a hamlet, but at other times a formal administration is absent, and administration takes place through customary law."


 * Not mentioned in the quote is that muhtars are locally elected by the village. Semsûrî (talk) 10:43, 4 March 2023 (UTC)
 * Quote is from "The Settlement Issue in Turkey and the Kurds" by Joost Jongerden (page 292) Semsûrî (talk) 10:44, 4 March 2023 (UTC)

Promote WikiShootMe.js user script as Gadget
I am writing to request the promotion of the WikiShootMe.js user script as a Gadget on Wikipedia. The WikiShootMe.js user script is a useful tool that allows users to quickly access the Wikishoot tool page, which displays Wikidata items, Wikipedia articles, and Commons images with coordinates on the same map, won the Coolest Tool Award in 2021.

The user script takes latitude and longitude coordinates from a Wikipedia page and redirects the user to the Wikishoot tool page. This can be very useful for editors who need to quickly locate images and other media related to a particular location.

The WikiShootMe.js user script has been developed and tested by myself and other users, and we believe it meets the criteria for promotion as a Gadget on Wikipedia. I have provided a link to the script below, along with an installation guide for interested users:

Script link: User:Gopavasanth/UserScripts/WikiShootMe.js Installation guide: User:Gopavasanth/UserScripts More about the tool: WikiShootMe on Meta-Wiki.

Thank you for your consideration. Please let me know if you have any questions or need further information.

Sincerely, Gopavasanth (talk) 05:51, 5 March 2023 (UTC)

Adopt MILHIST's C-class quality assessment criteria
WikiProject Military history's assessment criteria can be viewed at WP:MHA. Their C-class criteria are:
 * The article meets B1 or B2 as well as B3 and B4 and B5 of the B-Class criteria.

I am proposing we adopt this for WP:ASSESS's C-class criteria. B6 would not be required for C-class; note that some projects don't use B6.

Rationale: DFlhb (talk) 13:07, 17 February 2023 (UTC)
 * The current distinction between Start-class and C-class is somewhat subjective.
 * This provides much more objective criteria for C-class, which will make our ratings more consistent across articles.
 * Grades provide "gamification" that incentivise article expansion, so the more precise they are, the more effective the incentive is.
 * These criteria provide clearer guidance for editors wishing to improve Start-class articles, who may be unsure of where to start.
 * When one B-criteria is filled, the B-criteria are shown by default on Start-class articles, which this proposal would not affect.


 * I agree that the line between Start and C is blurry. But as someone who edits in topics that have some overlap with MILHIST, I've found that particular assessment system and the B-checklist tool to be more of a mild annoyance than anything. I suspect you could come up with an article that's only a few sentences long but would technically meet this set of C-class criteria. Thebiguglyalien (talk) 15:30, 17 February 2023 (UTC)
 * Wouldn't that fail B3? DFlhb (talk) 11:28, 18 February 2023 (UTC)
 * You don't need much content to make a lead and a section. Thebiguglyalien (talk) 16:15, 18 February 2023 (UTC)
 * I see. I've noticed that even short MILHIST articles tend to be far better sourced than for other WikiProjects. Maybe that has at least a little to do with their criteria incentivising either completeness or sourcing, while our current criteria just incentivises completeness? Seems like a bad incentive. DFlhb (talk) 16:57, 18 February 2023 (UTC)
 * I hate to ask this, but does anyone outside of MILHIST and I guess the 1.0 Editorial Team actually care about the non GA/FA article criteria? Sideswipe9th (talk) 23:31, 17 February 2023 (UTC)
 * From my experience at talk pages, apparently NO, at least for C/Start class. &#8212;CX Zoom[he/him] (let's talk • {C•X}) 08:43, 18 February 2023 (UTC)
 * MILHIST very much cares about b-class, with the others being less significant. Hog Farm Talk 16:31, 18 February 2023 (UTC)
 * Very much so. C class did not originate at MILHIST. It was brought in by other projects and adopted by MILHIST for conformity only after some debate. I argued against it; I did not think creating an additional class between Start and B was worthwhile, given that B is the minimum acceptable standard for any article. The outcome was not what the advocates expected. It resulted in the criteria for B class being hardened. Where once an article could have an unreferenced sentence or two and still be waved through as B class, now such articles were now graded C. Over time the role of C class has become that of identifying candidates for elevation to B class through a small amount of work. Currently MILHIST has about 20,000 articles rated B class and 60,000 as C class. Hawkeye7   (discuss)  18:40, 18 February 2023 (UTC)
 * WP:MILHIST has some advantages because of long continuity among the project's ranks. Hawkeye7 has been among those leading the project for many, many years and the respect I feel for his experience, competence, dedication and long first-hand knowledge of Wikipedia's history has been earned. I'd rather not speak for other wikiprojects but C-class can be, as Hawkeye7 points out, a useful flag that moderate diligence has been exercised in review and that only comparatively small effort needs be made to get the work to B-class thresholds. The required effort to promote between start and B-class reviews is substantial. BusterD (talk) 19:44, 18 February 2023 (UTC)
 * At WP:HWY, this means that there are at least all the required sections (Route description, History, and Junction list]], but that they are not necessarily complete or fully sourced. WP:HWY/A. --Rschen7754 19:55, 18 February 2023 (UTC)
 * I just thought of another potential benefit: with this change, all assessment grades will have clear, specific criteria (except of course Stub). It doesn't just clarify C; it also defines Start-class as any article that fails both B1 and B2, or fails any of B3, B4, B5. DFlhb (talk) 18:34, 19 February 2023 (UTC)


 * Should I turn this into an RFC? Would be nice to get wider community participation ruling on this one way or another, before we switch to project-independent quality assessments. DFlhb (talk) 20:35, 28 February 2023 (UTC)
 * Oppose per WP:BURO. The proposal is incomprehensible jargon because even an experienced editor like myself has no idea what those various B numbers are.  And, as  says, what's the point of these fine distinctions?  For example, I attend discussions at WP:ITN/C where article quality is an important consideration for every nomination.  Project ratings get no respect there.  I have suggested that they be used but most editors use their own assessment based upon the number of citations, the amount of prose and little else. Andrew🐉(talk) 10:28, 4 March 2023 (UTC)
 * IMO, the key point for C-Class is content (B2). Format (B4) and supporting materials (B5) are really immaterial for C-Class. I am glad to pass an article for C-Class if it meets B2 but fails all of B4 and B5 and B6.-- Lopullinen 15:44, 5 March 2023 (UTC)
 * I'd be fine with defining C-class as either B1 or B2, and dropping the rest, to echo your and Andrew's comments (or dropping the B-jargon and saying "citations" and "coverage" or equivalents. DFlhb (talk) 15:52, 5 March 2023 (UTC)

Request to mass create ISO 3166-2 codes as redirects
Hi all! I'm planning to undertake a task that would involve creating a large number of redirects to point the ISO 3166-2 country subdivision codes to the relevant articles on that country's subdivisions. Unless an page with a title matching a country subdivision code already exists, this process would create a redirect at that title to point the relevant subdivision. Some of these already exist as redirects (e.g. the subdivision codes for Argentina), but that set of redirects is currently incomplete. I realize that I could probably do this manually without issue, but it would take quite a while. I would hope to eventually semi-automate the process of creating these, since creating 5000 redirects and adding tags can be tedious if done manually. For that reason, I am asking for consensus around whether this sort of redirect creation is looked upon favorably by the community before I go ahead with mass creation. — Red-tailed hawk  (nest) 16:59, 4 March 2023 (UTC)


 * Can you provide a few examples? Also, what practical problem would this solve?  Sandstein   18:56, 4 March 2023 (UTC)
 * Sure! This would mean pointing things like UZ-NG to Namangan Region, ZM-05 to Northern Province, Zambia, et cetera. I think that this is a reasonable search term; I've had to type the codes into google to figure out what they've referred to when looking at datasets in the past. We have R from ISO 639 code for language codes, and the plan would be to do a similar thing for subdivision codes—so long as there isn't any conflict with existing redirects. — Red-tailed hawk  (nest) 19:19, 4 March 2023 (UTC)
 * With respect to the problem it would solve, it would allow users to type in the ISO code in the search bar and then be taken to the article on the corresponding geographic entity. Users currently can't do this. — Red-tailed hawk  (nest) 19:21, 4 March 2023 (UTC)
 * Personally, I prefer to defer to search engines to figure out the best destination for a search term, and not try to make every reasonable search term a redirect. I appreciate, though, that others have different views. isaacl (talk) 23:03, 4 March 2023 (UTC)
 * I tend to use Wikipedia where possible since it's ad-free and respects users' privacy, hence I'm in favour of creating redirects such as these. <span style="font-family:Garamond,Palatino,serif;font-size:115%;background:-webkit-linear-gradient(red,red,red,blue,blue,blue,blue);-webkit-background-clip:text;-webkit-text-fill-color:transparent">Daß Wölf 20:38, 5 March 2023 (UTC)
 * Sure; I think it's better to improve Wikipedia's search capability, though, without requiring editors to create innumerable redirects. isaacl (talk) 22:06, 5 March 2023 (UTC)
 * If this does happen, make sure you create a new redirect template (Template:R from ISO 3166-2 code) and use it, along with other relevant redirect templates. Gonnym (talk) 19:30, 4 March 2023 (UTC)
 * Note that User:PotatoBot (User:Anypodetos) created the ISO 639 redirects (Bots/Requests for approval/PotatoBot 2) so this isn't a completely new idea. Gonnym (talk) 19:33, 4 March 2023 (UTC)
 * I would be sure to make a redirect template and tracking category in the case that this gets approved, yes. — Red-tailed hawk  (nest) 19:35, 4 March 2023 (UTC)
 * Looks good to me. EpicPupper (talk) 05:38, 5 March 2023 (UTC)
 * A very good idea in theory but beware of name clashes. For example, ISO 3166-2:AL tells us that AL-01 is Berat, Albania, but  currently redirects to Alabama's 1st congressional district. Certes (talk) 18:06, 5 March 2023 (UTC)
 * As specified above, I wouldn't touch anything with a name clash during a mass creation. I agree that those are best handled manually. — Red-tailed hawk  (nest) 18:32, 5 March 2023 (UTC)
 * I think this is a good idea. It's a well-defined and limited set of redirects, all of which will be plausible search terms (pretty sure I've searched some myself). Where clashes exist, it may even be worth turning those clashes into disambiguation pages, although this will presumably be a manual process. Might be worth including some tracker for codes where the target page doesn't exist, or is itself a redirect, for manual follow up. CMD (talk) 01:14, 6 March 2023 (UTC)
 * I support this. User:Red-tailed hawk, if you can provide a complete list, I can provide you with a list of the ones that clash with existing redirects, and the ones that clash with existing articles (if any). I agree with CMD that disambiguation pages would likely be appropriate for all clashes with redirects. BilledMammal (talk) 01:41, 6 March 2023 (UTC)
 * I would be happy to. Do you know of any script that converts a Microsoft Excel document into a Wikitable? I'd be happy to post one here if I can get the formatting fixed. — Red-tailed hawk  (nest) 01:51, 6 March 2023 (UTC)
 * Try copying and pasting the cells into Visual Editor. Otherwise, see for a couple of Toolforge tools that will convert tab-separated text into wikitext tables, so you can try copying and pasting the cells into those tools. isaacl (talk) 02:14, 6 March 2023 (UTC)
 * I'm getting a terrible error when I try to copy-paste into VE. I'll take a look at those tools. Thank you for the pointers! — Red-tailed hawk  (nest) 02:16, 6 March 2023 (UTC)
 * Sorry, I don't. However, I would suggest saving the excel document as a CSV file, opening it in notepad, and copying and pasting the contents - probably to another page. It won't be formatted, but that isn't important. BilledMammal (talk) 02:30, 6 March 2023 (UTC)
 * Lgtm. Thanks, Hawk. Levivich (talk) 03:14, 6 March 2023 (UTC)

Making templates for votes
ok so i think that vote "options" (idk what's it called in enwiki) such as Support, Oppose, Comment should have a little icon that represents the options. so like Support ; 15px ;  Comment and  Meh. tynjee 02:58, 4 March 2023 (UTC)


 * Hey -tynjee. There is a long-established consensus against templates for marking votes, in particular because they encourage voting over discussion. See Voting templates. —&#8239; The Earwig (talk) 03:18, 4 March 2023 (UTC)
 * I will echo what The Earwig says in that there's been longstanding hesitation around making those templates. There already exists a comment template, and a meh template (though the current meh template is slightly different from what you're proposing). — Red-tailed hawk  (nest) 17:01, 4 March 2023 (UTC)


 * These are in widespread use on other language Wikipedias, so their absence on en.wiki often surprises multilingual editors!—<b style="font-family: Verdana; color: Maroon;">S Marshall</b> T/C 07:12, 5 March 2023 (UTC)
 * I wonder if they ever trigger template limits. CMD (talk) 16:01, 5 March 2023 (UTC)
 * Yes, and that shows the English Wikipedia different, which is a good thing. Trying to achieve technical compatibility would merely mask existing social incompatibilities and make things worse. (And I say this despite being active on 3 different multilingual wikis, and an admin on one). * Pppery * <sub style="color:#800000">it has begun...  17:28, 5 March 2023 (UTC)
 * I'm sure you're not proposing to use them on English Wikipedia. Just that something is done on many other Wikipedias doesn't make it right for us. Voting seems to be more common on other Wikipedias too. What I would love is for more editors to discuss things first before coming to a conclusion that can be summed up in one word (or icon), but I seem to be pissing into the wind there. Phil Bridger (talk) 17:42, 5 March 2023 (UTC)
 * Oppose. Wikipedians might find such icons difficult to use. YTKJ (talk) 18:30, 5 March 2023 (UTC)
 * I agree with your conclusion, but not with how you got there. What is so difficult about copying and pasting an icon? Phil Bridger (talk) 18:42, 5 March 2023 (UTC)
 * Oppose. There are userscripts that do this automatically (visually only, not actually in source) for those who want it. Just use those - no need to poke the bear. casualdejekyll  17:35, 6 March 2023 (UTC)