Problem - People merging duplicates merge the older PID# into the newer PID# and break everything.

LegacyUser

Alexis Hok said: Problem - People merging duplicates are merging old PID#s with completed families into the newer PID# duplicate they made. They don't know what they are doing and break all the old family relationships, notes, etc. I find lots of orphaned kids and spouses in the system due to improper merges.

Could you please prompt users to merge newer PID# duplicates into the older PID#s that have more information?

I'd even be willing for you to automatically assign the older PID# priority (or at least the PID# with attached children into the priority slot). It is really frustrating when I take the time to write a lot of documentation and get all the kids properly attached, and then everything gets lost because someone merged into a newer duplicate they made that is almost blank!!

LegacyUser

Tom Huber said: If you have found that to be the case, go through the change log and find the merge-deleted records. Then restore the record and it will revert to where it was just before the merge. The surviving record will have some oddities, but generally speaking most of the material from the restored record will be backed out.

The order of the merge is unimportant and long as relationships are maintained. What needs to happen is better comparison before merging.

Most bad merges are done by relative new users of Family Tree and they are not aware of what they need to do before they perform any merge.

That said, even old timers when it comes to using Family Tree can and do make errors in judgment and perform bad merges. So it is not something that is limited to new or inexperienced (with Family Tree) users.

There are two issues with the current Family Tree system when it comes to merges.

First, the side-by-side comparison is weak. This is especially true in areas where families lived next to each other for a century or more. My Huber, Clark(e), and Newman lines came from different parts of the country, but lived in the same area (usually the same township) for many generations. The families reused the same names for their children, so it is not unusual to find the same families with the same names marrying, even though they are not the same persons.

Second, when you look at a deleted person's record, it is a very limited view. We really need to see all the details, including "other information", relationships, and sources for that deleted profile. At least we can look through the deleted person's change log, but that is all. Seeing the entire record and the relationships is the only way to tell if the merge was a correct one or needs to be backed out (or the profile restored).

LegacyUser

gasmodels said: The major cause of breaking up families etc during merge is because the person merging is not bringing all the relationships to the left hand record. In families with multiple members and the complete record is on the right it means that there are many relationships that must be moved. It is essential to retain all relationships when merging.

LegacyUser

Alexis Hok said: I'm not sure you understand the magnitude of the issue.

Let me give you an example of how often this happens.
I watch my direct line ancestors and get weekly updates. Every week some new merge is made without properly transferring children or spouses.

There are 52 weeks in a year. So just in my direct line ancestors that is quite a number of mistakes to go in and fix (this weeks example is 15 children without a mother, and hopefully they will not lose their father and then their siblings).

Was it a mistake or did someone do it on purpose? Now someone needs to research 17 people to confirm all the family relationships (father, mother, children) and also to fix the relationships. While I'm confident about my ancestors and their children, even I need refreshers sometimes on the children and relationships with so many relatives.

The order of the merge IS important. Someone needed to click all 15 children and confirm they needed to be carried to the new family unit made with the newly merged mother.

Also, let's not forget there is a lot of history in the change history tied to that one PID now swallowed into a different PID, making looking at history and pulling out details and handwritten sources that much more tedious!

How would you know to even check for someone else's notes if you didn't know it was previously posted?

How many times do you open old merge PIDs to see if there were children or helpful notes not carried over to the new PID?

LegacyUser

gasmodels said: I do understand the issue - it is possible for the user to switch but I believe the many users want to have "their" entry be the one showing (ie they are the contributor). The way they accomplish this is create a new record and then merge the old one into their new record. At one time we did have restrictions on merging order for some records. For example Church membership records had to be on the left and all others merged into the membership record. That restriction was removed some time ago which made it easier to merge in any order.

I know this requires some work on your part. but what I would do is use the message system to contact those who make a bad merge and explain what they have done and why it was wrong. If you can also explain how to not make the mistake again, then you will accomplish two things (1) you will have taught the user something so they will not continue to make mistakes and (2) they can correct their mistake and you will not have to spend your time correcting.

