Wikipedia talk:Did you know

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Did you know?
Introduction and Rules
Introduction and rulesWP:DYK
Supplementary rulesWP:DYKSG
Reviewing guideWP:DYKR
General discussion
General discussionWT:DYK
Awaiting approvalWP:DYKN
April 1 hooksWP:DYKAPRIL
Preps and queuesT:DYK/Q
Main Page errorsWP:ERRORS
On the Main Page
Archived setsWP:DYKA
Just for fun
Monthly wrapsWP:DYKW
List of users...
By nominationsWP:DYKNC
By promotionsWP:DYKPC

This is where the Did you know section on the main page, its policies, and its processes can be discussed.

Backlog mode[edit]

I have added a new heading so the backlog mode discussion can be found more easily when it has been archived. TSventon (talk) 06:47, 28 May 2022 (UTC)Reply[reply]

I think it's worth noting that this is not because we have few DYKNs coming in, but because DYKN is seriously backlogged. I heard a suggestion to give DYKNs WikiCup points (2.5 for submitting, 2.5 for reviewing, to avoid people who create DYKs getting "free" points for QPQ) and I think something like that would be good to try. Maybe even a DYKN backlog drive, in the style of GAN backlog drives? Trainsandotherthings (talk) 00:18, 25 May 2022 (UTC)Reply[reply]
Trainsandotherthings, if you are interested in the question of backlog drives there was a discussion about them earlier this month here. TSventon (talk) 01:07, 25 May 2022 (UTC)Reply[reply]
That discussion wasn't all that fruitful and now the backlog is even larger with 207 hooks needing to be approved and 63 approved hooks. SL93 (talk) 01:17, 25 May 2022 (UTC)Reply[reply]
I think one issue is that most of the "delayed" nominations are noms that are quite difficult to review, either due to being mostly reliant on technical sources, or due to their subject matter (usually politics). A backlog drive would be nice but given the circumstances a backlog was probably inevitable. Narutolovehinata5 (talk · contributions) 01:42, 25 May 2022 (UTC)Reply[reply]
We have a mechanism all set up for dealing with large numbers of unapproved nominations per the RfC last summer and subsequent discussions: extra QPQs for experienced DYK nominators. The suggestion of a GAN-style DYK backlog drive was roundly panned at the time. Pinging EEng, who worked so hard to devise the process and shepherd the RfC to completion, to help get it rolling for real. BlueMoonset (talk) 02:50, 25 May 2022 (UTC)Reply[reply]
Me and my big mouth -- I've been dreading this day for the last 12 months. Yes, we came to a policy decision as BMs describes, but what hasn't been done (I think -- haven't been watching DYK) is to set up the automation that will identify editors subject to the new requirement. We may need to use the honor system temporarily. Give me a few days to review where we are and recruit technical firepower. EEng 06:37, 25 May 2022 (UTC)Reply[reply]
@EEng: I'm happy to help :) fools rush in, etc. I think the most straightforward way is to add a note to the {{NewDYKnomination}} template. Something like "effective 30 May 2022, DYK is in "unreviewed backlog mode". All nominations made by editors with 20 or more prior DYK nominations will require an extra QPQ." That way, it'll appear on all new nominations (but not currently open nominations) until we remove it, and timestamps itself. Beyond that, we already use the honour system anyway. theleekycauldron (talkcontribs) (she/they) 06:48, 25 May 2022 (UTC)Reply[reply]
What I'm vaguely remembering is we needed some new machinery for counting "credits" or whatever we called them. EEng 14:28, 25 May 2022 (UTC)Reply[reply]
@EEng: You mean like User:SDZeroBot/DYK nomination counts.json that @SD0001 mentioned below? —Kusma (talk) 15:41, 25 May 2022 (UTC)Reply[reply]
EEng, you were quite insistent that "credits" were to be a thing of the past; the only thing that mattered was nominations, which were set as the determinant going forward. BlueMoonset (talk) 03:42, 26 May 2022 (UTC)Reply[reply]
That's why I said " new machinery for counting credits or whatever" -- I remembered there was to be some change in what was counted, just couldn't remember what the change was. (I'm not Superman, you know, despite appearances.) Now that you mention it, that's exactly right. I've been reviewing the two big archived threads and there's a lot to it. It seems they ended with intentions to install new apparatus (template behavior at when new noms are saved etc.) and from other discussion some thought or work has been put into that, but not clear what still needs to be done to make it seamless. It actually sounds like others are more up to speed on the current status than I am, though I'm happy to help once I've got my sea legs again. EEng 12:47, 26 May 2022 (UTC)Reply[reply]
Is there a way to add a note on the DYK script that most editors use? It also doesn't support natively adding multiple "reviewed" pages without manually typing, say, {{subst:dykn|ArticleA}} and {{subst:dykn|ArticleB}} in the window. Some editors might miss this otherwise. Sammi Brie (she/her • tc) 08:00, 25 May 2022 (UTC)Reply[reply]
The DYK-helper tool is maintained by @SD0001, so that feature should probably be taken up with them. theleekycauldron (talkcontribs) (she/they) 08:13, 25 May 2022 (UTC)Reply[reply]
There should be a page from which DYK-helper can get to know if backlog mode is currently active. For instance, we can adopt WP:Did you know/unreviewed backlog mode to read enabled or disabled as the case may be – which could then be used by templates/scripts. Let me know once this is created – I'll then update the script accordingly. – SD0001 (talk) 13:10, 25 May 2022 (UTC)Reply[reply]
If a switch like that is added, it should also be used to conditionally display a backlog notice at the top of Template talk:Did you know. —Kusma (talk) 13:17, 25 May 2022 (UTC)Reply[reply]
User:SDZeroBot/DYK nomination counts.json is already in place that records nom counts and is updated in real-time, which can be read by {{subst:NewDYKnomination}} to determine if the current user needs a 2nd QPQ. (For 9 months now, server resources are being wasted on keeping that page up-to-date despite zero use – maybe that will change now :)) – SD0001 (talk) 13:17, 25 May 2022 (UTC)Reply[reply]
@SD0001: oh, that's actually incredible, thanks :) theleekycauldron (talkcontribs) (she/they) 18:34, 26 May 2022 (UTC)Reply[reply]
is there a page where the nominations themselves are available? theleekycauldron (talkcontribs) (she/they) 18:35, 26 May 2022 (UTC)Reply[reply]
What would be needed to actually start the 2 QPQs per nomination rule? SL93 (talk) 03:00, 25 May 2022 (UTC)Reply[reply]
I have added a backlog tag to at least alert people. —Kusma (talk) 06:20, 25 May 2022 (UTC)Reply[reply]
If something like this is added to the WikiCup, I'd rather go for 4/1. A DYK review isn't like half a GA review. —Kusma (talk) 07:57, 25 May 2022 (UTC)Reply[reply]
  • If I may be honest, I have some skepticism as to whether the planned backlog mode (i.e. two QPQs for editors with 20+ nominations) is going to help out much in the long run. One reason is basically simple arithmetic: if the number of nominations being made exceeds the number of QPQs being done, it doesn't matter if nominators are providing one or two QPQs, a backlog will still build up over time. Secondly, not all nominators meet the 20 nominations requirement: many nominations are done by editors who have 6-19 nominations and so would be exempted from this requirement. If they too make nominations without more work being done on the backlog, the backlog would still get bigger and bigger. Finally, the way I see it, it's not that people don't want to review nominations, or not enough people are doing them. The backlog isn't necessarily anyone's fault. The issue is that many nominations are controversial from the get-go owing to their content. For example, I cannot blame anyone from being discouraged from reviewing any nomination that has to do with Israel-Palestine considering how much of a hot potato that topic is. Narutolovehinata5 (talk · contributions) 08:19, 26 May 2022 (UTC)Reply[reply]
    A lot of nominations are made by people with over 20 nominations. Just Gerda, Corachow, Epicgenius, Sammi Brie, Z1720, you and me together have something like 25 nominations on the page right now. 25 extra QPQs done would significantly reduce the number of unreviewed noms, and I would expect the number of affected noms to be closer to 50. I take your point that some nominations are more attractive to review than others, but I don't see how we can change that.
    The question is what else can we do? We could fail all nominations that haven't been reviewed after four weeks (like at FAC) or reject nominations where the QPQ is provided late, but (unlike the proposal) these would not change the fundamental issue that we need more reviews than people are required to provide as QPQs. —Kusma (talk) 08:41, 26 May 2022 (UTC)Reply[reply]
    Hopefully the planned backlog mode is a short term measure and won't need to be used too often. theleekycauldron posted a chart here, showing that the number of unapproved nominations went down to below fifty in August-September in both 2020 and 2021. DYK depends on some editors reviewing more nominations than they need to, offsetting nominations by new editors that do not require a QPQ, and hopefully backlog mode will encourage them to help. Backlog mode will probably also encourage prolific contributors to divert some time from nominations to doing reviews which can be used later as QPQs. If some of those reviews are of more difficult nominations, they will still be useful. TSventon (talk) 10:48, 26 May 2022 (UTC)Reply[reply]
    I generally think we should encourage people to do QPQs before they nominate articles. Currently I count seven nominations by highly experienced nominators lacking a required QPQ, needlessly making the backlog worse. Personally I find it much less stressful to use one of my stack of QPQs than to have to scramble for one at nomination time. —Kusma (talk) 11:10, 26 May 2022 (UTC)Reply[reply]
Has a bot reminding editors about late QPQs ever been considered? For example, if a nomination doesn't have a QPQ and one hasn't been provided after seven days, a bot will leave the nominator a talk page message reminding them to do a QPQ. Of course, that's only if the nominator actually needs to be a QPQ. I imagine it could be a bit tricky to code, but it could help I guess. Narutolovehinata5 (talk · contributions) 14:51, 28 May 2022 (UTC)Reply[reply]
Kusma Good luck with that. I just brought up the QPQ issue at the nomination of a major DYK nominator and they asked why I have it in for the nomination. SL93 (talk) 20:08, 28 May 2022 (UTC)Reply[reply]
@SL93: Ugh. I think a time limit is reasonable, and another week is plenty. (Personally I usually just do not review noms that lack a required QPQ). —Kusma (talk) 20:26, 28 May 2022 (UTC)Reply[reply]

Technical stuff from the old discussions[edit]

I may be way behind the times, but I believe WT:Did_you_know/Archive_182#Start and End (and following section) is (or was) a key starting point for technical implementaion ideas. Who are our techies on this? Wugapodes, for startes? Wug, can you ping other techies involved? Possibly this is entirely obsolete but it's where my brain left off, anyway. EEng 03:50, 28 May 2022 (UTC)Reply[reply]

Ping Wugapodes. TSventon (talk) 04:31, 28 May 2022 (UTC)Reply[reply]
Wugapodes did you see this? Who else needs to be involved? TSventon (talk) 01:51, 30 May 2022 (UTC)Reply[reply]
@TSventon and EEng, sorry I missed these pings. What's needing done? Implementing a "some people need two QPQs" system? SD0001 had some ideas in that previous thread but to my knowledge no one's worked on anything yet. Wug·a·po·des 03:19, 30 May 2022 (UTC)Reply[reply]
I think it's probably best if we both go back to the top of WT:Did_you_know/Archive_182#RfC_Discussion:_Details_of_implementing_EEng's_propsal_"Unreviewed_backlog_mode" and review forward from there (maybe skimming it all first to see what early stuff was obsoleted by later parts of the discussion). Then we can compare notes. I don't think there's anything too hard in there, but that's easy for me to say since I'm assuming you're volunteering to do all the work (bless your heart). Shall we start that way? Oh yes, first question: What happened to moving everything out of Template space (which, some may recall, I predicted would never happen)? EEng 03:38, 30 May 2022 (UTC)Reply[reply]
It seems like the main things are (1) a way to keep track of "backlog" mode and (2) a way to note how many QPQs are needed for a nomination. The first we can do pretty easily by having WugBot update a page on-wiki with the number of untouched nominations. The second is slightly harder and not something I know much about. We'd need the on-wiki templates and lua modules to get the content of that page and parse it appropriately. I'm not sure how to do that. Substing the page into the template? As for moving out of Template space, I was looking today and WugBot has code to handle it, but I don't think anything's moved on that front. Wug·a·po·des 05:02, 30 May 2022 (UTC)Reply[reply]
I can handle (2) – all that's remaining is to edit Module:NewDYKnomination to read the nom counts and the "is backlog active?" page and show a message accordingly (the module is used in a substed template so no performance issue).
As for moving to template space, there was agreement in the last discussion that it should be done, but some insisted that a formal RFC should be held – we're waiting for someone to start that. – SD0001 (talk) 05:30, 30 May 2022 (UTC)Reply[reply]
It looks like data on other pages can be accessed via lua which is good to know. I'll look into modifying the module this weekend and see how far I can get with lua. Wug·a·po·des 07:46, 30 May 2022 (UTC)Reply[reply]
So you think this new "untouched" category of nominations is feasible? Right now we've got (courtesy of your hard work) a separate page for unapproved vs. approved. Would we move to three pages, or just have the two kinds of unapproved ("unapproved, untouched", "unapproved, touched") remain on a single page? Offhand I don't see clear plusses or minuses either way (other than inventing a third page is probably more work than leaving just two pages). EEng 16:21, 30 May 2022 (UTC)Reply[reply]
I imagined keeping our current two-page system. The page WugBot would update would just be a counter, kinda like the next queue counter. So it wouldn't distinguish the modified from unmodified nominations on the page, but doing so is feasible for WugBot if that would be helpful. Adding a third page is extra complexity for no clear benefit, so I'd rather try page sections before moving to a 3-page system. Wug·a·po·des 23:01, 2 June 2022 (UTC)Reply[reply]

@EEng and SD0001: I've modified the module and it seems to be working. Check out the module sandbox and examples in my sandbox. I still need to modify WugBot so to update Template talk:Did you know/Unmodified nomination count, but after that everything should be good to go on this. Wug·a·po·des 16:56, 4 June 2022 (UTC)Reply[reply]

Wugpodes any news? I am asking now to prevent the thread being archived after a week of inactivity. TSventon (talk) 15:12, 11 June 2022 (UTC)Reply[reply]
Wugapodes might be a tad distracted over the next few days. Schwede66 17:37, 11 June 2022 (UTC)Reply[reply]
@TSventon Oh, I was waiting on feedback from others. Looks like SD0001 did some fixes on the template, and given EEng's silence I take it everything looks good. I'll get to work on WugBot and update you once everything's in order. Wug·a·po·des 21:58, 14 June 2022 (UTC)Reply[reply]
Actually, I've had almost no time for WP for about the last two weeks. I have total confidence in you, Wugapoo, but if you fee=l you need me to pass my hand over something, give me a day. EEng 23:23, 14 June 2022 (UTC)Reply[reply]
No worries, I get being busy. No pressure to review anything, I just wanted to make sure I didn't rush something past you. Wug·a·po·des 23:27, 14 June 2022 (UTC)Reply[reply]
The template sandbox version looks good to me, sorry forgot to comment here before. I just added a minor check (to avoid an error just in case someone edits the page to contain a non-number). – SD0001 (talk) 04:08, 15 June 2022 (UTC)Reply[reply]
  • Looks good, Wug! Questions:
    • What keeps Template talk:Did you know/Unmodified nomination count updated? Is it done in real time, or daily, or hourly, or what?
    • Same question for the nominator's count of prior nominations -- is it updated in real time (so that if a user does nom A and then immediately nom B, the module processing nom B sees a count that includes nom A), or daily, etc?
EEng 04:28, 16 June 2022 (UTC)Reply[reply]
Template talk:Did you know/Unmodified nomination count will be updated by WugBot. I intend for it to be run alongside the approval checks, so it will be done every other hour. The count of nominations is handled by SD0001, and it looks like it occurs every couple of hours. SD0001 would know the specifics. Wug·a·po·des 22:31, 18 June 2022 (UTC)Reply[reply]
There are some race conditions here which may or may not matter (much), and when I get my thoughts together I'll say something about them. In the meantime (and apologies if this is answered above) where exactly are the counts-of-prior-noms-made-by-each-editor compiled? EEng 00:40, 24 June 2022 (UTC)Reply[reply]
The counts can be seen at User:SDZeroBot/DYK nomination counts.json. There certainly are a few race conditions, and I can see two at the moment: (1) the race between WugBot and SDZeroBot and (2) the race between nominators and both bots. For (1) that can be handled by SD0001 and I coordinating a staggered run schedule so WugBot doesn't run ahead of the by-nominator-count update. For (2) it's harder given the run schedules. We'd need some way to have the update triggered by an edit to the main nomination page or just have the bots run really frequently. I don't know how to do the first one, and either could actually make the race condition between bots worse since it would become an execution time issue not a scheduling issue. There's probably some sweet spot where the coordination is tight but not perfect, and the slack could be handled by a "hey, don't bulk nominate DYKs to try and end-run the backlog mode" message. Wug·a·po·des 20:19, 24 June 2022 (UTC)Reply[reply]
Let' start with the most obvious problem (and correct me if there's a flaw in this narrative): (a) Editor has 4 nominations (no QPQ); (b) Editor makes a 5th nomination (also no QPQ); (c) before bot updates DYK nomination counts.json, editor makes a 6th nom. This last nom should require a QPQ, but because the counts.json still shows the editor has having only 4 prior noms, machinery mistakenly reports that no QPQ is required.
Now, as I've said before we're talking about QPQs here, not someone's prison release date, so this isn't the biggest deal in the world, and at most it would happen maybe once a year. But when it does happen, consternation will follow and there will be a Talk:DYK thread opened, and a congressional investigation, and there will be gnashing of teeth and tearing out of hair and wrending of garments, all for nothing. So if we can avoid it easily then we ("we" means you, of course) should do it. Tell me if this makes sense: Can the nomination processing machinery, when it reads the nominator's value from counts.json (to see if it's < 5, between 5 and 19, or >=20 -- if I'm remember the boundaries correctly) then ++ it and write it back? That would "patch" the count without waiting for the bot to run again.
There's a similar race for crossing the 20-nomination boundary which triggers the double-QPQ requirement, and this would solve this too. Also, unless I'm not thinking of something, with this in place it's really not necessary for the counts.json bot to run frequently -- once a day would be fine.
Does what I've said make sense, and can you swing the writing back of the incremented count? EEng 21:07, 24 June 2022 (UTC)Reply[reply]
I'd rather we not wrend garments, I just bought mine. Unfortunately what you describe is not possible. The DYK nomination template uses a Lua module, but while these modules can read arbitrary pages, they cannot write to arbitrary pages. The only way to do what you described would be using an automated system like a user script or bot. Wug·a·po·des 21:38, 24 June 2022 (UTC)Reply[reply]
Well, shit. EEng 22:04, 24 June 2022 (UTC)Reply[reply]
As I mentioned above and in earlier discussions, updating of counts.json takes place in real-time. It doesn't run on any schedule. To take the latest one, Template:Did you know nominations/Adele Nicoll was created at 2022-06-24T16:39:29Z and SDZeroBot updated the count at 2022-06-24T16:39:33Z. If the difference of 4 seconds also seems too much, I'm sure we can find a way to make it faster. – SD0001 (talk) 22:24, 24 June 2022 (UTC)Reply[reply]
Sorry to have made you repeat yourself; last year I was told I needed a brain transplant, and the only brain available was from a goldfish. 4 seconds is plenty prompt; just out of curiosity, how exactly does the bot find out it needs to run? EEng 18:58, 26 June 2022 (UTC)Reply[reply]
It uses the Wikimedia EventStreams API. Basically it asks the wikimedia server: "notify me whenever a page with title beginning Template:Did_you_know_nominations/ is created". The bot runs 24x7 looking out for such notifications to arrive. When they come, it finds out who created the page, and increments that user's count.
It's similar to the technology that enables your phone to notify you of new emails – immediately when the email arrives. – SD0001 (talk) 19:49, 26 June 2022 (UTC)Reply[reply]
Can it notify you whenever someone creates a nomination with a boring or erroneous hook? EEng 21:59, 26 June 2022 (UTC)Reply[reply]

