Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.

Can projects ignore manuals of styleEdit

MOS:DATETOPRES was created at least three years ago. A discussion was held in August and September 2019 Wikipedia talk:WikiProject Football/Archive 127#MOS:DATETOPRES that determined that the project could implement the full term but GiantSnowman (talk · contribs) stated that the project should WP:IAR and that they should "keep it out". No further action was taken and they essentially ignored the manual of style. I was alerted to the change and opened a discussion (Wikipedia talk:WikiProject Football/Archive 151#Infobox style update) in February 2022 but was shot down, again with GiantSnowman being the most vocal in opposition. I raised it on the MoS's talk page Wikipedia talk:Manual of Style/Dates and numbers#MOS:DATETOPRES in infoboxes and there has been some discussion. It was subsequently raised by other editors Wikipedia talk:WikiProject Football/Archive 152#MOS:DATETOPRES in April.

The question is, can a project just ignore the manual of style? If the MoS is not appropriate, should it be changed or removed? Walter Görlitz (talk) 05:47, 1 May 2022 (UTC)

Apparently the issue concerns edits like this which changed "2020–" to "2020–pres." Looking at WT:WikiProject Football/Archive 152#MOS:DATETOPRES and WT:Manual of Style/Dates and numbers#MOS:DATETOPRES in infoboxes suggests that "The editor in question knows that but chooses to ignore". It is a really bad idea to wage war against an active wikiproject over trivia like this. In fact it is disruptive and if continued should result in blocks. You know the procedure—get a centrally published RfC to agree with you (and add it to WP:LAME) or leave the wikiproject alone. Johnuniq (talk) 06:55, 1 May 2022 (UTC)
Bingo. Firstly, DATETOPRES is a guideline and not compulsory. Secondly, I have been editing for 16+ years and in that entire time I have never seen it in use by various WikiProjects; I had not realised that DATETOPRES is very recent and therefore Walter was trying to enforce this new guideline on existing article styles. Thirdly, it appears to be Walter and Walter alone who is trying to enforce this, despite clear opposition. Ergo - the MOS should be tweaked to reflect the long-standing practices on Wikipedia. GiantSnowman 07:51, 1 May 2022 (UTC)
The history at the first discussion shows that several in the project agreed to change it to "present" but GiantSnowman is the most vocal opponent. Walter Görlitz (talk) 14:02, 1 May 2022 (UTC)
and yet as you can see here, others (outside of the various WikiProjects as well) agree with me that the MOS should be amended to reflect the long-standing editing conventions, and not the other way around (that you are the ONLY editor trying to enforce). GiantSnowman 14:21, 1 May 2022 (UTC)
Very short and easy answer - no they can't. Gonnym (talk) 07:55, 1 May 2022 (UTC)
The parts of the MoS that do not enjoy wide consensus should not be enforced. As football biographies are a large part of Wikipedia's BLPs, the MoS should reflect how they are written. Mass changes should only come with a wide consensus including the people who do the day-to-day work on the articles. —Kusma (talk) 08:27, 1 May 2022 (UTC)
If it doesn't have wide consensus - the agreement of the projects - then it should be removed from the MoS. Hawkeye7 (discuss) 10:51, 1 May 2022 (UTC)
But if there is no valid reason to ignore the MoS, then the project should follow it. That is the case with DATETOPRES and FOOTY. If they have a valid reason, let's see it. The only reason I have seen offered is there are a lot of articles to change, and for that, there are bots, editors with AWB and many, many volunteers. Is there another reason? Walter Görlitz (talk) 19:50, 1 May 2022 (UTC)
  • A LOT depends on the size of the WikiProject in question. A consensus to IAR among the members of a small WikiProject (with very few active members) would carry very little weight. A consensus to IAR among the members of a very large WikiProject (with hundreds of active members) should carry significant weight. Blueboar (talk) 12:20, 1 May 2022 (UTC)
  • Re "If the MoS is not appropriate, should it be changed or removed?" Neither, it should be ignored. It's really hard to get anything changed around here. We have a lot of rules that are either silly, objectively bad, or micromanaging. I try to ignore three rules before breakfast every day, it keeps me young. "Very short and easy answer - no they can't". I mean, they are, so I guess they can? I suppose you mean may'nt, but I mean it's a wiki not the DMV. The less telling other people how to write, the better. Consistency is way overrated, you'd be surprised how little the readers care about that. Herostratus (talk) 13:23, 1 May 2022 (UTC)
    • That I have no problems if there is a good reason to ignore it, but "the project is large and it would take a bot (or a lot of individual effort) to modify all of articles" is not a valid counter-argument. Since consistency is overrated, then why can't an individual editor ignore all rules and correctly apply the MoS on articles they edit against the project's own ignoring of the MoS? Walter Görlitz (talk) 14:02, 1 May 2022 (UTC)
      Or ignore both the MOS and the project's guidelines? Once you start ignoring the MOS, why stop at the Wikiproject? Peter coxhead (talk) 14:09, 1 May 2022 (UTC)
      Indeed that strawman is not a valid argument, but nobody has argued with the amount of effort required. —Kusma (talk) 14:25, 1 May 2022 (UTC)

I'm no expert, but my understanding is that we should follow guidelines unless there is a consensus not to follow them. You don't need a consensus to follow guidelines. Also, for what it's worth, it takes at least two people to engage in a lame edit war. That being the case, you probably shouldn't accuse someone else of being lame, if you're taking part in that same war. If the disputed issue doesn't matter, don't debate it. If it does matter, don't accuse others of being lame for believing that it matters. Instant Comma (talk) 16:20, 1 May 2022 (UTC)

The intro of MOS essentially says that with it sometimes be ignored, and even MOS itself is merely a guideline. What the actual question is is whether a project can make up a rule that conflicts with MOS. But editors should feel triply free to ignore any rule made up within a project, and quadruply so if it conflicts with MOS. So IMO it's a bad and pointless idea for a project to try to make such a rule, or imply that others are compelled to follow it. North8000 (talk) 17:45, 1 May 2022 (UTC)

