Best Of

@Áine Ní Donnghaile is correct. This has been resolved! Sam 😊

Here's my proposed abuse report. Comments please - current plan is to submit it next Monday. People's favourite (?) examples would also be useful.

(Edit - on second thoughts I have removed all reference to oversight - it's obvious it's inadequate, but we can't prove it …)

Over the last few years the BYU Record Linking Lab (RLL, https://record-linking-lab.byu.edu/ ) has added and modified high volumes of entries to the FS Family Tree.

This abuse report relates to the fact that these projects, which use the FamilySearch APIs via automated scripts, have resulted in very large numbers of FT data quality problems, in particular profile duplication and inappropriate source attachments.

The relevant user names are USCensusProject, CommunityCensus Project, and TreeBuilding Project.

We accept that inappropriate changes to the Tree are not normally seen as abuse. BYU RLL’s projects, however, do not work with the Family Tree as ordinary users do. This is a matter both of scale and of accountability.

One would expect the RLL team’s work to be of a high standard; in practice, however, teams of student volunteers use the APIs to create or change many profiles at a time (millions, in some cases),

• without complying with FS’ published API usage standards (see https://www.familysearch.org/developers/docs/guides/implementation-cert , and, in particular, https://developers.familysearch.org/main/docs/contributing-to-the-familysearch-family-tree ),
• without taking existing data (or indeed the needs of other users) into account, and
• frequently in a manner indicating lack of care in design, implementation, and/or testing (for examples, see https://community.familysearch.org/en/discussion/comment/608281/#Comment_608281).

Note that the student volunteers (see https://universe.byu.edu/2023/02/27/byu-professor-connects-the-human-family-with-research-lab/ ) appear to have been asked to ‘grow the tree in any way [they] could’.

BYU RLL’s stated approach (https://community.familysearch.org/en/discussion/comment/573042/#Comment_573042) is to automate many of the inserts and changes to a certain point, with the profiles then being left, silently, and often in an internally inconsistent state, for manual editing by other volunteers. (One widespread example is the use of married surnames when creating Census wife profiles.) This ‘halfway house’ approach was clearly never realistic as an overall solution, given the vast numbers of profiles involved.

We have made considerable efforts, going back to September 2024, to raise these matters with BYU RLL themselves; via FS Support; and (as recommended by Support) via Suggest an Idea. Despite some initially promising interactions, we have realistically made no progress at all.

We can provide detailed examples as required.

Here's a proposed missive to Joe - please let me know of anything you want changed before I send it (at the end of the month I think). It would also be good to know of anyone we could usefully add to the conversation (I'm wondering about the DQS team, for example).

Hi again Joe, I hope all is well with you and your team.

We are concerned that we have heard nothing in relation to the points raised with you in November 2024, responded to by you positively on 27 November 2024, and highlighted again in April this year.

There appears to have been no communication whatever from BYU RLL to inform the rest of the FT user base of your current projects or plans.

Meaningful reason statements are still absent from the vast majority of BYU RLL changes to the Family Tree (automated and otherwise), and BYU RLL users are still not responding to contact requests.

Current FT information is still not being taken into account appropriately by your user tools.

We have seen no improvement in the handling of BYU RLL changes requiring multiple interventions, in terms of either timeliness or collaboration. Profiles are still being left for extensive periods in a state that does not reflect genealogy best practice.

Enormous numbers of BYU RLL-created stand-alone ‘Numident triplet’ duplicates remain present in FT.

Overall our impression is that no progress has been made, so that you continue to introduce data quality issues to Family Tree and to waste the time of FamilySearch’s experienced users.

If these matters are currently being worked on within BYU RLL, FS, or both, please let us know what is happening and when we can expect results.

We are happy to help you resolve these fundamental issues if you let us know how we can contribute.

Thank you

Mandy Shaw and other interested FamilySearch Community members

@MandyShaw1 The same behavior of falling off the list of active threads was noted on one about the CensusProject(s). I have to think it may be done by design.

I actually encountered a NUMIDENT-based triplet today. I was, shall we say, not happy about it: it meant that I couldn't use Source Linker's profile-adding shortcut at all. Instead, I had a choice between the tedium of merging or the aggravation of editing Every Single Field on three profiles. (I ended up doing one-third one way and two-thirds the other way.)

The people were my spouse's distant cousins, so the whole "a stranger touched my grandmother!" squickiness didn't apply in this case, but I am very grateful that my dad falls outside the date range for this project.

My experience points out another problem with purposely adding orphans like this: the mother in the tryptich shared her full (maiden) name with one aunt and her married surname and residence with another aunt. In other words, it would've been dead easy to connect up those orphans the wrong way 'round. The existence of those three profiles made sorting things out extra-complicated, since the parents had no vitals added whatsoever, so there was no way to tell whether I was looking at the aunt or the niece.

I wonder how many of the people expressing joy to Joe were just being polite, and how many of them were happy because they didn't have the faintest clue what they were actually looking at. In my experience, people only like seeing data about their close relatives if it's all 100% correct — and we all know that that happens approximately never.

I certainly agree that bulk orphan profile creation needs to stop. BUT, I'm also seeing existing profiles damaged by the attachment of similar-name NUMIDENT records. We don't need that damage to the integrity of the FSFT.

@Joe Price 4 wrote:

you will have to clarify the thing about 12 years.

As @No one in particular wrote:

Orphan profiles eat time. They convert trivial tasks into onerous ones.

The "seed" data in the Tree — which was created twelve years ago — consisted, for very large part, of such orphan, disconnected tryptichs (parents and one child). Cleaning up such a group of duplicate profiles into a single set of parents with all of their children involves many, many merges, which are difficult and tedious and stressful. It doesn't help that the task seems endless: every time I work on a branch from a place and denomination that had indexes on FS before 2012, I encounter these index-based disconnected duplicates. Every. Time. Even after twelve years.