Putting a better safety net around merges and deleting relationships
I’ve done incorrect merges and deleting relationships I was sorry about and had to go back in and redo what I undid. Maybe have a bot or a system in place like “you must have a source (not just a reason) for this change” or “you must consult relatives for this change” the only issue with that last one is if you are the sole researcher for a line, like me with the line I am working on.
Comments
-
I don't think either of your suggestions could work, in practice.
In my early days of research, I would attend a County Record Office (here in England) but not note any reference of the source from which I recorded details on my relatives. Many sources are yet to be added to FamilySearch (or other websites), so - in spite of knowing my information is correct - I still can't add a source as back-up.
Neither do I see your “you must consult relatives for this change” idea working, as, sadly, many close relatives refuse to accept any evidence you might find and insist their information is correct. So, what do you do if a relative disagrees with the "facts" or, worse still, different relatives hold varying ideas regarding where an individual in question was born / died, etc?
Consultation / collaboration is an important part of the Family Tree project, but who has the final say should depend on carefully researched evidence - not necessarily adding a referenced source, or gaining the agreement from a close relative, who might have got their facts wrong.
3 -
No, please, no added impedance on merges! They're complicated and tedious enough already.
As you noted, an "agreement from relatives" clause cannot work, because at least 90% of the time, I am the relative -- and 90% of the remainder haven't been heard from since 2014.
A documentation requirement is likewise unworkable: the two merges I had to undo the other week were both well-supplied with sources. In fact, it was the doubled number of sources compared to the usual that alerted me to the problem in the first place.
I think the problem needs to be tackled from the other end: make it less difficult to undo a series of merges. I don't know what to suggest for the "how", but I do know that making the change log entries easier to parse/recognize would be a step in the right direction. Currently, merging a group of index-based tryptichs (parents and child) into a family results in all sorts of scary gibberish in the change logs, such as Relationship Added (Child Added) and Relationship Deleted (Child Deleted) -- both with exactly the same date and contributor and Reason. It'd make much more sense if these sorts of changes were labeled according to what actually caused the action: "relationship modified by merge of parent", for example.
3 -
"making the change log entries easier to parse/recognize would be a step in the right direction ... It'd make much more sense if these sorts of changes were labeled according to what actually caused the action: "relationship modified by merge of parent""
Double, triple like. This would make such a difference.
0