Jump to content

Wikipedia:Village pump (policy)/Archive 157

Add links
From Wikipedia, the free encyclopedia
Village pump (policy) archive  

This page contains discussions that have been archived from Village pump (policy). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX, AY, AZ, BA, BB, BC, BD, BE, BF, BG, BH, BI, BJ, BK, BL, BM, BN, BO · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197

Rethinking draft space

So, after a recent RfA, I began thinking about whether rethinking the use of draft space at all is something that we should consider. I've personally come to the conclusion that draft space is a failure, and for the most part is something that is used as a holding ground for G13 since the majority of the content is unsalvageable.

While I'm not proposing anything formally yet, I'd be curious at getting the community's thoughts on ways forward, whether it be disabling draft space completely or some other reforms. The current system isn't working, and thinking about ways to change it so we don't have to waste volunteer time maintaining a broken concept would be ideal. TonyBallioni (talk) 19:03, 15 February 2020 (UTC)

  • I think it's doing exactly what it should be doing being a graveyard for crap that would otherwise get into mainspace. And also acts as a place for WP:AFC to do its role when people aren't submitting crap. Headbomb {t · c · p · b} 19:13, 15 February 2020 (UTC)
    If you submit non-crap, the odds of it being found in AfC to be published in time for you to want to continue contributing approximate zero. The ideal here is that people should be able to create content that is notable and others improve it. Draft space hinders that goal, and does not help it. AfC could easily go back to the user subpage model for anyone who really wants to use it. TonyBallioni (talk) 19:22, 15 February 2020 (UTC)
    If your solution is to resume putting new submissions into mainspace, then you're basically accepting all the G13 nonsense that is there to die the slow death it deserves. If you want to make sure the good stuff gets in, then the solution here is to improve the AFC process. One thing that could be done is to tag the talk pages of drafts, so they get put in the various WP:AALERTS notice of Wikiprojects. It works pretty well at WP:JOURNALS and WP:WPWIR and other involved projects. Headbomb {t · c · p · b} 19:56, 15 February 2020 (UTC)
  • I don't see what benefit the current use of draft space brings to the encyclopedia. The whole point of a wiki is that content should be developed collaboratively, but in draft space nobody finds the content that needs improving. Rather than move things to draft just for them to be deleted six months later under WP:G13 people should use the existing deletion procedures where articles should be deleted, and let articles that should not be deleted be developed in main space where they belong. The use for draft space that I would support is very different from the way that it is currently used. Because Wikinews has been a failure it would be a good place for things that are in the news, so are covered by primary sources, but have not yet been covered by proper secondary sources, but it seems that enough people come out in support of having Wikipedia articles about anything covered by newspapers to preclude this. Phil Bridger (talk) 19:53, 15 February 2020 (UTC)
  • I remember being excited about draftspace early on, because it offered a place to find and collaborate on drafts that weren't quite ready for mainspace. There were two problems, though: 1) We don't have great tools for finding drafts, or even for notifying people creating articles that there's already an extant draft (an easily missed line before you start editing a page with exactly the same title as a draft is as close as we get). So nobody really uses it for collaboration/discovery. 2) After a series of RfCs and other discussions, the function of draftspace is the same as userspace but with a countdown to deletion for newbies who don't know any better. I don't know, maybe it's useful to have a bin for pages that don't need to be deleted yet, but don't make sense for any one particular user's userspace. I'd be interested to see some statistics about its usage. Admittedly, I have a specific perspective in this. I'm disappointed that draftspace is useless for experienced editors, and of the many, many new users I engage with, the vast majority of them are through off-wiki programs (courses, edit-a-thons, etc.) -- and perhaps draftspace is really just for those newbies that come to Wikipedia with no help. If that's the purpose, we should be clear about that, though. — Rhododendrites talk \\ 20:38, 15 February 2020 (UTC)
    TonyBallioni, the problem is that Draft space has been used as a holding ground for articles that should be in Category:Articles needing additional references, but that already has 387,516 articles in it, and it's pretty obvious that if a new page patroller adds that category in stead of draftifying it, nothing will happen. So they get dumped in Draft space where they await a slow death. Somehow we should find a way to get more eyes on those articles, rather than less. Vexations (talk) 20:55, 15 February 2020 (UTC)
  • I think that realistically, there is always going to be more input than manpower available to maintain it. The Weibull distribution probably doesn't strictly apply here but I suspect that the vast majority of drafts are not going to be edited collaboratively. So if you let all these things go into articlespace you get a flood of poor articles. If you put them in draftspace, a lot will be picked out by G13. Jo-Jo Eumerus (talk) 21:01, 15 February 2020 (UTC)
  • I am personally of the opinion an article in draft space is one that is open for people to collaborate on; whereas in userspace its more for personal development without interference (and I would expect to be able to cut/paste at article to mainspace if necessary). And I do use it that way myself with 20 drafts on my watchlist currently, fettling the drafts every 4 months or so(10 new; 10 ex-Afd; expect 5 to be in mainspace this year). But I agree an article to effective in draft space it needs to be in one or more peoples stewardship(watchlist) (not necessarily the creator) or its almost certainly a G13 goner. Its likely pointless putting a long established article with an inactive author to draftspace unless someone shows interest it. For new newspace entries a point to "help - my articles been draftified what do a do about it". I'd like to see a two week pre-G13 banner notice that could trigger people's watchlist interest if necessary to try to minimize G13/Refunds. We need to minimize admin manual work and have good process pathways. HEADBOMB's article alert suggestions may have some value. Its my bedtime so I'm probably talking dribble.Djm-leighpark (talk) 01:20, 16 February 2020 (UTC)
  • Draft space is a repeat of ideas that failed before, including the Incubator and Nupedia. Wikipedia succeeded where the perfectionist Nupedia failed because of its Wiki approach which is inherently quick and dirty. Even after 20 years, 99% of Wikipedia's content is less than good and every page has a disclaimer to warn readers that the content is not reliable. Our processes are built around this fundamental understanding and acceptance that our content is flawed and always will be. New content should be put alongside old content so that they can be read and processed together by everyone, not just an inadequate handful of inspectors. Draft space should be disabled and marked as yet another failed experiment. Andrew🐉(talk) 01:22, 17 February 2020 (UTC)
  • I don't try and interpret what the original ideas or thoughts belonged to the people behind the creation of the draftspace. I will however comment on its current function. There is no denying that there are more articles created then editors watching and fixing them. I work mainly in TV and film areas and check almost daily the articles alerts for these pages. There are a lot of pages that come from either non-English speaking countries or countries such as India where an article is created about some TV or web series that has a few lines, zero sources and is usually also badly written and ignores each and every MoS section it can. I personally do not have time to go over each one and fix them. I also do not have any intention of going to AfD for everyone as I find places like AfD and MfD to be bureaucracy filled places where the most horrible garbage can usually find supports to keep it. In most cases I've seen, these articles creators also never return. So what we are left with is horrible articles, with questionable notability and even more questionable unsupported statements. There is absolutely nothing to gain in keeping Wikipedia "mediocre" as one nom above me is arguing, and having these articles in article space does exactly that. To comment on the argument that drafts don't get worked on by others, I'd argue that the same articles won't get worked on even if they were in article space except from simple gnoming which doesn't make the article any better. On the other hand, articles which would have been worked together in article space, do get worked on together in draft space. There are many examples of MCU, Arrowverse, Star Wars and other notable TV series (and their seasons) that are actively worked on while being drafts. tl/dr - with the current overall system in place on Wikipedia, draftspace works and does what it needs to. --Gonnym (talk) 09:32, 17 February 2020 (UTC)
  • Don't go looking for problems where there aren't any. Getting rid of Draftspace would be a disaster which I would oppose in the strongest possible way. Just leave it alone – it's working: some articles that merit attention do get that, and those that don't generally die the deaths they deserve. --IJBall (contribs • talk) 13:39, 17 February 2020 (UTC)
  • The core issue here is that we have no meaningful way to sort and find content in draft space. But I'm not sure that burning down the house to catch the mouse is necessarily the correct way to respond to that. GMGtalk 14:01, 17 February 2020 (UTC)
  • All removing the draft space would do is massively increase the number of CSD and PROD and AFD tags being added to inappropriate new articles. If the draft space is serving no other purpose than acting as a holding area for stuff to keep it out of the article space, it's doing enough. Please don't get rid of it. --Jayron32 15:27, 17 February 2020 (UTC)
  • Here's what usually happens with draft articles:
    1. A new user creates an article in mainspace / creates a draft and submits it to WP:AFC.
    2. A reviewer thinks it's undersourced and moves it to draft space / declines the draft.
    3. By now, the new user has probably left Wikipedia (either they left when they created their page or they left because their work was rejected).
    4. Nobody else notices the page and so 6 months later, an admin deletes the draft per WP:G13.
    It's not the new user's fault that they don't know how to meet the toughest reviewer's sourcing requirements. Reviewers don't bother looking for sources to improve articles, they just draftify/decline and move on to the next "problem", and neither do admins who see a valid G13 (and thus press the delete button as it only takes 1 click). Getting rid of draftspace isn't the solution as it stop new users from creating articles altogether. Making it easier to find drafts won't fix the problem either if nobody wants to work on them. The only solutions I see are to stop draftifying articles without a proper discussion and to get rid of G13. Why is there even a deadline for draft space? Iffy★Chat -- 18:45, 17 February 2020 (UTC)
    Iffy, Reviewers don't bother looking for sources. They do if they're doing page patrol correctly. Look at the NPP flowchart. There is no way you a reviewer could reasonably arrive at draftify without meeting at least WP:BEFORE. I get your point about new users disappearing though. That is a problem, and it has to do with the size of the backlog. It takes too long to get feedback on an article. Vexations (talk) 22:55, 17 February 2020 (UTC)
    I've seen reviewers decline articles on the grounds that the citations were listed in the article but weren't formatted in the WP:REFB style. I've seen an article declined because the sources were WP:NONENG, even though that's allowed. We shouldn't design processes that only produce acceptable results if each reviewer knows dozens and dozens of rules and follows them all perfectly every time. WhatamIdoing (talk) 23:32, 17 February 2020 (UTC)
    WhatamIdoing, NPP folks or AfC? I've seen the behaviour you describe at AfC, and worse, but not by draftifying NPPers. The expectations of New Page Patrollers are that such mistakes should never happen, or very rarely. I don't think there's a problem with having a process that requires that the people doing the processing have extensive policy knowledge. Vexations (talk) 23:43, 17 February 2020 (UTC)
    WhatamIdoing, I think you are referring to AfC reviewers, NPP reviewers would pretty quickly get crucified for this behaviour and is against the process (see the aforementioned NPP flowchart). If you do have such examples, please pass them to me so that I can hand out admonishments. — Insertcleverphrasehere (or here)(click me!) 03:08, 27 February 2020 (UTC)
  • Even though I think the Draft namespace, and the whole system for dealing with new content, is nowadays functioning a bit better than say about two years ago, I still believe it is fundamentally not fit for purpose. A lot of junk is created that can't get immediately cleared out and a fair amount of easily improvable content on notable topics is relegated to silent deletion because it doesn't fit some reviewer's idea of what an exemplary article should be like. I'm beginning to think that the system of the pre-WP:ACTRIAL days was better: any registered user could create an article immediately available in mainspace, the loads of garbage could be quickly whisked away, the content with potential made immediately available for others to further improve, and the borderline cases decided on by the deliberative process. – Uanfala (talk) 23:44, 17 February 2020 (UTC)
  • I agree with others above that the Draft namespace is not working well, and obstructs the proper functioning of the wiki. The original case for draftspace was persuasive and exciting, but it doesn't seem to have worked out very well in practice. It's ended up being less like an incubator and more like Limbo. I keep coming across decent starter articles on encyclopedic topics that were draftified/declined (and often subsequently deleted as "abandoned") because someone found them wanting on seemingly arbitrary grounds. One example that currently sticks in my craw is an article about a prominent African-American newspaper that a novice contributor submitted to AfC; one reviewer correctly identified it as "ready to go" but the article subsequently sat in limbo for four months before someone else decided it wasn't good enough and declined the submission. (I discovered and un-draftified it because I was in the process of creating such an article myself, and it would have been ridiculous and anti-wiki to pass up the opportunity to build on the original contributor's work.) While it may be true that Drafts help to filter out bad articles as well, the absence of one good article does more long-term harm to the project than the presence of a hundred bad ones. When we are treating our most dedicated new contributors this way, it's a wonder we have any contributors at all. I'll humbly submit, however, that at least half of the problem here is that we are currently tricking novice users into submitting through the optional AfC bureaucracy rather than inviting them to participate directly in the wiki as we should. Biting the newcomers is bad, but fencing them out as we currently do is much worse. -- Visviva (talk) 06:46, 18 February 2020 (UTC)
  • Looking into the history, I was a bit surprised to realize that draftspace didn't become a thing until 2013. That forces me to reconsider some of my assumptions about the feature's negative impacts, since Wikipedia's ongoing slump was already well under way by 2013. But the recency of that date also makes it a bit difficult to take any of the above prognostications of doom seriously. It's hard to think of any standard by which the Wikipedia of 2013 was an "unmitigated disaster" but the Wikipedia of 2020 is not. Thus it seems highly unlikely that returning to the draftspace-free status quo ante would have any particularly disastrous effects. -- Visviva (talk) 07:12, 18 February 2020 (UTC)
  • Idea: make draft space only for articles with a plausible COI concern. It's pretty clear that we're not doing new editors any favors by fencing them off from AfD, but we need a way to keep bad faith editors from soaking up our time and effort. signed, Rosguill talk 07:15, 18 February 2020 (UTC)
    Rosguill, So much of the content submitted these days has a plausible COI that this wouldn't really help much unfortunately. and would make false flags even worse; who wants to work at AfC if ALL the articles are COIs? — Insertcleverphrasehere (or here)(click me!) 03:11, 27 February 2020 (UTC)
  • I sadly have to agree, even drafts that have a shot at making it into mainspace often end up subject to G13. However, I think that they could be fixed, possibly using Headbomb's suggestion of making drafts in particular subjects get a tag so that people that may be interested in them actually see them.
    However, I also think there should be a way to get junk cleared out faster, because at the end of the day the majority of drafts that fall to G13 are junk. I patrol recent changes, primarily userspace and draft space, and I believe this to be true based on what i've seen: lots of unrecoverable junk, an occasional good draft that's COI, and very little else. —moonythedwarf (Braden N.) 17:18, 18 February 2020 (UTC)
  • Do we have any metrics for measuring the impact that 7 years of draftspace has had on the wiki? Are there less deletions from mainspace now than before? Fewer AfDs? Less promo? More articles? Better articles? Levivich (lulz) 02:35, 19 February 2020 (UTC)
  • My position to keep aligns closely with IJBall, Rosguill, and Vexations. WhatamIdoing, the actions by the NPPers you described are what needs review rather than the process, although I do understand the process is not perfect. Perhaps the WMF can conduct the necessary research and provide answers to the questions asked by Levivich? Kudpung has been one of the most active in getting NPP the tools needed to do the job, and he may have some insight as to resolving some of the issues we're facing now. Atsme Talk 📧 13:30, 25 February 2020 (UTC)
    • Research was done when the draftspace was fairly new, and the conclusion was that the draftspace is where articles go to die. See m:Research:Wikipedia article creation and m:Research:AfC processes and productivity. It's not primarily about the speed of the initial response. I think it might be more about the parable that User:Iridescent told me a couple of years ago. The incentives are set up so that nobody wants to be the "bad" reviewer that lets an unwanted article into the mainspace, with the result that both bad articles and borderline articles get suppressed, rather than just the bad ones. WhatamIdoing (talk) 17:59, 25 February 2020 (UTC)
      • WhatamIdoing, that research appears to have been rather one sided and mainly the work and opinion of one WMF staff member. Unless I am seriously missing something, it failed to bring into the statistics the numbers of totally justified rejections of articles that are in no way fit or appropriate for an encyclopedia. Please correct me if I am wrong. This reinforces the notion that the the Foundation was interested in one thing only: the total number of creations, irrespective of their quality, and still is. Such research is probably best outsourced to a neutral consulting body, even if it costs some money. I firmly believe that such matters should be devolved to the community itself, leaving the WMF soley as the instiution that manages legal and financial matters on the Community's behalf, under the Community's instructions.Kudpung กุดผึ้ง (talk) 01:11, 27 February 2020 (UTC)
        • Oh, I'm willing to believe that one of the research projects might have some bias involved. After all, the WMF staffer who originally proposed the creation of the Draft: space is listed as one of the contributors. I suppose the fact that the draftspace was created by the WMF and that this research involved its main proponent sort of undercuts your opinion that the research project was probably biased against the draftspace. If we had devolved everything to the community, then we wouldn't be having this discussion, because the draftspace wouldn't exist.
          I also don't see the research claiming that any decision is objectively wrong. It shows that draftspace standards are significantly higher than mainspace standards. It does not judge whether the problem is draftspace being "too high" or mainspace being "too low", or a combination of the two. That judgment, after all, is about people's values, and different people have different values. WhatamIdoing (talk) 17:05, 27 February 2020 (UTC)
  • I can understand TonyBallioni's motivation for starting this discussion, and I'm only here because I was pinged and I think DGG as a major contributor to these elements should be invited to comment.
