Peer reviewing changes to the Family Tree
Hello FamilySearch!
I did a quick search through the forum and didn't see this suggested anywhere, although I'm sure it must have come up before. I think the feature I would like to see added to FamilySearch most is a method to prevent casual users from changing common relatives willy-nilly. So many times I've gotten the dreaded "Weekly changes to people you follow" message and discovered that one fairly close ancestor or another has been radically altered by someone whose research skills are still in their beginning stages. It is very frustrating to see so many hours of work undone. Sometimes merges are very destructive!
Part of my day job is writing software, and my team always has to peer review each others' code changes before they get added to the common repository--the other teammates actually have to click "approve" before any code change is added. This helps reduce mistakes and helps make sure that everyone is on the same page about what changes need to be made and why. Is there a way that something like this could be added to the FamilyTree?
I realize that it's easier said than done--it would be all too easy to impose overly strict controls that end up virtually locking the tree. Maybe all watchers can be notified of proposed changes and have a certain window of time within which to object or the changes are accepted automatically. Maybe an objector has to propose an alternative instead of just clicking "reject". There would probably have to be some allowance for dispute resolution if two users can't agree. I haven't really thought it all through--I just know that it would be really nice if I would get a warning that my great grandmother is about to have her parents replaced.
Thanks so much!
Comments
-
The concept of reviewing proposed changes before granting them permission to proceed has been broached in the past - though whether any search facility can find it is another matter.
The general reaction, I would paraphrase as "Please don't - you'll lock everything solid".
Watchers and past-updaters may no longer be interested in FamilySearch. They might be dead, have changed contact details or whatever. This means that any proposed change has to sit and wait for the timer to run down. How long? Long enough for me to lose interest, that's for sure. FamilySearch is not my main priority - it just happens to be something I keep an eye on, in order to monitor those changes. Recently I had to split my granddad's cousin who appeared, according to FamilySearch, to have emigrated from England to Montana. Except he was still in England after supposedly emigrating.
To fix this, I needed to alter the Montana guy by removing his original English birth details and then recreate my granddad's cousin (who'd been merge-deleted). I then did some research on the Montana guy and discovered that he'd also been born in England - so I added his English details and associated him with his English parents. As a bonus, I also located the Montana guy's brother. So that's about 5 profiles to be updated - and the Montana guy would be updated in several steps, presumably each requiring permission.
The above took me 2 or 3 nights work - the creators and/or descendants of the Montana guy didn't respond to my message telling them what I'd done, so goodness knows how long I'd have to wait if I needed to wait for my permission request to time out.
Intrinsically, the peer-reviewer idea sounds great but doesn't match up to the professional case as there is no guarantee anyone is at the other end of the review request, plus an IT professional probably has other things to be going on with while waiting for the review.
5 -
Here's one of the threads on peer reviewing titled "Moderators for individual records and/or family lineages."
2 -
WikiTree is another collaborative tree, and it has profile managers and merge requests and so on. It also, therefore, has an "unresponsive manager" procedure -- and it can really only operate this way because it is a couple of orders of magnitude smaller than FS's tree. (36 million profiles versus 1.2 billion profiles.)
Nominating everyone who follows a profile to be its managers sounds good in theory -- until you think it through, as Adrian said. I don't know about anyone else, but my response rate on internal messages on FS is abysmal: since 2018, I've had replies to my attempts at communication exactly twice.
3 -
@Sean R. Thornton Your example of code change review is interesting, but I contend it, too, could fail. I assume there is a process by which you are notified of a code change assigned to test (or just review?). Do you have a process by which something happens if one of the employees just gets tired of spending too much time to review and stops doing it? Or worse, said employee starts accepting changes without looking because of time constraints? Will anyone in your company ever notice that there are X changes in the cue not functioning in the system yet, or that bad changes are being found in the reviewed code? When that happens, what are the consequences for those employees?
I suspect your company would begin threatening to fire people who refuse or neglect to review and management will have to have an "all hands" to explain why everyone is part of a team, connected to success, yada yada.
How would this work in FamilySearch? There is no team. In fact, there are likely millions of users who think they have a private tree and are unaware of the world tree. We certainly get enough complaints about "my tree" being violated.
If people's changes start vanishing into thin air with a message of "Thank you for your change. Your work on the tree is important to us and we will review your change as quickly as we can. You will be notified after the review is complete, and if approved, it will be applied. If it is rejected and you wish to contest the ruling, you will be provided the opportunity through the feedback tab." I do so much work, I will forget what is in the cue. Maybe I will make the same change multiple times. Maybe I will deliberately create duplicate people in a futile attempt to circumvent the bottleneck and get the work done however I can, which of course would kick the duplicate actions to potentially different reviewers. How is that all reconciled? Don't you see what a mess it will be?
And finally, what about philosophical changes? What does your company say about that? I recently found and attached my mother-in-law's death certificate. While doing that, I noticed someone changed her name from the legal name she took at age 6 when her father naturalized, back to one of the many variants of her original Greek name. The Greek name is good for her father as he had it well into his adult life and there are many records of it, even though most have different spellings. But I reject it for my mother-in-law as there are few records which have her original name and all her adult sources reflect the legal maiden name she took. Even her birth certificate was reissued with the legal name. So I changed her name back to the legal maiden name; her Greek original name in all its multiple spellings are already alternate names. What are the instructions for this? It is personal opinion.
So, what are the code reviewer instructions about this? What would you do if one of your code reviewers looked at your change and said "you have functions built into your code which need to be removed. Any code that can be replicated in other places needs to be an external function that is called when needed, never inserted directly into the main program. It creates too much clutter and we need to keep the main program clean. Please re-write this whole section my way and I'll approve your change." OK, I'm sure you can tell my code writing days are a couple of decades behind me, but I think you get the picture. In your company, are the reviewers allowed to impose their own philosophical or style rules? Even for your company, this review process is a delicate and dicey thing that could easily fall apart or do serious damage if management doesn't stay on top of it. It certainly ISN'T a good idea for FamilySearch where there is no connection between "management" and the "workers".
3 -
If we could teach others to use the beta.familysearch.org site to learn and practice how to use familysearch, then we could cut down on the "learners errors". In working on familysearch for many many years I had not learned until a few months ago that one can go to the beta version and practice entering data and making changes in beta without effecting the real familysearch tree and causing problems with everyone else.
How do I use the beta version of FamilySearch?
Article Id: 1375
September 06, 2023
You can use the beta version of FamilySearch as a sandbox or learning place. You can experiment, learn, and teach about FamilySearch Family Tree without having to use real data. The changes you make on beta Family Tree do not synchronize with the live FamilySearch Family Tree.
Before you start
As you use the beta site, please be aware of the following:
- FamilySearch Support does not support the beta site.
- To see if you are on the beta site, look at the address bar at the top of your browser to ensure it says: https://beta.familysearch.org
The beta site also has some limitations:
- The beta site is designed for the FamilySearch engineers to use as they work on updates to the production website. Things do not always look the same there as on the original website.
- Sometimes the beta site is down. If you get an Internal Server Error, please try again later.
- The beta site can be slow, depending on work the engineers are doing.
- The data on the beta version of Family Tree does not always match what you see on the live version. The beta version shows a snapshot of tree data at a specific time. The beta site is not meant to be an accurate or up-to-date representation of FamilySearch Family Tree.
Steps
- Go to the beta version of the FamilySearch website.
- Sign in with the same username and password you use on FamilySearch.
1 -
The trouble with trying to learn to use FS on the beta site is that it does not have a full copy of the indexed records database, which means that hints mostly don't work at all in beta, and indexed sources only sometimes.
1