Rejection of Merger Because Dates Don't Match

+15 votes
Many times I have proposed a merger between two individuals who have the same name and the same parents and whose lives overlapped in time. These mergers have been rejected or postponed by one of the profile managers because their specific dates: birth, death, or marriage don't match. I try to say that this doesn't matter as it is better to merge the profiles and to indicate in the profile that the date is in doubt, but this does not always convince the other profile manager that the merger should take place. I think that I am on the side of the angels here, but there needs to be a better way to spread the word.
WikiTree profile: Rachel Rawlins
in Policy and Style by Henry Chadwick G2G6 Mach 4 (49.3k points)
I totally agree. Slight differences should not hold up a merge. Can only take them one at a time though.

3 Answers

+8 votes
Best answer
If a merge is proposed where information does not match, SOMEBODY has to do the hard work of reconciling the inconsistencies. You can hope that someone else will do the work, but if you want the merge to go through, the best course is to do the work yourself, figure out what the correct information should be and provide sources for it. And to really ensure that the merge goes through, put the correct, sourced information in both profiles so they match. That makes it a no brainer for the managers/trusted list to approve the merger.
by Chase Ashley G2G6 Pilot (245k points)
selected by Maggie N.

In many cases, the sources themselves do not agree on the correct dates, but that should not hold up the merge. It is very unlikely that the same parents would have two or more children with the same name who overlap in time. Imagine the difficulties that this would cause. What I am trying to say that when this situation is discovered the merge should always be approved. Questions about sources should be explained in the biography section of the profile and resolved, if possible, at a later time. This would conform to the principle that one person should have one and only one profile in Wikitree. 

On the question of who should do the rewrite, I believe that, in general, it should be the person who implements the merger, unless there is good reason to believe that someone else is more knowledgeable, in which case that person should be asked to perform the rewrite.

Good points, Henry. I think I was conflating approval of the merge and doing the merge itself. Once it is obvious that it is the same person, I see no reason not to approve the merge even if some of the information is inconsistent. The merge itself should only be completed, however, by someone who has done the research necessary to know what to do with the inconsistencies.
Agreed, but it is frustrating to come across situations where this philosophy is not adhered to and the merge is rejected.
You can only do the hard work if the other profile is open to do so! I just waited the 30 days to be able to merge two profiles that were a few years less than 200 years old, the other (inactive) manager and I had been in friendly correspondence yet he chose not to add me to the trusted list or do anything himself to make the merge go ahead, despite me being a direct descendant of this person in the profile. Another merge involving her duplicate husbands had already happened. I had to wait the full 30 days for him as well (he never came up as a possible match due to a 10 year difference in estimated and actual birth dates when I created mine), I'd hoovered up his descendants that had been orphaned at the time of the merge and my profile for the wife was already fully sourced, so it was just a waiting game.

There are numerous well documented examples of families with living children with the same name, some early French Canadian families come to mind. This is not to dispute your general point but just to caution about facile assumptions without the supporting evidence.
Is this really true? How does such a family get along in ordinary life? If all four of my sons were named Michael, for example, and I say "Michael, go walk the dog", what happens?

A question that could be asked of George Foreman contemporaneously, his 5 sons, all named George, go by various (unofficial) nicknames which could conceivably shed light on how 17th and 18th century families got around.


Addendum: A few further cases from Germany discussed in

  • Blätter des Bayerischen Landesvereins für Familienkunde, 68. Jahrgang 2005: Georg Paulus, „3 Söhnlein namens Johannes – Zum Phänomen der Namensgleichheit von Geschwistern„
  • „Leben und Sterben vor, während und nach dem Dreißigjährigen Krieg in der Gemeinde Fambach (1559-1703). Eine Kulturgeschichte anhand des ältesten Kirchenbuches von Kurhessen-Waldeck“ von Dr. Kai Lehmann
  •  All males of the House of Reuß are named Heinrich, starting in 1200 until today.
+10 votes
I find that sources help. When I've had that experience, I make sure my profile is well sourced, and then propose the merge again, pointing out the sourced information.
by Leanne Cooper G2G6 Mach 3 (35.3k points)
That's excellent advice. The best way way to prevent stalled merges is to add sources and sourced content to profiles. Many of the profiles most in need of merges cite no sources (in spite of having been created by several different contributors) or have no sources of any value (for example, they might cite a contributor's gedcom or an abandoned online family tree).

Even with sources, you may run into contributors who refuse to complete merges because they are hung up about something minor like the difference between a date of "about 1709" and a date of "before 1712." That requires patient explanation... :-)
Pointing out the benefits, i.e. how well sourced and connected your profile is and therefore how many more generations will show on their family tree when they merge with your ancestor might be worth a try?
+4 votes
Thank you Henry!

I'm glad someone finally said it.

This is not a trivial issue because a lot of our "customers" google an ancestor expecting the best out of Wikitree and instead of landing on one of our very finest well sourced profiles they land on a second rate profile that has been stuck in a pending/rejected merge-war for months. It reflects poorly on us all. It is one thing to hold up a merge because it actually needs more research or consensus. It's another thing entirely to drag out mergers unnecessarily.

I personally would prefer if we nominated a few people who could expedite mergers upon request on G2G that same day rather than waiting 30 days. There are a lot of cases where a wait really doesn't add anything to the process. Some mergers are obvious.
by R B G2G6 Mach 3 (39.7k points)
I always find that if you post sources for certain facts on the profiles, the merges go through much faster ~ !
I personally believe we should respect the 30 day waiting period, however frustrating this might be.  Life happens to us all, people travel for work, business, or maybe family emergencies crop up which mean that tending to profiles has to take second place.
The issue is not the 30 day waiting period. It is when one of the profile managers concerned specifically rejects the merger.

Sources, when located, should be added to the merged profile, but my point again is that there should not be two profiles for the same person regardless of sources.

Related questions

+5 votes
1 answer
184 views asked Mar 5, 2015 in WikiTree Tech by Henry Chadwick G2G6 Mach 4 (49.3k points)
+5 votes
1 answer
134 views asked Dec 9, 2014 in WikiTree Tech by Susan Tye G2G6 Mach 2 (22.4k points)
+3 votes
1 answer
63 views asked Sep 6, 2021 in WikiTree Help by Keith Taggart G2G Crew (520 points)
+1 vote
2 answers
112 views asked Sep 3, 2021 in WikiTree Tech by David Wilson G2G6 Pilot (104k points)
+8 votes
3 answers
+4 votes
2 answers
177 views asked Jun 2, 2019 in Genealogy Help by Andrew Ross G2G6 Mach 3 (30.8k points)
+3 votes
1 answer
116 views asked Apr 27, 2019 in The Tree House by Kristina Adams G2G6 Pilot (246k points)

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

disclaimer - terms - copyright