Is the user "TreeBuilding Project" taking the tree forward or wasting time?
Answers
-
Fyi some insight into BYU's hints mechanism:
0 -
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.
1 -
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).
0 -
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.
1 -
@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.
2 -
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.
1 -
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.
2 -
I also put in something like "Duplicate created by USCensusProject" or whatever the BYU project is that created the duplicate.
0 -
@TRodriguezTatro you aren't addressing the BYU RLL team when you post here (they very rarely visit), we are all ordinary FamilySearch users with similar concerns to yours.
To be fair, however, BYU RLL's aims (while quite different from those of most family history researchers using FS Family Tree) do not appear to have anything to do with for-pay search engines.
0 -
Thanks for the info. I removed my comment and will now press forward with removing my information and deleting my account from this forum. I disagree that these folks don't provide research to Ancestry, MyHeritage and other companies that have a fee for searching and finding records that I know I found on this site first before the info appeared on the pay sites...
0 -
BTW: This organization, Tree Building Project, is not only wasting time but also causing much anxiety and aggravation with users who have been (successfully) utilizing this site since it was created only to have to now take time away from OUR RESEARCH to clean up their duplicates and errors.
Thanks again,
TRodriguez-Tatro
0 -
I agree, as would, I think, every one of the large number of FS users who have posted in this thread. Sadly there appears, despite our best efforts, to be very little we can do about it.
btw TreeBuilding Project is just a user name used for automation purposes by the Record Linking Lab (RLL) team at BYU.
1 -
Here is an email I have just sent to @Joe Price 4 at BYU RLL, requesting a progress update, and also making some modifications to the information submitted previously (mostly about the APIs): see BYU RLL response v2.pdf.
1 -
Well, I have had no response from Joe as yet. I propose to leave it 2 weeks and then try FS Support again, on the basis that we have bent over backwards to liaise with BYU on this, as Support recommended, and have, realistically, got nowhere. Does anyone have a better idea?
Given the improved and successful focus on FT Data Quality over the last couple of years, I am finding it difficult to understand why this is not being attacked internally in FS (or maybe it is).
Meanwhile, for information, I have applied for formally supported access to the APIs, explaining that it would help a lot with collecting evidence for situations like this BYU RLL issue, but this has been firmly declined because I'm not writing a 3rd party solution, despite my only wanting read access.
2