A lot of things on Wikipedia are a 'broken concept', including AfC, NPP, AfD, and also the way users are encouraged, their behaviour is processed, or their qualities recognised, indeed, the Founder once said that RfA is a horrible and broken process.
The problem is that no one could have known when it was created that Wikipedia would become such a hugely successful and important collection of knowledge despite (or because of) its crowdsourced content. Many editors in that crowd may well be topic specific experts, professionals, or academics, but many are not, especially when it comes to creating new content, but those who patrol the new contributions are not necessarily schooled in real life either for the tasks that lay before them as Wikipedia backroom people. The main issues are that there is 1) a vast disparity in the way NPP and AfC reviewers go about their work and apply Wikipedia rules, regulations, guidelines, and policies, and 2) simply not enough active reviewers available for both systems (and in the absence of metrics, there is the possibility that some of the ~650 NPPers might be (or were) hat collectors, and 3) but perhaps less important, the cultural dichotomies among the different English speaking users who work in maintenance areas.
But this topic is not strictly about NPP/AfC, it's about the draft namespace which is nevertheless a major part of the mechanism fo maintaining the integrity of of the public part of the encyclopedia corpus. I welcomed the advent of the draft and the deprecation of the incubator, and I fought long and hard to bring about ACTRIAL and its permanent adoption and to create what I hoped would be a competent component to review new articles. I still believe that while 'the encyclopedia anyone can edit' is still an important founding principle, it does not exclude the possibility of introducing required controls as the project continues to grow organically - as demonstrated by the very reason why AfC was created in the first place, and the resounding consensus for ACPERM. Personally, I do not believe that ACPERM went far enough (but it was as much as we dared ask the community for at the time), and recent developments, such as the increase in paid editing and possible abuse of the Autopatrolled and NPP flags give me pause.
What we should probably be looking at is not to immediately deprecate the draft namespace, but to take a very long and serious look at the entire system of management of new content and that would begin with a proper system that informs potential new article creators just what they can and cannot create, and I firmly maintain that that is something that should be at least funded by the WMF even if they claim they do not have the developer capacity to do it. Tony's issue(s) therefore only scratches the surface, what is needed now after 18 years is a holistic approach, and less talk from the WMF about their big ideas lined up for the movement in 30 years hence (for one thing, I and possibly a lot of the users won't be around then unless we live to be a 100, and those of us who have been influential in the past may be seeking to reduce their activity as I have done over the past 2 years on NPP but we wouldn't want to think our efforts have been wasted). A good place to start perhaps, is at Wikipedia:The future of NPP and AfC, and extract some stats and metrics and until that is done, per Headbomb, WhatamIdoing/Iridescent, Atsme, Jayron32,  IJBall, Jo-Jo Eumerus, not be too hasty to condemn the draft namespace. Kudpung กุดผึ้ง (talk) 07:56, 26 February 2020 (UTC)
I find myself agreeing with Kudpung. Allowing the GFOO stream to go directly to mainspace would create an unimaginably huge mess, there simply must be a "holding pen" of some sort to enable at least basic triage.
Now hold onto your hats as I'm going to make a radical (and maybe crazy) suggestion... As I see it the problem is not the existence of draftspace, it's the way drafts are created. There are simply not enough competent reviewers to handle the stream of incoming GFOO, which consists overwelmingly of crap with a light sprinkling of legitimate draft articles. The status of new article creation needs to be drastically downgraded, it should be one of the least significant things a Wikipedian does. In fact the vast majority of draft/article creators are not "true Wikipedians" as all they do is drop one article and leave, many have an obvious COI too. They are the least desirable type of contributor (except for vandals of course). If we really want to reduce the draft overload we should find a way to force users to do substantial "gnome edits" before being allowed to create even a draft - autoconfirmed is a ridiculously trivial barrier. If a newbie had to do several hundred edits to existing mainspace articles before being allowed to create any new pages outside of their own userspace we would basically eliminate spammers and SPAs, as only people interested in working on WP for the sake of WP would be willing to do it. Anyone can edit, but only committed Wikipedians should be allowed to create articles. Roger (Dodger67) (talk) 08:36, 27 February 2020 (UTC)
Roger (Dodger67): completely agree with you. At 6M articles, if a newcomer wants to immediately create a new article, that's because it's some kind of their pet project (ranging from innocent article on one's primary school to COI spam). Many prolific users I know (myself included) started off with some type of "gnome edit" -- quick fix a typo or a mistake and then somehow you get hooked. These are the type of editors that we need to recruit -- the one's that care about information, not about their pet project. Renata (talk) 19:35, 27 February 2020 (UTC)
  • While some good comes out of draftspace, I believe it is draftspace is net negative to the project due to the way it burns wide eyed newcomers. A better approach would be to discourage newcomers from writing new pages until after they have found their editing legs by improving existing content. Other standard criticism is: in draftspace, drafters have virtually no contact with the mainspace editing community; & when they do submit, they receive patronising, top-of-draft templated comments, dissimilar to how mainspace works with talk on talk pages. The most valid reasons for draftspace is forcing AfC and draftspace processes on COI editors, and proponents of AfD-deleted pages who thing they can improve them, however, for both cases userspace could be used. --SmokeyJoe (talk) 13:47, 26 February 2020 (UTC)
  • Well, Draftspace is a problem because it does what it sets out to do very badly (help new editors). It delays good faith editors with months of waiting before inevitably getting a 'not ready' negative review (they are after all, new editors that don't know how to write articles). It is also used as a holding pen for COI editors' creations, but even for that it doesn't work well! Because those COI editors can just re-create the same article in mainspace again, and the New Page Patroller then has to pursue other means anyway (AfD, PROD, CSD). I think the draft space being a failure is simply a result of the fundamental problem with all the new page processes on wikipedia. We don't have enough reviewers, and we never will. The result of this short-handedness is that we do triage instead of holistic care. This is a necessity, but it results in fundamentally broken processes if you don't accept the fact of it on its face. New Page Patrol KNOWS that it is triage, and it bills itself as such. It doesn't pretend to be a welcoming place, it doesn't pretend to be a bunch of people that are there to help the newbies to write new articles. No, we sort the wheat from the chaff and we move on. AfC and the draftspace are fundamentally broken because they WANT to be something that they CANT be, because they simply don't have the manpower; and they never will. The result is something that ends up as a wild west; with some reviewers trying to help, and others just trying to keep AfC's head above water by pressing yes/no as quickly as possible (and even then the wait times are INSANE). The result is that as someone that submits to AfC, you are guaranteed to have a bad time; first you will wait for months, then, you'll get a decline and some semi-helpful tips (if you are lucky). The reviewers don't have time to help you write your articles, but that's what would be required in a lot of cases simply because not all new editors are capable of the competence required to write new articles on Wikipedia. Should Draft space be gotten rid of? YES. It is a drain on already strained reviewing manpower, and we simply won't ever have the manpower to make it work as intended. — Insertcleverphrasehere (or here)(click me!) 03:36, 27 February 2020 (UTC)
    • Insertcleverphrasehere I agree entirely with every you said here - except the last two sentences. What do you do if you got rid of it? AfC as a project would disappear into the horizon on a hot day, leaving simply thousands of NPP permatagged articles that people are not going to pick up and improve. As you most correctly and emphatically spelled out, NPR is triage, the New Page Patrollers aren't going to do more than they do and they're not expected to - the backlog is already ridiculously long again. Kudpung กุดผึ้ง (talk) 08:58, 27 February 2020 (UTC)
      • I don't think that everyone agrees with you that having "thousands of NPP permatagged articles that people are not going to pick up and improve" is a big problem. Editors have quite a diversity of views on this subject, and the folks at NPP and AFC do not seem to be representative of the whole community's views. WhatamIdoing (talk) 17:15, 27 February 2020 (UTC)
      Kudpung, What WhatamIdoing said. I don't find this a significant issue. If the topic is notable, but it's content is problematic, then it can be stubified with a couple sources and tagged for improvement. I think this is highly preferable to the current "move it to draft so that nobody sees how horrible it looks" (or keep it in draft). This is often even done when all that is needed are formatting fixes, and then the drafts end up deleted G13. If draft space didn't exist then stubifying articlles that need notability guidelines but fail content guidelines would become the new gold standard. Paid and COI editing would still be a problem, but as I said above, the draft space isn't really a solution to that anyway. — Insertcleverphrasehere (or here)(click me!) 18:04, 27 February 2020 (UTC)
  • One thing I have noticed in draft space is that users will spend considerable amounts of time creating very long articles that they think are masterpieces, but which will likely never be published for any number of reasons. It strikes me that limiting the size of drafts for new users might go some ways towards reducing disappointment, and letting us catch poor efforts before they go on for too long. Conversely, any page reviewer can tell when a short draft that is well sourced is notable enough, and can promote it to main space. I'm not sure how it would work, but something like "You can create a draft up to 5K in size using the best sourcing you can find" might be helpful. This is a clunky idea as I have described it, but the gist of it is to avoid huge long spam articles.ThatMontrealIP (talk) 16:40, 27 February 2020 (UTC)
  • Removing draft space would flood mainspace with the worst articles particularly attack pages, copyvios and spam which would stay for longer due to the NPP backlog which would be signifiantly increased by this proposal. There are a number of editors who do improve and publish drafts including abandoned drafts and the AFC process can work to significantly improve articles for mainspace that if posted there would be quickly deleted in their original condition, imv Atlantic306 (talk) 19:51, 27 February 2020 (UTC)
  • It's no secret that I think the current deployment of draft space – with overwhelmed & overpicky Articles for Creation reviewers, one-click draftify to "incubate" (the most ironic automated edit summary in the 'pedia) and semi-automated G13 deletion – is one of the most negative changes ever made to Wikipedia. I tend to advise good-faith newbies to accumulate enough edits to create articles directly in mainspace because they get far more attention there -- sometimes a swift death, but not the inexorable slide to deletion of G13. There is a place for drafting articles collaboratively, it's called mainspace. Espresso Addict (talk) 06:17, 7 March 2020 (UTC)
  • It is well known (m:Research:Wikipedia article creation) that restrictions to article creation reduce the quality of the articles being created, probably because bad faith users invest disproportionate efforts to get their edits through, while good faith users just give up. Wikipedia works thanks to cooperation and that happens mostly in mainspace. The entire namespace should be deleted and people directed to create their articles in main namespace. In the interim, past drafts can be moved by a bot to a subpage of the creator's userpage. To improve the average quality of articles created in main namespace, the requirements to create an article should then be restored to be the same as for any other edit. Nemo 06:23, 15 April 2020 (UTC)

An example

Yesterday I came across the newly created article Bob Chapek, with a very strong indication of importance and a reliable but not independent source. Nine minutes after creation it was moved to Draft:Bob Chapek by a new-page patroller following the instructions. From the histories and talk pages of those two pages you can see what a mess this has produced, with people misunderstanding speedy deletion templates and developing them in parallel. If the original article had simply been left alone to be developed in mainspace the normal wiki process would have been followed and people wouldn't have to waste their time trying to deal with the situation. Phil Bridger (talk) 12:35, 26 February 2020 (UTC)

The backlog at NPP is unacceptable. Not the monumental 22,00o it was 3 years ago, but constantly hovering around five to eight thousand makes it still totally unacceptable. If every active New Page Reviewer stopped to do a full service to every page in the queue that backlog would be immense. This therefore does not, IMO, exemplify any typical issues with the draft namespace system. I don't think Willbb234 did anything unusual in moving the IP's creation to draft - it was pretty much what any current active New Page Reviewer , including me, would probably do with such a page particularly as it was a BLP. In fact there followed a flurry of activity which resulted in a mainspace ready article very quickly, one way or another, so under the current processes available no one really wasted their time dealing with it. AFAICS, the draftification process did its job. Arjunpat, an autoconfirmed user (with albeit a low edit count ) created an appropriate article in good faith, was not really doing anything wrong but was almost certainly not aware that they may have been doing something that was nevertheless not quite right., i.e. creating a page in mainspace that was not ready for it; they were most likely not aware of other options such as creating it offline first, or in their user space, or as recommended, in draft space.
If every user who registers an account was informed immediately of what they can and can't do on Wikipedia, then a 'mess' would not be produced, articles would not be produced that would cause a mess, and time and energy would be saved all round - ball back in the WMF court. Nobody is being criticised here, but perhaps as a pure exercise in interest, after reading the main thread here, the contributing editors and BigRed606, Spshu, might like to chime in here with their thoughts. Kudpung กุดผึ้ง (talk) 00:57, 27 February 2020 (UTC)
Probably time for a backlog drive. And also tag them with WikiProject banners so they show up in WP:AALERTS. Headbomb {t · c · p · b} 01:17, 27 February 2020 (UTC)
Headbomb, Yeah, When we lost Onel a month or so back, things have started spiraling downhill. We are still treading water, but only just. I'm working on a methodology for inviting new people to join NPP, but running a drive might also be due. Really busy at work at the moment personally, so mostly just been dropping an average of a few reviews a day myself, as I don't really have the time for more. — Insertcleverphrasehere (or here)(click me!) 03:43, 27 February 2020 (UTC)
If you look at the history and the talk page of the mainspace redirect that was left behind by this move, and was later moved to Draft:Move Bob Chapek (admins only by now), you will see that this move to draft did cause considerable confusion and meant that experienced editors who understood what was happening had to spend time putting things right. We had editors adding content to the redirect, claiming that they had "fixed" things, and contesting speedy deletion. I purposely didn't name the editor who performed this move to draft because, as you say, most new page patrollers would have done the same. Phil Bridger (talk) 09:38, 27 February 2020 (UTC)
Perhaps the main problem is that different editors have different ideas about what constitutes "a mainspace ready article", especially as measured nine minutes after creation. WhatamIdoing (talk) 16:49, 27 February 2020 (UTC)

Here's one: AQUILA HOTELS & RESORTS. I found it at main space. The creator has a COI, but is probably good faith (but biased in a way that limits thier ability to write an article. The topic looks notable, but as written it is just jammed with promotionalism and way too many refs. It looks notable, but it's a company and its going to take an hour to strip out all the garbage refs from this article down to what is salvageable and fix all the formatting errors. No one wants to waste the time, so it ends up in draft space. Where it will likely die unless somebody takes pity on it. I posted on coin but I doubt anything would happen. Would it get CSDed if we didn't have draft space? I don't think so (it isn't exclusively promotional). Would it get AfDed? No, AfD isn't cleanup, and the topic does look notable. Our only option would be to stubify it and nuke most of the bad content. This would be preferable to it just getting shunted to draft space. — Insertcleverphrasehere (or here)(click me!) 04:02, 27 February 2020 (UTC)

Aaaaaaand, its gone. — Insertcleverphrasehere (or here)(click me!) 18:07, 27 February 2020 (UTC

Another example

Today I got a notice that a draft I created, Draft:Sandra Pinel was up for G13 deletion, and indeed was both notified on my talk and deleted while I was in the middle of leaving a lengthy message elsewhere. I don't believe I would have spontaneously had an idea to create this article, so I must have responded to a noticeboard thread or something to create it in draft, but I'm blowed if I can remember what. I've restored it (as policy states any user can get a G13 refunded on request I don't consider myself WP:INVOLVED to just do it myself), but most people won't even think of doing this, and if I don't get any ideas or assistance, it'll get deleted again, a year after creation. Update: I've worked out it's because I was patrolling CAT:CSD on 12 July 2019 and saw Sandra Pinel tagged for A7, searched for sources as a triage and moved it to draft with the idea of blowing it up and starting over. Obviously I didn't get very far! In the meantime the article was re-created in mainspace by the original creator, tagged for G11, AfDed at Wikipedia:Articles for deletion/Sandra Pinel and deleted, and the creator indefinitely blocked. GAME OVER.

A long time ago, I wrote on Wikipedia:WikiSpeak that Articles for Creation was "A place where articles don't get created, but sit languishing in purgatory". There is good stuff in draftspace to pull out, but it's like looking for a needle in a haystack. Essentially, we have the following conflicting requirements:

  • Creating articles is hard. Reviewing them properly is harder
  • As a corollary to the above, we don't have enough reviewers to cope with incoming work, and never will
  • Because experienced and knowledgeable reviewers are more likely to pause and pass on difficult or contentious new pages, new pages (both in mainspace and draft) are more likely to be dealt by less conscientious reviewers who will not do this
  • As a corollary to the above, all things being equal, a new page is more likely to dealt with by a "cookie cutter" message rather than anything with thought and knowledge, putting off genuine newcomers
  • Spammers looking to create COI topics should not be allowed to start articles AT ALL

Is it even possible to come up with a solution that handles the above? I'm not sure. Ritchie333 (talk) (cont) 18:20, 27 February 2020 (UTC)

Ritchie333, I think there are some ways to handle at least most of the above, but it means making Wikipedia less useful to readers. For example, a rule that says "No new articles about living people, businesses, or products (including pop culture products such as books, films, websites, etc.) less than 50 years old" would knock out a lot of COI and spam pages. But the cost, measured in terms of harm to the reason we're here, would be significant. I don't think the community would agree to that. WhatamIdoing (talk) 23:13, 27 February 2020 (UTC)

Yet another example

The article Narayanrao Uttamrao Deshmukh had a cast-iron source that confirmed that it passed WP:POLITICIAN, but was moved to draft and then rejected twice at AfC. We seem to be giving new page patrollers and AfC reviewers, who have not been given deletion powers via WP:RFA, the power to remove things from main space. This is very clearly a use of draft space as a backdoor route to deletion, as it is not supposed to be. Phil Bridger (talk) 20:23, 6 March 2020 (UTC)

This is not the best example: IMHO the AFC reviewers both acted properly. During the first review, the page was totally unsourced. During the 2nd review, the source was a dead link. Neither reviewer would have any evidence that the claims in the article were true unless they took the time to research the subject themselves. Their only choices were to not review, to decline and give the submitter useful feedback, or to halt their AFC reviews and start editing the page as if they were an editor rather than a reviewer. Another editor moved the page to the main encyclopedia. I found a suitable replacement source and removed the top-of-page sources-needed template. There is still some unsourced material but it's no longer a major BLP issue. davidwr/(talk)/(contribs) 22:30, 6 March 2020 (UTC)
The AfC people might've done the right thing, but these unilateral and process-free moves to draft space to circumvent deletion processes need to be reined the hell in already. The Drover's Wife (talk) 22:44, 6 March 2020 (UTC)
(after edit conflict) Sorry, but that's far from an acceptable answer. Sources do not have to be online, but, in this case, I can certainly read the original source online without the archive link. Phil Bridger (talk) 22:47, 6 March 2020 (UTC)
https://www.dnaindia.com/india/report-maharashtra-assembly-election-results-1967-full-list-of-winners-2798429 (the original source) works for me, too. WhatamIdoing (talk) 16:33, 12 March 2020 (UTC)

A counter-example

I have over 1,400 draft pages underway for U.S. state supreme court justices. Every few days, I pick one out and finish it. Sometimes I find a source covering several and make improvements across the covered group. Every few weeks, someone else comes along and finishes a draft or two, usually in connection with a specific state. In this way, over 600 articles have been created and moved to mainspace from this list (which initially had over 2,000 entries). This, I think, is an example of draftspace working as it should - with drafts for specific topics connected to specific projects, from which appropriate attention can be drawn. Perhaps what is needed is a better way to connect drafts with the projects that should be concerned about them. BD2412 T 03:37, 27 February 2020 (UTC)

The same tools that help improve articles could be used to help improve drafts. Would something similar to Random article but for drafts help? El Millo (talk) 03:59, 27 February 2020 (UTC)
I think order would present a better tool than randomness, in this space. BD2412 T 04:15, 27 February 2020 (UTC)
@BD2412: Order? Do you mean order from less to more complete? El Millo (talk) 04:47, 27 February 2020 (UTC)
I mean as in tying drafts to projects and to potentially interested editors. Every draft has some family of articles or topics that are the closest things to it, and a good step would be to bring the attention of contributors to those related topics to those drafts. One way might be to find some way to notify editors (or projects) when a link is made from a draft to a particular mainspace article. BD2412 T 05:00, 27 February 2020 (UTC)
Why not do both? PJvanMill (talk) 21:44, 29 February 2020 (UTC)
I just discovered, by reading more discussion below, that this already exists: Special:Random/Draft. PJvanMill (talk) 21:59, 29 February 2020 (UTC)
It might be possible to get Wikipedia:List of Wikipedians by article count run for the current contents of the draftspace. (I don't think it could tell you which pages began in the draftspace.) WhatamIdoing (talk) 16:46, 12 March 2020 (UTC)
It could also be useful to have them automatically transcluded at the top of relevant wikiproject talkpages (similar to tracking pages like Wikipedia:WikiProject_Genetics/Article alerts). Over at WP:Molbio we typically rely on people from AfC and NPP manually dropping my to let us know there's a relevant draft in need of attention. T.Shafee(Evo&Evo)talk 09:23, 31 March 2020 (UTC)
This is one of the neatest uses for draft space I've seen. // Lollipoplollipoplollipop :: talk 16:03, 20 April 2020 (UTC)

Arbitrary break after the examples

  • Having higher standards to move something out of draftspace than to delete it at AfD has been the case for so long that it seems normal to us, but to everyone else it's crazy. I'd love to know what percentage of Declined drafts end up being deleted (Whatamidoing (WMF), do you know if this data exists?) as opposed to being improved to the point of acceptance. If we do keep draftspace, search capabilities should be improved so that people from the Wikiprojects can search for keywords among drafts that have reached at least the "Submitted" stage, and assess articles themselves. Wikiproject participants would likely still have higher standards to "accept" than to "not delete" - I believe that's unfotunately human nature - but at least the reviewing would be done by people who are interested in the topic area.
With ad-hoc and infrequent perusing of draft space, I've found and rescued some wonderful articles that were declined, including Marine heatwave. The way we use draftspace might be the biggest biter of newbies we've ever created. Clayoquot (talk | contribs) 19:03, 27 February 2020 (UTC)
I agree that it's a big biter of newbies, not least because we tell people that it's best to create articles in draft space but they then take months to get reviewed and then, when they do, the reviewer quite often has less of an idea about what belongs in an encyclopedia than the article creator. Also if usage of moving to draft space by new page patrollers remains as it is then we should abandon the pretence that moving to draft is not a backdoor route to deletion. It is very clearly used in that way. Phil Bridger (talk) 19:26, 27 February 2020 (UTC)
Clayoquot, I don't know the percentage of deletions. The last research I saw on this was shortly after the creation of WP:G13, which really changed the numbers. WhatamIdoing (talk) 23:40, 27 February 2020 (UTC)
  • The problems of Draft space are inseparable form COI spam problems. Until we find a way to fix COI, Draft will remain broken. Renata (talk) 19:38, 27 February 2020 (UTC)
    • That reminds me of another question I have for Whatamidoing (WMF) ;) : What percentage of articles in Draft space are about people, organizations, or products, vs. everything else (this presumably can't be detected programmatically but maybe someone could do it by sampling)? Articles such as Webbed foot and Psychology of climate change denial seem to me to be obviously unrelated to our COI spam problem. Both of these were created at AfC by newbies who probably thought it was the only way to create an article, and Declined at AfC. Clayoquot (talk | contribs) 19:55, 27 February 2020 (UTC)
      • mw:ORES/Draft topic could answer your question, but I don't think it's actually been implemented. In lieu of real answers, I clicked Special:Random/Draft ten times. I found three drafts about living people, one had no article (the title was mathematics-related), one was a (worse) article on a subject that's had an article for years and years, one is a geographical place (the contents were only an infobox), two were for pop culture (more or less comic books), one was a building, and one was about computer science. One of the goals for ORES is to be able to tell us (i.e., WP:MED) when medicine-related articles are in the draftspace. Right now, editors leave notes at WT:MED when they find something to look at. (Forgive me for not bothering to clock in to reply to your interesting questions. Right now, I'm sitting outside and looking at blue skies and wispy clouds, and thinking that all I really need is a bowl of good strawberries and a power cord.) WhatamIdoing (talk) 23:40, 27 February 2020 (UTC)
      • Clayoquot: I did a quick sample of 50 drafts (selected via Special:Random/Draft so only 2 of them are not pending a review). Obviously, did not dig into notability and judged it at first glance. Details here.
13 pure garbage CSD
1 draft working on improving mainspace article (Draft:Michigan–Penn State Football Rivalry)
4 drafts from the project about US judges by BD2412
4 clearly notable topics (but will probably die in Draft)
5 clearly not notable topics
23 (effectively 50% of sample) in the notability grey zone -- which is the labor-intensive & frustrating zone of promo, COI, etc., of these:
2 are pending review
6 are rejected drafts
8 have neither references nor proper format
3 imho ready for mainspace
2 imho are borderline
2 imho are not ready for mainspace Renata (talk) 00:34, 28 February 2020 (UTC)
  • Personally, I'll only !vote for the deletion of draftspace if one of the following are done:
  1. An alternative is created to decrease the chances of a new user having to experience an article deletion. Also, disclosing any conflicts of interest are made easier.
  2. Research is done that indicates that blocking for undisclosed paid editing/using an account only to advertise or article deletion wasn't diminished after ACPERM.
If the only thing draftspace is doing is keeping junk out of mainspace, it's doing enough good that it needs to be kept around so we can discuss how it can do better. Frankly, I'd be less enthused to NPP again without a draftspace. It's not out of the purview of new editors to become upset when the article they created is nominated for deletion; I've even received a lawsuit threat or two. They aren't quite as upset when I decline their draft. Whenever I get a message about a decline, even if there is an underlying upset, there is also curiosity on how to do better. You don't get that with a deletion nomination. Therefore, having a draftspace is less bite-y than not having one. I dream of horses (talk) (contribs) Remember to {{ping}} me after replying off my talk page 21:49, 27 February 2020 (UTC)
The options aren't "draftspace or nothing". For example, we used to move pages to userspace. WhatamIdoing (talk) 23:40, 27 February 2020 (UTC)
WhatamIdoing, which posed the issue that G13 was created to fix; userspace drafts would sometimes languish in userspace, untouched for years, completely and totally forgotten. Nowadays we'd probably G13 old userspace drafts, but userfying articles would still cause a lot of the problems draftspace has, but without the little formality draftspace has. I dream of horses (talk) (contribs) Remember to {{ping}} me after replying off my talk page 19:45, 28 February 2020 (UTC)
I agree that there is no system that forces any WP:VOLUNTEER to finish articles that someone else started. The #Is it acceptable to blank userspace sandboxes of long-term/established, but inactive editors? discussion above suggests to me that not everyone thinks that it's actually a problem to have drafts "languish[ing] in userspace, untouched for years, completely and totally forgotten". WhatamIdoing (talk) 20:47, 28 February 2020 (UTC)
I would like to register my objection to moving either my WP:USCJ drafts or my WP:DABCONCEPT drafts to userspace. They do get worked on in draftspace by various editors from time to time, and it is my experience that having them in userspace would discourage those kinds of improvements. Also, @Renata3: what was the condition of the judge drafts that you saw in your review? BD2412 T 22:11, 28 February 2020 (UTC)
BD2412, If one of those Drafts was about to be deleted under G13, would you appreciate having the option to userfy it? Blueboar (talk) 23:50, 28 February 2020 (UTC)

WhatamIdoing, nowadays people can, if an editor is inactive (as in "hasn't edited for years") and has userfied drafts that have languished for years without being touched, have those drafts moved to draftspace. Also, BD2412 has an interesting objection; I have seen draftspace drafts gnomed quite frequently, but I doubt userspace drafts get that.

Since userfying articles is what we did before draftspace, and you've yet to offer any other option despite having a lot of time, I'm unconvinced that it's not "draftspace or nothing". Going back to the way things were before draftspace is "nothing", in my mind. If draftspace is unacceptable, we need to come up with an alternative to both that and userfying articles.

Blueboar, not speaking for BD2412, but there is a template one can use for drafts that are technically G13able but "have potential". I think that's the sort of draft he is working on. I dream of horses (talk) (contribs) Remember to {{ping}} me after replying off my talk page 13:59, 29 February 2020 (UTC)

Yes, a draft in Userspace CAN be moved to Draftspace... However, nothing requires drafts in Userspace to be moved. It is OK to leave material in Userspace, indefinitely. Also, I see no reason why we shouldn’t be able to go in the other direction as well, and move a draft from Draftspace over to Userspace.
The two spaces have different purposes, and so have different rules that govern them, but BOTH can be used to work on potential articles. The primary difference is that one (Draftspace) is for communal work, while the other (Userspace) is more for solo work. The point is... we have options. Blueboar (talk) 14:58, 29 February 2020 (UTC)
Obviously this is not an option of everyone, but if one of my drafts gets deleted pursuant to G13, I undelete it. BD2412 T 15:29, 29 February 2020 (UTC)
There are the different namespaces as we're using them today (mainspace, draftspace, userspace), but we could be using other approaches entirely. We might be able to hide them with Wikipedia:Pending changes. We might be able to put them in projectspace as subpages for a relevant (and active) WikiProject (if any). We could put them in draftspace, but make them easier for everyone to find (e.g., searching draftspace by default).
We could also change the incentives. Pages in draftspace are supposed to be proto-articles that would not survive WP:AFD. The NPPers have made a big deal here about saying that they follow AFD's WP:BEFORE process before moving a page to the draftspace, and then they turned around and defended their move of a minutes-old stub about the new CEO of Disney to draftspace, even though there is approximately a snowball's chance in Hell of that article ever being deleted at AFD. So maybe a random sample of AFC-declined/NPP-draftified articles should be sent to AFD, and if we find that any individual editor is using draftspace to store pages that have a high likelihood of surviving AFD (as evidenced by them actually surviving AFD), then maybe that editor is told to mend his ways or get banned from that process.
I am not particularly recommending any of these options. My point is only that there are a lot of options, once you start thinking about what we need to do instead of focusing on which namespace the page should be in. WhatamIdoing (talk) 03:39, 2 March 2020 (UTC)

I agree there are lots of options. One thing that could change the incentives would be to require admin rights to move a page from mainspace to draft space or to userspace, so it would be subject to scrutiny and like other admin actions. We could use a noticeboard or category to process cases in which, say, the creator of an article published it accidentally and wants to keep working on it privately. In most cases, draftifying an article is functionally equivalent to deleting it, but with a lot less accountability. Clayoquot (talk | contribs) 22:05, 3 March 2020 (UTC)

Getting rid of the draftspace means that we would lose out on useful incubtion for articles before they make it into the mainspace. I don't see how dleting this step willl reduce the amount of 'bad' articles. >>BEANS X2t 14:41, 7 March 2020 (UTC)

Comments from a Reviewer

I will respond to the comments of User:TonyBallioni about draft space being a failure. I am one of the more active AFC reviewers of drafts, and I think that I am qualified to comment on drafts in general. I mostly agree that draft space has not resulted in the benefits that some editors thought would come from it. If it is judged based on some of the optimistic thoughts that it would result in new collaboration, or in improvements in the quality of new articles, I agree that it has not succeeded. I think that any such expectations were unrealistic. The real question however should be whether it should be abandoned as a failure, replaced with something else, or retained for lack of a viable alternative. If draft space is abandoned as a failure, then the question must further be asked what is to be done with the documents that currently go into draft space. So what currently goes into draft space?

The documents in draft space are primarily: (1) proposed articles created by very new users, not yet autoconfirmed, who are not allowed to create new articles; (2) proposed articles created by other users who choose to use draft space, rather than using user space or putting the articles directly into article space; (3) proposed articles originally in user space that have been submitted for review, and are moved by AFC reviewers into draft space; (4) articles that are undersourced or have notability issues that have been draftified by New Page reviewers. If draft space is to be abandoned as a failure, we should consider what to do with those four current uses of draft space. The first use of draft space is by very new users. Are we proposing to reverse the requirement of auto-confirmation for new articles? I hope not. So are we proposing that they be submitted for review in their user space? Does that have any material benefit? The second use of draft space is by some content creators who go through the review process. It is true that they could skip the review process, or rely on WikiProjects for review. Dissolving draft space would be neither harmful nor useful for them. The third use of draft space is for AFC reviewers to move drafts into draft space from user space. Presumably reviewers would simply no longer do that, and would instead review drafts in user space. Nothing would really be gained by dissolving draft space. The fourth use of draft space is for moving articles into, as a side-door quasi-deletion. Eliminating draft space would presumably mean that these articles would instead be proposed for deletion or nominated for deletion. I would not mind seeing more questionable articles nominated for deletion, but I think that most editors would prefer not to increase the number of deletion debates. So, based on listing the uses of draft space, I fail to see any benefit to eliminating draft space.

As a reviewer, I think that drafts fall into four quality classes: (1) good; (2) possible; (3) not ready; (4) no good. The first should normally be accepted, although there may be an issue to be resolved or a question to be answered first. The second require a careful review by a reviewer who is patient and willing to spend the time on the review. The third are declined, and the reviewer does not need to worry much about whether it may be resubmitted later. The choices of the reviewer for the fourth class of drafts are to decline the draft (not worrying much about whether it may be resubmitted), to reject the draft, or to tag the draft for speedy deletion, sometimes as G11, G3, or G10. If draft space were to be dissolved, it is the second and third classes that would need to go somewhere other than draft space. The first will go into article space, and it doesn't matter what bit bucket to put the fourth in.

My conclusion is that draft space has indeed been a failure if we expected it to result in improved collaboration. Collaboration is done in article space. However, I haven't seen an alternative that would be any better than draft space. Robert McClenon (talk) 02:11, 1 March 2020 (UTC)

Robert McClenon, add me as someone who does not want more deletion nominations. It causes quite a bit of upset when that happens, particularly with newer editors. With a draft rejection, there's often still upset, but I think there's also often more understanding of why it happened.
And yeah, I agree with your last sentence. If we get rid of draftspace, we need to replace it with something else. To add to that point, at least we know what to expect from draftspace now. Better the devil you know than the devil you don't know. I dream of horses (talk) (contribs) Remember to {{ping}} me after replying off my talk page 02:46, 1 March 2020 (UTC)
I came back to indent my comment, which I forgot to do the first time, and to also ping TonyBallioni for Robert. I dream of horses (talk) (contribs) Remember to {{ping}} me after replying off my talk page 02:48, 1 March 2020 (UTC)
@Robert McClenon: I would slightly disagree with certain phrasing above. I create articles in draft space with no intention of going through the review process, but merely to have a place to assemble them that is not user space, so that other editors feel comfortable working on them. In many cases, these drafts are made in groups and start out as a collection of scraps and notes that are in no way suitable for introduction to article space, but which show promise for future development into an article. BD2412 T 00:57, 8 March 2020 (UTC)
User:BD2412 - Okay. That is still within my second category of draft space, but the explanation of why is different. You are creating the draft in draft space for possible collaboration prior to moving it into article space. If draft space were dissolved, you would presumably use user space. I don't think that changes the conclusion. Robert McClenon (talk) 03:47, 8 March 2020 (UTC)
@BD2412: That kind of collaboration could potentially be done in the project space of a relevant wikiproject. Espresso Addict (talk) 04:40, 8 March 2020 (UTC)
It could, yes. I suppose issues would arise as to which project space to use for subjects falling under multiple topic headings, but that is a minor concern. Draft space offers the utility of making it clear that the content being worked on there is nothing else but a draft. Unless and until we have a specific "Wikiproject:" namespace, all of these pages would be in project space, along with message boards and policy pages and the like. BD2412 T 04:54, 8 March 2020 (UTC)
BD2412, I think you are the first experienced editor I've met to use draftspace in the way it was originally sold to the community – ie for collaborative editing with other experienced editors – rather than an alternative to userspace for personal article development (rather less useful with the G13 clock ticking) or a place to hand-hold new editors through their early articles. I'd be interested in whether this is actually more common than I'd thought. Espresso Addict (talk) 05:17, 8 March 2020 (UTC)
I can't say that I know of any other experienced editors who use it this way - certainly not to the same scale. BD2412 T 05:24, 8 March 2020 (UTC)
Maybe this is the wrong place for this comment. But I don't know where else to put it.
I think it would be sad to lose draft space. Draft space is where I do most to cooperate with other editors. Usually this happens when a new editor is trying to create an article about a topic I believe is notable, but needs the help of a more experienced editor. Sometimes they've created the article in draft space, sometimes it's in their userspace and I persuade them to move it to draft space. Then we can cooperate, with them providing knowledge of the subject and sources, and me doing the formatting and explaining WP policies. Disabling this opportunity for cooperation would be a loss. Maproom (talk) 11:02, 1 April 2020 (UTC)
Maproom, if you're going to editors and persuading them to WP:MOVE the page to draftspace so you can help, why can't you just ask "Mind if I help with the article in your sandbox?", and skip the whole step about moving the page? WhatamIdoing (talk) 02:44, 17 April 2020 (UTC)
Some reasons:
  • If it's in draft space, it can get some attention from other helpful editors.
  • My memory is not perfect. I don't want to have to maintain a list of which private sandboxes I've been granted access to.
  • I think it's useful to maintain a distinction between private sandboxes, where the owner can do pretty much what they like without interference, and public drafts, where everyone is cooperating in moving towards an acceptable article. I want new editors to understand this distinction.
I think it would be a pity to lose the distinction. Many of the arguments against sandboxes on this page are, essentially, "lots of drafts are full of crap, let's just get rid of them all". Editors here are confusing container and content. Maproom (talk) 07:14, 17 April 2020 (UTC)

Ten random declined drafts

I clicked Special:Random/Draft until I found ten drafts that had been Declined (I clicked through about as many drafts that had not been submitted). I'm posting them here so we can have some data to collectively analyze questions such as "To what extent are the drafts that we decline at AfC acceptable to the community by the standards of AfD?", "How often are articles improved after they are declined?" and perhaps other questions too.

  1. Draft:Cherokee Files (series of classified correspondences between various representatives of the United States Government and the Republic of Korea)
  2. Draft:Vision Bus (company)
  3. Draft:Florida Crime and Intelligence Analyst Association (organization)
  4. Draft:DMCA Sans Serif (free font)
  5. Draft:Sartaj Singh Pannu (filmmaker)
  6. Draft:Gallery A (art gallery)
  7. Draft:Veidehi Gite (entrepreneur and "influencer")
  8. Draft:Stevie Tennet (musician)
  9. Draft:Subjectivity (journal) (academic journal)
  10. Draft:Sickle Cell Disease in the Caribbean (medical issue)

Clayoquot (talk | contribs) 17:21, 2 March 2020 (UTC)

Here's my analysis: 1) Cherokee files should have been accepted. AfC is not for stylistic concerns, it should only be concerned with "Would this survive the AFD". There's no reason to think this article would have been deleted from the main space. There's some MOS issues, and a few very minor tone issues, but that's a decent start to an article that normal editing should fix. 2) Vision Bus: Borderline notability, probably a good decline. 3) Florida Crime and Intelligence Analyst Association: Not clearly notable, no independent sources. Good decline. 4) Good decline, maybe suited for a redirect. No independent sourcing. 5) Sartaj Singh Pannu: Borderline; I would have probably leaned accept given the sourcing already in the article, but its a close one, and I won't begrudge a decline here. He's clearly a director of notable films, and as such there is likely to be good information out there on his bio, even if it isn't already cited. 6) Gallery A: Should have been accepted. Article directly cites one source, but the "Further reading" section indicates there's PLENTY of information available. There's clearly enough there to have avoided AFD if the article had gone that route. 7) Veidehi Gite: Probably a good decline, but there's not nothing there. I think I agree with the reviewer, but I also would not have tried to delete it if I ran across it in the wild. Hard call for me. 8) Stevie Tennet looks like it could have been accepted. The sourcing looks to pass WP:GNG to me. 9) Subjectivity (journal) is a good decline. Borderline A7 even. 10) Sickle Cell Disease in the Caribbean: Probably a good decline, though the information is good this is essentially a fork from other articles on Sickle Cell disease, and most of the novel information could be added to existing articles at Wikipedia without overwhelming them. My final count: 3 bad declines, 5 good declines, 2 borderline cases. --Jayron32 17:47, 2 March 2020 (UTC)
I'm working on Draft:Gallery A, so it has changed significantly since being mentioned above.ThatMontrealIP (talk) 20:03, 4 March 2020 (UTC)
Draft:Cherokee Files is entirely referenced by primary documents on a random person's website (which I'm not clicking through to--but all evidence suggests they're primary). The draft looks like one person is really interested in this bit of classified history and is summarizing the content of primary sources themselves. I see some brief mentions of this topic within Google Books ("Cherokee, Cyrus Vance") but nothing to hang an article on. There could be historians that discuss this enough to justify an article, but the Draft writer didn't show that. Outriggr (talk) 08:16, 5 March 2020 (UTC)

The real problem is biographies and lack of classification

If those could be sidelined into a different 'processing' workflow, it would free up pretty much everything else which have a much better chance of being worthwhile. Biographies created through AFC/Draftspace are by far and large WP:COI/WP:AUTOBIO stuff. If for instance, the drafter was asked in the WP:WIZARD what topics, broadly speaking, the article was about, it would also allowed WikiProjects to be notified of new drafts in their scope. Headbomb {t · c · p · b} 05:25, 8 March 2020 (UTC)

I've proposed this before. It would be ideal if submitters could be persuaded to do some of the sorting work via a suitable wizard, and it could also be used to give them tailored advice and links to specific notability guidelines. Espresso Addict (talk) 05:35, 8 March 2020 (UTC)
The main issue is that someone needs to code this into wizard and update the relevant scripts. Headbomb {t · c · p · b} 06:34, 8 March 2020 (UTC)
I love all of the above ideas. The articles I most hate to lose are the ones that take a lot of time and subject matter expertise to write. Clayoquot (talk | contribs) 16:13, 8 March 2020 (UTC)
I've added an "Improving your odds of a speedy review" section to {{AFC submission}}, which should hopefully help. See discussion. Headbomb {t · c · p · b} 08:44, 12 March 2020 (UTC)
User:EpochFail, is there any chance of mw:ORES/Draft topic being able to do this soon-ish? WhatamIdoing (talk) 16:48, 12 March 2020 (UTC)
Yes! The topic model is ready and can be applied to any article or draft on Wikipedia. What we're missing is some useful integrations between the models that make the predictions and tools for Wikipedia editors. Let me give an example. Let's look at the first version of the article for Alan Turing -- this roughly represents a draft. rev_id:234785. We can ask ORES what the general topics are using a query: https://ores.wikimedia.org/v3/scores/enwiki/234785/drafttopic ORES tells us that this draft article is probably relevant to: "Culture.Biography.Biography*", "STEM.Computing", "STEM.Mathematics", "STEM.STEM*". These can be used to route reviews of article drafts by subject expertise/interest/notability guidelines. Right now, we're working on some integrations by they aren't targeting new page review or AFC. E.g. you can use the search box to explore intersections of these topics. E.g. if you type: "articletopic:women articletopic:stem" into the search box [1], you'll get a list of topics that are probably relevant to WikiProject Women Scientists. This doesn't currently work for drafts, but it could. See Phab:T218132 for a task I filed regarding integration with NewPagesFeed. Topic routing was deemed to be of lower importance. I'd like to see this integrated with Special:Recentchanges too. In the meantime, a bot is a good option for producing lists of articles for WikiProjects and other groups of subject experts to review. In the past, I reached out to User:SQL about putting something together but I'm not sure if that got anywhere. --EpochFail (talk • contribs) 17:18, 12 March 2020 (UTC)
@EpochFail: Note that this is already being done - User:SD0001/AfC sorting -- a listing of submitted AfC drafts sorted by ORES-predicted topics. That's only a prototype report, but I'm still working on converting that to a periodically updated report -- this is being discussed at WT:WPAFC#Pending_AfC_drafts_sorted_by_subject -- the initial comments were highly favourable.
As far as sorting of declined submissions are concerned, I am thinking it would be better to use categories - because of the large number of declined submissions. This would need to be discussed first. SD0001 (talk) 15:14, 17 March 2020 (UTC)
@SD0001: After reading this discussion when it first started, and recently finding about about WP:AfC sorting, I actually was about to ask about expanding the AfC sorting tool on your talk page. (but then I went back to this discussion, and realized it has already been mentioned)
I think if the AfC sorting tool could be made in a similar way for all of draftspace, then draftspace could easily become a collaborative space (like it seemed to be originally imagined as). As long as editors were directed to using the tool in an easy-to-find space, it could be a great way to get involved in editing drafts, especially for new users. It could then be a way for newer users to potentially collaborate with those who have more editing knowledge, too. And it could be a great tool for Wikiprojects to use as well, especially during edit-a-thons. I'm not sure of the feasability of creating something similar to AfC Sorting for all of draftspace, though. - Whisperjanes (talk) 18:46, 10 April 2020 (UTC)
It is feasible. However, considering that there are over 22,000 declined AfC drafts and 12,000 unsubmitted ones, it would not make sense to make lists like WP:AFCS. It would be better to categorise them instead. That's what the category system is built for. But I'm not sure about doing this for the ones which don't have any AfC templates. Some folks like BD2412 maintain big sets of drafts on particular topics which are best left alone. SD0001 (talk) 16:27, 11 April 2020 (UTC)
@SD0001: Yes, I meant to propose lists for categorization, but I'm not sure if I explained it well. Are you saying that those types of lists are best used for AfC submissions, specifically? (I can imagine, since I assume including all drafts might be too many for editors to comfortably look through or for a page to handle, even if they were categorized). I think a list for all AfC drafts would be good, but I also thought it would be nice to be able to do something similar for non-AfC drafts, since draftspace is open for other editors to collaborate in. I don't think it should theoretically get in the way of lists that other editors maintain themselves (unless I'm missing something). Also, looking at some of the discussion above, it seems like other editors collaborate on BD2412's drafts, so I'm not sure how categorization would bother their own efforts, unless they use a specific process that would be disrupted by a new list. - Whisperjanes (talk) 15:45, 16 April 2020 (UTC)
I have no objection at all to a scheme of categorization of the drafts I have created. BD2412 T 15:58, 16 April 2020 (UTC)
Whoops, I seemed to also misunderstand something. In the comment I was replying to, I think SD0001 meant to say it would not make sense to make lists like WP:AFCS. I thought the term "list" and "categorize" were being used interchangeably (like how the WP:AFCS list has "categories" in the non-Wiki sense). My bad -- You can largely ignore my comment above.
I was proposing a list, originally, although I can see now why that probably wouldn't work. I do think separate lists for each type of draft topic could possibly work, though, or at least some of the other suggestions above are worth looking into (like being able get draft suggestions by topic). The reason I am a bit hesitant to use categories as the main way for specific drafts to be found is that I personally do not find categorizes to be an easy navigational tool, and I'm not sure about it being used as a tool to drive collaboration (mostly because I don't think its very accessible for new users). A list, to me, is a lot more frontward facing and accessible to all users, so could be more easily understood and used in article creation initiatives (like edit-a-thons). - Whisperjanes (talk) 16:31, 16 April 2020 (UTC)
@Whisperjanes: I'm sorry, it was my fault, I omitted a "not" in that comment (now fixed), because of which it must have been very confusing. I agree that categories aren't a very good navigational tool. But the reason I think lists are not worth it in this case is that since these are lists of declined or unsubmitted drafts, it's unlikely that they'd be of much interest to others. Categories are a more natural organisational tool which comes with lesser overhead. Categories can be easily converted to lists if needed for some purpose, and they can also be used in search (the "incategory" keyword, and combined with other search filters), and in PetScan. All this isn't possible with simple lists. While I agree that lists are better for browsing, that doesn't seem like an important consideration as I don't think many users are going to browse through lists of declined/unsubmitted stuff. SD0001 (talk) 13:30, 18 April 2020 (UTC)
  • I was going to chime in with how great draft space is for developing articles collaboratively within a WikiProject. But then I remembered how inactive most WikiProjects are. This is a dual problem. ☆ Bri (talk) 16:03, 24 March 2020 (UTC)
Possibly useful data point is reviewing my own contribs noted at User:Bri/Created#January 2019, a total of nineteen articles. Two were first drafts for at least two months: Draft:BMW R1250GS, tagged for collab at WP:WikiProject Motorcycling; and Draft:Pritchard Park. Neither attracted input from other editors. ☆ Bri (talk) 16:55, 24 March 2020 (UTC)
Headbomb, I'd really like to see biographies sorted into those about people who are still alive (or very recently deceased) and those who are historical figures. My experience is that WP:BLPs are almost always promotional, either WP:AUTO or some sort of WP:COI, and as such, almost always undesirable as encyclopedia content. On the other hand, a biography about somebody who has been dead for, say, more than 10 years, is likely to be notable, and these should be given priority for reviewing. -- RoySmith (talk) 02:35, 27 April 2020 (UTC)
Agree. Sometimes I search through declined drafts for phrases indicating that it is a biography about a dead person, because the majority are notable. Calliopejen1 (talk) 16:16, 27 April 2020 (UTC)

Proposal: Categorize all AfC drafts with ORES topics using a bot

FYI
 – Pointer to relevant discussion elsewhere.

I have proposed at WT:WPAFC#Proposal:_Categorize_all_AfC_drafts_with_ORES_topics_using_a_bot that a bot be used for sorting all AfC drafts by ORES-predicted topics. (@Headbomb, Espresso Addict, Clayoquot, WhatamIdoing, EpochFail, Whisperjanes, and Bri: ). SD0001 (talk) 11:00, 16 April 2020 (UTC)

More collaborative editing in draftspace

A few months ago I learned how to use AWB to check across draftspace as well as mainapsce, since then I have fixed a lot of typos in draftspace and had lots of thanks, mostly from newbies ( my last 500 draftspace edits go back to Oct 2019, but I'm hoping in that time some got moved to mainspace). It is fiddly and not the default, and timewasting even if you skip past a bunch of articles that would be obvious A1, A3 or A7 in mainspace. But if we changed AWB and some other tools to default to including draftspace within article space we could easily increase collaborative editing in draftspace. Similarly with categories. Currently you are not supposed to add mainspace categories to drafts, but what if we changed the software so that the category system ignored categories in draftspace unless an editor had opted in to seeing them? That way categories could be added, and editors who look for new things categorised in "their" area would likely do more collaborative editing in draftspace. ϢereSpielChequers 15:46, 29 March 2020 (UTC)

Keep it simple

I read all my experienced playmates sharing experiences about using draft space- culling the crud, and devising ever more complicated ways of bringing life back into the corpse. Whatever the system is tomorrow- make it one that you can explain to a non-user. We need more editors, and they are out there- brimming over with good faith but a soon as we describe what you have to do to create a new article- they thank you for the coffee and we never see them again. The R value of editing Wikipedia is well below 1, when I started it was 3 or 4 (making up the number- WP:OR, {(cn)}} and probably POV and BLP as well). So keep Draft:Space for the experienced and make it read only for the newbies. WP is already too complicated to explain in an afternoon training session to the potentially committed.ClemRutter (talk) 12:11, 10 April 2020 (UTC)

A? deletion of week old drafts

One reason why draft space doesn't work is that it protects for 6 months a bunch of articles that in mainspace would be deleted A1, A3 or A7. So one simple reform would be to allow all types of speedy deletion to apply to relevant drafts that were a week old. If a week is thought too harsh, a month would still enable us to sieve out a lot of crud. It should be fairly easy to create a "week old draft pages feed" to enable such sifting. ϢereSpielChequers 15:46, 29 March 2020 (UTC)

Support either a week or a month. 6 months is too long to wait for G13 deletion. This would get rid of a lot of crap. buidhe 09:43, 30 March 2020 (UTC)
A week is way too short. A month of inactivity would be the bare minimum. We do want people to be able to return to their drafts and improve them to standards. With obvious provision that a submitted draft that doesn't get reviewed is exempt. Maybe we should consider WP:CSD#D criteria which apply after a month of inactivity. Headbomb {t · c · p · b} 10:37, 31 March 2020 (UTC)
Six months seems fine. Anything shorter will introduce a perverse incentive: an editor who knows his draft is not ready, but has a heavy work period, new baby, etc. coming up, will protect it by submitting it for review, increasing the load on the already overworked reviewers. Maproom (talk) 17:51, 1 April 2020 (UTC)
@Headbomb, this is for A1, A3 or A7 candidates. This isn't a suggestion that drafts be deleted if they aren't ready for mainspace, more if they have no prospect of ever reaching mainspace. "Hoped to take part in the next Olympics" not "took part in the last Olympics. ϢereSpielChequers 15:43, 16 April 2020 (UTC)
    • Six months is appropriate, as it can take 3 months or more for an article to be reviewed. Even if those are exempt Ive come across some good drafts that should be published that have been abandoned for unknown reasons and reducing the time limit will make it easier for those drafts to be missed. With the current backlog there are 270 articles in the 3 month que and some do not need further editing so less than 6 months would be biting the newbies, imv Atlantic306 (talk)
      • There is a difference between screening out stuff such as this - an obvious A7 candidate if it was in mainspace, and reviewing drafts that have content worth reviewing. ϢereSpielChequers 18:32, 19 April 2020 (UTC)
I have no problems with the six month grace period, but I would propose applying CSD-U5 and CSD-G11 to the draft space to weed out the worst misuse of draft space. Kleuske (talk) 09:09, 14 April 2020 (UTC)
G11 already applies in draftspace as it does in all namespaces. Not sure about U5, I don't recall seeing many pages in draftspace that would merit U5 deletion if they were in userspace. ϢereSpielChequers 15:43, 16 April 2020 (UTC)

30/500 for new page creation

DECLINED
There is a clear consensus against requiring extended confirmed rights to create new articles. --DannyS712 (talk) 06:20, 3 May 2020 (UTC)

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.


I've been an AFC reviewer for a while and I have a somewhat radical proposal: Restrict new page creation to those who achieved the extended-confirmed status. That would largely eliminate the need for draft space since the more experienced editors would hopefully create articles that more or less belongs in mainspace. This move would also discourage SPAs, sock/paid editing rings, and PROMO violations. --K.e.coffman (talk) 20:56, 29 March 2020 (UTC)

@K.e.coffman: I'd think that if you made it harder for people to create a page in (main), it would increase the use of Draft:, not decrease it - where else would these people (~38.5 million registered editors) propose their new pages? — xaosflux Talk 22:24, 29 March 2020 (UTC)
I support this proposal for the same reasons, but it would certainly increase draft, not reduce it; also, there would be more need for AfC reviewers. buidhe 09:42, 30 March 2020 (UTC)
  • One would first need to start extracting some stats Xaosflux. As I mentioned somewhere above, ACPERM was a very strong consensus, as ACTRIAL always was throughout the many years of battle with the WMF for the Community to prove them (once again) wrong. We got what we wanted and it was as much as we dared to ask for - perhaps we should have proposed more, such as what K.e.coffman is suggesting now. AFAIK, neither during the trial nor since, has it been demonstrated that the new rule has increased the number of drafts. Kudpung กุดผึ้ง (talk) 20:57, 30 March 2020 (UTC)
    @Kudpung: agree, more stats would be useful, I was only referring to that concept that additional article restrictions are unlikely to reduce the number of drafts being created or alleviate the need for the namespace, likely the opposite. — xaosflux Talk 21:37, 30 March 2020 (UTC)
    In that case, why not also restrict the creation of pages in draftspace (and userspace) to autoconfirmed as well? Or might as well have a "page creator" user right. FMecha (to talk|to see log) 05:41, 14 April 2020 (UTC)
  • Oppose If you tell people that they have to make 500 edits before they can create an article then either they will give up altogether or they will run around making 500 pro-forma edits. And this would further complicate the many editathons where we specifically recruit new editors and encourage them to create new articles. Perfectionists who don't like Wikipedia's open door policy should go work on a more elitist project such as Scholarpedia. That published just 6 articles in 2019 and none yet in 2020. Is that slow enough for you? Andrew🐉(talk) 10:07, 31 March 2020 (UTC)
  • Meh I would be surprised if the WMF accepted this, it would be an overly simplistic approach that would be hugely offputting to the 25% of newbies who want to start by creating an article that we are missing. But perhaps we could do something re probable spam articles? Perhaps a page creation process that includes the phrase "I understand that if my article looks like an advertisement it will be deleted on sight" with a tick box that people have to tick to confirm they have read that. ϢereSpielChequers 10:33, 31 March 2020 (UTC)
  • Oppose no evidence that autoconfirmed creation in mainspace needs to be curbstomped in this manner. NPP is sufficient there. Headbomb {t · c · p · b} 10:39, 31 March 2020 (UTC)
  • OP's comments: @Xaosflux: the idea was to indeed present a message that would advise users to please wait until they have achieved ECP status to write their article. @Headbomb: the initial issue discussed on the thread was the perceived failure of draft space in enabling article creation. Waiting for your draft to be reviewed for a month or two -- and most likely declined / rejected anyway -- is not conducive to editor retention; it's better, IMO, to encourage new editors to join in editing existing articles. That way, they can gain the necessary experience, while reducing the load on NPP and AFC. @Andrew Davidson: editathons are conducted by experienced editors, who can move the articles directly to mainspace, sort of providing the AFC function on the spot. --K.e.coffman (talk) 22:51, 2 April 2020 (UTC)
    @K.e.coffman: going off of who registers at WP:PERM - many edit-a-thons are coordinated (at least locally) by "warm bodies", often that have never created a single article. — xaosflux Talk 02:12, 3 April 2020 (UTC)
  • Intrigued, but weak oppose I can see the appeal of this approach, and especially the argument that at six million, creating new articles is no longer the best way to contribute to wikipedia. Out of curiosity, I decided to look up the articles I created during my first 500 edits, to see what I would not have been able to do under this policy. They are, in order (with notes on why I created them):
Daughters of the Samurai (personal interest), Marion du Faouët (Women In Red wikiproject), Marguerite Hicks (personal interest), Owl Fisher (WIR), Judith Bakirya (WIR), Avis Little Eagle (WIR), Dayna Ash (WIR), Raya Bidshahri (WIR), Gertrude Helena Bone (defunct Project Gutenberg wikiproject), Elegiac Sonnets (personal interest), Safi al-Din al-Hilli (personal interest), May Arida (WIR), Waed Bouhassoun (WIR), Kafa Al-Zou'bi (WIR), Myrna T. Semaan (WIR), and Randa Bessiso (WIR).
I feel lukewarm about this body of work. Naturally I think all of these are appropriate and improve the encyclopedia (or I wouldn't have made them), but I also think the four "personal interest" articles are generally more notable, and that going out of my way to find new articles to create didn't often produce my proudest work. While I was writing those articles, I was also gradually improving Ōyama Sutematsu's page from this to its current state, which I think was a better use of my time. Nonetheless, I think I benefitted, as a new editor, from the ability to make articles, even if the ideal outcome might have been for me to have created four rather than sixteen. Article creation helped me learn what a wikipedia article is really supposed to be. As a new editor I actually had a very good experience with AfC -- wrote my first article in draftspace, was accepted through AfC in a mere sixteen hours, and felt a great sense of comfort knowing that people were keeping an eye out to make sure I didn't "mess up". I continue to use draftspace for any article I don't finish in one sitting, to indicate that I'm open to others' contributions, and keep those separate from "private" userspace drafts.
Overall, I think any problems with draftspace are really just displaced symptoms of problems with article creation. But in the end, I don't think a technological barrier at 500 edits is the right approach. Instead, I'd encourage a very strong focus on channeling newcomers toward destubbing and sourcing articles, especially in editathons. ~ oulfis 🌸(talk) 09:35, 3 April 2020 (UTC)
  • Oppose. This is going too far. This will only leave us with fewer long-term editors. —pythoncoder (talk | contribs) 15:24, 26 April 2020 (UTC)
  • Oppose per the above reasons of being discouraging to new editors. SemiHypercube 15:29, 26 April 2020 (UTC)
  • Oppose per all. While I'm certainly not opposed to stuff like mandatory registration, autoconfirmed status is sufficient for weeding out the weak articles IMO. My first edits were creating new articles in a relatively niche topic, and I feel that I might have been discouraged if I had to wait a whopping 30 days and 500 edits. – John M Wolfson (talk • contribs) 18:51, 26 April 2020 (UTC)
  • Strong oppose: per all. Absolutely not. This goes too far, and would lead to most new editors being terribly discouraged. This would also hurt editathons (and changing their format wouldn't help, either, but that's a conversation for another time). — Javert2113 (Siarad.|¤) 18:56, 26 April 2020 (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.

Spitballing: article proposals?

First off, disclaimer that I'm not involved in AfC or NPP. I do spend a lot of time in Huggle, however, so I do come across drafts fairly frequently. That being said, there's a fairly good chance that people more familiar with this stuff will think this is a bad idea, and I defer to them.

That being said: it seems to me that a large problem with the current Draft/AfC system is that new contributors spend a lot of time on articles that quite frankly have no chance of notability. However, there's no reason we actually need an article present to make a notability judgement. Therefore, I propose something like this:

  1. Prevent non-autoconfirmed users from creating pages in Draft: space.
  2. Instead, create a WP:Article Proposals page where those users can fill out something like the following:
    • Title of proposed article:
    • Describe the topic in a sentence or two:
    • In a sentence or two, why is this topic important?
    • What, if anything, is your relationship to the subject?
    • List at least two sources on which you would base your article. Make sure these sources are reliable and independent of the subject.
    The first and last questions are the most important here, but the others also seem worth including.
  3. Submissions to that page would be handled in one of three ways: a) immediately decline it, if it would almost certainly get speedied or fail AfD; b) if it's clearly notable, create the draftspace article and let the new editor know they can get to work; or c) if it's borderline, still create the draftspace article, but warn the editor that there's a good chance their effort would be wasted.
  4. Commit to keeping the Article Proposals backlog under a week or so.
    Is this practical? I have no idea. I kinda imagine that something like this would be quicker to review than a full on AfC, but I quite frankly have no idea.
  5. Once the article's been written, send it through a (possibly streamlined) AfC process, which hopefully would have a much shorter queue.

If this works as intended, I think it qualifies as an improvement on all sides:

  • New contributors benefit by quickly getting told that their article idea won't fly, before they've put a bunch of work into it; hopefully, this is less discouraging than our current AfC rejections, and they can go on to make a better proposal or contribute in other ways. Once they write their articles, they benefit from a significantly shorter AfC queue (and therefore wait time).
  • Reviewers can more quickly deal with obvious cases.
  • Draft space has much less cruft that will never be accepted, and maybe even becomes a useful place to find future articles to help with.

Again, this is not my area of expertise, and there's a decent chance it's a completely stupid idea. Thoughts? Gaelan 💬✏️ 08:25, 15 April 2020 (UTC)

I also don't work in this area at all (I admit that at this point, I rarely stray out of WP-space), but I do like this idea. It shouldn't be too difficult to implement, and it certainly seems like a friendlier environment for new editors. Despite my AWWDMBJ membership and general deletionist tendencies, I believe we may be reaching the point where borderline articles should be more acceptable, and this system would encourage the creation of those with a focus on proving the subject falls on the right side of that borderline. —⁠烏⁠Γ (kaw) │ 08:37, 15 April 2020 (UTC)
This has all the existing problems of draftspace while tiptoing away from the problem. De Wikipedia has a feature that prompts newbies to cite their source. Rather than reinvent the wheel we should nick that idea, and maybe put some screen in to reject certain commonly used unreliable source. ϢereSpielChequers 11:19, 15 April 2020 (UTC)
  • Oppose We already have a process for requesting articles, which has existed since 2001. Per WP:CREEP, we need to stop the proliferation of processes as we already have too much complexity and confusion. We should instead rationalise and simplify our processes by eliminating the ones that don't work; such as draft space and AfC. Andrew🐉(talk) 11:35, 15 April 2020 (UTC)
    Andrew Davidson, my proposal serves an entirely different purpose. Requested Articles is for people who want someone else to write an article about something. I'm proposing a sort of "pre-AfC" for people who want to write an article themselves, where we make sure it's notable before they spend a bunch of time writing. As for the CREEP argument, I agree that, all other things being equal, simpler processes are better; but all other things are not equal, and sometimes the more complex process works better overall. In addition, if this process results in higher quality drafts, it might mean we could significantly streamline the AfC process, it might actually result in simplification. Gaelan 💬✏️ 19:52, 15 April 2020 (UTC)
  • Comment I think User:Gaelan’s proposal for a simple wizard is interesting and could possibly save a lot of people wasting their time creating things that are never going to fly. Our basic problem is that for every unit of notable encyclopedic material there are hundreds of units of non-notable stuff out there – that’s even before we come on to the finer details of sourcing, COI etc. We can’t just open the mainspace to anything everyone feels like writing, unless many of us plan to spend the rest of our lives just pressing a delete button. As others have said there’s too much stuff and too few people to deal with it. I am not sure that just abolishing Draftspace will be of much benefit. I think we need the data others have asked for here, and we need to think about the whole workflow of creation/triage/support and encouragement. Under our current system things get stuck in various places because it’s just too much work for most editors to deal with them. Some get stuck in draftspace where they die. Others reach the New Pages Feed, where they sit for month after month without completing review. They’re probably not ok to release for a variety of reasons, but equally they’re too much work to easily fix, the creator is already a redlink anyway, and unless they are clearly not notable nobody wants to clog up AfD (maybe they could be sent to Article Rescue Squadron??). Nobody has yet found a way of getting decent, improvable content on quickly and encouraging new editors while disposing of non-notable content quickly too. The individual elements of our existing system are probably reasonably serviceable, but how they all work together is not optimal. If we outright banned IMDB as a source at all we could probably reduce all our backlogs by around 20% overnight. My last thought is that from memory in every case of a page I’ve reviewed that had been previously rejected at AfC and moved into mainspace by its creator anyway, the AfC rejection was correct. Mccapra (talk) 07:07, 26 April 2020 (UTC)
    @Mccapra and Gaelan: I think this is moving in the right direction. I'd love for you both to take a look at a discussion that Gryllida, DGG, and I recently had on improving the Article wizard. The TL;DR is that I'd like to force people using the wizard to provide some sources, and then to offer feedback based on how those sources compare with the WP:RSP list. {{u|Sdkb}} talk 07:50, 2 May 2020 (UTC)
Gaelan, you've proven once more the virtue of being open to outsiders--your proposal is simpler and better than anything discussed on that page, and I think it should be the basis of further discussion. Now of course the regulars will need to start looking for problems and exceptions , but i think what you have suggested is the basis on which we should build. The main problem is that the only judge of whether there should be an article is the community as a whole at AfD,; there are cases of AfD making what probably all of us here would regard as the wrong decision, and many cases about which any one reviewer would think so. Reviewers use experience to anticipate the likely judgement of the community, but it's not the reviewer's opinion that matters in the end. In other words, let us design the best and most logical rules at AfC, and we'll still be wrong. Tens of thousands of articles have been accepted at AfD without RSs. DGG ( talk ) 00:28, 3 May 2020 (UTC)
  •  Comment:I would suggest to implement this by adding "{{article start request}}" template, which would be similar to {{edit request}} in that it adds the request to a particular category.
Users could then place this "{{article start request}}" template at their personal talk page, followed by a description of what they are writing about, and a list of sources with summary of what each one of them says about the proposed article subject.
I think this could work especially well for paid editors as their draft usually is connected to one account.
I think this would also be good to be in a discussion format, and starting with a shorter "sources list" snippet rather than a complete article.
Has this been discussed anywhere else? --Gryllida (talk) 01:27, 3 May 2020 (UTC)
Gryllida, I suggest you go aheadwith this iidea, more or les as outlined. The place to discusss the details, is on the AFC talk page. DGG ( talk ) 01:31, 10 May 2020 (UTC)
Thank you, soon I will create an initial version of these templates and follow up at that talk page. --Gryllida (talk) 10:02, 10 May 2020 (UTC)

A really radical proposal

Why not follow the procedure outlined above, but instead of the initial proposed article being in a special place have it as a couple of sentences in main space. Then editors who know what they are doing (rather than anyone with a few hundred inconsequential edits under their belt) could review it and triage it by proposing it for speedy deletion, either improving it themselves or telling the author what needs to be improved or doing nothing and cheering the fact that something good has been created. People would then be able to find this thing (for which I have just made up the name "stub") and add content and sources to it. I propose calling this process a "wiki". Has nobody ever thought of this before? Phil Bridger (talk) 19:33, 15 April 2020 (UTC)

Let's say it's a controversial topic or a biography. Then if it doesn't start out good, the writer will only have a week to improve it or it will be deleted. The point of the draftspace is to give sufficient time to write a good article.—Naddruf (talk ~ contribs) 22:32, 15 April 2020 (UTC)
Phil Bridger: If I'm reading this correctly, you're just (with a heavy dose of sarcasm) proposing we open up mainspace to anonymous editors. If so, that's already been discussed to death above, has it not? Gaelan 💬✏️ 01:23, 16 April 2020 (UTC)
I don't think that the proposal is to open it up to logged-out/IP editors. WhatamIdoing (talk) 17:39, 17 April 2020 (UTC)

Preventing Wikipedia's Misuse as a Military Propaganda Engine

Duplicate of Wikipedia talk:Featured article candidates#Preventing Wikipedia's Misuse as a Military Propaganda Engine –Deacon Vorbis (carbon • videos) 17:39, 11 May 2020 (UTC)

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.

As a community we must raise vociferous objections to topics of militarism, atrocity, and warfare, given their misuse for warmongering, propagating history over herstory, chronicling institutions of murder over the societies they massacre, and the glib transformation of Wikipedia into a military propaganda engine for white westerners. Given that Wikipedia is suffering a verifiable deluge of military propaganda (8 Featured Articles in January, and 5 Featured Articles each in the months of February, March, and April 2020 alone), I propose that we as the Wikipedia community limit Featured Articles on military subjects to absolutely no more than one per month, if not one per year, and that if an article on a military subject is permitted in a given month, the Wikipedia community will mandate the inclusion of at least one Featured Article on a major global peace movement in that given month. I exhort the Wikipedia community to be vigilant and not let this treasure of public knowledge be misused by white supremacists, western militaries and institutions of death, nor extend the reach of their propaganda. — Preceding unsigned comment added by Herantifastory (talk • contribs) 17:14, 11 May 2020 (UTC)

Well, I, for one, welcome our new white westerner overlords. –Deacon Vorbis (carbon • videos) 17:23, 11 May 2020 (UTC)
Well, Herantifastory, you could improve some other articles to FA status rather than posting the same rant on 10 different talk pages (most of them archives). That would be more effective. Cabayi (talk) 17:30, 11 May 2020 (UTC)
(edit conflict)See WP:RIGHTGREATWRONGS. I believe that there are potential conversations to be had about NPOV issues relating to military issues on Wikipedia (for instance, militaries seem inclined to release a lot of COVID-19 photos under free licenses, so a disproportionate number have been making their way into COVID-19 articles), but that's not likely to happen here. Someone speedy close this, please. {{u|Sdkb}} talk 17:42, 11 May 2020 (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.

WP:RSOPINION and source quality

This is a lingering issue I tried to open discussion at the main policy page WT:RS but got little input, following an earlier discussion at [2] (under "Daily Mail and RSOPINION").

The short background: Obviously works like the Daily Mail are deprecated and should not be at all used for statements of facts. But they also do have staff writers that are reviewers for films and televisions, and thus their writings would seem to fall under WP:RSOPINION , and thus should be removed necessarily due to the DM's deprecation. This led to the whole intent of RSOPINION, which lacks the clarity that needs better resolution for works broadly, not just Daily Mail nor other deprecated works.

  • Does RSOPINION allow for the use of sources that are not reliable for fact, including those that are deprecated? The first statement of RSOPINION suggests this Some sources may be considered reliable for statements as to their author's opinion, but not for statements asserted as fact. but others argue that the line A prime example of this is opinion pieces in sources recognized as reliable. means RSOPINION is restricted to reliable sources.
  • Assuming RSOPINION does allow for the use of sources normally considered unreliable or deprecated. Should there also be a factor in RSOPINION related to expertise/recognition or similar authorizativeness of the author or the work to separate journalism from fan blogs or the like? For example, there are noted reviewers at the Daily Mail that have a history in reviewing UK television, so they would by a valued voice compared to some excited Doctor Who fan writing on their blog. I do note that if we take the interpretation about limiting to only reliable sources, this question becomes a non-starter on the presumption an RS is only going to publish opinions from people it considers authoritative to start.
  • Is there anything else of clarity that could be added to this point in RSOPINION? What we don't want is to open the floodgates to allowing random opinions to be used, and either by sticking only to reliable sources, or making sure that expertise/authority is sought here, we should be good, but there may be other facets I'm missing.

This is seeking input, as the discussion at WT:RS got little to add to that.--Masem (t) 14:58, 5 May 2020 (UTC)

What statement are you trying to source? If the statement is "In such-and-such a newspaper, so-and-so stated "The sky is green"", then that statement can be sourced to the original source where the quote came from. That's what RSOPINION is stating; if you need to establish that someone has stated something themselves then it's fine. It is not, never in any context, fine to use that statement to assess the veracity of the statement itself. That is, you cannot use such sources to verify that the sky is green, merely that the person who said "the sky is green" actual said those words. --Jayron32 18:12, 5 May 2020 (UTC)
Shoot, I should be explicit. The specific question was around things like critic's reviews of contemporary media like film, television and books, and if that is needed to tune the the use of RSOPINION better, so be it. I can see RSOPINION being more restrictive in some topic areas like political commentary, for example. Actually even moreso for political commentary given why sources like Breitbart have been strongly deprecated. But again, if we need to focus this specifically on critic reviews, that's might make this an easier discussion for that "carve out". --Masem (t) 20:15, 5 May 2020 (UTC)
If we're asking about critic reviews of media, that's an issue of WP:UNDUE and not reliability. A critic is a reliable source for what they said themselves. That's always true. The issue is "why should we care that the critic in question said it?" not "Do we believe they actually said the thing we're saying they did?" I mean, I'll take Robert Christgau and David Fricke over "Joe Schmoe from random local newspaper's" review of a particular album, even if the local newspaper is a reliable source, and we can believe that Joe Schmoe actually wrote that particular review. That's not a reliability issue. It's a recognized expertise and acclaim issue; opinions are not reliable or unreliable, opinions have weight and importance based on who the person who has the opinion is, and their reputation and area of expertise. --Jayron32 05:36, 9 May 2020 (UTC)
  • Blanket treatment of organs such as the Daily Mail is silly because they are typically have numerous sections written by many different writers in a variety of styles. Recognised staff critics such as Jack Tinker typically have a byline and their opinions will tend to be personal rather than just parroting a party line or house style. When I cite or quote such notable critics in a reception section, I would usually attribute them inline and link to their article, saying something like "Jack Tinker, writng for the Daily Mail, thought that the work was..." Andrew🐉(talk) 20:59, 5 May 2020 (UTC)
    Part of the issue was the blanket Daily Mail review removal but I want this to focus on the general RSOPINION though as I pointed out above, if we have to narrowly focus on critic reviews to distinguish from political commentary, that's fine. Reviews are far less contentious issues than political commentary from sources not normally RS for fact. --Masem (t) 03:57, 6 May 2020 (UTC)
  • I can see the temptation to allow critic/review pieces but I see two counterpoints. First, it would be a bit messy distinguishing acceptable review-pieces from other, unacceptable, opinion-pieces. Second, if the editorial management of that source is so thoroughly disreputable then it casts significant doubt on their choice of critic-staff and on their oversight of such content. No one Reliable is certifying that this critic's opinion is worth hearing. The critic is no better than a random blogger for our purposes. Alsee (talk) 02:34, 10 May 2020 (UTC)
  • I agree with Jayron32. When the Daily Mail says the UK government is about to lift lockdown we cannot use that as a source to support a statement that this is indeed the government’s plan. If their cinema reviewer says a film is boring that’s not a statement of fact it’s a statement of opinion. There’s no reason I can see why that shouldn’t be cited. Even a broken clock is right twice a day. Mccapra (talk) 02:55, 10 May 2020 (UTC)
  • So I'm wondering if it makes sense that we have what would be an "RSEXPERT" section, rather than modifying RSOPINION, which would allow statements (opinion or otherwise) from established experts regardless from where they are published but with a whole host of caveats:
    1. That who is an expert has to be established by consensus: not just someone notable (eg Alex Jones is not an expert on politics) but who editors that know the field are aware is a recognized voice in the field. In the area of media reviews, this would be notable film critics even those that write for a deprecated work like the Daily Mail. (As a corollary, an expert does not need to be notable, but if they have never been attached to a notable organization at all, that raises several questions).
    2. There has to be some verifyability that the expert is the one posted/writing the work. This is like the Twitter checkmark purpose.
    3. Key sourcing policies must be respected. BLPSPS still cannot be violated; an expert's commentary piece on its own cannot be used for talking about another BLP. MEDRS absolutely must be respected: An expert medical doctor writing to a common-man level about a new drug in his blog would not be allowed to be used on the page about that drug (though there may be other pages this could be applicable) A similar stance would be for SCIRS topics.
    4. This should be used for content that has general encyclopedic value, keeping in mind facets like WP:NOT#NEWS, WP:RECENTISM, WP:UNDUE, and so forth. This generally means that there are few areas where a single person's opinion, absent any other sources that call to that opinion, has weight to be used in WP. Reviews of media like television and film are one notable exception, another may be in analysis of court cases after they have been decided by legal experts, as in normal coverage of these types of topics, there is usually an accumulation of such reviews or analyses as to give the reader a broad idea of what experts have said about the topic.
  • Does this make sense? --Masem (t) 03:39, 13 May 2020 (UTC)
    We currently have an exception for subject-matter experts' self-published sources: "Self-published expert sources may be considered reliable when produced by an established subject-matter expert, whose work in the relevant field has previously been published by reliable, independent publications." It looks like your proposal would extend this exception to all questionable sources, instead of just self-published sources. If the publication is considered unreliable because it does not exercise adequate editorial control, your proposal would make sense. However, like Alsee said above, if the publication is considered unreliable because its editorial team has a reputation for curating content that is considered disreputable by reliable sources, then the opinion would still be questionable. Using the Alex Jones example, all of InfoWars would fall into the latter category regardless of author. — Newslinger talk 04:38, 13 May 2020 (UTC)
    That's why, in part, who is a subject-matter expert is going to be driven by consensus and based on where they are publishing from among other factors. Definitely don't the case that would allow Alex Jones to be considered a subject matter expert for a topic, for example. But I'm also wanting to make sure that if we have a UK reviewer who maybe has only written for the Daily Mail for their entire career, is known in other RS works talking about the UK reviewing scene as a top and important critic, that we can allow them as a subject-matter expert despite their lack of publication in an "reliable" source; consensus should be able to judge from the RSes talking about the person that they are an expert and can use them in this "RSEXPERT" manner. --Masem (t) 17:12, 13 May 2020 (UTC)

Mass enabling of talkpage archiving

Please see Special:Contributions/Philoserf (example). Thoughts on this? Those talkpages will probably have 1 or 2 threads for years to come, I don't see why the need for such forced archiving. This is not a complaint, and I'm posting here because I couldn't find any policy for/against this (but I certainly am against). Ping to User:Philoserf; please hold those edits until there is feedback? Rehman 02:42, 13 May 2020 (UTC)

Rehman, will do —¿philoserf? (talk) 02:45, 13 May 2020 (UTC)
Rehman, now there is someone following me deleting conversations. Weird. —¿philoserf? (talk) 03:48, 13 May 2020 (UTC)
Mass changes of any kind without prior discussion is highly undesirable. Infrequently used talk pages should be left alone until a central discussion says otherwise. Johnuniq (talk) 04:32, 13 May 2020 (UTC)
Should those edits be reverted? Rehman 06:04, 13 May 2020 (UTC)
In my opinion it's a non-issue. Leave the already modified talk pages as they are but inform Philoserf that archiving shouldn't be done for infrequently used pages (a new post every few months or so would be the bare minimum for me). Anarchyte (talk • work) 06:14, 13 May 2020 (UTC)
True. Although I'm leaning towards reverting as they look cluttered. I.e. in the example above, the talkpage already has {{Talkpage header}}, which would display the archives if available. And I've just noticed {{Friendly search suggestions}} and {{Annual readership}} has also been mass added. While it may be useful to some articles, I don't see the practicality of mass adding those to talkpages in this manner. Rehman 06:40, 13 May 2020 (UTC)
I was deleting "External links modified" sections from otherwise empty talk pages, which I'm allowed to do, to prevent them from being archived and creating useless archived pages. * Pppery * it has begun... 17:36, 13 May 2020 (UTC)
If archiving is set up, it should leave a minimum number of threads on the page like at least 3–5. For that archive client, it would be set by |minkeepthreads=.—Bagumba (talk) 08:59, 13 May 2020 (UTC)
Thank you all for the feedback. I learn each time I encounter an editor with an opinion.
Context
As I learn my way around, I have been visiting as many pages as possible. Observing the condition of the page, the talk page, and editorial interactions on these. I often make some small improvement and watch the page for editorial reactions. In this way I have learned a lot in just a little bit more than two active months here.
What I was finding in talk pages
I had seen a lot of pages with leading comments without title, often without signature. These, of course, acted as a lede and blew up the TOC. I had seen a jumble of talk page headers, warnings, markers, and other cruft in various mixed orders and styles. I also found misconfigured archive bot settings too.
What I intended
I thought that by adding friendly search suggestions and page views a new editor’s experience could have a bit of guidance and information about the article. I thought a conversation archive would help by moving crufty old conversations out of the way. Finally, I thought that by adding these as a prophylactic to pages that have been rarely updated we might get editors engaged.
Lesson learned
There are more views of what a talk page should be than I imagined.
Result
I will be more careful in any talk page updates I may offer and I will set retention so that a few old conversations remain when I do setup archiving. —¿philoserf? (talk) 17:55, 13 May 2020 (UTC)

Notability beauty pageants

There is no guideline for notability of beauty pageants. Wikipedia:WikiProject Beauty Pageants/Notability (beauty pageant participants) was an attempt to create such a guideline, but I am not sure why it fizzled out. As of now a huge number of pages in this category have been created which may or may not meet GNG as it is entirely a matter of perspective. Specific concerns in this matter are;

  1. Is a person notable just for participating in a pageant? If so what type of pageant confers notability, a national level? or a state level? or an international level pageant?
  2. What defines a national level pageant? or an international one? Who establishes the fact that a certain pageant is truly international? There are dozens of pageants that have international attached to their name, yet they are of not noteworthy.
  3. Is a single time winner of a national/international pageant considered to have passed GNG according to the AWARD guideline or should they be classed under SINGLEEVENT?
  4. what type of pageants can have their own articles?

I would like to invite the community to discuss this and come up with a policy WP:PAGEANT that can be quoted in discussions as an inclusion criterion for pageants and contestants. MistyGraceWhite (talk) 19:24, 10 May 2020 (UTC)

  • From my limited understanding of beauty pageants (which comes mostly from patrolling articles about them, and not due to any off-Wikipedia familiarity), there's "international" pageants that are nevertheless small-scale productions with limited notability. I think that if an SNG were to be drafted for this subject, the criteria would likely need to name specific pageants that actually represent the most prestigious competitions. signed, Rosguill talk 20:39, 10 May 2020 (UTC)
  • It looks like Wikipedia:WikiProject Beauty Pageants/Notability (beauty pageant participants) was located in draftspace and marked as a failed policy proposal until a little over a week ago, when Zanimum removed that tag without edit summary and moved the page out of draftspace. What's up with that? I also recall there being some other discussion on beauty pageants not too long ago, but I forget where. Is there other context we should have here? {{u|Sdkb}} talk 20:57, 10 May 2020 (UTC)
That draft was created after a series of AfD discussions about individual pageant contestants, winners and pageants themselves. Discussion at the Wikiproject level tended toward the opinion that there shouldn't be a pageant-specific SNG and that SNG's were a bad idea anyway. This meant that the proposal failed to gain consensus and was abandoned. I marked the proposal as failed and left it in draft for historical reasons. Hasteur apparently saw an abandoned draft and marked it for speedy deletion seven months later but it was not removed at that time. Zanimum apparently saw an over two-and-a-half CSD tag and took the actions they thought appropriate. It is still a failed proposal but new discussion may reach a different consensus. The previous discussion can be found at the project talk page archives. Similar older discussions include this one and this one. The end result is that beauty pageant contestants and pageants tend to get held to the general notability guideline at AfD. I hope this helps. Eggishorn (talk) (contrib) 17:08, 11 May 2020 (UTC)
Proposals should be drafted in user or project space (moved to the latter when ready for discussion if not there already) and failed ones left there appropriately marked. Draft space is for the drafting of articles, and anything that isn't one will likely get speedily deleted and the history lost. Thryduulf (talk) 19:33, 11 May 2020 (UTC)
Absent further discussion, I'm going to mark this as historical. It never was broadly accepted as a guideline for usage and leaving it as-is might cause confusion that this is a valid standard. Eggishorn (talk) (contrib) 18:22, 13 May 2020 (UTC)

Indefinite Blocking Policy

I agree with the need to have the option of indefinitely blocking a user from using the website. However, I feel that after five years has gone by, the block is no longer needed, especially in the case of users who made massive contributions to the website. Let's let some of the old users out of the cage. They probably won't be expecting their release and may not even realize it. But the point of Wikipedia is not to exercise the power to block people- the point of Wikipedia is to make an encylopedia. In 2015, User:Billy Hathorn was blocked for massive copyright violations. The user is also in the top 300 editors by number of edits on Wikipedia. Let's imagine that the person is still interested in editing Wikipedia one day: do you think the person has learned their lesson? I don't know all the details of this user's case, but I'm just saying that a permaban may be "justified" but it is not necessarily conducive to producing the best encylopedia. If you let some of the blocked users that made massive mistakes but also some good contributions out of their cages, they might be able to make productive contributions. If they mess up again, just ban them again- simple as that! That's my opinion. I know it probably won't get anywhere, but I think the concept of permabanning people here is excessive except in the case where every edit a user makes is reliably deleterious to the goal of making an encyclopaedia. Geographyinitiative (talk) 12:06, 12 May 2020 (UTC)

"Indefinite" does not mean "permanent". Anyone subject to an indefinite block can explain why they should be unblocked and if that explanation is judged to be acceptable they will be unblocked. And what makes you think that doing loads of edits is a way to produce the best encyclopedia? In some cases it has been that the user in question has made loads of edits that make the encyclopedia worse. Such thinking led to one editor only being desysopped recently by Arbcom even though it had been obvious for well over a decade that this person's prolific admin actions were detrimental to Wikipedia. Let's look for quality rather than quantity. Phil Bridger (talk) 12:22, 12 May 2020 (UTC)
Putting that aside, with any case that's 5 years old, it would hardly be that difficult to make an unblock request if they were interested in doing so. It seems a very niche group of editors who: were an appreciable positive; have a 5-year old indef; at some stage will want to edit again with that account; can't/don't want to make an unblock request. Nosebagbear (talk) 13:23, 12 May 2020 (UTC)
No one is blocked from using this website by us, the only people blocked from using this website are people who live in or access the internet through countries, households or organisations that ban access to Wikipedia. We block people from editing this site, not from using it. Everyone is welcome to use this site as a reader, but we reserve the right to withdraw editing privileges. Most indefinitely blocked accounts are never going to be unblocked, even if the editor wanted to edit within the rules, why expect a twenty something to resume with an account that was banned for vandalism when they were a child? If there was one change to the policy that I would most strongly support it would be to say that if you were blocked before your 18th birthday, you are welcome to create a new account two years after your previous edit. ϢereSpielChequers 11:43, 13 May 2020 (UTC)
WereSpielChequers, I generally agree, but there is at lease one minor who in my opinion should be talking to law enforcement based on some of their actions here. There’s the idiot kids making penis jokes that frankly I don’t care about, and then there are the really messed up kids who engage in cyberstalking their “enemies” on this site. I don’t want the latter back, no matter how long it’s been. TonyBallioni (talk) 16:24, 13 May 2020 (UTC)
The relevant policy you seek to amend is Wikipedia:Blocking policy#Indefinite blocks, which states in its entirety:

An indefinite block is a block that does not have a definite (or fixed) duration. Indefinite blocks are usually applied when there is significant disruption or threats of disruption, or major breaches of policy. In such cases an open-ended block may be appropriate to prevent further problems until the matter can be resolved by discussion. It is designed to prevent further disruption, and the desired outcome is a commitment to observe Wikipedia's policies and guidelines, and to stop problematic conduct in future.

Indefinite does not mean infinite: an indefinitely blocked user may later be unblocked in appropriate circumstances. In particularly serious cases in which no administrator would be willing to lift the block, the user is effectively banned by the community.

Looking at the text of this policy, I think it provides a pretty clear avenue for how indefinitely blocked users may return. If they appeal their block and manage to convince us through discussion that the block is no longer necessary to prevent disruption, they will be unblocked. Other relevant essays on this include Wikipedia:Guide to appealing blocks and Wikipedia:Standard offer. Mz7 (talk) 18:55, 13 May 2020 (UTC)

Usage of the UserboxCOI template

Template in question: {{UserboxCOI}}

So far, this has been a good little tool for dealing with COI users. However, a routine search revealed that there are about 260 transclusions outside of userspace. I glossed through most of them, and it seemed that a good amount of these are in user talk space. Some of these are in the COI editor's user talk, while some are in more experienced users', when the COI editor was corresponding and put a COI tag there. Most of the remaining are in draftspace; I am working on removing them. I am raising a few questions:

  1. should the COI template categorize userpages into, for example, Category:User pages with Conflict of Interest declarations?
  2. should the COI template warn users when placed in the wrong namespace (like the {{Afd}} template)?
  3. should the COI template categorize such templating mistakes into a tracking category, with an option to exempt (to keep an archive of past discussions)?

Thanks. Eumat114 formerly TLOM (Message) 14:00, 14 May 2020 (UTC)

Redirect Disputes

I am not a principal to any of these disputes but would like the opinion of other editors on a policy matter that comes up from time to time. An editor offers a reasoned argument that an article topic is not notable and that the article should be redirected to a parent article. This most frequently happens in music, but also elsewhere. In music, commonly there is an article on a song, and the argument is that the song is not notable and should be redirected to the album. Sometimes the argument is that an album is not notable and should be redirected to the artist. An opposing reasoned argument is made that the topic is notable and the article should be kept. The question is how this dispute should be resolved. One option is a deletion discussion, but often the proponent of redirection says that they are not requesting deletion, so that AFD is not the appropriate forum, and that the article should simply be redirected. I have occasionally seen this lead to edit-warring, and we know that edit-warring is the wrong answer, regardless of what the right answer is. So is there a different right answer? My thought, after looking at the policies and guidelines once, but not reviewing them in depth, is that a deletion discussion is the appropriate answer, even if no one is actually proposing deletion, because redirection is an alternative to deletion and is a side-door deletion; but maybe there is another procedure that is preferred. I realize that discussion is the preferred first step, but what is to be done if the discussion is inconclusive? Is there a first-mover advantage? Is there a second-mover advantage? A Request for Comments is another way to resolve a content dispute, but the only real differences between an RFC and an AFD are the length of time, with AFD being quicker, and that AFD is specialized to deletion-like disputes.

Should redirection disputes be resolved by AFD, or is there a different answer? Robert McClenon (talk) 23:41, 1 May 2020 (UTC)

  • Having been brought up on this very topic several times in the past (yes, the majority being music-related), I am glad for this opportunity to get some wider input.
I am firmly of the opinion that AfD is the suitable forum for these discussions. My main argument is that almost all of the send-to-AfD-for-redirect cases I have kicked off stem from NPP, and concern newly created articles. That means that there are practically no watchers of these pages - in many cases it will be just the author and the new page reviewer. It is pointless to start a "redirect discussion" on the articles talk page under these circumstances; no one will comment. This is also the very situation in which an obvious redirect won't "stick", because there are only two people involved, one of them heavily invested. - Now, one could address that by creating a list of redirect proposals for people to monitor. But that would have to be publicized and editors would have to get into the habit of watching it (maybe that even exists already? If so, I don't know where - which would illustrate the problem). In contrast, most experienced editors keep the occasional eye on AfDs, and at least some good input is rarely hard to come by. So we already have a well-visited forum to invite discussion of these cases.
Are intended-redirect AfDs sucking up too much time and energy from AfD commenters? I doubt it - there's generally some amount of such cases in evidence, but they are hardly swamping the venue. Is some functionality of AfD being abused because it is employed for discussions that don't have an intial target of "have an admin push the delete button"? Nope - because "delete" is not an uncommon outcome in these cases, and "redirect" is a rather common outcome in intended delete cases. It seems a rather finicky distinction to regard the latter ones as suited to AfD and the former as in the wrong venue. Looked at from a different angle, would the average non-notable song nomination suddenly be welcome at AfD if I nominated it for deletion up front, in the expectation that the outcome would instead be a redirect (as is the usual treatment)? Yeah, if done with intent that would be gaming the system, but don't tell me that very scenario doesn't happen innocently as well. And policing whether the intention of nominators equals the likely outcome would seem positively kafkaesque.
Tldr - sending an intended redirect to AfD for decision is functional and doesn't hurt. If we formally disallow the practice, some replacement infrastructure will have to be created, spun up and popularized. Let's not. --Elmidae (talk · contribs) 22:34, 1 May 2020 (UTC)
  • I think my perspective is similar to Elmidae's: converting to redirect is valid as a bold change, but further dispute should be handled at AfD. The only gray area in my mind are situations where one, usually inexperienced, editor is trying to prevent an article from being converted to a redirect despite there being a consensus among other editors that the page should be a redirect. signed, Rosguill talk 23:18, 1 May 2020 (UTC)
  • I agree; AfD is the best venue, both because of all of the reasons Elmidae explained and because this would essentially be one added purpose of an expanded "Articles for Discussion". If the talk page goes unseen, and it's not currently a redirect (or consensus for it to be one is unknown or nonexistent), AfD is the only logical choice. I personally would add the caveat from WP:NOTBURO that A procedural error made in a proposal or request is not grounds for rejecting that proposal or request, and that it shouldn't matter where the discussion takes place. —⁠烏⁠Γ (kaw) │ 00:48, 02 May 2020 (UTC)
  • New page is poorly created and needs to be redirected elsewhere. Especially true when a user tries to convert a redirect into a new article. NPP patroller boldly redirects, page creator reverts. If I see another experienced NPP patroller has redirected once, I may try to boldly redirect one more time to see if the creator takes the hint - if it's already been redirected a couple times, I would send the article to AfD for further discussion. If the page has been around for awhile, AfD is definitely the proper forum. So I would send it to AfD in all instances, if the dispute cannot be mediated between the edit warring users. SportingFlyer T·C 01:13, 2 May 2020 (UTC)
  • AfD is the appropriate location, if there is a discussion (that's can't be settled by BOLD/internally), making sure to ping everyone. Nominator should bold right at the start of their nomination that it's a redirection AfD, otherwise it defaults in interpretation to a redirect. Nosebagbear (talk) 09:01, 3 May 2020 (UTC)
  • I'm not sold on AFDs for redirect-or-standalone discussions. Redirect/don't redirect isn't just a notability question, it's also about WP:PAGEDECIDE. Deletion is about whether we have an entry or not; redirecting is about where the content should go. For example, one reason to put content about a song on the album page instead of its own page is if there isn't much content about the song. And a redirect discussion doesn't require an admin to close (no one is pressing the delete button). All of this pushes me to thinking that an RFC is better for redirect-or-standalone discussions than AFD. Though RFCs usually take 30 days as opposed to AFD's 7, that strike me more as a reason to close "redirect RFCs" sooner, rather than hold them in another venue. Levivich [dubious – discuss] 05:53, 10 May 2020 (UTC)
  • What is the problem with WP:Redirects for discussion? Thincat (talk) 08:46, 11 May 2020 (UTC)
    • @Thincat: RfD deals with pages that are currently redirects or soft redirects, and whether or not they should be deleted or retargetted. It is not a forum for discussing article content, so these sorts of discussions are completely out of scope. It's not a perfect fit for AfD but in the absence of a dedicated venue that is by far the best. Thryduulf (talk) 10:02, 11 May 2020 (UTC)
  • I agree that AfD would be the usual and best place to discuss whether an article should be redirected to a parent topic when article talk page discussion has failed -- I think the article talk page should usually be tried first. I would also note that music is not the only area to have this sort mof issue. Articles about primary schools are often but not always redirected to the article about the school district. Articles about neighborhoods are often redirected mto the articvel about the city or other larger area which contains them. Articles about TV episodes are sometimes redirected to an article about the series. Articles about individual books in a series are sometimes redirected to articles about the whole series. These are all similar judgement calls and simialr procedures should be followed for each of them. DES (talk)DESiegel Contribs 15:47, 11 May 2020 (UTC)

More Thoughts

I have a few comments. First, the music area has these debates because there can be different reasonable views as to how many articles to have at what level of granularity. With biography, for instance, the choices are delete or keep, no or yes. Merge/redirect is an occasional issue with biographies; it is the issue with music. There are strong inclusionist feelings by some editors and strong mergist or redirectionist feelings by some editors.

Second, I have also seen these debates after the article was in place for a while, although maybe that was because NPP was backlogged.

Third, I don't see any gaming of the system, but, to the extent that anyone is trying to use the system to their advantage, it may be the redirectionists, who argue against using AFD because they are not advocating deletion. I think that occasionally a redirectionist doesn't want to use AFD because it is likely to result in Keep, and they would prefer to win. There is good faith, but sometimes there is stubborn good faith.

Fourth, if there is consensus to redirect (merge) except for one editor, why not use AFD anyway? The alternatives are edit-warring or WP:ANI, and the alternatives are likely to take a few days to resolve, and AFD only takes a week. There is a commonly expressed view that formal closure is not always necessary because sometimes consensus is apparent, but if it isn't apparent to one person, formal closure is less messy than edit-warring.

Fifth, is there any reasonable reason not to use AFD for a deletion-like process?

Sixth, I will check to see whether the deletion policies and guidelines need to be clarified to establish that AFD is the proper forum for redirect disputes.

Robert McClenon (talk) 03:09, 2 May 2020 (UTC)

  • Imho, the WP:MERGEPROP procedure can be used unless one of the two articles is likely too un-WP:GNG to exist separately (which should then probably be rather discussed at WP:AfD). The WP:MERGEPROP procedure is somewhat less formal than WP:AfD, but is definitely a bit more structured than a mere "talk page discussion". It might be a good alternative when the article that is a candidate for being turned into a redirect is not wholly without merit, and a MERGEPROP discussion can possibly, for instance, be somewhat more suitable to concentrate on discerning whether the to-be-merged article merits a separate section in the article where the resulting redirect would go to (instead of only on the to-be-or-not-to-be question). --Francis Schonken (talk) 18:18, 11 May 2020 (UTC)

From the Deletion Policy

It says: "Suitable venues for seeking a consensus if a redirection is challenged include the article's talk page and Wikipedia:Articles for Deletion." So the claim that AFD is not appropriate for a redirect discussion is not just silly, it is just plain wrong. Robert McClenon (talk) 05:33, 2 May 2020 (UTC)

I agree, as seemingly has every editor to weigh in so far, that guidelines and precedent all support AfD as a place to deal with non-notable entries. One way to deal with lack of notability is to redirect/merge. Another way is to delete.There are others too. AfD is the correct venue to deal with articles that lack notability. Best, Barkeep49 (talk) 19:59, 2 May 2020 (UTC)
I have added clarifying language to WP:BEFORE. -- King of ♥ ♦ ♣ ♠ 21:34, 2 May 2020 (UTC)

Should we bring back the in wrestling section?

I mean it been there for years now — Preceding unsigned comment added by The Awesome Guy in the world (talk • contribs) 10:40, 15 May 2020 (GMT)

@The Awesome Guy in the world: Did you mean to post this elsewhere? Anarchyte (talk • work) 09:38, 15 May 2020 (UTC)


@Anarchyte: I just seen the archives and I saw the should we remove the in wrestling section? I’m sorry if this the wrong section to post The Awesome Guy in the world (talk • contribs) 10:40, 15 May 2020 (GMT)
If you're referring to this little discussion Wikipedia:Village_pump_(policy)/Archive_145#Should_the_"In_wrestling"_section_be_removed_from_professional_wrestling_articles? I'd say HECK NO. Consider Fandom (website) or something. Gråbergs Gråa Sång (talk) 15:26, 15 May 2020 (UTC)
Considering the discussion had a clear consensus I see no reason to restore it unless there is an extremely compelling reason to do so.--69.157.254.64 (talk) 05:30, 16 May 2020 (UTC)

How should we deal with false versions of Wikipedia articles being spread on social media?

File:Blood irradiation misleading screenshot.png
A false manufactured screenshot of an article that has been shared on Facebook. (Ultraviolet blood irradiation redirects to Blood irradiation therapy.)

We recently encountered a somewhat novel situation: Blood irradiation therapy, an article that had previously seen less than 50 views a day, suddenly spiked to over 30,000. We learned thanks to Beorhtwulf that it was because of a manufactured screenshot being shared on Facebook to try to give credence to Donald Trump's statement that ultraviolet light might be a cure for COVID-19. After a discussion at WikiProject Medicine, I whipped up a template, {{False version}}, and placed it on the article. It looks like this:

The pageviews for the page have since dropped back down to a healthier level, although they're still ~10x the baseline, meaning that roughly 90% of current readers are there because of the hoax. The template was brought to TfD by ToBeFree with the rationale that it wasn't appropriate to use a maintenance template for something that isn't a maintenance issue. It easily survived there, but several participants rightfully noted that we should probably have some broader discussion, so I'd like to bring up the general issue here. The next time we encounter misinformation of this sort, how should we handle it? {{u|Sdkb}} talk 20:23, 7 May 2020 (UTC) Courtesy pings to previously involved @Mark viking, WhatamIdoing, Mdaniels5757, and TheTVExpert: {{u|Sdkb}} talk 20:23, 7 May 2020 (UTC)

I think some may find the "please verify" language confusing. Verify with whom? It sounds like an instruction to specifically seek verification somewhere. BD2412 T 20:26, 7 May 2020 (UTC)
@BD2412: Would "confirm" or "check" be better word choice? {{u|Sdkb}} talk 20:45, 7 May 2020 (UTC)
Perhaps something more passive like "please take care". BD2412 T 22:04, 7 May 2020 (UTC)
I agree with the use of "Please take care" comrade waddie96 (talk) 11:25, 16 May 2020 (UTC)
  • Thank you very much, Sdkb, both for creating the template and this discussion. I do appreciate any attempt to combat fake news by facts, and I do see this as one. I just believe that, ironically, you're adding original research to the top of an article if there is no reliable source other than "Wikipedia user Beorhtwulf" and personal interpretation of statistics for placing the template in the first place. ~ ToBeFree (talk) 20:36, 7 May 2020 (UTC)
    Yeah, I don't really know how we could address that other than deciding that this is a valid exception to WP:OR, which wasn't drafted with a situation like this in mind. I certainly would have felt less confident placing the notice if Beorhtwulf had been an IP, had a talk page filled with warnings, or had ignored the request to upload a screenshot. It also would have complicated things if blood irradiation therapy had been getting steady normal traffic. This particular case was pretty clear-cut in my view, but part of what I'm hoping to accomplish by bringing this up here is to figure out how we might want to approach cases with more complicating factors. Some brainstorming is needed. {{u|Sdkb}} talk 20:52, 7 May 2020 (UTC)
    There is no requirement that project notices comply with WP:OR. It's always been just an editor's opinion that an article needs to be cleaned up, has an excessively long lead, or is difficult to understand. -- King of ♥ ♦ ♣ ♠ 23:28, 7 May 2020 (UTC)
    I wouldn't say this was a case of OR. An unsourced claim in the article text that a misleading version of it was circulating would be both OR and a questionable self-reference, but a template on a top is an out-of-band editorial communication aimed at helping the reader contextualise and understand what they are looking at. It's no more OR than a cleanup tag. For the record I was not the creator of the template and don't have a clear view on its retention. Neither did I seek to include 'research findings' or personal interpretations of statistics in the article. My involvement in this was to mention the article on a couple of talk pages in the hope of getting it some expert attention. Beorhtwulf (talk) 02:23, 10 May 2020 (UTC)
  • Thanks for starting the discussion, Sdkb. I can understand ToBeFree's concern--this seems like a real-world assertion that would need a verifiable source. But I am more sanguine about a warning template like this because there is already precedent for article lead templates making assertions that are not verifiable in RS--this article is written like an advertisement, that article is non-neutral, those articles have topics that are not notable. All of these tags caution the reader to read with a more critical eye and warning about fake offsite copies seems to be in the same vein. More generally, templates like this occupy an intermediate place between article content, which should be verifiable, and communications with the readers and fellow editors about the articles and the encyclopedia, which do not need verification, just consensus. --{{u|Mark viking}} {Talk} 21:09, 7 May 2020 (UTC)
    Yes, I don't see the big difference compared to if I, purely based on my own judgement, add another warning template. /Julle (talk) 22:23, 7 May 2020 (UTC)
    I agree that maintenance and warning templates don't (or at least shouldn't) fall under OR. They're, by definition, a result of our editors making judgment calls on the content of the articles and sections they're placed on. I believe that incorporating this template is a good idea, and as for the wording, I would go with something closer to instructing the reader to make sure they're reading this page rather than trusting a screenshot, but I'm unsure of the specifics on how to word that properly. —⁠烏⁠Γ (kaw) │ 22:54, 07 May 2020 (UTC)
  • I don't think I understand the need. So a reader sees a fake screenshot of a given Wikipedia article, then opens the real article on Wikipedia. Would the reader not, at that point, see that the screenshot is a fake? --Bsherr (talk) 21:58, 8 May 2020 (UTC)
Someone could easily think the screenshot was real, but since it no longer confirms biases it raises suspicions in their mind. Damaging Wikipedia credibility, which is what they are trying to achieve ie. nothing is true and everything is possible. Such are the goals of disinformation. -- GreenC 22:18, 8 May 2020 (UTC)
That would involve them parsing the article to check whether it matched what they had been told it said. We should not underestimate the deficiencies in reading comprehension, critical thinking and ability to assess of sources of some of the morons who weigh in on current affairs by sharing viral images of unknown provenance around Facebook (I don't know if your feed is as full as mine with utter nonsense about 5G, the whole pandemic is a conspiracy, etc). No doubt some of the spike in traffic was made up of visitors who wanted to look into the technology themselves, and hopefully they read the article, although I must say it was in a significantly poorer state at that point, which is why I brought it to the attention of editors (I wasn't the instigator of the template). Beorhtwulf (talk) 02:19, 10 May 2020 (UTC)
Don't such templates usually go on the talk page instead? Elizium23 (talk) 07:03, 17 May 2020 (UTC)
If the sole point of this template is as a response to File:Blood irradiation misleading screenshot.png, then I think the whole thing is based on a false premise. It's not the text that's being attributed to Wikipedia, it's the accompanying image (this one), and that's what people reusing our images are supposed to do. (They haven't done it quite correctly—they should be attributing the creator rather than "Wikipedia"—but they're definitely trying to comply.) Is there any evidence that whoever posted this is claiming that Wikipedia is responsible for the text, rather than just the image? ‑ Iridescent 13:48, 10 May 2020 (UTC)
My concern in initially raising this (again, I didn't make the template, though I think that was a reasonable thing for another editor to do) was the effect, not the intent. The social media post included both our photo and the text beneath it, within the same image as if from a screenshot. The text is written in something resembling a Wikipedia style: bolded term, abbreviation in brackets, definitional sentence followed by more detail. Obviously those of us familiar with Wikipedia spot that second-person wording in the second sentence and know this is not a quote from one of our articles, but given the Wikipedia domain as the image credit just above it looks to the uninformed like a screenshot from Wikipedia, maybe as viewed on a mobile device. I agree that it is not necessarily the case that whoever created this image did so to deliberately impersonate Wikipedia: maybe they just did an image search and got our image, and combined it with some ######## text, but the effect on uninformed readers is potentially the same. Whatever the intent here, page views on that article (the term as stated in the social media post redirects to the article in question) jumped overnight from 50 a day to tens of thousands, so people were looking this up. At the time the article was in a worse state, containing plenty of unsourced statements, although was not as egregious as the text in the screenshot. Beorhtwulf (talk) 10:53, 12 May 2020 (UTC)

Notable or noted?

FYI Wikipedia_talk:Notability#Notable_or_noted? — A question about the practical usage of the definition of 'notable' on Wikipedia — GhostInTheMachine (talk) 13:16, 17 May 2020 (UTC)

Template:Infobox person, Net Worth and Death

This may be in the wrong place, so bear with me and advise where to post if it is with my apologies.

I have tried searching around but cannot locate any good consensus regarding a matter which I recently got reverted for five times.

In regards to {{Infobox person}}, a category exists Category:Infobox person using certain parameters when dead which is added to an article when the {{{death_date}}} or {{{death_place}}} params exist but also a {{{salary}}} or {{{networth/net_worth/net worth}}}. Net worth states In personal finance, net worth (or wealth) refers to an individual's net economic position; similarly, it uses the value of all assets (long term assets) minus the value of all liabilities. - a dead person doesn't have any assets or liabilities.

Even the documentation for the template states Current estimated net worth, if relevant. for that parameter. Looks like there was some attempt to gain consensus on the talk page for the template, but that didn't get far.

Therefore the question I'm looking to gain consensus on here is should {{{salary}}} and/or {{{networth/net_worth/net worth}}} be removed if {{{death_date}}} and/or {{{death_place}}} exists and is a valid entry?

- RichT|C|E-Mail 22:22, 16 May 2020 (UTC)

FWIW, I noticed an infobox for death was created late last year. Template:Infobox death —¿philoserf? (talk) 22:28, 16 May 2020 (UTC)

Perhaps it would be better if salary or net worth mentioned the date of that particular reporting in the infobox? If it's cited well, it should be in reference to a specific time in which that salary or net worth was current. bibliomaniac15 22:32, 16 May 2020 (UTC)
The net worth being cited is another can of worms which I'm not going to get in to here - RichT|C|E-Mail 23:10, 16 May 2020 (UTC)
  • No Even if a person is dead their last known net worth before perishing is still worth noting in the infobox. For example it is worth noting that John D. Rockefeller was worth US$418 billion (in 2019 dollars; inflation-adjusted) in 1913 whilst he was alive. Regards  Spy-cicle💥  Talk? 22:40, 16 May 2020 (UTC)
  • No in addition to what I said here, one's earnings can be a defining trait whether dead or alive. People like John Jacob Astor (one of the reverts I made that was linked above), John Davison Rockefeller (who Spy-cicle mentioned), Andew Carnegie, and Cornelius Vanderbilt are all well known for being highly wealthy. SNUGGUMS (talk / edits) 00:34, 17 May 2020 (UTC)
  • No though editors should try to find the sourced value that is closest to the date of death, and consider applying standard WP inflation adjustment to current dollars. UnitedStatesian (talk) 04:16, 17 May 2020 (UTC)
  • No. As always, we are summarising what is reported in reliable sources, and for billionaires and other wealthy individuals, their networth is the subject of considerable media attention. For example, today sees the publication of the 32nd edition of the Sunday Times Rich List, a 100+ page report on the 1000 wealthiest people in the UK. Rich_Smith, as it looks unlikely that you will get support to remove "net worth" from infoboxes, please stop removing it, and restore it to any articles where you have taken it out. Edwardx (talk) 11:27, 17 May 2020 (UTC)
@Edwardx: I think you are missing the point of this, I'm only concerned with net worth with a person that has died (and where {{{death_date}}} and/or {{{death_place}}} is present and valid in the infobox)... not those still alive which I believe is what your reply was aiming at - - RichT|C|E-Mail 13:17, 17 May 2020 (UTC)
Rich_Smith, I do get that you are only seeking to address the infobox net worth issue for those no longer living (ie non-BLPs). Mention of the Sunday Times Rich List was only to highlight the media coverage that net worth matters receive more broadly. And you do appear to be missing my point that one should not seek to make changes (ie removing "net worth" from infoboxes of non-BLPs) BEFORE getting consensus to do so, rather one should wait and only do so if and when such a consensus is achieved. Edwardx (talk) 18:47, 17 May 2020 (UTC)
@Edwardx: I was working under the impression that as Category:Infobox person using certain parameters when dead exists and is displayed on the bottom of Template:Infobox_person/doc#Tracking_categories that consensus was reached at some point... albeit not able to find it when I was reverted, although someone did ask but got no response - RichT|C|E-Mail 21:13, 17 May 2020 (UTC)
  • A couple of things stand out in this post. Firstly, it is not true that "a dead person doesn't have any assets or liabilities". The whole procedure of probate is concerned with a dead person's assets and liabilities, known as their estate. Secondly we usually only get a reliable figure for anyone's net worth after they have died. I would have thought that it would be obvious that these fields were for the figures at the time of death (or maybe at some previous time for salary of people who retired before they died), but as it doesn't seem so obvious to everyone then maybe something like "at death" needs to be added to their titles. The net worth of a dead person is just as much encyclopedic content as that of a living person. Phil Bridger (talk) 13:47, 17 May 2020 (UTC)
In which case maybe the suggestion that Pigsonthewing suggested here will be better? A "Value of Estate"? Of course the other question there is should there be a requirement for a source for that figure - RichT|C|E-Mail 21:13, 17 May 2020 (UTC)
  • No per Snuggums and UnitedStatesian, although the net worth should be accompanied by a date (whether the person is dead or alive), the most encyclopaedic point in time is not necessarily always going to be the date of death (or the current year if living), so I'd be opposed to hard coding anything specific in the label. The use of {{inflation}} where relevant should be encouraged but not mandated. Sourcing should always be highly encouraged. Thryduulf (talk) 22:35, 17 May 2020 (UTC)

The home_town parameter of Template:Infobox_person

FYI
 – Pointer to relevant discussion elsewhere.

Please see: Template talk:Infobox person#Proposal: Repurpose and redocument the home_town parameter.

As I know that changes to major infoboxes are often controversial (and many to that template in particular have been WP:VPPOL RfCs in their own right), it seemed pertinent to notify this board of the proposal.

Summary: We removed |residence=, but kept this parameter for childhood non-birthplace residence, despite that being usually trivia. The proposal would repurpose this parameter for long-term residency places during the subject's period of notability.
 — SMcCandlish ☏ ¢ 😼  21:11, 19 May 2020 (UTC)

Use of Infobox port

It seems that {{Infobox port}} has been used in what I would consider an incorrect manner. The template is deigned for ports but it seems to have been used on many multiple occasions for places such as Peace Arch Border Crossing which is not a port, but a port of entry, a subset of which may include some (many? most?) ports. One solution to this may be to fork the current template into a new one for ports of entry, remove the port-related parameters (draft/depth being the most obvious one) and then swap them over either manually, or using a bot if a list or category of them can be identified. Is that a reasonable approach to take? Could/should I be bold and do that? Or should it be discussed somewhere first? Fob.schools (talk) 13:38, 20 May 2020 (UTC)

Based on a quick look, I think those instances should be changed to {{Infobox border}}. Also, this discussion might be better off at a WikiProject talkpage. Rehman 14:06, 20 May 2020 (UTC)
Yeah, but which project?Fob.schools (talk) 14:30, 20 May 2020 (UTC)
If there's nothing more suitable, I'd post at Wikipedia talk:WikiProject Infoboxes. Rehman 15:00, 20 May 2020 (UTC)

I have a specific example of which I am unsure if a non-admin archiving a discussion is appropriate. In this scenario on the spam whitelist talk page, an editor asked for one link to be whitelisted to use on an article that was recently deleted via RfD consensus. Since the spam whitelist talk page is primarily frequented by admins, is it appropriate for a non-admin to archive this discussion, as it is clearly unneeded now that the article has been deleted? Was just curious and thought this would be the appropriate forum to inquire on. Nanophosis (talk) 01:23, 18 May 2020 (UTC)

  • If the closure doesn't require admin action, and the closure is otherwise appropriate by that user, then yes, there's definitely no problem in a non-admin closing such a discussion. {{Nihiltres |talk |edits}} 19:31, 20 May 2020 (UTC)

 You are invited to join the discussion at Wikipedia talk:Copyright violations/Archive_1#Making it clear that copyvio tags should not be removed. Naypta ☺ | ✉ talk page | 11:49, 23 May 2020 (UTC)

RfC: Bureaucrat activity

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
The result of this request for comment is no consensus. Supporters of this proposal argued that these were reasonable activity expectations for bureaucrats and that the current activity requirements are insufficient, noting the importance of having bureaucrats who remain in touch with the evolving Wikipedia community. A few editors also voiced security concerns—if a bureaucrat is inactive, they may not notice if their account is compromised. Opponents to the proposal argued that the proposed activity requirements were unnecessary, stating that there is insufficient evidence of bureaucrat inactivity leading to problematic decisions. Other concerns included the thought that this proposal may lead to ill-considered or rushed decisions for the purpose of fulfilling the activity requirements, particularly given the relative scarcity of matters requiring bureaucratic attention. Respectfully, Mz7 (talk) 06:43, 24 May 2020 (UTC)

Since there's a thread at BN about bureaucrat activity, and I've told people the way to solve the problem is by creating an RfC, I'll go ahead and start one. I'm proposing the activity policy for bureaucrats be updated to the following:

Bureaucrats who do not have qualifying bureaucrat activity within the last two years before will have the bureaucrat permissions removed for inactivity, and may only have the bureaucrat permission restored by a new successful request for bureaucratship. Users will be notified one month prior to removal of their permissions. Qualifying bureaucrat activity shall consist of the following:

  • Granting or removing permissions that can only be done by a bureaucrat
  • Closing of discussions that are restricted by policy to bureaucrats
  • Participation in bureaucrat discussions either as a part for requests for adminship or bureacratship or as a part of ordinary discussions at the bureaucrats' noticeboard.

Simply expressing willingness to participate as a bureaucrat without activity is not considered activity for the purposes of maintaining permissions. Bureaucrats who have their administrator permissions procedurally removed for inactivity will also have the bureaucrat permissions removed, but may request them back if they return to activity and would otherwise qualify as an active bureaucrat.

TonyBallioni (talk) 21:25, 24 April 2020 (UTC)

Support (Bureaucrat activity)

  1. As proposer. The bureaucrat user group isn't one we have a particularly strong need for currently, and while I'm all for having people around who remember things from earlier in the projects years and can provide wisdom when they are needed, having them currently be active members of the project who are familiar with the wishes of the community in the area that they serve is important. So, I lowered this to two years because three years is excessive, got rid of the "I want it still" clause, and also removed renames as those are handled by global renamers now. We had a thread on the renamer portion at BN earlier and it was still considered activity, but I think opening that discussion for wider comment from the community is ideal, especially as any administrator can basically become a renamer on request at meta.
    The idea here is that the community has expressed a desire for bureaucrats who are familiar with how Wikipedia currently operates in the areas they serve both by promoting more active users to the permission and by complaining about inactivity. Proposing this as a way of seeing if there is a consensus for that view and because it is a view I hold myself. TonyBallioni (talk) 21:25, 24 April 2020 (UTC)
  2. Merely expressing a willingness to take part should not be enough in my view – it's the equivalent of archiving your talk page once a year to remain an administrator. Taking part in active discussions at BN, or a crat chat, at least every two years is not too arduous a step up. I agree that renaming is largely redundant now and should be removed.-- P-K3 (talk) 21:39, 24 April 2020 (UTC)
  3. This is a reasonable modification. After an extended period of inactivity, people lose touch with the community, the ongoing issues, and awareness of important discussions. Schazjmd (talk) 21:45, 24 April 2020 (UTC)
  4. As amended. If we truly end up in a situation where we have so many crats and so few RfAs that qualifying actions are rare, we can revisit the policy at that point. --AntiCompositeNumber (talk) 22:06, 24 April 2020 (UTC)
  5. Support. We need a decent number of crats for the occasional crat chat, but it is important that those participants be active members of the community, so that their decisions better reflect consensus. ST47 (talk) 22:31, 24 April 2020 (UTC)
  6. Support In any endeavor, a majority of the work will always be done by a small number of people; that's unchangeable. Raising the expected minimum activity, however, will help trim the fat. Why editors becoming inactive don't just resign the flag and pick it up later is proof of a hatshop mentality. Chris Troutman (talk) 22:41, 24 April 2020 (UTC
  7. Ultimately I think crats should be reconfirmed every so often (every 1 - 4 years) rather than some bare bones activity policy. However this is better than what we had before so I'll support it. But I really do think reconfirmation should be where we head. Best, Barkeep49 (talk) 22:53, 24 April 2020 (UTC)
    Please count me as opposed if in the view of the closer this edit would satisify the revised criteria. If that edit does then there's effectively no change to the criteria and this proposal fails WP:NOTBURO. Barkeep49 (talk) 00:16, 25 April 2020 (UTC)
  8. Support - I like Barkeep49's idea above, but this is a good first step. creffett (talk) 23:11, 24 April 2020 (UTC)
  9. Support Principle of least privilege * Pppery * it has begun... 23:13, 24 April 2020 (UTC)
  10. Support It is a bit silly that a bureaucrats could pop up now and again to keep the hat. How does that benefit the 'pedia? Natureium (talk) 23:24, 24 April 2020 (UTC)
  11. Support as useful. Beyond My Ken (talk) 00:16, 25 April 2020 (UTC)
  12. Support per above. imo two years is still too long, but this is absolutely a step in the right direction. -FASTILY 00:37, 25 April 2020 (UTC)
  13. Support We don't need hangers-on in any role that requires advanced permissions. I don't wish to pick on anyone but the BN thread that prompted this discusion was of a use who had not actually used any of their advanced permissions in 12 years and barely edited in 8 years, having already lost adminship once for inactivity. You leave for that long, you're starting over, not returning to exactly where you were. Beeblebrox (talk) 00:53, 25 April 2020 (UTC)
  14. Support per proposer ~ ToBeFree (talk) 00:55, 25 April 2020 (UTC)
  15. Support - it makes sense to me. Atsme Talk 📧 00:58, 25 April 2020 (UTC)
  16. Agree these should be tighter, and these are quite reasonable to keeping the tools sharp. The one caveat I will add, though, is that technically (ever so slightly) there is a legacy consultation role for bureaucrats at WP:USURP; that does not appear to be covered by these criteria. Not to be taken as aimed at any one individual, who I hope can and will return to activity. ~ Amory (u • t • c) 01:01, 25 April 2020 (UTC)
  17. Support If we do it for admins, then there is no reason not to do it for the next level up. The trouble is determining the right level of activity; I'd suggest 1 year since that matches the level for admins. –LaundryPizza03 (dc̄) 03:08, 25 April 2020 (UTC)
  18. Support - This is still far too lax, but at least it's something. ~Swarm~ {sting} 04:08, 25 April 2020 (UTC)
  19. Support per above.Pharaoh of the Wizards (talk) 04:46, 25 April 2020 (UTC)
  20. Support per all the above. Lugnuts Fire Walk with Me 07:58, 25 April 2020 (UTC)
  21. Support The nomination is sound. It's our usual policy for permissions, advanced or otherwise, to expire through under use, so this proposal merely brings cratship further inline with other permissions (Noting and agreeing with Swarm's point about incremental change.) Bbrox and Fastily also highlights important points. ——SN54129 08:43, 25 April 2020 (UTC)
  22. Support the amount of bureaucrat work is small but I think this is sufficiently generous. As with admins bureaucrats who aren't active are likely to fall out of step with changing standards. Hut 8.5 09:10, 25 April 2020 (UTC)
  23. Support. These are not requirements that are excessively hard to fulfil but would allow the removal of crat permissions from editors who are not acting as a crat. Thryduulf (talk) 09:26, 25 April 2020 (UTC)
  24. Support. Looks reasonable and very easy to meet – Ammarpad (talk) 09:35, 25 April 2020 (UTC)
  25. Support with the proviso that this not be applied retroactively. That is, for currently inactive arbitrators the clock starts ticking from the moment this proposal passes, not from their last action. Reyk YO! 09:33, 25 April 2020 (UTC)
  26. Support - as per proposer, but it's also still far too lax. Kudpung กุดผึ้ง (talk) 10:38, 25 April 2020 (UTC)
  27. Support. It can always be tightened further in the future, but we need a baseline and this proposal provides that. Britishfinance (talk) 13:47, 25 April 2020 (UTC)
  28. Support. - Not all crats but some are IMHO hatcollecting which really does need to be stopped, I agree with Kudpung this is still too lax however this is by far better than what we currently have and am happy to support it. –Davey2010Talk 13:51, 25 April 2020 (UTC)
  29. Support I would prefer to see a term limit of ~5 years. Crats need to be in touch with the current expectations of the community. If a re-sysop request appears, the "under a cloud" perception changes from time to time, and it takes only one quick-draw crat to make an irreversible mistake. Crats are bound by policy, but also have the option to not act at all. I would prefer crats to be very active in the community. Rgrds. --Bison X (talk) 18:38, 25 April 2020 (UTC)
  30. Support If the tools aren't used for a while, you probably don't need them. SemiHypercube 19:14, 25 April 2020 (UTC)
  31. Support per proposer. Wikipedia is not a millinery supply store, and those who hold advanced permissions should use them or lose them. Boing! said Zebedee (talk) 20:27, 25 April 2020 (UTC)
  32. Support any strengthening of the policy is an improvement, we need crats that are both active and aware of current community normals. Govindaharihari (talk) 14:16, 26 April 2020 (UTC)
  33. Support Very reasonable and not over-onerous criteria for retention of role Kees08 (Talk) 17:41, 26 April 2020 (UTC)
  34. Support: Perfectly reasonable and an excellent suggestion to boot. I agree with Swarm that this is just a first step, but this is a very good start. — Javert2113 (Siarad.|¤) 17:55, 26 April 2020 (UTC)
  35. Support: our legacy 'crats (and admins) are in their position because of their exceptional contributions to Wikipedia, which I thank them for, but this is not technical justification for having more privileged accounts than necessary. Not only is there a risk of accounts being compromised (given increases in security threats and our early lax attitudes to requiring strong passwords), there is also a risk of users not possibly being able to keep up with prevailing standards and practices when the majority of their experience was on a project with a different culture to it. Crats should be highly active in recent years. If personal circumstances prevent this then there are thousands of tasks they can do here that don't involve any commitment or activity requirements. — Bilorv (talk) 20:57, 26 April 2020 (UTC)
  36. Support - the more measures to stop a compromised bureaucrat account from wreaking havoc, the better. And bureaucratship is a commitment, much like adminship - they need to maintain said commitment. Kirbanzo (userpage - talk - contribs) 17:29, 27 April 2020 (UTC)
  37. Support as this is security 101 folks. spryde | talk 11:54, 28 April 2020 (UTC)
  38. Support crats need to be active at least semiregularly to remain in touch with community norms. – Teratix ₵ 01:48, 29 April 2020 (UTC)
  39. Support use the tools or lose the tools. LEPRICAVARK (talk) 12:05, 29 April 2020 (UTC)
  40. Support. Seems a good proposal to me.  — Amakuru (talk) 22:26, 29 April 2020 (UTC)
  41. Weak support It's a pretty infrequent problem, but the fact is, having out-of-touch crats making decisions is a bad idea. I'm not sure I understand all the opposition; how is it mean-spirited to say we need our decisions to be made by bureaucrats who are staying up to date? How is it chasing people away when they're already gone? And what possible reason can there be to retain tools you aren't using, aren't planning to use anytime soon, and are quite likely to misuse if you did use them because their uses have changed since you last paid attention? That said, I'd prefer a more nuanced solution. —valereee (talk) 14:13, 2 May 2020 (UTC)
  42. Support. No need to keep those dangerous rights if they are not used. – Majavah (t/c) 06:22, 8 May 2020 (UTC)
  43. Support - Seems like a reasonable first step. While chances to use crat tools are not terribly common, two years should be more than enough time. PackMecEng (talk) 17:46, 10 May 2020 (UTC)
  44. Support of course. Crats are elected because they have a high commitment to the community they serve. They always need to be up to date with the community's norms. Are we seriously going to wait until an out of touch crat makes a poor decision? Speaking from experience, we had a crat on Wikimedia Commons who granted back the mop to a former controversial admin, despite the latter's many mistakes and problems before their bit was removed. The crat had to resign due to community pressure. I'm also concerned about crats gaming the system by doing only the minimum amount of admin activity every year just to retain their sysop and crat bits. The Commons community also removed another crat for that. --Pandakekok9 (talk) 08:38, 13 May 2020 (UTC)
  45. Per nom. However, the two years is a bit long until de-crat, since if the advanced tools haven't been used over 6 months to a year they're probably not needed. I would also like to see a term limit of 4 or 5 years. comrade waddie96 (talk) 08:44, 14 May 2020 (UTC)

Oppose (Bureaucrat activity)

  1. Oppose this particular requirement. From my understanding the job of a bureaucrat is both stable and well-defined. There are very few bureaucrats and as we are volunteers I would expect some to move in and out of activity. I think it's better for our encyclopedia and editors if there are more bureaucrats, increasing responsiveness and increasing the liklihood of a request being answered quicker. I think the well-defined and stable scope makes this different to activity requirements for admins. For this reason I oppose the proposal. --Tom (LT) (talk) 23:46, 24 April 2020 (UTC)
  2. Weak oppose I'm not convinced that this would make Wikipedia better. Have there been any serious problems caused by rusty bureaucrats? buidhe 09:16, 25 April 2020 (UTC)
  3. Oppose The opportunities for such activity are quite sporadic and limited now as there are few RfAs and most of them don't have a close result requiring a chat. The proposal might therefore result in a unseemly rush to act in haste, in order to secure a rare opportunity to retain the position. Or the bureaucrats might start expanding the threshold for chats, in order to look busy. To avoid perverse incentives, it should be sufficient if the bureaucrat is active in the project in other ways – as an editor, patroller or admin. Or just have a fixed-term limit, as is done for arbcom. Andrew🐉(talk) 09:19, 25 April 2020 (UTC)
  4. Oppose. (most strong possible) The proposal does not present any problem that will be solved by this. We can not impose random rules, for no reason. BTW, links to the current policy and clearly stating the changes, instead of making us search, read and compare texts, would be much helpful - Nabla (talk) 10:36, 25 April 2020 (UTC)
  5. Oppose per all above, Creffet's comment below, and Cecropia's section below. Solution in need of a problem as it stands. --Puddleglum2.0(How's my driving?) 14:15, 25 April 2020 (UTC)
    Puddleglum2.0 - A solution to a problem is a proposal that is proposed just for the sake of change and do not offer any practical advantages, This proposal wasn't done out of pure boredom and this proposal has advantages like more active 'crats and 'crats who actually put the work in and who don't simply treat it as a "badge of honour" whilst doing absolutely nothing 'crat/admin related. –Davey2010Talk 15:10, 25 April 2020 (UTC)
    But there's very little work for bureaucrats to do. It's quite possible that there will not be an RFA discussion that finishes within the discretionary range for more years than this would allow, so the only activity that they would do would be to rubber-stamp community decisions. Do we want our bureaucrats to share out the rubber-stamping work so as to avoid this situation? If the real intent of this proposal is to do away with the position of bureaucrat, and leave this to stewards or arbcom members or someone else, then it should be open about saying so. Phil Bridger (talk) 17:58, 25 April 2020 (UTC)
  6. Oppose - Base cases make for bad law. This is rushed and not fully thought out. We don't want Crats acting simply out of filling a quota. Dennis Brown - 2¢ 23:56, 25 April 2020 (UTC)
  7. Oppose. Solution in search of a problem. Ruslik_Zero 20:59, 26 April 2020 (UTC)
  8. Oppose. Why do we so often chase people away from the project instead of concentrating on making people feel welcome? And what everyone else said, above. --Dweller (talk) Become old fashioned! 10:02, 27 April 2020 (UTC)
  9. Oppose - per Dweller and all of the above. OhKayeSierra (talk) 13:15, 27 April 2020 (UTC)
  10. Oppose per Buidhe and Dweller, but I am open to supporting a future proposal that is more effectively written. This specific proposal is still able to be gamed and unlikely to make a serious improvement to the project. Let's assume this proposal passes, and Crat A has been inactive for 728 days. By day 730 they need to "Grant[] or remov[e] permissions that can only be done by a bureaucrat" which is either intadmin or admin. All crats (currently) happen to be administrators and may have their bit removed or restored by request. So on day 729, Crat A removes their own administrator bit voluntarily. They are thus no longer inactive under this proposal and the clock restarts. Crat A remains inactive for another 728 days. They are no longer an administrator and on day 1458 they request their admin bit be restored. Having been inactive for nearly 4 years at this point, Crats B-Z are not "reasonably convinced that the user has returned to activity or intends to return to activity as an editor" (Wikipedia:Administrators#Restoration of adminship) but during the 24 hour holding period, Crat A participates in the discussion of their own userrights which is "part of ordinary discussions at the bureaucrats' noticeboard." They are thus no longer inactive. Crat A has thus extended their cratship for 6 years under this proposal with no substantial increase in activity. — Wug·a·po·des​ 17:26, 27 April 2020 (UTC)
  11. Oppose. A solution in search of a problem. Bureaucrats have demonstrated their trustworthiness, their clue, their competence for judging consensus (however community consensus evolves), having the best interests of the project at heart...and generally being boring. Absent pretty strong evidence to the contrary, I would assume they are capable of continuing to all this at whatever level of engagement they choose. If they choose that level to be zero, they are harmless, so I fail to see reason to remove the bit due to arbitrary activity/inactivity rules. In contrast, inactive bureaucrats returning to activity will either be due to again finding the time and enthusiasm to do so, and then that's a win and we should encourage it. Or they will have been encouraged to chime in during some tricky situation or where enough uninvolved bureaucrats are unavailable, where their voice may be valuable. In either case, even more than for a random admin, I'd expect they will nuance their participation to reflect their familarity (or not) with current community norms, as well as with timeless ones. Martinp (talk) 22:29, 28 April 2020 (UTC)
  12. Oppose Having an activity requirement for admins makes sense. The tools are widely used, and can be used any day of the year in a myriad of ways. There is never a shortage of admin tasks. But bureaucrat tasks come up only rarely. Having bureaucrats rush to try to do a task to not lose their perms seems foolish, and like a good way to create edit conflicts and wheel warring, as well as encourage bad decisions. Unlike the problem of inactive admins, I'm not seeing a serious problem of inactive 'crats that needs a solution. CaptainEek Edits Ho Cap'n!⚓ 01:26, 29 April 2020 (UTC)
  13. Oppose - First of all, since the criteria listed include non-logged action, I wonder who will be expected to plumb every Bureaucrat's edit history to determine if they qualify as "active". Second, Bureaucrats do more than the items listed. Third, I honestly do not believe that we really want Bureaucrats arbitrarily taking some action out of attempting to meet these criteria. Rather that they are instead doing so in service to Wikipedia. Such service of which I, at least, am wholeheartedly appreciative. - jc37 06:58, 29 April 2020 (UTC)
    I wonder who will be expected to plumb every Bureaucrat's edit history to determine if they qualify as "active". Well, other bureaucrats of course- probably xaosflux! Bureaucrats do this already, and in the current proposal this activity ironically doesn't count as bureaucrat activity. That said, since the above proposal further limits what is considered bureaucrat activity, it would be a slightly easier task than it is presently (not an endorsement). –xenotalk 11:46, 30 April 2020 (UTC)
    @Xeno: probably, though while updating something like Wikipedia:Bureaucrat activity doesn't appear to count itself, participating in an ordinary discussion at WP:BN - such as about the status of the activity check does. — xaosflux Talk 13:02, 30 April 2020 (UTC)
  14. Solution looking for problem. So many times on the bureaucrats' noticeboard we have a discussion where someone is unhappy with the various inactivity criteria, starts a long discussion over it and wants to change the policy; it's changed, tightened and it's still not good enough, apparently. A lack of activity doesn't mean keeping out of step with community norms; I can go months without any bureaucrat-related activity but I still read every RfA; we don't have a lot to do and sometimes we trip up over ourselves as is. No need to make that worse. Agree with Dweller, too, as we spend far more pushing people away than retaining them. Also, since there is at least one mention above of "some" current bureaucrats "hat collecting", I'd like to see evidence of this. Acalamari 22:29, 29 April 2020 (UTC)
  15. I don't see a genuine issue that needs fixing and the attitudes shown in some of the comments makes me sad. Spartaz Humbug! 05:50, 30 April 2020 (UTC)
  16. Oppose. I agree with CaptainEek that crat tasks are not frequent enough to allow any crat to definitely meet these "quotas". If there are no RfX to close or others are faster, that does not mean this crat doesn't want to be active, there just is nothing to do. And the more crats we have, the smaller the amount of work any of them has to do (which is not a bad thing). Unlike with admins, there is no basically infinite pool of stuff to do to demonstrate activity. As such, since all crats are also admins, it seems sufficient to remove cratship for inactivity at the same time as adminship is removed for inactivity (or, more radically, we could consider using the es-wiki model to combine adminship and cratship into one, eliminating this problem completely). I do agree with Davey2010 on WP:HATCOLLECTING problems in general but this proposal would consider crats inactive that explicitly denoted that they want to be active but lack stuff to do. Regards SoWhy 06:21, 30 April 2020 (UTC)
  17. Oppose, even if we have too many bureaucrats, I don't see why we should drive them away. —Kusma (t·c) 08:57, 30 April 2020 (UTC)
  18. Solution in search of a problem. Stifle (talk) 09:23, 30 April 2020 (UTC)
  19. Oppose The criteria seem wrong; I'd rather not see unnecessary bureaucrat activity increased just to meet these criteria. The net effect of these criteria seem that they would encourage more crat chats and more pushing towards quickly closing RfAs so as to meet these metrics. PaleAqua (talk) 19:59, 30 April 2020 (UTC)
  20. Leaning oppose. It seems to me that the grant of the 'crat bit is a statement by the community that the recipient is trusted to exercise that power. Mere absence of use should not diminish that trust. BD2412 T 20:09, 30 April 2020 (UTC)--
  21. Oppose I don't want bureaucrats doing bureaucrat things for the sake of appearing active. Better to go with project activity levels although with rather higher standards than we currently use for admins (which also need to be raised but that is a separate problem).©Geni (talk) 00:07, 1 May 2020 (UTC)
  22. Oppose per many of the above. Respect or trust or whatever it is we give to bureaucrats when they pass RfB doesn't seem to me to be worth much if we then say "We'll withdraw it if you don't keep busy". When i trust someone, i trust them until i have reason not to, not only as long as i can see they're still worthy of my trust; trust, in other words, is in character, which is not something that often radically and rapidly changes. Happy days, LindsayHello 07:45, 1 May 2020 (UTC)
  23. Oppose - For one, it strikes me as a solution in search of a problem, but more than that, it seems to motivate bureaucratic actions, either on the part of 'crats (showing up to add a "me too" comment to a discussion at BN, as a way to show they're involved maybe?) or on the part of whoever is tasked with deciding whether a given 'crat is active. This proposal doesn's streamline the way we do things, it doesn't seem to fix a problem with current processes and it encourages people to do work for the sake of doing work. Guettarda (talk) 13:13, 1 May 2020 (UTC)
  24. Oppose this particular variant, although I would support periodic reconfirmation RffBs for crats. It would serve the same presumed purpose of weeding out people who either weren't interested in continuing or have lost community trust, and unlike admins the numbers are low enough that we wouldn't be flooding the process, and the crat role doesn't involve as many contentious actions so there's less likelihood of a torrent of grudge-opposes. ‑ Iridescent 14:05, 1 May 2020 (UTC)
  25. Oppose. The activity requirement for administrators is reasonable, there are always things that need editing so a period of inactivity can be remedied with short notice. However, with the low number of RFAs per year, months may pass between each time bureaucrat activity is needed there. There is no benefit to having bureaucrats racing to close RFAs in order to satisfy activity requirements. Sjakkalle (Check!) 16:34, 1 May 2020 (UTC)
  26. Oppose Per Geni. SpencerT•C 01:32, 2 May 2020 (UTC)
  27. Oppose I don't see a particularly pressing problem that this solution aims to address. If there is no abuse by inactive bureaucrats, then no issue. If there are an insufficient number of bureaucrats to handle the job, the solution is to make more bureaucrats. Ergo Sum 01:41, 2 May 2020 (UTC)
  28. Oppose Still more of this "let's find a solution to a problem that doesn't exist". The crats have continually and consistantly proven to be the most responsible and dependable users we have. This constant need to change the rules in the middle of the game is offfensive. It's been done to death with "Admin." rules, and now we're on about the 'crats.
    Perhaps this is all simply young lions trying to make their bones. Everyone wants to have a "look what I did" moment that they can take pride in. But my feeling is that even if the 'old guard' is getting long in the tooth - there's absolutely no reason they can't work side by side with the 'young guns'. Or perhaps I just had some bad 'shrooms' on my pizza and I'm imagining things.
    Perhaps some folks feel we have too many crats. How anyone would come up with that is reasoning that I can't follow. I'd love to work hand-in-hand with 20, 30, 40 'crats that have 70, 80, 90% approval from the RfX process. Why the 'unwashed' would feel threatened by it is beyond me.
    In short? No. It's a fool's errand, and there's no need for it. I know there are tons of discussion about these "requirements" about, so I certainly not calling any individual a fool. Someone bringing this up can be a good thing if it quiets the chatter, and lets folks get back to actually building an encyclopedia. Thanks for your time. — Ched (talk) 02:04, 2 May 2020 (UTC)
  29. Oppose well intentioned proposal, but I tend to agree that this is a solution in search of a problem that doesn't currently exist. I also share the concern that there may not be enough opportunities to perform crat related functions. -Ad Orientem (talk) 02:15, 2 May 2020 (UTC)
  30. Oppose... concur with Ad Orientem, this is a solution in search of a problem. Jason Quinn (talk) 03:39, 2 May 2020 (UTC)
  31. Oppose as long as the bureaucrat doesn't leave the site completely, I see no need for this. SportingFlyer T·C 08:02, 2 May 2020 (UTC)
  32. Oppose I share the concern about not having enough opportunities to perform bureaucrat-only functions. I'd prefer a rule based on overall project activity. kcowolf (talk) 20:54, 2 May 2020 (UTC)
  33. Weak oppose - I don't see the point in this. DarkKnight2149 15:24, 6 May 2020 (UTC)
  34. Oppose per Andrew Davidson. the wub "?!" 17:18, 7 May 2020 (UTC)
  35. Oppose - There are currently less than 20 bureaucrats and, as others have stated, the chance to perform actions related to the role is far and few between (and we should not expect it on every available occasion). — Godsy (TALKCONT) 01:16, 8 May 2020 (UTC)
  36. Oppose Thism seems like a solution in search of a problem. I see no evidence that out-of-date crtats are causing difficulties to anyone, or making incorrect decisions. Use the same standards as for removing admin rights for inactivity. DES (talk)DESiegel Contribs 18:11, 10 May 2020 (UTC)
  37. Oppose—I don't mind 'cratship being removed for inactivity, so long as it's simply a matter of requesting "reactivation" of their permissions if and when these contributors return, just as it is with the administrator permission. Removing the advanced permissions of inactive accounts is a good security practice. However, requiring a new RfB for returning 'crats is needless, and requiring specific bureaucrat activity encourages needless actions or discussion just to retain the bit. I can't support the proposal with those elements present. {{Nihiltres |talk |edits}} 18:55, 16 May 2020 (UTC)
  38. Oppose - I don't see what problem this would solve. Is there an issue with old bureaucrats causing trouble? If the goal of this proposal is to simply get crats to be more active, why don't we just promote more crats instead? Forcing them to perform 1 action every two years isn't going to make any difference. Kaldari (talk) 22:03, 17 May 2020 (UTC)
  39. Oppose +1 to "solution in search of a problem." ZettaComposer (talk) 15:49, 18 May 2020 (UTC)

Discussion (Bureaucrat activity)

Requests to join the Bot Approvals Group must be closed by a bureaucrat, but aren't included in these requirements because there is no associated user right. The proposed requirements also leave out RfB crat chats (which, while rare, are possible). --AntiCompositeNumber (talk) 21:38, 24 April 2020 (UTC)

AntiCompositeNumber, good catch. Updated. Courtesy ping to Pawnkingthree. TonyBallioni (talk) 21:44, 24 April 2020 (UTC)

Anyone have a rough guess at how often these "qualifying bureaucrat actions" occur? What I'm concerned about is that the current one-month warning might not be enough warning time - unlike admin tasks, where there's always something to do, the need for 'crat actions is more intermittent, so I think that it would be possible for someone to get to the 23 month inactivity mark, get the warning, genuinely want to continue contributing as a 'crat, but then there are no 'crat chats/requests for (de/re)sysop/etc. for the next month. creffett (talk) 23:00, 24 April 2020 (UTC)

Every time there’s a resysop request. Just commenting “no issues” without acting would qualify. The two changes to what counts as activity are: getting rid of renames and getting rid of the “I am available for service” clause. The other change is moving three years to two. TonyBallioni (talk) 23:05, 24 April 2020 (UTC)
If commenting like that is sufficient, then no further complaints from me. creffett (talk) 23:07, 24 April 2020 (UTC)
Yep. Worded that way on purposes so as to make it easy while getting rid of some of the oddities of the existing policy. TonyBallioni (talk) 23:08, 24 April 2020 (UTC)
The new minimum qualifying activity can be fulfilled by typing four characters every 24 months, so I don't think the proposed changes address the primary motivation for the change.
Ironically, one of the most complicated and tedious bureaucrat activities - tending to bureaucrat inactivity - isn't considered a qualifying action unless it results in a log action. –xenotalk 14:12, 25 April 2020 (UTC)

Implementation if this passes

So I think the elephant in the room here is that we’d have one or two recent crats who are still crats by virtues of the current policy that says they can stay bureaucrats if they say they want to. From a human perspective I personally have a very hard time implementing this immediately for people who thought this month they were fine. My thought would be that it makes sense to have some sort of grace period after this passes to allow them reasonable time to return to activity beyond the 30 day notice. Maybe 60 days or something of that sort. Not opposed to longer or shorter, I just really want to avoid the feeling we are changing the policy on specific individuals, which I don’t think is something we want to be seen as doing. TonyBallioni (talk) 01:10, 25 April 2020 (UTC)

I'm not quite sure what you mean here; I thought you said we'd grandfather in previously qualifying activity so the first potential de-crat would be in 2021? -- King of ♥ ♦ ♣ ♠ 01:24, 25 April 2020 (UTC)
That was my original thoughts but I think the point above Bradv makes is good so this was in a way in a response to that. There’s a really difficult balance to walk here between being fair to individuals while also implementing what the community wants. I think grandfathering would be the easiest, but it’d also be the one that puts off community consensus for two years. Figuring out how to thread that balance is something we need to discuss. TonyBallioni (talk) 01:29, 25 April 2020 (UTC)
I think the clear precedent is what we did after we passed the stricter activity requirement for sysops. Following that we dropped 230 sysops. Best, Barkeep49 (talk) 01:46, 25 April 2020 (UTC)
(edit conflict) In my mind there’s a fairly large difference between an initial implementation when there was no previous criteria existed and there was a way to request back and one that happens after a criteria has been in place and that would only affect one or two people with no way to request back without an RfX. The latter is something that we should try to handle in a way that gives them a clear opportunity to show that they actually are available for service. TonyBallioni (talk) 01:58, 25 April 2020 (UTC)
The simplest solution here is to make the policy change take effect 30 days after the close of this RfC. That would allow 60 days for inactive crats to resume activity, and makes sure that the change the community wants actually takes effect in a reasonable time frame. – bradv🍁 01:49, 25 April 2020 (UTC)
Why 60 days? I would just give them 30 days, as if their last activity now-qualifying activity was exactly 2 years before the RfC passed. This is a RfC about setting consistent standards; all of this grandfathering is counterproductive. * Pppery * it has begun... 02:14, 25 April 2020 (UTC)
Because you don’t want to lose good people who might actually be trying to return but don’t have that much of a chance to contribute. Finding a middle ground where everyone can live with the timeframe is ideal. TonyBallioni (talk) 02:18, 25 April 2020 (UTC)
I agree with Tony and Brad, 60 days is good compromise between two years and immediately. Thryduulf (talk) 09:30, 25 April 2020 (UTC)
  • I'd back the 30+30 rule. 2 years seems excessively long, but I also feel immediate just risks damage with no appreciable upside. Nosebagbear (talk) 09:45, 28 April 2020 (UTC)
  • Question: What is the purpose of removing permissions to people who have not used them? What is the advantage of doing that? I mean, having more people with permissions is better than having less people. --NaBUru38 (talk) 20:06, 10 May 2020 (UTC)

Cecropia is Amazed

Back when the Bureaucrat role was first created by Jimbo for have an orderly way to handle Sysop requests, he said that he chose the term "Bureaucrat" because he felt it wouldn't be a title that people would find attractive, so there wouldn't be great competition to obtain it.

But maybe I suppose I shouldn't be amazed, nearly two decades down the road that some 'crats would become more bureaucratic in the traditional sense.

I'm not here to defend myself but one comment on my Talk Page from Chris Troutman is a little much (excerpted):

All userrights exercised on wiki are for the maintenance of the encyclopedia and are not trophies for once winning a popularity contest many years ago. The fact that your 'crat hat was removed for inactivity in 2014 and you asked for it back only to perform no work as a 'crat evinces your dishonesty. Please let me know if I'm wrong in my statement of facts. I now implore you to revert your edit at BN and ask for your admin hat to be removed until such time as your real life allows you to regularly contribute. I welcome your contributions and if you could actually be an active bureaucrat, that would be great. As it is, I ask that (per WP:HATSHOP) you not bring contempt upon the title "bureaucrat" in this manner. Chris Troutman (talk) 19:44, 24 April 2020 (UTC)

Trophies? Popularity Contest? "bring contempt." Do I really deserve these ad hominem attacks and violation of the principles of collegiality we had in the early days of Wikipedia. I'm disappointed. Cecropia (talk) 13:11, 25 April 2020 (UTC)

You do not deserve that and Silk Tork's suggestion of a way to honor with you and editors like you has sat very well with me. One of the most important sources of "new editors" we will have in the coming year are editors who were once active. I do hope you return to activity on the project as we need all the good editors we can get. Best, Barkeep49 (talk) 14:43, 25 April 2020 (UTC)
I don't think you need to worry too much about what that guy thinks. Reyk YO! 15:03, 25 April 2020 (UTC)
No you of course do not deserve such attacks. Speaking for myself (but I believe others are in the same camp) I would have wanted this two days or two years ago; you may have been a catalyst but no individual is the target for the good folks supporting this. ~ Amory (u • t • c) 16:49, 25 April 2020 (UTC)

Heh! Since some people have been throwing around figures, I can say that I did a lot in the early days of Wikipedia, including being a driving force in policies the community adopted. Since the issue came up, by 2011 I actively participated in and completed 411 promotions and closed additional RfAs and RFBs. The closest I know of was Taxman:Taxman, who promoted 170.

If I weren't 74 years old and still having to work full time I would be still be engaging actively in the community I enjoy. I'm pleased that after all this time there are still Wikipedians who remember me well. The way some are spinning their wheels on this subject you'd think I was asking for a pension. LOL! Cecropia (talk) 18:49, 25 April 2020 (UTC)

@Cecropia: One small point: criticism of your actions is not ad hominem. But yes, the evidence I presented brings your motives into question. Chris Troutman (talk) 01:09, 26 April 2020 (UTC)
Specifying what you think those motives are and turning them into specific accusations is ad hominem. Or playing with libel. It is one thing to bring up issues of opposition. To attack my character and attempt to bring me into disgrace is another thing entirely. Cecropia (talk) 14:01, 26 April 2020 (UTC)
Collapsing off-topic discussion. Mz7 (talk) 16:07, 27 April 2020 (UTC)
The following discussion has been closed. Please do not modify it.
Is that like, a legal threat? Govindaharihari (talk) 14:05, 26 April 2020 (UTC)
Quit stirring the pot. If Cecropia were making a legal threat, he would say as much. WaltCip (talk) 16:08, 26 April 2020 (UTC)
It looks like a legal threat to me, or at the least using a legal threat to quiet objections and I feel it is not stirring the pot to request him to clarify, thanks Govindaharihari (talk) 16:11, 26 April 2020 (UTC)
I do not think it helpful or respectful to suggest someone who served the project ably and is already under criticism whether they are making a legal threat because they happened to have mentioned the word libel. Best, Barkeep49 (talk) 15:40, 27 April 2020 (UTC)
Criticism of actions is not necessarily ad hominem, but doing so with accusations of "dishonesty" and using language like "I ask ... you not bring contempt" is unquestionably ad hominem, uncivil, and needlessly incendiary. I would love to be part of a community where people who happen to phrase their strongly-felt concerns in such a way realize on further reflection such discourse is damaging and withdraw it, rephrase their concerns, and apologize. Martinp (talk) 22:42, 28 April 2020 (UTC)

We should just grandfather Cecropia from this new policy due to how long he has edited Wikipedia Tsla1337 (talk) 00:38, 28 April 2020 (UTC)

No, the entire point of this policy change is to not grandfather users. * Pppery * it has begun... 00:48, 28 April 2020 (UTC)
No, That really would be a stupid idea and I would go as far as to say that would make this whole proposal utterly pointless. If you fail the requirements set out above then you should be booted. –Davey2010Talk 01:27, 29 April 2020 (UTC)

If this is voting on a policy change and I have been at the center of some of this it seems to me to be an exercise in ex post facto policy. Cecropia (talk) 18:59, 29 April 2020 (UTC)

Perhaps some individual with the authority to do so will let me know what the Star Chamber decides. (Before we have another uproar, that was sarcasm, if I'm allowed) Cecropia (talk) 19:02, 29 April 2020 (UTC)

Cecropia, I remember you fondly, not least for the +sysop back in 2005. Hope to see you around more, in any capacity. Best wishes, El_C 23:19, 29 April 2020 (UTC)
Thanks much El_C. Kind words are appreciated now. After reading some more on WP:BN Cecropia (talk) 19:28, 30 April 2020 (UTC)
  • Regardless of whether this proposal is successful or not, you're objectively unqualified to be a sysop by current standards, much less a bureaucrat. You are merely grandfathered in. This is the most highly-privileged and highly restricted permission on one of the most significant websites of all time. You have not logged an admin action since 2008. You have not logged a bureaucrat action since 2008, with the exception of one 2017 crat chat comment, and one BN comment replying to the objection of your crat chat participation, stating that you're not sure why your "participation on Wikipedia is of current interest". Are you kidding me? At that time, you were defended on BN based purely on your 2016 statement that you would return to activity. Well how great did that turn out! You have literally not been active since 2008, not even as of this year. Get real, you're not a crat after a decade of inactivity based on merit, but because of lax activity requirements that allow you to game your retention of the tools, nothing more. The fact that you have the hubris and brazenness to create a subthread stating your shock at the backlash you caused just reflects how completely out-of-touch you are with the community. No one on this site is afforded the unenforceable shoulder-shrugging that the few remaining "relic crats" are. But hell, the fact that you can start a thread complaining about how much of a victim you are is pathetic. Have some pride. Have some honor. Go re-run RfB if you're so convinced you're worthy of it. Don't provoke a policy change proposal purely in reaction to your own cratship, and then have the audacity to start a subthread about how you're "amazed" by the response. No apparently-unqualified "relic crat" has ever proved my concerns about them wrong, and you're upholding that legacy spectacularly. ~Swarm~ {sting} 02:46, 7 May 2020 (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.

RfC: proposed creation of new usergroup

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
This proposal is unsuccessful. Many editors acknowledged there were legitimate issues that motivated this proposal, including lengthy delays associated with updating and correcting errors on the Main Page. However, there were also a variety of objections. Many editors rejected the idea of giving users full access to the editprotected and protect toolsets without full permission to use them, arguing that it would pose an unacceptable risk to give users more technical ability than they are trusted to handle. Some editors also believed that such a system would be unnecessarily complex and may lead to "instruction creep", and others voiced security concerns, particularly with respect to increasing the attack surface for account compromises. Additionally, even if it were technically possible to unbundle only the ability to edit the Main Page, there were also editors who argued that, because of the critical importance and high visibility of the Main Page, the ability to edit it should also be limited only to administrators. Respectfully, Mz7 (talk) 07:33, 24 May 2020 (UTC)

This is a proposal to create a new usergroup, main page editor, as documented at Wikipedia:Main page editor. In brief, members of the new usergroup will be given the editprotected and protect user rights, which allows editors to edit pages transcluded onto the main page through full and cascading protection. This will allow editors with this permission to update content on the main page, and to fix errors on it. Details of the proposed mechanisms to grant and remove the right, and restrictions on its use, are at Wikipedia:Main page editor. If this request is successful, a phabricator request will be initiated, and once completed, Wikipedia:Main page editor will be changed from a proposal to a policy page and appropriately updated.

  • Note: if phab:T71607 is ever actioned, the protect userright would be replaced with editcascadeprotected.

Vanamonde (Talk) 20:26, 23 April 2020 (UTC)

Rationale
  • Wikipedia frequently has a shortage of administrators willing and able to perform tasks related to main page content. This results in updates to the main page being delayed, or in errors on the main page persisting for long periods of time.
  • A number of non-admin editors have long track records working on content related to the main page. These editors often are experts in project policy, are trusted contributors, and are fully capable of performing administrative tasks related to the main page, but are unable to do so, because editing the main page (and the subpages transcluded onto it) requires administrator permissions. Many of these users are uninterested in running for adminship because they would not use other tools. Many others do not have the wide experience necessary to pass an RFA.
  • Therefore, allowing trusted, experienced, willing non-admins to hold the rights associated with the new "main page editor" user group would increase the number of editors committed to main page projects who are able to perform these tasks, and also decrease the workload of admins. Updates to the main page can be made in a more timely fashion and errors corrected more quickly.
Technical background

The main page is currently full-protected with cascade protection. This is unlikely to change anytime soon. The various sections of it are transcluded onto the main page, and are therefore also cascade protected. The ability to edit cascade-protected pages requires "protect" permissions due to the current software design. Editing these sub-pages therefore requires the edit-protected and protect permissions, which are currently only locally available to admins. While it is technically possible to split the edit-cascade-protect and protect flags, efforts to do so have been pending developers since 2017.

Addressing potential concerns
  • Risk to other protected pages. Although users in this group will have the technical ability to protect and unprotect pages, this proposed policy explicitly states that they may not do so, and that using their rights to modify protection levels would be grounds for removal from the group.
  • Risk to the main page. This right will only be open to editors with a proven track record at the main page, who have proven their commitment to the project and their understanding of policy there. Even if someone should go off the rails or have an account compromised, the main page has over 114,000 watchers, over 4000 of whom have visited recent edits, and the proposal allows for requested revocation by any user in good standing and emergency revocation by any admin. Editors who disrupt the main page are likely to be brought to administrator attention very quickly. Additional risk to the main page is therefore minimal.
  • Potential difficulty of revocation. Under this proposal, any user in good standing can request revocation of membership in this usergroup from any other user, and administrators may revoke it without prior notice in case of active disruption to the main page. Furthermore, the process for removal intentionally does not require a numerical threshold, but a consensus that the editor in question will not abuse the right; therefore, in the presence of substantive concerns, the removal of membership should be straightforward.

Vanamonde (Talk) 20:26, 23 April 2020 (UTC)

Survey (proposed creation of new usergroup)

  • Support, as one of the drafters. Calls for assistance with the main page are frequent, and there are rarely enough admins on hand to address them. Vanamonde (Talk) 20:26, 23 April 2020 (UTC)
    Pinging those users either involved with drafting this, or whose opinions were solicited during workshopping as experienced editors working with the various main page sections, or who came to the page to opine from other venues. I will also post notifications to the discussion pages for the various main page section.@Valereee, Xaosflux, Maile66, Dank, David Levy, Mike Christie, DannyS712, Xeno, Wugapodes, Winged Blades of Godric, MGChecker, Jo-Jo Eumerus, Coffeeandcrumbs, Cwmhiraeth, Mandarax, Tryptofish, BlueMoonset, Yoninah, Amakuru, Gatoclass, Casliber, Sca, Masem, MSGJ, Stephen, Killiondude, Jayron32, and Hut 8.5:; @Bagumba, Kees08, Art LaPella, Floquenbeam, Howcheng, Khajidha, Gerda Arendt, Ravenpuff, Serial Number 54129, Alanscottwalker, Ritchie333, Davey2116, 331dot, Zanhe, LaserLegs, Banedon, Nixinova, Martinevans123, Ad Orientem, SoWhy, Shubinator, Modest Genius, Pawnkingthree, Pawnkingthree, Kusma, WaltCip, and Gog the Mild: Vanamonde (Talk) 20:26, 23 April 2020 (UTC)
  • Oppose Groups that have far greater technical permissions than social permissions are a bad idea. * Pppery * it has begun... 20:50, 23 April 2020 (UTC)
    @Pppery: Please explain. Chris Troutman (talk) 22:51, 24 April 2020 (UTC)
    I don't think this really needs much explanation, given that so many other users have opposed, but I'll answer anyway: I've seen several times that the social permissions of a group tend to drift to match their technical permissions. Here's one example, I view the problem as more widespread. * Pppery * it has begun... 23:02, 24 April 2020 (UTC)
  • Oppose sorry to do this, but this would defeat the entire point of full protection existing. The reason this proposal always fails is that the unbundling of full protection is a bad idea because it enables people who care a lot about content and are extremely unlikely to be blocked for edit warring to edit through full protection. Unbundled permissions are extremely difficult to remove, probably harder than desysoping, and if there is abuse I don’t have confidence it will be removed and not restored, especially because of how small the number of people who work in this area are. If someone is trusted enough to edit through full protection on the main page, they should be trusted enough to pass RfA. We’ve had people in the last year pass with this as a rationale, so I see that as a valid avenue that would be preferred. TonyBallioni (talk) 21:11, 23 April 2020 (UTC)
    @TonyBallioni: You don't really have to apologize; as I see it this is the best way to deal with the chronic delays at ERRORS, ITN, DYK, etc; if the community doesn't want it, I'm satisfied in the knowledge that I've done my best to fix the problem. But FWWI: I agree that editors who could be trusted with this permission generally ought to be admins. The trouble is they don't want to.. You're more than welcome to try to persuade them, but I doubt very much that you'd be successful. Vanamonde (Talk) 21:23, 23 April 2020 (UTC)
  • Weakly oppose. Per my comments below I can see the justification for this proposal, but I think it will create more problems than it solves. The difficulty in getting changes made to the main page is a feature, not a bug. Most editors don't particularly care about the main page, so the sort of people who are likely to want to apply for this are going to be either self-taught grammar pedants demanding that Wikipedia apply some rule they're misremembering from school, the more disruptive elements from DYK upset that those pesky admins slow things down by fact-checking their errors before we let the queues go live, and nationalists on a crusade to "correct the bias" at ITN. These are exactly the people we don't want having the ability to edit through protection. As per Izno and TonyBallioni, the ability to edit a page that averages 10 million readers per day isn't a relatively trivial feature like rollback but one of the most sensitive tasks on the entire project, and while I do support the principle of unbundling this is one of the jobs which should be left to admins. (I would actually be much more likely to support the unbundling of protect and editprotected if we excluded the main page from it.) ‑ Iridescent 21:37, 23 April 2020 (UTC)
  • Strong support It fills a very clear need and will help reduce serious backlogs. The main bottleneck at WP:DYK is moving preps (unprotected) to queues (full and cascade protected). At WP:ITN this permission would increase the number of regulars who can action discussions. The downside is we have to trust the granted editors not to do prohibited things. This should not be a big barrier because we do this all the time with user groups. We already have to trust that extendedmovers will not use suppressredirect contrary to deletion policy; we already trust that templateeditors will not be reckless in editing high-risk templates; we already trust that editors will act in good faith and not vandalize. Like many other parts of this encyclopedia, this proposal relies on meatball:SoftSecurity, and so we should evaluate whether the criteria can meatball:LimitDamage effectively. I believe it will. The criteria for granting are appropriately strict, requiring a request and consensus (and importantly not at admin discretion). The criteria for revoking are appropriately lax, requiring a single unauthorized act or community consensus. The prohibitions on use are bright lines, making ambiguous cases resulting in an untrustworthy person retaining the right unlikely.
    The checks and balances of the proposal are well constructed to make this a clear net positive on its own merits, but if it goes well, it creates the possibility for further improvements in other areas of policy. For example, template protection was created as an alternative to full protection for high risk templates. It is in the projects interest to have technically capable editors able to edit high-risk templates, but the proliferation of protection levels has been a consistent problem. If this proposal is enacted and goes well, it presents the opportunity to consider consolidating our protection schema by extending editprotected to template editors and thus eliminating the need for template protection. Another example is that it may help recruiters identify more strong RFA candidates and resolve the low number of admin recruits while simultaneously reducing the demand for admins in certain areas. It tackles the problem from both sides. The proposal would be a big change, and big changes are scary, but they also create opportunities for us to reconsider long-held assumptions and catalyse improvements elsewhere. On its own merits, it is a solid proposal, and it brings with it the possibility for future improvements in other areas. For me, that is the hallmark of a good idea, and so I support the proposal as a net positive. — Wug·a·po·des​ 21:45, 23 April 2020 (UTC)
  • Oppose any regular at ITN who wants to be an admin can simply apply, and except for the occasional RD that dies on the vine that section doesn't have a backlog to contend with. No comment on DYK I have no idea how that section works. --LaserLegs (talk) 22:25, 23 April 2020 (UTC)
  • Weak oppose as I'd rather see this get fixed with phab:T71607 - and then we can have a group that is allowed to edit protected pages. — xaosflux Talk 22:36, 23 April 2020 (UTC)
    To expand on this, I'm not opposed to creating a group that has the ability to edit protected pages, without being able to actually manage the protection; but with cascading protection this isn't currently possible. I'm not very worried about someone with such a new group being able to "protect" something be nature of transcluding it on a page with cascade - and this would be more of a positive than a risk I would think -- as inappropriate use could swiftly lead to access removal. — xaosflux Talk 16:13, 24 April 2020 (UTC)
  • Weak Support: Full protection is "sysop protection". This is counter-intuitive. The only solution I see to the counter-intuitiveness is to create a new protection level designated for main page and this purpose. {{replyto}} Can I Log In's (talk) page 00:17, 24 April 2020 (UTC)
  • Oppose I generally don't think we need more usergroups, and in particular, if we want to "unbundle" protection from sysop, I don't think this is the right way to do it. (And I don't think we should do it at all.) ST47 (talk) 00:59, 24 April 2020 (UTC)
  • Oppose per WP:CREEP as this would be additional complexity. As the issue is particular to the main page, it would be more sensible to try adjusting the protection level for that page, such as reducing the protection level to ECP with pending changes. Those are existing features and so no development would be required. Andrew🐉(talk) 10:27, 24 April 2020 (UTC)
  • Oppose - I am extremely uncomfortable with any change which includes phrasing to the effect of "this will let you do (X) but we're telling you not to do it" - as Pppery mentioned above, that's a social control on a technical capability. creffett (talk) 12:34, 24 April 2020 (UTC)
    Additionally: I'm also very uncomfortable that this would give users in the "main page editors" group the ability to edit any fully-protected page. Again, a case of "you can do it but we're telling you not to" - goes against the principle of least privilege (thanks for linking that below, Pppery, I couldn't remember the name) as a privilege that is way too broad compared to the small task it's needed for. creffett (talk) 23:20, 24 April 2020 (UTC)
  • Support as one of the drafters. There are multiple workers at main page who don't want to be admins, they just want to help. —valereee (talk) 13:41, 24 April 2020 (UTC)
  • Oppose. It's not supposed to be easy to edit through full protection. Also, people will regularly cite WP:IAR to violate the policy. NinjaRobotPirate (talk) 13:53, 24 April 2020 (UTC)
  • Oppose primarily for two reasons: unbundling should be based on the technical right itself, ad-hoc rights will be very prone to misuse given that even technical permissions are abused for which a need was already established. By granting ad-hoc rights with "please don't do this attached" is almost a sure-shot way or shooting ourselves in the foot — especially because Main Page is the most important and public-facing page that we have. Compromised accounts frequently tend to have some kind of fascination with the Main Page and opening up more accounts to edit through full protection (who are only supposed to edit the Main Page) is an inherent security risk. --qedk (t 愛 c) 17:11, 24 April 2020 (UTC)
  • Oppose – this is a problem specific to DYK and ERRORS. As for ERRORS, clearly proposed and non-contentious changes tend to get acted on quickly. I have seen some suggestions get ignored if the change is not clearly necessary and if the proposer has a reputation for being argumentative and unwilling to compromise (this is not meant to say that you fit in this group if you have ever had this happen). Iridescent summarizes this concern better than I did. DYK does have a problem where there is not enough admin time available to meet the admin demand. I think there are better solutions than throwing more people at the issue, such as reducing the number of approved hooks in some way (disallowing GA entries, increasing minimum size, increasing minimum expansion, a 'selection pool' with more hooks in the pool than will be selected so the least interesting get dropped off after X period of time), reducing what we expect of admins when moving to queue (if another check is still desired, a second approver can be added to the prep process; better tools; better instructions), and improving the workflow (dynamic preps/queues so we can get further than 6 days ahead). While many of those possible solutions will have opposition to them, I firmly believe that the DYK process needs a large overhaul and not a bandaid solution. I understand not wanting to do an RfA, but if you cannot handle the stresses/criticism of an RfA, I am not sure you would be able to handle the stresses/criticism that come with main page work. At least in my experience, the latter is much more stressful. I would consider this proposal if other solutions to solve the issues at DYK are attempted. Kees08 (Talk) 17:16, 24 April 2020 (UTC)
You bring up a good point about WP:ERRORS. Not all of them are exactly errors, but sometimes style, sometimes MOS:ENGVAR, or a suggested rewriting of the hook itself. And at times ... and this has happened to me as an admin ... if you quickly correct what has shown up on WP:ERRORS, someone else posts with an opposing opinion of whether or not the change should have been made. — Maile (talk) 18:21, 24 April 2020 (UTC)
  • Support There are frequent backlogs at ITN and DYK, and a number of experienced editors at both projects who would be unlikely or unwilling to become admins, but nevertheless could be trusted with these limited responsibilities.-- P-K3 (talk) 17:58, 24 April 2020 (UTC)
  • Oppose Per QEDK; risk of compromises to other pages outweighs the benefits IMO. We need more admins to assist with main page items, but I don't think the level of trust required to give people these technical abilities is less than the trust needed to become an admin. SpencerT•C 20:04, 24 April 2020 (UTC)
  • Support Un-bundling is always a good idea. Adminship is the ban-hammer and hence RfA is very political. Gnomish editors working Main Page to have this need for tools but might not be well-rounded enough to please the folks at RfA. I can see why some admins don't want to lose the power of full protect that they currently enjoy but that's the price for not working the backlog fast enough. Chris Troutman (talk) 22:49, 24 April 2020 (UTC)
    I ran for RfA specifically stating that I intended to help with the DYK admin work, duties which people are now complaining that there are not enough admins to perform. That argument was rejected by the RfA, as is what you are saying, and using an unbundled bit would be prohibited as doing an end run around RfA. RfA is political and I was nor rejected for not being well rounded. Hawkeye7 (discuss) 23:36, 24 April 2020 (UTC)
With respect, Hawkeye, anyone can look at the opposition in your RfAs and see they failed because of concerns about your behavior. It's disingenuous to say the community rejected your request to help at DYK as invalid. ~Swarm~ {sting} 04:41, 25 April 2020 (UTC)
  • Support – In the past few months, especially on the weekends, the main page has come to down to minutes away from a complete disaster. Situations in which there have been many experienced non-admins that know how to solve the problem and none of the available admins know how. There are also instances in which an admin makes an error that leaves the main page at risk of serious vandalism for several minutes because of an admin's action and I have avoided reporting to ERRORS for fear of exposing the vulnerability. (Note that the ITN image right now is not at WP:CMP, which means that for up to 10 minutes it was open for vandalism.) These are the minuscule things that most admins do not understand but experienced main page contributors do. --- C&C (Coffeeandcrumbs) 23:23, 24 April 2020 (UTC)
  • Weak oppose While I respectfully disagree with Iridescent's concerns and Kees08's seconding thereof, I don't think the possible technical hurdles counteract the benefits, nor is this a particularly needed unbundling. – John M Wolfson (talk • contribs) 00:21, 25 April 2020 (UTC)
  • Oppose: When I read the title, I thought this is about reducing the security risk of >1000 administrators having the unused but dangerous permission to edit the most frequently visited page on one of the most frequently visited websites in the world. On the contrary, the proposal is about increasing the risk. Never. ~ ToBeFree (talk) 00:49, 25 April 2020 (UTC)
  • Support, in principle. The Main Page does not have enough contributors with the knowhow, and the requirements for adminship are too high and broad. But we shouldn't give the new group the permission to protect pages, or to edit fully-protected pages; rather, we should create a new cascade-like protection level specifically for the Main Page and its subpages, perhaps bearing a light yellowish-orange color. The end result would be a user group similar to the template editor permission, who edit high-risk templates like {{Infobox}} that likely receive just as much exposure, if not more, than the Main Page. –LaundryPizza03 (dc̄) 03:03, 25 April 2020 (UTC)
  • Oppose - I'm a generally a big proponent of creating more extended privileges, but not in this case. Unacceptable risk vs reward. We're talking about the front page of one of the largest and most important websites of all time. It could be argued that the ability to edit the main page is the most importantly-restricted privilege an admin has. If the community cannot deem someone trustworthy enough to pass RfA they should sure as hell not be able to edit the main page. Secondly, I don't see the need. I monitor ERRORS, it has ample participation and is never backlogged. I haven't worked at ITN/C in many years, but looking at it now, it still has ample participation and no backlog issues. ~Swarm~ {sting} 04:35, 25 April 2020 (UTC)
    I think the problem is not that users run RFA and fail, the problem is that they refuse to run RFA.--Ymblanter (talk) 17:26, 25 April 2020 (UTC)
You won't find anyone who acknowledges this more than me; I once led an RfA reform project. However, even given the flaws of RfA that dissuades participation, I entirely reject the notion that editors wishing to modify the main page should be subjected to anything less than the standard community confirmation process for administrator permissions. I would sooner advocate for unbundling the block tool. ~Swarm~ {sting} 04:51, 28 April 2020 (UTC)
  • Weak Support for the reasons described by Coffeeandcrumbs and the nom. That said, I'm observant of the concerns raised by Swarm. Chetsford (talk) 05:07, 25 April 2020 (UTC)
  • Oppose there are no ‘chronic' delays at ITN or Errors for unambiguous errors. We don’t need more people rushing in and fixing more nuanced issues that warrant extended discussions. Stephen 09:18, 25 April 2020 (UTC)
  • Oppose per the above arguments of this increasing the risk for vandalism of probably one of the most-visited pages on the Internet. SemiHypercube 19:18, 25 April 2020 (UTC)
  • Support. I'm someone who comments on a problem that I see on the Main Page maybe once or twice a month. There is often a delay of several hours before anyone acts on or responds to my comments, sometimes nobody responds, or only some other non-administrator adds an agreement. I don't mind too much, and perhaps sometimes my comment really is too trivial to bother with, but it is frustrating and does incline me not to bother next time. I know that one solution is to check a day in advance, which I do sometimes, but even then the problem may remain unaddressed until the page is live (particularly with POTD). There do seem to be other non-administrators around with the necessary skills and sense of balance who could solve this issue very well if they were given the tools. It wouldn't need that many more sets of eyes, perhaps 10 or 20, to make a huge difference. Jmchutchinson (talk) 21:35, 25 April 2020 (UTC)
  • Oppose primarily per TonyBallioni, xaosflux and Swarm. Callanecc (talk • contribs • logs) 06:24, 26 April 2020 (UTC)
  • Oppose It just adds another bureaucratic layer and duplicates what already exists. How do you find this small handful of GF main page nominees, who are going to stick around when the going gets rough, or until they just get bored? How many have run for admin only to eventually shift their efforts away from the reason they originally wanted the tools? People are people, and a new user right is not going to guarantee they would be more effective, or stick with it, any longer than the current admins. — Maile (talk) 14:19, 26 April 2020 (UTC)
  • Oppose: We already have a means of allowing users to edit the main page: RfA, where the community exercises its right to examine a candidate. I don't see a reason to change this. Sadly, if this proposal passes, it would just contribute to an ever-increasing bureaucratic bent on this site. — Javert2113 (Siarad.|¤) 18:02, 26 April 2020 (UTC)
  • Support: there are not enough eyes on the technical maintenance of the main page. While I believe ERRORS and co are often overzealous in their aim to interfere with content that has passed normal approval processes, and I understand the damage that edits with this right could do were they to act maliciously, I am much more worried by the realistic prospects of a DYK queue minutes away from being loaded onto the main page being empty, or an objective factual error being present on the main page for hours. With a community process required, and only trusted editors experienced in Main Page content standing a chance of passing it, I do not believe we have any non-trivial risk of a user misusing these permissions, which would be a bright-line situation that could be remedied as soon as anyone noticed it; rather, it is admins who abuse their protection privileges because they have much more subtle ways to do so. — Bilorv (talk) 20:32, 26 April 2020 (UTC)
  • Oppose I understand the reasons behind this proposal, however, the main page has hundreds of millions of views per month. The more accounts who can edit the main page only increases the risk that one (or many) of these accounts will be compromised and the main page then vandalised etc. As it has been said above, the main page is probably the most important page on this site. It is the primary gateway to any visitor who does not use a search engine to access Wikipedia, and is the page which probably most people looking to browse or visit for the first time go to. RfA is the best way we have to determine the trustworthiness of a user and whether they should be given advanced rights, including editing protected pages. Although editing fully protected pages is probably less of a big deal than the block button (for the purposes of editors), editing fully protected pages in my opinion is the right that a administrator has which would cause the most damage for the reader. A reader won't probably notice or care that they if they are blocked by a compromised account, but will most likely notice a vandalised main page. Therefore users who can edit the main page and transcluded subpages should be trusted by the community enough that they could become sysops. Therefore, I would argue, any process for granting this right should be similar to RfA as the community would want to trust the user as much as they would if they were going to support them for adminiship. So, having this user right seems a bit moot, as the user might as well go for RfA. Therefore I would argue that editing the main page and by extension editing fully protected pages is something which should remain only possible by sysops. Dreamy Jazz 🎷 talk to me | my contributions 21:02, 26 April 2020 (UTC)
  • Oppose per Tony and NJP - IMHO it'll create more problems than it solves and like NJP says someone somewhere will invoke IAR, If you want to edit the main page then start an RFA. –Davey2010Talk 12:27, 27 April 2020 (UTC)
  • Strong opppose - while a good idea in principle, the implications make this a no-go. I'm fairly certain everyone else who has opposed has already hit on points I would have brought up, so I won't reinvent the wheel here - but in short, having non-administrators being able to edit the Main Page is a bad idea, as if that isn't bean bait I don't know what is. Kirbanzo (userpage - talk - contribs) 16:57, 27 April 2020 (UTC)
  • Support it's pretty obvious we have limited resources, more so these days than ever before, and in my mind there's a clear delineation in regular editors who would risk the integrity of the project and those who most certainly would not. I speak from personal experience as someone who has tried (and failed often) to keep the main page up to snuff, both as an admin and a regular editor. Some admins like the technical stuff, deletions, blocking etc. But many admins shy away from content related issues, and the main page is just where that kind of oversight is required. This proposal looks doomed to fail, but those opposing it perhaps aren't as acutely aware of the issues as some of the rest of us. I see no problems with this approach ... how many admins have gone rogue and deleted the main page? None. How many errors, poor links or unprotected redirects have been featured on the main page? Daily. A class of user between full admin and template editor is a no-brainer. It can be switched on and off at will by admins. If someone (like me, for example) can demonstrate a complete 100% dedication to the content aspects of Wikipedia yet still can't be trusted to fix chronic errors on the main page, the community has been corrupted. The Rambling Man (Stay indoors, stay safe!!!!) 21:55, 27 April 2020 (UTC)
    how many admins have gone rogue and deleted the main page? One. —⁠烏⁠Γ (kaw) │ 04:40, 28 April 2020 (UTC)
    more than 1... see [3] Mdaniels5757 (talk) 01:33, 2 May 2020 (UTC)
  • Support Per lots of wise people above. --Dweller (talk) Become old fashioned! 12:26, 28 April 2020 (UTC)
  • Oppose for as long as editprotected controls not only editing protected pages, but also creating salted articles and moving move protected titles. These need to be unbundled, and then we can create user groups for those who need only one of these privileges (anyone who needs 2 or more should go here instead). Iffy★Chat -- 12:56, 28 April 2020 (UTC)
  • Oppose for many of the reasons above, especially the technical overhead and instruction creep involved for such a niche set of tasks, and the lack of a rigorous vetting or oversight process for "unbundled" permissions like this. We have over a thousand administrators, and most admin processes are rarely backlogged. If DYK and ERRORS are experiencing problems, perhaps it's because there is something about those processes that put people off, rather than a lack of warm bodies with the right bits? – Joe (talk) 14:13, 28 April 2020 (UTC)
  • Oppose - While I might support editprotected as part of a user-right group of various other editing tools, after several community-wide discussions, I find I don't disagree with those who suggest that protect and block are intrinsically linked when it comes to handling disruption. This should not be split out as a separate user-right group. - jc37 06:42, 29 April 2020 (UTC)
  • Oppose per TonyBallioni, Iridescent and others. As an admin regularly involved with the main page myself, I do acknowledge the issues that the nomination here raises, and yes admins do have a lot of work to do and there are sometimes longish gaps between error reports and things being fixed. It's also true that there is a group of editors highly versed in main-page lore who regularly groom the queues and request changes at ERRORS - their work is highly valued. However I don't think the problem is a big enough one to warrant lowering the bar. This in turn means a much larger group involved with editing the main page, and would IMHO bring more problems than it solves. As Iri notes, keeping this group small avoids petty disputes and main page edit wars flaring up. The level of frivolous and POV edits would likely go up too. I've seen two main reasons why these editors don't go for RFA - one is that they don't want the additional workload and pressure, for example DYK prep builders who prefer to leave the queue promotion and checking to someone else; and the other reason is people who don't think they'd pass an RFA for one reason or another. The first group presumably don't need or want main page rights for precisely the reason they don't want adminship, while with the second group, unfortunately for me if someone wouldn't pass an RFA, then I don't personally think that person should be editing the main page.  — Amakuru (talk) 09:17, 29 April 2020 (UTC)
  • Oppose per TonyBallioni and Iridescent.Pharaoh of the Wizards (talk) 08:30, 30 April 2020 (UTC)
  • Oppose, no evidence that this is an actual problem. Stifle (talk) 09:24, 30 April 2020 (UTC)
  • Oppose per pretty much all the opposes above. Unbundling is mostly a good thing, but it's not always a good thing, and it certainly isn't in this case. Editing the main page is definitely something that needs the two step process of proposal and review. Boing! said Zebedee (talk) 01:36, 2 May 2020 (UTC)
  • Strong Support mainly per Wugapodes; there are only two or three admins active at dyk to my knowledge -- as the most viewed page, we should have everything be up to date there. --Puddleglum2.0(How's my driving?) 02:05, 2 May 2020 (UTC)
  • Oppose with regret, an obviously good faith proposal. I salute the many editors who worked on the idea, but there are just too many potential pitfalls here. Most have been covered by others but among those that stand out in my mind, are enlarging the pool of editors with the ability to edit one of the most trafficked pages in the world with inadequate vetting. It increases the potential for serious disruption to an unacceptable degree. I am also not wild about the idea of handing someone a very broad tool that would allow them to edit even fully protected pages in the mainspace and then saying "but you aren't allowed to do that." -Ad Orientem (talk) 02:06, 2 May 2020 (UTC)
  • Oppose someone trustworthy at this level (editing the main page) should have to pass RFA. Royalbroil 03:25, 2 May 2020 (UTC)
  • Oppose per TonyBallioni and Royalbroil. I simply fail to see a need for this. Anarchyte (talk • work) 05:02, 2 May 2020 (UTC)
  • Oppose as unnecessary. Anyone I would trust with this I would also trust for admin, so they might as well be vetted properly and go for the whole toolset in order to be even more helpful without the risks. -- Tavix (talk) 05:17, 2 May 2020 (UTC)
  • Oppose. The main page is our face to the world. If there is one place editors should go through an RfA-type process before they're allowed to mess with it, this is it. As I understand this proposal, the procedure for obtaining this right is very lightweight, and therefore inadequate. It needs scrutiny by the community in depth before granting, and that's what you get at RfA. If RfA is a problem for this task, then it has wider problems as well and it's RfA that needs improving, not yet another unbundling of user rights. SpinningSpark 08:13, 2 May 2020 (UTC)
  • Oppose, per lots of wise people above, especially TonyBallioni, Iridescent, Swarm, and Boing! said Zebedee to name but a few. One of the reasons Vanamonde93 omits in their Many of these users are uninterested in running for adminship because they would not use other tools. Many others do not have the wide experience necessary to pass an RFA, is that a large number of trusted users of the right calibre won't come forward because they are not prepared to run the gauntlet of the RfA system that is partially run by users who are determined to maintain it as the one venue where they can be as abusive as they like with total impunity.This ad hominem at a respected and trusted group: it is admins who abuse their protection privileges because they have much more subtle ways to do so by Bilorv probably does not foster good spirit where Wikipedia's working environment is beginning to show noticeable cracks. Kudpung กุดผึ้ง (talk) 08:23, 2 May 2020 (UTC)
  • Support. There is a clearly stated and evidenced problem that needs fixing, and this proposal would fix it. I've read the oppose votes and of those that are not philosophical oppositions to unbundling (not something that is really related to this proposal) or based on problems with RFA (not really relevant) there are none that I've seen that would not be solved or prevented by just not giving this right to anyone who is not suitable for it. e.g. if you don't trust someone who requests this not to push their POV then simply oppose their getting the right. There is no reason why the requests need not be as thorough as RFA. Thryduulf (talk) 11:40, 2 May 2020 (UTC)
  • Oppose, everybody who is trustworthy enough to edit the Main Page is trustworthy enough to be a sysop. Alternatively, automatically promote all Main Page editors to sysop if they have kept the right for a month. —Kusma (t·c) 11:52, 2 May 2020 (UTC)
  • Oppose. I understand the perceived need behind this proposal but I agree that it would probably create more problems than it solves. Granting such a right to essentially be able to deface the Main Page should require a discussion whether the editor is trustworthy enough but then why not have them run for RFA instead? The only area where I can see a reason to have non-admins be able to influence the main page is DYK but for that area, there is a more practical solution (which I had previously suggested) by having a queue that non-admins can edit ("emergency queue") but which the DYK Updater bot will only process if it detects the signature of someone on its allowed-list in the {{DYKbotdo}} template. It's a far easier solution than creating a new userright and a potential process to grant it. Regards SoWhy 15:58, 2 May 2020 (UTC)
  • Oppose To echo many of the comments above, the benefit is not worth the risk. To echo many of the other comments above, I'm not convinced that there's a benefit to begin with. The Squirrel Conspiracy (talk) 00:36, 5 May 2020 (UTC)
  • Oppose I do not feel that there is a great need for this right. The English Wikipedia has 1,140 Administrators at this time and one of the main responsibilities of a sysop is to protect pages. As many users above have said, the benefit is not worth the risk. -Examknowtalk 21:22, 8 May 2020 (UTC)
  • Oppose Just leave the task to the admins. While the user right seems reasonable, it may be prone to abuse. There are several places where other users may propose changes to the content of the templates that are transcluded in the Main Page. It is more important that concerns on such places are acted upon as soon as possible in order to avoid backlogs. LSGH (talk) (contributions) 17:26, 10 May 2020 (UTC)
  • Oppose per WP:CREEP. The solution to the "we don't have enough admins." problem, if there is such a problem, is obvious and is not this. UnitedStatesian (talk) 03:16, 16 May 2020 (UTC)
  • Oppose until there's a way to edit cascade protected pages without having the protect right. Such tool should only be restricted to admins who is trusted by the community. Don't have enough admins (despite having a thousand of them)? Recruit more! --Pandakekok9 (talk) 05:04, 17 May 2020 (UTC)

Discussion (proposed creation of new usergroup)

  • I can see the merits of this, but I'm highly sceptical of requirement 1g (Working to fix mistakes on the main page at WP:ERRORS) as one of the grounds for this being granted. While there are a lot of fine people there, WP:ERRORS has traditionally been one of the parts of Wikipedia most infested with POV-pushers, cranks and people obsessed with pushing some prescriptive form of grammar or other. (For decency's sake I won't name names, but anyone who's had the page watchlisted for any time will be aware of the issue.) I have a suspicion this is going to set up potential for a lot of bad feeling, as we either give out this new right to people who we know are likely to abuse it, or have a lot of awkward "thank you for your service but everyone thinks you're untrustworthy" conversations which in turn leads to resignations (or even grant-strip wheel-warring which will understandably upset the editor involved even more). Has any consideration been given to a more thorough process than "post at Wikipedia talk:Main page editor—a page which currently has only 22 watchers—and try to time it such that in 24 hours one of your friends will be watching and waiting to flip the bit?" We already have a perfectly good Wikipedia:Requests for permissions page which gets the eyes of considerably more neutral parties. ‑ Iridescent 20:43, 23 April 2020 (UTC)
    @Iridescent: I agree with your first concern, but that is among the reasons there's a more elaborate process being proposed for granting and removal than a request at WP:PERM. And that's also a reason not to leave it to the discretion of a single admin who would have to make an awkward decision; concerns can be raised by anyone. Yes, WT:MPE has 22 watchers, but the process requires cross-notifications at noticeboards that between them probably have in excess of two thousand watchers. Vanamonde (Talk) 20:50, 23 April 2020 (UTC)
    So, I understand your argument about people being reluctant to undergo RfA, but how is this much different? You’re advertising something for community comment and the people with enemies will have them show up just like at RfA. TonyBallioni (talk) 21:26, 23 April 2020 (UTC)
    @TonyBallioni: Two reasons; first, RFA has a bad reputation, deserved or otherwise, that's somewhat unique; second, the skillset is much narrower, and main-page specialists don't have to worry about being questioned on their knowledge of deletion or blocking policies. Vanamonde (Talk) 21:37, 23 April 2020 (UTC)
  • Can we move everything to the template space and have template editors who would be able to edit it? — Preceding unsigned comment added by Ymblanter (talk • contribs)
    @Ymblanter: Technically, I believe so. I don't know that that proposal has any greater chances of success than this one, because it would be assigning two very different functions to that usergroup and require downgrading protection on the main page. I would probably support such a proposal, but I am not willing to propose it myself. Vanamonde (Talk) 20:56, 23 April 2020 (UTC)
  • I tend toward "if we trust them enough to update the main page, we trust them enough to have the tools", especially if we're giving them protect/editprotected. --Izno (talk) 20:52, 23 April 2020 (UTC)
    @Izno: we may trust (many of) them; but there's a lot of reluctance to enter the snake pit that is RFA. Vanamonde (Talk) 20:56, 23 April 2020 (UTC)
  • One of the issues with lack of admins is actually down to timezones. The majority of our admins are in North America, so when it is the early hours of the morning there, obviously fewer admins are available. It also doesn't help that these hours correspond to late morning/early afternoon in Europe (where we also have a number of admins), when a lot of people are at college or work (not so much at the moment, obviously). I suspect this would also be the case with the majority of anyone we recruited as MP editors, as well. Black Kite (talk) 21:37, 23 April 2020 (UTC)
    When I ran for RfA, I pointed out that being in time zone kilo gave me an advantage. You didn't regard that as relevant then. Hawkeye7 (discuss) 23:41, 24 April 2020 (UTC)
    While I can't speak for Black Kite, that seems a perfectly reasonable view. "It would be good if we have more admins the upper UTC+5 to 12 or so time zones" does not mean "I should consider someone's timezone in deciding whether I think someone should be an admin" since for many or most editors, it comes down to trust rather than whether the admin may do some useful admin work. I mean people may oppose an RfA if they feel the editor is unlikely to ever actually use the tools, or even if they will rarely use the tools. But it doesn't mean the fact someone is likely to regularly use the tools, or will help in areas currently underserved, will make up for a lack of trust. Or even that it will come into the equation at all. Note that I make no comment on your RfA, other than that having skimmed through it sometime in the past, and having read your comments here, I would suggest you're still a way from being ready for another one. Nil Einne (talk) 14:30, 25 April 2020 (UTC)
    Sure, but if we were only talking about the front page update, would that alter the equation? Would such factors become more relevant? Hawkeye7 (discuss) 01:03, 26 April 2020 (UTC)
  • I was made an admin in 2006, stating that I planned to use it only for typos and such on the Main Page. I don't think such a person would pass RFA these days, so I don't assume that a good Main Page editor could pass RFA. Art LaPella (talk) 03:38, 24 April 2020 (UTC)
    @Art LaPella: Wikipedia:Requests for adminship/Kees08 looks to me like a recent example of what you describe, and it passed fairly easily. Personally I would always support someone at RFA who isn't a jerk, is experienced with content, and has a demonstrated need for the tools. And I suspect most Wikipedians would be the same.  — Amakuru (talk) 22:38, 29 April 2020 (UTC)
  • @Vanamonde93:, was consideration into a narrower set of authorised responsibilities considered - while they are fall into the same zone (so there's an immediate inclination to add all), there's two potential differences: some might be more (potentially) controversial, such as ERRORS, and others might be more unnecessary to expand the workforce (those not so dependent on 1 or 2 admins). My concerns on potential security issues (both wilful misuse and attack surface are separate) but I wanted to consider unnecessary risks of issues first. Nosebagbear (talk) 09:22, 24 April 2020 (UTC)
    I'm not sure entirely what you're asking, Nosebagbear. Are you asking if the set of appropriate uses was intentionally narrow? Yes, it was. The point of this thing isn't to end-run around unbundling the protect tool. Vanamonde (Talk) 15:58, 24 April 2020 (UTC)
    @Vanamonde93: - it was actually a query on whether an even narrower update was considered (Errors seems to have a bit of concern above, for example)? Nosebagbear (talk) 18:55, 24 April 2020 (UTC)
    @Nosebagbear: We considered it; but speaking for myself I think the skillset we're discussing is either relevant to just one main page venue, or to all of them + errors; I don't see how someone can be trusted enough to deal with the DYK queues but not with error reports about DYK. So I don't see the benefit to removing ERRORS from the scope of the proposed usergroup. I also don't see that addressing the concerns of very many users, with the possible exception of Iridescent; most folks seem to be saying that the security risk is too high (which is reasonable, though I disagree) or that the people who could make use of this should run at RFA (which isn't, because most of them have refused repeatedly). Vanamonde (Talk) 00:34, 25 April 2020 (UTC)
  • If going through the relentless gauntlet of RFA is a precursor to doing substantive volunteer work of this sort on the project, then maybe I'm just not cut out to be a volunteer.--WaltCip (talk) 14:40, 24 April 2020 (UTC)
  • In theory, one could enforce the restriction "main page editors can't edit fully protected pages other than <whitelist>" using the edit filter, but I would oppose the proposal regardless because (a) this proposal necessarily gives them the right to protect pages as well, which I don't think can be stopped by the edit filter and (b) this is an ugly hack. * Pppery * it has begun... 00:09, 25 April 2020 (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.

Clarifying common practice ref inclusion

There's certainly consensus against the implementation of these proposals as a group in this way here, along with what I think is a moderately clear consensus against part 1 of the proposal (i.e. adding a suggestion to users that they might be able to either write themselves or facilitate an external source being written, then subsequently write an article based on that source). The response to the other two parts of the proposal is less clear-cut, but they should be discussed as separate proposals in the relevant venue(s) as discussed below, with clarity on what exactly is being proposed. Naypta ☺ | ✉ talk page | 22:26, 25 May 2020 (UTC)

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.


A group of editors and I have been discussing the issue of subjects which are already notable in their field, but have yet to be sufficiently noted as per our criteria.

I'm proposing three inter-connected clarifications of what I understand to be common practice here: someone complains that no article exists about a thing, we explain how it works - and that person happens to be in a position where they can legitimately help to make significant coverage happen to the satisfaction of our guidelines.

This clarifying of common practice:

  • facilitates simplicity of process
  • requires only small additions
  • does not seek to redefine any terms

My three-part proposal is that:

  1. the WP:N page, under the "Notability requires verifiable evidence" section, should state:

    Users who are in a position to encourage such independent recognition may be able to facilitate an already notable subject meeting the Wikipedia noted criteria where insufficient verifiable evidence currently exists, and could subsequently provide that new evidence by writing or requesting an article.

  2. the main Help page should have a clear invitation to Request an article, either as its own section, or as a new section under Create a new article, pointing users directly at the Request an article page. It could offer additional encouragement:

    You can request that one of our editors creates an article on a subject you feel meets our criteria for Notability. If you can provide evidence of this from reliable sources, that can help to faciitate a successful outcome.

  3. the Request an article page could also make a statement as per #1, for those who only see this page, and be tweaked to do more to encourage proposers to provide evidence of notability. The current statement just doesn't go far enough, in my opinion, and propose this change:

    Give a brief description, with links if possible, for the proposed topic, to aid others in understanding your request confirming that the subject should have an article of its own. Note that some subjects are more appropriately placed within the article of another subject for which they have significance.

The discussion which led to this proposal is on the Notability talk page. I've brought it here because it pays regard to three separate pages. (NB: I have not suggested editing Verifiability because it seems to me to be addressed to the people who will do the actual article creation, rather than those who are simply proposing an article. Happy to hear if anyone feels something should go in there too.)

For inclusion, I am tagging @GhostInTheMachine: whose observation of the difference between 'notable' and 'noted' instigated the discussion, and administrator @Masem: who made a significant contribution to the shaping of the resulting proposals. I am equally grateful to all who have already engaged and contributed, and will link to this proposal in our original discussion, and on the pertinent pages above. -- BessieMaelstrom (talk) 13:55, 22 May 2020 (UTC)

  • This looks like a non-starter to me, because it is based on a false premise. It is impossible for any subject to be notable if it doesn't meet the lower standard of verifiability. There seems to be a confusion here between the current state of an article, which is not an issue with either notability or verifiability, and the sources that exist, which are relevant to both. Phil Bridger (talk) 15:24, 22 May 2020 (UTC)
    Hey Phil, thanks for this. I'm not sure I understand what you mean ref the current state of an article etc... can you say it another way, please? I see what you mean about the false premise, which I think was just me explaining it badly. I've edited to hopefully clarify the initial premise. -- BessieMaelstrom (talk) 15:38, 22 May 2020 (UTC)
    I don't think I can put in in another way, because it's a very simple concept if you will only listen to what other people are telling you rather than stick to the same ideas, but I will try different words. Neither notability nor verifiabilty depends on what is currently written within an article. They are both concepts that apply to things (such as article subjects) that exist in the outside world rather than just in Wikipedia. Phil Bridger (talk) 16:11, 22 May 2020 (UTC)
    I'd appreciate it if you can avoid making this be personal, Phil. I get that it's about being worthy of note in the outside world. Can I ask what is making you think I don't get that? I'm specifically talking about articles that do not yet exist, so I didn't understand your point about "the current state of an article". BessieMaelstrom (talk) 18:14, 22 May 2020 (UTC)
  • I don't think this is a good idea. A large proportion of people who come here to request an article or attempt to write one on a non-notable subject are trying to promote something; we don't want to encourage the idea that they can manufacture notability by writing their own sources. The minority of people who are in a position to write reliable sources on subjects that aren't currently notable (academics, journalists, etc.) presumably don't need our encouragement to continue doing their jobs. – Joe (talk) 15:44, 22 May 2020 (UTC)
  • I agree. We have enough spammers trying to get us to accept articles about topics that have only been written about by people with a conflict of interest. We certainly shouldn't be encouraging even more of this practice. We should cover topics that have been covered independently of any Wikipedia concerns. Phil Bridger (talk) 16:11, 22 May 2020 (UTC)


Joe, Phil, you're quite right, there will be people who think they can just write a blogpost about themselves. We should absolutely make clear that the WP:GNG still apply. Plus I didn't write it in a very accessible way. How about this?

Users who are in a position to encourage an independent article or review from a reliable source may be able to help a noteworthy subject meet the Notability Guidelines, and could then write or request a Wikipedia article.

We already have this very simple system whereby people can request an article, but it's pretty hidden to the uninitiated. As with everything, the more complex the path, the greater the impact on underrepresented groups.

As I said in the original discussion, small changes like this could give some a fighting chance against such things as the complexity of the user interface, or not being confident enough in your belief that the article belongs and worrying about experiencing rejection, or simply not having the time to figure it all out. It's no coincidence that these are also the top three in Sue Gardner's list of possible causes for gender disparity on Wikipedia.

I'm not suggesting that journalists and others need any encouragement to do their job, but their choices of subject matter can legitimately be influenced. Reviewers can be invited, journalists approached. The veil we are currently drawing to mask the doorway of article requests is also masking it from those who might just need that extra nudge.

Also, what's the worst that could happen? The requested articles list gets longer, but we already neatly divide it up into subject areas on several levels. Editors are likely to consider their smaller area of expertise, and suddenly those lists are a lot smaller.

Some people who found that simple doorway a far less intimidating way into Wikipedia might see their proposals not moving from the list, and look into it all a bit more, and maybe be inspired to edit. It could also be a doorway for that.

We are encouraged to be bold. We could be bold with this, and see what happens. Joe, Phil... who's with me?! --BessieMaelstrom (talk) —Preceding undated comment added 16:59, 22 May 2020 (UTC)

BessieMaelstrom, a minuscule proportion of our articles come through the article request system. The way to get more articles about under-represented topics on Wikipedia, such as those about women, non-Western topics, or "untrendy" topics that are not part of Anglophone popular culture, is for people to simply create the millions of such articles that can be done on the basis of reliable sources that already exist. That will be a much more productive approach than encouraging people to suggest topics for articles that will never be created anyway. BE BOLD. Phil Bridger (talk) 17:55, 22 May 2020 (UTC)
This isn't a proposal with the specific intention of solving that problem. It's a proposal to take a thing we already have and make it more visible, because it will help some people, an example of whom is underrepresented people whose work is on the edge of inclusion. A small amount of articles come through that doorway at least partly because we hide it. More people might follow the advice to be bold if we made the simpler path more visible. There are many ways to begin to address this complexity of problems, and this is one very easy one. I'm not suggesting we take out an ad in the Daily News. I'm suggesting we just make a bit more obvious than you can request an article, and that those who could invite someone to review work that isn't in here yet could think about doing that. -- BessieMaelstrom (talk) 18:25, 22 May 2020 (UTC)

Just wanted to add a quick note to all that I don't see this as a yes-or-no subject. We have a simpler doorway, and we also have the risk of flooding. My proposal is an attempt to make the doorway more visible and also help those who could be here to get here more easily. If my proposal doesn't hit those marks, let's talk about how we could hit those marks. BessieMaelstrom (talk) 18:42, 22 May 2020 (UTC)

I actually think that we would do better to remove any suggestion that requesting an article will actually lead to anything, because it will hardly ever do so. If someone wants there to be an article about a topic then the only way to get it is to do the work themselves, rather than ask some non-existent other editor to write it. Phil Bridger (talk) 19:46, 22 May 2020 (UTC)

This thread seems hopelessly muddled to me. Early on it states "Users who are in a position to encourage such independent recognition..." but later it suggest pointers to writing creating requesting a Wikipedia article. It says it's about "person happens to be in a position where they can legitimately help to make significant coverage happen to the satisfaction of our guidelines."

This makes a mishmash of the timeline of a proper Wikipedia article. Step 1, someone does something, something exists, or something happens. Step 2, reliable sources write about the topic. Step 3, the reliable sources come to the attention of a Wikipedia article. Step 4, the editor writes a Wikipedia article.

This proposal seems to be saying that if a Wikipedia article exists about a person, then the person is notable, so a Wikipedia article can be written about the person.

I feel this thread is so hopelessly confused that it should be closed. If there is any merit to the ideas hidden in the fog, a new proposal should be started. Jc3s5h (talk) 18:44, 22 May 2020 (UTC)

Hey Josh, thanks, that was helpful. I'm happy to clarify:
  • Step 1 - someone does something, something exists, or something happens that is actually worthy of note by somebody connected to a reliable source
  • Step 1a - that thing is in a state of being worthy of note (as considered by the World At Large), but not having been noted yet (in the World At Large)
  • Step 1b - a person nudges someone who can create a reliable source, possibly because we said "Hey, if you're really sure this is a thing the World At Large would think noteworthy, maybe you could nudge someone to look at it?"
  • Step 2 - they do nudge, and as it happens, they were right, and said reliable source writes about the topic
  • Step 3... etc
This is about the liminal space between notable and noted. (The original discussion is likely to be helpful too. Masem was very eloquent in describing this common practice.) -- BessieMaelstrom (talk) 19:06, 22 May 2020 (UTC)
Bessie, please just stop responding immediately to everything and have the courtesy to read and understand what everyone is telling you. We are not a bunch of chauvinists trying to slap down ideas from outsiders, but people trying to help you. On a minor point, what you describe in your last post is far from a common practice. I've been editing Wikipedia for well over a decade and have never seen anything like that happen. Phil Bridger (talk) 19:46, 22 May 2020 (UTC)
That's no minor point, Phil - it's about what I am actually proposing. I was empowered to make this proposal by the person who had observed that practice, but even if it's not common practice, my proposal still stands. This is about stuff happening pre-Wikipedia, so it's kind of impossible to know how much appropriate stuff might get through a more opened door until we more-open the door. I understand that there is a risk of flooding with inappropriate articles. If my proposal doesn't hit the marks, then I'm inviting collaborative suggestions for ways to encourage more qualifying requests without also exacerbating the COI problem... and maybe for ways to convert a Requestor into an Editor? Very happy to be pointed at the appropriate place for discussion, if this is not it. I'd really appreciate it if this didn't become personal, though. I have nothing but respect for all who attempt to do the impossible work that is caretaking this incredible archive of world knowledge, and even more challenging given that it is so fully collaborative. To my mind, the only thing that is personal here is how admirable it is to take that on, and I'm grateful for all contributions to this miniscule part of it. -- BessieMaelstrom (talk) 20:23, 22 May 2020 (UTC)
It does seem to me as though these are separate proposals that could be considered separately. Most of the discussion here seems to be about (1), and I oppose that per Joe Roe's first comment here. Wikipedia's role is to document knowledge that already exists, and guidance on how to establish new knowledge (i.e. get journalists to write about important topics that are not yet notable in Wikipedia's sense of the term) is firmly outside its scope. (okay, I guess I'll link to WP:RIGHTGREATWRONGS if I must) Proposals (2) and (3) seem fine to me, though. One question related to that that I've been wondering: how many articles listed at WP:Requested articles actually get created, and how long does it tend to take? My mostly uninformed hunch is that it may be largely a bottomless pit. {{u|Sdkb}} talk 20:04, 22 May 2020 (UTC)
Hey Sdkb. I was in there today whilst considering all this, and during that time I removed one blue link for something that had had an article created about it in my specialist subject. Looking through the rest, I can see a couple at a quick glance that I would have a go at converting into an actual article, and quite a few that I'd want to at least research. It's on my list as one of the areas in which I would like to do some maintenance. -- BessieMaelstrom (talk) 20:23, 22 May 2020 (UTC)
Of course, the list of requested articles may well include some objectionable / ridiculous / amusing / crazy suggestions, but it should also be seen as a rich source of input from the outside world. The request process needs to be simplified so that it is more available to non-editors. A way forward would be a wizard much like the Article wizard that captures extra detail such as a possible lead sentence and one or more sources. — Ghost in the machine talk to me 20:00, 23 May 2020 (UTC)
That's a great idea. Fancy sketching something out? I will happily work on it with you. -- BessieMaelstrom (talk) 22:51, 23 May 2020 (UTC)
@BessieMaelstrom and GhostInTheMachine: Revamping WP:Requested articles for usability sounds like a great task. Please feel free to ping me or post at WT:WikiProject Usability if you delve into that. The folks at WP:WIR might have some insights. {{u|Sdkb}} talk 22:14, 25 May 2020 (UTC)
  • I've really had enough of this discussion. My last words are that the "requested articles" feature will never be the source of more than a handful of articles, and I stand by my comment that any people who are serious about wanting articles should simply write them themselves, and that any generation of sources for the purposes of enabling a Wikipedia article has a vanishingly small chance of producing anything that is truly independent and reliable. Phil Bridger (talk) 12:19, 24 May 2020 (UTC)

I think this is opposed and done now, with thanks to all who responded. Two of you opposed the idea of making the current Submit an article section more prominent, and two of you supported that idea, with one suggesting it might benefit from a Wizard. So I guess that will be a different proposal. -- BessieMaelstrom (talk) 18:31, 24 May 2020 (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.

Interface admin and view deleted access

Tracked in Phabricator
Task T202989

I raised this as a thread on checkuser-l, but WP:INTADMIN currently restricts the ability to view deleted interface pages to IADMINS not as a feature of policy or intent, but as a bug in the system. There’s a patch that’s been proposed since August 2018, but is stalled at the review stage. I’ve debated asking for the permission for view access to deleted pages, since I doubt it’s going to be fixed anytime soon and there are several sockmasters where having the access to their deleted common.js, etc. would be very helpful to me.

The glitch in that is that our local activity policy requires use every six months. I have zero interest in using it for anything other than view deleted access. I think adding a line to the activity policy such as the interface administrator indicating that they still need access to the right to view deleted content would be fine. If people are overly concerned about the security risk here, we could possibly restrict activity for that reason counting to the CU team, but I don’t really think we’re talking about more than a handful of people who would want it for this reason.

Anyway, is there a consensus here for a quick change to the policy to allow for this? If not I can start an RfC, but I’m hoping this will be non-controversial. TonyBallioni (talk) 14:03, 31 May 2020 (UTC)

TonyBallioni, This sounds like a sensible change. S Philbrick(Talk) 14:08, 31 May 2020 (UTC)
I think you should just push to get this worked on, having to constantly check for people with no logged use that just "say" they want this constantly is going to be a headache. Suppose to keep automation checks working you could just indicate your need by updating something like User:Example/test.css. — xaosflux Talk 15:00, 31 May 2020 (UTC)
A patch has been in the works for two years and has stalled. I don’t really have any faith this is going to be fixed within the next decade even with poking. I don’t really think the automation issue is actually an issue. There’s 11 people with this now. One talk page message to check every six months for 1-2 people isn’t that much work. TonyBallioni (talk) 15:27, 31 May 2020 (UTC)
Also, xaosflux a link to the actual gerrit: [4] TonyBallioni (talk) 15:37, 31 May 2020 (UTC)
The easiest thing to do is grant interface administrator access as part of the checkuser toolset (whether it's done by bundling the actual permissions, or just by granting the flag concurrently with the checkuser flag) and then ignoring all checkusers who have interface administrator access from the activity monitoring stuff. I don't suppose anybody can explain why WMF is hell bent of making life as difficult as possible for those of us who have volunteered our time to behind the scenes management stuff. Why can't they just fucking fix the IADMINS stuff and stop trying to find new ways to make life impossible for the rest of us (such as the hiding anonymous users IP data) ? Nick (talk) 15:41, 31 May 2020 (UTC)
Some CUs here and on other projects have valid reasons not having 2FA, so that wouldn’t work from a WMF security standpoint. If you want a quick way to automate it, you could exempt CUs who have it from the activity requirements of IA. TonyBallioni (talk) 15:50, 31 May 2020 (UTC)
Adding editinterface to the CU group is silly and really not the point of the entire thing; I certainly agree the primary viewing problem should be fixed (I'm the one that authored the request afterall!) - a dev did update it a couple of months ago - just poked them on phab:T202989 - where this really is a global problem. — xaosflux Talk 15:53, 31 May 2020 (UTC)
As far as "indicate you have an ongoing need", it would be just as easy to indicate that at a dummy page like the one I put above as anywhere else, and would not require any extra work. — xaosflux Talk 15:55, 31 May 2020 (UTC)
I think it’s less complicated just to have a bureaucrat ask the question 1-2 times a year. Gaming the system isn’t something that I think is a good thing. People shouldn’t have to make a dummy edit to keep this if they’re using it. You could also look at it from a security standpoint that people who don’t need it are more likely to give it up if asked if they still need it rather than being told how to keep it. TonyBallioni (talk) 16:32, 31 May 2020 (UTC)
@TonyBallioni: oh all the dummy edits made by +sysops every year........ This wouldn't be a "twice a year" thing specifically, the policy has these rights continually expire - we don't do a twice a year review of everyone. In practice, we only review the rights holders monthly though. Looks like the activity at the phab task has given some renewed interest in the fixing though (which is really where it belongs). — xaosflux Talk 01:36, 1 June 2020 (UTC)
Is it not just easier to flip user:TonyBallioni’s Iadmin bit with a note that the 6 month term does not apply to him in a fully automated way, but that he just needs to confirm the need every 6 months? —Dirk Beetstra T C 17:40, 31 May 2020 (UTC)
Beetstra, That also sounds like a workable solution. S Philbrick(Talk) 18:18, 31 May 2020 (UTC)
If he's the only one with this issue/concern, then I'd support that. Primefac (talk) 21:21, 31 May 2020 (UTC)
I would prefer the view and edit permissions be split; until that happens WP:IAR and give Tony IAdmin since he has a clear need. — Wug·a·po·des​ 21:20, 31 May 2020 (UTC)
@Wugapodes: FWIW, there is no IAR needed for Tony to get this, he requested it at BN and I doubt there will be any cause to not issue it. — xaosflux Talk 01:32, 1 June 2020 (UTC)
I thought the criteria were more restrictive than that, but I read them again and clearly I misremembered. Good to know there's enough room for this in the existing policy. I trust Tony with IAdmin regardless, but I still think view and edit should be split for the reasons given in the phab task. — Wug·a·po·des​ 03:29, 1 June 2020 (UTC)

RfC: Source classification process

To increase transparency and robustness of the process for classification of sources, increase the review requirement for actions that prevent use of a source. This affects the list of perennial sources at the reliable sources noticeboard and also the spam blacklist. Guy (help!) 19:55, 17 May 2020 (UTC)

Add the following to the instructions for admins at MediaWiki talk:Spam-blacklist:

A project-level RfC is required when blacklisting any entry that is widely used as a cited source in articles (per {{insource|$SOURCEDOMAIN}}) other than those added by the spammer(s). The RfC may be initiated after addition to the blacklist where there is ongoing abuse, with the expectation that it will be removed if the RfC decides against blacklisting. RfCs should be registered using {{rfc|prop}} at Wikipedia:Reliable sources/Noticeboard

Opinions (Source classification process)

  • Support as proposer. Guy (help!) 19:55, 17 May 2020 (UTC)
  • Oppose as needless bureaucracy. If blacklisting will obviously be very controversial then have a big RfC, if the domain is only used by spammers just blacklist it already without any palaver. If it's somewhere between then just have a normal discussion and only move to a formal RfC if it is actually needed in that specific circumstance. As the proposal stands you're just asking for arguments about whether a source is "widely used" and whether any particular uses were technically "spammers" or not. Thryduulf (talk) 22:29, 17 May 2020 (UTC)
  • Oppose needless restrictions on the spam blacklist. I trust User:Beetstra and the other admins at the spam blacklist to know the difference between spammed sites and unreliable sources and to act accordingly. WhatamIdoing (talk) 19:13, 1 June 2020 (UTC)

Discussion (Source classification process)

This RfC follows on from text suggestions made in Wikipedia:Reliable sources/Noticeboard/Archive 293 § RfC: Deprecation and blacklisting process, which closed on 10 May 2020. Guy (help!) 19:55, 17 May 2020 (UTC)

Oh christ, no. RSN gets enough RfCs as it is - at one point late on 15 May, there were no fewer than eighteen open RfCs at that one board alone. People are going to acquire what I might term "RfC blindness" so that they no longer either care or even notice. --Redrose64 🌹 (talk) 20:16, 17 May 2020 (UTC)
Redrose64, that's partly because people are opening RfCs for sources that someone used once, rather than for sources where it's worth having a serious discussion. Guy (help!) 09:34, 18 May 2020 (UTC)
So perhaps a more pointful RFC would says something like "Shall we keep wasting editors' time with sources that aren't widely used? For example, future proposals to add a website to Wikipedia:Reliable sources/Perennial sources should show that there have been at least two discussions at RSN about the source in the past (not counting the current discussion), or that it is currently present in more than 10 articles."
This innovative list of unreliable sources is allegedly for the stuff that gets disputed over and over. That's why editors named it WP:RSP with a "P" for perennial and not Wikipedia:Assorted collection of things we found on the internet and have never used much, but we don't like them so we're proactively banning everyone from using them." WhatamIdoing (talk) 19:21, 1 June 2020 (UTC)

Blacking out Wikipedia in Support of Black Lives Matter

Moved to Wikipedia:Village pump (proposals) § Blacking out Wikipedia in Support of Black Lives Matter
 – SoWhy 09:23, 2 June 2020 (UTC)

WMF Board Authorises Universal Code of Conduct and non-local sanctions of those who breach them

The WMF Board has just authorised the creation of a UCOC by the Foundation (presumably T&S) to create a UCOC, purely in consultation with the local communities, along with various other related facets, which are summarised below.

  1. Developing and introducing, in close consultation with volunteer contributor communities, a universal code of conduct that will be a binding minimum set of standards across all Wikimedia projects;
  2. Taking actions to ban, sanction, or otherwise limit the access of Wikimedia movement participants who do not comply with these policies and the Terms of Use;
  3. Working with community functionaries to create and refine a retroactive review process for cases brought by involved parties, excluding those cases which pose legal or other severe risks; and
  4. Significantly increasing support for and collaboration with community functionaries primarily enforcing such compliance in a way that prioritizes the personal safety of these functionaries.

Whatever our respective views on the issues are, I believe we've now reached the point where a co-ordinated Community viewpoint, rather than that of a few interested editors on meta, needs to be created so we are in a position to engage, or react, rather than attempting to coordinate on the fly.

I've just created a general discussion part below for an initial discussion, but I imagine it'll need spinning off into aspects and so on and so forth. Nosebagbear (talk) 22:23, 22 May 2020 (UTC)

  • Whatever our respective views on the issues are, I believe we've now reached the point where a co-ordinated Community viewpoint, rather than that of a few interested editors on meta, needs to be created so we are in a position to engage, or react, rather than attempting to coordinate on the fly
    I disagree with this sentence basically in it's entirety. I've been in the minority on this project in regards to global/meta/Foundation issues in the past, and I think the local en.wiki community tends to overreact to things that aren't big deals and post-last year tries to turn everything into FRAM2.0. Because non-en.wiki specific stuff includes people from a lot of different projects it is often very nuanced, and I don't think having a single coordinated response that would inevitably have some broad strokes would do whatever the idea is justice. That includes not being able to identify any valid criticisms and address them in a fair way because of an overarching position.
    So no, I do not want there to be an official en.wiki position. To my knowledge, I am still an active member of this community who is generally trusted by others. I also think that the tendencies of some on this project to see every move of the Foundation as the boogeyman coming to get us is over the top and unhelpful. I don't want to be associated with that.
    If people want to raise their voices on meta, they can, but we absolutely should not be giving the weight of the entire English Wikipedia community behind a position that:
  1. most active editors will never see or care about (most people don't care about this level of inside baseball)
  2. that will have significant opposition on either side regardless of what the position is.
This project and community is not monolithic. We are a group of individuals and that is what makes us work. If people care deeply about this (as I'm sure many do), comment on meta. If you don't care enough to comment on meta. I don't want to be stuck with a coordinated position of driveby voters who don't actually engage long-term. TonyBallioni (talk) 22:36, 22 May 2020 (UTC)
This is a side issue, and not particularly relevant to the primary issue
@TonyBallioni: I won't comment on Meta because of the homophobic behaviour of a WMF account I tried to deal with there. As they were defending homophobic behaviour by the Foundation, I saw little point in complaining. DuncanHill (talk) 22:41, 22 May 2020 (UTC)
That's a very strong accusation, and I'm sorry you feel that way. Could you please diff so those of us who aren't familiar with what you are discussing can evaluate the situation for ourselves? I'm also pretty confident many at the Foundation would want to address abuse from a Foundation account. TonyBallioni (talk) 22:41, 22 May 2020 (UTC)
(ec) It was an email. And if you want another strong accusation, then dismissing editors on this board as "driveby voters who don't actually engage long-term" is pretty poor too. DuncanHill (talk) 22:45, 22 May 2020 (UTC)
If your really interested, you could just look at my contributions on Meta. DuncanHill (talk) 22:48, 22 May 2020 (UTC)
Tony, I just had an alert from Meta. You've made your position pretty clear. I don't trust you to deal with this matter. DuncanHill (talk) 23:02, 22 May 2020 (UTC)
Yes I reverted sensationalism that you posted on a research page because you didn't like a bad piece of software with good intentions. Per the above, I've checked your meta history and found this. What I see is you being rude to WhatamIdoing for explaining to you that m:Research:Detox, which I agree was a horrible project, was intended well and that once it was discovered it was corrected. I haven't seen what they emailed you, but I suspect it was similar and likely was trying to explain that detox was trying to detect homophobic abuse and that the people who were creating the algorithm did it wrong. TonyBallioni (talk) 23:14, 22 May 2020 (UTC)
She sent me an email full of links to homophobic abuse, and told me to read them. I expect you'll tell me that was "well-intentioned" too. DuncanHill (talk) 23:35, 22 May 2020 (UTC)
I'm sorry you were offended by that material. In my childhood and young adulthood I faced similar bullying in school where people just assumed things and didn't actually care what my sexuality was or who I was as a person. I was just stereotyped. I care deeply about this issue as well.
At the same time, yes, if you're dealing with a tool that was intended to identify things such as homophobic abuse, then yes, I would expect emails about the tool to include links to homophobic abuse. That's how you build and deal with something like this. I'm not privy to the emails, but I've been a part of many discussions about identifying abuse on Wikimedia projects using automated tools. I've never once had someone think what you're describing is a tool behaving properly, but yes, people are going to try to dive through previous abusive content to see what the tool should be preventing. TonyBallioni (talk) 23:43, 22 May 2020 (UTC)
It wasn't material identified by the tool. She had a very limited knowledge of the tool, and indeed was (or seemed to be) getting more information about it from me than she was from WMF. It was just a random list of homophobia she had found when trying to say that classifying "I am gay" as an aggressive statement was not homophobic. I didn't ask to be sent it, and to be frank nobody with any sense of decency would have sent it. Do you send unsolicited links to anti-Semitic content to Jewish people who have raised a concern with you? I hope not, indeed I'm sure you don't and never would. "I'm sorry you were offended" is a textbook non-apology apology. DuncanHill (talk) 23:50, 22 May 2020 (UTC)
I don't see the point in continuing this conversation here. I won't be going to Meta and I have said why. It's a toxic environment. DuncanHill (talk) 23:52, 22 May 2020 (UTC)
  • This isn't inside baseball. It will affect everyone. SarahSV (talk) 22:57, 22 May 2020 (UTC)
    • I get that view, but I also doubt it will have much if any impact on existing processes. I think anti-harassment is important, but after FRAM the foundation is very hesitant to do anything (for good reason.) Likely what you're going to see is a formalization of the norms they already use to global lock people who are already blocked on multiple projects. TonyBallioni (talk) 23:14, 22 May 2020 (UTC)
  • I think it's important for the range of views of enwiki editors to be made clear to the Foundation. I know that many weren't happy with the way Framgate happened, and I was one of them, but I'm currently trying to support a victim of bullying on another project, and I can see the value of the principles in that announcement. The likely problems aren't in the goal of a universal code of conduct (UCoC), but in the way that it gets implemented, and the more we can influence that to match our needs and expectations, the more likely it will turn out to be an improvement, not a burden. --RexxS (talk) 23:21, 22 May 2020 (UTC)
  • I don't think we're at the point where a co-ordinated Community viewpoint is necessary. As far as I'm aware, the WMF has not even proposed what a universal code of conduct would look like. Trying to discuss this now puts the cart before the horse, and prevents anyone from actually working toward a positive result. I think there is a real need for a baseline code of conduct for all Wikimedia wikis, because very few wikis have the codified conduct policy that enwiki does. This makes it more difficult to deal with even blatant incivility and harassment (see the amwiki situation last year). There are some things that are unacceptable on any wiki, and I think a global policy to handle that is important. I do think that the WMF could greatly improve Foundation-community relations during this discussion by committing to allowing wikis to replace the code of conduct with a sufficient policy and strong community consensus. --AntiCompositeNumber (talk) 23:28, 22 May 2020 (UTC)
  • Agree with AntiCompositeNumber. What exactly is the purpose of this VP thread? As far as I can tell the "UCOC" hasn't even been drafted yet. -FASTILY 00:37, 23 May 2020 (UTC)
  • @TonyBallioni: Tony, this may be one time I might have to disagree with you, if I understand what you're saying (and it's far from impossible that I haven't). I am personally very concerned about the WMF handing down diktats from above, when they're not on the front lines, actually editing on a day-to-day basis and facing the trials and tribulations that almost every Wikipedian has to confront. It's very easy to look down from on high and pontificate in a vacuum about ideal behavior, without experiencing what it's actually like to try to protect and improve a Wikipedia project from the onslaught of vandals, SPAs, CPOVs, not-at-all-civil POVs, children, jerks, assholes, and well-meaning fans. In the trenches, behavior is going to be a lot more brusque and direct than might be considered ideal in a utopian world, as we attempt to deflect these forces, while at the same time not running afoul of our community-based policies on civility and other behaviors. To have yet another layer of behavioral proscriptions imposed on us from a bunch of people even further removed from the realities of editing is a real concern for me, and -- I would think -- for other Wikipedians as well.
    Is it your concern that we shouldn't respond to the WMF about their Universal Code of Conduct ("Universal"? Is conduct in Nepal really the same as conduct in Detroit?) or that we shouldn't coalesce around a single "community response" too soon? I, too, would like to avoid another Framgate, but not at the cost of having my views and those of others like me being ignored by the WMF. If I'm mistaken about what you're proposing, please straighten me out. Beyond My Ken (talk) 05:21, 23 May 2020 (UTC)
    • Beyond My Ken, I have a more pro-WMF view than many on en.wiki because I have seen them do positive things both in terms of software (WP:ACPERM) and in their global actions (User:Til Eulenspiegel was globally banned by both the community and the foundation. After his community ban he socked and urged acts of violence against LGBT people. Basically the posterchild for Foundation action.)
      What I'm saying is that people like you and many other in this community do have legitimate concerns. I respect that, even if they are different from my views, and think that you and others should respectfully voice those concerns as individuals in dialogue with the Foundation to try to find a ground everyone can live with, but we've seen that this community can sometimes react rather kneejerk to anything the Foundation proposes (the recent rebranding thing on meta is probably the best recent example.) You'd likely get a consensus that was built of fear rather than an intent to work together, which is not something I want, nor do I think many reasonable community members. Letting people express their views individually can help make it so the largest Wikimedia Project doesn't have a statement like that, which I think would be a good thing.
      On the universal code of conduct and different geographies, as I said to Sarah, my gut tells me this is more about codification of things that have been ad hoc and isn't going to affect any major projects with the possible exception of pt.wiki, where there are other issues. The other thing is that on some small projects, this is 100% needed. See TI above: he basically owned a project and blocked a steward for telling him he couldn't block a user for having "Queer" in their username and then went on a socking spree cross-wiki. Abuse on small-wiki is not uncommon and stewards are very reluctant to do much about it for a variety of reasons. It has to get to the level where someone blocks a minority and then blocks a steward for intervening for something to be done. Giving the WMF more power to act when small wikis go haywire is a very good thing. TonyBallioni (talk) 05:48, 23 May 2020 (UTC)
      • Tony: I can see where the UCOC would be useful for smaller projects without community enforcement capabilities, but I think larger projects with a history of community-based policing of behavioral problems should be exempted, as long as that project's local policies generally follow the UCOC. Just as global sysops don't operate in the larger projects, and the role of stewarts is minimal in larger projects and more fundamental in smaller ones, T&S should concentrate on UCOC-enforcement on smaller projects, and not in larger projects, such as en.wiki. As projects become larger and more self-sufficient, they too can do their own behavioral policing and T&S/WMF can back off. Beyond My Ken (talk) 01:57, 24 May 2020 (UTC)

Discussion

Again, not relevant

As one of the worst pieces of abuse I've ever had was from a WMF account, and led to me abandoning Meta, I cannot "collaborate" with the Foundation. DuncanHill (talk) 22:34, 22 May 2020 (UTC)

  • RexxS, just to clarify, I agree with your statement generally. I'm just opposed to there being one en.wiki response. We should absolutely engage, but I think the diversity of our views on this topic are best reflected by individually commenting rather than a "community position" TonyBallioni (talk) 23:28, 22 May 2020 (UTC)
    • I respect that view, Tony, but I disagree with it in some ways. If we were to seek consensus for a united response and found one that almost everybody could live with, then I think a single response would be appropriate. If we found a range of views that couldn't reach a single consensus, then maybe we could present a selection of the views that had the most approval. Of course, individuals are always going to be able to respond, but that method of self-selection isn't likely to lead to a representative view, IMHO. As a community, we're surely grown-up enough now to encourage participation from a much broader spectrum of editors and work out what we can agree on. --RexxS (talk) 00:41, 23 May 2020 (UTC)
      • A real consensus (something everyone can live with) is likely not feasible with so many people. However it may be feasible to compile lists of pros and cons that have significant support. isaacl (talk) 20:06, 23 May 2020 (UTC)
  • I feel that there are two paths: A) One where enwiki engages in good faith and with the expectation of compromise and people walk away mostly happy-or-unfulfilled, and then B) One where enwiki refuses to engage or assumes bad faith or assumes that the WMF will bow to their demands and no one on enwiki is happy because the WMF lays down some hammers and fingers get smashed and people wail and gnash their teeth and bans and blocks get handed out and there's lots of drama about it but the grinder continues on, unpurturbed. A is productive; B is not. I think the best thing is for the English Wikipedia to draft a statement of support for the WMF's efforts and thus be part of the team writing the rules rather than reacting to them.--Jorm (talk) 23:53, 22 May 2020 (UTC)
    • Thing is, Jorm, nobody's going to disagree about what the rules should be: be nice to each other; no bullying; respect minority opinions, etc. The conflict will come when we try to figure out how to police those rules, and for enwiki, it's going to take a real effort to balance doing as much as we can in-house with the stress of being a volunteer asked to carry out that role. Giving way a little, and making better use of each other's strengths is how the WMF and the enwiki community are going to be able to achieve that balance. That's going to need a genuine partnership, not a hierarchical approach where each side thinks they know best and wants to run the whole show. --RexxS (talk) 00:41, 23 May 2020 (UTC)
      • Oh, I agree - and I think you and I are actually in furious agreement. I was using "rules" more metaphorically in the context of "we can be part of the people who drive the discussion" as "writing the rules".--Jorm (talk) 01:00, 23 May 2020 (UTC)
  • The Foundation has given itself a very powerful weapon, and I am afraid this is wishful thinking to assume it would only be applied to small projects where nobody can read the language and is unwilling to take action. If stewards are unwilling to take action, the Foundation will not do anything either, because nobody can understand what users on Amcharic Wikipedia tell to each other, unless Google translate of a given sentence would provide something like "I promise to murder you". I was once blocked for half a year on a project I had zero edits, I took it to Meta and nobody was willing to do anything, until Millosh, a steward at the time, went to the project and negotiated an unblock with the admin. And, if I am not mistaken, the guy is still an admin there. On the other hand, WP:FRAM happen at the English Wikipedia, not at thew Amcharic or Acenese one. I am really worried about damage they can inflict, not even necessarily intentianally misusing the tool, but just applying it without sufficient care.--Ymblanter (talk) 07:10, 23 May 2020 (UTC)
  • It is noteworthy that the BBC is now reporting that harassment would include edit warring. Now, whether this comes about as a simple misunderstanding on the part of the BBC, or whether this is being directly briefed by the WMF, is not clear. That being said, I think it's uncontroversial to state that common-and-garden edit warring is not a matter for which WMF centralised sanctions would be appropriate, and if that's the direction that this is moving in, then that is problematic.
    I think it is a fundamentally good idea to have a minimum standard of behaviour across all WMF projects, and I'd argue that that point shouldn't be controversial, even if perhaps it is; "don't be sexist, racist, homophobic; don't personally attack other editors; etc" all seems like a perfectly reasonable minimum baseline. The problem strikes me as coming when that baseline starts turning into other rules being enforced by WMF sanctions rather than by the local wiki procedures, as would be the case with simple edit warring as suggested by the BBC.
    I'm uncomfortable with the phrasing of "the Board is directing the Wikimedia Foundation to directly improve the situation", too, I have to say, and I hope that the "in collaboration with the communities" that follows is genuinely taken into account. Where local sanctions can be placed, that's almost always preferable in my view to WMF sanctions as a port of first call.
    Overall, though, I think it's too early to form "a position" on this one way or another; we need to see what, concretely, is being proposed. Naypta ☺ | ✉ talk page | 09:17, 23 May 2020 (UTC)
    I am not sure that even a minimum standard you mention is enforceable. For example, we know that Iran and Pakistan are deeply sexist societies, sexism is part of the culture, and, whereas it might be changing, it will take decades to have a noticeable change. It is deeply rooted in culture. It would be unreasonable to expect that Persian and Urdu Wikipedias are free from sexism, because their users are just part of the society. And whereas it would be great if anti-sexism measures are enforced, I just do not see how it could be done - hiring native speakers to monitor all the discussions? I have some (though a pretty old one) experience on the Russian Wikipedia, and WMF were at the time considered there as aliens from a different galaxy. They just can not enforce anything there in any consultation with the society. They can randomly block a bunch of users, it would be perceived that the user have been removed randomly by aliens. It would not change the project culture.--Ymblanter (talk) 09:33, 23 May 2020 (UTC)
    @Ymblanter: I understand the point you're making, and to some extent agree with it - it may come to pass that such a set of standards are not, in fact, proactively enforceable in all cases. However, that doesn't mean they wouldn't be helpful in reactive enforcement; if someone brings a complaint, there is then at least a policy to deal with it. Naypta ☺ | ✉ talk page | 11:45, 23 May 2020 (UTC)
  • I’m fine with this in theory but I’d need to see a draft of the text first to have a more informed opinion. What I don’t want to see is the WMF using this for more Fram-like bans, as that would be bad for everyone involved. —pythoncoder (talk | contribs) 12:22, 23 May 2020 (UTC)
  • There are certainly toxic aspects to our culture. But the Wikimedia Foundation has, by way of hamfisted and tone-deaf decisions, lost the community's confidence. We have of course already discussed and rejected the idea of a binding code of conduct that applies to en.wiki.—S Marshall T/C 14:22, 23 May 2020 (UTC)
  • What matters in this is the implementation, not the statement. As is typical for Board statements, almost everything about the implementation is too vague too discus directly--what needs discussion is our views on what the specific standards ought to be-- and once they are announcement, how we are going to deal with them. But there is one part that even as broad policy very much concerns me, the second point,"Take actions to ban, sanction, or otherwise limit the access of Wikimedia movement participants who do not comply with these policies and the Terms of Use;" - ifthe sentence refers to groups, such as individual projects which insist upon maintaining rules that justify harassment, then there's a point to it, and a role for theFoundation, because they are the only ones who have control over such groups. If it refers to individual editors, then it's a disaster, anda violation of all agreed working arrangements between enWP and the foundation. I willl have more to say on this when I know what meaning they intend. DGG ( talk ) 15:28, 23 May 2020 (UTC)
    • I have just become aware of the BBC version. If it is correct, andt he WMF intend to regulate edit warring, they will find, as we have found, that there is no way of doing it without regulating content. .Most truly difficult conduct problems arise from content disputes. (others arise from relatively arcane points of style, such as the infoboxes war, which in no rational organization would warrant either edit warring or harassment, and yet others from plain ordinary interpersonal hostility without rational motivation, which certainly requires regulation). In enWP, and presumably elsewhere, harassment is in fact a common way of settling content disputes, usually with hostility directed to those with particular points of view. This does need regulation -- I think in fact it is our greatest ongoing problem -- but what it absolutely doe not need is regulation from the foundation. To the extent we have biased content , we're to that extent a lower quality encyclopedia, but remain capable of improvement, the continual improvement that most of us came here to engage it; to the extent that others than the participants here regulate content, we 're not a open project, but the sort of directed project most of us came here to avoid. DGG ( talk ) 15:41, 23 May 2020 (UTC)
      DGG, the resistance to any authoritative body to rule on content disputes has always been a source of strife. Once civil POV-pusher can in theory drive off multiple frustrated editors if civility is the only standard - and that's my worry with what WMF appear to be proposing. It looks, in short, like a sealion's charter. Guy (help!) 16:56, 23 May 2020 (UTC)
JzG We are I think in complete agreement about the extent and nature of the problem, and the need to solve it. It is however very difficult to actually do this within our basic structure. Certainly and almost everyone in enWP would reject an outside authority here; I can imagine ways of setting an internal authority, but not one that would be generally accepted. Nor can I think of a set of rules that would not be capable of manipulation. The only way forward is to decrease the intensity of the disputes by not using the necessarily harsh sanctions for them that would be used for bad-faith disruption. The current procedure for winning a dispute is to try to get one's opponents removed from the topic, and our currrent DS rules provide that this can be done in a way very difficult to reverse. These are things we can improve. DGG ( talk ) 17:15, 23 May 2020 (UTC)
DGG, agreed. The closest we've ever come was probably the pseudoscience arbitration case. And that really was quite transformative. Guy (help!) 20:54, 23 May 2020 (UTC)
JzG. yes, that case and its followups need to be re-analyzed. The original motivation was good--to prevent the take over of scientific topics by true-believers, (the way Citizendium was taken over by a belief in homeopathy). The fundamental ideas, of distinguishing between various levels of scientific confidence, and providing for proportional coverage , remain valid. The way these standards can be misused, by overconfidence in what individuals here think scientific results, and the manipulation of the Reliable Sources standard to invalidate references showing the reality of coverage of things you rather didn't exist, was not really predicted. At a more fundamental level, it comes from the naïve reliance of WP upon sourcing, without the necessary critical examination of the actual sources. The worst part currently is the attempt to use standards that are applicable to the natural sciences to judge matters in the social science, and more recently to judge matters in the field of politics. Scientists have always known the extent of uncertainty--public reporting of the sciences is much less knowledgable; I instance the realization of the unreproducibility of results in fields such as psychology, or the disagreement between good controlled especially over time, and of evolving standards of practice. Or, most recently, the statistical blunders made by even the best analysts and most authoritative centers respecting Covid. The first step will be to convince WPedians in general of the problems; the much more difficult one will be how to solve it without destroying out principles. DGG ( talk ) 00:54, 24 May 2020 (UTC)
DGG, well, yes, but on the other hand we're not experts so we're supposed to take sources more or less at face value, depending on their quality. Where are you seeing the pseudoscience arbitration misapplied in politics? Guy (help!) 06:36, 24 May 2020 (UTC)
The difference between the natural sciences and politics derives from the difference in the way the word "fringe" is used in the fields. In the natural sciences any serious researcher at least pays lip service to the scientific method, in which unfalsifiable claims are rejected as unscientific and so fringe, or falsified claims are rejected as such. In the field of politics, where the term "political science" seemed to take hold many decades ago in the US and has now spread to the UK, very few claims are actually falsifiable, so the word "fringe" simply means "unpopular". Phil Bridger (talk) 12:30, 24 May 2020 (UTC)
Phil Bridger, and specifically? Guy (help!) 00:10, 26 May 2020 (UTC)
Wikipedia:Fringe_theories/Noticeboard/Archive_69#Bryan_Caplan. fiveby(zero) 20:40, 1 June 2020 (UTC)
If there's anything we learned for m the RS discussions of the past 10 years, it's that sources cannot be taken at face value. We may not be experts, but we're expected to be intelligent. Our editing here should make us more intelligent yet, and particularly skillful about the nature of writing and publishing. Critical reading is a skill, it can be taught, and I've taught librarians how to do it. . We should as a minimum know enough to recognize that headlines are generally written by the editor , not the author, and that selective quotation is deceptive. Rare is the news article even in places like F_x, that does not have some wording that pretends to give a balance. Rare is the book review that says nothing positive to be quoted; equally rare the one which says nothing negative., and in all cases they start out by saying something polite about the author. Technical literature is more sutle about these things, but it does not necessarily require great subject expertise beyond knowing the technical language of the subject. DGG ( talk ) 09:21, 24 May 2020 (UTC)
DGG, I aqgree here: it has to meet RS *and* it has to pass the sniff test. Guy (help!) 00:11, 26 May 2020 (UTC)
  • Meh I don't think we can do much beyond wait and see at this point. One obvious plus is that after they translate it into every language we have a project in it will at least provide a widely translated non religious text.©Geni (talk) 17:41, 23 May 2020 (UTC)
    There is already the Universal Declaration of Human Rights though. It's very widely translated. TryKid [dubious – discuss] 01:05, 25 May 2020 (UTC)
  • I know others are taking a 'wait and see' approach, but I find it impossible to be optimistic about this. The WMF has recent history of heavy-handedness in its dealings with our community and I am not aware of any reason to believe they have changed their methods. A code of conduct is a good idea in theory, but making it work in practice will be a nightmare given the current state of WMF-community relations. I'm concerned for the future of this project now that we are likely to fall under further regulation from people who aren't actively involved in the task of building an encyclopedia and, given how they use their donation money, don't really seem to care. LEPRICAVARK (talk) 18:40, 23 May 2020 (UTC)
  • No confidence. —Cryptic 18:58, 23 May 2020 (UTC)
  • After Framgate, I don't have any confidence in the WMF's capability to levy sanctions for behavioural conduct that isn't over a bright line, and especially not with a one-size-fits-nobody UCoC. —A little blue Bori v^_^v 2020's a bust; thanks SARS-CoV-2 20:32, 23 May 2020 (UTC)
  • I see that civility is being added to the code of conduct (now civility is mentioned in the summary of the terms of use, but it's not part of the legally-binding part). When the chat in Counter-Strike is more friendly and civil than Wikipedia, it's not surprising that the WMF has to step in, for legal reasons as well (the "Fuck off" RfC etc). What is especially embarassing about how AN/I handles incivility is that most users don't realize that Wikipedia has 148,477 active editors – being friends with a popular admin shouldn't grant you any special privileges not to follow policies of the site. That absolutely does not belong to a site of this scale. Unblockables, pitchforks and torches, factionalism... The downside is that the private WMF investigations might not be equally fair to all participants, either, if we judge by the Framban. --Pudeo (talk) 22:17, 23 May 2020 (UTC)
    Pudeo, you're absolutely spot-on about Wikpedia's chronic problem of cronyism. This problem has long been in need of a resolution, and ideally the WMF would be able to 'help' in a manner that would actually be helpful. But Framgate, to which you alluded, clearly demonstrated that the WMF is also susceptible to fairly blatant corruption. Moreover, I think it's fair to say that the community had little confidence in the WMF even before that fiasco. Regardless of how the rules are enforced, the system will always be somewhat corrupt. It's just a question of whether we want our community matters to be (mis)handled by people who are part of our community and thus somewhat accountable to us or by people who have few meaningful connections to our work and absolutely no accountability when they makes mistakes. LEPRICAVARK (talk) 22:47, 23 May 2020 (UTC)
  • I join the general group that we are unlikely to disagree much on the base rules (assuming EW isn't in there), but the implementation mechanisms. However, what I'd like to focus more in, is that several above are saying "let's wait for a full copy, then discuss it". At that point, changes are going to be much harder to bring in. Instead, having a better idea for when they initially come to us "what would the communities like to add in", is helpful. I did like @RexxS:'s suggestion of offering a range of community group viewpoints if no single one got consensus. I have a suspicion the WMF may pick the one they like more and completely ignore the other(s), but if we can't get a clear-cut viewpoint, that option has some major positives to it. Nosebagbear (talk)
  • In terms of what I'd like to see specifically, ideally I'd prefer implementation by communities with ARBCOMs and active conduct boards, and where their current policy covers everything within the minimums within a UCOC, be provided by the Community. There would need to be a corrective mechanism for communities which run out of control, conduct-wise, despite an ARBCOM, but that would need to be a general tool (rather than them just pulling out individual cases). Nosebagbear (talk) 09:18, 24 May 2020 (UTC)
  • A minimal (basic) global set of moral rules (i.e. rules of behavior) is necessary. Tgeorgescu (talk) 21:30, 25 May 2020 (UTC)
  • I have no confidence whatsoever in the WMF even to consider points raised by those who actually work on creating an informative and neutrally worded encyclopedia. The notion that they can or should even seek to impose a uniform code of conduct defining civility for volunteers worldwide is an affront, and their stated basis for so doing: that some female editors have complained that having their contributions edited by others inhibits their attempts to slant our coverage and is inherently biased—demonstrates their contempt for us and what we do that enables them to draw their salaries. There are conversations to be had about entrenched bias. There's research to be done to replace the WMF's woeful assumptions about percentage of female editors, which at this point I believe are deliberately alarmist (I am not male just because I don't have a pink userbox). Yes, there are double standards on civility and we could do better; WMF employees are among the worst offenders when it comes to sarcasm and dismissiveness, and the canard that not using four-letter words is a universal requirement to be treated with respect is classist and parochial even in the US. But the WMF don't listen to editors' wishes or show respect for the editing community. No, we should not try to meet them partway, and beg for them to understand, or hops they don't mean en.wikipedia as well. We should refuse to accept that they have any right whatsoever to dictate to us, and call them on their own intolerance and intolerable rudeness. Yngvadottir (talk) 21:58, 25 May 2020 (UTC)
  • I won't mince words here. This is bad. Wikipedia is not the first project on the Internet to have a code of conduct imposed on it, and these things are typically social justice takeovers that make everyone guilty but are enforced selectively. The Fram case (accompanied as it was by vague accusations of harassmeent) makes this more obvious. So does the list of social justice groups in the Signpost article that the WMF consulted with in April 2019. Ken Arromdee (talk) 01:47, 26 May 2020 (UTC)
  • Acting on the principle that a good defense is a good offense, I went ahead & proposed my own draft for a Universal Code of Conduct over at Meta. The important points are simple: except for defined & currently accepted areas, the Foundation will not intervene where the communities have a functioning governance system; if they do intervene, they must provide a justification for their action; & that there be a model Code of Conduct that applies to communities where none exist. I don't know how the PTB will respond to my proposed draft, but I hope it is in the spirit it was offered. -- llywrch (talk) 18:16, 26 May 2020 (UTC)
  • A friend of mine correctly pointed out that in situations like this, you should always summarily oppose to start and have your support won. Then, if things make sense, maybe it gets adopted. But without significant buy in, the answer is no, and should be anticipated to be no, unless the WMF convinces us they present us with a set of rules we agree with, and convince us they are capable of enforcing them without overstepping. My answer would have been no before FRAMGATE. It's even more no after FRAMGATE. I'm open to have my mind changed, but the WMF needs to do the legwork here. Headbomb {t · c · p · b} 14:34, 27 May 2020 (UTC)
  • The WMF has a severe case of cranial rectal inversion, demonstrated not only with Framgate, but their tone deaf response to most everything (including private correspondances). Frankly, we need less WMF involvement, not more. Let them stick to what they do best, raise money, and blow money unnecessarily. They have the reverse Midas touch. Dennis Brown - 2¢ 16:43, 27 May 2020 (UTC)

En.wikipedia would be much better served by somebody who just keeps the servers and software running. Maybe we should replace WMF.North8000 (talk) 18:58, 27 May 2020 (UTC)

    • Any editor (indeed, any person) can start a new website cloning all of Wikipedia's content and running it under whatever rules they like. However, since WMF owns the trademark registrations, the name "Wikipedia" can not be used outside the structure of the WMF without their permission. BD2412 T 19:24, 27 May 2020 (UTC)
  • Wasn't this already rejected by the community on Meta? GMGtalk 12:24, 28 May 2020 (UTC)
  • I have to agree with Tony. Any RfC or set of RfCs here is unlikely to be helpful. WMF has made mistakes but that doesn't mean they're always wrong, and often the first instinct here on enwiki seems to be "If it came from WMF, I'm agin' it." WMF aren't our enemies. —valereee (talk) 14:19, 28 May 2020 (UTC)
    Well, Valereee, I think it's more a question of "I've seen what happened before." In the past, vague statements like this were followed by disastrous, heavy-handed moves from WMF, be that in the form of software or Framgate. Yes, we always try to assume good faith, but when someone's already abused that assumption repeatedly, we don't keep blindly doing it. So in this instance, I certainly understand why the reaction is "Good God, not this again." Seraphimblade Talk to me 18:43, 1 June 2020 (UTC)
  • A couple of months ago, circa Framgate, I would have regarded anything involving WMF in enforcing civility as a terrible idea. But since then, I've become pretty much disgusted with Wikipedia, and particularly with what does, indeed, seem to me to be an intractable problem with incivility. I've largely given up on editing, on the theory that it makes no sense for me to volunteer time and effort for a project that makes me feel unhappy, when I can use my time and effort elsewhere with much greater satisfaction. I've briefly come back to participate in the soon-to-be-closed ArbCom Medicine case, because it was supposed to deal with some of the things that have made me unhappy here. And as that case looks to be on the verge of closure, it looks to me to have ended up appallingly. Not only does it look unlikely that the Arbs will do what they needed to do about toxic (or whatever other term one wants to use) conduct, but it's becoming pretty clear to me that several of the Arbs are not even reading the evidence. It's a case study in institutional failure. Now, from what I saw during Framgate, I doubt that WMF can do any better, but – and I surprise myself to find me saying this! – I'm actually kind of curious to see whether WMF should take over from ArbCom. They probably won't do any better than ArbCom, and likely will be even worse, but for en-wiki it may be the kind of shock to the system that will either lead to an actual improvement here, or that will, well, hasten the day. --Tryptofish (talk) 18:21, 2 June 2020 (UTC)

Toxic

Every time they say "toxic" in a document, a little part of me wants to scream inside. I have proposed on Meta that the term be avoided. — Pelagic ( messages ) Z – (02:59 Sat 30, AEST) 16:59, 29 May 2020 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(policy)/Archive_157&oldid=1131532903"