I dislike being the guy who just pokes holes while others do all the work,[1] but this raises some new questions.

  • (a) So, to be clear, the bot operates only by ++ing a user's counts on file -- it never rebuilds the counts from scratch (by looking at ... I don't know, I guess by looking at every page, going back forever, of the form Template:Did you know nominations/)?
  • (b) But the bot hasn't been around forever, so where did the initial counts come from?
  • (c) You look at who created the nom template page, not the name of the nominator given in the template itself? (Wugapodes -- maybe those two things can't be different? The nominated by (or self-nominated) stuff in the nom template -- does your machinery enforce that the named nominator is the same as the editor creating the template?)

EEng 21:57, 26 June 2022 (UTC)Reply[reply]

Okay, I was just oversimplifying. The EventStream API isn't perfect – it can miss a few notifications and deliver a few ones twice. To account for those glitches, we DO rebuild the counts from scratch -- every 24 hours. The process for that is simpler – it queries the database (quarry:query/59696). This is also where the initial counts came from.
As to (c), yes we only look at who created the template page. So multi-user nominations are credited to solely to one person. If we wanted to overcome this limitation, it's easy enough in the real-time update component. But the build-from-scratch component of the bot might would become a BIG task involving reading in the contents of 58318 pages, as opposed to a simple 1.5 minute database query. Is it worth it? – SD0001 (talk) 03:20, 27 June 2022 (UTC)Reply[reply]
W/r/t (c) they can be different. Thanks SD0001 for the clarification; I also missed the part where you explained the event stream API. It's the first I'm hearing about it so I look forward to reading up on it. @EEng: So with this information, it seems like the race conditions are minimized. There is still the issue of a bi-hourly WugBot run which would be what triggers "backlog mode". That is, we'll have up-to-the-minute counts of nominations but the backlog mode would only change once every two hours. I think that might actually be reasonable--we wouldn't want it yo-yo-ing around every few minutes as things get added and removed. What do you think? Wug·a·po·des 02:36, 29 June 2022 (UTC)Reply[reply]
Wugapodes, SD0001, EEng, has backlog mode gone onto the back burner? There are currently 61 unapproved nominations and it is nearly August, so the situation does not seen critical at present. TSventon (talk) 14:30, 31 July 2022 (UTC)Reply[reply]
Not yet. When the situation does become critical, then we'll get off our asses. Brilliant minds such as ours work best under pressure. (Just to repeat what I've taken pains to point out before, W and S are doing all the work; I just sit around trying to find flaws.) EEng 15:33, 31 July 2022 (UTC)Reply[reply]
  • One of the technical problems is see with DYK is that it's too hard to find hooks that need reviewing. There's one huge list of templates and you need to manually scan them to find the ones that aren't done yet. What I generally do when reviewing is just go to the newest days and pick one from there, because it's easier to find them at that end. I know that it's more useful to review older submissions, but human nature being what it is, I just go for what's easier. The Wikipedia talk:Did you know/Archive 187#Older nominations needing DYK reviewers section below is great. Something like that should be a regular (automated) feature of the system. -- RoySmith (talk) 14:51, 3 September 2022 (UTC)Reply[reply]


  1. ^ Who am I fooling? It's nice, actually.

