Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
"WP:PROPOSE" redirects here. For propose for deletion page, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

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 style[edit]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
Very short and easy answer - no they can't. Gonnym (talk) 07:55, 1 May 2022 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      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)[reply]
      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)[reply]

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

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

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

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

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
there is a discussion here...and many are saying 'the MOS' does not need to apply. GiantSnowman 08:31, 2 May 2022 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    this is a fair point about accessibility - but what about '2002–pres.'? GiantSnowman 17:51, 5 May 2022 (UTC)[reply]
    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)[reply]
    An excellent idea. MichaelMaggs (talk) 10:54, 6 May 2022 (UTC)[reply]
    @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)[reply]
    @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)[reply]
    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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
Agree with it being removed or amended. GiantSnowman 20:15, 2 May 2022 (UTC)[reply]
  • 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)[reply]
    FYI it's multiple WikiProjects that 'ignore' it, not just one... GiantSnowman 20:16, 2 May 2022 (UTC)[reply]
    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)[reply]
    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)[reply]
    Unfortunately, there is no rationale provided for the change either. Hawkeye7 (discuss) 06:04, 5 May 2022 (UTC)[reply]

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

  • 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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    • 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)[reply]
      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)[reply]
      • 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)[reply]
        Some of us (me) have attempted to amend the MOS to reflect this - and been reverted. GiantSnowman 11:42, 3 May 2022 (UTC)[reply]
        @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)[reply]
        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)[reply]
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)[reply]
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)[reply]

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

  • 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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    We kinda already are! GiantSnowman 16:16, 3 May 2022 (UTC)[reply]
    To put it in simple terms for you, what links the two is WP:OWNERSHIP. – Joe (talk) 07:27, 4 May 2022 (UTC)[reply]
    Useful contributions only please. GiantSnowman 18:07, 4 May 2022 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    yes, this seems like a fantastic compromise. GiantSnowman 10:39, 6 May 2022 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    (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)[reply]

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

  • 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)[reply]
    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)[reply]
    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)[reply]
    Still shows that it is barely used. GiantSnowman 21:02, 16 May 2022 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 (talk • contribs) 19:31, 9 May 2022 (UTC)[reply]
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)[reply]
Further on the history discussed above: as noted, the 15 February 2016 edit that added this provision to the MOS did not state any rationale for it (it was added along with some uncontroversial changes that were carefully explained in the edit summary). There was a contemporaneous discussion, but it didn't yield anything remotely close to a consensus. Especially strangely, on 2 March 2016, the same editor who added the DATETOPRES provision stated that they "violently agree that Francis's summary of the problems with 'present' is correct (as far as it goes; there are others). Just the fact that lots of people do it doesn't make it a good idea." So unless I'm profoundly misreading that exchange, it appears that even the editor who added the DATETOPRES language did not, on reflection, agree with it. In any event, given that there was never even a local consensus among MOS regulars for this change -- a change that would only have been noticed by someone carefully watching every revision to the page -- I think it should clearly be removed. -- Visviva (talk) 02:35, 22 May 2022 (UTC)[reply]
Agreed. GiantSnowman 18:12, 24 May 2022 (UTC)[reply]

RfC: Bot to blank old IP talkpages[edit]

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

Background

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: [1], [2], [3] —ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 08:22, 11 May 2022 (UTC)[reply]

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose Not worth it, especially given that IP masking is happening soon. * Pppery * it has begun... 18:13, 13 May 2022 (UTC)[reply]
    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)[reply]
  • Support - seems a reasonable approach and looks like it's being handled sensibly. Andrew Gray (talk) 17:43, 14 May 2022 (UTC)[reply]
  • 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 • {C•X}) 18:08, 14 May 2022 (UTC)[reply]
  • 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)[reply]
  • Neutral I guess. Is this an actual problem, or a solution in search of a problem? I personally haven't experienced this as a problem for me. Maybe it's OK to see that there've been vandal warnings going back ten years, as this could indicate that it's like a static IP for a school, if being aware of that even matters... which probably not. I suppose it's more just clutter, and cleaning up clutter is OK too. Not important IMO, but perfectly OK to do if desired. Herostratus (talk) 22:29, 23 May 2022 (UTC)[reply]

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

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

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

