Help:Project Protecting and Merging
Categories: WikiTree Help | Project Leader Help | Styles and Standards
Here are special instructions for Project Leaders on how to handle massively-common and historical profiles. For basic member instructions, see Help:Project Protection and Help:Merging. For the rules on living public figures, see Help:Living Notables.
Contents |
Which profiles should be protected?
There are four requirements. All four need to be met before protecting a profile.
One: They must fit within a project
Protected profiles must fit into a current or pending project.
Two: They must be 200 or notable
Do not protect any profiles under 200 years old unless they fit Wikipedia's guidelines for notability.
Three: They must have the lowest-numbered ID
If there are duplicates, only the profile with the lowest-numbered WikiTree ID with the correct Last Name at Birth (LNAB) should be protected.
If you're unsure of the correct LNAB and it has not been established in a style guide discuss it in G2G using the appropriate project tag, e.g. euroaristo, mayflower, etc.
To find the lowest-numbered profile you can go to the surname index page for the proper LNAB and resort it alphabetically and/or by birth date so that you can see the profiles for that individual. To see the WikiTree IDs, open the merging and matching options.
If there is no profile for the person with the proper LNAB, simply change the LNAB on one of the existing profiles from their edit page.
Four: They must be controversial or duplicated
Project protection should be used only when profiles need protection — because they are commonly-shared, frequently-duplicated, subject to confusion, etc.
There must be some sort of controversy or duplication problem, or reasonable expectation that there will be.
What protecting does and does not do
Project-protecting a profile does four things:
- It tells the WikiTree community that the profile belongs in a project. Major edits shouldn't be taken lightly. They should be discussed.
- It protects the Last Name at Birth. The LNAB on a protected profile cannot be changed and the profile cannot be merged-away.
- It protects the relationships. You need to be a manager of the profile, or a Project Coordinator or Leader to edit the parents, children, or spouses of a PPP.
- It protects against casual editing via GEDCOMs. You need to be a manager of the profile, or a Project Coordinator or Leader to edit a PPP using GEDCOMpare.
It does not prevent other profiles from being merged into it.
It does not prevent anyone from editing the profile using normal means.
How to protect and merge a project profile
Leaders can protect and unprotect profiles from profile edit pages. Look for the checkbox in the upper-right column.
All PPPs must be managed by a project and therefore need Project Boxes and a Project Account as a manager. See Help:Project-Managed Profiles.
Adopt/manage the profile
Profiles with a birth date or death date from more than 200 years ago can be adopted by Leaders even if they already have a manager.
If the profile is more than 200 years old click the Privacy tab. At the top you should see a link to adopt the profile.
If you know a person was born more than 200 years ago but their profile has no birth date or death date you will need to add a date before adopting the profile. This is possible as long as the profile is Open. If the profile is not Open, send an Open Profile Request. This form is linked from the PROBLEMS/QUESTION pop-up on profiles, or from the Trusted List box on the profile if the tree is private.
Merge duplicates
Do not start merging until the final WikiTree ID has been identified and protected. Merge all duplicates into this one profile. Do not merge duplicates into each other. This is very important. See the section below on the multiple redirects problem.
To complete merges yourself you will need to adopt both profiles (unless they are already "orphaned" or you are already on the Trusted Lists).
You do the adoption from the Trusted List page, i.e. the Privacy tab for the profile. Once you've adopted them, you can proceed with the merge.
Propose merges
If you prefer, you can propose the merges to the other managers. It's safe to do this as long as the ID is protected and you're only proposing merges that include the protected ID. However, only propose merges that include the protected ID. For example, you could propose that Schmoe-2 and Schmoe-1 be merged, and that Schmoe-3 and Schmoe-1 be merged, but don't propose that Schmoe-2 and Schmoe-3 be merged.
Remove extra managers
No profile should have more than a half-dozen managers. One or two is usually enough.
It's a good idea to contact Profile Managers if you're removing them and if this might come as a surprise to them. It could easily offend and upset new users who aren't familiar with how WikiTree works. This doesn't mean it shouldn't be done. It just means we need to be sensitive. This can easily be done by posting a public comment. Be sure to give everyone plenty of time to respond; everyone's schedule is different.
This could be an opportunity to invite the additional managers to actively participate in the project and take responsibility for managing a certain group of the profiles in it.
Note: Removing someone as a manager doesn't require removing them from the Trusted List. The member can still have the profile in their Watchlist and actively participate in editing, merging, etc., they just won't be the one getting the merge requests, etc. Therefore be sure to not use the the bulk "Remove Selected People" button below the Trusted List, as this removes people from the list altogether. Remove as managers by clicking the link by each person's name, instead.
Background: The multiple redirects problem
Here's why it's so important to identify the lowest-numbered ID with the proper LNAB and merge all duplicates into that one protected profile.
Merges create "redirects" — commands that tell web browsing software that a web page has moved and redirects the browser to the new page.
Let's say there are three profiles for Joe Schmoe:
- Schmoe-1
- Schmoe-2
- Schmoe-3.
You must merge Schmoe-3 into Schmoe-1 and merge Schmoe-2 into Schmoe-1.
Do not merge Schmoe-3 into Schmoe-2 and then merge Schmoe-2 into Schmoe-1.
If you do it the right way, these two redirect commands are created:
- If someone visits Schmoe-3 send them to Schmoe-1
- If someone visits Schmoe-2 send them to Schmoe-1
If you do it the wrong way, these two redirect commands are created:
- If someone visits Schmoe-3 send then to Schmoe-2
- If someone visits Schmoe-2 send them to Schmoe-1
Either of these will send visitors to Schmoe-1 but as you can see the first set is more efficient than the second set. In the second set, if someone goes to Schmoe-3 they are first redirected to Schmoe-2 and then when they get to Schmoe-2 they are redirected to Schmoe-1. It's two steps instead of one step.
With just three merged profiles, this isn't much of a problem. But if four or five duplicates get merged together into a long chain it causes problems.
First, it's inefficient. Our server has to work harder.
Second, Google won't follow more than three or four redirects in a chain. Let's say Schmoe-4 appears in Google search results. If Schmoe-4 is merged into Schmoe-1 Google will update its index and send visitors to Schmoe-1. But if Schmoe-4 is merged into Schmoe-3 which is merged into Schmoe-2 which is merged in Schmoe-1, Google won't follow the chain and Joe Schmoe's family won't find Schmoe-1.
Third, chains of redirects also make it much harder for WikiTree users to understand activity feeds and trace out the history to see which profiles were merged together. For example, let's say you want to know how Schmoe-1 was created. You can see on the Changes page that Schmoe-2 was merged into it. But then you'd need to go to Schmoe-2's Changes page to see that Schmoe-3 was merged into it. And then you'd need to go to Schmoe-3's Changes page to see that Schmoe-4 was merged into it. If Schmoe-2, Schmoe-3, and Schmoe-4 were all merged into Schmoe-1 it would be easy to see what happened, all on one page.
A tool for revealing multiple redirects: http://redirectcheck.com/index.php
This page was last modified 21:48, 26 January 2023. This page has been accessed 12,845 times.