Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• Jump to bottom
• New topic
• All village pumps

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion process.

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

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
• This is a high-visibility page intended for proposals with significant impact. Proposals that affect only a single page or small group of pages should be held at a corresponding talk page.
• Proposed policy changes belong at Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new articles belong at Wikipedia:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for 7 days.

« Archives, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230

Proposal to limit In The News Ongoing items to 45 days

Should items in ITN Ongoing automatically roll off after 45 days? 03:25, 24 June 2026 (UTC)

Note: The RfC tag on this discussion has been removed twice, with the editors suggesting that this be treated as a WP:RFCBEFORE. For that reason I'll use this discussion to guide the opening of a new RfC, when discussion on this dies down. BilledMammal (talk) 01:30, 29 June 2026 (UTC)

Survey

• Support. We now have ten items in ITN ongoing. This is ridiculous, and a consequence of this has been that we now only have space for three items in ITN itself. It also has stopped being useful; a reader going to Russo-Ukrainian war (2022–present) will struggle to find recent news about the war, such as the attacks on Saint Petersburg and Moscow. If there are sufficiently notable events related to the conflict - such as the Kharkiv offensive, the sinking of the Moskva, or the fall of Pokrovosk - then we can create an ITN entry, and direct readers to the relevant article rather than one that takes a longer-term view.

This also won't cause ITN to be overloaded; even with only three articles listed the oldest is almost two weeks old, so having a few extra stories on topics currently covered under ITN ongoing won't be disruptive. In addition, the 45 day period will still allow us to include events like the Olympics and the World Cup for the full length of the event.

As a second choice abolish ITN Ongoing entirely, because something needs to be done. BilledMammal (talk) 03:25, 24 June 2026 (UTC) Edited per Natg 19 BilledMammal (talk) 04:58, 24 June 2026 (UTC)

• Support in general, or at least that a review at ITN should be held to make sure the item is still being updated properly with ongoing significant news coverage (and not just gnoming type edits). Eg: to me it makes no sense yet to remove the Ukraine/Russian conflict, that still dominates the news, but every 45 days, or maybe 60, it should be put for an ITN review. That might help identify that there's a new timeline page, or a better target, or something along those lines. But I think we also need a better way to judge an ongoing item, like the Sudanese civil war is getting nowhere close to the attention of other ongoings, and the timeline is not updated since the 10th, so this is a prime candidate to go (which I will nominate immediately after this). We don't keep something in ongoing just because the event in ther real world is ongoing, there has to be a good volume of sourcing to keep it there and the article has to show sufficient updates. Masem (t) 04:27, 24 June 2026 (UTC)
• Support in principle, as I agree that there are ongoing articles that are on ITN too long, so there should be some sort of review process. However, the conclusions being drawn are incorrect. ITN has always had between 3-5 items blurbed, and the length of the ongoing section is not a major factor for this. (Earlier today, there were 4 blurbs, and a few days ago there were 5 blurbs.) This is typically a concern for admins to maintain the balance of the main page (WP:ITNBALANCE), and admins will add or remove blurbs based on this. Strong oppose the option to remove ongoing altogether as that is not at all necessary. Natg 19 (talk) 04:49, 24 June 2026 (UTC)
• Oppose mandatory removal after X days. Remove articles that have been listed there on a case-by-case basis. —Kusma (talk) 04:59, 24 June 2026 (UTC)

• Support in general. We definitely need this limit for the ongoing section as it's very unreasonable to have more ongoing items than blurbs (at the moment of writing this comment, there are seven ongoing items and three blurbs). I understand that there are multiple ongoing conflicts and events of wider significance whose timeline articles receive regular updates, which doesn't fully abide by WP:ONGOING, but it doesn't mean that prolonged ongoing events should be kept for good. The concept of 'news' is to inform people about notable current events, and a time frame of 45 days is reasonably long enough so that most people learn about an event. Furthermore, as ongoing events extend well over time, people get used to them and their coverage becomes routine (see WP:ROUTINE and WP:RUNOFTHEMILL). As for the time limit, the longest event that we post to ongoing with known duration is the FIFA World Cup, which lasts 38 days in the current format, so 45 days sounds like a reasonable time. --Kiril Simeonovski (talk) 07:34, 24 June 2026 (UTC)
• Support – The way I see this: if no one has done a blurb proposal for a news story covered by an Ongoing item for 45 days, then that ongoing-feature is likely no longer serving the original purpose. In general I am in favor of shorter-term ongoings. We can't possibly be massively overhauling an article constantly for over a year, and the front-page should not be filled with static content. ~Maplestrip/Mable (chat) 08:04, 24 June 2026 (UTC)

  if no one has done a blurb proposal for a news story covered by an Ongoing item for 45 days, then that ongoing-feature is likely no longer serving the original purpose

  Blurb discussions are often shut down explicitly since items are in ongoing (see the blurb noms for the Iran war as an example). Most editors on ITN see ongoing (which is somewhat true, although like many thing there, this has been overdone) as a way to offput blurbs for items frequently in the news, so not having a blurb proposal is largely by design. — Knightoftheswords 00:53, 25 June 2026 (UTC)

• Oppose. I don't like the idea of automatic removal, there should be some involvement in deciding(we don't automatically remove ITN items). There's no need to formally require a review, as any editor is free to start a proposal to remove an item("the Ukraine war has been up too long, let's remove it.") Ongoing can and has posted a significant event from an Ongoing event when called for. ITN, due to its name, is often misunderstood as a source of news, when its intention is to highlight articles about the news. I've long advocated that it should be easier to post something to ITN to increase movement(and that more articles posted is a good thing, not a bad thing). Ongoing isn't meant to require a "massive overhaul" every day, simply timely and regular updates. 331dot (talk) 08:13, 24 June 2026 (UTC)
  • we don't automatically remove ITN items This is absolutely wrong. Blurbs roll off because the room of the ITN box is limited, and RDs roll off because the limit per WP:ITNRD is six recent deaths. In both cases, however, we automatically remove the oldest news and recent deaths. The only missing puzzle with no restriction on such removal is the ongoing section. An alternative to time limit is maximum number of ongoing items (in a similar way as we have for RDs). Otherwise, the section will continue to grow without control and occupy the largest part of the ITN box. --Kiril Simeonovski (talk) 08:54, 24 June 2026 (UTC)

    They don't roll off based on an arbitrary time period, they roll off as new ones arrive. Would be open to a limit on the number of listings for ongoing(since we also limit ITN). 331dot (talk) 08:56, 24 June 2026 (UTC)

    Exactly, and that's why we need a rule that old ongoing items should be removed as new ones arrive. One way is to set a time limit, the other way is to set a maximum number. --Kiril Simeonovski (talk) 09:00, 24 June 2026 (UTC)

    I'd rather see a limit on the number of items rather than a time period(which would suggest items would leave and not necessarily be replaced)

    Has this discussion been brought to the attention of ITN? 331dot (talk) 09:03, 24 June 2026 (UTC)

    No (see the procedural note in the 'Discussion' section below). --Kiril Simeonovski (talk) 09:06, 24 June 2026 (UTC)

• Oppose. The solution isn't removal after an arbitrary time not abolishment of ongoing as a whole, rather the solution is to impose a maximum number and/or to periodically have a automatic renewal discussion (with no prejudice to keeping an item in ongoing if it meets the usual requirements). Thryduulf (talk) 09:07, 24 June 2026 (UTC)
• Support. It's not really in the news if it's been there for 45+ days. FaviFake (talk) 09:17, 24 June 2026 (UTC)

  Then that's an argument that can be used in a discussion to remove the item; we don't need an arbitrary time limit to do that.(which, as I said, would mean things would be removed but not necessarily replaced, as with ITN proper.) 331dot (talk) 09:27, 24 June 2026 (UTC)

  That's not always true, for example the Russia-Ukraine war is still ongoing after more than 45 days. Thryduulf (talk) 09:32, 24 June 2026 (UTC)

  Yes, and in that case it's no longer relevant enough to still be included here. It could be replaced with an article about a ore recent event in the war, for example. FaviFake (talk) 09:55, 24 June 2026 (UTC)

  It is certainly relevant enough, if being "in the news" is the measure. On the other hand, if you have the feeling that it should be replaced with something more recent, probably others feel that, too. Maybe that feeling is based on a view that would argue for calling the module "Breaking News" instead, which would be more aligned to the way you view what should be covered there. On the other hand, if a war is going on (or more precisely, being covered daily) then I think I would be shocked *not* to find it there. To some extent, it comes down to a core question of what this module is really for. Mathglot (talk) 10:29, 24 June 2026 (UTC)

  Ongoing is motivated by the Olympic summaries that we had used to post long time before it existed, and the key moment that led to its introduction was when the concept was expanded to the Arab Spring protests in order to prevent the ITN section from overflooding with blurbs on seemingly related events. Hence, its original purpose was to prevent multiple blurbs documenting a single event from being posted at the same time, not to keep major ongoing events on the main page simply because they're ongoing, and that's why WP:ONGOING requires regular updates to the article. As time went by, however, we significantly departed from the original purpose and began repeatedly invoking WP:IAR by posting timeline articles in brackets to justify that an item should still be kept (note that WP:ONGOING nowhere mentions that updates to sub-articles are sufficient). So, the answer to your core question is that 'ongoing' isn't as descriptive as it sounds. --Kiril Simeonovski (talk) 11:46, 24 June 2026 (UTC)

• Oppose in current form. While ongoing section is getting longer, it is also a result of that there more high impact continuing events than before in the various parts of the world. Having an arbitrary cutoff does not reflect the ongoing nature of these events. Instead, we can focus on other aspects such as if the ongoing entry has timely updates, instead of editors getting prodded to update the item when the entry comes up for discussion because the lack of timely updates. What for have it on the main page if the readers are not being kept abreast with developments on a day to day basis? – robertsky (talk) 09:43, 24 June 2026 (UTC)
• Oppose automatic time. I think a main purpose of ongoing is to save space and time, without it, all (most) the blurbs would be about ongoing matters. But I would support limiting the number, which would require more finely detailed editorial judgement. Alanscottwalker (talk) 13:07, 24 June 2026 (UTC)
• Oppose , for example the Russia-Ukraine war still is ongoing and still has plenty of developments. That something is lasting for long is not a reason to exclude it from the ITN sections, especially since it's still newsworthy. Headbomb {t · c · p · b} 20:11, 24 June 2026 (UTC)
• Oppose per Robertsky. Just since they're are more noteworthy events happening at a time doesn't mean that we need to start automatically dropping stories. Besides, a few of those entries could prolly just be removed via independent noms. — Knightoftheswords 00:51, 25 June 2026 (UTC)
• Oppose per Robertsky's comment on there being "more high impact continuing events" and Headbomb's comment on newsworthiness. S5A-0043🚎^(Talk) 03:59, 25 June 2026 (UTC)
• Oppose per Headbomb. GenevieveDEon (talk) 10:11, 25 June 2026 (UTC)
• Support in general. I think a time limit on Ongoing is preferable to a limit on the number of items. If an ongoing story is still worthy of being kept on ITN, it can be approved for another 45 day period by discussion. --Metropolitan90 (talk) 13:45, 25 June 2026 (UTC)
• Support 45 days in most cases is ample, and requests for extensions can be considered case by case.--Wehwalt (talk) 15:03, 25 June 2026 (UTC)
• Oppose as arbitrary. Why 45 days? Ongoing events don't just stop being relevant after a certain period of time has passed. I get the bar for an Ongoing item leaves open the possibility of way too many items in Ongoing, but the solution should be raising the bar for inclusion, not early removal. If not, I think we should consider a maximum number of Ongoing items, wherein one is removed when we're adding a new Ongoing item at a certain point. For example, if we have a limit of five, adding a new item after five would bump one item out, say, the article with the lowest volume of substantial edits in the past week. But a blanket limit isn't productive to the purpose of the section, IMO. DarkSide830 (talk) 02:01, 26 June 2026 (UTC)
• Oppose. Is the current process for removing an item from Ongoing insufficient? Or is the complaint that !voters in these removal discussions are "wrong"? If you truly think that there are items that should be removed, propose their removal. If ITN !voters are "wrong", then propose stricter criteria for "Ongoing" and get it changed. I don't think a simple day limit is the way to make criteria stricter, though. (As a side comment, I only count 7 topics in Ongoing, not 10 - it's 10 links but 7 topics.) SnowFire (talk) 16:58, 26 June 2026 (UTC)
• Oppose per Headbomb and Robertsky. To a reader, it would not be clear why some items that are ongoing are not on the list; right now the dichotomy between the regular blurbs/ongoing/recent deaths is intuitive but the proposed delineation is very much not. If there are issues with specific articles staying on there then they can be dealt with individually. Mir Novov (contribs | talk) 11:53, 27 June 2026 (UTC)
• Oppose per Robertsky, more ongoing means more events going on. You can add a discussion on removal of events that is not anymore ongoing on ITN. Warm Regards, Miminity (Talk?) (me contribs) 12:00, 1 July 2026 (UTC)
• Oppose as removal after 45 days is very arbitary. However, I would support opening RfCs for removing individual items in ITN Ongoing. FlammablePizza (talk) 16:48, 3 July 2026 (UTC)

There is no need for separate RfCs to remove individual items. The existing process allows for individual ongoing items to be nominated for removal directly at WP:ITN/C (and items have been removed recently in the past month). Natg 19 (talk) 16:53, 3 July 2026 (UTC)

• Oppose – As mentioned by plenty above, 45 days is arbitrary. Nice4What (talk · contribs) ♥ 03:47, 4 July 2026 (UTC)
• Oppose per above, no need for an arbitrary time limit. I also do not see the current number of ongoing items, which reflects the number of actual ongoing events in the world, as a problem to be solved. Moreover, I think this RfC is uncalled for as there was not any attempt to discuss this proposal on the ITN talk page (per WP:RFCBEFORE). Davey2116 (talk) 07:15, 5 July 2026 (UTC)
• Oppose automatic removal, but support a mandatory review after 45 days. Age alone is a poor measure of relevance: some stories fade quickly, while major conflicts or multi-stage events remain widely covered and substantially updated for months. After 45 days, continued inclusion should require renewed consensus under WP:ONGOING; otherwise, the item should be removed. Itliano355 (talk) 04:20, 14 July 2026 (UTC)
• Support per Andrew below—very few of these are getting any page views. If nobody's reading them, what's the point in having them?– Closed Limelike Curves (talk) 14:53, 27 July 2026 (UTC)

Discussion

• Procedural note: I don't see any evidence of WP:RFCBEFORE's

  you should try first to resolve your issues other ways. Try discussing the matter with any other parties on the related talk page. If you can reach a consensus or have your questions answered through discussion, then there is no need to start an RfC.

  For this situation, that would be an attempt to hold regular discussion on the matter at WT:ITN. To my knowledge, this has not occurred. Left guide (talk) 03:50, 24 June 2026 (UTC)
  • I've boldly removed the RfC tag. Formal RfCs represent an enormous investment of time from our community of volunteers, and to launch this without regard for RFCBEFORE/even trying to resolve concerns at the appropriate talk page is disrespectful of those people. I don't actually see any archived WT:ITN comments from BilledMammal in this calendar year, let alone comments on ITN's ongoing section, before today. Ed ^{[talk] [OMT]} 04:30, 24 June 2026 (UTC)
    • I've reverted, per my explanation below and the fact that WP:RFCBEFORE is a suggestion, not a requirement. BilledMammal (talk) 04:34, 24 June 2026 (UTC)

      Re-removed, essentially for the reasons Ed stated; this works fine as a proposal discussion. It's fine to advertise this in other projects and venues to get additional opinions if you like (have you?), and this discussion can be the one that fulfills the "before" requirement for a subsequent Rfc, but it doesn't fulfill it for itself. Then again, perhaps an Rfc won't be needed subsequently, unless this one becomes hopelessly deadlocked. Let's let the discussion continue, and see what we can learn about the situation and the issue in question. Mathglot (talk) 08:29, 24 June 2026 (UTC)

  Discussion at WT:ITN might allow us to reduce the current number of articles listed in ITN ongoing - although I think it is more likely to turn into a trainwreck - but it can't resolve the overall situation or prevent us from arriving here again. I think opening this RfC directly was the best option under the circumstances. BilledMammal (talk) 04:32, 24 June 2026 (UTC)

  Not following. Why would a discussion at WT:ITN that resulted in a consensus to permanently cap the number of ongoing entries not be able to "resolve the overall situation or prevent us from arriving here again"? After all, ongoing started with a proposal on WT:ITN.

  Also, I edit-conflicted when trying to add to my comment above that I do not have a concern with the topic of the RfC. I've certainly posted about concerns with ITN multiple times over the years! However, we have processes for a reason. I strongly object to you reverting my removal of the RfC tag, and would once again point out that you are parachuting into this situation and disrespecting the most important resource we have—editorial time. Shame, really. Ed ^{[talk] [OMT]} 04:43, 24 June 2026 (UTC)

  In my view, any discussion that resulted in a consensus to permanently cap the number of ongoing entries should be a formal discussion - we shouldn't be changing highly visible processes without broad visibility and input. BilledMammal (talk) 04:50, 24 June 2026 (UTC)

  Gotcha. That is an opinion, or really a question, that should have been asked as part of the RFCBEFORE that you decided to ignore. Plenty of changes happen on the main page "without broad visibility and input"; should Wikipedia talk:Did you know § Applying WP:EASTEREGG to hooks considered harmful happen on Talk:Main Page? Would you propose that all RfCs that aim to change the manual of style for all our articles be held here? Isn't the point of a RfC tag (as well as WP:CENT, etc.) to bring people into RfCs regardless of where they're happening? Etc. Ed ^{[talk] [OMT]} 05:17, 24 June 2026 (UTC)

• I !voted on the proposal, but I agree with others that this should've started at the ITN talk page. It was a shock to see this "complaint" opened without prior discussion at the ITN project, as in my opinion , this is more of an ITN internal matter. Natg 19 (talk) 05:02, 24 June 2026 (UTC)

  Processes with significant impact on the encyclopedia - and I include those controlling the main page in that - should in my view not be an internal matter, but a matter for the broader community. BilledMammal (talk) 05:07, 24 June 2026 (UTC)

  Then what's the point of WT:ITN? Might as well redirect it here if that premise is true. Left guide (talk) 05:11, 24 June 2026 (UTC)

  Then you are free to solicit input from the project more broadly- but ITN should at least be made aware of this discussion, if not it being held there. 331dot (talk) 09:14, 24 June 2026 (UTC)

To be fair, ITN was notified of this discussion - BilledMammal did the requisite notification template: Wikipedia talk:In the news#Wikipedia:Village pump (proposals) has an RfC. The main objection here is that this should have been discussed there first. Natg 19 (talk) 16:59, 24 June 2026 (UTC)

• Comment: the initial motivation or justification for the discussion appears to be the view that the presence of ten items in the ongoing list "is ridiculous". I am not a frequent consumer of ITN, but I don't understand why that is ridiculous. For example, on my device, the "From today's featured article" appears to the left of ITN and is longer than it by about two lines. By my reckoning, six additional items could be added to the ongoings, making the two modules about the same length, which would be easy on the eyes. Then again, I suppose it depends to an extent on the length of the FA excerpt. But I don't see a reason a priori why the ongoing list shouldn't have 16 (or 26) items. Is there some previous discussion about either the list length, or the comparative lengths of the FA and the ITN modules? Is there some attempt to keep them roughly the same vertical height on devices that support two columns, either formally, or by conventional practice? Or are they entirely independent, as far as length is concerned? Mathglot (talk) 10:10, 24 June 2026 (UTC)

  The goal is "balance", by which it is meant that the length of the TFA+DKY column should be approximately equal to the length of the ITN+On this day column. As I look at it now, the right (ITN+OTD) column is about two lines shorter than the left.

  Looking at the most recent 10 archived snapshots of the main page (i.e. 19 June to 23 June 2nd version): 19, 19b, 20, 20b, 21 and 21b were all balanced, in 22 and 22b the left column was about 2 lines longer and 23 and 23b the right column was about 2 lines longer. Thryduulf (talk) 10:42, 24 June 2026 (UTC)

  It's the idea of micromanaging such entries to "balance" the two-column view that is ridiculous. The majority of our readers use the mobile view which only has one column and so it's not an issue at all for them. And even the readers that use the desktop view won't care that much about a bit of white space. This also depends on other factors like the monitor size, viewing preferences, browser settings and so forth and so it's impossible to make it exquisite for everyone.

  My view is that Ongoing should be limited because of diminishing returns and less is more. There's always plenty ongoing in the world and we should focus on the items that are dominating the news, not trying to cover everything or promote particular protests.

  Andrew🐉(talk) 12:40, 24 June 2026 (UTC)

  @Mathglot: The most ridiculous thing (if any) is that we have only three blurbs documenting news stories in a section called 'In the news', and the reason for that is not their length, which sometimes happens to be, but the excessive room occupied by the ongoing and RD sections. Moreover, WP:ITNBLURB begins with Most In The News postings come in the form of blurbs., but the problem is that this is no longer the case. Therefore, either we change the ITN-related policies so that we no longer put weight on the blurbs or refrain from defending the content posted to ongoing because it's still significant. The room for ITN is limited, so it's a perfect trade-off between blurbs, ongoing items and RDs. --Kiril Simeonovski (talk) 12:58, 24 June 2026 (UTC)

  Only one of those blurbs is fresh news from this week; the other two are 10 days old and no longer in the news. Space for more blurbs is not needed until ITN figures out how to increase the rate at which it posts them. Andrew🐉(talk) 14:32, 24 June 2026 (UTC)

It only shows that we fail to serve ITN's purpose. --Kiril Simeonovski (talk) 17:41, 24 June 2026 (UTC)

• Pageviews By coincidence, 10 articles is the limit for the pageviews tool. To understand how these 10 topics are playing with our readership, please see their pageviews for this year. Only two of them have been getting the sort of massive views that indicate that there is a high level of general coverage and interest. They are 2026 Iran war and 2026 FIFA World Cup. These two routinely get daily pageviews of 100,000+ whereas all the rest rarely pass 10K. Those other topics don't stand out against the general background of ongoing issues which are often in the news such as climate change, artificial intelligence and other armed conflicts. Andrew🐉(talk) 11:38, 24 June 2026 (UTC)

  It should be noted that your view that pageviews are relevant to what ITN should and should not feature has been rejected on every single one of the many occasions you have brought it up. Thryduulf (talk) 12:52, 24 June 2026 (UTC)

  As GreatCaesarsGhost observed, everything is rejected at ITN. Andrew🐉(talk) 15:08, 24 June 2026 (UTC)

  You're free to use page views as your personal metric, as long as you understand you're largely wasting your effort. 331dot (talk) 19:27, 24 June 2026 (UTC)

  I didn't invent page views -- they have long been a standard, well-supported metric so DYK, for example, uses them to measure the effectiveness of its blurbs on the main page. The top read articles are headlined each day by the Wikipedia app which I browse every morning. They are given top billing and respect.

  But, for ITN, the app only shows new blurbs when they appear and all of ITN's repetitive clutter like Ongoing are ignored altogether. The app has been designed by WMF professionals to have a clean, fresh, engaging style. They reject ITN's hidebound format and so it's that which is wasted effort.

  Andrew🐉(talk) 06:53, 25 June 2026 (UTC)

  This is pretty interesting, thank you for the information! – Closed Limelike Curves (talk) 14:51, 27 July 2026 (UTC)

• For some reason, ITN simply cannot police itself. We suffer from some kind of analysis paralysis where every proposed change, however simple or obvious, immediately devolves into 10 tangential debates and everyone forgets to weigh in on the actual matter. BilledMammal is correct to think a proposal as ITN will go nowhere because they always do. GreatCaesarsGhost 13:23, 24 June 2026 (UTC)
  • I don't disagree that ITN has enormous problems (to the point where I've mostly disengaged from it!). Despite that, we have processes to protect volunteer time from extended unnecessary RfC participation. It's one thing to move intractable discussions to a wider venue, and a very different thing to parachute into a previously undiscussed issue (AFAIK) to drag likely dozens of editors into RfC back-and-forths. Ed ^{[talk] [OMT]} 14:36, 24 June 2026 (UTC)

  Sounds like the remedy might be to shut it down. Katzrockso (talk) 21:17, 24 June 2026 (UTC)

  Agreed, it's so dysfunctional, needs to go back to drawing board Kowal2701 (talk, contribs) 16:30, 27 June 2026 (UTC)

  We had this discussion almost exactly a year ago: Wikipedia:Village pump (miscellaneous)/Archive 82#Follow up discussion on ITN, and before that: Wikipedia:Requests for comment/In the news criteria amendments. That's enough "RFCBEFORE" for an "abolishing"/shutting down ITN RFC, so you can start one if you'd like. Some1 (talk) 16:48, 27 June 2026 (UTC)

  Tbh I've got too much on my plate atm, idk whether anyone else fancies it? Kowal2701 (talk, contribs) 17:32, 27 June 2026 (UTC)

  If anyone does, User:Levivich/ITN has mockups of potential replacements (what the main page could look like without ITN) from that old RFC. Anyone should feel free to take those pages (literally, move them) if they're helpful. Levivich (talk) 17:42, 27 June 2026 (UTC)

• I want to imagine WP:ITN came from WikiNews back in the day. WikiNews was discontinued a few months ago. – The Grid (talk) 14:41, 24 June 2026 (UTC)
  • WP:ITN says "ITN originated in the aftermath of the September 11 attacks, when entries were created and put on the Main Page within minutes of the attacks." Ed ^{[talk] [OMT]} 15:06, 24 June 2026 (UTC)
    • And Wikinews itself did not start until 2004. --Metropolitan90 (talk) 13:45, 25 June 2026 (UTC)

      also, wikinews and ITN had different goals. Bawolff (talk) 18:16, 3 July 2026 (UTC)

Request for comment on adding this week's article for improvement to the main page

This is a proposal to adapt this week's article for improvement (TWAFI) to focus primarily on helping create new editors while also improving articles. Each week a new article that is not contentious, a biography of a living person, a medical topic, or otherwise non-ideal for new editors (as determined by consensus) would be shown on the main page with accompanying text that encourages newcomers to improve it. Guidance and suggestions will also be given when editing via an edit notice. The selected article would normally remain unprotected while on the main page to allow for prospective editors to edit at any time.

Should TWAFI be shown on the main page? InfernoHues (talk) 05:19, 2 July 2026 (UTC)

• A - Yes
• B - No

If shown, what mockup should be used as the starting template? (rank from most to least preferred)

Mockup Versions

Mockup M.1

This week's article for improvement

An articulated bus, also referred to as a slinky bus, an artic, bendy bus, tandem bus, vestibule bus, stretch bus, or an accordion bus, is an articulated vehicle, typically a motor bus or trolleybus, used in public transportation. It is usually a single-decker, and comprises two or more rigid sections linked by a pivoting joint (articulation) enclosed by protective bellows inside and outside, and a cover plate on the floor. This allows a longer legal length than rigid-bodied buses, and hence a higher passenger capacity (94–120), while still allowing the bus to maneuver adequately.

Be bold and edit the article yourself! The box below lists examples of improvements you can make. If you have questions or want to give suggestions, go visit the article's talk page!

How to contribute

This article needs:

• Expansion on the topic of [X]
• WP:Reliable sources to confirm [Y]
• WP:Verification for dubious but cited claims in section [Z]

Mockup M.2

Help us improve Articulated bus!

Articulated bus

This week's article for improvement is Articulated bus, a type of vehicle found across the world! You can help make this article better by updating the history, adding information about different designs, finding sources about their use cases and limitations, and more!

Click here to start editing!

Wikipedia is written by volunteers, and that can include you, so be bold and edit the article yourself! Alternatively, if you have questions or suggestions, go visit the article's talk page! For general questions about editing Wikipedia, feel free to ask at the Teahouse.

Mockup M.3

Want to contribute to Wikipedia? Help us improve this article!

Volvo B8RLEA chassised articulated bus

This week's article for improvement is Articulated bus, a type of articulated vehicle, typically a motor bus or trolleybus, used in public transportation. It is usually a single-decker, and comprises two or more rigid sections linked by a pivoting joint.

