Jump to content

Wikipedia:Village pump (policy)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Joe Roe (talk | contribs) at 10:03, 24 March 2022 (Ban draftifying articles more than 30 days old: Removed markup interfering with the archive template). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines.

Please see this FAQ page for a list of frequently rejected or ignored proposals. Discussions are automatically archived after remaining inactive for two weeks.



Ban draftifying articles more than 30 days old

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.


Pretty much the title. The community has discussed this before, but draftification is not meant to be a backdoor to deletion. We've had discussions on this before where we've made it clear as a community old articles shouldn't be draftified without discussion.[1] However, the spirit of this consensus has been completely ignored in practice. Recently, I undid the draftification of Dancing satyr, an article created in 2004 that was "draftified" by a patroller and received practically no work on it. This is inappropriate. Here two created in 2005 including one that went through the original AfC process in 2005: [2] [3] Here's some more made in 2006: [4] [5] [6] I could link dozens of extremely old articles being draftified with practically no discussion whatsoever, simply by searching Special:NewPagesFeed, switching to the Draft namespace, and sorting by "oldest" unsubmitted.
For the reason that we have really old articles being draftified by many different reviewers, I think we need to make our expectations clearer about what "new articles" means in the context of draftification. I like to propose that anything over a month old should be ineligible for draftification without consensus at AfD. Reviewers do not appear to be interpreting the intent correctly and we need a firm rule on the matter. Chess (talk) (please use {{reply to|Chess}} on reply) 22:42, 8 February 2022 (UTC)[reply]

  • Support as proposer. Chess (talk) (please use {{reply to|Chess}} on reply) 22:42, 8 February 2022 (UTC)[reply]
  • Oppose no, just because an very poor article is 31 days old, if someone might want to work on it to get it up the minimum standards I can't see any reason to refuse letting an AFD for example close as "Draftify". — xaosflux Talk 23:07, 8 February 2022 (UTC)[reply]
    @Xaosflux: This proposal doesn't ban that. I'll bold it in the statement so it's clearer, but the actual proposal is "anything over a month old should be ineligible for draftification without consensus at AfD" All I want to ban is draftification of old articles WITHOUT community consensus. If someone wants to AfD an article and it closes with draftify that's totally OK. But right now patrollers are draftifying decade old articles that have 0 chance of being worked on. Chess (talk) (please use {{reply to|Chess}} on reply) 23:46, 8 February 2022 (UTC)[reply]
    @Chess: thanks, from the title, and the "pretty much the title" it didn't seem like as much as a carve out as a new brightline. I've struck my oppose, and don't have a strong opinion on it otherwise. I wouldn't support a "ban" on bringing an article back to draft if the authors agreed on it though, nor require them to AFD themselves. — xaosflux Talk 23:50, 8 February 2022 (UTC)[reply]
  • Support, if the creator of an article that they are the only substantial contributor to is not prevented from draftifying their article under this. We have several procedures by which an article can be deleted; silently moving them to draft space is not one of them. BilledMammal (talk) 00:03, 9 February 2022 (UTC)[reply]
  • Oppose as written, I would support a longer period, such as ban moving articles older than 90 days to draft without an AfD decision to do so. I think 1 month is too short; not all new articles are reviewed in the first 30 days. Schazjmd (talk) 00:12, 9 February 2022 (UTC)[reply]
  • Support. Will streamline Wikipedia processes and reduce backlogs. Xxanthippe (talk) 00:13, 9 February 2022 (UTC).[reply]
  • Oppose as written, I would support a longer time. Wikipedia:ATD-I says this process should be used for "newly created" articles. I have seen other discussions where editors consider six months or less to be "newly created". I would agree with that or at least three months. 30 days is too short. MB 00:28, 9 February 2022 (UTC)[reply]
  • Oppose as written there is generally a backlog of several months at NPP and it can easily take three months for a new article to be reviewed, though a shorter period is normal. 90 days would be more workable for this proposal than 30. On a separate point re the very old articles that have been draftified - if a very poor article was created in 2005 it might have been redirected in 2009. Along comes someone in 2022, undoes the redirect and makes no improvement. The article then goes into the NPP queue and may be e.g. completely unsourced. I agree that draftification in this kind of case should follow an AfD decision. Mccapra (talk) 00:41, 9 February 2022 (UTC)[reply]
  • Oppose as written raise to 90 days, and I'll gladly support this. This is easily my biggest pet-peeve on Wikipedia, and having to go through User:SDZeroBot/Draftify Watch every week and slap over-zealous reviewers is getting really annoying. Curbon7 (talk) 01:04, 9 February 2022 (UTC)[reply]
  • Support as modified so that articles may be draftified on initial review or otherwise in the first 60 days. Robert McClenon (talk) 04:02, 9 February 2022 (UTC)[reply]
  • Support as modified I'm fine with 60 days or any longer period under 6 months. Certain editors have been massively misusing draftification as a method to force articles onto AfC. If you think an article isn't notable, then PROD it or nominate it for deletion. If it is notable, but is lacking references or anything else, we have tags and templates for that. Draftification is an incredibly lazy action to take, trying to make the article somebody else's problem. SilverserenC 04:10, 9 February 2022 (UTC)[reply]
  • Oppose as written - I've supported the longer timeline below Nosebagbear (talk) 09:54, 9 February 2022 (UTC)[reply]
  • Support I have also been concerned about draft being used as a means to delete the article without the scrutiny of AfD. NemesisAT (talk) 10:01, 9 February 2022 (UTC)[reply]
See Chinese Wikipedia CSD O7:
O7: Abandoned Draft.
Any drafts that is being idle for 6 months
  • The "Draft" means:
    1. All pages in the Draft namespace; or
    2. Userpages with the {{AFC submission}} template.
  • When determining the last edit time of the draft, maintenance and bot edits should be ignored.
  Wiki Emoji | Emojiwiki Talk~~ 11:44, 10 February 2022 (UTC)[reply]
And how is that different from English Wikipedia's CSD G13? --Ahecht (TALK
PAGE
) 15:00, 10 February 2022 (UTC)[reply]
  • Oppose - as written. When articles are reviewed, often they are tagged, and left unreviewed as a means to encourage the article's creator, or other editors, to improve the article so that the articles passes either WP:GNG or WP:VERIFY, or both. In those instances, giving the article's creator only a month to improve is a handicap to that editor. Onel5969 TT me 19:29, 18 February 2022 (UTC)[reply]
  • Oppose. The NPP queue is routinely 3-4 months long. Only allowing draftification in the first 30 days makes it so that over half of the NPP queue is ineligible for draftification, eliminating an important tool for dealing with articles with borderline notability or poor sourcing. –Novem Linguae (talk) 20:56, 18 February 2022 (UTC)[reply]
  • Support per my post on the post-90-day ban below. Ajpolino (talk) 21:40, 18 February 2022 (UTC)[reply]
  • Oppose my opposition in the 'post-90-day ban below' applies equally here, but perhaps with more force! FiddleTimtrent FaddleTalk to me 09:20, 21 February 2022 (UTC)[reply]
  • Oppose scope_creepTalk 00:08, 22 February 2022 (UTC)[reply]
  • Support I often have had concerns with draftifying articles as I have on a number of occasions seen draftifying used as a way to get an article deleted when a QD or Prod would have failed. They move the article and then 6 months later because no one noticed the move the article gets nuked as an abandoned draft. -DJSasso (talk) 14:39, 3 March 2022 (UTC)[reply]
  • Support. Draftifying articles that are "not up to scratch" is a terrible practice. There is no guarantee that anyone is ever going to work on them in draft and the usual result is a G13 deletion. If a CSD or prod cannot be justified, then draftifying isn't either. If deletion is justified, then draftifying won't change that. SpinningSpark 16:22, 3 March 2022 (UTC)[reply]
  • Support in principle. As others note the timescale might need further discussion. I understand however that "draftifying" is a backdoor way of deleting content without oversight. - Master Of Ninja (talk) 09:57, 10 March 2022 (UTC)[reply]
  • Oppose 30 days is far too short - it's even more problematic because RfC's to deprecate sources run for 30 days on average, so it gives very short windows to deal with microstubs that solely rely on sources deprecated or found generally unreliable. Pilaz (talk) 09:45, 14 March 2022 (UTC)[reply]
  • Oppose per Novem Linguae. 30 days is certainly too short. I'm sure I voted on this before, but it got wiped. — Charles Stewart (talk) 11:22, 15 March 2022 (UTC)[reply]
  • Support. I would outright ban any draftification without consensus since it's a) a backdoor kind of deletion without oversight and b) removes content from the eyes of people who might want to improve it. WP:IMPERFECT is still a policy and Wikipedia became the success it is today because it was easy for people to stumble about things to improve. Draftification hinders these efforts by putting articles in a separate namespace where they are most likely ignored due to the persistent WP:SEP-effect. Draftification should only happen if the alternative were deletion. As long as the subject is suitable for inclusion, the state of the article should not be relevant. But whether a subject is suitable for inclusion is for the deletion processes to decide, not a single editor. If we cannot ban draftification without consensus outright, we should at least prevent established articles from being yanked from mainspace. If something survived for 30 days, it's likely that it should survive. If you see yourself unable to make a convincing argument at AFD that it should be removed, it shouldn't be. Regards SoWhy 19:37, 16 March 2022 (UTC)[reply]
  • Oppose: Our current new page patrol backlog goes way beyond 30 days. For articles that didn't go through AfC, this means many articles will become undraftifiable even before anyone at NPP or AFC looks at them. MarioGom (talk) 08:49, 18 March 2022 (UTC)[reply]
    Maybe we need to have a software change to mark which pages in the queue have been looked at by someone at NPP. Right now, the only thing we know is whether there are any pages for which someone at NPP has not yet clicked the button to approve. These are meaningfully distinct concepts, as some NPPers focus on the very front of the queue, to make sure that attack pages and blatant vandalism get deleted within minutes. They look at everything, but you have no way of knowing that. WhatamIdoing (talk) 20:42, 21 March 2022 (UTC)[reply]
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.

Proposal to ban draftifying articles more than 90 days old without consensus

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.


