GEDCOM import Approval by Wikiltree: Incomplete over 48 hours.

Question

Hi, I have a tree with over 100,000 people (with sources) that I'd like to start uploading to Wikitree in manageable smaller pieces. I do a lot of research on single surnames because it is useful to my primary research in human molecular genetics.   

 

I uploaded a very small GEDCOM file on May 14th as a preliminary test and it has been in the “Import Approval by Wikiltree: Incomplete” for over 48 hours. The instructions say to email wikitree if this occurs so I did but got no response.

 

This is the information on the GEDCOM file:

 

“John H Baker Descendants.ged was uploaded by Roland Baker 2015-05-14 23:42:37. The raw GEDCOM is 372910 bytes. It contains 88 individuals with the earliest person born March 23, 1822. It includes 76 sources.”

 

My account is at:

 

http://www.wikitree.com/wiki/Baker-14768

 

Best regards,

 

Roland

Comments

Hi Roland, I'm working on that for you :)

Why did you remove the match identified by the Arborist?

Rockwood-69 and Rockwood-49.

---

I too see your gedcom awaiting import approval.  It might have had some issues that were being fixed.  It will probably go through later today and you will recieve notification.  Hang in there!

---

Thank you sir!

I consulted with Linda Schreiber first about edits to this family group which she is managing and she gave me permission to work on it. Paul Howe has now successfully merged Nathaniel Rockwood (Rockwood-62) and Nathaniel Rockwood (Rockwood-49):

http://www.wikitree.com/wiki/Rockwood-49

The previous merge was not successful because the two profiles needed to have more editing done on them before they could be merged. Specifically one of the Nathaniels was listed as the son of his own nephew. Hence his parents as previously shown were born after he was! The other Nathaniel had the correct parents. I corrected his parents so that the parents in both profiles matched and then submitted the merge to Paul Howe. He was then able to complete the merge successfully this time.

You can confirm the essentials of merge by referring to “Rockwood Genealogical Register of the Inhabitants and History of the Towns” By Abner Morse page 214. I am currently working on a complete Rockwood genealogy. I already completed a complete rewrite of Charles A Flagg’s 1905 work on the family. I have that available now in GEDCOM format for upload to Wikitree.

If there are issues with the this GEDCOM file which I could have addressed pre-import please let me know and accept my apologies. I have a lot of GEDCOMs to upload and I want to make the process as smooth as I can for the administrators. Any feedback would be appreciated so I can learn the best practices to follow for future imports.

---

Thank you very much Roland.  Not the slightest appology needed.  That was as detailed and complete response as could be hoped for :)

Cheers!

---

The test upload completed this morning. Thanks! That’s a good trial run.

I just uploaded two more GEDCOMs this morning that are a little bit larger.

I have a question. I see a lot of sources showing up like:

Source: #S415 Object: @M56341@

Source: #S201 Object: @M50849@

Source: #S18 Object: @M57902@

I assume these are references to attached pictures and stores from my Ancestry.com tree. I’m exporting to GEDCOM from FTM. Is there any way to suppress these items that you know of? Possibly an export checkbox?

Also where I found a “match” during import, after import the imported spouses and children are not linked to the “match.” Instead they end up in “outer-space.” I was able to go back and link them up so it’s not a big issue for a smaller GEDCOM. From what I gather I need to manually re-link them post upload or create a duplicate person (instead of matching) and then merge the person in question post import.

---

Hi Roland!  One quick note.  Please only upload one GEDCOM at a time and wait until it was fully imported into WikiTree before uploading the next one.  Our GEDCompare program only compares against what is already in WikiTree not what is in pending GEDCOMs and we just want to be extra sure we aren't creating duplicates when importing GEDCOMs.   Thanks!

---

I understand. With that in mind I specifically created two GEDCOMs that are very distant from each other and have no overlapping people. So creating duplicates will not be an issue. I do a lot of single surname work. So I can safely upload two distant braches that have no overlapping segments.  However, when uploading GEDCOMs with shared people I will always upload them squentially after the previous one has completed to avoid the duplication issue you are referring to. But in this case there are no shared people. Thanks!

---

Hi Roland.  Your explanation of why you still intend on uploading 2 gedcoms is well thought out, however Eowyn is the one who handles all of the gedcoms.  It's always best to follow her advice, in this case one at a time :)

---