LegacyUser

Alexis Hok said: Ah, I was replying to the other person earlier. I actually like the side-by-side comparison, but people do not expect to click everything manually. Compared to the major service Ancestry, you do not (they automatically combine all family relationships). Probably other services as well.

I recall this previous order you mentioned. What I am suggesting here to resolve the issue is to (a) add either a prompt window or (b) default position the older PID# (or the PID# with family) into the left/main position. That's all--not force, just default position on left side. Currently it defaults the PID you are currently at into the left/main position.

What you mentioned about wanting to make their work the newest is true in several cases. However, this incorrect merging is a major problem and I think it often comes from people simply opening the PID that needs to be merged (the newest one) and merging with the old one.

I have tried in the past to ask/teach people about the swap position, some reply some don't, some don't change. It is just so much extra work to research/fix 17 people suddenly every week. This could be prevented by a simple default position swap!

Edit: Another option is to automatically add all spouses/children/parents in the side-by-side, and then just have us the users unadd during the side-by-side, if that makes sense?

The loss of details, notes, etc. isn't as important compared to suddenly having to fix many family members due to improper merges.

LegacyUser

Adrian Bruce said: Sorry but as Tom says, "The order of the merge is unimportant [as] long as relationships are maintained"

To give you a for-instance - I might have created a family of 2 parents and 8 children in a new set of PIDs. We'll say that the 2 parents are legitimate dupes of 2 older PIDs but the 2 older PIDs have only 4 children.

If anyone merges the 2 sets of parents with the older PIDs on the left, they must do whatever clicking is necessary to bring the 8 on the right over to the left. Just having it "older on the left" hasn't made it any easier, the clicking still has to be done.

Now it may very well be that the typical problem that you're being hit with does happen to be solved with having the older on the left. I wouldn't presume to say that's not true, because obviously for you, with those PIDs, it's perfectly true. But it's not true as a general rule.

My own rule of thumb is to have the more detailed PID on the left.

LegacyUser

Alexis Hok said: Yes, I think experienced users plan to put the more detailed PID on the left.

Parents are less an issue actually, but you are correct they need to be carried over too, unless the duplicates are both attached to the same parents.

Thing is, most PIDs don't have 10-15 parents that need to be carried over (and of course not all families had 10-15 children), but tracking down and researching 15 children is a lot harder than a duplicate set of parents.

How about the merge order is less important to experienced users? The point is that relationships are not being maintained. Please don't make this a general rule or its only me having this issue. I am reporting a consistent issue, one I'm tired of dealing with, and I'm offering suggestions and really hoping something will be done.

To clarify, I understand how to fix incorrect merges when I find them. I reach out to others when I come across these (maybe less so in the past year than before). I don't need suggestions on how to properly merge, thanks though.

Edit: I think I misread your comment. You're saying how would they code to handle the issue if both PIDs had the same number of duplicated parents and children, theoretically it does not matter the merge order as none of the old data is lost (although again who opens the old merge PIDs besides experienced users). Alternatively, there is also the issue of how to code an understanding of older or new PIDs.

I'm not a web designer/computer science major, so maybe they have ideas, but alternatively these issues could be skipped by the 3rd suggestion: during the side-by-side comparison, automatically move all spouses, children, parents to the left (the same way sources are automatically moved to the left) and just leave it to us users to move to the right the relationships we want to edit. In this way no relationships get lost in the merge.

LegacyUser

Christina Sachs Wagner said: I may be confused, but are you using the term "bad merges" when you mean "incomplete merges"? I'd call a bad merge, one that merges two different people into one. I was not aware that it mattered which PID was on what side, as long as I moved all pertinent information to the left in order to retain it. To be sure, I was taught to switch the one with the most information and sources to the left, so it was an easier process. Seems like if dates for PIDs or ordinances were relevant, it would be visible on the merge page to evaluate as part of the process.

