Global renaming is a part of MediaWiki-extensions-CentralAuth, and I don't think any active CA developers use the GlobalRename tag. Can we archive it?
Description
Event Timeline
I guess so; wondering if any of the members listed on https://phabricator.wikimedia.org/project/profile/1219/ might have an opinion
Not a CA dev, but I used the tag for resolving blocked renames where technical assistance is required from devs. (Suggested by https://wikitech.wikimedia.org/wiki/Stuck_global_renames)
I wonder how to make a decision (as usual). Like whether to add every member listed on https://phabricator.wikimedia.org/project/members/1219/ .
No stewards listed on https://www.mediawiki.org/wiki/Developers/Maintainers .
Was wondering whether to archive GlobalRename or make it a subproject of MediaWiki-extensions-CentralAuth if anyone considered the differentiation useful.
But looking at the board of MediaWiki-extensions-CentralAuth at https://phabricator.wikimedia.org/project/board/167/ it already has a GlobalRename column (and a useless "Feature requests" column which I just disabled because that's a task subtype nowadays).
So I propose to archive, indeed.
My 0,02 here is that this depends on the active developers/maintainers of CentralAuth. While global rename is indeed part of centralauth, it's a specific part of it that may benefit from having its own workboard. As such, independent project or subproject/milestone would be appropriate if developers would find it helpful for their work.
Since Taavi says this tag tends to be forgotten I agree with archiving GlobalRename after verifying that all of these tasks are tagged with MediaWiki-extensions-CentralAuth too.
I wonder about the overlap betweek MediaWiki-User-rename and GlobalRename / MediaWiki-extensions-CentralAuth. While the later renames the global account I think we still depend on RenameUser to rename the local accounts? If yes, maybe identifying which tag to use (CA or renameuser) may be confusing.
If current CentralAuth devs don't find the tag useful, archiving it and using a column instead seems fine. :shipit: