WeRelate talk:Watercooler/Archive 2012

Watchers

Topics


Active discussions taking place at other pages [11 June 2011]



Announcing a new List Pages function [27 January 2012]

We're happy to announce a new List pages function for listing all of the people in your watchlist, including full names, birth dates and places, and death dates and places! It also has a very fast search function so you can quickly navigate to any of the people in your watchlist. Many thanks to Jdfoote1 who has done the coding on this!

Before adding this to the main menu, we'd love to first get feedback here. If you have any comments or suggestions, please feel free to speak up!--Dallan 11:10, 26 December 2011 (EST)


Love it! I note that the Search function does not seem to work for me - but I'm the one blocking known ad and malware sites (but not "addthis"), so maybe that has something to do with it. The only suggestion I would make, and it might not be possible, is if I follow a link on this list and then use "back", it would be nice if the list was positioned at the link I followed. If this is not possible, that's fine - the list would still be very useful. Thanks. --DataAnalyst 11:48, 26 December 2011 (EST)
I notice that the feature I asked for (positioning the list to the link I selected) actually exists in Firefox - just doesn't work for me in IE8. Thanks. Since you asked for feedback, one more request - if I had a filter on and followed a link, and then used the back button, can you automatically put the same filter on again? Would be nice for sort order, too. (Kind of demanding, aren't I?) I can see this list being very useful for review/cleanup. I just used it to clean up some dead links associated with a particular surname. --DataAnalyst 16:45, 27 December 2011 (EST)
Very nicely done. Thank you. (P.S. Using Linux (Ubuntu 11) and Chrome browser) --ceyockey 12:26, 26 December 2011 (EST)
It doesn't run on my Windows 98 system, no surprise probably. Runs on my newer computer, though the initial load took a while, with no progress bar or other indicator that it was working. Was going to ask if data could be sorted, but noticed clicking on the column heading does that - nice! Was going to ask if removing from watchlist could be added, but since it is only Person pages, guess that would be somewhat limited. Thanks. --Jrich 12:42, 26 December 2011 (EST)
Yes! Love it! Even though the search box did not work for me using Windows XP and IE browser. But it's alpha so is easy to find folks. I especially like that all the folks in my many small trees are all together. This type of layout with dates and locations takes less real estate and is much preferred over the normal search results layout. --Janiejac 16:00, 26 December 2011 (EST)
DataAnalyst and Janiejac - are you both using IE? Would you mind checking out the filtering on this page and see if it is also broken? --Jdfoote1 17:03, 26 December 2011 (EST)
For me on Ubuntu, Firefox and Chrome both work with the test page, but Chrome has a crisp snappy feel while Firefox is slower and feels a bit mushy. --ceyockey 17:47, 26 December 2011 (EST)
On slickGrid I searched for Task 55 and got every title that started with '55'. Still using Windows XP and Internet Explorer. --Janiejac 20:30, 26 December 2011 (EST)
I tried searching the list again using Windows XP and Chrome and searched for Jackson, Azor. It took me right to Azor - so the problem is not with XP - it must be with IE. But using Chrome it did find Azor for me though I would prefer that it take me to the place on the list where he is shown alphabetically and not isolated by himself in a separate window. Also when I used the browser back button after searching it did not take me back to the list - it took me to where I was when I clicked on List. --Janiejac 20:45, 26 December 2011 (EST)
Filtering on this page works for me in both IE8 and Firefox. List pages works for me with Firefox but not IE8. Note: In IE8, as soon as I type one character into the search field, there is a message at the bottom saying "Error on page" Note: I am using Windows7. --DataAnalyst 21:57, 26 December 2011 (EST)

Thank you for the feedback! We'd especially like to know if people would prefer having the surname and given name fields split into separate columns, and how much people would want the ability to view watched pages in other namespaces -- families, mysources, etc. What do people think?

Regarding the comments so far:

  • If you press the "back" button, I don't think we can reposition the list to scroll to where your link was, but I'm pretty sure we could re-apply any search text, tree filter, and sort order you had entered.
  • DataAnalyst, I'm able to reproduce the error you're seeing with IE8. I'm out of town this week so I'll investigate more when I return. (Jdfoote1, I'll send you some information in a separate email.)
  • I think we could look into adding a progress bar on initial load. If not, we could add a "Loading" box like gmail has.
  • I'm thinking seriously about having this page replace the "Show and edit complete watchlist" feature of the current Watchlist page. If others like this idea, we can add a "namespace" filter to show different namespaces, and add little trashcan icons at the end of the rows so you can remove pages from your watchlist.
    +1 --ceyockey 13:07, 1 January 2012 (EST)
  • What would people think about adding "Star" icons to the left of the rows so you could flag certain pages, like gmail has?

--Dallan 14:02, 28 December 2011 (EST)


I am just looking at this new feature now, because each time I tried before, it didn't seem to work for me. I think because my watchlist is so large, and there was no indication the page was processing, I thought the result was just an empty box. Once I gave it more time, the list appeared.

One feature that may be helpful down the road is a "customize this view" button like RootsMagic has. Then I could check off the fields that I'd like to appear. This could be helpful for cleanup projects. --Jennifer (JBS66) 14:48, 28 December 2011 (EST)


I'm just now getting to it because I had a fatal crash and ended up having to buy a new post-Christmas laptop -- and reinstalling and copying over everything, and then learning about Win7. Strange new keyboard, too. Whattapain. Anyway. My watchlist is 16,000+ pages and it took about 30 seconds to populate that empty box, during which I couldn't tell that anything was happening. I agree that there needs to be a "Working . . ." notification of some kind while it's doing that.

But, more important, the list presently defaults to "All trees" and I wanted to examine just an individual tree. So I picked one -- but there doesn't seem to be a "Do It" button of any kind. And it didn't change trees automatically. Check-boxes at the left to define a working subset would be nice (it doesn't have to be stars) -- but what sort of tasks do you have in mind for that subset? "Create a new tree from selected pages" perhaps? And you would need a menu or list of tasks, of course.

All in all, though, I like the way the list looks. I think it will be much more useful for actually doing work in than the present "bare" list. I wouldn't object at all if it became the default method of seeing the watchlist. --MikeTalk 10:00, 1 January 2012 (EST)


Couple of comments

  • splitting surname and given name in to separate fields - would be good.
  • Tree inclusion
    • would be useful to include a 'Trees' column to indicate what tree(s) a name appears in; this would be a guide to further filtering
    • could be useful to include in the header a) number of pages on watchlist (which currently appears on the Watchlist page) and b) the count of returned records after a filter is applied (which might be useful for people who have those ginormous watchlists of 10,000+ pages)
    • I did a filter in my list page and the two returned people do not appear in any of my trees, but I couldn't tell that without selecting each tree as a filter and seeing them disappear each time. Would be useful to include a "no tree" or other named option in the dropdown for this filter.

--ceyockey 13:13, 1 January 2012 (EST)


Thank you for all the feedback. And thank you to Jdfoote1 for doing a lot of the work on this! The list pages function is official. I've put it under a new "List" menu item. A few notes:

  • The IE bug has been fixed. I've also upgraded to the latest version of jQuery, which means that the search box in the upper-right corner may no longer work for people running on Windows 98. If you're running Windows 98 or Windows 2000, check out the Opera web browser. I switched from IE6 to Opera on a Windows 2000 computer a couple of months ago and it worked great. If that doesn't work, let me know.
  • You'll notice a new loading indicator.
  • There's a new "Tree(s)" column to let you know what tree(s) your pages are in. Adding this column means that the initial load takes longer than it used to. Let me know if you'd rather go back to the way it was.
  • I'll ask Jdfoote1 about displaying the number of pages and splitting given and surname.
  • Having this page replace the full watchlist page (adding a namespace dropdown and a trashcan icon so you can remove pages from your watchlist) is something I'd like to see long-term, but it probably won't happen right away.
  • I was thinking that allowing people to "star" pages would be a way to flag or bookmark certain pages, as in gmail. Unless there's a lot of interest in this, it also won't happen right away.

--Dallan 11:51, 5 January 2012 (EST)


We've launched the List function publicly now by putting it on the main menu. I think what Jdfoote1 has done is pretty nice. It didn't sound like there was a strong desire for any of the other features mentioned above, so they haven't been implemented. If we're wrong, and people would really like to see some additional features in the list function, please let us know.--Dallan 13:58, 27 January 2012 (EST)


Citation for a web page - difference in how it appears [28 December 2011]

Check out this source page Source:Zubrinsky, Eugene. Carpenter Sketches, which has a title of "http://carpentercousins.com/carplink.htm Carpenter Sketches" with brackets to indicate it is a web page. If you look at the citation on the source page, it shows the title as "Carpenter Sketches" (followed by the very long subtitle). However, if you look at the citation on a page that refers to the this source page, it shows the title as "http://carpentercousins.com/carplink.htm Carpenter Sketches" with the brackets. The latter is rather ugly and I doubt what was intended. Can you fix this so that the citation on a person page looks the same as the citation on the source page? No rush, since this is just a cosmetic issue. Thanks. --DataAnalyst 15:50, 27 December 2011 (EST)

The problem was that the title field included the link and not just the title. Removing the link from the title field fixed the issue. -- Amy (Ajcrow 15:55, 27 December 2011 (EST)
Thanks for your quick response. The problem is, that I'm betting this is not the only source page that does this (even if there are guidelines against it, which I did not check). This particular publication is only available as an web site (as far as I know), so it does not surprise me that someone (not me) put the link in the title rather than just in the list of repositories (where it also is). Since the citation on the source page is correct, I'm thinking there is code that handles this situation - it just isn't being used on the person pages. If this got fixed, then it wouldn't matter if people put links into titles (which is hard to control). Also, the citation on the source page should match the citation on person pages so that users adding/editing sources know what they are getting. (A small thing, but should be addressed at some point.) --DataAnalyst 16:15, 27 December 2011 (EST)
This seems like a good idea -- I've added it as a suggestion on WeRelate:Suggestions

Ancestral File Numbers - to keep or not to keep, that is the question... [5 January 2012]

As I understand it, the system of Ancestral File Numbers (AFN) was a somewhat abortive attempt by LDS to provide a means for merging information for common individuals in different contributed trees. Many person pages on WeRelate still contain AFN values, which I have generally preserved and added as discrete AFN fact items - if I was editing such a page for any reason. I have observed in other cases, that folks have just chucked this info. Can someone advise on whether there is value in preserving these ids? If so, for cases where more than one candidate id is present, should each potential value get its own AFN fact or should we comma delimit a list in a single fact? If not, then maybe Dallan can rehabilitate his LDS fact removal agent to chuck AFN facts en masse? --jrm03063 10:39, 2 January 2012 (EST)

I find them an annoyance. A while back there was a vote to keep them, so I haven't deleted them. The only purpose I can see that they serve is as source documentation. I would think an appropriate cleanup measure would be to add a source for AF and copy the number into the text. Many persons have several AF numbers. --Judy (jlanoux) 12:25, 2 January 2012 (EST)
I was leaving them undisturbed for a while even though they contain no sources to justify their often ridiculous assertions. But lately I have been erasing them as they are often the very source of the egregious errors that I am cleaning up. Good data must be supported by other sources whether or not an AFN is cited, and the citing of an AFN has no evidentiary value, so a page might as well have no sources listed. In general, it is usually possible to find an AFN to support every alternate theory out there, and they should be used as nothing more than ideas when starting one's research, not as justification for statements of fact. Some are clearly based on good underlying sources, since in some cases, they have the right answer to difficult questions. But because they don't communicate those sources, you can't tell the good ones from the mass of absurd ones, without going through the trouble of finding the real sources for yourself. --Jrich 13:04, 2 January 2012 (EST)
I leave them for the very reason that they are often connected to bad data - data so bad that a traditional merge on import might not pick it up. If we keep them, then we know which record(s) the (hopefully) now beautiful WR page is associated with in case people have the original record in their files.-Amelia 13:45, 2 January 2012 (EST)

See similar conversation recently initiated on the talk page of the Ancestral File source page. I think there is some benefit in keeping the numbers - same reason as Amelia mentioned. I'd rather not move them to the source area - I often remove AF as a source (to avoid giving it any credit) and keep only the AFN as a fact. Dallan should advise on formating (one line per AFN or comma-delimited) - depending on how he might do duplicate checks.--DataAnalyst 14:27, 2 January 2012 (EST)


May I propose that:

  • We agree that they be retained as facts (weak ones, but fact items), not sources
  • Someone hip to how AFNs work update the Ancestral File page on the preferred fact form and add links to a few examples that use them? --jrm03063 14:43, 2 January 2012 (EST)

May I propose that:

  • I doubt you really want people matching GEDCOM records to existing pages based on AFNs for two reasons.
  • They are likely to bring along bad data and add it as alternate facts if not overwrite the existing facts. For one thing, if the AFN is really the source of their data, they have not demonstrated particularly good analytical abilities and/or experience.
  • At short notice this may not be the best example, but which page would AFN 4W01-50 be attached to: the Person:Abigail Shaw (14) who married Richard Davenport or the Person:Abigail Shaw (2) who married Stephen Bryant? (Extra credit: check out the parents). It is quite likely that some AFNs will have a mismatch between parents and spouse and on the basis of one should be attached to WeRelate page A, and on the basis of the other, attached to WeRelate page B. How much overlap/disagreement is acceptable when this association of WeRelate page and AFN is made? --Jrich 15:16, 2 January 2012 (EST)
Sure - those are arguments against keeping the AFN or, at least, giving it very little weight. Folks who are vetting inbound GEDCOMs presumably are not accepting masses of content supported only by AFNs. The places where I'm seeing AFNs are GEDCOMs that were loaded years ago and for relatively ancient genealogy. We don't even allow GEDCOMs that reach back into those times at this point. For my purposes, I just want to do the right thing with pages that I'm cleaning up cosmetically without repeating the research. I would also say that, whether we keep AFNs or junk them, the problems that you're alluding to should be clearly spelled out in the usage tips for the source. I strongly encourage you to offer revisions to the source page indicating the issues you describe so that others may be on guard. --jrm03063 16:20, 2 January 2012 (EST)

I see little value in AFN's period. They are usually attached to trees with little credibility and horrendous errors (the one listed above is a good example), and there are duplicative AFN's for many persons in the Ancestral File. I've been deleting them, especially if they obviously contain erroneous information and data on pages I've corrected.... I've also noticed that many Gedcoms with AFN's also have "Personal Reference Numbers", which have no value except to the person uploading the Gedcom..... Perhaps we can find a systematic way to exclude both from new Gedcom uploads?

-Jim:)--Delijim 16:37, 3 January 2012 (EST)


I feel about AFNs the same way I feel about World Family Tree as a source -- that they constitute negatively-reliable sources. When I merge pages, as in a GEDCOM upload (my own, that is), I have generally deleted both these "sources" since whatever source I'm citing has got to be better. And if I'm browsing the database, following links from person to person, and I come upon a Person page where the only sources listed are a dozen or more "WFT" citations -- and there's a lot of those around -- I really, really want to go in and delete them all. And then put a "No Sources Cited" template on the page. Okay, I don't often do it -- but I really want to. AFN and WFT as putative sources are -- seriously -- worse than displaying no source citation at all. --MikeTalk 21:00, 3 January 2012 (EST)


Ok, how about this:

  • The folks who have written so eloquently here on the weakness of the Ancestral File and AFNs should review/revise the Ancestral File source page and make sure that it does a good job explaining reasonable uses as well as the problems. We need that regardless of whether we keep AFNs or junk them, now or in the future.
  • Next, assuming that the AFNs are retained, we get a consensus on what they should look like (bare facts with a fact per AFN, or a list of AFNs on one fact, or a source w/AFN as a page, or whatever). We add that to the source page as well.
  • Finally, when the source page represents the situation and alternatives satisfactorilly, we get guidance from Dallan on how to do a formal election on whether the AFNs are spared for another year or whether they start to get deleted right now (It didn't sound to me like anyone thought these should be kept forever - but I could be wrong...).

--jrm03063 11:29, 4 January 2012 (EST)

How about if we vote on the Ancestral File source talk page: add a +1 to keep (at least for another year) or -1 to start deleting right away followed by your signature. A quick search shows roughly 44,000 people with ancestral file numbers. If we vote to keep them, I'm willing to do a potential-duplicate search based upon same AFN's at some point if there's enough interest in that.--Dallan 11:40, 5 January 2012 (EST)

RootsTech conference [5 January 2012]

Anyone else going to the RootsTech conference? It would be fun to meet in person.--Dallan 12:01, 5 January 2012 (EST)

I'll be there. I have no idea of my schedule, though. (It would be nice if they'd post the program grid. I don't even know when I'm speaking!) -- Amy (Ajcrow) 12:31, 5 January 2012 (EST)

GEDCOM upload/review [26 January 2012]

I've uploaded a GEDCOM for import, asking that it be imported to a tree already in WR. How does the system decide who is the root person on the new import and what difference does it make? The only thing I see is that during the review it tells me how far distant the person is from the root person. But what difference does that make? It isn't even the roots person I would have expected it to be.

The "root" person is the first person in your gedcom file. It used to make a difference in the gedcom review process, but not it's just informational.

And while I'm talking about GEDCM upload, for those interested, I wish you would visit the Suggestion Page and vote for a location button on the GEDCOM review! I think I'll not attempt another upload until that button is in place - and more votes may put it higher on the priority list! Here is my suggestion: When reviewing my GEDCOM for upload, I appreciate the button for "recently created or used sources" being available to click on. Could we also have such a button for locations? I seem to be having to search for the same locations over and over again. I had no idea my locations were so inconsistant, but this upload review has shown me I have a lot of work to do.--Janiejac 14:14, 9 January 2012 (EST)

I have a lot of things like this that I'll do once RootsTech is over.--Dallan 23:22, 26 January 2012 (EST)

Soldiers/Participants vs. Veterans [16 January 2012]

The categories for participants in military conflicts seems to be mostly limited to the term "veteran." Having read a number of talk pages about the structure, I did not find a discussion concerning the term itself. Veterans implies that a person was in the military and was discharged while still alive.

The term "veteran" excludes soldiers who died while in service and inadvertent participants. I give two examples for inadvertent participants (1) The teamsters who were at the Bloody Brook massacres, were not soldiers. However, being among the attacked, they (presumably) fought and they died in that battle. (2) A father [for the life of me I cant find the person's name] went to visit his sons at the Battle of Bennington, took up arms and was killed by a Tory soldier (militiaman).

Question is.. are we trying to categorize participants, soldiers, or veterans?

It doesn't seem efficient to have separate categories within a conflict for each type of combatant. Inadvertent participants would likely be a small number and may not require categorization. However, there are many soldiers, who never became veterans.

Question - Can/should the name within the categories be changed? Perhaps to read, "War of 1812 Soldier", World War I Soldier, King Philips War soldier. And then there are veterans (and non-veterans) with military service during peacetime.--Kpb2011 09:03, 14 January 2012 (EST)

By the same token, the word "soldier" implies those who fought with an army and excludes those who fought in the navy. The categories are intended to include all military participants, regardless of whether they survived the war. While "veteran" might technically apply only to those who fought and were later discharged, making such a distinction would only serve to make the categories more fractured and, thus, less meaningful. Also, the term "veteran" denotes military participation, while "participant" could include civilians, such as sutlers. We could add a note on the categories that include the word "veteran," but I don't think that changing the term itself would be beneficial. -- Amy (Ajcrow) 09:28, 14 January 2012 (EST)

If I understood correctly, the purpose for the categories is to identify those who have a military service record. That is, they enlisted or were conscripted/impressed or were somehow recognized as being part of a military unit by some governmental authority. Casual or inadvertent participants would generally be excluded (like the residents of Gettysburg were participants in the battle to some degree, but it was not military participation). It is governmental acknowledgement of a military record that is intended; the fact that the DAR, SAR, or some other membership organization recognizes participation is too broad (because they recognize committee of safety, etc.). The membership organizations would need to recognize military service in some military unit.
I am not trying to split hairs (promise!) whether the father is categorized as a Vermont Revolutionary War veteran is not as important as understanding what this site intends the categories to be used for. In the case of the father at the Battle of Bennington, he could be a "veteran" if his widow was granted a pension or he is listed as being part of a unit during the battle, not just a walk-on. With regard to the teamster at Bloody Brook, they are not "veterans," even though they were the whole purpose of the military escort, none appear to have been credited with service under Capt. Lathrop by the colonial government.--Kpb2011 10:26, 14 January 2012 (EST)
Since the military service categories are organized by name of unit, I have assumed the subject would have to be a listed member of a military unit under some higher authority. Whether that means federal or state troops, regular army or militia, is not relevant. (I haven't had to deal with service in anyone's navy, so I'm ignoring that. . . .) I've been adding people who served in militia units raised during the Texas Revolution, so it's not all "U.S." or "C.S.A.", either. I think the issue of "peacetime" service is pretty minor, since we don't include living persons and nearly all the Regular Army in the late 18th & all of the 19th century may be regarded as participants in the various Indian wars (and that's how the NARA service records for that period are classified). That leaves only deceased members of the Regular Army between 1918 and 1942 (who did not later participate in WWII) -- and they will still be found listed in organized units, which could be the basis of a "Peacetime" category, if you think that's necessary.
Incidentally, I have several people in my notes who were listed members of 17th-century Train Bands in Massachusetts & Connecticut; would you include them in the categorization system if they didn't take part in a specific war? I also have a couple of people in the expedition against Fourt Louisburg; what war would you consider that to be part of, for our purposes? --MikeTalk 21:08, 14 January 2012 (EST)

Am currently working on a list of Colonial War veterans now. I have begun categories see Category:American Colonial War veterans. That will cover a long time line 1609-1763. The 1745 Louisburg Expedition is Category:King George War veteran (1744-1748)
There are a few wars not yet added (Cherokee, Pequod, perhaps others).
As I understand it, American Rev War is organized by Continental Army and State Militas. The Overall structure begins here Category:Veterans--Kpb2011 21:25, 14 January 2012 (EST) Added: At the moment, I have not organized the Colonial units. King Phillips War had a relatively small number of participants, although there are records that would break them down in to units, but not sure that is needed.
The thing is, most of the participants in King Philip's War are well documented, mostly because of all the folks who want to qualify for Order of Colonial Wars and also Founders and Patriots, so they're easy to identify & prove (and therefore categorize) --MikeTalk 08:56, 16 January 2012 (EST).
Are you suggesting then, that for Colonial veterans, the categories get broken down from the state level to a subordinate level? Example, Capt. Lathrop's troop and Moseley's troop, should they have their own category under the King Philips War category? The war category gives the context, would that additional detail in a category name confuse rather than enhance? Would it read something link "Category: Massachusetts Colonial War Veteran Capt. Lathrop Troop (King Philips War 1675-1676)" or "Category: Colonial War Veteran Capt. Lathrop Troop (King Phillips War 1675-1676)". For the average user, inclusion of the dates seems important, since many are not likely to know which war occurred when nor able to differentiate Queen Anne's War from King George's. Frankly, I have to look up the dates to match service to appropriate conflict. Seeing "Queen Anne's War" gives me some context, whereas, "Queen Anne's War 1702-1713" provides me with much more. What I am saying is that because these conflicts happened so very long ago, the category names need to be meaningful without becoming overly long, nor require a level of knowledge beyond that of most users to actually assign a category.
The King George War (1744-1748 in the Colonies) was part of the European War of the Austrian Succession. There the numbers get larger and there are records where they could be broken down into regiments. However, I am not sure that that level of detail is needed. Most people do not know that history and would find naming the regiments, like Col. Samuel Moore's regiment not meaningful. Other ideas are welcome.
I'm very familiar with the Austrian Succession. The colonial action was indeed just a sideshow, in the same way that what Americans call the French and Indian War was really just a small part of the Seven Years' War. Still, I think those conflicts in the American colonial period that traditionally have been separated out from what one might call the continual "background" warfare that went on all the time could reasonably each have their own categories.
I definitely agree that the named Colonial Wars should have their own category and I suggest defining those as pre-1775. The later conflicts could be handled as you propose. Although, I have not given them much thought, as my ancestors were not generally known to have been involved in them.

OTOH, for the 19th century, because there were several Cherokee wars, ditto wars with the Creeks, Seminoles, etc, and because they were fought by a mix of regular U.S. Army troops and state militias -- and because the same men often took part in several of them -- I'm not sure it's useful to try to separate those out. I would just lump them together as "Indian Wars." Otherwise, you can slice this whole thing unnecessarily fine. As I noted before, that's also how NARA deals with the records, and it's how the later official campaign medals were categorized. The Library of Congress, being a government agency, followed this same breakdown in assigning subject headings (though they're more detailed), so you will also find there a good, ready-made list of U.S. military conflicts. --MikeTalk 08:56, 16 January 2012 (EST)


New place matcher [12 February 2012]

I've been working on a new place matcher. It hasn't been installed yet (that will have to wait until after RootsTech), but as far as I can tell it does a much better job at matching places in gedcoms than our current place matcher. Feel free to check it out and leave feedback.

You can help improve the new matcher by following the link and clicking on Choose the best match. This will present you with one of several thousand ambiguous place texts that have been found in GEDCOMs over the years. Please click on the best match. This will provide examples to use for improving the matcher, so that it picks the best match when place texts are ambiguous.

I took a look at this. No one can choose the "best" match when the input is ambiguous. This is the problem we have with the current matching. If the intent is not clear then there should be no match created and a red link left. Grabbing any old arbitrary match is introducing errors which are hidden because the original input is displayed and not the match.--Judy (jlanoux) 12:07, 29 January 2012 (EST)
In that case, please select the I can't tell which place this should be button. That will help me know when places are truly ambiguous, and when I shouldn't match to a specific place. Working through places on the "Choose the best match" link, and either selecting one of the places listed when the best match is apparent, or selecting I can't tell which place this should be when the place is not apparent, is the best way for you to help improve the place matcher that we'll be using. As you might imagine, it's difficult for a computer to tell which place an ambiguous text should match. Take "Virginia" for example: is this the state, or the city of Virginia in Minnesota? What happens when a text matches both a city and a township? We don't want to leave all ambiguous place texts red-linked; that would leave a lot of obvious matches red-linked. We need to teach the computer when a text is truly ambiguous and when the correct match is apparent. That's what using the "Choose the best match" link will do -- it will give me data that I can use to teach our upcoming place-matcher how to do its job better.--Dallan 11:27, 31 January 2012 (EST)

Like the name variants database, the places database is also being made freely available to other websites.--Dallan 14:46, 27 January 2012 (EST)

  • Wondering whether you considered using the OpenStreetMap Nominatim place names resource, likely enriching that resource with content from WeRelate? --ceyockey 18:29, 27 January 2012 (EST)
I've looked at OpenStreetMap in the past and I'd love to integrate their content. I know from past experience in integrating Wikipedia, the Getty Thesaurus of Geographic Names, and the Family History Library Catalog place database, that integrating a new source without creating a bunch of duplicates is a big job. I'm hoping that by making the database available to others, we'll get people interested in volunteering to improve it. I was thinking initially that this would happen by making hand-edits to the Place pages at WeRelate, but if someone wanted to integrate a new data source (integrating a database of all US Townships would also be really helpful), I'd love to help them. I could write a robot to add the new places to WeRelate or to update existing Place pages with additional information for example.--Dallan 11:27, 29 January 2012 (EST)
You might take a look at how ShareMap.org has implemented place lookup. Their Search results are broken into three sections: Wikiepdia (GeoNames), Places (GeoNames) and Nominatim (MapQuest). It appears from recent work I've done with ShareMaps that the address resolution data from MapQuest has been integrated in some way with the OpenStreetMap Nominatim solution. It might be worth a contact with the Sharemap folk to see how they are handling the draws and updates to power this search. On the broader topic of Places, I am of the opinion that any place which is contributed to WeRelate through a person surveying that place (such as a cemetery) should be reflected in OpenStreetMap such that the "division of labor" is geoinformatics in OSM and genealogical use in WeRelate. There are a number of solutions out there which provide specialized maps based on the OSM layers and which provide a feedback mechanism to contribute content to OSM; the ones which I have used most OpenLinkMap and OpenStreetBrowser. --ceyockey 23:42, 30 January 2012 (EST)
Thanks for the pointers. I'll contact ShareMap.org and OpenStreetMap to see about passing data back and forth.--Dallan 11:27, 31 January 2012 (EST)

It's cool to see you using GitHub for these projects. I'm betting that you'll get a lot more organic engagement than the previous model of having to ask for the sources.

Have you thought at all about how updates get managed if you're successful and Places/Names are adopted by others? Ideally there'd be some type of federated update system to not only push out WeRelate updates, but also receive updates from other sites which are also working on improving the data.--Tfmorris 18:22, 28 January 2012 (EST)

I haven't thought a lot about this. I think it depends upon who gets involved. We have a number of options:
  • We could ask people to update WeRelate directly as the "master" database. That's more or less what Wikipedia does when people use copies of their data.
  • I could write an API that other websites could use to push their changes to WeRelate and receive changes from WeRelate.
  • If an organization like FamilySearch wanted to be the "master" database for names, and maybe also for places, and would commit their resources to improving them, I'd be open to that, so long as they reciprocated with an API that would allow us to push and pull changes.
--Dallan 11:27, 29 January 2012 (EST)

How minor is minor? [29 January 2012]

When editing a page I've been filling in the window to say what changes I made even though I considered the edit to be a minor one. Then I found that such notes aren't listed on the Contribution list but only "Propagate changes to ..." Do watchers get notice of minor changes? Fortunately, on most of my pages, I'm the only watcher, but what if there were watchers and all I did was add a source for their unsourced date . . . or add a date where they had no date? Are these minor edits and would a watcher be notified? --Janiejac 15:43, 28 January 2012 (EST)

"Propagate changes to" are actually changes coming as a result of a change on another page (the preposition seems backwards to me). I believe they are always marked minor by the system.
They are.--Dallan 11:27, 29 January 2012 (EST)
When I am editing I tend to mark minor anything that doesn't change a date or add a spouse, most especially just adding a source that doesn't change the data that is there. There is a big gray area in between however, where it depends on whether I think somebody descended from this person will care. So if I fix the spelling of the town name, no, but if I move them to a different town, maybe if I think it is significant. If I add double dating to a date that had none, no, but if I change double dating that was already there, yes. Checking the watchlist shows both kinds of changes, and email notification can be configured to only be major changes, or both, so I figure it's better to err on the side of minor when in doubt. If people want minor changes, it easy enough to get them. There doesn't seem to be any uniformity to this, though, as it seems that some people mark everything major. --Jrich 16:40, 28 January 2012 (EST)
Here's the Wikipedia definition [1]. It's consistent with Jrich's practice.
What's most important is to use the summary field - then users can tell whether they need to click on the link. Which is actually one way to decide if you should click minor (as explained in the WP article) - if no one is going to care or dispute the edit, mark minor. Specific to WR maintenance work, please hit minor if you are making the same change over and over again, like adding categories or templates. --Amelia 22:42, 29 January 2012 (EST)

Help editing text in Wiki. Method for creating a tabular column [31 January 2012]

See Person:Thomas Coker (13). Below the 1840 census data is an account of the sale of inventory. I would like the dollar sale amounts to line up in a column but I don't wish to have a table with headings and don't need a table. The only way I have figured out for it to work is to use the pre tag but that is not allowed. Help. --Beth 12:42, 29 January 2012 (EST)

You could use <code> to set off this section instead of bullets. Then your formatting would be preserved.--Judy (jlanoux) 12:52, 29 January 2012 (EST)
I suspect wiki tables have a lot of functionality I don't know about, and may be able to have a borderless table with no special formatting of the first line, but certainly suspect you can do something like this using HTML tables. My experience suggests it is a good idea to exactly pair up tags with their closing tags, even say <TD> and </TD> tags, which HTML doesn't seem to require. --Jrich 12:59, 29 January 2012 (EST)
Thanks so much to both of you. I seem to have it working. I had to add a break tag and the test defaults to a monospaced font within the tag. What do y'all think? Haven't finished yet. The image is now on FamilySearch; that is fantastic.--Beth 15:23, 29 January 2012 (EST)
Actually, XHTML, the current standard, is less lenient than old-fashioned HTML and does require opening and closing tag-pairs, even for paragraphs (using <p> </p>) and breaks (where the syntax is now <br />, a sort of "portmanteau" tag), so I would recommend always using them. As Judy says, using the <code> </code> pair will maintain formatting. But the wiki handles text differently in the text box attached to a source (where formatting will be retained, apparently, no matter what you type in there) than in the big box labeled "Personal History" (where text behaves in typical wiki fashion if no tags are included to force formatting). In the source-connected text box, for instance, I've been just typing up (or copy-pasting) census listings in Wordpad (to ensure plain text), tidying them up, and then copying them as-is to the WR page with no tags at all. Works fine. I would think that would work with your inventory sale, too, provided it didn't have too many columns to display horizontally on the page. --MikeTalk 15:35, 29 January 2012 (EST)
I removed the Template:DNA reference which had been put on the page because it screws up the formatting of the text. It isn't a complete template, and not needed when you don't have any DNA. -Moverton 12:44, 31 January 2012 (EST)

Question about Savage [3 February 2012]

I'm thinking about some work with this source, and am considering the full text versions (such as this) as a starting point. Does anyone know if this version (other than the OCR defects) was the definitive published version? Thanks... --jrm03063 11:13, 3 February 2012 (EST)


Deleting page that does not exist [7 February 2012]

How may I delete this page, [2]? There was a page created for this family, see Family:Thomas Finley and Zeporiah McGee (1). --Beth 10:16, 7 February 2012 (EST)

Since the page never existed, there is nothing to delete. Are you seeing a reference to this page somewhere? --Jennifer (JBS66) 10:20, 7 February 2012 (EST)
Non WeRelate user emailed me the link to the empty page. I have no idea how she found it. I did not find it using the search engine. --Beth 10:55, 7 February 2012 (EST)
I have noticed times when emailing WR links, the automatically generated URL in the email will drop the index number, so if you click on it, you will be directed to the wrong WR page. The person who emailed you may have also omitted the index number themselves. --Jennifer (JBS66) 10:59, 7 February 2012 (EST)
Okay, thanks. I checked the email and the index number was dropped. --Beth 11:07, 7 February 2012 (EST)

probability vs certainty [8 February 2012]

Reviewing a GEDCOM upload - when I have a birth location of 'prob Oyster Bay' the system links this to Oyster Bay. I unlink it and leave it a red location because I don't want to leave off the probability - it is not a documented location; just my conclusion. It is similar to having 'abt' in front of a date which the system does handle. Isn't there some way to accommodate for the probable location? --Janiejac 16:41, 7 February 2012 (EST)

I just go ahead and link it, then add something like "probable place" in the description (eg. here). -Moverton 17:55, 7 February 2012 (EST)
Yes, but...when I have just uploaded a large GEDCOM with the probabilities removed, and I go to check out the pages, I'm not going to remember which ones were probabilities. At least if I leave them red, I'll have something visual to remind me to 'fix it'. I may not make it back to check all the pages anyway and think it safer to leave it red. That doesn't look good, but at least folks will understand that it is not a sure thing. I was just hoping for an future fix so the system would keep the 'prob' and I wouldn't have to go back to fix each one. --Janiejac 21:08, 7 February 2012 (EST)
I think it does what you want... if you match "prob Oyster" to Oyster Bay, the resulting page should have "Oyster Bay|prob Oyster" in the place field and display as "prob Oyster." At least I'm pretty sure that's what happened to non-standard places in my last upload.--Amelia 22:53, 8 February 2012 (EST)

Saving access to the SSDI [17 February 2012]

Recently, the Social Security Death Index (SSDI) has come under fire as being something that can be used by identity thieves. A handful of cases have been found where the Social Security number of a recently deceased person was used to fraudulently claim that person as a dependent on a federal tax return. Four U.S. Senators contacted Ancestry.com about removing the SSDI; Ancestry removed it from RootsWeb, although it is still available to Ancestry.com subscribers behind the pay wall. Legislation has recently been introduced that would effectively close the SSDI to the public.

Rather than being a source for identity thieves, the SSDI is actually a source to combat identity theft. If the IRS had checked the fraudulent tax returns against the SSDI, they would have discovered that the Social Security number that was given actually belonged to a dead person.

A Senate subcommittee held a hearing last Thursday (February 2) about the SSDI. Genealogists were specifically barred from providing testimony. Genealogists are being made to be the scapegoat.

The Records Preservation and Access Committee (RPAC) -- a joint committee of the Federation of Genealogical Societies, the National Genealogical Society, and a number of other organizations -- has started a campaign: "Stop ID Theft NOW!" Rather than making genealogists out to be the bad guy, this campaign shows that genealogists do care about the issue of identity theft. This campaign calls for the SSDI to be used for its intended purpose: to show that someone is deceased.

If the SSDI is closed to the public, identity theft will actually increase, as the general public and small businesses (who can't afford access to high-priced data services) will not be able to verify whether or not a Social Security number being presented actually belongs to someone who is deceased.

You can help! RPAC has started a White House petition. We need 25,000 signatures before March 8, 2012 for this petition to be reviewed by the administration. You need to register for a WhiteHouse.gov account (free). It takes just a couple of minutes to create the account and then click the link to "SIgn Petition."

For more information:

If you care about records access, please become involved. If these records close and we do nothing, we have only ourselves to blame.

--Amy (Ajcrow)--Ajcrow 09:46, 8 February 2012 (EST)

Thank you. I signed. I also referred folks to the petition on LinkedIn, the Group "Genealogy...Beyond the brick walls!" ... where, by the way, WeRelate appears to be unknown (based on responses to an inquiry I made). --ceyockey 19:55, 8 February 2012 (EST)
Thanks for the heads up. But unfortunately, in the eyes of many, genealogists are to privacy concerns, identity theft and public records access as the NRA is to the new interpretation of the 2nd ammendment, gun control, and the right to bear arms. Probably another losing cause as all our rights are dimminished. --BobC 23:48, 8 February 2012 (EST)
Bob -- that's exactly why the campaign is centered around "Stop Identity Theft NOW," rather than "Save the SSDI." We're showing that we do care about identity theft and that one way to do that is for the IRS to use this fabulous tool that would show them that a Social Security number belongs to a deceased person. RPAC has posted a FAQ page that covers this very issue. If we wring our hands and say this isn't going to work, then we've already lost. -- Amy (Ajcrow) 07:37, 9 February 2012 (EST)
Amy, you're singing to the choir. I was part of the unsuccessful letter-writing campaign some years ago when Social Security announced they were raising the fee for copies of the original application forms from $9.00 (or whatever it was at the time) to $27.00. I like the approach better this time and will join the effort and will encourage others to do so too, but my crystal ball says we're blowing sand in the wind. I think the decision has already been made and they are just going through the typical ritual misguided legislative and bureaucratic process. Common sense, professional analysis, and fact-based reality have little to do with the laws our legislators enact and the regulations our public administrators force down our throats. --BobC 10:50, 9 February 2012 (EST)
It is always disappointing when people point to a few bad apples then ask the government to destroy the entire crop! -Moverton 19:29, 17 February 2012 (EST)

Templates for transcribing standardized source documents? [9 March 2012]

Hi,

I've been playing around with Template:Scotland. Statutory Marriage Record as a means to transcribe information from Scottish records. I'm sure others have done similar things, but I haven't been able to find other templates or methods for this. Does anyone know anything about this sort of thing? I'm imagining it'd apply to all BMD certificates, and maybe indexes as well...

My basic idea is to set up a MySouce for a certificate and include all information from the certificate in it, as well as the image of the original. Probably not an original idea!  :-) I'm also wondering about developing a standard categorisation system for these transcriptions. Good idea?

Sam Wilson ( TalkContribs ) … 20:30, 26 February 2012 (EST)

I've done a handful of relatively specific transcriptions that are presented on MySource pages:
* MySource:WeRelate/Obituary of William Montagu, 5th Duke of Manchester
* MySource:Jrm03063/Dennett, Helen Marion. Last Will and Testament
* MySource:WeRelate/Dame. Family Bible Entries
* MySource:WeRelate/Tuttle, Joseph S. Family Bible Entries
* MySource:Jrm03063/Mason, James R. Interview with James C Mason
I think WeRelate has so far taken the view that needed semantic properties for the page will tend to be explicit parts of the page type. Perhaps that's not realistic, but it's what I've seen playing out thus far. Still, I think your idea has a lot of promise. If every mysource page, representing a marriage record/certificate, has a template that identifies it as a marriage certificate - that's information we aren't currently recording in a way that can easily be extracted. Likewise other common certificates - birth and death. Knowing all the mysource records of one type or the other could be handy.
I'm not sure it makes sense to put in the template EVERYTHING that might come from the original. Rather, put in the stuff where you want to designate useful semantics that are not otherwise available. For example, it would be an odd marriage record that didn't indicate date, place, both parties and their parents, but all that can be inferred from a single reference to the Family page associated with the marriage. There may be a few nuggets of interest not easy to get otherwise - witnesses, person officiating, religion. Birth and death certificates might only need a template marking them as a birth or death certificate - along with a pointer to the name of the person. From the person page itself, you'll get the date of birth or death and municipality - so again, no need to create redundant information. Hospitals are generally not places, so that might be useful to add. Birth certificates may indicate which birth this is for the mother, and whether it is a multiple birth, which could be helpful.
Also, don't worry about the case of resolving multiple conflicting documents - since you can represent alternate dates and places for birth, marriage and death - and just check which source supports which fact to get the facts associated with a particular source.
Hmmm - it's interesting. Perhaps smaller templates that serve mostly to mark the type of document and a few key additional facts? --jrm03063 22:30, 26 February 2012 (EST)
One more thing (it was late when I gave the answer above, so I missed some obvious things). At present, the common way to handle a birth, death or marriage certificate is simply as an image. You'll notice that images are allowed to act as supporting evidence for a fact on Person and Family pages. I have a number of such examples:
Still, the essence of your insight remains valid. There's no fundamental way for a program to come along and know that the images above are documents - let alone a death certificate - and that the image below is a portrait.
A template/semantic block (I'm afraid I'm not a really wiki terminology/formatting expert - please forgive me) that allows you to assert that an image is a particular type of document, and that a particular WeRelate Person page is the subject - WOULD INDEED be a useful item. I suppose you could infer some things by looking at what pages include the image, and what facts are supported by the image - but that seems just too flimsy for practical purposes. --jrm03063 10:56, 27 February 2012 (EST)
Yes, I'm not sure how much detail to transcribe. I'll keep playing with it and see what I can do. My initial motivation is just to be able to see what GRO certificates people have already uploaded here, in case any are of use to my research. (And of course a bit of a compulsion to aim for some weird idea of completion!) I'd also like to include in the MySource page the info from the BDM indices.
One thing I'm wondering, in my prototyping, is the etiquette for modifying other people's MySource pages? I mean, I'd like to create pages for certificates already uploaded, but they don't belong under Source:, nor really under MySource:Samwilson/ ... although, it doesn't really matter and I'll just stick em in the latter for now...
I agree with your concern. There's a decree that Wills, for example, are a MySource, but if the will is being transcribed or copied from a book - it's not really proper to say that I have special possession of the source. While some people don't like it - I rename such pages to "MySource:WeRelate/xxxxxxx" --jrm03063 14:08, 7 March 2012 (EST)
The only missing link I've found is that of a MyPlace sort of page, for individual streets etc. -- I think categories, automatically populated via the transcription templates, could serve. (Oh, now I'm just brainstormign... ignore me, till I get something actually done!) — Sam Wilson ( TalkContribs ) … 02:33, 28 February 2012 (EST)

I think it's a good idea to do proper transcriptions of all the documents we rely on, and many (notably birth, marriage and death certificates and census returns) are pretty standard. Where those documents are originally in table format, I think it is best to transcribe them as a table so that our transcription matches the format of the original. See, for example, the marriage certificate transcription on this family page: Family:William Harry and Jane Drake (1), or the baptism, censuses and death certificate on this person page: Person:Margaret Rice (13). If templates are to be created, we do need to bear in mind that the questions asked and column headings did occasionally change - Scottish birth certificates being a good example. When they first started in 1855 they asked for loads of (very useful) genealogical information - but quickly realised the system too cumbersome and costly, so from 1856 scaled back the questions, only to then reintroduce some of them in the 1860s. I've been doing mine as tables in the source fields on the person or family pages rather than MySources, as it keeps them all on the same page and it's often useful to see multiple sources alongside each other.--RichardK 15:44, 28 February 2012 (EST)


Topic: Templates for transcribing standardized source documents?

I would be interested in knowing how you went about constructing the tables for source citations for Person:Margaret Rice.

They certainly stand out a lot better than the lists of phrases I have been entering today. (Tree:HWLyle, Person:Elizabeth Atkinson).

Censuses from Kirkcudbrightshire are yet to be added to my trees, but I know their form. --goldenoldie 17:00, 7 March 2012 (EST)

I'm not sure which method the contributor of the page data used to do it, but I've found that putting the data in an Excel spreadsheet first and then using an Excel-to-Wiki Converter is an excellent way to accomplish it and doesn't require an extensive learning curve to achieve very acceptable results. If you use it, let me know if it makes your work easier. (BTW, thanks to WeRelate User Jlanoux for finding it.) --BobC 19:26, 7 March 2012 (EST)

I've been creating my tables in Excel, to which I've added formulae which partially convert the tables into the necessary formatting, but then there's still an element of manually adding the wiki-table formatting. Hence it's a bit cumbersome and if someone can come up with a nice simple way of doing it, that would be handy. I go through waves - sometimes I put in the effort to do the tables because they are clearer to read, sometimes I don't put in the tables because they're too time-consuming (for example my William May - not that dissimilar from your Elizabeth Atkinson, goldenoldie). Of course, tables don't always work - on my Margaret Rice page I didn't do the 1911 census in a table format because it would be too wide to display sensibly on your average computer - particularly as many of the columns had massively wordy column headings but had been left blank below.--RichardK 16:44, 8 March 2012 (EST)


I've started collecting transcription templates together in a category. My current idea is to be able to use these on Transcription: namespace pages, which can then be transcluded wherever (e.g. in the body of a MySource citation). — Sam Wilson ( TalkContribs ) … 22:31, 8 March 2012 (EST)


Redundancy, Wikipedia, and External links [27 May 2012]

I have a question on redundancy. I'm a newbie here and I have been trying to figure out how to handle this. I don't think there is a single right answer, but I was wondering what other folk's thoughts were on this.

Situation:

I have a 1906 copy of Source:Kenaga, William F. Historical Encyclopedia of Illinois and History of Kankakee County. Searchable pdf files for this book is available at the Family History Archives. The first part of volume 2 is history and information on Kankakee county. The second part is biographies. I originally set up a template page for the source so I could post the transcripts of a few biographies associated with my people and wikify them. These biographies are very Pando, what with migration patterns and local families intermarrying and all. At first I was only thinking of linking from transcripts to person pages. Then I figured I might also link to place pages and other pages, such as articles on military units. My question of redundancy starts when I wonder if I should always try to link to WeRelate pages or if I should link to Wikipedia pages. I've noticed in biographies on person pages that there are sometimes external links, frequently to Wikipedia. They are for events or things which involved the person, but for which there is no WeRelate page.

I see editing Wikipedia on general things and including genealogy related Wikipedia sections, such as history on WeRelate as a way to reduce redundancy, but once a place page gets an active WeRelate user editing the WeRelate page, the Wikipedia page does not get edited. WeRelate has some excellent military pages where the corresponding Wikipedia page is a skimpy boiler-plated article.

My solution would be very obvious - link from the transcripts to WeRelate pages when one exists, or ought to exist, and link to Wikipedia pages for other important topics. If people choose to edit WeRelate pages over Wikipedia pages, well, at least the information is getting put out there somewhere, and WeRelate is a friendly comfortable place to put information -- the more the better. However now I have another dimension to consider. Kankakee has a local wiki and it would be nice if at least Part I of this book was on that wiki to be wikified. At first, two transcriptions of the same book to be wikified sounded really, really ugly, but then I figured even if a full copy of the book existed on each site, it really would not be completely redundant and might be the best solution. Two sites, two different purposes. Persons and places and other articles on WeRelate could have an external link to the corresponding KanWiki pages, if any get created and sufficiently developed, just like an external link would be made to any other web page of significant interest.

This whole situation made contemplate the problem of redundancy. What goes here on WeRelate? What goes on Wikipedia? How much linking to external sites should there be? What about linking to the FamilySearch Research Wiki, Ancestory's wiki which Ancestory has populated with the Red Book and The Source, and also other research and information web sites? Is linking to Wikipedia preferred over other similar pages?

I am very new here, but I have been looking over the Help pages, the Support pages, the Watercooler, and various pages used as examples or which have been fixed. Just wondering here about other people's opinions on redundancy, Wikipedia, and external links. --LeeHollenbeck 00:10, 28 February 2012 (EST)

All good questions; I've been trying to figure them out also, lately. My approach is basically this:
  • Every person and place gets a page on WeRelate;
  • Where possible, these include the {{source-wikipedia}} template so that their info is brought in weekly from Wikipedia;
  • Sources such as books and other documents go on Wikisource and are linked to from Source pages here;
  • Other sources such as BDM certificates, which wouldn't be accepted on Wikisource, are transcribed here (and I'm working on some templates to help with this).
I favour WMF wikis over others, and then open content licenced wikis (such as WeRelate, OpenStreetMap, etc.), and then the Internet Archive, and then my own person web spaces. Under no circumstances do I think it worthwhile contributing to closed-access or closed-licenced websites. Ancestry give us nothing for free, so I'm not going to help them build a walled-garden of genealogical data! ;-)Sam Wilson ( TalkContribs ) … 02:17, 28 February 2012 (EST)
I'm pleased to see folks concerned about using Wikipedia and Werelate to their mutual best advantage. There's truthfully no way to enforce good practice in this regard, but we have a Help Page that outlines a relatively shared sense of what we consider to be good practice (and some of the nuts and bolts of doing so). Beyond that, I've been working a personal wikipedia inclusion project for the last several years. My practices described there take something from the help page and include a fair bit of my own heresy. At present, there are over 19,000 person pages that are associated (in a programatically recognizable way) with backing Wikipedia biographies. I'm hoping to find ways that WP and WeRelate can be mutually supporting, but I'm afraid I'm a bit of a dreamer... --jrm03063 09:39, 28 February 2012 (EST)
I had not thought of WikiSource. That is an idea -- something connected to their Illinois portal like the McLean County History. Maybe I'll keep doing the biographies here, they are like garland on the Pando tree, and Part I could go on WikiSource or KanWiki.
I also had not thought to check if the had a talk page. Lots of discussion there. I'll have to look more at the personal wikipedia inclusion project. So far, my MyRelate person pages have no Wikipedia pages.
I'm very pleased to have come across such a positive approach to cross-wiki collaboration (as a contributor to both Wikipedia and Werelate). Can I also add the FreeBMD family of resources as something people should consider contributing to and linking in: http://www.freebmd.org.uk/ and also, to a lesser extent as they are not free copyright but are charitable, http://www.genuki.org.uk AndrewRT 17:30, 19 May 2012 (EDT)

I would also recommend the FreeBMD family of resources (http://www.freebmd.org.uk/) and http://www.genuki.org.uk as very useful resources for British research. British family history organizations have more paid-website competitors than just Ancestry and, for this reason, have had to bind their own information with copyright.--goldenoldie 03:58, 27 May 2012 (EDT)


The weekly contest [1 June 2012]

The weekly contest notice on the home page says a new contest starts at noon each Friday. But it doesn't say what time zone the presenter is using. --goldenoldie 10:51, 2 March 2012 (EST) The time zone and rules are on the contest page. Contest begins Friday at Noon Pacific Standard (Seattle) Time. Sorry I am just getting to this - I've been on a family medical leave from genealogy. --cthrnvl 15:12, 1 June 2012 (EDT)


WeRelate now has a Transcript of Savage's Dictionary [17 May 2012]

Through the courtesy of Dr. Robert Kraft, we now have a transcript of the Genealogical Dictionary of the First Settlers of New England.

Users are encouraged to edit individual pages of the transcript to add links to corresponding Person pages (while leaving the narrative content as is). For example, volume 1, page 16 refers to Thomas Adams and his family. In addition, a template has been created that allows a page specification to also serve as a link to the corresponding page of the transcript, for example, {{savagepg|1|16}} -> 1:16.

The origin and creation process for the transcript is described in detail on the associated about page. The existing Source page for Savage has also been updated to reflect hints and tips appropriate to use of the transcript.

--jrm03063 19:18, 4 March 2012 (EST)


cool. Playing with this might be actually draw me back to WR.... Jillaine 21:03, 17 May 2012 (EDT)

Wondering about unknown vs. blank [26 March 2012]

In searching, I believe Unknown is treated as the literal name 'Unknown' (since doing a search for a name with Unknown brings back pages of Unknowns at the top of the list). Which means Unknown name fields should be left blank, which will be treated as unspecified by the search engine and so match anything. Is that correct?

Aesthetically I like having Unknown in the field (especially when it is the first name), and have seen others adding it so gather others do too, but as it may mess up searching, this probably shouldn't be done?

Unless search could be changed to treat Unknown as a wild card? Of course, this should probably be done in both the target (i.e., John Unknown finds John Doe or John Smith or John Unknown equally well) or in the result search potential (searching for John Doe would score John Doe higher than John Unknown which is higher than John Smith)? --Jrich 17:18, 22 March 2012 (EDT)

But what if you really did want to search for a John whose surname was not known? (Perhaps because you previously created the page and were trying to find it to make updates.) Then not having Unknown as a wild card would be preferred. Maybe there should just be a message notifying people that they should leave it blank instead of using Unknown when they really don't know it. -Moverton 15:17, 23 March 2012 (EDT)
If you made the edits recently, searching your Watchlist or Contributions would probably be nearly as effective. If you made the edits some time ago, then there's no guarantees the name hasn't been changed from Unknown by somebody else, so it seems like you would want the wildcard anyway in that case. I also imagine the searching logic gets used in lots of places besides straight searching, like adding new people, finding duplicates, etc.
Even if unknown name fields are supposed to be blank, the tendency to use Unknown will probably always be there because that is what is seen in page titles. So it would probably be useful when saving pages to convert Unknown in the name fields to blank. Though, again, a blank given name is awkward. --Jrich 16:08, 23 March 2012 (EDT)
Unknown and blank are treated similarly by the search engine: If you search for Givenname=John and Surname=Smith and set the drop-down at the bottom of the to "Exact and close match", then people whose given name is "Unknown" and people whose given name is blank are not returned. If you change the drop-down to "Exact, close, & partial", then people whose given name is "Unknown" and people whose given name is blank are both returned, but ranked lower than an exact or close-matching given name. Eventually I may have the search engine distinguish between a "missing" name and a known name and rank people with missing names higher than people with names that differ from what you searched for, but if I do, I'll treat Unknown and blank both as missing, and you'll still be able to search for "Unknown" names as you can today.--Dallan 20:07, 26 March 2012 (EDT)

Free webinar on Copyright Law for Genealogists [27 March 2012]

Since we address copyright issues on WeRelate, this free webinar should be of interest to users. Details below. Clipped from email received from The Association of Professional Genealogists. --Beth 20:53, 27 March 2012 (EDT)

APRIL'S WEBINAR Facts, Photos and Fair Use: Copyright Law for Genealogists Wednesday, April 25, 2012 — 9:00 p.m. Eastern Daylight Time Presented by Judy G. Russell, CG

Materials and records created by others are the bread-and-butter of genealogy. But whether copyright law allows use of old photographs, reports and articles can be murky at best. Join "The Legal Genealogist" Judy G. Russell as she sheds light on what’s copyrighted and what isn’t, when and how copyrighted materials can be used, and how to handle copyright issues with our own clients.

  • Reserve your Webinar seat now at:*

https://www1.gotomeeting.com/register/353574385

System Requirements: PC-based attendees Required: Windows® 7, Vista, XP or 2003 Server

Macintosh®-based attendees: Required: Mac OS® X 10.5 or newer

iPad, iPhone and Android attendees Required: Free GoToMeeting app from the App Store or Android Market

We hope you enjoy them!

The APG Professional Development Committee


Sorting out Canadian History [11 April 2012]

About ten days ago I put up a problem on a Place or Source Talk page, hoping someone would see it and sort out the parts I can't do for myself.

At the moment the WRsource for all Canadian 1851 census entries start off

Canada East, United Province of Canada. 1851 Census of Canada. (Ottawa, Ontario, Canada: Library and Archives Canada), followed by our specific reference to microfilm reel, section and page.

This is fine if you are working in Canada East (now Quebec), but doesn't fit if you are working in Canada West (now Ontario).

Canada went through four different reorganizations between 1763 and 1867:

1. Prior to 1763 the whole area now known as Canada was in French hands and was called New France (except for Nova Scotia which was called Acadia).

2. In 1763 it became British territory and was broken into the separate colonies of Nova Scotia, New Brunswick and Canada. Nova Scotia and New Brunswick did not link up with Canada until 1867.

3. In 1791 Canada was broken into two administrative divisions: Lower Canada (Quebec) and Upper Canada (Ontario).

4. In 1841 the two divisions were renamed Canada East and Canada West and further governmental reorganization occurred. Wikipedia refers to Canada East and Canada West as the United Province of Canada. I do not know what they base this on, but it is much more likely that the entity was called the United Provinces of Canada. Canada East and Canada West were two equal parts of a whole. This is not so when it comes to places in WeRelate.

5. In 1867 Upper and Lower Canada became Ontario and Quebec, respectively, and joined with New Brunswick and Nova Scotia to become the British Dominion of Canada. The other present provinces of Canada eventually joined the confederation independently of each other. The word Dominion has since disappeared from the description.

There were two censuses covering Canada West and Canada East--one in 1851 and one in 1861. The titles used as WR Sources should be the same for each except for the year. New Brunswick had a census in 1851 but it was entirely separate from that in the United Provinces and should have a separate Source. (Nova Scotia may have had one at the same time, but I have not seen any reference to published data.) All original data for all censuses (1851-1911) is held by Library and Archives Canada (LAC) at Ottawa. Transcriptions have been carried out by external organizations and some are available online as free and pay websites. LAC itself has originals online (but not necessarily transcriptions) for all censuses except 1861 which I understand is due this year.

Canada West did not have a system of civil registration and therefore the two censuses of 1851 and 1861 are vital for genealogists trying to trace their families during in the mid-nineteenth century.

Summarizing, could we please have a group of places described as

New France (to 1763)

Canada (1763-1791) -- and I wish I could think of a more descriptive name here

Lower Canada (1791-1841) and Upper Canada (1791-1841)

Canada East and Canada West = United Provinces of Canada (1841-1867)

Canada (post 1867)-- I am sure this is in place now

Thanks --goldenoldie 07:28, 11 April 2012 (EDT)

The general rule on WeRelate is to title place pages as they were around the year 1900. Each place page provides fields for defining alternate place names and the year ranges those names were in place. So, for Place:Ontario, Canada, we could add alt names of Canada West and Upper Canada.
Regarding the source titles, our Help:Source page titles page states that at the county level, the census sources for Canada should be titled County name, Province name, Canada. YYYY Census of Canada. I agree the census source page titles should be consistent throughout the years. --Jennifer (JBS66) 10:02, 11 April 2012 (EDT)
For the U.S. census, I put the locality in the "Record name" field of the source citation on the person's page, and I only reference the main U.S. source. This results in a citation that looks like "ED 46, 3rd Ward Kansas City, Jackson, Missouri, in United States. 1930 U.S. Census ...". When I look at this source's description of the census, I can see a case to be made that there should be three subordinate source pages for each of the censuses in the united Province of Canada, Nova Scotia, and New Brunswick. (Notice in that source it only refers to the "Province of Canada", not the "United Province of Canada" or plural "United Provinces of Canada". But I don't know what is more accurate.)
On the page Source:Canada. 1851 Census of Canada, for example, the problem is that the system only shows the first item in the "Places covered" list in the citation. If you use the three subordinate sources instead, you solve the problem as each of those sources only needs one place in its list. For the main Canada page, I suggest either removing the list of places and replacing it with just "Canada", or just add Canada as the first place in the list. That way you will not see the wrong place on so many of your citations. -Moverton 13:03, 11 April 2012 (EDT)

Jennifer, I must admit I have not seen the recommendation you quote for titling census sources for Canada.

I don't think it is workable because Canadian census districts are based on federal electoral districts and not on counties within the provinces. Electoral district boundaries changed every ten years as the census indicated population imbalances in the size of the various districts. The next census was based on the new boundaries. There might have been a point when an electoral district and a county was one and the same, but in many areas this passed before 1900. To reference a location with the LAC you must give the whole name or number of the electoral or census district or your question gets a null response.

When I started to look for census sources on WeRelate a couple of months ago I immediately selected the national source for the year in question. The census was organized on a national level, therefore I expected to use a national source. The frustration was in discovering that the group of censuses were presented in such a non-uniform way.

Even five years ago the common method to find a family on a Canadian census was to search an individual FHL microfilm covering a specific geographical area. At that point referencing the county and its province made sense. But now the census for the entire country is online at various websites as both original material and as transcriptions. We can dip into this database here and there as our wandering families oblige.

I want to have a go at altering the organization of the names of the Canadian censuses but some re-titling at the Place Category level must come first.--goldenoldie 16:56, 11 April 2012 (EDT)


WeRelate standard of place names in 1900 versus Wikipedia articles [17 June 2012]

If the WeRelate standard is to use place names as they appear in 1900, why do place name descriptions start with a paragraph out of Wikipedia that gives the population and the political organization of the place in 20xx?

Often the history section of Wikipedia articles includes material useful to genealogists, but the first section can give a false impression of the area where an ancestor was living a century or more ago.--goldenoldie 10:04, 27 April 2012 (EDT)

Because it is easier than starting from scratch. Wikipedia has its own design goals and motivations and these won't necessarily align completely with WeRelate. Using historical names is also likely to "give a false impression of the area where an ancestor was living" as they appear to reside in differently named locations without ever moving, and using dates with an about qualifier could make it impossible to decide on the correct name. No system is perfect, but the system in use seems relatively functional in most cases given the limited resources available. --Jrich 12:20, 27 April 2012 (EDT)
Let me further add, that if a place is known with sufficient precision - say a particular plot in a cemetery, a historical residence or garrison house - GIS coordinates, using the googlemap template can eliminate the problem of historical name ambiguity.
Even GIS co-ordinates need to be used carefully. Yesterday I found a Contained Place in an Ontario, Canada county situated (according to the accompanying Google Map) just north of the Himalayas. I don't know my modern Asian geography well enough to be able to report what country it is now in, but twenty years ago we could safely have said it was in the USSR.
Sure enough, someone had ended the co-ordinates with an E instead of a W. A correction has now been made--after another check with Google Earth.
Perhaps, but isn't the real problem there a failure to critically evaluate your information? I generally don't use GIS that I pick up from elsewhere. It's a matter of specifying a location that I know with certainty - opening a mapping site, zooming in, and lining up the cross hairs to get a reading. Then verify that your reference does what you expect. --jrm03063 17:06, 27 April 2012 (EDT)
As I've said before, I think the 1900 standard is kind of dumb. Even the LDS geographic names are not consistent with that date. It would make a lot more sense for WR, as a genealogy tool of the future, to set a more modern date like 2000. In any event, if the 1900 date is going to continue to be used, perhaps what the site needs is a useful 1900 geography resource, including maps from public domain sources (1900 atlases, 1900 encyclopedias, etc.), and a comprehensive gazetteer that's also taken from a reliable 1900 source. Now, where's Mr. Peabody and the Wayback Machine when you need him? — Parsa 23:09, 14 May 2012 (EDT)
In all honesty, it's not like we sat down and said "let's pick the ideal date". When I constructed the place wiki, I merged the LDS Family History Library Catalog (FHLC), the Getty Thesaurus of Geographic Place Names, and a crawl of Wikipedia. Nearly all of the places in Wikipedia and Getty were found also in the FHLC, but nearly half of the places in the merged result were found only in the FHLC. The places in the FHLC generally correspond to where they were located in the early 1900's, though some countries use different years. So if I chose the same date as the FHLC, it was possible to position nearly every place in the place hierarchy. If on the other hand I would have used 2000, I would not have known where to position nearly half of the places in the place hierarchy. Not being an expert in historical geography, I chose the same date as the FHLC. It's not an ideal solution, but remember that you can add the modern jurisdictional hierarchy as "also located in" places. Perhaps someday if the majority of places list modern jurisdictions as also-located-in places, we could automatically rename the place titles to their 2000 equivalents.--Dallan 23:06, 5 June 2012 (EDT)
I'd be willing to bet that very little genealogical research involves events occurring after 1900, I don't believe that what a place name was in year 2,000 or 2,012 is of great genealogical significance. Most people know who their grandparents were and start their research there. One or two generations of research probably gets any family back into the 19th century. 20th Century immigrants, WWII refugees, etc. likely come from places whose political boundaries are likely to have changed since, eg the former USSR or Yugoslavia. etc. Even the European Community dictates standards for political hierarchies which will involve future changes in boundaries and nomenclature. Just looking at the state of Virginia alone, for example, To bring the creation of new counties, from within older counties, parts of counties and elimination of extinct counties to current status or at any other point in time would present a research project of larger scope than many family's trees.--Scot 13:14, 6 June 2012 (EDT)
Scot, a lot of grandparents today were born in the 1950s and 1960s, so genealogical research is moving well into the 20th century. The points of advantage of a more modern date are these: 1) Few good and accurate maps exist from 1900 or dates prior to that. Much of the USA, for example, wasn't even covered by topographic maps of any detail in 1900. Really good accurate topographic mapping didn't exist for most of the world until the post WWII period. Today, we not only have accurate maps, but we can plot locations with GPS coordinates and find them on aerial photos and digital topographic maps online. Few accurate gazetteers existed in 1900, while numerous resources are available to us now. 2) Most countries, states and US counties have been relatively stable over the last several decades. There were much more radical changes in US and world geography prior to 1900. This is especially true of areas like Germany which were a patchwork of hundreds of small states under princes, counts and barons. To use your example of counties in Virginia, you can cite a place in a defunct county, but that place still exists somewhere today. It may have changed counties every decade or so, so which one do you pick? My feeling is that the current location is best, and references can be made on the place pages as to changes in the county in which it was located. 3) Genealogical societies and historical societies are based on modern counties, districts, etc. Searches of government records and local histories are based on modern boundaries, not those of yesteryear. 4) Geography is difficult for most people with today's boundaries and locations. How much more ignorant are people of the geography of 112 years ago? Most people would have no idea in which US county or European country a town might have existed back then. But they likely know where it is now. If they don't, they can find out in a minute using online maps. — Parsa 21:33, 6 June 2012 (EDT)
Being a grandparent myself, I feel no need to research my own birth, nor that of my parents as I am the primary source for much of the facts pertaining to them. Most of us are researching more than two or three generations so do little or no research in the 20th century. My Ancestor who was born 1728 in Brunswick Co., VA, married 1748 in Lunenburg Co. and died 1780 in Halifax Co. may never have moved, but the only record that exists for him in Halifax is his will. To think that all documentation of him would be found in Halifax records isn't likely or feasible. Do you think that someone would have sorted and transferred county records every time a new county was created is not realistic. Using place names as they existed at some point in the past certainly does not preclude the use of modern maps, GPS, or any other of the resources you mention. Having spent upwards of 4 months a few years ago mapping Portugal for WeRelate, I realize how difficult it is to pinpoint the exact location of a place, no matter what the timeframe. There are tons of duplicate place names, defunct names, boundary changes, political hierarchy revisions, ecclesiastical divisions, neighborhoods and a myriad of other difficulties encountered. Identifying the current place is easy, identifying the historical is often not. Portugal for example will eventually have to restructure their place name hierarchy to conform to the standards of the EEC. I imagine the situation is similar for many other countries. Are you or anyone else willing to update the entire database to reflect these changes? Of course not. 1900 was selected as the base year. If that seems arbitrary, so be it, but is a fixed point of reference, while you, it seems prefer a moving target. I would suggest we have many more important issues to address. As it is, genealogy is a study of the past, not the future.--Scot 16:04, 7 June 2012 (EDT)
I recently uploaded my earliest known ancestor who settled in Hempstead, Queens, NY. It grieved me to have to change his record to say he lived and died in Nassau Co. Nassau County wasn't in existance when he lived in the area and all historical records give his location as QUEENS County. But by 1900 it was Nassau and I reluctantly changed his info to read Nassau County. Having been taught to always leave dates and locations as they are found, it just seemed wrong to have to change the county. How many genealogists are going to be willing to make these changes?? --Janiejac 19:58, 7 June 2012 (EDT)
You should quote or abstract sources exactly as to how they spell names and name places, but of course, quoting and abstracting sources isn't done in the place field. The place field is merely naming a physical location. Since most of the time you don't know precise coordinates, you tend to say within the bounds of the prevailing government entity, but naming the government entity is not the point. The point is to identify the physical location of the event as best you can. Probably to reduce ambiguity, somebody started this system of using the government entities as it was known in 1900 (2000 was probably not an option when this decision was made). This way the name and bounds of the government entity were predictable and not dependent on the date of the event (bad: if the date changes, maybe the name changes; how do you deal with Abt-dates contemporaneous with a boundary/name change). WeRelate found that data useful, loaded the data, and by implication, adopted the same policy. Even if it was desired to update this policy, there are 2 million Person Pages and 800000 Family Pages, with place names that theoretically follow this policy. And since the changes in place names over the last 112 years are not always one-to-one (one name splits into two, etc.), it would require a human to research it. Meaning, I would guess, it probably won't happen. --Jrich 21:22, 7 June 2012 (EDT)
I've struggled with this on occasion, as well, and tried different solutions. I've finally settled on using a "pipe" in the place name -- entering the current place name, follwed by a pipe, then the place name used in the past. That preserves the original information, as well as taking anyone interested to the page where they should be able to get at least a brief history of the area, including previous place names and boundaries. An alternative is to use the description space to add a commentary on the present/previous name, although I think that's a little more "clunky".--GayelKnott 20:30, 7 June 2012 (EDT)
I am not willing to edit that many pages. So I believe that we should accept this standard and work around. There is an entry box on every place page that exists to show the changes in jurisdiction. Utilize this on the place page and that will improve the gedcom matches. So if you have a location that was once in Virginia but now in West Virginia then enter the data on the place page in "also located in". This data has been entered for West Virginia. You may enter the year range and the source. - Contributed by Beth
Janiejac, Gayel's suggestion of using the "pipe" in the place name is the preferred approach: enter the title of the wiki page, followed by a pipe, followed by the name of the place as it appeared on the record.--Dallan 22:14, 15 June 2012 (EDT)
Dallan, I'm going to go out on a limb, and say I don't believe you should even display the name after the pipe symbol. You should only display the name of the Place page that is specified. You should keep the pipe syntax, but you should use it only as a way to keep a record of what the original GEDCOM input said, so that if the computer picks some crazy Place that doesn't make sense, a subsequent editor can have that original input available as they try to fix the Place name. Every page may have multiple sources, and some sources may choose to name a location with a historical name, and other sources with a modern name, and others may have a wrong name. The source citation is responsible for quoting or abstracting what the source actually says, not the Place field. That would be shortsighted, as if nobody is going to come along and add another source that follows a different place naming convention. The place field needs to be understood as a summary resulting from analyzing all the sources, and it is thus perfectly reasonable to expect it to name the place in the preferred WeRelate style. The reason this question comes up over and over is partially because the pipe mechanism gives people the impression that their preference for naming a place matters over community standards. --Jrich 22:53, 15 June 2012 (EDT)
That's an interesting point of view. I'm wondering though, wouldn't all of the sources for a particular event describe the place the same way -- using the jurisdiction that was current at the point the event occurred? So if the event occurred in 1700, wouldn't the place be displayed according to the jurisdiction it was under in 1700?--Dallan 00:20, 16 June 2012 (EDT)
Not all sources follow a consistent practice, and even if they intended to, the level of knowledge and research is different, that differences are seen all the time. For example, a birth may be recorded in the Vital Records of Salem, Mass., but a book that studied deeds may tell you the household, the presumed location of the event, was in the part of Salem that became Beverly. Guidelines suggest one should name the location as Beverly, its name in 1900, but a source is really needed to justify this conclusion since the birth record is in Salem. The Chebacco parish in Ipswich, Mass. is now the town of Essex, but most colonial births will be found in vital records of Ipswich. A source citing a contemporary document may refer to a place by its Indian name, e.g., Winnisimmet, while some family genealogy may simply say the children were born in Chelsea, Mass. Does it help to have Winnisimmet added as a pipe alias, realizing that this will hide the more familiar name Chelsea? Or should the source citation quoting the contemporary document add a notation that Winnisimmet is now Chelsea? --Jrich 01:22, 16 June 2012 (EDT)
Thanks for these great examples! So ideally, we'd add places to the source citations in place of recommending the pipe syntax. Adding a place field to the source citation area would be a fairly simple change. What do people think?--Dallan 12:29, 17 June 2012 (EDT)
Not exactly what I had in mind... Not even sure how this would work, as a source may mention several locations: birth, residences, marriages, death, etc. Mostly I want to avoid issues like "Recent questionable edits" on User talk:Pkeegstra and other such issues. People get too religious over what they name a place when they're all talking about the same physical location. I think the place name field should be a link to a place page and nothing more. Anything else is overloading the field and creating problems. It represents the location of the event after analyzing and considering all sources, not just one source: a single summary value representing the most likely conclusion available. I think there are plenty of ways to rationalize what a source says to the displayed Place name, or even to add further clarification, using the already available free-form areas of the Description, the narrative, and the text box of the source citation without pipe aliases. If it weren't for GEDCOM loading and the occasional need to add "Prob." or similar qualifiers, I would advocate getting rid of pipe aliases entirely, and it could be, that the description field would serve both those functions adequately. My biggest concern is that it hides the "official" name in favor of personal preference. At one point there was talk about displaying the two sides of the aliased name separately. Don't like that, as I think most pipe aliases carry no added information, hence add no value, but that's at least better. --Jrich 13:43, 17 June 2012 (EDT)

Person page display suggestion [5 June 2012]

I'd like to suggest a small display change for certain Person pages, with Person:Omer Claiborne (1) as an example. (I've been building a large and extended Claiborne family network on WR lately.) If there's a date or place of marriage, or a source cited for a marriage, then a line shows up on the Person page under "Facts and Events," beginning "Marriage," with the spouse's name and so on. Well and good. But if there is no other data than the mere fact of marriage -- which often happens when you pick up a spouse's name from a joint grave marker at Find-a-Grave, for instance, and choose not to include that as a source -- then it appears that no such line is generated on the Person page.

Now, because the subject's parents & siblings appear at the top-right, and then the subject's own spouse(s) & children below that, if there are a lot of siblings, then the only mention of the spouse's name -- or even that there is a spouse at all -- is likely to drop "below the fold," and you have to scroll down to make sure you're not overlooking them.

In the case of Col. Omer Claiborne, noted above, his daughter was the famous "Liz" Claiborne, and I picked up her mother's name from Liz's own Wikipedia page. Even Omer's obit doesn't mention his wife's name, for whatever reason. I dislike being forced to make up an approx. date just to get the display to work the way I think it ought to. And I dislike, for various reasons, to cite Wikipedia for any fact that doesn't bear directly on the subject of the Wikipedia page. And I will chase down further documentation on those several relationships when I have the chance -- but in the meantime, it seems obvious to me that Omer's page ought to mention his wife's name without having to scroll down the page. (Okay, Omer, specifically, doesn't happen to have a lot of sibs, but I have seen this issue come up recently in cases where there were a dozen of them.) A "Marriage" line could be generated under "Facts and Events" by the mere fact of the existence of a Family page involving that person -- right? It could be just "Marriage [blank date] [blank place] SpouseName." I'm guessing the programming involved here would be pretty minor, a "Yes/No" thing. Anyone have a reaction to all this? Am I simply overlooking something? --MikeTalk 12:08, 7 May 2012 (EDT)

This problem is can be especially misleading if there are two or three marriages and some have dates and some don't. Then some marriages appear in the Facts and some don't, while the various spouse info boxes are not visible. However, even if the dateless marriage was forced to appear, estimated dates would still be desirable to have the order reflected correctly in the list of facts.
I would also like to suggest that if there are intentions/publishment of a marriage but no marriage date (what is the proper tag? Marriage Banns?) that it be displayed in the infobox "int. 30 Jun 1700" in lieu of the missing marriage date, the same way christenings are displayed in lieu of a missing birth date. If the marriage date is there, it would go in the infobox, and the intentions not. There are many couples for whom only their intention is known, but no marriage. Intentions should really be entered as separate facts, since the location may be different than the location of the marriage, but I find that adding an intention and also adding marriage dates of "Aft. 30 Jun 1700" just to make the marriage appear in the facts and to get the infoboxes ordered correctly is kind of kludgy.
Finally, I noticed that people with multiple marriages only list one spouse in search results. For example, it I search for Thomas Prence, Person:Thomas Prence (1) is listed showing only spouse Patience Brewster and none of the other three wives he had. I don't know if this was a recent change, or if this has always been so and I just noticed it. It would be useful to see all the spouses names displayed. Many, many times, the perspective that one has when working, doesn't encompass the entire life of a person being searched for, like when attaching a single child to just one of his marriages, so displaying only one spouse can make it difficult to identify the page as the right one. And it isn't always the first wife, so I am guessing it is the first Family page created, which makes it somewhat unpredictable. --Jrich 13:01, 7 May 2012 (EDT)
I agree with Jrich. I have encountered some of the same problems. I am wondering if the "missing" spouses in search results might be one of the reasons I find so many duplicate marriages? If you don't find what you are looking for in the search results it is easy to conclude the family doesn't already exist in the database - then you add it and now there are duplicate families, often with duplicate spouses.
I also try to use Before or After estimated dates when there are multiple marriages as a way to force them into the correct sequence. In my contributions there is a person with 8 recorded marriages to 7 different spouses - possibly not a record but certainly a good argument for being able to find all of them when searching, and trying to get them displayed in the correct order!--Jhamstra 17:07, 7 May 2012 (EDT)
As it happens, I came up with a similar problem just this morning, with the Rev. John Peter Livengood. He had four wives and only for the first one do I have a marriage date, or any other info. The other three names came from a county history and they spread over, probably, 30-40 years, so I hate to have to make really pointless guesses as to the dates. But they appear on his Person page, at least, because I did make notes on each of the Family pages as to order of marriage & the number of kids they had. --MikeTalk 07:46, 15 May 2012 (EDT)
Not that hard to put estimates in that mean something: the first wife died 1843, so you could put Aft 1843 for estimated date of second marriage. 1850 census shows second wife with kids 5 4 3 2 and 1 month (plus 7 year old that is probably left from first marriage), so that accounts for the 5 you mention, and one can conclude that she probably died soon after, and you could put Aft 1850 or say Abt 1852 for third marriage. One could then guess Abt 1855 for third allowing time for number of children you show. However, Find A Grave turns out to be a rich source, giving deaths of wives in 1843, 1852, 1854 and 1887 respectively. So now you can make good estimates. --Jrich 09:44, 15 May 2012 (EDT)
  • I fixed the order of marriages for you. All you have to do, is edit the person page and drag the family pages shown in the list into the correct order. As you move your mouse's cursor onto the left border of the box around the listed family page, the cursor changes to indicate that you can drag the item. It isn't really obvious that you can do this, but this feature prevents you from having to enter dates solely for the purpose of sorting the marriages. Moverton 16:27, 16 May 2012 (EDT)
Can you add these suggestions to WeRelate:Suggestions? I'm going to spend some time over the next few days implementing as many of the suggestions as I can.--Dallan 23:19, 5 June 2012 (EDT)

lipstick on a pig [19 May 2012]

Am I the only one getting tired of all the meaningless cleanup that is going on? How people that know nothing about a person waste time prettying up a fact that is obviously wrong, or mangle a fact into an error to make it look presentable, or even change data into their preferred form when the existing form is not wrong, and in the process, alert all the watchers: alert! come see the meaningless change to this page. What have I seen in the last week or so? Towns in Massachusetts move to England, towns in Massachusetts are fixed to go from red to blue on a fact dated before the Mayflower, dates are put into lower case even though most GEDCOMS force them to upper case, Sr. is changed to Senior, "Abt" is changed to "abt" or "ca". When these kinds of changes are the only changes made to a page, well, then it is pretty clear a lot of mindless busy work is going on.

It is one thing to come along and combine 3 or 4 alternate birth dates into one researched birth and provide a quality source citation to prove it. That is good stuff that improves the page and increases the value of the WeRelate website! Is is another to studiously change all 4 months to lower case without trying to resolve the confusion. That is not a change worth bothering the watchers about and should probably be deferred until you, or somebody else, actually cares enough to take the time to do some real genealogy and figure out which alternate is right.

I'd like to suggest that when you see a page that needs cleanup, try to find something to add to it, to improve it. It may take an hour or two of searching to find sources, but add that missing death date, add the rest of the children, cite the source the justifies the data that is on the page. Then maybe you have some claim to cleanup the cosmetics. At least when you bother the watchers with the notification that changes occurred, there'll be some substance there. If you can't commit that much to a page, then perhaps you should just leave it alone. After all, every piece of information that goes on a page should have a basis, and if you haven't done any research then you don't know that basis, and you are in danger of making a wrong assumption about the intended meaning of a potentially wrong fact already on the page, thereby completely obscuring a recognizable error with an additional mistake. --Jrich 12:16, 17 May 2012 (EDT)

Once again today I apologize for annoying you. I will cease and desist. I was actually removing the UID #'s which annoy me and along the way attempted to cleanup some other data. Obviously incorrectly. So not to worry I will leave the pages alone with the UID's. Have a great day. --Beth 12:33, 17 May 2012 (EDT)
Beth, this has been going on a long time, and the post was not focused on you, who showed up in my watchlist only this morning, and in fact, not the only one doing so this morning. Rather, this was motivated by what seems to be a growing trend (admittedly, your respected user name adds weight to my perception of trends) to simply make cosmetic changes to a page without apparent research or significance. (Most pages having UIDs are in significant need of more research, so it's not hard to find some improvement that will allow you to make the changes significant.) Some mornings it seems like that's all people spent their time doing, as dozens of such meaningless changes often show up in my watchlist. One of the reasons for posting this is to see what others think. My opinion is clear, I think, but perhaps I am out of step with the others. What 99% of the pages need is more research and sources, and that can't be done by computer, and cleaning up wrong facts almost seems like a waste of time until that is done. --Jrich 14:29, 17 May 2012 (EDT)
I believe you have a valid point, and I am pleased that you pointed out the problem of the numerous emails with no significant changes made to the pages. Rather ironic I know, but because I have workers here doing home improvements and am likely to be interrupted at any time for consultation, I was looking for a "mindless" task and decided to remove UIDs from pages. I did not think about the numerous emails users would would receive. Since this is a Wiki, I do not think it practical to place limitations on editing pages, but I do agree with you and will find some other "mindless" task. Maybe I will even clean the rest of my house. <g> I would ask when one is improving a page by adding something significant would they please also delete the UIDs and RIN numbers because they are of no significance on a community page? --Beth 16:24, 17 May 2012 (EDT)
Is there an agreed convention for capitalization of months? If so then perhaps a checker to warn when not following the convention would be useful? Otherwise there is no point in debating this? Personally follow the dd Mon yy convention but apparently this has not been agreed upon?--Jhamstra 19:00, 17 May 2012 (EDT)
Yes, there is an agreed convention for capitalization of months. See Help:Style guide Dates.--Beth 19:36, 17 May 2012 (EDT)
Dates are only one issue.
GEDCOM specifies that months are case insensitive. So data coming in from GEDCOM uploads depend on the software. If I were to upload a GEDCOM, my software would make all the dates be upper case, as is seen on Person:Judith Carter (6) which is a remnant of a trial I made of GEDCOM upload. I checked some other people's recent GEDCOM uploads and see both lower and upper case dates suggesting to me that WeRelate takes what it is given and it comes in both styles. Changing the case of these dates really makes no difference in usability. Does it need to be changed? Does it need to be changed so badly that it can't wait for a more comprehensive edit?
Another area is place aliases. The pipe alias on locations is legal. So when is it allowed to remove or add aliases according to one person's preferences assuming the previous value represented another person's preference? Is Boston, Suffolk, Massachusetts, United States|Boston, Mass. worth respecting or worth removing? Is Boston, Suffolk, Massachusetts, United States|Boston, Suffolk County, Massachusetts Bay Colony worth respecting or worth removing? They are legal. Yet people do edits where all they do is remove or add these aliases Does it need to be changed? Does it need to be changed so badly that it can't wait for a more comprehensive edit?
There are other cases where changes are made that seem motivated solely by personal preference without increasing anybody's knowledge of the genealogy or the pages usability. It doesn't seem necessary to me. --Jrich 21:09, 17 May 2012 (EDT)

Just want to point out that not everyone has the time, opportunity or access to do research on a given page but they may have enough time to do clean up ala lipstick on a pig. They should not be discouraged from doing so. They could be encouraged to select "minor edit," however, to avoid filling watchers' inboxes. Jillaine 21:13, 17 May 2012 (EDT)

Unless I am missing something, any kind of change that can be done without research falls into the obvious and meaningless category, such as changing "DEC" to "Dec" (in accordance with style guidelines but not honored by GEDCOM), or "Abt" to "abt" (a common occurrence despite being in contradiction to style guidelines). If WeRelate users really want this kind of uniform formatting, then I recommend that everybody go to the Suggestion page and endorse some suggestion for a bot to fix these formats, and leave people free to do the hard work that only people can do, which turns out, to be... research! How can you clean up a date of 4-5-1644 without doing research? This could be Apr, May, Jun or Jul. How can you cleanup 3 or 4 alternate birth dates without research? This is the type of cleanup that needs to be encouraged. Or some of the other "cleanup" that only appears meaningless, such as: deciding if the red location "Yarmouth" is in England or Massachusetts, or merging people based on the unsourced data already on their pages (which is often wrong because it comes from some Internet site that confused two different people to begin with), or renaming John Doe and Jane Doe to John Doe to Jane Unknown. All these last cleanup activities should only be done when one has time to do a research. So I completely disagree. People should be discouraged from making changes to a page they haven't researched. --Jrich 23:28, 17 May 2012 (EDT)

It seems like it would be pretty simple to create a bot to automate some of these things (standardizing month name capitalization, for example). Are there any active bots, or any in development? Jdfoote1 22:03, 17 May 2012 (EDT)


Wow. I for one am thrilled with anyone who will take on mindless tasks that need to be done. Just use the summary field and hit "minor edit" -- which exists for *precisely* this reason--and this entire problem disappears!--Amelia 00:32, 18 May 2012 (EDT)

Well, my watchlist works differently than yours. It shows all pages that have changed, whether major or minor. And often, if the last change was minor, the change is shown as minor even when it was immediately preceded by a major edit (in my own edits, it is not infrequent that the last edit is minor: "fixed typo", but that is fixing a major edit I had just made immediately before that). Not to mention that a propagated major edit turns into a minor edit after they propagate. So I think the problem isn't disappearing, it's being ignored. Which is maybe why I'm complaining about it, and you're not.
Then there is the mindless part. It is that. Yesterday I had one person cleaning up pages by adding pipe aliases, and another person doing cleanup by removing pipe aliases. Maybe we could coordinate and agree to add pipe aliases on even days, and remove them on odd days?
Finally, there is the "need to be done" part. Well, I find that what needs to be done is not changing the spelling of DEC to Dec, but to find the source that tells how it is we know the answer is December in the first place. I've seen plenty of pretty websites, but I've learned through experience, if the sources aren't there, they're not worth the time it takes to read them. One cleanup yesterday got me looking at the page in more detail. Four facts had been nicely cleaned up. I spent an hour searching on books.google.com and promptly deleted two of them as impossible and modified the other two because they were less precise than current knowledge of primary sources allows (adding those sources to the page of course). So nothing is left of the cleanup. What a waste of lipstick! What "needs to be done" is for people to spend time productively, doing research, not doing mindless cleanup that probably should be automated, and in truth represents more personal preference than it represents need or value or improvement. --Jrich 09:02, 18 May 2012 (EDT)
First, I'm quite certain my watchlist works the same way as yours. I was talking about emails, which is what I thought you were complaining about, and there is an option not to receive emails for minor changes. Minor changes are also clearly marked on the webpage list, if only people use them. I'm watching 14,000 people, and I really don't have the issue you describe. Second, you seem to have a problem with the concept that not everyone has long blocks of time when they can concentrate on this site. There are many, many things that can be done here when one is multi-tasking or brain dead, and there are many things that should only be done when one is paying attention. Implying that one can do the latter when their schedule allows only for the former is not productive. And your rant serves only to discourage anyone from doing anything that they don't think lives up to your extremely high standards. I think it's unproductive and that you are making a mountain out of a molehill, to borrow another phrase. A more productive undertaking would be to make a list of other minor changes that would be productive - like removing old gedcom sources, strings of nonsense in note fields, etc., so that people who are trying to help would have a more productive place to start.--Amelia 11:47, 18 May 2012 (EDT)
Well, Amelia, that was an important change we were both just notified on. It wasn't marked minor, so I know you got an email about it and got to share in the excitement. --Jrich 16:41, 19 May 2012 (EDT)
All of us are long time users of WeRelate and useful contributors. We need to work together for the health of WeRelate. Kinder comments and kinder critiques are preferred. We definitely need more users and don't want to scare new users off by our disagreements. If you Jrich prefer to watch every edit including the minor edits then you will definitely have more emails with the number of pages that you watch. This is a great opportunity for you educate new users tactfully and help them understand how WeRelate works. It is also an opportunity to figure out how we may alert users of important additions to WeRelate. I did not know of the existence of the Style Guide until recently or didn't remember it. I also found the Find A Grave templates on my own. Perhaps y'all know of a better way to communicate the additions to WeRelate. Warmest regards. --Beth 19:44, 19 May 2012 (EDT)

Genetic Genealogy [22 May 2012]

Could I ask what is your attitude to including information about genetic genealogy here? In particular, information about Y chromosomes, which would be common to many people with the same surname and all (subject to mutations) male line descendants of a given person. If you would welcome it here, where could it be placed? Presumably the Person: Surname: and Category: namespaces would be ok? Thanks. AndrewRT 17:44, 19 May 2012 (EDT)

We use the Surname page for this purpose. There are several Family Tree DNA adminstrators on site but not sure that any of us have actually posted the results on WeRelate. We have posted links to the site on the surname page.We welcome your additions in genetic genealogy to WeRelate. Our YDNA results template is in need of an overhaul. Thanks so much for participating.--Beth 19:55, 19 May 2012 (EDT)

thanks! Are there any good examples you could show of how this template has been used? AndrewRT 08:07, 20 May 2012 (EDT)

The template has not been used. If you search WeRelate; all; keyword DNA, you will find a variety of DNA pages. There is not a standard entry template. So however you choose to display your data, I would still either use the surname page or place a link on the surname page to your DNA project. The category DNA testing does not have a parent category and is not on all of the DNA related pages.--Beth 10:12, 20 May 2012 (EDT)

ok. is there any easy way to get a list of people on werelate who have data on ysearch or another public source? Are there copyright issues if we copy other peoples results? Would you work with me to design a template? AndrewRT 12:57, 20 May 2012 (EDT)

I do not know how to get a list of people on werelate who have data on ysearch. Maybe someone else does. Category:DNA Testing is now a page. I am searching WeRelate and adding this category to the relevant pages using the pipe and surname to sort correctly. I am not any good at designing templates, but I found that Parsa has created a table for results from 1 to 37 markers. See User:Parsa/DNA. This looks good to me. Maybe Parsa or someone else could convert this to a template and add tables for the other markers. --Beth 14:31, 20 May 2012 (EDT)

Had a look through these pages and it seems ripe for expansion and organisation. I'll make a start on creating a template we can use. Few questions:, to summarize discussions so far:

1. Is generic genealogy information welcome on werelate -- seems answer is yes.

2. Should y chromosome info be added to Surname page? The issue I have with this is what about polygenetic names like Smith, where you can have lots of very different y results? Even a monogenetic name like Tulloch can have multiple results due to cases where estate workers have taken their laird's surname, not to mention cases like adoption, unmarried mothers, remarriage and cuckoldry. Finally, I have one example of two descendants of one person several centuries earlier having slightly different results due to genetic mutation.

3. Should info be added to person pages? Most testers are living so wouldn't have pages themselves. However, info could be added to male line relatives, and could also include the relationship to the tester so that conflicts such as above could be described.

These considerations affect the template design so would want to agree it as part of design process.

All thoughts appreciated! AndrewRT 15:07, 20 May 2012 (EDT)

Unless you were able to do an actual genetics test on one of your ancestors, I imagine that the Person pages would only contain genetic information if it can be determined that all of his descendants had the same common markers. I haven't gotten too deep into the DNA stuff, but I think it would be interesting to get many different male descendants from different branches of a tree to sign up for testing to see if it would confirm the tree and establish common markers on the different lines. -Moverton 12:54, 21 May 2012 (EDT)
There's an example of someone who's done something similar here. There's a positive match from all six people showing not identical matches but matches that are close enough to indicate recent common ancestry. When you look at the detailed results you can see the results are very similar but not identical. If results are placed on person pages, I would suggest we add a comment to say the relationship between the person and the tester - I'll try to build an example to show what I mean. AndrewRT 17:11, 21 May 2012 (EDT)

I am glad that we now have a Category:DNA Testing. I have to assume that can be used whenever the ancestral line has been tested. Would it be practical to have a banner template to add to the top of a person page that we could type in the URL of where the results could be found? --Janiejac 09:23, 22 May 2012 (EDT)


Place names again [23 May 2012]

Last night I entered 15 persons with their family pages from a book Source:Nicklin, John Bailey Calvert. St. Paul's Parish Register 1715-1798. I entered their locations as Place:St. Paul's Parish, Stafford, Virginia, United States. But a quote from the book says "In 1777 the revision of the county lines threw St. Paul's Parish into King George County, where it has remained since that date. So for the first three score years the records in the Register are of Stafford county and for the last score of King George county."
So the folks I entered all were born and married in Place:St. Paul's Parish, Stafford, Virginia, United States but I think now I should have input this as King George, Virginia with no Parish designation. I want to double check this before I go back to change them all. sigh...--Janiejac 09:02, 22 May 2012 (EDT)


Rather than change the person pages, you could just do move the place page to the new title. This will create a "redirect" so both the old address and the new address will work and give information about the place. AndrewRT 17:47, 23 May 2012 (EDT)

#if: [26 May 2012]

Can I ask a technical question please? I'm trying to pull together a flexible template for DNA testing using the syntax #if: copied from a MediaWiki page on Wikipedia. However, it doesn't seem to work on this wiki.

Is there something that needs installing or turning on here to make that work? Otr is that facility not possible on this wiki. Many thanks. AndrewRT 17:45, 23 May 2012 (EDT)


I believe that the ParserFunctions extension needs to be installed.--Jdfoote1 18:46, 23 May 2012 (EDT)
Jdfoote1 is correct. I'm not even sure that ParserFunctions will run on a 1.7.1 wiki. Oh, no, I'm wrong; it will. So it shouldn't be hard to install. Still, there are lots of other things that would also be possible with a more up-to-date MediaWiki... — Sam Wilson ( TalkContribs ) … 19:46, 23 May 2012 (EDT)
is this something an admin could do or is it just dallan? AndrewRT 11:10, 26 May 2012 (EDT)
This could only be done by Dallan. We have an Upgrade MediaWiki suggestion, but I added another for installing the ParserFunctions Extension. Those who are interested in this functionality should Watch this suggestions page for updates. --Jennifer (JBS66) 11:38, 26 May 2012 (EDT)

Are you trying to make a template table for DNA results? Although not a template, I made tables for my Y-DNA and mtDNA on a user subpage: User:Parsa/DNA.

Thanks for the tip! Here's my effort so far: {{DNA-Y12}}. All comments and suggestions welcome! Would be good to have a standard that we could all use. AndrewRT 16:20, 26 May 2012 (EDT)


Googlemap & OpenStreetMap maps [5 June 2012]

I've managed to replicate the {{Googlemap}} template to give the equivalent for OpenStreetMap using a new template {{OpenStreetMapmap}}.

I notice there is a way to embed Google maps using the [Help:FAQ#Can_I_embed_a_Google_Map_on_a_page.3F help page here]] and the <googlemap> tag. Is there any way to replicate this so we can embed an OpenStreetMap map using a similar tag? May be more scale-able long term for this site if Google Maps starts charging when the site grows. AndrewRT 18:23, 23 May 2012 (EDT)

+1 from me. It'd be great to be able to use OSM here. — Sam Wilson ( TalkContribs ) … 19:51, 23 May 2012 (EDT)
It looks like there are a few options, any of which would require installing an extension on the server. Jdfoote1 19:57, 26 May 2012 (EDT)
Please add a suggestion to WeRelate:Suggestions. I'm going to try to implement as many suggestions as I can by the end of the week.--Dallan 00:39, 6 June 2012 (EDT)

Gripe re: living persons [15 July 2012]

All of the people and families I'm interested in are in a single family tree called HansenWatson. There used to be living people representing my parents and myself, and I was set as the root of the tree. It was very convenient to be able to start navigation from myself and to move freely among both my mother's and my father's ancestors.

Then somebody deleted the living person pages for me and my parents. And now, my awesome unified HansenWatson tree is split in two because the root of the tree was removed. And now it's a pain to navigate between the two branches of the tree.

This sucks. All of those people are my ancestors and there is in reality a single biological tree, so there ought to be a way of representing them as a single tree in WeRelate. The living person pages were useful for exactly this reason. I understand that they have fallen out of favor and are now apparently against policy, but I think that policy should be reconsidered. Let me navigate all of my ancestors in one, unified tree with a single root.--JoshHansen 02:58, 26 May 2012 (EDT)


Josh, I use my genealogy software for navigating my family tree. I see WeRelate as the place to contribute my research to one large collaborative workspace with no one starting person. I'm satisfied and concur with the WR policy that focuses on information about non-living individuals. I know that there are some who would like to use WR as the only place they manage their family tree info but i think that is simply not practical. I accept WR for what it is and not try to make it what it isn't. Jillaine 06:43, 26 May 2012 (EDT)

I'm not sure what you are using to try to move around. The easiest way is to have a pedigree or ahnentafel listing on your User page. Then you can just click to get to the line you want. --Judy (jlanoux) 11:54, 26 May 2012 (EDT)
Yes, WeRelate is not the family tree of any one of us. It's supposed to be humanity's family tree! As Judy said, add a pedigree to your User page. That's what I did on mine, in addition to having a link to pages I'm currently working on: User:Parsa#My_Pedigree. I created two templates to use. One with simple person page names, Template:Pedigree, and one that allows full real names as substitutes, Template:Pedigree2. — Parsa 12:33, 26 May 2012 (EDT)

The Family Tree Explorer has thus far been my primary way of navigating around WeRelate, but the lack of root person makes that less appealing. This is unfortunate, since the FTE interface is very nice.

Jillaine: if we're just supposed to accept WeRelate for what it is and never make any suggestions, then why does this Watercooler page exist? ;-)

--JoshHansen 19:10, 26 May 2012 (EDT)


What a good idea Steven your pedigree page looks good, thanks for the template.

I've been concerned about this too. I'm open to suggestions for how to solve it. Please leave some ideas on the WeRelate:Suggestions page. One idea for example might be to let people create a template on their user pages like what User:Parsa has developed, but that would be displayed like the family tree widget on the person pages.--Dallan 00:37, 6 June 2012 (EDT)

I have often thought about this topic.

I agree that publishing data on living people (other than yourself) is poor practice and should generally not be allowed.

However, living people should be allowed on a limited basis for several reasons.

1) The reason illustrated here. The living person is a contributor and their page roots their tree.
2) I have chosen to publish data on WeRelate in the deeply felt hope that the website will exist far into the future. The connection with the Allen County Public Library gives me this hope. Therefore, I pray that some family researcher far into the future will be able to utilize the information I have spent a lifetime collecting and organizing. I STRONGLY desire that as yet unborn researcher be able to connect me to my research on our family. If I cannot be added to WeRelate until I die, then I must depend on someone else to do this. This is unacceptable.

Therefore, for these reasons I feel that there should be an exception to the living people rule for researchers and their direct ancestors only. No cousins etc. That gets into the living people restriction.

The User:Parsa page is one good method of this. I have done something roughly similar on my User:Srblac page. I have also made entries for my myself, wife and our immediate ancestors so that we may be linked directly into WeRelate. I have used my page Person:Scott Black (1) to leave to posterity all that information that future family researcher would want to know. A User page entry is OK for a lot of this, but it is outside the normal dataset and doesn't get linked and searched in the same manner. I mention this at risk because I feel this subject is important. I would be more than highly annoyed if someone deleted my data as they did for Mr Hansen.--srblac 11:21, 15 July 2012 (EDT)


Acme Mapper [6 June 2012]

Acme Mapper (http://mapper.acme.com) is mentioned in Help:Places as a source for Latitude and Longitude References. I have tried finding the site several times without success. Has anyone else had this difficulty lately? Has the website ceased to be? --goldenoldie 03:39, 27 May 2012 (EDT)


I use it off and on, seems to be responding as I write this... --jrm03063 16:33, 28 May 2012 (EDT)

Don't know if it's what you're after, but I usually use the GeoLocator tool from Commons: http://tools.freeside.sk/geolocator/geolocator.html
Sam Wilson ( TalkContribs ) … 19:49, 28 May 2012 (EDT)

GeoLocator looks interesting and has been bookmarked for further inspection, but ACME mapper won't load. Maybe Firefox has issues with it (or vice versa) or maybe it's blocked on an international basis. (I live in the UK but do North American genealogy.) Thanks for comments --goldenoldie 02:29, 29 May 2012 (EDT)


I'm a pure Firefox guy - works fine there.... --jrm03063 16:51, 29 May 2012 (EDT)

Topoquest www.topoquest.com is a very good topographic resource for most of the U.S. and Canada. The coordinates are given on the top of the map after you do a place name search and go to the desired location. Don't overlook Wikipedia either. Most locations have coordinates on the Wikipedia page. Clicking on the coordinates will take you to a wide selection of maps with which you can view the location. I personally prefer cordinates in the DD°MM.MMM format of GPS devices. For coordinate conversions (as well as mapping), check out GPS Coordinate Converter.
For the UK and other areas, as well as North America, you can extract coordinates on Google Maps. Right click the location, and select "What's here?". Coordinates will appear in the search box, as well as in a pop-up box when you mouse over the green arrow. Then cut and paste into Coordinate Converter to get other formats. — Parsa 21:45, 6 June 2012 (EDT)


WeRelate is currently in beta [6 June 2012]

I notice the statement on the front page about WeRelate being in beta. I agree that this probably is a good description of the current state of the website, but it is now clearly the biggest free wiki genealogy website, has over 2m people included and is growing fast. I notice person pages here get very high hit rates on google, an important measure of how important the site is becoming to the web.

Two questions please: first, when should we aim to move to full release? I suggest we need to do this before he site really catches alight, as I think it will. Something like ballpark 100m person pages sounds about right because this is the level where new people joining start to have a good chance that one of their relatives is already documented. Do you know when that will be at current rates of growth?

Second, what is necessary to complete in order to move out of beta? Is there a list anywhere, or should we start to create a list?

Thanks AndrewRT 17:01, 27 May 2012 (EDT)

I'm not an admin and have no idea how many of these 'suggestions' are required to come out of beta, but have you seen this list? WeRelate:Suggestions
There is a LOT here that should be implemented before a rush of newcomers arrive!! I would love to see this list have another col with date when it's accomplished. Just need to see that some progress is being made. --Janiejac 17:32, 27 May 2012 (EDT)
I am sure that Dallan will respond. The last that I recall was to make WeRelate easier for new users, update the source citations and update the help files. --Beth 22:18, 27 May 2012 (EDT)
Easier for new users - I'm all in favour and was pleased to see advances in this several months ago (such as listing recently selected sources when you try to add a source to a page). However, I have lost some of that functionality. I'm not sure if it is because I have upgraded to IE 9 or if it is because I block some sites. If it is because of IE 9, I would encourage that this be resolved before moving out of beta, as it is a significant user-friendliness issue. Of course, it is always a challenge to keep up with browser changes, but it appears that IE 9 introduced a lot of change.
Another task for moving out of beta would be cleanup of some of the garbage data. I'm not talking about the research done by individuals on their recent ancestors; I'm talking about the garbage that has been downloaded from Ancestral File, OneWorldTree and similar repositories and then uploaded to WeRelate, where multiple families are intertwined as one. I cleanup as I go, but there are massive amounts of poor quality data that could easily turn off newcomers, and provide misleading examples of sound genealogy practice for the novice. Any ideas on how to tackle this? I've thought of reports to identify nonsense relationships, and/or going through some solid reference books and cleaning up any records already in WeRelate to match the source books (acknowledging the possibility of more recent research). Someone is already using Savage (early New England settlers) this way. This is a really big task. --DataAnalyst 22:58, 27 May 2012 (EDT)
I think worrying about data quality should not be a criteria for leaving beta. For one thing, beta is a measure of software stability, whereas data improvement will be a never-ending task (genealogy is never done). Second, there is no policy requiring sources, so it seems kind of hard to imagine what level of quality can be expected/demanded? If pages without sources are allowed, how do you set a criteria for leaving beta? And while most of the garbage data is old, I just spent that last week cleaning up up a colonial family loaded by GEDCOM a short two weeks ago with no sources, partial dates (years only), and many errors. Since garbage data is still coming in, beta would never end.
I would like to see beta end as I believe the data model and software seems to get the basic job done. There will never be a time when there aren't enhancements needed, so deciding the exact time is somewhat arbitrary, but the tag "beta" could be sending the wrong message as much as garbage data. The biggest change I would expect from the end of beta would be a more formal release procedure, possibly with staging in the Sandbox before release? --Jrich 00:33, 28 May 2012 (EDT)

For me the main requirements to get out of beta and to start promoting the website more are for us to get to the point so that if the user base were to increase dramatically over a short period of time, we wouldn't (1) be overloaded with support questions, (2) have newbies make changes that decrease quality and/or turn off existing users, or (3) have a lot of people upload material and then not return. I want to address these issues, but it's become clear that it's a bigger job than I can do on my own. We're going to need more volunteers on administration (and cleanup?) activities as well as helping out with the coding. I'll be issuing a call for volunteers to help with the coding this weekend.--Dallan 00:59, 6 June 2012 (EDT)


Sounds great! Grad school starts for me in mid-August, so let's hurry and get started! :) - Jdfoote1 19:36, 6 June 2012 (EDT)

Person & Main namespace [18 June 2012]

One think that I do think we should do before moving out of beta - although I appreciate it is a massive job - is to move all entries in the "Person" namespace to the main namespace. Having the main thing we do in a separate namespace doesn't make sense to me - it's a bit like all Articles on Wikipedia being named "Article:Something" rather than just "Something". At the moment the main namespace is filled with just a few random project pages - suggest these are moved to "Project:" or something like that. Rather than put this on the suggestion page I wanted to float it here first to see the response. AndrewRT 19:21, 28 May 2012 (EDT)

I think having people in the mainspace does make sense, but I've no idea if we're just far too far beyond being able to change to that now. Any ideas of the technical feasibility? I assume we'd have redirects from the Person NS? It may be able to be done by just changing the names of the namespaces, and doing a URL-rewrite to effect the redirects. Not sure though. — Sam Wilson ( TalkContribs ) … 03:33, 18 June 2012 (EDT)
I suspect that it's technically problematic. I'll bet that "Ordinary" namespace pages are effectively vanilla wiki pages. A vanilla page would then have to somehow get back vanilla processing under some other namespace name. From my point of view - if this is the worst thing you can think of - I think we're doing pretty well! --jrm03063 14:06, 18 June 2012 (EDT)

The Genealogy Contest is Back [1 June 2012]

I'm sorry I had to suspend the weekly contest - I was on a family medical leave from genealogy. But I've brought the contest back and it was inspired this week by watching Kevin Costner's TV miniseries the Hatfields and McCoys. Did anyone else see the show? My family lived very near to these families and I have a distant cousin who was in one of the "round-ups" (Person:Moses Christian (2)). So I was very interested. But I see the show got very high ratings. I imagine there will be a lot more interest in the genealogy of these people in the coming months. Thanks everyone for being patient while I was on leave : ) ~ Catherine --cthrnvl 15:19, 1 June 2012 (EDT)


Cleaning data [15 June 2012]

Hi,

I am trying to cleanup data to conform to WeRelates data standards and was wondering if there is a step by step instruction sheet how to achieve this somewhere?

I need to change the surname/given name of individuals in a family and wish to ensure that all records are correctly updated (i.e. no loss of data)

An example of what I am trying to clean up is found here:

Family:--_--_Lindsey_and_Esther_Kemp_(2)

Need to change [--?--] to Unknown.--nastrond 21:45, 6 June 2012 (EDT)

That's actually pretty straightforward, in two steps. First, click "Edit," go in, and manually change "[--?--]" to "Unknown," then save the page. "Unknown" is a word, as opposed to a string of punctuation, and the wiki software can deal with it. Second, click on "Rename" and change the page title to "Family:Unknown Lindsey and Esther Kemp". (Don't worry about the parenthetical number -- the software will update that.) And that's it. It'll take an hour or two for the indexing routine to catch up to the changes.

I assume this page arrived via a GEDCOM upload? I've always made a point of checking every single page in a GEDCOM after I import, doing clean-up, checking for errors, tweaking formatting, and so on. (I wish more people did that; there would be less garbage left strewn around the site.) But also, you might want to go back through your database in your desktop software and do a global replacement on all the names with punctuation strings and change them to "Unknown," so you won't have to worry about it after importing. --MikeTalk 09:33, 14 June 2012 (EDT)

Thank's Mike. Thought it would be very simple and I just needed this information to clean up that data. Perhaps this should be in a FAQ for other newbie members? I have been using this method for recording unknown names in my desktop software for over 15 years. I have a genealogy database of over 100K individuals and growing that I would like to sync with WeRelate on an ongoing basis, however the current upload, merge, cleanup process makes this too cumbersome. --nastrond 18:39, 14 June 2012 (EDT)

Proposal to remove quality from source citation fields [26 June 2012]

The discussion around one of the suggestions has led to a proposal to remove the "Quality" field from source citations. Quality is part of the GEDCOM 5.5 standard, which is why it's currently included, but it is fairly subjective, which may not make it appropriate for WeRelate. I'm thinking of removing it. What do people think?--Dallan 12:34, 17 June 2012 (EDT)

Remove it. I do use it sometimes, because it's there, but really I use it as a sort of "is this an official record?" type of thing, which is anyway perfectly apparent from whatever the source is. Simpler is better; I support getting rid of it. — Sam Wilson ( TalkContribs ) … 03:17, 18 June 2012 (EDT)
If folks used it correctly... it would be nice to distinguish between original and derived sources. If you do a search for "gedcom primary quality" on Google, pretty much all you get are WeRelate pages. — Parsa 14:38, 24 June 2012 (EDT)
I support the removal of the "Quality" field. If the quality is relevant to your conclusion; add this information to the citation field or narrative.--Beth 18:36, 24 June 2012 (EDT)
I mainly use "Quality" to flag serious problems or inconsistencies in the source (ie to downgrade an "original" or "archival" source. For example the public records for Allendale Township, Ottawa County, Michigan in the late 1800s contain many errors (wrong names/birth dates/death dates). They were obviously recorded well after the events by someone who was in a hurry to compile a document to meet some statutory filing requirement (see Samuel Arthur Wilson where the records confuse two brothers rather badly).--Jhamstra 11:36, 25 June 2012 (EDT)
Remove it. It's not used that much and when it is, it's often misused. As an example, I'm looking at a page Person:Robert Rose (13) which calls Torrey a primary quality source when it is no better than tertiary, Torrey having gleaned the date primarily from secondary sources and only when he had good cause flagging dubious data. On the other hand, Great Migration sketches are secondary sources, but of excellent quality since they are, for the most part, well sourced and traceable back to primary sources (often in multiple steps).--jaques1724 08:04, 26 June 2012 (EDT)

Site is back [18 June 2012]

The search machine went down today, and for various reasons it took longer than it should have to bring up a new machine in its place. But a new search machine is up and running now, and things should be back to normal (and I'm going to bed. :-)--Dallan 00:41, 18 June 2012 (EDT)

Thank you Dallan. --Jrich 01:14, 18 June 2012 (EDT)
Yes, thanks! — Sam Wilson ( TalkContribs ) … 03:11, 18 June 2012 (EDT)

Mythological pages? [23 June 2012]

Firstly, the page, Odin Woutan seems largely mythological. Odin is listed as the father of Skjold, a page with a corrupted Wikipedia introduction. Skjold's wife, Gefion, has a page describing impossible events. A glance through the pages in the near vincinity shows that many these pages may have little concrete evidence, and deletion might be advised.

In addition, it seems the lines are in fact duplicated. Skjold , King of Denmark is listed as a valid continuation of Odin's line; this line continues into modern day. As if this weren't enough, even this line is duplicated; Valdar seems similar to Valdar Hroarsson. These duplications should be resolved, and some of the less backed up information should be deleted.

I'm new here, and this discussion does not seem to be about "one page". However, if this is the wrong location, please point it out. --Dree12 15:28, 20 June 2012 (EDT)


The principle you're discussing relates to much more than one page - this is the right place!...We try not to host purely mythological content. I agree that the example you give is substantially mythological (and is troubled at that) - but there's at least an outside chance that there is a tiny historical basis there. We also try to limit pages to the years 700 AD and on. Earlier content, particularly if it is associated with wikipedia biographical (or semi-biographical) pages is tolerated for a couple of reasons:
  • We're not really working out there - we're just trying to put existing biographical pages into rough context.
  • Such pages also serve as a sort of fly paper - it helps us to be more quickly aware that someone is trying to work in areas where the basis for historical genealogy is pretty weak.
While I agree that the page you note is pretty weak, the effort to delete really baseless content (stuff that went back BEFORE ODIN!) has already discarded many hundreds of pages. I worked quite a while on a project I called the Tree Segment Delete Project. The idea being that we don't want to just delete individual bad pages when we find them. Instead, we want to get rid of the entire bad tree segments - which can be many, many pages. My strategy was to start at really bad pages and work outwards in all directions, labeling every person and family page that I encountered with the project template - until I ran into reasonable content. After working through a given general area a number of times - such that I figured I'ld marked all the reachable bad content and found the edges of the segment - I would start to actually delete the content. The tree segment delete project template served to prevent me from losing my way and cutting lose bad content while I was deleting individual pages - since I could always go back to the template and see what linked there. In that way, I was certain to eventually delete everything that I had marked.
If this is the sort of project that you're interested in, we can try to put together an approach to finding and eliminating content that carries on beyond my early efforts. If the particular area you note is one of your pet peeves - perhaps you can replicate my technique to mark the bad stuff - and I can come through and conduct the delete when you think it's ready? --jrm03063 16:59, 20 June 2012 (EDT)

I went ahead and merged the first line I was talking about, which was a straight duplicate. I still have a problem with Njord being a son of Odin, because Njord is the father of Frejya, Odin's supposed "wife". This means that either Njord was not a son of Odin or Odin married his own granddaughter, unlikely to be 13 years after as the page states. In fact, if we assume the page is correct, Njord should have been one year older than Odin, obviously impossible if he is to be his son. I propose that if we are to keep Njord, he is assigned one generation above Odin rather than below (which raises the problem you raised: before Odin).

Also concerning: Vana is listed as marrying her brother, Svegdi. While not impossible in this time, this is highly unlikely and has no support: Wikipedia states that Vana was probably not even from the same house, let alone same parentage. --Dree12 19:59, 20 June 2012 (EDT)


Your concerns are moot since this page needs eventual deletion. JRM has noted that spurious genealogy tied to it needs to be deleted entirely with it, but needs to be first linked to his template or something like it to systematically avoid leaving orphaned junk. There is no legitimate source for it and the policy of WeRelate is to ban mythological and biblical genealogies.--Scot 12:04, 23 June 2012 (EDT)
We need not be quite so absolute. I agree that we're in 90+% mythological territory and certainly before the 700 AD cut-off - but you can see by the number of watchers that a lot of people upload this sort of stuff. I'm no expert on the Scandinavian lines, but they start with pretty good historical basis and then become incrementally less reliable as you move back - so it's hard to pick a spot to stop. When I did my original work - I decided that "Odin" was a good ending/exclamation mark - a pretty clear indication that all the reasonable history has left the building. As to keeping pages back this far, I think a fair argument can be made to do so - in limited circumstances. We've got some good fronting WP pages that are clear on the limited amount of historical content associated with these characters. We could also do something like what we have for Cleopatra (yes, THAT Cleopatra!). Perhaps we build a template noting that the content is both outside the ordinary WeRelate historical scope and predominantly mythological. I think it's wise for us to serve up WP biographical and semi-biographical pages for any figure that has even a fraction of historical basis - to serve as a sort of fly paper for stuff that really doesn't belong. --jrm03063 09:23, 26 June 2012 (EDT)

Updated research guides for Ohio and Scotland [6 July 2012]

I added a new online resource for Ohio published by the Ohio Historical Society. I also added a new database for Scotland. This searchable database provides images of over 700 Post Office directories for Scotland from 1773 to 1911. If you are interested in a particular area you may download the entire directory. See Category:Research guides.--Beth 09:58, 6 July 2012 (EDT)


Issues with photos not appearing! [7 July 2012]

Hi everyone,

I just added my massive family tree to WeRelate, and am working on getting everyone situated. I like to have photographs for as many family members as possible. These photographs are scans of originals passed down through our family.

Part of the time, however, my uploaded photos - while they show up in a search for the subject and also show as the checked primary image on someone's person page in the edit screen, don't actually show up on the person pages?

Case in point is Isabel Rose Peters linked here: http://www.werelate.org/wiki/Person:Isabel_Peters_%281%29

She has a photograph linked to her person page and set up as her primary photo, but it doesn't show, and there also isn't a 'Photo Gallery' in her profile.

Help!--Zoesdare 11:26, 7 July 2012 (EDT)

If you do a search of Images for keywords Isabel Peters Rodenberger, the name of the file returned is "2 Isabel Peters Rodenberger 1947 corrected.jpg". Using that name instead of what was entered seems to have fixed the problem. --Jrich 11:35, 7 July 2012 (EDT)

Added research guide for Iceland [11 July 2012]

I created the Iceland Research Guide. See the link for free census images. If you have any additional information please add to the page. Thanks. --Beth 11:26, 11 July 2012 (EDT)


Added link to Kentucky Research Guide [11 July 2012]

For those of you who have research interests in Kentucky, I added a link to Littel's 5 volumes on The Statutes of Kentucky. See Kentucky Research Guide. --Beth 12:26, 11 July 2012 (EDT)


Research guides [28 July 2012]

I'm thinking it would be well worth having a wiki-based directory of genealogical sources relating to a particular place - similar to GENUKI but on an open content wiki. My question - is this within the scope of werelate and, if so, should it be linked to the Place: namespace and encouraged? AndrewRT 18:57, 22 July 2012 (EDT)

That is precisely what we have in mind for place pages! Sources, tips, practices, etc. - anything that's specific to doing the genealogy of a particular place - absolutely belongs on the related place page. --jrm03063 16:57, 23 July 2012 (EDT)

Andrew, if you have a better method; I am definitely a supporter. By the way we just added updates to the Australia resarch guides. --Beth 19:51, 22 July 2012 (EDT)


I have been adding a brief research guide to all the Ontario, Canada pages. It's a template named "Ontario Archives". More recently I have started a series of "local provisions" for county-level material within Ontario. Research guides as "articles" are not easily found by the new arrivals to WR. --goldenoldie 02:14, 23 July 2012 (EDT)

Hmmmm. The point of WeRelate place pages isn't really to nail down and describe the place, but to bring together place-specific genealogical resources (the former is a role that we should reserve to wikipedia). But WeRelate place pages also include the location hierarchy - so I'm not sure it makes sense to run to all the included places with that, or whether you just add that as a resource at the level to which it corresponds (do you put it on just the page for Ontario - or do you add it to every place in Ontario). As I think about this - I'm struck that it would be slick if place pages were defined with a resource list (a bullet list of items, probably often links) - and when they're displayed - you would (or could) get a combined resource list for the page in question as well as those of the enclosing place pages. Gotta add a suggestion on this one... --jrm03063 09:46, 23 July 2012 (EDT)
I have been letting these comments roll 'round in my head for a few days before writing more. In examining the Ontario pages I have found many with Wikipedia sources of various lengths that, in whole or in part, do not provide facts of genealogical value to our place pages: pages for a place described as a township with a description of the town of the same name, or vice versa; place pages for tiny hamlets which have taken a Wikipedia redirect to the municipality where they are located and the quote never mentions the hamlet; or, worst of all, 21st century facts such as the recent success of the local hockey team. These are the introductory descriptions which are being replaced by (1) the geographical and political links between the place in question and those surrounding it, and (2) if I can find it, something historical: when it was settled, names of first settlers, the industry that kept it running (though I tend to omit farming from that).
Let's distinguish between what they are and what they should be. Place pages, in general, do have an extract of the Wikipedia (WP) introduction at the top - when the WeRelate (WR) place page and a WP page more or less strictly overlap. The WP extract is maintained automatically, and serves the useful purpose of a sentence or two on what and where the place is. If you edit such pages, you'll see that the content comes from a template. The WP content also makes it clear that there IS a backing WP page, so information of a non-genealogical nature has a better place to be. It also serves those who really may want general information on the place. So the WP extract, appearing in WR, is all about striking a balance between putting a few general facts on a place page while avoiding a waste of time and effort duplicating things already done on WP. Examples I know of, that better show this balance, are for cemeteries such as Mount Auburn in Cambridge, MA and Fort Custer National Cemetery in Kalamazoo, MI. Those places have the WP extract but also have links to resources that are more genealogically oriented.
To get the various resource tips, at various levels of political subdivision, you go up by "Located In" link or back down one of the "Contained Places" links.
Of course, there will be assignments of WP extracts to a too-small enclosing place or other sorts of errors. It's a wiki - so we fix it when we find it. Sometimes that means you drop the WP template reference - other times it means moving it to a spot where it's more correct. In still others you may find that there really is a better choice for a WP place page - so fine - use that. --jrm03063 16:37, 28 July 2012 (EDT)
Pages for counties, townships and the new municipalities (conglomerations of townships formed in the past 40 years) all have links to one of a series of maps produced just after WW2 and sketchmaps showing where all the old townships were.
The Ontario Archives template is on every page--no point making a template that just refers to the province's page. It is an attempt to guide anyone finding him/herself with an ancestor for whom Ontario was off the family's beaten track to sources which might expand the data on that ancestor and the new family members that might now appear. The template could be a link rather than a complete article, but people might be less likely to refer to it.
I wonder if that's a good idea? There's no reason to expect that pages at the level of a Village or Hamlet will directly embed information on how to use a Provincial or National level resource. If we did - I would think we would want to do it automatically - by somehow presenting information all the way up this list of enclosing place pages from the page in question. I really don't think we would want to be burdened by a template that has to be maintained by hand-editing. Hmmmm.... --jrm03063 16:37, 28 July 2012 (EDT)
The "local provision" templates are more difficult to produce. If there is no online mention of the source, it is not easy to find that source from a distance (and that leaves me out). However, another WR member who started introducing sources for one township is now building up sources for the whole of that county.
Because of privacy laws, Ontario has only a limited provision of vital statistics (less that 50 years for births) and census listings (7 decades). The template was built with these problems in mind.

Suggestions for searches and family pages [4 March 2013]

When you add a person or children, the list of possible matches could be more compressed so it would be easier to check. Sometimes there are thousands of matches which requires more scrolling and clicking than I have patience for. A display more like the new watchlist would be nice.

Also, on the family page, it would be nice to show the spouses of the children.

I'm a new participant here, so forgive me if this is out of line.--KayS 15:17, 27 July 2012 (EDT)


This is a fine place to start a discussion of any sort, though it might transition elsewhere. For example, if it became a real suggestion, there's a place for that. Also, if it's support - there's a different sort of place for that (and we administrators try particularly hard to respond quickly).--jrm03063 11:32, 31 July 2012 (EDT)

Announcing a new name-variants database [13 September 2012]

We're now using a different approach for finding name-variants during searches, one that I think scales better than the previous approach, and which is easier to make publicly available. This new approach replaces the Related names on the Givenname and Surname pages. I've copied all of the variants that people had added to those pages into the new database.

You can find out more about the new approach here. The new approach is more generous in including variant names in searches than the old one was. If you find that very different names are showing up in your searches, you can improve the search function for you and everyone else by removing the very different names from the database. A link taking you to the variant-names project homepage appears in the lower-right corner of the results page whenever you search for people or families. The names that you add or remove will take effect immediately.

  • I am curious about why you have not accommodated the inclusion of supporting information for name variants, which was at least marginally supported in the previous, poorly scaling solution. I would speculate that perhaps you want to get out of the business of building up a potentially redundant name origins information space and rather focus on the core genealogy content, which is OK, but it would be useful to know if that is or is not the case ... rather than my just speculating. Thanks. --ceyockey 18:26, 27 January 2012 (EST)
The primary goal is to create a resource that other websites can use, and also to correct some problems with our current solution:
  • if you add name X to name Y, you also have to add name Y to name X (the new system does that automatically),
  • we didn't have a good solution for names that didn't have a wiki page (the new system includes twice as many names, and has a good solution for names that aren't in the system),
  • the current solution left out a lot of good name variants (the new solution is overly-generous, but it's easier to remove names than to add them).
I'm hoping that by allowing people to edit name variants in a simple form and encouraging other websites to use the database, this will encourage contributions from people who might be intimidated by a wiki and who wouldn't use WeRelate for their family history. People would still have to register at WeRelate to edit name variants though. And yes, I wouldn't mind if someone like FamilySearch took over the variant-names database so that we could focus more on the core genealogy content.
There are two things we don't have in the new implementation that I wasn't sure if I should add back in: sources for variant names, and the ability to watch for changes to a specific name. They were extra work to add to the new implementation, so I thought I would omit them and see if people missed them.
  • Do people think the source information is worthwhile - should I add it back in? It would make the forms longer vertically, because instead of multiple columns we'd probably have one variant per row, followed by an input box for the source.
    • I think that providing links to wikipedia for surnames would be a useful adjunct; if this could be done in a semi-automated manner, all the better. Wikipedia:Wikipedia:WikiProject Anthroponymy has within its scope the composition and enhancement of articles about surnames. Most surname pages here do not look to address origin information. I think most relevant for genealogy studies is how a surname changed within a line of descent, while surname origin information tends toward the population level ... and population level finds do not always translate to what happened in a particular line. Enhancing the ability for WeRelate to help people to track such lineal changes would be useful; such research findings taken in the aggregate would contribute to the overall body of work related to specific one-name studies. --ceyockey 18:43, 29 January 2012 (EST)
  • Similarly, is it important to have the ability to watch for changes to specific names?
    • Not in my opinion. --ceyockey 18:43, 29 January 2012 (EST)
--Dallan 11:27, 29 January 2012 (EST)

The database is being given away freely to any software vendor or website that wants to use it. The overall goal is that we'll eventually have better search experiences wherever we go on the Web. I hope that people get involved in this project and fine-tune the variants that appear for the names that they search frequently. Thank you!

Now that the new database is in place, the next questions are:

For some names, I would add the wikipedia entry giving the name's origin merely as a vague way of suggesting a preferred spelling for a family of variants. I don't have a problem with deleting them. It seems that people do tend to use the spelling of the source they are looking at, and have long wondered if there might be potential benefits in readability from guiding them toward preferred spellings (at least, say, prior to 1830, when spelling was largely phonetic). But with this better searching, it probably matters less. --Jrich 15:14, 27 January 2012 (EST)
That's what I'm hoping -- that this database would tie the variant spellings together for searches so people could use the spelling as it appeared on the source.--Dallan 11:27, 29 January 2012 (EST)
That only works for the first one in. At least prior to 1830, 1840, 1850 when spelling somewhat became standardized, every (primary) source is likely to have a different spelling. Secondary sources seem to chose the spellings that the author liked best. Have to be careful with a philosophy like that, it could encourage a bunch of meaningless renames. Better answer is to faithfully use the source's spelling in the abstract/transcription of the source, but use a more standardized spelling in the name fields/title. I.e., Elizabeth, never Elisabeth? But standardized is somewhat subjective, so unless WeRelate provides such an authority, again meaningless renames such as Ann for Anne, or vice versa. --Jrich 12:08, 29 January 2012 (EST)
  • What do we do with the Surname namespace? I'm wondering if we should delete all surnames that haven't been human-edited, or that don't link to any existing pages. We should at least remove the related names from any surnames pages that we don't delete.--Dallan 14:17, 27 January 2012 (EST)

Given names: I did a quick spot check. I see problems with common nicknames not being included. First one I checked, "Lindy"/"Malinda", neither includes the alternate. Then I checked "Ann" which correctly includes such variants as Nan and Nancy, but includes a long list of names that have nothing to do with Ann. There seems to be much emphasis on computer algorithms and not actual usage. While I agree that it is excessive to require a "source" for each entry, it would be very helpful to include space for discussion of certain variants. Many are specific to place or culture/ethnicity. It is usually helpful to have lists of translations from one language to the next. Also, I often wonder how certain names came into common usage and a place to record discussions of these would be useful to other curious souls. If this will not be available with the new system or if it will possibly transfer into new hands, I would like to see the given name pages stay for these purposes. --Judy (jlanoux) 12:38, 29 January 2012 (EST)

Surnames: Agree with copying only human-edited changes to the new database. As with given names, I would like to see surname pages remain as a place for discussion about origins and such as well as for pointers to family projects. However, it would be nice if there could be one master page and not one for each variant spelling. I assume the next search thingy would turn up the page no matter which someone searched on. This would probably best be done by humans. So maybe you could remove the pages which have never been edited. Anyone could create new if they want to have a page for their content. A link to the new variant page would be handy. --Judy (jlanoux) 12:38, 29 January 2012 (EST)


The nicknames were added by hand by me. I added the ones that were on WeRelate already, as well as any additional ones I could think of. I knew about Ann/Nancy, but not about Lindy/Malinda. This is where I hope that the community will help.

To start, the names database is going to look like the result of a computer algorithm because 90% of the variants came from a computer. The algorithm has been shown to be better than Soundex, and it's better than the algorithm used to generate the variants on our Givenname and Surname pages, but it's still just a computer. I'm hoping that people who really know the names a lot better than I do will remove the spurious variants.

How about instead of a source for each name, I'll add a discussion area to the bottom of each name. I'll populate it initially with a list of variants that have been human-generated, from WeRelate or BehindTheName.

Automated links to Wikipedia surname pages and developing an authority for names seem like good ideas, but I think better as suggestions for the future.

Unless someone speaks up for them, I'll delete all of the Givenname pages, and those Surname pages that don't have any text on them.--Dallan 11:13, 31 January 2012 (EST)


Third para from the bottom -- I agree wholeheartedly. I'm not sure that I could come up with a source for variants of names I have been following for many years. They are just familiar, from many sources. But availability of discussion areas seems very important, not only for working on the database itself, but for other information. Of one line, Spelling X seems to stabilize in those who moved west. Spelling Y stabilized among those who moved south. Another line, the spelling stabilized early across the pond, and seems to have stayed the same here. Another line, spelling wobbled everywhere, and fairly late. These can be useful discussions. --LindaS 19:30, 31 January 2012 (EST)


Question: on the Variant Names search results page under Computer Variants, there are two checkboxes to the left of each name. If one box is for delete and one is for confirm, which box is which? It's not clear. I've seen some I would definitely like to confirm, but don't want to check the wrong box!--LulaBelle 10:29, 10 September 2012 (EDT)

Sorry it's not clear. The checkbox on the left is to remove the name; the checkbox on the right is to confirm it.--Dallan 20:33, 14 September 2012 (EDT)

Fair Use [14 September 2012]

It's a long story but my grandfather's siblings were separated and put in different orphanages in England. The descendants of these children are now living in many different countries around the world. I've managed to trace the family back to the late 1700s. I'm not getting any younger and I'm desperate to find a place to record what I've found out about the family tree which will be freely accessible to family members for generations to come. WeRelate seems to "fit the bill" (free and accessible) but I have a BIG problem!! Genealogy experts always seem to stress that one must not rely on indexes, transcriptions, etc. and one must always use the original document as "proof" of a fact. So I've "collected" a lot of original documents from various sources (including FamilySearch, Ancestry, other websites, etc) It's taken me a while, but I think I've figured out a way to reduce the size of these original documents to 150 KB limit required by WeRelate. Because these documents may not always be available on the Internet or cost $$ (which I've already spent to obtain!), I want to upload them to WeRelate for future generations of my family members to look at. Is what I want to do considered "fair use"?? I think that I understand why genealogy sites have copyright notices that warn that their documents cannot be "reproduced" and that's because they don't want their data/documents "mined" and uploaded en masse to another site that might charge/make money from their data. But surely what I want to do is not covered by that copyright?? I'm just one person wanting to leave a legacy. So I'm seeking advice. How can I upload the original documents that I have to WeRelate without breaking any copyright laws? Thanks in advance for your assistance/advice :-)--Bobby007 09:58, 31 July 2012 (EDT)

I appreciate your concerns - WeRelate definitely is here to help with exactly this sort of challenge. We all want to have our work saved for the next generation - but it also often happens that interest in genealogy skips a generation or two - and we might have "logged off" before that next interested party turns up! Copyright issues are going to depend on the item in question. Can you break down the places where you obtained the scans, and what sorts of documents you have scans for? We should be able to help... --jrm03063 10:40, 31 July 2012 (EDT)

Yeah, Jrm03063 is right, it really depends on the particular documents. I think we could have some better guidelines in the help pages about specific classes of documents that are or are not allowed here. For example, my understanding of BMD certificates from the UK General Registry is that they are covered by Crown copyright (according to the National Archives website, at any rate). I made this template a while ago, to put on these docs:
This material is covered by Crown copyright and is published here in accordance with the copyright guidance note regarding the copying of BMD certificates issued by the National Archives, which states that "copyright in the layout of certificates is owned by the Crown. The Crown does not assert any rights of ownership in the contents of the forms." and that users (i.e. WeRelate, in this case) "are authorised to reproduce the layout of the form in any format including on the web, in films and in print."
For copyright questions in general, I usually ask over at Wikimedia Commons, where there are thousands of people dealing with these sorts of questions all the time. The other place you could consider uploading files to is the Internet Archive.
Oh, and by the way, there is no 150KB limit for files here. You are free to upload whatever sized files you like.
Sam Wilson ( TalkContribs ) … 22:06, 1 August 2012 (EDT)
Sticking my oar in here, Bobby -- I don't have as much experience with Crown copyright as I do with copyright laws in the U.S., but I know that the Crown makes a distinction between the form/appearance of a document and the actual content. For this reason, if you're not sure of your right (or not) to reproduce something, just quote the full content and then supply a full source citation. For most of us, most of the time, this is perfectly adequate. Of course, if something is taken from a published collection of public documents, then one must trust the competence and clerical skill of the editor and publisher. Whereas, if you're posting informatiion taken from an actual document that you have in hand, then the rest of us only have to trust you. It's useful, perhaps, to include a note in that case: "Original document seen." Or something similar that alerts the later reader that what he sees is only a single step away from the original, not three or four steps.
And yes, we need to find a legal source or a sufficiently knowledgeable person to supply more nuanced information about copyright laws and public documents outside the U.S. I'm afraid that most of us at WeRelate live in the U.S., even when we're researching elsewhere, and help pages here are not what they should be for non-U.S. issues. --MikeTalk 17:41, 2 August 2012 (EDT)

Not really sure what I'm doing --- I hope that this comment ends up in response to the "Fair Use" thread in the "Watercooler" :-)

First let me apologize for not replying sooner but I didn't get any notice that there was a reply to my original post.

And since, as I type this, I can't see what others said in response to my original post, I don't know the person's name but s/he said that there is no limit to the size of photos that can be uploaded. But in the "Images Tutorial", "Preparing an Image" section it says:

2. If you can, please limit your images to no more than 150 kb in size.

And there are references throughout the Images Tutorial that refer to the maximum size of an image that should be uploaded.

Secondly, the images that I want to upload are original documents that I found on the Internet (on sites such as Ancestry, familysearch, etc. etc.). They include censuses, birth, death, marriage documents as well as photographs of people and places. It would take me FOREVER to transcribe each document and I sure as heck don't want to do that!! And, as I said in my original post, genealogists always say to rely on the original document, not a transcription. So I want to upload the original documents to my tree here on WeRelate.

Can I do that??--Bobby007 16:54, 1 September 2012 (EDT)


OK here are examples of the types of documents (and where I found them) that I want to upload from my computer to my tree on WeRelate:

1. a scan that I did of a British birth certificate. The original was mailed to me by my second cousin in England. She paid the fee and ordered it from the British government.

If you are referring to the GRO certificates, you should be ok. A note was added to the source page a while back indicating that they can be uploaded here.

2. a picture of a tombstone that I found on the free site "Find a Grave" [3] and saved to my hard drive

Don't know, but you could add a link to the site.

3. a photograph of one of my ancestors that I found on a public tree on Ancestry and saved to my hard drive

Ask the person who originally uploaded the photo if it is ok to reproduce it on other sites or if they are using a particular license.

4. a death certificate that I found on a free website called "Seeking Michigan" [4] and saved to my hard drive

See if the website gives any restrictions. Might be able to just link to the item.

5. a Canadian census document that I found on a free website called "Automated Genealogy" [5] and saved to my hard drive.

Same as above.

6. a scan of a marriage certificate of an ancestor that I found when I googled the ancestor's name. It was posted to a public website (similar to WeRelate) by a distant cousin who I don't know and I saved the document to my hard drive.

Same as above. Might want to find out the source of the certificate.

7. an excerpt from a book that I found on a free site called Archive[6] I copied the part of the book that was about my ancestor and saved it to my hard drive. Note: some of these books have also been uploaded to Ancestry.

Assuming the book is out of copyright, it should be ok to reproduce.

8. a marriage certificate that I found on familysearch [7] and I saved to my hard drive. I also have copies of documents that cousins mailed to me (and I scanned to my hard drive) that they found when they went to the LDS Family Search Centres.

I generally avoid reproducing their images here. Instead I will just give a good reference to make it easy to find it. Obviously, it may not be adequate for people who want to see it themselves, but hopefully if I'm doing good research they will trust it. I don't know if they would complain about their images being reproduced on this site.

These are just some examples of the types of documents that I have and where I found them. The vast majority of the documents that I have on my hard drive are ones that I found on Ancestry (I have a monthly worldwide subscription).

Same as with the FamilySearch images, I don't reproduce Ancestry.com images here. Instead I provide the best reference that I can. Moverton 14:56, 2 September 2012 (EDT)

I hope that this helps to explain the types of documents that I want to upload to WeRelate.--Bobby007 19:27, 1 September 2012 (EDT)


I think that this is a real need. In fact, just a few days ago, I put up a suggestion on the suggestion page to improve the help in this area. I think there are many of us in this boat, and having clear guidelines about some common image types would be very, very helpful. - Jdfoote1 21:20, 1 September 2012 (EDT)

Thanks for your reply about whether I can upload the documents. Sadly, all of the sites where I found the documents have the same confusing mumbo-jumbo as here, explaining (NOT!) what I can and cannot do with the documents that I found.

I couldn't figure out a way to add a comment to your suggestion, jdfoote, so I'll put them here.

I agree!! What is required is simple and clear instructions. But I even have a question about what you put in your suggested format LOL! What is the definition of "public domain"??

I'm beginning to think what I really want doesn't exist!

I just want a place to record all the information and upload all the documents that I found after years of research on my family tree. Yes--I've given my immediate family the info on disks/DVDs but probably in the not too distant future, there won't even be a way to read those disks/DVDs!!!

So the internet (which I assume will be around for a few generations yet) seemed the logical choice. I picked this site because I'm assuming that it will be open and available free to the public as long as the internet exists?? But I don't want to spend hours creating "sources and citations" -- who the heck, other than professional genealogists, understands how to do that anyway, hehehe! It seems to me that if you have an original document to look at, who cares where it came from!

Sigh! I think that I give up!!--Bobby007 14:11, 4 September 2012 (EDT)


Hold on there! I wouldn't give up as yet. It's true, that the rules are going to be different for different sorts of things, and copyright law was not created for the purpose of making lives of Genealogists simpler. Still, I think you can take a few steps:

  • If you absolutely can't bring yourself to work on the material any more - get a couple of thumb drives and copy it to each (I have more faith in thumb drives than other media that will age very quickly). Give a thumb drive to each of two relatives you trust - and tell them it's a backup of your work (it's not officially a copy for their use - it's a backup to protect against your computer being struck by a meteor!).
  • If you can work a little more - then create a couple folders near to where you've got your existing content. Label one - "undecided". Label another "public domain", and label a third "under copyright". Make a copy of everything you've got into "undecided". Then, sift out anything that's a birth, death, or marriage certificate or census record - put them in your "public domain" folder. Pictures from "find a grave" and "ancestry" are copyrighted - so move those to "under copyright". When you don't know what else to move where - stop. Upload all the public record images to werelate (figure out an image naming convention first though - it's easier to rename things on your PC and then upload than it is to establish a good naming system as you go). Delete the file from your "public records" file as you upload them and save it.
  • If you're STILL game - then try to put a list of the names of the files in your "undecided" folder here. If they've got useful names, we should be able to help further sift into public and copyright.
  • "Fair Use" comes in, as a concept, only for those things in your "under copyright" folder. If there's no practical way to get a picture of someone (perhaps they've died), then it's a unique piece of information more apt to be protected for fair use. If you can reduce the resolution of the image, without losing too much information, you're on pretty strong ground. Best of all - if you know where you got the image - you can always ask the owner/contributor if they'll permit use on WeRelate. I've had a lot of "yes" answers over the years, and only one "no" that I remember. Don't be too worried that you'll get a fair use decision wrong, because we're a non-profit and we're generally immune unless someone asserts that they have a copyright to something and we refuse to take timely action to remove it. The key is good faith - if you think someone might be in a position to claim a copyright - name them (as best you can) - when you upload the image. Delete after you upload. Feel free to label the content as, "I NEED HELP FIGURING OUT THE COPYRIGHT".
  • Most of all - don't let the mass of content overwhelm you. You didn't acquire all this at once - you won't sift through it in one shot either. Be satisfied with incremental progress - you may not be around to be thanked for your efforts when someone finally picks up your work - but sooner or later they will. Hang in there! --jrm03063 15:35, 4 September 2012 (EDT)
Jrm03063 gives good advice. The reason you haven't found clear answers is that there are no clear answers. Governments and websites have different rules about using their images. But if you follow Jrm's advice you should be fine.--Dallan 20:33, 14 September 2012 (EDT)

The 'real name' field of the user profile [1 August 2012]

I've seen the 'real name' field associated with an account and the footnote saying it will be used for attribution, but so far I haven't been able to find any place that this field value is actually used. The user id seems to be used everywhere, including the history page, the URL of which is given in an "Authors:" note in GEDCOM export. I'm not anxious to have it be shown any place in particular, but am wondering if it is currently used, or is just an idea that has yet to be materialized. (BTW, the site interface is very nice.) --Robert.shaw 17:39, 1 August 2012 (EDT)


User Profile Nickname Change [5 August 2012]

What happens if I change my nickname. Is is similar to a person page or source page redirect?--jaques1724 15:52, 5 August 2012 (EDT)


Legacy webinar--Wikis for Genealogists--coming up [6 August 2012]

I had a reminder this morning of a Legacy "webinar" on Wednesday, August 8, 2012 2:00 PM - 3:30 PM EDT. The title is Wikis for Genealogists. Just thought I would pass it on if anyone is interested. --goldenoldie 05:17, 6 August 2012 (EDT)


DOB and DOD in earlier couple infoboxes [7 August 2012]

This isnt a major problem, but Ive noticed that the infoboxes for people born before about 1500 do not show the DOBs and DODs. I noticed this on some royal and noble couple before, but I just had this happen as I am working on the Coo/Coe family, ancestors of Robert Coe the immigrant:

http://www.werelate.org/wiki/Person:John_Coo_%287%29

By the infobox, I mean the 'spouse and children' box on the right hand side of the screen. Even after entering the dates they dont show. Is there a reason for this? Its not a big deal but I am curious.--Daniel Maxwell 02:36, 7 August 2012 (EDT)

I'm guessing that it's because the only dates that are in any DOB/DOD fields are "abt" and "bef" dates and perhaps WeRelate doesn't use those in what you're calling the info box. The other people have no dates in their DOB and DOD fields and therefore nothing would show up under their names. Jillaine 08:41, 7 August 2012 (EDT)
I have lots of pages that work right with abt and bef. I suspect it might be related to the dates, because several minor changes to both Person and Family page did not fix the problem (at one time there was a bug where changes did not get propagated). --Jrich 09:22, 7 August 2012 (EDT)

Ancestry.com has crashed [11 August 2012]

Ancestry.com has crashed. First time I remember not even being able to access the site. I was attempting to edit a person and nothing happened. This has been confirmed by other users. --Beth 00:47, 10 August 2012 (EDT)

I couldn't get into Ancestry for awhile yesterday, either. And then they put up the "Undergoing Maintenance" screen for a couple of hours. And now it seems to be working again. Looks like the problem was temporary. --MikeTalk 09:38, 11 August 2012 (EDT)

Help WeRelate become a better place [5 October 2012]

Would you like to help WeRelate become a better place for genealogists? Starting today, we're switching over to a new admin structure - in which everyone is encouraged to participate! We'd like to give a big thank you to our previous administrators who have served for many years. It's time for WeRelate to grow. WeRelate continually needs volunteers who can assist in maintaining and improving the website. The majority of these tasks can be performed by anyone. I encourage you to get involved!--Dallan 09:00, 13 August 2012 (EDT)


Update (29 September): I want to give a big thank-you to everyone who has signed up so far to volunteer:

We can still use more volunteers in nearly all areas. Please get involved!--Dallan 00:07, 30 September 2012 (EDT)


Help WeRelate to become a better place. The first thing I would suggest is:

We are advised by email that there has been a change on Watercooler or Support. If we "view the currenct version" we are sent to a menu of messages and we haven't a clue which one has been changed. It may not be the last one. It might even be one that has been archived. I have learned to copy from the email and paste in the "find" box once redirected, but that is, frankly, a pain, especially if we have other things to do at the time.

It is a bit easier to figure out the message we ought to look at if we go the "see what has been changed route", but

  1. the phrasing is not smooth and easy to understand
  2. I have to adjust the font-size in order to see it (some of us are getting older and cataracts are creeping)

Would it be possible to be directed to the topic and not just to the page? --goldenoldie 14:23, 30 September 2012 (EDT)

You're talking changes to how WeRelate works, this is about volunteers helping to clean-up. So possibly a slight change of topic. If I understand your question, you are talking mostly about WeRelate Talk pages with tables of contents listing many topics, and wanting to be directed just to the one topic that changed. However, the topic has a date included as part of the header and it has always been awkward adding links that point directly to topics because of the date. I am not sure why the date is part of the topic header. Perhaps simply because wikipedia did it that way? In essence, it makes the header unlinkable-to for all practical purposes since the date will change next time somebody adds a comment. --Jrich 22:44, 30 September 2012 (EDT)
The way I find which topic has been edited is to look at the history, the most recent change being on top and then read it from there. --Susan Irish 22:52, 30 September 2012 (EDT)

Hi Goldenoldie, When you receive an email alerting you to a change, click the link after the words "View the changes" not the link after the text "View the current version". Then, you will be directed to a page that shows side-by-side the "old" version and the "new" version, with the changes highlighted in green. If you click the "View the current version" link, then you are visiting the page without those changes highlighted. In that case, you need to click on the "History" link and "compare selected versions". Regarding the font size, if you need to increase the font for your particular needs, you can do this through your browser. I have a scroll mouse, and I find it easiest to hold the CTRL key while scrolling my mouse up or down to adjust.

As JRich said above, this topic is more about encouraging users to assist with WR maintenance, mentoring other users, volunteering for cleanup projects, etc. In that spirit, since I know that you have done a wonderful job cleaning up place pages for Ontario, you might consider taking a look at the WeRelate:Place patrol. Your expertise with Ontario place pages would be very beneficial! --Jennifer (JBS66) 08:34, 1 October 2012 (EDT)

Also, please feel free to add your suggestion about linking to the correct topic to the suggestions list. I agree it's an annoyance. But the obvious solution is to remove the last-modification date from the topic headers, and I'm not sure whether that would be an improvement.--Dallan 15:44, 5 October 2012 (EDT)

New Category [1 September 2012]

I've recently created a new Mormon Pioneers Category.

If anyone else has Mormon Pioneer ancestors, please feel free to add them. Or, if anyone wants to tell me that I messed up in how I created it, that's good, too. :)

- Jdfoote1 16:25, 19 August 2012 (EDT)


The sad thing about the pioneers is that most of the European lines are so poorly researched. Hopefully someday there will be some stronger research on them.--Daniel Maxwell 19:58, 19 August 2012 (EDT)


Thank you! Yes, one of my ancestors came to Utah from New York, walking, with her oxen! Those stories were documented in diaries which are online. I will check out your new category and include her. --cthrnvl 14:49, 29 August 2012 (EDT)


  • I believe you are supposed to add it like this [[Category:Mormon Pioneers|Chase, Ezra]] - that way when you look at the category page everyone will be listed under the initial of their last name. --cthrnvl 14:58, 29 August 2012 (EDT)
Aha - I figured there was probably a way to sort it correctly. I've fixed all of them that have been added so far. - Jdfoote1 16:37, 1 September 2012 (EDT)

New Genealogy Q&A Site [1 January 2013]

FYI, there is a new Genealogy and Family History Stack Exchange site. Stack Exchange is a software that runs some great Q&A sites, mostly centered around computing and programming topics, but over the past few years, they have branched out to other topics.

It is pretty cool software, and leads to good communities, with good answers to questions. I thought that some of you might be interested in checking it out.--Jdfoote1 19:55, 21 October 2012 (EDT)


FYI - the site has been in beta for a couple of months now and is becoming better defined. There are some werelate questions and some questions that cite werelate pages - but it could use more so feel free to join in. My opinion is the werelate philosophy and the stack exchange philosophy have a lot in common and the werelate community would benefit from participating in genealogy.stackexchange.com - and the genealogy community at stack exchange would clearly benefit from the werelate community.--Sparrell 10:37, 1 January 2013 (EST)


Policies regarding Wikipedia inclusion on pages [30 November 2012]

Recently, there have been issues raised to the Overview Committee regarding the Source-wikipedia template. We are interested in developing clearer policies and are considering changes to our existing Wikipedia inclusion practices. Currently, two practices exist on WeRelate:

1. There exists the ability to link to Wikipedia pages using the Moreinfo wikipedia template. This template does not import text from Wikipedia, but instead provides a link to the Wikipedia page. An example of this template can be found on the bottom of this page.

2. There also exists the ability to import text from Wikipedia using the Source-wikipedia template. An example of this template can be found on the page for George Washington.

We are asking for users' input as to whether or not we should continue to allow the import of Wikipedia text to WeRelate using the Source-wikipedia template. If we choose to continue allowing text to be imported from Wikipedia, there is an option of limiting its use to certain namespaces. For example, we could allow this template on Place pages but not on Person pages. Also, we will institute clearer policies regarding its use on Person pages. If any user objects to the Wikipedia text inclusion on a page they are watching, it may be changed to a Moreinfo Wikipedia template instead (ie, a link to Wikipedia). The Moreinfo wikipedia template would be the preferred option in any cases of conflict.

Please indicate with your signature below which of the following options you vote for:
Note: With each of these options, users may still link to any Wikipedia page. --Jennifer (JBS66) 19:21, 22 October 2012 (EDT)


Option #1:Continue to allow Wikipedia text to be imported to any WeRelate page [17 November 2012]

Users supporting Option #1

  1. --Beth 19:42, 22 October 2012 (EDT)
  2. --jrm03063 22:34, 22 October 2012 (EDT)
  3. --Amelia 16:25, 23 October 2012 (EDT)
  4. agree with Jrich stricter guidelines required --Andrew 18:53, 23 October 2012 (EDT)
  5. ----GayelKnott 21:16, 23 October 2012 (EDT)
  6. -- Jdfoote1 23:08, 23 October 2012 (EDT)
  7. ------Judy (jlanoux) 11:56, 24 October 2012 (EDT)
  8. ------Jim (Delijim) 12:38, 24 October 2012 (EDT)
  9. --AndrewRT 17:08, 17 November 2012 (EST) (although you could say I have a conflict of interest as I was a Wikipedian before I joined WeRelate even to the extent of being a trustee of Wikimedia UK)

Option #2: Allow Wikipedia text to be imported to WeRelate, but limit which namespaces this is allowed in [24 October 2012]

Users supporting Option #2

  1. (see comments below) Daniel Maxwell 07:44, 23 October 2012 (EDT)
  2. Susan Irish 17:08, 23 October 2012 (EDT)
  3. (reasons below) --DataAnalyst 22:50, 23 October 2012 (EDT)

Option #3: No longer allow Wikipedia text to be imported to WeRelate [25 October 2012]

Users supporting Option #3

  1. ceyockey (remarks below)
  2. KayS (added by Jennifer (JBS66) based on comment below under Option 3 voting remarks)
  3. mksmith (comments below)
  4. Jrich (agree with ceyockey)

General remarks and questions [26 October 2012]

  • What is the thinking behind this? Copying the text from Wikipedia seems pretty cool to me, but I'm obviously missing something if others think it's a bad idea. Why are people opposed to the import option? -- Jdfoote1 19:31, 22 October 2012 (EDT)
In answer to the question why inclusion may not be desirable, I can provide some points:
  1. wikipedia articles are sometimes wrong, as articles are sometimes written by people that may not be familiar with, or are not interested in, the finer points of genealogy. wikipedia articles are secondary sources as best, and made superfluous on pages with good use of primary sources and extensive narratives.
  2. Wikipedia articles often reflect a broader interest, especially when only the introductory section is included. Ideally WeRelate pages would have custom narrative, documented with footnotes, etc., and reflecting more focus on genealogical topics, such as deeds and wills, etc. For such a narrative, wikipedia are best given as a link under "Further Reading" for people that may want more historical context.
  3. wikipedia itself may have different articles on the different servers supporting different languages, and they may not be equivalent. Using links allows the best version to be selected whereas the current inclusions use only English.
  4. wikipedia is a very well known website, not likely to disappear, and given the back button, access via a link is not really harder to use. A link may be followed by the reader at their discretion.
  5. WeRelate's copy is only updated once or twice a year, so is sometimes out of date relative to wikipedia. I cannot comment on the cost of supporting this process, besides noting that a search for Template:Wp- returns 110,000 pages. --Jrich 20:57, 22 October 2012 (EDT)
Some of the concerns that I have seen from users include:
  1. There is a process to Use information from subsections of a Wikipedia article. However, if the title of the heading on Wikipedia changes, the text from that section is deleted from the WeRelate template with the next update (as WR can't find the newly-named subheading).
  2. Re: Place page inclusion, some feel the "present-day" focused WP text can conflict with WR's "historical" and genealogical place page focus.
  3. When a user views a page that contains WP text, the templates that appear on the page are Template:Wp-wikipedia page name and wikipedia-notice. However, users are supposed to use the Source-wikipedia template initially, and that is automatically changed into the preceding two templates. I have seen users confused about this.
  4. People have expressed fear of adding their own information to a page containg WP text. They are afraid to touch or "mess up" the WP template and don't feel comfortable removing the template from the page.
  5. Some users have tried to edit the WP template that appears on a page, not realizing their edits will be overwritten with the next WP>WR update.
  6. It is my understanding the Source-wikipedia template does not lend itself to internationalization. There are famous people who may be in foreign language versions of WP and not the English version, and the Source-wikipedia template does not allow for that linkage. On the other hand, the moreinfo-wikipedia template could be customized to point to any WP page, not just English.
  7. The Source-wikipedia template requires work from Dallan to manage/update. The moreinfo template can be user-managed. --Jennifer (JBS66) 08:33, 23 October 2012 (EDT)

I'm concerned that this is being moved to a vote prematurely, resulting in an insufficiently refined set of choices for a more nuanced situation. Particularly since the current practices were arrived at by previous lengthy discussions.

  1. It is not clear that the use of WP for more ancient individuals ("Charlamagne"?) presents the same problems as for more modern individuals. Likewise, use of WP for individuals of unusual fame ("Queen Elizabeth II"?) - where the genealogy is not at all a matter of question - may save us other sorts of trouble. Inflicting an arbitrary standard across all "PERSON" pages seems unnecessarily crude.
  2. I've never felt that the WP extract was really a substitute for going to the actual article - but neither do I feel that a "See WP for moreinfo" line, at the bottom of a page, is a loud enough announcement that there is a corresponding WP page. To my mind, the WP extract is really serving as a banner that might (if you're lucky) already have the information you need. This leads to my next observation...
  3. WP inclusion presently grabs the first "section" of the WP content. In some situations, that turns out to be much more than we would wish - while in others - not enough. While any approach will be imperfect, it seems like the quantity grabbed could be tuned a little better. Were that so - perhaps there would be less angst about WP inclusion.
  4. Finally, use of the WP inclusion or moreinfo currently serves (imperfectly) an additional important purpose. It defines that a particular WP page is substantially associated with a particular WR page. While it is unlikely that an inclusion of WP would occur on anything other than "the associated" WR page - a WP page could easily be a "more info" target for any number of WR pages. We really need a better way to define this kind of association (and not just with WP, but a number of other on-line sites). Those with dreams of sophisticated use of DBpedia and other sorts of analysis, will want to pay close attention to this item.

--jrm03063 22:22, 22 October 2012 (EDT)

I agree with Jrm that this is being voted on prematurely -- or too late depending on how you look at it -- given the years' long effort that's already been undertaken under the existing policies. I can see no discussion under the Overview Committee link. Is there any such public discussion? (How does one raise an issue to them?) This effects tens of thousands of person pages alone and resorting to a user vote at the first sign of dissension strikes me as a way to guarantee a messy outcome.

I also agree that this is not a problem in need of solving, particularly not by a blanket rule. The existing system provides for a stand-in summary that, while not perfect, serves to identify the person/place/thing in a general way and links that profile to other information of interest. It can always be replaced when someone has the time and dedication available to improve upon it. But until that time happens, which for many profiles is probably sometime after pigs learn to fly, users are able to rely on information written by a much, much, larger audience than is available on WeRelate.

Two other general themes I see below:

  • WR is a genealogy site, not a historical site. Even if true, I submit that it is still relevant and interesting to users to know that a relative was a state senator, a Revolutionary War hero, or a King of Prussia. A good biography should lead with these pieces of information anyway. With the WP inclusion, we get not only a crowd-sourced, standardized intro summarizing the highlights of a person's life, but also automated links to famous relatives, major events, and important terms and places, all of which enhance the experience. This is a tremendous amount of work that will probably never be duplicated from scratch on WR. (This also goes to the point below about people being "lazy" and using these inclusions instead of writing something from scratch. Dozens of pages can be identified and linked in this way in the time it takes to write a single summary of quality similar to what is already found on WR, not to mention the considerable interest in a single individual required to inspire such treatment (instead of a set of individuals, which we shouldn't assume is less valid). When we have 10 million users busily drafting and crowd-sourcing our own intros, then perhaps we can revisit.
  • WP has bad quality data. If we believe in the power of the wiki, and we have to if we're here in the first place, we have to dismiss this. We have the power of two wikis working in our favor here to improve the data -- if WP happens to be wrong and it can't be corrected, it can always be dealt with here. Frankly, if you think that the millions of users on Wikipedia create, on balance, bad information, then you shouldn't be here either, because if the wiki concept fails over there, then it has no hope with our relatively tiny number of users.--Amelia 17:23, 23 October 2012 (EDT)
If users are interested in facts that reside on wikipedia, they can always follow a link. That wikipedia may have value isn't the issue, only whether it needs to be copied through inclusion.
It is not interesting to know the facts 2, 3, or 4 times over. The un-nuanced placing of wikipedia entries at the top of the page regardless of whether there was an existing narrative or not, of whether the WP page is right or not, of whether the WP inclusion adds anything new or not, is part of the problem.
I am a WeRelate contributor, but have no particular wish to take on the task of updating wikipedia. I want to work on genealogy, specifically, and that includes lots of people that don't have a wikipedia page. Even a small survey shows that many wikipedia pages treat genealogy as an after-thought, are based on a single source, don't have lengthy analysis of genealogical controversy and unknowns, etc. Meaning, from the focus of genealogy, WP pages do tend to be less useful and less reliable. And meaning that my input still needs to be done on WeRelate because wikipedia does not provide a good medium for exchanging detailed genealogical research.
The idea of wiki can work (meaning it results in higher quality data) if one of two things happen. One: WeRelate attracts a specialized audience that does higher quality work then the general Internet. This is far from clear. It seems to me that Ancestry commercials have convinced people, who wouldn't dare presume to write a wikipedia article, that they are qualified to dump unsourced family trees on every genealogy website they find, including this one. Two: wiki enables the whole audience to improve bad pages and if this change almost always moves towards better quality. Unfortunately, it is easier to create bad genealogy using no sources or easily accessible secondary sources than it is to correct that genealogy using only good sources. So, in general, a secondary source of variable quality, that is the very definition of easily accessible, written largely by non-genealogists, is hardly the desired end result. It is more a flag, saying, "This page needs more work". --Jrich 19:37, 23 October 2012 (EDT)

Mmm. Shouldn't the question be:

under what conditions do we
link to Wikipedia
include content (full, partial)
remove content

?

Jillaine 08:02, 26 October 2012 (EDT)


I believe Jillaine has hit upon the key issue regarding the inclusion of wikipedia content. If a specific wikipedia page contains factually incorrect genealogical information, we should probably at least come up with a "wikipedia warning template" that indicates what information is in question, rather than wait for the wikipedia page to be fixed. From my vantage point, at least with my ancestors, wikipedia appears to be genealogically correct on almost all of their pages, so removing the information from WeRelate would remove information that is currently useful to others. Delijim


Comments from a peon:
I was very eager to send my friend a link to a page I had just linked her family to. While I was at it I added info from wikipedia. But before I could even send her the link, someone had removed the interesting text from wikipedia and replaced it with a LIST of dry facts. Bummer. So I have to agree that removing wikipedia info may results in more exacting genealogy but for the general user it can be very irritating. I was so disappointed that I didn't even send her a link to that WeRelate page.

Are you willing to pay that price to be so exacting? Decisions like this will determine not only your target audience but the level of participation from users. --Janiejac 09:54, 26 October 2012 (EDT)

Well searching for wikipedia and janiejac only yields a few pages, and the only one that appears to be similar to your description is Person:Elizabeth Fones (5), but the history doesn't quite match your scenario. So not sure what page you are talking about? Incidentally, it turns out that Elizabeth is a case similar to those mentioned elsewhere. The narrative (actually short paragraphs giving highlights of her life) were removed (not by you) to add the wikipedia template on the grounds of redundancy. Meanwhile, including wikipedia, and also listing it as a source, wasn't deemed redundant? So the inclusion was removed, before the agent ever filled out the template, while the source citation was retained, and the paragraphs restored. Meanwhile, court documents were cited to show that she had died considerably earlier than shown by wikikpedia.
I'm not sure what "price" you refer to. But one must not forget what makes general Internet genealogy so unreliable. It is a lack of sources, or reliance on bad sources that do not themselves use good (based on primary information) sources. There are plenty of those websites out there you can send to your friend links to, including a link directly to wikipedia if you want, but what will make WeRelate worth sending to somebody is if it is reliable. And this will require a list of the primary sources that let us know how something is known, and only what is known, and not a bunch of assertions and assumptions trumped up to look like facts. Good genealogy is exacting, because everybody wants to fill in the missing information, but the undisciplined use of bad sources, and the rush to a bad answer, is what leads to AWT/WFT/AFN-like quality. The results of this are evident on so many websites, that it obscures the ones that are good to the point where it is effectively unproductive to search the general Internet. If WeRelate does not want to be just another bad website, it must do something different than simply reuse the methods and results of bad websites. So, if a "dry" list of good sources is necessary to ensure that the data is reliable, yes, that is a "price" I think it is worth it to pay. Because otherwise, we are just recreating something that already exists somewhere else on the Internet. --Jrich 10:57, 26 October 2012 (EDT)
Internet genealogy isn't fundamentally unreliable - otherwise - what are we doing here? What makes it unreliable tends to be the inability of most sites to accept and include timely critical review. Many of us think that the use of a wiki and shared tree/data are procedural steps that are designed fundamentally to get at this. But let's not toss barbs right here. Let's find a middle way that respects the needs of purists while not overly burdening those who have more casual interest. --jrm03063 11:30, 26 October 2012 (EDT)
I didn't say it was fundamentally unreliable, if you read what I said. I mentioned there are good sites (Pane-Joyce just to give an example), and elsewhere in this discussion I even mentioned the review process of wikis that you mention, and said it was one of the reasons why WeRelate could work. What I said about Internet genealogy was that so much of it is unreliable that it obscures the good parts. Part of the reason for this is because people who have a casual interest go around and publish poorly-researched information multiple places on the Internet, and then the next casual user finds their oft-repeated error and re-publishes it again. Genealogy properly done (like the articles found in NEHGR and NYGBR) are scholarly and well-documented, and much like modern history, relies on primary sources. This is for a reason: because it works. It is pretty much common sense: the source of information that is closest to the original is probably the least distorted. A few good sites do this, the bulk of sites don't. Because it is hard. And copying a wikipedia entry is not this type of quality, it is secondary. Wikipedia has some correct pages but that is reflective of the sources used, and is not universally true, and what needs to be brought to WeRelate is those, and other primary sources, not wikipedia for its own sake. That is not snobbery or anything like that, it is recognition of what methods give the best results, methods that evolved largely because of errors made in the past. People that are researching to the level of primary sources are probably already familiar with the historical context and so giving them the discretion to not follow a link is less obtrusive than force-feeding them the wikipedia material, and even people not at that level presumably know what wikipedia is and how to follow a link if they want to read it. Turning WeRelate into some kind of wikipedia-mirror site isn't all that exciting to me. --Jrich 12:56, 26 October 2012 (EDT)
I sure hope that wasn't me. If it was - I'm really sorry! Beyond that - I really like your observation a lot - because it lays bare the problem with the decision as posed. It's forcing a choice between exacting standards and general appeal. Since we don't yet have an alternative that seems reasonable to both populations (or evidence that a discussion was held that found there wasn't a reasonable overlap) - I don't think we're ready to be holding a binding vote. While it looks like the status quo is tentatively going to prevail - I don't want people at the other end of this to give up either. We need better alternatives! --jrm03063 10:40, 26 October 2012 (EDT)

If nothing else, I think that this has created a really great discussion, with some very important ramifications for our community.

As I see it, there are a couple of philosophical questions about the purpose/goals of WeRelate that are at the heart of this debate. While I don't think there is a right/wrong answer for these questions, I can't help but give my opinion on what I prefer. :)

Quality or Quantity

The first question is whether we want the poorly-researched individuals on WeRelate. That is, where do we draw the line at what Person pages "should" be created? Is it better to have a person with just a birthdate and no sources, or better to have no page at all? This is very similar to the decision Wikipedia made to encourage "stubs", where pages are basically placeholders - they allow a page to be created with limited, not-that-great content, because often the existence of a page will encourage its improvement.

I am personally in favor of this sort of philosophy here - I think that (all else being equal), it is better to have a poorly-researched, unsourced person on here than nothing at all. That poor information can often work to spur better research, or spur someone to improve the page.

I think that there are some technical problems that cloud this issue (like the difficulty of importing a GEDCOM and combining it nicely with what is already on WeRelate), but I think we need to make a philosophical decision, and then try to build the tools that support that way of thinking.

Integrator or Duplicator

A second, somewhat related issue, is whether WeRelate should be completely independent of other data sources. Many of the comments have been about how we don't want to rely on Wikipedia for data, their data can change/be wrong, etc.

This is another case where I may be a radical, but I think that, when it is appropriate, it makes great sense to avoid duplicating work done somewhere else. This is a hypothetical example, but if there were a Creative Commons site that had indexed all of the censuses, then I would argue that creating a template that displayed a relevant portion of the index, would be much better than copying and pasting the index into WeRelate. I am hopeful that data sources like that will appear in the future (e.g., DBPedia), and I think that it would be useful to have both a philosophy and technology that prepares us to integrate those sorts of sources.

Therefore, what?

I see our Wikipedia policy as an application of these philosophical decisions. For Quality v. Quantity, I see Wikipedia as a great initial - very good information (in most cases) at very low cost. In that sense, I see Wikipedia inclusion as a great feature. The integrator/duplicator decision is much more nuanced. As mentioned, Wikipedia is not a genealogy site. Unlike my hypothetical census indices, in many cases the Wikipedia content is not ideal in a genealogical context, and should be replaced. That is why, in this specific case, I suggest a policy that encourages Wikipedia use only when the time/resources necessary to create a better page aren't there.

-- Jdfoote1 14:03, 26 October 2012 (EDT)


In general, I agree with the position that wikipedia could be useful on empty pages. But it is not clear to me why inclusion is required?
In Quality and Quantity I would suggest that if stubs are used, they carry a banner identifying them as in need of research to 1) show that a higher standard is desired 2) call attention to the need. The problem with stubs, though, is that poor research can result in pages that are hard to fix like Person:Thomas Parke (24) (see the Talk page). To combat this, I would like to see some sort of training required for new users so that it is clear what the goals and expectations and proper formatting and citing is, and earning wizarding levels that gradually permit wider and wider ability to do data entry. In an ideal world, this input would be done by professional genealogists (the level of quality desired) but as they aren't going to give things away, us amateurs should be able to compensate by having sufficient vested interest and accumulated research to at least achieve half-way credible results. If there isn't sufficient interest to do a certain amount of research, however, people should recuse themselves from posting data.
In Integrator or Duplicator: there is a fine line between clutter and useful data. Perhaps a user preference could control whether certain types of links are expanded or not. But I think there is a bigger issue, too, namely, is the purpose to document the exhaustive survey called for by the GPS, or just document the best known proof of the facts on the page. The Great Migration articles forms my model for a good presentation, and they imply the exhaustive survey, but only document the proof. Why cite one of Cutter's books if other, better sources already tell you all the same information you can learn from Cutter? But this is a long discussion outside the scope of the issue here. (Sorry if these examples are too New England-centric, that is where most of my work is done.) --Jrich 15:43, 26 October 2012 (EDT)

Option 1 voting remarks [25 October 2012]

I think wikipedia inclusion adds something to empty pages, and place pages, and so with a clear understanding that such inclusion is a temporary placeholder until a knowledgeable researcher writes a narrative, at which time it should be changed to a moreinfo link. Any practice of always including wikipedia, without regard to adding value to the page, would change my vote to option #3 as I believe following a link is very viable. --Jrich 21:10, 22 October 2012 (EDT)
I aupport option 1 with the inclusion of the data quoted from the above test. If any user objects to the Wikipedia text inclusion on a page they are watching, it may be changed to a Moreinfo Wikipedia template instead (ie, a link to Wikipedia). The Moreinfo wikipedia template would be the preferred option in any cases of conflict — Preceding unsigned comment added by Beth

This has been an interesting topic, with plenty of passion. It sounds like there is a general consensus that the wikipedia-include is not the ideal final state for an article, but I agree with those who think that it is better than nothing in most cases. I think that a move to ban the include template is not ideal. Maybe we could converge on a policy to replace the include template with sourced research when there is interest or time to do so?--Jdfoote1 23:12, 23 October 2012 (EDT)

Jdfoote - I agree, well said. Jrich, since I actually agree with this statement, I'm not going to get into the details of responding to your comment above. I'm not aware of anyone arguing (or of any policy) that an inclusion is required under any circumstances.--Amelia 00:10, 24 October 2012 (EDT)
Amelia, there is a person who included (inclused?) wikipedia articles on pages with lengthy narratives [8], that already had moreinfo [9], and created pages just so he add another one [10]. So I believe there is someone espousing, or at least practicing, inclusion under any circumstances. --Jrich 14:40, 25 October 2012 (EDT)
If this whole thing boils down to your disagreements with that user, then my discomfort with this entire process is increased another level. I don't think there's anything per se wrong with the examples you cite. In the first, the WP template adds 2 lines that supplement the existing narrative by explaining he was a Mayflower passenger -- otherwise not a real evident fact at the time (or now, for that matter). The second has already been reverted, which appears to have been the correct decision based on the info in the WP page, and on the third, I don't even understand what you're saying -- there's certainly nothing wrong with creating new pages that cite WP - it's a readily accessible first step, and in this case appears to be done in the course of building out what is now a well-documented family set.
Are these the examples that caused you to change your vote? I think they actually support your view - they add to the pages and can be replaced when someone wants to improve upon them, which has been done in one cases and not others.--Amelia 20:19, 25 October 2012 (EDT)
In the Francis Cooke page, you might notice that the part of the narrative that said he was a Mayflower passenger was removed to insert the wikipedia passage so it could occupy the prime spot at the top of the narrative. You might also note that the wikipedia inclusion is short and has a bad birth estimate (married in 1603 so could not be born about 1595/1599). In the case of Samuel Andrews: yes I reverted it, which earned me a complaint, but the reality is that it shouldn't have been done in the first place because the guidelines say at least make sure the moreinfo is there, which it was, and the Samuel Andrews wikipedia entry is one or two lines long, and information not provided by wikipedia was removed in the process (one of founders of Yale). In the Jonathan Chase case, two generations of unsourced pages were added to connect him to an existing family including specifying the wrong grandmother and adding no siblings or dates for anybody but him. This one was the only one of the three where a narrative didn't exist ahead of time and so the only case where you could argue that they added to the page. If just the page itself had been created to reflect the information given in wikipedia that would have been fine: presumably if there is a wikipedia page, a Jonathan Chase did exist, and if the dates had been wrong, the inclusion of wikipedia would have made it clear where they came from. But it did nothing for the various other pages added (presumably they were based on another source since the grandmother is not named on the wikipedia page, but apparently it was too much effort to cite it when all that is desired is to create another WeRelate/wikipedia connection). Philosophically I agree that it is better to link to wikipedia, not include it, and was only willing to try inclusion as a stop-gap for empty pages. It is exactly the apparent inability of people to make nuanced decisions about when to include wikipedia, that has caused me to have a concern about this issue, and little that I see under option 1 comments, except Beth's suggested caveat, would make me believe there is much chance that option 1 will result in wikipedia being done correctly. So I changed my vote. --Jrich 21:17, 25 October 2012 (EDT)

