Gedcom Challenge: Show Us The Data

LegacyUser · October 21, 2019

Tom Huber said: Well, GEDCOMs are not the only problem. I've run into a situation where MyHeritage is back at it with their sync process. It has caused a lot of problems, especially when a user syncs trashy records with FamilySearch FamilyTree. See my discussion about Ancestral Quest V16 (which problem actually existed before the updated version became available, but I didn't see it because I hadn't extended my local database by downloading my extended families. (https://getsatisfaction.com/familysea...)

As I started cleaning up some of the weird entries, I found that a user had sync'd their MyHeritage tree with FamilySearch FamilyTree.

LegacyUser · October 21, 2019

Robert Wren said: Tom,

How did you determine that a problem was "that a user had sync'd their MyHeritage tree with FamilySearch FamilyTree." ??

As far as I can determine, nothing shows in FS from a MyH sync; any 'change' only shows as done be the person doing the synch. MyH also gives the priority to FS, and will do a bilateral change to both if the change is two a 'different' item. (if I change something in MyH and someone has already changed the same item, the FS item is NOT changed & the item in MyH is.changed to agree with FS)

It MIGHT actually be better if it did note the change was via MyH, but as far as I can see there no trace. But, currently, a MyH change appears to be the same as if it was changed within FS.

Sorry to get off topic, RotKapchen

LegacyUser · October 22, 2019

Brett said: All

This was disappointing to come across ...

The individual's/person's record came from "New.FamilySearch"; and, nothing had been basically (except, the addition of a "Source" in 2015) done to to the record until we started working on the record in 2017 to 2018.

And, the above entry/change has been the only entry/change (eg. NO "Merges"/"Combines", etc) since we had done any work back in March 2018

Really disappointing!

Brett

ps: Forgot to mention that, as far as we can recall, this individual/person DID NOT even should up on the, "Watch" list for "CHANGES TO PEOPLE I'M WATCHING"; or, the Weekly E-mail for "Changes" to people we are "Watching" - possibly, because, the "Change" was by "FamilySearch" and not a 'lowly' User/Patron - otherwise, we would have been on to of that quick smart - this is concerning.

.

LegacyUser · October 25, 2019

rotkapchen said: Would love to see justification for this. Clearly there were things that were labeled FamilySearch back in the day when I saw things I know I had done labeled FamilySearch (the system was in total meltdown). But June 2019? Someone has some 'splainin' to do.

LegacyUser · October 25, 2019

rotkapchen said: If you note in my corrections above there are a whole bunch by TerryMcElroy and none are labeled GEDCOM. The question is, how did they get there? Maybe this circles back to Robert Wren's question, how did Tom Huber know that there was a dump from a particular 3rd party software?

LegacyUser · October 25, 2019

Stephanie Spencer Booth said: Me too! I've seen FamilySearch in the change log when support has changed a record, but never using a GEDCOM!

LegacyUser · October 25, 2019

rotkapchen said: Oh, goodie. A new GEDCOM load 4 days ago -- with duplicates already released to the temple. What in the world is wrong with your understanding of this problem Ron Tanner? When are you going to stop covering up this issue and resolve it? I keep reporting it to any General Authority that will listen. I'm sure you keep reassuring them there is no issue. You will be held accountable, eventually.

List to follow. It's going to be a long night.

LegacyUser · October 25, 2019

LegacyUser · October 29, 2019

rotkapchen said: Please send someone on staff to Dataversity:
https://www.dataversity.net/category/...

LegacyUser · November 15, 2019

rotkapchen said: Another day wasted on the errors of others:

11/14/2019
https://www.familysearch.org/tree/mer... GEDCOM dup by GeorgeThibodeau
https://www.familysearch.org/tree/mer... GEDCOM dup by GeorgeThibodeau
https://www.familysearch.org/tree/mer... bad data dup, wrong relationships
https://www.familysearch.org/tree/mer... dup by M T Evans, shared with temple
https://www.familysearch.org/tree/mer... GEDCOM dup Kyle Blake_1, shared with temple
https://www.familysearch.org/tree/mer... dup by TerryMcElroy, released to temple
https://www.familysearch.org/tree/mer... GEDCOM dup by RebeccaSpiers, released to temple, B/C/I duplicated
https://www.familysearch.org/tree/mer... GEDCOM dup by RebeccaSpiers, released to temple, B/C/I duplicated
https://www.familysearch.org/tree/mer... legacy records never merged, all work duplicated
https://www.familysearch.org/tree/mer... dup by TerryMcElroy
https://www.familysearch.org/tree/mer... dup by TerryMcElroy
https://www.familysearch.org/tree/mer... dup by TerryMcElroy
https://www.familysearch.org/tree/mer... dup by TerryMcElroy
https://www.familysearch.org/tree/mer... dup by TerryMcElroy
https://www.familysearch.org/tree/mer... dup by E Hunkele, released to temple
https://www.familysearch.org/tree/mer... dup by E Hunkele, released to temple
https://www.familysearch.org/tree/mer... dup by E Hunkele, released to temple
https://www.familysearch.org/tree/mer... dup by E Hunkele, released to temple
https://www.familysearch.org/tree/mer... dup by E Hunkele, released to temple
https://www.familysearch.org/tree/mer... dup by E Hunkele, released to temple
https://www.familysearch.org/tree/mer... dup by STACEY WHITE_1

