Merges need to be monitored Just like photos
Please, Please, Please
I have suggested this many times: The largest part of the messes in FS Family Tree are caused by improper merges. I see merges with the same name, birth years but many years difference in the death year. I ran into a person merging 3-4 individuals that I questioned why he was merging definitely unique individuals. His answer was to merge to get the right information?????? And asking what I meant by unique individuals. He found another person to help him "fix" the situation who was not much more knowledgeable and didn't understand unique people. The family is not quite right and got belligerent with me for trying to fix things. When turning him in for abuse, I was told it was not. Obliviously just under the radar. I then removed my real name and personal email contact, stopped relationship viewing and blocked him to protect myself.
That means Record Hints from merged ancestors are being attached incorrectly. In Utah it was acceptable to have multiple wives and children at the same time. Not in Pennsylvania with the Mennonites. It's bad enough that one family gets messed up, but then it compounds to the previous generation and the following generations.
This is being compounded by youth as early as 8 being set free in Family Tree. They are not monitored, mostly because their parents have no concept of what Family Tree is about.
***In a previous comment I made, the inmates are taking over Family Tree. Pretty soon there will be very little validity especially in the earlier years.
Suggestions:
Youth should not be allowed to do merges
Newbies to FT should not be allowed to do merges
When merges are done, like photos need to be review before allowed to complete.
If it is not a viable merge, the person should be notified as to why.
If someone finds a messed up family, there needs to be knowledgeable individuals to fix that family and while being corrected-stop any more merges.
I know the reply, who is going to do this!! If these steps are ignored, *** above will continue until it will take a millennium just to fix FT and another millennium to do what we should have been doing in the first millennium.
Comments
-
No, please, absolutely not! Merges subject to review like photos would make it completely impossible to clean up the index-based duplicates that the Family Tree was seeded with a decade ago and that I still spend a considerable portion of my time dealing with.
I think a better solution would start from the other end: what if improper merges were as easy to undo as an incorrect name change?
2 -
If that suggestion were to be implemented, I just might give up using the FSFT altogether. Nearly every item I upload to memories is restricted, as not permitted, and I have to beg for review by person. This happens even with my own proof statements. If I had to do that with every merge, I would never complete any work.
2 -
Merges already are monitored in every part of the tree where someone cares. That's what the Following lists are for. Who better to repair a bad merge than someone who cares enough to Follow the affected profile?
To me this suggestion seems unnecessary. @SandyKJ, perhaps we are not understanding what you mean. Could you clarify?
0 -
Photos are reviewed to make sure they are family safe. It takes hardly any time to get them approved.
I am watch families being ruined by merges that should never have been done by those who don't realize the devastation that is created when merging totally unique individuals.
Here is a simple merge that has to be undone which I have not fixed yet: Susan Flowers GM6W-CZM. Her page with several husbands and children that the "math" doesn't work with what marriage dates are available. Look at Show All and Filter by Merges you will see Susana Flower born 1845-1928 has been merged with Susan Flowers 1845-1940!!!! Bad merge. Once a mistake is made, record hints for both those individuals show up for the surviving ancestor and when attached compound the situation. Particularly bad when the one who died in 1928 shows up on a census in 1940. This is happening all the time. Just because they have the same death or birth dates and similar names does not mean they are the same individual and yet people make that mistake all the time.
Now look at this: Janet Verch Ienen 1550–1589 LKKM-HJT. Someone has cleaned this up. The last time I looked at her page, she had 7 SEVEN husbands and 3 sets of parents. Again look at Show All and Filter the Merges and see the varied birth/death years and different names that show up.
Another Anna Catherina Muller about 1645 – 18 January 1693 L85C-DRD Her page is a mess with husbands and even parents mixed up. Same thing Show All and Filter by Merges. There are at least 3 different ancestors merged together in there.
The more merges completed the more Family Tree brings up other suggested merges of similar individuals and people follow through blindly. With Family Tree being a world tree with 1.2 billion names in Feb 2019 there is no way that they can be monitored. We are all interconnected.
This is a small sampling of what I see and spend more of my time fixing bad merges, separating out children with several parents/spouses to be with the right parents/spouses and helping others to do the same.
I have to admit I have fixed a few of my granddaughter's bad merges and she is very active in FS and 22 years old. One of our ward leaders is getting 8 years old and above their own accounts. Do you think they will be monitored???
0 -
My main concern is seeing merges done improperly over and over again. Part of it seems to be a lack of guidelines to follow. I know I am finding more and more bad merges as I dig deeper into my tree. I am not versed in fixing them and so, more often than not, I just leave them hoping no one else will make it worse.
I think who merges is critical. the example above mentioned youth of eight years age being allowed to work in the Tree. That is scary. Who is monitoring them? Limiting what they can do until they are proficient is a good idea.
I hove been told training is almost impossible as there are so many variables. Are there some basic rules that should be taught and used.
I like the idea of having merges checked before they are implemented. How to do it is a good question. Surely something could be set up.
It has gotten bad enough I am thinkin of making Ancestry my go to tree and letting FamilySearch lag behind.
1 -
Let me describe the other side of the equation. Perhaps it will be enough to convince people that impeding merges with any sort of approval process is a Supremely Bad Idea. (And it's not true that photo approval takes "hardly any time". Half an hour is the absolute minimum I've ever encountered, and sometimes it takes days of back and forth.)
A decade ago, Family Tree was "seeded" with profiles from a preceding system. These profiles were based verbatim on index entries, and beyond linking parents to children, they made no attempt at linking up families. That task is left to us, the users of Family Tree.
For reasons that are beyond my (non-LDS) ken, most of these legacy profiles in the area I work in (greater Hungary) come from the baptisms of females. (Or males misindexed as females.) Whew, that approximately halves the amount of work I need to do. But it means that if a couple had five daughters, then there are five copies of Dad and six copies of Mom (one of them from her own baptism). That means eleven merges just to assemble about half of the one family -- and then I can start on Mom's sisters.
In practice, it's not even as "simple" as just doing those eleven merges. There's misindexing to deal with, the very real chance of same-named couples, and at some point, one needs to add in the boys, too. Last night, I was dealing with a family that legally changed its surname just after child number 4 was born, so Possible Duplicates was completely failing to find anything. So finding those eleven profiles takes time, as does making sure that they actually match. If merging them had an added wait time -- even of just half an hour -- it'd take two evenings just to assemble one family. That's just not workable.
And I have it good, compared to places in England, where there are legacy profiles based on marriages, too, and there are often multiple indexes -- and thus multiple copies of profiles -- for every event. And it's not just the girls, there. A family can easily take thirty merges (or more) to fully assemble. Do you really, truly, honestly want to subject all thirty of those to an approval process?
What would an approval process even look at? The superficial details like names and dates? Those are exactly the things that lead to bad merges. The actually-telling details, like occupations and godparents, are not in any index and are thus unavailable to any sort of bot. How would you work around that?
3 -
Agree, Julia.
My 2nd great-grandparents had 11 children, all baptized in the Archdiocese of Newark, New Jersey. The changelog shows that I have made 10 merges of Patrick Hughes, my 2nd GGF, and 6 for my GGF, Joseph Hughes. An equal number for each of the children of Patrick. And on and on and on.
0 -
To dog-pile on top of Julia's comment, the number of duplicate profiles imported by FamilySearch was so huge that for years afterward the total number of profiles in Family Tree decreased. Far more profiles were being merged than were being created. That was the point! FamilySearch were aware that the old way of each and every genealogist working in isolation was creating vast armies of duplicate profiles, often with errors, and the best (and ultimately the only) solution was for everyone to collaborate on one massive tree, with one unified collection of historical records and one global place names gazetteer.
My contributor stats page says I have created 27,485 profiles. I believe I have merged far more profiles than I have created. In the past 3 days alone I merged 81 profiles.
This recorded webinar by James Tanner goes into the backstory about the need for such massive merging: https://www.youtube.com/watch?v=swa3Ub56dKI
2 -
Well, something needs to be done. And it seems to me that a perfect place to start is to not let children on Family Search to run wild. I suspect that a lot of the "mistakes" are being made by them. They see people of the same name and merge them. They are not paying attention to dates, places, relationships, etc. I recently had an incorrect merge on my great-grandparents that appeared to be done just because the names were the same. The correct family (mine) was in a completely different county. It was so convoluted that I had to seek help from someone with greater knowledge than me to help me untwist it. Usually when I see questionable merges, if they are simple, I fix them. If they are not, I leave them alone.
1 -
I don't think we can blame children for any bad merges in Family Tree. They're much better at following directions and paying attention to details than many adults.
But BarbaraJean's comment points out why bad merges are especially objectionable: they're very hard to fix.
This is why I think the solution is not to impede merges, but to somehow make them easier to undo. I just haven't a clue how to do that.
3 -
This is why I think the solution is not to impede merges, but to somehow make them easier to undo. I just haven't a clue how to do that.
If we could see the merges made by another contributor, and the order in which they made them, we could maybe roll them back in the reverse order.
But, is that really necessary? For me, the occasional RESTORE buttons in the Change Logs do the job well enough.
Usually there some reason in the profiles that provoked the merging, so I want to change the profiles anyway. So, I don't worry if using RESTORE does not perfectly restore the profile.
0 -
It's not the profile itself that's hard to get back from a merge -- as dontiknowyou says, there's a Restore button for that. It's all of the relationships and sources and other information that gets Really Complicated Really Quickly. And it all depends on approaching from the right direction: if you find a child attached to parents with impossible dates or places, how do you tell whether it was the child or the parents who were incorrectly merged?
Sometimes what I really want is a great big "ctrl-z" button that I can just keep pushing until it all starts making sense again.
1 -
I encountered one this week that was such a mess that even restore couldn't fix. It took several hours, and I think I finally have it all sorted.
0 -
I suppose no one looked at the links to individuals I suggest to view the messes caused by excess merges. As Aine stated above even roll backs can't fix because bad merges were compounded in other preciously bad merges. Trying to keep track of all those unmerges and making sure the right ones were merged together and their family members were properly linked and the sources were separated out. I tried to fix a mess using beta.familysearch.org and finally gave up after making 2 pages of notes and still not getting to the bottom of the mess, being so confused and gave up.
Yes, I understand the seeding process and most of those have already been merged. The merges I am talking about are now, compounding previous merges:
Look at this merge done 14 August 2022. This is one of the examples I keep running into. Why would you merge Sellen and Zellen with 1666 and 1690 birth dates? Because Sellen 1690 has previously been merged with Zellen 1666 in this persons page. The second one needs to be better investigated. There are 21 (twenty one) merges showing on his page not including the merges within the people that were merged into his name. And because people keep adding individuals from old GEDCOMs, many not sourced, with wrong family relationships and information into the system not realizing they are already in the system, updated with better information. And so the bad merges continues.
Here's another one 28 August 2022
Really?????
If merges were monitored, people could be notified of why it is not a proper merge, alerting them and helping/teaching them to be more careful. FamilySearch would be able to tag and straighten out problems before the families become totally corrupt. As this continues Family Tree will no longer be touted as the most correct world tree.
1 -
Many of us share your pain at having to untangle what are often very messy merges. However, your idea of "FamilySearch" monitoring such work and restricting work involving merges to only certain users is totally impracticable. How do you imagine FamilySearch could assign enough employees and volunteers to keep a check on the work of the huge number of worldwide Family Tree users who are working within the project every day?
I have stated myself that I can't see how the project's aims can ever be met if the current open-edit format remains as now, yet I admit I have no concrete proposal that I believe could improve the present situation. Every time I stray away from work on my closer family members I find dreadful work being carried out. Is this being performed by young children? Perhaps mental health problems could be involved, or sheer vandalism, or simply complete ignorance of the way genealogy works! Who knows the nature of the people who are doing such damage?
You say: "As this continues Family Tree will no longer be touted as the most correct world tree." I have never seen this opinion being offered over the ten years I have worked on the project - a desirable ambition perhaps, but - whilst there are parts of the tree that are extremely reliable - some of it is a complete work of fiction. Multiple individuals have been reduced to one, composite person - who, nevertheless, might have several sets of parents attached, none of whom ever lived within a hundred miles of the other. That is an extreme example, of course, but one which I encounter on a regular basis.
This is why many FamilySearch employees encourage us to stick to work within our immediate families - they realise the complete nightmare it would be for an individual who took it on themselves to try to sort out even a fraction of the dreadful work that has been carried out by certain users.
In short, there is no direct answer to the problem that so concerns you (me and many others alike). If there was, FamilySearch would have devised a system by now that would take care (through monitoring, programming or otherwise) of this awful problem with incorrect merges.
At least the open-edit design of Family Tree does allow us to put little corners of it right - totally impossible with those uneditable trees on Ancestry, etc., which will probably remain unchanged - with their totally incorrect pedigrees - until you and I are long passed!
1 -
@SandyKJ wrote: "I understand the seeding process and most of those have already been merged."
Um, no, they have not. Not by a very, very long shot. There are still hundreds of thousands -- if not millions! -- of index-based duplicates in the Tree. Every time I work on a Catholic or Reformed family in Hungary, or any family in Slovakia, I encounter as-yet-unmerged profile sets, all dated 2012. Every. Single. Time.
"If merges were monitored".... By whom? and for what? Not having identical data? By how much? What distance between baptismal place and birthplace is OK? How many years off is a guessed birth year allowed to be? Or do we learn a new merge methodology, whereby we change all the data on one profile before we initiate a merge into the other? That'll make it So Much More Fun to undo a bad merge!
Yes, bad merges happen, and yes, they're difficult to recover from, but I don't know what army of researchers you expect FamilySearch to hire to monitor for them, or by what criteria you expect them to judge a merge. And no, this task cannot be added to the workload of whoever is currently hired to maintain the data in Family Tree, because that would be nobody. That's not how it works. Yes, there is staff to deal with the not-public parts of the Tree (dead-to-living requests, read-only and confidential profiles), but my impression is that even those people are semi-volunteer, and perpetually swamped. The rest of the data maintenance in FamilyTree is crowdsourced: it's done by people just like you and me.
Once you discover a bad merge, and manage to disentangle it, there are steps you can take to prevent a recurrence. First, fix both "ends": make sure both of the profiles involved and their entire families have been fully separated and documented. Make copious use of reason boxes, the Collaborate tab, and dare I say it, the Life Sketch to make it clear that the two similar people are not the same. Then Watch/Follow one or both profiles so that you'll be alerted if anyone makes a change to them. In other words, hire yourself to monitor that part of the tree.
3 -
I spend more time doing merges than trying to undo them. A typical situation is I find someone who has created a child, parent, grandparent group that duplicates an existing well-developed tree. The small group has, however, gobbled up records/sources. I need to merge the small cluster with the large tree in order to relocate the records and prevent further errors.
I have seen some crazy messes that I have cleaned up (if they are a link in my family line). Some, I just let stand until more information is available. The best example is a woman who gave birth some years after she died. I do not feel that the biggest messes that I have encountered are the result of merges. I believe that the messes are created by unschooled, inexperienced "researchers."
For those who repeatedly find incorrect merges, perhaps a quick "undo merge" button should remain available for 30 days after the merge was made. This would give the experienced, level headed researcher an easy way to correct the family tree.
0 -
For those who repeatedly find incorrect merges, perhaps a quick "undo merge" button should remain available for 30 days after the merge was made. This would give the experienced, level headed researcher an easy way to correct the family tree.
The problem with this, and why the Restore function exists, is that as soon as an edit is done to the survivor of the merge, there is no way for the program to know if that edit belongs to the survivor of the merge or the person deleted in the merge. Restore is that quick undo merge button for the person who was deleted and works great. The hard part is the necessary evaluation of the product of the merge, the survivor, and fixing data and relationships that should not have been placed there by the merge or should not have been placed there after the merge.
One topic that might be discussed here is whether the warning signs on merges should be hard stops to a merge and whether there should be more of them. Should one be told, "These two people cannot be merged because they were born three years apart."? "These people cannot be merged, their parents are different."?
Personally I don't think so, because I find that the worst merges done by careless people have nice flags such as the children born before a parents birth or two completely different sets of parents. It seems that most people who don't know how to merge also don't know how to clean up after a merge. If they had to remove parents, "fix" birth dates, remove children, and such before a merge could be done, incorrect merges would be much harder to recognize.
2 -
There is a practical/logical reason that "unmerge" becomes unavailable if the combined profile is edited: the system doesn't know which of the originating profiles the edit applies to. This is true whether the edit happened half a minute after the merge, or six years after the merge, so it's simply not possible to keep "unmerge" available for some arbitrary time. It's available if there haven't been any edits. If there have been edits (including further merges, or merges of family members), then the system effectively assigns all of those edits to the survivor, but allows you to restore the merge-archived profile to the state it was in before the merge. So in effect, it is still an "unmerge", but because all of the subsequent activity has to go somewhere, they don't call it that.
1 -
Might I suggest we reframe this problem as an opportunity to develop skill in detangling? With skill comes pleasurable anticipation and joy rather than frustration and defeat.
Once a part of the tree is detangled it usually stays that way, which is very gratifying.
@SandyKJ if you would like specific advice on how to detangle the part of the tree you are looking at now, please start a new discussion in the Family Tree section and post a PID or two.
4 -
As much as I grumble when I have to repair a silly merge, I use it as an opportunity to improve the profile. I add more sources; I include a Proof Statement, with step-by-step and connect-the-dots. I think I've become a more diligent researcher as a result of having to prove/refute the details of the many branches.
2 -
None of Gordon's hypothetical "hard stops" would work in practice. "The parents are different": of course they are, I haven't gotten around to merging them yet. "They were born three years apart": no, they weren't, but one of them was based on a misreading of a 4 as a 7. (I had exactly that just the other day.)
For every possible discrepancy that on the face of it looks like an obvious sign that the profiles are for different people, I can probably come up with an example where they were the same despite the difference. Conversely, for every possible data match that on the face of it looks like obvious proof that the profiles are for the same person, I can probably come up with an example where they were different people despite the similarity. There's really just no substitute for people like us considering each case individually, and learning how to navigate the (often scary-sounding) Change Log entries that can help restore conflated profiles to their proper, separate state.
If I had a better grasp of how exactly a merge is shown in the affected Change Logs, I could perhaps make suggestions on how to make those entries easier to recognize and easier to interpret, but my few forays into detanglement have not been sufficient for me to learn these details. Merging a set of index-based duplicates into a single family is a satisfying end result but a highly tedious process, so I must confess that I seldom (if ever) look at what's going on in the respective Change Logs.
0
