User talk:DataAnalyst/Archive 2010-2014

Next step: Review your GEDCOM [19 August 2010]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded richard odell - small file.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate lines and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 18:48, 19 August 2010 (EDT)

richard odell - small file.ged Imported Successfully [20 August 2010]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 09:25, 20 August 2010 (EDT)

Dutch duplicates [30 August 2010]

Hello DataAnalyst. You must be working through WR's duplicates list... I am working on a project that created a number of duplicates which I am working on daily. Is it at all possible for you to skip the Dutch duplicates? I don't mean to sound rude in any way, it's just that I have a bit of a process when I merge them. Thanks, --Jennifer (JBS66) 20:21, 29 August 2010 (EDT)

Sure. I already decided to skip all the ones simply marked as duplicates and started working through the duplicate parents, but I'll skip the Dutch ones there as well. I did another one today, but I'll skip them from now on. Thanks for letting me know. --DataAnalyst 21:08, 29 August 2010 (EDT)

Merging of duplicate parents' files [31 August 2010]

I believe you said the Gardiners are not your family lines. I spent a lot of time earlier today correcting established genealogical errors on the Gardiners that were created by your merging duplicate files. Now you have merged another Gardiner file, Isaac, son of Benoni and Mary and resurrected the disproved parents, George and Sarah (Slaughter) Gardiner for Benoni. You made no comments to justify your resurrection of the duplicate parents for Benoni.--Bill Wright 20:36, 30 August 2010 (EDT)

Please have some patience - I am in the process of updating the records, and will correct the problem. I am in the process of reading the article so that I can get it right. --DataAnalyst 20:39, 30 August 2010 (EDT)

The records have been fixed now. It is hard to track through the history of this family and figure out exactly the state at any given time, but the merge (which was correct) simply brought the incorrect parents (that were already in WeRelate) onto the same page as the correct parents, and it was several minutes before I could fix the records. I wanted to create the source first, and my other webpage was being very slow, so that took quite a while.

I'm tempted to start putting comments on Talk pages when I am in the process of correcting records, because it can take quite a while to cleanup pages after a merge. Maybe I'll start doing that. --DataAnalyst 23:07, 30 August 2010 (EDT)

Next step: Review your GEDCOM [23 October 2010]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded ormsbee - 251.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 13:00, 23 October 2010 (EDT)

ormsbee - 251.ged Imported Successfully [24 October 2010]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 12:27, 24 October 2010 (EDT)

Person:Thomas Knowlton (2) [30 October 2010]

I findSource:Knowlton, George Henry. Errata and Addenda to Dr. Stocking's History and Genealogy of the Knowltons of England and America somewhat unconvincing about the death date of Thomas Knowlton. It may be worth a note explaining that there is some disagreement, but I don't feel he has proved his case enough to remove the death date from the page. I believe 2 Nov 1711 must still presumptively apply to Thomas Knowlton unless further evidence is produced.

G.H. Knowlton's main argument seems to be the "poorly written" figures in the record. I say welcome to colonial writing. I have seen ones written like Continental ones (almost like 7's). I have also seen ones written in a squiggly line that looks almost like a 5. It depends on the style of the town clerks. What matters is what was intended, and that seems to be a matter of interpretation. And here, Knowlton's argument isn't any stronger than the others. In fact, one might be inclined to feel that the compiler of the published records would have a better feel for the clerk's personal style.

To me, the biggest problem is the use of Junior (because of Thomas' age: who was Thomas Sr?), which isn't even noted by Knowlton, and is completely left out of one of the two "quotes" of the town records given on p. 6. (I say "quotes", because it is clear that Knowlton only paraphrased the records as his own two quotes differ, and both differ from the published version.) But in the published version [1] the death record is right next to the death record of Hannah, which is right in line with the colonial practice of recording family information as a unit. And Thomas' son, called "Thomas 3d" in the original history didn't die until 1730. This raises minor doubts, but I don't feel this is a show-stopper.

Finally, Knowlton suggests this death record belongs to "History (77)", referring to Thomas, b. 1692, son of Nathaniel Knowlton and Deborah Jewett. (The corrections also note that the family of Thomas (58) really belongs to Thomas (77)). With a good alternative, Knowlton's argument would be made stronger, but this choice is so bad, it calls into question his judgment. Thomas-77 appears to have spent his entire 26 year life in Ipswich having his birth, marriage and death all recorded there. We are supposed to believe that a date of 2 Nov is mean to refer to a person whose death in Ipswich is recorded as 28 Feb (regardless of Knowlton's complaints about the poorly written year).

Cautionary and noteworthy, not convincing. --Jrich 11:25, 30 October 2010 (EDT)

Thanks. I have added the death date, with appropriate citation and note, back in. I wasn't sure how much to trust Tingley, not having used the source for very much, and the 'Jr.' in the death record threw me. Of course, not having seen the original handwritten record, I suppose it is possible that it said Sr. and was mistranscribed. Thanks for the correction. --DataAnalyst 11:44, 30 October 2010 (EDT)

I don't claim to be an expert on this family, so take any of the above with the appropriate grain of salt. I just think G. H. Knowlton (didn't really look at Tingley) was a little too strong in saying without qualification that the death date did not apply, when he presented no real evidence to contradict it.

I also want to add a thank you for documenting your sources! --Jrich 15:40, 30 October 2010 (EDT)

Next step: Review your GEDCOM [4 December 2010]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded franklin - 242.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 11:16, 4 December 2010 (EST)

franklin - 242.ged Imported Successfully [8 December 2010]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 20:25, 8 December 2010 (EST)

Next step: Review your GEDCOM [28 December 2010]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded carpenter - 333.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 15:14, 28 December 2010 (EST)

Merging Sources [29 December 2010]

Hi Janet, hopefully this will give you some insight into merging sources... You wrote:

I found 2 pages for what I believe is the same source: Source:Adams, Andrew N. Genealogical History of Henry Adams, of Braintree, Mass., and His Descendants and Source:Adams, Andrew N. Genealogical History of Henry Adams of Braintree, Massachusetts and His Descendants the difference being in whether or not Massachusetts is abbreviated. When I look at the details, the first is clearly the book I used - published in 1898 and available as a scanned book at Ancestry.com. (Massachusetts is abbreviated on the title page of the book.)

The second source is possibly a reprint of the book, as it has a different publisher and a publish date of 1965. Without getting my hands on the book, I don't know if it is a reprint (with the same pagination) or a second edition. My guess would be that it is a reprint rather than a true second edition, but the pagination could still be different if they threw in a new introduction or errata page.

Should these 2 sources be merged?

As a general rule, yes, especially if 2nd book is just a reprint. It is also acceptable to create two sources, each with the publication date at the end of the page name, in order to distinquish between two sources. So your instinct about how to distinquish between editions is exactly right. It can be in the form of (1898) or (1898 ed). For some reason I generally use the latter (perhaps because it seems like with the ed. the number looks more like a year).

When multiple editions are combined, the user has to be certain to distinguish which edition has been used in the specifics of the citation on the Person or Family page, in case there are page numbering or other changes.

If so, is it as simple as editing the first source to add info from the second (e.g., surnames, repository) and then adding #REDIRECT to the second source? 

Yes, mostly it is that simple. But I can give you some more hints on how to determine what's a duplicate and what isn't...

First, using a browser that allows tabs, I open up both source pages, AND then I open up the links under the repositories for both source pages. In your example, that is the Ancestry search page and the Family History Catalog page.

That will give you a great deal of additional info - the Ancestry page will allow you to view the title page and confirm the publication info (Ancestry often has errors in their publication info). The FHC page clarifies that the 1965 date reflects only the date they filmed the original book, and thus isn't a "publication date" for the combined source page purposes. When combining source pages, the protocol is to use the earliest publication data in the form, adding later publication info or distinquishing information in the text description box.

There is also default language you can cut and paste to show that there is more that one edition of a book, in case a future WeRelate user wants to create separate source pages for each edition:

This source may refer to multiple editions of the same book. If it is important to you to refer to a specific edition, you may create a separate Source page for that edition with the year of the edition in parentheses after the title.

From looking at the Ancestry title page, I decided to add the printer to the publisher area and fixed the place of publication. I also selected the "type" (book) and the "subject" (family tree/history).

