Are you supposed to edit profiles before proposing merges?

Question

I see several members who are quite active that edit profiles prior to proposing a merge, and another member told me she was told it was OK.  I see this mostly where there are two children with the same name, or two spouses with the same name.   But dates, places, etc may be different, and there are no definitive sources on either profile.

In most cases when editing the profiles, the members do not add any additional sources, just adjust dates to match or places to match.   In some cases the change has mention of "why the change", such as the death date cannot be correct due to the birth of a child, etc.

In my merge proposal I will identify why I think the people are the same and why I think different dates or places should be documented.   But, I have never actually edited the two profiles to make them match, mainly because that one piece of data might be the reason that they are not the same person.

Thoughts?

Comments

Yes, I've run into this. You have two profiles that started out as the same person in the original sources, but they either got conflated with different people or they have wildly different guess for dates and relationships, so the profile managers reject the merge. Generally, it's easier if you just edit them first so that they're identical. I have tried skipping that step, but it creates less trouble if I pre-merge them.

---

I'm of two minds about this. It is never ok to "force" data, editing (or 'tampering' with) data in proposed merges where there are no validatory sources provided and where collation is still ongoing (which in the WikiTree context of continual duplication, is about always). There are however situations where validation has [dis]proven the LNAB and / or parentage (unless it is a deep ancestor and then merely coming to grips with one version of the spelling of a LNAB is already dauntingly challenging), and pre-editing either the data fields (because of WikiTree automated fill-ins that are not always accurate - i.e. place names, spelling of LNsAB beginning with particles) are compromised. All data needs to be integrated into the bio's of merged profiles; as well as the reasons some data does not 'fit' and the arguments based on solid sources. It can be facilitating in such instances to pre-edit the bio's and data fields. Personally however I only do this within the confines of [to be] protected project profiles within the context of validatory collation. 

---

Hi Robin

I think this is an excellent issue to raise - well done.

Personally, I have edited some profiles after either proposing them for merge or noting them as temporary 'unmerged matches'.  In doing so though, I have generally waited some time after the initial proposal and only after examining sources cited on each.  I can't think of a case where I have made changes and 'forced' a merge where there are conflicting sources and I would certainly never remove such sources.

In general, I have done this where there is a lack of sources cited and where I could not locate any to substantiate what is there.  That doesn't guarantee that what I am doing is right but, if the profile manager hasn't responded that it shouldn't proceed, it's difficult to know what else to do.  Most that I deal with are already duplicate spouses of another profile so clearly only one is correct.

Anyway, well done for highlighting the importance of us being careful not to just rush in to such matters.

Answer 1

Robin,

I too have seen this happen before merge proposes and thought it a bit odd.  In one case,  I felt the edits were made deliberately to have the merge occur,  even though the facts that were edited out might have left doubt the merge should occur.  (Sorry, this happened long ago and I don't recall the specifics.)

I like your approach best,  it provides  a more complete review of the facts.  BUT,  since the first profile manager to approve a merge gives the second profile manager the  "right" to edit the final profile.... I can see how this first profile manage might try influencing the edit.

This probably didn't help.... bottom line,  I like the way you approach the merge.

Answer 2

I seem to recall that this has been a discussion topic in G2G many times.  There's what is ideal, and then there's what is practical.  It is not only not rare, it is quite common that PMs reject a merge where ANY detail between two profiles is not the same.  They don't understand the concept of whether the two profiles represent the same person.  I've even seen some prominent Wikitreers, including Leaders, reject mergers that should be obvious with just a brief review.  Unfortunately, as Ben said, sometimes the only alternative is to pre-edit to get the merge approved.

Answer 3

Every year, more sites are available and more well-sourced facts come to light.  Sometimes, when I'm editing an unsourced profile, I build the facts from various sources before suggesting a merge, by looking for military service, the birth dates and locations for siblings, etc.  It takes more time, but it's like pounding stakes in the ground when you are setting up a tent on a windy day.

Answer 4

Well there are many, many different circumstances ... here is another one :)  Do you trust the Data Doctors to logically investigate problems and adjust simple found errors ?

Data Doctors try to fix problems that others have overlooked. As a data doctor, one follows an error suggestion to try and solve the indicated problem and try to correct mistakes. I had one case today where a man with 4 marriages including same marriage date with dups of 2 wives.

His profile had a previous merge with no cleanup. So doing that merge cleanup made me acutely aware of the source which identified who was the correct wife that matched the specified date and pointed out to me which wife had to have the wrong marriage date. I also did a quick online perusal of other online trees for some added confirmation. And I made a minor date correction to the second wife's marriage date.

I did this because as a Data Doctor, I have seen toooo many merges rejected based of one single discrepancy that can easily be resolved if someone would only investigate logically. Unfortunately some profile managers have busy lives and appear not to have the time or willingness to look if the current documentation would easily solve the problem and allow the merge to go ahead. Instead they just reject the merge so they can move on to something else.

As a Data Doctor one has to make decisions about how much work one will do on a single profile. I was there to resolve a marriage date conflict. I could have kept going and searched for the second marriage source ... but that was really outside the scope of why I suggested a merge. My thinking was that digging for a source belonged to the Sourcerers project ... or to the profile manager. My objective for today was the Data Doctor Challenge.

I did see another potential problem on the same family ... there was a duplicate child. I started to initiate a merge for him (which was not indicated by the Data Doctors Error Report) but I saw that one of the dups said he was born before his parents, so obviously wrong. I did not change that profile at all or initiate a merge. Since my task today was the Data Doctor's Challenge and not the Sourcerer's Challenge, I elected not to search for a source and instead I left a note on the duplicate child's profile asking the profile manager to check their research. As a Data Doctor, I have seen many profile managers ignore those kind of messages ... but we can try and hope they will go looking for a source to resolve the child duplicate problem and eventually it will be resolved.

Comments

Just moving on to the next Data Doctor's error and there is another example of 3 profile managers who have gone a year without resolving a merge request by doing the sourcing.

Elender Matteson  is married to a man by the name of Joseph Friend. Well there are 3 profiles for the same man who is supposed to be married to this one woman.

Friend-1155, Friend-1223, Friend-1320

Previous merges have been suggested but refused. I don't object to the refusal. What gets me is that there are 3 different profile managers and one year has gone by and no source has been added which would allow the merges to go through.

What good purpose is there for wikitree to have 3 repeated profiles for the same marriage, for over a year ... and how much longer.

Data Doctors see so many errors like this and can't do it all. It would be helpful to have profile managers donate some of their time also to help clean their profiles in the database.

Is there a project that works on merge requests that have been sitting waiting for a source for a long period of time ?

---

I've always thought the  "unmerged match" option needs work,  especially since there are no deadlines for action.  The profile managers shouldn't be able to stalemate the process.

---

Profile managers don't receive an email about an unmerged match the way they do for a merge proposal; there's a notification at the bottom of one of the Wiki Genealogy emails (where it's easy to miss if you don't read the whole thing every day), and that's it.

The person proposing a merge gets a field where they can enter their reasons for thinking the profiles are for the same person, but when they're proposing an unmerged match they don't get a field to enter why they think it might be the same person and what still needs to be researched to confirm or disprove that. The official WT position last I recall was that the person proposing the unmerged match should make a comment on each of the two profiles, which doesn't especially encourage the proposer to go into great detail unless they're good with copy and paste.

Sometimes the unmerged match *can't* be resolved with currently available sources, so I wouldn't want an unmerged match to automatically switch to a merge proposal or disappear after X time, but it might be useful to have a monthly email saying "here's all your unmerged matches that are at least six months old", or an email on the anniversary of an unmerged match being made.

---

Hmmmm,

I was really speaking to the situation where a merge is proposed, yet someone turns it into an unmerged match.   Apparently someone who first proposed the match thought there was sufficient data available to complete a merge.     Am I confused on this?????

---

We haven't really worked out what a merge proposal means yet.  It could mean

- I want these merged now

or only

- I think these are the same person, but they might need work, eg removing bogus connections, changing an LNAB, etc.  Or maybe they should both be merged into a 3rd profile

or only

- these could be the same person, I dunno, just saying the PMs might like to have a look.  (Which is what Matchbot thinks it means)

Answer 5

On the other hand - they may be different - I have a couple of things I have been working on that are the result of people merging different people together and let me tell you it is not at all pretty - one bad merge involves at least three different couples and some children and it is a real pain teasing each person out of that mess - another has at least three people with the same name that apparently all got together in Virginia (now West Virginia, but not then) to die in 1783!  No, certainly  you can edit sourced information but NEVER try and match up dates if you do not for sure know that the dates present before are wrong - you may be making a very big mistake!

Answer 6

Thanks Robin, changing dates on a profile or removing relationships, seemingly without any investigation or appropriate sources, just to facilitate a merge or to correct a suggestion, is something I find very concerning.

Like you I try to provide a lot of detail in any proposed merge, highlighting the similarities, and giving some guidance as to how differences might be handled.

Although like other comments I have come across merges being rejected for very slight differences, I think there are other ways of dealing with that situation, rather than pre-editing a profile to match and risk then merging profiles that are actually different people.