Since most of the people opposing have supported a longer period, I'd like to propose that anything over 90 days old should be ineligible for draftification without consensus at AfD. I'm putting this in a separate section so we can get more clarity on what the consensus is. Chess (talk) (please use {{reply to|Chess}} on reply) 04:53, 9 February 2022 (UTC)[reply]

  • Support as proposer. Chess (talk) (please use {{reply to|Chess}} on reply) 04:53, 9 February 2022 (UTC)[reply]
    @BilledMammal, Schazjmd, Xxanthippe, MB, Mccapra, Curbon7, Robert McClenon, and Silver seren: Mass pinging to this new proposal so we can coalesce on a firm number. Chess (talk) (please use {{reply to|Chess}} on reply) 04:55, 9 February 2022 (UTC)[reply]
  • Support as before. Xxanthippe (talk) 04:55, 9 February 2022 (UTC).[reply]
  • Support as before. BilledMammal (talk) 04:55, 9 February 2022 (UTC)[reply]
  • Support as before. SilverserenC 05:03, 9 February 2022 (UTC)[reply]
  • Support with everything I said above the same. Curbon7 (talk) 05:22, 9 February 2022 (UTC)[reply]
  • Weak Support because I would prefer that the criterion be whether the article has been reviewed. I agree that some reviewers are misusing draftification because writing an AFD nomination is hard work. Robert McClenon (talk) 05:48, 9 February 2022 (UTC)[reply]
  • Support Mccapra (talk) 08:25, 9 February 2022 (UTC) changing my mind after reading other comments[reply]
  • Support this time restriction; beyond that I would specify that articles which have been marked as reviewed or which have passed through AfC (other than in an established misuse of these processes) should not be draftified. AllyD (talk)
  • Support the longer timeline - backdoor deletion is a concern, but NPP do have a valid usecase and so should match their timeline Nosebagbear (talk) 09:53, 9 February 2022 (UTC)[reply]
  • Support as before. NemesisAT (talk) 10:01, 9 February 2022 (UTC)[reply]
  • Support Older pages should not be unilaterally draftified as there is usually no one to notice it – it just results in a deletion after 6 months. – SD0001 (talk) 14:15, 9 February 2022 (UTC)[reply]
  • Support as before. Schazjmd (talk) 15:04, 9 February 2022 (UTC)[reply]
  • Maybe if expanded to ...without consensus at AfD or by the page author(s). I'm fairly neutral if this includes the page authors; if the author(s) agree, for example by talk page discussion or if there is a single author, can't see why they would need to AFD themselves. Oppose creating a policy that would require them to AFD themselves. — xaosflux Talk 15:12, 9 February 2022 (UTC)[reply]
    I'd imagine in effect an admin could justify this by saying WP:G7 is enough for a deletion and move to draftspace. Chess (talk) (please use {{reply to|Chess}} on reply) 20:54, 9 February 2022 (UTC)[reply]
  • Support. I'd also support a shorter period, requiring consensus for reviewed articles of any age and those moved out of draft (by anybody for any reason). I'd also support Xaosflux's suggestion regarding page author(s) - if someone could G7 the page then they should be able to support moving it to draft. Thryduulf (talk) 16:07, 9 February 2022 (UTC)[reply]
  • Support – after 90 days, draftification very frequently does serve as a back door to deletion, which of course isn't its purpose, simply because the article's creator has moved on. There are very few articles at the back of the NPP queue that can't be adequately dealt with via AfD, PROD, and/or tagging. I certainly support an exception for self-draftifications (which would presumably be covered by IAR anyway), and I could probably support a shorter period (e.g. 60 days) as well. Extraordinary Writ (talk) 19:56, 9 February 2022 (UTC)[reply]
  • Support The proposal looks sensible and straightforward. Others in favour seem to have made reasonable points to explain why. I would also support something with a shorter period (say 30 days) if there was sufficient consensus for it. @Chess: I've not been checking VPP processes for a while, but should this have an RfC made as well? Possibly a CENT notice, though I'm usually unsure when the latter are used exactly, honestly. To make sure there's enough people throughout Wikipedia who had a chance to look over it? This seems to have widespread support, but dotting all Ts and crossing all Is seems sensible to make sure it's implemented (well). Soni (talk) 00:37, 10 February 2022 (UTC)[reply]
    • I've been thinking the same thing; I don't believe CENT is needed, but placing an RFC tag on this would be appropriate - although I don't believe it will need to run for the full 30 days. BilledMammal (talk) 00:49, 10 February 2022 (UTC)[reply]
      • I decided to be bold and start the RFC since I'm fairly sure it'll be necessary. Still unsure if CENT is really not needed, but that can wait for more opinions. Hopefully I did not mess anything up technically when making it. Courtesy pings @Chess: and @BilledMammal:. Soni (talk) 11:33, 10 February 2022 (UTC)[reply]
  • Support. If the article's been around that long, time to deal with it. CSD, or else PROD, or else AfD, or else fix it, or else leave it. No place in that list for stealth deletions. (Summoned by bot.) Herostratus (talk) 16:11, 10 February 2022 (UTC)[reply]
  • Support iff "90 days" means 90 days after being marked patrolled, and not 90 days after creation, and excludes cases where the creator is moving it to draft and the article would otherwise be eligible for G7. Seraphimblade Talk to me 17:57, 10 February 2022 (UTC)[reply]
    So more or less oppose, since I believe most people take this as "90 days after creation" and the unreviewed backlog stretches back over a decade. Though an exception for G7'able articles is uncontroversial in my opinion. Chess (talk) (please use {{reply to|Chess}} on reply) 00:34, 13 February 2022 (UTC)[reply]
  • Support per above; 30 days is too short but 90 days is a good cutoff. This probably should be on CENT -- but it need not stay there for a month if this is a SNOW pass. I'd add to CENT it myself except I don't want responsibility for removing it if need be. The folks at WT:CSD may also want a ping. User:力 (powera, π, ν) 00:56, 12 February 2022 (UTC)[reply]
  • Support 60 days. TheBirdsShedTears (talk) 02:40, 13 February 2022 (UTC)[reply]
  • Oppose Supporting the 90 days limit, but consensus may be built at other venues than AfD, or that the articles in question were created and mainly edited by known socks, or hidden UPEs, or drafts accepted by AfC reviewers who were found to be socks or UPEs. – robertsky (talk) 04:10, 13 February 2022 (UTC)[reply]
    Why would any of those cases result in draftifying the article in question? Either they would be deleted or taken to AfD in such cases or another editor would take responsibility for the article. None of which has to do with draftification. SilverserenC 04:42, 13 February 2022 (UTC)[reply]
    There was a batch draftified in 2017 as consensus for dealing with a residue of potentially-salvageable articles created by the Content Translation tool: Wikipedia:Administrators' noticeboard/CXT/Draftification list July 2017. The emphasis in the present proposal should be on consensus as a potential exception condition rather than on a specific venue. AllyD (talk) 09:43, 13 February 2022 (UTC)[reply]
    I was involved in that and can attest that we lost multiple editors over the CTX initiative, which swept up a lot of very good articles for no reason other than that they were originally in another language. And we wonder why our retention sucks. I am still angry about that Elinruby (talk) 11:03, 3 March 2022 (UTC)[reply]
  • changed to oppose after reading over at WT:NPR Happy Editing--IAmChaos 22:36, 21 February 2022 (UTC)[reply]
  • Oppose, but I'd support a ban from 180 days or Seraphimblade's 90 days after being marked patrolled. Too many AfDs are dedraftified articles in this gap. — Charles Stewart (talk) 15:05, 14 February 2022 (UTC)[reply]
  • While it looks, unfortunately, like this proposal is likely to achieve a favorable outcome, I am moved to oppose it, as written. If the proposal was about draftifying a page as a means of circumventing a deletion process, as is often done with very new articles/pages, I would be in full support. But I don't think an arbitrary time table should be used to effectively disallow admin discretion by requiring consensus for draftification at XFD before it could happen. And I'm concerned that it's a step towards requiring the same type of consensus before userfication too, since userfication and draftification are semi-synonyms in spirit and effect. Let XFD discuss and determine deletion aspects of an article/page, as it does and is set up to do. And continue delegating draftification/userfication to an admin's discretion (post-deletion) as it is and has been effectively done up to now.--John Cline (talk) 23:23, 16 February 2022 (UTC)[reply]
    @John Cline: The ability to draftify isn't given to admins, but to all new page reviewers and hypothetically anyone that can move pages. The reason why I made this proposal is that draftification to circumvent deletion is already banned, and draftification is already supposed to be used for new pages and not for old pages. But many people are still moving decade old pages to draftspace, so giving people "discretion" isn't working. A hard limit is required at this point. Chess (talk) (please use {{reply to|Chess}} on reply) 22:05, 18 February 2022 (UTC)[reply]
    I understand Chess, and would likely support an effort that was limited to draftification by moving the page. The problem, for me, is that draftification (in general) also affects an admin's discretion to draftify a page (post-deletion) and that is why I opposed the proposal "as written". Best regards.--John Cline (talk) 23:39, 21 February 2022 (UTC)[reply]
  • Support Cbl62 (talk) 21:43, 16 February 2022 (UTC)[reply]
  • Support limiting unilateral and contested actions to hide existing articles in Draft: space, subject to the usual reasonable limits (e.g., self-draftification by sole authors still permitted, IAR is still policy, redirects aren't articles, the occasional inevitable mistake should be handled by reverting the move, etc.). WhatamIdoing (talk) 20:25, 17 February 2022 (UTC)[reply]
  • Oppose 90 days is far too short. It doesn't take cognizance of the fact of the length of the NPP queue which is more than 6 months old, which is common. All it will do it populate Wikipedia with articles that are badly damaged or unfit for mainspace, increasingly workload of NPP. I would certainly support 180 days, which would take care of the majority of the article on NPP. Obviously there is articles being added from donkey's ago, but the majority are under that limit. I will destroy the effectiveness of both NPP and AFC. — Preceding unsigned comment added by Scope creep (talkcontribs) 14:16, 18 February 2022 (UTC)[reply]
    • Scope creep, at the moment, Special:NewPagesFeed shows only one article that was created more than 90 days ago, but even that article would still qualify for unilateral, zero-discussion-required draftification, as it's only been in the mainspace for five days. Just because the NPP queue gives an older date for page creation doesn't mean that the article has been in the mainspace (or has been a non-redirect page) that long. WhatamIdoing (talk) 22:06, 18 February 2022 (UTC)[reply]
      • @WhatamIdoing: Yip, but it is not always like that. There was lots of articles created from months back that can arrive on the queue. I've seen several admins quitely going back to put back article into mainspace, that were older than 180 days, so when I saw that action, I set my own limit to 180 days. scope_creepTalk 00:26, 19 February 2022 (UTC)[reply]
        Right, but that makes the page older than 90 days, whereas this proposal is talking about how long it's been in the mainspace, not how long since the date of the first visible revision. WhatamIdoing (talk) 00:46, 24 February 2022 (UTC)[reply]
        And, you know, if it's been in the mainspace for >90 days, then the only change is that you couldn't dump it in draftspace without first getting consensus for doing that. "Talk to some other people first" does not seem like a very onerous requirement. WhatamIdoing (talk) 00:47, 24 February 2022 (UTC)[reply]
    • All it will do it populate Wikipedia with articles that are badly damaged or unfit for mainspace Have you considered, you know, nominating those articles for deletion? Which is what you're supposed to do with bad articles? Draftifying articles that you know will inevitably be auto-deleted in 6 months is appointing yourself as judge, jury, and executioner of the article. Wikipedia is built on consensus, not unilateral decisions. Mlb96 (talk) 07:08, 20 February 2022 (UTC)[reply]
      • No It is not an ad-hoc case of just nominating the articles for Afd. Many of these that go to draft are absolutely notable, but they often have serious problems and need time to be worked. The majority are notable. That is what draft is for. It is the ideal place for these types of problems. That is the solution is used industry wide, everywhere. It is not death sentence. That is assumption that your making and is not based on fact. It wasn't in the original design for ACTRIAL and isn't in the original process now. scope_creepTalk 15:21, 21 February 2022 (UTC)[reply]
      • @Mlb96: And badly damaged doesn't mean non-notable, in any instance. scope_creepTalk 15:29, 21 February 2022 (UTC)[reply]
  • Oppose - as written. There needs to be clarity about when the clock starts ticking. For example, an article is created on January 1, it consists of 3 paragraphs, wholly uncited. It's about a subject which can be redirected (say it's about a book and the author has an article). On January 3 it gets turned into a redirect. On April 15th, someone comes upon the redirect and reverts it, adding a single source to the author's webpage. Now, technically, this article was created over 90 days in the past. In this new criteria, that article would be ineligible to be draftified, while it is clearly not suitable to remain in mainspace. I would not be opposed to the 90 day limit if there is some clarification about when the 90 days begins, but not sure how that should worded. Onel5969 TT me 19:29, 18 February 2022 (UTC)[reply]
  • Weak oppose I am sympathetic to the idea that draftification is sometimes used when the right thing to do is AfD. So on that level I support this. However, the concern expressed by Onel about the current wording is troubling to me as well and so that balances out to this weak oppose. Best, Barkeep49 (talk) 20:10, 18 February 2022 (UTC)[reply]
    @Barkeep49 and @Onel5969, if you look at the comments below, I believe that your concern has already been addressed. The idea of "anything over 90 days old" is meant to be interpreted as an actual article in the mainspace for the last 90 days, not merely a calculation of the date of the oldest revision. WhatamIdoing (talk) 22:09, 18 February 2022 (UTC)[reply]
    Putting it in as a formal bolded !vote makes it far more likely that the closer will adequately weigh it when determining consensus than a comment by one person which was agreed to by a second editor. So I wouldn't at all say my concern has been addressed, but I am hopeful it can be addressed in the end. Best, Barkeep49 (talk) 22:17, 18 February 2022 (UTC)[reply]
    @Barkeep49, AFAICT there isn't any "current wording" to object to. The OP seems to have proposed a principle rather than a specific sentence to be added to a specific page. WhatamIdoing (talk) 17:15, 24 February 2022 (UTC)[reply]
    That could be technically true @WhatamIdoing but adding "anything over 90 days old should be is ineligible for draftification without consensus at AfD" to WP:DRAFTIFY (i.e. a minimally changed version of what was originally proposed) would seem to be the default unless the close indicates otherwise. I am stating here what my thinking is and am hoping it will influence consensus appropriately. Best, Barkeep49 (talk) 17:24, 24 February 2022 (UTC)[reply]
  • Oppose. A quick look at Special:NewPagesFeed shows the back of the queue to be around 4 September 2021, if you subtract out even older articles that were probably added by flipping a redirect into an article. That's 168 days. So if you are a back of the queue new page patroller, and there is a 90 day limit on draftification, then articles in the back of the queue are no longer eligible. The NPP would need to pay attention to date created and do math or install a user script, adding additional burden. Additionally, draftification is a very important NPP tool for dealing with articles of borderline notability or poor sourcing. I am not convinced that taking this tool away from NPPs patrolling the back of the queue in order to prevent over-zealous draftification is a good tradeoff. By the way, are there any diffs or statistics or evidence that over-zealous draftification is a major, frequent problem? Is this possibly a solution in search of a problem? Don't forget, anyone can object to draftification and move it back, and double draftification isn't really allowed per WP:DRAFTOBJECT. This existing workflow seems fine for dealing with overzealous draftification. –Novem Linguae (talk) 21:10, 18 February 2022 (UTC)[reply]
    @Novem Linguae, but how long has that article actually been in the mainspace? If you're looking at the same one that I saw, the answer is 5 days, not 168. WhatamIdoing (talk) 22:12, 18 February 2022 (UTC)[reply]
    @WhatamIdoing, the article I'm thinking marks the back of the NPP queue currently is Kluaynamthai. Articles older than that are more spaced out, so I assume the are redirects that got flipped to articles, so I'm not counting those. –Novem Linguae (talk) 22:18, 18 February 2022 (UTC)[reply]
    Do you think that this article, which has already been PRODded once, and which is already indexed by search engines, should still be subject to unilateral, undiscussed draftification by anybody who's managed to make 10 edits, rather than being sent to AFD to identify the consesus? WhatamIdoing (talk) 23:14, 18 February 2022 (UTC)[reply]
    I think it is reasonable for an NPP reviewer to have draftification available as an option when reviewing unreviewed articles, both at the front and the back of the queue. –Novem Linguae (talk) 03:27, 19 February 2022 (UTC)[reply]
    @Novem Linguae: Look at Special:NewPagesFeed, click on "Articles for Creation", sort by created date (oldest), and show unsubmitted articles. Many such cases of overzealous draftifications. People aren't going to object if they last edited several years ago. Chess (talk) (please use {{reply to|Chess}} on reply) 22:14, 18 February 2022 (UTC)[reply]
    Chess, thanks for your comment. I spot checked the first 5. Draft:Dean Shomshak was draftified per AFD. Draft:Gladius fighter was a redirect flipped to an article recently, so essentially a new article. Draft:Ancients (board game) was draftified per AFD. Draft:List of fictional medical institutions was deleted at AFD and WP:REFUNDed recently. Draft:Freespace was a redirect flipped to an article recently, so essentially a new article. All 5 draftifications were by experienced users and seem reasonable to me. Really I think the only quibble is that 2 of these could have been flipped back to a redirect instead of draftified, in order to leave the redirect in place. In conclusion, I am not convinced from this spot check that poor draftification decisions is a frequent problem. –Novem Linguae (talk) 22:26, 18 February 2022 (UTC)[reply]
  • Support Bad/poorly sourced articles on notable topics belong in mainspace where they can be improved (barring WP:TNT). Articles on non-notable topics need a WP:PROD, relevant WP:CSD tag, or an WP:AFD discussion. Borderline cases to WP:AFD. Unilateral draftification seems to sometimes function as a run-around to the current processes. I'd support an outright ban on unilateral draftification, but since this seems more likely to gain broad support, I'll throw my support here. Ajpolino (talk) 21:39, 18 February 2022 (UTC)[reply]
  • Oppose should be 90 days after it's patrolled. Non-patrolled articles should not enjoy immunity just because NPP is backlogged. Also, the proposal needs more clarification about when the timer starts. (t · c) buidhe 21:57, 18 February 2022 (UTC)[reply]
    @Buidhe, why should anything that's already been patrolled by dumped back in draftspace? Isn't figuring out whether an article should be in the mainspace kind of a major purpose of patrolling? WhatamIdoing (talk) 22:11, 18 February 2022 (UTC)[reply]
    Yes, after it's patrolled it should not be draftified, but before it's patrolled should be fair game because the NPP backlog goes back more than 90 days. (t · c) buidhe 22:16, 18 February 2022 (UTC)[reply]
    @Buidhe, can you give me the names of a couple of unpatrolled articles that have already been in the NPP queue for more than 90 consecutive days? WhatamIdoing (talk) 22:19, 18 February 2022 (UTC)[reply]
  • Oppose Looking at the 6 examples given in the original proposal (30 days), one was undeleted to draft per WP:REFUND by an admin after the article was prodded. This seems a legitimate action. Of the other 5, 3 were draftified by new users (less than 1,000 edits). Agree with previous comments that a time limit would would be counter productive to NPP. This proposal misses the problem that in the majority of these 'old' articles gratification was carried out by inexperienced editors. A far more effective solution would be to limit the ability to send articles to draft, either by minimum edit count or by a new permission. --John B123 (talk) 22:05, 18 February 2022 (UTC)[reply]
    John B123 that's an interesting point, but I wonder at what point permission creep would turn the process a bit too bureaucratic and unfriendly to new editors. I have no opinion on the whole matter (NPP is not an area I spend time with), but just a thought. A. C. SantacruzPlease ping me! 13:17, 19 February 2022 (UTC)[reply]
  • Support As I stated above, Draftifying articles that you know will inevitably be auto-deleted in 6 months is appointing yourself as judge, jury, and executioner of the article. Wikipedia is built on consensus, not unilateral decisions. These articles should go to AfD where the community can decide what to do with them. Mlb96 (talk) 07:10, 20 February 2022 (UTC)[reply]
  • Oppose This feels like the wrong fix for the problem. If people are misusing the draftification process, the answer to that is not to impose an arbitrary time limit after which the process may not be used/misused. Draftification can be a valid outcome of a new page review, I don't see why it should be taken off the table entirely purely on the basis of the age of an article - if the queue is backlogged, and nobody has got to a new article until the 90 days has elapsed, the first person coming to it should have the full range of options. Girth Summit (blether) 07:24, 21 February 2022 (UTC)[reply]
  • Support, simply from the perspective of fairness. If someone has created an article and it sticks around for 3 months without it being touched, it's not reasonable for a single lone actor to decide they don't like the look of it and effectively delete it by the back door without any checks and balances. Look at this from a human point of view, it's demoralizing. I could have supported the 30 day limit too, as it's not like this really cripples NPP irreparably - you still have AFD and CSD available.  — Amakuru (talk) 07:53, 21 February 2022 (UTC)[reply]
  • Oppose What has happened to the old fashioned concept of Using Good and Mature Judgement? What do we then do to the editor who missed the deadline by a day? ANI?
    We expect editors who use tools like the draftification script, or just plain old article moving to use judgment. We do not expect to legislate for every single goshdarned instance of what may or may not happen here. Wikipedia started with a tiny set of rules, and now we have an enormous bureaucracy. Do we like rules so much that we must enforce them on every single facet of building an encyclopaedia?
    Of course it's foolish to draftify an old article. Of course it is. No-one denies that. Of course doing so is an error. Of course it is. But codifying every possible circumstance makes Wikipedia harder and harder to use, it makes it a club for the initiates.
    This proposal seems to me to be a knee jerk reaction to an editor's good faith error. We do not need legislation for every error. What we need is guidance, education.
    Please let us continue to educate, not legislate. FiddleTimtrent FaddleTalk to me 09:09, 21 February 2022 (UTC)[reply]
    Using good judgement went out the window when people no longer exercise it. We expect them to use good judgement, and they don't. This comes from many different editors for a wide variety of reasons.
    And I'm going to go out on a limb here, if we're complaining about how Wikipedia is hard to use, draftification is the prime example of this. It's user hostile and is effectively a dark pattern that makes the user believe that draftification is mandatory and cannot be appealed. There is no information provided to users that they can unilaterally move out of draftspace, that they're not forced into this. The standard message tells people the only way to get out is AfC, a process where editors are led on in a lengthy scam that their topic may one day be notable if they just find elusive sources which in reality results in editors waiting months for reviews until they get bored and leave.
    Draftifying old articles is the most hostile aspect since the editors who created them are usually long gone and have no intention to work on them. Chess (talk) (please use {{reply to|Chess}} on reply) 01:16, 22 February 2022 (UTC)[reply]
    Then educate people. Rules, rules and more rules do not make a happy experience here. Soon we'll need permission to use vowels!
    Oh, a heads up here. You will need to educate people for these proposed rules anyway. So why not just educate them? Or is it so we can issue sanctions against people? FiddleTimtrent FaddleTalk to me 12:16, 22 February 2022 (UTC)[reply]
    @Timtrent: Perhaps we should make it a standard part of the movetodraft script that editors must be informed that they can unilaterally move the draft back to mainspace? Would that be a part of the education you're OK with? Chess (talk) (please use {{reply to|Chess}} on reply) 21:31, 22 February 2022 (UTC)[reply]
    Oh please let us have more pitfalls for people. Have you noticed that we not only have admins, but bureaucrats, stewards, arbitrators, a whole panoply of functionaries? The more rules the greater the ability to drive editors of all experiences away. TYhemore rules the more visits tio the drama boards, to ArbCom.
    I know I am not on the winning side here. You've started a populist movement, rather like the Turkish people were encouraged in electing a perpetual dictator who jailed a while cross section of Turkish society lest there was dissent. And no, you are not the dictator, but you are enabling more rules, something I find to be counter to the spirit of Wikipedia and thus distasteful FiddleTimtrent FaddleTalk to me 21:44, 22 February 2022 (UTC)[reply]
    The pressure on NPP reviewers (and similar editors) is to avoid approving an article that someone else might later claim was insufficient. The pressure to correctly accept articles on notable subjects is weaker than the pressure to exclude articles that could be complained about. This has led to a ratchet effect on standards and to pages lingering in the queue despite multiple admins and reviewers looking at them, because reviewers are humans, and therefore become afraid to be the person who can be blamed for clicking the button later.
    This proposal is a small effort to balance the pressures. If it's been in the mainspace for three months already and is still unreviewed (a relatively rare occurrence), and nobody's been willing to mark it as patrolled in that whole time, then we need to make that article the whole community's problem, not have one person hide it in draftspace. And, for the more worrisome case, if the article has been in the mainspace for years, and was marked as patrolled by NPP years ago, then there should be some level of discussion before dumping it in draftspace, rather than a unilateral, undiscussed action by one editor. This rule might push us back towards collaboration and away from one individual making the decisions.
    BTW, I looked through the move log for yesterday. Most moves from the mainspace to draftspace were pages that had been created within the last 24 hours. There was another big group (about 15–20 pages) that were all about 60 days old. There were very few that weren't in those two groups. WhatamIdoing (talk) 02:03, 24 February 2022 (UTC)[reply]
    @Timtrent: This RfC could go either way as I am tragically not allowed to jail the people who showed up in the past few weeks opposing my proposal. Chess (talk) (please use {{reply to|Chess}} on reply) 18:28, 6 March 2022 (UTC)[reply]
    @Chess Generally one must go with the flow without jailing people. I think you need to be grateful that sufficient people on each side of the proposal have given opinions. That should be genuinely satisfying because you are building consensus. Whatever the outcome you have built consensus. FiddleTimtrent FaddleTalk to me 18:52, 6 March 2022 (UTC)[reply]
    @Timtrent: I am being sarcastic because between now and when you compared me to a populist who jails dissidents many people have shown up to dissent against the proposal despite your prediction. One would infer that this is because I can't jail the oppose !voters. I somewhat doubt we will have "built consensus" though as my prediction is this'll probably end in "no consensus". The only consensus is that we shouldn't draftify old articles; but we already have a consensus about that. Chess (talk) (please use {{reply to|Chess}} on reply) 18:58, 6 March 2022 (UTC)[reply]
  • Oppose overly prescriptive limit; solution in search of a problem. Stifle (talk) 10:27, 21 February 2022 (UTC)[reply]
  • Oppose per Novem Linguae and Timtrent (Fiddle Faddle) above and Mccapra in the discussion below. A hard limit seems at odds with how our policies and guidelines are intended to work. What happens when someone drafties an article on the 91st day? A limit of 90 days will further impact the WP:NPP workflow which if anything needs more simplifying, both for backlog management and editor retention. If we have drafts that could be articles getting deleted—and I don't see much evidence presented that they are—what we need is for admins working G13 to be more careful about what they delete, and it is they who should be give more and clearer guidelines on identifying promising drafts and putting them through alternative routes to improvement or deletion by consensus. Regards! Usedtobecool ☎️ 16:08, 21 February 2022 (UTC)[reply]
  • Oppose per WP:CREEP. There needs to be some room for discretion. Beeblebrox (talk) 21:58, 21 February 2022 (UTC)[reply]
  • Oppose per Stifle and Beeblebrox. Doesn't seem to actually solve anything, and adds pointless bureaucracy. ansh.666 22:40, 21 February 2022 (UTC)[reply]
  • Comment I find it really fascinating that this was a unanimous support a few days ago, and then this discussion gets added to WP:CENT and it is a straight-line of oppose. Just goes to show the importance of collaborating to the fullest potential, in order to ensure that the consensus reached is the actual consensus! Curbon7 (talk) 01:32, 22 February 2022 (UTC)[reply]
  • Support draftification of old articles is basically deletion by the back door, but without any of the review and oversight that comes with the usual deletion processes. As a result it makes sense not to allow it. While each case is different and there is scope for discretion, that doesn't mean we can't have a bright-line limit beyond which it's generally considered unacceptable, as we do with 3RR. Hut 8.5 08:44, 22 February 2022 (UTC)[reply]
  • Oppose Per Beeblebrox. Having such an arbitrarily defined hard limit seems ill-advised. ThePlatypusofDoom (talk) 09:00, 22 February 2022 (UTC)[reply]
  • Oppose these and any other proposals that would make draftification more difficult than speedy deletion.—S Marshall T/C 23:11, 22 February 2022 (UTC)[reply]
    Draftification should be just as hard to do as speedy deletion. In both cases you are removing content from the mainspace of encyclopaedia without consensus. Thryduulf (talk) 15:39, 23 February 2022 (UTC)[reply]
    Most things we do here are "without consensus", including the creation of articles, which is very easy. Speedy deletion on the other hand is restricted to admins and is strictly based on consensus-agreed reasons, so your comment doesn't seem to make any sense. Plus: draftifying can be checked by everyone, not just admins: it can be reversed by anyone, not just admins. And people with a track record of poor draftifications can always get a topic ban, just like with most issues around here. Removing sub-par content from the mainspace (but on a notable topic, so perhaps salvageable) should be applauded, not vilified. Fram (talk) 15:55, 23 February 2022 (UTC)[reply]
  • Oppose Absolutely not. This proposed idea is hopelessly bureaucratic, difficult to enforce, and will undoubtedly lead to increased drama via WP:ANI (which is already busy enough as-is). If someone is causing trouble with inappropriate draftication, then block them, problem solved. No need to impose pedantic rules on the rest of us. -FASTILY 23:22, 22 February 2022 (UTC)[reply]
    Disputes over draftification are supposed to go to AfD. Not ANI. SmokeyJoe (talk) 03:35, 24 February 2022 (UTC)[reply]
    Yes, and I don't think anyone here disagrees with that. As others have already stated above, the 90-day limit is totally arbitrary. What are we supposed to do if someone converts an article to draft at 91 days? -FASTILY 09:57, 24 February 2022 (UTC)[reply]
    Same as now. WP:DRAFTOBJECT. SmokeyJoe (talk) 10:16, 24 February 2022 (UTC)[reply]
    I don't see how that's relevant to what I'm talking about. I foresee behavioral issues and increased drama (both accidental and premeditated) which typically leads to ANI. -FASTILY 23:05, 24 February 2022 (UTC)[reply]
    Sounds like the problem is with ANI, if it gets involved with drama when there is a simple process available. SmokeyJoe (talk) 21:34, 26 February 2022 (UTC)[reply]
    That makes no sense and doesn't address any concerns I've raised. When drama escalates, it frequently gets reported to ANI. I can't imagine why you're so fixated on this part, you're missing the forest for the trees. -FASTILY 23:53, 28 February 2022 (UTC)[reply]
    User:Fastily, I am not fixated, I just commented on one angle of your !vote and do not challenge most of it. But if you’d like comment on your details then: This proposal merely changes WP:DRAFTIFY’s “old” to “90 days”. Maybe old should be measure by edits, or pageviews. Maybe 90 days is too few or too many. In any case, it’s not more bureaucratic than the current 2d, just more precise. Difficult to enforce? I don’t see how it makes “enforcing” DRAFTIFY#2d harder, usually bright lines make enforcement easier. I don’t think it will increase any drama; I am already surprised that unilateral draftifications have been controversy free for so long. I foresore sneaky deletionism, clearing out the old permastubs, but have seen no evidence, despite watching the logs from time to time.
    If any drama does arise, draftification disputes should be sent to AfD, which should mean the discussion doesn’t bog down at ANI. If a particular editor keeps having AfD discussions repudiating their unilateral draftification, a meaningful remedy will be to remove their pagemover right.
    I am not fixated, I think this proposal is of no real consequence either way. SmokeyJoe (talk) 12:16, 3 March 2022 (UTC)[reply]
  • Moral support I think draftification as a backdoor to deletion is a loophole that should be tightened, but this specific proposal would likely lead to more problems than it solves. Making the draftification window longer, at least a year but maybe two, would strike a workable balance and avoid NPP concerns. Wug·a·po·des 07:05, 23 February 2022 (UTC)[reply]
  • Support Draftification is not a way to delete an abandoned article. We should have {{update}} template. Thingofme (talk) 12:12, 23 February 2022 (UTC)[reply]
  • Support with modifications, namely changing "articles" to "patrolled articles". --Ahecht (TALK
    PAGE
    ) 13:31, 23 February 2022 (UTC)[reply]
  • Oppose, I see no good enough reason for this. Fram (talk) 15:55, 23 February 2022 (UTC)[reply]
  • Oppose As said above, people with a poor record are already liable to get their privileges restricted, so it makes no sense to institute a universal ban, the time limit in which is bound to be completely arbitrary anyway. Avilich (talk) 00:54, 24 February 2022 (UTC)[reply]
  • Support in concept. I'm not sold on the length of time, but I do think we should disallow the draftification of longish-standing articles as most of the time it's a sneaky method of avoiding AfD/PROD. Anarchyte (talk) 03:56, 24 February 2022 (UTC)[reply]
  • Support, as a clear ratification of WP:DRAFTIFY #2d “ 2d. The page is a recent creation by an inexperienced editor. (Old pages, and pages by experienced editors, deserve an AfD discussion)”. 90 days seems reasonable. If it is too long, then it means AfD will be more used for obvious draftifications, which I don’t think is a current problem. If pages are unseen for 90+ days, this should be given more fuss, and AfD is an ok place for the fuss. —SmokeyJoe (talk) 04:12, 24 February 2022 (UTC)[reply]
  • Oppose Per concerns about above when the 90 days begins and the length of the new page backlog. I can think of many articles (such as class projects, unfortunately) that could fit in to the project but are not ready for mainspace and would be better draftified. Reywas92Talk 18:40, 24 February 2022 (UTC)[reply]
  • Oppose why on earth would we limit ourselves to an arbitrary period of time? This will just result in "wikilawyering" and drama—use some common sense, please? -- TNT (talk • she/her) 18:43, 24 February 2022 (UTC)[reply]
  • Oppose per my arguments below; insufficient evidence that this is actually a problem, whereas articles that have few eyes on them are a very serious problem. If an article that has actual eyes on it is draftified then the situation is easily settled, and if an article does not have eyes on it then that is a problem and the "safe" thing to do is to allow for draftification - we should absolutely default to "get it out of mainspace ASAP until a clear consensus is formed" in those situations. Strenuous objection to the argument that mere age, alone, gives an article any particular weight or protection - this completely misunderstands WP:QUO (which is the implicit policy being used here.) Status quo comes from an article having been seen from many people, not simply aging like fine wine, and such articles are at little long-term risk from draftification, so I don't think it is necessary to have a policy to protect them. If an article has had few eyes on it, on the other hand, then absolutely should not have any special protections regardless of its age, and moving it to draft space when someone objects to it is a reasonable thing to do. --Aquillion (talk) 00:51, 26 February 2022 (UTC)[reply]
  • Oppose Though I think this is a solution in search of a problem, I would support 6 months (nice that it aligns with the G13 cutoff), but 90 days is WAY too short. UnitedStatesian (talk) 22:17, 27 February 2022 (UTC)[reply]
  • Oppose if an article is moved to draft, it can be moved back by anyone immediately. Any article, however ‘mature’ that is unsuitable in its state for mainspace should be allowed to be draftified. We should be making this easier, not more difficult, and certainly not based on some arbitrary time limit. (I encounter spam articles of >10 years old that have never been in a state of decency but where I expect notability - moving them to draft and enforce them there to be brought up to level is better than AfD). Dirk Beetstra T C 03:58, 2 March 2022 (UTC)[reply]
  • Support, but would prefer a shorter time limit. If we have to have draftification, then it should only be applied to the newest articles as part of triage work, others should got through other discussion mechanisms like AfD. Thanks. Mike Peel (talk) 07:38, 2 March 2022 (UTC)[reply]
  • Support. In fact, I am against unilateral draftification under any circumstances or age. If the creator has not agreed to draftification and no one else has volunteered to work on it, then draftification is just slow backdoor deletion by G13. If the page is a fit encyclopaedia topic, leave it for someone to improve. If it isn't, then delete it outright rather than pretend to be helping it along. SpinningSpark 09:49, 2 March 2022 (UTC)[reply]
  • Oppose. At the minimum, if a page qualifies for G7 speedy deletion, it ought to be eligible to be moved back to draft-space by the creator or at the creator's request, but this proposal gives no room for that. It would be silly to permit pages to be speedy deleted while not permitting them to be moved to draft-namespace for the same reason. 49.198.51.54 (talk) 11:15, 2 March 2022 (UTC)[reply]
  • Oppose. I don't see the benefit of setting a time-limit. Also, "Draftifying" is not a backdoor to deletion. It maintains edit history, and is still an actively editable document, which deletion does not allow. --Jayron32 16:13, 2 March 2022 (UTC)[reply]
    Let's imagine that I decide that articles currently citing no proper sources – there are 188K articles tagged by Template:Unref, so I'm sure I'll find plenty – are, in my personal opinion, "unsuitable" for the mainspace.
    I can:
    • Send it to AFD, but then people are going to care more about whether the subject is actually notable, rather than the article being underdeveloped, and where someone might point out the awkward fact that we do not actually have a written policy that requires non-BLP articles to cite any sources at all, much less for them to be WP:Based upon sources that weren't written by the subject.
    • Try to PROD it, but then any single editor could stop me, and the reviewing admin might object, especially if I'm known for trying to use deletion as a substitute for improving articles.
    • Move it to the creator's userspace, where it will probably stay forever (unless I also spam an AFC tag on it, but that's mean to the AFC folks).
    • Move it to draft space, where I'm guaranteed that either: (a) readers won't see it some other editor does the work to bring it up to my standards or (b) it gets deleted because nobody touched it for six months.
    Looking at these options, if I want it gone, then PROD's my fastest route, and Draft: space is my most reliable route. About 22% of recent deletions (approximately the last two days), across all namespaces, has been via G13 in the draft space. This is twice the number of revdel actions in all namespaces combined and five times the number of expired PRODs that were deleted during the same time period. It is also four times the number of Draft: pages that were moved (mostly to the main namespace) on those days. This is just a two-day snapshot, but if those two days are representative, then if I dump a page in the draft namespace, there's about an 80% chance that it will end up deleted without any editor spending more than one minute considering my choice to set the article on that path towards deletion. This is what we mean when we say the draftspace is a "backdoor to deletion". Pages dumped there are very likely to end up deleted without much consideration beyond verifying that the article isn't obviously great and hasn't been edited during the last six months. WhatamIdoing (talk) 19:39, 2 March 2022 (UTC)[reply]
    Well if you (and by you, I mean you, WhatamIdoing, not the impersonal, rhetorical you) don't want the draft deleted, you can edit it so it is clearly a quality article. If your concern is that an otherwise potentially quality article may be deleted, just fix it. No one here is stopping you. --Jayron32 14:50, 3 March 2022 (UTC)[reply]
    Perhaps the people who love to WP:DRAFTIFY can do it? Chess (talk) (please use {{reply to|Chess}} on reply) 06:57, 6 March 2022 (UTC)[reply]
    @Jayron32, in this story, I'm the one who wants the page deleted, and I want it deleted even though I think it might be a notable subject.
    If I wanted it kept, then I'd leave the article in the mainspace. I'd do this first because not putting it on a path to deletion is an obvious way to keep it, but also because the previous research has shown that leaving pages in the mainspace is more likely to result in their improvement than dumping them in draftspace. This fact is why the people who originally proposed and supported the creation of the draftspace now consider it to be a failed experiment. If you want pages improved, you have to put them where the editors already are, and that's in the mainspace. WhatamIdoing (talk) 17:12, 7 March 2022 (UTC)[reply]
    Draftification of an unmatched paged and G13 auto deletion six months later is definitely back door deletion. I think the better question is whether the backdoor is being misused. SmokeyJoe (talk) 12:19, 3 March 2022 (UTC)[reply]
    "Draftifying is not a backdoor to deletion" has to be one of the dumbest things I've ever heard. WP:DRAFTIFY is strict on that matter for a reason. Curbon7 (talk) 05:23, 7 March 2022 (UTC)[reply]
    If it wouldn't be blatantly WP:POINTY, I would be happy to see someone draftify-to-delete all of the WP:NPROF articles that currently cite only sources written by the subject/his employer. I suspect that I'm not the only editor who has a few ideas about which articles are "unsuitable" and would be very unlikely to pass muster at AFC. But we don't do that, because Article content does not determine notability and WP:Consensus matters.
    OTOH, if we really do want to have a rule that says any individual editor's best judgment about whether an article is "unsuitable" is all that really matters, then let me know... I figure that if it were done slowly and quietly enough, then a whole bunch of those self-promotional NPROF articles could disappear, and this might solve the NSPORTS conundrum, too. The guideline can declare that the subject is notable, but one individual can draftify it because the current state of the article "unsuitable", and 80% of them will disappear for lack of active editing.
    Whoever gets stuck closing this: If you find that there's consensus for this draftifying articles that have been around for longer than 90 days (six months? a year? ten years?) because I think they're "unsuitable", then please explicitly state that in your summary. A clear statement that the word "old" in the 2d point of Wikipedia:Drafts can encompass any length of time that I feel like, so long as I think the article is "unsuitable", would forestall a lot of problems when editors start using this no-discussion route to deletion more freely for articles they deem "unsuitable". WhatamIdoing (talk) 17:26, 7 March 2022 (UTC)[reply]
  • Oppose per Beeblebrox. SpencerT•C 04:17, 2 March 2022 (UTC)[reply]
  • Support Please please please. It is really annoying to be scolded by a page reviewer with a year or two under his belt who wants me to know that some translation I did ages ago does not meet his standards. Yes, wikipedia articles in other languages sometimes don’t meet our standards. The fact that I did pro bono remediation on something should not mean I have to sign up to cure every single one of its ills, or fish through Google Books for references in another language just because some automated tool has an opinion about it. PS: Somebody do another one of these for sending unfinished drafts to mainspace also. Thanks from a wiki gnome who tries to solve problems xoxox Elinruby (talk) 10:54, 3 March 2022 (UTC)[reply]
    Opposing a ban on draftification is not a blanket endorsement of every draftification ever to be done. It's an endorsement for allowing the process which has its own remedy built-in: reverting the draftification and rendering that option moot. A ban to disallow the process, outright, is overly burdensome, for no appreciable good reason --John Cline (talk) 11:05, 3 March 2022 (UTC)[reply]
    ok boomer. If you think I oppose all draftification, you’re reading too fast. I can imagine cases where it is helpful, which atm all involve new editors and recent contributions. There may be others. Meanwhile, I support the proposal as written, because putting some time limit on it increases the odds that a) a new editor won’t have dropped out already over some other piece of automated rudeness and b) the author remembers enough about the topic to easily remedy whatever the issue might be. Elinruby (talk) 11:20, 3 March 2022 (UTC)[reply]
    Actually, I am an agnostic on whether the standard should be 90 days or some other number. I am not that familiar with performing new page patrols. But as an editor I really think there should be *some* standard. Per John B123 (talk · contribs), I actually like the idea of a standard for the ability to patrol new pages somewhat better. My objection to the current practice is that it is arbitrary. It is demoralizing to need to explain to a new editor who only writes about soccer why medieval Lebanon is important even with two references, or Operation Car Wash, even with interlanguage links. Or a founder of São Paulo even if he had a funny name. I have one of those right now. Elinruby (talk) 15:37, 3 March 2022 (UTC)[reply]
    @Elinruby, nothing you create should be draftified. WP:DRAFTIFY explicitly says "2d. The page is a recent creation by an inexperienced editor. (Old pages, and pages by experienced editors, deserve an AfD discussion)." You've been editing for more than 15 years, and you've made about 65,000 edits. Maybe we need to update the scripts so that they generate an error message for "old pages, and pages by experienced editors". WhatamIdoing (talk) 17:29, 7 March 2022 (UTC)[reply]
    @WhatamIdoing: Maybe you do, because I here to tell you that this does happen. I have a draftified article right now from sometime last year. I am not getting to it anytime soon because I am up currently to my neck in Russian information war against Ukraine, which seems more urgent. It will probably be deleted pretty soon as a stale draft if the pattern holds. Whoever did this was probably right about its defects —it was a translation from Portuguese wikipedia, which tends to be poorly referenced. But it expanded on a mysterious redlink in History of São Paulo, which has been languishing on a please-help-me queue for eons. I just barely got it into English and definitely don’t have the skillz to go find 17th century documentation for it. But if somebody were to want to read History of São Paulo it was interesting and expanded somewhat on the fact that the colonial city may have been founded by castaways, shrug. I am over it, but I spent a couple of days on it and this is one of several similar reasons I no longer work these queues. But to those saying no harm no foul, editors can always undraftify, I had no idea this was the case, so yeah there is harm. Most of the articles this has happened to were in obscure niches but were somewhat important within them, represented a non-negligible amount of translation work, and were killed by newish editors whose own efforts were concentrated in obscure niches of American or British culture. Elinruby (talk) 06:27, 8 March 2022 (UTC)[reply]
    @Elinruby Yes, I think if you're the one who has done most of the work on an article and someone draftifies it, unless you are very sure that other editor has done so against policy, the normal reaction would be frustration, not "that was wrong, I'll just move it back to mainspace". -- asilvering (talk) 02:11, 9 March 2022 (UTC)[reply]
    @Onel5969: Elinruby (talk) 00:05, 10 March 2022 (UTC)[reply]
  • Support Draftifying often seems to be an end round around speedy deletion as I often stumble upon articles that were around for years that someone draftified for no apparent reason and no one noticed happen so then 6 months later they were deleted as being an abandonned draft, when the article if it had not been draftified would have been an easy keep. -DJSasso (talk) 14:35, 3 March 2022 (UTC)[reply]
  • Oppose as written. NPP often has backlogs longer than 90 days. However, I'd support this with the exception of unpatrolled articles that have never been patrolled. Elli (talk | contribs) 18:52, 3 March 2022 (UTC)[reply]
  • Oppose The downsides are the various ones describes above. The potential upside is solving or reducing a problem, but I don't see where it has been shown that there is a problem that needs solving. The example "problem" discussed in the proposal was just that there is a draft languishing in user space somewhere which I don't see as a real problem.North8000 (talk) 19:57, 3 March 2022 (UTC)[reply]
  • Support as a good concrete expression of a basic principle that's already in the guidlines: draftification is only for new articles. If an article has been around for three months, then it will have already been looked at by a large number of editors (NPP only accounts for a fraction of the attention directed at new creations). Also, after such a period of time, it's not very likely that the original creator will still be around and interested in it, so draftification isn't likely to spur anyone into improving it (which is the reason things get draftified in the first place). – Uanfala (talk) 16:45, 4 March 2022 (UTC)[reply]
  • RFC about Draftifying old articles (unnecessary subheading removed)
    I'm not sure if Legobot "requires" a new section to do its dark bidding, so starting a new section to be safe, and someone more well versed with the bot can probably edit this section/tags accordingly.
    This is a RFC on the Village Pump Policy, started by User:Chess. The proposal is 'I'd like to propose that anything over 90 days old should be ineligible for draftification without consensus at AfD. More details and explanations, as well as current !votes can be found above.
    Soni (talk) 11:33, 10 February 2022 (UTC)[reply]
    @Soni: All that Legobot "requires" is (i) an {{rfc}} tag having one or more RfC categories; (ii) a brief statement of the issue to be discussed; (iii) a valid timestamp, such as is produced by the use of either four or five tildes. That's all. It cares nothing for whatever occurs before the {{rfc}} tag, but headings inside the statement can screw it up. --Redrose64 🌹 (talk) 15:21, 10 February 2022 (UTC)[reply]
    The RfC statement - and therefore the {{rfc}} tag - need to be before the comments. This is not a Legobot requirement: it is so that people arriving via the publicised link will hit the right spot and be able to read on without flipping back up the page. --Redrose64 🌹 (talk) 15:30, 10 February 2022 (UTC)[reply]
  • I'd prefer a limitation to articles that had been touched by more than one live editor. BD2412 T 03:15, 13 February 2022 (UTC)[reply]
  • For a redirect newly converted to an article (and so newly put into the patrol queue), is the intention to count 90 days from the creation of the redirect or the conversion from one? I can see this incentivizing perverse outcomes either way. Ditto for pages created more than 90 days ago and only newly moved into mainspace. —Cryptic 04:26, 13 February 2022 (UTC)[reply]
  • Comment A lot of the older articles were cleared in the November push. That is the reason you cant see them. The whole RFC is badly designed, too quickly promoted and not sufficiently publicised. scope_creepTalk 12:53, 19 February 2022 (UTC)[reply]
  • Comment the more I think about this the less sure I am this proposal makes sense. Draftification is for articles which a patroller thinks are likely to be notable, but where the sourcing is inadequate. AfD is for articles which we think are not notable (though we may be proved wrong). So directing likely notable articles to AfD after 90 days would require one of two things. Either the patroller does not do a normal BEFORE and just says “hey everyone this may be notable - is it ok to draftify it?” to gain censensus; in which case editors at AfD will get annoyed at lots of nominations with no BEFORE; or the patroller does a BEFORE, sources the article, and ends up not taking it to AfD because notability is now demonstrated; in which case they do the article creator’s work for them. That’s a great outcome for the collaborative project but I doubt most patrollers will be willing to do it in most cases. It’s mainly up to creators to source their own work.
    Discussions about draftification always sound like there’s a bunch of keen editors out there desperate to get to work on poorly sourced new articles, and somehow hindered by draftification. If there are such editors draftification helps them because it gives them a work list, so I don’t see the objection. If neither the creator, nor the patroller, nor editors worried about draftification are keen to do the work of sourcing, it doesn’t much matter if it’s in mainspace or draft.
    I understand there may be some editors draftifying inappropriately so vigilance is required, but whether this requires a system change rather than dealing with those individual editors, I’m not sure. Mccapra (talk) 11:51, 20 February 2022 (UTC)[reply]
    If a patroller is determining notability of an article without doing an at least BASIC WP:BEFORE then they should not be patrolling. If they improve an article then that is a Good Thing - Wikipedia is a collaborative process, articles do not have owners and there is no requirement for immediate perfection, and ultimately if a topic is notable we want an article on it. As experienced editors it is our responsibility to help those less familiar with our policies and practices, draftification is frequently the exact opposite of that. Thryduulf (talk) 15:45, 23 February 2022 (UTC)[reply]
    Sure it’s a good thing if patrollers improve an article. I’m just saying patrollers didn’t sign up to provide sources for articles started by others. We may do that sometimes; more commonly we do a quick search and can see there are probably sources to support notability. If an article has been tagged for weeks or months and not improved, draftification isn’t some hideous disaster, it’s the appropriate route to take. Taking it to AfD doesn't make sense because we’re not tying to delete it, we’re trying to get the creator to source it properly. Mccapra (talk) 19:20, 23 February 2022 (UTC)[reply]
    No you're not "trying to get the creator to source it properly", you're trying to get someone other than you (who may or may not be the creator) to source it within 6 months while simultaneously making it harder for people to find. If it's sufficiently problematic that it needs to be made less accessible then that's what AfD is for, if it's not actually problematic enough for that then you should not be moving it anywhere. Thryduulf (talk) 00:32, 24 February 2022 (UTC)[reply]
    Well if the creator isn't responding to tags, and nobody else has either in 90 days or whatever we agree, but the topic is likely to be notable, my choice is mark it as patrolled and hope that someone eventually comes along to sort it out, or stop and do the work of sourcing it myself (assuming I can, thought for many I can't), or, as I said above, bring an article lacking sources but likely notable to AfD, which isn't really what AfD is for. Mccapra (talk) 13:04, 24 February 2022 (UTC)[reply]
    AFD is for determining whether or not an article actually "is notable", and establishing that, rather than relying on one person's judgement about whether it's "likely", can be a valuable contribution.
    @Mccapra, you said Draftification is for articles which a patroller thinks are likely to be notable, but where the sourcing is inadequate. I'm curious: Inadequate for what purpose? WhatamIdoing (talk) 17:19, 24 February 2022 (UTC)[reply]
    Inadequate for the purpose of demonstrating notability, e.g. lacking sources, or sourced only to self-published sources, blogs, PR or social media. Mccapra (talk) 05:32, 25 February 2022 (UTC)[reply]
    There is no rule that says articles must provide sourcing that demonstrates notability. We actually have a rule that says the opposite: Wikipedia:Notability#Notability is based on the existence of suitable sources, not on the state of sourcing in an article. WhatamIdoing (talk) 21:40, 26 February 2022 (UTC)[reply]
  • Comment I find that Mccapra has got to the core of this, and I concur with their view. FiddleTimtrent FaddleTalk to me 09:26, 21 February 2022 (UTC)[reply]
  • Support - If a topic is notable, the article can be improved in the mainspace. Darkknight2149 05:15, 25 February 2022 (UTC)[reply]
  • Comment This discussion originally started with examples of several very old articles being wrongly draftified (which seems to me to be about individual editor behaviour rather than anything systematic). That’s already against established consensus but the case was made that the rules needed tightening and firming up. I’ve got no objection to that, if it helps stop inappropriate draftification. As the discussion has moved on though it now sounds like some editors don’t like draft space at all. If the consensus is that “If a topic is notable, the article can be improved in the mainspace” we can just get rid of draft space and stop fretting about time limits. Mccapra (talk) 05:45, 25 February 2022 (UTC)[reply]
  • Support Draftifying articles causes them to be hidden from most of the community, excepting the article creator, New Page Reviews, and AFC reviewers. This impedes the normal editing process that helps fix issues in regular articles, which can cause a page to go stale without attention given by the creator. These drafts then get G13 deleted after 6 months. Draftifying articles should generally not be done unless it is likely the creator will fix the issues present in the article. If an article has unfixable problems, such as notability, the article should just be deleted. If the article has fixable problems, such as verifiability, the normal editing process should handle them. Draftifying is not a miracle cure. It is only intended for very specific situations. 2601:647:5800:1A1F:B59F:66D4:2C8D:EA30 (talk) 00:23, 26 February 2022 (UTC)[reply]
  • Oppose; insufficient evidence that this is actually a problem. If an article is of sufficient quality (or can easily be brought up to sufficient quality), and it has eyes on it and people reviewing it, then it can be rapidly moved back to mainspace, but if it is not then I see no reason why the simple passage of time should provide special protection against draftification. Many people have objected to the idea of articles being draftified with "minimal review" or with few eyes on it - but it is a much bigger problem for a low-quality or deeply-flawed article to exist with minimal review and with few eyes on it. Tossing an article that obscure into draftspace until someone fixes or recreates it is not a serious problem; having articles that have had no real attention paid to them lingering around is a far more serious problem. The criteria that gives an article its "established" status is therefore the number of people who have seen and reviewed it and the number of eyes that are on it, not the mere passing of time. --Aquillion (talk) 00:51, 26 February 2022 (UTC)[reply]
  • Oppose. Too similar to the above proposal. Suggest withdrawing to avoid duplication of !votes/effort. –Novem Linguae (talk) 01:15, 26 February 2022 (UTC)[reply]
    To the closer, the above !vote was made when this section was a separate subheader that may have been the same proposal but with an RfC tag. Chess (talk) (please use {{reply to|Chess}} on reply) 18:31, 6 March 2022 (UTC)[reply]
  • I've got a number of conflicting thoughts on this, and don't know where I stand overall.
    • Banning any subset of draftification is, no question, going to result in an uptick of speedy-deletion requests, and most of those articles will likely be deleted. G11 is applied more leniently in draftspace than mainspace by almost all admins, and of course A7 can't be used on drafts at all. I've seen plenty of mercifully-draftified articles that I'd have speedied had they not been moved.
    • Deletion is the most contentious of the commonly-used administrator-only tools. While, say, a block might raise a ruckus - perhaps even a substantial one - one time out of ten thousand, the overwhelming majority go unremarked and have unanimous consent besides, of course, the blockee. In contrast, there is no entirely uncontroversial use of the delete button except for a subset of G7s. Poor speedy deletion tagging has always been one of the more common reasons for an RFA to fail. Despite that, we hand out the pagemover right like it's candy.
    • Best practice, although not universally followed, for speedy deletion is tag-and-bag: even if you're an admin, you should in almost all cases tag a page for speedy deletion by another admin rather than deleting an untagged one yourself. Moving pages out of mainspace with the redirect suppressed, by contrast, is just about always done entirely unilaterally. I'd be in favor of outright banning the use of suppressredirect for moves out of the main namespace if I thought I could trust CAT:R2 patrollers to verify the page move was correct instead of just mass-deleting the category with Twinkle.
    • It takes six continuous months of zero edits and objections between draftification and G13 deletion. If nobody either notices or cares that a page has gone missing for that long, then our encyclopedia hasn't lost anything it can't afford to.
    • WP:CSD ¶3 says A page is eligible for speedy deletion only if all of its history is also eligible. There's an argument to be made that a page that was once in mainspace and not speedy deletable there doesn't become speedy deletable just because it's been sitting in the draft namespace for six months: it could just be reverted to the mainspace version. —Cryptic 02:40, 26 February 2022 (UTC)[reply]
  • Oppose per WP:CREEP, and the fact that I don't see how this particular time limit is going to improve the encyclopedia. I don't see the problem that this fixes, but I see some problems it causes. Dennis Brown - 02:45, 2 March 2022 (UTC)[reply]
  • Support Any standard for draftification or for that matter new page patrol generally as it is a huge barrier to participation in article translation and a significant if not major cause of editor attrition. Elinruby (talk) 15:52, 3 March 2022 (UTC)[reply]
  • Oppose The downsides are the various ones describes above. The potential upside is solving or reducing a problem, but I don't see where it has been shown that there is a problem that needs solving. The example "problem" discussed in the proposal was just that there is a draft languishing in user space somewhere which I don't see as a real problem. North8000 (talk) 19:56, 3 March 2022 (UTC)[reply]
  • Note - This is not a separate vote. This was an arbitrary section header added when I was adding the RFC template, because I was not aware of Legobot technicalities. It is merely a rehashing of the section above, and is defunct now that someone maintained the RFC template to be in the right place. If you're voting, use the above section, not this one. Soni (talk) 00:36, 6 March 2022 (UTC)[reply]
    @Soni: Now that so many people have voted here that is too late. The easiest thing to do is remove the subheading (which I have now done) and let the two sections flow together. Please strike your bolded instruction not to vote here. SpinningSpark 08:36, 6 March 2022 (UTC)[reply]
    @Spinningspark:  Done. The alternative would be to move the votes there, but this is sufficient enough. Soni (talk) 23:48, 6 March 2022 (UTC)[reply]
    I thought this section was a meta-discussion subsection on whether to make this an RfC. Chess (talk) (please use {{reply to|Chess}} on reply) 18:30, 6 March 2022 (UTC)[reply]
  • Support - 90 days is plenty of time for someone to notice that an article needs to be removed. Otherwise, AFD is a perfectly acceptable solution. Nosferattus (talk) 19:48, 7 March 2022 (UTC)[reply]
  • Oppose As a NPP reviewer I echo the concerns of other editors who know that 90 days is not nearly long enough. ––FormalDude talk 13:58, 8 March 2022 (UTC)[reply]
    @FormalDude, WP:Drafts says that you shouldn't draftify "Old pages, and pages by experienced editors", but instead send them to AFD. How do you apply that? Is "old" a matter of days, months, years? Is "experienced" a matter of edit count, years of editing, number of articles created?
    I suppose the first question ought to be: Did you even know that's been the rule since 2017? WhatamIdoing (talk) 17:05, 8 March 2022 (UTC)[reply]
    Considering I've been here since 2017, yes, I did know. It is purposefully vague. ––FormalDude talk 22:50, 8 March 2022 (UTC)[reply]
    @FormalDude, I've been editing for more than 15 years, and I've made more than a hundred thousand edits. I've also written a substantial portion of our policies. Are there any circumstances under which you think an editor could justify declaring me to be "inexperienced" for the purpose of this rule, or would that be ridiculous?
    You've made 15,000 edits over the last five years. Could someone declare that you are "inexperienced" for the purpose of this rule, or would that be ridiculous? WhatamIdoing (talk) 18:06, 11 March 2022 (UTC)[reply]
    @WhatamIdoing: I'm not really a fan of the hypothetical, but I think I see what you're getting at. I'm not trying to discount any other editors' opinions here with my !vote. I just believe that, for one reason or another, certain editors are aware of the need for a draftification option beyond 90 days.
    Here's a question for you, non-hypothetical: Do you think WP:BLUDGEONING this discussion is aiding your argument? ––FormalDude talk 18:15, 11 March 2022 (UTC)[reply]
    I think that asking questions helps me understand other people's views. Sometimes it even causes me to change my mind. So far, though, my impression is that most of the people opposing limits are opposed to bright-line rules (e.g., like 3RR) rather than the 90-day limit itself. It seems that some opposers would prefer a situation in which they can always argue that it's at least plausible that an editor with your level of experience is what's meant by "inexperienced" in the rules about unilateral draftification and that therefore they can freely dump your articles in the draft namespace instead of sending them to AFD (or not, if they would be embarrassed to have their name on an AFD that's likely to fail). If you object, then the ANI argument is just "Nobody ever told me that if the editor has made 15,000 edits over the last five years that we should consider him 'experienced', so I couldn't be expected to know that. ¯\_ (ツ)_/¯ "
    If we did decide on a specific bright-line rule, then it would be possible to put an Wikipedia:Edit filter on it to warn editors when they attempt to draftify articles that do not qualify under the long-standing rules. Theoretically, this would reduce the opportunity for disputes. WhatamIdoing (talk) 02:56, 14 March 2022 (UTC)[reply]
  • Oppose I mainly work in this area; what I principally do is rescue draftified articles that are notable and significant, but have been neglected. Any arbitrary limits on what gets draftified, or how long the material can remain, serve to cause the rejection of good or at least usable content. I also work at NPP, which is chronically behind; it can not be assumed that something not patrolled for 90 days is suitable for the encyclopedia -- it is more likely to be the opposite. Draftification is the only practical way of handling this, as an intermediate position. DGG ( talk ) 19:43, 8 March 2022 (UTC)[reply]
  • Oppose, though I sympathize with the broad contours of the "support" argument much more than the typical positions on the "oppose" side. I understand the problem that's been raised here, and I do think it is actually a problem, but I do not think this will solve it. If page patrollers and page movers aren't doing those duties correctly, giving them another rule to follow isn't going to make them any better at it. -- asilvering (talk) 02:23, 9 March 2022 (UTC)[reply]
  • Oppose as this seems like instruction creep to me. The backdoor deletion concern should be addressed by this existing consensus, and if editors are not following that, the problem lies with those editors, and people who think others are engaging in backdoor deletion should use the normal channels for resolving behavioural problems. Adding a new rule would not help, and strictly enforcing an arbitrary treshold is generally not a good idea. PJvanMill)talk( 14:55, 9 March 2022 (UTC)[reply]
  • Support if there's a consensus at WP:ATD-I per the RFC then we should specify a time limit, obviously author requests like G7 would be another exception. Crouch, Swale (talk) 09:18, 10 March 2022 (UTC)[reply]
  • Support - Master Of Ninja (talk) 09:57, 10 March 2022 (UTC)[reply]
  • Oppose. In addition to the above, I generally believe that we should make the job of people who "double-check" easier, not harder. They really aren't the problem. JBchrch talk 19:16, 10 March 2022 (UTC)[reply]
  • Oppose - as is, this seems to be more of a short-sighted solution to the AFC backlog than an actual helpful proposal. Adding more constraints is just going to result in articles with potential being sent to the deletion backlog, since leaving a neglected article that's not up to snuff lying around in hopes someone will rescue it isn't something many NPPs are willing to do, myself included. 6 months is generous, yes, but compared to how fast AFDs go - and powers-that-be forbid the article is PRODed or CSD'd - it's a lot more time for the original creator to stop neglecting and actually bring their article to standard. Kirbanzo (userpage - talk - contribs) 21:57, 12 March 2022 (UTC)[reply]
  • Support. G13 has a specific time limit, so DRAFTIFY should too. (For all the opposers saying that arbitrary limits are bad, how do you defend the 6-month countdown on Draft: space? My preferred option: get rid of G13 and make it easier for people to find and improve on drafts.) I wish Reply Tool had change-indent and set-bullet so that I didn't have to edit source in this massive thread. Perhaps we should have arbitrary breaks every x days. ⁓ Pelagicmessages ) 11:18, 13 March 2022 (UTC)[reply]
  • Oppose. Draftication should be an option for inadequate articles that have potential to be brought up to standard. That an inadequate article has slipped under the radar for an arbitrary period of time does not somehow make it adequate. As an aside, draftication is often used when AfD or PROD would be more appropriate and it's better to draftify such articles than have them linger in mainspace just because they're 91+ days old and a PROD was contested by the author or nobody went to the effort of filing an AfD. As others have said above, a solution in search of a problem and an unnecessary extra layer of bureaucracy. HJ Mitchell | Penny for your thoughts? 11:58, 13 March 2022 (UTC)[reply]
  • Weak oppose, would blow in the face of those who try to rein in in the one-source microstub creators. 90 days is certainly better than 30 days, and there also definitely needs to be a better system to vet draftification, but as it currently stands 90 days remains too short. I would be in favor of a 180 days ban, however (although it would certainly create more work at AfD, but AfD has been doing fine lately, so there's a reservoir for this). Weak support for Seraphimblade's 90 days, if and only if previously patrolled. Pilaz (talk) 09:43, 14 March 2022 (UTC)[reply]
  • Support as longer timeframe Happy Editing--IAmChaos 21:08, 14 March 2022 (UTC)[reply]
  • Oppose All sorts of articles can and do get under the radar. Simply having spent more time under the radar is not a valid reason to justify more bureaucracy (having to draftify via AfD or PROD). On top of that, WP:NOTBURO is a valid reason to avoid this kind of WP:INSTRUCTIONCREEP, and would also likely be disregarded in practice per IAR (as removing from mainspace an article which might have potential but is clearly unready and has so far slipped under the radar is a clear improvement). RandomCanadian (talk / contribs) 03:25, 15 March 2022 (UTC)[reply]
  • Oppose: When an AfD was introduced, there was no draftspace. The draftspace is a place where we can put articles that, while we still might want to work on, we do not want the public to see for various reasons. There shouldn't be any sort of time limits for this: regardless of new or old, if articles have issues, the draftspace should be a place to work on the issues. -- Taku (talk) 13:38, 16 March 2022 (UTC)[reply]
  • Support per my comment in the section above. Regards SoWhy 19:37, 16 March 2022 (UTC)[reply]
  • Comment If someone moves an article that has been in the main space for more than 90 days or 6 months to the draft space, I suggest that the article be excluded from G13. Also, I think Wikipedia:Page-move war is already banned. --SilverMatsu (talk) 08:11, 17 March 2022 (UTC)[reply]
  • Oppose in its current form: See Onel5969's objections. MarioGom (talk) 08:51, 18 March 2022 (UTC)[reply]
  • Comment from outside NPP: Much of my wikiwork is in projects where meshs of stubs were developed to layout vast landscapes of articles for future development. In a particular project, no article can be completed without many links to other pages within the project, most of which are stubs at this time. This system has been most useful to me (not to mention inspriational) in helping me expand Geology stubs in particular. The +90 day ban, for all of the suggested pros and cons, would clearly protect this system, so, I support it in that sense.
I recently learned of draftifying. It was honestly disturbing. My fear is that Draftifying is disruptive to large projects with small active staffs. Stubs could disapear from projects without notification; and even if the project notices, it must shift priorities to sustain the structure.
"Draftifying is not backdoor deletion" In the case of long-running stubs, I am concerned that it is de facto deletion without notification, the page silently disappears, its only evidence of passing is red links that can easily go unnoticed. I am now looking at some inexplicable red links as possible stub moves to draft followed by traceless deletion.
If a stub is clearly in a project, I think the reviewer should notify the project's discussion of any thought of draftifying or deletion.
I used to think that "Wikipedia is patient" was an actual Policy, but I can't find the section ....
IveGoneAway (talk) 03:29, 22 March 2022 (UTC) 03:36, 22 March 2022 (UTC)[reply]
IveGoneAway (talk) 10:45, 22 March 2022 (UTC)[reply]
  • Wait, what? Draftifying is permitted without consensus? I would think that might be a surprise to some editors not familiar with NPP.
IveGoneAway (talk) 00:51, 24 March 2022 (UTC)[reply]
  • It also occurred to me that "backdoor deletion" is not neutral, suggesting intent to evade effort or concensus. Well-intentioned editors can draftify, and well-intentioned editors can delete drafts. IveGoneAway (talk) 01:01, 24 March 2022 (UTC)[reply]
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.

Side question re: Draftification

When an article gets draftified, do we require that it have a “sponsor” (ie an editor who agrees to at least attempt to improve it). If not, should we? Blueboar (talk) 20:18, 4 March 2022 (UTC)[reply]

We currently don't. It is assumed that the creator will continue to work on it, but in practice this assumption is regularly incorrect, and indeed the older an article is the less likely the creator is still around to work on it. This is one reason why draftification is delayed deletion in many cases and the problem the main proposal is attempting to solve. As for whether we should require a "sponsor", I'm not sure. We would need to be explicit that a sponsor is not an owner nor could we compel them to be responsible for the actions of others (e.g. no sponsor should be penalised because someone else moved a draft they sponsored to mainspace before it was ready). It's an idea that merits more thought though. Thryduulf (talk) 22:00, 4 March 2022 (UTC)[reply]
No we don't require it, and in the vast majority of cases there isn't one. I fully support the idea that there should be a sponsor before draftification, because if there isn't one then it is pointless. Further, the sponsor should be named in the draft template and it should be obligatory to contact the sponsor (perhaps by bot message) before the page can be deleted just to make sure that they don't want to continue working on it. SpinningSpark 09:12, 5 March 2022 (UTC)[reply]
Wouldn't the sponsor be the creator? The creator of every draft (including those moved from mainspace) receives a bot-delivered notice to their talkpage when there is one month before G13. Most editors who tag the draft with G13 using Twinkle also take advantage of auto noticing the creator's talkpage (though in practice there is rarely enough time between tagging and actual deletion for this second one to have any effect). So creators are being notified. UnitedStatesian (talk) 20:04, 8 March 2022 (UTC)[reply]
You're assuming that the creator is still an active editor. Sometimes we're draftifying articles for an editor who is blocked or who has stopped editing. WhatamIdoing (talk) 18:08, 11 March 2022 (UTC)[reply]
When people ask me to give them the content of a deleted page for further work, I usually put the article in their userspace a) so that it doesn't get auto-deleted [U1 doesn't apply to pages moved to userspace from elsewhere] and b) because if you ask for the content of a deleted page, I expect you to take some responsibility for it. Jo-Jo Eumerus (talk) 18:47, 5 March 2022 (UTC)[reply]
These pages in userspace will still be G13 deleted after six months of inactivity if there is an AfC tag on the page. UnitedStatesian (talk) 20:04, 8 March 2022 (UTC)[reply]
If we are talking about an existing sub-par article that is being draftified from main space into userspace, there shouldn’t be an AFC tag. It’s not an “article for creation” it’s a “rejected article” (that might be reconsidered if worked on further). Blueboar (talk) 19:18, 11 March 2022 (UTC)[reply]
@Blueboar If that's policy, it's not consistently applied. I see mainspace articles be moved to draftspace (instead of userspace) and given AfC tags all the time. Here's an example: [7]. That editor might be acting against policy or guidelines (I have no idea), but if so I would assume they don't know what the policy is rather than that they're deliberately contravening it - they're certainly not doing something abnormal. -- asilvering (talk) 19:52, 11 March 2022 (UTC)[reply]
It depends... I could certainly see a situation where a relatively new article might be sent back to draftspace for additional work... in which case, I think an AfC tag is appropriate. My point was about those that are sent to an editor's userspace... where the AfC tag is not really appropriate. Blueboar (talk) 23:51, 11 March 2022 (UTC)[reply]
Which is why I make sure never to do that with mine and I advise everyone else to never do it, including new editors. Since side deletion through G13 without even a proper AfD discussion for notability is absolute BS nonsense. And so people should actively prevent it from being applicable whenever possible. SilverserenC 00:03, 12 March 2022 (UTC)[reply]
  • When there's discussion of draftification in AfDs I close as delete, I don't automatically do because if no one adopts it, it's just going to rot and be G13ed in six months. However I do note the cases where I'm willing to do so with a request, that we don't need to go through REFUND/DRV. They just need to ping. Star Mississippi 16:54, 15 March 2022 (UTC)[reply]
  • Perspective from outside NPP: I don't think the idea of a "sponsor" is correct. If the mover was willing do improve the article, I should think they would not have moved it; they would have just taken the steps to improve it, whether by directly editing or by coaching someone else to do it. Any intention of the mover asside, the wording of the move places the onus on the creator ("When you feel the article meets"). If the creator is a new guy, the notice ("is not suitable as written to remain published.") comes off as a bit "bite the new guy", IMO.
I think "You break it, You own it" applies in this sense, anyone working to save the Draftified page has fair expectation that the mover should be engaged in helping them; but I don't know if that is commonly the case.
IveGoneAway (talk) 02:17, 22 March 2022 (UTC)[reply]

Possible alternative solution: Change G13 eligibility

One of the main reasons why people object to unilateral draftification seems to be the (real) danger of bypassing deletion processes by draftifying pages that are then deleted under G13 with little checks. Instead of restricting draftification as proposed here, how about we change G13 to exempt such pages from eligibility unless another criterion also applies? So pages could still be draftified without consensus but they can no longer be deleted without consensus, thus removing the main problem of "backdoor deletion".

The text could read something like this:

G13. Abandoned Drafts and Articles for creation submissions

This applies to any pages that have not been edited by a human in six months found in:

  1. Draft namespace,
  2. Userspace with an {{AFC submission}} template
  3. Userspace with no content except the article wizard placeholder text.

Redirects are exempt from G13 deletion.

This does not apply to:

  1. Redirects
  2. Pages that were moved from mainspace without the creator's consent or consensus at a deletion discussion unless they would also meet another speedy deletion criterion if they were still in mainspace.
    In this case, please also add a tag for that speedy deletion criterion. Administrators are advised to include both criteria in their deletion reason.

