US1910Project
Answers
-
Why is the project adding from the 1900 census?
Because the project has changed its name and focus, no longer limiting the duplicates to the 1910 census, but to many other US censuses and from censuses in other countries.
1 -
The user can change their contact name that is seen by other users at anytime. As mentioned above the BYU RLL effort covers many different historical record collections, mostly Censuses from USA and elsewhere. You can participate/follow their announcements on their Facebook page.
0 -
Like many other FamilySearch users I don't use Facebook!
Some time ago I believe "Professor Joe" agreed to engage with Community, but that has not been forthcoming. I know (as you have said in the past) FamilySearch (or, in this case, BYU) employees should not be expected / feel obliged to communicate with users through FS forums, but the lack of direct responses from the organisers of these projects is certainly not helping in our understanding of the apparent positive aspects of them, or explain why they are going horribly wrong.
The mass duplication of IDs and inputting of women's names with married names should not be tolerated by FamilySearch management. It beggars belief that there is actually an expansion of this work - which is now having a direct affect on me, via poor work relating to the 1911 England & Wales census.
2 -
@Paul W I don't post to FB but I use it see what's going on and they have efforts posted there often. The 1911 England&Wales was done a few months ago so hopefully that's the limit. The 1920 US Census is their recent project and that will probably be running for months. Tracking dups and time to fix is helpful. thanks.
0 -
DUPLICATES added by US Census Project (using the 1910 US Census)
Heman CISS - GCDX-JYF. Duplicate of Herman ZISS (L24K-DTW) and four children.
Louise CISS - GCDX-LQS
Anne CISS - GCDX-JYL
Mary CISS - GCDX-QDB
William CISS - GCDX-X7B
It would've taken very little research to find the correct spelling of their surname when the volunteer added it (boolean search). Records for this family have been in the FamilyTree database for years.
2 -
Duplicate added by Community Census Project--Dec 2022
M9LW-LZ8 Charles Kuntz
Same as M9LW-LZ8 (birth extraction record added more than 25 years ago by another family history project)
1 -
US CENSUS PROJECT DUPLICATEs added using the 1910 US Census that has the "Olm" family misspelled as "Alm".
There were already multiple records in the FS database because of birth extraction records for the children of Carl and Henrietta Olm. Carl died in 1906. Another researcher had added (duplicate) records for their daughter Helen and her parents in 2017.
US Census Project duplicates:
Hennrieta ALM. Duplicate PID GC8K-RB9. (current PID LRXR-STJ "Henrietta Osten")
Lena ALM. Duplicate PID GC8K-GSZ. (current PID 2WM8-C8J "Helen Elizabeth Olm")
I added a record for the son Alfred Olm then merged it with the one created by the US Census Project. I did this for multiple reasons, but mostly to see if Family Tree would ever link up what the project had entered with the family. No, it didn't happen. No one in this family showed up as a possible duplicate with the 1910 data.
I'm going for bonus points today. I set a timer to see how quickly I could add census records to the family. My results: under 29 seconds for four people (1900 US Census for this family).
And then I timed how long it took to merge the 1910 entries. My result: 5 minutes. And I'm experienced user!
Names, dates, relationship, residences all have to be looked at. Place names have to be standardized first if they're going to be brought over (yes, I'm charging that time to the Project). I know from past experience that it takes an hour for me to show a new or less experienced researcher how to do this and have them complete it successfully.
Even amazing researchers call me and ask me to walk them through merges on FT! Thanks to the US Census Project, i am really, really experienced at doing merges now (that's not a compliment).
0 -
DUPLICATES added by US Census Project (using the 1900 US Census)
William Giese. Duplicate ID GFLP-BSK
Tracy Giese. Duplicate ID GFL5-QQV. [Bad data on census, the record is for Theresa Giese (née Arndt)]
Herman Giese. Duplicate ID GFLP-GM8.
PLEASE--I'm begging you! Stop using the 1900 US Census to add more duplicates!
1 -
DUPLICATES added by US Census Project (using the 1910 US Census)
The inaccurate data added as the family of August GRIEVE (GC8V-GWP), Emma GRIEVE (GC8V-MF5), and their children William GRIEVE (GC8V-8M2) and Mathilde (GC8V-MF5) are especially troubling.
The surname for this family is wrong on the 1910 US Census. Not just misspelled, but w-r-o-n-g. This is the family of August PRIEBE and his wife, Emma GEISSLER. Records for that couple were added to FT in 2018 (PIDS August L16Y-SSW, Emma L16T-Y23, William L16T-55N)
The surname "Grieve" is somewhat common in the Cleveland, Ohio area, and there are other men who really are named "August Grieve" with similar vitals.
2 -
Thank you a.t.n, and other users. I'm curious as to how you are finding all these errors? I can track duplicates from a Possible Duplicates approach, but many of the duplicates/error you and other users are finding are beyond the capabilites of an algorithmic check. I know it takes research, but understanding how you are locating/discovering these bad entries could be helpful to convince and find a better approach. thanks
1 -
This week I'm finding them in greater frequency. As I'm working on a family, I'm getting a FamilySearch record hint for a census. When I go to attach it, it has just been recently attached to new individuals created by the US Census Project. Recent as in the last 45-60 days. So, I've just been merging and in the merge reasoning putting "Duplicate created by US Census Project". I've noticed that in each instance that I've encountered this past week, FamilySearch is not hinting that the person is a duplicate. I am just getting the record hint and then finding the duplicated people attached to the census.
So, FamilySearch is hinting correctly on the record for the people in the Tree. But that record is attached also to newly created persons via the US Census Project.
I'll try to remember to build a list of PIDs to share with you going forward.
7 -
To answer your question about how I'm finding the entries on FS with bad data contributed via census records, it's because I'm researching connections in Cleveland, Ohio. Many of my husband's relatives are buried at Lutheran Cemetery in Cleveland. As I go through indexed records for that cemetery I treat every entry as a potential relative.
Although it is coincidental that the sections/families I've been researching recently are highlighting the problems with census data, it is not unexpected that this is the case.
It contradicts genealogical standards to take census data at face value and put family trees into a production system without additional verification or sources. The bad data I've highlighted should prove that. I'm just one person, and I'm finding a problem with what the Census Project is doing every day.
You need another data point for accurate genealogy. If you keep doing things the way you've been doing them, the clean-up will be monumental. And the reputation of FamilyTree may not recover.
What I tell every new researcher I work with is to create a tree at Ancestry first and let that application's metrics pull up vital records and other family trees. Then compare your own research with those sources. Once you've done that and resolved the inconsistent data, you can be confident adding the person/family to FamilyTree.
2 -
@Amy Archibald next time you (or any user) gets a hint and find that record already attached by USCensus please let me know before you work it.
@a.t.n. Where are these Cemetery record indexes? a URL would help me understand your work practice that leads to hitting these dups.
Thanks
1 -
Using the 1910 US Census the Project "made up" another family in March 2021:
George KLAAK - GC8R-Z6G (head of household)
Millie KLAAK - GC8R-Z65 (wife)
George KLAAK - GC8R-25J (son)
The family surname is CLEGG. You used bad data from the 1910 US to create this family. The couple had already been added to FamilyTree in 2020 (maybe even before then because I haven't finished researching them).
Also, George Clegg Sr. was born in Ohio, USA, not England.
I wrote in a previous post that the Project is making a huge error by assuming the census data is accurate. I am pointing out again that you are creating significant problems with this approach.
Other duplicates I found recently:
John Halter - GCDN-SPC
Anna Halter - GCDN-7FW
Arthur Halter - GCDN-FP2
Elma (sic) Halter - GCDN-86S
Edmund Halter - GCDN-298
4 -
Apart from the straightforward issue of creating so many duplicates, the examples provided above show another good example of the dangers of projects based a census. The identity of the individual needs to be established first - not based on information from a census, which is commonly found to be incorrect, once further research is undertaken.
In the case of my ancestors, two are recorded as being 36 years old in census records ten years apart. Several are shown with a variety of birthplaces in different census records. One is even shown with his father's surname one year, his mother's surname ten years later, and reverts to the father's name ten years after that. As for ages, these rarley are an exact match when comparing one set of records with another.
So, if in England, (say) the 1871 and 1881 census returns were be the subject of separate projects, many effectively fictitious individuals would be created - as how would a volunteer know that "Thomas Smith" was the same person as "Thomas Brown", or that it was the same individual shown to be born in 1835 in one set, but 1845 in another, or that they were apparently born in Leicestershire according to the 1871 census, but in Warwickshire according to the 1881 collection?
With so much inconsistent information, it is sometimes really difficult to find / confirm you are adding the correct census sources to your relatives. To create individuals from census records, and accurately identify them, must often be a totally impossible task for a volunteer project member.
If FamilySearch or BYU want to create a "side-project", fine. But I believe continuing in adding these details directly to Family Tree has been shown to cause damage, which just does not match any positive benefits.
6 -
Another day and I've found another made up family surname added by the US Census Project
BOLIERICK--The correct surname is ZUCHLINSKI, and yes, they are duplicates; there are already records in FT for the couple and some of their eleven children.
Does anyone on the RLL even bother to LOOK AT THE CENSUS IMAGES? The surname on the 1900 US Census used to create these records is ILLEGIBLE. Are these indexes coming from Ancestry? Somebody just "guessed" at the name, and the RLL volunteer just went with that.
GFG9-K54 John (didn't even bother to give him a surname because the census record is illegible)
GFG9-VL2 Rozalya Bolierick
And seven children (Mary Bolierick, Leon Bolierick, etc.)
PLEASE, PLEASE, PLEASE STOP DOING THIS!
5 -
Hi guys. I promise you that we are aware of your frustration. We are actively working to find a solution. You may not know, but spamming the community with comments in multiple places is a violation of the Code of Conduct. Please, let's be kind and understanding in our conversations here in the community.
2 -
Joe, I thought I'd send you this egregious example of Joe Price's efforts to build the tree. It takes so much time for us users to clean up. If they can't stop creating these records, couldn't they at least provide a method for us to let FS know to delete these large quantities of duplicates? How about a button on the USCensusProject generated "families" that will request FS to delete these?
family created April 23, 2021 by 1910 USCensusProject
James F Ferguson 1856 – Deceased • GZST-6XK (father)
Leanner I Ferguson 1858 – Deceased • GZST-DBR (mother)
Hattie Ferguson 1890 – Deceased • GZST-FKQ (daughter)
Edward Ferguson 1892 – Deceased • GZST-FK6
Minnie Ferguson 1897 – Deceased • GZST-ZFM (daughter)
Mckinley Ferguson 1898 – Deceased • GZST-XKG
May Ferguson 1900 – Deceased • GZST-F2Q (daughter)
family created September 2, 2022 by 1900 USCensusProject
Frank Herguson October 1855 – Deceased • GFLZ-YHK (father)
Leamea J Herguson November 1856 – Deceased • GFLZ-RP5 (mother)
Iler H Herguson November 1880 – Deceased • GFLZ-YPJ (son)
Ivy F Herguson September 1882 – Deceased • GFLZ-LVZ (son)
Hattie Herguson January 1890 – Deceased • GFLZ-RHC (daughter, same as GZST-FKQ above)
Ed D Herguson August 1891 – Deceased • GFLZ-RHZ (son)(same as GZST-FK6 above)
Tom J Herguson July 1893 – Deceased • GFLZ-RH6 (son)
Minnie Herguson June 1895 – Deceased • GFLZ-G2D (daughter)
William M Herguson November 1896 – Deceased • GFLZ-52X (son)(same person as GZST-XKG above)
Nellie Herguson September 1899 – Deceased • GFLZ-PL9 (daughter)
existing FT records:
James Franklin Ferguson 23 October 1855 – 11 February 1922 • G3BR-QSZ (father)
Leanah J Brooks 1 November 1855 – 13 October 1933 • G3B5-LCZ (mother)
Ida Florence Ferguson 20 December 1877 – 10 December 1958 • GSRZ-PC2 (daughter)
Iley Houston Ferguson 20 November 1880 – 5 November 1953 • LJRV-F7M (son, same person as GFLZ-YPJ)
Ivy Franklin Ferguson 8 September 1882 – 21 August 1946 • GNMD-SFY ((son, same person as GFLZ-LVZ)
Nelle G. Ferguson 1899 – 1983 • LVHD-DNT (daughter, same as GFLZ-PL9 )
Harriett Louise "Hattie" Ferguson 1892 – Deceased • L4SG-6VQ (daughter, same as GFLZ-RHC & GZST-XKG)
4 -
The latest from the "USCensusProject"
Amanda, a woman of my family, born 1864, died 1947, was given an extra set of parents. No census was added, just an extra set of parents. Her parents were already connected to her, her siblings, and up and down the genealogical line.
In one census, after the death of her parents, she is listed as "adopted," and that census has long been attached to her profile.
The new parents given to Amanda were NOT listed as step or adoptive parents, but just another set of parents.
Update: And now, I find - https://www.familysearch.org/tree/person/details/GFY8-3M8 - an entire invented family from the 1910 census.
And a duplicate invented family in 1900. https://www.familysearch.org/tree/person/details/GF4Y-FPG
4 -
Using indexed census records--without looking at the census itself and doing no other research--is the equivalent of using "hearsay" to build a family tree.
3 -
I had a Zoom meeting with Professor Joe in Jan. He said the USCensusProject and CommunityCensusProject are not going away and that FamilySearch has given him their full support, despite the problems. Unfortunately this seems like a losing battle. Their main goal is for every soul to have a record, and duplicates are a necessary consequence of that. They don't have the time or staffing to research each person to see if they already have a record. If there is no record hint, they will create a new record. He is very kind and has good intentions, but I don't believe he understands how many duplicates the projects are creating. He said 7% duplication rate. I told him it was more along the lines of high 80s, based upon my research.
3 -
I watched Joe's video on YouTube and was impressed by the basic concept and data gathering methods. Where the projects fall down is in their connection to Family Tree. Again, that might have been of some use, but the volunteers are just not carrying out the simplest of checks, to avoid both duplication and leaving the wife's name the same as her husband's. Of those married women's names added via the 1911 England & Wales project, I am finding, on average, that I can identify a maiden name (through FreeBMD and GRO websites) within a few minutes.
2 -
And many - most - of those souls already have a presence in the tree. The project is not helping in that way.
3 -
I have spent hours (as in hours) cleaning up USCensusProject's pointlessly created duplicates and there's no sign the USCP pile is any smaller.
2 -
Why are the USCensusProject people now adding/changing parent/child relationships? I just looked at a married couple who had 12 children and the dual parent relationships were previously correctly shown for all twelve. For some reason, it was determined single parent/child relationships should also be added for each respective parent & child. It's ridiculous how long it took me to remove the 24 superfluous relationships. I'm encountering this situation many times over, and in several cases, two or more totally unrelated profiles have been connected by parent/child relationships, presumably just because they had the wrong ID in their clipboard when they pasted it in to create the new relationship and aren't in the habit of evaluating if anything they're doing is making any sense whatsoever. I'd love to be able to spend my time interpreting unindexed German/Latin records and updating our shared tree but instead I'm left to clean up after them. 😡
5 -
To be clear, the BYU RLL is not associated with the Family History program at BYU. It is the work of an economics professor.
3 -
Hey guys, I understand your frustration. I really do. I do genealogy myself and I have experienced what is being discussed here. I want you to know that I am hearing you. FS is hearing you. The many complaints about silence from FS is kind of upsetting to me. I and my team (of FS employees) that have been in this conversation are working with many other people from FS, including managers, of which I am a part. This issue is being addressed at high levels of FS and we have previously let you know that things are being discussed and that we would keep you informed. We have not been ignoring you or the issue. It is just that it isn't being resolved quickly.
We know you are upset and we know you don't like what is happening. The commentary on this issue is doing nothing but creating more contention with conjecture and debate. This doesn't resolve the issue or help. There are several things going on here that we will report back to you. I can't guarantee that you will like what we come back with, but I want to respond to your requests and my promise for more information.
So, all the negativity and contention within this thread is not helping and we need it to stop. I have never had an issue with anyone discussing frustrations, but I do have a problem when those discussions turn to name calling, threats, and meanness. There are so many violations of the code of conduct in this discussion that we considered closing it. However, we have decided to leave it open but will be heavily editing out the code of conduct violations. I am asking you to please pause on this topic while we continue to work on answers for you. You will need to be patient, but I assure you that we are working behind the scenes in your behalf.
Sam
4 -
Whilst I appreciate your comments (and those of @joemartel), the situation here is quite straightforward, so should not take any longer in finding a solution. Okay, FamilySearch employees can't sort out the errors made in the past, but its management can now advise Professor Joe of BYU that, in future, any activity on this project must be much more strictly supervised to ensure Family Tree users don't have to get so exasperated at all the bad work they are encountering. I'm sure most of those posting to this thread would not usually dream of violating the Community code of conduct, but find themselves doing so as here we are, nearly two years on, still awaiting an "official FamilySearch response" (and necessary action) to an issue that is effectively violating the instructions for working within Family Tree.
4 -
BTW - Even if / when this specific issue is resolved, there are still other projects, being run along similar lines, that need to be examined. The one involving the 1911 England & Wales census is still causing grief: adding of women's names in name of the husband, creating duplicates, and placenames not being standardized by the volunteers. It's not just the US1910 project that needs to be looked at, but the (stricter) agreed terms under which any present / future projects of this kind need to operate.
3
