Rejecting unmerged matches?

+10 votes
196 views
I could use some clarification.  My understanding of the unmerged match is to create a connection between two profiles that may be the same person, but there is not enough information to move ahead and merge them.

I've had several unmerged matches rejected because there was not enough information to merge them.  I would think that the rejection should only happen once there is enough information to prove that they are not the same person.

But maybe I'm not using the Unmerged Match correctly?  Thanks for any guidance.
in Policy and Style by M Cole G2G6 Mach 3 (34k points)
retagged by Robin Lee
Good question! I thought the same thing.
I think it's bordering on rude to reject an unmerged match in these conditions, unless the rejection comes form a newbie (or, if the person who rejects the match provides clear evidence that the profiles must not be merged).

4 Answers

+7 votes
 
Best answer

I agree with your overall assessment, M. Here is the relevant style guideline for unmerged matches.

Basically, if you believe that 2 profiles represent the same individual but have data discrepancies that you estimate will take more that the 30-day merge-approval period to research, you should set them as an unmerged match.

The unmerged match should only be removed when it has been researched thoroughly and one of the following 2 conclusions has been reached:

  1. If the 2 individuals are determined to be the same person, the unmerged match should be removed and a merge initiated
  2. If the 2 individuals are determined not to be the same person, then a rejected match should replace the unmerged match.

That's my opinion on how to use unmerged matches!

 

by Lindy Jones G2G6 Pilot (208k points)
selected by Robin Lee
And in cases where a little research shows that not only are the two people not the same person but didn't even live within a hundred years of each other, I wouldn't even reject the match; I'd remove it entirely (after making sure both profiles have dates and sources so they aren't going to show up in each other's suggested matches later). John Smith born 1883 in Knox County, Tennessee doesn't need a rejected match with every other John Smith in the database, just the ones that he's likely to be regularly confused with.
The only thing I would add is that an unmerged match should also be a TEMPORARY state.   In other words, when you put it in that state....you are saying that you have determined that they cannot be merged, yet and you will do the research.
Good points, Sharon.

The main point for merging and matching is that the profiles need further research, whether they turn out to be one or two individuals.

And as you note, rejected merges can become almost useless when the individuals have often-used names.

The general guidelines already state that an unmerged match is supposed to be a temporary state, Robin. But, in genealogical terms, temporary can realistically be years! To me, it's preferable to leave an unmerged match for as long as it takes to research it.

Also, you mention what is probably the main problem with our use of merges and matches. Too often, they are proposed by managers who do not intend to do the research themselves. I say, "Don't start what you can't finish!"
I don't agree that you should only make an unmerged match if you're willing/able to do the research.

Let's say I'm going through the merges that have passed the 30-day wait limit, and I see a proposed merge where one profile has a birth year and parents but no spouse or children, and the other profile with a close birthdate and place has a spouse, and children but no parents. They could be the same person, but it's entirely possible that they're two different  people of the same name who lived in the same area. There's nothing in the bios or the listed sources to support either merge or reject. Neither manager approved the merge (and obviously neither rejected it).  It's also a region that I don't have access to sources for, or I simply have no interest in researching this particular pair of profiles.

So, should I therefore leave them alone, and hope that no one will decide to blindly merge the two, when an unmerged match (even if it lingers for years) might allow some later researcher to find the sources showing that they're actually first cousins of the same name?
@Sharon,

The issue is, if you do not do the research, who will?   Default approved merges already mean that the profile managers are not active.   Putting the profiles in an unmerged matched state is like tossing the merge aside if you are not going to work it.  I certainly agree that you could put a note indicating that the profiles need more research before merging, but, the reason we have so many unmerged matches appears to be that no one takes responsibility for "solving" the issues.

The Arborist project specifically works these kinds of merges, but, if they are not left for us to do....we think someone else is working them.
You point out another problem (from my perspective) with how we currently use the merges and matches features, Sharon.

I think many of us set a merge when we should be setting an unmerged match.

A proposed merge should mean that the research has already been done and that it indicates the 2 profiles do indeed represent the same person. A proposed merge shouldn't need additional research, just approval by the profile managers if they agree, or default approval after the wait period.

When more research is required, we should use the unmerged match to indicate that additional research is needed. That whoever sets the unmerged match should be willing to do at least some research is, of course, my personal opinion.

In your example, I would say yes, you should leave it alone (unless you plan to do the research). Without your doing any research, you have no reason to judge the merge either way.

Proposed merge, unmerged match, rejected match: whatever our actions regarding any of these states, we should define best practice to include OUR doing the requisite research before we set profiles to any of these states.
And yet, we have Matchbot.

The alternative view is that a proposed merge by a 3rd party is merely a heads-up to the PMs to have a look at something they might not have noticed.

I would also say it's a waste of time investigating anything if you aren't in a position to act.  If I want to spend time investigating a merge, I'll pick one that's already got approvals, not one where my conclusions are likely to be rejected out of hand.
And Matchbot's accuracy rate leaves a lot to be desired!

Yes, an otherwise disinterested third party proposes a merge (often without stating any useful evidence, beyond the obvious similarities), expects the profiles' managers to drop their current work to complete the merge, and walks away with no accountability. I don't see that situation as particularly helpful or collaborative.

If it wastes your time to research a proposed merge, unmerged match, or rejected match, then why bother to make such proposals? Does it not waste the profiles' managers time as well?

Today, when I was adding a person to the database, the suggested matches included two profiles of people whose birth and death dates were identical; the CLN matches, and the father matches. I'm convinced from the data that the two profiles are meant to be the same person. The only conflicting information in the profiles is the spelling of the LNAB, which are clearly variants.

