Community moderators used to be able to merge user accounts but that was removed on the basis of privacy concerns, especially the log-in credentials (as I understand).

I am asking for the reinstatement of this feature in the specific case of a merge of an Unregistered into a registered one. In this case there is no credential issue. If the email / real name fields are a concern they could be wiped from the Unregistered account at the time of merging.

  • 3
    To heck with moderators having to do this, users should really be able to do this themselves with unregistered accounts. Aug 10, 2013 at 8:30
  • @CodyGray Shouldn't at the very least I be able to do this for them rather than having to fill out a form and wait?
    – Mr.Wizard
    Aug 10, 2013 at 8:31
  • 1
    Yes, I'm agreeing with that. But I'm saying that I think they should really be able to do this themselves without requiring any kind of intervention, whether from moderators, developers, or sentient hamsters. Aug 10, 2013 at 8:37
  • @Cody what protection do you propose to keep any random user from claiming a particular Unregistered account and its reputation? Many of the accounts I'm concerned with are abandoned, meaning that the owner no longer has control of them. I have to go by email/name/ip/writing-style to determine that they are in fact the same user.
    – Mr.Wizard
    Aug 10, 2013 at 8:38
  • @Mr.Wizard Merging with email looks promising, may be system should automatically do so on basis of emailid... But on basis on name/ip/writing style. thats gonna be tough job....
    Aug 10, 2013 at 8:50
  • Unregistered accounts work by storing cookies on a user's machine. So my thought was that if you had the cookie, you could associate that unregistered account with your existing registered account. I dunno if that's possible, though. If you don't have the cookie, like you said, it's going to be a guess, and I'm not sure if that should be something that moderators do. Aug 10, 2013 at 8:51
  • @CRUSADER Just to be clear I'm not proposing automation for that, I'm saying those were/are/would be my checks if a user asked to merge accounts.
    – Mr.Wizard
    Aug 10, 2013 at 8:53
  • @Cody Let's assume the cookie is long gone. At that point I can look at the IP history, email/real name fields, and potentially the site-specific knowledge and style of the users. Who is better qualified to decide on the merge? Do the devs have other information that makes the choice obvious? If not isn't there time better spent elsewhere?
    – Mr.Wizard
    Aug 10, 2013 at 8:55
  • 1
    I thought the whole point was that users had to request a merge. For privacy and other reasons, moderators aren't supposed to go around hunting for accounts that should be merged. Why is this even necessary if the users don't care? Aug 10, 2013 at 9:01
  • @Cody I think this question is still valid if that is the case, but as I have been hunting for duplicates could you please support that statement with a reference?
    – Mr.Wizard
    Aug 10, 2013 at 9:03
  • @Cody I think the users do care; some of them don't even know a merge is possible, others have asked and I had to direct them to a form. Still others have "lost" question by forgetting to sign in before posting (I didn't think that was easy but apparently it happens).
    – Mr.Wizard
    Aug 10, 2013 at 9:05
  • Given that elected community moderators already have tools to flag these and indicate they are a moderator asking for merges (and that in my experience - these requests are completed in a matter of minutes to hours), What is the use case for needing better tools? Are you defining "community moderators" as anyone with voting privileges or something new you want to add to the hierarchy?
    – bmike
    Aug 10, 2013 at 13:06
  • @bmike by "community moderators" I meant elected (or pro tempore appointed) moderators, as distinct from SE employees. I don't see the need to trouble the sysops unless necessary, and I am arguing that in this specific case it is not necessary.
    – Mr.Wizard
    Aug 10, 2013 at 13:25
  • 1
    I'm tossing this on our meeting agenda for the day - will post back in about 24 hours or so, maybe sooner. Just letting you know this has been seen and is being discussed (or will be, soon).
    – Tim Post
    Aug 13, 2013 at 5:56
  • @TimPost Thanks; I'll be interested to know what comes of it. I may not yet understand the reasons for (dis)allowing merges; if this is not approved please keep a few bullet points so I understand why. By the way, I'm the TL now; I've been trying to chat with you for a couple of weeks now I think and I'm always here at the wrong time. If you're still around could you join me there?
    – Mr.Wizard
    Aug 13, 2013 at 6:25

1 Answer 1


We talked about this at length. The tl;dr of my reply is that we're not going to spend any more effort making a fundamentally broken system even worse than it currently is, no matter how appealing temporary stopgap measures might seem.

Per your comment, I think it's a good idea to go into some detail as to why we took the feature away, why the system is broken and where we want to go with it. I'm going to try my best to not get too winded here, but there's a bit of ground to cover.

You have a good idea.

I'll start with your idea, and why it's actually a very good one. The worst thing that could possibly happen if a mistake was made is a few strange posts get associated with an unwitting account; this is easy to reverse. If the system required that the email address be the same for the source and target, this would be pretty safe to implement, and that's why I brought it up internally.

But this shows how the system is broken, really broken. We should fix that.

We still end up with moderators unable to use a tool half of the time where some of the time a feature is visible. Say that out loud if you like to get a grasp of just how absurd it actually sounds. When the ability to merge was originally taken away, I strongly recommended that the option remain and just put the merge in a queue where the community team could review and action it. For some reason, we didn't like the idea of another queue at the time, now were coo coo for cocoa puffs queues.

Ideally, we just give the feature back to you almost just as you had it, after improving the facilities we have in place to let users better help themselves and improve the tools that we have to process merges that our users or the system can't handle on their own. There is currently a developer only accounts queue that a few people on the community team can access in order to approve system initiated merges that don't quite match up, this could easily be fed by moderators clicking on the merge button.

You're right, we need to think about why we're being so careful.

Our privacy policy is a contract with our users. We promise to safeguard personally identifying information and not reveal it to any third party, this policy is audited on a yearly basis. We trust our community moderators completely, and only require that they accept a very plain language moderator agreement before they can see anything that our policy says is confidential.

We also engineer around the tendency for human beings to make mistakes, moderators now need to click special links in order for things like a user's email address, I.P. address or real name to become visible. This helps to prevent accidental or unwitting disclosure, even by someone looking over your shoulder.

It's very hard to make a mistake when it comes to the handling of personally identifying information.

When you merge an account, those possessing what becomes two sets of valid credentials come in contact with this information. If a mistake was somehow made and the two accounts did not belong to the same person, we've just violated our own privacy policy. Moderators are not paid, and should not have the burden of worrying about being held accountable for this sort of mistake. It's not that we're any better than you are when figuring out when merges should happen, it's that were paid to make these decisions and ultimately own up to any mistakes.

We need a simpler mousetrap.

Going forward, the sanest thing to do is offload as much of this responsibility as we can for merges to the users that need them, and improve our own facilities to handle what should become exceptional cases when the system can't process their request. At that point, we can just put the option back in your grasp and continue to handle ourselves whatever the system can't.

  • 2
    Cocoa queues? I thought you guys were a windows shop.
    – Kevin
    Aug 14, 2013 at 16:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .