Unmerged matches: should we have more clear advice about when not to do this?

Question

The way I see it:

1. One of the biggest problems on Wikitree is duplicate profiles. The longer they stay, the more that problems grow around them.

2. The aim of every merge proposal, as far as we should all see it, is to get a decision of either merging or NOT merging. The un-merged match option seems to be like a last resort, asking for a short delay.

3. In practice though, un-merged matches are normally brought in very quickly, because of minor questions such as differences of dates or name spellings, even on profiles which (a) show no sourcing and look guess based (b) have good sourcing discussions all over them which can already show a careful editor why there might be differences of spelling or dates.

4. The way un-merged matches currently work, they basically make it difficult to go any further. They actually block the work which they supposedly propose should be done. There are less people following them up, and the people who make them rarely seem to feel responsible for un-doing them later even when they post explanations about further study being needed.

Couldn't we, shouldn't we, be adding messages and instructions in policy, and in the information that comes up when we do unmerged matches, to explain when NOT to do them?

Some obvious things I would like us to be saying are:

1. Remember the aim in handling merge proposals is a decision to either accept or reject the merge. Unmerged matches are for special cases. Is it clear what further checking needs to be done? Please make sure this is described in your notes.

2. Have you looked at the profiles, and the profiles of parents, children, spouses and siblings in order to see if there are simple explanations for whatever is creating doubts?

Comments

Gaile, I wouldn't want to restrict the capability or deleting rejected matches. I have seen many people who are in the process of creating a duplicate, reject a perfectly good match because they want their "own" profile for the person. Wrong, but it happens.

