Wikipedia:Village pump (proposals)/Archive 183

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

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

---

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

RFC: Pending-changes protection of Today's featured article

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

A summary of the debate may be found at the bottom of the discussion.

---

If I merely do an accounting, auto-semi-protection would be the result. But that is not what a closer is to do. And the policy argument from WP:PROTECT carries a lot of weight. So with that in mind, and based upon the discussion below, while I think there is consensus below from the community that they would like to try auto-semi-protection on an article while it is TFA, there are also some policy-based valid concerns. So considering how this has been handled to this point, moving forward, this can be resolved with a 30-day trial of auto-semi-protection, just like the initial implementation of PC was (to start whenever implementation is ready).

(I realize this may be seen as "kicking the can down the road", but the WP:PROTECT policy rests heavily on a fundamental pillar of Wikipedia, and modifying the application of that, even locally, as noted in the discussion below, is not to be lightly done. And closers are required to take existing policies/guidelines/longstanding common practice, into account when closing.) - jc37 02:15, 30 August 2021 (UTC)

---

A one-month trial was authorised in April 2021 following Wikipedia:Village pump (proposals)/Archive 178#Pending-changes protection of Today's featured article. I understand that that trial has now ended (see User talk:Primefac#Follow-up RfC to TFA PC protection trial; courtesy pings, and thanks for the heads-up, to Goszei and Primefac). I am therefore opening this discussion to invite comments as to how it went, and what (if anything) to do next.

Consider me neutral. All I will say is, that I don't think I've seen a request for protection of a TFA at WP:ANI since February 2021.

Pinging all editors who took part in the original discussion: TheDragonFire300, Iridescent, Redrose64, Jéské Couriano, Izno, Thryduulf, Vaticidalprophet, Wugapodes, Buidhe, Nosebagbear, Mz7, Bilorv, Hawkeye7, Aza24, HAL333, RandomCanadian, Elli, Extraordinary Writ, firefly, Pinchme123, Yair rand, Espresso Addict, Levivich, Zoozaz1, Venicescapes, ToBeFree, Waddie96, ONUnicorn, Kusma, Dennis Brown, CaptainEek, Jason Quinn, Nsk92, Snow Rise, MusikAnimal, King of Hearts, Wretchskull, ProcrastinatingReader, Phil Bridger, Asartea and 力 (and Somebody "Notme" Else, who unaccountably did not). Narky Blert (talk) 12:06, 26 June 2021 (UTC)

Survey (TFA PC)

• From a quick look through the protected pages, what I see is:
  1. A significant uptick of activity on the day of the TFA
  2. Much of the activity on pages which were not already semi-protected was vandalism or other forms of unconstructive editing (there were a few here and there which were good edits, but they're the exception not the rule)
  3. Most edits by non-ACs on those pages were coming from VOAs or the like who would probably have vandalised something else anyway
  4. Problematic edits were quickly reverted
  5. No sign of any LTA which prompted this
• I was also thorough, and checked the first few TFAs after the trial expired. The nature of edits to these articles is broadly similar with that of the PC-protected TFAs (supporting point no. 3), and point no. 4 also holds. In short, the trial was successful as far as point no. 5 is concerned (though it is hard to judge how effective the measure was in respect to this), but I don't think it was otherwise effective in preventing vandalism to the TFA - whether we want a few vandals wasting their time at the TFA and getting caught and blocked rather quickly, or whether we want them messing around elsewhere (where their vandalism is less visible, and where enforcement can also take more time if nobody is checking AIV) is another question. Since PC had no appreciable impact on points 2 through 4, I would personally support semi-protecting the TFAs for the foreseeable future (this could be combined with the existing TFA Protector Bot run by Legoktm). RandomCanadian (talk / contribs) 13:29, 26 June 2021 (UTC)

  Note that I don't have fundamental issues with the protection just being PC, so support PC too, but I think semi will be more effective. RandomCanadian (talk / contribs) 23:38, 26 June 2021 (UTC)

• I fully support permanent PC-protection of TFAs; I have repeatedly seen vandalised TFA ledes upon clicking on them throughout my time here. I've also seen that most non-autoconfirmed edits are either vandalism or unconstructive edits. A phenomenon I see in TFA reverts is that they are more prone to collateral damage; sometimes more than one edit has been made by a vandal, and I've seen people (even ClueBot) accidentally only undo one of the edits, forcing a revision restoration. I do not quite understand when some people say that anyone should be able to edit Wikipedia and no protection shall be installed in TFAs, if that is the case, why not just remove all protection from all pages? Shouldn't they be able to edit their favourite articles? Why should TFAs be a scapegoat for vandals? They have been upgraded to a point where they may only need very few, almost unnoticeable corrections. Sidenote: RandomCanadian I support PC-protection over semi-protection as there may be some who spot mistakes that could be quickly corrected. Also, the fact that it is PC-protected would perhaps draw them away from unprotected sites over the illusion that they may be able to vandalise. Wretchskull (talk) 14:36, 26 June 2021 (UTC)
  • FAs can still have fundamental mistakes in them, particularly for more technical subjects. The process is very thorough for some particular kitsch Wikipedia things, but remember that most reviewers at FA are not subject experts. — Bilorv (talk) 17:34, 26 June 2021 (UTC)
• Support automatic PC protection. As I stated in the discussion that authorized the trial, the utility of pending changes is different from semi-protection in the sense that the goal is not to reduce the workload on administrators and editors (it effectively creates more work), but rather to ensure that vandalism is not seen by readers and thus potentially bringing the project into disrepute. In general, TFAs often receive a considerable uptick in viewership while they are on the Main Page. For example, yesterday's TFA about an obscure plant, Grevillea juniperina, saw 18,112 views, which is approximately 12 views per minute. Thus, for every sixty seconds that vandalism is allowed to remain on a TFA, that's potentially at least 12 readers who are seeing that revision on what is supposed to be a showcase of our very best content on Wikipedia, and a scroll through revision histories reveals that vandalism is indeed not getting reverted immediately on a consistent basis. On Shojo Beat, which is today's featured article, [1] was not reverted for 7 minutes (warning: it contains a link to porn). The trial successfully showed that turning pending changes protection on did not pose any unbearable burden to the PC backlog (it's only on for 24 hours anyway), and this small cost is worth the benefit of maintaining the polished quality of our featured content while still allowing prospective/inexperienced editors to suggest changes. Mz7 (talk) 16:22, 26 June 2021 (UTC)

  For the record, I oppose semi-protection. I think PC is sufficient. Several editors below have expressed vague or hypothetical problems with pending changes protection on TFA, but no one has pointed to concrete evidence of such issues during the trial period. It's true that pending changes protection is usually a bad fit for high-edit rate articles because doing so extensively would bloat the pending changes backlog—but when it's just on one article per day, the situation is entirely manageable. As I stated above, TFAs are often viewed at least once every five seconds, and the record demonstrates that vandalism on TFAs are often up for much more than that, even up to several minutes—the utility of pending changes is that we can avoid the embarrassment of presenting vandalism as our "finest work". The one point of opposition I can understand has to do with the technical issues impacting the pending changes tool—at the original RfC that authorized the trial, I also expressed skepticism about this whole idea on that basis, but as it stands right now, it seems that the tool is working well enough at the moment that we can cautiously proceed. Mz7 (talk) 17:13, 27 June 2021 (UTC)

  Nobody knows what will break next, and when. There has been half a dozen random critical bugs in the past year (less?), half of them were fixed 'by luck' IIRC, ie the devs couldn't/didn't figure out what was wrong but sometimes things just seemed to start working again. Nobody wants to touch the codebase, and few even know the codebase well. If it screws up, we could be largely on our own. I personally don't think we should encourage the proliferation of buggy technology; we need to be looking to undeploy pending changes and/or limit its use, not the opposite. ProcrastinatingReader (talk) 22:46, 27 June 2021 (UTC)

• Support per last discussion. ~ HAL333 16:28, 26 June 2021 (UTC)
• Oppose automatic PC protection; support automatic semiprotection while on the mainpage as an alternative. The edit rate on TFA is much too high for the pending changes system to be useful. Ivanvector (^Talk/_Edits) 16:43, 26 June 2021 (UTC)
• Strong support per RandomCanadian's very thorough assessment. I'm particularly interested in this point that lots of TFA vandals are likely just looking for a page to mess up and would do it on something else instead if TFA was semi'd. Unfortunately, whether this is true or not is very difficult to assess properly, but it's plausible to me. I like PCP because keeping the TFA editable is particularly valuable in helping people discover that we are the encyclopedia that anyone can edit. Sure, most edits are going to make it worse, but that's not really the point. A lot of valuable editors' first edits made articles worse. We need to see test edits and unhelpful good faith edits (and even some vandal edits) as a cost worth investing in to stop cutting the already dwindling flow of new contributors. I would oppose semi-protection. On a TFA page, at least some editors (and generally at least one with comprehensive subject knowledge) are going to be watching. — Bilorv (talk) 17:34, 26 June 2021 (UTC)

  I don't know whether TFAs actually recruit new editors. They've been through a thorough and picky review process. While they can certainly still be improved, a newbie (or even active editor) is more unlikely to be able to improve them compared to other articles. All in all, I'm not sure how many editors actually began their editing career by editing a TFA. ProcrastinatingReader (talk) 20:10, 26 June 2021 (UTC)

• Support temporary full protection (2-7 days max) via my comment in the last discussion "My first concern is with the reader, THEN the editor." PC is still a bad idea. I would also note that I think you are mistaken when you say "who would probably have vandalised something else anyway". Vandalism like this is akin to opportunistic theft, which is reduced when the targets are less visible, ie: less opportunity. There is a distinct attraction to vandalizing something on the front page that is different from run of the mill vandalism, so saying they would have done the same thing elsewhere, in absolute terms, is not accurate. For the editors that DO go vandalize something anyway, the damage is repaired just as quick with less visibility, in most cases. Dennis Brown - 2¢ 17:40, 26 June 2021 (UTC)
• Strong support - if it's featured, it has already been through the rigors and highly unlikely that it needs CE or anything else that can't wait 2 weeks. Atsme 💬 📧 17:50, 26 June 2021 (UTC)

  Quite a few TFAs have been promoted years ago, so {{cn}} on the "highly unlikely it needs CE". —Kusma (talk) 18:15, 26 June 2021 (UTC)

  I think there are certainly lower-hanging fruit, like the non-GA DYKs on the Main Page. I know that when I'm looking for something to do, I work through the DYKs and don't really bother with the TFA. Sdrqaz (talk) 20:35, 26 June 2021 (UTC)

• I passionately hate pending changes, but there are enough other places to freely edit. I'd like to see a second trial with semi instead of PC, but I support the general idea of doing something to protect TFA but keep editing open a bit. —Kusma (talk) 18:15, 26 June 2021 (UTC)
• Strong support. A long time coming. TFA is a prime example of where pending changes protection shines. The high edit rate is not an issue because the article has such high visibility. Still, I can't count how many times I've checked Today's Featured Article and it was in some broken or vandalized state. I know this won't change for me as a registered user, but I'll feel a lot better knowing the nonsense is hidden from the vast majority of readers. Meanwhile the good faith editors can still contribute, and our most visible article still follows the "anyone can edit" philosophy. It's a win-win. — MusikAnimal ^talk 18:21, 26 June 2021 (UTC)
• Support Agree that our first concern should be the readers. My experience with TFAs over the period has confirmed the value of pending changes protection. Pending changes doesn't stop suggested good edits, but it has prevented vandalism. Hawkeye7 (discuss) 18:59, 26 June 2021 (UTC)

  I actually think it is healthy for our readers to see some vandalism every now and then, it serves as a good reminder not to trust everything you read on Wikipedia. —Kusma (talk) 19:02, 26 June 2021 (UTC)

  LOL! Narky Blert (talk) 20:57, 26 June 2021 (UTC)

• Support per previous discussion, and strengthened by RandomCanadian's argument. waddie96 ★ (talk) 19:08, 26 June 2021 (UTC)
• Support per MusikAnimal. While I'm suspicious of pre-emptive protection, this is a viable compromise to solve a legitimate problem for our readers, so I'm fine supporting. To be honest, I didn't even know this trial was going on so it clearly did not wind up being a problem. For that reason I don't put much stock in the idea that there is something inherent to PC protection that will cause major problems. — Wug·a·po·des​ 19:09, 26 June 2021 (UTC)

I still oppose preemptive semi-protection per per the protection policy. That policy is quite clear: Applying page protection as a preemptive measure is contrary to the open nature of Wikipedia and is generally not allowed if applied for these reasons. I maintain my strong opposition to preemptive protection especially where no human judgment is involved like in automatic protection. I am willing to compromise on that and preemptively apply pending changes protection based on the trial results and protection policy: the protection level should be set to the lowest restriction needed in order to stop the disruption while still allowing productive editors to make changes. When compared with pending changes protection, preemptive semiprotection is not only against our fundamental values but more extreme than necessary to stop anticipated disruption. If we are going to carve out an exception to NOPREEMPT, that policy says we should choose the lowest protection level that is effective, and the trial shows that level is pending changes. For that reason I oppose preemptive semi protection as well as a trial of semiprotection which would show us nothing other than that semiprotection stops new and IP edits. Those preferring semi protection have offered no policy or evidenced based reason to prefer it over pending changes. Arguments so far offered for preemptive semiprotection are based on anecdotes, fear, and assumptions of bad faith, all of which are unconvincing given our policies. — Wug·a·po·des​ 23:56, 29 June 2021 (UTC)

Respectfully, I'm not sure any of us would have noticed the most likely PC problems unless we were actively working as reviewers in a robust fashion over the test period, which is part of why I wish I hadn't been so absent from the project over recent months and might have a better grasp on what the impacts were. Then again, maybe you were intending to say you -had- been working that area and didn't notice substantial impacts. But further (and again with respect) I would submit that such an argument is not a super compelling one (as either an empirical or rational measure) for the overall cost-benefit value of this change, because said observation cuts both ways: if you didn't even realize the trial was running, then you failed to notice any benefits in equal measure to failing to note any issues. Which makes the observation rather a wash at best--afterall, absence of evidence is not evidence of absence, for either any benefits or drawbacks that we may speculate about. This is why I am a little concerned that this discussion is building steam towards a result just as fast as the first one: I'd really like to hear more from those who were in the trenches in the involved areas, or otherwise did notice effects, however subtle, in one respect or another, before we rubberstamp this change as one that is fit for purpose/returns more value than negative side-effect on the whole. Snow ^{let's rap} 01:16, 27 June 2021 (UTC)

• Support Seems to strike a reasonable balance. XOR'easter (talk) 19:31, 26 June 2021 (UTC)
  • I'd generally go with semiprotection rather than pending-changes. The latter has always struck me as a "huh? when is this beneficial?" kind of feature. The operation of it is more complicated and harder to explain, too. I'd prefer the course of action that doesn't clog page histories and doesn't lead to oversight headaches. XOR'easter (talk) 02:18, 27 June 2021 (UTC)
  • It seems implausible to me that TFA actually serves to bring in new editors. If a reader cares about a subject and has enough enthusiasm for it that they want to write about it, they've probably already found the Wikipedia article on it. TFA shows off the community's work to people who don't already specialize on the article's topic. XOR'easter (talk) 20:28, 27 June 2021 (UTC)
• I would prefer to see a deeper analysis of the 30 days of trial data we collected. Were there any constructive edits from non-confirmed users? If so, what proportion? I'm not a big fan of pending changes. Technically, the functionality is barely functioning (we literally had to approve a bot to keep it working as a hotfix, because the devs couldn't find the bug) and in terms of development it is practically abandoned. Further, all it does is stop the vandalism appearing live. It doesn't stop the page history being clogged up with crap. If all or most the edits are unconstructive, then just go semiprotection (the only reason not to do so would be ideological, and I prefer pragmatism). ProcrastinatingReader (talk) 20:04, 26 June 2021 (UTC)

  Support semiprotection and oppose pending changes. The former because the evidence suggests almost all such edits are unconstructive, leading to vandalism on an article on the Main Page, but more importantly deriving users of factually accurate information for some period of time. Oppose pending changes because a) the functionality is broken (see Wikipedia:Bots/Requests for approval/FireflyBot II) and long-term unmaintained by the WMF (see phab:T185664); b) for the reasons above (and some others). Per the WP:Protection policy (WP:PCPP): Pending changes protection should not be used on articles with a very high edit rate, even if they meet the aforementioned criteria. Instead semi-protection should be considered. (which TFA is) -- there's a good reason for that, the PC user interface is inferior to edit requests, and quickly becomes a mess at high edit rate. ProcrastinatingReader (talk) 22:34, 27 June 2021 (UTC)

  Striking support for semi; now neutral on it, as per latest convincing comments, many of them from IPs, below. Still opposed to PC, as it is unsuitable. ProcrastinatingReader (talk) 23:52, 24 July 2021 (UTC)

• Support either PC or semiprotect for the duration of main page appearance. As noted above, the majority of edits blocked were not constructive and we should avoid allowing high visibility pages to be vandalized because it undermines the reputation of the encyclopedia. (t · c) buidhe 20:27, 26 June 2021 (UTC)
• Strong Opposition to using pending changes protection in this role, but a somewhat lukewarm level of support for using semi-protection instead. Much as with the original RfC on this topic, I think I am arriving at a point where it is already clear which way the wind is blowing, but I'm still going to take a moment to register my disagreement with the emerging consensus (which I don't always do in such circumstances), just because I can't shake the impression that this would be a substantially ill-advised move on multiple levels. I'm a pending changes reviewer myself and having logged a fair number of hours on the process over recent years, and I think I can say with some confidence that most editors who have not had to work with the approval side of the tool do not fully comprehend how complicated the application of that oversight becomes, particularly when you have multiple pending edits coming right on top of eachother, interspersed with auto-confirmed user/non-pending edits. Which is precisely the situation we would (more or less as a per se/absolute matter) be setting ourselves up for here. This extra demand (of complicated use of the permissions/manual editing to resolve conflicting edits) would create a substantial amount of unnecessary busy work for the reviewers, in what is already an area where the work often swamps the relatively small number of volunteers working consistently on the backlog--and this before we even contemplate the not-entirely-infrequent PC technical bugs--and all for a dubious benefit, since featured articles already are protected by vandalism pretty effectively by the fact that they are routinely patrolled during their day in the sun by the corps of regular editors, with most of the vandalism and otherwise problematic edits swiftly reverted.

There's also the question of hampering access in an area that traditionally has been a vehicle for first-time edits of new users, at a time when we are in the middle of a long and substantial downward trend in both editor recruitment and retention. Indeed, as I also noted in the previous discussion, having a situation where first-time users are funneled into a context where the community has abundant eyes on their initial edits, thus improving the odds that said new users will get essential feedback, engagement, and tutelage on our basic policies and procedures (and that their first, almost inevitable mistakes are caught and transformed from longterm errors into quickly fixed mistakes and teachable moments) strikes me as the best of all possible worlds, given the alternatives.