Issue with recent additions[edit]

Currently, WP:DYKA archives DYK hooks "according to the date and time that they were taken off the Main Page". However, at present, the bot that updates an article's talk page will state "A fact from this article appeared on Wikipedia's Main Page in the "Did you know?" column on [Date]" with "Date" linking to the archive. This means that talk page links are taking users to the wrong archive.

Example. DYK appeared on Main Page on 25 June but hook is archived under 26 June. Krisgabwoosh (talk) 00:21, 23 August 2022 (UTC)Reply[reply]

The archives have always been dated with when the hook was archived from the main page, rather than when it was first promoted to the main page. It's a known issue, one that gets mentioned here once or twice a year; it isn't possible to predict the removal time with any accuracy (indeed, sometimes hooks are removed altogether so they aren't archived at all). The link typically is to the adjacent archive, so it can be found. Unfortunately, there's not an easy fix; if there were, it would have been fixed by now. BlueMoonset (talk) 03:58, 23 August 2022 (UTC)Reply[reply]
I see. Is there a consensus policy on whether the link should be corrected? In my example, I changed the date to 26 June and linked to the correct archive, though not necessarily the correct date it was posted on. Perhaps the link should be changed but not the date? Krisgabwoosh (talk) 04:39, 23 August 2022 (UTC)Reply[reply]
No consensus that I'm aware of. If it's considered desirable, perhaps a bot could be created to adjust the links after archiving if necessary. BlueMoonset (talk) 16:35, 23 August 2022 (UTC)Reply[reply]
I'd consider that desirable, considering that this issue is added to eight articles each day. Perhaps a discussion could be started on that. Krisgabwoosh (talk) 17:09, 23 August 2022 (UTC)Reply[reply]
what if the bot simply posted to the archive in chronological order (instead of reverse chronological order) and posted its updates with the hooks appearing before the new section heading (instead of after)? this way, the new section heading will contain the post time of the hooks that will eventually be archived under it, rather than the archive time of the hooks being concurrently archived. dying (talk) 10:01, 27 August 2022 (UTC)Reply[reply]
I... have no clue what you just said. Support nonetheless as it seems smart. Krisgabwoosh (talk) 17:05, 27 August 2022 (UTC)Reply[reply]

oh, sorry! i should have attempted to illustrate this by showing what happens over a couple of updates. for simplicity's sake, let us assume that updates are being run at a rate of one set a day, and ignore the utc timestamps that the bot includes in its posts. currently, the bot posts its updates to the top of the hook list, so the earliest hooks remain at the bottom, and the archive is in reverse chronological order. in addition, each update consists of a section heading containing the date of the post, followed by the hooks being archived. over a couple of updates, the archive grows as follows:

== yesterday ==
* day-before-yesterday's hooks
== today ==
* yesterday's hooks
== yesterday ==
* day-before-yesterday's hooks
== tomorrow ==
* today's hooks
== today ==
* yesterday's hooks
== yesterday ==
* day-before-yesterday's hooks

as each update contains a heading with the date at the time and the hooks being archived, in the end, the date of each section heading is the archive date of the hooks that were concurrently archived below it. this is why "DYK hooks are archived according to the date and time that they were taken off the Main Page".

if the bot were to post to the archive in chronological order, then updates would be posted to the bottom of the hook list, so the earliest hooks remain at the top. now, if the hooks were to be posted to the archive above the new section headings rather than below, the archive would grow as follows:

* day-before-yesterday's hooks
== yesterday ==
* day-before-yesterday's hooks
== yesterday ==
* yesterday's hooks
== today ==
* day-before-yesterday's hooks
== yesterday ==
* yesterday's hooks
== today ==
* today's hooks
== tomorrow ==

using this method, in the end, the date of each section heading is the post date of the hooks below it. note that a new section may not contain any hooks when the heading is first added to the archive, but the hooks will eventually be archived in the update following. dying (talk) 02:17, 28 August 2022 (UTC) [copyedited. dying (talk) 06:52, 29 August 2022 (UTC)]Reply[reply]

Thanks for the elaborated explanation, I understand what you mean now. This is certainly an interesting remedy to the issue. I'm not sure if this is the right channel, but if so, perhaps a proper discussion could be started to see if community consensus could be reached on the topic. Krisgabwoosh (talk) 02:32, 28 August 2022 (UTC)Reply[reply]
i am admittedly still very much a neophyte in dyk space, so i am not sure if there is a more appropriate place to discuss this. however, i did manage to find this issue about the recent additions page raised in this page's archives, here, here, and here, so i am assuming that this forum is as good a place as any. (any editor with more experience is welcome to move this discussion to a more appropriate place.) would it make sense to ping the participants of the discussions linked above to try to form a consensus? my search was by no means exhaustive, so feel free to point out any other relevant discussions that are in the archive. dying (talk) 04:51, 29 August 2022 (UTC)Reply[reply]
@dying: I think the technical issue would be arise we switch from 12 to 24 hours a day, and vice versa. For example, imagine the bot posts an update that is supposed to run for 24 hours, placing the new section heading and bullet point below the hooks as normal. What happens when we switch to 12-hour sets, and now the future empty timestamp in place is wrong? theleekycauldron (talkcontribs) (she/they) 06:42, 1 September 2022 (UTC)Reply[reply]
I think the reason this setting is this way is because the only thing DYKUpdateBot can be instantly certain of when it shelves a set is what time it is right then – scrabbling around for the previous (upload) time is difficult and inefficient. theleekycauldron (talkcontribs) (she/they) 06:44, 1 September 2022 (UTC)Reply[reply]
That's a valid point. I'll be honest, I still don't entirely sure why DYK hooks are archived under the day after they go on the main page. Krisgabwoosh (talk) 06:57, 1 September 2022 (UTC)Reply[reply]
@Krisgabwoosh: They're archived when they leave the main page, which is 12 or 24 hours after entry, depending. But you're correct that it'd be much simpler for DYKUpdateBot to archive hooks when they enter the main page. theleekycauldron (talkcontribs) (she/they) 07:05, 1 September 2022 (UTC)Reply[reply]
While it would be easier, we have enough instances of a hook being changed during the time on the Main page that perhaps we keep archiving the last version. Bad enough that usually the credits remain wrong. --Gerda Arendt (talk) 07:31, 1 September 2022 (UTC)Reply[reply]
the fact that we don't have a comprehensive and accessible way of knowing how a hook has been changed while on the Main Page is a whole other can of worms.
I just remembered that it's technically my can of worms, since I promised to do something about that with my modification detection script... theleekycauldron (talkcontribs) (she/they) 07:49, 1 September 2022 (UTC)Reply[reply]

theleekycauldron, i could easily be wrong about this, since i am still new to dyk, but i admittedly cannot seem to see the problem you describe, since the time one set is archived is the same as the time the next set is posted, regardless of what the posting schedule is. (i am ignoring the negligible time difference between the two edits, made during the same bot update.) whenever the posting schedule is changed, the last section heading will still contain the post time of the set on the main page at the time, so when the next update happens, that section heading will still have the correct post time of the set being archived.

i had assumed above that updates happened daily to simplify the illustration, but we can easily generalize this to any posting schedule. let us define ax and px as the archive time and post time of the xth set, respectively. clearly, ax = px + 1 since the bot archives one set and posts the next in the same update. technically, the bot posts both a section heading containing a date, and a bullet point in bold italics containing a utc timestamp, but in order to not complicate the illustration below, i will represent both with a section heading containing a utc timestamp. after n sets have been posted (and n − 1 sets have been archived), the current behaviour of the bot for the next two updates is as follows:

== an − 1 = pn ==
* (n − 1)th set of hooks
== an = pn + 1 ==
* nth set of hooks
== an − 1 = pn ==
* (n − 1)th set of hooks
== an + 1 = pn + 2 ==
* (n + 1)th set of hooks
== an = pn + 1 ==
* nth set of hooks
== an − 1 = pn ==
* (n − 1)th set of hooks

with this current method, the nth set of hooks is found under the heading containing an as its timestamp, so the hooks are archived according to their archive time. however, using the proposed method would result in the following behaviour:

* (n − 1)th set of hooks
== an − 1 = pn ==
* (n − 1)th set of hooks
== an − 1 = pn ==
* nth set of hooks
== an = pn + 1 ==
* (n − 1)th set of hooks
== an − 1 = pn ==
* nth set of hooks
== an = pn + 1 ==
* (n + 1)th set of hooks
== an + 1 = pn + 2 ==

in this case, the nth set of hooks is found under the heading containing pn as its timestamp, so the hooks are archived according to their post time. the bot makes no assumptions about the posting schedule and needs to make no calculations to determine what timestamp to put in the heading, as it simply relies on the fact that the archive time for any set will be the post time for the following set. in both implementations, when the nth set is being archived, the bot will post a heading with the timestamp an at time an.

by the way, i also agree with Gerda that the bot should archive the last version of a hook. the bot already posts the first version on the talk page, so that should be easily accessible if desired. dying (talk) 10:11, 1 September 2022 (UTC)Reply[reply]

@Dying: Oh, I see! So the change is that the archive time is simply posted below the hook set at the time of archiving, instead of above. Clever! I should think that simplifies matters quite a bit. theleekycauldron (talkcontribs) (she/her) 20:33, 1 September 2022 (UTC)Reply[reply]
I'm not sure who handles the bots, but if we can get some consensus here, perhaps a change like this could be implemented. Krisgabwoosh (talk) 21:09, 1 September 2022 (UTC)Reply[reply]
to me, it seems like there is at least some sort of consensus to implement the solution and see how it performs before deciding if it should be made permanent if it works. the majority that have participated in this discussion are interested in the idea, no one seems to be against it, and one editor has expressed skepticism that there was a simple solution, but has yet to comment on the solution proposed. also, the way the bot currently archives hooks is "a known issue, one that gets mentioned here once or twice a year", so i think it is agreed that something should be done if possible. however, as the one who proposed the solution, i don't think i should be the one to make the call (in the same way one shouldn't approve one's own hooks).
DYKUpdateBot is operated by Shubinator, and the bot's code is available here. Shubinator, what are your thoughts on the proposal above? i admittedly have not grokked all of your code (thanks for making it easily understandable!), but i think replacing
        if idx_this_date == -1:  # if there isn't, create a new section heading
            idx_insert_section = str_archive.find('\n', str_archive.find('<!--BOTPOINTER-->')) + 1
            str_archive = DYKUpdateBotUtils._insert_str(str_archive, idx_insert_section, str_section_heading + '\n')
            idx_this_date = idx_insert_section
        idx_this_date = str_archive.find('\n', idx_this_date) + 1
        return DYKUpdateBotUtils._insert_str(str_archive, idx_this_date, str_set_heading + '\n' + hooks_outgoing + '\n\n')
        idx_insert_section = str_archive.find('<!--BOTPOINTER-->')
        if idx_this_date == -1:  # if there isn't, append a new section heading after the hooks
            return DYKUpdateBotUtils._insert_str(str_archive, idx_insert_section, hooks_outgoing + '\n\n' + str_section_heading + '\n\n' + str_set_heading + '\n')
        return DYKUpdateBotUtils._insert_str(str_archive, idx_insert_section, hooks_outgoing + '\n\n' + str_set_heading + '\n')
should be sufficient to implement the idea.
incidentally, the proposed code is simpler because there is no need to find the appropriate section heading to write under if the heading already exists; under this implementation, the section heading will always already exist, and the correct place to insert the update will always be right before the bot pointer. the if statement is only used to check to see if a new section heading should be included after the hooks. the idx_this_date variable isn't used beyond that check, since the insertion point will be at idx_insert_section in any case. (also, i think the last three lines can be compressed into one line using the ternary operator (with the empty string as the alternative), but am not sure if that would improve or degrade readability.)
admittedly, i haven't tested this code at all, and think there might be an off-by-one error somewhere, so please look it over carefully. also, the bot pointer should be moved to the end of the archive, right before the navigation template at the bottom, before this version of the code runs. (the lead of the archive page should probably be updated too, but to the bot, that is just flavour text.) dying (talk) 15:27, 2 September 2022 (UTC)Reply[reply]
Thanks for reaching out with the note on my talk page. As BlueMoonset mentioned above, (and at the risk of raining on your parade) this is a perennial conversation, and having seen many of these conversations fizzle out, it's best to set similar expectations here. A few thoughts:
  • The code above will more-or-less work as expected, thanks for the concrete illustration!
  • When DYKUpdateBot is out of service, human admins archive DYK sets. Manually archiving like this would likely feel unintuitive.
  • Both the flow (reverse chronological to chronological) and associating timestamps with when the set appeared on the Main Page break "backwards-compatibility" from the historical archives, and may be confusing to future archive readers.
I'm not sure I sense (yet) a consensus to move forward - and ideally we want a consensus for the upsides that acknowledges the downsides, like those mentioned above. Shubinator (talk) 22:11, 2 September 2022 (UTC)Reply[reply]
@Shubinator: With regards to your third point, I'd be happy to write a one-time script that adjusts the already-settled main page archives. theleekycauldron (talkcontribs) (she/her) 18:52, 4 September 2022 (UTC)Reply[reply]
Unfortunately this is not as straightforward as reading the existing archives and flipping them around. Back in the day (before I joined DYK), hooks were added and removed from DYK a lot more fluidly, and not as part of full sets. Think of how ITN operates today. So an effort to adjust historical archives may require recreating the archives from scratch. Shubinator (talk) 00:42, 5 September 2022 (UTC)Reply[reply]
@Shubinator: Ah, I see what you mean. The archives can still be recreated from an script-based analysis of the history of T:DYK, though, right? theleekycauldron (talkcontribs) (she/her) 00:58, 5 September 2022 (UTC)Reply[reply]
This was DYKHousekeepingBot's original purpose, back in the day, so it surely can be done. There are a fair number of edge cases etc to watch out for though, and if memory serves, some manual massaging was required even after handling the edge cases. Shubinator (talk) 00:18, 6 September 2022 (UTC)Reply[reply]
I mean, that's not a bad opportunity to correct the record for a lot of hooks – hooks that get pulled or added in the middle of the sets we have now... theleekycauldron (talkcontribs) (she/her) 00:59, 5 September 2022 (UTC)Reply[reply]
I'm not sure we absolutely need to change the archiving method. Could we, as a first step, try to move the explanation closer to the dates? If we said "The dates are when the set was taken off the Main Page; for most hooks, the time mentioned one section below is when it was added" directly under the "Did you know" header, people might actually see it. Currently this is somewhere up the page, somewhere where my eyes do not see it especially on a wide screen. —Kusma (talk) 13:16, 5 September 2022 (UTC)Reply[reply]
The issue for me is that when checking the actual article's talk page, the DYK bot will link to an archive that does not include the actual hook in question. Krisgabwoosh (talk) 00:20, 6 September 2022 (UTC)Reply[reply]

Shubinator, no worries about raining on my parade! as an editor new to dyk, i was fully expecting to get shut down after my first comment, but have been pleasantly surprised that people far more experienced than i am have been entertaining my idea. admittedly, i had not previously addressed the other issues you had mentioned as i had figured that they were all minor details, not worth spending time discussing if the initial idea was to be rejected anyway.

also, many thanks for checking my code! it's a testament to your coding ability that i was able to easily propose a modification. i had figured that whether or not this idea could be easily implemented in the code was the main issue to address, but now that that has been resolved, let's discuss the other details.

regarding manual archiving, i do not think this will be a serious issue if it is implemented, as i believe the most difficult thing to overcome is simply unlearning how archiving has been done in the past. i would suggest moving the manual archiving instructions from the top of the archive page to the bottom (and leaving a comment at the top mentioning this), and adding an additional visual cue by including a note after the last section heading (and the bot pointer), visible on the archive page itself (and not just in the code), stating that the set of hooks to be archived under that section heading is currently on the main page. for example, if the archive page looked like this:

12:00, 12 September 2022 (UTC)
• ... that when construction began on the Kauai Plantation Railway, "nobody in the crew knew how to build a train track"?
13 September 2022 [edit]
00:00, 13 September 2022 (UTC)
... that the hooks that will appear here have yet to be archived, as they are currently on the main page?

and the code looked like this:

* '''''12:00, 12 September 2022 (UTC)'''''
* ... that when construction began on the '''Kauai Plantation Railway''', "nobody in the crew knew how to build a train track"?

===13 September 2022===
* '''''00:00, 13 September 2022 (UTC)'''''

   please add the set of hooks to be archived to the line immediately following the utc timestamp above,
      followed by the line "==={{subst:CURRENTDAY}} {{subst:CURRENTMONTHNAME}} {{subst:CURRENTYEAR}}==="
         if a new day has occurred,
      followed by the line "* '''''~~~~~'''''", which outputs a utc timestamp.

   this will ensure all times are based on utc time and accurate,
      and that a new utc timestamp is created containing the post time for the hooks currently on the main page.

   the entire update should be inserted above the bot pointer, so that this comment remains immediately after it.

   this page should be archived once a month.

please do not move this dummy hook or replace it with hooks to be archived.  hooks should be archived according to the instructions above.  thank you! -->* ''... that the hooks that will appear here have yet to be archived, as they are currently on the main page?''

{{Main Page topics|state=collapsed}}

then i think manual archiving would be pretty straightforward.

regarding conforming the current archives to the proposed format, i do not think this is a good argument against implementing a new way to archive hooks, as it appears to be a case of the sunk cost fallacy. on the other hand, as the bot continues to add links to the article talk pages that often target an incorrect location in the archive, technical debt is constantly being accumulated. in any case, theleekycauldron has graciously volunteered to code up something to automate the conversion, and even though converting some of the older archives may be tricky, i presume that converting the more recent archives should be pretty simple, since adding and removing hooks as full sets has been the norm for a while. (i went through the 2022 archives and found no glaring issues.) in addition, i would also be happy to volunteer to fine-tune any issues manually, even though i know that doing so may take some time.

in any case, even if there were a whole bunch of editors clamouring for this change, i don't think it should be implemented all at once. would it make more sense to, for example, convert this month's archive to the proposed format and then run the bot with the new code for a week to see what people think? of course, if people clearly wish to snow close this experiment at any point, everything will be reverted to the way it was, and i will be the one responsible for reformatting this month's hooks to conform with the previous style, since i was the one who started this whole mess. however, if the idea does not get snow closed after a week, i could then begin converting all the archives to the new format, and maybe after another week or so, we could raise the question of whether or not this proposal is a good idea. dying (talk) 01:45, 13 September 2022 (UTC) [reformatted code. dying (talk) 22:37, 19 September 2022 (UTC)]Reply[reply]

theleekycauldron, as i was thinking about how to implement something that rebuilds the archives while accounting for hooks that are pulled, it occurred to me that, since the bot currently simply archives the hooks as it finds them on the main page, a dyk notice on the talk page of an article whose hook has been pulled will still point to the archives, even though the associated hook isn't there, regardless of whether hooks are archived by post date or archive date. i am assuming that this is not the desired behaviour, as you mention the "opportunity to correct the record for a lot of hooks". should the pulled hooks be included in the archive in some manner? alternatively, should the dyk notices be removed or altered to be more accurate if the pulled hook is not archived? dying (talk) 01:15, 27 September 2022 (UTC)Reply[reply]
  • I realize it's a little late to be asking this, but does this particular applecart really need upsetting? EEng 04:25, 27 September 2022 (UTC)Reply[reply]

The "Did you know?" section should be sacred[edit]

(Moved from Talk:Main Page)

Maybe it is due to the fact that I was born in the previous century but when I started "eponymously" editing Wikipedia 15 years ago this idea was already cemented in my head: An "encyclopaedia" means learning about a great variety of subjects that are completely disconnected with each other. This was probably reinforced by the fact that, in printed encyclopaedias, the articles are listed alphabetically, so you are exposed to the above principle each and every time you look up something.

The "Did you know?" section must be a statement of identity as an encyclopeadia for Wikipedia. Certainly, Wikipedia is more than just an encyclopeadia but everything else is supposed to run second and in support of it. It would appear as common sense, as an unwritten rule, but apparently it needs to be articulated as Wikipedia rule: The "Did you know?" section must have the kind of variety that you find when you browse articles alphabetically. Nxavar (talk) 07:06, 22 September 2022 (UTC)Reply[reply]

Context: ALL items in the "Did you know?" section on 19 September 2022 were about the funeral of Elisabeth II of UK (link). That day Wikipedia did not look like an encyclopaedia at all. Nxavar (talk) 14:37, 22 September 2022 (UTC)Reply[reply]
Did You Know changes every day, sometimes multiple times in a day. It has plenty of variety. A snapshot of any particular instance is not a great way to gain an understanding of what shows up on DYK. CMD (talk) 14:50, 22 September 2022 (UTC)Reply[reply]
For the record, I'm pretty sure themed DYKs are relatively common. It was just particularly obvious due to all of the Main Page having a theme. As POTD co-ordinator, I was a little surprised to see how many parts of the Main Page had independently gone for it, but POTD themes happen all the time. Adam Cuerden (talk)Has about 8.1% of all FPs 01:17, 23 September 2022 (UTC)Reply[reply]
OK then, the consensus appears to be that the Main Page can be "themed". Those who find this an insulting piece of PR when it also covers the implicitly versatile "Did you know?" section (regardless of intentions, this is what it amounts to), do they have a choice? Can we have a secondary "Did you know?" section that is neutral and random, and then opt-in at our preferences? It can be a random selection of "Did you know?" items from the last year. Nxavar (talk) 07:03, 23 September 2022 (UTC)Reply[reply]
Nxavar, variety is a good principle, and observed most days, with a clear objective for prep builders to present DYK sets about different topics. Every once in a while, however, we make an exception to honour an event. Such as Beethoven's 250th anniversary of birth. This funeral attracted many world leaders, and had the highest interest for any featured article so far. If you don't want to see themed hooks, you can simply look at the DYK archive (linked below the hooks of a day) and browse in the archives from the beginning for things you want to learn about. I think to learn about the conductor who will move to Yale University was interesting beyond a certain event, no? Gerda Arendt (talk) 08:53, 23 September 2022 (UTC)Reply[reply]
And in any case, although the eight hooks in the set were all linked by a common underlying theme, there was still a lot of variety in the actual subject matter they covered. I spot a vehicle, an organist, a state visit, a painter, another vehicle (OK some repetition there I grant you), a funeral director company, a farm and a Chinese song. Lots of different topics that are only really loosely connected to each other...  — Amakuru (talk) 09:06, 23 September 2022 (UTC)Reply[reply]
One of the principles of objective article writing is to not tell the reader what is interesting, important, etc. In Wikipedia, it is enshrined in the WP:MOS. I understand that the Main Page is treated differently, so my proposal is about limiting the theming tendency. Granted, the letter of MOS:NOTED is not violated, but I would very much prefer a "Today is a special day because this happened" than seeing content about that event all over the Main Page. Nxavar (talk) 09:08, 23 September 2022 (UTC)Reply[reply]
One of the principles of DYK is letting a reader know something is interesting. If something isn't interesting, that is grounds for rejection from this process. The aim of the main page hooks is to get people to click on articles, not to be article-writing themselves. CMD (talk) 10:00, 23 September 2022 (UTC)Reply[reply]
Then, maybe it is a good idea to allow readers to opt-out of the DYK section. Nxavar (talk) 10:27, 23 September 2022 (UTC)Reply[reply]
Technically speaking, you can opt-out of any part of the Main Page by editing the stylesheet of your preferred style. Right now, it is a privilege reserved to those who know some CSS. Nxavar (talk) 10:38, 23 September 2022 (UTC)Reply[reply]
Any reader can not read the DYK section. It doesn't require CSS. CMD (talk) 11:28, 23 September 2022 (UTC)Reply[reply]
The thing is, until you read it, you don't know if reading it is a good idea or not. And applying self-discipline so that you never read it, is kind of ridiculous and error-prone. Completely hiding it provides a certain comfort, anyway. Nxavar (talk) 11:41, 23 September 2022 (UTC)Reply[reply]
Maybe we should have had a trigger warning. EEng 16:31, 25 September 2022 (UTC)Reply[reply]
I agree. English Language Wikipedia is not English Wikipedia. It is unfortunate to have a complete focus on one event that is also intrinsically connected to oppression and colonialism. I do not think Wikipedia is following the 5 Pillars when platforming an event like this. Traanarchist (talk) 18:39, 24 September 2022 (UTC)Reply[reply]
Phoeey! Johnbod (talk) 20:04, 24 September 2022 (UTC)Reply[reply]
+1. Really, what one-dimensional dopiness. EEng 16:31, 25 September 2022 (UTC)Reply[reply]
I think that DYK has a slightly different goal than the rest of the encyclopedia: we are here to educate by content, but also to educate by hooking readers in. On a day where the world's eyes are turned to a single event, an event we had ten days to prepare for, it presents to us a unique opportunity. I'm sure we could've gone for broader consensus, but I think the main point here is that we had an opportunity to educate readers on topics we thought were timely and already in their minds – despite a somewhat conflicted legacy, I think we did a good job upholding our sacrality. theleekycauldron (talkcontribs) (she/her) 23:04, 24 September 2022 (UTC)Reply[reply]
Isn't sacrality something about the anatomy? EEng 16:31, 25 September 2022 (UTC)Reply[reply]
"Upholding your sacrality" might make a good euphemism for CYA. —David Eppstein (talk) 04:45, 27 September 2022 (UTC)Reply[reply]
It is not a hook if you leave people no choice. When the FA, POTD, and ALL the did you know items are related to the funeral of Elisabeth II of UK, we are basically forcing people to pay attention to Elisabeth II of UK. Nxavar (talk) 16:09, 25 September 2022 (UTC)Reply[reply]
Forcing people to pay attention to Elisabeth II
forcing people to pay attention to Elisabeth II – Hyperbolic, much? EEng 16:31, 25 September 2022 (UTC) P.S. If it was really true that you'd been forced to pay attention, you'd probably have learned to spell Elizabeth correctly.Reply[reply]
  • I agree with the premise of this section, that we should always strive to make DYK random and generally unrelated facts. BD2412 T 04:53, 27 September 2022 (UTC)Reply[reply]
    Why? Themes are fun. EEng 17:55, 28 September 2022 (UTC)Reply[reply]
  • If the OP just wants random articles then they can get this by clicking on Random article in the menu. The main page sections are expliclity not random as they all have some theme – OTD does anniversaries; ITN does news, DYK does novelties and so on. — Preceding unsigned comment added by Andrew Davidson (talkcontribs) 19:20, 2 October 2022 (UTC)Reply[reply]

Donations are everything[edit]

It just clicked. Today is currency day and we have a gallery of USD. The Main Page should cater to its more affluent and donation-prone readers, I guess. Nxavar (talk) 07:18, 28 September 2022 (UTC)Reply[reply]

The community has no control of, not any connection to the donation messages from the WMF. We aren't linked. Lee Vilenski (talkcontribs) 08:34, 28 September 2022 (UTC)Reply[reply]
You mean that the viewership of the Main Page is not linked to the viewership of the donation messages? How can you say "We aren't linked" when the WMF funds Wikipedia and uses its Main Page to draw funds from the public ?!? Nxavar (talk) 09:35, 28 September 2022 (UTC)Reply[reply]
The WMF does not use the main page, the main page is under the control of the community. As an aside, this is not the POTD talkpage, you will need to raise your concerns there. CMD (talk) 14:39, 28 September 2022 (UTC)Reply[reply]
  • Well this subthread got awful confused awful fast. EEng 17:55, 28 September 2022 (UTC)Reply[reply]
  • To get back on track, I believe we have a case of social exclusion due to poverty. Should WP only focus on themes that attract the interest of middle class? We should care about him too:
A homeless man in Paris.
Nxavar (talk) 06:49, 29 September 2022 (UTC)Reply[reply]
Nxavar: so DO something about it! Write an article that would be of interest to homeless people (not sure they read Wikipedia, but we can hope) and submit it to DYK! It's no good complaining about the fact that nobody else is writing such articles if you're not willing to write them yourself. MeegsC (talk) 08:47, 29 September 2022 (UTC)Reply[reply]
It is not about whether articles about poverty, or what can lead people to poverty (e.g work accidents, mental issues) exist. My complain is not that Wikipedia does not have such content. However, they do not receive nearly as much coverage, let alone theming, as more "hip" subjects, such as the Queen dying, today's aniversary of the Mandate of Palestine (lets fight antisemitism), LGBTQ stuff etc. Nxavar (talk) 08:54, 29 September 2022 (UTC)Reply[reply]
Nxavar, they don't have such coverage because nobody champions them. October 17 is the UN-sponsored International Day for the Eradication of Poverty. An article about that could certainly be a DYK post for the day. That would be the "equivalent" to Mandate of Palestine, which is one listing in "on today's date" – hardly a "theme". With more leadtime, you could have proposed a themed day for it; I don't think two weeks would give you enough time to organize for this year. But next year is certainly a possibility. MeegsC (talk) 09:06, 29 September 2022 (UTC)Reply[reply]
Did you notice the POTD? Also, my position is that there should be no theming for the DYK. Nxavar (talk) 09:10, 29 September 2022 (UTC)Reply[reply]
So does this mean that you're NOT planning to submit articles to change the conversation? As I said before, don't complain about it if you're not willing to do the work to change it! All of us who submit articles to DYK are writing about things we are passionate about. You can't expect somebody else to take up your torch. You can't expect volunteers to write about things "because they should". That's not how it works. If this is what you're passionate about then write about it! MeegsC (talk) 09:23, 29 September 2022 (UTC)Reply[reply]
That is exactly the problem: Passions are good, but sometimes they get out of control. Nxavar (talk) 09:28, 29 September 2022 (UTC)Reply[reply]
You posted you believe we have a case of social exclusion. If you believe so, then please write some material that helps include whoever is being excluded, and we can include it in DYK. Otherwise, there's not much we can do about it here, DYK is not a place where content is created. For POTD, you are again in the wrong place, as WT:DYK has no influence on POTD choices. CMD (talk) 10:15, 29 September 2022 (UTC)Reply[reply]

Queue 4: Bhadun[edit]

... that according to, in 2022, the residents of Bhadun can get US$5.30 by renting a wife per day for shooting?

This isn't very clear to me; I think it means that women in Bhadun can earn $5.3 a day by acting as an extra in a film shooting, where they are playing people's wives; but lacking source access, I cannot confirm it. Some copy-editing is needed. @Mehediabedin, Sammi Brie, and RoundSquare:. Vanamonde (Talk) 04:47, 23 September 2022 (UTC)Reply[reply]

@Vanamonde93: Yes you are right on track. But slight difference - They don't act as wives in series, they are actually housewives of the residents of the village. They playing for extra for any role. I am not good at copy-editing but I will do my best. Do I need to c/e hook related passage or the whole article? Mehedi Abedin 04:57, 23 September 2022 (UTC)Reply[reply]

I purposely left the ambiguity in as part of the hook (though certainly it needed editing in the article, which I carried out). Sammi Brie (she/her • tc) 05:03, 23 September 2022 (UTC)Reply[reply]
The shooting must be explained that it is not real. This is not April Fool's and death should not be used as a hook. Nxavar (talk) 07:11, 23 September 2022 (UTC)Reply[reply]
I think if the hook is going to be a little ambiguous on purpose, it needs to go in the quirky slot. Otherwise, I would suggest "that according to, in 2022, the residents of Bhadun can earn US$5.30 per day by being hired as extras for film shootings? The current formulation implies the residents are doing the renting, which isn't correct. We could potentially also drop the first half, for a punchier hook. Vanamonde (Talk) 13:56, 23 September 2022 (UTC)Reply[reply]
@Vanamonde93: That make sense but males don't get US$5.30 for film shootings, only wives of village residents get that. So we can replace "residents" with "wives of the male residents" or something like that. Or we can use better words. Mehedi Abedin 17:08, 23 September 2022 (UTC)Reply[reply]
@Mehediabedin: How about "In 2022, married women living of Bhadun can earn US$5.30 per day by being hired as extras for film shootings?" That's punchy, and appears to be accurate. Vanamonde (Talk) 15:58, 24 September 2022 (UTC)Reply[reply]
What in the world is a woman in Bhadun going to do with 5 US dollars? EEng 04:58, 27 September 2022 (UTC)Reply[reply]
@Vanamonde93: Agree. This is better. Mehedi Abedin 16:07, 24 September 2022 (UTC)Reply[reply]
Thanks, I'll implement the change. Vanamonde (Talk) 16:23, 24 September 2022 (UTC)Reply[reply]
  • @Vanamonde93 and Mehediabedin: I just noticed this hook in the queue, and I'm not sure it's actually consistent with what the source says. I don't speak Bangla, but relying on Google Translate here, the cited article starts with Need a wife? Get it for rent and then The role of the village wife is necessary for the drama? It is possible to get a wife by paying 500 rupees. I think the hook thus fails verification on two counts: Whether the wife gets the money, and what role the wife has in the shoot. Both "earn" and "extras" seem to be assumptions. (Also, why are we using USD here? And is "shooting" valid in South Asian English, or should this be "shoot" as it would be in AmEng?) -- Tamzin[cetacean needed] (she|they|xe) 20:37, 24 September 2022 (UTC)Reply[reply]
    @Tamzin: I don't read Bangla either. I presume the nominator does: I'd like them to opine on the translation. Having looked at the translation, I'm concerned about a slightly different aspect; the 500rs comes not from the article's author, but an interviewee. As such it's not usable directly. The "extras" I'm not actually concerned with; I think it's implied pretty clearly; but we could amend that to "appearing in a film shooting" if needed. Vanamonde (Talk) 20:43, 24 September 2022 (UTC)Reply[reply]

@Tamzin: Sorry I totally missed that part. And I thought that it will be better to use USD because Wikipedia is an international platform. And for the english part, in Bangladeshi English we know "filming" as "shooting" but we also use "shoot". Then how about this if I write "In 2022, production companies can get women for film shooting from Bhadun for the role of wife for US$5.30 per day?" Mehedi Abedin 20:50, 24 September 2022 (UTC)Reply[reply]

Maybe: ... that film production companies in Bhadun, Bangladesh, can hire a local woman as an extra for ৳500 per day? Something like that? I won't begrudge the "extra" point, but it's not at all clear from the article whether it's the women or their husbands who get paid. And I'm not sure what the precedent for currencies on the main page, but to me what makes sense is either BDT only, or BDT with USD in parentheses. But I'll defer to the DYK experts. :) -- Tamzin[cetacean needed] (she|they|xe) 21:08, 24 September 2022 (UTC)Reply[reply]
@Tamzin: That's okay except "film production companies" because they only shoot drama series here. But okay if there isn’t distinction between film production companies and drama production companies. Mehedi Abedin 21:51, 24 September 2022 (UTC)Reply[reply]
No objection to "television" rather than "film". -- Tamzin[cetacean needed] (she|they|xe) 21:53, 24 September 2022 (UTC)Reply[reply]
Thanks both, I'm going to substitute Tamzin's hook with "television" in place of "film". Vanamonde (Talk) 22:16, 24 September 2022 (UTC)Reply[reply]

DYK tools[edit]

I have a DYK button in the horizontal toolbar and one in the left vertical toolbar. Yet both usually indicate my articles do not qualify for DYK due to length issues. I then ignore the advice and nominate anyway, as I know the article is long enough. If anyone experienced the same or similar, it might be worth to check and probably fix it. And if someone knows of working DYK button of which I am not aware of, I'd be glad to know about. Paradise Chronicle (talk) 21:31, 24 September 2022 (UTC)Reply[reply]

Hard to see what you mean without examples, but if you're talking about Nataša Pirc Musar, the tools do not pick up a length expansion as it was moved from draft space. CMD (talk) 21:43, 24 September 2022 (UTC)Reply[reply]
It is not about Natasa Pirc Musar, but more a general thing. I use User:SD0001/DYK-helper.js with which at the Reindorf Review, that was created today and is sure long enough, the result appears in red and says Prose size:68 words, 451 characters.
At Guido Chigi Saracini which was created in 2 August 2022 and their last edit was on the 16th August, the result appears in green script: Prose size: 228 words, 1518 characters.
I interpret green script that an article qualifies and red script that it doesn't qualify which is maybe a cause of the question mark beside the red script stating that an article needs 1500 characters of prose size for DYK which the red script says it doesn't. Paradise Chronicle (talk) 17:08, 25 September 2022 (UTC)Reply[reply]
@Paradise Chronicle No comment on the script you mention, but checking with User:Shubinator/DYKcheck I get much higher numbers for those articles. CMD (talk) 15:07, 27 September 2022 (UTC)Reply[reply]

Queue 5: Univel[edit]

  • ... that Univel was an early-1990s attempt to compete with Microsoft on the desktop, but one industry consultant said that "they're dreaming"?

I know there's been some back-and-forth about this hook already, but the current version strikes me as ungrammatical. Can we attempt to find a cleaner sentence? @Wasted Time R, Narutolovehinata5, and CSJJ104: Vanamonde (Talk) 00:43, 25 September 2022 (UTC)Reply[reply]

How about changing the last part to: said of Univel's goal, "they're dreaming"? Wasted Time R (talk) 11:48, 25 September 2022 (UTC)Reply[reply]
Wouldn't that be redundant? Maybe just say "the company's goal" instead? Narutolovehinata5 (talk · contributions) 14:08, 25 September 2022 (UTC)Reply[reply]
Okay with me. Wasted Time R (talk) 14:19, 25 September 2022 (UTC)Reply[reply]
Seems reasonable to me, making the substitution. Vanamonde (Talk) 17:23, 25 September 2022 (UTC)Reply[reply]
Just a heads up that queue 5 is up next, but hasn't been approved yet (@Vanamonde93). Olivaw-Daneel (talk) 00:45, 27 September 2022 (UTC)Reply[reply]
Thanks for the reminder. Vanamonde (Talk) 02:37, 27 September 2022 (UTC)Reply[reply]

Langley Hawkins murder case[edit]

How is that possible DYK article is not linked to WD? Eurohunter (talk) 14:17, 27 September 2022 (UTC)Reply[reply]

Are you referring to Wikidata? It's a pretty new article. As far as I know, Wikidata is usually after the creation of an article, and done so by volunteers at Wikidata. Or ... you could go over to Wikidata and set it up yourself. — Maile (talk) 14:34, 27 September 2022 (UTC)Reply[reply]
It's not English Wikipedia's job to link everything to Wikidata, and it certainly isn't a requirement for a DYK for it to be linked. If a Wikidata page exists for it, then you can always link it yourself (as this is the encyclopedia that anyone can edit), and if one doesn't exist, I'm sure someone/a bot will create one in time (not sure the process for it though, as that's done on Wikidata, not here). Joseph2302 (talk) 14:45, 27 September 2022 (UTC)Reply[reply]