Guess I'm a little late to this conversation, but this really appears to be an issue of "precedent" in terms of wikipedia inclusion. I have never seen anything "wrong" in including wikipedia content on a Person Page. Those that seem so inclined can add additional content, narrative and sources to make the Person Page "more well-rounded". Wikipedia pages for the most part provide historical content that is directly pertaining to the person involved that can and normally would be important to those that descend or have general interest in them. To exclude wikipedia content because "it is not a genealogy site" seems rather snobbish since genealogy and history certainly go "hand-in-hand".... Since we have allowed wikipedia content to exist for several years on WeRelate, changing the rules now would be tantamount to "closing the barn door after the horses have already left". Changing this rule now would likely just be an irritant to those that have added wikipedia content thinking that it has added value to a Person Page, myself, JRM and several others included... I'd suggest that we resist the temptation to change precedent for change's sake alone... Live and let live. What we don't need here is more rules. I am also not in favor of establishing a "content police force" to include only certain selected wikipedia content. --Delijim


Option 2 voting remarks [24 October 2012]

My position is similar to this. I would actually like Wikipedia intros and imports to be used for detail to places (which are extensively detailed on Wikipedia) and well known cemeteries which have articles to give them some life. I could also not see a big problem with using intros being used to spice up pages for some famous people whos ancestry isnt really in doubt (ie Henry VIII).

