US1910Project
Answers
-
@Paul W I really appreciate your comments. You always do such a great job of laying it out there in such a good way. It means a great deal to me that we get some resolution around this and I am pretty involved in several things in the works for this issue. I am sorry for all the frustration and everything with this. And I do realize that the code of conduct issues would likely not be here if everyone wasn't so exasperated but we still have a responsibility to maintain a good atmosphere in the community and can't just let things go down that path. We have left the discussion open and have done some code of conduct clean up (sorry for so much editing). Don't shoot the messengers. We really are trying to get answers for you on this.
Sam
3 -
Is this a new project or a new name for the same project? From my Following list:
0 -
I just confirmed it relates to the 1911 census project that I referenced (above) yesterday. As illustrated below, maiden names are never indexed for the wife of the head of household, but at least this wasn't a duplicate! Additionally, I had to change the placename of Henry's birth - indexed as written in the record, but not as one on the Standards database.
Update - I have to admit it has taken me nearly 10 minutes to find Eliza's maiden name, COX, (from GRO birth index) and the couple's marriage (from FreeBMD).
3 -
This username is assigned to a person and not a project so as best as I can tell, it is not specifically part of the USCensusProject. I am doing a little more digging though to make sure there isn't something I don't see.
Sam 😊
1 -
I'll probably have a job finding it, but I thought I had received a response from a project leader when I raised the issue of this project a little while ago. I'll post a link if I can find it.
Update - found it quicker than anticipated! I'll leave you to read the detailed reply, but it does appear to be a bona fide project rather than the username of an individual.
See https://community.familysearch.org/en/discussion/comment/492575#Comment_492575
2 -
Yes, the names are from the same "project" just different countries.
This all started out as the US1910Project (hence the title of this thread) because they were only doing that census. As they started creating records from the other US census, they changed the US1910Project and everything US since to USCensusProject. There's a program being used at the ROC (Regional Operations Center) now the NAC (North American Operation Center) where the missionaries are trying to clean things up.
From my understanding, CommunityCensus Project is the UK version of the US ROC/NAC.
0 -
@Unabletodisplay the activities of CommunityCensus Project showing in my Following list are from the US Census - specifically 1940.
0 -
Wow, you guys are quick!! I did some digging on this because the name was obviously suspect. As you have already said (because you are so much faster than me!) there is another volunteer group working some of BYU's projects.
However, as I was typing this comment I learned more. There are 2 usernames that are very similar. CommunityCensusProject (with no spaces) is connected to a person and not a group project. We are going to ask them if they would be willing to change their username.
The other, CommunityCensus Project (with one space) is connected to the BYU projects. I do know this group and they are usually more careful and spend more time doing these so I hope that is still true. They had similar concerns as all of you and is actually why they stayed involved. They wanted to help with the quality of this project. Are you seeing the same issues as the USCensusProject? It looked like the one you posted @Paul W was but I couldn't quite tell. If so, please let me know. I have a little bit of influence with this group.
Have I mentioned how awesome you guys are! I love how you jump in to fix, understand, or troubleshoot!
Sam 😋
1 -
And now the 1880 US Census. Good grief!
I have spent three hours today merging multiple records for the family of August PRIEBE and his wife, Bertha (née Fehlhaber) because of multiple entries from individual researchers and birth and marriage extraction records. Plus I've sorted out this family from a couple by the same name who were in Cleveland, OH before locating to Minnesota.
And now I find that this family was duplicated A MONTH AGO using data from the 1880 US Census:
August Prode 1838 Deceased • GV29-4ZK * February 25, 2023 USCensusProject
(the project also added records for Bertha, Emma, Anna, Emilie, August)
After all the examples you've been given on this thread (and no doubt through other channels) about how census data is not reliable--and the indexes for those census records even less so--you are letting this continue USING THE 1880 U.S. CENSUS!
This project idea sped past its limited degree of usefulness when records from the 1910 US Census were added. Now it's a hindrance to research and a drain on resources.
And for me, this has moved well past frustration and is squarely in the element of trust. Why isn't it obvious to you that when you add records to FamilyTree you are PUBLISHING them. You are giving legitimacy to surnames and family relationships. Stop and consider what it means when you get that wrong. Not just for FS as a business, but for individuals and families--I'm talking about real people, the living ones, who are not just names on a census; the people who are piecing together their family history and all the good, bad and ugly that goes with that. How can anyone trust FamilySearch or information in its database when you actively encourage the publication of garbage data with zero research?
1 -
My main problem with these projects is (as stated by others in this thread) that census records do not provide a good source of detail from which individuals / families can be added to Family Tree.
Censuses are notorious for containing false information - ages and birthplaces often being shown completely differently from one census to another. Nicknames or middle names are frequently used for children, making their identity difficult to confirm when cross-checking against birth / baptism records. And, of course, one major problem is that nearly all wives will be recorded in their husband's name - and even the male, head of household's stepchildren are often found in his name (whether or not they actually did adopt his surname in everyday life).
So, the screenshot I posted is a typical illustration of the (approved) "CommunityCensus Project". Unlike with most indexing projects, where everything should be copied as it appears in the original document / transcript, it appears volunteers to these census based projects are encouraged to replace the names for married females with their maiden names. However, in practice, I have found there has been no apparent effort to do so.
Another main problem lies in the recording of placenames. Again, such projects present a problem in recording, say, a place of birth. It is inevitable that a great number of these will end up being non-standardized, as the enumerator - or, in the case of the 1911 E&W census, even the household head (who was responsible for completing the original form) - will have got the spelling wrong. Presumably, volunteers are told to index placenames "as recorded", which does mean extra work for the FT user in having to standardize, however. (Even where the spelling of the location is correct, the volunteers are not standardizing it properly.)
Hence the argument of many of us in saying census material should not be used to add names directly to Family Tree. To be honest, I find it difficult to suggest how any improvements can be made, assuming these projects do continue - apart from making them "stand alone" efforts (i.e., totally apart from any connection to the Family Tree database).
I admit I have not found the duplicates problem so bad with the 1911 E&W project as appears to be the case with the US 1910 one, but still believe increased supervision, along with improved project instructions, might be of great help in reducing the problems (with duplicates and otherwise) many of us are encountering on a regular basis.
5 -
I surfed in here today because I saw USCensusProject create relationships that don't even match the underlying records.
This is the original: https://www.familysearch.org/ark:/61903/1:1:MZ71-LDM
Note there are 2 families at this address.
Now look what happened in the tree. https://www.familysearch.org/tree/person/details/GJQ1-F96
USCensusProject created a marriage between the Head of household and his sister-in-law. I don't know if this would be obvious to a runaway tree editing bot, but from a human perspective it is moronic.
3 -
A lot of my work this week has been merging duplicates, triplicates, and quadruplicates created by the Project. In several cases, the household was a blended family. The children of the 1st marriage were named correctly (not always the case), but the Project had made them children of the 2nd husband even so. And the Project is not even bothering to come close to proper placename usage. These families were in the United States, but the Project had entered only the state, with no city or country. You have to WORK to remove those vital details.
3 -
PLEASE STOP!!
I can't help but scream! Now you've been adding the 1880 US census to the mix! As you can see, I'm working on just one of the 5 duplicate records for this person!! None of which I have created and one of them is from his family listed on the 1880 CENSUS! Three of the others, list FamilySearch as being the creator of these records because they were created before the change over to New Family Search and least two of the records do not include a single source. There are so many duplicate parents, just from this one person. I was approaching this research from his first marriage (a created FamilySearch record) and as I added more information, the duplicate count kept increasing. The 1880 US Census created family was not necessary! Please, please, please stop putting these duplicates in!
0 -
To save me time (and possibly any FamilySearch reps monitoring this discussion) would you kindly provide the ID of the profile created by the project. I've taken a quick look and can't identify the ID whose creation you are complaining about.
2 -
9VKR-P4W was not created by the Community Census Project. The 1880 census source was attached to an existing ID apparently created from an indexed birth record.j
1 -
If you take a look at the creation of the siblings in the record of Fredrich Wilhelm Sommer 21 February 1871 – Deceased • 9VKR-P4W, you will see that they were all created during the attachment of the 1880 US census. Otto already has 2 existing duplicates in Family Search that have been located. The other siblings have not been researched yet. The original records have not been modified. Otto's 2 duplicates do not have any sources. Why create more duplicates instead of cleaning up the database? Most novice users are intimidated by having to deal with merging duplicates. As FS warns, it's a serious and difficult issue.
Otto Sommer 23 April 1875 – Deceased • KKMZ-GHF
Otto S... 23 April 1875 – Deceased • KKQP-GF4
1 -
I'm wondering (but far from certain) if this thread might be most productive if it focused on the USCP - because they are the 800lb gorilla of Duplicate-Generation Projects.
My thinking is that if USCP can be persuaded to stop endlessly creating (and walking away from) these messes, whatever worked might guide us on how to approach the copycat DGPs.
2 -
WHY? Why on earth is the Census Project now changing a Place of Death and getting it wrong in the process?
What does that have to do with a Census? That location is taken from the memorial on Findagrave. It is the place of burial, which was already documented. The death index only shows Queens; there is no reference to Flushing.
2 -
I listened to a presentation by Joe Price a couple of months ago in which he mentioned that the volunteers with the census project were also going to be adding additional vital information and sources to records in FamilyTree (presumably to records the project had created?).
A common error I find with place of death information is that researchers take that from the Social Security Death Index. However, the SSDI actually records the last benefit address.
2 -
You can see that the formatting used in that erroneous death location is that of a Findagrave memorial. And, in fact, I created that Findagrave memorial. If I had information that her death occurred in Flushing, it would have already been present on the profile.
They've got lots of work they could be doing to fix the messes they have already made.
1 -
And NOW the Census Project is changing correctly formatted dates to incorrect format.
This is absurd and has crossed the line into abuse.
I'm still waiting to learn what benefits are derived from the "work" of the CensusProject.
0 -
@Áine Ní Donnghaile Good grief. I hadn't run into any newly minted USCP duplicates and had gotten my hopes up. Of interest, I was mid conversation with JP when his email provider started responding that his account is a non-existent address (which indicates he didn't just blacklist my address).
It could be super helpful if US CP apologists would take a moment to stop by and list the good that outweighs USCP's work on FS. Because, so far, that work seems indistinguishable from poisoning and vandalism.
1 -
@Áine Ní Donnghaile Perhaps noteworthy:
I noticed that new posts to this thread do not trigger it appearing on the Recent Discussions page. Huh.
I also noticed this thread has been deindexed from Google. Huh.
This thread is still indexed by Bing tho. Ruh Roh!
1 -
The USCensusProject-adjacent groups operate under an umbrella called BYU Record Linking Lab. If you want to learn of their many other plans for Family Search, you can visit their Facebook group page.
0 -
Please, I am begging, the work is getting worse, duplicates created I can handle, easy enough to merge. But what I have been seeing this past month (I am a full time researcher on here 8+ hours a day) is MUCH worse. They are attaching census records to the wrong families. They are attaching records to families that already have existing census attached thus adding children to the wrong families and then changing vitals for the parents (ignoring the many records already attached) to fit the ONE record they attached.
Some of the users are going a step beyond and merging multiple families.
I have been working on my personal McLaughlin surname project for the past 3 years. My maiden name is McLaughlin and I have over 30 years of research experience. I started 3 years ago by putting all the McLaughlin families I found in the 1900 US census into the correct family units. Merging with the 1910 census when I could. Then I focused my project on Philadelphia and began attaching WWI, marriage records, birth records, burial records, etc. I always cross reference my work, even using sources beyond what is available on this site when needed.
Because of this I run against these McLaughlin families many times and have become familiar with what children belong with what parents. I am now DAILY finding my work corrupted by the project. I am having to unmerge, restore, unattach and reattach records. The mistakes they make are obvious and illogical.
For example the last one I found the user attached a 1910 census in Philadelphia where the parents were both born in Virgina to a Fayette County family that already had a census attached (which added a child not theirs). They then changed the father from born in England 1870 (he had several records attached proving this) to born in Virginia Dec 1872. And the mother from born in PA to born in VA.
I personally would rather they create duplicates then make uneducated, unresearched GUESSES as to which family the record belongs to.
I realize this in not a FamilySearch project, but, surely you can contact the person handling the project.
I am unsure if this is part of the same project, but, I am also finding many children that died inbetween census dates being added to the wrong families, they see the father's name and mother's first name and just guess. This is not research. They should be looking at the address ont he death record and researching other sources to find the correct families. If they are unwilling to put in the time to research, then leave it alone and let people that actually research do the work.
In addition, I messaged 1 user about similar types of errors. He told me he was part of a mission based in Africa doing a LDS sanctioned project. I have seen many volunteers of this project also making horrible errors.
I don't have as much of a problem with duplicates as many of the others, and I also am very experienced, over 3 decades. Reason: I would prefer a duplicate to a guess and wrong records attached to families which can add children to the correct parents.
I myself sometimes have to create a family from one source when I can not first find the existing family. (Not via Batch/Gedcom, entering manually.) However, when I do this I then search for other records until I can link the person (or family) into an existing tree thus linking them to the world tree.
But, sometimes the sources are too vague and it has to be left until more data can be found to prove a relationship.
The alternative I am seeing is GUESSING. Records being attached to families soley on the husband's name and the first name of the wife. Ignoring location, existing sources attached to the family, dates, vitals, etc. Some of these users "hijack" other peoples family trees, changing maiden names, vitals, etc. to make it fit their ONE record. Then they merge both families (I have seen as many as six familes merged into 1 huge family with birthdates all over US and other countries,)
I personally will take the extra time merging VS the numerous hours and sometimes days it takes to fix resorting the families and figuring out which children belong to which set of parents and restoring deleted person, detaching sources then reattaching to the correct people.
2 -
Thank you for bringing up this topic. I am seeing many of the same issues on FamilyTree, and I, too, have been spending hours correcting other people's mistakes.
0 -
The process continues:
Duplicate family created by USCensusProject (1880) - on February 22, 2023
Lina Lehnard Female 1856 – Deceased • GVV8-WND
Existing FS family
Philippine Heinz Female 1856 – Deceased • GCFD-529
(created by USCensusProject (1910) on April 3, 2021)
0 -
I was at a meeting in August 2023 and asked an employee from FamilySearch about the Census projects, 1910 and others. He told me the projects were continuing BUT in a different way and that NO MORE changes will be made to the FamilySearch Tree. I'm sure we will continue to see changes made before that time but hopefully something like this won't be repeated.
0 -
@PBS Well, it seems that whatever the employee told you was incorrect, because I've just run across a set of people generated from the 1920 census by user "TreeBuilding Project" on May 15, 2024. (GRD4-LZR for the head of household in this particular case). That person is, of course, a duplicate of multiple people that have already been created, including one already produced by the USCensusProject for 1910.
0 -
@joemartel (who appears to not be taggable) wondered upthread how we are finding all of these duplicates. Well, sometimes you just stumble upon them in the natural course of research. Sometimes, Ancestry has figured out that census records are the same household, but FamilySearch doesn't recognize that (I realize this is a big oversimplification because Ancestry's related records have a lot going on under the hood). And occasionally, the census records are showing up as record hints in the research help section.
But—and this is critical—from what I've been able to tell, hinting on FS happens a lot less often when a record is already attached to a person. Presumably, this is to discourage people from detaching records when they're already attached to a person. (A similar interface pattern can be seen on the record page: under "similar records", records that are not already attached to people are at the top of the list.) But creating artificial people and attaching census records to them interferes with this design and overall makes research harder. I hope that the administrators of these census projects will take a hard look at any unforeseen effects the projects are causing.
2