I do wish that a deleted person were more easily evaluated.

LegacyUser

Alexis Hok said: I didn't use the term so you may not be addressing me, but I think they are using it as you mentioned, and also as a catch-all for other issues.

Regarding the merge question: This gets difficult to explain. Theoretically, no it does not matter which PID is on which side, as long as you move all pertinent information.

However, it actually might matter to someone. Let me give some examples.

Example1:
While merging duplicates with the same birth date, you do not need to copy and overwrite the birth date with the duplicate...or do you? In one, someone left a note in "reason this information is correct" saying they got the birth date from a Bible at xx location. The other has no source.

So while both displayed the same information, the one with a note gets buried in the merge data.

Example2:
While merging duplicates, you copy over a more detailed birth date. Now it gives you as the source of information. So someone contacts you seeking where you got the information. You tell them it was from a merge. Do people know they can hunt down the original poster?

But this is not something most people need to worry about. My issue is a broken family, which I suggested could be reduced by defaulting older PIDs or PIDs with children onto the left. The kind feedback from others though also prompted another idea -- for them to automatically move family members to left as they do with sources.

LegacyUser

Christina Sachs Wagner said: Thanks for the clarification.

I guess I'm wondering if your suggestion to default to older PIDs assumes that it is the profile that holds the greater information and I'm not sure this is a valid assumption to be made in enough cases to be a viable solution. But maybe that's because the ones I created are often the newer PIDs with greater information attached. :-)

LegacyUser

Tom Huber said: Alexis, the whole thing boils down to what others have said, to make sure that all the pertinent information is carried over into the surviving record.

What I was talking about was when you run into a record where "all the old family relationships, notes, etc." has been lost because someone performed a "bad" merge (yes, it is an incomplete merge, but technically, it is still a bad merge that was done), then you need to restore the record.

At that point, you need to make sure that both records (the surviving record and the restored record) are actually for the same person. The side-by-side feature of FamilySearch's merge operation is not as complete as it should be. I never perform a merge without opening both records with each in its own window (not tab) and, on a large monitor, place them side-by-side. This can be done with monitors that are as small as 15" or even smaller, but generally, the larger the monitor, the more easily the two records can be compared.

There are many factors to consider, but if you are cleaning up after some bad merges, the only way to effectively take care of the situation is to restore the record and then perform the compare.

Note, if the surviving record is the one in which relationships, notes, etc., have been lost, then you'll need to work back through the change log of the surviving record and restore the lost information. There is no quick and easy solution.

But, as gasmodels wrote, any time a bad merge takes place, use the FamilySearch messaging system to contact the person who did the merge. The following works for me pretty consistently:

Every time someone makes a change or merge that I feel is incorrect, I use the FamilySearch message system to leave them a kindly written message that contains the following elements:

-- Thanks for their interest in making the person's record as accurate as possible.
-- The person or family involved and my relationship.
-- My thoughts and sources with respect to the changes they made.
-- The corrections I made to their incorrect changes and why I did it.
-- Request that before they make changes that they study the record, including the sources that are attached, any notes and stories that may be included in memories.
-- Remind them (if they have not provided a source or a reason) that sources are crucial to establishing conclusions and facts, and that a person's reasoning is needed to let others know what research and thinking was done to reach those conclusions.
-- What I did to correct what I perceived to be incorrect material.
-- Thank them in closing for their interest in making the record as complete as possible.

Note that one of the things that I ask is that the other person takes time to study the record, including the sources that are attached and any notes and stories that may be included in memories.

That means that I have to make sure the record is as complete as I can make it, with all sources attached, all pertinent information about the person, and what conditions were like at the time the person lived.

I also make sure that every conclusion has a reason statement, especially those in the "Other Information" section since we cannot (at this time) attach sources to the conclusions for those events and facts.

Communication is key to helping others. Every one of us, at one time, was new to the whole idea of genealogy and many are even newer to Family History (there is a significant difference between the two). We all made mistakes and we continue to make mistakes, even after years of experience.

There have been many threads about what to do with newbies who manage to mess up the records. FamilySearch FamilyTree is intentionally an open-edit system, allowing anyone to make changes. Locking records, forci… [truncated]

LegacyUser

Robert Wren said: Alexis,

I would be quite helpful to provide a couple of PID's of the persons to which this has happened. It would make it easier to see, understand and analyze. Re: "most PIDs don't have 10-15 parents" - I've seen PID's with a half dozen marriages, which may create multiple parents for children in a merge if each individual is not checked.

--------------Merging IS a potentially complicated procedure and CAN (does) cause some problems. ---------------------

Reasons I have heard regarding the choice of which (or what) to merge have been:
> My person's info is correct, so I want to keep it as 'primary'
> The change record is so long, i wanted to simplify the PID.
> My Ancestry "person" is connected to this FSID, so I don't want to have to reconnect. (Merging to PID's can cause a disconnect in Ancestry)
> It was done with the FS phone app (which links left to right)
> What difference does it make? (This topic provides that answer.)

As Tom Huber pointed out above, the "RESTORE" features is often the easiest way to correct (reverse) a 'bad' merge.

LegacyUser

joe martel said: Some great thoughts about Merge. Personally I survive the PID with the most/most correct information. If its a toss up I like to survive the PID that was created earlier. But earlier PID don't mean better data, and some often are sparse on Sources, created when little evidence was provided.

Merge is being looks at for re-design. Many of those aspects have been brought up here and in other threads and are being considered. Here's my list of stuff brought up about Merge:
1. By default, bring over all the unique relationships from the PID being merged away. The user can dismiss that for each relationship. If there would be a conflict the user can choose which relationship survives.
2. Flip the sides so the survivor is on the right in the web-client (corrected)
3. Show more info, (memories, notes, relationshhip info, non-vitals)
4. Deleted Persons show more info?
5. Better Reason statement UI.
6. Showing temple
7. Auto decide which PID should be defaulted as the survivor, by some magic algorithm, of # Sources, vitals...
8. Create a ToDo list of stuff to remind of stuff I need to do.
9. Merge, UnMerge - see results before commit
10. Move single Sources rather than all-or-nothing
11. Training, certification
12. Smarter guidance that says a potential Merge is probably not good because of ...
13. Better Changelog viewing, i.e. collapse of verbose Merges changes

As you can see the list is big and some are good ideas and others not and some will get implemented and others not.

LegacyUser

Alexis Hok said: I don't want to single anyone out, and I'd have to look through my past history, but if you'd like a current example here is the latest merge that popped up:

William Brannan
1804-1889 • LHZT-26F ★ Unwatch

Spouse Deleted
22 November 2018 by xxx
William Brannan ★
1804-1889 • LHZT-26F
Anna Malone
1804-1859 • LHH9-8G5

Spouse Merged
22 November 2018 by xxx
Anna Malone
1804-1859 • LHH9-8G5 → Anna Malone
1811-1859 • GMWH-55C

Reason This Relationship Is Correct
2 Anna in same set of siblings.

I have not researched this yet. At a glance it looks like someone was merging 2 siblings same name, but then broke her spouse and children links while doing so? Perhaps she meant to do this, but I don't think so. Note spouse William has 15 children with no mother now.

Both these surname are in my family tree, but I do not recognize these people and have no edits or research on them. Maybe this was a research angle I wanted to return to. As I said, this was just something recent that needs looking into.

Edit: if someone else wants to research/assist that person be my guest as I have 100 other messages from familysearch this week to check and a large backlog to check that is a bit too depressing to crack open, heh.

LegacyUser