Answer 7

There's something wrong with the philosophy here. Because of the way I work I find lots of potential merges, some so obvious I cannot believe they're here. I have always proposed them to bring the matter to the PMs attention. Beyond that I've never felt much responsibility for them, especially when both PMs approve them but quite frequently they get left for me to clear up. I certainly feel no responsibility for changing data, looking up sources etc in a field know nothing about. I have however seen merges of mythical people rejected because the dates are out by 50 years or so. Lots of postponed merges get postponed for years. I'd like to see them automatically reproposed after say 6 months. Very often PMs see no responsibility for dealing with these.

Comments

I have come across managers who seem to have made a hobby of rejecting obvious merges because of some minor detail - when you check their contributions list setting proposed merges to unmerged matches is more or less the only thing they have done for the last six months.

Mostly I don't propose merges that I'm not going to be able to complete, because my list of merges that I have proposed is a tool for my "community work". When the ones at the top of the list go to 30-day default, that is my signal to do a new bit of work on that particular mess. It seems that most of the clusters I work on this way are managed by people who abandoned them years ago, without actually leaving WikiTree.

---

I've seen merges that were rejected simply because the manager wanted the merge to go in the opposite direction.

I usually sort out one profile with bio and sources (most of the stuff I work in is just gedcom imports with dead ancestry family tree links as 'sources') and then suggest merges, explaining what discrepancies I can in the merge suggestion comment. If either profile is linked to incorrect family members, I do correct that first so as to not propagate a problem.

Answer 8

So what should we do?  They say, add sources, but if you add the same sources to both profiles, that's prejudging the issue.  You don't have the sources that motivated the profile, and they're junk anyway.

I once had several failed attempts at merging yet another Arlette.  Her bio explained clearly enough that she was Duke Robert's frilla and the Conqueror's mother, but the DoB in the box was 200 years off.

One problem is that people decide based on the comparison table in the email without visiting the profile, so they don't even look at the bio.

Another problem is that people think their profile will be polluted if it's merged with an incorrect profile, even if they agree it's the same person.  So they block the merge until the other profile is correct.

The basic problem is that the protocol is designed for co-operating PMs, not for 3rd parties.  There's a basic presumption that the PM knows who the profile is.  Things tend to fall apart when this isn't the case.

Answer 9

I do research on profiles that have no sources and no profile manager or inactive manager. I don't want to merge two that are not duplicates but I will never just change the numbers to match the other. I've had people that didn't want to merge because that person is their relative and they are worried that their sources will be deleted. If I find discrepancies, I will do research on both profiles. I have many initial merges on my list that I can't continue the merge because of the profile being green and the profile managers won't respond. Some I've done the whole procedure for unresponsive managers and still nothing. Then I take a break from that and do my own family tree for awhile and then get back to the other ones.

Answer 10

My practice varies according to circumstances. If it is blindingly obvious from family relationships etc that the two profiles relate to the same person, but there are small differences in estimated dates, I will often adjust the dates to match each other. If I have good sourced evidence to hand that makes the two profiles come closer together, I will make appropriate sourced amendments. If there are differences in the spelling of what is really and obviously the same name, especially for pre-1700 profiles, I will make the two spellings alternates in the profiles, using the Other Nickname/Other Last Name fields, and include a note when proposing the merge to the effect that they are clearly alternative forms of the same name. I will also remove any GEDCOM junk. But, unless they are profiles in which I have a special interest, I do not do a lot of fresh research, and I do not eliminate information in the profiles unless I am absolutely certain that the information is wrong (in which case I may make an amendment with an explanation, and, sometimes, a Research Note).

It seems to me that what is a good guide on all this is a combination of common sense - doing what is self-evidently helpful - and thinking about what I would feel comfortable about if a profile was one I had created and someone else was making changes to it.

Finally, I never suggest merges unless I am confident the two profiles relate to the same person. I would rather us have more possible duplicates on Wikitree than merge two people who are not in fact the same. Wrong merges, as has been observed in some other answers, can cause a lot of work for those who later try to disentangle them.

Answer 11

When there are a number of children and a lot of merges I will typically try to get all of the info into one profile before merging so that no info is lost and it is easier then to do the merges and make sure the dates ad everything work before you run into trouble.  

If there is any conflicting dates or locations I indicate that in the bio and why I selected which one to display.  I also make sure to keep all of the old gedcom information and what it said so that there is a full paper trail including conflicts.  This makes for much cleaner mergers and makes sure no info gets left behind.  

I also make screen shots of the profiles to be merged away.