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

MandyShaw1

Fyi some insight into BYU's hints mechanism:

https://www.facebook.com/100057487747623/posts/pfbid02MmkyMEREopYhWq6T6URasiGka7k1YopABskXJvDn4CchsLpEWFtYpJBiSfC7CdKXl/?app=fbl

CherylMillerBlack

I signed up to work on the 5ADay project. (I'm currently getting 1940 census records.) I admit that I don't always get my 5 sources a day because I need to clean up duplicates and a few outright errors. However, most of the attached census records I have found have been done well, with the exception of putting women's married names (which causes duplicates).

I feel like this is a service I can do, and it does build the World Tree.

My suggestions for 5ADay and other projects is training, as KAClark2 mentioned. Just a few pointers—like not putting the wife's surname and checking the original image to find relationships—could go a long way in preventing further errors. I think everyone doing this wants to help; maybe they just need better tools.

MandyShaw1

Thanks @CherylMillerBlack, it's very useful to hear an experienced researcher's angle on this.

I'm not sure how familiar you are with this discussion (this thread has got very long, and there was a similar one before it).

The points we raised with BYU RLL late in 2024 were largely related to the impact of their automation projects and of the high-volume activities of their student volunteers ('treehelpers'), plus some concerns about the tools provided to other inexperienced users (point c) below).

Here is an edited summary of the issues we submitted to BYU RLL:

a) Communication

We were concerned about the lack of communication channels between BYU RLL and the rest of the FT user base: to publicise the aims and workings of BYU RLL projects to the wider user base (LDS and non-LDS), to set expectations, and to report and resolve issues that may arise (whether profile-level or wider concerns).

b) Accountability

BYU RLL projects don’t in our view demonstrate the expected collaborative approach to editing the Family Tree, in that BYU RLL automated and 'treehelper' users need to respond meaningfully and in a timely manner to messages from other FT users; also, appropriate reason statements need to be put on all changes made by BYU RLL (we have seen very few genuinely clarifying reason statements on automated or 'treehelper' interventions, and the vast majority have no reason statement at all).

c) Failure to take current FT information into account

Inexperienced users of the Power Linker, Source Linker via BYU RLL hint emails, etc., don’t necessarily understand the impact a resulting change would have on the FT before they make or approve it. Just because a match looks great in the Power Linker (or indeed the Source Linker) does not mean that there is no contra-indication somewhere else in the FT profile's data, in its Research Helps (or Data Quality Score guidance), or in an alert. Starting from a BYU RLL-chosen candidate match will always mean that the user has had no chance to judge whether this is the best match available to existing FT data.

d) Timing problems and best practice

We understand from FS Support that it requires multiple interventions to implement some BYU RLL automated or 'treehelper' changes, often with considerable delay (months or years) between the steps. These situations may leave a profile in a state that does not reflect genealogy best practice, potentially for a long time (one widespread example being the creation of profiles using women's married surnames). Such pending work is in no way communicated to other FT users, resulting in confusion and time-wasting (while FT reason statements and notes/Alerts are available to help with this, they are not used). Additionally, changes that may have been made by others in between BYU RLL visits are frequently not taken into account by BYU RLL’s automated/'treehelper' activities.

(Plus some concerns re the handling of duplicates by BYU RLL profile creation, and some thoughts on how the FamilySearch APIs might be tweaked to lessen the impact of BYU automation activities.)

I am currently working on a follow-up email to BYU RLL to see how they are getting on with all these points (I will post it here once ready).

CherylMillerBlack

Thank you so much @MandyShaw1 for taking the time to spell this out for me. These are all really valid concerns. I did go to the Facebook page that you linked above, and BYU RLL is offering "quizzes" to help volunteers improve their skills. It's a good step, I think, but I commented that I couldn't take the quiz because there was no way to look at the Person Page(s) or the original image before deciding if the example was an appropriate source.

So, there is a long way to go. (And that only addresses issue #c!)

I look forward to hearing what the response is from BYU RLL, and would be glad to help with emails or other communications to them.

I doubt these projects are going to stop (and the intent is good), so we need to get/help them to solve the problems.

Áine Ní Donnghaile

@CherylMillerBlack Given the lack of response from BYU RLL, after MANY attempts by Mandy and others, I don't hold out much hope of a valid (or any) reply or behavior modification.

MandyShaw1

They did at one point ask for and receive my advice (which may or may not have been any use to them) on how I would handle the very many duplicate '3-packs' their automated Numident project has created. I have since identified an additional API which may help, this is one of the things I'm going to write to them about. But, more generally, in my opinion their automation and 'treehelper' processes are likely to need serious end to end work (and not just on the programming front).

Also, their intent may be good, but their overall objectives are very different from those of the experienced researchers whose work they are impacting.

melanes

I am starting to put as a reason statement or merge explanation as, "Duplicate created by BYU RLL" or some such explanation. FamilySearch does look at those statements, so it may help highlight the problem. I just had to merge a duplicate family because a treehelper didn't look at the images, they relied entirely on the index, which was incorrect.

JD Cowell

@melanes I've been putting in "___ project duplicate", as appropriate, in my merge reasons for a while now, but I think blaming BYU explicitly might at least catch someone's attention. Hopefully eventually. Maybe after the first literal million. Who knows!

Amy Archibald

I also put in something like "Duplicate created by USCensusProject" or whatever the BYU project is that created the duplicate.