Thanks for opening this, this workflow certainly needs to be improved.

Also, in cases where a request is user-initiated - why would WMF Legal be needed as well? The user should still be contactable as they made the request.

AFAIK this started life as a replacement for the requests which came through legal. An automated option to "delete" accounts was required by Google (& Apple ?). I assume it's there so Legal can account for the decisions when Google (& Apple ?} follow up on complaints.

Yes, then it grew in to self-service. AFAIK, the ones manually from Legal still just come to the VRT queue?

Sorry, it looks like this was caused by removing the email address from the account (AccountVanishRequests) through which automatic user-initiated vanishing requests are handled.
We've put back the email address for that account, so this behavior should no longer happen (and an email will be sent automatically).

Test case just came through from Läägpõrkur.

https://meta.wikimedia.org/wiki/Special:GlobalRenameQueue/request/128118

It didn't barf. Did legal get the message?

The immediate issue should now be resolved.

I've emailed Legal for confirmation that the refusal was reported to them. They have not yet responded. The issue resolved once the loop is closed, not before. "All good at our end" isn't the required end-point.

Has legal ever responded?

This task shouldn't languish in the queue as "open" for months when it's already been fixed.

As the WMF-Legal project tag was added to this task, some general information to avoid wrong expectations:
Please note that public tasks in Wikimedia Phabricator are in general not a place where to expect feedback from the Legal Team of the Wikimedia Foundation due to the scope of the team and/or nature of legal topics. See the project tag description.
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team. Thanks!

Added to the DEC 2024 stewards meeting agenda where legal is usually present

@Cabayi

I just went through the user story here is the current results:

1. Have a registered account
2. Have the user not qualify for automatic vanishing
3. Have the user request account vanishing using Special:GlobalVanishRequest
4. Have a renamer DENY the request (e.g. https://meta.wikimedia.org/wiki/Special:GlobalRenameQueue/request/133443/)

What happens:

• The vanish DENY completed, there is no mention of anything about WMF Legal
• The requester gets emailed the rejection, email looks like this:

So it appears that due to workflow changes the original user story may no longer be valid. Anything else you done here?

Note: also tested after removing recovery email address from requester, so they have no email address.

Vanish deny completes without any error message.

Discussed at WMF/Stewards meeting: pending verification from WMF Legal:

1. Is this solved because WMF Legal is no longer part of the workflow?
2. Is this solved because WMF Legal has verified they are receiving notices now?
3. Is this NOT solved because WMF Legal is expecting notices, not getting them, and this is failing silently?

pending verification from WMF Legal

Hi, has that happened?

I haven't heard back from them yet

Hello, I'm with WMF Legal and confirm that the bug is outstanding - we're not currently receiving any notices of rejected vanishing requests. We really appreciate your vigilance and support tracking this issue. We're in touch with the appropriate eng team who is now further investigating the issue.

We're working with @kostajh and @SimoneThisDot to modify the rejection flow such that notifications are no longer sent to Legal, but rejected requests and reason for rejection is documented such that we're able to look this up when needed (eg, in the rare case that we receive a related legal inquiry). This would mean making the reason for rejection field required as opposed to optional (current setting). We're asking for this change on the assumption that it wouldn't be an overly burdensome change for Renamers, please do let us know if that's wrong and we should take pause and reconsider. We're keen to balance potential legal risks and volunteer needs.

@ANakanishi_WMF - there were only 3 options, but you didn't really confirm. This would NOT be solved only if:

When volunteers REJECT a vanish request, legal EXPECTS to get a notice but does NOT.

If you are not *expecting* to get a notice, then this problem is solved. I think that is the expectation?

You mentioned that you are not getting reject notices, but you want to change the workflow so that you don't get reject notices -- but that is already the current state. So what do you want changed there?

This bug would have nothing to do with changing the input form to require content in that field (which I suspect could just be gibberish?) (That should be a new enhancement request)

Hi @Xaosflux thanks for the quick feedback. To clarify: this is NOT solved because WMF Legal is expecting notices, not getting them, and this is failing silently.

Two solutions that we're exploring:

1. Fix this bug, so Legal gets notifications once again; OR
2. Leave the bug as is, and change the workflow such that Legal doesn't get reject notices, but does have the ability to look up rejected requests and reason for rejection (preferred)

@kostajh @SimoneThisDot when you've had a chance to investigate this bug, please let us know your recommended solution for moving forward. Thank you!

Anakanishi, thank you!

For #2, these are available on wiki at: https://meta.wikimedia.org/wiki/Special:GlobalRenameQueue/closed ; currently 'WMF Trust and Safety' and 'WMF Office IT' may access this. That may be a good idea, even if #1 can't be or shouldn't be fixed. If your "lookup" workflow can be "ask TS to look it up for you", that can currently happen. While technically it doesn't require the fields to be populated with anything useful, trusted volunteers are unlikely to reject without documenting their reason.

Xaosflux, on #2 I’ve reached out to Trust and Safety for their support. Great idea - thanks for helping us connect the dots. I expect to hear back next week.

Regarding the rejected reason field, we’ll do some digging on response rate and quality before requesting any changes. Based on your feedback, it sounds like we may already be getting what we need.

Quick stats:
FEB 2025 had ~38 rejected vanish requests
JAN 2024 had ~41 rejected vanish requests

Source: https://meta.wikimedia.org/w/index.php?title=Special:GlobalRenameQueue/closed&limit=25&newname=&status=rejected&type=1&username=

Did a quick sampling and found some themes in the stated reject reasonings:

(1)What I'd consider strongly supported reject reasons:

• User is a long term abuser
• User is blocked on some project(s)
• User reason was that they wanted a rename, not a vanish
• User reason was that they wanted some other help
• User posted they wanted to cancel the vanish

(2) Renamer did not provide a reject reason

(3) Some reject reasons that may not be supported equally by all the volunteers:

• Requester didn't give type in a reason
• Requester has multiple accounts but isn't vanishing *all* of their accounts
• Renamer didn't agree with requester reason

Those later ones may require some discussion and training -- I know we'd rather keep this being handled by volunteers, and we should have consistent responses. I can be point for the stewards team to coordinate that - let me know if there is some additional foundation guidance first. (We can take that part off phab - feel free to email me: https://meta.wikimedia.org/wiki/Special:EmailUser/Xaosflux )

@Xaosflux really appreciate the quick stats, as well as your generous offer to run point on behalf of the stewards team -- thank you. I've reached out via email to discuss the data and foundation guidance.

In T374053#10638103, @Xaosflux wrote:

Anakanishi, thank you!

For #2, these are available on wiki at: https://meta.wikimedia.org/wiki/Special:GlobalRenameQueue/closed ; currently 'WMF Trust and Safety' and 'WMF Office IT' may access this. That may be a good idea, even if #1 can't be or shouldn't be fixed. If your "lookup" workflow can be "ask TS to look it up for you", that can currently happen. While technically it doesn't require the fields to be populated with anything useful, trusted volunteers are unlikely to reject without documenting their reason.

@ANakanishi_WMF following up on this, are you able to access https://meta.wikimedia.org/wiki/Special:GlobalRenameQueue/closed ? What more is needed to resolve this task?