Can we have a button for Unmatched Merges?

Question

I've been working on a lot of unmatched merges thanks to the magic word that Ales gave us.  So many of them really are a match.  The current process is to first remove the merge and repropose it again (several steps).  Could there be a choice in the list that allows you send them directly back into a merge status?  We could have compare, remove, reject, reactivate. . .

Comments

I'm not as dedicated as Cindy to unmerged matches, but when I do come across them, I admit to being irritated at the extra steps needed to re-propose the merge. In short, I support Cindy's request for a short cut button.

Answer 1

Yeah, this probably could be streamlined. I checked and it takes 6 steps to propose a merge if the two profiles are in a unmerged match.

Comments

Thank you Jamie for considering this for improvements!

---

Thank you Jamie for the new button!  It works!

Just checking that after I use it, the merge shows up as a proposed merge and the unmerged match still is there.  Will that unmerged match go away at some point?

If I go to delete the remaining unmerged match then they both go away so I don't want to do that.  I'm going to proceed with using the button and leaving the unmerged match on there in the expectation that it will get resolved.

Answer 2

TECHNICAL QUESTIONS 

Did this unmatched merge process ever get streamlined? It was incomprehensible the one time I had to do it. Is it safe for me to stop avoiding it now?

Also, does the 30 day clock which applies to regular merges also apply to unmatched merges? Meaning can anyone with the knowledge to resolve the situation jump in and resolve the unmatched merge if the 30 day clock has run out? 

Or does the 30 day clock only start ticking when the unmatched merge is lifted and the merge request is redone? 

Comments

The 30-day clock does not apply to unmerged matches.

---

Thank you! That's good to know.  

 

---

To answer the question about streamlining the process, it's one of the things being worked on right now (along with improving how comments are used during the process).

---

SUGGESTIONS FROM NEWBIE PERSPECTIVE

Clearly this was never intended to be an incomprehensible lost-in-space limbo-land for profiles.   

I've been reading up on this via G2G where most of the comments are from experienced wikitreers, but I saw Linda Peterson wisely point out that "newbies" tend to misunderstand what "unmerged match" means, interpreting it as a merge which I approve, but the other manager has not yet got a chance to weigh in on. From that misinterpretation, the wikitree requirement for collaboration can fling those profiles into the unmerged-match blackhole.....a place where time ceases to exist, or at least the 30 day clock fails to tick. 

A quick release button and comment box for why  the "unmerged match" was applied are good ideas I saw to partially address this problem, but remembering my "newbie" perspective,  I wanted to add ideas about language, time, and graphic interface as proposed suggestions for whoever is working on this thorny issue: 

1.) Remove the word "remove" from the process of undoing an "unmerged match."   

Why? No amount of help advice on merges explains this terrifying word "remove" . What was I removing??? This really was never clear until I finally got reckless and consented. Then, what had I done? Now I was having to restart the merge all over to complete it! That was very suspicious, like one of those M.C. Escher Mobius strips. where I might be walking this loop of ignorance forever. Neither intuition, nor help pages were of any use. 

2) Build a highly intuitive graphic-user-interface format for getting into and out of the "unmatched merge" limbo. Test on "newbies"  not pros. Refine until they are no longer screaming or quitting or misinterpreting.     

3) Apply a time clock to "Unmerged Matches" with a warning to the person about to apply it that after 40 (?) days, anyone with the knowledge to resolve the match is free to  do so. There is nowhere else on wikitree that I see individual contributors given such unilateral power to unintentionally clog up the resolution of what is designed to be a fluid group process. The time clock would empower the person with the best sources, the best insight, or the best tidying up skill  to resolve the duplicate or to untangle it if it was actually  two persons conflated. 

4.) Rename the dreaded "Unmerged Match" since the name is open to misinterpretation. I think Jillaine Smith suggested "Delayed Merge" on one thread. That's more descriptive. Something like " 40 Day Merge Delay" could sync well if the time clock was applied, sending the idea that if you ignore this for over 40 days, someone else is free to clean up. "Merge Delay for Research" could work or "Request Time For Research."  Help pages could make clear the regular merge gets a 30 day window for completion and this other thing gets granted a special 40 days. Make it feel like when a teacher grants you extra time to do your homework. A privilege to help you do your very best, but then to empower the group process to take over when it just ain't getting done. 

It can be better, but it's a kink in the system for a variety of layered reasons, not just a one cause glitch.   