Pages deleted under G13 may be restored upon request by following the procedure at Wikipedia:Requests for undeletion/G13.

This way, any page that would have been eligible for speedy deletion in mainspace (A7, G11 etc.) can still be deleted under G13 since the move to draftspace was meant to give the creator the chance to improve the article instead of outright deletion. On the other hand, pages that would not have been eligible for speedy deletion back in mainspace will not be eligible for speedy deletion just because they were moved to draftspace or userspace, making backdoor deletions impossible. Any such drafts would either have to be moved back to mainspace or the editor who wishes to delete them has to present a case why the subject is not eligible for inclusion at all (since WP:IMPERFECT as a policy tells us that we should not delete stuff just because it's not written well (the policy literally says "Even poor articles, if they can be improved, are welcome")). Regards SoWhy 09:50, 24 March 2022 (UTC)[reply]

Comments on the upcoming vote on the Universal Code of Conduct (UCoC) enforcement guidelines

Folks, the UCoC is badly written and voting in favour of the enforcement guidelines in the upcoming vote (starting March 7) now reduces the chances of the UCoC ever getting fixed. So I advocate voting "No".

Also note that hundreds of Wikimedia staff (WMF and affiliates) are encouraged to participate in the vote (even if they have never edited any of the wiki projects), and that the threshold to approve the guidelines is just 50% rather than the customary two-thirds majority. To my mind, this means vote is stacked in favour of approval from the beginning.

To give some examples of the problems with the UCoC, take the definition of harassment.

Per the UCoC, this includes: "Disclosure of personal data (Doxing): sharing other contributors' private information, such as name, place of employment, physical or email address without their explicit consent either on the Wikimedia projects or elsewhere, or sharing information concerning their Wikimedia activity outside the projects."

As written, this literally means that Wikimedians will not be allowed to share "information concerning [other contributors'] Wikimedia activity outside the projects". This may not be the intended meaning, but it is the literal meaning – like Fight Club: "The first rule of Fight Club is you do not talk about Fight Club."

What about "place of employment"? There are pages on Wikipedia, in project space and article space, that discuss contributors' place of employment (including by implication, in some cases, the address of that workplace) without their consent. Examples:

Wikipedia editors and arbitrators have in the past commented on such cases to the media ... take this seminal article for example, which was directly responsible for the changes to the WMF Terms of Use outlawing undisclosed paid editing:

What Wikipedians like User:Doctree, User:Dennis Brown and others told that publication about Wiki-PR editors' activity falls foul of the letter of UCoC as presently written, does it not?

Then there are cases like the ones listed below. From the perspective of the UCoC, as written, all the protagonists in these cases ("David r from Meth Productions", "Qworty", "Wifione") were victims rather than perpetrators:

What about the UCoC's definition of "psychological manipulation"? "Psychological manipulation: Maliciously causing someone to doubt their own perceptions, senses, or understanding with the objective to win an argument or force someone to behave the way you want."

What if someone genuinely and honestly subscribes to fringe beliefs, or is just not competent (think Scots Wikipedia)? They will encounter plenty of volunteers who will try to "cause them to doubt their own perceptions, sense, or understanding with the objective to win an argument" ... and "force" them to stop inserting said fringe beliefs into articles!

As written, the UCoC passage about psychological manipulation can be read to criminalise ordinary debate ... but debate is how the Wikipedia sausage is made.

This UCoC passage, if approved, will multiply accusations of "gate-keeping" lobbed against volunteers. There are enough such accusations already, often unjustified; there's no need to provide extra encouragement.

It can also be used arbitrarily against anyone who has ever advocated a point of view, or tried to change another editor's mind, because what is "malicious" is entirely subjective. Think of Russian Wikipedia in the present circumstances ... this passage, as written, could be used to wiki-criminalise anyone who "maliciously causes others to doubt their own perceptions, senses or understanding" (which they gained from watching Russian state TV).

That's before we get to other issues like having a right to be heard ...

So, to my mind there's no choice but to vote no. The UCoC is not fit for purpose. First you fix WHAT you want to enforce, then you vote to enforce it. We haven't done the first thing yet; voting for enforcement now is putting the cart before the horse. --Andreas JN466 14:04, 5 March 2022 (UTC)[reply]

  • Sadly, I have to agree. Part of the problem is that it contains a lot of “CofC jargon” - the sort of overly lawyeristic language that is found in a “typical” corporate or academic code of conduct. Language that sounds nice in the abstract, but does not reflect the reality of how WP actually operates. Blueboar (talk) 15:45, 5 March 2022 (UTC)[reply]
^THIS. ~ ONUnicorn(Talk|Contribs)problem solving 18:17, 17 March 2022 (UTC)[reply]
    • Between the UCoC and its enforcement guidelines it's self-contradictory (at one point it asks us to respect the names that ethnic groups use to describe themselves, but later says that it does not recognize the concept of ethnicity), seemly prohibits sharing any information about anything an editor does on Wikipedia in any venue other than on Wikipedia, can't decide on whether to use "system issues", "systemic issues" or "systematic issues", and is full of basic grammar errors. --Ahecht (TALK
      PAGE
      ) 17:33, 17 March 2022 (UTC)[reply]
      Where does it say that it does not recognize the concept of ethnicity? Levivich 17:41, 17 March 2022 (UTC)[reply]
  • I agree. It seems to be a tool to control the projects. We are no longer a community, but instead, subjects of the Foundation. Mere peasants. No thanks. I volunteered almost 16 years ago to help a project, not to be an unpaid employee suject to the whim of those who are paid, and are uninvested in the "free" part of what we do.. Dennis Brown - 16:32, 5 March 2022 (UTC)[reply]
Per the UCOC enforcement guidelines, I will begin to zealously enforce the UCOC on Wiki when it is passed. The first step will be the MfD of Wikipedia:Lunatic charlatans and User:JzG/charlatans per their use of an insult based on mental illness (the word "lunatic") and implying that the people POV pushing are unable to comprehend reality. Chess (talk) (please use {{reply to|Chess}} on reply) 18:44, 8 March 2022 (UTC)[reply]
  • The whole UCoC thing seems to be going from the particular to the general, which I'm sure is a logical fallacy with a posh name but even though I don't recall the name I know it's a fallacy. Firstly, the Wikimedia Foundation owns the servers, so in an emergency it can, and if the emergency is great enough should, act to enforce its will. Most projects (at least the larger ones) manage to get on quite OK writing their own rules and without a UCoC. We have had a couple of cases where projects have not managed this and descended into nationalism with people who don't follow the party line being blocked or had adminship taken away, which leads to more nationalism. The response to this should be simply to come down hard on those projects quickly, using the WMF's power of ownership, not to enforce a UCoC that attempts to predict everything that might possibly happen on everyone, something that can have no end of money thrown at it without ever being right. This seems to be another of the WMF's make-work projects to use up all of the money that they generate, rather than anything, such as investing in infrastructure, that helps our mission. Phil Bridger (talk) 18:24, 17 March 2022 (UTC)[reply]

Perhaps the possibility should enter into discussions of Wikipedia firing WMF and replacing them with somebody who has a better understanding of what they should be doing. Keeping the servers running and handling the bare minimum administrative and legal items to keep Wikipedia running.....not trying to write rules for or govern us. Even the mere discussion of such might bring some perspective. The WMF structure is currently flawed and prone to going awry. They get to (re)write the "constitution" any way that they want, and have the board members pick the board members. North8000 (talk) 18:07, 17 March 2022 (UTC)[reply]

Anyone who owns the domain and runs the servers will have Terms of Service and a Code of Conduct. There is a reason that all websites have these: they're more or less a legal requirement. The only reasonable question is what it should say. The idea of someone keeping the servers running and not regulating how they're used is total fantasy, because the people who run the servers are required to regulate them (in accordance with the law). Levivich 18:15, 17 March 2022 (UTC)[reply]
I think that the legal requirements are about 1/20th of what WMF is seeking for themselves.North8000 (talk) 19:47, 17 March 2022 (UTC)[reply]

Should good articles be nominated for deletion?

Wikipedia:Articles for deletion/Historical background of the 2014 pro-Russian unrest in Ukraine

--Knight Skywalker (talk) 14:06, 5 March 2022 (UTC)[reply]

My answer was to the implicit question "should deletion be prohibited for GA's?". In practice, deletion of a GA would rarely be a suitable action. North8000 (talk) 20:22, 20 March 2022 (UTC)[reply]
I agree with that, and, in an ideal world, no article that should be deleted would get anywhere near being a GA. Unfortunately this is not an ideal world, so "rarely" is not the same as "never", Phil Bridger (talk) 21:01, 20 March 2022 (UTC)[reply]
  • Yes, they obviously can be deleted (and sometimes even should be), with a caveat. GA status means that an article has had a lot of fine-combed attention paid to it - while it is definitely true that GA doesn't evaluate articles for notability or some of the other reasons we might delete them, it should at least be very unusual for such core problems to go unremarked. In particular the sourcing requirements for a GA would usually force an article to pass the WP:GNG. Likewise the focus on making sure something is well-sourced should normally prevent a hoax from passing GA (but as we've seen that isn't always the case.) --Aquillion (talk) 15:54, 20 March 2022 (UTC)[reply]
  • In theory, good articles should be deleted if is found that the topic doesn't meet the notability criteria. However, such an incident would be rare; good articles require all the main aspects of the topic to be addressed and various aspects like material that has been challenged to be sourced, along with there being no original research or plagiarism. This means that if the main aspects of the topic being addressed are incredibly minuscule without original research, it should be noticed by a good article nomination reviewer. However, it is possible for a reviewer to miss the problems thereof, especially since only one reviewer is needed for a good article nomination to pass. As a result, if an editor has a valid case that supports the notion that a good article is not notable, they should be able to nominate it for deletion. They should be aware, however, that their case will be more carefully scrutinized in such a deletion nomination. In regards to the discussion you have linked, it appears that there was a consensus that Historical background of the 2014 pro-Russian unrest in Ukraine should be kept for reasons outside of it being a good article, as they did notice improvements to its neutrality and synthesis could be addressed. Lazman321 (talk) 18:16, 20 March 2022 (UTC)[reply]

Universal Code of Conduct Enforcement guidelines ratification voting open from 7 to 21 March 2022

Hello, the vote mentioned above is now live. Those ready to cast their ballots can jump to votewiki locally via Special:SecurePoll/vote/802. For more details, see below or Voting page on Meta-wiki. Xeno (WMF) (talk) 00:19, 7 March 2022 (UTC)[reply]


You can find this message translated into additional languages on Meta-wiki.

Hello everyone,

The ratification voting process for the revised enforcement guidelines of the Universal Code of Conduct (UCoC) is now open! Voting commenced on SecurePoll on 7 March 2022 and will conclude on 21 March 2022. Please read more on the voter information and eligibility details.

The Universal Code of Conduct (UCoC) provides a baseline of acceptable behavior for the entire movement. The revised enforcement guidelines were published 24 January 2022 as a proposed way to apply the policy across the movement. You can read more about the UCoC project.

You can also comment on Meta-wiki talk pages in any language. You may also contact the team by email: ucocproject(_AT_)wikimedia.org

Sincerely,

Movement Strategy and Governance
Wikimedia Foundation


Let me know if you have questions. Xeno (WMF) (talk) 00:19, 7 March 2022 (UTC)[reply]

Update on Universal Code of Conduct Enforcement guidelines ratification vote (as of 18 March)

Hi all,

With a little under 4 days left in the poll, I can share that there are 1518 voters as of 17 March 21:00 UTC.

There were 564 voters with a home wiki registration of enwiki. By homewiki, enwiki represents 34% of the electorate.

Keeping in mind that homewiki isn't always indicative of where an editor is active, here are some of the other votership numbers:

Day 11
enwiki: 564 (37.3%)dewiki: 168 (11.1%)frwiki: 90 (6.0%)eswiki: 69 (4.6%)ruwiki: 71 (4.7%)plwiki: 65 (4.3%)metawiki: 50 (3.3%)zhwiki: 46 (3.0%)jawiki: 44 (2.9%)itwiki: 45 (3.0%)commons: 29 (1.9%)arwiki: 20 (1.3%)cswiki: 19 (1.3%)ptwiki: 18 (1.2%)nlwiki: 17 (1.1%)kowiki: 17 (1.1%)trwiki: 15 (1.0%)cawiki: 11 (0.7%)idwiki: 10 (0.7%)78 others: 144 (9.5%)
  •   enwiki: 564 (37.3%)
  •   dewiki: 168 (11.1%)
  •   frwiki: 90 (6.0%)
  •   eswiki: 69 (4.6%)
  •   ruwiki: 71 (4.7%)
  •   plwiki: 65 (4.3%)
  •   metawiki: 50 (3.3%)
  •   zhwiki: 46 (3.0%)
  •   jawiki: 44 (2.9%)
  •   itwiki: 45 (3.0%)
  •   commons: 29 (1.9%)
  •   arwiki: 20 (1.3%)
  •   cswiki: 19 (1.3%)
  •   ptwiki: 18 (1.2%)
  •   nlwiki: 17 (1.1%)
  •   kowiki: 17 (1.1%)
  •   trwiki: 15 (1.0%)
  •   cawiki: 11 (0.7%)
  •   idwiki: 10 (0.7%)
  •   78 others: 144 (9.5%)

The poll can be accessed locally here: Special:SecurePoll/vote/802.

Let me know if you have any questions. Xeno (WMF) (talk) 02:22, 18 March 2022 (UTC)[reply]

Huh… missed that. Ok, but I still find the low turnout disturbing. Blueboar (talk) 13:24, 18 March 2022 (UTC)[reply]
Indeed! Donald Albury 17:14, 18 March 2022 (UTC)[reply]
Blueboar/xaosflux/Donald Albury: Please feel free to advertise the vote further! We've seen more than 100 new votes since last writing (40 coming from enwiki homewiki registrants): total 1623 for this data set, with another 6 projects represented. While it's not a perfect comparison, at the same time the MCDC Election vote, there were 855 votes - that election ended with 1018 voters. Xeno (WMF) (talk) 00:54, 19 March 2022 (UTC)[reply]
I believe Zuz was planning to notify every Wikiproject, after a small trial run. I am not certain what is happening with that, though. BilledMammal (talk) 01:01, 19 March 2022 (UTC)[reply]
@BilledMammal: I realised that the Wikiprojects are only on English Wikipedia. But we want to encourage voting from all projects. Hence, I decided to post on other projects instead of only the English Wikiprojects.Zuz (WMF) (talk) 09:08, 20 March 2022 (UTC)[reply]
Day 12
enwiki: 604 (37.2%)dewiki: 173 (10.7%)frwiki: 92 (5.7%)eswiki: 72 (4.4%)ruwiki: 71 (4.4%)plwiki: 69 (4.3%)metawiki: 50 (3.1%)zhwiki: 48 (3.0%)jawiki: 49 (3.0%)itwiki: 47 (2.9%)commons: 34 (2.1%)arwiki: 21 (1.3%)cswiki: 21 (1.3%)ptwiki: 20 (1.2%)nlwiki: 18 (1.1%)kowiki: 17 (1.0%)trwiki: 16 (1.0%)cawiki: 11 (0.7%)idwiki: 23 (1.4%)84 more: 167 (10.3%)
  •   enwiki: 604 (37.2%)
  •   dewiki: 173 (10.7%)
  •   frwiki: 92 (5.7%)
  •   eswiki: 72 (4.4%)
  •   ruwiki: 71 (4.4%)
  •   plwiki: 69 (4.3%)
  •   metawiki: 50 (3.1%)
  •   zhwiki: 48 (3.0%)
  •   jawiki: 49 (3.0%)
  •   itwiki: 47 (2.9%)
  •   commons: 34 (2.1%)
  •   arwiki: 21 (1.3%)
  •   cswiki: 21 (1.3%)
  •   ptwiki: 20 (1.2%)
  •   nlwiki: 18 (1.1%)
  •   kowiki: 17 (1.0%)
  •   trwiki: 16 (1.0%)
  •   cawiki: 11 (0.7%)
  •   idwiki: 23 (1.4%)
  •   84 more: 167 (10.3%)

A few numbers were mismatched; fixed. Xeno (WMF) (talk) 02:23, 20 March 2022 (UTC)[reply]

Update on Universal Code of Conduct Enforcement guidelines ratification vote (as of 19 March)

Just a reminder that the home wiki (or "Domain" in the voter list) value used for these charts is set at the time of registration and does not always reflect where a user is active.

To explore this further: looking at March 18 data when the voter count was 1586, there were 130 enwiki registrants with most edited at other projects: wikidata (31); commons (25); and the rest between at least 37 other projects. at the same time, enwiki represented the "most edited" wiki for 32 non-enwiki registrant voters (6 from commons+wikidata, and the rest from another 15 projects). (I realize that "most edited wiki" may still not represent where a user is most active, so stay tuned...)

The chart below is from 20:00 UTC on 19 March; there were 1803 votes (+180) with 660 registered at enwiki (+56) and there were 108 projects with voters. Xeno (WMF) (talk) 02:23, 20 March 2022 (UTC)[reply]

Day 13
enwiki: 660 (36.6%)dewiki: 187 (10.4%)frwiki: 107 (5.9%)ruwiki: 86 (4.8%)eswiki: 74 (4.1%)plwiki: 73 (4.0%)zhwiki: 60 (3.3%)jawiki: 57 (3.2%)itwiki: 54 (3.0%)metawiki: 52 (2.9%)commons: 38 (2.1%)cswiki: 23 (1.3%)idwiki: 23 (1.3%)arwiki: 23 (1.3%)ptwiki: 22 (1.2%)nlwiki: 18 (1.0%)kowiki: 18 (1.0%)trwiki: 16 (0.9%)hewiki: 14 (0.8%)cawiki: 12 (0.7%)fawiki: 9 (0.5%)87 more: 177 (9.8%)
  •   enwiki: 660 (36.6%)
  •   dewiki: 187 (10.4%)
  •   frwiki: 107 (5.9%)
  •   ruwiki: 86 (4.8%)
  •   eswiki: 74 (4.1%)
  •   plwiki: 73 (4.0%)
  •   zhwiki: 60 (3.3%)
  •   jawiki: 57 (3.2%)
  •   itwiki: 54 (3.0%)
  •   metawiki: 52 (2.9%)
  •   commons: 38 (2.1%)
  •   cswiki: 23 (1.3%)
  •   idwiki: 23 (1.3%)
  •   arwiki: 23 (1.3%)
  •   ptwiki: 22 (1.2%)
  •   nlwiki: 18 (1.0%)
  •   kowiki: 18 (1.0%)
  •   trwiki: 16 (0.9%)
  •   hewiki: 14 (0.8%)
  •   cawiki: 12 (0.7%)
  •   fawiki: 9 (0.5%)
  •   87 more: 177 (9.8%)

Please share the information links with interested users: Project OverviewUniversal Code of ConductEnforcement guidelines (proposed) • VotingVoter information

The poll can be accessed locally via the jump page: Special:SecurePoll/vote/802 and closes 23:59:59 UTC on 21 March 2022. Xeno (WMF) (talk) 02:23, 20 March 2022 (UTC)[reply]

@Xeno (WMF) Any idea how WMF staff fit into the pie chart? --Ahecht (TALK
PAGE
) 15:04, 20 March 2022 (UTC)[reply]
Ahect: 42 of 2017 voters had "(WMF)" or "-WMF" in their username as of right now. Xeno (WMF) (talk) 15:24, 20 March 2022 (UTC)[reply]
Staff accounts have been created on Meta-Wiki for the last ~10 years, so those will be recorded with Meta-Wiki as the home wiki. Whatamidoing (WMF) (talk) 20:53, 21 March 2022 (UTC)[reply]

Update on Universal Code of Conduct Enforcement guidelines ratification vote (as of 20 March)

There are just about 23 hours left in the voting period which ends at 23:59:59 UTC 21 March. As the time of this post, 2099 votes had been cast.

As of 16:00 on 20 March 2022 there were an additional 219 votes raising the votes cast to 2022 (!). English Wikipedia home wiki registrants have contributed 734 votes (+74 since last), representing 36.3% of the votership - close to its eligible voter representation of 34%. Another 8 wikis had registered voters for a total of 115 projects represented. Xeno (WMF) (talk) 00:54, 21 March 2022 (UTC)[reply]

Day 14
enwiki: 734 (36.3%)dewiki: 210 (10.4%)frwiki: 121 (6.0%)ruwiki: 96 (4.7%)plwiki: 83 (4.1%)eswiki: 80 (4.0%)jawiki: 73 (3.6%)zhwiki: 73 (3.6%)itwiki: 59 (2.9%)metawiki: 54 (2.7%)commons: 42 (2.1%)idwiki: 26 (1.3%)ptwiki: 25 (1.2%)cswiki: 24 (1.2%)arwiki: 24 (1.2%)nlwiki: 21 (1.0%)kowiki: 20 (1.0%)trwiki: 18 (0.9%)cawiki: 15 (0.7%)hewiki: 14 (0.7%)fawiki: 11 (0.5%)94 more: 199 (9.8%)
  •   enwiki: 734 (36.3%)
  •   dewiki: 210 (10.4%)
  •   frwiki: 121 (6.0%)
  •   ruwiki: 96 (4.7%)
  •   plwiki: 83 (4.1%)
  •   eswiki: 80 (4.0%)
  •   jawiki: 73 (3.6%)
  •   zhwiki: 73 (3.6%)
  •   itwiki: 59 (2.9%)
  •   metawiki: 54 (2.7%)
  •   commons: 42 (2.1%)
  •   idwiki: 26 (1.3%)
  •   ptwiki: 25 (1.2%)
  •   cswiki: 24 (1.2%)
  •   arwiki: 24 (1.2%)
  •   nlwiki: 21 (1.0%)
  •   kowiki: 20 (1.0%)
  •   trwiki: 18 (0.9%)
  •   cawiki: 15 (0.7%)
  •   hewiki: 14 (0.7%)
  •   fawiki: 11 (0.5%)
  •   94 more: 199 (9.8%)

Please share the information links with interested users: Project OverviewUniversal Code of ConductEnforcement guidelines (proposed) • VotingVoter information

The poll can be accessed locally via the jump page: Special:SecurePoll/vote/802. Xeno (WMF) (talk) 00:54, 21 March 2022 (UTC)[reply]

@Xeno (WMF): "the voting period which ends at 23:59:59 UTC 21 March" - well it's 01:04 UTC 21 Mar 2022 and I followed the link you gave and got the message "This election has finished, you can no longer vote" so either you were wrong about when the poll closes, or the poll has been closed early. DuncanHill (talk) 01:06, 21 March 2022 (UTC)[reply]
@DuncanHill: Apparently the local link is broken. m:Special:SecurePoll/vote/391 works, though. --Yair rand (talk) 01:24, 21 March 2022 (UTC)[reply]
Thank you DuncanHill, there was a mismatch between the local jump poll and the votewiki poll. It is working again. Xeno (WMF) (talk) 01:23, 21 March 2022 (UTC)[reply]
Thanks @Yair rand: As Xeno says, it is working again. DuncanHill (talk) 01:26, 21 March 2022 (UTC)[reply]
Thanks as well Yair rand. I'm attempting to handle "real life" at the moment, but this unfinished miasm of the UCOC, does need to be looked into, before we even begin to think about enforcement, in my not so humble opinion... (Please see my comments here for just the tip of the iceberg.) - jc37 08:10, 21 March 2022 (UTC)[reply]
Thanks for the !ping waddie96 ★ (talk) 13:16, 21 March 2022 (UTC)[reply]
Thank you for the ping. I am however not eligible to vote in this poll. It is a sad irony that those of us who no longer feel comfortable contributing as a result of WMF actions, including in forcing through the UCoC, are disenfranchised from opposing it. Needless to say, it does nothing to encourage me to return to participating more actively... WJBscribe (talk) 16:39, 21 March 2022 (UTC)[reply]
From the same set of 2022 voters: the named projects in the chart above represent 84.1% of the electorate; this chart shows turnout from the 199 voters in the "94 more". Xeno (WMF) (talk) 03:12, 21 March 2022 (UTC)[reply]
Day 14 - 94 more projects
svwiki: 9 (7.7%)wikidatawiki: 8 (6.8%)huwiki: 8 (6.8%)ukwiki: 7 (6.0%)viwiki: 7 (6.0%)enwiktionary: 7 (6.0%)fiwiki: 6 (5.1%)thwiki: 6 (5.1%)bnwiki: 6 (5.1%)hrwiki: 6 (5.1%)frwikisource: 6 (5.1%)mediawiki: 5 (4.3%)srwiki: 5 (4.3%)nowiki: 4 (3.4%)elwiki: 4 (3.4%)incubator: 4 (3.4%)nlwikimedia: 4 (3.4%)etwiki: 3 (2.6%)skwiki: 3 (2.6%)plwikisource: 3 (2.6%)eswikinews: 3 (2.6%)12 projects: 2 (1.7%)61 projects: 1 (0.9%)
  •   svwiki: 9 (7.7%)
  •   wikidatawiki: 8 (6.8%)
  •   huwiki: 8 (6.8%)
  •   ukwiki: 7 (6.0%)
  •   viwiki: 7 (6.0%)
  •   enwiktionary: 7 (6.0%)
  •   fiwiki: 6 (5.1%)
  •   thwiki: 6 (5.1%)
  •   bnwiki: 6 (5.1%)
  •   hrwiki: 6 (5.1%)
  •   frwikisource: 6 (5.1%)
  •   mediawiki: 5 (4.3%)
  •   srwiki: 5 (4.3%)
  •   nowiki: 4 (3.4%)
  •   elwiki: 4 (3.4%)
  •   incubator: 4 (3.4%)
  •   nlwikimedia: 4 (3.4%)
  •   etwiki: 3 (2.6%)
  •   skwiki: 3 (2.6%)
  •   plwikisource: 3 (2.6%)
  •   eswikinews: 3 (2.6%)
  •   12 projects: 2 (1.7%)
  •   61 projects: 1 (0.9%)

Update on Universal Code of Conduct Enforcement guidelines ratification vote as of 21 March 10:30 UTC - poll closes 21 March 2022 23:59 UTC

There is under 7 hours left in the poll, which will close at 23:59:59 UTC 21 March 2022.

Here are the votership numbers when 2174 votes (+152) were cast: 124 projects (+9) with votes; 799 from enwiki home wiki registrants (+65). Please take note of the data caveats in the section above. Xeno (WMF) (talk) 17:11, 21 March 2022 (UTC)[reply]

Day 15
enwiki: 799 (36.8%)dewiki: 220 (10.1%)frwiki: 125 (5.7%)ruwiki: 103 (4.7%)plwiki: 97 (4.5%)eswiki: 82 (3.8%)zhwiki: 80 (3.7%)jawiki: 79 (3.6%)itwiki: 64 (2.9%)metawiki: 54 (2.5%)commons: 45 (2.1%)idwiki: 28 (1.3%)ptwiki: 26 (1.2%)arwiki: 26 (1.2%)cswiki: 24 (1.1%)nlwiki: 21 (1.0%)kowiki: 21 (1.0%)trwiki: 20 (0.9%)cawiki: 17 (0.8%)hewiki: 15 (0.7%)fawiki: 13 (0.6%)103 more: 215 (9.9%)
  •   enwiki: 799 (36.8%)
  •   dewiki: 220 (10.1%)
  •   frwiki: 125 (5.7%)
  •   ruwiki: 103 (4.7%)
  •   plwiki: 97 (4.5%)
  •   eswiki: 82 (3.8%)
  •   zhwiki: 80 (3.7%)
  •   jawiki: 79 (3.6%)
  •   itwiki: 64 (2.9%)
  •   metawiki: 54 (2.5%)
  •   commons: 45 (2.1%)
  •   idwiki: 28 (1.3%)
  •   ptwiki: 26 (1.2%)
  •   arwiki: 26 (1.2%)
  •   cswiki: 24 (1.1%)
  •   nlwiki: 21 (1.0%)
  •   kowiki: 21 (1.0%)
  •   trwiki: 20 (0.9%)
  •   cawiki: 17 (0.8%)
  •   hewiki: 15 (0.7%)
  •   fawiki: 13 (0.6%)
  •   103 more: 215 (9.9%)
A breakdown of the additional 103 projects (percentages not to scale) -
svwiki: 10 (8.2%)huwiki: 8 (6.6%)wikidatawiki: 8 (6.6%)enwiktionary: 8 (6.6%)viwiki: 7 (5.7%)ukwiki: 7 (5.7%)bnwiki: 6 (4.9%)hrwiki: 6 (4.9%)fiwiki: 6 (4.9%)frwikisource: 6 (4.9%)thwiki: 6 (4.9%)srwiki: 5 (4.1%)mediawiki: 5 (4.1%)elwiki: 4 (3.3%)nlwikimedia: 4 (3.3%)nowiki: 4 (3.3%)incubator: 4 (3.3%)etwiki: 3 (2.5%)plwikisource: 3 (2.5%)eswikinews: 3 (2.5%)skwiki: 3 (2.5%)orwiki: 3 (2.5%)15 projects: 2 (1.6%)65 projects: 1 (0.8%)
  •   svwiki: 10 (8.2%)
  •   huwiki: 8 (6.6%)
  •   wikidatawiki: 8 (6.6%)
  •   enwiktionary: 8 (6.6%)
  •   viwiki: 7 (5.7%)
  •   ukwiki: 7 (5.7%)
  •   bnwiki: 6 (4.9%)
  •   hrwiki: 6 (4.9%)
  •   fiwiki: 6 (4.9%)
  •   frwikisource: 6 (4.9%)
  •   thwiki: 6 (4.9%)
  •   srwiki: 5 (4.1%)
  •   mediawiki: 5 (4.1%)
  •   elwiki: 4 (3.3%)
  •   nlwikimedia: 4 (3.3%)
  •   nowiki: 4 (3.3%)
  •   incubator: 4 (3.3%)
  •   etwiki: 3 (2.5%)
  •   plwikisource: 3 (2.5%)
  •   eswikinews: 3 (2.5%)
  •   skwiki: 3 (2.5%)
  •   orwiki: 3 (2.5%)
  •   15 projects: 2 (1.6%)
  •   65 projects: 1 (0.8%)

Please share the information links with interested users: Project OverviewUniversal Code of ConductEnforcement guidelines (proposed) • VotingVoter information

The poll is accepting votes via m:Special:SecurePoll/vote/391 until 23:59:59 UTC 21 March 2022. Xeno (WMF) (talk) 17:11, 21 March 2022 (UTC)[reply]

Universal Code of Conduct Enforcement guidelines ratification vote now closed - distribution breakdown

Voting closed with 2352 votes across 128 home wiki projects. The final results from the voting process will be announced here on Meta-wiki, along with the relevant statistics and a summary of comments as soon as they are available.

67 additional local votes were cast bringing the total number of enwiki registrants voting to 866 (36.82% of all voters). By comparison, enwiki registrants represent 33.95% of the electorate.

As mentioned above, the 'home wiki' value used in these charts does not necessarily represent where a user was active during the eligibility period.

These figures should also be considered preliminary.

enwiki: 866 (36.8%)dewiki: 233 (9.9%)frwiki: 134 (5.7%)ruwiki: 119 (5.1%)plwiki: 109 (4.6%)eswiki: 87 (3.7%)jawiki: 81 (3.4%)zhwiki: 81 (3.4%)itwiki: 69 (2.9%)metawiki: 57 (2.4%)commons: 51 (2.2%)idwiki: 31 (1.3%)ptwiki: 27 (1.1%)arwiki: 26 (1.1%)cswiki: 26 (1.1%)nlwiki: 24 (1.0%)kowiki: 21 (0.9%)trwiki: 21 (0.9%)cawiki: 20 (0.9%)hewiki: 17 (0.7%)fawiki: 13 (0.6%)107 addl: 238 (10.1%)
  •   enwiki: 866 (36.8%)
  •   dewiki: 233 (9.9%)
  •   frwiki: 134 (5.7%)
  •   ruwiki: 119 (5.1%)
  •   plwiki: 109 (4.6%)
  •   eswiki: 87 (3.7%)
  •   jawiki: 81 (3.4%)
  •   zhwiki: 81 (3.4%)
  •   itwiki: 69 (2.9%)
  •   metawiki: 57 (2.4%)
  •   commons: 51 (2.2%)
  •   idwiki: 31 (1.3%)
  •   ptwiki: 27 (1.1%)
  •   arwiki: 26 (1.1%)
  •   cswiki: 26 (1.1%)
  •   nlwiki: 24 (1.0%)
  •   kowiki: 21 (0.9%)
  •   trwiki: 21 (0.9%)
  •   cawiki: 20 (0.9%)
  •   hewiki: 17 (0.7%)
  •   fawiki: 13 (0.6%)
  •   107 addl: 238 (10.1%)

Here is a breakdown of the 139 votes from 24 further projects with between 10 and 3 voters:

enwikt: 10 (7.2%)svwiki: 10 (7.2%)huwiki: 9 (6.5%)wikidata: 9 (6.5%)ukwiki: 9 (6.5%)bnwiki: 8 (5.8%)viwiki: 7 (5.0%)hrwiki: 7 (5.0%)mediawiki: 7 (5.0%)fiwiki: 6 (4.3%)frwikisource: 6 (4.3%)thwiki: 6 (4.3%)skwiki: 6 (4.3%)srwiki: 5 (3.6%)elwiki: 4 (2.9%)nlwikimedia: 4 (2.9%)nowiki: 4 (2.9%)incubator: 4 (2.9%)etwiki: 3 (2.2%)plwikisource: 3 (2.2%)eswikinews: 3 (2.2%)rowiki: 3 (2.2%)bawiki: 3 (2.2%)pawiki: 3 (2.2%)
  •   enwikt: 10 (7.2%)
  •   svwiki: 10 (7.2%)
  •   huwiki: 9 (6.5%)
  •   wikidata: 9 (6.5%)
  •   ukwiki: 9 (6.5%)
  •   bnwiki: 8 (5.8%)
  •   viwiki: 7 (5.0%)
  •   hrwiki: 7 (5.0%)
  •   mediawiki: 7 (5.0%)
  •   fiwiki: 6 (4.3%)
  •   frwikisource: 6 (4.3%)
  •   thwiki: 6 (4.3%)
  •   skwiki: 6 (4.3%)
  •   srwiki: 5 (3.6%)
  •   elwiki: 4 (2.9%)
  •   nlwikimedia: 4 (2.9%)
  •   nowiki: 4 (2.9%)
  •   incubator: 4 (2.9%)
  •   etwiki: 3 (2.2%)
  •   plwikisource: 3 (2.2%)
  •   eswikinews: 3 (2.2%)
  •   rowiki: 3 (2.2%)
  •   bawiki: 3 (2.2%)
  •   pawiki: 3 (2.2%)

The remaining 99 votes are from projects with between 1 and 2 voters. Some single voters could be grouped into a larger language code. 38 other wikis had a single voter not grouped with this chart.


en: 12 (19.7%)de: 7 (11.5%)pl: 4 (6.6%)zh+: 4 (6.6%)ha: 3 (4.9%)ru: 3 (4.9%)eowiki: 2 (3.3%)glwiki: 2 (3.3%)igwiki: 2 (3.3%)kawiki: 2 (3.3%)mkwiki: 2 (3.3%)newiki: 2 (3.3%)orwiki: 2 (3.3%)sqwiki: 2 (3.3%)urwiki: 2 (3.3%)es: 2 (3.3%)fr: 2 (3.3%)it: 2 (3.3%)oc: 2 (3.3%)sv: 2 (3.3%)
  •   en: 12 (19.7%)
  •   de: 7 (11.5%)
  •   pl: 4 (6.6%)
  •   zh+: 4 (6.6%)
  •   ha: 3 (4.9%)
  •   ru: 3 (4.9%)
  •   eowiki: 2 (3.3%)
  •   glwiki: 2 (3.3%)
  •   igwiki: 2 (3.3%)
  •   kawiki: 2 (3.3%)
  •   mkwiki: 2 (3.3%)
  •   newiki: 2 (3.3%)
  •   orwiki: 2 (3.3%)
  •   sqwiki: 2 (3.3%)
  •   urwiki: 2 (3.3%)
  •   es: 2 (3.3%)
  •   fr: 2 (3.3%)
  •   it: 2 (3.3%)
  •   oc: 2 (3.3%)
  •   sv: 2 (3.3%)

See more statistics here.

Thank you for your input in this process. Xeno (WMF) (talk) 02:31, 22 March 2022 (UTC)[reply]

Seeing as the sports discussion is now closed, I think it's time we examine another notability policy: WP:NPOL, which applies to judges and politicians. NPOL reads in full, minus the explanatory footnotes:

The following are presumed to be notable:

  • Politicians and judges who have held international, national, or (for countries with federal or similar systems of government) state/province–wide office, or have been members of legislative bodies at those levels. This also applies to people who have been elected to such offices but have not yet assumed them.
  • Major local political figures who have received significant press coverage.

Just being an elected local official, or an unelected candidate for political office, does not guarantee notability, although such people can still be notable if they meet the general notability guideline.

I have two main quibbles with this that I think should be reconsidered. Firstly, in my experience officials at the state/province level, concerning both leaders of executive departments and legislators, do not tend to necessarily get the requisite SIGCOV in RS necessary to write even a basic article by virtue of simply holding such offices. I've written articles concerning officials/politics at the state/province level in both the United States and the (1960s) Democratic Republic of the Congo. It is really hard to find SIGCOV of some these people. Most provincial assemblymen in the Congo during the 1960s, and most of the provincial ministers as well are not covered in RS, or at best are named in sources and maybe tied to a public comment or two but nothing beyond. Even some of the Royal Museum for Central Africa's monographs on provincial history don't say much about the ministers beyond when they held certain jobs. If you disagree, I welcome you to try and write some of those yourself. As for the American state legislators, standard government bios and newspaper coverage in the recent years has been helpful, but I'd wager to estimate that for the pre-1900 era, many/most of these legislators are only known by their name and the constituency they were elected to, nothing more. Those that are known and have decent Wikipedia articles seem to more likely than not have held more important offices later in life or had distinguished military and business careers. In short, I think automatic presumption of notability for simply holding some sort of subnational provincial/state office is a bad idea. I do not think this status serves as a genuine predictor for good SIGCOV being locatable.

Secondly, the Major local political figures who have received significant press coverage seems like a bowdlerized way of suggesting that GNG is the standard...why not simplify it to that? Of course, I personally think GNG should just be the only standard for almost everything, but that's my personal preference. Anyways, I think these points are worthy of community consideration. -Indy beetle (talk) 09:40, 7 March 2022 (UTC)[reply]

  • I don't think the NSPORT RfC is a good example to follow. It was a 6 week-long behemoth of a discussion where the original proposal and the vast majority of sub-proposals trainwrecked and in the end only led to only two, relatively minor changes. Why not propose these changes on the talk page of WP:NPOL and discuss it with editors interested in the topic first? – Joe (talk) 10:14, 7 March 2022 (UTC)[reply]
    Agree with Joe. I'd also say that it might be a good idea to wait after the NSPORTS discussion has finished (a few weeks maybe) just so there is more interest in discussion your proposed changes. I feel many might see this as yet another NSPORTS trainwreck if you start the discussion in too quick of a succession. A. C. SantacruzPlease ping me! 10:23, 7 March 2022 (UTC)[reply]
    "two, relatively minor changes"? Hardly. (1) The SNGs for American football, baseball, basketball, rugby, cricket, and association football were rescinded. (2) a new mandate for SIGCOV was adopted, barring the creation of substubs sourced only to databases. And (3) the presumption of notability has also been excised as well. Nothing "minor" about these changes. Cbl62 (talk) 23:03, 7 March 2022 (UTC)[reply]
    Strongly agree. The close of NSPORT went from a disagreement about the utility of micro-stubs created from (generally reliable) databases to ripping the floor from the clarity of the SNG. This was a big change and I don't think we will understand the magnitude of the changes for a while. Enos733 (talk) 23:36, 7 March 2022 (UTC)[reply]
    I mean, minor relative to the original proposal to "abolish the current version of NSPORTS". Still, I agree that these changes were not well thought through and have an unclear level of consensus; another reason not to pick up the habit of trying to rewrite long-standing guidelines in overcomplicated mega-RfCs. – Joe (talk) 08:51, 9 March 2022 (UTC)[reply]
  • One advantage of having a reasonably clear-cut notability guideline in this area is that we can avoid many of the otherwise inevitable arguments about notability, which would be dominated by people claiming that the person who agrees with them about politics is notable but the person who disagrees is not. Phil Bridger (talk) 21:28, 7 March 2022 (UTC)[reply]
I absolutely agree with Phil Bridger. Simplicity is key. There will always be edge cases but having stubs about members of the Arunachal Pradesh state legislature in 1975 is preferable to having long debates about whether we should have such stubs. NPOL is pretty straightforward as it stands. Mccapra (talk) 12:13, 17 March 2022 (UTC)[reply]
  • I also don't think the NSPORT RfC is a good example to follow. The initial proposal and the close failed to understand the purpose of the SNG and its connection to the values of this project. As I mentioned late in the discussion, "which sets are worthy of being complete? To answer this involves a certain about of real world judgment of what is considered important and a certain amount of "should we expect everyone in the set to have independent coverage.... I think this is generally what the SNG is supposed to do, suggest people/events meeting a defined criteria have a certain real world importance and are likely to have some substantive coverage". As a community we have the core values of anyone can edit (so the editors decide, to a certain degree what is worthy to write about) and that the goal is to create a verifiable encyclopedia (also reflected in WP:NOTPAPER). As a community, we decided that individuals serving in government with law-making powers have both real-world importance and are likely to have biographical information in reliable sources. Without this clear bright line, we are likely to have longer and more intensive debates over whether the coverage of a subject is substantive (see WP:Articles for deletion/Jamie Fitzgerald (American football) for a preview of what might happen without clear lines). --Enos733 (talk) 23:01, 7 March 2022 (UTC)[reply]
As I do believe in clarity for editors, I am working on a draft of guidance of political candidates. --Enos733 (talk) 23:01, 7 March 2022 (UTC)[reply]
Enos, in response to your comment: As a community, we decided that individuals serving in government with law-making powers have both real-world importance and are likely to have biographical information in reliable sources. Two things, first of all, WP:Notability says Determining notability does not necessarily depend on things such as fame, importance, or popularity [my emphasis on importance]. Secondly, I am directly challenging the notion that by virtue of holding legislative power that these lower officials are likely to have biographical information in reliable sources. -Indy beetle (talk) 23:10, 7 March 2022 (UTC)[reply]
I read "importance" in this sentence as meaning "high rank or status," similar to "fame" or "popularity," rather than being consequential or significant. But again, the purpose of an SNG is to help clarify that real-world notability, to help new editors think about who is eligible for an article, and minimize debate at AFD. I do think that nearly all people who hold federal or state/province-wide elected positions do have biographical information found in reliable sources and the current version of NPOL is quite clear (except for political candidates). Enos733 (talk) 23:31, 7 March 2022 (UTC)[reply]
This is simply not the case. I've held off on writing some articles on provincial governors in the Congo for lack of better info. Many members of their national parliament from the 1960s don't even have basic biographical info (and I once consulted book which was solely devoted to discussing that parliament from that time period). What about Preston Brooks Callison, member of the South Carolina House of Reps and father of Tolliver Cleveland Callison Sr.? What about all of those listed here and here, for example? I sincerely doubt one could find enough info in RS to write basic articles on the hundreds of past assembly members stretching back to the late 1700s. -Indy beetle (talk) 23:49, 7 March 2022 (UTC)[reply]
I am not suggesting that it is always easy to create a biography on each elected official, especially in a pre-internet era. But, it is often doable. For Preston Brooks Callison, we can verify that he did serve two terms in the South Carolina House of Representatives, representing Greenwood County. (see https://www.findagrave.com/memorial/113638548/preston-brooks-callison). With these bits of information we can narrow our search to find information and search the archives. We should be able to find articles about Callison's campaign, the bills he sponsored, the committees he served on, and probably some information about his life before or after the legislature. Enos733 (talk) 00:06, 8 March 2022 (UTC)[reply]
  • NPOL does need refinement, as while modern holders of relevant office receive coverage that results in them being notable, the longer ago the politician held office the less likely that is to be true. BilledMammal (talk) 09:58, 9 March 2022 (UTC)[reply]
    I strongly disagree with this statement. The only difference is that written material is harder to find. I fundamentally believe that the SNGs are supposed to provide guidance for editors about which subjects are "significant, interesting, or unusual enough to deserve attention or to be recorded." Clear criteria does two things. First, clear criteria helps with this global project - so editors do not have to spend energy discussing the relative importance or significance of like objects. Second, clear criteria minimize the energy spent debating sources at AFD.
    I point again to the amount of editor time was spent debating whether the sources about Jamie Fitzgerald rose to the level of significant coverage. Yes, Jamie is a relatively marginal professional athlete yet there are multiple written articles of his life and career. After sources were found, we spent two weeks and 69,634 bytes debating whether the sources were sufficient. The point is was that discussion helpful to the community? Yes, editors were able to find sources that were not included before the AFD (which improved the project), but we collectively spent lots of time trying to figure out whether those sources were significant enough, not that information in the article was wrong.
    I am not someone who thinks that stub articles are problematic. If the information is verifiable of someone in a category that the community thinks is "significant, interesting, or unusual enough to deserve attention," I only see positives for the project (especially with Google prioritizing results from Wikipedia). Enos733 (talk) 17:35, 9 March 2022 (UTC)[reply]
    Written material is not just harder to find, it is also less likely to exist. BilledMammal (talk) 03:10, 16 March 2022 (UTC)[reply]
    You'd be surprised to find how much has been written about otherwise seemingly-obscure state politicians from the 1800s. Take a look at my man Elisha Carpenter (found at random). That is far from a stub article. –MJLTalk 04:06, 21 March 2022 (UTC)[reply]
I agree the points raised about NSPORT in the recent RFCs (and the many before it) apply equally to NPOL and all the other SNGs. Mainly: you need to meet GNG to be able to write a policy-compliant article; SNGs should be accurate predictors of GNG; many (most?) current SNGs are not accurate predictors of GNG (including NPOL), and should thus be revised to be accurate predictors of GNG. Levivich 17:35, 9 March 2022 (UTC)[reply]
I think that there are going to be some articles that might have one super-duper in-depth source, and a bunch of sources that don't on their on quite meet sigcov, and that there still could be a policy-compliant article. Named natural features come to mind. — Mhawk10 (talk) 03:02, 16 March 2022 (UTC)[reply]

In general, are animal and in vitro studies acceptable sources to support toxicology statements?

WP:MEDASSESS and WP:MEDINVITRO generally discourage the use of animal and in vitro studies to support statements regarding human health effects. This is because these studies do not translate consistently into clinical effects in human beings. However, in toxicology assessment, in vitro methods are preferred as screens over lab animal testing, and certainly over the typical process of human clinical research. Obviously, potentially poisoning humans to determine toxicity of a substance is frowned upon, so it may be hard to find studies that meet our high standards of medical evidence.

Generally speaking, should statements of toxicity status be subject to the same WP:MEDRS standards as all other medical statements, or should an exception be made to allow for in vitro and animal studies?

Secondly, should statements that a substance is toxic be subject to lower standards of evidence than statements that a substance is not toxic?

If the answer is "yes" to any of these questions, I propose we draft a revision to MEDRS to codify this exception. MarshallKe (talk) 16:26, 8 March 2022 (UTC)[reply]

@MarshallKe, this is kind of a technical subject, and you might have better luck with this discussion at Wikipedia talk:WikiProject Medicine or Wikipedia talk:Identifying reliable sources (medicine). WhatamIdoing (talk) 17:06, 8 March 2022 (UTC)[reply]
Probably belongs at WT:MED (or even better, WT:TOX). Pretty much everything is "toxic" at some dose, even water. Alexbrn (talk) 17:50, 8 March 2022 (UTC)[reply]
Without comment on appropriate venue, any substance approved for use in humans is first subject to in vitro and animal toxicology studies. It stands to reason that these are therefore suitable for mention on Wikipedia, so long as they're presented in context. MastCell Talk 18:19, 8 March 2022 (UTC)[reply]
I think that's a reasonable line to draw. Rather than wikivoicing "this substance is toxic in humans", mention if something didn't pass Phase 1 trials or otherwise has a recommendation against human use/consumption from a major public health body. In both of those latter cases, we'd still be using the WP:MEDRS standards: it should be clear to the reader that the data are pre-clinical, and the article text should avoid stating or implying that reported findings hold true in humans. Bakkster Man (talk) 13:40, 21 March 2022 (UTC)[reply]
I have notified the recommended pages. MarshallKe (talk) 18:48, 8 March 2022 (UTC)[reply]

Official names and primary sources

I think I am detecting a shift of practice towards favouring official names regardless of common names.

The most recent instance is Talk:Amanat (political party)#Requested move 1 March 2022. It seems that neither nom, three experienced editors, nor the closer saw any problem with moving the article on the rationale Official party name change. There was no other discussion.

This is not necessarily a bad thing. The redirect remains.

And I think this trend is also reflected in the use of primary sources (which of course tend to use the official name) as evidence supporting an article name change. Previously these were ignored, but not so much recently.

Other views? Andrewa (talk) 04:13, 9 March 2022 (UTC)[reply]

Looking at recent news results, I see a strong indication that it is now the WP:COMMONNAME. There should have been a discussion on that basis, but I believe the lack of objections is due to that, rather than any emerging preference for the official name. BilledMammal (talk) 04:16, 9 March 2022 (UTC)[reply]
WP:NAMECHANGES is the relevant policy. I also assume COMMONNAME was met, as it was not raised as an objection.—Bagumba (talk) 04:48, 9 March 2022 (UTC)[reply]
Yes, but neither of these was raised. And NAMECHANGES just says we prefer recent sources, not that we disregard them.
The question of the common name was not even raised. Andrewa (talk) 05:03, 9 March 2022 (UTC)[reply]
Not raised could very well mean "not an issue", not that it doesn't matter or should be removed from the policy.—Bagumba (talk) 09:04, 9 March 2022 (UTC)[reply]

See also #On name changes and article names. above. Same issue, different perspective. Andrewa (talk) 05:03, 9 March 2022 (UTC)[reply]

Apparently WP:COMMONNAME was not an issue. Regardless, the more common name, evidenced by reliable sources, would be hard to overturn as it has been hashed over many times all over Wikipedia. The result has been to use the more common name, but there are exceptions. -- Otr500 (talk) 06:55, 21 March 2022 (UTC)[reply]

Discussion about images of recently deceased

I started an RfC discussion (well, not yet RFC-tagged) about using images of recently deceased persons. Link: Wikipedia talk:Non-free content#RfC: Using biographical images of persons immediately after death. --George Ho (talk) 05:36, 9 March 2022 (UTC)[reply]

Now it's RFC-tagged. --George Ho (talk) 08:53, 10 March 2022 (UTC)[reply]

Wikipedia usernames and article content

When both the username and real name of a Wikipedia editor are widely reported by reliable sources, to what extent should Wikipedia blanketly prohibit articles in the mainspace from stating that such a person edits under that account name (except when that person has voluntarily posted their own real name, or links to information containing their real name, on Wikipedia)? — Mhawk10 (talk) 21:10, 15 March 2022 (UTC) (updated: 02:26, 16 March 2022 (UTC))[reply]

Discussion: Wikipedia usernames and article content

  • There have been a few cases of this that I've encountered on-wiki recently, and I'm really not sure how to handle this. WP:OUTING seems to be a behavioral policy that considers outing someone to be harassment. But this seems to be a behavioral policy rather than a content policy, and it seems to juxtapose with the principle that Wikipedia is Not Censored when these sorts of things might be relevant in a Wikipedia article (for example, when a person's principle notability comes from their Wikipedia activity/reactions thereto). While there's always WP:IAR, policy could be more explicit in terms of how suppression should be handled in these cases and what the expectations are for editors who are writing articles that involve these edge cases. — Mhawk10 (talk) 21:13, 15 March 2022 (UTC)[reply]
  • Comment Per WP:OSPOL the problem goes beyond mentioning real name + username, since that policy indicates that any links to WP:RS that does the WP:OUTING must be redacted from any WP-space. Talk:Ketanji Brown Jackson has a recent example. Gråbergs Gråa Sång (talk) 21:40, 15 March 2022 (UTC)[reply]
    I do think that prohibiting links to reliable sources that also happen to connect an editor to a username (such as in the KBJ article), restricts article content in a way that's not exactly consistent with Wikipedia not being censored. If the vast majority of articles that cover the event also contain the username of the editor, then this might result in us being unable to cite particular reliable sources for facts that don't involve the editor's name. That being said, I can think of a few editors where there is intense public speculation about their private identity that has been discussed in mainstream media (even naming alleged names) without those sources saying anything conclusive about the identity. In general, I think that speculation like this is less likely to be of encyclopedic value, and so the privacy considerations of the editor are relatively much stronger. Editors are living people, too. — Mhawk10 (talk) 03:13, 16 March 2022 (UTC)[reply]
  • This seems kinda pointless since we cannot prevent RS from reporting things and likewise, can't prevent RS from being used on Wikipedia. This is kind of like when someone doesn't want negative information in an article about them but it's widely reported by RS. Similarly, our COI policy/guideline would prevent this since in theory the editor would have to disclose anyway. CUPIDICAE💕 22:44, 15 March 2022 (UTC)[reply]
    The assumption that our COI policy/guideline would prevent this since in theory the editor would have to disclose anyway implies that the only reason that someone would get widespread media coverage for editing Wikipedia was for COI. I don't think that this is universally true. — Mhawk10 (talk) 22:49, 15 March 2022 (UTC)[reply]
    It most definitely is not true that COI is the only reason someone gets widespread media coverage for editing Wikipedia. Pierre-sur-Haute military radio station#Controversy over Wikipedia article and Wikipedia Seigenthaler biography incident are just the first two examples that come to mind. Thryduulf (talk) 17:20, 16 March 2022 (UTC)[reply]
  • It shouldn't be mentioned just for the sake of it. However, if it has been reported by reliable sources and is relevant and germane to the article, it should be used in it. The anti-outing policy is a conduct policy, not a content policy. It is absolutely not intended to forbid the use of relevant and verifiable information in an article, especially when, by virtue of having been reported in reliable references, the information is no longer private anyway. Seraphimblade Talk to me 23:13, 15 March 2022 (UTC)[reply]
    That is not how the OS team currently implements the policy. If a reliable source outs a Wikipedian, links to that source are oversighted in all namespaces, including main and talk. Best, Barkeep49 (talk) 00:40, 16 March 2022 (UTC)[reply]
    Since this RfC is probably prompted by Mark Bernstein (Wikimedian): @Barkeep49: I presume the OS team exercises some discretion (given that said article hasn't been OS'd yet)? ProcrastinatingReader (talk) 01:42, 16 March 2022 (UTC)[reply]
    I can't reveal what discussions (if any) there have been about Bernstein. My comment was about consensus across multiple discussions, which felt appropriate for an RfC that is at the Village Pump and whose outcome would not impact only a single article. Best, Barkeep49 (talk) 01:55, 16 March 2022 (UTC)[reply]
    @Barkeep49, I wonder if I can have your input on the "allowed-ness" on this: I cite a source like the Ketanji Brown Jackson Politico article or the Mark Bernstein Haaretz somewhere on-WP, not for username, but reasonable WP:DUE/WP:PROPORTION stuff, and I don't include a url in the cite. Gråbergs Gråa Sång (talk) 09:04, 16 March 2022 (UTC)[reply]
    That's an edge case I don't feel comfortable speaking about. I really don't know how that would go down with the OS team. Best, Barkeep49 (talk) 14:35, 16 March 2022 (UTC)[reply]
    Barkeep49, are there any considerations besides WP:OUTING that guide current OS practice? ToS, UCoC, etc? I guess I'm wondering if it's something that can be changed by changing the outing policy or if a different approach is needed. –dlthewave 18:29, 16 March 2022 (UTC)[reply]
    @Dlthewave I want to ping @Thryduulf who has been doing an excellent job of describing current practice in this discussion, but from the discussions I can think of, decisions have been made based on OUTING and based on the OS teams' understanding of community preference in applying it. ToS and UCoC are both minimum expectations and our OS policy goes beyond even the global minimum for OS. Best, Barkeep49 (talk) 18:49, 16 March 2022 (UTC)[reply]
    I'm pretty certain that the UCoC has never coming up in discussions about specific outing concern incidents - obviously that may change in the future if/when it comes into force, but based on my current understanding I don't think it will have a significant impact. I know ToS has come up in discussions on the Oversight list, but I don't recall any this context (my recollection is that its most often mentioned in the context of self-disclosure by (apparent) minors). As Barkeep notes the main considerations are the OUTING and oversight policies and our collective and individual understands of how the community wants us to deal with these things. Those understandings are built in part on discussions like this one but also other on-and-off wiki discussions, feedback and comments about editors' and readers' priorities and desires for what Wikipedia should be like. That it should be a safe space where people don't need to fear being outed is frequently a strongly expressed preference, which is one of the reasons we generally treat it very strongly. Obviously we also take the individual circumstances into account, including the nature of the publication and article. Thryduulf (talk) 22:29, 16 March 2022 (UTC)[reply]
  • It's hard to know what should happen in a hypothetical case since there are always other factors. What prompted this discussion was the arrest of a Wikipedia editor. The article should never have been created, since it lacks notability. If we had followed policy in the first place, the issue would never have arisen. TFD (talk) 02:18, 16 March 2022 (UTC)[reply]
  • Hi all! I've received an email from an arbitrator who has expressed substantial concerns about the RfC. Seeing as nobody has !voted yet and it's been entirely a discussion, I've withdrawn the RfC tag and deleted the survey section. I think that this is OK per WP:TPO (I don't think this distorts anybody's comments), but if anybody who commented objects to the change in the format of the discussion then I have no objection to them reverting my edit that removed the RfC tag and survey section. — Mhawk10 (talk) 02:26, 16 March 2022 (UTC)[reply]
    That arb was not me, but I'm glad the RfC tags were removed. Best, Barkeep49 (talk) 02:44, 16 March 2022 (UTC)[reply]
    I can confirm that Barkeep was not the arb. — Mhawk10 (talk) 02:49, 16 March 2022 (UTC)[reply]
    I think it is a discussion that we need to have, as WP:NOTCENSORED and WP:OUTING currently contradict each other. I don't see a WP:TPO issue though I disagree with the withdrawal and I am concerned by the fact that the discussion that prompted the withdrawal of a formal discussion took place off-wiki. BilledMammal (talk) 03:31, 16 March 2022 (UTC)[reply]
    To be clear, the extent of "discussion that prompted the withdrawal of a formal discussion" was a single email from an arb that I did not reply to until after I withdrew the RfC. I'm also not claiming that there's a consensus here already on whether or not an RfC is appropriate. — Mhawk10 (talk) 03:47, 16 March 2022 (UTC)[reply]
    Mhawk10, would you be willing to share the nature of the concerns to the extent that you feel comfortable? This could be helpful for other editors who might want to move forward with a formal proposal. –dlthewave 18:24, 16 March 2022 (UTC)[reply]
  • Barkeep49 and Mhawk10, I echo the concerns about the RfC being suspended or aborted (which one is it, even?) due to an off-wiki conversation. This discussion is about what the policy should be; all of us can go read what it currently is. I am not sure how that discussion is to be had without soliciting community feedback, and that is what an RfC is for. Seraphimblade Talk to me 04:09, 16 March 2022 (UTC)[reply]
    I'm not sure why you're pinging me as I was very much discussing this publicly and was not aware an email had been sent until Mhawk posted it here. Best, Barkeep49 (talk) 04:17, 16 March 2022 (UTC)[reply]
    This is currently a WP:CENT-posted discussion posted at the Village pump; I think that community feedback can be obtained in a somewhat unstructured manner before we come to a particular proposal (or set of proposals) to !vote on. — Mhawk10 (talk) 05:01, 16 March 2022 (UTC)[reply]
    I'm not sure what further input is needed, in a pre-RfC sense. It's a pretty straight up-or-down "Yes, a link between a username and identity is permitted in articles if verified by reliable sources" or "No, a link between a username and identity is not permitted in articles." Is there something besides those options that particularly requires more input? (I'm also not certain how my comment wasn't a clear "Yes, it should be"—granted, I didn't bold anything, but I don't generally find that to be particularly necessary when it's clear what I'm advocating.) Seraphimblade Talk to me 05:30, 16 March 2022 (UTC)[reply]
    If you feel like a straight up-down thing is worth RfCing, then I can't stop you from (re-)launching an RfC. I think that there might be a grey area where privacy is a real concern (I indicated one such case in my response to GGS above). It might be better to break it out case-by-case on a few proposals. For example, one idea could be:

    When both the username and real name of a Wikipedia editor are reported by reliable sources, to what extent should Wikipedia prohibit articles in the mainspace from stating that such a person edits under that account name?

    • Option 1: In all cases except when that person has voluntarily posted their own real name, or links to information containing their real name, on Wikipedia ("voluntarily revealed their identity on-wiki").
    • Option 2: In all cases except when the person has voluntarily revealed their identity on-wiki or when multiple high-quality independent reliable sources reports that fact.
    • Option 3: In all cases except when the person has voluntarily revealed their identity on-wiki or when multiple independent reliable sources report that fact.
    • Option 4: In all cases except when the person has voluntarily revealed their identity on-wiki or when at least one independent reliable sources report that fact.
    • Option 5: Other
    I'm not locked into this sort of thing (I'd like to see some deliberation on edge cases and phrasing) but this sort of thing might be better than a simple up-down RfC, such as the one I initially posted, since it allows for nuance and taking into account reasonable privacy concerns. — Mhawk10 (talk) 05:56, 16 March 2022 (UTC)[reply]
    The alternative approach would be to do what I (abortively) did, which is to get a yes or no on "do any cases exist outside of voluntary self-ID" and go from there. I think we can probably skip that with a properly formatted RfC. Alternatively, it might be worth waiting for oversighters/arbcom to chime in to point out edge cases before an RfC is launched, since they are likely to have some additional experience in that area that could be useful in terms of thinking about things beyond simply the presence of sourcing. Something like the age of a person (which is a bit hard to directly fit into the structure I proposed above) or other factors might be at play. We'd also need to explicitly state something about the use of links that contain WP:OUTING material, as Barkeep49's response to your initial post indicates that current OS practice is to oversight those in the general case as well. — Mhawk10 (talk) 06:10, 16 March 2022 (UTC)[reply]
    Slightly problematically for OSers trying to engage in the discussion, at best, they'll be able to note edge cases where they've decided to leave the material on-wiki - they can't tell us any borderline cases that they just decided to remove, because that would itself be a breach. Nosebagbear (talk) 09:07, 16 March 2022 (UTC)[reply]
    There have been multiple occasions where we have removed a connection between a username and a real life identity made by independent sources but not by the user in question. The reliability or otherwise of the source is not generally relevant and the namespace where the mention is made is never relevant. When the subject has clearly made the connection themselves we do not oversight as it's purely a content decision whether to include the name or not, we have had some such links reported to us though and I have a hazy recollection that one link was removed and then restored when it became clear that the subject had made the connection themselves (oversight is a tool of first resort so redacting and then unredacting after discussion is normal).
    In general terms, the WP:OUTING policy trumps the WP:NOTCENSORED policy because outing someone against their will is not acceptable under pretty much every circumstance, but NOTCENSORED is a never a reason for inclusion of content (it is a reason not to exclude it). There are of course edge cases, and one fairly recent one does come to mind, but I can't think how to phrase it in a way that doesn't give too much information. Thryduulf (talk) 13:05, 16 March 2022 (UTC)[reply]
  • I'd imagine that in addition to Bernstein, this question would also apply to pages such as Ira Brad Matetsky. 2601:18C:8B82:9E0:0:0:0:AFF6 (talk) 11:46, 16 March 2022 (UTC)[reply]
    @Newyorkbrad has disclosed his real name publicly (he clearly links to his biography on from his userpage for example) so there is no issue with mentioning his username in his biography. The question only arises when the subject has not made the link themselves. Thryduulf (talk) 13:07, 16 March 2022 (UTC)[reply]
    That is correct in my specific case. I had originally intended to edit anonymously, but after I became an arbitrator, Daniel Brandt and possibly some moderators at the old Wikipedia Review had other plans. That was 14 years ago, and I've made no effort to conceal my identity since that time. Newyorkbrad (talk) 21:23, 16 March 2022 (UTC)[reply]
  • Privacy also involves degree of public prominence of the information. Changing the situation from somebody screwing up and outing themselves in some obscure RS to publishing it in Wikipedia is a major change, even if the info was technically already "public". The only thing that keeps Wikipedia from being one of the most privacy-violating websites in the world for editors in anonymity. Aside from that it is a published, easily public-searchable record / database of everything the person ever wrote or did on Wikipedia and exactly when they did it. Privacy can be a matter or life and death, persecution, loss of freedom or careers etc. and should trump all other considerations. Option 1,, the most restrictive is best. North8000 (talk) 13:33, 16 March 2022 (UTC)[reply]
  • I am not of the view that there needs to be an elaborate policy statement about a matter such as this which comes up a few times a year. Stifle (talk) 14:24, 16 March 2022 (UTC)[reply]
    When someone willingly links themselves to their username off-wiki in a highly visible reliable source elsewhere, I'd argue that stating their real name in an article in that case would be reasonable if they are notable. Of course that's an edge case - it would be rather unlikely for someone to so visibly out themselves elsewhere and still be anonymous onwiki. I don't think we should treat the content of articles on Wikipedians differently than any other formerly anonymous person. As a result I think somewhere around option 2 is best. ThePlatypusofDoom (talk) 14:32, 16 March 2022 (UTC)[reply]
    We are far more likely to be dealing with a situation where someone is being outed by an RS for some kind of accused misconduct in their editing than for someone to have revealed themselves and that's then linked back onwiki. Best, Barkeep49 (talk) 14:55, 16 March 2022 (UTC)[reply]
  • Readers > editors; content > conduct; NOT, V and NPOV > OUTING. Editors should be permitted to talk about anything in RS as long as that discussion is about summarizing the RS for a Wikipedia article. We can't and shouldn't "filter" the RS just because the RS is talking about one of us. If you're notable and named by RS, but you don't want that info to end up in a Wikipedia article, well that's just too bad, regardless of whether you're a Wikipedia editor or not. Wikipedia shouldn't treat its editors differently or better than any other BLP subject. Editors have the same BLP protections as any other BLP subject (e.g. the rules about low profile/high profile, BLPREQDEL, etc.); they're not entitled to greater protections by virtue of being editors. This RFC ought to run. And I may someday regret this !vote :-) Levivich 16:02, 16 March 2022 (UTC)[reply]
    My opinion falls closer to yours Levivich than the current practice among the Oversight team. But I want to note that a majority of the people I'm aware of who are named in an RS which have been oversighted are not notable people. I also want to emphasize just how important I find RS to be in this equation. There have been some unreliable media sources which have outed English Wikipedia editors and caused them severe real world harm, including being taken into police custody, and ultimately forced them away from Wikipedia. Best, Barkeep49 (talk) 16:32, 16 March 2022 (UTC)[reply]
    I do wonder how much harm re-publishing on Wikipedia causes over and above the harm caused by the original outing. If something is already findable on Google, does it matter if it's on Wikipedia or not? If the police have already arrested me, it seems too late to matter whether that's on Wikipedia or not; the cat is well out of the bag.
    I could envision a system where OS can "shut down" a conversation on the grounds that there are not enough quality RS to justify it, i.e. making some kind of "widely reported" vs. "not widely reported" determination. This could prevent Wikipedia from Streissanding something obscure, while also not putting us in the position of ignoring something everyone already knows. The only question is, how do editors appeal OS's decision, and how does OS give enough information (and to whom) for accountability without defeating the purpose of keeping private things private? Maybe, if OS were to invoke this "power" and shut down a conversation, they could send their rationale to Arbcom (privately via email), and arbs can act as a check and balance? Just spitballing here. Levivich 17:10, 16 March 2022 (UTC)[reply]
    @Levivich The way to appeal an oversight action is, per Wikipedia:Oversight#Complaints, to contact the Arbitration Committee. For most things that are potentially controversial, including every oversight block, the oversighter who performed the action will email the oversight mailing list for peer review anyway. All arbs who are oversighters have full access to that list.
    Something appearing in a Wikipedia article can be extremely amplifying, especially as most journalists read Wikipedia, and there has been at least one case of an arrest occurring only after information was included here. The potential for real world harm is not theoretical, especially when even mere allegations of wrong doing can seriously impact a person's life. e.g. in the UK allegations of rape or paedophilia can end a career, in other parts of the word allegations of things like homosexuality or supporting the wrong political figure can be even more impactful.
    How much information can be shared varies on a case-by-case basis, and we do endeavour to share as much as we can but in some cases that is not much but there isn't anything we can really do about that without defeating the point of oversighting something in the first place. Thryduulf (talk) 17:36, 16 March 2022 (UTC)[reply]
    Surely it would not be appropriate to include editor names on the basis that there is a self-published source that says who the editor is, if there is a low-quality tabloid article that allegedly identifies an editor, or if a random politician accuses somebody they don't like of being an editor on the basis of circumstantial evidence. I don't think that anybody here would argue that editors deserve less protection that other BLPs for sourcing contentious claims. The question to me is whether or not they deserve more protection than an ordinary BLP and, if so, to what extent. — Mhawk10 (talk) 17:17, 16 March 2022 (UTC)[reply]
    We would obviously not connect a person to their username on any other site if they had not disclosed the connection themselves, doubly so if they were not a notable person. There is no reason why Wikipedia usernames should be any different. Thryduulf (talk) 17:38, 16 March 2022 (UTC)[reply]
    With respect to if they had not disclosed the connection themselves, that isn't exactly what current policy is. The current outing policy requires disclosure on Wikipedia. Citing the Wall Street Journal for a non-editor admitting to running a particular twitter account appears to be treated differently than citing The Wall Street Journal for an editor admitting to editing Wikipedia from a particular account but not disclosing it on-wiki. — Mhawk10 (talk) 18:39, 16 March 2022 (UTC)[reply]
  • I think the current state of affairs is satisfactory and need not change. Verifiability does not guarantee inclusion (WP:ONUS); inclusion is subject to consensus, may it be explicit (talk page discussion) or implicit (editing). On top of this, the OS team can remove content when WP:OSPOL is met. Do we really need more? JBchrch talk 17:42, 16 March 2022 (UTC)[reply]
    I don't think anybody here objects to oversighting people's phone numbers, social security numbers, etc. when they pop up in articles, since they're almost never WP:DUE and almost always raise WP:BLP concerns. The second bullet under WP:OSPOL specifies that [i]dentities of pseudonymous or anonymous individuals who have not made their identity public should be oversighted, but there's a bit of a difference with WP:OUTING (which has the additional requirement that the identity to be made public on Wikipedia). The other snag is when we link to a reliable source that happens to contain the identity of a pseudonymous or anonymous person and use that source to support a statement in the text of a Wikipedia article that itself does not reveal the identity. There have been a few cases of this sort of stuff being oversighted that I can think of that aren't explicitly mandated by the text of WP:OSPOL but WP:OUTING would suggest to oversight. — Mhawk10 (talk) 18:16, 16 March 2022 (UTC)[reply]
    Ok, gotcha. In that case, is it fair to say that the issue can be narrowed down to whether OSPOL 1(b) should not apply to the identities of pseudonymous or anonymous individuals that have been reported by reliable sources (or whichever alternative criteria)? Not that I have a ready-to-wear opinion about this, just thinking about how we can frame the discussion. JBchrch talk 19:03, 16 March 2022 (UTC)[reply]
    Something along those lines would make the most sense to me. The same sort of exception would also need to be placed in WP:OUTING#Exceptions to make it consistent with WP:OSPOL w.r.t. any changes that get made. — Mhawk10 (talk) 19:48, 16 March 2022 (UTC)[reply]
  • I agree with Levivitch's comment, and I think that Wikipedia:Biographies of living persons#Presumption in favor of privacy takes a more appropriate approach for article content than the hard line of WP:OUTING. We're not causing undue harm by publishing information that has already been prominently publicized. This reminds me of mass shootings where the known perpetrator's name is all over the headlines but we can't even mention that an arrest has been made because <whisper>the accused shooter</whisper> would appear in the citation. –dlthewave 18:21, 16 March 2022 (UTC)[reply]
  • I don't always agree with Levivich (nor does he always agree with me, and he's let me know that more than once), but I do here. If something has been reported in a reliable source, that information is no longer private. At that point, attempting to "preserve the privacy" of the information is absurd; it is like trying to save the lives of people who are already dead. Seraphimblade Talk to me 08:32, 18 March 2022 (UTC)[reply]
  • Here is my reluctance: from my perspective, there has been an erosion, over the past some years, of the idea that we are both an encyclopedia and a community, and that both are worth protecting. Or perhaps it's simply an increasing number of users who seem to be hostile to the notion that we are a community, and that sometimes that means prioritizing a person over a specific change to an article. Perhaps it's in my head, but it seems like there are more Wikipedians than ever who are both pseudonymous themselves and spend most of their time trying to "get" other Wikipedians. Sometimes it's indeed helpful, but it doesn't make for a great atmosphere. (I'm not talking about anyone in particular, but if you think I'm talking about you, hopefully it leads to some reflection about why that may be.) In general, having done this for a long time we're pretty good at balancing the needs of both community and encyclopedia, but there's still a ton of gray area, and this RfC is about one of them. On the surface, I don't think I would disagree with the wording: that if it's widely reported on by reliable sources [such that it would get over a high bar set at WP:NPF and WP:DUE], then it may be ok to mention... but the actual language of the support it's received here gives me pause, because I don't get the sense that people are supporting "we'll be extremely careful and err on the side of excluding," regardless of the wording. So there's my reluctance, anyway. — Rhododendrites talk \\ 15:57, 18 March 2022 (UTC)[reply]
    Would reluctance be resolved if the guidelines were to include language that in the case where it is unclear whether or not the link between the user and their real name has been widely reported by reliable sources, the username should be excluded from the article? — Mhawk10 (talk) 04:09, 21 March 2022 (UTC)[reply]
    I can easily see that being wikilawyered to death. You'd have to also amend things like WP:NOT3RR for it to be of any effectiveness. –MJLTalk 15:38, 21 March 2022 (UTC)[reply]
  • I'd be inclined to back the B position - that is, there must be a great deal of reliable sourcing making the link, before we would move past OUTING. This is mainly in line with the "degree of privacy loss" aspect. A name being mentioned on a barely seen RS somewhere is not akin to headline notice in a wikipedia article. But if multiple good sources are covering the relation, then the loss is not really noticeable. I would include a "provisionally remove should the editor dispute the link", pending TP discussion. Yes, this comes with obvious flaws, but I think a net gain. In some ways I'd prefer a case by case process to handle rare exceptions, but given that the misteps come with risk of significant conduct violations, I'd want to know who editors should go to for a go/no-go ruling. Nosebagbear (talk) 10:17, 21 March 2022 (UTC)[reply]
    Yes, I think it is vital here that we stress that the default is always to not include or remove anything that might be outing or otherwise disclosing non-public information unless and until it is clear that the inclusion is supported by (ideally multiple) prominent reliable sources, DUE, and would not otherwise cause (additional) harm to whoever's information is being discussed. Thryduulf (talk) 13:01, 21 March 2022 (UTC)[reply]
  • Leaving aside the privacy questions, isn't this just trivia? Jimmy Wales is probably the most famous Wikipedian, and yet you will not find his username in the article about him. Adrianne Wadewitz, no username. Amin Azzam, no username. Yaroslav Blanter, no username. Dariusz Jemielniak, no username. There are a few (Ira Brad Matetsky, James Heilman), but most of them don't include a username. I'm not sure that any of them actually should. What benefit does that provide to the (non-editing) reader? It's inside baseball at best, and maybe navel-gazing. WhatamIdoing (talk) 21:19, 21 March 2022 (UTC)[reply]
    Given that it is appreciably covered in the articles in cases such as the exemplar case that led to this discussion, I feel like were they not Wikipedians, we'd generally cover it as a point that had had significant coverage - basically, were they, say, famous reditters, without our own OUTING policy in the way, we'd cover it. Nosebagbear (talk) 15:59, 22 March 2022 (UTC)[reply]
    @Nosebagbear: Counterpoint to that: See the section for Ken Bone (Illinois) on the 2016 US Presidential elections. We mention that Bone has a Reddit account, but we don't actually name it. –MJLTalk 03:44, 24 March 2022 (UTC)[reply]
    An interesting counterpoint, though not quite oranges to oranges, perhaps nectarines to oranges, in that that's a few line section vs the articles in the examples given. Where someone's wikipedia (or whatever) account is responsible for a large portion of their notability and it is well sourced by multiple reliable sources, I'd give it.
    Out of interest @MJL: do you think we should add, say, Jimbo's? Nosebagbear (talk) 09:07, 24 March 2022 (UTC)[reply]
  • This is not the sort of thing that policy can decide. It needs to be dealt with on a case-by-case basis, depending entirely on the article in question. Lets even ignore the WP:OUTING issues, where a person does not publicly acknowledge their own Wikipedia account. If and when to mention some reliably-sourced information is not clear cut, and covered only very broadly by policies such as WP:IINFO and WP:UNDUE and the like. Being true and reliably-sourced are necessary but not sufficient conditions for including some fact. In many cases, the actual Wikipedia user name, even if reliable sources have reported it, may be so trivial as to not bear mentioning in an article about that person. Not every reliably-sourcable fact about a person's life must be included in an article, discretion needs to be taken as to which information is relevant or not, and what works in one article may not be useful in another. --Jayron32 18:22, 22 March 2022 (UTC)[reply]

