Proposal to NOT allow merges of generations of ancestors [closed]

Question

When a Pending Merge is 'approved' currently, the PM is giving permission for other merges to be completed for 'five generations of ancestors' of the profile. See Pending Merges section in Merging Help page

Many people do not realize that this is part of the Proposed Merge process.  This one statement causes problems, especially when the PMs of the ancestors are different than the profiles that had merges proposed and approved.  The PMs of the ancestors are never notified and merges have been completed, sometimes incorrectly.  Since merges cannot be reversed, profiles must be created again, losing the 'lower' seq that they may have had, as well as the history of the changes and who made them on the earlier profile.   

A recent merge was done with no merge proposal found, so we can only 'assume' that there was an earlier merge proposed, although we have not determined what profile had an approved merge.  Five generations is too far to find what merge proposal allowed a later merge to be done with no prior notification to PMs. I have seen this happen infrequently, but when this happens, it is usually a serious problem. 

If a merge is completed because of default approval after 30 days, the 5 generation rule does not seem to apply probably because no one actually gave approval.

Recent G2G about this issue Merges without manager approval

My proposal is to remove the second sentence in the the Pending Merges section in Merging Help page 

From

When you propose a merge you are giving permission for others to complete it. You are also giving permission for five generations of ancestors of the profile to be merged.

to

When you propose a merge you are giving permission for others to complete it. 

Comments

This seems like a forgotten leftover from the early days - it may have made practical sense once upon a time.

Thanks for proposing this, Linda.

---

Thanks for that.  I have been brewing about this issue for a while.

---

Thank you for spotting this, Linda. To my mind, it is a clear anomaly, and if this is indeed what the system allows, it is a dangerous one.

---

100% agreement with this (especially as a 'survivor' of the the early "editbot proposed merge" debacle years ago and multiple firsthand experiences trying to repair the damage of incorrect merges).

I understand correcting the language as you've shown but shouldn't the coding also have to change to remove the automatic permission to merge the 5 gens?

---

Yes, that would need to be done if the proposal is agreed to.

---

The recent G2G https://www.wikitree.com/g2g/1105747/merge-was-way-too-easy-what-happened? is an example of the phenomenon that Linda is concerned about -- and an indication of how unsettling it can be for members to encounter merge proposals that are supposedly already approved, in spite of no history of a proposal.

---

Was there any conclusion to this proposal?

---

Jamie says it is on the To Do List.  Who knows when it will get done.  I have looked on Trello and I don't see it mentioned so it is anyone's guess.  

Unfortunately, we just have to deal with the issues until this is changed.

Answer 1

I agree with the proposal to change Pending Merges section in Merging Help page to only allow one merge to be approved.

When you propose a merge you are giving permission for others to complete it. 

Comments

I agree.  Merges should not be done without any notification to the project managers.

---

Merging 5 generations at once will generate MUCH more work for arborists and PMs to clean up afterwards.

We should only permit a merge to result in 1 generation to be merged at a time.

---

*gasps in horror* FIVE generations at a time! Ridiculous!

---

I think this is an important change to our present merge system. Each merge needs to be carefully considered. Some WikiTreers, especially newbies, may not give enough attention to whether or not profiles really represent the same person. When dealing with certain early eras and groups of people, you might have cousins in a generation in the same locale all sharing names with uncles and grandfathers. To merge them can create a real mess.

---

I totally agree with this Linda, although I have never seen it in practice. Yesterday I wanted to complete a merge which had had the 30 day approval, but both profiles had fathers which also needed merging (same inactive PMs)... and I had to propose the father merges before I could proceed any further.

---

Agreed!  And it made me smile to see no comments on the "no" vote side!   So, as the parliamentarian would say:

"Hearing no objection: So moved."

---

Makes me happy! After seeing it happened this week, it reminded me we had to do this

---

I was not aware of this and I agree that it should be changed.

---

That one is a new one on me also, never noticed that, and I usually go up the line on needed merge proposals so the parents get covered.  Maybe I missed it because I deal mostly with early profiles that don't have 5 generations known before them.  

But yes indeed, this needs amending, and the automatic approval up the generations cancelled.

---

I had no idea!  All you see on a merge proposal is the comparison of the two parents and need to propose merge for them so the job appears to be done.  Yes please fix it.

---

I agree that it probably is time to change this policy. However, I also think it would be nice if it were possible to request a multi-generation merge in a single merge proposal, specifying all of profiles proposed for merging. That would, of course, require creation of a new technical feature.

---

Hi WikiTreers,

First, to clarify: multiple merges are never completed at the same time. What we're talking about here is permission being given from one side for multiple merges to be completed. Permission still needs to be given from the other side, and each merge still needs to be done by a member. (The permission and merge from the other side generally happen in one step, but still, each merge needs to be done by a WikiTreer, hopefully with appropriate care and consideration.)