---

What black hole are you referring to? Unmerged matches (and any other outstanding merge requests) are easily found under the Find menu (Find Merge Requests) which takes you here:

https://www.wikitree.com/wiki/Special:BrowseMatches

There one can find all unmerged matches and "unmerged matches waiting for me".

My concern about an equivalent time clock for unmerged matches is that someone will come along and complete a merge that should not be completed.  A notification system, though, would remind people that they should check them.

I still concur (with myself <grin>) that renaming it is a good idea. :-)

Now I'm going to go look at my own list... I know that i have at least a couple that will never be resolved.

---

Sidebar: Because of this thread, I looked at two unmerged matches on my list. I was able -- with the help of Roger Stong -- to complete one of them. I'm giddy.

Time for breakfast!

---

At risk of boring you , what feels like an "energy sucking  black hole of suspended animation" is how often I see a manager with a poorly sourced or unsourced profile "reject" or "unmatched merge" an obvious match to a thoroughly sourced profile. Now the profile is in limbo.  Often this duplicate pair is tied to to a cluster of multigenerational duplicates which I have tagged as well.   I assumed there never was any way to go forward with the merge if the manager chose to never lift the "unmerged match", but my "Find Merge Requests" log suggests that my assumption could be incorrect. What I can't figure out is how those two "unmatched merges" got cleared at all if the clock is not ticking? Changes history of the profiles do not shows the managers or anyone else removing the "unmerged match" status.   

Most often it is just one detail of difference triggering the  "unmatched merges"  such as how the name is spelled, and I find less experienced contributors can be rather touchy and incredulous when shown primary evidence that their family name had systematically shifted over time. Since I learned about the significant name shift on one of my family lines, I have been able to resolve a number of wikitree roadblocks, and have unearthed lots and lots of genuine duplicates. The blocking of the resolution of these actual duplicates happens on a surprisingly frequent basis, mostly by the flat out rejecting tactic, but sometimes  "unmerged match" is used, typically with no visible effort to research further and a steely resistance to consideration of weight of the primary sources that I add. At some point I just resign myself to leave behind a paper trail of quality sources, comments, and research notes associating the duplicate pair of profiles.

"Find Merge Requests" was new to me and I appreciate the heads up about it. Looking over two of those profiles reminded me of the frustration of dealing with the "unmerged match".   

I do think that avoiding contact with  "unmatched merges" might be my new go-to position unless someone signals "let's work on this together." From the G2G threads it's clear an "unmatched merge"  problem exits and has long been documented, but the solution is not yet at hand. 

I currently am helping someone who needed coaching about how to get the clock ticking on a merge that they had accidentally tagged as "unmerged match."  thinking that was the normal polite way of providing time for the second manager to weigh in, but that manager is turning out to be non-responsive, and we are well-sourced to iron out all issues once the system allows it. Your advice about the clock has helped us a lot in this situation, and at least two merges should happen in about 30 days!  

.  

---

With the upcoming changes, removing an unmerged match will no longer be necessary if you want to repropose the merge.

I don't like the idea of time limits on unmerged matches. Unmerged matches are really for profiles where there isn't enough information yet to know if they are the same person or not. To get that information, the needed records may be only held in an archive, a book that needs to be requested through interlibrary loan, or even DNA testing (all of which can take many months to get to). Anyone can do the research to resolve an unmerged match, they don't have to wait some period of time. Also, a time limit might encourage people to do lazy research to force the merge through when the time limit is up. For my one-place study, I've had multiple people not pay attention to the sources and just assume the same name and place == same person and propose a merge just because they were trying to reduce the number of unmerged matches.

Renaming would probably be good. I don't know if "Delayed Merge" is the right term for it though.

---

Concur with all your points about time limits and unmerged matches.

If not "Delayed Merge," how about "Postponed Merge" or "Potential Match"?

---

Oh yeah.  I see Jamie's point about why a time limit on these is not a good idea,  and for sure merges done too quickly on scant data can really be problematic. 

It makes sense that something in between approve and reject is needed. Since the other choices for managers read something like  "approve merge" and "reject merge", maybe "unmatched merge" could be promoted to a really descriptive name. 

 

In addition to Jillaine's suggestions, please consider these ideas for a new name: 

"inconclusive match" or

"needs research" or

"delayed for research" or

"research needed: inconclusive "