Wikipedia:Village pump (policy)

The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines.
If you want to propose something new that is not a policy or guideline, use Village pump (proposals).
If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards.
This is not the place to resolve disputes over how a policy should be implemented. Please see Wikipedia:Dispute resolution for how to proceed in such cases.

Please see this FAQ page for a list of frequently rejected or ignored proposals.

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

Are policies being used to the detriment of Wikipedia?

I would like to continue a discussion I started earlier, see Wikipedia:Village pump (policy)/Archive 152#Are policies being used to the detriment of Wikipedia?. Recently I worked several hours to add some recent research on Parkinson's disease to the article on it. Immediately it was reverted by one of the guys whom I complained about earlier, a group of editors who put watch-points on huge numbers of articles and whenever anybody edits those articles they immediately check to see whether, in their opinion, it conforms to the rules of Wikipedia. So in this case, it was reverted on the grounds that the references were either primary or "predatory". "Primary" means they were research articles in peer-reviewed journals, and "predatory" means that they come from those scurilous popular science magazines like (in this case) New Scientist. I am told (on Talk:Parkinson's disease) that we have to wait until someone publishes a review article (not a research article) in a peer-reviewed journal! The policy cited is Wikipedia:Identifying reliable sources (medicine). So if that policy really means that we cannot put the exciting research of the last year into the article, well then, I think the policy should be changed. Eric Kvaalen (talk) 17:21, 8 January 2020 (UTC)[reply]

I would recommend you pursue any further discussion about a discrete guideline at that guideline's talk page, in this case WT:MEDRS. I would further comment that you will need to have better rationale than you have provided here and previously for any change in this regard, and you will need specific changes that you would like to make to specific sections of that guideline. Good luck. --Izno (talk) 17:35, 8 January 2020 (UTC)[reply]

Yes, I do believe that policy is meant to stop exciting research of the last year being added. It's on purpose and for what many consider good reasons. One is that exciting research of the last year is often at least partly wrong. Gråbergs Gråa Sång (talk) 09:35, 9 January 2020 (UTC)[reply]

As noted by Izno, this is not the right forum to pursue these questions. Peter coxhead (talk) 10:30, 9 January 2020 (UTC)[reply]

this is absolutely the correct forum to pursue these questions. That’s what the village pump is for. I’m amazed that you’d say it isn’t.

Please carry on with this topic. —Sm8900 (talk) 10:59, 9 January 2020 (UTC)[reply]

This is a generally correct place to discuss this topic, but guideline change, unless you are starting a request for comments, is almost always better discussed at the talk page of the guideline in question. It is a correct forum, but only minimally so. --Izno (talk) 15:58, 9 January 2020 (UTC)[reply]

if you need to cover information that is not covered in a journal, try looking to see if it is covered in major newspapers, rather than just online publications like Live Science. -Sm8900 (talk) 11:07, 9 January 2020 (UTC)[reply]

Major newspapers are often not considered good enough per WP:MEDRS either, but context matters. Gråbergs Gråa Sång (talk) 11:45, 9 January 2020 (UTC)[reply]

I prefer to have a discussion here rather than on the talk page of the policy about "reliable medical sources". I want the input of the general public, not some clique of guys who made that policy! Now, concerning what user Gråbergs Gråa Sång has written above, it may be that some things reported in the last year turn out to be partially wrong, but we can still report the research! If we were to exclude everything from Wikipedia about which there is any shadow of doubt, then there wouldn't be much left. Our readers deserve to know what's goin' on in a field, not just the established, conventional wisdom. And Sm8900, the popular science source I used is not "Live Science", it's New Scientist, which is a print magazine that has been going for more than sixty years. It is "the world's most popular weekly science and technology magazine" (see [1]). Eric Kvaalen (talk) 05:45, 13 January 2020 (UTC)[reply]

Didn't ping Gråbergs Gråa Sång and Sm8900. Eric Kvaalen (talk) 11:42, 20 January 2020 (UTC)[reply]

hi. Thanks for the reply! That’s good to know. Sm8900 (talk) 19:51, 20 January 2020 (UTC)[reply]

@Eric Kvaalen: Concerning the "predatory" bit, this is not because you have used New Scientist for a source (which would fail being a WP:MEDRS-compliant source), but rather because you used MDPI and Frontiers journals, which have various problems. Calling them predatory is a bit too extreme (Zefr has a propensity to do that), but they are not reputable venues, and again, do not satisfy WP:MEDRS. Headbomb {t · c · p · b} 05:03, 23 January 2020 (UTC)[reply]

@Headbomb and Gråbergs Gråa Sång: Thanks for the explanation of "predatory". But I still don't know what journals that I cited are considered suspect. And in any case, I disagree with this idea that someone can come along and delete all my work just because he thinks that some of the journals referenced are "predatory" and some are "primary". We want our readers to have up-to-date information on the research that has been done. Or more to the point, our readers want that! Right? I don't think that Zefr considered each statement that I made and referenced, and decided that each one was too doubtful to tell the readers. I think he just hit Undo. Either these guys, like Zefr, are enforcing incorrect interpretations of the policies, or the policies need to be changed. (I'm not pinging Zefr, because this is not meant to be an argument just about what he did in this case. It's a general problem, with several guys doing it.) Eric Kvaalen (talk) 05:33, 28 January 2020 (UTC)[reply]

@Eric Kvaalen: Several people are tackling several different problems in several different ways, some with more tact than others, some with poorer arguments than others. So unless you give us other situations, it is hard for anyone to generalize anything and give you broader advice. However, one thing that should be clear is that WP:MEDRS has to be followed when WP:MEDRS-covered claims are being made, and that Frontiers Media and MDPI journals generally don't qualify as WP:MEDRS-compliant sources, regardless of if one considers those journals and publishers to be fully predatory like the garbage from OMICS Publishing Group, or merely 'questionable/unreputable'. Headbomb {t · c · p · b} 06:10, 28 January 2020 (UTC)[reply]

@Headbomb: But what I've been trying to say is that I don't think the "MEDRS" (medical reliable source) policy is good, if it excludes putting in the research that I put into that article. I'm not asking for advice. I'm asking people to think about what kind of articles we want in Wikipedia. If you would like more examples of the same sort of problem (not just with medical articles), see the older thread that I mentioned at the beginning. Eric Kvaalen (talk) 17:05, 2 February 2020 (UTC)[reply]

@Eric Kvaalen: "If it excludes putting in the research that I put into that article." That's exactly what the policy is designed for, see WP:WHYMEDRS. We don't want such research featured in Wikipedia, because it is too early, too erratic, and too unreliable in the evidence chain for Wikipedia. Headbomb {t · c · p · b} 19:29, 2 February 2020 (UTC)[reply]

@Headbomb: Yeah, well, that's your opinion. The question is, does the reading public agree with you? I doubt it. Eric Kvaalen (talk) 16:47, 9 February 2020 (UTC)[reply]

What the reading public wants is irrelevant. This is what the community wants. Headbomb {t · c · p · b} 09:15, 10 February 2020 (UTC)[reply]

Let's avoid making assertions about what "the community" wants. We don't all the same opinions about everything, and it appears from this discussion that at least some part of "the community" also wants to take the suspected preferences of the reading public into account.

Eric, I'm not going to say that we're perfect, or that we don't go overboard sometimes. Some of us would really like to exclude anything except solid Evidence-based medicine (which sounds fine until you realize that's about 50% of regular, conventional medicine, that there's more to medicine and medical conditions than objective facts, and that "the community" rejected the proposal to elevate the scientific point(s) of view over all of the non-scientific [that word means "arts and humanities and law and business and stuff", not nonsense] POVs years ago).

In general, it's my experience that mentioning a big media sensation in an article, in a very small way, is not an unreasonable way to reduce edit warring and get a compromise that editors can live with until the media hype dies down. But in other cases, I think it's easier just to play the game their way. So they don't want you to cite a "primary" peer-reviewed research paper on whether having an appendectomy reduces the risk of Parkinson's? Fine: cite PMID 31713092, which is a review article instead. You can do this by finding the paper you'd like to cite at PubMed – https://www.ncbi.nlm.nih.gov/pubmed/30381408 – and then looking for the box on the side that tells you some other papers that are citing it. Start with anything in that list that's tagged with a blue "review" label and see what they say. WhatamIdoing (talk) 01:54, 11 February 2020 (UTC)[reply]

@Headbomb: The policy specifically says that newspapers are valid, depending on circumstances. allowing mainstream media is one way to make sure we are expanding as a genuine resource. --Sm8900 (talk) 16:52, 9 February 2020 (UTC)[reply]

@Sm8900: the policy specifically warns against using newspapers to make WP:MEDRS claims or determine the WP:DUE-ness of scientific coverage. Headbomb {t · c · p · b} 09:05, 10 February 2020 (UTC)[reply]

@WhatamIdoing: Thanks for the suggestion! @Headbomb: I'm amazed that you say that what the reading public wants is irrelevant, and that the only thing that matters is what "the community" wants! Who is this community anyway? Those who managed to get their opinions cemented into Wikipedia policy? We're not editing Wikipedia just for ourselves, or just for the pleasure of enforcing the rules. Eric Kvaalen (talk) 08:42, 18 February 2020 (UTC)[reply]

Eric Kvaalen, it seems to me that the opinions of the reading public can readily be discounted when that population does not intersect with the one participating and forming consensus on Wikimedia projects. This is why: because Wikipedia is "the free encyclopedia that anyone can edit" and therefore any sufficiently interested reader of Wikipedia can become an editor of Wikipedia with little effort. If anyone in "the reading public" feels strongly about a point of policy on Wikipedia and wishes to effect change, then the way to do this is to become editors and have their voices heard. Otherwise, the opinions and tastes of the nebulous, amorphous, "reading public" can never be known well enough for us to form policies and guidelines in the first place. That's why it doesn't matter, because it's too difficult to measure and it's easy enough to become an editor, and therefore, part of the community. Elizium23 (talk) 08:49, 18 February 2020 (UTC)[reply]

Not only that, but if you made a poll that asked the scientifically illiterate general public questions about science, you will end up with answers that don't reflect the opinions that matter. If I asked people "Should legislators make laws mandating that doctors warn parents against the dangers of mercury in vaccines and their links to autism prior to vaccination", I would get "Oh yes, I don't want my child to get autism!" from a significant portions of them. So yes, what readers "want" is irrelevant here. Headbomb {t · c · p · b} 10:51, 18 February 2020 (UTC)[reply]

Eric wrote: We're not editing Wikipedia just for ourselves, or just for the pleasure of enforcing the rules.

Some of us are. I'm not saying that's a good thing, but, for better or worse, it's a true thing. Not everyone is as selfless and idealistic as you. WhatamIdoing (talk) 20:52, 18 February 2020 (UTC)[reply]

@Elizium23: Of course theoretically anyone can become an editor of Wikipedia. But there are milliards of people who just use Wikipedia as a reference. When they want to know about Parkinson's disease, they go to the Wikipedia article on Parkinson's and read. They're not gonna start arguing on the policy pages in favor of putting the latest research results. In fact, they will have no idea that the latest research results have been deleted from the article because of some policy about not using primary sources! (Or "predatory sources".) But they would certainly be offended if they knew. And Headbomb, I'm not advocating putting in nonsense about vaccines or whatever. I'm talking about the latest scientific research. WhatamIdoing, thanks for the compliment! Eric Kvaalen (talk) 12:39, 28 February 2020 (UTC)[reply]

Unless the latest scientific research has been vetted through reviews and meta-analysis, it is not ready to be featured in encyclopedias, because primary research−, especially in biological sciences, is not reliable. Again, see WP:WHYMEDRS Headbomb {t · c · p · b} 13:15, 28 February 2020 (UTC)[reply]

Is it acceptable to blank userspace sandboxes of long-term/established, but inactive editors?

Firstly, apologies for the delay in closing this. I was hoping to close it as a team with any other editor but WP:ANRFC continues backlogged and unattended.

Coming to the crux of this RfC, the general consensus is that it is not acceptable to blank userspace sandboxes of long-term/established, but inactive editors. Now, the fine print that most editors have also pointed out (and which apply by default, thus status quo) is that we have existing policies which apply to userspace drafts (WP:STALEDRAFT, WP:NOTWEBHOST, et al.) In some cases, deletion would be more applicable than blanking as well (which might conflict with STALEDRAFT point 4) but that is outside the ambit of this RfC. The community did not come to an explicit definition of who are long-term editors and what period of inactivity should be used to determine editors as inactive, and thus the community should exercise common sense when applying this consensus to userspace drafts. The takeaway from this RfC is that inactivity of the userspace draft's author should never be a reason for its blanking.

As for the sub-proposal, there is no consensus to unilaterally revert blankings that have been already done due to inactivity. --qedk (t 桜 c) 20:59, 26 February 2020 (UTC)[reply]

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 debate may be found at the bottom of the discussion.

Hi folks. Not to specifically call anyone out, but I have noticed that some editors are wholesale blanking userspace sandboxes of established, but inactive editors, citing guideline WP:STALEDRAFT, #2. This is a bad practice IMO. Not only is it a nuisance for inactive editors for when they return, but also it encourages unhelpful busy work amongst active editors.

So my question is as follows: Is it acceptable to blank userspace sandboxes of long-term/established, but inactive editors? -FASTILY 23:36, 22 January 2020 (UTC)[reply]

Yes. But, there should be a reason. The obvious reason from the words is that the content of the sandbox is "stale", as in no longer true. This is not just "old". Other reasons include dubious content that is turning up on internal Wikipedia searches. This really should be the exception, but far better to blank mildly problematic material than to seek its deletion where WP:ATD would favour blanking.

A hyperactive gnome who has taking to blanking inactive user's sandboxes indiscriminately should be asked to stop. I think that users over-policing others userspace are doing a net disservice to the project. --SmokeyJoe (talk) 23:44, 22 January 2020 (UTC)[reply]

The reason should be a good reason, and possibly a very good reason. "Old" is not a reason. Per User:Graeme Bartlett below, any possible use is adding content to mainspace is a very good reason to not blank. Userspace is No_Index-ed, so blanking serves only to hide the content from people searching userspace with the internal search engine. Mildly inappropriate things, like a list of a child's school friends, is good to be blanked. --SmokeyJoe (talk) 02:19, 23 January 2020 (UTC)[reply]

I think these blankings should be required to use {{Inactive userpage blanked}} or {{Userpage blanked}}. The first is very gentle with not even a hint that the page was inappropriate. I think it is well used for blanking possibly childrens' personal information, or a promotional draft topic. The second has a very subtle implication that something was inappropriate about the content. --SmokeyJoe (talk) 02:35, 23 January 2020 (UTC)[reply]

@SmokeyJoe: postings of childrens' personal information should be referred to WP:OVERSIGHT. — xaosflux ^Talk 02:44, 23 January 2020 (UTC)[reply]

User:Xaosflux, what if it is just a list of names? "I like to play Fortnite with my friends, Joe, Jill and Jack". Personal, but not identifying. Their being children is presumed. --SmokeyJoe (talk) 03:24, 23 January 2020 (UTC)[reply]

We usually take "personal information" to be shorthand for non-public personal information and are usually extra accommodating for minors - that example alone wouldn't need suppression, but if anyone is in doubt feel free to refer to OS, we'd rather say "it's fine" then miss something. — xaosflux ^Talk 03:32, 23 January 2020 (UTC)[reply]

(edit conflict) I'm not sure how this meets WP:RFCBEFORE, and qualifies for having bot pings for wide range of editors, which has a non-negligible fatigue factor on an volunteer project. Having said that, with no context at all, no, these people should go do something actually productive instead. This is probably top five of the silliest things you could do on Wikipedia that has no impact on our readers whatsoever. It has little to nothing to do with actually building an encyclopedia. GMG ^talk 23:46, 22 January 2020 (UTC)[reply]

@Fayenatic london: Stop it. Save the Foundation the fraction of a fraction of a penny by blanking a user talk page when it literally makes no difference to anyone ever. You will die. You have a limited amount of time to contribute to this project. Use it to do something that actually matters even a tiny bit. GMG ^talk 23:53, 22 January 2020 (UTC)[reply]

no blanking for being stale is not a reason. Perhaps there could be another reason to blank if the page was harmful in some way. However old abandoned userspace drafts may still be turned into articles, and I have actually done that in the last few days. If they are blanked then no one will bother with this small chance of benefit. Graeme Bartlett (talk) 01:01, 23 January 2020 (UTC)[reply]
No (unless the sandbox page violates a policy). That is useless editing, especially when there are so many actual problems in actual articles that need fixing. Sandboxes are not necessarily, and often are not, "Unfinished userspace drafts" (quote from STALEDRAFT). Often they are experiments with code, samples of things that editors want to keep around, or examples that are being used as a demonstration to inform a talk page discussion. They may look like drafts, but unless an editor can read minds, there is no way to know. – Jonesey95 (talk) 01:43, 23 January 2020 (UTC)[reply]
No - not without very good reason, but then shouldn't we be looking at a rationale for deletion, not blanking? Looking at my multitude of chaotic subpages, a few could certainly do with a darned good sort out and tidy up, but I don't think that's reason enough to blank them if I stopped editing. There are a few gems in there that someone might find of use, and the rest are, like me, 'mostly harmless'. The contents would still be there in the history of the blanked page (assuming you didn't mean 'deletion'), so what would be the purpose of blanking content? I can't see any reason to do it unless it was breaching one or other of our content policies. I'm quite OK with deleting individual elements that are causing disruption, say to how Category content is displayed (e.g. {{adopt me}} templates in sandboxes or remaining on user pages of long-inactive editors.) But only if we were to agree that it was OK to blank the entire user and talk pages of all inactive or deceased editors, would it then be fine. But would we ever agree to do that? Nick Moyes (talk) 01:45, 23 January 2020 (UTC)[reply]
No. Why on earth would anyone be sifting through sandboxes? One shouldn't be blanking inactive user's pages, why would you do it to their sandboxes? I think some calling out is in order, actually. Especially if it is being done on a wide scale. Ifnord (talk) 02:05, 23 January 2020 (UTC)[reply]
Yes. More under WP:STALEDRAFT point 4 (which requires that there be problems with it, like BLP, reliability, or promotional stuff) than totally arbitrarily... but almost any draft is going to have one of those problems, since if it didn't it wouldn't still be a draft. Wikipedia isn't a web host and we should discourage people from leaving things like those there, especially since there is a small risk that they could be mistaken for an article if linked to directly. Also, with regards to the "those people should find better things to do" argument - keep in mind that the implication of this RFC is that we would then devote administrative effort to policing them and stopping them from doing such blanking, which only makes the problem worse. If the blanking is at worst harmless (and serves some useful purpose for the reasons I mentioned), I don't see the value to adding red tape forbidding it, especially since we absolutely want to blank seriously problematic stuff and trying to get stricter about requiring that it be problematic would be wasting even more editor time and arguments over stuff that doesn't matter. Blanking is easy, lightweight, and harmless. (Also, this RFC is a waste of time and the idea of starting it to prevent people from wasting time blanking stuff probably deserves a trout. If people think the whole issue is a silly waste of time, then we're better off dropping it and not worrying about what anyone does to stale drafts as long as BLP issues and promotional material isn't left up.) --Aquillion (talk) 02:22, 23 January 2020 (UTC)[reply]
I have blanked some user pages including sandboxes because they contained blatantly promotional material but in general no, people should not blank such pages without a good reason. If someone is doing this and they persist after having this discussion drawn to their attention, they should be blocked. Johnuniq (talk) 02:24, 23 January 2020 (UTC)[reply]
Meh I'm not seeing a strict policy discussion that needs to be had on this as some sort of standalone rule. I think it would be bad form for anyone to do this just because or in any sort of non-trivial volume. That being said, in most cases I think it is fine on a small-scale case-by-case nature; though outright blanking would be less desirable than at least placing a {{Inactive userpage blanked}} template. — xaosflux ^Talk 02:28, 23 January 2020 (UTC)[reply]
One case where I think this is normally OK is for a user primary sandbox (e.g. User:User/Sandbox but not User:User/SomeTopic) that contains general non-encyclopedic things (like abandoned fake big brother graphs that I have no idea why people make, or an obvious resume dump) - as a preferred route over dragging the page to MFD. — xaosflux ^Talk 03:16, 23 January 2020 (UTC)[reply]
In the context of this questions though, I wouldn't expect established/long-term users to have this sort of cruft there. — xaosflux ^Talk 12:56, 23 January 2020 (UTC)[reply]
Generally, no. Some possible reasons for exceptions appear above. Johnbod (talk) 02:54, 23 January 2020 (UTC)[reply]
No There are valid reasons to blank user pages, but inactivity should not be a factor in any circumstance. SportingFlyer T·C 03:43, 23 January 2020 (UTC)[reply]
No – not just for inactivity; only if there is a reason (like copyvio, BLP vio, etc.) – Levivich 04:45, 23 January 2020 (UTC)[reply]
Yes for duplicate articles, and other pages causing additional maintenance work e.g. when checking red links: WP:FAKEARTICLE which says "Userspace… should not be used to indefinitely host… old revisions… or your preferred version of disputed content". Blanking or redirecting is the standard approach set out at WP:STALEDRAFT, and avoids taking up other editors' time for an MFD. The positive reason for blanking is to save checking backlinks after deletions. XFD processes require cleanup in their wake, and should not give rise to more work for Wikipedia:WikiProject Red Link Recovery. That is to say, if when checking backlinks I find a userpage, I blank it so that it no longer links to categories/ templates /anything else that might be deleted; then, if those do get deleted/renamed there will be one less incoming redlink from a userpage to be checked. If the editor is long gone, I just blank the page following WP:STALEDRAFT; if the last edit was more recent, I sometimes first update the red link, and then leave an explanatory edit summary such as [2]. What has given rise to this "unhelpful busy work" – has an editor complained in a case where I omitted to leave an explanation? – Fayenatic London 14:39, 23 January 2020 (UTC)[reply]
- My actions are also consistent with WP:ABANDONED #Guidelines. The many editors asserting here that "there is no reason" have probably not spent much time doing cleanup of red links after XFDs. – Fayenatic London 23:05, 23 January 2020 (UTC)[reply]
- As more editors are naming me as a problem, I'm trying to remember what else I have done in the past that might have annoyed anyone. If the user is active, I usually just update the linked categories after renaming, although I might then blank the page if it's duplicate content as required under WP:FAKEARTICLE. There have been cases when I found backlinks coming from a couple of drafts by the same user, and then I checked what else the editor left behind, in case (i) any of it is suitable to be submitted for assessment as a draft article, or (ii) any of it is problematic as BLP. Apologies if I have then taken action with other junk that should have been left alone. – Fayenatic London 10:01, 24 January 2020 (UTC)[reply]
No... I have never understood the rational behind STALEDRAFT. If something in userspace is problematic, I agree that it should be removed (deleted or blanked). But the question of whether the user is active or inactive is IRRELEVANT to that determination. If there are valid reasons to delete or blank material in userspace then remove it... there is no reason to wait until the user becomes “inactive”. If, on the other hand, the material is acceptable for userspace while the user is active, it should still be acceptable when the user becomes inactive. There is no NEED to remove it. It’s not like we need to free up the space for someone else. There is no harm in letting it just sit there in userspace... forever. Blueboar (talk) 15:20, 23 January 2020 (UTC)[reply]

That said - I would be open to further discussions on what should (and should not) be allowed in userspace. Perhaps we do need further limitations on what userspace is used for (or, to put it another way, limitations on HOW we use userspace). The point being that any limitations agreed to would apply to ANY userspace page... active or inactive. We need to eliminate the idea that something can be “OK while the user is active but not OK if the user leaves.” Focus on the material (and why it is problematic), not the active/inactive status of the user. Blueboar (talk) 16:43, 23 January 2020 (UTC)[reply]

