Using images to denote the "top of a branch".

Here are a couple of images anyone can use for those profiles

http://www.geni.com/photo/view?album_type=project&photo_id=6000...

http://www.geni.com/photo/view?album_type=project&photo_id=6000...

(see the ."photos for the project provenance & images" - http://www.geni.com/projects/Provenance-and-Images/photos/1020 )

They can be tagged to profiles you have permission to edit.

Could. Not. Disagree. More.

I also agree with Victar. Just lock the profile and add a Curator note regarding the parents.

Why?

1) Adding shell parents is both dirty and ugly, 2) adding generic images is expressly discouraged.

I use shell parents if there is misinformation out there about the parents that would lead to merging in bad info. In most cases though, the shell is sufficient, particularly if MP'd and locked. I guess to me it seems redundant and decreased tree performance. So, while I don't mind, why spend time doing it? Seems like a waste of ones time when there are other things to get done in the tree. Perhaps problem areas for profiles that haven't yet been locked.

Right. We have the ability to lock profiles for a reason. To not make use of it seems silly to me.

It's probably worth noting that users have been suspended in the past for adding N.N. shell parents en masse to the Big Tree.

Then I will be suspended shortly, Victar. It is the "only" method I have found to keep up with fictitious parents being added to first arrivers in Colonial America.

I do not fully lock profiles. That makes it more difficult for members to contribute to their ancestors profiles, merge duplicates, resolve data conflicts, etc. There certainly are tree areas that should be fully locked -- the 200 or so Bible profiles as example -- and handled by curator only. But those are not my areas. I am reliant on collaborator contribution.

It can't possibly be the "only method" as other curators, like myself, manage just fine without doing so. We're not talk talking about locking full areas here, just about top nodes.
As I wrote to Dan, this is a discussion to be had in the Curator discussion, not in a public forum.

The main benefit of adding "shadow parents" comes during a merge. If the profile has no parents, the person doing the merge can easily miss the problem.

Unless you know the line by heart or have a speedy reference, it's not clear whether the profile should have parents. Maybe they were erroneously disconnected. Maybe they were disconnected from bad information. Maybe they look wrong, but they're really right.

A good curator note can help. If the note says the parents are unknown, then it's clear what to do. If the note says the parents are unclear, or controversial, or "thought to be", then it can be a guessing game.

When I was a curator, this was one of my biggest frustrations. Some curators use shadow parents and some don't. It's almost impossible to help maintain the line if they don't. The bad parents come back again and again and again.

I hope the curators won't try to hide this debate behind closed doors. This is a case where the curators should be inviting public comment and participation.

I would prefer a public discussion. I curate in service of the members working on their trees, and what assists them in this task.

As a volunteer I draw lines on what I can and cannot do. I cannot maintain locked profiles. I'm impressed by those who can, but I cannot.

I did what is advocated here by Private User and Private User for several years and EVERY SINGLE TIME users merged duplicates and ended up adding the erroneous parents back in when there were no known parents.

The problem for those of us who work in the Colonial area is that there are tons of online trees and vanity genealogies that give parents names when there is no evidence for them, based on no evidence. Often these parents are nobility too LOL.

We've had this discussion many times. Those of us who work in heavily trafficked areas of the tree have found that the so-called "shell" parents are the only way to prevent having to fix the unknown parents over and over.

MPs of unknown father of and unknown mother of. Locked.

Oh yes, and Curator's Notes too.

Importantly, I do not do this routinely, say for the parents of families from Eastern Europe, but only as a last resort in areas where there are thousands of descendants and a lot of adding of duplicates and merging.

Yes, of course. My own direct (obscure) ancestors need no placeholders when "we know no more.". So use there could indeed impede genealogical research.

There were some 30,000 first arrivers to New England, and only a couple of thousand (as Justin taught me) have known ancestry ... And of that known ancestry, often can only go back a Gen or two.

They also had appallingly few names and similar dates & locations, so even when there have been good studies, it is easy to mix them up, or make creative family leaps.

In fact much of my curating is requests for help from members asking for fictional ancestry to be gotten rid of on Geni. In service of our members I feel we owe it to 1) use our curating tools 2) empower them to maintain their lines. Fully locking profiles takes that away from members eager to contribute, it's their ancestor, after all.

If and when "relationship locking" becomes a possibility then the topic could be revisited.

When the erroneous parents come back after a merge, they can't be merged with the Unknown parents because the Unknowns are Locked too. This will leave a yellow triangle and then we split the tree. I don't mind it at all. I'm sure most users want accurate information and if we provide it, they will appreciate it if we can back it up with sources.

Mimi - the fully locked profile requires a curator only to work with it, whereas any member can resolve the parent conflict in favor of the "unknown" parent.

There are some 25,000 profiles in question for early New England, of course not all of them have fictitious pedigrees out there. But there are sufficient quantities that it is far more efficient for curators to provide the tools for members to align & correct "themselves."

This is a small point, but worth noticing --

I've often seen the shadow parents get merged with profiles for false parents instead of being disconnected. Having the name field locked ensures that the shadow parents continue to be Unknown Father (or whatever), but the merge can bring in false grandparents.

In some cases I suspect the merge has been intentional, made for the sole purpose of preserving as much as possible of the fake line. But in most cases I think it's been an accidental consequence.

I don't have an opinion whether it's better to fully lock or just field lock the shadow parents. It might depend on the traffic in that area of the tree, or on how easy it is for the typical user to spot the imposture.

Yes, dragging in a grand parent needs to be dealt with. Usually it comes to the attention of a member who can disconnect or raise the question to a curator. I try to add managers to the "unknown parent" for this reason (more eyes on).

I should have been clearer in my original note that I do NOT encourage this practice of "explicit unknown parents" en-masse ... only when there are lots of INCORRECT parents hanging around the Internet.

As Hatte & Erica can attest to, it is quite useful to prevent wide-spread mis-information from repeatedly being dealt with.

As they indicated, just MP'ing, even locking, the "profile without known parents" does not a-priori prevent erroneous parents from being "dragged in" by a merge.

Further, I encourage that the 'explicitly unknown' parents not be called simply "N N" ... I think that 'naming' the parents as "(unknown father of ...)' helps to identify that this is not just a simple "we don't know yet who these parents are" (which ought to be left blank, not have 'shells' created). Curator notes can also point out common 'wrong' parents to further discourage connecting incorrect parents.

The point about generic images in this situation is similar to that of "Died Young" images ... shouldn't be necessary, but they are extremely useful in reducing the number of incorrect merges.