Is USCensusProject a human being?
The reason I ask is because whoever they are is making two residences for every census record they attach. One for the county and one for the city. I was thinking of messaging them and askng them to stop doing that, but then it occurred to me that maybe this is a bot or something.
Answers
-
It's not a bot, but it is a BYU project. You probably won't get an answer if you message.
You'll find multiple threads on the topic, includingYou'll find links to several other threads in this one: https://community.familysearch.org/en/discussion/150416/uscensusproject
2 -
Names added by the USCensusProject, 1910CensusProject, etc., were added by automation by a group called the Record Linking Lab (RLL). Unfortunately, this group added millions of low quality names from US and other censuses to Family Tree. This was done programmatically (via the API, if that is familiar to you). The names were added as fragments (mini-trees of 3 - 10 people who are not connected to anyone else in the tree).
The RLL is the same group that uses the TreeBuildingProject username referenced above, but that username is for their data dumps based on Social Security NUMIDENT records.
I was part of a user group that did an audit of these data dumps. Census dumps averaged about 60% duplication; SS dumps close to 100%. Many, many people have complained about the damage being done by these data dumps.
For a time, the RLL tried to claim their duplication rate was low, even though evidence suggested otherwise. After the audit provided positive proof of high duplication rates, the RLL started claiming that the duplicates they added were in fact good because sometimes if you merged their duplicate profile with an existing profile, the resulting profile could have more information or tie into more relatives. (This claim is misleading, of course, because these low-quality duplicates often result in bad merges and incorrect relationships which are extremely difficult to untangle.)
Hopefully some good lessons have been learned from these damaging projects and they will not be permitted in the future.5 -
'they will not be permitted in the future'
I am unconvinced that anyone has the power to stop these projects, which have an enormous head of steam. The automated side is only one part of the picture. I got nowhere in multiple attempts to contact FS' Chief Information Officer on this subject, and FS Support can't help at all, they just tell us to speak to BYU RLL. See the thread Aine linked to for much more on this.
2 -
"Testing in the Field"
This story has no basis in fact and no similarity to any real persons or organisations.
The Chief of Product Testing and Quality Control retired while the most experienced person likely to be their replacement was on maternity leave. The company was reluctant to advertise the job for fear that it would damage the career prospects of the person on maternity leave.
During the interval, an accountant presented a plan to completely remove all product testing and quality control because: 1: It was expensive. 2: The trucks that delivered the product (consumer appliances) were returning from their deliveries empty, which was wasteful in the eyes of the accountant.
The proposed plan was to offer an asbolute no question replacement guarantee to purchasers. If any fault, no matter how minor, was a problem to the purchaser the company would collect the appliance and replace it free of charge.
The appliance would then be repaired by an outside contractor and sold through another outlet as grade B.
At first the plan worked. The returning delivery trucks were no longer empty, the financial benefit of not checking or testing was immediately apparent. The accountant presented a projected future gain that would without a doubt generate a sweet Christmas bonus.
Then the returns started escalating. For every 100 products sold, around 40% were being rejected. The short term gain was rapidly being lost.
Then the affected customers started passing around the word that the products were actually junk, "I've had 3 and they all had faults" that kind of thing.
Then the sales started to plummet. Within a short time many of the trucks leaving the depot contained only replacements for faulty appliances.
The company was forced into desperate measures. With an uncertain future and an immediate past history of failure, the stock price was so low that the repair contractor bought the entire company. They moved en-masse into the premises and put their testing and repair capabilities to work on the product line. Within a short time the appliances leaving the premises were all perfect, and with a new look and under a different brand name.
And the person on maternity leave ? - When offered an alternative position during the chaos she was "disinclined to aquiesce" and received a settlement instead.Conclusion: Testing in the field is not beneficial.
2 -
Thanks all for the education. I read some of the other conversations, but had to stop. I find it very interesting that RLL can make such a powerful gizmo. It occurs to me that the same talent could make another gizmo that cleans up the mess made by the first gizmo. Of course they wouldn't need to if there had been proper QC, but here we are. Is there any history of that kind of effort? In other words is there any hope the onus will be on the creater of the problem rather than the FS users one by one.
0 -
@Michael J. Allen As explained above and in the various threads, the creator is nonresponsive. We've had occasional replies, but most queries and complaints go unanswered. The replies tend to be boilerplate, "It's all good and wonderful."
1 -
A key BYU RLL objective appears to be to make sure, when they show the Tree to members of the general public, that they can find something relating to that person's family, the aim being to get those people interested in family history. This is clearly a totally different aim to that of most researchers and genealogists using and editing the Tree, and is apparently the reason for their addition of millions of census and Numident families to the Tree. (Simply showing the individual a relevant census or Numident Record could provide similar encouragement much more safely, but that's not what they do.)
I think BYU RLL's overall processes, procedures, and programming all require serious work, and we have raised specific concerns with them (and received an acknowledgement), but, as Aine says, we have seen zero evidence of change. I was planning to chase them up shortly (we last heard from them in late 2024), but without much hope.
Edit: the concerns we raised are summarised in this comment:
3 -
BYU RLL makes tools that can turn records into profiles with a click.
RLL's motivation is to put those tools into as many hands as possible, with a focus on people who have no prior experience with genealogy. Most recently this included sending English language, US NUMIDENT records to an African userbase.
This was all explained to us by the BYU prof who spearheads these projects. He was very proud of these click-farms and their ability to click records into profiles on a massive scale.
He was asked point blank why RLL resources couldn't be used to help us clean up the never ending mess but he wouldn't respond to that question.
More recently there was ability to change the usernames used in RLL record-clicking app. Besides USCensusProject, there are variants of CommunityCensusProject, ProfJoePrice, TreeHelper0000 [random digits] and the like. Some of the (well meaning) African userbase customized their profile to include their name and face.
0 -
Thanks everyone for the explanations and I take my hat off to those who try to insert some common sense into this situation. I'm experienced so I can deal with the clutter, but their target audience wouldn't even know it is clutter. There is likely a high percentage who don't even look at the original source image and therefore just accept what is offered.
Probably unrelated to RLLs work, but in a similar vein, one of the censuses for my county is standardized as a different county. Inexperienced users who don't look at the image and accept what is offered will think their ancestor lived somewhere they didn't. I'm guessing one little line of code is responsible because it is the same error consistently applied to every person in the entire county. I have brought it up to FS folks and mentioned it in the community as well. My impression is nothing will be done about that problem either. When humans did indexing other humans would check their work. When AI does it the result is shipped without review. When humans make an error indexing it is one here and one there. When AI does it one error is applied to thousands and thousands of people.
Neither the original topic of this thread nor the one I just mentioned would be that big of a deal if there were an effort to fix them.
Sorry, now I'm just starting to rant. Carry on with the good work.
0 -
Unfortunately I honestly don't think fixing a duff bulk automated insert automatically is ever likely to be possible except where no-one has changed any of the relevant profiles/relationships at all in the interim - there would just be too much to take into account, and too much danger of making things even worse.
0 -
I just ran across another similar case. For a person I'm looking at, user Volunteer Project has made a custom event for every census at the same time making a residence for every census. A variation on what originally prompted my initial question. Clicking on Volunteer Project shows "Change made by authorized support staff or as part of an update." I need to take a break.
0 -
Volunteer Project is a different entity from what I have read. They/it are charged solely with standardizing place names in entries in the FS tree. Per a staff member in another thread:
The Volunteer Project user pertains only to the Improve Place-Names initiative that was created by FamilySearch. The only changes that will be made by Volunteer Project are the standardizing of place-names on events where there was previously no standard.
0 -
Thanks for that. Looking deeper I see user FamilySearch added the custom events of census even though the residence for each census was already there. User Volunteer Project did indeed do the standardizing for each even though their standardizing leaves a bit to be desired. Example: Place of residence "Muck, , Washington". I realize its easy to armchair criticize what these entities do. Maybe what they do is really really hard.
0