You can improve this article by:

• Updating its information
• Fixing its grammar
• Finding reliable sources about its use cases and limitations

You can be bold and edit the article yourself. Alternatively, if you have questions or want to give suggestions, go visit the article's talk page! For general questions about editing Wikipedia, feel free to ask at the Teahouse.

If shown, where should the section be placed on the main page? (rank from most to least preferred)

Placement Options

Position P.1 (example at User:Chaotic Enby/Main Page)

TFA

TWAFI

DYK

ITN

OTD

Position P.2 (example at User:Chaotic Enby/Main Page rebalanced)

TFA

DYK

TWAFI

ITN

OTD

Position P.3 (example at User:InfernoHues/Main page mockup)

TFA

DYK

ITN

TWAFI

OTD

Background

Workshopping for this RFC occurred at Wikipedia:Village pump (proposals)/This week's article for improvement, and initial discussions can be seen here, here and here.

Articles for Improvement was previously trialled as a section on the main page in 2013. For example, see the Main Page on 10 May 2013 when the section listed Fashion accessory – List of cheeses – Life science. The trial was considered a failure and the section then pulled. An extensive status report on the project was published in the Signpost following the trial.

Survey (TWAFI)

• A - I highly recommend reading the initial statement by Bremps in the workshopping page for much more detail on the goals of this proposal. The current sections on the main page can feel 'closed off' to potential editors, so having a section dedicated to newcomers would be welcome. While not enforceable, experienced editors should be encouraged to be extra kind and patient to people editing the page, and to explain any reverts in detail without jargon.
  I prefer M.3, M.2, M.1 in that order. The most focus should be on the improvements to be made. For placement, I prefer P.1, P.2, then P.3. P.1 would make the box more easily visible on mobile, while P.2 would do so on desktop. As the majority of people worldwide use phones to use the internet optimizing for that makes sense. This should be high up on the page in order to attract new users, who are less likely to scroll down. InfernoHues (talk) 05:19, 2 July 2026 (UTC)
• P3, P2, and P1, and M2, M1, M3. 🪐Kepler-1229b | talk | contribs🪐 05:26, 2 July 2026 (UTC)
• M2 should, however, have the links bolded. 🪐Kepler-1229b | talk | contribs🪐 17:37, 2 July 2026 (UTC)
• A, P3, P2, P1, M3, M2, M1. This seems like a great idea to attract new editors. In solidarity, FantasticWikiUser_{(Ts and Cs)} 05:49, 2 July 2026 (UTC)
• Support/A. M3>M2>M1 for emphasis on improvement; Aaron Liu/sapphaline proposal (above all)>P1≈P2>P3>>P4 or similar. 7amiþ solidarity · 💬 · 📊 · 🇺🇸 05:58, 2 July 2026 (UTC)
• A, M2>3>1, P2>3>1 – I think this proposal has an excellent chance of helping create new editors by making readers aware that they specifically can edit here while also providing them with immediate guidance and a place to do so.
  For mockups I prefer 2 to start because it's direct, short and very clear. The tone is a departure from our usual dry style, but I believe using a more direct and human approach will lead to greater engagement. The article info given is just enough for new editors to know if it's something they'd like to engage with, without adding too much information or distracting links and muddying the messaging. It also provides an obvious way to begin (click here!). For position I prefer higher, more eyes means more chances someone makes their first edit.
  I'd also like to preempt some potential objections based on workshop feedback. There will be some unconstructive editing, but it will be confined to a single page, easy to handle, and well worth handling if it means new editors join the project. For concerns about potential strife between experienced and new editors, WP:BITE provides a strong backing to ensure behavior is collegial and friendly, guidance will be given to experienced editors as well about what conduct is expected, and I have faith that our editorship will be able to act constructively and aid newcomers. For editors preferring a different approach entirely, I too think we should try other approaches, but in addition to TWAFI and not instead of. fifteen thousand two hundred twenty four (talk) 06:11, 2 July 2026 (UTC)

• B in a similar vein to a portion of WP:ITNCRIT, i.e. articles appearing on the main page are evaluated based on the quality of the article and its updated content (this is invoked too harshly at times, but that is an aside). There is a time and place to draw attention to articles that need improvement; the main page is not the forum to do so unless we subject articles to a standards check and tidy them up first (which partially defeats the purpose and just creates another hassle to deal with). Moreover, the main page is primarily for readers, which is also why we exist. Catering to editors or attempting to draw in new contributors should be done carefully; this is not the way. Additionally, I imagine the extreme visibility would make the selected article a magnet for vandalism and unconstructive editing becoming another burden for patrollers. — Godsy ^(TALK_CONT) 06:36, 2 July 2026 (UTC)

  I will vote though: P4 (i.e. User:Godsy/main page mockup) & M1. — Godsy ^(TALK_CONT) 11:18, 2 July 2026 (UTC)

  ITN quality standards don't clearly apply since TWAFI isn't intended as a way to inform readers about a topic, and the messaging of "this page needs improvement" will make that clear to readers as well. As for there is a time and place to draw attention to articles that need improvement, the first sentence of the RfC clarifies that this process will focus primarily on helping create new editors. Improving articles, while good, is a secondary goal to creating new editors who can then improve many articles. Your point about the main page being primarily for readers is unclear to me, all editors start as readers, so active efforts to seek new editors by necessity must target reader venues.

  Unconstructive editing will be confined to a single page that is highly monitored, will be easy to handle, and will be well worth handling if it means more new editors. fifteen thousand two hundred twenty four (talk) 07:21, 2 July 2026 (UTC)

  If ITNCRIT applies here, then I am a pigeon and each article on Wikipedia is actually a watermelon. This argument makes absolutely no sense. Also, why is it okay to bombard users every now and then (especially on mobile clients) with a page-long ad asking for donations from the reader, but NOT okay to have a small section of the main page dedicated to getting readers to become editors? Ilov3gam3z (talk) 11:37, 2 July 2026 (UTC)

  The users who would be against AFI are much more likely to be against the banners too. That's a much longer debate. In solidarity, Aaron Liu (talk) 20:15, 2 July 2026 (UTC)

• A, M3>M2, P2>P3 – I prefer the wording of M3 the most, as it's the most inviting to potential new editors by encouraging them to contribute. For the same reason, I find the M1 is the most ambiguous and uninviting. In solidarity, nil ^nz 06:38, 2 July 2026 (UTC)
• A, I think this is really excellent. M3>M2>M1, per Nil NZ I think M3 is the most inviting to newcomers, though use cases and limitations is odd wording. P1>P2>P3 per InfernoHues, there's symbolic value in making TFA and TAFI the two most prominent, and P1 does this for mobile viewers while P2 is for desktop. Kowal2701 (talk, contribs) 07:38, 2 July 2026 (UTC)

  That wording is awkward, but it's trying to convey that the suggestions can be tailored to whatever article is selected. fifteen thousand two hundred twenty four (talk) 08:22, 2 July 2026 (UTC)

  Could’ve put [insert text here], but no worries Kowal2701 (talk, contribs) 08:26, 2 July 2026 (UTC)

• A, predicated on P1 failing. M2 is my favorite, followed by a huge drop off and then M3 and M1. On placement, P2 then P3 and oppose it all if P1. I have serious doubts that this will accomplish anything, certainly not article improvement and I am very doubtful about gaining editors, but I don't think anybody cares about OTD and, well, ITN is ITN, so its fine in the right column if it doesn't bother with TFA and DYK balancing-wise. I have also made my feelings known about the fact that I don't think any of the mockups are that great (why are we linking be bold or the Teahouse on the main page??), but M2 is best for only including minimal distractions. 1brianm7 (talk) 07:53, 2 July 2026 (UTC)

  To quote my very first comments on this proposal, 53 days ago, If there is consensus for this, it should probably not be weekly, but daily. Most of the content which does reach the main page in ITN and DYK (presumably OTND as well, but I know nothing about that) is improvable, but almost all of the improvements happen quickly I stand by that and would support daily over weekly. I think any hopes of article improvement are a pipe dream unless we abandoned editor recruitment, and if we abandon that count me against any position above TFP or TFL. In my eyes, we are shoving an edit button in the face of the uninitiated in the hopes that they randomly get bit by the itch. I think I now prefer P3 to P2, by a smidge, and am equally as supportive of proposals that would not interfere with the operation of DYK or TFA, such as but not exclusively P4. 1brianm7 (talk) 12:51, 5 July 2026 (UTC)

  Random idea: replace TFL with AfI on days TFL don't appear (that being Tuesday, Thurs, Sat and Sun)? Hason-LEK-SIN ● Let’s chat! ● My contribs 13:16, 5 July 2026 (UTC)

  I'll support daily (TAFI) so a wider variety of interests can be caught, but only if we implement a random or semi-random selection process (too much work otherwise). 7amiþ solidarity · 💬 · 📊 · 🇺🇸 17:10, 5 July 2026 (UTC)

• A, M2>M1>M3, P3>P1>P2 per my comment on the discussion. M2 is more new editor friendly. P3 is the best because harly anyone really cares about OTD. Warm Regards, Miminity (Talk?) (me contribs) 08:41, 2 July 2026 (UTC)
• A: Recruiting new editors is essential for the success of Wikipedia and this proposal sounds like a good way to achieve this. M3: The important feature here are the prominent examples of what can be improved. I have no preference about placement. — Preceding unsigned comment added by Joe vom Titan (talk • contribs) 09:00, 2 July 2026 (UTC)
• A, M.2 > M.3 > M.1, P.2 > P.1 > P.3. FaviFake (talk) 09:54, 2 July 2026 (UTC)
• A, M3>M2>M1, P2>P3>P1 I begrudgingly accept this is a good idea despite not personally liking what it does to the current main page, as I'm not the target audience here. M3 over M2 over M1 as M3 gives good info and M1 is unwieldy. As for the placement: I see what people are saying about putting it next to TFA, and I do like that, but P1 is off the table for me because of the decision to prioritize ITN and OTD over DYK there. I'd support putting TAFI where DYK is if DYK was placed where ITN is and ITN was placed where OTD is. People supporting P1 have not given a rationale for this, and I can't think of a satisfactory one. Also isn't there some way we can make TAFI 2nd on mobile and go where ITN currently is on desktop? –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 10:05, 2 July 2026 (UTC)
• A: Support. The better Wikipedia gets, the harder it will become to edit. Take, for example, Mobile, Alabama. This article has grown naturally and has been brought up to date and up to snuff through both informal and formal review processes over decades. It has: over 30 photographs taken by Wikipedia editors, a dozen or so public domain images, over 300 citations (including to out-of-print university press books), and dozens of formatting templates like {{Infobox settlement}}. You can contrast this against the earliest version of the article. On 11 January 2002, RjLesch wrote: "City in Alabama, United States of America. Four members of the Baseball Hall of Fame were born in Mobile: Hank Aaron, Willie McCovey, Satchel Paige and Ozzie Smith." That's it. The strategies used to bring in editors circa 2002 won't be applicable today. We need ways to onboard new editors rather than encouraging them to boldly make good faith edits and then immediately reverting. One line of opposition to this proposal came from concerns around having so many people work on the same article; I actually think this is a strength because it gives folks who want welcome new editors a designated article to watch. Additionally, as an admin, I'll volunteer to watchlist WP:ERRORS for the duration of the trial run. Rjjⁱⁱⁱ (talk) 10:07, 2 July 2026 (UTC)

  @Rjjiii any preference for which mockup to start with and positioning? fifteen thousand two hundred twenty four (talk) 10:58, 2 July 2026 (UTC)

• A, M2 > M3 > M1, P1 = P2 > P3. Thank you all for workshopping this into an RfC. I really think this is an important way to engage new editors, and for that reason the placement on the MP should be front and center. Agnostic on P1/P2 since they're more prominent on mobile/desktop respectively. From the mockups, M2 is the most snappy and funnels potential editors most directly with the prominent call to action. YuniToumei (talk) 11:09, 2 July 2026 (UTC)
• Support. A, M3 > M2 > M1. P2 > P3 > P1. Thank you to the other editors in the previous village pump discussion to working this into an RfC! I sincerely hope this passes. — Preceding unsigned comment added by Ilov3gam3z (talk • contribs) 11:31, 2 July 2026 (UTC)
• B The idea has potential and the main page could use some fresh ideas. But there are numerous problems with this proposal as it stands including
  1. The proposed process works on a weekly cycle but main page sections have a daily cycle. An article such as List of Syrian cheeses does not merit a full week of exposure on the main page when our featured articles only get a day.
  2. The improvement process lacks structure and specifics. For example, the mockup suggests Articulated bus. This is a very mature article which was created over 20 years ago and has had over 800 editors since. It only has one cleanup template and that was added in 2017. The first thing I would do to improve that article is remove that template as it is obviously stale and confusing.
  3. The article selection process is not random as has been misleadingly suggested. Instead, there is a nomination process which is adversarial with Support/Oppose votes. In my experience of ITN, this is toxic as it generates conflict and chat rather than actual improvement. ITN limits the possibilities to those topics which are in the news but this is so open that I expect the nominations would soon overflow.
  4. An article which is on the main page for a week is in the spotlight. This is the worst possible place for new editors who will want to make their mistakes in a quieter and less conspicuous setting. The spotlight will tend to attract a different sort of editor.
  5. This idea has been tried before and failed. I don't get the impression that this is any different.
• Andrew🐉(talk) 11:32, 2 July 2026 (UTC)

  1. There is no rule stating that everything on the main page has to be daily. ITN disregards this, too.

  2. Articulated bus was the AFI (Article for Improvement) that day, so that is why. Blame AFI, not TWAFI. (Side note: I am sure that this will boost attention to AFI and their picks will get better)

  3. We really do not have consensus on how to vote them in, if they should be automatic or hand done.

  4. Well then some editors will simply not use TWAFI and will edit in more remote corners of the site. I see no problem with this. As long as we bring in even one new and good editor, this is a success in my book.

  5. We are in a much worse predicament then we were the last time we tried this. Editor retention and gain of editors is down immensely and we are being drowned with AI vandalism. We need new editors at any cost. Also, this proposal seeks to have a lot less moving parts (the human element) in hopes of not doing what bogged down the last proposal like this one. We have done a lot of work to differentiate the two. Ilov3gam3z (talk) 11:45, 2 July 2026 (UTC)

  At the worst case, we do a trial run and at the end it fails and we remove TWAFI from the main page. At least give it a try. Ilov3gam3z (talk) 11:46, 2 July 2026 (UTC)

  That's kind of what I'm thinking. If this is a complete flop then WP:CCC. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 12:03, 2 July 2026 (UTC)

  I itch to rebut the badgering but this is not the place for threaded adversarial discussion, which tends to be toxic. Instead, I've been looking at the List of Syrian cheeses which is so problematic that it demonstrates how clueless this process is. Its issues include:

  1. It turns out to be a list of Levantine cheeses and so the current page title is misleading.
  2. The Levant is a highly controversial place as it includes places like Armenia, Israel, Palestine, Syria, Lebanon and other hot spots.
  3. The controversies in this region are not just geographical and religious but also extend to the foods such as the famously lame case of Hummus and friends.
  4. Looking at the history of the page, it started as Syrian cheese and its entire content was [stub] really good mida de tern cheese. kind of like feta but moreod ld ir So, this is not a serious topic IMO; it's more of a joke.
  5. These issues make this a really bad starting point for a new editor. Highlighting it on the main page for a week would make Wikipedia a laughing stock.

  Andrew🐉(talk) 12:39, 2 July 2026 (UTC)

  We would obviously be more careful about our selections if the proposal were to gain consensus. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 13:05, 2 July 2026 (UTC)

  No, you obviously wouldn't be more careful because no care was taken in this high-profile case. "You never get a second chance to make a first impression" and this is especially important with new editors. The AFI crew clearly can't be trusted. Andrew🐉(talk) 13:09, 2 July 2026 (UTC)

  "The AFI crew clearly can't be trusted."

  Do you have to put down your fellow editors to make your point? If there are so many problems with this article, then the AFI crew is doing it's job and doing it well. When we implement TWAFI, AFI will obviously have a slightly different purpose and more people will join the group of AFI editors with the purpose of working on TWAFI specifically. As such, the AFI's will become more new-editor friendly. We can, at the very least, give this idea a trial run and if it fails remove it. No harm done whatsoever. Ilov3gam3z (talk) 13:46, 2 July 2026 (UTC)

  The idea already had a trial run and it failed. Looking at the list of AFI accomplishments, they seem to peter out in 2016. The project switched from a daily schedule to a weekly schedule around then and so its glory days are long past.

  There are other fresher ideas and initiatives so perhaps they should be given some exposure on the main page instead. For example, when I browse the Wikipedia app lately, I'm invited to add a picture to an article by its Suggested edits. I've tried this a few times and it works well. It's a reasonably well-designed process because it's based on existing usage in another language and the tool walks the editor through the process in an straightforward way. Adding a picture to an article that hasn't got one makes a big difference and so it's quite satisfying.

  Other ongoing activity on my radar includes the Guild of Copy Editors drive for July and meetups in Chicago, London, San Diego and elsewhere. New editors would get a lot more out of such activities than AFI work in my experience. But it doesn't have to be either/or. A new section on the main page should list all such outreach and improvement activity, not just one single article.

  Andrew🐉(talk) 14:21, 2 July 2026 (UTC)

  "This other idea (which in your case is the Guild of Copy Editors and suggested edits on the user’s Homepage) will work/is working in attracting newcomers, so this is not needed."

  Wonderful! Let us implement both. —@Bremps in the original VPP discussion/workshopping.

  The main goal of TWAFI on the main page is to increase visibility of articles that need attention so new editors will gave a good place to start. This can complement with the other two initiatives we mentioned.

  "But (attracting newcomers) isn't the main goal of TWAFI" well, we can change that.

  And also, why are you just pinpointing on specific articles (Syrian cheese, articulated buses, politics appearing on AFI) instead of looking at TWAFI as a whole? Hason-LEK-SIN ● Let’s chat! ● My contribs 23:27, 4 July 2026 (UTC)

  Agree wholeheartedly with this. TWAFI is (and was very well stated in the previous discussion) a two-pronged proposal. 1: Improve the content of the articles in question. And 2: Acquire new editors to combat declining editor retention rates and the phenomena of old editors leaving Wikipedia. Also, no offense, but Andrew, your mention of specific articles rather then the whole proposal reads to me as a whataboutism. Ilov3gam3z (talk) 23:42, 4 July 2026 (UTC)

  To turn the "We" into a "You" is a choice of words that sticks out. What was intended to be conveyed by doing that? –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 04:15, 3 July 2026 (UTC)

  It's just ordinary English grammar. I'm not sure who "we" is supposed to be though as there are only 8 active editors listed at WP:AFIP and you guys aren't amongst them. Andrew🐉(talk) 10:47, 3 July 2026 (UTC)

  The EnWiki community.. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 12:58, 3 July 2026 (UTC)

  I've been through the history of this proposal now. It started in 2024 with a post by Bremps at Talk:Main Page. That is so long ago now that I'd forgotten that I commented at the time. There was no consensus for this as there were 6 formal opposes and plenty of other comment pointing to problems with the proposal. Problems which are coming up again now because they haven't been addressed.

  Bremps has kept pushing the idea regardless but has failed to engage with the project which still operates this feature, just dismissing it as nearly dormant. So, it's not the current AFI crew that is responsible for the obvious defects in this proposal; they have been pursuing their existing agenda of prioritising the improvement of important topics like Chess. The main responsibility rests on Bremps who has been building a castle in the air in the ivory tower of the idea lab.

  Andrew🐉(talk) 14:45, 4 July 2026 (UTC)

  Looking at the graph of editors who have made at least ten edits in a month plotted against date of first edit, I don't perceive much significant change in editor retention comparing 2012 to, say, the past four years (medium-term retention seems to have gotten a bit better, if anything). The active editor counts over the last 5 years seems roughly stable (perhaps a slight upwards trend this year). The new registered users counts are decreasing, but if the editor retention stats are indeed roughly stable, then the drop hasn't affected how many editors stay around and edit. isaacl (talk) 16:06, 3 July 2026 (UTC)

  ITN often wades into politics. AFI has guidelines to never wade too closely into politics. I do not think this will be nearly as toxic as ITN, and for that argument to be a demerit, AFI would have to be more toxic than ITN, which is impossible. In solidarity, Aaron Liu (talk) 17:40, 2 July 2026 (UTC)

  Politics was actually nominated successfully at AFI. The actual prohibition seems to be "controversial" articles, meaning those with "heated discussion, edit warring, or questioned notability" and so they might be any kind of topic. The nomination discussions often seem to raise the issue of "importance" which is just like ITN's "significance". AFI is currently a backwater but if its articles get a week on the main page, we should expect some escalation. Andrew🐉(talk) 19:54, 2 July 2026 (UTC)

  Well in the past, AFI was aimed at people who were already editors. Should this proposal gain consensus, the criteria would accordingly shift (if not officially, de facto) because of the new crop of editors who would be interested in the process. Importance shouldn't be a factor for the proposed purpose. The goal would be to find articles that need improvement, but not so much that they can't be on the main page. InfernoHues (talk) 20:00, 2 July 2026 (UTC)

  If you read the fine print of this proposal (the discussion before the RfC) you would know that we will try to steer clear of contentious topics. AFI was aimed at things to be fixed by experienced editors, now we will simply aim it towards problems to be fixed by new editors. Ilov3gam3z (talk) 20:09, 2 July 2026 (UTC)

  I don't understand your disconnect here. Your argument reads (at least to me) "I know we will avoid contentious topics but that might happen anyway (mechanisn?) and cause arguments and edit warring in the contentious article (which, as detailed in this discussion wont happen)." ??? Ilov3gam3z (talk) 20:13, 2 July 2026 (UTC)

  calm In solidarity, Aaron Liu (talk) 20:16, 2 July 2026 (UTC)

  I do admit the irony, but I consider Politics the article as not too close into politics because it has very little heat. Importance might be an issue, but there's always enough articles whose topics completely avoid that debate because everybody agrees they're important enough, such as Articulated bus. Unlike ITN, there's no pressure for the items to feel current (and nominations take a very long time to become stale), so we'd still have a healthy AFI queue. In solidarity, Aaron Liu (talk) 20:12, 2 July 2026 (UTC)

  Bendy buses used to be quite a hot topic in London and getting rid of them was one of Boris's big achievements as London mayor. There's a current AFI nomination for the Reform candidate in Makerfield and that's about as political as it gets. It hasn't had much attention and no-one seems bothered that it is so political. Andrew🐉(talk) 20:35, 2 July 2026 (UTC)

  That's still not hot enough that it becomes contentious in editing.

  I would oppose Robert Kenyon as an AFI candidate; besides the other reasons, it is a BLP. No one seems bothered about the political part because the AfD nom is an even bigger and obvious reason to oppose it. Note that receiving no supports results in an automatic fail. In solidarity, Aaron Liu (talk) 21:20, 2 July 2026 (UTC)