Alexis Hok said: There is a lot I left out of my first message in an effort to keep things short and simple. For example, FamilySearch creates profiles for many marriage records pre-1900. If the spouse was previously married and under a different surname, a person might not find this earlier record when creating a new PID. Later, when finding the marriage record and duplicate, they will then need to merge. Likely, the newer profile page in this case will have more family connections than the older marriage record. This is just one example where I merge duplicates that don't fit the mold.

There will be lots of cases where the older PID may not have as many details. This is why I added the note the one with children be defaulted to the left position in an attempt to cut down on all the incomplete merges.

The switch positions is a great feature, I use it often. But for many users, I don't think they understand everything. They can only learn by trying, but to break 15 children from someone is a hard way to learn and a tedious thing to fix every week. FamilySearch adds new things all the time to help, like now if you add the mother into a family unit, she will automatically apply to all children in the missing-mother family unit, which has been a big help (something they added recently in the past few years).

I really don't need a lot of bells and whistles while merging. I'm afraid extra options will slow a 'release' fix. No option will be perfect, but the best one I've seen so far is for all relationships to get moved to the left, and then leave it to the user to unadd/movetotheright the relationships they don't want to carry. This will still require people to move and click things properly, but at least it would cut down on all the broken families being made all the time.

LegacyUser

Adrian Bruce said: "the best one I've seen so far is for all relationships to get moved to the left, and then leave it to the user to unadd/movetotheright the relationships they don't want to carry"

Agree totally - that's what Joe mentions below with "By default, bring over all the unique relationships from the PID being merged away. " (The only thing there is that you don't want to bring something over that would duplicate a marriage (say) that's already there. I did that once and wiped out the marriage date and place that I'd just spent a while entering!)

LegacyUser

Alexis Hok said: "Alexis, the whole thing boils down to what others have said, to make sure that all the pertinent information is carried over into the surviving record."

I am so sorry, I thought I said this was the problem in my original post. I remember simplifying the post before clicking submit, so maybe I made a mistake. Is that why I keep getting so many responses explaining the same thing over and over?

When people are merging duplicates, old PID#s with completed families are not having all the family members carried to the new PID#. I'm not reporting a bug, I'm saying people are not clicking all the family members to add during the merge.

Why do people not get click-added during the merge? There could be many reasons. For many users, I think they don't understand the merge process on FamilySearch. (maybe they expect family relationships to be automatic, like it is on other programs such as Ancestry.)
People can only learn by trying, but to break 15 children from someone is a hard way to learn and a tedious thing to fix every week.

Maybe none of my suggestions were perfect, maybe no solution will be perfect, but something needs to be done to cut down on all the broken families due to merges.

I love the side-by-side comparsion during merges, I just am having a problem with people not click-adding family members during the merge and breaking all the family ties.

My best solution so far is for all relationships during the side-by-side comparison automatically be moved to the left, and then leave it to the user to unadd/movetotheright the relationships they don't want to carry. This will still require people to move and click things properly, but at least it would cut down on all the broken families being made all the time.

(I think there is value in adding merges into old PIDs with more history/information displayed, but the family relationships during merges is the real issue).

Sorry for the long posts and thank you for the feedback.

LegacyUser

Alexis Hok said: Thank you for the feedback, Adrian!

Christina, regarding merge order I talked about earlier, here is an example of someone recently merged:

Parent Merged
17 November 2018 by xxx
PVT John Bell
1753-1800 • K2F5-R8Y → John Bell
1753-1800 • GMZD-Z9M

Note I think she moved everything from the old PID to the new PID. She copied all my notes over properly. That's great, although it now shows she is the poster in 2018 and there is no change history.

You would have to dig deep into the merged person's change history to see all the change history and the original poster of all the comments.

https://www.familysearch.org/tree/per...

I don't mind it now shows someone else as the creator of the comments. The reason I post notes and sources is to help people properly identify ancestors, to prevent confusion with other people of the same name, to help in research, AND to give some story on the person.