But when... were IP addresses going away altogether?—Bagumba (talk) 11:58, 31 May 2022 (UTC)[reply]

Lots and lots and lots of hidden text[edit]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Yes, I think we need to go after all of these issues. BD2412 T 23:51, 14 May 2022 (UTC)[reply]
Yeah I agree with OP's points. My one caveat is that I personally have not seen this, at least not very much. That's just me tho. Yes move to talk page is correct fix IMO. Support a well-written bot or whatever else would help. Herostratus (talk) 22:24, 23 May 2022 (UTC)[reply]
I just found this example today. The text in this case is a reference that purportedly has a broken link, which was hidden with a note saying that the link appears to broken. This hidden text had been sitting in the article for nine years (until today). I probably see more of this than the average editor because I sweep for ref tag errors, which include those in hidden text. BD2412 T 23:47, 27 May 2022 (UTC)[reply]
I don't recall having moved article text into html comments in recent years, but I don't see a reason why this should be considered a bad practice. After all, when you simply remove text, you're effectively hiding it in the page history, and when you move it to the talk page, you're hiding it from view of anyone except those looking at the talk. In fact, putting that text in an html comment makes it more visible to editors who engage with the relevant bits of the article. I don't think there's a need for any project here, and moving text out of (or into) html comments is best left to the regular, article-specific, editorial activity. – Uanfala (talk) 11:37, 31 May 2022 (UTC)[reply]
If there is an issue with the text, it should be brought up in the talk page, not hidden in the article itself where no one will notice unless they edit the same exact section. This is extremely bad practice. Gonnym (talk) 11:53, 31 May 2022 (UTC)[reply]
It seems that what you refer to as "extremely bad practice" is an instance of good targeting: a commented out passage will always reach the people it's aimed at: those editing the relevant section, whereas a talk page post may initially be better visible to a larger audience, but has less chance of getting noticed by the people it's intended for (I don't think many of us have the habit of systematically scouring the talk page and its archives before making an edit to an article). – Uanfala (talk) 12:21, 31 May 2022 (UTC)[reply]
The article is not a place to discuss anything. If you comment text out, what will the next person do? Reply there? If you have concerns, bring it up in the talk page. Gonnym (talk) 12:26, 31 May 2022 (UTC)[reply]
Of course that's not the place for threaded discussions. But if you use an html comment, you're not starting such a discussion: you're just flagging up an issue and leaving interested others the opportunity to resolve it (by e.g. uncommenting and correcting, or removing altogether). I'm not saying this is the best method, but it certainly has its uses. If we're going to start bulk moving commented out text to the talk page, the net result will be the substitution of one (at worst) small problem with another (likely bigger) one. – Uanfala (talk) 12:35, 31 May 2022 (UTC)[reply]

Adding own talk contribs to "vandal" template[edit]

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.

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

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)[reply]
Yeah I don't think this would really be useful, since contribs includes contribs to user talk and vandal contribs are usually pretty short. Galobtter (pingó mió) 22:53, 18 May 2022 (UTC)[reply]
Like the others, I see this as having limited utility to me as an admin, or really to anyone. I can see own user talk edits easily in the contribs list. Pulling them out on their own is certainly a thing we can do, but why really? --Jayron32 15:48, 20 May 2022 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Bot-compiled lists of links to wikt:[edit]

When we do not have an article about the primary meaning of a term, we sometimes have a disambiguation page for the term instead. Before an article about the primary meaning was craeted, for example, moonrise was a dab page. It is now moved to moonrise (disambiguation), and the moonrise entry is redirected to moonrise and moonset. When editors wanted to link to moonrise, linking to the dab page is discouraged, so linking to wikt:moonrise is an alternative. But after the primary meaning is covered by an article, we need to retarget those links to point to Wikipedia, not Wiktionary. What about creating a regularly updated bot-compiled list? Human editors may then only need to fix the links manually, not track them down.

Specifically: A bot would look for [[wikt:$1]] in articles, and if [[$1]] exists and is not a dab page or a redirect to a dab page, then the bot adds [[$1]] to the list. ($1 here represents a wildcard.) Utfor (talk) 19:56, 24 May 2022 (UTC)[reply]