Also, I think where unmerged matches are set NOT as a result of a merge proposal need to be handled a bit differently than matches created during the proposal process. I have set profiles as unmerged matches when I stumble across them, and it looks like they match, but not 100%. Or, they aren't profiles that are in my watchlist, or I'm not interested in spending the time to research them. (We have to draw a line somewhere about what we spend time researching - and for me, much of the time, the profiles I'll spend time researching are in my family line.) I have many times gone back to unmerged matches that I've set up, and research them enough to prove or disprove duplication.

I'm pondering what suggestions I could make about merges, matches, rejections, etc. I certainly agree the current process is not working as well as it could be.

---

Proposed merges ARE already a sort of unmerged match just by the fact that they are proposed merges. I think it is best if one doesn't know what to do with them the best practice is to just leave it alone instead of adding another 30+ wait period which can only begin (when there is an unresponsive profile manager involved) once the unmerged match has been removed and a new merge proposed and yet another 30+ days elapses.

Unmerged matches should be used in the case of collateral profile merges like parents to happen first.

---

Vincent - I'm not sure I am following what you are saying about adding another 30+ wait period...I thought that only happened when merges are proposed. Or does it relate to unmerged matches as well?

---

Here's what happens.  You go to merge the unmerged match.  Click merge.  A message appears.  Living Jones (Jones-???) and Living Jones (Jones-????) are currently set as Unmerged Matches to indicate that the two profiles are not ready to be merged yet. 

So now the only option is to remove the unmerged match. After that all you can do is reinitiate a new merge.  Back to the beginning.  30+ days.

That's the reality.  

P.S. I'm not fussing at you or anyone, you do good work I've seen.  But that's what happens with this situation and I think many people aren't aware of that, that's all.

 

---

I would like to know what you do in a merge situation when one of the profiles has privacy limits that were set by the profile manager who is no longer active on WikiTree, i.e., no activity since November, 2011; over 4 years.  The profile with the privacy limits has generic dates for birth and death, i.e. born 1880's and died 1970's. I'm sitting with a duplicate profile that should be merged, but I can't because the profile manager is not active to approve the merger, or to add me to the trusted list. What do you do in a situation like this?

---

Vincent, this is late response to your question, but the 30 day default clock only starts with a Pending Merge, not an Unmerged Match. And then it requires that nobody click on it for 30 days.

That means nobody. If a manager or anybody else steps in and clicks on it on day 29, from either the original email approval request, or from the bottom of one of the profiles, then the 30 day clock starts all over from that 29th day.

If the Pending Merge gets manually reset to an Unmerged Match at any time, either before or after the 30 days, then a new Pending Merge request is required, which starts a brand new 30 day clock.

So people may be going through the 30 day approval list and making them Unmerged Matches. That will show up in the email of the original proposer, along with whoever did it. The thing is then to tell them to not do that so much.

Or people may be continuously clicking on the "Merge" link of a Pending merge every few weeks or so, without being a Trusted List member. That will restart the 30 days after each time that they click it. I have seen merges get delayed for several months in this way.

 

Carolyn, I wait on Private profile merge requests for years until a Sysop notices it and steps in and completes the merge. In some cases, you can report the tree as abandoned, but then you prompt deletion of the Private profiles rather than a merge. That is a rather nasty outcome that I try to avoid, because I really don't like the concept of profile deletion on recent people. Some day they will be over 100, and may be made Public then. But deletion is just loss. So my advice is to just set the merge, and then let it be. It will stay in your proposal list, but that's a small thing.

---

That's what I said.

---

For the unresponsive profile manager there is an option for that which will be the case for Carolyn to pursue.

---

Well then I guess I said it in more detail. I apologize for taking it as the question it seemed to be.

Maybe between us both the process will now be more clear to others.Or not.

---

About the clearest thing I get from all this is that the merge process needs clarification in addition to a complete overhaul!

Answer 1

One possible solution would be to place a time limit on an Unmerged Match. As an example lets say that an Unmerged Match is made, you now have 30 days to resolve this match. If it goes beyond 30 days the match get's rejected and only the profile manager who did not set the Unmerged Match can re initiate the merge.

Comments

I, personally, wouldn't want to see an unmerged match turn into a rejected match after 30 days. I - perhaps incorrectly - have set unmerged matches where I find potential duplicates that don't match 100%, but I don't have time to investigate them at the moment,

---

Again, if there is not time to investigate further, just click away and leave it as you found it.  Don't add 30+ days.  Simple.  Easy.

---

Dale I am not sure how this helps at all in the types of cases I was discussing? (Good matches, that get delayed because someone converted the merge proposal to an unmerged match only because they noticed a difference such as spelling difference or birth year difference, and did not have time to look further at it themselves.)

---

I like the time limit.

---

Maybe a great idea in some context not being discussed. But it really has nothing to do with the original question?

---

I like the time limit, but, disagree with the reject status.   I find most unmerged matches were put that way because someone did not think there was enough data to prove they are the same.   I believe that it is just the opposite....prove to me that they are NOT the same.

---

Think I agree here.  About a month ago, I discovered one of my "proposed merges" had been set as unmerged match.  As I had already spent a considerable amount of time researching this in connection with another family, I shot off an email (to the person who set it -- as this was one of those "waiting on default approval" outlining my research, and that I had looked, only found 1 individual in the county matching to criteria, sources, etc., etc.

It is still set as an unmerged match.

Answer 2

I'm going to enter this conversation as one of those guilty of creating unmerged matches. Not, as someone suggested, to up my points count; I didn't even know there were points.I honestly thought I was doing it correctly. In some cases, if it was a profile that I planned to actively work, I contacted the other profile manager. Other times, I assumed I had "done good" by alerting "someone" that this was a potential match.

I think part of the problem could be alleviated with this simple change to the unmerged match sentences:

If more research is needed and YOU are going to do it in the next 30 days, you can postpone with an Unmerged Match

I can guarantee you that if I had seen it phrased that way, the unmerged matches that I initiated would not have happened. As it is, I've gone through and removed the ones that I don't plan to resolve. Sorry for having contributed to the problem.

Comments

I like your suggestion, Debi!

---

I think this would be good for cases where there's already an approved merge proposal (by default or otherwise). But if I'm searching for a name and run across two profiles that look very very similar but have some significant difference that needs resolving before a merge (LNAB, parents, whatever) and that are not already in a proposed merge, I want to be able to set them as an unmerged match, because (in theory) that'll alert the profile managers to the existence of a possible duplicate. (It'd be even better if there was a comment field for unmerged match proposals like there are for merge proposals, so I could say at the time both why I think they're the same person and what's keeping me from proposing the merge right now.)

Sure, if I have a connection to them and have the resources, I'll do the research and propose a proper merge or set a rejected match, but most of the time they're unrelated to me and I don't know the resources for the area or the timeframe. But just because I'm not willing/able to do the research doesn't mean that I shouldn't use WikiTree's quick and easy way to alert all the profile managers that the research is needed.

---

The way you want to use Unmerged Matches is how I was using it, Sharon. The profiles are not relevant to any current line of research I'm pursuing. I just stumbled across them while doing other things and want to make someone aware who might care.

But reading the definition, it's clear that's not the intended purpose of Unmerged Matches (emphasis mine):

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.

http://www.wikitree.com/wiki/Merging#Unmerged_Matches

I wonder how difficult it would be to add a fourth option such as "Definite Maybe"? There's just something about getting ALL the potential matches sorted into one category or another that makes my little OCD heart happy. Leaving them on the Potential Match list just seems wrong somehow.

---

It seems to me that pointing out potential duplicates to profile managers - ie by creating unmerged matches - should be seen as helpful. I guess if people would rather we ignore them so they don't just hang around, that, to me anyway, feels non-collaborative when we are just trying to help. Imagine if everyone who stumbled across likely duplicates marked them as unmerged matches, how much it might help us all whittle down the duplicate count.

---

The language about unmerged matches seems to relate to when they result from a merge proposal. I, too have seen people just set merges as unmerged matches for nonsensical reasons.

this may be a case where the unmerged match process, which was created for one reason - ie merges - has other benefits to the overall tree.

---

Yes, please look at the original post.

Answer 3

I don't like it when an objection to a merge causes a new 30-day delay in in completing a needed merge. However, I am uncomfortable with any proposal that could have the effect of forcing a merge to happen because it once received default approval. 

There are many valid reasons for postponing a merge with an unmerged match. Not every merge that gets default approval is valid. I've seen too many cases where a well-intentioned merge combined two unrelated people together, leading to a tangle of misinformation that is frustrating to try to resolve. For this reason, I'm glad for the notice on the Pending Merges page that says:

Not all Pending Merges should be completed, even when they've been approved. Some approvals are automatic. Every pair should be carefully compared and considered. Be sure to check the top of the biographies and comments sections for special notes from other members.

I've frequently dealt with situations where a valid merge is appropriately delayed because there are unresolved conflicts between the profiles for the parents that should be resolved (to avoid "orphaning" a parent) before the merge occurs. (Today I dealt with a case where a merge I proposed was postponed because new duplicate profiles for the parents of one profile had been created after I proposed the merge.) Those are cases where it would be nice to move quickly once the earlier generations get merged.

Would it be technically possible to log the fact that a particular merge proposal once received approval (default or otherwise) -- and allow the merge to go forward quickly after someone documents that the reason for the postponement has been resolved?

Comments

The original proposal was exactly that NOT ALL merger proposals or merge delays (by switching merge proposals to unmerged matches) are good OR bad, and that therefore what is needed are more pro active reminders to editors of the correct guidelines and ways to make the right decision.

If, as a community, we can give simple listings of when not to do these things, that would help right? Just saying we've had bad experiences is a starting point to identifying a problem, but not a solution.

Most of the responses to my original post are bringing up complaints about other problems as if two wrongs make a right.

Answer 4

We can't start demanding of people that they investigate things in 30 days.  But we don't need to.

It'll take for ever to investigate all the issues around all the duplicates that need merging, and many of those issues will be unresolvable anyway.  But the merges need to go ahead regardless.  Leaving duplicates unmerged isn't the answer.

Comments

I tend to agree that too many impediments to good merges creates more problems on wikitree than to many merges. On the other hand I do not deny bad merges are also a problem but a lot of those happen at the time of gedcom import? In any case solving one of these problems does not require that we accept more of the other.

---

Andrew and RJ,

An unmerged match is and was only ever supposed to be a temporary setting so a time limit on that would encourage others to make a decision to either match, reject, or do the research. Is it a solution? Not the best but it would make people aware that making the profile an unmerged match is not the end solution, but rather a step in the process. We already have a 30 day clock on the merge process so how is adding another 30 day clock an impediment?

---

If something is not the best solution, it seem valid to propose improvements? The manner in which it is currently causing problems has been discussed quite a lot above. Indeed, please look at the original post.

---

You are saying that the instructions are not clear but the help guide say's this about the topic "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.". My suggestion just reinfoeces this statement.

For the complete help guide on this topic see this.

http://www.wikitree.com/wiki/Merging

---

There's no clear responsibility for deciding a merge is good.  The proposer doesn't have to - certainly Matchbot doesn't.  The PMs don't have to.  They can ignore it.  Some PMs approve all merges without looking at them.

Basically it's down to the completer, whoever that might be.  But at least they can complete.

Nobody can do anything with an unmerged match.  You can decide it's absolutely positively good and resolve all the issues, but you can't do the merge, because any approvals it ever had have been discarded.  You can only release it into the wild to discover its random fate.  But you could have done that without wasting any time on it.

A lot of the time the best thing to do when you find an unmerged match is just leave it for a Leader.  If you try to provoke any progress, there's a good chance of a poor outcome and then you wish you hadn't.

---

@Dale. 

If your suggestion is putting a time limit on the unmerged match, I think it is not going to be appropriate in all cases. In some cases it will just create new problems. I also don't see it will solve the problems I originally noted, and I think Vincent's posts explain why.

The text in the help page is not what people are seeing when they go to make an unmerged match. They are not being told to be careful about changing a proposed merge to an unmerged match at all in practice. So even for obviously correct matches, extremely often, merges are being blocked because of minor spelling differences and the like. For example many medieval profiles have 2 or even more spouses who are all just minor spelling variants, with the same parents or parents who are also duplicates. I often find such frozen merges which are very old, because people have no incentive to go back. I also find cases where the same proposals have been made, blocked and forgotten many times.

One reason for thinking that simple warnings can help is that in attempts to correspond with editors who do this I normally find they are apologetic and just had not realized what problems this creates. They believe this is just what everyone's supposed to do.

I think we should at least try to gather feedback on the idea of a warning, rather than having discussions about "yes its not perfect", "people should know better because it is on a help page" or "there are other problems which annoy me"? :)

