Canned Reason Statements. Helpful or Harmful?

LegacyUser

Chas Howell said: While doing a merge I see you are now given Canned Reason Statements you can choose by clicking Add. Kind of works against coming up with a thoughtful & informative statement of your own. Akin to floating a stop sign without coming to a full stop.

LegacyUser

Robert Wren said: They are at least helpful by including the PID's in the reason statement - other than that . . .

Hopefully users will at least READ them before using and then ADD 'a thoughtful & informative statement'

LegacyUser

Christina Sachs Wagner said: I love them! I use them to build my own and definitely use the PIDs that are included. It will be extremely helpful if restoring needs to take place. I am known for my typos and having the PIDs already there in a reason statement makes them super easy to copy and paste correctly, or just click the closest reason statement and modify the text to meet my needs.

LegacyUser

Don M Thomas said: Kind of dumb! Why even have a required reason statement if you are going to have added canned reason statements? Dumb! Dumb! Dumb! Go back to where a reason statement was not required. Have lost my interest in all of this. Who knows, I might add a reason statement if I was not required. I don't enjoy working in the Family Tree anymore. Try to follow the party lines, but just can't get past the open edit-ness of the Family Tree.

LegacyUser

Jeff Wiseman said: Selecting "There is enough evidence to believe..." as reason for the merge is now a great way to be lazy and not actually state what that evidence truly is!

Now I just click "Add" and I don't need to worry about putting in any USEFUL information. Now we will have loads of "Reason for Merge" texts (which are mainly self evident) taking up lots of space and actually useful information points will be encouraged to be left out.

And there is no advantage to the PIDs in it because when someone comes back later to look at the reason for change text in a change history, both of this PIDs will already be present in the view making their inclusion in the text completely redundant.

Sorry, but this really appears to just be more clutter that no-one will ever look at after the fact. And if multiple changes occur, what do you do with the situation where the PIDs no longer match the ones shown in the change history? (we already have that situation in the merge histories)

I agree very much with Chas. Why are we encouraging people to think about their reasons for doing things even less than they do now? Better to leave the space blank and let someone else analysis it.

LegacyUser

Gordon Collett said: They are certainly better than:

.

or

dup

What will be helpful with the ID numbers is that these statements will show up on a child or parent whose relationship changed due to the merge, making it very clear that the relationship changed because of a merge.

LegacyUser

Juli said: The PIDs from the canned statements should be very helpful for building a more personalized statement, but I kinda wish there was one that referenced extraction projects (the source of 99.99% of the merges I do).

LegacyUser

Christopher Padgett said: They are more helpful than the when I find reason statements such as: "Found it on Ancestry" or "Find-A-Grave" or "Gedcom file."

LegacyUser

Jeff Wiseman said: I guess you're all right.

So what about adding a canned reason that states: The record GSBH-NW2 is an intentional duplicate of LC31-CKQ that was imported via a GEDCOM file.

I know that rotkapchen would use that one A LOT
https://getsatisfaction.com/familysea...

LegacyUser

Kathryn Grant said: Yes, rotkapchen would probably use that statement thousands of times.

LegacyUser

Jeff Wiseman said: The entire merge mechanism has been totally revamped in order to get the user to slow down and THINK about what they are doing. And now, just as they are in a position to DOCUMENT that thinking that they have been doing, we short circuit their whole thought process by giving them canned answers that SOMEBODY ELSE has thought up--someone who had absolutely nothing to do with the decision making for that specific merge.

If we keep trying to hand everyone pseudo-answers like this, they'll never learn to do it themselves and there'll be no incentive to improve. The more people try to think about their OWN reasons for performing the merge, the greater the potential for their reason statements to be "Reasonable".

when someone changes a name on the Person page, it populates throughout the whole change log so that the changed name appears even before the date of the change

I believe that I have seen something similar with PIDs after merges, but I can't find an example at the moment.

LegacyUser

ATP said: Personally, I'm with rotkapchen!

LegacyUser

Paul said: I had just given "gold stars" to a couple of posts that were rather supportive of the new feature, then read Kathryn's comments! Now I feel a little on the fence over the issue.

On the one hand, IDs form part of the statements, which in themselves say something similar to what I would input in certain cases. However, it does make it very easy to think, "That's close enough", or even to just to quickly click on an option to get the job done.

Kathryn is very much correct in emphasising the seriousness of the current situation regarding incorrect merges - which I feel is proving far more damaging than having multiple duplicates in Family Tree. But, at present, I don't think any of us can really assess the degree to which inserting these statements will either prove these choices to be a good thing, or the opposite.

What is now swaying me towards her way of thinking is Kathryn's comment, " I can guarantee you that some will think these statements are evidence that FamilySearch approves the merge and that therefore it's correct." Exactly the position many of us find with the "Possible Duplicate" hints produced by the FamilySearch algorithm, in the first instance. No matter how crazy they turn out to be on closer examination, some users will always believe they must make the merge because "FamilySearch says so". So they go ahead regardless of providing a reason statement.

I guess I deliberately waited to comment on this one, in order to come to a balanced view but - until I see this being used in practice - still cannot make my mind up over how useful (or not!) it will prove to be.

My current reason statements frequently relate to the extraction program issue. The other common reason I give involves the two IDs relating to the same event. (e.g. one ID has one christening source for the individual attached to it and the other has another "identical" source attached - same date, place, parents details.) In the latter case, I write a reason statement for the merge along the lines of, "Same event involved - name of individual, parents and event place name match exactly."

Incidentally, one thing this has emphasised for me is the importance of adding an ID reference when I add a Note or Discussion item in the Collaboration section. Once a merge has taken place, and these have been carried over to the surviving ID, they often make no sense at all - especially where there has been an existing item on the same subject. For example, I write a Note headed "Identity of William Brown" against two separate records (IDs) for "different William Browns". If I forget to amend / delete these before later making a merge I end up with two identically headed notes on the one ID, neither of which now makes much sense. So (not my original idea) I would suggest always adding the ID you are adding comments to when raising Discussion / Notes items - especially if your note acknowledges there might be duplicates that need to be merged at a later date!

LegacyUser

Paul said: Kathryn

Apart from my more general comments (below), I feel I have to disagree with your specific comment that the option, "All vital information and relationships match" will rarely apply. Although you acknowledge an exception (applying to identical extracted records), I could frequently use this statement in other cases, too. Admittedly, there will usually be little detail on either of the IDs to be merged, but I frequently come across examples where (say) one user has attached certain sources to an individual (and possibly their parents and siblings) with one set of IDs and another user has created IDs for the family using other sources - particularly census ones. If both users have carried out further research, birth and other vitals data sometimes matches exactly, too. I am surprised you do not seem to have shared my experience in encountering this.

LegacyUser

Kathryn Grant said: Thanks, Paul! I appreciate your comments. I'd be interested to see some examples where ALL vital information and relationships match. Most, perhaps, but do all really match? (I'm asking sincerely, not snarkily--if that is a word ) If I come across any (besides duplicate extracted records), I'll post them. Perhaps you could do the same?

Thanks again!

LegacyUser

Paul said: Will try to do this, Kathryn. However, I did qualify my comments by saying, "Admittedly, there will usually be little detail on either of the IDs to be merged". So I am conceding that in many cases there will only be one or two vitals inputted on each of the IDs to be merged. So "ALL" does seem a bit of an exaggerated term - but, literally, quite accurate!

LegacyUser

Cindy Hecker said: I think as a teaching technique it can help new users learn what would improve their reason statements. So many lack the skill and there are not many great examples when they are review change logs. Maybe offering it as suggestions of ways to write the proper reason statement rather an the option to select them.

For example you merged these 2 people because....alter this suggested statement to best fit your reasons. Add pertinent details as needed.

But often even I go with a simple easy Same birth and death info and locations type statement, because long statements matter when there is more complication like separating same names but different people. I think everyone would like to keep things simple where possible.

LegacyUser

Christopher Padgett said: When the reason statement was first rolled out, I recall learning statements such as, "This is my father." or "I attended this funeral." or "This information is consistent with her birth and marriage record, etc." were given as examples of good reason statements. Periodically, I've added statements such as "This date can be found in the family bible that was maintained by his mother." or "This was my grandmother and this is how she spelled her last name."

Names tend to be the biggest point of controversy I've experienced recently. Often there are names that can be spelled different phonetically and that for some reason over generations get changed. For example, I have Whelan and Whalen in my tree. I have Zweydoff, Zweidorf, Zweydorff, and Zweydorf. Different branches spelled it different ways. I honor how that branch spelled it v/s inserting my will on to records. I put a lot of weight into how that person signed their name particularly if I have a letter or document they signed in my family archive. I'll digitize that document, add it to the memories section on FamilySearch and use it as a reference.

Often I'll get a notification of changes and see another contributor who frequently is listed as a 12th - 14th cousin has went in and changed all the spellings. I will then take a moment to breathe. Politely message that person, introduce myself as the grandson or nephew, etc of the persons that have been changed, and then inquire what information they have that caused them to make the changes. They will typically write back and say "found it on records" or "its on my GEDCOM file." I'll then politely write them back and share how different people spelled surnames different ways due to phonetics, due to enumerators spelling names on records based upon what they wanted, etc. I'll then politely inform them I intend to change the spelling back to how that person spelled their surname. The typical response I get back is, "Fine. Do whatever you want."

The FamilyTree is not a static record. It is dynamic: constantly evolving as more information is found, records are made available, secrets are uncovered by researchers, etc. Whoever came up with the ability to show how different contributors are related deserves a gold star as that one little feature has brought tremendous value to the user experience. I have been able to connect and share with cousins on branches of my tree that I didn't even know I had. Just recently I was able to learn about a cousin in a German branch of my tree from Germany and we've started corresponding off of FamilySearch. So whoever created that feature, thank you.

LegacyUser