Notability of lists

Ever since the Wikipedia:Articles for deletion/Mass killings under communist regimes (4th nomination) clusterfuck, I've been trying to figure out exactly when notability guidelines apply to list articles. According to Wikipedia:Stand-alone lists, it seems the answer is "always"? To be clear, I am referring to the need to prove notability of the general concept of the list, as its own topic, in reliable sources in order to create/keep a list article, and that mere notability of the items in the list does not justify the creation of a listicle. Am I correct in my analysis? Is there *any* situation where we can publish lists without establishing notability of the general theme of the list? MarshallKe (talk) 00:50, 17 March 2022 (UTC)[reply]

The relevant notability guideline is WP:LISTN.—Bagumba (talk) 01:49, 17 March 2022 (UTC)[reply]
The notability of a list is based upon whether there exists significant coverage of the topic, as a whole. Per WP:NLIST, the entirety of the list does not need to be documented in sources for notability, only that the grouping or set in general has been. There’s also WP:IAR; some lists may be split between multiple pages based on an arbitrary index (such as year) for the purpose of not having an absolutely giant page that negatively impacts usability, even when the specific year cutoffs aren’t something discussed directly in sources. — Mhawk10 (talk) 07:38, 17 March 2022 (UTC)[reply]
Good callout on Ignore All Rules, I think, because I've seen some lists that probably don't meet notability requirements but still they are good articles that improve the encyclopedia, and I'm not going to waste time nominating them for deletion. This situation is a good application for inclusionism (I am both an inclusionist and a deletionist depending on circumstance). Though, I would never attempt to use Ignore All Rules unironically in an edit debate, because if it comes to that, you don't really have a leg to stand on and it's essentially just polling at that point. MarshallKe (talk) 13:06, 17 March 2022 (UTC)[reply]
As others have said, there's definitely an IAR aspect here, but I generally see lists either notable as the list as a whole is notable (such as the list of periodic table elements, us presidents, etc), that the list extends from a topic that is clearly notable as to give documented examples of that topic, list as list of those that broke the 4-minute mile or list of biz office bombs. Or in the final case, the list is a "natural" grouping of how atopic is usually discussed and dissected in RSes even if the list itself is not specifically called out, such as our many lists of characters in fictional series, or lists of countries sorted by population or GNP or inflation, etc. Anything else starts getting into synthesis of topic which is OR and likely a notability problem, which the OP list feels on the edge of being. Particularly since it requires each entry to be clearly sourced to demonstrate inclusion. --Masem (t) 13:36, 17 March 2022 (UTC)[reply]

