Do you look at the whole branch when suggesting a merge?

Question

Based on the database error project, there are a lot more people proposing merges today.  I am wondering if we need to update some of the instructions.  Particularly this from Merging FAQs:

What if the data or parents for the two profiles don't exactly match?

This is often true. It shouldn't stop you from doing the merge if the two profiles represent the same person.

Before the merge is completed, you or the person completing it will be prompted to select which data fields and which parents to keep. The biographies and sources will be combined, along with memories, notes, photos, etc.

After the merge is completed, you'll be able to edit anything, just like on any other profile.

I recently had a conversation with a person who indicated that as the person who proposed the merge, he did not need to look at whether the parents matched or not, he was just suggesting the one merge.   He also indicated it was up to the person who finalized the merge to "decide which parents to keep"....YIKES.   That may be true when the parents are different people, but shouldn't we address what to do when the parents are also duplicates?   Or, am I the only one that thinks this is a concern?

Comments

I think the system works well. The ultimate responsibility of the merge of a profile lies with the profile managers.

You might want to suggest to the other user that his suggestions might be better handled by creating unmerged matches.

---

Lance, I would agree in a world of "Active Profile Managers", that the solution is, everyone does "their work" but in reality, that does not happen because we have so many inactive profile managers.   IF you look at the main page for Wikitree, we have had almost 344,000 poeple work profiles, and last month 1817 of them did 100 or more transactions....do the math, that means less than 1% of the profile managers are active.     Which is why we have over 30,000 unmerged matches that need to be "resolved" and over 4,000 default approved merges to be worked.

---

My experience is that I have things that I am working on that I spend many hours doing. Coming across obvious duplicates or errors, I flag for a merge. I guess I could continue and ignore the error, but if I am working on my project I do not need another rabbit hole to go down into to find out why there is a duplicate sitting there.

 

Recently I had a cousin join that uploaded a whole branch of our family as a fed on and now the work to clean it up is overwhelming.. I have resigned it to getting cleaned up as I pass through it.

 

Another argument for considering banning GED uploads

---

My five cents (after having looked at the other answers as well):

• Proposed merges should always be accompanied by instructions should there be conflicted parent profiles
• Yes - the person responsible for the merge is in my humble opinion also responsible for the parent profiles (as well to a large degree for the states of the bio's of the profiles to be merged, though I do see that that is not everybody's strength, it is also context bound and some people are just excellent arborers)
• It should also be done in a way that eventually one ore more profiles won't go "floating" off in the WikiTree-ether (either in the bio's of all of the surrounding profiles, or at least in the comment boxes - see: Comparing Vosloo-32 (L) and Vosloo-73 (R) - though having just gone through my own unmerged matches feed, I saw that I had not always been this dilligent in the past)
• I do not agree that matching them would "take them off the radar" - this has given us many times the oppurtinity to solve issues and get the correct parent profiles attached
• To cite "We always use sources" from the honor code does not adress the reality of of the tens of thousands of duplicate profiles created with and without sources over the years. Many many times we (in our project) just had to be practical and merge where possible (WikiTree can be very straightforward in a mathematical/algorithmic sense because one can easily at times pick out duplicates in various different ways). With the new "boiler plate" the profiles that get GEDCOM'd and are duplicates have very weird and gnarled sources indeed.
• Indeed with hard research many controversies go away - this does not prevent people from creating duplicates ...
• ... imagine a project with 10000 + profiles which will eventually fall into place like a giant puzzle but every single profile needs "validation" against the odds of [ ... fill in any role or badge here you find appropriate ...] at times clearing up stuff but many times just make more work - dis- and re-connecting (also other WikITree members using dated secondary sources) ... Rome was not build in one day ...
• which brings me to this - even if one could regard the error database methaphorically as a 3-D Printer - that very beautiful magnificent Rome will not be merely improved or speeded up by the use more automated proceses ... such as the features that Ales is suggesting.
• perhaps I'll have to qualify what I have just put out here with a few extra pennies later on ... for now ... I bow down with this remark - Please take into account the humanity ... we are all humans, wiithout us there would not have been genealogy, without our wants and woes we would not have had all these wonderful and dreadful tales to "validate" - there is only so many hours in a day. We all make mistakes.

---