LegacyUser · November 15, 2019

Tom Huber said: It would be nice to know the source for the non-GEDCOM dups. I think that FS can find out what fed the system with the dup, whether it was created with:

The source-linker
Ancestral Quest
RootsMagic
Legacy
Ancestry-FS connections (members only)
or manually entered.

We know it wasn't the GEDCOM, because those are indicated, but given some of the comments previously, it appears that there is a demographic showing where the duplicate entries are coming from.

I don't know what FamilySearch can do, if anything, to stop user stupidity, but the source linker could use some serious improvements (See "Add person on Source Linker does not update when information in the person (to be added) flyout is updated with known information. https://getsatisfaction.com/familysea...)

I use Ancestral Quest and I haven't recently used it to add a parent, spouse or child, but as I remember, before I can add the new person, I have to perform a search against the massive tree. While I can ignore the results, for someone to be doing that accidentally and consistently for a number of people seems highly unlikely.

I trust that the other two systems (RootsMagic and Legacy) are similar. I can't speak to adding people from Ancestry, since I seldom use the connection to the massive tree myself.

It almost looks like the people involved are doing this on purpose.

LegacyUser · November 15, 2019

Adrian Bruce said: I am still concerned that I don't know what's being measured when FS talks of dupes being found.

If my ancestor had 6 children baptised and their parish was subject to an extraction program, then there will possibly be 8 versions of them - 6 as a parent, 1 in a marriage and 1 for their own baptism. I don't count those as 8 duplicates but am unclear whether they might get picked up like that in the FS analysis.

And if I'm entering a census family into FSFT, as I have said before, I refuse to halt my data entry process to look for dupes part way. I will enter the whole family and look to merge the dupes later - potentially quite a bit later, when I am in a position to look at the next family. If this is being counted as an issue for the duplication report (and surely it must be???) then I suggest that it's missing the point. And no, I'm not totally sure how to count the issues correctly there.

For me, it becomes an issue when there is a whole group of families duplicated with no merge. And surely, it becomes an issue when people start looking to submit ordinances without checking for dupes (reminder - I am not an LDS member so apologise if I have events and terminology wrong).

LegacyUser · November 15, 2019

Tom Huber said: You have your terminology correct.

Anyway, When a person is added through the source-linker, it will bring up possible duplicates in that fixed flyout. The problem is that in many cases, the information from the source is incomplete and so it will not find the records for that person, even though they are in the massive tree. Being able to update the information in the flyout should be easy, but simply cannot be done. That should solve a lot of the dups that are created when existing records are in the massive tree.

We know when a dup is added from a GEDCOM, but it faces the same problem as the source linker -- incomplete information (often a problem with the compare process as much as anything). GEDCOMs typically are from unsourced trees and as such even if there are sources, they don't seem to be taken into account.

So, getting back to your process, Adrian, I find no fault in it. Any dupes should show up as you add a person from a census. If they don't, then I will add the person, just like you do.

LegacyUser · December 20, 2019

rotkapchen said: Common guys. I really can't keep up with this mess.
SOMEONE PLEASE DO SOMETHING!!!!!!!
There are dates on some of these loads in the past few months

11/14/2019
https://www.familysearch.org/tree/mer... dup by TerryMcElroy, printed for temple work
https://www.familysearch.org/tree/mer... dup by TerryMcElroy, shared with templehttps://www.familysearch.org/tree/mer... dup by GraddyMichaelBaker1, reserved for temple work

12/10/2019
https://www.familysearch.org/tree/mer... dup by TerryMcElroy, shared with temple https://www.familysearch.org/tree/mer... bad data dup by PeterSchuelke1, released to templehttps://www.familysearch.org/tree/mer... bad data dup by PeterSchuelke1, released to temple
https://www.familysearch.org/tree/mer... dup by PeterSchuelke1, released to temple
https://www.familysearch.org/tree/mer... dup by PeterSchuelke1, released to temple
https://www.familysearch.org/tree/mer... dup by PeterSchuelke1, released to temple
https://www.familysearch.org/tree/mer... dup by PeterSchuelke1, released to temple
https://www.familysearch.org/tree/mer... dup by PeterSchuelke1, released to temple
https://www.familysearch.org/tree/mer... dup by TerryMcElroy, with errors
https://www.familysearch.org/tree/mer... GEDCOM dup by Wilfred G. LeBlanc, printed, B/C completed
https://www.familysearch.org/tree/mer... GEDCOM dup by John William Gaudette, released to temple, B/C completed
https://www.familysearch.org/tree/mer... dup by AdamsShepardAlfred1
https://www.familysearch.org/tree/mer... dup by PeterSchuelke1, reserved not printed

