Unmerged Matches - permanent?

+17 votes
713 views
Unmerged Match option is being routinely used as a permanent solution to take no action.  WikiTree should consider having these reset automatically after 30-90 days.
in Policy and Style by Living Anonymous G2G6 Mach 5 (51.5k points)
retagged by Ellen Smith
Where are you seeing it used this way? Please provide examples.
Mikey, I went looking to see what you're seeing. Looks like you're working on the db_errors project and tracking down old unmerged matches. I found one from 2013  

I don't think these old unmerged matches are being used as permanent status. I believe that the profile managers have ignored them.

When we see these old unmerged matches that are clearly the same person but have no explanation for why the unmerged match was chosen, we could repropose them. I did one just now and added this to the explanation:

"Reproposing a three year old unmerged match. If you feel these two are not ready to be merged please provide an explanation. Thank you."
I find them on my own ancestral lines and the db_errors work.  I don't go intentionally looking for these, and haven't kept track.  I know I can reset and re-initiate a merge for any I come across.  I have done some.  And on others, posted messages (for what that's worth).  But, it would be better if there was a process in place for handling this.  Ignoring them, to me, is making it permanent (it's just semantics).

If programming changes to make the site software automatically do something are too complicated  to implement, or not wanted by TPTB, then it could help to a degree to just specify a maximum time allowed so when we do come across these, we have something to back up our assertion that it needs to be reconsidered. Then maybe Ales could also add a check for unmerged matches older than X days if the data structure allows checking that.
"Ignoring them, to me, is making it permanent."

One could say this about any aspect of a wikitree profile. Ignoring a profile makes everything on it "permanent" -- including empty data fields, Unknown LNABs, citation-less claims, etc. etc.

I guess I just don't interpret all this to mean permanent; to me, it means there is yet more work to be done.
I wish I could include a reason when I propose an unmerged match -- I can do it when switching a merge proposal to an unmerged match, but when proposing the match from scratch I have to manually leave notes on both profiles. There's always a reason when I don't go straight to suggesting a merge -- parents are different, location information's too sparse to be sure, birth/death dates match but wife and children are different, etc. -- and it'd help the profile managers if the "someone set an unmerged match" message also said "because they have the same birth and death dates but different parents" or "they're both John Woods who married Mary Smiths in the same timeframe, but with such common names and no location information I'm not sure they're actually the same people" or whatever.
Sharon, you're not alone. I and others have made repeated requests for this feature-- for Unmerged Matches as well as Rejected Matches. I guess there just hasn't been sufficient Voice to convince Chris to make the change.

Until then, we have to take the extra step of posting individual comments on both profiles. Very frustrating.

9 Answers

+15 votes
Instead of an automatic reset, some study should be done. I use this category for merges that may be correct but have major problems, same birth death, differing parents, or same parents differing siblings or birth death, etc. Too much conflict to easily resolve. Hoping that their PMs would help solve the problems.

 These should not be reset to proposed merges.
by Tom Bredehoft G2G6 Pilot (209k points)
Maybe they should generate an automatic 30 (or 60 or 90) day reminder: "Set as unmerged match xx days ago and still nothing done."

30, AND 60 AND 90 would be good.  Even better if the 90 day reminder included notice that indicated some action would take place (auto-reinitiate merge, or notify a leader, or _?_) after 14? more days.  And/or, if ones older than 90 days could then show up in db_errors.

+9 votes
Is there a way of seeing how many unmerged matches there are?
by Esmé van der Westhuizen G2G6 Pilot (148k points)
Over 29,000 total.   You can see ones for a specific surname, or ones on your watchlist, by carefully choosing the correct options on the page that comes up when you click Find then Pending Merges in the top menu.

But number is not the most important consideration.  These lingering, unmerged duplicates are a hinderance to improving the tree and removing errors (not limited to errors found by the db_error program).
OMG, it's statistics like this that make me SERIOUSLY wonder what I'm doing here trying to help out.  Maybe I should just go back to doing my own family tree for my own purposes and forget about trying to work with a broken system.
+8 votes

I have found many rejected matches which are, after comparision, matches.

When they are both unmanaged, I could perform the match, but when they are managed, I deleted the rejection which turns them back into unmerged matches with a message to the profile managers. My message was:

 

detected by Database Errors Project

Error: 160 Duplicates between global tree and unconnected

 

 

The falsely rejected matches are a more serious problem then unresolved unmerged matches. I appears that excessive caution was used to reject the match. Or perhaps the merge process was too complex or time consuming to completed.

by Doug Henderson G2G6 (9.9k points)
+9 votes
I have a case where an Unmerged match may remain "permanent".

I've done research on a line that makes the case for a certain person to be another certain person. I *think* I've made a strong case but descendants of this person refuse to believe their ancestor was involved in the controversy I describe. And they argue (without sharing their sources) for a different second marriage. I've shared my theory as a separate profile. I've marked it as an Unmerged Match with the other profile.  It's going to stay that way until one side or the other can confirm their/our respective claims.