At the moment, there are no links to either source (other than some other redirects), but I have just uploaded a GEDCOM file and matched to the first source (so please don't choose to redirect it).

When I merge duplicates, I generally decide which to retain based on which one has the fewest redirects, because I like to keep things neat and tidy. Thus I generally will take the page I DON'T want anymore, and then open up all the pages that link to that page and fix the links so that they now redirect to the correct title.

In your example, that means opening the linked page, selecting edit, and then replacing #REDIRECT [[Source:Adams, Andrew N. Genealogical History of Henry Adams of Braintree, Massachusetts and His Descendants]] with #REDIRECT [[Source:Adams, Andrew N. Genealogical History of Henry Adams, of Braintree, Mass., and His Descendants]]. Now nothing links to the duplicate page (except my talk page, because of your question).

If there is a good reason to keep the duplicate page (for example, it was set up to use a variation of the author's name that is an alternate to the correct name, and that might be commonly searched for), I use the redirect. Often, and in this case, I would go to "more" on the command menu and select delete, and then verify that this is dupe page and there are no links here. I think you should have that feature for source pages, but if not, you could also use speedy delete.

Finally, I tend to go the extra mile and look for alternative repositories to add as well. My favorites for books out of copyright are the Internet Archive and Google Books. For recent books, I try to add a link to WorldCat, which will help people find the book in a library.

I hope this helps! I'm not sure there is a good set of instructions on merging duplicates anywhere on WeRelate; perhaps I will try to take this example and turn it into a help page? Let me know if it makes sense to you. - --Brenda (kennebec1) 18:42, 28 December 2010 (EST)Brenda

Thanks, Brenda - this made a lot of sense to me. And I see that you have done all the work except for deleting the second source. Thanks.

In terms of writing up instructions - yes, that would be very useful. I did not know that the FHL catalogue had that much info in it - I have been using Ancestry.com and AmericanAncestors.org most of the time lately. (I wish that AmericanAncestors/org included title pages in their scanning - I'd rather see the real title page than their citation info, even though their citation info can be useful.) If you incorporate the instructions you wrote for me into more formal instructions, I would not use the word "redirect" in talking about changing links on pages that point to the source to be deleted. (Once you have updated the link, they will link to the correct page without a "redirect".) Also, include a link to the help text for speedy delete (http://www.werelate.org/wiki/Help:FAQ#How_do_I_delete_a_page.3F), since a lot of people will not know how to do that (or exactly what it means).

Thanks for adding info to sources. I have not focussed on adding surnames and place names to sources I create (mostly journal articles) or sources I match to, because I have been working full tilt to get my records properly sourced and loaded. But some day, I may go back and help with improving the source pages (or other volunteer work - there is no shortage of work to do). Gotta run - my family wants me to watch some TV with them. Thanks again. --DataAnalyst 19:47, 28 December 2010 (EST)

carpenter - 333.ged Imported Successfully [30 December 2010]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 14:34, 30 December 2010 (EST)

Nice clean up you're doing [31 December 2010]

Just wanted to thank and acknowledge you for the data clean-up you're doing on Bowen and related lines. Thanks!

Jillaine 16:52, 31 December 2010 (EST)

Thanks. You never know when you're going to offend someone who is very attached to "their" data, so I appreciate the feedback. --DataAnalyst 16:59, 31 December 2010 (EST)

If people are too attached to "their" data, then they shouldn't be on a wiki. ;-) Jillaine 17:16, 31 December 2010 (EST)

Carpenter

I like the changes! Looks good! Jrcrin001 13:35, 3 January 2011 (EST)

Disproven versus not accepted? [16 January 2011]

Hi,

Your change comments on Waitstill Unknown alias Snow say "Snow" has been disproved. That suggests evidence that her name is not Snow, or that she has other parents than Nicholas and Constance, or that her age or location at some point rule out her connection to this family. Are you aware of that evidence? Because it would be really nice to put that evidence in a note on her page so subsequent readers don't say, "Wait! Still unknown? Well, then, I can help here! Her maiden name is Snow." Except for one unsupported statement that it is unproven, I haven't found either the reasons people think she is a Snow or the reasons why this is considered disproved. Or, is it more accurate to say it is not accepted? For this, one can merely cite the lack of supporting evidence, and GMB as a reasonably current indicator of informed consensus, in a note whose purpose is to inform readers that Snow has been considered and rejected, and thus need not be reasserted without good proof. --Jrich 10:00, 16 January 2011 (EST)

Sorry, I don't have the argument where her maiden name and parentage has been disproven. Nor do I know the origin of the speculation that her maiden name was Snow. My suspicion is that her identity was disproven before Jacobus wrote his article on the Ingraham family in 1943, since he does not mention her maiden name. If it was still uncertain whether or not her name was Snow, he (and probably Torrey) would have at least mentioned the possibility of her being a Snow. So either it was convincingly disproven, or the whole speculation came up since then. Not sure which. Since the citation (from what appears to be a fairly recent book) emphasizes that her maiden name has not been discovered and that Snow has been disproved, I would say that her name should be listed as Unknown, just like all the other wives whose maiden names have never been found. I felt that both the note still on her page and the argument on her Talk page were sufficient to cause a person pause before changing her back to a Snow.--DataAnalyst 11:30, 16 January 2011 (EST)

The problem with the Talk page is that I don't think it is visible during merge or during GEDCOM upload. I will strengthen the note that is there because my lambasting of the author for not providing proof could be construed as casting doubt on it. --Jrich 14:36, 16 January 2011 (EST)

It also occurred to me to put Waitstill Snow as an alternate name with a note indicating that it has been disproven. I've seen that done on other records. This might also forestall someone from "correcting" her name to Snow (and is more visible in a merge, but maybe also more confusing). I'm not sure if Search uses alternate names - I think it does. If so, that is another advantage, as it might prevent the creation of a duplicate under the name Snow. I'll leave that to your discretion. --DataAnalyst 16:06, 16 January 2011 (EST)

Next step: Review your GEDCOM [30 January 2011]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded battles - 246.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 17:55, 30 January 2011 (EST)

battles - 246.ged Imported Successfully [3 February 2011]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 08:19, 3 February 2011 (EST)

Followup on Benjamin Washburns [7 February 2011]

I know we have been going round and round on the Washburns based largely on my faith in the work of George Bowman. It was frustrating not to be able to find a fuller article giving all the details after the promise made in Pilgrim Notes and Queries cited in one of my postings. I was getting ready to order some films and try and find the evidence myself, but I ran across a fairly good, well-documented website on the Wasbhurns (perhaps you have seen it, but I generally search the general Internet only as a last resort - this website was a real find). For example, it lists the deeds of Benjamin and Bethiah with references to the Plymouth volume where they may be found, which would make checking into them really easy. Based on what they have posted, the clearest piece of evidence that Bowman was right is under Benjamin and Martha (here), which says that Martha refused administration on her husband's estate, so it was granted to Cornelius Washburn. The website says "his brother Cornelius", and I am not sure if this is explicit in the document, but brother would be more likely than, say, granting it to his cousin, which would be the alternative if it was not his brother. Cornelius was a son of Jonathan (VR Bridgewater, p. 1:327, b. 1702), so Benjamin who m. 1729 Martha Kingman would appear to be the son of Jonathan, and he could not be the father of Henry. The source is Plymouth Probate, 8:261 and 16:408,413. I assume the second one is the distribution of his estate, and the first one probably has the granting of administration to Cornelius. So it should be easy for someone to verify this and I am much happier knowing the actual basis for this conclusion, even if I haven't personally verified it. P.S. there is also a deed (Plymouth deeds 43:269) where the heirs sold land "derived from our grandfather Jonathan Washburn, deceased, to our father Benjamin Washburn". --Jrich 23:27, 6 February 2011 (EST)

I was hoping I could help you as I have a Plymouth colony wills, etc. film currently on loan, but it's vol. 1-4: Plymouth Colony records, wills, 1633-1686. I have it until 2/22 (and could extend it), if you need anything looked up in those volumes. Jillaine 08:39, 7 February 2011 (EST)

wikipedia consistency [10 April 2011]

Don't worry about perfect consistency between wikipedia and our extracted templates. Dallan gets a snap shot of Wikipedia once or twice a year. That is the basis for the templates - so changes in WP are not going to immediately reflect on the WR templates that are then constructed. The updates will - eventually - get through, just not instantly. --Jrm03063 14:11, 10 April 2011 (EDT)

Thanks. I figured it must be something like that after my attempt at update did not work. Good to know that the references are refreshed periodically. --DataAnalyst 14:33, 10 April 2011 (EDT)

Hello! [14 June 2011]

I have been very pleased to see someone else actively working in the medieval spaces. I've struggled with the WeRelate data base for a couple years now - merging out the duplicates and using wikipedia, thepeerage, and medieval lands as a rough and ready source set (I know, the real genealogists scoff at wikipedia - but it's way better than nothing - which was pretty much what we had). I see you're taking the time to clean up a lot of the cosmetics that I didn't take the time with, which is just great! I hope you're finding the experience interesting and at least somewhat satisfying. For my part, it's not so much that I'm hugely interested in this time period - but I like the werelate model and felt it was sort of embarrassing to have that space looking weak when there were so many wikipedia pages that could be drawn upon.

Anyway, I did want to say hello and thank you for wandering around out there!

Best Regards... --Jrm03063 22:17, 14 April 2011 (EDT)

Let me echo JRM's thoughts, I am interested in medieval genealogy but much that gets uploaded here is the subject of scholarly research which can be used to validate and correct in what we have. I have held off for the time being as separating the wheat from the chaff seemed a monumental task. The efforts of JRM and others like yourself has geatly improved things. One comment, though I see you adding surnames. This an anachronism in most cases, as surnames did not come into use until into the 14th century and in some case much later. While many place names, patronyms and other bynames eventually became surmames, They were not within this timeframe.--Scot 18:53, 13 June 2011 (EDT)

Yes - I am aware that surnames are anachronistic, but I assumed that the surname field was being used to capture some sort of differentiator, since it appears to be fairly common to retroactively assign those differentiators. I've used Medieval Lands as my guide in most cases, but guessed in others where Medieval Lands did not provide a guide (or I missed the hints). I have also hesitated about completely getting rid of the differentiators that others have assigned - even when I have been uncertain of them. For one thing, if I am uncertain, I don't feel it is necessarily my place to correct them - for another, leaving a questionable differentiator might prevent someone from adding the person yet again.

If there is a discussion about the "best" way to represent medieval names, you might direct me to it - I can't remember having searched for such a discussion, but simply followed what appeared to be common practice. And I can't claim to be completely consistent, even in the degree to which I clean up records - as you say, it is a monumental task and my energy for it wanes at times. I've been focusing on one line (which of course branches all over the place), and occasionally fixing tangential lines or lines that got confused with my line. I've spent several months on this and the end is not yet in sight - not sure if I will finish. I'm sure it would have been easier to start from scratch with a good source - but sometimes untangling the threads is like a puzzle and it gets me going.

I hope others will join the task at some point, because the existing quality of medieval records really lowers the value of WeRelate. --DataAnalyst 20:54, 13 June 2011 (EDT)

Next step: Review your GEDCOM [14 August 2011]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded kempton - 237.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 19:16, 14 August 2011 (EDT)

The Great Migration Begins [4 December 2011]

It's a bit of a nit, but the bindings and title pages use roman numerals for volumes, not arabic.--jaques1724 07:05, 17 August 2011 (EDT)

FWIW, Jacques, the use of roman numerals is no longer standard bibliographic practice, nor is it required for "accuracy." The two forms are interchangeable but arabic numerals are preferred for volume numbers in both book-sets and periodicals, as being more quickly readable. See the Chicago Manual, and most other current sources. --Mike^Talk 08:13, 4 December 2011 (EST)

kempton - 237.ged Imported Successfully [17 August 2011]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 11:48, 17 August 2011 (EDT)

Duplicate parents problem [22 August 2011]

A merge on Person:Ada Mallison (1) has given her two sets of parents. Please see if you can remove whichever one is an error. Two is definitely an error. --Judy (jlanoux) 20:12, 22 August 2011 (EDT)

Next step: Review your GEDCOM [27 August 2011]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded etheridge - 83.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 11:13, 27 August 2011 (EDT)

etheridge - 83.ged Imported Successfully [28 August 2011]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 10:52, 28 August 2011 (EDT)

flipped main and alt name - consistency with siblings [29 August 2011]

This is personal opinion on my part, but I tend to think the above is a poor reason for making a change. At some point it leads one into an unresolvable conundrum. To be consistent, do you have to use the modern spelling so all the children and their parents consistently show the same spelling back through all the generations? Changes in spelling happened, where are such discontinuities allowed to show up?

Many cases I can give where one child chooses one spelling different than another sibling; or where a name tended to be spelled one way in one generation, another in a later generation; or where a name has 20 or 30 spelling variations. Foreign names are also tricky. Some of my Sontag ancestors chose to use Sunday (the English translation) so I have a family with parents named Sonntag, some children named Sontag and other children named Sunday.

Striving for consistency is impossible, and in some cases, introduces errors. It is really questionable whether we can determine the correct spelling anyway, barring a signature. Since many people were illiterate in colonial times, that means it often can't be done, and one case I read about, the person themselves changed how they spelled their own name over the course of their lifetime. (Of course, with modern names, say 1850 and later, spelling was much more rigorous and reliable.)

So, suggestions:

1. Try to be flexible and allow alternate spellings to exist since in some cases, since those Merricks may have been named that way to match their children, instead of your perspective of their siblings. Unless it appears to be misleading, why change it? In some ways, displaying a family with both spelling is useful because it reminds readers they have to consider both variations when searching for information.
2. When prominent spelling variations exist, add Surname: pages to make sure search treats both spelling equivalently. For example, Surname:Merrick should probably have Mirick, Mirrick, Myrick, Myreck, etc., etc., added to it as alternate spellings. And vice versa.
3. If you have to change a name, instead of renaming the page, merely change the name fields. The displayed names will ignore the page title and use the name fields. It is simpler to clear changes out of one's watchlist without having follow all the redirects back. --Jrich 13:32, 29 August 2011 (EDT)

Next step: Review your GEDCOM [14 September 2011]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded cleveland - small test.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 19:24, 14 September 2011 (EDT)

cleveland - small test.ged Imported Successfully [16 September 2011]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 06:57, 16 September 2011 (EDT)

Next step: Review your GEDCOM [17 September 2011]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded cleveland - 267.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 16:19, 17 September 2011 (EDT)

cleveland - 267.ged Imported Successfully [22 September 2011]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 10:52, 22 September 2011 (EDT)

Next step: Review your GEDCOM [26 November 2011]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded tracy - 278.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 21:12, 26 November 2011 (EST)

Next step: Review your GEDCOM [3 December 2011]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded tracy - 278.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 11:48, 3 December 2011 (EST)

Peterborough Rollback [4 December 2011]

Just so you'll know what happened, Janet, I rolled back the place-name change you made on Family:Thomas Lord and Dorothy Bird (1). Peterborough is, in fact, still part of Cambridgeshire -- as much as the new administrative boundaries allow it to be part of anyplace. In any case, WR uses 1900 as the "official date" for place names. I have a lot of problems with this policy myself, as I hate the idea of, for instance, someone being shown as born in a place that didn't even exist at the time. (And the insistence on present-day place names in ALL circumstances that some folks on WR show produces such inanities as "Czar of the Soviet Union.") Anyway, I usually prefer to add new pages for people not yet on WR rather than get involved in nit-picky arguments on American colonials who have been over-studied, so I don't imagine you'll bump into me very often. :) --Mike^Talk 08:24, 4 December 2011 (EST)

Pardon me for butting in, but I'm confused. Currently, the family page in question shows Peterborough, Cambridgeshire, England but due to a redirect, links to Place:Peterborough, Northamptonshire, England. Also, we allow the "pipe trick" to show both how a location was at the time of the event, as well as properly linking to the place page. What county was Peterborough a part of at the time of the event? --Jennifer (JBS66) 08:38, 4 December 2011 (EST)

If you go to a map of Britain prior to the massive administrative reorganization in 1974(?), Peterborough was in Cambridgeshire and always had been. If you check Wikipedia now, they have Peterborough in both Cambridgeshire and Northamptonshire, presumably because it's much larger now and overlaps both counties. However, WP also says it's still regarded as being in Cambridgeshire for "ceremonial" purposes (whatever that means . . .). Anyway, I simply rolled it back, I didn't pipe it, or de-pipe it, or whatever. --Mike^Talk 21:34, 4 December 2011 (EST)

The redirect of the Peterborough page from Cambridgeshire to Northamptonshire, was accompanied by the description "Use historic counties", but was not done by the werelate agent, so who knows if this page follows the convention or somebody's particular idea of how it should work. But searching the FamilySearch catalog (I'm assuming this website followed the 1900 convention too???) for Peterborough, England only gives results in Northampton, nothing in Cambridge. --Jrich 09:44, 4 December 2011 (EST)

Just so you know, I did not personally make any entry to do with Peterborough. I merged an uploaded GEDCOM record with an existing semi-protected record, which included an event (marriage licence) in Peterborough. So if there was a change, it must have been an automated one. I just now checked the history, and it looks like the marriage licence event has been Peterborough, Cambridgeshire all along - although maybe it only looks that way - I couldn't say what has been going on "under the hood". The reason I point this out, is that if something happened to the place name as a result of my merge, it could occur again. --DataAnalyst 10:02, 4 December 2011 (EST)

That likely happened because when pages are saved, the system matches the places. This will happen if I open and save any page, not just during gedcom upload. Since the current place page's title is Place:Peterborough, Northamptonshire, England, and the family page previously said Peterborough, Cambridgeshire, England, the system matched the place, keeping the original wording. This is the same as if a person had Tolland County, Connecticut on their page (or in their gedcom). This would be changed to Tolland, Connecticut, United States|Tolland County, Connecticut. --Jennifer (JBS66) 10:57, 4 December 2011 (EST)

Torrey's marriages [5 December 2011]

Sorry, didn't recognize the name Janet Bjorndahl the other day.

I noticed you having been citing Torrey's marriages a lot. As you can tell from Family Talk: Thomas Wilder and Hannah Eames (1), I am not a big fan of this particular work, though I have known him to write some excellent articles.

The one saving grace of this work is that he does list sources. This makes it more of a research tool, but rarely a good source in itself. I feel the proper way to handle him is to cite the actual source, and so he should rarely be cited directly.

As the Wilder case makes clear, he basically propagates garbage when he doesn't know, and when he does know, the reason he knows is more important than his saying it. For example, Family:Joseph Allen and Anne Brazier (1) already had the Watertown record on the page. Citing Torrey doesn't add anything: I don't think a reasonable person would believe him over the Watertown record unless there are other sources supporting him, and in that case, it is those other sources that are needed on the page.

Even citing Torrey with his source list is pretty useless, since a fair number of the sources he names may simply be (for example) secondary sources saying Nathaniel Wilder was the son of Thomas and Anna Wilder, i.e., not useful in establishing the wife's maiden name or marriage date, and not as authoritative as citing Nathaniel's birth record directly, and so basically a waste of time to look up. To be useful to a reader, one should go through Torrey's sources, and cite the really essential ones he provides, culling out the ones that are simply repetitious with no higher authority or new information, or are unsupported secondary assertions.

Just one person's opinion, of course. --Jrich 18:26, 4 December 2011 (EST)

That's interesting. When I started getting into New England ancestry, I noticed how frequently Torrey was cited and inferred that it was a standard authority for early New England research. And maybe that is more true of the intermediate amateur genealogist (serious enough to cite sources) than of the truly serious scholar. One of the advantages I have seen in a work like Torrey's is that the breadth would help to eliminate incorrect information (i.e., A did not marry B, because she married C) - of course, the opportunity to do so did not always mean that it was taken, but it appeared to me that at least some attempt had been made to eliminate overlapping marriages. And I understand that Torrey was meant to be more of an index than anything - not meant to be a definitive evaluation of the sources.

I have cited Torrey in my own records whenever possible, assuming that there are many who would ask whether the information is supported by Torrey - again, because I saw it used so frequently. Another reason I cite Torrey is to leverage his birth and death date information - it helps to support that I have the right John Smith married to the right Jane Doe. A VR is a better source for the marriage date and place, but Torrey supports the identification of the parties when they are not identified in the VR, or the matching of the marriage VR with the death VR. This is useful for someone who does not have time or inclination to sort out all the John Smith's within one town. I think the latest citation I added to WeRelate included a death year - the only reason I added the citation was for that purpose. Some people might find it of value - during a merge (especially a timeboxed one such as reviewing a GEDOOM), it is hard to take the time to evaluate every citation on the page to determine if there is sufficient other information to "prove" that the right death record has been associated with the right marriage record. Hope that is clear - I have to run. --DataAnalyst 18:55, 4 December 2011 (EST)

It is exactly the hard cases like sorting out John Smiths (e.g., the John Smiths of Long Island!!) where it is more necessary, not less necessary, to work hard, and requires identifying the primary evidence and explaining all assumptions, because invariably the secondary sources get corrupted by confusion and mistakes. Torrey does not do this. I was looking at pages I have worked on where Torrey was cited, and can provide examples of errors where the answers are actually known and not that hard to find, but thought Family:Edward Adams and Lydia Penniman (1) was useful because this page contrasts his entry and approach with that of Robert Charles Anderson. Torrey wasn't attempting to provide a definitive statement of what is currently known, he was trying to build an index to information at a pre-Internet time when it wasn't so easy to find information. Thus he did not do several of the steps that would be necessary to be reliable. He wasn't selective about his sources, didn't chase information back to its primary origin, didn't try to resolve contradictions, didn't do enough analysis to ferret out misleading assumptions, etc. Torrey's marriages is meant as a starting point, not a finishing point. Since one of my goals at WeRelate is to try and counter the vast amount of misleading and mistaken genealogy on the Internet, my research has usually matured past this point before I post and I can't justify citing Torrey when I have far more authoritative sources in hand. In fact, most of my cites of it are for the purpose of refuting it. --Jrich 09:56, 5 December 2011 (EST)