There is a problem. There is a proposal to try to reduce that problem.

---

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.

Unfortunately it keeps saying "you" a lot without saying who it's addressed to.

In fact, reading the help file, you'd get the impression that merges are all down to the PMs for 30 days before being thrown open to the rest of the world.

But anybody can postpone or reject a merge at any time, even before the PMs have read the emails.  They needn't have any plans to pursue it.  They won't be affected by any timeouts. 

The merge can be re-proposed.  But then the original proposer is out of the loop and the merge won't appear on his lists.  That's another problem with using unmerged matches.

 

 

---

Yes it is a vague wording. It is not a clear set of instructions, and the terms are not defined.

I would say unmerged matches should only be for fresh proposals to open consideration of a possible future merge proposal.

I would say once a merge has been proposed, the options should be accept, reject, or discuss.

 

Answer 5

Let me try to get this discussion back to the original topic by being Devil's Advocate: Is it ever really all that useful to change a proposed merge into an unmerged match? (I do recognize that unmerged matches have other uses.)

A secondary question will arise. Even if a usefulness can be named, are there not other better ways to do those things?

For example, I have seen people say they use this possibility as a kind of place holder to remind them or someone else to look at a profile later, because of some specific doubt. But as many people seem to recognize, this "nuclear option" way of raising a doubt (by blocking the merge in such a way that it may never happen) is really not working well in practice. 

