Should we stop allowing GEDCOM bio updates to PPP profiles?

Question

When people upload data from their GEDCOMs to existing profiles, oftentimes they add some (or a LOT) of duplicated "sources", or "sources" from Family Data Collection or Millenium File or Edmund West, etc.

Some of the profiles they are adding to are VIP's (i.e., Mayflower passengers and the like). The additions these GEDCOM uploads have made are really unnecessary, and are cluttering up the profile.

Should we stop allowing GEDCOM updates to PPP profiles, in order to further protect these ancestors? I'm not suggesting locking down the profile - only cease allowing the GEDCOM update process to add to it.

One example is shown in the URL, but this applies more broadly than just to him.

Comments

A question for someone more experienced here than I am:  Does WikiTree actually benefit from allowing gedcom uploads at this point, given the offsetting problems they cause?  What would be the effect of disallowing them and insisting on manual data entry?

---

When I first joined WT I uploaded my entire tree as a GEDcom and then went through the ID process for finding matching profiles, 1600 in total.  I thought this was the best way to get my profiles into WT.

What a mistake.  I'm still finding errors from that process.  In the greeting each new WT users receives it should explicitly warn the new user not to upload an entire tree.  Even large group uploads can be a problem.

Since then I have never used a GEDcom upload for a profile.  I enter everything manually now.

---

I'm not against entering data by GEDCOM, but I AM against entering persons without any dates, places, or sources.  I don't think the Save button should be available until there's at least one date, one place name, and one source.  I consider profiles without any dates, places, or sources to be completely unacceptable.

Elsewhere, I believe Chris or other staff developer has said they are working on the GEDCOM import now, to improve source migration, lessen the link duplication and junk.  If that was improved, and some minimal requirements were placed on what profiles are allowed to be imported, I believe that would make GEDCOM import palatable.

---

I thought all the GEDcom garbage was old. I didn't realize that people could still upload these. When I joined a few months ago, what I remember is I could upload a gedcom and it could find me matches in the tree, but I still had to create the profiles I wanted manually. Which was great since it forced me to find and document my sources properly.

---

Tanya, the new gedcom process is still letting bad data through.

---

I love being able to enter new people via GEDCOMpare. It saves me typing and reduces the chance of my making a typo in the date or LNAB, while still giving me the chance to clean up the sources and bio.

However, I don't find it helpful to use GEDCOMpare to edit data in existing profiles. For the amount of effort the cleanup takes me, I'm better off manually adding my sources. And so far, no one who's edited the bio via GEDCOM on a profile I manage has made a useful addition; it's all been badly formatted duplicates of  sources already on the profile or Ancestry trees.

---

Hi Sharon,

I'm new to WikiTree and I agree with you.  Adding profiles by GEDCOM lessens the risk of typos but I also strip all the source material and manually add it.  It's actually quicker than trying to edit it.  It's also nice to be able to see a family group at a time.  

I guess the issue (might be) that it took around a week to work out my new 'system' so I'm now laboriously re-checking every profile from that week and adjusting the format.  Thankfully I didn't upload thousands of profiles and I'm down to my last 100 to check. 

I've also learned to focus on one small 'twig' at a time which has helped.

I would hate to see the loss of the GEDCOM uploading system as I have around 15000 people to add and I'm finding a lot of my research has not been added to WikiTree as it is South Australia specific so no shortcuts for me!  Furthermore, I think a 'system' is only as good as its operator.  I'm seeing good and bad manually added/GEDCOM added profiles and I think there "might" (caveat!) be an argument to be made that a bad GEDCOM upload "might" be an operator issue +/- bad data/poor research.

---

I'm in favor of not allowing GEDCOMpare to edit PPP profiles.

---

Limit GEDCOMs of any type to after 1800 or so, the earlier you go in time the more likely you are to find profiles already in existence in our tree.  Having to clean up GEDCompare imports is also an absolute pain when you have already done the work of sourcing and improving a profile to the best avaliable data on them.  See my comments below for more.

---

