Anna Magdalena Theron, b7c1 - name fields locked

Peter it has not been decided for sure that that is the way to go.
Due to the namegiving pattern in SA to many merges of whom a lot were wrong, resulted in that.
We tested and it didn't work.
In my family issues on one day in one case Anna had 130 tree (ooreenkomstes). Not one single one correct.
The name fields are locked after a discussion even from curator from around the world, has said that once we are thinking it is correct we can MP it and lock the fields required to ----voorkom--- those types of errors.
Any curator can unlock them.
Let us just give the poor new people a change to adapt to all the new features.
Hoop dit help.

Judi you are not correct in saying it has not been decided..... nor has any definitive testing been done......

On co-managed profiles it HAS been decided to default to the published Guidelines...

This issue has nothing to do with new features.

See this recent discussion regarding middle name field in relation to Tree Matches:
http://www.geni.com/discussions/139530

I have changed it for you Peter.... but there seems to be lots more like this, see for eg.
Martha Maria Haumann

Alwyn Francois van Heerden, b1c1d4e7f6

Jacobus Petrus Theron, a1b7c6

Only and only because I have asked a few times, at Geni head office, in Noah's time, in Hieronimari.
Mike Stangel could I please ask you to also give me some sort of answer here.
I would like to ask if it is fair to sit four 8 hours, just fixing merges, because of the name giving pattern in South Africa.
Is there a thumb of rule that must be followed?

I just don't get time for anything else than merges, merges and merges,- incorrect sometimes, correct sometimes, due to names fields and then merges because people don't follow through on there merges, adding, etc.

On only two profiles I added today from a death notice, I had to look at 98 and 153 martches.
In one case the name was Johannes Jacobus Botha-
Nothing else but the name Johannes were a match. The rest all incorrect. Parent, other names, etc, etc.

So no match and if I hadn't immediately on adding the profiles from my research in the Pretoria Archive, look at the matches, a lot of wrong merges would have been done.

Further more, Erica I think it was, in a previous discussion on this, said we must lock the fields of sources research work.

But in the last couple of days I had users asking me to please put a note at the top of one or more of the profiles they added and had to correct a lot of times, about every week. And will I please lock the fields for them, before it gets wrong again. Including the de Villiers-Pama numbering.

If I am a MP then anybody are more than welcome to send me researched proof and I will fix it for them, with the biggest love.

One user did also ask me yesterday and gave researched proof and photo's and I unlocked it so that he can change. He then send a message asking if I will please lock again.
I do hope this will clarify this.

I just want to carry on building the tree with all the research I have done, paid to get done, and just don't get time to add the sources and new profiles where everbody can benefit.

We counted over the weekend and here is close to 3000 photos and death notices that I just don't get time to add.

Regards/Groete
Judi

I do not have an issue with locking fields that have been researched. My enquiry was about the use of the first name field. I have in the past used all the names in the first field but have recently used only the first name in the first field and other names in the second field. I now find that after merges the names appear as peter william william instead of peter william. This then obviously results in a data conflict. Following the practise of then reverting to the guidelines brings me into conflict with users who put all names in first field.

Judi, none of us expects you (or any user) to sit for 8 hours doing merges and correcting bad merges. I'd like to see the Jacobus Botha match, as our matching algorithm shouldn't have shown a match if both profiles have immediate family members and there are no matching names among them. If you encounter another such match, please leave it and send me a link to the profile or the side-by-side match comparison page.

We certainly appreciate everything you do for Geni and other Geni users, but please don't work yourself to the point where you can no longer tolerate doing it. We can look for more people to help you, or just leave it for another day. Ideally we'd be able to spread the work among thousands of active South African users -- I'd be interesting in hearing your thoughts on what features would be necessary to accomplish this. One idea that leaps to mind, is to allow users to use the edit form to suggest changes on locked profiles, then you would only need to accept or reject the changes instead of unlocking, messaging, waiting, re-locking, etc.

Thanks for the response Mike. I personally use MP to prevent 2 similiar named profiles from been merged, no locking is required.

However on very well documented profiles where new and old information causes edit wars locking is the answer.

Judi manages over 24 000 profiles which could be part of problem.

Regarding the middle name issue, I share Peters frustration at endless data conflicts resulting from different use of the field.

Our Guidelines continue to be ignored because of the multiple Tree match issue.