Which leads to a third question: surely there are other ways to mark something as needing re-checking or raising small doubts? At the very least, such reminders are going to work a lot better if addressed to someone and written up as a specific question. The comments boxes on profiles seem perfect for this. Indeed, aren't responsible editors doing these unmerged matches partly with the idea in the back of their mind that their reason will end up being posted in a comments box? Why not ONLY use the comments box for basic questions about reasonable looking merge proposals?

(I personally tend to believe that medieval profiles could use fully blown talk pages like on other wikis, and not just the little boxes. Many problems seem to arise because of the lack of any way of recording prior discussions. But that is another subject.)

Comments

(G2G threads attached to profiles are Wikitree's version of Talk pages. I and several PGM volunteers use G2G this way.)

I have lonnnggg requested that Unmerged Matches generate a comment on both profiles no matter when the Unmerged Match is selected. To date, Chris won't implement that request, concerned about cluttering up profile pages.  (deleting extraneous comments is a very simple solution to this problem.) Currently, a comment is posted to only one of the profiles (not sure which one) and only when Unmerged match is a response to an existing proposal.

I continue to feel that unmerged matching is not the problem but providing insufficient merge proposal details IS.  If people included sufficient details at the time a merge is proposed (or pre-merge editing was done to the profiles to align the data), then more people would complete merges, fewer people would select unmerged match, and fewer 30-day defaults would a) happen and b) be marked as unmerged matches.

---

> Is it ever really all that useful to change a proposed merge into an unmerged match?

Can't think of a situation.

 

---

OK Jillaine, so cluttering of pages is the problem. Currently I don't know how to get a simple listing of all discussions about a profile, and I guess almost no one does. That sounds fixable. I fear Wikitree suffers because all such formatting issues seem to be handled by one person. Maybe that should be the subject of another discussion.

But back to the subject, see the question RJ has already answered. Can you think of a case where there is not another way to handle it? 

Why not keep unmerged matches for fresh proposals and stop them being used as a response to merge proposals? In what way are the a good way of replying to a proposal, raising a concern or asking a question? If that is what they are for, isn't it clear they work very badly?

Your response is again changing the subject. Yes some merge proposals are not perfect, but that is a "two wrongs make a right argument"? 

In practical terms any policy which demands too much on a wiki community will never work. The wiki needs to be designed to make improvements easy. When I propose merges I am often handling 7 profiles at once while I carefully cross check them, and try to understand and note the dozens of implied merges and splits required in some single cases. I often post sourcing all over those profiles to try to help avoid them getting blocked. I often write to the managers, but there are often so many. I must admit I often get cynical and change all uncertain the name spellings and dates first so they are all exactly the same, just to make sure no one will block it. 

You want to make it even harder to improve wikitree? 

---

I have already shared when I find changing a proposed merge to unmerged match-- when the proposer has provided insufficient information in their merge proposal to complete the merge, but when it's obviously the same person. I don't like doing it, but if the proposer hasn't done their job...