The problem comes when Wikipedia by itself is used as a source for pages, even when the WP page itself contains outdated or wrong information. The most egregious use of this is on pages for Royalty/Nobility on WR, which quite frankly are a frightening mess that hopefully one day can be improved.

Probably the single worst example I can think of this is with Benedict Swingate Calvert. There is no proof that the Countess of Walsingham was his mother, it was a conjecture made by a single author and now appears as 'fact' on WP (see his tree at bottom of WP article). While the erroneous identity of his 'mother' isnt used on WR, it is in the intro, and with the precedent of WP being used as a source for nobility on other pages, its possible mistakes of this height could find their way on other pages.

WP also has mythical origins on the articles for some colonists, but my sojourn to Wikipedia to correct some of them wasnt very positive. A good example of this with the colonist John Brockett: http://en.wikipedia.org/wiki/John_Brockett

There is in fact not 'little doubt' that he is the son of a Sir John Brockett. There is no proof, and in fact evidence suggests that Brockett was a yeoman of unknown origins. The name of his wife is also not known.

WR has a page with the correct, known information, but also an unmerged, unconnected page with the erroneous information.

So then to summarize, the problem with using WP is that not only do we have to worry about sourcing the pages here on WR, but in some cases we would have to go on WP to correct the mistakes/myths given on some of their pages. The easiest thing to do then I think is to limit the intro imports for things that problems are unlikely to have issues (places) and offer links for everything else.--Daniel Maxwell 07:44, 23 October 2012 (EDT)

Facing errors from all sorts of places - published and unpublished, web sites and old manuscripts and whatever - strikes me as more or less fundamental to genealogy. At least with WP, there's a chance to stop the bleeding. I've checked both of the WP pages you mention - but I don't see discussion of the problems you note on the talk pages. Neither do I see counter discussion or criticism of the references/sources offered. We don't even see your discussion on the talk pages of our own John Brocket pages that you mention. Why? --jrm03063 21:57, 23 October 2012 (EDT)
John Brockett wasnt one of the pages that I tried to improve on WP. To be honest, I dont like the Wikipedia 'community' after having been burned over there so I doubt I will ever contribute there again. I know exactly what would happen if I removed that information (revert). Its not a complaint about WR, btw. There was no reason to open a discussion about Brockett here because the correct information is linked to the relevant families by Jaques. I dont have the power to delete the others (merging them wouldnt matter, because we dont need any of the pages except for the one for John. His 'ancestry' would otherwise have to be deleted). — Preceding unsigned comment added by User:DMaxwell 01:27, 24 October 2012

I agree with most of what Mike says under Option 3. My first negative experience with incorporating WP was when I noted an error in WP and corrected it there - and the correction was not reflected in WR (because the copying is only done a few times a year). This can leave the page looking like you added a citation to say one thing, but the page says something contradictory - hardly a good feeling for someone who cares about the quality of my work. The reason I vote for Option 2 instead of Option 3 is that when it comes to Place pages, it appears to me that WP users have spent some effort on place pages. In fact, I usually use WP as my first source for finding correct names, counties, etc. when checking out place names. So I don't mind copying in WP for place pages. I'd be OK with a link, but a copy gives me the data just a bit faster when I am trying to determine if I have found the correct place page.

Then I would also note that just because extensive discussion went into the original design does not mean it should not be changed. I live in the IT world and unfortunately it happens that you sometimes need to abandon something that you spent a lot of time designing. It can be painful, but sometimes you realize that your beta version of something just doesn't pan out as planned. I think this is one of those cases. --DataAnalyst 23:01, 23 October 2012 (EDT)


Option 3 voting remarks [23 October 2012]

I've voted to disallow copying of Wikipedia content into WeRelate. This is based on wanting to keep a separation of mission and intent between the WeRelate and Wikipedia resources and to discourage point-to-point connection solutions. There is no problem I can see with use here as currently done from a licensing point of view (see http://en.wikipedia.org/wiki/Wikipedia:Reusing_Wikipedia_content#Re-use_of_text_under_Creative_Commons_Attribute_Share-Alike for what I'm basing this on).

  • Mission / Intent : I think that automated inclusion of Wikipedia content contributes very little to the genealogy mission of this site; much of the genealogically relevant content will be found either in the biography infobox or a "family"-type section ... in the case of biographies. For other page types, it is generally the case that either an infobox has the most relevant information (e.g. many place articles) or an infobox with that relevant information has not yet been created (e.g. surname articles just don't have a good infobox available yet).
    Point-to-Point connections: In this day and age, I think we should be working toward using linked data resources rather than relying up individual connections to individual resources. I mentioned in the last section that infoboxes contain much of the genealogically-relevant information; DBpedia, a linked data resource, draws it's content in large part from these infoboxes. "Linked data" is a component of the Semantic Web; if we can develop templates which draw into WeRelate content from DBpedia, this establishes the feasibility of drawing content in from any number of other resources using the same technical solution (SPARQL queries against RDF repositories or SPARQL endpoints). ~can consult Wikipedia for articles on linked data, SPARQL, semantic web, DBpedia, RDF, etc~
--ceyockey 20:31, 22 October 2012 (EDT)
Careful - inclusions are presently the only reliable indicator that a particular WR page is associated with a particular WP page - upon which you can then examine "dbpedia" properties. While "moreinfo" is supposed to do the same thing, it's not as visually obvious and hasn't (so far) been advertised as intended to define a unique association.--jrm03063 22:31, 22 October 2012 (EDT)

Though I'm relatively new to WeRelate, I would vote against importing data from Wikipedia mainly because the data there may not be accurate and the purpose of the site is not genealogy. Including a link to a Wikipedia topic would be fine. Is there something else I need to do to vote?

But then, I see lots of misinformation on this site, too.--KayS 21:22, 22 October 2012 (EDT)

KayS, I can note above under the Option #3 header that you voted for this. If you see this message, please feel free to replace my note with your signature. --Jennifer (JBS66) 07:34, 23 October 2012 (EDT)

Jennifer is that your vote? Waiting for the votes for the three other committee members. That will be most interesting. --Beth 22:52, 22 October 2012 (EDT)

Hi Beth, no I've not voted yet. That was my signature at the end of the post. I'll add a few headers to try and clarify this a bit. --Jennifer (JBS66) 07:26, 23 October 2012 (EDT)

I've been grumbling for some time about the increasing dependence on WP auto-inclusion, frequently in lieu of actual genealogical research. Wikipedia and WeRelate are different sites with different missions, whether or not they happen to use the same software. (And I will note that I've been editing articles at WP since early 2003, mostly in history topics.)

1. WeRelate is a genealogical site, not a general historical encyclopedia. Yet, the majority of what gets imported by the robot from WP, especially from the lead paragraph of an article, has nothing whatever to do with genealogy. In fact, one of the fundamental policies at WP states that they are not a genealogy site. They deprecate that kind of thing, and with reason. They are not us and we are not them.
2. It appears to have become a habit by some people at WR who put up articles on major historical figures, especially in series (like U.S. presidents and British royals) to rely on whatever WP has, and that's it. They add little or nothing from other sources -- of which there usually are many available. It's the triumph of knee-jerk convenience over thoughtful research and editing.
3. I don't think accuracy (or not) in a WP article is really the issue since the same question arises with any secondary source, and not only those online. Likewise, being out-of-date is an issue that applies not only to all online sources but to hard-copy published sources as well.
4. I frankly think relying on "linked data" supplied by someone else is a bad idea, at least for a project like WeRelate. By doing so, we abdicate responsibility for what appears here. We assume someone else knows better than we do about what sort of information WR needs, and how it should be presented -- someone who may know or care nothing about genealogy. If convenience is the only criterion, why not just link to Ancestry, link to RootsWeb, link to USGenWeb, link to the Texas Death Index website -- link to wherever info might be found, but not bother to actually state that info on the page at WeRelate. If that's the goal, why bother with any of this?

I have no problem with using material from Wikipedia, any more than from any other site -- but I would much prefer to see such information explicitly and selectively copied from WP to WR, with the proper source citation appended. That way, one can take from a WP article only that which is actually useful and germane to WeRelate. I frequently include a link to a WP article when one exists -- but only a link. If there's useful information, I reproduce it on the page at WR with a citation. --MikeTalk 07:53, 23 October 2012 (EDT)



Update and guideline revisions [30 November 2012]

I would like to thank everybody who responded to this post and who honestly voiced their opinions – your input was very helpful. It is clear that the majority of users prefer to retain the ability to include text from Wikipedia pages. As was noted in the original post, regardless of whether we chose to continue/discontinue inclusion of text from Wikipedia, we would be instituting clearer policies regarding its use. The Overview Committee has revised the Guidelines for use of Wikipedia. Below, are highlights of these changes.

Internationalized the more-info template We added a language code parameter to the more-info template. This will now allow users to reference any language version of Wikipedia, not just English as had been past practice. The default value for this is EN, so the templates that already exist will still function properly.

Referencing Wikipedia content We added a new recommendation on placement of this template. Previous placement at the bottom of the page has been changed to placement within an “External links” section.

Removed the section “Use Wikipedia as a Source” This section had recommended that if a Person has a page on Wikipedia, that a user would then add Wikipedia as a Source. Wikipedia can be used as a Source, if the data you are sourcing was obtained from Wikipedia, otherwise, there is no requirement to list Wikipedia as a Source. Since the use of Wikipedia in this manner is no different from any other source on WeRelate, this section was removed.

Renaming the WeRelate page to agree with Wikipedia This section has been retitled and clarified. A person who has a page on Wikipedia will, in many cases, be titled as any other page on WeRelate – in the Givenname Surname format. However, if a Person’s name does not fit this format (such as Charlemagne), and they have a page on Wikipedia, the page should be renamed to match the Wikipedia page title. The purpose of this guideline is to present a standard method when titling pages that may not fit traditional conventions.

Added section on stage names When a person has a stage name, their page on Wikipedia is titled with their stage name. This differs from WeRelate’s guidelines. Their WeRelate page should be titled to reflect their true given name and their stage name can be added as an alternate name.

Including content from specific sections of Wikipedia This procedure is no longer recommended. The reason is that if the text of a heading on Wikipedia is edited, the template that was added to WeRelate will no longer function properly.

Added Known Issues section In this section, we note the bugs that are currently known to occur when including Wikipedia content.

Added Watching for errors section This section is just to remind users to watch the pages on which you include Wikipedia content. When you see changes from the “WeRelate agent”, text included from Wikipedia was updated. Review these changes for things like accuracy, WP>WR inclusion “bugs”, and changes to subsection header titles which would result in a loss of text in the WR template.

Added a section about procedures in cases of conflict If users watching a page cannot come to a reasonable agreement about the inclusion of Wikipedia text on a page, the preferred method will be to reference Wikipedia instead.

Updated Including Wikipedia content section We clarified that this process includes text from English Wikipedia only. Also, we stated that including Wikipedia content is valuable if you would like to add narrative to a page, and you cannot currently improve upon the summary introductory lead section on Wikipedia. If you can improve upon that narrative, you can certainly add your own text and reference Wikipedia instead.

Removed the Contributing to Wikipedia section The focus of these guidelines is to detail how WeRelate can best utilize content from Wikipedia, in keeping with our genealogical focus. While we did note elsewhere, that errors found in included Wikipedia content can be changed on the Wikipedia page itself, the goal here is not to advocate for the use of another site but to encourage best practice on WeRelate. --Jennifer (JBS66) 10:50, 30 November 2012 (EST)


More Issues with Wikipedia [18 November 2012]

Similar to earlier comments on wikipedia's use of templates, a wikipedia article using <ref> tags to create a footnote creates an ugly error message embedded in the template. See old version of Template:Wp-Deliverance (Hazeltine) Dane. I edited the template to remove the ref tags but that is obviously a temporary fix of one instance of a potentially on-going problem. --Jrich 10:39, 29 October 2012 (EDT)

This is one of many problems that can crop up when Wikipedia content is automatically included without human review. An automatic update can grab Wikipedia content in any state, with vandalism or bloopers or whatever present. I think using content from Wikipedia is okay anywhere, but automatic update should be limited to just those places where the gain is clear, which might be only on the Place: pages. In particular, I think Wikipedia content on Person: pages should not be auto-updated. --Robert.shaw 15:38, 29 October 2012 (EDT)
I think we could be smarter about these fragments - both from the point of view of creating them and the point of view of viewers (both human and software) that consume them. I see the standard WP introduction inclusion much more as a banner that clearly asserts the existence of a corresponding WP page. I'm not at all satisfied that a "see WP for more info" line, at the bottom of a narrative body, is sufficient for this purpose. The problem described here reasonably suggests that more debugging of the extract is needed - but I don't think it's a basis for concluding that extraction can not be done cleanly, appropriately, and routinely.
I'm also concerned that we're just re-voting on something without the benefit of considering possibilities that did not exist when we last did this. Some of us would like to be able to know that a given page on WR (perhaps ceyockey?) has a one-to-one correspondence to URLs for other sites. Consider Chaucer, for whom we have four "references" indicated. In truth - these are something both less and more than ordinary references - they are correspondences. At present - inclusion is the only sure-fire way to define a correspondence between WR and WP. We need a general approach to accomplish this sort of thing - that not only works for WP but for other items as well (we can't just assume that a "Find A Grave" reference appears only on the person page to whom it refers). Information like this sets the stage for doing larger scale genealogical verification and analysis - performed by software - leveraging information available on other sites. --jrm03063 16:34, 29 October 2012 (EDT)
We could be smarter: we could assume people know what wikipedia is so they are capable of deciding if they wish to visit it, and that they can follow a link and use the back arrow. In that case, just putting a link seems the epitome of the most bang for your buck there is. How much easier to just put a link, rather than try and recreate the environment of wikipedia at WeRelate so their code will display correctly over here! Do we really get value from inclusion that requires keeping in lock step with wikipedia regarding version and features so that we can safely import any fancy layout a wikipedia author may care to employ in their article? Do we really need to build the software to bring over (or remove, or mask) all their templates, and links, and all other features on the page, so that it will look right over here, when it already looks right over there, and can be gotten by simply following a link? And for what: to get a summary that is often either so brief as to be worthless, or mentions stuff not pertinent to our page, or includes genealogically incorrect stuff, or is 6 months out of date with what wikipedia currently displays. A link alerts the reader that an article exists, it will display correctly in its native environment, and the reader can read all, part or none of the article as makes sense. All this stuff about correspondences strikes me as a pie-in-the-sky, computer science experiment waiting for some linkage semantics that aren't defined yet, without any support from the wikipedia side, and requiring a lot of Dallan's time, which could probably be more productively used getting us out of Beta. --Jrich 15:25, 18 November 2012 (EST)

Can you help promote the WeRelate Genealogy Contest? [30 October 2012]

We need your help to promote the WeRelate genealogy contest. The contest was designed as one fun way to learn how to use WeRelate. Now we could use your help promoting it on your Facebook, blog or through conversation with your genealogist friends. And if you are interested in the contest please bookmark the Contest Summary Page. If you have any ideas or suggestions please add them to the Contest's Talk Page. This week's contest is Person:Jacques Barzun (1), he was a French-born American historian of ideas and culture. Thanks for playing! Catherine --cthrnvl 11:37, 30 October 2012 (EDT)


Revision proposal for Wpsurname template [4 November 2012]

See Template talk:Wpsurnamelist. Thanks. --ceyockey 20:00, 4 November 2012 (EST)



Ooh how to make Werelate better [4 December 2012]

I just uploaded my first gedcom under the new system. The number of people in my gedcom is 11 people. I cannot even imagine a new user uploading 500 people. I have only managed to add the source pages and place pages for one person after several hours. We need a system that creates source pages and place pages from the information. What a mess I have been through to even get to the upload. Part of this is not because of Werelate but I would like to share my story. I am the administrator of the Coker Dna site. I have an assistant who searches for living descendants. She forwarded me a Pdf file on a Coker family. I do not like Family Tree Maker but I did purchase the 2012 version because of the syncing capability. So I entered the data from my assistant's file on Ancestry. Researched the people on Ancestry and synced the file to FTM 2012. Well do not do that. All of the census records are linked only by year. I had to rename all of my census records by county. Then from ancestry each source citation is separate. I found it necessary to delete the source citations and in the FTM 2012 program paste them so I had only one that linked to the others. After going through all of this I uploaded 11 people to Werelate and am rather frustrated with the entire process. Is it really worth all of the trouble? I love WeRelate and am dedicated to the one page person idea but it is really too diffcult.

Some automation needs to be added for place pages and source pages. --Beth 21:36, 9 November 2012 (EST)

AMEN!! When I have a source that says 1850 U.S. Census why can't the system be smart enough to match that to Source:United States. 1850 U.S. Census Population Schedule??? I put the location in the citation detail window. That way I have only a limited number of yearly census records in my source list and they are all subject to whatever location I put in that window. Changing all these census sources with every GEDCOM upload is a pain. I've said until the source and place matching gets smarter, I'm not likely spend more time uploading. I still love the concept; but it is much too time consuming. --janiejac 23:42, 9 November 2012 (EST)

So many of us are floored when we arrive at WeRelate. Automating the allocation of sources and places would be a pretty big order. And, if you can figure out how to browse through sources and places you will see the great number of possibilities open to us. For a piece of software to choose the right one for our data is asking a lot. The easier way might be to browse through the sources BEFORE you upload your GEDCOM so that you can adjust it to the WR selection in your other family tree software first. But if you have a gedcom all set to go, the temptation to upload it is just too much. So it's best to let all your sources fall into Mysource and figure out where they really ought to go afterward.

But have a look at templates. Templates allow you to set up a form of words that you can use over and over. You do not even have to put your templates into WeRelate. In the summer I was working on a family of eight children who arrived on the scene about 1800. Each of the eight had families of 10 to 12 and many of those begat another six. I discovered the branches and leaves after I started putting the family on WeRelate. So each census family group from Ancestry was typed--with the Source--onto a StickyNote pinned at the side of my screen. From the StickyNote I could then match my source to a WR Source and, for each individual, paste a Note listing the family census entry with the individual in bold. StickyNotes were also transferred to Evernote where I could build up a biography for each family group.

Since then I have been wondering about writing the templates not onto Sticky Notes but onto WR templates with all the "wiki-speak" typed in. However, these templates might overload our "cloud" or server unless there was a way to delete them when they are no longer needed. And, one can't embolden the varying individual.

Occasionally I wander through the WR forest, browsing other people's family trees. I am amazed at the number of Mysources I find, as well as the number of places written in red. How much more these people could have shared with the rest of us by taking a bit more time and investigating what is in the WR Source and Place banks. --goldenoldie 04:20, 10 November 2012 (EST)


Why not just leave them as MySources? The important thing is that there IS source information. I think it's far less important whether that source info is in the Source or MySource namespace. Jillaine 07:20, 10 November 2012 (EST)

One reason is because then each user basically has a separate page describing the same source so that there could be hundreds of MySources describing Savage's dictionary for example. Perhaps GEDCOM upload should default to making things "Citation Only", instead of MySource? --Jrich 10:02, 10 November 2012 (EST)
That sounds like a good idea. —Moverton 21:05, 10 November 2012 (EST)
I agree also. Great idea, please add this to the suggestions page and I will watch the page for a vote.--Beth 23:09, 10 November 2012 (EST)
This is already true if you do not have a proper "title" field in your structured sources (which happens to me due to decisions I made a decade ago). And I think it's awful. If you reuse several particular sources that really are MySources (i.e. family bibles), then the "Citation Only" system makes them no longer linked to the MySource page that contains the information about the Source (and conversely What Links Here for that MySource loses value). I know why we did it, but be careful of inviting a problem worse than the solution.--Amelia 08:48, 11 November 2012 (EST)

[comment deleted by poster]


Uploading the gedcom and matching the places and sources was not the problem for me. I had 0 errors and matched all of the places and sources that existed on WeRelate. I am suggesting that WeRelate should create pages for the census sources that do not now exist and create place pages for the cemeteries that are on Find A Grave that do not exist on WeRelate. Also in the gedcom upload change the all Caps on the month from DEC to Dec, eliminate the zero ie 01 Dec to 1 Dec and recognize that USA is the same as the United States so I don't have to eliminate all of these pipes. I cannot change this in my gedcom upload without monkeying with it before I upload it; a step that I prefer to avoid. Also that WeRelate change all of the surname pages that are still in red by automatically adding the proper categories. Yes, I can do all of this but it wastes my valuable time. I also believe that if this is done; it would help new users immensely and help our volunteers by reducing the number of pages that need correcting.--Beth 08:44, 10 November 2012 (EST)
That is why I always enter dates in upper case, because of how the software interacts with GEDCOM files. I don't use the GEDCOM upload feature, but I try to be conscious of the fact that others do. Also, if you aren't using the categories, you don't need to bother creating their pages. I just leave the categories as red links. —Moverton 21:05, 10 November 2012 (EST)
I don't understand your reasoning about the dates in upper case. I enter my dates with first letter in upper case and the rest in lower case. However, the gedcom changed everything to upper case or WeRelate did. Haven't checked. Don't like red links so I change them. --Beth 23:09, 10 November 2012 (EST)
Please add these suggestions to the suggestions page or vote for one of the existing suggestions. For example, here is a suggestion for adding FindAGrave cemetery pages and here is a suggestion for smarter source matches.--Dallan 07:58, 11 November 2012 (EST)
GEDCOM uses all upper case letters in its dates, so that is how I enter the dates in WeRelate. Other people (I don't use the GEDCOM import feature) have previously reported that WeRelate is case sensitive and doesn't match up the dates correctly if the case is different. That is why I enter them the way I do. Maybe that explains it better. —Moverton 19:48, 11 November 2012 (EST)
I wouldn't be surprised if the original GEDCOM specification required upper case - but I seriously doubt that there are any GEDCOM readers still out there that are not happy to work with any combination of upper and lower case - provided that the date is otherwise correctly formatted. I was just looking at the Help page for Date Conventions, and that seems to prefer month abbreviations that are in mixed case. Surprisingly, the date related keywords "ABT", "BEF", "EST", "CAL", "AFT", "BET", "FROM" and "AND", are shown in all upper case. Those make more sense to me in all lower case because: they aren't proper things, they qualify the date - but aren't as important, and they would be more visual different. --jrm03063 11:28, 12 November 2012 (EST)
(Correcting myself) - apparently, GEDCOM doesn't stipulate upper case for the date qualifier keywords. --jrm03063 11:35, 12 November 2012 (EST)
I tried downloading my Ancestry.com tree into a GEDCOM file to see what it would do, and the dates appeared as entered. No changes were made to the case. I am wondering how the other genealogy programs behave when exporting to GEDCOM. Perhaps what I had seen other users reporting was just because they were entering their information in all caps in whatever software they were using, and it was exported that way. -Moverton 12:47, 12 November 2012 (EST)
The all-upper-case thing is a relic from the early days of GEDCOM. I remember the arguments from GENETECH sessions in the 1990s, back when so much of the computer world was still case-sensitive. I enter everything in the latest version of TMG in ordinary upper-lower format, but the GEDCOM-creator module there still produces all upper-case for dates & modifying abbreviations. I assume they just haven't gotten around to changing it. Like Beth, it just sort of bothers me, so it's one of the things I tidy up when I go through all the new pages on an import. --MikeTalk 06:54, 14 November 2012 (EST)
May I ask that you review Help page for Date Conventions, and associated talk, and add your perspective there? Thoughts on matters of data format will be more helpful there. --jrm03063 13:09, 12 November 2012 (EST)
I don't believe that the GEDCOM uploader modifies the dates that you enter, nor does it care about case. If it does, that's a bug.--Dallan 01:32, 21 November 2012 (EST)

I have recently volunteered to help out on WeRelate. Here are some thought / findings. I do think the site is stuck in its cellophane wrapper from when it was born and is having difficulty blossoming and developing. It is not attracting new people when it claims to be a Top 10 Family History site.

The site is not easy to use.


Gedcoms (Uploading)

Nightmare to upload!! I tried to upload of family of 4 people as an experiment. I gave up in the end as it was quicker/ easier to put them on individually.

If I was new to the site and had a tree of 50 people I would probably have give up and found an easier Family History site.

Sources & Places

Personally I believe that there are too many sources for Mr or Mrs Average to handle / use. The majority of people use Birth, Deaths, Marriages and census data.

Sources have created places that don’t exist and /or create duplicate places and then create categories that are not required.

Some sources are from the 11 or 12 century – Manor records?? How can this be relevant?

What is needed is to look at the historical place and the place today are they the same or to different. We are trying to add people born in, for example, 1814 to a towns or a village. But today it’s probably a city. We are also trying to add people born in, for example, 1814 to a town or a village. But today does not exist or has changed counties or even countries. It’s like putting the apples with the oranges, yes they are fruit but should they be in the same basket? Perhaps there should be some hierarchy for places –eg City of London, New York City as Top with the districts places feeding in? Rather than Wandsworth being separate to London, it should be a district/area of London. A small village in Wales used to be split into two parishes today its one village, how do you add some to WeRelate born in 1790? Old or New.

Too much emphasis on USA – Is it the default for all places? If you add a person born in London it thinks you mean in the United States. I believe the default for Wales was USA

Places perhaps should not be manually created, only automatic. Some people would find it’s easier to create a new place than search for the right one.

I noticed that a lot of errors – farmer as a place, Y as a place etc have been added from Gedcoms where the person is not using the site – last contribution is in 2008 or 2009. Should these errors either be deleted, left as wrong for ever or the person contacted. For someone to go into each individual record of farmer as a place and amend it would take a long time.

You are very quick / heavy handed on mistakes – it’s a big deal - the world will end because you have not used a certain template or relinked a place wrong, We are human not machines.Mistakes happen.


I enjoy using the site and the community created but find it totally frustrating. Over to the committee.--Colin Madge 13:13, 29 November 2012 (EST)

This is going to generate a lot of important commentary I think. Do we want to carry the discussion on here, move the whole thing elsewhere, or move it in pieces to discussion locations for gedcom upload, places, and sources respectively? --jrm03063 13:41, 29 November 2012 (EST)



Speaking as another newbie, and also as someone else who sees the potential in WeRelate, I think these suggestions ought to stay together. If they are separated, each of the problems will lose weight and not receive the consideration it deserves.

If the discussion is moved elsewhere, especially if it is moved to "the committee", we ordinary folk won't see it and we will be unable to point out to "the committee" where they are failing to take our needs into their decision making.

One of the problems is that it is so easy to concentrate on one's own tree and never see what else is going on on the site. How many of us ever look at the Home Page and see what the Featured Page for the Week is? Or what the subject of the Genealogy Contest is? I have yet to figure out what the contest is about because the principles of the contest don't appear on the home page--like so many other things, you have to travel elsewhere to find them. You can even choose never to look at the topics on the Watercooler or in Suggestions, or never to inspect the data contained in Places or Sources beyond the names of places and sources you may need.

It is too easy for someone to present WeRelate with a huge gedcom full of imprecise data and leave it here and go off and continue to do his/her genealogy somewhere else, never considering the mess they have left behind tempting the rest of us to, maybe, fix it up.

We all ought to take off our blinkers and figure out how to run the race as a group, not as invidividuals trying to expand our own genealogical projects to the tenth cousin or to the nth great grandparent.

--goldenoldie 16:00, 29 November 2012 (EST)



Ok - here goes...

  • Part of the reason that our learning curve is steep is that there's rather a lot to learn. Both the genealogy specifics and the media-wiki underpinning. We can't make media-wiki easier. The genealogy specifics of WeRelate are laid out in a way that - initially - is unfamiliar. I don't think most genealogy programs expose the family object that connects people (although the software must implement something like it under the covers in all systems). This is ultimately a plus however, since systems like the "ancestry.com" interface wind up obscuring operations with the family. Wikitree (a wiki that doesn't seem to expose the family) winds up creating situations where the child is aware of their respective parents - but the parents aren't directly aware of each other. I think the "power user" eventually will appreciate the separate page for defining family connections. Still, maybe there's a way to create a simplified newbie interface that hides access to the family page/object in the most common circumstances.
  • I think we can get some statistics on the number of folks who attempt a GEDCOM upload but never complete it. This would be good information to know.
  • I don't think the place pages default to US locations - it's just a situation where the current database is more complete for US locations.
  • Unforgiving of mistakes is something we can all work on. Some examples of well handled and/or badly handled exchanges with newbies might be useful. Courtesy shouldn't be an issue - but it is. The Overview committee seems to have been created (at least partly) with that in mind. Unfortunately, they've defined their scope as solving disputes. That's too late. On stuff like this, a more pro-active approach is going to be needed. Newbies who get shabby treatment, are just going to leave.
  • Not sure that preventing users from creating places is a great answer. On the other hand - tools that find unresolved place names (red links) so that they can be addressed systematically might help. Other problems may be subject to similar semi-automatic resolution. We used to have huge numbers of duplicates, but that's been dealt with.
  • There are a number of hallmarks of bad ancient GEDCOM uploads that I've accumulated on my home page. "Y" for death is but one, there are a number. We should try to work on those, but I think we are. It's a work in progress.
  • I admit that the GEDCOM upload process is a little tedious - but we've had painful experience with folks uploading large crappy GEDCOMs. I think the system is pretty good at exposing obvious problems, that most folks would probably want to fix. I wonder if there's a better way to do this though. Instead of starting with the interface that lets the user work on their GEDCOM here at WR - maybe the first step should be to just process it for errors and ship the errors back in an e-mail? If they WANT to start working on it here, that's fine, but that's probably not the case at first.

--jrm03063 17:26, 29 November 2012 (EST)


I'll try to respond to a few of the issues above -- I think they bring up good points.


Gedcom upload stats

Less than 50% of the gedcoms that are uploaded make it all the way through the import process. I just did a check of 20 gedcoms that were uploaded more than 45 days ago and are likely abandoned:

  • 50% of them have too many errors and warnings to be imported.
  • 20% of them have mostly living people and just a few dates on the dead ones.
  • 15% of them have a lot of (more than 40) potentially-duplicate families that need to reviewed.
  • 15% of them have no issues.

I don't think we want gedcom's in the first two categories. Back in 2007-2008 we didn't have these checks, and that's where a lot of the messy data came from. I'm not sure how to handle the potential-duplicate problem better than we're handling it now. See below for some ideas on simplifying places and sources.--Dallan 15:12, 3 December 2012 (EST)


Place matching

What if instead of red-links on places, the system were to match the place to the closest place page it could find, both during gedcom upload and possibly also when you edit pages online? And we simply remove the Places tab from the gedcom review screen? So if I have "Not-found place, Minnesota" in my gedcom, the system would link it to Place:Minnesota, United States?--Dallan 15:12, 3 December 2012 (EST)


Sources [7 December 2012]

I've been thinking about this one for awhile. We currently have 930,000 source pages. These came from a mass-import of FamilySearch's Family History Library Catalog many years ago. But only 15,000 of them have been linked to from person or family pages. And in fact some data from FamilySearch suggests that nearly 50% of the films in their catalog have not been requested by patrons in the Family History Library even once. So what if we were to delete all Source pages that had never been edited by a human or linked-to from another page? That would make matching sources much simpler, at the expense of people having to manually re-add sources occasionally.

Alternatively, or in addition to removing unused sources, we could remove the Sources tab from the gedcom review screen and not allow matching sources during gedcom upload. (Not sure if I like this idea.)--Dallan 15:12, 3 December 2012 (EST)

I approve of the idea of deleting the unlinked or unedited source pages. --Beth 00:28, 4 December 2012 (EST)
I think unlinked/unedited source pages at this point are largely useless to us, and could get behind deleting them. Please don't remove the Sources tab from gedcom - I don't see how that would do anything other than create a significant amount of extra work for people actually wanting to use WR sources.--Amelia 01:29, 4 December 2012 (EST)
Well now, as one of the beneficiaries of the "unused" Source pages, I would argue against their blanket deletion. There are at least two auto-generated Source pages where I have entered the only Person or Family pages that link to them - perhaps 5 or 6 years after they were generated. I was glad that they were already in the database with proper links to repositories. In both cases these were books or manuscripts rather than microfilm archives. In one case I made no edits, in the other I made a minor edit. I would highly recommend that rather than deleting all unused Sources, you consider listing them last in the Source searches.
Just referenced another previously unused Source (another book) today 8-). --Jhamstra 20:45, 5 December 2012 (EST)
I think I agree with this sentiment. If there's a good reason to drop unused sources from being in the general pool - we would still like to be able to have them available for review before we go ahead and try to create a new source page. Even if a film has never been retrieved - maybe its not because it wasn't useful - maybe it's because no one knew what it was useful FOR? --jrm03063 12:12, 4 December 2012 (EST)
I would make a similar recommendation regarding Places. And while we are on this topic, my pet peeve with Place matching is that if I enter "Michigan" (for example) I am bombarded with a huge list of places within Michigan before I get what I usually want which is "Michigan, United States (state)". I have been tripped-up more than once in data entry because I got some suggested place within Michigan (or Friesland or wherever). Try entering California or United States and see what happens - this is VERY annoying. Please don't offer suggestions that are more localized than what I entered, or else offer them after the "obvious" to me choices that actually match what I entered!
--Jhamstra 11:35, 4 December 2012 (EST)
There may be challenges to doing what you want. Unless we knew for certain that people follow a reliable practice of strictly entering the most narrow subdivision first, then the next level, and then the next - without omitting anything. Perhaps, instead of a field where the software tried to guess from within a huge database - a place selection dialog - more like a file dialog - that started from the most coarse level and worked down? Hmmm.... --jrm03063 12:10, 4 December 2012 (EST)
I favor keeping the sources in the database. The entries are likely more helpful (due to more metadata and links) than the typical hand-entered source, I imagine. If the concern is the impact their presence has on search results, I'd suggest changes that treat that without removing them (e.g. have them come after the already-used sources in the results list). I think the fact that only 15,000 have been used so far is mainly a reflection of the limited number of users that WeRelate has attracted so far; hopefully many more will use the site in the future. --Robert.shaw 14:56, 4 December 2012 (EST)
You captured my thoughts on the issue. I don't think the source pages should be deleted just because they haven't been used yet. I have found few opportunities to link my tree with anyone else's on this site which means I'm also looking at sources that no one else has because they may be very local in nature (eg. English parish registers). I would have to spend more time entering sources than I do now. Also, I don't know how those numbers were counted, but if some films (or even copies of the original source) are already widely available in libraries or online, those films may never be requested by anyone. -Moverton 15:17, 4 December 2012 (EST)
Because a few previously unused sources have been utilized is no justification for maintaining the massive source database. One may create the source page. Volunteers have in the past spent months attempting to clean up the source pages. That project was never completed. I suggest you move the unused sources to the archives. --Beth 22:09, 5 December 2012 (EST)
If there were a large cost to having so many unused sources, that indeed would seem to be a reason to remove them. But I doubt that the space they occupy is an issue, and it's not clear there is any other noticeable cost. If people were putting effort into cleaning up unused sources, then that was a very low-return activity, and definitely something to avoid wasting effort on. But the existence of unused sources doesn't require anyone to work on them; they can safely be ignored until someone actually wants to use them in a citation. --Robert.shaw 00:02, 6 December 2012 (EST)
The "cost" that was originally cited was not a space issue but that their presence makes matching sources more complicated. AndrewRT 18:47, 6 December 2012 (EST)
I think Moverton has made a significant rebuttal, namely that significant swaths of the world are under-represented, and so there are gobs of unlinked-to sources because few people from certain countries have signed up as beta users of WeRelate. Further, I would like to see specific examples detailed of the problem because my gut says that the problem lies somewhere else than in the number of sources. Having one, two, or a handful of examples would make it more likely that everybody is addressing the same problem, and not assuming one issue when it is really another that is the problem. Some specific concerns I have based on the data I have on my home system (note: I can only talk as a non-GEDCOM uploader: I tried one GEDCOM upload and thereafter avoided it like the plague) are:
  • I don't title any of my census sources using the county name (presumably a very common source). So my GEDCOMs are never likely to match the source pages for censuses easily.
  • I title some magazine articles using the article title and some after the magazine name with the article title in the detail, etc. I have hundred of references to NEHGR. Should I match to NEHGR on WeRelate or do I match to the specific article page (which often are not there)?
  • I don't know which field in my genealogy software corresponds to the "Record Name" field in a WeRelate source citation, so even if I wanted to setup my GEDCOM to match WeRelate sources, I am not sure I would know how to do so.
