I think there should be a feature to mark people as containing many errors.
I have encountered people whom obviously have messed up connections and I feel there should be an option to mark these people as problematic/containing many errors. This would have multiple positive effects, one is that it would warn others that it may not be correct, so that they can use caution when using the data, but it would also mean that inexperienced researchers like myself could ask for help on a person. There could be an area where more experienced users can look through these reported profiles and attempt to correct them.
Thank you for any consideration you may make and if you have questions about what I mean please ask.
Comments
-
George
.
As an aside ...
.
Not detracting from your suggestion ...
.
There ALREADY is a Forum/Medium were ALL (not only, inexperienced) Users/Patrons CAN ask for HELP ...
.
And, not only in regards to an individual/person in "Family Tree" of 'FamilySearch' ...
.
Also, this is aside from the (Official) 'FamilySearch' "Support" (Case) system/network ...
.
That forum/medium is the "Community.FamilySearch" Forum ...
[ By the way, to which this "IDEAS" Forum, is currently attached ... ]
.
Within the "Community.FamilySearch" Forum, you can,
(1) Simply ask 'Questions' (ie. for HELP; or, just a general one) to the whole forum; or,
(2) "Join" a specific 'Group' in the forum, become a member of that group
...., [ And, of course, ask 'Questions' within that 'Group' ]
.
The "Community.FamilySearch" Forum is about ...
Users/Patrons HELPING Users/Patrons ...
[ ie. in other words, we help each other ... ]
.
Give it ago ...
.
"Join" the "Community.FamilySearch" Forum ...
https://community.familysearch.org/s/
.
Ask a 'Question' ... ask for HELP ...
"Join", a 'Group'; or, many, "Groups' within the forum ...
.
There are many out there, only to will to HELP others ...
.
Brett
.
0 -
I usually add a Discussion / Notes item to the Collaboration section for the IDs this problem applies to. I head it "Identity of (John Smith)" and list the possible errors / likely pitfalls to be encountered in researching the individual. Unfortunately, some users never bother to check out the Collaboration sections - and these are highly likely to be those who are most likely to be making errors concerning the identity of those IDs who have the same name and other similarities.
Where possible, detach any incorrectly attached sources yourself and amend wrong inputs in the Vitals and other sections. I have even created several new IDs for instances where several, separate individuals have been merged into one, then added the relevant sources / vitals details to each person.
0 -
Paul,
"I have even created several new IDs for instances where several, separate individuals have been merged into one, then added the relevant sources / vitals details to each person"
Remember that it is always better when possible to Restore those merged-away PIDs instead of creating brand new ones. By Restoring the deleted PIDs you keep the full change histories (including the bad merges as justification for the restorations) and you do not leave any temple ordinances that were performed prior to the merges attached to the incorrect PID surviving the merges (when you do a restore to a PID that had ordinance data on it prior to it being incorrectly merged away, that ordinance information is still there on the restored PID and is removed from any downstream merges that were performed).
Although it may seem easier. if you re-create all new PIDs in order to "start over", all of that information is permanently lost and ordinances will have to be all performed again, even though they had already been performed on the correct person record previously. Furthermore, the surviving PIDs (which we now know included wrong information from the earlier merges) will be left with the ordinance information from the old PIDs that should have been restored instead of re-created. That means those surviving PIDs will never have their temple work done since the incorrect ordinances carried over from the wrong merges makes it look like all of the ordinances for that person have been completed.
Although it can be a real nightmare trying to correct this stuff, the only way to avoid further damage in the system is to RESTORE incorrectly merged-away PIDs and not "start over" completely. This is why careless merging can cause such damage to data in the system.
0 -
As has been suggested by others, correcting any errors with a record is clearly the preferred situation. Undoing incorrect merges or correcting sources are the most obvious errors one can find. A few days ago I found a record with a relatively common name that had three christening records attached - one in 1774, one in 1789 and one in 1884. The names were the same and the parents names were the same - very common names and only the mothers given name. Anyone with a little thought would know that the sources could not all apply to the same person and that there was an issue with this record. There was a data flag because one christening was entered for the birth and another for the christening with the earlier being the christening so birth was 5 years after the christening. I did not fix because it was an issue raised by another user and I simply pointed out the issue to them.
Because there was a data flag it caused concern on a users part. However, if the christening and birth information had been reversed there would not have been a data flag and many users would have assumed the information to be correct. I do believe when we encounter records where these kinds of errors appear or when there is insufficient information to completely identify a person - I do believe it would be nice to have a feature where we could provide a rating of some type as to the completeness of likely correctness of the information. I was thinking of something in the range of 1 -5. I encounter records of this type and think I will get back to this and see if I can fix but time takes it toll and I forget. I do not take the time to write up the information in a note or the life sketch (my bad) but I think I might take the time to flag the questionable records which would be an asset to my myself and other users.
0 -
Yes, not quite George's suggestion, but to pick up on Paul and Jeff's methods of recreating the innocent victims of incorrect merges... I recently spent a week of my hobby time unravelling two families that had been merged / melded / mashed-up. One American and one English. To my surprise one of the (really) English children contained "within" them, not just the obvious English profile but two others that had been merged in - though I couldn't tell you whether this was before or after her translation across the Atlantic.
By looking at the All-Changes for that profile and filtering down to just look at merges I could find these other two profiles. (Result for that filtering logic, thank you!) Then I could re-instate those merge-deleted profiles. For me, the huge benefit was that the reinstated profile came back with their previous parents and / or spouses. Not merely had the daughter been merged into a different family, no thought had been taken to the parents and / or spouses left behind. There was one husband, if I recollect correctly, who was (up until that point) floating around with no family and no indication of who on Planet Earth he was. Restoring his wife put him back into a context.
I mention this because (a) it was probably much easier to re-instate those merge-deleted profiles than try and negotiate FamilySearch's "Good News - we may have found your new person already in the database" logic; and (b) to illustrate that the benefits of re-instating aren't just with Ordinances that us non-LDS can't see....
The caveat is that if A is merged into B and B into C and then C into D, and you're looking at just D - I think you can't immediately see any reference to A and B - I think....
0 -
To take George's suggestion now - there definitely needs to be a "Here Be Dragons" type warning visible somewhere.
To take the example of the cross-Atlantic families again - I can see two types of warning that I'd like to see highlighted.
1) This data may very well be wrong;
2) Do not do XXX without checking very carefully because it's almost certainly wrong.
Example of type 2 - "Do not confuse Peter Stubbs of the USA (PID XXXX-XXX) with Peter Stubbs of England (PID YYYY-YYY). There is no evidence of either crossing the Atlantic and plenty that they stayed where they were born."
Example of type 1 - "Peter Stubbs of the USA (PID XXXX-XXX) has previously been confused with Peter Stubbs of England (PID YYYY-YYY). Both now have wives named Mary. Mary Stubbs of England is correct. There is no evidence about the name of Mary Stubbs of the USA - her name may arise out of the previous confusion and is probably wrong."
I fear that Mary of the USA is incorrectly named but I am in no position to do anything other than flag up a probable error.
There may be other error types. Not sure if it's at all profitable to write any categorisation logic.
0 -
GeorgeBland2's suggestion surely has merit. My personal experience is that most of the time these things are discovered, it is the result of a schizophrenic person record. I.e., a single PID that is representing more than a single unique individual. This occurs through adding incorrect sources (and resulting conclusions) and/or incorrect merges.
It really would be beneficial to be able to flag a PID as "there is something really wrong here" with some kind of explanation. If someone comes along and fixes the issue, they could then remove the flag and explanation. Furthermore, it shouldn't be some kind of hack using the life sketch, Notes, or discussions as it can be an actual control function applied to the PID (see the following discussion).
However, the REAL power in this hasn't been mentioned yet. If such a flag has been set with an explanation, since it is identifying a person record that is ALREADY schizophrenic, that record should no longer be allowed to be used in subsequent merges until the problem is first fixed and the flag removed. This would be a tremendous aid in mitigating bad merges by people who have not really looked at the details of the records being merged well enough. If they remove the flag (i.e., they override it) just so they can do a merge, that unjustified change to the record (i.e., the removal of the flag) would be plainly and permanently recorded in the change history for that PID.
If someone wants to use that PID in a merge, they would be forced to fix the other problems on it first (which is EXACTLY what should be happening anyway)!
Not too long ago FS did add a test during the merge process that would bring up a warning if the record had already been involved in multiple merges. But the problem is not really multiple merges (e.g., recombining PIDs taken from the IGI records can necessitate dozens of merges as a family is reconstructed, and THOSE should NOT get the warning). It's the "cross-pollination" from multiple people with the same name and similar locations. That can happen even without incorrect merges occurring.
Yes, I really LIKE this idea as it could be the foundation for a serious mitigation of the current bad merges problem that rampantly continues today!
0 -
Jeff
I usually do just as you say. My reference to creating new IDs refers to where, say, a user (or users) has added sources for a John Smith of Essex, a John Smith of Lancashire and a John Smith of Yorkshire to an existing ID for a John Smith of Dorset. It is where I cannot find existing IDs for those other John Smiths (which is often the case) that I create new IDs, to which I then attach the relevant sources. Incidentally, I find the best way to do this is to create the IDs first, then go to Review Attachments (on the sources attached to the wrong John Smith), detach and immediately reattach the source(s) to the correct John Smith(s).
Mind you, if you are dealing with an individual who IS actually called John Smith, I imagine locating the correct, alternative ones (with or without using FIND) would be quite some job!
(The worst example I actually encountered was with an individual named James Young, to whom sources for individuals of that name from the length of England - and one from the USA - had been attached! The resulting mess took me over two days to sort out.)
0 -
Paul - "It is where I cannot find existing IDs for those other John Smiths ... that I create new IDs"
Yes, I would agree there - it's what I seem to do. For whatever reason, I did (at least) once fail to find all the merge deleted PIDs of one mash-up and ended up, as you say, creating a new one - just for that one.
0 -
Re Jeff's proposal for a block on merges until the problem is fixed. Yes, I like this - there would have to be a facility to unblock regardless, for all sorts of reasons, but I suspect just having the block visible would inhibit most carry-on-regardless merges.
However, not sure how that works with my instance of the American wife named Mary Stubbs who almost certainly isn't named anything of the sort - blocking further merges probably isn't desirable if none of the records have a name.
Flippant comment - where Jeff says "the foundation for a serious mitigation", I read it as "the foundation for a serious LITIGATION"!
0 -
"I suspect just having the block visible would inhibit most carry-on-regardless merges"
I'm suggesting that the block is a true functional block. If it has been set, nobody can merge that record with anything else. Anyone can turn it off if they want in order to further merge it (and likely scramble the problem even more), but the issue is that they must make a distinct decision to turn it off first. And since it is an attribute of the PID, it should also show up in the change history with the REASON why that person turned it off.
"blocking further merges probably isn't desirable if none of the records have a name"
missing names, vitals, or other conclusions based on the records attached to a PID in itself is no reason for a block. But if you have conflicting records and relationship attachments to a PID, that would justify someone putting a block on merges with that PID. That applies to the support of ALL conclusions in the person record regardless of which items they are (including the name vital).
I read it as "the foundation for a serious LITIGATION"
Let's hope it never reaches that point :-)
0