• B (No) or place it below the four main sections (TFA, ITN, DYK, OTD). Which would readers rather see on the main page: a box telling them to improve a random article (that they most likely have no interest in editing), or a box that lists current world events? I know I'd choose the latter, because a large, static section on the main page whose content changes once, weekly is, imo, boring. Plus, the primary purpose of the proposed TWAFI template is to apparently "create" new editors, but I'm having a difficult time believing that it'll accomplish that. If few existing editors are editing List of Syrian cheeses (this current week's article for improvement), why would a brand new editor be interested in improving that article? From their POV, the article looks to be in already decent shape, especially if it's after Day 2 of being featured. Besides, "improving" the article means the new editor must take time to do research on Syrian cheese and add a reliable source to the article. If they get reverted because they added unsourced content, original research, or an unreliable source? That'll discourage them from further editing. And as another editor said above, the article selected for TWAFI will be a magnet for vandalism and LTAs, especially if it's placed so prominently on the main page and with a call to action to edit it. That being said, I don't mind it being on the main page, but I don't see any benefits to having it placed above the four main MP sections. Some1 (talk) 11:34, 2 July 2026 (UTC)

  Prior TWAFI articles, such as List of Syrian cheeses, were not chosen with a primary focus of engaging new editors. The revert argument is non-specific to TWAFI, any new editor could be reverted at any article, the difference here is that a TWAFI page will be monitored by editors acutely aware of WP:BITE and who will be actively seeking to assist newcomers. fifteen thousand two hundred twenty four (talk) 12:27, 2 July 2026 (UTC)

  If I had to choose, I would place the TWAFI box below Today's featured picture. For the main page, dynamic, quality content should be the primary focus, with attempts to recruit new editors second. Some1 (talk) 22:35, 2 July 2026 (UTC)

  @Some1: I suggested P4 (User:Godsy/main page mockup) above, which I believe is similar to what you are suggesting. — Godsy ^(TALK_CONT) 23:29, 2 July 2026 (UTC)

  Thanks for creating the mockup... Seems like having 2 boxes in the left column and 3 boxes in the right column will make the MP look uneven on desktop view (there's a large empty space in the DYK box). Looking at the proposed placement options above in the OP, all of them will also have that same issue on desktop mode. I prefer what's in User:ONUnicorn/sandbox, but with the TWAFI template in a shade of yellow or another color. An alternative would be to place the TFP box in the first column below DYK and the TWAFI box in the second column below OTD; that way there's 3 boxes in each column. Some1 (talk) 23:48, 2 July 2026 (UTC) Forgot there's a "Today's featured list", so striking. Some1 (talk) 00:33, 3 July 2026 (UTC)

  You could also show more of TFA to fill up the space. More DYKs are an option as well, but it might not be possible to promote that many hooks. InfernoHues (talk) 00:05, 3 July 2026 (UTC)

  I concur that the imbalance is a problem. The bottom does seem to be the best course of action for that reason and to keep the traditional, longstanding stuff in the expected locations. — Godsy ^(TALK_CONT) 01:53, 3 July 2026 (UTC)

• A x20. This is a very good idea because thats exactly what Wikipedia should do to encourage more newcomers to start editing tasks, one of the best features about Wikipedia. M.1>M.3>M.2 and P.2>P.3>P.1
  (talk with this worm) 12:39, 2 July 2026 (UTC)
• B Per Some1's recent comments. If it must be done, send it as far down the page as possible.--Wehwalt (talk) 13:11, 2 July 2026 (UTC)
• I very much vote A!
  My the mockup version I prefer is M.2 and the position I prefer is P.1.
  --I sometimes eat bananas, and you can talk to me here: (talk) 13:22, 2 July 2026 (UTC)
• A and M3 > M2 > M1. As for placement, I actually don't prefer any of the placements except for P3, but like Wehwalt and Some1, this should probably be placed below the existing content (e.g. where TFL is located). However, if we had to choose, then P3 > P2 > P1. I really prefer that TWAFI not be placed above DYK and would want that to be the absolute last resort, as DYK has already been closely vetted, and that would very negatively affect DYK pageviews. I am less opposed to putting it above ITN (which is less closely vetted than DYK) and OTD (which is even less closely vetted than either ITN or DYK). – Epicgenius (talk) 13:22, 2 July 2026 (UTC)

  I echo this concern about hiding DYK. It's a place editors can showcase articles they worked on without requiring it to get all the way to FA level, and is, in my experience, very popular among editors for that reason. It's a great incentive to get editors putting some effort into articles, and a more valuable part of the main page than ITN and OTD are. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 14:07, 2 July 2026 (UTC)

  I would agree that it should not go above DYK. I feel that this would work well as a landscape bar at the bottom like TFL. MallardTV ^{Talk to me!} 16:42, 2 July 2026 (UTC)

• A and M3 > M2 > M1 and P1 > P3 > P2, with the caveat that in P1, I'd rather have it below DYK instead of above. --SarekOfVulcan (talk) 13:50, 2 July 2026 (UTC)

  Having TWAFI below DYK would be suitable for me, too. – Epicgenius (talk) 13:58, 2 July 2026 (UTC)

• A, support P2 > P3 > P1 and M2 > M3 > M1 per my comments in the previous discussion. Agree with Epicgenius that having it above less closely vetted sections like ITN and OTD is preferable to having it above DYK. I don't like the idea of setting it up for failure by making it as invisible as possible to conclude that people aren't interested. Chaotic Enby (in solidarity · talk · contribs) 15:04, 2 July 2026 (UTC)
• A (support), for largely the same reasons that have been discussed to date. Regarding the language, my order of preference is M3 > M1 = M2. Regarding placement, my order of the three proposed placements is P1 > P3 > P2, but a hypothetical P4 that places TWAFI below DYK would be on par or even better than P1 imo. ModernDayTrilobite (talk • contribs) 15:05, 2 July 2026 (UTC)
• No opinion on whether we should, but do not disrupt the top four boxes.--Launchballer 15:10, 2 July 2026 (UTC)
• A, M3, P1 Ktkvtsh (talk) 15:19, 2 July 2026 (UTC)
• A, M.3> M.2> M.1, P.None of the above, mainly per Epicgenius. This is a great idea that deserves visibility, but I reluctantly think it seems more suited to a place further down the page (i.e. above "Other areas of Wikipedia") to avoid obscuring any featured/vetted content. If we must choose now, P.3 > P.2 > P.1 seems the most reasonable. UpTheOctave! • 8^va? 15:55, 2 July 2026 (UTC)
• B (oppose) per Andrew and Some1. It does not appear that there is enough vetting at AFI, and also don't feel that this is something that would help new editors. In addition, the "weekly" cycle thing is a concern, as that makes the MP stale. ITN also has a problem with this, but that is a separate issue. Natg 19 (talk) 17:29, 2 July 2026 (UTC)

  If this is approved, I prefer M2 or M3, as M1 has a generic title bar and does not have an "appeal" to edit. In addition, I do like the idea of "ways to contribute" or "how to contribute", which presumably has specific suggestions and is not just boilerplate language. No preferences on positions. Natg 19 (talk) 17:33, 2 July 2026 (UTC)

  For what it's worth, there was some discussion on making it daily, but weekly was chosen to start with since we don't know for sure how effective this will be yet (will all basic improvements be made in a day, or will the full week be needed). InfernoHues (talk) 18:06, 2 July 2026 (UTC)

• A, M3, P3 In the News should come first, then an article for improvement. M3 has explicit suggestions for how to imporve the article. --Enos733 (talk) 17:36, 2 July 2026 (UTC)
• A as I find oppose arguments unconvincing (per replies above) and prefer M.3: Potential improvers should know most how they can actually change up the article. M2 does have these suggestions but without the bulleting, it's so hidden that the last !voter did not see it. It's much less important to summarize what the article is about, because this is about improving the article, not telling you what the article's about right now. Which is also why I think M.3's first paragraph should be trimmed to just one sentence (M3A?).
  I have mixed feelings about placement as all of the available options unbalance the columns. I do agree that it should be ideally visible without scrolling, though, as that's what most of the people we want to attract do. In solidarity, Aaron Liu (talk) 17:53, 2 July 2026 (UTC)
• B (opposed). There should be various prominent links that invite editing, but having direct links to an article to edit on the Main Page with little explanation what needs to be done is not going to do much good. I expect a lot of the edits will be simple ENGVAR violations "fixing" the spelling or grammar. —Kusma (talk) 18:49, 2 July 2026 (UTC)
• A, worth trying. M2 > M1 > M3, simplest call to action and least WP:INSTRUCTIONCREEP. P2 > P3 > P1, make it visible, don't touch the left column of the main page. ~ A412 ^talk! 19:08, 2 July 2026 (UTC)
• B (Oppose). The main page is for quality content that benefits readers, not primarily for recruitment of new editors. I also agree with concerns expressed above that having an article in need of improvement up on the main page for a week while most of the quality content appears for only a day is out of step with our priority of serving up quality, fresh, relevant and timely articles. Dclemens1971 (talk) 21:32, 2 July 2026 (UTC)
• A, with the following template ranking: M.2>M.3>M.1. For positioning: Aaron Liu's proposal>P.2>P.1>P.3. We can and should be doing more to recruit new editors. The template and positioning rankings I put in order of what I think would be most attention-arresting. Bremps... 21:41, 2 July 2026 (UTC)
• B (Oppose). The Main Page is already cluttered, and drawing readers into editing is already one of the purposes of DYK. (That's one of the reasons I opposed having GAs added to new and recently expanded articles in DYK, and I would regard undoing that change and reinstating the statement in the DYK section that these are among Wikipedia's most recent articles and "you can edit them" as a better way to encourage people to try editing.) I also share the concern that featuring the same article for improvement for a week while content selected for its quality is only featured for one day is something of an insult to those who worked hard to polish the quality content. Even ITN and Recent Deaths turn over faster than weekly. The underlying problem is that TWAFI is a suggestion among a multitude of maintenance and improvement tasks, including a large number of articles that are equally or more in need of improvement; it's an artificial focus, while what we need to ensure readers are aware of is that editing in general is welcome, no matter what they want to fix or add. (Yes, they can even edit TFA.) Showcasing one article as in need of improvement actually undercuts the message that this is an encyclopaedia, but it's also an open wiki. Yngvadottir (talk) 22:31, 2 July 2026 (UTC)

  Unfortunately TFA is now automatically semi-protected for two days; see Wikipedia:Perennial proposals#Protect featured articles. That is part of why I enthusiastically supported this from the workshop stage. In solidarity, Aaron Liu (talk) 23:00, 2 July 2026 (UTC)

  Maybe we should contact the TFA editors to change this? Ilov3gam3z (talk) 15:14, 5 July 2026 (UTC)

  You are not overcoming this overwhelming consensus without some extraordinary new information. In solidarity, Aaron Liu (talk) 21:38, 7 July 2026 (UTC)

• A (Support) I know the WMF is somewhat controversial right now, but support in the spirit of meta:Wikimedia Foundation Annual Plan/2026-2027 (even if it's mostly corperate nonsense). This furthers those goals much better than the image carosal that met so much backlash a few weeks ago. Would prefer M1 as it provides article specific contribution advice, and this is purely cosmetic and not practical, but I'd put it below most of the content, probably above POTD, because I like how the mockups look in wider format. We may need to implement more thorough vetting at AFI if they do get onto the main page. ⇖ /.°°.\ ⇗ ^{(They/Them/Their)} 23:11, 2 July 2026 (UTC)

  But if I had to choose, probably P2 ⇖ /.°°.\ ⇗ ^{(They/Them/Their)} 23:24, 2 July 2026 (UTC)

• A (Support); however, I would propose it be Today's article for improvement rather than This week's article for improvement as a week is a long time to placing an article on the frontpage that is in need of improvement, especially with the amount of real-estate that will be committed. As far as preferences go, P3 -> P2 -> P1 & M3 -> M2 -> M1 in those orders. TarnishedPath^talk 01:09, 3 July 2026 (UTC)
• A No preferences for the mocks. Any would do, in my opinion. I strongly recommend P1 or a variation that puts this in the left column. ITN could use more space at times as sometimes it is either the the content in the left column being too short, or the DYK OTD section being too long that leads to entries in ITN being bumped off (temporarily). With WP:ITNBALANCE as it is, we may have to sacrifice more space than before. – robertsky (talk) 02:33, 3 July 2026 (UTC)

  To be frank, I don't think ITN (or OTD) uses the space it currently has particularly well. Why give it more? 1brianm7 (talk) 03:26, 3 July 2026 (UTC)

  ITNBALANCE reduces the space that ITN has. With this proposed section, ITN... would like be virtually gone? Unless ITNBALANCE excludes the TAFI section from consideration for balance between the two columns. – robertsky (talk) 03:33, 3 July 2026 (UTC)

  Yeah, I've said before in the workshop that I don't think the concerns about balancing and size have been adequately accounted for, and have supported concision to make the TWAFI box as small as possible. I would hope that OTD also shrinks itself if this is successful, especially since it's my understanding that OTD has the least community buy-in. And I expect more people to realize that these mockups are really too big without doing much of anything with the space once they are implemented. With this proposed section, ITN... would like be virtually gone? that's one of the strongest arguments I've heard for this proposal /hj 1brianm7 (talk) 03:58, 3 July 2026 (UTC)

  I don't see why TFA couldn't be made longer if needed to fill in the space, just show more of the article. You could also increase DYK, but that's harder. InfernoHues (talk) 04:02, 3 July 2026 (UTC)

  We could also make the two sides take 50% instead of the current 60-40 balance we have now. That, plus making TFA longer would likely solve the balance problem. ScienceD90 (she/her) (talk) 04:11, 3 July 2026 (UTC)

  The current balance is 55-45, not 60-40. And still, I'd oppose rebalancing, because I think ITN and OTD (and possible soon TWAFI) are really quite bad at using the space they have. 1brianm7 (talk) 04:20, 3 July 2026 (UTC)

  I think we might want to create a new section about the balancing issue instead of just having it in the middle of the survey section, so we can get more ideas on fixing it. ScienceD90 (she/her) (talk) 04:38, 3 July 2026 (UTC)

• A (Support) I think this would be an improvement as it helps new editors find a page that could use improvement. I vote M.3>M.2>M.1. I think M.3 is th best choice because it lists out what needs to be done on the article. M.2 has the advantage of being smaller but the list is not as visually clear, instead being embedded in the paragraph. M.1 is the worst option as it just copies the lead. For the placement, I vote P.2>P.3>P.1. I think this section should be at the top so the most editors see it. I have ranked the placements based in how high the new section would be. ScienceD90 (she/her) (talk) 02:39, 3 July 2026 (UTC)
• A, we can easily remove it if it doesn't live up to expectations. That being said, it has to be executed in a way that's mindful of TFA. It's ridiculous to have our best editors toil away to write a featured article for the hopes of getting 1/7 of the exposure some randomly selected article will. With that in mind, M3>M2>M1 (though the exact wording will need some improvement), and P3>P2>P1, though I wouldn't be opposed to putting it under TFP as some have suggested. JustARandomSquid (talk) 07:35, 3 July 2026 (UTC)
• A, as when last discussed I'm generally supportive of this idea. However, on placement, I've come around to a long horizontal placement like the mockups in the past discussion. This makes it more visible, but also makes it easier to remove if there is an issue/no appropriate article for that week without disrupting the rest of the main page (think of how TFL appears and disappears without causing issues). CMD (talk) 09:11, 3 July 2026 (UTC)

  @CMD do you have any preference for which mockup should be used as the starting template? fifteen thousand two hundred twenty four (talk) 10:15, 3 July 2026 (UTC)

  Thanks, missed that part of the multi-question. M3>M2, oppose M1. CMD (talk) 10:57, 3 July 2026 (UTC)

• A, no preference for placement. Agree with TarnishedPath that Today's article for improvement would be better than keeping one article on the front page for a week. Whonting (talk) 10:54, 3 July 2026 (UTC)
• A - Support, just like I did in the previous discussion. For the mockup preferences, without any other suggestions/own mockups: M3 > M2 > M1. For the placement, no preference (lean P.2) since I usually look at the whole Main page, however, my concern is that this would bury the other parts of the main page (especially ITN)
  Side note for M3, as Ilov3gam3z mentioned, they are okay with removing the indentation

Extended content

So instead of:

You can improve this article by:

• Updating its information
• Fixing its grammar
• Finding reliable sources about its use cases and limitations

Do this:

You can improve this article by:

• Updating its information
• Fixing its grammar
• Finding reliable sources about its use cases and limitations

Hason-LEK-SIN ● Let’s chat! ● My contribs 14:26, 3 July 2026 (UTC)

• A, M2>M3>M1, P1 or P2 I wouldn't link WP:bold and I would leave off the sentence about the teahouse. Rolluik (talk) 16:41, 3 July 2026 (UTC)
• A, no preference on mockups, Oppose P.1, but would prefer a P.4 as some have mentioned that puts it in a solid line across both columns above/below TFP. ~~ AirshipJungleman29 (talk) 14:39, 3 July 2026 (UTC)
• A. M2 is the most to-the-point layout, and I prefer P1, then P2, for logical placement. –LaundryPizza03 (dc̄) 16:13, 3 July 2026 (UTC)

• B (oppose) per others above. In addition to the opposing comments already made, I just feel this initiative will fail to solve the problem it's trying to solve. The process to identify the articles to improve (Wikipedia:Articles for improvement) seems to stand on weak footing - there were a lot of comments above on List of Syrian cheeses, which at least is an article can could use some love, but next scheduled on is Chess, a very complete article that will flabbergast new editors - what are they expected to improve there? I also feel that this is completely the wrong approach to get new editors. Wikipedia should rather build a social media presence, have a daily "article to improve" post on Instagram, for instance, and attract new and younger editors where they actually are spending their time. Even if this TWAFI proposal here goes through, my expectation is that it will change nothing. In terms of position (in case this goes through) I echo others: don't mess with the parts on the main page that work for this hail-mary expirement. Khuft (talk) 18:39, 3 July 2026 (UTC)

  Good point about Chess. That was not nominated because it would be suitable for newbies but because it was a former featured article and was level-4 vital. That nomination was in 2023 and the AFI pipeline is full of such high-stakes articles. Pivoting the project to be a training ground hasn't been thought through and simply won't work as there's no way that the chess project's fanatics will let newbies mess with their most important article. The article has had over 3,800 editors to date and is already semi-protected due to vandalism. Andrew🐉(talk) 19:11, 3 July 2026 (UTC)

  I personally think the chess article is at least GA level, and I dread it going through a flurry of edits. Edits to it from new or anonymous editors are usually not very good. MaxBrowne2 (talk) 02:55, 4 July 2026 (UTC)

  This was a bad idea. It's not a matter of WP:OWN, rather wiping years of intelligent article evolution by inexperienced editor(s). Who thunk this up?? --IHTS (talk) 06:08, 7 July 2026 (UTC)

  The edit history of Chess, now AFI for two days, says otherwise. In solidarity, Aaron Liu (talk) 21:40, 7 July 2026 (UTC)

  My take is that an inexperienced editor, Chuddite, has rushed in to do some bold restructuring of the Chess article without prior discussion. More experienced editors are now talking about reverting this: we should revert to the earlier and superior organization ... Agreed. Revert. ... I hope we don't get too many more "improvements". And that's without any completely new editors attracted by a post on the main page. They wouldn't be able to edit the article because it is still protected. Andrew🐉(talk) 22:34, 7 July 2026 (UTC)

  My take is that it's still a net positive. The first comment you're quoting starts with Some of the recent reorganization is bad., my emphasis on Some. In solidarity, Aaron Liu (talk) 00:54, 8 July 2026 (UTC)

  When making the RfC, we didn't consider what articles would be chosen. Bremps, the proposer, said the articles would have to be randomly chosen. I think TWAfI needs to be C-class or less, too.
  To quote Bremps: "This other idea will work/is working in attracting newcomers, so this is not needed." Wonderful! Let us implement both. 7amiþ solidarity · 💬 · 📊 · 🇺🇸 19:14, 3 July 2026 (UTC)

  The worry I have is that there are several people who have said that as part of the process X will happen, but no one saying (not even Bremps) that they will personally work on making X happen. I think a lot of details can be worked out through local discussion, but I'd feel a lot more reassured if there were actual volunteers stepping up and saying they will be working on the details and participating in the day-to-day work. isaacl (talk) 21:39, 3 July 2026 (UTC)

  I'll definitely be around when this is getting off the ground to weigh in and help, but I definitely imagine this to be non-adversarial and relatively light when the novelty wears off. Bremps... 22:01, 3 July 2026 (UTC)

  I'll definitely be there to help as well. InfernoHues (talk) 22:59, 3 July 2026 (UTC)

  I'll be there to help, too. 7amiþ solidarity · 💬 · 📊 · 🇺🇸 00:35, 4 July 2026 (UTC)

  I will personally work on making X happen. fifteen thousand two hundred twenty four (talk) 04:01, 4 July 2026 (UTC)

  I suggest getting the process going now, producing weekly versions of what would be posted to the main page, to better understand the day-to-day work required, and what automation may be desirable. I think establishing a track record of having content prepped, enqueued, and ready, as well as finding volunteers to implement any required automation, would help reassure the community that the initiative can regularly update the main page. isaacl (talk) 16:50, 4 July 2026 (UTC)

  Bremps signed up as a participant of TWAFI in August 2025. They are not now listed as an active member of that project because the only thing they seemed to do was post a link to the Idea Lab which seems to be the actual place this idea was cooked up. So far as I can tell, Bremps has never nominated an article for TWAFI nor even discussed someone else's nomination. They seem to have zero experience of the project and yet they propose to take it over, transform it and put it on the main page. But note that they are not an admin and admin rights are essential for main page activity. Andrew🐉(talk) 07:14, 4 July 2026 (UTC)

  This is not a proposal for Bremps to take over or head TWAFI, it's a proposal for a new community process, of which there are many community members offering their support.

  Concerning needing admin permissions, 7 admins have supported this proposal so far. fifteen thousand two hundred twenty four (talk) 07:35, 4 July 2026 (UTC)

  This is not a new process; it's the existing process of Articles for Improvement which has existed since 2012. This RfC is only to determine whether the current article for improvement should be posted in a section on the main page. And this idea isn't new either as this was already tried in 2013. Andrew🐉(talk) 14:58, 4 July 2026 (UTC)

• A. I think this is an excellent proposal and will help recruit new editors to Wikipedia and bring more attention to articles that really need it. I prefer M2, M3, M1, especially M2 because it suggests to newcomers what kind of improvements can be made to the article and gives an easy link to start editing. However I oppose all of the proposed placement options. I agree with concerns that there needs to be a clear distinction between featured content and an invite to participate in editing. Therefore, I think TWAFI should be in another color such as yellow or orange and placed below the featured content, like this:

Extended content

Position P.5

TFA

DYK

ITN

OTD

TFP

TWAFI

I think this could be a good way to implement the proposal while keeping all existing main page content visible. Just a thought. MidnightMayhem (talk) 00:49, 4 July 2026 (UTC)

The problem with this is that then most people won't see it, which defeats the purpose. --I sometimes eat bananas, and you can talk to me here: (talk) 02:06, 4 July 2026 (UTC)

I like the colour difference, but the burying at the very bottom though… 🫩 Hason-LEK-SIN ● Let’s chat! ● My contribs 06:28, 4 July 2026 (UTC)

The idea of placing TWAFI down there with the featured picture did come up in the previous discussion. It was generally rejected because not many people would see it. In fact, several people admitted they did not even know there was a featured picture section on the Main Page. ScienceD90 (she/her) (talk) 11:59, 4 July 2026 (UTC)

• A. Great idea. Opposers who suggest there are many other maintenance tasks to get into are missing that many people don't know they can edit Wikipedia at all. DYK doesn't motivate them to edit; they don't know they can write DYKs and have no idea how articles are chosen for it. I am not terribly particular about position or mockup, but I don't like how P1 puts it above DYK. The FA and DYKs ought to have high billing on the page and this shouldn't displace them. In solidarity, asilvering (talk) 02:51, 4 July 2026 (UTC)
• B (Oppose) per Andrew. Also, I believe new editors are likely to edit within their own niches, rather than edit related to Syrian cheese just because the Main Page suggested it. Nice4What (talk · contribs) ♥ 03:46, 4 July 2026 (UTC)
• B. I'd rather see this on the Community Portal, not MainPage. There is no way to predict whether a wikiarticle will improve enough after a week of collaborative editing to be featured on MainPage. Prefer featuring FAs on MainPage. And then, there is DYK to feature recently upgraded wikiarticles. After TWAFI, improved wikiarticles can go through GA review and qualify for DYK to get on MainPage. --PFHLai (talk) 08:48, 4 July 2026 (UTC)

  The point of TWAfI really isn't to improve articles but to help editor retention. As @asilvering pointed out, many people don't know that DYKs are for them to write. I also doubt that most people know a Community Portal even exists (as a moderately new editor, I sure didn't). 7amiþ solidarity · 💬 · 📊 · 🇺🇸 14:30, 4 July 2026 (UTC)

  7amithorn is only 2 months old and so still has much to learn. Articles for Improvement is 14 years old and its formal goals do not include editor retention:

  The project's four main tasks are to:

  • Coordinate and collaborate to improve articles.
  • Identify candidate articles.
  • Select the order they appear on the community portal in the Articles for improvement section.
  • Assess and track our accomplishments.

Andrew🐉(talk) 15:31, 4 July 2026 (UTC)

Or it could be that 7amiþ is talking about the refocused version of TWAFI proposed here, the topic of discussion, which in the first sentence states This is a proposal to adapt this week's article for improvement (TWAFI) to focus primarily on helping create new editors. From my 3 year 9 month old account, fifteen thousand two hundred twenty four (talk) 15:51, 4 July 2026 (UTC)

That's preamble which seems to be a false premise. The specific and only RfC question is Should TWAFI be shown on the main page?

Note that there's already an existing project devoted specifically to editor retention. It's WikiProject Editor Retention. Trying to repurpose AFI to do the same thing is silly and further demonstrates that this proposal has not been thought through.

Andrew🐉(talk) 16:04, 4 July 2026 (UTC)

I agree with Andrew. As I noted above, I feel the whole initiative is starry-eyed passion project without a clear strategy to achieve its goals. Is it aimed at finding new editors or at editor retention (two completely different goals)? If the first, why do we think a random "article to improve" like List of Syrian cheeses, or Chess, would attract new editors? Do potential new editors even go to the main page, or do they access the info they need via links to specific pages via Google (or an LLM)? Wouldn't it make more sense, as I mentioned above, to reach out to younger, potential editors via e.g. social media? If the aim is editor retention, how is throwing a random article at people that have disconnected from editing (probably because they have jobs and a family nowadays) going to rekindle the fire of editing? Will they really go and look out for Syrian cheeses in order to improve that article? Will they scan the Chess article to see where they can potentially improve the grammar? Sorry for the snarky tone, but I feel a lot of effort is going into a white elephant initiative. Khuft (talk) 16:17, 4 July 2026 (UTC)

The selection isn't Special:Random, there's criteria given in the second sentence of the RfC, one of which is that pages cannot be "non-ideal for new editors". One way an article for improvement could help attract new editors is by making them personally aware that they can edit (not everyone is aware of this) and that we actively want them to edit (ditto), and then providing them with an immediate place to try editing (with suggestions and help).

We can and should try multiple ways to bolster editorship. I don't see why trying social media outreach (not really something we can handle on our own, though the WMF does do some, did you know there's a Wikipedia roblox game?) would mean we can't also try TWAFI.

As for retention vs onboarding, I believe that an accessible, positive, and structured first edit experience, as this proposal aims to provide, would lead to more new editors who also stick around longer. fifteen thousand two hundred twenty four (talk) 17:08, 4 July 2026 (UTC)

I say new editors. With all the articles selected, there's eventually bound to be one whom someone's interested enough to take a look at and see how they could improve. The main page has extremely more page views than we have editors, (is generally not scraped by LLMs due to its lack of information,) and an appearance on the main page tends to attract improvement even by new editors.

Wouldn't it make more sense, as I mentioned above, to reach out to younger, potential editors via e.g. social media?

Is this proposal preventing that? In solidarity, Aaron Liu (talk) 17:17, 4 July 2026 (UTC)

I wrote most of that preamble. I don't appreciate having my efforts characterized as being a false premise (AGF?), regardless, the preamble is what opens and defines the RFC, This is a proposal to ..., and is binding. If you're curious why it's worded how it is see this thread. fifteen thousand two hundred twenty four (talk) 16:22, 4 July 2026 (UTC)

It is not compliant with WP:RFCBRIEF or WP:RFCNEUTRAL. The final question is simple and clear but the preamble isn't and so shouldn't be there. Andrew🐉(talk) 17:23, 4 July 2026 (UTC)

Both those link to the same place. If you believe the RFC is procedurally unsound (though you appear to be alone in this assessment thus far), then feel free to move for a procedural close. fifteen thousand two hundred twenty four (talk) 17:28, 4 July 2026 (UTC)

I've re-read the opening statement and I entirely fail to see what you could mean in saying that it isn't brief and neutral. The preamble briefly states the goal of the proposal, without making any claim as to whether or not it will be achieved, and other than that only contains information about what an affirmative consensus would actually entail.

I check every RfCs opened, in part to check if their opening statements are compliant and suggest fixes they aren't, and this one is better than the vast majority of them. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 21:11, 4 July 2026 (UTC)

Yeah, I think this RFC is fine too. And I'm saying that as somebody who isn't on board with the entire idea, either. (Just saying, I found being pointed to stuff like TWAFI rather demoralizing when I was getting into editing: I didn't know where to start, the topics often weren't of any interest to me, and I didn't know where to start with finding sources. Being told "this is a good place to start" and then failing just made me feel inadequate. But I'm not the only editor, and others seem to see something in this, so I wish them nothing but luck.) GreenLipstickLesbian💌🧸 21:23, 4 July 2026 (UTC)

Yeah, it's fair to say this won't work for everyone. I personally found the similar WP:Task Center very useful when I started, and used it often. My biggest issue was that I would get no feedback if what I was doing was "correct." That's why I supported this proposal, as kind of an extension of that. InfernoHues (talk) 21:28, 4 July 2026 (UTC)

Yeah, i definitely feel that lack of feedback thing. I know was really lucky to run into the Women in Red project several years ago; a bunch of enthusiastic editors willing to help out but also let me make mistakes, is something I wish I could give to all editors. That and their monthly editing drives/newsletters I was subscribed to still keep me going. GreenLipstickLesbian💌🧸 05:40, 5 July 2026 (UTC)

@Andrew Davidson, please don't be condescending. In my opinion, it's precisely the opinions of newer editors that matter more when we're talking about efforts to create new editors. In solidarity, asilvering (talk) 20:29, 4 July 2026 (UTC)

I have them a level one warning. See it on their talk page. Please tell me if this is appropriate. Ilov3gam3z (talk) 23:13, 4 July 2026 (UTC)

As for my reasoning, among other things, the '2 months old comment' seems to me to be a direct violation of WP:NPA. Ilov3gam3z (talk) 23:15, 4 July 2026 (UTC)

• A, M2>M3>M1 and P2>P3>P1. I'd also be fine with the alternate suggestions of placing it below DYK or in a box above TFP, but I don't like the idea of placing it above DYK. I agree with TarnishedPath and with some of the opposers that the weekly cycle is not ideal, so I think moving to a "Today's article for improvement" is worth considering as a next step once things are running smoothly if this is implemented. MCE89 (talk) 18:37, 4 July 2026 (UTC)
• A, but oppose all of P.1, P.2, P.3 I think this is a good idea in order to draw in new editors. However, more important to me is that the four mainstays of the Main Page (TFA, ITN, DYK, OTD) should stay in place. If I had to pick one of those for TWAFI to displace, it'd be DYK (in other words P.1 is the least bad of the three options), but honestly I still prefer DYK for that space over TWAFI. I like Godsy's P.4 and MidnightMayhem's P.5. No preference among the mockups M.1, M.2, M.3. Davey2116 (talk) 07:15, 5 July 2026 (UTC)
• A. Per it being a good idea. jp×g🗯️ 07:49, 5 July 2026 (UTC)

  @JPxG do you have any mockup and positioning preferences? fifteen thousand two hundred twenty four (talk) 08:58, 5 July 2026 (UTC)

• A: I've read through every oppose argument and did not find any to be compelling. I'm not sure why people are making a big deal about whether this is aimed at editor recruitment or editor retention; regardless of what effect it has on those this will make AFI a more useful place. (At the minute it seems to be largely ineffective.) Also support keeping the article for improvement on the main page for a full week as one day is not enough for significant change. No opinion on placement. Stockhausenfan (talk) 11:09, 5 July 2026 (UTC)
• B (Oppose) as impractical; realistically what I foresee will happen is that the suggested article would become a magnet for vandalism and consequently be semi-protected, defeating the purpose of this project. And anecdotally very few "new" editors make talk-page edit requests. I would be fine with a trial lasting, say, two-three months to gauge the editing patterns induced by this project though. JavaHurricane 14:57, 5 July 2026 (UTC)

  There should probably be a stipulation in this proposal once implemented that articles chosen must not be protected and can't be for the week of. Ilov3gam3z (talk) 15:04, 5 July 2026 (UTC)

  That's even more impractical. JavaHurricane 07:11, 6 July 2026 (UTC)

  That's what they said about an encyclopedia anyone can edit. "It'll just be vandalism." Turned out not to be true. Levivich (talk) 15:06, 5 July 2026 (UTC)

  I wonder why we protect the TFA preemptively nowadays, then. Or why DYKs regularly and quickly make their way to RFPP. JavaHurricane 07:08, 6 July 2026 (UTC)

  Because men have forgotten God. jp×g🗯️ 20:00, 7 July 2026 (UTC)

  What? FaviFake (talk) 21:41, 7 July 2026 (UTC)

  ??? Ilov3gam3z (talk) 21:57, 7 July 2026 (UTC)

  Pretty sure they mean that highly productive editors (men) have forgotten god (the necessity of privileging newbies for the project's sustainability) Kowal2701 (talk, contribs) 22:20, 7 July 2026 (UTC)

  I think this is a joke—an incredibly funny one which we should enjoy at that, in fact.

  (If we're opting for serious interpretations of something biblical, I can equally-validly interpret it as "people (anonymous and new editors) have forgotten how to have good things (biblically, God)". I envision some prosperous years of religious sect-building and excommunications over this.) In solidarity, Aaron Liu (talk) 00:57, 8 July 2026 (UTC)

• A, M1, P2 - M1 seems to best match the rest of the main page, and I like the placement of P2: the juxtaposition between TFA and an article needing improvement encapsulates the idea of Wikipedia quite nicely: what articles start as, and what they can become. I'd support A with any of the other M's or P's as well. If we want a human written encyclopedia, we're gonna need humans to write it, and this seems like a good idea to try to increase recruitment. Let's see if it makes a difference. Levivich (talk) 15:10, 5 July 2026 (UTC)
• A I was summoned so I'll offer my opinion. I do still think that AFI and Vital articles could be merged, and unfortunately have not gotten enough momentum between the projects to actually get anything definitive. If we're making changes, would want to toss that discussion in to see if anyone else is interested in such a merge. GeogSage ^{(⚔Chat?⚔)} 20:39, 5 July 2026 (UTC)
• A – P2 – This is an excellent idea that really shows what Wikipedia is about. I am fully in favor of showing the website as an ever-improving and ever-evolving reference work. ~Maplestrip/Mable (chat) 07:56, 6 July 2026 (UTC)
• A. M2 > M1 > M3 but all mockups are acceptable to me. Location wise, I like both P3 or full-width box somewhere below the two columns bit but I would accept any location. I suggest trying it out to see how it goes, and then see if a week is too long for one article.

I found the Article for Improvement extremely compelling when I was a new editor first learning the ropes, and I think we should make it as easy as possible for people to find these kinds of high-quality on-ramps to editing. I expect having it on the main page would also bring me back to looking in on the articles, especially to make sure all was going well with the newcomers. I think experienced editors are perfectly capable of curating appropriate article choices for the main page, i.e., articles with low-stakes and approachable flaws. ~ le 🌸 valyn (talk) 22:33, 6 July 2026 (UTC)

• A, M3 > M2 > M1. Though, I would prefer if this were to be daily and for multiple articles to be improved. I have no opinion on the positioning. Beta Beta Beta - talk 01:25, 7 July 2026 (UTC)
• A, M3 > M2 > M1, M3 > M1 > M2 if the "How to contribute" box in M1 isn't collapsed by default. And I think TWAFI should come before all other boxes, i.e. be in the following position:
  TWAFI
  TFA

  DYK

  ITN

  OTD
  sapphaline (talk) 09:17, 7 July 2026 (UTC)

  What do you think of my mockup? In solidarity, Aaron Liu (talk) 21:41, 7 July 2026 (UTC)

  I agree with all your points, but I think placing it below DYK and OTD would be better since we still want to highlight the featured articles and all the other content above. Atakes Ris (talk) 10:56, 10 July 2026 (UTC)

• A M1, M2, M3 this seems like a really good idea, i think TWAFI should go at the bottom of the right hand side or below the news. Jabba550  | ✉ in solidarity 12:32, 7 July 2026 (UTC)
• B. If done anyway, oppose all of P1, P2, and P3, and suggest a P4 instead that pushes this feature down beneath OTD. First of all let me say that I love calls to action, and I think that encouraging people to consider becoming editors is important. In fact, this kind of collaboration is great. However, this is too wide a collaboration. A successful collaboration is like... 10 people in a classroom or a Discord channel. Opening up a collaboration to a zillion contributors is a formula for heartbreak if the goal is any improvement more than skin-deep. We want a welcoming newbie experience, yes, but a newbie experience that involves being reverted or heavily rewritten by random other people aren't it. And heck, even in the case of just ~10 contributors, there's always the risk that two editors take time to work on the article and seriously research it, but go different directions. And then a drive-by collaborator just stops in long enough to make unneeded style edits to annoy them. This problem is much worse with a Wikipedia-wide invitation. So yes to today's article for improvement for WikiProjects or subreddits or Discord channels, no to the main page. SnowFire (talk) 22:49, 10 July 2026 (UTC)
• A. I don't care exactly how it's done, but this is something we should do. Attracting new editors is crucial, and I'll take any plausible idea for it. Toadspike [Talk] 22:09, 11 July 2026 (UTC)
• A, M3>2>1, P2>3>1. I also agree that the contrast between the FA and TWAFI is clearer when they are placed side-by-side, and the second and third mockups are more encouraging to new editors. I also suspect there are a reasonable nember of semi-experienced editors who don't know about AfI, and introducing them to the process could counter the unconstructive edits by newcomers. Somepinkdude (talk | contribs), in solidarity 16:25, 12 July 2026 (UTC)
• A, M2>3>1, strongly prefer P2 - This seems like a no-brainer way to improve the Main Page. I do feel like the concerns about too many editors on one article are valid, but I think that it is more important that we encourage editing and I think AFI needs the support. Regarding the placement, if we do end up doing this it'd be best to have it at the top to contrast with TFA. Eman7blue42 (talk page | recent edits) 22:56, 12 July 2026 (UTC)
• B The more I think about it, the more I'm convinced that this will quickly become "This Week's Vandalized Article", especially if the proposals to prohibit protecting the page go through. It would be the only page prominently linked to from that main page that isn't protected, and will require constant and vigilant oversight from RC patrollers and admins. The only way I could see this working is if we didn't actually link to the page, but instead had a message similar to M2 without the link to the page and that, instead of "Click here to start editing", had a link to Click here to view this and other articles in need of improvement! that links to Wikipedia:Articles for improvement/Articles. --Ahecht (TALK
  PAGE) 17:26, 16 July 2026 (UTC)

  Ahecht, am I missing something? Currently, only the featured article is protected out of the boldlinks on the main page. InfernoHues (talk) 19:24, 16 July 2026 (UTC)

  I'm not referring to boldlinks, I'm referring to items that have an entire box devoted to them, namely the Featured Article and Featured Picture. --Ahecht (TALK
  PAGE) 20:29, 16 July 2026 (UTC)

  The featured picture isn't protected. InfernoHues (talk) 21:10, 16 July 2026 (UTC)

• B & none of the placement options. If this does pass it should be below the other content, in the same slot as TFL, and limited to one day per week. This idea does not showcase quality encyclopaedia content, quite the opposite - it's specifically picking a bad article that needs work. The Main Page is supposed to present material that demonstrates the value of Wikipedia and is useful to readers, not content for editors or designed to recruit new ones. Bold links from the Main Page are held to minimum standards of quality, by all existing sections, which this wouldn't meet. I have no objection to TWAFI existing, or being advertised to existing editors, but I don't think it should be on the Main Page or otherwise advertised to readers. Modest Genius ^talk 19:04, 16 July 2026 (UTC)

  The main idea of having this is by having an article that demonstrates the point about the free encyclopaedia that anyone can edit (see the initial workshopping/RFCBEFORE). I don't think the main page was ever intended to always show articles with quality content, otherwise having DYK for new articles and "other areas of Wikipedia" would not have existed. Even if it is, remember, consensus can change, and most people in this discussion say this is probably the best way to bring in editors.

  Although, I do agree that this feature could be "advertised" to current editors, probably through Special:Homepage, though that might mean a lower success rate. Hason-LEK-SIN ● Let’s chat! ● My contribs 23:01, 16 July 2026 (UTC)

I don't know if DYK is necessarily "high quality content", but they do have minimum quality standards and a "presentability" standard, which TWAFI is the opposite of. Natg 19 (talk) 00:49, 17 July 2026 (UTC)

To add to Hanson's comment, looking at the Main Page, there's tons of free, encyclopedic content, but editing only gets three mentions: the tagline and two boldlinks way down at the bottom. To use a metaphor, if I had a book that was half about cheese and half about bread, I would want to place both on the cover. The Main Page feels like a cover of pure bread. 7amiþ reform · 💬 · 📊 00:52, 17 July 2026 (UTC)

Why don't we just add a huge EDIT NOW! button or something to the "Welcome to Wikipedia" banner on the MP? (Or redesign that banner in general?) It'll probably attract more editors than the TWAFI template. Some1 (talk) 01:02, 17 July 2026 (UTC)

Sure, that'd work nicely. (TBH I sww TWAfI as a huge EDIT NOW box, but also trying to answer the follow-up: "Edit... what?") 7amiþ reform · 💬 · 📊 01:17, 17 July 2026 (UTC)

But you wouldn't want a book about cheese to have a cover that's half cheese, and half how to write & print a book. The behind the scenes stuff should remain there. The vast majority of our readers already know that they can edit articles - it's already stated right at the top of the Main Page - they just choose not to. Modest Genius ^talk 10:19, 17 July 2026 (UTC)

Surveys indicate that, while most readers know that they can they edit, few of them do so and there are three main reasons for this:

1. Lack of expertise
2. Satisfaction with the existing content
3. Fear of rejection

The first two are fine as we don't want change for change's sake by clueless newbies. But we could do more to make everyone feel welcome and suggest some low-hanging fruit for them to pick in a safe way.

The best example I've seen lately is the Suggested edits feature which has been offered to me in the app. These are carefully tailored to be specific and suitable for newbies. They will scale well for our millions of readers and so will build confidence without clashes. We should try to put such a personalised feature on the main page near the "anyone can edit" intro. Andrew🐉(talk) 11:12, 17 July 2026 (UTC)

( peanut gallery comment) Fear of rejection basically summarizes half of my work here: edit/comment, then wait around for someone to tell me how wrong I am. No matter what ends up getting approved, I believe it MUST help editor confidence. 7amiþ reform · 💬 · 📊 01:42, 18 July 2026 (UTC)

• B There are already tens of articles across a wide range of interests linked on the main page every day that could be edited and improved by anyone who cares to, rather than choosing one by committee that will likely interest a tiny fraction. Stephen 00:41, 17 July 2026 (UTC)

  From Bremps, the proposer (here): First, the selection will be done by RNG, as it is currently. This sounds jarring to anyone who participates in ITN or DYK, but I believe this is the best method. No one gets to play favorites or horse-trade support votes. I believe that otherwise, this will be a major issue as everyone tries to get their pet article in the line for improvement. 7amiþ reform · 💬 · 📊 00:55, 17 July 2026 (UTC)

  That comment sorta confused me when I first read it. Almost all ITN posts comes in RDs, which doesn't have any horse-trading or favorites, and ITN noms are a whole process that also almost never has anyone playing favorite or horse-trading (the only possible favorites that occur is with the US and UK, which are pretty wide scopes). DYKs and RDs can be almost anything, if RD the person just has to have died and not be a stub and the DYK just has to be recently improved and not a stub (interestingness is a very low bar). I think OTD, TFA, and TFP all have much better arguments as occurring via horse trading and favorites, but I still wouldn't really say so. 1brianm7 (talk) 02:48, 17 July 2026 (UTC)

  The RfC text does not say that articles will be chosen randomly, though that was in the original proposal. InfernoHues (talk) 02:50, 17 July 2026 (UTC)

  sorry. What I meant to say was more like "it would be preferable for TWAfI to be randomly generated, here's Bremps's reason [insert here]" 7amiþ reform · 💬 · 📊 02:53, 17 July 2026 (UTC)

  The Article for Improvement is already an ongoing practice. The RfC is about if it should be put on the main page or not. --I sometimes eat bananas, and you can talk to me here: (talk) 17:35, 20 July 2026 (UTC)

Discussion (TWAFI)

• Pining from previous discussions: @Bremps:, @BlueEleephant:, @Wikipedian12512:, @Idacticus:, @Aaron Liu:, @Chaotic Enby:, @David10244:, @7amithorn:, @Donald Albury:, @Kowal2701:, @Reconrabbit:, @Fifteen thousand two hundred twenty four:, @Clovermoss:, @Stonybrook:, @1brianm7:, @Naturedata:, @Thebiguglyalien:, @Gnomingstuff:, @Femke:, @Meadowlark:, @Jpxg:, @Ilov3gam3z:, @Hason-LEK-SIN:, @Chipmunkdavis:, @Isaacl:, @Joe vom Titan:, @Quince&Medlar:, @Zxcvbnm:, @Wreaderick:, @Edittttor:, @ISometimesEatBananas:, @Madotea:, @Felinaex:, @Walteronthehill:, @Youprayteas:, @Loytra:, @Toneshmellow1776:, @ScrubbedFalcon:, @NorthernWinds:, @Dylansan:, @Robertsky:, @FantasticWikiUser:, @EatingCarBatteries:, @Kepler-1229b:, @Enos733:, @FaviFake:, @WhatamIdoing:, @Rjjiii:, @JuxtaposedJacob:, @Toadspike: InfernoHues (talk) 05:21, 2 July 2026 (UTC)

  More pings: @Miminity:, @Eddie891:, @Andrew Davidson:, @YuniToumei:, @SarekOfVulcan:, @Choucas:, @Some1:, @Wehwalt:, @ScienceD90:, @Cremastra:, @OwlParty:, @PerfectSoundWhatever:, @Rosguill:, @Danubeball:, @Sahaib:, @Ca:, @Schwede66:, @Art LaPella:, @Stephen:, @JohnLaurensAnthonyRamos333:, @Remsense:, @Ad Orientem:, @SWinxy:, @UndercoverClassicist:, @Kusma:, @Modest Genius:, @Joe Roe:, @Just Step Sideways:, @Lallint:, @Yngvadottir:, @Khajidha:, @Andrybak:, @Kvng:, @Ktkvtsh:, @Selfstudier:, @CFA:, @PFHLai:, @Ahecht:, @AirshipJungleman29:, @JMCHutchinson:, @Aoba47:, @Gonzofan 2007:, @ChocolateCharcuterieBoard: InfernoHues (talk) 05:22, 2 July 2026 (UTC)

  Fixing incorrect pings: @JPxG:, @StonyBrook:, @Bo-3903:, @Gonzo fan2007:, @Jmchutchinson:, @Beeblebrox:, @JohnLaurens333: InfernoHues (talk) 05:27, 2 July 2026 (UTC)

  Notified T:MP and T:CENT InfernoHues (talk) 05:38, 2 July 2026 (UTC)

  Notified Wikipedia talk:Articles for improvement. 7amiþ solidarity · 💬 · 📊 · 🇺🇸 05:53, 2 July 2026 (UTC)

  hwat is this all about then? OwlParty (talk) 08:20, 2 July 2026 (UTC)

  There was a discussion on the topic of implementing this week's article for improvement on the front page. I participated in the initial thread but not in the RFCBEFORE, nice to see it got to this point. I'll have something to contribute in a while. -- Reconrabbit (talk) 11:04, 2 July 2026 (UTC)

  @Reconrabbit, it might interest you to know that WP:RFCBEFORE gets its name from the idea that there are some things you could try 'before' starting an RFC in the hope that there would never be a need for that RFC. In the case of adding something to the Main Page or making a WP:PROPOSAL for a new policy or guideline, of course, there's no way to avoid an RFC, so RFCBEFORE's advice (e.g., "Asking over at the Teahouse") is irrelevant. WhatamIdoing (talk) 17:38, 2 July 2026 (UTC)

  I don't involve myself too much in these processes so that's interesting to know. The section was quite literally "RFCBEFORE on adding a "This week's article for improvement" section to the Main Page"... but I get the feeling I am telling you things you already know now. -- Reconrabbit (talk) 18:30, 2 July 2026 (UTC)

  FWIW, I've found that a good rule of thumb is that if you're explicitly naming sections "RFCBEFORE", you're likely doing something wrong. Cremastra (talk · contribs) 20:16, 2 July 2026 (UTC)

  Why was I tagged here? Idacticus (talk) 16:22, 2 July 2026 (UTC)

  You participated in at least one of the discussions that led to the creation of this RfC. InfernoHues (talk) 16:31, 2 July 2026 (UTC)

  Which one? What is this about? Idacticus (talk) 22:04, 2 July 2026 (UTC)

  See the topic's name ("Req"...). You were the first to support this idea besides Bremp, the initial proposer. In solidarity, Aaron Liu (talk) 23:04, 2 July 2026 (UTC)

• Rationale for P1 prioritizing ITN and OTD over DYK? Why not put TAFI where DYK currently is, DYK where ITN currently is and OTD where ITN currently is? That has to be justified just as much as any other part of the change. Also, is there a way to make mobile users see TAFI under TFA while letting desktop users see TAFI to the right of TFA? If so, why should we not do that? –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 10:07, 2 July 2026 (UTC)

  I'm not sure about the mobile stuff, but TWAFI is better on the left-hand side where the green colours stand out, instead of on the right hand side with the more subdued colours.

  --I sometimes eat bananas, and you can talk to me here: (talk) 13:23, 2 July 2026 (UTC)

  Then change the colour scheme? –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 14:09, 2 July 2026 (UTC)

  Whoa there! In solidarity, Aaron Liu (talk) 23:06, 2 July 2026 (UTC)

  Possibly. -I sometimes eat bananas, and you can talk to me here: (talk) 20:57, 15 July 2026 (UTC)

• Should we leave notifications about this thread on WT:DYK, WT:ITN, and WT:OTD respectively? We are talking about making a change that could potentially negatively impact these sections' viewership. – Epicgenius (talk) 13:25, 2 July 2026 (UTC)

  I have notified WT:DYK, WT:ITN, and WT:OTD about this discussion. – Epicgenius (talk) 13:40, 2 July 2026 (UTC)

• P: I guess nobody supports the idea to place AFI above both columns? In solidarity, Aaron Liu (talk) 17:38, 2 July 2026 (UTC)

  I am well aware that this is a ridiculous idea with which I'm only barging in now instead of during the workshop. Regardless, a mockup is available at User:Aaron Liu/sandbox. The lack of color in the AFI space is intentional; it's simultaneously frontpaged and less attentionate than TFA. I'll shut up about this now. Toodle-doo. In solidarity, Aaron Liu (talk) 17:47, 2 July 2026 (UTC)

  I was considering proposing this in the workshop, but didn't think it would gain any consensus. InfernoHues (talk) 17:50, 2 July 2026 (UTC)

  Maybe under the featured picture? Like this [[1]]. But I would put color in the box. ~ ONUnicorn^{(Talk|Contribs)}problem solving 18:41, 2 July 2026 (UTC)

  That's exactly the kind of thing I am supporting, thanks for the mock up. UpTheOctave! • 8^va? 18:49, 2 July 2026 (UTC)

  I don't like that (though trialing anything would be better than nothing) because the kind of people we want to attract would have to scroll very far to see it. In solidarity, Aaron Liu (talk) 20:13, 2 July 2026 (UTC)

  I would support that (placing TWAFI under TFP), and agree that the TWAFI box should have a color. Since TFA and DYK are green; ITN and OTD are blue; TFL is red; TFP is purple; maybe TWAFI can be a shade of yellow. Some1 (talk) 22:46, 2 July 2026 (UTC)

  Suggestion got buried in earlier discussions Hason-LEK-SIN ● Let’s chat! ● My contribs 06:57, 4 July 2026 (UTC)

• Regarding the addition by Andrew Davidson to the Background section, after reading the links I'm not I agree that the project was "considered a failure." I agree with the users in those discussions (and the signpost article interviews) that said the main problems were a) bad template design and b) three articles were listed at once, both which are hopefully fixed in this proposal. Even with those issues, there were still improvements made to some articles featured. InfernoHues (talk) 03:40, 4 July 2026 (UTC)
• Pinging regulars at TWAFI, I can't see that they've been notified, @BabbaQ, SVcode, 2600 etc, Earth605, Utopes, and GeogSage: please see the above Kowal2701 (talk, contribs) 12:19, 5 July 2026 (UTC)

• @Bremps: @BlueEleephant: @7amithorn: @InfernoHues:(feel free to ping more if needed), So I noticed that Chess is currently the Guild of Copy Editors article "of the week", that got me thinking, are they "more successful" than TWAFI? And, since I'm relatively new, how does the Guild work? I'm honestly quite confused.

As a side note, why was the Chicago Bulls nominated for TWAFI? It had a B grade, which isn't usual for TWAFI. While "researching" for this comment, I found the nomination of the Bulls, which mentioned that it isn't really deserving the B due to the multiple missing citations. And truth to be told, they were right: using the VE editing suggestions feature, the Bulls article had 31 editing suggestions, compared to 8 from the Lakers, 20 from the Celtics, 21 from the Spurs, and 29 from the *deep breaths* Knicks. What!? Huh!? The Knicks have almost the same number of uncited statements as the Bulls!?

Oh, and these numbers are after I have gone ahead and removed duplicated wikilinks the system suggested, by myself, leaving only "Add a citation" suggestions. Okay yeah, I see why that article was nominated for TWAFI.

Please save my brain, I've been watching too much NBA content than what is considered healthy... Hason-LEK-SIN ● Let’s chat! ● My contribs 14:28, 19 July 2026 (UTC)

In my experience working in the GOCE, they are less concerned with improving articles in the sense of "adding missing information and expanding", more "making articles more clear and clarifying issues with the existing text". -- Reconrabbit (talk) 16:16, 19 July 2026 (UTC)

Noted, checks out. Hason-LEK-SIN ● Let’s chat! ● My contribs 22:54, 19 July 2026 (UTC)

• Perhaps we could choose two seperate AfIs, and the one on the main page is C-class or lower? Perhaps we could even require all AfIs to be below B-class. This way, most good-faith, competent edits won't reduce the value of its content, and it's easier for newcomers to add information to an article with major gaps. Somepinkdude (talk | contribs), in solidarity — Preceding undated comment added 18:04, 26 July 2026 (UTC)

I strongly support making TWAfI below B-class (C, Start, or Stub). SPD nicely summarized my rationale. 7amiþ reform · 💬 · 📊 05:11, 27 July 2026 (UTC)

Yes the argument for this is strong. Stockhausenfan (talk) 15:13, 27 July 2026 (UTC)

Change WP:CSD G5 from a speedy deletion rationale to a speedy draftification rationale

I propose that CSD G5 be amended so that where the only basis for the removal of content is creation by a blocked or banned editor, such content should be speedily draftified rather than speedily deleted. This is, of course, absent an independent reason requiring deletion (such as copyright infringement, BLP violation, obvious hoax, spam, non-notable, or attack content). CSD G5 exists to enforce community sanctions against editors, not for the purpose of eliminating potentially useful encyclopedic content, and Wikipedia should make it possible for any potentially useful content to be made available to readers based on the merits of that content, rather than by its author. Draftification would preserves material for uninvolved editors to review and improve while ensuring that it does not remain in the reader-facing spaces of the encyclopedia.

Notably, this change would not create a permanent refuge for such content, as drafts are routinely deleted after six months of non-activity, while any that are improved can be subject to mandatory submission and review through the Articles for Creation process before possibly being restored to mainspace. This approach preserves potentially valuable work and reduces needless and wasteful duplication of effort (which I have had to undertake several times when creating new articles to fill information gaps, only to discover that the gap originated with a mass deletion and much of the deleted content could have been reused). Importantly, draftspace content is non-indexed, so the common refrain that bad actors are rewarded by having content maintained in the encyclopedia is effectively nullified by draftification, making the content invisible to readers generally but still findable by editors specifically seeking to write an article on the draftified topic. I believe that this change would achieve a balance between enforcement of blocks and bans and the project's broader mission of building and preserving a comprehensive encyclopedia for the benefit of readers. BD2412 T 02:16, 4 July 2026 (UTC)

No. G5 is so good faith editors don't have to spend hours to days to weeks to even months of their time cleaning up after UPE, POV pushing (especially in areas which are under an extended confirmed restriction), BLP vios, plagiarism, ect. And, yes, these are important to deal with in draftspace, and, no, most AFC reviewers are not looking out for issues that complex because, well, they're overworked enough as it is. I remember yours and others defense of such content at an AN thread over G5 a few years ago; it took me hours to prove that the content was completely unverified in the given sources.

G5 is for readers; most of our editorial norms rely on assuming good faith. giving such a massive burden to AFC reviewers and other editors is just going to wear people out. GreenLipstickLesbian💌🧸 07:07, 4 July 2026 (UTC)

Also, I've tagged userspace harassment for g5; moving that to draftspace would be useless. GreenLipstickLesbian💌🧸 07:11, 4 July 2026 (UTC)

GLL absolutely all of your first comment seems to ignore BD2412's important point This is, of course, absent an independent reason requiring deletion (such as copyright infringement, BLP violation, obvious hoax, spam, non-notable, or attack content). If you see UPE, POV pushing, BLP vios, plagiarsm, etc that would all provide a reason for deletion. If you have to spend hours proving the content is unsuitable then it's not suitable for speedy deletion, which is explicitly for the most obvious cases.

I do agree with your second comment that this proposal, at least as is, could only work for article content. Thryduulf (talk) 09:32, 4 July 2026 (UTC)

The intent of this proposal is limited to content in article space. I am glad to make that explicit. It is correct, of course, that things like BLP violations and plagiarism would be deleted under other policies. BD2412 T 16:52, 4 July 2026 (UTC)

And absolutely all of your comment seems to ignore my point that G5 eliminates the need for good faith editors to spend countless hours proving that editors the community has banned or blocked cannot be trusted to write useful content. Plagiarism, BLP issues, POV pushing, and so on are not always easy to find; anybody remember the saga of Doug Coldwell?

And found th AN thread I was referring to, [2] with the feather spirited defense of continent that, because some people though mass removing G5 was a good idea, I had to spend actual hours proving what we already knew. GreenLipstickLesbian💌🧸 17:24, 4 July 2026 (UTC)

The community is entitled to have admins prove that their deletion calls are correct; otherwise, good content, and content added by good editors uninvolved in the dispute, gets deleted carelessly. BD2412 T 17:42, 4 July 2026 (UTC)

If you see what you perceive to be an incorrect speedy deletion, you are free and encouraged to bring it up with the deleting admin. Until then: "there are people in the world who see themselves as being at war with Wikipedia, and here we are smashing our own best blade on the eve of battle". GreenLipstickLesbian💌🧸 17:49, 4 July 2026 (UTC)

Is there a master list somewhere of all of the articles that have been deleted under G5? Do we even have the tools to properly investigate this? BD2412 T 18:46, 4 July 2026 (UTC)

You can use the quarry to locate log entries that invoke G5. –LaundryPizza03 (dc̄) 18:50, 4 July 2026 (UTC)

@LaundryPizza03: Can quarry isolate pages deleted under G5 for which there were substantial edits other than by the blocked/banned editor? BD2412 T 23:42, 4 July 2026 (UTC)

Not even in principle, because you need to look at a diff to tell whether an edit is substantial; and the actual text of edits (deleted or otherwise) isn't replicated to the databases that Quarry queries; and if it were, it would be redacted. Because what would be the point of restricting viewdelete to administrators if anyone gets access to the underlying data anyway?

What it can do is show who edited a deleted page, and when, and whether the edit was marked minor, and what the resulting size of the deleted page was after. I suppose we could add G5s with a non-bot, non-minor edit by someone other than the first editor which added at least, say, 500 bytes to Wikipedia:Database reports/Possibly out-of-process deletions. It'd be more work than I think I'd be willing to put in, though, since excluding revisions from before the most recent creation is nontrivial, and pretty much everything that shows up on that report just gets ignored anyway. —Cryptic 00:22, 5 July 2026 (UTC)

CSD G5 exists to enforce community sanctions against editors, not for the purpose of eliminating potentially useful encyclopedic content – I don't follow, removing edits made in violation of community sanctions is quite literally enforcing those sanctions, otherwise what's the point of the prohibition?

Blocks are preventative. If an editor could be expected to be able to constructively create new pages, then they would not be blocked from being able to create new pages. fifteen thousand two hundred twenty four (talk) 10:28, 4 July 2026 (UTC)

Well, people are blocked indefinitely and from all namespaces for behavioral issues too. sapphaline (talk) 11:00, 4 July 2026 (UTC)

Yes. This is a collaborative project, if an editor cannot collaborate with others (be that because of poor behavior or otherwise), then they cannot constructively contribute. fifteen thousand two hundred twenty four (talk) 11:16, 4 July 2026 (UTC)

Just because someone cannot constructively contribute due to behavioural issues does not mean that all content they write is inherently unsuitable for an encyclopaedia. Thryduulf (talk) 11:27, 4 July 2026 (UTC)

Just because someone cannot constructively contribute because of behavioral issues, just re-read what you've written here a few times.

The community should not be forced to entertain contributions made by someone who cannot constructively contribute, and who is actively disallowed from contributing because of this. fifteen thousand two hundred twenty four (talk) 11:48, 4 July 2026 (UTC)

Please do not selectively quote me, I said Just because someone cannot constructively contribute due to behavioural issues those extra four words are important. You need to stop conflating behavioural issues with article quality issues because the two are independent. There have been numerous examples through the years on this project of people who write top-notch articles but were banned because they could not civilly contribute to discussions due to things like racism, sexism, refusal to listen to unregistered editors, etc. Likewise there have been people who have been banned for their inability or unwillingness to understand things like plagiarism or fair use but who were excellent in discussions about unrelated matters. G5 as currently written allows and arguably encourages us to throw away near-FA level content just because the author expresses their views in an uncollegiate manner. We generally don't want the content written by the second group of editors, but we generally don't need G5 to get rid of it (e.g. G12 applies whether or not the author is banned). Thryduulf (talk) 12:29, 4 July 2026 (UTC)

Just curious, have there been any cases of near-FA level content being thrown away because it was written by a sockpuppet of a blocked/banned editor circumventing their block/ban? Chaotic Enby (in solidarity · talk · contribs) 12:40, 4 July 2026 (UTC)

I have no idea. G5 content gets thrown away regardless of quality and without any review, so unless someone provides evidence to the contrary I have to assume that it spans the entire range from content that would be speedily deleteable as A1/A3 in articlespace all the way through to approaching FA-level. Thryduulf (talk) 13:04, 4 July 2026 (UTC)

The quote was shortened for brevity, not to be selective, as I found the following words didn't impact the points being made. Though seeing as you disagree I've inserted them.

I'm not conflating anything. Restricted editors can make garbage edits, restricted editors can make excellent edits. Doesn't matter. They're not allowed to make either, and the community shouldn't be required to spend its time sifting through edits made in violation of blocks and bans to find out which is which. It's also clearly a poor idea to host in draftspace new contributions from users blocked for copyvio, or upe, or blpvios, or... all of which this proposal would accommodate by default. I have a feeling we simply disagree, and that's fine. fifteen thousand two hundred twenty four (talk) 13:07, 4 July 2026 (UTC)

"They're not allowed to make either" - our only purpose here is to improve the encyclopedia. If a banned editor's edit matches this purpose, then they are allowed to make the edit. Enforcing blocks and preventing sockpuppetry should be complementary to improving the encyclopedia, not be a goal in itself. sapphaline (talk) 14:46, 4 July 2026 (UTC)

Enforcing our existing policies, such as WP:BLOCKING or WP:BANNING, improves the encyclopedia. That's why those policies exist, because by consensus we agree they improve the encyclopedia.

If you'd like to change consensus to better accommodate those who were unable or unwilling to abide by it, may I suggest starting with changing An editor who is site-banned is forbidden from making any edit in WP:SBAN to An editor who is site-banned is forbidden from making any edit (unless it's really really good)? fifteen thousand two hundred twenty four (talk) 15:31, 4 July 2026 (UTC)

Certainly "An editor who is site-banned is forbidden from making any edit in mainspace", but conversely, why let bad editors WP:OWN their beneficial edits? BD2412 T 20:34, 4 July 2026 (UTC)

If you as a trusted good faith editor do not want that G5 tagged page to be deleted, just add a substantial amount of content and detag it. Moving pages around is not significant enough to avert a G5 deletion. Graeme Bartlett (talk) 11:34, 4 July 2026 (UTC)

The argument here is that moving a page from the article to draftspace should be enough to avoid G5. Disagreeing with that is a valid position to hold, but you need to explain why you think that. Simply stating what the policy currently is is not a relevant argument in a discussion about whether the policy should be changed. Thryduulf (talk) 11:39, 4 July 2026 (UTC)

Enough pages in draft space also get deleted by G5. We have enough problems with socks appearing and creating drafts. Anyway a trusted editor can request the undeletion of a G5 in order to improve it. But being slack and not editing it leaves it looking the same as the banned creator left it. So substantial changes are needed to avoid a G5 delete. Graeme Bartlett (talk) 11:48, 4 July 2026 (UTC)

Again, the current policy existing in the way it currently exists is not an argument for (or against) changing the policy. The argument being presented here is that not everything that gets deleted by G5 needs improving. Some stuff does, yes, but some is not all. The desire is to stop treating everything written a banned editor as identical in all respects simply because the author is banned - i.e. Comment on the content, not the contributor. Thryduulf (talk) 12:33, 4 July 2026 (UTC)

The problem is that this pretty much creates an incentive to keep circumventing your ban, since editors in good standing will have to keep arguing the content on its merits while ignoring the banned contributor. Chaotic Enby (in solidarity · talk · contribs) 12:36, 4 July 2026 (UTC)

If the content is sufficiently good that editors want to keep it then it should not be speedily deleted. If the content isn't good enough for anyone to want to keep it then nothing changes. Thryduulf (talk) 13:05, 4 July 2026 (UTC)

If the content is sufficiently good, then the banned user should be encouraged to take the SO and appeal their ban, so that such contributions can be eventually undeleted/kept.

I've been disappointed to see good articles get G5'd and wish they could be kept. I'm even more disappointed, however, when banned users I want to see return continually flout their ban, and further diminish the community's goodwill and their chance to return. In solidarity, nil ^nz 13:22, 4 July 2026 (UTC)

If the content isn't good enough for anyone to want to keep it then nothing changes. Not really, it means that good-faith contributors have to exert energy to review AfC submissions from banned users, which goes against the whole point of banning them. Chaotic Enby (in solidarity · talk · contribs) 13:24, 4 July 2026 (UTC)

@Chaotic Enby: How is a banned user going to make an AfC submission? Articles don't submit themselves, and unsubmitted articles are not reviewed. BD2412 T 16:43, 4 July 2026 (UTC)

How is somebody with a history of evading their block/ban without immediate detection.... Going to evade their block/ban without immediate detection? GreenLipstickLesbian💌🧸 19:04, 4 July 2026 (UTC)

In that case, you might as well delete all of Wikipedia because there's no guarantee that any article in the entire project wasn't created by an alt of a blocked or banned user. As a practical matter, if we move these pages to draft and s-protect them and require admin review for restoration to mainspace, that will suffice. BD2412 T 20:28, 4 July 2026 (UTC)

Hyperbole is unhelpful. GreenLipstickLesbian💌🧸 20:33, 4 July 2026 (UTC)

G5, as it stands, is only for cases where there is evidence that the creator was evading a block/ban. Not for cases where "there's no guarantee it wasn't", and the two obviously aren't comparable.

Additionally, requiring admin review for every page created by a blocked users gives them a very easy way to overwhelm admins through whichever process will be chosen for that review. Chaotic Enby (in solidarity · talk · contribs) 21:34, 4 July 2026 (UTC)

How? I'd like you to explain the mechanism by which you think that would happen. BD2412 T 21:37, 4 July 2026 (UTC)

The entire point of G5 is that it is not about content. It is about enforcing that some people are not allowed to contribute. —Kusma (talk) 16:58, 4 July 2026 (UTC)

Wikipedia is a project to build an encyclopedia, which means that everything takes a backseat to content. BD2412 T 21:46, 4 July 2026 (UTC)

You have been here long enough to know that this is not true. Please do not pretend you are unaware of the many ArbCom decisions and community bans against excellent content creators who did not play nicely enough with others. We have always prioritised protecting the community that builds the encyclopaedia over any individual pieces of content. —Kusma (talk) 22:57, 4 July 2026 (UTC)

Protecting the community is itself content-forward. We don't need to protect the community from useful and non-problematic content that happens to come from an editor who has also made bad content. BD2412 T 22:59, 4 July 2026 (UTC)

The difference between a banned editor and a non-banned editor is that the banned editor is not allowed to contribute useful and non-problematic content. (We reject useless or problematic content from both banned and non-banned editors). And most banned editors are not banned because of "bad content", but because of socking, incivility, edit warring or paid editing. —Kusma (talk) 23:21, 4 July 2026 (UTC)

@Graeme Bartlett: I have seen instances where an article was carelessly and improperly deleted under G5 despite other editors having contributed substantially to the article. Deletion destroys the evidence of such contributions without review. BD2412 T 16:54, 4 July 2026 (UTC)

“If you as a trusted good faith editor do not want that G5 tagged page to be deleted, just add a substantial amount of content and detag it”. That’s great if you’re there to see it in between tagging and deletion. For mainspace content, this would make sense if deletion went via a week in draftspace. SmokeyJoe (talk) 06:08, 5 July 2026 (UTC)

Absolutely not. G5 is our only tool to enforce bans against IP-hopping users. Not deleting banned users' content means we allow the banned user to contribute, destroying the very purpose of a ban. If you think banned a banned user's contributions are worth keeping, convince the community to unban them. Do not let them contribute while banned. —Kusma (talk) 12:58, 4 July 2026 (UTC)

@Kusma:, if someone were to move all of your article-space content to draft space, would you consider that an endorsement of your work, or a punishment? BD2412 T 16:48, 4 July 2026 (UTC)

For a banned editor who is not allowed to edit either draft space or article space, it is an endorsement. For a non-banned editor who is allowed to edit article space, it is a punishment. —Kusma (talk) 16:54, 4 July 2026 (UTC)

No. It's not uncommon for G5-eligible articles to also frequently reincarnate due to being the focus of a particular sockfarm. —Jéské Couriano v^_^v ^{Object Class: Drygioni} 16:50, 4 July 2026 (UTC)

@Jéské Couriano: We have tools to deal with that without throwing out the baby with the bathwater. What if we were to move the article to draftspace, throw a big tag on the top noting that it was moved there because it was created by a banned or blocked user, s-protect it against editing by new and unregistered users (which would include the edit needed to submit the draft for review), and move-lock it so it can't be returned to mainspace without admin review? BD2412 T 16:58, 4 July 2026 (UTC)

Why would we spend more time and effort on the contributions of banned editors than on those of non-banned editors? —Kusma (talk) 17:03, 4 July 2026 (UTC)

That time is already being spent with the effort taken to delete the content, except that the rules governing G5 are not being observed, and contributions by regular editors erroneously get deleted without review. BD2412 T 17:12, 4 July 2026 (UTC)

Because nine times out of ten these article subjects (which are universally either living people or companies) have marginal notability if that and wouldn't be a viable draft simply for want of usable sources. —Jéské Couriano v^_^v ^{Object Class: Drygioni} 18:21, 4 July 2026 (UTC)

@Jéské Couriano:, and what happens to nonviable drafts? They automatically get deleted after six months of not being worked on. However, if nine out of ten of these are nonviable, then the one out of ten that is viable could be saved, to the benefit of the project. BD2412 T 18:45, 4 July 2026 (UTC)

Assumes facts not in evidence, BD2412. If they weren't deleted by G5 they wouldn't last six months before someone decided to send them to deletion debate as an obvious G5 candidate which constantly gets re-created and edited by a sockfarm. —Jéské Couriano v^_^v ^{Object Class: Drygioni} 20:40, 4 July 2026 (UTC)

Surely you see how that option just makes the case for draftification stronger. BD2412 T 20:51, 4 July 2026 (UTC)

In what universe? It'd just be making one additional waste-of-time step for minimal benefit, because the likelihood of some rando working on a draft that was draftified as G5 not being yet another gimmick of the same sockfarm that made and exclusively edited all the prior iterations of it is abysmally low to the point it's a rounding error. If someone wants to take a serious crack at an article on that subject, they'd need to basically do it from scratch rather than try to adapt the (generally blatantly promotional) text and (universally worthless) sources written by the sockfarm. —Jéské Couriano v^_^v ^{Object Class: Drygioni} 20:57, 4 July 2026 (UTC)

Is there any data to demonstrate those odds? It seems to me that we would need to look at the articles to know for sure. BD2412 T 21:10, 4 July 2026 (UTC)

This is your proposal. The onus of providing supporting data is on you. Where's this supposed featureable content that we're continuously throwing away for no better reason than spite? I'll even make it easy: quarry:query/106998 has deletions from 2026 marked G5, handily sorted by length at deletion. —Cryptic 22:14, 4 July 2026 (UTC)

@Cryptic: HD 93963, a binary star with planets in the constellation Leo Minor (obviously not any sort of spam, and well-referenced) deleted for having been created by a banned editor despite substantial intervening edits. This was raised at WP:RFU, but it is a rare case that an editor will discover that such content exists to be revived. BD2412 T 22:28, 4 July 2026 (UTC)

I could maybe be convinced to support speedy draftifying content like this, created by a banned user but already almost (but not quite) entirely rewritten by others - which is already not speedyable as G5, and never has been - but that's not what you're proposing. —Cryptic 23:08, 4 July 2026 (UTC)

That actually is what I'm proposing, because the only way the typical editor can know whether the content has been rewritten by others is to look at the edit history, which remains available for six months for content moved to draft. What sort of rule would you propose to allow draftification of content like this? BD2412 T 23:21, 4 July 2026 (UTC)

What you wrote at the top of this section proposes to make G5 candidates that actually are G5 candidates non-speedyable, not to make draftifyable content that's only been partially fixed. I'm struggling to see the overlap between these cases.

And trying not to wax hyperbolic here, but the verification issue is true of nearly every page that gets deleted, speedily or otherwise. How can the typical editor know that Basuri really was exclusively promotional without leaving it in draft for six months? That Micro, Small and Medium Enterprises and Textiles Department really did copy its content from https://wbmsmet.gov.in/? That Cash.com was an attack page, not a neutrally-written encyclopedia article describing a fine, upstanding, not-shady-at-all website? For the case you raise here, it's easier to verify than typical: anybody can go to, say, here to see that only the banned user edited Saturn 2 before it was deleted. —Cryptic 00:05, 5 July 2026 (UTC)

The key difference between all of those other kinds of deletion is that an admin is expected to look at the content to determine whether it is an attack, or spam, or a copyvio. With G5, and particularly with G5 mass deletions, the admin need not even look at what they are deleting. BD2412 T 01:04, 5 July 2026 (UTC)

This seems to be an example for sub-optimal application of Special:Nuke, which is not safe to use for pages that are already several weeks old. As Cryptic says, this example is not a valid G5 speedy. —Kusma (talk) 23:27, 4 July 2026 (UTC)

@Kusma: I agree that this is not a valid G5 speedy. In fact, part of my concern is that there are lots and lots of G5 deletions that are not valid in this way. What policy or practice can we put in place to prevent these from happening? BD2412 T 23:44, 4 July 2026 (UTC)

How about "put a link to a XTools/Authorship query for the article in the G5 notice and encourage deleting admins to to check it"? Morwen (talk) 00:07, 5 July 2026 (UTC)

If only the WMF would make us a shiny new Attribution API that told people who wrote the article they're asking for attribution for, instead of just returning a link to Wikipedia. At least it seems to usually work right for files.

User:SD0001/deleted-metadata-link and User:DreamRimmer/DeletedMetaData could stand to have higher profiles, I suppose. If they do what they say reasonably well, anyway; I haven't used either myself. —Cryptic 00:27, 5 July 2026 (UTC)

lots and lots - data, not just a single example and a whole bunch of assumptions, plz. —Cryptic 00:30, 5 July 2026 (UTC)

The data is that a mechanism exists to mass-delete articles without a mechanism to prevent improper deletion of content not actually covered by the rule. A regular editor can't even, on their own, review the citations used in a G5-deleted article. BD2412 T 01:06, 5 July 2026 (UTC)

Quit beating the table into pulp and provide actual evidence, BD2412. Your entire vibes-based argument is akin to answering the classic loaded question by saying your wife is perfectly fine and no, you can't talk to her. —Jéské Couriano v^_^v ^{Object Class: Drygioni} 18:14, 8 July 2026 (UTC)

Oppose We should enforce the rules that banned means banned, not pamper banned editors and encourage WP:BOGOFing. * Pppery * _{in solidarity} 17:06, 4 July 2026 (UTC)

@Pppery:, if someone were to move all of your article-space content to draft space, tag it as problematic, and protect it against editing by new accounts, would you consider that "pampering"? BD2412 T 17:07, 4 July 2026 (UTC)

If I were revealed to be a reincarnation of Technical 13 (as people suspected in 2019) or some other sockmaster and hence all of my content would otherwise have been subject to deletion then yes I would view choosing not to do so as pampering. * Pppery * _{in solidarity} 17:10, 4 July 2026 (UTC)

To clarify, we're not retrospectively deleting (or moving to draftspace) the contributions of banned editors. Only those made after the ban, in violation of it (namely, sockpuppetry). Chaotic Enby (in solidarity · talk · contribs) 20:25, 4 July 2026 (UTC)

• Absolutely not. The purpose of WP:G5 is to discourage ban-evasion by making it unlikely that any of their contributions will have any effect at all; this proposal would weaken that deterrent. Draftifying the creations of sockpuppeteers instead of deleting them would encourage more block-evasion. Blocks are not meant to be "you don't get to contribute to Wikipedia unless someone really likes your edits" or "you only get to contribute to Wikipedia through drafts" or the like. They're meant to prevent someone from contributing to Wikipedia entirely. Under this proposal an editor could repeatedly create new accounts via a VPN, each time announcing "hi, it's me, the person who was blocked for spamming / promotional editing / undisclosed paid COI editing / tendentious BATTLEGROUND editing! Here's ten more drafts of my work!" and we would just have to... accept them? You're effectively proposing that every blocked user be allowed to contribute via draftspace, which is nonsense. If you think a particular blocked user is still capable of making constructive contributions that outweigh whatever got them blocked, encourage them to appeal with a restriction to draftspace - but making it a universal rule that everyone who is blocked gets to contribute drafts, by modifying policy such that there would be no way to actually prevent anyone from openly creating drafts ever? No, absolutely not. --Aquillion (talk) 03:37, 5 July 2026 (UTC)

  Re: "Here's ten more drafts of my work!" and we would just have to... accept them? No, we would not have to "accept them", that's not how draftspace works. Nor is this a rule that everyone who is blocked gets to contribute drafts, as it would only apply retroactively to articles already being considered for G5. How else are we going to make sure innocent editors don't get caught in the crossfire, if the admins using G5 aren't doing it? BD2412 T 03:41, 5 July 2026 (UTC)

  If the problem you see is that admins deleting via G5 because they aren't checking article-history carefully, then how about working on that problem itself? But that means there's also a problem of the taggers (NPP, etc), so that's another locus of problem to address itself. Your solution seems to be not teaching them to do their job better but instead to give more work to AFC folks. Let's see those data: a non-negligible ratio of lost-content to justify it. As of what I'm seeing here so far, it seems mostly like an XY problem for some hard cases make bad law, and the small price we pay in loss of usable content against the large price we'd pay in volunteer time and softening stance on editors who abuse our site. DMacks (talk) 07:09, 5 July 2026 (UTC)

• An admin inappropriately deleting an article that doesn't actually satisfy G5 is deleting the article out of process; if you believe anyone has been doing that, call attention to it and ask people to investigate (any admin could easily do so.) Even once or twice would be enough to start an ANI thread and get them trouted; if an admin continues to do so after that, it would imply either systematic negligence or deliberate maleficence and they could probably be recalled based on that alone, no differently than an admin who just randomly decided to delete an article out of process. That's not a reason to remove G5; the same argument applies to most CSDs. For example, an admin could mistakenly believe or inaccurately assert that something is patent nonsense, or pure vandalism, or a blatant hoax; and once the deletion has occurred, nobody but another admin could double-check that. Our solution to that isn't to change or weaken vital CSDs; it's to treat it seriously when it comes to light. And it would come to light, if it happened with any frequency! It's absurd to suggest that an admin could get away with deleting articles out-of-process for long; if they're regularly deleting articles with non-blocked contributors, one of those contributors is eventually going to notice an article they were editing was deleted, and say "hey, why was the article I edited deleted?" Once this reaches ANI, it's just a matter of hours until another admin looks at the deleted articles, notices the problem, digs deeper, and bam, the articles are getting undeleted and the deleting admin has some 'splaining to do at the bare minimum. At the end of the day it sounds to me like the upshot of your proposal is that we'd be accepting drafts from banned users, in order to "solve" a purely theoretical problem that you made up in your head and which our existing processes can resolve adequately. That is (as I think the direction of this discussion should show you) a nonstarter. --Aquillion (talk) 02:55, 6 July 2026 (UTC)

• The point of this proposal is not to try to get admins in trouble for good-faith use of a flawed mechanism, but to make the mechanism itself more conducive to actually improving the encyclopedia by ensuring some opportunity for community review of content before deletion. BD2412 T 03:07, 6 July 2026 (UTC)

• Oppose Long-term abusers need to be encouraged to find another hobby. Some of the more clever ones troll the community by posting stuff and watching us tear each other apart about what to do. DENY is the only tool the WMF has provided. Johnuniq (talk) 02:32, 6 July 2026 (UTC)
  • If a long-term abuser using a sockpuppet account were to fix a bunch of clear misspellings, or to add clearly relevant reliable NPOV sources where "citation needed" tags were posted, would we revert those edits to deny them their glory? Isn't it just as much of a troll to trick the community into deleting good content? BD2412 T 02:42, 6 July 2026 (UTC)

    I would be astounded if there weren't tens of editors with good hand and bad hand accounts where the good hand account is regarded as an editor in good standing but the bad hand account is blocked because nobody had any reason to suspect either account was socking (and they got lucky not to be discovered on other checks). Similarly there absolutely will be editors who were rightly blocked who have returned and are quietly editing productively without anyone knowing their former status and there will be undisclosed paid editors adding neutral, referenced content about notable subjects (possibly in complete ignorance of our paid editing policy). Nobody investigates editors who quietly add or maintain good content and don't get into arguments. All this is a good thing, because it means the encyclopaedia and its readers benefit from the good content. Thryduulf (talk) 03:05, 6 July 2026 (UTC)

    Some people don't mind abusers. However, Wikipedia depends on a community and many members of that community are distressed when offenders are permitted to repeatedly remind targets that they are watching and can't be removed. We operate under WP:NODEADLINE and do not need typo or citation fixes from abusers. Johnuniq (talk) 03:20, 6 July 2026 (UTC)

    Would you revert a clear typo fix discovered to have been made by an abuser, and restore the typo? BD2412 T 03:30, 6 July 2026 (UTC)

    You are starting to WP:BLUDGEON this discussion ... * Pppery * _{in solidarity} 03:49, 6 July 2026 (UTC)

    I agree with Pppery but will reply that I would revert all edits by a banned user. It would be very counter productive to spend time discussing which edits by a banned user should be retained. People are banned for a reason and often that reason involves harassing the editors who first opposed their changes. Supporting harassed editors-in-good-standing is well worth the cost of not immediately fixing some typos. Johnuniq (talk) 08:33, 6 July 2026 (UTC)

    many members of that community are distressed when offenders are permitted to repeatedly remind targets that they are watching and can't be removed. This is both true and completely irrelevant to the points BD2412 and I made. You might wish to respond to what is actually being proposed rather than this strawman. Thryduulf (talk) 09:42, 6 July 2026 (UTC)

    I was responding to the idea that some edits by banned users should be retained—what am I missing? WP:G5 only applies if there is good reason to believe the editor is blocked or banned and that does not apply to the hypothetical returned user who does constructive gnoming. They have to reveal themselves to be recognized. Johnuniq (talk) 11:22, 6 July 2026 (UTC)

• Comment: this proposal seems to be aimed at a subset of editors who write good articles but get banned for non-content reasons (e.g. complete inability to work collaboratively without spewing insults at everyone else). Do we need a new policy? Wouldn't it be simpler to acknowledge that the correct outcome for a small subset of troublesome editors is to be banned/blocked from everywhere except draft space and their own talk-page? Elemimele (talk) 16:46, 6 July 2026 (UTC)

  The class of editors that you are talking about typically gets banned by ArbCom or by large scale community consensus. It is vanishingly rare for these editors to continue to contribute articles that are then G5 candidates. But in any case, we do not need a new policy for these: ArbCom could just choose to limit these editors' bans if they believe that to be helpful. (I expect they do not believe such a limited ban to be helpful, but I could be wrong).

  Typical G5 candidates are not of very high quality, usually written by editors banned for paid editing or nationalist POV pushing. Most of these editors are persistent sockpuppeteers with large sock farms. —Kusma (talk) 18:16, 6 July 2026 (UTC)

  Exactly. I get the intent of this proposal but I can't see it as useful because (a) it applies to a miniscule number of people; (b) it could be done already for that tiny handful, if ArbCom or the community-acting-via-its-admins wanted. Elemimele (talk) 08:45, 7 July 2026 (UTC)

Reassessment and refinement of proposal

In light of the discussion above, I am persuaded that draftification as usually practiced would be excessive as a solution to the real concern presented, which is:

• How can members of the community be afforded a reasonable opportunity to review content that does not violate other principles of the encyclopedia but is deemed appropriate for mass G5 deletion to insure that:
  • 1) content being deleted actually qualifies under G5 (i.e., does not contain substantial work by innocent editors), and
  • 2) deletion does not hastily dispose of resources that can be commandeered and refactored by trusted editors towards actual improvement of the encyclopedia.