Second, it's been mentioned that permission is being given to merge profiles for which the person is not a profile manager. Linda wrote: "If the profiles being proposed for a merge have the same PMs as all the ancestors 5 generations back, that would be fine, but normally they don't. Therefore when a merge is proposed for profile A and B, a PM of both A and B approve the merge, they can complete that merge, BUT that approval is also allowing any merge of A and B's ancestors to have merges proposed and they are 'automatically' able to be completed because the PMs of A and B said that 'one' merge was OK. ... Therefore the PMs of the 5 generations back have 'no say' in the approval process of their profiles since they were never notified of a proposed merge for the profile that they are PM of."

If this is happening, it's a bug and we need to fix it. (Jamie, can you test to confirm this? These are what we refer to as "implicit merge proposals". See BT #416 etc.)

Leaving aside the possible bug, do we want to make a policy change? It would be a significant one. The current system may seem a little wonky, but it's been in place for over 10 years. The consequences of changing it, I think, would be much more troublesome than most members would imagine. There would be far more merge proposals getting emailed back and forth, far more delays for permissions, and all accompanying frustrations. And, of course, more duplicates that never get merged. Making the merge process slower and stickier may cause more problems than it would solve.

Chris

P.S. I do think Ellen's idea is worth consideration, i.e. a technical change that would show all the potential merges for which permission is being given. If the user interface was done well that could be great.

---

Chris, Thanks for weighing in. If you think it is a bug, then it does exist. I have sent messages to Jamie a few times recently where the problem has been seen and the answer has been the 5 generations back approval was the reason.

When it is different PMs, it has caused some PMs frustration because they would not have approved merges that were done. Changes log shows no proposed merge and Nothing can be determined what proposed merge triggered a possible 5 generation merge.  If a proposed merge is automatically allowing 5 generations to be merged, then those merges should be automatically proposed so it can be seen for approval, but I think it should be handled as individual proposed merges.

Personally, if I propose a merge, I check up and down a tree to see if there are duplicates with parents and children, and then I propose a merge for them. I don't 'assume' a 5 generation merge can happen or be approved. Personally, I think each merge should be done individually to ensure that each possible merge is looked at individually. When someone does an approval now, they don't look to see if they are possibly approving 5 generations. I have completed merges and had to propose another merge because the merge of parents was not proposed at the time of original merge proposal, but that is probably because I am doing a merge from default approval status.

Unfortunately there are people, not Arborists, that go through Proposed Merges and complete them, without checking anything because 'They are allowed to complete them, so it must be correct.'  It is stated in Merging Help page that each merge should be rechecked at time of merge, but many people think it must be ok. We see plenty of people being referred to Mentors for doing improper merges. Unfortunately when a merge is approved because of default 30 day inactivity status, some people don't understand that doesn't mean it should automatically be done.

---

I agree with Linda. Each merge should be completed individually with careful consideration. There are merges being completed without a proposal and approval that can be tracked. I can't even think how often it would be feasible that five generations of profiles should be merged with one approval.  In the early days of WikiTree where there were massive duplicate GEDCOMs being uploaded, the need for merges of five generations at one time made sense. Not anymore. With the changes made in the way GEDCOMs are uploaded, huge trees of duplicates should not be making it through the process. And there are tons more WikiTreers, some very casual users who don't always understand the need for careful merging. Safeguarding the progress made on family tree lines should be prioritized over speed in merging, I think.

---

I totally agree with Edie, don't know how often I have had to recreate profiles and sort out which children belonged where because of careless merges.

---

Edie's comment about the reduced number of many-generation duplicate trees is similar to what I was thinking when I said that it probably is time to change this policy. I do still find multi-generation trees that need merging, but they are not nearly as numerous as they once were, and nowadays they usually were hand-added by a new member, and there often are differences between the new tree and the existing content (different parents somewhere in the line, different spouses, etc.).

I don't know whether there is a bug related to multi-generation merge approvals, but I do know that I sometimes run across a pair of profiles that I believe are duplicates, but have no history showing them as ever being marked as matches, yet when I go to propose the merge (and dutifully explain why I think they are duplicated) I am told that an approved merge was found so I can proceed immediately to complete the merge. I find that experience unnerving. I have no clue who proposed the merge that caused this pair of profiles to be approved for merging, nor when it was proposed or why.  And (if I remember correctly) because the merge has been approved the system will not let me convert it to an unmerged match, which I may want to do if I am uncertain whether the merge should completed.

---

I could see the "5 Generation Rule" being a problem if profiles which are PPP under a Project were incorrectly merged because further down the line someone approved a merge to fit with an incorrect history of that line. Once a contentious family had been straightened out by a Project, it would be very frustrating to have it muddled again by a merge series which the Project had no control over.

I would argue very strongly for each merge to be taken on its merits no matter how long the process took, with all PMs (including Projects) having the right to approve or decline that merge.

Declaration of interest: Managed Profiles coordinator for the England Project.

---

I had - like many others - no idea about that rule, and I agree to only allow one merge at a time, and if it's only to have a closer look on the older generations to see if they are *really* the same person. Often enough there are different people with the same names.

---

And different PMs than the original proposed merge, so they are not notified. Those ancestor profiles need the same scrutiny!

---

Can we get an update on this proposal that was approved in G2G over a year ago and it sounded like it would be done?  I don't see it in the list of things being worked on in Trello, but yet we are still having issues with this problem. PMs are not notified and merges occur, many that should not be done. 

See Recent G2G question

If more merges are proposed by stopping this rule,  that is what should be done to ensure that all PMs are made aware of a potential merge. If many of us are proposing each merge now, the PMs not being made aware, is occurring when others have not checked all generations and this rule is being used, probably by accident, or because someone realizes more merges are needed. 

I have proposed merges manually 5 generations back because of duplicated lines, but I seldom, if ever saw the same PMs on all profiles. 

Answer 2

I disagree with the proposal and want the existing Pending Merges section in Merging Help page to remain as it is, allowing other generations to be merged with approval. 

When you propose a merge you are giving permission for others to complete it. You are also giving permission for five generations of ancestors of the profile to be merged.

Comments

I must be missing something but I do not see the issue other than duplication causes a lot of work. Wether one profile or 5 generations of, there is always a lot of work (collateral damage) for all involved. And working in projects, the generations ascending or descending have to be merged at some time or another. Merges can only take place after a merge proposal has been done and the profile managers having given permission. And if a profile manager does not respond immediately, the respite of 4 weeks give ample time before anybody can complete the merge. I read the link referred to above and do not see any issue, and I perform and propose thousands of merges per year.

---

The issue is, I believe, that the approval is thought to be only for the two profiles, whereas what is actually happening is that default approval is being given for extra generations that have not been vetted for merging.

---

Melanie is correct.  If the profiles being proposed for a merge have the same PMs as all the ancestors 5 generations back, that would be fine, but normally they don't.  Therefore when a merge is proposed for profile A and B, a PM of both A and B approve the merge, they can complete that merge, BUT that approval is also allowing any merge of A and B's ancestors to have merges proposed and they are 'automatically' able to be completed because the PMs of A and B said that 'one' merge was OK.  

Therefore the PMs of the 5 generations back have 'no say' in the approval process of their profiles since they were never notified of a proposed merge for the profile that they are PM of.  This doesn't happen very often, partially because we have so many profiles that get to the default timeframe OR when a merge is proposed, the ancestors / parents are reviewed for duplicates and are also proposed at the same time.  That is what I do when I propose a merge, but it is not always done.

If you would like to know of a profile that was recently merged with this situation, at least we think this is the situation because we cannot find the proposal, send me a PM because I don't want to post it publicly, which would call out the person that made the merge.

---

Ok, I believe you. A bug that was not noticed and fixed years ago. Though I can honestly say that I have not have that experience unless there is no manager on a profile at all. Or perhaps this issue only applies to arborists and the like.

---

Nothing to do with PMs on a profile. It is like proposing a merge of 2 orphan profiles that will go right into the merge process, but these ancestor profiles have PMs. It isn't a bug. That 2nd line is in the Help page, so it was intended to work like this.

---

Could you inmail me an example please Linda, so I can understand better? Appreciatively ...

---

Thanks Linda, got the email and looked at the profile in question. You are correct - there is no merge proposal. The text in the bio of the merged away profile does state 'do not merge into [...] {2 profiles mentioned} [unless] "do not merge his wife, with others, unless you correct the [.] line for [.]". This text could have easily been missed, though it does not excuse the merger from taking the responsibility for the merge. And merging a lower descendent having caused this conflation, is something that does happen. I however still don't see how someone can just merge an ascendent profile without that profile being orphaned, or one being on the trusted list or active manager, or the active manager giving consent. As I said - I do thousands of merges and merge proposals a year (at times also making mistakes - just this glaring one yesterday), and never came across the 5-generation glitch.

---

If you review the earlier g2g you will see that it has happened, not very often, but it does happen. When tech has been asked, their answer is that a different generation had been merged because of this line in the pending merges that I have proposed to be removed. If there is another reason, ie 'glitch' in the system, that allows merges to be completed without being proposed, removing this line, and related code, will the require tech to look at the problem for a different reason.

There are many of us that will look back through generations to propose all the duplicate profiles so we wouldn't be triggering this situation, but some don't.  Those that are approved because of default approval would not allow past generations because there was not an official approval by PMs.

Answer 3

Can we get an update on this proposal that was approved in G2G over a year ago and it sounded like it would be done?  I don't see it in the list of things being worked on, but yet we are still having issues with this problem.

See Recent G2G question

Comments

Linda, Chris is more likely to  see this if  it's  a response to a post he wrote.

Answer 4

Just wanted to update everyone. Jamie posted that all implicit merges from the 5 generation merging will be removed and 5 generation merges will no longer be implied when a merge is proposed.

Please see update posted on https://www.wikitree.com/g2g/1327208

Comments

Success! Thank you for bringing this up, Linda.

---

You are very welcome. This helps all of us.

---

That's brilliant Linda, thanks for bringing that to our attention.