Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by NaomiAmethyst (talk | contribs) at 04:29, 23 July 2021 (→‎Arbitrary break (ClueBot edit summary): Reply.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.


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

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

    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)[reply]
      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)[reply]
    • 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)[reply]
      • 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)[reply]
    • 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)[reply]
      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)[reply]
      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)[reply]
    • Support per last discussion. ~ HAL333 16:28, 26 June 2021 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]
      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)[reply]
    • 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)[reply]
    • 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)[reply]
      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)[reply]
      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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
      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)[reply]
      LOL! Narky Blert (talk) 20:57, 26 June 2021 (UTC)[reply]
    • Support per previous discussion, and strengthened by RandomCanadian's argument. waddie96 ★ (talk) 19:08, 26 June 2021 (UTC)[reply]
    • 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)[reply]
    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)[reply]
    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)[reply]
    • Support Seems to strike a reasonable balance. XOR'easter (talk) 19:31, 26 June 2021 (UTC)[reply]
      • 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)[reply]
      • 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)[reply]
    • 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)[reply]
      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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • Support per all the above. No-brainer. Lugnuts Fire Walk with Me 07:37, 27 June 2021 (UTC)[reply]
    • Support semi-protection, PC as a second choice, all per above. MER-C 08:43, 27 June 2021 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    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)[reply]
    • 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)[reply]
    • 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)[reply]
      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)[reply]
      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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
      • 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)[reply]
        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)[reply]
        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)[reply]
        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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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. SpencerT•C 23:42, 3 July 2021 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]
    • Support either/both, net positive. Stifle (talk) 10:15, 5 July 2021 (UTC)[reply]
    • 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)[reply]
      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)[reply]
      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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]

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

    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • Oppose PC. By its nature, PC isn't effective for high-traffic pages. El_C 13:31, 11 July 2021 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]

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

    This was tried back in 2013, and didn't work out * Pppery * it has begun... 13:58, 28 June 2021 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    @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)[reply]

    Proposal: Turn on syntax highlighting by default for new accounts

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


    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)[reply]
    • Support Helps to improve retention, and it looks good too. dudhhrContribs 02:31, 6 July 2021 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • Strongest support per Sdkb. 🐶 EpicPupper (he/him | talk, FAQ, contribs | please use {{ping}} on reply) 03:27, 7 July 2021 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]
      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)[reply]
    • 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)[reply]
    • Support. Makes things way easier, less intimidating, easier to navigate, spot mistakes, etc ─ ReconditeRodent « talk · contribs » 01:41, 12 July 2021 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • Support Although I tend not to use it myself — GhostInTheMachine talk to me 17:18, 16 July 2021 (UTC)[reply]
    • 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)[reply]
    • Oppose 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)[reply]
      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)[reply]
      @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)[reply]
    • 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)[reply]
    • Support unconditionally. This feature is must have if you don't use Visual editor. AXONOV (talk) ⚑ 21:55, 22 July 2021 (UTC)[reply]
    • 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)[reply]

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

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

    • Support removal of Wikiproject links, as wiki projects are not reader facing. -- Asartea Talk | Contribs 16:08, 8 July 2021 (UTC)[reply]
    • @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)[reply]
      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)[reply]
      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)[reply]
      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)[reply]
    • 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)[reply]
      • This is a good point, we really shouldn't be.... Aza24 (talk) 16:04, 9 July 2021 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]
    • Strongly oppose removing links to categories and portals, these complement the content of the navigational template. DuncanHill (talk) 08:07, 10 July 2021 (UTC)[reply]
      @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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
      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)[reply]
      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)[reply]
      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)[reply]
      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)[reply]
      Nearly every page has at least one, including this one. Hawkeye7 (discuss) 21:29, 12 July 2021 (UTC)[reply]
    • 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)[reply]
      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)[reply]
    • 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)[reply]
    • There is an old RFC about this......that resulted in the removal of Wikiprojects all over.Moxy- 14:24, 10 July 2021 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]

    Proposal: Remove the link to the local embassy from the main page

    CONSENSUS FOR REMOVAL
    This was listed on WP:CENT earlier today, but it's already been present here in a centralized venue for ten days, and so far among !voters there is unanimous support and no signs that'll change much, so it'd be pointless WP:BURO to keep it open longer. The page is very clearly dead, among other concerns, which editors see as valid reason for removal of the main page link. The only remaining question is whether to formally deprecate it as well, something about which views are more split. That question can be considered on its own if anyone wishes to raise it. (non-admin closure) {{u|Sdkb}} talk 23:56, 22 July 2021 (UTC)[reply]

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

    At the moment the other areas of Wikipedia template includes a link to the Local Embassy. I don't think this link is particularly useful to most visitors to the main page and should be removed. My reasoning for this proposal has 3 main parts

    • The page is dead, and has been for years. In the last year there were 5 requests for help posted on the talk page, 4 of those have received no response, and one (a question about how the listed ambassadors were no longer active on the project) received a 3 month late response telling the user to ask for help somewhere else. Of the 9 questions asked in the 2018-2019 archive 2 received a response, one asking for a revert on the Chinese Wikipedia, and one asking for technical help with the content translation tool. Since 2004 the talk page has received a total of 1052 edits (note the edits are split across Wikipedia talk:Local Embassy and Wikipedia talk:Local Embassy/Archive 1), and a look through the page history will show that many of those edits are random vandalism, confused questions about actual embassy problems or random chit-chat, with relatively few edits using the page for language related issues.
    • The page doesn't seem to have a well defined purpose. The main page link states the page is for "For Wikipedia-related communication in languages other than English", the notice on the page states it is for "discussing Wikipedia-related multilingual coordination.", and the linked page on meta describes the meta embassy as being a place for "resources to help with cross-language issues — site-wide policy and software decisions that affect all of us and interlanguage linking". The pages functionality also seems to overlap quite confusingly with Wikipedia:Embassy, which is equally as dead.
    • Even if the page wasn't abandoned I don't think the functionality it is supposed to provide is of use to enough people to justify a main page link - this seems like the kind of page that should be linked from the community portal or help desk. The other links in that section lead to essential resources for users - the community portal which acts as a central hub for all Wikipedia related community stuff, the help desk for asking questions about editing, the reference desk for asking questions related to content etc. In comparison to those asking questions about Wikipedia related stuff in languages other than English seems to be a rather niche use case. The lack of usefulness to users is demonstrated by the aforementioned deadness of the place.

    I think that while this page may have made sense in 2004 in the days before google translate and the like the need for it to be a main page link has long passed. I don't see the sense in sending readers of the main page to a confusing, abandoned page where their questions will languish unanswered for years. 192.76.8.91 (talk) 22:39, 13 July 2021 (UTC)[reply]

    • Support Agree the page is clearly useless as it stands. For what it's worth, I did some cleanup of the page a few months ago, but that made it only a tiny bit less useless and still not worthy of being linked from the main page. * Pppery * it has begun... 23:43, 13 July 2021 (UTC)[reply]
    • information Administrator note this would just be a simple update to Template:Other areas of Wikipedia. — xaosflux Talk 15:20, 14 July 2021 (UTC)[reply]
    • Support I was thinking how pointless this was. In my opinion the whole {{Other areas of Wikipedia}} needs to be rearranged and cleaned up, I think a link to the Teahouse would also be useful, but perhaps for another discussion :) — Berrely • Talk∕Contribs 18:09, 14 July 2021 (UTC)[reply]
    • Support Unnecessary and unhelpful. ~ HAL333 19:42, 14 July 2021 (UTC)[reply]
    • Support. It's useless. No use linking it anymore. Chess (talk) (please use {{reply to|Chess}} on reply)Template:Z181 06:40, 15 July 2021 (UTC)[reply]
    • Support, probably makes more sense for those using other languages to ask at other language wikis, which are already linked from the main page. CMD (talk) 06:59, 15 July 2021 (UTC)[reply]
    • Comment - if the page is unused, shouldn't it be deleted altogether, or at least marked with the old "historical interest only" hatnote. As an aside, I notice my name has been on the list since 2014 as someone who can help with Kinyarwanda issues. I guess if you need to talk about your friends and relatives or order carrots at the market, I could help out with that, but my deeper understanding of that language is very limited! To the best of my knowledge nobody has contacted me since I've been on that list though, anyway.  — Amakuru (talk) 09:27, 15 July 2021 (UTC)[reply]
      • Amakuru It would probably be worth sending it to MFD again if the decision here is to unlink it, but I don't think it's possible to send pages for a deletion discussion while they're linked from the main page, they fall under the 6th criterion for speedy keeping. 192.76.8.91 (talk) 12:50, 15 July 2021 (UTC)[reply]
        As long as other Wikipedia sites have their own local embassies, it would probably better to mark the page as historical rather than delete it. To preserve history, I think that is a good idea for the long term, anyway. isaacl (talk) 16:36, 15 July 2021 (UTC)[reply]
        isaacl I think the page that other wikis have equivalents of is WP:Embassy, this seems to be a rather confusingly named English wiki only variant of that page?? It's really rather confusing why we have two of them. Marking it historical or archiving it would also be fine by me, but I think it really needs to be removed from the main page first (if that's what the outcome of this discussion is) because we shouldn't be sending readers to closed help pages. 192.76.8.91 (talk) 16:48, 15 July 2021 (UTC)[reply]
        I didn't check all of the links to other language versions of the local embassy page, but the handful I looked at seemed to serve the same purpose. isaacl (talk) 17:38, 15 July 2021 (UTC)[reply]
    • Support. Seems of little use, let's remove it and mark it as historical. — Goszei (talk) 22:26, 15 July 2021 (UTC)[reply]
    • Comment - It does get a consistent couple hundred hits a day, after all. The main purpose of the page, to my eyes, is to provide a directory of people who are willing to help in particular languages. Thus most of the requests for help would be directed to those people and not visible on the embassy talk page, right? So let's ping some of the people who have added their name here (just some names I recognize as active): @OhanaUnited, Deryck Chan, Sky Harbor, Trialpears, Amakuru, Deisenbe, M-Mustapha, CptViraj, Finnusertop, Mhhossein, King of Hearts, Buidhe, SoWhy, Sandstein, Kippelboy, Titodutta, and Deborahjay: when was the last time, if ever, you received a message which may have come via the Embassy? Certainly if nobody is leaving messages at the Embassy and nobody is getting messages through the Embassy, it seems hard to justify keeping on the main page. — Rhododendrites talk \\ 21:03, 16 July 2021 (UTC)[reply]
      Added myself very recently while checking out the page from the discussion and fixing the awfully awkward Swedish. I feel like there wouldn't be any harm in removal, but would like some data. --Trialpears (talk) 21:15, 16 July 2021 (UTC)[reply]
      I've never received a user talk page or any other kind of message that indicated or gave me the impression that it was through the Embassy. – Finnusertop (talk ⋅ contribs) 21:20, 16 July 2021 (UTC)[reply]
      I don't recall having ever received messages from people who were directed my way via the Embassy. -- King of ♥ ♦ ♣ ♠ 15:09, 17 July 2021 (UTC)[reply]
      I don't recall anyone ever mentioning they came through the Embassy but then again, why would they? Regards SoWhy 18:35, 17 July 2021 (UTC)[reply]
      None whatsoever on the English Wikipedia, but I have received messages through the Local Embassy pages of other Wikipedia editions. From a cross-wiki point of view this is an important landing page for newcomers who are not fluent in the project language and for cross-wiki editors. With that in mind I think it's important to keep maintaining the Local Embassy as a landing page with links to relevant resources for multilingual visitors, and I mildly oppose removal from Main Page due to the English Wikipedia Main Page's normative effect on new Wikipedia language editions. Deryck C. 01:07, 19 July 2021 (UTC)[reply]
      Rhododendrites I hope it's not too late, but I can recall some negligible instances of receiving requests from the users who were directed to me vit the Embassy. You can see the instances here and here. --Mhhossein talk 11:41, 20 July 2021 (UTC)[reply]
    • Support removal I use the embassies of other language Wikipedias. While I support removing the English Wikipedia embassy from high prominence due to low usage, I certainly want it to remain accessible. Part of the usefulness of the embassy system is that they exist on so many language versions of Wikipedias, and there is value to that interconnectedness and their availability. Also, the lack of posting to the English Wikipedia embassy is not a reflection of the absence of non-English language questions that people would like to post here. Many users would post somewhere, but instead do things like write to OTRS instead. If possible, lowering barriers to access for posting at the embassy would be helpful, because public questions are better than private ones when there is no need for privacy. Blue Rasberry (talk) 15:15, 17 July 2021 (UTC)[reply]
    • Support per nom. Net negative; main page is too highly viewed for even a somewhat abandoned page. Aza24 (talk) 15:42, 17 July 2021 (UTC)[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Any actions that should be taken around concerns for Hong Kong based editors?

    See this article https://hongkongfp.com/2021/07/14/hong-kong-wikipedia-editors-take-precautions-amid-fears-mainland-peers-may-report-users-to-national-security-police/ --occono (talk) 20:55, 14 July 2021 (UTC)[reply]

    That source seems to be mixing up the different language Wikipedias which are entirely different projects. eg: One member of the Wikimedians of Mainland China (WMC) user group who was involved in the chat about reporting Hong Kong users has top-level editor positions on Wikipedia, including Administrator, Bureaucrat and Oversight status. (I don't think we have a Chinese or HKer crat+OS, so presumably that's a zhwiki user). Their screenshot is from zhwiki too. Later in the article they discuss enwiki's policy on personal attacks. eg Editorial activities on Wikipedia rely heavily on a set of complex guiding principles and policies. Violations or repeat offences may lead to users being warned or even banned by administrators, who are users elected from the community. ... One of the policies is the prohibition of the use of legal threats. They're either unintentionally muddling them up or switching between them confusingly.
    Anyway, on the substantive point, I see nothing we can do except re-emphasise (if asked) the advice that your username, user page content, and whatever you give away in edits can all be used to trace you. I don't think the WMF would give away IPs or emails to Chinese authorities, and that article seems to just suggest individuals doxing each other. Since all content is public there's nothing we, as a community, could do about that anyway. The users should probably also take steps to prevent snooping by their ISP. Courtesy ping Deryck Chan, since he's mentioned in the article. ProcrastinatingReader (talk) 22:34, 14 July 2021 (UTC)[reply]
    Thanks for the courtesy ping.
    • The article is unintentionally vague about the boundaries between different Wikipedias. One can only say so much in a news article. But I don't think that is particularly confusing because the policies mentioned (e.g. OS, 3RR, no legal threats) are all either global or applicable across most WMF projects. I am not privy to the investigative journalism into the off-wiki threats so I can also only presume those "top-level" positions refer to zh.wp rights.
    • In terms of things the global / English Wikipedia communities can do:
      • Pursue global bans along the lines of WP:No legal threats against editors who chimed in to suggest reporting one another to PRC/HK national security police (NSP). The HKFP article did say the editors involved had flatly denied hinting at reporting HK editors to NSP, and the case may be thin if the threats were made in an off-wiki discussion channel about Wikimedia, but could possibly be backed up if multiple editors can corroborate.
      • Continue our WP:RSN vigilance regarding media owned by states that censor Wikipedia access. The discussions last year that banned Global Times, Wen Wei / Ta Kung, and CGTN are in the right direction and we need to keep up the vigilance.
      • Moving forward, Wikimedia will need to take on a stronger role in the creation of reliable sources, not just a consumer of reliable sources published by others.
    --Deryck C. 10:35, 15 July 2021 (UTC)[reply]
    The meta:Global bans criteria does seem quite strict, in that it requires 2 local blocks, and I'm not sure NLT is a global policy. Potentially Foundation action via meta:Trust and Safety would also work, and might even be the more appropriate route since the threats seem more material than the usual legal threat, doubly so if the issues involve functionaries (who can see user IPs). ProcrastinatingReader (talk) 10:53, 15 July 2021 (UTC)[reply]
    There is currently no protection against legal threat on Chinese Wikipedia. The NLT is only a guideline, not a policy as it was imported from English Wikipedia. The page says while there's precedent for blocking an editor on Chinese Wikipedia for issuing legal threat, there is no consensus on the implementation of this rule as a policy. It won't hold much "teeth" if it's just a guideline and no enforcement from Trust and Safety team. OhanaUnitedTalk page 01:20, 17 July 2021 (UTC)[reply]

    CentralNotice banner for Indic Wikisource Proofreadthon August 2021

    Dear colleagues, please comment on CentralNotice banner proposal for Indic Wikisource Proofreadthon August 2021 for the Indic Wikisource contest. (15 August 2021 - 31 August 2021, all IPs from India, WPs,only). Thank you.- Jayanta Nath (Talk|Contrb) 17:10, 18 July 2021 (UTC)[reply]

    Optional AIV backlog notice for administrators

    As the title suggests, I propose that we create an optional notice for administrators. When there is a backlog at AIV, HBC AIV helpberbot5 sends out a notice to administrators about the backlog. This is not in the form of a talk page message, but instead is similar to the one that appears when a user is thanked for an edit. It will be delivered once to all opted-in administrators that make an edit after the backlog is confirmed until the backlog is resolved. The benefit of this feature is that AIV reports will be dealt with quicker. I’ve seen that backlog go as high as 20 (user) reports before someone responded. If we create an opt-in Bat Signal, we can significantly lower the odds of that happening. Thank you for hearing out my proposal, and I hope you will join me in supporting it. Helen(💬📖) 20:52, 18 July 2021 (UTC)[reply]

    A low-tech way to do that would be like the "attack pages" bat-signal (a piece of code written by @HighInBC IIRC; I use Barkeep49's version at User:Barkeep49/Attack.js), by adding an "AIV is backlogged" message to all pages whenever AIV is in the backlogged category. An alternative approach within the current technology would be an opt-in list of admins that just get an ordinary ping if AIV is backlogged. Neither of these approaches is perfect, though. (Whether AIV is "backlogged" has only little relation to whether any blocks need to be made urgently, which is the more important issue). —Kusma (talk) 18:15, 20 July 2021 (UTC)[reply]
    Pinged the wrong user, meant Barkeep49. Sorry, Barkeep-not-49. —Kusma (talk) 18:17, 20 July 2021 (UTC)[reply]
    I have found that script quite useful (which HighInBC did write) in responding quickly to attack pages. To me I think a broader tool, which would probably have to be a wishlist item, of letting users select desired noticeboards to highlight when backlogged could be helpful rather than just focusing on AIV. Best, Barkeep49 (talk) 18:24, 20 July 2021 (UTC)[reply]
    That sounds like a great idea. I would opt in. ~ ONUnicorn(Talk|Contribs)problem solving 18:53, 20 July 2021 (UTC)[reply]
    That does sound like a great tool. My current script simply checks if a category has any population and creates a button[5]. It would not take too much work to have it check a category for backlogs and then create a button for each backlog that the user has opt-ed into. I don't have the time to do this myself but I would certainly use it if it existed.
    BTW I love the idea of calling my tool the bat signal.HighInBC Need help? Just ask. 22:08, 20 July 2021 (UTC)[reply]
    @HighInBC if you get around to doing more development could you do it on a separate page so those of us who want to use it don't need to import your whole JS page? This is why I had to create a fork. Best, Barkeep49 (talk) 02:52, 21 July 2021 (UTC)[reply]
    Sure. It is something I just threw together one day, though it seems to be adopted by more than a couple of people. Right now I have two nearly identical copies for attack pages and vandalism pages. I should try to make a single script that can be configured, if I do this I will be sure to make a subpage. It is hard for me to focus on coding these days as I have a house full of distractions. HighInBC Need help? Just ask. 03:04, 21 July 2021 (UTC)[reply]
    Echoing others that it's a great idea, especially Barkeep's suggestion of a more general tool. Also, this may be controversial, but I think it should be opt-out - so, MediaWiki:Group-sysop.js - because I think that would be a net positive, and the whole point is getting attention to one of the easiest backlogs. Enterprisey (talk!) 06:57, 21 July 2021 (UTC)[reply]
    Don't think we should force that script in there - but perhaps an opt-in gadget to make it easy for admins that want to enable it (even the dreaded "single user supported gadget" type) - can announce in the adminnews. — xaosflux Talk 10:37, 21 July 2021 (UTC)[reply]

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

    Full list of pages discussed in MFD (provided for convenience)
    MediaWiki:Abusefilter-disallowed/de (edit | talk | history | links | watch | logs)
    MediaWiki:Articleexists/he (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error empty references define/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error empty references define/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error empty references define/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error group refs without references/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error group refs without references/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error group refs without references/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error included ref/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error included ref/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error included ref/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error no link label group/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error no link label group/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error no link label group/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error ref no input/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error ref no input/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error ref no input/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error ref no key/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error ref no key/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error ref no key/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error ref numeric key/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error ref numeric key/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error ref numeric key/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error ref too many keys/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error ref too many keys/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error ref too many keys/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references group mismatch/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references group mismatch/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references group mismatch/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references invalid parameters/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references invalid parameters/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references invalid parameters/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references missing group/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references missing group/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references missing group/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references missing key/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references missing key/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references missing key/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references no backlink label/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references no backlink label/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references no backlink label/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references no key/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references no key/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references no key/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references no text/es (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references no text/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error references no text/pt-br (edit | talk | history | links | watch | logs)
    MediaWiki:Cite error refs without references/nl (edit | talk | history | links | watch | logs)
    MediaWiki:Contact/ko (edit | talk | history | links | watch | logs)
    MediaWiki:Contact/pl (edit | talk | history | links | watch | logs)
    MediaWiki:Contact/pt (edit | talk | history | links | watch | logs)
    MediaWiki:Contact/uk (edit | talk | history | links | watch | logs)
    MediaWiki:Contents/ko (edit | talk | history | links | watch | logs)
    MediaWiki:Contents/pl (edit | talk | history | links | watch | logs)
    MediaWiki:Contents/pt (edit | talk | history | links | watch | logs)
    MediaWiki:Copyright/ko (edit | talk | history | links | watch | logs)
    MediaWiki:Copyrightwarning/ar (edit | talk | history | links | watch | logs)
    MediaWiki:Copyrightwarning/de (edit | talk | history | links | watch | logs)
    MediaWiki:Copyrightwarning/es (edit | talk | history | links | watch | logs)
    MediaWiki:Copyrightwarning/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Copyrightwarning/it (edit | talk | history | links | watch | logs)
    MediaWiki:Copyrightwarning/ja (edit | talk | history | links | watch | logs)
    MediaWiki:Copyrightwarning/nl (edit | talk | history | links | watch | logs)
    MediaWiki:Copyrightwarning/pl (edit | talk | history | links | watch | logs)
    MediaWiki:Copyrightwarning/ru (edit | talk | history | links | watch | logs)
    MediaWiki:Featuredcontent/de (edit | talk | history | links | watch | logs)
    MediaWiki:Featuredcontent/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Featuredcontent/ko (edit | talk | history | links | watch | logs)
    MediaWiki:Featuredcontent/pl (edit | talk | history | links | watch | logs)
    MediaWiki:Featuredcontent/pt (edit | talk | history | links | watch | logs)
    MediaWiki:Gadget-HotCat/de (edit | talk | history | links | watch | logs)
    MediaWiki:Gadget-popups.js/de (edit | talk | history | links | watch | logs)
    MediaWiki:Histlegend/fr (edit | talk | history | links | watch | logs)
    MediaWiki:Interaction/de (edit | talk | history | links | watch | logs)
    MediaWiki:Interaction/ko (edit | talk | history | links | watch | logs)
    MediaWiki:Interaction/pl (edit | talk | history | links | watch | logs)
    MediaWiki:Interaction/pt (edit | talk | history | links | watch | logs)
    MediaWiki:Licenses/ko (edit | talk | history | links | watch | logs)
    MediaWiki:Listfiles-summary/de (edit | talk | history | links | watch | logs)
    MediaWiki:Noimage/de (edit | talk | history | links | watch | logs)
    MediaWiki:Permalink/pt (edit | talk | history | links | watch | logs)
    MediaWiki:Protect-text/es (edit | talk | history | links | watch | logs)
    MediaWiki:Revision-info/de (edit | talk | history | links | watch | logs)
    MediaWiki:Sharedupload-desc-here/de (edit | talk | history | links | watch | logs)
    MediaWiki:Sharedupload-desc-here/nl (edit | talk | history | links | watch | logs)
    MediaWiki:Sharedupload-desc-here/no (edit | talk | history | links | watch | logs)
    MediaWiki:Sp-contributions-footer-anon/nl (edit | talk | history | links | watch | logs)
    MediaWiki:Sp-contributions-footer-anon/nl-informal (edit | talk | history | links | watch | logs)
    MediaWiki:Sp-contributions-footer/nl (edit | talk | history | links | watch | logs)
    MediaWiki:Sp-contributions-footer/nl-informal (edit | talk | history | links | watch | logs)
    MediaWiki:Talkpagelinktext/nl-informal (edit | talk | history | links | watch | logs)
    MediaWiki:Tooltip-n-aboutsite/pt (edit | talk | history | links | watch | logs)
    MediaWiki:Tooltip-n-contact/pt (edit | talk | history | links | watch | logs)
    MediaWiki:Tooltip-n-contents/pt (edit | talk | history | links | watch | logs)
    MediaWiki:Tooltip-n-featuredcontent/pt (edit | talk | history | links | watch | logs)
    MediaWiki:Tooltip-t-permalink/pt (edit | talk | history | links | watch | logs)
    MediaWiki:Tooltip-t-recentchangeslinked/pt (edit | talk | history | links | watch | logs)
    MediaWiki:Tooltip-t-whatlinkshere/pt (edit | talk | history | links | watch | logs)
    MediaWiki:Uctop/nl-informal (edit | talk | history | links | watch | logs)
    MediaWiki:Uploadtext/fi (edit | talk | history | links | watch | logs)
    MediaWiki:Uploadtext/ru (edit | talk | history | links | watch | logs)
    MediaWiki:Wikimedia-copyright/pt (edit | talk | history | links | watch | logs)
    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)[reply]
    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)[reply]

    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)[reply]
      • 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)[reply]
        @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)[reply]
        @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)[reply]
    • Keep most - these seem more useful to keep around than to delete. Elli (talk | contribs) 00:41, 19 July 2021 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]
    • 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)[reply]

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

    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    +1 @Whatamidoing (WMF). Thanks for giving clarity for what I am proposing. Aasim (talk) 17:52, 20 July 2021 (UTC)[reply]

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

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

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

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

    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)[reply]
    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)[reply]
    • 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)[reply]
    • 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)[reply]
    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)[reply]
    • 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)[reply]
    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)[reply]
    I would suggest something along the lines of "Reverted edit by [user]: Non-constructive" ―Qwerfjkltalk 16:02, 22 July 2021 (UTC)[reply]

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

    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: [6] [7] [8] [9] 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)[reply]
    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)[reply]
    • 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)[reply]

    Change language in a template

    There is a discussion at Template talk:Nutshell regarding a potential change to the wording/language of the template text. Your input is requested. Primefac (talk) 15:14, 21 July 2021 (UTC)[reply]

    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1035012861"