Merging Frustrations

geni have to step foward into reality.
correct spelling /writing should be acurate into the language from the profile origine.

ce nest pas la premiere fois que ceci est aborder comme sujet
malheureusement vous avez rencontrer ce dileme vous aussi.
seront nous a la creation de profile multi-language ou resteront nous a un unilingue anglais
question a debattre

Martin,

It simply is not that straight forward. Without knowing the specifics of the profiles Mario mentions it is hard to comment on his exact issue but for my self i have recently spent a lot of time working on medieval Alsace nobility.

The Alsace is now a French province yes, but previously has been a German province? So should profiles be french or german, or english (i dont speak french or german!)? Before you answer consider what language these people themselves would have spoken, certainly not french nor german as we know them, should i learn Frankish? Or should the tree be in Latin as most of the primary sources are in that language.
The tree as it stands is an inconsistent meddle of French, German, English and Dutch (presumably the Dutch influence is a relic of Gedcom imports) which is neither accurate nor satisfactory to anyone. However, i think choosing any one of those languages and changing every profile to suit would not necessarily be a good thing.

Mario,
If one profile is an MP it's data will over ride the other profile every time.
It might be worth checking the Actions menu of each profile to check if there are any data conflicts, i think it does happen that there can be data conflicts but the conflict resolution screen does not come up.
Also it makes a difference when you are comparing two profiles in order to merge them which side of the screen they appear on. I cannot remember which side dominates but there definitely used to be a particular way to favour one set of data over the other, it also used to affect who ended up as the primary manager.

Alex Moes,

Only a locked MP or one with field locking on it will override what is in the profile being merged in.

Kevin

alex why not learn esperanto ;p geni in esperanto am joking lol

Thanks for the clarification Kevin.

Martin, LOL, a good suggestion.

Kevin, do you know which side of the comparison screen has the bias?

I am too busy for experimenting now but will try and remember to check next time i do some merging.

Alex,

There are a bunch of factors that can cause a merge to go one way or another.

One of which is the number of managers on a given profile involved in a merge.

The second one is whether one profile is deceased and the other one isn't.

There are others that I cannot remember at this time.

Asking Mike Stangel for help in letting us all know how merges actually work.

Kevin

Thanks, Alex and Kevin,

One of the profiles that gave me grief is:

Bonifacio III Paleologo, marchese del Monferrato

I am not sure if I understand about MP: Do you mean that if a profile is MP, then when a merge occurs, the values in the "MP" profile take priority? Or do you say that, only locked fields are protected?

About the left/right side of profiles, I will experiment with this.

I am now finding merges kind of scary. I though that merging in the Big Tree was a good thing, that it eliminated duplicates and that it helped join different branches together and thefore making the Big Tree even more interesting. But now, whenever doing a merge, I am nevous (not enjoyable). I would be mortified if because of a merge I make, other members' work would be lost.

It is very scary that anyone in Geni (at least from Pro up) can merge any profiles. It seems to me that "merging" should be a privilege granted only when one has received training and is qualified to do merges without damages.

Anyhow, back to Monferrato...

For more problems with merges, see Discussion I just started -
http://www.geni.com/discussions/138573 (Didn't see this one till after I finished my comment there) -

Turns out Burial Data (at least when each Profile has info, and it does not agree) is as entered by the "Primary Profile" - no hint of the other info in Timeline or Data Conflict chart (I found the Data Conflict Chart, there were some Data Conflicts - this data just thrown out - so beware!!)

First of all, you need to look under Actions on the merged profile and see if you see "Resolve Conflicts". That is your opportunity to choose the correct values if there are conflicts.

It is my understanding and experience that if two profiles are merged and one had a value in a field and the other doesn't, that the one with the value will be chosen. For example in a period or language without middle names, if someone put a middle name, it will show up after the merge.

Also, the more complete value wins I think. A complete date versus a partial date.

The profile with the most managers "wins" and the MP "wins". You still have to go to Resolve Conflicts either under Action of, if you are a manager, in your Merge Center and resolve the data conflicts.

If you have profiles that are sourced with correct data and a decent About, you can request they be made into Master Profiles and even have the dates locked. That is a way to 90% ensure stability in lines that are well researched and documented.

Hatte, excellent directions. I will take the good habit of always checking for "Resolve Conflicts" in Actions.

I will keep looking Data Conflicts in the Merge Center too. However, I have seen bizzare behaviors in there. For example, the "Data Conflicts" tab would show a number of conflicts, say (2), then when I click on the tab, the number of conflicts turns to (0). Then I click away, and the number shown on the tab turns back to (2). I just gave up relying on this feature.

Have now found additional problem with merges -
if non-Primary Profiles has person as Deceased, Primary as Living - Geni accepts and enters as Deceased - BUT does not include anything other than the Data Fields Info from the Death Event of the Non-Primary Profile - specifically I observed Does Not include comments in Description, nor Documents attached to the Non-Primary's Death Event - in this "New" Death Event. (Nor does it concatenate the Old one!!)

Interestingly, the Documents were left going to the "Old" event, which no longer appeared in the Profile's Timeline!

When I go to merge two profiles and one is living (erroneously), I usually first go in and change that profile to deceased.

morel - the "counter" on the Data Conflicts in the Merge Center doesn't always keep up, there can be a delay of hours or days I think until it is refreshed. I just ignore it. Also, sometimes you resolve a conflict and the profile stays in your Merge Center which is annoying. Again, sometimes that seems to be a matter of syncing of databases usually but sometimes there may be a data conflict below or above that is causing that behavior, I suspect. Someone who pays more attention to the idiosyncracies of the program can likely explain this better.

But don't worry too much about any discrepancy of the counters in the Merge Center, that's been happening for a long time.

Everyone has their own work pattern, but if you are new to Geni it's good to ask more experienced members how they do things. Over time, you learn by practice what some of the more efficient ways of doing things are. I know that there are others who do things even more efficiently than I do.

By the way, I meant that BEFORE a merge, if you see one profile is erroneously marked as living, go into that profile and mark it as decease. Make sure to reload the compare profiles page before you merge to see if indeed they are both now deceased. That ought to address your issue Lois.

Keep posting issues or challenges. Some of them may be issues that the Geni team can address. Best however is to open a ticket for the kind of behavior that you describe Private User.

I realize that some people don't pay attention to the side-by-side compare profiles view in a merge and so if there are odd behaviors that should not be happening, we can't count on them doing as I suggest and first making the erroneously living profile deceased :)

But people SHOULD be paying close attention to the Compare Profiles and not merge if in doubt. Click on the Profile itself and go in and read the About and make sure it's really a duplicate and see which one is better documented, etc. Or contact the managers. Sometimes I send the Compare Profiles link to the two managers or to a curator if one is involved and ask about merges I am unsure of before I merge.

In this case, I could have done that. But in many where merging with Private Profiles, it is not possible for those of us not Curators to do so.

Do you have any idea - do all Curators when merging Private Profiles do so? When I do merges, I go thru and annotate for myself what I have before merging. But the two large sets of merges Curators did - no warning, so couldn't do that. Now that I know about the problem - will do so for those I can. And worry more about merges forcibly done by Curators.

My comment above was re: Hatte's comment that if one Deceased, one alive ( and she knows dead is correct) - she always changes to deceased first. (She got in two more comments while I was typing one response)

Now that I realize the impact (losing the non-Data Field info in Death Event), when able I definitely will change the living Profile to deceased.

BUT - when merging with a Private Profile - often for those of us not Curators it is not Possible first to change Data NOR to look at the About!!

Hatte - In those instances where users would like to change living status and/or look at About and/or see who has more Documentation, etc. - but cannot because the other is a Private Profile we cannot access till after the merge -- do you suggest we ask a Curator to do it for us? Or??

I actually did not know that there was a loss Private User, so that is useful information. I don't ALWAYS change the erroneously living profile to deceased but I prefer to. Also, I sometimes disconnect bad parents since it saves some time to do so before the merge.