Blueboar, We already have Wikipedia:User pages which covers what userspace is for (and what it's not for). -- RoySmith (talk) 17:27, 23 January 2020 (UTC)[reply]

Yes, I know... my point was to say that I would be open to amending that page if people think there is something not covered there already. However, the idea that the acceptability of MATERIAL in userspace should be based on the active/inactive status of the USER is ridiculous. Blueboar (talk) 19:16, 23 January 2020 (UTC)[reply]

No. There is absolutely zero value to blanking a userspace sandbox. If it's objectionable for some legitimate reason (WP:BLP, WP:copyvio, WP:attack, WP:G11, WP:U5, or maybe a few others) then it should be deleted via WP:CSD if applicable, or WP:MfD otherwise. If it's just stale, who cares? It's causing no harm in userspace. I've got stubs in my userspace that I haven't worked on in over 10 years. I'd be really pissed if anybody blanked them. -- RoySmith (talk) 16:06, 23 January 2020 (UTC)[reply]
No. At least not without some very good reason to do other than the fact that they're old and the user is inactive. — TransporterMan (TALK) 18:27, 23 January 2020 (UTC)[reply]
No. I see some assumptions above that these are all drafts and the stale draft criteria should apply, however user sandboxes are not the preferred location for drafts, and may people use their sandboxes for other things besides drafts. There is no reason to blank someone's coding experiments, test page, page of lorem ipsum text, or whatever else people are using their sandbox for. ~ ONUnicorn^{(Talk|Contribs)}problem solving 18:40, 23 January 2020 (UTC)[reply]
Of course it's not acceptable unless there is some other reason, such as spamming or WP:BLP violation, for removing the content. Don't people have anything better to do? Phil Bridger (talk) 18:54, 23 January 2020 (UTC)[reply]
Yes with a reason. I sometimes do this after cleaning up after closing TfDs. Say an editor use their sandbox to test a template that is getting deleted/merged then blanking the now useless page is a good way to remove the page from Special:Wanted templates when it gets deleted. It's a useful tool when cleaning maintenance categories with basically zero costs. Systematically going through sandboxes is of course not appropriate. ‑‑Trialpears (talk) 23:24, 23 January 2020 (UTC)[reply]
Who cares. I wouldn’t waste my time doing it, but I also think those who waste their time objecting to it should find better things to do. TonyBallioni (talk) 01:39, 24 January 2020 (UTC)[reply]
No unless within policy. Many good points have been made above, particularly GMG—Fayenetic, you're wasting your time and ours. @TonyBallioni: to be fair, if someone wasn't already wast[ing] their time doing it, there world be no need for others to waste their time objecting to it! 🐤 ——SN 54129 08:31, 24 January 2020 (UTC)[reply]
Perhaps we might add a speific CSD criterion, so that unambiguously unwanted pages can be removed, but others must be referred to MfD, and useful content can be rescued? We might also consider the case of sandboxes of deceased editors, and separately those of banned users. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:00, 24 January 2020 (UTC)[reply]
No, we already have adequate policy to deal with stuff where there is a need to remove it. Deletion or blanking of otherwise uncontentious sandboxes has no benefit, and might deter the return of some of our long missing editors. Worse it prevents the process of honouring deceased Wikipedians by completing their drafts. Ϣere SpielChequers 16:19, 24 January 2020 (UTC)[reply]
No primarily because, as stated in the OP, "encourages unhelpful busy work amongst active editors" Wikipedia already has too many nannys running around doing things like this. We need to discourage that. --Jayron 32 16:25, 24 January 2020 (UTC)[reply]
Wait (or NO) - perhaps I've misunderstood what's going on, but isn't MfD the correct venue for this, or at least tagging it and letting an admin decide? No editor should take it upon themselves to blank anything, and I don't believe an admin would just blank a page without justification. ^Atsme _Talk 📧 16:30, 24 January 2020 (UTC)[reply]
This is a bizarre question. One wonders what the upside is. It's like, "Dear Abby, Is it okay to go through someone else's trash and collect certain kinds of trash so I can put it in my trash? No? OK thanks" -Jordgette [talk] 18:28, 24 January 2020 (UTC)[reply]
No, as a general rule, allowing for (a few) exeptions, some listed above already. Because there is no net good, space is not a problem, indexing is not a problem. We should have a policy on inactive users, such that after long, really, really long inactivity, as in "presumably dead", allowing (forcing?...) user space to be cleaned up and usernames to be freed up. - Nabla (talk) 19:24, 24 January 2020 (UTC)[reply]
Yes, if the following are all met: 1. The page has something on it that is causing it to appear in maintenance lists, content categories, what-links-here links from multiple pages that could be deleted etc (so blanking it will save editor time), 2. The page appears to have been unused/abandoned (e.g. no significant inlinks and page not edited for 12 months or user not edited for 6 months), 3. A curteous message is left, and 4. The user doing the blanking is in good standing. Blanking a page is not deletion; the page can easily be viewed/revived. Taking the page to MFD would use up more editor time (and bytes). It might be helpful if the blanking editor explained what led them to the page. DexDor^(talk) 19:44, 24 January 2020 (UTC)[reply]
No – User sandboxes vary in the type of material they contain, so whether they could be assessed as drafts much less as stale could end up being an overly subjective determination. Additionally, I don't see how going to the effort of blanking sandboxes benefits the project in any way. If they contain inappropriate categories or something, those could simply be removed by themselves. Master of Time (talk) 22:56, 24 January 2020 (UTC)[reply]
No - There's just no benefit whatsoever. This is one of the maintenance tasks people engage in that I just don't understand. I get digging through userspace looking for spam, copyvios, defamatory content, made up topics, etc. but if you don't find that, why are you messing with sandboxes? Just move on. Especially if it's someone who has clearly demonstrated they're here in good faith. Nobody will ever see these sandboxes/drafts other than the creator and people looking for things to blank/delete, so why bother. (so yes, my "no" extends past established users to anyone who makes a good faith attempt to improve Wikipedia, or who uses their sandbox to experiment in order to better improve Wikipedia). — Rhododendrites ^talk \\ 19:26, 25 January 2020 (UTC)[reply]
Comment - Here is my concern: that the result of this RfC, which is "no" to the point of WP:SNOWing, will be used to say "I would've blanked instead of taken to MfD, but that's not allowed anymore." We already see fairly regularly sandboxes taken to MfD that do not qualify for deletion but are nonetheless deleted "because we're already here" -- taking away one of the alternatives to deletion may exacerbate that problem. Probably best dealt with through a separate discussion, I know, but thought I'd express it here. — Rhododendrites ^talk \\ 19:29, 25 January 2020 (UTC)[reply]

I agree that the consensus is close to SNOW... but my take away is a bit different. People seem to be agreeing that “editor is no longer active“ isn’t ENOUGH to justify EITHER action (blank OR delete). People are saying that there has to be a more substantive reason to act. If there IS a more substantive reason then blanking is still sometimes an option. Blueboar (talk) 20:10, 25 January 2020 (UTC)[reply]

No the only theoretical benefit to the encyclopedia is if the sandbox has something seriously wrong with it such as a BLP violation, copyright violation etc and with an established editor that's unlikely. Otherwise all this accomplishes is to annoy the editor if they ever return to activity. I would suggest that anyone tempted to waste time doing this instead tries one of the many more useful tasks out there. Hut 8.5 14:56, 26 January 2020 (UTC)[reply]
Sometimes/What's the occasion for this RfC? There are a bunch of straw man arguments that editors shouldn't be blatantly patrolling to blank userspace drafts, but is that something that's currently happening, and if it was, was there ever any question that sort of patrolling is unproductive? I've WP:STALEDRAFT blanked userspace pages when processing post-XfD/merger cleanup tasks (ensuring redirects point to the right location, deprecated files/categories are updated in articles, articles using the right template, etc.) and it's often the case that a userspace draft is a copy of an old version of an article (with few edits) and that the editor is not just "inactive" but hasn't been back in years. These drafts will accrue many maintenance edits when they're plainly not in use and likely will never be—they're forgotten copies or aspire to be. Is this RfC really to say that we should continue processing those articles during maintenance instead of taking a second to put them out of circulation? Is it an actual problem that users are having active drafts blanked and that they return, unable to find them again? Having trouble seeing the actual issue here except a growing consensus that stale userspace drafts should not be touched apart from extreme circumstances. I just don't see how that added friction benefits anyone. As a content contributor who keeps maintenance work to a minimum, it certainly doesn't benefit my workflow.

I would suggest clarifying to allow userspace blanking as a last resort (before MfD) when the article has no potential mainspace or communal draftspace use and the user is reasonably inactive (e.g., several years). This is not that different from the extant stale draft guideline. czar 15:41, 26 January 2020 (UTC)[reply]

Sometimes per User:Czar. I've seen much of the same. I find old drafts of articles currently in mainspace that have been left behind for years, sometimes with the editor having been gone just as long. Yet these drafts are still edited, mostly by bots but not always. MB 17:35, 26 January 2020 (UTC)[reply]
Only if there is an other reason aside from it just being not used for a while. >>BEANS X2^t 13:36, 27 January 2020 (UTC)[reply]
Use common sense - if it would probably be deleted at WP:MfD the editor should ask himself: Which is better for the project, to send it to MfD or to be bold and blank it? Reasons to take it to MfD have been raised above (e.g. stale draft, etc.). Also, if is is causing real technical problems that can't be easily worked around, which is better for the project, to edit it so the technical problems go away, or blank it? Note that "the redlink problem" that Fayenatic london raised at 14:39, 23 January 2020 (UTC) is an annoyance if you are checking things by hand, but not a reason to blank or edit another user's page. If an editor is checking things with a script he can reprogram the script to ignore user sub-pages. davidwr/(talk)/(contribs) 20:45, 27 January 2020 (UTC)[reply]
I'm not aware of a script to check backlinks, so checking is all by hand (although if this identifies bulk changes to be made, yes they could be done using e.g. WP:JWB). Note that it would often be welcomed for some user pages to be updated, e.g. renaming an entry listed under "categories that I created". Redlinks bring other pages to light that should be blanked under guidelines e.g. WP:FAKEARTICLE. – Fayenatic London 22:09, 27 January 2020 (UTC)[reply]
It depends and use common sense per User:davidwr, who is on point and says it best, in my view. Generally, drafts should be kept unless there is evidence that the editor has long since abandoned or retired from their account—generally, my "rule of thumb" is any draft or sandbox which has gone unedited in at least 5 years and the editor has shown no sign of activity in at least four of those years. BD2412 said it best in the Wikipedia:Miscellany for deletion/User:Jakefrdrck/sandbox, which closed as "delete," in his comparing it to the real life scenario of the care for their former desk of a long-departed employee. So, in short, my preference is leave as-is until such time the editor has demonstrated they have no intention of returning. Then it can go to MfD, closed as "delete," and WP:REFUND should apply in most cases should they return and wish to undelete their long-stale drafts. --Doug Mehus T·C 21:10, 28 January 2020 (UTC)[reply]
Only if there is a very good reason. IMHO, other users' userspace pages should normally not be tampered with, with the obvious exception that user talk pages are open for appending to anyone who wants to discuss anything (within limits) with the user in question. If a user's sandbox page is causing no problems in main space, category space, etc., leave it alone, no matter how long it has been unchanged. If it does cause problems elsewhere, or if it violates policy (e.g. by being blatantly racist, child-porn, copyvio, etc.) then act as the circumstances require. For a mild problem, leave a message on the user's talk page and see what happens. For a serious problem, the page may have to be blanked or even revision-deleted. For an extremely serious problem, the user's account might even have to be cancelled (after due process). But IMHO a page should not be blanked or deleted for "just" having existed for a long time in an apparently inactive user's own sandbox. — Tonymec (talk) 01:15, 30 January 2020 (UTC)[reply]
Yes - A less tedious process than deletion for promotional content (although CSD may be efficient enough when very blatant) or stale drafts for technical reasons (they turn up redundantly during routine cleanup operations for instance). Turning it into a redirect is often a good solution. Also easily reversible by any editor who may find it useful, so courteous and convivial. If the issue is important like BLP or copyright violations, blanking is not sufficient and we have better processes like CSD, REVDEL... If it's a non-redundant and potentially useful "lost draft", then it can be moved to main or draft space or brought to community attention (MfD, noticeboards, etc). —Paleo Neonate – 22:56, 30 January 2020 (UTC)[reply]
Yes if per DexDor. Nikkimaria (talk) 02:16, 1 February 2020 (UTC)[reply]
No Follow what it says, move it to Draft. Jerod Lycett (talk) 22:00, 1 February 2020 (UTC)[reply]
No. If it is potentially viable mainspace content, move it to draftspace. If it's' worse-than-useless junk, take it to WP:MFD. If unsure, leave it alone; userspace is cheap. — SMcCandlish ☏ ¢ 😼 22:00, 2 February 2020 (UTC)[reply]
Comment The blanking of sandboxes for "staleness" and the debate on why some editors think this is a productive action is the type of insanity which leads some people to stop caring about being part of the production of an encyclopedia. I gnome these days because I do not care to be part of a beaurocratic exercise in pettiness. If you are not directly producing or supporting the creation of content, then I wonder what Wikipedia is for. LessHeard vanU (talk) 22:47, 2 February 2020 (UTC)[reply]
No Unless there is some obvious reason to delete it (non-free content, BLP violations, etc.) — and in that case, it can be sent to MfD instead or CSD if urgent, blanking it would only annoy the user if they return. Why would people be sifting through inactive editor's sandboxes anyway? 173.251.14.133 (talk) 12:17, 6 February 2020 (UTC)[reply]
No While I might buy into an inactivity clause for deletion (but not blanking), there is no reason for another editor to be editing another's userspace. The busy-bodies involved in this practice should be booted from the project. Chris Troutman (talk) 23:15, 6 February 2020 (UTC)[reply]
No What possible virtue is there to this? I would also second Chris' comments above. Andy Dingley (talk) 23:32, 6 February 2020 (UTC)[reply]
For cause only If it's a BLP without adequate sourcing or other obviously problematic material with little chance of being improved, sure, but otherwise I don't see how the current wording of STALEDRAFT applies. Beeblebrox (talk) 00:33, 8 February 2020 (UTC)[reply]
No. I agree, let their user pages remain as they are. --Sm8900 (talk) 16:54, 9 February 2020 (UTC)[reply]
No. Apart from common-sense exceptions (problematic material, abandoned duplicates of old revisions of articles, blatant POV forks, tests of old templates, etc.), userspace pages should not be meddled with, regardless of age. This has the potential to drive away returning editors, and risks throwing away useful content if done at scale. I really don't see the maintenance benefits: there are very few cases where that's needed (like removing mainspace categories, but this should be done across the board irrespective of age), and if editors find themselves inclined to edit in userspace in order to clear some gnoming tasklist, then they'll normally be much better off adjusting their workflows to ignore userspace altogether. – Uanfala (talk) 10:55, 13 February 2020 (UTC)[reply]
No While the arguments in favor as to save time checkign back links etc are compelling, leave em alone. There should be a notice at the top of all sandboxes to the tune of "this is a sandbox not an article" if the material is not being worked on in a timely manner, but no need to find busy work. ^Thanks,L3X1 ◊distænt write◊ 04:22, 15 February 2020 (UTC)[reply]
No - Such blankings are generally pointless. In rare cases where the content poses a problem, the templates suggested by the guideline are useful. "In rare cases, if the content is particularly problematic but does not quaify for speedy deletion, consider blanking and applying these templates" would be better wording for #2 of WP:STALE. — Godsy^(TALK_CONT) 00:44, 16 February 2020 (UTC)[reply]
No, unless they violate policy in some way (WP:POLEMIC, etc.). Sometimes good editors leave who have good sandbox drafts which contain good information no matter what state of completion they are in. There's no reason to blank sandboxes or edit other people's user subpages unless policy is being violated. Softlavender (talk) 04:55, 16 February 2020 (UTC)[reply]
No, with the already mentioned exceptions of policy violations. If the presence of outdated links, templates, etc on these pages is thought to be a problem, I could see just wrapping the whole thing in "no wiki" tags and saving it as pure text. --Khajidha (talk) 23:10, 18 February 2020 (UTC)[reply]

Revert blankings done due to inactivity?

I read a consensus above that blanking due to mere inactivity is not supported, and further maybe, that inactivity is not even a contributing reason for blanking a usersubpage. I take that to imply that the user of {{Inactive userpage blanked}} is disapproved of. Does this mean that the ~4000 uses should be reverted? In contrast, {{Userpage blanked}} is intended for inappropriate content, borderline and not CSD-worthy, although the wording is gentle; it may be used on inactive user's userpages but inactivity is not the reason for use. There are several hundred transclusions of this template. I see no reason to revert the use of this template, because this template should only be used where there was some reason not including inactivity. --SmokeyJoe (talk) 00:27, 30 January 2020 (UTC)[reply]
- The remedy for pointless blanking is not pointless unblanking. I see that Template:Inactive userpage blanked is being discussed for merging to Template:Userpage blanked. Investigation might show that it would be desirable to delete the "inactive" template (or possibly make it a redirect with a strong note in the documentation to not use it merely because of inactivity). Johnuniq (talk) 00:33, 30 January 2020 (UTC)[reply]
  - That sounds sensible. --SmokeyJoe (talk) 06:00, 30 January 2020 (UTC)[reply]
  - We could also make an edit filter to do something when the template is used, ranging from a message asking whether or not to do it, preventing the addition, to blocking the person who adds the template. Graeme Bartlett (talk) 04:23, 8 February 2020 (UTC)[reply]
Support. Softlavender (talk) 04:56, 16 February 2020 (UTC)[reply]
Oppose blanket reversion of edits that were made to fix a problem (such as incorrect categorization). If the user wants the page back (and in 99% of cases they probably don't) they can easily get it back. If for some reason an editor still thinks the page should be "live" they should (1) make sure they don't reintroduce the problem and (2) explain (i.e. in edit summary) why they think the page should be live. Inactivity shouldn't itself be a reason for blanking a page, but it may be a reason why blanking a page (for other reasons) is better than other options (such as asking the user to fix it themselves). DexDor^(talk) 07:38, 16 February 2020 (UTC)[reply]
Oppose per Dexdor. If an editor wants a page back, then can just revert without requesting help from anyone. We should not put back the errors that led to the blanking in the first place. If a page is currently blanked, then the action was obviously uncontested. MB 16:47, 16 February 2020 (UTC)[reply]
Oppose What's done is done; and I don't see combing through places where this happened in the past as a useful activity. Let's just all agree that moving forward, we aren't going to do this, and leave it at that. --Jayron 32 12:55, 17 February 2020 (UTC)[reply]
It Depends - I can accept a “what’s done is done” approach, as long as the practice stops. I agree that it would be pointless to revert the thousands of pages that were blanked on good faith prior to this discussion. However, now that we have a consensus saying that blanking due to inactivity isn’t the right thing to do, any future blanking of this sort should be reverted when found. Blueboar (talk) 13:22, 17 February 2020 (UTC)[reply]

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

Align checkuser/oversight block policies with established practice

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.

Clear consensus to implement the proposed changes. Note that the email directions (per the discussion) have also been updated to avoid OS-related matters being sent to the general functionaries list. Primefac (talk) 02:40, 29 February 2020 (UTC)[reply]

In a recent arbitration case, it came up that our policies use inconsistent language to describe checkuser and oversight blocks, specifically whether a block marked as a checkuser or oversight block "should not" or "must not" be modified by administrators without access to those tools. Without getting too into the weeds on specific rationale (I will add a discussion section) I propose the following changes to the blocking policy and to the local checkuser policy: Ivanvector (^Talk/_Edits) 18:40, 29 January 2020 (UTC)[reply]

To the blocking policy:

From the section WP:CUBL: "Without first consulting a CheckUser, administrators ~~should~~ must not undo or alter any block that is specifically identified as a "checkuser" block, such as through the use of the {{checkuserblock}} or {{checkuserblock-account}} templates in the action summary.^[1]"

References

^ Non-CheckUsers ~~should~~ must not review CheckUser blocks that require access to CheckUser data, e.g., when an editor is professing innocence or is questioning the validity of the technical findings in any way. Administrators may still decline unblock requests that are made in bad faith, are more procedural in nature, or are off topic.

From the section WP:OSBL: "Appeals of blocks that have been marked by an oversighter as oversight blocks ~~should~~ must be sent to the functionary team via email (functionaries-enlists.wikimedia.org) to be decided by the English Wikipedia oversighters, or to the Arbitration Committee."

To the local checkuser policy:

From the section "CheckUser blocks": "These blocks must not be reversed by non-checkusers. Administrators ~~should~~ must not undo nor loosen any block that is specifically called a "CheckUser block" without first consulting a CheckUser."

Ivanvector (^Talk/_Edits) 18:40, 29 January 2020 (UTC)[reply]

Support

Support as proposer. Ivanvector (^Talk/_Edits) 18:37, 29 January 2020 (UTC)[reply]
As this is the obvious intent of the current wording and has been the practice for years. I don’t think this even needs an RfC, but sure. TonyBallioni (talk) 19:02, 29 January 2020 (UTC)[reply]
Support.--Bbb23 (talk) 23:05, 29 January 2020 (UTC)[reply]
Support, but, I would like to hear from checkusers about the possibility of language that better defines when a Checkuser block is made, as opposed to an ordinary block by a checkuser. eg. Is it a checkuser block merely because the checkuser looked at some technical checkuser evidence? Is it a checkuser block when the checkuser relied upon checkuser evidence that should not be disclosed? --SmokeyJoe (talk) 23:30, 29 January 2020 (UTC)[reply]
A CU block must be designated in the block form/log as a CU block, e.g., checkuserblock-account.--Bbb23 (talk) 23:37, 29 January 2020 (UTC)[reply]
Yes, know that, and that seems clear enough. Perhaps a bluelinked "CU block" would be even more clear, if needed. The question is: How does the CU decide whether to designated it as a CU block? --SmokeyJoe (talk) 00:05, 30 January 2020 (UTC)[reply]
That question has nothing to do with this RfC.--Bbb23 (talk) 00:18, 30 January 2020 (UTC)[reply]
I think it does, because it goes to the notion that someone might IAR unblock a newcomer because they infer that the CU slaps CU Blocks willy nilly. Clarifying what the underlying reason for CU blocks can be, I think is desirable. --SmokeyJoe (talk) 06:05, 30 January 2020 (UTC)[reply]
I'll respond to this in the discussion section. It's relevant IMO, but I don't think any changes to the policy are necessary in this regard. Ivanvector (^Talk/_Edits) 13:01, 30 January 2020 (UTC)[reply]
Various organizations disagree on whether shall or must is better, but I think we can agree that should isn't must. Current practice is must, so a fine change. I don't think we need an RfC either, especially as must is language that will soon be adopted by ArbCom. ~ Amory (u • t • c) 18:39, 30 January 2020 (UTC)[reply]
Support as a purely grammatical change. The wording of a rule should unambiguously describe the intent. If the intent is "must not", then the rule should (must, even) say, "must not". -- RoySmith (talk) 20:03, 30 January 2020 (UTC)[reply]
Support – reflects commonly applied and accepted practice. Mz7 (talk) 02:22, 31 January 2020 (UTC)[reply]
Support per RoySmith -- common sense grammatical change. Puddleglum ^2.0 19:01, 31 January 2020 (UTC)[reply]
Support Seems sensible. --TheSandDoctor ^Talk 09:44, 1 February 2020 (UTC)[reply]
Support if there is confusion then this needs to be rewritten to make if clear. Sydney Poore/FloNight ♥♥♥♥ 17:30, 1 February 2020 (UTC)[reply]
Support - clarity is desirable. Cabayi (talk) 19:53, 1 February 2020 (UTC)[reply]
Support – Wikipedia's policies rarely strictly forbid anything, but this is a reasonable exception. ~ ToBeFree (talk) 18:46, 4 February 2020 (UTC)[reply]
Support I just made the same exact changes to BLOCKPOL without realizing we have a RfC open regarding this. This should have one of those "consensus by editing" moves but either way, a no-brainer. Thanks to Izno for pointing out the RfC. -qedk (t 桜 c) 19:24, 7 February 2020 (UTC)[reply]
Support that has been de facto policy, might as well have the policy reflect reality. ~~ Alex Noble - talk 08:19, 10 February 2020 (UTC)[reply]
Support clarity is better and this has been a de facto policy. Pharaoh of the Wizards (talk) 10:36, 10 February 2020 (UTC)[reply]
Support, why not? >>BEANS X2^t 13:31, 10 February 2020 (UTC)[reply]
Support and suggest WP:SNOW close. EllenCT (talk) 20:12, 10 February 2020 (UTC)[reply]
Support This makes complete sense to me. -- Dolotta (talk) 19:37, 13 February 2020 (UTC)[reply]
Support Per above. -FASTILY 19:46, 14 February 2020 (UTC)[reply]
Support per all of the above. OhKayeSierra (talk) 11:38, 24 February 2020 (UTC)[reply]
– John M Wolfson (talk • contribs) 12:55, 24 February 2020 (UTC)[reply]
Support It would make more sense to apply IAR for cases that were innocent mistakes or other rare exceptions rather than have more open ended wording and apply IAR when it is not properly followed. Mkdw ^talk 21:14, 26 February 2020 (UTC)[reply]

Oppose

Should not is preferable. Every hard and fast rule has casualties. See for example the de-sysopping of Bish. All the best: Rich Farmbrough (the apparently calm and reasonable) 13:59, 9 February 2020 (UTC).[reply]

What desysopping of me would that be? I don't seem to have noticed it. Bishonen | talk 14:12, 9 February 2020 (UTC).[reply]
Oppose: this strikes me as a similar case to office actions, but Wikipedia:Office actions reads, Wikimedia administrators and others who have the technical power to revert or edit office actions are strongly cautioned against doing so. Indeed, we can make the same argument that an office action should almost never be undone because it is made with private information that the reversing admin does not have access to, yet the community has still supported reversal of office actions in some cases. I imagine it'd be snowing in the other direction were this proposal about office actions rather than checkusers. I guess the important difference here is that the community trusts checkusers and distrusts the WMF. Well I'm with you on the latter, but not the former. We have a largely outstanding cohort of very trustworthy checkusers and oversighters, but I do not trust them all. Of course, when it comes to actually reverting a CU block, the reverting admin should have a very strong reason why it is an exceptional case that warrants it, and they should understand that there will be consequences to their actions to all involved. — Bilorv (talk) 11:49, 14 February 2020 (UTC)[reply]
Oppose I also thing the "must not" is an overreach. It opens the door to people playing "gotcha" with good-faith admin actions, and this just opens the door to more harassment of admins from people with axes to grind in general against the admin corps. Should not is strong enough, as there should be some common-sense wiggle room in any rule of this nature. I personally have no intention of undoing checkuser blocks willy-nilly, but I also see this change in wording to be not beneficial to the project. --Jayron 32 20:25, 14 February 2020 (UTC)[reply]
Oppose; in general agreement with the sentiments expressed above, given my perception that with all the trolls, hackers and bad actors lurking on the Internet, checkuser determinations cannot always be made with absolute certainty. We should allow some wiggle room for April Fools' 'zillas and good-faith alternative accounts which may have been absentmindedly not identified on a timely basis. wbm1058 (talk) 13:51, 16 February 2020 (UTC)[reply]
Oppose due to a necessity for clarity in emergency situations. If a CheckUser/Oversight account is obviously compromised, for example blocking every admin on the site and adds penis.jpg to all the infobox templates, I wouldn't want anyone hesitating for even a few minutes before deciding to WP:IAR and undo the blocks anyways to fix the problem. A few minutes is an eternity in internet time and if God-forbid a CU/OS account was compromised it should be abundantly clear to all admins that it's appropriate to undo these types of blocks in emergency situations. Aside from this caveat though, I'm in favour of the language change. But I'd very much like a specific exemption be made for emergency situations where it might not be possible to immediately get a CheckUser/Oversighter/ArbCom. Chess (talk) Ping when replying 06:28, 26 February 2020 (UTC)[reply]

Discussion

The rationale for restricting management of checkuser- and oversight-blocks to administrators with access to the tools is that the blocks are based on private information, and more specifically that the private information directly contributes to the reason for the block. An administrator who cannot review the private information cannot assess the block simply because they don't have all of the information. The Arbitration Committee published a statement many years ago explaining all of this in better terms than I can, and the policies also refer to former checkuser Mackensen's much more to-the-point advice here.

It's come to light more recently that some users believe the Committee's use of "should" in their statement, and its use in the policies, implies that there are circumstances where an administrator can adjust such a block if they believe they have a good-faith reason to do so, without having first consulted with the blocking checkuser/oversighter (i.e. without having ascertained all of the facts). That is generally the case with normal administrative blocks of course, where all of the circumstances are public (to other administrators at least), but we need to make clearer that it is not allowed for blocks that clearly indicate that private info is involved. Hence these four brief but significant proposed substitutions. Ivanvector (^Talk/_Edits) 18:40, 29 January 2020 (UTC)[reply]

Oversight block questions should probably go to the oversight-en-wp(at)wikipedia.org list, not the functionaries list; just as check user blocks go to the check user list, not the functionaries list. Additionally, these can go to ArbCom list. — xaosflux ^Talk 19:00, 29 January 2020 (UTC)[reply]
If either a CU or an OS wants to refer up, they can engage the functionaries teams as needed. — xaosflux ^Talk 19:06, 29 January 2020 (UTC)[reply]
I think that’s dated from before the practice of automatic review of OS blocks. Probably could be reworded to refer to ArbCom since requesting a re-review of something that’s already been reviewed within minutes of happening is a bit redundant. Also noting I don’t think we need an RfC to do what I suggested. TonyBallioni (talk) 19:15, 29 January 2020 (UTC)[reply]
L235 changed that section from "email the oversight list" to "email the functionaries" just this past November, noting that the oversight email list does not accept emails from non-oversighters. However, anyone can email oversight by emailing User:Oversight, and there's a form for it at WP:OVERSIGHT, so maybe this should be fixed - oversightable matters really shouldn't go to the functionaries, although that's better than, say, posting at WP:AN. The section was changed to "email oversight" (from "email Arbcom") back in 2016 ([3]) supposedly as a result of an Arbcom motion but the motion is not linked. Ivanvector (^Talk/_Edits) 13:08, 30 January 2020 (UTC)[reply]
@Ivanvector: the os-l list doesn't, but anyone can email oversight-en-wp(at)wikipedia.org and it will send it to the OS team via OTRS. — xaosflux ^Talk 17:48, 1 February 2020 (UTC)[reply]
@Ivanvector: There is a section of the blocking policy that lists cases in which unblocking would "almost never be acceptable": Wikipedia:Blocking policy#Unacceptable unblocking. I've been thinking that something to the effect of When the block is explicitly labelled as a CheckUser or Oversight block, without the permission of a CheckUser or Oversighter should be added to that list. Mz7 (talk) 19:42, 29 January 2020 (UTC)[reply]
The note/reference change is internally inconsistent. The admin "must" not review but "may" decline? I think the "must" should remain a should in that case. --Izno (talk) 19:56, 29 January 2020 (UTC)[reply]
- Hmm, maybe so, but I think not really. The meaning of the "may" decline bit is (I think) meant for unblock requests which are clearly inappropriate. Like say a checkuser-blocked account uses an unblock request to write 36 capital letter Os bookended by two capital letter Ps, any admin (or non-admin, for that matter) should feel comfortable declining that. But no action can be taken on any reasonably good-faith unblock request without input from the blocking checkuser. Ivanvector (^Talk/_Edits) 20:12, 29 January 2020 (UTC)[reply]
  - Right, but at that point the admin has "reviewed" the request in question and made a decision as to its legitimacy (which is part of unblock requests--the other major part is whether the request is sufficiently convincing). I don't mind going the other way with it--and leaving all unblock requests with a CU behind it solely to CU-review, but if that's the case then the casual administrator should have nothing to do with it. Alternatively, we can reconsider the use of the word 'review' in this context without some qualification up front--allow the casual admin to review and reject (only) frivolous requests, and the CU to review and reject/accept non-frivolous requests. --Izno (talk) 21:23, 29 January 2020 (UTC)[reply]
- I don't think that section needs any changes. Frankly, I don't think it's relevant.--Bbb23 (talk) 23:08, 29 January 2020 (UTC)[reply]
  - @Bbb23: If I understand this comment correctly, that means you support my suggestion that the note should not change. Is that correct? --Izno (talk) 13:49, 30 January 2020 (UTC)[reply]
    - Mz7 suggested adding a sentence to a section of the policy. I disagreed.--Bbb23 (talk) 14:05, 30 January 2020 (UTC)[reply]
@SmokeyJoe: regarding when to mark a block as a checkuser block, the Committee's 2010 statement included: "Checkusers are reminded that because designating a block as a "Checkuser block" means that it cannot be reviewed on-wiki or on unblock-l, this term should only be used when confidential information has been used in the blocking decision." The policy doesn't contain language quite this strong, but it's generally the guidance we rely on. "Confidential information" is deliberately vague; essentially, any time a checkuser makes a block based on information that could not be discussed publicly (per the privacy policy, or related policies) it is marked as a checkuser-block. Conversely if the block is based only on info that is available to any other admininstrator, we don't mark it. We're advised not to use the tool at all in cases where a block can be made without its use or where we don't expect it to have any benefit. Checkuser blocks should be limited to private information gleaned from the checkuser tool; if checkusers are coming across private information in other forms we should be passing it up to oversight or arbcom, just like any other admin. I do realize it can seem at times like some checkusers are slapping "CU block" frivolously ("willy nilly" as you put it) but in any case that it's come up as far as I'm aware, it's been proven (privately, because privacy policy) to not be the case. If a checkuser were using the templates inappropriately, it's abuse of the tool and the permission can be revoked. The only instance that I know of of a checkuser being removed because of abuse was detected by other checkusers, not from a public complaint, and it was not because of marking blocks inappropriately.

To hopefully answer your question, the community should trust that checkuser-blocks are only being used in instances where private information is involved, where the reason for the block cannot be discussed publicly, and that's pretty much the extent of what that template means. But all blocks, including checkuser-blocks, are subject to outside scrutiny - checkusers have a mailing list for discussing private matters, arbitrators all have the same access we do and can review the logs, and complaints to the committee about private-information blocks are handled quickly, as the Committee's statement says. Ivanvector (^Talk/_Edits) 13:34, 30 January 2020 (UTC)[reply]

All I will say is that the above is Ivanvector's opinion and the not the opinion of all CheckUsers--Bbb23 (talk) 13:41, 30 January 2020 (UTC)[reply]

Haughty. --SmokeyJoe (talk) 23:38, 30 January 2020 (UTC)[reply]

This is all based on various users' statements about the policies and my experience of best practice both on and off Wikipedia in handling confidential info, but it is certainly fair to say that this is my opinion and may not be held by all checkusers. Ivanvector (^Talk/_Edits) 15:11, 31 January 2020 (UTC)[reply]

Remember most people think stabbing yourself in the foot is a bad idea, but it is certainly fair to say that view may not be held by all. PackMecEng (talk) 19:15, 31 January 2020 (UTC)[reply]

the community should trust that checkuser-blocks are only being used ... where the reason for the block cannot be discussed publicly,. Is that a minority opinion? Why should the community have this trust? —SmokeyJoe (talk) 23:31, 31 January 2020 (UTC)[reply]

I welcome the RfC. Policy should not be lifted from ArbCom statements, because ArbCom is not supposed to make policy. A confirmation RfC fixes the problem. --SmokeyJoe (talk) 23:38, 30 January 2020 (UTC)[reply]
Somewhat furthert to the above, but feel free to move this or advise me to move it elsewhere if it's off topic. I was just looking through Category:Requests for unblock and found an unblock request from a user who has been CU blocked. Their page is tagged with the template Template:Checkuserblock-account. The template warns that "administrators undoing checkuser blocks without permission or the prior approval from a checkuser risk having their administrator rights removed". Right, so, I don't want to do that.

The question has to be, however: why am I seeing this unblock request at all? It's like I'm deliberately being given enough rope to hang myself.

My suggestion would be that CU block templates must always be used when the block is "technical", and these templates should ask users who wish to appeal to use not Template:unblock but some new template (CU-unblock?), which would put unblock requests into a different category. I and my non-CU admin colleagues would have no need to ever look at the category, would be blissfully unaware of what goes on there, and would as a result be much less likely to find ourselves in front of ArbCom trying to explain why we accidentally undid a CU block. --kingboyk (talk) 10:52, 2 February 2020 (UTC)[reply]

Hrm. {{Checkuserblock}} says that an account should post an unblock request to the talk page. The default MediaWiki:Blockedtext that all blocked accounts see defers to Wikipedia:Appealing a block which points to the general {{Unblock}} template. Some rewriting would be necessary, I think (and shortening). Jo-Jo Eumerus (talk) 11:16, 2 February 2020 (UTC)[reply]

CU blocks may be declined by any administrator. In addition, many administrators add value in their decline by saying things about the behavioral evidence that supports the block. Sometimes, the unblock request raises issues that an administrator may wish to discuss, including wondering whether the block is misplaced, in which case they can ping the blocking CU with questions. I block many socks, sometimes 50 at a time. I obviously don't keep all of them on my watchlist. Nor am I one of those admins who handles the unblock request category, so often a ping is the only way I find out that a user has requested an unblock. Although this often creates more work for me, I feel it's part of my job, so to remove that component would not be helpful to the process.--Bbb23 (talk) 14:21, 3 February 2020 (UTC)[reply]

"CU blocks may be declined by any administrator". Good point, Bbb23. I'll get my coat. -- kingboyk (talk) 07:56, 4 February 2020 (UTC)[reply]

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

Rules for establishing cleanup template maintenance categories

This would refer more to guideline than policy, but I've been seeing how certain categories like Category:Wikipedia articles with style issues by month keep articles tagged with multiple different cleanup templates (up to 26 in that case), but other categories like Category:Articles with neologism issues keep those tagged with only one. I don't know what the standard is and couldn't find anything in documentation, only a guide on how to actually establish monthly categories.

I've been seeing some inline cleanup templates that don't put articles in any categories, and they look like they could really do with one for themselves. I've been eager to add them, but I don't know whether categories for single cleanup templates would be allowed en masse. Most seem to lazily revert to higher-level categories, and this seems to be an established (tolerated?) practice, according to the way these category pages are maintained. To me, a lot of those clumping categories look somewhat useless, because I can't ascertain whether an article inside it is dealing with, as in the above example, a {{Colloquial}} issue, an {{Essay-like}} issue or a {{Long quote}} issue. A few of that category's templates, like {{Example farm}}, place articles in more specific categories that come under Category:Wikipedia articles with style issues by issue, but most don't. I'm very eager to create independent categories for each of those templates.

Could there be a one-cleanup-template–one-category rule of thumb? When it comes to clearly related templates, like inline versions of box templates or those describing the same issue in different words, Category:Wikipedia articles with style issues has proven that you can create template-specific categories and simply place them in a broader one and allow both to sort their contents by date, effectively giving the users the option of how specific they'd like to browse. This could be established for inline vs. box templates, so one could view all articles tagged with either in the category one step above. A user might want to more rapidly fix only those articles tagged with inline templates, so they don't have to go searching for the offending statement. In case someone brings it up, I don't think the population of transclusions of each template matters when it comes to categories specifically. Templates and template-corresponding categories should be judged together. Only if a template is deleted should its corresponding category be deleted. If the only way a cleanup template can become "notable" is if it puts the very few or 0 articles it's ever going to be tagged on in a higher-level, more populated category, it shouldn't really be a template obviously, but being able to immediately know that (without advanced searching) is another benefit of my plan. I would also deal with such a case accordingly, as has been done previously. Additionally, as stated explicitly on many of these categories, an empty cleanup-template maintenance category means a job well done, and more often than not it will just fill up again anyway. Or should the status quo remain and all templates point to some existing category that vaguely fits? I want to know before I touch any of those categories or establish new ones (though I've already established one). Because, if I'm allowed, I will en masse change existing cleanup templates that dump(?) their articles in vague, high-level categories to point to new dedicated categories within their former category. This should, in theory, change nothing except add functionality (the ability to browse articles by specific cleanup template (with month added) while retaining the ability to browse them by their previous cleanup classification by stepping up levels if desired).

· • SUM1 • · (talk) 23:17, 7 February 2020 (UTC)[reply]

Tagging Rich Farmbrough, Mr. Guye and Fayenatic london, based on their cleanup-template category-maintenance activities. · • SUM1 • · (talk) 05:43, 9 February 2020 (UTC)[reply]

Tagging Marcocapelle, DocWatson42 and Oculi based on other category-maintenance activities. · • SUM1 • · (talk) 06:12, 10 February 2020 (UTC)[reply]

I think my only activity in this area has been to implement consensus where such categories have been nominated at CFD. There have been several renamings for clarity, but I think also some merges where multiple categories were considered unnecessary – sorry, I don't remember the specifics; maybe that was only where templates were also merged. My view would be that more cleanup categories do no harm to the general reader, as they are hidden categories, and may be created provided they will actually be used by someone. – Fayenatic London 07:16, 9 February 2020 (UTC)[reply]

We are somewhat ham-fisted in this area, as a community. We have deleted cleanup templates as being too broad, and we have deleted them as being too narrow. In the latter case we may have up-merged them, but in the former we have just de-tagged tens of thousands of articles, without a serious attempt to split them out.

I would be in favour of splitting these categories, if for no other reason, as a defence against someone having the bright idea of wiping the whole thing. I hope it would result in more cleanup being done, I certainly find that recasting a sentence to be readable (or at least less un-readable) is something that requires a different state of mind from fixing a table layout issue.

I will of course be available to assist, time permitting.

I am concerned that articles now belong in too many hidden categories, and the biggest culprit here is the redundant "All articles .... " part of the hierarchy, something I tried to address many years ago.

All the best: Rich Farmbrough (the apparently calm and reasonable) 08:31, 9 February 2020 (UTC).[reply]

Some transclusion statistics

{{Abbreviations}} 99
{{Colloquial}} 8
{{Debate}} 21
{{Essay-like}} 4372
{{Example farm}} 565
{{Fanpov}} 1581
{{Inappropriate person}} 148
{{Inappropriate title}}, 7
1. {{Inappropriate title soft}} 5
{{Long quote}} 48
{{Manual}} 418
{{MOS}} 342
{{Needs table}} 3
{{Overly detailed}} 2601
1. {{Overly detailed inline}} 9
{{Over-quotation}} 871
{{Pro and con list}} 31
{{Repetition}} 77
1. {{Repetition section}} 17
2. {{Repetition inline}} 8
{{Research paper}} 59
{{Review}} 243
{{Story}} 293
{{Summary style}} 12
{{Term paper}} 27
{{Textbook}} 24
{{Tone}} 8816
1. {{Tone inline}} 272
{{Too many flags}} 1
{{Travel guide}} 299
{{Verbosity}} 25

All the best: Rich Farmbrough (the apparently calm and reasonable) 11:44, 9 February 2020 (UTC).[reply]

Thank you both for your responses and Rich for the statistics. I will see what Mr. Guye has to say, then I may start this process. Rich Farmbrough, you may have a point with the "All articles" part, but is this really a bad thing, given the usefulness of some of these categories? What is "too many"? Articles seem to have equal or even more non-hidden categories than hidden ones (screenshot). · • SUM1 • · (talk) 13:18, 9 February 2020 (UTC)[reply]

Yes that is another problem. Causes are two-fold in this case, American Presidents always attract a lot of categories, secondly there is a lot of cross categorisation, a better system might avoid this. All the best: Rich Farmbrough (the apparently calm and reasonable) 14:28, 9 February 2020 (UTC).[reply]

@Rich Farmbrough: Cross categorisation was another problem I was going to point out at some point. Some are easy to fix, like the numerous cleanup templates (1, 2, 3) that are placed in both Category:Wikipedia maintenance and other categories that are inside categories that are inside Category:Wikipedia maintenance, like Category:Wikipedia article cleanup.

However, some, like Category:Hidden categories vs. Category:Tracking categories vs. Category:Container categories vs. Category:Wikipedia maintenance, which have instances of each other inside each other, look more difficult to fix without a significant change in established practice. Category:Tracking categories is inside Category:Wikipedia maintenance (since 2008), which is inside Category:Tracking categories (since 2017). But I'm new; I don't know whether this an explicitly sanctioned practice or a disorganised side effect. · • SUM1 • · (talk) 16:34, 9 February 2020 (UTC)[reply]

Well there have traditionally been a lot of strangenesses in the article categorisation graph, though these have been reduced somewhat over the last few years: and the "back end" cats don't receive (or indeed deserve) as much love.

But the thing I was referring to was article categories like "Male non-fiction writer" and "American Presbyterians".

All the best: Rich Farmbrough (the apparently calm and reasonable) 20:18, 9 February 2020 (UTC).[reply]

While I appreciate SUM1 tagging me in, I have no opinion on this subject. Please do keep me in mind for other subjects, though. —DocWatson42 (talk) 06:33, 10 February 2020 (UTC)[reply]

@DocWatson42: That's fine. Anything that isn't objection to my plan works for me. · • SUM1 • · (talk) 22:28, 10 February 2020 (UTC)[reply]

Thank you, SUM1. I don't have a very strong opinion on this other than to say that the system could use reform. This has been a problem that has confused me in the past. Category:Articles lacking reliable references is the apotheosis of the problem. I think that it is OK to have tags discussing basically the same subject (like {{Third-party}} and {{Third-party inline}}) go to the same category, but other than that I don't have much to say other than some level of reform would be welcome. — Mr. Guye (talk) (contribs) 00:09, 14 February 2020 (UTC)[reply]

Rigor in using the concept "PC" (as in Personal Computer)

"site:wikipedia.org +pc" gives 65 million hits. There are four categories, IMHO, to this: PC as a political term, PC referring to a Personal Computer, PC meaning Microsoft Windows in a positive or neutral context, PC meaning Microsoft Windows in a negative context.

Now, my issue is with the latter. In the old days, many people (even still today!) perceive what I'd call an instance of Windows as "the PC", like "the Fridge" or "the Oven". This is very convenient for Microsoft, because most of the time, when the user is stung by quirks or bugs specific to Windows, the user simply "blames the Computer" instead of blaming the current Operating System. At the same time, whenever such a box serves people "above and beyond", Windows and Microsoft get the kudos.

My suggestion

I call for a more Fair, or more Rational, or at the very least a Policy for this... I guess praxis. (Mind you, I do respect and admire Bill Gates. He's my age and he and his wife are giving gazillions to Good Causes, which many others don't!)

What would be on the level of Wikipedia's stature is, to be precise in (even "casual") writing about personal computers and differentiating them from the operating system at hand. Especially when it is obvious (at least to professional computer folk) that the PC deserves none of the blame, only the operating system. Incidentally, this is painfully prevalent in discussions relating to hazards like Computer Viruses, where the average Joe honestly believes "these viruses" are a PC thing, and not a Windows thing. (We are 20 years past The Year Two Thousand.)

Dignity

It is below Wikipedia to be imprecise, or downright common in this particular issue. I know that what I'm saying is controversial, but I ask you to really think this through.

Disclaimer

This is the two cents I have. I am not interested in arguing or defending this position. Instead, I submit this as-is, and if it is not good enough, so be it. Gwrede (talk) 22:37, 8 February 2020 (UTC)[reply]

Comment

In attempting to differentiate between a personal computer and its operating systems you are falling into the same trap yourself. A personal computer (PC) can run many different operating systems (OS), thus you can have a Windows PC, a BSD PC or a Linux PC and probably several other types of PC/OS combination. Indeed, you could even argue that a Mac was a personal computer though given the closed ecosystem that is probably a step too far. Martin of Sheffield (talk) 23:20, 8 February 2020 (UTC)[reply]
At the Video Games Wikiproject, we generally avoid using "PC". Its either the operating system, or "personal computer" (though once identified for the first use , we might switch to PC later in the same article. --Masem (t) 23:40, 8 February 2020 (UTC)[reply]
I'm not entirely sure what concrete change is being proposed here, but it seems fairly obvious that we shouldn't be using the term "PC" in isolation, with no context or definition. As Masem says, "personal computer" should be fine, which would encompass all the flavours, including Mac. I suppose there is a colloquialism of saying "PC" to mean something like what's described at IBM PC compatible, which for some might imply Windows as an automatic, others not. Either way, they key is to define clearly which sense is meant and to go from there. — Amakuru (talk) 08:54, 9 February 2020 (UTC)[reply]
I am also not clear what the exact issue is, or what the solution proposed is, as related to computers. If you type PC into the WP search box there are a lot of different definitions. My view is that it is up to each article to be clear, and in formal writing you should write out what you are abbreviation in full the first time in the article, and then can use the shortened version afterwards. If articles are not doing that, they are not being clear. As commentators above note PC in the personal computer term could mean an Apple 2, an Amiga, the current Macs or what are x86 / IBM compatible PCs, and many other computers. I would disagree with @User:Martin of Sheffield's comment re: Macs, as they are a concept still a personal computer although it is easier for most people to refer to them as "Macs" (being a subset of PCs). I also note computer viruses are actually a computer-thing rather than a Windows-thing: the first virus was non-Windows based. Viruses are more associated with Windows due to many factors, not least the number of users making it a greater opportunity for mischief. - Master Of Ninja (talk) 11:51, 9 February 2020 (UTC)[reply]

There's only about 60,000 occurrences of "PC" or realted terms on en:WP, not 60 million.
I think we need an example of a problem caused by usage to take any steps to resolve an issue. All the best: Rich Farmbrough (the apparently calm and reasonable) 14:32, 9 February 2020 (UTC).[reply]

There are about 60K in the mainspace, and about 150K pages across all namespaces, but the search specified at the top includes non-English Wikipedia pages. I get 82M ghits on that search and about 5M if "pc" is in quotation marks.

I looked at the first page of search results for "PC" on this wiki. I didn't see any that I thought were urgently in need of a change. I think that we should be using correct terminology, and I've no objection to spelling it out, but if the statement is about personal computers, then it should say that, and if the statement is about a specific piece of software (e.g., malware affecting only Windows, or malware affecting only Adobe Flash), then it ought to say that. The volume of uses doesn't really tell you much. I'd rather see a few examples of specific recommended changes. WhatamIdoing (talk) 22:04, 9 February 2020 (UTC)[reply]

I'm not entirely sure I follow what policy needs enacting or changing. There are already general rules from the MOS on the use of abbreviations, Wikipedia:Manual of Style/Abbreviations, that seems adequate to deal with any issues of the use of the abbreviation "PC", I'm not sure we need to get to the level of granularity of legislating particular usages of individual abbreviations. --Jayron 32 20:17, 14 February 2020 (UTC)[reply]

Advertising important policy and proposal RfCs on the watchlist

Currently, the only two major changes to the watchlist are the monthly Signpost edition and RfAs as and when they come by. RfAs are also advertised on CENT, while Signpost isn't. Imo, to avoid keeping it empty and invite more participation from the silent majority, we should advertise policy and proposal RfCs that have had more than a certain number of participants (20?) to invite wide-reaching participants. This, ofc, only includes the RfCs that are tagged with the {{RfC}} template and thus, already open to participation via FRS. The minimum cap should allay concerns about RfCs that aren't going anywhere to come up in our watchlists. Thoughts? --qedk (t 桜 c) 08:41, 9 February 2020 (UTC)[reply]

Just for additional context: note the {{centralized discussion}} template currently is used to draw attention to requests for comments that have broad effect on the community. See Wikipedia:Centralized discussion for more details. isaacl (talk) 18:05, 9 February 2020 (UTC)[reply]

Hi there!! I'm very glad to see this topic here right now; namely, because I just posted a proposal to address this actual topic. we are right next door, at Wikipedia:Village pump (proposals)#Idea for new community workspace. feel free to come by, and to add any comments!!! thanks!! --Sm8900 (talk) 18:20, 9 February 2020 (UTC)[reply]

Who defines "important"? If we have someone making judgement calls, it opens the door for a stream of complaints every time we don't post one; if we go with "everything more than 20 participants", we'll have a constant stream of such things as "naming conventions for New York subway stations" which are of no interest to most people. (Taking the current "project-wide topics" section of WP:RFC, if the "anything with 20 participants gets listed" rule was in place then we'd at the moment have watchlist notices for such burning issues as "Should the New Zealand naming conventions be amended to allow the use of macrons for articles written in New Zealand English?", "Should the signature parameter be removed from infobox person?", "What should be the venue for discussing Rcat templates?", "Should drug prices be listed on articles about medications?", "Is it acceptable to blank userspace sandboxes of long-term/established, but inactive editors?", "Should an SPLC classification as a hate group be automatically leadworthy?" and of course "Should The Fellowship of the Ring etc be merged into The Lord of the Rings?".) I also don't buy the "silent majority" argument; when it comes to RFCs all participants aren't equal, and any closer is going to take the opinions of those who are active in the relevant area and are familiar with the issues more seriously than a gaggle of randoms recruited via a sitenotice. ‑ Iridescent 18:27, 9 February 2020 (UTC)[reply]

@Iridescent and Xaosflux: I think we can find good "middle ground" here. If changes are being discussed to a WP:POLICY page, surely an RfC regarding that will be general enough and deserving of site-wide participation? And otherwise, a monthly "See new open RfCs here" is not an issue imo. --qedk (t 桜 c) 07:54, 10 February 2020 (UTC)[reply]

I'm one of the unoffical watchlist "gatekeepers" - and agree that something that is at least useful or important to most editors may deserve a watchlist inclusion. A significant change to general editing policies such a Wikipedia:Verifiability overhaul proposal could impact most editors for example, and I think it would likely warrant both a lengthy RfC and very wide advertisement; a change to something current like what content belongs in the the introduction to this single article obviously doesn't. In the middle ground you might have meta-issues such as Wikipedia:Village pump (proposals)#Proposal: “are you sure” page when clicking on “log out” before logging out - and I really don't think most editors care enough that we should bother them. Notice fatigue is real, so I think this type of notice should be conservative. — xaosflux ^Talk 18:42, 9 February 2020 (UTC)[reply]

Maybe the advertisement that we need is one that asks people to watch CENT if they're interested in that type of discussion. WhatamIdoing (talk) 22:07, 9 February 2020 (UTC)[reply]

@WhatamIdoing: if we want an "always on" link to CENT on the watchlist, it could be squeezed in to MediaWiki:Watchlist-details. Something like: See also centralized community discussions. perhaps? — xaosflux ^Talk 23:22, 9 February 2020 (UTC)[reply]

The header of Special:RecentChanges could also possibly be used (we link things to that on meta-wiki for example). — xaosflux ^Talk 23:27, 9 February 2020 (UTC)[reply]

We might consider running a 1-time or once-annually recurring advertisement of the Wikipedia proposals RFCs page (among others in that set) and/or Template:Cent. That gives people an opportunity to watch those themselves rather than forcing them to have a new watchlist notice everytime a new Important Discussion is held. --Izno (talk) 04:44, 10 February 2020 (UTC)[reply]

That sounds reasonable, another option would be to get signpost to cover it at least once as it is also delivered to user_talks. — xaosflux ^Talk 12:19, 10 February 2020 (UTC)[reply]

I like the ideas of an annual notice and a story in the Signpost. WhatamIdoing (talk) 17:44, 11 February 2020 (UTC)[reply]

@Smallbones: Since Signpost is more of your field. Also, @WhatamIdoing, Xaosflux, Izno, and Iridescent: are biannual watchlist notices agreeable? In any case, we can post it to the watchlist once and then if people complain, discuss this further. --qedk (t 桜 c) 17:22, 20 February 2020 (UTC)[reply]
I wouldn't want to see it more often then that really, just don't want to wear people out so they ignore notices. — xaosflux ^Talk 18:21, 20 February 2020 (UTC)[reply]
Assuming that "biannual" means "semiannual", then that's okay with me. WhatamIdoing (talk) 18:25, 20 February 2020 (UTC)[reply]
I saw the notice and found this discussion and just wanted to say that I'm really not a fan of the current formatting. Trying to find the important link (Wikipedia:Requests for comment/All) took me four tries and that is clearly not a good user experience. I'm not really sure how to fix it nicely, but I really think the most important link should be the only one in bold. ‑‑Trialpears (talk) 13:02, 24 February 2020 (UTC)[reply]
I'm quite surprised this notice was posted based on a consensus of three editors. I don't see how any of the currently listed discussions are so important to have a community-wide notification pushed on watchlists (Iridescent's examples are an excellent illustration). Not really a fan of a regularly-repeating notification either; it's indiscriminate, not distinguishing between times when there are important discussions and when there are not. When I receive a watchlist notice, I expect an issue that needs (not merely benefits from) the input of a wide range of editors. – Teratix ₵ 13:30, 24 February 2020 (UTC)[reply]
I’ve gone ahead and removed it per the above. The format wasn’t particularly helpful in that you weren’t sure what you were clicking on, and I think doing a watchlist notice for RfCs in general creates more confusion than it creates insight. We already list RfCs which are major changes in how we as a project do business on the watchlist. For anything less than that, WP:CENT is always available if it’s a big enough deal where wide impact is needed. TonyBallioni (talk) 13:50, 24 February 2020 (UTC)[reply]
Oppose per Iridiscent and TB; encouraging a talking shop does little to encourage wisdom. ——SN 54129 14:03, 24 February 2020 (UTC)[reply]
Oppose per Iridescent and TonyBallioni. Many of the discussions that are currently up and were on the watchlist don't particularly rise in importance of being on WP:CENT, much less on the watchlist with the Signpost and RfAs. – John M Wolfson (talk • contribs) 19:38, 24 February 2020 (UTC)[reply]
Comment I also had to click all four links before concluding I had no idea what I was being pointed at and asking for a clue at help desk, who kindly pointed me here. I don't have any objection to being pointed at specific RfCs that really do need wide visibility, but this was just confusing because I couldn't figure out what it could be. I'd assume the average editor-who-can-find-their-watchlist would be even less clued in. --valereee (talk) 20:11, 24 February 2020 (UTC)[reply]
Oppose. The way to get more people to participate in such important discussions is to cut down on the places where they are advertised, rather than increase it. That way everyone knows which page to look at. We have WP:CENT for this purpose, and if that needs to be better advertised then it should be so, rather than have its purpose diluted. Phil Bridger (talk) 20:31, 24 February 2020 (UTC)[reply]
I don't think it would be very controversial to add a CENT link in to MediaWiki:Recentchangestext. — xaosflux ^Talk 21:43, 24 February 2020 (UTC)[reply]

Adding Current template to active presidential candidate articles

This:

All of these articles are updated frequently and subject to a lot of content and citations being removed and added constantly each day. Based on the wording of the template page's information, I think it's not advised to be used, but I feel it would be best given the inherit flux of these articles. Would I be warranted in adding this to the candidates at 2020 Democratic Party presidential candidates#Active candidates?--occono (talk) 22:45, 11 February 2020 (UTC)[reply]

No. Not active enough at this stage, anyway. To quote the template's documentation page: Generally it is expected that this template and its closely related templates will appear on an article for less than a day; occasionally longer. feminist (talk) 02:54, 12 February 2020 (UTC)[reply]

Also too biased towards US politics. If this becomes a thing, it should be neutral with respect to the title of the office-seeker. Headbomb {t · c · p · b} 04:20, 12 February 2020 (UTC)[reply]

The template shown is the normal Current template, just with a variable value for active presidential candidate, I didn't mean it as a suggestion for how to word such a template in general of course :).--occono (talk) 08:39, 12 February 2020 (UTC)[reply]

Sorry, did not see this discussion before opening a new one at Talk:2020 Democratic Party presidential candidates#"Current" template. I also oppose, for reasons explained there. I've gone ahead and removed them all. Hydromania (talk) 08:25, 12 February 2020 (UTC)[reply]

Well if it's meant as a regular 'active events' warning, they're politicians, they'll always be active for at long as they aren't retired. And even then. Headbomb {t · c · p · b} 16:07, 12 February 2020 (UTC)[reply]

Oppose as it would require an "active politician" template as well, which all politicians technically are. Plus it is U.S.-centric. funplussmart (talk) 01:29, 17 February 2020 (UTC)[reply]
Oppose. At a broad level, templates such as Template:Current are justified when an article is likely to have problems that readers should be aware of (in this case, being outdated). While presidential candidates' articles don't update instantaneously, they're updated enough that readers can expect them to be relatively current, with the exception of ultra-new content that any reasonable reader wouldn't expect to have been updated yet anyways. Sdkb (talk) 05:33, 19 February 2020 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. GMG ^talk 14:01, 17 February 2020 (UTC)[reply]
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. --Jayron 32 15:27, 17 February 2020 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
- 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)[reply]
  - 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)[reply]
    - 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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
- 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)[reply]
  - 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)[reply]
  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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I think order would present a better tool than randomness, in this space. BD2412 T 04:15, 27 February 2020 (UTC)[reply]

