Wikipedia:Village pump (policy)

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines.

• If you want to propose something new that is not a policy or guideline, use Village pump (proposals).
• If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards.
• If you want to ask what the policy is on something, try the Help desk or the Teahouse.
• This is not the place to resolve disputes over how a policy should be implemented. Please see Wikipedia:Dispute resolution for how to proceed in such cases.
• If you want to propose a new or amended speedy deletion criterion, use Wikipedia talk:Criteria for speedy deletion.

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

« Archives, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197

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)

• Support as proposer. Chess (talk) (please use {{reply to|Chess}} on reply) 22:42, 8 February 2022 (UTC)
• 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)

  @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)

  @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)

• 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)
  • Per Schazjmd, I would prefer an exception for unreviewed new articles, or a 60 or 90 day period, but if there is not a consensus for that then I would also support the proposed 30 days. BilledMammal (talk) 00:25, 9 February 2022 (UTC)
• 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)
• Support. Will streamline Wikipedia processes and reduce backlogs. Xxanthippe (talk) 00:13, 9 February 2022 (UTC).
• 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)
• 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)
• 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)
• 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)
• 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. Silverseren^C 04:10, 9 February 2022 (UTC)
• Oppose as written - I've supported the longer timeline below Nosebagbear (talk) 09:54, 9 February 2022 (UTC)
• 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)

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)

And how is that different from English Wikipedia's CSD G13? --Ahecht (TALK
PAGE) 15:00, 10 February 2022 (UTC)

• 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)
• 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)
• Support per my post on the post-90-day ban below. Ajpolino (talk) 21:40, 18 February 2022 (UTC)
• Oppose my opposition in the 'post-90-day ban below' applies equally here, but perhaps with more force! Fiddle^Timtrent Faddle^Talk to me 09:20, 21 February 2022 (UTC)
• Oppose scope_creep^Talk 00:08, 22 February 2022 (UTC)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)

  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)

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)

• Support as proposer. Chess (talk) (please use {{reply to|Chess}} on reply) 04:53, 9 February 2022 (UTC)

  @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)

• Support as before. Xxanthippe (talk) 04:55, 9 February 2022 (UTC).
• Support as before. BilledMammal (talk) 04:55, 9 February 2022 (UTC)
• Support as before. Silverseren^C 05:03, 9 February 2022 (UTC)
• Support with everything I said above the same. Curbon7 (talk) 05:22, 9 February 2022 (UTC)
• 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)
• Support Mccapra (talk) 08:25, 9 February 2022 (UTC) changing my mind after reading other comments
• 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)
• Support as before. NemesisAT (talk) 10:01, 9 February 2022 (UTC)
• 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)
• Support as before. Schazjmd (talk) 15:04, 9 February 2022 (UTC)
• 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)

  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)

• 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)
• 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)
• 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)
  • 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)
    • 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)
• 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)
• 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)

  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)

• 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)
• Support 60 days. TheBirdsShedTears (talk) 02:40, 13 February 2022 (UTC)
• 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)

  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. Silverseren^C 04:42, 13 February 2022 (UTC)

  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)

  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)

• changed to oppose after reading over at WT:NPR Happy Editing--IAmChaos 22:36, 21 February 2022 (UTC)
• 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)
• 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)

  @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)

  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)

• Support Cbl62 (talk) 21:43, 16 February 2022 (UTC)
• 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)
• 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 (talk • contribs) 14:16, 18 February 2022 (UTC)
  • 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)
    • @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_creep^Talk 00:26, 19 February 2022 (UTC)

      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)

      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)

  • 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)
    • 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_creep^Talk 15:21, 21 February 2022 (UTC)
    • @Mlb96: And badly damaged doesn't mean non-notable, in any instance. scope_creep^Talk 15:29, 21 February 2022 (UTC)
• 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)
• 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)

  @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)

  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)

  @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)

  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)

• 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)

  @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)

  @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)

  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)

  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)

  @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)

  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)

• 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)
• 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)

  @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)

  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)

  @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)

• 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)

  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. Santacruz ⁂ Please ping me! 13:17, 19 February 2022 (UTC)

• 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)
• 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)
• 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)
• 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. Fiddle^Timtrent Faddle^Talk to me 09:09, 21 February 2022 (UTC)

  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)

  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? Fiddle^Timtrent Faddle^Talk to me 12:16, 22 February 2022 (UTC)

  @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)

  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 Fiddle^Timtrent Faddle^Talk to me 21:44, 22 February 2022 (UTC)

  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)

  @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)

  @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. Fiddle^Timtrent Faddle^Talk to me 18:52, 6 March 2022 (UTC)

  @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)

• Oppose overly prescriptive limit; solution in search of a problem. Stifle (talk) 10:27, 21 February 2022 (UTC)
• 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)
• Oppose per WP:CREEP. There needs to be some room for discretion. Beeblebrox (talk) 21:58, 21 February 2022 (UTC)
• Oppose per Stifle and Beeblebrox. Doesn't seem to actually solve anything, and adds pointless bureaucracy. ansh.666 22:40, 21 February 2022 (UTC)
• 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)
• 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)
• Oppose Per Beeblebrox. Having such an arbitrarily defined hard limit seems ill-advised. ThePlatypusofDoom (talk) 09:00, 22 February 2022 (UTC)
• 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)

  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)

  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)

• 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)

  Disputes over draftification are supposed to go to AfD. Not ANI. SmokeyJoe (talk) 03:35, 24 February 2022 (UTC)

  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)

  Same as now. WP:DRAFTOBJECT. SmokeyJoe (talk) 10:16, 24 February 2022 (UTC)

  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)

  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)

  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)

  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)

• 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)
• Support Draftification is not a way to delete an abandoned article. We should have {{update}} template. Thingofme (talk) 12:12, 23 February 2022 (UTC)
• Support with modifications, namely changing "articles" to "patrolled articles". --Ahecht (TALK
  PAGE) 13:31, 23 February 2022 (UTC)
• Oppose, I see no good enough reason for this. Fram (talk) 15:55, 23 February 2022 (UTC)
• 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)
• 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)
• 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)
• 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. Reywas92^Talk 18:40, 24 February 2022 (UTC)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)

  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)

  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)

  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)

  @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)

  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)

  "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)

  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)

• Oppose per Beeblebrox. Spencer^T•C 04:17, 2 March 2022 (UTC)
• 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)

  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)

  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)

  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)

  @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)

  @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)

  @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)

  @Onel5969: Elinruby (talk) 00:05, 10 March 2022 (UTC)

• 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)
• 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)
• 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)
• 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)
• 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)

  @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)

  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)

  • Thank you for explaining/fixing this Soni (talk) 15:38, 10 February 2022 (UTC)
  • Comment Will this brand new RfC be considered binding on all editors and admins? Because I don't think it has been widely publicized and it should run for at least one month. I can't believe such a drastic new policy will be decided here. Liz ^{Read! Talk!} 01:54, 13 February 2022 (UTC)

    This RFC would presumably result in the addition of a sentence to Wikipedia:Drafts (and/or other suitable pages), and it would presumably be just as binding as anything else on that page. If someone did unilaterally draftify an old article, the solution would be just to move it back (and presumably also send it to AFD), maybe while saying something like "Sorry, I didn't know that had changed. Thanks for telling me". WhatamIdoing (talk) 20:20, 17 February 2022 (UTC)

• 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)
• 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)
  • My assumption would be 90 days from the conversion; the redirect might be seven years old, but the article is only ten days. BilledMammal (talk) 04:32, 13 February 2022 (UTC)
• 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_creep^Talk 12:53, 19 February 2022 (UTC)
• 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)

  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)

  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)

  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)

  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)

  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)

  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)

  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)

• Comment I find that Mccapra has got to the core of this, and I concur with their view. Fiddle^Timtrent Faddle^Talk to me 09:26, 21 February 2022 (UTC)
• Support - If a topic is notable, the article can be improved in the mainspace. Darkknight2149 05:15, 25 February 2022 (UTC)
• 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)
• 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)
• 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)
• Oppose. Too similar to the above proposal. Suggest withdrawing to avoid duplication of !votes/effort. –Novem Linguae (talk) 01:15, 26 February 2022 (UTC)

  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)

• 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)
• 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 - 2¢ 02:45, 2 March 2022 (UTC)
• 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)
• 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)
• 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)

  @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)

  @Spinningspark:  Done. The alternative would be to move the votes there, but this is sufficient enough. Soni (talk) 23:48, 6 March 2022 (UTC)

  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)

• 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)
• 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)

  @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)

  Considering I've been here since 2017, yes, I did know. It is purposefully vague. ––FormalDude talk 22:50, 8 March 2022 (UTC)

  @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)

  @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)

  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)

• 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)
• 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)
• 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)
• 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)
• Support - Master Of Ninja (talk) 09:57, 10 March 2022 (UTC)
• 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)
• 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)
• 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. ⁓ Pelagic ( messages ) 11:18, 13 March 2022 (UTC)
• 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)
• 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)
• Support as longer timeframe Happy Editing--IAmChaos 21:08, 14 March 2022 (UTC)
• 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)
• 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)
• Support per my comment in the section above. Regards SoWhy 19:37, 16 March 2022 (UTC)
• 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)
• Oppose in its current form: See Onel5969's objections. MarioGom (talk) 08:51, 18 March 2022 (UTC)

• 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)

• Ah, stumbled on it at 4AM: WP:NORUSH == WP:PATIENT?

IveGoneAway (talk) 10:45, 22 March 2022 (UTC)

• 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)

• 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)

• Support 90 days is good. Ironmatic1 (talk) 19:39, 22 March 2022 (UTC)

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

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)

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)

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)

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)

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)

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)

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)

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)

@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)

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)

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. Silverseren^C 00:03, 12 March 2022 (UTC)

• 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)

• 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)

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)

• This would presumably mean any page that it was desired to delete would need to be moved back to mainspace or go through MFD. Crouch, Swale (talk) 10:33, 24 March 2022 (UTC)

  If you wish to delete it, you can nominate it for deletion without moving it back to mainspace and the move will then happen if the consensus at the deletion discussion is "keep". I would prefer AFD to MFD in these cases though since that would have been the correct venue. But if you cannot make a compelling case for deletion other than "it needs more work", then it should not be left in draftspace. Which is what the current editing policy already mandates after all, i.e. that anything eligible for inclusion that can be improved should be kept. SoWhy 10:46, 24 March 2022 (UTC)