To add to Robin's point, there are unmerged matches sitting since 2012. The last thing we need is more.

---

if I were better at research (without having to add them to my own tree :) ), I would be tempted to jump in and help. Is there an easy way to see the list (I've seen it before, but can never recall how I got there -- sometimes, its like we're just in one large maze)?

---

Dennis, you're asking about how to see the list of unmerged matches?  It's on the same page as pending merges.  At the top, one of the choices is "all unmerged matches."  You can also choose "unmerged matches initiated by me."  Some that I've done required minimal research, didn't take long at all.

---

I agree with Robin completely. Some of these proposed merges can be default approved. That leaves the merge and the approval with no one taking responsibility. Each step of the process should be carried out with care. If a merge is default approved, that still leaves two members who have checked carefully. To say that it is the responsibility of the person who completes the merge also ignore the responsibility of the person proposing it to check to see if other connected profiles need to be merged as well.  We are all responsible.

---

ok so I was working on getting rid of duplicates in my NNS people and I began going bottom up but quickly realized, and I do not think it has been said in here and I think it should be- that we ought to start from the top down - as when we look at it from the perspective we have - there are a whole bunch of ancestors right? BUT if you look at the big picture one ancestor goes down to a lot more descendants and so if we start with the earliest person on a branch that has duplicates needing merges and work down from there it should be a easier task

or do I have it backward?

---

Navarro...

If you start with the "oldest" relative, then as you are doing the merges you will see all the duplicate siblings and children, much easier to catch all the duplicates that way.

---

Working on the Australian Suggestions Report, I have come across some extremely BAD merges, that have taken me ages to correct. It is the responsibility of the person proposing the merge and the person completing the merge to make sure the profiles are for the same person.

Of course in an ideal world, if the profiles had Sources, date of birth & date of death (or approx) and PLACE NAMES this might help stop the BAD merges.

It took me about 5 days to sort out a BAD merge that had happened joining an Australian family with a family from the United States.

Answer 1

Sooner or later, someone's got to do the hard genealogical research of getting real data with sources.  My experience is that a lot of controversies go away when you've found the actual facts.  

So with merges -- it feels like we're trying to decide who has the responsibility but nobody wants to do the work.  Often if two people need to be merged there's a whole duplicate family out there, often one or both of them are unsourced.  So it seems to me the best principle is "in for a penny, in for a pound."  If you're going to bother at all, do it right, do the research, propose all the merges from the top down.  It's nice if the profile managers are involved, but my experience is that a large numbe of profile managers listed on files I work on have not posted on WikiTree for over a year.

Comments

Jack....your viewpoint is well taken and absolutely where I was headed.   Too many people just proposing/doing merges because "it looks like the same person, or worse, because the DB_errors indicate that they are the same.

---

Proposing a merge only calls attention to it and puts it on the general to-do list.  Before wasting time researching it, bear in mind that somebody else might know the sources.

If you want to work on a merge, it makes more sense to pick one off the list that's already got approvals.  Then, having figured it out, you'll be able to go ahead.

Working on a cold merge is often a waste of time, because in the end you might have no control over how it gets completed anyway.

I've wasted a lot of time untangling and merging up whole families, on paper, only to have the whole operation blocked by people (Leaders actually) wanting to do the whole job themselves.  But I've learnt the lessons.

---

My suggestion how to propose a merge and describe why in a Research Note see G2G Best-practice-merging-and-how-to-document-sources

I tried use a Free space page it can be included in the Research Notes on more profiles....

Feedback is welcome and I think we need some kind of template of headlines that should be included.....

The background to this case is a new WikiTree user that got help with finding Swedish roots that we documented etc...

and then the GEDCOM import bomb from Ancestry exploded in the well sourced family tree ;-)  and created unreadable profiles with vague sources and sources repeated every where, duplicated profiles.... plus that some of the profiles should be merged... some had just one parent. The dates are from census ==> its Census year minus age ==> abt born year...

so the challenge is 

1. communication
2. find sources we both trust
3. new WikiTree user and getting interested in start the odd thing called merging....
4. messy imported profiles that are impossible to read if you don't clean them..... 

Lesson learned from this exercise

1. Cleaning a GEDCOM import from Ancestry is one of the most complicated tasks inside WikiTree.
   
   If people complain that using Templates is complicated then finding one source used every where and use #S-121212 that adds no value is more than complex
    