@BD2412: Order? Do you mean order from less to more complete? El Millo (talk) 04:47, 27 February 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
- 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)[reply]
  - 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)[reply]
  - 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)[reply]

Personally, I'll only !vote for the deletion of draftspace if one of the following are done:

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.
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)[reply]

The options aren't "draftspace or nothing". For example, we used to move pages to userspace. WhatamIdoing (talk) 23:40, 27 February 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Pre-discussion on a possible RFC related to categories on contentious labels/groupings

A few discussions that I've seen recently, particularly related to BLP, suggest that we may need to rethink categories which are based on contentious terms or labels or other types of classifications which ultimately come down to some subjective determination from reliable sources. Issues arise from these as you cannot source include in a category (whereas you can with a list), and because inclusion is typically black-or-white, without the ability to explain further, can lead to issues of where the line for inclusion should be drawn. And of course, there's the larger question if we should have these types of categories at all. Nearly all other categories we have are based on objective facts that are apparent from sourcing in the included articles (though editors may have reasons to edit-war over which "fact" is correct) and thus not an issue there. Also in consideration is that we typically don't have categories for non-contentious but still subjective-from-RSes areas, such as no category for "Films considered the best" though we certainly have a list for that.

Because of potentially how broad this could be, it does not make sense to start an RFC before knowing what the scope of issues are so that a fair and impartial RFC question can be asked. To that end, I'd like to brainstorm here to figure out how to frame the question (not try to resolve it!) for a potential RFC on the matter.

