Why can't instructions be made clearer to CommunityCensus Project participants?
In the examples I have encountered relating to the 1911 census I have found - apart from the duplication problem - all married women seem to have been added in their married names.
Surely this issue can be escalated to a senior FamilySearch employee, so that action can be taken to ensure these projects have firm project instructions and stricter checking and supervising arrangements?
I have now merged her with GVC1-33F. In fairness, I only created this profile today, so duplication is not the problem in this example. However, it took me just five minutes to find details of her marriage to Robert, and hence to discover Margaret Ann's maiden name.
Oh, and also to find Robert Wrightson had been wrongly indexed as Robert Wrighton - although that error is a Find My Past issue!
Answers
-
Many families have been added to FamilySearch from the 1911 census via the Community Census Project. As they have been added from the census, the married female surname is still showing.
Volunteers from the UK ROC (Remote Operation Centre) for FamilySearch are systematically working their way through the families and, where possible, adding maiden names, marriage dates and places, fuller names instead of initials and sources. These are checked by an experienced FamilySearch Volunteer.
Often, whilst adding the above information, a duplicate will emerge on FamilySearch which is then merged to avoid multiple entries in the system.
Unfortunately (or fortunately), sometimes you may get to the family before we do and we are grateful that, in effect, you will do the research on the family for us. If you would like to get involved in this wonderful project, please contact me at christoper.wright@familysearch.org
Chris Wright
UK ROC Leader
1 -
Thank you for your response, Chris. My criticism of the work being carried out by the Community Census Project remains unchanged, however.
Two of the main guidelines to Family Tree participants are:
(1) To avoid creating duplicates
(2) Not to add a woman in her married name.
I wonder why those running this (and similar) projects are not seeing that volunteers abide by these guidelines, a failure which (as you explain) is necessitating another group of volunteers ( from the UK ROC) to have to go back to these records to do further work - in amending surnames to maiden names, add additional data and eliminate duplicates.
I would refer you to the discussion on the US1910Project at https://community.familysearch.org/en/discussion/88094/us1910project/p1, where many users have expressed their exasperation at a similar project. The huge amounts of duplicates created by that project has caused lots of work for everyday Family Tree users. It is apparent here that project volunteers have not been carrying out additional work, but leaving it to those who would much rather be spending their time on genuinely productive work relating to their family branches.
Perhaps (as others have failed to do, in spite of many requests) you could advise us of the actual benefits being created by these volunteer census projects. All many of us are experiencing is the negative aspect - of spending hours of our valuable time in amending the data and merging duplicates.
Meanwhile, sorry, but no I won't be getting involved in volunteer census projects that many in this Community feel should be completely halted until: Family Tree guidelines are abided by, appropriate project instructions are issued to volunteers, and much improved supervision is implemented.
1 -
Thanks for your feedback Paul. I am aware of the 1910 US issues but I believe that the UK version has sufficient fail safes as the algorithm that put the families onto FS from the census do not have duplicates initially (I'm sure a few slip through). In theory, only the UK ROC knows about them unless researchers happen upon them.
We are working through the families as fast as we can which involves fleshing out the entries including the very important finding of the maiden name. Every family is reviewed and all definite duplicates that subsequently emerge are merged.
We have written very specific instructions and guidelines to our volunteers and would hope and expect them to be followed.
I hope that gives you some reassurance.
0 -
Reference the reply above which states:
“I am aware of the 1910 US issues but I believe that the UK version has
sufficient fail safes as the algorithm that put the families onto FS from the
census do not have duplicates initially (I'm sure a few slip through).”
-------------------------------------------------------------------
I’m sure my experience with this project is duplicated with many other FS users,
concluding that the UK 1911 census project is in dire need of fail safes!
Several very complicated family situations have been exacerbated and confused by this
project.
I messaged one volunteer worker before realising a particular convoluted mess had
been part of this project. Here is the reply I received.
-----------------------------------------------------------------------------------
“I worked on this family as part of a FamilySearch project which connects families which
have been entered into FamilySearch as part of the UK/Wales 1911 census. We do
our best to make sure things are correct as far as the direct family we are
working on is concerned but are asked not to go beyond
the original family we are working on.”
-------------------------------------------------------------------------------------------------------
The result of this is in my case was women listed with their married names [sometimes
when they were just living with a man], children from three marriages listed as
one family, and worst of all, temple work ‘ready’ for all of them – including
marriage and child sealings.
I see that after censuses are inputted, checks are made but in one reply it states
“Unfortunately (or fortunately), sometimes you may get to the family before we do and we are grateful that, in effect, you will do the research on the family for us.”
------------------------------------------------------------------------------------
I can see why two sets of researchers are needed – one to input and another to check, but the gap between the two is creating massive and immediate problems plus a great amount of work.
Above all is the worry about the integrity of temple work – and that it’s possible temple ordinances might be completed incorrectly and needlessly.
1 -
If this project was purely an indexing exercise it would be fine. Volunteers indexing names exactly as recorded in the 1911 England & Wales census - although that has already been done, of course, and the results appear on FamilySearch courtesy of Find My Past.
But this project aims to add every name from the 1911 census to Family Tree - based on what is written in those records. The problem with this is that "wives" (and widows) continue to be recorded in their married names. Not only that, no checks are made regarding actual ages or birthplaces, so these are invariably wrong, too.
Anyone experienced in handing census records will know their contents are notoriously unreliable - not matching in detail from one census year to the next. (Different birthplace shown in different collections and ages often out by several years.)
Together with the fact that there are no linked images for England & Wales census records (unlike their US counterparts), one has to reach the conclusion for which this post has been given its title. There is really no acceptable reason such data should be used to create IDs in Family Tree. All that is being added is unchecked, inaccurate detail - and probably thousands of duplicates.
0 -
You and I have probably merged a few hundred duplicates each, @Paul W. 1880, 1910, 1920 - all for the same family. I tear my hair out.
1 -
I struggle to understand what the purpose of the Community Census Project(s?) is. Whenever I try to read anything about them, there seems some utterly naive view that more data must be good and what are we complaining about? Is it just a make-work project to make people feel important and / or wanted?
4 -
The project I encounter most often is currently using the name USCensusProject. I have messaged that account a few times, but I have never received a reply. I hope I don't jinx myself - the last time I encountered that account making strange changes was 21 May. They had shifted from adding more names to changing correct information in profiles to incorrect details.
Given some of the other odd things I've encountered, the CensuProject may have just changed its username to some other name.
2 -
I'll attempt to explain the value of these community census projects. I am very skeptical about how successful they are in achieving their aims, especially when balanced against the pain they cause, but there is some value and they have been created with good intentions.
Any census collection will contain many people who are not yet in Family Tree. Adding those people to Family Tree via a census means that they will have at least one source to document the person, who will generally have a name and birth data. In most cases it will also create relationships to other family members who were in the same census household. With proper duplicate checking, any persons who are already in the Family Tree will simply be linked, rather than creating extra duplicates. But for those who are not already in the Tree, this process will create new Tree persons, often within families, which will eventually allow them to then be connected to other Tree persons. Growing the Tree with sourced persons who often even have family relationships is a good thing.
As I understand it, that's the idea, and if it worked as hoped, the benefits might be appreciated. However, census records aren't the most reliable record collections out there, and so trusting that single collection to create new persons is problematic; it's always better to find multiple sources for a person before you add them to the Tree to help ensure that you have correctly identified that unique person who has lived on the earth.
Although there might be some benefit in adding new persons to the Tree who aren't already there, one of the biggest problems with these projects is creating duplicate persons who are already in the Tree. We all know that the duplicate checking done in these projects is not accurately matching duplicates. Matching on married names for women is problematic without further research, and inaccurate or incomplete data in the records will also make matching unreliable. I don't want any system blindly assuming it has found duplicates, but choosing to avoid incorrect duplicate matching means that many duplicate persons will be created in the Tree. I got a chuckle out of @Paul W 's thought that these projects would create "probably thousands of duplicates"; if only that were true -- they are certainly creating millions of duplicates.
In conclusion, I hope I've helped people understand that some small amount of good comes from these projects, and they are not being done with ill intent. But that good has to be weighed against the many problems caused by millions of records with questionable data and new duplicates that have to be dealt with. That small good just isn't worth the large pain.
6 -
@Alan E. Brown - thanks for the (properly sceptical) thoughts. I'm glad someone attempts to explain what's going on.
I notice that you refer to "duplicate checking" - judging by the complaints, I'm mildly surprised that such checking exists. But, by the very nature of things, we have no idea about when the duplicate checking works, we only see when it doesn't. That may not be statistically fair - but if you're on the wrong side of a raft of new duplicates, then "perception is reality". And, of course, FS are never good at coming forward with real numerical analysis.
I can only say that I've just done a swift check of my ancestors that qualify for inclusion in the 1911 and the system isn't flagging any as having potential duplicates. That could be for any number of reasons such as:
- I've already linked them to the 1911, so the project hasn't attempted to link them again;
- The project successfully recognises that they are already in FS FamilyTree (e.g. in the 1901, 1891 etc) and so counts them as duplicates not to go further forward;
- The project hasn't got round to them yet so I'll have the deep joy of duplicated ancestors to come;
- Or anything else.
I could have misunderstood the logic so don't quote me on reasons...
I am prejudiced against creating duplicates - when you have a Billington relative with 6 baptised children so you have 6 versions of him plus a 7th for his marriage and an 8th for his own baptism, then merging 8 profiles is a pain. Much better not to have to merge them but simply search the sources. You know, the old-fashioned way.
2 -
And if your Billington relative, like my Hughes relative, had 14 children, all of whom were baptized, and all of whose records were indexed multiple times, they are already very well documented. I've spent much time merging them properly, and having to start all over again doesn't make my day.
3 -
You have provided a well described, balanced view of these projects.
If I may respond on a relatively minor point, I raised the original "question" with reference to the CommunityCensus Project, believing that specific title relates to the 1911 Census for England & Wales. (I stand corrected if someone can point out other collections covered by this project.) I believe the population of England & Wales in 1911 was around 36,000,000, which is why I added the more conservative estimate of "thousands" of probable duplicates, rather than the "millions" that possibly have been created by the various census projects, relating to the US in particular.
It remains a disappointment that there appears to be no acknowledgment (by FamilySearch or project leaders) of the huge amount of inaccurate information that is continuing to be added to Family Tree through these projects. If we, as individuals, advised we were happily adding IDs for individuals whose identities had not been carefully researched and confirmed I'm sure there would be lots of criticism for such sloppy work, yet that is exactly what is happening here.
To emphasise, I see nothing wrong, per se, with a project that aims to link families and broader communities, but, in practice, even this is not happening. (I have found only some of a household's members being added to the Tree and others left out.) I would just prefer the extracted information from these projects to be kept within separate databases. And, in spite of the good intentions - and possibly project instructions - volunteers seem to be making little effort to make even basic checks, that might confirm ages, maiden names and correct relationships in relatively little additional time.
Unfortunately, it is very doubtful we will ever receive a response from FamilySearch management on why it feels adding so much unreliable detail to Family Tree is in any way enhancing the program.
1 -
Their latest activities seem to be deleting correct information that was entered last month by ... "CommunityCensus Project". There is, of course, no evidence or reason statement for either action.
2 -
Just this morning I saw a family entered by the "USCensusProject" where the entire family has been given a surname containing invalid characters. Warning messages on every member of the family were ignored. https://www.familysearch.org/tree/person/details/GJHZ-YNM
One of the children even has an invalid character in the given name as well.
I struggle to see value in these entries.
3 -
"I struggle to see value in these entries"
Quite. The rules are surely simple - if you can't read it, leave it for someone who can.
Surely no human being would enter data like that? Which makes me wonder... Do we know for certain that the USCensusProject really does consist of human beings entering data into FS FamilyTree? And not some sort of software (AI anyone?) that's loading stuff according to rules that, in all honesty, result in a percentage of morale-destroying nonsense?
1 -
I've messaged USCensusProject a few times, but I've never received a reply.
It was my understanding that the "work" was being done by a group of humans, but it certainly could have transitioned to robotic/AI work.
1 -
I continue to be constantly reminded of how time-wasting the CommunityCensus Project has proved to be.
This branch is just a snippet of what I have encountered over the last few days whilst trying to construct accurate records for my LATHA(E)N branch of relatives. In this "offshoot" the warning flags indicate place names that have not been standardized. Also, an example of the typical situation where no attempt has been made to find the maiden name of George Potts' wife. What is hidden (from the screenshot) is the copying of the birth place and date for each individual, as indicated by the 1911 census. As every researcher knows, an examination of original birth certificates and, say, the 1901 and 1921 census records is likely to reveal rather different "facts" about the birth data than in this one source.
It remains difficult to comprehend how any serious genealogist (and one assumes there should be many in the employ of both FamilySearch and BYU) could continue to support the import of such data to Family Tree. I have found census records to be, at best, a rough guide to the precise identity of an individual. That such records should be used as if a sound basis for adding individuals to Family Tree is quite beyond my comprehension.
Again, would anyone who could possibly stop this work please make every attempt to do so? Its end result is clearly breaching guidelines provided to Family Tree users and creating far more work for us than the exercise is worth. (Merging duplicates, finding maiden names, establishing the true place and year of birth, etc, etc.)
I have never denied there might be some good provided by these census projects per se, but in no way should the gathering of such information (on different sets of census records - including the US 1910 collection) have led to this data being directly transferred to Family Tree.
Just a tiny sample of what many of us are being confronted with: non-standardised and unchecked places and dates, and wives' surnames copied as per their husband's (perfectly correct for indexing purposes, but not for inputs to Family Tree):
3