Some of these links could be deliberate and still be appropriate even if an article exists. —Kusma (talk) 13:29, 28 May 2022 (UTC)[reply]
Thank you for the efforts and the feedback! User:Certes: It seems like use of Template:Wiktionary also is listed, e.g. in A.C. Milan. User:Kusma: Thank you for pointing out a useful fact. Utfor (talk) 18:31, 28 May 2022 (UTC)[reply]
@Utfor: Yes, the query lists all links to Wiktionary, even if the [[wikt:?]] text is within a template rather than explicitly in the article. A. C. Milan already links to Milan, so the link (via template) to wikt:Milan doesn't add much and could be removed. Certes (talk) 22:37, 28 May 2022 (UTC)[reply]
@Certes, you might want to remove disambiguation pages, which often link to Wiktionary correctly. ― Qwerfjkltalk 10:07, 29 May 2022 (UTC)[reply]
@Qwerfjkl: Good idea. That reduces the count from 12862 to 7900. I've also removed cases where the Wiktionary entry matches the linking page or a redirect to it. Beware that some Wikipedia articles are about a different topic to the similarly named Wiktionary link. For example, 187 (slang) links to wikt:187 which defines the slang term, whereas 187 in Wikipedia is about a year. Certes (talk) 13:28, 29 May 2022 (UTC)[reply]

Enabling the New Topic Tool by default[edit]

Screenshot of the new topic tool

Should the new topic tool be enabled by default on English Wikipedia? {{u|Sdkb}} talk 21:33, 27 May 2022 (UTC)[reply]

Background[edit]

The WMF's editing team has been developing tools that aim to improve the functionality of talk pages for both newcomers and experienced editors under the umbrella of the talk pages project. A few months ago, we enabled their reply tool by default. The new topic tool is a similar tool for starting new sections on talk pages; you can preview it by clicking here and choosing "Add topic" at upper right, next to the history tab.

The editing team has informed us In light of the recent A/B test results showing the positive impact of the New Topic Tool, the Editing Team is in support of enabling it by default at all projects, and has done so on 20 other projects, with it available here as a beta feature that can be turned on in your preferences. This RfC asks whether it should be enabled as a default-on feature, but with an opt-out option available to all logged-in editors in their preferences.

Survey (New Topic Tool)[edit]

  • Yes. This tool is the logical complement to the reply tool, which we have been using very successfully for several months. It makes starting discussions easier for both newcomers (vital for our future) and experienced editors (essential for our present). The ease of opting out (both fully in your preferences, and on a case-by-case basis by just editing in source if you need to) limits the potential for harm. We've already been using it successfully at the Teahouse since March. It's not at 100% perfect functionality quite yet, but it's close, and it's certainly much better than the status quo. Enabling it now rather than once development is fully complete will provide us with a more meaningful window to give the developers feedback that they'll be able to address before they wrap up their initial development work. {{u|Sdkb}} talk 21:33, 27 May 2022 (UTC)[reply]
  • Sure, why not. If it helps less-experienced users participate more (as the A/B results suggest), then that's probably worthwhile. Judging from Wikipedia:Talk pages project#Starting a new discussion, the big differences are the live preview (useful!) and the automatic signature (useful if "hyphen-hypen-space-tilde-tilde-tilde-tilde" hasn't already been permanently burned into your brain). Beyond that, the UX doesn't seem wildly different from the existing "+" setup, so there doesn't seem to be much to object to. -- Visviva (talk) 23:36, 27 May 2022 (UTC)[reply]
  • Yes. A/B tests show positive benefit, it's fairly easy to enable, and helps new contributors. 🐶 EpicPupper (he/him | talk) 01:56, 28 May 2022 (UTC)[reply]
  • OOjs UI icon add-constructive.svg Support, makes sense after the reply tool. ― Qwerfjkltalk 07:18, 28 May 2022 (UTC)[reply]
  • Strong support I think it's a great and simple-to-learn tool. — Ixtal ( T / C ) ⁂ Join WP:FINANCE! 11:27, 28 May 2022 (UTC)[reply]
  • Support There are bunch of userscripts that help to do the same though. AXONOV (talk) ⚑ 13:28, 28 May 2022 (UTC)[reply]
  • Support An improvement over the raw wikitext form. – SD0001 (talk) 16:41, 28 May 2022 (UTC)[reply]
  • Support I've found it to be an excellent counterpart to the reply tool. Sideswipe9th (talk) 15:25, 29 May 2022 (UTC)[reply]
  • Support Nice improvement. MichaelMaggs (talk) 17:15, 30 May 2022 (UTC)[reply]