to clarify - there are multiple WikiProjects that do not follow this rule, which was introduced (according to Walter) only 3 years ago (i.e. long after the various WPs had already started their standards/MoS. So it's not that the WPs don't comply with the rule, it's that the rule did/does not match how editors actually edit (if that makes sense?) GiantSnowman 18:30, 1 May 2022 (UTC)

Can anyone explain why this actually matters? AndyTheGrump (talk) 18:32, 1 May 2022 (UTC)

it doesn't - but Walter has been engaging in a disruptive campaign to change how multiple WikiProjects and probably hundreds if not thousands of editors edit tens/hundreds of thousands of articles, for some reason. GiantSnowman 18:34, 1 May 2022 (UTC)
And, you know, saying that using common sense will lead to chaos is not a good look -- the "If you allow gay marriage, next people will be marrying telephone poles" type argument. Most slopes are not slippery and we have, I hope, the sense that God gave sheep to know when to draw lines. Some people feel more comfortable when rules are always rigidly adhered to, and fine -- in their writing they are free to keep a list of Wikipedia rules on their desk and make sure that every one is followed. Give the rest of us the courtesy of the same freedom (I speak of rules where it's not really important (like the current case); there are some MOS rules that everyone ought to follow, and the borderline is debatable and always will be). Let Wikiprojects set their own rules, or indeed have a rule that says "you may do such-and-so as you think best". Herostratus (talk) 18:48, 1 May 2022 (UTC)
Well if it does not matter, whey exactly is an admin (in this case GiantSnowman) reverting?
It clearly matters to you GS. The MoS is clear and there is no valid reason to ignore it. The only disruptive element is the one who continually removes a correctly applied manual of style because you don't like it. I follow one team. I have correctly applied the MoS to the current players of that team and that is in no way disruptive. I am not forcing the project to change their way of editing a few hundred articles, but i's clear that you have no valid reason to ignore the rule, and so ignoring it is disruptiuve to the whole project. Walter Görlitz (talk) 19:39, 1 May 2022 (UTC)
You (alone) say there is no valid reason to ignore it - I (and many, many others) say there is no benefit in following it. GiantSnowman 20:53, 1 May 2022 (UTC)
@Walter Görlitz: The question is, can a project just ignore the manual of style? WP:LOCALCONSENSUS says not. --Redrose64 🌹 (talk) 20:32, 1 May 2022 (UTC)
The question is… when dealing with a large WikiProject disagreeing with one of our more obscure MOS guidelines, which actually represents wider community consensus? There is an argument for saying that occasionally project consensus can actually be “wider” than guideline consensus. This is something WP:LOCALCONSENSUS does not consider. Blueboar (talk) 20:50, 1 May 2022 (UTC)
This is far wider than that - it is multiple WikiProjects that have been editing in this manner since long before the 'rule' came into effect. GiantSnowman 20:50, 1 May 2022 (UTC)

Can somebody please persuade Walter to stop single-handedly trying to force the MOS on articles when there is clear opposition to the same? GiantSnowman 20:59, 1 May 2022 (UTC)

At the top of this guideline it says, "It is a generally accepted standard that editors should usually attempt to follow, though it is best treated with common sense, and occasional exceptions may apply." How about using a bit of common sense when it comes to things that have worked perfectly well ever since Wikipedia was founded? Phil Bridger (talk) 21:22, 1 May 2022 (UTC)
I agree with Walter. The fact that the MOS is apparently followed in this instance by the entire project except for a few projects shows that there is widespread consensus to follow the MOS and that these few projects are trying to use a LOCALCONSENSUS to ignore it. The project benefits with a consistent style; it just looks more professional. The MOS is a style guide for the project that editors should usually attempt to follow. While occasional exceptions may apply, that does not mean it should be ignored by whole projects. MB 21:27, 1 May 2022 (UTC)
Perhaps the question is can someone persuade GiantSnowman to stop reverting the MoS when it is correctly applied?
With that stated, I have not seen the discussion at the manual of style, nor a rationale for its widespread implementation. With that said, I have also not seen a rationale for its exclusion by a handful of sports projects. Walter Görlitz (talk) 22:26, 1 May 2022 (UTC)
then what are the acceptable 'occasional exceptions'? I also think you saying "the MOS is apparently followed in this instance by the entire project" is misleading, as it implies that editors are actively and deliberately following the MOS, which is not the case. How many editors know about it? How many bear it in mind when editing? You will note that Walter is the only one actually going around trying to enforce this. That shows that only one editor actually follows the MOS... GiantSnowman 08:33, 2 May 2022 (UTC)
Are you seriously twisting "occasional exception" into all the thousands of articles within a particular project? An "occasional exception" should be justified with a good reason, not just because "we have always done it that way". And yes, an editor writing in compliance with the guideline, even if not realizing what they are doing is per a specification, and perhaps just following how they see something done in most other articles, is still following the MOS. MB 19:06, 2 May 2022 (UTC)
Per WP:CONLEVEL, participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope. If a WikiProject wants an exemptions from the policy or guideline then they should open a general discussion requesting a consensus for that exception. BilledMammal (talk) 00:26, 2 May 2022 (UTC)
there is a discussion here...and many are saying 'the MOS' does not need to apply. GiantSnowman 08:31, 2 May 2022 (UTC)
  • Of all the examples of overreach in the MOS, this has to be at or near the very top. I can't imagine that this was a big enough issue to require a hard and fast rule that every article must follow, with no exceptions. Does anyone actually think readers get confused by seeing "2002-" in an article? Or is this is an example of MOS-types setting rules with no regard for common sense? -- Vaulter 01:44, 2 May 2022 (UTC)
    exactly. I have been editing for 16+ years, at no point has any reader expressed confusion in this regard. GiantSnowman 08:31, 2 May 2022 (UTC)
    @Vaulter, @GiantSnowman, I believe that it will be confusing for people using screen reader software. You could ask Wikipedia talk:Manual of Style/Accessibility to be sure, but I believe that these are the results (Wikipedia article first, screen reader voice second):
    • 2002 = two thousand two
    • 2002– = two thousand two
    • 2002–2022 = two thousand two two thousand twenty-two
    • 2002–present = two thousand two present
    Since "2002" (i.e., one year only) and "2002–" (i.e., twenty years) are read out the same way, it could be very confusing and misleading. WhatamIdoing (talk) 03:07, 5 May 2022 (UTC)
    At last a substantive comment, rather that the "my project's more important than yours" stuff. In my screen reader (the free one that comes with Linux Mint) I get similar results, with "2002" and "2002–" reading the same way, ignoring the "–". If this happens in the screen readers most commonly used by people who actually need them then it seems like a good reason for our football articles to be changed. Phil Bridger (talk) 07:00, 5 May 2022 (UTC)
    I agree too. I'd also say the MOS should be updated to mention the accessibility concerns rather than the current vague statement to "not use incomplete-looking constructions." -- Vaulter 15:49, 5 May 2022 (UTC)
    this is a fair point about accessibility - but what about '2002–pres.'? GiantSnowman 17:51, 5 May 2022 (UTC)
    That's a great point, but this sounds like it might need to be applied more widely. Generally, this says that dashes should be avoided? "Since 2002" would sound better than "2002 present" or "2002 president" so perhaps we could use something like that instead? How do screenreaders read "3 August 1976–5 September 2001"? —Kusma (talk) 23:20, 5 May 2022 (UTC)
    An excellent idea. MichaelMaggs (talk) 10:54, 6 May 2022 (UTC)
    @Kusma, I believe that is read out as "three August nineteen seventy-six five September two thousand one" (or perhaps 'one thousand nine hundred seventy-six' for the first year). WT:ACCESS is a better place to ask, if you want a solid answer instead of a guess. WhatamIdoing (talk) 19:21, 6 May 2022 (UTC)
    @WhatamIdoing, thank you. I don't currently have the time or energy to pursue this. But if dashes are not read at all, we should perhaps replace dashes that mean "to" either by the word "to" or by a fancy template that produces a dash or the word "to" depending on whether it is in standard or in screenreader mode. We should definitely attempt to have a MOS that improves accessibility where possible. —Kusma (talk) 19:48, 6 May 2022 (UTC)
    When I asked about it, a blind editor told me not to worry about it, because it was normal and expected all over the web. I decided to write the words out (in prose) anyway. I did not feel encouraged to make a big deal out of it, and it's certainly not worth edit warring over, but it seemed like an easy way (for me) to be slightly clearer, and it's really no extra effort (for me). You might find it useful to keep this in mind while you're editing for the next month or two, and see what kinds of situations you encounter. It's useful to know the range of situations before trying to make any big changes. WhatamIdoing (talk) 23:26, 6 May 2022 (UTC)
  • I don't see why this is causing so much huff. WikiProjects do not have WP:OWNERSHIP over articles. MOS is a central matter to be determined by the community at-large. If a small minority of editors have made a change to MOS that others disagree with (and this I think has happened before), including members of a WikiProject, the appropriate response is to take it to the relevant MOS talk page and/or open an RfC. If it's so obvious that so many editors clearly disagree with a change, this should not be difficult to achieve. The WikiProject members can all have their say on said talk or in said RfC. -Indy beetle (talk) 08:50, 2 May 2022 (UTC)
    • Sigh… Agreed… if there are editors who can’t accept a simple “ignore”, then we probably do need to hold an RFC to determine whether the current language of WP:DATETOPRES needs to be amended. Blueboar (talk) 13:56, 2 May 2022 (UTC)
  • Repeal. MOS:DATETOPRES is improper because:
    1. According to the OED, "pres." is an abbreviation for "president" not present. The suggested usage is therefore not standard English.
    2. The present is imprecise or indeterminate because it is constantly changing. It would be better to specify the time of writing, which is not the same as our articles are not updated in real-time.
    3. The discussion above indicates that it lacks consensus
    4. WP:CREEP
Andrew🐉(talk) 19:22, 2 May 2022 (UTC)
Agree with it being removed or amended. GiantSnowman 20:15, 2 May 2022 (UTC)
  • WP:CONLEVEL explicitly says WikiProjects can't overrule global consensus, but just because something is written in the MOS doesn't mean it's global consensus. One has to see if the specific MOS rule was added after a widely-advertised RFC (per the global consensus of WP:PGCHANGE), or if it was a bold edit. If it's the result of a widely-advertised RFC, then it's global consensus, and WikiProjects can't exempt themselves, no matter how large; they'll need to start a new RFC to see if consensus has changed. If on the other hand the rule was added in a bold edit, then a large WikiProject not complying is evidence that there isn't global consensus for the bold addition in the first place. I'm not sure which is the case here. Levivich 19:25, 2 May 2022 (UTC)
    FYI it's multiple WikiProjects that 'ignore' it, not just one... GiantSnowman 20:16, 2 May 2022 (UTC)
    It was boldly added with this edit in 2016. It has been there a long time, so there is an argument for WP:IMPLICITCONSENSUS, but there is no evidence of a global consensus. Hawkeye7 (discuss) 20:37, 2 May 2022 (UTC)
    which post-dates the way that the WikiProjects in question have been editing by at least 10 years... GiantSnowman 10:57, 3 May 2022 (UTC)
    Unfortunately, there is no rationale provided for the change either. Hawkeye7 (discuss) 06:04, 5 May 2022 (UTC)

As Indy beetle says, the best way forward is to have a discussion to establish consensus. Unlike the species capitalization question, I feel the visual effect on the reader is small. Thus I think possible options could include "keep the same as originally written" or "follow local consensus of interested editors for the article". In an ideal world, sure, it'd be nice if everything was consistent. I think it could be a reasonable choice, though, to say the benefit/effort ratio isn't worth it for this case. isaacl (talk) 21:01, 2 May 2022 (UTC)

  • Rules should reflect current consensus. If they don't, we need to fix them. "Ignoring" them because they bother us without discussing them is simply not a sensible option because a) why have them in the first place and b) how can we expect new users to do right when we don't even follow our own rules? Please open a formal challenge to the MOS guidance at the relevant talk page. -Indy beetle (talk) 00:54, 3 May 2022 (UTC)
    Agreed. Perhaps the rule has its uses but its scope is narrower than MOS implies and needs to be clarified. Certes (talk) 01:06, 3 May 2022 (UTC)
    Sure, that's what I said: we should discuss the matter to establish consensus, and update the guidance accordingly. The consensus view could be to have a fixed rule, or flexible rules. Whatever it is should be clarified. isaacl (talk) 15:26, 3 May 2022 (UTC)
  • Since it seems that it was added without a proper RfC, ignore it for now and leave it up to the WikiProjects. It's more important to have consistency between subjects (like football articles or military articles) than it is to have consistency between all ~6.5 million articles. The former lies up to the respective WikiProjects and can be decided on their talk pages. Wasting our time discussing something as trivial as this is a poor use of our time. Why? I Ask (talk) 01:15, 3 May 2022 (UTC)
    • As a coordinator for the MilHist project, I must object. The problem is that mindset effectively gives WikiProjects special powers which they explicitly do not have. To quote the information page: WikiProjects are not rule-making organizations, nor can they assert ownership of articles within a specific topic area. WikiProjects have no special rights or privileges compared to other editors and may not impose their preferences on articles. A WikiProject is fundamentally a social construct: its success depends on its ability to function as a cohesive group of editors working towards a common goal. In practice we tend to defer to subject expertise for certain matters which tends to coalesce in certain groups, but projects do not simply get to decide what rules apply for articles in their field and what do not. That has to be allowed by the community at large. MOS are rules. If they are bad rules, then let us make them good rules! -Indy beetle (talk) 04:35, 3 May 2022 (UTC)
      The MoS is a guideline, not a hard rule. As it clearly says at the top: it is best treated with common sense. The MoS is designed to make the pages more accessible for the reader. Something like this only deals with minor aesthetics, at best. And the latter note is why Wikipedia has such a hard gathering and retaining experts in specific fields. Because this pseudo-bureaucracy works against them. Let the WikiProject with the most experts in the subject best decide how to move forward in their respective fields (unless, as I said, it creates major accessibility issues). No one has control over any Wikipedia article; that includes people that tout the MoS as the final say. Discuss matters on the respective articles or the WikiProjects that maintain the articles. I point you toward WP:CREEP. Why? I Ask (talk) 06:30, 3 May 2022 (UTC)
      • Well, if we're simply going to ignore the MOS when we WP:DONTLIKEIT because we're too lazy/special to put in the bare minimum of effort to change it, we might as well scrap the whole concept. Yes, we should treat MOS with common sense, but why don't we actually try to make the MOS common sense (by securing widespread agreement on its text)? That seems way more in the spirit of avoiding CREEP. The sheer amount of resistance to this idea of simply dropping some comments off at a talk page makes me suspect that the people here who object to the MOS guidance are actually worried that it does have consensus, and don't want to find out for sure. -Indy beetle (talk) 11:06, 3 May 2022 (UTC)
        Some of us (me) have attempted to amend the MOS to reflect this - and been reverted. GiantSnowman 11:42, 3 May 2022 (UTC)
        @Indy beetle's arguments are persuasive. It can't be right that whole swathes of articles are subject to repeated reverts when editors attempt to follow the MOS, with reverting editors relying on the often unwritten 'customs' of WikiProjects who according to the information page lack any authority ("WikiProjects have no special rights or privileges compared to other editors and may not impose their preferences on articles"). The MOS is of global scope, and if an argument is being made that certain classes of article should have special rules applied, those special rules should be discussed in an RFC and added to the MOS if it transpires there is global (not WikiProject) consensus to do so. MichaelMaggs (talk) 13:04, 3 May 2022 (UTC)
        Obviously, it doesn't have complete global consensus or else there wouldn't be so many people opposed. Both WikiProject Guidelines and the MoS are simply recommendations. Case-by-case bases are what works best. As the MoS FAQ page points out: It is not a mandatory policy that editors must assiduously follow. Why? I Ask (talk) 16:56, 3 May 2022 (UTC)
If it's in the MOS, it is presumed to have consensus and should be followed. If a particular project does not like it, it is up to them to start a discussion to have this item either amended or outright removed from the MOS. Unless and until that amendment/removal, anyone is free to edit an article to adhere to MOS and anyone reverting such edits is to be considered acting against consensus. --User:Khajidha (talk) (contributions) 13:20, 3 May 2022 (UTC)
Except the MOS is a) not compulsory and b) was added without consensus and against standard editing for many editors. GiantSnowman 13:26, 3 May 2022 (UTC)

