Wikipedia:Village pump (idea lab)
Idea lab
First discussion New post
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:
Before commenting, note:
  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.
Discussions are automatically archived after remaining inactive for two weeks.
« Archives, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36

Centralized discussion
Village pumps policy tech proposals idea lab WMFmisc
For a listing of ongoing discussions, see the dashboard.
view edit history watch archivetalk purge
Making Wikipedia More Welcoming To The Modern User
I may be wrong, but in 20 years, Wikipedia's design has not changed much. The design was great for the online innovations of 2001, but... not so great now. Websites nowadays have simple, user-friendly buttons, accounts systems that have cross-platform "read later" lists (or better yet, folders too), personalised feeds, etc. Wikipedia still has a fairly limited UI, while the rest of the internet has moved on. The app has some modern intergrations, but these don't sync with the website so it's still limited in scope.
Now obviously a "For You" feed would include countless data and privacy concerns but surely there could be some sort of opt in system for a user-data driven, modern UI? Like a personalised feed that simply recommends new articles based on ones you have read would do wonders for this. Is there any reason why this can't happen? Squid45 (talk) 17:38, 17 May 2021 (UTC)
In your user preferences, you can change your skin and even create your own. There is even a list of cool skins. 'Read later' lists can be bookmarked in-browser. And note that Wikipedia is an encyclopedia, not a social media website or dictionary. A personalized feed would defeat the purpose of Wikipedia. Sungodtemple (talk) 17:53, 17 May 2021 (UTC)
One of the attractions of Wikipedia is that it doesn't make silly suggestions of what we might like in the way that many other web sites do. It is a way of selling you more or telling you what you should think rather than anything that benefits the reader. If that's modern, then I'm proud to be old-fashioned. Phil Bridger (talk) 18:10, 17 May 2021 (UTC)
Can I also say that one of the positive attributes of Wikipedia is that, unlike many other websites, it does not ask us whether we want to accept cookies? Rollo August (talk) 20:12, 17 May 2021 (UTC)
I'm really not too keen on the idea of a "For You" feed, or user data driven navigation. For starters there's the privacy issues alluded to in the op. Tracking and storing user movement around the site so that an algorithm can guess what readers might be interested in would be a massive divergence from current policy where even stuff like checkuser data is only kept for 60 days for user privacy, and if it's an opt-in system you'll never get enough data to produce meaningful results (most of our readers do not have accounts, and I imagine only a fraction of registered users would be happy with the WMF tracking their reading). How do you propose to separate user data from reading from user data from editing? Any tracking of where our registered users go is going to be massively polluted with nonsensical page jumps from things like Auto wiki browser, new page patrol, anti-vandalism work, sorting through cleanup categories, etc. Fundamentally though the idea of driving user navigation by page views should be unnecessary - navigation should be built into articles. If a paragraph mentions something that a reader might be interested in it should be a wikilink, if there's a series of articles on a topic that make sense to read together they should be presented together in a navbox, if there are articles that are a natural follow on from the article a reader has just read they should be listed in the "see also" section, and all articles should be sorted into appropriate categories to make it easy for editors to find related content. We also have a huge number of volunteers working on maintaining the front page as a showcase of high quality content from around the site, which has enough variety to serve\ well as a list of recommendations for things readers might be interested in reading. (talk) 22:41, 17 May 2021 (UTC)
The term "modern" makes sense from a descriptive perspective – for instance, solely to distinguish newer periods and ways from older ones.
It becomes a problem when it carries the presumption that older ways are "old-fashioned"; that is, presumed to be worse. In technological fields where businesses make the choices and impose them on users, the reverse is often true.
— Richard Stallman
When the "modern user" gets used to something which is 'convenient' but not actually in their interests and asks us to implement it too, our best option is to politely say "We won't give you that, but we're not refusing out of malice; here are the reasons why this change is actually not in your interest". It's a good opportunity to try to teach people to respect themselves, actually. DesertPipeline (talk) 05:53, 18 May 2021 (UTC)
I do like the reading lists feature in the iOS app, and wish that was available in the browser version. ⁓ Pelagicmessages ) – (14:07 Sun 30, AEST) 04:07, 30 May 2021 (UTC)
Minerva and Timeless skins have a "related articles" widget which works in mysterious ways, but I don’t see it "driving user engagement" the way YouTube's suggestions do. When I'm reading articles, I tend to use navboxes and the See also section, though sometimes Related Articles does surface something pertinent. ⁓ Pelagicmessages ) – (14:07 Sun 30, AEST) 04:07, 30 May 2021 (UTC)
@Pelagic, the "Related articles" feature is available on the desktop site (just not here, because editors didn't want it). It's just the top three search results, preloaded for convenience. Put morelike:Article_title into the regular search box, and you'll get the same effect. Click here to see the results for morelike:fish.
(You can manually control the search results if the results are poor. This sometimes happens with very short articles (e.g., "Joe Film is an actor known for once voicing a My Little Pony character", which can rate pretty high in searches related to the only thing linked in that substub). Whatamidoing (WMF) (talk) 02:55, 3 June 2021 (UTC)
Citation needed tagging in VisualEditor
Moved from Village pump (proposals)
 – Tol | Talk | Contribs 05:10, 25 May 2021 (UTC)
I think the ability to be able to select and place "citation needed" through the cite feature in the visual editor with a single click would be helpful. Not needed but it would save time. TigerScientist Chat > contribs 21:05, 18 May 2021 (UTC)
Copy the following text and paste it in any article: {{cn}} This will simply work with the visual editor in the way you're requesting. ~ ToBeFree (talk) 21:09, 18 May 2021 (UTC)
ehh I guess maybe. TigerScientist Chat > contribs 15:10, 19 May 2021 (UTC)
You may want to post this on Phabricator if you really want this, however I think that just using the template is easy enough personally. EpicPupper (talk) 19:00, 19 May 2021 (UTC)
@TigerScientist: If you'd like, I can see if I can put together a user script which could add another button to to this. Tol | Talk | Contribs 05:28, 25 May 2021 (UTC)
Tol not needed but if it doesn’t take much time or effort go ahead. Thank you for even suggesting this. TigerScientist Chat > contribs 05:30, 25 May 2021 (UTC)
@TigerScientist: No problem. I haven't worked with VE before, so I don't know how long it'll take, but I'll try to get something to you within about two weeks. Tol | Talk | Contribs 18:24, 26 May 2021 (UTC)
Done: The script's documentation is at User:Tol/VECN, including installation instructions. Let me know if you have any questions! Adding stuff to VE is remarkably simple. Tol | Talk | Contribs 20:36, 26 May 2021 (UTC)
WOAH thank you Tol! TigerScientistChat > contribs 16:01, 27 May 2021 (UTC)
@TigerScientist: You're welcome! Tol | Talk | Contribs 20:19, 27 May 2021 (UTC)
@Tol, you are the only person I have ever heard say that adding a script to VisualEditor is easy. Would you please put mw:VisualEditor/Gadgets​, mw:VisualEditor/Gadgets/Creating a custom command, and mw:VisualEditor/Gadgets/Add a tool on your watchlist? They're very low traffic pages, and Flow/Structured Discussions will ping you in Echo/Notifications if anyone ever posts anything to their talk pages. Also, you might be interested in mw:New Developers. Whatamidoing (WMF) (talk) 03:07, 3 June 2021 (UTC)
@Whatamidoing (WMF): Wow; alright! I still don't fully understand VisualEditor, but I'm more than happy to watchlist those pages. Thank you for the resource! Tol | talk | contribs 05:48, 3 June 2021 (UTC)
Sometimes AIV is too slow.
I’ve reported a lot of vandals to administrator intervention against vandalism, and while I think AIV is great for most cases, I think that it can be too slow in some serious cases. Last night was one of those— there was a group of trolls attacking Waiuku; I took them on with the help of two others, but the edits kept coming. LizardJr8 reported them, but I knew it would be a while before an admin came to help. The vandals were destroying the page quicker than we could fix it. Then I decided to cut the AIV line and go straight to Liz. She speedily dealt with it. What I think we should do is create a new template. It will serve as a kind of Bat-Signal to quickly get an admin’s attention for cases of vandalism that need to be dealt with immediately, not to be dealt with at the whim of anyone that’s just passing by. Of course, I recognise there would be an issue with new users thinking that their cases of vandalism trump all other cases in importance, and admins would be flooded with requests. I’m not sure if this is possible, but perhaps we can make it so that only more experienced editors have access to the template (maybe as a part of Twinkle?). That way, they have enough experience under their belt to know what cases are high priority and what cases aren’t. It would work like this— once a user finds an admin, they go the the admin’s talk page, open the Twinkle menu, and select the template. Maybe there’s one or two boxes they should fill out, such as the name/IP address of the vandal or amount of disruptive edits they made. In summary, this feature would help users in an active vandalism crisis quickly get hold of an admin. A Twinkle template would allow them to quickly get the information conveyed instead of creating a lengthy plea for help (like what I do, LOL). I would love to hear your thoughts on the matter. 🐍Helen🐍 20:27, 28 May 2021 (UTC)
HelenDegenerate, See Wikipedia:Requests for comment/Responder role for a proposal (which doesn't appear to be making any progress) from ProcrastinatingReader for one way to deal with this. -- RoySmith (talk) 21:46, 28 May 2021 (UTC)
I think we had a few more things to figure out, but to some degree I don't think it would pass if it went live now. It's probably better to try it if/when a greater portion of the community feels there is a problem here. ProcrastinatingReader (talk) 21:57, 28 May 2021 (UTC)
Oh yeah, this problem. I think we should have a chat room (IRC, Matrix, Discord, whatever) where some admins hang out, and there could be a command that'll ping one of them, rotating among the admins in the room. There should be either a Twinkle button or a separate user script that'll send the command with a link to a specific AIV case. We can figure out access control later. I've been meaning to slap together a prototype for a while now - we don't even need to ping anyone for starts, just post a message - and thanks for the reminder. Enterprisey (talk!) 03:22, 29 May 2021 (UTC)
Did you know that... believe it or not, we need more administrators? The solution is actually things like: a) making RfA more active. b) making RfA less toxic. c) making RfA more encouraging. If we could do that, then this thread never would have started. 🐔 Chicdat  Bawk to me! 12:16, 29 May 2021 (UTC)
What is the difference between (b) and (c), between making RFA less toxic and making RFA more encouraging? Robert McClenon (talk) 22:53, 30 May 2021 (UTC)
From what I have heard, d) be more circumspect before reporting things to AIV might also help. Anecdotally, there are a lot of questionable reports. Jo-Jo Eumerus (talk) 13:06, 29 May 2021 (UTC)
What about having the bot move to the top reports where the user has fresh reverted edits after the report tinestamp? –xenotalk 13:15, 29 May 2021 (UTC)
Xeno, that sounds intriguing S Philbrick(Talk) 19:17, 29 May 2021 (UTC)
@Xeno:, I like that idea. I wonder— would we create a new bot to do the job, or would a preexisting one be in charge of moving the reports? If we used a preexisting one, maybe we can make ClueBot NG do it— it is an anti-vandal bot, after all. And one other thing: to draw extra attention to serious vandalism crises, perhaps the bot puts some kind of brightly-coloured symbol by it to show it is a high-priority case. What do you think? 🐍Helen🐍 23:56, 29 May 2021 (UTC)
HelenDegenerate: it would probably just be a new feature request for the AIV helperbot, but the first step would be confirming with AIV regulars to ensure it's a desirable change. –xenotalk 00:27, 30 May 2021 (UTC)
This is interesting. The bot would need to be running every minute or two to be useful, but I'd have no objections. I can't see any way to avoid a large proportion of the vandalism reports wanting to use the special template. IRC obviously has requests for this. Discord has informally - you can just ask if someone is free to help, but we are not a semi-formal adjunct like the IRC and we like to keep stuff on-wiki where it belongs Nosebagbear (talk) 13:30, 30 May 2021 (UTC)
@Nosebagbear:, I think I have the solution to that: simply restrict the use of the feature to extended confirmed users. Or if we’re talking about Xeno’s idea, there won’t be a problem with that, as only one entity would be able to use it— AIV Bot. 🐍Helen🐍 22:08, 30 May 2021 (UTC)
While I like the idea of sorting the reports, I am a bit afraid of edit conflicts. Constant bot edits will make it difficult to annotate reports. —Kusma (talk) 22:44, 30 May 2021 (UTC)
@HelenDegenerate: the vast majority of AIV notices are already done by EC-editors. It's not that I think they'll spam it to be annoying, I just think that anywhere up to a third of AIV reports (given that by the time someone does that it's already the 3rd (or more) issue) are going to make individuals "this is a bad, rapid case, I should use this" or "they've vandalised after being reported to AIV, we should use it now". Limiting it in that way will not avoid the issue. Nosebagbear (talk) 22:12, 30 May 2021 (UTC)
@Nosebagbear: True. I myself am staring to lean towards Xeno’s idea, because it’s up to the bot when to move certain cases to the top. Perhaps we can program it like this: if a particular vandal edits x or more times after the report, or has made over x amount of disruptive edits in the past 24 hours, then the program moves to the top and tags it as priority. 🐍Helen🐍 22:17, 30 May 2021 (UTC)
Yeah, a separate sub-section that things that had been bumped to the top a certain number of times would be good. However, this (and, to be fair, any solution) is still contingent on someone being around to process it. Dire emergencies are occasionally dropped on AN/ANI, but I suspect most admins are like me and are mildly unhappy if the request is not a standout issue, lest it become the norm. Could also add a bot task to drop a notification onto ANI if something had been in the "uber-crit" box for, say, 3 hours? Nosebagbear (talk) 22:25, 30 May 2021 (UTC)
@Nosebagbear: That could be fixed by having the AIV bot figure out which admins have made edits in the past minute (so they'll probably still be online), then leaving an automated urgent help message on their talk page. Same criteria still apply-- vandal must have edited x or more times after the report, or has made over x amount reverted edits in the past 24 hours. If the admin doesn't respond to the request within, say, 10 minutes, the notice is removed from their talk page and AIV bot chooses the next admin that makes an edit. I know this sounds complicated, but it might be able to solve both problems that you've brought up. 🐍Helen🐍 17:56, 31 May 2021 (UTC)
So, you'd need this to be opt-in by admins, and I'm not sure how many you'd get given the problematic bit is 0200-0800 UTC. I also suspect that this system wouldn't be able to remove the notifications, and the wiki equivalent of deleted Discord pings are really annoying, because I have to go investigate the history every time to figure out what it was. Nosebagbear (talk) 18:21, 31 May 2021 (UTC)
A concept for a possible notification. Anarchyte (talk)
I really like this idea in theory, but I would hate having a dozen messages posted on my talk page each day. What would be perfect is if we added a way to push a notification (example on the right) when various pages (AIV, RFPP, etc) reach n outstanding reports. It would of course be opt-in and would only ping people that have made an edit in the last 30 or so minutes. Anarchyte (talk) 16:03, 7 June 2021 (UTC)
@Anarchyte: Without any software changes, there could be a mass ping template like Template:@MILHIST containing a bot-maintained list of currently active admins that have opted in to "attention to AIV" pings? —Kusma (talk) 16:10, 7 June 2021 (UTC)
@Kusma: Interesting. I'd hope that only a bot could ping the list though, or we'll get some very cranky admins. Anarchyte (talk) 16:14, 7 June 2021 (UTC)
@Enterprisey The #cvn-wp-en and #wikipedia-en-help channels already exist on IRC --Ahecht (
) 16:35, 7 June 2021 (UTC)
Article talk pages
Most article talk pages are ghost towns, filled only with assessment templates. A lot of article related discussion happens on user talk pages, wikiproject talk pages or in edit summaries instead of on the article talk page. In the rare case where people come and try to discuss actual article content on article talk pages, they tend to get ignored for years, as nobody notices their contribution to the talk page. Should we encourage people to try to find out who the actual page authors are and ping them when they try to write a new talk page post? The suggestion to do so would need to be in {{talk header}} and/or the editnotice to have any chance of being seen. Or should we try to encourage people to go to a more widely watched forum when they want to say something about an article? —Kusma (talk) 10:12, 29 May 2021 (UTC)
@Kusma: If the users never go to the talk page, then how, if I may ask, would a notice on the talk page help? 🐔 Chicdat  Bawk to me! 10:42, 29 May 2021 (UTC)
@Chicdat: I am trying to solve the problem that people who have managed to use the talk page are being ignored. The alternative is to change the talk page header to discourage people who have found it from using the talk page. —Kusma (talk) 11:12, 29 May 2021 (UTC)
@Kusma: Can you give me a few talk page examples with years-old, unnoticed posts? 🐔 Chicdat  Bawk to me! 11:15, 29 May 2021 (UTC)
@Chicdat: From my own contributions: Talk:Leningrad Cowboys Go America, Talk:Ursula von der Leyen (although this is an article with 1.2 million views per year, none of the talk page posts get actual discussions). Additionally, I have noticed that I don't go to article talk pages to discuss the article. I think I should have posted this at Talk:Lynching of John Carter, with a ping to Drmies and Uncle G. I posted at a user talk instead because I'm used to ignoring article talk pages. I think that is a bad habit, but it is a common habit. I am trying to propose we all use article talk pages more, and use pings to make sure the right people get notified of the discussion. —Kusma (talk) 12:05, 29 May 2021 (UTC)
@Kusma: Wow... you're right! I never noticed any of this before. The Talk: namespace really is quite inactive. Thank you for noticing this problem. 🐔 Chicdat  Bawk to me! 12:08, 29 May 2021 (UTC)
Ok, so TLDR: Article talk pages are dead. Should we bury them or revive them, and if we want to revive them, should we try to use pings to do so? —Kusma (talk) 13:07, 29 May 2021 (UTC)
First, yes - I agree it's a problem. Often if something I wrote sits more than a day or two then I'll check history and go to one of the recent editors to discuss. I like the idea of notifying the original author, but I'd include the editor with the most edits as well. Also, should it be a "ping" on user talk, or just an email that someone has posted to the article talk and it hasn't been responded to in x hours, or x days? — Ched (talk) 13:25, 29 May 2021 (UTC) edited: revived implied by my response. — Ched (talk) 13:27, 29 May 2021 (UTC)
To expand a bit on the why notify the most prolific editor as well: There are a TON of articles where the original author simply isn't editing wiki anymore. Even the most prolific editor of that article may be long gone. At that point, I guess you just look at page history and try to find someone still active. (which doesn't really solve the problem, I know.) — Ched (talk) 13:33, 29 May 2021 (UTC)
The question is whether we can/should have some automation for the task of "find the people most likely to be interested in a talk page query". Could be something like "from the article statistics, check who has been active in the last month, and then take the top two of those". Once I have to personally look through the history page, it is easier to just post on a user talk page. —Kusma (talk) 14:01, 29 May 2021 (UTC)
Ummm .. ok? "Yes"? - I'm agreeing with you Kusma. The "can we" - I don't know. Sorry, I'm not familiar with the actual coding of such things. The "should we" - yes, I think so. I wasn't trying to restate anything, I was just agreeing with you. Apologies for the confusion if I wasn't able to express myself more clearly. — Ched (talk) 14:33, 29 May 2021 (UTC)
Oh, I also thought I was agreeing with you, and just tried to clarify who should be notified. :) —Kusma (talk) 14:40, 29 May 2021 (UTC)
Watchlist folders
Tracked in Phabricator
Task T3492
I've been wanting to bring this back up for some time but never got around to doing it until now. The watchlist is a very useful tool designed to help us users keep track of recent changes, but I find the current A-Z listing system a bit tedious. As I write this, I have 188 articles on my watchlist. I don't think that's such a huge number compared to other experienced users, but it's big to me, and I often find myself going through my list and asking myself, "Why is this article still here? It hasn't been vandalized for months. I don't need to keep an eye on it anymore." The problem is with a long list, I often miss a page or quickly get tired of checking it. With watchlist folders, users such as myself would be able to have an easier time locating articles.
I've searched through the archives and found three discussions about topics like this (1, 2, 3), but none of them really lifted off the runway. I want to keep my watchlist private (so no subpages), and bookmarking watchlisted pages seems redundant. The latest entry is from 2013, so maybe we've come far enough to make this possible. Perhaps watchlist folders could be part of our Preferences as a Beta feature. I'm not a very technical user, so I'm not sure if this is possible, but I'd like some feedback on the idea of watchlist folders. It'd certainly make my Wikilife easier if this is utilized, and the only reason I'm not watching more articles than I am now is because they'll just get lost in the long, long list. Regards. ResPM (T🔈 🎵C) 01:32, 2 June 2021 (UTC)
@​ResolutionsPerMinute​: it sounds like you want to have more than one watchlist for different things (in this case organized in to "folders" of some sort) correct? If so, this is phab:T3492 (now celebrating its 15th year of not being implemented!). — xaosflux Talk 01:49, 2 June 2021 (UTC)
@Xaosflux: This does look like what I'm talking about, but 15 years in the works without being implemented? Am I hearing that right? ResPM (T🔈 🎵C) 02:05, 2 June 2021 (UTC)
@​ResolutionsPerMinute​: yup - seems there are a couple of problems: (a) no one can decide on what exactly it should be, (b) no volunteer wants to take over actually managing it, including the software developement, to completion. — xaosflux Talk 02:10, 2 June 2021 (UTC)
@Xaosflux: Drat. Well, I'll take solace in the fact that its foundations exist. I wish I could help, but I'm a citer, not a developer. I would if I could. Thanks for filling me in. ResPM (T🔈 🎵C) 02:16, 2 June 2021 (UTC)
User:MusikAnimal/customWatchlists exists, but with watchlists being publicly visible. It's also possible to implement private watchlists in JavaScript (thus bypassing phab hurdles) by using mw.user.options, though no one seems to have done this yet. You could file a request at WP:US/R. – SD0001 (talk) 08:21, 4 June 2021 (UTC)
ResolutionsPerMinute​, I'm desperately trying not to comment on how big your watchlist is (mine is 12,929) and I won't comment on the folder proposal but I want to make sure you are aware that there is a timed option now available. Click on the star, note the dropdown box and pick an option other than permanent. I work on a lot of copyright situations and I want the related article on my watchlist for a little while case they don't know to contact me but I don't want it on forever, so I used one of the temporary options. Believe it or not that's helped keep my watchlist from getting completely out of control. That option sounds like it might apply when you decide to watch an article that has had some vandalism. S Philbrick(Talk) 01:08, 11 June 2021 (UTC)
@Sphilbrick: I've known about the timed options since they were first implemented, and I've decided to utilize this option as a substitute for now. I'm not my ideal solution, but it works. ResPM (T🔈 🎵C) 01:17, 11 June 2021 (UTC)
Radical reform of DYK
I start from the premise that, from a reader-perspective, WP:DYK is fundamentally broken, in that very many of the entries on it are just plain boring. I'm thinking about starting a proposal to have us conduct a trial in which we eliminate all the eligibility requirements and instead allow facts from any page to be nominated but require !voting on all proposals such that only the ones judged most interesting get selected.
I anticipate that this would draw quite a bit of opposition just by virtue of being such a radical departure from the status quo. Per the idea lab's instructions, I'm not looking for supports/opposes here, but I would like to get a bit of a sense of just how likely this would be to get snowed and if there's any way I could set it up that might reduce the chances of that or more generally any big considerations I should have in mind. Cheers, {{u|Sdkb}}talk 07:24, 4 June 2021 (UTC)
The real question is what the goal of DYK is and should be. Is it supposed to be fun and exciting to read? Then why limit to new articles, the vast majority of which is about obscure topics? From a reader's short term perspective, why should it be on the Main Page at all?
What I like about DYK is that it encourages new articles to be of a decent standard. Which is useful for readers, and more so than reading the articles while they are on the Main Page.
Anyway, back to your idea: I don't really see voting as a viable way out unless there is massive participation. And DYK is already quite process heavy, so perhaps we would need to reduce complexity elsewhere. —Kusma (talk) 07:59, 4 June 2021 (UTC)
For me the purpose has always been to casually highlight some of our more obscure articles of non-FA quality for readers and editors alike by making use of a specific style form (DYK) which might spike their interest. I never understood why we limited it to new articles. —TheDJ (talkcontribs) 10:01, 4 June 2021 (UTC)
We don't quite limit to new articles: 5x expansions (so stub->real article) and freshly promoted Good Articles are also eligible. —Kusma (talk) 15:38, 4 June 2021 (UTC)
DYK in its current form definitely fills a role as an editor incentive. It's a little hard to balance that against readers losing out on more interesting hooks. Part of what appeals to me about a trial is that it'd allow us to be more clear-eyed about what the tradeoff is. If we see hooks getting significantly more pageviews, we'll know that's a possibility; same with the converse. {{u|Sdkb}}talk 15:39, 4 June 2021 (UTC)
I think we should consider clearly what we want. Should all hooks appeal to everyone? [I think that rules out too many subject areas.] Or is it OK that there are some articles about topics of limited appeal (Latvian mariachi band conventions, extinct amoebae, Peruvian radio stations) in the mix? We have some diversity criteria for prep builders that make sure we don't have eight buildings in New York or eight Catholic hymns or eight politicians on at the same time. If that isn't enough to find two or three interesting ones every day, maybe we need to recruit more nominators with more mainstream interests. —Kusma (talk) 15:51, 4 June 2021 (UTC)
I'm not sure I buy that there's that strong of an inverse relationship between obscurity and interestingness. Much of the appeal of Wikipedia as a place for entertainment comes precisely from the fact that it contains so much on obscure topics, and several of the top DYKs of all time are on quite obscure topics. {{u|Sdkb}}talk 16:40, 4 June 2021 (UTC)
I agree that many entries are boring. My reaction to most of the hooks is "so what?" The satisfaction of editors should be in creating something that is exciting for readers, rather than in the mere fact of "their" creation being on the main page. Many subjects are simply boring, so however well-written the articles they shouldn't qualify for this section. Phil Bridger (talk) 08:27, 4 June 2021 (UTC)
If I can tell from the hook that an article is about a boring topic like baseball or cricket, I just ignore it, no matter how interesting the hook sounds. But a lot of people will care and actually enjoy the very same article. I guess we need some variety. —Kusma (talk) 09:07, 4 June 2021 (UTC)
Kusma, almost all of my hooks have been about historic buildings in Scotland. A niche interest perhaps, but they mostly garner 5-10,000 views - I like to think that some of the readers must have found a few of them interesting... GirthSummit (blether) 16:06, 4 June 2021 (UTC)
The point is not whether the general topic interests a particular person, but whether the hook is interesting. For example yesterday's hooks included "... that concert pianist, composer, and opera librettist Leonard Liebling was the editor-in-chief of the Musical Courier from 1911 to 1945?" and "... that the principal of Big Tree Elementary read a book from a hot-air balloon to honor her students for having collectively read more than 2.5 million minutes in 2006?". Isn't it obvious which would be the more interesting hook to over 99% of our readership? That is true for me even though I happen to be more interested in reading about Leonard Liebling than Big Tree Elementary. Surely someone had to be editor of a published journal, so that hook is very definitely a "so what?". Phil Bridger (talk) 18:40, 4 June 2021 (UTC)
Yep, this. The fact that hooks like the Liebling one aren't being insta-rejected illustrates just how low our standards are. No other fun fact list on the internet would look themselves in the mirror after publishing that. And readers can seek out any other list they want. We can't compete when we're tying our hands behind our back by limiting our scope to new content, which is why I think we need to consider removing the eligibility requirements, even if it totally upends the way DYK has traditionally worked. {{u|Sdkb}}talk 19:20, 4 June 2021 (UTC)
There's two things I'd like to say here: (a) DYK currently has more submissions than people are happy about (many would prefer DYK to update only once in 24 hours, not once in 12) so widening eligibility may not be necessary and (b) why should we compete with fun fact lists elsewhere? What's in it for us if we try to do that? —Kusma (talk) 19:36, 4 June 2021 (UTC)
Well, as Wikipedians I think we want people to read Wikipedia, which includes our Main Page. And if so, that means we have to compete for their attention, which means competing against other places they might go instead to find trivia facts. In the sense I mean it, it's not really a choice, it's something we're already doing and have to do if we continue having DYK. {{u|Sdkb}}talk 21:27, 4 June 2021 (UTC)
It comes down to what are the primary goals people feel should be met by Did you know? Going by what others have said, learning trivia might not have consensus support. On a related note, I once engaged in discussion about having featured content on the main page with an editor who couldn't understand why I was raising goals from a reader's perspective. To them, the primary objective was to act as an editor incentive. I agree though that in addition to thinking about editor goals, we ought to consider the value to readers for items on the main page. isaacl (talk) 22:05, 4 June 2021 (UTC)
This. Infinity times THIS. A hook that combines "Music dude does music stuff" and "published journal has editor" is boring. If the editor of the music journal was an auto mechanic or if this noted musician edited a science fiction magazine, that would be interesting. --Khajidha (talk) 12:39, 7 June 2021 (UTC)
"The internet encyclopedia distinguishes itself from other web resources because it strives only to include information from reliable journalistic sources. That’s the value of the project: sticking to its own boring processes even if it means the encyclopedia version is less dramatic than the tabloids." - Stephen Harrison, Slate Gråbergs Gråa Sång (talk) 09:53, 4 June 2021 (UTC)
I take a similar view to Kusma above - what I like about DYK in its current form is that it celebrates content-creation. It encourages editors to write new articles up to a decent standard, and it gets others to come along and review, copy edit, tweak those articles. Newer editors can learn a lot by watching the changes experienced reviewers make in the short time their creation is in the preps and queues. I think that kind of encouragement can only be a good thing, both for editors, and for readers who benefit from the new, decent-quality articles. Whether the DYK hooks themselves are of much benefit to the reader is a slightly different question, but the difference between boring and fascinating is very subjective. I've clicked on a few DYKs and thought 'so what?', but they probably made other people think 'wow, really?' or 'cool - I didn't know that'. Tens of thousands of people click on our hooks every day - are those numbers declining, indicating that regular readers are losing interest in them because they find they're usually boring? I'm also slightly worried that by raising the bar on how interesting/surprising a hook has to be, we might be encouraging sensationalist writing, which we don't want. (Also: Change? Argh, I fear change!)GirthSummit (blether) 10:21, 4 June 2021 (UTC)
That's a very good point about encouraging sensationalist writing. {{u|Sdkb}}talk 15:40, 4 June 2021 (UTC)
The function, as per WP:DYK, is to showcase new or expanded articles. It is, as Jayron put it, supposed to highlight the fact that Wikipedia is being constantly updated and expanded by directing readers to the newest such expansions. It is also, practically speaking, a motivator for contributors. When I work with a newbie on a new article, the DYK process is always intimidating but when it finally gets to be the main page that feeling of "look at what I did!" is extremely powerful. For people who contribute because they want to have an impact on the world by contributing to a free knowledge resource, the spike in readership reassures them that yes, people are indeed reading what you're writing. It's a big deal to be on the main page.
...But, I think Sdkb has a good point that by framing it simply as "Did You Know," we're priming readers to expect a list of weird, wild, interesting, and exciting facts from across Wikipedia. Maybe adding a line contextualizing the section would help, but it seems at least worth talking about other options.
What I think is not going to work well is to try to write rules which seek to accomplish the goals of DYK but attempt to qualify what is/isn't interesting. We risk marginalizing whole topic areas, and invite endless culturally relative debates over what is/isn't "interesting enough."
In the end, I think a main page section dedicated to new/newly expanded content is important, but there are possibilities to clarify/contextualize or even, I don't know, splitting that main page real estate into two sections or something. —
Rhododendrites talk
\\ 22:05, 4 June 2021 (UTC)
The last slot in DYK should always be "...that the above facts were taken from Wikipedia's recently created or expanded articles?", with "recently created or expanded articles" linking to the description of how to nominate an article for DYK. --Khajidha (talk) 12:36, 7 June 2021 (UTC)
@Firefly: Clarifying the scope of the DYK section is great. The downside is that a tagline (or Khajidha's idea of a final DYK) will take Main Space screen estate, which isn't as infinite as it may look. Going from 8 to 7 DYKs might be part of such a change. I guess it's worth it, but others might disagree. —Kusma (talk) 12:46, 7 June 2021 (UTC)
The only problem with "Main Space screen estate" is that we have chosen to give this one page a two-column layout unlike any other page on the site. This forces us to add and subtract items from various sections to maintain "balance". Which everyone complains about, but it seems that most of them find the obvious answer of "make the **** thing a single column and the problem goes away" even more objectionable. --Khajidha (talk) 13:07, 7 June 2021 (UTC)
@Kusma: I've had a go at including the explanation without affecting anything else. It's a crude first-approximation, so please only take it as proof that it's possible and nothing more! :) firefly ( t · c ) 13:15, 7 June 2021 (UTC)
Thanks @Firefly! The small font size might not fly for accessibility reasons, but perhaps we can merge this with some of the links. Here's a variation that integrates the links into what @Khajidha said:
... that these facts are from recently created or expanded articles, and that you can start or nominate your own?
Or something like that? —Kusma (talk) 13:36, 7 June 2021 (UTC)
@Kusma: That's far better than my attempt from an accessibility standpoint, although we may get pushback on the grounds that it breaks consistency with other sections of the Main Page. I've added your idea into my sandbox so we can all see what it could look like in practice. firefly ( t · c ) 13:44, 7 June 2021 (UTC)
Might still need some fine tuning (tried an alternative, not yet convinced), but it should be possible to get this to work. —Kusma (talk) 16:31, 7 June 2021 (UTC)
FWIW Kusma, feel free to use the sandbox I linked to experiment if you wish. firefly ( t · c ) 12:19, 8 June 2021 (UTC)
Oppose It's the premise that is broken. DYK is not boring; it's one of the most interesting sections on the main page. Consider the alternatives:
  1. FA – this usually goes on at length about a niche topic such as Interstate 69 in Michigan – today's conversation stopper. DYK is better because it is more varied, briefer and more focussed on being hooky.
  2. ITN – this is usually quite stale with up to a week or more between new blurbs, whereas DYK is much more productive, running 8–16 new items every day. And the ITN blurbs focus on a narrow slice of what's actually in the news and seem utterly obsessed by death
  3. OTD – a tired format with the same stuff recycling year after year
  4. FL – the poor man's FA
  5. FP – the pictures are often quite good but the attached blurbs are usually dire
And then there's all the main page boilerplate – dozens of links and slogans which may be useful but are hardly exciting
But, in any case, Wikipedia is an encyclopedia not a comedy, drama or thriller and so our readership will be expecting the content to have a comparatively educational tone – "worthy but dull". If you find it boring then you've come to the wrong place.
Andrew🐉(talk) 16:13, 7 June 2021 (UTC)
@Andrew Davidson, per both my initial post and the idea lab rules, please do not !vote here. Regarding your comment, the other sections of the main page each have their own issues, most of which have been discussed at length in other places. They are beyond the scope of this discussion, though; let's try to stay somewhat focused. {{u|Sdkb}}talk 18:09, 7 June 2021 (UTC)
So, the OP doesn't want !votes on their proposal to introduce !votes to DYK. WP:SAUCE!
And the other main sections are relevant because they demonstrate what happens when you have a peanut gallery of !voters. ITN is quite broken because it works in that way and so most nominations get shot down. The only part of ITN that is as productive as DYK is RD and that's because it was reformed to eliminate opinionated !votes about the worthiness of the subjects.
Andrew🐉(talk) 08:38, 9 June 2021 (UTC)
No idea what you're talking about. The entire point of the idea lab is discuss ideas, not vote on them, how much more explanation do you need? Aza24 (talk) 22:27, 9 June 2021 (UTC)
I agree with all the points made by Andrew Davidson. DYK is for new articles that are accessible to read, which makes it better than most content on the front page. "Interesting hooks" are totlly subjective, and if you don't like a couple of hooks, don't read them. It seems like Sdkb is trying to ignore all the valid points made above by wikilawyering over the use of the word oppose, instead of actually replying to any of the comparison to much worse front page content. I cannot for example remeeber the last time I ever read a FA/FL on front page, as they're too long and too niche topics. On the other hand, DYK reviewers are encouraged to make hooks accessible to a broad audience, which mostly they do. Joseph2302 (talk) 08:42, 10 June 2021 (UTC)
I don't think I like this proposal. DYK is a place that motivates editors, particularly new ones that want to have their work seen by more readers. If hooks are boring, I would like the reviewer or promoter to suggest ALT hooks. I am also in favour of increasing the 1500 minimum word count for DYK articles, as this will generate more text and possibly provide better hooks. I am concerned that "Allowing facts from any page" to be nominated will cause DYK to highlight popular articles instead of a diverse set of topics, as those are the articles that are frequented the most by readers and editors. If this idea was implemented, I would like a new rule set to be established for the trial run so that articles with tags, source problems, or have already been featured on DYK within the past few years are not eligible. I like the above conversation to add a sentence about what DYK is, and encourage more editors to get involved. Z1720 (talk) 00:00, 8 June 2021 (UTC)
Comment As the creator of the Leonard Liebling article, I find it a little disheartening to read that others think my hook is so boring that it's the prototypical example of what's wrong about DYK. Personally I thought it was interesting, simply because of the variety of different things mentioned in the hook. Concert pianist, opera librettist, composer, and music editor of of an important music publication for a long time. That's a highly varied skill set that is unusual, and I think its interesting no matter what other's say here. In the end, this sort of discussion is highlighting personal taste and personal opinion about what's entertaining to you personally, which is ultimately subjective. My personal opinion is DYK is working just fine as it is, and serves a useful purpose in encouraging positive editing. If it ain't broke, don't fix it.4meter4 (talk) 00:02, 8 June 2021 (UTC)
DYK has always been rather subjective, and what could be interesting to a nominator may not be so to others, or even vice-versa. To be frank, I sometimes think that there are times when a hook is just simply not going to raise much interest outside of a small niche, but the regulars, whether out of politeness or another reason, decline to reject the hook or propose alternatives. There are also cases where hooks are clearly flawed but nominators are insistent on them in spite of consensus against, which given how it's more often than not led to problems, is another issue that is worth considering. Narutolovehinata5 tccsdnew 00:15, 8 June 2021 (UTC)
As a contributor to DYK for years, my experience is reviewers are usually pretty objective, and the DYK rules for review provide enough structure to keep things that way. Frankly, the suggestions here are arguing for a greater degree of subjectivity than currently exists by encouraging editors to express their own biases about what’s interesting and allowing majority votes to determine content. Inevitably such a system will end up marginalizing certain kinds of content (particularly with a predominantly white straight male voting base doing the voting). I am not for creating a systemically unjust and unfair process, which the suggestions here will do. It will also create more work and more opportunities for conflict and stress. It doesn’t sound like an appealing change to me.4meter4 (talk) 02:03, 8 June 2021 (UTC)
The bias concern is something we'd certainly want to look out for, but we have no way of knowing whether or not it'd be much of an issue when we aren't even willing to run a trial. ITN operates with a very similar !voting system, and despite the perennial complaints from both ends, it seems to do okay at least in terms of globalizing its coverage. A cultural mindset of "don't just !vote yes on the video games hook just since you personally like video games" might be enough to minimize problems. And it's certainly not as if our current system is free of bias—it's heavily weighted toward subject areas that produce lots of pages and that have editors willing to make nominations. {{u|Sdkb}}talk 02:36, 8 June 2021 (UTC)
Actually we do have a way of knowing. Much has already been written about systemic white male heterosexual bias on Wikipedia that is based in research with data. Google it. Creating a voting system at DYK which further empowers the white male straight editing majority is not a solution. There’s absolutely no way that you can reasonably argue that a voting body made up of predominantly straight white men aren’t going to have their point of view dominate in a voting system. That’s codifying bias into our process. As for current issues, yes we do have biases towards western topics in our nominations and we ignore women. As a member of WikiProject Women in Red, I spend most of my time creating articles on women to help solve that. We can’t help what gets nominated, because this is a volunteer project, but we can create a system that isn’t going to shut out minority content. 4meter4 (talk) 02:45, 8 June 2021 (UTC)
Well there's an easy solution to that, which is for all the non–whitemaleheterosexuals to get off their asses and vote. I'm one myself so I know it can be done. EEng 20:56, 10 June 2021 (UTC)
Sorry, I've been around this block so many times I'm not going to invest the time reading all the above in the hopes DYK will really change, but I'll repeat stuff stuff I've been saying for years:
EEng 02:57, 8 June 2021 (UTC)
As I've said to you many times before EEng, adopting your proposal would (a) add a great deal of overhead to the process, (b) mean that far fewer hooks get featured so there is less new content for readers to engage with on the main page on a daily basis, (c) disenfranchise most DYK contributors, and (d) in all likelihood, lead at best to a marginal overall improvement in hook quality. It just isn't viable in my view. Gatoclass (talk) 03:54, 8 June 2021 (UTC)
EEng 04:40, 8 June 2021 (UTC)
Firstly, when I said "disenfranchisement", I was referring to the reduced number of users who would actually get their articles featured on the main page under your system. Nobody cares about the number of times they get to vote on somebody else's nominations. Secondly, the notion that confining DYK nominations to GAs would somehow improve the overall standard of DYK hooks is a fantasy. Common sense alone should tell you that reducing the overall number of nominations would correspondingly reduce the total pool of hooks and therefore the overall hook standard. There is no correlation between the size or quality of an article and the quality of its associated hook. Gatoclass (talk) 05:10, 8 June 2021 (UTC)
There are really three independent proposals here: run fewer hooks, so you can skim the best off the top and leave the dregs in the barrel; use voting to determine which we deem best; improve the quality of the articles run by running GAs instead of stubs aborning. These three proposals can be adopted, or not, pretty much independently. EEng 12:35, 8 June 2021 (UTC)
I don't hate the idea of voting on hooks, but like 4meter4 I am very concerned about white & male bias in such voting. Also, right now we allow up to half of hooks to be US-related. If we go to a voting format, are we going to end up with the kinds of arguments we see at ITN over that, with pointy votes that appear to be motivated by making sure we don't have "too much" coverage of the US? —valereee (talk) 11:33, 10 June 2021 (UTC)
DYK does not need "radical reform" so much as it needs to enforce a rule already in place — hooks must be "interesting to a broad audience". Reviewers just need to put their feet down and refuse to approve hooks that fail this criterion, just as they would refuse hooks that are unverified or taken from stubs. – Teratix 09:30, 8 June 2021 (UTC)
Pretty much this. While DYK is subjective, there is a line between a hook that would catch the attention of even people unfamiliar with the subject matter, and one that only appeals to a small niche. It's not uncommon for it to happen that a hook was approved because the reviewer didn't have the drive to decline what was clearly an unsuitable hook, and perhaps addressing this would help address complaints about DYK. As for the concerns above about DYK having certain biases, that has more to do with the makeup of DYK's regulars rather than the structure of DYK itself. Remember that DYK is a volunteer effort, it's not compulsory, so the articles featured are at the mercy of the editors who nominate. And while I would absolutely support broader representation of articles on DYK, lowering our standards probably isn't the way to go, but perhaps there are other ways to encourage outside contributions instead. Narutolovehinata5​t​c​csd​new 10:26, 8 June 2021 (UTC)
I have rejected hooks I felt boring, both as a direct reviewer and while scanning the approved list. However, it's very hard to establish some sort of enforceable standard to hold reviewers to account on. There has never even been agreement among DYK regulars about what makes a hook interesting, and all hooks go through at least 3 gates, so presumably someone somewhere in the chain found them interesting. CMD (talk) 10:37, 8 June 2021 (UTC)
People are encouraged to review the oldest noms or to promote the older accepted noms, though. We'd need to stop doing that to strengthen any gatekeeping effect, and just discard anything that has not seen action in a month. Currently I think anyone with a rules-compliant article can more or less expect that it will hit the Main Page at some point. —Kusma (talk) 12:49, 8 June 2021 (UTC)
In my experience, the oldest noms typically take longer because they're controversial or otherwise tricky, not since they're especially boring. {{u|Sdkb}}talk 16:06, 8 June 2021 (UTC)
Although this post is partly in response to EEng, I'll put it here as the discussion has moved on a tad.
The first point to make is that it's a fantasy to imagine that one is going to get a substantially higher quality of hooks by having !votes on every nomination. Apart from the sheer impracticality of trying to do that given the number of nominations, there are actually very few real standout hooks. EEng talks about reducing the number of featured hooks to a third or a quarter of the current number, but one in three or one in four hooks are not noticeably better than the rest. If you look at either nominations page on any given day, you might find 5 or 6 standout hooks out of a hundred or more, if you are lucky. That's more like cutting the number of featured hooks to one in 20 or less. This doesn't mean that the vast majority of hooks are not up to scratch, it just means that you are not going to get Ripley's Believe-It-Or-Not​-level hooks without really radical nomination pruning, and probably not even then.
The problem then as I see it, is not so much one of radical reduction, since most hooks are of an acceptable standard, it is rather how to eliminate that relatively small number of hooks that are substandard. It would surely be considerably easier to create a process for doing that than to try and evaluate every single nomination by consensus. One might, for example, have a regime where any user can flag a hook as substandard. There would then be some sort of process for trying to improve on the hook or replace it, and perhaps a small permanent panel to make a final judgement. It would surely be a lot simpler than some of the proposed alternatives above. Ultimately though, there is no substitute for engagement. If you think a hook is not up to scratch, tweak it, propose an alternative, or start a discussion about it. A substandard hook can only make it to the main page because nobody along the way saw fit to challenge it. Gatoclass (talk) 13:51, 8 June 2021 (UTC)
Paging Wugapodes so he can say how excited he'd be to code the voting machinery. EEng 14:20, 8 June 2021 (UTC)
I've explained my process. What's yours? – Well no, you've explained the bare bones of a process, which IMO is little more than my "handwave". Sorting out the details of such a process would be a major undertaking. Apart from which, of course, you are in the difficult position of trying to persuade the DYK community to adopt a system that would radically reduce the amount of their content that reached the main page. Gatoclass (talk) 14:45, 8 June 2021 (UTC)
EEng 16:36, 8 June 2021 (UTC)
Well I don't know that it's about "ego" EEng, but whether a DYK community member is new or old, none of them are likely to be keen on seeing less of their work promoted. But we've had so many contributors over the years, I sometimes wonder if it wouldn't be more accurate to simply say "Wikipedians" rather than "DYK community". Gatoclass (talk) 17:04, 8 June 2021 (UTC)
Sorry, too late. You had it right when you said "DYK community" -- those with an investment in the current process which supplies the growing line of little icons on their user pages. It's ego. EEng 17:11, 8 June 2021 (UTC)
"Ego" is a highly fungible word that can mean just about anything depending on context. Yours seems to be along the lines of getting a big head or fancying oneself as special. I can't speak for others, but on the increasingly rare occasions that I've been in a position to nominate a new article for DYK, the payoff for me has always been just to have a few people click on my article and hopefully appreciate the hard work that went into it. So I would say it's about getting a little recognition for one's contributions - there are very few of us, I think, who can manage with none - it's just a pretty basic human impulse. Gatoclass (talk) 17:31, 8 June 2021 (UTC)
(Gc, I know we like each other, so you won't mind when I say that you need to look up the word fungible.) Bottom line, you said it, no getting around it: reform of DYK is blocked by those who won't abide anything that might reduce the amount of their content that reache[s] the main page. EEng 18:59, 8 June 2021 (UTC)
I don't think the entire Wikipedia community can be considered to be involved with the Did you know... process. Even just looking at those who created/expanded the articles with associated DYK items: I wrote one such article; I only learned about the DYK item when I got a posting on my talk page about it on the day it appeared. I had (and still have) no involvement at all in the process. I will say that regarding ego, it was a pleasant surprise to see that the article attracted someone's attention. I think that would be a nice goal for DYK: strive to recognize some articles created/expanded by editors who have never had an associated DYK item before. isaacl (talk) 18:10, 8 June 2021 (UTC)
@Isaacl, I'd like that, too. When I see good pages by new editors with interesting facts as I'm patrolling, I sometimes encourage them to go to DYK. But due to bad design, the process is often too intimidating for them to do so on their own. That means that I have to co-nominate with them. And when I recently sought clarification about whether or not QPQs are required for co-nominations, most editors seemed to feel they are. Decisions like that are what make me feel most hopeless about DYK—not only are we actively disincentivizing the sorts of nominations we most need, we're so wrapped up in our own processes that we're blind to how much of a problem we have (see also: all the comments here along the lines of "it's all subjective, so there's no such thing as a boring hook"). {{u|Sdkb}}talk 18:50, 8 June 2021 (UTC)
Amen, brother. EEng 19:09, 8 June 2021 (UTC)
I think it would be nice to solely nominate an article that had been created or expanded by another editor, without approaching them to ask them to nominate the article or do a co-nomination, as this would enhance the serendipitous nature of the event. Rather than use the carrot of "nomination without cost of an obligatory review", I suggest setting a target quota over some period of time (week, month, year). It might not get achieved, but it would set an objective to strive for. (I don't particularly like the concept of quid pro quo reviews, but as I'm not familiar with the culture of the DYK process and participants, I don't have any suggestions as to what else could be done.) isaacl (talk) 19:38, 8 June 2021 (UTC)
If we want less of the negativity involved in "that hook sucks" perhaps encouraging people to post additional hooks for some wikibrownie points (nomination credits or whatever) might also help. Basically encourage {{sofixit}} for boring hooks. —Kusma (talk) 14:07, 8 June 2021 (UTC)
One issue with this is that it's not uncommon for the nominator to complain about hooks written or modified by other editors, and while at times they are for legitimate reasons, other times it feels more like a case of "I don't like it". Narutolovehinata5 tccsdnew 14:17, 8 June 2021 (UTC)
I haven't done many DYK noms myself (see a comment I will make later as to why) but the few I've done I've welcomed the feedback. My skills are more suited to technical writing (financial statements, standard operating procedures, process manuals, real exciting stuff) and frankly I suck at creative writing, and every hook I've written has been modified by a reviewer. I do understand why a different editor might get attached to the exact hook that they wrote, though. Maybe if it was made more clear up front that hooks might be modified before going live, it would save some of that drama? Ivanvector's squirrel (trees/nuts) 15:23, 8 June 2021 (UTC)
You don't WP:OWN your DYK hook any more than you own any of your created pages. Listening to the nom / page creator is important because they know the subject matter and context best, but it is quite unwiki to allow them too much say over the hook. —Kusma (talk) 16:24, 8 June 2021 (UTC)
Quite unwiki perhaps, but it does happen and it's a tricky position to put a reviewer in. Easy enough to say that a reviewer should be hard-nosed and reject the DYK, but it is a decision that will invariably generate strife with those nominators, which is not pleasant. CMD (talk) 02:30, 9 June 2021 (UTC)
I strongly disagree with the premise that DYK is fundamentally broken, but certainly there are opportunities for improvement. I find myself largely agreeing with Andrew Davidson (don't tell him I said that) about DYK routinely being the most interesting of all the featured content on the main page, and I also agree with the editors who have said that "interesting" is subjective, and a poor reason to completely overhaul the process. Each of the hooks visible at any given time is likely to be "interesting" to some readers while others visible at the same time are not, and some readers won't be interested by any of them, but DYK rotates often enough that I don't see why this should be a concern. For me, modifying the criteria for DYK would be more helpful. I don't nominate many articles for DYK because the sort of writing that I do tends not to fit into any of the criteria. Aside from GA promotions DYK rewards bulk, not quality. I really dislike the 5x criteria for article expansions: what about articles that are already quite large? For example I've participated recently in a broad endeavour to include Indigenous history in articles on Canadian cities, where often there is no information at all or just a very brief mention. This is the sort of info that would make good DYK hooks, but there's no way I'm expanding those articles by five times with that info. If we want DYK to reward article improvement, rather than rewarding mass creation of stubs, then that criteria needs tweaking. Ivanvector's squirrel (trees/nuts) 15:48, 8 June 2021 (UTC)
Thus my proposal that we eliminate the new/expanded criteria and run only GAs. Get people to focus on that. There's a huge GA backlog waiting to be addressed. EEng 19:07, 8 June 2021 (UTC)
I don't think that limiting DYK to just GA noms would do anything to improve the quality of DYK noms, nor to help the GA backlog. It would just lead to more poor quality GA noms and tie up reviewers from promoting actually good content. My point was that the current criteria leave DYK a huge gap between 1) creation of new, stubby dreck, and 2) doing the work necessary to promote a good article. If we want DYK to promote incremental improvements to content (maybe we don't, idk) then there needs to be some middle ground. Or, if we just want DYK to be a list of recently-promoted good articles, then just drop the pretense of "interesting hooks" altogether and just have a bot auto-fill a flat list of new good article titles in its place. That would free up DYK reviewers to review GAs instead. Ivanvector (Talk/Edits) 21:18, 8 June 2021 (UTC)
Your concerns are all valid. But at least DYK effort would be expended toward something lasting i.e. GAs, instead of the current, essentially meaningless DYK reviews, which are a dead end. But at this point I've expended my annual quota of effort wasted advocating DYK reform. EEng 23:03, 8 June 2021 (UTC)
Gatoclass, I think your math here is a little off, since it ignores the likelihood that removing the new page requirement would make the hook nominations much more interesting. We'd start getting nominations because someone came across an interesting fact while browsing, rather than that they wrote a page they want to promote. {{u|Sdkb}}talk 16:10, 8 June 2021 (UTC)
That sounds like you're picturing a DYK that encourages reading (to find cool facts), not writing (to add those cool facts). —Kusma (talk) 16:31, 8 June 2021 (UTC)
Maybe, but right now we have tepid facts in crappy "new" articles. Here's an idea: require that the fact be new. But I still say we should divert all this review labor to GA reviews, by running only GAs. EEng 16:39, 8 June 2021 (UTC)
I sometimes wonder if anyone in the DYK process does read the articles in question. I have often seen hooks on the Main Page that were blindingly obvious ("DYK... that this fish lives in water?" type things), but when I click on the article there is some amazing, spectacular, mind-blowing thing just begging to be used. --Khajidha (talk) 16:47, 8 June 2021 (UTC)
Certainly it's true that some folks don't seem to be very good at identifying good hook material in their own articles. But you are perfectly welcome to propose alt hooks when you find them Khajidha. Gatoclass (talk) 16:54, 8 June 2021 (UTC)
And I have. Both complete alternate hooks and improved phrasing (grammar, tone, flow) of existing hooks. But I don't have the time to concentrate on the project, so my contributions are fairly minor. Some one above said it before, there seems to be a reluctance to call a spade a spade and tell the nominator flat-out "that hook is completely boring and will not be allowed to run, you need to find something better in the article. Have you considered <other thing from article>? " I also question why people who nominate 327 virtually identical articles on butterflies/mushrooms/railroad stations/etc aren't told that they can only pick ONE, the others will not be used. --Khajidha (talk) 17:07, 8 June 2021 (UTC)
You may have meant "327" as an exaggeration, but we actually had 314 nominations on creeks and streams in Pennsylvania [1] -- some of the most stupendously dully hooks (and articles) ever. My attempt to suggest that maybe readers might have been getting just a teensy bit tired of all that dreck was shouted down. EEng 17:19, 8 June 2021 (UTC)
Not really meant as an exaggeration, I had come across examples before. --Khajidha (talk) 18:18, 8 June 2021 (UTC)
(edit conflict) Oh heck no, I would be totally opposed to a model that eliminated the requirement for new content and substituted it with "here's a cool fact I came across somewhere on the Wiki." I also think it would have absolutely zero chance of getting adopted, since there probably isn't a single DYK contributor who would agree to it. Gatoclass (talk) 16:48, 8 June 2021 (UTC)
Why? What the fuck is the value of featuring new content, specifically? It constantly, constantly steers our readers to our worst -- often embarrassingly bad -- content. I keep hearing it over and over: "The purpose of DYK is to feature new content, The purpose of DYK is to feature new content, The purpose of DYK is to feature new content" -- as if it's self-evident that DYK makes no sense unless that's true. But it's not. EEng 18:59, 8 June 2021 (UTC)
Embarrassingly bad? How so? We don't promote articles which are not within policy. They must be: 1. Notable; 2. More than a stub (i.e. bigger than 1500 characters); 3. Thoroughly referenced to reliable sources; 4. Neutral; 5. Free of Copyright Infringement. The main issue here seems to be that you simply don't like the topics being proposed, but yet they do satisfy WP:GNG in order to pass DYK. The other complaint is article size, but I don't see that as an issue. A 1,500 character minimum is perfectly fine for many encyclopedia entries. The print editions of encyclopedias like Encyclopedia Britannica include entries shorter than 500 characters. Our threshold for inclusion in terms of length is reasonable. Lastly, I personally think GA review is a joke. More than half the time GA articles come to DYK with policy issues that require fixing (i.e. plagiarism, NPOV problems, other sourcing issues, etc.). Our DYK reviewers seem to be more astute at reviewing articles for policy issues than what gets done at GA. I am more confident that a DYK article on the main page is within policy than an article with a GA stamp.4meter4 (talk) 23:49, 8 June 2021 (UTC)
EEng 03:10, 9 June 2021 (UTC)
If I wasn't already convinced that there's a disconnect between what regular Wikipedia editors consider interesting and what normal people (i.e. readers) do then this discussion would have convinced me of it. I find many of the comments above, including those from editors with which I usually agree, simply incredible. The section is called "Did you know ...", not "Boring facts that we have decided to put on the main page to boost a few editors' egos". Phil Bridger (talk) 18:04, 8 June 2021 (UTC)
But unfortunately there's no truth-in-advertising regulation for Wikipedia main-page features. EEng 18:59, 8 June 2021 (UTC)
DYK has multiple objectives, not just one, it's never been solely about highlighting interesting facts. With regard to my comments above about how certain proposals here are likely to be received by DYK contributors, I am not making value judgements about those responses, I'm simply trying to inject a note of realism into the discussion. There is little point in coming up with radical reform proposals that are almost certain to fail. Gatoclass (talk) 01:30, 9 June 2021 (UTC)
What I like: Restoring some brief line giving context for the DYK section. Making an effort to make hooks more consistently "hooky" (but not necessarily funny or sensational). I think that in the review process, and in prep assembly, it would be reasonable to be more insistent that the hook be clearly interesting, or enticing to read more about it, even if that means that some nominations end up failing. Still, I agree with some other editors that DYK is often the most interesting part of the Main Page. What I don't like: instituting any sort of voting process, or changing the kinds of pages that are eligible for DYK. --Tryptofish (talk) 20:52, 9 June 2021 (UTC)
Your mother wears army boots.{{country data {{{1}}}
| flaglink/core | variant = | size = | name = | altlink = national football B team | altvar = football | class = B }} Well, could you get on board with the two principles below? EEng 22:04, 9 June 2021 (UTC)
For those playing along at home, Old Army Boots (you should see what I'm wearing, by the way), attempted to put {{fbdb}} there, but only put "fbb", poor fella. But anyway, I already commented below. (Spoiler alert: No.) --Tryptofish (talk) 22:13, 9 June 2021 (UTC)
I meant to do that. 😜 EEng 23:47, 9 June 2021 (UTC)
Two concrete proposals, do or die (IMHO)
I will now assert:
If we can get these two principles enacted, then we may be on our way to real reform of DYK, because it mark the end of the tyranny of those who cry that it's somehow unfair to reduce the amount of their content that reache[s] the main page (see way up in this thread); it will force us to find ways to make choices about what DYK features, instead of essentially everything nominated being pumped down the sludge pipeline no matter what. If not, then there will never be reform.
DYK nominations in the pipeline
EEng 16:37, 9 June 2021 (UTC)
@EEng: If you're looking for !votes on these, you might want to move to VPR or another place where that can happen. {{u|Sdkb}}talk 16:43, 9 June 2021 (UTC)
No, just talking about it for now. EEng 17:02, 9 June 2021 (UTC)
So the Two concrete proposals are not concrete proposals? :-) Anyway, I've been warned if I write "I agree with EEng" one more time, they're going to create a new edit filter. Levivich 17:28, 9 June 2021 (UTC)
I'll also reiterate that I'd love to see someone make a concrete proposal to bring back the "from Wikipedia's newest content" message. I don't think that person should be me given my reputation from this, but I'd support it and frankly I think it has a much higher chance of passing than either idea above. {{u|Sdkb}}talk 16:55, 9 June 2021 (UTC)
Except that would re-engraves in stone probably the worst thing about DYK: its "new content" fetish. However, if you wanted to say, "From new articles that have been slapped together in a hurry to meet the arbitrary and inexplicable DYK 7-day deadline", I'd be on board with that. EEng 17:02, 9 June 2021 (UTC)
The 7-day deadline encourages me to start all possible DYK candidates in userspace so I have time to complete them. A shorter deadline would work even better. I admit it is a bit weird to have a 7 day limit until nomination followed by a 1-100 day wait until the article actually reaches the Main Page. —Kusma (talk) 17:59, 9 June 2021 (UTC)
start all possible DYK candidates in userspace so I have time to complete them – Thus neatly defeating one of WP's more cherished principles, collaborative work. EEng 20:47, 9 June 2021 (UTC)
We increased the deadline because people complained about the deadline being too short. The C of E God Save the Queen! (talk) 20:23, 9 June 2021 (UTC)
I remember various discussions of increasing the days-to-nominate, and the most common objection was, "But then we'd have too many nominations! We'd have to run four sets a day!" In other words, the tight deadline is an arbitrary way of throttling the input to the DYK system, which has no rational way -- indeed does not attempt -- to choose among submissions. For its sheer arbitrariness and irrationality, the seven-day deadline is perhaps the most ridiculous aspect of the DYK system (and that's saying a lot). EEng 20:47, 9 June 2021 (UTC)
I don't follow your logic. What is the goal, and why do these things help? I would understand the principle "stop guaranteeing a Main Page appearance for rule compliant articles with boring hooks", but why is choosing from 30 boring articles better than choosing from 300 boring articles? —Kusma (talk) 18:09, 9 June 2021 (UTC)
why is choosing from 30 boring articles better than choosing from 300 boring articles – Choosing from 30 boring articles isn't what's being proposed. What's being proposed is to choose 30 (or more likely 100) articles from 300 articles. The 300 range from boring/badly written to fascinating/well written, so by taking only the best 100 you're probably getting a pretty good group, and certainly better, on average, than average of all 300 (which is what we present now). EEng 20:47, 9 June 2021 (UTC)
Comment. Reducing the number of submissions per editor doesn't necessarily guarantee overall improvement. In fact, the reverse may be true. Editors who contribute regularly are often more skilled at crafting more interesting hooks and articles than those who don't participate often. Thus such a limitation may have the opposite effect of what you are intending. Further, policing the number of nominations per editor is going to be a headache. I'm not seeing a strong argument as to how this improves DYK's quality. If this were to come to a vote on another page I would not support it.4meter4 (talk) 19:58, 9 June 2021 (UTC)
Comment. Reducing the submissions per editor is nothing more than penalising the regular contributors who do much of the work to make DYK tick. We have already (sadly) lost one of our main contributors earlier this year, we do not need to lose more. Plus it won't improve content, if anything its more likely to make it workse/ The C of E God Save the Queen! (talk) 20:23, 9 June 2021 (UTC)
In order: EEng proposals, no and no. Add something to the Main Page to make it clear DYK isn't a random sample of articles and is showcasing the new-n-improved, but actual wording is complicated -- I agree with EEng about the new-article fetish, just disagree about the degree, and so don't support having a NEW NEW NEW hyperfocus in the wording. Not sure it's come up here, but I broadly concur with prior "broaden the seven-day range", although perhaps a little symbolic because I suppose most DYK regulars are working in sandboxen? Vaticidalprophet 20:26, 9 June 2021 (UTC)
It might be good to have only one rotation of DYK per day, unless that causes a backlog. Maybe. Otherwise, this strikes me as water under the bridge. --Tryptofish (talk) 20:42, 9 June 2021 (UTC)
Well, duh, of course it will cause a backlog unless we bite the bullet and start rejecting nominations. Right now we run as many sets per day as are needed to shovel everything -- everything submitted, whether good, bad, or indifferent -- out the door. And it looks like we'll keep on doing that, because ya know, this is the Special Olympics and everyone gets a trophy! EEng 23:50, 9 June 2021 (UTC)
I think there are (at least) three different goals associated with the Did you know... initiative, including the following:
Overlaid upon this is the priority placed upon these goals. For example, the obligatory review system is a consequence of placing a more urgent priority on presenting more items (it's a circular dependency: when there are more submissions, then people want to present more items; but in order to present more items, you need more submissions and throughput).
It may be easier to achieve these goals separately with different initiatives, rather than trying to stretch Did you know... to cover all of them, never mind adding another goal of highlighting articles rated as good article quality. isaacl (talk) 20:43, 9 June 2021 (UTC)
I would support anything that would encourage people who think they have to nominate every article they write for DYK, whether or not they can actually create an interesting hook.
People seem to try to reverse engineer it. If while you're writing you come across something that makes you think, "Wow! That is so interesting! That would make a great hook!", great. Nom it. But people seem instead to be thinking "Okay, check, article created. Now, what can I use for the hook?" So really, all we need to do is change fundamental human nature. —valereee (talk) 12:18, 10 June 2021 (UTC)
From my experience, it varies. If I've created or improved a DYK-able article and I can think of a good hook, I'll put it forward (often while pinging EEng for a better hook ;-D). In other times, like A719 road, the hook has leapt out at me and I've scrambled to try and improve the article sufficiently to meet the other criteria.
"So really, all we need to do is change fundamental human nature." - Brilliant, Val, you've just outlined exactly how we can fix RfA and a whole bunch of other problems! Ritchie333 (talk) (cont) 13:20, 10 June 2021 (UTC)
Yep, this is very well put—that's the root of the issue. I'm not too confident about changing human nature, but a different system could incentivize different behavior. There have been so many times where I've come across a super interesting fact on an established page and thought "this would make an excellent DYK hook if only it were eligible". I don't think it'd be impossible for us to create a situation in which the most active DYK nominators are not editors promoting their own page but rather editors scouring the encyclopedia for the most interesting facts. {{u|Sdkb}}talk 14:29, 10 June 2021 (UTC)
Smaller reform suggestion: split the review
A slightly different proposal: the technical side of the review is done as normal, and when approved, the hook goes to an intermediate page (between noms and approved noms) where each nom has its hooks voted on by the general community. The more eyes the better, and will hopefully work because the voting body don't have to put in the hard work reviewing. Hopefully it will decentralize the "hook is interesting" aspect enough that the nominator doesn't get offended with "oppose" votes, or feels that it's just their one reviewer who doesn't like it. And the decentralized nature will hopefully mean that reviewers don't feel obliged to approve a hook they don't feel is interesting (one-on-one as it is, it may feel personal when you say no). The slightly more extreme version is to just go full ITN, where it's completely decentralized and everyone gets a vote on if it meets technical spec and is interesting, but given how much must be met for the technical side of DYK, I think that's too much of an ask. So, one person reviews the technical side as is normal, then a voting system; some ratio of support:oppose can be decided on for a hook to go through, and this stage would also allow other alt hooks to be proposed. Kingsif (talk) 11:33, 10 June 2021 (UTC)
Too cumbersome. EEng's proposal actually makes more sense than that, and it doesn't make enough sense either. Gatoclass (talk) 12:47, 10 June 2021 (UTC)
I'm very concerned about voter bias, both unintentional and pointy. Are we going to end up with only those hooks that are interesting to white men? Are we going to get voting designed to ensure we aren't US-ipedia? —valereee (talk) 12:29, 10 June 2021 (UTC)
Voting on individual hooks could actually worsen some biases we have, and is a bit clumsy. Perhaps we could have a system where decent articles with insufficiently hooky hooks can be flagged up for the Hook Rescue Squadron? —[[User:|Kusma]] (talk) 12:37, 10 June 2021 (UTC)
I am currently toying with the idea that a voting process may be useful as a backup, where the interestingness of a hook becomes disputed. That way it isn't used for all hooks, (and hopefully not for many at all,) but it provides a clear path forward on interestingness debates and takes some of the personality out of results. CMD (talk) 12:40, 10 June 2021 (UTC)
I echo the concerns about diversity of hooks. A lot of editors will be American or British, and I think that would lead to an unconscious bias towards hooks from these countries. Similar to on WP:ITNC, where we get way more proposals for US articles than any other country. Also, if anything, DYK process needs to be made simpler, not more complicated. It's already the most complex process a newish editor gets involved in. Joseph2302 (talk) 12:43, 10 June 2021 (UTC)
Also, it doesn't solve the issue I mentioned above somewhere: what we the editors think might be "interesting" doesn't always match with what readers end up deciding they want to read. So we could exclude hooks as boring, when readers may have found them interesting, or vice versa. Joseph2302 (talk) 12:50, 10 June 2021 (UTC)
(edit conflict) Yes, I agree with you and Valereee that maintaining hook diversity would likely be a major challenge in any !vote-based system. There are certain topics that are perennially fascinating to human beings and others that almost invariably are not. How, one wonders, would hooks about obscure sea sponge species fare in a !voting system? Or hooks about opera or ballet? We are an encyclopedia, not a tabloid, and hooks should reflect the full diversity of encyclopedic topics, not just those likely to attract the most attention. Gatoclass (talk) 13:07, 10 June 2021 (UTC)
I still believe that an interesting hook can be written about any topic (provided there is something interesting there), nominators just need to give up on trying to force all the specialist knowledge into the hook - interesting to them, boring to people who don't know about sponges/opera/ballet. Either find something universal about the item, even if it seems unimpressive to the experts, or keep the specialist hook simple enough. Kingsif (talk) 18:17, 10 June 2021 (UTC)
I do think this is an issue. We have noms who think it's a shame that the person's major accomplishments are sidelined by the fact they did something surprising. Maybe we need to discuss the fact that "Writer wrote book" is much less interesting than "Writer learned to skydive at 89" or whatever. —valereee (talk) 22:00, 10 June 2021 (UTC)
I very much agree with this sentiment. There should probably be a change in the thinking of DYK contributors that the hooks they write are not for them, but for the greater readership, and that hooks need to be written with that audience's interest first, even if it may not be favorable to the specialist. For example, a hook about an opera singer performing a role may be of interest to opera fans, but it may be less so to the hoi polloi, whereas if the opera singer did something surprising for an opera singer (for example, if they also sang rap or another completely different genre), that may be more likely to catch the attention of even non-opera enthusiasts. I understand we all have our biases but we don't own our articles or hooks and we should always keep that in mind. Narutolovehinata5​t​c​csd​new 01:38, 11 June 2021 (UTC)
This is something I've noticed a lot. And sometimes the contributor is so close to the subject that they don't see that something that they find interesting (and needs no explanation to them) would be greatly intriguing to the general public with just a little expansion, but comes off as incredibly dull without it. --Khajidha (talk) 11:43, 11 June 2021 (UTC)
@Valereee, Kusma, Chipmunkdavis, Joseph2302, and Gatoclass: Prep promoters seem to do a good job building diverse sets, I'm sure a group of users - or maybe the technical reviewer? - could be going through the noms to basically rule out any supports and opposes that seem biased (e.g. "support - California is cool" or "oppose - I've never heard of Petrovic" would just be discounted). But this would be contingent on everyone giving a reason for their !vote. Kingsif (talk) 18:22, 10 June 2021 (UTC)
I don't think that's workable. Discount "math sucks", but keep "our readers are put off by having to see advanced mathematics"? Discount "oh no not another radio station" but keep "radio stations only have a very local impact"? If you have to develop criteria about what votes to toss out, shouldn't you just develop better criteria for the hooks? —Kusma (talk) 18:37, 10 June 2021 (UTC)
What I'm concerned about are !votes like "Oppose. There are too many US hooks. This isn't US-ipedia." Also whether heavy support for a certain hook is because that hook is about a subject which typically is of high interest to white men, and vice versa. Are we going to end up with every footy hook sent through because, duh, footy is inherently interesting, and one about feed sack dresses yawned at because of our editor demographics? —valereee (talk) 18:49, 10 June 2021 (UTC)
For what it's worth, to both of you, I would personally discount all of those comment examples (and anything just saying "footy is interesting"). Who cares that radio stations are local? And it's already written into DYK that there's a lot of US hooks (they're usually quite reliable filler so I don't want to lose them). I suppose I should have been clearer that it would be the bias content, not bias phrasing - !votes counted on quality, as per the rest of Wikipedia. I don't know if you still think it's unworkable, though, with all the thought behind the count. Kingsif (talk) 22:56, 11 June 2021 (UTC)
But @Kingsif, it doesn't have to be that blatant. These are inherently !votes that are opinions. How do you count a !vote on whether something is "generally interesting" as a "quality vote" or not? Someone could say, "Oppose. Clothing was made of cloth...ho-hum." Is that a "quality vote" opinion? I can't argue with it. It's a reasonable opinion. And a ton of white men might have that same opinion about most of my articles and hooks because I often write about things of interest to women. I also try to write about things I suspect might be of interest to people of color and especially to women of color. Those things may not look "generally interesting" to most of my fellow editors. —valereee (talk) 13:18, 14 June 2021 (UTC)
There are lots of topics that I am not interested in, but I can still see a difference between a boring hook and an interesting one. Take opera. I have no interest in opera. A hook that is basically "opera singer sang opera" is boring. But a hook like "opera singer sang in both East and West Germany before the wall fell" or "opera singer sang multiple lead roles in a single weekend" or even "16 year old sang role usually reserved for mature singers" has something interesting about it, even if you hate opera. So, while I (a white man) may not be personally interested in the topics you write about, I can still appreciate your hooks if you give me a reason to. --Khajidha (talk) 20:36, 14 June 2021 (UTC)
Evaluating page quality
Editors have commented above that there can be a problem when a new page of poor quality gets highlighted. Short of limiting DYK to GAs only, there are other ideas that might be worth brainstorming on. Currently, DYK requires that new and newly-expanded pages conform to basic policies, meet some standards for citing sources (mainly for the hook), and not be stubs, but also says that the pages should not be expected to be at the level of a GA (I assume that the GAs are GA-level, wink, wink). There is room in there for some potential tweaking of the standards.
I recognize that one has to be careful not to open the door to, in effect, making DYK review almost the same as GA review, because that would make a lot of nominations far too protracted and difficult. Simply asking reviewers to confirm that the page satisfies core policies is a necessary but low bar. We could also stipulate that pages should have no conspicuous formatting problems, and have the same requirements for inline citations that we currently require for the hook, throughout the main text. We could say that the page should be written well enough that it is understandable to any reader who comes to it from the main page. Maybe require more than one or two sources. I would think of it as setting the bar a little higher than Start class, but lower than GA. Also more like "Wikipedia's best new content" instead of "Wikipedia's newest content". If some careful thought were to go into the wording, this would eliminate some nominated pages from eligibility, but in a beneficial way, without making the review process insurmountable. I don't think there will be consensus to limit DYK to GA only, but this is a less drastic step that is worth evaluating. --Tryptofish (talk) 18:52, 10 June 2021 (UTC)
I issued the following challenge (slightly reworded here) somewhere above but (surprise!) it went unanswered:
Among the things GA requires but DYK doesn't are that an article be clear, concise, and understandable; address the main aspects of the topic; and stay focused on the topic without going into unnecessary detail. DYK has no such requirements, so the articles it presents are allowed to be badly written, confusing, woefully incomplete, and/or bloated and discursive – and they often are. Of course, if you're saying that's not true, then DYK's article's already meet GA and no one should have any problem with making GA the gating requirement for DYK. Or do you admit that DYK articles are often badly written, confusing, woefully incomplete, and/or bloated and discursive, but since that's OK we shouldn't apply the GA standard? Please say which. EEng 20:20, 10 June 2021 (UTC)
Yes, such criteria are good. I wouldn't like for us to reinvent the wheelconcept of article assessment, though, and would suggest to stay close to existing things like WP:B? or WP:C?. —Kusma (talk) 20:58, 10 June 2021 (UTC)
I think raising the standards a bit (length, sourcing) is fine. For the lazy who want to click instead of reading, something like "if mw:ORES says B, pass, if it says Stub or Start, fail, if it says C, look more closely" could work as a proxy for a real review. —Kusma (talk) 20:40, 10 June 2021 (UTC)
Oh yes, by all means let's substitute automated evaluation for human review. That would let us run twice as many -- three times as many -- five times as many DYKs every day with no additional human effort!More seriously, no one's yet answered my challenge here just above. Maybe you'll be the first. EEng 20:50, 10 June 2021 (UTC)
I'm not sure whether this hasn't already happened (some folks seem to think "not copyvio" is the same as "Earwig doesn't find a copyvio"). Some human review (ideally coming with suggestions how to improve the article) is always good to have if you ask me (I prefer constructive feedback to just a tick). Just need to be careful not to make it too daunting for new reviewers. —Kusma (talk) 21:09, 10 June 2021 (UTC)
I have low, very low, enthusiasm for anything that would be automated. I'd prefer to look at it in terms of improving the wording of the DYK rules (and preferably not the supplemental rules, except to make them consistent). Something near to B-class, but not as high as GA, seems approximately right to me. As for EEng, I want to challenge you to stop changing the subject to your own earlier comments, and to focus instead on the ideas here. --Tryptofish (talk) 21:17, 10 June 2021 (UTC)
If we're going to stick with reserving DYK for new pages, I don't think there's anything terribly wrong with our current standards. Most new pages aren't super high-quality—article development takes time—and that's reflected in DYK. My view is that we ought to ditch newness as the (usual) requirement, but that's already been discussed (at great length) above. {{u|Sdkb}}talk 21:29, 10 June 2021 (UTC)
Perhaps there are ways to address some of the concerns that underlie the desire to ditch newness, without actually ditching it. Such an intermediate approach will not satisfy editors who "want it all", but wanting it all rarely gets consensus. --Tryptofish (talk) 21:44, 10 June 2021 (UTC)
But DYK is not reserved for newness. It can feature any article, no matter how old, so long as it has recently been brought to GA standard. So I wish people would stop saying it's only for new articles. You can already take any article on Wikipedia that isn't already an FA or GA and get it featured by bringing it to GA standard. So the only barrier is that you must do a bit of work on an article you want to nominate to improve it. That is good for the encyclopedia and in my view is an appropriate requirement. Gatoclass (talk) 06:52, 11 June 2021 (UTC)
Taking an article to GA status is not just "a bit of work", especially if it's a big article for an important topic, which is also where the most interesting DYK hooks are likely to be found. And regardless of your personal view about whether people ought to be willing to put in more work, the reality is that they don't—90% of DYKs are for new articles, not GAs, and a giant collective mindset shift isn't going to just happen because we decide on it. The only way the current nomination dynamics will change is if we're bold enough to change (or at least experiment with) the rules. {{u|Sdkb}}talk 07:25, 11 June 2021 (UTC)
Well maybe some of you guys need to spend a little more time trying to figure out exactly what you want from DYK, because one minute the discussion seems to be about better quality hooks and the next it's about better quality articles. But certainly you are not going to get better quality articles by dumping the GA requirement and just going with any hook you happen to find somewhere that tickles your fancy. Apart from which, I would dispute the claim that there is a lot of work getting articles to GA standard - it depends entirely on the state of the article beforehand, and the rigorousness of the reviewer. But even if there was considerable work in the average GA, so what? Shouldn't you be expected to do a little work for the privilege of getting a DYK on the main page? Part of DYK's purpose is improvement of the encyclopedia, and the GA requirement achieves that. Gatoclass (talk) 09:40, 11 June 2021 (UTC)
Regardless, I think it's pretty clear that the main complaint about DYK over the years has been about hook quality, but I think most hooks these days are actually of an acceptable standard. The problem is a relatively small number of hooks that just aren't up to scratch, and if we solved that problem, we would probably eliminate 90% of the complaints.
So for what it's worth, here's my proposal for improving overall hook quality, that doesn't require radical makeovers of dubious benefit or feasibility. Basically, we just give people an incentive to work harder on hooks. One way to do this would be to have some sort of DYK credit for identifying a substandard hook and coming up with a better alt. Let's call it the "Eagle Eye" credit or something. So, if you challenge a hook as insufficiently interesting, and come up with an alt hook that makes it to the main page without substantial changes, then the challenger gets a DYK "Eagle Eye" credit. That gives reviewers and other users an incentive to start paying more attention to hook interest to see if they can come up with something better. It's a simple, low overhead solution that would be easy to test and which could conceivably result in a significant improvement in overall hook quality. Gatoclass (talk) 09:46, 11 June 2021 (UTC)
I like it. Crowdsourced and carrot instead of stick. —Kusma (talk) 10:30, 11 June 2021 (UTC)
Template:The DYK Medal is already available for use in the meantime! CMD (talk) 11:52, 11 June 2021 (UTC)
I like this idea a lot! I've certainly done that for hooks in the past, and I could certainly see myself doing more of it if it counted as a QPQ. It won't solve the problem of some articles being nominated because the nominator wants to see their work on the main page rather than since the article contains any fact of interest. But it would help address the problem of nominators being too close to the subject to know what's actually interesting about it (what Narutolovehinata5 and Khajidha discussed above; search for "change in the thinking of DYK contributors"). {{u|Sdkb}}talk 20:42, 11 June 2021 (UTC)
I've been doing this for the sake of DYK, you mean to be saying I could've gotten credit this whole time ;) Kingsif (talk) 23:00, 11 June 2021 (UTC)
I like this idea, too. I think treating it as a QPQ is worth doing. It gets more sets of eyes on noms, which can only be a good thing. —valereee (talk) 13:27, 14 June 2021 (UTC)
New user right (edit request reviewers)
This snowed at VPR and it's going to snow here as well; there's no point in dragging it out. {{u|Sdkb}}talk 17:41, 8 June 2021 (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.
Moved from WP:VPR
I propose the creation of a new user right: "edit requests reviewers" who have the ability to accept/reject edit requests that are proposed in the talk of protected pages (except PRC protection and full protection) This right is automatically assigned to administrators and PRCs who have extended confirmation.
I make this proposal because I believe that only trustworthy users can accept/reject edit requests following the same logic that led to the creation of the PCR user right. DrSalvus 23:11, 5 June 2021 (UTC)
  • Oppose because this doesn't seem to make sense or solve a problem, and is technically infeasible. The permission to edit a semiprotected page is limited to autoconfirmed users. It follows that any autoconfirmed user can make the same edit independently, and thus should also be able to process the same content when requested on talk. Where the content is in dispute, it is resolved by the usual WP:DR processes to build consensus. This proposal is also technically unforceable and cannot be a user right as proposed, because it's technically indistinguishable whether an edit is implementing a request or is an independent edit. Finally, Wikipedia does not need to limit editing in this manner, and there is no evidence of a problem with autoconfirmed users responding to edit requests. Actually, the real problem is that PCR shouldn't be a separate user right. It should be bundled in with autoconfirmed or extendedconfirmed. An autoconfirmed user is sufficient to implement an edit request via talk, and is sufficient to edit a pending changes page directly and have their changes go immediately live, and thus should be able to approve a change as well. ProcrastinatingReader (talk) 01:28, 6 June 2021 (UTC)
  • Oppose, appears to be a solution looking for a problem. Can you give us some examples of autoconfirmed or extended-confirmed editors wrongly accepting/rejecting edit requests? Sungodtemple (talk) 01:48, 6 June 2021 (UTC)
  • Note @Dr Salvus: I've moved this from VPR to VPI. This really would need a lot of work shopping before it is ready for a proposal discussion. If you strongly disagree, go ahead a move it back - but it will likely get snow closed there. Here it could be developed more. — xaosflux Talk 03:15, 6 June 2021 (UTC)
  • No. Any experienced editor in good standing may review an edit request. That is policy. 🏳️‍🌈 Chicdat  Bawk to me! 10:09, 6 June 2021 (UTC)
  • Oppose, as ProcrastinatingReader states above and far better than I could this makes no sense from a technical viewpoint. Furthermore I see no reason why this should be implemented, the reason almost all edit requests are made is because the editor can't currently edit the page because of the circumstance outside of their control, and normally we wouldn't have some special usergroup checking their edits eiter. -- Asartea Talk | Contribs 15:20, 7 June 2021 (UTC)
  • Oppose, reviewing an edit request shouldn't require any more technical capability than editing an article, which is basically the base level of competence expected of all editors. Creating a userright for this would just be a hat to collect: it wouldn't improve anything, and would make responding to edit requests much more bureaucratic than it needs to be, which is actively harmful to content creation. Ivanvector's squirrel (trees/nuts) 15:13, 8 June 2021 (UTC)
  • Comment: I've notified WikiProject Edit requests of this discussion. Happy editing! ---Another Believer (Talk) 15:19, 8 June 2021 (UTC)
  • I agree that sometimes there's a tendency to go straight for the easy templated XY or RS response on edit requests – answering the letter of the request, rather than taking the two extra minutes to dig out a source or suss out what the requester is trying to say. I've been guilty of that myself on occasion. However, doing it via userright is not the way to address that, for the reasons stated by others (technical infeasibility being a big one). If you see a request declined that you would've completed, there's nothing saying you can't still work on it, and if you see someone doing it a lot, discuss it with them. If it's something that's more widespread, that's something that should be demonstrated with diffs and addressed, but for now I agree that this is a solution seeking a problem. ‑‑ElHef (Meep?) 17:22, 8 June 2021 (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.
Dealing with off-wiki campaigns with the power of upvotes
WP:AN#Possible new tool/technique/procedure (permalink) gave me a bad idea. The goal is dealing with the stream of visitors so that Wikipedia's operations are affected little as possible. So let's make an off-wiki page to send them to. I propose we make something that looks like Reddit, where the "posts" are either questions (for us, the editors) or edit requests. Comments can be made, and posts and comments can be voted on by visitors, in the usual way (maybe we require an account to be created, maybe we offer Google/whatever sign-in). Why, Enterprisey, why?!, you may be asking. I think a Reddit-style platform is the optimal solution to this situation: lots of incoming visitors/attention, most of it bad - so we use the wisdom of that crowd to sort the most popular items to the top, and then deal with them in a public way. The idea being people want to be heard, and hopefully they'll be satisfied with upvoting the posts they would've made instead of writing them yet again in an edit request, on our talk pages, or on articles. By way of responses, maybe Wikipedia editors can post with a special tag, or even under the name "Wikipedia" itself, and their posts could automatically sort to the top ("stickied", in Reddit terms). Yes, this is really anti-egalitarian, but our systems break down above a certain amount of load anyway (recent example: the "fifth caliph of Islam" brouhaha), and the alternative is just using page protection on everything.
Goszei suggests using a Twitter-like model instead of a Reddit-like model - actually, using Twitter itself: create a hashtag, like #WikipediaSuggest, and then people post using both that and some "incident"-specific hashtag. While this is a great idea, and addresses some of the (massive) moderation problems we'll encounter, I think people are already wise to the tactic of dumping people onto Twitter and then not responding to them. Heck, even UserVoice gets that sort of reaction these days. So I think Reddit on an original-ish site has the best chance. Enterprisey (talk!) 08:55, 6 June 2021 (UTC)
Any proposal that can eliminate the problems of the AFT and keep the benefits would be a good one. I think just making the problems someone else's, namely Twitter's, is one way (perhaps the only way) of solving this. The moderation would be their problem, and their algorithms are crafted to sort out junk. It would also serve as an outreach and appeal to pick up editing that extends beyond Wikipedia. The suggested Reddit-model is more "controlled" than just dumping to the open sea and seeing what floats, but that control comes with a significant moderation burden. — Goszei (talk) 20:43, 6 June 2021 (UTC)
Then of course the media will get alerted and we'll get endless flak (which in all honesty we will completely deserve) for having this platform. At which point the WMF will step in.
Of course if we do moderate this new platform to avoid all of the /pol/ shit we've done basically nothing to address the problem beyond just shifting the workload around. :I'll paraphrase this from Ratatouille and say that the meaning of "anyone can edit" isn't that anyone can be a good editor, but that a good editor can come from anywhere. While the vast majority of new contributors aren't good we need to treat everyone with respect and give them the opportunity to be on the same level as any "established" Wikipedian, because our most important job is to find the 10% of people who actually will be good editors and keep them editing productively.
Also the fifth caliph of Islam thing isn't even our fault. That's Google and Bing's fault for having a paradigm based on surfacing anything regardless of actual accuracy. When you search for it on Wikipedia we give the right results. Chess (talk) (please use
{{reply to|Chess}}
on reply) 21:08, 6 June 2021 (UTC)
Suggestion: reverts should be sourced as well
In recent months I've seen my edits being reverted more and more often. I'm not saying all of my edits were good, but I *am* saying some of them were proper new knowledge into the encyclopedia. Some of them were—also, I believe—reverted because of partisan bias, always by the reason that I don't source well enough.
True enough, this is my sin. I don't source well, because of how my memory works. But isn't it also a sin to revert without reason as well?
Especially since in the philosophy of science I'm a follower of Karl Popper, i.e. a falsificationist. From that standpoint it seems kind of trite to just revert stuff which hasn't been duly falsified. Such a thing doesn't seem to lead to accumulation of knowledge. Especially since this encyclopedia *tries* to follow broadly Popperiean principes; does it really, anymore?
Why not require a cite for a substantial revert, as well as an edit, for symmetry? I mean, a revert is as much of a removal as a removing edit. Both of them should be sourced. Evenmoreso the removal and the revert, than the addition, in fact: they destroy knowledge added by the community, for the Sake of an Arbitrary and Often Useless Rule. I believe the better option would be to make destroying edits and reverts as hard to do, and well-sourced by standard, as an addition is.
And by the way, that sort of change of rules would revitalize the community as well. *Everybody* is in pains with how the editorial culture here is turning. It's harder and harder to just wiki-edit, because the learning curve and editorial culture has become so steep. You just can't get your stuff in, evenwhile you know what you're talking about. In the lesser known wikipedias such as my Finnish one, you can barely step in still. But in en-pedia, it's almost impossible, unless you're a (semi-)professional editor.
That is then fully counter to the original mission of Wikipedia. You cannot collect all of the encyclopedic knowledge out there if you bring up this sort of barriers to the common expert just writing it up. Of course the rules make it easier for the editorship to keep standards up, and stake their ground, but the accumulation of knowledge then suffers. For example via those constant, formalistic, unsourced reverts I and everybody else suffers.
Please put a stop to them by rule. If not by the rule I'm suggesting—in sourcing reverts and amissive edits—then otherwise. Because otherwise the development of this encyclopedia is going to hit a serious case of diminished returns. We will stagnate, quite like DMOZ once did. Decoy (talk) 20:56, 6 June 2021 (UTC)
Verifiability is Wikipedia policy, not "an Arbitrary and Often Useless Rule". Schazjmd (talk) 21:00, 6 June 2021 (UTC)
And most of the above is addressed in WP:BURDEN specifically. —  HELLKNOWZ   ▎TALK 21:07, 6 June 2021 (UTC)
It's actually perfectly in line with the original mission of Wikipedia. Back in the day we used to say that "on the Internet, no one knows you're a dog". Wikipedia's idea is that rather than focusing on the old paradigm where we trust an "expert" to write an article based on their knowledge of the subject, we allow anyone (even dogs) to edit but make trusting them irrelevant with very strict sourcing requirements. So, when you're reading Wikipedia you don't have to trust the Wikipedia editors who could be dogs. You just click on the box with the number in it and look at the original information.
If you don't like the founding principles of Wikipedia then go to Citizendium. Chess (talk) (please use
{{reply to|Chess}}
on reply) 21:21, 6 June 2021 (UTC)
@Chess: I'm not sure Citizendium will exist anymore by the time Decoy gets there. 🏳️‍🌈 Chicdat  Bawk to me! 10:33, 7 June 2021 (UTC)
If you want a source for reverts, I'm going to use [3] to source this revert. This was poor paragraph, with an unsourced quotation because it apparently isn't a real quotation! Please keep a formal encyclopedic WP:TONE without such opinionated or essay-like wording. Reywas92Talk 19:07, 7 June 2021 (UTC)
Net worth values in IBs
I find the net worth estimates in IBs (eg at Bill Gates) to be very problematic and confusing. How can we actually provide the reader with an accurate estimate when Bloomberg and Forbes often conflict? Which one do we choose? Do we average? Should it be a weekly or monthly average? How often should it be updated? What do the accompanying red or green triangle indicate? (An increase/decrease in the past day, week, month, year, etc) It opens up a whole can of worms. In similar situations, like the values of elements or drug prices, we avoid including monetary values. I'm starting to think that we should do the same and save an explanation of net worths for the prose where it can be better explained. What do you think? ~ HAL333 04:31, 8 June 2021 (UTC)
(edit conflict) Use both. 🏳️‍🌈 Chicdat  Bawk to me! 10:38, 8 June 2021 (UTC)
Use neither. As noted, where appropriate it can be explained more completely elsewhere. Nikkimaria (talk) 12:07, 8 June 2021 (UTC)
We had a discussion somewhere (but I don't recall where) recently about "net worth". I'll note that I hate the term "worth" in this context as if someone's worth was determined by what they own, but we seem to be stuck with it. I am in the fairly normal position of a middle-class Englishman approaching retirement age in that my net worth consists of a house and a pension fund and little else, but I would struggle to tell you my net worth to closer than about 20% either way, so how on Earth can we consider any published guesses to be in any way accurate? The very rich tend to have assets in large shareholdings and property, the monetary value of which can only be properly assessed when they are sold - the current share price of a company does not determine what a large stake can be sold for. Of course Bloomberg and Forbes often conflict, because thay both make wild guesses and then pretend that their figures are in some way objective. Phil Bridger (talk) 15:39, 8 June 2021 (UTC)
Link to RfC on this: Template talk:Infobox person#Deprecating the net worth parameter?. Cheers. ~ HAL333 17:05, 8 June 2021 (UTC)
formating article export
Tracked in Phabricator
Task T167956
Hi, I would like to set the page format for article export (PDF, Book and/or print, whatever)? Can't find such options (my fault?). I am thinking about simple stuff like font size, position of tables and widht of the outer frame of the pages. No idea how that could be implemented, probably not too hard. Would be cool if someone took care of that. Thank you — Preceding unsigned comment added by Hennk von Muspelsheim (talkcontribs) 12:51, 8 June 2021 (UTC)
Not at the moment. This should really be at technical. Someone please move the dicussion accordingly, I have no idea how to do it. Sungodtemple (talk) 12:02, 9 June 2021 (UTC)
@Hennk von Muspelsheim: on the left sidebar pane there is a "printable version" button example you may click - however keep in mind this feature is deprecated; if you use the "print" function in your browser (including options it may have to "print to pdf") you will likely have better results. If you have other general questions on how to use Wikipedia, please see Wikipedia:Help desk - if you think you have identified a technical problem you can post at WP:VPT. — xaosflux Talk 15:51, 9 June 2021 (UTC)
Adding new language option as Indian English
Tracked in Phabricator
Task T212313
Moved from WP:VPR
A new language option should be given to users known as Indian English. It is important not only as a new language but also all Indians use their own numbering system known as Indian Numbering System which uses lakhs and crores instead of millions and billions where 100,000= 1 lakh(1,00,000) and 1 million(1,000,000)= 10 lakh(10,00,000). Most of the websites and apps convert values to the Indian Numbering System when English(India) is selected and I think Wikipedia should do the same. — Preceding unsigned comment added by Sreeganesh M R (talkcontribs) 10:58, 9 June 2021 (UTC)
Is there a recognized, formal standard for Indian English? And, if so, how does it differ from those of British English, Australian English, Irish English, etc? We really don't even need all the "_______ English" tags we already have. Note that colloquialisms and terms for things not really found outside of India don't count for these differences. Your suggestion of automatic converting of numbers seems like something similar to the idea of automatic conversion of units. Such things have been rejected in the past. --Khajidha (talk) 11:17, 9 June 2021 (UTC)
I am sure this has been discussed at length previously, but my take is that the differences between various varieties of English are small enough to mean that we don't need any automatic conversion. The number system is one of the major features that is different in Indian English from that in other varieties, but I think that all that needs to be done is for editors to be aware that others, even though pretty fluent in English, may not be very familiar with terms such as million or crore and to bear that in mind when deciding whether to link them. Phil Bridger (talk) 12:07, 9 June 2021 (UTC)
What exactly do you mean by new language option, Sreeganesh M R? It's already a policy that articles can be written in any variety of English including Indian English, so for example topics related to India should already write large numbers in lakhs. – Joe (talk) 12:17, 9 June 2021 (UTC)
The manual of style discourages use of lakhs and crores even when writing in Indian English. Usedtobecool ☎️ 13:47, 9 June 2021 (UTC)
@Usedtobecool: It does? The only above I'm seeing at WP:CURRENCY is for non-country specific articles. {{u|Sdkb}}talk 14:13, 9 June 2021 (UTC)
According to MOS:INDIA the use of lakhs/crores is allowed provided that million/billion equivalents are provided in parentheses, and that lakh/crore is linked at the first mention. Narutolovehinata5 tccsdnew 14:16, 9 June 2021 (UTC)
MOS:LAKH: We are the Borg. Usedtobecool ☎️ 15:20, 9 June 2021 (UTC)
  • @Sreeganesh M R: this proposal isn't actionable and would need much development, including for you to be much more specific about what you want changed (and then how you want that to happen) - I've moved from the VPR forum here to the idea lab so it doesn't just get declined and closed. — xaosflux Talk 13:42, 9 June 2021 (UTC)
  • For use in the software, please see phab:T212313. — xaosflux Talk 13:45, 9 June 2021 (UTC)
  • There was a discussion I think several years ago now (I can't find it) about merging all the different "use ____ English" templates and directives down to only those which are actually functionally unique, which would have left us with only {{Use American English}}, {{Use British English}}, and {{Use Canadian English}}, with every other existing template redirected to whichever one applied to that variant (between US and UK; Canadian is unique). It evidently did not reach consensus. I can see the case being made here that Indian English is a variant that's unique enough to also be treated uniquely in this scheme. However, if the proposal is to create a separate Indian English Wikipedia (akin to Simple English Wikipedia) then no, strong oppose. Ivanvector's squirrel (trees/nuts) 14:29, 10 June 2021 (UTC)
  • One problem with Indian English is defining it. At the academic level it loses most of its distinct characteristics, and as it is a second language for the great majority of its users, very many make grammatical "choices" that would not be found in the better Indian newspapers (which are probably the best choice for a "standard"). But are these "mistakes"? Who is to say? An Indian schoolteacher I suppose, but we have few such editing. One of the most conspicuous differences is use of "the", which Indian writers tend to omit (like Polish ones). Is that wrong or not? The Times of India wouldn't do it, or not often. Johnbod (talk) 15:08, 10 June 2021 (UTC)
Exactly. I would think that true language variants would be set by native speakers. If the distinctiveness of "Indian English" is mostly due to usage by secondary speakers, I would not count it as valid. In English language sources from India, academic sources and major news sources are probably going to be indistinguishable from British English. --Khajidha (talk) 16:10, 10 June 2021 (UTC)
Well, major news sources are certainly not indistinguishable in their references to large numbers. Indian sources nearly always use lakh and crore, which are unknown terms in British English. Phil Bridger (talk) 16:32, 10 June 2021 (UTC)
True, but that could be handled with a "use British English, but provide lakh/crore numbers" option. Are there any other differences in high-level, formal sources? --Khajidha (talk) 18:12, 10 June 2021 (UTC)
Yes, I agree that there are very few things that are unique to formal Indian English, hence my statement above, but we should acknowledge those that do exist, and hope that our readers will learn about them. Phil Bridger (talk) 20:03, 10 June 2021 (UTC)
I certainly don't agree that "there are very few things that are unique to formal Indian English" - actually there are rather a lot (depending on how you define that dialect). If Khajidha believes "major news sources are probably going to be indistinguishable from British English" this suggests to me he doesn't spend much time reading them. Johnbod (talk) 21:52, 11 June 2021 (UTC)
Hide custom signatures for new editors
I recently wrote User:Enterprisey/signature rfc drafting. Might formally propose it at some point. All feedback welcome (here or there). Enterprisey (talk!) 22:20, 9 June 2021 (UTC)
Adding on a bit to what I wrote there, I think right now it's tricky, because we need to find an impossible balance between having readable wikitext (because talk pages are still edited in wikitext) and having enough syntax for programs to be able to tell what's a signature, so that they can do things like the variable display you're proposing. This is quite similar to the problem we have with references filling up the wikitext and the debate about list-defined references. Long-term, I hope the solution to both of these will be the same: make VisualEditor (or, in the case of talk pages, discussiontools) so effective that almost no one looks at wikitext, at which point it will be able to become as complex as needed. {{u|Sdkb}}talk 22:44, 9 June 2021 (UTC)
Yeah, I'm hoping the proposed syntax, or whatever people come up with, will be acceptable. If the community's position is indeed zero-tolerance for any changes, the situation looks pretty dire. Enterprisey (talk!) 22:58, 9 June 2021 (UTC)
I think it's a great idea, personally. SportingFlyer T·C 23:01, 9 June 2021 (UTC)
Excuse my ignorance, is there a wave of new editors complaining about how confusing signatures are? Is this really a problem? HighInBC Need help? Just ask. 23:03, 9 June 2021 (UTC)
Yeah, a few. Just looking at comments currently on WT:SIG, I found WT:SIG#A reader's perspective, Special:Diff/1025529507 (from the previous thread), Special:Diff/1027705784​, and Special:Diff/1027480740​. Unfortunately, due to survivorship bias, the lack of further examples isn't an argument for or against new editors finding signatures confusing. Enterprisey (talk!) 23:22, 9 June 2021 (UTC)
Seems like some confirmation bias there, as the only people involved in that polling are ones that had a complaint. — xaosflux Talk 01:12, 10 June 2021 (UTC)
I figure new editors are equally as likely to find their way to the discussion whether they did or didn't have a complaint. Sure, people who had a complaint are more motivated to share it, but surely someone without one would've seen the 4+ responses and wanted to make their side heard? Enterprisey (talk!) 03:40, 10 June 2021 (UTC)
Given that the current, WP:CENT-listed RfC at WT:SIG is currently showing an avalanche of opposition to even restricting the use of custom signatures, what is the point of even asking this? – Joe (talk) 10:18, 11 June 2021 (UTC)
This doesn't restrict their use, so it might have an easier time passing. Enterprisey (talk!) 22:40, 11 June 2021 (UTC)
minor edits in watchlist
This is first time I am posting here so not sure whether this is the right place. I read few weeks ago that there was discussion to restrict marking "minor edits" to auto/extended confirmed user.There was no consensus. That proposal was made because many new users misuse it and the editors who have "hide minor edits" filter on watchlist are not able to see it. So I propose that a new filter be added to watchlist which shows minor edits from new users but hides minor of 30/500 users. -- Parnaval (talk) 12:26, 12 June 2021 (UTC)
(For reference, the discussion is here: Wikipedia:Village pump (proposals)/Archive 179#RfC on limiting minor edits.) It looks like there is a filter for removing all minor edits, and for removing all extended confirmed edits, on your watchlist, so this would just be about removing edits that are in the intersection of the two. I'm not sure if Wikipedia:Customizing watchlists advice gives any way that you could bodge this together yourself. I think this is quite a specific and esoteric use case and not necessarily worth the developer time it would take. We have more major watchlist issues, like not being able to watchlist a single section of a talk page, or watchlist a talk page without watchlisting the article. I'm pretty sure we got this new watchlist filter system from a Wishlist, though I can't locate which year or proposal it was from, so I would imagine this would take a lot of WMF developer time (and it takes a huge amount of community effort to get the WMF to do even the smallest development change). — Bilorv (talk) 12:12, 14 June 2021 (UTC)
@Bilorv: are you talking about the default watch list? Which specific option are you referring to for "hide extendedconfirmed" ? — xaosflux Talk 23:32, 14 June 2021 (UTC)
@Xaosflux: you need to re-add a ping if you miss the signature—this one didn't go through. Yeah, in the default watchlist under "Filters", you can choose which edits to view out of ones made by people who are IPs/registered/autoconfirmed/extended-confirmed. There's also a filter for hiding minor edits. But no (combination of) filter(s) that will exclude only the intersection of extended confirmed and minor edits (only the union). — Bilorv (talk) 10:34, 15 June 2021 (UTC)
@Bilorv: ah ok this is on the javascript-interface watchlist; at a quick look I'm not seeing these parameters being outputed such that a userscript could take advantage of them - so an upstream software enhancement would likely be needed here. — xaosflux Talk 11:01, 15 June 2021 (UTC)
Make mobile version article segments closeable from the bottom
Moved from WP:VPR
On mobile, article sections pose a few problems. The best example of this is that you might be midway through an article, then go to a new page, then press back to go back to the article, and find you have lost your place. Frequently it positions you at the top of a previous section or midway through it.
Scrolling on mobile is also fairly time consuming.
So instead the idea is to let each segment be closed from midway through it or from its bottom. This way you can read a section, and then close it once you're done without having to scroll up. Another idea would be to be able to close the section from any point up or down it.— Preceding unsigned comment added by (talkcontribs) 14:50, 13 June 2021 (UTC)
Interesting suggestion. BusterD (talk) 15:39, 13 June 2021 (UTC)
I moved this to Idea lab, as it isn't an actionable proposal - it is a request to invent a new UX control. From a UX perspective, how would you see this working? Consider there are things you can click on "in the section" already - like links, images, etc (not to mention copying text). — xaosflux Talk 20:52, 14 June 2021 (UTC)
Not quite what the OP is asking, but a simple CSS solution:
.​collapsible-heading​.​open-block { position: sticky; top: 0; background-color: #fff;}
will make headings stick to the top when open. Nardog (talk) 21:15, 14 June 2021 (UTC)
I think i have a better proposal. Let's implement the same feature recently released for Fandom's mobile display: a floating TOC that can be used to navigate all sections quickly. So if a user want to close/collapse the current section, they can open the TOC, select current section, then close. This doesn't require tediously scrolling up. You guys should check it out. enjoyer -- talk 23:01, 14 June 2021 (UTC)
Let me know when you've found an int-admin willing to edit MediaWiki:Common.js​/​css to implement this proposal please. 🏳️‍🌈 Chicdat  Bawk to me! 10:01, 15 June 2021 (UTC)
Last edited on 15 June 2021, at 11:01
Content is available under CC BY-SA 3.0 unless otherwise noted.
Privacy policy
Terms of Use
HomeRandomNearbyLog inSettingsDonateAbout WikipediaDisclaimers