OK - I will keep my eyes out for records you are watching and be very careful about what citations I add. You realize, of course, that you are a relative rarity in terms of the research you do. I will try to remember to honour that and leave well enough alone.--DataAnalyst 20:34, 5 December 2011 (EST)

It doesn't take many people putting research based on primary evidence on the Internet before the lazy genealogists will mostly be copying respectable genealogy instead of junk. They might even learn what to look for if they read enough arguments taking the time to explain why such and such is right or is wrong, instead of the all-too-easy-to-do unsupported assertions. Your work on Person:Elizabeth Grout (2) and Person:Joanna Kempton (4) has been like that. Thanks. --Jrich 22:50, 5 December 2011 (EST)

tracy - 278.ged Imported Successfully [19 December 2011]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 11:52, 19 December 2011 (EST)

Next step: Review your GEDCOM [8 January 2012]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded kilborn - 462.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 12:13, 8 January 2012 (EST)

Clean up of Olmstead pages [13 January 2012]

DataAnalyst - recently you have been very busy refining and removing many of the citations and ancestral file numbers that I added to the family members of Capt. Nicholas Olmstead. I am not bothered by the clean up and I am never bothered by the addition of information to the pages... but... I am deeply disturbed by the removal of ANY information without a clear explanation and analysis. As far as these Olmste(a)d pages go, my two biggest concerns are the removal of ancestral file numbers and the alteration or removal of cited text.

First - ancestral file numbers - Please provide an explanation as to why you have chosen to remove only the GOFA numbers from these pages and to leave the other ancestral file numbers? I disagree with this change. The GOFA numbers refer to the numbering used in the Genealogy of the Olmsted Family in America. This ancestral numbering system is widely recognized among Olmste(a)d family researchers to identify unique individuals and has worked well as such for many, many years. I see that the GOFA number is not always cited/tied to the source on many of these pages, but that is an easy enough fix. What I don't see on these pages is a source or explanation for the other ancestral numbers. If they are from a GEDCOM dump, I hardly think that makes them more relevant.

Second - altering/removing cited text - I have transcribed the citations word for word and you should not alter them, typos aside, or insert your own text into them without clearly identifying it as such. If you have a comment on the citation, please note it outside of the quoted text. The amount of text in a citation is a matter of personal preference and surrounding text, especially that which contains info about an individual's relationships, can often provide important clues. There was no harm in including the few additional lines of text from GOFA about the immediate family members of these individuals and I think it should remain on the page. That is the way that you would see the information on the page of the book. Your method of citation took the one line out of context, chopped off related information, and inserted your own notes/assumptions without identifying which words came from the source and which came from you.

In closing, I want to be clear, that I am all for the individual attention to these pages and bringing as many sources to the table as possible. Your attention to these pages is appreciated, but please remember that one person's trash might be another person's genealogical gold and, in the case of these individuals, so little is known, that any relevant information should be included that might provide clues to the circumstances of their lives. Please do add to the pages as you see fit, but I respectfully request that you cease deleting GOFA numbers and altering/removing cited text from the sources on these pages.--Cos1776 12:52, 13 January 2012 (EST)

