Improvement: revised merge process

+5 votes
380 views

The current profile merge process suffers from several problems:

  • It is irreversable.
  • Who can merge is limited and not based upon merit or reputation.
  • Discussion and the log of changes of the losing profile is lost.
  • The reducing redirects convention of merging the higher-numbered profile into the lowest-numbered profile can result in a more complicated editing process if the lowest numbered profile is weaker.
  • There is only one shot at moving facts from the losing profile to the winning one.
  • Because the merge is irreversable and only a privileged few can participate in the editing, it substantially diverges from the wiki way [https://meta.wikimedia.org/wiki/The_wiki_way]
I propose a three-step merge process: initiation, collaborative editing, and finalization.
1. Initialization:
  • Anyone can initiate a merge process by preparing a merge proposal.
  • The proposal shall identify which profiles are to be merged (there may be more than two).
  • They should identify which existing profile is strongest/most complete/most well-written. That profile will serve as the base for editing the merged profile.
  • If not all profiles have the same LNAB, the LNAB of the merged profile should be included in the proposal. The final LNAB may continue to be discussed and changed during the editing process.
  • Sign-off by an expert may be appropriate in some instances, such as for pre-1700 profiles, before the process moves on to the next step.
Collaborative editing:
  • There will be one surviving profile and one or more contributing profiles.
  • The contributing profiles will be made read-only (but its wikitext still available for viewing and copying) and include a prominent notice that a merge is in progress with a link to the surviving profile.
  • The surviving profile shall continue to be editable. It shall include a prominent notice that a merge is in process and identify and link to the contributing profiles.
  • Anyone who could have edited the surviving profile before the merge shall be able to edit the surviving profile during this stage. Participation may be limited, of course, if the profiles were not open at the start of the process.
  • If the merge is of profiles with different LNAB, the LNAB of the resultant profile may continue to be debated and changed during the collaborative editing phase.
  • The intention is that this phase may continue for enough time that anyone with an interest in the merge can have an opportunity to participate
Finalization
  • This would be an appropriate time for the merge to be reviewed and approved by an "expert", someone who has gained merit by the quality and accuracy of previous contributions.
  • The surviving and contributing profiles are archived
  • The archived profiles should be addressable and available for examination
  • The id of the merged profile is algorithmically selected from the ids of the original profiles so that it reflects the selected LNAB and would result in the most efficient redirection pattern (e.g. lowest numbered)
  • If the id of the surviving profile is not the same as the selected LNAB, the surviving profile is copied over the one with the selected id
  • The changelog of the new profile will start with an entry that this profile is the product of a merge of (list of the archived profiles, including links)
  • The new profile will start with no comments (or maybe the comments from the merge process could be retained or copied in)
  • The merge could be reversed by restoring the archived profiles
I'm sure that if this proposal should end up being seriously considered, the final result will not be exactly as described, but I hope that this can serve as a starting point towards developing and implementing a merge process that is more in keeping with the wiki way.
in WikiTree Tech by Randy McLaughlin G2G3 (3.9k points)

1 Answer

+12 votes

Hello Randy 

While your idea has merit the problems you suggest are not actually accurate.

  • Who can merge is not limited as any Wikitree Honor code signer can merge any profile baring the restrictions they would have in doing a normal edit. i.e. Pre-1700, Pre-1500, privacy locks, Project Protection status. Merit and Reputation has no factor in deciding who does a merge. 
  • Change logs are not lost and can be found if required
  • As the resulting profile needs editing anyway it doesn't matter if one profile was weaker.
  • As the change logs can be found it means that if sources and facts are missed during the merge process they can be found again.
  • While the merged away profile Wiki-ID is lost there is nothing preventing the wrongly merged away profile from being recreated which in effect reverses the merge. Therefore a merge is not Irreversible.
As for your three step process that is pretty much what is the current process but with a few unnecessary and time consuming steps. For instance needing a signoff by an expert or putting profiles into read only mode is adding complexity to the merge process. 
by Darren Kellett G2G6 Pilot (566k points)

Since Randy, and I'm sure many others, aren't aware of how to find the merged-away change log, I'll try to give an example.

Recently two profiles were merged by me:

Francis Billington (Billington-1050) was merged into Francis Billington (Billington-399)

If you display the change log for Billington 399 here, then at the top change in address box, where the URL is shown, from 

https://www.wikitree.com/index.php?title=Special:NetworkFeed&who=Billington-399

to

https://www.wikitree.com/index.php?title=Special:NetworkFeed&who=Billington-1050

you'll see the log for the "merged-away" profile. 

Darren's claim that any wikitree Honor Code signer can merge any profile (with essentially the same restrictions as if they were editing one of the profiles) doesn't match with my experience. I proposed several merges recently and in each case could not proceed because I was not the profile manager.

Part of what is frustrating and infuriating about the merge process is that people who have engaged in significant research into the individual or family are shut out of the process, while someone whose only contribution was the import of an unsourced GEDCOM years ago is given special privilege. I would prefer an open, collaborative process. Rewarding quantity over quality is not apt to result in quality results.
If we start with two equally contributing profiles, why is it that one profile's history is readily available while the second can only be seen by editing a URL or following a link that doesn't describe its target? Change history describes a form of sources that don't end up in citations. They tell us who contributed what and in what context. That history should not be tossed aside.

Let's say that doe-1 was imported from a GEDCOM years ago and never changed since then. Later, doe-2 was created and received many enhancements over the years. Merge them and the resulting changelog will show the GEDCOM import, the merge proposal and the merge. The history that would explain all the enhancements, on the other hand, may still be there, but hidden away where it's hard to find and as if it were somehow less important. If one profile, and its history, should be preferred over the other doe-2 would be the better choice.

The choice of which id should be retained by the merged profile would be better done by computer. If, using the lower numbered id convention, doe-3 was merged into doe-2 and then at a later date the merged doe-2 was merged into doe-1, doe-3 would redirect to doe-2 which would then redirect to doe-1. If a program were to actually test redirects it would find that the best way to avoid a chain of redirects would be for the second merge to also end up at doe-2 with both doe-1 and doe-3 redirecting to it.

The choice of which profile edits should be based on and the choice of which id the merge ends up using could and should be independent decisions.
Looking at the merges you proposed they were all proposed at the start of March. No other proposed merges are showing this year. Now there is a normal 30 day waiting period for anyone that is not the profile manager or on the trusted list to complete the merge. So if the profiles were not merged already then you would be able to have merged them around the 4th of April. That 30 day period is so the profile managers can look at the proposal and decide if it is valid. After 30 days anyone else can look and decide themselves if the merge proposal was valid.

They were only merged earlier because a Project Leader adopted the profiles and then processed the merges. Why that Project Leader got involved I have no idea. I also see in your contribution history that you have done a bit of editing on the resulting merged profiles. So you were not locked out from contributing to make the profiles better quality which you have done.
Finally, in response to Darren Kellett's critique of my proposal, I'd like to respond to his characterization of my proposal adding unnecessary and time-consuming steps.

Sign-off is an optional part of the process. It might be deemed appropriate for pre-1700 profiles, for example. The current process requires not just sign-off but active participation of the profile manager. It seems that nonresponsive profile managers often add unnecessary and considerable delay and complexity to a merge under current procedures. When sign-off is needed, the person or panel responsible for sign-off would presumably be active, committed members.

I may have been unclear in my proposal about what can be done programmatically. The finalization process might begin when someone clicks a button and then proceed programmatically. Within seconds, the newly merged profile would replace the one at the most efficient id. The old profiles would be archived and made read-only and replaced with redirects to the merged profile. Likewise, merge initiation would include a programmatic step to add notes and links to all profiles involved in the merge and to make the contributing profiles readonly.

Both the current merge process and my proposal have a proposal or initiation step, an editing step, and a finalization step. The most signifcant change for someone initiating or editing a merge is that editing begins without delay and is done collaboratively rather than by one person. Because of the collaborative intent of the edit step, that step should last long enough that other interested parties have reasonable amount of time to learn of the merge and participate.
I think there's a misunderstanding here, Randy. The profile managers are the ones who approve or reject a merge, and jointly the managers of the merging profiles collaborate on the "final product," the biography and data fields of the combined profiles. An "expert" as you call it would seldom be necessary as the profile managers themselves most likely have already done some form of research in the creation of the original profiles.

We have a process that protects the managing members from merges completed by others for 30 days, giving them time to research whether the merge is appropriate or not. As a profile manager, I would not be pleased if you merged a profile I managed without my collaboration because I was absent. I would also not want to relinquish my managing rights to determine the LNAB, content, and sources that are retained or removed. If I'm away for a few weeks, I am not abdicating my management by not responding immediately to your proposal. That it might be time-consuming for you to wait for my response is part of the collaboration process as we're all volunteers and work on WT when we have the time available. A member who is not a manager of one of the profiles involved certainly has input, and can provide appropriate support to the managers by providing sources that may lead to additions, edits and changes needed either during or after the merge.

Merges aren't something that should be hurried, but carefully considered by the managers of the profiles.
I sounds to me that you were annoyed at the fact you couldn't just merge these profiles straight away. Doing a Merge is a major step and needs to have an opportunity for collaboration from any affected people which is usually the profile managers. That is why there is a 30 day wait on any merges proposed that don't involve all the profile managers. Any other way is not collaborative. There is plenty of G2G posts where people are upset because other Wikitreers did edits and sometimes major changes to profiles (Changing parents for example). Allowing merges to be done straight away without allowing the profile managers to have a say is a sure fire way to annoy a lot of people.

As for which profile has merit or better history that could be very subjective to decide and would only cause further delays in the merge process as people would argue that one profiles history is better than another's. And It would not make any sense if an incorrectly named profile with a "Better History" was used as the change history on a correctly named profile. That is why the lowest numbered Wikitree ID is used (Or the correctly named Wikitree ID) and their change history is the one that is easy to find.

The history for the merged away profile can be accessed from the Merge statement in the Change History tab.  The statement initially has the names and dates of profiles being merged, then it has the 'merged away wikitree ID'' and the ''merged into wikitree ID''.  If you select the 'merged away wikitree ID', it is a link to the Change Log for that profile and you can easily go backwards through that change log to see what was changed.  By keeping them separate, anyone can see what was done on each profile.  The activity cannot be merged because you wouldn't know which profile the changes had been made to.

Merges were changed so that they must be merged into the lowest sequence.  Biographies 'should' be merged, removing duplicate text. All PM are retained on the resulting profile. 

Related questions

+15 votes
3 answers
+20 votes
2 answers
+43 votes
8 answers
+10 votes
2 answers
233 views asked Feb 8, 2016 in WikiTree Tech by William Arbuthnot of Kittybrewster G2G6 Pilot (190k points)
+17 votes
1 answer
189 views asked May 20, 2015 in WikiTree Tech by William Arbuthnot of Kittybrewster G2G6 Pilot (190k points)
+13 votes
1 answer
+22 votes
1 answer
325 views asked Jan 5, 2024 in The Tree House by Gill Whitehouse G2G6 Pilot (205k points)

WikiTree  ~  About  ~  Help Help  ~  Search Person Search  ~  Surname:

disclaimer - terms - copyright

...