In other words follow the rules even if they make no logical sense? General rules are guidelines to prevent errors. They are very helpful. But if I understand the reasons behind the rules well enough such as in the example above it would seem there is absolutely no harm in breaking the general rule as long as I am 100% sure there is no possibility of it generating an error, correct?

Consider that there are always dozens of GEDCOMs being uploaded by different people at one time. Some of them will from time to time have overlapping segments and thus generate duplicates.

I think Eowyn is basing the upload rule assuming that one person uploading two GEDCOMs will always be including some of the same people. In my case since I work on large genealogies that include non-overlapping branches that don't share any of the same people nor geographical regions that I can break up separate branches and do two uploads.

For example I've worked on open source software my whole life. This is a perfect analogy. I can submitt a patch to one portion of the Linux kernel but not a second patch on the same portion at the same time. However, I can submitt a patch to a different portion of the kernel at the same time. This is all based on diffs. So there is no harm. In fact it increases the efficiency of the project.

---

Exactly... follow the guideline even if they do not make sense to you :)

Seperately, work in a constructive way to change guidelines that you disagree with or to help better the system.  We are always looking to improve!

Much like the law of the land... abide by the law and work through legal means to have the law changed.  I should not breal laws and participate in activities that are illeagle, but if the law is changed I may.  Until that time, I abide.

With less formal things like "please don't step on the grass" or "please take your shoes off" I still abide out of general respect for others.

I promise nobody is giving you a hard time Roland... quite the oposite.  I welcome you openly, and was trying to help guide you down the easier and better path.

Do as you think best, and we're happy to have you here!

---

Hi Roland,

I review about 150 GEDCOMs a day.  Not everyone who uploads multiple GEDCOMs at once is uploading them from distant branches like you mention doing.  It's not fair for me to say to you, okay Roland, you go ahead and upload multiple ones and everyone else can only do one at a time.  Not to mention, I'd never be able to keep track of all the people who might have exceptions to this rule or that :)

---

I quit.

---

Because you are unable to upload 2 gedcoms at the same time?

---

I have deleted the two pending GEDCOM uploads. If you have any other of my GEDCOMs pending please delete them. I do not want them uploaded to Wikitree.

---

Unrelated topic, I think you and I might be related through Vermonter Frank Cyrus Smith.  He might also be related to the Smiths from St. Albans who were governors.  We're probably cousins.  I do a lot with Vermont history and genealogy.  Let me know if you have any interest in connecting your Smiths to the tree.

---

>> Because you are unable to upload 2 gedcoms at the same time?

No.

I am accustomed to working on large open sources projects. I had hoped that Wikitree would be guided by the same principles. In other words, logical actors do what is logical for the greater good in a volunteer collaboration. Rules aren't arbitrarily applied.  But the above example proves otherwise. I have over 100,000 people to import. And my work is expanding beyond that. I need to work logically and efficiently with people of like mind. If I can’t work logically and efficiently than there is no point in proceeding with the undertaking.

I hope that answers your question.

---

---

---

It certainly did... I understand some things much more clearly now for sure :)

Sorry our procedures were not more to your liking, really.  It sounds like you would be a fantastic contributor for a variety of reasons.  You seem very polite, incredibly educated and well spoken, and super knowledgable about genealogy.  These are things we value here and constantly strive for.  I only wish you knew how similar your visions and goals really are to those of WikiTee :(

---

Likewise Robert I respect your diplomatic approach and thank you for the kind words!

If Wikitree would consider changing the rules I would reconsider leaving. I would hope to see Wikitree's model conforming to the successful voluneer open source collaboration projects that I've participated in for over two and a half decades. I'm one of the oldest contributors to the Linux, FreeBSD and Apache projects.

But if Wikitree is going to follow rules that make no logcal sense and impede productivity I'm better off contributing to a different project or creating my own project. I hope you understand. Issues like this is why projects fork. Its not good enough that a project employs voluntary collaboration for the creative commons. The project evironment needs to be robust.

For me its all about the work - the furthering of my research and helping others with their research.  I need to do that in a working environment that is efficient and logical.

---

And I'll add that usually when open source collaborative projects do fork it's for a justified reason and often the resulting fork is beneficual in my experience. And I've seen many forks over the years. It's a process of creative destruction.

Please do understand there is nothing personal in my descician. I commend everyone for their efforts here. And I wish you well with the project!

---

Thank you Roland... I wish you nothing but success and happiness!