Wikipedia talk:In the news

This is an old revision of this page, as edited by Usernamekiran (talk | contribs) at 17:24, 16 November 2023 (→‎Archive of ITN postings: question). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


Latest comment: 10 months ago by Usernamekiran in topic Archive of ITN postings

Archive of ITN postings

Hello. Is there an archive that contains all blurbs that have been posted to ITN? I am aware that ITN/C has an archive, but that also includes all unsuccessful nominations, which makes it harder to find just the ones that made it to the main page. The closest thing I am aware of to what I want is the revision history of Template:In the news, but that's not in an easily digestible format. 98.170.164.88 (talk) 16:33, 7 September 2023 (UTC)Reply

No so far. People typically either use the search button in the archives or the browser's own search bar to find or pinpoint posted items (e.g. by typing "posted" in any given archive which makes it easier somewhat). Brandmeistertalk 19:13, 7 September 2023 (UTC)Reply
I wonder if there's an automated bot we could request to run across a date range that would create a list of blurbs and the date they were added, as long as there is a large enough character diff in between revisions. Then we can create such archives (even if not perfect) and have monthly new archive pages. Masem (t) 12:56, 8 September 2023 (UTC)Reply
I don't have the energy myself, but building such an archive does seem like a worthwhile project. Does the ITN recognition template we (sometimes remember to) put on article talk pages have a category associated with it? That could help too. --Jayron32 13:01, 8 September 2023 (UTC)Reply
I've tossed a request at Bot Requests for this. Masem (t) 13:15, 8 September 2023 (UTC)Reply
Thanks for doing that! It would be quite useful to be able to see all the stories that appeared on ITN in a given week/month/year or to search through the full archive. (Discussion link for convenience: Wikipedia:Bot requests § Creating archive page for added ITN items, permalink.) 98.170.164.88 (talk) 04:10, 9 September 2023 (UTC)Reply
For those following this, there is a test version of a bot producing searchable output from when things were added to ITN. It doesn't see the diff in changes to blurbs from the addition of blurbs, but I think that's something we can deal with. I would ask those to look and comment there if they see anything else. Otherwise I was going to this bit to create by month archives from past changes, and then run once a month to create new monthly ones. Masem (t) 17:38, 11 September 2023 (UTC)Reply
I think this is a great idea. It has good statistical/analytical implications as well to have the individual blurbs that have been posted, as we can then start tracking or tagging these by region or subject matter. Duly signed, WaltClipper -(talk) 13:51, 12 September 2023 (UTC)Reply
Yes, we have a category for articles with the ITN talk template called Category:Wikipedia In the news articles. Scientia potentia est, MonarchOfTerror 14:32, 8 September 2023 (UTC)Reply
Yes great idea but we will have a problem what will the category Name going to be that's the problem we will have 41.114.234.69 (talk) 18:11, 3 November 2023 (UTC)Reply
There is also Wikipedia:Main Page history, though that is for all of the Main Page, not just ITN. -- Patar knight - chat/contributions 01:34, 9 September 2023 (UTC)Reply
  • @Masem the bot does see the diff, that's how it extracts the editor's username, and timestamp   If you guys need a diff, then I think this would be possible too. But it will clutter the archive page. Kindly let me know if you guys have any suggestions or requests regarding the archive. We should discuss the technical side at WP:BOTREQ#Creating_archive_page_for_added_ITN_items to keep it in one place/ease of access. —usernamekiran (talk) 18:51, 11 September 2023 (UTC)Reply
    @Usernamekiran, you could make the timestamp into a piped link to the diff, e.g. [[Special:Diff/1174852896|2023-09-11T03:03:52Z]]. Then it would be clickable but wouldn't take up any extra visual space. Edit: You could also do that with the verb ("added", "removed", "modified") instead of the timestamp, which may even be better. 98.170.164.88 (talk) 01:20, 12 September 2023 (UTC)Reply
  • a question: is <small> used in ITN? —usernamekiran (talk) 16:41, 15 September 2023 (UTC)Reply
    @Usernamekiran: Best I know, not in normal postings to the template. The only special text is the bold (for featured article) and italics for the picture reference if used. Masem (t) 18:16, 15 September 2023 (UTC)Reply
  • @Masem: Hello. The program is almost finished. so far:
    • If a new line begins with *[[ or * [[ then the bot considers it as a recent death. If it begins with <!--, it considers the entry as news.
    • the bot excludes lines beginning with | (if there is a white-space after the pipe)
    • based on the date of first addition (from diff), the program adds the entry to header of corresponding date, including diff, editor, and time. If a news entry is updated (eg death toll), then the bot adds the new updated entry below the original entry.
      • in case the entry was first added on 30 September, and death toll was updated on 2 October, then the update entry will go in September's page.
    • so far the only issue is with "currentevents". They are being treated as normal news. But if we change MOS, then it can be resolved. eg, if current events begin with *<!--CE Mar 09 2022-->, then bot can differentiate between ongoing events, and news.
    • I created four archive pages with that logic: complete March 2004 (starting from second entry, as there is no diff for creation. we can add it manually), complete April 2004, few days of May 2004. I was paying my attention to other things, so I did not realise the timestamps in headers. I have corrected the timestamps in archive of Sept 2023.
    • as there were no particular standards/MOS back in the day, the archive pages of the early days will look a bit odd.
    • please let me know if you want more features/functionalities. I think one request is to add wikilink to archive page's day header (eg "September 23"), to corresponding date header of Wikipedia:In the news/Candidates. Is that correct?
  • I think we should keep the discussion here, so that it will be visible to more editors that are involved in ITN stuff. —usernamekiran (talk) 17:36, 1 October 2023 (UTC)Reply
    The archive from September 2023 looks very clean and organized, I like it! The bottom of the March 2004 archive is somehow formatted wrong, though. I think you might need to add code to balance out unclosed HTML tags so they don't affect later entries.
    I'm not sure what's going on with the images. The March 2004 archive has them but the September 2023 one doesn't. Personally I'm fine with it either way as long as it's handled consistently.
    Great work. 98.170.164.88 (talk) 19:44, 2 October 2023 (UTC)Reply
    @98.170.164.88, as ITN was started in March 2004, there were no guidelines. The bottom of March 2004 is because of that. Apparently, "float right" was used with the entries. The tags were closed properly, but the bot gets entries for archival from diffs, the tags were misplaced. I dont know when the styling of ITN was formalised/stabilised, but from that point the archive pages would be neat. I have intentionally It is also very difficult to go through all the revisions and check for inconsistencies, and create code/exceptions for that. The better approach would be to first create all the archive pages, and then repair the archive pages with AWB, and similar tool. Regarding images, I thought they were not necessary, I think I could add the pictures.
    About Masem's functionality regarding linking the archive date header to headers of "Wikipedia:In the news/Candidates/archive", I am not sure if it would be possible, or how to approach it. The blurbs/entries are not always added to template:ITN on the same day as of they are posted/nominated at the candidates page. So the headers' date would be a mismatch. —usernamekiran (talk) 23:31, 2 October 2023 (UTC)Reply
    after observing source of ITN another time, adding images to the archives will not be good idea as there would be a lot of mismatches (caption of older picture going to newer one, or other way around), and breakages as well. As we are providing diffs, I think if someone wants to see particular image(s) then it would not be very difficult. —usernamekiran (talk) 23:39, 2 October 2023 (UTC)Reply
    Actually, there's just an easier solution than the diffs and that's just to have the header of these results pages link to the ITNC archives, like Wikipedia:In the news/Candidates/April 2005. That simplifies that - if the user needs to see a more detailed edit history they can then do a normal page search to the period themselves. Masem (t) 00:21, 3 October 2023 (UTC)Reply
    @Usernamekiran: Omitting images is fine by me, but for some reason the March 2004 archive has them included (maybe because the code used was "image:" instead of "file:"?). As for the HTML issue at the bottom of the page, there definitely is an unclosed tag in the wikicode that's affecting all subsequent entries. This section has three <div> tags and no </div> tags. As a result all blurbs that follow, even ones that never had anything to do with the float-right code (e.g., the story about Korea Train Express), are being affected. You're probably right that the best solution is probably to create the archives first and then work out the problems like this, as there may be a lot of different kinds of issues and writing code to handle them may take more effort. Btw, I notice that in the March 2004 archive a lot of blurbs are wrongly classified as RDs. In the September 2023 archive this problem does not occur.

    Regarding references to ITN/C: As a very simple solution that would save coding effort and capture most of the value, I think it's sufficient to just have one link at the top of the monthly archive your bot generates, where it currently says "ITN archive page for September 2023", that links to the associated ITN/C monthly discussion archive (maybe with clickable arrows going to the next and previous ITN and ITN/C discussion archives as well). I think this is Masem's idea directly above. Actually, it's perhaps even a better idea to make an "ITN archive header" template, so that if we decide the header format needs to be changed it can be done in one place instead of requiring every archive page to be updated.
    If you want a more complicated solution that I'm not sure is actually worth implementing, but might be slightly more convenient, here's my idea: handle it on a per-story basis, instead of a per-day basis. Every time a new story is encountered in the ITN page history (i.e., only when "added"), check the month's ITN/C discussion page (and if needed, the previous month's), find where the bolded article or RD name is linked/mentioned, and get the closest section name above that. If the link doesn't occur anywhere in the ITN/C archive, then skip it I guess. So then the output might look like:
    Again, not sure it's worth the coding effort, but it seems technically feasible to implement. 98.170.164.88 (talk) 00:36, 3 October 2023 (UTC)Reply
    @98.170.164.88 second one is actually an impressive solution! I am okay with coding it, but I am not sure if it would be well taken at "bot request for approval", I mean, that is a lot of resources for an archival page (as the bot would run from toolforge/wikimedia server). So our best option would be to go with the first one. —usernamekiran (talk) 00:50, 3 October 2023 (UTC)Reply
    in older archives, the images are being added because I am excluding the images by excluding the lines that begin with | This method also excludes a lot other unnecessary stuff. In current days, the images are included in another template "Main page image/ITN", and it has a pipe in the beginning, similar to an infobox. —usernamekiran (talk) 01:40, 3 October 2023 (UTC)Reply
  • update: kindly check the following archives, this is how the bot will create them, unless there are some other requirements. November 2022, December 2022, and partial January 2023. —usernamekiran (talk) 20:43, 17 October 2023 (UTC)Reply
    @Masem, Brandmeister, Jayron32, WaltCip, MonarchOfTerror, and Patar knight: do you have any suggestions, or should I finalise this format/bot? —usernamekiran (talk) 20:54, 17 October 2023 (UTC)Reply
    I should have checked this one earlier — but was busy offwiki. Do we think this is more valuable if we present a snapshot of how the ITN box looked on a particular day? If there was a reason we went with this — please ignore my comment?
    On an unrelated note, given that we have this granular data (which is great btw) can I ask for a separate request of dump of a csv, or a table with the following fields — article name, posted timestamp, rolled-off timestamp. Some of us were doing this manually, but, would be great to have a script do this! Thanks! Ktin (talk) 20:54, 17 October 2023 (UTC)Reply
    @Ktin: Hi. I am not sure where to get the data from (article name, posted timestamp, rolled-off timestamp). also, you said that was done before. Can you please provide a link, or example edit as to what you want. Sorry, I am not much familiar with the ITN stuff. Also, your userpage is very interesting. —usernamekiran (talk) 21:03, 17 October 2023 (UTC)Reply
    Thanks much! You already have all of that information in those links that you shared earlier — E.g. “RD <Article name> posted by <admin name> on <timestamp>”, “RD <Article name> removed by <admin name> on <timestamp>”. So, in these two examples the first time stamp is the “posting timestamp” and the second one is the “roll-off timestamp”. Ktin (talk) 21:29, 17 October 2023 (UTC)Reply
    @Ktin: oh, got it. But the thing with this bot task is, if an ITN entry/blurb/RD is updated or removed, then it looks for the matching entry in current month's archive, and in previous month's archive. ie, when a current event/RD is added, we get only "RD <Article name> added by<diff> <admin name> on <timestamp>". We do not get the corresponding "updated by"/"removed by" entry for a couple of days. So we cant use the same program for the task you suggested. However, a separate task can be created. So to create the dump, we will have to wait for at least two months (I think). I mean, in October, we should create create dump for August, and previous months, but not September, and later months. But given the simplicity (everything will be present on the archive page), a user script would be easy to create, and a better option. —usernamekiran (talk) 15:44, 19 October 2023 (UTC)Reply

Let's double the number of recent deaths that we show

Make it two lines, for a total of ten people. Reason: I suspect that even more people will die in the future than have in the past. BD2412 T 23:40, 12 October 2023 (UTC)Reply

That can create problems with Main Page balance (one or two extra lines can cause that). Plus the "Recent Deaths" tag leads to the appropriate "Deaths in YYYY" articles which include everyone regardless of article quality, so readers can finds they've missed. Masem (t) 00:21, 13 October 2023 (UTC)Reply
As stated earlier, I dislike the rigidity of needing to "balance" the front page with an arbitrary visual neighbor. The fact is, since we instituted the "anyone who died can be listed in RD, as long as the article is OK," it was obvious we would have scaling problems. Therefore, I support the general sentiment of @BD2412 that we should expand the number of folks listed. It may take more work to figure out how to co-exist with the other boxes, but it's time to do that hard work. - Fuzheado | Talk 05:16, 13 October 2023 (UTC)Reply
For my part, I've never quite gotten why it falls entirely on ITN to balance the main page, when when news stories happen is out of our control; and not DYK's, which has had a waiting list for as long as I can remember and could easily list a few fewer or few more articles if needful. —Cryptic 13:44, 13 October 2023 (UTC)Reply
  • Redesign The number of lines is determined by the screen size. If you read it on a smartphone, which is what the majority of our readers do, then it already runs to three lines (and balance is not a thing as there's only one column).
Looking at Deaths in 2023, it appears that there are about 20+ deaths every day. As the current RD selection seems to span several days, it seems that RD is listing about 10% of the total. The selection seems skewed to certain types of people such as classical musicians and baseball players due to the activity of particular editors who focus on those categories.
The presentation is currently quite poor as only the names are listed so there's no context or clue to help the reader. If the number of names were doubled, it would be even more of a sea of blue and most readers would just pass by.
Other languages do this much better with a separate obituary section (e.g. German) and so we need a complete redesign like that.
Andrew🐉(talk) 09:17, 13 October 2023 (UTC)Reply
You've convinced me beyond a reasonable doubt of this clear and present need to remove all the names and thereby reemphasize the bold blue link to the one true separate obituary section, where context and clues help the reader in ~100% of reliably sourced cases. The only thing in my way is this abject lack of authority or permission to do so. So I'll just suggest it again (along with a reminder that the recently dead are no longer "people" nor "folks"), then politely retire to my rightful spot as a fly on the wall. InedibleHulk (talk) 11:50, 13 October 2023 (UTC)Reply
Yes, ITN is quite paralysed by protection which stifles drive, experiment and initiative. Notice that there were no nominations of any sort yesterday.
As IH suggests, it might be better if ITN were mostly a clearer list of links to more dynamic pages including:
With a single blurb and picture as a lead headline and story, this would let readers browse or find what they want while limiting the demands on the ITN process.
Andrew🐉(talk) 12:37, 13 October 2023 (UTC)Reply
Hey, I suggested two things. No more, no less. You're free to infer what you will and "jump off" from wherever, of course, but I won't be held responsible for inspiring any links that aren't already there. InedibleHulk (talk) 17:48, 13 October 2023 (UTC)Reply
Which makes no sense, as the Main Page overall is not a navigation guide, but a means to feature WP's quality content in different slices. This is a non-starter proposal because just having a set of links doesn't promote any type of quality. Masem (t) 13:22, 13 October 2023 (UTC)Reply
It makes perfect sense because, per WP:ITNPURPOSE, helping readers to find topics in the news is what ITN is all about.
What makes no sense is making readers fly blind by just listing names without any clue as to the sort of person that they are. For example, there's now an RD nomination for yesterday. This is Luis Garavito who was quite an unpleasant person. Encouraging readers to click on such a distasteful topic without any warning seems quite wrong.
Andrew🐉(talk) 16:12, 13 October 2023 (UTC)Reply
But that is only one purpose of ITN, and the other factor is that we are not a newspaper - ITN should not be expected to be a mirror of what are the headlines in major newspapers, though we might at times happen to be that - we just do not purposely want to be like that at all times.
Also WP:NOT#CENSORED applies to these topics. We do expect articles to be written to the standard of the principle of least surprise such that when opening the article they are not suddenly awash in unwanted imagery or the like, but we still should be included, in prose, what some might consider unpleasant if that's what the topic is known for. Masem (t) 17:14, 13 October 2023 (UTC)Reply
A friendly note: Let's please not use "We are not a newspaper" as a form of "I don't like it." WP:NOTNEWS has a very specific focus to guard against original reporting, notability, and gossip. It is not a blanket ban on any functions that might overlap with a newspaper, such as informing the public, as WP:ITNPURPOSE says, To help readers find and quickly access content they are likely to be searching for because an item is in the news. I'd argue that this is, in fact, us "purposely want[ing] to be like that." We must not overreach on a slogan like "NOTNEWS" and stop informing the reader. – Fuzheado | Talk 07:24, 14 October 2023 (UTC)Reply
NOTNEWS #2 is specifically that we are not meant to write like a newspaper; we are supposed to try to be writing for permanence and the long-term, and to that end, not every topic that gets headline coverage in newspapers makes for a good encyclopedic topic on WP. And again, the "help readers find topics" is one point of ITNPURPOSE, there are other points and they must be in balance. Masem (t) 13:35, 14 October 2023 (UTC)Reply
NOTNEWS is an argument for shutting down ITN completely as the usual stream of sports results, weather and breaking news obviously violates it. Obituaries are comparatively encyclopedic because they are a retrospective summary of someone's complete life. Andrew🐉(talk) 09:23, 16 October 2023 (UTC)Reply
That's not what NOTNEWS says. We are to write encyclopedic articles, but there's no reason we cannot keep these dynamic and up to date as news articles about them are written. What is a problem that comes under NOTNEWS more often is that editors jump to make a new article about an event that seems newsworthy but has no clear long-term, encyclopedic importance, such as many attempts to post small domestic crimes that have come up. That might grab newspaper headlines but if there's no enduring coverage or long-term impact, then we shouldn't be covering it.
There is clear overlap with writing for an encyclopedia and inclusion of newspaper-like coverage, but we are supposed to be keeping our approach closer to that of the encyclopedia. Masem (t) 12:34, 16 October 2023 (UTC)Reply
I can understand your distaste if you followed the link from ITNC directly to the Modus operandi section like I did, but the lead of the article gives a pretty unobjectionable idea of the sort of content you can expect to find later on. —Cryptic 17:32, 13 October 2023 (UTC)Reply
Masem, I'd love to someday test that assumption ("a means to feature WP's quality content in different slices"), which you've repeated in numerous places. DYK and OTD have minimum quality standards, but I wouldn't call many of the articles in them examples of our quality content. Ed [talk] [OMT] 17:05, 13 October 2023 (UTC)Reply
At least when I participated in DYK, those reviews were pretty close to the standards we expect to ITN featured articles, including minimum size and necessary sourcing. TFA is the best of the best, but the other sections including ITN and DYK show articles that are well on their way to being high quality content and at a state that new editors should be able to join in in editing and by following the established standard on the article. Masem (t) 17:11, 13 October 2023 (UTC)Reply
As of right now I believe this is not a bad idea. Which I suppose is a rather oblique, grazing way of expressing a quite weak support at the moment. But obviously it would take an exhaustive separate discussion and an RfC to make such a fundamental change. I think that at the very least, ITN and RD should be severed entirely, cleaved apart like the German Wikipedia (maybe German engineering really is better). Although Masem's concern that Main Page is not a navigation page is also somewhat valid, it does feature some navigational features already, even in ITN (ex. the RD link, the current events link). JM2023 (talk) 18:09, 16 October 2023 (UTC)Reply
  • My 2ct: I like the neutral presentation of the names in the RD section. They fare - as far as I observe: mostly Germans of all kinds and musicians of all nationalities - much better with little ado than in DYK hooks after a more complex process; yesterday's singer (and still on the Main page) received 10k+ views that day and would probably get just 1k in DYK. People do click in the section, to my surprise, so why consider taking it away, or making it more complicated? - I also agree that the so-called Main-page-balance should not worry us too much, - there's no balance on mobile. --Gerda Arendt (talk) 13:30, 13 October 2023 (UTC)Reply
  • Nah. If you want to see deaths you can read Deaths in 2023, which is linked in the box. DarkSide830 (talk) 00:24, 16 October 2023 (UTC)Reply
  • Make it two lines, for a total of ten people: FWIW, I currently see the 6 RDs taking up two full lines already. I suppose it differs by one's display. —Bagumba (talk) 02:27, 16 October 2023 (UTC)Reply
  • I would quite like to know the reasoning behind the "more people will die in the future than have in the past" comment and how that specifically should tie into any change in policy or process at WP:ITN. There was already a recent complaint on the Main Page about the fact that ITN was too morbid. We needn't be even further on the nose with such an obvious alteration. Duly signed, WaltClipper -(talk) 12:42, 16 October 2023 (UTC)Reply
    • @WaltCip: It is my understanding that the "Boomer" generation was the largest ever in terms of sheer numbers. The rest is just math. BD2412 T 17:18, 16 October 2023 (UTC)Reply
      A better way to look at this is that we have far more bio articles on those with their notable activities in the 2000s, where Internet coverage created many new RSes beyond traditional print to allow these to be created. Its a systematic bias issue that it is far easier to document using online sources than having to do physical legwork related to print sources. Masem (t) 17:40, 16 October 2023 (UTC)Reply
    It's pretty likely that the higher the population, the greater the absolute number of deaths are. To my knowledge, no one has yet invented an elixir of life or discovered a fountain of youth somewhere in the woods, so it's rather likely that overall death increases. That said, I don't necessarily support the redesign for more lines. JM2023 (talk) 18:11, 16 October 2023 (UTC)Reply
    I'd be curious to see what the distribution of articles by decade of birth are. It's possible it's greater the farther towards the present you go (acknowledging that many persons in recent decades WILL become notable down the line but aren't now). DarkSide830 (talk) 21:48, 16 October 2023 (UTC)Reply
  • Note that RD is currently showing seven names rather than the usual six. They are:
  1. Helena Carr
  2. Richard Roundtree
  3. Tom Walker
  4. Desert Crown
  5. Adam Johnson
  6. Bishan Singh Bedi
  7. Matthew Perry
Most of these people (and horse) died several days before Perry so pushing him off the main page in just 5 hours seemed rather unjust, especially as he was so famous (over 8 million views on the first day of the news). The sorting order needs work.
Andrew🐉(talk) 09:46, 30 October 2023 (UTC)Reply
RD nor ITN uses fame as a measure for posting, nor do we worry about page counts. Names should stay on RD for at least half a day if not 24 hours, though, and that's something we can resolve. Masem (t) 12:29, 30 October 2023 (UTC)Reply
I always got the impression that names were listed in order of death with the most recent death as the first name, which would not usually cause names to drop off the list in less than 12 hours unless a lot of blue links die at once. JM2023 (talk) 16:51, 30 October 2023 (UTC)Reply
That is the case with blurbs, not RDs. Curbon7 (talk) 20:36, 30 October 2023 (UTC)Reply
Seems like a no-brainer that recent deaths should be sorted by recency. Is there any particular reason why this is not the case? Looks like something that should get changed JM2023 (talk) 21:08, 30 October 2023 (UTC)Reply
We used to do it that way, but as it often takes a while to get the article up to scratch many would become older than the oldest RD and never get posted. The current way guarantees a posting if the bio is good enough within the seven days on ITNC. Stephen 22:19, 30 October 2023 (UTC)Reply
Richard Moll, we hardly knew ye. BD2412 T 01:03, 31 October 2023 (UTC)Reply
  • On a different note, death of Matthew Perry was significantly covered in the reputed/reliable (RS) print media from India in English, Hindi, and Marathi language. These are the print media that I have access to. That is extremely rare. Most of the times, Marathi print media doesn't give a damn about foreigner celebrities (excluding politicians) unless it is related to India. As of this comment, the RDs are: Ina Cronjé (24), Helena Carr (25), Richard Roundtree (24), Tom Walker (23), Desert Crown (23), and Adam Johnson (28). Since the day of their death, Perry had 10,868,775 views, Roundtree had 498,880 and Carr had 33,939. Perry had died on 28. Others have far less. I am aware there are procedures including the discussions at "candidates" page, but removing Perry so soon after the death, and other - older deaths being there feels like Matthew Perry was not significant enough. The pageview stats say otherwise. We should make some changes, but I am not sure what they should be. —usernamekiran (talk) 14:09, 31 October 2023 (UTC)Reply
    For what its worth, there was a blurb-RD nomination for Perry, but it had very little support. Curbon7 (talk) 19:17, 31 October 2023 (UTC)Reply
    We. Do. Not. Care. About. Pageviews.
    You have been told this multiple multiple times and that this is becoming disruptive.
    Yes, there was a problem with Perry being removed so fast, but that is not an issue about trying to serve pageviews. Masem (t) 00:33, 1 November 2023 (UTC)Reply

RD batching

We need to do a better job of batching these. Matthew Perry was on the main page for barely 5 hours because of how long it took to promote articles of people who predeceased him. The current run has 5 of 6 people who predeceased him and 1 who died on the same day.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 23:50, 29 October 2023 (UTC)Reply

Ideally, a promoting admin should be starting at the bottom of the ITNC list and adding those first, than top down or other "favoritism" reasons. Eg in this case this edit from Ad Orietem jumped to Perry, then Stephan later went through to add several others that were also already ready but just lower down the list when Perry was ready (at the time of this diff). (In this case IAR to get Perry back in line with those other new noms would be reasonable.) Masem (t) 00:10, 30 October 2023 (UTC)Reply
Agree with Masem. This rotation was particularly abrupt (and on a Sunday, to boot). Readers will be looking for Perry (far more, I warrant, than any of the other listings), so IAR, reinstate him at the front, and give him another ride on the merry-go-round. Moscow Mule (talk) 00:39, 30 October 2023 (UTC) (But nothing of the above should be construed as anything other than the utmost respect for posting admins' tireless work.)Reply
Perhaps we should create a process that gives us a better idea of how long RDs have been up without having to look at diffs. – Muboshgu (talk) 00:40, 30 October 2023 (UTC)Reply
While we do not date RDs in the template (since they can be posted at any time within 7 days of nomination and are posted in the order promoted), perhaps it would be good if the "first" RD addition of a given day (after 00:00 UTC turnover) should be invisicommented to date that, with all subsequent RDs assumed to have been posted on that same day. Masem (t) 02:41, 30 October 2023 (UTC)Reply
Perhaps we should codify WP:ITNRD that we can leave extra RD entries beyond the usual six if items have been up for < 12 hours, instead of leaving it to IAR.—Bagumba (talk) 07:08, 30 October 2023 (UTC)Reply
This is a good idea. Curbon7 (talk) 20:40, 30 October 2023 (UTC)Reply
A while ago (I think last year), an admin boldly added an invisible comment after each entry indicating the time it was posted, but this was reverted by another admin. Curbon7 (talk) 07:21, 30 October 2023 (UTC)Reply
I sort of vaguely recall seeing the diff, but don't remember why it was removed. If, as I suspect, it was because it seemed unmaintainable - well, my template-fu is about fifteen years out-of-date, but I've got a prototype template in my sandbox that turns *{{subst:itnrd|[[Matthew Perry]]}} into *[[Matthew Perry]]<!--leave until 05:23, 30 October 2023--> (i.e, 12 hours after the edit substing it). ({{rd}} and {{RD}} are already taken.) I don't post RDs myself; I mostly work with articles in much worse shape, so don't trust myself not to miss something in the quality check before posting, especially if there's only been one or two comments. Admins who do post RDs: would you use this? Would you prefer more elaborate format like *{{subst:itnrd|Joe Schmoe (electrician)|Joe Schmoe|nowrap=yes}}*{{nowrap|[[Joe Schmoe (electrician)|Joe Schmoe]]}}, or just *{{nowrap|{{subst:itnrd|[[Joe Schmoe (electrician)|Joe Schmoe]]}}}}? (Prototype can't handle either quite yet.) —Cryptic 03:56, 31 October 2023 (UTC)Reply
The readers looking for his article weren't bothered by this. It's spelled the exact same way his name is, can't miss. Those unaware were the real hypothetical victims here. InedibleHulk (talk) 04:36, 30 October 2023 (UTC)Reply
I've restored Perry. We often IAR with a 7th (even 8th) RD item to ensure an entry stays up for 12h min. —Bagumba (talk) 00:50, 30 October 2023 (UTC)Reply
I feel it is a good service to have it restored. I don't know how long restoration to 7th position will help, but it is better than 5 hours.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 03:53, 30 October 2023 (UTC)Reply
It's a shame we can't do some HTML magic where we show 5 or 6 deaths at a time, but then also have a "More Recent Deaths" button or link ahead of that, which would then expand or "unfold" 2 or 3 or however many more qualified recent deaths onto the template, similar to how hats work for expanded content. It'd be useful during surge periods, while also still maintaining balance on the Main Page for the first time that it loads, as the "More Deaths" portion of the header would be collapsed until the user clicks that link. And we'd only need to do that in unlikely scenarios when we have something like 7 or 8 RDs posted within a 24-hour time span. The button could be labeled "Show more..." or "Continued..." or something like that. Duly signed, WaltClipper -(talk) 12:50, 30 October 2023 (UTC)Reply
We already have a "more recent deaths" button. It's the link to Deaths in 2023 which is concealed by the "Recent deaths" title. That page is usually quite up-to-date and comprehensive, listing many notable deaths for each day. And it's usually a top-read article as it averages over 130,000 views every day. It seems to be so effective because discussions are exceptional and its editors are able to edit. ITN's RD is just a fraction of that content. Andrew🐉(talk) 08:28, 31 October 2023 (UTC)Reply
Other language Wikipedias such as German, French and Spanish, include the date of death in their equivalent sections and naturally list the entries in that order. The Spanish one has quite a lot of entries. Andrew🐉(talk) 21:06, 30 October 2023 (UTC)Reply
So as an idea for batching, let's say that we should only post RDs in one batch every 12 or 24 hours. This is up to the posting admins to make sure they are not stepping on other admins' toes. When an admin posts they would be required to go through the entire ITNC page, from bottom up, to add items to the list as one batch. Other editors (not just admins) can mark RDs as ready to help the process here. The "downside" that we will not have rapid updates of RDs of articles that are already in good shape, but that's maybe 25% of the RD ITNCs from my experience? --Masem (t) 01:26, 31 October 2023 (UTC)Reply
I don't think we have enough active admins to ensure a systematic post every 12–24 hours. I've seen RDs marked "ready" that I was WP:INVOLVED with that took a while to post. We don't need more barriers to timely posts. If Perry had been left as the 7th RD, there wouldn't have been an issue. —Bagumba (talk) 14:51, 31 October 2023 (UTC)Reply
As I pointed out, if when Perry was posted that the posting admin started from the oldest "ready" RD and added those before adding Perry, we also would have avoided this situation. We need admins not to play favorites or to rush newer "popular" noms before reviewing the older ones waiting to be posted. It basically boils down to admins taking more responsibility and carefulness when posting. Masem (t) 00:35, 1 November 2023 (UTC)Reply
Perhaps this suggestion could be added to WP:ITN/A. Curbon7 (talk) 01:07, 1 November 2023 (UTC)Reply
Masem, forgive me if i am misunderstanding you, but i think that, had the posting administrators posted the rds in chronological order, we still would have had the same problem. i believe the only difference is that perry wouldn't have been the one bumped. dying (talk) 18:59, 6 November 2023 (UTC)Reply
Correct, and quite possibly no one would have noticed. Stephen 21:15, 6 November 2023 (UTC)Reply
  • For some reason, I have spent an inordinate amount of time (perhaps more than many others here?) thinking about this topic over the last few (three?) years. At the end of it -- I have come to the conclusion that the better is the enemy of the good, and have made my peace. So, let's start from somewhere, here goes.
  1. Should we at least ensure that an RD stays 24 hours on the carousel? Yes, if we can. Unfortunately a few proposals were made on that front and 'community consensus' did not emerge on this topic. So that failed.
  2. Can we pass this responsibility to posting admins and ensure that they have a look at the RD falling off the carousel and perform an WP:IAR if the falling RD has spent less than 24 hours and allow that one to stay for a few hours longer? Some admins already do that. However, we all know that admin capacity is super hard to come by and we cannot mandate this. A proposal to solidify this approach also failed, iirc.
  3. Can we add a timestamp as a comment in the posting template so that it is easier for an admin to see when the falling-off RD was posted? Seems a simple solution to add a timestamp, but, we could not find out how this was to be done. Conceptually it sounds simple to add a timestamp as a comment next to the article title on the ITN template.
  4. Can we add a couple of extra RDs on the carousel? This proposal failed because we could not align on screen sizes and did not want RDs spilling over to three lines on some screens.
  5. Today (or at least a couple of months ago) we have an issue that our posting curve is not smooth. i.e. we do not post at regular intervals. Even when we have articles marked as a ready, they stay in that state for a very long time. This is primarily because of available admin capacity. We had run the numbers and had seen that the entire ITN project is reliant on a handful of admins. Definitely thankful for their time. So, the answer is a) we need more admins to participate, or b) explore a new role of an 'admin without tools', or c) technology solutions to create a staging / holding area where non-admins move content to and a script posts at a pre-defined interval e.g. 4 hours. Unfortunately none of these solutions have found takers for some reason or the other.
  6. With all of that said, where are we right now? Answer is -- we make do with what we have. -- Admins are encouraged to:
  1. Post more often
  2. Not batch the postings but post one at a time
  3. Evaluate articles from the bottom of the page
To conclude, like I mentioned earlier, sometimes better is the enemy of the good. And, we have something that is working, however flawed. I continue to remain in awe of the number of articles that are improved to main page levels of quality in this project and that is an absolute WIN for Wikipedia at large and there are no two ways about it. Happy Diwali to all those who celebrate. Ktin (talk) 18:29, 11 November 2023 (UTC)Reply
Should we at least ensure that an RD stays 24 hours on the carousel? Yes, if we can. Unfortunately a few proposals were made on that front and 'community consensus' did not emerge on this topic. So that failed.: Keeping them up for at least 12 hours seems to be a common WP:IAR practice. A few mentioned 12h (instead of 24h), because that's the minimum amount of time that DYK hooks stay up. —Bagumba (talk) 07:45, 12 November 2023 (UTC)Reply

"Arrival of spacecraft (to lunar orbit and beyond) at their destinations"

 
Moonrise on Dinkinesh

So, following the discussion that has occurred so far on the 152830 Dinkinesh/Lucy probe nom at ITN, I wanted to request some clarification on the third item in the "Space Exportation" section at ITN/R, which reads as "Arrival of spacecraft (to lunar orbit and beyond) at their destinations". Do we consider this to include all fly-bys of a probe, or is this more about final destinations? Because, honestly, I think an auto-blurb for every intermediate destination of a probe such as this one (having six more impending fly-bys not including two swings back past Earth) seems excessive. So I guess my question is as follows: Does this event fit the aforementioned criteria, and if so, do we think that the this statement being interpreted as such is best practice for ITN? DarkSide830 (talk) 16:28, 2 November 2023 (UTC)Reply