IMO they are both optional guides. MOS is a collection of hundreds of items, most of them coming from at most local consensus, and many from small discussions or bold edits. And so as a whole it certainly doubly has has no global consensus for the reason described and also that the context for inclusion decisions was that they were going into a mere guideline, and one which further softens itself in it's intro. And a project guide is just from one project. So, as a reference, if a binding rule is 100% influential, the MOS is like 40% influential and a prominent widely used project guideline is like 39% influential. So while MOS might be slightly more influential, IMO nobody should be forcing MOS-based changes to content written in accordance with a heavily used project guideline based on that 1% difference. Sincerely, North8000 (talk) 14:09, 3 May 2022 (UTC)

  • It's untenable that we would allow a new rule to be boldly added to MOS and expect others to start an RfC to remove it, no matter how long the new rule has been there. If it was boldly added it can be boldly removed. People don't watchlist PAGs, there ought be no silence or implied consensus there. There is another thread going on somewhere about whether RFCs should be required for PAG changes and the answer is yes for substantive changes, and this is why. Levivich 14:18, 3 May 2022 (UTC)
    Exactly - the pre-2016 version should be restored, and if people want to change that, they start a RFC to do so. GiantSnowman 15:32, 3 May 2022 (UTC)
  • The wider issue here is that WikiProject Football seems to have developed a bit of a habit of putting themselves in opposition to project-wide consensus. This was an underlying factor in Wikipedia:Arbitration/Requests/Case/GiantSnowman, and now we have: this thread; Wikipedia:Administrators' noticeboard#Admins can ask questions too, where it was proposed that WT:FOOTBALL should be consulted before football AfDs (which we require nowhere else in the project); and today I've closed a bunch of AfDs with participants insisting on voting based on a guideline (WP:NFOOTY) that no longer exists. Active WikiProjects like WP:FOOTBALL are fantastic for our coverage and I wish there were more of them, but as others have pointed out, they're not policy-making organs or editorial boards. If the members of a WikiProject disagree with a project-wide policy, the answer is to engage with the project-wide policy-making process, not try to ignore it. If it doesn't go your way, then you just have to accept that. And I don't say this to admonish WP:FOOTBALL, I say it to warn them. We've seen WikiProjects developing this silo mentality before and it tends to end with ArbCom cases, sanctions, and good editors leaving the project with hard feelings. That isn't good for anyone. – Joe (talk) 14:37, 3 May 2022 (UTC)
    What relevance does my personal ArbCom case from over 3 years ago have to this current issue? Have you even read this thread which makes it clear that the 'rule' was introduced without consensus in 2016 and that it was done so long after a number of WikiProjects had already developed their MOS? There are clear grumblings about this situation from many outside the various WikiProjects. The only thing that "isn't good for anyone" is comments like yours which seem to tar all members of a WikiProject with the same brush. GiantSnowman 15:36, 3 May 2022 (UTC)
    There are clear grumblings about this situation from many outside the various WikiProjects. Great! Let's go do something about it! -Indy beetle (talk) 16:03, 3 May 2022 (UTC)
    We kinda already are! GiantSnowman 16:16, 3 May 2022 (UTC)
    To put it in simple terms for you, what links the two is WP:OWNERSHIP. – Joe (talk) 07:27, 4 May 2022 (UTC)
    Useful contributions only please. GiantSnowman 18:07, 4 May 2022 (UTC)
  • Would it be possible to provide a template that displayed the hyphen (to save space) but the text "to present" (for screen readers)? Hawkeye7 (discuss) 21:57, 5 May 2022 (UTC)
    An excellent suggestion. {{Screen reader-only}} may be useful here. I don't see its converse {{Except screen reader}} but, if the dash is visible and silent, we don't need one. Certes (talk) 23:52, 5 May 2022 (UTC)
    yes, this seems like a fantastic compromise. GiantSnowman 10:39, 6 May 2022 (UTC)
  • The idea a WikiProject can ignore parts of MOS without question seems very troubling to me considering how many aspects of MOS relate to the reading experience (both ability to read and ease of comprehension) for disabled readers. I think establishing a precedent WikiProjects can just do what they want and WP:OWN articles (not how it works) in such a way that could dismantle some of these disability protections seems like a seriously unwise idea to me.— Ixtal ( T / C ) Join WP:FINANCE! 08:14, 6 May 2022 (UTC)
  • Kusma has made the best suggestion in this thread which is to use "Since 2002" in preference to either "2002-" or "2002–pres". That's much better for people using accessibility screen readers than the existing MOS rule, and is short enough to be used generally, including infoboxes. I'd like to see an RFC updating MOS:DATETOPRES to include that, while making it clear that it's not open to any WikiProject to carve out general exceptions. MichaelMaggs (talk) 11:14, 6 May 2022 (UTC)
    But the MOS by its very nature is not compulsory, so unsure why you are complaining about general exceptions - oh and your suggestion will simply result in arguments between 'since 2002' and '2002–pres'. GiantSnowman 11:17, 6 May 2022 (UTC)
    No, "Since 2002" replaces both "2002-" and "2002–pres" in MOS:DATETOPRES. "2002–present" stays, but I don't see people wanting to use that in an infobox. As to your other point, what you position as a right of a Wikiproject to make its own rules independently of MOS, I call WP:OWNERSHIP. There's no need to reply to every post here with the same argument. MichaelMaggs (talk) 11:31, 6 May 2022 (UTC)
    I'll stop replying when people actually start reading the MOS in question and the points raised by many editors (including many those outside the multiple WikiProjects in question). Accusing others of OWNership is incredibly ABF and shows the weakness of your argument/position. GiantSnowman 11:41, 6 May 2022 (UTC)
    Maybe someone could make a regex search to figure out how many articles actually use the "–pres" option, before we argue any more about what to do with it. WhatamIdoing (talk) 19:35, 6 May 2022 (UTC)
    (I will be interested in knowing how often it is used in sortable tables, because "2002–pres" sorts very differently from "since 2002", which is an option that is otherwise very appealing to me.) WhatamIdoing (talk) 19:38, 6 May 2022 (UTC)

I mean, I'm not seeing how any of this is tenable since "present" changes every day at midnite, and certainly becomes untrue in many articles every year, and in at least one article on most days I'd guess. I have seen lots of articles where it says "the song is scheduled to be released in 2017" and so on. It's fairly common. So I mean "present" is often useless and sometimes wrong. "present (as of [year])" is what's required.

There is {{asof}}, but that can't be used in infoboxes, and it's already used on 72,000 pages and how many editors are we going to assign the job of checking each of these every year or so? If you have like "1993-present (as of 2022)" then you warn the user that the info may no longer be current (which "present" alone does not) and also exactly how non-current it is, and you provide editors coming across the material to know if it's OK to let slide ("as of 2021") or possibly take a look at updating ("as of 2004"), without populating a huge category which (I'm guessing) doesn't even differentiate between data from last year and date from the Clinton Administration. I myself occasionally will see a an "as of 2008" and do a quick check to see if the given status is still current and update it to "2022" if that's appropriate. I suppose other editors gnaw away at this too, albeit slowly I'm sure. Using just "present" doesn't tell us if this is needed.

I used to work with a guy who would write "latest version" on the media for each new iteration of an app, heh. Isn't using just "present" a little like that?

TL;DR: why is "present" ever used alone, and why would any rule suggest doing that??? Herostratus (talk) 01:09, 7 May 2022 (UTC)

  • I tried to see how often "-pres" is actually used in articles. Regex search for a 4 digit number followed by one of the various types of dashes and "pres" or "pres." or "present" gives only 1,450 results. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 06:17, 7 May 2022 (UTC)
    OK, this is great research - because given the hundreds of thousands of sports biographies alone which will use year spans (plus tens of thousands of other biographies as well), this clearly shows that the MOS is essentially ignored by everyone, not just the 'few WikiProjects' that some are pointing the finger at. As I have stated many times, the MOS should be changed to reflect the clear wide/long-standing usage by editors. GiantSnowman 07:50, 7 May 2022 (UTC)
    Very few of them are "–pres"; almost all of them (98%?) are "–present". You can see the abbreviation in the last row of the table at Colorado Buffaloes men's basketball#Record by coach. WhatamIdoing (talk) 20:44, 16 May 2022 (UTC)
    Still shows that it is barely used. GiantSnowman 21:02, 16 May 2022 (UTC)
Yeah, I sort of agree. "to present" becomes more clearly wrong when not updated than "since 2000", and the same is true for the variants with a dash. —Kusma (talk) 07:23, 7 May 2022 (UTC)
I don't think that out-of-date information is generally a problem with our articles about footballers, at least those who play in Britain or in the top leagues in major footballing European countries. We usually have, in my experience, editors falling over each other trying to update the articles every time they play a match, often not even waiting until the match is over. Phil Bridger (talk) 07:56, 7 May 2022 (UTC)
Not sure this is also true for, say, Congolese politicians. If we have a rule, it should consider the needs of the less active topics as well. —Kusma (talk) 09:31, 7 May 2022 (UTC)
I'm finding it a bit crazy how many people are saying that MOS is optional. Yes, it is a guideline, but one that we should keep too. If the guideline isn't suitable, then it should get changed. If, however, a particular WikiProject, or even a set of editors don't believe it applies to them, then that's not cool. Maybe a better topic would be if this part of the MOS is suitable. I can't say I've ever seen it before, and is worth discussing. Best Wishes, Lee Vilenski (talkcontribs) 19:31, 9 May 2022 (UTC)
Previous attempts to remove or amend the MOS - which, I repeat, was introduced without consensus - have been reverted. It is clear from this thread that the MOS format is barely used, and as such it should be removed to reflect the clear real-life editing. GiantSnowman 21:05, 10 May 2022 (UTC)

The number of words in wikipedia articlesEdit

Did you know that the number of words in all wikipedia articles is 4,109,724,931.

The maximum size of a 32 bit unsigned integer is 4,294,967,295.

Should we have some recognition for that if it occurs?

2600:6C4E:1200:1E85:10CF:627A:ACF0:5728 (talk) 06:26, 1 May 2022 (UTC)

