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

There is a (near-unanimous) consensus for the proposal; and with comments only trickling in very sporadically in the past week or so, it's clear that WP:SNOW applies, too. RandomCanadian (talk / contribs) 22:42, 3 September 2021 (UTC)

---

Should administrators be allowed to apply extended-confirmed protection to high risk templates? 03:59, 17 August 2021 (UTC)

Moved from Wikipedia:Administrators' noticeboard § TemplateProtector bot updated; Should we use ECP on templates?

 – Wug·a·po·des​ 20:45, 17 August 2021 (UTC)

In response to the August 16 incident (permalink), and subsequent pings I've received on several of platforms, I've gone ahead and changed the behaviour of User:MusikBot II/TemplateProtector to elevate protection levels based on the configuration. Prior to today, the bot only looked for templates that were completely unprotected. In the past this was mainly a necessity for performance, but I believe this is no longer a problem. After today's events, I hope we recognize the necessity for this extra layer of automation.

That said, prior to running the bot, I tediously reviewed the full list of affected pages. The ones that have had their protection changed I'm fairly confident in. I either verified few or no previous editors would be unable to edit it, or that the content rarely if ever changes (i.e. redirects). For the few outliers, I used a little WP:IAR and applied extended-confirmed protection so that prior editors can still contribute. A few others I added to the bot's exclusion list so they will forever be ignored.

Which brings me to my next question, should we allow preemptive use of ECP on templates? Currently the policy states Extended confirmed protection should not be used as a preemptive measure against disruption that has not yet occurred. I agree with this sentiment wholeheartedly, but the situation is obviously different for templates and modules that are vulnerable to causing massive disruption. Take Template:Australian politics/party colours as an example. It is regularly edited by experienced users. All are extended confirmed, but none are template editors, and probably wouldn't become one solely to edit a template like this. The transclusions meanwhile are political in nature and hence are higher risk for targeted vandalism. So extended confirmed seems like a very nice compromise, which is why I applied it in this case (the bot would have otherwise raised to template protection).

If we do formally permit use of ECP for preemptive purposes, I suggest modifying the bot configuration to say, >500 transclusions for autoconfirmed (status-quo), then >5000 for extended confirmed, and perhaps >8000-10000 for template editor (currently set to >5000). With ECP in the picture, that should in my opinion take out a lot of potential for vandalism. However it's worth mentioning that, to my knowledge, since February 2019 there have been a but a handful of cases where someone lowered from template protection after the bot applied it. So that suggests 5000 is reasonable for template editor, in which case you might put ECP at 3000 or something. But we have to agree on using ECP first :)

Thoughts? Previous discussion on this topic can be found in the original bot proposal. Warm regards, — MusikAnimal ^talk 02:38, 17 August 2021 (UTC)

