In T375508#10402876, @Dreamy_Jazz wrote:

Some of the dashboards have been added. However, some metrics are not appearing in the list of metrics to select. I'll check again to see if this metric appears next week.

Noting that we're having some internal discussion about the access requirements, so it might make sense to mark some of the subtasks that depend on these requirements as stalled.

@Dreamy_Jazz ICYMI, using OOUI or Codex would be OK here per T373818#10393954.

In T348780#10398412, @Mstyles wrote:

We've stopped this project in favor of the USD project

@mszabo @STran is this task still valid?

As of today, there are 812 filters using ip_in_range.

I think the next step here is documenting why we want to do this, thinking through retention policies, clarifying what we want to store, and then filing an L3SC task. We should probably file a task to track the design/product specification/L3SC approval, and then this task can just be about the engineering implementation. I'm marking this task as Stalled, for now.

In T378449#10271481, @Tgr wrote:

Probably the same as T355280: Try to connect to central session before temp user creation but can you check why autologin is not working?
The debugging steps would be:

1. create a temporary account on igwiki;

Untagging TSP as this is an upstream issue.

To handle those cases quicker, it would be useful to be able to revert subsequent edits from the same IP (but via multiple temporary accounts) using the rollback feature as well.

In T381653#10386274, @Samwalton9-WMF wrote:

PageTriage is only deployed on English Wikipedia, where anonymous/temporary users can't create articles, so I don't believe this is a scenario which can occur in Wikimedia production projects at this time, unless I'm missing something?

In T376726#10383137, @BTullis wrote:

In T376726#10383000, @kostajh wrote:

There is nothing more for Trust and Safety Product Team to do here, so I'm untagging our sprint, and also unlinking Temporary accounts as the remaining work (making sure https://dumps.wikimedia.org/other/globalblocks/ is offline) is not relevant to that project.

Thanks for the ping @kostajh and apologies for the delay in responding.

Your patches above removed the globalblocksdir from the dumpsdata100[3-7] servers, where dumps are initially written (by the snapshot servers).
However, the way that the dumps system currently works is that the dumpsdata servers regularly rsync the files to the dumps distribution servers, which are currently called clouddumps100[1-2].

When this sync occurs, existing files on the distribution servers are not deleted; new files are simply added to the colelction.
This setup has allowed us to have two servers with much larger storage (clouddumps) for holding many more copies of the dumps than the dumpsdata servers, which are more like a transient store.

This means that the previously dumped globalblocks files still exist on clouddumps100[1-2].

btullis@clouddumps1002:/srv/dumps/xmldatadumps/public/other$ tree globalblocks/
globalblocks/
├── 20240713
│   └── 20240713-globalblocks.gz
├── 20240720
│   └── 20240720-globalblocks.gz
├── 20240727
│   └── 20240727-globalblocks.gz
├── 20240803
│   └── 20240803-globalblocks.gz
├── 20240810
│   └── 20240810-globalblocks.gz
├── 20240817
│   └── 20240817-globalblocks.gz
├── 20240824
│   └── 20240824-globalblocks.gz
├── 20240831
│   └── 20240831-globalblocks.gz
├── 20240907
│   └── 20240907-globalblocks.gz
├── 20240914
│   └── 20240914-globalblocks.gz
├── 20240921
│   └── 20240921-globalblocks.gz
├── 20240928
│   └── 20240928-globalblocks.gz
└── 20241005
    └── 20241005-globalblocks.gz

13 directories, 13 files

The simplest option for taking them offline is simply for me to delete this directory and everything in it, from both servers.

Is that approach acceptable to you, or should I be looking to archive these files somewhere?