Prep 1 - Earthrise[edit]

@Hawkeye7 and Theleekycauldron: I did not do a swap on the current image, but If you all are interested, I created a cropped version so the earth is a teeny bit bigger:


— Maile (talk) 21:44, 27 September 2022 (UTC)Reply[reply]

I have switched to the cropped version. Hawkeye7 (discuss) 21:51, 27 September 2022 (UTC)Reply[reply]
This is a historic image. I'm not thrilled with the idea of a crop. There's clearly no legal impediment to creating a derived work, but it seems inappropriate from a historical and artistic point of view. -- RoySmith (talk) 23:30, 27 September 2022 (UTC)Reply[reply]
You might be interested in the documentation of the original image at Commons, "This is a retouched picture, which means that it has been digitally altered from its original version. Modifications: rotation, cropping, level adjustment, dirt removal. This work is based on a work in the public domain. It has been digitally enhanced and/or modified. This derivative work has been (or is hereby) released into the public domain by its author, Earthsound. This applies worldwide" National Aeronautics and Space Administration is the source. Earthsound is the person or entity who uploaded it at Commons. — Maile (talk) 00:32, 28 September 2022 (UTC)Reply[reply]
Anyone interested might what to see for how the original looked. CSJJ104 (talk) 18:19, 1 October 2022 (UTC)Reply[reply]