Request for comment on administrator activity levels

Please see the following RfC, suggesting that we increase the minimum activity requirements for administrators to an average of 20 edits per year, over a 5 year period.

Wikipedia:Village pump (policy)/Request for comment on administrator activity requirements

WormTT(talk) 19:08, 17 March 2022 (UTC)[reply]

Primary source vs non-primary source

Primary source after event happened (official artist website or social media - after so it's confirmation event actually happened) or non-primary source before event happened (The Guardian or other reliable source - before so there is no confirmation it actually happened)? Or we assume if there is no next article about event cancelation it actually happened? Eurohunter (talk) 18:13, 21 March 2022 (UTC)[reply]

Not something policy can determine, absent of specifics, though as a matter of principle Wikipedia shouldn't generally be assuming things happen just because someone said they were going to. So unless you are proposing a specific change of policy, I'd suggest you take any queries regarding actual disputed content to WP:RSN, providing the necessary details. AndyTheGrump (talk) 18:19, 21 March 2022 (UTC)[reply]
@AndyTheGrump: I will ask at RfC or is there any better place to ask? Eurohunter (talk) 19:24, 21 March 2022 (UTC)[reply]
I could be wrong, but I'm guessing that you meant "independent vs non-independent" here. Most of the newspaper is filled with independent primary sources. See also Wikipedia:Secondary does not mean independent. WhatamIdoing (talk) 21:22, 21 March 2022 (UTC)[reply]
@WhatamIdoing: Yes but here is also question "independent (before event occured) vs non-independent (after event occured)". For me in this case we still have no independent (after event occured) source. Right? Eurohunter (talk) 15:21, 22 March 2022 (UTC)[reply]
Right. Pre-event announcements are technically reliable for a statement that the event was "planned" or "announced", and not that it "happened". WhatamIdoing (talk) 16:28, 22 March 2022 (UTC)[reply]
  • I'm having a hard time envisioning the the scope of the question. Eurohunter, can you point us to the locus of the specific dispute that led you to ask this question? As with many of these issues, the specifics always matter, and it is difficult to speak in the general in a way that will be sufficient to resolve a specific dispute properly. --Jayron32 18:16, 22 March 2022 (UTC)[reply]