In other words, I believe the essential difficulty is not that WeRelate has 930,000 sources, but that people at home don't follow WeRelate guidelines. My suspicion is that you could remove the unused sources, to the detriment of users not yet active, and gain nearly nothing in terms of making it easier to match GEDCOM sources. --Jrich 22:27, 6 December 2012 (EST)
Thank you Jrich for stating what I, too, suspect is a major part of the problem, as well as clarifying some of my qualms about removing "unused" sources.--GayelKnott 23:21, 6 December 2012 (EST)
Jrich, I think this helps me to understand why there are two widely diverging views on whether unused Sources are actually a problem. Like you I do not do GEDCOM uploads, preferring to create and edit my contributions in situ. So for me when I do a Source search I usually converge quickly to what I am looking for. However I can readily imagine that when doing Source matching as part of a GEDCOM upload there could be a flood of irrelevant candidate Source matches.
From the foregoing observations I think the solution is also fairly obvious - when doing Source matching as part of a GEDCOM upload give preference to candidates:
1) Sources already cited by this user
2) Sources that have been cited by other users
3) Possibly other Sources but only if few candidate Sources have already been found.
Also I have seen several previous comments from you regarding using Sources that are journals, etc. For journals, magazines, newspapers, etc I never cite Sources - I simply give Citations. Maybe this is a cop-out but it seems to work well for me and completely avoids hassling with other people's conventions regarding granularity of the Source (Volume vs. Issue vs. Article?).
--Jhamstra 00:33, 7 December 2012 (EST)

It sounds like most people favor ranking source results over removing unused ones. Sources that are linked-to are already boosted in the search results screen, but I could increase the boosting. I just checked a couple of gedcoms, and most of the time the correct source appeared in the top few results. Increasing the boosting of linked-to sources would improve this.

However, linked-to sources are not boosted in the drop-down auto-complete list. Neither are linked-to places. I could change both of these lists to rank sources or places by the number of pages linking to them, just as they are ranked in search results. Thoughts on this approach?--Dallan 12:03, 7 December 2012 (EST)

I believe the two situations are fundamentally different, and probably different ordering apply. When I am working with the drop-down list of sources I am just trying to type a small amount to get the desired source. First of all, unlike GEDCOM loading, I have to be aware of WeRelate titling conventions, so that if it is government records, I start typing part of the town, but if it is a book, I start typing the author's last name, if it is a periodical, the name of the periodical, etc. Spelling and case have to match, or the drop-down list will not work. A GEDCOM can have "Savage" or "Savage, James" or "James Savage" in the author field, and "Genealogical Dictionary" or "First Settlers in New England" in the title field, etc., and that should work. For the drop down list, I pretty much have to type an exact subset of "Savage, James. Genealogical Dictionary of the First Settlers of New England" to make it work. The intuitive thought process is along the lines of "starts-with", not a field by field matching that is used in GEDCOM matching. Ranking previous choices at the top of the drop-down list probably does most of what you would expect ranking by linkage to accomplish anyway, and any disruption of the starts-with algorithm by what other users happen to do, is going to be confusing and create indeterministic results as linkage counts change.
Places are different than sources in that the current algorithm is not "starts-with". But even there, it seems like the benefit of ranking by linkage count is already covered for drop-down lists by placing recently used items at the top. Other comments at WeRelate:Suggestions/Improve dropdown Place search. --Jrich 12:29, 7 December 2012 (EST)

Statistics page [21 November 2012]

We currently have a statistics page (possibly a standard wikimedia page) which states (my emphasis added):

"There are 6,406,872 total pages in the database. This includes "talk" pages, pages about WeRelate, minimal "stub" pages, redirects, and others that probably don't qualify as content pages. Excluding those, there are 3,018 pages that are probably legitimate content pages."

Clearly we have far more than that - the syntax seems to exclude Person: and Family: pages, for instance, whcih we'd want to include as "legitimate content pages".

Is there any way we can tweak this so it calculates a better figure? AndrewRT 16:56, 17 November 2012 (EST)


Its possible that the 3,000 something number may mean fully sourced pages, ie those with zero unsourced events. Sadly WR isnt at the point yet where the bulk are fully sourced.--Daniel Maxwell 17:20, 17 November 2012 (EST)

That page is a standard page of the software package (MediaWiki), and the number for "legitimate content pages" is the count of pages that have no prefix (like "Person:" or "Place:"). On most wikis, like Wikipedia, this is the number of most interest; it is the number of articles. On WeRelate it isn't very important, but getting better statistics is likely pretty far down in the list of desired improvements.--Robert.shaw 14:22, 18 November 2012 (EST)

It used to be that when did a search on all namespaces (click on Search > All), you'd get a total page count for each namespace. This appears to be broken. I'll look into it. And yes, fixing the stats page is not a high priority.--Dallan 01:49, 21 November 2012 (EST)

Removing Wikipedia content [18 November 2012]

Following on from the discussion above, I wanted to spin out this comment please from Jennifer (JBS66):

People have expressed fear of adding their own information to a page containing WP text. They are afraid to touch or "mess up" the WP template and don't feel comfortable removing the template from the page.

I do think we could do more to encourage people to "move on" from Wikipedia if we are in a position to write a better article for our purposes - i.e. more focussed on the genealogy. Should we supplement the text in the various templates and help pages to encourage this?

Related to this, could we also do something about the position of the WP text - perhaps relegating it to the bottom of the page in a separate section, so that the WP information takes precedence?

AndrewRT 17:13, 17 November 2012 (EST)


In working on Place pages I have found many a lengthy Wikipedia introduction or history section that starts with all the vital facts we would like in WR and then, in the last paragraph, makes a comment on the recent success of the hockey team, or mentions the name of the current mayor, or relates an unfortunate fatal accident at a dangerous intersection. IMHO these are the facts that WeRelate does not need.

I have started adding a new intro to the Wikipedia quote: The following section is based on an article in Wikipedia (complete with the WP link). This allows me to drop offending last paragraphs and also to rephrase sentences slightly, and insert distance facts that the bot omitted just because they are phrased in "km" and "mi". I try to remember to add the wiki-notice template at the end. I admit to accidental omissions on this point.

But in Section 1.7 of the WR Help:Place pages there are detailed instructions as to how to edit the Wikipedia article. It seems to infer that any quotes from Wikipedia must contain ALL their links to other Wikipedia articles. Sometimes their use of little green arrows seems to go over the top. It is this consideration that makes me stop and wonder if I should really drop that last para when the rest of a long piece is a well-written explanation of what we want to know. --goldenoldie 02:26, 18 November 2012 (EST)

Goldenoldie, I would just like to clarify... When you add this text from Wikipedia, are you placing the text directly on the place page, rather than using either the source-wikipedia or moreinfo wikipedia templates? --Jennifer (JBS66) 14:15, 18 November 2012 (EST)

I think we need to hear again from the oversight committee first - I remain perplexed that the voting choice above was put to the community without any apparent community level discussion. To my mind, it is little more than a re-vote on what was decided several years ago. When that exercise is concluded - we can perhaps start a more meaningful and useful discussion on how best to use WP - instead of revisiting old biases. --jrm03063 12:28, 18 November 2012 (EST)


Weekly Brick Wall [25 November 2012]

I have a few "brick walls" in my genealogy that have stymied us for years. I have been following the Genealogy Contest with great interest, and I was wondering if it might be possible to set up a weekly "brick wall" - where we spotlight a person who has been difficult to track down/connect to parents, etc., and get the help of the community to figure things out. I don't know if I'm a good enough genealogist to provide help, but I'd love to have some help. Would there be interest in doing something like that, especially from the side of those with the skills to help out? -- Jdfoote1 21:51, 18 November 2012 (EST)

I am not interested in a contest per se, but it would be more interesting to me to have a big list of people that present problems to others, where one can try to help based on their family interests or knowledge of a particular area. Then if you are going to have a contest, make it based on the best contribution to any one of those people. I.e., not just famous people, but also the normal people who may not have books or wikipedia articles written about them... The problem would be to keep the list from getting too big. Maybe each user can have only one person active on the list at a time? The winners would be examples of how collaboration works. --Jrich 23:08, 18 November 2012 (EST)
I like the idea of brick wall help. One idea might be to have users add their brick walls to either the featured page nominee list or establish a similar nomination page for the contest. That could accomplish a few things -- a stable of ideas for those efforts, incentive for the nominating user to do as much on the existing page as they can, two levels of focus for interested users to help (both the current nominee and the list), and the work required would theoretically make it self-limiting for users wanting to add their own brick walls.--Amelia 11:15, 19 November 2012 (EST)
I really like these ideas. I put up an initial page at Brick Walls, please take a look, and feel free to edit/improve. I really like Jrich's point that it would be good to have an entire list of brick walls, where you can provide help at any time, but I also think that having a weekly featured page can be helpful, and can (theoretically) build a community around collaborating on one page - it adds a little excitement. I tried to create a format this is the best of both worlds.
I lay out some rules for what state a page has to be in before it can be featured, and for how many pages/user can be submitted. Hopefully that leads to a useful and interesting list. What do you think? -- Jdfoote1 12:19, 19 November 2012 (EST)
What a great idea. Would love to see a Weekly (or monthly or whatever) featured page, as well as a list. --GayelKnott 15:06, 21 November 2012 (EST)
That's a good point - does anyone have an idea of about the right length of time to have someone be "featured"? Is a week too short? A month too long? Should we start with a week and see how it goes? -- Jdfoote1 11:23, 22 November 2012 (EST)
I dont think I would trust such a contest. Alot of difficult parentage mysteries should be handled by trained genealogists; I fear instead it would be hamfisted reasoning that would lead to bogus parentage being added, or worse yet, GEDCOM guesswork imported onto the site. Its one thing to have a collaboration request page, but really what youd have is people asking for free genealogical work that they really should have done through a pay service. User:DMaxwell
The research result is either supported by the facts or it isn't. It doesn't make any difference whether you paid for it or not. There are plenty of very experienced genealogists who don't work at it professionally. Having said that, people should have reasonable expectations about the willingness large quantities of research gratis. If it's something where a fresh set of eyes will help or where some specialized expertise can be brought to bear quickly, the contest might bear fruit. If it depends on someone donating tens of hours of free research to grind out an exhaustive search, it's probably not reasonable to expect people to be willing to donate at that level. Tfmorris 16:02, 22 November 2012 (EST)
But thats the problem. Most people (yes, even here at WR) are not qualified to judge what is or isnt sound genealogical evidence. This is why we have instances in the LDS FamilySearch database of 'connections' of English colonists to supposed 'parents' back in England. The average person sees 'John Smith' baptized somewhere about the right time, and concludes thats him! Ive solved the mystery! When in reality its not that simple. I oppose the creation of a brick wall contest and instead suggest a collaboration request page. User:DMaxwell
It's not about the "qualifications" of individual researchers, its about how well the research meets The Genealogical Proof Standard. I would suggest reading both the Standard and the associated article. There are also many other discussions of The Genealogical Proof Standard on-line (try Google), and in articles here at WR. Then try reading some of the articles published in journals like NEHGR, NGSQ for examples of how they are used, often by people who are not professional genealogists, but whose research has been accepted by professionls.
As far as "solving" problems, many of my past break-throughs have come from other genealogists who have said things like, "Have you tried these records?", or "Have you considered this possibility?" I don't think anyone is asking for "free" research. --GayelKnott 16:40, 22 November 2012 (EST)
I am perfectly aware of the GPS, thank you very much. What I am saying is that some of what has already been added to that page is way over the head of even a strict semi-pro amateur. To expect some of those to be solved I think is wishful thinking. But my original point still stands. Having a 'contest' is just asking for trouble with shoddy research that may be added so one could 'win'. The rest of my point is more a side issue related to my thought that a Wikipedia style Original Research policy, at least past a certain generation, should be adopted at some point, but thats a fight for another day. User:DMaxwell
DMaxwell - good points. Would things work better if we didn't run it as a contest (something that I wasn't planning, anyway)? I'm thinking it would be more like a list of Brick Walls, with one that's featured, sort of to encourage people to pay particular attention to that one. Thoughts? -- Jdfoote1 07:58, 23 November 2012 (EST)
Mr Foote, thank you for addressing my point. I suppose really my only concern was the idea of a contest would lead to bad solutions being introduced into WR. I didnt intend to insult anyone or say that it was an inherently bad idea. I oppose rather strongly that WR become 'like all over genealogical sites' and remain a giant mass of guesses. user:Dmaxwell
I'd suggest enhancing the instructions and example to help people write better queries. It's not trivial to write a good query and often just the process of writing it down is enough to jog the mind to think about possibilities not explored. We've got the benefit of being able to easily link to existing information, but I don't think "I want to know who [link:this person's] father was" constitutes a good query. The model should be more along the lines of the problem statement that one would give a professional genealogists to start their search or even the genealogical queries columns that were popular in the paper world. The basic template is: 1) here's what I know, 2) here's what I want to find and 3) here are all the places I've looked so far, all condensed down to be hyper focused on the problem to be solved.

First Featured Brick Wall [23 November 2012]

Let's give this Brick Wall thing a try - I think the best way to learn is by doing.

I've added our first Featured Brick Wall to Brick Walls. Our first brick wall is Person:Leonard Schmidt (1). Please take a look at his page, and see if you can help out, or if you know someone who could.

We are looking for information about his birth, which was supposedly somewhere in Baden.--Jdfoote1 08:26, 23 November 2012 (EST)


Thanks for selecting my gr-gr-grandfather as the first brick wall. DMax, don't worry; I don't let any shoddy claims stick around long, and I'm looking as Gayelknott described, for something along the lines of "have you tried..." (something I'd not yet considered). Fresh pair(s) of eyes. Jillaine 09:54, 23 November 2012 (EST)

Volunteer opportunities [9 December 2012]

I wanted to highlight two patrols that are in need of volunteer assistance:

Welcoming new users: This group adds a welcome message to the pages of all new users who sign up to WeRelate. This message helps to guide new users to help and tutorial pages. Also, the Welcoming group checks new user pages for spam and monitors user talk pages for questions. If you have a few minutes to spare each day to assist in welcoming new users, please leave a message on the Welcoming new users talk page.

GEDCOM review: This group manages the GEDCOMs that are imported to WeRelate. Files are reviewed to ensure they meet WeRelate's quality standards before upload. Volunteers also assist users with their questions about the review process and communicate about problems with their files. It would be helpful for the prospective volunteer to be familiar with the GEDCOM upload process. If you are interested in volunteering for GEDCOM review, please leave a message on the GEDCOM review talk page.

These are just two of our volunteer groups. To read more about volunteer opportunities available at WeRelate, visit the Maintenance portal page. Your assistance would be a great help to the WeRelate community! Thank you, --Jennifer (JBS66) 09:33, 1 December 2012 (EST)

Regarding both of these, is there any benchmark for how well we want to do and are there any stats to compare against this? I'm wondering if having these would encourage new volunteers in the areas most needed. AndrewRT 14:53, 4 December 2012 (EST)
Do you mean how well we want to do in terms of the number of volunteers needed vs. the current number of people volunteering? --Jennifer (JBS66) 07:35, 5 December 2012 (EST)

Yes, and in addition for instance with welcoming new people, how many have joined, how many were welcomed within the hour, day, week etc, average time until welcomed, targets etc. AndrewRT 15:17, 9 December 2012 (EST)


Genealogists from 1907 and their interests [1 December 2012]

This article which hit the blogosphere today might be of interest to other WR members.--goldenoldie 14:06, 1 December 2012 (EST)


Simplifying GEDCOM Import [8 December 2012]

As suggested in several places in the "Ooh how to make Werelate better" section above, the present GEDCOM import procedure can be rather overwhelming for a family historian new to WeRelate. For the long-term success of this site, we need to make things easier, especially in a user's initial encounters, and making import simpler would be an important part of that. Here I want to discuss improvement of one aspect, the review interface that the GEDCOM uploader sees.

First, consider that there are at most two significant activities an uploader has to do between specifying the file to upload and the data being published. These are: (1) check the warnings about the gedcom, making corrections as needed, and (2) evaluate the possible duplicates that the system presents. The other tabs on the review interface support other, optional actions. In particular, the user doesn't really have to review, link, or add places or sources; the default handling by the system is adequate if not ideal.

Despite this essential simplicity, the novice user is presented with a sequence of eight tabs (and steps) to ponder, learn about, and deal with. This is much more of a burden on the new user than is necessary for him or her to complete the zero to two required steps. (There are zero things required if there are no warnings and no matches; if the user doesn't want to deal with more details, all that's necessary is to click a button to send the data off to admin review.)

Because of this, I suggest enhancement of the review interface so that the initial presentation is much simpler. If the GEDCOM has too many warnings to be accepted as is, then the initial screen should simply say this and give guidance on resolving it, perhaps with a button or tab which takes the user to the warning list as it exists today. If the GEDCOM has warnings, but not too many, then the guidance would be slightly different (saying they need to be examined, and that re-upload should be done unless all are benign). Only after the user declares them all benign would the existence of the next step be made evident. If there are no warnings, nothing need ever be presented regarding them. Only after the warnings, if any, are handled would the family matches be presented.

This is not to suggest we get rid of any existing functionality. Actually, the new presentation might be mainly a new layer initially hiding the existing interface which would remain available. The new screens might have a link/button to access "full review", or some similar navigation (with an easy way to get back to the simpler screen). Those who want to use something like the current interface (which isn't all that bad once you get familiar with it) would only have to deal with one click more to access it.

Do others agree that GEDCOM import needs simplification? Is something along the lines sketched likely to do that well enough? Are there other approaches or variants that might be more helpful? -Robert.shaw 17:33, 2 December 2012 (EST)

I agree that it's daunting, but there are real data points that can inform this discussion - and we're not using them. We know who signed up, we know what their contributions are, we know if they attempted to load any GEDCOMs or not, the size of the GEDCOMs they tried to load and we know if they've gone dark for some period. We should attempt to profile the contributions from users who appear to have dropped off the radar - and see if there's a discernible trend as compared to users who stuck around. Historically, when anyone could upload anything, we were overwhelmed by huge amounts of dubious content. Very recently, wikitree had to stop accepting new users for that very reason - and in my experience - I've found wikitree frustrating since someone uploaded a bunch of my ancestry and now has disappeared - so it will be six months before they're considered to be "unresponsive".
We DO KNOW - that when the bar for loading a GEDCOM was low - we acquired a ton of material of a generally low quality. It was also the case that a lot of the contributors of that content then simply disappeared. Here are the top entries in my table of "network" overlap, along with the date of that person's last contribution, and if a GEDCOM upload was indicated somewhere on their last page of contributions:
Colby Farrington 7624 1 Nov 2012
Clover 5735 15 Oct 2012
Claudiakerr 5462 28 Jul 2009
Aabh 5382 25 Nov 2010
New.incarnation 5031 24 Jul 2012
Brlangston 4983 8 Jul 2012
Klingonpixie 4951 31 Aug 2012
Jhamstra 4925 2 Dec 2012
Genealogist84 4825 28 Jul 2007 (upload only)
Katharine958 4790 1 Dec 2012
Drewwalkerski 4297 29 Dec 2007 (upload only)
Jolayne 4285 2 Apr 2007 (upload + 7 edits)
Rjfoxx 3519 14 Jul 2007 (upload only)
Tammyhensel 2997 15 Nov 2012
Gtcurtis 2679 12 Oct 2007 (upload only)
Ravencrest 2151 8 Mar 2008 (upload only)
Mbgegan 2051  ?
Coggazone 2048  ?
Rwillimon 1803 5 Dec 2007 (upload only)
Rtengel 1751 2 Dec 2012
Jrich 1596 2 Dec 2012
Allwayslearning 1582 29 Aug 2009 (upload + 3 edits)
Jeffhomes 1548 24 Sep 2011
Butch57 1541 29 Mar 2009 (upload only)
Dlongmore 1540 23 Sep 2012
Jameslhahn 1493 9 Mar 2008 (upload only)
Susan Irish 1447 2 Dec 2012
Seranade 1412 19 Feb 2009
Holyhabanero 1403 10 Apr 2007 (upload only)
Jaques1724 1319 2 Dec 2012
Gregobhte 1305 21 Jan 2009 (upload + 5 edits)
Since I'm on the list, I'm trying to figure out what this table means, particularly since I've never uploaded a gedcom to werelate. Could you clarify?--jaques1724 20:28, 2 December 2012 (EST)
Sure. The middle number is the number of pages that that user and I are watching in common. The date is the date of that user's last contribution to werelate. If the last page of contributions for a user contained changes related to a GEDCOM upload, I added the note "upload" and indicate how many hand edits were performed subsequent to the upload. I indicated everyone on my network list in order to give context to the relative number of folks who basically only did uploads - and those who have (or did) - continue to be active editors. --jrm03063 21:45, 2 December 2012 (EST)
Many of us are aware that lots of poor GEDCOMs were uploaded in 2007-2009 (before the review process was begun). I wasn't suggesting reducing quality checks in the least, just simplifying the mechanics so that those mechanics are not such a deterrent. Keeping a complicated import interface in order to have uploaders prove commitment to WeRelate (as a sort of "initiation") doesn't seem to be in the best interests of WeRelate. --Robert.shaw 15:45, 3 December 2012 (EST)
Back when WeRelate was still new, the "quantity vs. quality" question came up regularly. I think that's been resolved, by consensus, firmly on the side of "quality" because sheer quantity, as we now know, results in a large proportion of junk that only makes more work for the regulars here. So I'm not in favor of making things "simpler" if that's going to encourge a return to drive-by GEDCOM-ing -- but I'm glad to see that's not the issue this time. That said, it's true that the appearance of all those tabs on the first and only screen the new uploader is confronted with can be a little daunting. And since the mandatory tabs -- warnings and duplicate families -- aren't even the first tabs in the sequence, it's not terribly obvious what the new user is expected to do next. Replacing the present screen with several layers of simpler screens -- one task or choice per screen -- makes sense. If the GEDCOM has no serious problems, the user would be led quickly to the optional chores (which I never skip because I'm obsessive . . .), which could be presented one at a time or at least in a smaller group with an introductory statement that they were optional. If there are serious problems with the upload, the user would never get far enough in the process to become confused; he would be sent back to the beginning, and would either fix things or not. And if he can't be bothered, that's probably better for us. --MikeTalk 08:39, 4 December 2012 (EST)
This makes good sense to me! I had about quit uploading because it was SO time consuming. I thought I had to create place and source pages either before I started or while I was reviewing. I didn't want to use MySource because it couldn't later be replaced with a regular source. But I understand that is being remedied so maybe I could try again. But if the upload could be set up with several layers it could make the process a whole lot more intuitive for the new user! --janiejac 10:38, 4 December 2012 (EST)

What if we were to change the order of the tabs to: Overview, Warnings, Family Matches, Import, Places, Sources, People, and Families? Is that all we'd need to do, or are you thinking of other things as well?--Dallan 12:10, 7 December 2012 (EST)

As a start, how would it be to have "Warnings" on a separate first screen, all by itself -- assuming there are any warnings? This would require the uploader to deal with those issues before going any further. Or, if there were too many warnings, the list of them would be accompanied by a notice to go back and start over. (As a matter of good design, "Overview" might need to be de-tabbed and simply placed in a box above the warnings info, where it can't be overlooked.) Once the warnings are taken care of, the next screen would show the other tabs in order of priority -- family matches (with "NECESSARY!" or something above it, maybe), then the optional-but-recommended ones.
You know, you might also want to retain the current screen as a "Expert Mode" thing, with a new multi-screen version as the default for novices. (But I would still, at least, reorder the tabs.) --MikeTalk 19:47, 7 December 2012 (EST)
I really like the idea of Novice and Expert versions, although I'm not sure I would classify them that way - maybe Basic and Advanced would be better. Even as a newbie, I cared about place and source matching and it was helpful to know that I needed to do source matching before family matching. And it sounds like some experienced people are not finding a lot of value in source matching, so maybe they'd prefer a Basic version.
Could you offer an intro screen with links to Basic and Advanced and let each user pick? It would require some info to help them pick. I know it is a pain to support 2 versions of something, but I assume there would be little additional code, and it would serve the purpose of not overwhelming people who are interested in loading their data, but not doing source matching or editing.
I agree with Robert and Mike that Warnings should be the first thing people see - for both Basic and Advanced. It is the first thing that I check, followed by the Overview (to check for the number of exclusions). Maybe this means moving the Warning tab first, or showing it on first access (even though it is the second tab), or some other design, as suggested by Robert.
I would keep the order for the Advanced version - it is important to do edits, source and place matching before family matching, or those changes will not be incorporated in the merges.
Perhaps we should replace the hoizontal array of tabs with a vertical stack of numbered buttons to reinforce the order in which tasks should be addressed. --MikeTalk 16:05, 8 December 2012 (EST)
The big question if there is a Basic version is whether or not to include Place matching. On some of my uploads, over 90% of my places were automatically (and accurately) matched, so it was nice to have. But if you are going to automatically match places, you have to give users a chance to review them and that means another tab on the Basic version. It doesn't matter much to me, because I would continue to use the Advanced mode.--DataAnalyst 12:31, 8 December 2012 (EST)
I've come to believe the accuracy (or not) of GEDCOM import place-matching is largely a factor of how carefully or accurately the data was recorded in the original version the user compiled before uploading. I've seen family groups on WR in which page after connected page shows nearly every placename in red, because the way the information was entered was bizarre (or misspelled, or idiosyncratic) and the uploader never returned to clean it up. Often, it's not even clear what placename the uploader had in mind. Once you've done a few GEDCOM uploads (and I've done dozens), you'll find yourself entering data in your desktop program with its eventual destination on WR clearly in mind. --MikeTalk 16:05, 8 December 2012 (EST)

Bernard Fidelis Damian Keller [7 December 2012]

Hello! Between Willy Eberhard and me wew have broken the door wide open with new info about the Keller family from Baden switzerland....back to the 1600's! Where do I begin to start adding to this amazing document? Bernard's name is Bernard Fidelis Damian Keller...name change needed His father is Caspar heinrich Keller b 1750 his wife is Clara Helena Herzog also born 1750 born and married in Baden Caspar's father is Johannes Baptista Keller. This is a start...many children & siblings found. I have been taking photos of the individual recordings of names/events/ from the Baden Catholic Church archive microfishe....can we store the photos here somehow? I have the page numbers and volumes if that would help too.

Advice needed....--Keller-powell 01:09, 7 December 2012 (EST)


Categories [16 December 2012]

Long-term I'm thinking about enhancing Category pages to include the ability to filter the pages listed in the category by place. Currently, when you select Sources from the search menu and do a search for sources, subjects and availabilities are listed on the left-hand side of the results list. Clicking on one of these subjects/availabilities filters the search results to include only those results having that subject/availability. So when you're looking at a Category page, say World War I Veterans, on the left-hand side of the page you'd see a list of countries listed in the form fields for the Person, Family, Source pages listed in the category. Clicking on a country would filter the list of pages in the category to show only those pages in that country, and you'd now see a list of states/provinces. Clicking on a particular state/province would filter the list of pages in the category to show only those in that state/province. If you've used search at FamilySearch before, this idea of filtering by countries and states is similar to what they do on their search results page.

I'm not sure if this would affect how we're handling categories or even if it's a good idea. I thought I would bring it up here.--Dallan 08:06, 16 December 2012 (EST)


Measuring success [19 December 2012]

Inspired by a discussion on my talk page, I've created an article to discuss the metrics we could use to measure the success of the site: User:AndrewRT/Metrics. Would love to hear your thoughts. AndrewRT 17:23, 16 December 2012 (EST)

Jrm left the following comment on the page:

"We should probably get some notion of success as it might be defined by our gracious hosts at Allen County. Is it enough to have an active wiki forum for genealogy - to go with their existing genealogy offerings? Or do they need to see some level of use/influence/?"

What's the best way to address this question to Allen County? AndrewRT 18:28, 19 December 2012 (EST)


Noble House Affiliations as a Surname? [18 December 2012]

I've worked quite a lot with royal and noble names that don't follow ordinary given, surname conventions. I'm trying out a couple of initial conventions for creating those names (the names on the person page that is - not the name OF the page).

  • If there isn't a recognizable modern surname, then leave that portion empty for all of the names and alternate name forms, except...
  • Enter a standing alone alternate name line filling in only the surname field, with the name of the noble house affiliation entered as the surname

Examples:

This works fine for associating people with the ordinary surname category, but it also creates less useful associations to the surname in modern nation locations.

An alternate approach would be to associate the name of the house using an explicit category designation in the narrative body. For example:

While the explicit designation doesn't create the added location-specific categories, it does have the disadvantage of requiring use of explicit wiki syntax. I would also presume that the use of wiki syntax in the narrative body would not yield information in a useful form across GEDCOM export/load cycles.

One additional question. Have we sorted out the relative roles of the surname category page and the surname page proper? When there's a WP page for a noble house - which should include it?

Opinions? --jrm03063 20:20, 16 December 2012 (EST)

My own preference with the royals in my tree is like this : King of England Edward I Plantagenet, but that is probably a little messy. This is something that perhaps should be brought to a vote; Ive hesitated to work on any royals on WR because there is such a mix with no clear standard right now, including titles written in foreign languages. user:DMaxwell
The problem you're looking to solve is lack of consistency? I prefer the categories (shocking, since I set them up!) I don't think the location-specific categories are helpful because too many royals were born in weird places, I think wiki solutions are ideal because they take advantage of all the great options we have on the wiki that we don't in our software (I don't think we should design for downloading if it will limit us), and I don't really like the standalone name because it's really just a workaround that's going to look weird (and it wouldn't make any more sense in a download than wiki syntax).--Amelia 11:30, 18 December 2012 (EST)
I'm torn on explicit use of the noble house category versus the surname. I think there is a slightly better chance of the noble affiliation being recognized and preserved in a GEDCOM export - if it was left in a surname field - instead of being a piece of wiki text somewhere in the narrative. Then again, we could make the GEDCOM export/import smart enough to recognize that type of association - and create it as a surname field on export - and turn it back into a noble house on import.
Are we at least in agreement that we're going to avoid using the surname field for things that really aren't surnames? That much doesn't seem too controversial. --jrm03063 11:56, 18 December 2012 (EST)