• I like this. I think we should clearly specify whether the other applicable criterion includes or excludes A-series criteria. I can see arguments in favour of both options, and don't immediately know which I favour, but leaving it unspecified feels likely to result in arguments down the line. Thryduulf (talk) 14:43, 24 March 2022 (UTC)

  The proposal is not supposed to save pages from deletion just because they are in draft space, just to prevent pages from speedy deletion that would not be eligible for speedy deletion in mainspace. My logic is simple: If the page was moved from mainspace without consent or consensus, the same criteria should apply as if it were still there. For example, if an A7-worthy article is moved to draftspace to allow the creator more time to avoid such a deletion, G13 can apply if the page in its current state meets A7 (i.e. all revisions meet A7) and the G13-clock has run out. Because the alternative would be to move it back to mainspace and then A7 it there (which seems pointless). Regards SoWhy 14:54, 24 March 2022 (UTC)

  Yes, I understand that, I'm just saying that (if people agree this is what we want) it would be best to explicitly say that so there are no arguments that G13+A7 is invalid because A7 doesn't apply to draft space. Equally if consensus is that A criteria should not apply in this situation, then we should explicitly say that to avoid the exact opposite argument. Thryduulf (talk) 15:12, 24 March 2022 (UTC)

• This doesn't really solve the problem, merely papers over it. An article that was moved from draftspace and then rotted there for six months has already been de-facto deleted, so preventing it from being de-jure deleted accomplishes nothing. * Pppery * _{it has begun...} 15:40, 24 March 2022 (UTC)

  @Pppery Agreed. -- asilvering (talk) 15:56, 24 March 2022 (UTC)

  @Pppery: This proposal is an auxiliary idea to prevent backdoor deletions by forcing editors to confront the merit of a page in discussion at least once (unless speedy deletion applies). Whether that's immediately or after six months does not change that. Regards SoWhy 16:48, 24 March 2022 (UTC)

• My take on all of this: 1) with a “New” Article, we can assume that the creator is active and will be willing to continue to work on the article if draftified. The question is simply defining the timeframe for what constitutes a “New Article”. 2) When it comes to “Old” Articles we can not make that assumption. My feeling is that “Old” articles should no longer be draftified - UNLESS at least one editor explicitly states that they are willing to step-up and take responsibility for improving it. This would obviously require some form of discussion prior to draftification… either in a formal AFD or on a talk page somewhere. The point being that if no one is willing to step-up and claim responsibility, then there is no point to draftification (and we should default to deletion). 3) IF there is someone willing to step-up and improve the draftified article, we should give them as much time as they need to do so. There is no need for an automatic “back-door” deletion in Draftspace. Blueboar (talk) 15:58, 24 March 2022 (UTC)

  This proposal presupposes the current practice of articles being draftified without discussion and then G13-deleted as stale drafts. I don't argue in favor of this practice, quite the opposite, but as long as it exists, we have to address at least this loophole and this proposal attempts to do so. Regards SoWhy 16:44, 24 March 2022 (UTC)

• comment I think it would be useful to create a list like this for this alternative solution to work. --SilverMatsu (talk) 09:29, 25 March 2022 (UTC)
• Comment I think a more general change would be useful - make G13 only apply to articles that are not suitable for mainspace. If an article is moved to draft space by NPP because it is unsourced, we shouldn't need to waste editor time on deleting it once it has been abandoned. On the other hand, if an abandoned draft is suitable for mainspace, then it should be moved there, rather than deleted. BilledMammal (talk) 05:29, 3 April 2022 (UTC)

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:

• https://en.wikipedia.org/wiki/Wikipedia:Congressional_staffer_edits

• https://en.wikipedia.org/wiki/Orangemoody_editing_of_Wikipedia

• https://en.wikipedia.org/wiki/Wiki-PR_editing_of_Wikipedia

• https://en.wikipedia.org/wiki/Church_of_Scientology_editing_on_Wikipedia

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:

• https://www.dailydot.com/irl/wikipedia-sockpuppet-investigation-largest-network-history-wiki-pr/

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:

• https://www.newstatesman.com/politics/2011/09/hari-rose-wikipedia-admitted

• https://www.salon.com/2013/05/17/revenge_ego_and_the_corruption_of_wikipedia/

• https://www.newsweek.com/2015/04/03/manipulating-wikipedia-promote-bogus-business-school-316133.html

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)

• 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)
  • Except no competent lawyer would write this. It's unproofread gibberish. Julietdeltalima (talk) 08:42, 17 March 2022 (UTC)

^THIS. ~ ONUnicorn^{(Talk|Contribs)}problem solving 18:17, 17 March 2022 (UTC)

• • 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)

    Where does it say that it does not recognize the concept of ethnicity? Levivich 17:41, 17 March 2022 (UTC)

    3.1, first bullet: The Wikimedia movement does not endorse "race" and "ethnicity" as meaningful distinctions among people. --Ahecht (TALK
    PAGE) 04:36, 28 March 2022 (UTC)

• 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 - 2¢ 16:32, 5 March 2022 (UTC)

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)

• 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)

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)

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)

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)

I think on the basis of UCoC's definition of "psychological manipulation" I would vote against the enforcement guidelines. Just about any conversation could be construed or twisted to show there was intent 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. The long and possibly largely private (protecting the victim) ensuing battle will probably hinge on if there was "clear" maliciousness. Would not almost every argument, debate, or discussion revolve around an objective to win an argument? If enforcement is written so broad to include all aspects of the realm under which the WMF ultimately governs, without regard to those that are largely self-governed, then there is an issue. If left unresolved it will only hurt some platforms such as this one. Of course, there are those that are experts at gaming and when proven should be dealt with. There will likely be real cases, possibly some emergencies, and some legal aspects that needs the WMF to step in, but they already have that authority and should use it only when needed. The WMF does not need to create wording so vague that just about anyone will be guilty from the start. Even the essay WP:GOAD has the actual title Don't take the bait -- Otr500 (talk) 02:59, 28 March 2022 (UTC)

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)

• Yes—why not? A few months ago a featured article was nominated for deletion and the result was merge. JBchrch talk 15:31, 5 March 2022 (UTC)
• Articles are suitable to be merged/deleted/redirected etc. regardless of the quality scale. We've had plenty of FAs be deleted in the past. Best Wishes, Lee Vilenski ^{(talk • contribs)} 15:33, 5 March 2022 (UTC)
• Any change in policy which prevented 'good articles' from being deleted or merged would inevitably result in abuse of the 'good article' designation. AndyTheGrump (talk) 15:37, 5 March 2022 (UTC)
• Any article should stand on the merits of its subject. Designations like GA and FA are indications of the quality of the article, rather than notability of its topic. If you think this one should be kept then argue for it in the deletion discussion without regard to the quality of the article. Phil Bridger (talk) 17:02, 5 March 2022 (UTC)
• If you think a GA or FA you should be deleted, I'd strongly recommend making sure to do a really thorough WP:BEFORE and ensuring the deletion nomination is well thought out, clearly articulated and proofread, but there is and should be no prohibition on the nomination. Thryduulf (talk) 18:23, 5 March 2022 (UTC)
  • Would like to note that way back in the day there was a hoax that was a Good article. I think Thryduulf has the right idea. -Indy beetle (talk) 23:00, 5 March 2022 (UTC)
• Who remembers Bulbasaur (AfD discussion)? Uncle G (talk) 09:29, 7 March 2022 (UTC)
• Notability is not written into either the GA criteria or the FA criteria (although in current times it is a bit harder to get a NN subject to FA). If it's not notable, then AFD is the way to go. I've nominated a GA for deletion before (Wikipedia:Articles for deletion/M-144 (1937–1939 Michigan highway), ended in redirect). Besides the Lewis AFD linked above, Wikipedia:Articles for deletion/Doug Ring with the Australian cricket team in England in 1948 (2nd nomination) is another example of a FA not surviving an AFD. Hog Farm _Talk 20:53, 7 March 2022 (UTC)
• Nominations that clearly aren't going anywhere can be handled through WP:SNOW keeps and existing processes. Frivolous nominations can be handled by penalizing the editor making them. I don't see the point of making this blanket rule. Chess (talk) (please use {{reply to|Chess}} on reply) 07:02, 10 March 2022 (UTC)
• Certainly. A single editor deciding or saying that it meets GA criteria should not prohibit the normal review processes. North8000 (talk) 18:14, 17 March 2022 (UTC)

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)

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)

• 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)
• 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)
• Lipstick on a pig scenario, except in reverse. I guess. casualdejekyll 22:48, 28 March 2022 (UTC)
• Yes, they are not exempt. Emir of Wikipedia (talk) 21:40, 5 April 2022 (UTC)

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)

---

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

More languages • Please help translate to other languages.

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: ucocprojectwikimedia.org

Sincerely,

Movement Strategy and Governance
Wikimedia Foundation

---

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

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%)

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)

• Less than 2000 so far? That this is getting so few respondents is worrisome. Perhaps it should have been advertised more widely (ie with a banner). Blueboar (talk) 12:04, 18 March 2022 (UTC)

  @Blueboar, locally we ran a watchlist notice, and globally there is a CentralNotice banner which began on the 16th. — xaosflux ^Talk 13:15, 18 March 2022 (UTC)

Huh… missed that. Ok, but I still find the low turnout disturbing. Blueboar (talk) 13:24, 18 March 2022 (UTC)

Indeed! Donald Albury 17:14, 18 March 2022 (UTC)

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)

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)

@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)

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%) A few numbers were mismatched; fixed. Xeno (WMF) (talk) 02:23, 20 March 2022 (UTC)

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)

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%)

Please share the information links with interested users: Project Overview • Universal Code of Conduct • Enforcement guidelines (proposed) • Voting • Voter 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)

@Xeno (WMF) Any idea how WMF staff fit into the pie chart? --Ahecht (TALK
PAGE) 15:04, 20 March 2022 (UTC)

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)

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)

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)

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%)

Please share the information links with interested users: Project Overview • Universal Code of Conduct • Enforcement guidelines (proposed) • Voting • Voter information

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

@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)

@DuncanHill: Apparently the local link is broken. m:Special:SecurePoll/vote/391 works, though. --Yair rand (talk) 01:24, 21 March 2022 (UTC)

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)

• @Bilorv, Blueboar, Bonadea, Calliopejen1, Carcharoth, Chrisvls, Claude J, Clovermoss, CoffeeCrumbs, Deepfriedokra, EllsworthSK, Enigmaman, Gtoffoletto, Headbomb, Isaacl, JJMC89, Jayron32, Jc37, Jheald, Jonesey95, Kaldari, Lomrjyo, Megalibrarygirl, Mr248, MrOllie, Newslinger, Nick Thorne, Nigel Ish, Nishidani, Otr500, Pelagic, Pigsonthewing, Rdfox 76, Seraphimblade, Shushugah, Slatersteven, Softlavender, Steven Crossin, Tazerdadog, Titodutta, Valereee, WJBscribe, Waddie96, Winged Blades of Godric, Zero0000, and Zzuuzz: (Pinging those who have previously commented on the WMF's "universal code of conduct" project, excluding those who have already voted.) The vote on the proposed Universal Code of Conduct Enforcement Guidelines closes in <24 hours. The texts are here and here, voting is here. --Yair rand (talk) 01:28, 21 March 2022 (UTC)

Thanks @Yair rand: As Xeno says, it is working again. DuncanHill (talk) 01:26, 21 March 2022 (UTC)

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)

