Wednesday, September 21, 2016

John Huff and FamilySearch Family Tree – #BYUFHGC

John Huff at the BYU Conference on Family History and GenealogyJohn Huff of FamilySearch gave a presentation titled “Making Data Decisions in Family Tree” at the recent 2016 BYU Conference on Family History and Genealogy.

The goals and principles behind New FamilySearch (NFS) were to improve the accuracy, quality, and pace of genealogy work; to reduce duplication of data and effort; to preserve all contributions; to allow only the contributor to change their information; and to encourage addition of sources.

What ended up happening was frustration over duplicates that couldn’t be combined, confusion over using the system, continuation of the “mine” versus “ours” mindset, limits on what could be fixed, collaboration difficulties, and problems introduced by centralized, automated changes.

There were data issues. Some of the records came from Ancestral File and the merge algorithms used back in its time had “splinched” persons [think “Frankenstein monsters”]. There was overwhelming duplication which led to IOUSes (individuals of unusual size). These were terrible for the system. [You may recall when NFS was deployed in Arizona the IOUSes caused the system to continually crash.]

Combines caused problems. There was no attribution for who did the combine. It was much easier to combine than to separate. [I think it could take 10 hours to undo a bad 10 second combine.] Combining multiple persons into one created merge magnets that attracted further combines. FamilySearch found one with more than 50 persons combined together.

FamilySearch had to sit down and decide what to do. They decided to change some of the goals and mindset. The principles of Family Tree are similar to NFS, but FamilySearch really wants sources. And rather than keep every alternative value for an event, they would keep only one conclusion. They would provide better tools for the community to provide evidence and clean up the data. They would allow errors to be fixed and bad changes to be fixed as easily as it was to introduce them. They wanted to provide attribution of changes and impede bad ones.

To build a better tree, you need to act as a community. Be courteous, kind, cheerful, and patient. Be respectful of others. Leave things in a better state than you found them. Communicate and collaborate. Add an email and make it visible. Use the messaging system. If contributors won’t respond to messages, after making efforts to contact them, go ahead and make changes—based on evidence.

Only make changes that you know. Knowing means the best conclusion of the community. If you don’t know something, don’t add, edit, or delete. [I would add to that, if you don’t have evidence and proof.] Before making changes, review the reason statements, sources, discussions, notes, and memories. Contact contributors. Don’t mark persons as dead unless you know they are dead. Don’t add persons you aren’t sure existed. Put them in a personal tree. Keep notes of relevant person IDs when making merges; have the end in mind before starting the merge.

If you want to help people not make changes to your stuff, the best defense is a good offense. Provide good reason statements. There is a great article: “Reason statements for adding, editing, and deleting information” in the FamilySearch Help Center. [I half-way disagree with John’s appraisal. The first half is great. The second half is a great collection of unhelpful reason statements “I attached this birth certificate because it provides evidence about his birth.” As an alternative, I would direct you to a similar article in the wiki: “How to Write Effective "Reason" Statement in the FamilySearch Family Tree.” Or see this article in the FamilySearch blog: “Tips and Tricks: Writing a Good Reason Statement for Changing a Record.” But I digress…]

Search records, including partner websites. FamilySearch provides hints. They work very hard to make the hints good. John thought the accuracy to be about 99%.

Use the watch list. You can filter your watch list by name or ID or location. Search for “DEL” to see all the deletions. You can sort in all sorts of ways. The watch list can also show the changes that were made, including hiding those made by yourself. You can filter to those made by a particular user. You can filter by anything on the page because it actually does a word search.

Use the Possible Duplicates feature. If you indicate a person is not a match, Family Tree will no longer show it as a possibility, but it can be seen under the Not a Match link. Use Dismiss Suggestions and Dismiss Problems. If you see exact duplicate conclusions (such as alternate name), delete all but one.

FamilySearch doesn’t yet have a good answer for how to solve edit wars. They are going to come up with a solution, but there are other things that must be done first. If someone gets abusive, contact support. If you desire to change a read-only person, contact support and request a change. If you find living persons marked deceased, contact support to fix it.

We are working on a way to allow you to share a group of private persons, John said.

It is rare that you need to delete persons. Delete only those who truly never existed. [You can delete persons you create that haven’t been changed by others. Otherwise, contact support.] If you find a person wrongly deleted, it can be found in the change history of the surviving record or if you have the ID.

Deleting relationships is the secret weapon to fixing up family messes. Delete relationships instead of persons. Clean up after yourself. Don’t orphan the persons or they’ll never show up again.

There are a set of cases where you can’t merge. The most common are persons with unknown sex, persons who would have too many things like comments, a few IOUSes, or restricted persons, like Read Only persons.

Remember that the only thing that will be available 100 years from now will be the data, not the system.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.