Show Possible Duplicates as a Data Problem in Tree View.
LegacyUser
✭✭✭✭
foleydb said: Show possible DUPLICATES as a DATA PROBLEM with a red box exclamation point PLEASE. In the last four years here's what I've done:
My Contributions: 230976
Sources I Have Attached: 196047
Memories I Have Attached: 1198
People I Have Created: 33731
I regularly manage and correct the records and relationships of tens of thousands of people in my wider family tree, so I know precisely what I'm doing and talking about. There is no more important task or improvement you could make than to finally show possible duplicates in the tree view as a DATA PROBLEM. You show non-standardized dates and locations this way, which is vastly LESS IMPORTANT than possible duplicates. PLEASE, PLEASE, PLEASE fix this. Thanks.
My Contributions: 230976
Sources I Have Attached: 196047
Memories I Have Attached: 1198
People I Have Created: 33731
I regularly manage and correct the records and relationships of tens of thousands of people in my wider family tree, so I know precisely what I'm doing and talking about. There is no more important task or improvement you could make than to finally show possible duplicates in the tree view as a DATA PROBLEM. You show non-standardized dates and locations this way, which is vastly LESS IMPORTANT than possible duplicates. PLEASE, PLEASE, PLEASE fix this. Thanks.
Tagged:
0
Comments
-
Paul said: YOU may know what you are doing - sadly many, many careless / inexperienced users do not. Until the "possible duplicate" algorithm is considerably enhanced - to prevent the considerable number of those that are "not (even) a (close) match" - I want them to be hidden as deeply as possible!
I shudder to think how many crazy merges have been made following "FamilySearch" suggestions that two IDs are a possible match. Until I stop seeing several James Young individuals, from all over England, being consolidated into one ID, or persons named John Wrightson being merged with someone named John Wright, I would rather leave merging of duplicates until a later stage.
If you haven't come across these serious problems - created by over-enthusiastic users, led into a false sense of security by these suggestions - you are most fortunate. I would rather not see genuine, separate individuals disappear from the Family Tree (as is currently happening far too often), than allow any further encouragement of incorrect merges.
In any case, these are NOT data problems. Wrongly formatted dates and place names fall into that category, but not suggestions relating to individuals' possible, matching identities.0 -
foleydb said: Thanks for your reply, but hiding possible duplicates seems unlikely to be a useful solution. I have found it to be extremely rare that anyone creates a mistaken merge anywhere on the part of the tree that I tend. Which is all the more reason for the system to highlight possible merges in tree view so I can do this, and not leave it to other less experienced contributors. Having to open a person's listing to see the possible duplicate notification makes this an almost random process, instead of one that I can deal with consistently and effectively.0
-
Paul said: I'm always interested to read of how different users' experiences and work in Family Tree varies so much from mine. I have posted problems here over the years and the lack of any response has proved no one else had apparently encountered my problem! In short, my reply here was based on my problems (and those of many others that have posted here) in finding a need to occasionally spend two or three days clearing up the mess of multiple, incorrect merges.
To illustrate how this happens, I am placing the screenshot below. Admittedly, what it does not show is that both "Georges" had parents named William & Elizabeth. True, the birth dates are "close", but I would see very little evidence for one to be put as a possible duplicate of the other. Unfortunately, there are many careless users who will not see things that way and, apparently without any evaluation of the facts, go right ahead and make the merge. I only wish I had your experience of rarely coming across examples of this - in which case, I probably would not have written my previous remarks.
None of us will be around forever to check changes to individuals on our "Following" list (I can only speculate on the amount of incorrect changes / merges that have been made to IDs I am not keeping an eye on), so I do despair over the possibility that so much of my hard work will eventually be completely undone.
(I have just noticed the totally different birth / christening places a careless user has inputted for the individual on the left. In spite of the whole family being of Norfolk, she has mysteriously added a Lancashire christening. BTW - both Wiggenhall and Ashton are 100 miles from Ashby de la Zouch - in different directions - and Wiggenhall & Ashton are about 180 miles apart!)
Just to illustrate why I would prefer these suggestions to to appear more prominently, as per your request. However, in spite of my comments, I would stress that I feel you are making a reasonable request here, which I'm sure many users would also be pleased to see implemented.0 -
Adrian Bruce said: Yes, I'm torn between the two points of view here.
On the one hand, I agree with Paul that I have to unravel too many "Name's The Same" merges - such as the instance where my ancestors in Cheshire were merged with two couples of the same name from Devon, one couple of the same name from Kent and another couple of the same name from Lincolnshire who would have needed a time-machine to have had the children that the resultant mash-up family had.
The techies have told us they are working on the merge-suggestion algorithms, but by their very nature we don't see the ones that aren't suggested any more so it's still something we have to worry about.
On the other hand, I would agree with "foleydb" that being able to prioritise merge suggestions would seem a good idea. Truth is, Paul, I'd rather see them and reject them myself if necessary, before someone else sees them and does a daft merge. Hmm. On that basis, I am swinging towards the OP's view.0
This discussion has been closed.