This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Proposal: issue a notice when an edit creates a File: redlink
A common problem with bulk spelling/case/punctuation fixes is accidentally applying them in filenames, turning them to redlinks. This should be easy to detect and notify about, similar to how you get a message when you create a link to a disambig page. Can we get such notices, at least as an option? Dicklyon (talk) 01:05, 4 April 2022 (UTC)
Seconded. I've almost created quite a few such errors using JWB etc. DPL bot may be a useful model: it issues a polite user warning when we link to disambiguation pages. Certes (talk) 10:28, 4 April 2022 (UTC)
@Certes, I presume that Dicklyon is referring (correct me if I'm wrong) to mw:Help:Extension:Disambiguator, which is even better than DPL bot, as it alerts you in real time. {{u|Sdkb}}talk 04:24, 5 April 2022 (UTC)
Both might be useful. An immediate alert in WikiEditor is a good idea and should reduce such errors in manual editing. I assumed from the term "bulk" that Dick's suggestion applied instead to errors created with tools such as AWB and JWB, where editors might preview just a sample rather than every page, and possibly by bots. Unless we're going to change that software then an alert after the fact may be the best we can do there (but see xeno's filter comment below). Certes (talk) 10:26, 5 April 2022 (UTC)
I think both the realtime pop-up and the after-the-fact notification would be useful. I was thinking more of the lattter, for AWB or bot edit error catching. It's easy to fix after the fact if the errors are noticed (e.g. by another small AWB batch for a commonly used filename that got messed up in a big batch; I've done this for errors someone noticed, but then that someone is already annoyed). Dicklyon (talk) 18:44, 5 April 2022 (UTC)
Template to request page translation from English to another language
Apologies if this exists in some form but I have been unable to find it if it does. I know there are editors who translate pages from one language to another and there are ways to request expanding English pages using translations from other language Wikipedia pages. However, my proposal is for the creation of a template that can be added to articles requesting the page be translated from English to another language. The English language Wikipedia has far more pages than any other language version of Wikipedia and there are many pages about organisations or subjects that have strong ties to a specific country that may be non-English speaking, whereby it would make sense for the page to have a translated version in that country's native/official language if one does not exist already, which is the case with many pages. For example, the page Great Legalisation Movement India has an English language version but no Hindi language version. Therefore, it would be beneficial to be able to add a template to this page requesting a Hindi language version of the page be created. Helper201 (talk) 20:18, 31 March 2022 (UTC)
Why should we care whether out articles are translated into other languages? This is the Hindi Wikipedia's issue, not ours. * Pppery *it has begun... 20:53, 31 March 2022 (UTC)
This would be best done on the destination wiki, most people that come across our article are unlikely to be able to write in the foreign language. Check out wikidata:Q13308814 for some examples of "requests for translation" on other projects. — xaosfluxTalk 21:10, 31 March 2022 (UTC)
For an article which isn't going to have huge readership in another language, I generally think running the English-language article through Google translate would work best (assuming translation to and from your language works OK, I don't know if that's the case). English language articles are much more frequently updated than other languages in many cases, I've seen cases where a translation preserved the content of an article exactly as it was in say 2019, the article has been massively expanded since and the foreign-language article has stagnated with no improvements. Google translate on the English article is more likely to be up to date. Blythwood (talk) 04:10, 6 April 2022 (UTC)
Proposing a change to the notability declining message in AFC
Consensus appears to support this proposal, with an edge being given to Femke's alternative bullet-format. ~Anachronist (talk) 20:01, 26 September 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.
From:
This submission's references do not show that the subject qualifies for a Wikipedia article—that is, they do not show significant coverage (not just passing mentions) about the subject in published, reliable, secondary sources that are independent of the subject. Before any resubmission, additional references meeting these criteria should be added (see technical help and learn about mistakes to avoid when addressing this issue). If no additional references exist, the subject is not suitable for Wikipedia.
to:
This submission's referencing do not show that the subject qualifies for a Wikipedia article. See an explanation for our inclusion guidelines here.
In summary: the sourcing in this article does not demonstrate significant coverage (not just passing mentions) about the subject in published, reliable, secondary sources that are independent of the subject. Before any resubmission, additional references meeting these criteria should be added (see technical help and learn about mistakes to avoid when addressing this issue). If no additional references exist, the subject is not suitable for Wikipedia.
I think less people will be confused about the decline message then. – AssumeGoodWraith (talk | contribs) 02:35, 16 March 2022 (UTC)
Support seems more clear than current version. signed, 511KeV (talk) 15:42, 16 March 2022 (UTC)
Support, but change "do not" to "does not" for grammatical reasons. ― Blaze WolfTalkBlaze Wolf#6545 16:08, 16 March 2022 (UTC)
I would also change "Before any resubmission, additional references meeting these criteria should be added" to "Make sure you add additional references that meet these criteria before resubmitting". Less aggressive but still gets the point across. ― Blaze WolfTalkBlaze Wolf#6545 16:13, 16 March 2022 (UTC)
I think it's important to make it more clear, thanks for the proposal :). The wording is still relatively academic: long sentences, difficult words. Would it work better to use bullet points for the sourcing requirements? This may make it easier to mentally tick the boxes. I may be wrong, but I thought the best convention now is not linking words without meaning (like here). I like Blaze's Wolf suggestion about softening the language. Femke (talk) 20:45, 16 March 2022 (UTC)
I'm feeling daft - is the only difference here adding a hard return after the main statement with some minor formatting tweaks? (please ping on reply) Primefac (talk) 09:10, 17 March 2022 (UTC)
Support highlighting the key statement is key to getting many to read anything in these notices. Lots of these templates could be improved with some minor tweaks. Regards KylieTastic (talk) 09:35, 17 March 2022 (UTC)
Oppose at the moment. In the future I suggest proposing things like this at WT:AFC, or at least leaving us a note on that talk page. By proposing this here I kind of feel like you left WikiProject AFC out of the discussion. Anyway, here are my concerns: 1) This seems to add vertical whitespace. I would suggest removing the line breaks. 2) This links yet another policy page for the draft writer to read. There's a danger of information overload. If anything we could look into making this more concise. –Novem Linguae (talk) 15:18, 17 March 2022 (UTC)
Trying to address information overload, bringing out the four criteria for sources (which a large portion of new editors struggle with), and cutting out the least helpful link (most people understand how to add a source at this point, the 'verification' decline message can provide technical help if they struggle). On a side note, we don't do that well explaining notability before submission. The Article Wizard has a great short and easy explanation how to use sources, but the notability explanation is a bit vague.. Femke (talk) 17:35, 17 March 2022 (UTC)
This draft's references do not show that the subject qualifies for a Wikipedia article. In summary, the draft needs multiple published sources that are:
Make sure you add references that meet these criteria before resubmitting. Learn about mistakes to avoid when addressing this issue. If no additional references exist, the subject is not suitable for Wikipedia.
However, it should say like “not just passing mentions about the subject” – AssumeGoodWraith (talk | contribs) 23:59, 17 March 2022 (UTC)
I agree. This is a lot simpler compared to the current message, which contains 7 links (compared to the 5 of Femke's proposed message) and takes up 4 lines on my screen size (1366x768). This also gives the reader the main issue in bold so that if they don't want to read the rest, they can see the issue with their article quickly and easily. IF the reader does continue reading, the bullet-points listing what the sources should be make it easy to know what they should be looking for in sources. ― Blaze WolfTalkBlaze Wolf#6545 00:09, 18 March 2022 (UTC)
I like this a lot, it breaks up the wall of text and draws attention to the important points. Rusalkii (talk) 18:14, 18 March 2022 (UTC)
@Rusalkii: You pretty much just said the exact thing I did, except in a lot fewer word and it makes more sense than what I was saying. (nothing bad about either of our responses, I just found it kinda funny how we basically said the same thing, but I just chose to go into more detail) ― Blaze WolfTalkBlaze Wolf#6545 18:46, 18 March 2022 (UTC)
@Femke, I suppose the proposed notability message will be applied downstream on the specific SNG notability messages as well? (see {{AfC submission/comments}} for the full list of the messages possibly applicable) – robertsky (talk) 07:20, 21 March 2022 (UTC)
Support; Femke's version of the message is a clear improvement to the current one. Much more clear and concise. LunarisTFM(💬 • 📝) 15:10, 28 March 2022 (UTC)
Support The use of bullet points helps emphasize the "point" (pun intended) of the article being declined, versus just a straight paragraph of information. UrbanVersis32KB ⚡ (talk / contribs) 18:50, 20 July 2022 (UTC)
This basically says the the sourcing-GNG is the only way in. If you want it to be accurate you'd need to instead say that it's the best way in. (SNG's being the other).North8000 (talk) 19:07, 18 March 2022 (UTC)
I'm fairly sure SNG's basically just build off of GNG. If an article follows GNG it should also be following SNG's, and if it fails GNG I don't think it would be supported by SNG's. ― Blaze WolfTalkBlaze Wolf#6545 19:10, 18 March 2022 (UTC)
There are some SNGs that are alternatives to GNG, like WP:NPROF. We have a separate decline message for those (which in the case of an academic not showing notability, doesn't put enough emphasis on the SNG, but that's for another day). I don't think I've changed the meaning here from the old decline message. Femke (talk) 19:14, 18 March 2022 (UTC)
(edit conflict) That's a complicated topic. But the wiki standard is that a new article just needs to meet either the sourcing GNG or the SNG. Why use a different standard at AFC? North8000 (talk) 19:17, 18 March 2022 (UTC)
My concern with all of these versions is that they assume that the AFC reviewer correctly declined the submission, which is not always the case. I remember one BLP declined with this message, and when the editor inquired with the reviewer, the answer amounted to "Oops, nobody ever told me that WP:NONENG sources were okay." Presumably this is not the usual experience, but in that case, what was needed was just a re-submission (to get a reviewer who happened to know the actual rules) instead of adding more sources. WhatamIdoing (talk) 20:18, 21 March 2022 (UTC)
I don't see that as a problem with the text of these messages, but as a problem of screening / providing info for new reviewers. If I'm not mistaken, scrutiny for new reviewers has increased? A second solution to that problem would be to do random checks, and give feedback to reviewers when they make mistakes. Femke (talk) 20:27, 21 March 2022 (UTC)
I think there's a pretty significant ratchet effect at AFC. Nobody wants to be the reviewer who followed the long-standing written directions, because you could be accused of being a lax reviewer who is passing anything with a decent chance of surviving AFD (which is what the AFC directions say all reviewers should do, but...), and that's unpleasant. So the articles that get accepted through AFD are the highest quality ones, and that means the "normal" accepted article is very good, so you want to accept only articles that are better than average, so...
If the trend continues, then of course eventually we'd want to merge FAC and AFC, because the standards would be the same. I don't think we'll get to that point, but we're getting pretty high. Here are the five most recent articles accepted at AFC, with their ORES ratings:
The median rating for English Wikipedia's articles is "Stub". C-class and above is the top 10% of all articles. Why aren't most AFC articles also stubs at the time they're accepted?
Here are the five most recently declined drafts (I can't get ORES ratings for drafts, so I add my own comments):
Draft:Pop Danilo – 17th-century painter with a book for a source = would almost certainly survive AFD. Start-class.
Draft:Mini Me Dolls – No independent sources. Product likely non-notable. Barely Start-class.
So you can see, I hope, that I agree more often than I don't, but since two notable subjects were declined in this group, I suspect that the AFC reviewers are looking for a "nice" article or an "above-average" article, instead of an article that is likely to survive AFD on the grounds that the subject is notable.
This gap is what makes me wonder whether these instructions should be written more like ClueBot's warnings: Hey, this is just one person's opinion, and that person could be wrong, but that person thinks you need more/better sources. WhatamIdoing (talk) 20:43, 22 March 2022 (UTC)
From what I've seen so far, I think I agree about the standards at AfC being a bit too high. Maybe a reminder on WT:WikiProject Articles for creation about common mistakes? A change to the wording here is unlikely going to change that culture.
I'm open to make the reviewer more visible in the text. Do you have a wording proposal? Atm, I'm only able to come up with quite ugly long sentences. Something like "A volunteer has reviewed the draft. They determined that the references do not show that the subject qualifies for a Wikipedia article It semi-duplicates the "Title" of the decline message, which already gives the information that this is a decision by one person. Femke (talk) 20:51, 23 March 2022 (UTC)
@AssumeGoodWraith, I like that suggestion. If the AFCH script could automagically put the correct username in the link, then that would be terrific. WhatamIdoing (talk) 00:07, 25 March 2022 (UTC)
All of the pressure I've felt to be more strict has come from outside AfC (NPPs draftiying and coming to complain about my acceptance on my talk page, harsh AfDs, etc). No one's done anything wrong, in fact the criticism was often founded, but it's stressful enough to be on the receiving end of that I've been leaving some borderline accepts for another reviewer and generally tightened my criteria.
Though it should be noted that AfC as it was explained to me has as a criteria not "the draft will survive AfD", but "the draft will survive AfD on the strength of existing content", i.e. we explicitly do not do our own checks for sources or other notability criteria. That's a manpower problem, not a culture problem. Rusalkii (talk) 13:03, 24 March 2022 (UTC)
I'm a bit apprehensive about creating more work for reviewers. A large chunk of declined drafts are corporate spam, and those already take up quite a lot of reviewer time. Will they take up a disproportionate fraction of "appeals" too? If we want to tackle overly strict declines, I think a conversation needs to happen at AfC talk, not in these messages. Femke (talk) 17:24, 24 March 2022 (UTC)
@Rusalkii, I think it's a culture problem. First of all, AFD has never had a rule about "on the strength of existing content", so why would anyone impose that non-rule on AFC? WP:DEL#REASON says nothing like that, and the Deletion policy is unquestionably the one that matters at AFD. We should probably correct that AFC page.
Second, why should anyone be complaining on your talk page or posting harsh AFDs? Sure, if someone believed that the draftification of notable subjects is a way to improve visible article content (by hiding all the "bad" articles), or if they think it's a great way to extort extra edits from any interested editors, then I could see that it would be annoying to have someone disagree with them by supporting the long-standing, written policies and guidelines – but the problem is that other editor, and our culture ought to back you up for putting notable subjects into the mainspace.
Ditto for actual mistakes: All of us make mistakes, so all of us should respond with the same kindness and gentleness that we want to receive when we screw up. More relevantly than that, we have different interpretations and different knowledge. A subject that you think is "obviously" notable, because of your own outside knowledge, is one that might be WP:NEVERHEARDOFIT for me (which, you'll recall, is an invalid argument for deletion). So if I were to reject what you think is an notable subject, it would make more sense for me to at least wonder about whether you know what you're talking about, than for me to yell at you for daring to hold a different opinion. That's the culture change that I think we need: To assume that experienced editors who are following the written policies and guidelines are doing the right thing, even when the right thing means putting an "embarrassing" or "overly positive" article in the mainspace. WhatamIdoing (talk) 00:04, 25 March 2022 (UTC)
I think it important to note that an AFC “decline” is a temporary status, pending further improvement, and resubmission. Reviewers who decline are notrejecting the submission, they are merely stating that the article is not YET ready to be moved to mainspace. Blueboar (talk) 15:30, 28 March 2022 (UTC)
I have not read all the comments but I just want to make sure the notability guideline will link to the correct guideline based on the reviewer's selection as it does today. Also, the guidelines are different for WP:NCORP for depth (WP:SIGCOV vs. WP:CORPDEPTH) and independence of the sources (WP:INDY vs. WP:CORPIND) so that needs to be taken into consideration in the message. I agree the bullet-pointed message is better than we have to today because I think the relevant guideline is buried. S0091 (talk) 23:54, 1 April 2022 (UTC)
Oppose AssumeGoodWraith's proposal; Support Femke's version, as I like the WP:42-esque clarity. — Mcguy15 (talk, contribs) 18:05, 8 April 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
What if accounts are created by administrators
One day, I looked in the block list that there are many blocked newcomers and my propositions are: 1. Make an email adress to request for an account once the Create account button for unregistered (anonymous) users will be gone 2. Edits from newcomers (non-autoconfirmed users) will need moderation from automoderated users. Is this good for Wikipedia? CafeGurrier66 (talk) 15:18, 2 April 2022 (UTC)
There is already a method to request an account(WP:ACC). I'm also not clear on what your solutions actually have to do with the problem you describe. 331dot (talk) 15:21, 2 April 2022 (UTC)
There is also already a place for new/inexperienced users to seek a mentor (WP:AAU). 331dot (talk) 15:22, 2 April 2022 (UTC)
I am looking at an email adress to request for an account. This proposition can reduce vandalism as I want that the Create account option be removed so that accounts are created using an email adress CafeGurrier66 (talk) 15:25, 2 April 2022 (UTC)
It would increase vandalism, not reduce it. Vandals could use throwaway email addresses to obtain accounts over and over. 331dot (talk) 23:46, 2 April 2022 (UTC)
Making accounts harder to obtain would certainly deter some bad edits, but would also deter some good edits. We've discussed this several times and many editors support preventing anonymous edits. However, the consensus is that, on balance, we should keep the current process. Newcomers' edits can be made to await moderation using Pending changes but this is only applied to a few pages where vandalism has been a frequent problem. A current proposal to hide IP addresses may make unregistered vandals so hard to deal with that we are forced to limit editing to registered users, but details are still unclear. Certes (talk) 00:00, 3 April 2022 (UTC)
I thought this was more than a proposal- that they were doing it(the IP thing). 331dot (talk) 01:11, 3 April 2022 (UTC)
If I were detered from editing when I didn't even have an email account, I'd probably never create an account and edit here, as to me, it would've felt a bit hostile place. ---CX Zoom(he/him)(let's talk|contribs) 01:00, 3 April 2022 (UTC)
Yes, I have encountered IP editors in the past who did not want to create an account because they thought they were required to provide an email address. I've also encountered editors wishing to edit through an IP block but did not want to provide an email to request an account. 331dot (talk) 01:12, 3 April 2022 (UTC)
That's really a different issue, though it may result in a change to the level of IP vandalism which requires us to rethink our approach to allowing IP edits. Of course, if we choose to prevent anonymous editing altogether, the fancy new software to obscure IP addresses will never execute. Certes (talk) 12:16, 9 April 2022 (UTC)
Does Wikipedia have a button / option, as does for example Youtube, where you can invert colours so it's not as bright? I think it would be a big improvement to add it, if it doesn't have one. - Joaquin89uy (talk) 12:45, 31 March 2022 (UTC)
Yes! Thanks. It shouldn't need enabling though, it should appear to everyone from the get go, imo... (also it's a bit too dark, but that's a detail i guess lol). - Joaquin89uy (talk) 13:03, 31 March 2022 (UTC)
I agree that everyone including IP editors should also have access to the gadget, but I think we should hold this proposal until the default skin is switched to Vector 2022, as Dark mode doesn't go well with Vector legacy's (current default skin) sidebar and footer. ---CX Zoom(he/him)(let's talk|contribs) 13:40, 31 March 2022 (UTC)
Ah! I see. Thanx. Now I know. - Joaquin89uy (talk) 11:57, 4 April 2022 (UTC)
@CX Zoom There's no such known issue with dark mode in vector legacy. If you're seeing an issue, please post to WT:Dark mode (gadget) with details and screenshot. – SD0001 (talk) 14:45, 1 April 2022 (UTC)
Dark mode gadget used on Vector legacy on Android
@SD0001 Thanks for letting me know. I think this issue happens only when Dark mode is used in conjunction with Vector legacy on Android browsers (Chrome/Edge) (see the picture), which is the platform I most often use. After your comment, I used dark mode on Vector legacy on Edge on Windows to confirm, and yes it works perfectly fine there. Also, on Android, dark mode works perfectly with just any other skin but not Vector legacy. ---CX Zoom(he/him)(let's talk|contribs) 11:03, 4 April 2022 (UTC)
@Joaquin89uy and CX Zoom: the "dark mode toggle" gadget we have here is a community supported js/css gadget - a more official darkmode option is being tracked in : phab:T26070. — xaosfluxTalk 15:24, 31 March 2022 (UTC)
I'm just amazed that anybody finds that "easier on the eyes". Gives me a headache trying to make out the text.--User:Khajidha (talk) (contributions) 19:38, 7 April 2022 (UTC)
to your common.css. Let us know on the linked thread if it works. – SD0001 (talk) 08:13, 11 April 2022 (UTC)
Music genre discussion thread
I'd like a forum where you can post a song and have people discuss its genre. If this already exists, just link me to it. Wtoteqw (talk) 18:26, 2 April 2022 (UTC)
Not what Wikipedia is for. AndyTheGrump (talk) 18:47, 2 April 2022 (UTC)
Wtoteqw If you just want to discuss music in general, that's what social media is for. If you want to discuss how to classify Wikipedia articles about songs in terms of their genre(often a contentious business from what I see), you should use the article talk page of the relevant song's article. 331dot (talk) 01:14, 3 April 2022 (UTC)
Any discussions regarding statements about music genres on article talk pages must be based around what reliable sources say. We aren't the slightest bit interested in contributors own opinions... AndyTheGrump (talk) 03:31, 3 April 2022 (UTC)
@AndyTheGrump: To be fair, there are a shitload of arguments here about music genres, and even a special warning template for people who change them without citations. It's certainly one of the things Wikipedia is for... jp×g 06:53, 11 April 2022 (UTC)
Citing what actual experts say about genre (such as musicologists and music journalists) is useful at Wikipedia. Vanishingly close to 0% of the actual edits to articles that add or change genres to music articles actually bother to do so. --Jayron32 13:37, 12 April 2022 (UTC)
Diff colours
After years of squinting, I just became the 400th editor to fix the appearance of diffs so that added and deleted text is clearly visible. Is it time to change the default colours? Certes (talk) 14:15, 5 April 2022 (UTC)
Yes. I would have changed it for myself many years ago if I had known how, but that only affects one editor. Nearly all would benefit from a change to the default. Phil Bridger (talk) 14:49, 5 April 2022 (UTC)
@Certes I think several changes have been done to these, are you using Vector 2022 as your skin, it should have the "latest" updates. — xaosfluxTalk 14:58, 5 April 2022 (UTC)
Ah, you're right: I'm using Legacy Vector. (I prefer article text to occupy most of the screen, rather than just the bottom right corner.) The new skin does make diffs clearer than before, but small portions of deleted text are still hard to spot so I'll keep my CSS hack. Certes (talk) 18:16, 5 April 2022 (UTC)
mw:Visual diffs offers another way to look at it. The team never settled on a good color scheme, though, so I warn you that it's all intense red and green. Other aspects of the approach might be handy, though, and you can toggle back and forth between the two modes. It's in Beta Features, if you want to try it out. (It'll remember whichever mode you used most recently.) Whatamidoing (WMF) (talk) 19:56, 6 April 2022 (UTC)
Thank you, that's a useful backup for when I just can't spot the dot that's been replaced by a comma in the middle of a full-page paragraph. Certes (talk) 20:37, 6 April 2022 (UTC)
Follow up at CFD as needed. — xaosfluxTalk 11:05, 14 April 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.
I think those categories are misnamed.
"category:1:3 resonance" should be "category:1:3 resonance with Neptune"
"category:1:4 resonance" should be "category:1:4 resonance with Neptune"
"category:1:6 resonance should be "category:1:6 resonance with Neptune"
"category:1:9 resonance" should be "category:1:9 resonance with Neptune"
etc.
There are many resonances in the universe, those categories only apply to resonance with Neptune.
Perhaps, the is a wrong place for this discussion.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Make New Vector the default skin
NON-VIABLE IN THIS FORM
As Curbon7 says, someone could create a viable proposal for this idea, but this isn't it. Closing now before it becomes a timesink. CafeGurrier, please read WP:RFCBEFORE, which generally applies here even if you didn't label this as an RfC. Please also read WP:NOTAVOTE. More generally, please consider spending some more time familiarizing yourself with the community before diving in with WP:CENT-worthy proposals. -- Tamzin[cetacean needed] (she/they) 23:15, 15 April 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.
Some Wikimedia projects and Wikipedias uses the new Vector by default, should we have the new Vector set by default in the English Wikipedia. - CafeGurrier66 (talk • contribs) 19:14, 15 April 2022 (UTC)
@CafeGurrier66: just to clarify, default for ip editors and new editors? or for all users regardless? – robertsky (talk) 19:23, 15 April 2022 (UTC)
For all users, like in MediaWiki. Furthermore, it still can be changed in the user preferences. If you support, type in #Support if not, type in #Oppose. - CafeGurrier66 (talk • contribs) 19:29, 15 April 2022 (UTC)
Survey
Oppose – "Legacy" Vector has the advantage of using the right side of the screen for content, rather than inserting a sidebar like ad-infested websites do. If this changes then I'll just change it back in my preferences, but unregistered editors don't have this ability and occasional editors may not find it. Certes (talk) 22:41, 15 April 2022 (UTC)
Oppose Our friends over at French Wikipedia and a few other language projects have new vector enabled by default, so this could be a legitimate proposal if built correctly. However, I think the current proposal is skipping way too many steps to be tenable. Such a fundamental change likely needs pre-discussion to hash out elements like what specific wording will be used; seeing as the current proposal is incredibly confusing, it's obviously that hasn't happened yet. I would not necessarily be opposed in principle to this proposal in the future (though I would still oppose as I find new vector to be unwieldy), but there are a lot of steps still needed to get this to the point of broad community discussion. Curbon7 (talk) 23:02, 15 April 2022 (UTC)
Discussion
My attitude to change is very much of the "if it ain't broke then don't fix it" school. Could someone please tell us what is broke in the current default, and how this proposal fixes that? Please note that I do not accept that the statement, "some Wikimedia projects and Wikipedias uses the new Vector by default", contributes anything useful to this discussion. Phil Bridger (talk) 21:01, 15 April 2022 (UTC)
To those who feel the need to change things… please change broccoli. Blueboar (talk) 22:49, 15 April 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposal to change portal links on the Main Page
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.
There is a clear consensus to remove the portal links from the top banner and center-justify the Welcome to Wikipedia message (1) and to move the link to the portals contents page to the Other areas of Wikipedia section lower on the Main Page (2). Some editors expressed a concern about the wording of "Content portals – A unique way to navigate the encyclopedia" as part of 2. There was enough support in the RfC that this language can be used when initially implementing these results, but further discussion/editing may lead to superior wording (with no subsequent RfC required to change it).
There is a weak consensus to add the language switcher button to the newly freed space in the upper right corner (3). Many editors did not mention this element of the proposal, with most focusing on the portal elements, while among those who did there were decidedly mixed feelings. Concerns expressed included questions about whether this tool should be so prominently displayed and technical concerns about implementation. These technical concerns should be taken seriously as this RfC is implemented and it may be discovered that subsequent discussion, or a follow-up RfC, is needed around the language switcher.
A few editors also expressed procedural concerns about this RfC, suggesting it lacked neutrality. There was some pushback on this noting that the RfC question asked was neutrally phrased and to the extent that the background was not neutral that it was located after the neutrally phrased question. This latter view is supported by WP:RFCNEUTRAL and given the use of the RfC tag, the holding of the discussion at a prominent location (a Village pump), and the inclusion of the discussion at CENT, there appears to be insufficient procedural reason to not honor and implement the consensus found in this discussion. Barkeep49 (talk) 19:45, 14 April 2022 (UTC)
Should the proposal to change portal links on the Main Page described below be adopted? {{u|Sdkb}}talk and JBchrchtalk 01:19, 15 March 2022 (UTC)
Current location of the portal links on the Main Page
Wikipedia's portals have long suffered from low readership and poor maintenance. There have been numerous efforts to curtail them in recent years, some of which garnered substantial support, and the community has chosen to delete many hundreds of unmaintained or unread portals. In contrast to this tenuous state, portals enjoy extremely prominent positioning at the top of the Main Page, where eight of them and the portal contents page is linked in the very top banner, above even the TFA and ITN. The specific portals receive only 2000–5000 pageviews per day, less than well-performing DYK hooks which appear much farther down and often more briefly. The portals contents page does marginally better, with a daily average of 11,800 views.
Last October, JBchrch made a proposal to remove the portal links from the Main Page, per the web usability principle that underutilized links should be cleared out to reduce clutter. It received 30 !votes in favor and 17 opposed, but was closed as no consensus because it did not offer clear-cut choices and thus did not manage to elicit clear-cut responses. After discussion on the closer's talk page and a challenge at the administrators' noticeboard, the close was left standing. Last month, the closer launched a follow-up discussion asking broadly whether the display should be kept or changed, but it was withdrawn after procedural objections in part about its lack of specificity. {{u|Sdkb}}talk 01:19, 15 March 2022 (UTC)
Proposal
We propose the following related changes:
Remove the portal links from the top banner and center-justify the Welcome to Wikipedia message.
Move the link to the portals contents page to the {{Other areas of Wikipedia}} section lower on the Main Page, adding Content portals – A unique way to navigate the encyclopedia.
Add the language switcher button to the newly freed space in the upper right corner.
Mockups
Top banner proposal: portals links removed and language switcher added
Support as co-proposer. Our Main Page should not be featuring so prominently links that are barely ever used, that don't represent our best work, and that clutter its design. The other areas section is a suitable new home for the portal contents page, offering a middle ground that allows us to avoid complete removal. The language switcher is a helpful feature for the Main Page that will fit nicely in the newly freed space. {{u|Sdkb}}talk 01:19, 15 March 2022 (UTC)
Support as co-proposer. The proposed changes are an improvement on the current design of the main page. They modernize the interface by cutting down on bluelinks and helping the reader focus on more representative parts of the project, such as TFA. The language switcher is not only a functional tool, but also serves as a symbol for the global nature of the Wikipedia project. Access to the portals is relocated in a manner that's proportional to their importance and readership. JBchrchtalk 01:53, 15 March 2022 (UTC)
Support looks good and cleaner. We could increase the size of "Welcome area" to lessen white area.Moxy- 02:00, 15 March 2022 (UTC)
Support, the "Welcome" message is centered which looks much nicer, and having a language switcher front and center when a user goes to the main page of Wikipedia can be very helpful. I only have one critique and that is how the language switcher looks, however it's very minor and not that jarring compared to how much nicer the main page looks in the mockups. ― Blaze WolfTalkBlaze Wolf#6545 02:12, 15 March 2022 (UTC)
Support It looks nicer, more professional, and more modern. Plus, Portals should not be the focus of readers. We have a lot better work to show off. CaptainEekEdits Ho Cap'n!⚓ 02:33, 15 March 2022 (UTC)
Support, I like the new proposal, and portals, while an interesting idea for their time, just never really have quite worked out. SeraphimbladeTalk to me 03:27, 15 March 2022 (UTC)
Support, whatever the importance and relevance of portals, it is certainly not enough to warrant the prominence of their current inclusion. Having our welcome and main title pushed so far to the left (so close to the icon!) is unproductive and generally bad design. This is a definite improvement. Aza24 (talk) 03:47, 15 March 2022 (UTC)
@Aza24: It doesn't push it over at all. Try viewing at (say) 1280px wide (or zoom out a few steps) - there's a big gap between the three "Welcome to Wikipedia," lines and the three rows of portal links. --Redrose64 🌹 (talk) 09:26, 15 March 2022 (UTC)
@Redrose64: I was referring to the literal Wikipedia logo (the globe) in the corner being so close to the "welcome to wikipedia", making both feel redundant. Since I am on a standard laptop, viewing the page as many people do, if I have to adjust my screen to see a more desirable layout, that is an issue. Aza24 (talk) 23:16, 15 March 2022 (UTC)
I don't mean that you should zoom out permanently - just long enough that you can see that no pushing is going on. --Redrose64 🌹 (talk) 21:15, 16 March 2022 (UTC)
??? By pushing, I mean the existence of the portals prevents the "Welcome to Wikipedia" from being in the middle, and thus pushes it to the left by necessity. Aza24 (talk) 02:01, 6 April 2022 (UTC)
With MonoBook skin, on narrower screens (less than 892px wide), it automatically rearranges so that the portal list is rearranged horizontally (like a WP:HLIST) and is entirely below the three lines of which "Welcome to Wikipedia" is the first. This doesn't happen in Vector. --Redrose64 🌹 (talk) 18:08, 6 April 2022 (UTC)
Actually, maybe it would be best to change the wording on the other areas as "Navigate the encyclopedia by topic". Still support whatever phrasing ends up gaining consensus. A. C. Santacruz ⁂ Please ping me! 10:23, 15 March 2022 (UTC)
Support, looks much better. Cavalryman (talk) 09:49, 15 March 2022 (UTC).
Strong support: this is mostly a formality after the previous discussion, and my comment in that discussion still stands. I also agree with much of what others have written. — Bilorv (talk) 10:26, 15 March 2022 (UTC)
Support: I can maybe add something here insofar that I would like to say that as a fairly long-time reader / passing visitor, I don't recall a single instance of my having clicked any of these portal links before today. This seems like a clear improvement and may even result in these pages functionally becoming more visible to people looking to learn some more about this place, as this proposal would group them up with some of the more dynamic starting points for doing that. Dr. Duh 🩺 (talk) 10:39, 15 March 2022 (UTC)
Support portals aren't used that much, and don't need to feature so prominently on the main page. Joseph2302 (talk) 10:42, 15 March 2022 (UTC)
Procedural oppose. Per my extended comments below, this RFC is extremely non-neutral and so invalid. Thryduulf (talk) 12:43, 15 March 2022 (UTC)
I also oppose on the merits. This proposal would significant inconvenience thousands (at least) of visitors without bringing any benefits to those people who do not use the links, nor does the vague proposal to replace it with nothing or a language switcher come remotely close to providing a similar benefit to a similar number of people. Thryduulf (talk) 17:27, 17 March 2022 (UTC)
Procedural oppose and speedy close per Thryduulf. This proposal is rehashing a proposal already made last autumn, and which had no consensus because it didn't propose a clear alternative. We asked you to explain how the space freed up by the portal removal would be put to better use, and this has not been answered. Please come up with a concrete proposal, and we can consider it. — Amakuru (talk) 12:47, 15 March 2022 (UTC)
Just to add to this, and what I think would make the difference, would be to move the line about "the free enyclopedia that anyone can edit" and the article count over to the right-hand side, while leaving "Welcome to Wikipedia" on its own on the left, and then reduce the overall vertical space of that banner so that the featured sections of the main page are more prominent on first load. I'd support removal of portals if a benefit like that could be demonstrated, but not otherwise. Adding the language dropdown and moving the welcome banner to the centre just makes the issue worse, IMHO. Why are links to foreign-language sites which are external for us more useful to a reader than portals, which are gateways into our own content? Doesn't make sense. — Amakuru (talk) 12:53, 15 March 2022 (UTC)
You are of course free to express a view on the proposal, but I would ask you to please not convert it into a procedural argument. This proposal is materially different from the two previous discussions and is not a rehash. Your advice that efforts should be concentrated on the creation of a new, consensual [1][2] and specific [3] proposal was not overlooked, I can assure you of that. The design approach adopted here may not be exactly the one you suggested (there were many), but that does not invalidate the proposal from a procedural standpoint. JBchrchtalk 14:56, 15 March 2022 (UTC)
Weak support. Those portal links get a surprisingly high amount of traffic for static links. Perhaps not enough to justify being right at the top of the page, but enough to be on the page somewhere. Nevertheless this proposal does improve the design and I expect the language button would get more use than the current portals list does. Three caveats:
If we put a language button in such a prominent location, we should remove the 'Wikipedia languages' section at the bottom of the page, to avoid duplication.
The 'unique way' wording is poor and uninformative. I would prefer something like 'browse by topic' or 'content organised by topic' (though the latter has ENGVAR issues).
Implementation clearly has to wait until the language button has been thoroughly tested and is ready for millions of users. The page on Meta still refers to May 2021 as if it's in the future, so is presumably very out of date.
Support as an incremental improvement over the status quo, per nom and other support voters above, and per my comments and others' in the last RFC as to what's wrong with the status quo (low clicks, prime screen real estate, etc.). I also support Amakuru's suggestion to, instead of having the language toolbar, move the logo to the left and the tagline to the right, and reduce the vertical size of the entire grey box at the top. That would be another incremental improvement. I see no problem with the neutrality of the RFC statement, the "proposal" section, or the "background" section (and the last one doesn't need to be neutral anyway, as it's just an extension of the proposer's proposal). Levivich 20:32, 15 March 2022 (UTC)
Support anything to get the portal links off the top of the page, even though I agree with the Modest Genius about the misuse of the word unique in the proposal. I don't care what happens with the language switcher. I also agree with Levivich in saying that this RFC isn't unreasonably, deceptively, or confusingly non-neutral. Perfection is not required in an RFC question. WhatamIdoing (talk) 03:50, 16 March 2022 (UTC)
Strong support - a solid step in the right direction. Cleaner, clearer, more useful. Good point from Modest Genius regarding making sure the language button is 100% ready before this is implemented. Retswerb (talk) 05:07, 16 March 2022 (UTC)
SupportGood idea but procedural oppose Biased RFC, and respecting the process matters. Suggest a do-over because this is a good well founded idea.North8000 (talk) 13:11, 16 March 2022 (UTC)
This clearly has become the RFC and so I'm striking my procedural oppose in order to to comment on it. With the evolution of search, portals are not a used way to find info and so disproportionate emphasis on the main page should be corrected. North8000 (talk) 13:16, 12 April 2022 (UTC)
Support Given most of the previous blockers to actually doing anything have been satisfied. I fully expect more goalpost moving however - its getting to the point of being actively disruptive. Only in death does duty end (talk) 13:29, 16 March 2022 (UTC)
Support in any form, though I concur with adjusting the description to be more informative and to match the rest of the box, for example Portals –Topic-by-topic overviews of Wikipedia's content.Ninepointturn (talk) 15:11, 16 March 2022 (UTC)
Support in theory though I think the execution is a little off. I'd prefer the "Welcome to Wikipedia" bit be larger to fill some of the white space. The language menu seems out of place too. Calidum 21:55, 16 March 2022 (UTC)
Support. Basically, though not the fine details. The portal links space is quite unjustified, and improvements to the Main page should proceed without a requirement for a Village Pump RfC written-in-stone detail for every increment. Yes, move the Portal links as proposed. However, do not lock in decisions on a "language switcher button" or the "unique way" wording that needs copy-editing. In 5 seconds I suggest "Contents portals for navigation", but after typic it am leaning to "Contents portals". If portals do have value, why would the link have to explain them? --SmokeyJoe (talk) 04:38, 17 March 2022 (UTC)
Support - can be twiddled in the details, but moving portals out of the prime real estate makes sense all round. I like the the language selector up top, but that's definitely secondary to getting the under-maintained portals out of the spotlight. --Elmidae (talk · contribs) 14:03, 17 March 2022 (UTC)
Support - there's value in whitespace -- not every pixel has to be filled. That said, I'm not a huge fan of the "unique way" wording -- a content directory by category is hardly unique and has been a web staple for 25 years (see DMOZ or Yahoo! Directory). --Ahecht (TALK PAGE) 15:14, 17 March 2022 (UTC)
Support Frankly I would like to see Portals go the way of the dodo and the Book: namespace, but this is a step in what I believe is the right direction casualdejekyll 01:16, 18 March 2022 (UTC)
Support with the caveat, mentioned by others, that the wording on the new Content portals blurb could be improved. Ganesha811 (talk) 20:05, 19 March 2022 (UTC)
Support moving Portal links from top of Main Page. The new grey banner with language switcher looks more modern. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:56, 20 March 2022 (UTC)
Support Long overdue. --Jayron32 13:30, 21 March 2022 (UTC)
Support If it's moved somewhere, then sure. --99.227.9.86 (talk) 17:00, 24 March 2022 (UTC)
Support per previous discussions. I'd rather they be removed entirely but this is a step in the right direction. SnowFire (talk) 03:40, 26 March 2022 (UTC)
Support per previous. No objection to iteration on the wording in the "other things you can do" part of the main page. The language switcher may or may not come (hopefully it does). I am happy to implement on the main page if/when this is closed in support of the change. --Izno (talk) 17:21, 27 March 2022 (UTC)
Support looks better, cleaner, and the language switcher would help users access other languages easily. Itsquietuptown✉️📜 02:05, 29 March 2022 (UTC)
No, the language switcher makes other languages harder to access: they'll be two or three clicks away rather than one. I understand the desire to prevent readers from discovering portals and congratulate the supporters on their tenacity in finally making them invisible, but replacing them by the language switcher would just make another useful feature less accessible too. Certes (talk) 11:50, 29 March 2022 (UTC)
The language switcher is coming whether we want it or not, though whether it takes this form on the main page is an open question. See phab:T293470. Izno (talk) 19:37, 29 March 2022 (UTC)
Comment - After the end of this RfC, I suggest individual discussion about the language switcher button. I didn't see clear benefits for readers in replacing links to portals per links to other Wikis. If the initial goal was a clean layout, this change doesn't make much sense.Guilherme Burn (talk) 19:41, 29 March 2022 (UTC)
Seconded. Part of the case for removing the portal links is that the space is needed for something else, and the language switcher is a convenient "something else" to propose, but we should only adopt it if it's beneficial, not just to fill space. Certes (talk) 21:59, 29 March 2022 (UTC)
So, I Support P1 per Background cited. Weak Support P2, Analyzing the most popular portals Massviews , without the main page portals, I realize that the portals have an excellent potential for a “not encyclopedically rigid content”. This is good, instead of a link to the monotonous Content portals it could be a link to a new Portal:portal page, more visual, free and fun. And Oppose P3, the language switcher button doesn't look better to me than a blank space.Guilherme Burn (talk) 19:13, 7 April 2022 (UTC)
Support: About the same view as SmokeyJoe and others. The portal links should be removed from such a prominent place, the language switcher looks kind of awkward, and we really don't need to be so extreme about proposal wording or process in order to make changes. Sdkb: when will this discussion be closed? --MZMcBride (talk) 05:32, 30 March 2022 (UTC)
The standard RfC length is 30 days. I could see an argument for closing when it's snowing this heavily, but given the impact, I could also see an argument for letting it run its course just to be sure there's no doubt. Whatever the uninvolved closer prefers is fine with me. {{u|Sdkb}}talk 07:52, 30 March 2022 (UTC)
Support: We can better use the space at the top of the page than linking to portals. Allowing readers to change to a different language edition without having to scroll down is one possibility.-gadfium 07:36, 30 March 2022 (UTC)
Support -- It looks to be a well founded proposal to me. -- Dolotta (talk) 22:39, 31 March 2022 (UTC)
Oppose I disagree with the notion of removing the list of portals entirely from the main page. I agree the language changer should be added, but the links to the separate portals should be retained lower in the page. — Mcguy15 (talk, contribs) 01:48, 6 April 2022 (UTC)
To add, DYK is dynamic and uses sentences to specifically entice readers to click on the articles. Making the comparison to DYK pageviews is not equivalent. They serve different purposes, and the portal page views are certainly substantial and shouldn't be tossed aside. — Mcguy15 (talk, contribs) 01:51, 6 April 2022 (UTC)
Oppose, a conclusion I come to rather to my surprise. I have barely used portals myself and never edited any of them and came into this debate thinking I was going to say support: portals have stagnated compared to other areas of Wikipedia and the required quality of portal content is far below DYKs and especially ITN and FA items. But examining them I think here we run into the question of what people want to use Wikipedia for: I think it's a legitimate use case that someone, especially younger editors and people without a very extensive education, comes onto Wikipedia without really knowing what they want to look for but knowing they want to know more about (say) history and explore Wikipedia's articles on it. When I want to look for something I normally know what article I'm looking for and if I don't I keyword search. I imagine that's true of a lot of older editors. But I think there will be users for whom this isn't the case, who haven't had a full education, who want to browse the diversity of articles Wikipedia has on a topic without really knowing what they want to look at. Blythwood (talk) 04:05, 6 April 2022 (UTC)
Support. Portals are just generally low-quality and don't reflect how Wikipedia is used today; we should be sunsetting them completely on every level and at every opportunity. The argument that people are somehow still using them in significant numbers or that they somehow provide some sort of useful function seems entirely speculative, while their low quality is obvious at a glance. Worse, their very nature tends towards WP:OR and WP:SYNTH - they date back to a much older time when the idea of having such "conversational" things that essentially use their structure to educate readers in the voice of editors was not so clearly unacceptable. Complete removal from the main page would be ideal and should still be pushed for in the long term - even the "other ways to navigate" isn't ideal; portals should not be linked anywhere at all in any context and should ultimately be tagged as depreciated, since they no longer reflect or fit into the goals of the project - but this is at least a vast improvement over the current situation. --Aquillion (talk) 07:25, 8 April 2022 (UTC)
Oppose. I'm clearly out of step with the community on the question of portals, but I genuinely dislike the proposed design. I don't think including the language picker is a good idea at all: it's not in the matching style, gives a very difficult to use way of navigating to a different language, isn't something that many readers reaching the English Wikipedia are likely to want to use, and would give three different ways of accessing different language versions. It feels like an ill-thought-out dummy item to address the objections in the previous RfC to replacing portal links with blank space. I also much prefer a left-aligned welcome message. Espresso Addict (talk) 02:12, 9 April 2022 (UTC)
Support I do not believe portals should be featured so prominently, though I do strongly believe they should be retained. The language switcher is to me a great idea; I find the current way of switching between languages to be quite cumbersome. Ljgua124 (talk) 09:14, 12 April 2022 (UTC)
Support - It looks more professional. I don't believe portals are important enough (they're still important!) to be one of the first things a reader sees when they open Wikipedia. — Goldencall me maybe? 10:33, 13 April 2022 (UTC)
Discussion (Portal links)
This RFC has one of the least neutral background statements I've read in a long time with lots of value judgements and disputed statements such as:
Wikipedia's portals have long suffered from low readership - this has been disputed in every discussion about portals on the main page, with the figures used by those claiming this actually demonstrating the opposite.
There have been numerous efforts to curtail them in recent years, some of which garnered substantial support and all of which also garnered substantially opposition and none of which achieved consensus to curtail them.
the community has chosen to delete many hundreds of unmaintained or unread portals. True but completely irrelevant to the portals on the main page.
In contrast to this tenuous state what tenuous state?
portals enjoy extremely prominent positioning at the top of the Main Page, where eight of them and the portal contents page is linked in the very top banner, above even the TFA and ITN. There is no neutral explanation of why this is seen a problem?
The specific portals receive only 2000–5000 pageviews per day, less than well-performing DYK hooks which appear much farther down and often more briefly. The portals contents page does marginally better, with a daily average of 11,800 views Once again, there is no neutral explanation of why this is a problem.
Separately, the Desktop Improvements Team has introduced a new button for switching between language editions, and has been discussing on Phabricator how it might appear on Main Pages. So?
Last October, JBchrch made a proposal to remove the portal links from the Main Page, per the web usability principle that underutilized links should be cleared out to reduce clutter. It received 30 !votes in favor and 17 opposed, but was closed as no consensus "because it did not offer clear-cut choices and thus did not manage to elicit clear-cut responses." And also because there was no consensus that there was a problem that required solving.
Given all of this, I'm not convinced that this RFC can be seen as valid. Thryduulf (talk) 12:42, 15 March 2022 (UTC)
I'm not going to try and dismiss your comment, however you have said that it's not neutral, but haven't attempted to show how it could be made neutral. ― Blaze WolfTalkBlaze Wolf#6545 13:52, 15 March 2022 (UTC)
I'm not the one making the proposal, so it's not my job, but it would need to be completely rewritten without the emotive language, without the irrelevancies and based completely on undisputed facts, with a clear statement of what problem has been identified, why that is a problem (again based on facts and acknowledging that everything subjective is disputed), what is being proposed to fix this problem and how this fix will be an improvement. It is not possible to make this neutral with small tweaks. Thryduulf (talk) 14:58, 15 March 2022 (UTC)
Alright then. I was merely saying that because I feel that showing exampled of how it could be made neutral might help with making it more neutral in the future if this is indeed closed due to not being neutral. ― Blaze WolfTalkBlaze Wolf#6545 15:00, 15 March 2022 (UTC)
The proposal itself is neutral… the “background” section is not. Would it help to move that into the survey? Blueboar (talk) 15:56, 15 March 2022 (UTC)
Not really to be honest as it's already irrevocably invalidated this RFC and even if that weren't the case it would be inappopriately long and out of place in the survey section. It would be distinctly odd at best in the discussion section given that it's written to be a background to the RFC not a response to it. Thryduulf (talk) 18:19, 15 March 2022 (UTC)
meh… It represents the nominator’s opinion of what led up to this RFC, and so is a factor in explaining his/her opinion as to the outcome. If you think it is flawed, you can always write an “alternative-background” expressing your take on the situation. In any case, I do think that the basic question was neutral. Blueboar (talk) 19:02, 15 March 2022 (UTC)
There is no requirement that any remarks posted by the OP be neutral beyond the initial question.
Also, I think it's important not to fetishize neutrality for proposals. If you're proposing a major change, you should be in favor of it. You should not waste our time with a proposal that you oppose or that you don't care about one way or the other. WhatamIdoing (talk) 03:45, 16 March 2022 (UTC)
They've given their remarks highly prominent positioning above the actual proposal. Normally when starting an RfC, people put their arguments in the survey section. Chess (talk) (please use {{reply to|Chess}} on reply) 14:19, 20 March 2022 (UTC)
If they put exactly the same words under ===Survey=== instead of under ===Background===, their words would still have "highly prominent positioning". The RFC question (=the thing that needs to be neutral) is "Should the proposal to change portal links on the Main Page described below be adopted?", and that's above both the ===Background=== and ===Proposal=== subsections. WhatamIdoing (talk) 20:14, 21 March 2022 (UTC)
I have to agree that this is a manifesto rather than an RfC. To pick just one point, I don't see how only and 2000–5000 pageviews per day belong in the same sentence. That's about a million visits annually for each portal. Do we really want to frustrate that many readers? (The proposal's title suggests that adding a language button isn't the main goal.) Certes (talk) 23:32, 15 March 2022 (UTC)
The main page gets 5.5 million daily views (that's over two billion a year). I don't think our readers will be frustrated if we move links that are clicked on less than 0.05% of the time (1 million out of 2 billion). Levivich 14:42, 17 March 2022 (UTC)
The issue is that we would be inconveniencing the readers who use the links without providing any benefit for those that don't. Thryduulf (talk) 17:24, 17 March 2022 (UTC)
Of course it would provide a benefit to those that don't (declutter, more attractive interface, etc.), otherwise why would so many of your colleagues support it? Levivich 17:45, 17 March 2022 (UTC)
If something is clicked by 0.05% of visitors, there is a not-unreasonable chance that half that traffic is bottraffic which we are unable to detect as bot traffic... We know that ppl use proper user agents for their bots and we thus have undetected bots. And if I wrote a bot, I too would start by going through all the links on the main page, so anything linked from the main page has a high chance of getting such automated traffic. The point being that it is very hard to estimate if such traffic is significant, without looking at several other elements listed. —TheDJ (talk • contribs) 14:46, 29 March 2022 (UTC)
I think that, given the fairly overwhelming nature of the consensus so far, it is extremely unlikely that changes to the wording of the RFC could shift the result enough to alter the outcome. Especially given that this concern was raised early on and has clearly failed to sway participants, it feels like procedural stonewalling to object to such an overwhelming RFC result on procedural grounds - it's pretty obvious from the discussion here that the position of portals on the main page is not sustainable. Asking for another month-long RFC with different wording just so it can inevitably reach the same result is not reasonable. --Aquillion (talk) 07:37, 8 April 2022 (UTC)
@Sdkb and JBchrch: do you have a screenshot of what the new design will look like in Mobile wikipedia? Would be interesting to see where and how much space the language switcher would take. The current one has portal links after the welcome block and takes up 10-15% of screen height. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 08:37, 20 March 2022 (UTC)
@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, for the portal link farther down, you can go here on mobile. I don't have a mobile screenshot of the top, but I'm sure someone else could make it fairly easily. {{u|Sdkb}}talk 18:08, 20 March 2022 (UTC)
Question: I haven't seen this "language switcher" in action. Do I understand that this dropdown will have 300+ entries? Can we see a copy in motion? That sounds difficult to use... BusterD (talk) 18:12, 6 April 2022 (UTC)
@BusterD, go here, and you'll be able to test out the switcher (you can also change your skin to Vector 2022 here; it includes a bunch of other modifications which are not part of this proposal). {{u|Sdkb}}talk 18:20, 6 April 2022 (UTC)
You can see the language switcher top right on any article of Portuguese Wikipedia, though it has been moved to bottom right on the main page. It was also on other Wikipedias such as French but seems to have been removed. Certes (talk) 18:21, 6 April 2022 (UTC)
Thanks, folks. Any special reason fr.wikipedia dropped the switcher? I don't like it for lots of reasons but partly because it's unlike any other visual element on the page. 300+ entries on dropdown seems ridiculous and unweildly. I still think this is a solution is search of a problem, but that position has been discounted by those who just don't like portals... BusterD (talk) 18:30, 6 April 2022 (UTC)
One version of the language switcher had only a few popular languages appear initially, and revealed a further button to show the full set. I don't know why frwp removed the switcher, though I agree with their decision. There was an intermediate version where frwp main page looked like ptwp does now, i.e. frwp tried the language switcher top right, then moved it to bottom right before removing it completely. The language switcher is worth considering but we mustn't adopt it simply as an excuse for hiding portals; that proposal seems to be passing without the need to find something to fill the resulting gap. Certes (talk) 20:29, 6 April 2022 (UTC)
Although I expressed support to remove Portal links from the top, I think they deserve a separate section towards the bottom, with somewhat detailed explanation, say, "Explore the world of Science, visit the Science portal (newline) Other portals: (there goes a brief list), (then comes) [link:See all portals]". The portal name on the first line will be shown at random using {{random item}}. Thoughts? —CX Zoom[he/him](let's talk • C • L) 14:06, 7 April 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Wikipedia Needs to Support Ukraine
OP blocked, nothing to see here--Jayron32 14:35, 20 April 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.
As we all know, there is currently a terrible war in Ukraine. I think that the Wikipedia should immediately change the colour scheme of it's layout to Blue and Yellow (These are the two colours on the flag of Ukraine, for those who may be unaware) in support of Ukraine. What do you all think? The140IQProfessor (talk) 19:12, 18 April 2022 (UTC)
As much as I agree that support on ukraine is needed, Changing the cholor scheme is way too much of a change, and wikipedia is designed to be neutral. On wikipedia, we do not choose "Sides" of anything, We simply list the facts, no matter what they are. Also a color scheme change would require a LOT of program adjustments and would be too complicated. PerryPerryDTalk To Me 19:21, 18 April 2022 (UTC)
Bawl with the background set to File:Flag of Ukraine.svgThe140IQProfessor, seems like a bit too much, but I actually thought about something along these lines for my script, Bawl. Essentially because of this I added a custom background option to show your support for something. Originally it was going to be just the flag of Ukraine, but being customizable made more sense in the end. Set Flag_of_Ukraine.svg as the background image in the options and you'll get this. (see image) — Alexis Jazz (talk or ping me) 19:47, 18 April 2022 (UTC)
I think that people need to stop trying to rebrand Wikipedia as a soapbox, no matter how strong, and seemingly justifiable, their moral conviction is. 65.88.88.93 (talk) 20:27, 18 April 2022 (UTC)
Many people on Wikipedia have been actively supporting Ukraine recently. Myself and numerous others I know of have been prolifically active in improving content related to Ukrainian culture, people and topics. This is a venue that is quite literally available to everyone, and results in meaningful content being made! Perhaps explore this route, rather than imposing personal guilt onto others. Aza24 (talk) 20:40, 18 April 2022 (UTC)
The TS has been blocked as a sock, so I do not think we should discuss this seriously.--Ymblanter (talk) 20:47, 18 April 2022 (UTC)
Also we literally just went through this kit-and-caboodle a few weeks ago with the Signpost "scandal" lol. Curbon7 (talk) 11:54, 19 April 2022 (UTC)
Oppose: @The140IQProfessor: Also, you are already blocked as you are clearly not here to contribute to build the encyclopedia. - CafeGurrier66 (talk • contribs) 10:41, 20 April 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
"Sibling networks" definition
I’ve seen various television network pages having related networks featured on the infobox, but is there any sort of definition or requirements that these should be added. With some of Warner Bros. Discovery-owned television networks, there hasn’t been any clear guidelines for what should be listed there since it’s combining two companies that own a lot of networks that some of them overlap in the genre or theme that the networks have, which can cause some confusion. Hopefully any input here can clarify everything. Thanks Paramount1106 (talk) 02:19, 16 April 2022 (UTC)
I think, in general, just rely on the same terminology at use in your source texts. If source texts widely describe two entities as "sibling networks", and the evidence is clear that the usage is widespread and commonplace, then feel free to do the same for those two entities. If the terminology is not widely used, or even more relevantly, if you can't find clear and abundant examples describing two specific networks that way, don't use the terminology. --Jayron32 14:37, 20 April 2022 (UTC)
Create a short-cut for Wikipedia:Long-term abuse/Xayahrainie43
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.
Xayahrainie43 is too long to type and remember, I proposed to create a short-cut for them as WP:LTA/X43, this name came from Chinese wikipedia and also used on meta-wiki for SRG. PAVLOV (talk) 09:43, 20 April 2022 (UTC)
Not every sock master is an LTA. And LTA pages should by and large be deprecated. CUPIDICAE💕 12:24, 20 April 2022 (UTC)
Support. This will be helpful for hard and/or long usernames. - CafeGurrier66 (talk • contribs) 16:17, 20 April 2022 (UTC)
I can't think of any potential conflicts or confusions. If you think it's the most appropriate shortcut, I'd say just go ahead and add it. -- zzuuzz(talk) 16:36, 20 April 2022 (UTC)
Done Thanks a lot for approval. PAVLOV (talk) 16:58, 20 April 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Fortis and lenis are both terms that have inconsistent definitions and are rarely used in comparison to voiced/voiceless in every context, it seems, other than Wikipedia pages for phonology; this is needlessly confusing and voiced/voiceless should be enforced over them. There are two different reasons one may argue against this proposition. Firstly, one might say that fortis and lenis mean voiced and voiceless themselves. In this case, fortis and lenis, as the rarer terms, should not be used for the sake of recognition. Otherwise, one may propose an alternative definition for fortis and lenis; it is the strength of a consonant, or the length, possibly something even more exotic. These simultaneous arguments, when viewed together, show why this fails; there is no consistent definition of fortis and lenis! In fact, there exist consonant inventory tables which use fortis and lenis in place of voiced and voiceless, despite the fact that plenty of pages for phonology, including Portuguese phonology and Spanish phonology, are entirely comprehensible without mentioning either word once, even in their many sources. In conclusion, fortis and lenis are dated and ambiguous terms that should be replaced with voiced and voiceless. Additionally, I might add that unvoiced should be replaced with voiceless in every linguistic context due to the fact that they are synonyms and voiceless is much more prevalent, but this proposition is not relevant at the moment. (This has been moved to Wikipedia talk:WikiProject Linguistics#Standardise voiced/voiceless over fortis/lenis)
(I'm not sure if this is a proposal or a policy suggestion) — Preceding unsigned comment added by 169.241.63.173 (talk) 18:25, 21 April 2022 (UTC)
Ok, should I remove it from here once I post it there? 169.241.63.173 (talk) 20:35, 21 April 2022 (UTC)
Yes, you can just copy your post to Wikipedia talk:WikiProject Linguistics, and then either remove the whole of this thread here or leave it in place with a pointer to the other discussion. – Uanfala (talk) 21:56, 21 April 2022 (UTC)
So you're a child and want to look up Anaheim, California because Disneyland. You go to Wikipedia on your mobile device, enter "ana" in the search box and are instantly presented an image of a penis in an anus. That's.. rather inappropriate. The issue has been reported on Phabricator, but you know the response time of the WMF is typically measured in years. Maybe the thumbnails can be disabled with a configuration change, but if not there's always CSS. See screenshot for an example, the file page description has some CSS to play with. Proposal: we disable thumbnails in ajax search results where we can until the search learns to respect MediaWiki:Bad image list. — Alexis Jazz (talk or ping me) 17:22, 18 April 2022 (UTC)
Wait, you want us to make a local script-hack to disable all images on search results? No thank you, follow up at phab. — xaosfluxTalk 17:41, 18 April 2022 (UTC)
Xaosflux, if there's configuration option for this that would be used instead, but if there isn't, well, what other way is there? And hey, when phab:T306246 is resolved it can be re-enabled. Maybe enwiki disabling it will make the WMF developers work harder on it. If the WMF didn't have a reputation for routinely ignoring tasks this proposal likely wouldn't exist. If the WMF committed itself to resolving the task in a matter of days, this proposal wouldn't be needed too badly, but I don't see that happening. The way I see it, this would be a deployment blocker for this feature if it had been caught sooner. Typing three letters in a search box should never result in NSFW pictures unless you're on a porn site. — Alexis Jazz (talk or ping me) 18:11, 18 April 2022 (UTC)
If those images aren't encyclopedic, they can be fixed editorially - no? The bad image list is designed to stop vandalism, not as some sort of "NSFW" content filter; though I do think that possibly integrating with MediaWiki:Pageimages-denylist could be useful, but that also isn't meant to be some sort of "NSFW" filter. — xaosfluxTalk 18:35, 18 April 2022 (UTC)
Of course, these are just my initial thoughts - if a community consensus to not use images on this page emerges we can further explore technical options. — xaosfluxTalk 18:36, 18 April 2022 (UTC)
@Alexis Jazz: Correct me if I'm wrong, but isn't the solution as simple as transcluding {{MediaWiki:Bad image list}} into MediaWiki:Pageimages-denylist? Or does the extension not parse the page before grabbing the list of images? --Ahecht (TALK PAGE) 20:18, 18 April 2022 (UTC)
a) it doesn't work like that; b)the search results doesn't seem to be using 'pageimages-denylist' (since it doesn't seem to be using the pageimages utility). — xaosfluxTalk 20:23, 18 April 2022 (UTC)
@XaosfluxIf you say it's not using pageimages I'll believe you, but if it were why wouldn't it work like that? Looking at the source of pageimages, it's doing a dbquery to get the pagelinks from the denylist, which should include any links in transcluded templates. --Ahecht (TALK PAGE) 20:53, 18 April 2022 (UTC)
@Xaosflux As a follow-up, per the source of MobileFrontend, it looks like it's asking the API for the pageimages property of the search results, which is supplied by the pageimages extension. --Ahecht (TALK PAGE) 21:23, 18 April 2022 (UTC)
I was misled by some of the phab comments! — xaosfluxTalk 23:37, 18 April 2022 (UTC)
Frankly, the image quality on those thumbnails is so embarrassingly bad (since they take a low-resolution thumbnail and stretch it to the height of each row) that disabling them makes the search results look SO much better and more professional. --Ahecht (TALK PAGE) 19:56, 18 April 2022 (UTC)
Partial Support We should have an option to disable thumbnails in the user preferences. - CafeGurrier66 (talk • contribs) 13:01, 22 April 2022 (UTC)
This is primarily a reader-facing item, and most readers don't have "preferences" to set. — xaosfluxTalk 13:11, 22 April 2022 (UTC)
Commented at the Phabricator task. I like the images in search results, so I don't want to see them go away, but this should absolutely be a blocking issue. {{u|Sdkb}}talk 21:20, 23 April 2022 (UTC)
This is a redirect that I think would be useful when it comes to the sandbox for the main page. Normally, we are against cross-namespace redirects, but I think this is one that would be useful. Interstellarity (talk) 13:48, 2 April 2022 (UTC)
@Interstellarity: Redirects from mainspace to Wikipedia, Portal, Category, Template and Help namespaces are already IAR exeptions of this rule so we will close this soon. - CafeGurrier66 (talk • contribs) 11:05, 24 April 2022 (UTC)
In principle, I'm against the very existence of Main page in mainspace, and wish it were in the project namespace, like some other English language projects (wiktionary:) already do.
If Main page remains in mainspace, it only makes sense that it's subpage-seeming pages also redirect to relevant pages in Wikipedia namespace, and thus I support this proposal.
Comment I was initially inclined to support this, as there's no reasonable way a reader would naturally navigate to the sandbox page. But then it occurred to me that creating this redirect might cause the page to appear in search suggestions (a feature in New Vector) when someone starts to type "Main Page", introducing potential confusion. If that's true, it moves me toward opposition, as reader needs should come first. {{u|Sdkb}}talk 16:51, 2 April 2022 (UTC)
@Sdkb: If so, couldn't the page be noindex'ed? ― Qwerfjkltalk 21:00, 2 April 2022 (UTC)
@Qwerfjkl, as far as I know, search engine indexing affects Google searches (which I'd presume would be smart enough to hide the sandbox) but not suggestions that pop up while you're typing in the Wikipedia search bar (which is what I'm thinking about here). {{u|Sdkb}}talk 21:23, 2 April 2022 (UTC)
@Sdkb and @Qwerfjkl There isn't currently any way to do this, but see phab:T24251 for a long-outstanding request to add this functionality. Thryduulf (talk) 10:40, 14 April 2022 (UTC)
I mark any cross-namespace redirect as egilible for speedy deletion. - CafeGurrier66 (talk) 09:58, 4 April 2022 (UTC)
@CafeGurrier66: Not all cross-namespace redirects are eligible for speedy deletion. The R2 speedy deletion criterion only covers redirects from the mainspace and does not cover redirects to Category, Template, Wikipedia, Help, or Portal namespaces either. Sdrqaz (talk) 09:58, 5 April 2022 (UTC)
Support, assuming Sdkb's concerns are able to be overcome. It feels like there should be a way to exempt pages from the NV search, and if there isn't, it should be a feature added to New Vector. I support the idea, since there's no reason a reader or editor would be harmed by Main Page/sandbox redirecting. Also, the talk page is Talk:Main Page, not Wikipedia talk:Main Page, so Main Page/sandbox feels more consistent. — Mcguy15 (talk, contribs) 21:09, 12 April 2022 (UTC)
Oppose Having Main Page/sandbox redirect to Wikipedia:Main Page/sandbox isn't the same thing as having both Main Page and Wikipedia:Main Page. Typing "Wikipedia:" at the beginning of any Wikipedia namespace page has been standard (at least since before I signed up). Cross-namespace redirects are superfluous to the redirects that we already use for the Wikipedia namespace (such as WP:MP and WP:SB. If we're going to make more redirects to Wikipedia:Main Page/sandbox then it should probably be something like WP:MP/SB or simply WP:MPSB. But a cross-namespace redirect isn't it and is just an excuse to make more cross-namespace redirects.—Mythdon (talk • contribs) 05:15, 15 April 2022 (UTC)
Also invoking IAR should be a matter of common sense and doesn't need to be laid out as an exception in any Wikipedia policy/guideline. "If a rule prevents you from improving or maintaining Wikipedia, ignore it." itself covers every exception to Wikipedia policy to involves IAR. Ignoring rules to improve or maintained Wikipedia is something that should be broadly construed and each and every exception doesn't need to be explicitly mentioned. This proposal is more or less pedantry in that it seeks process just for the sake of process. There's no need to fix what's not broken or try to rewrite policy over a proposal that is itself pedantic and based purely on semantics.—Mythdon (talk • contribs) 05:15, 15 April 2022 (UTC)
Oppose because 1. That is not what IAR is and 2. Why hasn't anybody created WP:MPSB yet? Let me do that right now casualdejekyll 05:53, 15 April 2022 (UTC)
Oppose because "Meh". --Jayron32 12:49, 21 April 2022 (UTC)
Support The deletion policy clarified that redirects from mainspace to Wikipedia namespaces are not egilible for speedy deletion. - CafeGurrier66 (talk • contribs) 09:41, 22 April 2022 (UTC)
Making a proposal to invoke WP:IAR is 100% the opposite of IAR's purpose. —pythoncoder (talk | contribs) 22:48, 24 April 2022 (UTC)
Comment It seems to me that Make an IAR exception is almost a contradiction in terms. IAR is about what doesn't get codified, so there is no need to formally codify an exception. Maybe you'd like to reword? There's so much cognitive dissonance from the summary that it gets in the way of considering the actual proposal. --Trovatore (talk) 18:04, 25 April 2022 (UTC)
combines the notes regarding non-free fair use rationales and disambiguation links, making them more concise and precise to the exact case where fixing is needed (a change in the content of a page).
removes the note about double redirects. Multiple bots already work to fix this task automatically; see this section. Per WP:BOTDEF, After launching the bot, an assumption can be made that there is no further need for human decision-making. Protected double redirects can be fixed through human decision making later on through Special:DoubleRedirects or a database query.
Makes the non-free fair use rationale note more precise. Per the non-free use rationale guideline, A redirect pointing to the page where the non-free content is intended to be used is acceptable as the article name in the non-free use rationale. If an article is...renamed later on, there is no need to update the fair use rationale(trimmed).
tweaks the link to the disambiguation fixer to change to an interwiki link, to avoid using an external link. This is an almost-cosmetic edit. removes the link to the disambiguation fixer as it is often down and fixing the links manually or via another semi-automated tool like AutoWikiBrowser or JWB is enough.
removes the request to check if Wikidata interlanguage links are updated, as this is automated
This change makes the template more concise, and reduces banner blindness by only showing the most crucial messages. A diff of the changes can be viewed here. See this 2020 post for more context and an earlier proposal. Thank you for your consideration! 🐶 EpicPupper(he/him | talk) 22:00, 14 April 2022 (UTC)
Concise is good, but I've a couple of concerns. As the last line notes, moving a page can be a prelude to reusing the old title ($3) for another page such as a dab. In that case, we do want to fix the rationales and the double redirects, which would otherwise lead to the new page on a different topic. Certes (talk) 22:12, 14 April 2022 (UTC)
That's a good point. I would also support moving the two pages under a "if you're turning it into a double redirect" bullet point if needed, e.g.
If you turn "$3" into a disambiguation page or into a redirect that targets a disambiguation page:
General support, provided that Certes' concerns and any others others bring up are addressed. This is another good opportunity to address banner blindness. Ideally, I'd like to see it adapt to the particular circumstances of a given move: e.g. include a message about subpages only if there are actually subpages (and if so, say "there are subpages" rather than "there might be subpages"). {{u|Sdkb}}talk 14:00, 18 April 2022 (UTC)
The subpage idea is interesting, but unfortunately I think that's not possible to do in wikitext or Lua AFAIK. 🐶 EpicPupper(he/him | talk) 18:40, 19 April 2022 (UTC)
Restructure the last point. Yes, a rewrite of this message was definitely needed. However, the greatest need for change is in the last point: currently, it's restricted to the case of dab pages, which is only one subset and where we already have several layers of redundancy in the mechanisms for tracking and dealing with the links. What we need instead is more general advice that will also cover the ground that we can't otherwise easily observe (all changes of primary topic that don't involve moving a dab to the base title: like, moving a dab away from the base title, making one article primary instead of another, turning the old title into a redirect to a different place, etc.). The clean-up work that all of these cases entail is: 1) checking all incoming redirects (and ideally, links) and retargeting as appropriate – otherwise, these can end up pointing to the wrong page; and 2) updating any fair-use rationales – otherwise these would break. When do these actions need to be performed? Certes above is on the right track. What all these cases have in common is that the old title will become something other than a redirect to the moved page. So how about Unless "$3" remains a redirect to the moved page, make sure the incoming redirects and links point to the correct target, and update fair use rationales if there are any.? – Uanfala (talk) 17:52, 19 April 2022 (UTC)
Agreed, I think this is an elegant way of framing it. Colin M (talk) 18:21, 19 April 2022 (UTC)
Thanks for the feedback! I've tweaked the message based on your feedback. Cheers! 🐶 EpicPupper(he/him | talk) 18:33, 19 April 2022 (UTC)
I support the broad outlines of this proposed rewrite (though the last bullet still needs some tweaking - I think Uanfala's proposed wording is the best so far). I wonder if it would be worth wikilinking somewhere in the message to WP:RMCI#Cleaning up after the move, since it goes into a lot more detail on post-move cleanup procedures, with examples and some further corner cases (though it does suffer from some awkwardness and bloat of its own). Colin M (talk) 18:26, 19 April 2022 (UTC)
Thanks! I've added the link at the top. 🐶 EpicPupper(he/him | talk) 18:37, 19 April 2022 (UTC)
Oh, yes, a pointer to the more detailed documentation is definitely a good idea. I do agree that that documentation needs work: it's split, unreasonably, between WP:POSTMOVE and WP:RMCI#Cleaning up after the move, and it's a bit hairy in places. – Uanfala (talk) 19:08, 19 April 2022 (UTC)
General supportGraham (talk) 04:11, 24 April 2022 (UTC)
I've reverted CafeGurrier66's close to allow for more discussion, see their talk page for context. Cheers, 🐶 EpicPupper(he/him | talk) 20:00, 25 April 2022 (UTC)
This was closed on the other page. — xaosfluxTalk 13:07, 28 April 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 discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
We should find a way to increase awareness of internet addiction among Wikipedians
Wikipedia can be addictive. Have you ever felt that you missed something important to do, just because of an article or a discussion at WP. Internet addiction and more specifically WP addiction as a big issue and we should inform and protects ourselves and others. By what means, I can not tell. Maybe ask for expert advice as a community. Let 's talk about it. Do you fell it is an issue we should be concerned? I think if we find a way to increase awareness, it would be an important step that highlights we are a community and even we do not know each other, we care. Cinadon36 10:16, 19 April 2022 (UTC)
I've been kind of back into my Wikiholism and doing virtually nothing else lately; Wikipedia is like a vacuum you get sucked into. So much to get caught up in, between editing articles, fighting vandalism, keeping up with policies/guidelines and participating in discussions, that it just sucks you in. The time I've spent on Wikipedia lately is time I'd normally spend watching videos or playing video games. Not sure when or how I'm going to come out of it, but Wikipedia addiction is most definitely a thing and I haven't been this addicted in awhile. —Mythdon (talk • contribs) 11:02, 19 April 2022 (UTC)
Very ironic timing as I am currently on Wikipedia procrastinating from doing an online exam lol. Curbon7 (talk) 11:04, 19 April 2022 (UTC)
In seriousness, it seems like an ebb-and-flow thing for me. This month I've been chilling with edits, but in February I was definitely spending way too much time on here. To some extent it probably has something to do with seasonal affective disorder, as now that it's warm and bright out I haven't been editing as much, though I'm still active daily. Curbon7 (talk) 11:07, 19 April 2022 (UTC)
Wikipedia itself is not for increasing awareness of any topic, which is considered promotional, even for good causes. (anti-suicide measures have been proposed before) WP:RGW is also relevant. There may be ways to work with the Foundation on this topic. 331dot (talk) 11:05, 19 April 2022 (UTC)
This could be something interesting to toss to the researchers if they haven't done this before, but yeah this is not in-scope for this page. Curbon7 (talk) 11:10, 19 April 2022 (UTC)
We have an article on Internet addiction disorder… which is marked as needing more work. I would suggest that a great way to make people aware of the issue (one that IS within the scope of WP) would be to improve that article. Blueboar (talk) 11:47, 19 April 2022 (UTC)
This is very true. I have my board and joint just round the corner. They happen to be the most important exams in a students life here. Even the slightest bad performance there sends you into a black hole, as you can't get into cheaper goverment colleges,(many aspirants, less vacancies) and have to spend millions in private colleges, whose affordability is somewhat difficult for our family. Yet, here I am, addicted to Wikipedia, replying to a random VPPR. —CX Zoom[he/him](let's talk • C • L) 11:48, 19 April 2022 (UTC)
So awareness of internet addiction is best pursued by posting on the internet? Let's have a smoke while discussing addiction to tobacco. 71.247.146.98 (talk) 12:00, 19 April 2022 (UTC)
This is totally wrong. "Have you ever felt that you missed something important to do, just because of an article or a discussion at WP" - no, never, why or how? If there is something more important to do just leave Wikipedia and start doing it otherwise it's serious mental problem not related to Wikipedia. Leave mental problems for hospitals. If you ask questions about "addiction disorder" in such a way this is trivializing the problem of addiction disorder so should footbal stadiums help to increase awareness of footbal addiction among footbal fans or should television help to increase awareness of television addiction among audience? Eurohunter (talk) 12:16, 19 April 2022 (UTC)
Casinos aren't in the mental health business, nor should they. Yet casinos offer information about gambling addiction. Maybe for some, the important step of recognizing the problem, needs to come from the source of the addiction. (says someone who scored a 163 on this test) --DB1729 (talk) 14:05, 19 April 2022 (UTC)
Thanks for your comments friends, but I would like to clarify that I wasn't talking about raising awareness among general public, which would be against WP policy. I am suggesting we introduce something (a policy or a guideline maybe?) for healthy editing. Like a rule of conduct, maybe just like Wikipedia:Civility. Cinadon36 13:43, 19 April 2022 (UTC)
Have you ever seen something like this in any book, television, zoo, gym or whatever? Leave individual mental problems for hospitals. Eurohunter (talk) 14:16, 19 April 2022 (UTC)
Mental health has quite a range, and most of the situations do not need a hospital. Have you ever heard of a frustrated person counting to 10 before replying? That's a mental health strategy. Do you go for a walk outside when you're having a bad day? Mental health strategy. Watch a funny movie when you're feeling down? Mental health strategy.
@Cinadon36, the "story" about internet addiction changes every few years. The newest version is that internet addiction is a symptom, not a disease. That means that (for example) depressed people want to spend all of their leisure time watching videos, not that watching videos makes you depressed. This makes sense: YouTube will autoplay a stream of videos, and you don't have to go to any effort. However, that doesn't help your mental health as much as positive interactions with other people would.
To use a more Wikipedia-specific example, if you are feeling "addicted", it can be useful to figure out whether you're getting sucked into the outrage machine (turning into "our most moralistic and least reflective selves", in the words of this recent article). If you are, you might have a happier life if you spend less time on things like reverting other people's efforts, getting into arguments on talk pages, or trying to enforce rules, and more time on building something that interests you and you find to be pleasant (e.g., clearing out a small backlog, making sure your favorite subjects have decent articles, or encouraging editors). WhatamIdoing (talk) 23:39, 20 April 2022 (UTC)
Thanks @WhatamIdoing: for your input. I feel addiction is a problem that some wikipedians have, and lots of them at are risk. They can be a manifestation of an underlying disease, or it can appear in an otherwise healthy individual. The "DSM-IV-TR Criteria for Substance Abuse and Substance Dependence" can be found here. [4]. In any case, my proposal was based on the idea that we have a moral responsibility to care for each other, and protecting each other from addiction could be useful. It is like saying to your loved one: "hey mate, you are too much consumed on this issue, are you ok?" How we do this, if we decide to act, we should first consult the experts. But unless we act, it is like WP is becoming a thing, that is produced based on mental illness. The analogy could be diamonds, that are products based on child slavery. As diamond sellers should make sure they do not use slavery, WP should make sure that the final outcome (articles) is not the result of mental health problems, nor any problems were caused during the "production period". Cinadon36 07:14, 21 April 2022 (UTC)
If someone has a mental health situation, and they use it to improve a Wikipedia article, then why would that be considered a problem? We have editors with mental health conditions such as autism and (actual, not movie-style) OCD. This can lend motivation and focus to their editing, and I have trouble imagining why this would be a problem. If you really like having all the Star Wars articles properly categorized or ordered into a list, then what's the problem with that? We'd never tell an editor, "Oh, hey, sorry, your desire to set up a logical cat structure is at least partly motivated by a mental health situation, so you're not allowed to help out with something that we all agree needs to be done. You sit on the side lines and watch while the rest of us slog through this tedious work that you'd be very happy to do." That would be both discriminatory against the editor and ineffective for the project.
There are some limits. Someone wrote Wikipedia:Wikipedia is not therapy many years ago, because we sometimes have people who are trying to use Wikipedia as an actual type of medical treatment. They might be practicing their computer skills (a type of Occupational therapy) or practicing social skills by contacting other editors. If, and only if, this activity is disruptive (e.g., they keep accidentally vandalizing articles), then we block them even if they say "but I need to keep editing for my health program!" This is really rare, though. WhatamIdoing (talk) 19:38, 21 April 2022 (UTC)
We have an article on this already, Problematic social media use. Social media addiction is a thing, and Wikipedia, despite WP:NOTFACEBOOK is social media. [5][6][7] I'm not saying there's really anything that can be done about it here, but to act like it's some bonkers thing is bonkers in and of itself. To say things like no, never, why or how? If there is something more important to do just leave Wikipedia and start doing it is to ignore the psychological effect of addiction. Many places and products that are addictive have signage and programs to help those with problems, so it's not a wild idea that's never been heard of. ScottishFinnishRadish (talk) 14:21, 19 April 2022 (UTC)
Excellent post, Cinadon36, and thank you for making it. We need to pay more attention to this topic as a community. I like the idea of making a page with tips for healthy editing. We could also take a look at some of our processes and see if there's any way we could improve them from a mental-health point of view. Enterprisey (talk!) 21:26, 28 April 2022 (UTC)
I hope I chose the right forum. Presently, WP:Requests for undeletion exhibits a very large notice on top stating that the UNDEL is not the place to request restoration of pages deleted via deletion discussions, and such requests must be made at WP:Deletion review. While not elaborated by the notice, the notice seems to imply to include WP:FFD and the now-axed WP:PUF, as these are deletion discussion areas.
This becomes tricky for requesting restorations of files deleted due to freedom of panorama-related reasons, like cases of freely-licensed images of buildings deleted during the time {{FoP-USonly}} did not exist yet, or rare case of a country introducing commercial-friendly FOP in which deleted files here need to be restored for them to be moved to their almost-permanent home (Wikimedia Commons). For such cases undeletions can be made immediately.
This proposal was suggested by Hobit at Wikipedia:Deletion review/Log/2022 April 25, where I requested the restoration of three files of buildings (two from Cambodia and one from France). Since such discussions at WP:Deletion review can be impractical, as the reason for undeletion is crystal clear, the best option is the allowance of WP:Undeletion requests to accept requests on undeletion of files deleted via FFD and PUF but only for freedom of panorama reasons. This will reduce the bureaucracy on Wikipedia. JWilz12345(Talk|Contrib's.) 08:14, 26 April 2022 (UTC)
To give some more context for editors who don't know the intricacies of how freedom of panorama (FOP) works on Wikimedia projects: The Wikimedia Commons has a rule requiring that all uploads there be freely usable under the laws of both the United States and the country in which the file was created. The English Wikipedia has a different rule: we only require that content be free under US law. In the United States, photographs of any constructed architectural work (e.g. a building) can be freely distributed under the freedom of panorama rule in copyright law. Because of this, it is acceptable to upload any photograph of a building to the English Wikipedia, even if the building is located in a country that does not have freedom of panorama. According to User:JWilz12345/Deleted no FOP, it seems like there are a number of examples of cases where administrators have deleted photos of buildings on the basis that there was no freedom of panorama in the countries in which they were taken, but because there is freedom of panorama in the United States for buildings, those photos were actually okay to upload on the English Wikipedia (but not to the Commons). It's definitely a bit confusing, but on the whole, I think JWilz12345 has it right, and I am not opposed to their proposal here to make this something acceptable to bring to WP:REFUND. (If only they un-withdraw it...) Mz7 (talk) 02:23, 27 April 2022 (UTC)
I agree, we should make this easier by letting REFUND handle it. It's a good idea. BTW I totally get people throwing up their hands and walking away after a frustrating experience like what they just went through. I hope they come back. In the meantime let's fix this problem they've identified and reduce the frustration factor for others. Levivich 23:53, 27 April 2022 (UTC)
Thanks for some encouragement @Mz7 and Levivich:. I'll reopen my proposal. But from now on I won't request for restoration any deleted images of buildings that I may stumble upon soon, while browsing through PUF requests. The remark by IP has discouraged ne to some degree. I will only request restoration if ever freedom of panorama is introduced in our country, hopefully after the 2022 elections. JWilz12345(Talk|Contrib's.) 14:48, 28 April 2022 (UTC)
Please don't let one anonymous remark put you off. Any act or idea, however good, will upset one person in seven billion. Certes (talk) 15:02, 28 April 2022 (UTC)
Thanks for the encouragement @Certes:. Now, back to the proposal. In accordance with the proposal, the large notice on top of WP:UNDEL must be modified to read like I suggest or something similar (the bolded passage is my suggested new addition):
Despite what the heading message says I restore all sorts of uncontroversial pages. If the requestor provides evidence to support their claim - perhaps a link to the policy, and info on the the affected file, it may be obvious that the earlier deletion should be overturned. There is a flow of images that have copyright expired in the last year or two, or that are too simple for copyright having their deletions reversed. Also many FFD file deletes are just nominated by one person and then never supported by anyone. You cannot call that a consensus, and the deletion is more in the way of a soft delete. The lead text instructions should probably reflect our policy, but don't make it too long, otherwise it will not be read or understood. Graeme Bartlett (talk) 10:39, 29 April 2022 (UTC)
I would suggest adding a new bullet point to the section of WP:RFU that says Instructions for special cases for US-FOP undeletes. I'm not sure exactly what the the bullet point should say, but something to the effect of US-FOP undeletes can be requested here, which gives some brief guidance/explanation about when these can be undeleted. Maybe something like "A file that was deleted based on lack of FoP can be undeleted at RFU if it is eligible for a {{FoP-USonly}} tag." Levivich 15:46, 29 April 2022 (UTC)
Oppose REFUND should be a formalistic venue, not making content decisions that certain files were wrongly deleted. * Pppery *it has begun... 16:22, 29 April 2022 (UTC)
Stop page from going back to the top after going back after clicking on image?
It's one of the more irritating things on Wikipedia, that when you are reading an article and then click on an image to view it, and then go back to the article and it has returned you to the start, top, of the page. Then you have to scroll down to find where you were, and it's very annoying when reading a long article. I guess this is something only programmers or people more deeply involved in Wikipedia could fix, but it would be a welcome fix. 2A07:A880:4601:1051:5AAD:6475:8E2A:7767 (talk) 06:40, 3 May 2022 (UTC)
This is more of a technical issue than a conscious decision by editors, although I am unaware of the specific phabricator ticket for this. — Ixtal( T / C ) ⁂ Join WP:FINANCE! 07:30, 3 May 2022 (UTC)
Huh? That doesn't happen for me. Are you talking about the (horrible, no good, very bad, really just needs to be taken out and shot and buried in a deep, deep, DEEP grave and never spoken of again) mobile version? --User:Khajidha (talk) (contributions) 11:58, 3 May 2022 (UTC)
2A07:A880:etc., which browser are you using? I've noticed this with Internet Explorer, and is one of the (many) reasons that I don't use it. --Redrose64 🌹 (talk) 18:44, 3 May 2022 (UTC)
FYI… this does not happen in Mobile View… nor when using Desktop view on a phone. So that is not an issue. Blueboar (talk) 15:13, 7 May 2022 (UTC)
Works for me, using desktop/monobook/firefox/without "media viewer": Went to a page, Alpine_transhumance, scrolled down, clicked the image, which my browser followed to the image description page, click "back" in the browser and was right where I started. — xaosfluxTalk 18:36, 7 May 2022 (UTC)
Works fine for me as well, using Firefox 100 on Linux on a desktop PC. Phil Bridger (talk) 18:41, 7 May 2022 (UTC)
Make portals visible in default search
I suggest that portals be visible in default search alongside with articles (when the userreader does not actively choose namepaces).
Rationale: To increase portal pageviews and to increase awareness of the portals among readers. Not all usersreaders know about namespaces and what they are. Utfor (talk) 16:33, 3 May 2022 (UTC), edited by Utfor (talk) 18:45, 3 May 2022 (UTC)
I don't think a lot of readers would care to know what namespaces are since I bet the majority of people using the search function on Wikipedia are just trying to find a specific article. But if people think this is a good idea I don't object (but I don't really support it either). ― Blaze WolfTalkBlaze Wolf#6545 18:57, 3 May 2022 (UTC)
My point is not that readers would want to know all about all namespaces, but if they search, they need to know what the portal namespace is in order to find portals in the search. Utfor (talk) 19:06, 3 May 2022 (UTC)
Well I honestly don't see why a reader would want to use the portal. If a reader is looking for a specific article they'll just search for it. ― Blaze WolfTalkBlaze Wolf#6545 19:09, 3 May 2022 (UTC)
Oppose - if a reader is searching for an article, why would they want a portal? ― Qwerfjkltalk 19:27, 3 May 2022 (UTC)
You could shorten that to "why would they want a portal?". Seriously, just scrap the damn things. --User:Khajidha (talk) (contributions) 19:38, 3 May 2022 (UTC)
I believe we should just deprecate portals entirely.--WaltCip-(talk) 16:53, 4 May 2022 (UTC)
Oppose, per above. Portal talk pages are dead, portal pages are dead, just desolate in general. Take the Formula 1 portal, it gets less pageviews than an article I wrote about a diabetes medication. I wouldn't be saddened at all to see them go. X-750I've made a mistake, haven't I? 03:01, 5 May 2022 (UTC)
Support – If links to portals are not available anywhere to WP:READERS, then readers are left in the dark, then having no way of knowing about their existence. Omission of portals from searches on en-wiki is exactly why page views for some portals may be lower than they need to be; readers don't see links to them. Portals should not be censored from public consideration. Then, when more people actually learn about portals, because they can actually see links to them, more editors will naturally come along to improve them. North America1000 14:11, 6 May 2022 (UTC)
But why would readers be interested in portals in the first place? If a reader is looking for a specific article, they wouldn't be wanting ot see results for a portal on a related subject. They would be looking for the article. ― Blaze WolfTalkBlaze Wolf#6545 14:17, 6 May 2022 (UTC)
Queue the portals to link below the main articles, creating an option, rather than no option being available. North America1000 14:28, 6 May 2022 (UTC)
I don't see how that would make users click portals more. In fact it probably wouldn't make a difference since if a user starts typing the article title in, a bunch of different articles will pop up (probably more than can be displayed) before it reaches the bottom unless it's the exact article title or no other article title matches that, which in that case the portal wouldn't match what is typed. ― Blaze WolfTalkBlaze Wolf#6545 14:42, 6 May 2022 (UTC)
Oppose Can we just stop trying to beat life into the dying horse that is Portals? casualdejekyll 14:30, 6 May 2022 (UTC)
Your logic seems inversed, because providing readers with an option to actually see portals does not "beat life" into them. Rather, this would actually make them more visible to readers. Why should we "stop trying" to make an entire Wikipedia namespace readable? Many readers become editors, but readers cannot potentially improve hidden content. North America1000 14:46, 6 May 2022 (UTC)
Oppose. The default search settings should, in my opinion, contain the minimum amount of pages required to get readers to what they are looking for. Cluttering up default search with pages of questionable usefulness in the name of "increasing visibility" makes searching for stuff a more time consuming and worse experience. Portals aren't useful for navigation because they contain a semi-random selection of snippets from articles and are often quite badly out of date - it's completely pot luck as to whether you'll find what you're looking for. Portals already have fancy bars, buttons and links in basically every major article on the site, that should be more than enough visibility for readers to realise they exist. 192.76.8.77 (talk) 10:50, 8 May 2022 (UTC)
Weak support. I didn't know what a portal is until like 6 months ago. It's just hidden too deep inside. And it's a reader-facing namespace. Not something like Modules or MediaWiki pages. Portals are a really nice way to navigate Wikipedia, but people simply don't know about their very existence. —CX Zoom[he/him](let's talk • {C•X}) 14:05, 8 May 2022 (UTC)
Conditional support, oppose otherwise. I would support this only if this is part of a portal viability test which after x months (say 6 months) we check if portal traffic has significantly increased. If they haven't, the portal namespace finally gets deleted. There are voices that keep trying to revive this failed idea, when the evidence consistently shows no one cares but a very small group. Gonnym (talk) 17:10, 8 May 2022 (UTC)
Oppose Portals are already searchable in the search engine, as is any namespace. There are already links to portals in the "see also" sections of many articles. Not only that, but portals are barely updated anymore. The last time Portal:United States was updated was April 9, last time Portal:The arts was updated was January 9, and so forth. Even from my own experience as a reader, in the 15+ years that I've used Wikipedia, I used portals a grand total of zero times. Trying to bring back portals is like trying to bring back the dinosaurs. It's not going to improve reader experience and sometimes its just better to let something that's dead stay dead.—Mythdon (talk • contribs) 17:39, 8 May 2022 (UTC)
That is incorrect. The last edit to a portal page is not when it was last updated. Just like on Wikipedia's Main Page, portal updates usually come from elsewhere. See for example [8]: the United States portal is updated about every week. —Kusma (talk) 08:26, 9 May 2022 (UTC)
Support Portals aren't good because of their low visibility. If portal visibility keeps getting suppressed by people because "Portals are bad," how are they expected to ever improve? They're worsening the problem they're blaming. — PerfectSoundWhatever (t; c) 03:50, 9 May 2022 (UTC)
Oppose - An attempt to resurrect a dying concept. Let's focus on working on what already appears in the default searches - the actual articles which are the purpose of this project. -Indy beetle (talk) 07:30, 9 May 2022 (UTC)
Support at least as a test. Portals are so hidden now that people only rarely stumble upon them. Any change to their view counts needs to come from outside of portal space; without either something like this or a way to make portal links in articles more visible, we should expect portals to continue to slowly die. We should not hide gems like Portal:Cheshire from our readers. —Kusma (talk) 08:26, 9 May 2022 (UTC)
Oppose. Portal:Cheshire (given above as an example) is already linked from 1579 mainspace articles[9] and is viewed on average 6 times per day. Most people just aren't interested in them, and any effort spent on them is a waste of time. Perhaps Cheshire is a low-interest topic, but Portal:Covid-19 is also clearly linked from some 1600 mainspace articles, many of them very often visited (pages like COVID-19 pandemic and so on), and it gets only 84 pageviews per day. Portals just aren't what people are looking for here, very few people seem to be using portals as their entry point or seem to be returning to them on a regular basis. Sending more people to pages they don't really want is not useful. Fram (talk) 09:46, 9 May 2022 (UTC)
The thing is, portals are technically "widely linked", but never in a place where I actually see the link (they are competing for my attention with far too many other things). In articles longer than two screens, I don't think the portal links do anything. I don't have a particularly good suggestion how to change that. To put the pageviews into some more perspective, the portals are more popular than outlines and indices: [10]. —Kusma (talk) 10:10, 9 May 2022 (UTC)
Oppose as they are pretty useless. We should be moving away from Portals. Graeme Bartlett (talk) 10:15, 9 May 2022 (UTC)
Question. Aren't categories reader-facing (and much more well-maintained)? Wouldn't this logic apply to them, too? –MJL‐Talk‐☖ 17:27, 9 May 2022 (UTC)
Oppose portals have been dying a slow death for over a decade. Whatever use they may have once had, they are now basically moribund, and I see no reason to enact the proposal. --Jayron32 17:41, 9 May 2022 (UTC)
The number of words in wikipedia articles
Did you know that the number of words in all wikipedia articles is 4,109,724,931.
The maximum size of a 32 bit unsigned integer is 4,294,967,295.
Should we have some recognition for that if it occurs?
No. Only if adding more words causes an integer overflow and deletes the content. AndyTheGrump (talk) 12:27, 1 May 2022 (UTC)
Maybe that would break the Internet. Phil Bridger (talk) 13:15, 1 May 2022 (UTC)
One lives in hope... AndyTheGrump (talk) 14:56, 1 May 2022 (UTC)
I don't think the 32 bit integer limit applies to something like Wikipedia. I could be wrong though. ― Blaze WolfTalkBlaze Wolf#6545 14:01, 2 May 2022 (UTC)
Why wait? Dust-off that old 16-bit PC and put this to the test. 50.75.226.250 (talk) 15:50, 2 May 2022 (UTC)
I don't think a 16-bit PC can have an internet browser. Also, I'm fairly sure we have gone beyond 32 bits, mainly since (For example) Minecraft's limit of normalness is the 256-bit integer limit (After that it still works but it starts breaking). ― Blaze WolfTalkBlaze Wolf#6545 16:54, 2 May 2022 (UTC)
Well, it was supposed to be a joke that apparently misfired, apologies. Or you could make a perfect straight man :). Jokes aside, sure there were (and can be) internet browsers on 16-bit devices, including PCs, but that's another topic. 50.75.226.250 (talk) 17:02, 2 May 2022 (UTC)
Lynx (web browser) can run on 16-bit machines. Anyway, if there is a limit relating to MAXINT, it will either be the number of bytes in a file, or the number of files on a server. The number of words is totally irrelevant - in English, words are delimited by pinctiation and spaces, both od which are characters just like letters or digits. --Redrose64 🌹 (talk) 18:54, 3 May 2022 (UTC)
Please don't disillusion me like this. I was hoping that someone somewhere would break the Internet so we could all get back to a simpler life. Phil Bridger (talk) 20:23, 3 May 2022 (UTC)
the total number of words are from different pages, that is similar to different files. To be short, I dont think crossing that limit will cause anything to happen. If we include all the words from english subdomain only (enwiki), I think we would have the words at least 7-8 times more than the article-space. main talk, user, user talk, WP, WP talk, templates, and literally every text that exists on enwiki. Later, dewiki is subdomain, and technically still a part of "wikipedia" website. —usernamekiran (talk) 05:20, 10 May 2022 (UTC)
Wikipedia:Naming Conventions
There is WP:SNOW-level opposition to the proposal, and no support from anyone but the OP. Further attempts at introducing a naming convention for naming conventions should probably go to the idea lab for workshopping first. —Kusma (talk) 12:45, 12 May 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.
How can they violate a policy on article titles? They are not articles. Phil Bridger (talk) 19:20, 11 May 2022 (UTC)
We can certainly discuss renaming these guideline pages… but Phil is correct: WP:Article titles applies to article space, not policy/guideline space. Blueboar (talk) 19:26, 11 May 2022 (UTC)
@Joe Roe @Blueboar @ZLEA these page titles (in the category) as they stand currently are strangely titled and I have suggested a proposal with a more natural title without being complicated by unnecessary use of parenthesis. You may disagree with my observation, that's ok. If we can discuss on the merits of the proposed title vs existing title of these pages, that would be more fruitful for this discussion. Thanks. Venkat TL (talk) 19:51, 11 May 2022 (UTC)
As I stated in the preceding move discussion, and as Phil states here, WP:TITLE does not apply to Wikipedia-namespace pages. WP:TITLE itself says "This page does not detail titling for pages in other namespaces." - ZLEAT\C 19:32, 11 May 2022 (UTC)
Follow up - I believe the current titles are the most convenient. The pages in question are naming conventions, so it makes no functional sense to have the topic come before "naming conventions" in the title. Having "naming conventions" before the topic arguably makes it easier to search for naming conventions, so Wikipedia:Indian constituencies naming conventions and Wikipedia:Indian constituencies (Naming conventions) don't make much sense. Furthermore, Wikipedia:Naming conventions for Indian constituencies is needlessly wordy, and in my opinion, Wikipedia-namespace page titles should be concise for easier searchability. - ZLEAT\C 20:16, 11 May 2022 (UTC)
The difference between the two is only 2 alphabets. Not words, 2 alphabets. If that is a concern, then #2 below is the shortest.
The problem is that #2 does not put "naming conventions" before the topic, thereby making it harder to search if one is looking for naming conventions. - ZLEAT\C 21:54, 11 May 2022 (UTC)
Sorry but this is silly. GiantSnowman 21:25, 11 May 2022 (UTC)
Oppose. Notability (people), Notability (organizations and companies), etc., is superior to Notability of people, Notability of organizations and companies, etc. (Although, a colon would also work: Notability: people, Notability: organizations and companies.) — kashmīrīTALK 00:59, 12 May 2022 (UTC)
Venkat has since objected to that close. In my view, it is per sedisruptive editing to try to prolong a discussion about something profoundly pointless that has no chance of succeeding. It represents a fundamental misunderstanding of the nature of discussions in an all-volunteer organization. And it is particularly troubling to see from someone who has already been banned from one part of projectspace this month for refusing to drop things over a minor change. But, since he has asked me to revert this "inappropriate and immature closure", I will reopen it. -- Tamzin[cetacean needed] (she/they) 10:09, 12 May 2022 (UTC)
Oppose Should be re-closed ASAP per WP:SNOW. The OP Venkat TL is under the impression that braces ( ) should be used in page titles only for strict disambiguation purposes. This is clearly nonsense; what we do now is perfectly sensible. The consensus here is already universally sceptical, and no way is it going to endorse this change. — Cheers, Steelpillow (Talk) 10:39, 12 May 2022 (UTC)
Oppose. Pointless change, no real benefits to the move have been put forward and moving policy documents that have been at their current location for ~20 years is going to be disruptive. The current set of titles follow a well defined pattern that makes them easy to search for and locate, using titles like Wikipedia:Indian constituencies (Naming conventions) would make it more difficult to find the various sub policies, and I don't see the benefit of the increased wordiness of the other proposed titles. It is claimed that these titles violate WP:Article titles, which they patently do not. As that page states in it's lead (complete with emphasis) This page explains in detail the considerations, or naming conventions, on which choices of article titles are based. This page does not detail titling for pages in other namespaces, such as categories. 163.1.15.238 (talk) 11:48, 12 May 2022 (UTC)
Oppose After considering the proposed options, I still find the status quo page titles to be the most intuitive and navigable. DanCherek (talk) 11:57, 12 May 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
May is Hearing and Speech Month in Canada
My name is Leana Ilagan, I’m an Speech-Language Pathologist from the Philippines, and currently on a post-graduate study program in Canada.
I want to express my appreciation and gratitude to Wikipedia, as you served us all with resources as well as legitimate facts across the world as time stand and fly by, and for that we thank you.
Wikipedia is known as the most famous online encyclopedia globally, may I suggest for us to promote May as Speech and Hearing month, to give more awareness to our fellow nations and people around the world. This will be provide an opportunity to raise awareness about hearing and communication health. Moreover, it can give attention to the importance of early detection and intervention in the treatment of communication disorders and hearing impairments, as well as recognize the role of health-care professionals in providing life-altering treatment for people to overcome and/or manage them.
I highly encourage Wikipedia to add this event for the special events celebrated and recognized for the month of May.
Wikipedia is not for promoting causes like that, no matter how worthy. Graham87 09:15, 12 May 2022 (UTC)
No, it is not for promoting such causes, but there is nothing to stop interested editors from improving relevant articles. I would urge the proposer to do so and encourage others to do so, whether in May or any other month. Phil Bridger (talk) 17:21, 12 May 2022 (UTC)
A Proposal to formalise and centralise the control and reporting of Undisclosed Paid Editing
Wikipedia, by which I mean the community that is the English language Wikipedia, is serious about controlling undisclosed paid editing. That we know.
Wikipedia requires paid editors to disclose their status. See WP:PAID. It provides four levels of warnings to suspected paid editors (UPE) who have not made a proper disclosure:
Editors in good standing who suspect an editor of UPE are encouraged to use these warnings in good faith, at which point the system ends. There is no obvious, nor reliable, route forwards.
Instead, we have independent, committed editors and admins alike who try, and often succeed, in pursuing UPE either to a formal disclosure (good), or to an indefinite block (also good) should they not disclose and matter be proven.
But proven is a difficult word in this context. Proven by whom, and to what universal and agreed standard? Using what tools? Using what authority to use a putative toolset that may not even exist?
Were we investigating sockpuppetry then the route to opening an SPI is clear. We even have tools to assist us. We pass the task to a team of acknowledged experts, a team empowered within agreed limitations to investigate, and to act. We make the evidence based report, and stand aside, confident that experts will reach an evidence based conclusion. We trust the team.
For paid editing investigation we have a loose confederation of gifted amateur sleuths, Miss Marples if you will. Like Miss Marple, that loose confederation is susceptible to being accused of being interfering busybodies, perhaps being pilloried by accusations of bias, perhaps being accused of many other and more serious things, all from areas where they have acted in good faith and met a powerful Wiki-enemy. This can lead to our Miss Marples being driven away. 🇺🇦 FiddleTimtrentFaddleTalk to me 🇺🇦 18:51, 9 May 2022 (UTC)
Proposal (UPE reporting)
To counter this I make a simple sounding proposal, one that will create a trusted core team of UPE fighting experts, very much along the lines of our Sockpuppetry team.
Those experts are to be provided with, or to create, or to cause to be created, such tools as will, with correct community consensus based approval, ease the work of identifying UPE beyond reasonable doubt.
The experts will start from a mixture of community reports (cf SPI) and their own initiative, always processing their work in as transparent a manner as does not create a WP:BEANS situation, and does not breach the legitimate privacy rights of editors who fall within the scope of their investigations.
As usual I hope the community will seek to improve on this very simplistic proposal. 🇺🇦 FiddleTimtrentFaddleTalk to me 🇺🇦 18:51, 9 May 2022 (UTC)
Discussion (UPE reporting)
This is wayyyyy overreaching imo and overly bureaucratic. As someone who works extensively in identifying UPE, this is a super myopic view/proposal and way too black and white, which UPE is not. It's more than just fiverrs and freelancers being hired and one off employees editing on behalf of their company. Further this is also somewhat redundant because it's already required by the terms of use, which isn't subject to enwiki's discretion (with regard to warnings, which are often ingnored as well as disclosure.) Creating a "trusted group" is also unrealistic imo. Who is to say who is trusted and who is not? A lot of UPE identification in terms of identifying the who/where they were hired can and is done off wikipedia and disclosing more than that would disclose a lot of tells and identifiers we use. PRAXIDICAE💕 18:59, 9 May 2022 (UTC)
@Praxidicae I'm glad you said that, and I understand it, and thank you. You are one of the committed and gifted people I refer to. What I hope to happen is for the community to use this discussion as a spur to show people like me an approved route forward. I am not wedded to any of the proposal, but I feel that we must start somewhere for the ordinary editor. Counter proposals are more than welcome. 🇺🇦 FiddleTimtrentFaddleTalk to me 🇺🇦 19:07, 9 May 2022 (UTC)
@Praxidicae: Whats a fiverr? —usernamekiran (talk) 21:13, 9 May 2022 (UTC)
Honestly a lot of this proposal is just too much, it's like 9 solutions in search of a problem. Is the way we handle UPE the most ideal? No, but it's also not possible in some aspects to do any better because of our policies on outing and AGF, add to that, sometimes it's better not to disclose publicly what we do know because that's a tip off to some of the more damaging paid editing firms. Further, formalizing a "group" of individuals is a bad idea because it's going to become an issue of gatekeeping. I also worry that formalizing said group would result in more malicious harassment of editors (I can attest to this personally as I'm accused on a nearly daily basis here and off-wiki of "working for competitors") and we'll wind up with more blown-out-of-proportion ANI threads like the one targeting Celstina at ANI right now, especially when the particularly powerful paid editors with thousands of edits, which trust me, do exist, get rubbed the wrong way. PRAXIDICAE💕 19:12, 9 May 2022 (UTC)
How do we protect the Celestina007s of our community?
You are opening up very substantial areas for discussion. I am at the end of my expertise, and hope to learn, now. If the proposal is too much, then please prune it, refactor it, do what you believe needs to be done to it, because those who, like me, look up to those like you are unsure how to move forward. 🇺🇦 FiddleTimtrentFaddleTalk to me 🇺🇦 19:21, 9 May 2022 (UTC)
Isn't WP:COIN already a centralized board for handling conflict of interest? It suffers from low traffic (or at least, low uninvolved traffic), but IMO is the "next step" that this proposal asserts is missing, in that it's a centralized board for community review of COI concerns. signed, Rosguilltalk 19:02, 9 May 2022 (UTC)
FWIW I don't consider COIN to be a particularly valuable part of identifying UPE since a lot of what we need to demonstrate to prove that an editor is a paid editor (outside of one off obvious accounts that get blocked at the start for spamming/paid editing) can't be posted on-wiki. PRAXIDICAE💕 19:04, 9 May 2022 (UTC)
Me neither. As soon as it reaches coin its dead, they start to play up and fudge it. I suspect coin and board are pretty much dead. Its show the decay in Wikipedia that once vibrant board is now barely used. scope_creepTalk 20:40, 9 May 2022 (UTC)
I'm not clear on what is being proposed that requires community consensus. It sounds like you are proposing that some tools be created, but without specifics, it's unclear if this is something requiring access to private information. If not, then anyone can create tools using publicly available data. (I know there has been sensitivity in the past with things like building a notification system for a user's edits, but there is no way to prevent someone from using public data as they will.) isaacl (talk) 20:02, 9 May 2022 (UTC)
I'm not sure that "prove" is a good word to use, unless we also specify the standard of proof required. I have always understood that the standard of proof required to take sanctions here to be (using terms from English law, which I am most familiar with) below the standard required in criminal cases (beyond reasonable doubt) but above that required for civil cases (balance of probabilities). Blocking, or other sanctions, are important enough not to be taken lightly, but we are not taking away anyone's liberty or money here, simply telling them not to edit a web site. Phil Bridger (talk) 20:09, 9 May 2022 (UTC)
It's even better than that: we're taking away their money if and only if they're guilty. Certes (talk) 20:49, 9 May 2022 (UTC)
I don't think the proposal is bureaucratic from what I interpret it to be. But it is a little loosely/vaguely defined. I think COIN is best suited venue for UPE, and related discussions. Like Praxidicae said above, there are PR/editing firms at play, these are way different than one-off, or overly obvious newbies/freelancers. UPE, and accusations of UPE requires (most of the times) off-wiki evidence, and providing that off-wiki evidence would be revealing our methodology/MO, which would help them improve, and would make finding UPEs difficult for us. Other issue here is about outing, and other related stuff. The best way to tackle this is to call it COI instead of UPE. That way, way have to provide less (on-wiki) evidence so that we can prove COI, and maintain the discreetness of our MO, and get that ediotr topic banned from the particular topic. I am not sure what tools you are thinking (to use/create) that could help identify UPE. I dont think thats even possible. But what we could do is, to make a subpage somewhere in COIN to list all the editors who are interested to work against UPE/COI. A procedure/guideline in case we come across UPE/COI to get blocked. If the evidence is solid, we can provide it to ARBCOM, and they can block the UPE/COI editor through role account to avoid being targeted/harassed. Praxidicae has also voiced my concerned about the team which I raised here. In short, NPP/R was not formed in a week, it is result of years. We can create an informal list in a subpage of COIN. We should create a standard guideline/procedure for course of action if COI/UPE is found. It would be better if the course of action somehow hides the investigator (arbcom/role account?). With time, this process might grow/develop automatically. —usernamekiran (talk) 21:13, 9 May 2022 (UTC)
I'm trying to get my head around what this would involve. As far as private data goes, the two main types that assist with UPE would be CU and information about job ads and advertisements. The former is already handled in an existing system, and I fear that special "UPE CU" admins would risk creating too many new problems. I can see a case for expanding the use of CU in order to tackle prolific sockpuppeteers, but that could be handled in the existing CU framework. In regard to the latter, WP:OUTING has already been modified to both a) permit the linking to job ads on COIN even when there is a risk of identifying editors; and b) requiring paid editors to "self-out" by linking to their profiles on freelance sites from their user pages. As to what editors do off-wiki, such as watch job ads and known contractors, (which, in the interest of full disclosure, I do), I'm not sure how en.wiki can be involved. The issue is that ultimately, what someone knows from off-wiki data is irrelevant unless it can be shared, as in the end you can only block or request a block if you can support it with evidence, even if that evidence needs to be shared on COIN or with a trusted admin/arbcom per the existing COI procedures. Any other "tools" would only be to look at on-wiki editor behaviour, wouldn't involve private data, and therefore I don't think should be limited in access to a select group, as that is counter to our principal of transparency. To be honest, I think the only effective way of combatting most paid editing is to make Wikipedia less attractive for advertising by making the rules on businesses and individuals more restrictive, but I don't see that happening any time soon. - Bilby (talk) 23:15, 9 May 2022 (UTC)
CheckUsers already handle nonpublic evidence of UPE sent to paid-en-wp@wikimedia.org – mainly advertisements on freelancing websites. Perhaps we need to clarify that this is preferred way of reporting over sending to individual admins (per WP:BLOCKEVIDENCE, individual admins should not act on nonpublic evidence because it leaves no paper trail) or ArbCom (who have enough on their plate and set up paid-en-wp@ for that reason). The instructions seem to be scattered all over the place and out of sync. – Joe (talk) 11:43, 10 May 2022 (UTC)
It seems that there is some variation on this around - I'm very happy to see that clarified. Thanks! - Bilby (talk) 11:52, 10 May 2022 (UTC)
If something needs to be changed, it's WP:OUTING. The policy section was never meant to protect people who are here to exploit our collaborative non-profit project for their own financial ends. It's part of the harassment policy, after all. The point is to protect people from being doxxed because they made controversial edits, blocked a popular user, or pissed off the wrong LTA. We should just expand the exceptions Bilby mentions to one of "accusations of pervasive conflict of interest in a user's editing". I don't get why we twist ourselves in knots defending those who want to hurt what we've built. -- Tamzin[cetacean needed] (she/they) 08:45, 10 May 2022 (UTC)
Those experts are to be provided with, or to create, or to cause to be created, such tools as will, with correct community consensus based approval, ease the work of identifying UPE beyond reasonable doubt. What kind of tool do you expect to be created that requires special permissions? Tools that rely on non-public data are already restricted to admins or checkusers. It seems a bit premature to setup a whole new process to authorize the use of some tools, when we don't seem to have tools to authorize in the first place. MarioGom (talk) 14:13, 10 May 2022 (UTC)
Sorry, coming to this quite late, as I'd only noticed the parallel discussion at Wikipedia:Village_pump_(idea_lab)#Undisclosed_Paid_Editing. The wording here might be partly my fault, as I raised the concern at a current ANI argument, where a UPE-hunter has been accused of making unclear and exaggerated statements about the tools and powers available to them. I replied at ANI that I thought UPE-hunting was better done by a selected group who have whatever tools they need, and have procedures in place to follow: if we minions knew what rights UPE-hunters have, and how the decision is reached, UPE-hunters wouldn't have to justify their actions by claiming mysterious special rights and abilities, and we'd have been spared an outstandingly long and painful ANI. It may just be that we need better documentation of what processes already exist. But the ANI thread is strong evidence that we haven't quite got this right yet. Elemimele (talk) 12:29, 11 May 2022 (UTC)
The problem I see with that ANI thread is that too many people were too happy to continue talking about non-existing special rights and non-existing secret tools even after receiving many technical explanations. And this is a good example of the FUD that, unfortunately, continues: if we minions knew what rights UPE-hunters have There're no "UPE-hunter rights". Any discussion that continues standing on this false premise is not going anywhere useful. MarioGom (talk) 17:50, 11 May 2022 (UTC)
@MarioGom:, that was partly my point. With neither any special tools, nor with a duck-test for UPE, it's basically impossible to fight it without landing up at ANI, because there is no conceivable situation in which you can make an accusation of UPE without being accused of bad faith. You say they're doing UPE. They say they're not paid. And if you don't believe them, you're the baddie. If there were a duck-test, you'd at least be able to say "account is quacking"; if there were some technical way to match up the account to IP addresses previously found to be indulging in UPE, or that match organisations/people advertising their services as WP editors-for-cash, then someone could declare the editor a UPE (though this probably overlaps very heavily with SPI); and if there were a group given particular rights to reach the decision, the decision would look less like an individual piece of vindictiveness, and more like a community consensus. My feeling is that as things stand, it simply isn't sensible to go looking for UPEs precisely because there are no tools, definitions or special groups to do the job. I just can't decide which is better: abandon hunting UPE and just attack bad edits irrespective of their cause; or create structures/tools/definitions to legitimise UPE-hunting. Elemimele (talk) 12:19, 13 May 2022 (UTC)
Per Praxidicae; seems overly bureaucratic and a solution in search of a problem. firefly ( t · c ) 19:17, 9 May 2022 (UTC)
This isn't something that can feasibly be done within policy or practicality, due to the concerns Praxidicae brings up. It's impossible to definitively determine whether a user is UPE without either self-outing or outright outing that is almost guaranteed to also have collateral damage, especially given the tendency of UPE editors to lie in an effort to not have to disclose. —Jéské Courianov^_^va little blue Bori 20:18, 9 May 2022 (UTC)
Per prax in the discussion section. Our processes for handling and documenting UPE could be improved, but bureaucracy and yet another pseudo-permission won't do that. This proposal should have been workshopped with people active in this area first (@Timtrent: did you see Wikipedia:Village pump (idea lab)#Undisclosed Paid Editing?) – Joe (talk) 11:38, 10 May 2022 (UTC)
Hell no. As soon as we are asked creating "trusted core" teams of "experts" to "fight" anything, we should run screaming in the other direction. Just. No. --Jayron32 14:06, 10 May 2022 (UTC)
@Jayron32: I am not opposing you, but your "to "fight" anything" comment intrigued me a lot. Would you kindly elaborate on your (entire) comment? I mean, whats the reasoning behind it? —usernamekiran (talk) 22:00, 11 May 2022 (UTC)
I don't find the battleground mentality a useful way to build an encyclopedia. We don't fight. We write articles and make them better. Also, since you said "entire", I also oppose empowering any centralized group with extra powers in this regard. --Jayron32 11:40, 12 May 2022 (UTC)
I totally agree, with every point. I am glad that I asked for the clarification. Thanks for the response :-) —usernamekiran (talk) 20:11, 12 May 2022 (UTC)
Strongest possible oppose in line with Jayron and Praxidicae. — Ixtal( T / C ) ⁂ Join WP:FINANCE! 14:14, 10 May 2022 (UTC)
Oppose Lots of nasty stuff with little prospect of helping. North8000 (talk) 17:52, 10 May 2022 (UTC)
Neutral (UPE reporting)
Neutral so as not to pile on, and so as not to further set back the likelihood of doing something about UPE, because any more Opposes may be interpreted as opposing the need to improve the process of dealing with UPE. I am saddened that User:Timtrent decided to throw out a half-baked proposal, knowing that his objective was to avoid having a more detailed proposal torn apart, and so instead getting the whole idea torn apart. I had hoped to work out some idea about how to improve the UPE process at the Idea Lab, but this has probably left any such efforts dead for the next few months. COIN does not work consistently or well. We have two policies that interfere with each other, the rule against UPE, and the rule against outing, and we have given the wrong priority to the two, so that anonymity can be used for advertising. We have a good policy that isn't enforced, and we need better enforcement, and this idea has probably made discussion of better enforcement out of the question for a few months. Robert McClenon (talk) 16:55, 10 May 2022 (UTC)
@Alanscottwalker I think that this proposal may fail, but do not see how a failed proposal does not act as a catalyst for a better proposal. Nor do I understand why folk here seem unable or unwilling to modify the proposal or to create a counter-proposal.
You or anyone else are welcome to accuse me of naïve thinking if that is what I have shown and if you wish to, but I have always though that we, the community, were better than this, and could and would discuss proposals to reach one that we would agree on. 🇺🇦 FiddleTimtrentFaddleTalk to me 🇺🇦 12:53, 11 May 2022 (UTC)
For what it's worth, I don't think this proposal failing is any set back for other well thought proposals on UPE or COIN. MarioGom (talk) 21:27, 10 May 2022 (UTC)
@MarioGom Agree with you. Failed proposals can highlight a difficult area. A failure, which seems likely here, ought to act a catalyst for wiser heads than mine to create better proposals. I am wholly lost as an AFC reviewer. If I act in good faith over what I perceive as UPE I risk being pilloried for those acts at ANI as is happening to another editor at present. I have no formal route forward. I believe we need one, and a good proposal for one. Mine seems to be destined for failure, but so what? Better editors than I can create better proposals. 🇺🇦 FiddleTimtrentFaddleTalk to me 🇺🇦 13:14, 11 May 2022 (UTC)
A Sonchus Competition?
When I look at all of the Sonchus articles that have not been created, I feel like that something should be done to create all of the species in the Sonchus genus. What I think Wikipedia should do is either create a competition for the expansion or create a WikiProject for the Sonchus genus. I have already created Sonchus kirkii and Sonchus ustulatus but that is still not enough.
𝙷𝚎𝚕𝚕𝚘𝚑𝚎𝚊𝚛𝚝 (𝚃𝚊𝚕𝚔) 23:06, 12 May 2022 (UTC)
Have you tried asking for help at WP:TOL or any of the numerous subprojects? I don't know how active those are, but that would be the first place I would go for help. --Jayron32 18:03, 13 May 2022 (UTC)
I am not really sure that having a competition would be consistent with the goals of Wikipedia. YTKJ (talk) 18:26, 13 May 2022 (UTC)
There are quite a few competitions on Wikipedia, such as the WP:Wikicup and WP:The Core Contest, which stimulate friendly competition. I wouldn't say that's against the goals of Wikipedia at all. That said, it is difficult to find participants for competitions around small topic areas, like Sonchus, and seeking collaboration within a Wikiproject will likely be more fruitful. Femke (talk) 09:17, 14 May 2022 (UTC)
I have merged the guides and placed the result on Wikipedia:Post-move cleanup. It would be fine to have some of you fellow Wikipedians to review it and edit it if you find something that can be improved. Utfor (talk) 19:50, 12 May 2022 (UTC)
Funny timing! I just spent the last couple hours working on a draft of the same thing. It's mostly written from scratch, because I think there are some major issues with the guidance currently at WP:MOVE and WP:RMCI:
They over-emphasize certain cleanup tasks that are rarely necessary (e.g. fixing double redirects)
They fail to mention certain tasks which are important, like updating the article prose (beyond just the first mention) and renaming subsidiary pages (including categories and related mainspace articles)
There's some organizational kludginess. A bunch of cleanup tasks are only required when there's a change to topic structure, and they should probably be grouped together for that reason. Something like "Fixing fair use rationales" can be subsumed by the more general step of "Fix mistargeted wikilinks".
I think v1 of my draft should be done today - then maybe we can compare notes and decide which pieces to take from where? Colin M (talk) 20:38, 12 May 2022 (UTC)
Okay, I think my draft is at v1.0. Some notes on sections from the earlier guides which I deliberately did not include:
"Fixing fair use rationales": This is subsumed by the broader task of fixing mistargeted wikilinks.
"Address any technical restrictions": This comes up very rarely, and when it does cause issues, they're pretty easy to spot. Seems like it's not worth the WP:CREEP cost? If this is a thing that matters, we should give an example.
"Fix double redirects": These are taken care of by bots. Nuff said.
"Categorizing redirects": I don't really see this as an aspect of post-move cleanup. (Also not exactly a high-priority task.)
"Update talk page notifications": No idea what this section is saying.
"Wikidata update": I just don't understand this step. Under what circumstances is it necessary, and what are the benefits? Maybe an example would help here?
"Categories and subcategories": No idea what this section is saying.
I trust you fully; just make any changes you believe are improvements. Utfor (talk) 18:35, 13 May 2022 (UTC)
Okeydoke, for the sake of preserving history, rather than doing a cut-and-paste move, I've moved the merged old content you put together to userspace at User:Utfor/Merged postmove cleanup guidance and moved the version I started to Wikipedia:Cleaning up after a move. I'm going to go ahead and boldly update WP:MOVE and WP:RMCI with summary style links to this new page. Colin M (talk) 16:46, 14 May 2022 (UTC)
Wikipedia requires a subject index
Years of experience as a reader of this wikipedia lead me to notice that the category system cannot replace the efficiency of a subject index.
Every time there is a need to search for a topic of minor consideration or whose article has not yet been written, the reader must search within countless articles and categories both related and very collateral to the topic to be investigated, the typical case of unnecessary lateral thinking.
A general thematic index system and by categories could complement the current system of categories and articles in the event that the topic to be investigated does not meet the corpus of text or the necessary relevance to have its own article, in addition to being able to link individual paragraphs. and sections within articles that cover a different topic than the topic they mention.
The new system could link both categories, complete articles, sections or even individual paragraphs, the creation of these entries can be given directly as an addition to the edition summary with similar requirements to the creation of articles.
Perhaps what I'm proposing already exists in a way that I hadn't thought of, but the closest thing I can think of is the internal search, which doesn't perform this task.
As for the operating system, one could go to an alphabetical page where the different topics are described and these in turn contain content links. It could also be searched by categories of thematic indexes. — Preceding unsigned comment added by Diosverde (talk • contribs) 20:36, 14 May 2022 (UTC)
I think that's what WP:OUTLINES were intended to help with, but I don't see them used much. Schazjmd(talk) 20:45, 14 May 2022 (UTC)
Er, I think that Portals were intended for this, but... --Redrose64 🌹 (talk) 21:23, 14 May 2022 (UTC)
A lot of these traditional approaches (categories, indexes, portals) had the problem that you had to discern the mentality/organization of the system (including what "lens" was used for navigation/ classification) to use them but were the only thing available. The advent of google type searches or Wikipedia's own search bar do not have that issue and IMO have rendered those imo older methods obsolete. North8000 (talk) 23:01, 15 May 2022 (UTC)
Automatic Semi-Protection of In The News articles
I have noticed a drastically sharp increase of vandalism on articles when they get added to "In the News". My suggestion is to automatically semi-protect these articles for a period of time, Likely about 30 days, That or Review Edit Protection to allow people to still contribute to the articles, but in a safer matter, again for about 30 days. PerryPerryDTalk To Me 14:44, 16 May 2022 (UTC)
I have not, Thanks for the advice, I'll go do that immedietly PerryPerryDTalk To Me 14:59, 16 May 2022 (UTC)
Adding own talk contribs to "vandal" template
Sorry all, remembered that this was for a change in the workflow for requesting revocation of TPA into using AIV instead of ANI. Restructuring in a new proposal. 🐶 EpicPupper(he/him | talk) 02:10, 28 May 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.
Hello! I'd like to propose adding a "own talk contribs" link to {{vandal}}. This is helpful for tracking potential vandals, as they often post non-policy-compliant messages on their talk page. I have a draft implementation in the sandbox here; see the diff. An example of what the revised template would look like is below. Pinging @Suffusion of Yellow as I vaguely remember them requesting this, but can't find the post anymore. Cheers!
(The above is a usage example of the revised template.) 🐶 EpicPupper(he/him | talk) 15:14, 18 May 2022 (UTC)
The one place this template is non-optional, at least that I can think of, is AIV. For other occasions there's a whole load of other templates you can use (see Template:Userspace linking templates). You could also make up your own or get this linked from Template:User-multi. Sometimes this link may be useful, but as someone who looks at AIV reports, I would not find this a useful regular addition. Admins are already checking contribs and talk page histories. On the rare occasions something is obscured for whatever reason, an explanatory note would help identify the problem quicker than a link. YMMV. -- zzuuzz(talk) 15:55, 18 May 2022 (UTC)
Yeah I don't think this would really be useful, since contribs includes contribs to user talk and vandal contribs are usually pretty short. Galobtter (pingó mió) 22:53, 18 May 2022 (UTC)
Like the others, I see this as having limited utility to me as an admin, or really to anyone. I can see own user talk edits easily in the contribs list. Pulling them out on their own is certainly a thing we can do, but why really? --Jayron32 15:48, 20 May 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Bot-compiled lists of links to wikt:
When we do not have an article about the primary meaning of a term, we sometimes have a disambiguation page for the term instead. Before an article about the primary meaning was craeted, for example, moonrise was a dab page. It is now moved to moonrise (disambiguation), and the moonrise entry is redirected to moonrise and moonset. When editors wanted to link to moonrise, linking to the dab page is discouraged, so linking to wikt:moonrise is an alternative. But after the primary meaning is covered by an article, we need to retarget those links to point to Wikipedia, not Wiktionary. What about creating a regularly updated bot-compiled list? Human editors may then only need to fix the links manually, not track them down.
Specifically: A bot would look for [[wikt:$1]] in articles, and if [[$1]] exists and is not a dab page or a redirect to a dab page, then the bot adds [[$1]] to the list. ($1 here represents a wildcard.) Utfor (talk) 19:56, 24 May 2022 (UTC)
@Utfor:Here is a Quarry query which attempts to list the links. Certes (talk) 00:42, 28 May 2022 (UTC)
Some of these links could be deliberate and still be appropriate even if an article exists. —Kusma (talk) 13:29, 28 May 2022 (UTC)
@Utfor: Yes, the query lists all links to Wiktionary, even if the [[wikt:?]] text is within a template rather than explicitly in the article. A. C. Milan already links to Milan, so the link (via template) to wikt:Milan doesn't add much and could be removed. Certes (talk) 22:37, 28 May 2022 (UTC)
@Certes, you might want to remove disambiguation pages, which often link to Wiktionary correctly. ― Qwerfjkltalk 10:07, 29 May 2022 (UTC)
@Qwerfjkl: Good idea. That reduces the count from 12862 to 7900. I've also removed cases where the Wiktionary entry matches the linking page or a redirect to it. Beware that some Wikipedia articles are about a different topic to the similarly named Wiktionary link. For example, 187 (slang) links to wikt:187 which defines the slang term, whereas 187 in Wikipedia is about a year. Certes (talk) 13:28, 29 May 2022 (UTC)
As a regular Wiktionary contributor, is this something it’s worth doing in a more coordinated fashion between both projects? We equally have a big backlog (and a similar degree of inconsistency) in linking to the appropriate Wikipedia page. It would be good to have a joint-project effort to keep them consistent (even if it’s just a small handful of people overall). Theknightwho (talk) 14:15, 31 May 2022 (UTC)
Medon
Being handled at a more specific venue. — xaosfluxTalk 14:19, 31 May 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.
Medon needs a disambiguation page. The existing page is about mythology. Should it be transformed into a disambiguation page or should we start a new page ? --Io Herodotus (talk) 05:36, 29 May 2022 (UTC)
OK. I post it there. --Io Herodotus (talk) 12:55, 29 May 2022 (UTC)
Other option is talk about this at the article talk page. — xaosfluxTalk 14:19, 31 May 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Add CC-BY-SA logo
OP is CU Blocked - if someone wants to seriously bring this up, links are below. — xaosfluxTalk 23:28, 31 May 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.
All wikis under the CC-BY-SA license have its logo at the bottom. I think the WMF needs to add it to the bottom next to the WMF logo. TOPaner (talk) 10:19, 31 May 2022 (UTC)
@TOPaner this doesn't seem like a proposal specific to here on the English Wikipedia. If you want to propose that the footer for all of the hundreds of WMF projects get changed you should follow up at meta:Requests for comment. — xaosfluxTalk 14:18, 31 May 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Limit on number of AfD/PROD nominations made per day
Good faith proposal that has a WP:SNOW chance of being enacted. Let's consider other proposals. – Muboshgu (talk) 17:49, 1 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.
I'm not sure whether this proposal should be here or in Village pump (policy); please forgive me if I have the wrong venue. I'm proposing this in response to a recent ANI complaint against a particular editor, accused of flooding AfD with so many nominations that there isn't time to give them due consideration. One of the remedies being considered against the editor is a limit on how many AfD nominations they can make each day. I have suggested that it would be better if such a limit applied to everyone, and there was some support.
My proposal is that No editor should be permitted to make more than 5 nominations to AfD per day.
Naturally I welcome other limits; 5 is a number plucked from thin air. Ideally this limit should be enforced technically, but I don't know if that's possible.
The reasoning behind this is that (1) it takes time to do a proper BEFORE, so most editors won't be making good AfD nominations if they are making more than 5 a day, and (2) if AfD gets flooded, constructive editors there who would like to search for sourcing, and investigate the notability of subjects properly, are overwhelmed, and we run the risk of deleting articles that could and should have been cleaned up, undermining the entire AfD procedure. Naturally the proposal is not intended to stop bulk AfD nominations of sets of articles that are so closely related that a single AfD discussion applies to all. These should count as a single AfD. Elemimele (talk) 22:48, 31 May 2022 (UTC)
Absolutely not, unless we are limiting article creation per day. You cannot limit deletion venues if we do not limit creation venues. PRAXIDICAE💕 22:51, 31 May 2022 (UTC)
@Praxidicae: I actually agree: I would have no problem with limiting the number of creations too. If anyone is creating more than 5 articles per day, they probably aren't creating particularly well-researched articles. I am also worried that the AfC backlog is huge, which encourages people to shift articles into main-space before they're ready, but that's a different issue. Elemimele (talk) 23:05, 31 May 2022 (UTC)
It's not going to happen, this isn't a meaningful proposal and not well thought out. PRAXIDICAE💕 23:07, 31 May 2022 (UTC)
I think it's OK to create six or more stubs a day. There are people who take lists of artists, or politicians or sports people, or writers that have tended to be not included and add them as stubs, others improve them later. This is a good thing. CT55555 (talk) 23:09, 31 May 2022 (UTC)
While I'm in favor of curbing the television, sports (mostly Olympians, cricket) articles, this is a solution in search of a problem. The vast majority of users don't list one or even five at xfD and those who do have a reason for it. Sanction those who are outside the norm, don't punish the community for something 99% aren't doing. StarMississippi 22:58, 31 May 2022 (UTC)
I understand the motivation. Five does seem like a reasonable limit. I wonder if (and especially in the context of the WP:ANI discussion there could be a limit tied to ability/competence. For example if someone is proposing 10 deletion per day and they are consistently met with unanimous agreement, then that sounds like good work. If they are proposing 10 a day and usually proposing them without proper WP:BEFORE searches, missing good sources, that is what concerns me.
So if limits could be tied to skills/competence, that would be maybe a better path forward.
Likewise, there is not need to limit article creation per day if the editor has demonstrated competence, but if they are creating 4 per day that tend to get deleted, we should limit that too. But I think that side of the argument should be made in a different discussion. CT55555 (talk) 23:02, 31 May 2022 (UTC)
How many editors make more than 5 AFD nominations per day? How many create more than 5 articles per day? Neither of these are broad structural problems; they are very personal problems, involving like less than 10 people on Earth. Levivich 23:07, 31 May 2022 (UTC)
Given the inherent drama involved in calling those users to task when they cause problems I believe a more general solution is preferable. If it really is just ten people they seem to be creating a disproportionate amount of fuss. Artw (talk) 23:19, 31 May 2022 (UTC)
Creating a new rule that applies to 99.9% of people because 0.1% of people cause drama when called to task is a terrible idea. That is the direct opposite of how to handle this problem. And yes, they do create a disproportionate amount of fuss, this thread here being an example of same. Levivich 23:22, 31 May 2022 (UTC)
On 3/29, I put up 6 articles (result 4 delete, 2 keep) because I was working through old promotional tags. I don't think the community would have benefited from me skipping one of the ones that ultimately was keep and the 6th of the day was a delete, which may have continued sitting as promotional material for years as old categories are infrequently cleaned up. We are all volunteers and don't want to limit productivity arbitrarily as who knows when a user will have time to continue their self appointed project.Slywriter (talk) 23:13, 31 May 2022 (UTC)
Support Would be extremely helpful in discouraging the spamming of the AfD process with low quality nominations where WP:BEFORE has not been performed or has been performed sloppily. Artw (talk) 23:19, 31 May 2022 (UTC)
Would also support a weekly rather than daily limit to allow more flexibility, though it probably should be more like 15 than 35. Artw (talk) 23:22, 31 May 2022 (UTC)
Another idea that echos what User:Artw is talking about would be to force people to show the results of their WP:BEFORE searches. I nudged someone yesterday on this and it quickly resulted in them seeing for themselves the notability:
We could write a template that, given a set of keywords, spits out the requisite searches. That would help everyone: nominators and nomination reviewers. That template could then be a standard part of the nomination. — rsjaffe🗣️ 23:34, 31 May 2022 (UTC)
This would be an improvement. In the example above I didn't care enough to do the searching, but after I nudged the nominator to do so, it was easy for me to illustrate the notability. So I consider this an excellent suggestion. CT55555 (talk) 23:38, 31 May 2022 (UTC)
My experience lately is unfortunately that you would have to re-run all the searches again anyway as verification because for whatever reason nominators have been "missing" results on obvious searches they really should have seen.
A counter suggestion would be that if it becomes super obvious that a user has not done BEFORE that they claim they have the AfD should be immediately closed. Artw (talk) 23:36, 31 May 2022 (UTC)
What do you think about my idea above - the number of AfDs being tied to competency? For example:
If less than 50% of the articles you nominates for deletion are deleted, you are limited to one per day
60% 2 per day
70% 3 per day
80% 10 per day
85% no limit CT55555 (talk) 23:40, 31 May 2022 (UTC)
No. Artificial limits are ill conceived. If I spot more than five pieces of trash a day and may only nominate five that may help with a backlog, bit it does not help with Wikipedia quality. Just no. 🇺🇦 FiddleTimtrentFaddleTalk to me 🇺🇦 23:32, 31 May 2022 (UTC)
Strong oppose (as a note for those unaware, this is borne from this ANI thread, where TPH came under criticism for nominating an inordinate number of articles for deletion; something like 10 AfDs and 35 PRODs a day.). This is just blatant WP:RULECREEP in my opinion. If someone is nominating a huge number of AfDs as TPH was, just leave a message at their talk page. If they continue, then consider posting to ANI so that an admin can take a look. We already have an AfD limit, granted it's unwritten and up to interpretation how much is too much, but we are effectively doing exactly what this proposal suggests. But let's say hypothetically this proposal passes and someone goes over the hard limit of 5 (let's assume for purposes that there is good-faith intent and the articles are worthy of an AfD discussion). What then? Do we nuke the extra AfDs even though they are valid? Do we instantly TBAN the user from AfDs even though they are doing their due diligence? No, we would do exactly what we are doing at this very moment: letting them know on their talk page, and escalating to a different venue if that fails. Curbon7 (talk) 23:35, 31 May 2022 (UTC)
Ah I took 35 by the average number that was stated in the ANI thread. Curbon7 (talk) 01:15, 1 June 2022 (UTC)
Nope. We don't need to create a one-size-fits-all sitewide policy to address one editor's conduct. If an editor is flooding any deliberative process with requests, then we can address that on an individual basis. As well, the issue with TenPoundHammer's nominations is at least as much with their quality as their quantity. If all of his deletion nominations were well-founded, and a significant supermajority actually resulted in article deletions, we probably wouldn't be having this discussion. TenOfAllTrades(talk) 23:35, 31 May 2022 (UTC)
No as has been said afd is a facet of article creation, and this would create needless bureaucracy. - LCU ActivelyDisinterested∆transmissions∆ °co-ords° 23:39, 31 May 2022 (UTC)
After some more thought I believe this is looking at the issue the wrong way. The problem is lack of people to properly review afd, not the quantity of them. Of course that's hampered by people being putoff participation by how toxic the environment can be. - LCU ActivelyDisinterested∆transmissions∆ °co-ords° 00:29, 1 June 2022 (UTC)
Oppose all limits: this instruction creep would be inflexible, but the appropriate rate of nominations is dependent on the size of the community and the type of nominations made. Any rule like this should be for a temporary period only, not indefinite because the limit would be so arbitrary, but it is so rarely a problem that it makes sense to deal with these issues on an ad hoc and often editor-specific basis. — Bilorv (talk) 23:44, 31 May 2022 (UTC)
Only extended-confirmed editors should be making more than 5 AfD noms per day and nominating an easily-sourced article without good reason should be a one-way ticket to a topic ban. And so should !voting keep on an article with no inline citations.—S MarshallT/C 23:48, 31 May 2022 (UTC)
I'm assuming you meant something different by your last sentence than how it actually reads, because that literally goes against AfD procedure. If an article has no ilc, but is definitively notable via meeting WP:GNG or some other criteria, then who cares if there are no ilc. For example, if this chap got put up for AfD, everyone would vote !keep, as he obviously meets notability criteria even though there are no ilc. Curbon7 (talk) 00:37, 1 June 2022 (UTC)
Caveats withstanding of WP:BLP, WP:V, etc, of course still apply; I'm just giving a generalized statement as to why that would be a poor idea. Curbon7 (talk) 00:39, 1 June 2022 (UTC)
WP:V is of course the controlling policy here. It includes WP:BURDEN: our core content policies require that everything challenged or likely to be challenged is supported by an inline citations. An AfD nomination is a challenge.—S MarshallT/C 08:02, 1 June 2022 (UTC)
Strong oppose - instruction creep, would seriously hamper NPP if set as low as 5. signed, Rosguilltalk 01:34, 1 June 2022 (UTC)
Oppose We need to fix the AfD process and should have a separate discussion for that. I'll throw out a few brief ideas in followups to this vote, just to give a view of how much change might be useful.— rsjaffe🗣️ 01:39, 1 June 2022 (UTC)
Example 1: Completely retool the AfD process to mirror the new page patrol process. No more !votes. Have a set of approved (and trained) AfD reviewers who review the AfD and either approve or deny. Quality control would be enforced upon the reviewers, and we'd give the diligent ones treats (cookies, barnstars, etc.) — rsjaffe🗣️ 01:41, 1 June 2022 (UTC)
Mate this literally just defeats the purpose of AfD, and is a recipe for disaster. There are numerous instances of 11th hour saves; I just had one a few weeks ago with Wikipedia:Articles for deletion/Bailey Walsh (note that 3 very experienced editors voted !delete before I came to the rescue). This will do probably 2 things: (1) slow down AfD reviewing to a grinding halt, as reviewers will have to spend ages grinding through every source repository lest they delete someone notable, and (2) easily incite carelessness, as some reviewers will want to speed through the review process and half-ass it. #2 will then lead to god-knows how many hours other people will have to spend re-reviewing all of the articles that the rushing reviewer poorly reviewed. That sounds so painful that I seriously doubt any sane person would even volunteer, so you'll then be left with a handful of reviewers, even less people active in AfD than at present. Sorry for the long reply, but I really had to map out why this is a very bad idea. Curbon7 (talk) 02:10, 1 June 2022 (UTC)
That's fine. I'm just spitballing here. The point is, we need to have a separate discussion to think carefully about the whole process. There are going to be tradeoffs to any solution, so we'll need to carefully think things through. — rsjaffe🗣️ 02:13, 1 June 2022 (UTC)
Example 2: Instead of immediately presenting AfDs for discussion, have nominators choose one of two queues. "Fast queue" for articles of obviously no worth but that don't meet criteria for speedy deletion. Placing articles in that queue is a privilege automatically given to extended-confirmed users, but is a separate privilege that can be withdrawn if abused. Other articles, where the question is whether they're notable enough or not, would go into the "slow queue" that would be dispensed for review at a controlled rate. If the queue gets too large, actively recruit more reviewers and give the diligent ones treats (cookies, barnstars, etc.) — rsjaffe🗣️ 01:45, 1 June 2022 (UTC)
On second thought, there'd have to be more consideration of what criteria should be for fast queue. That's a matter for discussion. — rsjaffe🗣️ 01:47, 1 June 2022 (UTC)
We could even just have one queue, but have trained AfD reviewers who could patrol the queue and pull out the simpler ones and treat them like the plan in Example 1. — rsjaffe🗣️ 01:49, 1 June 2022 (UTC)
I'm liking example 2 less and less. — rsjaffe🗣️ 01:50, 1 June 2022 (UTC)
I would suggest a better "metric" here is sustained rates of nominations. There can be fully legit reasons (such as a multi-AFD) to nominate more than 5 articles at once ... but there is very little reason to nomination more than 5 over a large period of time (week+), unless it is the result of an established RFC that a large volume of articles need deletion and volunteers are working through that backlog. Otherwise, that's on the order of WP:FAIT to do that many over that amount of time w/o consensus. --Masem (t) 02:13, 1 June 2022 (UTC)
Active new page patrollers could easily break that limit in a day. One of our primary responsibilities is to identify new articles that should be deleted. — rsjaffe🗣️ 02:17, 1 June 2022 (UTC)
Which to me falls under as a prior consensus based reason to delete. The case that led this was by one editor deciding a large number of articles had to go (reasonable) but at a sustained pace that FAIT would apply. --Masem (t) 02:18, 1 June 2022 (UTC)
Comment: 5 is way too low. I had been thinking more like 50 AfD within a week for most users as anything more than that will tax the limits of the people wanting to add to the articles. New page patrollers, admins, etc. wouldn't have a limit and also no limit for autoconfirmed on ProDs. Having said that I support the throwing around ideas of rsjaffe has been doing. Gusfriend (talk) 02:50, 1 June 2022 (UTC)
To join with the random ideas about improving the process my crazy idea would be for there to be a button (or process) so that if the result is to delete then any user can have the page copied into their sandbox. This would mean that there would be less of a concern about effort being wasted and if someone has an inkling that there is some information that they can add then they can work on it before sending it to AfC. In other words, we accept that there will be too many to properly deal with during the timeframe and give people a better chance to work on it personal draftspace. Gusfriend (talk) 02:54, 1 June 2022 (UTC)
Oppose Although rapid-fire nominations with low accuracy are problematic, not all bulk nominations are created equal. This proposal would preclude bulk AfD nominations of similar pages (sometimes used where many similar articles have a shared problem other than mere lack of notability); as well as cases where a large number of similar articles are AfD'd separately or PRODded because they are all likely non-notable, but still need to be assessed individually. –LaundryPizza03 (dc̄) 06:42, 1 June 2022 (UTC)
Okay this is pretty close to a snow close situation! But reading the comments, would there be any merit in having a limit that depends on being granted a particular right, along the lines of autopatrolled for article creation: if you're given that right, you can nominate as many AfD's as you want (and it would naturally be given to new page patrollers/AfC people, who will need to nominate many poorly-created pages for deletion)? But it may be over bureaucratic.
My concern is that although I've tried to contribute to AfD, I'm becoming depressed by the lack of thought going into the process. There are too many people going into it with the mentality of an X-factor/America's-got-talent jury, expecting to assess an article at a glance, and with their finger on the Button of Power. We have to remember that AfD is about creating a better encyclopaedia, not about racing to delete as much as we can, as fast as we can. Some topics are quite hard to investigate, and need time and effort; if we carry on as we are, we're going to end up as a fan site for the film and sports industries rather than an encyclopaedia, because those are the industries that create the sort of easily-accessible, impossible-to-miss sourcing that even the most hard-core deletionist will fail to overlook. Meanwhile, anything that happened before 1980 is doomed because (almost) no one at AfD can be bothered to look at paper sources any more. Elemimele (talk) 08:50, 1 June 2022 (UTC)
There is true in what you say, there are people who vote 99%+ delete only for more careful commenters to find sources after and who don't change their mind in the face of any amount of sourcing. CT55555 (talk) 11:50, 1 June 2022 (UTC)
Strong Oppose - sometimes bulk nominations are warranted. Have we even thought about how this would be policed or actioned given that so many users use scripts to nominate? You don't change a whole system because I one editor has been problematic. Also if you limited the number of AFDs/PRODs you should also limit the number of new article creations. I get that people are worried that so many articles are being nominated that there isn't opportunity to discuss them but equally so many articles get created that don't meet our standards and fly under the radar. There are also so many articles that shouldn't exist too. The bigger issue is that the first port of call should be to look for reliable sources/coveragebefore nominating for deletion. ≫ Lil-Unique1-{ Talk }- 10:18, 1 June 2022 (UTC)
Oppose I once went through about 150 AfDs in a week (mostly bulks) because of a huge issue with UAE place names and a problematic early admin/editor. That apart - admittedly a one-off - on a good day, an active NPP editor would easily see a need for more AfDs than this - as per User:Rosguill above. Best Alexandermcnabb (talk) 10:51, 1 June 2022 (UTC)
Practical questions for those who support this: How would a limit be enforced? What would happen if an editor goes over the limit (Ban? Block? Report to ANI? Some sort of warning template?). Just saying “There oughta be a rule!” is not enough. Blueboar (talk) 11:57, 1 June 2022 (UTC)
Oppose Having a blanket restriction on the number of AfDs doesn't address the problem of low quality nominations. Such a limit will put an undue burden on experienced editors using AfD for legitimate purposes (e.g. NPP). Qwaiiplayer (talk) 12:44, 1 June 2022 (UTC)
Oppose because shotguns are a poor way to deal with mosquitos. AndyTheGrump (talk) 12:47, 1 June 2022 (UTC)
Suggest someone snow-closes this; Okay, it was me who started this, so I probably shouldn't close it, but in view of the overwhelming opposition, I'm prepared to accept this is a very dead duck. It was only an idea, and sometimes ideas can make the journey from village pump to village stocks rather quickly... Elemimele (talk) 17:39, 1 June 2022 (UTC)
Good faith proposals should never lead to anyone being sent to the stocks. We use the pillory for this. – Muboshgu (talk) 17:48, 1 June 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Competence requirement at Articles for Deletion
This proposal has been withdrawn by its author. ─ The Aafī on Mobile(talk) 19:41, 1 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 recently closed idea above was firmly rejected as editors were overwhelmingly protecting of the bona fide need for new page patrol members and others working to remove cruft from nominating many articles for deletion per day.
However, I'd like to propose a much more refined idea, that I think addresses the motivations above, and the concerns expressed above. It is an idea that simply limits people at the problematic intersection of low-competence and high-delete-enthusiasm.
The specifics could be refined. But perhaps a limit based on ability to identify articles to be deleted ought to be enacted. For example if an editor overwhelmingly get's AfD's wrong, they probably should not be nominating many. If they overwhelmingly get it right, there's no need to interfere. And for those in borderline situations, borderline restrictions are appropriate.
If the majority of an editors AfD votes are wrong (based on community consensus at close), we limit to 1 AfD nomination per day
If they get it wrong 25% to 50% of the time, we limit to 5 AfD nominations per day
If they get it wrong 15% to 25% of the time, we limit to 10 AfD nominations per day
If they can get it right 85% or more of the time, there's no need to limit anything
Such rules would do nothing other than somewhat limit the most ferocious and incompetent and mildly limit those with mild learning to do and place no barriers for any competent or even carefully incompetent editor. CT55555 (talk) 18:22, 1 June 2022 (UTC)
Still strong oppose as instruction creep and a bureaucratic headache to implement in practice. Enforcing limits based on an arbitrary accuracy cutoff would encourage gaming behaviors at AfD, and much more important than an editor's right/wrong record at AfD is the quality of their participation: I don't care if an editor has a low match rate if their dissenting opinions are supported by reasonable, policy-based arguments (and conversely, the editor who has a 100% AfD rate that is 99% pile-on votes contributes nothing to the encyclopedia). Bean-counting over this would disincentivize people from weighing in on difficult cases, which are often the ones that most need additional participation. In my biased opinion, the above discussion shows a clear community consensus against any sort of community-wide, systematic rate-limiting at AfD, without precluding the application of rate-limits as sanctions for individual, problematic editors following community discussion. signed, Rosguilltalk 18:30, 1 June 2022 (UTC)
You make a good point about the accidental consequences - gamification thing. Is there a way to limit those who are bad at it that is more nuanced than what I proposed?
Right now the current WP:ANI debate is unavoidably about an individual and it would seem kinder to have a general rule. CT55555 (talk) 18:36, 1 June 2022 (UTC)
Making a rule that applies to 100% of the people in order to stop a problem with 1% of the people is never going to fly. Ask yourself: How many people make more than 5 or 10 noms a day? How many AFD noms get it wrong >50% of the time? And are you seriously purporting to limit people's contributions if they get it wrong 15-25% of the time? What the heck is your error rate, I wonder? :-P And what does "get it wrong" mean, anyway? Is AFD like an examination or something, where there is one right answer?
This entire notion of putting blanket restrictions on people's AFD contributions is an example of "solution in search of a problem". First demonstrate with evidence that there actually is a problem with AFD that needs resolving. Then we can talk about solutions.
By the way, 99% of articles are never nominated for AFD. Don't forget that. AFD in its entirety is a tiny corner of the encyclopedia with relatively few regulars. The notion that we're going to bother tens of thousands of editors with a rule (an entire evaluation scheme with punishments, in fact), just because of one editor at ANI...? That really is dead on arrival; nothing like this will ever get consensus. The tens of thousands of us who aren't affected don't want to be bothered. Levivich 18:39, 1 June 2022 (UTC)
There is a tool that shows any users most recent 200 AfD votes and if they matches the community consensus at close. I've used "wrong" as a shorthand for that. Anytime I've used the tool, invariably people are making errors around the 10% rate.
For those who are unaffected by this, sorry for taking up space. But for the AfD regulars, the high volume of erroneous nominations is taking up a lot of time. CT55555 (talk) 18:42, 1 June 2022 (UTC)
You're not exactly the spokesperson for AFD regulars and aside from a handful of the regular complainers, I don't think anyone else is saying this is a big problem. PRAXIDICAE💕 18:46, 1 June 2022 (UTC)
I make no claim to be a spokes person for anyone. I have however observed frustration from people overloaded at AfD, so I don't think I'm saying anything controversial. CT55555 (talk) 18:53, 1 June 2022 (UTC)
What high volume of erroneous nominations? What's the evidence of this? Exactly how many nominations, over what period of time, and how are you considering them "erroneous"?
Another thing: do you think that if someone nominates an article for deletion, and it is kept, that this is "wrong" or "erroneous"? That the nom shouldn't have been made? It was a mistake? None of this is true. To figure out if a nom is a "bad" nom (a disruptive one), one must look far deeper than just the outcome of the nom. AFD stats aren't the be-all/end-all of the story. In many, I bet most, cases, when an article is nom'd but kept, it's because the search for sources by multiple people demonstrates notability, when prior efforts, usually by fewer people, did not. That's not a mistake or an error. It's just crowdsourced discussion.
Get away from the idea that a nom that's kept is a mistake and that we need a rule to reduce those mistakes. One hint that what I'm saying is true is the outcome of the prior thread on this page; another hint is the apparent outcome of the ANI thread. Levivich 18:47, 1 June 2022 (UTC)
Hi, lots of questions in there, here's my answer.
What high volume of erroneous nominations? - There's a discussion at WP:ANI about an editors who nominates dozens per day, most of which end up in keep.
What's the evidence of this? - as above
Exactly how many nominations, over what period of time, and how are you considering them "erroneous"? - Hundreds, weeks and months, when I say wrong, that's my short hand for "proposed for deletion, but community consensus was to keep" and I'm using the tool here to assess
do you think that if someone nominates an article for deletion, and it is kept, that this is "wrong" or "erroneous"? - Yes, basically I do. There is nuance. But basically if someone nominates something saying it's not notable and them someone does a WP:BEFORE search and proves it is (that's the normal chain of events) it does suggest rushing on behalf of the nominator and that is likely a mistake. There's exceptions, nuance etc, but that's the run of the mill chain of events at AfD in my observations. CT55555 (talk) 19:01, 1 June 2022 (UTC)
A feature of what I proposed is that it is not "blanket" at all. It's a relative face-cloth/flannel, that will only land on the tiny group of people who nominate unusually high volumes of poorly identified articles for deletion. CT55555 (talk) 18:46, 1 June 2022 (UTC)
oppose and oppose any further nonsensical proposals here about this matter. This is not only redundant and bordering on WP:CREEP, WP:CIR already exists and is required everywhere. These may be good faith proposals but they are time sinks, solutions in search of a problem. PRAXIDICAE💕 18:44, 1 June 2022 (UTC)
My proposal was made merely minutes ago. I think I can only have taken a few minutes of your time at most, which is a tiny fraction compared to the labour being put in by those working to save good articles at AfD. CT55555 (talk) 18:50, 1 June 2022 (UTC)
That's not my point, or Lev's, at least I don't think. What is the purpose of these go-nowhere proposals? They are solutions in search of a problem or you just don't understand, truly, how AFD works. This is a non-starter and non-problem. If one editor is causing major issues, that is dealt with at ANI or ArbCom. This isn't an AFD wide problem. PRAXIDICAE💕 18:52, 1 June 2022 (UTC)
I do perceive there to be a problem at AfD. I said nothing of it until recently. I considered the recent WP:ANI to confirm this, and so have made an honest good faith attempt to improve things. I respect your right to disagree that there is a problem. CT55555 (talk) 18:54, 1 June 2022 (UTC)
That's a problem with one editor. That is being dealt with at ANI. Applying extremely ambiguous arbitrary sanctions to all editors helps what, exactly? Especially when WP:CIR applies everywhere and I see no evidence that it hasn't been upheld as a group, as opposed to by individual editors at AFD and I don't see any such evidence from your proposal(s) on the matter. PRAXIDICAE💕 18:58, 1 June 2022 (UTC)
Making a fair set of rules rather than making it all about one editor did seem fairer to that person, to me. CT55555 (talk) 19:02, 1 June 2022 (UTC)
What about the current rules are unfair or problematic? You haven't presented any evidence that this is a larger problem than a handful of editors who are currently or have been dealt with. PRAXIDICAE💕 19:08, 1 June 2022 (UTC)
I deleted my first reply, as I misunderstood the question. My perception is that it's more fair to have a rule for everyone than us all discussing one editor in the level of details necessary. CT55555 (talk) 19:14, 1 June 2022 (UTC)
Except the problem isn't with all editors, unless you have proof otherwise. There is no evidence the current rate of nominations by pretty much everyone else is problematic or do you have specific evidence of that? PRAXIDICAE💕 19:19, 1 June 2022 (UTC)
You make a fair point here. I think the current case is the only one. I make this (clearly failing) suggestion to depersonalise this from that editor and to protect things in future, but I see the widespread rejection of this idea, so I'll answer your questions, but clearly this isn't going anywhere. CT55555 (talk) 19:22, 1 June 2022 (UTC)
The last time I recall someone talking about the labor being put in by those working to save good articles at AFD, it was User:Lightburst, who stopped editing around the same time you started, about eight months ago. With all due respect, eight months of experience isn't enough experience to be proposing policy changes at the pump. This should have been brought up as an idea at WP:VPIL or WT:AFD first. Levivich 18:59, 1 June 2022 (UTC)
That's a strange thing to say about User:Lightburst and reads like you're implying that I am them. My comments were a paraphrase of User:Cunard from here
I'm somewhat new in terms of time served here. I did not know there was minimum experience to propose ideas here. I have not done so before, but as this is on a topic where I spend most of my time (i.e. AfD) I felt it was reasonable to do so. CT55555 (talk) 19:09, 1 June 2022 (UTC)
There are several things wrong with this proposal, but the one that I think is wrongest is the evaluation of editors by their agreement with the final decision. Such a system would be extremely trivial to game, so I don't think that I'm giving anything away by saying that it would be possible to increase the percentage to anything wanted by giving opinions in discussions that are heading for an obvious result. Phil Bridger (talk) 18:53, 1 June 2022 (UTC)
Yeag, User:Rosguill pointed that out quickly and it's a good point. It's a non starter if that can't be fixed. I accept that. CT55555 (talk) 18:55, 1 June 2022 (UTC)
Oppose Anything to fix AfD that doesn't address the broken process is a bandaid on a gaping wound. Not worth it, and probably cause more harm than good. — rsjaffe🗣️ 19:04, 1 June 2022 (UTC)
Oppose. It seems to me this whole concept is based on "If the article is kept, the nomination was wrong", which seems contradictory to the what a Keep decision means in AfD. It means the consensus was that there was not a valid basis to delete the article. Determining consensus is not a binary "correct/incorrect" value-call, consensus can change over time, and consensus is sometimes based on who participates in the discussion and what points are raised in that discussion. Besides the problems raised above, this proposal is contrary to the very nature of consensus on Wikipedia. Singularity42 (talk) 19:13, 1 June 2022 (UTC)
And lack of consensus will also result in "keep", even though that is a good indication that the nomination wasn't reckless. And consensus is sometimes based on who participates in the discussion and what points are raised in that discussion really needs to be emphasized. Because of low participation, we get some really idiosyncratic results. — rsjaffe🗣️ 19:31, 1 June 2022 (UTC)
I recognise the truth in your comment, but my (flawed, it's not going anywhere, but I'll reply anyway to clarify) theory was a bit more nuanced than that, there is a tool that can show if proposed deletions were kept due to no consensus and separate that from being kept due to actual consensus to keep. i.e. there are less crude ways to do this than what you think I was proposing, that is not to say my proposal captured all the nuance. CT55555 (talk) 19:34, 1 June 2022 (UTC)
Comment (by idea author) This isn't going anywhere, so I'll withdraw the idea to prevent further pile on. CT55555 (talk) 19:30, 1 June 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Top banner proposal: portals links removed and language switcher added
Proposed addition of portals contents link to {{Other areas of Wikipedia}}
02:00, 15 March 2022 (UTC)
Support ― Qwerfjkltalk 07:05, 16 March 2022 (UTC)
The page "$3" (links | edit) has been moved to "$4" (edit | history | links | revert | log) (move log)
There is currently a discussion at Wikipedia talk: Requests for adminship regarding changing the display of ongoing RfXs in the RfA Page. The thread is Wikipedia_talk:Requests_for_adminship#RfC_on_display_of_vote_totals. Thank you.— Ixtal ⁂ (talk) 22:50, 25 April 2022 (UTC)
Oppose - if a reader is searching for an article, why would they want a portal? ― Qwerfjkltalk 19:27, 3 May 2022 (UTC)
AndyTheGrump (talk) 12:27, 1 May 2022 (UTC)
