Relationship Tracking Bug
There is a subtle but significant bug in our tracking of changes to profiles.
The following is complicated.
We record and display a change anytime a profile is edited. However, edits to relationships involve two or more profiles. We still often record just one edit to one profile, the profile you were editing when you changed the relationship.
For example, if you add a wife to a husband, you are editing the husband's profile and we record this. However, you are also editing the wife's profile. We do not record this (unless you're creating a new profile for the spouse). We only record one activity item, for the husband.
This is not a bug. Although it's not ideal, we do not want to crowd activity feeds with too many items. Recording two items would be repetitive in most contexts. Anyone following your family's activity would see:
- You edited the marriage of Husband X.
- You edited the marriage of Wife Y.
Moreover, many more profiles could be affected if Husband X had existing children. A series of checkboxes on the profile-creation form would have enabled you to say that the new Wife Y is the mother of Child A, Child B, Child, C, etc. All their mothers could be edited in the one addition of Wife Y to Husband X.
The limited way in which we record changes to relationships is less than ideal, but it is intentional.
Lots of activity feed items would make it easier to follow the history of changes but they do have costs. First, they crowd the activity feeds. If feeds are too crowded important changes may get overlooked. There is also a resource usage aspect. Although the space they take up in our database is minor it does add up over time. As the number of items grows, it takes longer to search them and it takes more server space to store them.
The most serious problem here, the real bug, is that changes to marriages and relationships can get attributed to the wrong WikiTree member. This was a more serious problem before November 2014, when we implemented a patch for it.
Our diff pages show the difference between a profile at two points in time. It's supposed to be before and after an edit. But that's not exactly what it is. It's the difference between the edit now and the last edit that was recorded.
If we don't record a change, we do not record how the profile looked at the time of the change. If we don't record a change when a marriage or relationship is edited, it will look as if the marriage or relationship was edited along with the next change, even though it was made before it.
The bug patch solves this in most cases, except:
1.) Very old changes to marriages. If a marriage edit was made prior to about 2011, it may be mis-attributed.
2.) The following obscure and unusual case: If you make a roundabout edit to a marriage, where the marriage edit is not shown on the diff thanks to the fix, but then make a direct edit to a marriage to a different spouse for that person, the diff for the marriage edit will show both changes. This only happens if the person has two spouses, if the first marriage edit was hidden, and if there was no interim edit (i.e. the marriage edits have to be back-to-back, one hidden then one shown).
- ↑ Technically you're not editing either profile. Marriages are stored in a separate database from the one for people.
- ↑ If you're creating a new profile for the spouse or parent, there will be a history item for each profile, e.g. "You edited the father for X" and "You created the profile for Father A." If you're making an existing profile the spouse or parent there is no new history item for this existing profile, just for the profile you're editing. See above.
- ↑ One case where we do record two items is with merges. It's important for merges because it's such a major change to both profiles. Tracking them is essential.
- ↑ A less significant problem but one that member's would complain about: it would over-count some contributions, e.g. one edit could look like 13 contributions. That could be overcome but all this adds complexity.
- ↑ Technical note: The resource usage is much more serious than just the space for the history item (rc item) itself. If we want diff tracking to work, we need to save the entire version of the profile when the edit was made. If the spouse of a man with 10 children is changed, that could be 13 full revisions, just for one edit.
This page was last modified 17:51, 31 December 2014. This page has been accessed 11,260 times.