Some of the questions that I can see that should be asked would include:

When is it appropriate for a category based on a contentious label (such as those listed at WP:LABEL or similar classification to even exist? Are there certain lines to be drawn? Should these only be as lists where sourcing can be used to demonstrate that inclusion is warranted? Is this a case-by-case basis?
Assuming such a category is appropriate, how should it be named? Something like Category:Conspiracy theorists or Category:Climate change skeptics can put possibly-subjective label into implicit Wiki-voice fact, which is not appropriate if their is any question for any element of the category. Should these be named to "People considered conspiracy theorists" or something similar, which assigns that there is some subjective nature from RSes for inclusion? In cases where there can be factual inclusion into such a category and subjective inclusion (such as for hate groups which can be factually categorized by the government, or subjectively labeled by a group like Southern Poverty Law Center) should we have dual categories, named appropriately?
What type of inclusion requirements should be required for including persons and entities on these lists? Since we cannot source category inclusion, how crystal clear or obvious should the association be? Should there be minimum sourcing requirements? (Can 1 RS be sufficient to include, for example?) Is this also a case-by-case situation?

Again - the goal right now is not to answer these questions but to get a scope of what questions we should be asking for a larger RFC on these types of categories, and I am only looking for input into refining these or adding more questions that would be appropriate in establishing how we should handle these categories otherwise. --Masem (t) 16:00, 17 February 2020 (UTC)[reply]

A bit surprised to see that the OP seems to make no reference whatsoever to related available guidance such as WP:COP, WP:EGRS, WP:OVERCAT (e.g. its WP:OCASSOC & other subsections). Before embarking on an RfC I suppose it needs to be demonstrated more clearly in what sense such existing guidance would be insufficiently helpful to find consensus on concrete issues. Precisely defining lacunae in existing guidance might lead to an easier overview of which questions need to be asked. On the other hand, if it appears to be so that nobody ever looks at existing relevant guidance, there's no need to do a rewrite of these guidelines based on a new RfC, while the new guidance would probably not be read more carefully than the guidance that is already available. --Francis Schonken (talk) 16:44, 17 February 2020 (UTC)[reply]
- That could very well be the reason, as we have numerous cats that are against specifically WP:SUBJECTIVECAT, yet they still keep happening. --Masem (t) 00:15, 18 February 2020 (UTC)[reply]
  - That said, reading WP:SUBJECTIVECAT, I feel there are some editors that do not see labels as subjective words that fall into that, and maybe we need more explicit guidance there. --Masem (t) 00:17, 18 February 2020 (UTC)[reply]
Per Schonken, I as well think the problem comes not from a lack of guidance, but from the willingness of the community to be diligent in developing consensus and enforcing already existing guidance. --Jayron 32 17:22, 17 February 2020 (UTC)[reply]

RFC on a different kind of victim's list

There have been previous discussions here about Wikipedia:Casualty lists or Wikipedia:Victim lists. People interested in that subject might also want to join the Talk:Hospitalized cases in the vaping lung illness outbreak#Inclusion criteria RFC. The article in question is largely two lists (although not using bullet formatting) of two groups of living people, i.e., those who have filed lawsuits related to their illnesses and those who have talked to newspapers about it. WhatamIdoing (talk) 23:21, 17 February 2020 (UTC)[reply]

Whether a particular WP:REDIRECT section agrees with actual practice

FYI

– Pointer to relevant discussion elsewhere.

Please see this discussion at WT:REDIRECT, on the list of (non-speedy) deletion criteria for redirects. — SMcCandlish ☏ ¢ 😼 05:56, 18 February 2020 (UTC)[reply]

Stop putting Roud index numbers in the lead of folk songs

Every article on a folk song (e.g. Cotton-Eyed Joe) includes a sentence like this one in the lede: "In the Roud index of folksongs, it is No. 942."

This sentence contains essentially zero information. It takes up valuable space in the lede. We should stop doing this. — Preceding unsigned comment added by 2620:0:1045:18:7160:6E50:4F33:28C4 (talk) 08:07, 18 February 2020 (UTC)[reply]

My topic-ignorant and knee-jerk reply to that based on your example is Yeah! Remove or possibly move to an info-box if it's helpful to someone. Gråbergs Gråa Sång (talk) 10:48, 18 February 2020 (UTC)[reply]

Or use as an EL, like we do with imdb. Gråbergs Gråa Sång (talk) 11:35, 18 February 2020 (UTC)[reply]

Roud Folk Song Index is valuable information for those interested in the topic. Walter Görlitz (talk) 15:37, 18 February 2020 (UTC)[reply]

It may be valuable information, but surely not so valuable that it should go in such a prominent position in the text of each article. It should be treated in the same way that an ISBN for a book is, as an infobox item. Phil Bridger (talk) 15:49, 18 February 2020 (UTC)[reply]

Do I understand it correctly that for the given example, [4] would be the right link? Gråbergs Gråa Sång (talk) 16:51, 18 February 2020 (UTC)[reply]

Roud indexes are useful and important. Perhaps more time should be spent paying attention to MOS:LEAD: "The lead section ... It is not a news-style lead or "lede" paragraph". Martin of Sheffield (talk) 20:39, 18 February 2020 (UTC)[reply]

Tell it, brother! I've fixed the heading. ―Mandruss ☎ 21:03, 18 February 2020 (UTC)[reply]

There was nothing wrong with the heading. "Lead", "lede", and "introduction" all mean the same thing. WhatamIdoing (talk) 18:42, 25 February 2020 (UTC)[reply]

I, for one, find the spelling "lede" affected and exclusive of people who don't know newsroom jargon. Phil Bridger (talk) 19:10, 25 February 2020 (UTC)[reply]

@WhatamIdoing: Per Wikipedia:Manual of Style/Lead section#Comparison to the news-style lead, it is not an inconsequential difference like, say, heading and header. There is nothing wrong with highlighting the distinction via the "lead" spelling. There is also nothing wrong with using one word for something, since doing so facilitates clear communication. New editors needn't and shouldn't be required to learn that lead, lede, and introduction refer to the same thing; there are plenty of barriers to entry without silly things like that. I personally would draw a line after correcting a heading, which I did here, but before correcting a comment, which I refrained from doing here. But I'll never accept the implication that editors are being anal when they assert and defend the Wikipedia spelling per the guideline. ―Mandruss ☎ 07:00, 26 February 2020 (UTC)[reply]

I think you are reading far too much into the statement "The lead paragraph (sometimes spelled "lede") of newspaper journalism...". It notes the other spelling; it does not say that the other spelling means something completely different. We do still have a few editors who insist that lede means teaser, but that's not what the dictionaries say: "The introductory portion of a news story, especially the first sentence." (American Heritage), "The introductory paragraph(s) of a newspaper or other news article." (Wiktionary), and "the first sentence or short portion of an article that gives the gist of the story and contains the most important points readers need to know" (Grammarist). You can read more about the non-difference between a journalistic lede and a journalistic lead at Merriam–Webster's blog. Should Wikipedia have a journalistic lede/lead? Well, I think we should be writing introductions to encyclopedia articles, but to the extent that we have articles on current events, then we probably should have traditional journalistic leads/ledes at the top. That means getting the who-what-when-where into the first sentence and keeping the most important facts at the top. IMO there shouldn't be teasers (which is one type of "buying the lede", a phrase that almost never uses the lead spelling) in any Wikipedia article. (Header and heading are importantly different, and confusing those two can harm WP:Accessibility.) WhatamIdoing (talk) 17:40, 27 February 2020 (UTC)[reply]

You've missed some of my points. Bottom line for me is that there are better reasons to use one word than to use three, and that one word is "lead". (I also oppose incorrect use of "heading" and "header", for some of the same reasons. I was searching for a contrasting example and perhaps didn't search long enough.) ―Mandruss ☎ 01:22, 28 February 2020 (UTC)[reply]

If you want to settle on a single word, then I recommend "introduction", which will be familiar to just about anyone who had to write a paper for school. "Lead" is jargon from the newsroom, no matter which decade's spelling you happen to prefer for it. (The lede spelling gained popularity right about the time when the bigger newspapers stopped using Lead (metal) for their typesetting.) WhatamIdoing (talk) 05:22, 28 February 2020 (UTC)[reply]

Nah, I'll settle on "lead", since (in my experience, which is as incomplete as anybody's) it has far wider acceptance than "introduction". I only rarely see "introduction" coming from experienced editors. Thus the road to consistency is considerably shorter for "lead". ―Mandruss ☎ 06:00, 28 February 2020 (UTC)[reply]

"...significant information should not appear in the lead if it is not covered in the remainder of the article." Gråbergs Gråa Sång (talk) 21:09, 18 February 2020 (UTC)[reply]

This seems like something that should be sent straight to the infobox, or, better, wikidata AND the infobox. —moonythedwarf (Braden N.) 21:12, 18 February 2020 (UTC)[reply]

Agreed, seems a perfect fit for an infobox. PackMecEng (talk) 21:14, 18 February 2020 (UTC)[reply]

I think inside the box as well. --A D Monroe III^(talk) 22:03, 18 February 2020 (UTC)[reply]

Agree wikidata and infobox - Master Of Ninja (talk) 23:04, 18 February 2020 (UTC)[reply]
This is a type of authority control number. It belongs in Wikidata, the infobox, and any authority control templates. WhatamIdoing (talk) 18:42, 25 February 2020 (UTC)[reply]
I also concur that the information is better suited for the infobox and Wikidata and not for the lead. In a sufficiently developed section on notable collections of folk songs that also include such songs, I could also see a mention of Roud, but the inclusion in the lead paragraph is far too prominent a place for such information. --Jayron 32 18:45, 25 February 2020 (UTC)[reply]

RfC: Locality categorization by historical subdivisions

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Question: What should the general rule/principle/guideline be for categorizing current localities by historical administrative subdivision in Central and Eastern Europe? There are quite a few articles of cities and towns that have been categorized not only in which administrative subdivision they currently are in, but also by the former subdivisions.

Typical example: Eišiškės, a small town in Lithuania, is in these categories: Category:Cities in Lithuania, Category:Cities in Vilnius County, Category:Šalčininkai District Municipality, Category:Vilnius Voivodeship, Category:Lidsky Uyezd, Category:Nowogródek Voivodeship (1919–1939). The first 3 categories reflect the current administrative subdivision. Vilnius Voivodeship was a subdivision in 1413–1795. Lidsky Uyezd was a 2nd-level subdivision sometime between 1795–1915. Nowogródek Voivodeship (1919–1939) was an inter-war subdivision.

General options:

