Wikipedia talk:WikiProject Articles for creation

Main pageTalk pageSubmissions
Category, Sorting, FeedShowcaseParticipants
Apply, By subjectReviewing instructions
Help deskBacklog
drives
Aug 2026

Welcome—discuss matters concerning this project!

AfC submissions Random submission

3+ months

4,334 pending submissions

• Are you in the right place?
  • If you want to ask a question about your draft submission, use the AfC Help desk.
  • For questions on how to use or edit Wikipedia, use the Teahouse.
  • Create an article using Article wizard or request an article at requested articles.
• Put new text under old text. Start a new topic.
• In addition to this page, you can give feedback about the AFCH helper script by creating a new ticket on GitHub.
• New to Wikipedia? Welcome! Ask questions, get answers.

AfC unreviewed draft statistics as of July 27, 2026

New field for AI use disclosure at AfC Submit Wizard?

I've been thinking of how the AfC Submit Wizard could use additional field(s) to help submitters disclose their AI usage.

It would only help honest people be honest, but I think it would improve our understanding of how (new) editors use AI and help reviewer feedback be more specific than what we have currently.

I've drafted potential questions at Wikipedia:WikiProject Articles for creation/Submission wizard/AI use disclosure. I'm interested to see if this is a viable idea. Ca ^{talk to me!} 10:27, 1 July 2026 (UTC)

Thanks! I think this is worth a try. Newystats (talk) 12:11, 1 July 2026 (UTC)

I really like this idea! I suggest limiting to a single key question though, whatever the reviewer needs the most - in this case, just the first question. In general, fewer questions increases the chances that people will fill something out. Dreamyshade (talk) 23:12, 3 July 2026 (UTC)

I agree with knocking a question off or two. However, I don't think keeping only the first is a good idea. From my experience, most editors, when asked about their AI use, claim they used only used AI for copyediting or formatting when its clearly untrue. The latter two question are more evidence-based, rather than self-report-based. Ca ^{talk to me!} 13:48, 7 July 2026 (UTC)

I've reduced the number of question to just one. 👍 Ca ^{talk to me!} 10:54, 13 July 2026 (UTC)

mmm, the results would probably be useful, but it might give people the wrong impression that LLM use is allowed, and I'm not really comfortable w using newbies as guinea pigs like that. Idk if there's a way to address that? Kowal2701 (talk, contribs) 20:53, 4 July 2026 (UTC)

The WP:Article Wizard already informs participants that LLM generation is disallowed, so I'm not too worried about giving the wrong impression. Technically, AI use for "basic copyedits and translation" is currently allowed, so I tried to orient the example answers to follow that limitation.

I agree we shouldn't conduct systematic research with the disclosures without them being informed about it, but that wouldn't be its primary goal. I think its main use case would help reviewers distinguish between cases where drafts were wholly AI-generated and cases where it was just simply rewritten with AI. Both are disallowed by policy, but one is salvageable and one is not, helping reviewers provide more specific feedback.

I'd also add that frequent exposure to known AI-generated text has been shown to improve AI-detection abilities. Ca ^{talk to me!} 13:44, 7 July 2026 (UTC)

that sounds good then! Kowal2701 (talk, contribs) 21:46, 14 July 2026 (UTC)

Ready for implementation?

Tracked in github.com
Issue #10

Submission Wizard screenshot with additional AI disclosure field

Based on on- and off-wiki feedback (much appreciated), I've...

• reduced the question count from three to one
• replaced the request for prompts with one for transcripts (more comprehensive)
• and restyled the field to match rest of the wizard

I'm wondering if the community believes the current proposed field is ready for implementation. Ca ^{talk to me!} 09:32, 22 July 2026 (UTC)

Great! I support it. I'd just move "If you used another AI tool like Grammarly or Google Translate, or no longer have the transcript, simply describe how you used AI." before the input field instead of after, since it helps people understand what to put into the input field. Dreamyshade (talk) 09:55, 22 July 2026 (UTC)

Good idea— Done Ca ^{talk to me!} 02:56, 23 July 2026 (UTC)

This looks good to me! In solidarity, nil ^nz 03:59, 23 July 2026 (UTC)

I've opened a pull request on Github. Ca ^{talk to me!} 13:15, 25 July 2026 (UTC)

@SD0001, since you appear to be the maintainer, would you be interested, at your own leisure, in reviewing the PR? I think it would be worth trialing the new disclosure during the August backlog drive. Ca ^{talk to me!} 13:42, 31 July 2026 (UTC)

Notifying expired TAs

I just declined Draft:The Kinetic Group (TKG), which had been sitting in the pool for over 3 months. It was most recently submitted by a TA, who hasn't edited since, and whose account recently expired. The notification went to their talk page, but I guess they'll never find out, since their account is no longer active, and if they come back and continue editing they'll get assigned a new TA. (The same could also arise even with TAs that aren't yet expired, but expire before the user next comes back.) I don't think this is a major problem, and in any case I'm not sure what we can do about it, just thought I'd mention. -- DoubleGrazing (talk) 09:07, 2 July 2026 (UTC)

Yeah, not really sure there's much for us to do, it is the same as someone with a dynamic IP submitting in the old days, if their draft was declined but they were on a new IP, they'd need to still visit the old talk to deal with it. Primefac (talk) 10:20, 2 July 2026 (UTC)

Rejecting drafts based on sourcing

If you are going to rejectdecline a draft for lack of SIGCOV or other problems with sourcing, then try to explain what is wrong, or mention which sources are problematic. I came across this draft Draft:Tunji Olowolafe. It has been reviewed (and rejecteddeclined) twice. It has been submitted again. If editors are just gonna rejectdecline it without a proper explanation, then it will keep getting submitted over and over again, clogging up the AfC queue (which is at over 4000 as of this writing).

@Gheus rejectdeclined it with an explanation of "See WP:NEWSORGNIGERIA." That is a misuse of the guideline. NEWSORGNIGERIA doesn't say that no sources from Nigeria can be used, it says many Nigerian news media outlets and Nigerian newspaper coverage should be considered with caution when assessing notability, particularly for biographies. I don't see any "consideration with caution", I see a blanket rejectiondecline of the draft just because the sources are Nigerian.

@ArthurTheGardener just rejecteddeclined the draft without explanation. Presumably because the sources are Nigerian.

If you can't be bothered to go through the sources, then just skip the draft and go to the next one. At least take a look at few of the sources. If a source is WP:PROMO you can remove it from the Draft. Drafts aren't owned by the creators, but they "belong" to everyone and anyone can edit them.

Is AfC really a place where we simply accept/reject/decline articles? Why not edit it a bit and see if you can get it to a state that it can be published. Again, there are over 4000 Drafts in the AfC queue. Last time I was active at AfC (months ago), the queue was always around 2000 Drafts. If editors just keep rejectingdeclining the drafts with poor reasoning, not improving the draft, the queue will just grow.

Regarding the draft I mentioned, Draft:Tunji Olowolafe. Yes, some sources are WP:PROMO, but I also see some decent ones, like Vanguard (Nigeria), The Punch, and The Guardian (Nigeria). The subject of the article has been appointed Chancellor of Ekiti State University, as confirmed by the universities website. After spending 10 minutes researching (clicking links), this person seems notable. TurboSuperA+_[talk] 12:03, 3 July 2026 (UTC) edited 12:47, 3 July 2026 (UTC)

Correction: the draft was declined twice, not rejected. Kovcszaln6 (talk) 12:21, 3 July 2026 (UTC)

Thanks, fixed. I'm going to leave the section title as-is so I don't mess up the links. TurboSuperA+_[talk] 12:48, 3 July 2026 (UTC)

(FYI, {{Anchor}} can solve the section title-link issue.) —ClaudineChionh (she/her · talk · email) 03:13, 4 July 2026 (UTC)

I don't think the subject line matters much. The point is communicated well enough in the text of the original post with corrections. ✶Quxyz✶ (talk) 03:19, 4 July 2026 (UTC)

Yes, in an ideal world, the reviewer would decline, and add a meaningful explanatory comment to the canned decline template, or go to the author's talk page to do the same. The author would then carefully read and consider the explanation, study the P&G the template links to, and gain a good understanding of the issues involved, enabling them to improve the draft in all relevant aspects before resubmitting.

It has also been known to happen (!) that the author doesn't even look at the decline template and comments, just does their own thing, and resubmits. Or just resubmits. Or doesn't even realise there are comments and decline reasons provided, and comes to the help desk, or the Teahouse, or goes to the reviewer's talk page, or someone else's talk page, or some off-wiki channel, or asks AI, or any combination of the above.

(One could be forgiven for developing a degree of cynicism after a while.)

I for one often – not nearly always, but probably more often than not – provide some comment in addition to declining, eg. if I pick the company/organisation notability template, I might add something like "Primary sources and routine business reporting do not establish notability per WP:NCORP." Or if I'm declining for insufficient reliable sources, I would probably point out which of the sources cited are non-RS, and why. At other times, such as with non-English or AI content, I would probably just use that template and not add anything. Don't ask me where my boundary between adding a comment vs. not lies; it's somewhat fuzzy and loose.

I don't know if, and to what extent, declining without commenting is responsible for our nearly 5K pending drafts. It could conceivably be the other way around: if every reviewer took extra time to write comments with each review, they would spend more time with the review and therefore get through fewer reviews in any given time. Either way, I'm not sure there's a clear causality there, but happy to have this pointed out. -- DoubleGrazing (talk) 13:08, 3 July 2026 (UTC)

The reviewer could remove all the non-RS and PROMO sources, including the claims they are cited for. It wouldn't take long and it would be a huge help, both to the editor submitting the Draft and any subsequent reviewers. TurboSuperA+_[talk] 13:28, 3 July 2026 (UTC)

Attempting to remove all the spam and promo from every AfC submission would be a full time job for a team of five. ScalarFactor (talk) 14:04, 3 July 2026 (UTC)

You don't have to remove all of it, just some of it. Two editors looked at the Draft linked above. If each of them removed 2-3 sources, the third reviewer (in this case me) would have a much easier time of removing a few others. Then perhaps the fourth reviewer could get the rest. This is a collaborative project and nobody expects one editor to do everything. But as it stands now, it looks like the Draft will just keep getting kicked down the road until one editor takes it upon themselves and fixes it all. Why not make it easier for that one last editor? TurboSuperA+_[talk] 14:16, 3 July 2026 (UTC)

I have a concern that is not necessarily based on the time the reviewer spends editing; the time the creator/authors spend editing. If theoretically (because they don't understand RS) every sentence is unsourced, and we blank the entire draft, but every sentence could be properly sourced, we've just forced the creator/author to re-write the entire draft instead of just plonking in some references. The aggregate is that no one's time is well-spent.

Don't get me wrong, I understand where you're coming from, but I'm only going to remove chunks of a page if it will then result in the page being acceptable (e.g. there's an entire "personal life" section that's unsourced but the rest demonstrates notability). Primefac (talk) 14:28, 3 July 2026 (UTC)

That's a good point. I guess that's also something to keep in mind, what the claim is. If it is something not extraordinary, then a better source can be found (and it can be tagged that way). There's also the consideration that certain sources (like SPS) can be used for some claims, but do not add to notability.

There's also cases where the whole Draft is LLM-generated or there isn't any chance of notability, and those can be promptly declined/rejected. But in cases where there is a possibility that the subject is notable, I think we can agree that declining without providing any explanation or tips for the editor on how they can improve the Draft is not helpful. TurboSuperA+_[talk] 14:46, 3 July 2026 (UTC)

Yes, my personal philosophy is, unless the decline reason is very obvious, to always leave a comment. Since there are times where they genuinely aren't needed, though, we can't really mandate it. Primefac (talk) 14:56, 3 July 2026 (UTC)

I agree that many reviews are less than ideal in failing to give more tailored comments etc., but after the first few years I came to feel that a large number of submitters just ignored/didn't read, any advice in review comments. I decided to save my time by not writing longer explanations on reviews and put the effort into detailed answers when interested submitters asked for help on my talk page. So although I started off thinking the same as you, I came to feel as though it was, unfortunately, often just a waste of time. However it does depend on if the chosen decline notice(s) gives enough of a pointer to the issues, and a short comment is often going to be helpful.

You say reviewers should improve any issues for others and called yourself the third reviewer but have not made any edits or comments. You said After spending 10 minutes researching (clicking links), this person seems notable but did not accept it or leave a comment pointing to which key sources you believe showed notability. You should follow your own advice if you expect others too. I also think you are assuming to much of the two reviewers intent. Gheus did not say "no sources from Nigeria can be used" as you interpreted, I would AGF and they meant that they thought some of the sources failed for that reason but just failed to be clear. Also I think presuming that ArthurTheGardener declined just because the sources are Nigerian is just pure assumption. KylieTastic (talk) 16:26, 3 July 2026 (UTC)

I didn't make any changes because I used the Draft as an example, so wanted editors to see it. Also, it takes me some time to go through a Draft. Most of the declined Drafts got deleted, but here are some to show the kind of comments I leave: Draft:Doobie_Duke_Sims, Draft:Otabek_Mahkamov_(politician), Draft:Priyam_Archi. If there is a mix of RS/non-RS, I'll do a detailed breakdown. And usually editors find that helpful; if you check some of the declined Drafts in my AfC log, you will see that they were accepted. A new editor submitting a Draft has a much better chance of getting it accepted if they know exactly what to fix.

I'm not saying we need to, or should, do that for every Draft, but the one linked in OP was salvageable, cause there are some RSes. I also checked the articles themselves and they seem real, i.e. not paid promotion.

I'm just saying that a long Reference list may seem daunting (it did to me), but if every reviewer does a little bit, like the squirrel, we might get an Article out of it and start clearing the queue. TurboSuperA+_[talk] 16:54, 3 July 2026 (UTC)

I don't know if that's quite what you mean, but we've discussed before reviewers doing partial reviews where they can, eg. someone who can read Korean-language sources doing those, while another reviewer with a good grasp of WP:MEDRS could handle them, rather than a reviewer having to do 'all or nothing'. This seemed, and seems, a good idea to me.

I'm still not sure this is going to do much to reduce the backlog, though. -- DoubleGrazing (talk) 17:35, 3 July 2026 (UTC)

The assumption that I declined the article because the sources were Nigerian is incorrect and uncalled-for. I rejected it on May 25th because although there were a lot of sources, I felt that several of them didn't contribute much. Since then, some better sources have been added, presumably in response to my assessment. Regarding comments: I've found that if editors need more information, they generally ask on my Talk page, and I'm happy to have a more detailed conversation there. ArthurTheGardener (talk) 17:36, 3 July 2026 (UTC)

I'm sorry if I offended you, that wasn't my intention. Gheus left a comment NEWSORGNIGERIA, and you didn't say anything, so I assumed it was for the same reason. I also didn't want to imply that there were any issues. Thanks for clearing it up. TurboSuperA+_[talk] 17:43, 3 July 2026 (UTC)

No offence taken, but thank you. I'm still a bit new to AfC, and I'm sure I make errors of judgement, but I do give my assessments a lot of thought. ArthurTheGardener (talk) 17:52, 3 July 2026 (UTC)

The top post at that university, as far as NACADEMIC is concerned, is Vice-chancellor.

I do occasionally take out a duff IMDB source, but in many cases it's not a quick task ChrysGalley (talk) 14:11, 3 July 2026 (UTC)

I'll always remove the blatantly bad ones like IMDb, spotify, etc. Primefac (talk) 14:28, 3 July 2026 (UTC)

That's good to know: I was wondering what the etiquette was. ArthurTheGardener (talk) 17:53, 3 July 2026 (UTC)

Helper-script changing AFC templates to redirected names

When looking at a resubmitted draft that had previously been declined, I am especially want to see what has changed since the previous decline. That means I am likely to diff the revision at the time of the decline against the current version. This diff is needlessly complicated because some of the AFCH tools use redirected forms of the AFC templates (and even change canonical calls to those redirected ones) whereas other AFCH tools and also other genfixes actions change them to canonical. The more decline–resubmission cycles or gnoming, the more my eyes glaze over even before I get to the content that might have changed.

As a simplified demonstration of workflow/timeline (first I saw with the problem in the queue, no prejudice against the involved editors):

1. First submission places {{AfC submission}}
2. First decline, where {{AfC submission}} becomes {{AFC submission}} and a {{AFC comment}} is added.
3. Various edits, including resubmission. AWB gen-fixes has been run, where {{AFC submission}} and {{AFC comment}} become {{AfC submission}} and {{AfC comment}} respectively
4. I look at the diff since last decline

Lots of AFC material from prior to #3 appear as new or changed content because the case-change in the template calls.

Is there a reason that AFCH uses the all-caps version, and even changes mixed-case canonicals of them to all-caps? DMacks (talk) 08:08, 5 July 2026 (UTC)

Tracked in github.com
Issue #469

I would presume the reason is no one noticed or at least no one had thought to file an issue before since the template was moved in 2020. I have raised one now. KylieTastic (talk) 10:00, 5 July 2026 (UTC)

Correct; nothing was technically broken when the names were changed so the script never got updated. I'll see about fixing that (because I agree, those sort of edits are diff-killers). Primefac (talk) 10:40, 5 July 2026 (UTC)

When does probation end?

Hi there. I have been a reviewer on probation for 13 months. In this time I have been reviewing a bit on and off. I made one mistake by accepting Manuport Logistics which was then deleted, which I freely accept was my error. Whether I am officially on probation or not makes no difference to me but I am just curious when users are normally given permanent status. Thank you in advance. JacobTheRox^{(talk | contributions)} 15:04, 5 July 2026 (UTC)

I go through the entire list every 6 months primarily to check for inactive reviewers, but I occasionally will do spot-checks for the probationary list. Nothing wrong with slow and steady, so I generally don't think about "promotion" until the review count starts getting up towards 100 (which averages out to about a review every other day over a six-month period). Primefac (talk) 15:17, 5 July 2026 (UTC)

Okay, thank you for the reply. JacobTheRox^{(talk | contributions)} 15:24, 5 July 2026 (UTC)

StoryToys Wikipedia Article Page Creation Process Related Assistance

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

---

Help! Can somebody on Wikipedia pretty please help me and also show me how to create StoryToys Article Page with proper information sources and also reliable coverage and reviews? Pretty please actually reply to me as soon as possible. Thank you! DisneyFanMF (talk) 18:51, 5 July 2026 (UTC)

DisneyFanMF, WP:YFA is really your best port-of-call, but if you want additional help with that specific draft please ask at WP:AFCHD, as this page is more for administration of the project itself. Primefac (talk) 19:00, 5 July 2026 (UTC)

This page is for discussion about the operation of the AFC process. You've already posted to the main AFC help desk. Please do not use multiple forums. 331dot (talk) 19:06, 5 July 2026 (UTC)

Ah, my bad, didn't see they already posted at the HD. Primefac (talk) 19:17, 5 July 2026 (UTC)

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

Princenile TA socks

Just letting the project know to be wary of NGC drafts, many that meet WP:NASTRO but are very short and only contain one or two sources are likely to be Princenile socks. Please tag for WP:G5 and/or report to the sockpuppet investigation. Pretty identifiable WP:DUCK behavior to watch out for. 🌀Hurricane Wind and Fire, why did you decline my draft? (talk) (contribs)🔥 04:15, 6 July 2026 (UTC)

A Question about a Hidden Notice

I have probably seen this many times and ignored it. In editing a draft, I see <!-– Important, do not remove anything above this line before article has been created. --> The infobox and the AFC stuff are above it. My first question is: Does "before article is created" mean before the draft is accepted? I can see that the AFC stuff should not be removed except by AFC acceptance (or by an editor who knows what they are doing and has a good reason for doing it). (Removing the AFC stuff to hide declined is a case of knowing what one is doing and having a wrong reason.) If that is what it means, should the infobox actually be below the hidden notice, because the infobox, like the text, is part of the draft and subject to review? Robert McClenon (talk) 02:40, 7 July 2026 (UTC)

I know you're experiences are vastly larger than mine, but I've never seen an infobox above the ----- line break, but yes, if you use AFCH to clean the page it will put things in order of:

• AFC templates (and associated hidden notices)
• Shortdesc/maint tags (if any)
• Infobox
• Article content
• Refs

Whether this is done manually or with the script, the infobox isn't magically immune from review if it's in the wrong place </joke>. Primefac (talk) 09:20, 7 July 2026 (UTC)

Just the other day I saw a draft where that hidden comment was the last line in the source. :) DoubleGrazing (talk) 09:59, 7 July 2026 (UTC)

I have seen that comment moved all over the place. I guess we have a lot of blind editors :)

Yes Robert it means before the article is accepted, and yes all content including any infobox are meant to be below it. The reason it is there is just to try to stop submitters altering the various AfC templates they often do not understand. Mostly that is removing or editing old declines, but sometimes changes to other AfC templates or the adding weird stuff to the active submission breaking it. I have even seen the odd case of content/infobox above the ---- line as well. KylieTastic (talk) 10:40, 7 July 2026 (UTC)

So my next question is: Should I move the line break to be in its proper place if I am leaving the draft for another reviewer? My thinking is that I am not required to do that, but that doing that is a best practice. Does anyone agree or disagree? Robert McClenon (talk) 22:58, 7 July 2026 (UTC)

I used to move things to the correct order when I noticed, but yes I would agree with your thinking: not required, but a good thing to do. KylieTastic (talk) 08:28, 8 July 2026 (UTC)

If things are bad enough I can't just make a fix in ten seconds, I'll use the AFCH cleaner function to tidy it all up. Primefac (talk) 17:00, 12 July 2026 (UTC)

August backlog drive

Hello all! In case you missed it, the AfC backlog hit a magical 5000 drafts yesterday. There has been discussion of organising a backlog drive in August on the discord (before the next NPP drive in September). I've said I'm happy to coordinate one along with @Tenshi Hinanawi, and have tentatively created WP:AFCAUG26, but before we set everything in stone, just want to run it past everyone here too. So, people keen? In solidarity, nil ^nz 21:55, 7 July 2026 (UTC)

I am seldom in favor of backlog drives because they are often poorly documented, so that I and other reviewers may not know what we are supposed to do when. In this case, I think that a backlog drive is in order. I also think that the criteria, including the scoring criteria, should be documented a week or so in advance of the start, so that any questions can be asked and answered, and so that the reviewers understand and agree on the criteria. Robert McClenon (talk) 23:03, 7 July 2026 (UTC)

We'll be following the format and criteria used in the last few drives, which can be found on the drive's page, but if there's anything unclear let us know. In solidarity, nil ^nz 00:15, 8 July 2026 (UTC)

WP:GAN do backlog drives every four months due to the fact that there are always more people nominating than reviewing GAs. Maybe I think AFC could organise it to happen two times a year or so. JuniperChill (talk) 00:23, 8 July 2026 (UTC)

I think this would be worth thinking about. NPP currently hold backlog drives every four months too, and if AfC were to do regular drives, my suggestion would be to also do it every four months, but in the intervening months, so every second month there'll be either a NPP drive or AfC drive (with a month's buffer in between). Only issue with scheduled drives is you then run the risk of clashing with some of the other big ones, which stretches the same editor pool between them (and/or burn them out). In solidarity, nil ^nz 01:31, 8 July 2026 (UTC)

I would double that and do eight months. The backlog seems to have been managed pretty well to keep it reasonable. ✶Quxyz✶ (talk) 16:19, 8 July 2026 (UTC)

I don't think 90-days bonus is feasible and we might want to reduce it down to 60-days. Currently, I do not think there are any articles that would qualify for that bonus and there might only be a couple when it starts in less than a month. ✶Quxyz✶ (talk) 00:24, 8 July 2026 (UTC)

At CAT:AFC/AGE, there's currently 369 that are 90-days, and 627 that are 60-days, so happy to look at how we score the bonuses. In solidarity, nil ^nz 00:38, 8 July 2026 (UTC)

Oops, I did an off-by-one error. 90 days should be fine then. ✶Quxyz✶ (talk) 00:40, 8 July 2026 (UTC)

I haven't been on this talk page for several months (maybe a year, wow) - I did float the idea with Ingenuity of having, in essence, a backlog drive every month - that is, a no pressure way to reward consistent reviewing of articles, rather than having an up-down-up-down fluctuation punctuated by an elimination drive every x months. I think it gained some small traction at the time, but perhaps it is time to revisit it? It would certainly encourage me to do more AfC reviewing and hopefully others as well, without the pressure of doing x articles all in one month, then slacking off. Cheerio, Mattdaviesfsic. Talk to me. 18:35, 16 July 2026 (UTC)

Found it: Wikipedia talk:WikiProject Articles for creation/Archive_53#RfC: Rewards for AfC participation - back when I was certainly less experienced than now...! (Although there is probably still something to the original idea.) Cheerio, Mattdaviesfsic. Talk to me. 19:08, 16 July 2026 (UTC)

Merging and Merging

It seems that I didn't take part in the discussion of merging the Merge process with the Deletion process. I concur with the result, because I think that deletion and merging are related library processes, and that sometimes merging is an alternative to deletion and sometimes deletion is an alternative to merging. Having two separate decision and record-keeping processes to handle what was one encyclopedia-management process was unnecessary. That isn't the question.

However, my question has to do with merging in a different stage of the development process. I sometimes look at the category of AfC submissions with the same name as existing mainspace pages. Right now, there are 322 submissions (mostly drafts) in this category, which is grossly excessive, and is a reason why we need a backlog drive. But there are a variety of reasons why there are entries in this category. Many of them are human names, and the draft needs disambiguation. Many of them are redirects in article space to a parent article. This is what {{db-afc-move}} was created for, but of course the redirect should only be tagged for G6 after the reviewer has verified that the draft should be in article space, and, if accepting the article, the reviewer should also check what changes are needed to the parent article.

But sometimes the originator has created two copies,either the same or almost the same, in article space and in draft space. If they are the same, then the draft should be replaced by a redirect to the article. However, what I encountered had to do with Norman L. Paxton, a flying ace of World War Two. I saw that there were a draft and an article, by the same person, and the draft had more information than the article. I declined the draft as -exists- but said that the article should be expanded. I then added a tag to the article to merge from the draft. Another editor reverted my addition of the merge tag with an explanation that the proposed merge process is deprecated, and there are other ways to discuss a merge. I wasn't using the Merge tag to request a discussion of a marge. I was using it in a way that I previously used it, when it was still in Twinkle, to indicate editorially that it was my recommendation that merging be done boldly. Maybe I was using the Merge tag in a way that was never intended. Maybe I was using the Merge tag in what had been a secondary use that has been swept away.

So I think that I have two remaining questions. First, is there a way that I can mark pages that I think that there should be a merge done, such as of a draft that contains information that is similar to but not the same as what is in an article? I thought that the Merge tags could be used for that purpose as well as for merge discussions, but maybe I was mistaken. Second, in the specific case, may I swap the draft and the article, with explanations in the history via the Move dialog? Robert McClenon (talk) 21:11, 8 July 2026 (UTC)

The user in question has decided that the {{merge from}} template cannot be used any more, and thus reverts every use of it. I disagree but I also am tired of arguing with them in multiple places about their "improvements" to various pages and processes. Personally I would ask them what they expect us to do in these sorts of situations.

If there is only one content editor, then swapping an article with a better draft is a perfectly acceptable thing to do, but if they have different editors a merge will be needed. Primefac (talk) 17:07, 12 July 2026 (UTC)

Thank you for explaining that this is an editor on a hobbyhorse, User:Primefac. I will continue to use the {{merge from}} tag the next time that I think that a draft needs to be merged into an article, or that two drafts need to be merged, neither of which is done with the merge process. When I am reverted, I will discuss with that editor, and then maybe bring the discussion either here or to a Village Pump. I think that occasionally a draft should be tagged for merging via the editorial process, not by a formal process. Robert McClenon (talk) 01:29, 13 July 2026 (UTC)

For the record, my response was a little strong, this is not a single editor out on a crusade, merge discussions were folded into the AFD process but it's the fact this editor is zealously overseeing the process that has been bothering me. Basically I object to the idea that you can't put a banner up to let people (who might not visit the talk page) know that there are other pages that could be merged into a page, and have yet to get anything other than "you're not allowed to use this template any more". Primefac (talk) 08:43, 13 July 2026 (UTC)

AFCH used the ~enwiki version of a username

Tracked in github.com
Issue #408

I declined User:Awsalas/sandbox () and the AFCH script left the declination notice on the talk page User talk:Awsalas~enwiki (). I'll note the draft didn't use that version of the name in the template, from the submission: () {{AfC submission|||ts=20260709200058|u=Awsalas|ns=2}}

Anyone seen this before or know what might have cause this? Bobby Cohn 🍁 (talk) 20:24, 9 July 2026 (UTC)

This is https://github.com/wikimedia-gadgets/afc-helper/issues/408. GTrang (talk) 15:31, 10 July 2026 (UTC)

Option to reject AI generated submissions

This is a hot take, but us reviewers should be able to reject AI-generated submissions.

7 out of 10 submissions I review are AI generated. I'm not over exaggerating. It has become so frustrating, and you see the same for the new pages feed. 95% of submissions I decline are AI generated. Note that I've just had my NPP rights renewed, but I'm not a very new reviewer

Now of course, we should always give the editor a chance to improve and cleanup the article, like we do now. I'm not against that. But it has become stupidly common for editors to use AI to "fix" the articles, or simply make a really poor effort. In fact, in my opinion, such articles usually require to be completely rewritten. They do not meet Wikipedia standards.

So why not have the option to straight up reject it after multiple attempts? I mean as if it's already not clear enough that AI is banned. Fortek67 (talk) 20:05, 10 July 2026 (UTC)

User:Fortek67 - Are you specifically asking for the use of artificial intelligence to be added to the list of Reject codes? It is already a reason to decline. If you are saying that it should be added to the list of Reject reasons, then I agree. A reviewer should be given the option of how much tolerance to allow for authors who use artificial intelligence. Robert McClenon (talk) 00:53, 11 July 2026 (UTC)

I am aware of the decline option for AI, use it a lot. I'm just proposing the option to reject. Fortek67 (talk) 09:34, 11 July 2026 (UTC)

I agree that it should be added as a reject reason. SomeoneDreaming (talk) 01:18, 11 July 2026 (UTC)

But you can already reject something after multiple attempts that are going nowhere. That's perfectly normal practice. If someone has made multiple obviously AI submissions, decline as usual, and write a comment recommending that the next attempt be rejected if it's again AI slop. Then the next reviewer can be your 2O (and will probably reject). You can also report people for repeated LLM use at ANI. In solidarity, asilvering (talk) 01:21, 11 July 2026 (UTC)

Okay, that makes sense, but under which AFCH reject reason? In many cases I have been the 2nd (or 4th…) opinion and it’s clearly not going anywhere but I didn’t think it clearly fit into the listed reasons and there’s no custom field. SomeoneDreaming (talk) 03:29, 11 July 2026 (UTC)

• Rightly or wrongly I do occasionally reject LLM submissions. The key test for me is "is there any way that this can be rewritten by a human and meet the notability requirements?" or is it a hopeless matter? Here is an example from yesterday Draft:The Long Game, which was given a chance from the previous reviewer to improve, the editor made some minor changes and actually added a new chatgpt generated image. So not notable (robot said so), no pathway to notability, and the editor not understanding the problem. There would be cases, in my view, where the clanker-crud is so bad that not only can it not be rescued, but the very basis of the draft is contrary to the purposes of the project (advertising for example). But certainly the frustration is shared. ChrysGalley (talk) 08:28, 11 July 2026 (UTC)

  ChrysGalley, yes, but sometimes those options don't apply. Some drafts generated by AI are so bad they should be just straight up rejected. Others can be less obvious, but they are still declined nonetheless.

  And actually, don't we already make it explicitly clear that AI is banned? Because reviewing AfCs nowadays is getting super frustrating. A lot of other reviewers can't even tell and accept it. Then months later it is (maybe) brought up to WP:AIN and the damage has to be cleaned up.

  @gurkubondinn, sorry to ping you, but what do you think of having an AI option for rejecting AfCs? Fortek67 (talk) 09:38, 11 July 2026 (UTC)

  No worries @Fortek67, I don't mind being pinged (you might be thinking of Gnomingstuff who doesn't like it, both our usernames are 12 characters long and start with a 'G'). I would really like an option to reject AI generated drafts. All of the rejection options are based on the topic of the draft. But I've started rejecting the most egregious ones with the 'topic is contrary to the purpose' reason anyway and a note along the lines of "AI-generated submissions are not accepted" (not that it stops them from being resubmitted). Having rejection option for NOLLM would be great. ‑‑gurkubondinn 09:46, 11 July 2026 (UTC)

  Thank you so much for your response, gurkubondinn. Considering now that at least a couple of people like the idea, and nobody isn't against it, maybe there's an actual place to officially propose this. Is the village pump good? I'm saying this now before this discussion gets to long. Idk. Or maybe we should wait some more time. Fortek67 (talk) 09:48, 11 July 2026 (UTC)

  The discussion has only been open for 24 hours, and it's our own project, we can sort it out here. Primefac (talk) 12:59, 11 July 2026 (UTC)

I've nothing against declining for obvious AI use, and will also readily G15 speedy such drafts, but summarily rejecting at first sight seems a bit bitey to me. Yes, as a reviewer it's frustrating to witness the constant onslaught of AI, especially as the situation seems to be only getting worse. But from a new author's point of view, it may be their first draft, and maybe even the first time they're learning that AI shouldn't be used. I think declining, and giving them a chance to rectify the issue, is less harsh and works well enough for the first (or even second) review. -- DoubleGrazing (talk) 10:05, 11 July 2026 (UTC)

I meant to also say that the problem is more nuanced than just black & white 'AI / no AI'. There are obvious G15 ones which literally need WP:TNT. At the opposite end of the scale, there are those that may or may not involve AI, but don't have any major problems, are fundamentally sound (sources check out, etc.), and could be rescued with minimal effort. If we start rejecting everything with possible AI use to any extent, I think we'll be throwing away some proverbial babies with the bathwaters. -- DoubleGrazing (talk) 10:11, 11 July 2026 (UTC)

WP:TNT – that was my main point with rejecting. Some articles are so bad, they were generated with just one prompt and clearly do not meet Wikipedia standards. Fortek67 (talk) 10:17, 11 July 2026 (UTC)

I think that blatant unsalvageable AI usage probably already comes under the The subject is contrary to the purpose of Wikipedia rejection notice. At least, that's what I have been doing when confronted with blatant AI.

My concern with adding a specific AI-reject reason is that reviewers might reject even salvageable drafts. Rejecting should ideally be fairly last resort to allow the editor to improve the draft. qcne (talk) 10:54, 11 July 2026 (UTC)

I concur, rejection is sufficient using the existing framework. Primefac (talk) 13:17, 11 July 2026 (UTC)

I've started rejecting drafts that meet the G15 criteria. That makes sense to me, because deleting something is a form of rejecting it. But all of the rejection reasons are based on the topic of the draft, and I'm not rejecting because of the topic. It would make more sense to have a way to reject that isn't based on the topic, because that might give the user the wrong impression in the talk standard talk page message and edit summaries that the AFCH tool posts. ‑‑gurkubondinn 13:20, 11 July 2026 (UTC)

I am still not sure how I feel about G15, but that is also an acceptable way of dealing with AI nonsense. Primefac (talk) 13:43, 11 July 2026 (UTC)

I would just like to be able to do it without also telling the user that the topic is unsuitable, because the topic is often notable. The problem is just that they didn't actually write draft they've just submitted and I'm earmarking for deletion. It would be better if I could do it in a way that communicates "this was not accepted because it is generated text" without mentioning the topic. That's why I mostly just decline before I tag for G15, but that has the problem of implying to them that if they just submit something that "looks" less like generated text then it would be fine. It would be great if it would tell them that generated text is not accepted without implying anything else. When I feel like the user might be open to writing a new draft themselves, then I'll often also go on their talk page and explain that as well. It's just the obviously generated, or a re-generation of something that has already been declined/deleted/rejected and so fourth that I will outright reject it at AfC. ‑‑gurkubondinn 13:52, 11 July 2026 (UTC)

Unless I'm mistaken the ai decline does that, and I like your method of decline-then-G15. Primefac (talk) 13:55, 11 July 2026 (UTC)

I guess that what I would prefer is to somehow be able to not include the "Next steps" in the decline notice that gets posted to the user's talk page (for example in Diff/1363562428), because that suggests that they could just regenerate the article and try again. The notice should somehow communicate clearly that generated submissions are not accepted, and that there is no way to get around that. ‑‑gurkubondinn 14:11, 11 July 2026 (UTC)

That's the current way I guess you can say, the closest to "rejection". Although I still think an "AI" option will be better. Fortek67 (talk) 12:56, 12 July 2026 (UTC)

The decline/reject options will never fit every situation which is one of purposes of using comments. The AI decline already gives instructions on what they should do and where to go if they have questions. If they keep submitting AI slop, then reject it using "contrary to the purpose of Wikipedia" and use the comments to explain further. The "Next steps" would be for them to completely rewrite it which is essentially what the decline tells them but maybe it could more straight forward. S0091 (talk) 21:10, 11 July 2026 (UTC)

Honestly I though that too that all reviewers would start rejecting AI submissions. Then again we would have to carefully consider, how bad an AI submission should be for it to be rejected? I'm not saying all AI submissions should be rejected.

And we should make it explicitly clear what should be rejected. Because if it just says "AI" then all reviewers would start rejecting submissions. Although my current main point is that one of the warnings you see when creating an AfC, is that AI is banned. We have the same for things like non-notable topics, or bias autobiographies. So maybe we should treat AI the same way? Fortek67 (talk) 12:58, 12 July 2026 (UTC)

I'm extremely confused here -- isn't this happening already? There are over 5,000 articles in Category:AfC submissions declined as a large language model output. Gnomingstuff (talk) 06:23, 13 July 2026 (UTC)

I am talking about rejecting not declining submissions. Have a look at the AfC review options. Fortek67 (talk) 06:29, 13 July 2026 (UTC)

I just had a thought, spurred by Gnomingstuff's highlighting of category of AfC Category:AfC submissions declined as a large language model output.

An LLM Reject may help us better track the level of AI-generated drafts? Quite often I will go straight to Reject as Contrary to the purpose of Wikipedia for obvious slop drafts, and then tag then with G11. But this doesn't actually then reflect as an AI-related Reject.

Just a thought. qcne (talk) 12:43, 13 July 2026 (UTC)

I am absolutely already in the habit of rejecting AI generated drafts if I see no reasonable attempt at human-driven improvement by its creator. If they've already been declined once for AI and I see the next edit summary is obviously AI generated and then they resubmit it again, I immediately reject the draft under, as others have said, "contrary to the purpose." We should waste absolutely no time on people who've already been told very clearly that AI is not allowed. Athanelar (talk) 05:29, 18 July 2026 (UTC)

The painful reality is that a subset of editors, hopefully a small subset but it's also growing in number, is simply unable to operate without AI. In the draft:The Long Game mentioned above, first declined for AI usage, then the second submission's edit summary ran: Created Wikipedia article for Saalim Zayed's book "The Long Game." The article covers the book's main arguments about education and short-term thinking, its Islamic framework, and the author's background. I expanded the synopsis to include details from all eight chapters, added a themes section covering the book's main ideas, and included multiple citations from the manuscript. Tried to keep the tone neutral and encyclopedic without sounding promotional. Noted that there are no independent review. So after the first reject they didn't see and/or understand the first decline reason and went straight back to the robots. ChrysGalley (talk) 07:16, 18 July 2026 (UTC)

This is the general pattern I'm starting to see develop, yes. I even wrote a whole AISIGN about it; WP:AIUNSURE. People will see the decline notice and then, rather than reading it, will ask the chatbot to ask us to explain why it was declined.

But that's exactly why I don't waste time on these people. If they don't read the giant red notice explaining what they need to do then I'm not going to waste time saying the same thing all over again. Turn your brain on and come back. Athanelar (talk) 08:25, 18 July 2026 (UTC)

Well said. They don't read the notice and just copy and paste it to whatever AI they're using. AI will rewrite it and give them some long edit summary to paste. These editors know nothing about Wikipedia. Fortek67 (talk) 08:29, 18 July 2026 (UTC)

Rejection for Repeated Resubmission

The above discussion mentions drafts that are repeatedly declined due to the use of artificial intelligence. This raises a mostly unrelated question. Do we need a rejection code for repeated resubmissions of drafts? I reject them as Not Notable, because the declines usually were for either notability or verifiability, and the originator never established notability after repeated declines, but I have sometimes wondered whether repeated resubmission without improvement should be specifically listed. Robert McClenon (talk) 04:37, 12 July 2026 (UTC)

@Robert McClenon This seems like a good idea and will help reinforce with repeat submitters. I feel there is a template somewhere that sums that up (along the lines of draftnoimprove or something like that) we could modify for use. 🌀Hurricane Wind and Fire, why did you decline my draft? (talk) (contribs)🔥 05:35, 12 July 2026 (UTC)

User:Hurricane Wind and Fire - That may be {{noimprove}}. It is one of multiple templates that I have written that are entered in the AFC comments window. At present, it is worded to warn that a future resubmission will result in rejection, but I have sometimes also used it on a rejection. Robert McClenon (talk) 05:44, 12 July 2026 (UTC)