Thanks for the !ping waddie96 ★ (talk) 13:16, 21 March 2022 (UTC)

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)

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)

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%)

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)

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%)

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%)

Please share the information links with interested users: Project Overview • Universal Code of Conduct • Enforcement guidelines (proposed) • Voting • Voter 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)

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%)

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%)

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%)

See more statistics here.

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

Can we get a view of WMF employees participation, independent of which wiki is their home? I see 46 usernames with (WMF) in it, in various projects. The participation levels seem really low in general, but relatively high for the WMF. 46 is more than the number of participants from Portuguese and Indonesian Wikipedias. There are 232 Million people who speak Portuguese and 42 Million people who speak Indonesian, but only 550 WMF employees. I would support discounting those votes, if they were required to affirm and support the UCoC as employees. Vexations (talk) 14:10, 30 March 2022 (UTC)

Vexations: What statistics are you interested to see? 48 voters had (WMF) or -WMF in their username which represented about 2% of the 2352 votes cast. (P.S. There is a parallel discussion at WP:VPM where I linked statistics which show where voting users were active, i.e. at least 20 edits during the eligibility period - ptwiki had 60, Indonesian languages also had more representation than shown by the home wiki distribution.) Xeno (WMF) (talk) 14:31, 30 March 2022 (UTC)

Well, for example, I'd like to see for each wiki how many people were eligible to vote, how many people actually voted and what percentage of eligible votes that represents. Something like Turnout by wiki in https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/Enforcement_guidelines/Voting/Stats

Assuming that 48 of 550 eligible WMF employees voted, that is approximately 8.7%, a much higher percentage than the large wikis.

A ratio of % of electorate/% of total voters would be interesting as to see as well. For enwiki, that ratio is almost 1.1, but it's 2.5 for the WMF employees. Vexations (talk) 15:00, 30 March 2022 (UTC)

I would expect higher participation from a group of people for whom Wikipedia is their livelihood, vs people who just happen to speak the language. How many of those 232 million Portuguese speakers spend a significant amount of time editing Wikipedia every day? Frankly, 8% participation from WMF employees sounds really low -- in my company when employees are asked to participate in a voluntary survey we usually get closer to 40% participation. --Ahecht (TALK
PAGE) 14:39, 30 March 2022 (UTC)

Should we allow votes from people who can only vote one way? Vexations (talk) 15:01, 30 March 2022 (UTC)

Is there any evidence that they could only vote one way? Thryduulf (talk) 15:35, 30 March 2022 (UTC)

I looked a bit more closely at the WMF staff who voted and noted that 11 of them hadn't made any contributions in 2022, and some made as few as 3 edit in their entire edit history. The weight that we assign to those votes is extraordinary. I think that deserves more scrutiny. Vexations (talk) 15:31, 30 March 2022 (UTC)

Note that edit counts are a very unreliable way to measure engagement, some of those staff may have made contributions with non-staff accounts, or contributed in other ways (e.g. maintaining the software, processing donations, etc, etc) Thryduulf (talk) 15:37, 30 March 2022 (UTC)

"Engagement" was not an eligibility criterion. I won't single out individual voters, but I did check for alternative accounts. To address your point about "contributing in other ways": they're employees, so yes, they contribute in some way. As do all kinds of other people who were not allowed to vote because they did not meet the eligibility criteria. But those criteria do not apply to the WMF. Vexations (talk) 16:52, 30 March 2022 (UTC)

Is there a rough time frame for when the results will be published? Sideswipe9th (talk) 15:05, 30 March 2022 (UTC)

I'll cross-post below; tl;dr: scrutineers are still reviewing, and hopefully about 2 weeks from close of voting. Xeno (WMF) (talk) 17:14, 30 March 2022 (UTC)

Universal Code of Conduct Enforcement guidelines ratification vote - closing message

cross-posted from WP:VPM#Universal Code of Conduct Enforcement guidelines ratification - extended voting statistics

---

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

More languages • Please help translate to other languages.

Greetings,

The ratification voting process for the revised enforcement guidelines of the Universal Code of Conduct (UCoC) came to a close on 21 March 2022. Over 2300 Wikimedians voted across different regions of our movement. Thank you to everyone who participated in this process! The scrutinizing group is now reviewing the vote for accuracy, so please allow up to two weeks from the close of voting for them to finish their work.

The final results from the voting process will be announced here, along with the relevant statistics and a summary of comments as soon as they are available. Please check out the voter information page to learn about the next steps. You can comment on the project talk page on Meta-wiki in any language. You may also contact the UCoC project team by email: ucocprojectwikimedia.org

Best regards,

Movement Strategy and Governance

---

Some additional statistics are available and discussed at WP:VPM#Universal Code of Conduct Enforcement guidelines ratification - extended voting statistics. Xeno (WMF) (talk) 17:14, 30 March 2022 (UTC)

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))

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)
• 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)
  • Gråbergs Gråa Sång, I can modify the prompt if you would like. — Mhawk10 (talk) 22:34, 15 March 2022 (UTC)

  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)

• 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)

  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)

  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)

• 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)

  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)

  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)

  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)

  @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)

  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)

  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)

  @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)

  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 thi2nk 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)

• 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)
• 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)

  That arb was not me, but I'm glad the RfC tags were removed. Best, Barkeep49 (talk) 02:44, 16 March 2022 (UTC)

  I can confirm that Barkeep was not the arb. — Mhawk10 (talk) 02:49, 16 March 2022 (UTC)

  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)

  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)

  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)

• 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)

  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)

  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)

  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)

  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)

  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)

  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)

  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)

• 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)

  @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)

  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)

• 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)
• 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)

  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)

  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)

• 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)

  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)

  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)

  @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)

  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)

  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)

  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)

• 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)

  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)

  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)

  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)

• 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)
• 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)
• 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)

  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)

  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. –MJL ‐Talk‐^☖ 15:38, 21 March 2022 (UTC)

• 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)

  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)

• 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)

  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)

  @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. –MJL ‐Talk‐^☖ 03:44, 24 March 2022 (UTC)

  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)

  @Nosebagbear: Nope! It seems pretty trivial and doesn't add much to the article. You could possibly include it in the external link section, I guess, but Jimbo is the only page I'd say that it might happen for. –MJL ‐Talk‐^☖ 16:35, 24 March 2022 (UTC)

• 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)
• WP:OSPOL and WP:OUTING must apply in all mainspaces. Otherwise there is no point and no coherence to them. You cannot have something that is accepted in mainspace, but if quoted on the talk page of that article would be eligible for suppression. WP:OUTING defines "outing" as Posting another editor's personal information ... unless that person has voluntarily posted their own information, or links to such information, on Wikipedia. (emphasis in original), and goes on to give examples of "personal information". Connecting a Wikipedia username to information about a person, even just a job title, is specifically defined as outing.
  This does not just mean that you cannot mention a Wikipedia username in a mainspace article if the subject has made the on-wiki connection, but you also cannot add {{Connected contributor}} on the talk page, or message them on their talk page saying "This article about you has just been created". Where we fall on linking or referencing RSes that out a Wikipedian is less clear, but see Wikipedia:Linking to external harassment.
  As it stands, this does indeed privilege Wikipedia editors over non-editors in prioritising their privacy over encyclopedic information, but I believe only in very rare edge cases that are difficult to analyse. This is enshrined in WP:HNE's Content and sourcing that comply with the biographies of living persons policy do not violate this policy [that WP:OUTING etc. applies to non-Wikipedians]. To change this, we would need to propose a concrete change to WP:OSPOL or WP:HARASS. — Bilorv (talk) 21:38, 24 March 2022 (UTC)

• I think I said this before or maybe I thought I said it but didn't, but I don't think WP:OUTING should ever override our article content policies. Otherwise we have the IMO unacceptable situation where it's fine to mention that Mitt Romney operated a Twitter account under the name Pierre Delecto as we do in Mitt Romney#Social media but somehow cannot do so if the same situation arises with a Wikipedia account. The privacy of Wikipedia accounts should not be protected in article content over other private matters, this is inconsistent with the purpose of BLP etc.

  Note that as our OUTING is generally understood, an editor needs to themselves make the connection on wiki. So an extremely notable person could publicly talk about how they edited Wikipedia with account X and this could be very widely reported. Yet if this Wikipedia account never made the connection, it's technically still outing. There are good reasons for this, and indeed I just dealt with a case at ANI+NPOVN where I pointed out that whatever had been said on Twitter and whatever the similarities of user names, it was outing to link what had been said on Twitter here unless the editor had themselves linked their Twitter account (which it turned out they did). So I fully support that policy when dealing with editors as editors. But when dealing article content that's a different matter.

  As others have said this doesn't mean we should always give the user name etc or always mention Wikipedia user/allegations just because it was reported in sources, there are plenty of content reasons we may not do so. Indeed navel grazing or whatever you want to call it unfortunately does mean editors are way too quick to add stuff about Wikipedia which is something we should oppose. But there longer we last the more likely we will end up being in a situation when it will be appropriate and we would do for anything else and we should not let OUTING prevent that.

  As I said I'm restricting this article content only. Obviously this means there may need to be discussion about inclusion etc on the article talk pages or other places. Such discussion should be limited to where it's necessary and any editor who appears to be doing so gratuitously or with the purpose of outing the editor should be sanctioned. If it's decided not to include any link, I think it'll generally be fine provided it doesn't cause more confusion to remove the discussion. We can consider rev-deletion but frankly IMO the only times when the discussion would be legitimate in the first place are when it's probably a bit silly since we're rev-deleting something widely covered in sources, still I won't oppose.

  We should generally not tag articles with connected contributor in cases where the editor hasn't made the link and the only link has been in external sources. And editors should not bring up the connection outside of discussing the inclusion of the material i.e. in discussion about the editor. If they have concerns, they can take them to arbcom.

  Note that if we do allow OUTING to override our content policies, not only will this affect our utility and reliability as an encyclopaedia, but this is actually IMO more harmful to editors included editors who may be affected given that I don't think we will ever eliminate navel grazing. An editor A may have linked their account on wiki to a real world identity of someone notable for something that has nothing to do with Wikipedia. They may still prefer it isn't mentioned in articles. In reality navel grazing means it often may be despite the person being notable for something else and very few articles about them mentioning the Wikipedia connection. Unfortunately as anyone with experience with BLP and CoI knows, even if this editor points this out in a reasonable manner, it may be difficult for them to get any action. The editor can try walking back their linkage which we sometimes sort of allow, but that is complicated and could easily make things worse for them, and may not even be what they really want to do. Yet account X where there a multitude of reliable sources connection them to a real life notable person, the person themselves has confirmed the connection and doesn't even oppose the linkage but has never said so on Wiki because they no longer use the account is protected. Unsurprisingly editor A is going to think the situation is incredibly unfair. Yes the primary issue may be our navel grazing that we need to deal with but by not turning OUTING into some sort of overriding policy on article content we may actually help remind editors that what matter is our content policies not our desire to protect an editor.

  Nil Einne (talk) 14:52, 6 April 2022 (UTC)