My first reaction is that flybys come in two types that I'll arbitrarily call mission objectives and waypoints. I think mission objective flybys (of which there can be multiple per mission), e.g. New Horizons flyby of Pluto, are what should be ITNR. Waypoint flybys, those that are included just to get the spacecraft to its objectives, should not be excluded from ITN but neither should they be on ITNR. Separate from this is the discussion of when something should be posted. That needs to discussed individually, but as a rule of thumb I'd suggest closest approach should be the default with a specific consensus required to post before then. Thryduulf (talk) 16:59, 2 November 2023 (UTC)Reply
  • It obviously means what it says and that's after due consideration which is why the boundary was pushed out to lunar orbit. Deep space probes are not so common and their destinations so frequent that there's a problem that needs fixing. In this case, the probe has delivered a significant and surprising result in finding that the asteroid has a moon (pictured). Per WP:NOTBURO, we should not obstruct coverage of such marvelous science. Andrew🐉(talk) 12:47, 3 November 2023 (UTC)Reply
    It's not about frequency, it's the "so what" aspect of it. Do we need to inform readers of every time a probe makes a fly-by? And surely you can't be serious about that NOTBURO comment. No one is suggesting we "obstruct" scientific coverage. Now, I don't get how you think a rock being, in fact, two rocks is more important then the change in a head of state for a country of 10,000 people, but whatever. Either way, I'm not saying "screw science", I merely am questioning if this needs to be ITN/R. Personally, having an item be ITN/R is more bureaucratic then removing such an item, in my opinion, but that is not the point. DarkSide830 (talk) 18:45, 3 November 2023 (UTC)Reply
    If a flyby produces significant scientific findings then it will be eligible for inclusion in ITN whether it is ITNR or not. Thryduulf (talk) 12:28, 4 November 2023 (UTC)Reply
