Is the user "TreeBuilding Project" taking the tree forward or wasting time?
Answers
-
I quote: 'The Power Linker tool helps attach 300,000 Numident records to the Family Tree each week.'
This seemingly puts up a random BYULL-generated hint - note the 'Attach All' button, which I have not tried.
Note also the complete lack of any context, guidance, or warning on the screen. (It also presents FT information on the screen without obliging you to log in to FS.)
It would appear to me that they are developing their own record hinting tools (fine) and letting random volunteers use them to update the live FT data.
BYULL created a tool to crowdsouce duplicate generation. This is astounding to me.
0 -
So, how do we challenge this? If we report it as abuse, we'll just be told that such Tree changes do not count as abuse.
0 -
Practically speaking, I don't think there's anything that can really be done about it. FT administrators seem fine with it despite these glaringly obvious problems, and no one involved at BYU seems to think there's any issues, even when they're repeatedly pointed out in multiple threads on here.
1 -
Re PowerLinker…
"… (It also presents FT information on the screen without obliging you to log in to FS.) … "
If that presents FT information without the need to log in, isn't that in breach of FamilyTree data confidentiality rules, which demand logging in? With a proper, personal login, not an algorithmically generated one in the background…?
3 -
I'd have thought so.
1 -
@JD Cowell Mine is treehelper_a343, 104 more than a239.
0 -
I believe we have options. Forgive my vagueness here but every idea I have requires the same thing. We need to work together and prepare the story of how BYULL actually changed FS.
What the work was like before the 1910p/USCP? How has it been since USCP finally withdrew? What has changed since group-based NUMINT launched? What numbers can we pry loose to help illustrate this?
I also think we need to understand how BYULL is able to keep doing what it does.
I'm going to look harder at BYULL's talking points. Maybe collecting them into one place will reveal something useful.
I have more thoughts on this but I need to move on for tonight.
1 -
Sorry. Got a Cloudflare timeout and double posts ensued.
0 -
For newbies such as me who weren't involved in the 1910 census project discussions, this I think is the thread: https://community.familysearch.org/en/discussion/comment/480794
1 -
Whoever in FS is responsible for the newish data quality strategy might perhaps be a better starting point-does anyone know who that is?
Interesting link re FS solution partner requirements:
https://www.familysearch.org/developers/docs/guides/implementation-cert
Note the various data quality requirements, and in particular the reference to a Data Quality Agreement being under development.
0 -
My mission today (unplanned) has been to clean up another treehelper mess. John Francis Brown LYCK-SDP died in 1903. I've had him and his family well-documented since Oct 2021.
Yesterday, a treehelper added a 1930 census for a man and family of similar name. Scrub, scrub, scrub.
1 -
Here's an excellent example of the problem.
https://www.familysearch.org/tree/person/details/G7LW-MLT is a High quality profile entered by an experienced contributor.
It has since acquired two obvious, flagged duplicates, one apparently the result of a Gedcom import, and the other the work of a treehelper.
Given FS can flag these duplicates without trouble, can it not reject them at profile creation time when automation is in play (and maybe provide the correct existing profile id instead)?
1 -
Re rejecting duplicate profiles at creation time. That depends on what the creation process is.
I would hope that any profile creation process warns about a duplicate. *However* in general, I reserve the right to ignore such a warning at the time. For instance, if I'm working backwards from a census family and find the marriage of one of the parents of the household, I will enter that marriage regardless of any pre-existing profiles. For instance, in England and Wales, post 1837, the marriage record gives me the (alleged) fathers of the bride and groom. My concern is to simply to enter the marriage details so I will (usually) enter the father of the bride (or groom). At that point, the system may respond (today) with a suggestion that the new father might be profile X. I invariably cancel out that suggestion because I have enough on my plate entering the marriage, without wandering off into working out who the father is. A serious task in itself.
My ability to reject such a suggestion is important - there was a time when it was much more difficult to reject such a suggestion and I would pretend that the father's name was "Dummy Smith" or whatever, to avoid the unhelpful suggestion.
From what I can see, most of these projects could be programmed to deal with potential dupes, but it probably needs to be at their end, rather than a general FSFT facility.
I support the aim, but we mustn't make the warning too wide.
1 -
Something very odd has happened to this thread, it suddenly has a lot of much older comments where newer ones should be, and more recent ones seem to pop up in random places. @Ashlee C.
1 -
@MandyShaw1 We noticed it a little while ago. All the threads have reversed order so that the newest comments are showing under the original post. We're working on figuring it out.
1 -
@Adrian Bruce1 Agreed re avoiding too broad a brush, maybe enforcing a preliminary check-for-duplicate/permission-to-create API call, the output of which could be overridden with reason statement if necessary, would work better.
1 -
@No one in particular First sorry for the late reply.
Thanks for your concern about me being a new member and being hit with hard questions. Yes, I am new to this group. I've been on FamilySearch trained to work on BYU Record Linking Lab projects in a remote setting for over 4 years. I am not connect to BYU Record Linking Lab but work on those projects. In fact I trained hundreds of other volunteers on how to "PROPERLY" attach and correct all types of records. Please note I trained them on how to PROPERLY attach or not attach and how to correct records, including clearing up duplicates that might be generated. Whether they are doing it correctly I can not promise they will do it correctly. Some volunteers are at different levels of experience. Again, we are all human and make mistakes.
Let me note that BYU RLL (Record Linking Lab) is not connected to FamilySearch, they work in conjunction with FamilySearch. These records, i.e. NUMIDENT, Census Records, and Duplicate records etc., are distributed out in several ways. If you visit the https://record-linking-lab.byu.edu/ then select Volunteer, scroll down, the records are loaded into: Random Hints, 5-A-Day Project, Goldie May, Power Linker and List of Volunteer Activities. These activities are open to the 'public' so to speak. I know that may make some people very uncomfortable that experts are not doing the work. Well they are 'volunteers'. However, the BYU RLL will pull out any records in question and then have 'human' eyes on the records to correct the errors that it detects. Again, this is not fool proof but they are aware of all the issues that haven been brought up.
No system is fool proof or 100% correct. I will repeat I am not connect to BYU RLL (Record Linking Lab), but I have been associated with them for over 4 years and I feel I understand some of their process. I'm no computer expert either.
Hopefully, this will clear up some of your questions and concerns.
3 -
At least three times in the last week "treehelpers" have attached an incorrect census record to the same profile.
One of my distant cousins, who is 98 years old but for whom I cannot find evidence of her death, has the same first and last names and middle initial as an unrelated deceased person who was born in the same state in almost the same year. The census record is for this living person and is attached to her profile (only visible to me, I know) and the rest of her family.
However, they keep attaching it to the incorrect, deceased person. No matter that the associated record hint has been marked "not a match," the family members don't match, the place is wrong, the census has been attached to the living person's profile, and that there is an alert note warning of the potential confusion. I messaged one of the "treehelpers" and got no reply, so maybe it is a computer doing the work.
3 -
Over 80% of my Family Search time is currently spent merging duplicate and orphan profiles created by the USCensusProject and NUMIDENT-projects and unwinding other BYULL-related damage. It is nearly all I am doing in Family Search now.
4 -
Cosigned. It makes me want to give up entirely on FS, actually. I wonder how the Record Linking lab would respond if they knew, given that their whole promotional materials, etc. seem to be geared towards "we're making this easy for anyone to start researching family history"?
1 -
As for what to do, I think telling an accurate story of how BYULL has changed Family Search, sharing a full record of their methods will help. In a word, sunshine.
And as near as I can tell, "they" is still just the same prof who's been driving this all along.
0 -
This is interesting:
https://docs.google.com/document/u/0/d/1sLvol63Q5TQcWEEd_PhBfaoNjiM8so0DRl5UsGz8hzw/mobilebasic
It implies that the FS Source Linker is used most of the time, and that 'tree extending' is supposed to be a special case driven by a Google Sheet and carried out by experienced researchers.
The PowerLinker by definition is looking at existing FT data.
It is difficult to see what in all this is generating all these duplicates, but it can't be the ordinary Source Linker stuff, especially as that makes you log on as an ordinary named FS user.
I wonder if the BYU-automated aspect (which looks to be limited to the PowerLinker piece) has been badly programmed and is doing unnecessary creates.
I am prepared to test this via careful experiment with the PowerLinker (tidying up any resulting mess, obvs) and collection of evidence. Could do this tomorrow (Thursday).
1 -
@KAClark2 thank you for your further detailed input.
Can you point us at the best place for impacted FS users to report RLL related issues encountered (e.g. duplicates created by a treehelper user) please? I cannot find anything relevant on the RLL website.
2 -
'The PowerLinker by definition is looking at existing FT data.' - see my earlier comment. Just wondering whether this is actually always true, but will investigate.
0 -
As an aside: I wanted to recognize+affirm that this thread is more productive and less restrained, than the last time we were here. I really appreciate everyone's contribution to that.
1 -
If anyone could provide example FT PIDs where treehelpers etc. pop up in the change log, as input to my investigation into what is actually going on, I would be v grateful.
Initial findings against the 50,000ish profiles in (my mostly US and UK) analysis database show 60 created by a treehelper according to the change logs. About 900 show updates by treehelpers.
4 -
@MandyShaw1 G7HD-1KP and his parents GZDM-WKJ and KG27-TVN have been touched by treehelpers multiple times in the last couple of months.
Also LYCK-SDP and his wife and children.
3 -
I sent generic "What can you tell me about your organization?" chats to a handful of duplicate generating accounts. After 3 repeats and 5 days, I got a response from Tree Building Project
I am a professor at BYU. I run at lab at BYU called the Record Linking Lab (rll.byu.edu). We are doing some large projects with FamilySearch right now to help people see thier family when they use FamilySearch for the first time. Joe
I thanked Professor Joe for replying and asked if he was aware of the actual impact on the researchers and volunteers. As clearly and constructively as I could, I explained the impact and restated my question again.
That was six days ago and there has been no further communication.
I will say that Professor Joe is the long time driving force behind BYULL projects.
I'll add that flaming him here will be counterproductive and we need to stay tactful.
3 -
Here's the blurb I've worked out to describe what's happening. Improvements are welcome.
BYU LinkingLabs is spearheading click-farm projects. They serve to flood Family Search with millions of low-quality orphan and duplicate profiles.
0 -
@KAClark2 I sincerely appreciate your thoughtful and through reply. You bring a helpful perspective to the discussion.
I've been on FamilySearch trained to work on BYU Record Linking Lab projects in a remote setting for over 4 years. I am not connect to BYU Record Linking Lab but work on those projects.
In fact I trained hundreds of other volunteers on how to "PROPERLY" attach and correct all types of records. Please note I trained them on how to PROPERLY attach or not attach and how to correct records, including clearing up duplicates that might be generated.
I fully accept this at face value. I am also confident you are far from unique. While validating your contributions, I want lay my experience along side of it.
Four years puts you near the beginning of the 1910p/USCP.
I have processed many hundreds of USCP-generated profiles. I found 1, possibly 2, that were attached to existing families. My experience seems to be typical.
I've processed a relatively small number of BYULL NUMIDENT project-related profiles (the sheer volume of them has ground my work to a halt). I did find 1 attached to a family.
We have careful diligence on your end. We have something very much like a catastrophe on our end.
What do you suspect is happening in-between?
3