Merging private profiles is a separate issue. They have to both be in the World Tree first of all and they need to not be claimed by close relatives. Curators should check first to see if one of the managers is a close relative and then stop and ask for permission.

I'm confused how you can merge private profiles but not edit them or maybe I need to go back and re-read.

When Geni gives a suggested Match - all it shows is the Compare Box. First side says yes, Request Merge -- without being able to access anything but what is in Compare Box (unless Profile or manager within his Max Extended Family). Then someone from the 'other side' has to confirm the match - and unless Geni now shows them as within Max Extended Family of the Profile or a Manager of it - the Compare Box is all they can see also. Once they accept the Merge, and the two are in fact merged -- THEN they have access to look at the merged About, edit the Profile, etc. Not before.

(I circumvented the system in the case I just did because I merged a 2nd Great-uncle with a recently-made Public duplicate of him -- which put those profiles then in my Max Extended Family. Without that, could not have seen or edited the profiles before finishing the merges.)

Above - am discussing Private Profiles.

I do not often merge private profiles so "anything" I say about merging applies to public / historic / deceased ( or should be) profiles.

If there is a data conflict after a merge, it is visible from profile view > actions menu > resolve data conflicts.

The "best practices" are, for me -

1) review the over view notes
2) if there aren't any - write them, including source citations
3) resolve data conflicts to the left. In the wiki process the profile furthest to the left is considered the "Main profile" (the most data enriched)

Re: naming conventions

There is a series of projects to address agreements for area / history / language specifics

If there isn't a project for the area being worked in - start one.

We've come up with some workable solutions to address multi lingual trees.

Hope this helps.

Erica - do not know if you are aware - currently Geni only considers how much data is entered if the two profiles have the same number of Managers - so -- if thru mergers or whatever, the profile with very little data but with two Managers is merged with a profile with lots and lots of data but only one Manager -- the Profile with very little Data but two Managers will be the Primary Profile (and appear to left in Data Conflict Window)

And this means exactly what, Lois? The "primary manager" is, I believe, only a legacy display. Messages go to all managers. The only other function I am aware of is "add manager" currently only routes to primary manager & an enhancement to go to all managers plus curator if any has been requested.

To clarify what should be in FAQ

Each field in the data conflicts resolve screen is separately selectable, not to mention that they can be re edited in the Edit basics screen.

So intelligent selection based on source is in fact quite possible.

Erica - In response to your "And this means exactly what, Lois?" --

I was responding to your statement "3) resolve data conflicts to the left. In the wiki process the profile furthest to the left is considered the "Main profile" (the most data enriched)" - seems to me that is saying that the "Main profile" was "the most data enriched" - and thus that the left-most box in Data Conflict Box could be counted on coming from the Profile with the most Data.

Since the left-most box in Data Conflict was from Primary Profile, but could not be counted on to come from "the most data enriched" Profile, wanted to clarify - without being argumentative or impolite or etc.

I may have misunderstood your statement. But that was the only reason I mentioned that there.

However - IF you had read my earlier Posts - You would have seen two additional, quite real effects due to which Profile is chosen to be the Primary Profile --

a) ONLY the Burial Data from the Primary Profile is used in the merged Profile (at least, where both have data) - and the Data in the non-Primary Profile does not appear in the Data Conflict Window, nor the Timeline, etc. -- just disappears.

b) IF the Primary Profile had the person living, the Non-Primary Profile had the person deceased -- the merged Profile will have the Person deceased BUT all info other than the Data (eg Description of Event, Documents attached to event) from the Non-Primary Profile's Death Event would be missing in the (new) Death Event on the merged Profile (nor is the old Death Event concatenated in the Timeline - simply missing!).

This is NOT why I mentioned which profile was made Primary in response to your comment above -- but I do think it is important.

(Your going on about the "primary manager" when that was not something I mentioned at all, as if in response to my comment, and when I had just recently been discussing these problems caused by which Profile was chosen as Primary seemed to denigrate these problems - which is why elaborating again here.)