Is the user "TreeBuilding Project" taking the tree forward or wasting time?
Answers
-
The treehelpers have moved on to the 1930 census.
Unfortunately, the 1930 census has been attached to a man who died in 1897, giving him several children who were born in the 1910s. 27GZ-VJD
Why oh why do the treehelpers not view the the red exclamation alerts?1 -
Perhaps, being mostly students in teams run by their profs, they simply don't challenge what they are told to do (even though they are presumably also expected to develop their critical thinking skills).
Meanwhile, since any challenging is clearly all down to us, I propose to submit the Idea tomorrow afternoon UK time (via both new and old Suggest an Idea UIs).
0 -
Idea submitted. There still appears to be only the one submission route.
The Idea is not yet showing but I have put a screenshot here: Idea posted 29 September 2024.pdf
I've sent Support the following hopefully uncontroversial holding message: 'Thank you for this advice. I have posted an Idea as suggested, but be aware that there is a warning on the relevant Community page, as follows: ‘You can continue to add ideas but they won't be posted while this area is under construction.’ Therefore, if the Idea does not appear on the list in the next few days, we will need you to find another escalation route.'
1 -
Interesting response from Support: 'We are aware of the warning on the suggest an idea page. This is to encourage people to look at the site to see if the idea has already been posted by someone else. The engineers will still see your posted suggestion and will take any action needed, Please be aware that it may take some time before there s a response to this as the engineers are dealing with a very heavy workload.'
I have sent them this: 'Thank you for that helpful insight. But, given the clear pressures on the engineers and the fact that what we are requesting is a communication channel allowing discussion of the situation with an appropriate FS team (so not a system enhancement), is Suggest an Idea really the best way forward?'
(My Idea is still not appearing on the Suggest an Idea list, anyway.)
0 -
@MandyShaw1 - thanks for trying. I do feel concerned that Support imagine that suggestions are always engineer-appropriate. There are lots of disciplines involved with the running of a site such as FamilySearch and software change is just one of them. I would have thought that the suggestion here was fundamentally procedural in nature.
1 -
Agreed. Things that puzzle me particularly are the lack of any sort of User Group and the apparent lack of information asset ownership (which latter is maybe the gap we are coming up against in this thread - perhaps there is no communication channel because no team exists for it to lead to, or indeed that has the teeth necessary to protect FS data against unwise initiatives).
1 -
A few months ago, when we were having a similar discussion, I did an online search for "Data Integrity" positions open with FamilySearch. I found quite a few advertised open positions.
In the last few days, I've made similar searches but found no open positions advertised.
Does that mean anything? Maybe; maybe not. Perhaps the positions have all been filled.
2 -
I wonder if those are the people involved with PQS, who seem both collaborative and effective, but who I suspect don't have much of a strategic role.
1 -
Reply from Support: 'We thank you for willingness to try all that you can do to help set up a dialog to resolve the problem. We would suggest that perhaps it would be better to contact the project direct. We have added this Url to aid you record-linking-lab.byu.edu'
We obviously need to explain that we've already tried that route without success, in that the few responses we have received from BYU RLL (all of them from one senior person with, no doubt, many calls on his time) have mostly involved detailed discussions of specific example profiles, with no real attempt to cover our many strategy-level suggestions and questions.
I think the next steps (assuming my posted Idea elicits no constructive response) are probably
1) for one of the professional/experienced genealogists among our number to try Joe one more time, and then, if necessary,
2) for us to explain the above to Support and ask to be put in touch with whoever is BYU RLL's FS liaison person (surely they exist).
Comments anyone?
P.S. I have flagged this comment with a message asking for this thread's Discussion List positioning issue to be fixed.
0 -
Not surprisingly, I suspect, no joy as yet either on the Discussion List positioning issue or the listing of my suggested Idea.
My current thought is to message both Joe and Support on Monday.
@Adrian Bruce1 tagging you in case notifications have stopped working here again. (Tried to tag Aine as well, but could not make it work!)
0 -
Thank you @MandyShaw1 for your efforts in this! I feel that FamilySearch should do more to communicate with its users, but it's difficult when the concerns are not even acknowledged. But thank you for trying!
Also, I guess we could try with Joe one more time. Considering his past responses, I don't expect anything to come of it.
1 -
@melanes I will message Joe here in this thread I think, for transparency (though the discussion list positioning problem is not helping…)
0 -
Well, here is another example:
Edell Allen GRN4-PGZ. This duplicate profile was created from the Numident project. The birth location was entered as, "Louisville W*, Mississippi, United States" with no attempt to standardize the location. The duplicate profile entered the gender as female, which is correct. The other profile had been created from the 1940 U.S. Census where the gender was incorrectly recorded as male.
Granted, this would have been a difficult for the treehelper person to know. But it illustrates that drive-by genealogy work is creating problems and not solving old ones. This wasn't about discovery for me. I was doing a step-by-step descendancy project checking profiles, attaching, records, cleaning things up. I know the family and the context and could recognize the duplicate despite the incorrect gender on the one. The treehelper person did not take the time.
3 -
Hi Joe, thank you for your help on this thread.
There still seems to be a big gap in understanding between the FS users posting here and the BYU RLL team concerning the overall impact of your initiatives on the Family Tree and on researchers.
How can the FT user community discuss these non-profile-specific matters with BYU RLL, ideally with input from FamilySearch also?
1 -
I lost track of this thread when it dropped off the front page.
On 14th Sept. I reported that "The NUMIDENT record for Margaret Jane Haney LWQW-HZM was attached today with her father's record attached to her mother, and her mother's record attached to her father. On this occasion by USCensusProject." I corrected that on the 17th Sept.
Today, 9th Oct I find that TreeBuilding Project has got involved and has reattached the father's record to the mother, and the mother's record to the father.
Does the left hand have any idea what the right hand is doing?
This source was already correctly attached to all the right people so why did TreeBuilding Project get involved at all?
I have corrected it AGAIN. It's bad enough having to fix these problems once, but do we have to to it over and over again?
1 -
@ColinCameron There's some sort of problem with the positioning of this thread on the discussion lists, it seems to be in a 23 September time warp. I've already reported this positioning problem several times, including flagging one post, and indeed I split the thread for a bit, but the mods were against that idea. None of which is helping us get any of these NUMIDENT and census issues properly discussed and resolved.
0 -
@Joe Price 4 further specific profile example for you.
0 -
Overnight, another NUMIDENT cross-threaded with the father's record attached to the mother and the reverse.
ONLY - the NUMIDENT was already attached correctly. So why did the CommunityCensus Project need to touch it at all?
I attached it to the correct parents on 14 September 2024, after the USCensusProject had attached it to the wrong parents on 13 September.
Parents Joseph McGarrity K46T-J83 and Kathryn Hines GMM5-17W. Their daughter is Mary Joseph McGarrity GMMR-333.
Fixing the same family for the same record multiple times is not a good use of researchers' time.
2 -
Maybe the BYU RLL automation scripts are based on data previously retrieved and stored by BYU, and don't check the up-to-date FT data? That would explain a few things (as well as being a seriously bad idea).
0 -
And another one the same - Anna Coleman G7F1-3PL, her husband, Henry McAllister G7F1-V87, and their son Lawrence. The record was already correctly attached, but the TreeBuilding Project attached it at cross purposes this week.
0 -
@Joe Price 4 please note the two additional profile-level concerns added by Aine today, plus the fact that the discussion lists in Community are not currently showing this thread in the right place.
If you don't currently have time to engage with us on this matter (understanding that you have a lot of calls on your time), please identify a suitable member of your team as an alternative contact. Thanks.
0 -
And, overnight, another cross-threaded NUMIDENT attachment on LB29-F7M and LB29-W9L.
0 -
And AGAIN, by the Community Census Project. A cross-threaded NUMIDENT attached to LBXZ-HYM and LB68-1Y4. I had, of course, already attached it correctly on 15 September 2024. That was after the USCensusProject had attached it incorrectly.
0 -
Looking at his profile, Joe doesn't seem to have visited this Community for a couple of weeks. I guess he may or may not receive email notifications related to this thread, or indeed when we ping him here, and anyway it's clear he has a lot of responsibilities.
I think I will email BYU RLL via the link on their website home page to ask if someone can respond here (Edit: done). There are quite a few new profile-level examples, and the non-profile-specific request suggested to me by FS Support won't yet have been picked up either.
1 -
No sign as yet of any BYU interaction. If this is still the case on Monday I will ask FS Support to escalate this matter to BYU RLL's FS liaison person, unless anyone wants to try a different approach?
0 -
Re my submitted (Suggest an) Idea, this morning four new Ideas have appeared, all submitted by the same person, but mine has not surfaced (and I have had no communication about it from anyone in FS). So I would guess that avenue is closed to us.
0 -
Only new Ideas seem to be coming through from Suggest an Idea (or certainly that's the impression I am getting). I have posted a question asking what's happening re the backlog, and will delay moving forward with my escalation request to Support until I've had an answer, I think, it's only fair.
0 -
All the new Ideas have just changed into General Questions, so I have given up on the Idea approach and sent the following to Support:
'We have requested assistance from BYU RLL, both via FS Community and via their website as linked to below, and have had no response whatever.
Could you escalate this to whoever in FS is BYU RLL’s liaison person please.'
2 -
I have had a response:
'We are grateful to you for all the time that you have spent trying to resolve this issue. We at FamilySearch Support Europe have no specific access to anyone in the BYU Record Linking team beyond the email we have already supplied. If you are not receiving replies, we suggest you contact BYU more generally via their website. [BYU main website link provided]
However, picking up on one point you made in an earlier email, perhaps you do not fully understand how the projects work. Stage one is to create a record of a family on FamilySearch that is not already there, based on a record such as from the 1911 census. This will, as you comment, contain a wife's married name. The second stage is for volunteers to tidy up these records - including substituting the wife's maiden name if possible or deleting the married name at least, linking to other records and merging duplicates. There may be a gap of months between Stage 1 and Stage 2.'
I shall reply to this, obviously, making the points
a) that we were asking to talk to whoever in FS is BYU RLL's main contact, inside or outside the Support team,
b) that they clearly know more than we have ever been told, indicating that they must have a source they could put us in touch with who would be able to help us,
c) that the married name point is just one of the issues we have encountered.
I propose also to send them my problem summary document (Numident summary.pdf - the detailed analysis/results section is now in another linked document).
Any other thoughts gratefully received.
3 -
On their response:
The second stage is for volunteers to tidy up these records - including substituting the wife's maiden name if possible or deleting the married name at least, linking to other records and merging duplicates. There may be a gap of months between Stage 1 and Stage 2.'
The CommunityCensus Project work (on the 1911 census) I encounter is mainly dated 2022 and I believe I have only seen one instance of a woman's married name being changed to her maiden one. Some two years on, there is no evidence that "Stage 2" is producing any improvement to the original work. With the use of FreeBMD and the GRO birth index it has often taken me a matter of minutes to identify the wife's maiden name. However, another main issue has been the entering of placenames and dates of birth. The former rarely appear in standardized form and the latter is usually written as a year (e.g. "1875"), when census records are known to be wildly adrift when it comes to the recording of ages, so at the very least "about 1875" should be inputted, rather than an exact year. Also, I sometimes see different spellings of the same surname being inputted for different members of the same family, which seems to be taking the "indexing exactly what you see" instruction a bit too far.
I have sent Chat messages on several occasions to "CommunityCensus Project" (a couple answered by "Joe"), but these have provided me with little confidence that there will be any improvement in these flawed practices when it comes to future projects - presumably again involving inexperienced volunteers following poor PIs.
Sadly, anyone who could help in improving the quality of this work (or, hopefully, see that it shouldn't be linked to the Family Tree project at all) seems to be in denial about the amount of damage being caused by its poor standard - and I haven't even mentioned the problem with the creation of a huge amount of duplicate profiles (well, not up till now)!
Mandy should be commended on the time she is dedicating to the issues relating to these various BYU projects, but I remain doubtful that her / our highly constructive criticisms will lead to any positive improvements regarding what is proving such a pain to all of us who are encountering (and having to clear up) the end results of such poor work.
4
