Question

"An Unmerged Match is a temporary state. You should work with others to resolve the open questions and either complete the merge or reject it."

This is just a gentle reminder for all. An Unmerged Match is meant to be a temporary limbo while serious doubts are clarified.  It is not a means to indefinitely delay or obstruct a merge.

If two profiles generally appear to represent the same person (they have the same spouses or kids or parents), the merge should be completed with the best information available, and conflicting information should be highlighted in the biography section.  Alternative spelling of surnames can be recorded in Other Last Name(s), so that any of several alternative spellings can be used to search for the individual.

The problem with these over-delayed Unmerged Matches is that as long as there are two profiles for the same person, there are likely to be duplicate spouse, parent and children profiles created as well.  The longer we wait to complete the merge, the more work we have to do to straighten out additional duplicates that might have been stopped with the initial merge.  

Please check http://www.wikitree.com/index.php?title=Special:BrowseMatches&type=matched&order=datedn and especially the Unmerged Matches Initiated by Me to see if there are merges you should be completing. Remember, the information we have contributed to the collaborative WikiTree is no longer mine or yours, it is the whole world's family WikiTree.  Let's keep it trimmed up by merging multiple profiles for the same person, even it there are still questions on the details.  

 

Comments

So, what is the sugestion to handle a lineage where the parents listed in one set of  duplicate profiles are from a lineage in a published book and the documentation for that publication is research done long before the "modern" era of genealogy. The source researcher apparently took two men of the same name and, using very few paper records, made a parental connection.

The problem now is DNA testing infers the lineage is incorrect due to different yDNA haplotypes for male "descendants" of those parents. There are no non-paternal events documented in the two lines.

One of the profile managers desires to not accept the more recent evidence.

---

Hi Michael,  This happens all the time in the Smith families; believe me!

The proper course of action is always to complete the merge if there are two profiles for the same person.  One profile per person is the WikiTree way.

The best information available should be used in the vital statistics area of the merged profile.  Additionally, one of the Templates:  http://www.wikitree.com/wiki/Templates  should be added to the top of the Biography section to indicate the conflicting information.  For instance, if the parents are questioned, please highlight this question with the Template:UnverifiedParents.  It is very important to complete the merge and indicate the conflict in the text.

If there are only two matching yDNA tests, you can't tell which, or if either, line is properly attached to the common ancestor forefather. If there are more yDNA tests that match one or the other test, it may be clear that one brother's descendant is a match, but the other brother's descendant is not. You need to use traditional research methods to locate more accurate or better documentation for the non-matching line.

I would be glad to look at your common ancestor if you think it might help.  You should also look for additional yDNA tests for descendants of the Common Ancestor's other sons or grandsons.  

Answer 1

Kitty, I agree it is important to tackle clean up sooner rather than later.  There seems to be some huge clean up required under the unmerged matches.  Out of curiosity, going from Oldest (appears to be 2012 entries) to most recent (2014), it looks like there are 900-1000 just for 2012.  Many of these are Red, Green & Yellow - some are "matchbot".  Perhaps there is or was a system glitch or some other issue for which the respective Profile Managers were not notified - and/or not appearing on "initiated by me" lists, or they are just not  "aware" that  a merge should be initiated or rejected..

 

If there is already an ongoing "project" to handle this, I would be willing to devote some time to sending individual messages to Profile Managers and/or posting the same message on the "matched" profiles. (which would, I think, determine the active from inactive).  My "personal opinion" is that the "Managers" probably know best and probably could quickly determine the match or reject.

 

In Spot checking, I found many appear to be a match with some discrepancies, many looked to be Gedcom imports and some may no longer be active, but the privacy settings on some do not allow for an upfront determination, thus the thought of going direct to the profile manager.

Answer 2

Kitty,  I was just going to post something on this subject when I saw your question.   It is important that the person who puts the merge into this state continues to work the issue.  If one of the profile managers is active, you should make sure they are aware and ask if they need help.   I think there are a lot of profiles in this state incorrectly, it was just easier than doing the work to figure out which profile had the correct data, or documenting the differences.

Comments

So what should I do, if I come across two profiles that are obviously supposed to be the same person but have major discrepancies?

If I propose a merge, somebody else can make it an unmerged match, but more likely somebody else will just reject it.  What then?

Don't tell me I should work on it myself.  It's of no interest to me, I don't have access to the relevant resources, I only noticed it in passing.  Perhaps I just spotted them in the "Find" output while searching for somebody else.  I'm trying to do something else and the job will never get done if I chase every loose end.

But there's another reason not to work on it.  That's because, if I figure out how to complete it, and propose a merge, I'll then have no control over how it gets completed.  Quite likely somebody else will just accept the system defaults.  Then I'll think I wasted my time.

If I want to work on merges, I'm better off picking something off the Pending list that's already got default approvals in spite of conflicts.  Then, if I can figure out how to complete it, I can at least go ahead and do it.

And please don't mention PMs.  If they were going to do it, they'd have done it.

What I do find is that WikiTree is training me to ignore things that need attention.  Anything that's not immediately important, turning a blind eye and not getting involved generally seems to be a wiser policy.  I've caused myself too much trouble by looking at stuff I had no need to look at.

---

RJ, alternatively when you stumble across these unmerged matches and don't want or can't work on the research yourself, you could attach a g2g post to the profiles drawing attention to the need for resolution. In such cases I also post messages on each of the profiles, which alerts PMs and TL's to the existence of the G2G post.

---

Well I had a look and I had 175 Unmerged Matches Initiated By Me.  Don't blame me, I only found them.  None of them is of any particular interest to me - I do things because they need doing and somebody has to.

I don't think 175 g2g threads would be too welcome - these molehills need flattening, not turning into mountains.

I turned one into a proposed merge, but it got rejected.

So I picked one to start a thread on, but that one got rejected as well.

Rejected merges are a problem.  Somebody has to make the decisions.  Having asked for somebody to go ahead and make a decision, we can't just refuse to accept it.  And here the duly constituted entitled and empowered authorities have decided that the profiles are different people.

But this then means the genealogy around them is incoherent and can't be fixed.  The two profiles can't sensibly be placed in the same family, and they can't be placed in two different families.  Usually they will end up in two partial clones of the same family, which kind of co-exist in the same place at the same time.

On the whole it seemed best just to leave them flagged and hope they stayed like that until a Leader came round to do some expedited merging.  Then maybe something slightly useful might have been achieved by not just doing nothing.

But of course this is where the new scheme comes in.  Previously there was no good excuse to drag a Leader into these merges, whereas now it seems to be compulsory.  So now if anybody wants to get them completed, there's a less hazardous route and a good chance of getting them done.