I disagree with the idea that a draft should be rejected due to repeated submissions; when that happens it is a failure of the editor, not the content, and we need to ask ourselves if the draft is not salvageable, or the editor is. Repeatedly resubmitting without making changes falls into WP:TE territory (regardless of whether the draft subject is notable) so the two things need to be independently evaluated (i.e. a draft with a CCoS could still be acceptable even if the creator is incompetent). Primefac (talk) 09:40, 12 July 2026 (UTC)

Well my initial idea was that rejecting submissions that are so bad, they require complete rewriting. Sometimes users just generate complete text walls of AI slop, no actual information to anything, such as links, templates, categories, etc.

Also, when is it applicable to nominate the submission for CSD G15? I've seen it done before, wouldn't you say that's a way of rejecting? Fortek67 (talk) 12:55, 12 July 2026 (UTC)

Having a rejection reason for repeated resubmissions would address it in a much more resilient, structural way than a specific "reject" version of the LLM decline. However, we can also think about the aspect of guidance: was the lack of improvements because the draft author refused to communicate and heed the advice, or simply did not understand or did not get actionable enough advice?

I once added (from a suggestion of @Jimbo Wales) this section as Wikipedia:WikiProject Articles for creation/Reviewing instructions § Reviewing repeated submissions:

Articles are frequently resubmitted after being declined by a reviewer. If you are reviewing an article that was already declined, and the same issues appear to still be present, it can be helpful to look at the edit history to see if a good-faith effort was made at addressing them. Submitters may be seeking a second opinion from a different reviewer or might not always fully understand the issues justifying a previous decline. Giving a more personal explanation can be helpful, either to guide them towards fixing the issues, or to explain how notability might be lacking.

If there have been substantial improvements, these should be addressed in any subsequent decline. Alongside the templated decline message, the reviewer should add a comment, either on the draft or on the author's talk page, explaining in their own words why the improvements fall short of addressing the issues that have been pointed out.

On the other hand, repeatedly submitting the same version, after attempts by several reviewers at clearly communicating the issues in their own words, may be considered tendentious editing.

The tendentious editing part matches what @Primefac was touching on: it is an issue with the editor rather than with the draft's subject, and especially for drafts on more popular topics (e.g. upcoming films), we don't want to shut the door to other potential improvements. Ideally, we'd want to establish a healthy balance: provide close guidance to cases where the editor genuinely struggles to understand how to improve the draft, while also putting a stop to repeated submissions where it is clear that no attempt is being made from their end. Chaotic Enby (in solidarity · talk · contribs) 14:34, 12 July 2026 (UTC)

I agree, and yes, we don't want to shut the door to other potential improvements – but what do you think of WP:TNT? Like I said before, some of these submissions are sometimes just AI slop text walls. Poor formatting, no links, no cats, etc.
Then again I assume that can be rejected because it is "contrary to the purpose of Wikipedia", but I think an option for AI would be better, it's more specific. Fortek67 (talk) 14:39, 12 July 2026 (UTC)

TNT is always on the table: sometimes, the best improvement is really just to start again from a blank state. The problem is that rejections address the subject itself rather than the actual content, and can discourage these efforts. Chaotic Enby (in solidarity · talk · contribs) 15:10, 12 July 2026 (UTC)

I think that’s why the suggestion is made for a reject reason that addresses the content rather than the subject, but I might be missing something? SomeoneDreaming (talk) 18:00, 13 July 2026 (UTC)

Custom Reason for Rejection?

There is an option for a custom reason for a decline. Should there also be a custom option for rejection, or would that encourage newer reviewers to reject submissions for inadequate reasons? Robert McClenon (talk) 04:40, 12 July 2026 (UTC)

No, because yes. Primefac (talk) 09:35, 12 July 2026 (UTC)

Definitely not – rejecting submissions is pretty serious, and some reviewers may think that it can be done for any reason. Fortek67 (talk) 12:52, 12 July 2026 (UTC)

I also suggest holding off per the others and I feel the rejection reasons cover nearly everything we could reject for. There may be one or two cases where our current reasons don't fit but that can be further explained in the comment. 🌀Hurricane Wind and Fire, why did you decline my draft? (talk) (contribs)🔥 14:27, 12 July 2026 (UTC)

AfC stats tool

Similar to the AfC review history tool, is there a tool that can identify articles authored by IPs or temporary accounts that were later accepted by a specific AfC reviewer? Bonus if it can also detect whether those articles are Nigeria-based BLPs or companies. Also, should I be asking this at WT:AFC or WP:VPT to get a better chance of an answer? If so, please let me know so I can move this. Jeraxmoira🐉 (talk) 17:03, 12 July 2026 (UTC)

@Jeraxmoira Worth asking at Wikipedia talk:WikiProject Articles for creation as that is where all us AFCers hang out. qcne (talk) 17:18, 12 July 2026 (UTC)

If an AFC reviewer has an /AfC_log enabled you'll be able to cross-reference their accepts with the users. Primefac (talk) 19:11, 12 July 2026 (UTC)

They have around 1900 accepts and the log also includes declined entries, which makes it difficult to identify which accepted articles were written by TAs/IPs. I'm sure there's a pattern to be found here, but the volume of articles makes it harder.

I came across https://quarry.wmcloud.org/ on the ANI thread. Primefac, do you think it's possible to pull this data via Quarry or are there any limitations to it? Jeraxmoira🐉 (talk) 20:43, 12 July 2026 (UTC)

Yeah, if you get the right search params that could probably pull what you want. Primefac (talk) 20:53, 12 July 2026 (UTC)

@Jeraxmoira: Is this still needed? There's no tool for this, but I can give you all the data you need. I'm also happy to set up a temporary web service so you can query it yourself if you need to find more users. – DreamRimmer ■ 07:54, 23 July 2026 (UTC)

DreamRimmer Thank you for asking, but I don't think it will be of any use to me now. Editors at SafariScribe's NPP/AfC reviews may need it, but I'm not sure. Jeraxmoira🐉 (talk) 20:21, 24 July 2026 (UTC)

Odd 'authors'

Monday morning's idle curiosity more than anything of real substance, but: I've seen several drafts (mostly or only on South Asian subjects, although that could be just a coincidence) citing sources where the authors are shown as "Share, Twitter, Facebook, LinkedIn, WhatsApp, Follow us" or something to that effect. This comes from social share buttons on top of the news (or 'news') article being cited, such as here. Can anyone think of a reason other than the use of AI/LLM which would cause this? -- DoubleGrazing (talk) 09:22, 13 July 2026 (UTC)

Appears to be an issue with website's data. Putting your linked URL into VE's automatic ref generator produced the following:

References

In solidarity, nil ^nz 09:51, 13 July 2026 (UTC)

Oh, okay, thanks. I assume 'VE' means VisualEditor? I didn't even know it has an automatic citer tool. (I guess that serves me right for never going anywhere near the damned thing.) -- DoubleGrazing (talk) 10:53, 13 July 2026 (UTC)

Yup, Visual Editor! Is a pretty handy tool at times for populating citations from just a URL, DOI or ISBN. In solidarity, nil ^nz 12:33, 13 July 2026 (UTC)

With it being likely the VE will become default for new editors, I wonder if this needs to be raised as a bug in Phab. qcne (talk) 12:35, 13 July 2026 (UTC)

I think it's actually something wrong with the page's metadata, not anything phab could fix. But it's probably a good idea to start a ticket just in case. In solidarity, asilvering (talk) 22:53, 13 July 2026 (UTC)

I checked the html source code, and the webpage has "author":{"@type":"Person","name":"Web Desk","url":"https://www.asianetnews.com/author/web-desk"}, so I'm confused why VE isn't pulling that like Citer does below. In fact, I can't see any obvious reason that would make it pull the Socials instead? In any case, I've opened a ticket at phab:T432076. In solidarity, nil ^nz 23:31, 13 July 2026 (UTC)

citer grabs the author field, which is a generic name but certainly more correct:

• Desk, Web (2024-09-06). "നാലാം വാരവും തിയറ്റര്‍ വിടാതെ 'വാഴ'; മൂന്നാഴ്ച കൊണ്ട് ബോക്സ് ഓഫീസില്‍ നിന്ന് നേടിയത്". Asianet News Malayalam (in Malayalam). Retrieved 2026-07-13. {{cite web}}: |last= has generic name (help)

Maybe there's some code/algorithm they could yoink? ScalarFactor (talk) 23:10, 13 July 2026 (UTC)

Draft:George Perks

Hi, I was reviewing this page and think I should probably decline it, due to insufficient significant independent coverage. However, I was wondering if WP:NM might apply to him, in which case he has produced/engineered several albums that reached no. 1 in UK charts, and so would pass. Thanks Freddieh9 (talk) 14:57, 14 July 2026 (UTC)

I can't recall NM ever being successfully used for a producer/sound engineer in the absence of significant coverage. But if you think it's borderline, and you're not sure whether to accept or not, "has produced some top-charting albums" is probably worth accepting for. We don't need to be sure things will survive AfD - just that they have a reasonable chance. In solidarity, asilvering (talk) 15:03, 14 July 2026 (UTC)

Not really, the sources used, apart from 2 interviews, only give a trivial mention to him. Freddieh9 (talk) 16:43, 14 July 2026 (UTC)

Discussion of interest

Reviewers might me interested in the discussion happening at Wikipedia:Village pump (miscellaneous)/Archive 89 § AfC reviewers removing old decline notices on several occasions Best, Squawk7700 (talk) 00:38, 16 July 2026 (UTC)

AfC related discussion

AfC reviewers may be interested in the following discussion: Wikipedia talk:New pages patrol/Reviewers § NPP Guideline Proposal Regarding AfC Drafts EaglesFan37 (talk) 19:36, 16 July 2026 (UTC)

FYI, this is still getting comments and discussion on the NPP talk page. The proposal is to not allow NPPs to mark accepted drafts as reviewed, which would affect many AFC reviewers. –Novem Linguae (talk) 13:04, 21 July 2026 (UTC)

Suggestion for "Accept" template

The user talk page template for accepted articles (Template:AfC accept/testcases) includes the following friendly bits of advice, depending on the initial assessment:

• All = "See the quality assessment scheme to find out how to improve the article."
• Stub = "It is common for new articles to start out as stubs and then attain higher grades as they develop over time. You may like to take a look at the grading scheme to see how you can improve the article."
• Start = "Most new articles start out as Start-Class and then attain higher grades as they develop over time. You may like to take a look at the grading scheme to see how you can improve the article."

