How do you protect profiles from improper merges

+21 votes
About once a month I come across a situation where there are multiple men all with the same name, all born within a 5-10 year period of time that have been conflated all over the internet, but more importantly, here on WikiTree.   I have been going through this and even created a free space page to document all the different men.   Yes, 13 men with the same name born in a 14 year period of time.   It all started with a merge that was proposed incorrectly (they were not the same men)  In working the issue, I found that we already had 3 men conflated on one of the profiles.   I am concerned that once we get this all cleaned up, someone will see those false lineages on other sites, start merging profiles and we will be right back where we were.   These are just "common men" from the 1850s, so there is no project to protect them, nor do I think that a project needs to be involved.

What I would like to propose is that there is a type of "rejected merge" that "permanent".    The error message would indicate that a leader has to remove the rejection.   Does that sound like something we should think about?
in Policy and Style by Robin Lee G2G6 Pilot (665k points)
Just call it something like the Arborist Project

The problem with a Research Note or other warning is that a lot of people apparently don't read what they're working on.
Robin, thanks for raising this issue. The suggestion of a 'permanent rejected match' is an interesting solution. Potentially it seems like it would be much simpler than project protecting all the profiles that might need this type of protection.
I like your solution Robin.

10 Answers

+14 votes
Best answer
The easiest solution is to project-protect all of the profiles. That is easy enough to justify when the profile clearly fits into a project like Mayflower or Notables, but I agree that it is more of a challenge when there is no clear need for project involvement.

I have project-protected some profiles under the United States Project for reasons very much like this one. The main function of PPP is to prevent bad merges, and it should be applicable to any profile that is subject to bad merges. If these are U.S. people (at any time, not just post-1776), I can offer the United States Project as a profile manager. I hope that other broad-scope projects could provide assistance for other regions of the world.
by Ellen Smith G2G Astronaut (1.1m points)
selected by Jillaine Smith
+18 votes
if not a "permanent rejection" , perhaps a new project, that is made Project manager for the frequent "victims" which can be put under PPP , closely monitored by maybe the Arborists?
by Eddie King G2G6 Pilot (534k points)
+10 votes
At least for the moment, I think the best thing you could do is add a Research Note to the profile(s) identifying which ones with same/similar names are not duplicates and explaining that there is conflation of data on this or other web sites.
by Dennis Barton G2G6 Pilot (385k points)
Yes this is what I do ... use Research Notes header to indicate which 2 profile numbers and names (on both profiles) that should not tbe confused with each other. This lets other members know that someone is aware of the similarity, but has ruled out because sources indicate that they are NOT duplicates.
Just the other day, a profile I had put a research note on saying not to merge was merged anyway, and the person didn't even bother with any post-merge cleanup!
Lois, Julie, Robin, I certainly wouldn't claim it's a guaranteed solution to the problem, particularly if you're in the sights of a "Whatever-Thonner" who's watching the clock instead of reading the profiles.  But it's a possible mechanism available right now that might deter some, and might help protect the similar profiles.  Can't hurt!
I have to say here that most of the really bad merge proposals I've seen, were not made during any kind of -thon.  Some people just don't pay attention.
+16 votes

I feel your pain. I've been working days on a similar situation!

To answer the question - When I needed to PPP a profile temporarily to control the direction of a merge, I've just added a note & signed it (~~~~).
When I had two profiles that needed permanent PPP to prevent them being merged together, I looked into whether or not the Arborists Project could manage that. I forget whether it was the project that declined or Team Wiki, but it was a "no go" because the project did not have a project account and project box.
Considering the number of times this is an issue, would it be worthwhile to have a mini-project with a project account & project box that could be employed when a profile (or a pair of profiles) meets the criteria at for PPP - except for there being an existing project.
by Liz Shifflett G2G6 Pilot (420k points)
+9 votes

Generally, I would go in the direction of what Dennis Barton suggested: a research note. That's usually sufficient. I think that can be the best way to ensure that similar profiles, once disambiguated, don't get entangled or mashed together again. Here's my example: Eilbeck-9 & Eilbeck-10. Those men (and their wives, Mary & Mary Ann) were mashed together on other sites, which made for some confusion. Surely not as confusing as your situation

But since this is 14 very similar men, I think that your initial route is probably better, provided that it's linked on each of the profile pages:

a free space page to document all the different men 

One additional work-around type solution that may help. The real risk is the loss of data in merges. So I'd suggest ensuring that the "final" version of each profile is archived in the Internet Archive's Wayback Machine, then also link those archives on the Free Space Profile that you've made. That way, if the information is merged away, a future genealogist might find not just breadcrumbs that you've left behind, but the whole of your research in the Internet Archive.

Still, you're concerned, and I understand why:

I am concerned that once we get this all cleaned up, someone will see those false lineages on other sites, start merging profiles and we will be right back where we were. 