So the cost-benefit analysis on this proposal is way, way off, as I see it. That said, switching the approach from pending changes to semi-protection as the default at least eliminates the cumbersomeness of the concept a little and avoids the deleterious effects on the PC backlog and the volunteers who chip away at it on a daily basis. But my first choice would be to avoid both and rely on the traditional, largely self-correcting approach. And at a bare minimum I also agree with ProcrastinatingReader in their very pertinent caution above: I'd at least want to see a more fulsome exploration of whatever insight (impressionistic though it may be) that the trial has provided us, before I could be convinced to move to support a change from the status quo here. I really don't mean or want to tweak anyone's nose in particular here, but my impression of both the discussions is that there has been rather a rush to action here and rather too little consideration of the possible numerous and substantial knock-on effects. I can probably be convinced that this proposal isn't entirely a solution in search of a problem, but I really think we need a subtler parsing of the issues here. Not that the majority needs to convince me here--consensus seems to be moving solidly away from my perspective on this--but anyway, those are my impressions. Snow ^{let's rap} 00:42, 27 June 2021 (UTC)

• Support semi-protection - From my experience, PC doesn't work well in high edit-rate situations, which TFA generally is. And from the perspective of a FA writer who's had two of the article's I've worked on as TFAs, some of the bad edits can hang around for a bit. This lasted 4 minutes, this edit which removed an infobox through vandalism was up for 12, this for 11, etc. etc. The no-protection system is just resulting in the pages being messed up when they're most visible for sometimes decent chunks of time. PC would be nice if viable, but I'm afraid that it would frequently break down under the high edit rates TFAs often get. Hog Farm _Talk 01:03, 27 June 2021 (UTC)
• Support semi-protection, it just needs to be done folks. Semi-protection does wonders, we all know this. Every single TFA I've ever watched is just brutally vandalized, every single one. And more than half the time the article ends up getting semi anyways, so why has it just become this awkward race on how long the article can hold out when they almost never do? The vast majority of IP/non-registered edits to TFAs are vandalism—with semi, worst comes to worst, and they have to suggest edits on the talk page, not a big deal. I'll support pending if that's all this gets to, but we all know it's broken and messy, time to move on. Aza24 (talk) 01:28, 27 June 2021 (UTC)
• I strongly support semiprotection and am neutral on pending changes. I find monitoring pending changes to be a colossal labour-intensive timesink about 90% of the time. Cas Liber (talk · contribs) 04:19, 27 June 2021 (UTC)
• Support per all the above. No-brainer. Lugnuts ^{Fire Walk with Me} 07:37, 27 June 2021 (UTC)
• Support semi-protection, PC as a second choice, all per above. MER-C 08:43, 27 June 2021 (UTC)
• Support semi-protection, oppose pending changes. I strongly opposed the use of PC in the initial RfC because of technical issues with the flaggedrevs extension. I am still uneasy about using flaggedrevs on a high-profile page given that it still doesn't appear to have a dev team 'owning' it. I note that my "patch the holes" bot (User:FireflyBot II) hasn't had to do much work at all lately, which is a good thing - however I don't believe we've yet gotten to the bottom of exactly what caused the issue (autoconfirmed editors' edits not being automatically accepted when they should be) in the first place. I don't think we should be using potentially buggy code on our most high-profile articles. I agree with ProcrastinatingReader that we must be pragmatic here, not ideological. firefly ( t · c ) 09:04, 27 June 2021 (UTC)
• Support PC, semi second choice To me PC is the best option, but semi is preferable over nothing. Oppose all forms of protection on TFA, on second thought, as we want people to be able to edit articles featured on the main page and the vandalism is managable.Jackattack1597 (talk) 10:45, 27 June 2021 (UTC)Jackattack1597 (talk) 10:39, 14 July 2021 (UTC)
• Strongly oppose pending changes. Per several commenters above me there is no evidence that it is a net positive in highly visible places such as TFA, and indeed some evidence that it is a net negative. Oppose automatic protection of any sort for any reason. We want to encourage people to edit Wikipedia so we should be erecting as few barriers to participation as we can and that means protecting only where there is a demonstrated need for it. Thryduulf (talk) 11:29, 27 June 2021 (UTC)
• Comment I see a lot of people asserting that PC protection causes "problems" on high-traffic articles. Did anyone notice these problems in May, when the trial was running? Can specific examples be provided? Anomie⚔ 11:55, 27 June 2021 (UTC)
• Support semi-protection while it is featured, oppose putting pending changes on it. Pending changes is a complicated mess and on an a highly active article it would be doubly a complicated mess. There are always several guardians for the TFA article and that combined with semi-protection should be enough. North8000 (talk) 13:59, 27 June 2021 (UTC)

I'd like to emphasize that this is a very narrow case. It's only one or 1 1/2 days of semi-protection for one or 2 articles at a time. North8000 (talk) 13:35, 28 June 2021 (UTC)

• Support semi-protection. IP/non-autocomfirmed editors can use edit requests, and even though I admire the ideal of pending changes protection for TFA (à la anyone can edit), I'm hesistant because of the technical issues raised by Firefly and the practical issues mentioned by Hog Farm. Clovermoss (talk) 18:53, 27 June 2021 (UTC)
• Question: Has anyone done a study on the effects of protecting the TFA on valdalism on other pages linked from the main page? If the vandalism simply transfers to there when the TFA i semi'ed, that woukd be a good reason to prefer PC. 93.172.254.2 (talk) 08:31, 28 June 2021 (UTC)

  I haven't seen any studies, so I can only offer the usual anecdotal evidence: Speaking as a reasonably frequent DYK contributor, vandalism on my DYK articles has been negligible over the last two years. —Kusma (talk) 08:39, 28 June 2021 (UTC)

  However, on Saskatchewan, the article was only vandalized since being put on the main page under Template:In the news, and in fact was semi-protected. Sungodtemple (talk) 13:21, 28 June 2021 (UTC)

• I support a second one-month trial for semi-protection (first choice), semi-protection (not a trial, second choice), and pending changes (third choice). I support all three for the purposes of coming to a consensus on at least one of them. KevinL (aka L235 · t · c) 16:32, 28 June 2021 (UTC)
• Support semiprotection as a first choice with PC as a second. PC isn't great for high traffic articles and consumes a nontrivial amount of editor time reviewing changes. I also doubt that most non-autoconfirmed users can make that many good edits to an FA. Hut 8.5 17:25, 28 June 2021 (UTC)
• Support some kind of protection, no specific preference as to which kind. The ratio of vandalism and poor edits to genuine improvements is far too low in my opinion, and personally I think that for a newcomer being able to edit an article only to have your work instantly reverted is much more likely to drive people away than simply stopping them from editing. Looking at today's features article, of the 10 IP edits that have occurred so far 9 were instantly reverted and the last one is pointless (they turned an alternate name in the lead into a wikilink, so there are two links to the same article in the same sentence). 192.76.8.91 (talk) 17:59, 29 June 2021 (UTC)
• Oppose, either PC or semi-protection. The TFA's editability's usefulness as a recruitment tool outweighs the reputation problems it causes. --Yair rand (talk) 22:15, 29 June 2021 (UTC)
• Oppose pending changes is a technical feature of MediaWiki that is broken, has no one supporting it at the Foundation, and is harder for volunteers to patrol than just dealing with the vandalism in live articles. We should remove it as a technical feature on this wiki, not make it automatic. TonyBallioni (talk) 02:50, 30 June 2021 (UTC)
• Oppose any automatic protection (other than potentially move). I'd be curious if someone better versed in statistics could use the pageviews for TFA on a day and number of accounts made on that day to gauge how more popular TFAs tend to lead to more accounts created. This is logical, but I can't say for certain it's true because I don't have the data. What we do have data for, however, is the number of new accounts whose first (or one of their very first) edits is to a TFA. "Today's" featured article (only been up for about 3 hours total now, today's in quotes because it's UTC today, not necessarily your local today) already has one potentially new editor - who made what appears to be a test edit, then apologized for doing so, and immediately made edits to the featured article. Sure, they weren't necessarily good edits - but it's someone who now has an account and likely wouldn't have if not for the TFA they were interested in. The prior TFA has an IP editing from the app making good faith, reasonable changes who may have made an account (no way to know), as well as one other brand new account making one of their first edits to it. It only takes looking at varying topics to see that on average, TFAs result in at least 1-2 brand new editors whose first edits include to the TFA. That doesn't prove that new editors are joining because they can edit TFA, but imagine someone going to Wikipedia to look up "X", seeing the TFA "Y" they're interested on the main page, clicking it, noticing a change they want to make, and then making it. That reinforces the encyclopedia "anyone can edit" mentality, and is likely the biggest drive to them creating an account - seeing that "hey, yeah, I actually can edit this!" Automatically doing things is great - but indiscriminately doing it is not. I could potentially support a targeted automatic protection (ex: maybe base it on topics under DS or similar) where only articles with a very high likelihood of being vandalized while TFA are protected - leaving TFAs that aren't usually getting vandalized alone. And I don't buy arguments about it being "more work" - when I was looking through TFAs to prepare my comment, I noticed that over almost all (read: somewhere above 80% at least) of true vandalism was reverted by either ClueBot or someone using an automated tool within minutes, and usually barely a minute. Not to mention that sometimes changes were an improvement (or at least not vandalism), and they were still reverted by people - not sure what's going on with that. So no, the problem with TFAs isn't vandalism - it's that we are not capitalizing on the obvious fact that a non-zero number of new editors start out because they can edit a TFA - and we need to work on improving it so that people editing TFAs are retained. I digress slightly, but the solution is more effective communication when an edit to a TFA by a new user is reverted - perhaps a new, soft template message would be useful, or just writing custom ones instead of standard templates. The "solution" is not a solution at all - it creates a new problem of losing editors before they even start, because to them we are no longer "the encyclopedia anyone can edit". We would become "the encyclopedia some people can edit" - because they won't know how protection works, and they aren't going to read up on it - they'll just see "I can't edit this". -bɜ:ʳkənhɪmez (User/say hi!) 03:09, 30 June 2021 (UTC)
  • Ah, but see, the problem is you're actually looking at the article histories instead of assuming IPs are bad and making gut judgments based on that. Even beyond TFAs, a section of my user page currently lists articles semi-protected for over a decade that I've unprotected and the outcomes of doing so. In nearly all cases, disruption was minimal to non-existant. Take Flower for example which gets about 2k views per day. In the 27 days since the last protection expired there have been 9 edits by new or unregistered users. Of those, two were immediate self-reverts by IPs making test edits. Of the 5 remaining edits, three were reverted within one minute. The last two are actually interesting. An IP adds unconstructive text to the beginning of the article, then a new account comes and builds on it before both edits getting reverted a few minutes later. Both revisions were reverted 15 minutes after the IPs edit. So of the roughly 38,800 minutes since that article was unprotected, unconstructive text was visible to readers for at most 18 minutes or about 0.05% of the time. For simplicity, let's assume those 2k daily readers are spread roughly evenly across those 38k minutes. That means we can estimate that of the 54,000 readers this past month, vandalism was seen by roughly 25 readers. Meanwhile, we had four people try their hand at editing!
    Another example, probably more similar to TFA, is Pablo Picasso which I unprotected 22 May. In that time it's averaged about 6.7k views per day with two days spiking over 10k daily views. In those 39 days, there have been 10 edits by new or unregistered users. Of those ten edits, 8 were reverted. One was good faith but unsourced. Another was a change of date format. A third was a (sourced!) addition of content that was reverted because the IP didn't know how to use ref tags (seriously, that was the revert edit summary). That leaves us with 5 reverted edits that were not obviously in good faith. Of those 5, two were reverted immediately by ClueBot, and the remaining three were reverted within two minutes. Of the 56,000 minutes that the Pablo Picasso article was unprotected, vandalism was visible for at most six minutes or about 0.01% of the time. Making the same assumption as last time, that means of the 261,000 viewers, vandalism was seen by approximately 28 people.
    Of course, there's other examples and counter examples, but unprotections of visible pages support the basic assumption of Wikipedia: people are more constructive than destructive. Even an article with millions of annual page views has not only minimal disruption but multiple constructive and good faith edits by new and unregistered editors. Even where we have disruption visible, it is rarely visible for long and the impact is minor. Now let's turn to TFAs.
    All About That Bass (ft. 30 June) saw edits from 9 unique new or unregistered users before it was protected after 13 hours. Three of those 9 editors were constructive and unreverted. Of the 6 remaining, one was an account that got blocked after 15 minutes and 8 edits. Two of the remaining 5 were good faith but reverted for being unnecesarry changes. The last 3 were vandalism. Of those vandalism edits, two were reverted within two minutes, and the third was alt-text vandalism not visible to readers which stood for a little under 30 minutes before reverting. Despite being protected and including the vandal who got blocked, disruption was visible to readers for about 13 minutes of the 794 minutes it was unprotected. Hardly the epidemic people claim. Berlin to Kitchener name change (ft. 29 June) was never protected and saw edits from 6 distinct unregistered editors. Two of them wound up blocked. Of the remaining 4, one was reverted for writing a too detailed short description. Another (still unreverted) fixed some external links in citations. Another (still unreverted) added wiki links to the lead to Berlin and Ontario. The last added a weird symbol to the then-empty "image" parameter of the infobox. It stood for 16 minutes before someone noticed, all other vandalism was reverted within one minute. Phillip Davey (ft. 28 June) was protected after 7 hours and 6 distinct IPs but all of which were on the same sub net. Instead of protection, this could easily have been dealt with by a range block (and was, see 188.162.254.128/25). CM Punk (ft. 27 June) was already indefinitely protected. Shojo Beat (ft. 26 June) was never protected and saw 6 edits from new and unregistered editors. One was a good faith attempt to undo vandalism but resulted in an edit conflict that messed up the paragraph break. Another actually did undo vandalism. Another was to add a wiki link. The remaining three were vandalism. One seemed to attempt image vandalism (which I thought we had an edit filter for) but the revision is deleted and I'm having trouble loading it. Another was undone immediately by clue bot, and the last was undone by an IP after 5 minutes. Of the 1440 minutes that the article was featured, vandalism was visible for 12 minutes. Grevillea juniperina (ft. 25 June) was never protected and saw 9 distinct new or unregistered editors. Three of them were constructive and in really interesting ways. Two IPs worked together to improve the article after a vandal messed it up. Another editor had just registered that day and helped by adding links to the lead. Of the six unconstructive editors, One seems good faith but like they misunderstood hyphenation and alt text. Another seems like a test edit but might be good faith (I don't know much about plants). A third changed the file name from the latin to the English, maybe not realizing that it would break the image. The rest are pretty typical vandalism that was quickly reverted.
    I've already spent hours going through TFA page histories and many more before this looking at how readers interact with unprotected pages. The claim that semi-protection is inevitable is false. Many TFAs don't get protected, and in one case I would argue the page shouldn't have been protected (but it was a new admin who probably didn't understand range blocks so a proper response for the tools at their disposal). The idea that TFAs are uniquely subject to mass vandalism is hyperbole. While they get more than the usual vandalism, it is still minor and at a much lower rate than people are hyping it up to be. Over 5 TFAs I saw one revision deletion. The idea that TFAs need no work is false, multiple new and unregistered users have improved these TFAs and some of their edits still stand days later. The idea that pending changes would lead to a huge backlog of work is unsupported. Not only are most edits done by people who would go right through PC protection without review, those who would are very few and would be auto accepted by a revert without needing PC reviewers to intervene. When I say that those supporting automatic semi-protection are relying on intuition and not evidence, this is what I mean. If you actually took the time to look at the edits being made instead of checking to see if it's an IP address with the "reverted" tag, you'll see that these fears about vandalism are overblown. I've even shown you examples of helpful but imperfect IP edits being sumarily reverted by regulars because of formatting errors. Tons of new and unregistered editors are helpful and make valuable contributions to TFAs. Having looked through hundreds of revisions of both TFAs and regular articles I seriously need more evidence about the evil IPs than a bunch of gut feelings, and it's tiring to have actual facts and trial outcomes dismissed in favor of feelings. — Wug·a·po·des​ 01:03, 1 July 2021 (UTC)

    Many decisions are made on intuition and anecdotes rather than hard data analysis. I don't remember the last time I saw statistical evidence influencing an RfC. The best (and perhaps the only good) analysis I've seen on Wikipedia is User:Enterprisey/AIV analysis, but I'm still not sure how many peoples' minds that data changed. The ROI of taking the time to generate and analyse data on Wikipedia is low I feel, and data-based arguments will seldom be more convincing than anecdotes. I would personally not put in the effort to do this kind of analysis for this reason. ProcrastinatingReader (talk) 01:22, 1 July 2021 (UTC)

    On the contrary, I find User:Wugapodes' analysis very useful and has helped convince me we are in very little danger of going under if we don't protect TFAs. Whether the ROI is sufficient is up to Wugapodes in this case. — JohnFromPinckney (talk / edits) 07:10, 2 July 2021 (UTC)

    While I'm sure Wugapodes's analysis took time and is certainly better than anecdotes, when I was referring to "statistical evidence" I meant using a large sample size, such as User:Enterprisey/AIV analysis. Probably using some data science tool, since it'd be too tedious to do by hand. We have 30 days of trial data from the previous RfC that remains unanalysed (for the most part), and a lot of historical data (in the revision history) of what happens to articles while they're on TFA. If we want definitive answers to the questions we ask, the data exists and it's in public revision history. But only so many people can analyse it, and I just can't imagine it'd be worth their while, because it seems unpredictable how much of a difference it would make -- if the data suggests problems, will people abandon their 'pre-emptive protection/anyone can edit' philosophy? similarly, if the data suggests minimal issues, will editors forget about their anecdotes? ProcrastinatingReader (talk) 13:37, 2 July 2021 (UTC)