A: categorization should be limited - by what? Whether it is referenced in the article? How long the subdivision lasted? How large the subdivision was? To the 1st-level former subdivision? To how recent subdivision was? Etc?
B: categorization should not be allowed (i.e. current localities should be removed from the former subdivision categories; historical information could be preserved in a different venue like a separate list or an addition to the locality article or something similar to the "historical affiliation" box as in Görlitz#History)
C: status quo; no general rules; specific issues with individual categories should be addressed at WP:CfD

22:24, 21 February 2020 (UTC)

Major concerns with such categories:

WP:OR/WP:V: many of the locality articles do not even mention or reference former subdivisions. In Eišiškės example above, only Nowogródek Voivodeship is mentioned in the article body (added by me 12 years ago without a reference). What is the basis to claim it was in the Lidsky Uyezd? An editor looking at a map? Finding out former subdivisions is not always straightforward, particularly for smaller towns or for older subdivisions – some medieval regions did not have well defined borders, while in more recent years administrative border adjustments are frequent.
WP:NONDEF: if many of the articles don't even mention the historical subdivision, it cannot be the defining characteristic (which is the central goals of the categorization system).
Confusion for readers: in the example of Eišiškės above, could you tell which of the 6 categories is for the current and which is for the former subdivision? (this could be somewhat alleviated by better category names)
Clutter/maintainability: Görlitz lists 23 different countries/states (not to mention subdivisions) that it was a part of. Should all of these be represented in a category? If not all, then which ones?

Examples of categories: just some samples from different countries. Category:Kingdom of Galicia–Volhynia (did not have well-defined borders), Category:Republic of Central Lithuania (has other valid historical articles mixed in with current localities), Category:Telshevsky Uyezd and Category:Minsky Uyezd (2nd-level subdivision), Category:Lithuania Governorate (subdivision that lasted 5 years), Category:Ținutul Nistru (existed for 2 years), Category:Belastok Region (short-lived WWII subdivision), Category:Province of Catania (subdivision renamed in 2015), Category:Localities in Western Moldavia (without digging, can't tell whether current or historical subdivision), Category:Province of Westphalia.

Why this RfC? There were some CfD discussions over the years (ones that I am aware Aug 2015 (delete), Sept 2015 (delete), Oct 2015 (no consensus), Apr 2017 (no consensus)) but they did attract much attention (unlike AfD, CfD rarely attracts outsider attention), yielded inconsistent results, and did not hash out what should be done with these categories in general. And these categories keep proliferating. Therefore, looking for a broader principle-based discussion here, rather than individual consideration of specific categories at CfD.

Side note: some locality articles have "historical affiliation" boxes (example: Görlitz#History), though in some others it was removed as "nightmares" or "LISTCRUFT". And a user got blocked for adding them (and refusing to communicate).

Opinion poll: Locality categorization by historical subdivisions

Please place your !vote here.

A: definitely should be limited to may be current immediate subdivision and may be the historical in which a populated place was established. For the "historical affiliation" box mentioned above for Gorlitz, it should be avoided as a spam as it simply fails the Manual of Style for flags WP:MOSFLAG and infringes on original research WP:OR due to political speculations. Aleksandr Grigoryev (talk) 22:59, 21 February 2020 (UTC)[reply]

Aleksandr Grigoryev: I thought about it, and I don't think it's a workable solution. Many places don't have a specific founding date and they are just mentioned in written sources in year x, or even more broadly in century y. Plus what makes the first subdivision so special? Further, I don't think it's maintainable. If you think about it, it still means that there will have to be categories for all historical subdivisions of that region as localities were founded/mentioned in different times. So, for example, there will have to be a category for Vilnius Voivodeship that contains localities founded/first mentioned in 1413-1795 and for Lidsky Uyezd that contains localities founded/first mentioned in 1795-1915. But then, it's likely that someone will decide that the category on Lidsky Uyezd is not comprehensive and start adding articles purely by geographic location. Renata (talk) 03:15, 24 February 2020 (UTC)[reply]

A (Current Subdivision and Historical One at Founding) I'm with Aleksandr above, the current geographical subdivision and the original seems reasonable. So Marseille would be both in the current French subdivision and be noted as a former Greek colony. (I don't want this approach to throw out all historical/former city categories beyond subdivisions though: Category:Former national capitals and Category:Populated places along the Silk Road both seem defining.) RevelationDirect (talk) 00:31, 22 February 2020 (UTC)[reply]

C. This is far too broad a question and these things badly need to be determined on a case by case basis. Some of the above shouldn't have locality categorisation in this way. Some of them should. The idea that we can answer them on a global basis with reference to a handful of subdivisions in eastern Europe is the sort of discussion that leads to all kinds of ridiculous situations when applied to local situations in places nobody was giving thought to. The Drover's Wife (talk) 00:54, 22 February 2020 (UTC)[reply]

The Drover's Wife: not really looking to write any policy here, but just to get a rough idea/consensus from the wider community on what categories should or should not be present in locality articles. It would be very helpful if you could expand on your comment "Some of the above shouldn't have locality categorisation in this way. Some of them should." -- which should (not) and based on what criteria? Even if just considering the examples listed above. Renata (talk) 01:46, 22 February 2020 (UTC)[reply]

I am woefully under-educated about the history of this specific region and I'd hate to give pronouncements on things I don't understand well enough to have a sensible opinion. I'm just extremely cautious of a discussion like this creating a rule that then gets applied to completely different circumstances in other places. The Drover's Wife (talk) 03:23, 22 February 2020 (UTC)[reply]

B (A if we have to): Limited to current subdivisions only, as has been the long established practice; bio articles relevant to the polity itself are also currently placed in the category named for that polity -- it is Category:People of medieval Wallachia, but not Category:People from Saac County (i. e. a defunct county in said Wallachia). This avoids a massive overcrowding. I don't see when populated places would be placed even in articles pertaining to those polities, let alone their subdivisons; only nostalgia and irredentism can be the driving factors here, and neither is encyclopedic. Current subdivision also establishes a neutral standard: populated places that were once in Romania are categorized by their current subdivision in Ukraine, but the same standards would apply to localities in Romania that were once in Hungary. Dahn (talk) 05:46, 22 February 2020 (UTC)[reply]

A or B, one could say "A, because we should allow this if a historical subdivision is a defining characteristic of a locality", but in practice it never is a defining characteristic, so A and B are very similar. Marcocapelle (talk) 08:47, 22 February 2020 (UTC)[reply]

A. Current and historical are enough. Historical division/subdivision should at least be mentioned in prose before including it. In addition, as already noted by other editor, the "Historical affiliations", including the mentioned problems, should be removed, because it is unsourced, trivial, and just takes up unnecessary space of the page. – Sabbatino (talk) 11:13, 22 February 2020 (UTC)[reply]

Sabbatino: Can you clarify which "historical" is enough? All of the examples above are "historical" so you are not actually limiting to anything. Renata (talk) 15:56, 22 February 2020 (UTC)[reply]

Country and first level division (governorate, state, province, etc). – Sabbatino (talk) 13:05, 24 February 2020 (UTC)[reply]

C I'm with The Drover's Wife on this. It's unwise to make policy decision on such a broad front. Examples can be listed of multiple short-lived political entities to which a city may have been attached over many centuries; it would probably be excessive to make the city a child of all of them. Cities changed hands multiple times in the Holy Roman Empire. On the other hand some administrative sub-divisions, while practically defunct, nevertheless remain on the statute books. For example Thurles (civil parish) is in the ancient barony of Eliogarty. While Eliogarty no longer has a practical administrative function, it has never been legally abolished. I would not like to see Thurles being removed from Category:Eliogarty. In summary, such thingsare best decided on a case-by-case, CFD basis. Laurel Lodged (talk) 11:36, 22 February 2020 (UTC)[reply]

@Laurel Lodged: As per your own comment, the barony in question still exists, in some definition, and the first verb in Eliogarty is "is". This is therefore an irrelevant example to this particular discussion, equivalent at best to including cities and towns in their traditional or cultural region. Dahn (talk) 10:03, 23 February 2020 (UTC)[reply]

C Per The Drover's Wife above. I believe handling this on a case-by-case basis and category-specific CFDs is the way to go.--Darwinek (talk) 16:01, 22 February 2020 (UTC)[reply]

Ok, I have narrowed down the geographic focus of the RfC just to Central and Eastern Europe (because that's really where the issues are). Ping to editors who already commented, in case that changes their thoughts: Aleksandr Grigoryev, RevelationDirect, The Drover's Wife, Dahn, Marcocapelle, Sabbatino, Laurel Lodged, Darwinek. Renata (talk) 16:09, 22 February 2020 (UTC)[reply]

No Change in View Based on the limitation of scope to the discussion. RevelationDirect (talk) 19:24, 22 February 2020 (UTC)[reply]
Comment - CFD Piecemeal Approach A CFD discussion is just as likely to suggest a global approach as this discussion might suggest a case-by-case approach. The area I have concern with is the subcategories of Category:Districts of East Germany, where we categorize literally every populated place that used to be part of the GDR by former region, which doesn't seem remotely defining to me. If I nominated that tree for deletion, it's likely to come up why I'm not nominating the Lithuania examples Renata provided. Does anyone see a difference between those two examples? RevelationDirect (talk) 19:24, 22 February 2020 (UTC)[reply]
- I'm not sure why it would come up. It doesn't follow that that what might be appropriate in one situation must be appropriate to another in a completely different geographical, political and historical context because they're both abolished institutions. If you think the German and Lithuanian ones you've both mentioned are equivalent and that they suck, nominating them both is a much better outcome than attempting to make global policy affecting thousands of situations you haven't considered. If you're preferring the few-heads global policy attempt because you think you're going to lose a CfD on the two (I don't know, this is emphatically not my area of knowledge in the world), that should tell you something. The Drover's Wife (talk) 20:23, 22 February 2020 (UTC)[reply]
  - I'm not sure anyone can name a situation when categorizing by past subnational entity would benefit anyone. Mind you, we're not talking about examples such as "Ancient Greek colonies" or "Former capitals of...", none of which actually refer to a subdivision. We are talking about subdivisions for all purposes defunct, and the type of info one would be able to recover from the article and/or a map. Nobody would benefit from having Places in modern-day Turkey grouped under their former Ottoman vilayets, though the article on both the place and the vilayet should include references to one another, at least once theyre both developed. Dahn (talk) 09:59, 23 February 2020 (UTC)[reply]
    - ...unless someone was trying to find out what happened to the cities that were once within a particular Ottoman vilayets. I'd expect that to be unusual, but I can imagine it happening (at least for larger cities). (That sounds like a great school assignment: "Pick one of the Ottoman vilayets we've been talking about this week, figure out what it's biggest city was, and find out what's happened to that city since then.") WhatamIdoing (talk) 18:59, 25 February 2020 (UTC)[reply]
I'd go with B, with the usual allowance for exceptions in exceptional cases. This is a classic list role. All the problems that afflict using a category for this information would disappear if using a list. A list is also much easier to maintain and add any necessary qualifiers to (as might be needed for example if administrative boundaries shifted during the relevant historical period). As a bonus, a list is also much more likely to attract the attention of contributors with relevant historical expertise. I can see no reason why the approach would be different from one geographical area to the next; the arguments with respect to Central and Eastern Eurperiodically I ope would seem to apply equally well in any other geographical context. -- Visviva (talk) 04:33, 24 February 2020 (UTC)d[reply]
C. I'm not sure why this is such a contentious issue. If the town existed in the past as part of a former subdivision, why would it be inappropriate to note that? It actually sounds fairly useful; if I were trying to find out what was the extent of and former municipalities in, such-and-such of a now-defunct province, the categorization of places into such categories seems like a natural way to do that. --Jayron 32 18:53, 25 February 2020 (UTC)[reply]
I'm leaning C (no particular rules). I'm not sure that every little village that was once part of the Roman empire should be categorized that way, but Vienna was the capital of multiple empires/nations, and it seems odd to limit its categorization to only the most recent. WhatamIdoing (talk) 19:00, 25 February 2020 (UTC)[reply]
C. Should be treated case-by case basis, and the text must support categorization, with valid refs. In fact it is often important to know who belong where at a particular time, and periodically I am thinking about adding a kind of timeline template to articles about locations. Staszek Lem (talk) 20:07, 25 February 2020 (UTC)[reply]

C (A if we have to): Definitely not B. When talking specifically about Central and Eastern Europe, some places actually have more connection to their former subdivision in terms of historical importance than their current one, so it would be strange not to categorize them by their former subdivision. Ejgreen77 (talk) 11:43, 26 February 2020 (UTC)[reply]

RfA Consensus

The crat chat for Money emojii's RfA has brought up two areas that it seems like some discussion from the community might be productive. For both these discussions it's important to acknowledge that RfA is not strictly a vote but obviously does have numbers attached to it in a way that other consensus exercises do not. Best, Barkeep49 (talk) 23:08, 24 February 2020 (UTC)[reply]

Discretionary Range

Different crats seem to interpret the discretionary range differently. For some it seems to be a sliding scale, the closer to 75% the more likely they are to find consensus, the closer to 65% the less likely they are to find consensus. For others it appears that there is a rapid drop-off after 75% in likelihood to find consensus. There might be other ways not capture by these two philosophies. How do you think the discretionary range should be considered by crats? Barkeep49 (talk) 23:08, 24 February 2020 (UTC)[reply]

Get rid of it and set the minimum support needed at 69.5% and anyone above passes and anyone below fails. The current Gathering of the Elders methodology is unfair to both the community who voted and the candidate. We essentially have a House of Lords deciding what arguments they think are strong when the fundamental criteria is trust. I’m sorry, but someone who was highly trusted 15 years ago but is inactive now shouldn’t be able to say whether or not my reason for not trusting someone is good. Hell, not even newly elected crats should be able to do that. Who is anyone to be able to tell me that my reason for not trusting someone with the tools “isn’t strong”. That’s insulting and every crat chat is basically a super vote since there is not a policy that defines the minimum requirements to be an admin. TonyBallioni (talk) 23:43, 24 February 2020 (UTC)[reply]
This is something I've been musing about for a while. I made a relevant comment way back in April 2017, and I think it's worth repeating here. The English Wikipedia has no official requirements to become an administrator (WP:ADMIN#Becoming an administrator). There are no documented community norms for becoming an administrator; many editors have their own ideas about what the community norms are, but nothing is set in stone. As a result, when an RfA within the discretionary zone heads to bureaucrat discussion, the job of "assessing consensus" becomes difficult. We generally don't want administrators to be selected based on a numerical vote; we want RfAs to be decided based on "the strength of rationales presented" (WP:RFA#Discussion, decision, and closing procedures). Yet unlike closing something like a content RfC or an AfD, bureaucrats have no official standards that would inform their decision.
Instead, they are left to make a judgment based on their own experience, having observed and judged RfAs in the past. The way we've designed the system (i.e. with no official documentation in policy of what community standards for adminship are), it's no surprise that some editors think bureaucrats are "supervoting" and some editors think bureaucrats are "assessing consensus". The editors who are making the arguments that the bureaucrats are saying "weigh less" or are "weaker" will obviously disagree with them about it, and unless a vote is so totally off the mark that any reasonable Wikipedian would disregard it, it's not really clear who is in the right here because we have no rigid RfA standards. The reason we call it the "discretionary range" is because the result of the RfA is up to the bureaucrats' discretion, and as far as Wikipedia policy goes, the bureaucrats can exercise that discretion however the heck they want. Mz7 (talk) 00:26, 25 February 2020 (UTC)[reply]
To be fair, we do consistently get a handful of ridiculous arguments in almost every RfA (off the top of my head, I'm pretty sure someone voted support in the most recent RfA with the justification everyone agrees after quite a few people had opposed). A patch of middle ground between Tony's no discretionary range proposal and the status quo would be to instruct crats to only discount baseless votes (or alternatively, votes with clearly absurd rationale if we want to preserve people's ability to vote without giving a reason) and then just assess whether the adjusted total passes the 70% mark. _signed,Rosguill ^talk 00:40, 25 February 2020 (UTC)[reply]

You and Tony make good (albeit different) arguments about no requirements, etc., but as a counterpoint, trust and confidence of the community isn't in practice significantly more vague than some of the standards used in other consensus-based discussions. The whole reason we have terms like deletionist and inclusionist is because most of the time there is a contested AfD, a judgment call being made by participants. Even bright-line "rules" like NFOOTY can get argued about! I'd counter that, much like with sysops at XfD, if bureaucrats are deciding what makes a strong argument based on their beliefs, they are doing it wrong. In both cases, they should be attempting to assess the consensus present in the discussion, taking into account the community standards.

A good closer should happily consider arguments they do not like because the community does. There's an argument in your comments for stricter bureaucrat activity or participation requirements, even for bureaucrat recall, but outside of that I think half the issue is all the work we've done to turn RfA closer and closer to being a vote. The smaller the discretionary zone, the more scrutiny we get when we end up in it. Either it should be a 100% vote, which as noted has recently been handily dismissed, or we should let bureaucrats do their job. Either way, it would definitely be a good idea to see if we can't define some standards (beyond the above) for folks to point to. ~ Amory (u • t • c) 10:56, 25 February 2020 (UTC)[reply]
There are candidates who attract controversy at RfA because they've displayed inexperience or poor judgement at some point in the past, and there's candidates who attract controversy because they've worked in difficult areas long enough to make enemies. This second set, of which I'd consider myself a member, consists of people that would very likely be turned away from running at all if they didn't know that some sort of reasonableness filter would be applied to !votes. Vanamonde (Talk) 00:50, 25 February 2020 (UTC)[reply]

The ultimate problem is we're trying to tease out the relative value of the pros versus the cons for a candidate by examining the net opinions expressed by individual commenters. (For example, we see the bureaucrats trying to evaluate the significance of the concerns raised and weigh them against the positive qualities of the candidates.) I had proposed a reform where the request discussion would be structured to produce a weighted list of pros and cons. However, it didn't garner much support. isaacl (talk) 02:01, 25 February 2020 (UTC)[reply]

Along the same lines as Tony, just dump it. The arguments presented by the bureaucrats in their fabled 'crat chats are completely arbitrary -- and that's no fault of their own. "Good arguments on both sides, but I think the balance of the community is for promotion." "The supporters acknowledge and refute the opposing arguments." "The concerns of the opposers are more substantial than the supporters." Those are three statements that I just made up on the spot, but they could apply to any RfA, and they are all completely devoid of objective meaning, and just reflect the opinion of whoever is making the comment.

I think there should be *some* bureaucrat discretion exercised over things like troll votes, meatpuppetry or sockpuppetry, etc. But when it comes to figuring out whether an RfA has passed or not, let's set a strict numerical standard and keep to it. We intentionally don't have set standards for adminship, so there is nothing objective to measure the strength of arguments against, hence the pickle 'crats are placed in. -- Ajraddatz (talk) 03:38, 25 February 2020 (UTC) (expanded 03:45, 25 February 2020 (UTC))[reply]

Different crats seem to interpret the discretionary range differently. Thank God for that. The 'crats are humans and not algorithms. This obsession with numbers is a bad thing. --SmokeyJoe (talk) 04:18, 25 February 2020 (UTC)[reply]
One distinction between a deletion discussion and a RfAnything is that we have detailed inclusion criteria - known otherwise as "notability guidelines" - and other policies that govern when a page can stay or go. Thus such discussions tend to be analyses of how the policies and guidelines apply to the page in question more than votes about people's opinions. So sometimes a deletion discussion that by headcount is evenly split ends with a clear consensus for a particular course of action (and sometimes it is even closed against the wishes of the majority of participants). At RfAnything conversely we don't have detailed promotion criteria in the form of a policy or guideline that says "(don't) promote if <foo>" and much depends on the inherently subjective concept of trust. In such a place headcounts are more important even though strength of argument isn't completely unimportant. Jo-Jo Eumerus (talk) 11:05, 25 February 2020 (UTC)[reply]
Most of the discussion here seems to be about the discretionary range itself, but I think Barkeep49 was more specifically asking if and how 65.1% and 74.9% should be treated differently. Basically, what is the function that defines behavior between 65% and 75%, acknowledging that 0-65 and 75-100 are defined by y=0 and y=100? I think my rephrasing it that way is a little misleading, though, since the whole point of the discretionary zone is "here's where we need to think," and not "let's tally." Maybe 74% should be more likely to succeed than 66%, but the region should encompass all of the non-obvious percentages, so within the range the percentages alone shouldn't do the talking. ~ Amory (u • t • c) 11:06, 25 February 2020 (UTC)[reply]
To answer Barkeep's original query, I am inclined to push for the "sliding scale" interpretation, with a hint of Amory's caveat. The discretionary zone is for interpretation to occur, primarily on the comparative strength of reasoning. If that interpretation decided the reasoning quality was equally good, then I could see 73% passing and 66% not, but if was the key word. In effect, it should factor in, and at a sliding weight, but the primary !vote reasoning is what's most important. Nosebagbear (talk)

In quick response to the others, I think retaining CRATCHAT is preferable, and the common reasoning used by crats is acceptable. It absolutely isn't objective. However, the reason why RfBs are so tough are because we are in effect saying "yes, we have sufficient trust in your subjective interpretation to utilise it". I think cases missed out by an objective limit would cause more Community unhappiness and damage then the current set-up. Nosebagbear (talk) 11:44, 25 February 2020 (UTC)[reply]

Alternatively, we could not throw the baby out with the bath water, just because we just had an RFA which was very tight. However you cook the rules there will always be a case which is on a knife-edge, bang in the middle of what you regard as your fail to pass zone but the principle of WP:CONSENSUS applies nonetheless. I personally think it's preferable to have a group of trusted and experienced arbiters when it comes to such a line-call, rather than leaving the whole thing to the tyranny of numbers. The current system allows for crats to fail someone on 80%, if there are some horrendous egregious things raised in the oppose, and it also allows a pass on 60% if a whole load of crappy opposes are there. Although such cases would be highly unusual, I think it's correct that they are allowed to exist. — Amakuru (talk) 12:21, 25 February 2020 (UTC)[reply]
With the greatest respect for TonyBallioni, I disagree pretty strongly with his point of view above and agree with Amakuru. Those trusted "elders" help ensure the outcome doesn't get derailed by poor quality discussions -- which is exactly what we try to do in other potentially contentious, though usually less well-attended, discussions like deletion. They mitigate against the risk of an even more "unfair" outcome: tyranny of the loud, of the page-watchers, of the borderline-canvassed. A few years ago, we we plagued by RFA !voters with axes to grind, idiosyncratic criteria, and joke/pointy commenters. It's great that the community has matured past that (there are disagreements as to criteria, but much more healthy ones) and we're fortunate that recent, even discretionary-range RFAs have generally coalesced around very reasonable support and oppose argument which just different people weigh differently. But it's healthy to have someone taking a look for when that would not be the case in particular.

To Barkeep's question, I think a discretionary range of 65 up to 75 means promotion at 65 is tenable only if a sizable number of the opposes are weak, inscrutable, not explained, etc. Nonpromotion is tenable at 75 only if there are major, relevant concerns raised in the discussion that supporters have really not engaged on or acknowledged. What happens bang in the middle I'm quite happy to leave to the bureaucrats; the sky won't fall either way. Martinp (talk) 17:42, 25 February 2020 (UTC)[reply]

As I stated elsewhere, going back to five years before the RfC that expanded the discretionary range, there are very few RfAs that run to completion and end up in that range. I believe this indicates that the discussions in most RfAs are sufficiently convincing to either drive support above 75%, or below 65%. Recall that participants in RfAs are self-selected, and so are unlikely to be a representative sample of the entire editing population. Thus it's hard to consider the relative percentages as an absolute indication of relative support.

Due to the rarity of outcomes in the discretionary range, I think the best inference that can be made is that the arguments put forth and independent investigations performed failed to identify an obvious consensus in either direction. We just don't have enough data to determine if a 72% support percentage is significantly different than a 68% support percentage, for example. So I don't think either the sliding scale model or the cliff model works. I think during the RfA, the community needs to be encouraged to discuss the specific tradeoffs between pros and cons of the candidate, so the bureaucrats can have a basis to understand how to weigh the candidate's characteristics. isaacl (talk) 18:15, 25 February 2020 (UTC)[reply]

Hard cases make bad law. We should not change established practice just because there is an occasional hard case that comes along. The current system is fine, and I'd rather have a group of Bureaucrats giving careful consideration to all arguments presented, than to have an easily WP:GAME-able hard limit that opens the door to abuse both in support of and in opposition to candidates. Keep the current status quo exactly as it is. Does it mean we will, on occasion, have highly-contested, disputable results. Yup. Does that bother me? Nope. It's far better than the alternative. --Jayron 32 18:50, 25 February 2020 (UTC)[reply]
I don't have much more to add beyond what Jayron and Amakuru have already said. That different crats have different interpretations is a feature not a bug. — Wug·a·po·des 22:59, 25 February 2020 (UTC)[reply]
Re: "Different crats seem to interpret the discretionary range differently." Well, yes, that's what makes it discretionary. Dekimasuよ! 03:54, 26 February 2020 (UTC)[reply]
Hard cases make bad law - and with that, Jayron32 sums it perfectly. Among the 1,000s of RfA that have taken place, 'crat chats have been extremely rare, but IMO, for the time being anyway, are an appropriate solution for our less than perfect system of (s)electing our admins when an outcome from the voting community is not clear. Kudpung กุดผึ้ง (talk) 10:53, 26 February 2020 (UTC)[reply]
The number of participants (iVoters) should also be considered. Are we deciding 60% of say, 150 participants, or 60% of 350? The lower number of participants should require a higher percentage of supports, etc. --^Atsme _Talk 📧 18:16, 27 February 2020 (UTC)[reply]

Trendlines

Relative levels of supports and opposes can rise and fall over the course of the 7 days. When should/shouldn't RfA trendlines be used as indicators of consensus? Barkeep49 (talk) 23:08, 24 February 2020 (UTC)[reply]

In general I think a vote cast on the first day of an RfA should have the same weight attached to it as a vote on the last day and so, as a rule, trendlines should not be considered when evaluating consensus. However, there are definitely situations where "new" information could come out towards the end of an RfA which would make trendlines important and relevant. These would be the exception and not the rule and so I would expect that only in an occasional crat chat (which are already rare) would consideration of trendlines be appropriate. Best, Barkeep49 (talk) 23:08, 24 February 2020 (UTC)[reply]
That sounds like a fair summary that I would agree with. If something comes to light on the last day, and causes a sudden large spate of opposes and switches, that is something to consider. But, as I said several times, I think the trendlines should have been mostly ignored in the Money emoji RFA. The two major issues - content and maturity - were both brought to light on around the second day of the RFA, so it's not as if the early supporters had no time to think about it and reconsider. — Amakuru (talk) 23:13, 24 February 2020 (UTC)[reply]
This is definitely the viewpoint I'd agree with. The CRATCHAT also had an admin give an example of where their support % went up by 10% in the last day. While a less clearcut example than the "late negative news" example, I could see this also being relevant (e.g. a common objection was proved to be based on inaccurate information, or they save Jimmy's life on day 7). Nosebagbear (talk) 11:38, 25 February 2020 (UTC)[reply]
Trendlines are meaningless and to say that the votes (and yes vote, because it is a vote and not a discussion and we’re lying to ourselves every time we say otherwise) of the people who come later are more important than the votes of the people who come earlier. As someone who is frequently one of the first supports because I recognize most names that run and don’t really have to dig that often, the idea that my voice is less important than the voice of someone who opposes on the last day really bothers me. It’s dismissive and insulting to people who are the early supporters to assume they would have opposed if they had known what someone else said. TonyBallioni (talk) 23:38, 24 February 2020 (UTC)[reply]
Your perspective is valid, but I find it frustrating when several dozen editors rush to support a candidate during the early hours rather than waiting to see if any objections will be raised against the candidate. RfA isn't a race. Sure, there's no need to wait if you are familiar with the candidate, but is that the case for all early voters? It may not be fair to assume that these early voters would have changed their rationales if they had been aware of information that came to light after they voted, but it also isn't justifiable to assume that none of them would have changed their minds. Rather than being meaningless, trendlines are useful in demonstrating how later participants felt about the evidence raised during the discussion. LEPRICAVARK (talk) 00:02, 25 February 2020 (UTC)[reply]
Various proposals (including one of mine) have suggested having an initial discussion period without support/oppose opinions being put forth. The main sticking point is in order to allow once-a-week editors to support or oppose, the request for administrative privileges would have to run longer than a week, and there's not much support for that. isaacl (talk) 01:05, 25 February 2020 (UTC)[reply]
Taking trendlines into account encourages strategic !voting, and as such would be a terrible thing to do. It's also offensive to many early !voters to downgrade their opinion, even while acknowledging the reality that some editors drop immediate and potentially not-well-researched "support" comments. Vanamonde (Talk) 00:44, 25 February 2020 (UTC)[reply]
I wonder if the best way to handle the question of trendlines would be to stop extrapolating data, and instead leave borderline RfAs open until they are outside of the discretionary range. – bradv🍁 00:51, 25 February 2020 (UTC)[reply]
That would be brutal on candidates in a process that is already more strenuous than it should be. It also doesn't account for the possibility that a discussion could peter out or otherwise reach an equilibrium in the discretionary range, in which case the discussion would stay open until the candidate gives up, effectively making our success cutoff 75%. _signed,Rosguill ^talk 00:57, 25 February 2020 (UTC)[reply]
Rosguill, that's a fair consideration, but there's also the possibility that the community would reach a decision sooner than the crats would. Particularly in our most recent example. – bradv🍁 00:58, 25 February 2020 (UTC)[reply]
It's not just the length of the process, it's that the candidate is expected to be able to respond to questions while the RfA is open. I imagine it's not exactly pleasant to wait for the 'crats to deliberate on whether you get the bit or not, but I would personally prefer that to another several days of answering questions in a public hearing. _signed,Rosguill ^talk 01:04, 25 February 2020 (UTC)[reply]
Rosguill, in theory, that could be resolved by closing the questions after a set time, such as seven days. Not sure if this solution would be practical, but it's a thought. LEPRICAVARK (talk) 03:01, 25 February 2020 (UTC)[reply]

I like to think of an RfA as a snapshot reading at a moment of time, and so I think it shouldn't be any longer than needed to get a reasonable sampling of community opinion. I don't think extending it indefinitely is a good idea, as the process itself can increasingly bias the results the longer it runs. For example, you may get candidates withdrawing or commenters withdrawing their opinions in the name of unity to stop rancorous disputes. Or the whole limbo period may become extremely politicized, with both sides canvassing far and wide for sympathetic opinions. Let's see if more guidance on determining consensus can be worked out. isaacl (talk) 01:20, 25 February 2020 (UTC)[reply]
A potential solution to how to remove trendline assessment while still addressing the knee-jerk support phenomenon would be to only open voting a few days into the RfA, giving people time to research candidates and ask questions before voting begins. _signed,Rosguill ^talk 01:04, 25 February 2020 (UTC)[reply]
In addition to the concern I mentioned previously on extending the length of an RfA, as I recall some were not convinced having a discussion period would stop blind support opinions. (I still think it would be good to have some minimal baseline discussion available before commenters started weighing in with support or oppose opinions.) And, well, if someone feels they have all the necessary information at hand already to provide an opinion whenever the opinion phase starts, why shouldn't they be able to state their views? The willingness to revise their opinion based on further discussion is the key characteristic needed, though that's a much tougher issue to address. isaacl (talk) 01:27, 25 February 2020 (UTC)[reply]
@Isaacl: something to consider, but off the top of my head I'm not certain that would be a good idea... the discussion period might end up a little like WP:ORCP, with people coming up with unduly negative points in the discussion phase, but worse than ORCP because it would be right there on the RFA itself. And the candidate then having to sit there nervous while the voteless discussion unfolds, with no supports to evidence that the RFA is a good idea. Early withdrawals might become more common without the validation of a spate of supports when the RFA kicks off. — Amakuru (talk) 12:27, 25 February 2020 (UTC)[reply]
I don't think it will be any different than what happens now, except without a "Support", "Oppose", or "Neutral" heading above the discussion points. Editors would raise all the pros and cons they are considering. isaacl (talk) 17:45, 25 February 2020 (UTC)[reply]
I probably agree with Amakuru on this, but at the very least, requiring participants to return to an RfA, possibly more than once, would likely lower the number of !voters; I don't think that's a good thing. ~ Amory (u • t • c) 19:50, 25 February 2020 (UTC)[reply]
I don't see any difference once the opinion phase begins. A participant can pick any time at that point to participate once, much like today. If they want to come back and review any subsequent discussion, that's up to them. isaacl (talk) 22:04, 25 February 2020 (UTC)[reply]
Weighing a trend in favour or against promotion gives additional and undue weight to the side that is trending. If we are still operating under the assumption that RfAs are decided by consensus and the strength of the arguments, then those arguments should be able to be evaluated independent to the direction that the wind is blowing when the RfA ends. The trend is a shadow on the cave wall compared with the essence of the arguments being made. (though, as I mention above, I still think that without set standards for adminship we should do away with this notion of consensus and arguments and just move to a numerical standard) -- Ajraddatz (talk) 03:43, 25 February 2020 (UTC)[reply]
[cross-posting from Money emoji's crat chat] ...Everyone has a chance to assess the candidate in the 7-day period, it is absolutely possible that the assessment made in the later opposes has already been taken note of by the earlier supports and taken into account. As a crat, your job is not to second-guess the votes made earlier as if they made an incomplete assessement simply because the later opposes raised a certain issue. There is absolutely no evidence to your statement that earlier comments retain value, if they did, by your very own logic, this RfA would have an increasing trendline throughout, since that's how it started off, however it did not, proving your logic untrue by contradiction.
By saying, this trendline is giving me some idea about consensus, you are automatically reducing the weight of the votes placed earlier on, even if the votes placed earlier were more researched and well-formed, simply because a crat's "opinion" is that the trendline matters, Xeno got it exactly right the first time. If the trendline matters, we might as well all vote in the last one hour since that's all that should count anyway, but we don't, because every vote should count on their own merits, and not when they were placed. I wish this were down to a difference of opinion but it is simply not fair to those in this RfA who casted their vote with due diligence and exaggerates the view of the pile-on opposes which may or may not have any merit to them. And as usual, I'm open to clarifications. --qedk (t 桜 c) 06:53, 25 February 2020 (UTC)[reply]
The problem with trendlines is that they can mean a lot of things. Including nothing. If a lot of people are switching their !votes that might be useful, but a "trend" in and of itself is a weak reason for doing anything. Jo-Jo Eumerus (talk) 08:34, 25 February 2020 (UTC)[reply]
Trendlines are useful for one thing: finding inflection points. If something has been trending down or up steadily, or not varying much, then whatever. If, however, there is a fairly steady state until a piece of evidence comes out, and there is a massive shift, that is useful information. The trend isn't important, and it should not be the reason for success/no success, but it can be a useful tool for identifying when such an inflection point has happened. In practice, that sort of thing is almost always negative and usually happens early enough for candidates to withdraw, so the investigative utility is quite rare. (All this is noting, of course, that percentages before the first, say, 20 or 30 !votes should be ignored) ~ Amory (u • t • c) 11:16, 25 February 2020 (UTC)[reply]
In most RFAs, we're nowhere near the discretionary zone. Even if we are, strength of the arguments will be (at least to the bureaucrats) persuasive. I'm not against them considering trend in those rare cases which are getting close to coin-toss decision zone, and agree that when they do look at trend it is worthwhile to also look at reaffirmations of earlier supports or opposes. Martinp (talk) 17:44, 25 February 2020 (UTC)[reply]
Trendline is only relevant if there is a major shift late in RfA, with vote rationales heavily citing freshly revealed information. That said, I think 24-48 hour extension could be better option in such situation.--Staberinde (talk) 17:52, 25 February 2020 (UTC)[reply]
In a vacuum, trend lines shouldn't be used since polling is not a substitute for discussion; in practice it's more difficult to give a hard-and-fast rule because sometimes polling is useful. Amory summarizes my view well and is a useful TLDR. If you want the nitty gritty, see User:Wugapodes/RFA_trend_lines. — Wug·a·po·des 01:51, 26 February 2020 (UTC)[reply]

RfA Consensus/Crat Chat: General Comments

. . . déjà vu? :) I'll try to find the last time we "voted" on this "not a vote" stuff for Crat Chats, if someone else does not link it first, but has it not all been said . . . Alanscottwalker (talk) 23:58, 24 February 2020 (UTC)[reply]

I think you mean this discussion Alanscottwalker. I would suggest that since we have settled that it's a consensus process knowing how we interpret things does matter, hence the two questions I threw out. Best, Barkeep49 (talk) 00:05, 25 February 2020 (UTC)[reply]

Actually that's archived poorly, that came after a bunch of other discussion about how Crat's should weigh in the Chat, which spawned discussion about how to rejigger the RfA process and the Crat process. Long story short, the gist whether good or bad was discretion means what crats say, it's their discretion Alanscottwalker (talk) 00:15, 25 February 2020 (UTC)[reply]

Hypothetically a person could - and IMHO should - pass RfA with << 50% support if it was obvious from the support and the person's wiki-history the person would be the best administrator ever but the naysayers were there to grumble about trivial or irrelevant things. If he got 500 "nay" votes merely because he used American English instead of British English on his own user page, for example. This will never happen of course. Likewise, a person with 98% support could and probably should be denied adminiship by a Crat if it came out 2 hours before the close that his IP-only sock-farm was repeatedly abusing other Wikimedia projects, even if he never abused the English Wikipedia or the projects it depends on such as WikiData or the Commons. Again, I don't expect such a thing to happen but it could. However, for this reason we need to allow some 'crat discretion and we need to keep in mind that "early participants" may not see late-breaking information [particularly information in the last 12-24 hours] that would cause them to reconsider if they saw it. I do not mean to suggest that "trend lines" are always valuable - frequently they are not. But it does mean "the reason behind the trend" may be very valuable in some cases. davidwr/(talk)/(contribs) 17:32, 25 February 2020 (UTC)[reply]

Talk page length

Hi there,

Just want to tell y'all we're discussing the guideline (or "rule of thumb") that talk pages should be archived when over 75 kB, over at WT:Talk page guidelines#guidance on talk page size.

Feel free to chime in! Best regards, CapnZapp (talk) 09:59, 25 February 2020 (UTC)[reply]

Ding-a-ling! E Eng 11:18, 25 February 2020 (UTC)[reply]

^Atsme _Talk 📧 14:17, 25 February 2020 (UTC)[reply]

as you said on my talk page, you have selected me specifically as the first editor to challenge about this, and I believe you had said something on 21 February about giving me a two week period to see if I wanted to do something about it? . DGG ( talk ) 07:53, 27 February 2020 (UTC)[reply]

[1] Non-CheckUsers ~~should~~ must not review CheckUser blocks that require access to CheckUser data, e.g., when an editor is professing innocence or is questioning the validity of the technical findings in any way. Administrators may still decline unblock requests that are made in bad faith, are more procedural in nature, or are off topic.

[1]