See:

 http://www.wikitree.com/index.php?title=Special:MergePerson&user1_name=Hicks-2968&user2_name=Hicks-2716&action=compare
by Jillaine Smith G2G6 Pilot (907k points)
Wow, that's a juicy tale! I wonder if there are some court (divorce) records that might prove the case?
Agree that it's a fascinating dig- up of a story !

The sources on the other match are weak; this should be merged eventually.
The sources on the "real" Moses Hicks/Hix aren't weak as much as they are missing. I'd really like to see them, but the researchers -- at least about ten years ago -- won't share them. I'm not willing to complete the merge until both sets of sources are examined. My case is strong but it's also largely circumstantial.  It has its own weaknesses.  It's missing a marriage record of Lavinia Doolittle.  It's missing the birth record of her daughter who married a Brownell.  It's from New York State during a time when records weren't kept or were lost due to fire .  My own work could be disproven in a heartbeat by one or two original records.

The other researchers are "old school," pre-Internet, real on-the-ground researchers but who also hold info close to the chest. As frustrated as I am with that approach, I know enough about their work that I am not willing to steamroll over it.  A contributing challenge is age.  I'm not even sure if one of the researchers is still alive. Last I knew he had moved into a home and his files had gone to a family member who is also interested but not enough to actively dive into the boxes.
This post and traveling down this path AGAIN is having me rethink posting my article online.  I'd had the working draft online for a few years but a publisher warned me that if I ever really wanted to get it published (for real) that I should take it down.  I did. But I may never get it published "for real."  It's too long for most journals. I tried to shorten it for publishing but I hated the result.  It's not long enough for a book although I totally envision a historical novel coming from it.  Anyway, I'm going to put it back up.
Perhaps you could write some other long-ish articles (maybe on the same general area of interest) and put them together into a book(let), and self-publish? Like a collection of short stories, but 'for real'.
Thanks for the encouragement, Ros. It's taken 10 years to write just one! :-)
+7 votes
It doesn't help when the 'comment' as to why X profile and Y profile should be merged is "these profiles appear to represent the same person because: same person".  Duh! Same how? Same dates, same family members, same geographic location, or all three?
by Ros Haywood G2G Astronaut (1.9m points)

That is what the Matchbot does...

Ah, thank you.  I did wonder...
+5 votes
I've discovered another reason why unmerged matches may be ignored.

When someone proposes a merge on one of the profiles I manage, I immediately receive an email notifying me of the merge proposal. However, recently someone put an unmerged match between a profile I manage and another one. The only notification I received was buried in the New WikiTree Activity section of the daily Wiki Genealogy Feed email; if I'd been in a time crunch and had deleted the email unread, I'd never have known that someone proposed the match.

If WikiTree wants profile managers to resolve matches with the same care and attention that they're expected to give to merge proposals, 1. profile managers need to be informed about the matches in the same way that we're informed about merge proposals, and 2. as with merges, match proposers need to be able to give reasons for why this pair is an unmerged match and why they didn't go straight to proposing a merge -- what's the conflicting information? what still needs to be researched?  We need the same "reason" field for match proposals that we get with merge proposals and when switching merge proposals to unmerged matches.
by Sharon Casteel G2G6 Pilot (165k points)
There is a way round this lack of a comment.  When you have the two profiles up in front of you to compare, and you decide they should be unmerged matches (say, because of differing birth dates), before you go up to the top to click on 'set as Unmerged Match' you are able to scroll down each profile and enter a comment in each profile's comment box.  So you could say something like "Setting as Unmerged Match because...".  Somebody somewhere is going to see that.
+4 votes
Could we somehow rig the system so that it won't allow an unmerged match unless it is posted at the same time in G2G? You click on "unmerged match" and up pops the G2G "Post a question" window? Perhaps even prepopulated with "xyz-123 and xzy-2 should be set as unmerged match because ..."
by Helmut Jungschaffer G2G6 Pilot (602k points)
I like this proposal a lot.
+3 votes
To borrow from Helmuts suggestion could we have a space to require a reason for the unmerged match similar to the way we have to enter a reason for choosing one LNAB when merging?  It would really help me evaluate why an unmerged match had been sitting for a long time.  Maybe then I could provide research to resolve the open question if it isn't obvious.
by
+3 votes
I have had two "permanent" unmerged matches. Both are cases of same name, same geography, same time frame, but not clear if it is the same person.

For one of them,  once the 1939 register came out, II was able to determine that they were DIFFERENT people, and removed it.

The other one is 17th century, and a common name in that location at that time.  I have looked, without luck, for evidence either  way.  I periodically search to see if any new data has shown up.  But, until I find any, it will remain an unmerged  match.
by Janet Gunn G2G6 Pilot (158k points)

Related questions

+12 votes
1 answer
+8 votes
3 answers
+9 votes
2 answers
460 views asked Mar 28, 2017 in WikiTree Tech by Laura Bozzay G2G6 Pilot (830k points)
+25 votes
5 answers
+15 votes
2 answers
+31 votes
1 answer

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

disclaimer - terms - copyright

...