"Latest change" (mis-)attribution after merge
If a conclusion is moved in a merge from the "deleted" side to the "surviving" side, the "latest changes" slot should keep the date and identity of the user who actually contributed that conclusion. Attaching my name and the date of the merge to it creates false information. I did not have anything to do with the conclusion; I just merged in a profile that contained it.
Comments
-
Julie
.
Like MANY others ...
.
I wholeheartedly agree with you ...
.
This has been 'pet peeve' of MANY of us over the YEARS ...
.
If I recall, the matter has been raised on numerous occasions in the OLD 'FamilySearch' ("GetSatisfaction") 'Feedback' Forum; but, to 'NO AVAIL' ... NOTHING had been DONE.
.
The principle reason/suggestion/consideration as to WHY such may be inappropriate being, something like ...
.
The User/Patron doing the "Merge"/"Combine" is the one EFFECTING the ACTION, at that 'Time'; and, NOT, the ORIGINAL User/Patron who entered the "Details", at an EARLIER 'Time'; PLUS, the ORIGINAL User/Patron who entered the "Details", did so for ANOTHER individual/person; and, NOT, that for the 'Surviving' individual/person.
.
Which to me, personally, seems like, avoid doing what SHOULD be done ...
.
'Yes', the User/Patron, doing "Merge"/"Combine", is the one EFFECTING the ACTION of the "Merge"/"Combine", at that 'Time'; BUT, that said, they are SIMPLY "Transferring" the ORIGINAL "Detail", from an EARLIER 'Time'; as, they WANT such, transferred to the "Surviving" individual/person, in an "AS IS" state.
.
The User/Patron EFFECTING the ACTION, of the "Merge"/"Combine", CAN later "Change"/"Edit"/"Amend", what they have "Transferred", if they so desire; which, would then be in their 'Name' (well, "Contact Name) ...
.
When EFFECTING the ACTION, of a "Merge"/"Combine"; and, ORIGINAL "Detail", from an EARLIER 'Time', is "Transferred", in as an "AS IS" state, that "Detail" should ALSO "Display", BOTH, the ORIGINAL "Contact Name" (User/Patron); and, the ORIGINAL 'Date' (of an EARLIER 'Time') - NOT just that of, the "Merger"/"Combiner"; and, the "Merge" 'Date'.
.
Even if there is CONCERN, why NOT also just INCLUDE a REFERENCE to the ORIGINAL 'FamilySearch Person Identifier' (PID) to which it was ORIGINALLY recorded.
.
Just my thoughts.
.
Brett
.
ps: Of SUPPORT, I hope.
.
0 -
Julie
.
Like MANY others ...
.
I wholeheartedly agree with you ...
.
This has been 'pet peeve' of MANY of us over the YEARS ...
.
If I recall, the matter has been raised on numerous occasions in the OLD 'FamilySearch' ("GetSatisfaction") 'Feedback' Forum; but, to 'NO AVAIL' ... NOTHING had been DONE.
.
The principle reason/suggestion/consideration as to WHY such may be inappropriate being, something like ...
.
The User/Patron doing the "Merge"/"Combine" is the one EFFECTING the ACTION, at that 'Time'; and, NOT, the ORIGINAL User/Patron who entered the "Details", at an EARLIER 'Time'; PLUS, the ORIGINAL User/Patron who entered the "Details", did so for ANOTHER individual/person; and, NOT, that for the 'Surviving' individual/person.
.
Which to me, personally, seems like, avoid doing what SHOULD be done ...
.
'Yes', the User/Patron, doing "Merge"/"Combine", is the one EFFECTING the ACTION of the "Merge"/"Combine", at that 'Time'; BUT, that said, they are SIMPLY "Transferring" the ORIGINAL "Detail", from an EARLIER 'Time'; as, they WANT such, transferred to the "Surviving" individual/person, in an "AS IS" state.
.
The User/Patron EFFECTING the ACTION, of the "Merge"/"Combine", CAN later "Change"/"Edit"/"Amend", what they have "Transferred", if they so desire; which, would then be in their 'Name' (well, "Contact Name) ...
.
When EFFECTING the ACTION, of a "Merge"/"Combine"; and, ORIGINAL "Detail", from an EARLIER 'Time', is "Transferred", in as an "AS IS" state, that "Detail" should ALSO "Display", BOTH, the ORIGINAL "Contact Name" (User/Patron); and, the ORIGINAL 'Date' (of an EARLIER 'Time') - NOT just that of, the "Merger"/"Combiner"; and, the "Merge" 'Date'.
.
Even if there is CONCERN, why NOT also just INCLUDE a REFERENCE to the ORIGINAL 'FamilySearch Person Identifier' (PID) to which it was ORIGINALLY recorded.
.
Just my thoughts.
.
Brett
.
ps: Of SUPPORT, I hope.
.
0 -
I guess most of us have accepted there is no way this is going to change - especially as it had been the subject of many posts on the GetSat site. As you know, this situation also applies if, say, just a full-stop is entered at the end of a sentence in a reason statement. I find lots of my comments now attributed to another user, who has a shared interest in one branch of my family. At first I thought, "That's exactly how I would have worded that", then realised it was my wording!
There's no way I'm going to spend my time going back to re-attribute all the comments, now in his name, to mine - especially as the change log should show who originally inputted what. The merged record situation is a more difficult one to follow through, but I can't see a way around the problem.
0 -
I guess most of us have accepted there is no way this is going to change - especially as it had been the subject of many posts on the GetSat site. As you know, this situation also applies if, say, just a full-stop is entered at the end of a sentence in a reason statement. I find lots of my comments now attributed to another user, who has a shared interest in one branch of my family. At first I thought, "That's exactly how I would have worded that", then realised it was my wording!
There's no way I'm going to spend my time going back to re-attribute all the comments, now in his name, to mine - especially as the change log should show who originally inputted what. The merged record situation is a more difficult one to follow through, but I can't see a way around the problem.
0 -
Again, this is the result of the schizophrenic "Reason this information is correct" text. FS is trying use the same data item to perform multiple unrelated functions.
The field where you record the reason you are making the change should ALWAYS be presented to the person as a new BLANK field. The reason for a subsequent change will always be different from the reason a previous one was made. But when you mung it together with the reasons for a specific vital CONCLUSION, it scrambles things.
I had once made a change to an item and documented what that change should be made. Someone changed it back to what is was without changing the reason statement. I corrected it giving all of the same reasons/sources. They changed it back AGAIN without changing the reasons statement. So in the change history, every change had the exact same reason, except that for half of them the reason bore no resemblance to what they had actually done to the data.
The title for those fields need to be corrected to "Reasons this change is correct" and should always come up BLANK for each new change.
I agree wholeheartedly with Julia. Taking such useful data in the change history and mislabeling it is just plain silly.
0 -
Again, this is the result of the schizophrenic "Reason this information is correct" text. FS is trying use the same data item to perform multiple unrelated functions.
The field where you record the reason you are making the change should ALWAYS be presented to the person as a new BLANK field. The reason for a subsequent change will always be different from the reason a previous one was made. But when you mung it together with the reasons for a specific vital CONCLUSION, it scrambles things.
I had once made a change to an item and documented what that change should be made. Someone changed it back to what is was without changing the reason statement. I corrected it giving all of the same reasons/sources. They changed it back AGAIN without changing the reasons statement. So in the change history, every change had the exact same reason, except that for half of them the reason bore no resemblance to what they had actually done to the data.
The title for those fields need to be corrected to "Reasons this change is correct" and should always come up BLANK for each new change.
I agree wholeheartedly with Julia. Taking such useful data in the change history and mislabeling it is just plain silly.
0 -
I've upvoted Juli's post because I would like the result to be as Jeff suggests - a clear list of separate items.
What I don't want to see is just the straight retention of the existing scenario but with the old contributor details in a single box. My reasoning might be thought pedantic but is basically that when I merge two profiles, I am making a decision about that value - specifically I decide to carry it over to the new, merged profile. Granted it's a non-decision decision in most cases because it's the default, but nonetheless, I am deciding that it's worthy of copying. That's my responsibility.
But yes, that acceptance of the worthiness of copying shouldn't splat over the previous stuff.
0 -
I've upvoted Juli's post because I would like the result to be as Jeff suggests - a clear list of separate items.
What I don't want to see is just the straight retention of the existing scenario but with the old contributor details in a single box. My reasoning might be thought pedantic but is basically that when I merge two profiles, I am making a decision about that value - specifically I decide to carry it over to the new, merged profile. Granted it's a non-decision decision in most cases because it's the default, but nonetheless, I am deciding that it's worthy of copying. That's my responsibility.
But yes, that acceptance of the worthiness of copying shouldn't splat over the previous stuff.
0 -
Part of the problem is that the handling of merges in the change history is a little too simplistic. If a vital is slightly different between the two records being merged and the the value from the non-surviving record is chosen during the merge, the fact is that the actual vital in the surviving PID has physically been changed. So obviously that one piece of the merge in the change history for that PID must have a "Reason for the change". Since nothing was changed in the deleted PID, it's change history remains intact.
The problem is that you are making MULTIPLE changes during a merge and each one of them would have a different reason for the change. If the merge is really for true duplicates (as it should be), most of the reasons will be similar and rather trivial (e.g., the vital data was more complete or was in standard format where the value in the other PID was not). But there are other times when the values are quite different and a good reason would be necessary.
But having to enter a separate reason for each and every vital, conclusion, relationship, and source that is changed during a merge would certainly be a nuisance (even though each one would have SUPPOSEDLY been examine before and during the merge and a reason for its change surmised). FS has attempted to deal with this by using a SINGLE reason statement that can be populated with one of 4 canned statements that are very general in nature. But when you distribute that change among the individual pieces of the merge, it doesn't make much sense. The reason was for the merge in its entirety and attaching the generality of the whole merge to each piece of the merge is counter productive.
It might be useful in the change history to treat the merge as a "package" of changes (which it really is). You could mark the merge of the records in the change history with a reason and then each of the individual merge "pieces" could automatically have a very simple reason such as "part of merge of PID and PID" or something like that assigned to them. That would mitigate some of the extreme bloat that occurs in the change history logs when a merge that has a long and detailed reason statement has been made in the system.
I have noticed in the last year or so that many reason statements that you can enter for changes are not actually being made visible in the change histories at all, so they are still obviously a work in progress. But in spite of how valuable the change histories are for unraveling screwed up merges, they have continued to be confusing and missing valuable information over the past couple of years.
0 -
Part of the problem is that the handling of merges in the change history is a little too simplistic. If a vital is slightly different between the two records being merged and the the value from the non-surviving record is chosen during the merge, the fact is that the actual vital in the surviving PID has physically been changed. So obviously that one piece of the merge in the change history for that PID must have a "Reason for the change". Since nothing was changed in the deleted PID, it's change history remains intact.
The problem is that you are making MULTIPLE changes during a merge and each one of them would have a different reason for the change. If the merge is really for true duplicates (as it should be), most of the reasons will be similar and rather trivial (e.g., the vital data was more complete or was in standard format where the value in the other PID was not). But there are other times when the values are quite different and a good reason would be necessary.
But having to enter a separate reason for each and every vital, conclusion, relationship, and source that is changed during a merge would certainly be a nuisance (even though each one would have SUPPOSEDLY been examine before and during the merge and a reason for its change surmised). FS has attempted to deal with this by using a SINGLE reason statement that can be populated with one of 4 canned statements that are very general in nature. But when you distribute that change among the individual pieces of the merge, it doesn't make much sense. The reason was for the merge in its entirety and attaching the generality of the whole merge to each piece of the merge is counter productive.
It might be useful in the change history to treat the merge as a "package" of changes (which it really is). You could mark the merge of the records in the change history with a reason and then each of the individual merge "pieces" could automatically have a very simple reason such as "part of merge of PID and PID" or something like that assigned to them. That would mitigate some of the extreme bloat that occurs in the change history logs when a merge that has a long and detailed reason statement has been made in the system.
I have noticed in the last year or so that many reason statements that you can enter for changes are not actually being made visible in the change histories at all, so they are still obviously a work in progress. But in spite of how valuable the change histories are for unraveling screwed up merges, they have continued to be confusing and missing valuable information over the past couple of years.
0 -
Jeff's suggestion of a changelog reason of "part of merge of PID and PID" is exactly what I think should happen, but it needs to be part of a proper separation between conclusion attribution/reasoning and the changelog.
My post was prompted by a corner of my distant family where I found contributions by an actual other user. (This is highly unusual for me: 99.99% of the merges I do are because of index-based legacy twiglets, which lost any semblance of individual attribution a decade ago.) This user filled in the reason box for his conclusions, and I wanted to preserve both those reasons and the user's identity -- but the merge gave me no such choice. During the merge, I couldn't even see that there *were* reasons, never mind what they were, and the user's name wasn't visible, either. In other words, there is no method by which I can preserve this information and prevent it being overwritten by the utter falsehood that *I* contributed the conclusions, apparently out of thin air.
0 -
Jeff's suggestion of a changelog reason of "part of merge of PID and PID" is exactly what I think should happen, but it needs to be part of a proper separation between conclusion attribution/reasoning and the changelog.
My post was prompted by a corner of my distant family where I found contributions by an actual other user. (This is highly unusual for me: 99.99% of the merges I do are because of index-based legacy twiglets, which lost any semblance of individual attribution a decade ago.) This user filled in the reason box for his conclusions, and I wanted to preserve both those reasons and the user's identity -- but the merge gave me no such choice. During the merge, I couldn't even see that there *were* reasons, never mind what they were, and the user's name wasn't visible, either. In other words, there is no method by which I can preserve this information and prevent it being overwritten by the utter falsehood that *I* contributed the conclusions, apparently out of thin air.
0 -
"…it needs to be part of a proper separation between conclusion attribution/reasoning and the change-log…"
That is exactly correct. Although they can occasionally reference each other in useful ways, Reasoning and details on Conclusions are a totally different thing and have different uses from Reasons for why changes have been made in the change history.
By mashing these two different things together into a single item, FS has attempted to kill two birds with one stone. As a result, they just maimed two birds. It has muddied the water so much that that even experienced users can't quite use it in a way that makes sense. And the way it is used during merges is even worst.
0 -
"…it needs to be part of a proper separation between conclusion attribution/reasoning and the change-log…"
That is exactly correct. Although they can occasionally reference each other in useful ways, Reasoning and details on Conclusions are a totally different thing and have different uses from Reasons for why changes have been made in the change history.
By mashing these two different things together into a single item, FS has attempted to kill two birds with one stone. As a result, they just maimed two birds. It has muddied the water so much that that even experienced users can't quite use it in a way that makes sense. And the way it is used during merges is even worst.
0
