Deleting alts about writeoff

[VanTanev]

What are we looking for feature-wise here?

• Ability to delete alt accounts.
• What happens to stories under alt accounts when account is deleted? Forbid deletion unless account empty? Also delete all stories?
• What does "changing" an alt entail? Are username changes allowed? What about username changes on main account?

Moving sounds too complicated to immediately tackle, but deleting stories when an alt is deleted might be undesirable (given that it's not available right now at all?)

Maybe best to split in several small tasks and do them one by one.

[RogerDodger]

(Alias, alt, and artist are all synonymous.)

Each user has any number of artists. Almost all public user data (comments, entries, and guesses) is considered as belonging to a particular artist. In this sense, deleting an alt is much more like deleting a user, which is to say very messy.

(1) Soft delete with a flag in the artist table (so it's reversible)
(2) The user's active_artist_id, if equal to that this artist's id, is set to another owned by that user1 GET /artist/ will 404
(4) Any view where the artist's name appears should instead show [deleted](or some other string)
(5) Any artist listing (scoreboard) should the artist

I don't think stories should unpublish nor post bodies be deleted, since I'd rather the act of deletion simply being SET deleted=1 (such that it's not destructive).

Merging alts on the other hand is relatively simple. You just have to change the artist_id of everything that belongs to the artist (entrys, posts, and theorys) to the target artist's id. On the other hand, while being simple, this is destructive.

Completing (4) will also involve completing #6.

In both cases, you have to handle the artist name as it appears post replies. That is, when someone quotes a post, it's rendered to, e.g., >>RogerDodger (i.e., denormalised), so any post referencing that artist's posts and any post that artist's posts reference (since the post reply header is also denormalised) need to be re-rendered.

In any case, I think the only use-case that's really desired right now is to delete freshly made accounts that have no (or few) comments and no entries, such that their artist swap list doesn't contain dummy accounts. So restricting deleting/merging to only accounts with no entries nor guesses should make things a lot simpler, since you'd only have to handle orphaned posts.

---

[1]: Deleting artists should only be allowed if the user has more than one artist, since a user having no active_artist_id will prevent them from doing anything.

[ReallyNotAHat]

More non-programmer design ideas incoming...

I've thought about this a bit more since, and I think you might want to consider arranging the workflow to give a bit more importance to someone's email/login over their artist name.

Right now, on the site, we have two buttons on the top right; our 'original account name' and our 'currently used' account name. This kinda creates a false dichotomy, because if I understand what's going on correctly, our 'original name' is no more special than the 'alt names' we create later.

So I'd suggest, however you set the rest of the functionality up, to change the rightmost button from 'original account name' to use our login email address.

Under that dropdown, then, you could put a 'manage authors' button, which would allow us to do whatever we're allowed to do with deleting alts. A compilation of all stories published under that login (combining across owned authors) might be nice as well, so if I want to find a story that was published on an alt I don't need to try five different alts before I discover which one I was using at the time. Simply stacking the 'user page' thing that each alt has might be enough, maybe with a collapse, which (if story management was allowed from those pages) would also give a centralized place to unlist/unsearch stories.

This should make the nature of 'alts' clearer to people, as well as allow someone who wants to 'rebrand' themselves to do so without needing to re-register their email or whatever.

[RogerDodger]

From a UI perspective communicating the distinction between users and artists is pretty complicated, because such a distinction doesn't really exist in most places. Most places are one account per pseudonym.

The way I've currently tried to make it distinct is that the ~User dropdown contains controls pertaining to the user (email settings, site preferences, password change, etc), whereas the @artist dropdown contains controls pertaining to the artists (swapping between which is active). The use of ~ for users is from Unix, and @ for psuedonyms is from Twitter, IRC, etc.

Now, that distinction isn't exactly super obvious, and I don't pretend it is. The most confusing part about it is that users automatically have an artist created for them that has the same name as their username. But I think the alternative of making the sign-up form more complicated is worse. (I could be wrong.)

As it currently stands, I think most people have come to understand the distinction, even if they don't use the same terms as me.

Emails aren't unique nor used for login details. They're only used for notifications and password recovery. Displaying them as the username would be misleading. I understand a lot of places actually do use emails as a username, and if the writeoff site did it the distinction between usernames (used to login) and pseudonyms would be clearer, but I don't like the idea of emails being used as a unique identifier because then they're difficult to change.

All that said, this is really a good idea:

Put a 'manage authors' button [under the ~User dropdown], which would allow us to do whatever we're allowed to do with deleting alts.

That page could also be where people merge or rename their aliases, and where they make new ones. Filling the @artist dropdown with an "Add alias" button is a bit silly, since it's not something people do very often.

[ReallyNotAHat]

Mmm, fair enough. Although it might be nice to have some difference between the user name and author name, it's probably not necessary or useful as the site now stands, so complicating the sign-up screen is unlikely to be worthwhile.

When working/thinking about author deletion or story moving, it's probably also worth considering how to use the 'Anonymous' account, as well. Perhaps someone could delete an account, but elect to move all the stories/comments to the Anonymous name instead of scrubbing them?

I'd picture asking to delete an author name giving a few options:

1. Wipe/Merge/Anonymize/don't touch comments
2. Wipe/Merge/Anonymize/don't touch stories

Where I could set the each one separately.

Although, to be fair, I'm a bit mixed on the 'merge' idea. I do think it would be neat, but... having comments and stories change from one owner to another is a little... I dunno. I'm not sure I like the idea, as much as I like the idea of the idea, if that makes any sense.

Anyways, the Anonymize option would basically give all the stories/comments to the Anonymous author. If someone wanted more control than that, they'd probably need to do it somewhere other than the 'delete account' option.

And tbh, the only real reason I want a 'delete account' option is because I have, like, three Horizon alts I made as a joke, and they're cluttering up my alt dropdown. :P If there was simply a way to hide alts from that menu, I'd be happy enough; maybe a checkbox somewhere in the hypothetical 'manage authors' page to display/hide them from there.

Honestly, I do kinda like the 'add alt' listing in the dropdown, because it shows how easy making alts is. The alt features you've built are one of the more unique things I've seen on the site, and having it front-and-center like that is kinda cool.

[RogerDodger]

And tbh, the only real reason I want a 'delete account' option is because I have, like, three Horizon alts I made as a joke, and they're cluttering up my alt dropdown. :P If there was simply a way to hide alts from that menu, I'd be happy enough; maybe a checkbox somewhere in the hypothetical 'manage authors' page to display/hide them from there.

Implemented.

Tabling the deleting alts idea for now, since the main use case is solved with marking them inactive.