Jeff Wiseman said: But remember that the reasons for setting vitals to given values is a whole different beast than documenting why 2 records are considered to be identifying the same person.

These canned answers are all based on limited reasons between 2 records. But more and more frequently people are loading duplicates of entire families into the tree. In this case, all of the relationships for one record and all the relationships to another do not "match" at all relative to the PIDs (i.e., none of the PIDs match). But when examining the contents of all the different PIDs, it can be determined that there are 2 separately recorded families that are all duplicates.

The fact that the FAMILY with all its supporting PIDs is a duplicate of another recorded family with a different set of PIDs becomes the main supporting reason for a single member of one family being a duplicate of a single member in the other. Especially when there is very little information in those single records by themselves to make a decision.

None of the canned answers deal with this very common situation where you aren't so much merging 2 records as it is part of merging 2 or more families. we're talking about up to around 30 PIDs that are necessary to actually show the reasoning for the merge--especially when all the data in the 2 PIDs being merged by itself is not adequate to provide a justifiable reason.

The canned answers are myopic in these situations where they are only focused on the 2 PIDs being merged. Those PIDs may not have enough information in them by themselves to make a justifiable merge without considering all the other PIDs related to them.

LegacyUser

Adrian Bruce said: :-)

LegacyUser

Adrian Bruce said: Maybe the canned reason statements need to have an "[insert x, y, z here]" to emphasise that more is needed.

Yes, I understand the fear that the canned reason may be a lowest common denominator - but isn't it better than "Same person", which is today's LCD?

LegacyUser

Tom Huber said: I agree with the general sentiment that having "canned" reason statements is not a good idea (and for the reasons that were given).

However, I also realize that having those "canned" statements available can serve as a guide for those users who do not know what to write and may actually cause them to go back and take another look at what they did. However, I suspect a majority will simply select one of the statements without any regard to its accuracy.

I prefer to use my own statements which include: "I have examined both records and believe they are for the same person, despite very little identifying information for the duplicate record."

LegacyUser

Lynne Stanley said: I really like the new Reason Statements for merges. After the "canned" reason, I add the why, such as "the birth year and place are the same", or whatever I based the merge on. It saves time by writing half of what I would write in anyway. I like that the canned responses show the ID's of both files. By the time I get to that point in the merging, I want to be done with the process. For me, it is a time-saver.

LegacyUser

Jeff Wiseman said: Well, It's going to be even more of a total nuisance now for people searching through Change history logs for details on why things changed. All of the merge reasons will be fully expanded to clutter up the change history log making it even harder to scan. As it is, what use to be as many a 10-20 changes on a single page can now easily require 5-10 pages to display with due to all the expanded reason statements. This will only exacerbate that issue.

LegacyUser

Adrian Bruce said: Whatever the merits of the specific canned reasons, it seems unlikely that they will be longer than an independently created reason that fully explains the logic for matching the two.

If your point is that we need the ability to easily expand or contract the reasons in bulk, then that's something that I can agree with.

LegacyUser

Christina Sachs Wagner said: They are easily modified. If you click on one, you simply need to edit it to meet your needs. It's what I've been doing since I found them! I love them because it's a great place to start and already includes the involved PIDs.

LegacyUser

Adrian Bruce said: Having the PIDs already there is a big plus for me, too. My suggestion would be that the canned reasons include place-holders for extra words to prompt someone to add the necessary details - eg, which bits conflict?

LegacyUser

m said: I was dismayed as well for the same reasons Kathryn mentioned.

LegacyUser

Kathryn Grant said: I agree! The reason statements would be so much more useful if they were presented as a starting place rather than a final statement.

LegacyUser

Jeff Wiseman said: Wow!

I don't know what other people's experience here is, but for nearly all merges that I have had to do, they have ALL involved looking at far more than 2 PIDs. When there is sparse data on the PIDs, you must look at all other related PIDs (which may even be duplicates to be identified later on as well). So basically, before I can do a merge, I need to identify all other possible duplicates in all the relationships of the other potential duplicates.

In my experience, comparing just PID A and PID B is almost never enough information to justifiably merge them.

And when I start merging PIDs, as a result there are usually several others that need to be merged at the same time because they reinforce each other. Sometimes I'll have to do as much as a dozen merges in less than an hour!

But what I have discovered with the new "quickie" reason selections is that they are addictive. In spite of the fact I normally tend to be pedantic about these things, I have discovered myself simply clicking on one and then moving on, glad to be done with another merge related cleanup of someone else's mess.

So the reasons for the merge is far more complicated than I document. I guess if someone disagrees, they can contact me and I can explain it :-(

LegacyUser

Paul said: My experience is rather different to yours, Jeff. So many of my merges are based on an ID being created with identical christening data to one that was created many years ago as part of the extraction program. No problem in making the straight PID A comparison with PID B for me, in most cases.

True, many I come across can involve multiple ID checks, but most of my work in this area is "extraction program related".

Incidentally, until recently duplicates added with the GEDCOM reason statement have hardly featured in my merging work, either. Funny how the experiences of different users can vary so much.