Wikipedia:Village pump (proposals)
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
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).
- Proposed policy changes belong at Village pump (policy).
- Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
- Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
- Software changes which have consensus should be filed at Phabricator.
Discussions are automatically archived after remaining inactive for nine days.
Transclusion of peer reviews to article talk pages
Hello,
First time posting here.
I would like to propose that peer reviews be automatically transcluded to talk pages in the same way as GAN reviews. This would make them more visible to more editors and better preserve their contents in the article/talk history. They often take a considerable amount of time and effort to complete, and the little note near the top of the talk page is very easy to overlook.
This also might (but only might!) raise awareness of the project and lead to more editors making use of this volunteer resource.
I posted this suggestion on the project talk page yesterday, but I have since realized it has less than 30 followers and gets an average of 0 views per day.
Thanks for your consideration, Patrick (talk) 23:07, 2 January 2025 (UTC)
- I don't see any downsides here. voorts (talk/contributions) 01:55, 4 January 2025 (UTC)
- Support; I agree with Voorts. Noting for transparency that I was neutrally notified of this discussion by Patrick Welsh. —TechnoSquirrel69 (sigh) 21:04, 6 January 2025 (UTC)
- This is a great idea, it's weird that it isn't done already. Toadspike [Talk] 21:13, 6 January 2025 (UTC)
- So far this proposal has only support, both here and at the Peer review talk. Absent objections, is there a place we can request assistance with implementation? I have no idea how to do this. Thanks! --Patrick (talk) 17:23, 13 January 2025 (UTC)
- It might be useful to have a bot transclude the reviews automatically like ChristieBot does for GAN reviews. AnomieBOT already does some maintenance tasks for PR so, Anomie, would this task be a doable addition to its responsibilities? Apart from that, I don't think any other changes need to be made except to selectively hide or display elements on the review pages with
<noinclude>...</noinclude>
or<includeonly>...</includeonly>
tags. —TechnoSquirrel69 (sigh) 17:28, 13 January 2025 (UTC)- Since ChristieBot already does the exact same thing for GAN reviews, it might be easier for Mike Christie to do the same for peer reviews than for me to write AnomieBOT code to do the same thing. If he doesn't want to, then I'll take a look. Anomie⚔ 22:41, 13 January 2025 (UTC)
- I don't have any objection in principle, but I don't think it's anything I could get to soon -- I think it would be months at least. I have a list of things I'd like to do with ChristieBot that I'm already not getting to. Mike Christie (talk - contribs - library) 22:54, 13 January 2025 (UTC)
- I took a look and posted some questions at Wikipedia talk:Peer review. Anomie⚔ 16:14, 18 January 2025 (UTC)
- I don't have any objection in principle, but I don't think it's anything I could get to soon -- I think it would be months at least. I have a list of things I'd like to do with ChristieBot that I'm already not getting to. Mike Christie (talk - contribs - library) 22:54, 13 January 2025 (UTC)
- Since ChristieBot already does the exact same thing for GAN reviews, it might be easier for Mike Christie to do the same for peer reviews than for me to write AnomieBOT code to do the same thing. If he doesn't want to, then I'll take a look. Anomie⚔ 22:41, 13 January 2025 (UTC)
- It might be useful to have a bot transclude the reviews automatically like ChristieBot does for GAN reviews. AnomieBOT already does some maintenance tasks for PR so, Anomie, would this task be a doable addition to its responsibilities? Apart from that, I don't think any other changes need to be made except to selectively hide or display elements on the review pages with
- Support, I've submitted a couple of articles for peer review and wondered when I first did it why it wasn't done on a sub-page of article's talks the same way GAN is. TarnishedPathtalk 02:24, 16 January 2025 (UTC)
Support. This would be very, very helpful for drafts, so discussions can be made in the Talk pages to explain a problem with a draft in more detail rather than only showing the generic reason boxes. Hinothi1 (talk) 12:56, 18 January 2025 (UTC)
Good Article visibility
I think it would be a good idea to workshop a better way to show off our Good, A-class and Featured articles (or even B-class too), and especially in the mobile version, where there is nothing. At present, GA icons appear on the web browser, but this is it. I think we could and should be doing more. Wikipedia is an expansive project where page quality varies considerably, but most casual readers who do not venture onto talk pages will likely not even be aware of the granular class-based grading system. The only visible and meaningful distinction for many readers, especially mobile users, will be those articles with maintenance and cleanup tags, and those without. So we prominently and visibly flag our worst content, but do little to distinguish between our best content and more middling content. This seems like a missed opportunity, and poor publicity for the project. Many readers come to the project and can go away with bad impressions about Wikipedia if they encounter bad or biased content, or if they read something bad about the project, but we are doing less than we could to flag the good. If a reader frequents 9 C-class articles and one Good Article, they may simply go away without even noticing the better content, and conclude that Wikipedia is low quality and rudimentary. By better highlighting our articles that have reached a certain standard, we would actually better raise awareness about A) the work that still needs to be done, and B) the end results of a collaborative editing process. It could even potentially encourage readers who become aware of this distinction to become editors themselves and work on pages that do not carry this distinction when they see them. In this age of AI-augmented misinformation and short-attention spans, better flagging our best content could yield benefits, with little downside. It could also reinject life and vitality into the Good Article process by giving the status more tangible front-end visibility and impact, rather than largely back-end functionality. Maybe this has been suggested before. Maybe I'm barking up the wrong tree. But thoughts? Iskandar323 (talk) 15:09, 11 January 2025 (UTC)
- With the big caveat that I'm very new to the GA system in general and also do not know how much technical labor this would require, this seems like a straightforwardly helpful suggestion. The green + sign on mobile (and/or some additional element) would be a genuinely positive addition to the experience for users - I think a textual element might be better so the average reader understands what the + sign means, but as it stands you're absolutely right, quality is basically impossible to ascertain on mobile for non-experts, even for articles with GA status that would have a status icon on desktop. 19h00s (talk) 16:43, 11 January 2025 (UTC)
- While GA articles have been approved by at least one reviewer, there is no system of quality control for B class articles, and no system to prevent an editor from rating an article they favor as B class in order to promote or advertise it. A class articles are rare, as Military History is the only project I know of that uses that rating. Donald Albury 17:16, 11 January 2025 (UTC)
- I totally agree we should be doing more. There are userscript that change links to different colours based on quality (the one I have set up shows gold links as featured, green as GA, etc).
- If you aren't logged in and on mobile, you'd have no idea an article has had a review. Lee Vilenski (talk • contribs) 20:15, 11 January 2025 (UTC)
- A discussion was held on this about two years ago and there was consensus to do something. See Wikipedia talk:Good Article proposal drive 2023#Proposal 21: Make GA status more prominent in mainspace and Wikipedia:Good Article proposal drive 2023/Feedback#Proposal 21: Make GA status more prominent in mainspace. Thebiguglyalien (talk) 04:20, 12 January 2025 (UTC)
- @Thebiguglyalien: Is that feedback discussion alive, dead, or just lingering in half-life? It's not obviously archived, but has the whole page been mothballed? So basically, there's community consensus to do something, but the implementation is now the sticking point. Iskandar323 (talk) 04:57, 12 January 2025 (UTC)
- Basically, most of the progress made is listed on that feedback page and the project has moved on from it. There were a few options, like the visibility one, where it was agreed upon and then didn't really go anywhere. So there are some ideas there, but we'd basically need to start fresh in terms of implementation. Thebiguglyalien (talk) 05:16, 12 January 2025 (UTC)
- @Thebiguglyalien: Is that feedback discussion alive, dead, or just lingering in half-life? It's not obviously archived, but has the whole page been mothballed? So basically, there's community consensus to do something, but the implementation is now the sticking point. Iskandar323 (talk) 04:57, 12 January 2025 (UTC)
- You're barking up exactly the right tree, Iskandar323. Regarding showing the icons on mobile, that's a technical issue, which is tracked at phab:T75299. I highlighted it to MMiller (WMF) when I last saw him at WCNA, but there's ultimately only so much we can push it.Regarding desktop, we also know the solution there: Move the GA/FA topicons directly next to the article name, as was proposed in 2021. The barrier there is more achieving consensus — my reading of that discussion is that, while it came close, the determining factor of why it didn't ultimately pass is that some portion of editors believed (wrongly, in my view) that most readers notice/know what the GA/FA symbols mean. The best counterargument to that would be some basic user research, and while ideally that would come from the WMF, anyone could try it themselves by showing a bunch of non-Wikipedian friends GAs/FAs and asking if they notice the symbols and know what they mean. Once we have that, the next step would be running another RfC that'd hopefully have a better chance of passing. Sdkb talk 06:50, 12 January 2025 (UTC)
- It's great that I've got the right tree, since I think that's a village pump first for me. It seems that the proposer of that original 2021 discussion already did some basic research. Intuitively, it also seems just obvious that an icon tucked away in the corner, often alongside the padlocks indicating permission restrictions, is not a high visibility location. Another good piece of final feedback in the GA project discussion mentioned earlier up this thread by TBUA is that the tooltip could also been improved, and say something more substantial and explanatory than simply "this is a good article". On the subject of the mobile version and the level of priority we should be assigning to it, we already know that per WP:MOBILE, 65% of users access the platform via mobile, which assuming a roughly even spread of editors and non-editors, implies that 2/3 of contemporary casual visitors to the site likely have no idea about the page rating system. Iskandar323 (talk) 07:31, 12 January 2025 (UTC)
my reading of that discussion is that, while it came close, the determining factor of why it didn't ultimately pass is that some portion of editors believed (wrongly, in my view) that most readers notice/know what the GA/FA symbols mean
This is not my reading of the discussion. To me it looks as though a major concern among opposers is that making GA/FA status more prominent for readers is likely to mislead them, either by making them think that GAs/FAs are uniformly high-quality even for those which were assessed many years ago when our standards were lower and have neither been maintained or reassessed, or by making them more doubtful about the quality of articles which have never gone through the GA/FA process but are nonetheless high quality. By my count at least ten of the 15 oppose !voters cite this reason either explicitly or "per X" where X is someone else who had made this point. Caeciliusinhorto (talk) 16:18, 12 January 2025 (UTC)- I've also encountered a fair few instances of older, lower standard GA articles. But I also think greater visibility (effectively also transparency) could also benefit in that area as well. If GA status is more prominent, it provides greater cause to review and reassess older GAs for possible quality issues. Also, most of the worst GAs I have seen have come from around 2007, so it seems like one sensible solution would be for GA status to come with a sunset clause whereby a GA review is automatically required after a decade. Maybe I'm getting a little sidetracked there, but this sort of concern is also exactly what I mean by greater visibility potentially reinjecting life and vitality into the process. Iskandar323 (talk) 17:15, 12 January 2025 (UTC)
- I think you're right about that being the most major source of opposition, but most major is different than determining — I don't think those !voters will be open to persuasion unless the quality of GAs/FAs improves (which, to be fair, it definitely has somewhat since 2021). But the "they already know" !voters might be more persuadable swing !voters, and it would have passed with their support. Sdkb talk 19:02, 12 January 2025 (UTC)
- @Sdkb: So, is there any way to poke the mobile issue a little harder with a stick? And do you think it is worth re-running the 2021 proposal or a version of it? What format should such a discussion take? Is there a formal template for making a proposal more RFC-like? Iskandar323 (talk) 12:59, 20 January 2025 (UTC)
- I think that's a fair reading of the discussion. But, I suppose the best way to be more transparent is to tell a user that it has been rated GA after a peer review, but that doesn't mean that the article is perfect... Which is what GA (and FAs) also say. Lee Vilenski (talk • contribs) 19:54, 12 January 2025 (UTC)
- My radical proposal would be to get rid of the whole WP:GA system (which always came across to me as a watered-down version of WP:FA). Some1 (talk) 16:31, 12 January 2025 (UTC)
- Why? TompaDompa (talk) 16:38, 12 January 2025 (UTC)
- It is a watered-down process from an FA, but it is also the first rung on the ladder for some form of peer-review and a basic indicator of quality. Not every subject has the quality sources, let alone a volunteer dedicated enough, to take it straight from B-class to Featured Article. Iskandar323 (talk) 17:17, 12 January 2025 (UTC)
- That's literally the point of it. Lee Vilenski (talk • contribs) 19:52, 12 January 2025 (UTC)
RSS feed for Portal:Current events
An admin suggested that I make this a proposal here so here it is:
Unlike other Main page sections such as On this day (RSS) or Featured article (RSS), daily entries from Portal:Current events do not yet have an RSS feed. This has been requested several times on the Portal's talk page over the years, but never gained traction: 2006, 2010, 2013, 2020.
Adding a feed via MediaWiki's FeaturedFeeds extension should be relatively straightforward (for an admin with access to extension settings):
- Create the feed page under MediaWiki:Ffeed-currentevents-page ("currentevents" would be the feed's name). Requires admin access.
- Add the following as the page's source:
Portal:Current events/{{#time:Y F j|-1 day}}
(This should set yesterday's current events to today's feed entry.) - Configure the new feed in Wikipedia's FeaturedFeeds settings (adapting from extsting settings from other existing feeds like On this day). I'm not sure exactly what access is required here, or whether this can only be done by a WMF staff member.
I may be biased, but I don't see any good reason not to provide Current events as an RSS feed: it simply gives users another way to access this fantastic content using their favorite feed reader. Thoughts? Robinmetral (talk) 08:09, 12 January 2025 (UTC)
- Makes a lot of sense to me. Feels like it should be doable but phab:T160561 gives me pause. I would drop a link here at WP:VPT to get some technical eyes on this that can make sense of exactly how to implement. Trialpears (talk) 01:56, 14 January 2025 (UTC)
- Thank you for the ref to phab:T160561! I agree that it might make more sense to move this over to WP:VPT by now, since there doesn't seem to be anyone opposing this in principle. I just reached out on the ticket thread to see if anyone involved in this at the time still remembers what happened. If there doesn't seem to be any technical blockers, I'll move this proposal to WPT to hopefully find someone who can implement it. Robinmetral (talk) 04:03, 14 January 2025 (UTC)
Update image of Template:Template category
Proposal to update image used in Template:Template category:
Currently it looks like this:
The pages listed in this category are templates.
This page is part of Wikipedia's administration and not part of the encyclopedia.
Further template category notes
This category contains pages in the template namespace. It should not be used to categorize articles or pages in other namespaces. To add a template to this category:
|
I propose we change the image to:
The pages listed in this category are templates.
This page is part of Wikipedia's administration and not part of the encyclopedia.
Further template category notes
This category contains pages in the template namespace. It should not be used to categorize articles or pages in other namespaces. To add a template to this category:
|
-- waddie96 ★ (talk) 22:26, 13 January 2025 (UTC)
- This is too big a venue for this discussion. In any case, I don't think it's an improvement — better to keep it simple. Sdkb talk 03:06, 14 January 2025 (UTC)
Replace abbreviated forms of Template:Use mdy dates with full name
I propose that most[a] transclusions of redirects to {{Use mdy dates}} and {{Use dmy dates}} be replaced by bots with the full template name.
Part of the purpose of {{Use mdy dates}} is to indicate to editors what they should do. Thus, readability is important. I propose all of these redirects be replaced with their target which is:
- More easily understood even the first time you see it.
- Standardized, and thus easier to quickly scan and read.
The specific existing redirects that I suggest replacing are:
- {{Mdy}} → {{Use mdy dates}}
- {{MDY}} → {{Use mdy dates}}
- {{Usemdy}} → {{Use mdy dates}}
- {{Usemdydates}} → {{Use mdy dates}}
- {{Use MDY}} → {{Use mdy dates}}
- {{Use mdy}} → {{Use mdy dates}}
- {{Dmy}} → {{Use dmy dates}}
- {{DMY}} → {{Use dmy dates}}
- {{Usedmy}} → {{Use dmy dates}}
- {{Use dmy}} → {{Use dmy dates}}
- {{Use DMY}} → {{Use dmy dates}}
- {{Usedmydates}} → {{Use dmy dates}}
- ^ I would probably leave alone the redirects that differ only in case, namely {{Use MDY dates}} and {{Use DMY dates}}, which are sufficiently readable for my concerns.
Daask (talk) 20:30, 18 January 2025 (UTC)
- In principle I like this idea (noting my suggestion to bring it here). My only concern would be about watchlist spam, given that, while this may not technically be a cosmetic edit, it's only a hair above one. But there's only a few thousand transclusions of these redirects, so if the bot goes at a rate of, say, one per minute, it'd be done in a few days. -- Tamzin[cetacean needed] (they|xe|🤷) 21:09, 18 January 2025 (UTC)
- It looks like most or all of these are already listed at Wikipedia:AutoWikiBrowser/Template redirects, so whenever anyone edits an article with AWB, they'll already be replaced. No strong view about doing so preemptively.
- However, if our goal is to ensure that these templates are actually meaningfully used, then we have some bigger fish to fry. First of all, even the written-out form isn't sufficiently readable/noticeable — many newcomers may not know what it means, and many experienced editors may miss it if they aren't happening to look at the top of the article. Ideally, we would either offer to correct the date format if anyone enters the incorrect one via mw:Edit check (task) or we'd include it in an editnotice of some sort.
- Second of all, roughly 2/3 of all articles still don't have a date tag, so we need to figure out better strategies for tagging en masse. There are surely some definable groups of articles that are best suited to a particular format (e.g. all U.S. municipality articles I'd think would want to use MDY) that we could agree on and then bulk tag. Sdkb talk 21:50, 18 January 2025 (UTC)
Ideally, we would either offer to correct the date format if anyone enters the incorrect one via mw:Edit check (task) or we'd include it in an editnotice of some sort.
This could also feasibly be done with a regex edit filter, which is better than Edit check in that specific case as the latter doesn't work with the source editor as far as I know. Chaotic Enby (talk · contribs) 07:01, 20 January 2025 (UTC)- However it's done technically, it will need human supervision as some instances shouldn't be change, e.g. in quotes and the titles of sources. Thryduulf (talk) 07:08, 20 January 2025 (UTC)
- A filter could only flag an issue, not fix it. And any time a user gets a warning screen when they click "publish", there is a significant chance they will abandon their edit out of confusion or frustration, so we should not be doing that for a relatively minor issue like date format. -- Tamzin[cetacean needed] (they|xe|🤷) 07:11, 20 January 2025 (UTC)
- I do believe that just flagging it would be better than giving an explicit warning (that might scare the user) or automatically fixing it (which, like Thryduulf mentioned, might not be optimal for direct quotes and the likes). Chaotic Enby (talk · contribs) 07:17, 20 January 2025 (UTC)
- Concur with Tamzin — the main point of Edit Check is to introduce an option to alert an editor of something without requiring a post-edit warning screen, which is all edit filters can do. The ideal form would be a combo of a flag and an automatic fix — for instance, dates not detected to be within quotes would be highlighted, clicking on it would say "this article uses the MDY date format; would you like to switch to that? learn more convert". Sdkb talk 16:38, 20 January 2025 (UTC)
- I do believe that just flagging it would be better than giving an explicit warning (that might scare the user) or automatically fixing it (which, like Thryduulf mentioned, might not be optimal for direct quotes and the likes). Chaotic Enby (talk · contribs) 07:17, 20 January 2025 (UTC)
- It's definitely a cosmetic edit, in that it only changes the wikitext without changing anything readers see. But consensus can decide that any particular cosmetic edit should be done by bots. As proposed, there are currently 2089 transclusions of these redirects, 1983 in mainspace. Anomie⚔ 14:21, 19 January 2025 (UTC)
Forbid Moving an Article During AFD
There is currently a contentious Deletion Review, at Wikipedia:Deletion_review/Log/2025_January_19#Raegan Revord, about an article about a child actress, Raegan Revord. Some editors think that she is not biographically notable, and some editors think that she is biographically notable. There is nothing unusual about such a disagreement; that is why we have AFD to resolve the issue. What happened is that there were a draft version of her biography and a mainspace version of her biography, and that they were swapped while the AFD was in progress. Then User:Liz reviewed the AFD to attempt to close it, and concluded that it could not be closed properly, because the statements were about two different versions of the article. So Liz performed a procedural close, and said that another editor could initiate a new AFD, so that everyone could be reviewing the same article.
This post is not about that particular controversy, but about a simple change that could have avoided the controversy. The instructions on the banner template for MFD are more complete than those on the banner template for AFD. The AFD template says:
Feel free to improve the article, but do not remove this notice before the discussion is closed.
The MFD template says:
You are welcome to edit this page, but please do not blank, merge, or move it, or remove this notice, while the discussion is in progress.
Why don't we change the banner template on an article that has been nominated for deletion to say not to blank, merge, or move it until the discussion is closed? If the article should be blanked, redirected, merged, or moved, those are valid closes that should be discussed and resolved by the closer. As we have seen, if the move is done in good faith, which it clearly was, it confuses the closer, and it did that. I have also seen articles that were nominated for deletion moved in bad faith to interfere with the deletion discussion.
I made the suggestion maybe two or three years ago to add these instructions to the AFD banner, and was advised that it wasn't necessary. I didn't understand the reason then, but accepted that I was in the minority at the time. I think that this incident illustrates how this simple change would prevent such situations. Robert McClenon (talk) 06:06, 20 January 2025 (UTC)
- Seems like a reasonable proposal. Something similar occurred at Wikipedia:Articles for deletion/2025 TikTok refugee crisis. AfD was initiated, then the article was renamed, an admin had to move it back, and now it has been renamed again while the AfD is still ongoing. Some1 (talk) 06:32, 20 January 2025 (UTC)
- Thank you for the information, User:Some1. Both my example and yours are good-faith, but taking unilateral bold action while a community process is running confuses the community. I have also, more than once, seen bad-faith moves of articles during AFD. An editor who is probably a COI editor creates an article that is poorly sourced or promotional. A reviewer draftifies it. The originator moves it back to draft space. Another reviewer nominates it for deletipn, which is the proper next stop after contested draftification. The originator then moves it back to draft space so that the AFD will be stopped. Sometimes an admin reverses the move, but sometimes this stops the discussion and leaves the page in draft space. I think that any renaming should be considered within the AFD. Robert McClenon (talk) 06:52, 20 January 2025 (UTC)
- "Renaming" and "draftifying" may be technically the same operation, but they are quite different things. I don't mind outlawing draftify during AFD, as it pre-empts the outcome, but fixing a nontrivial typo or removing a BLP-noncompliant nickname from a page title should be done immediately by anyone who notices the problem, independent of whether the page is at AFD or not. —Kusma (talk) 09:15, 20 January 2025 (UTC)
- Thank you for the information, User:Some1. Both my example and yours are good-faith, but taking unilateral bold action while a community process is running confuses the community. I have also, more than once, seen bad-faith moves of articles during AFD. An editor who is probably a COI editor creates an article that is poorly sourced or promotional. A reviewer draftifies it. The originator moves it back to draft space. Another reviewer nominates it for deletipn, which is the proper next stop after contested draftification. The originator then moves it back to draft space so that the AFD will be stopped. Sometimes an admin reverses the move, but sometimes this stops the discussion and leaves the page in draft space. I think that any renaming should be considered within the AFD. Robert McClenon (talk) 06:52, 20 January 2025 (UTC)
- Oppose. Improving an article during AfD is encouraged and we must resist anything that would make it harder. Following the proposal would have meant a cut and paste move/merges would have had to happen in order to use the existing draft, making the situation more difficult to understand than a clear page swap. —Kusma (talk) 06:49, 20 January 2025 (UTC)
- Support, the AfD deals with notability, and moving can impact the scope and thus the notability. In that specific case, during the AfD, sources from both could've been considered, as AfD is about the sources that exist rather than the current content of the article. Not sure how a merge would've made it
more difficult to understand
than what actually happened. Chaotic Enby (talk · contribs) 06:55, 20 January 2025 (UTC)- It would have hidden the actual revision history for no benefit whatsoever. —Kusma (talk) 07:25, 20 January 2025 (UTC)
- When merging, the other article's history should be linked in the edit summary for attribution anyway. The benefit of avoiding the massive confusion for the closer (and the later deletion review) far outweighs the need for a few more clicks to find the history. Chaotic Enby (talk · contribs) 07:41, 20 January 2025 (UTC)
- If people are discussing version A before 13 January and version B after 13 January, this may result in confusion for the closer. But the confusion arises from people discussing two different versions of the article. I am all for clearly stating in the AFD when anything like moving or merging has happened, but outlawing moves is not solving the unsolvable problem that articles can change during an AFD. —Kusma (talk) 09:11, 20 January 2025 (UTC)
- When merging, the other article's history should be linked in the edit summary for attribution anyway. The benefit of avoiding the massive confusion for the closer (and the later deletion review) far outweighs the need for a few more clicks to find the history. Chaotic Enby (talk · contribs) 07:41, 20 January 2025 (UTC)
- It would have hidden the actual revision history for no benefit whatsoever. —Kusma (talk) 07:25, 20 January 2025 (UTC)
- Inclined to support as a draft swap seems rare, and seems somewhat at odds with the stated principle that AfD is about notability, which would not differ between a mainspace article and a draft article. In situations when there is a draft, the AfD could come to consensus to use the draft, or to keep on the topic and the draft can be moved in post-AfD. That said, regarding blanking, I have seen articles at least partially blanked due to BLP or copyright concerns. Those seem correct actions to take even during an AfD, and I suspect other instances of blanking are rare enough, and likely to be reverted if disruptive. CMD (talk) 09:31, 20 January 2025 (UTC)
- Weak oppose forbidding the kind of move made here. We encourage improving an article during the AFD, and separately it is often said during AFDs that an article should be TNT'ed and started over. Replacing the article with a new version, whether through moving a draft or simply rewriting it in place, is a valid (if hamhanded) attempt to do both of those things to save an article from deletion. Support forbidding moving the article to a new title with no content changes, as that could be disruptive (you'd have to move the AFD for one, and what if it gets reverted?). Pinguinn 🐧 10:57, 20 January 2025 (UTC)
- You do not have to move the AFD (and you should not, it is unnecessary and causes extra work). All you need is to make a note on the AFD what the new page title is. Of course you should almost never suppress the redirect while moving a page that is at AFD. —Kusma (talk) 14:06, 20 January 2025 (UTC)
- @Robert McClenon Look at the timeline again, in the Revord case it did not happen while the AFD was in progress. The swapping happened while the afd was closed keep. The afd was then reopened. Gråbergs Gråa Sång (talk) 10:58, 20 January 2025 (UTC)
- I can see the benefit of forbidding moving between namespaces, but this proposal would also catch simple renames. I've seen plenty of deletion discussions for articles with simple typos or spacing errors in their titles, where the nominating user has not corrected things before nominating. We should not forbid moving them to the correct title. Phil Bridger (talk) 13:49, 20 January 2025 (UTC)
- Simple renames (to fix typos, etc.) should be okay, but moving an article, for example, from Biden crisis (AfD on July 19) to Withdrawal of Joe Biden from the 2024 United States presidential election (moved July 21) (which also changed the scope of the article) while the AfD is still in progress should not IMO. Some1 (talk) 14:58, 20 January 2025 (UTC)
- I agree, which is why this should be left to human judgement and consensus rather than forbidding things. Phil Bridger (talk) 18:33, 20 January 2025 (UTC)
- Simple renames (to fix typos, etc.) should be okay, but moving an article, for example, from Biden crisis (AfD on July 19) to Withdrawal of Joe Biden from the 2024 United States presidential election (moved July 21) (which also changed the scope of the article) while the AfD is still in progress should not IMO. Some1 (talk) 14:58, 20 January 2025 (UTC)
- I don't see the benefit of retaining poorly worded article titles for seven days or more. I'd support against moving namespaces during an AfD, but not all renaming.
- This could actually cause an issue if someone was to move an article to a title that someone else wants to move an article to (in case of an obvious PRIMARY TOPIC/Dab change). Lee Vilenski (talk • contribs) 14:57, 20 January 2025 (UTC)
- Oppose There are some rare cases this is a problem, but I have seen many/most cases it is helpful. In the given example, let's say the move was disallowed and the article was deleted. Now wait a few weeks and make the article again with the new content. People will complain no matter what. You've got to be reasonable. If there was a major effort to redo the article it should be discussed during the AfD. -- GreenC 18:27, 20 January 2025 (UTC)
- Based on the comments above I think the best we can get will be a policy that requires any change of title be clearly and explicitly noted in an AfD, supplemented by a guideline that discourages controversial and potentially controversial changes in title while discussion is ongoing. Any change that would alter the scope of the article or which has been rejected by discussion participants (or rejected previously) is potentially controversial. On the other hand, a suggested change that has significant support and no significant objection among discussion participants is usually going to be uncontroversial. Thryduulf (talk) 19:02, 20 January 2025 (UTC)