Merge column suggestion
Comments
-
I would like to see 3 columns on the merging page. The 2 that already exist and then add a third column. It would look something like this and populate some things automatically.
Current Layout:
Proposed 3 columns:
Have it auto fill in both names, and birthdates and any other data that is on both persons. This way the people looking at the merge later, can have confidence in the decision that was made.
There could be drop down options for each section with things like, Identical names, Identical dates, One year off, born in same state, Husbands have identical ID numbers, There are no conflicts.
Then have the notes column, automatically populate the final page.
Like this...
Then if a merge is done, it can more clearly be UNdone if it was wrong. This way the people looking at the merge later, can have confidence in the decision that was made.
0 -
@Miriam Peterson, I'm afraid that your idea would make an already-tedious process into a dreaded chore, without improving the outcome at all: people would just click through to the end, same as they do now.
99% of the merges I do are legacy data. In a prior system, index entries were made into profiles, but with no provision for unifying people who appeared in multiple index entries. Thus, if a set of parents was indexed in ten different baptisms, they could each end up with ten different profiles. In 2012, when the current Family Tree started, these little family tryptichs were imported into it, and many of them have been floating around ever since. When I clean up such a family, I end up writing reasons for merge like "PID2 was a legacy-data duplicate of PID1 based on the indexed baptism of his daughter NN in YY." The determination that this is true -- that PID2 really is the same guy as PID1 -- comes long before the merge process; it generally involves a full list of all of the index entries that the legacy data comes from, along with partial transcriptions of the corresponding images, for the unindexed details like house numbers and godparents that help to confirm that it's really a single family. (I take those notes in a text editor, but I know others who use spreadsheets.)
In such legacy tryptichs, almost all of the actually-useful data is associated with the child -- which is the one profile that doesn't end up getting merged. A process that automatically pulled data from the two profiles being merged would therefore be basically useless. It'd be pointless added tedium to click through it all.
3 -
Most merges I see are from duplicates created with gedcom imports. Errors are frequently carried over in the merge. Whatever the purpose of adding new profiles to the shared tree using a gedcom import, this is the # cause I see for constant churning in the shared tree.
The worst merges to correct happen when someone changes a name before the merge. Name changes appear retroactive in the change log.
With respect to edit wars, there are people who seem to not care about sources or explanations and there is not much to be done about that.
Bad merges are very common, especially for people who are to early to appear in the 1850 census and it is usually helpful to use the merge filter in the change log to understand the profile. I have a tab open now for Jane Mitchell who was originally created as the wife of John Greer. She now has two different husbands with children born at the same. What happened to John Greer?
1 -
Family Tree is like a Wikipedia. Whenever an editor makes a change, they are asked to (and will want to) defend/explain their changes up front at the time of the change. FamilySearch tried to provide some brief merge reason examples, but they are too brief. Many people are using them, but without any additional explanation.
Here is my sample template I use when explaining a merge:
The suggested duplicate record (<paste in the duplicate’s full name with birth – death dates and PID#>) had the same <describe what vitals, dates, places, and relationships including PIDs of relations were very similar or identical>. But it had no <describe what it was lacking in relation to what the surviving record has, for example sources, parents, spouse, # of children>. It was created by <paste in the userID of the user> on <date>. Whereas the surviving record (<paste in the duplicate’s full name with birth – death dates and PID#>) has <describe how much better the surviving record is in comparison, like # of sources and # of vitals and relationships>. This merge will clean up <identify another family member>'s details page by not showing duplicate <relationship>s. I will <describe what you will allow to be preserved in the merge, and/or what your next plan is to complete merging of other duplicate relationships>.
The bigger problem is when users simply type in "same person".
0 -
@Jon W. Thomas, one problem with a long-and-painfully-detailed reason for merge is that it gets repeated in the change logs of every affected family member, multiple times.
(Another problem is that the data for writing it is not available on the screen where you enter it.)
Sometimes, I copy-and-paste my pre-merge notes into a Note on one of the parents, but I don't try to include those details in the merge reason. I certainly don't try to justify my choice of which profile ended up "on top" -- in the merges that I do, unifying index-based floaters, that choice is essentially random: the profiles are all equally devoid of everything but the name, and said name is often exactly the same as the others.
1