In my view, the real issue is that many folks on WikiTree (and elsewhere) aren't very conscientious in their quest to contribute. Provided that your documentation was thorough and convincing, this would not be a problem if people acted conscientiously, taking the time to read the profiles and check the logic. So your proposed solution seems to be creating a barrier to stop any reckless or non-conscientious behaviour:

What I would like to propose is that there is a type of "rejected merge" that  [is] "permanent".    The error message would indicate that a leader has to remove the rejection.   Does that sound like something we should think about?

It's an interesting idea. I would suggest that it might be better described as "locking"  a rejected merge. That isn't "permanent", but rather requires a key to override the lock. 

I would ask, what criteria and/or procedure would need to be met and followed in order to make the rejected merge? And, likewise, what criteria and/or procedure would need to be met and followed to "unlock" a rejected merge?

So yes, I could see utility in your suggestion. But there's a question of how it would be applied.I don't have a good metric or threshold, so perhaps you can address that.

P.S. Sounds like you've put on a valiant fight and have earned one of these.

by anonymous G2G6 Pilot (127k points)
+6 votes

In general I would agree that PPP is the best defense. It isn't a guarantee, but if the project is diligent about reviewing their daily feeds it can prevent a lot of damage.

The biggest problem is that PPP requires the profile to be over 200 years old or notable. If the profiles don't fit that parameter, they can't be PPP under current guidelines. I have often PPP'd a profile temporarily to ensure the correct LNAB, but then removed it after the merge was completed if it didn't fit all 4 requirements.

If an exception can be made to the PPP guidelines for this issue, it would give us access to this tool to help prevent these types of merges.

by Joyce Rivette G2G6 Mach 9 (90.2k points)
+6 votes

I'm thinking about how the {{Died Young}} sticker is applied as a visual alert to avoid situations where dead children are supplied with spouses and children years after their deaths. (Yes, I've seen it happen.) Perhaps a conspicuous sticker that could convey something like "Conflation alert - see Research Note for details" would be of help.

There are of course the Research Note Boxes, but I think they are so big and ugly that I for one avoid using them.

by Leif Biberg Kristensen G2G6 Mach 9 (93.2k points)
+5 votes

Are you profile manager for any of these? Certainly you can reject a merge of any file you manage? You are certainly not an uncooperative manager that has to be reported. Have you sent personal messages to the people who keep fooling with the profiles? There should certainly be some sort of stop-gap measure to prevent abuse !!
by Daniel Bly G2G6 Mach 5 (50.0k points)
No, I do not manage them, they are profiles that was working to help another member.
+8 votes
Besides adding a research note, if the risk of a wrong merge is particularly great, I add a short statement in bold above the Bio heading with a forward reference to the research note - something on the lines of “Caution: please do not confuse ... : see Research Notes below" or "Caution: there are a number of people with this name in this period and care needs to be taken to keep them separate: see Research Notes below".

I have seen one or two profiles where others have put warnings in red above the bio heading.
by Michael Cayley G2G6 Mach 9 (92.4k points)
+2 votes
Marking repeatedly proposed and rejected merges sounds like a good idea, but marking anything as "Permanent" could lead to errors due to premature or inadequate investigation.

A major problem is contradictions in data that have been perpetuated over time, assumed correct but not, and still no agreement in absence of original or even new data, which could actually turn up anywhere in the future, even detection or transcription errors.  In two cases encountered recently, the original document was inaccurately transcribed, apparently at a courthouse, and people kept assuming the inaccurate transcription was the final truth when it wasn't. In one case, the truth was in the original handwritten document, and the error was in the transcription of the document, and there are far more than enough of those around, for any possible number of reasons including fumbles or just plain haste or impatience.

While marking repeated rejections seems like a very useful classification, "Permanent" is an extreme word, where as "Rejected in the Past" may be a more precise and explanatory description, and still allow those who like to solve enigmae to still investigate or even publish the issues prompting the repetition of the requested merger.

Local and contemporary namesakes have been a huge problem causing repeated errors in assessment over time, relaying to descendants and descendants of namesakes, perpetuated.  Those proposing merges might be notified by a clear, automated message that the merge was proposed before, along with the reasons for its rejection/s. Otherwise, you can even have personal investment in false family heritage claims getting what they want, even covering the truth with misconceptions. "Settled" when it's not really. However, "Merger Rejected in the Past" can alert everyone from the start, and along the line if it proceeds, that something more than casual glances are needed, and it might even stop proposed rejections in their early stages if those proposing the merger look at the reasons for the past rejections, and drop it there.  That saves judges from having to hear the case where they are not necessary.
by Blake Finley G2G4 (4.2k points)

Related questions

+5 votes
1 answer
133 views asked Sep 16, 2019 in WikiTree Tech by Robin Lee G2G6 Pilot (665k points)
+3 votes
1 answer
+6 votes
3 answers
151 views asked Sep 30, 2020 in Genealogy Help by Ed Visser G2G Crew (760 points)
+3 votes
2 answers
+55 votes
7 answers

WikiTree  ~  About  ~  Help Help  ~  Search Person Search  ~  Surname:

disclaimer - terms - copyright