Would it be possible to use the ID locking mechanism to identify historically-significant ancestor profiles?

Question

 

The idea of tracking and identifying historical ancestor profiles came up after a post by Chris Hoyt over in this thread.

 

I'm wondering if this could be done with our "locked ID" system. Supervisors use this to identify a WikiTree ID as the final ID for a person so that it can't be merged-away. We're thinking about using it in some way to limit merging-in profiles too.

 

We might expand this and use it as how we identify the historically-significant ancestor profiles in general. If a profile gets locked it could be highlighted or identified in some way in search results, FindMatches results, surname index pages, etc., as well as on the main profile page.

 

Comments

What would be nice is to have the search results sorted first by birth date, then by last/first name (in case wildcards were used), and then by profile number. You could easily see the exact duplicates, and the order in which they should be merged (into the lowest numbered profile). The lowest numbered profile should always be the historically significant/managed profile, that is now enforced by the new merge rules that prohibit merging from a lower number to a higher number. There is no ordering whatsoever of the results in the example results list.

---

Update: See http://www.wikitree.com/g2g/5298/what-should-badge-historically-significant-ancestors-say

Answer 1

I love Chris Hoyt's idea... I always keep going back to thinking of twitter profiles of celebrities where it has the big VERIFIED notice, we could do something similar... thats what I had thought about the badges on the ANCESTOR profiles for...

Comments

Exactly. Using the current locking mechanism to identify mature, historically-significant profiles would enable what Chris is talking about, and the badge-like images you've been asking for.

---

Love it! i want the badge to link somewhere useful like the euro ar i st o homepage or whatever is relevant

---

Right, the badge would be designed to draw visitors' attention, give a basic explanation, and link to more information. I think it would have to link to a central historical-ancestors explanation page, though, which would then link to the user groups and categories.

---

awesome... we could just perk up the h s p page a bit  and use that... don't think a badge page like normal badges would be that useful with a list of  50,0 00 profiles

Answer 2

As I don't know how the WikiTree works, this may not be possible, but here is another suggestion about Supervisor Profile Managers. 

If when you get a list like the one below, it would be very useful if those historically significant ancestors who have already been merged were identified by either having all the supervisors having a different identifying color, or the merged profile name having a different color, or both: and  would look something like example below:

• Samuel Davis 1640 Haverhill, Essex, Massachusetts - September 10, 1696 ~ Managed by Supervisor.
• Samuel Davis 1610 Gravesend, Kent, England - 1667 ~ Managed by Elizabeth Rankin.
• Samuel Davis 1638 Gravesend, Kent, England - 1718 ~ Managed by Elizabeth Rankin.
• Samuel Davis 1638 Gravesend, Kent, England - 1718 ~ Managed by Supervisor.
• Samuel Davis February 21, 1645 Roxbury, Suffolk, Massachusetts, United States - July 26, 1690 ~ Managed by Jennifer Shaw.
• Samuel Davis 1640 Haverhill, Essex, Massachusetts - September 10, 1696 ~ Managed by JD Wilson.
• Samuel Davis 1615 England - July 4, 1672 ~ Managed by Brian McCullough.
• Samuel Davis 1624 , , England - September 1696 ~ Managed by John Gile.
• Samuel Davis November 26, 1640 Haverhill, Essex, Massachusetts, USA - September 10, 1696 ~ Managed by Robert Weaver.
• Samuel Davis June 21, 1669 Concord, Middlesex, MA - ~ Managed by Dee Christophel D'Errico.
• Samuel Davis 1629 - ~ Managed by Allan Morton.
• Samuel Davis 1624 , , England - September 1696 ~ Managed by John Gile.

That way users would have an idea of which Sam Davis's on the list were already examined/merged/cleaned up - or whatever is done to these profiles - and then could connect their ancestor to the 'best' one of the correct date and location.

I guess the question is, can those Supervisors have a different color code within your system; or could the profile/person name in one of the completed merges automatically become a different and easily identified color code once the merge is completed?

Comments

Hi Chris. Yes, I got this from your other comment. I knew what you meant and I think it's a great idea. It's definitely doable. Whether it's with colors or icons or "Supervisor" labels or whatnot, I'm not sure.

---

We need a solution to this problem which stays in the spirit of WikiTree but protects these projects.  Does lock prevent me from claiming a person as a parent?  I could decide that I'm a son of president obama and simply put his profile in and as my father?

---

Hi Ed,

Three things to keep in mind:

1. You have to sign the Honor Code to add an Open profile as a relative. Otherwise, or if the profile is Private, you need to be on the Trusted List.
2. If someone makes a mistake, the mistake can be fixed fairly easily. The only mistakes that are hard to fix are merges.
3. If someone intentionally or repeatedly violates the Honor Code we can kick them off WikiTree so we don't have to keep cleaning-up after them.

Chris