Can projects ignore manuals of style
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)
- 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)
- 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)
- 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)
- 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)
- 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)
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)
- 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)
- @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)
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
. Whileoccasional 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)
- 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)
- 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)
- 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)
- 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)
- @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)
- @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)
- An excellent idea. MichaelMaggs (talk) 10:54, 6 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)
- @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):
- 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)
- 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:
- According to the OED, "pres." is an abbreviation for "president" not present. The suggested usage is therefore not standard English.
- 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.
- The discussion above indicates that it lacks consensus
- WP:CREEP
- 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)
- FYI it's multiple WikiProjects that 'ignore' it, not just one... GiantSnowman 20:16, 2 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)
- 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)
- 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)
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)
- 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)
- To put it in simple terms for you, what links the two is WP:OWNERSHIP. – Joe (talk) 07:27, 4 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)
- 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)
- 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)
- 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'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)
- 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)
- 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)
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)
- Very few of them are "
- 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)
- 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)
- 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)
- 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)
- Agreed. GiantSnowman 18:12, 24 May 2022 (UTC)
- I went ahead and changed the advice from "write 2001–present" to "write 2001–present (as of 2022)". I didn't change the advice to use just "pres." in space-constrained cases, as I don't know how that should be handled. Herostratus (talk) 03:28, 3 June 2022 (UTC)
- Agreed. GiantSnowman 18:12, 24 May 2022 (UTC)
"Fix" Wikipedia Adventure by adding buttons to progress in "click on edit button" steps
- 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.
After some updates, the Wikipedia Adventure can no longer progress after clicking on the edit button. While I don't know about the hooks of the guided tour, I know that we could easily add buttons that say "Clicked!" to have the tour progress itself instead of waiting for an event that never comes. Aaron Liu (talk) 06:27, 4 June 2022 (UTC)
Edit summary field - make drop down
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)
- @Rocknrollmancer: edit summary should be limited to 500 characters still; just checking though - seems like you don't want a "drop down" type of control, but you want the input box to be taller with wrap-around text (a la phab:T6716)? — xaosflux Talk 14:22, 31 May 2022 (UTC)
- Yes, that's what I tried to imply Xaosflux; it could show perhaps three lines at any time with auto word-wrap. I've had this (difficulty) with (off-Wiki) feedback webforms showing only part of the message, Eon energy being recent (actually contracted-out to a metrics analysis specialist), when I anticipated that it was single-line only, so composed it into a draft webmail field then pasted in, although there was no character count down, so I was guessing. That's what prompted this post. Thanks. Rocknrollmancer (talk) 16:46, 31 May 2022 (UTC)
- @Rocknrollmancer: thanks for confirming, looks like this is something that would have to be fixed upstream in mediawiki software, not something we can do here on the English Wikipedia. There is a task (phab:T6716 that has been open for a very long time to change the from an input box to a textarea box that would support either a scroll bar or text wrapping. You can comment on T6716 directly. — xaosflux Talk 18:33, 31 May 2022 (UTC)
- @Rocknrollmancer: Enable a gadget in your preferences to show some common summaries. TSOPar (talk) 17:20, 5 June 2022 (UTC)
- @Rocknrollmancer: thanks for confirming, looks like this is something that would have to be fixed upstream in mediawiki software, not something we can do here on the English Wikipedia. There is a task (phab:T6716 that has been open for a very long time to change the from an input box to a textarea box that would support either a scroll bar or text wrapping. You can comment on T6716 directly. — xaosflux Talk 18:33, 31 May 2022 (UTC)
- Yes, that's what I tried to imply Xaosflux; it could show perhaps three lines at any time with auto word-wrap. I've had this (difficulty) with (off-Wiki) feedback webforms showing only part of the message, Eon energy being recent (actually contracted-out to a metrics analysis specialist), when I anticipated that it was single-line only, so composed it into a draft webmail field then pasted in, although there was no character count down, so I was guessing. That's what prompted this post. Thanks. Rocknrollmancer (talk) 16:46, 31 May 2022 (UTC)
Proposal: Change the Wikipedia logo to rainbow colors for LGBT Pride Month
WP:SNOW. (non-admin closure) 🐶 EpicPupper (he/him | talk) 23:02, 8 June 2022 (UTC) |
- The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Many websites are adding rainbow colors to their website. I think Wikipedia should as well. Not sure what a logo would look like, but worth discussing. Interstellarity (talk) 00:40, 8 June 2022 (UTC)
- Pride Month is celebrated at different times in different countries. AndyTheGrump (talk) 00:44, 8 June 2022 (UTC)
- Oppose per AndyTheGrump, and also m:Logo#Temporary logo variants and this Phabricator ticket. 🐶 EpicPupper (he/him | talk) 01:04, 8 June 2022 (UTC)
- Note that these links don't ban the practice of celebratory logos, they ban the practice of celebratory logos using local CSS.
- No general comment on the proposal. Izno (talk) 01:46, 8 June 2022 (UTC)
- Yes, they don't ban the practice of celebratory logos, they strongly recommend against the practice of celebratory logos for holidays. 🐶 EpicPupper (he/him | talk) 01:59, 8 June 2022 (UTC)
- Oppose this well-intentioned idea, because every month is Think Of Us Month for some cause or other, many of them equally worthy. To be fair, we'd give each of them equal prominence – impossible in the year with only 12 months – and would never show our "normal" logo. It is better to feature related articles, pictures, etc. via the main page selections. Certes (talk) 11:32, 8 June 2022 (UTC)
- Oppose I'm not in support of this as it isn't "about Wikipedia", and doesn't apply to all of our readers. While WMF is headquartered in the US, our readers are world-wide and this is a US-specific awareness event. — xaosflux Talk 12:47, 8 June 2022 (UTC)
- Possible option - if there is a special editing drive for the locality (like a "Edit-a-thon for improving articles on United States LGBT Scientists") a geo-notice might do. — xaosflux Talk 12:51, 8 June 2022 (UTC)
- Oppose Beyond the event, too US/Western centric in every respect. North8000 (talk) 12:50, 8 June 2022 (UTC)
- Oppose Wikipedia is not for promotion of anything, regardless of the cause/event. Hog Farm Talk 16:49, 8 June 2022 (UTC)
- I remember seeing a similar proposal recently for "official" recognition of another awareness/pride week/month, and think the same of this one. Interested people are welcome to have a drive to improve articles related to the subject at this time or any other time of year, but it should not come with any official imprimatur. Phil Bridger (talk) 18:55, 8 June 2022 (UTC)
- It was this. Phil Bridger (talk) 19:02, 8 June 2022 (UTC)
- Oppose. The only time it is appropriate for Wikipedia to collectively endorse any cause is when that cause pertains to our ability to build an encyclopedia (e.g. things about copyright or freedom of speech). As wonderful a cause as Pride is, it does not pass that bar. Editors can of course still show their individual support for Pride on their userpages and in their signatures. -- Tamzin[cetacean needed] (she/they) 20:48, 8 June 2022 (UTC)
- Yes, they can obviously show their support there, but such support is pretty empty unless they also work on improving related Wikipedia articles. Phil Bridger (talk) 21:40, 8 June 2022 (UTC)
- Oppose As pointed out, a promotion of a US-centric cause that is unrelated to Wikipedia and would open us to endless promotion of various deserving causes. Meters (talk) 21:47, 8 June 2022 (UTC)
Substitute int: messages
The {{int:filedesc}}
and {{int:license-header}}
belong on Commons which is a interlanguage wiki. I claim that they don't belong here on enwiki and requested they be substituted at WP:BOTREQ#Substitute messages but @Novem Linguae: wanted consensus so I post it here to get it.Jonteemil (talk) 16:03, 8 June 2022 (UTC)
- Yeap, just double checking. Any objections to subst-ing all these with a bot? There will be about 4000 pages affected in the File namespace. If no objections I will file a BRFA shortly. Thanks. –Novem Linguae (talk) 18:38, 8 June 2022 (UTC)
- No way. The
{{int:...}}
markup is a means for obtaining messages from the MediaWiki: namespace that are adjusted for the reader's language preference (int = internationalised). If you have never altered your language pref,{{int:filedesc}}
emits MediaWiki:Filedesc; if you have it set to de -Deutsch, you will see MediaWiki:Filedesc/de, and so on. Since it is dependent upon the reader's pref setting, any bot run will enforce the language setting of the bot. Why is this not at WP:VPR, anyway? --Redrose64 🌹 (talk) 19:41, 8 June 2022 (UTC)- Moved. –Novem Linguae (talk) 20:04, 8 June 2022 (UTC)
- I'm sorry, but I'd like to note that this is the English Wikipedia, not a multi-lingual wiki like Wikimedia Commons or Meta. 🐶 EpicPupper (he/him | talk) 20:24, 8 June 2022 (UTC)
- Sure, content and discussions should be in English, but that doesn't mean editors must use an English-language interface to edit English Wikipedia. isaacl (talk) 20:54, 8 June 2022 (UTC)
- We generally expect content in wikitext to be in English. I don't think any multi-language users should have any expectation that File space acts differently. Izno (talk) 21:43, 8 June 2022 (UTC)
- I agree that it wouldn't be in the minimal set of necessary features, and that users speaking other languages shouldn't expect it to be. Nonetheless, providing internationalization hooks and localization into other languages is a welcoming feature to offer, particularly for English Wikipedia which has a lot of editors that are non-native English speakers. isaacl (talk) 22:59, 8 June 2022 (UTC)
- We generally expect content in wikitext to be in English. I don't think any multi-language users should have any expectation that File space acts differently. Izno (talk) 21:43, 8 June 2022 (UTC)
- Sure, content and discussions should be in English, but that doesn't mean editors must use an English-language interface to edit English Wikipedia. isaacl (talk) 20:54, 8 June 2022 (UTC)
- On occasion, I post messages with an {{int}}-based invitation to read it in another language (
More languages
), and an invitation to translate it into another language (Please help translate to other languages.
). Ideally, these should show in the user's interface language (see in practice). The presumption is that there are users who may be more familiar with languages other than English. Does this proposal concern just the two mentioned examples, or all usages of int? Xeno (WMF) (talk) 23:19, 8 June 2022 (UTC) - If ain't broke, don't fix it. To the best of my understanding, the existence of
{{int: }}
messages isn't causing any harm, so no need to remove them. If there is a harm being done, I'm open to the idea of removing them. —CX Zoom[he/him] (let's talk • {C•X}) 08:10, 10 June 2022 (UTC) - Doesn't seem like this an issue, and is actually marginally helpful for readers with their interface languages set to anything other than English? — xaosflux Talk 10:06, 10 June 2022 (UTC)
- Oppose, has potential uses for people from other language Wikipedias looking at our images who can figure out more easily whether they are appropriate for re-use elsewhere. No actual harm has been demonstrated (bugs in bots should be fixed in their source code, not worked around in the whole wiki). —Kusma (talk) 11:16, 10 June 2022 (UTC)
RfC: Bot to blank old IP talkpages
- The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
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)
- 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)
Survey (iptalk blanker bot)
- 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 • {C•X}) 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)
- 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)
Discussion (iptalk blanker bot)
- 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)
- 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
- My preference for using a transcluded template is that if we have to change something due to future software changes (say the
- 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)
- @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)
- 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)
- 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)
- 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)
But when... were IP addresses going away altogether?—Bagumba (talk) 11:58, 31 May 2022 (UTC)
- Won't the changeover to masked IP addresses make this task obsolete? Not sure it's worth it to edit millions of pages if the problem will be going away shortly. –Novem Linguae (talk) 10:18, 2 June 2022 (UTC)
- It will not be going away shortly. Beta testing for IP masking has only just begun since last week. Other large scale WMF initiavites like Reply links took 1 year to go from beta testing to full roll out. IP masking is a much more drastic change and will surely take much longer for full implementation. As discussed above, there are other benefits from this task, namely uncluttering WhatLinksHere and reducing Lint errors backlog, that will relevant post IP masking. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 11:37, 2 June 2022 (UTC)
Numbering system of archives
![](https://web.archive.org/web/20220704211207im_/https://upload.wikimedia.org/wikipedia/commons/thumb/e/ea/Purple_arrow_down.svg/20px-Purple_arrow_down.svg.png)
On May 14, I created a template protected edit request at Template talk:Archives, which would allow specifying the starting number for archives, including /Archive 0. The request was applied after two hours by User:Terasail.
On June 3 I opened another one, this time at Template talk:Talk header. Although the first request was fulfilled, this one was met with a lot more discussion regarding the appropriateness of /Archive 0 and whether or not the edit that would allow such a use should be applied. I believe a continuation of such discussion should continue into a more centralized discussion, since it was suggested that the consensus was to not make the edit at {{Talk header}}, and not whether a user should be able to number their archive as such.
In my opinion, I believe it is a reasonable request to allow /Archive 0, but the previous discussion at {{Talk header}} has also pointed out that starting from 0 can be confusing, unintuitive, and illogical. I totally agree that article talks should never have archives starting from zero, however,
Should we forbid numbering an archive as /Archive 0 in userspace?
- Yes.
- No, but the templates should not support them at all.
- No, but {{Talk header}} should not support it. {{Archives}} is fine.
- No, and the templates should support this use.
Pinging users at the previous discussion: @Paine Ellsworth, FlightTime, Bsherr, Mathglot, Shibbolethink, and Sdkb 0xDeadbeef 10:32, 9 June 2022 (UTC)
- 1, it can be confusing. 🐶 EpicPupper (he/him | talk) 21:24, 9 June 2022 (UTC)
3: I don't think that it should be forbidden to start archiving from 0 in userspace (Other namespaces should start at 1), if you ask me you can count how you like in userspace. I added it to {{Archives}} since it seemed reasonable to me and it is a supported feature for {{Archive list}}. Indexing from 0 is pretty standard for computing and it didn't really raise any concern for me. {{Archives}} and {{Talk header}} serve different purposes and while {{Talk header}} is less appropriate for user talk, {{Archives}} is perfectly appropriate and the template itself is designed to offer the most customizability and I think it should be kept with the option to set it to a custom value while it is probably best to not add it as a feature to {{Talk header}} Terasail[✉️] 11:40, 9 June 2022 (UTC)
- Is this not more for VPR/VPP than technical though? Terasail[✉️] 11:49, 9 June 2022 (UTC)
- I'm not sure. Feel free to move it. 0xDeadbeef 11:52, 9 June 2022 (UTC)
- Did you mean {{Talk header}}? 0xDeadbeef 11:53, 9 June 2022 (UTC)
- 4: I can see some reasonable use cases for "/Archive 0" and that in all talk namespaces. Sometimes I find an extant talk page with years old topics that no one responds to, that could've been much better dealt with at a parent talk page. So "let's redirect it to the parent talk page" is an obvious belief. But where do the existing topics go? One could just aggregate them all to "/Archive 0" of the parent talk page, if the parent talk page has already gotten an "/Archive 1" of its own. —CX Zoom[he/him] (let's talk • {C•X}) 13:37, 9 June 2022 (UTC)
- Further, specifying a starting number like "Archive 2020" is okay too (in user talk namespaces), considering that people like me like categorising topics according to year. But maybe we're only discussing about "Archive 0" thing? —CX Zoom[he/him] (let's talk • {C•X}) 13:42, 9 June 2022 (UTC)
- 3. In my recent work with article talk pages I found that there were a few valid applications for a 0th archive. There were a few instances where a merge of two articles resulted in editors creating an "/Archive 0", or archives that were "0.1, 0.2, 0.3" and so on, so as to accomodate the discussions on the merged article's talk page. However, imho these limited applications were very few and far between. Since the Talk header template is widely used on article talk pages, but used far less on user talk pages, #3, which allows editors to use the Archives template with the
|start=0
parameter, is sufficient. And there is also the ability to fork the Talk header template onto a user talk subpage, add the 0th archive facility and then transclude the subpage to one's user talk page. Just a thought. P.I. Ellsworth , ed. put'r there 14:45, 9 June 2022 (UTC)- @Paine Ellsworth, may I propose allowing setting the parameter only in the "User talk" namespace? We could detect if someone is using the parameter and error out when used in other namespaces. 0xDeadbeef 07:30, 11 June 2022 (UTC)
- That's a good question. I know that sensors can differentiate among namespaces like mainspace and userspace, however I'm not sure that they can differentiate one talk space from another. If they can, then I don't see why it couldn't work. Are you averse to putting the Talk header template on one of your user subpages and making it work that way? P.I. Ellsworth , ed. put'r there 08:15, 11 June 2022 (UTC)
- Maintaining a separate template creates too much burden. I don't intend to have a copy in my user subpage if it can be avoided as that would look like using Wikipedia as a web host to me. 0xDeadbeef 08:42, 11 June 2022 (UTC)
- Forgive me as I have no clue what kind of "burden" that would be. I don't use Talk header, however I do use other templates on subpages and transclude them to my talk page to customize their usage, so I guess it's just "different strokes for different folks". The only problem with forking a template to your userspace is that future improvements to the main template would be missed, and over time unless you keep up with it, the template in your userspace doesn't look the same as the main template. That can be a small problem I guess. P.I. Ellsworth , ed. put'r there 12:45, 11 June 2022 (UTC)
- Maintaining a separate template creates too much burden. I don't intend to have a copy in my user subpage if it can be avoided as that would look like using Wikipedia as a web host to me. 0xDeadbeef 08:42, 11 June 2022 (UTC)
- That's a good question. I know that sensors can differentiate among namespaces like mainspace and userspace, however I'm not sure that they can differentiate one talk space from another. If they can, then I don't see why it couldn't work. Are you averse to putting the Talk header template on one of your user subpages and making it work that way? P.I. Ellsworth , ed. put'r there 08:15, 11 June 2022 (UTC)
- @Paine Ellsworth, may I propose allowing setting the parameter only in the "User talk" namespace? We could detect if someone is using the parameter and error out when used in other namespaces. 0xDeadbeef 07:30, 11 June 2022 (UTC)
- No, people are free to manage their talk archives any way they like. If there is popular demand for templates helping with certain types of archive organisations, our templates should be adapted as necessary. —Kusma (talk) 15:22, 9 June 2022 (UTC)
- No, you can start from minus three if you want. Whether it's worth adapting templates to edge case user behavior is a separate question. Mathglot (talk) 19:42, 9 June 2022 (UTC)
- Wait, we are talking about userspace? As in one's talk page archives? I mean I archive my talk page myself by hand, and at one point I did number my archives as "1, 2, III, Delta, 6, Berlin". I have since grown up and now use a normal numbering system, but isn't that my business? If it's article talk pages you mean, I think that staring any sequence at zero is likely to throw people who aren't programmers? You don't often see "page 0" etc. Books use i, ii, iii before page 1 and maybe that could be used? Herostratus (talk) 21:23, 9 June 2022 (UTC)
- 4: User talk pages belong to the user, so they should for the most part do anything they want. Updating templates to support any starting value would not take that long, and it might as well be done. What would the harm be? Sungodtemple (talk) 00:52, 10 June 2022 (UTC)
- That "harm" might be determined by usage. The Talk header template is widely used on article talk pages, but I've only seldom seen it used on user talk pages. So to me it makes sense to not give that template 0th archive sensing capability. So again, either users can transclude the Archives template, which already has 0th archive sensing, or they can fork the Talk header template to their user talk subpage, give it 0th sensing, and then transclude the subpage to their talk page. No harm, no foul. P.I. Ellsworth , ed. put'r there 02:48, 10 June 2022 (UTC)
- Uhhhh as to the question of "Should we forbid numbering an archive as /Archive 0 in userspace", no - who cares They can call their archives whatever they want as long at it isn't blatantly disruptive or obviously trying to hide revision histories, if they want to use User_talk:X/Archive_Jan-Mar_1999, */Archive 0, or */Some_of_my_old_messages - I don't care. As far as the hidden question: should we maintain templates for edge cases? probably not. — xaosflux Talk 15:42, 11 June 2022 (UTC)
Make Main Page responsive by replacing tables
PASSED | |
There is clear consensus to adopt the proposal. (non-admin closure) {{u|Sdkb}} talk 16:10, 11 June 2022 (UTC) |
- The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The Main Page in order to split the blue and green boxes into columns and to split Today's Featured Picture with its description text. Because tables are used, when the screen width of the page is small, the columns do not collapse to become one column on non-responsive skins like Vector. This is a proposal to switch the tables to use CSS flex so that they are responsive and do collapse. The resulting page and code can be viewed here.
Ping to those who participated in the original discussion: @Ravenpuff @Stephen @Izno @Xaosflux Lectrician1 (talk) 01:54, 2 June 2022 (UTC)
- I support this change. I have personally found the width listed (875px) to be a reasonable break point. --Izno (talk) 21:54, 2 June 2022 (UTC)
- Support (Isn't this a web standard by now?) Levivich 01:30, 3 June 2022 (UTC)
- Using tables for layout was obsolete a long time ago... But it's been a challenge to get a consensus to change. (The silver lining is that by now, all supported browsers support the latest CSS layout models.) isaacl (talk) 02:15, 3 June 2022 (UTC)
- As far as I can remember, every attempt to get rid of tables has been part of a larger attempt to change 37 different things on the Main Page all at once (if not from the beginning, then by having people say "well, while, we're doing this, let's do ____, too"). If this proposal is limited to JUST changing away from tables and making the final appearance as nearly identical as possible, it might succeed. --User:Khajidha (talk) (contributions) 11:56, 7 June 2022 (UTC)
- In recognition of the difficulty in getting support for new visible changes, there have been proposals to modernize the implementation without affecting content/design layout changes on regular width screens. The rise of users with narrow screens on mobile devices, though, has given a concrete reason to make such changes. See the discussions linked to by Izno. isaacl (talk) 15:48, 7 June 2022 (UTC)
- If it makes no visible difference on regular width screens and only does this very specific thing on narrow screens, I would support it. Just don't try to go into the "let's add today's featured portal over here, and a link to requests for adminship here, and a ZX Spectrum emulator over there, and a random number generator over here, and.....". --User:Khajidha (talk) (contributions) 19:00, 7 June 2022 (UTC)
- In recognition of the difficulty in getting support for new visible changes, there have been proposals to modernize the implementation without affecting content/design layout changes on regular width screens. The rise of users with narrow screens on mobile devices, though, has given a concrete reason to make such changes. See the discussions linked to by Izno. isaacl (talk) 15:48, 7 June 2022 (UTC)
- As far as I can remember, every attempt to get rid of tables has been part of a larger attempt to change 37 different things on the Main Page all at once (if not from the beginning, then by having people say "well, while, we're doing this, let's do ____, too"). If this proposal is limited to JUST changing away from tables and making the final appearance as nearly identical as possible, it might succeed. --User:Khajidha (talk) (contributions) 11:56, 7 June 2022 (UTC)
- Using tables for layout was obsolete a long time ago... But it's been a challenge to get a consensus to change. (The silver lining is that by now, all supported browsers support the latest CSS layout models.) isaacl (talk) 02:15, 3 June 2022 (UTC)
- Support, this makes a great deal of sense and we should expect and design the site to be viewed by users on screens of all sizes. Seraphimblade Talk to me 02:07, 3 June 2022 (UTC)
- I support having a responsive design that can adapt to different screen display widths. isaacl (talk) 02:15, 3 June 2022 (UTC)
- Support 🐶 EpicPupper (he/him | talk) 02:32, 3 June 2022 (UTC)
- Support responsive main page is brilliant. This should have been done eons ago. – SD0001 (talk) 12:02, 3 June 2022 (UTC)
- Support obviously MichaelMaggs (talk) 12:35, 3 June 2022 (UTC)
- Support, clear improvement for those who don't log in or can't use superior skins like Monobook. —Kusma (talk) 12:50, 5 June 2022 (UTC)
- It is ironic that an 18 year old skin is more responsive than the current default, at least in this regard. – Joe (talk) 16:55, 5 June 2022 (UTC)
- Regarding Vector particularly, this recent blog post by a WMF engineer may be of interest. Izno (talk) 00:40, 6 June 2022 (UTC)
- It is ironic that an 18 year old skin is more responsive than the current default, at least in this regard. – Joe (talk) 16:55, 5 June 2022 (UTC)
- Support, long time coming. Good usability is good. -- Visviva (talk) 16:33, 5 June 2022 (UTC)
- Support. Damn, really? I knew the main page was overdue a modernisation, but not 15 years overdue. And as a broader point, I don't think stylistic issues like this should be subject to local project consensus. We're encyclopaedia editors, not web developers or designers. The WMF and MW devs should have a free hand to make incremental upgrades to prominent pages like this. – Joe (talk) 16:44, 5 June 2022 (UTC)
- The main page design isn't fixed by the MediaWiki software, which makes sense given the wide variety of installations for which it can be used. While I agree it would be better to delegate implementation details to technical experts (be they volunteers or paid staff), for better or worse, there tends to be a feedback loop between implementation and visible design features, which I believe has fueled a reluctance of some vocal members of the community to agree to defer. isaacl (talk) 20:31, 5 June 2022 (UTC)
- I mean the implementation and what it looks like. All we should be concerned with is the content. – Joe (talk) 21:53, 5 June 2022 (UTC)
- Well, so far this discussion has been refreshingly free of "it's not broken for me, so why fix it" comments. Perhaps the increasing number of mobile device users has helped overcome community reticence to change. isaacl (talk) 22:12, 5 June 2022 (UTC)
- I mean the implementation and what it looks like. All we should be concerned with is the content. – Joe (talk) 21:53, 5 June 2022 (UTC)
- The reason this discussion is occurring is because there have been at least two attempts to add this main page responsive behavior for Vector without an active consensus and at least one user complaint. You can see the complaints in archives 192 and 198. Izno (talk) 00:37, 6 June 2022 (UTC)
- smh we've been discussing this for four years. This is how we end up being decades behind the rest of the web. Thank you, Lectrician1, for bringing this home. Levivich 03:47, 6 June 2022 (UTC)
- The main page design isn't fixed by the MediaWiki software, which makes sense given the wide variety of installations for which it can be used. While I agree it would be better to delegate implementation details to technical experts (be they volunteers or paid staff), for better or worse, there tends to be a feedback loop between implementation and visible design features, which I believe has fueled a reluctance of some vocal members of the community to agree to defer. isaacl (talk) 20:31, 5 June 2022 (UTC)
- Support a responsive design. Gonnym (talk) 17:07, 5 June 2022 (UTC)
- Support an update is clearly required. – robertsky (talk) 17:32, 5 June 2022 (UTC)
- Support - while I use Monobook exclusively (due to finding Vector butt-ugly) I'm always on board for making pages that newer editors/readers are very likely to see more readable. —Jéské Couriano v^_^v a little blue Bori 21:49, 5 June 2022 (UTC)
- Support. But, I've got a question. When I view the desktop version of Izno's sandbox on my phone, it's still in two-column mode. When I resize a window on my real desktop to the same width, it does the responsive thing and goes into single column mode. What's happening here? -- RoySmith (talk) 01:06, 6 June 2022 (UTC)
- @RoySmith are you viewing it using mobile frontend like most phones would use (en.m.wikipedia.org)? Are you setting your phone to use "desktop" mode, and if so - are you logged in and have a skin selected? The link above is good for seeing "Is how I look at the mainpage normally going to be OK" - but if you want to see a difference you really need to be using the only main condition it matters, legacy vector - such as loading the sanbox with this link. — xaosflux Talk 01:11, 6 June 2022 (UTC)
- Basically, the operating system resolution of smartphones is large enough these days such that the check for "greater than 875 px" returns true. The blog post I linked above in re to Joe explains some of it. There isn't really a way to fix that issue besides the change suggested in that blog post (I guess if you can find the 'zoom' button on your smartphone's browser, that would 'fix' it, but I'd have to look hard for the one on Firefox). Izno (talk) 01:56, 6 June 2022 (UTC)
- I'm not (by any means) an expert on CSS, but isn't that what using em instead of px is supposed to solve? -- RoySmith (talk) 03:00, 6 June 2022 (UTC)
- I am pretty sure not, since ems are still based on some relation to a root font-size. Your browser is the one that decides to display this size of text on mobile (Firefox does the same in Vector on mobile, so you're not alone). Either (mobile) browsers need to improve their understanding of the default appearance (or attempted appearance) of web pages (e.g. heuristics based on included CSS or something) or Vector needs to have the change suggested made. Izno (talk) 04:28, 6 June 2022 (UTC)
- But isn't the whole idea to make it relative to the font size? Instead of "go into 1-column mode on windows less than 875px", it's "go into 1-column mode on windows less than 70 typical character widths?" I tried it in User:RoySmith/Sandbox/MP2. Seems to do the right thing on both my desktop and my phone. -- RoySmith (talk) 13:34, 7 June 2022 (UTC)
- I've learned something. :D Safari < 15 is bugged when text zoomed, which is 4% of our views, but apparently Safari at some age is broken with px media queries also.
- I can take a look at this. Izno (talk) 01:45, 8 June 2022 (UTC)
- Ok, so your version doesn't work the way you think it does. All that happened is that you chose a wider (70em) break point. 55em, which is about 860px in Vector (and close to it in others), displays the same behavior as a breakpoint of 875px. Izno (talk) 02:09, 8 June 2022 (UTC)
- But isn't the whole idea to make it relative to the font size? Instead of "go into 1-column mode on windows less than 875px", it's "go into 1-column mode on windows less than 70 typical character widths?" I tried it in User:RoySmith/Sandbox/MP2. Seems to do the right thing on both my desktop and my phone. -- RoySmith (talk) 13:34, 7 June 2022 (UTC)
- I am pretty sure not, since ems are still based on some relation to a root font-size. Your browser is the one that decides to display this size of text on mobile (Firefox does the same in Vector on mobile, so you're not alone). Either (mobile) browsers need to improve their understanding of the default appearance (or attempted appearance) of web pages (e.g. heuristics based on included CSS or something) or Vector needs to have the change suggested made. Izno (talk) 04:28, 6 June 2022 (UTC)
- I'm not (by any means) an expert on CSS, but isn't that what using em instead of px is supposed to solve? -- RoySmith (talk) 03:00, 6 June 2022 (UTC)
- Support. Uncontroversial modernization. MarioGom (talk) 07:38, 10 June 2022 (UTC)
- Support - baby steps for the front page but progress is progress. Retswerb (talk) 03:38, 11 June 2022 (UTC)
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)
- 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)
- 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)
- 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)
- Yes, I think we need to go after all of these issues. BD2412 T 23:51, 14 May 2022 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- @Uanfala: There are instances of blocks of text that have been hidden for ten or twelve years or more, apparently completely forgotten, while the rest of the article has likely completely changed around them. BD2412 T 01:11, 5 June 2022 (UTC)
- To the best of my knowledge, this has never been a standard, accepted practice for editing. On the occasions when I have seen it used I have simply removed the content, it's just clutter in the edit window at that point, and article histories are a thing for anyone who wants to see what an article used to say, but no longer does. Beeblebrox (talk) 02:47, 5 June 2022 (UTC)
- @Uanfala: There are instances of blocks of text that have been hidden for ten or twelve years or more, apparently completely forgotten, while the rest of the article has likely completely changed around them. BD2412 T 01:11, 5 June 2022 (UTC)
- 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)
- 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)
- 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)
- 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)
- A lot of hidden things are useful (comments about likely pitfalls, for example to warn people against linking a non-notable person to someone else with the same name). That kind of hidden text should stay there indefinitely (also, editnotices don't work everywhere, so hidden text must be used sometimes). I don't mind a cleanup project going through hidden text, but it needs a lot of human triage whether hidden text should (a) be removed outright (b) be put on the talk page or (c) stay there forever. —Kusma (talk) 12:47, 5 June 2022 (UTC)
- User:Δ has generated a report indicating the total volume of just those hidden text blocks that are over 1,000 characters. Although it is a bit difficult to parse, suffice to say that runs to about 40,000K. BD2412 T 06:03, 6 June 2022 (UTC)
- As to the points on standard practice using hidden text to leave notes in the article has been part of the cheatsheet for nearly a decade. I don't see a reason to remove these en masse, but a tracking category could be useful. - LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 16:18, 11 June 2022 (UTC)
- Beyond the sheer volume of instances, there is no consistency between them. There are instances of hidden text that I have seen where a few sentences or a few paragraphs are hidden without any note in the text or explanation in the edit summary, or where a note in the text is itself ambiguous or unhelpful. We have instances of that type and many others that have been sitting in article wikitext for over a decade. BD2412 T 18:42, 11 June 2022 (UTC)
- First step: sweep for hidden text and add a template to the talk page header that says "this article has hidden text", to alert editors. Then go through them and remove/move the text. We should also document in a PAG somewhere that hidden text should not be used as a way to communicate. Levivich 18:55, 11 June 2022 (UTC)
- A lot of my content space work has been in an area of history which spawned a number of pop culture artefacts, and as such I regularly see hidden text in the form of "please do not introduce additional information about this person's role in video games" or similar. See for example Lady Zhen#In popular culture. I think a hidden text edit notice exactly where a good faith editor is likely to introduce or change material against consensus is the most perfect way to communicate, rather than a years-old discussion centralised on a wikiproject or whatever. Good targeting, per users Uanfala and Kusma above. I don't think the practice necessarily needs to be discouraged in all cases. Folly Mox (talk) 19:02, 11 June 2022 (UTC)
- I think what we need to aim for is removing hidden content. If there is a sentence or a paragraph or a reference that is purely article content with a note questioning its validity or utility, that should not be kept hidden perpetually. BD2412 T 19:04, 11 June 2022 (UTC)
- Yes, hidden notes are a great way to highlight things where good faith editors are likely to make changes that aren't desired (not just because of consensus but also because something seems counter-intuitive for some reason, etc). However they should not be used to hide content - that should either be removed completely, moved to the talk page or tagged as appropriate to the situation. Sometimes noting what content has been removed (and why) can be useful but not the content itself. The trick is distinguishing the two. Thryduulf (talk) 19:29, 11 June 2022 (UTC)
- I think what we need to aim for is removing hidden content. If there is a sentence or a paragraph or a reference that is purely article content with a note questioning its validity or utility, that should not be kept hidden perpetually. BD2412 T 19:04, 11 June 2022 (UTC)
- A lot of my content space work has been in an area of history which spawned a number of pop culture artefacts, and as such I regularly see hidden text in the form of "please do not introduce additional information about this person's role in video games" or similar. See for example Lady Zhen#In popular culture. I think a hidden text edit notice exactly where a good faith editor is likely to introduce or change material against consensus is the most perfect way to communicate, rather than a years-old discussion centralised on a wikiproject or whatever. Good targeting, per users Uanfala and Kusma above. I don't think the practice necessarily needs to be discouraged in all cases. Folly Mox (talk) 19:02, 11 June 2022 (UTC)
RFC: Move Main Page to Wikipedia:Main Page
Nope. @Lynvir: please research the many, many, discussions that have occurred on the topic first; including topics from Wikipedia:Perennial proposals#Move the Main Page to another namespace, such as "Wikipedia:" or "Portal:". Then, if you are extremely serious, workshop this up somewhere first. — xaosflux Talk 10:07, 21 June 2022 (UTC) |
- The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Should we make the homepage Wikipedia:Main Page rather than mainspace? It will be nice as minspace is for encyclopedic content only and the English Wiktionnary has already done so. Lynvir (talk) 09:47, 21 June 2022 (UTC)
Survey
Discussion
RFC: Shut down Wikipedia:Administrative action review
IAR Involved Close - no one wants this RfC. Those of us who think it was a bad idea are content to see if it actually takes off or if it dies. Those who thought it was a good idea don't want it marked historical yet and have an issue with the format of this RfC. The only thing everyone seems to agree on about this is that having an RfC about whether or not to mark it historical is something we don't need now. When all the interested parties agree this isn't a formal discussion worth having at this point; thats when you stop the discussion. I've already voted, so if anyone other than the IP who started this wants to revert me, go ahead, but my reading of the consensus is that there is nothing controversial about closing this now. TonyBallioni (talk) 19:52, 12 June 2022 (UTC) |
- The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Background (Administrative action review)
Wikipedia:Administrative action review (XRV) was created following Wikipedia:Requests for adminship/2021 review/Proposals#Passed: 6C Administrative action review. To start with, this board has nothing do with improving RFA, so many people who were not interested in RFA did not see the original proposal, as mentioned by User:Risker and User:TonyBallioni in the discussion section of the proposal. 6 months after creation and long discussions on the talk page later, the scope of this page is still unclear. It has hardly ever been used and still has "This is a newly created process and norms are still being established." on top. Many users have opined that XRV is a duplicate to WP:AN and its inactivity supports this notion. XRV has not received edits for the last 3 months except for test edits. There is nothing that XRV can do that cannot already be done at WP:AN with input from a wider audience. XRV is clearly a failed experiment and I propose that it be formally deprecated and marked as historical. There is already too much bureaucracy in wikipedia, pointing users to an unused and redundant process is unhelpful. 2409:4071:D9A:88D6:11AA:2ACF:EA4C:C433 (talk) 09:18, 11 June 2022 (UTC)
Support (Administrative action review)
- Support I don't think XRV has done anything to support its founding as a solution to improve RFA's; it's birth from this RfC predicted that
if it turns out to be useless it will naturally die
, and it so it has. — xaosflux Talk 11:49, 11 June 2022 (UTC) - Put me here if this RfC continues — it failed because it is duplicative and the only reason to use it is to prove a point that it is needed. That being said, I agree with Kudpung below that the better outcome would just be to let it wither away in obscurity, so I don't really oppose a procedural closure of this RfC. Actually think a procedural closure might do more to speed up the death of it since there will be less fighting over whether to save it or not. TonyBallioni (talk) 19:04, 12 June 2022 (UTC)
Oppose (Administrative action review)
- Oppose and malformed RFC The RFC is non-neutral. The "background" isn't background, it is arguments for a certain outcome. There is a good place for the process in Wikpedia. It needs to be tweaked. Less focused on "use of tools", more focused on actions (including/especially non-severe course corrections, and including mere mis-use of the imprimatur) of admins where fellow admins consider it impolite to intervene. North8000 (talk) 12:00, 11 June 2022 (UTC)
- If you think there is a good place for a process like that on Wikipedia, then I suggest your time would be much better spent getting consensus for a new venue with that explicit purpose, rather than trying to mould this one into a vision that is completely at odds with what some others want to see the place become. Thryduulf (talk) 12:13, 11 June 2022 (UTC)
- Oppose: My position is that AAR is a good idea and we should use it.—S Marshall T/C 12:14, 12 June 2022 (UTC)
- Procedural close, RFC consists entirely of argument.--WaltCip-(talk) 14:43, 12 June 2022 (UTC)
- Oppose: it is too soon to mark it as historical. — Bilorv (talk) 14:53, 12 June 2022 (UTC)
- Procedural close send this proposal through idea lab so that people can jointly work on it, then bring it back. Major issues with the proposal atm. Curbon7 (talk) 15:33, 12 June 2022 (UTC)
- Procedural close per the others and my (now reverted) closing statement. Levivich 16:13, 12 June 2022 (UTC)
Neutral (Administrative action review)
- (see also my extended comment in the discussion section) It's currently harmless in it's nominally experimental but practically completely inactive state. My preference is just to leave it like that until it completely fades into obscurity such that placing a historical tag is completely uncontroversial, but equally actively marking it deprecated now is not going to harm anyone or anything so I've got no reason to oppose that. Thryduulf (talk) 12:06, 11 June 2022 (UTC)
- (see my comment in the discussion section) For once I find myself concurring 100% with Thryduulf. Kudpung กุดผึ้ง (talk) 12:26, 11 June 2022 (UTC)
- I see no useful purpose in doing anything about it at this point, so find myself in agreement with Thryduulf and Kudpung for now. However I am open to logical reasoning and rational persuasion based on evidence. Cheers, · · · Peter Southwood (talk): 07:30, 12 June 2022 (UTC)
Discussion (Administrative action review)
- The "background" here is misleading and inaccurate and would be more appropriate as a comment. Yes, some people didn't think that XRV wasn't sufficiently related to RFA or too similar to AN. They're reasonable points, even if I disagree with them, but ultimately they had their say, along with those with other objections, and the RfC still found a comfortable consensus with something like 70 participants. After it was closed, we implemented the basic process proposed in the RfC and quickly started building momentum with some initial threads and a healthy set of discussions on how to refine the process. What happened then was that a small group of power users, unaccustomed to not getting their way, swooped down to try and delete the page, then when that failed, obstruct it by insisting we needed a second RfC confirming the first before it could be used, put tags on the page telling people not to use it, and most damagingly of all, remove all incoming links to it from other project pages. With that concerted attempt to smother the process before it got started, coming from the very people XRV was supposed to make more accountability to the community, it's not surprising that it became inactive shortly thereafter. So mark it as historical as a description of the current state of affairs if you like, but that doesn't change the fact that a) XRV had a strong consensus behind it which is now unrealised because of the objections of a small cohort and b) there remains a need for it, as seen by regular confusion about where the used of PERMs can be reviewed, and the continuing stream of ANI threads and ArbCom case requests about administrator misconduct that could have been resolved with early intervention at a less fraught venue. – Joe (talk) 10:47, 11 June 2022 (UTC)
- If you are going to give diffs of supposed obstructionism, it is only fair to those users that you ping them. Courtesy pings to users mentioned above @Spartaz, Jehochman, Bbb23, Floquenbeam, Beeblebrox, Thryduulf, Kudpung, and Isaacl: 2409:4071:4D0B:373:FC64:EA32:3697:9D16 (talk) 11:32, 11 June 2022 (UTC)
- ...I linked to talk page sections which dozens of users participated in. Why have you only notified the most vocal opponents of XRV? Not exactly a wonderful start if you're genuinely after a balanced discussion. Of course, even if there's a consensus to mark it as historical, we'll have to have a second on how to mark it as historical. – Joe (talk) 11:34, 11 June 2022 (UTC)
- If you are going to give diffs of supposed obstructionism, it is only fair to those users that you ping them. Courtesy pings to users mentioned above @Spartaz, Jehochman, Bbb23, Floquenbeam, Beeblebrox, Thryduulf, Kudpung, and Isaacl: 2409:4071:4D0B:373:FC64:EA32:3697:9D16 (talk) 11:32, 11 June 2022 (UTC)
- (responding to ping) It was clear from the RfC that developing something called XRV to do something related to reviewing (some subset of) actions by administrators and/or administrative actions (most but not all administrative actions are taken by administrators, most actions by administrators are not administrative actions) had consensus from those participating, which is not the same thing as implementing a less-than-half-formed venue with no clear agreement, even among proponents, regarding its purpose, scope or processes. When it became clear to me that it wasn't going to be easy to get agreement on any of the prerequisites for a functioning venue I decided I had better things to do with my life and the lack of activity suggests most others feel similarly. I don't really see the need to do anything with it other than let it naturally fade even further into obscurity. Thryduulf (talk) 12:10, 11 June 2022 (UTC)
- Joe Roe: Me? A power user? OMG! All I did was to state a few accurate facts here and here - simple generalisations about RfC proposals and noticeboard behaviour. That said, well,
"coming from the very people XRV was supposed to make more accountability to the community"
, I'm not even an admin, so it wouldn't affect me. XRV is dead, and you, dear IP hopping user, would probably have done better by letting sleeping dogs lie. Kudpung กุดผึ้ง (talk) 12:24, 11 June 2022 (UTC) - I have reverted an inappropriate closure by Levivich, who had cast a "Profanity-laced keep" for XRV. Clearly they are WP:INVOLVED here. To address comments about canvassing, the reason I pinged 7-8 users was because Joe Roe was specifically talking about them in the examples they gave (which included one direct diff). The RFC question of "Should Wikipedia:Administrative action review be depracted and marked as historical?" is neutral. In the background section I explained why I opened this RFC, obviously I wouldn't have opened it if I was opposed to shutting it down myself. I don't see what RFCBEFORE is required here, XRV is a completely inactive process, I only sought to make it a formality. And no I am not a "logged out OP", I am a long term IP user who never saw a reason to create an account. My ISP assigns very dynamic IPs, so my contributions are spread out over a broad range of IP addresses. 2409:4071:4D13:677B:E5E4:694E:766D:5EE0 (talk) 06:20, 12 June 2022 (UTC)
- The basic problem with AAR is that after the community reached consensus to create it, it got back-door deprecated by way of quibbles about process and scope. We clearly should have more structure around this than currently exists, because when an administrative action is disputed on AN, the thread can be closed after a random interval by a self-selected person, and that means that the actions are reviewed by whoever gets there first. This creates an incentive to rush to comment if you want to be heard, which in my view is clearly suboptimal. We should have fixed-duration discussions and holding them in a separate venue will help to archive them. DRV reaches better decisions with less drama than the AN does, and having a well thought out process is the reason why.—S Marshall T/C 12:12, 12 June 2022 (UTC)
back-door deprecated by way of quibbles about process and scope.
is an, interesting, way of framing the discussions that were attempting to determine whether there was consensus for the sort of process you desire or the sort of processes favoured by others. There was very clearly consensus for something, but given that all these months later there is still no consensus about what exactly that something was is rather telling. Thryduulf (talk) 14:28, 12 June 2022 (UTC)- The consensus was: A new process, Administrative Action Review (XRV) designed to review if an editor's specific use of an advanced permission, including the admin tools, is consistent with policy in a process similar to that of deletion review and move review. Thanks to all the editors who contributed (and are continuing to contribute) to the discussion of how to implement this proposal. Wording taken directly from the RfC close.—S Marshall T/C 15:41, 12 June 2022 (UTC)
- IIRC there was a collapsed box in the proposal that had further details. The consensus was quite specific. Levivich 16:12, 12 June 2022 (UTC)
- Yet, after months of discussion among editors acting in good faith, there is still no agreement on multiple open questions. This is rapidly heading towards rehashing those discussions, so I'll leave it here as you can read as well as I can and, unless anybody has anything new to bring to the table, there is no point in another few thousand words of no consensus. Thryduulf (talk) 16:17, 12 June 2022 (UTC)
- There were no "months of discussion". XRV was smothered in a matter of days and none of the discussion was constructive, only nonspecific objections to the process being "a mess" or "an embarrassment" or "not what the RfC said". We asked you and others repeatedly what those "multiple open questions" about the process were supposed to be, and never got an answer. It died because you (plural) insisted that the RfC consensus could not be implemented before some supposedly critical flaws were resolved, but you wouldn't tell us what those flaws were. – Joe (talk) 16:27, 12 June 2022 (UTC)
- I would put it less strongly than Joe Roe, but I do think the community consensus was clearer than most of our policies, Thryduulf. There was some real disagreement by people who wanted it to be something it wasn't, but the main problem was tactical failure to understand plain English.—S Marshall T/C 16:33, 12 June 2022 (UTC)
- I agree that what it was supposed to do seemed quite clear, but think that it has a failure to launch. — xaosflux Talk 16:39, 12 June 2022 (UTC)
- I wouldn't say failure to launch so much as it was shot down shortly after launch by people who opposed its launching. Joe summarized the details well above. Levivich 18:33, 12 June 2022 (UTC)
- It didn't help that one editor, who had very firm ideas how XRV should develop, made 25% of the talk page edits as well as 25% of the edits at XRV itself. They're now blocked for disruptive editing and checkuser-blocked, but many may have been too exhausted or frustrated by then. NebY (talk) 19:20, 12 June 2022 (UTC)
- That's a good point. It wasn't just those opposed to the idea who killed it; overenthusiastic supporters were equally to blame. It may be that, with the initial fervor dying down, cooler heads can now prevail and we can get it re-launched. Levivich 19:32, 12 June 2022 (UTC)
- I agree that what it was supposed to do seemed quite clear, but think that it has a failure to launch. — xaosflux Talk 16:39, 12 June 2022 (UTC)
- I would put it less strongly than Joe Roe, but I do think the community consensus was clearer than most of our policies, Thryduulf. There was some real disagreement by people who wanted it to be something it wasn't, but the main problem was tactical failure to understand plain English.—S Marshall T/C 16:33, 12 June 2022 (UTC)
- There were no "months of discussion". XRV was smothered in a matter of days and none of the discussion was constructive, only nonspecific objections to the process being "a mess" or "an embarrassment" or "not what the RfC said". We asked you and others repeatedly what those "multiple open questions" about the process were supposed to be, and never got an answer. It died because you (plural) insisted that the RfC consensus could not be implemented before some supposedly critical flaws were resolved, but you wouldn't tell us what those flaws were. – Joe (talk) 16:27, 12 June 2022 (UTC)
- Yet, after months of discussion among editors acting in good faith, there is still no agreement on multiple open questions. This is rapidly heading towards rehashing those discussions, so I'll leave it here as you can read as well as I can and, unless anybody has anything new to bring to the table, there is no point in another few thousand words of no consensus. Thryduulf (talk) 16:17, 12 June 2022 (UTC)
- IIRC there was a collapsed box in the proposal that had further details. The consensus was quite specific. Levivich 16:12, 12 June 2022 (UTC)
- The consensus was: A new process, Administrative Action Review (XRV) designed to review if an editor's specific use of an advanced permission, including the admin tools, is consistent with policy in a process similar to that of deletion review and move review. Thanks to all the editors who contributed (and are continuing to contribute) to the discussion of how to implement this proposal. Wording taken directly from the RfC close.—S Marshall T/C 15:41, 12 June 2022 (UTC)
- As I said before, mark it as an optional process and see if it helps solve problems (or if it tends to intensify them). Based on experiments we can then decide whether to make it permanent. Jehochman Talk 19:34, 12 June 2022 (UTC)
Update for the fully professional league to notable leagues
- The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Hi. To clarify the sakes that can help enhance SIGCOV and GNG, I have proposed to update the following from the the title "fully professional leagues" to "notable leagues" in the area that the SIGCOV and GNG are to be respected, and to make the concerns addressed as to the list would be to inclusive in terms of notability.
I will look forward to hear your opinions, and have a peaceful day. Cheers. Ivan Milenin (talk) 03:08, 13 June 2022 (UTC)
Responses (football leagues)
- I've made a new section so the responses are readable. A few questions: (1) Can I ask why the proposal was not put to WP:FOOTBALL first, as this seems to be within that board's area of interest? (2) I note that WP:FPL is an archived/"historical" page that you have derived this from. Is this something that has been deprecated by the Football WP sub-group? (3) There seem to WP:FOOTBALL notability criteria already. What does this new proposal add? I.e. is this really needed? (4) What are the notability criteria used here? Do you have a list? (5) Why add defunct leagues? (6) Why mention since x year?
- (Continued) I do hate excessive guidelines as they prevent casual editors adding to knowledge. However if you wish to make a "notability list" then you need to ensure that you have criteria for it, as otherwise (eventually) either notability seems to get "captured" by a small group of editors, or alternatively descends into everyone thinking their hobby issue is notable enough to put on the list as there's no strict criteria. I hope these thoughts help in refining what you want to do. - Master Of Ninja (talk) 07:33, 13 June 2022 (UTC)
- @Master Of Ninja I would note that they have zero need to put the proposal to a wikiproject first - in fact, I would generally say that would be a negative for a content project as doing so would inherently prohibit any notability policy that those interested in football disagree with. I make no comment on the other questions. Nosebagbear (talk) 09:09, 13 June 2022 (UTC)
- @User:Nosebagbear - thanks for reply. It's interesting as I feel this cuts both ways. That slightly odd sub-project guidelines or conventions shouldn't necessarily overrider WP policies. - Master Of Ninja (talk) 13:08, 13 June 2022 (UTC)
- @Master Of Ninja I would note that they have zero need to put the proposal to a wikiproject first - in fact, I would generally say that would be a negative for a content project as doing so would inherently prohibit any notability policy that those interested in football disagree with. I make no comment on the other questions. Nosebagbear (talk) 09:09, 13 June 2022 (UTC)
- Why is this here? you already started a discussion in the appropriate place, Wikipedia talk:Notability (sports). Please do not split the discussion by having it in several places at once. —Kusma (talk) 11:42, 13 June 2022 (UTC)
- Good catch, although it seems the proposal is somewhat different but related. The noted discussion is here: Wikipedia talk:Notability (sports)#Proposal for association football (soccer). A user there already pointed to a previous discussion at Wikipedia:Village pump (policy)/Archive 173 § Notability guideline for association football on Wikipedia:Notablity (sports). As well as another related discussion at Wikipedia_talk:Notability_(sports)/Association_football. These seem quite related discussions to me so should be consolidated on one forum. Any similar discussions on other parts of WP should be consolidated to this. @User:Ivan Milenin - what's your thoughts on this? - Master Of Ninja (talk) 13:18, 13 June 2022 (UTC)
- @Master Of Ninja: I have read those comments. They appear to have been related, so, no problem with that. Proceed. Ivan Milenin (talk) 15:11, 13 June 2022 (UTC)
- Thanks User:Ivan Milenin. I see User:GiantSnowman and User:SMcCandlish have also made the same point in the section below. You should probably actually consolidate it on the other page (Wikipedia talk:Notability (sports)#Proposal for association football (soccer)) as that has more interest and discussion. I will (try and) close this discussion. If you have any other related discussions you should move to close them and point them to the main discussion page.
- Although note in future having a central discussion does not stop you from posting to other boards to tell others that a relevant discussion is occurring elsewhere - it just is better to have one page for discussion.
- I would also suggest in your proposal on Wikipedia talk:Notability (sports) that you update it and write some more background including links to the previous related discussion, and a summary of the outcomes, as linked on my previous reply above. This allows users dropping by to work out what has been discussed before, and to catch up more easily on progress so far. Otherwise it relied on User:Kusma pointing out to this page that there had been previous discussions. - Master Of Ninja (talk) 08:19, 14 June 2022 (UTC)
Keep discussion central
- This needs to be discussed at Wikipedia talk:Notability (sports)/Association football please. Having it in 3 separate locations is pointless. GiantSnowman 15:39, 13 June 2022 (UTC)
- Agreed. — SMcCandlish ☏ ¢ 😼 23:16, 13 June 2022 (UTC)
Proposal to prohibit WikiProjects from ranking further articles as A-class
I would like to notify the Village Pump of a proposal to prohibit WikiProjects from ranking articles as A-class that was filed at MfD yesterday. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 18:55, 18 June 2022 (UTC)
Allow admins to grant PCR right?
NOTHING TO DO HERE | |
This is a proposal for what is (and always has been) the status quo for PCR grants. --Blablubbs (talk) 13:22, 19 June 2022 (UTC) |
- The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Currently, only bureaucrats may create new pending changes reviewers. I propose that this power be transferred to administrators, since the right is relatively less important (unlike, say, the power to grant new admins). Thanks. NotReallySoroka (talk) 06:42, 19 June 2022 (UTC)
- @NotReallySoroka: Er, I'm an admin with no superpowers - just the basic admin bundle plus autopatrolled. If I go to "User rights management" for any user (from a newly-registered account with zero edits, all the way up to Jimbo), I get the same two columns. The first, titled "Groups you cannot change" is greyed out - it has the following entries:
List of items
|
---|
|
- I could therefore remove the pending changes reviewer right from you, and restore it again. But I won't, because that is against WP:ADMIN#Expectations of adminship. I could also grant it to Jimbo, who apparently doesn't have it... --Redrose64 🌹 (talk) 09:28, 19 June 2022 (UTC)
- Redrose64, WP:JIMBOISNOTAHATSTAND /j. — Ixtal ( T / C ) ⁂ Join WP:FINANCE! 11:34, 19 June 2022 (UTC)
- @NotReallySoroka: see Special:ListGroupRights this is already in place. — xaosflux Talk 10:35, 19 June 2022 (UTC)