• I agree that this would be a reasonable compromise, especially for templates that are more content-oriented than technical. I'd also be interested in the viability of, for some highly visible content-oriented templates, breaking them into a TPE-protected template that covers the logic and XCP-protected subtemplates that cover the content (maybe with a mediating Lua module to sanitize potential attempts at CSS vandalism). But that's just spitballing there. -- Tamzin^{[cetacean needed]} (she/they) 03:43, 17 August 2021 (UTC)
• I also agree that this makes sense. HighInBC ^{Need help? Just ask.} 03:59, 17 August 2021 (UTC)
• Thanks for all the work and I support preemptive ECP. Perhaps there should be an exclusion method to allow only semi-protection for templates/modules in a certain category, but the exclusion would be ignored if the translusion count is above some threshold. The numbers proposed for the thresholds are too high. We don't want 3000 articles easily damaged by one malcontent. Johnuniq (talk) 04:04, 17 August 2021 (UTC)
• Thanks for your work on this, MusikAnimal. I also support ECP, and I concur with Johnuniq that the thresholds are too high. The 2018 RfC found consensus for semi-protecting above 200–250, so I'd suggest that as a better cutoff. I think often, as humans, we're bad at grasping what big numbers mean, so here's a way to look at it: How would we feel if an unconfirmed or IP editor decided to rapidly make 500 similar edits to a set of pages? Even if they were good faith, I think the response would be (ideally a friendly version of) "woah, slow down a bit, take some time to get acquainted with things around here before doing something that substantial". That isn't quite analogous to editing a template with 500 transclusions since the latter is more easily reverted, but still, we're talking about the same impact, and it should come with a similar level of restriction to prevent disruption. ((u|Sdkb)) ^talk 04:41, 17 August 2021 (UTC)
• I support these measures and also feel that the 3000-threshold should be lowered. Schwede66 04:56, 17 August 2021 (UTC)
• Yes, absolutely. I'm not seeing a significant downside here. If we have pages we're reluctant to use TP on, this is a good compromise. As with Schwede66 above, I would support lowering the threshold. Vanamonde (Talk) 06:26, 17 August 2021 (UTC)
• Support pre-emptive ECP at whatever threshold is deemed appropriate within the 4-digit range. ECP is widely available, so this should not be a significant block on updates. If such a change would allow for an increase in the Template protected threshold, so much the better as that remains quite an exclusive right. CMD (talk) 09:33, 17 August 2021 (UTC)
• Yes; I would even put the threshold for ECP a little lower, tbh, to around >1500. Thanks for the hard work, MusikAnimal. Lectonar (talk) 10:02, 17 August 2021 (UTC)
• No, there was an RfC prohibiting the use of EC here, for good reasons (like EC doesn’t correlate well with template writing ability). Wikipedia:Requests for comment/Extended confirmed protection policy 2. At minimum there should be another RfC on this, rather than an AN discussion. The thresholds of EC are ridiculous anyway, and it’s overly prohibitive in the topic areas on which it’s blanket applied ProcrastinatingReader (talk) 10:11, 17 August 2021 (UTC)
  • Also, would non-EC TEs now also need EC to edit ‘less high visibility’ templates?
    I’d be more happy with this proposal if EC could be granted at WP:PERM, so editors with less than 500 edits can request the perm if they have a need to edit one of these templates. ProcrastinatingReader (talk) 10:27, 17 August 2021 (UTC)

    "EC doesn’t correlate well with template writing ability" - It's not the correlation to template writing which is the issue. Some vandals, as yesterday's episode proved, are quite adept. The key is that EC has some correlation to a common investment in the Wiki. Cabayi (talk) 10:33, 17 August 2021 (UTC)

    It goes over the top. It may well exclude all vandals, but it excludes legitimate editors too. One editor adding Nazi symbols shouldn’t cause us to knee-jerk stop the thousands who edit them productively. Let them request it at WP:PERM. ProcrastinatingReader (talk) 10:35, 17 August 2021 (UTC)

    I'd like to see some actual examples of editors who would be shut out and bitten by this. As a general rule of them, somebody with less than 30 days' tenure and 500 edits is only interested in writing articles or improving content. The back end work of templates is only of interest to experienced editors who've been around the block a bit. Ritchie333 ^{(talk) (cont)} 10:42, 17 August 2021 (UTC)

    There's not really a roadmap like that. Some editors only do anti-vandalism, some editors only write templates, some editors only write content, some do a mix of them all. I think we can all think of editors in each of these groups. I'd have been shut out by this, if I didn't happen to have my account registered earlier than I actually started editing. If I registered slightly later, would I have been any more of a vandal?

    Also it only just occurs to me... The two things that fix this Nazi issue are: 1) the protection bot not skipping already-protected pages, which is critical; 2) the change to the filter MusikAnimal applied. Those two things have already been done. It's not clear what this third change is preventing. The current config TE-protects >5000. This is proposing changing that to 8000-10000, and doing ECP for >5000. So... we're proposing letting more editors edit through the protection? ProcrastinatingReader (talk) 11:05, 17 August 2021 (UTC)

    Agreed with Ritchie. Additionally, anyone who cannot edit a template directly can always make an edit request on its talk page. Doing that from the view source page is not hard (and if someone finds it hard...maybe they aren't ready to be editing templates yet). ((u|Sdkb)) ^talk 11:06, 17 August 2021 (UTC)

    I remember before I had the TE perm it was pretty frustrating having to make edit requests. Anything more complex takes ages to get reviewed, or just doesn't get reviewed, because someone else (likely someone unfamiliar with the template) has to take responsibility for the code being functioning and fairly representing consensus, which sucks up so much time even reviewing them. I suspect that'll be less-so for ECP, since a lot more editors have the perm, but at the same time only a subset of ECP editors will review requests to edit templates (likely the same subset as those who are TEs, so similar numbers). There's also various changes one wouldn't want to approve but also wouldn't revert, and those are all incremental improvements. I don't think being able to edit a sandbox and request an edit is a replacement for being able to edit directly. ProcrastinatingReader (talk) 11:21, 17 August 2021 (UTC)

    ProcrastinatingReader, [a]lso, would non-EC TEs now also need EC to edit ‘less high visibility’ templates. I honestly cannot see a case where someone gets TPE before becoming extended-confirmed. firefly ( t · c ) 11:24, 17 August 2021 (UTC)

    Firefly, Well I suppose a sock of a banned editor might want to give it a go, but hopefully they'd be spotted. :-) Ritchie333 ^{(talk) (cont)} 11:52, 17 August 2021 (UTC)

    Ritchie333, indeed, I can understand that people might request it but as you say I doubt it'd actually be granted absent exceptional circumstances! firefly ( t · c ) 13:18, 17 August 2021 (UTC)

    @ProcrastinatingReader To be clear, you can request EC at WP:PERM/EC. Also remember this isn't about template writing ability, it's about guarding highly visible templates from disruption. Many of these templates require no template editing skills whatsoever, but any intentional vandalism will have far-reaching effects. Right now we go from semi to template protection, which is quite a big jump. It'd be nice to have an in between in there. The 2016 RfC also predates the many waves of template vandalism we've had. I do not believe the points raised there have merit today, which is why many admins, myself included, have continued to use ECP on templates when it made sense to do so (high number of transclusions, but the regular editors are not TEs). I don't have the time or energy for another RfC, so if we feel that is needed, someone else will have to spearhead that effort. — MusikAnimal ^talk 15:37, 17 August 2021 (UTC)

    People can request it for alt accounts. All other requests are denied. So I don’t think it really counts. As I understand, the change you made to your bot would’ve prevented this Nazi issue, as it has 55k transclusions, so I don’t see the need for even more layers of pre-emptive protections when the problem has already been patched. The only other reasonable idea is to TE protect, in addition to the automatic protections, any simple template that realistically does not need to be changed. (eg a hypothetical 1k transclusions variant of Template:Wbr.) But EC protecting basically anything meaningful in the template space seems overkill. ProcrastinatingReader (talk) 15:46, 17 August 2021 (UTC)

    WP:PERM/EC's banner leaves the door open for granting the perm to non-alt accounts in rare circumstances; and even if it didn't, WP:IAR does. If there were a situation where it would clearly benefit the encyclopedia for a non-EC editor to start editing ECP templates, it would be within standard administrative discretion to grant them the perm. I do know of at least one newer user who was offered EC for merit by several admins and declined. (An eon ago in 2012, I was given confirmed at the 3-day mark and rollback at the 13-day mark; that probably doesn't happen anymore.) -- Tamzin^{[cetacean needed]} (she/they) 18:00, 17 August 2021 (UTC)

    @Tamzin: Can you link me a successful EC request by a non-EC editor (with no EC alts, and not a case of ECP being granted after it was initially pulled for gaming the system)? Ideally in the past year or two. ProcrastinatingReader (talk) 18:15, 17 August 2021 (UTC)

    Looking back a few months I don't see any, but that's not my point. My point is that it's allowed by policy, and in a scenario where a good-faith new user starts flooding the system with edit requests for ECP'd templates, any admin has the authority to grant them the bit. It's just that that's a rather unlikely scenario to occur. Under the current use cases for ECP, on the other hand, it's hard to think of a need-based reason to grant the bit, especially since, IIRC, granting ECP to a not-usually-eligible editor doesn't exempt them from DS/GS 30/500 sanctions. -- Tamzin^{[cetacean needed]} (she/they) 18:34, 17 August 2021 (UTC)

    @ProcrastinatingReader: I'm not going to go dig through my logs, but I have rarely given out ECP early, think it was related to a well established editor on another project wanting to do content translation here. It came with a strong reminder that it does not override the 500/30 arbcom remedies that they should now take extra care to avoid. — xaosflux ^Talk 19:00, 17 August 2021 (UTC)

• The more important decision is to let the bot re-assess templates which have already been protected. Semi protection on a template which has crept up to 10 times the threshold for TE protection is a major red flag (without any embellishment). Cabayi (talk) 10:24, 17 August 2021 (UTC)
• Oppose for all the reasons ProcrastinatingReader raised. I think Cabayi's idea is a good one, though. Jo-Jo Eumerus (talk) 10:31, 17 August 2021 (UTC)
• Support increasing the preemptive usage for security reasons, and also encouraging editors to get more involved with Template editing practices in general. Not discussed here, but of inverse concern are lightly transcluded templates, that are added to several popular pages, but I don't have a policy change for that. Shushugah (he/him • talk) 10:30, 17 August 2021 (UTC)
• Comment: does anyone know how long the disruption yesterday actually went on for? It seems to me that a large part of the problem is that vandalism can be undone on the template within 5 minutes but may not quickly propagate to all of the pages it's transcluded on for caching reasons. Anyone can manually purge a page but is there a tool to automatically purge all pages in a particular category or list (here, the list of transclusions)? If not, can one be created or does that open us up to some denial of service attack?
  If vandalism like this can be undone in 5 minutes then I will likely oppose an increase in stringency, but if there's no other way to stop a repeat of yesterday then I'll likely support it. Notice that all we needed to stop this attack was the MusikBox elevation fix (which I completely support). — Bilorv (talk) 15:39, 17 August 2021 (UTC)

  Yes, User:ProcBot/PurgeList. But I’m pretty sure the software’s job queue does normal page purges pretty quickly/immediately, it’s just certain types that take longer (those types are not applicable here). ProcrastinatingReader (talk) 15:48, 17 August 2021 (UTC)

  Okay, so was it really just a few minutes or so (5? 10? 20?) that the vandalism yesterday was up for? Also, just spitballing, but has anyone considered some method of bot protection that gets to the root cause of the aim of this vandalism—to damage highly-viewed pages? A vandal wouldn't do this on 50,000 less-than-a-view-per-day non-mainspace pages, I would guess. We could have a cascading protection like we use for the main page but on a lower scale, applied by bot to anything with above X views in the last month. Just interested in the feasibility. — Bilorv (talk) 16:06, 17 August 2021 (UTC)

  Fucking magnets, how do they work? El_C 22:49, 17 August 2021 (UTC)

  @Bilorv: I suspect, after the change was reverted, that propagated to the pages within a minute. (It would take my bot 1 minute to purge 55k pages; job queue is currently not backlogged, and rarely is, if the statistics are accurate.) As for your idea, it sounds feasible. One possible approach: WMF provides this data dump that can be used. Using that, one can bulk fetch the templates used by each page above X pageviews and then sum it all up. ProcrastinatingReader (talk) 14:07, 18 August 2021 (UTC)

  Yes Bilorv, it was 5 minutes to fix (well done those who were on the ball). It was also 15+ emails to WP:VRT and at least one press enquiry (just counting the ones I saw & handled myself), 2+ press reports, and the reputational damage to Wikipedia. The loss of 5 minutes effort was the least of the damage. Cabayi (talk) 09:51, 18 August 2021 (UTC)

• Support. Good stuff, MusikAnimal. Make sure to give the bot extra treats. El_C 17:06, 17 August 2021 (UTC)
• An update to our protection policy is an action for an advertised WP:RFC at an appropriate location. WP:AN is not that location. --Izno (talk) 19:19, 17 August 2021 (UTC)
• Support and I'm frankly surprised this wasn't already done. Arguments about how this might bite new template editors aren't compelling: you can be patient and get your 500 edits! It's not hard! Further, we should do what we can to minimize harm done to readers and our subjects (especially BLP pages); "accidentally" suggesting that someone is a Nazi in a BLP seems like a bright line we shouldn't be crossing - or even provide the road that could be used to cross it. Jorm (talk) 19:33, 17 August 2021 (UTC)
• Support. If they'd done this on some template that is used on fewer, it probably wouldn't have been caught for much longer. I get that this means there are some people who could make positive direct contributions and instead for a short time will have to make edit requests, but that's true for many articles, and those are single articles. —valereee (talk) 21:11, 17 August 2021 (UTC)
• Support reasonable actions to make it harder to vandalize thousands of our most highly viewed pages in a few mouseclicks. Unprotected templates transcluded into huge numbers of highly salient pages, especially BLPs, make mass-scale vandalism ridiculously too easy and common. - Astrophobe (talk) 21:31, 17 August 2021 (UTC)
• Support this makes sense. Also support lowering the threshold for ECP to 3000 pages (or even lower). Jake Wartenberg (talk) 21:38, 17 August 2021 (UTC)
• ’’’Support’’’ templates are highly visible so the impact of vandalism / test edits / not understanding template workings/code or formatting is high. I support lower thresholds for this reason: eg > 100 transclusions for autoconfirmed > 250 for EC and > 1000 for TE. Tom (LT) (talk) 22:00, 17 August 2021 (UTC)
• Support. Our long-standing policy on High-risk templates (and it is a policy despite its guideline tag) pre-dates the EC policy by a long way. I'm never a fan of specifying exact thresholds for these things, but should we use EC for high-risk templates where appropriate? Sure. -- zzuuzz ^(talk) 22:18, 17 August 2021 (UTC)
• Support protection, regardless of whether we classify it as ECP. Regarding "high-risk", I'd go so far as to say that the template namespace should be protected by default, with a whitelist to allow editing e.g. DYK nominations. Has anyone ever seen a new user make meaningful positive contributions to any template such that it wouldn't be better handled through a protected edit request? — Rhododendrites ^talk \\ 22:35, 17 August 2021 (UTC)
  • Oh, lots. Some templates are maintained almost entirely by anons - notably sports templates but also many other types. To get some idea of the massive backlogs and content deficit that would create, take a look at recent changes. -- zzuuzz ^(talk) 22:46, 17 August 2021 (UTC)

    I agree that protecting the entire template space would be a significant change and that it's not unusual for templates such as sports season standings to be updated productively by new or unregistered editors. Plus since transclusion from any namespace is permitted, editors would just start putting more templates into project space. isaacl (talk) 23:14, 17 August 2021 (UTC)

    It might be worth having an edit filter that watches for new images being added to templates by non-EC editors. If we can't restrict access to the whole namespace we can at least make oversight easier. I'll run it over to WP:EFN. — Wug·a·po·des​ 00:30, 18 August 2021 (UTC)

    Thanks for the link. I guess they're just not in any of the topic areas I watch. — Rhododendrites ^talk \\ 19:02, 18 August 2021 (UTC)

• Support, especially for content templates like ((Color topics)) where template-protection may unduly interfere with productive revisions. That template has 233 transclusions in mainspace, just short of the proposed EC cutoff proposed by Tom (LT). –LaundryPizza03 (dc̄) 01:16, 18 August 2021 (UTC)
• Support for so many reasons it would take all day to list them. Worthwhile, though, to verify that the template editor permission will allow editing of ECP-protected templates. There may be occasional rare exceptions where this is warranted. Risker (talk) 02:42, 18 August 2021 (UTC)
• Support This is the only viable alternative to more extensive use of full protection. I think however that admins will need to be reminded they can grant EC. I had forgotten until I saw this here. DGG ( talk ) 03:24, 18 August 2021 (UTC)
• Support as there is a clear need for templates with more than auto-confirmed and less than template-editor protection. The language Extended confirmed protection should not be used as a preemptive measure against disruption that has not yet occurred should be removed from the ECP policy page. User:力 (power~enwiki, π, ν) 03:54, 18 August 2021 (UTC)
• Support - as a very reasonable compromise between semi-protection, and TPE protection (which it seems would impose barriers to some content templates being updated). I am also very glad to see that MusikBot II will now raise protection levels as transclusion counts increase, given the performance issues have been elided. Nice work MusikAnimal :) firefly ( t · c ) 06:24, 18 August 2021 (UTC)
• Support I have long supported this and believe it could have a significant impact on reducing template vandalism while minimizing the harm for legitimate users. --Trialpears (talk) 08:39, 18 August 2021 (UTC)
• Support the introduction of ECP as an extra level in protecting templates. Oppose the increase in threshold for TE protection. Support the bot re-assessing previously assessed templates. Noting the need for the bot to respect manual adjustments to the protection, preferably it would flag up somewhere (pinging the adjusting admin) that the protection level is out of sync with the norm. Also noting that many sensitive templates are substed & that the transclusion numbers are not the whole story. Cabayi (talk) 09:57, 18 August 2021 (UTC)
• Support per above. ― Qwerfjkltalk 10:06, 18 August 2021 (UTC)
• Pile on support per above.--John Cline (talk) 13:21, 18 August 2021 (UTC)
• Oppose - I realize I'm coming to this late and it's already snowing, but hear me out. ECP is a game-able protection level - it takes a more dedicated vandal to game it but trust from my experience at SPI that it's very little deterrent over semi, and with templates the payoff is having your vandalism immediately appear in maybe tens of thousands of articles all at once. Plus, the disruption you cause still produces ANI complaints three days later and serious reactions like this proposal here with widespread ramifications. In exchange for 500 nonsense edits (or one edit plus a script that clicks undo 499 times over a few days) and a 30 day hold (set a reminder in your calendar), this would've been a pretty sweet deal for our recent Nazi vandal. On the other hand, template protection secures high-risk templates to only editors who have been vetted by other members of the community, which is a process that's far more difficult to game. If template vandalism is becoming a widespread problem (I would argue it has been for quite some time already) then we should consider some form of pending changes protection for templates that appear in article space. Ivanvector's squirrel (^trees/_nuts) 13:55, 18 August 2021 (UTC)
  • If I understand correctly (in no way a given!), this proposal is whether to allow ECP on templates, with the specific levels to be determined later. On re-reading the proposal it seems that the example given would indeed lower the protection of some templates - which I would disagree with were it proposed formally. I'd probably suggest keeping the current thresholds and then inserting another at 2500 transclusions for ECP. MusikAnimal - thoughts? :) firefly ( t · c ) 14:45, 18 August 2021 (UTC)

    Yes, we will decide on adjustments to the thresholds in a separate discussion (I don't think that requires an RfC). Regardless, even if the bot doesn't use ECP, I would still like to see use of it in preemptive fashion written in our policy. As noted above, Template:Australian politics/party colours is a prime example, given the usual template editor protection would have shut out all editors. — MusikAnimal ^talk 16:13, 18 August 2021 (UTC)

    • Agreed, and I assumed as much. Thanks! firefly ( t · c ) 16:46, 18 August 2021 (UTC)

• Support. It seems like it would be sensible to have another level of protection available here, since the two current options are basically "everyone can edit" and "only administrators + a very small number of users can edit". Yes, of course it is possible to game the EC permission, but I don't see how restricting ourselves to a permission that is even easier to game is the right solution. 192.76.8.74 (talk) 21:28, 18 August 2021 (UTC)
• Support. This seems reasonable, especially if it helps to prevent the mass vandalism we saw yesterday. Clovermoss (talk) 22:29, 18 August 2021 (UTC)
• Support entirely reasonable proposal.-- Jezebel's Ponyo^{bons mots} 16:38, 19 August 2021 (UTC)
• Support. This proposal could enable us to reduce template vandalism, even if it doesn't eliminate it. And anything that reduces vandalism is still worth doing, per the nirvana fallacy.— Shibbolethink ^{(♔ ♕)} 15:31, 22 August 2021 (UTC)
• Support adding ECP as an intermediary step, but Oppose raising the 5000 transclusion threshold for TEP. I think something like the 250/2500/5000 proposed above would make more sense than lowering the protection levels on highly-used templates. --Ahecht (TALK
  PAGE) 21:30, 23 August 2021 (UTC)
• Support Making ten edits and waiting four days? Easy. Making five hundred edits and waiting thirty days? Not so much. 🐔 Chicdat  ^{Bawk to me!} 10:31, 24 August 2021 (UTC)
• Support — As for Ivanvector's oppose, I think that instead of lowering the threshold for template protection, this should mainly be used for templates that are currently semi-protected but are high-risk enough to warrant extended-confirmed protection. Tol (talk | contribs) @ 20:25, 1 September 2021 (UTC)
• Support with a certain transclusion count or otherwise high risk such as the template appears on controversial or popular topics. Crouch, Swale (talk) 20:51, 3 September 2021 (UTC)

  Support: Could be useful as another option for those templates in a dead zone of high use; too highly used to use semi, but not high enough to necessarily use template protection. Regards, User:TheDragonFire300. (Contact me | Contributions). 21:44, 3 September 2021 (UTC)

Discussion (ECP & templates)

• I was just about to ask someone close this, because I don't have the stomach for a proper RfC, but it looks like we're doing it anyway! For those of you who are just now seeing this thread: This started as an update about the bot I maintain, in response to a recent vandalism incident. I was gauging interest on using ECP, as many of the articles that would have been raised to template protection by the bot seemed to call for it. So anyway, for the purposes of this RfC, !voters can ignore all the proposals regarding the bot such as what thresholds we will use. That can be ironed out later once consensus for the use of ECP is established. Thanks, — MusikAnimal ^talk 21:20, 17 August 2021 (UTC)

  Thanks for the clarification. I was about to say essentially what you said about dealing separately with any changes to the bot. I have a personal bias that appreciates having a step between semi-protected and template-editor protected, so this may be hindering me from evaluating the downside of using extended-confirmed protection. (There is a module I wrote, before the template editor role existed, that later got template-editor protected; an admin kindly lowered it and the corresponding template to semi-protected so I could continue to support it as needed. I know it could get raised back to template-editor protected any time and then I'd have to rely on edit requests. It's not a huge deal and changes are infrequent, but it's a potential future impediment.) isaacl (talk) 21:37, 17 August 2021 (UTC)

• Comment - although ECP is certainly a lot safer than semi-protection, it's still something a dedicated vandal could overcome without anyone else needing to cast eyes on them. Signing up a new account, doing 500 edits, and waiting 30 days, is not beyond the realm of imagination. Wouldn't it be better for us to use template protection for these high-visibility templates? Obviously this will cause irritation for other legitimate users wishing to make tweaks to those, but I think that's a better solution than risking the 16 August fiasco again.  — Amakuru (talk) 08:14, 18 August 2021 (UTC)

  Some vandals might go to that extent - we always see it elsewhere - although it is definitely a significant barrier. Many will be caught on their way to EC, but some will get there. At least we might get a few typos fixed in the process. We've previously had administrators who are mass sockpuppeteers and some who have deleted the main page, so nothing will ever be perfect. It's just a matter of getting the cost/benefit balance right, and this proposal gives us an extra option to do that. -- zzuuzz ^(talk) 09:02, 18 August 2021 (UTC)

• Please excuse me if I've missed some discussion, I haven't read everything related to this incident. I know MusikBOT doesn't escalate protections to avoid the bot overriding admins delibretly setting a lower protection level. Wouldn't it make more sense to control these cases using the ((bots)) template to prevent the bot from changing it in those cases? --Trialpears (talk) 08:34, 18 August 2021 (UTC)

  By "using the template", I'm assuming you mean ((bots))? I don't think this task should be exclusion compliant in this way because a vandal could also do this to prevent it from being protected, say right before they transclude it into a much more visible template (which should also be automatically protected, but for the sake of the argument let's pretend that's not the case). The bot only ignores pages with recent page protection changes in the past 7 days, according to the ignore_offset option in the User:MusikBot II/TemplateProtector/config. We don't want this to last for eternity because humans won't bother to go back and check that a template with just 500 transclusions now has several million. Humans forget, the bot will not :) However admins can also explicitly exclude specific pages via the config, so there's still a means to make the bot ignore a template. — MusikAnimal ^talk 15:53, 18 August 2021 (UTC)

  That's indeed the template, just forgot the ((t)). You're probably right about the bot being exclusion complaint isn't a great idea, but your config solution seems sufficient. The ignore offset of 7 days also seems find, but then why didn't it escalate protection at ((wbr)) and others mentioned in related discussions. --Trialpears (talk) 21:31, 18 August 2021 (UTC)

  Up until yesterday, the bot only acted on templates that were completely unprotected. Now it will escalate from semi to template editor in accordance with the configuration. The technical means to do this was only made possible some months ago. So while the bot came too late to the rescue in this case, we should at least be glad our new database replicas are fast enough to make this functionality possible :) — MusikAnimal ^talk 03:37, 19 August 2021 (UTC)

  I appreciate the desire to review the transclusion count periodically, but am not sure if a seven-day minimum period is long enough. For bot-set protection, it doesn't matter, but if an admin set the protection level, surely they considered the future potential usage of the template for more than the next week? isaacl (talk) 20:17, 19 August 2021 (UTC)

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

According to the current tally, the number of articles with link rot issues slowly but steadily approaches the 300K mark. Even though that's less than 5% of the English Wikipedia and mostly we deal with articles that have most of the citations being all right, I believe that becomes quite a problem when we have articles referenced to a page which can't be found on any archive, and in particular favts referenced to that source. The info, in that case, might require update, deletion (based on WP:V or WP:BLP concerns) or simply we might need to change the link in the reference, none of which can be handled by bots alone. This is also an area which seems not to be particularly touched by Wikipedia editors in general, as this is simply routine maintenance of encyclopedia instead of badges/honors connected with the more pleasant parts.

Since this is my first post at Village Pump, please assure me this is the proper venue for that proposal (or else redirect me to another forum), and, of course, I'd like to hear your opinions on it. Szmenderowiecki (talk) 14:40, 3 September 2021 (UTC)

Thanks for the idea, Szmenderowiecki! This village pump is used for proposals like this all the time, so you're at the proper venue. Resolving link rot is certainly a plus, so anyone who helps resolve it is doing good. I wouldn't say it's our most urgent backlog, though, as it's less severe than ((Citation needed)) (dead references at least likely supported the material, even if they're no longer verifiable, whereas citation needed references mark totally unsupported material) and we're never going to get through the citation needed backlog without radically increasing the number of editors.

One thing I'm wondering is where the more recently tagged instances of link rot are coming from, as Internet Archive is theoretically supposed to be archiving every outgoing link from Wikipedia. Are they old links from before IA was doing that, or editors mistaking links as permanently dead when actually they're available through IA, or is IA failing to capture everything? ((u|Sdkb)) ^talk 18:55, 3 September 2021 (UTC)

Probably all those things. Systematic saving of links at Wayback and Archive.today wasn't done prior to about 2012. Current save methods are not 100% for a couple reasons. Some percentage of ((dead link)) tags are resolvable but a bot or person has not done so yet. IMO a bigger problem is false negatives ie. links that are dead but not marked or being saved by the bots due to soft-404s and other issues. The methods we are using are problematic. The solution is every link is born archived ie. the archive URL is part of the rendered page automatically, no bots. -- GreenC 19:37, 3 September 2021 (UTC)

It seems to be the former case (as a lot of these are from 2007-2012, which is why it is often hard to find them; some are apparently cited in 2013 and dead (for example here), while this article describes a 2015 Spanish film, and yet the official website is dead and the link rot tag is there.

as Internet Archive is theoretically supposed to be archiving every outgoing link from Wikipedia but it isn't doing so automatically. At least the references in this article stay unarchived for two months or so (though to be honest, IA bot has gone once or twice through the page when the heat wave was in the news).

IMO a bigger problem is false negatives ie. links that are dead but not marked or being saved by the bots due to soft-404s and other issues. I haven't really encountered that problem at the time I was doing that on a sample of some 20-30 articles; and anyway we can't recognise it until we actually get to the page and check both the URL and archive, which can only be done by a person.

As for "citation needed" backlog, this one is going to be way more difficult than dead links, because the latter will just involve checking the page against its archived versions (or copying the title), while in the former, we would actually have to find the information, which often is difficult and involves several languages. I mean, the anti-link rot drive is a quicker fix (though admittedly not so fundamental).

The solution is every link is born archived ie. the archive URL is part of the rendered page automatically, no bots. You mean that we should automatically send queries of whatever links we submit to Wikipedia to IA, and then added to the citations? Sounds pretty cool, but that's hell of a load on IA's servers. Szmenderowiecki (talk) 01:30, 4 September 2021 (UTC)

"Sending every link.. we submit to Wikipedia to IA" is what Internet Archive does see Wikipedia:Link_rot#Automatic_archiving. To give a sense of scale, Wikipedia has about 100-200 million unique URLs in about 500 sites; Wayback machine has archived over 107 billion web pages. The false negative problem is not anecdotal, it can be extrapolated based on a decent size data set. It's not a wild guess to suggest there are many more than 300k articles containing silent dead links. For an example of links born archived, see frwiki - not recommending that solution, but is an example of how things can be done differently. -- GreenC 18:58, 4 September 2021 (UTC)

That's all the more reasons to initiate such drive in this case. Szmenderowiecki (talk) 06:47, 5 September 2021 (UTC)

There are also some problems with internal link rot that are worth considering as well. We have redirects (some categorized by ((r to section)) and ((r to anchor))) which point to particular sections of articles that no longer exist or changed their name. These take you to the article, but sometimes the proper section or information can be hard to find. — Wug·a·po·des​ 20:59, 7 September 2021 (UTC)

Requirement of 2 votes for template deletion. I understand most experienced editors avoid deletion talks like a plague ....but...Think we need a basic number of votes for template deletion. As of now we have many templates deleted by 1 vote...in many cases that 1 vote is by an editor here editing for only a year or so.--Moxy- 20:03, 30 August 2021 (UTC)

Bad idea. A ton of TfDs are rubber stamping following cleanups like migrations of rail templates to Module:Adjacent stations. Sometimes they have no participation but it's obvious to a closer how they'll go, given years of precedent. Closers are qualified to evaluate how contentious a deletion is likely to be. Same principle applies at AfD (see WP:SOFTDELETE). Is there actually any evidence of a problem here, such as links to DRVs showing TfDs closed in this manner reached incorrect decisions and thus were overturned? ProcrastinatingReader (talk) 20:09, 30 August 2021 (UTC)

Correct as per WP:NPASR...just to bad that area of Wikipedia does not have better oversite....one day one can hope for better.Moxy- 00:58, 31 August 2021 (UTC)

Agree with proc. A lot of TfDs don't get any votes, and like AfD and RfD, those can be deleted after a week. Of course, I think most admins would be willing to undelete upon request if the consensus is very weak. Elli (talk | contribs) 20:12, 30 August 2021 (UTC)

Proc said it well. A ton of TfDs are completely uncontroversial with many similar deletions occurring in the past with more discussion. These are often unused and not used on hundreds or thousands of pages like most of the templates that editors know about. If you have concrete TfDs you have issues with I'm sure the regulars are willing to discuss or change as appropriate. While there are a lot of problems with having a quite small pool of closers it does make changing norms a lot easier. --Trialpears (talk) 20:28, 30 August 2021 (UTC)

• Oppose. Agree with Proc's analysis of the situation. Also, strictly speaking, there are no votes in deletion discussions. Editors make recommendations, and the closing party decides based on quality of arguments as well as quantity. —C.Fred (talk) 20:32, 30 August 2021 (UTC)
• Oppose per Proc. ((u|Sdkb)) ^talk 00:48, 31 August 2021 (UTC)
• Oppose I guess per above. It the closers are admins, they're probably pretty good at figuring it out. Just treat it like a PROD I guess... somebody nominated it, nobody objected after a fair amount of time, the admin can deleted BUT use her discretion not to, and anyway yea undelete upon request in a case like that. I guess. Herostratus (talk) 00:47, 3 September 2021 (UTC)
• Oh no, all these editors editing for only a year or so, what could we possibly do about them? Oppose: no demonstrated benefit; current guidelines like WP:SOFTDELETE linked above can handle the job well enough in my experience. ~~~~
  User:1234qwer1234qwer4 (talk) 17:44, 8 September 2021 (UTC)

It's very obvious that these two options would make the mobile version of Wikipedia more user-friendly. Interstellarity (talk) 16:31, 1 September 2021 (UTC)

• Support as nom. Interstellarity (talk) 16:31, 1 September 2021 (UTC)
• Would the proposed “contact us” button link to the article’s talk page, or are you proposing something different? Blueboar (talk) 16:47, 1 September 2021 (UTC)
• Wikipedia:Growth_Team_features#Help_panel is already being developed. If you're talking about the mobile left sidebar, that could probably benefit from some broader discussion. ((u|Sdkb)) ^talk 16:57, 1 September 2021 (UTC)
  • I've found that newbies make good use of the growth team features for essentially this purpose. I agree we should look into expanding its use if possible. — Wug·a·po·des​ 20:28, 1 September 2021 (UTC)
• ? @Interstellarity: which mobile view (please be specific)? What do you propose the target of these be? Is this something that we, the English Wikipedia editors, can technically implement? — xaosflux ^Talk 17:56, 1 September 2021 (UTC)
• Hi all,

The proposed contact us link would link to Wikipedia:Contact us and the help link would like to Help:Contents. In the mobile sidebar (the image to the right), I think both links are best placed next to the About Wikipedia and Disclaimers link. I'm not sure if it can be technically implemented by English Wikipedia editors, but I hope I provided enough information on this in detail. Interstellarity (talk) 18:19, 1 September 2021 (UTC)

There does not appear to be anywhere for us to do this locally, you could start by inquiring with the mobilefrontend developers to see if: (a) project-specific sidebar links could be supported here such as they are on the webui; (b) possibly if project specific parameters would be supported here; (c) if this is something they would want to incorporate in to the master extension. — xaosflux ^Talk 18:53, 1 September 2021 (UTC)

@Xaosflux: Could you provide the contact information for the people responsible for developing the mobile interface? That would help a lot. Thanks, Interstellarity (talk) 18:54, 6 September 2021 (UTC)

@Interstellarity: like most things, it is supported by the developer community. The workboard for this is here. @Fuzheado: is listed on that project and may have more information. — xaosflux ^Talk 19:17, 6 September 2021 (UTC)

Hmm.. not sure what you're referring to in terms of me being listed on a project? Fuzheado | Talk 00:25, 7 September 2021 (UTC)

@Fuzheado: click here you are actually listed as the only member of the "Mobile" project. I'm assuming phab project management is a sloppy mess now though! — xaosflux ^Talk 02:44, 7 September 2021 (UTC)

@SGrabarczuk (WMF), I think this idea might be mostly for Olga's team? Whatamidoing (WMF) (talk) 19:17, 9 September 2021 (UTC)

Also here is the MobileFrontend project listing. — xaosflux ^Talk 02:45, 7 September 2021 (UTC)

Would editors have any way of replying to such a contact? The most valuable part of this development could be a way around WP:THEYCANTHEARYOU. Certes (talk) 19:06, 6 September 2021 (UTC)

Interstellarity is proposing the addition of a prominent link to Wikipedia:Contact us, which recommends boldly editing articles, posting at the Teahouse, sending e-mail to the Wikipedia:Volunteer Response Team, and several other things. Most Wikipedia editors would be able to reply to some of those but would not see others. Whatamidoing (WMF) (talk) 19:20, 9 September 2021 (UTC)

So... I been seeing a lot of massively-viewed articles without a protection, due to it being expired. Should we start discussing the idea of an auto-protect bot for articles that get over 250K views a day, and depending on size like is it a B class or GA class, should it be protected. It will help most of the CVU/AVU jobs. MoonlightVector 16:21, 7 September 2021 (UTC)

You are seeing unprotected pages with lots of views because this is the encyclopedia that anyone can edit. Unless there are specific and persistent problems that cannot be solved by any other tool except protection, we should not prohibit thousands of people from engaging in the one thing that sets us apart from every other website (see WP:NOPREEMPT). If there are particular pages that counter-vandalism patrollers notice are being persistently disrupted, regardless of page view stats, protection can be requested at requests for page protection where a human will review the best tools to stop the disruption. — Wug·a·po·des​ 20:04, 7 September 2021 (UTC)

This has very little chance of passing, even with a very conservative threshold, but I wish we wouldn't dismiss it out of hand so quickly. We recently had a very acute lesson in what can happen when we wait to see if vandalism occurs rather than acting preemptively. There's not a huge difference in pageviews between a template that appears on 500 smallish articles and a single extremely high-visibility article. I would be interested to see a (hopefully non-public; feel free to email me) list of the unprotected pages with the most pageviews. There's good reasoning behind our founding-era principles, but at this point they're 20 years old and they're not gospel, so we shouldn't be afraid to re-examine them as needed. ((u|Sdkb)) ^talk 21:10, 7 September 2021 (UTC)

@Sdkb, while there might not be a huge difference in pageviews between a template that appears on 500 smallish articles and a single extremely high-visibility article, it is much more common for templates to use more complicated wikisyntax than for articles, so the protection likely prevents widespread damage from unsuccessful good-faith "fixes" by unexperienced editors and not just vandalism. Sure, this can (and does) of course as well happen to articles, but again, these usually have more simple syntax (and afaik the VisualEditor is now the standard option?) ~~~~
User:1234qwer1234qwer4 (talk) 15:43, 8 September 2021 (UTC)

Indeed, the reason for protecting templates isn't page views, it's the technical aspects of how templates work. The harm of good-faith-but-incorrect edits is a major reason, but the damage caused by bad faith edits to templates can persist even after a revert because of how pages are parsed and served to readers. Rather than processing each page every time a reader requests it from the server, we cache them. An edit always invalidates the cache, forcing a re-render of the content. Most vandalism is reverted quickly if it even gets past filters, and since the edit purges the cache the vandalism immediately disappears. This is not true for templates. Because updates to templates can invalidate millions of caches, any update to a template is slowly rolled out across pages that use it. So no matter how quickly vandalism to a template gets reverted, it can stay up on articles for potentially hours after the revert, until the cache gets updated. These are vastly different levels of damage, and the idea that preemptive template protection is the same as preemptive article protection only makes sense if you don't dig into the specifics of how these attacks work. Vandalism to a template used on many small articles can easily have much greater consequences than vandalism to a single highly visible article.

@Sdkb: It may seem like I'm dismissing the idea out of hand, but I'm not interested in giving multi-paragraph responses every couple of weeks on substantially the same topic, and even less interested when the proposals show no understanding of our policies or the dozens of substantially similar proposals in our archives; the most recent discussion on preemptive protection on this board closed less than a week ago, and the one before closed less than two weeks ago after lasting two months. Compare those two most recent proposals to this one and consider why I was more willing to engage with them seriously. I spent part of yesterday updating our protection policy and an explanatory supplement to reflect the most recent discussion, so yes, I'm not keen to rewrite here what I already wrote at WP:PPOL and WP:HRT yesterday. If we are going to amend a foundational principle of the website and major clause of the protection policy, per the parable of Chesterton's fence I'd want a proposal that shows some understanding of the protection policy, or at least mentions it, before I support spending substantial volunteer time entertaining a perennial proposal. — Wug·a·po·des​ 21:27, 8 September 2021 (UTC)

@Wugapodes, that's fair. It doesn't look like we've added this to the WP:PERENNIAL list yet, which might be a good idea. When recently-discussed topics are raised, it's good to have easy access to a concise history with wikilinks. ((u|Sdkb)) ^talk 21:35, 8 September 2021 (UTC)

@Wugapodes, the fact that this is the encyclopedia that anyone can edit does not mean we should absolutely not install preemptive pending changes protections, which, while allowing everyone to edit an article, would make edits subject to a review before being displayed. I don't have any strong opinion on the issue, but I wanted to point out that the "protection" mentioned in the opening comment does not necessarily refer to a protection from editing. ~~~~
User:1234qwer1234qwer4 (talk) 15:55, 8 September 2021 (UTC)

I thought thatwe ecisevely rejected thatan idea in a vey well attended RfC afew yearsago. I don't see that we've beome any worse since then. (I sometimes think of editing deWP, but their pending change protection always causes me to go away.) DGG ( talk ) 06:35, 10 September 2021 (UTC)

Background

This is a proposal to expand the functionality of ((find sources)), a template frequently used in ((Talk header)) (example) to help editors find sources to improve articles. Specifically, we seek to make it possible for different sets of links to appear for different types of articles, such as links to medical sources for medical articles.

Currently, there are three four related templates that generate find sources links:

• ((find sources)), the basic set of sources starting with five Google links, plus JSTOR, NYT, and a couple more
• ((find video game sources)), which contains the basic set above, plus three more links targeted to video gaming
• ((find medical sources)), a completely different set of links aimed at supporting WP:MEDRS-compliant sourcing
• ((find biographical sources)), a set of links aimed at supporting biographies.

We anticipate that additional templates in this family for other subject areas may be created in the future. Under this proposal, talk header will choose between the available templates, either automatically or on the basis of a manually set parameter, to display the one most appropriate for a given page.

Approaches for selection

We are considering several possible approaches for how to select which set of links to use:

1. Through a new parameter that can be manually set (i.e. to display medical links at Talk:Giardiasis, we'd change ((talk header)) to ((talk header|search-domain=medical)) at that page)
2. Through auto-detection of WikiProject banners (i.e. Talk:Giardiasis would switch to using medical links because it includes the ((WikiProject Medicine)) banner)
3. Through auto-detection of Wikidata properties (i.e. Talk:Giardiasis would switch to using medical links because an automated analysis of its Wikidata item identifies it as a medical topic)

It would be possible to combine these approaches, such as implementing a combined option 2 – 1 approach, which in the case of ((Talk header)) would default to option 2 (project auto-detect) but would allow any editor to set a parameter (e.g., ((talk header|search-domain=medical))) which would then take precedence over the project auto-detect. Having the parameter available would also be extensible to use by other templates on article pages where project detection isn't applicable; see below.

Previous discussion is at Template talk:Talk header, and we have created functional prototypes of options 1 and 2 in the talk header sandbox, which can be seen at the associated test page. (Current sandbox revision uses method 2, so testcases for method 1 currently fail, but pass successfully with the correct sandbox revision in place.)

Which approach(es) would you prefer?

Design

We are considering implementation via a wrapper template (here) which does all the detection of search domain, and transcludes the correct flavor of template. By placing the wrapper template at the current title (Template:Find sources) and moving the old content to Template:Find general sources, this remains transparent at the top level; all current transclusions of Template:Find sources after the changeover will invoke the wrapper, which invokes ((Find general sources)) by default. Outside of the Talk header template, this means a seamless transition for all other transclusions which will do exactly the same thing after go-live as they did before; that is, they will continue to invoke the basic "Find sources" link set, albeit by one extra call where ((Find sources)) transcludes ((Find general sources)) which invokes the Module.

Currently Template:Talk header includes the basic set of source links for all articles where it is not suppressed by parameter. After go-live, the behavior of "find sources" in Template:Talk header may change, depending which solution is chosen. If the parameter method is chosen, then the links in the Talk header would remain the same, until someone added the parameter. If auto-detect by WikiProject is chosen, then the links in the Talk header of pages on medically-related topics will switch to the medical links, and on video-related topics will switch to the video links; all other Talk headers would remain as before.

Impact on other templates

Other templates use the ((find sources)) templates, such as ((unsourced)) and other maintenance templates, as well as many others. Depending which approach is chosen, this could affect whether the other templates will be able to take advantage of them. A combined approach allowing auto-detect and via param would permit both.

We look forward to your feedback on the considerations above and the proposal overall. Thanks! Mathglot (talk) and ((u|Sdkb)) ^talk 23:20, 12 August 2021 (UTC) updatedto add biographical sources; by Mathglot (talk) 22:32, 13 August 2021 (UTC)

• Listed at: Wikipedia talk:WikiProject Medicine. Mathglot (talk) 23:49, 12 August 2021 (UTC)
• Listed at: Wikipedia talk:WikiProject Video games. Mathglot (talk) 23:53, 12 August 2021 (UTC)
• Support as helpfully expanding the utility of this talk page banner. I would in particular be a fan of the wrapper template idea, as it is the least disruptive imo. I think the parameter approach via "search-domain=medical" is the best solution for how to label pages as needing MEDRS in the banner, though I think the auto-labelling is a good idea. My suggestion would be to try the auto-labelling first, and revert to manual labelling anything that is medical if it goes haywire and labels a lot of unnecessary things.--Shibbolethink ^{(♔ ♕)} 23:57, 12 August 2021 (UTC)
• As co-nominator, I obviously support this. Given how widely the find sources links appear, I think it's important that they are as useful as possible, and this will help with that by making them more appropriate to their context.
  Regarding selection approaches, I favor mainly option 2 (project banners), with the ability to override via option 1 (manual parameter setting). That's because I think it's important to have an element of automation to get this adopted on a wide scale. Option 3 (Wikidata) doesn't seem technically feasible, so that leaves project banners. I think "Is this tagged with ((WikiProject Medicine))?" is an excellent metric, because the project tag belongs on all medicine-related articles, which is also basically the set we want to have the medicine links. However, it's nice to have the ability to override the default for the rare cases where it isn't working as expected, and having the parameters from option 1 will allow that. The only thing weighing against them is added code complexity, which isn't a huge downside.
  Regarding the wrapper template implementation, that's been more Mathglot's area of focus, so I'll defer to them and others who comment here. Also, I realize all this is more complex than some of the stuff that comes across VPR, so if anyone has questions or wants clarification, please don't be afraid to ask! Cheers, ((u|Sdkb)) ^talk 05:50, 13 August 2021 (UTC)
• I support the general proposal. I do have some questions about the implementation - I think if an automated detection system is implemented it will need to have a bit more subtlety than 'does this have a WikiProject Medicine banner?'. Articles about people in medicine, healthcare companies, medical books or journals, the history or social/political aspects of medicine, etc. are usually tagged with WPMed, but these articles do not necessarily require MEDRS sourcing for all claims. I wouldn't say this is a 'rare' case. If it's possible to take the intersection of WikiProject banners into account (e.g. don't default to 'find medical sources' if there is a WPBiography tag on the page in addition to WPMed) that might help, but I think this might need to be handled via a supervised AWB run or similar. Also, a hybrid of the 'find medical sources' and 'find general sources' template could be helpful for topics that might contain claims needing MEDRS sources but which are not strictly medical. Spicy (talk) 19:54, 13 August 2021 (UTC)

  I like the thought of the hybrid template, since for the examples you gave, most sources wouldn't need the MEDRS standard but several might. For instance, a medical researcher would need it for the part of the page discussing their discoveries, a company for discussing their products, a journal for discussing medical controversies about their work, a history page for discussing medical details about viruses involved in a pandemic, etc. ((u|Sdkb)) ^talk 20:40, 13 August 2021 (UTC)

  @Spicy:, regarding "don't default to 'find medical sources' if there is a WPBiography tag on the page in addition to WPMed" this could definitely be added; it poses no great difficulty and would be isolated in the wrapper. It just depends on whether that idea gains consensus.

  Another option to consider, is that there's no need to choose only one set of "find sources" links. If the article is in both projects as in your example, one could imagine various outcomes: we could let the Talk header template grab the medical links automatically, and then add a biographical links below it, the second one either added automatically as well, or manually by adding ((biographical sources box)). Yet another possibility, would be to have the order of WikiProjects matter: if Med is first and Biog second, then you only get the "find medical links" automatically, anything else you'd have to add manually; if Biography WikiProject was first, then it would be the other way round. But maybe it's too subtle operationally, even if well documented ("You mean, I'm spozed to read the stinkin' documentation?") Not sure why AWB would be involved; I think it's all doable in the wrapper.

  Sometimes having too much choice gets to be a problem because you can get paralyzed with all the possibilities, so at the outset I'm inclined to go with the simplest useful proposal that gains consensus; not because that makes it easier for template writers, but because that will give editors some time to see and use the new functionality, which may subsequently percolate into a more specific and informed wish list of increased functionality based on their real-world experience with the early version. Mathglot (talk) 22:11, 13 August 2021 (UTC)

  The reason why I suggested AWB is because I think human judgment could be required for some of the edge cases - I don't think we should be giving people the impression that a MEDRS-compliant source is required to cite a medical device company's yearly revenue, for example. I suppose this could be handled in other ways, like the system you've described or Sdkb's hybrid template idea (although both of those rely on the assumption that the WikiProject tagging is accurate, which isn't always the case)... Spicy (talk) 06:16, 31 August 2021 (UTC)

  Not too familiar with AWB but would there be any significant downside to first using Mathglot's logic-based approached based on WikiProject with a manual override? Centralizing the logic where possible seems preferable. In the case of a medical company, maybe just add priority logic to check for 'WikiProject Companies' and assign those topics to display the general link set. AWB could still be used to mass apply overrides if there's a scenario that can't be accounted for in the root logic. - Wikmoz (talk) 20:48, 31 August 2021 (UTC)

  @Spicy:, Hopefully as people see it live and perhaps read the expanded /doc, they'll see some of the options and apply whatever makes sense to get the desired display. As far as not requiring MEDRS links for the medical devices company revenue case, two possibilities occur to me without changing anything said prior (although these examples are no doubt not obvious since it's not live, and there's no doc):

  • Add an additional set of links to the header outside the scope of the new header functionality, by separately adding ((General sources box)) after the Talk header, so that you have both the medrs links automatically added by the new template functionality per Med project presence, and the "regular" links. You can see how this would look in this mocked up Talk page for the "Cochlear Limited" article (note: the actual Cochlear article TP does *not* have WikiProject Medicine on the Talk page; I had to add it to the mockup for the purposes of this test)
  • turn off find-source links with the existing 'hide' param, and add ((General sources box)) (i.e., the Talk page will look the way it does now) (the third, "hybrid" solution has been mentioned already)

  I was trying to find a medical devices company with the Medicine WikiProject already present so it would be a good example of your concern, but I gave up and had to force project medicine into the mockup for the test. (I didn't look very hard.) The question, I suppose, is this: "Is the benefit of having medrs links produced automatically via project detection worth the disruption that might be caused by losing the general "find sources" links for cases like medical device companies tagged with project Medicine, or in other cases where the correct WikiProjects are not applied and so the general link set would be better?" Is that a fair statement of your concern? I'm not sure we know the answer to that until we try it, unless someone wants to do some clever analysis and see what's out there now. I'm not opposed to undoing the installation after the fact, if on balance it turns out that the new approach is not helping editors improve the articles concerned by proposing a better set of reliable source links for most articles most of the time, because that is the whole point, right? Mathglot (talk) 01:47, 1 September 2021 (UTC)

• I broadly support the idea, allowing for tweaks to get the usability issues right. It's worth steering people towards suitale sources somehow. Shooterwalker (talk) 22:18, 13 August 2021 (UTC)
• Support. I think this is a good idea. Clovermoss (talk) 22:23, 13 August 2021 (UTC)
• Listed at: Module talk:Find sources. Mathglot (talk) 22:28, 13 August 2021 (UTC)
• Listed at: WT:WikiProject Biography. Mathglot (talk) 23:23, 13 August 2021 (UTC)
• Support. Very cool idea and great work Mathglot and Sdkb! I think Option 2 (with the manual override function) sounds like the best approach. It's probably not worth getting too hung up on the edge cases. For those, I'd favor whichever approach is easiest to engineer and maintain with a slight preference to avoid hybrid or stacked link sets. - Wikmoz (talk) 01:35, 22 August 2021 (UTC)
• Mathglot, Sdkb: What would be the next steps? - Wikmoz (talk) 04:46, 31 August 2021 (UTC)

  ​Thanks for the follow-up, Wikmoz. This hasn't garnered too much participation, but since it's been in a visible location and reactions so far have been positive, I'd say it's safe to move forward with implementation using option 2 with manual override function. ((u|Sdkb)) ^talk 20:31, 31 August 2021 (UTC)

  Yes, that sounds reasonable to me. Once it's been moved live in template form and had time to gain some page views, we could take another look to see if more tweaks or other changes are needed based on any feedback from those encountering it for the first time. Perhaps subsequent to that, I imagine one would check to see about moving parts of it into the module. Adding Sdkb. Mathglot (talk) 20:48, 31 August 2021 (UTC)

WP:SNOW close in favour of:

• increasing the proportion of new accounts receiving Growth features from 2% to 25%
• increase the share of newcomers getting mentorship from 2% to 5%

After the 1 month an update on the results of the trial will be posted and available for discussion in a similar manner to the 2% trial, and any proposal for changes or expansion brought here, as was done with this proposal. Seddon ^talk 16:00, 11 September 2021 (UTC)

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

---

Hi everyone – I'm Marshall Miller, the product manager for the Growth team at WMF. Over the past three years, the Growth team has been developing a set of features meant to improve the experience for new editors. The goal of our work is to help newcomers make successful first edits, instead of them leaving from frustration or confusion. Thank you to the many community members who participated on this page and helped put together this proposal!

Following a VPR discussion in April 2021, the features have been applied to 2% of new accounts as a trial. The community members following along have agreed that the initial trial has had positive outcomes, and so we now propose increasing the share of new accounts receiving the features from 2% to 25% (with some caveats).

The Growth features aim to guide newcomers as explained on the project page. The most important elements are:

• Newcomer homepage: a special page with useful actions that newcomers are encouraged to visit immediately after account creation.
• Suggested edits: a feed of articles that have maintenance templates such as ((Advert)) and ((Underlinked)). Newcomers can choose topics of interest to filter the feed, like "Fashion", "History", or "Physics".
• Mentorship: newcomers are assigned a mentor from a list of experienced volunteers. A pop-up form helps them submit a question to their mentor's talk page using a simple interface. Whereas Adopt-a-user is meant to be an enduring connection for a newcomer, "mentorship" in the Growth features is meant for quick questions.
• Help panel: when the newcomer is editing an article, the help panel is like a collapsible mini-homepage, providing relevant help links and the ability to ask mentor questions.

The Growth features are now on 50 Wikipedias, including large ones like French, Spanish, Russian, and Portuguese -- and with German and Dutch Wikipedias having recently started trials. Evidence shows that the features improve newcomer engagement without burdening communities.

In April 2021 we discussed testing the features on the English Wikipedia at this page. We started giving the features to 2% of new accounts in June (about 2,000 new accounts per month), and posted data and results after a month. There were two main outcomes:

• The "suggested edits" feature seems to be leading to many good edits with low revert rates. During the test period in June, the revert rate was 9% (with the baseline revert rate for newcomer edits that month being 27%). To date, 2,325 article edits have been made. Many users do dozens of these edits. You can see these diffs by filtering to the "newcomer task" edit tag in Recent Changes.
• The "mentorship" feature yields some good questions and some low-quality or nonsense questions. To date, there have been 329 questions asked to the 22 mentors who have signed up. We're still discussing how best to scale up the mentor capacity and how to encourage high-quality questions. You can see these diffs by filtering to the "mentorship module question" and "mentorship panel question" edit tags in Recent Changes.

We think the next step is to give the Growth features to 25% of new accounts for one month (about 25,000 new accounts). The exception would be the mentorship features, for which we have open questions mostly discussed here. We want to increase the share of newcomers getting mentorship to only 5%, so as not to overwhelm the mentors. We would run this phase of the test for one month, and then bring the results back here to decide whether to further increase the share of newcomers with the features. In looking at the data, we will think about these questions:

• Revert rate of suggested edits. Are high-quality edits being generated without an undue burden on patrollers?
• Volume of mentor questions. This would allow us to extrapolate how many mentors would be needed to handle 100% of new accounts, or how the mentorship features might need to be improved to handle increased volume.
• Quality of mentor questions. Are there improvements we could make to the features to help newcomers ask useful questions?

We're interested to hear any questions, ideas, or concerns -- and we're hoping there's general support for moving to this next phase of testing the Growth features. We also are looking for about 20 more people to sign up as mentors to handle the increased volume of questions that will come in with the next phase. Mentors should expect to get 3-4 questions per week on their talk page. You can learn more about that and sign up on this page. Thank you! -- MMiller (WMF) (talk) 23:33, 2 September 2021 (UTC)

I like the "Your impact" section. It can be really discouraging when you're starting out with something new to not get any feedback on whether what you're doing is making a difference. I'd be interested to learn more about what goes into picking the suggested edits, but certainly the idea of presenting a newbie with specific things they can do right now is great. And I like the tinder-esque "swipe left, swipe right" U/I in the mockup. -- RoySmith (talk) 00:00, 3 September 2021 (UTC)

Thanks for checking things out, @RoySmith! Seeing your questions made me realize I should have posted instructions for how anyone can turn on the Growth features and try them out. You can do it with these instructions.

About your comments and questions: I'm glad to hear that you think the Impact module is on the right track. The goal is to help newcomers have that realization that editing Wikipedia is valuable and exciting. It's definitely really rudimentary right now, and we're planning to make it more powerful in the coming year (we'll eventually be posting ideas on this currently barebones page).

In terms of suggested edits, we want newcomers to find interesting pages that need easy edits, so they can quickly have success on the wiki. We're currently sourcing them through maintenance templates, like ((Advert)), which is one of the templates we draw on to find articles for the "copyediting" task. You can actually see (and edit!) exactly which templates are used for which type of task through a new Special page we created to enable community members to configure the Growth features: Special:EditGrowthConfig. With this page, much of the control over how newcomers experience the Growth features is in the hands of community admins.

Beyond the user-applied maintenance templates, we've been experimenting with creating suggested edits algorithmically. One way that's currently being tested on several wikis is called "add a link", which uses an algorithm to suggest words and phrases that could be made into wikilinks. It's going well so far, and the details are here on this project page. And in that vein, we're also building a first attempt at a task that suggests images that could be added to unillustrated articles. That one has many more open questions and risks, and so we hope to hear from more community members on its talk page.

And in terms of allowing users to choose topics of interest (e.g. "Music", "Sports", "Europe"), those come from a machine-learning model that tries to assess which topics an article is about based on the words used in it. It is trained using WikiProject tags from English Wikipedia, and tends to be pretty accurate. The information about how that model works is here.

I'm happy to answer any other questions or hear any other ideas! MMiller (WMF) (talk) 00:30, 3 September 2021 (UTC)

• Support the increase to 25%. MMiller and the rest of the Growth team have done an exemplary job collaborating with us in the community on the development of these features, and as summarized above, the results have been very promising so far. This rollout is suitably cautious and will allow more newcomers to benefit from them while giving us more information to inform the final launch. ((u|Sdkb)) ^talk 00:20, 3 September 2021 (UTC)
• Support - MMiller and his team have both an excellent project and have been doing a fantastic job at working with the community, adapting to our specific requests (one example is they added the functionality to decouple the % getting the Growth panel and the % getting mentors to adapt to our trialling wishes). I think this is a great next step in rolling it out, and will give enough trial data to better predict benefits and risks. Nosebagbear (talk) 00:53, 3 September 2021 (UTC)
• Support Seems like a reasonable next step. * Pppery * _{it has begun...} 00:56, 3 September 2021 (UTC)
• Support. Just in case it's not clear from my comments above, making this explicit. -- RoySmith (talk) 01:06, 3 September 2021 (UTC)
• This seems very worthwhile and I support moving forward as suggested. --Malcolmxl5 (talk) 01:25, 3 September 2021 (UTC)
• Support I think this is a very worthwhile project. The WMF team in charge of this has been very responsive to the community. Calliopejen1 (talk) 18:41, 3 September 2021 (UTC)
• Support per above. ― Qwerfjkltalk 19:42, 3 September 2021 (UTC)
• Support as someone who has offered to help as a mentor. I think helping new users getting the hang of how to edit on Wikipedia is one of the most important tasks we can do to make sure we have a healthy, growing community. Isabelle ^🔔 22:52, 3 September 2021 (UTC)
• Strong support, as a mentor and someone who's been giving a bit of feedback for this on the Growth features talk. As far as I've seen, it's going great so far and upping to 25% is the right next step. — Bilorv (talk) 23:04, 3 September 2021 (UTC)
• Support. Well done; this seems to be a very welcome initiative that should benefit both projects and editors. Certes (talk) 15:31, 4 September 2021 (UTC)
• Support Absolutely! Promising results so far. This seems a valuable tool for editor retention and recruitment, my number one priority. CaptainEek ^{Edits Ho Cap'n!}⚓ 22:38, 6 September 2021 (UTC)
• Support New editors need guidance. Thanks to MMiller and the team for their collaborative work. Johnuniq (talk) 23:43, 6 September 2021 (UTC)
• Support with thanks to MMiller for his diligent work with the community on this initiative. ProcrastinatingReader (talk) 00:15, 7 September 2021 (UTC)
• Support Great project that is ready to proceed forward. I still have have concerns about whether the mentorship program will scale up to 100%, but the other parts are. --Trialpears (talk) 09:12, 7 September 2021 (UTC)
• Support I turned this on for my sock account and I really like the idea, especially the "impact" summary on the homepage. I may even have finally changed my mind on the utility of cleanup tags, which I've always thought were useless clutter. Agree that the mentorship component seems least scalable and maybe should be a separate opt-in. I'd also like to see this available on mobile eventually; my first thought was that the "snack-sized task" model would be a good match for mobile editing, but I didn't see a way to enable it without switching to desktop mode. Opabinia regalis (talk) 20:51, 7 September 2021 (UTC)

  Hi @Opabinia regalis -- thanks for trying out the features! I should have said in my original post that these features are available on both mobile and desktop, and yes we do think and hope that they are a great fit for mobile editors. Maybe you're identifying some challenges with finding the features on mobile. If you tap on the "hamburger button" in the upper left on mobile, the navigation menu opens. Then you can tap your username in that menu to go the homepage. Does that work for you? Do you see a way to make it more clearly accessible?

  Speaking of mobile edits, the Growth team has been building some new types of tasks that are specifically geared toward ease of use on mobile. The first one that is currently being tested on about 10 Wikipedias (German, Arabic, French, Polish, and several others) is called "add a link", in which an algorithm suggests words or phrases that could be made into wikilinks and the user taps "yes" or "no" to add the links. It's a very simple kind of editing, but it's designed to be the sort of thing that can be done with just one hand on a cellphone, perhaps while hanging on to the railing on a bus commute. In the tests so far, it's going well. I hope you can check the project out and add any of your own thoughts here or on its talk page. MMiller (WMF) (talk) 17:06, 8 September 2021 (UTC)

  @MMiller (WMF): Thanks for looking into it! I think the issue I noticed are probably not relevant to newcomers with the features already enabled, so maybe not so important. Glad to hear about the mobile tasks!

  I should've been clearer, I noticed two things: first, I couldn't enable the features using the mobile site. Now that I look again, I think this is my misunderstanding in expecting "Settings" in mobile to correspond to Special:Preferences. I can get to preferences using a direct link, but there doesn't seem to be an interface link to it that I can find.

  Second, I hadn't realized I was using "Advanced" mobile view. In that view I don't see a link to my username in the hamburger menu. When I turned that view off, I was able to get to the new homepage as you suggest, by clicking my username. It is a little unintuitive, though, there is both a "Home" link and a "Homepage", and they're not the same thing - Home goes to the main page, so if you want your homepage you click on your username, not on "Home". I guess what I meant was, I'd like to see this in Advanced view too (which I think is generally better for editing.) Opabinia regalis (talk) 19:23, 8 September 2021 (UTC)

  Hi @Opabinia regalis -- thanks for the clarification. Yes, it's true that one can't enable the features from mobile, because the full set of preferences are not available. I think that's a potential improvement to the mobile skin in general. For our deployment, newcomers will have these features on automatically, and so they'll not need to know how to turn them on. But this is an important note -- for instance, an experienced editor who only uses mobile would have to switch to desktop view to turn them on.

  In Advanced mode, it actually is possible to get to the homepage. The rule is that you can always go to your homepage by clicking your username wherever you find it in the menus. In non-Advanced mode, your username is in that hamburger menu, like you found. But in Advanced mode, it's under the "person" avatar in the upper right of the screen.

  As you say, the nomenclature around the homepage is tricky. I think there was a time when the first item in that hamburger menu was called "Home", but I believe we changed it to "Main page", to cut down on this confusion. Do you see it called "Home" or "Main page"? MMiller (WMF) (talk) 04:18, 10 September 2021 (UTC)

  I like the idea of small tasks just for mobile. Another one I could see working is spell checking/correction, but the "add a link" task seem particularly good because it's a wiki-specific skill. -- RoySmith (talk) 22:00, 8 September 2021 (UTC)

  @RoySmith -- I'm glad you mentioned spell checking; we heard that idea from a lot of community members when we first started talking about the "add a link" task. In that vein, we've started doing some research on how we might build such a task. If you have any ideas or concerns with making a task for spell checking, it would be great to hear from you here or on the talk page for the research. MMiller (WMF) (talk) 04:22, 10 September 2021 (UTC)

• Support Given the initial trial results, it makes sense to expand at this time. GenQuest ^"scribble" 12:31, 8 September 2021 (UTC)
• Support I've enjoyed participating in the mentorship program, and I'm glad to see the features as a whole have a positive impact. I can say from experience that the questions are of varying quality, but depending on how you can respond they can still be valuable. For example, I had one or two editors who simply said "hi". I took it as an opportunity to leave them a welcome template on their user talk page. Another posted multiple paragraphs related to their belief that they were deposed royalty. While unfortunate, I simply ignored the posts until the editor got bored and left, then I cleaned up my talk page. Those low-quality questions are outweighed by the positive interactions. Personally, I don't get too many posts, but going from 2% to 25% would probably change that. Perhaps advertising in newsletters like Tech News, Signpost, or Admin Newsletter would be useful to get more sign-ups? — Wug·a·po·des​ 21:50, 8 September 2021 (UTC)
• Support I have in the past tended to be somewhat unenthusiastic about proposals affecting our interface or working style coming form the WMF, but they've become much more useful recently, and this looks like one of their good ones. We probably could and should have done it ourselves many years ago, but I'm glad it got done. DGG ( talk ) 06:40, 10 September 2021 (UTC)
• Support MarioGom (talk) 22:40, 10 September 2021 (UTC)

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

Hello! I am not sure if I am putting this post this in the correct place, so please excuse me it is not.

The article Sexual slavery in Islam is continually being vandalized by users (often anonymous IPs), who delete large, referenced blocks of texts. The reason for this appear to be that the information is slander against Islam. These edits are always reverted by experienced users, and since these edits are never referenced and instead removes referenced information, it is easy to make the assumption that there is a religios bias from users who which to remove referenced information because they think that this information put their religion in a bad light. Recently, I myself ask for citations from certain information in the article, but this was reverted by a user who claimed these sentences had references, even if they did not. Clearly, the article attracts emotions.

Another issue has come up: the article has long had a neutrality template. Because of the consistent vandalizing, I wondered if the neutrality template was in fact placed their originally because of religious bias. I made this question on the talk page, and the template was indeed removed. It has since been restored. I have to say, that the article is large, I have not read all of it, I am not an expert in the subject, and I cannot be entirely certain whether the neutrality template is warranted or not. And since I recognize that this is a sensitive issue, I simply don't have the energy to involve myself further.

However, it is safe to say that the article is about a very sensitive subject, and I am forced to revert vandalism so often that I wonder; should not an article that are so sensitive and vandalized so often as this one have some sort of protection? Many sensitive articles who are often vandalized have such a protection, at least against IP-editing. So my question is; can this article be protected? It truly needs it, I have to revert vandalism more often on it than any of the other articles on my watchlist. Best greetings, --Aciram (talk) 17:04, 8 September 2021 (UTC)

@Aciram Protection can be requested at WP:RPP. ~~~~
User:1234qwer1234qwer4 (talk) 17:07, 8 September 2021 (UTC)

The article is now semi-protected. Johnuniq (talk) 02:02, 9 September 2021 (UTC)

I agree that the page reads a bit non-neutrally and is possibly missing a lot of context. For something as contentious or sensitive as this, each statement should have multiple independent reliable sources, not just one. Else it could be taken as an attack page. I think the appropriate course of action is to take the matter to the talk page to discuss the issue, possibly nominate the page for deletion. Aasim (talk) 19:33, 13 September 2021 (UTC)

Hi y'all! I've been spending the last few hours and have realized that there is quite a heavy backlog of old split proposals that never got attention (in addition to a large amount of tags that have not been removed after a failed discussion). How could Wikipedia deal with this? The QPQ system for DYKs is very good at dealing with unresolved nominations, but I don't see how it could be applied here. Adding some kind of parameter to the split template where one needs to include the relevant WikiProjects, and then a bot automatically creates a talk page in that WikiProject would encourage more attention to any proposal. Please let me know what you think or if you have other ideas. Warm regards, A. C. Santacruz ⁂ Talk 10:06, 14 September 2021 (UTC)

Not necessarily against the idea, but please note that about half of our Wikiprojects are moribund. Notifying a moribund Wikiproject won’t do much. Blueboar (talk) 12:46, 14 September 2021 (UTC)

Just as a reminder, splits and merges are covered in WP:AALERTS for each project, under "Articles to be split" and "Articles to be merged". Headbomb {t · c · p · b} 23:33, 14 September 2021 (UTC)

Hi Wikipedia users!

New users which are not eligible for editing new pages on English Wikipedia, cannot have an option "Submit the draft for review" when creating a draft at: https://en.m.wikipedia.org/wiki/Wikipedia:New_user_landing_page which they want to move the draft to the main article. Please add this option as it is needed for new Wikipedia users which create drafts in order for their drafts to be articles on English Wikipedia.

Thank you — Preceding unsigned comment added by ARBENTUZI (talk • contribs) 04:48, 18 September 2021 (UTC)

@ARBENTUZI The button Start creating! under their article wizard heading allows you to create a draft with the "submit" button , after navigating through the options. Is that what you were asking? ― Qwerfjkltalk 10:28, 18 September 2021 (UTC)

No I am asking to make an option on a draft "submit for review" in order for the draft to be moved as a main article.— Preceding unsigned comment added by ARBENTUZI (talk • contribs) 11:23, 18 September 2021 (UTC)

@ARBENTUZI The whole point of draftspace is that it is reviewed before being moved to namespace. Otherwise, there would be no point in preventing new users from creating articles. ― Qwerfjkltalk 11:58, 18 September 2021 (UTC)

All Wikipedia:Autoconfirmed users can move pages from Draft: to the article mainspace. I wonder what percentage of new editors could do that themselves, by the time they finish drafting the article? ARBENTUZI, for example, just needs another two edits.

Also, there's another process called "review", and that's done by Wikipedia:New pages patrol rather than Wikipedia:Articles for creation. Maybe the question is about that. WhatamIdoing (talk) 21:04, 20 September 2021 (UTC)

• To put this another way… When someone creates a draft in Draftspace, it is automatically “submitted” for review. No need for a button. Blueboar (talk) 13:24, 18 September 2021 (UTC)

  No, that's not a good idea. How would reviewers know when it was ready for review? You would have partially complete drafts getting declined and wasting reviewer's time. The backlog for reviews is already bad, putting every partway done draft into the review list would make it unbearable. RudolfRed (talk) 17:23, 18 September 2021 (UTC)

• When you create an article in draftspace, put the ((Draft article)) template at the top of the page. This includes an option, when you’re ready, to 'submit for review'. --Malcolmxl5 (talk) 19:56, 18 September 2021 (UTC)

Hi Wikipedia admins!

Please either allow new Wikipedia users to submit a draft for review or automatically be accepted as an article or allow them to create new articles directly without being required to make 10 edits. Like they create articles directly on every other Wikipedia.

Thanks — Preceding unsigned comment added by ARBENTUZI (talk • contribs) 21:40, 20 September 2021 (UTC)

There is a reason we stopped allowing freshly-registered accounts to create articles directly in mainspace, and there'd need to be a new consensus against this to roll the change back. And if you know how to edit source, you can use ((subst:submit)) to submit a draft for review. Stop relying entirely on there being a button for everything. —A little blue Bori v^_^v ^{Jéské Couriano} 21:46, 20 September 2021 (UTC)

@ARBENTUZI:

1. At the New user landing page, click Start creating.
2. Read the advice and click Next when finished.
3. Do that again.
4. Answer the next prompt honestly.
5. Depending on your answer, you may have to read a few more prompts, but eventually you will be asked to create a title for your draft page. Enter it in the bar and click Create new article draft to get started.
6. When you finish writing your page, click Publish changes to publish your draft.
7. Finally, when your product looks something like this, click Submit the draft for review! to do that thing. –MJL ‐Talk‐^☖ 17:26, 21 September 2021 (UTC)

To Arbentnui, I agree with all points mentioned above, please read the feedback that you have gotten here. Varousz (talk) 22:05, 22 September 2021 (UTC)

• I have to agree with ARBENTUZI that we really ought to have ((Submit)) (which sends articles to AfC) integrated into the interface in draftspace, rather than relying on editors to add it and not accidentally remove it themselves. ((u|Sdkb)) ^talk 04:44, 23 September 2021 (UTC)

  @Sdkb When I was checking all the articles caught by the "AfC draft submitted with no references" tag, I found 3 malformed submissions. I'm sure a source search could easily turn up more. ― Qwerfjkltalk 19:59, 23 September 2021 (UTC)

Wikipedia:Books and articles have the option of converting to PDF. I propose we offer EPUB in addition. .... 0mtwb9gd5wx (talk) 01:15, 19 September 2021 (UTC)

@0mtwb9gd5wx: Wikipedia Books basically don't exist any more -- the Offline Content Generator was deactivated because there was no interest in maintaining it, the Books namespace was deprecated, and all existing books were deleted. The replacement "Download PDF" link is just running a copy of Chrome on a server and uses it's built in "print to PDF" function, so there is no option to convert it to other formats (since printing and converting are entirely different processes). You can, however, use MediaWiki2LaTeX (https://mediawiki2latex.wmflabs.org/) to convert pages to EPUB. --Ahecht (TALK
PAGE) 13:36, 24 September 2021 (UTC)

https://archive.is/zeW6f

(Sorry, wikipedia doesn't accept the full URL, hence archived page.) — Preceding unsigned comment added by 37.115.210.35 (talk) 19:10, 23 September 2021 (UTC)

I don't see what specific change is being proposed here. — JohnFromPinckney (talk / edits) 16:51, 25 September 2021 (UTC)

This is a notice that an RfC has been started requesting comment on if the draft of Wikipedia:Notability (television) should be implemented as a guideline and a WP:SNG. Comments are welcome at the discussion, here. - Favre1fan93 (talk) 16:34, 27 September 2021 (UTC)

 You are invited to join the discussion at MediaWiki talk:Editpage-head-copy-warn § Can we remove the content reuse disclaimer?. ((u|Sdkb)) ^talk 03:03, 2 October 2021 (UTC)

This is a quite big and good feature to have as of right now, i have been getting quite a bit of ip's vandalising my page and doing the request to protect my talk page is time consuming, a feature i would request is for all Extended users to be able to protect their talk page from ips. MoonlightVector^{Talk page} 14:50, 4 October 2021 (UTC)

MoonlightVector This is a form of a perennial proposal, see Wikipedia:Perennial proposals#Grant non-admins admin functions within their user space. 331dot (talk) 14:52, 4 October 2021 (UTC)

I don't think it's possible to gives users permission to protect specific pages without admin rights as if you're able to add protection to 1 page, you're able to add protection to all pages. However if this is possible then I think it should be a separate permission from Extended Confirmed similar to rollback to prove that the user will be able to use it correctly and not use it to just prevent people from warning them or something on their talk page. 331dot makes a good point above. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 14:53, 4 October 2021 (UTC)

• If you have a habitual problem with IPs vandalizing your talk page, you may request indefinite protection. 331dot (talk) 14:55, 4 October 2021 (UTC)
• Another option is to treat your user talk page the way you might treat voicemail on a phone… simply clearing/deleting any messages you don’t want to keep.

I regularly clear my user talk page after I have read new messages (not just vandalism). And I have found that Vandals tend to go away if you don’t respond to them. Blueboar (talk) 15:16, 4 October 2021 (UTC)

Your 2nd part is the entire reason WP:DENY exists. The trolls want attention. You deny them that, they get bored and leave. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 23:39, 4 October 2021 (UTC)

It is well know that the results of UFC events are often subject to vandalism. Wouldn't it be better to semi-protect the articles (as the event nears) to allow only registered users to edit. Most of these fake edits come from IP accounts. Registered users would get banned if they do anything spooky. I posted this suggestion in WT:WikiProject Mixed martial arts. but was doubtful for a response as it is quite inactive. I am not a highly experienced editor. Just thought of sharing my suggestion to the editors here.--Atlantis77177 (talk) 10:09, 6 October 2021 (UTC)

As it is policy to encourage people to try editing Wikipedia without requiring that they first register an account, we in general do not pre-emptively protect pages. If repeated vandalism or disruption over a short period becomes a problem on a page, we can temporarily protect the page or block IP addresses or ranges from which abusive edits are being made. - Donald Albury 13:50, 6 October 2021 (UTC)

A common theme when seeking admin intervention against a troublesome IP is that too many productive users will be caught in large range blocks.

Would there be value in having a page that logs IP ranges with vandalism/spam issues and then produces a recent changes queue limited to these ranges? Slywriter (talk) 12:43, 1 October 2021 (UTC)

• Interesting concept. If you did such a thing, two (or more) issues come up. Likely, it would need to be "admin only" to read, like the page that shows article pages with few or no watchers. The idea is to prevent low hanging fruit for vandals. Second, having a bot determine what the proper range is presents problems. Ranges aren't cut and dry, and you have v6 and v4 ranges to consider, which is an lot of coding and debugging. I can see the value in page like that, basically a list of hot spot ranges, even if it was a little sloppy with the ranges, but the question would be: does the benefit outweigh the work involved? I don't know. Then the next question is, who is willing to write the bot to maintain this? Again, an interesting idea, but it would require a fair amount of investment for an unknown return, particularly because it may be limited to admin (at least at first). Dennis Brown - 2¢ 11:37, 7 October 2021 (UTC)

Dear colleagues, please comment on CentralNotice banner proposal for Alumni and Mentors of Russia 2021 articles writing contest. (15st September 2021 → 30th November 2021, all IPs from Russia, Wp, 3 banner impression per one weeks). Only for russian ip. Thank you. JukoFF (talk) 13:34, 11 October 2021 (UTC)

• This is at meta:CentralNotice/Request/Alumni and Mentors of Russia 2021. — xaosflux ^Talk 13:44, 11 October 2021 (UTC)

In follow up to Wikipedia:Village_pump_(technical)#Paalika_Keka and some edit summaries at MediaWiki:Preferences-summary/en-gb, I'm proposing that we specifically add verbiage that we "discourage" our users from selecting en-ca and en-gb interface variants. These variants cause users to miss any localization to our interface messages, and put them at the mercy of either falling back to the default message - or accepting whatever the editors of translatewiki have put in place. I'd much prefer we forcibly made these fallback, but that is not currently a software option. — xaosflux ^Talk 20:42, 24 September 2021 (UTC)

Pings to some recently involved editors: @PrimeHunter, Mike Peel, Redrose64, and Jdforrester:. — xaosflux ^Talk 20:42, 24 September 2021 (UTC)

• Yep, scrap the lot. I suspect that people who choose these options do so in the belief that it will configure the text of articles - which is the one thing that it doesn't alter. Most of us know that petrol and gasoline are the same substance, but how often do words with UK/US variants come up in the interface messages? --Redrose64 🌹 (talk) 20:50, 24 September 2021 (UTC)
• Fully support deprecating the lot for all the reasons above. They only cause problems that we then have to unravel at VPT(!). firefly ( t · c ) 20:55, 24 September 2021 (UTC)
• Support. I once examined the full en-gb file and it only made around ten minor spelling and punctuation differences like color/colour, not different words like petrol/gasoline. For that you lose a lot of messages customized for the English Wikipedia, e.g. with links to our policies, processes and help pages. For example, compare the edit page for a fully protected page in en and en-gb (admins must log out to see it). en-gb users sometimes cause confusion when discussing the interface with others, and some help pages don't match what they see. en-ca (Canadian English) has the same problems but few users so it rarely comes up. PrimeHunter (talk) 21:18, 24 September 2021 (UTC)
• Support; they are nothing but trouble. Customize some of the messages within the variants to point people to how to choose the right setting. – Jonesey95 (talk) 00:33, 25 September 2021 (UTC)
• Support per Primefac. – SD0001 (talk) 02:21, 25 September 2021 (UTC)
• Yep, support. Tol (talk | contribs) @ 02:41, 25 September 2021 (UTC)
• Comment since I was pinged. We already have a warning in the preferences: "Language (warning:selecting a language other than 'en - English' may prevent you from seeing custom parts of the interface on the English Wikipedia and you may see inaccurate external translations.):" (where the 'external translations' bit is weird/wrong - it's translations built into MediaWiki). Presumably that could be extended to warn against en-GB and en-CA. I'm generally in favour of giving people the choice, though. Also, it shouldn't be completely disabled, as it's useful to browse the interface in other languages when you're not a native language speaker (I quite regularly do this on other language wikis). Thanks. Mike Peel (talk) 10:11, 25 September 2021 (UTC)

The quoted warning was added to MediaWiki:Yourlanguage this year. It is only displayed if the language is still the default en. PrimeHunter (talk) 13:35, 25 September 2021 (UTC)

The bit about external translations is correct because it is done at Translatewiki.net, which is not a WMF wiki. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:15, 26 September 2021 (UTC)

• @Mike Peel: I don't think we have the capability to remove these entirely locally, this is just about "discouraging" this right now - and may include adding warnings if your language is in those English variants. — xaosflux ^Talk 10:20, 25 September 2021 (UTC)
• Just to be clear, this proposal is only about the interface - and will have no impact in any way at all on the content of articles or the manual of style for engvar's in articles. — xaosflux ^Talk 10:20, 25 September 2021 (UTC)
• Support per nom. ― Qwerfjkltalk 14:21, 25 September 2021 (UTC)
• Support. Checking the last 30 days stats at translatewiki, en-gb has 44 translations and en-ca has only 4 translations. This shows that there are very few maintainers for these variants, which is what causes test edits and vandalism to go undetected until en.wp users notice it. Due to lack of active maintainers at both translatewiki and locally at en.wp, users who opt English variant interfaces get a suboptimal experience. So English variant interfaces should be discouraged in favour of base en. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:15, 26 September 2021 (UTC)
• Can we not just get en-GB and en-CA removed? What purpose do they serve? – Joe (talk) 07:55, 26 September 2021 (UTC)

  @Joe Roe: in some cases yes - part of this proposal is to actually discourage editors from "selecting" that language - not just cleaning up the messages; some prior messaging had push back about discouraging someone from using those settings. Nothing intrusive - just labels on things like preferences warning that this option is discouraged if someone actually does set it. — xaosflux ^Talk 09:42, 26 September 2021 (UTC)

  I mean removed as option, so we don't have to have to have these messages. – Joe (talk) 09:46, 26 September 2021 (UTC)

  Probably non-zero development work from the languages team, especially since a user's interface preference can be global and not solely local. IznoPublic (talk) 15:15, 26 September 2021 (UTC)

  If development work is being done, then the right solution is to fix phab:T57473, rendering the whole issue moot. * Pppery * _{it has begun...} 22:57, 26 September 2021 (UTC)

  @Pppery: the general tech problem is that when a localized message exists in a base language, but the user is set to use a base-variant language, when the base-variant language is not localized the user's language fallback chain doesn't bring them to the base language. — xaosflux ^Talk 23:32, 26 September 2021 (UTC)

  Does phab:T57473 refer to something else? * Pppery * _{it has begun...} 23:34, 26 September 2021 (UTC)

  That one seems to be about the fallback chain for base languages only, I think there is another could of phab tickets about base-variant fallbacks that I'm not remembering right now.— xaosflux ^Talk 11:01, 27 September 2021 (UTC)

  Oh. I actually meant fix the general problem, not one specific manifestation I may have linked to by mistake. * Pppery * _{it has begun...} 14:14, 27 September 2021 (UTC)

• Yes, please, discourage away. I'm tired of getting confused questions at VPT. :^) --IznoPublic (talk) 15:16, 26 September 2021 (UTC)
• Forcibly deprecate if we can get the developers to allow us to do it, and Support as second choice if not. No reasonable user who understands the situation would choose en-XX, and keeping the options around only confuses people and makes them waste their time figuring out the correct choice. We also ought to be doing all we can to discourage editors from wasting their energy maintaining the en-XX UI sets—having those forked makes precisely as much sense as forking English Wikipedia into American English Wikipedia and British English Wikipedia, i.e. zero sense. ((u|Sdkb)) ^talk 18:03, 1 October 2021 (UTC)
• Support. I've had a problem caused by selecting GB- User_talk:SilkTork#What's_broken?, which has now been fixed by reverting to standard en. What it offers (a simple spell check) can be problematic in itself as I am aware that I have automatically "corrected" spellings in articles which shouldn't have been corrected because that option is offered even when the article is supposed to be in American spelling. So it's a fairly useless gadget. SilkTork (talk) 16:45, 5 October 2021 (UTC)
• Support I did set en-GB in my global preferences, and had to revert back to en after some issues in multiple projects. When I selected, I did not foresee the kind of problems it would bring, and even when facing problems, it was not always clear that they were caused by the en-GB preference. MarioGom (talk) 08:36, 13 October 2021 (UTC)
• Support. The behaviour when there are customised messages (which are very common on en.wikipedia) is just confusing for users. Far worse than having to see the occasional US spelling. the wub "?!" 09:35, 13 October 2021 (UTC)

It seems to me that WebCite is obsolete now. I suggest to perform a script run/bot run to migrate all archive links that use WebCite to archive links using the Wayback Machine. According to our article, WebCite has not been accepting new archive requests since February and the site seems to be down since August. It seems unclear if WebCite will come back or not, so I think switching to a more stable archive service seems desirable. In particular, I think in cases were the original link is dead and a WebCite archive link is used, that link should be replaced by a Wayback Machine link if possible. I do not know how many replacements this task would entail, but I expect it would be impractical doing it manually. Toshio Yamaguchi (talk) 09:16, 30 September 2021 (UTC)

• Seems sensible. Stifle (talk) 11:13, 13 October 2021 (UTC)

I have this bot WaybackMedic has approval to run and ran in the past, converting WebCite to Wayback. It's harder than it seems. The problem: WebCite for a long time was the only provider who offered a "save page now" feature, allowing users the ability to save a page at that moment in time. Everyone else including Wayback only did sporadic automated crawls (they eventually offered a SPN). As such, it was the preferred site if you wanted to save a page that had content drift eg. weather stats on a page that are continually changing. So when converting from WebCite to Wayback it's darned tricky to get it right because it requires Wayback to have an exact match of the same day, or risk creating an archive with content drift. The ideal method is copy the WebCite page to another provider, and this is something I am looking into, but don't have much more to say right now. For the record, there are 238,851 WebCite links on enwiki - manual moves are the best option but that would take years of community effort. If there is a page you really care about, recommend doing so. -- GreenC 16:36, 13 October 2021 (UTC)

Fascinating info - I always learn something from you GreenC. Seems like the perfect task for an edit-a-thon, it is a shame we don't do those anymore :-( Thanks again for your expertise. MarnetteD|Talk 16:57, 13 October 2021 (UTC)

Thanks MarnetteD, I think you are right it is fascinating, many faceted. One idea is to convince the CS1|2 group to add a visible message that WebCite is deprecated and to find a new archive link. There is an RfC to support deprecation, and the situation has become worse since then. -- GreenC 17:18, 13 October 2021 (UTC)

Hello,

When I was navigating through articles of Pioneer & Communist Youth Leagues, I've found that all the templates (i.e. navboxs) related to youth wings of political parties are uncategorised, or categorised for geographic logic, indifferent of the ideology, the location or the level in the geopolitical hierarchy of the subjet. So, I've tried to found if there is an already created template category where to add these templates, but all I've found is Category:Political party templates, Category:Political ideology templates or Category:Organization templates.

I've therefore two questions:

• Is it a good idea? (I think so, but as I'm recurrent contributor to the UNCAT project, I want to ask some questions of principle, in order to know the opinions of the contributors and to be able to clarify certain dilemmas I can ask myself when a categorization seems to me to be done.)
• If yes, can someone help me for the creation of the best-named categories (if necessary) in the relevant parent categories, to make a list of templates to categorise and to do the job.

--Anas1712 (talk) 16:02, 17 October 2021 (UTC)

PS: If not in the best place to ask, please older people in the community indicate me where to repost the asking.

Would you please translate the french part of your statement, to english. GoodDay (talk) 16:53, 17 October 2021 (UTC)

Y --Anas1712 (talk) 17:57, 17 October 2021 (UTC)

I've left a note about this discussion at Wikipedia talk:WikiProject Politics. Thryduulf (talk) 16:55, 17 October 2021 (UTC)

I would like to propose creating a multiauthor space for creative writing: WikiFiction (or WikiNovelist).

Wikinovelists should contribute with donations to be able to participate in multiauthor books and everyone should previously register in order to contribute. This process will hopefully keep bored haters/destroyers away from busy creators -or modern serial witch burners from potential intelligent life out there.

WikiFiction could be a way to get funds for this or other wikimedia projects.

This new platform could recycle the current Wikipedia platform, with the added registration requirement, perhaps with a valid cellphone. A maximum of authors per book should be set for a given time, to avoid some books getting too crowded and the content confusing and neverending changing.

There should be authors and editors, who could review the final book for coherence. All versions should be stored until the final version is agreed. Authors and editors could go by name or nick, but all should be registered with a way to prove identity.

Any profits from any WikiFiction book should ideally be offered to non-profit charity organisations, chosen by votation of main authors, with a percentage dedicated to maintain WikiFiction.

Part of the donations for wikinovelists could be saved in a fund, which will offer free passes for those who could not contribute otherwise. So a young Leonardo da Vinci from a remote village somewhere in this planet, could still contribute to a book with perhaps unique ideas, even if her income is zero.

Creative writing or imagination in general is urgently needed to find solutions for the future we are facing. Encyclopedias and history are giving us great (or terrible) ideas from the past. Some novels (a bit as science) can be a valuable means to predict or create the future.

I will contribute with a first novel first chapter idea as a test. It is aimed to be a multiauthor book that would focus on a paradigm change related to Climate, from looking at plastic or recycling as the big problem here, to admitting we human overpopulation are the real issue on this planet. The book will revolve around that.

This creative piece of work requires the input of scientists, modern philosophers, social anthropologists... And needs to start rolling asap... — Preceding unsigned comment added by 94.252.121.207 (talk) 13:44, 16 October 2021 (UTC)

You are not just on the wrong page for this, you are at entirely the wrong project. Your suggestion is completely outside the purpose of Wikipedia. You could try reading meta:Proposals for new projects. --Redrose64 🌹 (talk) 14:38, 16 October 2021 (UTC)

This thing is just not for Wikipedia. It might not even be for Wikimedia. 🐔 Chicdat  ^{Bawk to me!} 09:58, 17 October 2021 (UTC)

@Chicdat: Agreed. The entire purpose of the wikimedia foundation is to run free, open-content wiki projects. A project where you need to pay for access, where only a limited number of people are only allowed to edit each page, and where registrations with a phone number is required to edit is completely at odds with what the foundation is about. There's also the rather strange proposed structure here where donations go to other charities, rather than funding the rest of the foundation? It honestly reads like a proposal for a completely separate website. 192.76.8.77 (talk) 18:40, 18 October 2021 (UTC)

I believe that you will find that the Wikimedia Foundation's charitable purpose is "education". US federal law names six common charitable purposes for a tax-exempt 501(c)(3) organization. See also https://www.irs.gov/charities-non-profits/charitable-purposes. Whatamidoing (WMF) (talk) 02:33, 20 October 2021 (UTC)

@Whatamidoing (WMF): Indeed, but the Wikimedia foundation mission statement [1] makes it clear that the way they intend to go about providing educational materials is by running multilingual wiki projects. My point was that a website where you need to pay/"donate" to be able to edit and where editing is restricted to a small number of people would be entirely contrary to the concept of running wiki based projects, which are generally supposed to be reasonably open and editable. 192.76.8.77 (talk) 09:10, 20 October 2021 (UTC)

Correct. IPv4 nominator, the closest you'll ever get to this is a different website entirely. 🐔 Chicdat  ^{Bawk to me!} 10:22, 20 October 2021 (UTC)

The mission statement says that the goal is "to collect and develop educational content". It is not clear to me why crowd-sourcing novels should be considered any form of "educational content". Whatamidoing (WMF) (talk) 20:01, 21 October 2021 (UTC)

• This is a nice idea, and I like it, but would it not have been better proposed at the section of Wikipedia:Village pump headed WMF? YTKJ (talk) 19:24, 22 October 2021 (UTC)

What should the English Wikipedia community do to communicate about the current election for the Movement Charter Drafting Committee? 03:58, 12 October 2021 (UTC)

Note: I've gone ahead and added the watchlist notice WP:BOLDly in light of the discussion below. Mz7 (talk) 02:54, 13 October 2021 (UTC)

Hi everyone, the election for the Movement Charter Drafting Committee (which is charged with drafting a "Movement Charter", or essentially a constitution for the global Wikimedia community) is now open and will be open for about two weeks, until 24 October 2021. (Info: announcement email, local info page.) There are three things that we should decide, hopefully while the election still has some time to run:

1. Should the election be publicized by MassMessage to eligible voters on enwiki (like for ArbCom elections)?
2.  Already done - Should we post a watchlist notice for the election (like for RfAs)?
3.  Already done - Should enwiki maintain and use a local info page about this election with appropriate information/FAQs and links? I started a rough draft (Wikipedia:2021 Movement Charter Drafting Committee Election) when I noticed that the meta documentation is really not well organized and the messaging thus far has already had a few screwups (the election not being announced when voting opened a day ago; the ballot said there are 19 candidates, but there are actually 70; etc.). If the answer to this question is yes, we could use that local link (instead of the meta links) for all of the local announcements (including watchlist/MassMessage if desired). In any event, please be bold in helping build out the local info page.

Because the election is over in 13 days, this RfC will by necessity run shorter than the standard 30 days. Best, KevinL (aka L235 · t · c) 03:50, 12 October 2021 (UTC)

• Yes on 1, 2, and 3. Apologies for the haste with which this was written – it had not come to my attention sooner that there would not be coordinated communication about this election. KevinL (aka L235 · t · c) 03:53, 12 October 2021 (UTC)
• Support all three. This is a big deal, more so than is recognized: it could fundamentally change the way the movement is organized. It's in our best interest to make sure that en-wiki is well represented in this election, and all three ideas strike me as reasonable ways to do that. (Mass messaging is a bit intrusive, but it's also quite easy to opt out of.) I also hope that, in the spirit of IAR, this RfC is closed promptly, preferably within the week. Regards, Extraordinary Writ (talk) 05:04, 12 October 2021 (UTC)
• Support all 3, and honestly, just BOLDly do the latter two. Enterprisey (talk!) 06:47, 12 October 2021 (UTC)
• Support all 3, do 2 and 3 ASAP. firefly ( t · c ) 07:12, 12 October 2021 (UTC)
• [Disclosure: candidate] - 2 & 3 right now please, and support all three Nosebagbear (talk) 08:46, 12 October 2021 (UTC)
• So: strongest possible oppose to sending tens of thousands of talk messages; There is already a Central Notice up for this, we don't normally put a WLN when there is already a CN - but if people want it, sure; if someone wants to run a local page more power to them. — xaosflux ^Talk 10:13, 12 October 2021 (UTC)
  • Not even sure what a local page would need to do, but I don't really care. The candidates are already selected (meta:Movement_Charter/Drafting_Committee/Candidates) and the voting is already open (meta:Special:SecurePoll/vote/390) - all that is left for the community to "do" really is send in voters. — xaosflux ^Talk 10:17, 12 October 2021 (UTC)

    @Xaosflux: To this point, maybe what we need is a "5 minute guide to the MCDC elections", akin to Wikipedia:5-minute guide to ArbCom elections, not a main page WP:MCDCE2021 like WP:ACE2021. What I do know is that I've explained what the MCDC is and why people should care and how to vote and find out info to a dozen Wikipedians, all generally well informed, who tried to read the meta pages and couldn't understand what the MC would be, so we need some kind of local page. KevinL (aka L235 · t · c) 14:43, 12 October 2021 (UTC)

    I'm currently working on a page to show candidate's basic stances on the compass questions in a simple table format, but it is taking a while given the sheer numberJackattack1597 (talk) 22:00, 12 October 2021 (UTC)

  • FWIW, I've prepped a WLN at MediaWiki_talk:Watchlist-messages#Movement_Charter/Drafting_Committee/Elections. — xaosflux ^Talk 11:08, 12 October 2021 (UTC)
  • If this global initiative is something that needs the level of advertisement as sending talk pages to every eligible voter, that should be requested upstream, of all WMF projects I'm not aware of any others doing something like that. While this seems important, it doesn't seem to be at the point of some sort of extinction level event for the English Wikipedia. — xaosflux ^Talk 10:51, 13 October 2021 (UTC)
• Do 2 and 3 (right away), neutral on 1. In a situation like this, the RfC should run about 30 minutes. The ArbCom messages are kind of irritating, but at least I know what an ArbCom is; I fear I am the only Wikipedian who had never heard of the Wikimedia Movement, a Movement Charter, and did not know we needed to draft one and were going to have elections for it. Now I have to weigh the three candidates whose names I even recognize against the other 69 people. My point: I am dubious as to how much acceptance editors will have for a MassMessage about something they've never heard of. Or maybe I'm the only ignorant one here. — JohnFromPinckney (talk / edits) 12:12, 12 October 2021 (UTC) Edited: apparently there are 72 candidates. — JohnFromPinckney (talk / edits) 12:16, 12 October 2021 (UTC)
• Confusion I just quickly read Wikipedia:2021 Movement Charter Drafting Committee Election, meta:Movement Charter and meta:Global Council and I don't really have the slightest idea what this election is about or in what way it would affect the English Wikipedia (or any other Wikipedia). Well, I get it is essentially about meta:Movement Charter, but what effect this "charter" will have/is supposed to have on the project (EN Wikipedia) is not readily clear to me. I wish someone who understands could write up a quick overview on the immediate effects this would have on EN Wikipedia. Toshio Yamaguchi (talk) 13:58, 12 October 2021 (UTC)

  @Toshio Yamaguchi: This question is precisely the most important reason to have a local discussion and info page. The short answer is, the Movement Charter will regulate how all future changes to the Wikimedia movement will occur. It will constitute a "Global Council" (m:Global Council) with the authority to represent the global movement to the Foundation; depending on what the MCDC writes, it could also have a budget, staff, lawyers, power to adopt binding global policy and overrule local projects, the ability to consent to changes to WMF-project relations going forward, etc. Essentially, it will be a GovCom for the entire global Wikimedia movement, and the MCDC is in charge of saying how it will be formed: whether it will be elected or appointed (or a mix), what diversity requirements there will be, what voice each project will have in selecting it, what powers it will have, etc. Enwiki is likely to have a fairly small share of the seats on the council. I hope this helps – and if you can help translate that into a concise statement of why this is important, please BOLDly edit Wikipedia:2021 Movement Charter Drafting Committee Election to say so. Best, KevinL (aka L235 · t · c) 14:31, 12 October 2021 (UTC)

@L235: that's actually a really clear and concise summary. I'd encourage you to add it to that page! The Land (talk) 18:11, 12 October 2021 (UTC)

• Notice WMF has placed an update on this here: Wikipedia:Village_pump_(miscellaneous)#Voting_to_elect_members_for_the_Movement_Charter_drafting_committee_is_now_open. — xaosflux ^Talk 17:17, 12 October 2021 (UTC)
• So: Definitely 2. Probably 3. Neutral on 1, but that's getting more support than I expected so far. Regarding a local info page - anything that demystifies what the whole thing is for the English Wikipedia audience would be a good move. The Meta documentation has improved a bit during the course of today, but there's much more to do on that. Happy to contribute to that (albeit, I'm somewhat limited in what I can say as I'm one of the candidates). Regards, The Land (talk) 18:08, 12 October 2021 (UTC)
• Support all three, more communication is definitely a good thing.Jackattack1597 (talk) 18:49, 12 October 2021 (UTC)
• Oppose mass message please don't flood my notifications when we already have a site banner. Support watchlist notice, neutral on local page though if someone wants to maintain it, more power to you. — Wug·a·po·des​ 20:57, 12 October 2021 (UTC)

  @Wugapodes: Hm, I would argue that a mass message does better than a site banner to (1) overcome banner blindness, (2) link to the local info page and/or 5-minute-guide page to emphasize the importance of the election (surely as or more important than ArbCom elections), and (3) send emails to those with that enabled. Best, KevinL (aka L235 · t · c) 02:56, 13 October 2021 (UTC)

  @L235: I think you overestimate how many people care to read through 70-odd statements from people they don't know for a position on a committee they've never heard of. While I obviously agree about the importance of the meta election, simply being important doesnt imo justify tens of thousands of notifications that are redundant with information in two other prominent locations. I skimmed my user talk history and I don't think I ever got a mass message about Board elections despite that being far more important and easier to understand. The way to combat banner blindness is to design better banners, not bludgeon people with information about things they already chose to ignore or participate in. Not everyone is interested or cares about what happens on meta, and those who do have numerous ways of finding out. For all the talk of banner blindness, you forget that constant useless mass messaging risks people opting out of mass messaging in general. We already send out tons of ACE mass messages, and there are almost 5,000 editors who opt out of mass message delivery. It's easy to fix banners, it's hard to get people to resubscribe to mass messages. Besides, if someone is so disconnected from the goings-on of enWiki that they missed a central notice and watchlist banner for weeks then I doubt a talk page message and email are going to be what spurs them to read almost four score nominations for a committee they probably haven't heard about. I just don't see the value in flooding watch lists, talk pages, and email inboxes with information already widely available for an election of niche interest to most people. Is it important? Sure, but that's why we have a banner at the top of every page. — Wug·a·po·des​ 18:01, 13 October 2021 (UTC)

•  Note: I've gone ahead and added the watchlist notice WP:BOLDly in light of the discussion above. Mz7 (talk) 02:54, 13 October 2021 (UTC)
• Note: options 2 and 3 are already done - so unless someone wants to argue to UNDO them, this is really just about #1 now. While shorter than 30 days seems OK, before running and sending huge numbers of talk messages, I think this should be at the least "very well attended" for that part. — xaosflux ^Talk 10:42, 13 October 2021 (UTC)

  @Xaosflux: I have been watching this conversation, and talked briefly with Mz7 before he implemented the watchlist notice confirming that I saw consensus for it. I agree with you that per our polices, guidelines, and procedures, we do not necessarily have to wait 30 days to find consensus, especially in this case, but given the magnitude of the impact, more editor participation will be required. Best, Barkeep49 (talk) 00:40, 14 October 2021 (UTC)

• Support all 3, this may be the most important election in Wikimedia history The stakes of this election include great influence on some percentage of Wikimedia donations. This Movement Charter is going to be a governance document lasting at least 10 years, and in that time, the Wikimedia Foundation will collect about US$1 billion in donations to the Wikimedia community. This governance document could direct allocations of anywhere between 10-70% percent of that. Conservatively, I think at minimum this document will send $100,000,000 within 10 years to causes, purposes, people, and places which previously were never considered or in discussion for getting funding. This is a really big deal. This situation and notice is a candidate for doing more communication in more channels than we ever have for any other community notice previously. However, this election is only part of this, and we might want to direct people's attention to a landing page for the part which comes immediately after and is just as impactful. After we elect these drafters, while they are writing the Movement Charter, anyone in the Wikimedia community can post comments to them on talk pages. Think of this like the United States Bill of Rights. If someone suggests text for the drafters to include, then they may put that in the Charter which would make it a Wikimedia Movement constitutional right. Beyond voting for drafters, people should be getting ready to give comments to the elected drafters. Blue Rasberry (talk) 00:24, 15 October 2021 (UTC)
• Oppose 1, but Support 2 and 3. 1 strikes me as unnecessary and redundant to it being listed on WP:CENT and having a blurb about it at WP:AN, not to mention a CentralNotice and Watchlist notice as well. That's plenty of ways to get the word out. I'd also like to note that we wouldn't mass message users during steward elections, so I don't see a reason to do so in this case either. My apologies, it seems that this discussion is what's listed on WP:CENT. I've struck part of my comment accordingly, but I would strongly support listing Wikipedia:2021 Movement Charter Drafting Committee Election on there once the dust settles from this RfC. OhKayeSierra (talk) 00:44, 15 October 2021 (UTC) (Edited comment due to mistake about WP:CENT. OhKayeSierra (talk) 00:49, 15 October 2021 (UTC))
• (Disclosure: Am candidate.) There are 17 hours remaining in the election. Probably time to close this, one way or another? --Yair rand (talk) 18:52, 24 October 2021 (UTC)
• I've removed the RFC banner. This discussion is OBE at this point, namely the end of the vote. --IznoPublic (talk) 18:59, 25 October 2021 (UTC)

We need a new |url-status= value, something like live paywall escape, for when the original url is live and behind a paywall and the archive-url is not behind a paywall. In this situation, with the markup |url-status=live, the link will be to a less desirable source for most readers, but |url-status=dead would not be true. —Anomalocaris (talk) 06:20, 29 October 2021 (UTC)

Should we really be purposefully encourag ing links to bypass the source's website to a paywall bypass? I mean it's one thing to have a source link and an archive link, it's another to have a source link and a ---> CLICK HERE TO BYPASS PAYWALL <-- (in icon form). ProcrastinatingReader (talk) 12:33, 29 October 2021 (UTC)

I think we should do so if and only if the alternative is legal. Do we have any proper legal advice on this? Some of us are used to circumventing links from Wikipedia's DOIs, which often point to a greedy publisher when there are free legal alternative sources such as the author's university. Certes (talk) 12:40, 29 October 2021 (UTC)

I often cite articles from a journal that is included in JSTOR (not a problem for me, as I have a personal account), but is also free-access fron a university site. I recall an editor removing the free-access url entry from a citation because I had included the JSTOR ID. Related to this is the availability of free access to draft versions of articles, with the final, published, version behind a paywall. It is nice to be able to read the draft, but I do not know what changed in the official published version. I have also cited an article from Nature that was available through the university of the principal author, until it was taken down (I expect that Nature is very protective of material it holds copyright to). So, there is always the possibility that the non-paywall source may be taken down because of a publisher exerting its copyright. Overall, though, I think we ought to be doing everything we can to link readers to free-access sites for sources, as long as we are reasonably certain that copyright is not being violated. - Donald Albury 18:11, 29 October 2021 (UTC)

• As a technical note, this is probably more appropriate for |url-access= than |url-status=. ((u|Sdkb)) ^talk 20:34, 29 October 2021 (UTC)
• I think there's an ethical dimension to this moreso than a legal one. Wikipedia depends on high-quality sources, and producing quality journalism isn't free. If a struggling newspaper has chosen to put up a paywall as their response to the dire situation of the industry, I'm not sure we should make it so easy for readers to get around it that they're not even alerted to the fact the source is asking for a contribution. For anyone who really needs the info, the archive link will still be there, making it pretty easy to get around the paywall. ((u|Sdkb)) ^talk 20:34, 29 October 2021 (UTC)

  There's a difference between The Guardian researching and writing a story then making it available to all with a polite request for donations, and Elsevier locking away a research paper to which their only contribution is web hosting. Certes (talk) 20:48, 29 October 2021 (UTC)

  There are absolutely publishers that charge outrageous prices, but trying to determine what's a "valid" paywall and what's not is way beyond the appropriate scope for us. ((u|Sdkb)) ^talk 21:09, 29 October 2021 (UTC)

• IMO we should not be in the overtly stated business of bypassing paywalls. -- GreenC 20:44, 29 October 2021 (UTC)
• The more ethical, less user friendly option would be to always defer to the archive over live version. That would be the equivalent of providing the source as it was when the editor sourced the content. Slywriter (talk) 21:25, 29 October 2021 (UTC)

Its a "Phab as old as time" T75299: implementing topicons into the mobile skin. As more and more of our readership becomes mobile, fewer and fewer of our readers can understand when a page is truly quality or not. The significant time and effort we put into GA and FA articles becomes unappreciated. There was some spirited discussion on the Phab last year, and no obvious solution. We need a coder who can suggest a technical solution and a community consensus as to how topicons should be placed (if at all). Alternatively, we need to rethink how we present topicons in general. Thus: I would appreciate brainstorming how to fix our presentation of GA/FA status so that mobile readers can see it too. CaptainEek ^{Edits Ho Cap'n!}⚓ 21:33, 29 October 2021 (UTC)

• I've been pushing to get that phab ticket addressed, and it seemed to be making progress in March but then it trailed off. It's definitely extremely important, but I'm not sure how much brainstorming there is left to do—what it needs is just some attention from the WMF to get it implemented. ((u|Sdkb)) ^talk 21:44, 29 October 2021 (UTC)
• As someone who edits about as much from my phone as from my PC (especially when needing to use vpn for my pc) any and all improvements to mobile use would be really really appreciated. Although not part of your suggestion, has there been discussion recently on ways to show talk page banners (such as coi/paid disclosures, sanction alerts, or other highly important ones)? A. C. Santacruz ⁂ Talk 23:40, 3 November 2021 (UTC)

Hi, I recently write a bot to create article lists in other languages. The bot is running in jawiki and zhwiki now, you may see the result, the bot will create a list for every language like this. How about enhancing Wikipedia:Featured articles in other languages like this? Kanashimi (talk) 03:40, 20 October 2021 (UTC)

That page is marked historical, so if you can revive it with a bot, please do! ((u|Sdkb)) ^talk 00:56, 21 October 2021 (UTC)

Thank you. Now preparing... Kanashimi (talk) 11:31, 21 October 2021 (UTC)

@Kanashimi: please note, to run a bot on the English Wikipedia you should request approval here: WP:BRFA. — xaosflux ^Talk 11:36, 21 October 2021 (UTC)

Ok. I will wait for some days if there are other opinions. Kanashimi (talk) 11:41, 21 October 2021 (UTC)

Sure! If you bot will only being updating 1 page (for now at least) it should have no problem getting approved. You are also welcome to do low-volume testing in your bot's own userpage (e.g. User:Bot/SampleReport). Having an example is a good way to demonstrate. — xaosflux ^Talk 11:50, 21 October 2021 (UTC)

(edit conflict) Maybe we can discuss related issues about this task here, so that we do not need to open a BRFA but find that it is worthless, does not meet the requirements, or does not feasible at last. Kanashimi (talk) 11:53, 21 October 2021 (UTC)

@Sdkb@Xaosflux I have generate a list of Afrikaans in Wikipedia:Featured articles in other languages/Afrikaans. May you help me to see if there are problems? Thank you. Kanashimi (talk) 05:02, 22 October 2021 (UTC)

You might want to replace the 、 separator by something more common in English, like a standard semicolon or a centred dot. You'll also need some explanation (tick mark and green background means the article exists etc.) Other than that it looks good to me. —Kusma (talk) 06:34, 27 October 2021 (UTC)

Oh yes, I forget this. Now fixed, please give some feedback, thank you. Kanashimi (talk) 09:13, 27 October 2021 (UTC)

@Kanashimi, that is feedback. ― Qwerfjkltalk 09:36, 27 October 2021 (UTC)

Some more comments or it looks good now? Kanashimi (talk) 09:40, 27 October 2021 (UTC)

Looks much better. Making Wikipedia:Featured articles in other languages/header an editable subpage is a great choice and allows others to further improve the descriptions. —Kusma (talk) 09:45, 27 October 2021 (UTC)

Thank you. :) Kanashimi (talk) 10:01, 27 October 2021 (UTC)

I do not understand what is meant by "article with the same name" at Wikipedia:Featured articles in other languages/Afrikaans. "No article" or "article does not exist" is clear enough, but not the "same name" thing. — JohnFromPinckney (talk / edits) 13:11, 27 October 2021 (UTC)

If you ask me, the color coding + ✓ or ✗ before each entry is self-explanatory enough to ditch the legend altogether. AngryHarpy‍^talk 14:12, 27 October 2021 (UTC)

Thank you for the comments. @JohnFromPinckney It means "the article title is the same with wikidata label". I have changed the commentary and hope this will help. @AngryHarpy It is for sort. I will remove the color so it will only have this function. Kanashimi (talk) 17:50, 27 October 2021 (UTC)

Ah. So for the ✗ red cells under Articles in English, if there's a red-linked title that matches the Afrikaans title, it means the English article doesn't exist, and if there's a blue-linked matching title, it's a link to an en-WP dab page with that name. If there's a different name in that column it means that there is an en-WP article corresponding to the Afrikaans subject, but it's got a different title. And in any case, ✗ red cells with a ((d:Q12345678)) link to a Wikidata item that has some connection to the Afrikaans article (even if it's not named the same).

Have I got all of that right?

And the Languages column shows how many Wikipedias have an article on that topic (although the number doesn't seem to match in the articles "languages" list). Yes? — JohnFromPinckney (talk / edits) 07:41, 28 October 2021 (UTC)

Oh, yes you got it! I hope someone adding more explanation so everyone will understand the meaning. Kanashimi (talk) 08:04, 28 October 2021 (UTC)

Cool. I am trying out some edits of the /header page right now, in the hopes of making things clearer. Which brings me to another question:

The first column is labelled "#" but not otherwise explained. Do the numbers in this column have some specific meaning? Do you expect them to be of some use to editors sorting on other columns? To me, it appears that this is just a semi-coincidental ranking based on a sorting by "Languages" (and which is arbitrary when, say, 5 articles all have the same number of articles there). So: can we do without this column? (It would save having to explain it, among other things.) — JohnFromPinckney (talk / edits) 11:03, 28 October 2021 (UTC)

Yes, the "#" field is basically sorting by "Languages". If there are two rows with the same "Languages", then they will sort by "Articles in English", this is the major different. You may click on the header of "Languages" to sort by "Languages", and should see the "#" field is not continuously. Kanashimi (talk) 11:28, 28 October 2021 (UTC)

Okay, have a look, please, at this edit. I hope it makes some of the details clearer; in any case, it provides a bit of an introduction to the /whateverlanguage page. Feedback welcome. — JohnFromPinckney (talk / edits) 12:29, 28 October 2021 (UTC)

Good! Thank very much! Kanashimi (talk) 13:09, 28 October 2021 (UTC)

I would advise that you omit any reference to Wikidata. A LOT of editors here at WP.en are not big fans of that particular project. Blueboar (talk) 21:29, 27 October 2021 (UTC)

Well, this is really a problem. I can remove links to Wikidata, but there will be nothing left for the foreign articles without wikidata label. Would this be more beneficial? Kanashimi (talk) 22:04, 27 October 2021 (UTC)

Just wanted you to know that including WD links IS a problem… better that you know that before you spend lots of time on them. Blueboar (talk) 12:46, 28 October 2021 (UTC)

Thank you for your advice. Kanashimi (talk) 13:10, 28 October 2021 (UTC)

Including WD links in mainspace is certainly controversial, but there's absolutely no need to avoid linking WD in project pages. – SD0001 (talk) 07:43, 10 November 2021 (UTC)

~@Kanashimi: Your page for Afrikaans looks great! If you are planning to run this bot for other wikis, maybe Wikipedia:Featured articles in other languages can be archived somehow, to make place for newly updated data? Artem.G (talk) 19:16, 2 November 2021 (UTC)

Yes, I am planning to run for other wikis. In the end Wikipedia:Featured articles in other languages should looks like ja:Wikipedia:諸言語版の秀逸な記事 or zh:Wikipedia:其他语言的维基百科典范条目. Kanashimi (talk) 21:48, 2 November 2021 (UTC)

BRFA filed --Kanashimi (talk) 06:25, 10 November 2021 (UTC)