I don't know whether WikiTree has better coverage of the earlier periods, but my impression has been that coverage in any period depends largely on the specific interests of community members.  Some families or some locations will be heavily represented in the database, while others will be virtually ignored.

A bigger problem is that, the earlier the time-frame, the more likely you are to run into such inconveniences as missing (or never-created) records or the need for specialized research tools or expertise.  Thus, the earlier the time-frame, the more likelihood there is of running afoul of inaccurate, credulous or outright fraudulent published sources and the harder it becomes to prove or disprove their claims.  Then, as you've experienced, once you've managed to disprove some commonly accepted, published "fact," you have to deal with the would-be "corrections."

Answer 1

Plan B in GEDcompare is - don't mark the match, then use Add to create a duplicate, then merge.  With the new merging form, it comes to very much the same thing - EXCEPT the merging will probably be done by somebody else.

For the gedcommer this has big advantages - it's a lot quicker, other people do a lot of the work, and he gets to be a PM.  The downside is, some stuff might get dropped that he would have kept, but it'll be in the history.

A 3rd option would be possible, where you mark the match, but the system then creates a duplicate and immediately proposes the merge.  Perhaps that would be the way to go with PPPs.  The gedcommer wouldn't become a PM in that case (though he'd join the TL).  But he'd get his stuff imported, and the PM would then get the merge proposal and decide what to keep, if anything.

Comments

Maybe option 4 would be for the system to recognize a match for a PPP profile, and when it does, it marks the GEDCOM import person as one that has to be done manually - and doesn't actually create a new profile at all. Then the GEDCOM uploader would have to actually invest some time in determining what to upload, if anything.

---

In fact, perhaps it would be logical to have a general principle that a merge into a PPP has to be done by a PM of the PPP.

---

Would there be some way to add to that general principle so that the PM of a PPP would have to approve any addition of a child or parent?

---

I like option 3.  It doesn't completely stop people (the duplicate profile becomes a set of proposed changes), but limits actual edits to PM's of PPP's.

Answer 2

I totally agree that these shouldn't be allowed to happen, particularly if a profile has the PPP - Profile Protection.  Many of these profiles have been merged, and re-merged to get rid of duplicates, and clean up the bios, add sources, removed 'dead links' to internet trees etc.

The gedcom often introduces more dead links, info provided but unsourced which often is already in the bio and sourced, or has sources like S#2222 which means nothing.  Another clean-up is needed, only to wait for the next gedcom.

The person(s) uploading often are not familiar with project guidelines, and don't remove the material that is redundant and/or unsourced.  Or they remove redundant material, keeping what they added and removing the researched material, or they just leave it all, expecting someone else to do the cleaning.

I think the gedcom uploads in these cases should be prevented entirely.

Comments

I agree with you completely, Chris.  Gedcom uploads to PPPs should be stopped.

---

I also agree, Chris.  I had thought PPPs were already blocked from interference from gedcoms, but obviously not.

Perhaps requiring manual entries on all PPP and pre-1700 profiles would help.  Also, what about establishing a waiting period after signing up, or a minimum number of manually-input contributions, before allowing someone to upload a gedcom?  That might help ensure at least some familiarity with WT.

Answer 3

I've been entering my own tree one profile at a time for this very reason. I'd rather do thst than have 100s blank or screwy profiles to merge later.

Comments

I enter by hand - not that all mine are so great - but at least I am trying to do it right - research is needed on a lot of mine yet but I am constantly working on it and find more family to add so it gets complicated

---

I also enter all of mine by hand - and there have been a lot of them, but this permits me to control what goes into  the system..  It takes  more time, but is worth it.  I would also support eliminating GEDCOMs entirely.  They cause a lot of extra work.

---

Yes! I admit that many of my profiles only have minimal sources attached because I wanted to enter several generations quickly, so I could connect to later generations with existing profiles. I'll add more sources and improved biographies later. I much prefer this type of "bare bones" profile to all of the ghost profiles that were added by Gedcoms and then never looked at again by the person who added them. It's instant gratification for the uploader and requires no effort or genuine commitment on their part.

---