Obviously, the notion of moving G5-eligible articles to draftspace to wait six months for deletion is not popular, and presents valid concerns that bad actors will try to take advantage of that window. I think that the ends indicated above can be accomplished, in a fairly automated fashion, through some combination of a time-limited period for review (perhaps as little as a few days, perhaps a week, as we currently use with PROD) and notification sent to relevant WikiProjects, and perhaps a process like the one we have for suspected copyvios, where the content of the page is replaced with a banner indicating the issue, but remains accessible in the page history pending final deletion. I still think moving the content out of mainspace, to draft or perhaps project space, would be a useful additional precaution. BD2412 T 18:10, 8 July 2026 (UTC)

• Oppose. You have still not provided evidence that would justify treating G5 differently from other CSDs. Your number 1 is a concern for all speedy deletion criteria (sometimes admins get it wrong) and your number 2 is still suggesting that banned editors should sometimes be allowed to contribute, which is not going to fly.
  —Kusma (talk) 18:19, 8 July 2026 (UTC)
  • I have explained in the previous discussion that G5 can be carried out as a mass-deletion process without individual admin review of the content deleted. Another option would be to file a WP:DRV for each deleted article, which would automatically restore them during the course of that discussion, which is typically around a month. That is already a right that exists for all editors. I don't know that it would be a preferable solution. BD2412 T 18:27, 8 July 2026 (UTC)

    BD2412: I'm not normally one to pull this card, but, please, go spend some time cleaning up CAT:PROMO. Not just running these articles though ChatGPT, either, like you've suggested for poorly-written articles recently: actually go, review about 20, and clean/rewrite them. These aren't all sock creations, but many are: and they're a decent amount of what G5 targets.

    The community already has a mechanism to stop articles from being G5-ed: a good faith, non-sock, contributor has to make substantial edits to the page. If you're unable or unwilling to do that, then, well, that's your prerogative. GreenLipstickLesbian💌🧸 21:08, 8 July 2026 (UTC)

    @GreenLipstickLesbian: There is no card to pull. I have two and a half million edits worth of work in all areas of the encyclopedia, including the removal of promotional language. BD2412 T 21:48, 8 July 2026 (UTC)