2. Its much better to have a source from Family Search that everyone can access and share (Question: Can we do screen dumps of the source?!?! , maybe a video of it is ok....)
    
3. WikiTree miss some kind of best practise how to work together on a merge inside WikiTree - correct me if I am wrong
    
4. Using an annotated Family Group Sheet
   
   
   Link bic pic
   Family Group Sheet
    
   1. Problem is children must be connected to both parents... to be seen in the Family Group Sheet
      
       
5. Research Notes is ok but...
   Its one way forward to use a Research Notes section but the profile gets messy. I vote for that we activates Talk pages inside WikiTree as they have on Wikipedia
   
   
   
   Maybe call a Talk page Research plan?!?! see G2G
   
   
   
   
   as other users can't guess we need to document our decisions and correlations of sources....

• MGP2 - Chapter 5 GPS Element 3: Analysis and Correlation
• Genealogical Proof Standard: Analysis and Correlation of the Collected Information

---

oh this is super helpful - thank you

Answer 2

It seems to me that the person suggesting a merge has a responsibility to determine that the two profiles should be merged, not just match names, the match bot can do that.

Comments

Agree and not agree....

1. The matchbot work is not genealogy its pattern matching
2. In the WikiTree community we have the Honor Code that we all agree with and tell us that 
   
   We cite sources. Without sources we can't objectively resolve conflicting information.
    
   1. Everyone creating a profile on WikiTree should help making it easy to resolve conflicts by adding sources..... 
      
      ==> the responsibility to do the work is everyone inside WIkitree and at least we could mark an unsourced profile with
      
      {{Unsourced}}
      
      to warn other people that this profile is not based on genealogy proofs and it's impossible to merge as long it has no proofs for the facts ==> can't objectively resolve conflicting information.

 

Answer 3

No, Robin, you're not the only one.  Of course the parents need to be checked.  I've had cases where I looked at two profiles for a merge, and ended up 3 or 4 generations up the line.  The last thing we want is to end up with more mess, instead of less

Comments

The solution is easy add sources ;-)

We cite sources. Without sources we can't objectively resolve conflicting information. 

---

IF you can find them.  That's sometimes much easier to say than to do.

---

Or at least mark them {{Unsourced}} so other people get warned

Answer 4

Yes, certainly we should address what to do when the parents, grandparents, etc are also duplicates.  I see this frequently. I note in the merge request that the parents also need merging and should be merged first.

I would strongly suggest NOT setting them as unmerged matches. That takes them 'off the radar' where they all too often linger for months or years...

Comments

Darlene, I'd like to agree & disagree at the same time. Yes, when proposing a merge we should always check prior & succeeding generations. But I don't just check -- if the entire branch is duplicated, I start at the top & start submitting merge proposals for each generation. I'll submit two generations, then make a note in my to-do list to continue to the next generation when those merges are complete. That way the ball doesn't get dropped... It also makes the actual merges a little easier, since the parents are no longer different in any particular generation.

Of course, this is far easier when the duplication was caused by having the same people imported thru multiple GEDCOMs... No worry there about whether they are really duplicates.

Answer 5

As always use sources... so other people on WikiTree understand...

From the honor code: We cite sources. Without sources we can't objectively resolve conflicting information.

What to do?!?!? 

Add a Research Note section to the merging profiles to prove your facts if it's not a obvious typing error... is the reason of a merge...

1. Example of content of a Research Note section
   1. Add sources so that each statement of fact has a complete and accurate source citation
   2. Add your analyze...

The profile manager receiving the merge request can't guess...

If you receive a merge request with no research ask for sources....

As new tools like the matching bot and the Database Error report is just based on pattern matching or logic we can use those tools but WikiTree is about Genealogy and should be based on sources

1. We cite sources. Without sources we can't objectively resolve conflicting information.

Answer 6

I agree the instructions need to be clarified.

If you see a likely merge, you should always propose it.

Otherwise we just get into the absurd situation of proposing a proposal.

Comments

Agree and not agree

Problem I see in Sweden where we have patronymics ==> every second person is called Brita Anderdotter or Andersson = Brita is the daughter to Anders.... see name statistics