We should be cognizant of the fact that most space agencies consider trivial events such as waypoint fly-bys to actually be part of the "mission objectives" when evaluating the spacecraft's performance. For example, when Apollo 13 circled around the Moon to return to Earth, that abort maneuver was technically considered a mission objective under the alternate mission (see PAO transcript, 057:11:53). It's just something to be aware of, especially in press releases by said agencies who want to pump up their program as much as possible, mostly to justify its continued funding and support. Duly signed, WaltClipper -(talk) 16:50, 3 November 2023 (UTC)Reply

Remove sign parameter from Template:ITN candidate

Currently, {{ITN candidate}} has a |sign= parameter that almost everybody uses. However, I don't see why this should be in the template instead of having the proposer just add their signature after the template (which is what this currently displays as) and handling such signatures that are parameters inside the template is quite harder for many discussions scripts to do. For example, Convenient Discussions would mistakenly reply inside the template. I don't see at all why this exists and I want to remove this. My topic on this at Template talk:ITN candidate got no replies and I'm not comfortable changing such a widely-used template, so I proposed it here based on Cryptic's suggestion from WP:VPI so we can hopefully discuss this and next steps. Aaron Liu (talk) 02:33, 12 November 2023 (UTC)Reply

The "nom cmt" and "sign" parameters to this template don't actually do anything except prefix "Nominator's comments:" to stuff that would appear after the template anyway, and maybe - maybe - make it less likely that very new users forget to sign. I can't see how that's worth the genuine problems it causes with tools; if it means we have to paste in {{xsign}} templates a bit more often, there's enough extremely experienced users watching ITNC to do so. —Cryptic 02:57, 12 November 2023 (UTC)Reply
If it is the case that the signature in the template screws up the newer tools used for replying, then we should get rid of it or change something (I think doing a template subst might be overkill). We'll also need to make sure that experienced users are reminded to add their signature outside the template when nominating. Masem (t) 00:04, 13 November 2023 (UTC)Reply
Cryptic also proposed that when/if we make this change, we also update the examples to remove the mention of |sign= and |nom_cmt= since most users appear to be copy and pasting from the examples. Should I do this right now? Aaron Liu (talk) 01:35, 13 November 2023 (UTC)Reply
No, because we still need a way for editors to sign nominations, or at least to make sure they are aware of the steps they need to comment and sign nominations. Masem (t) 01:59, 13 November 2023 (UTC)Reply
Sorry, I forgot to mention also including <!-- Additional comments go here -->~~~~ at the end Aaron Liu (talk) 02:03, 13 November 2023 (UTC)Reply
Ah, yes, in the two copy-paste boxes we have. Yes, I think we can make that change then, but check our guidance doc to make sure that's not also in there. Masem (t) 02:22, 13 November 2023 (UTC)Reply
I would change it, and run it as a pilot, keeping a close eye on new nominations for a couple of weeks to see if problems arise. And be prepared to revert if it causes unforeseen problems. Stephen 02:16, 13 November 2023 (UTC)Reply
(I actually proposed changing the example usage without immediately changing the templates, so the old format still worked. Obviously the examples will need to change if we remove the parameters entirely.) —Cryptic 02:21, 13 November 2023 (UTC)Reply
Hm, that brings something else up - we'll need to do something about the existing transclusions. Either leave the parameters there forever, which defeats the purpose to some extent, or subst the existing ones both on WP:ITNC and all the archives. I'd vote for substing, if that works out cleanly, since most of the archives are over the transclusion limit already. —Cryptic 02:24, 13 November 2023 (UTC)Reply
I've just merged the sandbox, which aims to optimize around transclusion limit and also removes altblurbs 5 and 6, into the main template Aaron Liu (talk) 02:37, 13 November 2023 (UTC)Reply
There've been times when there have been five or six altblurbs proposed and discussed before, and you've just made those invisible in the archives. —Cryptic 02:48, 13 November 2023 (UTC)Reply
Yeah, let's undo this, that's going to cause problems. We may have to make a new template to avoid that. Masem (t) 03:10, 13 November 2023 (UTC)Reply
Preserving the appearance of the archives is the most important thing as they are huge and are often searched and referenced. And I already find it confusing when the older archives don't work properly due to some other structural change. In this case, the signature parameter seems unimportant as it is usually defaulted and so I'm not seeing a good reason to fiddle with it.
Note also that the title for this section currently contains a spelling error: "parmater" while at the template talk it's misspelt "paramter". Editors who make but do not notice such glaring errors should not be messing with templates as they will tend to break their syntax. See The Era of “Move Fast and Break Things” Is Over.
Andrew🐉(talk) 10:07, 13 November 2023 (UTC)Reply
This is relevant, how, exactly? Fixing templates isn't editing articles; two of the most brilliant programmers I've ever worked with couldn't spell worth a damn. —Cryptic 04:39, 16 November 2023 (UTC)Reply
An obvious simple workaround would be to create a new nearly identical template. This preserves the integrity of the archives, and I think everyone just copy/pastes the parameters from the candidates page anyways. Curbon7 (talk) 10:18, 13 November 2023 (UTC)Reply
I have updated the examples. Aaron Liu (talk) 13:59, 14 November 2023 (UTC)Reply
So far, we’ve got one person who did it correctly and one person who didn’t. Aaron Liu (talk) 15:41, 15 November 2023 (UTC)Reply
  • I just created a nomination at ITN/C. I did so by copying the example in the documentation at {{ITN_candidate}}. The main work required was to identify the relevant article, compose the blurb and identify the updaters. The signature required no effort at all. So, my experience is that this isn't a problem that needs fixing and so we should do nothing.
Note also that the template currently says emphatically that "This template should not be substituted." per {{nosubst}}.
Andrew🐉(talk) 15:14, 13 November 2023 (UTC)Reply
I do not understand your argument. Why can’t we change the example? Aaron Liu (talk) 15:20, 13 November 2023 (UTC)Reply
The problem is that, since this is both not substed and the signature appears within the template parameters rather than after it, any attempt to reply using discussion scripts also puts the reply in the template parameters. You using the template isn't the problem. The person responding to you using the template is. —Cryptic 04:36, 16 November 2023 (UTC)Reply

"Reviewers' attention needed"

If there's anything to show that ITN and RD should be cleaved apart... we aren't even paying attention to RDs anyway. JM (talk) 16:31, 13 November 2023 (UTC)Reply

Even if we split it, I bet that RDs would still go unattended because of the fact the newest default theme eliminates the TOC to that level. The old style allowed one to see at a glance any "READY" or "NEEDS ATTENTION" in one spot, now an admin has to either unfold each date on the left or go through the entire page. I know there's an option to modify the CSS to force this table, but this shouldn't be the solution and won't be friendly to new admins that want to help at ITN.
I am wondering if we have a daily bot that can look for special tags in short templates (like "itn ready" or "itn attn"), or even if just using using simple catches of "(Ready)" and "(Attn)" in the H4 headers to list out ITN items that need admin attention for posting. Masem (t) 01:24, 14 November 2023 (UTC)Reply
I still think the new display theme wastes too much screen space, ITNC or not. I set Preferences->Appearance->Vector legacy (2010). —Bagumba (talk) 01:48, 14 November 2023 (UTC)Reply
I don't think any are being missed from posting, but there do seem to be occasional batches of barely noticeable people that are plucked from Deaths in 2023. Those often remain unreviewed as there's not a great deal of interest in assessing relatively obscure biographies. The blurb nominations get all the interest and commentary. Stephen 03:43, 14 November 2023 (UTC)Reply
  • I don't usually pay much attention to RD as it's just a list of names, like the phone book. Today, these are:
