Help get this topic noticed by sharing it on Twitter, Facebook, or email.

Alternate Merging strategy

Merging seems to be a problem. In my family tree there are quite a few generations of David Eppersons. Some of them have been merged out of existence because David Epperson has many descendants and many people want to contribute, feel helpful, or don't read the dates and names carefully enough.

My suggestion is to make the merge use a similar process as http://stackoverflow.com/. If a user asks a question is a duplicate (has been asked on the site previously), 5 different people have to vote to close the question before it's closed (or one user who has a good record in that subject). After it's closed it can be voted to be reopened and reviewed by 3 people before being reopened. That way the community is in charge but there is more agreement than just one vote to merge records that may not need to be merged.

So on familysearch I feel like multiple users (3+) should agree to merge a record before the actual merge takes place. That way if one or two users miss-read something a generation isn't merged out of existence. Also have a way for other users to vote to undo a merge if they felt like it wasn't a duplicate. Maybe have a place for comments on why it isn't a duplicate/merge.
4 people like
this idea
+1
Reply
  • I like the spirit of this suggestion. Experience on my line has shown me that I have one relative in addition to myself working on my paternal line, and so I am sure that there are other lines out there that are not as heavily trafficked that would not be able to garner the attention needed for quick resolution (without me going out and creating three 'collaboration' accounts).

    David, your suggestion was kind of implemented in reverse when FamilySearch restricted individuals from deleting persons who had multiple contributors, but this restriction has also likely contributed to the merge-mania you have observed.

    I also like the SO model, so it would be interesting if we could incorporate some of it, here.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • 2
    I seriously wonder how many lines across the world can gather 3 people to agree a merge. There seems to be a fascination that many US based users have, that you don't need to go far before finding someone else working on your line. Nonsense. On my entire spread of ancestry, based on Cheshire, England, I find just one other line is being worked on - and I have to go back to a 5th great grandparent to locate a common ancestor.

    Now, I'm not a prolific contributor to FSFT - it's not my primary documentation, but if others come along and find that they can't merge obvious duplicates, then they will get very discouraged very quickly. And the problem is that FS generated massive duplication when it decided to load people from the indexes of historic parish records. For some (but not all) of my Cheshire relatives, they exist as separate records in FS FT derived from their own baptism, their own wedding, their own burial and each of their children. So if they have 5 children, then they are in FSFT 8 times. If there's no-one else working on the line and I can't clear up 8 duplicates that FSFT created because FSFT now implement a consultation rule, then goodbye guys.

    Where multiple people are working on a line, then trying to secure consultation is a seriously good idea. But if not....

    Maybe there should be some sort of time limit on consultations. Anyone who's worked on or around the potential merges, or has them in their watch list, gets consulted. If they don't respond within 1 month, then they are deemed to have agreed and the merge can go ahead. (Thinking about it - that's how virtually any professional consultation process works). And if there isn't anyone within that scope of consultation, the merge can go ahead. I could live with that.

    Not sure how you describe the scope of consultation yet...
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • 2
    I like the idea too. I think in some cases FamilySearch employees and/or service missionaries need to get involved in the merge decisions. Think how the work load would be reduced on the service missionaries if they didn't have to spend their time helping untangle problems made by improper merging. Their time could be better spent evaluating proposed merges and duplicates.
    • NO WAY-- FamilySearch Support Missionaries cannot even answer a simple problem. I do not even think they know how to read and comprehend-- Instead they look for keywords and assume that is the answer.

      Case-in-Point:

      Just this morning I got a reply on my problem of "Not Available" ordinances. The problem occurred when the record was created [by FamilySearch Data Admin] as a "Male" when clearly "Elizabeth" was a female. Changing the Gender, "froze" the ordinances. Meanwhile, I was able to locate only one mention of the spouse's name. Here is the response:

      We have reviewed your concern that ordinances for Elizabeth Gordon LCQ2-KZS are shown as Not Available. The term "Not Available" appears if the system does not show a couple relationship for the couple. Elizabeth Gordon and Alfred Gions 1813 – Deceased • L5Z8-TZN do not show a marriage event. ​To add a couple relationship, on the details screen, scroll down to Family Members. In the couple box, click the pencil icon on the right. To create a couple relationship, in Marriage Events, click Add Event. The sealing to spouse should now show as Request or Request (Needs Permission) in the Ordinance tab. Also, there may be an 1850 US census that shows Elizabeth as a female. We suggest that you attach a census to her record to provide evidence of her gender.

      Why is FamilySearch creating records again?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • 1
    Maybe a refinement to the proposed idea could be that everyone watching the two records to be merged would need to approve the merge within a certain time period.

    Then Adrian would not have any trouble merging since he would be the only one watching his ancestors while the twenty people watching David's ancestors could all have a say. It would probably take support's involvement only if someone refused an obvious merge because he wanted to keep "his tree" separate.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • This is an interesting thread. We need some better approaches to Merge. We need to facilitate good merges and discourage bad merges. The problem is distinguishing good vs bad and putting in the the proper impedance.

    Regarding a pending/vote model like this is very convoluted. There are the technology issues and user experience issues.

    Assume we have a model where User 1 can make a set of changes for a Merge. But those aren't committed. They are a set of Pending changes. A certain set of Users is required to "Agree" with the pending changes. Once a threshold of agreement is met then it is committed.

    Technology: Now instead of writing the changes we need another store of pending changes that has to be managed. Assuming that works what happens through time. Say User 1 creates a pending changes, but during the timeframe, one or both Persons and their relationships change before agreement. Do you toss the pending change and start all over? What if no Person changes but User 1 changes their mind, or User 2 creates a Pending change for the same pair, but the changes are different...

    Voting model is predicated on the candidate pending changes, for a certain length of time, involving a number of users, or specific set of users (Watchers). Users come and go in activity. There is the possibility of creating a large set of "read-only" Persons that are locked via the model.

    User experience issues are making this system understandable and predictable to the users. I can Merge this pair with 3 watchers, but not this one with 4 watchers. I can't Merge the pair because there is a pending change... Fine I'll game the system. I'll just create a new Person and avoid all Merges...

    From my current perspective, my gut tells me this is too complicated. But I do believe there is a more simple, straightforward system. We just haven't discovered it yet. It's kind of like sculpture: inside that block of stone is an elegant piece of art. Thanks for helping out and keep the thoughts coming.
    • I would certainly think that storing pending changes for automatic agreement once the threshold was reached, is way too complex. Not to mention that tweaks elsewhere might have destroyed the logic for the merge. I was envisaging a simple lock on both persons so that they get visually marked as "Proposed Merge between X and Y" - Proposed not Pending. The lock would prohibit such a merge.

      Once agreement is reached - or deemed to be reached by expiry - then the notification goes back to the proposer so that they can manually do the merge, double checking to see if all the other stuff is still OK. And only at that point, is the decision about what items to use made.

      That would simplify things.

      As for gaming the system by creating a new person - well, isn't that what gets done when we need to un-merge two people who simply can't be split any other way? In other words, it's quite difficult to condemn the idea!
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • Perhaps FSFT could learn from WikiTree. They have one or more "Profile Mangers" for every record. Approval from one of the managers is required before merges are completed. If merging is not denied within a month, then automatic approval is granted. Managers can set the level of editing possible for the profiles they manage (from complete open-edit to complete lock-down). They can accept other patrons as Co-managers. There's no limit to the number of Co-managers for any profile. Profiles become "orphaned" with no managers if none of the managers log onto the system within a certain period of time. Orphaned profiles can be "adopted" by anyone willing to take on the role and responsibilities of manager.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • M Geesey, et.al.
    I'm curious how this could work. Using your terms - "manager".
    Assuming the manager is very familiar with the line how much time would she take to do a Merge, assuming it's simple, vs. complex (lots of spouse, kids, tangles)?
    Could a manager work on profiles (FT Persons) they are not familiar with?
    How familiar must they be?
    How much time would they take to become familiar?

    Based on those number how many should a manager be able to work on in a given week?
    Would they need to be commit to these profiles? Or could there be multiple mamangers?

    There are over 1.2 billion Persons in FT.

    How many managers would there need to be to keep the time in the queue small? I think if I had to wait a month, that's too long.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • I'm not sure about the particular technologies that would be involved, and we do have to make sure that the solution is not worse than the problem, but on multiple occasions someone has merged an ancestor into oblivion. Because I have marked all of my ancestors and their children "watched" I usually catch this kind of thing fairly quickly, although it does take a lot of time each week when I get the weekly digest to make sure someone hasn't made a mess of things.

    But back to the original issue. Once someone is incorrectly merged, if you catch it quickly enough, before other people have piled on additional changes, it is relatively simple to unmerge. And when I do this, I carefully document why I am unmerging and mark them "Not a match." But then another person (sometimes the same one that did the original merge) comes along, pays no attention to what is written even though they check the "I've checked the notes" check box, and re-merge them. These are the kind of cases that need some sort of moderation.

    Maybe rather than coming up with a blanket policy that doesn't fit well for lightly researched lines, a researcher could "Request moderation" on a heavily contested line. Then only in these cases would a merge/split be deferred pending moderation. Maybe the moderator is a FSFT volunteer; maybe it is someone who is interested in the line; that will take more thought. But the idea would be that after moderation or arbitration is requested on an individual, all subsequent changes must be approved by the moderator. Hopefully the moderator is evaluating documentation for each proposed change, and rejecting changes without substantiation.

    I understand this raises a bunch of questions about how long an individual should remain in moderation after it is requested, and such things. No specific recommendations; I'm just trying to help the thought process along in the spirit of the original post.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • I’m unsure
    How about the person who created the persons entry into Family Tree is responsible for approving pending merges for 30 days. If they don't approve/disapprove within that time period the system would automatically merge the records.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • 3
    Could the merge routine be improved by incorporating data error checks? Currently you get an error message and cannot do the merge if you try to merge a male and a female. How about the routine checking for and blocking the merge in following cases? The criteria here are just first thoughts, clearly they would have to be carefully thought out and refined:

    "These two people cannot be merged because:

    The people being merged were born more than 20 years apart.

    The people being merged died more than 20 years apart

    The people being merged were lived more than 100 miles apart at time of birth or death.

    The resulting individual would have children born before usual childbearing years or before birth.

    The resulting individual would have children born after usual childbearing years or after death.

    The resulting individual would have children born within one year of each other

    The resulting individual would have children born over a span of more than 60 years.

    The resulting individual would have a spouse who was born more than 80 years before or after"

    Analyzing what went wrong in many different merges would like show other blocks that could be put in place.
    • view 3 more comments
    • A location check can only be done on matching events - e.g. compare locations for the birth for each potential merge person. We might feel instinctively that someone with a child born in Bavaria, and one born in London could not have another in the middle born in New York. But the census shows that it was true.
    • The only potential problem I see is the "after usual childbearing years" warning. I've had this kind of thing crop up within certain situations where the birth was valid for the mother, but it is rare. The "after death" is a valid and obvious point, but could also exist within families of certain religions where the life of the (unborn) child is preserved after the mother dies -- again it is very rare.

      My thought is to implement something like this, but with the ability to override with sources having to be given to justify the override (i.e. birth certificates, etc.).
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • 1
    Gordon, I really really like your "Feedback" above. I think your above thinking about putting in roadblocks for wrongful merges, is the closest thing we will ever get to having the opposite of an open editing Wikipedia style genealogical "Family Tree." Sounds as though it might be the best of both worlds, in that all can input data, (Family History), into the "Family Tree," but are restricted, (closed), to making illogical or unwanted changes to the open editing system. Now lets hope that the engineers will implement your above roadblocks, and add to them, and make the system closed to unwanted changes in the "Family Tree."
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • 2
    I also am in agreement with the kind of restrictions Gordon suggested being added. However, in addition, (I have mentioned this before in other threads) the current merge function needs to be modified so that all parents and children are retained during the merge. The current option of requiring the "user" to move parents and children from the right to the left during the merge frequently causes the relationships to be removed from the system and it is quite difficult to recover this relationships for the average user. Sometimes the user just forgets to move some of the records and sometimes they do not understand that the relationship will disappear of the records are not moved from right to left.

    I believe the move should be done with the merge and then if something is incorrect say an incorrect child, the parent child relationship can then be removed. All sources are moved, why not all relationships also. It will leave a better "trail' regarding the change being made and the user can enter a specific reason not just the generic reason for the merge.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • There is consideration to retain all the relationships that don't collide by default.

    As for the set of roadblock logic, this assumes the data on the respective persons are correct prior to the merge, but that may not be the case. The birth place was wrong, by 111 miles. So now I can't Merge. Perhaps you will suggest the user has to go fix the data errors in each Person so they aren't roadblocked, then go perform the Merge.

    Also, the user would have to go do fixups for all relatives that would be impacted by the roadblocks prior to the Merge. Is that the suggestion?
    • view 2 more comments
    • As for Joe's comment,
      "Perhaps you will suggest the user has to go fix the data errors in each Person so they aren't roadblocked, then go perform the Merge.

      Also, the user would have to go do fixups for all relatives that would be impacted by the roadblocks prior to the Merge. Is that the suggestion?


      That would be both my hope and my fear. I would hope that someone would have to look so thoroughly at the data to remove a roadblock that he would realize that the two people couldn't possible be the same and not merge them after all.

      My fear would be that someone would be so insistent on merging that he would remove all the "incorrect" data preventing the merge no matter how much there was, completely fouling up a record, to get the merge done.

      I have to say that in the few recent instances where I have run into completely inappropriate merges, they have been cases of just "merge and run." The person doing the merge just merged and didn't do anything else to the record. I've discovered its pretty easy now to just restore the deleted person then run through the change log and removed everything added by the merge from the surviving record. Having a bunch of editing done to the record before the merge would make undoing the merge much more difficult.
    • I fully agree with Gordon. There are far too many people who just do not take the time to fully check and validate two records before they merge them. In other instances, the records involved may contain obvious errors that should be corrected and which would allow the merge.

      Erroneous merges will continue to be a problem especially when the Church encourages inexperienced / unaware persons to perform family history research and take their own relatives' names to the temple. Even classes do not resolve the problem. And when an inexperienced (novice) computer user is involved, the problem becomes worse.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • This is a comment not a suggestion-I have found that at least 50% of the individuals listed as "not a match" are indeed a match. In the days before IOUS merging, many-many users marked these inappropriately as "not a match" so the hint would "disappear".

    I end up ignoring the "not a match" warnings and make my own merge decisions based upon the data available. It is a good system, it was just temporarily highjacked.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • 1
    I would like to see a system where the user is rated on their merge capabilities, and they can only merge based on that rating. The user would fill out a profile noting what sources they used for merging, and that would determine what they could do.

    For instance, someone who uses actual probate and parish records, could merge whatever they wanted. Someone who only uses gedcoms, or Ancestry would only be able to merge four or five star matches.

    Maybe some people would not give an accurate assessment of the sources they use, but hopefully most people would.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • Not exactly related to the original topic but Merging does need to have some best practice training.

    There are 2 major areas in merging that need to be addressed.

    1) Change Logs
    2) Relationship reasons.

    1) The change log of the surviving person can often be the thinner of the two records and due to the residual effects of incorrectly combined records in nFS it can result in informational clues concerning hidden persons being lost. Once merged one must traverse the deleted records change logs to represent a true history of the surviving record. Some effort must be given to bring this information into a more easily seen format. My best practice has been to add Tombstone sources
    https://docs.google.com/presentation/...
    in order to give visibility to the merge and change history of a person. If a change log source for the deleted person were added to the surviving person during the merge this would give increased visibility to often relevant information.

    2) When relationships are broken due to a merge the only reason that is given is the reason for the merge (relationships are not alone in this but are the most significant information that can be lost in a bad merge) It has been my best practice to move all relationships to the surviving person and resolve them individually allowing for reason statements to be given appropriately.
    When relationships are left behind a prompt for a reason statement should be given.
    • view 9 more comments
    • As soon as I quit looking for an example of how I merge relationships when missing spouses seem to interfere with that process and got back to work in Family Tree, I came to an example. I am posting what I do as a new topic.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • I would like to suggest that only people who have to passed a test be allowed to merge. They could be given examples like to one below to see if they can spot the differences between people whose records have little information but e.g. whose spouses and children are different in some way. It would be easy to create an online quiz for this purpose.

    I just came across the worst series of merges I have so far seen. The person had no concept of the fact that in some cultures names are repeated over generations with fathers. grandfather, uncles, nephews, sons and cousins all likely to have a common name. Not only that but they failed to understand that in the particular culture, in this case Scottish, many married 1st cousins. (So a Mrs McDonald nee McDonald is not the same as Mrs McDonald nee McFee.)

    This person, who spent at least 2 days doing all this work merging, did not stop to review the results. They did not at look at the now merged result and see the that man now had at least 4 different wives and at least four different marriages sources for these different wives.

    There is another problem, and that is that the change log also changes. It only shows the details of the current relationships. So for example if a spouse has been merged when you click on the spouse in the change log to see their record it shows only the current information even in the early entries in the change log. The change log does not show the details for the spouse at an earlier date.

    Cheers
    • Users do not want to take tests-- those are for the teachers to see if the lessons are being learned!

      BTW, names should not even be entered as "Mrs McDonald nee McFee" they need to be in standard format with out the married name. Should be only "McFee" in the surname field. But I did not mean to provide a critic of your example.

      We must assume that the merge routines within the html code are written correctly and tested properly before being updated onto the 'live site'. And don't get me started about the 'log', that has always been so convoluted and complex even a 3D thinker cannot "sus-it-out".
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • Yes, Merging is a complex process and must be taught. All of the problems with bad merges happen because people were not given the keys/tools to know how to merge.

    I have done hundreds, if not thousands, of merges and have only had a handful that I had to unmerge (what happened to that feature). I teach very few others how to merge because they do not have the analytical mind or just do not want to learn to merge.

    FamilySearch has done a poor job of 'teaching' the novice user how to do anything. Even simple data entry. I'm having to 'standardized' everything sometimes from a user that thinks they know how to do it. There are many helps available but they are too hard to get to, if known about.

    The website uses 'cookies' and they need to be used to track a users experience level. Only Experienced, Advanced, Expert and Professional level users should be allowed to Merge. A beginner should never have such access to tools that will seriously "mess-things-up".

    I use the website all day, every day-- as a Professional Family History Consultant. I have often had to 'fix' the work of my clients because they thought they could do it. However, I can teach them how to do merging properly, I cannot make them learn to sometimes think 3-dimensionally and visualize the outcome.

    I'd be happy to discuss the process I use.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • 1
    The idea of rating people's abilities and allowing them access to tools only as they demonstrate the requisite ability, is one that appears every so often. (Yes, you did hear a sigh from me - though not necessarily for the reason that you think).

    If it's a case of me sitting a test, then forget it. This is my hobby and I have zero commitment to the LDS Church - I'm here simply because it offended my sense of propriety to see my 4G GF Bate married to his own mother (or whatever it was). So I fixed it. And fixed some more... And... But put obstacles in my way and I'll be back to my tree on Ancestry.

    Also, quite apart from anything else, I've seen too many non-genealogical tests that show that the tester really doesn't understand the first thing about their own topic beyond waving a few slogans about, to have confidence that anyone can create genealogical skill tests.

    But what might, just might be possible (and acceptable to people like myself) is for the FS FT system to record what people do and release the next level of capabilities, only when they have done X number of tasks at one level. For instance, you can't access merging until you've used Source-Linker at least X times on Y different people. There'd need to be a display somewhere that told you where you were on the scale of Newbie to Jedi and it would need to be made clear to people that their access to tools depended on their experience.

    This idea may have come up already - I don't remember, so I apologise if I'm purloining your idea without attribution. Part of this inspiration comes from Stack Exchange where badges and access are given out depending on how often you answer queries, etc, but also on the quality ratings that people manually give to your answers and comments. As there is no quality rating system on FS FT (though potentially there is on GetSatisfaction) that part of the idea seems a non-starter - unless anyone can think up a quality rating system...
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • 2
    I confess to not having waded my way through all of the comments on this thread, so apologies if someone already said this.

    The reason bad merges happen is that the tools are inadequate. The "Potential Duplicates" screen presents you with names and PIDs, and nothing else. No dates, no children, no locations. If I'm looking for potential duplicates, then of course the names are the same. Is it any wonder that people merge profiles based on name alone, when they have to start the process based on name alone?

    Instead of putting all the blame on clueless users (although doubtless some of them are that), we should be putting some thought into how to make the tools work better. Detangling relationships and sorting through data are by their nature complicated tasks, but the software should _help_ with them, not hinder as it does now.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • 1
    Juli states above that "the tools are inadequate". I have said several times in the past that if you need training in a system, then the user interface is inadequate. You shouldn't need training in a system - how many decades have we had wizards and rich interfaces? (This is not the full story - you do need training in the process that the system is intended to support - you can't do genealogy very well in FS FT until you understand, for instance, that it's an open access, anyone-can-edit, massive tree. Or you can, but as we know - grief ensues...)

    With that in mind (and possibly hiding this idea by adding it onto an old thread), here's my personal take on the overall merging process.

    Essentially it consists simply of 2 steps:
    1. Are these 2 PIDs the same human being?
    2. If they are, look at each "fact", decide which PID has the best value, and do the merge.

    Two steps that should not be mixed up. But what happens?

    Taking some quick screen shots of a sample (presumably incorrect) merge:

    Here's the start - a list of possible dupes:

    I don't have a problem with this - this is just the entry point and we need to choose one possibility to review.

    Here's the next step.

    And this is where it all starts to go wrong. This screen is a call to decide which PID has the best value for each "fact" - it's a call to set up the merge. Hang on - what happened to my step 1 - "Are these 2 PIDs the same human being?" I think this is what Juli is concerned about.

    At this point we should be lining up the values for each person, looking at their families, and generally saying things like, "Hang on, nothing matches!" Or, "Yes, same spouse, same residence, next child born two years after the last... OK" And if we look at the suggestions above, this is the point at which the system should also be saying things like "Hang on - the PID on the left has only events in the USA, the PID on the right has only events in the UK. Are you sure they're the same person?" So this stage needs a total revamp. The result might not be radically different in appearance though (a) family would need to be made clearer and lined up and (b) the "facts" would be, at this stage, read only, for review only.

    This is the lowest part of the screen shot above - it is exactly what should appear at the end of this step 1 "Are these 2 PIDs the same human being?"


    And this asks for the explanation why the merge is correct - despite the fact that the system has never asked you properly to think about it.

    It's the right screen to appear at the end of Step 1 "Are these 2 PIDs the same human being?".

    Only after we've explicitly decided that these 2 PIDs are the same person should we go into step 2 "Look at each "fact", decide which PID has the best value, and do the merge." Or this screen...

    In that context, this screen is basically fine.
    • Adrian, I agree with your two steps. I commented somewhere (haven't gone looking for it) where I called them "matching" and "merging", and it's especially in the first of these that FS FT's merge setup is extremely lacking. It goes straight from a list of profiles with the same names (and nothing else to tell them apart by) to the "which should we keep" screen, which is totally backwards and useless.

      However, even if things were presented in the right order, with matching first and then merging, the current merge screen is inadequate: it doesn't identify who put in each conclusion and when, and there's no access to reason statements or notes and discussions. The conclusions are also treated in too-large chunks: you can't keep the date from one profile and the place from the other, for example. Yes, there are workarounds for these failings of the merge system (starting with having both profiles open in other tabs), but the point is that with a well-designed tool, we wouldn't need workarounds.
    • "it doesn't identify who put in each conclusion and when, and there's no access to reason statements or notes and discussions." Good points.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • 1
    Adrian, I think you have hit on the right key for facilitating better merges.
    "Essentially it consists simply of 2 steps:
    1. Are these 2 PIDs the same human being?
    2. If they are, look at each "fact", decide which PID has the best value, and do the merge."


    The link "Review Merge" from possible duplicates (or any merge) should go to a side by side comparison of the two PID's, rather than the 'merge' screen. This would faciltate an in depth comparison and analysis of the two individuals, including vitals, sources, notes, discussions, change records, hints, et al.



    These pages are, of course, currently available from the 'review merge screen in the upper left hand corner where it links to both individual PIDS - but takes a few more clicks.


    Then AFTER the side by side review and a determination that "these 2 PIDs the same human being;" the process would go to the MERGE (review) screen to transfer data and merge the two PID's.

    There is also circumstantial 'evidence' than many novices might believe that if FamilySearch indicates "Attach," "Merge," "Add," et al, it might construed as a recommendation, or command, to take the action because it's 'approved'. Witness the many emailed record 'hints' are rapidly added when received
    • "a side by side comparison of the two PID's, rather than the 'merge' screen. This would faciltate an in depth comparison and analysis of the two individuals, including vitals, sources, notes, discussions, change records, hints, et al. "

      Good idea - though, as it stands, that needs a lot of glass to get to a legible size of text. But I hope that someone might have a bright idea to get round that.
    • Which is the reason I switch from my cellphone to my laptop, to even make the image.
      I find it rather difficult to do much actual research on small screens.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly

  • I’m anxious but hopeful
    I am not sure if I am posting to the correct location - on/off topic - but my idea seems to relate to this older post so I am going to post here.

    I too agree that Merge has become a more complicating issue to the collaborative tree - I hope my comment can be taken in the hopeful/helpful way I hope I intend to give it.

    I like the collaborative tree idea but I believe the ability for any one person to merge can drastically affect the effectiveness and accuracy of the tree. I propose that if there is a merge wanting to take place that the person wanting the merge - the person who 'created' the current person state/view and perhaps a 'family relation' be required to be involved in the merge process.

    In other words - more than one person would be required to work through the process - in hopes that all the relationships/sources etc. will be preserved and correct as possible so that when the merge completes it provides a more accurate view than the state/view that existed previously. If this process requires correspondence entries concerning the relations/sources involved I propose that correspondence be included to document the decisions made in completing the merge process.

    How is this different than the current merge process? To my understanding the biggest difference would be that the merge process would be slowed down to involve at least three people rather than one.

    In addition, I would like to propose that IF there are 'family organizations' (usually for famous/well-known people) there be a way to channel public collaborative tree sourcing/merge requests for relations to that family through such a regulated source/merge process - in hopes that the state/view of that family/person will be changed positively/organized rather than chaotic/messy.

    Further, I would propose that living people be allowed to create such a 'family organization' such that their Watch lists are pooled so that they can help keep track of public collaboration contributions - and that if a public collaborative merge is requested that someone from the 'family organization' be required to be involved/consent to the final changes the merge will affect.

    Anyway, I don't know if this sort of idea is feasible or compatible with the current FamilySearch FamilyTree roadmap BUT I do know that public collaborative merging is becoming a more complex process and I think that a process of involving a 'family organization' would be a way to approach that in hopefully a more 'organized' manner.

    Thank you for the wonderful work FamilySearch has done - I hope it continues improving!
    • What about the many thousands (if not millions) of automatically-created duplicate profiles based on indexed records? Who would be the other people involved in cleaning those up?

      WikiTree has a sort-of two-person merge process, in that merges have to be proposed and then approved, but I've never done one there so I don't know the details. But WT doesn't have quite the legacy data mess that FS does.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly