I'm not seeing a concrete reason to adopt the tool:

• Source code is publicly available and can be used to deploy as a new tool
• The tool doesn't use the database or other persistent storage, so a separate deployment doesn't lose any context or stored user data
• The tool name (ftools) seems to be short for Fastily Tools, so unnecessary to be retained
• The tool is not that popular, so it seems unlikely that lots of people have bookmarked the old link

From the discussions you linked, forked or equivalent tools have already started coming up. If you still want to adopt ftools, I would suggest to go through the process.

I would say the two threads less than a day apart point to its active use, as well as it being part of the rangeblock guideline page. The concern here is not simply retaining the functionality, but retaining the functionality as well as the tool path to minimise disruption to administrators' current workflows.

This seems to be mostly or purely about the rangeblock calculator, which is (hopefully) going to become a special page available to all users. It already exists for checkusers.

If there are other parts of ftools unrelated to the CIDR calculator that haven't been mentioned here yet, I think creating a new task for each of these would be good, with an explanation of the use-case for each tool that should be adopted.

Oh my, I see it now. I came here from the "Rangeblock Calculator" AN discussion linked as "1" above and thought "we already have a solution for that". But one of the main points of the task is to prevent the automatic deletion after 40 days from happening, and probably to re-enable the scripts in their original form. Okay, okay.

I thought adoption means implementing a tool's functionality in MediaWiki's core or an extension, and I thought I was looking at a request to implement the rangecalc script in MediaWiki's core.

I too missed that the tool has been disabled and is up for auto-deletion in 40 days. The abandoned tools policy is unclear about handling such situations, likely because it has never been updated since tool deletion became possible. However, it does say that the notifications and waiting period can be skipped if the tool's only maintainer is Owner of abandoned tools. Will wait for comments from others in TFSC. But frankly, I doubt any disruption is occurring to administrators' workflows that can't be fixed by updating the tool link in the rangeblock guidelines.

The waiting period and notifications are required per the policy. Regardless of whether you think Fastily will respond, they have the right to object so long as they are the maintainer.
Since you have access to the source, archival/deletion is a nonissue since you can clone it at any time.

However, it does say that the notifications and waiting period can be skipped if the tool's only maintainer is Owner of abandoned tools.

It is not a maintainer, so the condition does not apply. AFAICT, the account (deliberately) isn't used any more.

FYI, there is nothing useful remaining in the tool's directory - any files to run the tool were removed prior to disabling. Other than the URL, there would be no difference to creating a new tool. (Anything that links to it can be updated.)

In T381138#10369300, @JJMC89 wrote:

FYI, there is nothing useful remaining in the tool's directory - any files to run the tool were removed prior to disabling. Other than the URL, there would be no difference to creating a new tool. (Anything that links to it can be updated.)

Hm, it is possible/worth it/has precedent to set a domain redirect to wherever the new version of the tool is hosted to minimize confusion?

In T381138#10446291, @PixDeVl wrote:

Hm, it is possible/worth it/has precedent to set a domain redirect to wherever the new version of the tool is hosted to minimize confusion?

Yes. The prior ftools tool was archived which in turn freed the tool name for reuse. Any Toolforge maintainer could now create their own ftools tool. To make that tool redirect to some other tool, see https://wikitech.wikimedia.org/wiki/User:BryanDavis/Kubernetes#Make_a_tool_redirect_to_another_tool_WITHOUT_running_a_webservice

In T381138#10446364, @bd808 wrote:

Tool was archived by its prior maintainer.

Forgive me for being unfamiliar with Toolforge currently- does archive entail completely hiding as well? Since none of the tools by this maintainer seem to exist anymore from search or audit log (searching by username).

In T381138#10446385, @PixDeVl wrote:

In T381138#10446364, @bd808 wrote:

Tool was archived by its prior maintainer.

Forgive me for being unfamiliar with Toolforge currently- does archive entail completely hiding as well? Since none of the tools by this maintainer seem to exist anymore from search or audit log (searching by username).

Archived tools are for all intents and purposes deleted. There is an archival tarball made of whatever remained in the tool's home directory at the point of archiving, but nothing else. That happens 40 days after a maintainer of the tool pushes the "disable tool" button in the Striker UI. https://wikitech.wikimedia.org/wiki/Help:Toolforge/Tool_accounts#Delete_a_tool_account

I have now become the maintainer of the tool. It can be found at https://ftools.toolforge.org/.