What I mainly notice is that these are all Anglo-American but I've not heard of any of them and have no interest. Bob White is a common name and so needs disambiguation but doesn't get it.
Looking at the latest full day in Deaths in 2023, we have:
This seems much better in that it explains who these people were, provides a reference for each death and is much more comprehensive, timely and global in its coverage. It also includes someone that I've heard of – the prolific SF author, Michael Bishop. He would probably stand little chance at RD because, with many works to his credit, some jobsworth would insist that each of them must be cited.
So, on this evidence, RD should indeed be separated from ITN so that it might flourish as a separate obituary section, as we see on the front page of other Wikipedia languages. It just needs to follow the model above to be far more informative and productive.

References

Andrew🐉(talk) 09:08, 14 November 2023 (UTC)Reply
How many of those articles at Deaths of 2023 are of quality to post on the main page? Certainly we should try to pull those that are in good shape to post via ITN's RD, and not bring those that are miles away.
But we are not going to change our approach to accommodate for more recognizable names over others. RD is about 1) quality of the article and 2) the death can be verified in reliable sources. Masem (t) 13:16, 14 November 2023 (UTC)Reply
It would be a nuisance to update RD with so many entries a day, especially for the involved admins. DarkSide830 (talk) 15:53, 14 November 2023 (UTC)Reply
some jobsworth would insist that each of them must be cited why should we allow unverified information into articles linked from the main page? Masem is right, RD is about the quality of the article. JM (talk) 15:56, 14 November 2023 (UTC)Reply
Editors, I am thinking more along the lines of "RD is suffering under ITN" because people take more interest in blurbs than in RDs which is why it ends up with someone going through and marking so many of them as "attention needed". I've also noticed since I started this section that people keep confusing blurb standards for RD standards and acting like significance or fame has any effect on whether something is qualified for RD.
I'm NOT saying we should listen to Andrew and have a whole new obituary section and have to reorganize the main page; the RD section on the main page should be left alone, but I do think RD would do better with a separate project page. Those actually interested in RD can go there and see nothing but RDs to review, and there's nothing else on the project page like blurbs to draw people away from them.
(A further development of this would be that RDblurbs would be proposed in ITN as a blurb separately from being proposed for RD; and thus could end up having the same qualifications as normal blurbs (i.e. notable death not notable life, per most recent discussion on that matter)) JM (talk) 16:07, 14 November 2023 (UTC)Reply
ITN overall has an issue where only "popular" or "important" topics get significant attention from those that do not regularly participate in ITN, which affects both RDs and normal non-RD blurbs. A major disaster but not one in the US or Europe? We struggle to find !votes, but make it a much smaller incident in the US and Europe and people !vote from all over. It wouldn't be as bad if these non-regulars were !voting and addressing quality issues, but 90% of the time (my estimate) they are only their to !vote feeling the topic is important to them and ignoring any quality concerns. Splitting off RD will not solve that, you will still only have people flock to popular or important people (eg compare the !votes for Matthew Perry to others of late). Sadly, that's a "WP is voluntary"-related problem that is not easy to correct beyond slapping notices everywhere that quality is a key metric (and effectively the only metric for non-blurb RDs). Masem (t) 00:51, 16 November 2023 (UTC)Reply