I like the idea of helping editors learn how to improve their articles, but I suspect that Wikipedia:Content assessment (or Wikipedia:Content assessment#Grades) is not super helpful for new editors interested in improving their articles, because it wasn't written for that audience. For example, the grading scheme table starts with a description of Featured Articles, rather than starting with a description of Stub/Start class and describing how to get to C or B quality. The most useful information is inside the table in "More detailed criteria", collapsed by default.

I suspect it'd be more helpful to primarily link to Wikipedia:Article development - that page isn't amazing, but could be revised to better address the needs of new editors. Makes sense to retain a link to the grading scheme for people curious about what "stub" and "start" mean. For example:

• All = "See article development to learn how to improve the article."
• Stub = "It is common for new articles to start out as stubs and attain higher grades as they develop over time."
• Start = "Most new articles start out as Start-Class and attain higher grades as they develop over time."

Also, the templates in Category:WikiProject Articles for creation might make sense to re-categorize into Category:WikiProject Articles for creation templates. Dreamyshade (talk) 04:46, 17 July 2026 (UTC)

Honestly, I think we might want to remove all of that and just replace it with something like "Feel free to continue working on the article." In solidarity, asilvering (talk) 23:21, 17 July 2026 (UTC)

I'd support this and / or @Asilvering's suggestion below. Shorter the better probably so that new editor's aren't overwhelmed. qcne (talk) 12:41, 18 July 2026 (UTC)

Easy enough to remove, so I've done so; if folk really want it back it's easy enough to undo. Primefac (talk) 12:51, 18 July 2026 (UTC)

Referencing – AI artefact?

I'm seeing quite a few drafts where inline citations are missing, and instead the sources are all cited in the 'References' section, and always in the vertical form. I'm guessing some AI tool is the culprit? -- DoubleGrazing (talk) 11:21, 17 July 2026 (UTC)

Could you link to an example draft to help me (maybe others) to understand what you mean by "in the vertical form"? Cheerio, Mattdaviesfsic. Talk to me. 11:23, 17 July 2026 (UTC)

Sorry, I've just deleted the most recent one which prompted me to come here. But if you look at Template:Citation#Simple_citations, it shows both the horizontal form (each cite param next to each other) and the vertical (each on top of each other). I mostly see the horizontal type, but these ones where the refs are all at the bottom they're invariably in the vertical layout. -- DoubleGrazing (talk) 11:29, 17 July 2026 (UTC)

Oh I see. I assumed you meant individual citations on different lines, haha. Cheerio, Mattdaviesfsic. Talk to me. 11:38, 17 July 2026 (UTC)

Hm, maybe? But I dimly recall this being the way I learned how to do citations, before I just let all the automated tools do it for me. My guess is we have a how-to page somewhere that suggests doing this, and either AI is "learning" from it or some editathon or something pointed people at it. In solidarity, asilvering (talk) 18:47, 17 July 2026 (UTC)

• I tend to use Citer, but if it's out of action or can't find an ISBN and I'm doing it manually then at least to begin with I would write them out line by line, just to check I don't have too many pipes or include a carriage return. I've also have in my sandbox a line-by-line template, more so I don't forget something. I always now use <references> rather than {{reflist}} because it's so much easier to maintain. However I think there is something on the AI side here, when you get a single edit text+submit all in one. But unfortunately AI isn't consistent in approach on these, or rather I suspect there are competing AI products doing similar things. ChrysGalley (talk) 08:53, 18 July 2026 (UTC)

Proposal for condensing declines

While the TfD for Template:AfC notice holder was ongoing, KylieTastic suggested that, if there was going to be something to contain old declines, it should function like {{WikiProject banner shell}}. Although a banner shell seems rather tricky to pull off, this suggestion gave me a brand new idea that made me support deleting the template so I can start over on the right track.

This new idea involves condensing declines into bullet-point lists (like how {{multiple issues}} handles maintenance banners or {{old XfD multi}} handles historical AfD outcomes) that only show the first sentence of each decline reason.

Rough example

{{prior declines|
{{AFC submission|d|v|u=173.71.213.176|ns=118|decliner=WaddlesJP13|declinets=20241203000101|small=yes|ts=20241202225931}} <!-- Do not remove this line! -->
{{AFC submission|d|v|u=User1SD|ns=118|decliner=DoubleGrazing|declinets=20241201105511|reason2=web|small=yes|ts=20241201103428}} <!-- Do not remove this line! -->
{{AFC submission|d|web|u=49.184.195.198|ns=118|decliner=AlphaBetaGamma|declinets=20240922154515|small=yes|ts=20240922140213}} <!-- Do not remove this line! -->
}}

Example with many declines

{{prior declines|
{{AFC submission|d|n|u=R3adyWrit3s|ns=118|decliner=Theroadislong|declinets=20260502192127|reject=yes|small=yes|ts=20260430000000}} <!-- Do not remove this line! -->
{{AFC submission|d|n|u=R3adyWrit3s|ns=118|decliner=EatingCarBatteries|declinets=20260429234124|reject=yes|small=yes|ts=20260429232832}} <!-- Do not remove this line! -->
{{AFC submission|d|music|u=R3adyWrit3s|ns=118|decliner=EatingCarBatteries|declinets=20260429230652|ts=20260429224712}} <!-- Do not remove this line! -->
{{AFC submission|d|bio|u=ElizabethMarieCamacho|ns=118|decliner=Theroadislong|declinets=20260429191336|small=yes|ts=20260429000000}} <!-- Do not remove this line! -->
{{AFC submission|d|ai|u=R3adyWrit3s|ns=118|decliner=Gurkubondinn|declinets=20260427221314|reason2=v|small=yes|ts=20260427221107}} <!-- Do not remove this line! -->
{{AFC submission|d|music|u=R3adyWrit3s|ns=118|decliner=Tacyarg|declinets=20260427101859|small=yes|ts=20260426154710}} <!-- Do not remove this line! -->
{{AFC submission|d|music|u=R3adyWrit3s|ns=118|decliner=Bonadea|declinets=20260426142824|small=yes|ts=20260426133600}} <!-- Do not remove this line! -->
{{AFC submission|d|v|u=R3adyWrit3s|ns=118|decliner=ChrysGalley|declinets=20260426131949|reason2=music|small=yes|ts=20260426130344}} <!-- Do not remove this line! -->
}}

If a notice-containing template is reintroduced, The AfC helper script may have to be reconfigured to prevent unintended removals of declines within the template. – MrPersonHumanGuy (talk) 16:58, 17 July 2026 (UTC)

• Must say I like this idea. Cheerio, Mattdaviesfsic. Talk to me. 17:04, 17 July 2026 (UTC)
• Support the idea too, so long as (a) the immediately previous decline is retained in full to assist the current editor, and (b) the old Comments are left in. These previous declines are invaluable for the reviewer but a new editor is unlikely to benefit from the historic chapter-and-verse versions. ChrysGalley (talk) 08:57, 18 July 2026 (UTC)
• I pretty much fully agree to this proposal. NeoGaze (talk) 09:33, 18 July 2026 (UTC)
• I have a slightly less "let's redesign the entire template structure" way of doing what is being proposed, but in the meantime I have a question - are the old declines for us reviewers, or for the people working on the page? If it's just for us, then yes, this is a perfectly suitable means of showing previous declines. If it is for the writers, trimming it down might remove too much useful information (note that |small= on old declines removes everything except the decline rationale itself). In other words, does removal of the extra information in old declines hurt the editor more than it helps us (by reducing the amount of scrolling we need to do to review the page)? Primefac (talk) 09:44, 18 July 2026 (UTC)

  Are the old declines are for us reviewers, or for the people working on the page?

  I'm sure that both types would appreciate no longer having to scroll as much through declines, and that more of these declines can fit on their screen.

  Does removal of the extra information in old declines hurt the editor?

  I doubt it would. As far as I can tell (and if comments at the AfC help desk are any indication), some editors don't seem to find the lists of tips in the decline notices to be sufficiently helpful, so having the same lists repeated over and over again might not leave any better an impression on them.

  Part of my idea is that the latest decline would be kept at full size above this banner. In that case, two lists of tips could remain up for editors to read, if they even do that at all. If it's necessary to display more reasons at the same time, the AfC decline notice should be designed to be able to display more than two if needed. That way, reviewers can reiterate every point they think is still necessary and won't have to pick just two anymore. – MrPersonHumanGuy (talk) 10:35, 18 July 2026 (UTC)

  Just as a minor note about your last point, we have decided many times over the years that two decline reasons is more than sufficient; by the time you hit a third decline reason, you're more than likely reiterating things that were in the other two. Primefac (talk) 11:13, 18 July 2026 (UTC)

  If editors only need to see the advice that accompanies two decline reasons, then it may not hurt to condense previous declines in the way demonstrated above, especially if the advice given in them is already reiterated in the latest decline notice. – MrPersonHumanGuy (talk) 12:30, 18 July 2026 (UTC)

It would be better if like {{WikiProject banner shell}} you could still expand/show any of the individual declines. KylieTastic (talk) 12:36, 18 July 2026 (UTC)

Agreed. In general I like the idea of condensing templates on drafts with loads of declines, but I worry that by removing actual content from the decline message it breaks the chain somewhat and could confuse new editors. Whereas, collapsing them does the same thing but keeps the content. Worth thinking how that would look on mobile view though. qcne (talk) 12:40, 18 July 2026 (UTC)

It's like how {{multiple issues}} removes content from maintenance banners. For example, if {{cleanup}} or {{AI-generated}} are placed inside it, then only the first sentence of each would be shown, and their corresponding placement reasons (if filled in) wouldn't be viewable to readers. Users who place those cleanup tags likely want readers to be able to see their reasons without going into the source editor. – MrPersonHumanGuy (talk) 14:29, 18 July 2026 (UTC)

As a matter of fact, when I first introduced {{AfC notice holder}}, I originally called it {{AfC notice shell}} and put declines inside the banner, but that caused declines to become narrower because they were {{ombox}}es, so I proposed adding a wide parameter that would turn {{AfC submission/declined}} into a {{fmbox}}. When that suggestion was turned down (because I didn't realize I needed to get consensus before making an edit request on a template talk page), I later got the idea to put the declines below the banner instead. I thought hiding declines would be okay because that's what {{WikiProject banner shell}} does on some talk pages. – MrPersonHumanGuy (talk) 12:54, 18 July 2026 (UTC)

If there is to be an AfC banner shell instead, it could look something like this:

This is just a rough, improvized demonstration using only the markup I'm familiar with. An actual version (with proportions that better match {{WikiProject banner shell}}) might use Wiki syntax I wouldn't have been able to think of or work with. {{WikiProject banner shell}} relies on a module, and modules are beyond my Wiki skill set. – MrPersonHumanGuy (talk) 13:51, 18 July 2026 (UTC)

As I said, I have ideas. Let's figure out what we want to see before we start throwing things at the wall. Primefac (talk) 14:13, 18 July 2026 (UTC)

@Primefac: Are you ready to show us your ideas yet? – MrPersonHumanGuy (talk) 12:03, 22 July 2026 (UTC)

I was waiting for more discussion, but either way I sandboxed some changes a week ago. Primefac (talk) 08:38, 23 July 2026 (UTC)

Here's a full list of condensed versions of decline comments as they would appear in a bulleted list of declines below the latest one:

• neo – This draft's references do not show that the neologism meets Wikipedia's criteria for inclusion.
• web – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for web content.
• prof/academic – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for academics.
• athlete/sport – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for sports.
• music/m/band – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for music.
• film – This draft's references do not show that the film meets Wikipedia's criteria for inclusion for films.
• book – This draft's references do not show that the book meets Wikipedia's criteria for inclusion for books.
• event – This draft's references do not show that the event meets Wikipedia's criteria for inclusion for events.
• corp/inc/org – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for organizations and companies.
• bio – This draft's references do not show that the person meets Wikipedia's criteria for inclusion for people.
• nn – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion.
• list – This draft's references do not show the list meets Wikipedia's criteria for inclusion for stand-alone lists.
• med – This draft contains medical, health, or psychological claims. Wikipedia requires a higher standard of sourcing for biomedical content.
• geo – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for geographic features.
• species – This draft's references do not show that the species meets Wikipedia's criteria for inclusion for species.
• astro – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for astronomical objects.
• number – This draft's references do not show that the number meets Wikipedia's criteria for inclusion for numbers.
• creative – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for creative professionals.
• school – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for schools.
• cat – This is not the correct place to request new categories.
• empty/blank – This draft appears to be blank.
• lang|languagenotenglish|language – This draft is written in language.
• test – This draft appears to be a test edit.
• redirect – This is not the correct place to request new redirects.
• van – This draft has been declined because it meets one of the criteria for an attack page, a negative biography, or vandalism.
• ilc – This draft lacks inline citations.
• blp – The text of this submission has been removed. Wikipedia has a strict policy regarding biographies of living people.
• cvcv-n – This draft appears to contain copyrighted material which has been removed.
• cv|Website/cv-n|Website – This draft appears to contain copyrighted material from Website, which has been removed.
• source/v/rs – This draft is not adequately supported by reliable sources.
• not – This draft is not suitable for Wikipedia.
• news/oneevent – This draft appears to be a news report or about a single event.
• dict/d – This draft appears to be a dictionary definition.
• plot – This draft appears to be a plot summary.
• joke – This draft appears to be a joke or a hoax.
• ai/llm – This draft appears to contain text generated by a large language model (such as ChatGPT).
• resume – This draft reads like a resume or curriculum vitae.
• ecr – This draft covers a contentious topic with an editing restriction.
• nosource – This draft does not include any sources or inline citations.
• essay – This draft reads like an essay or opinion piece.
• npov – This draft is not written from a neutral point of view.
• advert/spam/adv – This draft reads like an advertisement.
• exists – This draft appears to be a duplicate of an existing article.
• duplicate/dup – This draft duplicates another submission currently submitted for review.
• duplicate|Title/dup|Title – This draft duplicates another submission, Title, currently submitted for review.
• context – This draft provides insufficient context for those unfamiliar with the subject.
• mergeto/merge – This draft does not have sufficient content to warrant a standalone article of its own, but it could be merged into the existing article on the same subject.
• mergeto|Pagename/merge|Pagename – This draft does not have sufficient content to warrant a standalone article of its own, but it could be merged into the existing article at '''Pagename'''.
• reason|Reason – Reason

If it's only necessary to show the full text of up to two comments about the latest submission, then it may not be necessary to retain the full text of each and every comment about earlier submissions, especially if subsequent reviewers reiterate the same messages, or if old comments no longer apply. – MrPersonHumanGuy (talk) 11:08, 21 July 2026 (UTC)

Proposal for a potential future RfC

Collapsing so people don't get confused. – MrPersonHumanGuy (talk) 13:34, 27 July 2026 (UTC)

@Mattdaviesfsic, ChrysGalley, NeoGaze, Primefac, KylieTastic, and Qcne: Would it be okay to start an RfC yet? The options woud be these:

• Option A: Put previous declines into a box with a bulleted list of declines and condensed reasons, as shown above. Analogous to {{Multiple issues}}.
• Option B: Put previous declines in a box and make them collapsible, as roughly modeled above. Analogous to {{WikiProject banner shell}}.
• Option C: Primefac's ideas.
• Option D: A different idea. (please try to describe what you would want instead)
• Option E: No changes whatsoever.

This is just a heads-up. No one has to start !voting on any of these unless {{rfc|prop}} is put up. – MrPersonHumanGuy (talk) 10:31, 24 July 2026 (UTC) Fixed to avoid bot. Primefac (talk) 23:04, 24 July 2026 (UTC)

• Option B, with (ideally) the tweak that the most recent decline is not collapsed: though the show button is totally clear, my experience is that new editors won't necessarily see it. There again if they are parsing via LLM I guess all bets are off anyway. I'm OK with Option A too, and actually E isn't so bad either, I don't see this as a burning bridge issue. Consequently, in terms of RFC, it would be best to have any other options from other users detailed in the RFC, so it may mean a further wait. ChrysGalley (talk) 10:54, 24 July 2026 (UTC)

  The question is how we go about finding out if anyone else has any other ideas that should be included as options so their proponents don't necessarily have to pick Option D when the RfC happens, unless their specific idea just so happens to be the 4th entry on the final version of the option list. – MrPersonHumanGuy (talk) 11:08, 24 July 2026 (UTC)

  with (ideally) the tweak the most recent decline is not collapsed

  Except it isn't really a tweak, because part of my idea is that the most recent decline is kept as-is above the other declines, hence my phrasing "Put previous declines ...".

  P.S. Now that I think about it, my deleted design for a banner that collapsible declines would go under could have been Option D, then:

  • Option D: Put previous declines underneath (not inside) a Prior draft decline notices banner (with the same color and width as decline notices) where they can be collapsed. (a template with this design had been deleted)
  • Option E: A different idea. (please try to describe what you would want instead)
  • Option F: No changes whatsoever.

  – MrPersonHumanGuy (talk) 11:42, 24 July 2026 (UTC)

Maybe it's been discussed previously and I've missed it above, but does this discuss at all the timing of collapsing the previous declines? Like is it beneficial to collapse all but the most recent version? This would allow the submitter to get the benefit of the detailed review of the most recent decline. Or is the proposal to collapse all? Or has this even been decided with respect to these options or discussed. Bobby Cohn 🍁 (talk) 15:00, 24 July 2026 (UTC)

Additionally, I find a curated contributions search a difficult way to propose changes using an RfC. Are there at least perma links that could be used to demonstrate @Primefac's options? Bobby Cohn 🍁 (talk) 15:03, 24 July 2026 (UTC)

To help clear things up, I've just decided to look through the revisions, identify what Primefac has added to the sandbox version (it's the small parameter), and transclude the sandbox version to show Primefac's idea in action:

Now I know what Primefac had been talking about and can clarify Option C accordingly. – MrPersonHumanGuy (talk) 15:40, 24 July 2026 (UTC)

Now for the next version of the option list:

• Option A: Collapse declines (except for the latest one) into a bulleted list below the latest decline like this:

Example of Option A

• Option B: Collapse declines (except for the latest one) in a similar fashion to {{Wikiproject banner shell}} like this:

Example of Option B

This is a rough conceptual design, as I don't know how to replicate {{WikiProject banner shell}} perfectly.

• Option C: Primefac's idea for condensing declines:

Example of Option C

• Option D: Putting the declines below a banner that collapses them: (a template with this exact approach was recently deleted)

Example of Option D

• Option E: A different idea. (please try to describe what you would want instead)
• Option F: No changes whatsoever.

I'm just workshopping this in advance of a potential future RfC discussion I'd like to start, and I just want to make sure it's good to go before we begin. – MrPersonHumanGuy (talk) 17:17, 24 July 2026 (UTC)

Appreciate the clarification on collapsing "(except for the latest one)"and I like including the demonstrate versions as you have here. I think that makes a strong well thought out RfC. Bobby Cohn 🍁 (talk) 17:23, 24 July 2026 (UTC)

I also appreciate the clarification. (I initially read "previous declines" as "declines in the past", i.e., all of them.) MrPersonHumanGuy, are B or C intended to show decline reasons while collapsed? My initial impression is that B doesn't, and C... I don't know why one does and the others don't. LittlePuppers (talk) 20:04, 24 July 2026 (UTC)

Here's a rundown of what each is supposed to do:

Option A: Hides part of each decline reason whilst showing them on a bulleted list.

Option B: Hides all reasons in collapsibles, which can be expanded to show them in their entirety.

Option C: Hides part of each decline reason whilst keeping them in separate boxes. (I'm not sure why it isn't showing the WP:NBIO-based reason)

Option D: Hides all declines (except the latest one) in a collapsible that can be expanded to show them all.

– MrPersonHumanGuy (talk) 21:56, 24 July 2026 (UTC)

Do we need an RFC? Is there a reason we can't just come to a consensus? Primefac (talk) 21:33, 24 July 2026 (UTC)

aaaaaand you already started one. Two things: first, if you're going to ask for opinions to get a consensus, wait for the bloody consensus to form. Second, please don't ping people multiple times in the same thread, especially if they've already commented, replied, and (in my case in particular) is one of the primary maintainers of the project. Primefac (talk) 21:40, 24 July 2026 (UTC)

RfC: Condensing or collapsing decline notices (except for the latest one on each draft)

I've been workshopping an option list for this RfC discussion a moment ago and settled on the version of the list that now appears below. Each of the first four options describes a specific proposal for condensing or collapsing draft decline notices (except for the latest one on each draft), and each of these four entries is accompanied by a collapsible box containing an example of how these proposals may look in action. Although essential, all that content was too much to be displayed at the RfC listing page, so I've expanded the paragraph above it and made it its own comment. – MrPersonHumanGuy (talk) 10:10, 25 July 2026 (UTC)

• Option A: Condense declines (except for the latest one) into a bulleted list below the latest decline like this:

Example of Option A

Full list of condensed messages

• neo – This draft's references do not show that the neologism meets Wikipedia's criteria for inclusion.
• web – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for web content.
• prof/academic – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for academics.
• athlete/sport – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for sports.
• music/m/band – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for music.
• film – This draft's references do not show that the film meets Wikipedia's criteria for inclusion for films.
• book – This draft's references do not show that the book meets Wikipedia's criteria for inclusion for books.
• event – This draft's references do not show that the event meets Wikipedia's criteria for inclusion for events.
• corp/inc/org – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for organizations and companies.
• bio – This draft's references do not show that the person meets Wikipedia's criteria for inclusion for people.
• nn – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion.
• list – This draft's references do not show the list meets Wikipedia's criteria for inclusion for stand-alone lists.
• med – This draft contains medical, health, or psychological claims. Wikipedia requires a higher standard of sourcing for biomedical content.
• geo – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for geographic features.
• species – This draft's references do not show that the species meets Wikipedia's criteria for inclusion for species.
• astro – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for astronomical objects.
• number – This draft's references do not show that the number meets Wikipedia's criteria for inclusion for numbers.
• creative – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for creative professionals.
• school – This draft's references do not show that the subject meets Wikipedia's criteria for inclusion for schools.
• cat – This is not the correct place to request new categories.
• empty/blank – This draft appears to be blank.
• lang|languagenotenglish|language – This draft is written in language.
• test – This draft appears to be a test edit.
• redirect – This is not the correct place to request new redirects.
• van – This draft has been declined because it meets one of the criteria for an attack page, a negative biography, or vandalism.
• ilc – This draft lacks inline citations.
• blp – The text of this submission has been removed. Wikipedia has a strict policy regarding biographies of living people.
• cvcv-n – This draft appears to contain copyrighted material which has been removed.
• cv|Website/cv-n|Website – This draft appears to contain copyrighted material from Website, which has been removed.
• source/v/rs – This draft is not adequately supported by reliable sources.
• not – This draft is not suitable for Wikipedia.
• news/oneevent – This draft appears to be a news report or about a single event.
• dict/d – This draft appears to be a dictionary definition.
• plot – This draft appears to be a plot summary.
• joke – This draft appears to be a joke or a hoax.
• ai/llm – This draft appears to contain text generated by a large language model (such as ChatGPT).
• resume – This draft reads like a resume or curriculum vitae.
• ecr – This draft covers a contentious topic with an editing restriction.
• nosource – This draft does not include any sources or inline citations.
• essay – This draft reads like an essay or opinion piece.
• npov – This draft is not written from a neutral point of view.
• advert/spam/adv – This draft reads like an advertisement.
• exists – This draft appears to be a duplicate of an existing article.
• duplicate/dup – This draft duplicates another submission currently submitted for review.
• duplicate|Title/dup|Title – This draft duplicates another submission, Title, currently submitted for review.
• context – This draft provides insufficient context for those unfamiliar with the subject.
• mergeto/merge – This draft does not have sufficient content to warrant a standalone article of its own, but it could be merged into the existing article on the same subject.
• mergeto|Pagename/merge|Pagename – This draft does not have sufficient content to warrant a standalone article of its own, but it could be merged into the existing article at '''Pagename'''.
• reason|Reason – Reason

• Option B: Collapse declines (except for the latest one) in a similar fashion to {{Wikiproject banner shell}} like this:

Example of Option B

This is a rough conceptual design, as I don't know how to replicate {{WikiProject banner shell}} perfectly.

• Option C: Primefac's idea for condensing declines:

Example of Option C

• Option D: Put the declines (except for the latest one) below a banner that collapses them: (a template with this exact approach was recently deleted)

Example of Option D

• Option E: A different idea. (please try to describe what you would want instead)
• Option F: No changes; maintain the status quo.

Which of these options do you think would be best? – MrPersonHumanGuy (talk) 18:01, 24 July 2026 (UTC)

Courteously pinging Mattdaviesfsic, ChrysGalley (who supported B, was okay with A, and said F wasn't so bad either), NeoGaze, Primefac, KylieTastic, and Qcne, all of who I discussed these ideas with. – MrPersonHumanGuy (talk) 18:07, 24 July 2026 (UTC)

In hindsight, that may not have been necessary.  Self-trout – MrPersonHumanGuy (talk) 21:42, 24 July 2026 (UTC)

Discussion

Support B, this condenses the information but still allows users to go back and find links or prior advice they may find useful, and I think it preserves the message of the original declines the most faithfully. I like that it keeps the icons and stop signs respectively as well. Bobby Cohn 🍁 (talk) 19:03, 24 July 2026 (UTC)

(invited by the bot but I'm a NPP'er and occasionel AFC reviewer) I don't have the detailed knowledge on this minor formatting issue to have an opinion. I'd support anthing that would make even minor improvements. But I'm using this opportunity for a suggestion which addresses a big problem which is declining articles for reasons which are not in the official criteria to decline an article. Which is the official criteria that it is unlikely to survive an AFD. So my proposal is that declines should include an explanation on why the reviewer feels that it would not survive an AFD. (which usually means not meeting wp:notability criteria) Sincerely, North8000 (talk) 20:29, 24 July 2026 (UTC)

If using custom for a decline reason becomes problematic, we might have to remove it, but if you see completely invalid decline reasons (and the draft hasn't been edited since) feel free to revert those declines; I do it from time to time when it's brought to my attention. Primefac (talk) 21:59, 24 July 2026 (UTC)

The typical case is rejecting for article quality / development issues rather than projected survibability at AFD. And my quess is that the main two reasons are not knowing the AFC criteria or being afraid to pass an article which has quality/devlopment issues but which would probably survive at AFD. Sincerely, North8000 (talk) 23:07, 24 July 2026 (UTC)

Yes, we are notoriously bad at not accepting borderline drafts, and we have to remind folk every few years that it's perfectly acceptable to do so. Primefac (talk) 23:11, 24 July 2026 (UTC)

Just noting that I have updated Option C, and I haven't coded a "reject" small version which is why they're blank. Primefac (talk) 21:58, 24 July 2026 (UTC)

• Support B-prime (unless you want to call this an 'E', in which case I can mock it up above, based on B). What I mean by B-prime is the look-and-feel of B, but with the sections in chronological order, just as they would be on the user talk page as things are now. That is what users are used to on Talk pages, and B(no prime) might be the sole exception to that, leading to possible confusion, especially for newbies. (Summoned by bot) Mathglot (talk) 00:26, 25 July 2026 (UTC)

  @Mathglot: With the B-prime format, should the latest decline be on the bottom instead of the top? – MrPersonHumanGuy (talk) 02:03, 25 July 2026 (UTC)

  I don't know what Mathglot intends, personally I think it should be kept on top, in a position most likely to be seen first, as the latest decline would be the most relevant. Mitchsavl (talk) 02:41, 25 July 2026 (UTC)

  I was trying to stay open to both possibilities, but personally, I think the big, expanded, latest status should be on top (the way a Talk header is on top of the talk page, even if recent or modified) and all the previous declines smaller, collapsed, and in chrono order, oldest first. So, agreeing with MMitchsavl. Thank you for requesting that clarification. Mathglot (talk) 03:25, 25 July 2026 (UTC)

  I disagree with having the collapsed order go from oldest first. Reviewers should be able to see the progress made between declines, so having them ordered newest-to-oldest makes sure that the most relevant ones are seen first, and the oldest, less relevant ones are listed last. In many cases, a draft's earliest declines are completely irrelevant (e.g. "blank" or "not english"). In solidarity, nil ^nz 05:54, 25 July 2026 (UTC)

  Nil NZ, do you also support ordering a Talk page with the most recent section at the top, and older ones below it? Wouldn't the most recent sections on the Talk page also be the most relevant? In B-prime, you'd see the progress made from one decline to another just by reading down, the way we always do in English text. With option B, you have to read upwards from the bottom to see the progress, right? Mathglot (talk) 08:33, 25 July 2026 (UTC)

  It's not a talk page or "discussion" thread though, so I don't think it's entirely comparable as an example. A counter example would be edit histories (or any other change log really), in which we put the most recent revisions at the top.

  When reviewing, we're wanting to know what's changed since the most recent previous declines, not progress since the draft's creation. Having to read up from the bottom is just an extra inconvenience by burying the lede, so to speak. In solidarity, nil ^nz 09:37, 25 July 2026 (UTC)

Support A or B (via Feedback request service): These options minimises unnecessary repetition of information. On drafts, I have seen comments left just below the notices about issues where a more detailed explanation is needed, and on the off chance that an editor needs to see the full notices, they can either look up the template or search the draft page history. I think the template could be structured similar to {{multiple issues}}, or have a structure as follows:
{{decline top}}
{{AfC submission|D|reason|multiple=yes}}
{{decline bottom}}

Building it out of multiple templates effectively means that an infinite set of parameters (or a Lua module) is not required to account for every possibility.

Mitchsavl (talk) 01:37, 25 July 2026 (UTC)

• Support B (Summoned by bot) per Bobby Cohn's argument. TarnishedPath^talk 02:53, 25 July 2026 (UTC)
• Support A (first choice), B (second choice). The neater, the better, though there is something to be said for not diminishing attention to numerous previous declines. BD2412 T 03:12, 25 July 2026 (UTC)
• Support B Started from the recent decline up to the previous declines, all are detailed, plus the icons and stop signs when a draft gets rejected and the font size, the style, it has AfC vibe over it. (Summoned by bot) CONFUSED SPIRIT(Thilio).Talk 04:05, 25 July 2026 (UTC)
• Support A or C, but honestly any of these would probably be fine. Making it more compact is nice, but I do like being able to see at a glance (i.e. without pressing buttons) what the previous decline reasons were. LittlePuppers (talk) 08:02, 25 July 2026 (UTC)

  Additional thoughts: thanks CaptainEek for making me notice, it would be nice if we had something where there was a short decline reason (as I mentioned initially; selfishly, I just want enough for me to be able to tell the reason at a glance), but it would also be good if it could be expanded. So... kind of option E? I really do like the layout of A, though. Unfortunately, I can't think of a good way to make that design expandable. LittlePuppers (talk) 02:08, 26 July 2026 (UTC)

  Support E, as upon reflection and discussion it's become increasingly clear that this could use more iteration. It appears that short descriptions while collapsed and the ability to expand to the full description are both widely wanted (or perhaps I'm just projectecting my opinions), and no current option has both those features. LittlePuppers (talk) 19:24, 26 July 2026 (UTC)

• Option A>D>B. I agree with LittlePuppers, that as a reviewer, I'd like to see the previous decline reasons instantly, instead of having to open them manually. I'm fine with option B as long as AFCH automatically opens them. Kovcszaln6 (talk) 08:15, 25 July 2026 (UTC)
• @MrPersonHumanGuy: what is your brief and neutral statement? At over seventeen thousand bytes, the statement above (from the {{rfc}} tag to the next timestamp) is far too long for Legobot (talk · contribs) to handle, and so it is not being shown correctly at Wikipedia:Requests for comment/Wikipedia proposals. It also contains complex formatting, such as the table, the collapsible sections and other boxes. --Redrose64 🌹 (talk) 09:53, 25 July 2026 (UTC)

  Thank you for adding one. --Redrose64 🌹 (talk) 10:38, 25 July 2026 (UTC)

• Oppose B and D As a reviewer, it must be possible to instantly see the abbreviated decline reasons. If I have to suddenly click a button to expand previous declines, that makes my life harder. Oppose A and C The drafter needs to be able to see and read full past declines. Support E I would support a modified option B if it showed an abbreviated decline reason without having to click expand. E.g., "Submission declined on 3 August 2025 by MCE89 (talk). Reason: Biographical notability not established." (or some other abbreviation of the reason). CaptainEek ^{Edits Ho Cap'n!}⚓ 19:17, 25 July 2026 (UTC)

  CaptainEek, out of curiosity, what about Option C doesn't show the decline reason? The decline rationale is exactly the same as when |small= is not used, the only difference being it cuts out the "what does that mean" text (it literally just noincludes the bullet points). (please do not ping on reply) Primefac (talk) 20:12, 25 July 2026 (UTC)

  Hmmm, I was wondering how exactly you were truncating it. That's interesting. But I still think that removing the explanation does the drafter a disservice? Like, they're going to ask "where'd that explanation go." Explaining what it means is most important to the drafter. Again, fine with it being collapsed, but the drafter should be able to access it somehow. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:18, 25 July 2026 (UTC)

  Ah, a fair point, and something I hadn't considered. Thanks. Primefac (talk) 20:49, 25 July 2026 (UTC)

• Support A>C>B I too would prefer the previous reasons to be auto-expanded, but at least B gives us a succinct summary without clicking/tapping, which D does not. —ClaudineChionh (she/her · talk · email) 01:21, 26 July 2026 (UTC)
• Support A>C>F. Oppose B&D. Per LittlePuppers/Kovcszaln6/Claudine (and also CaptainEek to an extent). In solidarity, nil ^nz 01:40, 26 July 2026 (UTC)
• comment I object to this RFC as rushed before the options were fully explored. Was Primefac even given chance to agree that was what they were proposing? I think every version has tweaks that could make them better options, so rushing this is just ending up with a pick the least worse option. KylieTastic (talk) 10:00, 26 July 2026 (UTC)

  I was not, though I opined on that matter in the earlier thread. There was no agreement to do anything when this was started. Primefac (talk) 18:44, 26 July 2026 (UTC)

• Support E (as a B+) which is B where the short reason the same as A gives the basic reason and link. A has the problem that it does not allow the submitter to open and see the fuller reasons. C has removed useful info/links with no show - but kept large icons and too much space. I do think an option just to reduce the small versions we have now exists but not in this form. D needs the show option to be inside the notice and more than just show as it's very un-obvious especially to new editors. KylieTastic (talk) 10:00, 26 July 2026 (UTC)

  The reason Option D shows the show option below the banner is because I don't know how to design it so it would be inside the banner while the content it shows would be below the banner. I can make visual representations of how such a desired template should appear in collapsed and expanded states, but I don't know how to design a working version of such a thing. – MrPersonHumanGuy (talk) 10:33, 26 July 2026 (UTC)

• B or D I personally don't mind clicking a button to show the decline(s) but I want to be able to see the full rationale, which is why I don't really like A (oppose). Furthermore most drafts I come across don't have more than two declines so I don't think it is unreasonable to click to view them. I like B's superior overview which is why I'd prefer B over D but I'm happy with both Squawk7700 (talk) 21:38, 26 July 2026 (UTC)

Non-reviewers commenting on drafts

Wikipedia:WikiProject Articles for creation/Participants states that "Editors whose usernames are not on the list are strongly cautioned not to review AfC submissions", which is sensible advice for multiple reasons, but how does the project feel about comments from non-reviewers? Does the project consider it appropriate for a non-reviewer to add relevant commentary to a draft submission using Template:AfC comment? I ask, because I've done this on a few occasions. I'm not interested in signing up as a reviewer (I'd easily meet the criteria), but I do sometimes notice relevant issues with drafts, which a reviewer may not necessarily otherwise be aware of. AndyTheGrump (talk) 15:16, 20 July 2026 (UTC)

No issues from my point of view. qcne (talk) 15:17, 20 July 2026 (UTC)

Likewise Cheerio, Mattdaviesfsic. Talk to me. 15:24, 20 July 2026 (UTC)

No issue that I can see. Sure some individuals could give bad advice on drafts, but they can on any forum — so that's no reason to discourage the majority from helping. It would be good if non-reviewers who enabled the AFCH tool got access to the AfC comment option (I assume it does not do that). KylieTastic (talk) 15:40, 20 July 2026 (UTC)

When I manually left comments at Draft:Carl Azuz to explain the draft's situation, I appended (Non-reviewer comment) at the end of each comment to remind people that I'm not an AfC reviewer. – MrPersonHumanGuy (talk) 18:03, 20 July 2026 (UTC)

• I think it's very helpful. I personally think it wouldn't be a bad way for those not-quite-ready for AFC, maybe just outside the criteria, to contribute / learn the ropes. If you are in the AFC logic then a reviewer should be easily able to detach themselves from any comment which is wide of the mark. The {non-reviewer} pseudo-tag I guess takes it beyond criticism. ChrysGalley (talk) 21:14, 20 July 2026 (UTC)
• I see no harm that can be done by experienced editors who are not reviewers commenting on drafts, and there is likely to be some benefit. For that matter, I see no harm that can be done by inexperienced editors who are not reviewers commenting on drafts. The worst that can happen is that the comment may be wrong, but in that case the reviewer can explain why they disagree with the comment. Welcome to commenting. Robert McClenon (talk) 19:03, 21 July 2026 (UTC)

As a non-reviewer, I very occasionally use {{AfC comment}} to add a comment to a draft (e.g., diff). As a corollary, when I have more extensive comments, I leave them on the Draft talk page instead (e.g., here). I presume that reviewers check the Talk page as well, but I'm not really sure. (Note: I don't want to hijack this thread, so if responders feel it's worth it, we can start a subsection (or section) about this.) Mathglot (talk) 19:19, 26 July 2026 (UTC)

Missing Reflist

I am reviewing a draft, and I see the message: The submission contains <ref> tags, but has no references list! You may not see all references.. It does have four references at the bottom. There is a References heading, which is the end of the text in the document, but it is followed by the references in viewing the draft. I am inferring that the references are being displayed by default as if there was a {{Reflist}}. Am I also correct in inferring that the best practice is that I should insert a {{Reflist}} at the end of the draft? Robert McClenon (talk) 19:08, 21 July 2026 (UTC)

Generally, yes. A lot of very new editors don't realize they need to add it because if the References header is the last in the article, the individual references do appear in ~roughly the correct spot. ScalarFactor (talk) 21:10, 21 July 2026 (UTC)

This can be resolved with TheJJJunk's ARA tool - User:TheJJJunk/Automatic Referencing Assistant. Highly recommended to find things like these. Cheerio, Mattdaviesfsic. Talk to me. 23:29, 21 July 2026 (UTC)

Factual Errors in Drafts

This question is about what I should do if I am reviewing a draft and that draft has factual errors. I am aware that there are at least two cases, the general case and the special case. On analysis, I realize that there are several cases. One simple case is where the reviewer knows what should be in the draft. The answer then is obviously to correct the draft, and then do one of: (1) accept the draft; (2) decline the draft for another reason; (3) leave the corrected draft for another reviewer.

Another simple case is where there is a factual error, and the reviewer does not know what should be in the draft, but the draft should be declined. In that case, the reviewer should include a note about the error in addition to the decline code, and should make it clear that there are two issues to be addressed.

What should I do if I am not ready to accept or decline the draft? Should I leave a comment, and leave the draft waiting for review, or should I decline the draft in order to get the author's attention? If I should decline it, what decline code should I use? I don't see a decline code that has to do with factual errors. If I leave a comment in a draft, the author is told only that there is a comment in the draft. The content of the comment is not passed through to the user talk page.

What should I do if I think that the draft is otherwise ready for acceptance, but that there are errors? Should I leave a comment in the draft, or should I decline the draft with a comment? There isn't a decline code that has to do with errors.

Just for clarification, I am asking about drafts where the reviewer think that the draft at least might be a reasonable article, not about drafts that are run-of-the-mill and unlikely to be accepted in the near future. Robert McClenon (talk) 19:55, 23 July 2026 (UTC)

I'm not sure how to answer your question. there is a factual error, and the reviewer does not know what should be in the draft -- how is a reviewer supposed to know what they don't know? How would they know if there is an error if they don't know it's there?

In a very hand-wavey sense, I would say that an error or two by itself should not fail a draft, just like ilc (lack of inline citations) should almost never be used by itself. If the error is noticed and can easily be corrected (i.e. the "right" information is in the references) then the reviewer should do that, otherwise it should be removed (unless the reviewer knows it's "wrong" but doesn't know the "right" information in which case an AFC comment might be appropriate). Primefac (talk) 22:05, 23 July 2026 (UTC)

An example that is wrong without knowing the right answer would be, in a list of state legislators, a politician who is from another state, or a person whose BLP is not that of a politician. There can be cases where the reviewer could figure it out, if the author forgot to add {Maryland politician} after the name, but I am asking in general. Robert McClenon (talk) 00:23, 24 July 2026 (UTC)

One reason that I might decline a draft for an error is that the author might be able to correct the error sooner than leaving the article for normal editing. Robert McClenon (talk) 00:23, 24 July 2026 (UTC)

The draft in question is Draft:120th United States Congress. It has a few names listed for the United States House of Representatives. That is wrong, because those seats should be TBD like the rest of the House. My thinking is that this error shows sloppy preparation. I think that errors that show sloppy preparation should sometimes be declined to give the author a chance to do more research and resubmit. Robert McClenon (talk) 00:59, 24 July 2026 (UTC)

I declined the draft for -v- because there was no source given for the names. There usually isn't a reliable source for incorrect information. Robert McClenon (talk) 03:09, 24 July 2026 (UTC)

Erroneous election results and fictional election results are two different problems. Fictional election results are sent to MFD and deleted. Robert McClenon (talk) 03:09, 24 July 2026 (UTC)

• I would go by materiality: if the error would undermine the article's overall credibility then it's at least a -v- decline, or even -nn-. But if it's a silly copy/paste mistake of some incidental fact, then tag or delete; declining if BLP and the shortfalls are problematic. However I know you are aware of the hit-and-run AFC submissions by a TA: so someone is working on the draft, yes there are factual errors simply because the editor hasn't finished their drafting work yet. Then some random TA / new user comes along and submits the unready draft for AFC despite contributing nothing more than press the blue submit button. Happened to one of my own drafts yesterday (it was approved, "warts and all", and there were plenty of warts).ChrysGalley (talk) 11:14, 24 July 2026 (UTC)

  I know it's not the point of this thread, but just to say that a TA or new user submitting someone else's draft out of the blue is a bit of a red flag, and it may be worth looking at their other edits. There's at least one serial-socking LTA whose MO includes submitting pending drafts (as well as making large numbers of dummy/minor edits). -- DoubleGrazing (talk) 11:31, 24 July 2026 (UTC)

  @DoubleGrazing - yes I am watching and waiting. It's Youth bulge theory and Thehenrygreen in this case, but I can't point to anything at the moment. ChrysGalley (talk) 11:39, 24 July 2026 (UTC)

Message to Be Ignored

I marked a draft as being reviewed. Then the display of the draft said A reviewer is in the process of reviewing this submission. Don’t edit the draft.

Duh. That means don't edit the draft unless you are the reviewer. Robert McClenon (talk) 00:52, 24 July 2026 (UTC)

Was there an issue with someone ignoring the message? In solidarity, nil ^nz 03:43, 24 July 2026 (UTC)

I see you marked three as under review this month, none of these were edited while under review? KylieTastic (talk) 09:36, 24 July 2026 (UTC)

No. I am just complaining that a new reviewer might misunderstand the message. Robert McClenon (talk) 17:09, 29 July 2026 (UTC)

I really hope not, that would apply to any such notice such as {{In use}}. If someone puts up a notice saying please leave alone, then thinks it means them they probably just need to take a break. This is not even WP specific, we have many such signs in real life. I have never seen a sign on a door saying "Cleaning in progress, keep out (unless you are the cleaner)". However, maybe you have finally found the reason for slow roadwork progress.... maybe some of the workers see the sign "Road closed" and think damn, I really needed to get down there to fix the road! KylieTastic (talk) 18:45, 29 July 2026 (UTC)

Deceased member

Hello. Would you please unsubscribe deceased User:Gobonobo from your future notifications? Sorry I am unable to find the right way to do that. Thank you. -SusanLesch (talk) 20:00, 24 July 2026 (UTC)

They have nothing to do with this project? Special:Diff/1365695224 should deal with most of it though. Primefac (talk) 21:45, 24 July 2026 (UTC)

Thank you, yes I hope the nobots tag will help. I wrote to you because he received your backlog drive notice. -SusanLesch (talk) 22:50, 24 July 2026 (UTC)

It would have been because he had the NPP user right at the time the message was sent. Voorts has since removed their extended rights, so shouldn't be an issue for the future. In solidarity, nil ^nz 06:04, 25 July 2026 (UTC)

Thank you, Nil. -SusanLesch (talk) 11:43, 25 July 2026 (UTC)

Requesting feedback on an improved AfC draft

Hello everyone! I recently made substantial improvements to my Articles for Creation draft and would really appreciate any feedback before it is reviewed. I addressed the concerns raised in previous reviews by adding significantly more independent reliable sources, reducing promotional language, reorganizing the article, improving citation quality, trimming unnecessary detail, and aligning the draft more closely with Wikipedia's sourcing and neutrality policies. If anyone has time to take a look, I'd be grateful for any suggestions on remaining issues related to sourcing, neutrality, notability, formatting, or AfC expectations before a reviewer evaluates it. Draft: https://en.wikipedia.org/wiki/Draft:Adrian_Hadribeaj. Thank you! Pulseoraus (talk) 00:18, 25 July 2026 (UTC)

The article is already submitted for review. Also, please post the questions to the WP:AFCHD help desk instead. Sulfurboy (talk) 05:59, 25 July 2026 (UTC)

Okay, thank you so much for everything.

~~ Pulseoraus (talk) 06:01, 25 July 2026 (UTC)

Rewriting a draft

I ran across a draft a few days ago which is almost certainly notable, but was declined for LLM (and other small issues, both consequent and unrelated). The author hasn't come back (so, to be blunt, probably won't), but I don't think it would take me long to rewrite it into something short but serviceable.

So my question is (after rewriting): am I better off using AFCH to accept it, or just removing all the AFC templates and moving it to mainspace? Does it matter? LittlePuppers (talk) 08:12, 25 July 2026 (UTC)

It doesn't really matter, AFC is not mandatory and if you're comfortable with your rewrite there's no point in waiting for someone to review it. Primefac (talk) 10:01, 25 July 2026 (UTC)

Sorry if I wasn't clear, I wasn't intending to put it up for review, just rewrite it in draft and then move or accept it myself. LittlePuppers (talk) 18:35, 25 July 2026 (UTC)

Either should be fine if you have a preferred workflow. Publishing it via AfC, particularly with the script would help better retain relevant info to the draft process of the article, if you think it's relevant. Sulfurboy (talk) 18:41, 25 July 2026 (UTC)

I'm trying to figure out if it is relevant :). Probably, I suppose. LittlePuppers (talk) 18:42, 25 July 2026 (UTC)

You haven't told/linked us to the draft, so I can't assess. But if you have any doubts just do it through AfC script. Point being ultimately be WP:BOLD and just do one or the other. Neither options is going to get you in trouble or anything like that. Sulfurboy (talk) 10:31, 26 July 2026 (UTC)

Agree. Just wanted to add that avoiding trouble is not the top consideration here. Improving the encyclopedia and maintaining its quality are. So, yeah, BOLD is fine, but as you said, in case of doubt, go through AfC. (Also agree that the OP should always link the article they are asking about.) Mathglot (talk) 19:30, 26 July 2026 (UTC)

Sorry, sorry :). It's Draft:Samarendra Nath Ghoshal. (That said, the same thought has crossed my mind regarding other articles in the past. I don't recall if I've ever done a full rewite from a draft though.) LittlePuppers (talk) 19:36, 26 July 2026 (UTC)

I certainly remember that draft, it was a real why-oh-why moment. The subject has presumed notability in my opinion, so even a basic set of sourcing for those components should get the article going, and once in mainspace there will be more chance of improvement than in draft. So I would say push to mainspace, unless you particularly value another AFC round. ChrysGalley (talk) 21:13, 26 July 2026 (UTC)

Okay, I got around to a quick (less quick than I anticipated, naturally) rewrite, overcited it, and pushed it to main, where I have some more work to do on it. LittlePuppers (talk) 22:40, 26 July 2026 (UTC)

Decline question

Why my wiki for Draft:Meitantei Precure! The Movie: The Mysterious Garden And The Secret Of The Two always got declined? — Preceding unsigned comment added by CureSeashine (talk • contribs)

hey! How can i made a post in Talk Page? CureSeashine (talk) 19:38, 26 July 2026 (UTC)

You just posted to this talk page. What talk page are you trying to edit? 331dot (talk) 19:50, 26 July 2026 (UTC)

yes i wanna submit a question regarding my wikipedia abot Meitantei Precure Movie as it was declined the draft CureSeashine (talk) 19:52, 26 July 2026 (UTC)

You can do so at WP:AFCHD Sulfurboy (talk) 19:54, 26 July 2026 (UTC)

You should post at main AFC help desk. 331dot (talk) 19:55, 26 July 2026 (UTC)

Sulfurboy also replied to the post you made on his talk page. LittlePuppers (talk) 19:56, 26 July 2026 (UTC)

Changing the AI decline notice

The current text is as follows;

This draft appears to contain text generated by a large language model (such as ChatGPT). You cannot use LLMs to generate article content.

LLM-generated pages with certain obvious signs of being machine generated may be deleted without notice.

These tools are prone to specific issues that violate our policies:

• hallucinations: they often invent false information and cite non-existent references.
• unencyclopedic tone: they tend to be vague, promotional, or essay-like, rather than neutral and factual.
• copyright issues: they may closely paraphrase existing text, leading to copyright violations.

Instead, only summarize in your own words a range of independent, reliable, published sources that discuss the subject.

See the advice page on large language models for more information.

The section beginning These tools are prone to specific issues that violate our policies is misleading, as it implies that LLM-generated text which does not contain these issues may be acceptable. In any case it's unnecessary; we don't need to give people a screed on why LLM generated text is bad, the only part which is relevant to their article being declined is that it's not allowed. Let's keep it short and sweet and minimise the room for misinterpretation (especially because AI chatbots love to misinterpret this kind of wiggle-room and whisper like Grima Wormtongue into their users' ears that AI usage is okay if it doesn't have these issues.) Athanelar (talk) 05:59, 27 July 2026 (UTC)

I agree. I have had pushback on that on my Talk page, since the LLM editor then says "there's nothing hallucinated here, I've checked everything." One editor wrote (paraphrasing), "OK, so yes I used LLM, but you are asking me to do a rewrite for a rewrite's sake, since all the sources and text wording are OK?" The answer is yes. But because the decline focuses on what could go wrong, a mini justification on our stance about LLM, it's actually not the point: the point is LLM is against Wikipedia's policies and guidelines, just like many other issues: copyright, non neutral text, unsourced. By all means give a one line link to the justification, but I don't see the point in deflecting off the core point, which is that LLM is not allowed. ChrysGalley (talk) 07:11, 27 July 2026 (UTC)

Colons are still added to categories with sort keys inside {{Draft categories}}

Tracked in github.com
Issue #472
Resolved

It appears that colons are still added to categories with sort keys inside {{Draft categories}}, even though Issue #256 has been fixed.

Examples:

• https://en.wikipedia.org/w/index.php?title=Draft:Bids_for_the_2040_Summer_Olympics&diff=prev&oldid=1366400226
• https://en.wikipedia.org/w/index.php?title=Draft:Sandbox&diff=prev&oldid=1366402333

GTrang (talk) 23:28, 27 July 2026 (UTC)

I have updated the ticket but I suspect this is a change in MediaWiki software behaviour. If there is nothing after the {{Draft categories}} apart from white-space it is trimmed. The current AFCH clean function assumes there will be a newline directly after which is very odd as it would also fail if there was a space before the newline even if other stuff after. KylieTastic (talk) 09:54, 28 July 2026 (UTC)

I think ive got unit tests for this. A dev can just add the bug as a test case, then tweak the algorithm or use AI to tweak the algorithm until the tests pass. –Novem Linguae (talk) 13:29, 28 July 2026 (UTC)

I keep meaning to get things setup so I can knock down some issues.... maybe one day I'll find time. KylieTastic (talk) 14:17, 28 July 2026 (UTC)

Meant to get to this earlier today, a little late for me to get to it now, but it's straight-forward enough (and I agree with Kylie's assessment of the issue) I should be able to bash this out in the next day or two. Primefac (talk) 22:58, 28 July 2026 (UTC)

Discussion at MediaWiki talk:Gadget-afchelper.js

I recently created a discussion at MediaWiki talk:Gadget-afchelper.js about whether to use "wikicode syntax" or "wikitext" in the AfC Helper gadget, and was recommended to mention it here. Feel free to participate in the discussion. Axolitl (talk | contribs) 22:51, 28 July 2026 (UTC)

Can an admin take a look at this?

Wondering if this is a little suspicious or just me..Draft:Sylvester Abanteriba was created by now blocked user User:InsightBuilder, since then there have been a couple edits and a resubmission by anonymous users which seems a bit suss for a relatively unknown draft. Am I reading in to this too much? Would it be worthy of an SPI matter or is there a more efficient way of handling it? Also it seems that some of the edits came after the ban (not sure how that's possible), if that's the case maybe just G5? Sulfurboy (talk) 05:12, 29 July 2026 (UTC)

User is a sock (now blocked), page nuked. Good catch. Primefac (talk) 08:52, 29 July 2026 (UTC)

Is User:Herrrybuilder part of that drawer? Both IB and Hb overlap with the same TA at some of the same drafts. And if IB is a sock of an account with "Henry" in it, then Hb's account-name is a portmanteau of them. DMacks (talk) 09:04, 29 July 2026 (UTC)

Yes. If there isn't yet an SPI, there probably should be one, if only to track these better. Primefac (talk) 09:15, 29 July 2026 (UTC)

It isn't a sock-farm I recognize and didn't see any user-page or block-log tags pointing to one either. I can SPI it later today, but it would be mostly pro-forma for you people (waves hand generally at CU and Sulfurboy) to fill in details. DMacks (talk) 13:48, 29 July 2026 (UTC)

Wikipedia:Sockpuppet investigations/Harry james Kh DMacks (talk) 23:25, 30 July 2026 (UTC)

Thanks for this. I'm pretty green with SPI stuff, and you for sure put together way more info than I could have. Sulfurboy (talk) 01:20, 31 July 2026 (UTC)

Thanks for the initial report. Interesting how a few editors each have their own small piece that isn't recognized as being a unified puzzle picture until later. Special goggles help, but only if the wearer even knows where to start looking. DMacks (talk) 01:26, 31 July 2026 (UTC)

Backlog Drive

Am I correct that the backlog drive begins at 0001 GMT, 1 August 2026? (I think that is about 20.5 hours, but that is not the question.) Robert McClenon (talk) 03:25, 31 July 2026 (UTC)

Correct! (~15 hours from now) In solidarity, nil ^nz 08:50, 31 July 2026 (UTC)

Unless otherwise specified to be different all datetimes quoted on Wikipedia should be taken as UTC times. So actually it would start from 00:00 UTC, 1 August 2026. KylieTastic (talk) 08:53, 31 July 2026 (UTC)

Leaderboard for Backlog Drive ?

Can someone please explain how the leaderboard for the August backlog drive was working at about 0720 GMT, 31 July 2026, when 18 reviewers had non-zero scores? Robert McClenon (talk) 07:21, 31 July 2026 (UTC)

It would have been the bot firing early (probably a test?) during set up – it has since reset the leaderboard in preparation for tomorrow :) In solidarity, nil ^nz 08:47, 31 July 2026 (UTC)

It just looks like Bunnypranav was just getting thing just setup for BunnysBot to work. Yes there appeared to be a bug, or mis-configuration for the first run but that was fixed. KylieTastic (talk) 08:48, 31 July 2026 (UTC)

Yeah the bot initially took the starting date as some time in the middle of July, hence the non-zero scores. Should be fixed now. Please do ping me if anyone spots such irregularities, even later into the drive. ~/Bunnypranav:<ping> 09:33, 31 July 2026 (UTC)

@Bunnypranav It looks like the bot updated it again at 12:01 UTC with more users at non-zero scores. 🌀Hurricane Wind and Fire, why did you decline my draft? (talk) (contribs)🔥 13:47, 31 July 2026 (UTC)

Looks like the starting date was from the start of today rather than tomorrow. (subject link: Wikipedia:WikiProject Articles for creation/August 2026 Backlog Drive/Leaderboard). KylieTastic (talk) 14:51, 31 July 2026 (UTC)

Thanks for informing. I think me starting the scheduled run before Aug might be the reason. I will start the run sometime tomorrow after UTC changes the month, hopefully should fix issues without causing any inconvenience to the users as well. ~/Bunnypranav:<ping> 16:05, 31 July 2026 (UTC)

How often does the bot update the leaderboard? Robert McClenon (talk) 03:45, 1 August 2026 (UTC)

@Robert McClenon It updated every six hours for the December drive so I assume it's the same this time? 🌀Hurricane Wind and Fire, why did you decline my draft? (talk) (contribs)🔥 03:48, 1 August 2026 (UTC)

Yup, six hours again this time around In solidarity, nil ^nz 05:07, 1 August 2026 (UTC)

Is there a hashtag for the month? Mme Maigret (talk) 04:53, 1 August 2026 (UTC)

No hashtag; AFC accepts/declines are already recorded, so the bot is able to track them without one. In solidarity, nil ^nz 05:07, 1 August 2026 (UTC)

Needs WikiProjects ?

I accepted a draft in which either the originator or a previous reviewer had provided categories, so I didn't need to tag Improve Categories. But it didn't have any WikiProjects, and I didn't know what the right WikiProjects should be. If I accept a draft that needs better categories and better WikiProjects, then I can tag it to Improve Categories, and figure that the category gnome will also assign the projects. But how do I tag a newly accepted article that has categories but needs to be assigned to projects? Robert McClenon (talk) 00:42, 1 August 2026 (UTC)

As far as I am aware, there is no way to do this. In solidarity, asilvering (talk) 04:04, 1 August 2026 (UTC)

@Robert McClenon just do it yourself with WP:RATER. If you don't know exactly, my go to strat is to pull up an existing article about a similar topic and see what projects it's in. CaptainEek ^{Edits Ho Cap'n!}⚓ 06:53, 1 August 2026 (UTC)