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)

• B As an idea to attract and engage new editors, I think this is a well-intentioned but flawed idea. You're asking them to go from front page to problematic article to somehow discerning what is currently wrong with it editing it to producing an end result that is better and conforms to all Wikipedia policies and practices. I think that's a recipe for disaster, both in terms of the damage done to articles that already need improvement and the discouragement of new editors who feel slapped down as soon as they try to answer a call for help. Note that some of those "articles for improvement" are already B-class. The improvements they need are likely to be beyond the scope of an untrained beginner. I think it would be more useful to have a section explicitly calling for new editors and showing them the first steps they should take in order to become editors here, The Wikipedia Adventure for example, and from there to editing a subject that interests them and which they know about, rather than whatever random article "needs improvement" today Chuntuk (talk) 14:37, 28 July 2026 (UTC)

  M1 and M3 both have a list of things that need to be improved in the article, and if any editor needs more specific instructions, they could ask the volunteers who promised to be there (see replies). Also, I personally support making TwAfI C-class or lower. 7amiþ reform · 💬 · 📊 15:27, 28 July 2026 (UTC)

  If I'm a new editor, how do I know where to get help? If you're one of the volunteers, how do you know I need it? Chuntuk (talk) 19:22, 28 July 2026 (UTC)

  how do I know where to get help? – You will notice that all three mockups state that questions can be asked either at the teahouse or the talk page, with links. Additionally the RFC states Guidance and suggestions will also be given when editing via an edit notice, how to get help falls under guidance.

  how do you know I need it? – Volunteers will be monitoring and evaluating edits to the article and its talk page. The Teahouse is already monitored by volunteers assisting newcomers. fifteen thousand two hundred twenty four (talk) 19:49, 28 July 2026 (UTC)

• B; I admire the intention behind this idea in regards to attracting new editors but I just don’t see it being that effective. People without edting experience aren’t going to decide to randomly edit a topic they may have no interest in; since they don’t have Wikipedia-editor-brain yet they will be less likely to notice things they want to change in the article. Even if they do, there’s no guarantee that the edits they’ll make won’t simply be reverted due to their lack of experience, potentially putting them off editing for good. Mir Novov (contribs | talk) 15:57, 28 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)

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: [2] [3] [4] [5]), 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 28 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)

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)

FFAC/FAC

I recently got the FFL star changed to make the FA stars consistent, In order to have consistency throughout all the FA stars, can we also change the FFAC/FFLC and FAC/FLC images to and respectively? I uploaded these two years ago but never proposed actually adding them. splains (💬/📝) 23:30, 27 July 2026 (UTC)