If I didn't have unmerged match as an option when responding to a merge proposal, what should I do in the above situation? I don't want to reject the merge because it's obviously the same person. But I am not necessarily the person involved in the research-- I'm usually a volunteer going through the list of pending merges which have passed the 30 day mark.

---

This is my last comment on this topic

Andrew you want to have us either merge or reject without having the ability to do further research within the 30 day clock already on any proposed merge and that is just not realistic for all proposals. when we run into an unresponsive manager it will take a couple of months to solve that problem and that would mean rejecting a proposal that could be a merge, so yes an unmerged match in those cases would be the best option as they are set up today. If you look at the oldest unmerged match on

http://www.wikitree.com/index.php?title=Special:BrowseMatches&type=matched&order=dateup&canAct=1&requested=0

you will see that it was made in February of 2012 and the problem is the manager of the Red privacy level profile has not been active since September 20 2011 so it is the unresponsive managers that are making things more difficult and not WikiTree policies.

Bottom line your suggestion will not make any difference in most of these cases and has the possibility of encouraging others to either not try to find duplicates or merge those that should not be merged.

---

@Jillaine and Dale. So why intervene at all in such situations? Why not leave it for the time period. Why not leave it to others who are working on it? If you really want to intervene, why not at least have a system where the way of intervening is to write with your questions and concerns? Is it so important to be able to intervene without showing any actual attempt to look at the case?

Remember a lot of these merges involve a whole net of relations. So each of these interventions basically is not just one delay, but a whole bunch of them. Why do you feel the need?

The 3 options I propose are accept, reject or discuss. Currently the 3 options are accept, reject or do something which makes everything blocked, delayed and unclear. Very often, this third option is leaving things half fixed and making Wikitree worse.

@Jillaine. Just to make sure it is clear, what I am saying is that you still don't give a clear answer to the question. Your reply is seemingly saying that "discuss" is inconceivable, even with someone who has just posted a proposal (so not an inactive editor).

@Dale. In the cases I am concerned about there was a merge proposal and then someone who blocked it. So the problem of unresponsive editors only applies in terms of other parties involved indirectly such as profile managers who "might have a source"?

---

I don't think that was ever a proposed merge.

It should be impossible to propose a merge with a Red profile if you aren't on its TL, because it's only a stab in the dark.

In any case, it shouldn't be Red unless there's confidential info on it, and if there is, the PM might not want to share it with a 5th cousin who happens to have a duplicate.  What then?  A permanent unmerged match may be the only answer.

But duplication down in the private zone isn't a problem.  There's nothing to discuss with profiles that aren't Open, because third parties can't do anything with them period.

---

Andrew, you ask: "why not at least have a system where the way of intervening is to write with your questions and concerns?"

To me that's what unmerged match is. I put in the explanation box (or in the profiles comments box if an explanation box is not provided) my concerns and any outstanding questions. 

Granted, it doesn't automatically start a g2g -- that would be nice -- but it does post a comment to at least one of the dupe profiles.

 

---

OK Jillaine, that is what we want it to be, but it is not that now in practice. I wanted to get discussion about how to make it more like this in practice.

Hence my proposal that we distinguish between simple unmerged matches, ones made from a fresh start with no prior merge proposal, and what to do when we want to request discussion on a merge proposal. I think these are two different things? I think the second one should be called something like a request for discussion, and the messages and texts and clickable links which come up should explain it this way.

For the time being, unmerged matches block merges. Tweet style comments are the best we can hope for and often just say something like that there is a spelling difference. That is the present reality. Yes, some merges deserve to be rejected, but that is another subject.

---

I don't experience them as different in purpose. Whether initially selecting UMM or responding to a merge proposal with a UMM, we're saying the same thing: these two are probably the same but more info is needed before the merge can be completed.

What is different is that only the second (responding to a merge proposal) pops up an explanation box. As I've said elsewhere, I've long requested an explanation box for UMM no matter when it's selected. I'm not alone in asking for this. It comes up every few months. Lacking that, the UMM'er has to take two extra steps to place comments on both profiles.

As for the "spellings are different" responses by UMMers -- if the responder is not paying attention to either the contents of the merge proposal or whatever is written on the profiles that answers this question, then yeah the UMM'er is in the wrong. (As is the rejecter who does the same thing--'which frankly I see all too often.) BUT (here comes my drum again) if there is insufficient information to help the responder make the merge, then "blocking" the merge's progress is wholly appropriate. And in my experience is that 95% of the times I respond with a UMM, the proposer has not done their job.

Bottom line for me is that our energies are better spent encouraging the initial proposers to do their job better than to add more complexity to the process by adding another response option.

---

Why don't we work in both directions? :) (Better proposals, and ALSO better guidelines etc for people coming across a proposal.)