We are at 120, but...[edit]

@DYK admins: , we are at 120 approved nominations, but with only one filled queue and three filled preps. I think this means that we should stay at one a day for the present and fill some preps and queues as changing to two a day would put more pressure on prep builders. Also if we change to two a day at four filled preps and queues and then back to one a day at ten filled preps and queues, that leads to much more frequent changes up and down. TSventon (talk) 07:33, 30 September 2022 (UTC)Reply[reply]

Absolutely agree that this approved nominations number is artificially high since we don't have enough queues and preps filled. When the number filled stays relatively consistent, the switches at under 60 and 120 and over work; when there's significant variation in the numbers filled, we change more often than it makes sense. If six more preps were filled, we'd be at around 75 approved, nowhere near where a changeover would take place. BlueMoonset (talk) 00:32, 1 October 2022 (UTC)Reply[reply]
I agree – sorry that I've been away, the meatspace has been tumultuous. Just got consistent wifi access, so that's hopefully a return to normal activity soon. theleekycauldron (talkcontribs) (she/her) 01:26, 1 October 2022 (UTC)Reply[reply]
Another consideration might be the fact that some of the articles on the approved list have had problems found by the promoter. These are generally fixed quickly, but it does suggest that the number of approved articles is higher than it should be. CSJJ104 (talk) 18:16, 1 October 2022 (UTC)Reply[reply]