• We treat such information exactly like any other piece of information, with WP:BURDEN (the people wishing to include it must provide scrupulously reliable sources) and WP:ONUS (the people1 wishing to include it are responsible for convincing others that it is relevant); along with the more stringent WP:BLP guidance. Which is to say can is not equal to should and it must be both well referenced and there must be consensus that it is relevant. --Jayron32 16:25, 6 April 2022 (UTC)

Regarding reversion of banned edits

I just reverted an edit that removed legitimate content. Why was that legitimate content removed? Because it was added by a sockpuppet. You can find it in my most recent contributions. Had I not reverted that edit, users may never know the UAE's stance on the Russian invasion of Ukraine. This is not the first time this has happened. I can understand if a sockpuppet made a vandal edit, but an edit should not be reverted just on the basis that the user was banned. The same goes for WP:G5, which indicates that any page that is created by a blocked/banned user in violation of a block or ban should be deleted, which leads to the potential deletion of legitimate content. User quarrels should not be carried over into the main namespace. Any legitimate edit or page should not be reverted or deleted on the basis of who made the page. I am not encouraging ban evasion. I am simply saying that more specifically, users should focus on the content of the edit or page rather than the user who made it. Removing legitimate content is detrimental to Wikipedia's mission to provide the sum of all human knowledge, regardless of whose knowledge it is. The policy should be changed so to remove things saying that banned users should have their edits reverted or pages deleted. Only if the edit would be reverted or the page would be deleted anyway due to other criteria. So we get rid of WP:G5 and WP:BANREVERT. Blubabluba9990 (talk) (contribs−) 16:25, 26 March 2022 (UTC)

I tend to think that sock edits can and probably ought to be reverted to prevent their gaining by their actions. If the revert is on a hot topic, then someone like yourself will notice and can restore it if thought desirable (as well as taking responsibility for it at the same time). Selfstudier (talk) 16:29, 26 March 2022 (UTC)

It depends on the edit. If the edit is clearly helpful then it should remain. In a nutshell, it boils down to focusing on the content of the edit or page rather than the user who created it. Blubabluba9990 (talk) (contribs) 16:32, 26 March 2022 (UTC)

Different banned editors behave in different ways. Some of them lie, and make a large number of edits. Editors who revert edits by banned editors should feel free to regard the edits as lies, and revert them, unless it is stunningly obvious that the edits are helpful, correct, that any sources cited actually exist, are reliable, and support the added information. Jc3s5h (talk) 17:07, 26 March 2022 (UTC)

"prevent their gaining by their actions"

And this sort of shallow and pointless vindictiveness by all the people who think like you is just as harmful to Wikipedia as any number of vandals we have on the site. At least the latter are almost always reverted by bots. Silverseren^C 17:48, 26 March 2022 (UTC)