I still think we should not reply to a proposal for improvement with a two wrongs argument that just leads to no improvement.

By the way I think 95% of the cases I see are the other way around, or possibly 96.5%, approximately. :)

Answer 6

My 3 cents:

I agree the sequence and language is confusing – especially for those of us that do not merge frequently or are just learning the "navigation parts of Wiki".  But it should also be the individuals responsibility to determine/research if, in fact, they are the same people or not before proposing the merge.

Perhaps some modification to the language would be in order to streamline the process or make it more intuitive. 

Following are some of the various feed suggestions (over the last year or so) – maybe we could get something on the drawing board to “revamp this for the future” -- Maybe "propose a theoretical solution" vs. "just discussion".

1.   less confusing if there could be two buttons on the remove-match page, one to simply remove the match and one to remove it and immediately start a new merge without a step in between

2.   option on the unmerged match area to have the option to  'Reinstate merge'

3.   If it's been approved once, it should still be approved after an unmerged match.

5.   Reason box for Unmerged Matches/Rejects

6.   Status indicator on Pending Merge

7.   Change the sequence : :(with reject/continue option throughout)

First Step:  Initiate Unmerged Match - 

(Unmerged Match is simply a way of saying: these two MAY be the same, but some closer analysis needs to happen to make sure that's true.  There may be  conflict to resolve before proceeding

http://www.wikitree.com/g2g/52398/there-comment-unmerged-match-explaining-merge-should-time 

Second Step:  “Pending Merge”

(When 1 or more approvals received or waiting for default approval -- Status indicator - Continue

3rd Step:  Either Merge or Reject  Merge

All approvals and conflicts resolved -- ready for Final Compare and Merge --  Either Merge or Reject  Merge (Reason for Reject)

Comments

A lot of the "time limit" problems seem to be a result of "inactive" managers -- Need some resolution here also.

---

@Sandy, please look at the original question. This discussion is about quite specific cases where unresponsive editors are not directly the issue.

I am also not sure how making a forced step in merges (of FIRST making an unmerged match, even in straightforward cases) helps anyone at all?

---

True, all I am "trying to say" is merges et al have been an ongoing issue for a very long time (for a variety of reasons); everyone seems to agree on this point -- and it needs fixing somewhere -- and listed as a "Needs Fixing" but I also think some suggestions on where to start might be helpful.  I am not trying to be negative; circumvent the subject - only trying to be helpful.

-- My thought was maybe a mini-solution is to "change the merge sequence" itself so it is more intuitive and the time limit does not keep getting reset (i.,e. consolidate the functions - not separate them  - step 1 = Unmerged Match (clock starts 30 day process -- Step 2 = Verification of info - and/or wait for default - Step 3 - Merge or Reject based on step 2. - don't allow reset to unmerged match where it starts over again, but maybe an additional 5-10 day extension to complete.  Most active managers can either approve or reject before 30 days (but I think some do not even bother, they just let the clock run out) - if a problem is noted, it can be tackled by 2 people instead of 1.

1. One of the biggest problems on Wikitree is duplicate profiles

- agree -- but a merge should not be proposed unless one is fairly certain they are dups & reasons why, -- or there just is no data and it needs elimination.  If the old underlying issues of "not enough information" are not addressed and cleaned up - it continues to be a problem, and more new imports every day contribute to that.

2. The aim of every merge proposal, as far as we should all see it, is to get a decision of either merging or NOT merging.

-- Agree - but I have seen many instances of "proposed" merges where the underlying data itself rules out the merge -- And these set as "Unmerged Matches" for months - they are not a match - likely never will be.  Research should be at step 1 rather than Step 3 or 4 of current sequence. (where it gets reset to unmerged match) -- Although I agree it should be "reviewed" again before actual merge occurs.

If, as a community, we can give simple listings of when not to do these things, that would help right? Just saying we've had bad experiences is a starting point to identifying a problem, but not a solution.

-- Agree  -- How do we get to the next level without throwing out some possible solutions?

---

Sandy, but can you give some comment on the proposals I originally made? Indeed, we should be able to discuss proposals for improvement. My experience with G2G so far is that it seems very difficult to get discussions which lead to towards actions.

---

Andrew, I went back and re read your original post. The only "proposal" I see in it is improvement of help text. I can certainly support anything that further clarifies how to do merges.   

 Subsequent comments you've made in this thread have included additional ideas. And others have added additional suggestions.

What exactly are you seeking a response to? Maybe you could edit your original post to better focus our attention.

On the positive front, you've clearly touched a place of frustration for all of us. And doing so has resulted in a torrent of different types of responses. I'm sorry this is frustrating for you. But I am now no longer clear what exactly you're wanting us to respond to. Sorry.

---

Sorry if I am being obtuse, I went back and reread the whole feed.; so, again -- will try one more time to see if I can get there.

Your original proposal does not Clearly “say to me” what it is that you are actually proposing as a “solution” 

My assumption is you mean “Change the Instructions under Help” == Yes, I agree Needs to be more Explicit (but also think that things like (Debi Hoag statement) needs to be incorporated., as well as “on screen Instruction of what the System expects at a particular level”

I also think it needs to be looked at from both system constraints – and user input (most think they are doing it right – Root problem = misinformation)

RECAP Q. Unmerged matches: Should we have more clear advice about when not to do this [Yes - How/Where}

1. (a) Remember the aim in handling merge proposals is a decision to either accept or reject the merge. [You want to have us either merge or reject without having the ability to do further research within the 30 day clock – Yes agree, BUT once it gets to that (Merge) level it should be accept/reject – not renew for another cycle] (Root Problem -- sequencing)

(b.) Unmerged matches are for special cases. Is it clear what further checking needs to be done? (No Not Clear – Needs To Be More Definitive – Who Takes Responsibility/where -- This is a research issue] - Please make sure this is described in your notes.[Where and how does this appear – How Notified/at what level]

2. Have you looked at the profiles, and the profiles of parents, children, spouses and siblings in order to see if there are simple explanations for whatever is creating doubts .[Where and how does this appear – Who takes responsibility for this – at what point in the sequence  – the “Proposer” the “Profile Manager” the “Completer”]?

From a user standpoint – Directions for use and purpose need to appear “on the Screens accessed” --  "Help needs to define & explain the steps".  The current sequence itself (although useable) is not intuitive (my opinion only) for a user and creates other problems.  Screen text will get to the people working the merges – whereas “Help verbage” might not reach everyone.

Thus, in a nutshell:
Step 1 Unmerged matches Say = Research – Clearly define and needs to be used for just that – to resolve discrepancies before the Merge (start clock here vs after)
(A)*Both Profiles need to be Researched; -- are they the same or not – This should be BEFORE proposing the merge and (B) the specific reason for going with a merge should be clear ( in place profile posts)

Step 2 Merges Say – Complete/Reject
(a) “Proposer - I’ve done all the research I can and still think they are the same”;
(b) Manager approval/default approval – agrees with suggestion;
(c) Volunteer Completer – Re-review - sees from profile they agree or not -- if not, set as “Reject” – Not as Unmerged Match – If Completer disagrees with Reject option – They need to research themselves to either approve or reject (with their reasons) as 3^rd consensus (or maybe leave as is and contact profile manager for resolution; or if not completed within 60 days system default to "rejected" where it starts all over).

Hope I got it right this time – there are some good suggestions here – How to summarize them (pros vs cons) and how to get it to the next level –  I don’t know.

I think Dale’s suggestion (couple days ago) should also be incorporated under this.  It seems clear that we need more definitive language and more definitive solution suggestions that include how to Stop, Prevent, Fix the basic ROOT CAUSES – this takes “people with system expertise” to set the correct path – If it can be done with the “help verbage" ”G2G Posts -- Great – I am all for it -- most cost effective!

http://www.wikitree.com/g2g/199835/is-it-time-to-revise-the-merge-proposal-system

Regards

 

---

One of the very basic aims of the proposals is that people doing these actions get a short clear reminder of the "big picture", and specifically about how those isolated actions fit with certain bigger aims.

If you approach the process too much like writing a sub-routine for a computer then of course you can miss this point. Computers do not need to be told the aim. People are better than computers because they can find solutions you do not even predict, IF they understand the aim.

---

Subtle messages don't get through.  Maybe just change the name from Unmerged Match to Canceled Merge.

(Though come to think of it, it's hard to see the difference between Unmerged Match and Rejected Match.)

---

I don't understand why it's so difficult to understand the distinction.

Rejected Merge-- these two profiles are definitely not the same

Unmerged Match-- these two profiles may be the same, but more work is needed before the merge can be completed.

Perhaps "Unmerged Match" should be renamed to "Postponed Merge"

---

Jillaine do you really think RJ, Vincent and me simply don't understand how it is INTENDED to work? :)

---

No. Just RJ. ;-)

---

And yet the two cases are dealt with almost identically.

(Which reminds me, there are lots of good merges on the Rejected list as well, for the same reasons, presenting the same problem.)

---

LOL. But anyway I agree with RJ Jillaine. The "unmerged match" function was presumably mainly intended to be a kind of more tentative merge proposal. Right? I think we all follow it the same way until this point?

But no matter what the original intention, it is now being used as a tool which freezes merge proposals being made by someone else. It is this second use, which actually seems hard to even justify, at all, and is certainly difficult to explain and understand. But I think this is the MOST common use of the tool now.

I guess it just evolved wrong. It should be possible to change things that evolve in a direction that creates many problems. We need more genealogists, and we need to make it easy for them to work, especially concerning precisely this type of job.

You can say, if you want, that there is no difference between the two uses of the unmerged match function. But tools, even on the internet, are always judged in terms of how they help get to a certain goal, starting from a certain problem. And if you look at at it this way, the two uses of the function are very distinct.

I can certainly see a strong argument for simple stopping this use of the tool, and forcing anyone who wants to question a merge proposal to simply contact the proposer some other way. (There are already many ways.) I see no real problem that this would create, and simple solutions are often best.

If it can not be stopped, then I think indeed we should look for non subtle messages which remind people that they are about to block a merge proposed by someone else, which is something that is not subtle. I do think as part of this we should be giving very different terminology and messages than when someone proposes a "fresh" unmerged match.

(I do not see any point to discussing how it is not really blocking merges completely because you can still try to save them. In practice unmerged matching is stopping many much-needed merges. And in practice you can still try to save pretty much anything. So it is like saying something is not in the way of someone because they can walk around it.)

---

Don't agree with me, that's fatal.

I think the idea was that PM A proposes and PM B says I'll think about it, and when he's thunk he re-proposes the merge.

This might happen down in the private zone, where approving a merge is basically about approving the merging of the TLs.

But in the Open profiles, it's often C proposing and D completing if E doesn't block first.  But nobody has any particular stake or responsibility.

The facility exists to go straight to unmerged match, but I haven't seen anything about what it's for.

I use it a lot for reasons of funk.  If a merge looks straightforward I propose it, but if there are complications (eg parents don't match, or both LNABs wrong) I don't dare.

The only way I know to make progress on those merges would be to get on the TL of both profiles.

But then we have the cases where somebody blocks a merge because they aren't convinced it's the same person.  I don't know how to make progress on those either.

---

Exactly. It is a roadblock. It is too easy to say "I have doubts".

Answer 7

Something needs to be done, certification might be the right thing, just for merges of profiles that a member does not manage.   I spent hours doing research on two profiles and documented why they were the same, one of the profiles was public, so the notes were all put in the comments on that profile.  When the merge became default approved, an experienced Wikitree member, merely looked at the data, none of the notes, and set the merge as "matched" because "not enough data to make a judgment"   I do not know what else to do....

Comments

That happens a lot.

---

A profile with the Green "Public" privacy setting will never go into a default approval, the profile manager has to approve the merge or it will never be able to be completed.

---

Not true, there are a lot of Green Public profiles that are default approved.  I believe that only Private profiles are not default approved.

---

Robin, I take it that you're not comfortable using your Leader status to adopt the other profile after having done all that work?

---

Also, Chris W said in another thread that certification/testing for merge approval would be near-impossible to implement, so I don't think that's an option.

---

Leader status aside, I would have pointed out to the experienced wikitreer that they failed to read the comments on the profiles, and to be more careful moving forward.

---

A leader can only adopt profiles that are over 200 years old...this was a green privacy profile under 200 years old.

And I did point it out to the other person, but never heard a word back on the subject.   Turns out these two profiles have been set as unmerged matches twice now.  I just wish there was something we could do....

---

If we go back to the original post I wrote, the idea was a rather simple proposal that won't fix all problems, but aims at some improvement.

Answer 8

I am really late to this party, but having read all the answers and comments on at least two occasions, I don't see that the question has a good resolution, and I have a problem just like was described with an Unmerged Match, which has the tendency, even when it is only one case, in my own Watchlist, of indefinitely postponing action.

I DO think that there is an answer, if is it possible to accomplish.  I have the following to say; read it carefully (and let me know if any aspect it is unclear).

It appears that Unmerged Match is NOT a STATE!  Instead, it ought to be a tool.  Since the answer is that there should not necessarily be a postponement (rather, an acceleration of the merge process seems to be desired), than the proper response seems to be: Have the TOOL Unmerged Match post comments to the affected profiles.  Possibly have it automatically note differences. Possibly have it automatically direct a potential subsequent merge attempt to those comments before proceeding with the merge (because it has somehow tagged the profiles, minutely, perhaps with a template)  Allow the proposer of the Unmerged Match to add comments to the profile with regard to the Unmerged Match notation.  Probably the tool should send email to all affected parties, including the proposer (so that e has a record of it).

Most importantly, the tool should NOT delay the merge process by these actions.

Is that possible?  Would it work?

Comments

Roger, this-- or a variation of it-- has been requested many times. Chris has resisted it for several years claiming it would clutter the profiles in question. (Comments posted to a profile do generate an email to the PMs.) Maybe he's changed his mind.