I have found DataAnalyst to be a very careful researcher so spot-checked some of the individuals mentioned and I think the changes that were made look very appropriate to me. The GOFA number was labeled as an AFN, looked like an AFN, and would have been an invalid AFN, so it would be only natural that it be deleted. There may be some value in documenting it but a more appropriate way would be to add something like "[#11]" to the text of the GOFA citation so the reader has an idea of where if comes from, GOFA not be an abbreviation at the tip of everybody's tongue. As far as editing the citation from Olmstead Family in America, it is certainly not necessary to include long passages when the person being documented only takes a line or two. If the page is about John, for example, it is not necessary to provide his father's whole entry with all the siblings included. That is redundant with the infoboxes on the family and unnecessary, and usually is a symptom of a page that has been built by blanket cut-and-pasting. The citation I see there now is more customized specifically for John, and hence in my mind less redundant, more focused, more concise, and to be preferred. (And using square brackets to insert one's editing of passages for readability and comprehension, is very much a standard practice, and quite recognizable as such.). --Jrich 14:01, 13 January 2012 (EST)

JRich is right about the GOFA numbers not being widely recognized. I had no idea what they were until I happened to notice that one of the numbers matched a page number of the citation, and then I figured it out - and even then, I thought it was a page number reference (I guess that was a coincidence) - and therefore redundant with the citation. From now on, I will try to remember to move the GOFA number to the citation. Otherwise, my reasons for changes are as JRich has indicated. It should also be noted that times have changed, and what might have been valuable additional information on other family members no longer needs to be cited here, as the book is freely available on the web (at Internet Archive). --DataAnalyst 18:40, 13 January 2012 (EST)

I am fairly certain that I did include the GOFA number in each GOFA citation, but you have deleted most of them. I do not have a problem with the numbers appearing in the citation only and not the AFN, but I do think they should be included. As far as the amount of cited text goes, you are both missing the point here. These folks are not fully researched yet. The door is not closed. The process is still evolving and different researchers are bringing their pieces of the puzzle to the table for the community to evaluate. First of all, you deleted the text that provided the source for the parents of many of those individuals, albeit a secondary one. Second, citing source text on the person page is helpful at this stage of the game, not redundant, and not all of the cited information is automatically reflected in the infoboxes. It may very well spark a connection that had not been previously investigated. What you did was to toss out a piece of the puzzle because you judged it to be irrelevant. It is precisely that type of thinking that has kept many researchers behind their brick walls. Not everyone conducts their research in the same way or looks at a problem in the same way or brings the same background to the table. We need fresh eyes for some of these old mysteries and censoring the information is not helping.

You are right about the citations showing parentage - I was not always careful to include that part of the citation. I have gone back and done that and added in the GOFA # at the same time. As far as I know, nothing else of relevance to the person's web page was removed from their citations - only information that should have been (and in some cases, has been) cited on another page. Citations about a person's siblings and their siblings' marriages do not belong on the person's web page - it only leads to difficulty in picking out the information in the citation that is relevant to the subject of the web page. Citations about the marriage of the person's parents, if already on that family web page, are not required. If I accidentally removed something of relevance to the subject of the web page, and it is not reflected in another citation, by all means, correct the citation. I try to be careful, but sometimes miss things, as we all do.--DataAnalyst 23:17, 13 January 2012 (EST)

I agree about keeping the information on the page relevant to the subject individual. And it is redundant to describe Nicholas' whole family on each and every one of his children's page. It is not necessary to put information about siblings Sarah, Rebecca, Mary, etc., on John's page, because people know that each person has their own page, and they will go to the person's individual page if they want to know about them in detail. The problem with redundancy is, if somebody wants to change information on one of the siblings, they will probably not think to change John's page, meaning the siblings' information that is on John's page will not get updated and become out of date and inaccurate. For this reason, redundancy should be kept to the minimum possible.

With this particular source, it is always possible to include a link in the source citation that points to the online scanned image of the page in the book, so an interested party can read as much as they wish. For example,

[http://books.google.com/books?id=qkJEAAAAMAAJ&pg=PA12&dq=%2211.+John%22 Google Books]

[http://www.archive.org/stream/cu31924029843244#page/n59/mode/1up Internet Archive]

which give Google Books or Internet Archive, respectively. The transcription or abstract is really more of a finding aid, giving the reader a quick idea of which facts the source supports, but it is not meant as a substitute for serious research. --Jrich 00:14, 14 January 2012 (EST)

kilborn - 462.ged Imported Successfully [17 January 2012]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 19:42, 17 January 2012 (EST)

Next step: Review your GEDCOM [16 February 2012]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded griswold - 546.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 20:29, 16 February 2012 (EST)

Next step: Review your GEDCOM [5 March 2012]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded griswold - 546.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 18:38, 5 March 2012 (EST)

Francis Barnard married Hannah ? (Merrill or Marvin)? [9 March 2012]

Looking at Family:Francis Barnard and Hannah Merrill (1), and see that Savage and Sheldon (see Person:Francis Barnard (2)) are claiming this is Hannah Marvin. Still, there seem to be some solid references on the page proper. Do you think this is a case of an error in Savage? (I'm trying to be diligent about noting such issues in the transcript I'm working on). Thanks! --jrm03063 13:24, 9 March 2012 (EST)

According to Marvin Descendants, 25-26, Matthew and Reinold Marvin had three sisters: Margaret, died young; Mary, married John Hayse and Richard Wood; Elizabeth, married Robert Edwards.

Page 15 of Hartford VR (americanancestors.org) [Barnard] Frainces, m. Hanna Meruell, Aug. 15, 1644 [Book of Distributions:21]; [Barnard] Francis, m. Hanna Merrell, Aug. 15, 1644 [Frank Farnsworth Starr manuscript:26]. Barbour's Families of Early Hartford follows the Hartford VR.

The other secondary sources I was able to check call her Hannah Marvin.

Francis Barnard is not mentioned in the "Merrill Memorial"

Conclusion: The Hartford records are closer to the primary source than the others. For that reason I'd say Francis Barnard's wife was Hannah Merrill, origin unknown (not related to John Merrill of Hartford). The absence of any evidence of a Hannah Marvin sister to Reinold and Matthew reenforces that conclusion.--jaques1724 15:15, 9 March 2012 (EST)

I'll just add that Sheldon really doesn't add any weight to the scale, since he gives no explanation of where his conclusion came from, and most likely he was relying on Savage. Hence he is only a reflection of the object already seen, not anything new. The lack of evidence for the sister is pretty striking actually, since she was not named in the alleged father's will, and his death in 1615 constrains her birth to be on the far reaches of reasonable given a marriage in 1644 and 5 or 6 children that we know about.

It seems likely that this was a mis-reading of the record, as double r and interior vowels are always tricky, and some colonial writers make a double-ell look like a small-n, especially if blotted, faded, stained, torn, etc. So "Marvin" may be understandable. In fact, a researcher might want to keep a slighly open mind, and follow the History of Hadley, which says "Merrill, Meruil, or Marvin". But it seems pretty definite she was not a sister of Matthew and Reinold Marvin and even if Savage read it as "Marvin", he should have qualified this with a "perhaps", since it does not appear that he could have had any evidence of such a relationship, merely an assumption. --Jrich 16:26, 9 March 2012 (EST)

Great! Thanks! I'll add this to the documentation of another defect noted in Savage... --jrm03063 16:31, 9 March 2012 (EST)

Error importing griswold - 546.ged [15 March 2012]

We had an error while attempting to import your GEDCOM. This is most likely our fault. We will review the error and should have your pages ready tomorrow (or Monday if tomorrow falls on a weekend). There is no need to re-import your GEDCOM file.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 22:13, 15 March 2012 (EDT)

griswold - 546.ged Imported Successfully [15 March 2012]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 22:46, 15 March 2012 (EDT)

Next step: Review your GEDCOM [22 April 2012]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded benedict - 756 - dry run.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 17:09, 22 April 2012 (EDT)

Next step: Review your GEDCOM [29 April 2012]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded benedict - 756.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 19:09, 29 April 2012 (EDT)

benedict - 756.ged Imported Successfully [11 May 2012]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 15:53, 11 May 2012 (EDT)

Elizabeth Payne Citation [12 May 2012]

Nice! Interesting that Jacobus missed it when doing the Payne/Paine sketches in 1930--jaques1724 17:35, 12 May 2012 (EDT)

See William Odell talk page [31 July 2012]

Hi Data,

I've left a comment on the talk page for William Odell, whom you worked on a couple years ago. Let me know what you think. I basically agree with that web page I linked, but I am reluctant to put down it as 'definite' since its still just a theory advanced on a webpage.--dmaxwell 13:51, 30 July 2012 (EDT)

Next step: Review your GEDCOM [2 August 2012]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded snyder - 160.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 22:04, 2 August 2012 (EDT)

snyder - 160.ged Imported Successfully [4 August 2012]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 23:48, 4 August 2012 (EDT)

Next step: Review your GEDCOM [13 October 2012]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded stroheber - 423.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 19:52, 13 October 2012 (EDT)

stroheber - 423.ged Imported Successfully [20 October 2012]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 23:01, 20 October 2012 (EDT)

Next step: Review your GEDCOM [27 October 2012]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded stroheber update - 61.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 11:31, 27 October 2012 (EDT)

stroheber update - 61.ged Imported Successfully [27 October 2012]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 15:18, 27 October 2012 (EDT)

Next step: Review your GEDCOM [4 November 2012]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded stewart - 330.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 16:55, 4 November 2012 (EST)

stewart - 330.ged Imported Successfully [10 November 2012]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 22:46, 10 November 2012 (EST)

Merge of my suggestion with yours [11 November 2012]

Even though my suggestion wasnt that popular, it isnt the same thing as what you merged it with. I dont upload GEDCOMs so my suggestion doesnt concern them.

I still hope they will have an auto unsourced category, regardless of whether or not it came from a gedcom. It should probably stay up as I think it will prove to be key to improving this site.--Daniel Maxwell 09:07, 11 November 2012 (EST)

Sorry - I clearly didn't get enough sleep last night - I selected the wrong page to redirect. I have undone that error, but you are no longer watching your suggestion page. Sorry about that.--DataAnalyst 09:09, 11 November 2012 (EST)

Age of Deacon John Loomis at death [16 January 2013]

The age comes from his still-existent tombstone, the oldest Loomis tombstone in America. Most Loomis genealogies give ca 1622 as the birth date:

http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=17820293--Daniel Maxwell 06:14, 16 January 2013 (EST)

Ormerod sources [22 February 2013]

I was just changing some Ormerod souces to the 1819 edition that I had originally incorrectly put as the 1882 edition, and I think I may have inadvertently changed a couple that you put in. Sorry if I have messed something up.--Werebear 22:16, 20 February 2013 (EST)

It happens. Was that just Feb 20, or earlier than that? I still have the email notifications from Feb 20, so I can check them out - there weren't many. If it was earlier than that, I can go through my deleted emails. It would just be good to know how far to look. Thanks for letting me know.--DataAnalyst 10:26, 21 February 2013 (EST)

Never mind - I realize now what was done. I will use my database to find the citations that need to be corrected.--DataAnalyst 19:09, 21 February 2013 (EST)

I believe I have fixed all my references so that they point to the 1819 edition.--DataAnalyst 13:38, 22 February 2013 (EST)

breaking my GEDCOM into uploadable pieces - Volunteer Partners! [28 February 2013]

Thanks for inquiring. Since I wanted to give you details, I thought I should post it here instead of mingled with Mr. Rolls' discussion.

My Jackson database is 26,500 individuals. The early Colonial folks are intertwined but the later ones are not so much. I think my difficulties were two-fold. I am wiki-challenged and thought it would be easier to learn. Then I didn't know enough geography to realize that Hempstead was not only a village but a Town full of lots of villages. So I had to stop and study the geography and history of the naming of the areas. Then I tried to upload from my earliest ancestor down. Robert Jackson died in Hempstead, Queens (now Nassau), NY in the late 1600s. Perhaps I should have started with a more recent ancestor and worked up. (Dallan did give me permission to post these early folks.)

The database is a combined effort of a lot of Jackson folks who have sent me either their research or their family records. So some is original research and some is info has been gleaned from others to help weave all these folks together. It is sourced but all sources are not equal! My http://www.jacksonfamilygenealogy.com web site shows all of Robert's descendants but there are a lot of early NY folks who are not his descendants in the db that I had to learn about just to understand the relationships between these folks. The whole db is posted at rootsweb but so much more can be done at WeRelate if I just had the skill and energy. I would be happy to send you a GEDCOM of the whole database if you think you'd be interested in seeing what you could do with it. I'm about to have an 84th birthday and don't think I'm going to get this done. I've done bits and pieces of it and I lose track of what's been done and where to pick up again. I even started a user's page just as an index. When I first started (several years ago) I created a category 'Janie's tree' just to try to keep track of the pages I've created, but when working on categories, the consensus was that we shouldn't have personal categories, so I deleted them.

Let me know if you would be interested in having a GEDCOM of the database. I believe it will be easier for me to work on supplemental articles that would link to the person pages than in struggling to get the GEDCOM divided properly and then uploaded with the right locations. I am currently unable to devote full time to this, though I can see it can easily take a full time commitment to do it properly. If you don't have the time for this right now, perhaps you could give pointers on how to do it and keep track of what's been done.

Thanks so much for your interest. --janiejac 01:43, 28 February 2013 (EST)

Sure, send me the GEDCOM. It is about 5 times as large as my New England database, which took me somewhere between 3-6 months to load. I'm not going to promise to load your GEDCOM into WeRelate, but I should at least be able to divide it into manageable chunks and maybe determine what you have already loaded into WeRelate and what is outstanding. Once I've taken a look at it and divided it up, we can make a plan.--DataAnalyst 18:52, 28 February 2013 (EST)

Next step: Review your GEDCOM [2 March 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded temp.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 07:49, 2 March 2013 (EST)

Next step: Review your GEDCOM [3 March 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded test Jackson.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 16:27, 3 March 2013 (EST)

Next step: Review your GEDCOM [3 March 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded test Jackson.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 17:50, 3 March 2013 (EST)

Next step: Review your GEDCOM [5 March 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded test Jackson.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 18:40, 5 March 2013 (EST)

Next step: Review your GEDCOM [5 March 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded test Jackson 1335.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 18:55, 5 March 2013 (EST)

Next step: Review your GEDCOM [5 March 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded test Jackson.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 20:37, 5 March 2013 (EST)

Person:Oliver St John (25) [11 March 2013]

Hi DataAnalyst, thanks for tidying up this person. Have you any view about which of the two hypothesised parents are more likely to be right? I didn't know if you had any more evidence than was up there already. Thanks AndrewRT 18:46, 11 March 2013 (EDT)

Sorry - I've got nothing other than the citation from the Bulkeley Genealogy. He is the brother-in-law of a direct ancestor of my husband - just on the edge of my scope - so I did not attempt to find his parentage.--DataAnalyst 22:09, 11 March 2013 (EDT)

Source:Whiting, William. Memoir of Rev. Samuel Whiting, D.D., and of His Wife, Elizabeth St. John, p. 39, does not seem to provide sources but agrees with Foster's Royal Lineage and provides a line (again, with no evidence presented) several generations back from there. One would think for such a prominent line, it might be covered by one of the "visitation" sources where (as it appears to my limited understanding) the church surveyed the important people in each parish. --Jrich 22:41, 11 March 2013 (EDT)

My understanding of the Visitations is that it was for the purpose of heraldry - to prove that a family had a right to a particular coat of arms, based on descending from the person to whom the coat of arms had been granted (or, I suppose, at least from someone who had established a right to the coat of arms). It was the heralds that conducted the Visitations - and they are not particularly reliable, because people had a vested interest in "proving" that they were entitled to a coat of arms by self-reporting their ancestry (still, they get used for genealogy in the absence of any other evidence proving them wrong). I have no idea if St John had the right to a coat of arms - if not, it would explain why he was not reported in a Visitation.--DataAnalyst 23:08, 11 March 2013 (EDT)

Thank you for the correction. I don't do much work in England, so apparently misinterpreted the purpose. --Jrich 00:13, 12 March 2013 (EDT)

'Death' date of Joan Brooke, wife of Robert Foote [15 March 2013]

Data,

There is a discrepancy on the 'death' (or rather, last known to be alive) date of Person:Joan Brooke (17). Last date known to be alive is stated from will of her mother to be in Jan 1608/9, but her mother Elizabeth Whetman Brooke had a will dated 18 Jun 1599 and she herself was buried on 30 Jun 1599. So how can she (Joan) be last known to be alive in the will of her mother in 1608/9 when her mother was dead for nearly 10 years? I realize this could be a simple error, but if not I will dig out the source to correct it.--Daniel Maxwell 14:38, 14 March 2013 (EDT)

I think you read both citations and the latter one stuck in your head. The first citation refers to her husband's will (1608/9) not her mother's will.--DataAnalyst 19:51, 14 March 2013 (EDT)

Ah yes I had mistagged it in my own tree and misread the citation. Sorry about that!--Daniel Maxwell 20:02, 14 March 2013 (EDT)

Next step: Review your GEDCOM [20 March 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Edward Jackson - 991 - test places.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 22:08, 20 March 2013 (EDT)

Next step: Review your GEDCOM [15 April 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded James Queener - 1091.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 19:32, 15 April 2013 (EDT)

Next step: Review your GEDCOM [15 April 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded James Queener - 1087.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 20:48, 15 April 2013 (EDT)

James Queener - 1087.ged Imported Successfully [16 April 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 17:32, 16 April 2013 (EDT)

Next step: Review your GEDCOM [20 April 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Stephen Jackson - 1207 - first try.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 18:45, 20 April 2013 (EDT)

Next step: Review your GEDCOM [24 April 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded temp.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 21:18, 24 April 2013 (EDT)

Next step: Review your GEDCOM [27 April 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Joseph Jackson - test.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 09:10, 27 April 2013 (EDT)

Next step: Review your GEDCOM [2 May 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Stephen Jackson - 1205.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 18:57, 2 May 2013 (EDT)

Next step: Review your GEDCOM [3 May 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded David Jackson - 743 - check places.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 23:06, 3 May 2013 (EDT)

Next step: Review your GEDCOM [8 May 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded David Jackson - 742.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 20:08, 8 May 2013 (EDT)

Next step: Review your GEDCOM [8 May 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded David Jackson - 742.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 20:13, 8 May 2013 (EDT)

David Jackson - 742.ged Imported Successfully [9 May 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 23:30, 9 May 2013 (EDT)

Next step: Review your GEDCOM [14 May 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Joseph Jackson - 2154.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 22:16, 14 May 2013 (EDT)

Next step: Review your GEDCOM [19 May 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Joseph Jackson - 2149.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 10:18, 19 May 2013 (EDT)

Joseph Jackson - 2149.ged Imported Successfully [22 May 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 22:50, 22 May 2013 (EDT)

Next step: Review your GEDCOM [23 May 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Edward Jackson - 1223.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 20:00, 23 May 2013 (EDT)

Next step: Review your GEDCOM [26 May 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Edward Jackson - 1223.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 12:12, 26 May 2013 (EDT)

Edward Jackson - 1223.ged Imported Successfully [27 May 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 10:56, 27 May 2013 (EDT)

Next step: Review your GEDCOM [31 May 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded William Jackson - 763.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 12:51, 31 May 2013 (EDT)

William Jackson - 763.ged Imported Successfully [2 June 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 23:34, 2 June 2013 (EDT)

Next step: Review your GEDCOM [3 June 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Holden Rushing - 1978.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 19:48, 3 June 2013 (EDT)

Next step: Review your GEDCOM [8 June 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Hannah Bennett - 1005.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 12:54, 8 June 2013 (EDT)

Hannah Bennett - 1005.ged Imported Successfully [8 June 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 20:30, 8 June 2013 (EDT)

Next step: Review your GEDCOM [9 June 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Holden Rushing - 1976.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 10:19, 9 June 2013 (EDT)

Holden Rushing - 1976.ged Imported Successfully [11 June 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 15:24, 11 June 2013 (EDT)

Next step: Review your GEDCOM [14 June 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Benjamin Jackson - 1511.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 00:39, 15 June 2013 (EDT)

Next step: Review your GEDCOM [15 June 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Benjamin Jackson - 1510.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 23:09, 15 June 2013 (EDT)

Benjamin Jackson - 1510.ged Imported Successfully [16 June 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 11:32, 16 June 2013 (EDT)

Next step: Review your GEDCOM [23 June 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Robert Jackson - 1081.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 09:39, 23 June 2013 (EDT)

Black Creek, Prince Edward County, Ontario [23 June 2013]

Hi I see you have been adding to the list of places in Prince Edward County. Cherry Valley will have the article from Wikipedia built into it in next week's update. But Black Creek is being somewhat more elusive.

When I worked on Ontario last year I had a website bookmarked that placed every community in Canada. Since then my computer blew up, was replaced, and, although I have all my data, I can't figure out how to link my list of bookmarks back into Firefox. The name of the website (not the URL) is very long-winded and I can never remember it. Google has just led me to http://www4.rncan.gc.ca/search-place-names/name.php from where I got the following info:
Feature type : Unincorporated area
Generic : Dispersed Rural Community
Location : Prince Edward
Latitude - Longitude : 43º 58' 5 N, 77º 1' 50 W
Latitude - Longitude (decimal) : 43.96792, -77.03053 from which I shall be able to get it out of the "unknown" category.

One more bookmark back into my collection!

Regards --Goldenoldie 14:43, 23 June 2013 (EDT)

Thanks! I was unaware of the Natural Resources web site. It will make future searches easier. I am uploading JanieJac's 20,000+ person database, which is leading me to verify a lot of place names where I have not done the research myself. Most of the places are in the U.S., but one branch of her tree was largely in Ontario. I appreciate the update and the link.--DataAnalyst 14:54, 23 June 2013 (EDT)

Let me know if you have any more problems with the Ontario stuff--or any in southern Scotland, if she has any. Scotland is getting the same treatment as Ontario did.

In both cases the central government has, since 1975, reduced the municipal organization tree by one layer. This means it is very necessary to make some notes in WR's "See also" box so that we can discuss the original township (Ontario) or county and parish (Scotland) circa 1900 and also in today's terms. The original terms will always be necessary to check vital records in the era in which they were registered, while the newer organization has to be used to find the place on modern maps.

The Ontario government had the "courtesy" to renovate its website as soon as I had completed the province on WR. As a result, many URLs, particularly those for the 1951 maps, now end up at a useless "sorry, we moved it" page. Aaaarrghhhh!

cheers, Pat

Next step: Review your GEDCOM [23 June 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Robert Jackson - 1081.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 18:44, 23 June 2013 (EDT)

Robert Jackson - 1081.ged Imported Successfully [24 June 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 11:26, 24 June 2013 (EDT)

Next step: Review your GEDCOM [27 June 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded George Hewlett - 445.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 08:42, 27 June 2013 (EDT)

Next step: Review your GEDCOM [28 July 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded test large file.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 18:32, 28 July 2013 (EDT)

Next step: Review your GEDCOM [9 August 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded George Hewlett - 445.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 18:31, 9 August 2013 (EDT)

George Hewlett - 445.ged Imported Successfully [12 August 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 07:29, 12 August 2013 (EDT)

Next step: Review your GEDCOM [12 August 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Martha Jackson - 877.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 20:13, 12 August 2013 (EDT)

Next step: Review your GEDCOM [14 August 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Martha Jackson - 877.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 18:50, 14 August 2013 (EDT)

Martha Jackson - 877.ged Imported Successfully [18 August 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 09:49, 18 August 2013 (EDT)

Next step: Review your GEDCOM [19 August 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded James Jackson - 4605.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 22:55, 19 August 2013 (EDT)

Next step: Review your GEDCOM [24 August 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded James Jackson - 4605.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 14:58, 24 August 2013 (EDT)

Wissler/Wistler [1 September 2013]

Hi, I saw that you changed some data on Jacob Wissler and Sarah Jackson. Is Sarah the sibling of one of your ancestors? I have that I am descended from Jacob W. Whisler and Sarah Waltz. It looks like the two Jacobs may be the same person but more research would be needed to tell. I did very little research on these lines, mostly used the info given to me by the relatives that searched and then did some work 12 years ago or so. I did visit the state library and Hamilton Co on a visit there. Beverly--Bevbh 17:00, 1 September 2013 (EDT)

Hate to disappoint you about possibly finding a close relative, but I am uploading data on behalf of Janiejac, and she has a very large database of Jacksons. Sarah Jackson (wife of Jacob W Whistler/Wissler) was the third cousin of Janie's great-great grandfather, Benjamin Jackson (1817-1845). Their common ancestors are James Jackson and Rebecca Hallett. I will be uploading Sarah's ancestry within a week or so.

You can contact Janiejac to see if she has any more information that will help with resolving the identity of Jacob Whistler/Wissler, but based on the copy of her database that I have, it looks like all she has are the marriage record, census records and info from Janeen Proctor.

Good luck with your research!--DataAnalyst 18:27, 1 September 2013 (EDT)

‎James Jackson - 4605.ged [7 September 2013]

While reviewing your gedcom, a problem was identified and the file will be unable to be uploaded in its current state. Your gedcom contains some duplicate families. To fix this problem, the file will need to be corrected in your personal database, removed from WeRelate (click "Remove this GEDCOM" from the Overview tab), and uploaded again before it can be accepted. Unfortunately, this is one of the errors that cannot be rectified using the WeRelate review process.

If you have any questions, you can reply here. I will be watching your Talk Page.

Thanks.--Khaentlahn 00:05, 3 September 2013 (EDT)

Khaentlahn, in this case, I believe we should upload this GEDCOM. DataAnalyst has been working hard to help another user import her files and the hundreds of Family Matches have already been processed. DataAnalyst is an active user who will be able to merge the few duplicate families after upload.

The duplicate families are:

• Thomas Jackson and Mary Willis
• John Seaman and Hannah Williams
• Thomas Thorne and Penelope Coles --Jennifer (JBS66) 12:04, 3 September 2013 (EDT)

Thanks, Jennifer. As you said, I am doing this upload for Janiejac. Of the 3 potential duplicates that WeRelate tagged, going by Janie's information, only one is suspect.

• Janie's notes say explicitly that Mary Willis married two different men, both named Thomas Jackson - the information looks credible, and is supported by the source book - I will add the exact citation.

Done, and nomerge template added.--DataAnalyst 09:20, 7 September 2013 (EDT)

• The 2 John Seaman and Hannah Williams families are separate generations (two different John Seamans, born about 35 years apart). It is entirely possible that both are valid marriages, so again, I will assume that it is right and leave it alone.

Nomerge template added.--DataAnalyst 09:20, 7 September 2013 (EDT)

• Thomas Thorne and Penelope Coles does look suspicious, but this is not a simple duplicate. The two Thomas Thorne's are different individuals (both sons of Joseph, but different Josephs), and I would guess that only one of them married a Penelope Coles, but I am not sure which one. I'll check out the sources more, but if I can't determine which is correct, I'll add notes (or put both men in the same marriage, as I have seen others do) or leave it to Janie to resolve.

One marriage and one Penelope Coles kept and the other merged into it, based on Bunker source. The other Thomas Thorne left with no marriage.--DataAnalyst 09:20, 7 September 2013 (EDT)

2 of the 3 sources cited actually show the opposite result. It also appears from a snippet that NYGBR 94 (1963):42 agrees, though I can't see the whole thing. The older Thomas m. Letitia Hinchman (29 Jul 1727). :-( --Jrich 17:38, 7 September 2013 (EDT)

Thanks, JRich. I think only half my brain was functioning when I worked on this, because I didn't even notice the other sources to check. I changed the records as per Clarke (not just Thomas's first marriage, but his second one as well, as well as death date). As you pointed out, the Bunker source seems rather weak at this particular point and there is no good reason to prefer it. Clarke gives ages for both Thomases at death - but I don't know if they come from gravestones/VRs (which would distinguish them), or are just calculated (which doesn't mean anything).--DataAnalyst 19:14, 7 September 2013 (EDT)

I trust that this is acceptable and not worth holding up the upload for. As you said, I have spent many hours on this upload and I believe that the quality overall is consistent with WeRelate expectations. Thanks. --DataAnalyst 19:40, 3 September 2013 (EDT)

Error importing James Jackson - 4605.ged [5 September 2013]

We had an error while attempting to import your GEDCOM. This is most likely our fault. We will review the error and should have your pages ready tomorrow (or Monday if tomorrow falls on a weekend). There is no need to re-import your GEDCOM file.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 21:05, 3 September 2013 (EDT)

In attempting to import this file, this was the error that was generated. Hopefully this can be fixed. It may be that the duplicate individuals will make it impossible for the review process to import the file, but this is outside my knowledge base.--Khaentlahn 21:15, 3 September 2013 (EDT)

Thanks - I really hope it can be fixed too. It will be a fair bit of work to redo, since I did not keep track of the handful of "matches" (out of almost 400) that were a nomatch.

Dallan - Note that some of the families that I matched to were renamed after the match and before the upload - I hope this is not the source of the error, as I would expect that the redirect feature would handle this. If the potential duplicates noted by WeRelate are preventing the upload, I can exclude one of each pair and add them manually later. If this is the cause of the failure, can you add instructions to the upload to indicate this and suggest what I just suggested (exclude one of each "duplicate" and add them manually later)? Thanks --DataAnalyst 21:23, 3 September 2013 (EDT)

I've seen this happen occasionally and, at those times, Dallan reprocessed the file and continued the upload where it left off. I sent him an email this morning just to be sure. --Jennifer (JBS66) 06:43, 4 September 2013 (EDT)

Thanks --DataAnalyst 20:29, 4 September 2013 (EDT)

I wish there was some kind of award or badge to give Data for what she has been doing for me and for WeRelate! She has been working since early March to upload, not her own family, but my large data base! I call this real collaboration as I would never have got it done. I understand the process but my 26,000 person database was overwhelming. Somehow, someway, eventually, the process needs to be streamlined so that others won't be as overwhelmed as I was. MANY THANKS FOR YOUR GREAT EFFORTS! --janiejac 23:24, 4 September 2013 (EDT)

Sorry - I've been out of town and haven't been able to get to this; I get back late tonight and will look at it first thing tomorrow. I'm sure I'll be able to get it loaded.--Dallan 13:52, 5 September 2013 (EDT)

James Jackson - 4605.ged Imported Successfully [6 September 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 23:52, 6 September 2013 (EDT)

Next step: Review your GEDCOM [7 September 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded James Queener - 1087.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 15:23, 7 September 2013 (EDT)

Next step: Review your GEDCOM [7 September 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Jemima Jackson - 633.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 16:02, 7 September 2013 (EDT)

Next step: Review your GEDCOM [10 September 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded Jemima Jackson - 627.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 21:42, 10 September 2013 (EDT)

Jemima Jackson - 627.ged Imported Successfully [11 September 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 09:20, 11 September 2013 (EDT)

Example of Collaboration to Load a Database [5 October 2013]

This is an example of a collaborative effort, in which I helped JanieJac load her database. After we were done loading it, others (in particular, JRich – thanks!) provided additional corrections and additions (e.g., adding dates and places, merging individuals, etc.).

The reason I write this up, is that it may prove informative for others who are overwhelmed by the prospect of loading a large database - to show that it can be done, and may not be as much work as they think (depending on the degree of cleansing required).

Starting with a database of approximately 20,000 deceased individuals, the following work was done:

• Split tree into smaller trees for uploading
• Cleansed the data:
  • Cleansed place names (and in some cases, added place names to WeRelate)
  • Found or estimated birth years where missing
  • Merged sources
  • Corrected errors found by genealogy software and WeRelate
  • Corrected errors and added information based on additional research resulting from above tasks
• Loaded trees into WeRelate

The hours spent were not tracked, but it is estimated that the entire process took approximately 500 to 700 hours, with the bulk of the work (400-500 hours) spent cleansing the data. The majority of cleansing time was spent on the two largest tasks – cleansing place names and finding/estimating birth years.

While it may seem like a lot of effort went into cleansing the data before the load, and several corrections were made afterwards, the error rate was actually quite low – other than place names and adding birth years, corrections touched only about 1-2% of the people. There may, of course, be further corrections in the future, but that is to be expected with a database of this size.

A large part of the cleansing effort focused on place names and on adding/estimating birth years where they were missing. The former was done because Janie was particularly interested in standardizing place names, and the latter due to my personal preference for having at least estimated birth years available in search results. Being a bit obsessive, I chose to look up birth years in census records where available. This process proved useful, as a few more errors were discovered and fixed. It should be pointed out, though, that neither of these efforts was mandatory before uploading the file to WeRelate.

I believe that the biggest obstacle for Janie doing this work herself was the need to split the file. I ended up disconnecting about 150 people from their parents to split the file into small enough trees (350 to 4600 people each) for loading. While a bit daunting, this took only one (very intensive) weekend. Janie has asked me to document the process I used, and I will likely attempt to do so at some point, although it is one of those things that may be easier to do than to explain.

Some statistics and estimates

Database profile:

People born before 1600	2
People born 1600-1699	571	3%
People born 1700-1799	3,442	17%
People born 1800-1899	13,227	64%
People born 1900-1999	3,273	16%
People with burial place*	4,534	22%

* I mention burial places in particular, because the largest effort in cleansing place names was cemetery names. Much of the original documentation of burial places likely took place before Find a Grave was available or had enough information to be useful. In some cases, the same cemetery was described with up to 7 or 8 different names. This isn't intended as a criticism - just a point about how hard it was prior to Find a Grave to be certain of cemetery names (and even Find a Grave is not perfect).

Cleansing statistics – note that the last 3 areas represent a fairly small percentage of the database:

Merged/eliminated 1915 places	27.5% of places
Found/estimated 4300 birth years	21.5% of people
Merged 100 sources	7.5% of sources
Merged 33 people	0.16% of people
Corrected 170 errors found by software or WeRelate	< 1% of facts
Added/corrected additional information	< 1% of facts

Effort estimates – these reflect only this particular file**, but are at least a very rough guide for future efforts. They show that the effort to split and load the file was not excessive – this amount of time seems quite reasonable to me. As mentioned above, the bulk of the work went into cleansing, and most of that into 2 tasks (places and birth years).

Split into smaller files	1 hr/1000 people
Load into WeRelate	Up to 8 hrs/1000 people

** This particular file had a reasonably high degree of internal integration (and thus took a while to split), but had a relatively low degree of overlap with existing WeRelate data, other than data previously loaded from the same database (and thus was relatively easy to match and merge).

Post-load corrections. I have no estimate for how much time this took, but several corrections and additions (e.g., adding marriage date and place) were made shortly after the data was loaded.

Net result – I wish I had kept statistics on the number of new people I loaded, but I didn’t. However, I would guess that in the end, Janie and I uploaded between 10,000 and 15,000 new individuals into WeRelate (in a period of 5 ½ months). Well worth the effort! (And I even had some fun doing the research – after all, isn’t that why we do genealogy?)--DataAnalyst 22:58, 15 September 2013 (EDT)

Thomas Minor Revisions [24 December 2013]

Thanks for the input, I'm on board with your point re: christening vs. birth date. However, in this case, I believe Thomas' page is now incorrect. Here's why:

-Source 2 indicates that Thomas was baptized 23 Apr 1608 (not christened).

-No source listed in the record indicates Thomas was ever christened. This makes the current record factually incorrect.

-Source 7 (by John A Miner) is clear that Thomas was born 23 Apr 1608, not baptised or christened. All of John's published work consistently indicates 1608 as Thomas' birth date. John is the lifelong Miner/Minor researcher and founder of the Miner Association. Very credible source is my point. Was Thomas born or baptized 23 Apr 1608. I don't know - both are shown in the record.

-As now written, the terms christening and baptism are being used interchangeably - a problem I've noticed in many WeRelate records. Baptism is typically the act of bringing the child into the church family. Christening is the naming ceremony. There are exceptions, but the record as it relates to Miner/Minor is quite consistent in its use of baptism.

I hope I've clearly explained why I made the changes. I believe they make the record more factually correct than the way it is now. Maybe some note regarding the slim likelyhood that Thomas was born and baptised on the same day is in order. Problem is, both are purported to be true - just depends on who you want to believe. That's why I included 23 Apr 1608 as a birth date and as a baptism date.

Best, Frank--Frank 03:13, 25 September 2013 (UTC)

If you read the GEDCOM standard, the meaning of the BAPM tag, and the CHR tag seem interchangeable.

BAPM {BAPTISM}: = The event of baptism (not LDS), performed in infancy or later.

CHR {CHRISTENING}: = The religious event (not LDS) of baptizing and/or naming a child.

CHRA {ADULT_CHRISTENING}: = The religious event (not LDS) of baptizing and/or naming an adult person.

It used to be that the two tags were treated differently, with Christening understood by the system, Baptism not. Now they seem to be handled the same. Still Christening corresponds to the always-there fact, next to the birth, while Baptism is optionally displayed, at the bottom in the edit screen. In practice, I believe nearly everybody simply uses christening, partially due to the historical differences, partially because its position on the display represents why either of these events are of interest. It is basically a church event that acts as a proxy for birth when birth is missing, or to confirm reasonableness of the birth when it is there. Adult baptism is seldom documented because it seldom has much use, except perhaps to note residence changes or name changes due to marriage, etc. --Jrich 04:19, 25 September 2013 (UTC)

[Adding the following to keep the topic in one location. --Jrich 14:17, 25 September 2013 (UTC)] es, the GEDCOM standard does appear to use the terms baptism and christening interchangeably. The broad non-specific nature of the definition accommodates the different and widely varying practices of all religions. It is not meant as as a defacto one-size-fits-all standard. To apply it as such diminishes the wonderful and rich diversity of our religions.

A case in point is the Minor/Miner family baptisms of 15 Sep 1751, when four Minor children ranging in age from a few months to a few years old were baptized in the First Church of New London, CT. Clearly, this was not a naming ceremony, but rather a ceremony to bring the children into the church and its belief system. To note these ceremonies in the WeRelate record as a christening is not historically correct, nor would it be consistent with Connecticut VRs, church records, and the independent conclusions of multiple genealogists.

Consider Hans Landis, the Swiss Anabaptist Minister martyred in 1614 by the civil authorities of the canton of Zurich, Switzerland. He is emblematic of an entire religion based on when and how many times a person of faith should be baptized. The Anabaptists (meaning twice baptised) later evolved into the Mennonites, Amish, and numerous other offshoots all with their own distinct timing and religious dogma surrounding baptism. Neither the term nor pracice of christening (as in a naming ceremony) is used by any of these faiths.

Next steps:

1) WeRelate data entry protocals should be adjusted to accomodate the diverse and unique practices of all religions. 2) The baptism entry should be used when applicable. In my opinion, it should be on par with the christening entry; that is, neither baptism or christening should have preference. 3) More attention needs to be paid to the distinction between baptism and christening, including the use of christening as a defacto birth record - a practice that should be avoided if for no other reason than accuracy in my opinion.--Frank 13:12, 25 September 2013 (UTC)

First of all, your statement "bring the children into the church" is not clearly so. Usually communion does that. And most infant deaths are recorded with no name for the child. So I disagree with your base argument, at least to the "clearly" extent. Second, baptism was a subject of much religious dissension during the time period in question, so practices of modern religions have no bearing on what was done then, and further I have no desire to become a religious-history nut to figure it out. Third, it doesn't seem to be the meaning of the ceremony itself that makes baptism or christening important to genealogy. Fourth, since the rest of world, including software makers, are using GEDCOM, the data coming into WeRelate is going to be that way whether WeRelate chooses to make itself different or not. So no matter what rules are written, incoming data will tend to use either tag for either meaning and soon there will be no consistency anyway. --Jrich 14:17, 25 September 2013 (UTC)

To move the conversation along, let's put all the esoteric religious discussion aside - at least for now. For me, this all boils down to whether or not the data in WeRelate reflects the historical record; that is, vital records, church records, family bibles, and the rest. What do the records say? The answers are what should be in WeRelate.--Frank 14:53, 25 September 2013 (UTC)

Two points:

First point: Each country has its own history of recording births/baptisms, which is worth understanding. Unlike the U.S., which introduced civil vital records fairly early, the UK did not introduce this practice (nationally) until 1837. Prior to that, the primary source of "birth" information was parish registers, which recorded baptism date. Occasionally, they also recorded the birth date, but this was not common practice (for more specific information, see this article). Therefore, any date from the UK as early as 1608 that purports to be a birth date is highly suspicious - it was likely a baptism date, and there is no record of the birth date.

Second point: Unfortunately, while it is reasonable to use an early (pre-1700) baptism date as a proxy for a birth date (it would normally be within a month or so of birth), some genealogists have chosen to represent it in their work as the actual birth date. This appears to be the case with the book by John A Miner - whether or not he was personally responsible for this representation in the book.

John A Miner is also co-author of The Curious Pedigree of Lt. Thomas Minor, which clearly indicates that the date is a baptism date, and does not provide a birth date (p. 183: '...the Thomas Myner baptized at Chew Magna on 23 April 1608.' and p. 184: 'Thomas bp. 23 April 1608'). This is much more believable. Therefore, I believe the WeRelate page as I corrected it is accurate.

As for the "christening" vs. "baptism" fact - my personal preference would be to use the "baptism" fact, but my genealogy program (and I believe WeRelate) do not treat them the same and the only way to get the date to display as a proxy for birth date is to use the "christening" fact. So that's what I (and many others) do - as Jrich pointed out.--DataAnalyst 03:15, 26 September 2013 (UTC)

Thanks for the clarifying thoughtful response. Appreciate it. One last question for you: as the practice applies to WeRelate, what is the thinking behind having a christening date display as a proxy for the birth date? If its primary purpose is to populate the header field, what possibility is there to allow baptism dates to be used for the same purpose? In my way of thinking, such a change would result in much improved data integrity - at least when it comes to birth-baptism-christening dates! Best,--Frank 03:45, 26 September 2013 (UTC)

From a quick test (not saved), it looks like WeRelate does in fact display baptism the same as christening. It still applies the "chr:" label, though. I was not aware of that when I reverted the page, so I could have left the baptism date while removing the birth date. My software (last updated Sep 2011) does not treat them the same, so when I upload a GEDCOM file, it will always be christening date.

One of the implications of WeRelate treating them the same, is that if all you have is a baptism date and you are pretty sure it was not in infancy (e.g., a number of children in the same family baptized at the same time, or the baptism of an Anabaptist), you should estimate a birth year so that the baptism is not treated as a proxy for birth date. I was not aware of this and will have to keep it in mind.--DataAnalyst 11:59, 27 September 2013 (UTC)

Yes, I've also noticed the system takes baptism dates and posts them in the header as a christening date. Appreciate you confirming I wasn't imagining it! Over time, I'll probably revert Thomas' date back to a baptism if you have no major objection...--Frank 12:10, 27 September 2013 (UTC)

I have no issue with that.--DataAnalyst 12:12, 27 September 2013 (UTC)

I have to concur that if an event which by all indications is performed in an Anglican church in Chew Magna, Somerset, England cannot be called a "christening" then I'm not sure what the word means. My understanding is that preference for the term christening comes from the Anglican (US Episcopalian) and the Catholic communities. Calvinist communities in the UK (Church of Scotland or Reformed in England) and their successors (e.g. New England Congregational or Unitarian) are the ones who historically prefer the term "baptism". (Speaking as a Calvinist, but from the Dutch tradition.) So absent specific evidence to the contrary, I cannot construe an event in England as anything other than Anglican. --Pkeegstra 13:28, 3 October 2013 (UTC)

Far from being an expert, I 'googled' "anglican christening" and got the following web page about baptism from the Church of England. It references part of today's ceremony as coming from their 1662 Book of Prayer. Offered as a point on the curve.... http://www.churchofengland.org/weddings-baptisms-funerals/baptism-confirmation/baptism.aspx

Also see this page from the Church of England explaining the difference between christening and baptism - at least how they view it. http://www.churchofengland.org/media-centre/news/2013/07/top-10-facts-about-christenings.aspx Frank 16:07, 3 October 2013 (UTC)

You know, I can't recall a single documented instance actually called "Christening" in pages I've worked on. There could be some, but I don't recall any off the top of my head. I ran into this the first baptism I ever tried to enter, saw that the usage on this website was to favor the Christening tag. Since the only external factor that would seem to constrain the website's designers from doing what they wanted is the need to interface with GEDOM, I looked up that standard, and as mentioned above, I could not find enough differentiation of their tag definitions to suggest things were being done wrong. So, I have contributed thousands of Baptisms in the Christening slot, as have, I believe, nearly all users. While the handling has (very) recently changed to make display (but not editing!) more similar for the two tags, that does not impact the fact that existing pages use Christening for things we would all agree are Baptisms. So in essence, the difference may mean something to you, but not to this website really. If we wanted the tags to be used in a more precise, differentiated manner, this would be hard to fix, because it would involve doing an analysis of all the (tens or hundreds of thousands) Christenings to see which tag each one should really be. The easiest way would be to change the display label from Christening or Baptism to both be Chr/Bap (or Bap/Chr if you prefer) so you can't tell the two tags apart. As with various other detailed issues, I think the answer is to take advantage of the narrative or the source citation. When the source citation says they are baptized on such-and-such a date, even if the date is displayed in the Christening slot, you can communicate the more detailed, more precise, point on the page that way. --Jrich 17:46, 3 October 2013 (UTC)

Was this ever resolved? Franklyspeaking has been changing several Sherman-family related Christenings to Baptisms, and I still cannot make heads or tails of the 'why' despite this discussion. The idea that one is 'wrong' and the other correct is not something I have ever heard of in genealogy. It seems to me the best way to go about this is to just remove the distinction completely and maybe combine them into one or the other, or perhaps have them hyphenated like chr/bap.--Daniel Maxwell 18:48, 23 December 2013 (UTC)

Based on the contributions of others that I've seen over the past 2 1/2 years, I think the de-facto distinction was that a christening happened very soon after birth and serves as a reasonable substitute where birth data is not available; i.e., English records from the sixteenth and seventeeth centuries and some jurisdictions in colonial New England (Charleston, Hingham and, to some extent, Roxbury come to mind). In these cases, an estimated date of birth is not needed. Baptisms, on the other hand, were used in cases somewhat to well after the fact. Instances include known adult baptisms and cases where multiple children were baptized at the time one or both of the parents were admitted to full communion. In these cases, where the birth date is unknown, an estimation is necessary to keep a reasonable order among the siblings and to aid subsequent searches by other contributors to give them at least a ballpark idea of a birth date where they're attempting to differentiate among persons of identical or similar names. In my contributions, I've differentiated between christenings and baptisms as described.--jaques1724 19:48, 23 December 2013 (UTC)

Yes I agree with you. But the distinction here is that a user was changing infant christenings, not those of adults (that I saw at least). Daniel Maxwell 23:57, 23 December 2013 (UTC)

Dallan is attempting to implement an event "adult christening" from the GEDCOM spec which is intended to capture the semantics of a christening/baptism event which should not be used as a proxy birth. (But it's not working correctly yet.) My (not yet complete) survey of the branches of Christianity which baptize infants suggest that none of them understand any semantic distinction between "christening" and "baptism". Consequently the Oversight Committee recommends against trying to make any such semantic distinction between "baptism" and "christening" events. Note in particular that the system does treat "baptism" as a proxy birth the same way ot does "christening". --Pkeegstra 21:15, 23 December 2013 (UTC)

That has been my problem with Franklyspeaking's changing of the events. He's been changing non adult christenings of baptisms despite that these people were infants at the time. In those cases, they are 'proxy births' because they are the usual 16 or 17th century CofE manner of record keeping and as close as you will usually get to a 'birth date' in that time period. Daniel Maxwell 23:57, 23 December 2013 (UTC)

Right. So while we aren't quite at the point of formally deprecating "baptism", since there is no semantic distinction and the only implementation distinction in the system is that the "christening" slot is pre-allocated, there is little to be gained by defining new events as "baptism", and even less to be gained by changing existing "christening" events to "baptism". --Pkeegstra 11:36, 24 December 2013 (UTC)

Featured page nomination [18 October 2013]

I wanted to let you know that I nominated you (and your Userpage) for Featured Page of the week. I was inspired by your work with Janie's GEDCOM and the helpful statistics you compiled. Delijim puts together the featured pages each week, and he asked if you could add a bit more detail to your Userpage. Things like genealogical associations you belong to, examples of your work on WR, maybe a photo if you are comfortable with that, etc would be good. If you have any questions at all, just let me know. Thanks! --Jennifer (JBS66) 22:41, 2 October 2013 (UTC)

Thanks - I am glad that the information on collaboration will reach a wider audience, and hopefully inspire more partnerships to get large databases loaded. I have expanded my user profile as requested and added a link to the section of my talk page regarding Janie's GEDCOM.--DataAnalyst 13:45, 5 October 2013 (UTC)

Hi Janet, I really like the additional information you've added to your User Page. If you have any Person Pages that you're particularly proud of, please let me know so I can use that as an example of your work added to WeRelate. You'll be the Featured User for November:)

Thanks much and best regards,

Jim:)

Hmmm - I don't have any person pages that particularly stand out, but maybe Edward Sale (6), for the (tentative) conclusions about which children belonged to each marriage, or Barbara Ringler (2) for the (again, tentative) conclusion about her parents. Both show the extent of source citations that I try to include. My focus right now is on putting together a solid well-documented framework of names, dates and places which others (or maybe myself later) can flesh out to provide a better sense of the people behind the names.

In addition, I have recently been adding the names of Mennonite colonies and villages in Manitoba, Canada and South Russia (now the Ukraine). For example, see Chortitza Colony and Berghtal Colony in Russia/Ukraine, and RM of Hanover, aka the Mennonite East Reserve in Manitoba. Unfortunately, the Wikipedia templates have not yet been filled in.

Let me know if you need anything else from me. Thanks.--DataAnalyst 19:25, 18 October 2013 (UTC)

Next step: Review your GEDCOM [15 October 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded fehr - 734.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 16:57, 15 October 2013 (UTC)

WP templates [20 October 2013]

I noticed that you are placing wp and Wikipedia-notice templates on place pages. Instead, you'll want to add {{source-wikipedia|wikipedia page name}} to the pages. Each week (I believe on Sundays), the system will automatically change the source-wikipedia template to the proper wp and notice templates and propagate them with data from WP. For more information about this process, see Help:Guidelines for use of Wikipedia. --Jennifer (JBS66) 21:03, 20 October 2013 (UTC)

Thanks - I was wondering why the wp templates did not seem to be resolving to content. I did not know where to look for help. Thanks.--DataAnalyst 21:05, 20 October 2013 (UTC)

Next step: Review your GEDCOM [2 November 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded fehr - 757.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 14:22, 2 November 2013 (UTC)

fehr - 757.ged Imported Successfully [8 November 2013]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 02:04, 9 November 2013 (UTC)

Franz Thiessen 1777 [11 November 2013]

Thank you for adding all your information! I just inputted the family tree my Dad had researched years ago, and I look forward to doing my own research in the future. I wasn't sure whether to enter the historical or modern place names, so thank you for making the changes. Your references are amazing. I will check out the Mennonite sites as well.

Douglas Thiessen--Dfthiessen 20:58, 10 November 2013 (UTC)

Glad you appreciated it. If you are not a subscriber to GRANDMA, I would recommend it - well worth the $20 for a two-year subscription. I have copies of the Old Colony (Chortitza) of Russia (Schapansky), Mennonite Migration (Rempel) and B.H. Unruh if you want me to look up something as you do your research. Actually, you can buy B.H. Unruh on CD (same website as GRANDMA). Where do you live? I am curious about where your ancestors moved to, since they stayed in Russia so much longer than mine did.--DataAnalyst 21:08, 10 November 2013 (UTC)

I'm grateful for your advice and the offer for assistance! My Dad's family stayed in Neuendorf until WWII, when the German invasion of the Ukraine enabled them to flee the USSR (The Nazis had a policy relocating German-speaking people). My grandfather had been one of the Mennonite men who were arrested and exiled (possibly executed) in 1938 as part of Stalinist purges. My grandmother, my Dad and his brother and sisters were initially in Oderberg, Oberschlesien(now Czech Republic)and Poland. They escaped into West Germany at the war's end, and came to Yarrow BC in 1949 with the help of the MCC. My relatives are mostly here in the Vancouver area, but we have some relatives in Winnipeg (some who came to Canada earlier). When did your relatives leave Neuendorf?--Dfthiessen 21:50, 10 November 2013 (UTC)

I should mention that GRANDMA is not perfect - what genealogy is? - but it has a ton of information and is a good starting place for more research. Some of its more common errors appear to be using burial dates as death dates, but this is because that is how they are published in some of the church book transcriptions.

My ancestors were among the first to leave Chortitza and Bergthal and come to Manitoba in 1874 to 1876. One line (Fehr) immigrated to Manitoba from the Chortitza Colony in 1874, which was unusual, as most of the earliest immigrants were from the Bergthal Colony and the Kleine Gemeinde. The latest my Fehr ancestors stayed in Neuendorf appears to be about 1810, after which they moved to Neu Osterwick, Chortitza. There was a lot of movement between the villages in the early days of the colony, so it surprised me a bit to see that your ancestors stayed in one village so long, but I guess that makes sense once the colony was reasonably well-established. For the most part, I don't know which village(s) my ancestors lived in between about 1815 and 1874.

My other lines moved to the Bergthal Colony when it was established. You might not know, but virtually the entire Bergthal Colony emigrated to Canada - their leaders convinced them to do this as a community, and I believe that those who could not afford the move were subsidized by those who could. When I read what happened to your grandfather (and I think I noticed another relative too), I am so glad that my ancestors chose to leave when they did. Very chilling.

The largest number of my relatives are in Manitoba, but many live in Saskatchewan, Alberta, B.C. (I have an aunt and uncle and cousins in Vancouver) and other parts of Canada, and some emigrated to Paraguay in the 1920's. Take care.--DataAnalyst 22:21, 10 November 2013 (UTC)

I can tell you've learned a lot of history through your research! If it wasn't for the MCC and the Mennonites that came to Canada early on, my Dad's family would have probably ended up in Paraguay or some place like that. I heard that some unmarried men in my Dad's family were sent off to Canada if they caused trouble or if times were tough. Ironically, they ended up being the lucky ones. How lucky we all are to be here in Canada! Thanks again for inspiring me to do some more research.--Dfthiessen 08:27, 11 November 2013 (UTC)

Recent Cheshire edits [11 November 2013]

Hi. I had been getting a bit down recently as edits to pages I have been watching that have actually made the pages worse have been outnumbering the improvements. Your November 9 edits on some Ormerod-related pages have brought the ratio back into positive territory and are helping to restore my faith in a collaborative approach to genealogy. Thanks.--Werebear 21:47, 10 November 2013 (UTC)

I realized some time ago how hard it is for people to let go of the "facts" they have researched. I have lamented myself when I've had to lop branches off my tree that I realized did not belong after spending months researching and documenting them. All we can do is keep correcting and providing a role model of better data, better sourcing and respectful collaboration. It took a couple hundred years for the data in amateur genealogy to get in as bad shape as it is, so I imagine it will take decades (if not centuries) to turn things around - we just have to take the long view.

BTW, I left a question for you at Person talk:Hugh de Venables (1). I don't know if you will have noticed it among all the emails I must be flooding you with.--DataAnalyst 13:52, 11 November 2013 (UTC)

Next step: Review your GEDCOM [11 November 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded test.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 01:55, 12 November 2013 (UTC)

WeRelate Featured User - week of November 11, 2013 [12 November 2013]

Hi Janet, congrats, you're this week's WeRelate Featured User! You are shown on the Main Page of WeRelate, and we've listed a few of the pages you mentioned to help show the detail and source-based work you've added to WeRelate! Thanks for the additions on your User Page and providing the sample pages and other information. You will remain on the Featured Page until November 25th.

Again, congrats, and keep up the good work!

Best regards,

Jim:) Volunteer Administrator - WeRelate--Delijim 20:41, 12 November 2013 (UTC)

alt dates in the medieval and genealogical spaces [26 November 2013]

You offered remarks of some length on this subject, on a particular person page. I responded there, but want to respond directly as well.

In summary - I completely agree. So much so, that I think your careful remarks on the subject are overkill.

I think the origin of many (probably most) of the alt dates, is as a consequence of de-duplicating in situations where there are different GEDCOM estimates. They're almost never sourced - and I doubt that there's any value in trying to determine their origin most of the time.

When you find a better quality date or date estimate - from Cawley for example - please feel free to jettison unsourced alternatives without comment - in favor of the better data with attached source. If there are legitimately different alternatives - they will eventually come back into existence if/when other basis documents are offered into evidence. It's a far better use of your time to add available positive information - than to worry even a moment about trying to prove the non-existence of alternatives.

Thanks for being interested in the outer limits and medieval genealogy!

--jrm03063 17:53, 25 November 2013 (UTC)

Ah - maybe the context was not clear. I had estimated the 1150 birth year (with a note on how I arrived at the estimate) and Werebear later added the "calculated" 1155 birth year (with source) and moved the 1150 estimate to alt birth year. I assume that Werebear was wary about removing my estimate. The intent of my note was to encourage replacement of one estimate with another, rather than keeping both - but with a caution (essentially, although not worded quite this way) about representing the 1155 birth year as a calculated year, since I have my suspicions that it is more of an estimate than a calculation based on a primary source.

When I was working on medieval lines a few years ago, I was pretty free about tossing unsourced dates and replacing them with estimates based on info from Cawley.--DataAnalyst 01:46, 26 November 2013 (UTC)

Next step: Review your GEDCOM [25 November 2013]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded test.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 01:50, 26 November 2013 (UTC)

Adding Gård to list of place types [1 December 2013]

Hi

I noted your recent suggestion. How I wish there was a name for this type of farm in English!

My family had a farm in Kirkcudbrightshire, Scotland. Inspecting the 1841 census for the whole farm (not just the surname group) and the baptismal entries from the 1750s onwards showed me that it was also the home of many inter-related families. The whole parish and many beyond were also made up that way. The influx of agricultural machinery was probably what put an end to it. The concept did not make its way to North America, perhaps because farms were so much easier to buy (not tied to the "lord of the manor", etc.)

I enjoyed reading your autobiographical sketch.

Regards --Goldenoldie 08:16, 1 December 2013 (UTC)

Check out the Wikipedia articles on hamlet and village. In Canada, hamlet is an officially designated term, but it appears that in the UK it is less formally applied, and sounds like it might fit the bill for your Scottish farm - unless there was a church there, in which case it appears that it might have been considered a village.

As far as I can tell, the Norwegian gårder were essentially the same as the farming villages my German Mennonite ancestors established in what is now the Ukraine, where several farming families lived in relatively close proximity to each other and farmed the surrounding area, but also provided services in tailoring, blacksmithing, etc. They lived in similar settlements in the Danzig delta before that - and every German Mennonite resource I have seen calls them villages. This pattern is not familiar to me, since I live in western Canada, where the Dominion Lands (homestead) Act required farmers to live on the quarter-sections (160 acres) of land they were given, thus making them pretty isolated from one another (although it appears that some, such as my husband's great-grandfather, who was a farmer, postmaster, blacksmith and inventor, managed to establish small settlements patterned on farm villages in their homelands).

I'm hoping that Dallan will have time to add gård to the list of place types, but if not, I suspect I will create these farms anyway and call them either hamlets (even though I can't see any evidence of the term being used in Norway) or villages (Wikipedia lists several of them as villages). I have a lot of work to do on my Norwegian data first, though, so I'll wait and see.

BTW: I have Scottish ancestry and wish I could trace it back to Scotland, but have hit a brick wall with my Scots-Irish ancestor John Stewart, who lived in the County of Cork, Ireland. With such a common name, and knowing about the destruction of many Irish records, I have my doubts about ever being able to chase that line down.--DataAnalyst 16:00, 1 December 2013 (UTC)

Wikitree and WeRelate [10 December 2013]

Hi Janet,

Congratulations on your main page status the other week.

I have added the following line into the Wikitree / WeRelate article so that you can see an example. Nothing flashy but here it is.

For Example On Wikitree my maternal grandfather, Frank O'Sullivan's profile has a link to his profile page on WeRelate where a lot further information is available.

I wish I had thought of this ages ago and set it up appropriately--JeffreyRLehrer 21:15, 9 December 2013 (UTC)

Speculative Child [9 January 2014]

Hi Janet

In a revision to Family:Samuel Blair and Martha Lyle (1) You Wrote:

removed speculative child (wrong generation); a relatively recent published source apparently puts Elizabeth, wife of George Duffield as daughter of Samuel Blair and Frances Van Hook)

Could you identify on the page your source for this. While I seriously doubt that the current (and previous) child list is accurate, we probably need to provide the original source documentation for each child currently in the list. If there is contrarian evidence (i.e., they shouldn't be in the list) we need to document that too. A recently published work could be useful, but would also not be an original source documenting that this is or is not a child of the couple. Q 15:34, 5 January 2014 (UTC)

I had added the source to the marriage record of George Duffield and Elizabeth Blair, but I added it to her record as well, with a note that I don't know if the book identifies her ancestry, or simply speculates it (since I haven't seen the book). Note that when I said "recent" source, I did qualify it with "relatively" - in this case the 1950's (more recent than the 19th century sources otherwise used). :)--DataAnalyst 19:41, 5 January 2014 (UTC)

While the entire list of children for this couple is probably unreliable, I don't know that using a tertiary source is a good way for eliminating, or accepting, any of the children. The work (Keister, 1957) may be well documented or not, but we can't tell from the information readily available. Any any case, its a secondary/indirect source. Not an original source in the sense of the BCG criteria. You've not indicated your actual source for the information. Presumably it accurately reflects whats in Keister, 1957, but perhaps not--we can't evaluate that any more than we can evaluate how good a job Keister did with the family. What's needed are original/direct source documents (what used to be called primary sources) that document the children of this couple. Citing a secondary work, known to you only through a tertiary source, probably isn't the best way to go about eliminating or confirming those children. By the way, you only eliminated one of the 17 children of this couple, currently given in the WeRelate article. None of those children are documented one way or another. Did Keister include all of the other 17 children? Probably not. If that work did include them, then I'd guess that its child list is no more sound than the one that appears currently on WeRelate.

I think it would be a useful thing to research the children of this couple. Probably hard to do since these children were all born around 1700 in Ireland. But in any case, better documentation for them is needed. Q 02:04, 6 January 2014 (UTC)

Well, I didn't think I really needed to justify removing someone from a family when the only way she could have been part of that family was if she married a man 35 years her junior (as per her original unsourced birth year) or she was born to a woman in her 60s (my revised estimate of her birth year). The speculation was clearly across generations, which I indicated. This is the kind of information that should be removed unless it is well-sourced (e.g., if there was solid evidence that she was born when her mother was, say, 45 and she married a man 20 years her junior). Lacking any such evidence, it made sense to remove her from the family, regardless of any source saying anything else.--DataAnalyst 02:28, 6 January 2014 (UTC)

Also, I was not taking on the task of cleaning up this family - only cleaning up one member based on merging duplicates. You are right that there is a lot more to be done with this family, but that was not my immediate task.--DataAnalyst 02:31, 6 January 2014 (UTC)

Hi, Janet,

I have to say that I share some of Quolla's concerns about changes you have been making on Duplicate Pages, particularly the use of derivative sources as a justification for changing pages and removing comments about questionable information. While the pages do look nicer when they are "cleaned up" in this way, I feel that it does a real disservice to other researchers to remove information that appears to be conflicting or troublesome, particularly on the basis of derivative sources.

One reason I feel this is a disservice, and why I'm concerned about it, is because I have spent way too much time having to deal with the apparently "clean" pages on Ancestry, (and WorldConnect and Ancestral File) where the lack of recognition and/or acknowledgement of problems in the reported data have doubled, tripled, or even quadrupled my time, energy and frustration in trying find and sort out the problem. In at least some instances, particularly on Ancestry, these pages may even be "well documented" in the sense that they have many records attached to them. Unfortunately, as Quolla points out, simply citing a source is not really sufficient proof, particularly where the source is derivative and/or the information is secondary.

As a researcher, I would much rather have the information that there are conflicts and/or problems with the information out front where I can see it. Admittedly, the result is a page that doesn't look as nice, but it both warns me and other researchers of the existence of problems, and may suggest where the problems are located.

The use of multiple speculative parents templates is one way of making it clear that there are problems. There are other templates that can be used, as well. One is the Questionable Information template, which might have been appropriate in the case of Elizabeth Blair, based on your comments above. Another template that is very useful is the Red Flag . Again, although not actually a template, the sentence calling for Original Source Documentation can be very useful, particularly where the only sources cited are derivative, and potentially or obviously of questionable quality. Finally, just adding a note in the text section of the page, pointing out apparent problems, is another way to highlight those problems.

Again, I realize that not everyone wants to have all this "messy" information on a page. Beyond my own reasons for preferring it, however, it is worth noting that the recognition and resolution of conflicting information is as much a part of the Genealogical Proof Standard as the citation of sources. Even where the problems/conflicts have been resolved, it is still important to acknowledge the existence of conflicting information and provide an explanation of why some information is accepted as correct while other information is rejected. --GayelKnott 05:27, 6 January 2014 (UTC)

Hi Janet

Gayle has taken more time than I to explain the issue with this particular modification to the page, and has assessed the issues very well. With regard to your statement "Well, I didn't think I really needed to justify removing someone …" I would observe "yes, you did need to justify that". Using a tertiary reference to a secondary source (old school terminology) doesn't serve to justify the change you made. I'd recommend you read up on the standards of proof that the BCG provides, to get a feel for some of the issues related to this. The fourth of their five criteria "resolution of conflicting information" is the one we are most concerned with here. You might also want to read The_problem_of_the_commons which might help you understand why we are concerned with the approach being taken here. Q 05:46, 6 January 2014 (UTC)

The GPS standards cut both ways. The information that was there wasn't exactly primary either. Just because one person asserts something without proof or evidence doesn't earn it the right to be treated as serious genealogical evidence, especially when, as in this case, a child is shown born 6 years after the mother died. The only thing appearing to connect her to this family would appear to be that her husband and the purpoted family were from Ireland, hardly a rare quality at the time. I see no evidence about her birth, leaving her husband's birth as the probably the best grounds for estimating it, and he was also born after the purported mother died. I believe this is an entirely reasonable change. --Jrich 15:36, 6 January 2014 (UTC)

That's quite true. Which is why I said that there was a need to document the DOB's of the children, etc. It would be nice if all articles were well documented with original source material. Eventually, that's the goal, I think. But eliminating things with out documenting why, removes part of the problem, without justification. The problem here is confused enough without adding to the confusion. Q 16:24, 6 January 2014 (UTC)

Something seems awfully one-sided here. If justification is desired in return, I think it is necessary to start with justification, and there wasn't any.

There is some natural ambiguity in who this page represents. The original page was for daughter Elizabeth with no husband and a birth in 1697 based on an AFN (the AFN does no show any marriage). The marriage to George Duffield in 1756 was added with no source and in fact was added to the father of the George Duffield who actually married Elizabeth Blair. As this was wrong, it was apparently corrected to the son, which now made it improbable/impossible, all still without any source identifying the wife of George as the daughter of Samuel and Martha. At that point the page became not the daughter Elizabeth, but the wife of George Duffield. So, after several various edits and merges, the page is covered with narrative about George and nothing about Elizabeth. In fact, the source added to Elizabeth's page by DataAnalyst appears to be the only justification either way. So perhaps the daughter of Samuel and Martha got lost. But I see nothing real that suggests the Samuel and Martha connection to the wife of George Duffield is even possible, and no reason why any serious person should consider it worth saving. It is easy enough to recreate a new daughter for Samuel and Martha, though they have another daughter Elizabeth b. 1706, so this could probably wait until some documentation can be found to justify that such a person really existed. --Jrich 17:49, 6 January 2014 (UTC)

Thanks, Jrich. I do get Gayle's point that sometimes conflicting data has be left on a page, and there are certainly several times I have made comments (more usually on the Talk page, where I think they belong) about incorrect information that has been widely copied into family trees. However, I don't think that WeRelate has to address and refute every piece of bad genealogy out there, and this had the feeling of just plain error. Three sources (2 on his page and 1 on his father's) identified the George Duffield who married Elizabeth Blair as the one born 1732; the page that I merged gave her parents as Samuel and Frances (Van Hook) Blair (no ambiguity); and there was nothing to support the speculation that she was born to a woman at least 65 years older than her husband or even a hint that she married a different George Duffield (of an earlier generation). This appeared to me to be pure error - not worth even making a note of. It is not an error that commonly occurs elsewhere (4 out of 46 public trees at Ancestry.com that give her parents have this error, and none of the family trees at RootsWeb. The error does not exist in the newest incarnation of the Ancestral File.) So you can hardly blame me for thinking this was just an error made by someone who did not look at the dates closely enough to realize it, and did not need a big explanation (I did put one in the edit summary) to justify removing it.

Gayle, if there are other specific changes I have made that concern you, please let me know. I have spent hours and even days researching some of the families I have been merging, and definitely use my judgment at times in discarding unsourced or poorly sourced questionable data (especially when it follows common errors, such as assuming that someone was born where they lived at the time of marriage or death). If you feel that a specific judgment call has been a bit cavalier, let's take a look at it - I might or might not agree with you. (As noted, I would disagree that Elizabeth Blair's page is one that justifies documenting conflicting information.)--DataAnalyst 01:57, 7 January 2014 (UTC)

Janet,

Fundamental to any kind of research that wants to be seen as credible, not just genealogy, is the need to document and explain your judgement calls, or "feelings". It's part of the process that attempts to keep research more or less honest. If you discard information other people have posted, then not just curtesy but a concern for credibility requires that you explain why in a way and place that is easily apparent to other researchers. When you think that something is poorly researched, then you need to explain why you think it is poorly researched, not just discard it because you "feel" that it's wrong. Again, this is fundamental to any research that wants to be taken seriously and seen as credible.

As for other examples, the most extreme one for me is that of Family:John Rogers and Mary Byrd (2), where you deleted a warning posted by another researcher that there was conflicting information regarding John's wife (originally regarding the mother of John's son). You say you spend hours, even days, researching pages you merge, but it would have taken no more than five or ten minutes max to determine that there are serious problems regarding Rachel Eastham, not to mention that who were the wives of both John and his father Giles is problematic. It is not clear that Rachel was John's mother, and a quick look at the Family Page for Giles and Rachel would have made that clear (one or two minutes max, remaining on-site).

There is also the issue of source quality. In the example Family:John Rogers and Mary Byrd (2), the only source you supplied was from WorldConnect, where the original poster used only derivative sources and tried to explain away disagreement in the information contained in his sources by claiming "transcription error" without reference to the original document. At best, this source highlights the need to recognize potential problems with the information being posted on WeRelate. It does not constitute support for deleting a caution that there are problems with research reported here or elsewhere.

Elsewhere, and I'm sorry that I don't remember where, I've seen you give "many existing trees on-line" as an explanation of why some information is correct and other information is not. Aside from the fact that this is not documentation at all, that explanation was buried in the edit summary -- which is not a place where other researchers are going to look for documentation. Sorry, that explanation does need to go on the person page where other researchers will see it. It's that concern for credibility, again. As for "discarding unsourced or poorly sourced questionable data", again, a concern for credibility, if not for courtesy, does require that you provide an explanation somewhere that is easily visible to other researchers. And that explanation does need to include an explanation of why, in your judgement, the data is questionable.

Again, with regard to source quality, there is nothing wrong with citing specific on-line trees, whether on Ancestry or elsewhere, as long as you recognize that these are derivative sources, and subject to error (as, admittedly, are original sources, but that is a different issue). Just because many of them agree does not make them right -- most of the ones that agree are usually copies of earlier ones. If you think that one of them does represent quality research, then the standard procedure is to note the sources cited by the author as evidence of that quality and/or provide an explanation of why you think that specific tree does represent quality research. Doing so not only provides other researchers with an indication of the quality of the source you are citing (one of the characteristics of a good source citation), but also allows other researchers to check the same source for themselves if they so wish. Again, the ability for other researchers to check the sources you cite is fundamental to any research that wishes to be considered credible, in that it allow for what is known as "replicability", one of the most basic aspects of credible research.

The real issue here is not about making judgement calls -- all of us do, and those judgement calls are always made from some point of biased perspective. What is at issue is following those procedures and standards that exist in an effort to make the results of our research as credible as possible, and hopefully allow us to go beyond my bias versus your bias in any discussion. As I've already indicated, those standards and procedures are shared by research in any discipline, not just genealogy, and have been around for a very long time. For genealogy specifically, that have been outlined in the Genealogical Proof Standard, which does include the need to an explanation of why you are doing what you are doing, --GayelKnott 19:33, 7 January 2014 (UTC)

I have posted some information on the page of John Rogers and Mary Byrd that I hope helps. It was not that hard to find. It seems to be the cause of the controversy, so hopefully, this will advance the discussion.

I will add that the original warning, the one that was deleted, deserved to be deleted. The next warning was much better and I hope I haven't upset things by modifying it. The original cited no sources (there ought to be a template for flagging pages that say "some sources" without listing giving any specific examples), did not give any explanation of either the pro or con for either set of parents, and had absolutely no presentation of any evidence that needed to be refuted, explained, or otherwise dealt with, in order to resolve the controversy. In other words, you would never know when you were justified removing it. For all the reader knew, it was merely saying I saw two websites that gave different sets of parents. (Wow! dog bites man!) It had to go in order to make any progress. --Jrich 04:02, 8 January 2014 (UTC)

Thanks for the update. It is transparent, and does move the search forward. --GayelKnott 17:04, 8 January 2014 (UTC)

In the case of Giles Rogers and son John, the only citation for John's wife being Rachel Eastham was OneWorldTree. This is an immediate trigger for me to disregard the data and all subsequent comments based on it. So in this case, I didn't do a lot of extra research - mostly just a sanity check. I will admit that I was misled by the certainty with which other trees stated that Rachel was the wife of Giles (not John) - but we all make mistakes and that is why we are part of a community that corrects each other's mistakes.

BTW: I have updated the source page for OneWorldTree to explain why I think it is a worse than useless source and will continue to feel free to disregard and discard anything citing it. I have no intention of refuting information that came from OneWorldTree on each individual page of WeRelate - the source page says enough and I almost always make a comment in the edit summary in case anyone wants to follow up with me or by looking at the source page. Refuting OneWorldTree every time I encounter it is simply a waste of time and a distraction on the pages. This does not mean that I automatically discard data citing OneWorldTree - I only do so when I find what appears to be more reliable data elsewhere (and like everyone else, I am occasionally susceptible to being misled by what looks like reliable data but is not).--DataAnalyst 02:04, 9 January 2014 (UTC)

Ancestry has several hundred, possibly several thousand, trees that list Rachel Eastham as wife of John Rogers, as well as a (questionable but cited) source: Family Data Collection - Individual Records about John Rogers --GayelKnott 16:56, 9 January 2014 (UTC)

Barbour Series of Connecticut Vital Records [9 January 2014]

What is meant by "edited version" when providing source information from the Barbour series of Connecticut vital records? Example is the record of the 1675 death of Josiah Hull of Killingworth.--jaques1724 18:01, 9 January 2014 (UTC)

See my comments (Different versions with different pagination) on the Talk page of the source. The version of the Barbour Collection that is available at Ancestry.com is a 55-volume version that was edited by Lorraine Cook White (and others, I believe), between 1994 and 2002 (see search results at Google Books). You can see the book (and hence the page number) by doing a search at Ancestry.com, then selecting to view a record, then viewing the original image. Unfortunately, Ancestry.com does not include title pages in the image viewer, but includes the following helpful info:

Original data: White, Lorraine Cook, ed. The Barbour Collection of Connecticut Town Vital Records. Vol. 1-55. Baltimore, MD, USA: Genealogical Publishing Co., 1994-2002.

On the other hand, the typescript version is the one published at AmericanAncestors.org. It is a digitization of "an original Lucius Barnes Barbour typescript in the NEHGS special collections" that was created from 1918-1928. I assume the edited version is based on this typescript (although possibly it is based on the original notes). My understanding from the source page is that there are also slips of papers preserved in the Connecticut State Library - presumably the original notes taken and used to create the typescript.

Under normal circumstances, there would be separate source pages for the typescript version and the edited version, but since the source page seemed to represent the slips and every transcription thereafter, I used it anyway. The links to Ancestry.com (edited version) were on the source page prior to the typescript being added (and before I started linking to this source).

Hope this explains it clearly enough - if not, ask again.--DataAnalyst 01:20, 10 January 2014 (UTC)

James Wilburn Jaynes birth date [3 February 2014]

Thank you so much for correcting the birth date on this record. I tried to enter the source you gave into my tree on my computer, but I haven't been able to bring it up. Where did you search to find the 1880 census you sited?

It was such a pleasant surprise to find someone other than me who had information on our family. --Mary Jean--Jaynes931 23:08, 3 February 2014 (UTC)

Well, you might not want to thank me too fast. I only used the one source, and it is possible that his age is not correct (note the marriage date of his parents). I corrected him because he had 2 sets of parents, so I looked for a census record to resolve which set was correct.

I used Ancestry.com for the census record. While the image says James W. Jaines, Ancestry has indexed it as James W James, so you might want to try searching on that. It is Big Smith Dist, Franklin, Georgia, page 39, supervisor district 2, enumeration dist 30, if that helps. I added the place (Big Smith, Franklin, Georgia) to the source citation (I usually do that, but forgot this time). I have submitted a correction to Ancestry.com, but it usually takes them quite a while to work through corrections and update their indexing (if they agree).--DataAnalyst 00:51, 4 February 2014 (UTC)

James Wilburn Jaynes birth date [4 February 2014]

That's definitely our family, as I had that location in my records for other family members. Our name is a problem as it's been changed and spelled differently in almost every generation. I'll try James. Thanks so much, --Mary Jean--Jaynes931 14:57, 4 February 2014 (UTC)

Andrew Cowan [9 February 2014]

YOu wrote:

I will also add links between Person:Andrew Cowan (20) and Person:Andrew Cowan (4) to indicate that there is strong evidence for them being the same person. If any Cowan researcher chooses to actually merge them, that would be fine with me - I just didn't want to presume to do that myself.

While the question remains open, and I always appreciate help, exactly what is the strong evidence that these are the same persons? Q 23:11, 8 February 2014 (UTC)

I actually took that from a note you made on the Person page of Andrew Cowan (20) on May 29 2011 (18:36). This note still exists on the merged page Person:Andrew Cowan (18), and refers to the evidence immediately above it:

'From this we know that Andrew (4) and Andrew (5) are two distinct persons, and that Andrew(20) is the same person as Andrew (4). The identity of "Andrew Jr." in the Augusta County Court records is as yet undetermined. It is possible that he is in fact Andrew (5), but direct evidence to evaluate that that needs to be developed.'

In making the note at the top of the merged page, I softened it a bit, to say "there is a good case to be made". If you no longer believe that the evidence points in this direction, please update the page(s) to reflect your most recent thinking on this.--DataAnalyst 03:31, 9 February 2014 (UTC)

Just wondering if you had something to go on that I didn't know about. The identity of the various "Andrew Cowan's" is a very complex problem. Eventually, we'll get the right set of original source records, combined with YDNA evidence, and be able to reach a definitive conclusion, I believe. But at the moment this is slightly beyond our grasp. Q 13:46, 9 February 2014 (UTC)

Very strange that you are not an admin [17 February 2014]

Data,

I of course am happy to delete all of the pages you tag in the course of your clean ups, but it seems like it might be easier (and faster) for you to just delete them yourself if you were a member of the speedy delete team. I started off quite similarly - I used to tag hundreds of 'living' people (which don't need to be tagged).--Daniel Maxwell 02:09, 18 February 2014 (UTC)

Yeah, I thought of asking for that privilege, but since I'm focusing right now on cleaning up multiple parents, I thought it would be best to have a segregation of duties - I ask for the delete and someone else carries it out. I realize that isn't necessary for living people, but I am not specifically targeting living people - they are just one flavor of the pages I am requesting to be deleted during the cleanup. I'm seeing quite a bit of garbage from the early GEDCOM uploads as well.

Maybe I should ask for delete privileges anyway, just to use on living people - it would streamline things and not waste overall volunteer time. As long as I can discipline myself and only use the privilege on living persons :)--DataAnalyst 02:28, 18 February 2014 (UTC)

I am not sure the system differentiates between those (only livings and nothing else); you would simply have the power to delete. Naturally, you could be free to restrict yourself to livings...most of what I delete are livings (several hundred a week), the only time I delete 'others' if there is clearly wrong children listed in a family and not mentioned in a source, or such as your own case where you have tagged people and asked them to be deleted. But however you'd like to do, I guess. Speedy Delete can be a uphill battle...we have a staggering number of livings here. Daniel Maxwell 02:34, 18 February 2014 (UTC)

I asked for the privilege - I know I would be able to use it on any page, but I would restrict myself to the policy. I noticed that the delete backlog is very long (about 1000 pages the last time I looked) - and I just keep adding to it - this would allow me to delete living people immediately rather than adding to the backlog. Thanks for suggesting it.--DataAnalyst 02:40, 18 February 2014 (UTC)

Next step: Review your GEDCOM [19 May 2014]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded test.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 13:27, 19 May 2014 (UTC)

Next step: Review your GEDCOM [19 May 2014]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded test.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 13:47, 19 May 2014 (UTC)

adding info from Wikipedia [13 July 2014]

Janet, Would you have time or interest to add info about Jacob Beeson Jackson, 6th Governor of West Virginia to WeRelate from Wikipedia here http://en.wikipedia.org/wiki/Jacob_B._Jackson? I don't know how to do this. I am creating a page for the cemetery where he is buried as wanted to be able to link to his person page and found he wasn't yet in WeRelate! Not my 'Hempstead' line of Jacksons but I'm interested in getting as much Jackson info on WeRelate as I can. Since this Jacob is already in wikipedia, I expected to find him here but no. --janiejac 18:31, 8 July 2014 (UTC)

Done. I added him and his wife and linked him to his ancestry. I also linked one of his brothers (John Jay Jackson, Jr.) to their parents, and added the Wikipedia template to his page as well. John Jay Jackson, Sr. had 3 other sons (see source West Virginia and Its People, 2:557), one of whom was James Monroe Jackson (who had a grandson also named James Monroe Jackson, according to info on the Jackson Memorial Fountain) - this might be the same person as James Monroe Jackson - I'll leave you to do further research on that, as my brief searching did not confirm this.

Note that I added the Wikipedia template as documented on the source page for Wikipedia - section Including Wikipedia content. This does not immediately copy in the Wikipedia information - an automated job runs periodically to do that, so you'll see the content within a week or so. If you want to do this yourself, please note that the template needs the work wikipedia to be in lower case, although WeRelate will automatically capitalize it as soon as you type the "|", so you have to go back and change the "W" to lower case. This is a quirk I have not bothered reporting to Dallan yet.--DataAnalyst 18:15, 13 July 2014 (UTC)

Thanks!! This line also has DNA information from well documented descendants but the results show the haplogroup is a common one; therefore having matching DNA will NOT confirm a relationship to Stonewall Jackson's line. Because of this, I don't know that it would be of any benefit to add the DNA info. But I'll put a link here just in case anyone is interested. https://www.familytreedna.com/public/Jackson/default.aspx?section=results#StonewallBrigade

Next step: Review your GEDCOM [24 July 2014]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded myhre - 412.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 13:16, 24 July 2014 (UTC)

Next step: Review your GEDCOM [24 July 2014]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded myhre - 412.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 13:31, 24 July 2014 (UTC)

myhre - 412.ged Imported Successfully [24 July 2014]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 01:46, 25 July 2014 (UTC)

link to wikipedia [30 August 2014]

Hi Janet, I've just looked at John Jackson where you have added a link to wikipedia. When I click on the link it does go to his wikipedia page; but isn't it supposed to bring over at least some of the info from wikipedia? I just updated the page from a GEDCOM so I'm wondering did I do something to cause the wikipedia info to not show? You added the link July 13th - I don't know how often the material from wikipedia is brought over. --janiejac 19:08, 30 August 2014 (UTC)

You might have to ask Dallan about this. The link on that page has not been processed by the job that inserts the Wikipedia content. I thought that job ran weekly, but maybe it only processes places, not people. Normally, I only use the template on place pages. Take care.--DataAnalyst 01:33, 31 August 2014 (UTC)

Thanks, I'll ask him. --janiejac 03:51, 31 August 2014 (UTC)

Next step: Review your GEDCOM [5 November 2014]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded bjorndahl - 1623.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 01:30, 6 November 2014 (UTC)

Next step: Review your GEDCOM [6 November 2014]

You're not done yet!

WeRelate is different from most family tree websites. By contributing to WeRelate you are helping to create Pando for genealogy, a free, unified family tree that combines the best information from all contributors.

Now that you have uploaded bjorndahl - 1623.ged, your next step is to review what your pages will look like, review any potential warnings, and combine (merge) people in your GEDCOM with matching people already on WeRelate. You need to review your GEDCOM before it can finish importing. We will keep your GEDCOM in the queue for two weeks to give you time to review it.

Note: if your gedcom contains many errors or multiple families, we’d ask that you resolve and correct the errors, delete this gedcom and re-submit it without the errors before merging it with families already on WeRelate. If the gedcom is very large, we’d suggest breaking it up into separate files (or families) and importing them one at a time, which makes the review and correction process easier.

Click here to review your GEDCOM

Once you have finished your review and marked your GEDCOM Ready to import, one of our administrators will review your GEDCOM and finalize the import. This usually happens within 24 hours. You will receive a message here when the pages have been created.

--WeRelate agent 16:00, 6 November 2014 (UTC)

bjorndahl - 1623.ged Imported Successfully [9 November 2014]

The pages from your GEDCOM have been generated successfully. You may now:

• launch the Family Tree Explorer to navigate your tree
• view your network -- If you matched families in your GEDCOM to existing families, find out to which other WeRelate users you are related.
• view related pages not in your tree -- If you matched families in your GEDCOM to existing families, find out which people you are now related to that you can add to your tree (takes awhile to display for large trees).
• view a searchable list of the pages in your tree -- The searchable list will be available about an hour after your tree has been imported.

For questions or problems, leave a message for Dallan or send an email to dallan@WeRelate.org.

--WeRelate agent 15:22, 9 November 2014 (UTC)