No one would need to ask her where she found the source information because I posted sources and images all over the place on that profile back in 2013-2016 and she properly copied it over.

Why did she move all that data though to a new PID#? I don't know, maybe she got scared some old source data from an incorrect past merge (by someone else) I fixed would pop up again.

Actually, I really should make sure she carried over all the children properly, but that takes time to open up and do all those comparisons.

People merge all the time the old PIDs into new ones, for whatever reasons, but her new PID had not the amount of detail as the old one until she merged (and I know because I'm the one that posted all the comments there).

LegacyUser

gasmodels said: Alexis, one last comment - your ideas are appreciated. Many of us have experienced the situations you have encountered. For myself I have only had it happen a few times (probably because my ancestry is not tangled with many other users). Everything you have described makes sense, what many of the responders have attempted to do is provide you suggestions as to how to work with the current system so as to reduce you "pain". This does not mean that your suggestions are not valid and I am sure will be considered going forward as the developers do pay attention to these threads (see comments from Joe Martel above).

Please, continue to follow Get Satisfaction and contribute as you desire. Your comments are valuable to those of us who are involved.

LegacyUser

Christina Sachs Wagner said: Having had to untangle 6 identities (all bore the same name) who were merged into one, I'm more than a little hesitant to vote to have anything that moves automatically in a merge. It was pretty crazy trying to figure out which sources and which children belonged to which Charles. Imagine 6 of each census attached to one big incorrectly merged family! I think it took me more than two weeks to straighten it out.

LegacyUser

Juli said: Christina, I agree that anything that makes incorrect merges harder to disentangle is a Bad Thing, but I'm not sure that moving everyone over by default would do that. If they're moved over, it means they're still attached, rather than floating free somewhere, never to be found again.

LegacyUser

Paul said: Yes, its definitely best that everything is moved across by default - as Juli implies, at least it is then much easier for the mistakes to be sorted out (immediately or even later, by someone else) than leaving individuals completely detached, with far less chance of correcting relationships.

LegacyUser

Jeff Wiseman said: https://getsatisfaction.com/familysea...

LegacyUser

Christina Sachs Wagner said: That makes sense! Thanks for clarifying for me!

LegacyUser

Jeff Wiseman said: For kind of an exception to this approach in merging, see:

https://getsatisfaction.com/familysea...

LegacyUser

Tom Huber said: See the thread at https://getsatisfaction.com/familysea..., which offers a great solution to the problem.

LegacyUser

Alexis Hok said: All this talking about merges has reminded me of something.
It is the ONE thing about Family Tree I don't know!

Here it is, my one question:

When merging someone with 'living' hidden children attached that you can't see.....what happens to those relationships during merges, since you can't see them and carry them to the new PID?
Do they automatically get transferred over?

Or, do they get broken.

It is why I always prioritize people with children to be the main surviving PID, even if the other PID has more details or is older. Just to be safe. I usually leave modern PID alone though...

LegacyUser

joe martel said: I need to clarify my point #2.
The enhancement request would flip the survivor in the web-client to be on the right-hand side. Today the survivor is on the left.

Some say flipping it is required to match other UI that put this on the left and that on the right.

I will correct my post above.

LegacyUser

Jeff Wiseman said: Please forget #7. That will totally destroy all sense of consistency in what is normally a fairly complex situation to start with. Please don't do it!

#2 is going to cause enough confusion as it is if implemented. Only because it has been like this for years now. I can guaranteed you that I personally will screw up at least 2 or 3 merges after that is done. If you need to do it for consistency, then fine. Just don't plan on changing it again later :-)

And announce it when it is put into place, please.

LegacyUser

Jeff Wiseman said: Just curious. The Website has had it this way for a long time. Are these "other" UIs that do it in reverse for mobile devices that came out long after the standard web interface?

If so, I have to ask why THEY were designed backwards and now we have to fix the problem by changing the original product?

Just saying....