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.
Support as proposer. We still haven't fully cleaned up the mess that are the Lugstubs. A vast majority of these articles, if not all of them, solely reference to Olympic databases, no indication alone of fulfilling GNG. While there are some articles which can notable, a vast majority of them fail WP:NOLYMPIC, though to give a chance for them to be reviewed and remaining on Wikipedia, instead of mass-PRODification, akin to the passed WP:LUGSTUBS and WP:LUGSTUBS2, I propose that these over 22,000 Lugstubs, as part of LUGSTUBS3, be moved to draft space with a 36-month expiration date to give enough time for the good ones to be submitted to AFC and reviewed. This I believe is an appropriate concession between those who wish these article stay, and those who wish these articles be delete. InvadingInvader (userpage, talk) 18:28, 12 January 2024 (UTC)
Also, I think this would deserve more workshopping as there is almost for sure to be false positives in a massive 20,000+ article list generated by bot; the previous lugstubs discussions that were workshopped and were 25 times smaller still had many errors. BeanieFan11 (talk) 18:38, 12 January 2024 (UTC)
This is why I suggest mass drafting. That way, those who wish to work on these articles as well as potential false positives would be saved and returned, whilst the truly unnecessary Lugstubs would be purged. You can still hold your contest. InvadingInvader (userpage, talk) 18:48, 12 January 2024 (UTC)
@InvadingInvader: But there is no way anyone can work through 25,000 articles in that timeframe. Would you be willing to just temporarily withdraw this, do some workshopping, maybe hold the contest and re-propose at a later date? This would be a major disaster as it stands. BeanieFan11 (talk) 18:51, 12 January 2024 (UTC)
@InvadingInvader: I think we need more time to work everything out before diving straight into drastic measures. There are sure to be many false positives in this and this would result in the catastrophic removal of tens of thousands of articles. I suggest trying out the contest and seeing how that works first, and if it is unsuccessful, then we could resort to this. BeanieFan11 (talk) 18:53, 12 January 2024 (UTC)
Think of it this way - as it stands, 95% of these articles would never be found in draftspace and would be soon deleted. If we run the contest and it is successful, we could continue to do every so often it and work our way through in a more beneficial way that does not remove tens of thousands of potentially notable articles / that actually improves them. BeanieFan11 (talk) 18:55, 12 January 2024 (UTC)
They're not being removed. They're being sent to draftspace. Remember that there are about 110,000 active users on the English Wikipedia. That's (at a minimum) four users per one article. Even if it was only one user per draft, there would be time to save these articles if they meet the GNG. I'm proposing a 36-month deadline. That is more than enough time to find sources for these articles. And hey – if they end up being deleted, but more SIGCOV comes five years later, they can EASILY be re-created. InvadingInvader (userpage, talk) 18:55, 12 January 2024 (UTC)
95%+ of users here do not work in the Olympic area. This deadline is not long enough (also, see WP:NODEADLINE) and would likely have 95%+ of the articles deleted. My suggestion is the contest, which, if successful, could be repeated every so-often and would result in them being improved rather than deleted. BeanieFan11 (talk) 18:59, 12 January 2024 (UTC)
Move them to draftspace then to do it. Or userfy them. They don't belong in the mainspace until there is proof that they fulfill the GNG. InvadingInvader (userpage, talk) 19:00, 12 January 2024 (UTC)
That directly contradicts the notability policy I cited above. We are not required to draftifiy everything that does not at this very moment pass GNG with the current sourcing. BeanieFan11 (talk) 19:04, 12 January 2024 (UTC)
Seems closer to comparing apples to oranges. We aren't required to draftify everything, but we should. If something can't fulfill GNG, don't include it in the mainspace. That's why draftspace exists: to work on articles and get them into compliance. InvadingInvader (userpage, talk) 19:07, 12 January 2024 (UTC)
Past consensus disagrees. Per the discussions at LUGSTUBS and LUGSTUBS2, the community has agreed that these articles in most of their current state belongs in the draftspace, or at the very least not the mainspace. InvadingInvader (userpage, talk) 19:12, 12 January 2024 (UTC)
Those both passed by the skin of their teeth and affected much smaller quantities of articles. This proposal is too rushed and needs workshopping. BeanieFan11 (talk) 19:13, 12 January 2024 (UTC)
Quote the closure of LUGSTUBS2: a stronger consensus that they should not be left in mainspace. Skin of your teeth? InvadingInvader (userpage, talk) 19:15, 12 January 2024 (UTC)
Also from the closure: However, I would urge the proposers not to charge headlong into the draftification process without further thought. A lot of people are uncomfortable with the large number of articles—a list of 1200 people from different eras and different nations is very difficult for humans to parse and I would urge the proponents to break it down. BeanieFan11 (talk) 19:16, 12 January 2024 (UTC)
I would rather us go through them in a sensible and non-rushed way (WP:NORUSH), such as holding contests to improve the notable ones while steadily nominating others for deletion. BeanieFan11 (talk) 19:19, 12 January 2024 (UTC)
Why not do it in draftspace then for the time being? That's where articles are meant to be improved to be better than stub class InvadingInvader (userpage, talk) 19:22, 12 January 2024 (UTC)
Because draftspace makes it a rush and imposes a deadline (WP:NODEADLINE). Articles can be improved in mainspace too, you know. BeanieFan11 (talk) 19:23, 12 January 2024 (UTC)
That's why I proposed an extended deadline for drafts. Also that allows us to spare tens of thousands of AfD debates. InvadingInvader (userpage, talk) 19:25, 12 January 2024 (UTC)
It is still a deadline that is way too short; we do not have enough editors to go through nearly 1,000 tough-to-research articles a month. BeanieFan11 (talk) 19:26, 12 January 2024 (UTC)
You can always recruit more editors. Request a mass-messenger to send a mass message out. NPP does it all the time. InvadingInvader (userpage, talk) 19:27, 12 January 2024 (UTC)
Or we could just improve them in mainspace, which means that editors can work at their own pace without a imposed deadline that will result in mass deletion... You've been systematically PRODing and AFDing Olympians - I support your efforts there - but not 25,000 all at once. BeanieFan11 (talk) 19:29, 12 January 2024 (UTC)
Probably not productive to relitigate LUGSTUBS2 with a 70% shorter G13 immunity window. Needs workshopping, preferably at a dedicated page. Folly Mox (talk) 18:56, 12 January 2024 (UTC)
very strongly oppose. This has all the problems identified at the previous proposal (which only barely had consensus), only worse because of the vast number of articles that have not even been attempted to be pruned for false positives, etc. Thryduulf (talk) 11:05, 15 January 2024 (UTC)
Improvement to how Wikipedia handles multiple citations of the same source.
Currently multiple citations to the same source are handled reasonably well, with a number appearing in superscript in the body multiple times, with the same number appearing just once in the references list, with letters (a, b, c, etc) after the number allowing you to return to the exact place in the article that you were up to, however, the reader won't necessarily know whether they were up to a, b, c, or whatever. Sure, it's usually not too hard to find your place, but it could be made easier if the in-text superscript said for example, 8a, 8b, 8c, etc rather than just using the same repeated numeral for multiple citations of the same source. MathewMunro (talk) 05:38, 7 January 2024 (UTC)
When clicking the numbered link to get to the ref, the ref becomes highlighted. Maybe the specific 'a', 'b', etc. could be specially denoted there? That would be an extension with consistent behavior. Changing the way the footnote marker is written in the text seems more confusing to readers, since it suggests that either there are different refs ('8a' vs '8b') or that there are different subparts of ref 8 (some refs do bundle multiple entries). DMacks (talk) 05:50, 7 January 2024 (UTC)
Sure, the reference becomes highlighted, but whether you have to click on 'a' or 'b' or whatever to get back to where you were is not clear, whereas if the superscript in the body of the article said '8a' or '8b', it would be pretty clear which one you were up to. An alternative would be to differentially highlight the 'a' or 'b' after the '8' or whatever number & letter it was in the references after you click on the superscript number in the body of the article, so you know which letter to click on to get back to where you were, or some similar means of making it stand out so that people know which one is the one to click to get back to where they were. MathewMunro (talk) 10:23, 7 January 2024 (UTC)
It sounds like you are objecting to my proposal of do exactly what you later wrote as your alternative:) To wit, I wrote "clicking the numbered link to get to the ref...the specific 'a', 'b', etc. could be specially denoted [in the ref after clicking]". DMacks (talk) 14:11, 7 January 2024 (UTC)
Sorry, I didn't understand what you meant by 'Maybe the specific 'a', 'b', etc. could be specially denoted there?', but I'm on the same page now :)
And yes, that would be a smaller and for some a less confusing change. Highlighting the specific 'a', 'b', etc in a different colour would be one effective way of specially denoting which hyperlink to click on to get back to where you were. MathewMunro (talk) 14:39, 7 January 2024 (UTC)
This seems like it would be confusing in combination with T100645, which IMO would be far more useful than this. Particularly since it seems to me that the browser's back button is more convenient than trying to figure out whether 'a' or 'b' or whatever is the right tiny link to click to get back, assuming someone isn't just using the Reference Tooltips gadget in the first place. Anomie⚔14:05, 7 January 2024 (UTC)
That phab task looks like it would be a software replacement for {{rp}}? That sounds helpful. I agree that the idea floated here, of adding letters to the citation numbers[2b] would be more confusing than anything else, and imply a seperate work or portion of work supporting the cited claim despite actually being the same.[2a] Seems like it might also interfere directly with the citation style of some articles, which use ref groups to generate citation numbers with a similar format.[C 2]I'm not necessarily against a software patch to use javascript to change the metrics of the hopback link followed to make it easier to guess, but: the tiny sliver of the userbase that actually interfaces with citations probably reads them through an on-hover or single tap, without clicking through to the reflist; whenever I guess wrong, I tap "back" in the browser and guess again; most multiply cited sources shouldn't have so many different loci of citation that it's a difficult or tedious process to find the correct hopback link; and those that are cited that many times will probably be recognisable based on their oft repeated citation numeral, negating the need to click through to it after the initial few appearances. Folly Mox (talk) 14:29, 7 January 2024 (UTC)
Thanks for the tip. I didn't realise just using the browser's back button would take me back. Although I noticed that when using the back button, the reference will be somewhere on the page, depending on where it was (top, middle or bottom of the page) when you clicked on the reference, but clicking the correct 'a', 'b', 'c', etc hyperlink in the references will set the relevant line in the body of the article to the top of the page, making it easier to find. I realise that most people can find a reference that's somewhere on the page pretty easily, but it is easier to find it in my opinion if it's at the top of the page.
I accept that there are drawbacks of using a 1a, 1b, 1c, etc referencing style, and so forget about that. How about instead we do either one or preferably both of the following:
1. Make the back button take you to the place you were, but with the line containing the reference set to the top of the page; and
2. After you click a citation superscript numeral in the article's body, highlight & bold the relevant 'a', 'b', or 'c', etc in the references that you have to click on to get back to where you were?
Although, I just noticed that if you click the little '^' symbol in the references, it does exactly what I want it to do, and the hover works well too, so maybe it's just a matter of learning how to use it properly :) although, there's nothing wrong with having multiple ways of accomplishing the same thing. MathewMunro (talk) 14:49, 7 January 2024 (UTC)
Neither of these is a good idea. We should not attempt to change how the browser's "back" button behaves. Some websites do this, by various means including server-side immediate redirection, client-side immediate redirection, and Javascript that actually modifies the botton's action. It can mean that you get trapped on that website with no way of getting back to where you came from - this might of course be intentional, but it's not what we want for our readers.
When you follow a link from a superscripted ref marker to the ref itself, or from the backlink on the ref to the superscripted ref marker, the place that you reach gains a pale blue background; this is due to a CSS rule:
The first selector (ol.references li:target) goes for a whole list item in the references section. To pick out an individual backlink within that list item could be possible, but would mean that the individual backlink would need to be the target of the link from the superscripted ref marker, and since this is not the whole ref, the pale blue background would be less visible. Such changes - even if agreed on here - would need to be requested through phab:. --Redrose64 🌹 (talk) 18:18, 7 January 2024 (UTC)
Agreed modifying the back button behaviour would be bad if it had any kind of spill-over effect trapping you on a page. I certainly don't know enough about web-programming to know whether or not it could be done in a way that only does what it's supposed to do on all browsers & devices. And if you had to choose between highlighting the whole reference and highlighting just the relevant 'a' or 'b' or whatever, you would certainly be better off just leaving it the way it is, especially seeing as clicking the '^' symbol takes you back to where you were even if you don't know whether it was reference 'a' or 'b' or whatever. But if you could differentially highlight both the whole reference and the relevant 'a' or 'b' or whatever, (or change the text colour of the relevant 'a' or 'b' or whatever in addition to highlighting the whole refernece) that would be ideal, but again, this would only be a very very marginal improvement. I'm happy to let it go :) MathewMunro (talk) 21:07, 8 January 2024 (UTC)
Two comments: this extends="Smith 2023" attribute to add to <ref> has been in beta since 2019. We can't really hold our breath for the MW development team, or whoever it is who decides to push such features out of the beta cluster to us, to actually get around to this any time soon. I'm working on some scripting to help replace {{r}} with other citation methods. The community completely deprecated inline parenthetical referencing in 2022, and rp is a form of it, albeit less intrusive a form that doing "(Smith 2023, pp. 178–180)" in mid-sentence. This is slow-going technical work, but it's something I'm committed to. (I feel a responsibility, having been the one who introduced rp in the first place. It was needed a long, long time ago before Lua modules enabled us to turn templates into sophisticated scripts, but rp is badly obsolescent now and needs to go to the retirement home along with {{harv}}.) — SMcCandlish☏¢ 😼 02:29, 18 January 2024 (UTC)
RfC: applying signature validation retroactively
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 strong consensus that signature validation should be applied retroactively. For reference, the overall implementation of signature validation is tracked at T248632 (and the technical implementation of retroactive validation is at T255324). (non-admin closure) Tol (talk | contribs) @ 01:44, 20 January 2024 (UTC)
In 2020, as part of the DiscussionTools project, signature validation was added to MediaWiki. Since its implementation, users have been unable to save an "invalid" signature in Special:Preferences. A "valid" signature must:
link to the user's userpage, talk page, or contributions
not abuse template substitution in specific ways (namely, no forging signatures and no adding line break characters)
These changes have been in place since 2020, but they only prevent someone from saving a new signature. Invalid signatures from pre-2020 are still permitted by the software. If implemented, users with invalid signature preferences would have the standard signature (MediaWiki:Signature: [[User:Example|Example]] ([[User talk:Example|talk]])) applied when signing until such time as they update their signature preference. Affected users would be warned a month in advance of this change.
Technical implementation: this would be implemented by setting $wgSignatureValidation to disallow, after sending a MassMessage to all affected users at least a month in advance.
Support as proposer. There are many reasons this is a good thing. The most obvious is that invalid signatures are A Bad Thing, and getting rid of them is thus A Good Thing. All invalid signatures violate WP:SIG in some way, so this cuts down on problematic signatures. Additionally, I would argue it is unfair that this validation is only applied to new editors. HouseBlastertalk03:47, 12 January 2024 (UTC)
Support. I do not see the harm in this, as signatures are mostly an aesthetic thing, and the reasons given are practical. Practicality should usually outweigh aesthetics. ― novov(tc)10:08, 12 January 2024 (UTC)
Support Definitely a positive change, best to phase out invalid signatures that might be causing software issues. Sohom (talk) 15:47, 12 January 2024 (UTC)
Support, this will reduce the need for linter bot edits, and a month's notice is more than sufficient for people to either correct the issues, or ask for help doing so if they need it. The proposed notice should point them to where they can ask for technical help if they're not sure what they need to fix or how to do it. SeraphimbladeTalk to me15:48, 12 January 2024 (UTC)
Support. In addition to disabling bad or broken syntax this will also reduce the need of editors and bots to fix these, this reducing watchlist spam and angering other editors. --Gonnym (talk) 16:23, 12 January 2024 (UTC)
Strong support all but obsolete tags and Plain fancy signature, which I’m neutral to as forbiddance of the former were only implemented yesterday and the latter doesn’t actually do harm. I’ll switch if somebody can demonstrate that there aren’t much people using the former and the latter won’t be reset. It’s also disappointing the subst thing isn’t checked. Aaron Liu (talk) 16:50, 12 January 2024 (UTC)
Support as a practical measure. Grandfathered users do not deserve any special exemption. I forecast white fluffiness and encourage someone to close this once it's been up for a few days. {{u|Sdkb}}talk17:00, 12 January 2024 (UTC)
from the way I see the RfC , the users will not be locked out from signing pages. The RfC is basically about resetting the signature output to default if they don't fix/update their signatures by a set time. – robertsky (talk) 10:04, 13 January 2024 (UTC)
Editors will be able to sign their posts. The RFC says "users with invalid signature preferences would have the standard signature ... applied when signing". – Jonesey95 (talk) 14:57, 13 January 2024 (UTC)
Support. I recall a couple times where editors decided to edit war to retain <font> tags in their signatures. This will at least reduce or eliminate new signatures with linter errors. I hope the advance warning includes a link to instructions on how to update signatures with deprecated tags. Philbert2.7182818:49, 13 January 2024 (UTC)
I believe the report linked immediately above lists only people who have posted to any talk spaces in the last three months. That catches most of the people whose signatures would be causing errors in current discussions, but there are no doubt thousands of inactive editors with invalid signatures. There are also thousands of editors with font tags in their signatures; those editors are not listed on the above report. It is an open question as to whether they will really be "affected" if they are inactive, but I'll leave that one to the philosophers. Importantly, no existing pages will be edited or changed as a result of this RFC. It affects only editors' saved signature preferences. – Jonesey95 (talk) 16:39, 12 January 2024 (UTC)
@HouseBlaster: I was not notified by the above. Please edit this section to delete your comment, then save. Then edit again to add the same comment but with a new signature. Johnuniq (talk) 04:50, 12 January 2024 (UTC)
Once again, please note that the "sig-too-long-post-subst" editors should not be notified, because they will not be affected by this change. Also, editors whose only error is using obsolete (font or tt or strike) tags in their signatures should have their signatures reset, but they are not listed in the report linked above. We will need to scrape some database or other in order to find them. – Jonesey95 (talk) 16:43, 12 January 2024 (UTC)
Possibly whatever that report does was confused by the amount of substing in your signature, or possibly it saw some issue with whichever time-specific signature happened to be in use at the time. Anomie⚔16:23, 14 January 2024 (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.
Community feature requests
I am proposing a new project: Community feature requests.
Basically it will be a continual system for voting on feature requests, much like the m:Community Wishlist Survey but not held once a year (well, that project isn't being held this year at all...) but always open to voting.
Each request would sit in its own subpage, just like Dark mode, with description of the problem, proposed solution and benefits followed by discussion and voting.
To display the results a table like this could be generated on Toolforge every hour - ranking the feature requests by number of support votes (for example like the "Current leaderboard" here).
Probably Meta is natural place to host this idea (one set of English feature requests for all wikis to avoid overlap), but if Meta rejects it I would be fine hosting it locally on English Wikipedia.
Note that the process of creating and voting for feature requests can start today and I think it would assist in getting voices heard by the Wikimedia Foundation development team.
For the benefit of others, note as described on the meta:Community Wishlist Survey page, the WMF is working on processes to continually receive community requests. (I realize from your comments at meta:Talk:Community Wishlist Survey/Future Of The Wishlist § How long until this is implemented? that you are aware of this direction.) I think it would be good to collaborate with that team to work out how the requests will be tracked. Of course, anyone is free to start creating pages now to draft and develop their ideas. I'm a little wary, though, of trying to co-ordinate the community into using a single framework when the WMF processes are coming. isaacl (talk) 17:26, 23 January 2024 (UTC)
Increase default thumbnail size from 220px to 250px
CONSENSUS TO INCREASE TO 250PX
This bifurcated discussion finds a strong consensus to increase the default thumbnail size on English Wikipedia to 250px. There is no consensus to further expand to 300px, though a number of editors expressed interest in revisiting the subject after a while at 250px. I am not certain of the technical steps needed to implement this change, but I will determine them and see that they are done. —Ganesha811 (talk) 21:15, 24 January 2024 (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.
Way back in 2009, English Wikipedia decided to change its default thumbnail size from 180px to 220px (which became the default for all wikis). It's been 15 years since then, and the most common screen resolution is now 1920x1080,[1][2] which makes 220px seem rather small. The Swedish, Norwegian, and Finnish Wikipedias have already switched to 250px and the Dutch Wikipedia switched to 260px(!). Since there are already other wikis using 250px, the impact on the thumbnailing services and thumbnail storage should be manageable (as the most commonly requested thumbnails will already be available in 250px). A 2014 proposal to increase the default size to 300px failed to reach consensus, which is why I'm trying the more modest proposal of 250px (which is the next size up in wgThumbLimits). Nosferattus (talk) 19:00, 5 January 2024 (UTC)
Support as proposer - After wondering why thumbnails are so tiny on Wikipedia (especially compared to other websites), I finally figured out I could change the default in my preferences, which made me wonder why the default is so small, which led me to research the history of the issue. Seems like a bump in the size is overdue. Nosferattus (talk) 19:04, 5 January 2024 (UTC)
Oppose In many case images aren't just used on their own, but side by side with other images (the multiple images template for example). This already leads to cramped text on none desktop screens, and this propodal only makes that worse. Thete is also the issue of |upright= to think of, as this would effect the size from which images are scaled. If images appear to small a setting for larger base size is available in preferences. -- LCU ActivelyDisinterested«@» °∆t° 20:33, 5 January 2024 (UTC)
The common screen size of phones have also increased. In most cases where the multiple images template is used, it's on its own line instead of sharing with text. IP editors and readers should also be accounted for, and I don't see what considerations upright adds to thumbnail sizes. Aaron Liu (talk) 21:45, 5 January 2024 (UTC)
Sorry but In most cases where the multiple images template is used, it's on its own line instead of sharing with text is the opposite of my experience. -- LCU ActivelyDisinterested«@» °∆t° 22:01, 5 January 2024 (UTC)
You're right - the one line ones are "mini-galleries", which are vastly preferable to multiple images, which are used far too often. Johnbod (talk) 04:12, 7 January 2024 (UTC)
Yep with this increase all horizontal multiple images templates will immediately become to wide. Mini-galleries are definitely a better idea. -- LCU ActivelyDisinterested«@» °∆t°12:49, 7 January 2024 (UTC)
I still don't see what considerations upright adds to thumbnail sizes. Aren't the considerations of that exactly the same as those for changing the thumbnail sizes? Aaron Liu (talk) 21:36, 9 January 2024 (UTC)
Upright is scaled from the base image size, so any images that have been set as a specific size using upright will increase in size based on this change. -- LCU ActivelyDisinterested«@» °∆t°22:57, 9 January 2024 (UTC)
Support - 220px is tiny, especially on a 4K monitor which are becoming more common. I think it would be useful to increase the size, especially since other Wikis already have. 30px isn't much in the grand scheme of things and hasn't caused any issues for me when putting images in infoboxes. --StreetcarEnjoyer (talk) 20:46, 5 January 2024 (UTC)
Support 220px looks tiny on my screen. I can set my default up to 300px but prefer to see what the readers are seeing. Or not, given the small size on their 4K monitors. Hawkeye7(discuss)23:02, 5 January 2024 (UTC)
Meh Personally, despite my screen being 1920×1280, I seldom maximize my browser. Also keep in mind how Vector 2022 shrinks the content area. Anomie⚔00:29, 6 January 2024 (UTC)
As a staunch supporter of V22, I don't think the larger Earth image looks wrong here. (Not sure if that means we should do it though, so I'm neutral.) Aaron Liu (talk) 12:51, 7 January 2024 (UTC)
Comment I don't fully understand the importance of screen size here, as I thought WP:VECTOR2022 specifically constrains article width by default. Could anyone with a super-wide monitor clarify? CMD (talk) 03:39, 7 January 2024 (UTC)
It does by default. But the people !voting here probably either use a different skin or have clicked the button to un-constrain it. Anomie⚔04:29, 7 January 2024 (UTC)
Given the resistance to the community wish of making unconstrained the default, it would be best to make decisions considering restricted width as the most likely one to be encountered by desktop readers. Having a look myself, I don't think 250px creates an issue within the constrained width (and I believe the latest zebradesign has been implemented), but worth keeping this default look in mind. CMD (talk) 14:31, 7 January 2024 (UTC)
Strong Support Hardly any images except photos of faces can be properly read at 220px. As per Relativity, except even in 2009 our images looked too small. Johnbod (talk) 04:10, 7 January 2024 (UTC)
Support. I'd prefer jumping straight to 300px (and I think mw:Ops would, too), but 250px is fine and an improvement over what we have now. Somewhat bigger images are easier for people to see (e.g., if you're old enough to use reading glasses, which I'm sure I set down somewhere just a minute ago), but they also make the pages seem more interesting. I set mine to 300px last year, and I've never regretted it, and you can, too: go to Special:Preferences#mw-prefsection-rendering-files and change the thumbnail size. As noted above, several other communities have made this change already, and I'll add that AFAIK no community has ever switched to a bigger number, regretted it, and then asked to be switched back to a smaller size. BTW, because the English Wikipedia is the largest wiki in the history of the world, etc., the actual switch is something that requires a bit of planning. This is not difficult – in fact, on our end, it's really quite easy – but we should not be surprised, e.g., if we get an official request to manually set the images in the very most popular articles (probably on the order of the top 0.01% by page views) to the new size in advance of the official switchover. We can send a bot around to do this (and also to undo it after the switch is made), and that will take some of the strain off the servers on the magical day (plus give both editors and readers a way to see the change in action before it happens everywhere). Let's do this. WhatamIdoing (talk) 04:55, 7 January 2024 (UTC)
Oppose We still also must consider mobile screens, and going above 220 px will put a strain on those readers. If you are on desktop, you can set the default size through a registered account to handle this. Masem (t) 18:32, 7 January 2024 (UTC)
Why would it? As mentioned above, since images are put on their own line in mobile, having bigger images is nice and causes no issues. I just increased my thumbnail size to 300px and it looks great - a lot of images are a lot easier to see that way (Special:Preferences#mw-prefsection-rendering-files also affects mobile, so you can test it for yourself). 250px is not going to cause any issues for mobile. Galobtter (talk) 18:53, 7 January 2024 (UTC)
I disagree, I find larger thumbs on mobile to be too large for a reasonable reading experience. Masem (t) 20:13, 7 January 2024 (UTC)
I'll also add that there is an issue with anything larger than 220px for a large chuck of non-free images, which we have constrained to 0.1MP. Many portrait non-free images like movie posters end up with image sizes around 400 x 225 px to stay within the 0.1MP. Thumbnail sizes over 220 px will implicitly and incorrectly imply that non-free images can be uploaded to larger sizes, which will not happen. Masem (t) 20:19, 7 January 2024 (UTC)
Is there any actual legal basis for 10% of a megapixel? My impression is that this was more or less a random number pulled out of somebody's. jp×g🗯️15:42, 8 January 2024 (UTC)
No, it’s just something we picked. The legal precedent is only that the usage has to be ‘minimal’. If u have a retina screen in many cases u already get noticeably pixelated thumbnails for non free images. Upping the thumbnail size would increase that problem. —TheDJ (talk • contribs) 21:35, 9 January 2024 (UTC)
Also, 250x400 px = 0.1MP exactly, so we could have the same height on a vertical image. US theater posters have a ratio of 27:40, so we'd be expecting to see uploads at 250x370px. WhatamIdoing (talk) 02:16, 10 January 2024 (UTC)
Support, especially for mobile. I've got a tiny screen for a mobile, and default thumbnail has a lot of ugly white around it. On desktop it's a no-brainer; I usually set upright=1.35 to ensure images/graphs are easy to see. By choosing a better default, fewer people will need to rescale. Many people rescale using the px parameter, which causes accessibility issues, so another plus if that is avoided. My guess is that a default of 300px or 260px would be even better. —Femke 🐦 (talk) 18:58, 7 January 2024 (UTC)
Support Jeez, I remember it was pulling teeth to get the thumb size bumped up years ago, and now it's been more than a decade? I think we are hitting the useful limits of thumbnail size at 250px, given that a) lots more reader use is mobile, which is width-restrained, and b) the WMF's Vector redesign harms screen horizontal real estate for the vast majority of readers and it's likely even if they're browsing full-screen at 1920x1080, they don't necessarily have correspondingly more content area, but I think the small bump proposed here is sensible. Der Wohltemperierte Fuchstalk19:24, 7 January 2024 (UTC)
The mobile width of an average mobile screen is 360 to 440 ‘non-retina’ pixels. With margins removed that’s about 300 to 360 web pixels. Above that width, the skin will scale down the image. —TheDJ (talk • contribs) 21:39, 9 January 2024 (UTC)
Support. This is less of an issue with Vector 2022, which makes the horizontal area much smaller, but I still recommend it be done. I myself have manually set the thumbnail size to 400px so I can see more in Vector 2017, which is the skin I use. SWinxy (talk) 19:45, 7 January 2024 (UTC)
Support I set my personal default to 400px some time ago and that's fine so even 250px is small. And I'm not using anything special – mostly a 1920 x 1080 laptop or a smartphone. Andrew🐉(talk) 21:09, 7 January 2024 (UTC)
Support: aesthetically, I like the current size better, but that's no reason to oppose, just my opinion. I am convinced by supporter's arguments above. 🌺 Cremastra (talk) 22:41, 7 January 2024 (UTC)
Support. I do not see downsides to this proposal. Screens are significantly larger than they were a decade ago, so they should be able to handle slightly larger thumbnails just fine. For non-free media, that means the media will likely be smaller than the proposed new default, but that is only a minor issue. Conversely, I think 250px default thumbnails would be a significant benefit for both desktop and mobile users, especially seeing how many articles already use images that are 250px or larger in their infoboxes. – Epicgenius (talk) 23:28, 7 January 2024 (UTC)
In that case, I don't think there are any other issues with upscaling the default thumbnail size to 250px. Although I definitely see why there is a size limit for non-free media, I agree the 0.1 megapixel limit seems arbitrary (for example, why can't it be 0.11 or 0.12 megapixels, which would allow non-free media to be slightly wider?). – Epicgenius (talk) 19:56, 8 January 2024 (UTC)
Support, a really good idea. Now hopefully somebody will get around to increasing the default text size, probably small enough that it was designed for 18-year-olds with the eyesight of eagles. Randy Kryn (talk) 00:32, 8 January 2024 (UTC)
Support Reading and commenting from mobile to say that this looks better on the mobile version of the wiki and doesn't raise any issues there. CoconutOctopustalk12:20, 8 January 2024 (UTC)
Support going straight to 300px; I am almost kind of reticent to support going to 250px because we might end up stuck there for another fifteen years. 300px is, I'd say, close to an absolute minimum for things being legible. 220px is so mindbogglingly tiny I can't even explain it without using language from the old country:
For reference, here is a screenshot of this page on a 4K monitor at 100% zoom level lol.Please sir may I have some more pixelsjp×g🗯️15:38, 8 January 2024 (UTC)
The default skin was not handed to us on tablets from heaven; it was made by designers in accordance with the constraints of the project, one of which was that thumbnails were 220 pixels wide. This seems like a rather circular problem: we can't increase the thumb resolution because the skin wasn't designed around them, and the skin won't be designed around larger thumbnails because we don't use them? jp×g🗯️20:45, 8 January 2024 (UTC)
Hmm, I've searched a bunch of places and I can't seem to find a place that says V22 was designed on the basis of 220px thumbs. Aaron Liu (talk) 20:59, 8 January 2024 (UTC)
Expecting the WMF to react to changing thumbnail sizes on a single project (even the main one) seems unlikely, and the default fixed-width page layout is how the vast majority of users will experience the site. (As an aside, one reason for the page width limits is that the longer lines go, the harder it is to read, hence one reason why you never ended up with extremely horizontal books. I dunno who is browsing Wikipedia at full-width and full 4K resolution, but that's objectively a worse way to experience it, and we shouldn't be considering those edge cases when making decisions for the majority.) Der Wohltemperierte Fuchstalk16:14, 9 January 2024 (UTC)
Weak support. It's a marginal change, but apparently important enough to end up at CD. Oh well – I kinda like bigger images anyway. I can't support this beyond personal opinion on aesthetics, but I'd be willing to put a Weak Support on it. InvadingInvader (userpage, talk) 15:57, 8 January 2024 (UTC)
Strong support - Increasing to at least 250px (if not 300px) makes sense in relation to more advanced mobile phones and desktop screens. As a visual thinker and learner (as opposed to a "word person") this change would also increase literacy for those of use who are visually dominant. Therefore I see it as an accessibility issue as well. Netherzone (talk) 18:36, 8 January 2024 (UTC)
Support Just like with money inflation, keeping as the relative same as 15 years ago would be about 500px and 250 is a tiny step in comparison. North8000 (talk) 19:04, 8 January 2024 (UTC)
Support as web design best practice. I broached this idea back in 2020, and given the response here it seems I shouldn't have let myself be talked out of it. I've had my personal preference set to 250px ever since then — it's nice, and I'd like to give readers that same experience. I find the opposes generally unconvincing (Masem's fair use concerns seem at least a bit valid, but as TheDJ notes, a bit of pixelation is already happening on high-resolution devices, which are becoming more common over time, so it's water under the bridge; and I don't have any problem with people uploading larger fair use images that then get automatically reduced, nor with us exploring raising the 0.1MP standard). {{u|Sdkb}}talk00:24, 10 January 2024 (UTC)
Support: I've previously thought 220px was too small on desktop, and an increase to 250px seems reasonable even considered the limited width of Vector 2022 (which improves readability and skimming). — Bilorv (talk) 23:48, 13 January 2024 (UTC)
Support The current default is just too small, and it's my observation that many new/unregistered users end up setting images to a larger resolution so they'll be legible. As it stands, WP:THUMBSIZE doesn't describe actual editing practices, and hopefully a better default size will improve that. hinnk (talk) 19:19, 19 January 2024 (UTC)
Support Seems reasonable, although some care is neccesary for smaller screens.
Even though there is overwhelming consensus to increase resolution, 250px is a very small jump and in my opinion it should be increased to 300px. In the 2000s, the most common screen resolutions are 800x600 and 1024x768. Now, the most common resolution are 1080p, which is 1920x1080. 1920/1024 = 1.875, so in theory we should scale the image to 400px, but that's too large because New Vector has a fixed width for content. So, I made a test to determine whether 300px is truly the optimal image size. In one page, I opened Earth in default New Vector and preview it in 300px. In another page, I opened the same article in the Internet Archive as it looks like in 2008 and use a browser tool to set a 1024x768 resolution and then scale the page until both article's text looks at around the same width. Indeed, in both pages, the image looks almost exactly in the same proportion. I'm uploading screenshots of my test to Wikimedia Commons for others to see. CactiStaccingCrane (talk) 10:53, 9 January 2024 (UTC)
Also, I would like to add that increasing picture resolution helps with printed and offline version of Wikipedia where there is no option to browse the full-res picture. That's why I consider 250px to be too small of a change. CactiStaccingCrane (talk) 02:52, 10 January 2024 (UTC)
Oppose. The scaled version is definitely closer to 250px. The picture of Earth is a square image, while a lot more images are landscape. In my experience, for such images, 300px covers up way too much text. Aaron Liu (talk) 12:41, 9 January 2024 (UTC)
It's not too helpful an image as the Earth image appears to be in an infobox that maintains its width, however as the pixel scaling is horizontal a landscape image would cover up less text than a square image. CMD (talk) 14:10, 9 January 2024 (UTC)
300px covers up way too much text – Um, it doesn't cover up any text. Bigger images do take up more vertical space, but if it's actually overlapping with the text, then you should probably be at the Wikipedia:Help desk or Wikipedia:Village pump (technical) with a screenshot showing how the image prevents you from seeing all the words on the page. WhatamIdoing (talk) 02:23, 10 January 2024 (UTC)
Bigger images will cause words to run away from the image, which is what I meant by "cover up", not literally overlap. Aaron Liu (talk) 03:16, 10 January 2024 (UTC)
Because current popular screen sizes aren't fitted for such large image sizes. One day your local wages will inflate, but that doesn't mean we should inflate them now. Aaron Liu (talk) 03:16, 10 January 2024 (UTC)
Support, that's what I use and it is great both on my laptop and on my smartphone. (I rarely use ultra-wide screens). —Kusma (talk) 13:32, 10 January 2024 (UTC)
Oppose per my rationale above. Were default Vector not restricting width I would possibly feel differently, but it is what it is, and given image/template sandwiching issues a more conservative default is a bit less ungainly in edge cases. Der Wohltemperierte Fuchstalk13:59, 10 January 2024 (UTC)
Support but note significant work --> a change from 220px to 250px will mean that some images with be a bit on the large size (with upright=1.35 for instance), but not too ugly. When we change it to 300px, a lot of images with upright=1.35 or upright=1.5 will have become too big. We may want to find consensus to change the upright parameter automatically under certain conditions (f.i. upright>1.35.. ). —Femke 🐦 (talk) 17:55, 12 January 2024 (UTC)
This was part of my reasoning for opposing both changes, if the default is increased any images set with upright will become the wrong size. Some kind of automated correction would certainly help. -- LCU ActivelyDisinterested«@» °∆t°21:00, 12 January 2024 (UTC)
Oppose. 300px simply looks too big on my laptop screen (effective resolution 1280×800, using Vector Legacy). Even worse on my smartphone (also using Vector Legacy which I understand is an edge case), where the image takes up about 40% of the page width. —pythoncoder (talk | contribs) 21:18, 12 January 2024 (UTC)
Support I set my personal default to 400px some time ago and that's fine so even 300px is small. And I'm not using anything special – mostly a 1920 x 1080 laptop or a smartphone. Andrew🐉(talk) 09:05, 16 January 2024 (UTC)
Oppose seems to be too big on smaller devices like phones and has some issues with Vector 2022 right now I might support in the future if Vector 2022 is fixed Isla🏳️⚧ 00:32, 17 January 2024 (UTC)
Oppose. That seems a bit much, and if we're going to do this kind of stuff it should be incrementally and give the reading community time to adjust and provide feedback. — SMcCandlish☏¢ 😼 02:20, 18 January 2024 (UTC)
Comment Is it possible to have a "variable" width that changes depending on the size of your display? So basically like a percentage, but that doesn't seem to be currently supported in thumbnails. InfiniteNexus (talk) 23:48, 20 January 2024 (UTC)
Can't we use something that depends on the actual current width of the page? Vector 2022 allows that to change with the click of a button; why shouldn't the images become larger if the screen is larger? Maximum and minimum values, and even the height of the screen, can be calculated freely and automatically. For example, we could define that an image's maximum width is the minimum of: 20% line width, 100% view height, 400px. ~ ToBeFree (talk) 19:04, 12 January 2024 (UTC)
Dynamic scaling of content, not just images, should be the way forward. This would ultimately allow for a single page style regardless of screen size or aspect. -- LCU ActivelyDisinterested«@» °∆t°20:55, 12 January 2024 (UTC)
As I understand it, somewhere in the server infrastructure, the thumbnail images have been generated and cached for fast delivery (thus WhatamIdoing's suggestion that the size be manually changed for high-traffic articles in advance of switching the default, to take the load off the servers from generating images on-demand until the cache has been re-generated). Thus having the thumbnails with different pixel sizes based on each user's window size would have a significant impact on performance. It is theoretically possible to specify a maximum limit for the space in which the thumbnail is rendered, though, so it won't take up more than a certain amount of the available content space regardless of the pixel size of the image. I've never looked closely at how it works under the hood, though, so am not sure how much rework might be needed. Cases where editors have used an {{{upright}}} scaling factor > 1 to deliberately exceed the usual horizontal space allocated would have to be accommodated, which might be tricky. isaacl (talk) 21:47, 12 January 2024 (UTC)
Ah, thumbnail caching is a point I hadn't thought about. But if we use the "minimum of: 20% line width, 100% view height, 400px" example, we can serve 400px thumbnails and they'll never have to be upscaled. Or, taking "upright" into account, the limits could be "20%*upright width, 100% width, 100% height and 400px*upright", with 400px*upright thumbnails, I guess. ~ ToBeFree (talk) 13:06, 13 January 2024 (UTC)
Yes, as I said, it would be possible to limit the space in which the image is rendered while serving it at a specific size, though I am uncertain about the amount of changes required for implementation (it could require work both in the MediaWiki code as well as the wikitext source). As any applied scaling factor isn't a fixed value (or one of a fixed set of values), however, accommodating it with a CSS rule would require custom CSS to be generated for each instance and targeted for the specific image. Given how the cascade works, I'm not sure if the template can cleanly manage this on its own (though I suppose as a kludge it could manually replicate a common rule while adding additional constraints). (Javascript code could apply an appropriate rule, but this would result in layout shifts, as well as requiring the user agent to support Javascript.) isaacl (talk) 17:51, 13 January 2024 (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.
Anomalous temporary situations where good can be done.
Color Bars are used on nonpartisan election articles which are located on the bottom of the where the political party would be located if the election was not nonpartisan
Some Wikipedia editors have removed the Color bars and replaced the colors with political party as a good faith edit on the election articles, and concerns and objections have been put forward. Removed the Color bars and replaced the colors with political party as a good faith edit Assuming that the candidate is in a politicil party with out displaying the name which can cause issues add disruptions to nonpartisan election articles. I propose Color Bars should not be used at all on Infobox election of nonpartisan election main page articles in The United States DLCY89* (talk) 02:28, 16 January 2024 (UTC)
@DLCY89*: I'm skeptical more than a handful of editors reading that are going to know what you are talking about. We need a historical link to an article that showed the "color bars" and an after version that has the "poltical parties" replacing them so we can compare them. — SMcCandlish☏¢ 😼 01:34, 18 January 2024 (UTC)
The middle one of these appears to have done the following:
added political party names and color bars representing the parties under the names of the candidates in the infobox.
The third of these:
removed the party names and kept the color bars, but changed one of the Democrats to green for unknown reasons (I can't find anything in that article or the one on the candidate suggesting a connection to the Green Party)
The party names are important encyclopedic information in this context. The color bars are just decoration and serve no actual purpose. They certainly cannot be relied upon to convey information, since what colors correspond to which US political parties is going to be something familiar mostly to Americans (and only some of them), it is very easy to simply not notice at all (I had to look several times before I noticed it, and that was in the context of actively trying to distinguish visual differences between the three versions), and most importantly we have plenty of readers who are color-blind (i.e., the third version fails MOS:COLOR) – even aside from the strange switch to green for one candidate. I would thus advise putting back the party names and removing the color bars, or putting both back and undoing the confusing and unsourced change to green, but expect that other editors are likely to remove the color bars entirely as unneeded decoration (they are basically just unusually wide icons, against MOS:ICONS). — SMcCandlish☏¢ 😼 18:07, 18 January 2024 (UTC)
At the very least, we have to have the party names, because the colour bars can be confusing, at least for US politics. (The US parties have inverted colours from many other countries — their progressive party is blue while their conservative party is red.) I kind of like them, personally, but I can't deny that they are largely decoration. 🌺 Cremastra (talk) 12:49, 21 January 2024 (UTC)
Yes, we should certainly have the party names, whether or not we have the colours as well (about which I have no opinion). Am I the only editor who saw the title of this section and assumed it was about colour bars?— Preceding unsigned comment added by Phil Bridger (talk • contribs) <diff>13:09, 21 January 2024 (UTC)
I am of the opinion that party identification should not be included in the infobox of a non-partisan election. On one level, especially in jurisdictions without party registration, there is a certain amount of speculation and inference in incorporating a party label. Also, candidates may run by downplaying or rejecting a party label, although they may previously identify with a party. Finally, the infobox does not specify that the election was nonpartisan and provides the wrong impression to readers. I do believe the information about party identification is encyclopedic, but should be mentioned in the prose. --Enos733 (talk) 22:22, 24 January 2024 (UTC)
I'm not sure that we have a shared agreement about what it means to have a "non-partisan election". The candidates in the election linked above are still members of a political party, supporting their political party, and being supported by their political party during the election campaign. "The voters don't have to vote for members of their own party" is not a non-partisan election in quite the same way as "There are no political parties involved in this election campaign". WhatamIdoing (talk) 18:02, 25 January 2024 (UTC)
What Ballotpediasays about nonpartisan elections is correct, "Nonpartisan elections are elections in which all of the candidates for an office are listed on the ballot without party labels identifying any political parties with which the candidates are affiliated or by which the candidates are nominated." The term is distinct from partisan elections where the candidate does have a party label on the ballot.
Now, it is true that many candidates do make their party identification known in a nonpartisan election, but the party identification does not mean that the candidate is supported by that political party. Similarly an endorsement by a party does not mean the candidate affiliates with that party.
But the point of a nonpartisan election, fundamentally, is that the voter does not see the party label on the ballot. The infobox should reflect the nonpartisan nature of the election, affiliation of the candidates should be in the prose. - Enos733 (talk) 20:19, 25 January 2024 (UTC)
I agree infobox should reflect the nonpartisan nature of the election. I believe the best solution is to remove Color Bars and party lables. Is there also a way to put a party affiliation labels info boxes instead of color bars or political party of labels? DLCY89* (talk) 22:59, 25 January 2024 (UTC)
I'm not sure that if you're nominated by a political party, and your campaign is promoted by and paid for by a political party, that Wikipedia should join in the sort of wink-wink-nudge-nudge style of pretending that there aren't any political parties involved. Infoboxes aren't meant to duplicate the ballot itself. They're meant to provide information.
Here in California, we have "actually nonpartisan" elections for local schools and courts. The election for the Mayor of Los Angeles is not one of those. Or think about our current governor: Bill Clinton, Al Gore, and Jesse Jackson campaigned for him when he was elected mayor in San Francisco. Ignoring the role of the Democratic Party in that election would provide a materially false understanding of what happened. WhatamIdoing (talk) 20:04, 27 January 2024 (UTC)
But is that role properly covered by imputing a single party for each candidate into the infobox? Or is it better done by text in the body of the article that can go into more detail? Anomie⚔14:22, 28 January 2024 (UTC)
This can be achieved by disabling the relevant User:Hazard-Bot task.
As discussed at WT:About the sandbox#Sandbox header is too big, it's very inconvenient, and is of dubious educational value considering how often people remove the header against its warning. There's already an editnotice at the sandbox, so whichever minority of editors who do read the rules will still be informed that it isn't a free-for-all. Mach61 (talk) 23:01, 21 January 2024 (UTC)
The point of the sandbox template is to invite people to 'click edit' because it's a 'space to experiment'. An edit notice doesn't serve this function; a blank page is not at all inviting. Pretty much everyone who has ever edited the page will have read the notice which says that it can be edited. -- zzuuzz(talk)23:26, 21 January 2024 (UTC)
That might indeed be useful, though I don't think it resolves the question here. I hesitate to ask whether there's a timescale for that? -- zzuuzz(talk)22:04, 24 January 2024 (UTC)
So let's have a link, to Template:Sandbox heading, and ask what it should look like. Personally I'm not really seeing a great deal to do. We have a line saying what it is, one saying what to do with it, another explaining why it keeps changing. A couple of explanatory links, and a notice about what not to do with it. Let's hear what needs culling. -- zzuuzz(talk)22:04, 24 January 2024 (UTC)
perhaps this?
To modify this page, click here. Content added will be deleted within hours. For more information, see Help:Editing
What would probably be a more helpful guide to getting people to experience editing on Wikipedia would be to take a revision of, say, sandpit and have that revision be the sandbox used to experiment with editing. It will give users practice with templates, images, linking, citations, basically all the components of a Wikipedia article. AwesomeAasim06:33, 7 February 2024 (UTC)
Wikiprojects are not set up with any sort of systematic content consideration, but as a matter of facilitating editor attention. The Abkhazia and Artsakh projects are both quite inactive as well, and Wikipedia:WikiProject Limited recognition isn't doing better either. Such moribund projects would likely be more often wound up if the process was simpler. CMD (talk) 08:06, 26 January 2024 (UTC)
This has nothing to do with notions like "unfair that many unrecognized countries have WikiProject while N. Cyprus doesn't". Wikiprojects are not "recognition", or "categorization", or "stand-alone article", or anything of the sort. There absolutely is not a one-to-one relationship between "asserts it is a country" and "has a wikiproject devoted to it". Wikiprojects are only one thing (when they are operating properly; when they are not, they sometimes are another thing: canvassing farms.). That legitimate thing is that they are simply internal pages at which sufficient editors to keep them alive choose to centralize their collaboration. There are insufficient editors to keep even WikiProject Cyprus active, so no, there is no reason at all to spin up a WikiProject Northern Cyprus. And the place to propose such a thing in the first place would be WP:WikiProject Council/Proposals (where the answer would be that at most there might maybe should be a N. Cyprus taskforce/workgroup at WikiProject Cyprus, but even that is dubious with so few editors devoted to the region as a topical focus). — SMcCandlish☏¢ 😼 00:04, 9 February 2024 (UTC)
"Articles should mention any person, place, thing, or term that redirects to them. This category contains otherwise valid redirects which are not mentioned in their target articles."
I propose that we make this description more accurately match WP:RFC#DELETE #8, which says:
"If the redirect is a novel or very obscure synonym for an article name that is not mentioned in the target..."
I have highlighted these words because WP:Nobody reads the directions, and because the "if...then" nature of this item has not always been noticed. Some less-experienced editors have been left with the impression that every redirect, except for some simple variations in spelling, etc., really should be mentioned – or the redirect should be deleted. The actual rule is that we want to delete only those redirects that are both (a) "novel or very obscure" and (b) not mentioned/worth mentioning in the article.
This is well over 100 redirects that are "not mentioned in the target article". However, none of them are "novel or very obscure", so RFD#DELETE #8 does not apply. They are, for the most part, popular brand names or formulations in various countries. (Dispersible aspirin, for example, is the style popular in France, and unheard of in the US [you dissolve it in water, like Alka-Seltzer tablets].)
Articlesshould mention any person, place, thing, or term that redirects to them. This category contains otherwise valid redirects which are not mentioned in their target articles.
+
It is often helpful for an article to mention any person, place, thing, or term that redirects to it, though this is neither required nor appropriate in all cases. This category contains otherwise valid redirects which are not currently mentioned in their target articles, and which an editor believes should be evaluated for possible addition to the article.
I think you've raised an important point, and I've also encountered editors eager to add something to an article simply because there's a redirect about that thing. I support the change except for the "which an editor believes should be evaluated for possible addition to the article" part, which is not always true. I'd also favor removing the next paragraph of the status quo,
Editors who monitor this category will ensure that redirects that are sorted here will either be added to their target articles, retargeted and retagged, or deleted.
Something like this would be a good idea, as long as it doesn't interfere with deleting redirects that actually should be deleted, e.g. because they were deleted coatracks or because they are trivia or other non-encyclopedic stuff we should never cover. But we don't need, for example, every attested historical spelling of a term to be mentioned in an article, as long as it's clear to the reader why they were redirected there (e.g. because a recognizable version of it is bolded in the lead already). — SMcCandlish☏¢ 😼 23:46, 8 February 2024 (UTC)
FFF, I cheerfully defer to your judgment on this. I'm not really certain how the regulars at that cat (if any) use it. I'd like a description that gives newer folks an accurate understanding of the guideline (the first sentence) and what happens (the second sentence).
SMcC, I agree with you. I also think some editors have difficulty with imagining what's clear to the reader – not in a theory of mind kind of way, but these editors are thinking that since they've no clue why Entericin redirects to Aspirin, then probably nobody who deliberately searches for that term will have any idea, either. But the reader, unlike the editor, reaches the article with pre-existing context. The reader may be looking at an old publication like doi:10.1016/S0140-6736(01)11747-2 ("Entericin in the Treatment of Enteric Fever", The Lancet, 1909), and just want to figure out what it is. Arriving at Aspirin automatically provides all the context they need. This won't be true for everything (e.g., if a person's name redirects to a town), but it is IMO true for many brand names and dated synonyms. WhatamIdoing (talk) 00:23, 9 February 2024 (UTC)
Explanation of nationality on sports pages
If you look at wikipedia pages relating to club teams or club games it will often have lists of players and beside each one a little flag denoting 'nationality'. As per wikipedia protocol these flags represent sporting nationality rather than actual nationality however nowhere is this ever explained to the reader on the page. My suggestion is that where possible, for instance on a chart with a 'nationality' column, there should be a pop up note. Obviously for international sport this is not needed as it is obvious that used flags denote the country a player represents rather than actual nationality. Firestar47 (talk) 14:30, 12 February 2024 (UTC)
General Sanctions (Darts)
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.
Although this hasn't been kicking for quite 30 days yet, it looks ripe for closure with no input in a few days and a pretty solid ratio. There is no consensus to authorize General Sanctions for the topic of Darts. By the numbers we're looking at an almost even split, and there are no strong policy based arguments that support or refute the authorization of GS, so it comes down to if editors believe that the disruption is severe and widespread enough to warrant GS. Arguments from those supporting the authorization simply weren't enough to convince even a slim majority that GS was necessary, rather than the enforcement mechanisms we already have in place. ScottishFinnishRadish (talk) 19:26, 13 February 2024 (UTC)
After reviewing this thread, the linked diffs and talkpages, and the requested closure above, I'm supremely unimpressed with the conduct of a number of people in this topic area. It certainly isn't just one person, incivility is rampant throughout the area. In order to break the back of this problem, I'd propose General Sanctions be authorized for the Darts topic area, text below copied from WP:GS/PW. The WordsmithTalk to me02:04, 17 January 2024 (UTC)
Any uninvolved administrator may, at his or her own discretion, impose sanctions on any editor working in the area of conflict if, despite being warned, that editor repeatedly or seriously fails to adhere to the purpose of Wikipedia, any expected standards of behavior, or any normal editorial process.
The sanctions imposed may include blocks of up to one year in length, bans from editing any page or set of pages within the area of conflict, bans on any editing related to the topic or its closely related topics, restrictions on reverts or other specified behaviors; or any other measures which the imposing administrator believes are reasonably necessary to ensure the smooth functioning of the project.
Prior to any sanctions being imposed, the editor shall be given a warning with a link to this decision and, where appropriate, should be counseled on specific steps that he or she can take to improve his or her editing in accordance with relevant policies and guidelines.
Sanctions imposed may be appealed to the imposing administrator or at the appropriate administrators' noticeboard.
I considered it, but chose not to on purpose. WP:CTOP is specifically tied to Arbcom and subject to their oversight; we still have template issues leftover from when Contentious Topics replaced WP:ACDS. By using the older Discretionary Sanctions language, it makes things much more clear that it was placed by the community and not Arbcom, that it doesn't happen at WP:AE or get appealed to WP:ARCA, etc. Separating community-based sanctions from arbcom-based sanctions reduces confusion in the long run. The WordsmithTalk to me06:10, 17 January 2024 (UTC)
Over the long run, personally I think it would be simpler to have one procedure for authorizing additional actions by administrators, with either the community or the arbitration committee designating topic areas where the procedure can apply. I appreciate, though, that this would be breaking new ground for the community and so at present has more uncertainty. isaacl (talk) 06:21, 17 January 2024 (UTC)
Before Wikipedia even existed, I received the wisdom that politics, religion, and sports were subjects that caused heated arguments. So I am not surprised at all. That said, from what I've been able to follow of the dispute here, it's not the topic, but the fact that articles have been written in one form for a long time, and the argument is over whether that form adheres to our policies and guidelines. It's the common "But no-one has objected since 2006!" argument, combined with arguments over Manual of Style compliance, original research, and sports statistics, all of which have provoked heated arguments in other areas in the past. It's not really darts itself that is being argued about. Uncle G (talk) 12:01, 18 January 2024 (UTC)
Nothing that cannot be resolved with some AGF colleborative discussions. But that will need the necessary goodwill on both sides. An outsider barging in with "my opinion can't be swayed" as their motto doesn't work at all, as the last two years have shown. And assuming bad faith of the darts regulars isn't helpful either. This proposal is an overreaction. It will only discourage discussion. Tvx1 17:32, 18 January 2024 (UTC)
Ah, yes, the perennial WP:CONTENTAGE "argument to avoid", which supposes incorrectly that old content is mystically exempt from later changes to policies and guidelines and process (often even compliance with the P&G rules that existed all the way back then but weren't followed in that topic at the time, without much of anyone noticing). The more obscure a topic is, especially if it has a fans/practitioners editor base that leans in a walled-garden direction (often via a topical wikiproject), the less it tends to attract cleanup efforts, especially compared to things of broad editorial interest like major sciences or globally famous persons. It's a severe misunderstanding of WP:EDITCON, a supposition that because a loose consensus can be established simply through acceptance of content being as it is for a long time that this equates to the formation of an ironclad topic-specific consensus that somehow overrides any highly-specific site-wide consensuses established through affirmative processes, like policies and guidelines, that have a much higher WP:CONLEVEL. This fallacy is a long-term source of squabbling, across many topics. I only ends one way (with the P&G eventually being followed as in every other topic), but has a very corrosive effect on editorial goodwill. Sports and games in particular are commonly a nexus of this recurrent problem. CONLEVEL policy was created to curtail it, but perhaps is not clear enough, or simply too infrequently acted upon. — SMcCandlish☏¢ 😼 18:32, 18 January 2024 (UTC)
I'd forgotten about that, and it's worth developing further. Though that rather long discussion was most immediately about WP:YEARS and "their" articles, WP:ITN, and a few other specifics, what SnowRise said there (in part paraphrasing Levivich) resonantes strongly and is broadly applicable. — SMcCandlish☏¢ 😼 06:50, 19 January 2024 (UTC)
Oppose This is a massive overreaction. The entire situation really revolves one user, who even during the AN report stated their intention that they would not colleborate and stated that "their opinion can’t be swayed", against whom the community seems to be unwilling to take action. This proposal amounts to using a large blow torch to get rid of a fly. All it really needs is users on both sides to be colleborative and to accept nothing is black and white here.— Preceding unsigned comment added by Tvx1 (talk • contribs)
The issue goes far beyond the one person you're pursuing an indef on, as well as the other two long term users who have been indeffed over Darts content. Invicility, WP:BATTLEGROUND conduct, and WP:OWNership seem to run rampant in this topic area. For avoidance of doubt, here are a few examples of your own recent conduct: [3][4][5][6][7]Wrong link, should have been [8]The WordsmithTalk to me17:28, 17 January 2024 (UTC)
What point are you even trying to make with these diffs? More than half of them is me just reporting factual events like two users having been blocked. Care to explain what policy I violated posting that? Or is it just a blockable offense to just post something in a darts-related discussion that doesn't agree with the non-regular darts article editors?? As for the first two, maybe you should also read and cite what I was replying to? Heck, I'm not even a member of that darts project, I'm just an occasional editor to those articles, mostly those on the world championships. I was just baffled by behavior shown on the talk page by BOTH sides during the last world championship and it's still inexplicable that only one of the users who resorted to personal attacks was sanctioned. Even more so because the unsanctioned users had displayed the same behavior before in an other topic area and got topic banned there as a result, and because the user did not show any insight on their behavior and no willigness to change during the AN proceedings. I honestly don't understand why you and others keep putting all the blame on one side. In fact all the drama that occured over the past two years in that topic area is somehow connected to that user. A core issue is their ""my opinion cannot be swayed" they displayed throughout and which they reiterated at WP:AN. That's why I maintain that this proposal amounts to suggesties to using a nuclear missile to kill ant. Start with dealing with that one user, as multiple people suggested during the AN, and then see how things evolve at the topic over next weeks and months before resorting to such drastic measures as general sanctions.Tvx1 17:25, 18 January 2024 (UTC)
I honestly don't understand why you and others keep putting all the blame on one side. The whole point I am making is that all the blame is not on one side. This entire time you've been crusading for an indef on ItsKesha, and you're right that she's been grossly uncivil. Much of her behavior has also been in response to even worse personal attacks and even slurs hurled by the now-blocked editor and others. That doesn't excuse it at all, but rather it points to a wider problem. As far as which policies you've violated, right off the bat You need to learn to read is clear WP:NPA and WP:CIVIL violations, especially given that it was a response to a ten month old comment. The rest demonstrates WP:BATTLEGROUND conduct, WP:OWNership, and assumptions of bad faith, though my fifth diff has the wrong revision so I'll correct that now. The point is that there's enough conduct here to block half the editors on Darts pages, but instead I'm trying for a gentler approach of "final warning for everyone, cut it out or else". The WordsmithTalk to me20:28, 18 January 2024 (UTC)
Battleground, Ownership and assuming bad faith are things that I hope are not referring to me, because these are not characteristics of mine. I was one of the few who actually did the effort of carefully reading the policy and guideline arguments and the relevant policies and guidelines and properly adressing the arguments. I certainly do not consider myself the owner of any article ever. And as I said, I'm not a darts project member at all. Just an infrequent editor of some related articles. Tvx1 23:51, 30 January 2024 (UTC)
Support but with a time limit like a year or 18 months or something. We have too many topics that stay perpetually under conditions like these (community or ArbCom ones), when the problems are usually traceable to fewer editors than it takes one hand to count, most of whom learn their lesson, do something else around here, or go away entirely. — SMcCandlish☏¢ 😼 22:33, 17 January 2024 (UTC) PS: I don't mind waiting for a while as Tvx1 suggested. This might actually just fizzle out on its own. — SMcCandlish☏¢ 😼 18:33, 18 January 2024 (UTC)
@SMcCandlish: A time limit does seem like a good idea, though I'd suggest 24 months to capture the full 2024 and 2025 darts "seasons". Even the frequent use of words like "outsiders" make it clear that we're dealing with a group of entrenched editors centered on one topic area, and GS/DS/CTOP is the only tool we have that has a proven track record of success for this type of issue. The WordsmithTalk to me20:39, 18 January 2024 (UTC)
Sure, works for me, if it comes to actually needing the GS. Hopefully Tvx1 is correct that it won't be, though I'm not sure how that is determined? Do we have yet wait for yet another ANI to come up? — SMcCandlish☏¢ 😼 06:50, 19 January 2024 (UTC)
Oppose. We're talkin' 'bout darts...darts. GS is one of the worst pieces of Wikipedia red tape. I've been here for years and I still don't understand how it really works. This is some sort of heavy-handed response to a few people that can't play nice together. Just block them and move on. Don't put some big hanging sword over the entire topic. For the record, I've never edited a darts page, and couldn't really care less about the topic. I just happened to see this pretty randomly and was dumbstruck. 35.139.154.158 (talk) 05:33, 18 January 2024 (UTC)
Support having reviewed (what I could see) of the evidence, it is clear that nearly every single editor involved in the area has a tendency to go all BATTLEGROUNDy at the drop of a hat. See Tvx1 above. ~~ AirshipJungleman29 (talk) 19:57, 18 January 2024 (UTC)
Comment: I'm neutral on whether or not general sanctions would help, but I don't believe the problem is darts. The problem is one we've seen time and time again where a few editors take control of a specific corner of Wikipedia, establish their own way of doing things, and the community drags its feet on doing anything about it. GS is a bandage that might have a marginal effect on this outbreak, but it doesn't actually solve the problem. We don't need to fix the darts topic area, we need to fix WikiProjects and the way they facilitate ownership of content, and we need to start handing out bans to editors who can't engage civilly. If general sanctions are adopted, I agree that it should only be for a limited time. Thebiguglyalien (talk) 21:43, 18 January 2024 (UTC)
I'm not sure the problem is WikiProjects any more than it is Darts. To me the problem is groups of entrenched editors fixated on isolated topic areas (darts, roads, weather etc); they do tend to congregate at Wikiprojects but also regular article talkpages, project-space pages, etc. Even off-wiki locations, so restructuring the WikiProjects themselves won't be effective. Discretionary Sanctions are the one thing that's shown promise, so I think applying it to more of these areas could help correct the issue. The WordsmithTalk to me22:16, 18 January 2024 (UTC)
Overall I agree, but WikiProjects seem to facilitate it the most when this comes up, and getting better about restricting the whole "controlling a topic from a WikiProject" thing would benefit Wikipedia overall. But you're right that there's an underlying problem here beyond individual topics and beyond WikiProjects. Walled gardens need to be broken whenever they crop up, and group ownership over a topic area needs to be easier to address. Once a group of editors decides to ignore best practices in their topic area, there's very little recourse short of a massive Village Pump or ANI discussion (and even those are hit or miss). Thebiguglyalien (talk) 01:54, 19 January 2024 (UTC)
Yes, this is exactly the problem. We see the same things in so many areas, and LOCALCONs just self-perpetuate due to the editors in a niche WikiProject being the only editors following a DELSORT topic. So we end up with long-term "consensus" that, e.g., academic journals do not have to have ever received any significant or even secondary independent coverage to have an article, simply because editors in that area misrepresent an essay as if it's a real guideline or as if it was compatible with GNG at all. That leads to articles on pseudoscience-peddling academic journals that can only be based on puffy content from their own website and outdated, trivial primary data from an indexing service they applied to join... Or, e.g., the "600 articles on phone versions" from that other thread, or the "solar eclipses sourced only to primary news reports and listicles" issue pointed out there by @TryKid. It's Wikipedia-wide. JoelleJay (talk) 03:42, 19 January 2024 (UTC)
Believe me, I know. I spent several months challenging WikiProject ownership at WP:YEARS with mixed results, and I keep an eye on Wikipedia:WikiProject Deletion sorting/Events because many of the regulars there have decided that routine news coverage demonstrates notability. There just needs to be a way to address the Wikipedia-wide problem rather than playing Whac-A-Mole with general sanctions and then hoping that admins actually pay attention to the given area. Thebiguglyalien (talk) 04:10, 19 January 2024 (UTC)
It's dissapointing that some people only see the negatives of WikiProjects and don't see the many WikiProjects have actually been very positive to Wikipedia by colleborating to do things like writing multiple Good and even Featured Articles. Tvx1 23:41, 30 January 2024 (UTC)
Oppose I'm not sure that sufficient evidence has been put forth that this is a widespread problem, rather than being a few editors we could easily handle through regular process. I also don't see how this solves the walled garden issue. There is considerable muttering that the darts regulars are being recalcitrant. But somehow I doubt that GS is going to be used against the regulars. Indeed, it seems more likely that GS is going to be used against darts newbies, to keep out dissenting voices. CaptainEekEdits Ho Cap'n!⚓23:08, 18 January 2024 (UTC)
Contrary to the previous three users, when I read the pages the nominator links, I can see behaviours that rise to the level of community sanctions. Way back last year, JRRobinson was indefinitely blocked and topic-banned, but I think his conduct and language has become normalized in this topic area, and we're still seeing discourse at his level. The AN/I thread led to an indefinite block of Penepi, which I think is a useful intervention. In the AN/I thread, ItsKesha articulated a clear apology and retraction, and pledged to do better in future. I think the jury's still out on whether there's more to do; but as a precautionary measure, for the time being, I would support community sanctions.—S MarshallT/C10:07, 22 January 2024 (UTC)
Support: It's not just currently, but there've been issues with darts-related topics going back a decade or more. Some people might think the topic a petty one for sanctions, but the measure of a contentious topic is, well, the degree to which people are running to the battlements. Ravenswing 17:49, 22 January 2024 (UTC)
Leaning oppose. GS (and DS, CT, and the like) are good for a handful of particular problems: mainly blocks that won't stick, pages in need of more liberal protection, and editors who need to be topic-banned rather than blocked. They shouldn't be used just as ways for the community to signal its unhappiness with something, I don't think. It seems that the conduct issues in this area are already being resolved quite effectively when they're reported at AN[I], and adding general sanctions just adds more long-term bureaucracy for little gain. But I certainly support the underlying idea that the behavior in this topic area hasn't been appropriate and that admins should feel empowered to make blocks as necessary. Extraordinary Writ (talk) 07:42, 23 January 2024 (UTC)
Oppose, seems to be much more preferable to deal with on a case by case basis. While there is some issues with WP:OWNership from the looks of things, I don't see (and can't imagine) the problem to be articles about darts tournaments, but rather a behavioral thing with users. It might end up in shared spaces with darts and related talk pages... but "darts" are not the cause, and the topic doesn't seem like it needs to get hit with sanctions. Utopes(talk / cont)07:54, 24 January 2024 (UTC)
Strong Support I don't think that darts are above sanctions, and this topic area needs to be cleaned up from the link above. Culture is the single worst problem Wikipedia has right now. Swordman97talk to me22:04, 5 February 2024 (UTC)
Try lesser sanctions like blocks of the editors involved. A contentious topic or general sanction designation should really only be used when we need to discourage good-faith editors to ensure accuracy and minimal to no disruption. I am not seeing how this is a topic that will attract continued disruptive editing. Interesting side note: almost every topic designated on WP:GS already are very contentious topics in the real or academic world outside of Wikipedia. AwesomeAasim06:30, 7 February 2024 (UTC)
I was hoping that imposing sanctions on the topic area would be the less severe option, with the possibility of restrictions and blocks inducing better behavior without the need to actually impose blocks on anyone. Nonetheless this proposal doesn't seem likely to achieve consensus, so it may be necessary to take this advice the next time this topic area flares up. The WordsmithTalk to me17:09, 7 February 2024 (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.
Separate Buttons For Visual Editing and Source Editing
As we all know, Wikipedia has two different modes of editing: visual editing and source editing. However, upon a visit to German Wikipedia to translate an article, I noticed that they separate the "Edit" button that appears on top of the page to two different buttons - "Edit" and "Edit Source Code" (the bar shows Read | Edit | Edit Source Code | History). I think that would be a useful change to make on the English Wikipedia. Sometimes you want to make simple edits and it pulls up the source editor, which means you have to waste a few seconds switching it, and vice-versa. This would simplify the process of editing as it would allow users to jump straight to visual or source editing depending on their needs without having to waste time switching it. It would also help let users know when a page only allows source editing instead of visual editing, which some pages do. StreetcarEnjoyer (talk) 20:50, 13 February 2024 (UTC)
I think you'll find it's more complicated than that. The mw:VisualEditor/Single edit tab (an unfinished project of the mw:Editing team; pinging @Trizek (WMF)) is better for brand-new editors, who don't know what the difference between "Edit" and "Edit source" is. For myself, as a power user, I prefer two tabs, and I use both frequently, based on what kind of edit I plan to make.
Maybe edit source could be renamed to something like "edit wikitext" to better clarify what it does? When I was new I thought source editing would be editing HTML directly so it was a bit confusing. StreetcarEnjoyer (talk) 21:39, 13 February 2024 (UTC)
New editors don't know what "wikitext" is, so I don't think that will help.
I don't think there is a perfect name for this label. I believe I saw one comment, some years ago, from someone who thought that "Edit source" meant editing the Wikipedia:Reliable sources. Mostly, I think that people will figure it out by clicking on the button. WhatamIdoing (talk) 16:54, 14 February 2024 (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 there, Wiki changed the font on Thursday night but is there any way you are able to revert it back to the original font before the changes on Thursday. The new font changes on mobile look very ugly and I personally would much prefer the original font design. VileName8089289 (talk) 18:45, 18 February 2024 (UTC)
At least the browser I use allows me to choose the standard serif/non-serif fonts for rendering text in settings, which doesn't override Google's preferences but whatever is Wikipedia's default font is substituted by the font of your choice. I use Bahnschrift (essentially DIN 1451), but you can choose Comic Sans if you want.
As far as we are concerned, most of us cannot change it on a system level. You should first start with the technical part of the village pump, maybe they will have a better grasp on your issue (I noticed nothing tbh), and maybe they will ask you to add a ticket to Phabricator (a bit like Wikimedia's internal Github). It could also be that interface administrators tweaked something, though I heard nothing about it. If VPT doesn't help, ask the interface administrator noticeboard if they were tweaking anything lately that caused a change in fonts. Szmenderowiecki (talk) 19:17, 18 February 2024 (UTC)
Also, BEFORE YOU ASK ANYWHERE ELSE, make sure you didn't change your system font settings on your phone or tablet. Maybe you inadvertently did just that. Because I am on mobile and I cannot reproduce your problem. It looks OK. Szmenderowiecki (talk) 19:21, 18 February 2024 (UTC)
The font design changed to the new edition on Thursday night then it briefly reverted back to the original design and then permanently changed to the new design. The new design is much less appealing and I much prefer the original font design pre Thursday night. VileName8089289 (talk) 20:35, 18 February 2024 (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.
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.
Why do we have to use the British imperial style of writing in the English Wikipedia? Most native English speakers use the American style of writing. Furthermore, the British imperial style reminds a lot of people of colonial abuses. I certainly don't want to be reminded of any of that while editing an article. Wikipedia is a free, democratic wonderland to me, but having to learn "the King's English" reminds me of how many robberies, rapes, and murders it took to build that empire. This destroys my inspiration, my motivation. I would be happy to learn a new style that doesn't remind me of violence, however you like, but please, no more abuse. Citizen127 (talk) 11:47, 19 February 2024 (UTC)
And the Americans didn't rob, rape, and murder in building their 'empire' across the west? Just ask the Indians about that. But, seriously, EVERY empire ever built from the Persians, to Alexander the Great to the Romans to the Mongols the Spanish to the Japanese robbed, raped, and murdered their way to emperial 'glory'. To take it a step further, most empires also practiced genocide while expanding. So I don't see your point in singling out the Brits. Masterhatch (talk) 12:48, 19 February 2024 (UTC)
Just a side note to clear up a potential misunderstanding regarding Wikipedia being a "free, democratic wonderland"; in fact, it is not a democracy. It has processes which resemble democratic voting, but these are still generally consensus-based and subject to override (even straw polls such as RfA); and the institution itself is not wholly democratic, due to the site's relationship to the Wikimedia Foundation and effectively functioning as its volunteer arm. Duly signed,⛵ WaltClipper-(talk)13:42, 19 February 2024 (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.
Please revert font design on wiki to original design used before Thursday
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Don't badger us with the same requests over and over again - this will not increase your chances of addressing your concerns. The VPT thread is dealing with that, and you already got advice above (how you change fonts on your device/browser, rather than in Wikipedia, is device/browser-specific); no need to start more of these discussions. Szmenderowiecki (talk) 16:18, 19 February 2024 (UTC)
Hello there, Wiki changed the font on Thursday night but is there any way you are able to revert it back to the original font before the changes on Thursday. The new font changes on mobile look very ugly and I personally would much prefer the original font design. VileName8089289 (talk) 15:20, 19 February 2024 (UTC)
Asked and answered two sections up. Please stop posting this over and over, on this page and on the other pages you have been doing so. MrOllie (talk) 15:21, 19 February 2024 (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.
Here are some links I think it could include: (note that the information in the middle columns is mostly based on observation and guesswork, and only occasionally on documentation)
EBSCOhost and ProQuest unfortunately appear to be technically infeasible without some modifications. EBSCOhost requires a token in the URL alongside the query, and ProQuest sends the query in a POST request.
I welcome this. The ISSN link defaults to OCLC, so that would mean one extra click to getting where you're going. BUT the advantage is that if one place doesn't give you access, another place might have it. SWinxy (talk) 19:44, 20 February 2024 (UTC)
Yeah, the OCLC WorldCat URL is what {{ISSN}} and {{ISSN link}} currently link to. It's good for finding library holdings.
FWIW: I think Google Books and HathiTrust are usually included in the lists of libraries for a digital edition when they have a scan, but I'm not sure if their links work, so actually locating the entry is a pain, especially for Google Books. And I don't think the other sources are listed at all, though I haven't really checked. Google Books and HathiTrust usually link to WorldCat. Google Books and WorldCat have metadata for most things I've looked for, but I think ISSN Portal has public metadata for all non-provisional, non-legacy ISSNs and subscriber have access to metadata for all ISSNs ever assigned.
I think using WorldCat typically takes enough clicks that the inconvenience of one more click is probably worth the convenience of having much easier access to other websites that might provide better access to it.
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.
Support as nom The new title would clarify the noticeboard's purpose to new editors. AN is much less clogged than ANI, and complex issues can be discussed in AN without the trouble of short archive durations or large page sizes. Catalk to me!16:31, 18 January 2024 (UTC)
Oppose ANI's original purpose is for "urgent incidents", which overlap with user conduct issues much more than they overlap with the routine administrator actions and ban appeals than AN sees more often. ChaotıċEnby(talk · contribs) 16:01, 18 January 2024 (UTC)
Oppose: “ANI” is just too iconic, and incidents that aren’t user conduct can sometimes appear. Both urgents and user conduct need urgent review, and splitting would require prospective people to watchlist subscribe to both pages and get everything at once. Aaron Liu (talk) 16:22, 18 January 2024 (UTC)
Weakish oppose. This isn't a bad thought, and if we were just setting up the noticeboard, I'd want to give it serious consideration. I do think it'd help newcomers understand the noticeboard's purpose more easily, and that it'd discourage the (frequent) misuse of ANI as a place to litigate content issues. My main hesitation would be that titling the noticeboard "user conduct" would make the "you've been mentioned on ANI/ANUC, therefore you've done something wrong" implication even stronger than it already is, which might in turn raise the heat level, which is, uh, not what that noticeboard needs. That said, I have to oppose because, in 2024, the noticeboard has been ANI for ages, and retitling it would cause disruption/make it harder to read the historical record. There is not a compelling enough need for a change to make that worth it. {{u|Sdkb}}talk16:50, 18 January 2024 (UTC)
Oppose. As I showed in the RM, incidents requiring immediate admin intervention aren't ANI's "secondary purpose"—the clue is in the name—they're the original and primary reason that the board exists. Its mob-justice user conduct function crept in over time without anyone really meaning it. If change is needed, it's in the other direction: we should be directing user conduct complaints away from ANI and towards lower-drama options like WP:DR and WP:XRV. – Joe (talk) 17:20, 18 January 2024 (UTC)
Oppose - This feels a bit like rearranging deck chairs on the Titanic, and would just continuously confuse users with 33% of posts being closed as "No action, take it to WP:AN". We don't need to create more problems in a board that's already rife with problems. Duly signed,⛵ WaltClipper-(talk)17:24, 18 January 2024 (UTC)
Oppose and topic ban Ca from meta edits/discussion about ANI Ca seems to be unable to drop the stick about ANI being not what they want it to be. The requested move was closed only 12 days ago and we are having a very similar discussion. --GuerilleroParlez Moi17:57, 18 January 2024 (UTC)
Ehhh, seriously? It was just seekings of consensus within process (the RM) after a bold edit, and following okay advice from someone else. I don’t see why this warrants a topic ban. Aaron Liu (talk) 18:03, 18 January 2024 (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.
I think I would prefer the reverse: discuss patterns of user behaviour at the administrators' noticeboard, and leave the incidents noticeboard solely for incidents that require immediate attention. isaacl (talk) 17:19, 18 January 2024 (UTC)
I find AN to be a place I'm more likely to check in on given the pace, volume, and temperature of discussions when I'm busy than ANI. Bringing some, but not all, of the discussions where temperatures flare the most to AN would, for me, not be any sort of improvement. Joe's suggestion above about directing some stuff to other forums already setup to handle them is also a good one. Best, Barkeep49 (talk) 17:41, 18 January 2024 (UTC)
To double-check my understanding, are you saying that you feel discussions on patterns of user behaviour as well as discussions of incidents requiring immediate attention are both discussions where temperatures flare the most? isaacl (talk) 18:07, 18 January 2024 (UTC)
I wrote the following a few minutes before the RfC closed, and I am not convinced there is WP:SNOW possibility of a change in the opposite direction: [Oppose, but] delete the words "and chronic, intractable behavioral problems" that were added to the page header in June 2018 per Joe Roe. ANI is certainly not a suitable venue for dealing with accusations of that kind. At the moment ANI certainly sometimes functions as a kangeroo court, where it is not possible to get natural justice or a fair hearing (!voters are not even required to be impartial, or to be capable of telling the difference between reality and fantasy, and there are no rules of evidence etc); such discussions there are sometimes vehicles for subjecting regular editors to harassment and psychological abuse, that sometimes rises to the level of a massive public show trial, complete with ritual public humiliation and threats, bullying, gaslighting and other pressure to make forced false confessions; such discussions there are sometimes vehicles for trying to gerrymander a content dispute by making false or frivolous conduct accusations in attempt to get the other side blocked or banned so that they won't be able to !vote in the content dispute; and such discussions there are sometimes a an exceptionally toxic environment, and sometimes not an environment compatible with the safety of editors either. James500 (talk) 20:08, 18 January 2024 (UTC)
@James500 I closed it due to the fact that the RFC is for changing the whole purpose of ANI in general, (which doesn't have a chance right now)) not just the header, that is why I left this section open so things like changing the header can be discussed. Seawolf35T--C20:23, 18 January 2024 (UTC)
I agree with the many of the points you made. If we were to not use ANI for such purpose, what should be the alternative(s)? Catalk to me!00:38, 19 January 2024 (UTC)
I think there should be a more concerted effort to direct people to the more structured alternatives that already exist for specific types of disputes (WP:DRN for content disputes, WP:XRV for contested use of permissions, WP:AE for edits in contentious topics, etc.) and, as a last resort, ArbCom for the remainder. – Joe (talk) 07:54, 19 January 2024 (UTC)
RfC: allow soft deletion of unopposed nominations
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.
No consensus for proposal. As indicated in the discussion there is already provision for the AfD closer to soft delete an article that has been de-prodded. The consensus appears to be that the current system of the closer making an informed judgement based on the circumstances to either relist or soft delete after one week is fairer than encouraging or requiring a soft delete after just a week. SilkTork (talk) 01:24, 24 February 2024 (UTC)
probably, yes. This shows that there is probably little reason to keep the article in question, so can be deleted. However, if a good reason does exist, it should be reinstated, hence soft deletion Cal3000000 (talk) 16:08, 13 February 2024 (UTC)
Details (RfC: allow soft deletion of unopposed nominations)
If a nomination has received few or no comments from any editor, and no one has opposed deletion, and the article hasn't been declined for proposed deletion in the past, the closing administrator should treat the XfD nomination as an expired PROD and follow the instructions listed at Wikipedia:Proposed deletion#Procedure for administrators.
This proposal would remove the requirement that an article be eligible for PROD to be "soft deleted". In effect, this would mean poorly-attended but unopposed deletion debates can be closed as WP:REFUND-eligible soft delete.
Survey (RfC: allow soft deletion of unopposed nominations)
Support as proposer. In December, there were 46 deletion nominations ultimately closed as delete after being relisted as "ineligible for soft deletion": 1, 2, 3, 4, 5, 6, 7, 9, 10, 11,[a]12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32,[b]33, 34, 35, 36, 37, 38,[c]39, 40, 41, 42, 43, 44, 45, and 46.In fairness, there were four (4) articles that are still bluelinks because they were ineligible for soft deletion: 1,[d]2, 3,[e] and 4. But I don't think that a redirect, a stub, a non-neutral REFBOMB mess, and No Pants Day justify the volunteer time rubber-stamping nominations. WP:OFD2023 shows that ~15% of AfD nominations are closed as keep, which is ~twice the 8% survival rate of the "ineligible-for-soft-deletion" December group. This suggests that editor time is better spent rescuing other articles.Finally, I will note that this change would still allow for WP:REFUNDs of the affected articles. HouseBlastertalk01:15, 13 January 2024 (UTC)
I want to add a little bit to my rationale: this proposal would result in PROD and soft deletion being treated differently, and that is the point. A well-advertised-but-unattended discussion is not the same thing as a banner staying atop a page for a week. Arguing against this proposal because it would treat soft deletion and PROD differently is textbook circular reasoning: treating them the same way is A Good Thing because they should be treated the same way. Respectfully, why should fundamentally different processes have the same outcome?I would also point out that the status quo is the 46 articles from December are "hard" deleted: you either need some showstopping sources to show the closer/an admin at WP:REFUND or else must make your case at WP:DRV to get them undeleted. This proposal would result in all of them being REFUND-eligible. HouseBlaster (talk · he/him) 03:29, 14 January 2024 (UTC)
Strong support no irreversible harm. Potential abuse/misuse is mitigated by a single user and in worst case, a guaranteed WP:REFUND is always possible. ~ 🦝 Shushugah (he/him • talk) 01:36, 13 January 2024 (UTC)
Support Makes it easier to restore deleted articles and discourages drive-by/rubber stamp !votes. Seems like a net-positive. -Fastily01:54, 13 January 2024 (UTC)
Support but caveats: The nominator must make a clear delete rational; the nominator must declare that they have followed WP:BEFORE, and say why the BEFORE options, especially WP:ATD are not suitable. I assume that this can override a previous PROD removal. —SmokeyJoe (talk) 05:29, 13 January 2024 (UTC)
Oppose I have always held that soft deletion at AfD is simply a procedure where we pretend that the nominator, instead of nominating the article for AfD, tags it for PROD instead. So there should be no difference in the rules for soft deletion vs. PROD IMO. However, I am open to considering introducing an expiration for PROD declines, such that an article which has not been declined for PROD in, say, the last five years becomes eligible for both PROD and soft deletion. The reason why declined PRODs are ineligible for PROD is the same reason why we discourage edit warring - you shouldn't be able to get the last say just by being more obstinate at forcing your changes through. However, five years is long enough to presume that the original decliner may have forgotten about the article; they can always maintain their opposition by re-removing the PROD or !voting keep at AfD. -- King of ♥ ♦ ♣ ♠06:19, 13 January 2024 (UTC)
Support. It took me a bit to parse the proposal, which boils down to "can articles be soft deleted if they've had a contested PROD?". Q for nom: would this change mean that after a single week a decision would be made, or would the normal relisting cadence happen? I'm with King of Hearts in an alternate solution where a soft deletion would only be blocked if the PROD was less than some number of years ago. Eight years, perhaps? Ten seems too long (2014 was a decade ago) but 5 feels too soon (2019 was just a few days ago). SWinxy (talk) 19:22, 13 January 2024 (UTC)
I envisioned it being a tool in the closer's toolbox: namely, if they feel relisting would be productive, relist. If not, it would be eligible for soft deletion. HouseBlaster (talk · he/him) 22:33, 13 January 2024 (UTC)
Oppose per King of Hearts. If someone nominates an article for PROD, which is contested, and then immediately renominates it for AfD, just because the person who opposed that PROD didn't show up to the discussion, doesn't mean the article should be deleted. Also open to allowing PROD again after 10 years or something like that, but soft deletion is just applying PROD rules to AfD. Galobtter (talk) 19:31, 13 January 2024 (UTC)
Oppose. This proposal would effectively allow an article to be PRODed twice. If a PROD has already been removed once, the nomination is controversial. If the person who removes the PROD states in his edit summary that the article should not be deleted, or that the grounds for deletion are erroneous, or that the article satisfies GNG, or the like, I can only infer that the AfD is not unopposed, and that making a comment like that amounts to opposition. James500 (talk) 02:53, 14 January 2024 (UTC)
This proposal is also explicitly based on the assumption that changing the rules of AfD will not change the behaviour of AfD participants described by the statistics cited. It is not obvious that the assumption is true. This proposal might result in an increase in the number of nominations being made in the first place. Nominators might decide to send every declined PROD to AfD in the hope of getting a soft deletion while no one is watching. This proposal might also result in more keep !votes being made in the first place, if deprodders cannot just wait for an unattended AfD to be closed as no consensus. I also notice that the statistics cited are for December (the time of year when we have the fewest active editors), and do not take into account any seasonal variation that might exist. James500 (talk) 18:06, 14 January 2024 (UTC)
Fair enough point about seasonal variation. I pulled the statistics for June 2023 (chosen as halfway through the year): 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32, 33, 34, 35,[f]36, 37,[g]38, 39, 40, 41, 42, 43, 44, and 45.Bluelinks: 1, 2, 3, 4, 5, 6. There is also Wikipedia:Articles for deletion/Log/2023 June 16#Explore Learning, which I am not sure which category to put in. It was closed as "delete", but is currently a redirect to ExploreLearning (without a space). That article appears to be on an entirely different company. At the very least, the two articles (Explore Learning and ExploreLearning) coexisted for a period of time—maybe there was a WP:CONTENTFORK? I'd appreciate it if someone with admin goggles could take a look.Finally, the behavior changes you cite seem to be positive changes. The point of any discussion is to find consensus, which logically means "no consensus" closes are not an ideal outcome. We allow speedy renomination of no consensus closes for a reason, after all. Thus, I would argue that discouraging dePRODers from seeking a "no consensus" close is a good thing. I also take issue with the assertion that Nominators might decide to send every declined PROD to AfD in the hope of getting a soft deletion while no one is watching. First, I would hope that people would not attempt to game the system. But holding a full-blown AfD is absolutely not while no one is watching. There is a banner atop the page (which was evidently enough to attract the dePROPer), it is listed on the daily AFD log, and there is literally an entire WikiProject dedicated to ensuring other interested participants see the discussion. HouseBlaster (talk · he/him) 22:13, 14 January 2024 (UTC)
ExploreLearning and the deleted Explore Learning (AfD discussion) are two different subjects on two different continents. The latter went through Proposed Deletion in July 2008, one month after it was written. Also relevantly, a succession of copyright violations of corporate advertisements, editors with declared and undeclared (but obvious) conflicts of interest rewriting most of the article, and preference for the company WWW site over independent sourcing caused the non-company sources cited in 2008 when Proposed Deletion was challenged to have been long-since lost, buried years deep in the edit history, in 2023 when the article came to AFD. Uncle G (talk) 12:31, 18 January 2024 (UTC)
Oppose there is often low participation at AfD so waiting a second week for comments is reasonable. Also the deprodder would be rushed into responding when they may be offline for a period. This suggestion would unnecessarily speed up deletion without any consensus in my view, Atlantic306 (talk) 22:48, 14 January 2024 (UTC)
Oppose. If an article is ineligible for PROD then it is, by definition, controversial and is thus completely unsuitable for deletion without an active consensus to do so. Thryduulf (talk) 11:01, 15 January 2024 (UTC)
Oppose, although well-motivated, this proposal would open the door to deletion of articles that just don't happen to be interesting to the handful of editors who regularly visit AfD, even when the nomination is obviously spurious or misguided. Admins should be both allowed, and expected, to use their discretion to relist, or otherwise ensure that deletion is for policy-based reasons, not just because no one could be bothered that week. Elemimele (talk) 12:10, 15 January 2024 (UTC)
Oppose may open door for misuse. I see these cases as no consensus to delete which if anything should default to keep. Well-meaning proposal but defies conventional wisdom. --PeaceNT (talk) 04:36, 16 January 2024 (UTC)
Support. If nobody cares enough about an article to make a brief comment on an AFD, it does not have enough support to exist. Stifle (talk) 09:52, 16 January 2024 (UTC)
Meh This RFC seems poorly written, as it fails to note that very section the nomination links to goes on to offer several options for when it was an opposed prod, one of which already is soft deletion. It's unclear to me whether "supports" will be interpreted as supporting the status quo or as calling for something more strict, and I could see some opposes actually supporting the status quo too. I see there was a better-worded RFC on this topic at Wikipedia talk:Deletion process#Clarifying NOQUORUM Soft Deletes that didn't get many responses.Personally I think we can afford a relist or two before soft-deleting, even if the de-PRODder didn't notice the AFD to oppose there too, per WP:NODEADLINE. But leaving it open to admin discretion (i.e. the status quo) is ok with me too on the assumption that admins will save immediate soft deletion for clearer cases. Anomie⚔12:12, 16 January 2024 (UTC)
Oppose For similar reasoning as King of Hearts. I would not necessarily be opposed to this in cases with a multi-year gap between PROD and AfD, but I do not like the idea of essentially being able to PROD an article twice in a short period of time. As for a timeframe, leave it to admin discretion. Curbon7 (talk) 12:24, 16 January 2024 (UTC)
Oppose - a week is nowhere near enough time, a lot of articles for deletion are likely to be on more obscure topics, that we possibly should have articles about, but that most editors will not be familiar with. A week is not enough time to be seen by someone who might be able to expand the article or explain it's importance. If there's an automatic deletion cut-off it should be closer to a year. Irtapil (talk) 15:11, 16 January 2024 (UTC)
Procedural Oppose per Anomie. There is a lot of context missing from this RfC, such as how that sentence got added to the process and the conflict with another part of the same section, i.e. it may already be an option. I put forward a discussion at Wikipedia talk:Deletion process#Clarifying NOQUORUM Soft Deletes to try and discuss some different wordings and options that could be used in a proper RfC per WP:RFCBEFORE. It would be advisable to close this discussion, workshop the wordings on that talkpage, and come up with a more comprehensive one since the current wording is self-contradictory. The WordsmithTalk to me20:52, 16 January 2024 (UTC)
I take this proposal to be stating that we should strike and the article hasn't been declined for proposed deletion in the past, which I think would resolve the contradiction. voorts (talk/contributions) 04:01, 17 January 2024 (UTC)
If that's what this means, then support, to strip away some bureaucracy and also get rid of the kind of nonsensical idea that some CoI or other "problem article" writer gets a special "right" for having removed a prod tag while addressing no problems in the article. — SMcCandlish☏¢ 😼 01:31, 18 January 2024 (UTC)
I don't think that would have been deleted after just one week. There's no consensus for deletion in the first week - two different redirect arguments and a delete !vote. -- asilvering (talk) 00:07, 20 January 2024 (UTC)
eh. I appreciate the reasoning, but I don't much like the idea of an unopposed AfD being soft-deleted at the end of a single week, and I don't really think it's too much to ask that someone second an AfD in the event that an article was deprodded. I'd be happier with the idea if it was something like "can be treated as an expired PROD if they've been relisted at least once", I suppose. -- asilvering (talk) 00:14, 20 January 2024 (UTC)
I'll generally relist a no comment nom when I'm patrolling the logs but when no one has argued in support of retention or even commented indicated an interest, I will close these as a soft delete. No one has shown up in that two week window but if they do down the road, they don't need to do the DRV dance. They can have it restored and it can be addressed, if necessary at that time. I do think a week might be too little of a time though so while i do this, I'm not in full support. It's something that deserves merit though. StarMississippi01:31, 20 January 2024 (UTC)
Oppose if an article is ineligible for PROD, it is because someone has deprodded the article and would, presumably, !vote to keep in an AfD. They should not be expected to have to do this twice. I would be in favor of considering a time limit on prod (ie articles proposed for deletion >10 years ago can be re-proposed), when considering how much our notability standards have changed, and the possibility for PROD to be abused. Eddie891TalkWork15:55, 20 January 2024 (UTC)
@Eddie891 I don't think this is an accurate assumption. I frequently see PRODs like "article has existed since 2007, take it to AfD". Many de-prodders give no reason at all, and also do not show up to the AfD. -- asilvering (talk) 00:00, 22 January 2024 (UTC)
yes, but the implied de-prod reason in the first instance you give is that the person is suggesting the article be taken to afd, where more editors can !vote on the afd. And editors not showing up to the AfD is part of why I opposed— we cannot expect good faith de-prodders to have to keep tabs on a subsequent afd nomination and comment again. Eddie891TalkWork00:13, 22 January 2024 (UTC)
If I PROD an article, I keep it on my watchlist in case it is de-PRODed, so I can then determine if I want to take it to AfD. Presumably a person asking to take something to AfD will want to participate in that discussion, and if they do not, I don't think asking someone to take something through another bureaucratic hoop is a great reason to de-PROD. voorts (talk/contributions) 00:21, 22 January 2024 (UTC)
The person is suggesting the article be taken to AfD, yes. But it doesn't make sense to infer from that that the de-prodder would vote "keep". In my experience, they do not, since "article has existed since 2007" (or whatever) is not a valid keep rationale, and they can find no other. -- asilvering (talk) 00:27, 22 January 2024 (UTC)
On multiple occasions I've deprodded something not because I think it should be kept necessarily, but because I believe determining whether the topic should or should not have coverage on Wikipedia and/or whether it should have a standalone article or be covered on a broader one (i.e. merge and/or redirect) needs more time and effort than PROD allows. For example, I deprodded The Roaring Twenties (band) recently because google searches brought up so many false positives that determining whether sources exist for the subject is not possible from just a cursory look - especially as many of the obvious ways of excluding false positives will also exclude an unknowable proportion of true positives if they exist. In other cases I've deprodded because the most likely place sources are going to exist is in offline resources and/or in languages other than English. A third category is where the only realistic outcomes at AfD are keep, merge or redirect. Thryduulf (talk) 22:38, 7 February 2024 (UTC)
Sure, those are all fine reasons to contest PROD. That's exactly why it doesn't make sense to infer that a de-prodder would vote "keep". -- asilvering (talk) 03:25, 8 February 2024 (UTC)
But a PROD isn't a keep vote, it's a statement saying "this article should not be deleted by PROD." If there's no subsequent discussion at an AfD on an article that has been PROD-ed, the two statements are "delete this article" (nominator) and "don't delete this article through PROD" (the de-prodder) which is a no consensus as far as deletion is concerned. SportingFlyerT·C20:29, 13 February 2024 (UTC)
Support: it is too easy to create an article that worsens the encyclopedia's quality and too difficult to delete it. Anyone may object to a PROD without a valid reason, but only justified AfD comments are taken into account by the closer. Deletion should not be prevented because of baseless objections by article creators. Soft deletion after no reasoned opposition at AfD is a good approach. Relisting indefinitely is not a solution to low participation at AfD as a venue: the same number of discussions will need contributors regardless of how long they are open. A closing admin who sees the nomination is poorly reasoned should not delete the page. They should instead !vote in the AfD, present some references and/or improve the article (just as they should if it was a nomination and three baseless "delete" !votes). — Bilorv (talk) 21:37, 21 January 2024 (UTC)
Oppose - A week is too short of a time, so I would appreciate at least one relist. Since there are no requirements for editors in nominating an article for deletion (just expectations), suggestions to require a more complete nominations are unrealistic, or subject to interpretation by the closing editor. --Enos733 (talk) 19:13, 22 January 2024 (UTC)
Oppose I don't see anything wrong with the procedure here of relisting ineligible AfDs when discussion is light. The problem is really just that we need more AfD participants. SportingFlyerT·C19:16, 22 January 2024 (UTC)
Oppose - One week is not long enough. If it went through the cycle three times with nobody offering an opinion, I might see it — but when's the last time that has happened? A solution in search of a problem — or a short-sighted "solution" that will create problems. Carrite (talk) 03:53, 23 January 2024 (UTC)
Strong support If the administrator believes an relist would be appropriate, they should relist it. If an administrator believes an article that has received no opposition to deletion should be deleted similar to PROD, they should delete it, with the opportunity for REFUND. I see no need to forbid soft deletion in these cases that typically still result in deletion and no need to expect others to expend time casting a !vote for what may be obvious or easily undoable. Reywas92Talk21:42, 24 January 2024 (UTC)
Oppose per KoH (who, no, I am not related to). If someone has previously objected to deletion, we should not just go behind their backs deleting it. QueenofHearts04:13, 26 January 2024 (UTC)
Oppose A handful of editors are saying it doesn't harm anyone. It will drive off many a new editor who sees their hard work turn into a red link and who leaves without asking for a WP:REFUND, either due to ignorance of its existence or anger/sadness with the community. Also per Thryduulf in particular. Sincerely, Novo TapeMy Talk Page18:30, 30 January 2024 (UTC)
If people use AfD as cleanup, then this would be true. But it an experienced editor truly believer an article was not notable, no process whether DRAFT'ication, reviewing it or even PROD'ing it will make it notable. New editors should interact with kind AFC reviewers and or NPP reviewers. I see this proposal as reducing the amount of time in AfD to precisely increase time for reviewing AfDs themselves and reviewing new articles. But testing this out would reveal that better. ~ 🦝 Shushugah (he/him • talk) 21:46, 7 February 2024 (UTC)
People shouldn't use AFD as cleanup, but it happens quite often. New editors should interact with kind AFC/NPP reviewers, but many get bitten instead. This proposal will not go any way to remedying either problem, rather it will make the impact of people incorrectly using AfD as cleanup worse and it will increase the number of new editors who are bitten. Thryduulf (talk) 22:24, 7 February 2024 (UTC)
As Thryduulf wrote, unfortunately many do use AfD as cleanup.
Also, any logged-in user, regardless of knowledge of policy, may nominate. The proposal doesn't require anyone to vote (assuming I'm reading it correctly), so experienced editors may not even voice an opinion. Sincerely, Novo TapeMy Talk Page18:12, 9 February 2024 (UTC)
Strong Support AFDs with no participation is a major problem in this process, there are at least 20-30 of them that get zero attention at any given point of time - just look at Cyberbot. Saying that more people should join AFD is NOT going to solve things, most people gather around a few popular AFDs anyway and ignore the rest. Swordman97talk to me22:17, 5 February 2024 (UTC)
Support? oppose per below - I don't think I understand the opposition. The proposal requires closing admins to go through the "before deletion" part of WP:PROD, right? That includes making sure "The page is eligible for proposed deletion: the page is not a redirect, never previously proposed for deletion, never undeleted, and never subject to a deletion discussion." So let me spell out what I'm supporting: PROD → DEPROD → NO-VOTE AFD → NO SOFT DELETE [NO PROD/DEPROD] → NO-VOTE AFD → SOFT DELETE What am I missing? — Rhododendritestalk \\ 18:11, 6 February 2024 (UTC)
I think I got caught on the fact that once an article has gone to AfD, it is by definition ineligible for PROD, and this was to address that problem but is worded in an overly broad way. Sounds like extra breadth (to apply to articles that have been prodded/deprodded in the past) is kind of the point. In that case, yes, I am opposed. — Rhododendritestalk \\ 18:27, 6 February 2024 (UTC)
Oppose per king of hearts but I do think that allowing a PROD again after a long time period (10 years? 5 years?) is reasonable. Hobit (talk) 21:13, 7 February 2024 (UTC)
Why does the passage of time automatically make something that was controversial no longer so? Sure it will in some cases, but unless it does in at least the significant majority (which I'd be interested to see evidence for) then it doesn't strike me as beneficial to the project. Thryduulf (talk) 22:26, 7 February 2024 (UTC)
To me it's because an objection from years ago has little weight now. Our inclusion guidelines (and more so, how they are interpreted) have changed significantly in that time. An old objection based on how things were doesn't seem like it's hugely relevant at this point. It's not something I really want, but I think it would be a reasonable compromise. Hobit (talk) 23:49, 7 February 2024 (UTC)
That assumes that the old objection related to something that is no longer relevant and/or standards that have been superceded. That is going to be true in some cases, but in other cases the objection is still going to be "hugely relevant" today. For example rationales like "plenty of sources in books", "seems notable based on the <other language> Wikipedia article", "widely covered in contemporary (non-English) newspapers", "sources seem to be available but they're paywalled so I can't check myself" and "if this is not individually notable it should be merged not delete", for example. It would be better if sources were in the article of course, but assertion that sources existed 5-10 years ago is as much a reason to take it to AfD today as it was 5-10 years ago. Thryduulf (talk) 01:12, 8 February 2024 (UTC)
Fair. And because AfD is always a way forward, that's reasonable. But it feels reasonable to me to let them expire as described. I agree it could be abused. Hobit (talk) 01:48, 8 February 2024 (UTC)
Oppose I've been here for (mumble, mumble) a very long time, & this is the first time I've heard of "soft deletes" & I don't understand the point of it: an article is either kept or deleted. And if someone as experienced as I doesn't understand the point, I figure new volunteers will be equally confused. (Unless they are uniformly smarter than me, which is entirely possible.) -- llywrch (talk) 22:18, 8 February 2024 (UTC)
A WP:Soft delete is basically a PROD that spent some time at XfD and received very few (if any) comments rather than being prodded. If a page has been prodded or soft deleted anyone can get it back by going to WP:REFUND and asking. If a page has been deleted following a consensus, they need to go to DRV and convince folk there that there was something significantly wrong about the deletion. Thryduulf (talk) 22:44, 8 February 2024 (UTC)
Oppose I think that this is the defacto process for those anyway, except that this proposal speeds up the time table. Lots of AFD's need more than a week to get some input. North8000 (talk) 23:04, 8 February 2024 (UTC)
Reluctant oppose This creates a loophole where deprodding can be bypassed through a low-attendance AfD (i.e. you prod, they deprod, you AfD, they ignore or fail to notice it, the article gets deleted, all in a relatively short amount of time). I would support if the proposal specified that the deprod must have been at least (say) five years ago. I would alternatively support a proposal to "expire" old deprods as King of Hearts suggests (in which case this proposal would be unnecessary). I would also also support a proposal to discourage (but not prohibit) relisting more than N times (for, say, N=3), to encourage the closing admin to select another option (policy already allows the use of soft deletion at the discretion of the closer).This is already in the policy, oops. Any proposal along those lines would have my support. It's just this particular combination of features that, in my opinion, is problematic. --NYKevin04:17, 11 February 2024 (UTC)
Mild support though I think one re-list is a reasonable check on this. It's pretty rare that something slides through AFD without any comments, and there is always a WP:REFUND later. Shooterwalker (talk) 14:42, 16 February 2024 (UTC)
Strongest possible oppose This will certainly result in articles that should not be deleted getting deleted and remaining deleted, per other opposes above. AFD soft deletes are a problem and we don't need any more of it. One takes an article to AFD in the hopes that an enforceable consensus will determine the fate of the article for what is usually a considerable amount of time. Soft deletes of AFDed articles are a loophole for COI/UPE. If I counted all the times problematic articles got soft deleted by admins not knowing to evaluate whether a misuse was likely, and got refunded soon after, I would be very mad right now, and that's just not healthy. Usedtobecool☎️15:49, 19 February 2024 (UTC)
Oppose It's very difficult to get a clear consensus if there are only a few participants (e.g. nominator plus one or two) in an AfD. That being said, anyone concerned about an article absolutely should take the time and make their argument at its AfD nomination. XtraJovial (talk • contribs) 21:39, 21 February 2024 (UTC)
Oppose as written. Something with more checks and balances might work. Perhaps we should require a delete !vote by someone other than the nominator. An alternative would be for the closer to do due diligence to check for sources etc, but that's not the closer's job and they may have better things to do. We could say that anyone other than the nominator can close the unopposed AfD as delete, but only if they repeat the WP:BEFORE as a check. Certes (talk) 10:03, 23 February 2024 (UTC)
Discussion (RfC: allow soft deletion of unopposed nominations)
So not comment then default deletion ..... do those involved in deletion at least look for sources...as in is there an common sense or effort involved if noone comments? Moxy-04:48, 14 January 2024 (UTC)
If people are not looking for sources before !voting, I would argue that is a problem beyond the scope of this proposal.HouseBlaster (talk · he/him) 02:42, 15 January 2024 (UTC)
MIKTA is just a case of a really bad nomination by a user who clearly sent an article to AfD without Googling its title. Lazy nominations are a problem with or without soft deletion. Pichpich (talk) 04:35, 15 January 2024 (UTC)
Perhaps, although I'd be counting on the closing admin to review the deletion rationale before actually soft-deleting the article, just as I'd expect admins to close PRODs as deletions only after performing the usual and basic WP:BEFORE checks. Am I just being naïve here? Pichpich (talk) 12:58, 15 January 2024 (UTC)
Am I just being naïve here? unfortunately you are. While the worst offender that I know of was desysopped, there is no shortage of deletions being done without proper checks. Thryduulf (talk) 14:56, 15 January 2024 (UTC)
I know for a fact at least some admins don't look at articles at all when closing deletion discussions, so no. (And TBF deletion closers have a lot of work to do without replicating the participants work) Mach61 (talk) 16:49, 15 January 2024 (UTC)
The admin instructions for handling expired PRODs do not require us to conduct checks for sources (etc.) prior to deletion, but if you feel they should be changed to include such a requirement, feel free to gather a consensus to that effect at Wikipedia talk:Proposed deletion. WP:BEFORE is a part of a different process, namely WP:AFD; PROD is intentionally a more streamlined process. Stifle (talk) 08:55, 23 January 2024 (UTC)
The intention behind this proposal is decent. I might encourage another proposal with a few more checks and balances, but I think it's so rare that a deletion discussion would go more than a week with no response. Shooterwalker (talk) 14:38, 16 February 2024 (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.
New Anonblock/Schoolblock template
A long time ago I wondered why we have a separate anonblock template for educational institutions, and one pointed out that the educational one has information specific to educational institutions (specifically, it provides information related to class projects). The problem with this is that sometimes IP addresses belonging to educational institutions are not easily identified. So to address this, I've boldly created a new template that merges both of them at {{New Anonblock}}. Thoughts? PCHS-NJROTC(Messages)Have a blessed day.00:24, 24 February 2024 (UTC)
Proposal for Integrating University Knowledge into Wikipedia
Hello! I share with you this proposal, it is still not very mature, I would appreciate ideas and suggestions to carry it out. Any opinion is welcome. Thanks
The aim of this proposal is to compile and share all academic content from universities on Wikipedia. This involves adding the syllabi of all subjects from all university degrees to the platform, providing free and open access to university knowledge for anyone or any artificial intelligence.
Implementation:
1. Acquisition and Digitalization of Notes:
Students are encouraged to digitize their notes and publish them under the CC BY SA license for inclusion in Wikipedia.
Participation from students can be promoted through annual awards for the best notes in each degree, whether in the form of monetary incentives, meal vouchers, or transportation grants. It is crucial to avoid plagiarism and respect copyright.
Collaboration with student delegations and the involvement of professors in this task are encouraged.
2. Uploading Content to Wikimedia Commons:
Students can upload their notes to the Wikimedia Commons repository with their full name, which enhances their visibility on Google and improves their curriculum vitae.
3. Distribution of Content on Wikipedia:
The notes are reviewed and understood, and the information is distributed across related Wikipedia articles.
To achieve this, two options can be considered:
Hiring specialized editors.
Requesting the collaboration of Wikipedia volunteers, possibly establishing a Wikiproject dedicated to organizing tasks and coordinating content contributions.
This proposal aims to enrich Wikipedia's content with verified and accessible academic knowledge, benefiting students, researchers, and learning enthusiasts worldwide.
See Wikipedia:What Wikipedia is not. Students notes are (or should be) original works. Wikipedia is an encyclopaedia, which only contains articles summarising material from already published reliable sources. Whether Wikiversity might accept such content, I don't know: you could try asking there. AndyTheGrump (talk) 18:32, 2 March 2024 (UTC)
For example, the heading "April 18" would appear as large as the page title, and an article title like OneGet would look like the "Bump XfD heading sizes" heading above. For obvious reasons, this does not include WP:Requested moves.
Yes. This would make all such individual page discussions subscribable, and only level-2 headings are subscribable due to technical complexity. As for the level-1 heading, most XfDs already have a separate page for each day's log anyway, so displaying it as large as the page title shouldn't cause much problems. Aaron Liu (talk) 17:00, 26 January 2024 (UTC)
@Aaron Liu: Two questions. (i) Have you informed all relevant bot operators, and the maintainers of scripts like XfD Closer? (ii) do you intend to alter old XfD pages? --Redrose64 🌹 (talk) 20:26, 27 January 2024 (UTC)
No and no. You do bring up a good point with notifying scripts, but I don't see any scripts other than @User:Evad37's XfDcloser and @Awesome Aasim's xfdvote that could be affected. I do not intend to alter old XfD pages, as there really isn't much of a point in doing so. Maybe we could only alter these beginning in March so monthly logs retain some uniformity. Aaron Liu (talk) 23:20, 27 January 2024 (UTC)
I see it as pointless. At the most, the heading for the top level should be level 2, not 1. If anything it could mess with scripts as stated by Pppery Redrose. I don't think my script would be affected, but others certainly can be. AwesomeAasim23:49, 27 January 2024 (UTC)
I think you meant Redrose Having the top heading would be very confusing and wouldn't have everything below it fold, and I can name at least one other discussion page that has level-1 headings. I don't see why it would be bad either, and while I don't know much about XfD closer's code, I suspect it'll be an easy fix of adding one equal sign to everything. Aaron Liu (talk) 01:08, 28 January 2024 (UTC)
It's also definitely not pointless. It allows people to subscribe to a section instead of watchlisting the entire page for notifications. Wikipedia:Help desk has already done basically the exact same thing. Aaron Liu (talk) 01:25, 28 January 2024 (UTC)
Subjectively I prefer the look of the current smaller headings. Though I realise this is pretty small compared to the practical advantages of subscribing to a new topic. ― novov(tc)11:15, 28 January 2024 (UTC)
Some other thoughts: 1) Using H1's seems to be a bad practice and is avoided almost everywhere on enwiki. 2) Changing this would likely require patches to several pieces of software including WP:Twinkle and mw:Extension:PageTriage. 3) It may be a good idea to sandbox this and drop a link here so we can see what it would look like. –Novem Linguae (talk) 09:26, 30 January 2024 (UTC)
Traditionally the advice has been to avoid multiple first-level headings on the web, but for semantic reasons, rather than technical problems, assuming the heading structure is laid out in appropriate hierarchical order. (As far as I know, assistive technology such as screen readers don't have a problem, and search engines deal with it as well.) It can be argued, though, that a web page could semantically be a container for multiple documents, each with its own first-level heading. In the context of MediaWiki, since the software automatically generates a first-level heading for the page title, then semantically everything before the first = heading = in the wikitext would be its own document.
Although personally I feel a bit uneasy with more than one <h1> element on a page, I can't say that it causes any practical problems from a general web perspective (I don't know about the various tools and extensions used by editors). There are of course already English Wikipedia pages with multiple first-level headings, such as Wikipedia talk:Mass message senders. isaacl (talk) 18:44, 30 January 2024 (UTC)
I agree that there should be no technical wider-web issues; the HTML spec even provides an example of how outlines with multiple h1 elements can be rendered, so any fully-compliant user agent will take it in stride. Having said that, if there are a bunch of internal tools that will need to be updated to handle the change (and it seems that there are), then that's the more relevant technical issue. I'm not worried about the semantic aspect, given that something like XfD should prioritize the needs of its specific users, determined through consensus, rather than doggedly adhere to general advice. Regards, Orange Suede Sofa (talk) 00:18, 31 January 2024 (UTC)
If you mean how the list is transcluded under the final section, I actually don't see much of a problem with that as the headers will only appear at the end of the ToC. RfD was an intended target. Aaron Liu (talk) 23:48, 8 February 2024 (UTC)
I wonder how well the existing structure of MFD works for people using screen readers, when they go directly to the page. It has a =Level 1= (the page title), then nothing for ==Level 2== or ===Level 3===, but there is a ====Level 4====. I'm pretty sure that skipping levels like that is not recommended. WhatamIdoing (talk) 05:27, 12 February 2024 (UTC)
@WhatamIdoing: It's not in the HTML spec; you need to burrow about in WCAG 2.2 in order to find G141 Organizing a page using headings, which says To facilitate navigation and understanding of overall document structure, authors should use headings that are properly nested (e.g., h1 followed by h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc.). In the "Other sources" on that page, we have a link to WebAIM: Semantic Structure: Regions, Headings, and Lists which has The <h1> describes the page as a whole (and should be similar to the page <title>). A page should typically have only one <h1>. Headings <h2> through <h6> represent increasing degrees of "indentation" in our conceptual "outline". As such, it does not make sense to skip heading levels, such as from <h2> to <h4>, going down the page. --Redrose64 🌹 (talk) 18:19, 12 February 2024 (UTC)
These pages aren't articles, though, so policy doesn't apply. Semantics are also enhanced as every h1 header actually signifies a different page (for each daily log). "being worked on" also has me very doubtful as to when it'd arrive due to, say, graphs and mw:Extension:DiscussionTools/Comparison. Note how much the WMF still has to do to catch up with a script from 2018 (before notifications!) and mostly developed by a single person. To be fair, it borrows many great ideas from WMF devs, but they still have yet to take the script's ideas and implement them. There has been no new feature additions under DiscussionTools reflected since November; all they've added since seems to be linking the timestamp to the "perma"links. Aaron Liu (talk) 02:46, 5 March 2024 (UTC)
Adding article title to sidebar table of contents
Usually, one starts articles from the top, and the title is the first and most prominent thing one sees. Occasionally, such as when following a section link, one starts somewhere in the middle, and then the title is not in view at all (within the page proper, I mean, it may be being shown elsewhere in the browser in various forms - tab caption, adress bar, et cetera). Jumping to the top to look at it means losing and then having to regain the place that was the very purpose of the section link. Which is not a problem, but which is an inconvenience.
If the title were part of the sidebar ToC, it would always be in view. Well, maybe not always, but at least as long as the top of the ToC remains in view, which is always for short ToCs and much of the time for longer ToCs. (ETA: Plus, the ToC is separately scrollable, so going to its top to look at the title does *not* mean losing one's place in the body text.)
The ToC currently starts with the literals "Contents" and "(Top)", neither of which conveys significant information. I daresay even first-time visitors to the site will mostly be able to figure out what the sidebar is showing wihout the former, and the latter is a pure placeholder. The title could replace either of them, in case people dislike the idea of adding another line to it.
When logged in, as I scroll down the page and the page name scrolls out of view, a fixed banner appears at the top of the page with the page name. Rather than adding the article title to the sidebar table of contents, I would suggest this behaviour be mimicked for non-logged in users. isaacl (talk) 16:21, 6 March 2024 (UTC)
Proposal: Establish a free ISBN Number Generator on Wikipedia
Dear Wikipedia Team,
I hope this email finds you well. As an avid supporter of Wikipedia’s mission to freely disseminate knowledge, I would like to propose an enhancement that could significantly benefit both content creators and readers worldwide.
Proposal: Establish an ISBN Number Generator on Wikipedia
Background:
Wikipedia has been a beacon of open knowledge, providing valuable information to millions of people globally.
Authors, researchers, and educators often contribute to Wikipedia, sharing their expertise and insights.
The publishing industry relies heavily on International Standard Book Numbers (ISBNs) to uniquely identify books and facilitate distribution.
The Idea:
Wikipedia could create a simple, user-friendly ISBN number generator tool directly on its website.
This tool would allow authors, especially those experiencing financial strain, to generate ISBNs for their self-published works.
By integrating this feature, Wikipedia would align with its core objectives of democratizing knowledge and supporting creators.
Benefits:
Accessibility: Many independent authors lack the resources to obtain ISBNs through traditional channels. A built-in generator would empower them to publish their works without financial barriers.
Global Impact: Wikipedia’s reach spans the globe. An ISBN generator would benefit creators from all corners of the world.
Quality Content: Encouraging self-published authors to use ISBNs would enhance the quality and credibility of content on Wikipedia.
Implementation:
User-Friendly Interface: Design a straightforward interface where authors can input book details and receive a valid ISBN.
Guidance: Provide clear instructions on how to use the generator and the importance of ISBNs.
Integration: Integrate the tool seamlessly into Wikipedia’s existing infrastructure.
Conclusion: I believe that implementing an ISBN Number Generator aligns perfectly with Wikipedia’s ethos. It would empower creators, promote quality content, and further the mission of free knowledge dissemination.
Thank you for considering this proposal. I look forward to hearing your thoughts on this matter.
The Wikimedia Foundation is not a publisher, and so cannot manage an allocation of ISBN numbers. Even if it chose to enter the publishing business and pay for a range of ISBN numbers, ISBN numbers are a limited resource, so making them available on demand to anyone would use them up quickly. isaacl (talk) 06:25, 5 March 2024 (UTC)
Wikipedia doesn't need to be a publisher in order to produce an ISBN number and to host a couple of book details (this is not big data storage).
And the idea is that Wikipedia CREATES the ISBN number NOT BUY numbers, that's whole the point - to demonitise what should be a very simple FREE book 'cataloging system'.
As the ISBN agency have epicly failed in their duty to provide a service freely available to all (free publication of ideas is a HUMAN RIGHT not a privilage for those who can afford it) - they have allowed corruption in.
Consider how many books are EXPLODING into existence with the advent of AI - millions of ISBNs will be required, each worth $80-$130 USD. Money that belongs in the pockets of writers, illistrators, not bloated corporate building running simple $2 cataloging software that a 5 year old could code. Disgusting.
Self published books are almost never reliable sources for use on Wikipedia, except in the rare cases when the author has previously been published by a reliable journal or by an established publishing house in the same topic area. An ISBN issued by Wikipedia/Wikimedia would inevitably be considered a "stamp of approval" in the marketplace and evidence of reliability when newer editors try to use such "books with Wikipedia issued ISBNs" as reliable sources, and we will be obligated to answer countless plaintive questions from editors reasonably asking "if the book is not reliable, then why the hell did Wikipedia issue an ISBN?" I would favor efforts by any non-Wikimedia nonprofit to lower the cost of obtaining ISBN numbers. But US $130 is the price for a moderate grocery buying trip in the US, and we are not talking about filling the cart with expensive cuts of beef. If a person wants to publish a book that will be taken seriously by reviewers and booksellers worldwide, then there are some basic expenses that must be paid by the author/self publisher. It is not the role of Wikipedia to right great wrongs in ISBN pricing. Cullen328 (talk) 07:24, 5 March 2024 (UTC)
"Self published books are almost never reliable sources for use on Wikipedia" - Cullen, this comment has nothing to do with my proposal.
"An ISBN issued by Wikipedia/Wikimedia would inevitably be considered a "stamp of approval". - If this proves a real concern, one may include a disclaimer. The proposal would clearly be stated as a 'catagloging service', not an editorial or publishing service.
"But US $130 is the price for a moderate grocery buying trip in the US" - I remind you that the US is not the centre of the world, it is a but a part of a much larger whole. In many, (many) countries, that figure is very substantial, but regardless, it should be free as a matter of principle. Cataloging creative works should be a public service, for the public good, not a profiteering oppurtunity that benefits a handful of greedy individuals.
"It is not the role of Wikipedia to right great wrongs in ISBN pricing" - it is everyone's duty to right wrongs. In this instance, Wikipedia is an excellent alternative; it supports free access to knowledge and information. "Evil deeds may only be carried out when the good stand silent" or whatever the quote is... Jared Travels Time (talk) 07:59, 5 March 2024 (UTC)
Jared Travels Time, if free ISBNs is your passion, then feel free to establish and fundraise for a nonprofit organization to make that happen. This is outside the scope of Wikipedia which is not a forum for advocacy of any kind, except for advocating for a free encyclopedia in as many languages as possible, the only exception to that general rule. Your quote would require us to advocate for every good cause, and we would rapidly devolve into arguing about which causes are good-better-best and which causes are bad-worse-worst. In brief, not gonna happen. Cullen328 (talk) 08:25, 5 March 2024 (UTC)
ISBN numbering is controlled by registering agencies in each country. It's similar to phone numbering plans: someone could make up their own phone numbers and give them out freely, but they'd only be usable if someone built a network to use them. If the Wikimedia Foundation were to invent their own publishing ID system, for it to be useful for those buying books, booksellers would have to change their computer systems to use the new IDs. isaacl (talk) 17:50, 5 March 2024 (UTC)
At meta:WikiCite and d:Wikidata:WikiCite the Wikimedia community mints metadata identifiers. They are not ISBNs, but they are what the Wikimedia community wants for itself. Joining that community and conversation is not easy as it lacks documentation and has most of the community knowledge only in the minds of the practicioners, but to the extent that there is a consensus and plan, this is where it is.
Also check out v:WikiJournal User Group which registers DOIs. Those are not ISBNs, but the nature of DOIs are changing a lot and Wikipedia has an established long term relationship with Crossref. If we did assign DOIs to book then the WikiJournal model would inform the planning.
The computing reference desk has a lot of questions not about computing. For example, there are a lot of questions about cell phones. I think there should be a reference desk about technology that isn't computing. Bubba73You talkin' to me?00:22, 5 March 2024 (UTC)
I've never used the reference desks, but are there enough computing questions to justify the existence of both this new board and the current one? Seems like a better idea to just widen the scope. ― novov(tc)04:43, 5 March 2024 (UTC)
I use and read the math and computing reference desks frequently, and sometimes science or others. I think that there is enough for both, but widening computing to technology would work. There are so many questions in computing that are help with phones and not about computing. Bubba73You talkin' to me?23:19, 6 March 2024 (UTC)
Why wasn't this brought up on the RefDesk talk page? Or mentioned there? The Computers and IT page says it is for "Computing, information technology, electronics, software, and hardware" which seems pretty broad already. And there's a miscellaneous desk for people confused about where a question should go. What exactly is the problem you seek to fix? Matt Deres (talk) 20:16, 8 March 2024 (UTC)
Allowing editors to opt out of private information on XTools.
Option 2 at the least, as proposer. The current state of affairs does not seem like a good thing. Isn't automatically revealing more private information on XTools unsavoury at the very least? Users should at the minimum have the right to restrict more private data such as the timecards from appearing in the XTools analysis. As SlimVirgin wrote during a 2014 discussion on the issue, Even though the information is in theory publicly available, presenting it in this format is still a privacy issue. (Just because we all walk down the street doesn't mean we'd want CCTV cameras joining up our activities and someone posting it online.)🌺 Cremastra (talk) 20:10, 19 February 2024 (UTC)
Option 1 I do not think users should have any expectation that information extractable from WP logs won't be compiled, and would argue that allowing them to is (mildly) against WP:5P3Mach61 (talk) 20:21, 19 February 2024 (UTC)
Option 2. Option 3.Option 2.5. As I understand it, the devs only allow opting out of three areas: timecard, monthly counts, and top edits by namespace. My !vote is to require users to affirmatively opt-in for timecard and monthly counts, but not top edits by namespace, which should not allow an opt-out. I agree with @Cremastra and @SlimVirgin. When you're editing on Wikipedia isn't private information per se, since anyone can take a look at someone's edit history. However, an easy-to-use tool that lets someone know when you're generally online and making edits can pose security risks (e.g., it can show when you're usually home and usually not at home; similarly, monthly counts can show what months you're generally on vacation or away from home). Regarding @Mach61's point that users should [not] have any expectation that information extractable from WP logs won't be compiled, the only tool that currently does that compiling is XTools, and I doubt someone would go through the headache of creating, hosting, and maintaining a new tool in the event that en-wiki users are allowed to opt out. This should be disabled by default because new editors won't know that it exists, and anyone who knows enough to know that XTools exists would know how to opt in if they choose. voorts (talk/contributions) 20:44, 19 February 2024 (UTC), changed !vote 20:49, 19 February 2024 (UTC) and again 21:08, 19 February 2024 (UTC)
I doubt someone would go through the headache of creating, hosting, and maintaining a new tool in the event that en-wiki users are allowed to opt out. It's quite simple to write a quarry query doing all of this - it wouldn't look as nice, but the information would be there. BilledMammal (talk) 21:44, 19 February 2024 (UTC)
There are many tools. In addition to Quarry, there's Apache's Superset, or the PAWS JupyterHub deployment (where you can work in your preferred language), or you can go thru an API e.g. Wikimedia REST API. Or if you prefer to work in your own environment using VSCode or whatever, you can talk to the databases remotely via ssh (you'll need a Wikimedia developer account and Toolforge membership). The database schema diagram is quite handy. Sean.hoyland (talk) 09:01, 7 March 2024 (UTC)
There already is at least one other tool that shows timecards and monthly counts (wikichecker), and I'm pretty sure that creating a new version of the xtools edit counter tool would be relatively trivial, since the source code is freely available. Firefangledfeathers (talk / contribs) 23:27, 19 February 2024 (UTC)
Fair enough. Xtools is fairly integrated into Wikipedia though, so I think removing that option creates an extra step for potentially malicious people to poke around. voorts (talk/contributions) 23:30, 19 February 2024 (UTC)
Option 1.5 - Mostly agree with Pppery and Mach61. Edits are public and transparent. If someone wants to gather our public edits and make a neat tool to show patterns in those edits, that's generally a good thing IMO. What's more, we have no real say, because we already agree to make edits on a public, transparent, free, and open wiki. It's 100% up to the developers what they want to do, and an RfC about opt-in/opt-out is really just a request. If the devs honor it, anyone else could just fork it and host the same thing elsewhere. For the most part, I don't think the devs should allow opt-out. Again, it's all public information and the tool is frequently useful. The only argument I find myself sympathetic with is the one about timecards per SlimVirgin/Cremastra. Although I just finished talking about how it's all public and up to the devs, to take it to an extreme, I think this community wouldn't take kindly to developers of a tool that, for example, processed the entire text of a user's contributions to produce a profile guessing at their real life identity. In short, if you run an RfC, be sure to separate the timecard from everything else or you'll get a bunch of people like me who sortakinda think the timecard should have an opt-out, but would oppose a blanket question. — Rhododendritestalk \\ 21:00, 19 February 2024 (UTC)
Along the SlimVirgin/Cremasta line of reasoning, let me toss out another way edit timestamps might leak personal information. Lets say I looked at all your timestamps and observed that near the end of every week, you abruptly stop editing at a specific time, and pick up again 24 hours later. I might guess that those are the times of sunset where you live and thus surmise that you're an observant Jew/Muslim/etc, who stops editing on the sabbath. Other editing gaps around major religious holidays might confirm my guess. A few minutes with an almanac could narrow your location down to a few cities where sunset happens at those times over the course of a year. That's quite a bit of information just from looking at your timestamps.
If I've figured out that you're an observant Jew who lives in New York, I've narrowed you down to maybe a million people. On the other hand, if I've figured out that you're an observant Jew who lives in the Falkland Islands, according to Jewish population by country, there's only one of you, so I've got you nailed. RoySmith(talk)22:33, 20 February 2024 (UTC)
Comment - The info page on xtools says Your wiki should have had a local discussion showing consensus for these statistics to be allowed. Did that discussion ever happen, and if so when? If not, then en wiki needs to go back to hiding that info until that discussion happens (which would be this topic if/when it becomes an RFC). RudolfRed (talk) 21:09, 19 February 2024 (UTC)
Option 1 Your edit history is always publicly available and visible to anyone and everyone, and pretending otherwise is at best ineffective and at worst misleading and harmful to the transparency that Wikipedia tries to support. Even allowing opt-out for timecards is potentially harmful, as it gives the false impression that users can hide PII such as the times they are active. Finally, it seems somewhat silly to have all this handwringing about XTools when completely unaffiliated sites such as http://en.wikichecker.com/ exist. --Ahecht (TALK PAGE) 21:11, 19 February 2024 (UTC)
Option 2.5 (My !vote is to require users to affirmatively opt-in for timecard and monthly counts, but not top edits by namespace, which should not allow an opt-out. -- voorts) What harm can one do with someone's edit count and top edits? I can see an argument against time cards and monthly edits. Someone could always try to create a tool to replicate these functions in order to act maliciously, but there's no reason for us to facilitate their aims by providing a tool to do this.Sincerely, Novo TapeMy Talk Page 21:17, 19 February 2024 (UTC)Option 1 per Novem Linguæ below. Sincerely, Novo TapeMy Talk Page18:12, 1 March 2024 (UTC)
Several purposes: they can help users in identifying sockpuppets, they can can help visualize when a user is likely to be active if you're waiting for feedback from them, and they can help make it obvious to editors that such an analysis is possible and that it is something they should be aware of if they are trying to keep their anonyminity. --Ahecht (TALK PAGE) 21:36, 19 February 2024 (UTC)
Option 1; scrutiny protects both the encyclopaedia and the user. Allowing some users to opt out would allow maleficent users to evade / delay proper scrutiny. If some editors' editing patterns are available, then all editors' editing patterns should be available. This data is not private like one's medical records or finances. Having said that, a warning to editors, say in the edit window, might not go amiss. The principle is simple; if you don't want your editing patterns available to all and sundry for scrutiny, then do not edit Wikipedia. Baffle☿gab21:30, 19 February 2024 (UTC)
Option 1; this won't improve privacy, all it will do is gate-keep it - more technically minded users will still be able to access it, while less technically minded users won't. I don't think that is a productive division. BilledMammal (talk) 21:33, 19 February 2024 (UTC)
The timecard should go. I see no reason for this data to be aggregated like this - what legitimate purpose does it serve? But the others, I see legitimate uses for them, and I don't see any good reason to allow opt-out. I think opt-out would possibly be harmful as mentioned by some responses above (ie, that it would make people think their edits are more private than they are). We've already given up that kind of privacy by editing here in the first place. -- asilvering (talk) 21:34, 19 February 2024 (UTC)
Comment Aside from all-important anonymity, Wikipedia is the most privacy-violating website that there is. It it a very easy convenient publicly searchable database of every edit that the editor ever made including the exact date and time that they made it. And there isn't a simple line between public and non public. Degree and ease of public access is important. Scratching your butt on your front lawn is technically public, as is your name and address, but if I take a telephoto video of you doing it and have it put on television and make a permanent searchable youtube video of it, I'm changing the degree of privacy and can't just say that I'm not because it's all public already. For example, if somebody outs you, anybody with no expertise can just click "edit count" can prepare a study on you in 30 seconds on how much editing you did when you were supposed to be at work and give it to your boss. I think that protecting anonymity is far more important than this proposed change, but I think that the proposed change is also a good idea. North8000 (talk) 21:44, 19 February 2024 (UTC)
Option 1. The privacy of editors is important, but we need to balance this against our goal of making an encyclopedia, which requires a degree of transparency in order to track sockpuppets and malicious editors; failing at that doesn't just hurt our mission, it has the potential to cause real-world harm even to people who haven't edited the encyclopedia, either because of BLP issues or because of harm caused when they try to rely on it. On the balance, these things are not a high privacy interest for most editors, while they are extremely valuable for identifying sockpuppets and COI editors. --Aquillion (talk) 22:02, 19 February 2024 (UTC)
No, those are not even remotely close. When you suspect that someone might be a sock of a previous user and are trying to build a case for SPI (or whether you even should attempt to do so), comparing the users' time cards is an extremely valuable way to get an initial at-a-glance sniff test. It doesn't prove anything on its own, ofc, but it allows you to avoid wasting time on editors that are clearly and obviously distinct. Editor interactions are far less valuable for this because it's natural for editors with overlapping interests to edit the same articles, and because it is easier for a sock trying to evade detection to move to another article than it is for them to change the entire times at which they edit over an extended period of time. And of course combining the two can provide enough information to tell you whether it's worth digging into their edits for more specific similarities. Losing access to time cards would make it far more difficult for editors who hunt sockpuppets to perform an initial pass to rule out possible sockmasters, while providing a "privacy" benefit that is purely symbolic at best. --Aquillion (talk) 13:09, 21 February 2024 (UTC)
Option 1. Status quo. The information proposed to be obfuscated doesn't seem particularly dangerous to me except maybe the timecard, and the timecard is an important tool for sock hunters. –Novem Linguae (talk) 22:53, 19 February 2024 (UTC)
Option 1. This is silly. It's all public information, and absolutely nothing is stopping me from forking xtools and/or developing a similar service and running it out of my personal website. -Fastily01:23, 20 February 2024 (UTC)
Option 1 I don't see the privacy concerns with monthly counts or edits by namespace, and these are very often used by e.g. people at PERM/RfA evaluating a someone's activity and where they spend their time editing. The timecard is more concerning, but is used to find socks, and so it is useful that way; but I wouldn't necessarily be opposed to the "option 2.5" suggested above. Galobtter (talk) 01:28, 20 February 2024 (UTC)
Option 4 don't allow opt-out, but only let CUs see it, for privacy reasons. Just because something can be done doesn't mean it should be. Levivich (talk) 04:24, 20 February 2024 (UTC)
Option 1. The data is public, will remain public even if you were to opt out and even if you did opt out on Xtools it could be compiled and displayed in the exact same way by some other tool. Pretending editors can opt out from this would therefore be misleading. Thryduulf (talk) 05:19, 20 February 2024 (UTC)
New option 5 Allow only users that are not on Special:ActiveUsers to opt-out.
I tried using the en.wikichecker.org tool to look up an user that has agreed to it, and got an html code 403, so the argument of it being possible to view this aggregated data elsewhere is still moot. Might be an EU issue. I have never used timecards as an admin on an smaller wikipedia for my entire time of serving as one, which is over an decade, so I reject the argument of timecards being useful for moderation. As for timecards being useful for communication, just use some patience, volunteers do not owe you to respond within the hour.--Snævar (talk) 10:51, 20 February 2024 (UTC)
WikiChecker does that sometimes. Usually refreshing the page gets it to load correctly without the 403 error. It's probably a CDN issue. --Ahecht (TALK PAGE) 14:38, 20 February 2024 (UTC)
Option 2. Allow users to opt out if they want - it should only be up to them and it's the kind of situation where giving the choice doesn't really hurt anyone. But because we are only speaking of publicly accessible info, GDPR isn't implicated so I don't particularly care either way. Szmenderowiecki (talk) 11:37, 20 February 2024 (UTC)
Option 1: basically per Pppery and Ahecht. The data is already publicly available for all and can be easily accessed by an external source (and one such platform is mentioned above). JavaHurricane12:46, 20 February 2024 (UTC)
Option 1 I reject the premise in the heading. The times editors make their contributions are public information and there's no reasonable expectation they ought to be private. As others have outlined, there are many legitimate reasons to audit a user's pattern of editing – detecting sockpuppets, evaluating RfA candidates, and working out when you can expect them to respond to a question. – Teratix₵14:46, 20 February 2024 (UTC)
Option 1. I disagree that hiding timecards gives a false sense of security. Making it less accessible does mean fewer people are likely to see it, and I hope that doing so would be widely-accepted as still being possible to view. That being said, I strongly disagree with the idea that publicly showing XTools data should be opt-in. I also disagree that there should be an opt-out. There may be an opportunity for the XTools maintainers to remove timecards publicly, and our checkusers given an internal tool for timecards. SWinxy (talk) 19:57, 20 February 2024 (UTC)
There's already another tool which provides timecard information: https://spi-tools.toolforge.org/spi/ (which I maintain). It's integrated into the SPI toolset, but there's nothing to stop people from running it as a stand-alone tool. XTools presents the data in a nice U/I, but the basic functionality is trivial to implement, so making XTools opt-in would be meaningless. RoySmith(talk)20:23, 20 February 2024 (UTC)
Option 1 The data is public and apparently easy to recreate. Now, I could get behind encouragement to only allow logged-in editors access x-tools, but that is a separate question. --Enos733 (talk) 20:43, 20 February 2024 (UTC)
Option 1 The data is public and anyone can aggregate it to show the same. To pretend otherwise is security through obscurity and just encourages people to have a fake sense of safety. —TheDJ (talk • contribs) 21:18, 20 February 2024 (UTC)
Option 2 though it wouldn't be my ideal formulation (which would be to have a public opt-in version and a no-opt-out version accessible only to particular rights-holders). I seem to recall opining in the opposite direction when the same question was raised several years ago but my view has changed due to a factor strangely absent from this discussion: volunteers' experiences of harassment. Even though the information is all public and can be collated with some technical knowledge, reducing the ease of access of information would limit or prevent certain types of harassment and violence against volunteers. It is worth noting that privacy of a volunteer can reduce rather than increase when they create an account, as many IP addresses are not highly sensitive to that individual but the pattern of their editing behaviour is. I'm reluctant to spell out more per WP:BEANS. — Bilorv (talk) 22:26, 22 February 2024 (UTC)
Option 1 - this is all publicly available information that could just be compiled by someone self-hosting the tool to ignore opt-outs. a false idea of privacy is arguably more harmful than the status quo. Rexo (talk | contributions) 15:44, 3 March 2024 (UTC)
How trivial would it actually be to self-host the tool, though? As it is everyone on the planet with a Web browser has all those analytics their fingertips.
Option 2 with opt-in for time cards The fact that there’s no opt out combined with the fact that this is not clearly and visibly disclosed to editors (hell, maybe there should be a disclaimer in the edit window itself with the licensing and all that blah blah) is a bit shocking to a reasonable observer coming from the context of internet anonymity expectations. The amount of data that sometimes be extrapolated from a time card is concerning.
Regarding monthly edit counts, I think it needs to be balanced against the value of that info in many cases.
Option 1 - because the other options have no actual impact on privacy. XTools does not include any private information because it does not have access to private information. It talks to the database replicas, sanitized versions of the production databases that have had private information redacted. There aren't degrees of privacy in the information it accesses and presents via the website and the API. All of the information is equally public. The choices available to people are largely captured by Wikipedia:Why create an account?. People can choose to expose or not expose their IP address, they can choose an account name that is or is not related to their real name, they can choose to reveal or not reveal personal information on their user page or in interactions with other users, and so on. Sean.hoyland (talk) 06:57, 9 March 2024 (UTC)
Option 1 The information is publicly available and the tool could be recreated by someone at any time if they wished. Matt Deres (talk) 21:14, 9 March 2024 (UTC)
.jpg)
Self-trout. InfiniteNexus (talk) 01:11, 21 January 2024 (UTC)
Moved from Wikipedia:Village pump (policy)
Done I presume LegoBot will do its thing and copy the new RfC text over. Ca talk to me! 16:56, 18 January 2024 (UTC)
22:42, 13 January 2024 (UTC)
04:48, 14 January 2024 (UTC)