That is pretty much how I do it too, I had some GEDCOMS at one point but had not kept them because of a computer crash - and I am not really sorry because I was new to this back then and a lot of it was not sourced or even valid - I am glad I hand wrote the names dates and sources for so many and that I was super lucky with my mom's family that it ended up being from lines that were documented so well compared to lots of people - I really only have one "brick wall" left as far as getting back to point of entering North America - those that were not already here that is

Answer 4

I completely agree. I've had to clean up a set of profiles (prominent aristos) back in September/October which were polluted by a Gedcom upload - even the name fields had been changed around and were no longer what they should be. And so, Gedcompare is still doing this to protected profiles?

The rule is we should communicate with a project before making significant edits to a PP profile. Does GedCompare discuss before making edits? If it does not, then it should not tinker with protected profiles.

Comments

Well said. Gedcom uploads don't seem to require any communication before adding their content. Their uploads are definitely not in keeping with our policies for Project Protected Profiles.

---

I agree with S Willson, GEDCompare does not stop messing with PPPs, just saw it happen a couple of days ago.  :(

Answer 5

I am a newer member to WikiTree.  i have uploaded a GEDcom from Ancestry.com.  I am very grateful to be able to quickly upload my new people and match others with an already created profile.  But learning the hard way, I have no desire to create a mess for another profile manager.  I think if I add stuff that makes a mess, the Profile Manager should call me out on it and ask me to correct it.  In most cases, editing duplicated info/sources.  It is very hard to add from source information from Ancestry.com.  I try to find it on Family Search first, but I have had little luck with almost 650 of my own family members.

I would love to have a template for what information needs to be kept from an Ancestry resource.  I found some profiles through suggested links from a Project Manager in the Pre-1700. They were good examples and that was very helpful. I know have a visual of a great profile with good sources.  I would love to see a few examples of an Ancestry.com GEDcom upload as is with suggested edit below.  Or, perhaps a sample profile as it appears from Ancestry sources and a sample of what the cleaned up version would look like.  Kind of like a before and after.  

I do agree, we need something in place to prevent a lot of junk.  

And to all who have allowed me on your trusted list, I am slowly working to review and correct any junk I may have left behind.  Just message me if you find one.

Comments

Thank you, Janet. I wish more new(er) members were like you.

---

There are some good g2g threads regarding what to keep from Ancestry.com. Ales has been working on templates for "citations" from Ancestry that might actually lead somewhere. If I weren't on my tablet, I would copy and paste some links for you, but just do a search on g2g for ancestry sources or deleting sources from subscription services. Hopefully that will give you some helpful info.

---

Thank you, Edie.  I really appreciate the information about where I can find help in the area of editing resources from subscription groups.  This is so important to all of Wiki Tree.  New members need to be given the links and information when we join.  It would be very helpful to have more detail on the Wiki Tree Information for Policy and Style.  I know that I read the information.  

For All Wiki Treers--Keep asking specific questions on Policy and Style.  I am very impressed at how much help there is out there.

Answer 6

The text below is from the help-page.

Project-protecting a profile does three things:

1. It tells the WikiTree community that the profile belongs in a project. Major edits shouldn't be taken lightly. They should be discussed.
2. It protects the Last Name at Birth. The LNAB on a protected profile cannot be changed and the profile cannot be merged-away.
3. It protects the parents. You need to be a manager of the profile, or a Project Coordinator or Leader to edit the parents of a PPP.

If a new member adds profiles from a gedcom this is probably not something he/she knows anything about. It takes a while to get familiar how thing are (or should be) done at WikiTree.

 

My opinion is that either the PPP needs to be changed or the gedcom process needs to be changed.

Comments

Yet, we're still seeing problems on with parents being added.  My guess, after following a few recent discussions of such problems, is that this is happening because someone creates a parent (perhaps through a gedcom), then attaches the PPP as a child.  

It seems to me that, in the spirit of what project protection is intended to address, it would be appropriate to bar any attachment of a protected profile to another profile except by a PM (including the project involved) or Trusted List member.

Answer 7

Chris W. just reported this to me (and asked that I post it here):

"Today or tomorrow we are adding links to encourage project contact
when editing pre-1700 profiles.... [There] will be a status message you see when editing or adding pre-1700 profiles, including from GEDCOMpare."

Hopefully, this will slow down (if not stop?) the bad data that is getting added to new or existing profiles.

EDIT: He also said things are done in steps, and this is the next step. I add this because the solution above does not specifically address the issue originally asked about-- GEDCOMpare edits to PPP profiles (unless they're pre-1700; I suppose most are).

 

Comments

What project(s) did this?

PGM is examining its member list, but we haven't removed any badges... yet.

---

Yes, I've noticed my PGM badge is still in place, although I did make notification that I didn't feel able to meet the increased requirements for participation and so would opt out.  I didn't want to foul up whatever process there was to remove badges en masse, so I've just been waiting to see what happened to it.

I was under the impression that other projects were performing similar clean-outs.

---

Susan, I'll contact you off-board.

---

hmm, I know my project leader was looking at the project badges and the activity level of many of them a while ago.  Seems like not such a good idea.  I know of one cousin who is part of the project, but also has roots in Eastern Europe and was working on those lately.  Doesn't mean she's not interested in contributing to the project.

---

Periodically reviewing  and revisiting project involvement is a good thing.

I've found people who requested a project badge and never made another edit on wikitree after being awarded the badge or who have been inactive for years.

I realize that people's interest may vary. That's fine. But projects need active volunteers willing to improve project-related profiles.

---

I figure WikiTree has over half a million pre-1700s, maybe closer to a million.

Only a small minority of those are covered by projects like PGM and NNS.

Most projects don't work the same way.

PPP is the sharpest level of protection.  There's a wider set of profiles managed by a project.  And an even wider set of profiles watched by a project.

In principle that extends to 5,000 watched profiles per project.  In practice maybe up to 15,000.  About 1%, if all the profiles watched are pre-1700.

So most pre-1700s are unwatched.

Bigger lists can be built using categories and stickers.  About 25,000 profiles have the England Sticker, but they aren't all pre-1700.

Question is, what does coordination mean at all these different levels of project involvement?  How many profiles and contributors can a project coordinate?

More projects don't necessarily help, as they tend to just spread the same people more thinly.

---

I've never thought of myself as having an OCD in trying to follow rules and answer questions honestly (but maybe I am: I'm certainly obsessive in trying to find everybit of info about the profiles I work on)
  If being a member of the relevent project is sufficient to edit or create pre 1700 profiles then maybe it would be better if that was the question asked .Maybe some official guidance on what it is supposed to mean given. (fairly urgently before cleanathon)
 If membership of a project is also conditional on working within the guidelines re sourced evidence and naming conventions, then this could add a level of quality control. That seems sensible but feasible for the more widely ranging projects?

---

I noticed the new message on a few profiles I was working on the last few days and, in spite of being mildly OCD,  I chose to ignore it because:

1. I was not making any substantive changes to the profile,

2. I was simply moving the references tag under Sources, adding an Acknowledgement heading and an unsourced template, and

3. They were orphans from a gedcom upload from 2011.

I was working them in order to get the attention of people working unsourced profiles. They appear to be sourced because of the ubiquitous reference to So and so entered this on such and such a date.  I can't adopt that many profiles and most aren't even remotely related to me . I was hoping I wouldn't get my fanny kicked for ignoring it on the few profiles it showed up on, but these are profiles no one has touched since 2011-2012 and are orphans. I decided I would take the risk in order to try and save them from invisibility.

---

Thank you, Edie, good job!

You know, that sounds like something the EditBot could do, shouldn't be too hard to detect.

---

That would be great. I'm not sure how many profiles there are, but it's a lot. It's the upload of Christensen-519. She's no longer an active member. I still have a lot to go.

Answer 8

Every time I think about getting rid of the Gedcom process altogether (which is every time this conversation comes up), I then think about the gap between the number of profiles here and the number of profiles on other sites.  Geni.com claims to have 180 million profiles.  WikiTree currently has 17 million.  I'm not sure how many unique profiles there are on Ancestry and Family Search, but I'm sure both have many millions more unique profiles that aren't on any of the others.  My ambitious side wonders if there's a way WikiTree could get all that genealogy data and boil it down to something usable here, maybe even as a working family tree, waiting to be promoted to the status of a true WikiTree profile.  Gedcom uploads could also be imported using that same status: a working family tree which would only become full profiles after the user has achieved some facility with the site, identifying if profiles already exist for their working file, and determining if their research adds anything to existing profiles.  A pipe dream, I know.

Comments

More profiles, more Google hits, more money, more staff.

Quality sites don't do well in the league tables.

---

Yes, RJ, that's my feeling as well.  As I've said multiple times on this thread, I prefer quality over quantity.  But I have read the terrain on WikiTree over the years I've been here and it's apparent that the drive for numbers is not going to stop.  My point is that I can imagine a way to obtain those numbers that may be better in terms of both number *and* quality than what WikiTree is doing now.  I'm not sure if it's legal or feasible in terms of how the online genealogy industry works, however.

---

FamilySearch claims over a billion profiles. 

If WikiTree really wanted to emphasize quantity over quality GEDCOMs wouldn't be limited to 5000 and it wouldn't be required to confirm or reject all 10k or however many matches in the GEDCOM before you could add a single person. People with big GEDCOMs with lots of people already in WikiTree usually give up. But it's great for people who have GEDCOMs full of people that aren't in WikiTree yet.

And if WikiTree really cared about quantity over quality, the API wouldn't be read-only. The button to create a profile has to be pressed by a live human. No auto-created profiles allowed.

GEDCOM does not automatically mean junk data. The junk comes from inexperienced researchers, which are the majority of contributors to WikiTree. Watch the changes feed for awhile and see how much unsourced info gets in manually vs. GEDCOM. Unless we want to ban everyone who doesn't know what the GPS is, WikiTree is going to have to deal with the junk.

---

Yes, I agree, inexperienced researchers are absolutely the problem, in terms of quality under the current system.  And the most obvious solution to that problem, which has been suggested on the G2G over and over again over the years, is to not allow new users to upload a gedcom until after they demonstrate some experience and facility with the site (time or contributions or some other metric, any one of which would work).  The fact that they haven't implemented any such solution is an indication of the priority of quality vs. quantity.

---

Time and number of contributions can't tell you how good a researcher is or what the quality of the GEDCOM is. Who is going to volunteer to judge every new person to see if their GEDCOM is good enough to upload?

---

But time and number of contributions can indicate whether someone might have sufficient experience with WikiTree to be able to judge their own gedcom and make informed decisions about the edits.

---

Maybe. But take me for example. I joined in 2012 and added dozens of unsourced profiles. Then I came back in 2015 and added more unsourced profiles. So I had been a member for 3 years and had hundreds of manual edits. But the work I added wasn't quality work. And I had a fully sourced GEDCOM, I was just too annoyed to open up each source in my software and copy/paste it into the profile. Higher quality profiles would have been created from my GEDCOM.

---

Well, none of these detailed questions regarding the suggestion to restrict gedcom uploads are relevant, are they? WikiTree isn't going to implement that suggestion so it doesn't matter how it would work in practice.

---

lol, I started some years ago with GEDCOM imports, my data was actually fully sourced mostly (Drouin collection is good for that), but I didn't enter my sources in the other program.  So of course they didn't show up when I imported my tree.  Still having to fix some of them, it takes a lot of time along with everything else I do on here.

---

Many of the profiles I've edited from GEDCOMpare are profiles that I created manually. I didn't create them without sources, but (like Jamie) I didn't take the time to open up each source in my software and copy/paste it into the profile. With GEDCOMpare, I've been able to find content and sources that I didn't bother to add the first time around. Then I evaluate the content to determine whether it's worthwhile to add (sometimes it's good, but sometime it isn't).

Answer 9

I've experience not only Duplicates but it STRIPS a lot of things too like media files.   I know it was the only way to get my FTM files moved to other programs but it removed a lot of stuff and now I'm dealing with 2, 3 and more duplicates which almost doubled my tree... what a mess !   I'm going thru the entire thing one by one.   In the last 6 months I've deleted over 10,000 duplicated files and many more to go.   :(

Comments

Yes, WikiTree GEDCOM imports don't import media files, whether the media were in personal software or on a website like Ancestry.

I think that the handling of media files in GEDCOM exports and imports is at the root of some of the biggest problems we have with profiles created from Ancestry.com GEDCOMs. Ancestry users are encouraged to add "facts" to their family trees and to source those facts by creating links to media files that exist only within Ancestry. Those media files don't get exported when a GEDCOM is created from Ancestry, nor do they get imported when that GEDCOM is uploaded to WikiTree. As a result, members who felt that they had attractive and well-sourced profiles in Ancestry may discover that all they have imported to WikiTree is a handful of factoids and a collection of ugly-looking Ancestry URLs that in many cases aren't even accessible to Ancestry members.

Answer 10

It would be so much easier to support this if we didn't have so many utterly screwed up project protected profiles in the first place, in other words, if we would have some quality control in place before a profile gets project protected. And then, yes, by all means, content of the biography should be also protected.

Comments

Are uncontrolled gedcom imports one of the factors causing the screwed up project-protected profiles?  If so, then controlling them make sense:  At the least, stop (or reduce) the on-going damage while the project works on cleaning up all the profiles it protects.

This, of course, assumes that the project members will have more time to devote to cleaning up all the PPP biographies (and parent or child attachments), if they aren't side-tracked by the repeated need to salvage some of them.

---

My only concern is that project protection sends the wrong message to people who are not familiar with the very limited scope of protection. And consequently, I would feel much better if project protection would not be slapped on profiles before they are checked for some minimum standards of quality - such as is there any evidence they have actually existed. So for me the discussion about having to protect the few good profiles in the sea of dubious ones makes only sense when we at the same time address the quality issues.

---

I see your point. I had thought one of the criteria for earning project protection was a developed, documented biography, but I did recently run across a protected profile which was little more than a gedcom dump documented by a family tree (with a broken link, naturally).  Perhaps a first step would be for projects which are protecting profiles to re-examine all the profiles on their lists, then eliminate protection from those which don't meet the standards - or, of course, bring them up to snuff.

But, in the meanwhile, stiffening the protection makes sense to me: finger in  dike, so to speak.

---

some PPPs are applied to get a pending merge frozen in direction, with name variations being the problem they are trying to solve.  Only they get forgotten there after the merge is done.

---

Could a list of such non-project PPPs be generated?  Perhaps that would be a start on winnowing the number of profiles being protected - so the remainder could be more easily worked on and their additional protection justified.

---

don't know, talk to arborists who are the ones who do this from what I understand.

---

Thanks for the suggestion, Danielle.  I have a query in to an Arborist, just to see whether such a list would even be possible.

Answer 11

I was not experienced enough to understand what was happening in Wikitree when I uploaded a gedcom.  I very much wish I had never done so because it introduced a lot of sloppy profiles.  I've been slowly working on them, but I sure wish I hadn't uploaded.  I think I would be comfortable with entering manually.  I find most sources can added to a profile with copy / paste functions either from my genealogy software, or by reconfirming the source on Ancestry or FamilySearch, etc..

Comments

The new GEDCOM import launched last September.

Now there is no bulk importing. People have to make a choice for every single person in their GEDCOM if they want the data for that person in WikiTree or not. If the person already exists then they get a merge-like screen, where they choose which data to use, and they are able to edit the biography before saving. If the person doesn't already exist they get sent to the add person page with the data pre-filled. They can make changes to the data before saving the profile. No data is added to WikiTree from a GEDCOM upload without action from the uploader.

---

Ah, that would be what I needed, and I think that would have worked for me.  I would still suggest starting off with a smaller number just to be able to see how it works and how much work I'll need to do to fix it up.  Even so, I think some folks might not understand that they are actually adding mistakes because of weak sources (e.g., ancestry trees as sources). Not uploading gedcoms or limiting the size, I suppose, minimizes damage by people who don't understand, but it would probably discourage others from adding quality work that others would love to see.

---

I have heard the same story over and over and over again from new users and from veteran users talking about their initial gedcom experience with WikiTree, Janice.

---

Jamie, I believe there may still be people uploading gedcoms with their fingers figuratively on the "go" button.  Just this last week I saw a situation - happily caught by Lisa Murphy (wonderful Arborist that she is) before it came to my attention and before it caused any damage - where someone doing apparently mindless entries tried to merge the profiles for two dead children of the same name (for whom I stand as PM) with the profile of a third adult of that name who happened to have died, in a different town and with different parents, within a few years of each other.

---

Jamie, every day (every day!) we see PPP'ed PGM profiles polluted by GEDCOMpare "edits". While yes, people still have to approve of their gedcompare edits one by one, it's still faster than manual editing without gedcompare. And the few active and quality volunteers we do have end up spending their time cleaning up these messes because most of the people using gedcompare with these profiles don't know what they're doing. I'd rather that PGM volunteers were working their way through profiles we haven't yet improved, not having to spend time re-improving "finished" profiles and chasing after newbies. Like I said, disheartening.

---

I'm thankful for this discussion.  I feel less bad about how I started out with my file.  Hopefully one day I get it all cleaned up.

---

PGM and a few other sections of the tree have issues with duplication and bad research. That's why PP exists and hopefully, after the discussion period, this policy will be approved.

But people are assuming that these issues are tree-wide, and want to ban GEDCOMs completely because of it. There are almost 800,000 pre-1700 profiles and many more that aren't in WikiTree yet. Most profiles don't have the issues that PGM profiles have.

---

Is it only "PGM and a few other sections of the tree" which have these issues - because of the particular challenges the research involves, I assume - or are the issues made more obvious in certain places because of project oversight?  As RJ Horace has pointed out here, only a very small portion of the profiles, even of pre-1700 profiles, enjoys even theoretical project oversight.

---

I'm a manager of over 6000 profiles, and manage a couple hundred pre-1700 profiles, and haven't had a single GEDCOM change to any of them. Then again, the profiles I manage aren't in parts of the tree that have a lot of coverage. Most every pre-1700 person I've wanted to work on has not been entered into WikiTree yet. A lot of people interested in genealogy are interested in PGM or royal profiles, so there will be a lot of activity on those. So let's lock them down because they've already been researched to death. But there are TONS of profiles that haven't been researched yet, and whose data isn't published anywhere online. Let's not make it harder for people to add those.

---

there are a lot of people in the USA and Canada descended from French colonists to New France, not all of whom are even entered yet, and not all of whom are fully researched.  But some of those that are fully researched have so many descendants it's a repeat operation regularly to merge new profiles into them and sort out the junk from the valid data brought in.  For example, Hélène Desportes, reputedly the first woman of French origin born in the colony, must have millions of descendants by now.  Spread all over the world.  How to limit the extra work is something needed most definitely.

Answer 12

It can't be just bios.  It wouldn't make sense to allow people to change data fields, and then not let them edit bios to match or cite sources etc.  You'd have to block changes to data fields.

And connections as well.  Actually, if a PPP already has a full set of connections, a gedcommer doesn't need to add any more.  His new connection will be at least one step away.

Comments

Your option 3 is still the best idea - when someone tries to GEDCOM into a PP profile, put up a notice it's not allowed and that they should instead create a duplicate profile and propose a merge of the duplicate into the desired profile.  Then it's totally under the control of the project people, and they can treat the changes in the duplicate as 'proposed changes', keep what's good (if anything) and ignore the rest.

---

However, there's the danger that mega-gedcommers with thousands of aristos in their tree would just create thousands of duplicates.

---

RJ, your suggestion makes a ton of sense. Do not allow the creation of duplicates to a PPP or make changes to it. They can only create a profile one person away, but then we would still have someone trying to add new spouses or children to the PPP.  (I am assuming that the parent would also be project-protected.)  Then how would that work? The addition could only be approved by the PMs or project leaders?

Answer 13

It does seem like the problem is that you haven't imported your gedcom until you've integrated it all into the main tree.   This means most of the integration is going to be done by newbies in a hurry.  Those Add and Edit buttons look like a to-do list, and people think they're supposed to do them all, and before they do anything else.

Perhaps the intermediate stage can be beefed up.  Say that the gedcom is "installed" as soon as the comparisons have been done.  At that point, every person in the gedcom that's been matched has a kind of Unmerged Match with a WikiTree profile.  Indicate this on the profile, and regard that as the end of the Import procedure.  Remove the Add and Edit buttons from the Gedcompare form.

Then provide those facilities through the normal tree-building process.  Eg, if a profile has a gedcom match, and you do Add Father, you get an option to Add Father From Gedcom.

Then people would usually start from themselves and work backwards, and by the time they get to the immigrants and aristos they might have decided they don't need to edit every profile they have a gedcom match for.   Or it might take a long time to get round to them all.  The job would have its normal place in the priorities and wouldn't seem like a high-priority task as it does at present.

And if people do decide they need to incorporate their gedcom data into an existing profile, this could be done by changing the "Unmerged Match in Gedcom" state to a "Proposed Merge From Gedcom".  This would make the relevant data in the gedcom visible to other users to approve and complete the "merge" in the usual way (with the usual alternative of joining the TL).

Comments

I really dislike the idea of intentionally making duplicates that then have to be merged.

We need to diminish the amount of additional work this new process is requiring of projects, not increase it.

I say simply disallow gedcom "editing" of PPP Profiles.  Have the system force a skip.

---

But if my gedcom has loads of aristos and the system starts skipping them all, I'll probably just stop finding matches.  That's how we got so many duplicates in the first place.

---

When I say "skip," I mean disallow creation of a profile; i.e., skip the GEDCOM entry.

Answer 14

I poked around in GEDCOMpare to remind myself what a user sees when they try to edit a pre-1700 project-protected profile. It seems that there are currently several alerts and warnings, but maybe more are needed. Here's what I found and what I recommend to possibly improve the current arrangement:

1. Ample alerts exist on edit screen for a PPP profile. When the EDIT window is opened for a PPP profile, there's a red warning banner that says "Project-Protected Profile: Do not save any changes without communicating with project members" and a notice like this (the actual notice I saw), accompanied by the PPP image:

Dunham-151 is collaboratively edited by the members of a project. Changes must be discussed.

1. Send a private message to the Profile Manager, Puritan Great Migration Project WikiTree.
2. Post a public comment on the profile.

2. Recommendation: Earlier notice of PPP status could help. Currently, GEDCOMpare doesn't indicate that a profile is PPP until after a person has opened the "EDIT" window, by which time I think it might be too late to dissuade them from completing their planned edit. The COMPARE page (which a person needs to view in order to access the EDIT button) does show the project name as profile manager. It seems to me that adding an indication of "Project Protected" on the COMPARE screen might reduce the incidence of uninformed edits to these profiles.

3. Editing of non-PPP Pre-1700 profiles is just like "usual." For Pre-1700 profiles that aren't project protected, the EDIT window has the new banner that says "If you are not already coordinating with a pre-1700 project, click here before proceeding (required). Thank you!" This is the same as what currently displays for a non-GEDCOMpare edit to a pre-1700 profile.

4. Recommendation: Remind people that they may not need to edit the profile. For all types of profiles, the edit screen advises:

Below is the current data for Dunham-151 (left column) and the new values suggested by the GEDCOM (center column). Select what you want to keep and, if you like, manually edit it (right column). Before clicking the "Save Changes" button, be sure you have evaluated the current profile in its entirety, including any comments or Research Notes.

The final statement in the alert might be too late. People should review the current profile before they even think about editing, not as their last act before pushing the "Save Changes" button. I think it would be helpful to precede that paragraph with the advice:

Before editing this profile, review the current profile in its entirety. The information content you propose to add might already be there, in which case you should cancel your edit.