No. Only if adding more words causes an integer overflow and deletes the content.   AndyTheGrump (talk) 12:27, 1 May 2022 (UTC)
Maybe that would break the Internet. Phil Bridger (talk) 13:15, 1 May 2022 (UTC)
One lives in hope... AndyTheGrump (talk) 14:56, 1 May 2022 (UTC)
I don't think the 32 bit integer limit applies to something like Wikipedia. I could be wrong though. ― Blaze WolfTalkBlaze Wolf#6545 14:01, 2 May 2022 (UTC)
Why wait? Dust-off that old 16-bit PC and put this to the test. (talk) 15:50, 2 May 2022 (UTC)
I don't think a 16-bit PC can have an internet browser. Also, I'm fairly sure we have gone beyond 32 bits, mainly since (For example) Minecraft's limit of normalness is the 256-bit integer limit (After that it still works but it starts breaking). ― Blaze WolfTalkBlaze Wolf#6545 16:54, 2 May 2022 (UTC)
Well, it was supposed to be a joke that apparently misfired, apologies. Or you could make a perfect straight man :). Jokes aside, sure there were (and can be) internet browsers on 16-bit devices, including PCs, but that's another topic. (talk) 17:02, 2 May 2022 (UTC)
Lynx (web browser) can run on 16-bit machines. Anyway, if there is a limit relating to MAXINT, it will either be the number of bytes in a file, or the number of files on a server. The number of words is totally irrelevant - in English, words are delimited by pinctiation and spaces, both od which are characters just like letters or digits. --Redrose64 🌹 (talk) 18:54, 3 May 2022 (UTC)
Please don't disillusion me like this. I was hoping that someone somewhere would break the Internet so we could all get back to a simpler life. Phil Bridger (talk) 20:23, 3 May 2022 (UTC)
A grandma managed to do it once so it is possible. ― Blaze WolfTalkBlaze Wolf#6545 14:23, 6 May 2022 (UTC)
  • the total number of words are from different pages, that is similar to different files. To be short, I dont think crossing that limit will cause anything to happen. If we include all the words from english subdomain only (enwiki), I think we would have the words at least 7-8 times more than the article-space. main talk, user, user talk, WP, WP talk, templates, and literally every text that exists on enwiki. Later, dewiki is subdomain, and technically still a part of "wikipedia" website. —usernamekiran (talk) 05:20, 10 May 2022 (UTC)

Make portals visible in default searchEdit

I suggest that portals be visible in default search alongside with articles (when the user reader does not actively choose namepaces).

Rationale: To increase portal pageviews and to increase awareness of the portals among readers. Not all users readers know about namespaces and what they are. Utfor (talk) 16:33, 3 May 2022 (UTC), edited by Utfor (talk) 18:45, 3 May 2022 (UTC)

I don't think a lot of readers would care to know what namespaces are since I bet the majority of people using the search function on Wikipedia are just trying to find a specific article. But if people think this is a good idea I don't object (but I don't really support it either). ― Blaze WolfTalkBlaze Wolf#6545 18:57, 3 May 2022 (UTC)
My point is not that readers would want to know all about all namespaces, but if they search, they need to know what the portal namespace is in order to find portals in the search. Utfor (talk) 19:06, 3 May 2022 (UTC)
Well I honestly don't see why a reader would want to use the portal. If a reader is looking for a specific article they'll just search for it. ― Blaze WolfTalkBlaze Wolf#6545 19:09, 3 May 2022 (UTC)
  Oppose - if a reader is searching for an article, why would they want a portal? ―  Qwerfjkltalk 19:27, 3 May 2022 (UTC)
You could shorten that to "why would they want a portal?". Seriously, just scrap the damn things. --User:Khajidha (talk) (contributions) 19:38, 3 May 2022 (UTC)
I believe we should just deprecate portals entirely.--WaltCip-(talk) 16:53, 4 May 2022 (UTC)
  • Oppose, per above. Portal talk pages are dead, portal pages are dead, just desolate in general. Take the Formula 1 portal, it gets less pageviews than an article I wrote about a diabetes medication. I wouldn't be saddened at all to see them go. X-750 I've made a mistake, haven't I? 03:01, 5 May 2022 (UTC)
  • Support – If links to portals are not available anywhere to WP:READERS, then readers are left in the dark, then having no way of knowing about their existence. Omission of portals from searches on en-wiki is exactly why page views for some portals may be lower than they need to be; readers don't see links to them. Portals should not be censored from public consideration. Then, when more people actually learn about portals, because they can actually see links to them, more editors will naturally come along to improve them. North America1000 14:11, 6 May 2022 (UTC)
    But why would readers be interested in portals in the first place? If a reader is looking for a specific article, they wouldn't be wanting ot see results for a portal on a related subject. They would be looking for the article. ― Blaze WolfTalkBlaze Wolf#6545 14:17, 6 May 2022 (UTC)
    Queue the portals to link below the main articles, creating an option, rather than no option being available. North America1000 14:28, 6 May 2022 (UTC)
    I don't see how that would make users click portals more. In fact it probably wouldn't make a difference since if a user starts typing the article title in, a bunch of different articles will pop up (probably more than can be displayed) before it reaches the bottom unless it's the exact article title or no other article title matches that, which in that case the portal wouldn't match what is typed. ― Blaze WolfTalkBlaze Wolf#6545 14:42, 6 May 2022 (UTC)
  • Oppose Can we just stop trying to beat life into the dying horse that is Portals? casualdejekyll 14:30, 6 May 2022 (UTC)
    • Your logic seems inversed, because providing readers with an option to actually see portals does not "beat life" into them. Rather, this would actually make them more visible to readers. Why should we "stop trying" to make an entire Wikipedia namespace readable? Many readers become editors, but readers cannot potentially improve hidden content. North America1000 14:46, 6 May 2022 (UTC)
  • I dont know if IPs can vote but I would support this had I had a account-- (talk) 14:13, 7 May 2022 (UTC)
Portal:COVID-19 Moxy-  14:17, 7 May 2022 (UTC)
  • Oppose. The default search settings should, in my opinion, contain the minimum amount of pages required to get readers to what they are looking for. Cluttering up default search with pages of questionable usefulness in the name of "increasing visibility" makes searching for stuff a more time consuming and worse experience. Portals aren't useful for navigation because they contain a semi-random selection of snippets from articles and are often quite badly out of date - it's completely pot luck as to whether you'll find what you're looking for. Portals already have fancy bars, buttons and links in basically every major article on the site, that should be more than enough visibility for readers to realise they exist. (talk) 10:50, 8 May 2022 (UTC)
  • Weak support. I didn't know what a portal is until like 6 months ago. It's just hidden too deep inside. And it's a reader-facing namespace. Not something like Modules or MediaWiki pages. Portals are a really nice way to navigate Wikipedia, but people simply don't know about their very existence. CX Zoom[he/him] (let's talk • {CX}) 14:05, 8 May 2022 (UTC)
Conditional support, oppose otherwise. I would support this only if this is part of a portal viability test which after x months (say 6 months) we check if portal traffic has significantly increased. If they haven't, the portal namespace finally gets deleted. There are voices that keep trying to revive this failed idea, when the evidence consistently shows no one cares but a very small group. Gonnym (talk) 17:10, 8 May 2022 (UTC)
No, we've already rejected deletion of the namespace multiple times. This discussion is about making them visible, particularly in the wake of main page unlinking which concealed major portals from 90% of visitors. Certes (talk) 20:01, 8 May 2022 (UTC)
  • Oppose Portals are already searchable in the search engine, as is any namespace. There are already links to portals in the "see also" sections of many articles. Not only that, but portals are barely updated anymore. The last time Portal:United States was updated was April 9, last time Portal:The arts was updated was January 9, and so forth. Even from my own experience as a reader, in the 15+ years that I've used Wikipedia, I used portals a grand total of zero times. Trying to bring back portals is like trying to bring back the dinosaurs. It's not going to improve reader experience and sometimes its just better to let something that's dead stay dead.—Mythdon (talkcontribs) 17:39, 8 May 2022 (UTC)
    That is incorrect. The last edit to a portal page is not when it was last updated. Just like on Wikipedia's Main Page, portal updates usually come from elsewhere. See for example [1]: the United States portal is updated about every week. —Kusma (talk) 08:26, 9 May 2022 (UTC)
  • Support Portals aren't good because of their low visibility. If portal visibility keeps getting suppressed by people because "Portals are bad," how are they expected to ever improve? They're worsening the problem they're blaming. — PerfectSoundWhatever (t; c) 03:50, 9 May 2022 (UTC)
  • Oppose - An attempt to resurrect a dying concept. Let's focus on working on what already appears in the default searches - the actual articles which are the purpose of this project. -Indy beetle (talk) 07:30, 9 May 2022 (UTC)
  • Support at least as a test. Portals are so hidden now that people only rarely stumble upon them. Any change to their view counts needs to come from outside of portal space; without either something like this or a way to make portal links in articles more visible, we should expect portals to continue to slowly die. We should not hide gems like Portal:Cheshire from our readers. —Kusma (talk) 08:26, 9 May 2022 (UTC)
  • Oppose. Portal:Cheshire (given above as an example) is already linked from 1579 mainspace articles[2] and is viewed on average 6 times per day. Most people just aren't interested in them, and any effort spent on them is a waste of time. Perhaps Cheshire is a low-interest topic, but Portal:Covid-19 is also clearly linked from some 1600 mainspace articles, many of them very often visited (pages like COVID-19 pandemic and so on), and it gets only 84 pageviews per day. Portals just aren't what people are looking for here, very few people seem to be using portals as their entry point or seem to be returning to them on a regular basis. Sending more people to pages they don't really want is not useful. Fram (talk) 09:46, 9 May 2022 (UTC)
    The thing is, portals are technically "widely linked", but never in a place where I actually see the link (they are competing for my attention with far too many other things). In articles longer than two screens, I don't think the portal links do anything. I don't have a particularly good suggestion how to change that. To put the pageviews into some more perspective, the portals are more popular than outlines and indices: [3]. —Kusma (talk) 10:10, 9 May 2022 (UTC)
  • Oppose as they are pretty useless. We should be moving away from Portals. Graeme Bartlett (talk) 10:15, 9 May 2022 (UTC)
  • Question. Aren't categories reader-facing (and much more well-maintained)? Wouldn't this logic apply to them, too? –MJLTalk 17:27, 9 May 2022 (UTC)
  • Oppose portals have been dying a slow death for over a decade. Whatever use they may have once had, they are now basically moribund, and I see no reason to enact the proposal. --Jayron32 17:41, 9 May 2022 (UTC)

A Proposal to formalise and centralise the control and reporting of Undisclosed Paid EditingEdit

Wikipedia, by which I mean the community that is the English language Wikipedia, is serious about controlling undisclosed paid editing. That we know.

Wikipedia requires paid editors to disclose their status. See WP:PAID. It provides four levels of warnings to suspected paid editors (UPE) who have not made a proper disclosure:

Editors in good standing who suspect an editor of UPE are encouraged to use these warnings in good faith, at which point the system ends. There is no obvious, nor reliable, route forwards.

Instead, we have independent, committed editors and admins alike who try, and often succeed, in pursuing UPE either to a formal disclosure (good), or to an indefinite block (also good) should they not disclose and matter be proven.

But proven is a difficult word in this context. Proven by whom, and to what universal and agreed standard? Using what tools? Using what authority to use a putative toolset that may not even exist?

Were we investigating sockpuppetry then the route to opening an SPI is clear. We even have tools to assist us. We pass the task to a team of acknowledged experts, a team empowered within agreed limitations to investigate, and to act. We make the evidence based report, and stand aside, confident that experts will reach an evidence based conclusion. We trust the team.

For paid editing investigation we have a loose confederation of gifted amateur sleuths, Miss Marples if you will. Like Miss Marple, that loose confederation is susceptible to being accused of being interfering busybodies, perhaps being pilloried by accusations of bias, perhaps being accused of many other and more serious things, all from areas where they have acted in good faith and met a powerful Wiki-enemy. This can lead to our Miss Marples being driven away. 🇺🇦 FiddleTimtrent FaddleTalk to me 🇺🇦 18:51, 9 May 2022 (UTC)

Proposal (UPE reporting)Edit

To counter this I make a simple sounding proposal, one that will create a trusted core team of UPE fighting experts, very much along the lines of our Sockpuppetry team.

Those experts are to be provided with, or to create, or to cause to be created, such tools as will, with correct community consensus based approval, ease the work of identifying UPE beyond reasonable doubt.

The experts will start from a mixture of community reports (cf SPI) and their own initiative, always processing their work in as transparent a manner as does not create a WP:BEANS situation, and does not breach the legitimate privacy rights of editors who fall within the scope of their investigations.

As usual I hope the community will seek to improve on this very simplistic proposal. 🇺🇦 FiddleTimtrent FaddleTalk to me 🇺🇦 18:51, 9 May 2022 (UTC)

Discussion (UPE reporting)Edit

  • This is wayyyyy overreaching imo and overly bureaucratic. As someone who works extensively in identifying UPE, this is a super myopic view/proposal and way too black and white, which UPE is not. It's more than just fiverrs and freelancers being hired and one off employees editing on behalf of their company. Further this is also somewhat redundant because it's already required by the terms of use, which isn't subject to enwiki's discretion (with regard to warnings, which are often ingnored as well as disclosure.) Creating a "trusted group" is also unrealistic imo. Who is to say who is trusted and who is not? A lot of UPE identification in terms of identifying the who/where they were hired can and is done off wikipedia and disclosing more than that would disclose a lot of tells and identifiers we use. PRAXIDICAE💕 18:59, 9 May 2022 (UTC)
    @Praxidicae I'm glad you said that, and I understand it, and thank you. You are one of the committed and gifted people I refer to. What I hope to happen is for the community to use this discussion as a spur to show people like me an approved route forward. I am not wedded to any of the proposal, but I feel that we must start somewhere for the ordinary editor. Counter proposals are more than welcome. 🇺🇦 FiddleTimtrent FaddleTalk to me 🇺🇦 19:07, 9 May 2022 (UTC)
    @Praxidicae: Whats a fiverr? —usernamekiran (talk) 21:13, 9 May 2022 (UTC)
    @Usernamekiran: Fiverr[4]. PRAXIDICAE💕 21:17, 9 May 2022 (UTC)
    Honestly a lot of this proposal is just too much, it's like 9 solutions in search of a problem. Is the way we handle UPE the most ideal? No, but it's also not possible in some aspects to do any better because of our policies on outing and AGF, add to that, sometimes it's better not to disclose publicly what we do know because that's a tip off to some of the more damaging paid editing firms. Further, formalizing a "group" of individuals is a bad idea because it's going to become an issue of gatekeeping. I also worry that formalizing said group would result in more malicious harassment of editors (I can attest to this personally as I'm accused on a nearly daily basis here and off-wiki of "working for competitors") and we'll wind up with more blown-out-of-proportion ANI threads like the one targeting Celstina at ANI right now, especially when the particularly powerful paid editors with thousands of edits, which trust me, do exist, get rubbed the wrong way. PRAXIDICAE💕 19:12, 9 May 2022 (UTC)
    How do we protect the Celestina007s of our community?
    You are opening up very substantial areas for discussion. I am at the end of my expertise, and hope to learn, now. If the proposal is too much, then please prune it, refactor it, do what you believe needs to be done to it, because those who, like me, look up to those like you are unsure how to move forward. 🇺🇦 FiddleTimtrent FaddleTalk to me 🇺🇦 19:21, 9 May 2022 (UTC)
  • Isn't WP:COIN already a centralized board for handling conflict of interest? It suffers from low traffic (or at least, low uninvolved traffic), but IMO is the "next step" that this proposal asserts is missing, in that it's a centralized board for community review of COI concerns. signed, Rosguill talk 19:02, 9 May 2022 (UTC)
    FWIW I don't consider COIN to be a particularly valuable part of identifying UPE since a lot of what we need to demonstrate to prove that an editor is a paid editor (outside of one off obvious accounts that get blocked at the start for spamming/paid editing) can't be posted on-wiki. PRAXIDICAE💕 19:04, 9 May 2022 (UTC)
    Me neither. As soon as it reaches coin its dead, they start to play up and fudge it. I suspect coin and board are pretty much dead. Its show the decay in Wikipedia that once vibrant board is now barely used. scope_creepTalk 20:40, 9 May 2022 (UTC)
  • I'm not clear on what is being proposed that requires community consensus. It sounds like you are proposing that some tools be created, but without specifics, it's unclear if this is something requiring access to private information. If not, then anyone can create tools using publicly available data. (I know there has been sensitivity in the past with things like building a notification system for a user's edits, but there is no way to prevent someone from using public data as they will.) isaacl (talk) 20:02, 9 May 2022 (UTC)
  • I'm not sure that "prove" is a good word to use, unless we also specify the standard of proof required. I have always understood that the standard of proof required to take sanctions here to be (using terms from English law, which I am most familiar with) below the standard required in criminal cases (beyond reasonable doubt) but above that required for civil cases (balance of probabilities). Blocking, or other sanctions, are important enough not to be taken lightly, but we are not taking away anyone's liberty or money here, simply telling them not to edit a web site. Phil Bridger (talk) 20:09, 9 May 2022 (UTC)
    It's even better than that: we're taking away their money if and only if they're guilty. Certes (talk) 20:49, 9 May 2022 (UTC)
  • I don't think the proposal is bureaucratic from what I interpret it to be. But it is a little loosely/vaguely defined. I think COIN is best suited venue for UPE, and related discussions. Like Praxidicae said above, there are PR/editing firms at play, these are way different than one-off, or overly obvious newbies/freelancers. UPE, and accusations of UPE requires (most of the times) off-wiki evidence, and providing that off-wiki evidence would be revealing our methodology/MO, which would help them improve, and would make finding UPEs difficult for us. Other issue here is about outing, and other related stuff. The best way to tackle this is to call it COI instead of UPE. That way, way have to provide less (on-wiki) evidence so that we can prove COI, and maintain the discreetness of our MO, and get that ediotr topic banned from the particular topic. I am not sure what tools you are thinking (to use/create) that could help identify UPE. I dont think thats even possible. But what we could do is, to make a subpage somewhere in COIN to list all the editors who are interested to work against UPE/COI. A procedure/guideline in case we come across UPE/COI to get blocked. If the evidence is solid, we can provide it to ARBCOM, and they can block the UPE/COI editor through role account to avoid being targeted/harassed. Praxidicae has also voiced my concerned about the team which I raised here. In short, NPP/R was not formed in a week, it is result of years. We can create an informal list in a subpage of COIN. We should create a standard guideline/procedure for course of action if COI/UPE is found. It would be better if the course of action somehow hides the investigator (arbcom/role account?). With time, this process might grow/develop automatically. —usernamekiran (talk) 21:13, 9 May 2022 (UTC)
  • I'm trying to get my head around what this would involve. As far as private data goes, the two main types that assist with UPE would be CU and information about job ads and advertisements. The former is already handled in an existing system, and I fear that special "UPE CU" admins would risk creating too many new problems. I can see a case for expanding the use of CU in order to tackle prolific sockpuppeteers, but that could be handled in the existing CU framework. In regard to the latter, WP:OUTING has already been modified to both a) permit the linking to job ads on COIN even when there is a risk of identifying editors; and b) requiring paid editors to "self-out" by linking to their profiles on freelance sites from their user pages. As to what editors do off-wiki, such as watch job ads and known contractors, (which, in the interest of full disclosure, I do), I'm not sure how can be involved. The issue is that ultimately, what someone knows from off-wiki data is irrelevant unless it can be shared, as in the end you can only block or request a block if you can support it with evidence, even if that evidence needs to be shared on COIN or with a trusted admin/arbcom per the existing COI procedures. Any other "tools" would only be to look at on-wiki editor behaviour, wouldn't involve private data, and therefore I don't think should be limited in access to a select group, as that is counter to our principal of transparency. To be honest, I think the only effective way of combatting most paid editing is to make Wikipedia less attractive for advertising by making the rules on businesses and individuals more restrictive, but I don't see that happening any time soon. - Bilby (talk) 23:15, 9 May 2022 (UTC)
    CheckUsers already handle nonpublic evidence of UPE sent to [email protected] – mainly advertisements on freelancing websites. Perhaps we need to clarify that this is preferred way of reporting over sending to individual admins (per WP:BLOCKEVIDENCE, individual admins should not act on nonpublic evidence because it leaves no paper trail) or ArbCom (who have enough on their plate and set up [email protected] for that reason). The instructions seem to be scattered all over the place and out of sync. – Joe (talk) 11:43, 10 May 2022 (UTC)
    It seems that there is some variation on this around - I'm very happy to see that clarified. Thanks! - Bilby (talk) 11:52, 10 May 2022 (UTC)
  • If something needs to be changed, it's WP:OUTING. The policy section was never meant to protect people who are here to exploit our collaborative non-profit project for their own financial ends. It's part of the harassment policy, after all. The point is to protect people from being doxxed because they made controversial edits, blocked a popular user, or pissed off the wrong LTA. We should just expand the exceptions Bilby mentions to one of "accusations of pervasive conflict of interest in a user's editing". I don't get why we twist ourselves in knots defending those who want to hurt what we've built. -- Tamzin[cetacean needed] (she/they) 08:45, 10 May 2022 (UTC)
  • Those experts are to be provided with, or to create, or to cause to be created, such tools as will, with correct community consensus based approval, ease the work of identifying UPE beyond reasonable doubt. What kind of tool do you expect to be created that requires special permissions? Tools that rely on non-public data are already restricted to admins or checkusers. It seems a bit premature to setup a whole new process to authorize the use of some tools, when we don't seem to have tools to authorize in the first place. MarioGom (talk) 14:13, 10 May 2022 (UTC)
    Sorry, coming to this quite late, as I'd only noticed the parallel discussion at Wikipedia:Village_pump_(idea_lab)#Undisclosed_Paid_Editing. The wording here might be partly my fault, as I raised the concern at a current ANI argument, where a UPE-hunter has been accused of making unclear and exaggerated statements about the tools and powers available to them. I replied at ANI that I thought UPE-hunting was better done by a selected group who have whatever tools they need, and have procedures in place to follow: if we minions knew what rights UPE-hunters have, and how the decision is reached, UPE-hunters wouldn't have to justify their actions by claiming mysterious special rights and abilities, and we'd have been spared an outstandingly long and painful ANI. It may just be that we need better documentation of what processes already exist. But the ANI thread is strong evidence that we haven't quite got this right yet. Elemimele (talk) 12:29, 11 May 2022 (UTC)
    The problem I see with that ANI thread is that too many people were too happy to continue talking about non-existing special rights and non-existing secret tools even after receiving many technical explanations. And this is a good example of the FUD that, unfortunately, continues: if we minions knew what rights UPE-hunters have There're no "UPE-hunter rights". Any discussion that continues standing on this false premise is not going anywhere useful. MarioGom (talk) 17:50, 11 May 2022 (UTC)
    @MarioGom:, that was partly my point. With neither any special tools, nor with a duck-test for UPE, it's basically impossible to fight it without landing up at ANI, because there is no conceivable situation in which you can make an accusation of UPE without being accused of bad faith. You say they're doing UPE. They say they're not paid. And if you don't believe them, you're the baddie. If there were a duck-test, you'd at least be able to say "account is quacking"; if there were some technical way to match up the account to IP addresses previously found to be indulging in UPE, or that match organisations/people advertising their services as WP editors-for-cash, then someone could declare the editor a UPE (though this probably overlaps very heavily with SPI); and if there were a group given particular rights to reach the decision, the decision would look less like an individual piece of vindictiveness, and more like a community consensus. My feeling is that as things stand, it simply isn't sensible to go looking for UPEs precisely because there are no tools, definitions or special groups to do the job. I just can't decide which is better: abandon hunting UPE and just attack bad edits irrespective of their cause; or create structures/tools/definitions to legitimise UPE-hunting. Elemimele (talk) 12:19, 13 May 2022 (UTC)

Support (UPE reporting)Edit

Oppose (UPE reporting)Edit

  • Per Praxidicae; seems overly bureaucratic and a solution in search of a problem. firefly ( t · c ) 19:17, 9 May 2022 (UTC)
  • This isn't something that can feasibly be done within policy or practicality, due to the concerns Praxidicae brings up. It's impossible to definitively determine whether a user is UPE without either self-outing or outright outing that is almost guaranteed to also have collateral damage, especially given the tendency of UPE editors to lie in an effort to not have to disclose. —Jéské Couriano v^_^v a little blue Bori 20:18, 9 May 2022 (UTC)
  • COIN. Use it. casualdejekyll 22:03, 9 May 2022 (UTC)
  • Per prax in the discussion section. Our processes for handling and documenting UPE could be improved, but bureaucracy and yet another pseudo-permission won't do that. This proposal should have been workshopped with people active in this area first (@Timtrent: did you see Wikipedia:Village pump (idea lab)#Undisclosed Paid Editing?) – Joe (talk) 11:38, 10 May 2022 (UTC)
    @Joe Roe Too late, unfortunately. 🇺🇦 FiddleTimtrent FaddleTalk to me 🇺🇦 17:31, 10 May 2022 (UTC)
  • Hell no. As soon as we are asked creating "trusted core" teams of "experts" to "fight" anything, we should run screaming in the other direction. Just. No. --Jayron32 14:06, 10 May 2022 (UTC)
    @Jayron32: I am not opposing you, but your "to "fight" anything" comment intrigued me a lot. Would you kindly elaborate on your (entire) comment? I mean, whats the reasoning behind it? —usernamekiran (talk) 22:00, 11 May 2022 (UTC)
    I don't find the battleground mentality a useful way to build an encyclopedia. We don't fight. We write articles and make them better. Also, since you said "entire", I also oppose empowering any centralized group with extra powers in this regard. --Jayron32 11:40, 12 May 2022 (UTC)
    I totally agree, with every point. I am glad that I asked for the clarification. Thanks for the response :-) —usernamekiran (talk) 20:11, 12 May 2022 (UTC)
  • Strongest possible oppose in line with Jayron and Praxidicae. — Ixtal ( T / C ) Join WP:FINANCE! 14:14, 10 May 2022 (UTC)
  • Oppose Lots of nasty stuff with little prospect of helping. North8000 (talk) 17:52, 10 May 2022 (UTC)

Neutral (UPE reporting)Edit

  • Neutral so as not to pile on, and so as not to further set back the likelihood of doing something about UPE, because any more Opposes may be interpreted as opposing the need to improve the process of dealing with UPE. I am saddened that User:Timtrent decided to throw out a half-baked proposal, knowing that his objective was to avoid having a more detailed proposal torn apart, and so instead getting the whole idea torn apart. I had hoped to work out some idea about how to improve the UPE process at the Idea Lab, but this has probably left any such efforts dead for the next few months. COIN does not work consistently or well. We have two policies that interfere with each other, the rule against UPE, and the rule against outing, and we have given the wrong priority to the two, so that anonymity can be used for advertising. We have a good policy that isn't enforced, and we need better enforcement, and this idea has probably made discussion of better enforcement out of the question for a few months. Robert McClenon (talk) 16:55, 10 May 2022 (UTC)
    Perhaps Timtrent will withdraw this. Alanscottwalker (talk) 18:03, 10 May 2022 (UTC)
    @Alanscottwalker I think that this proposal may fail, but do not see how a failed proposal does not act as a catalyst for a better proposal. Nor do I understand why folk here seem unable or unwilling to modify the proposal or to create a counter-proposal.
    You or anyone else are welcome to accuse me of naïve thinking if that is what I have shown and if you wish to, but I have always though that we, the community, were better than this, and could and would discuss proposals to reach one that we would agree on. 🇺🇦 FiddleTimtrent FaddleTalk to me 🇺🇦 12:53, 11 May 2022 (UTC)
    For what it's worth, I don't think this proposal failing is any set back for other well thought proposals on UPE or COIN. MarioGom (talk) 21:27, 10 May 2022 (UTC)
    @MarioGom Agree with you. Failed proposals can highlight a difficult area. A failure, which seems likely here, ought to act a catalyst for wiser heads than mine to create better proposals. I am wholly lost as an AFC reviewer. If I act in good faith over what I perceive as UPE I risk being pilloried for those acts at ANI as is happening to another editor at present. I have no formal route forward. I believe we need one, and a good proposal for one. Mine seems to be destined for failure, but so what? Better editors than I can create better proposals. 🇺🇦 FiddleTimtrent FaddleTalk to me 🇺🇦 13:14, 11 May 2022 (UTC)

RfC: Bot to blank old IP talkpagesEdit

Should a bot be used to blank old IP talkpages which:

  • Have not received any messages in the last 5 years
  • The IP is not under active blocks (including range blocks)
  • There have been no edits from the IP in the last 5 years

Pages that meet this criteria will be blanked and replaced with {{Blanked IP talk}}, which reads

ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 04:31, 10 May 2022 (UTC)


There are millions of IP talkpages with vandalism warnings received since the earliest days of Wikipedia. Recent vandal warnings serve a useful purpose, but warnings from very long ago are detrimental as there is a high chance that the IP address would have shifted to different users. Stale warnings and other messages will confuse legitimate new editors editing from that IP seeing it apparently directed at them. Blanking the page and replacing it with {{Blanked IP talk}} template will avoid confusing legitimate editors, while still allowing access to potentially useful edit history.

Other benefits of this task will include uncluttering the Special:WhatLinksHere data for pages across all namespaces. Stale IP talkpages contains millions of links to articles, policy pages and their associated redirects, User pages, User talk pages, templates etc,. They will be cleaned up with this task.

This will involve the bot editing at least 1.5 million pages. If consensus is found for this proposal, I (or anyone else) can use a bot to implement it, subject to the normal WP:BAG approval from the Bot request for approval process.

Here are some sample edits: [5], [6], [7]ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 08:22, 11 May 2022 (UTC)

Survey (iptalk blanker bot)Edit

  • Support, as proposer. I believe the criteria is a safe base for a bot to work from. We can discuss the bot's techincal implementation details, its handling of edge cases and see if any minor changes are necessary during the WP:BRFA process. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 08:37, 11 May 2022 (UTC)
  • Support. I understand some concerns raised in the discussion, and think that we can proceed cautiously by having such a bot begin by focusing on very old IP talk pages (e.g., the IP has neither edited nor been blocked for over 12 years, and the page has not been touched in that time), and once those are done, evaluate any surprises and move the limit up a year, and proceed that way until we get to the five year range. BD2412 T 05:54, 12 May 2022 (UTC)
  • Weak support I still have reservations over the matter, as I noted in the WP:VPIL discussion, but at least I have a sense that those reservations are also in the minds of the BotDevs and will be taken into account. --Jayron32 18:08, 13 May 2022 (UTC)
  • Oppose Not worth it, especially given that IP masking is happening soon. * Pppery * it has begun... 18:13, 13 May 2022 (UTC)
    One does not simply get to roll out IP masking. Major changes like that take a long time to happen. Many things about it is still not clear and WMF has yet to give a timeframe for implementation. Even after IP masking is rolled out at some point, stale IP talkpages will continue to pose a maintenance burden. A substantial portion of the existing millions of Lint errors is because of IP talkpages. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 19:19, 13 May 2022 (UTC)
  • Support - seems a reasonable approach and looks like it's being handled sensibly. Andrew Gray (talk) 17:43, 14 May 2022 (UTC)
  • Support. I see no reason as to why decade old IP talk pages shouldn't be templated out automatically, saving much time and manual effort, I sometimes find in RecentChanges. CX Zoom[he/him] (let's talk • {CX}) 18:08, 14 May 2022 (UTC)
  • Support. There is indeed too much of a maintenance burden with these old IP talk pages. Blanking them / Blanking with template will reduce this while also making the what links here a bit more useful again. --Gonnym (talk) 20:18, 14 May 2022 (UTC)

Discussion (iptalk blanker bot)Edit

I think I still prefer a subst'd type version of that simple template, so as to not add over a million instances of a template out there (which drags along another template, which drags along a module, etc). — xaosflux Talk 10:40, 10 May 2022 (UTC)
My preference for using a transcluded template is that if we have to change something due to future software changes (say the {{FULLPAGENAMEE}} magic word or some table markup), we can just update one page instead of having a bot go around changing substed uses. If the associated templates and modules are a concern, a compromise will be to hardcode {{Blanked IP talk}} to not use any other templates and modules. However note that every template and module used by {{Blanked IP talk}} is already used heavily enough to be under full protection. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 11:06, 10 May 2022 (UTC)
I have gone ahead and hardcoded most of the template, with no change in text. Previously it used 7 other templates and modules, now it uses only one. When reading this page from mobile, I realised the old template did not render in mobile due to it using tmbox tmbox-notice classes. Now it renders in mobile too. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 16:39, 15 May 2022 (UTC)
Question, what if the IP talk page hasn't received any actual warnings in 5 years, but their talk page got vandalized by another IP or a user before that 5 years happened, and no one noticed? Maybe the bot should look to see if there were any new warnings placed on the talk page in 5 years? ― Blaze WolfTalkBlaze Wolf#6545 14:13, 10 May 2022 (UTC)
The idea is to remove all stale messages from inactive IP talkpages, not just warnings. This is why {{Blanked IP talk}} uses the word "messages" instead of "warnings". If the page has received any edits within the last 5 years, the bot will ignore it. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 14:48, 10 May 2022 (UTC)

FYI, there's {{Old IP warnings top}} and {{Old IP warnings bottom}} for IPs that are quite likely shared. Then again, shared IPs probably wouldn't go for five years without a talk page message. --I dream of horses (Contribs) (Talk) 20:52, 10 May 2022 (UTC)

I use those templates regularly when I see lots of old warnings, and I think that it is a better solution han just blanking them out, but I also wonder if this whole idea will be moot if/when the WMF rolls out IP masking. Beeblebrox (talk) 21:10, 10 May 2022 (UTC)
Might it make more sense to wait for IP masking, give it a year or so, then delete every IP talk page? They're not going to be used any more. And even for users with the "unmask IP" right, the old unused IP talk pages will be less and less useful as months go on, given the dynamic nature of most IPs. Suffusion of Yellow (talk) 21:23, 10 May 2022 (UTC)
Deletion of things other than routine warnings risks deleting important information. Also, IP addresses aren't going away completely for a long while. Also, an old proposal thing maybe of interest: WP:OLDIP. -- zzuuzz (talk) 21:35, 10 May 2022 (UTC)
Once masked identities are introduced, unregistered editors won't be looking at IP talk pages anymore but instead looking at their own talk pages. Thus the old IP talk pages won't have to be deleted to avoid confusion, and I think should be kept to preserve any discussions. isaacl (talk) 22:30, 10 May 2022 (UTC)
That goes to the second reason for templating these pages. The discussions contain links—millions of links. Links to articles, links to disambiguation pages, links to user pages and user talk pages, links to Wikipedia policy pages. Cleaning up incoming links across multiple namespaces for pages that tend to accumulate bad links is burdened by the clutter of links to decade-old messages from long-abandoned IP talk pages. BD2412 T 23:26, 10 May 2022 (UTC)
@BD2412 that sounds like an argument for clearing those pages - not really for why adding a million instances of a template is the best solution. — xaosflux Talk 23:32, 10 May 2022 (UTC)
An intentionally templated page is immediately distinct from a page blanked for reasons unknown. IP editors sometimes blank the warnings they receive; in my experience, they never template them. I do agree, by the way, that these can not be deleted, as the edit history may contain useful information. BD2412 T 23:35, 10 May 2022 (UTC)
I'm pretty sure we won't need to keep most of those messages. When it comes to schools, there's actually a high chance that the IP address will remain assigned to the same organisation. We frequently block schools for five years because they've shown that they can be that static. They can even get re-blocked without any new talk page messages. I can see a situation where a school comes fresh off one of these blocks to a freshly blanked talk page. I don't think that's necessarily a problem, but I also don't think it's fully recognised by this proposal. In an ideal world, we'd probably want to check when a block was made or expired. -- zzuuzz (talk) 21:17, 10 May 2022 (UTC)
The proposal would exclude blocked pages from templating, but could be expanded to exclude pages that have come off a block within, say, the past three or four years. Ultimately, the vast bulk of pages we are dealing with are IPs that have actually never been blocked, but received a warning or a caution once or twice many years ago, and were never used again. That is pure clutter. I would certainly not be opposed to developing a protocol which starts with the most decrepit pages, and works up from there in a relatively slow and methodical fashion. BD2412 T 23:30, 10 May 2022 (UTC)
As BD2412 says (who have been doing this semi-automated for some time), the proposed criteria is enough for vast majority of IPs. I can set the bot to ignore pages having {{Schoolblock}} even when the IP is currently not blocked or check for block expiry date for pages having school block template. We can discuss these kind of cases and other technical implementation details when the BRFA is filed. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 02:53, 11 May 2022 (UTC)

Wikipedia:Naming ConventionsEdit

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

There are multiple entries in Category:Wikipedia naming conventions, but all of them are violations of Wikipedia:Article_titles#Disambiguation due to location of parenthesis. The dab category need to be in the parenthesis, not individual entries. So Wikipedia:Naming conventions (X) should be Wikipedia:Naming conventions for X (or something that follows the disambiguation rules). There has been no consensus discussion for those names, so here we are having it. Proposed titles are Wikipedia:Indian constituencies naming conventions or Wikipedia:Naming conventions for Indian constituencies or Wikipedia:Indian constituencies (Naming conventions)

How can they violate a policy on article titles? They are not articles. Phil Bridger (talk) 19:20, 11 May 2022 (UTC)
  • We can certainly discuss renaming these guideline pages… but Phil is correct: WP:Article titles applies to article space, not policy/guideline space. Blueboar (talk) 19:26, 11 May 2022 (UTC)
  • So you're saying we need to develop a naming convention for naming naming conventions? – Joe (talk) 19:27, 11 May 2022 (UTC)
    @Joe Roe @Blueboar @ZLEA these page titles (in the category) as they stand currently are strangely titled and I have suggested a proposal with a more natural title without being complicated by unnecessary use of parenthesis. You may disagree with my observation, that's ok. If we can discuss on the merits of the proposed title vs existing title of these pages, that would be more fruitful for this discussion. Thanks. Venkat TL (talk) 19:51, 11 May 2022 (UTC)
  • As I stated in the preceding move discussion, and as Phil states here, WP:TITLE does not apply to Wikipedia-namespace pages. WP:TITLE itself says "This page does not detail titling for pages in other namespaces." - ZLEA T\C 19:32, 11 May 2022 (UTC)
  • Follow up - I believe the current titles are the most convenient. The pages in question are naming conventions, so it makes no functional sense to have the topic come before "naming conventions" in the title. Having "naming conventions" before the topic arguably makes it easier to search for naming conventions, so Wikipedia:Indian constituencies naming conventions and Wikipedia:Indian constituencies (Naming conventions) don't make much sense. Furthermore, Wikipedia:Naming conventions for Indian constituencies is needlessly wordy, and in my opinion, Wikipedia-namespace page titles should be concise for easier searchability. - ZLEA T\C 20:16, 11 May 2022 (UTC)
    The difference between the two is only 2 alphabets. Not words, 2 alphabets. If that is a concern, then #2 below is the shortest.
    1. Wikipedia:Naming conventions (aircraft)
    2. Wikipedia:Aircraft naming conventions
    3. Wikipedia:Naming conventions for aircraft
    Venkat TL (talk) 21:24, 11 May 2022 (UTC)
    The problem is that #2 does not put "naming conventions" before the topic, thereby making it harder to search if one is looking for naming conventions. - ZLEA T\C 21:54, 11 May 2022 (UTC)
    Sorry but this is silly. GiantSnowman 21:25, 11 May 2022 (UTC)
  • WP:If it ain't broke, don't fix it. The current conventions are fine, and convenient, like multiple editors voiced their opinion at Wikipedia talk:Naming conventions (Indian constituencies)#Requested move 11 May 2022. —usernamekiran (talk) 21:56, 11 May 2022 (UTC)
  • Oppose. Notability (people), Notability (organizations and companies), etc., is superior to Notability of people, Notability of organizations and companies, etc. (Although, a colon would also work: Notability: people, Notability: organizations and companies.) — kashmīrī TALK 00:59, 12 May 2022 (UTC)
  • I initially closed this with the summary

    Let's all focus on more important things, like what the new bikeshed should look like. I vote hot pink! -- Tamzin[cetacean needed] (she/they) 07:24, 12 May 2022 (UTC)

    Venkat has since objected to that close. In my view, it is per se disruptive editing to try to prolong a discussion about something profoundly pointless that has no chance of succeeding. It represents a fundamental misunderstanding of the nature of discussions in an all-volunteer organization. And it is particularly troubling to see from someone who has already been banned from one part of projectspace this month for refusing to drop things over a minor change. But, since he has asked me to revert this "inappropriate and immature closure", I will reopen it. -- Tamzin[cetacean needed] (she/they) 10:09, 12 May 2022 (UTC)
    Thank you for the Ad hominem. Venkat TL (talk) 10:46, 12 May 2022 (UTC)
  • Oppose Should be re-closed ASAP per WP:SNOW. The OP Venkat TL is under the impression that braces ( ) should be used in page titles only for strict disambiguation purposes. This is clearly nonsense; what we do now is perfectly sensible. The consensus here is already universally sceptical, and no way is it going to endorse this change. — Cheers, Steelpillow (Talk) 10:39, 12 May 2022 (UTC)
  • Oppose. Pointless change, no real benefits to the move have been put forward and moving policy documents that have been at their current location for ~20 years is going to be disruptive. The current set of titles follow a well defined pattern that makes them easy to search for and locate, using titles like Wikipedia:Indian constituencies (Naming conventions) would make it more difficult to find the various sub policies, and I don't see the benefit of the increased wordiness of the other proposed titles. It is claimed that these titles violate WP:Article titles, which they patently do not. As that page states in it's lead (complete with emphasis) This page explains in detail the considerations, or naming conventions, on which choices of article titles are based. This page does not detail titling for pages in other namespaces, such as categories. (talk) 11:48, 12 May 2022 (UTC)
  • Oppose After considering the proposed options, I still find the status quo page titles to be the most intuitive and navigable. DanCherek (talk) 11:57, 12 May 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

May is Hearing and Speech Month in CanadaEdit

My name is Leana Ilagan, I’m an Speech-Language Pathologist from the Philippines, and currently on a post-graduate study program in Canada.

I want to express my appreciation and gratitude to Wikipedia, as you served us all with resources as well as legitimate facts across the world as time stand and fly by, and for that we thank you.

Wikipedia is known as the most famous online encyclopedia globally, may I suggest for us to promote May as Speech and Hearing month, to give more awareness to our fellow nations and people around the world. This will be provide an opportunity to raise awareness about hearing and communication health. Moreover, it can give attention to the importance of early detection and intervention in the treatment of communication disorders and hearing impairments, as well as recognize the role of health-care professionals in providing life-altering treatment for people to overcome and/or manage them.

I highly encourage Wikipedia to add this event for the special events celebrated and recognized for the month of May.

Thank you! — Preceding unsigned comment added by (talk) 21:32, 11 May 2022 (UTC)

Wikipedia is not for promoting causes like that, no matter how worthy. Graham87 09:15, 12 May 2022 (UTC)
No, it is not for promoting such causes, but there is nothing to stop interested editors from improving relevant articles. I would urge the proposer to do so and encourage others to do so, whether in May or any other month. Phil Bridger (talk) 17:21, 12 May 2022 (UTC)
As a side-note. This is listed already under May#Month-long_observancesTheDJ (talkcontribs) 09:24, 12 May 2022 (UTC)

Merger of post-move cleanup guidesEdit

Recently, there was a discussion pointing out that the post-move cleanup guides need work. Wikipedia:Village_pump_(proposals)/Archive_189#Making_the_post-move_message_more_concise