Discussion (New Topic Tool)[edit]

Courtesy pings: PPelberg (WMF), Whatamidoing (WMF). Notified: WT:Usability, WT:Talk pages project. {{u|Sdkb}} talk 21:33, 27 May 2022 (UTC)[reply]

hi y'all – on the topic of, "How will people who prefer the existing section = new workflow be able to turn off the New Topic Tool?"...
In addition to what @Sdkb mentioned above about you being able to disable the New Topic Tool within Special:Preferences, the tool offers peoples the ability to switch back to the existing section = new experience from directly within the tool as pictured here:
New Discussion Tool Hint.png
PPelberg (WMF) (talk) 02:04, 28 May 2022 (UTC)[reply]

Please see this.[4] "What's going on with the times here? Bakkster Man posts at 12:29 am, Today (UTC+1) with many diffs. Next, in line, (visually) a post by Gimiv 8:40 pm, Yesterday (UTC+1) complaining about a report with no diffs. Last, a post by RandomCanadian at 11:50 pm, Yesterday (UTC+1).[reply] Why are times skipping around...23:29, 27 May 2022 (UTC), next 8:40 pm, Yesterday (UTC+1), next 11:50 pm, Yesterday (UTC+1). I have no connection with any of these editors, but it's very confusing, shouldn't our "software" organize this chronologically? Seems to make editors look as if they haven't read, or are mis-replying to posts." — Preceding unsigned comment added by Doug Weller (talk • contribs) 12:17, 28 May 2022 (UTC)[reply]

I don't understand what you mean. That is not what I am seeing in that link; there isn't even a comment by Bakkster Man, and that is not how the timestamps look like for me. Can you include a screenshot of what you're seeing, and clarify what the problems are? (You can upload it to https://phabricator.wikimedia.org/file/upload/ if you don't want to clutter up Wikipedia.) Here's what the page looks like for me, and I don't see anything wrong: https://phabricator.wikimedia.org/F35185664. Matma Rex talk 21:43, 28 May 2022 (UTC)[reply]
@Matma Rex please take a look at the whole thread.[5]. You've pointed to an earlier version. I can't fit it into a screen shot. Doug Weller talk 15:14, 29 May 2022 (UTC)[reply]
Oh, actually you linked to an earlier version, that's why I also looked at the earlier version. I thought that was intentional.
I am also still confused by the weird timestamps, I guess you're using some gadget to display them in your timezone and in different format? If it's showing some of them as "(UTC)" and others as "(UTC+1)", then that must be a bug in that tool. I have no idea what tool it is (it'd be slightly easier to guess if you shared a screnshot). You might find pages easier to read if you disable it, if that happens often.
The non-chronological order is expected for me. As far as I know, only replies at the same indentation level are supposed to be in chronological order. When you reply with deeper indentation to a comment earlier in the discussion, by necessity the result can't be chronological (unless you put your reply at the bottom of the thread, instead of making it a directly reply). I found a good example of this in the documentation pages: Wikipedia:Indentation#Indentation examples (admittedly it took me a while to find it). Matma Rex talk 18:56, 30 May 2022 (UTC)[reply]

Medon[edit]

Medon needs a disambiguation page. The existing page is about mythology. Should it be transformed into a disambiguation page or should we start a new page ? --Io Herodotus (talk) 05:36, 29 May 2022 (UTC)[reply]

Edit summary field - make drop down[edit]

I've had a quick look at archives and can't see that this has been discussed? The Edit summary field (described elsewhere as a "text box, not a drop down box") is annoying as the text scrolls sideways, hence some is 'invisible'. With the advent of 1,000 character summaries, could this usefully be made to drop-down, to show multiple-lines, perhaps with a side scroll bar?--Rocknrollmancer (talk) 20:11, 29 May 2022 (UTC)[reply]

[edit]

All wikis under the CC-BY-SA license have its logo at the bottom. I think the WMF needs to add it to the bottom next to the WMF logo. TOPaner (talk) 10:19, 31 May 2022 (UTC)[reply]

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