-
-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow users to close their accounts and remove their username/profile #5052
Comments
Just copying @RichardTaylor's email here, as it provides good background insight for when we come to this issue:
|
Linking to: "Improve censor rules created by anonymise and close user account operation" #4922 |
Commenting to use the words self-service name / username removal to hopefully make this ticket easier to find. |
Consider if following this process all requests by one user should still be collected together under one profile - such a collection of requests could aid re-identification of an individual. What's probably most important for an automated system is being clear what it does, and does not do. |
Should consider how to keep records of this happening. Currently we have a case ref for each manually handled RTE request. |
A structured form that generates a more-or-less one-click admin confirmation is a much better position than what we do now, and I think a great stepping stone to feel out any problems that we'd want to finesse before allowing the user to close their account themselves.
I think this would be a great move. In exploring RTE we've refined our understanding that there's a difference between the account name and name included in correspondence (more value in the latter wrt our legitimate interests). Closing would have the benefit of making it much trickier for a visitor to link someone's entire request history, while still preserving the full request content. |
+1 on both close & anonymise and close options. There is some mechanics which would help us from a logging perspective that we can explore; but, the basic theory here is great. I think, based on recent discussions, having an admin action the request is the best way to achieve what we are looking to do. This enables us to ensure a request is logged 1, validated (e.g. sometimes there's things to check), a period of 'buyers remorse' is provided (e.g. we'll do This is cheap, cheerful, and a significant improvement as it allows us to automate more of the processes. In terms of buyers remorse - we want this to be as easy as possible for the user, but we know there is a risk of things not being understood well, or the user making the wrong request (perhaps they did want to anonymise, or actually do want to engage RtE in full). Having this period of time (which we could also call a cooling-off period) is a useful safeguard, both for the user, and for the support team. It is a useful 'value add' opportunity, with little actual time cost 3. Footnotes
|
I've analysed support mail that we dealt with during 2022, and 77.5% of threads in the inbox involving RtE requests arrived via our current contact form. There is a great opportunity here to set out the options to users before they get in touch, which could significantly reduce our workload in dealing with these. |
This issue has been automatically closed due to a lack of discussion or resolution for over 12 months. |
WhatDoTheyKnow users writing to us asking to close their accounts is becoming a notable fraction of support mail.
There may be an opportunity to reduce the administration workload by letting users themselves anonymise and close their accounts (the admin button for this operation was introduced via #3074 and #4869).
There are a number of reasons though not to do this:
See also letting users unsubscribe from all email from the system: #4603
The text was updated successfully, but these errors were encountered: