Personally I don't see the admin interface being the correct place for this rough estimate

The canonical source for this data is https://developer.joomla.org/roadmap.html

I started putting dates on the milestones for patch releases to help keep myself organized primarily, not as a means of publicly saying "Joomla expects X release to go out on Y date" (it does have a side effect of giving people keen enough to pay attention a rough idea what I'm thinking). It's on a roughly 4-6 week schedule though, and I don't expect it to change much (I started at 4 weeks then between holidays and event travel things have shifted a bit to accommodate as needed).

The Joomla backend really isn't the place to be communicating this repository's activity. Your backend should be about your site. Not project news, local events, or other marketing stuff that other CMS' choose to put on their dashboards.

I like the Feature Request of @peteruoi. Another Reason get People Notice about developing, test.

A Place to put Information:

So Admin can (de)activate on own Preferences.

Well it's not actually something irrelevant from their site.
We are not talking about the joomla 4 rc 1 schedule.
We are talking about something we are already showing to them and that is the next minor update. By saying we are showing to them i mean we inform them either way (when the update is ready) that the time has come to update it.
Obviously we show this to cover the majority of cases that don't visit github or even joomla.org. But if that's the case why don't we add value to what we already have, by letting them know ahead that the next update is near enough (let's say even a week beforehand).
I suspect lot's of administrators don't visit daily their backend. Actualy i believe that many don't visit it once in a week (don't have facts just guessing) so i believe with a timer in their backend we may raise awareness for this type of super users or just convenience for super users who visit more often to schedule their time to update ahead. (we may be even lucky enough to remind extensions developers to run a test with their extensions in case everything breaks :P )

And if it says 3 July 15:00 GMT and its not released until 10 July 18:00 GMT - then users will stop paying any attention to the message

if it says 3 july i guess the release leader will know 1 week before (or even 2days before) that its is not possible and will renew the timeline to show 10 days after or even a month(!) however the closer we are to the goal (release) the accuracy will be better.
This time indication must me communicated that it is an indication and not a full planned schedule (as some critical security updates which where announced in joomla.org sometime ago.)

However, this can still be useful imo for the reasons i stated before.
Another scenario. The day before a release we are 99% certain of the time of the release. Then even that super users that visit daily their sites can program to take a two hours leave from their home :)

Ofc you can still say that there is still this 1% that may make joomla lose face but this is not the case if it has been well communicated what this feature really is.

This is still marketing style data that doesn't belong in a site's administrative dashboard, no matter how you spin its presentation. While it might be nice to promote engaging with their ecosystem, my company's WordPress clients don't care about these types of marketing widgets (project news and upcoming events) and they pay us for maintenance so they don't need a widget to say "next release is coming in X days, be prepared!".

Yes, it might be a feel good thing. Yes, some people might actually appreciate that information. No, I do not believe this type of module or information belongs in the core Joomla distribution.

Obviously i wasn't referring to these type of clients that can buy support from companies or even joomla's companies that sell automated updates. These type of clients won't stop using professional services cause 3 words of information are presented in the dashboard. They could be also be able to press disable this "feature" and gain that much space.
If you continue to update the milestone eta in github that would be more than enough for my needs too. So i don't want this feature for myself. I just think it will be really usefull for many (if not the majority) of joomla sites.
I won't be arguing more :) You are the release leader and if you don't think it's worthy there is no point in keeping this open :)

I'm just one person with an opinion.

It is a lot more involved than simply writing a module to find a milestone and show a date. It has to be smart enough to know what milestone should be considered "next". It has to be heavily cached due to GitHub API rate limiting. Or, it calls for us setting up and maintaining more architecture on joomla.org because people will want to expand what that module displays (which adds to my personal workload). And if it's hosted on joomla.org that means we have to write and maintain an interface to create and maintain that dataset (which adds to my personal workload).

We already have enough existing resources that there isn't a pressing need to add a module to every Joomla site. If you notice, the one feed we do supply from project resources is buried on the postinstall component page and only when showing messages for core. There is no other external feeds pushed into the Joomla backend and I personally prefer we keep it that way; my stance for years (and I know some on the marketing team hate me for this) is that the Joomla backend is not something for us to use as a marketing arm and outreach to users for pretty much any reason short of update notifications. And unfortunately that precludes something like this.

Yes i get your point, And kind of imagine the extra burden to maintain. However, my point is that the proposed feature is much more close to the notifications of updates that we already have than whatever feed from joomla.org for marketing reasons. Imo we don't cross this subtle line with this and it can really help.
If we have the resources to do it is another thing. Obviously if we don't we don't. :)

closed for the reasons stated my Michael above