Stale blurbs?

All of the ITN blurbs currently displayed are at least a week old, with the oldest (2023 Nepal earthquake) being 13 days old. Furthermore, there are no new ITN blurbs being suggested/voted on (not including RD). Should some of them be allowed to leave, or is it a matter of the news cycle not being especially eventful this week? ChaotıċEnby(talk) 16:07, 16 November 2023 (UTC)Reply

Doesn't seem like anything new of major national or international scale is really making the news lately. Most newsmedia coverage is focused on the current Israel-Palestine War and its periphery covered in ongoing. JM (talk) 16:31, 16 November 2023 (UTC)Reply
There've been plenty of blurbable events, enough in the past week alone to fully replace T:ITN. Some of the articles aren't in good enough shape. More aren't worth nominating given the disfunction at ITNC. —Cryptic 16:45, 16 November 2023 (UTC)Reply
Most of these seem to be covered by the ongoing wars (Gaza, Ukraine, Sudan and Myanmar), local politics, or elections (like in Madagascar or Liberia) for which the results aren't there yet.
Also genuinely asking, what's the dysfunction about? If it's related to people not !voting for lesser-known topics, I feel that having them at least nominated would be a good first step? ChaotıċEnby(talk) 16:51, 16 November 2023 (UTC)Reply
I thought of nominating the Indian bus crash but figured it was pointless because the community just rejected an Indian train crash on the basis that they happen all the time now. JM (talk) 17:01, 16 November 2023 (UTC)Reply