• I have long called out WP:G5 as one of the worst additions to the CSD criteria ever added. It exists only to support editors who care about Wikipedia as a "we win, they lose" place and who aren't here to actually write an encyclopedia. It's usage almost entirely is to damage Wikipedia, since any actual reasons to remove content from banned editors (such as if there's copyvios or BLP violations) would fall under a different CSD or content removal policy in the first place. There is literally no purpose to G5 that isn't covered by something else and it only exists to allow the removal of actual good content from the encyclopedia under the excuse of it being made by a banned person. Silverseren^C 17:52, 26 March 2022 (UTC)

  Ordinarily, when reverting an edit, editors should assume good faith and make the checks outlined in WP:BURDEN. Perhaps G5 goes a little too far, but when reverting edits by a banned editor, the reverting editor should not be required to assume good faith, nor should the reverting editor be expected to invest any more effort than a cursory scanning of the edit. Jc3s5h (talk) 19:47, 26 March 2022 (UTC)

  The reverting editor shouldn't be reverting at all if there's no reason to. That's the point. A banned editor's edits are no different than any other editors'. If they have a known history of certain bad editing, such as copyvios, then that should be checked for in particular. But the edits regardless should only be reverted if there's something wrong with the addition. If it is good content, then I consider anyone reverting it to be vandalizing the article. Anyone enacting G5 on good content is a vandal and a harm to Wikipedia, full stop. Silverseren^C 19:50, 26 March 2022 (UTC)

  Allowing banned editors harms Wikipedia more than blindly reverting and deleting all their contributions. Scrutinizing every edit of a banned editor takes a lot of volunteer time, especially as we can't mark them as reviewed so the work might be done over and over. Far more practical to just revert the lot and allow people to individually reinstate those edits they wish to to take responsibility for. —Kusma (talk) 23:20, 26 March 2022 (UTC)

  Why do you need to scrutinize any of their edits? If they were banned for making edits that violated things, such as copyvios, then that's a reason to. But simply the act of having been banned is not a reason to revert their edits at all. If they were banned for non-article reasons and socked because they're really addicted to making proper content additions to Wikipedia, reverting their edits is not helping anyone. It is just vindictive punishment BS. Silverseren^C 23:27, 26 March 2022 (UTC)

  We do not ban editors lightly, so being banned is a reason to revert all their edits. This "vindictive punishment BS", as you call it, is not particularly fun to administer but is preferable to encouraging banned editors to create sock after sock after sock. —Kusma (talk) 23:53, 26 March 2022 (UTC)

  Except they do that anyways. All of the time. Reverting their edits doesn't stop them, but it does damage Wikipedia and make everything worse than it was before. Hence why I consider G5 reversions to be vandalism and call out the editors doing it as often as I can. Since the ones doing that are a detriment to Wikipedia as a whole. Silverseren^C 23:58, 26 March 2022 (UTC)

  I disagree, in contentious areas where socks (I am referring specifically to socks) most often show up, reverting all their edits, even if it were sight unseen, is likely to result in a net improvement to the encyclopedia. Of course they do make some good edits in order to stay hidden for as long as possible. But it is just enough for that purpose, the rest are not good edits. Selfstudier (talk) 10:12, 27 March 2022 (UTC)

  If you are reverting "sight unseen" you cannot possibly know whether the edits are good or bad. Just as someone reinstating a reverted edit takes responsibility for that edit being an improvement to the encyclopaedia, the person reverting must take responsibility that the reversion is an improvement to the encyclopaedia. Thryduulf (talk) 14:44, 27 March 2022 (UTC)

• What do you guys think "ban" means? – Joe (talk) 18:32, 26 March 2022 (UTC)

  It should mean "the user's account is banned and any detection of them having made a new account is also banned". But, as noted with G5, it is instead used as "user's new account is banned and any edit they ever made is reverted", even if they sockpuppetted only to make normal articles that have no issues. It's especially annoying when certain editors do such reversions of all edits for people who were banned for behavioral problems and conflicts with others. Since that has nothing to do with their editing and so there's no reason to even think there's any other violation issues with their edits. Silverseren^C 19:40, 26 March 2022 (UTC)

  Are you aware of the difference between a ban and a block? —Kusma (talk) 23:22, 26 March 2022 (UTC)

• In the original comment Blubabluba9990 states: “Had I not reverted…users may never know the UAE's stance on the Russian invasion of Ukraine.” This is a flawed assumption. Our articles are never in a “final state”… information is constantly being added, changed, removed, and returned. There is a good chance that, had he not reverted, some other editor would have come along and mentioned the USE’s stance. When good information is removed for procedural reasons, we can assume it is only temporary. It may be annoying to have to re-add good information, but it isn’t the end of the world. Blueboar (talk) 19:56, 26 March 2022 (UTC)

  Wouldn't that defeat the purpose of removing it in the first place though. Blubabluba9990 (talk) (contribs) 19:00, 4 April 2022 (UTC)

• Come spend some time in the SPI trenches and you'll get a better appreciation for why we need G5. Throw-away accounts are free and painless to create in bulk. If all an LTA needs do to make an edit is create yet another throw-away account, then banning has no meaning. -- RoySmith (talk) 19:59, 26 March 2022 (UTC)
• I have also seen editors who believe all edits by banned users should be automatically reverted, and had to revert some reverts because they caused errors that the banned user fixed. I realize that WP:BANREVERT says good edits "CAN" be allowed to stand, which I think is too weak, good edits "SHOULD" be allowed to stand - and the whole section should be revised so this point will be clear to people who don't read beyond the first sentence. MB 20:02, 26 March 2022 (UTC)

• The problem there of course, is that (outside the realm of typo fixing or copyediting) editors may have a different view on what defines a "good" edit. In the end, if you see an edit that has been removed and you believe that it is genuinely positive, there is no problem with you taking responsibility for it yourself and restoring it. Though I would suggest not doing this with anything remotely contentious, and it's always good to leave an edit summary explaining what you are doing. Black Kite (talk) 20:28, 26 March 2022 (UTC)

  Re-fixing typos and obvious errors (like things that get flagged as errors in the error cats) is a waste of time. The banned-edit reverter should look at the nature of the edit to determine if it is genuinely negative or otherwise contentious. MB 20:53, 26 March 2022 (UTC)

• We could have further language along the lines that, while considerations of expediency might make individual attention to every edit at times difficult, editors have a general responsibility for ensuring that their own reverts are not often of good edits. In any case, this is a situation where IAR may be applicable. — Charles Stewart (talk) 15:27, 27 March 2022 (UTC)

• I have literally seen mere typo fixes undone on the grounds of the fixer being a banned editor. BD2412 T 20:11, 26 March 2022 (UTC)

Yup… annoying… but that’s all it is - an annoyance. Blueboar (talk) 20:30, 26 March 2022 (UTC)

• If no one catches it, then it is more than an annoyance. Typos and grammatical errors and the like make the encyclopedia look bad to readers. We should not be self-sabotaging our professionalism. BD2412 T 21:05, 26 March 2022 (UTC)

• As with so many other things on Wikipedia a bit of thought should go into any edits made, so the answer to the question of whether banned edits should be reverted is "it depends". This encyclopedia seems to be getting more and more dominated by people who can quote a policy or guideline for anything but act as if they are automata incapable of any human thought. Just stop going for quantity of edits and go for quality. Phil Bridger (talk) 21:22, 26 March 2022 (UTC)
• Good edits should not be reverted, regardless of the editor or the editor's status. There are probably millions of below-par articles in English Wikipedia. Anything that can be done to rectify this should be welcome. The idea that someone else may come along to reinsert the banned editor's good edit is a bit facile. Someone may show up, or they may not: the certainty of the existing good edit is replaced with an unknown probability. In the meantime, a damaging edit (the one that removed the banned editor's positive contribution) is allowed to stand. A much better punishment would be to require banned editors to do a minimum number of supervised, constructive edits. Being in debtor's prison doesn't help one repay their debt. And there will perhaps always be extreme recidivists, this way they may be more readily identifiable. 172.254.222.178 (talk) 22:28, 26 March 2022 (UTC)

  If an editor is not banned, their good edits stand and their bad edits are (hopefully) reverted; this requires some degree of triage whether edits are good or not. For banned editors, we can skip the triage bit. For editors that are particularly destructive (like most banned editors), we should skip the triage bit and blindly revert, as protecting the community from the banned editor is more important than whatever typo they fixed. —Kusma (talk) 23:11, 26 March 2022 (UTC)

Well, how about protecting the community of readers from bad content? Twenty-plus years into the project, any proper statistical sample of articles may indicate the sorry state of affairs (and I am not referring to proofing errors and related edits). Shouldn't administration be subservient to good content, not the other way around? What has a greater impact on Wikipedia's reputation? The untold number of below-par articles, or the actions of relatively few bad actors? I think these questions should be considered. 68.173.76.118 (talk) 00:21, 27 March 2022 (UTC)

Sure, but allowing a "small number of bad actors" to edit won't magically fix our millions of terrible articles. If the ban decision was correct, allowing their edits to stand is not likely to be an overall improvement. —Kusma (talk) 00:30, 27 March 2022 (UTC)

• Both G5 and BANREVERT are overused, but we definitely need some degree of expediency in handling edits by banned users. At the very least, the provision that the three revert rule does not apply to reverts of edits by banned users is necessary. Likewise we need better oversight of G5, but I'm inclined to agree with RoySmith that there are cases we need it. At the very least, I support the change proposed by MB, 'I realize that WP:BANREVERT says good edits "CAN" be allowed to stand, which I think is too weak, good edits "SHOULD" be allowed to stand'. — Charles Stewart (talk) 23:01, 26 March 2022 (UTC)

  I can't immediately spot where that proposal was made but I fully support it. I would also add something to make it clear that a user who is reverting is taking responsibility for that reversion being an improvement to the encyclopaedia. If the reversion leaves the page in a worse state (for any reason) then that is their responsibility. Thryduulf (talk) 14:47, 27 March 2022 (UTC)

  That would completely change what a ban means. The key difference between a banned editor and a non-banned editor is that the banned editor is not allowed to make good or neutral edits. —Kusma (talk) 15:25, 27 March 2022 (UTC)

  The idea that sock edits may not be reverted unless they have been scrutinized to see if they might just be good edits is not a great idea. That an editor in good standing might be sanctioned for reverting an edit made by a sock is ludicrous. An editor MAY/CAN leave a sock edit in place is the right balance.Selfstudier (talk) 15:41, 27 March 2022 (UTC)

  I wonder if there is a metric somewhere showing how many sock edits were not reverted by responding editors. There may be a general tendency to do the easy thing, in this case to just revert indiscriminately. More emphatic language may lead some editors to examine the sock edits in context. I do not think that allowing a constructive sock edit to stand should be considered "unbanning". The banned editor is still banned, and has no control over any of her/his input. 65.88.88.201 (talk) 17:25, 27 March 2022 (UTC)

  If you make edits that harm the encyclopaedia why would you not be liable to be sanctioned for it? That the edit you reverted was made by someone (suspected of being) a sock of a banned editor is irrelevant - you are responsible for your own actions, good and bad, regardless of why you made those actions. Indeed there have been several arbitration principles related to this issue, including:

  • In the spirit of building the encyclopedia we aim to preserve facts or ideas that belong in an encyclopedia and are verifiable [...] When faced with potential multiple unhelpful edits, the onus is on the reverter to assume good faith and check if the edits are actually unhelpful before reverting. (Giant Snowman, links in original)
  • The core purpose of the Wikipedia project is to create a high-quality free encyclopedia. Contributors whose actions are detrimental to that goal may be asked to refrain from making them, even when these actions are undertaken in good faith. (Climate change and many others)

  So it would seem to be up to you to explain why you should not be required to take responsibility for your own actions. Thryduulf (talk) 17:44, 27 March 2022 (UTC)

  If you're going to quote ArbCom, how about this one from Wikipedia:Arbitration/Requests/Case/Banning Policy#Banned editors?

  When an editor's conduct is exceptionally disruptive or inappropriate, that user may be banned from editing Wikipedia. Banned editors are prohibited from editing Wikipedia in any way, from any account or anonymously, and all contributions made in defiance of a ban are subject to immediate removal. While users in good standing are permitted to restore content from banned users by taking ownership of that content, such restoration should be undertaken rarely and with extreme caution, as banned editors have already had to be removed for disruptive and problematic behavior. A user who nonetheless chooses to do so accepts full responsibility for the consequences of the material so restored.

  Anomie⚔ 17:57, 27 March 2022 (UTC)

  Exactly so, we are talking about socks here, not editing in the normal course. No-one is preventing an effort to alter policy, anyone can make the case for that and see what happens. Selfstudier (talk) 18:02, 27 March 2022 (UTC)

  Everybody agrees that edits made by socks may be reverted. The question is whether they should always be reverted. If the content is actually disruptive, then obviously remove it. However if it improves the encyclopaedia then the action that is disruptive and inappropriate is the reversion - note that that very case also quotes the principle that the purpose of Wikipedia is to create a high quality encyclopaedia and that editors may be asked to refrain from actions that are detrimental to that goal. Reverting an edit that improves the encyclopaedia is detrimental to that goal. Thryduulf (talk) 18:19, 27 March 2022 (UTC)

  Revert all of a sock's edits would be unrealistic since they would have a minimum 500 under their belts to be editing in any controversial area. But I don't want to be jammed up for reverting any of their edits if I think that's the right thing to do and anyone disagrees with a revert has the right to restore if they want to. Socks should not get to make work for ordinary editors, they cause enough time wasting already.Selfstudier (talk) 18:28, 27 March 2022 (UTC)

  If you look at an edit without knowing or caring who the author is and think it makes the encyclopaedia worse in some way, then revert it. If you look at that same edit without knowing or caring who the author is and think it makes the encyclopaedia better in some way, then don't revert it. If your only reason for reverting is who made the edit then you are not improving the encyclopaedia - at best you are wasting your time and the time of everyone who evaluates your edit, at worst you are harming the project. Thryduulf (talk) 18:57, 27 March 2022 (UTC)

  Socks harm the project not good editors.19:10, 27 March 2022 (UTC) Selfstudier (talk) 19:10, 27 March 2022 (UTC)

  You have it backwards - good editors are those who do not harm the project. Bad editors are those who do harm the project - whether either is a sock is irrelevant. If an editor inserts a BLP vio into an article that is a bad edit, regardless of who made it. If an editor inserts a sourced mention of something DUE that is a good edit regardless of who made it.

  Would you revert the removal of profanity from an FA just because the editor who reverted it was a sock? If no then you are agreeing with my point that it is the content of the edit that matters. If yes, then you are actively harming the project. Thryduulf (talk) 20:42, 27 March 2022 (UTC)

  My position is quite simple. I am not a sock and I am subject to WP rules and regs same as anyone else. Your position, it seems to me, is to support, even if indirectly, sock activity. So we will have to agree to disagree and should there be a legitimate complaint against me for any revert I make, then I will deal with that eventuality then.Selfstudier (talk) 21:16, 27 March 2022 (UTC)

  Your position is that it matters who makes an edit more than it matters what the content of that edit is. My position is that the content of an edit is all that matters - edits that improve the encyclopaedia should stand, edits that don't should not. Sock or not sock is irrelevant. Thryduulf (talk) 22:08, 27 March 2022 (UTC)

  I appreciate that it is irrelevant to you and you are entitled to that view. I simply don't agree for the reasons I have given.Selfstudier (talk) 22:15, 27 March 2022 (UTC)

  Regarding the blockquote by Anomie above: 1. "subject to" is a condition, not a set course of action. 2. Constructive edits are not in "defiance of the ban", as it is assumed the ban resulted from non-constructive actions. Either ArbCom should use more exacting language, or that wording does not support blanket removal of sock edits. I have no legal experience whatsoever. My comment is based on logical, not legal analysis. 71.245.250.98 (talk) 19:12, 27 March 2022 (UTC)

  Your logic is faulty, as you're starting from a false premise regarding the definition and intent of a ban. Anomie⚔ 21:33, 27 March 2022 (UTC)

  The blockquote is self-contradictory. It states that banned editors are not to edit period, but then proceeds to muddy the waters stating that such edits are "subject to" removal and talks about edits done "in defiance of a ban". Is one to presume that some edits may be excluded? Why not just state "all edits by banned editors will be removed". The definition and intent of a ban, stated in that quote, doesn't help the contradiction. 172.254.222.178 (talk) 21:59, 27 March 2022 (UTC)

  • MB made the proposal in this edit. Kusma, two wrongs aren't generally seen as a dependable way of making a right. You can look for ways to deter banned editors even if you take responsibility for your reverts being generally constructive. — Charles Stewart (talk) 15:36, 27 March 2022 (UTC)

• The banned editor that the OP refers to is Radovicdarko538, who was blocked in October 2020 for copyright violations. A choice quote from their user talk page (diff): Basically every single edit you've made has violated WP:COPYRIGHT. They (and their socks) are the subject of an ongoing contributor copyright investigation. I would be very careful about reinstating any of their edits – policy is very clear about who is responsible for any copyright violations that are restored. DanCherek (talk) 00:06, 27 March 2022 (UTC)

• Comment: I would also note that editors implementing these reverts are often insufficiently selective. For example, this major revert was intended to remove this minor edit by a sock puppet. BilledMammal (talk) 23:24, 27 March 2022 (UTC)

• Yeah, that sort of reversion is just a blatant piece of blanking vandalism. If I didn't AGF, I would think that the sockpuppet investigation edit summary claim was just a cover for an edit attempting to make that sort of major change. Silverseren^C 23:48, 27 March 2022 (UTC)

• All edits by a banned user after they are banned should be reverted, regardless of account. That means all edits by socks after the sockmaster has been banned/blocked. Socking is, IMO, one of Wikipedia's chief weaknesses as it concerns both damaging content and harmful behavior. If you don't like that something was reverted, just reinstate it, saying that you take responsibility for it. The latter is important, because it means if there's a copyright violation, BLP violation, or other form of violation, it's on you. Just reverting and saying "it looks productive" isn't sufficient. If the banned user is actually a positive contributor such that we should permit them to make as many edits as they want as long as they create a new account each time they're banned, they shouldn't be banned. — Rhododendrites ^talk \\ 13:56, 29 March 2022 (UTC)

  All edits by a banned user after they are banned should be reverted, regardless of account. Does this imply that all edits before the ban should be considered legitimate? Did the editor suddenly break bad after a certain number of good edits? Or should pre-ban edits be scrutinized to weed out the bad ones? And if that is the case shouldn't such scrutiny be also applied after the ban? I think we should be smart about this and accept constructive edits that further Wikipedia wherever they come from. This is not all about banned editors, though some of them may bask at the attention or may aim to have discussions like this going on forever. 74.64.150.19 (talk) 12:14, 30 March 2022 (UTC)

  all edits before the ban should be considered legitimate? - Legitimate insofar as we don't automatically revert them all, but obviously not immune from scrutiny. — Rhododendrites ^talk \\ 21:32, 30 March 2022 (UTC)

• Every time this comes up, I always wonder about the situation where an editor is banned not because of their edits, but because of their behavior when making their edits. A lot of the discussion above seems to be focusing on editors who are indeffed or banned for making disruptive edits or otherwise damaging the encyclopedia. However, I know there are cases where a user's edits were not blatant vandalism or disruption, but the user was banned because they couldn't contribute collaboratively (the specific case I have in mind is WP:BKFIP but I'm sure there are others). My belief is that instead of blindly reverting, people should take note of who the sock in question actually is (or is alleged to be). If the master has a history of making edits that violate content policies, sure, revert the lot. However, if the master was only banned for communication issues, and their edits wouldn't get anyone who could communicate effectively sanctioned, then they shouldn't be reverted simply because they were made by a banned editor. All cases of edits made by socks of users banned simply for behavioral issues and not for content issues should be evaluated individually. 2601:18C:8B82:9E0:0:0:0:3BDB (talk) 00:53, 30 March 2022 (UTC)

  As an aside, this is also the reason why IMO all blocked socks should always be tagged (as along as the alleged master is known and there aren't any privacy issues with making the connection public). This way patrollers know who the master is alleged to be and can determine the appropriate level of scrutiny for any given sock edits. 2601:18C:8B82:9E0:0:0:0:3BDB (talk) 00:53, 30 March 2022 (UTC)

  Even with editors banned for content problems we will very often lose nothing by evaluating the edit. Even someone banned for copyright violations - if they add a paragraph of text then yes we need to check whether it is a copyvio but we harm the encyclopaedia by reverting their correction of a typo. There seems to be a default assumption that every banned editor only ever makes one type of contribution and that all of them are wholly and unquestionably negative. While this is the case for a handful of editors it simply is not true for the majority. Thryduulf (talk) 11:16, 30 March 2022 (UTC)

  When material is added by a banned editor, it must be evaluated. The question is: who is best qualified to conduct that evaluation? The answer to that is: the other editors who watch the page (and know the topic and its sources). This means that the automatic removal is not the end of the evaluation process… but the beginning of it. Other editors who watch the page need to follow up after a ban removal… and evaluate whether the removed material is acceptable or not… and if acceptable return it to the article under their username. Blueboar (talk) 12:37, 30 March 2022 (UTC)

  In other words automatic removal makes works for other people (which may or may not get done) without necessarily bringing any benefit to the encyclopaedia at all. The alternative would be to do the evaluation before removal. If it's clearly good, leave it in benefiting the encyclopaedia. If it's clearly bad, remove it also benefiting the encyclopaedia. If it's not clear then explicitly flag it as needing review. That way those who know the subject do not have their time wasted undoing work that just needs to be reinstated, readers benefit from an improved encyclopaedia and nobody loses. Thryduulf (talk) 14:03, 30 March 2022 (UTC)

  That makes no sense. It requires just as much work to review it after it has been removed, than before it has been removed. However, with a banned editor, we know upfront there is a better-than-average chance of the edit being disruptive, and we at least try to discourage them from continuing to sock. In your scenario, the edits may remain unreviewed for a very long time (just look at e.g. the time CCI's take), making it a lot more interesting for the sock to continue socking again and again. Fram (talk) 14:31, 30 March 2022 (UTC)

  there is a better-than-average chance of the edit being disruptive Is there any actual evidence for this? I see it (and variations of it) time and time again in discussions like this but I've never seen anybody present any actual evidence for it. Sure some individual editors' contributions are more likely to be disruptive (note: not always) but this is not true of all banned editors (because some are banned for reasons other than making disruptive content) and I'm not convinced it's true of even a majority of banned editors. As for the socking arguments, so what? Nobody has explained why a sock improving the encyclopaedia is actually a bad thing? If the edit is disruptive, remove it - nobody is suggesting otherwise. We're just suggesting that instead of expending effort reverting a good edit and then expecting someone else to expend more effort reviewing it and reinstating it that the review happens first and so no energy is wasted. Thryduulf (talk) 15:33, 30 March 2022 (UTC)

  The counter-suggestion is to save time by just assuming bad faith of all sock edits, using simple blunt tools like User:Writ Keeper/Scripts/massRollback.js. Sock puppetry is highly destructive to all of our editing and decision mechanisms, and the main way to discourage it is to simply not let any sock edits stand, whatever their quality. Yes, this loses good edits of Icewhiz and Greg Kohs and a couple dozen other smart people. However, if we let their good edits stand, it means we allow them to edit, as the vast majority of their edits are good. What do you think "Icewhiz is banned" should mean in practice when a checkuser discovers an Icewhiz sock? —Kusma (talk) 16:24, 30 March 2022 (UTC)

  Indeed. The effort to reverse sock edits is in many cases minimal. The review effort stays the same, so the main question is do we let edits by known problematic editors stand until review, or do we only accept them after review. Seems like a no-brainer to me, certainly when taking into account that one approach encourages socks, and the other discourages it. Fram (talk) 17:10, 30 March 2022 (UTC)

  Somewhat confusing. Editor X is banned. X edits again via Xsock1. Xsock1 is discovered and also banned, while at the same time Xsock1edit1 is allowed because it is deemed constructive, while Xsock1edits2 to 10 are reverted as negative. And so on. Why is this considered as X being allowed to edit? All of X's edits are owned and managed by responding admins/editors. 72.89.161.42 (talk) 19:25, 30 March 2022 (UTC)

  Related proposition: sock edits allowed to stand could be (re)signed as revisions of the responding admin/editor. 72.89.161.42 (talk) 19:33, 30 March 2022 (UTC)

  There's a copyright/plagiarism problem, but the general principle of this is already true: anyone can reinstate the edits if they want to take responsibility for them. — Rhododendrites ^talk \\ 21:32, 30 March 2022 (UTC)

  That's not true for articles deleted under G5. BilledMammal (talk) 03:27, 31 March 2022 (UTC)

  Why not? I mean, obviously you need to ask an admin to restore it so you can take responsibility for it, but there's no rule that an article deleted under G5 cannot be restored for any reason AFAIK. — Rhododendrites ^talk \\ 03:48, 31 March 2022 (UTC)

  Because you can't determine the quality of the content prior to restoring; it becomes a fishing expedition. I don't know about reverting in general, but I think removing G5 might be a good idea, and instead require the articles to be taken through the normal deletion process if they are not appropriate for Wikipedia. BilledMammal (talk) 04:11, 31 March 2022 (UTC)

  Deleting articles created by the socks of banned users is part of the core concept of a ban (it is the enforcement of "not allowed to edit"). If you suggest we stop enforcing bans, I suggest to start a discussion to repeal the banning policy instead. —Kusma (talk) 10:41, 31 March 2022 (UTC)

  instead of blindly reverting, people should take note of who the sock in question actually is if we blocked the person from editing, for whatever reason, we've decided we no longer want that person's contributions. There are many possible interventions for behavioral (as opposed to content) issues before arriving at the last, most severe tool of blocking the person. If the behavioral issues are so severe that we get to that point, we're saying we don't want that person to be here anymore, not that we don't want a specific account to stop editing. You can look at a sock's edits and say they're good just like you can look at that blocked person's main account's edits as say their good... it just so happens that the bad outweighed the good. I would strongly object to any sort of exception to "well, this person was just a toxic jerk or a chronic edit warrior or POV pusher -- so much so that we had to stop them from being able to edit -- but if they break further behavioral rules by creating a sock puppet their edits should be allowed to stand if they're good." If it's true that their content is worth allowing them to continue to run afoul of behavioral rules, just unblock their main account because we got it wrong. Until that point, in order for our blocks to actually mean anything they have to actually block the person without letting others jump in to complain about treating a blocked editor like a blocked editor. If you want to reinstate the edits, reinstate them and take responsibility for them. — Rhododendrites ^talk \\ 21:32, 30 March 2022 (UTC)

• I guess the long and short of it is that I strongly agree with the "readers first" philosophy. Every action that editors or admins take (well, minus WP:OFFICE stuff) should be prioritizing readers over editors, content over authors. Remember, we are more or less instructed that "If a rule prevents you from improving the encyclopedia, ignore it". Reverting or deleting the edits of a blocked sock is following the rules, granted. However, if the encyclopedia's content and/or the overall experience of the casual reader would be diminished or damaged by reverting sock edits where the only problem is who made them, the rule should be ignored in the interest of the readers. As I alluded to above, if the edits in question wouldn't get an editor in good standing reported or sanctioned, it's best to leave them alone. (Same user as above, for the record. Damn these dynamic IPs.) 2601:18C:8B82:9E0:A5CE:109A:272:9B9F (talk) 01:45, 31 March 2022 (UTC)

• Remember, we are more or less instructed that - but you've changed the text of IAR. It's "if a rule prevents you from improving or maintaining Wikipedia, ignore it." If "readers first" were a suicide pact, we'd never be able to ban people who harass, dox, stalk, attack, etc. other editors. Wikipedia isn't just an encyclopedia -- it's an encyclopedia project continuously edited by a community of volunteers. It also doesn't take much of a leap to conclude that it is not in the readers' best interest to allow toxic, abusive, or just plain disruptive editors to keep editing. Or rather, it's a short-sighted sort of reader-first priority. What happens to the readers of all the articles that other people would've worked on if they hadn't been busy fixing problems created by the banned user, chilled from participating by intimidating behavior, endlessly fighting the same battles against POV pushing, etc.? On a volunteer, community-written and maintained encyclopedia, what's good for the long-term health of the community is good for the readers. — Rhododendrites ^talk \\ 03:48, 31 March 2022 (UTC)

• It also doesn't take much of a leap to conclude that it is not in the readers' best interest to allow toxic, abusive, or just plain disruptive editors to keep editing. Correction, it's not in reader's best interests to let them edit disruptively. It is very definitely not in readers' best interests to disrupt Wikipedia by reverting edits that improve the encyclopaedia.
• Once again nobody is asking for copyvios, POV pushing, etc. to be retained, we're saying that only the copyvios, POV pushing and other edits that are actually harmful are reverted. Thryduulf (talk) 10:05, 31 March 2022 (UTC)

• It often takes a massive amount of time and effort to discover copyvio's, POV pushing, subtle vandalism, ... often enough to get someone fnally blocked. It often takes considerable effort to find the socks and get them blocked as well. And then you ask us to spend the same effort again to make sure that every edit that those socks made is also a copyvio, subtle vandalism, ... And somehow, it is in the readers interest to let those edits from known problematic editors remain in the mainspace because some may be beneficial, and whoever removes them wholesale, with the possibility to reinstate beneficial ones afterwards, is disruptive? Staggering. What you are actually arguing is that we should never block or ban anyone, as it will have no consequences at all, they can just start editing again with a new account and their edits will not be treated any different from those of non-blocked editors. You are giving free reign to the abusers, putting a considerable extra burden on people trying to keep such editors out, and in general you are ancouraging the sockers and discouraging the people trying to fight such issues. I don't think you fully appreciate the time it may take to e.g. find copyvio translations, which no automated tool reports, and which you don't see by just popping some sentences in Google search. You are advocating that when such an editor returns and is found, we should again prove, page by page, edit by edit, that their contributions all have the same issues. Who will ever do this, and why were they then blocked in the fuirst place if in reality that block doesn't help us one bit. A completely unrealistic and destructive approach under the guise of "thnk about the readers" who are actually done a huge disservice by this approach. Fram (talk) 10:21, 31 March 2022 (UTC)

  However, it seems that most of what you describe is related to the ease of sock creation/operation and of other forms of editing under assumed identities. I wouldn't pin the inherent weaknesses of an open platform on those who advocate a bit more discretion in the reverting of edits. 65.88.88.76 (talk) 20:35, 31 March 2022 (UTC)

• Correction, it's not in reader's best interests to let them edit disruptively. Completely disagree that we should allow banned editors -- people who we've decided either cannot contribute constructively or cause too many problems to continue whatever constructive edits they do make -- to continue receiving the benefit of the doubt as far as their contributions as long as they just keep making new sockpuppets. Toss out the exceptions to WP:CLEANSTART, too, while we're at it, because we're willing to take your edits under every new account you make. Again, if someone contributes constructively, that may be cause to revisit whether we got it wrong when they were banned, but it's not reason to just ignore the fact that they were banned (the user, all the user's edits, under any account). — Rhododendrites ^talk \\ 13:56, 31 March 2022 (UTC)

• Interesting read thus far. I pretty much always revert whatever a banned user posts or edits. They are banned and their edits should not stand. That said, I do read the edits (unless they made hundreds against the ban), and if I find an edit fully worthwhile I will re-add it under my handle while perhaps tweaking the language. If they are banned from talk pages I may revert it all or I may strike it through with a note that the post was from a banned editor. Fyunck(click) (talk) 06:27, 31 March 2022 (UTC)
• The recent application of WP:G5 to an article I contributed to resulted in a sequence of events (some of which was certainly my fault) which made me very sad, and reduced my desire to edit Wikipedia by ~95%.☹️  Tewdar  16:04, 31 March 2022 (UTC)

• Are you talking about this, where G5 was accidentally applied, and the deleting admin apologized and restored it the day after you filed a request for undeletion? — Rhododendrites ^talk \\ 16:27, 31 March 2022 (UTC)

  Yeah, that's the one. Like I say, a lot of what makes me sad about that and the aftermath was my own fault.  Tewdar  16:34, 31 March 2022 (UTC)

• (edit conflict) It should also be pointed out that the "anyone can reinstate edits made by banned users and take responsibility for them" concept is flawed. It's simply not true that anyone can reinstate edits - only experienced, registered users can reinstate edits. Any registered account that doesn't have X amount of experience (the variable here seems to constantly change), as well as any anonymous user regardless of experience, that makes a request for a refund of a G5'd page, recreates such a page themselves, and/or directly reinstates edits, will more likely than not be accused of being a sock of the same user and wind up blocked. If this is the approach that we as the community want to take towards edits where the only problem is who originally made them (revert procedurally and let others reinstate), we need to stop considering anyone who does reinstate or request refunds to be a sock simply for doing so, even if they don't have a long tenure/high edit count/certain user rights/whatever. 2601:18C:8B82:9E0:8423:8282:6E8F:5572 (talk) 16:31, 31 March 2022 (UTC)

• The cynicism/skepticism you're describing is a bigger issue than what we're talking about here. It's true insofar as unregistered or newly registered users are more likely to be accused of being a sock whenever they reinstate an edit (or, really, do much of anything that requires nontrivial knowledge of how Wikipedia works). That people throw around sock accusations without sufficient evidence or have a bad attitude towards new/IP editors is a problem, but it's not specific to the topic at hand. — Rhododendrites ^talk \\ 17:04, 31 March 2022 (UTC)

Also, blocks/bans are not meant as a form of punishment but rather to prevent disruption. If a user starts making good edits they may be allowed to appeal to their talk page if they feel remorseful about past actions. If the edit would be reverted normally (i.e. as spam or vandalism) then it should be reverted. But good edits or pages should NEVER be reverted or deleted, regardless of who made the edit. This has long been a pet peeve of mine. 2600:6C65:627F:FA3D:F588:8D5F:537C:2F52 (talk) 20:01, 5 April 2022 (UTC)

That was me I forgot to log in. Blubabluba9990 (talk) (contribs) 20:03, 5 April 2022 (UTC)

• The problem is that many such edits require extensive research to determine if they are even good. Users may violate copyright, may misrepresent source material, may create hoaxes, may be a continuous edit-warrior where neither version is objectively better, etc. Asking editors to carefully comb through every edit, spend hours digging through source material, etc. for banned editors is not a reasonable requirement. If someone is banned, it means we can't trust them to edit Wikipedia anymore. If someone else wants to come along and add the same content, or create the same article, by all means do so. But that doesn't mean that we should waste any more time on a banned editor's work than we have to. --Jayron32 16:18, 6 April 2022 (UTC)

Attribution of images

Near the end of the text of Macbeth, King of Scotland is an illustration painting labeled there as "Macbeth at the fort of Macduff", signed by "J R Skelton", who is Joseph Ratcliffe Skelton, q.v. Clicking on this painting shows that its original name was "Do you see that white sail far out to sea Yonder is Macduff" in its Wikimedia Commons jpg format, and shows a man standing at the parapet looking down at Macbeth and pointing to a distant white sail approaching on the sea.

The citation states that the painting is from the 1907 book "Scotland's story : a history of Scotland for boys and girls by Marshall, H. E. (Henrietta Elizabeth)", who is credited three times on this page as author of the book. Then clicking More details, Henrietta Elizabeth Marshall continues to be credited three more times on this Wikimedia Commons page. But nowhere, at the WP Macbeth article, or at either of the pages relating to the painting itself, is the painter J R Skelton ever mentioned.

Is there any policy governing attribution of images included in Wikipedia articles? Milkunderwood (talk) 21:44, 26 March 2022 (UTC)

MOS:CREDITS says that attribution does not belong in articles, it should be with the image itself (on the "image description page"). MB 22:15, 26 March 2022 (UTC)

We technically only require that the source of an image be documented for purposes of validating the copyright license and source. There is nothing in policy that requires us to document who made a painting or took a picture though if this information is absolutely known and verified, it is useful to add it to the file page. --Masem (t) 22:25, 26 March 2022 (UTC)

This is a public domain image hosted on Commons. There is no requirement at the English Wikipedia to provide attribution, and I doubt very much whether there is at Commons, but you could ask there. Phil Bridger (talk) 22:33, 26 March 2022 (UTC)

Using images without attribution in articles is allowed. However, most of the time mentioning the artist is good practice in the image caption anyway, and we require it when the image is what we talk about: Wikipedia:Manual_of_Style/Visual_arts#Image_captions.

But you are right that the image description page on Commons should mention the artist. Among other things, knowing the artist helps in determining whether the image really is in the public domain and in which countries. —Kusma (talk) 23:46, 26 March 2022 (UTC)

OK, thanks. I've edited the Commons file just to add his name. I thought this might carry over to the initial Media Viewer page with no edit option, but it doesn't; and at their help page they warn that it's rarely looked at - and indeed most questions are left unanswered. So a reader still needs to click the More details link to find it. Milkunderwood (talk) 00:23, 27 March 2022 (UTC)

I added the several indents for replies, which makes it much easier for a reader to distinguish them. I've recently been finding more pages with replies lined up instead of indented. Has that gone out of style here? Milkunderwood (talk) 00:37, 27 March 2022 (UTC)

@Milkunderwood: Now the indents are all wrong. You made it appear that my first comment was a reply to Phil Bridger, while it was a reply to you. My "you are right" has lost its context. Please revert. (I am on my phone and would likely mess it up). —Kusma (talk) 06:19, 27 March 2022 (UTC)

In removing colons and then reinserting a single colon, I accidentally typed a semicolon in error, and it bolded the following text, same as typing apostrophes. Is this a known feature? Milkunderwood (talk) 00:19, 28 March 2022 (UTC)

@Kusma FYI note that the new [reply] function automatically adds an additional colon - so if people use it, the problem you pointed out is likely to get more confused. However, [reply] works only on "desktops" (presumably including laptops?), not phones. Milkunderwood (talk) 01:09, 28 March 2022 (UTC)

It works perfectly on my phone (I have deactivated the broken "mobile mode"). —Kusma (talk) 08:02, 28 March 2022 (UTC)

@Milkunderwood yes a semi-colon is known. See Help:Wikitext#Description lists. Thryduulf (talk) 07:34, 28 March 2022 (UTC)

RFC discussion about samples in song articles

I started the RFC discussion about using non-free samples in song articles. Your input there is welcome. Link: Wikipedia talk:Non-free content#RfC: Using samples to identify songs in song articles --George Ho (talk) 08:11, 2 April 2022 (UTC)

Help

An admin just reverted this post by me as soapboxing. How do I say the same thing without being accused of, "soapboxing"?-Y2edit? (talk) 15:56, 2 April 2022 (UTC)

If you say the same thing, you will still be soapboxing. Go peddle your sectarian drivel somewhere else. AndyTheGrump (talk) 15:59, 2 April 2022 (UTC)

(after edit conflict) Just don't say it. Saying what you said would be soapboxing (I would probably have used a stronger word) however you said it. Phil Bridger (talk) 16:01, 2 April 2022 (UTC)

Please let me know what rules I must read about to avoid sanction/s.-Y2edit? (talk) 17:51, 2 April 2022 (UTC)

Just don't behave like a bigot and you will avoid sanctions. Phil Bridger (talk) 17:59, 2 April 2022 (UTC)

@Y2edit?: Long answer: Please see Wikipedia:Arbitration Committee/Discretionary sanctions#Guidance for editors. That section links to various policies and guidance pages which you should review to understand what is expected of editors. It is a lot of information to absorb, but taking the time to read over that material should help you avoid problems. - Donald Albury 18:06, 2 April 2022 (UTC)

(edit conflict)Phil Bridger, someone quoted this from a reliable source "

But accuracy is not the film’s priority, nor is it interested in justice and closure for the Pandit community. Instead, the purpose of The Kashmir Files is to inflame hatred against Muslims; against secular parties that Modi’s followers brand anti-Hindu; liberal intellectuals and activists, whose faith in India’s inclusive democracy runs contrary to the supremacist tenets of Hindu nationalism; and against the liberal media that the Hindu right disparages as sold-out “presstitutes.”

" which I thought was bigoted and posted what an admin eventually removed (please click and read the link I posted above). Now, how do I protest this bigotry without getting Sanctioned (even the mighty Russia has been brought to its knees)!-Y2edit? (talk) 18:10, 2 April 2022 (UTC)

Thanks Donald Albury-Y2edit? (talk) 18:13, 2 April 2022 (UTC)

Why aren't the Five Pillars a policy?

The Five Pillars are a long-established part of Wikipedia. They are listed prominently at Wikipedia:List of policies and guidelines and are frequently referenced by members of the community. As described in the talk page FAQ, they are a statement of Wikipedia's fundamental principles. We recently had an in-depth discussion and RfC around the wording of the first pillar which demonstrated its importance and relevance to the community.

Given all that, is there any reason why an RfC hasn't been held to formally make the Five Pillars a Wikipedia policy? It would give the 5P the formal heft that they seem to have gained informally. I see that this has been discussed occasionally on the talk page (here, for example), but not for quite a while, so I thought it would be worthwhile to ask. Ganesha811 (talk) 16:10, 2 April 2022 (UTC)

From a corporate speak - the 5P set our the internal mission/goals (that is, how we want to build articles that meet the larger outward Foundation mission), implemented through key corporate policies (here being NOT, V, NOR, NPOV, BLP, and a few others) with support of other P&G. So itself it is not a policy but what all policies and guidelines should be written in mind with. --Masem (t) 16:36, 2 April 2022 (UTC)

(edit conflict) Just my opinion, but when things - especially major policies like the verifiability policy and a few others - get made policy they tend to be enforced fairly literally. The 5P are principles, not statutes. (Yes, nothing here is a statute but there are some policies and parts of policies which are enforced in accordance with the words of the policy far more than others. And those are the ones that are most important to the encyclopedia.) Making the 5P a policy would put emphasis on their exact words rather than their meaning and because they weren't written with that kind of interpretation in mind, it would result in outcomes unintended by the legions of editors who have worked on the 5P. Regards, TransporterMan (TALK) 16:48, 2 April 2022 (UTC)

Thank you both for your answers. I appreciate the perspectives, especially the point about precise wording. Ganesha811 (talk) 20:02, 4 April 2022 (UTC)

Question

Is this an opinion piece? If so, is it true that it cannot be cited on Wikipedia?-Y2edit? (talk) 17:47, 4 April 2022 (UTC)

Depending on the context, anything may be cited in Wikipedia. Including opinion pieces, if they are declared as such. For instance you could cite this article as follows: "according to The Wire's media column..." etc. 65.88.88.93 (talk) 20:12, 4 April 2022 (UTC)

To add: it is important that in contentious/controversial situations, the affiliation of the source is made clear. In writing about a conflict between two nations for example, state the source's national affiliation. In a conflict between a viewpoint considered conservative and another considered liberal, state the source's ideological affiliation. And so on. Contrary to what is bandied about by the news industry, there is no such thing as reliable or objective sources. But there can be reliable, objective citations. Every case should be examined on its own merits. 65.88.88.93 (talk) 20:21, 4 April 2022 (UTC)

Results from the Universal Code of Conduct Enforcement guidelines ratification vote published

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

More languages • Please help translate to other languages.

The Trust and Safety Policy team published the results of the Universal Code of Conduct Enforcement guidelines ratification vote. The vote ended 21 March 2022. See the results and read more on Meta-wiki.

---

Hello, this is a follow up to the thread above. I'm also cross-posting the message originally posted to wikimedia-l and m:Talk:Universal Code of Conduct/Enforcement guidelines#Results from the Universal Code of Conduct Enforcement guidelines ratification vote that outlines the next step in the process: ("The Board will review input given during the vote, and examine whether there are aspects of the Guidelines that need further refinement.")

There is an upcoming Board Community Affairs Committee meeting 21 April 2022 at 10:00 UTC. Xeno (WMF) (talk) 01:29, 6 April 2022 (UTC)

---

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

More languages • Please help translate to other languages.

Hello all,

We would like to thank the over 2,300 Wikimedians who participated in the recently concluded community vote on the Enforcement Guidelines for the Universal Code of Conduct (UCoC). At this time, the volunteer scrutinizing group has completed the review of the accuracy of the vote and the final results are available on Meta-wiki. A quick summary can be found below:

• 58.6% Yes, 41.4% No
• Contributors from 128 home wikis participated in the vote
• Over thirty languages were supported in the ballot

What this outcome means is that there is enough support for the Board to review the document. It does not mean that the Enforcement Guidelines are automatically complete.

From here, the project team will collate and summarize the comments provided in the voting process, and publish them on Meta-wiki. The Enforcement Guidelines will be submitted to the Board of Trustees for their consideration. The Board will review input given during the vote, and examine whether there are aspects of the Guidelines that need further refinement. If so, these comments, and the input provided through Meta-wiki and other community conversations, will provide a good starting point for revising the Guidelines to meet the needs expressed by communities in the voter's responses.

In the event the Board moves forward with ratification, the UCoC project team will begin supporting specific proposals in the Guidelines. Some of these proposals include working with community members to form the U4C Building Committee, starting consultations on training, and supporting conversations on improving our reporting systems. There is still a lot to be done, but we will be able to move into the next phase of this work.

Many people took part in making sure the policy and the enforcement guidelines work for our communities. We will continue to collaboratively work on the details of the strong proposals outlined in the Guidelines as presented by the Wikimedians who engaged with the project in different ways over the last year.

Once again, we thank everyone who participated in the ratification of the Enforcement Guidelines.

For more information regarding the results, please refer to the Results page.

Regards,

Stella Ng on behalf of the UCoC Project Team

Senior Manager, Trust and Safety Policy

User:SNg (WMF) 00:42, 6 April 2022 (UTC)

---

For convenience, I have cross-posted a message from the senior manager of T&S Policy above that outlines next steps in the project. Xeno (WMF) (talk) 01:29, 6 April 2022 (UTC)

RfC: Add a question mark to Dubious Template

Proposal

Should we change {{Dubious}} to say ^{[dubious? – discuss]} rather than ^{[dubious – discuss]} like .

Rationale

{{Dubious}} is meant to be discussed rather than fully stated.

Comments for / against

If you truly intend to conduct an RfC, I'd recommend reading WP:RFC, as this is malformed. Also, an RfC generally shouldn't be conducted if the matter hasn't already been discussed to some degree. Is there an existing conversation? Lastly, I suppose I'm just curious as to why this isn't posted at the Talk page for the template. DonIago (talk) 02:07, 9 April 2022 (UTC)

Here’s the Original discussion. 2603:7080:DA3C:7A33:F4FF:3B44:570:60A8 (talk) 02:19, 9 April 2022 (UTC)

That's not a discussion, that's a request to update the template before a discussion has even occurred. As to whether discussion should now occur here or there, I'm not sure I have a strong opinion, though if the discussion occurs here then there should be a notification there. DonIago (talk) 02:47, 9 April 2022 (UTC)

Added discussion. 2603:7080:DA3C:7A33:F4FF:3B44:570:60A8 (talk) 03:05, 9 April 2022 (UTC)

Thanks; that looks good. DonIago (talk) 03:07, 9 April 2022 (UTC)

How is it malformed? 2603:7080:DA3C:7A33:F4FF:3B44:570:60A8 (talk) 03:45, 9 April 2022 (UTC)

A couple objections. Firstly, the rationale seems incorrect. When someone places this template, they are not asking whether the content is dubious, but rather they are in fact making the observation that the content is dubious and that effort should be spent investigating whether the cited source is accurate. Secondly, even if we accept the rationale as correct, this seems like an incredibly trivial issue. It's not clear to me what substantive confusion is caused by the absence of a question mark that would necessitate a full-fledged RfC to alleviate. See also WP:SLOP and WP:BIKESHED. Mz7 (talk) 05:26, 9 April 2022 (UTC)

Ok, added more reasoning. 2603:7080:DA3C:7A33:F4FF:3B44:570:60A8 (talk) 05:35, 9 April 2022 (UTC)

If it’s not subjective then why does it say “[dubious — discuss]” rather than just “[dubious]”? 2603:7080:DA3C:7A33:F4FF:3B44:570:60A8 (talk) 11:44, 9 April 2022 (UTC)

There's already an implied question mark: "discuss" = "?". The editor asks for others to discuss whether her/his assessment is correct. 68.173.76.118 (talk) 12:45, 9 April 2022 (UTC)

Adding a question mark improves clarity though. 2603:7080:DA3C:7A33:F4FF:3B44:570:60A8 (talk) 12:50, 9 April 2022 (UTC)

Then why does {{Original research inline}} it? 2603:7080:DA3C:7A33:F4FF:3B44:570:60A8 (talk) 12:53, 9 April 2022 (UTC)

Well, you can always start an RfC to replace [original research?] with [original research - discuss] since the question mark implies an invitation for comment. 68.173.76.118 (talk) 13:14, 9 April 2022 (UTC)

---

By :2603:7080:DA3C:7A33:F4FF:3B44:570:60A8 (talk) 23:38, 8 April 2022 (UTC)

---

• I can accept either “dubious?” or “dubious - discuss”. Both indicate that the person adding the template thinks the tagged material needs review and discussion. Blueboar (talk) 13:10, 9 April 2022 (UTC)
• "How is it malformed?"—I've added the rfc-tech category template to the section on Template talk:Dubious. The category template is a necessary piece. --User:Ceyockey (talk to me) 13:26, 9 April 2022 (UTC)
• Oppose The term "dubious" already implies doubt; adding a question mark is redundant. * Pppery * _{it has begun...} 14:18, 9 April 2022 (UTC)

  Was it incorrect for me to have added the category template on the template talk page? I thought that was the current proper procedure. Thanks. --User:Ceyockey (talk to me) 14:46, 9 April 2022 (UTC)

  Personally, given that this discussion concerns a template, I think the discussion itself should be occurring on the template's Talk page, not here, and I'm not sure the proper process has been followed for listing this as an RfC (no use of the standard template, for instance). It seems to me we should be at the level of a standard discussion in any case rather than an RfC, but...it's not worth turning a molehill into a mountain. DonIago (talk) 03:22, 10 April 2022 (UTC)

• Support -- I agree with the rationale that "dubious" implies a statement in wikivoice, the same way that "citation needed" makes a statement. If there's a discussion, it's not clear that it's dubious (and if we are sure something really is dubious, it should be tagged with something more aggressive or removed). jp×g 06:49, 11 April 2022 (UTC)

  I think that you may be confusing editor annotation/markup with the annotation's target (the related statements in the article, and their handling in the talk page). This is an RfC involving the presentation of (fairly common) editor markup. 172.254.222.178 (talk) 11:51, 11 April 2022 (UTC)