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

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.

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.

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'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!

@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.

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

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.

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

I think your letter looks great, Mandy.

I agree, @melanes, I think we need another line of attack. The DQS team, another go at Support (who can't wash their hands of this for ever), or perhaps the Data Protection team if there are any living people marked deceased amongst the mess (I'll look into that).

@URWelcome If only we knew. No-one in FS appears to have any power at all over BYU RLL, and while the latter pay occasional lip service to our complaints they don't actually seem to understand the seriousness of the situation at all (or, given the head of steam their activities have somehow acquired, they are burying their collective heads in the sand).

One of the many problems is imo that they appear to be running a major IT project with a big impact on an enormous production database with no proper project controls and with an inexperienced student workforce whose stated objective appears to be, simply, to get as many of the worldwide deceased population into FT as they can, ignoring all other concerns and, as far as I can see, with negligible checks and balances.

Thanks for the pointer re the 1930 census, I'll do some poking around.

I think the treehelper* usernames get picked up over time by assorted different volunteers working their way through a queue of those interventions that they haven't yet (perhaps fortunately) found a way to automate.

Quick note concerning Data Protection. I have looked into this. BYU RLL appear to have a script which sets those of its created profiles that have no death date to Deceased. In all the cases I have looked at, this appears to have fairly solid, if undocumented, facts behind it, e.g. the person had a child in the 1930s or earlier. Ideally we'd have more clarity about the date criteria behind BYU RLL's selection of candidate profiles for creation, but I think this aspect is pretty much OK.

Also - I have just sent Joe Price (BYU RLL boss) an email containing both my proposed text and @CherylMillerBlack's points (both above dated 19 June).

Well, I wrote to Support again, with frustrating results. Here's the conversation. I'll keep you posted.

Me, 25 July:

In relation to request 992152, I am afraid I need your help again.

You may find the following useful as a summary of the situation.

The BYU Record Linking Lab continues to introduce vast numbers of data quality issues to Family Tree and to waste the time of FamilySearch’s experienced users. In particular:

1.There has been no communication whatever from BYU RLL to inform the rest of the FT user base of their current projects or plans.

2.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.

3.Existing properly verified FT information is still not being taken into account properly, either by BYU RLL’s automated and semi-automated scripts or by their user tools.

4.Community members 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.

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

I did succeed in obtaining an initial response from BYU RLL, and several emails were exchanged initially, but there has been no progress on any of the above points.

(You also suggested I used the Suggest an Idea option on Community, which I did last September, but with zero response or feedback.)

More detail about the discussions to date will be found here if required: [link to this Community thread]

Please find a way to put me in touch with someone in FS who has the ability to get this resolved.

Them, yesterday:

We understand your frustration with records that are added with incorrect information that create issues for others to resolve.

There are numerous “projects” that work in FamilySearch from around the world. Each entry is made by an individual working within their project guidelines. Their guidelines are set by someone at the head of their project that may involve one person or many people who are working on various records. FamilySearch is not involved with determining their guidelines.

Account holders who enter information are not required or requested to communicate with others who also use FamilySearch/Family Tree.

Reason statements are created by the person making the changes and are known to be unhelpful at times. FamilySearch does not police reason statements or other information added by individuals.

Adding incorrect information is not considered as “abuse” by FamilySearch administration. Even though it is very valuable and helpful, “Genealogy best practices” is not a requirement for entering information into FamilySearch/Family Tree.

Unfortunately, the many duplicates that are found in FamilySearch/Family Tree are created by a variety of those who use Family Tree and FamilySearch provides helps to manage duplicates but does not have a method to prevent them from being created.

If you assess that someone is abusing FamilySearch/Family Tree, please click [report abuse link] for Reporting abuse in FamilySearch/Family Tree.

You can also click [Suggest an Idea form link] to let the engineers and developers know your feelings and suggestions about this issue. Many of the changes in FamilySearch have been made because of suggestions using this feature.

Me, just now:

Unfortunately you are missing our point here.

BYU Record Linking Lab’s projects do not work with the Family Tree as ordinary users do, they run automated scripts creating or changing many, many profiles at a time (millions, in some cases). This is a matter of scale and accountability.

Re ’each entry is made by an individual working within their project guidelines’. The entries in question are not made by accountable individuals, they are made by automated scripts, apparently prepared and run by student volunteers, and if there are any project guidelines they are not published and do not take existing data into account. I do understand that FS is not responsible in any way for such guidelines, but if someone is going to run high-volume automated bulk updates then surely FS has to have a way of protecting its precious data assets and their users.

I know the bar is very high for an individual user adding incorrect information to be considered abuse, but again this is a matter of scale. FS has applied considerable resources to its excellent Data Quality initiative over the last couple of years, does it really want the results compromised by high-volume automated scripts?

FS does have APIs to help in avoiding duplicates, e.g. the Person Matches by Example API. Obviously such anti-duplicate measures are not going to succeed every time, but I have provided RLL with examples showing how they can help. The real problem is, as above, that RLL appear not to take the existing FT data into account at all.

Concerning best practice, I get that individual users are not policed at that level, but this is a matter of bulk automated updates silently leaving very large numbers of profiles in a ‘halfway house’ state, realistically permanently.

As stated in my last email, I have already tried Suggest an Idea with zero result or even feedback, I see no point whatever in trying that again, especially as we are not asking for improved functionality.

Please advise what you think we should do next to get this issue mitigated. I am happy to provide evidence, to submit an abuse report, or to contact the Data Quality team, just let me know what will work best (I prefer to avoid a scattergun approach, and I am sure you do too).

While FamilySearch and BYU are under the same parent organization, you would be surprised at the lack of communication and cooperation that exists between departments and entities (speaking as someone that has worked with a church department in a professional capacity).

Speaking of BYU, it may be worth appealing to higher ups at BYU about RLL and the impacts it is having. They probably are only hearing about the supposed positive impacts and have no idea of the damage to the data quality that is happening. I'm not sure who that would be though.