When a happy WikiTree member or a matchbot start with no genealogy thinking that we need sources to prove the facts then you get a lot of merge requests that are totally uninterested....

So yes its ok to initiate a merge based on some vague criteria BUT its good if you have some genealogy skills in the area the person lived

As maybe 90% of the profiles inside Wikitree are GEDCOM imported and lack good sources we ask for a mess...

I think we need to take responsibility and follow up things like we do on G2G (we have statistic of up vote/down vote)

1. Number of merge request a profile manager received
2. How long it takes to answer
3. How many requests the profile manager  has rejected 
4. How many requests an user has created and got rejected.... 

     

Answer 7

I was already thinking about the way to improve Wikitree's merge function.

My idea is to compare also all relatives of merging pair. And then recursively compare relatives until they are the same person on both trees or enough difference is found on a pair not to be a match.

Although it would be on sunday's data, you would still immediately see all connected profiles, that also needs to be merged.

Comments

That would be AWESOME!

---

As always Aleš Trtnik you are right.

Why not let computers do what they do better than WikiTree users

Yesterday I tried to find an approach how to merging a family. And it easy and fast becomes a mess. Lesson learned

1. Ida in Sweden was Ada in 1880 Census in USA
   1. Ida Kristina Isaksson born 1867 jan 13 in Näshult, Jönköping, Sweden
   2. Ada C. Lindgreen born 1868 Sweden

==> you need to have some fuzzy logic

 

Would be cool if you also had the DNA information and could tell that check Gedmatch xxx and yyy to confirm match...  

---

First beta is done. View this post.

http://www.wikitree.com/g2g/270075/merging-by-breanches

Answer 8

I agree Robin. It sounds like the documented policy should be updated.

If one is going to propose a merge, then they should have done the research to support why they think the profiles match, including which conflicting data should be kept or discarded and why.

Clearly, someone has to do the research and make the decision. And if one has done the work, why not pass it along to help whoever is actually doing the merge? If they haven't done the work, how can they be sure the profiles in question should be merged at all?

Although, as I type this, I can see where maybe someone is asking for someone else to do the research. On the surface, they think its a match, but not sure how to research it further. However, with the current system, proposing a merge doesn't come across as asking for research help (unless they explicitly say so).

I've proposed merges where I didn't realize some of the differences. It wasn't until I actually performed my first merge, that I realized that someone has to decide. I have a few pending merges now that I'm still researching. 

The policy should include something to the effect... if there are any differences between the two profiles, please provide necessary sources to support deciding between which differences to keep and which to discard.

Comments

I think creating more policies does nothing but create a further non-user friendly environment.  If a user sees a possibly of a merge and is not the profile manager, there should be nothing wrong with REQUESTING /PROPOSING a merge.  The profile managers are those responsible to look into the merge and take appropriate action, It is out of the hands of the person making the suggestion.  I understand that if parents of a duplicate don't match, you can't complete the match anyway.  Perhaps the profile manager, assuming the managers are one person, was unaware the duplicate existed.  Alerting them of a POSSIBLE merge seems like a good thing without working on their family tree and sources etc.

---

In agreement Jim!

Answer 9

I can say I've honestly tried to examine whole branches right from the mergee profiles right up to the start of the issue... Which in cases is a great grandparent... so consequently I attempt to look back one step further.

It is hard though, on both me and my computer as we both try to handle the processing of it.

Answer 10

It is a problem in some of the lines I manage.  Sometimes the people in these lines reused child names after the first child with the name died.  In one case, 3 children all had the same first name.  Likewise, I have a string of at least seven Isaacs and it requires diligence to assign their children properly, also because multiple cousins are using the same names, too.

Unfortunately, it takes me a long time to be sure which is which.  I usually leave a note when I know there may be confusion, but sometimes I just decline the merge for the time being.

People don't seem to notice that the merged people don't share siglings even though one parent may share a first name.

Patience.

Comments

If I see a second use of name I first try to find a death record for the youngest sibling and then form a merge to reject it. It isn't fool proof but does give an indication to be cautious with the profiles. But rejecting merges has to be done only if you are sure. There are a lot of rejected merges that are plain wrong. Duplicate family lines that are caused by rejected merges are not good as the confusion increases as people start to correct one but not the other. I have seen some really crazy reasons to reject rather than be bothered to sort things out.