Mike thank you for responding. It was night in South Africa when you answered so I was off. I get quite a lot of those similar to Botha and will certainly send you links.
My computor boffen son is staying in Cincinnatti so mom must sort these things out herself.☺
I really feel better today as I have decided yesterday to finish those and them start with all my death notice photos and start adding and loading.
Have a lovely day.
Judi

If a merge generates multiple tree matches, these tree matches should reciprocally then be visible to all managers of those profiles. Do curators get more or different matches than pro users? I am not seeing these huge hit totals. 2 to 3 per day max.

No Peter, curators receive the same matches.. Judi just manages 8 times the number of profiles you do...

However If you add a profile with a very common name.. like Johannes Jacobus Botha (which was added by Judi on March 27 2014)..

I can't find the profile you say you added on 01 October Private ...can you post it here please...

If I add a new profile with Johannes Jacobus in the first name field it generates 5 matches:
Johannes Jacobus Botha

If I add a new profile with Johannes in the first name and Jacobus in the middle name fields it generates 74 matches:
Unknown Profile

Don you won't get the one I had because I said they are not matches. Then before I say so for sure, it asks if I want to delete them because my family wont see it either.
So these 5 are then new ones.
J

Shoo you are fast Johann Ahlers

Those 2 profiles you merged were part of a test we are performing here...Johann..

No worry I will recreate...

New 5 match profile (now MP to prevent merge) Unknown Profile

New 75 match profile (MP)
Johannes Jacobus Botha

Judi these are new profiles... I can't find the PROFILE you created not the matches... Please place the profile here...

Mike Stangel can you comment on the false match duplication effect that Don is recreating two posts above?
5 Matches with all names in first name field: Unknown Profile;
75 matches if you use middle name field on the same profile: Johannes Jacobus Botha

It would seem to be ridiculous to use the middle name field if this is the result?

Sharon this is a very common name...

The algorithm is finding a lot of Johannes Botha's and a lot of Jacobus Bothas with similiar named parents...

It is only finding 5 where Jacobus Johannes is a double barrel first name... and thereby missing potential good matches

My apology, Don. Have kept my hands off since to allow you to run your experiment. You certainly fooled me!

See also this profile. In the revisions list Geni is credited with adding the name to the second name field. However the duplicate name is left in the first name field.

John Henry Henry Finaughty's profile was updated. middle name
Sat at 12:27 AM · view

John Henry Finaughty

Thanks Peter, there are thousands like that....

Unfortunately there is nothing we can do about it as long as people ignore the Guidelines....

Don,
My point is that persons are not properly checking for duplicate names when merging.

I agree that people don't check for and resolve data conflicts after merges - it has always been this way - people just don't bother after finishing merges.

It is very easy to see which profiles have been affected by your merge activity - from the profile page under Actions open up the "View nearby Merge Issues" - there are usually quite a backlog - if you arrange these in order of most recent first you will see your name in the updated by column - then work through them. If there aren't any check one of the other profiles you worked on.

It is only fair on the rest of the community! I am forever mopping up after people with very trivial conflicts such as these.

The findings on numbers of matches generated mentioned above are exactly the points made by Bjorn and Mike already in 1911 and which I brought up in http://www.geni.com/discussions/139530 requesting the status on the intention to replace the current tree matching algorithm within Geni with the more efficient Smart Match mechanism
Mike has got that request in hand and will as soon as priorities permit, attend to that.
Peter is correct in saying that persons are not properly checking for duplicate names when merging (from the list suggested in Tree Matches).
Regardless of your preference for name field use conventions, it is the responsibility of the initiator of a merge to "mop up" any resultant data conflicts for which agreement has been reached despite other possible difference in opinion. This mopping up , including the John Henry Henry's, is not always done, hence your frustration Peter and the Junes & others doing it in the end.

The problem with customising workarounds to suit ourselves for how we use Geni's naming fields - (instead of taking our objections to Geni) - is that you create two conflicting modes of filling in the naming fields amongst our users: making endless unnecessary Data Conflicts, as Peter is pointing to.

Exacerbating this is that on the Resolve Conflicts table, you are never sure if the Middle Name field is actually empty on the one profile (because it doesn't show as a conflict).
eg
FIRST NAME: 1)John 2) John Henry
MIDDLE NAME:1) - 2) -

When you resolve the conflict to conform to the correct Geni naming field standard, in this case- you lose the Andrew altogether (because you are unable to anticipate on the Resolve Conflict Table that the first profile has not got the Middle name at all, because it wouldn't show up as a conflict if it did, as the field on the other profile is blank)