• Given that editors have received editing restrictions with the G5 criteria in place for a long time, personally I don't think it's a good idea to change this retroactively. As has been discussed by others, I think if the community wants to change the terms of an imposed restriction to supersede G5, it can do so in the discussion where it enacts the restriction. isaacl (talk) 19:01, 8 July 2026 (UTC)
• Perhaps what would work and be acceptable would be something like:

  A G5 speedy deletion of a banned editor's contributions may only be done after a review of the specific page and at a rate no greater than 10(?) pages per day (excluding associated talk pages) unless one of the following applies:

  1. There is an explicit consensus that either:
     1. The editor's contributions should be exempt from G5
     2. The editor's contributions may be deleted under G5 without limit and/or individual review
  2. The editor is a confirmed sockpuppet of an editor first banned more than 30 days ago whose contributions are not G5-exempt
  3. The editor is genuinely believed, by at least two editors in good standing familiar with the case, to be the sockpuppet of an editor whose contributions are not G5-exempt
  4. At least 30 days have elapsed since the ban, and
     1. The editor's contributions are not exempt from G5, and
     2. There is no consensus to maintain the limit for this editor, and
     3. Any discussions about making the editor's contributions exempt from G5 and/or about maintaining the G5 limit for that editor have been closed.

  Obviously this would need to be workshopped and wordsmithed, it is explicitly not a formal proposal at this point. It is an idea presented for discussion. Please do not leave bolded !votes (support, oppose or anything else) in response to this idea and please explain why you (don't) support all or parts of the idea. Thryduulf (talk) 19:56, 8 July 2026 (UTC)

  G5 isn't just for editors evading a ban - it's also for editors evading blocks (WP:BLOCKBANDIFF), it's for editors who are tbanned, it's for new editors writing about topics which have an extended confirmed restriction in place due to extensive, and often nationalist, POV pushing.

  Some of these points just apply to making sure sock blocks are okay; I think we can trust SPI clerks and CUs to action those. So any case that went through SPI has also de-facto sort of fulfills the "two editors in good standing" think they're a sock requirement; any case where the editor filed an unblock also fulfills that.

  Anyways, we have a way to make somebody's contributions G5 exempt: go and edit the article. It does require... actually touching mainspace, not just arguing about wikipolicies, so I'm not expecting all the village pump regulars to know that's an option. But it is. GreenLipstickLesbian💌🧸 21:27, 8 July 2026 (UTC)

  The point of this is to make sure that other editors actually can edit the articles, which requires that they not be deleted immediately. Thryduulf (talk) 21:46, 8 July 2026 (UTC)

  G5 is unique amongst CSDs in that they only apply once it's clear (either thru behaviour or technical evidence) that a sanction is in play. And since G5s aren't immediately obvious there's a grace period where the articles can be edited with nobody being the wiser. —Jéské Couriano v^_^v ^{Object Class: Drygioni} 21:56, 8 July 2026 (UTC)

  Most Wikipedia articles fall under WP:DEADLINE, so there is no particular pressure to check the utility of any given article by any given editor. Where an article is suspected to be subject to G5 deletion, it would be nice to have some notice rather than suddenly seeing, for example, a bunch of links in a template turn red. BD2412 T 22:02, 8 July 2026 (UTC)

  You'd be surprised how frequently you get that notice. Ignoring SPI doesn't change the fact that they very frequently presage G5s. —Jéské Couriano v^_^v ^{Object Class: Drygioni} 22:12, 8 July 2026 (UTC)

  Are Wikiprojects alerted when a contributor of articles under their bailiwick is the subject of an SPI? That would also be a good step. BD2412 T 22:14, 8 July 2026 (UTC)

  Apart from the technical difficulties in implementing this, I do not think "user X is under suspicion of sockpuppetry" is a message that should be pushed to all of their potential collaborators. It is one thing that SPIs are public and another thing to draw extra attention to them. —Kusma (talk) 05:29, 9 July 2026 (UTC)

• 'Oppose – See my objections in the above section. fifteen thousand two hundred twenty four (talk) 07:22, 9 July 2026 (UTC)
• Comment. As per others, I think this proposal really wants to be "encourage admins / the community to be more willing to hand out blocks for all but Draft and User space". I'm willing to believe that there are certain blocked editors who produce content that might be useful but are blocked because they can't collaborate, and giving them an outlet for that can be healthy. The problem is that the universe of blocked editors includes those whose contributions are not good faith and would be a waste of time to try, or so unreliable as to be worse than nothing, or even just validation of trolling by forcing someone to read an anti-XYZ screed. That's the G5-as-written case where such contributions should be speedily and instantly deleted, no looking, just move on. SnowFire (talk) 20:36, 12 July 2026 (UTC)
• Oppose for the very obvious reasons described above. scope_creep^Talk 08:16, 18 July 2026 (UTC)
• I'm not convinced there is a problem that needs solving at the moment. I wrote an essay on this topic: Wikipedia:G5 is not a firm rule. Already under current policy and practice, administrators are empowered to use their discretion to draftify or choose not to speedily delete pages that are clearly beneficial to the encyclopedia, and if an administrator deletes a page that someone else thinks is actually beneficial to the project, there are options available to that other editor to rectify the situation. The most common case for G5 is when a sockfarm is trying to push articles about non-notable topics (e.g. autobiographies or run-of-the-mill companies). Since no amount of editing can overcome a lack of notability, draftification would be the wrong choice for these topics. G5 lets administrators save the community 7 days of AfD time at our discretion because blocked/banned editors shouldn't be editing anyway. Mz7 (talk) 08:31, 18 July 2026 (UTC)
• Oppose - largely per Mz7 and others here. Another big reason G5 exists is because a lot of serial sockpuppeteers make articles in violation of topic bans and as such, any article created by them are immediately poisoned. Administrators shouldn't have to interact with pages clearly made in bad faith other than to delete them. ♠JCW555 (talk)♠ 18:25, 18 July 2026 (UTC)
• Comment: This has been proposed over and over again. If it fails this last time, could we just add the G5 proposal to WP:PERENNIAL? I'm also thinking that the "we should allow AI" threads (there was one in June) are well past their time, and deserve a WP:PERENNIAL addition. Somepinkdude (talk | contribs), in solidarity 19:25, 18 July 2026 (UTC)

  I am not asking for banned editors to be able to edit. I am only asking for an opportunity for the community to review G5 deletions, short of taking them to DRV. BD2412 T 22:48, 18 July 2026 (UTC)

  Asking that contributions by banned editors be retained for a time-limited period for review, when considering that our current policy forbids banned editors from making any such contributions to begin with, sounds like allowing banned editors to edit to me. fifteen thousand two hundred twenty four (talk) 14:53, 19 July 2026 (UTC)

  It isn't allowing banned editors to edit at all, it's allowing the community time to verify that the pages are actually created by banned editors and contain no significant edits by non-banned editors and deleting them will not harm the encyclopaedia (which are requirements of the current policy, albeit the last is implicit). Thryduulf (talk) 15:03, 19 July 2026 (UTC)

  See point 2 of the proposal. Current policy prohibits banned editors from contributing resources in any regard, this proposal de facto facilitates banned editors adding resources.

  Your comment seems to largely consider point 1, which is irrelevant. Admins already determine if content being deleted actually qualifies under G5 as part of actioning G5, same as for any other speedy deletion. fifteen thousand two hundred twenty four (talk) 15:19, 19 July 2026 (UTC)

  This appears to be an argument for deprecating all forms of speedy deletion in lieu of moving articles to draftspace. After all, how does the community know that attack page was really an attack page? That G11 was really an advertisement (a criteria which, I'd guess, is far more abused than any other). That A3 really had no text? That page which disappeared into the OS hole, how do we know it really needed to be OS-ed? Why not give the community an opportunity to review all of those to make sure they're valid and that deleting them will not hard the encyclopaedia? GreenLipstickLesbian💌🧸 19:57, 19 July 2026 (UTC)

  @GreenLipstickLesbian:, we do as a project worry about what happens if an admin goes rogue and misuses the tools (or even uses them too aggressively). If an admin were to decide to randomly delete as many low-attention articles as they could and claim that the deletions were pursuant to a CSD criteria, how would we find out that they were so doing? What if we presume that they were clever enough to create a sockpuppet account to tag the articles and then follow up with their admin account to delete them, so it looked like an exercise in confirmation of the tag? Once the article is deleted the identity of the CSD tagger becomes obscured. I am concerned about all of these possibilities, but CSD G5 is the only criteria that allows for deletion of an article based solely on who created it (and whether anyone else worked on it thereafter), rather than anything to do with the content of the article, so the propriety of deleting it cannot be determined from looking at the content alone. I would add that a copyvio or an attack page or spam should be deleted with the rationale that it is in fact a copyvio or an attack page or spam, since those are deleted irrespective of who created them. BD2412 T 21:26, 19 July 2026 (UTC)

  Yes, you have made it abundantly clear that you disagree with the community/arbcom's decision to base G5 on the creator's identity.

  It isn't the only criteria which allows for that, though; OS operates without any public criteria or oversight, and permanently deletes pages based on the identity of their creator.

  I am not interested in your admin sock conspiracy theories. GreenLipstickLesbian💌🧸 21:50, 19 July 2026 (UTC)

  That doesn't make sense. First, content and lists of contributors both become inaccessible to normal users once the article is deleted, but remain visible to administrators; both cannot be verified by normal users, but can still be verified by any admin, so the distinction you are making does not exist. Furthermore, if an admin were to G5 an article with substantial contributions by legitimate users, there would be one group of non-admin users who could reasonably notice - the legitimate contributors in question. This is unique to G5, which means that it is actually the CSD criteria an administrator is least likely to abuse in this manner; every contributor would become a potential whistleblower and would remain so forever, since all it would take is one of them trying to navigate to the article only to see it was G5ed to expose what happened. The fact that this has never happened in the 20 years G5 has existed further underlines the fact that it's not a reasonable concern. --Aquillion (talk) 21:55, 19 July 2026 (UTC)

  (You can use User:SD0001/deleted-metadata-link to see the list of contributors of a deleted page, so it's not totally gone) * Pppery * _{in solidarity} 00:16, 20 July 2026 (UTC)

  This whole paragraph reeks of WP:ABF. Yes, admins have gone rogue, but the amount of them that have is so astronomically dwarfed by the amount of normal sockpuppets and abusers that it's ridiculous. If you truly believe that an admin is socking for the sole purpose of what you're describing, report them to ArbCom then. Otherwise stop with this conspiratorial thinking.

  The fact that you're more worried about the tiny amount of admins that have gone rouge (and like Aquillon said above, never for this reason) versus the way bigger problem of sockpuppets and banned editors continuing to edit says something. They were banned for a reason. ♠JCW555 (talk)♠ ♠JCW555 (talk)♠ 21:59, 19 July 2026 (UTC)

  I do agree with the broader point that we do need more transparency (as much as we realistically can) towards deletion and other admin-exclusive processes. I will note that we already have Wikipedia:Database reports/Possibly out-of-process deletions, and that a similar report for G5 deletions (e.g. scanning for deleted pages with substantial edits by a non-blocked users) could be helpful. Chaotic Enby (in solidarity · talk · contribs) 22:51, 19 July 2026 (UTC)

  @Chaotic Enby: I'd be happy with that. I assume setting such a thing up would be similar to the setting up of the other report. BD2412 T 23:15, 19 July 2026 (UTC)

  Yep, they use {{Database report}} combined with an SQL query, which a bot periodically updates. Chaotic Enby (in solidarity · talk · contribs) 23:23, 19 July 2026 (UTC)

  I've made an attempt at Wikipedia:Database reports/Possibly out-of-process deletions/G5. But, well, I agree this line of thinking is silly. G5 is one of the few criteria in which a script can (attempt to) determine whether it qualifies or not. If an admin was going to try to abuse their rights by deleting lots of obscure articles and hoping nobody notices they would use something like A7 or G11 instead which are both broad, impossible to verify without human judgement, and so common as to not draw any notice. * Pppery * _{in solidarity} 00:16, 20 July 2026 (UTC)

  ... and I'm sure somewhat will look at this report, see the mistake I already pointed out at User talk:Liz#Mass Mario deletions and claim vindication. But on the contrary the fact that I caught that batch deletion via a completely unrelated mechanism shows that admins can be caught if they do bad stuff as-is. * Pppery * _{in solidarity} 00:19, 20 July 2026 (UTC)

  Thanks a lot! I was trying to write something, but you've been much faster than me! I take it that the second query is scanning for edits by non-blocked users? Chaotic Enby (in solidarity · talk · contribs) 00:20, 20 July 2026 (UTC)

  Yep. And I don't think the data exists to exclude reverts; edit summaries of deleted edits (rightly) aren't available in the wiki replicas. Change tags might be (I don't know offhand) but even if they are determining what is and isn't a revert is tricky from them alone. * Pppery * _{in solidarity} 00:23, 20 July 2026 (UTC)

  I was thinking of the very blunt (Reverted) tag, but I sure can't say where to find it in the database replica... Chaotic Enby (in solidarity · talk · contribs) 00:25, 20 July 2026 (UTC)

  (edit conflict) It turns out that tags of deleted edits are available (they're in the mw:Manual:Change_tag table) However, do you mean "reverts", "reverted edits" or both - your comment here contradicts your one above. * Pppery * _{in solidarity} 00:32, 20 July 2026 (UTC)

  Well I mixed up (Reverted) and (Undo), whoopsie! I did mean reverts, not reverted edits. Chaotic Enby (in solidarity · talk · contribs) 00:36, 20 July 2026 (UTC)

  Would I be correct to think that the way to go at it would be the likes of:

  (select ar_len from archive where ar_namespace=log_namespace and ar_title=log_title
    and not exists (select 1 from change_tag on ar_rev_id=ct_rev_id where ct_tag="mw-undo" or ...)
    order by ar_timestamp desc limit 1) as size,
  

  Chaotic Enby (in solidarity · talk · contribs) 00:44, 20 July 2026 (UTC)

  Not quite. mw:Manual:Change_tag table#ct_tag. You have to reference mw:Manual:Change_tag_def table in addition. I've had a go at it on the SQL report, since I as usual was doing the same thing as you at the same time. * Pppery * _{in solidarity} 00:48, 20 July 2026 (UTC)

  If someone finds it, we could also exclude tags like AFCH and Twinkle (example). Chaotic Enby (in solidarity · talk · contribs) 00:32, 20 July 2026 (UTC)

  Just added a line to exclude bots from the second query, which should avoid some pretty skewed results there. Chaotic Enby (in solidarity · talk · contribs) 00:29, 20 July 2026 (UTC)

• Oppose; this would add completely pointless layers of red tape and busywork to the vital task of cleaning up after block-evaders and to our system of discouraging ban-evaders. I'd further oppose any changes whatsoever stemming from this discussion, or any further discussions in any way stemming from it. You have repeatedly failed, over an extended period of time, to raise any reasonable or credible concerns with G5 whatsoever; your handwaving about theoretical abuse of G5 (contrary to your assertions above) applies much more clearly to every other CSD, since both content and edit history are visible to administrators and no one else. Nor, more importantly, have you substantiated the idea that your concerns have ever once been an issue actual, not a single time, in the multiple decades G5 has existed. G5 is twenty years old. It is not an exaggeration to say that it is nearly as old as Wikipedia itself. If your concerns had any serious basis whatsoever, you would be able to point to at least one incident surrounding it, yet you have not. Neither, in my opinion, have you given a credible explanation for why you're targeting G5 specifically; an "obscure article" could be deleted under an invalid CSD at any time (though, again, you have failed to demonstrate that this has ever happened in the twenty years G5 has existed), and both the contribution history and content would then become inaccessible. Either way, this conversation has reached WP:DROPTHESTICK territory; it is obvious at this point that not enough people share your concerns about G5 to make any changes to it. --Aquillion (talk) 21:55, 19 July 2026 (UTC)
• Oppose per above. * Pppery * _{in solidarity} 00:16, 20 July 2026 (UTC)
• Oppose per "we now have a database report that does the job". Chaotic Enby (in solidarity · talk · contribs) 00:24, 20 July 2026 (UTC)
• Oppose per above. We delete them for a reason. FaviFake (talk) 00:35, 20 July 2026 (UTC)

Should we disallow opening parallel RM and AfD discussions?

Right now, nothing stops someone from opening a requested move on an article's title while an AfD discussion about that same article is still running, and vice versa. In the case of Robinson list, for example, we ended up with four separate discussions about basically the same question. (See Special:Permalink/1362924519 and Special:Permalink/1362895939.) Since the creation of parallel RMs and AfDs happens relatively frequently, I'm thinking this could be solved with a simple rule: if an article already has an open AfD, no new RM should be started on it until that AfD closes, and, vice versa, if an article already has an open RM, no new AfD should be started on it until the RM closes. If any RM or AfD is started, they can be procedurally closed.

Having an RM and an AfD about the same article creates a risk of contradictory outcomes: an AfD could close one way and a concurrent RM could point the other way. What's the point of discussing the name of an article if the article might not exist in a week? An AfD that's considering a merge is, for example, is effectively already a discussion about scope and naming. The proposed rule wouldn't stop anyone from raising the naming or merge question, it would just mean raising it in the existing discussion, or starting a new one after the old one ended, which usually happens in a week. If someone thinks the AfD is heading the wrong way, or thinks a merge target's name is wrong, they should post a comment in the open discussion. This is already covered in part by WP:AFD4: If an AfD discussion is already open but you would like to propose an alternative target or outcome (e.g., merge the article instead of deleting it), do not create a second nomination. Instead, consider contributing to the open discussion.

I'm not sure if there could be edge cases where this wouldn't work well, this is just the first solution that came to mind. What do you think? FaviFake (talk) 10:51, 7 July 2026 (UTC)

Courtesy pings: Paditor, Nathannah, Kirbylegal, Spartaz, Elemimele, Wcquidditch, Pburka, BarrelProof, Jruderman, GrinningIodize, Thincat, SchreiberBike as participants in the discussions I cited. Notified: Wikipedia talk:Articles for deletion, Wikipedia talk:Merging, Wikipedia talk:Deletion process, Wikipedia talk:Speedy keep and Wikipedia talk:Requested moves. FaviFake (talk) 10:58, 7 July 2026 (UTC)

This just seems like common sense to me. Mangoe (talk) 11:10, 7 July 2026 (UTC)

It's not common sense to everyone. Even despite the fact that I only monitor the merge nominations at AfD, I see editors opening a RM during an AfD about once a week. Having a clear rule that allows the newer discussion to be procedurally closed would help immensely. FaviFake (talk) 12:12, 7 July 2026 (UTC)

I meant that it is common sense to shut down parallel discussions in general. Of course people start them, because people tend to focus on their present concerns and try to deal with them immediately. Mangoe (talk) 12:32, 8 July 2026 (UTC)

I've addressed this in my comment below. FaviFake (talk) 13:25, 8 July 2026 (UTC)

(edit conflict) Parallel discussions are pretty much never a good idea, so I'd support something like this. All that needs to happen is for one of the discussions to be procedurally closed in favour of the other. Which discussion should be closed will depend on the circumstances, but obviously if the outcome of one depends on or could be impacted by the outcome of the other the dependent one should be closed. For example we will normally procedurally close an RfD if there is an ongoing AfD, RM or merge discussion about the target page. Thryduulf (talk) 11:11, 7 July 2026 (UTC)

(edit conflict) I don't see anything wrong with having a discussion about deletion that starts after an RM is opened. When someone comments in an RM discussion that a topic is not notable so an article should be deleted, it is commonly replied that the RM is about what the title(s) should be, not whether the articles should exist. And if we have a poorly named article that might not be appropriate as an article at all, both issues should be discussed and resolved, although different questions arise in those discussions. When there are multiple different RMs open for the same article at the same time, it is common for all but one of them to be procedurally closed. It is often agreed to wait for a deletion discussion to close before trying to close a parallel RM. —⁠ ⁠BarrelProof (talk) 11:15, 7 July 2026 (UTC)

Sorry @FaviFake I was unaware of that. I am a reletively new editor on here but have it noted for future. Thinking about it in hindsight (of which we all know is 20/20). I would support this proposal. Kirbylegal (talk) 14:21, 7 July 2026 (UTC)

Surprised this is common. It makes no sense to open an RM for an article at AfD, there are multiple AfD outcomes that could render an RM moot. This reasoning would not apply in the other direction though, and making it automatic for an RM to close upon an AfD feels like it opens a potential avenue to disrupt RMs. CMD (talk) 14:25, 7 July 2026 (UTC)

Yup, unfortunately it is relatively common. Another example I can think of off the top of my head would be The Eagle (gay bars), where at one point there were seven parallel discussions about the article, including a RM opened 2 days after the previous six discussions were opened. In cases like this, a rule allowing the new RM to be procedurally closed would at least help with the mess.

Maybe opening an AfD during a RM could be allowed only in urgent cases, such as current event or severe policy violations? FaviFake (talk) 14:37, 7 July 2026 (UTC)

What's an "urgent" AfD? — Very Polite Person (talk/contribs) 14:48, 7 July 2026 (UTC)

Something that technically doesn't fit any of the narrow WP:CSD criteria, but really needs to not be here. You could IAR delete it if it's that urgent, but establishing consensus properly is rarely a bad thing. SarekOfVulcan (talk) 19:21, 7 July 2026 (UTC)

@Chipmunkdavis, I'm not surprised that this is common. Merge discussions were only merged into AFD a few months ago. It usually takes people a couple of years to adjust to a significant process change. WhatamIdoing (talk) 04:52, 17 July 2026 (UTC)

To the extent that would have made a different to the cases mentioned it should be a slight improvement, an RM should not be opened for an article with an AfD discussion whether or not AfD includes the merge process. CMD (talk) 05:02, 17 July 2026 (UTC)

I tend to agree, but then I'm obviously comfortable !voting to merge at AFD, since I do that at a rate approximately three to four times as often as that's been an AFD result (~25% for me vs ~7% for AFD before RM was folded into it). WhatamIdoing (talk) 05:13, 17 July 2026 (UTC)

Agreed that is an AfD is open a Requested Move or ideally any heavy maintenance tagging on the article should be blocked - not "may", "should", or "could". Once something is a LIVE afd page, "standing down" shouldn't be a could-be or may-be, but an automatic "no".

What about if a Requested Move is active/already there (even by minutes) and someone else tossed up the AfD?

I do not support the idea that either has primacy by whatever arbitrary letters present in the URL or surrounding project page history/legacies.

I don't know the best answer but this FEELS like a rare binary we have the opportunity to streamline/summarily pre-murder shenanigans and drama.

• If AfD live = no +RM added allowed binary rule, you don't get to start a new RM, and everyone will revert you freely till you're spitting mad if needed.

^ no brainer, easy slam dunk fix.

• If RM live = we can't say you CAN'T afd newly, but then what?

^ not a no-brainer? — Very Polite Person (talk/contribs) 14:41, 7 July 2026 (UTC)

@FaviFake, thank you for bringing this to my attention. I would support a rule that restricts RMs during AfDs as you've described. I apologize for opening a second AfD discussion for Robinson list, as I was not aware of Wikipedia:AFD4 at the time. GrinningIodize (talk) 15:08, 7 July 2026 (UTC)

No worries! As I said in my comments above, the problem is widespread so I just picked that discussion as an example! FaviFake (talk) 15:10, 7 July 2026 (UTC)

The order of operations matters some. If the AFD is posted first, an RM discussion that will be rendered moot by deletion or merger is a waste of the community's time. AFDs often generate article improvements and sometimes substantial changes to article content and sourcing that may be relevant to the RM so even when the article is kept, letting the AFD play out before starting an RM is sensible. If the RM starts first, it's not necessarily a waste of time to start an AFD, although my preference is always to wait. —Myceteae‍🍄‍🟫 (talk) 15:20, 7 July 2026 (UTC)

I mostly agree, but how can we turn the last part into a more rigid rule? Just saying it is not recommended won't help solve the problem. There's definitely no reason to hurry if the article has low page views, but I can see why an AfD could be started parallel to a RM if the article is about a current, rapidly evolving event. In some cases, I can see why it might be best not to wait for a RM to fully close before starting an AfD, but for more low-stakes articles people should just wait. What concrete criteria should an article satisfy to be eligible for being nominated at AfD and RM concurrently? FaviFake (talk) 17:17, 7 July 2026 (UTC)

I'm not sure we should have a firm prohibition on starting AFDs after RMs because I'm not sure what the criteria would be. I'm more inclined to support procedurally closing all RMs that start during an active AFD. It seems like this is the actual locus of the problem, anyway. I'm far more active on RM than AFD and I rarely see this. —Myceteae‍🍄‍🟫 (talk) 18:00, 7 July 2026 (UTC)

I don't think it's necessary to have a policy. I have already seen people procedurally close either an AfD or RM because a parallel discussion is ongoing. I trust our closers to exercise common sense. Katzrockso (talk) 18:10, 7 July 2026 (UTC)

I often refrain from closing RMs about the same article because I'm usually involved and it could be argued the closure wouldn't qualify as WP:MULTI. I'd like there to be a clear rule that allows me to close these RMs even in borderline cases. FaviFake (talk) 18:21, 7 July 2026 (UTC)

I thought about WP:MULTI but I'm not sure it applies, anyway, since these discussions address fundamentally different questions, although of course the issues often overlap. Is this only an issue with merge proposals at AFD, and has the problem increased since the PAM–AFD merger? The scope and content issues effecting mergers have more overlap with article title considerations than GNG, copyvio, etc. issues that inspire article deletion nominations, so I could see how this happens. —Myceteae‍🍄‍🟫 (talk) 18:32, 7 July 2026 (UTC)

Yeah, that's what makes me uncomfortable with closing these RMs procedurally. About the problem increasing: I don't know, I've only started to monitor merge nominations and AfD more generally only after PAM was wound down. FaviFake (talk) 19:08, 7 July 2026 (UTC)

Given that an AfD can result in a keep and move the page result, I would support procedurally closing RMs opened during an active AfD discussion. It's already an accepted practice in WP:RMEC; Furthermore, any editor may end such a move request with a procedural close: to centralize related discussions that should have been a multi-page discussion.

Do we need anything further than that? Perhaps slightly clarifying that sentence to explicitly include AfD Katzrockso (talk) 19:16, 7 July 2026 (UTC)

to centralize related discussions that should have been a multi-page discussion does not cover these situations, except perhaps those involving the Eagle gay bars, which was an extreme example of extraneous and unnecessary discussions. I read that part of the guidance as applying to a situation where a bunch of similar move requests on different pages are closed procedurally to consolidate what should have been a a single proposal for multiple moves conducted on a single page. —Myceteae‍🍄‍🟫 (talk) 19:30, 7 July 2026 (UTC)

I can see how someone might read it that way. I wouldn't oppose a new short bullet point adding "when the article is already at Wikipedia:Articles for deletion" to that section of WP:RMEC. Katzrockso (talk) 23:14, 7 July 2026 (UTC)

I'm leaning towards supporting this. It's a pretty substantial change to the RM closing instructions so hopefully more editors will weigh in. —Myceteae‍🍄‍🟫 (talk) 01:37, 8 July 2026 (UTC)

There needs to be an allowance for situations such as where the AfD has an apparent consensus that RM is the better course of action and an RM is opened before the AfD is formally closed. In cases like that the RM should stand and the AfD closed. It's probably less common than inappropriate RMs while an article is at AfD but less common is not never. Thryduulf (talk) 02:09, 8 July 2026 (UTC)

That's a fair point. We can add a footnote to accommodate this situation. Katzrockso (talk) 03:58, 8 July 2026 (UTC)

That would still be allowed. As long as there aren't any open AfD discussions about an article, editors can open new RMs. FaviFake (talk) 09:08, 8 July 2026 (UTC)

@FaviFake I think you missed the point that it should be allowed to open an RM when there is an open AfD in a few limited circumstances. Thryduulf (talk) 09:22, 8 July 2026 (UTC)

I must've missed it; where was that suggested? I thought that exception only applied to opening an AfD when there is an open RM, not vice versa. FaviFake (talk) 09:25, 8 July 2026 (UTC)

I suggested it, and explained the rationale for it, in the comment you replied to. Thryduulf (talk) 09:34, 8 July 2026 (UTC)

Well, not really. A RM should never be opened if there is an ongoing AfD, but in case it is opened before the AfD is closed, the latter should be closed rather than the former. I don't think we should allow open[ing] an RM when there is an open AfD in a few limited circumstances. We can simply say that, in case someone incorrectly opens a RM during an AfD, in some cases it might be best to fix the issue by closing the AfD rather than the RM. FaviFake (talk) 09:43, 8 July 2026 (UTC)

The point is that in the situation I described, opening the RM isn't incorrect. Thryduulf (talk) 10:12, 8 July 2026 (UTC)

@FaviFake, I think I've missed something important. Here, you say "As long as there aren't any open AfD discussions about an article, editors can open new RMs". However, in practice, when editors do that, you unilaterally turn their RMs into AFDs (examples: [3] [4] [5] [6]), and just the other week, you were telling me that all RMs have to happen at AFD.

Do you possibly mean something like "Unless editors who want to talk about a merge use at least one template, tag, notification, category, or take some other other noticeable/monitorable actions, then I guess we won't be able to notice every single discussion about merging articles, but whenever I do notice it, I'll do my best to force that discussion to happen at AFD"? Because I think that other people have a different idea of what it means to "open a new RM". WhatamIdoing (talk) 05:08, 17 July 2026 (UTC)

I believe you are conflating RM and PAM. I've never moved a RM discussion to AfD, and I only move formal PAM proposals, not all merge discussions. If a merge proposal does not use the formal {{PAM templates}}, then it's a simple talk page discussion and shouldn't be moved, as I've explained on my talk page. FaviFake (talk) 11:51, 17 July 2026 (UTC)

Yes, you're right. I was thinking about WP:PM instead of WP:RM. WhatamIdoing (talk) 21:17, 17 July 2026 (UTC)

I'm not an expert on Wikipedia procedures but it seems like if consensus has been reached, by definition the AfD is complete and should be closed—in other words, an editor shouldn't rely on consensus to start the RM unless they're also closing the AfD as having reached consensus. That said I think this addition would be essentially harmless, and I'd support the change with or without it. Elliptical Reasoning (talk) 18:17, 17 July 2026 (UTC)

OK, figured out where my non-expertise came in, I hadn't realized those things had different privilege requirements. Disregard the objection above. Elliptical Reasoning (talk) 18:32, 17 July 2026 (UTC)

(in reply to this comment) If there is enough consensus at AfD, it should be closed first, otherwise we'd go back to having two parallel discussions. The AfD needs to be closed first, otherwise it will continue to attract editors and it will likely become harder to close it over time. FaviFake (talk) 10:15, 8 July 2026 (UTC)

Generally yes, but there may be exceptions, but procedurally closing an RM just to close an AfD with consensus to open an RM is pointless bureaucracy.

More generally, an RM and an XfD affecting the same page should almost never be open at the same time. Where they are, one of them should be closed. In most cases where AfD is involved the RM should be discussion that is closed, but most is not all. In most cases where RfD is involved the RfD should be the discussion that is closed, but most is not all.

Another example of an exception to the general case would be a well-established ongoing RM that has lots of thoughtful comments none of which are suggesting deletion or merging but during which someone opens a borderline frivolous AfD.

Ultimately what we want to do is make it clear that one discussion should be closed without being too rigid about which discussion that should be. Thryduulf (talk) 10:21, 8 July 2026 (UTC)

You are both correct and I'm not sure we need to dwell on edge cases. If an AFD is winding down and it appears quite clear that consensus is 'keep and proceed to RM', editors should virtually always wait for a formal AFD close before initiating the RM. RMs are rarely urgent and waiting a few days keeps things "clean". But on the occasion where someone does jump the gun and start the RM because it is SNOWing at AFD, a reasonable would-be closer should let the RM proceed. This is well within the closer's discretion. WP:RMEC, WP:SNOW, and other early closure provisions allow for early closure but closers are expected to consider other factors particular to the discussion at hand. Also, as I've said elsewhere and at least some others agree, it matters which discussion is started first. If the AFD starts first, the RM should almost always be procedurally closed. If the RM starts first, starting a separate deletion nomination is less problematic, although my strong preference is to almost always wait for the RM to close. If we add a bullet to WP:RMEC it should say something like "When an AFD discussion is ongoing and was started first, where the AFD outcome may render the RM question moot and where concurrent discussions are counterproductive". That needs major wordsmithing but approximates what I think we are trying to get at. —Myceteae‍🍄‍🟫 (talk) 19:26, 8 July 2026 (UTC)

And perhaps closers can use some light encouragement to procedurally close these more often, without mandating that every such discussion be closed. As @Thryduulf indicated, procedural closes (for this an other reasons) seem to be more common at RFD. We do still sometimes see prolonged, complex discussions left open while a parallel RM or other discussion plays out. But the culture of each of these venues is a bit different—sometimes for good reason—and RFD is more permissive of quick determinations to close discussions procedurally. —Myceteae‍🍄‍🟫 (talk) 18:26, 7 July 2026 (UTC)

The current RM at Talk:Atlantic (Dufresne album) is a good example of a case where a deletion discussion and an RM can run completely independently of each other without causing any problems. —⁠ ⁠BarrelProof (talk) 20:25, 7 July 2026 (UTC)

You call this a good example?
If the article gets deleted before the RM discussion closes, we can [...] stop worrying about what its title should be.

All of the replies mention AfD in one way or another, making the !votes unnecessarily conditional. Also, I can't seem to find any AfD discussion for that article...? FaviFake (talk) 21:49, 7 July 2026 (UTC)

Yes, I think it's a good example. Perhaps I should have used the word "could" rather than "can", since no AfD has been opened, as you noticed. But the possibility of an AfD has been discussed, and the opinion has been expressed that such a discussion could take place independently without causing a problem. —⁠ ⁠BarrelProof (talk) 22:08, 7 July 2026 (UTC)

Fine example. —Alalch E. 19:55, 8 July 2026 (UTC)

I think merge discussions also need to be included. Merges often emerge as a soft delete for article material anyways User:Bluethricecreamman (Talk·Contribs) 22:10, 7 July 2026 (UTC)

Merge discussions occur at AFD, and FaviFake clarified that the concurrent AFD–RM discussions they encounter have all involved AFD merge proposals. —Myceteae‍🍄‍🟫 (talk) 22:18, 7 July 2026 (UTC)

• I'm not sure if the two processes are symmetrical. In practice, rm usually requires editors to examine reliable sources to determine the common name. That same sourcing exercise often answers the notability question as well. If enough independent rs cannot be found, rm is unlikely to get very far in the first place. Accesscrawl (talk) 10:44, 8 July 2026 (UTC)
• Oppose (do not disallow). Wikipedia:Avoid instruction creep. Concurrent AfD and RM is proven to work. I have had good experiences with concurrent AfD and RM -- from the top of my head: Killing of Shani Louk -- October 30 AfD and the concurrent RM. I'm not convinced that anything about how the linked discussions concerning Robinson list went suggests adding a new written norm to any policy or guideline.—Alalch E. 19:55, 8 July 2026 (UTC)

  This is a great example, which I recommend reading, because it challenges many intuitions here. Both the AFD and RM were orderly and effective. Both presented serious and important questions. Both benefitted from running separately yet simultaneously, because this kept them focused while avoiding unnecessary bureaucratic delay.

  Now consider various factors to decide whether the RM should have been procedurally closed right then. First, the RM was created 48 minutes after the AFD – but why should it have mattered here, whether it was 48 minutes after or before? Second, in hindsight, we see that the AFD turned out as SNOW keep – but at the time, could a would-be early-closer have assumed what the AFD outcome would be? (Only one day before, a closer of a prior discussion had concluded there was no consensus and permitted the immediate AFD.) Third, I began by emphasizing that both the AFD and RM were highly productive – but (devil's advocate) was it so obvious that that would happen, or is that also colored by hindsight?

  I don't mean to pick on these factors; in fact, I agree with Myceteae that they're excellent factors to consider – with discretion and judgment. I was struck by reading one comment above, and troubled by the latter part of it: "I often refrain from closing RMs about the same article because I'm usually involved ... I'd like there to be a clear rule that allows me to close these RMs even in borderline cases." I, for one, do not want involved people anywhere near closing borderline cases. Adumbrativus (talk) 07:21, 11 July 2026 (UTC)

  I agree, there are several good points here, and it may just be that Killing of Shani Louk is an example of the sort of concurrent discussion that should be allowed to stand even if we adopt a guideline to generally close one of these. And if we do adopt that provision, the close is still best done by an uninvolved editor if there is any hint that it is a borderline case. Well meaning would-be closers should always consider whether their involvement will give the appearance of impropriety, even if they believe most other reasonable closers would have made the same call. An involved close is likelier to invite scrutiny, controversy, and further disputes, contrary to the goal of holding one orderly discussion at a time. —Myceteae‍🍄‍🟫 (talk) 17:55, 11 July 2026 (UTC)

Not sure that I get a bolded opinion as I was pinged but I agree with FaviFake, RM should be subordinate to a deletion discussion and therefore should not be allowed to run concurrently to an AFD unless there is a special reason to allow it l, which I'm sure needs no instruction but can be agreed by a consensus at the AFD. Spartaz ^Humbug! 17:08, 10 July 2026 (UTC)

but can be agreed by a consensus at the AFD. ...or potentially at the RM. Noting, again, that I think this should be a fairly rare occurrence, I think editors in RM are empowered to argue for the legitimacy of the discussion itself, in addition to the merits of the move proposal. This arises in other, more common situations at RM, for example when someone calls for a procedural or early close on the grounds that it is too soon after the prior RM. It would be up to the closer to weigh the merits of keeping the RM open vs. the problems associated with running concurrent discussions. Also, it's fine to leave a bolded !vote. FaviFake indicated that they pinged everyone involved in the recent AFD discussions, with no evidence of biased canvassing. —Myceteae‍🍄‍🟫 (talk) 17:48, 10 July 2026 (UTC)

I disagree that RM should have equality in making that call. One venue needs to be subordinate to the other. Spartaz ^Humbug! 23:10, 10 July 2026 (UTC)

I completely disagree. It should be about the strength of the arguments presented at RM for an exception to the (proposed new) usual practice. It makes no sense to derail an AFD discussion to assess the merits of whether some other discussion should be allowed to proceed. The community can decide that AFD usually supersedes RM but AFD participants are not some Supreme Court that gets to decide whether other venues have jurisdiction on a case-by-case basis. —Myceteae‍🍄‍🟫 (talk) 23:27, 10 July 2026 (UTC)

I agree with Myceteae and disagree that one venue needs to be subordinate. A productive RM should not be derailed by a frivolous AfD (or vice versa) for example. Which is the best venue is entirely dependent on the individual circumstances so we need to allow editors discretion to close the discussion that needs to be closed, regardless of which one that is. Thryduulf (talk) 11:23, 11 July 2026 (UTC)

Another example of a RM that was just closed as moot because it was opened during the AfD discussion: Talk:Do not call list § Requested move 6 July 2026. FaviFake (talk) 09:05, 16 July 2026 (UTC)

I would consider the multiple merge proposals involving Robinson list and Do not call list and this RM all part of one big incident. It's not clear whether this is a representative example or is an extreme case of a pair of articles that for some reason inspired a flurry of mutually exclusive proposals all at once. —Myceteae‍🍄‍🟫 (talk) 22:05, 16 July 2026 (UTC)

Right, that's true. What I can say is that, based on my experience (again, I've been monitoring all articles nominated specifically for merging since April 2026), most of the few concurrent RMs I saw were failures. I'm not sure if there's a way to get more concrete data but that's just what I've been seeing myself. Is there a way to get more data on this practise? FaviFake (talk) 22:37, 16 July 2026 (UTC)

It'd be difficult, but I think if someone were both determined and had some computer skills, a general estimate could be found. You'd have to line up the timestamps on the AFDs with the timestamps for talk-page sections. The talk-page sections can't be reliably identified, but Twinkle has a standard format, so you could try to use that to find most of them. WhatamIdoing (talk) 05:18, 17 July 2026 (UTC)

To look at these moving forward, it seems like it would be trivial to build a report or maintenance category of articles that are currently co-listed at RM and AFD. That would help characterize and monitor this problem now and, if there is a decision to change the RMEC criteria, would provide a tool or identifying candidate discussions for procedural closure. —Myceteae‍🍄‍🟫 (talk) 16:14, 17 July 2026 (UTC)

AfD takes precedence over RM. An AfD is a more serious question. An AfD usually goes to the quality of the sourcing. An RM needs to consider the sourcing. An AfD delete or merge renders the RM moot. So, if an AfD is opened during a RM, pause the RM. Exceptions may occur.

If the RM would solve the problem alleged at AfD, that sounds like a speedy keep, a WP:BEFORE failure, for the AfD. A consensus to rename can occur at AfD. A consensus to delete is not valid in an RM. SmokeyJoe (talk) 13:26, 17 July 2026 (UTC)

I'm not sure. Imagine the case of a recent death. It's common for editors to try to delete those articles; it's also common for editors to debate whether it should be called "Death of...", "Killing of...", "Murder of...", "Assassination of...", etc. I don't see any reason why editors need to stop talking about what the name should be on the talk page, especially when the AFD looks unlikely to result in deleting or merging the article away. Sure, if it does get deleted or merged away, the discussion is moot, but editors can volunteer their time on anything they want, including discussions that would only matter under certain circumstances. WhatamIdoing (talk) 21:43, 17 July 2026 (UTC)

I think it is more common for these articles, which are of dubious notability, to be unilaterally draftified by a new page patroller. I watch it happen, and I’m not sure that it is a bad thing.

when I say “pause the RM”, I mean (probably) delist it, and certainly stop the RM clock, but that doesn’t mean forbid further posts to the RM section. SmokeyJoe (talk) 23:32, 17 July 2026 (UTC)

New page patroller here. I'm pretty sure that you're right about the first point, but it's worth noting that our backlog is immense and it's growing by the hundreds-to-thousands every week, so it usually takes a pretty long time for a given article to get patrolled; by the time that a patroller ends up at a page, it may be far too late to draftify it under WP:NOTBACKDOOR.

I've personally witnessed unpatrolled articles from over a decade ago. GrinningIodize (articles without a Wikidata item) (talk) 14:11, 18 July 2026 (UTC)

Very old unpatrolled articles? Aren’t they all old redirects that were overwritten by a new article? There was some talk of doing something to account for that. -SmokeyJoe (talk) 07:57, 19 July 2026 (UTC)

The section title word “disallow” is too strong. I recommend “discourage”. Opening an RM during an AfD should be “discouraged”. This does not mean discouraging talk page posts about title matters.

However, opening an AfD during an RM is more than ok, if a thorough WP:BEFORE has been done and a good AfD nomination is written, and it references the ongoing RM. The opening of a frivolous AfD is a serious problem, a running RM or not. SmokeyJoe (talk) 00:38, 18 July 2026 (UTC)

if a thorough WP:BEFORE has been done and a good AfD nomination is written
Note that WP:BEFORE checks (or more precisely, points C and D) don't need to be performed if the nominator is not proposing deletion. FaviFake (talk) 15:53, 18 July 2026 (UTC)

User:FaviFake, yes, sure. Where the AfD is proposing deletion, I think it is extremely likely to be justified to take precedence over an RM, but subject to it being a good, not frivolous, nomination. Reminding AfD nominators of BEFORE encourages better, non-frivolous AfD nominations.

If the AfD nomination is for a merge, I still lean to it taking precedence over an RM, but with less confidence. Maybe, interrupting an RM due to a proposal to merge, should require two editors to support the merge (aka a seconder to pause the RM in favour of discussing a bigger option of a merge). SmokeyJoe (talk) 00:35, 19 July 2026 (UTC)

Huh, that may be a good idea! We could decide that, in more unclear cases, the proposal to close the overlapping RM must be seconded by someone else. That could be the clear-cut criterion we need. FaviFake (talk) 10:34, 19 July 2026 (UTC)

How exactly would this work? It sounds like this would effectively give the seconder a WP:SUPERVOTE to close discussions regardless of the opinions of other editors. Suppose 10 editors are actively engaged in an RM that they feel is legitimate. An eleventh editor chimes in to say we should close this because there's already an open AFD. A twelfth editor (the seconder) comes along, agrees with 11, and closes the RM. And what is the procedure? Does the initial editor indicate their intent/desire to procedurally close through some special venue or documentation? How are would-be seconders recruited? —Myceteae‍🍄‍🟫 (talk) 17:23, 19 July 2026 (UTC)

It sounds like this would effectively give the seconder a WP:SUPERVOTE to close discussions regardless of the opinions of other editors
Well, in a way yes, but that's only because the RM likely shouldn't have been started in the first place and has stood on fragile grounds since its creation. It is rare for editors to propose closing a RM because an AFD exists, so if there are 2 people who share this opinion, then the RM most definitely should be closed.

Does the initial editor indicate their intent/desire to procedurally close through some special venue or documentation?
They would simply comment under the RM or AfD discussion stating clearly that they believe the RM should be procedurally closed, and then a second editor may reply to that comment or come up with the same suggestion on their own in the other discussion. If any editor sees these two comments and the RM hasn't ran its course, they are always allowed to procedurally close it in favour of the AfD discussion. Or, the seconder can close it themselves directly if they notice the first comment. They don't have to post a second comment per se, they can simply write a quick procedural closure statement indicating why the two discussions are incompatible. This system is similar to PROD: 1 person tags the article and gives an explanation, while the other one checks that it's procedurally correct and performs the deletion. We should avoid having unnecessary bureaucracy for these time-sensitive decisions.

Wait, I just had a new idea! What if, instead of permanently closing the RM, it were closed temporarily? In all the various scenarios proposed here, the problem isn't the RM itself! The actual issue is that the AfD and the RM are open at the same time! We could just decide that any editor, even involved editors, can temporarily close the RM if there is a parallel AfD discussion, and then any editor, even involved editors, is allowed to re-open the RM if the nominated page isn't deleted or redirected at AfD. This is the perfect solution because it solves the problem of two parallel open discussions, while allowing the RM to continue if it is still relevant, without losing the previous comments! FaviFake (talk) 22:57, 19 July 2026 (UTC)

It is rare for editors to propose closing a RM because an AFD exists. Right, per your statements here, isn't this largely because there is no consensus or guideline encouraging such closures? If we change that then presumably there will be more of these. I'm trying to understand how this would operate under the current system or under a new guideline that spells out some criteria for early closure. Either way, I'm skeptical and not in support of endorsing a supervote mechanism based on my understanding of how this might operate.

As for temporary closure, I'm uneasy about that approach, too. When discussions are closed for any significant length of time and then re-opened, results are mixed. Often the discussion has gone stale. There may be relevant arguments raised at AFD (even if the result was 'keep') and significant changes to the article content during the course of the AFD that impact the RM determination. When there's a big gap in the discussion and important intervening developments have occurred, it can be difficult for new participants to jump in and for closers to determine the meaning and relevance of early !votes—these problems arise at RM, anyway, and are sometimes unavoidable, but I wouldn't want to build them in. Procedurally, we don't have a mechanism to 'pause' an RM other than to close and then re-open it. It can be disorienting when a discussion flips back and forth between open and closed and the history of what has happened and why is often not clear. Presumably, such early or temporary closes could be subject to WP:MRV, which would further complicate things.

In some (many? most?) cases, it is actually better to procedurally close the first discussion and then launch a fresh one once the AFD has concluded. This allows for the proposal to be reworked if necessary and for the nominator to highlight discussions and other developments between the opening of the first and subsequent RM. To be clear, I'm not yet fully onboard with routinely closing these RMs early, but that may be less disruptive. —Myceteae‍🍄‍🟫 (talk) 23:21, 19 July 2026 (UTC)

Right, per your statements here, isn't this largely because there is no consensus or guideline encouraging such closures?
I doubt that two users will satisfy all of these conditions:

• be aware that this obscure procedure even exists
• have the same opinion
• be willing to close a discussion early, even if they are allowed to, and have the script / technical skills to do it
• happen to land find themselves on a rare RM for an article that currently is also at AfD

Again, I think the similarities of this system and PROD still guarantee ''enough layers of cheese relatively to the weight of such a temporary closure.

When discussions are closed for any significant length of time and then re-opened, results are mixed.
AfDs don't usually last a long time, they're usually closed within two weeks and most are closed earlier. And, as was said by many opposers in this discussion, RM and AfD discussions fundamentally tackle different questions. One is: "should this article exist?", while the other is: "given that it exists, how should it be called?". They don't necessarily have to collide, which is why the reason behind this whole thread is just to prevent pointless discussions about the title of an article if we don't know whether it will continue to exist as a standalone article.

it can be difficult for new participants to jump in and for closers to determine the meaning and relevance of early !votes [...] the history of what has happened and why is often not clear
We could use a message like this, similar to the {{Merge MfD note}} that also helps closers in a similar way:

This requested move was temporarily closed on July 27 because there was a parallel AfD discussion. Now that the AfD has been closed, the discussion has been reopened. {{esig}}

Presumably, such early or temporary closes could be subject to WP:MRV, which would further complicate things.
We can just decide that they cannot be reviewed at MRV. A move review will virtually never be closed faster than the AfD, and the closure will be "overturned" anyway after the AfD ends (which, again, usually happens relatively quickly!). If even such a benign closure is so controversial, it likely means the two discussions wouldn't have been able to co-exist harmoniously without causing a mess in the first place.

In some (many? most?) cases, it is actually better to procedurally close the first discussion and then launch a fresh one once the AFD has concluded.
That can still be allowed! If an editor in good faith decides to create a new RM before anyone has re-opened the one that closed temporarily, then the new discussion takes precedence and the previous discussion is moot due to the other developments between the opening of the first and subsequent RM. Sure, there may be some odd edge cases, but having two parallel RM/AFD discussions is (relatively) so rare that editors can just use commons sense. Our main goal should remain to prevent two discussions from running at the same time, and this proposal achieves that. FaviFake (talk) 00:06, 20 July 2026 (UTC)

I'm honestly more confused about how this is supposed to work and I don't see the similarities to PROD. If we think it's unlikely that two editors who agree with an early/temporary closure and know about this obscure procedure will find each other, what benefit is there to the procedure in the first place? If we accept, for the sake of argument, that concurrent RMs and AFDs are a problem, then an intervention that is unlikely to be carried out is not much of a solution.

To me, this sounds like the opposite of PROD in terms of effecting the more drastic outcome. With PROD, any single editor can object and prevent the drastic outcome (soft deletion). With this, any seconder can unilaterally impose the drastic outcome (procedural close) even over the objection of 10 other editors. To be fair, procedural closure is less drastic than soft deletion.

If we were to implement something like this, a note modeled after {{Merge MfD note}} would make sense.

I mostly agree with your takes on MRV and the duration of AFDs. But implementing all this still seems quite convoluted and more likely to irritate editors than to streamline effective discussions. RM regulars tend to be sticklers for following closing instructions. This includes latitude for complex or unique closes, but there's an expectation that they can be challenged. Say I'm one of the 10 editors who wanted the RM to proceed. I go to the talk page of the closer (the 'seconder') to challenge it. They inform me of this obscure procedure. I think that's bogus and take it to MRV. After perhaps a few days or a week, my MRV is procedurally closed. Or maybe someone has chimed in and said they agree the RM should be re-opened, what then? Does another supervoting closer at MRV get to make a unilateral call?

Also, while I agree that AFDs usually run shorter than MRVs, I'm assuming that the types of articles that get concurrently nominated at AFD and RM have a lot of issues and therefore might be prone to longer discussions. And I do think that a two week 'pause' in a discussion is not ideal, even if it is possible to revive a fruitful discussion after such time has passed. —Myceteae‍🍄‍🟫 (talk) 02:05, 20 July 2026 (UTC)

an intervention that is unlikely to be carried out is not much of a solution
That was mostly in reply to your suggestion that if this procedure is enacted, then presumably there will be more of these editors closing these discussions. (Which is what we generally want in the first place, since concurrent RM discussions currently are almost never closed early.) I'm just trying to come up with a set of criteria that's as deterministic and straightforward as possible without being too bureaucratic to effectively close these discussions in a reasonable amount of time.

Maybe, in addition to 2 involved editors agreeing, we can establish that even 1 single editor can close the RM temporarily, provided that they are completely uninvolved in both discussions.

any seconder can unilaterally impose the drastic outcome (procedural close)
Sure, but just like PROD, any editor can re-open the discussion once the AfD is closed, which makes their closure very weak. I doubt that the arguments at the RM would massively overlap with those at the AfD, as those venue fundamentally have different objectives, so I don't think a temporary closure would be as "drastic" as you describe. With the simple orange MfD-like note and the assumption that in most cases the arguments are still valid if the article is kept, I think this system doesn't impact or "disorient" the RM discussion to a noticeable degree. And if the early !votes are rendered irrelevant after the AfD is closed, it means the system successfully halted a discussion that was going to fail anyway!

Does another supervoting closer at MRV get to make a unilateral call?
This sounds very unlikely to actually happen, but: if the AfD hasn't been closed yet, they would procedurally close the MRV and tell the appellant to wait; and if the AfD discussion has been closed, they would procedurally close the MRV and tell the appellant to reopen the RM or create a new one. These RMs intentionally stand on such fragile grounds precisely because AfD looms over them.

I'm assuming that the types of articles that get concurrently nominated at AFD and RM have a lot of issues and therefore might be prone to longer discussions.
That isn't necessarily the case. In this example, every AfD discussion was closed in a week or less.

a two week 'pause' in a discussion is not ideal, even if it is possible to revive a fruitful discussion after such time has passed
Well, maybe that's where we disagree. Sure, a discussion being paused for 2 weeks is not a perfect situation, but I think it's much more ideal that a 2-week-long discussion that is rendered moot by the mighty AfD discussion. That's the problem I'm trying to come up with a solution for. FaviFake (talk) 13:44, 20 July 2026 (UTC)

Thanks for the detailed reply. I think we have common goals about facilitating effective discussions but have different perspectives on what constitutes a problem and which solutions make sense. I think there's a difference between "this discussion could have waited" versus "this is disruptive" and of course there are many shades of grey in between. In looking the Robinson list–Do not call list situation, there were three concurrent discussions with substantial overlap. With the benefit of hindsight, I think a reasonable editor could have closed one or two of those per WP:MULTI with a dash of WP:IAR and common sense, without needing the support of a new guideline. In fairness, such bold action may have been controversial, but who knows? But if Robinson list was an outlier, and most of the time the RM and AFD questions are clearly distinct—which they should be—and the discussions proceed without much disruption or confusion, then I'm not convinced we need to 'fix' anything. —Myceteae‍🍄‍🟫 (talk) 16:41, 20 July 2026 (UTC)

The Eagle gay bars situation was also a bit of a mess but arguably it was the RM proposal that saved it. Six of the seven concurrent discussions were AFDs. I'm hard pressed to say that the RM was the problem. —Myceteae‍🍄‍🟫 (talk) 16:50, 20 July 2026 (UTC)

• Oppose (do not disallow) per Alach E. I don't buy this notion that AFD is somehow "more important" than RM, and I think it's silly for editors to imply that there is some sort of turf war between the two processes. They are both important, and cover different things; RM is particularly important for high-visibility articles where the choice of title is sometimes controversial and requires careful analysis, while of course AFD is most often concerning topics of borderline notability. Obviously if an article is eventually deleted, that does render any ongoing RM moot, but I don't think we should prohibit editors from discussing the title at an RM in the normal fashion just because someone has decided to put the article up for AFD... there's likely to be cross-pollination anyway, an editor who wants to move the article will probably also vote "keep" in the AFD for example.  — Amakuru (talk) 17:26, 17 July 2026 (UTC)

  AfD isn't even that powerful as AfC can supersede it and vice versa (which is a factual statement, I did it myself). — Very Polite Person (talk/contribs) 17:47, 17 July 2026 (UTC)

  The issue of high visibility articles is a good point. @WhatamIdoing's examples of "Murder of …" articles in reply to @SmokeyJoe above very often in this category. I think I've commented elsewhere in this thread that RMs are rarely urgent, but getting the proper title for a high traffic article involving BLP and current event concerns is important. Such high profile articles often attract a lot of participants at RM and AFD and have rapidly changing facts on the ground that make it difficult to assess whether opinions in early !votes are applicable to the current state of affairs. All of this can prolong discussions. It would be a bad practice to lock a problematic title in place while an AFD goes on for 2+ weeks. —Myceteae‍🍄‍🟫 (talk) 23:23, 17 July 2026 (UTC)

• Allow parallel discussions… but… mandate that both discussions should have a link to the other. Blueboar (talk) 21:53, 17 July 2026 (UTC)

  Agree. People coming to contribute to an RM should be aware if there is a proposal to delete, which includes deletion of all the talk page posts. SmokeyJoe (talk) 23:35, 17 July 2026 (UTC)

  I agree. The concurrent discussions should be cross-linked fairly prominently. —Myceteae‍🍄‍🟫 (talk) 14:32, 22 July 2026 (UTC)

• Allow concurrent discussions. I think concurrent discussions should usually be avoided but after much consideration I don't see cause to implement a new rule or standard. When an RM proposal arises during the course of an AFD, or vice-versa, I would encourage editors to wait for the first discussion to close in most cases. Editors launching the second discussion should ideally make a clear case for why the new discussion is distinct and should occur now. Editors may occasionally boldly close a discussion that is deemed disruptive, confusing, or duplicative following the normal standards but the mere existence of a concurrent RM and AFD is not sufficient. It might help to create a maintenance category or report that shows all pages that are currently co-listed at AFD and RM. This would help identify a pattern and whether there is a need for further intervention. —Myceteae‍🍄‍🟫 (talk) 14:31, 22 July 2026 (UTC)

why stop there? Why not lock the cathedral of lies in their entirety so we own "the truth"? Ices333 (talk) 17:31, 25 July 2026 (UTC)

— Ices333 (talk • contribs) has made few or no other edits outside this topic. —⁠ ⁠BarrelProof (talk) 19:02, 25 July 2026 (UTC)

Introducing WikiForms – A native tool for data collection and forms within Wikimedia

Hello community,

​For various administrative tasks, surveys, and data collection within Wikipedia, we often rely on third-party platforms like Google Forms. While functional, this raises concerns regarding data security, privacy, and seamless integration with our existing ecosystem. ​To address this, I have developed WikiForms, a custom form builder tool tailored specifically for Wikimedia projects.

​The core development is almost complete, and the interface is fully available in English. I would love to get your valuable feedback, suggestions, and feature requests to make it ready for active community deployment.

• Tool link: https://wikiforms.toolforge.org
• Repo: https://github.com/anafibnshahibul/WikiForms/

Please feel free to visit the site, create a few test forms, and share your thoughts here. Whether it's about UI/UX, security, or feature suggestions, your input will be immensely valuable!

​Best regards, Anaf Ibn Shahibul (talk) 15:11, 8 July 2026 (UTC)

Hi! Thanks for the work you put in this! I see that the tool brands itself as "AI-powered", could you go into more detail about what it is like?

Additionally, I see that Wikiforms incorporates cookies from Google Ads and Google Analytics, which might not be ideal as Wikipedia projects function on a volunteer, ad-free basis. Can you also clarify this for me? Chaotic Enby (in solidarity · talk · contribs) 19:56, 8 July 2026 (UTC)

@Chaotic Enby

Thank you for pointing this out! The inclusion of Google Ads and Analytics was a mistake from the early setup and is being completely removed right away. WikiForms will be entirely ad-free and tracking-free to respect Wikimedia's privacy values. As for the "AI-powered" tag, it was meant for automated quiz grading and basic bot-protection, but based on community feedback, I am removing those features entirely to keep the tool simple and safe. Anaf Ibn Shahibul (talk) 00:33, 9 July 2026 (UTC)

Hello! I notice that you've licensed your work under Creative Commons Attribution-ShareAlike 4.0. Are you aware that applying such a license to software can have potentially unwanted implications?

(I'm not a lawyer and this is not legal advice.) GrinningIodize (talk) 20:57, 8 July 2026 (UTC)

Additionally, I have some more questions:

• You say that data security and privacy are a concern when using Google Forms, but how would this third-party alternative fix those issues? What privacy laws do you certify compliance with?
• Google Forms is backed by a massive multi-billion dollar corporation with thousands of customers. They have a strong financial incentive to keep their customers happy. What incentivizes you to keep your potential customers happy? Do you intend on providing paid services or accepting donations?
• Your site advertises "AI-powered answer grading" and "real-time anti-cheat protection", but how would these features be beneficial to the Wikipedia community, where cheating is not a major concern?
• WikiForms has a cookie settings prompt stating that it uses cookies from Google Ads. Wouldn't this actively harm privacy?
• How is your service being audited for security vulnerabilties? A quick glance at the file tree in your README would suggest that there are dozens, perhaps even hundreds of files that could harbor potential vulnerabilities.
• Your SECURITY.MD file gives you up to 3 days to fix a vulnerability, but what leads you to believe that this will be sufficient in production, considering that you only have one contributor?

Thank you for your time. GrinningIodize (talk) 21:25, 8 July 2026 (UTC)

@GrinningIodize Thank you for the excellent feedback!

There are your answers:

• Licensing: You make a very valid point. I realize that while Creative Commons works perfectly for Wikipedia's text and articles, it isn't designed for software source code and can cause compatibility issues. I am relicensing the codebase under a standard open-source software license (like the MIT License or GPL) immediately, and keeping CC BY-SA only for the documentation and assets.
• Privacy: The core goal of WikiForms is to provide a self-hosted, open-source alternative within the Toolforge ecosystem so that community data stays within Wikimedia rather than being handed to a third-party corporation. There is absolutely no plan for commercialization, paid services, or ads; this is entirely a volunteer project for the movement.
• Security: I hear your concerns about the complex file tree. I am currently performing a major cleanup to delete experimental scripts, minimize the codebase, and reduce any potential vulnerability surface. I am also updating the unrealistic 3-day patch policy in SECURITY.md to reflect a more practical timeline for a volunteer developer.

Thanks for give your opinion. Anaf Ibn Shahibul (talk) 00:38, 9 July 2026 (UTC)

Thanks! For the sake of transparency, are you using AI assistance to write your replies in this thread? Chaotic Enby (in solidarity · talk · contribs) 09:36, 9 July 2026 (UTC)

@Chaotic Enby,
​Yes, to be transparent, I used AI to recheck my grammar and tone because Bengali is my native language. However, all the decisions and core points are entirely my own.
Anaf Ibn Shahibul (talk) 11:58, 9 July 2026 (UTC)

Just so you know, Wikipedia editors usually prefer to see imperfect grammar rather than what often feels to be bland, boilerplate AI prose. As a courtesy, I'm pinging @Sohom Datta, one of our best technical editors who also happens to be a Bengali speaker! (and will be much more qualified than me regarding data privacy aspects, which seems to be one of the main sticking points here) Chaotic Enby (in solidarity · talk · contribs) 12:49, 9 July 2026 (UTC)

@Chaotic Enby Thank you for advise me. I really appreciate the warmth and honesty of this community.

And thanks for pinging @Shom Datta! Having a fellow Bengali speaker, who understand technical data privacy will be incredibly helpful for making WikiForms better and safer for everyone. Anaf Ibn Shahibul (talk) 15:31, 9 July 2026 (UTC)

Thanks for the quick response! I'm still a bit concerned that your service doesn't seem to have any independent security audits or certifications, despite holding email addresses and other private information acquired from Wikipedia users. How would you answer these concerns? Do you intend on finding a third-party auditor before entering production? GrinningIodize (talk) 16:00, 9 July 2026 (UTC)

Also, if you don’t intend on having ads, may I inquire as to why your site has Google Ads cookies in it? GrinningIodize (talk) 16:04, 9 July 2026 (UTC)

"AI-Powered" - thanks, but no thanks. What AI integrations are even possible in a visual editor for forms with a few checkboxes/textareas?? I could make the same thing with a 2002 version of PHP, with zero vibe-coding and zero JS. This genuinely looks like a honeypot to gain access to random Wikipedia accounts. Why and when Toolforge became a free dumpster for vibe-coded shit that's at best tangentially related to Wikimedia projects are even better questions, though. sapphaline (talk) 23:02, 8 July 2026 (UTC)

I agree with most of these points, though I probably would have phrased it in a less expressive manner (no offense, sapphaline). — Preceding unsigned comment added by GrinningIodize (talk • contribs) 23:06, 8 July 2026 (UTC)

@Sapphaline, @GrinningIodize

​To clarify the number of files: the project is built on top of the Laravel framework, which automatically generates a standard directory structure and boilerplate configuration files. It isn't a collection of bloated custom scripts, but rather a standard framework setup designed to follow secure coding practices. However, I am still cleaning up any unused default files to keep the repository as minimal as possible. Anaf Ibn Shahibul (talk) 00:49, 9 July 2026 (UTC)

@Sapphaline

Thank you for your candid feedback, sapphaline. I understand your skepticism. The AI integration was an experiment for evaluating quiz responses, but I agree it is unnecessary here, so I am completely removing all AI components.

To be absolutely clear, this is not a honeypot. WikiForms will strictly use standard Wikimedia OAuth for any user verification. The tool will never ask for, collect, or store your Wikipedia password or credentials—everything is handled securely by Wikimedia's own infrastructure. I am focusing on stripping down the codebase to make it transparent and minimal. Anaf Ibn Shahibul (talk) 00:40, 9 July 2026 (UTC)

what ai are you using in the projected? how can we trust that it wouldn't false flag user's? Lavender-wikigirl (talk) 23:26, 8 July 2026 (UTC)

also with the ai proctored, the project runs the risk of ai hallucinations(this is the main resun llm are banned from making edits on the main wikipedia). Lavender-wikigirl (talk) 23:30, 8 July 2026 (UTC)

@Lavender-wikigirl,

Thank you for your response! To clarify where these protections are applied:

​The AI protection and bot defense were specifically built into the quiz module.

In addition to response checking, the tool includes bot protection at the API level. If a direct request is made to the API from an unauthorized or unrecognized IP address, the system will automatically reject the request.

​However, as mentioned, to completely prevent any risk of AI hallucinations or false-flagging within our community workflows, I am stripping out the LLM/AI components entirely and focusing purely on the core form-building and secure API verification features. Thank you for your valuable insight!
Anaf Ibn Shahibul (talk) 00:43, 9 July 2026 (UTC)

Out of curiosity, when the AI features were still present, what model(s) did you use for anti-cheat? Cam I see the relevant source code files somewhere? GrinningIodize (talk) 16:02, 9 July 2026 (UTC)

Whoops! Meant to say "can", not "cam". GrinningIodize (talk) 16:02, 9 July 2026 (UTC)

@GrinningIodize Regarding the anti-cheat system: when the experimental AI features were active, it utilized the OpenRouter API to dynamically validate form submissions against spam or automated pattern inputs. Since moving towards a cleaner open-source architecture, those parts are being deprecated. You can find the basic integration setups in config/services.php (which purely pulls from environment variables). Anaf Ibn Shahibul (talk) 08:47, 10 July 2026 (UTC)

Got it! Thanks! GrinningIodize (talk) 15:42, 10 July 2026 (UTC)

I tried, and got error pop-up dialog box with "Requests from unauthorized origins are not allowed" at this page. Steps:

1. https://wikiforms.toolforge.org, click Get Started
2. click Data Form; ⟶ https://wikiforms.toolforge.org/create
3. on Untitled Form, click Log in with Wikipedia
4. received "Requests from unauthorized origins are not allowed"

I started over, following steps 1–3 as above, and this time, got an empty form with a big 'Publish' button at the bottom, and it recognized my log in. (I am on Vivaldi 8.0 on Windows 10.) So, the bug seems to be resolved after a second try, but it did happen on the first attempt.

Do you have a phabricator project, and where is it? If not, where do you want notification of bugs and other feedback, especially after this VPT thread is archived?

Suggestions: add a small Info icon, maybe top right near the login id, with a link to an on-wiki description of the tool, or a reference manual if you are planning on having one. Add an additional link among the fine print links at the bottom, for 'Bugs', and maybe another one for 'Feedback'. A link for 'About us' (or 'Developers') would be appropriate to briefly describe your team, and the motivation for the project. Thanks, Mathglot (talk) 16:57, 9 July 2026 (UTC)

I think that you're meant to report bugs on the GitHub issue tracker. GrinningIodize (talk) 16:59, 9 July 2026 (UTC)

Perhaps; should be linked on-form in any case. Mathglot (talk) 17:31, 9 July 2026 (UTC)

@Mathglot,

The "Requests from unauthorized origins" issue on the first attempt happens due to strict Cross-Origin (CORS) and session cookie checks when navigating straight into /create before a session state is finalized. I am fine-tuning the Laravel Sanctum configuration to prevent this initial origin conflict. And Thank you so much for the amazing feedback! Adding an Info icon, 'Bugs', 'Feedback', and 'About' links at the bottom is an excellent idea. I will absolutely implement these links into the interface. For on-wiki tracking, I don't have a Phabricator project yet, but until then, I will link the GitHub issue tracker directly on the form for easy bug reporting. Anaf Ibn Shahibul (talk) 08:44, 10 July 2026 (UTC)

Doesn't the WMF just use meta:LimeSurvey? ARandomName123 (talk)^{Ping me!} 07:14, 10 July 2026 (UTC)

I'm also confused as to why you felt the need for Google analytics and marketing cookies. ARandomName123 (talk)^{Ping me!} 07:31, 10 July 2026 (UTC)

@ARandomName123 To clarify, the Google Analytics and marketing tracking code was a leftover from a boilerplate template used during the initial frontend setup. I have completely removed all Google tracking/ads components from the codebase now. If you still see the tracking cookies, it is due to browser caching. Clearing your browser cache will completely remove them. WikiForms will remain 100% tracker-free and ad-free! Anaf Ibn Shahibul (talk) 08:45, 10 July 2026 (UTC)

Yeah, from what I understand, making LimeSurvey more accessible to communities would be much more preferable to reinventing the wheel! Neat project tho, just using a nuclear bomb to deal with a mosquito in a frog pond. Chaotic Enby (in solidarity · talk · contribs) 12:07, 10 July 2026 (UTC)

More feedback:

• Creating the form
  • Add section trash can
    • is vertically centered on the right; that is an atypical location. Top right is more typical (as in Short text #2).
    • I didn't at first recognize it as a trash can; maybe something more like , , , ?
  • Why is the first question input field labeled SHORT TEXT #2? Why not #1?
  • Hitting the Publish button doesn't appear to do anything below the fold, which is where you are when you hit it. It does not clear the form, does not go to a new page like a confirmation page, but it does create a Published! note you can't see above the fold. Since I couldn't see it, I kept hitting Publish, so I probably have several copies of my test survey out there. Maybe use a hash footprint plus userid to check/prevent dupes?
  • Form localization – I want to control most survey and button label text:
    • 'Fill Out Form'. I want to control this button label text.
    • true/false labels; 'True' and 'False' are not appropriate for my survey; I want 'yes' and 'no' (and for another one, maybe I want 'Oui' and 'Non').
    • 'Email (optional — to receive results)'.
    • 'Submitted! Your response has been recorded.' and 'Back to Home'

• Finding my forms
  • How do I find my forms if I didn't see/didn't record the published message? You need a 'My Forms' link somewhere, that goes to a page listing my forms in a table; at a minimum, a bare list, but a sortable six-col table would be nice, with name, created, last update, form size (or question count), number of responses, link to responses.

• Finding my results
  • I have one response (by me) to my survey. Where do I go to see the results?
  • Some kind of sortable summary table would be nice

Thanks, Mathglot (talk) 17:42, 9 July 2026 (UTC)

@Anaf Ibn Shahibul, I think that I may have found leaked credentials in your repository (I used Claude Sonnet 5 to conduct a search, but I have verified its output; this comment is entirely manmade). I am currently suspended from GitHub and I'd prefer to avoid sending emails. What is the proper method for me to report this information to you securely? GrinningIodize (talk) 17:44, 9 July 2026 (UTC)

Some more issues:

• Publishing empty forms fails silently.
• You can't log in unless third-party cookies are enabled.

GrinningIodize (talk) 18:14, 9 July 2026 (UTC)

@GrinningIodize I'll remove cookies soon. Anaf Ibn Shahibul (talk) 05:50, 10 July 2026 (UTC)

Awesome! Thanks! GrinningIodize (talk) 15:43, 10 July 2026 (UTC)

@Mathglot Thank you for testing! When you are logged in and viewing your form, you can find the "Responses" option right at the bottom of the page. I am also planning to add a sortable summary table there soon to make it much easier to analyze the data! Anaf Ibn Shahibul (talk) 05:50, 10 July 2026 (UTC)

@Anaf Ibn Shahibul: just noting, that you are not allowed to collect personally identifiable information on toolforge. https://wikitech.wikimedia.org/wiki/Wikitech:Cloud_Services_Terms_of_use#7.2_If_this_is_a_Toolforge_Project —TheDJ (talk • contribs) 10:49, 11 July 2026 (UTC)

When it comes to running something like this (you are not the first person). Really consider how multiple security audits, resellience and reputation come into play, as well as legal liability (data leak responsibility). All that needs to be covered by contracts for almost any usage within our movement. The software is just half of the puzzle, and arguably the simpler part. —TheDJ (talk • contribs) 11:01, 11 July 2026 (UTC)

Hi @TheDJ, thanks for the guidance!

I have completely removed the tracking scripts to follow the PII rules. I’ve also locked down the APIs—anyone trying to access them directly or from other domains will get a 403 error. I also adding many security features.

The project is strictly "In Development" right now, and there is no risk of data leaks. Since this is open-source, anyone is welcome to contribute and help me improve the security further!
Anaf Ibn Shahibul (talk) 05:28, 12 July 2026 (UTC)

In the current build, the Usercentrics platform and the Google Ads/Analytics cookies are still present, is this intentional? Chaotic Enby (in solidarity · talk · contribs) 14:39, 12 July 2026 (UTC)

@Anaf Ibn Shahibul: Why is it attempting to shove tracking cookies onto those who visit, let alone do so by default? What sort of "AI proctoring" is involved? What would the purpose of a quiz even be for here? Do you have access to any of the data or is it secured so that only sysops and higher (those the community has chosen to trust) can access it? How is the data encrypted? Jerod Lycett (talk) 05:51, 13 July 2026 (UTC)

Even sysops wouldn't be high enough in terms of trust. We aren't required to sign the ANPDP, a binding agreement related to access to nonpublic information. If personally identifiable information is to be stored, you'd be looking at functionaries (arbitrators, CheckUsers and oversighters), who routinely deal with nonpublic information and are required to sign it. As pointed out above, storing this kind of information isn't allowed on Toolforge and would most likely require you to co-develop your platform (alongside an appropriate privacy statement) with WMF staff familiar with the relevant requirements in terms of data retention. Chaotic Enby (in solidarity · talk · contribs) 16:06, 13 July 2026 (UTC)

I'll also note that the current project lacks any privacy statement at all, only linking to the Wikimedia Foundation Privacy Policy. Chaotic Enby (in solidarity · talk · contribs) 16:15, 13 July 2026 (UTC)

@Chaotic Enby and @Jerodlycett, Thank you for your critical feedback. This is an open-source hobby project, and I highly appreciate you pointing out these compliance gaps. I have addressed them immediately:

• Google Cookies Removed: I had already removed the `gtag` script previously so no tracking data was ever sent to Google, but the configuration settings were still lingering in the build. I have completely stripped them out today. No tracking cookies are served now.
• "AI Proctoring" Clarification: I am not tracking or spying on anyone; the project is fully open-source. That term was a misnomer for an upcoming server-side anti-spam mechanism. It is purely designed to detect automated spam responses and malicious direct API/CLI probing (using a custom error code 677).
• Data Access & Privacy: To be absolutely clear, no administrators (sysops), and **not even I as the developer**, can access or view any of the form data. The architecture is built so that the data is completely private—only the user who created the form and the specific people they explicitly grant access to via the settings can view it.
• Privacy Policy: You are completely right about the privacy policy omission; it was an oversight on my part. I am writing and adding a dedicated Privacy Statement to the site today, and I will ensure full compliance with WMF data rules before any official deployment.

I am currently working on these security updates locally and have not pushed the code to GitHub yet. Thank you for helping me make WikiForms compliant with Wikimedia policies! Anaf Ibn Shahibul (talk) 06:57, 14 July 2026 (UTC)

Due to a busy schedule today, I have deployed the initial version now with privacy policy, about, and terms page, but I will thoroughly refine the design and update everything by tomorrow. Anaf Ibn Shahibul (talk) 07:19, 14 July 2026 (UTC)

Please don't generate replies using a chatbot, it can be seen by many as a lack of respect. If you aren't comfortable with English, you can write your replies yourself in Bengali and use a translation tool. Chaotic Enby (in solidarity · talk · contribs) 10:48, 14 July 2026 (UTC)

@Chaotic Enby, Ok I'm sorry, I'll remember it. Anaf Ibn Shahibul (talk) 10:50, 14 July 2026 (UTC)

Thanks a lot. Additionally, despite repeatedly claiming the contrary, this still does not comply with the Terms of Use regarding Toolforge (emphasis mine):

Not collect any other Personal Information and Wikimedia Usernames from End Users, other than any user agent information forwarded by the anonymizing reverse proxy or OAuth provided usernames and email addresses.

Contrast this with your privacy statement:

2. What Data We Collect

• Wikipedia username — via MediaWiki OAuth 2.0 when you log in. We never receive or store your password.

Looking at your GitHub README, I am also puzzled by statements such as this one:

SEO & Analytics Ready: Shipped with out-of-the-box configurations for web crawlers, open-search capabilities, and security metadata.

Your code also shares data (form responses) with third parties (namely, by sending model queries through openrouter.ai), and, if I'm not wrong, seems to store emails and hashed passwords? Chaotic Enby (in solidarity · talk · contribs) 11:07, 14 July 2026 (UTC)

@Chaotic Enby The ToS has a clear-cut exception for OAuth-provided usernames. GrinningIodize (articles without a Wikidata item) (talk) 16:51, 14 July 2026 (UTC)

My bad, I was stuck in the user agent information part and missed that this was a separate clause entirely. Chaotic Enby (in solidarity · talk · contribs) 16:54, 14 July 2026 (UTC)

It's alright, don't worry about it. GrinningIodize (articles without a Wikidata item) (talk) 16:57, 14 July 2026 (UTC)

@GrinningIodize, Thanks for clearing!

@Chaotic Enby, the Analytics is Gtag Cookies, but I already remove that. Thank you. Anaf Ibn Shahibul (talk) 17:12, 14 July 2026 (UTC)

Happy to help! GrinningIodize (articles without a Wikidata item) (talk) 17:13, 14 July 2026 (UTC)

Would it be possible to apply the Codex design system - or at least OOUI - for UI consistency? Right now the squircles are rather overused.

Also, for the "Powered by MediaWiki", I don't quite see how MW is being applied in the repo.

And I would suggest using translatewiki.net for the localization process. ZhaoFJx(Talk) 06:24, 18 July 2026 (UTC)

@ZhaoFJx, Thank you for submitting your feedback!
To be honest I added the "Powered by MediaWiki" badge because it actually looks nice, but I will remove it soon. And of course it's possible to change the style but I'm dealing with security issues and some API issues right now. Once these are finished, I will start working on the design.

Also I don't know about the http://transletwiki.net you mentioned. I will research about it and let you know whether it is possible to bring this feature or not.
Thank you very much!
Anaf Ibn Shahibul (talk) 16:41, 18 July 2026 (UTC)

@ZhaoFJx,
I researched about https://translatewiki.net and tried to add. Unfortunately I was not able to setup https://translatewiki.net successfully due to my lack of knowledge. So a request to the open source community would be for someone to help by adding this to my project if possible.
Thank you.
Anaf Ibn Shahibul (talk) 19:40, 21 July 2026 (UTC)

re What links here

I have two proposals for improving the special:Whatlinkshere page, also available directly from individual pages. This page has three checkboxes:

☐ Hide transclusions

☐ Hide links

☐ Hide redirects

These three checkboxes are all initially unchecked, so that the default behavior is to show all three kinds of links and the user can choose to hide one or two of them.

1. Show instead of hide

   I think it would be more intuitive if the boxes were labeled “show" instead of "hide". To preserve the default behavior, the boxes could all be initially checked like this:

   ☒ Show transclusions

   ☒ Show links

   ☒ Show redirects

2. User preference

   Add a user preference to allow an editor to choose the default checkbox states.

These ideas are independent, either could be implemented without the other. Is there enough interest and merit to pursue either or both? If so, where is the best forum?

— YBG (talk) 12:41, 16 July 2026 (UTC)

I agree that normally having things in the positive is easier than the negative. (in solidarity), JacobTheRox^{(talk|contributions)} 16:16, 19 July 2026 (UTC)

What percentage of users understand WMF?

In a pump discussion at here someone correctly stated that most users do not understand what WMF is. As I stated there, I also think that a very small percentage of internet users understand what WMF is, how it operates and that it attempts not to be involved in content. We should clarify this. I propose that any new user should receive a link to a message explaining this aling with a welcome message, and banners on pages should do so once I a while. If we are here to "provide knowledge" let us start with this. Yesterday, all my dreams... (talk) 16:37, 18 July 2026 (UTC)

There are a lot of things that editors need to learn to be successful on wikipedia, but understanding WMF is probably the least important. Schazjmd (talk) 18:35, 18 July 2026 (UTC)

Yeah, I tend to agree. It ultimately is important but you can go pretty far without knowing about WMF. When an entry-level employee is hired, they don't usually start by reading the bylaws and learning about the corporate structure. Maybe that's a poor comparison, and heck, probably more employees should understand these things. I'm also not sure what it means to understand WMF. Do I understand WMF? I don't know how I would answer that. —Myceteae‍🍄‍🟫 (talk) 17:44, 19 July 2026 (UTC)

They probably mean "understand what the WMF means/is" ~2026-40532-03 (talk) 12:14, 20 July 2026 (UTC)

Well, yes, I understood that. I don't mean to be obtuse here but to understand is a complex concept. There's probably some Dunning-Kruger at play here. I would probably say I understand WMF with less confidence today than I might have five years ago, and certainly 10, even though I understand it more now than I did then. —Myceteae‍🍄‍🟫 (talk) 17:05, 20 July 2026 (UTC)

As an example, I am a fairly inexperienced editor, who has never looked into what WMF is, and I would guess it's the parent organisation of Wikipedia, and wouldn't be certain what else it does other than that.

To me the relevant question is, why would this matter for editing Wikipedia? MaelstromOfSilence (talk) 15:06, 24 July 2026 (UTC)

I agree this is the relevant question, and I agree with Schazjmd that this is pretty far down the list of must-know topics for new editors. —Myceteae‍🍄‍🟫 (talk) 21:05, 26 July 2026 (UTC)

I didn't even know what WMF was referring to until someone said parent organization of Wikipedia. Wikimedia foundation or something, controls all wiki projects like wiktionary and the specieswiki stuff like that. I don't fully understand it though probably.

-- LightningThrower (talk) 21:25, 26 July 2026 (UTC)

The story goes that if people start understanding, it will immediately be replaced with something even more difficult to understand. Rumour has it that this has already happened. Hawkeye7 (discuss) 22:52, 26 July 2026 (UTC)

Yeah, Wikimedia Foundation (WMF) owns and operates Wikipedia and other Wikimedia sister projects such as Wiktionary. On one hand, anything and everything that WMF does, or that is done to WMF, impacts Wikipedia. And as a general matter, I think it's good for folks to know and care about the structure. But on the other hand, one can get very far in contributing to Wikipedia without even knowing WMF exists. The learning curve can be overwhelming and we have so much discussion about editor recruitment, retention, and the experience of new editors; I just don't think it makes sense to pile on. —Myceteae‍🍄‍🟫 (talk) 22:53, 26 July 2026 (UTC)