I have merged the guides and placed the result on Wikipedia:Post-move cleanup. It would be fine to have some of you fellow Wikipedians to review it and edit it if you find something that can be improved. Utfor (talk) 19:50, 12 May 2022 (UTC)

Funny timing! I just spent the last couple hours working on a draft of the same thing. It's mostly written from scratch, because I think there are some major issues with the guidance currently at WP:MOVE and WP:RMCI:
  • They over-emphasize certain cleanup tasks that are rarely necessary (e.g. fixing double redirects)
  • They fail to mention certain tasks which are important, like updating the article prose (beyond just the first mention) and renaming subsidiary pages (including categories and related mainspace articles)
  • There's some organizational kludginess. A bunch of cleanup tasks are only required when there's a change to topic structure, and they should probably be grouped together for that reason. Something like "Fixing fair use rationales" can be subsumed by the more general step of "Fix mistargeted wikilinks".
I think v1 of my draft should be done today - then maybe we can compare notes and decide which pieces to take from where? Colin M (talk) 20:38, 12 May 2022 (UTC)
Okay, I think my draft is at v1.0. Some notes on sections from the earlier guides which I deliberately did not include:
  • "Fixing fair use rationales": This is subsumed by the broader task of fixing mistargeted wikilinks.
  • "Address any technical restrictions": This comes up very rarely, and when it does cause issues, they're pretty easy to spot. Seems like it's not worth the WP:CREEP cost? If this is a thing that matters, we should give an example.
  • "Fix double redirects": These are taken care of by bots. Nuff said.
  • "Categorizing redirects": I don't really see this as an aspect of post-move cleanup. (Also not exactly a high-priority task.)
  • "Update talk page notifications": No idea what this section is saying.
  • "Wikidata update": I just don't understand this step. Under what circumstances is it necessary, and what are the benefits? Maybe an example would help here?
  • "Categories and subcategories": No idea what this section is saying.
Colin M (talk) 21:29, 12 May 2022 (UTC)
I trust you fully; just make any changes you believe are improvements. Utfor (talk) 18:35, 13 May 2022 (UTC)
Okeydoke, for the sake of preserving history, rather than doing a cut-and-paste move, I've moved the merged old content you put together to userspace at User:Utfor/Merged postmove cleanup guidance and moved the version I started to Wikipedia:Cleaning up after a move. I'm going to go ahead and boldly update WP:MOVE and WP:RMCI with summary style links to this new page. Colin M (talk) 16:46, 14 May 2022 (UTC)

A Sonchus Competition?Edit

When I look at all of the Sonchus articles that have not been created, I feel like that something should be done to create all of the species in the Sonchus genus. What I think Wikipedia should do is either create a competition for the expansion or create a WikiProject for the Sonchus genus. I have already created Sonchus kirkii and Sonchus ustulatus but that is still not enough. 𝙷𝚎𝚕𝚕𝚘𝚑𝚎𝚊𝚛𝚝 (𝚃𝚊𝚕𝚔) 23:06, 12 May 2022 (UTC)

Have you tried asking for help at WP:TOL or any of the numerous subprojects? I don't know how active those are, but that would be the first place I would go for help. --Jayron32 18:03, 13 May 2022 (UTC)
  • I am not really sure that having a competition would be consistent with the goals of Wikipedia. YTKJ (talk) 18:26, 13 May 2022 (UTC)
    There are quite a few competitions on Wikipedia, such as the WP:Wikicup and WP:The Core Contest, which stimulate friendly competition. I wouldn't say that's against the goals of Wikipedia at all. That said, it is difficult to find participants for competitions around small topic areas, like Sonchus, and seeking collaboration within a Wikiproject will likely be more fruitful. Femke (talk) 09:17, 14 May 2022 (UTC)

Lots and lots and lots of hidden textEdit

Wikipedia has countless articles for which some text was added at some point, and then contested in some way not by being deleted, but by being hidden, often with a note (also hidden) explaining the reasoning for which the text was hidden (e.g., 'I don't think the source supports this' or 'this is off topic'). I find this to be a very bad practice, since this hidden text seems to be quickly forgotten about, and just stays on the page indefinitely. We also have metric tons of hidden links to deleted images, equally useless. I propose that we document all the pages that have blocks of text that were initially visible but were made hidden, and make a project of moving those from the articles to their talk pages for discussion. I think some of this can probably be done by a bot, but unfortunately only a small proportion, due to the potential for incorrectly moving appropriate uses of hidden text. However, it needs to be done, one way or another. BD2412 T 01:24, 14 May 2022 (UTC)

I agree that it's clearly bad practice just to hide questionable text. As i recall, i used to remove it and put it on the talk page for discussion if i questioned some sentence(s); at some point i stopped, but perhaps i'll start again. How can we document such pages and text, BD2412? Is there some auto- or semi-automated way? If so, i'll happily take some of this on. Happy days ~ LindsayHello 08:05, 14 May 2022 (UTC)
FYI here is a (somewhat slow) regex query that will give a random sample of mainspace articles with HTML comments. I checked 20 and counted 7 that seemed to contain removed text, with the other 13 being legitimate annotations/documentation. I don't see how any automated process could separate these two categories. Even if the content of the comment looks like wikitext, it might just be example syntax (you see this a lot in infoboxes - e.g. | closed_date = <!-- {{End date|YYYY|MM|DD|df=y}} -->). Colin M (talk) 15:54, 14 May 2022 (UTC)
I think some hidden text is useful in preventing certain good-faith edits that are a hindrance. As an example that I just came across, Alejandro Mayorkas has hidden text in the political party parameter of the infobox indicating that a source would be needed before people reflexively add the party of the president who nominated him. I do not understand why deleted images have been left in articles with hidden text, those should be removed. – Muboshgu (talk) 15:56, 14 May 2022 (UTC)
I would support a proposal that would take the hidden test to the talk page and annotate with sufficient details e.g. comment date, commenting editor. Ktin (talk) 19:18, 14 May 2022 (UTC)
I have some thoughts on these. First, I think the hidden text on removed images are there to remind people that there was an image there, and perhaps a new one could be added at that location, but I would be glad to see all of those messages flat-out deleted, and I think that could be done by a bot because they have a repeated format. Editors can see for themselves where an image would be useful in an article, and what good is the notice of removal after years have passed? As to the hidden text reflecting an editing dispute, that is more complicated, but I think that we can generate a list of most likely instances of text that should be removed. Something that has sat in the article for several years, is lengthier than typical example syntax, and contains Wiki links and formatting, would be a strong candidate to check first. BD2412 T 19:39, 14 May 2022 (UTC)
A related anti-pattern is the unterminated or incorrectly terminated comment. This is picked up by report 5 in WP:WikiProject Check Wikipedia/List of errors, which currently lists 600 offenders. It does pick up the case when correctly terminated comments follow later, e.g. <!-- Badly terminated comment > Smith is an [[actor]] who did some [[film]]s. <!-- Valid comment -->, which quietly hides the intervening wikitext. Certes (talk) 19:56, 14 May 2022 (UTC)
Yes, I think we need to go after all of these issues. BD2412 T 23:51, 14 May 2022 (UTC)

Wikipedia requires a subject indexEdit

Years of experience as a reader of this wikipedia lead me to notice that the category system cannot replace the efficiency of a subject index.

Every time there is a need to search for a topic of minor consideration or whose article has not yet been written, the reader must search within countless articles and categories both related and very collateral to the topic to be investigated, the typical case of unnecessary lateral thinking.

A general thematic index system and by categories could complement the current system of categories and articles in the event that the topic to be investigated does not meet the corpus of text or the necessary relevance to have its own article, in addition to being able to link individual paragraphs. and sections within articles that cover a different topic than the topic they mention.

The new system could link both categories, complete articles, sections or even individual paragraphs, the creation of these entries can be given directly as an addition to the edition summary with similar requirements to the creation of articles.

Perhaps what I'm proposing already exists in a way that I hadn't thought of, but the closest thing I can think of is the internal search, which doesn't perform this task.

As for the operating system, one could go to an alphabetical page where the different topics are described and these in turn contain content links. It could also be searched by categories of thematic indexes. — Preceding unsigned comment added by Diosverde (talkcontribs) 20:36, 14 May 2022 (UTC)

I think that's what WP:OUTLINES were intended to help with, but I don't see them used much. Schazjmd (talk) 20:45, 14 May 2022 (UTC)
Er, I think that Portals were intended for this, but... --Redrose64 🌹 (talk) 21:23, 14 May 2022 (UTC)
Wikipedia:Contents/Portals is a partial subject index, though the inclusion criterion is portals surviving its MfD rather than topic importance. Certes (talk) 22:00, 14 May 2022 (UTC)
Would a subject index be any better than Google? Elemimele (talk) 16:29, 15 May 2022 (UTC)
Our current categorization system is definitely lacking. See also Wikipedia:Category intersection. Mz7 (talk) 18:51, 15 May 2022 (UTC)

A lot of these traditional approaches (categories, indexes, portals) had the problem that you had to discern the mentality/organization of the system (including what "lens" was used for navigation/ classification) to use them but were the only thing available. The advent of google type searches or Wikipedia's own search bar do not have that issue and IMO have rendered those imo older methods obsolete. North8000 (talk) 23:01, 15 May 2022 (UTC)

Automatic Semi-Protection of In The News articlesEdit

I have noticed a drastically sharp increase of vandalism on articles when they get added to "In the News". My suggestion is to automatically semi-protect these articles for a period of time, Likely about 30 days, That or Review Edit Protection to allow people to still contribute to the articles, but in a safer matter, again for about 30 days. PerryPerryD Talk To Me 14:44, 16 May 2022 (UTC)

PerryPerryD Have you discussed this with those at ITN, say WT:ITN? 331dot (talk) 14:57, 16 May 2022 (UTC)
I have not, Thanks for the advice, I'll go do that immedietly PerryPerryD Talk To Me 14:59, 16 May 2022 (UTC)

Adding own talk contribs to "vandal" templateEdit

Hello! I'd like to propose adding a "own talk contribs" link to {{vandal}}. This is helpful for tracking potential vandals, as they often post non-policy-compliant messages on their talk page. I have a draft implementation in the sandbox here; see the diff. An example of what the revised template would look like is below. Pinging @Suffusion of Yellow as I vaguely remember them requesting this, but can't find the post anymore. Cheers!

EpicPupper (talk • contribs • deleted contribs • nuke contribs • logs • filter log • block user • block log • own talk contribs)

(The above is a usage example of the revised template.) 🐶 EpicPupper (he/him | talk) 15:14, 18 May 2022 (UTC)

The one place this template is non-optional, at least that I can think of, is AIV. For other occasions there's a whole load of other templates you can use (see Template:Userspace linking templates). You could also make up your own or get this linked from Template:User-multi. Sometimes this link may be useful, but as someone who looks at AIV reports, I would not find this a useful regular addition. Admins are already checking contribs and talk page histories. On the rare occasions something is obscured for whatever reason, an explanatory note would help identify the problem quicker than a link. YMMV. -- zzuuzz (talk) 15:55, 18 May 2022 (UTC)