[openstreetmap/openstreetmap-website] Account deletion cool-down period (PR #4313)

[Andy Allan]

I'd like to know more about the purpose behind the proposed delay, since without that being clear it's hard to review the implementation. I don't have any access to DWG discussions (nor might other developers in future working on this).

There is mention here about open changesets - is it imperative that accounts remain open until the last changeset is closed? If so, why? My only guess would be some kind of moderation tool that is waiting for closed changesets, but I assume (perhaps incorrectly) that it's nothing to do with adding more data to an open changeset after the account is closed. Or is it some other reason?

If it needs to wait for the changeset to be closed, then why is there a configuration value? Why is it not based on `Changeset::MAX_TIME_OPEN?` Or if there is some moderator process that needs to wait until all changesets are closed, would it need to be `Changeset::MAX_TIME_OPEN + some_interval`?

I've read the recent discussions on user account self-close and reopen (#4018). If I understand correctly, all this PR would do is prevent a display_name from being quickly reused on another account - is this correct? Is this the only goal? The miscreants are presumably using fresh emails every time, since emails are currently still retained (#3488).

I have a list of suggestions on how to improve the PR, but it would be great for me to have the purpose and goals clear in my own head first, otherwise I don't want to make unhelpful suggestions based on an incorrect picture.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/4313#issuecomment-1779595580
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/pull/4313/c1779595580 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20231025/e4e5551e/attachment.htm>