One filled queue[edit]

@DYK admins: and Valereee we are down to one filled queue. Your help to move preps to queues is appreciated. TSventon (talk) 08:13, 30 September 2022 (UTC)Reply[reply]

Two more queues filled. Thanks for the ping. — Maile (talk) 11:06, 30 September 2022 (UTC)Reply[reply]

Prep 5 Bombing of Mokha[edit]

I updated this hook slightly to remove the "more than" as the article seems to suggest 120 dead is the upper limit. Pinging LordPeterII, Mhhossein and AzureCitizen in case I missed something. CSJJ104 (talk) 18:05, 1 October 2022 (UTC)Reply[reply]

Minor problem i'm having.[edit]

So im new to DYK reviewing and i'm noticing this problem i'm having where every time i review a nomination the message "{{DYKsubpage |monthyear=September 2022 |passed= |2=" appears above the template. Is there any way I can fix this? Onegreatjoke (talk) 21:31, 1 October 2022 (UTC)Reply[reply]

Hey there, @Onegreatjoke! Make sure to close your {{DYK checklist}} templates :) theleekycauldron (talkcontribs) (she/her) 21:37, 1 October 2022 (UTC)Reply[reply]
Thanks for the help! Onegreatjoke (talk) 21:39, 1 October 2022 (UTC)Reply[reply]

Grammatical issue in Felipes hook[edit]

Howdy! My original hook was modified from "... that the lichen genus Felipes is named for the fruiting structures of its sole species, which are said to resemble a cat's paw?" to "... that the lichen genus Felipes is named for its fruiting structures, which are said to resemble a cat's paw?". The problem is, a genus doesn't have fruiting structures! I understand the desire to shorten hooks, but I fear this one no longer makes grammatical sense. Thoughts? MeegsC (talk) 09:37, 2 October 2022 (UTC)Reply[reply]

I don't see why a genus can't have a characteristic if a species can have one, but if there is a need to change the hook I suggest simply substituting in the species name. CMD (talk) 09:44, 2 October 2022 (UTC)Reply[reply]
Because a species has structures. A genus is a collective noun for a group of species. Its members have structures, but the collective noun itself does not! MeegsC (talk) 10:09, 2 October 2022 (UTC)Reply[reply]
But a species is a collective noun for a group of individuals! We could talk about the wings of birds, or the scales of fish, which are even larger groups. CMD (talk) 10:16, 2 October 2022 (UTC)Reply[reply]
Fine. If everybody else is okay with it, I'll just stew in my own corner. ;) MeegsC (talk) 11:11, 2 October 2022 (UTC)Reply[reply]

Change to the {{DYKsubpage}} template[edit]

A lot of the time, when I'm scrolling through building sets, I get bogged down by super-long discussions that haven't finish and take up quite a bit of scrolling space. Can we please add some code to the template, in between <includeonly> tags, that adds a {{Hidden}} template when the {{PAGESIZE}} exceeds 20,000 bytes? theleekycauldron (talkcontribs) (she/her) 23:47, 2 October 2022 (UTC)Reply[reply]

Kind person needed[edit]

who has the prose size/5x expansion tools installed, to check if Tibetan art has been 5x expanded since this edit, or how short it is. I'm afraid i hate adding yet more stuff to my computer. Many thanks, Johnbod (talk) 14:21, 3 October 2022 (UTC)Reply[reply]

The diff has 4045 bytes; the current revision has 15K. Unfortunately, that's only a 3x expansion. Sorry. Ritchie333 (talk) (cont) 14:38, 3 October 2022 (UTC)Reply[reply]
Johnbod, when I run DYK check now, it says, Assuming article is at 5x now, expansion began 109 edits ago on September 26, 2022. As I type this, a nomination would only be a few hours late; I think under the circumstances it should be allowed since the expansion was completed on October 3 and was therefore within the requirements of a seven-day 5x expansion, as long as you complete the nomination as soon as possible. Best of luck! BlueMoonset (talk) 03:24, 4 October 2022 (UTC)Reply[reply]
Many thanks both! Template:Did you know nominations/Tibetan art went up some 12 hours ago, as I thought I could close the gap. Johnbod (talk) 04:03, 4 October 2022 (UTC)Reply[reply]

One filled queue 4/10[edit]

@DYK admins: we are down to one filled queue. Your help to move preps to queues is appreciated. TSventon (talk) 00:32, 4 October 2022 (UTC)Reply[reply]