Is the user "TreeBuilding Project" taking the tree forward or wasting time?

Well, I have now had what feels like a very positive response from FS Support (despite the 'hopefully' and 'eventually'):

We have not forgotten about you even though we are somewhat slow at some things.

Your message has been forwarded to the FamilySearch team that will follow up with the BYU RLL.

FamilySearch does not control the RLL but there are hopefully some influences that will eventually make a difference in the issues that you have described.

I have said thank you very much and requested that the team concerned keep us posted. We'll see.

@MandyShaw1

I'm sure it's not that many of us don't appreciate your efforts in highlighting the damage these projects have inflicted on Family Tree, but have become so exasperated at the lack of recognition of the fact that we "gave up the will" long ago. So, whilst I admire your seeming indefatigability with regards to this issue, as long as FamilySearch management take a positive view of this work I doubt whether any amount of our negative reports will be of help in improving the situation.

In theory, this work (in the form of "stand alone" projects) could have provided excellent databases, but - as we have discovered - linking the data directly to Family Tree has just caused us too much grief!

@Tex Lawrence There seems to me to be a big difference in practice between FS' AI initiatives and BYU RLL's efforts.

Despite teething troubles, we are beginning to see FS' internal work having a real positive impact on FT data quality; their solutions don't update FT, but they do enable users to do a better job themselves. Full Text Search seems to me to be an unmitigated success; and from what I have read and seen, the Computer Assisted Indexing work is far better planned and implemented than the rather scattergun front window given to it by Get Involved would imply.

BYU have their own AI projects fed by FS Records and their indexes (Censuses, Numident). Initiatives like their Census Tree analytics tools are not a problem from my perspective. What is a problem is that they (possibly encouraged by FS, but we don't know this) at some point decided it was a good idea for teams of student volunteers, under what seem to me to be completely inadequate project controls, to update/create millions of FT profiles automatically using their AI models and the FS FT APIs.

Oh dear, can't help thinking that's worse if anything (and not conducive to BYU's believably finding random people at state fairs on the Tree, either).

I've just been doing my monthly check of BYU RLL's activities against the profiles in my newly refreshed analysis database. A warning that the TreeBuilding Project user appears to have started doing merges (e.g. see GLBB-XDY), presumably via the documented Merge API.

More on the meaningless Residence values for WW2 Draft Registration Cards.

In my analysis database there are 4 profiles that had these sources added by TreeBuilding Project on 6th September. All have these meaningless Residence addresses, of which all but one have the 'Non-Standardised Place' message showing.

However that one (G6Z1-8FK) was subsequently (7th September) changed by the FamilySearch user to add a standardised place. This is something that appears to have happened to nearly 2,000 Residence events on profiles in my database (mostly untagged), with the updates occurring from June 2021 up to date. Looks like there has been a FS bot running regularly against FT tidying up missing standardised places. Maybe BYU are assuming FS will clean up after them in this way, given that they can't be bothered to put an accurate value in place to start with (noting that full Residence address information is definitely present in the record persona metadata).

(Incidentally the only other Residence tags I can find in my database that were added by TreeBuilding Project are Numident ones, and they appear to have had sensible place names in place from the start.)

I think I may have found another angle.

I have been investigating the standards that apply to organisations whose applications make modifications to the Family Tree via the FS APIs, in particular this: https://developers.familysearch.org/main/docs/contributing-to-the-familysearch-family-tree

BYU RLL are as far as I can see the only people who update existing Family Tree profiles using the APIs without the change-by-change user confirmation that is clearly expected by this standard. As we know, they have also inserted many, many profiles into Family Tree, without user confirmation, where there was a high confidence match (i.e. what would become a FS-flagged duplicate) present already, which again is clearly not compliant with the standard.

(Incidentally it seems to me that the FT gedcom import mechanism does comply with this standard.)

I have asked Support to find out for us whether this standard applies to BYU’s projects, and, if not, why not?

Separate point: it's clear that none of the abuse criteria recently identified for us by a mod on

(though the relevant comments seem, disappointingly, to have been deleted) cover any of BYU RLL's activities in any way.

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.

I agree. I think concrete examples would be good. I ran across several examples in just the last week alone - merging at least 12 duplicates created by the users/projects mentioned, poor data entry for locations and names, etc. Unfortunately, I am working on an active research case and had to spend the time correcting everything in order to use FamilySearch to its best advantage - relevant record hinting on properly created profiles. If I run across anymore, I will take note so I can provide them.

Just a quick update to say this is taking a lot longer than I hoped.