12/20/2019
https://www.familysearch.org/tree/mer... GEDCOM dup by Wilfred G. LeBlanc with errors, released to temple, B/C/I completed
https://www.familysearch.org/tree/mer... GEDCOM dup by Wilfred G. LeBlanc with errors, released to temple, B completed
https://www.familysearch.org/tree/mer... dup by TerryMcElroy

LegacyUser · December 20, 2019

joe martel said: I went and looked at a couple of these and they weren't created via Gedcom.
It has been a number of months since the Gedcom dup checking flow was changed and Gedcom is now consistently one of the lowest % dup contributors. Others products and their users can be multiple times the Gedcom dup rate.

I really understand the frustration. My typically quiet tree suffered quite a bit of damage these last weeks. I will have to go clean it up. It really does come down to certain users who choose to create duplicates more than other users. I think contacting those users, in a friendly, helpful.... voice is the best approach today. There are thoughts about how to prevent bad behavior but it is complex. Sorry.

LegacyUser · December 20, 2019

rotkapchen said: While I appreciate the candor it is not sufficient.

I have always contacted individuals. For the most part I have never received a reply (there are a few exceptions). But here is where Family Search fails - in policy - where individuals are perfectly willing to 'fix' their errors they are not provided any means to do so. Where is that 'fix'?

And for those who refuse to participate (an issue I have had with Family Search making the 'claim' that it is a social environment) there is no means by which to resolve their unwillingness to collaborate. This too is a fundamental part of this environment that requires responsibility on the part of Family Search.

So let's suspend the issues with GEDCOM for a moment, regardless of the source, what is being done about duplicates in general?

Now let's suspend the issue of duplicate loading for a moment, what is being done about the number of duplicates being released to the temple for work that clearly does not need to be done? If nothing else, everything of recent I have submitted fits that scenario.

Are you suggesting that duplicate work in the temple is not an issue? Clearly that has been my real point all along - but I had to pick particular battles that the tech group could relate to in order to get any traction.

I have repeatedly asked for insights into what analytics are being presented to show that duplicates are not an issue and have never received any response or real perspective. I have been told by individuals who have seen some form of such reports that the reports indicate it is not an issue. That's great. Clearly the data I show suggests that the analysis may be missing something.

Therein lies the opportunity.

In the meantime, I still am not being helped in any way to recover my personal time to attend the temple, as this work is FAR more critical, particularly because it continues to be ignored.

LegacyUser · December 20, 2019

Brett said: rotkapchen

SPOT ON

Brett

LegacyUser · December 20, 2019

rotkapchen said: Thanks Brett.

LegacyUser · December 21, 2019

Stephanie Spencer Booth said: rotkapchen,

Thanks for stating the problem so clearly. Yes, the duplicates that get dumped in the temple system really bother me too. Fortunately, I have time to serve in the temple (because it is only 4 blocks away) and clean up dups in Family Tree. Almost every time I find dups, they are in the temple system.

It does seem like it is a user problem. The users are not taking the time to do the temple work themselves, and they're not taking the time to keep Family Tree cleaned up either. They invest as little time as possible to really foul up the system, and they are probably patting themselves on the back the whole time!

I don't know what the solution is, but I will continue to merge dups anytime I have spare minutes so that SOME of the ordinances done in the temple are for people who've never had them done before. Know that your efforts are appreciated, rotkapchen, and not just by the living.

LegacyUser · December 21, 2019

Brett said: Stephanie

The ONLY "Solution" is ... TRAINING, Training; and, more, training ...

BY the "Ward/Branch (and, Stake) Temple and Family History, Consultants" ...

Nothing more, nothing less ...

Brett

ps: Not to mention STOPPING the ability to up-load GEDCOM Files into "Family Tree" of "FamilySearch" - SORRY!.

.

LegacyUser · December 21, 2019

Stephanie Spencer Booth said: Brett,

I agree 100%. As a family history center director, that's one of my main concerns, that FamilySearch users think they don't need any help because it's just so easy. Those are the users who need the most help.

In my monthly report to church headquarters, I requested that they run a campaign to show how much users could benefit from visiting a family history center instead of coming up with a new trick that makes them think they can do it all by themselves. I've got some really talented volunteers working at our center who can do wonders in an hour with a patron, but the patron has to come in first. We have classes that are free and anyone can come, but they do have to come to benefit.