• Support semi first choice per everyone else above, PC distant second choice (because it still takes up too much editor time). Levivich 06:51, 30 June 2021 (UTC)
• Support semi PC is useless in general, it should almost never be applied. It is a waste of editor time. Semi'ing TFA is a sensical and reasonable action that should have happened years ago. It is hardly premature: we know that TFAs are routine targets of vandalism. We're so stuck in the idea that pages aren't pre-emptively protected that we forgot that our rules can be changed if doing so benefits the encyclopedia. TFA protection is a reasonable exception to our regular policy because it saves significant editor time and attention. CaptainEek ^{Edits Ho Cap'n!}⚓ 06:01, 1 July 2021 (UTC)
• Oppose pre-emptive protection in part based on Wugapodes' selective analysis above. I don't care for (it's impolite to say "I hate") PC anyway, and if it's as poorly maintained as I hear then I'm even more glad to avoid it. Applying semi-protection pre-emptively is a big hammer for a couple of small gnats, at most, and as mentioned multiple times above it goes against our anyone-can-edit ethos. Let's just let TFAs be as they are, and the few which get vandalized can (and will) get cleaned up, and when needed protected for the day. — JohnFromPinckney (talk / edits) 07:20, 2 July 2021 (UTC)
• Strong Support PC-protection but not automatic semi (and definitely not full) protection. TFAs the most visible part of WP and are therefore are often the very first article a new editor might try to edit. It would send a very bad message for someone's first attempt at editing to be met with a notice that they are not allowed to edit. That is contrary to the open editing philosophy of WP. However, PC is a great way to filter out all the vandalism that happens at TFA. Ergo Sum 14:05, 3 July 2021 (UTC)
• Oppose blanket protection on principle, this goes against the philosophy of Wikipedia, only apply protection to pages if they actually need it. Also oppose having an RfC after data collection but before data analysis, which is what seems to have happened here - that makes no sense. Thanks. Mike Peel (talk) 14:57, 3 July 2021 (UTC)
• Support semi s, oppose PC, because PC is confusing. But then, I think I've always opposed PC as confusing from the time it was first mentioned in enWP. I don't think semi does much harm when used this way. When its on the main page is not the time to encourage edits on it from beginners. There are many other easily visible articles that would be better choices DGG ( talk ) 17:20, 3 July 2021 (UTC)
• Support semi; neutral leaning very weak support PC; per Hut 8.5. Pre-emptive semi-protection is essentially never the answer, but this is one of the very few scenarios where there would be a demonstrable benefit to the project. Spencer^T•C 23:42, 3 July 2021 (UTC)
• Support semi, Oppose PC. Pending Changes protection sucks on any article with a high edit rate, as the reviewers only choice is to either accept or revert all edits made since the last review. On a page where someone makes one edit this is fine; in an article where you can easily end up with contributions by multiple different people, some of which are good, some of which need work and some of which are bad, its an enormous nuisance and a lot of work on the reviewers side. -- Asartea ^{Talk | Contribs} 15:51, 4 July 2021 (UTC)
• Support semi-protection, oppose PC for reasons others have already given in detail and clear wording that I don't need to repeat or try to reiterate in new wording.  — SMcCandlish ☏ ¢ 😼  03:44, 5 July 2021 (UTC)
• Support either/both, net positive. Stifle (talk) 10:15, 5 July 2021 (UTC)
• Oppose semi as a procedural matter If we want to overturn previous consensus on that matter, we should do it as a proposal specifically aimed at that to be sure of attracting all interested people. People who might oppose semi-protecting TFA may have ignored this discussion as PC doesn't prevent editing, it only stops anons from viewing them until they're approved. Neutral on PC, but I note a lot of the comments here seem to be ignoring the actual trial that was conducted in favor of prior belief, if not the proposal itself in favor of "PC should never be used anywhere". Anomie⚔ 13:13, 5 July 2021 (UTC)

  Just FYI, I've modified WP:CENT to include semi-protection as one possible outcome of this discussion. -- King of ♥ ♦ ♣ ♠ 04:20, 19 July 2021 (UTC)

  A bit too late, IMO. And someone already effectively undid your edit. I'm not going to change my !vote. Anomie⚔ 00:12, 20 July 2021 (UTC)

• Support semi, neutral PC Semi looks like a good fit here. PC might be more mild and "welcoming" to newer editors, but it's challenging for any article with a high edit rate. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs | please use {{ping}} on reply)} 03:32, 7 July 2021 (UTC)
• Oppose PC, mildly prefer status quo (no protection) vs. semi-protection as standard. I think that Pending Changes are in general a bad idea anywhere and an especially bad idea for the main page article for the reasons discussed. If IP vandalism is sufficiently a problem, we can abandon the general stance toward not semi-protecting TFA, although per previous discussions I'd think that's a bit of a last resort. But PC is even worse than semi-protection IMO. SnowFire (talk) 03:34, 7 July 2021 (UTC)
• Support Semi and Oppose Pending Changes. Pending Changes protection should not be used as a default option for anything. It is inherently confusing, and its use should be minimized. Robert McClenon (talk) 04:35, 5 July 2021 (UTC)

*:@Robert McClenon: you seem to be in the wrong section? -- Asartea ^{Talk | Contribs} 10:10, 7 July 2021 (UTC) Thank you for the comment, Asartea. Robert McClenon (talk) 11:50, 7 July 2021 (UTC)

• Support semi (but don't oppose PC if that's where consensus is) Everyone knows at this point that "everyone can edit Wikipedia", so that reason to not protect our prized article for the day no longer holds water.  – John M Wolfson (talk • contribs) 14:29, 7 July 2021 (UTC)
• Oppose any form of protection. This is a solution in search of a problem. Yes, the TFA gets vandalized, but it also gets fixed rapidly. We are the encyclopedia that anyone can edit, and that principle should be proudly on display when we choose an article for a prominent position. And, as has been mentioned before, seeing occasional vandalism (that is rapidly fixed) is a good reminder to readers that Wikipedia is not a reliable source. I'm also convinced by the detailed analysis done above that shows vandalism rarely sticks for long on the TFA. Ganesha811 (talk) 14:33, 7 July 2021 (UTC)
• Support semi-protection After having done a lot of recent changes patrol in the past I can say that this is not a moment too soon. As for PC, I'm more neutral. Shellwood (talk) 23:04, 8 July 2021 (UTC)
• Oppose protection per Ganesha811 and others. We need to attract new editors and page protection is detrimental to that. Yes, there will be some vandalism but that seems less important and the curent levels appear manageable. --Ykraps (talk) 05:07, 9 July 2021 (UTC)
• Oppose all protection. (i.e. retain the status quo, in which we semi-protect if things get out of hand, but otherwise deal with recent changes as we would with any other article). One of the biggest hurdles to recruiting new editors is that nobody actually believes the maxim that this is is really an encyclopedia that anyone can edit. I know that, because when I made my first-ever test edit back in 2006, I didn't really expect it to actually go live on to the project immediately. Seeing my (admittedly junk) addition up there in black and white is what lured me into the idea that I could contribute here. As the most visible editable page on the project, the TfA is the first port of call where someone might consider making such a test edit, and we should not put obstacles in their way such as saying "yes, you've edited Wikipedia but only you can see your edit" or, even worse, semi-protect the article so they walk away feeling that Wikipedia is only for experts. On a practical level I agree with Tonyballioni that PC, while a good idea in principle, does not work very well, and just ends up confusing things while making more work for editors in tidying it up.  — Amakuru (talk) 08:40, 9 July 2021 (UTC)
• Support PC and Semi If it has passed through the FA process usually it is up to scratch and a lot of the changes from IPs will often not be of much benefit. IP editors can also request edits on the talk page, but this is a good start to prevent vandals hitting a highly viewed article for a day.  Spy-cicle💥  ^Talk? 16:17, 9 July 2021 (UTC)
• Support semi-protection. If FAC and TFA work as they should, an article shouldn't require much twiddling with prose by the time it hits the main page. If there are larger issues that need to be sorted, they are better addressed on the talk page in any case; major revisions occurring on an article receiving thousands of views a day isn't great for the readers. Rates of editing are generally too high for PC-protection to be useful, IMHO. Vanamonde (Talk) 20:09, 9 July 2021 (UTC)
• Support semi-protection trial I don't usually comment in these affairs, but I feel I want to make one here. When I was observing TfAs while they were featured, I did not see any edits from non-autoconfirmed users that were not reverted. That being said, the opposers have a case. I think we should collect a bit more data before making a permanent decision. Link20XX (talk) 01:39, 10 July 2021 (UTC)
• Oppose PC. By its nature, PC isn't effective for high-traffic pages. El_C 13:31, 11 July 2021 (UTC)

• Suppoer Semiprotection; oppose Pending Changes per others. Would like to see more evidence this would be useful though and support analysis of past experiment, and setting up a new experiment that solely tests semiprotection, to see if there were any improved content. Shushugah (talk) 16:31, 11 July 2021 (UTC)
• Support semi-protection. FAs, by definition, don't need immediate edits or radical overhaul and the attracting new users argument doesn't require every single page to be editable automatically, needs to be balanced with the time and energy of regular contributors, especially where vandalism is more common, and doesn't have data backing it up anyway. Oppose pending changes as busywork. ─ ReconditeRodent « talk · contribs » 01:41, 12 July 2021 (UTC)
• Support preemptive PC protection as the best compromise between the interests of readers and editors. Semi as second choice over the status quo of no preemptive protection. It's simply embarrassing for vandalism to be shown on what is supposedly the crowning achievement of the day, even if it's only for a few seconds. Oppose semi trial as pointless; unlike PC, we know already what's going to happen and running a trial will not tell us anything that will help decide whether semi should be used or not. -- King of ♥ ♦ ♣ ♠ 04:15, 19 July 2021 (UTC)
• Oppose protection Vandalism happens, and if it isn't the TFA it'll be somewhere else that may not be picked up for a while. The TFA is well-watched and reversions to vandalism happen quickly. PC is a crap method that doesn't work very well, and particularly not on high-traffic pages. The lofty ideal of "the encyclopaedia that anyone can edit" has been battered and tattered for a while now, and this is another nail in its coffin. - The editor formally known as SchroCat (58 FAs, many of which have been on the MP), editing from 2A00:23C7:2B86:9800:39CA:4E99:E03B:7228 (talk) 08:34, 20 July 2021 (UTC)
• Neutral on pending changes, oppose semi-protection – Per Bilorv, who wrote:

  ... keeping the TFA editable is particularly valuable in helping people discover that we are the encyclopedia that anyone can edit. Sure, most edits are going to make it worse, but that's not really the point. A lot of valuable editors' first edits made articles worse. We need to see test edits and unhelpful good faith edits (and even some vandal edits) as a cost worth investing in to stop cutting the already dwindling flow of new contributors.
  — User:Bilorv 17:34, 26 June 2021 (UTC)

  The past 20 years has shown that the vandalism level on TFAs is manageable. The effort expended in doing so doesn't outweigh the benefits of showing new users that this is "the free encyclopedia that anyone can edit". 207.161.86.162 (talk) 00:15, 23 July 2021 (UTC)

• Very Strongly Support Making Semi-Protection Official – As a seasoned anti-vandalism user, let me say that my many years of experience have demonstrated that articles that are breaking news or have very high daily viewership suffer from extensive vandalism, if they don't have some kind of page protection. TFA articles featured on the main page are no exception, in fact, some of the articles featured there prior to the implementation to the experimental Semi-Protection policy experienced some of the largest vandalism attacks I had ever seen within a 24-hour period. This included a handful of both known LTAs and drive-by vandals. An example of this is Hurricane Daniel (2006), back in mid-July 2018. Sure, Wikipedia is supposed to be the encyclopedia that anyone can edit (actually, anyone here in good faith, not those with disruptive intentions), but that does not mean that we can abdicate our responsibility to uphold the integrity and accuracy of the encyclopedia by leaving featured articles unprotected when mass vandalism is inevitable. Allowing vandalism isn't just disruptive, it also brings bad publicity and inspires further vandalism and copycats (which is often far more disruptive than the initial vandalism). This policy is a no-brainer. The experimental Semi-Protection has seriously cut down on disruption across the articles featured on the main page via TFA, without any meaningful negative side effects. As such, I believe that this policy should be made permanent. This policy should've been implemented years ago. It's time for us to finally do the right thing to safeguard the integrity of this site. LightandDark2000 🌀 (talk) 05:16, 23 July 2021 (UTC)
  • As someone who has had more articles appear as TFA than nearly everyone on this thread (with one or two exceptions), describing the position of those who disagree with you as a "no-brainer" grates. I actually find more disruption and grief from registered editors trying to "improve" things that don't need improving (or making it worse) than with IP vandals. Vandals get bored when reverted and go away - the registered users will argue at length over ridiculously stupid points. Vandalism is picked up quickly and reverted, and articles that are subject to persistent vandalism during the day can be protected. I'm looking at today's article (Arthur Blackburn) and seeing a very few pieces of vandalism (quickly reverted), but some excellent changes from non-registered users. Protect the article and those changes won't be made. Not all IPs know to use a talk page, and even less will be bothered to leave a note asking for a possessive apostrophe be added, for example. The "integrity" of this site is in being open to those who want to make good changes. If you think the material on WP articles has "integrity": you're wrong. It doesn't. FAs get out of date and have errors, and IPs are just as good at picking that up as registered editors - often better than many editors. - The editor formally known as SchroCat (who's had more articles on the MP than most people here), editing from 86.162.16.171 (talk) 10:09, 23 July 2021 (UTC)
• Oppose semi-protection; OK with Pending. Got to go with Wugapodes on this. His detailed, FACT-based research above is very convincing. Regards, GenQuest ^"scribble" 23:45, 24 July 2021 (UTC)
• Support Semi, PC as second choice, oppose no protection – TFAs are highly visible. This goes both ways -- new people see it and decide to have a bit of "fun", and their disruptive edits are seen by more people. Hurricane Emily (1993) is a glaring example of what happens when TFA's aren't protected. I think semi would be the best course of action, since it doesn't create a big backlog at PCR. codingcyclone ^advisories/_damages 06:13, 25 July 2021 (UTC)
• Support any level of protection for TFA, up to and including full protection, but with extended confirmed protection being the most preferred - The reality of the matter is that the purpose of Today's Featured Article is not to encourage new editors to jump in and start editing said article. It's to showcase what Wikipedia articles can be with enough work. If an article has reached the point where it reaches the main page as Today's Featured Article then there's likely to be little any newcomer can do to improve it, and instead it will just be an enticing target for vandals, POV pushers, and other disruptive editors. Other parts of the main page, like In The News and Did You Know already serve to entice new editors. If an editor has a genuine concern about the contents of a given day's featured article then they can make a request for it to be changed on the talk page. All leaving TFA unprotected does is entice vandalism and discourage experienced editors from bringing articles to Featured Article Candidacy because they don't want to deal with vandals messing up the page they've worked on when it's most prominently on display. HumanBodyPiloter5 (talk) 19:40, 26 July 2021 (UTC)
  • As an editor that has had multiple articles as TFA, the claim that “All leaving TFA unprotected does is entice vandalism and discourage experienced editors from bringing articles to Featured Article Candidacy because they don't want to deal with vandals messing up the page” is utter horseshit. HumanBodyPiloter5, your words may have carried more weight if you had ever written an FA, or been to TFA, or even reviewed an FAC, but please don’t try to speak for FA writers if you’ve never walked in their shoes. I’ve had more articles at TFA (and another coming up next week) than I care to remember, and vandals are not the real problem. Registered editors who think they know better than a host of regular experienced FA reviewers are a much bigger and more damaging problem than passing IP vandals who are very quickly reverted and/or blocked. - The editor formally known as SchroCat (who's had more articles on the MP than most people here), editing from 2A00:23C7:2B86:9800:E5FF:FC15:F2DE:FA0B (talk) 21:57, 26 July 2021 (UTC)
• Oppose protection in any form per Amakuru and others. The recruitment opportunities far outweigh the problems and TFA is one of the most watched articles on this project, with any vandalism quickly reverted. I only had one article ever featured as TFA (Adele Spitzeder on 9 February 2020) but on that day, it only had a couple of edits and only four were vandalism that was quickly reverted (see history). TFA is a showcase for great work, not a special part of Wikipedia. An article should not be treated differently just because it appears there and the protection policy should apply to it like it does any other article. Protect it iff there is too much vandalism to handle but not preemptively because most articles (like mine) won't even attract that many vandals even without protection. Regards SoWhy 09:47, 28 July 2021 (UTC)
• Stronge Oppose Any kind of preemptive protection for TFA. Per ever other time we've had this discussion (I mean really, this again?) and the well articulated analysis of amakuru et al above. I just had a glance at some of the recent TFAs, and casual editors are the only ones catching embarassing typos (see Talk:Dementia_with_Lewy_bodies#TFA) and embarassing errors (see Talk:Call_of_Duty:_Modern_Warfare_Remastered#Killstreaks_==_scorestreaks?), and that's just scratching the surface. Sure there's vandalism, but reverts are easy, checking for quality is not. Even without the rollback button, I can revert a dozen instances of vandalism in the time it would take me to examine a single ref (maybe more). Sometimes it seems casual editors are the only ones catching this sort of thing. If a gross LTA starts attacking a page, fine then protect it then, but otherwise this is a pretty good way of getting people involved, and maybe even overcoming CommunityWiki:FearOfEditing. If there are ten bits of vandalism for ever good edit, so what? It's easy to revert the bad edits and keep the good ones, at the end of the day, the article has still improved. Reputation damage is a red herring, far more damage is done to our reputation by the appearence of some really subpar not recently reviewed FAs (some of which should never have been promoted in the first place) or ones that while generally decent have dumb errors which slipped through the process (seems that things are still all FACed up). The existance of Wikipedia vandalism on the other hand is already well ingrained into the public consciousness through pop cultural osmosis, and keeping it off TFA is not going to change that (and given many recent TFA vandals have been autoconfirmed e.g. (1, 2, 3, 4, 5), this proposal wouldn't even accomplish what it purposts to (I find it especially amusing that occaisonally the first one to revert an autoconfirmed VOA is a new or unregistered user), but would stand as a wonderful monument to the inability of some people to meatball:AvoidIllusion. Admins seem fairly quick to pull the trigger on protection anyway (maybe too quick Apollo 15 was protected after being hit by only three unconstructive edits by two vandals, which to me seems like a decline at RFP, but I am a bit out of touch with how standards have evolved over the years). As for PC, it really only works on low traffic pages, and it has the ability to confuse and frustrate mobile editors who won't see that their change has gone through. The fact that the extension is not properly supported is also an issue. Sorry about the rant. Regards, 81.177.3.8 (talk) 17:06, 30 July 2021 (UTC)

Side comment

I have always thought that if the goal is to entice new editors to get involved, then featuring an article that has been worked on for years, and is (essentially) complete is the wrong way to go about it (and yes, I know WP articles are never “finished”… but I think you know what I mean). Perhaps we should (also) highlight an “article for improvement” to fulfill that goal. Blueboar (talk) 13:45, 28 June 2021 (UTC)

This was tried back in 2013, and didn't work out * Pppery * _{it has begun...} 13:58, 28 June 2021 (UTC)

The main issue (I think) with improving articles is the broadness of the topic. For example, I would probably be unable to improve the article Philosophy much, as I don't even know what to add or remove. Only an expert would know consensus and due and undue weight. Looking at Wikipedia:Articles for improvement/2013/21, subjects like Ancient music and Emigration are also very difficult to improve. What should be improved? Due and undue weight? And what about Wikipedia policies and guidelines? I think a better idea would be to list pages that are easy to improve, such as minor CE. Sungodtemple (talk) 17:14, 28 June 2021 (UTC)

Wikipedia:Growth Team features is currently being trialled on English Wikipedia. One of them is to provide a list of suggested tasks for newcomers. isaacl (talk) 23:19, 30 June 2021 (UTC)

The Main Page has different sections. DYK and ITN articles are more underdeveloped. ITN articles are more exciting and ITN events are good for editor recruitment, perhaps the best Main Page section for that purpose. I think one section - TFA - for showing off sustained development to get an article to a 'complete' form is a good thing, both for possible motivation to get articles to that stage, and for readers to see what such articles look like. ProcrastinatingReader (talk) 14:08, 28 June 2021 (UTC)

@FAC coordinators: Although I imagine you're all aware of the above discussion, perhaps a note should be dropped at whatever talk page is active with FA regulars? (I don't know which one that is, since you have so many). ProcrastinatingReader (talk) 20:05, 7 July 2021 (UTC)

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

Preventing IP editors from creating article talk pages

So, as I understand it, IP editors & brand new accounts can not create new articles. But that hasn't stopped them from trying. Every night Wikipedia:Database reports/Orphaned talk pages is generated which is a list of orphaned talk pages, mostly created by IP accounts, where there is no accompanying article. Sometimes the talk pages just have random comments but often there is the draft of an article. This is not a huge problem, since I've been checking it, there are anywhere from 5-15+ pages listed each day. But it does happen daily and I wonder if the IP account page creation ban should be extended to article talk pages, especially since they are not associated with any existing articles. Occasionally, these orphaned talk pages are in redirect, category or draft space but they are primarily in article space.

Thoughts, comments, objections? Liz ^{Read! Talk!} 05:14, 27 July 2021 (UTC)

I'd tenatively oppose this, pending more information, since IPs could just as well be making a legit talkpage comment on a not-yet-existing talkpage of an existing page. Do we have data about total talkpage creations by IPs to see what fraction of that is the problem we might want to solve? You said the orphaned talkpages are "mostly created by IP accounts". Should we just limit their creation to admins? DMacks (talk) 05:45, 27 July 2021 (UTC)

Just to be clear, is the question whether to prohibit IPs from creating any article talk page, or just ones for which there is no associated article (e.g. Talk:Like this one)? If the latter is technically feasible, then perhaps doing it might indeed reduce some spam, but we should not be stopping unregistered users from creating talk pages for articles that already exist, given the vital role of talk pages in the editorial process. Mz7 (talk) 07:15, 27 July 2021 (UTC)

I agree with @Mz7. ―Qwerfjkltalk 07:26, 27 July 2021 (UTC)

I also agree with Mz7. Further, if IP editors are prohibited from creating talk pages then the message they see when attempting to do so must, very prominently, link to the places they are likely intending to be - i.e. draftspace, WP:TEAHOUSE, Wikipedia:Sandbox, etc. Thryduulf (talk) 10:42, 27 July 2021 (UTC)

I agree that we shouldn't be preventing IPs from creating talk pages for existing articles, but that creation of orphan talk pages in mainspace is almost never appropriate or useful. However, I don't think an edit filter can be made that checks for the existence of a different page (e.g. to create an edit filter that restricts creation of orphan talk pages in mainspace to autoconfirmed users). If it is in fact possible I would support such a move. IPs creating draft articles in such places will only end up being confused when they get deleted - it is in their own interest that they be redirected to Draft: space or elsewhere. firefly ( t · c ) 11:18, 27 July 2021 (UTC)

question: Is it ever appropriate to have a talk page with no associated article? Asked another way, should everyone (not just IP) be prevented from creating a talk page that doesn't have an existing article? RudolfRed (talk) 17:36, 27 July 2021 (UTC)

Is it ever appropriate to have a talk page with no associated article? Yes. Talk page archives (e.g. Talk:Cuba/Archive 1 exists, Cuba/Archive 1 doesn't) and GA reviews (e.g. Talk:Ink wash painting/GA1 exists but Ink wash painting/GA1 doesn't) are the most common instances I can think of (whether they have an "associated article" depends on interpretation), but there are very occasional other uses (e.g. in the very early days of Wikipedia, the talk page of a deleted article is often the only place a deletion discussion was documented) - see Category:Wikipedia orphaned talk pages that should not be speedily deleted. I can't think of a reason why an IP editor would need to create any of these (and any exceptions will be so rare any attempt to codify them will massively outweigh the effort of just asking someone who can), but autoconfirmed users at least do need to be able to. Thryduulf (talk) 18:58, 27 July 2021 (UTC)

If it is feasible, then I support preventing IPs from creating TPs without an associated article per Mz7’s example. If we outright prohibit them doing so it undermines WP:BRD, as once an IP’s edits are reverted in an article without a TP, their only options are to edit war (possibly communicating through edit summaries) or to walk away. Cavalryman (talk) 22:58, 27 July 2021 (UTC).

• We do not currently have a technical tool available that would allow for:

IF( 
 (USER IS IP) AND
 (ACTION=CREATE PAGE) AND
 (NAMESPACE=TALK) AND
 (NEWPAGETITLE NOT LIKE "NEWPAGETITLE/*") AND
 ("TALK:(BASEPAGENAME:NEWPAGETITLE)" EXISTS) AND 
 (PAGE (main):NEWPAGETITLE NOT EXISTS)
  )
THEN DISALLOW CREATION;

• (or something resembling that pseducode). If we wanted to stop creation of all new talk pages by unconfirmed editors, that would be trivial to do. — xaosflux ^Talk 23:13, 28 July 2021 (UTC)

  The (NEWPAGETITLE NOT LIKE "NEWPAGETITLE/*") line could possibly be omitted, as IP editors shouldn't need to create new talk page archives and while I haven't looked I doubt they are frequent initiators of GA nominations. I get the impression from your tone though that this would not make a material difference to the ability to implement the proposal? Thryduulf (talk) 23:51, 28 July 2021 (UTC)

• Yup, this is technically impossible in the software AFAIK. But you could request an adminbot to CSD such pages automatically. ProcrastinatingReader (talk) 23:28, 28 July 2021 (UTC)

  I would oppose deleting these pages without human review, as they could contain viable drafts, help requests, and other things where the only problem is being in the wrong place. Thryduulf (talk) 23:47, 28 July 2021 (UTC)

• Per Mz7. It would be nice if the software prevented talk pages eligible for G8 from being created by non-autoconfirmed accounts. If you can get the WMF to do that (or can do it yourself) you have my blessing. Without that, the status quo of "letting them do so and having an admin mop them up every day or two" is the best option. I agree with the above suggestions that we can't trust a bot to do those deletions. User:力 (power~enwiki, π, ν) 23:50, 28 July 2021 (UTC)
• If it were possible, I would support, but it seems to be impossible with our current technology. I'd be interested in what the volume of bot deletions would be, but like others I'm wary of biting IPs who post viable content only to have it instantly deleted. — Wug·a·po·des​ 00:09, 29 July 2021 (UTC)
• As others have expressed concern about this limiting legitimate edits, which I share, how about this idea? Either software (unlikely, but maybe there is some feature I am unaware of that would make this possible) or an adminbot (would likely need adminbot to get around salt/blacklist) automatically creates talk pages for new article-space pages a set, but relatively short (i.e. 1 hour) time after page creation. It could even be just a blank page created. This would allow editors not auto-confirmed (or IP) to make edits to legitimate article talk pages (of articles that exist) while still preventing orphaned talk pages from being created. I share the concerns about automatic deletion, but since talk pages can be deleted when an admin deletes the associated page, I cannot find any reason that automatically creating them via bot would be a problem. This also has the benefit of removing the “creating a new page” fear that some may have, and it could also be used to apply a talk page banner or other message automatically, or even categorize into “unfinished talk pages” or similar for editors to clean up and finish the “header” material. -bɜ:ʳkənhɪmez (User/say hi!) 15:43, 31 July 2021 (UTC)
  • Since I forgot to explicitly say, if such a bot were implemented, then creation of talk pages by non-auto-confirmed accounts (or even higher) would be a viable option and I would support it if a method to not hamper legitimate creations (either my bot suggestion or otherwise) is implemented at the same time. -bɜ:ʳkənhɪmez (User/say hi!) 15:45, 31 July 2021 (UTC)

Proposal: Turn on syntax highlighting by default for new accounts

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

Supporters mentioned that it would be helpful to new editors, which lowers the learning curve and improves their experience, and that the option to turn it on is hard to find. Opposers were concerned about slowness, accessibility, and difficulty turning it off. Arguments are relatively equal, and many editors supported implementing this change, so I find that there is clear consensus to turn on syntax highlighting by default for new accounts. –Novem Linguae (talk) 09:10, 4 August 2021 (UTC)

---

Tracked in Phabricator
Task T288161

Syntax highlighting is an extremely useful feature launched in 2018 that helps make wikitext easier to read by turning wikilinks blue, templates purple, references green, and other color codings. It can be toggled on or off at any point by clicking the highlighter button () in the editing toolbar, but many new (and not-so-new) editors take quite a while to discover it, thereby missing out on its benefits.

I propose that, for all new accounts and IP editors, syntax highlighting be enabled by default. This proposal does not involve making any changes for existing users. All editors will continue to have the option to turn syntax highlighting on or off with a click of the button. {{u|Sdkb}} ^talk 19:09, 5 July 2021 (UTC)

Survey (syntax highlighting)

• Support as proposer. This will improve the editing experience for new editors, helping boost retention. Syntax highlighting isn't perfect (I've encountered occasional minor bugs), but over the two years it's been in widespread use, most of us seem to have found it to be a clear positive. {{u|Sdkb}} ^talk 19:09, 5 July 2021 (UTC)
• Support Helps to improve retention, and it looks good too. dudhhr_Contribs 02:31, 6 July 2021 (UTC)
• Support I genuinely didn't even know this is a thing and sincerely wish I'd known when I first got started here. Without syntax highlighting, it's just one big intimidating mess, plus the icon doesn't really communicate what it does. I do appreciate you mentioning it and letting me know it's a thing. // NomadicVoxel (talk) 17:24, 6 July 2021 (UTC)
• Support Conditional support The syntax highlighting greatly improves usability of raw wikitext syntax. It would also be nice if the WMF could evaluate editor retention metrics based on this feature being enabled for new users. MarioGom (talk) 18:15, 6 July 2021 (UTC)

• Changed my !vote to support conditional to the absence of any important accessibility issue. See discussion below. MarioGom (talk) 18:21, 6 July 2021 (UTC)

• Strongest support per Sdkb. 🐶 EpicPupper ^{(he/him | talk, FAQ, contribs | please use {{ping}} on reply)} 03:27, 7 July 2021 (UTC)
• Support The learning curve here is so steep, this is a nice intuitive way to help the user out. BTW I just tried it for the first time and will be leaving it on, I like it a lot. HighInBC ^{Need help? Just ask.} 08:45, 9 July 2021 (UTC)
• Oppose for now - it significantly slows performance on large articles. Let's see some data that this is something new editors want before making it a default. We have no idea if it'll boost retention or not. "I like it" is like the worst reason ever to make a change like this. I don't think the color scheme is accessible. I'm not sure it's the same syntax highlighter for VE source as for the old editor? And there are questions below about the feasibility of implementation. Really just need a lot more information and preparation before we can consider whether this would be an improvement or not. Levivich 13:12, 9 July 2021 (UTC)

  The problem is that it's hard to figure out what exactly new editors want because often they don't know about these sorts of pages, and there's not really any way for us to do community-run surveys of new editors. —pythoncoder (talk | contribs) 11:30, 16 July 2021 (UTC)

• Tentative support I think in general, this is definitely something we should aim for. The html stuff is going to intimidating and confusing for most new editors. However, adopting such a system should be a done carefully, and there should be tests done on both the feasibility and usability, as Levivich points out. Aza24 (talk) 16:00, 9 July 2021 (UTC)
• Support. Makes things way easier, less intimidating, easier to navigate, spot mistakes, etc ─ ReconditeRodent « talk · contribs » 01:41, 12 July 2021 (UTC)
• Strong support Hell yes. I evangelize syntax highlighting to every newbie I run into. I wish I didn't have to. Single biggest QOL improvement I've ever experienced on this site -- and the people who most need it don't have it. Vaticidalprophet 01:59, 15 July 2021 (UTC)
• Support. I always use syntax highlighting, and I think it makes it much easier to edit. Outside of the slight slowdown, it certainly won't hurt new editors' ability to edit. —pythoncoder (talk | contribs) 11:32, 16 July 2021 (UTC)
• Support as a default for everyone, as technically that's trivial to implement, and this feature is good for all cases. The raw text box without syntax highlighting is unreadable. ProcrastinatingReader (talk) 11:41, 16 July 2021 (UTC)
• Support I can't imagine myself ever editing without syntax highlightening. Very large pages were performance is affected are quite rare. – SD0001 (talk) 16:06, 16 July 2021 (UTC)
• Support Although I tend not to use it myself — GhostInTheMachine ^{talk to me} 17:18, 16 July 2021 (UTC)
• Oppose for the same reason that others are supporting – because the button is hard to find. If syntax highlighter were turned on by default, it would have to be made very very clear to every new user how to turn it off. (If I were a new editor trying to turn this off, probably the first thing I'd do is go to the "Preferences" menu, where I'd find a checkbox labelled "syntax highlighter", which is already unchecked, so I'd conclude that the only thing I'm able to do is change the colour scheme.) This proposal would necessarily require us to make the toggle easier to find, perhaps by drawing attention to it with a pop-up on a user's first edit – in which case, why not just do that, without also turning it on by default for users who might not want it? DanFromAnotherPlace (talk) 20:13, 16 July 2021 (UTC)
• Oppose struck out due to revised vote below - Qwerfjkl (talk) 19:49, 27 July 2021 (UTC) . This worked terribly on the mobile 2017 WikiText Editor, (at least it did for me), and made it almost impossible to to use the Source Editor (it seemed to offset the cursor from the actual text being edited by a few lines). ―Qwerfjkltalk 14:52, 22 July 2021 (UTC)

  I get the cursor offset thing on my iPad both with and without the syntax highlighting. It offsets whenever the keyboard is being displayed — GhostInTheMachine ^{talk to me} 18:39, 22 July 2021 (UTC)

  @Qwerfjkl, which mw:Editor were you using? The mw:2017 wikitext editor doesn't work on the mobile site. Whatamidoing (WMF) (talk) 21:39, 22 July 2021 (UTC)

  @Whatamidoing (WMF) I presume it was the default mobile source editor, then. It's been several months since I used it. ―Qwerfjkltalk 06:35, 23 July 2021 (UTC)

  I don't think that the mobile wikitext editor supports syntax highlighting at all. If you were using the desktop site on a mobile device, then you could have been using the 2017WTE, and, yes, performance would probably be terrible (as reported, e.g., at phab:T197502). Whatamidoing (WMF) (talk) 18:23, 23 July 2021 (UTC)

• I agree with Levivich and aza24. I like the idea of making source editing easier, but the consequences are too speculative. The performance hit on our large articles is non-trivial, and figuring out how to turn it off can be hard. This combination can actually make it less likely that new editors complete an edit using source. I also wonder whether there will be any significant benefit in retention. Most new editors I see or work with use the visual editor or the mobile editor and will rarely if ever see the effects. Where they would see it is on talk pages and community pages where the performance hit is more likely given the usual sizes, signature formatting, and templates. I'd support more work looking into these questions, but I think it is too soon to push this as a default. — Wug·a·po·des​ 19:41, 22 July 2021 (UTC)
• Support unconditionally. This feature is must have if you don't use Visual editor. AXONOV (talk) ⚑ 21:55, 22 July 2021 (UTC)
• Support. I have some reservations about the performance slow-down on big articles, but on every other count, syntax highlighting is an absolute boon for usability and therefore retention (uncolored wikitext is virtually unreadable). We can investigate the performance problems further, but I highly doubt their impact will amount to a net-negative for the enterprise as a whole, given the huge benefits. — Goszei (talk) 01:54, 23 July 2021 (UTC)
• Support. Colour-coding makes a huge difference to usability, and the gains far outweigh any downside. MichaelMaggs (talk) 10:19, 23 July 2021 (UTC)
• Support: this proposal reflects exactly my own experience; this is a great editing aid that I wish I had discovered earlier, and I wish for others to have the editing ease of use right away with it. Al83tito (talk) 03:13, 24 July 2021 (UTC)
  • And I would also support -as a plus but not as a prerequisite- the idea of making the button as visible as possible to allow new users to turn the feature off if they so wished.Al83tito (talk) 03:13, 24 July 2021 (UTC)
• Support — This is the first time I am reading about this feature, and wow it is a gamechanger. It would be tremendously helpful for newcomers (and somewhat experienced but slow editors like me) to have this as a default setting. — The Most Comfortable Chair 13:39, 27 July 2021 (UTC)
• Support as it considerably lower the barriers to contributing and in general makes wikitext editing much easier. I adressed performance issues below and don't see that as a significant obstacle. --Trialpears (talk) 16:46, 27 July 2021 (UTC)
• Strong oppose: I'm revising my above vote having now tried it out. The actual syntax highlighting was helpful, but it slowed my text deletion to ~one character per second, as made editing very tricky. It was fine for locating text, though. ―Qwerfjkltalk 19:47, 27 July 2021 (UTC)

  Is this exclusively when adding templates or in other cases as well? My testing on long pages it seemed to only be unclosed {{ causing major slowdown, but in that case it was real bad. --Trialpears (talk) 11:46, 28 July 2021 (UTC)

• Support - wow, what a great tool I had no idea existed. Having read the discussion and tested it out myself, I think this increases readability in a way that could lead to a real bump in editor retention. Well worth doing. Ganesha811 (talk) 04:58, 29 July 2021 (UTC)

Discussion (syntax highlighting)

• Regarding the technical aspect of this, if this achieves consensus, I will file a phabricator ticket requesting the change be made, as I don't think we can do it ourselves. It should hopefully be a simple switch to flick somewhere. {{u|Sdkb}} ^talk 19:09, 5 July 2021 (UTC)
• Wow. I didn't know about this syntax highlighting before. I though the proposal was about the syntax highlighter gadget. I think someone familiar with accessibility should assess whether these thin fonts, light blue and light green colors will not be a problem. MarioGom (talk) 18:19, 6 July 2021 (UTC)

  News to me as well; I'll have to try it. I was using the gadget for a while this year, but unbearable load times made it a net negative so I deactivated it. Maybe the toolbar version (which I embarrassingly hadn't noticed) will be so much better that I can support Sdkb's proposal. — JohnFromPinckney (talk / edits) 18:27, 6 July 2021 (UTC)

  @MarioGom There has been a revision of the colors to ensure they meet AA contrast guidelines for accessibility (phab:T271895) but those changes don't appear to have actually been deployed here yet (phab:T280024). I've asked on the latter task to make sure it's not slipped through the cracks. the wub "?!" 21:40, 6 July 2021 (UTC)

• ? @Sdkb: unless I'm missing something, that toggle isn't a preference, is it? I'm asking because if it isn't a preference, there isn't anything to "set on an account" - which means that the request isn't going to be that the English Wikipedia to opt-in people to a new value by default, but that you want developers to invent this capability and incorporate it in to the user preferences database as well. Also, I don't think this is even available in MobileFrontEnd (just FYI). — xaosflux ^Talk 22:16, 6 July 2021 (UTC)
  • Perhaps @Pastakhov: can let us know more about that capabilities of mw:Extension:CodeMirror. — xaosflux ^Talk 22:20, 6 July 2021 (UTC)

  You probably know about the technical side than I do. From my understanding, it's not something that appears as a preference in the formal sense. However, the software seems to remember when I turn it on or off, so there must be something somewhere tracking it. {{u|Sdkb}} ^talk 22:32, 6 July 2021 (UTC)

  Cue my signature comment: I think we can do this locally with a JS hack. See: tests: [2][3] pref: [4]. ProcrastinatingReader (talk) 22:47, 6 July 2021 (UTC)

  @ProcrastinatingReader: So your proposal is to run a javascript hack on every page to click that button - but to fit this proposal it will need what: some stored local storage item that keeps track of your option preference in case you are someone that isn't supposed to have it on? — xaosflux ^Talk 23:12, 6 July 2021 (UTC)

  Keep in mind, that even an IP can edit, and it seems like they should still be allowed to turn it off when they want to? Would this be forcing it back on each new edit while they were in the same session/browser/etc? Basically, I'm saying this doesn't sound like a great idea to be pushing down for a client-side hack around that would need to process for even IP editors. — xaosflux ^Talk 23:22, 6 July 2021 (UTC)

  Pretty much, but note prefs aren't saved for IP users anyway. Alternatively, it seems this documents mw.user.options and suggests it correlates with $wgDefaultUserOptions. It's not in the doc but see here. According to doc comment, it should already be enabled by default. ProcrastinatingReader (talk) 23:47, 6 July 2021 (UTC)

  It was trivial to see that it is not by IP's, just open this link in a private browser window and see. — xaosflux ^Talk 23:54, 6 July 2021 (UTC)

  Right exactly, it's not, but according to the code it should be, so something seems off. The extension docs give a solution to turn it on by default, claiming it isn't, but that contradicts the extension code and AFAICS the key isn't overriden in our config. ProcrastinatingReader (talk) 23:57, 6 July 2021 (UTC)

  To follow up, after some discussion on IRC we discovered that the extension isn't properly setting a default for the preference, so it ends up defaulting to disabled. Legoktm (talk) 08:38, 7 July 2021 (UTC)

  It's technically easy to set a difference preference for new accounts, and MediaWiki supports that. The reason it usually isn't done is because it creates a weird experience. E.g. what does "Reset to defaults" do, does it reset to *your* defaults or everyone's defaults? If this is a good feature that people don't know about, I think it makes sense to change everyone's defaults but make it straightforward / one-click to turn it off if you don't want it. Legoktm (talk) 00:02, 7 July 2021 (UTC)

  • Please keep in mind, I'm not trying to argue that CodeMirror defaults are necessarily good or bad - just that this proposal seems to be cart ahead of the horse, it doesn't take any community consensus to ask developers to look in to adding the functionality to program this. — xaosflux ^Talk 23:24, 6 July 2021 (UTC)

    Looking at the discussion, maybe the RFC is a bit premature, and it might lead to an unimplementable or under-specified decision. I think it is still useful to gauge community support for this idea, but the final decision would probably need to be done when:

    • The new accessibility-tuned color scheme is deployed (phab:T280024) and we all have some time to test it. I support this idea, but I'm finding the current color scheme fatiguing.
    • We have an approximate idea of the implementation path and its ramifications.

    --MarioGom (talk) 08:33, 7 July 2021 (UTC)

    Implicit in every support !vote is "support, assuming it's technically feasible". If this gains consensus, we'll file the phab ticket and see what response we get, but uncertainty about that shouldn't be a barrier to assessing consensus. Likewise, anyone who wants to condition their support on the colors update being rolled out is welcome to do so. {{u|Sdkb}} ^talk 07:47, 10 July 2021 (UTC)

    We can perhaps opt into the accessibility update developed by WMDE, assuming they're okay with us doing so. Technically it's a simple config switch, but I presume their consent would be required. ProcrastinatingReader (talk) 11:42, 16 July 2021 (UTC)

• I have used this since it came out. It is quite helpful, although it does take a bit getting used to it. I leave it on all the time. That said, there are often times that while generating an edit page it cannot load due to a timeout (of some fraction of a second), so it just defaults to no highlighting. I don't know which end of the connection is causing this. Is it the current hotel I'm in, or are our servers struggling with the user load at those times. I wonder what the drain would be on the system and / or bandwidth if everyone's using this? GenQuest ^"scribble" 23:15, 24 July 2021 (UTC)
• Is it possible to make the syntax highlighting disable itself when in a page or section that exceeds a certain amount of bytes (like 200,000), or when it's in (a) certain namespace(s) (like the talk pages)? That might satisfy both those who wish to make it easier to edit the source code for newbies, as well as those who are concerned about the performance penalty in large pages/sections. pandakekok9 (talk) 14:51, 27 July 2021 (UTC)

  There's no actual evidence it meaningfully slows down pageload. Has anyone presented any performance timings on slow devices as evidence? Or any other form of evidence, at all, for the assertion? And frankly, if one is trying to edit a 200k char page on a slow device and not using per-section editing, it's going to be unbearable anyway. ProcrastinatingReader (talk) 15:24, 27 July 2021 (UTC)

  I've done some testing about this on our longest article, List of dramatic television series with LGBT characters: 2010s, which sat at 528kb. It looks like there's no appreciable slow down if you don't have a template that is opend but not closed. In that case it was unbearably slow. At a large but not insanely large page like Iceland, 183kb it was slow but managable. Given that normal editing that newcomers are likely to perform isn't affected and the slowdown is only particularly bad on very long pages I think it's without a doubt better to have highlighting on by default. Perhaps some people are thinking about the gadget which does have very serious performance issues. --Trialpears (talk) 15:58, 27 July 2021 (UTC)

• I use this type editor on Commons and its of great help (it appeared without me doing anything). At the same time, I still couldn't discover how to use this feature on English Wikipedia, despite me becoming a relatively experienced editor with over 1.5k edits, each averaging almost 600 bytes. From my own experience I can say that new editors will certainly find it easier to use the "highlighted syntax" editor. But I think that when someone opens the editor for the first time, a message should pop up telling about different types of editors and where to switch between them, along with a checkmark option to disable the message forever, like the one used when uploading files to Commons. (I'm mostly at Support level as of now, will vote above when I make my final decision.) Thanks! ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 17:52, 27 July 2021 (UTC)
• I generally support syntax highlighting by default, but I'm somewhat concerned about performance issues that are not related to page load times; I'm on a reasonably modern machine, but I've lost edits before when I edited very large pages with syntax highlighting enabled; the editor sometimes slowed down, then went to a white loading screen and never recovered. Granted, this might be mostly a "me" problem, but seeing 15 minutes of work disappear can be a very frustrating experience (which is why I've switched to remember the dot's syntax highlighter a couple months ago). Keeping in mind that many of our editors may be using weakly performing devices to access Wikipedia, I would only support enabling this by default if we can rule out that issues like this may still occur. --Blablubbs (talk) 10:24, 28 July 2021 (UTC)

  This definitely still happens for me, even for short articles. ―Qwerfjkltalk 11:34, 28 July 2021 (UTC)

  @Blablubbs and @Qwerfjkl (and anyone else), I wonder whether there might be a "meet in the middle" approach, that solves @CX Zoom's problem without auto-enabling it. Maybe a box that pops up with a note about enabling syntax highlighting? Whatamidoing (WMF) (talk) 20:36, 28 July 2021 (UTC)

  @Xaosflux and Legoktm: are probably most likely to know whether that's possible in the software. ProcrastinatingReader (talk) 22:06, 28 July 2021 (UTC)

  It seems like it should be technically possible to me, we have something similar for CodeEditor (syntax highlighting for JS/CSS/Lua pages), where there's a one click button in the toolbar to turn it off/on. I do think the "losing large edit" problem might be better served by implementing VE's drafts feature in the regular wikitext editor too... Legoktm (talk) 03:43, 29 July 2021 (UTC)

  I would strongly oppose the pop-up box approach. When we think about the new editor experience, we need to be extremely selective about what information we present, as we want to get them to the point of having made a constructive edit before they give up. We're already asking them to read a lot of important things (e.g. copyright notice, plea to add references) and to decide between VE and source. Adding another box they have to click through builds the pile and introduces potential confusion (some people may think turning on syntax highlighting is activating the VE). I'd much rather use that valuable pre-edit moment to communicate core concepts like referencing than to explain this particular feature. We shouldn't force people to set up a whole comprehensive profile just to fix a typo. {{u|Sdkb}} ^talk 18:35, 29 July 2021 (UTC)

  I agree with the sentiment that popup notices at the very beginning may scare some editors away. Maybe, then we can create a Help article at Help:Different ways to edit Wikipedia. Over time, editors will learn more about the various editing methods. As for new editors, they can be greeted with highlighted syntax editor. Even if there *might be* some performance issues associated with it, one shouldn't expect new editors to make massive edits. For experienced editors, they can switch anytime they wish to. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 08:59, 30 July 2021 (UTC)

• Do we have any actual data on how much speed and load times tend to be affected with this? --Yair rand (talk) 05:28, 29 July 2021 (UTC)

  I don't suppose we do. From my personal experience though, I have felt that the difference in load times is negligible or non-existent, unless it is a page with a lot of Wiki-markup or errors. Pages with a lot of words don't seem to make a significant difference in load times for me, and I use half a decade old laptop with less than average internet speeds. On my laptop, the edit window of this talk page with over 210,000 bytes loads syntax highlighting essentially right away. But the edit window of Rafael Nadal — with more than 240,000 bytes — takes an extra second or two to load syntax highlighting after the edit window is opened, which is probably because of the large amount of Wiki-markup in the article. Even so the edit window does load just as quickly as with syntax highlighting disabled. — The Most Comfortable Chair 04:28, 31 July 2021 (UTC)

  @The Most Comfortable Chair The load time can be significantly worse on mobile devices (as I know from personal experience)./ ―Qwerfjkltalk 11:22, 31 July 2021 (UTC)

  Edit windows are excruciatingly slow to load on my mobile phone and they crash frequently, without syntax highlighting turned on. I used to edit on my phone before I knew this was a feature, so I wouldn't be sure if syntax highlighting makes it worse or if edit windows on mobile phones are buggy in general. — The Most Comfortable Chair 12:24, 31 July 2021 (UTC)

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

Sdkb, do you wanna take care of the phab ticket? --Trialpears (talk) 09:25, 4 August 2021 (UTC)

Sure, filed phab ticket: phab:T288161. We'll see how it goes. {{u|Sdkb}} ^talk 19:36, 4 August 2021 (UTC)

I missed this whole discussion, but with regards to performance: this will greatly be improved in the coming year or so once we roll out CodeMirror 6. You can follow phab:T259059 for updates. — MusikAnimal ^talk 16:26, 5 August 2021 (UTC)

Proposal to tweak ClueBot Edit summary

Specific proposal: Replace ClueBot edit summary of "Reverting possible vandalism by [username]" with less judgemental "Edit by [username] not accepted" (or some other bland edit summary that you all can come up with. Details follow.

---

We all love ClueBot, it is this astounding machine, it is essentially always correct about when an edit is bad, and it's very very helpful in patrolling and keeping our articles free of nonsense. When it does delete a contribution, it leaves a nice and non-accusatory notice on the contributors talk page. That doesn't mean ClueBot is absolutely perfect, and I think that its edit summaries could be improved.

About, I dunno, 95% of the edits ClueBots flags are vandalism. The other 5% are bad edits, worthy of and needful of being deleted, but not actually intentional vandalism. These shouldn't really be tagged as vandalism or possible vandalism (ClueBot always leaves an edit summary of "Reverting possible vandalism by [username]".) Not a huge deal, since the edits are pretty bad even if in good faith, but not absolutely ideal, and easy to change I would think? It could just say "Edit by [username] not accepted" or "Reverting edit per ClueBot algorithms" or something that doesn't say "vandalism".

So, for the first time ever, I just saw (here) ClueBot roll back some edits by a new and possibly promising user User:Franco tradisionele disse that were actually reasonably OK. There were several misspellings (contributor is ESL), and no sources, and whatever else, and ClueBot got triggered, but the information itself was Wiki-standard and it was the kind of new-user edits that you can work with, and the kind of editor that you can work with. I am not complaining about that. I'm gobsmacked that people were able to make something so amazing, and even if it happened more often I'd still be a ClueBot fan. I'm just talking about the edit summary.

So, in this one case, the new editor was wrongly called a vandal, and this violates the First Law of Robotics if one takes "injury" to include "insult". (Or possible vandal, which's not much better, anymore than "you're possibly an asshole" from a human colleague is not really neutral). The user was surprised and confused by this and it would be understandable if she was upset. Yes I know that its just one person (so far, that I know of), but still.

So couldn't we petition to have the edit summary just changed to something more bland and judgemental (and that, since simply describing an action, correct 100% of the time rather than 95%)? Am I missing something here, or is this worth even worrying about, or is there too much downside? What say you? Herostratus (talk) 20:05, 19 July 2021 (UTC)

I say "Reverting edit by [username]" to be more neutral. "Edit not accepted" makes newcomers think ClueBot is perfect, which it isn't. Sungodtemple (talk) 20:39, 19 July 2021 (UTC)

There isn't a nice way to be told by a robot that your edit was so problematic it's been reverted. New editors will have no idea what ClueBot does, and why it might revert them. The important thing is to be directed to somewhere that explains the situation, and what you should do about it. Perhaps "Edit triggered a problem detected by ClueBot; editor, please see your talk-page for an explanation" or something similar Elemimele (talk) 20:54, 19 July 2021 (UTC)

I don't see this as particularly useful as a user may question why the edit has not been accepted to which the response would be: suspected vandalism. So it would just be adding confusion to the reverts. Terasail^[✉️] 00:12, 20 July 2021 (UTC)

Please link to prior conversations around this so that others can at least see the somewhat lengthy debate around the matter:

• User talk:ClueBot Commons/Archives/2021/July#WHOOP WHOOP TERRAIN TERRAIN
• User talk:ClueBot Commons/Archives/2017/December#Proposed change to standard wording

For this specific proposal for this specific messaging, Oppose as it does not contain the word "revert" or "vandalism" and is therefore likely to cause problems with other automated tools looking for one of those specific words in edit summaries to identify reverts. -- Cobi^(t|c|b) 00:40, 20 July 2021 (UTC)

OK. Including "revert" is fine with me, but you're saying that one robot has to use the word "vandalism" so that another robot can understand that dif. Even it is not vandalism. As it isn't, 5% of the time. Needs of robots trumps need to be as welcoming as possible seems to be what you are saying? Herostratus (talk) 00:55, 20 July 2021 (UTC)

Oh, and don't forget people, ClueBot also leaves a message on the user's talk page. IIRC this message is fine, it doesn't mention vandalism, notes that it might be wrong, and so on. Probably because on a talk page message you're not limited to a short string. But because the contributor's name is link in the edit summary (which it has to be), the person is also drawn to the edit summary. How about maybe "Edit reverted, see your talk page"? Herostratus (talk) 01:05, 20 July 2021 (UTC)

• Oppose any "not accepted" verbiage. 1) This could be suggestive that the edit was never published, when it was. 2) This suggests that edits are normally going through some sort of acceptance review, which they are not. — xaosflux ^Talk 02:06, 20 July 2021 (UTC)
• Oppose. To the proposals points directly, I do not believe you can add "insult" to the First Law of Robotics until you cross into some form of Harassment, which is certainly not within ClueBot's capabilities or current wording. With 1RR and friendly wording ("Report False Positive? Thanks, ClueBot NG"), ClueBot is doing its job while being as friendly as possible. Furthermore, as mentioned by Cobi in the previous discussion on ClueBot Commons, another person coming up to you and calling you a "possible asshole" is comparing apples to oranges here. It's also a major escalation in severity that, again, does not apply to a robot saying the same thing to everyone.

Now, it is my opinion that ClueBot uses phrasing I believe any reasonable person would not take offense to. The "possible" qualifier implies that the revert, be it done by a human or bot, could be in error. This is the same verbage I would see used in any other ambiguous situations - "possible phishing" in my mail client, "possible spam," on my phone's call screen, "banned for possible cheating" in a video game. It implies that there is room for error and to seek assistance and/or take caution in your further actions.

That all said, the primary reason I oppose such a change is strictly technical - changing even minor things will break someone's workflow. Other tooling expects this wording from ClueBot. Creating change here does not create a net benefit for something I do not see as an existing problem. -- SnoFox^(t|c) 07:32, 20 July 2021 (UTC)

A forgotten point from my original oppose: As for what the message should contain, I think it is important for robots to inform humans as to why they're taking action. Simply removing the reason, as suggested, will create even more confusion. If you are unfamiliar with ClueBot, what is more obvious than specifying exactly what it thought you did? Wikipedia has a word for it - it's vandalism. We should use that term, not try to sugarcoat it or hide it. The current text is succinct and as friendly as possible given the technical restrictions around edit summaries. -- SnoFox^(t|c) 07:55, 20 July 2021 (UTC)

• Oppose both proposed wordings here. The "not accepted" wording is highly confusing because it inaccurately suggests we have some kind of approval process for edits to be accepted. I also don't like the "check your talk page" type wording because it obscures the reason why the revert was performed and I think that it would make the page history difficult to follow - in 10 years time you're going to be directing people to messages that likely don't exist anymore. I think there could see some benefit to modifying the message to make it more explicit that the actions were being performed by a bot (perhaps add something like "this action was carried out by an automatic computer program" before the link to submit false positive reports?) but I don't think the current wording is particularly problematic or offensive. 192.76.8.91 (talk) 16:00, 20 July 2021 (UTC)

No - ClueBot makes it clear that it is possible vandalism. Possible being the key word. It means it could not be vandalism, but ClueBot is only making a statistical guess. Aasim (talk) 02:27, 22 July 2021 (UTC)

I would suggest something along the lines of "Reverted edit by [user]: Non-constructive" ―Qwerfjkltalk 16:02, 22 July 2021 (UTC)

Arbitrary break (ClueBot edit summary)

So let's see, at this point we have...

• Original proposal (by me) was "Edit by [username] not accepted"
• Next editor suggested "Reverting edit by [username]" (which is better IMO)
• Next editor suggested "Edit triggered a problem detected by ClueBot; editor, please see your talk-page for an explanation" (which is even better IMO, but there are possible length issues)
• Next editor is OK with keeping current ("possible vandalism") as this gives clear reason.
• Next editor is OK keep with keeping current as the word "vandalism" must be kept in for benefit of other robots
• Next editor is only opposed to "not accepted" language (not clear if OK with current)
• Next editor is OK keep with keeping current as any change could disrupt other robots (also, no reasonable person minds any of their edits being called "possible vandalism")
• Next editor is OK with keeping the current, altho adding "this action was carried out by an automatic computer program" might be good
• Next editor is OK with the keeping the current, basically.

It looks pretty even, but a big sticking point is the fear that other programs (or whatever else is including in "workflow") would be disrupted. Big if true, but how big is this really? I'm asking. What do these other programs or workflows do? Important stuff, or paper-shuffling? Counting how many edit summaries contain the word "vandalism" and stuff like that? That's good for reports like "2.1% more edit summaries use the word 'vandalism' in April", and that's OK but it's really just bean counting.

I myself seldom use the revert buttons, or the word vandalism; I often (not always) just restore the previous version and give a hand-written explanation and/or use "revert test edit" (there are a non-zero number of useful editors here whose first edit looks like vandalism but was probably just testing to see if you really could edit an article just like that, and assuming good faith is recommended). So anyway, my revert edit summaries seldom contain the world "vandalism" even if it probably is, so... am I breaking other robots? Am I messing up people's workflows? Should I not do that? Is there a guideline somewhere to that effect? (FWIW Wikipedia:Edit summary legend seems to support the use of "rvv" for vandalism reverts, so maybe you need to talk to those people too.)

