Suggested Reason Statements during merge
Does anyone else find the suggested reason statements too easy to just copy'n'paste?
Before they were suggested, careless users just didn't give a reason and you knew immidiately to double check everything. Now they just copy'n'paste the first one the see. The problem is it now looks like a valid reason.
Today I got notified that two individuals had been merged because, "All vital information and relationships match. ID numbers: ****-*** and ****-***. (emphasis mine)
Far from this being true, I discovered that: Given names didn't match, Family names didn't match, Birthplaces didn't match, Ages didn't match, Fathers didn't match, Mothers didn't match, Siblings didn't match, Spouses didn't match, Children didn't match. The only similarities I can see is that they were both born in America, in the same decade.
The census records for each of them, living with their respective families, for both the 1920 and '30 census are now attached to the merged individual!
My concern is that the reason statement gives this a validity it doesn't deserve.
Rant over.
Comments
-
I can agree to some extent, but before these "pick list" items appeared users would just add a comment like "Exact match", in spite f the profiles being totally different! When used correctly, I find this feature has proved to be a useful enhancement. Personally, I often add something like, "All family members match, too" or "Same spouse / marriage event details".
Many of the merges I have encountered - recently or in the past (before a printed option could be "pasted in") have been just plain wrong, whatever wording has been used to justify the merge.
None of this will be a problem as far as careful and conscientious users are concerned. But the careless and inexperienced will still mess-up, regardless of the options they are given in relation to reason statements and what they then choose to enter.
0 -
Before they were suggested, careless users just didn't give a reason and you knew immidiately to double check everything.
Hm. I knew no such thing. Also, I did so many merges myself, cleaning up thousands of 1, 2, 3-PID fragments imported by FS that I could not be bothered to compose a carefully worded reason statement. Nor was one needed; no one had touched those PIDs in a decade, and the reason I was merging was apparent on inspection.
My concern is that the reason statement gives this a validity it doesn't deserve.
It is a formula and you know that, @ColinCameron.
You seem to be advocating somehow raising the bar. Unfortunately, no amount of raising the bar would solve the problem behaviors of some actors here. But the good news is bad actors are a tiny minority and over time the mass effect of crowdsourcing erases their tracks.
0 -
I don't think having or not having "canned" reasons available really helps with sorting through change logs. FS attaches the reason to all sorts of weird parts of the process, so as redundant as it seems at the time of input, I think it's a good idea to include the word "merge" in the reason....
I do wish one of the canned reasons were tailored for the use of people like dontiknowyou and me, whose merges are 99% of the "index-based duplicate parent" variety.
0 -
The reason statements are basically the two PIDs and a choice of 4 grades of evidence, least to most. I do appreciate having the PIDs enter the change log automatically and I give as little thought as possible to the choice. I need to guard against decision fatigue.
The reason statements greatly over-specify the choices. Boiled down, the choices are:
- Match in detail
- Match in part, detail incomplete
- Match in part, detail conflicting
- Match on circumstantial evidence or inference, detail largely or completely lacking
1 -
Whoever flagged my comment above as Spam, please remove the flag.
0 -
Ive always wondered what it is that triggers to the spam indicator
is it a person marking it as spam - or is it some other type of trigger.
0