Lindy, from what you say here, it sounds like you think that if I'm not willing to do all the research to confirm or reject this match and find the correct LNAB (even if it turns out to involve driving a thousand miles to check courthouse or church records), I shouldn't even bother proposing the merge, and I'm wasting the profile manager's time if I do propose it.

I disagree. By proposing the merge, I'm bringing this duplicate to the attention of someone who does have an interest in the profiles – the profile manager(s). If I just move on and don't propose a merge or match, the profiles are still probable duplicates in WikiTree that need research, only they're not labeled as such where someone can find them.

(It's like unsourced profiles: there's thousands of profiles without sources that don't have an Unsourced category, but that doesn't make them any less unsourced; it just makes it harder for someone to find that they need work. If I can't find a source, I can at least add the category; someone else might have better luck.)

We all should be willing to do sufficient research before we propose a merge or set an unmerged match. That doesn't mean we have to do endless legwork.

We compare the data for the 2 profiles, check any currently attached sources and references, and determine a course of action; I consider those actions to be research.

For the example you give, Sharon, I would set an unmerged match if I didn't want to do further research myself.
+5 votes
Your assumption is correct. The purpose of Unmerged Match is indeed to connect two profiles that might be the same person but that need more research to confirm or disprove this.

I've also seen it used to link two profiles that appear to be the same person but that have issues further up the line (for example, same birth and death date/place, same spouse, and same children, but one profile has John Smith and Mary Jones as the parents and the other has James Smith and Anne Watson), or where a merge of the two profiles needs to wait on the approval of the merge of a parent.

Note that ideally, Unmerged Match shouldn't be a permanent state. There are tons of lingering unmerged matches that have been untouched for four or five years, and quite a few on closer look turn out to be easily resolved. Some may indeed be unresolvable with the evidence available, but it's a good idea to revisit your unmerged matches regularly to see whether you can find any new information.
by Sharon Casteel G2G6 Pilot (106k points)
+5 votes
Often Unmerged Matches are created when the two Profiles obviously refer to the same person (e.g. they have the same name and are married to the same man), but have slightly different facts given (e.g. birth or death dates). I believe that these Profiles should be merged and the discrepancies noted in the bio. I don't see any value in keeping two separate profiles for the same person. As noted elsewhere, Unmerged Matches tend to linger forever.
by Henry Chadwick G2G6 Mach 4 (48k points)
Exactly, Henry. I have a match I have had to start again. I had proposed a merge from a profile I managed that was well-sourced to another profile with no sources, though with a wife and child in common. Because the other PM didn't do the merge, it hung around then was tagged as unmerged after 30 days, supposedly because the death dates didn't match. It can be so frustrating when other PMs ignore requests and don't acknowledge emails, then a merge is unmerged.

As you note, Henry, some additional research was needed. Unmerged match was the proper state at that time. Once the additional research resolved the discrepancies, then the unmerged match should be removed and a proposed merge set.

Fiona, after the 30-day period, if the other manager has not responded, you should send an Unresponsive Profile Manager request (if the profile is locked). If it is set to unmerged match, you can reset the proposed merge, then post a G2G help request or sent an email to WikiTree admin to request help with the proposed merge.

Thanks, Lindy. The merge has been re-set. The annoying aspect is that of the person who set the unmerged match had read my version of the profile, it would have been clear why the death dates were different.
My point is that Unmerged Matches may be appropriate when one is not sure that the two profiles refer to the same person, In this case, further research is required to clear up the uncertainty, if possible. But when the two profiles clearly do refer to the same person then they should be merged and conflicting facts noted in the bio. Wikitree is based on having one profile per person, even if some of the facts may be unresolved.
It will depend on how close those conflicting facts are. Birth dates a couple years apart and sourced from census data are close; birth or death locations in different states or countries may not be.

Either way, you don't base your choice simply on closeness of data; you have to look at the source citations and other reference, then maybe do a little additional research to decide why the discrepancies exist, if they are important enough to require more research, and if they indicate 1 or 2 individuals (or even more, if conflation is present in either profile).

For the most part, we probably do this intuitively, so it may sound odd when we write out the steps or procedures. And each of us uses his/her own judgment, so we may see slight variations in how others do or describe the steps. As long as we are conscientious about our work, we'll get the job done!
+5 votes
There are conflicting instructions.
It's suggested that you should use an unmerged match if you aren't sure they're the same person.
But it's also stated that an unmerged match signifies your agreement that they are the same person.
It's also said that an unmerged match is temporary.  But ignorance might not be temporary.  Many questions can never be answered.

What we can say is
- "give me time" makes no sense on an open system with thousands of users.  Who's asking who, and why them?
- the system grinds to a halt if people act because they don't know.  Because there's always somebody who doesn't know.
- we must assume that if a merge is left pending it's likely to get completed by default.  It's no use saying it's not automatic.
- a system designed for PMs can't work for random 3rd parties.  Because nobody knows what needs them to do it.
by RJ Horace G2G6 Pilot (562k points)

I don't see the conflicting statements in the Unmerged Matches section of the style guide, RJ. Are you referencing a different page?

The guideline does say unmerged match is a temporary state. To me, that implies that whoever sets the unmerged match will do the research. From his/her point of view, however, he/she may simply be alerting the profile managers to the situation, and expecting them to do it.

But the profile managers may have other work that they want to complete; so the one who set the unmerged match should not expect immediate - or even timely - response to his/her action. Thus, temporary is only relative to whether or not anyone will do the work.

All of my comments on this topic are, of course, my idealized view of collaboration; they may not represent - or even work in - the real world!!

Related questions

+27 votes
1 answer
+10 votes
1 answer
176 views asked Jun 5, 2014 in Policy and Style by Anonymous Knight G2G6 Mach 3 (35k points)
+9 votes
2 answers
+24 votes
6 answers

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

disclaimer - terms - copyright

...