Or do these other robots only care about what other robots are doing, not what we meat units write? Well for goodness' sakes why? This sounds sketchy, don't you know how that sort of thing ends up? (BTW we know that the First Law of Robotics prevents a robot from assaulting you, wouldn't it also prevent it from saying "Eat my dust, touchhole"? I think the Science Police would say so. Emotional injury is injury.)

"Revert" is fine, an editor at User talk:ClueBot Commons/Archives/2017/December#Proposed change to standard wording averred that "many tools key off of the regex '/^revert/i'", which, OK, keeping the string "revert" in it makes sense anyway as a purely descriptive human-readable characterization of what happened.

Anyway, I'm struggling to think what the actual problem here is. Help me out here. Show me an important robot that requires the use of insults to function, that can't be rewritten or dispensed with, and you'll get my attention. Herostratus (talk) 15:45, 22 July 2021 (UTC)

ClueBot NG reads edit summaries from other users here and here. That could definitely be updated for ClueBot NG itself, but this shows that it isn't an unusual thing to do for other tooling. A quick search of Wikipedia itself reveals this user's monobook.js and another here keys off of edit summary messages like this -- no idea what it is doing with that data, though. There are more: [5] [6] [7] [8] and the examples keep coming if I keep trawling through the search results. And that's not even off-wiki. There are a ton of tools with off-wiki source code and those would need to be checked, too. -- Cobi^(t|c|b) 04:28, 23 July 2021 (UTC)

The problem is that the edit summary that is being proposed by you the original poster seems to be very vague. It gives no reason why, it is far less helpful explaining what is going on to other editors, and it will confuse the editor who made that edit as they will have no understanding why their edit was reverted.

I would favor replacing "Possible vandalism" with "Possible unconstructive edit" but for the most part, the edit summary is very clear.

"Reverting possible vandalism by $2 to version by $1. Report false positive? Thanks. Cluebot NG (Bot)"

The message delivered also makes it very clear that the bot sometimes makes mistakes. And for the size of the wiki, I think having a bot help revert vandalism at the cost of catching some false positives is understandable. Aasim (talk) 21:49, 22 July 2021 (UTC)

• Oppose. There will always be some small percentage of ClueBot edits that will be mistaken, which is why its edit summary includes "possible", but a 95% (or whatever it is) success rate is good enough that there's more of a downside from making the bot less clear/direct about what its doing than there is an upside from the extreme assumption of good faith. {{u|Sdkb}} ^talk 00:06, 23 July 2021 (UTC)
• Oppose I have no problem with the 5% that might get their feelings hurt. 95% correct flagging is well past an acceptable threshold. This is not an issue worth much discussion time. GenQuest ^"scribble" 22:53, 24 July 2021 (UTC)
• Oppose. It is important that invalid reverts have a clear and accurate description. When cluebot gets it wrong we want people to understand and confidently revert cluebot. The various alternatives raise a serious risk of people seeing a bad cluebot edit, presuming the edit is somehow legitimate or authoritative, and believing they should not touch it. Even worse, research has shown that unexplained reverts are a real killer on new users. This proposal would inadvertently cause new users to give up, feeling powerless because their edit is "not accepted" for no comprehensible reason. Alsee (talk) 08:41, 31 July 2021 (UTC)
• The summary of Cluebot NG's task is very clear: an anti-vandal bot that tries to detect and revert vandalism quickly and automatically. Changing the edit summary made by the bot doesn't achieve anything, and will just lead to more confusion, IMO. All vandalism is unconstructive, but not all unconstructive edits are vandalism. So no, the "not constructive" suggestion doesn't work either. pandakekok9 (talk) 05:11, 4 August 2021 (UTC)
• Oppose, the current message is fine ("possible" vandalism). Stifle (talk) 16:34, 9 August 2021 (UTC)

People can't create an article on English Wikipedia like before

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

---

Hi Wikipedia users!

People can't create a new article on English Wikipedia like before. For example first when trying to create an article that doesn't exist, when entering the words on search section it doesn't appear anymore "Start this article" in red on the bottom of the page with or without search results. Then the second when entering parts of the words for creating an article on the browser, for example: https://en.m.wikipedia.org/w/index.php?title=Wikipedia:New_user_landing_page&page=Donkervoort+10 (to create an article for Donkervoort) it appears the tab to create it as a draft which we don't want to create the article as a draft but to create it directly. The option to appear like creating an article like before appear only when entering these part of the words: https://en.m.wikipedia.org/w/index.php?title=Draft:Donkervoort_D10/editor/all&redirect=no# Or when the article was created before than was redirected to the main article. We want to remove the draft option and return the first option to appear an option in red for creating the article when entering the words for an article that doesn't exist on the search tab and also to create the article when entering the part of the words on a browser like: https://en.m.wikipedia.org/w/index.php?title=Donkervoort_D10/editor/all&redirect=no# which when using this option to create an article for Donkervoort appears to create as a draft.

Thanks — Preceding unsigned comment added by SIDITJAUPI (talk • contribs) 19:08, 9 August 2021 (UTC)

@SIDITJAUPI: Your account isn't confirmed yet (10 edits, 4 days registered). As a result of WP:ACPERM, non-confirmed users are not allowed to create articles directly in the mainspace; you either need to become confirmed, or use WP:AFC. ProcrastinatingReader (talk) 19:10, 9 August 2021 (UTC)

This isn't going to happen. ACPERM is one of the few instances where the move is backed by the community, the Foundation, and the facts and the goal is keeping out unencyclopaedic content, including advertizing. I should note OP has since been blocked as a sockpuppet. —A little blue Bori v^_^v ^{Jéské Couriano} 05:51, 10 August 2021 (UTC)

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

Integrating the Vital article template into the talk header

Should {{Vital article}} be integrated into {{Article history}}? ~ HAL333 21:03, 23 July 2021 (UTC)

• Support as nominator to limit talk page clutter. The current Vital article template takes up a relatively large amount of room for the required text: "This is a level-# vital article in this subject." ~ HAL333 21:03, 23 July 2021 (UTC)
• You're suggesting a merger with {{Article history}} and not {{talk header}}? If so I feel you should change the header to avoid confusion. Either case I have some issues but I don't see it as a complete non-starter. --Trialpears (talk) 21:20, 23 July 2021 (UTC)
• I think that most of the time the WikiProjectBannerShell is the best place for this information on crowded talk pages. User:力 (power~enwiki, π, ν) 23:01, 23 July 2021 (UTC)

• Support Consider this more appropriate than WikiProjectBannerShell or talk header. Hawkeye7 (discuss) 00:06, 24 July 2021 (UTC)

• comment I just wish someone could convince me that "vital article" is meaningful with good, well followed criteria. Doug Weller talk 09:22, 27 July 2021 (UTC)

I 100% agree with Doug Weller, selection of what are deemed to be vital articles seems to be pretty arbitrary, and further I don’t really see value of the list any more. Cavalryman (talk) 23:17, 27 July 2021 (UTC).

• I suggested this at the idea lab last year; SandyGeorgia had some thoughts at the time convincing me against it, and might be interested in this discussion. ProcrastinatingReader (talk) 00:10, 28 July 2021 (UTC)

• Add to WikiProject banner shell only-- should not be cluttering talk pages at all. Thanks for the ping; my opinion is formed by having watched efforts like this come and go over about 15 years. Like so many of the earlier Wikiprojects that attempted to classify articles by importance, this is ... no more than a currently-popular WikiProject that is likely to be replaced in a few years by the next iteration of a scheme from a different group of editors. (In most areas I edit, it is apparent that the choices aren't always logical, either.) This should be added only to the WikiProject banner shell, as merely another Wikiproject that is likely to be replaced somewhere down the road. I agree with both Doug Weller and Cavalryman that the selection seems to be entirely arbitrary, and not really reflective of ... much of anything (same was true of similar past projects). It should not be added to either talk header or article history, rather just another WikiProject, rolled into that banner shell. SandyGeorgia (Talk) 19:03, 28 July 2021 (UTC)
  • I hate to argue with the person agreeing with me that WPBS is the right location, but I don't think it's fair to call WP:VA a transient and arbitrary project. It is the sole successor of the earlier "CD" projects, after people realized that nobody needed a CD with part of Wikipedia (the various Kiwix projects can fit all of Wikipedia -- at least all the text). Also, at least at the higher-importance levels has been repeatedly picked over for non-arbitrariness. User:力 (power~enwiki, π, ν) 23:55, 28 July 2021 (UTC)
• Add to WikiProject banner shell per others mentioned above and I agree with 力 about Vital article being useful and I make use of it myself. Huggums537 (talk) 19:30, 30 July 2021 (UTC) Strike and switch to...
• Oppose per comments by Sdkb. Also, I didn't realize my previous vote would involve collapsing. Huggums537 (talk) 14:18, 9 August 2021 (UTC)
• Comment I have integrated {{Vital article}} into {{WikiProjectBannerShell/sandbox}}, and editors can see some examples. Should this be closed that way, let me know and I can make it live. Otherwise the same kind of coding can be used in {{article history}}. — Wug·a·po·des​ 23:33, 30 July 2021 (UTC)

  @Wugapodes: can we move it into the collapse? ProcrastinatingReader (talk) 19:38, 6 August 2021 (UTC)

I think I would support the move into the collapse. Cavalryman (talk) 13:06, 9 August 2021 (UTC).

• Comment I think this proposal is thinking along the right lines, but ultimately I can't support. The vital article banner takes up an entire banner just to communicate one small piece of info, which isn't necessary, especially considering many vital articles will have many other banners. But it's not part of an article's history, so it doesn't fit there, nor is it a topic-based WikiProject in the same way as the projects that get collapsed into the WikiProject banner. It should ultimately be consolidated into something, but I'm not sure whatever that thing is is ready yet. {{u|Sdkb}} ^talk 15:06, 3 August 2021 (UTC)

  Sdkb, Would you support integration into {{talk page header}}? Shibbolethink ^{(♔ ♕)} 13:32, 13 August 2021 (UTC)

• Question, given the vital article list is the domain of a single WikiProject, shouldn’t the vital article banner just be considered a standard WikiProject banner and placed inside the WikiProject banner shell along with all other pertinent WikiProject banners? Cavalryman (talk) 03:41, 4 August 2021 (UTC).

  I don't think so. The WikiProjects listed in the banner are all content projects—people look to that banner to answer questions like "To what content areas does this article relate?" and "Where can I find other editors knowledgeable about this topic?" The vital article notice is included on talk pages for an entirely different reason, and answers the totally different question "How important is this topic?". {{u|Sdkb}} ^talk 19:47, 4 August 2021 (UTC)

  A WikiProject is a group of people who want to work together to improve Wikipedia. The group of people who want to improve Wikipedia by working together is a WikiProject, too, even if their area of effort is in identifying broad subject areas rather than everything about a single subject area. See also Wikipedia:WikiProject Articles for creation, which also doesn't have a narrow content area, and Wikipedia:WikiProject Disambiguation, whose focus is on improving Wikipedia in all articles. WhatamIdoing (talk) 19:20, 6 August 2021 (UTC)

• Oppose mainly because as far as I can tell the vital articles project is just the priority list of a few people, hardly something that rises up to "talk page banner" importance. OTOH, adding it to the Article history template is OK for me. Jo-Jo Eumerus (talk) 19:43, 6 August 2021 (UTC)
• Oppose. Keep it where it is. My personal opinion of vital articles is that they are a somewhat useful indicator, used in various places for getting a very rough idea of what our most important articles are. The decisions made there should never influence what happens in article space, or indeed the main page, other than as an indicator, but I think it's fine to have a small talk-page banner indicating that the article in question has been selected.  — Amakuru (talk) 13:24, 13 August 2021 (UTC)

WikiProject links in navigational templates

Many navigational templates includes links to non-article content at the bottom of the template. This can include useful categories, portals, outlines and more which should not be removed. A typical example of this from {{Canadian Forces Air Command units}} below this comment.

My concern is about these links including WikiProjects as these clearly contradict MOS:LINK which states In articles, do not link to pages outside the article namespace. These pages are not reader facing and should be kept out of articles.

Given their high usage, I estimate about 34,000 articles are affected, I thought it was best to make sure there is consensus for removal even though they are clearly against the manual of style. WT:LINK, WT:CLN and Template talk:Navbox notified --Trialpears (talk) 16:01, 8 July 2021 (UTC)

• Support removal of Wikiproject links, as wiki projects are not reader facing. -- Asartea ^{Talk | Contribs} 16:08, 8 July 2021 (UTC)
• @Trialpears:, I disagree with your reasoning. If you think these links violate MOS:LINK, then MOS:LINK needs to be clarified (although I think it is obvious that it is talking about links in the text). We routinely link to non-articles through templates. All of our cleanup templates do so, for example. Most navboxes have a self-link (which goes to the template namespace). —Kusma (talk) 16:13, 8 July 2021 (UTC)

  Oppose wholesale removal. In your example, I find the link pointless, but I'm not sure I do so in 34000 articles that you haven't presented here. —Kusma (talk) 16:15, 8 July 2021 (UTC)

  Kusma You're probably right about it being intended for inline links. Guess confirmation bias set in when looking for the policy/other page about linking to non-reader facing pages. The list I based my estimate on was Special:WhatLinksHere/File:People_icon.svg which is uses of the icon usually placed besides these links in mainspace. It's not a perfect list at all, but should be good enough for discussion. Could you come up with a case where a WikiProject link would be beneficial? I checked a few dozen of the pages before starting this discussion and all of them were similar to the one shown above with just as little utility. As with essentially all template edits, these changes shouldn't be done fully automatically either, but have human review to make sure they are appropriate. --Trialpears (talk) 16:28, 8 July 2021 (UTC)

  I don't have a concrete example in mind where a link currently exists (I might like a WikiProject link for smaller projects, say, on Template:Doctor Who), but generally we should be open to showing the collaborative nature of our project and consider having links in navboxes or similar that invite the reader into the backstage area. Given that most portals (our other reader-facing namespace that can be linked to) are display only showcases these days, additionally linking to Wikiprojects makes some sense. (I'd prefer portals to be much more integrated with WikiProjects and be much more about collaboration than about displaying our finest work, but I'm probably in the minority even among the two dozen people who still care about portals). —Kusma (talk) 16:37, 8 July 2021 (UTC)

• One concern - a lot of our Wikiproject’s are essentially moribund. Do we really want to point readers to moribund project pages? Blueboar (talk) 17:34, 8 July 2021 (UTC)
  • This is a good point, we really shouldn't be.... Aza24 (talk) 16:04, 9 July 2021 (UTC)
• Reluctant support I love the idea of linking to WikiProjects, especially for more specific templates, like {{William Shakespeare}} or {{Richard Wagner}}, but the age of WikiProjects has really been disappearing for sometime now, and in general linking is probably a net negative. Aza24 (talk) 16:04, 9 July 2021 (UTC)
• Categories and portals are both reader-facing, so I oppose disallowing linking to them in navigation templates. I support disallowing links to WikiProjects; it's just not an appropriate thing to do. {{u|Sdkb}} ^talk 07:53, 10 July 2021 (UTC)
• Strongly oppose removing links to categories and portals, these complement the content of the navigational template. DuncanHill (talk) 08:07, 10 July 2021 (UTC)

  @Sdkb and DuncanHill: I fully agree that categories, portals and other reader facing pages are good links and do not want them removed, just WikiProject links. I've made some slight modification to my original statement to make sure this is clear. --Trialpears (talk) 08:18, 10 July 2021 (UTC)

• Strong oppose per Kusma. It's possible that there are some links on some templates that are poor value, but the place to discuss these is at the level of the individual template not trying to legislate them away wholesale. Thryduulf (talk) 11:52, 10 July 2021 (UTC)
• Portals seem like poor value (to readers and to editors in maintenance) in general to me, but I suppose that's another discussion. I think the WikiProject links are probably a good thing. ProcrastinatingReader (talk) 12:14, 10 July 2021 (UTC)
• Strong oppose per Aza24 Thryduulf. This is just yet another bad edit to the MOS made in 2021. We've always linked to files, portals and categories. MOS:DRAFTNOLINK was only supposed to prohibit linking to the draft space. Suggest its removal from the MOS instead. Hawkeye7 (discuss) 12:19, 10 July 2021 (UTC)

  Hawkeye7 Perhaps we're misunderstanding each other? We've indeed always linked to files, portals and categories and I think we should continue to do so, but I don't feel WikiProject links are appropriate to do the same with. Also Aza24 described their comment as "reluctant support" which is quite far from your comment. --Trialpears (talk) 12:24, 10 July 2021 (UTC)

  Ooops. Wrong user. Corrected. We always have, and should continue to do so in spite of the MOS. I understand your proposal is more limited than the MOS, which bans images from articles, but I do not endorse this approach. Hawkeye7 (discuss) 12:35, 10 July 2021 (UTC)

  While I still strongly oppose MOS:LINK, and therefore any action based on it, I do accept the arguments of Sphilbrick and Blueboar that the links to Wikiprojects are editor facing and not reader facing. However, I am not convinced that all navigational templates are on article pages and not Wikipedia or Talk pages. Hawkeye7 (discuss) 20:47, 10 July 2021 (UTC)

  There are a not significant amount of navboxes intended for Wikipedia, Help and Template namespaces, but since the rationale doesn't apply there these should not be removed. If someone uses a navbox in a discussion (as I did above or in ER for example) I don't see a reason to have a link there but not in articles. It's technically possible but will likely be a cause of confusion for essentially no benefit. --Trialpears (talk) 21:50, 10 July 2021 (UTC)

  Nearly every page has at least one, including this one. Hawkeye7 (discuss) 21:29, 12 July 2021 (UTC)

• Note… Wikiprojects are usually linked to on article TALK pages. This is appropriate as Wikiprojects are “editor oriented” not “reader oriented”. Blueboar (talk) 13:10, 10 July 2021 (UTC)
  Thus… I Support removing links to Wikiprojects from article space, but would Oppose removing them from talk pages if that is proposed. Blueboar (talk) 20:06, 22 July 2021 (UTC)
• Partial oppose If you take a glance at MOS:LAYOUT, you can see that we define the elements of an article as following into four groupings: 1 before the article content, 2 article content, 3 appendices, 4 end matter. Technically, navigation templates are part of the fourth grouping and therefore part of the article, but I think when one reads the prohibition against linking outside the article namespace in articles, many would think the emphasis is on the second grouping, the article content. If a reader is in the middle of reading the article content, and comes across a linked item, it is reasonable for them to expect that the link will bring them to a different article which contains more detail about the linked item. However, they might be surprised if that link brings them to a list of categories or a portal. In contrast, if you are at the bottom of an article and see a navigation template, with a link called "category", or a link called "portal", you would hardly be surprised to be brought to a list of categories or a portal. Invoking the principle of least astonishment, I think most readers would be astonished to find a link to a list of categories or portals embedded in the article content but would not be at all surprised to see that in a navigation template.
  My initial thinking was to simply oppose this proposal and accept the navigation template as shown, but I am persuaded by the comments of Sdkb that wiki project should be handled differently. While I find more value in wikiprojects than I do in portals in general, I note that portals are reader facing while wikiprojects are more oriented for editors so I think our convention of mentioning wikiproject on article talk pages is the better location of such links.--S Philbrick(Talk) 13:12, 10 July 2021 (UTC)
• There is an old RFC about this......that resulted in the removal of Wikiprojects all over.Moxy- 14:24, 10 July 2021 (UTC)
• Given that I imagine all new editors started as readers, I think there is value in trying to let readers know that there is an infrastructure to support those who are interested in specific areas, and thus draw them into the corresponding Wikipedia community. That being said, I'm not sure a link labelled "WikiProject" is a great way to do that. I suspect many will not understand what it means. Perhaps User:MMiller (WMF) on the growth team (for those who are unaware, Wikipedia:Growth Team features has info on current features being developed) can tell us if there has been any investigation in trying to guide new editors, based on the pages they've visited as readers, to find communities of interest? isaacl (talk) 21:26, 10 July 2021 (UTC)
• Oppose we do need a whole-scale re-thinking of navigational boxes; they have a 1990s-web vibe that isn't necessarily correct, though there is certainly some benefit to their current usage. As the status quo, if people pay enough attention to notice a "WikiProject" link, I don't see that as harmful. User:力 (power~enwiki, π, ν) 21:30, 10 July 2021 (UTC)
• Support removal. I definitely can imagine cetain cases where linking to a WikiProject is beneficial for the reader, but that's what the talk page of a template can be useful for; particularly multiple WikiProjects. There are also many projects where a WikiProject is so vaguely broadly, for example the Canada WikiProject listed in this example that it's not super useful, or where it's inactive, which is a negative experience. I do think WikiProjects/Portals need to be rethought, but do not think Navigational templates are it. Shushugah (talk) 16:16, 11 July 2021 (UTC)
• Support removal of links to wikiprojects from nav templates (and more generally from mainspace articles), per nom and the others above. Levivich 19:33, 11 July 2021 (UTC)
• Support. Extra clutter and not worth promoting in article space, although specific WikiProjects that are still active and want it could keep links on major pages as long as it stops being the default. ─ ReconditeRodent « talk · contribs » 01:41, 12 July 2021 (UTC)
• Support removal of WikiProject links per nomination. I don't see any situation where a WikiProject is useful to a reader — they're for editors and should stay on editor-oriented pages. Tol | talk | contribs 04:20, 12 July 2021 (UTC)
• Oppose — This feels like an inobtrusive way to invite readers to become editors. Just as navboxes have V T E: View Talk Edit, and every page has an edit button, categories of content should have a small way to join the editing community. Now, as to what content they land upon at the WikiProject in question, there is much to improve. (For what it's worth, I also feel actively hostile to the MOS-lawyering cited as justification here since we have numerous objects at the footer that are non-articles.)--Carwil (talk) 19:42, 16 July 2021 (UTC)
• Oppose - largely agree with Carwil on this. I wouldn't say WikiProjects aren't reader-facing. Many of them provide useful tools for finding articles, understanding the way articles are written, etc., not to mention providing resources to help newbies orient themselves to thinking about editing in a particular area. That makes it quite different from, say, ANI or the spam blacklist or any one of the other pages that are decidedly not there to welcome new users. That's not to say WikiProjects should always be included either, of course. Base it on whether the WikiProject is at least semi-active and/or whether it has a useful landing page. — Rhododendrites ^talk \\ 21:12, 16 July 2021 (UTC)
• Weak oppose as I generally think we should invite readers to see more of the editing process. Elli (talk | contribs) 00:50, 19 July 2021 (UTC)
• Strong Oppose - these links are an invitational way to get people involved in understanding and editing Wikipedia. Are we going to remove Portal: links as well? Perhaps MOS should be amended to deprecate non-article links in article text (where they would interfere with the intent of creating an informative article on the current subject); while allowing appropriate Wikipedia:Wikiproject and Portal: links in article titles, sidebars, navboxes and other supporting infrastructure, where they encourage users to explore the topic more widely, and perhaps get involved themselves.--Verbarson (talk) 09:06, 19 July 2021 (UTC)
• Oppose per Rhododendrites, isaacl, and the first paragraph of Sphilbrick's comment on MOS:LAYOUT. — Wug·a·po·des​ 19:47, 22 July 2021 (UTC)
• Strong support – Mainspace navigational templates are public-facing and WikiProjects are very much not. It may be useful to be encouraging readers to become more involved in the editing process, but WikiProject links are not an especially useful way of doing that given that most WikiProjects have fallen into disuse. (Reviving WikiProjects may be an advantageous endeavour, but any such efforts will have to start with active editors.) And the inclusion of links that are all-but-useless to 99.9% of users in navigational templates is just poor design. 207.161.86.162 (talk) 23:20, 22 July 2021 (UTC)
• Oppose: for reasons above-stated: this feels like an unobtrusive way to invite readers to become editors. Only the most interested and detail-oriented readers will notice them anyway. Also, a wholesale removal denies the chance of each Navbox to be individually evaluated. In short, the negatives of removal outweigh the positives of non-removal. If anything should be done, would be to refine the Manual of Style. Thank you. Al83tito (talk) 03:06, 24 July 2021 (UTC)
• Strongly Oppose – Per the other users above and also WP:IAR. I think that including these links in the navigational templates are a great way to introduce readers to the relevant WikiProjects and recruit new editors. There is practically no other way for new readers to learn of or find the WikiProjects (outside of a direct interaction with a user who is already a member of the said WikiProject) outside of these links. I think that removing these links will do more harm over the long run than they could ever benefit the project. A lot of WikiProjects are suffering from inactivity and user retention issues, and this would just be another nail in the coffin for those WikiProjects. And if the wording in WP:MOS is an issue, than perhaps that policy page should be modified so that it clearly allows this. We've been doing this for many years with virtually no problem at all, and I see no reason to change tact just because of a strict reading of WP:MOS. Also, WP:IAR exists. If and when a rule prevents us from improving the site, we should disregard it. And modify it, if necessary. LightandDark2000 🌀 (talk) 22:10, 24 July 2021 (UTC)
• Support Project links are a different beast, as highlighted by many above. Wikiproject links should only appear to the casual reader, if ever, on the talk pages. Regards, GenQuest ^"scribble" 14:12, 25 July 2021 (UTC)
• Oppose WikiProjects are useful, both for finding articles about a specific topic and for helping/encouraging new users to edit in that area. I'd also argue they can help established editors find new WikiProjects they might be interested in. Remagoxer ^(talk) 09:04, 28 July 2021 (UTC)
• Support removal of Wikiproject links. They are not reader-facing pages and shouldn't appear in article pages. Reducing Nav-template-clutter even a little is also desirable. Regarding some of the oppose arguments, I agree with the general idea of wanting people to peek-behind-the-curtain and hopefully join us but I don't think wikiproject links are the way. Alsee (talk) 07:54, 31 July 2021 (UTC)
• Oppose I remember first time I found WikiProject Chemistry. Afterwards, I could not find it again. I didn't know about the talk pages (they are hidden for a new user - normally comments are after the article), or the different name spaces and so on... Christian75 (talk) 15:32, 1 August 2021 (UTC)
• This is a good example of WP:IAR usage. Clearly, it's a problem with MOS:LINK, not the navigational templates. It's not like we're linking to WikiProjects so blatantly in the article body (which is what MOS:LINK wants to prevent in spirit, I think). If a reader find those links, it's most likely that they already have the potential to be an editor, not merely staying as a reader. We should help them reach their potential. pandakekok9 (talk) 05:18, 4 August 2021 (UTC)
• Oppose I started reading this, entirely expecting to support. But that link in the template is so nice-looking and non-obtrusive, and it's MILHIST which is actually an active Wikiproject. I think this should be determined on a case by case basis, and to the extent it conflicts with MOS:LINK, MOS:LINK should be changed, not this usage. I would oppose linking to non-active/marginally active wikiprojects. As to how you define that, I don't really know, but that's what localized discussions are for. Calliopejen1 (talk) 22:13, 10 August 2021 (UTC)
• Support removal of WikiProject links, as non-reader facing pages. Per Alsee, and others. Mathglot (talk) 22:00, 14 August 2021 (UTC)

How to propose an amendment to a MOS guideline

Hi comrades. I would like to propose a short addition to a particular paragraph of a MOS guideline, off the back of a discussion about compatibility of practice with that guideline. I've found WP:PROPOSAL, but that seems to deal with really substantial policy/guidance proposals. What is the correct procedure for proposing a small addition to a MOS para? Thanks DBD 12:38, 17 August 2021 (UTC)

Have you raised it at the Talk page for the MoS in question? DonIago (talk) 13:49, 17 August 2021 (UTC)

That's where the prior discussion was happening. Is the correct procedure then just to start a new section? No templates, tags or what-have-you? DBD 16:21, 17 August 2021 (UTC)

It can depend on the magnitude of the amendment and whether other editors feel that any level of escalation is needed (i.e. get consensus for your amendment before editing the MoS), but I've had changes to the MoS be proposed on the Talk page, encounter no or easily-resolved concerns, and then made the edit. Do make sure that even when it appears you have a consensus that you give it a reasonable amount of time (5-7 days is good) before making the actual edits, in case there's any late-breaking worries about them. Hope this is helpful! DonIago (talk) 17:02, 17 August 2021 (UTC)

That's reall helpful. Thanks loads DBD 18:26, 17 August 2021 (UTC)

Tap to display...

The tap to display equations in the math and physics articles is EXTREMELY ANNOYING. it is impossible to read an article without constantly tapping. Just display the damn equations.— Preceding unsigned comment added by 2600:1700:3f7a:66a0:ec58:294e:5e43:7f52 (talk) 14:54, 16 August 2021 (UTC)

This is a problem with MediaWiki on iOS. For now, you can switch to the desktop site. 2600:100F:B125:3055:FDBC:91B8:8484:BD84 (talk) 18:49, 17 August 2021 (UTC)

Add google.com/url to the spam blacklist

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

---

While not technically spam (but neither is youtu.be which is on the global m:Spam blacklist), google.com/url is used mostly for bad image insertion: [9] [10] [11] [12] [13] [14] [15] [16] and occasionally to insert a link wrong: [17] [18] [19]. See search for more. I suggest adding google\.com\/url to MediaWiki:Spam-blacklist to prevent erroneous edits. — Alexis Jazz (talk or ping me) 10:38, 22 August 2021 (UTC)

It makes sense to block any url that can be used to proxy other urls and bypass the regexes in the blacklist. I can't think of any legitimate need to use this. If there is a legitimate need then perhaps someone will enlighten me. HighInBC ^{Need help? Just ask.} 10:42, 22 August 2021 (UTC)

• Support as proposer. — Alexis Jazz (talk or ping me) 11:30, 22 August 2021 (UTC)
• This will need some cleanup of the existing links before it can be implemented, wouldn't it? Jo-Jo Eumerus (talk) 11:45, 22 August 2021 (UTC)

  Jo-Jo Eumerus, that's not really an issue, only added/changed lines are affected by the spam blacklist. So adding this to the blacklist won't stop you from editing articles that already include such a link. Cleanup is needed, but no prerequisite to add google.com/url to the blacklist. — Alexis Jazz (talk or ping me) 12:42, 22 August 2021 (UTC)

So many articles never get processed by maintenance bots in effect a {{nobots}} directive due to the blacklist blocking page saves. IMO causes more damage then prevents, over time. If existing cases were eliminated, then add the blacklist to prevent new, would be best. -- GreenC 14:21, 22 August 2021 (UTC)

• Oppose IMO we need to eliminate the blacklist, not make the blacklisting problem worse by expanding it. North8000 (talk) 13:42, 22 August 2021 (UTC)

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

Foreign-language interface messages

What should we do to all foreign-language interface messages (like MediaWiki:Abusefilter-disallowed/de)? Should we:

• Keep all of the foreign-language messages, or
• Delete all of the foreign-language messages, or
• Keep some, but delete others

This is following up from an MFD where there was consensus to keep the messages but get wider input in the village pump. I have been procrastinating this due to university, but I think it is finally time to debate it. Aasim (talk) 22:53, 18 July 2021 (UTC)

I am going to start by quoting myself: Per Wikipedia:Miscellany_for_deletion/MediaWiki:Noarticletext/es, as an English language Wikipedia, it is entirely pointless to have personalized messages in [foreign languages] as it is expected that those contributing have a decent command of English. In summary: In order to contribute to this project, you need to have enough of a command of English to understand all the English-language system messages and policies that we put there, and translating these messages will probably just encourage non-fluent English speakers to contribute to this project in broken English, rather than contributing to their own language Wikipedia fluently without problems. Aasim (talk) 22:56, 18 July 2021 (UTC)

Also, courtesy ping the users who participated in the MFD: @Pppery @Xaosflux @Zoozaz1 @Godsy @Davey2010 @Kusma @Elli

And the previous MFD: @SmokeyJoe @Robert McClenon @Gioguch Aasim (talk) 23:14, 18 July 2021 (UTC)

Survey (foreign-language interface messages)

• Case-by-case per my comments at Wikipedia:Miscellany for deletion/MediaWiki:Abusefilter-disallowed/de. — xaosflux ^Talk 00:12, 19 July 2021 (UTC)
  • For anyone not wanting to dive in, here is an example: We have a page, MediaWiki:Blockedtext/en-gb that will display to users that set their interface language to en-gb; now we really don't encourage the use of this language here - but if this page were deleted instead of those users seeing our customized message there they would get the mediawiki default. We certainly don't do this for all messages in en => en-gb, but for the most important ones we do. This can also be useful for certain default messages that are displayed to our editors that are using very popular languages such as MediaWiki:Abusefilter-disallowed/de. — xaosflux ^Talk 10:10, 19 July 2021 (UTC)

    @Xaosflux I think you misunderstood what I was asking. I was asking about foreign-language interface messages, not English dialect localizations. That would mean that MediaWiki:Blockedtext/en-gb would not be in the scope of this discussion. Aasim (talk) 02:25, 22 July 2021 (UTC)

    @Awesome Aasim: even so, still case-by-case. There are certainly cases where these could be useless, however the prime sample you opened this discussion with is an example of one that certainly could be useful - as without it our editors with de interface set (for example cross project editors) would not see our localized version - but instead the mediawiki default. — xaosflux ^Talk 09:43, 22 July 2021 (UTC)

• Keep most - these seem more useful to keep around than to delete. Elli (talk | contribs) 00:41, 19 July 2021 (UTC)
• Case-by-case. Way too many interface messages of way too variable quality and usefulness to judge as a group. E.g. The various Copyrightwarning messages which haven't been translated should probably be deleted, as an English message is probably worse than the default translated message in that situation, but the contents messages are fine and have no mediawiki default. 192.76.8.91 (talk) 03:38, 19 July 2021 (UTC)
• Keep most, at least those that are visually integrated in the wiki UI (page headers, footers, sidebars etc) that is otherwise also localized in the user's language of choice. People are entitled to use the Wiki interface in any user language they choose. It's got nothing to do with not being able to use English fluently – I, for instance, have occasionally edited as a guest on numerous other Wikipedias, including my native German one, but I still keep the interface in English in most of them, out of pure habit. If we have enwp-specific strings that are meant to be integrated in this localizable UI, then it's only proper to also have these strings localized. Of course we can't commit to keeping everything translated into every language Mediawiki supports, and we shouldn't bend over backwards trying to achieve that, but if we already have those translations, what harm does it do to keep them and thereby maintain better user experience for some visitors? I'm less convinced about those that are meant to be displayed as part of metadata inside articles, for example all those "cite error" components. Fut.Perf. ☼ 10:40, 19 July 2021 (UTC)
• Keep all as a default, being in a foreign language is generally a reason to keep them. (Lots of reasons for people who don't read English well to participate here). Use MFD to discuss individual pages that are problematic for reasons other than being interface messages in a foreign language. —Kusma (talk) 10:49, 19 July 2021 (UTC)
• Keep all by default, without prejudice to individual discussions at MfD if any are problematic for a specific other reason. Simply being in a foreign language is not a reason in and of itself for deletion. Thryduulf (talk) 11:09, 20 July 2021 (UTC)
• Keep all – Wikipedia, or rather, English Wikipedia, is part of a larger community of projects under the Wikimedia umbrella that includes over 300 other Wikipedias, not to mention other sister projects. Wikipedia:Wikimedia sister projects has this to say:

  Wikipedia encourages links from Wikipedia articles to pages on sister projects when such links are likely to be useful to our readers, and interlingual crosslinking to articles on foreign-language editions of Wikipedia whenever such links are possible.

In addition, the Welcoming committee also has tools available to address new users in their own language, when their English isn't up to snuff for contributing here; here's a list. While neither of these cases is quite the same as this one, nevertheless it's clear that English Wikipedia intends to be welcoming to speakers of other languages under various circumstances, and in that spirit, this case should be no exception. Mathglot (talk) 01:11, 22 July 2021 (UTC)

• Keep all unless there's specific cause to delete. I have occasionally had reason to visit foreign-language wikis. There are a variety of kinds of valuable edits that do not require knowledge of the local language. It's helpful if as much of the interface as possible remains readable. Alsee (talk) 08:02, 31 July 2021 (UTC)
• Keep all unless they have a specific problem. As detailed below by Whatamidoing, if we delete the messages then users with that interface language will usually not see an English message, they will see the MediaWiki default for their language. MediaWiki:Abusefilter-disallowed/de links to Wikipedia:Edit filter/False positives like our customized English version MediaWiki:Abusefilter-disallowed. If we delete it then users with German interface will see translatewiki:MediaWiki:Abusefilter-disallowed/de, a German translation of translatewiki:MediaWiki:Abusefilter-disallowed which tells the user to contact an administrator. We don't want the user to do that. Default MediaWiki messages are written for all MediaWiki installations so they don't link local wiki pages and don't mention local policies and features. We should translate more of our important customizations to common languages, not delete the existing translations. PrimeHunter (talk) 22:27, 31 July 2021 (UTC)

Background (foreign language interface messages)

For anyone who doesn't know what's being talked about:

All the little pieces of text in the user interface (i.e., not the articles, but things like words on a button) are called "system messages". They are almost always written in English originally, put into the MediaWiki software code, and then translated at a separate website, TranslateWiki.net.

For example, when you make an edit, there's big blue button for saving your changes. You're probably used to seeing the button say "Publish changes". The button's text is stored in a MediaWiki message called MediaWiki:Publishchanges. If you have your language preference set to English in Special:Preferences, then you will see "Publish changes". If you have your language preference set to something else, then you will see the translation (from TranslateWiki.net) for that language. Fun trick: For your account, it says Publish changes. (That trick shows a different version to each reader. For nearly all of us, that sentence will be English. If you want to see what another language looks like, then click here to see this page in Russian or here to see this page in Japanese.)

That's the normal system. Now let's talk about customizing it for all editors at this wiki.

Imagine that you're the largest wiki in this history of the world, and you think that the generic wording somewhere should be different. You probably don't want to touch MediaWiki:Publishchanges, because Here There be Lawyers (seriously – they care about that button) and you definitely don't want to change the copyright notices, but you might very well want to change some messages, such as the text displayed when you visit a non-existent page, or (since our documentation is more extensive than average), you might want to add a link to a help page that exists at this wiki but not at any others. You've thought it through, and your change isn't a general improvement that would help everyone, so you only want to change it here at the English Wikipedia, for all users of this one wiki. That's do-able, if you have the necessary user rights. You edit the MediaWiki system message page to contain your new text (in HTML, not wikitext). This local message page will override the normal text.

Now here's the problem – and why those pages translated exist: You've replaced the message in English. But there are almost 300 other languages that people might have set their preferences to, and none of them see your new custom message, because you've only written the English one. For example, MediaWiki:Noarticletext looks like this in various languages:

Comparison of MediaWiki:Noarticletext

MediaWiki default	There is currently no text in this page. You can search for this page title in other pages, search the related logs, or create this page.
English
British English	There is currently no text in this page. You can search for this page title in other pages, search the related logs, or create this page.
Spanish	En este momento no hay texto en esta página. Puedes buscar el título de esta página en otras páginas, buscar en los registros relacionados, o crear esta página.
German	Diese Seite enthält momentan noch keinen Text. Du kannst sie erstellen, ihren Titel auf anderen Seiten suchen oder die zugehörigen Logbücher betrachten.
French	Il n’y a pour l’instant aucun texte sur cette page. Vous pouvez lancer une recherche sur ce titre dans les autres pages, rechercher dans les opérations liées ou créer cette page.

You can see that we have customized the English version, but all of the others are showing the MediaWiki default, translated into that language. If you want the custom version showing even for people who have set their UI to a different language, then we'd (re-)create MediaWiki:Noarticletext/es, MediaWiki:Noarticletext/de, MediaWiki:Noarticletext/fr, etc., with the text that we wanted them to see. The question in this RFC is: Do we want to keep those translations of custom pages?

BTW, if you are fluent in more than one language, and you'd like to help with translations, please contact me. I can help you get started. Whatamidoing (WMF) (talk) 21:46, 19 July 2021 (UTC)

@Whatamidoing (WMF): (will have to look up the many phab tickets) but its been argued (by me and others) that what should be fixed for a subset of this problem is the variant fallback behavior (i.e. If MediaWiki:Foo has been initiated, and the variant hasn't been initiated, then show the base language. So if Mediawiki:Foo exists and MediaWiki:Foo/en-CA doesn't, but someone has en-CA set - show them the base on an en project instead off falling back to the mediawiki default). As far as the other problems, see my note above about how it is useful to have a local version of certain pages such as the abusefilter reject message in popular languages that x-wiki editors may be coming from. The question above isn't about is any specific one of these good or not though, it is asking if the community wants to nuke ALL of them without further consideration, which I think is a very bad idea. — xaosflux ^Talk 21:55, 19 July 2021 (UTC)

While publishing an actual "translation" of something missing such as MediaWiki:Publishchanges is certainly a good idea, it is not the solution for a page like MediaWiki:Abusefilter-disallowed which augments the default with styling. (An entirely new solution for that with variables and classes COULD work but that is well beyond the scope of this discussion). — xaosflux ^Talk 22:00, 19 July 2021 (UTC)

I have no opinion about whether the existing pages should be deleted, or whether more should be created. My main opinion is that if you can't figure out what a system message actually is, it'll be difficult to form an opinion about anything else.

There was some work done a year or two ago about "circular" fallback languages – pt vs pt-br is a primary example. I'm not sure that it gets applied in this situation, however. In the en-ca/en-gb examples, however, it might probably be faster to make a list of customized messages and transclude the custom version into the "translated" page name. Whatamidoing (WMF) (talk) 03:45, 20 July 2021 (UTC)

We've done that on the more "important" local messages like MediaWiki:Blockedtext/en-gb, though it is a kludgy hack and has challenges with passing the variables. — xaosflux ^Talk 09:53, 20 July 2021 (UTC)

@Xaosflux: we can do this with a local bot, right? Say for any MediaWiki: customisations, have a bot create all the en-* pages to transclude the main one. ProcrastinatingReader (talk) 00:17, 28 July 2021 (UTC)

@ProcrastinatingReader: well, it would have to be an admin bot, and some require parameters to be handled in unusual ways preventing normal transclusion. It would be much better to fix the language variant fallback tree upstream (thus also fixing it for everyone that uses mediawiki). — xaosflux ^Talk 00:29, 28 July 2021 (UTC)

@Xaosflux: I'm happy to write up the bot if some admin is willing to run it. It'd be better in the software, of course, but probably better have some fix for it than have it be bugged. We could always delete them in the future if an upstream fix ever happens. Do you know what phab task this is BTW? ProcrastinatingReader (talk) 10:11, 28 July 2021 (UTC)

@ProcrastinatingReader: it certainly isn't as simple as adding a transclusion on every MediaWiki:Foo/en-gb of MediaWiki:Foo - like I mentioned anything everything with parameters may need to be handled in a different way. phab:T229992, phab:T162008, and possibly others outline the problem. Ideally at least an option should be available to define a local fallback scheme such that uninitiated messages in certain languages (esp language variants) can fallback to a specified language (e.g. en-gb --> en) instead of to mediawiki default. — xaosflux ^Talk 14:46, 28 July 2021 (UTC)

+1 @Whatamidoing (WMF). Thanks for giving clarity for what I am proposing. Aasim (talk) 17:52, 20 July 2021 (UTC)

MediaWiki Tidy

Similar to HTML Tidy, a bot or tool to improve the layout and indent style of markup. .... 0mtwb9gd5wx (talk) 04:01, 17 August 2021 (UTC)

@0mtwb9gd5wx: I'm not sure what you're asking here - could you give a few more details on what you are proposing? Mediawiki already included a HTML cleaner that fixes a lot of invalid markup, and anything that the parser can't fix automatically is tagged by the wp:linter for wikignomes to fix up. If you're referring to edits that make no changes to the rendered HTML of a page but make the wikitext look nicer - that is called Wp:Cosmetic editing and bots that exclusively make them are expressly forbidden per WP:COSMETICBOT. 192.76.8.74 (talk) 04:26, 17 August 2021 (UTC)

@192.76.8.74: Like pretty printing for programming languages, there could be a tool that receives MediaWiki markup and formats it via standard rules, as a server-side tool, to present, to the editor, an alternative to browser-heavy syntax highlighting, similar to https://refill.toolforge.org/ or https://refill.toolforge.org/ng/ . .... 0mtwb9gd5wx (talk) 04:52, 17 August 2021 (UTC)

unfortunately there isn't really such a tool possible, as whitespace is very important in wikicode (unlike in most other programming languages). There is a syntax highlighter tool available in the editor though; the , left of "Advanced" in some toolbars (not the pencil icon on the far right). If "New wikitext mode" or "Automatically enable all new beta features" is enabled at Special:Preferences#mw-prefsection-betafeatures then it is available on the menu icon . —TheDJ (talk • contribs) 08:11, 17 August 2021 (UTC)

@TheDJ:@192.76.8.74:Actually, some pretty formatting is possible, such as:
<ref name="N">NEWLINE{{cite web |last1=L |first1=F |title=T |url=U |website=W |access-date=D}}NEWLINE</ref>
and naming refs then putting cites between refbegin and refend. .... 0mtwb9gd5wx (talk) 00:36, 24 August 2021 (UTC)

TFD proposal - condensing political party templates

There is a discussion at WP:TFD regarding the merging of some 16000 political party templates into one meta module. Your input would be appreciated. Primefac (talk) 11:38, 26 August 2021 (UTC)

{{usstat|80|92}}

goes to:

• https://uslaw.link/citation/stat/80/92

and mentions:

• https://www.govtrack.us/congress/bills/89/hr8030

it needs to also point to:

• https://www.congress.gov/bill/89th-congress/house-bill/8030

also, is there a template for congress bills ?

{{uscongress bill|house|89|8030}}

.... 0mtwb9gd5wx (talk) 04:45, 27 August 2021 (UTC)

Template_talk:USStat may be the correct venue for this request. Template:USBill may be the template you seek. Folly Mox (talk) 05:54, 27 August 2021 (UTC)

Add Albanian Wikipedia to the bottom of English Wikipedia page - section 50.000+ articled

Moved to Talk:Main Page § Add Albanian Wikipedia to the bottom of English Wikipedia page - section 50.000 articled

 –  ― Qwerfjkltalk 15:16, 28 August 2021 (UTC)

Proposal: Split the biographies from the main vital articles

The biographies are in 3 levels. I think it would be beneficial to split them off into their own list with 5 levels rather than the current list. If you oppose this, I would like to know your thoughts on adding in-between levels such as level 3.5 or level 4.5. I look forward to your comments. Interstellarity (talk) 14:56, 27 August 2021 (UTC)

Please see the previous discussion on the vital articles talk page here. One editor suggested opening up the discussion here for greater visibility. Interstellarity (talk) 15:01, 27 August 2021 (UTC)

• Oppose for the same reasons I and others opposed at the previous discussion. The Vital Articles lists are hard enough to maintain at their present size without expanding them further, and I've seen no justification for this other than as a way to create more room in (i.e. expand) the sets. {{u|Sdkb}} ^talk 16:36, 27 August 2021 (UTC)
• Oppose. As I see it, the main purpose of WP:VA is to identify sets of 100, 1000 and 10,000 articles which are considered the most important, to help endeavours like WP:The Core Contest, classify the quality of our most important articles, and also to give editors a hand in choosing which articles to prioritize for work. None of that benefits from splitting the list into people and non-people though. Rather, it just creates inconsistency with editors having to check both lists, with perhaps lower participation by those selecting the articles. Note that Wikipedia is not split along these lines in any other area - we don't have Featured articles / Featured people, or Articles for deletion / People for deletion. Finally, to address some specific points:
  • I can see the argument that biographies and non-biographies are hard to compare with each other as to which is more important, the same goes for any other diverse categories. Evaluating which of Jupiter, World War II, Clothing and Christianity is the most "vital" is almost meaningless, but the VA project still lumps them together.
  • It's been said that an advantage is the freeing up of 127 new slots for articles at level 3, but that's not something I think we want. Per Sdkb the lists are intentionally kept at specific levels, and if the 1000 level 3s are not enough then either look at level 4, or get consensus to expand it to 1200.
  • As for needing to classify people into 5 separate levels, I again don't see the need or rationale for that. Looking at Wikipedia:Vital articles/Level/5/People/Writers and journalists, I already don't know who the majority of those are, and I think they rightly represent the lower bound of vitality. Yes, they're important people, but anyone below that shouldn't be classified as such IMHO, and the exercise becomes increasingly unwieldy and arbitrary too. A desire to add a level 6 probably exists in other areas too, but I'd oppose that for similar reasons.
  • In summary, I think the VA process has worked well down the years, and this large-scale split down the middle wouldn't be beneficial. Cheers  — Amakuru (talk) 08:07, 28 August 2021 (UTC)
• Comment: I am neutral on this, but the project pages should be placed under Wikipedia:WikiProject Vital Articles if it is needed to get rid of unnecessary essay templates. They are unintentionally undermining, they don't encourage to edit pages when the opposite is needed. Interstellarity's project has already been useful. Currently Level 5 needs more development and alternative listing would be useful in finding the most vital biographies and for example listing them alphabetically. --Thi (talk) 15:42, 28 August 2021 (UTC)

Gender used in messages is biased in preferences (copied from Village Pump (Technical))

Copied this over from Village Pump (Technical) because it was posted to the wrong place. I want to get community consensus on this here to send it to Phabricator...

In the preferences settings under the first tab named "User Profile" there is a section about: Gender used in messages, where a user can specify to be addressed by gender neutral, feminine, or masculine pronouns, and when another user hovers over the username the chosen pronouns will be displayed as he/him or she/her along with the user rights and other user groups of the user as well as their edit count and some other basic information about the user.

However, there is a technical issue with this feature that makes the preference appear to be biased in nature where the feature appears as if it doesn't work at all if a user chooses that they wish to remain gender neutral because if this option is chosen there is simply nothing at all displayed when you hover over the username, and there should be at least something such as they/them to indicate the user has made the choice and the feature is working.

I propose we add they/them to the feature to avoid the appearance that the preference is biased against people who choose to remain gender neutral, and to ensure that all editors will have a way of knowing the feature actually works. Huggums537 (talk) 19:03, 30 July 2021 (UTC)

[I need to make an amendment to this proposal to avoid any confusion on what it is about. I first brought it to Village Pump (Technical) because this is mostly about the feature technically not functioning properly where it will not display the choice of the user if they choose "Gender unspecified". This is not so much about the bias against they/them pronouns, but I thought I might throw that in there because it also incidentally appears to look that way. However, my main concern is the functionality, which can easily be solved with a simple text modification.

Therefore, I amend my proposal to modify the text as suggested by King of Hearts and Trappist the Monk in the manner described by Writ Keeper so that it shall say, "Gender unspecified" or "Unspecified gender" on the popup.]

As for they/them, y'all can debate about whether or not that makes it in until the cows come home for all I care. Huggums537 (talk) 21:36, 30 July 2021 (UTC)

• Agreed, there should be a fourth option. We shouldn't force "they/them" pronouns on people who simply haven't made a choice, so we need to distinguish between actively neutral vs. passively neutral. -- King of ♥ ♦ ♣ ♠ 19:27, 30 July 2021 (UTC)
• By when another user hovers over the username the chosen pronouns will be displayed as he/him or she/her along with the user rights and other user groups of the user as well as their edit count and some other basic information about the user, I assume you're talking about Navigation Popups? That's a locally-maintained gadget, not a piece of the Mediawiki interface, and so changes to it would not go through Phabricator; instead, an intadmin would need to make the requisite changes at MediaWiki:Gadget-popups.js (specifically, line 4185, where an option other than he/him or she/her would need to be added, and line 7276, where a corresponding l10n string would need to be added. KoH's suggestion of an explicit difference between "they/them" and "unspecified" is a different matter, of course, but that would be neither sufficient nor necessary to add they/them support to NavPopups; changes to the script would still need to be made regardless of whether such a Phab ticket were filed. Writ Keeper ⚇♔ 19:35, 30 July 2021 (UTC)

  Writ Keeper, I think this sounds correct. So, the changes under the new proposal would simply be to add "Gender unspecified" to the navigational popup so that it matches the current choices already being offered in the preferences and will show up in the popup the same as the other two choices. Huggums537 (talk) 23:18, 30 July 2021 (UTC)

• (edit conflict) I don't know what you mean by when another user hovers over the username the chosen pronouns will be displayed as he/him or she/her along with the user rights and other user groups of the user as well as their edit count and some other basic information about the user. I've never experienced that. I'm not really sure that I want to.

  Regardless, I don't particularly want to be addressed with they/them/their because there is (thankfully) only one of me. Alas, the default radio button 'Unspecified' doesn't really mean 'Unspecified'. So, for me the fix is to do as you say for those who prefer singular plural pronouns to select that and make 'Unspecified' really be 'Unspecified'. Or, better, dispose of the options altogether and stop the attempt to put us all into neat little boxes.

  —Trappist the monk (talk) 19:40, 30 July 2021 (UTC)

  Sounds like the Wikipedia:Tools/Navigation popups extension. For you it's unspecified. A lot of people would refer to you as "they" by default, consequently, unless there are better pronouns to use for a person whose gender is unspecified/unknown(?) ProcrastinatingReader (talk) 20:02, 30 July 2021 (UTC)

  Trappist the monk, I don't want to put anyone into "neat little boxes", but I do want to give everyone the options to choose, not dispose of them. So, that is why I support the idea King of Hearts has suggested about adding a fourth option to distinguish between active or passively neutral, and the way that could be accomplished is by integrating your idea of adding an option of "unspecified gender" right along with they/them, he/him, and she/her. That way a user has complete choice over how they wish to be addressed. Huggums537 (talk) 20:57, 30 July 2021 (UTC)

  Trappist says she prefers not to be referred to as they and also doesn't want to specify any pronouns; that's cool. I won't refer to her as they.

  Without those neat little boxes, we end up with a default setting. That default setting has on the internet often been he/him. Allowing us to place ourselves into those neat little boxes means I don't get (too often) called he/him, which over the decades has become quite tiresome. The default setting moving toward singular they is IMO quite productive, but for those who both reject they and refuse to specify, each of us should feel free to come up with her own default setting. :) —valereee (talk) 13:46, 3 August 2021 (UTC)

• See MediaWiki talk:Yourgender § July 2021 follow up from UTJW for discussion on the idea of the MediaWiki software having an option for users to specify that they do not wish to be addressed by a pronoun. ("Unspecified" was added to the text in the user preference setting based on the discussion.) There is a related Phabricator ticket. isaacl (talk) 20:26, 30 July 2021 (UTC)

  Isaacl, except that "unspecified gender" does not appear when you hover over the username. As I mentioned before, it is just blank and shows nothing giving the appearance that it does not work for users who have decided to choose this option. At the very least, the text should be altered to say, "Unspecified gender" the way Writ Keeper has suggested. That way it will still be in compliance with the previous discussion while solving part of the problem as well. Huggums537 (talk) 21:03, 30 July 2021 (UTC)

  Yes, I read your original post regarding what is presumably displayed by the navigation popups extension (perhaps you could confirm this). isaacl (talk) 21:24, 30 July 2021 (UTC)

  Isaacl, sure, when I choose he/him or she/her my choice appears in the popup, but when I choose "Unspecified" nothing at all appears.... Huggums537 (talk) 21:44, 30 July 2021 (UTC)

  So you're confirming that the popup in question is being displayed by the navigation popups gadget that you have enabled? isaacl (talk) 21:59, 30 July 2021 (UTC)

  I'm only confirming the popup doesn't display all the options. I will try to verify which tool is producing the popup if I can, but I figured experienced editors around here would already know which one produces the information when you hover over a username, and Writ Keeper suggested it was the navigation extension and that sounds correct to me because I looked at the code and it has related information in it... Huggums537 (talk) 23:30, 30 July 2021 (UTC)

  Isaacl, Ok, I think I have confirmed it is the navbox gadget. Huggums537 (talk) 08:40, 31 July 2021 (UTC)

• they…This user considers singular they standard, modern, informal English usage, so avoids it on Wikipedia.
  ―Qwerfjkltalk 20:35, 30 July 2021 (UTC)

• How does this same thing keep going in circles?? The literal options for this value are already: unspecified, male, female. This is a language setting, and is part of software used globally - including in languages that only use gendered nouns (e.g. Userio vs Useria for "User"). This proposal is very vague and seems to be the XY problem - are you really trying to change the mediawiki software, or do you really want someone to just recode the local gadget? — xaosflux ^Talk 22:51, 30 July 2021 (UTC)

  Xaosflux, This is actually a simple and uncontroversial edit I'm proposing with no changes to the existing values in the mediawiki software. All I'm asking for is that when a user chooses "Unspecified" for gender neutral preferences that something will show up in the popup to indicate they have made that choice the same way it pops up he/him or she/her if someone chooses the male or female preferences. Currently, nothing at all shows up in the popup for "Unspecified". However, we could add two little words that say, "Gender unspecified" into the popup and that would at least show something that indicates a user has made that choice. It's not that complicated. Huggums537 (talk) 23:08, 30 July 2021 (UTC)

Unspecified is the default at Special:Preferences. If a user has never touched or looked at their preferences then Unspecified is marked. There is currently no way to tell whether a user has deliberately chosen Unspecified or never done anything. The popup is only seen by registered users who have enabled "Navigation popups" at Special:Preferences#mw-prefsection-gadgets, a script made at the English Wikipedia by the editors. It's disabled by default and cannot be used by unregistered users. It would be possible for popups to say "Gender unspecified" instead of saying nothing, but popups has no way of knowing whether the user chose that or never chose anything. That would require a change in the MediaWiki software. PrimeHunter (talk) 23:28, 30 July 2021 (UTC)

PrimeHunter, But why does it have to matter to anyone else if a user chose the option or it was defaulted to them in order for the option to be displayed like the others? Huggums537 (talk) 23:36, 30 July 2021 (UTC)

Why does it have to matter that someone chose masculine or feminine pronouns? — Wug·a·po·des​ 00:45, 31 July 2021 (UTC)

Wugapodes, Don't ask me why it matters, ask whoever decided to inform everyone else of these pronouns with the popup information, but also decided to withhold the information about the non-use of any pronouns no matter if it was decided by default or not... Huggums537 (talk) 02:42, 31 July 2021 (UTC)

My point being that you're fine with respecting the choice of those who choose a non-default option, but seem to not care about those who chose the neutral option. You may not care, but others do. — Wug·a·po·des​ 02:56, 31 July 2021 (UTC)

Wugapodes, these assumptions of what I do or do not care about are, and should be irrelevant to the discussion because what I care about has no effect whatsoever on the simple insertion of plain "Unspecified gender" text, and the text itself does not care one way or the other either, nor does the insertion of the text imply about any caring one way or the other since the text itself applies to both options so your point about what I do or do not care about seems rather moot. Huggums537 (talk) 03:48, 31 July 2021 (UTC)

To be clear, "neutral" meaning that some people don't want the system referring to them with gendered language at all. You haven't explained how being told something is unspecified is helpful compared to just not specifying it. — Wug·a·po·des​ 03:01, 31 July 2021 (UTC)

Wugapodes, I've explained repeatedly in great detail that the plain and simple advantage of the proposal is making it visible so others can see it. If the helpfulness of that over just leaving it invisible like an unwritten law or unspoken rule isn't obvious, then I don't know what to tell ya. Huggums537 (talk) 03:56, 31 July 2021 (UTC)

A better response here would have been that it doesn't matter if someone chooses male or female because the pronouns get displayed either way, and it should be the same with "gender unspecified" that it doesn't matter if someone chooses it, or the default chooses because the same chosen option gets displayed either way. Huggums537 (talk) 11:55, 7 August 2021 (UTC)

No changes need to be made to the Mediawiki software if you disregard the idealism that somebody needs to know if the user made the choice or it was defaulted to them. You said the navigation popups would have no way of knowing, but I think the navigation popups would be the very least concerned about needing to know that so it would be no problem to just add "Unspecified gender" to the display and it will show up either way whether a user chooses it, or it gets defaulted to them. Simple. Easy. Huggums537 (talk) 23:54, 30 July 2021 (UTC)

• It keeps going in circles because a tool is misusing grammatical gender to infer personal gender which are different despite their overlap (see Grammatical gender#Grammatical vs. natural gender). The software setting is designed to serve a specific purpose in internationalizing system interface messages, but we use it on EnWiki as a stand-in for the particular gender someone chooses to perform. This leads to repeated conflict when our cultural beliefs about personal gender don't line up with how the rest of the world's languages use noun classes. Unless MediaWiki or the gadget distinguish personal gender from grammatical gender, I would expect these discussions to continue going around in circles. (edit conflict) — Wug·a·po·des​ 23:18, 30 July 2021 (UTC)

  Wugapodes, None of that makes any difference here since the proposal doesn't affect any changes to the international software. It only affects the local English Wikipedia Navigational popup so that the popup matches what the international software already says, and becomes visible to other users. It keeps going in circles because people keep seeing problems with this, and they aren't getting solved correctly. Huggums537 (talk) 07:45, 31 July 2021 (UTC)

  Correct, this is why it should be removed, as its usage is incorrect. If people want to identify (gender or pronouns) somehow, they can write that on their talk page, we should not infer it from information we use for grammatical gender in the software language. —TheDJ (talk • contribs) 16:50, 31 July 2021 (UTC)

  TheDJ, yeah just removing it alltogether if you can't please everyone is a novel solution, but then it deprives everyone of the feature. With this host of brilliant minds we have among us, surely we could come up with something to display that would be acceptable to everyone? I'll take any suggestions at this point. Surely there must be someone here with a better idea than mine for the display popup? Huggums537 (talk) 19:28, 31 July 2021 (UTC)

  No we wil not come up with something acceptable to all. This is the internet. Therefor, less is more. —TheDJ (talk • contribs) 07:26, 1 August 2021 (UTC)

• I swear. People on this site are way too freaked out about gender issues man. There really should be no big deal about simply letting other people know that a gender hasn't been specified... Huggums537 (talk) 00:06, 31 July 2021 (UTC)
  • Some people do specify a gender, choosing the neuter. Ignoring people who try to explain that isn't going to build consensus. If you want to be pedantic, the lack of a "he" or "she" is a way of letting you know that a gender hasn't been specified because it's not specified. It's not ambiguous, and changing it will just annoy a different group of people. Pretending this is simple won't make it so. — Wug·a·po·des​ 00:45, 31 July 2021 (UTC)

    Wugapodes, adding the text "Gender unspecified" to the popup is not ambiguous either, and it isn't changing anything. It's only as simple as making the choice visible to others. The argument that not making the choice visible to others is your invisible sign that they have made the choice would be a great one if people could see invisible signs, but pretending people can see invisible signs won't make it so. Huggums537 (talk) 03:21, 31 July 2021 (UTC)

• For context, there was discussion on what text to display instead of the previously-used icons in phab:T284783, "NavPopups should not use ♂♀ icons to describe how one wants to be addressed". isaacl (talk) 04:40, 31 July 2021 (UTC)

  Isaacl, I think graphical icons representing gender are irrelevant to a discussion about adding text with an unspecified gender. Also, adding "Gender unspecified" was a new idea never even talked about in that discussion. I have struck adding they/them from the proposal, and that is the only relevance I can see there might have been from that discussion, so I see no real context there. Huggums537 (talk) 07:09, 31 July 2021 (UTC)

  In addition, I would just like to note that I wish I would have been able to participate in these other discussions because I darn sure would have mentioned something to these proponents of the idea that gender matters in other languages, and we need to take that into account when considering our software/language/gender etc. decisions. My message to them would be a very simple one; "This is English Wikipedia, not X-language Wikipedia". Perhaps nobody else thought of that answer in previous discussions. I didn't go through them in great detail, but glanced over it enough to get the idea that people were making a fuss about how gender is approached in other languages such as Spanish. 07:25, 31 July 2021 (UTC)

  The discussion touched on why nothing is displayed when the "unspecified" option is selected in the user preferences, thus I provided a link for anyone interested in the context. The navigation popups gadget is deployed on other language Wikipedia and thus must be able to accommodate their requirements as well. isaacl (talk) 14:26, 31 July 2021 (UTC)

  Ok, I guess that's fair enough context. However, I seem to be getting conflicting information about the nav popup gadget since other users have implied it's a tool local to the English Wikipedia only, suggesting it's use is different from the Mediawiki software where the preferences are used internationally. Huggums537 (talk) 16:58, 31 July 2021 (UTC)

• According to Wikipedia:Database reports/User preferences#Gender (two years old), 98% of registered users have not specified gender. I assume it's lower for active users but the vast majority of unspecified are not real-life gender-neutral people but just users who haven't seen the option (it didn't always exist) or don't see a good reason to specify their gender. I don't think popups should use space on that, and I think many popups users do realize that if no gender info is shown then it's because the user hasn't given it. Displaying "Gender unspecified" may make users worry about whether they ought to specify their gender when they don't want to. I support just continuing to say nothing when nothing is specified. PrimeHunter (talk) 09:51, 31 July 2021 (UTC)

  PrimeHunter, sure, to some negative nelly it might make users worry, but positive polly tells me there is every bit as good of a chance that the display may make users more aware that they have the option, and they very well may be more grateful that they have been shown they can now choose if they want to. I also think there are more than plenty enough users who don't realize that if they choose "gender unspecified" it will show nothing [there is any meaning at all behind nothing being shown] so enabling visibility is well worth it. Huggums537 (talk) 11:17, 31 July 2021 (UTC)

  @Huggums537: Or maybe they'll feel compelled to leave it blank but now be unable to? If they object to having "they/them" next to their name, the only thing they can do is change to "he/him" or "she/her". Gone is the option to blank it. That's a problem. Convince the devs to add a fourth gender preference and then maybe something can be done here. As is, this is unworkable. ProcrastinatingReader (talk) 12:26, 31 July 2021 (UTC)

  ProcrastinatingReader, I *think* you are describing a problem that already pre-exists and trying to ascribe it to my proposal because users who might object to having they/them next to their name already have no other choice but to change to he/him or she/her if they want something different. Adding "Gender unspecified" to the popup display does not affect that, it only puts on display what currently already exists. Perhaps it's not my proposal that's unworkable, but the underlying preferences my proposal would represent that's unworkable. Huggums537 (talk) 13:27, 31 July 2021 (UTC)

  From my perspective, I only came here to perform the ordinary task of enabling the display of simple user information, but I an not able to go ahead and do so because those who came before me already implemented the unworkable system that doesn't seem to allow that to happen. Huggums537 (talk) 20:02, 31 July 2021 (UTC)

• Comment I think others from previous relevant conversations would benefit from being pinged to this discussion. Especially those that were specific to this exact particular topic such as [20] where a user brought up the exact same issue on Jimbo Wales talk page, and several users responded there including; Cullen328, Indy beetle, Sdkb, TheDJ, Floquenbeam (noping set), RGloucester, valereee, Khajidha, and Xaosflux. The other most pertinent conversation was: MediaWiki_talk:Yourgender#July_2021_follow_up_from_UTJW, where the only real new contributors were Whatamidoing (WMF) and SandyGeorgia. Both of these conversations focus on pretty much the same issue, and I think this is a good place to get it resolved now. If it says, "Gender unspecified" in the popup, then it would simply be an exact match to what we have already decided would be there in the preferences. The only difference is that it would now be visible to others, and I think this more transparent approach is much better. What are we hiding anyway? Huggums537 (talk) 11:09, 31 July 2021 (UTC)
• Maybe I'm missing something, but the options here are 1) display "they/them" in pop-up, encouraging others to refer to the person as they/them; 2) display nothing in the pop-up, encouraging others to refer to the person as they/them, because that is the normal thing to do for most English speakers. It feels like we're being asked whether to print "This page intentionally left blank" or just leave the page blank. – Joe (talk) 11:33, 31 July 2021 (UTC)

  Joe Roe, those are the same old tired options of yesterday. There is a brand new brilliant option out now that is the wave of the future! Add "Gender unspecified" to the popup display. Huggums537 (talk) 11:59, 31 July 2021 (UTC)

  Ah, I did miss something then. In that case, that falls afoul of a very good point made in phab:T284783: someone's gender does not equal how they want to be referred to. That's why the popup now has the pronouns directly, rather than an indication of personal gender. If somebody indicates that they want to be referred to as they, that doesn't mean that their gender is unspecified. Silence really seems to say more than words here. Or another option could be to let people customise what is included in the popup? – Joe (talk) 12:08, 31 July 2021 (UTC)

  You didn't miss anything. I was just tryna be funny. Silence really seems to say more than words here. Adding "Gender unspecified" doesn't "say" anything less than silence currently does. In fact, it says more because it informs other users of information that many were not aware of before. The point about whether somebody wants to be referred to as they or not is moot in this case because that has already been decided for us by default. All we are trying to determine in this discussion is if we want to display that decision or not. It's really that simple. If we stand by our decision, then we should have no problem putting that decision on display. Huggums537 (talk) 13:01, 31 July 2021 (UTC)

• Whether one wants the software to refer to them by gendered pronouns or not, that choice could not, and would not mean one wants the software to publicly refer to them by the phrase 'unspecified gender', 'unspecified gender' is not a pronoun, and 'unspecified gender' is not a public statement they are being asked to make, however vague and ambiguous that would be, they are only being asked if they want a gendered public pronoun in communications. -- Alanscottwalker (talk) 15:30, 31 July 2021 (UTC)

  Alanscottwalker, whatever one chooses the software to "refer" to them as when they are asked to pick a username could not, and would not mean one wants the software to publicly refer to them by the phrase, "User". "User" is also not a public statement they are being asked to make either. Yet, "User" appears twice in the nav popup and many other places across Wikipedia (very prominently on a userpage) because it is simple descriptive data used to convey information. So it is with adding "Gender unspecified". This idea that anyone is somehow being "referred" to something against their will is just ridiculous. Nobody is bitching about being "referred" to as "User" against their will, and rightfully so. It's getting way out hand. Huggums537 (talk) 17:50, 31 July 2021 (UTC)

  They are a User. That's the word for anyone who uses a website. If anything, this proposal is what's ridiculous, and no need to bitch, at all. Alanscottwalker (talk) 19:33, 31 July 2021 (UTC)

  Alanscottwalker, some really strange and far out weirdos might argue with you that they aren't a "User" at all. They might say they don't "use" anyone, and it offends them to be "referred" to as a "User". Just think about that for a moment because it's essentially the same strange argument that says one doesn't want to be "referred" to as "Gender Unspecified". Yet, "Gender unspecified" is just words to describe anyone who has that option enabled just as "User" is just a word to describe anyone who uses a website. So, hopefully you can see what I'm talking about when I say that kind of argument is "ridiculous". Huggums537 (talk) 20:41, 31 July 2021 (UTC)

  Unconvincing -- one seems intentionally or inevitably unlikely to arrive at anything like hope, through a comment that begins with what looks like trolling or baiting, followed by irrelevant other stuff exists, and mangling of referent with respect to pronouns. -- Alanscottwalker (talk) 12:55, 1 August 2021 (UTC)

  Alanscottwalker, I've participated very heavily in this thread, interacting with at least 95% of the participants, and nobody else has complained or suggested anything about trolling or baiting aside from yourself. Unfounded accusations against other editors can be seen as personal attacks. However, since you have not outright accused me of anything, I'm willing to forgive you this trespass if you are willing to understand that making such a suggestion is almost just as bad as making the accusation itself, and avoid doing it again in the future. Thanks. Huggums537 (talk) 14:50, 1 August 2021 (UTC)

  The only thing unfounded would be that PA suggestion, my comment was on contribution, not person, founded in the prior comment. That your other comments may also be alot is no relief. Your arguments have not convinced apparently any of the others either; for my part, I've tried to explain, but I think we are at or passed any useful further discussion, here. -- Alanscottwalker (talk) 15:32, 1 August 2021 (UTC)

  Agreed. ―Qwerfjkltalk 15:40, 1 August 2021 (UTC)

• Oppose: no real reason to do this. ―Qwerfjkltalk 15:56, 31 July 2021 (UTC)
• i have said what i wanted to say about this before. I also have no illusions this discussion will be resolved to everyone’s liking. —TheDJ (talk • contribs) 16:12, 31 July 2021 (UTC)
• Hi! I made the Navigation Popups change that switched from the symbols to the current display of pronouns per Phab ticket T284783. I would be similarly happy to implement the result of this current discussion. Anyway, while I understand why you'd want "gender unspecified" in there, from what I can see from this thread and the previous linked discussions, there's no consensus for such a move. Heck, I think a pretty decent way to express an "unspecified" preferences setting is simply by not specifying a gender in the interface; I also agree with the rest of what Wugapodes said above. Tangentially, we could introduce a new preference specifically for pronouns and that would solve some issues, but people would just object that we already have a preference for that. Also, my worst-case estimate for how long that work (PHP, database, etc etc) would take is "forever", based on previous experience. So... not sure what to do, but I'll keep following the discussion. Again, feel free to ping me if anything gets decided, although I see the precise code change necessary has already been identified above by Writ Keeper. Enterprisey (talk!) 08:00, 1 August 2021 (UTC)
• As Wikipedians, we have no gender. As humans (behind our accounts) we're either male or female. You can't change your XY or XX chromsome combinations, no matter what you identify as. GoodDay (talk) 15:15, 1 August 2021 (UTC)
• I would support having a fourth option per User:King of Hearts, such as the following:

  She/Her - shows she/her in the nav popups

  He/Him - shows he/him in the nav popups

  They/Them - shows they/them in the nav popups

  Unspecified - empty/blank/nothing appears in the nav popups like it currently does right now

  That way editors who "actively" choose to use the pronouns They/Them will now have an option to see 'they/them' in the nav popups for their usernames if they wish; while editors who don't care enough or don't want to have their pronouns listed on Wikipedia can use the 'Unspecified' option. In both cases, the system will use the singular 'they' for the 'They/Them' and 'Unspecified' options, but the nav popups will show they/them for the former option and as blank/empty for the latter option. I also oppose any explicit "Gender unspecified/undisclosed/withheld, etc." wording in the nav popups; nothing should appear in the nav popups pronouns spot for the Unspecified option. Some1 (talk) 16:27, 1 August 2021 (UTC)

  Support this proposal for a fourth option. – There is a difference between preferring to have one's gender identity undisclosed and actively expressing a nonbinary identity through the use of they pronouns. They pronouns should not be imposed on those who prefer to have their gender identity undisclosed on Wikipedia. RGloucester — ☎ 16:39, 1 August 2021 (UTC)

• The pursuit of an inclusive editing environment demands that we respect editors' gender identities. It does not demand that we let editors rewrite the English language. The singular they has achieved widespread use in English as a singular pronoun that does not connote anything about the person's gender, and as an English-language website, I really struggle to see any issue with us using it that way. {{u|Sdkb}} ^talk 18:41, 2 August 2021 (UTC)

  Sdkb, the great irony of this argument is that it proudly waves the banner of inclusive editing high and mighty for a minority group of gender identities, while simultaneously excluding a majority group of "singular they" English speakers and writers it admits has achieved widespread use as evidenced by the Wikipedia link. This does nothing to further the cause of "inclusive editing" and makes the minority group appear to be hypocritical. Huggums537 (talk) 02:36, 3 August 2021 (UTC)

  Huggums, in the three days this discussion has been open, you've commented 37 times. It's okay to engage the discussion, but there's a limit past which you go into WP:BLUDGEON territory. Please be mindful of that. If you are going to reply, please be clearer about your argument; I do not follow your point. {{u|Sdkb}} ^talk 02:45, 3 August 2021 (UTC)

  Having just read your comment again, I think I might have totally misinterpreted it as being against using "they", when it is actually ok with using "they", and totally responded incorrectly. A thousand apologies. I shall strike it from the record since it was a misunderstanding. Huggums537 (talk) 03:10, 3 August 2021 (UTC)

  Yes, my comment is in favor of singular they. Thanks for the striking; perhaps it's me who needs to be clearer. {{u|Sdkb}} ^talk 14:58, 3 August 2021 (UTC)

• Support the proposal to have allow a fourth option of completely unspecified if the User's wishes to. We should not impose singular they on user's who do not want just like we should not impose generic he. We should allow flexiablity. As someone who rejects the use of my gender pronouns on Wikipedia (as my gender pronouns are not relevant to my editing here), whilst also rejecting "they" it is frustating to be forced into one, allow the flexiablity to have none. Regards  Spy-cicle💥  ^Talk? 20:59, 2 August 2021 (UTC)
• Simply remove the gender output from the popup gadget – it is not necessary. This would save a whole load of debate now and in the future. — GhostInTheMachine ^{talk to me} 09:09, 3 August 2021 (UTC)
• Singular They -- already abled? Noticed in examining [21], that the User on the right, in the Popup display is able to convey 'he' and 'they'. The pop-up, shows, quote: "Personal pronoun: he/his, singular they is OK too." So there might already be flexibility for rendering "they" or other pronoun choices, too. Enterprisey, Xaosflux or others familiar with pop-up, is that explained somewhere? Alanscottwalker (talk) 13:33, 3 August 2021 (UTC)

  @Alanscottwalker: nav pops does a few things; for your example of User:Reyk, they have set their interface to male - and navpopus uses this to populate the value in the top left corner of the popup. Navpops also provides some preview-text of a page, in this case the user has put the prose Personal pronoun: he/... on to his userpage, and navpopus has fetched it and delivered it in the preview section at the bottom of the box. — xaosflux ^Talk 14:00, 3 August 2021 (UTC)

  Ah, Thanks! So there is a way to get 'they' or something else in the popup. Is there a way to know what the popup will fetch and make sure it fetched that? -- Alanscottwalker (talk) 14:14, 3 August 2021 (UTC)

  @Alanscottwalker: I wouldn't count on it - NavPopups is primarily designed as an aid to fetch a popup for articles, it certainly is possible that it could fetch and include things based on keywords in the wikitext of userpages. However, it would bloat the script and require those wanting to use it to wave magic chickens over their userpage. The script is here: MediaWiki:Gadget-popups.js. It generally will include the first few lines of text on any page. — xaosflux ^Talk 14:39, 3 August 2021 (UTC)

  So, is that it fetches the first "uncoded" prose on the page? -- Alanscottwalker (talk) 15:05, 3 August 2021 (UTC)

  @Alanscottwalker: mostly (it will fetch wikilinks), the goal around it is mostly to fetch the lead of an article, so it tries to skip templates, etc. — xaosflux ^Talk 00:17, 4 August 2021 (UTC)

  Xaosflux and Alanscottwalker, I have also noticed it will capture the first image [and Wikilink] on the userpage as well. [See my popup for example.] So, if someone in the LGBTQ community wanted to fly an image of a rainbow flag, they could do that if they wanted to trouble themselves with setting up their userpage that way. Also, thanks Alan for sharing the link and bringing this up. Huggums537 (talk) 08:40, 4 August 2021 (UTC)

  That gets me thinking... maybe you could write {{PrefersPronoun|(insert whatever pronouns)}} on your userpage and popups will replace its current display with that. Thoughts? Enterprisey (talk!) 08:07, 4 August 2021 (UTC)

  @Enterprisey: seems like that would be quite an edge case, keep in mind that statistically most editors don't use navpopups, and even less editors would discover and use magic keywords on their userpage to feed in to it (also would probably need some sort of input validation to prevent garbage values from messing up navpop). — xaosflux ^Talk 09:56, 4 August 2021 (UTC)

  I would suggest that an addition be made to Wikipedia:Tools/Navigation popups/FAQ (not that that is terribly easy to find). I would need help with technical wording/links, but something like:

• "Pronoun preference display:

  A User has a choice in ________ to choose gendered pronouns (she/he, her/his), otherwise the system defaults to singular they. When the User chooses gendered pronouns, their choice is displayed in popups. Another way to display various pronoun choices in popups, including neutral pronouns, is to configure your User Page so that the first untemplated prose on the page states something like, 'Personal pronouns: (your pronoun preferences, here).' "

  Alanscottwalker (talk) 15:11, 4 August 2021 (UTC)

  Edge case it may be, but that's a weak argument given that it would be incredibly useful for people who actually need it. I can personally assure you that the Popups code is enough of a trainwreck that a few more lines of code won't "bloat" anything. Anyway, I just found Category:Pronoun user templates, so going through those and having Popups read them (in addition to allowing custom pronouns - but because that appears at the beginning of the popups message, people might use them as generic statuses!) Enterprisey (talk!) 18:14, 4 August 2021 (UTC)

  I'm not opposed to it, as it is a opt-in script afterall. — xaosflux ^Talk 18:44, 4 August 2021 (UTC)

  Ahh, it's possible I misunderstood. I thought you meant "edge case" as in "too much of an edge case to be worth supporting", but if you meant "edge case" as in "we should do this in preferences and/or make it more visible to the user because 'a niche template to influence a niche gadget' is very undiscoverable and thus useless to most people", yes, I completely agree. Enterprisey (talk!) 22:00, 4 August 2021 (UTC)

  Enterprisey, if I understand things correctly, a user can already use the popups as a generic status by simply adding the status before the first line of text on the userpage, right? Huggums537 (talk) 06:44, 5 August 2021 (UTC)

• Like others have written the existing messages are written so that if an user does not define a gender it is assumed that is because of privacy reasons, not gender ones. If this proposal gets through, it does need to create/edit all messages with the gender magic word and reword them from being worded for privancy conserned editors to editors that do not define themselves as either male or female. If that is not done, then we end up with an mess where gender neutral users get fustrated with inappropriate messages. This is not just a matter of pronouns, some messages are worded in a specific way based on which pronoun should be used.--Snævar (talk) 23:43, 3 August 2021 (UTC)

  A few comments scattered throughout this discussion have made claims about what the purpose of the gender preference setting is. I've been looking at this off and on for a couple of months now, and I've come to some conclusions: The first is: This setting doesn't exist because of English. The second is: It's not really about your identity.

  Languages being what they are, every language has its own idea of how to cope with write about gender. Some few, including English, pay little attention to it compared to others. In some, linguistic nods to the gender of the speaker and/or the subject is pervasive. Russian is a typical example of this. You'll see in some Special:Log pages a statement like "WhatamIdoing moved Tyop to Typo". In Russian, you have to assign a grammatical gender to the verb for this sentence. You have to write "WhatamIdoing she-moved Tyop to Typo" or "That guy he-moved Tyop to Typo". There is not "neutral-moved" option in Russian. You either have to know, or you have to use the unspecified-gender default for that language.

  In the event that you are writing about someone whose gender is unknown to you, different languages take different approaches. In English, we often default to singular they if personal pronouns are necessary, but mostly pronouns aren't necessary, and gender doesn't otherwise affect English grammar. In Russian, I understand that they (currently/still) default to masculine for unknown subjects. In German, even if you know the person's gender, you use the grammatical gender that belongs to the noun, rather than the person: "Die Person moved her page; der Editor edited his page; das Neue needs help with its question" – using all three personal pronouns to refer to the same person.

  Main message: The point of this setting is to enable automated messages to make sensible grammatical choices in every language. For this setting to be functional, it needs to correspond to grammar needs. It is possible to construct an grammatically correct sentence in English with any of the three existing options. Therefore English doesn't need a fourth grammar option. (Swedish might; their four pronouns are roughly he/she/it/other it.) If you want an option for announcing your personal identity, then it really shouldn't get mixed up in this translation-focused setting. Whatamidoing (WMF) (talk) 20:06, 6 August 2021 (UTC)

  • Hear, hear! To my understanding this is 100% accurate. Further, the impression I got from people who were deeply into working on these translations is that the existing three options are sufficient to the purpose for basically all languages.
    Note that, even if you're speaking English, the same value of the preference needs to be used for people who have their interface language set to Klingon or Sindarin or Simlish or whatever. While some languages have distinctions between animate/inanimate (e.g. "it"), formal/informal, adult/child, and the like, these can probably be ignored in the interest of not having a confusingly complex preference that wouldn't make much sense in many languages. "It", for example, seems likely to only really be relevant for people who don't want to anthropomorphize bots.
    Personally, I see the recent changes to the preference texts described at MediaWiki talk:Yourgender as a step backwards, as they seem to have confused people into thinking there's a meaningful distinction between "unspecified" and "specified the neutral default". All the preference is intended for is literally "How should MediaWiki describe you grammatically?", and it doesn't matter whether MediaWiki uses "they" because you haven't specified or because you specifically chose "they" or because you chose "they" because you didn't want to pick "he" or "she". That's also how Popups should represent it, in whatever specific manner the developers of that tool want to realize that. Anomie⚔ 03:25, 7 August 2021 (UTC)
  • What if you don’t want MediaWiki to refer to or describe you at all? Is there an “opt out”? Blueboar (talk) 12:04, 7 August 2021 (UTC)
    • Not really, you can't hide your actions from others. The only solution is to not make any actions in the first place. Note that even creating an account is an action, which will generate a log entry along the lines of "User account X was created", so you'd have to start by not creating an account. Anomie⚔ 12:49, 7 August 2021 (UTC)
      • Before this thread closes, I'd like an opportunity to point out that the proposal was not aimed at changing any grammatical structures of the gender settings, and the whole point of it all was only to merely make all of the currently existing settings visible in navigational the popup, which currently excludes the default singular they pronouns setting, but includes the male/female pronouns settings. However, there is no good reason for the excluding the visibility of the setting if the grammatical functionalities of the settings are the same regardless of whether the setting is visible in the navigational popup or not. Huggums537 (talk) 17:01, 28 August 2021 (UTC)

  With all due respect to the freedom of choice and everything related, I oppose all of these suggestions, including the fact that we're even discussing it, for the simple reason that we are dealing with anonymity. We are not face to face discussing things - we don't even know who we're collaborating with, for Pete's sake. This isn't a university campus - it's a virtual community of anonymous volunteers, all of whom are supposed to be here to help build the encyclopedia. Why are we focusing on gender and not the work and reason we're here? If the article isn't gender-related, move along. We don't have time to go check pronoun preferences of anonymous editors when we're in the throws of an important discussion that is directly related to building this encyclopedia. We should not have to focus on the volunteers. I do believe that being respectful toward one another is expected, regardless of race, color, creed or gender - none of which we know because of anonymity, and I'm happy not knowing. Everyone's time here is valuable and deserves equal consideration. Most of all, I dread the thought of an editor forgetting the proper pronoun of an anonymous editor they oppose in a TP discussion, and then find themselves at the dramah board because they used the wrong pronoun. I've already seen that happen. There are too many variables, and we have far too many wikilawyers on WP. I'll share the advice I got from an admin when I was feeling offended: "grow thicker skin". Atsme 💬 📧 13:42, 7 August 2021 (UTC)

  With all due respect Atsme, those were people purposefully and intentionally misgendering someone over an extended period of time, which I'm pretty sure you already knew. There's no need to be an alarmist. Mistakes are occasionally made, and I've never seen that escalate to what you're "afraid of". If it ever did, it would be dismissed almost immediately. Symmachus Auxiliarus (talk) 00:54, 8 August 2021 (UTC)

  Atsme, you've also oversimplified the entire conversation into being merely about focusing on anonymous volunteers and their gender in order to justify a position opposing the entire discussion on the basis it's not related to building Wikipedia. However, the very fact that so many have participated here with their thoughts and opinions regarding privacy, and rights to choose as well as gender is ample evidence there are issues in this discussion that are of importance to Wikipedians, and obviously worth considering in a community discussion, otherwise we wouldn't participate at all. I see no valid reasons for any support of you implying a spirit of building Wikipedia while simultaneously dismissing a whole community for their participation in the discussion - keeping in mind that community discussion itself is an important part of "building an encyclopedia". Without discussion there is no consensus, without that, there's no Wikipedia to build. Huggums537 (talk) 07:31, 8 August 2021 (UTC)

  Symmachus Auxiliarus, I was not referring to that case. Huggums537, I understand and sympathize with your concerns, but the bottomline hasn't changed. We are here to focus on editing, not editors. We did not volunteer our time for any other purpose than to help build the encyclopedia; i.e., create content, copyedit articles, stop vandalism, help newbies edit articles, etc. We are not a social platform to advocate for social issues, and there is also WP:RGW. Those are things we dedicate to the time we spend in real life, not here on WP as editors who have graciously volunteered our valuable time to help build the encyclopedia. We are either going to choose anonymity (all the way around which would include gender), or choose to make our real life identity known. Which is it? Beyond that, there should be no obligation for us to be anything beyond polite (collegial) and helpful. Anything short of that, such as launching hurtful PAs and creating unambiguous disruption at an article or other WP venue, would be actionable, but that is why we have administrators. It is also not an editor's responsibility to act as "thought police". Perhaps this essay will help put things in perspective, as it did for me (rather shockingly) when I first read it; it applies to all of us. I have adopted a sticks and stones approach to words because it is a more realistic approach to living in the real world. Atsme 💬 📧 16:11, 8 August 2021 (UTC)

  Atsme, it seems to me the only one here focusing on other editors, advocating for (or against) social issues, or righting the great wrong of not building an encyclopedia is actually yourself. I personally strongly disagree with Wikipedia:Wikipedia does not need you (even though I respect the author), for the very simple fact that there would be no Wikipedia without "you". The only real world purpose that type of essay serves is to scorn [ostracize] others. Even you admit it was "rather shockingly" put into your perspective, and I think someone would almost have to be in a state of shock allowing for [adopting] such a perspective. However, some other essays (with far less shocking perspectives) worth considering are: Wikipedia:Editors matter and Wikipedia:Wikipedia is a community. Huggums537 (talk) 19:55, 8 August 2021 (UTC)

Survey (alternatives)

• What do editors contributing here think about some alternative wording other than what has been suggested in this proposal that we could use in the navigational popup display to indicate to others that the neutral option has been selected? A few examples that come to my mind are:
  1. Gender undisclosed
  2. Gender withheld
  3. Neutral pronouns
  4. No pronouns selected

Huggums537 (talk) 01:04, 1 August 2021 (UTC)

• Support option 3 or 4 as these do not use gender language, and refer only to the pronoun usage just as the he/him and she/her model does so this is more in line with past discussions about how this whole thing is about language, and how pronouns are used rather than gender. Huggums537 (talk) 01:27, 1 August 2021 (UTC)
• Option 5, none of the above. In other words, leave it as it is. As I tried to communicate above, there's no reason to fiddle with the pronoun display. — JohnFromPinckney (talk / edits) 09:59, 1 August 2021 (UTC)

  JohnFromPinckney, I have not seen where you tried to communicate above... Huggums537 (talk) 13:31, 1 August 2021 (UTC)

  Exactly. I haven't written anything at all before this. What do you suppose that communicates? — JohnFromPinckney (talk / edits) 05:36, 3 August 2021 (UTC)

  JohnFromPinckney, Ok, yeah you got me. That was pretty good bait for fishing man. Huggums537 (talk) 06:22, 5 August 2021 (UTC)

  This response gave me a good chuckle Sdrqaz (talk) 00:03, 6 August 2021 (UTC)

• Option 5, none of the above. This is not about specifying gender, but specifying pronouns. There is no way in natural English to easily avoid using pronouns for somebody. The only viable options are (a) leave it as he/him, she/her, they/them; (b) introduce more options to choose from (e.g. sie/hir); (c) have free text boxes where people write in what they want for each part of speech; or (d) a combination of a+c or b+c. In all cases there would need to be either a default (which would be they/them) or a requirement for people to explicitly choose before being allowed to edit (this is incompatible with allowing unregistered users to edit). While I would happily support a, b or d (and maybe c) this is not what is being proposed here. Thryduulf (talk) 11:15, 1 August 2021 (UTC)

  Thinking more about this, unless there are changes to the current three options, then all of 1, 2 and 4 imply that only he or she are valid options and so should be opposed as actively harmful and 3 is essentially the status quo - default to gender neutral unless someone has actively chosen something else. Thryduulf (talk) 13:41, 1 August 2021 (UTC)

• Support options 3 or 4 per Huggums537. Ideally we would have a free text option where people can choose whatever pronouns they want in order to accommodate the less common options without us needing to enumerate them all and maybe miss some valid options. Unfortunately, that would need some policing as I'm sure that the "attack helicopter" weenies would try to have their idea of "fun" with it. That doesn't seem to be an option here anyway as all we know is that the user has chosen one of three options. Without further information about what the user wants, 3 or 4 is the best we can do. --DanielRigal (talk) 13:15, 1 August 2021 (UTC)
• None of the above - I don’t want anything to appear about my gender or my pronouns when you hover over my name. I don’t want it to say “this user did not choose” or “unspecified”, or anything. I like the fact that if you do not click a button, nothing appears. Blueboar (talk) 14:29, 1 August 2021 (UTC)

  Blueboar, If you do click the button nothing appears also... Huggums537 (talk) 14:40, 1 August 2021 (UTC)

Ah... Don't care what does or does not happen when you do click a button, as long as nothing appears when you don't. Blueboar (talk) 15:01, 1 August 2021 (UTC)

Is the problem that we need more than just three buttons for people (those who want to these click buttons) to click on? Blueboar (talk) 15:52, 1 August 2021 (UTC)

Blueboar, I think a lot of people are saying that is a problem, yes. Huggums537 (talk) 06:17, 5 August 2021 (UTC)

• Comment - What if an editor identifies as a Banjo? Does it really matter? GoodDay (talk) 17:21, 1 August 2021 (UTC)

I would assume (perhaps incorrectly) that a banjo would want “it/its” displayed as its preferred pronoun when someone hovers over its username. Or at least have that as an option. Blueboar (talk) 17:35, 1 August 2021 (UTC)

This comment, especially considering the context of its author, appears to be mocking individuals who identify as non-binary. That's absolutely unacceptable. {{u|Sdkb}} ^talk 18:31, 2 August 2021 (UTC)

That may be inferring a bit too much in the comment in my view, for all I knew it could referring to the adage On the Internet, nobody knows you're a dog (or "banjo"). To my knowledge, GoodDay does not have a history of mocking indivduals (but you are welcome to prove otherwise). Regards  Spy-cicle💥  ^Talk? 16:12, 6 August 2021 (UTC)

Completely meaningless whether GoodDay has a "history of mocking individuals" or not. At worst it's an uncalled for comment mocking other users, and at best it adds absolutely nothing to the conversation. Aza24 (talk) 20:00, 7 August 2021 (UTC)

This is a known transphobic joke. Assuming good faith, GoodDay should probably heed their own advice and bow out of this discussion and any other discussions pertaining to gender identity. Isabelle ^🔔 13:35, 8 August 2021 (UTC)

Indeed, I'm not a fan of Wikipedia bending political correctness to the breaking point, on this topic. Thus my overall reluctance to participate in such discussion. Now, please folks, no more pinging me :) GoodDay (talk) 13:51, 8 August 2021 (UTC)

• Support option 4 the usage of completely unspecified if the User's wishes to. We should not impose singular they on user's who do not want just like we should not impose generic he. We should allow flexiablity. As someone who rejects the use of my gender pronouns on Wikipedia (as my gender pronouns are not relevant to my editing here), whilst also rejecting "they" it is frustating to be forced into one. Just simply allow the flexiablity to have none. Regards  Spy-cicle💥  ^Talk? 20:59, 2 August 2021 (UTC)

  Please don't duplicate your comments.―Qwerfjkltalk 21:21, 2 August 2021 (UTC)

  Spy-cicle, Hi. It appears you are now supporting two different option 4's. The 'option 4' mentioned in the prior section is different from this. Alanscottwalker (talk) 13:52, 3 August 2021 (UTC)

  To clarify Alanscottwalker as the first discussion question was not clear. I support any option which allows users to have an unspecified gender/gender pronoun (or the option to opt out entirely) whilst allowing those who choose an unspecified gender/gender pronoun to have the option to not have "they/them". Hope that helps. Regards  Spy-cicle💥  ^Talk? 15:55, 6 August 2021 (UTC)

• Question: Is there a way to NOT have any “default” setting (at all)? Blueboar (talk) 14:20, 3 August 2021 (UTC)

  @Blueboar: no, even if the schema for this database value were expanded to allow "nul" as a value - something would still be the 'default' (even it is were "nul"). The current default is unspecified. — xaosflux ^Talk 15:01, 3 August 2021 (UTC)

Ah... THAT'S the problem. Blueboar (talk) 16:36, 3 August 2021 (UTC)

• Option 5, fix MediaWiki settings I've used Nav Pops for years. At some point I noticed that there was a male or female symbol in the popup (they were recently changed to he/she). I also noticed that some users (like myself) didn't have a symbol, because they had not chosen their gender (pronouns). There is no need to clutter the tiny popup with any additional "gender unspecified" text, because most users who use the gadget will eventually understand how it works. If you don't see he/she, you can use "they", or check the editor's user page to see if they have more information about their preferences there. However, I do think it would be best if the MediaWiki settings had a fourth option, so that there would be a real option for users who want to actually choose something else than male/female pronouns. Then the Nav Pops gadget could show "they" for those who had really chosen it. -kyykaarme (talk) 19:41, 3 August 2021 (UTC)
• Support 3 and 4: users who have not specified their gender should default to "unspecified" and have nothing render in the popup. Users whose pronouns are they/them should be able to select that setting so that "they/them" appears in the popup. "Not disclosed" and "withheld" both fall under "unspecified" unless we want this to be used for soapboxing. Ideally we would have a fifth free text setting which would tell popups to render whatever the user specifies but that the software would treat the same as gender neutral (for templates and whatnot), but without admins being able to override the setting this would be an open door to vandalism. Ivanvector's squirrel (^trees/_nuts) 15:06, 5 August 2021 (UTC)
• Oppose all - per my discussion above. Atsme 💬 📧 14:09, 7 August 2021 (UTC)
• Oppose all - We're supposed to be here to make an encyclopedia, not to do random junk.50.201.228.202 (talk) 15:16, 7 August 2021 (UTC)

  50..., for what its worth - absolutely none of any part of this discussion will have any impact of editors without accounts. — xaosflux ^Talk 17:24, 7 August 2021 (UTC)

• Oppose all per my comment above. Despite being labeled a survey, this section does not have the possibility of reaching an actionable consensus, since any survey that leaves out the status quo option is inherently leading. {{u|Sdkb}} ^talk 17:56, 7 August 2021 (UTC)

  Sdkb and Stifle, I did not think to add the status quo as one of the selections, and wasn't intentionally leading anyone. Would either of you consider choosing an option if the status quo was also a choice? Also, do you think everyone would be okay if I retroactively add the status quo to the selection in order to avoid leading anyone? Huggums537 (talk) 22:41, 9 August 2021 (UTC)

  After more than 13 responses? No, way too late. — JohnFromPinckney (talk / edits) 22:54, 9 August 2021 (UTC)

  Ok, that's fine since it doesn't need to be there anyway because I have observed that plenty of other people have been able to choose the status quo option without the selection being made available to them and without them making any insinuations about anyone leading them either. So, it should seem fairly obvious in anyone what good faith that the option is not truly needed anyway. Huggums537 (talk) 23:10, 9 August 2021 (UTC)

• Oppose all per Sdkb. Stifle (talk) 16:30, 9 August 2021 (UTC)
• Support the four options proposed by Some1. Clovermoss (talk) 22:38, 18 August 2021 (UTC)

Discussion: Optional user generated choices

There has been some conversation above between Xaosflux, Alanscottwalker and Enterprisey about enabling a user generated script, or maybe simply placing a notice letting users know they can generate their own popup if they choose to alter their userpage. I also noticed users such as Valereee were in favor of such an idea while Kyykaarme and TheDJ suggested people check userpages indicating this might be a viable option for such users. I'd like to get thoughts from the community on this option as well. Whatever the outcome of this entire thread, I've already recently enabled this option on my own userpage as an example that can be seen if you hover over my username and have the navigation gadget enabled in your preferences. Huggums537 (talk) 11:45, 7 August 2021 (UTC)

@Huggums537: I currently use the {{User They them pronouns}} infobox in my profile to let others know my preference. Right now, that's the best option, seconded only to have one's pronouns in their signature (which I'd rather not do, for aesthetic reasons). I think that having a way to transpose that information to the pop-up gadget would just make things easier for all. I personally use the pop-up to check other user's pronouns when talking to someone I haven't talked to before. Isabelle ^🔔 13:40, 8 August 2021 (UTC)

Isabelle Belato, yes, I'm also using the same userbox for my selection as well. However, the selection doesn't appear in the nav popup either. I had not thought of putting it in the signature. That's a novel idea, but I rather like approach I'm currently using to add the line of text to my userpage and allow nav popups to fetch it for me because it solves my problem, and it looks like nothing I've suggested in my proposal is going to pass, but hopefully the community will put a notation somewhere to let others know they can do the same thing I've done if they choose to. Huggums537 (talk) 18:10, 8 August 2021 (UTC)

2021 RfA review

I have started a 2021 RfA review and accompanying RfC to identify what issues, if any, there are with RfA. Interested editors are invited to participate. Best, Barkeep49 (talk) 01:41, 29 August 2021 (UTC)