The GEDCOM upload is an issue because those same users who "don't need any help" want to upload as much as possible within the least amount of time without concern for accuracy in the data. They're not going to come back later and spend any time cleaning up the mess, no matter what method they are using to load the data.

LegacyUser · December 21, 2019

Brett said: Stephanie

Same, same ... well aware ... you are 'Preaching' to the 'Converted'.

Brett

ps: "They" WANT their, DATA; and, (Temple) WORK to prevail, no matter what ...

pps: Unfortunately, 'human nature' ... We ALL think WE know all; and, WE are the ONLY "One" that does ...

.

LegacyUser · December 21, 2019

m said: I have LDS pioneer lines and non-LDS lines and I can say there are many duplicates on both LDS and non-LDS lines----and I think many more duplicates on the NM non-LDS lines. (Why, I don't know.)

LegacyUser · December 21, 2019

m said: I have not noticed a decrease in duplicates on either LDS or non-LDS lines. I seem to be merging the same amount.

LegacyUser · December 23, 2019

rotkapchen said: Stephanie: We need more people like you. It infuriated me when I asked the Dallas Temple Recorder, 8 years ago if when they attended training the topic of duplicates was discussed and he said, "No." So I knew there was no hope to solve the problem downstream. I've even reported specific instances of duplicates that were released to the temple when we could not merge large files and they also refused to do anything about it.

Wherein lies relevant responsibility?

We're always told to take responsibility. I've done that. You've done that. Where are the others?

Brett: Sorry. Having lived through technology and training for decades, training is NOT the issue - particularly once you move into the always-beta world. It requires world-class design, which we clearly do not have here.

LegacyUser · December 23, 2019

rotkapchen said: Thanks for adding your experiences.

LegacyUser · December 23, 2019

Brett said: rotkapchen

Sorry, we will NEVER get "... world-class design ...''.

"FamilySearch" has limited resources.

The Church has limited resources to make available to "FamilySearch".

How can we attract world-class Programmers/Engineers ...

The best we can hope for is ... TRAINING, Training; and, more, training ... by the "Ward/Branch (and, Stake) Temple and Family History, Consultants" ... Nothing more, nothing less ...

Also, "Family Tree" of "FamilySearch" NEEDS to be DRIVEN by US, the User/Patrons; NOT, the Programmers/Engineers (ie. Designers and Developers) as it is now.

Plus, in "Family Tree" of "FamilySearch" there NEEDS to be MORE participation by US, the Users/Patrons, from a World wide cross-sectional "Focus" Group, with regard to, Design and Development; and "Testing".

Nothing more, nothing less ...

Brett

.

LegacyUser · December 23, 2019

rotkapchen said: Brett: I'll concede most of that for a moment. The issue is making the most of the limited resources, where and how time/effort is focused. The other issue is the huge chasm between the Temple Department and Family Search. Get them on the same page -- same resources, just working smarter.

LegacyUser · December 23, 2019

Brett said: rotkapchen

I do not think that there is not so much as a 'chasm' between the "Temple Department" and "FamilySearch", in fact, I would suggest the "Temple Department" follow the counsel of "FamilySearch".

One problem/issue is that it is PARTICIPATION over QUALITY, that is the current direction.

Another problem/issue is that the general populous WANT their, DATA; and, their (Temple) WORK to prevail, no matter what ...

Unfortunately, 'human nature' ... We ALL think WE know all; and, WE are the ONLY "One" that does ...

Hence, the amount of (Temple) WORK being done for "Duplicates", that were "Dismissed" as "Duplicates"; and, NOT, "Merged" / "Combined".

That 'all boils down to' ... TRAINING, Training; and, more, training ... by the "Ward/Branch (and, Stake) Temple and Family History, Consultants".

There is much less trouble from the non-member Users/Patrons, than from the Member Users/Patrons.

The non-member Users/Patrons ARE better "Genealogists" (ie. Genealogy / Family History Researchers), than the Member Users/Patrons.

I know, 'been there, done that', still do ...

Brett

.

LegacyUser · December 23, 2019

Tom Huber said: The way the GEDCOM process is now set up, it is not easy to accidentally add a lot of people as duplicates, although the compare process and screens could still use a lot of work. Any GEDCOM flagged duplicates are usually older (not recent within the past two or three months) and "left over" from the earlier system.

The bigger problem rests with people who do not fully understand the nature of the massive tree and how to use it. They may (and I've been guilty of this myself) merge two families, but fail to complete merging all the duplicate children. A few may produce duplicates and reserve them for whatever purpose. These seem to be common and need to stop.

I agree with Joe in that communication often takes care of the problem. A kindly written message of appreciation thanking them for their interest in our relatives is often appreciated.

Gedcom Challenge: Show Us The Data

Comments

Categories