On 25 Mar 2025, Help: Style guide and Help:Style guide (biography) were redirected to the refreshed Help:Conventions page. The talk pages for those previous Help pages were combined on this talk page.

Topics from the previous Help talk:Style guide

Other date modifiers [22 March 2011]

Should we add cal, calc, estimated, and est be added to the list of "approved" date modifiers? Currently these can be entered, but since the system doesn't understand what they mean, they're ignored in date calculations made by the system. So what I'm really asking is does the system need to treat these as synonyms for "about" in date calculations. Similarly, should between, bet, and btw be added to the list of approved date modifiers?--Dallan 17:59, 21 March 2011 (EDT)

Help:Date Conventions tried to establish different meanings for cal, est and abt but in practice this is just not done. If people explain how they arrive at estimates, it is not needed, so I think the point to emphasize is to explain where estimates came from.

In adding my suggestions to the date section I thought it best to guide people towards one preferred form, so that there is less variability on pages, even if the software supports much more flexibility than is recommended. I imagine some flexibility is needed to deal with vagaries of non-standard GEDCOM data, but I don't think rarer forms need to be advertised. --Jrich 10:42, 22 March 2011 (EDT)

Date conventions page [29 March 2011]

I came across a Help:Date Conventions page, which should probably be merged into this page. Would anyone be up to doing this?--Dallan 18:06, 21 March 2011 (EDT)

Dallan: I may be too new at this to make a suggestion (but will anyway). The Help page you referenced seems more comprehensive than the section in the Style Guide and they should certainly be reconciled and merged. But would it be best to have one central Style Guide, or separate sections for Name, Date, etc.?--Kirsten 19:14, 23 March 2011 (EDT)

I think my personal preference would be to have one central style guide with the most-important points, which references help pages as needed for additional detail. From a quick read of this style guide and the date conventions page, it looks like most/all of the important points from the date conventions page have been summarized in the style guide, so I think that's great.--Dallan 19:42, 29 March 2011 (EDT)

Jr. / Sr. / Roman Numerals [24 March 2011]

This is a tricky topic. Is this excluding the colonial use of these terms, which were applied transiently, as older namesakes died? In the case of Roman numerals, does this require entering all the way back to a different name to ensure the whole sequence is studied, and the counting is not based on some arbitrary boundary? In modern times, it almost seems like these are part of the name, i.e., Orel Hershiser IV. But it used to be that people would drop the Junior when their father died, etc. I just worry about people using these based on the scope of their research, as opposed to the big picture. In any event, WeRelate users have to be prepared to deal with unrelated people having the same name. --Jrich 00:34, 22 March 2011 (EDT)

I agree, and it's a problem that extends beyond colonial research. I've had instances in mid-19th century Ohio research where a man was a "Jr." growing up, but a "Sr." in his elder years. In addition, just because a father and son have the same name does not mean that they were known as John, Sr. and John, Jr. -- one might have had a nickname or gone by his middle name, even in the records. I am very hesitant to instruct people to include suffixes that might not even have been used. Wouldn't it be better just to instruct people to include any suffixes, such as Jr., Sr., and roman numerals in the suffix field and not in the surname field? That way we can accomodate any suffixes that change over time, as they can be entered as an Alt name. -- Amy (Ajcrow) 07:40, 22 March 2011 (EDT)

Good points. There's a "social standard" from Emily Post or Miss Manners where, when the eldest dies, everyone is supposed to move up a notch. Then there's the separate matter of describing what genealogical records say. Like others, I have men who were not father and son but have the same name and are shown in records as "Jr." or "Sr." Probably the easiest way to handle this would be simply to change the instructions to say that such designations, if used, should go in the Title Suffix field rather than in the name field.--Kirsten 12:54, 23 March 2011 (EDT)

I'm confused by the above comments because the page was referring to the "Title Prefix and Suffix fields" already and not advocating putting these in the Surname field directly. My posting above was trying to suggest that these particular designations should be discouraged, or at least, not encouraged, and maybe some guidelines given to try and prevent their use solely to presents one person's narrow research focus which could differ from other researchers viewpoint. For example, the emigrant William Reed of Weymouth might be named Senior by an American researcher, since he had a son William, but by some accounts, he is several deep in a string of William Reeds that stretch back to England, so other researchers might want to call him William Reed III, or something else. (This person is subject to lots of controversy, so these points may not be true, I just remember reading various accounts for him that had differing numbering systems, so hoped it illustrates the point.) At least with titles like Capt, Deacon, etc., there tends to be a much more consistent usage of which ever one ends up on the gravestone, so it is subject to somewhat less subjective choice on the part of the researcher. --Jrich 13:31, 23 March 2011 (EDT)

How would you suggest this be stated? Recommend that designations such as Jr., Sr., etc. be omitted because the names of the spouse and parents would differentiate between the individuals? That could work.--Kirsten 19:08, 23 March 2011 (EDT)

You captured the essence of it. Something like: Use of Jr., Sr., or Roman numeral in the Title Suffix field is possible, but is discouraged as transient, limited in scope, and possibly misleading. In almost every case, there should be other information (spouse, birthdate, etc.) that can be provided that gives a more universal and reliable identification of an individual across the whole community of WeRelate users. --Jrich 11:27, 24 March 2011 (EDT)

When a name is unknown [30 March 2011]

Elsewhere on WR help pages, we instruct users to enter the word Unknown when part of a name is not known. The system also adds that into the title automatically. Also, for international users, the use of NN is quite common to denote unknown. --Jennifer (JBS66) 07:50, 22 March 2011 (EDT)

Sure, but we've been rolling with a local convention of the full word "Unknown" for a while. It seems reasonable as the locally preferred convention. I do think we should say that we use "Unknown" to fill in for a missing surname and - when missing both the given and surname - we only fill in the given name with "Unknown". We don't really need "Unknown Unknown (86)" - though there are such pages... --Jrm03063 10:26, 24 March 2011 (EDT)

I agree. There are a bunch of "Unknown Unknown" pages out there :-( but the current version of the software now tries to use just a single Unknown for the title when both parts are unknown. I've seen FNU and LNU, but I wasn't aware of the NN convention. I'll add NN to the list of "unknown" synonyms.--Dallan 19:42, 29 March 2011 (EDT)

There are also other variations on this with different punctuation such as N.N. - N.N - N. N. etc --Jennifer (JBS66) 06:40, 30 March 2011 (EDT)

3-letter abbreviation for month [28 March 2011]

Must the abbreviation for the month be in English? We have users whose native language is not English who enter the abbreviation for the month in their language. --Jennifer (JBS66) 10:16, 22 March 2011 (EDT)

I added that because it seems to be what GEDCOM requires for a Gregorian date. GEDCOM also supports French months but only for the revolutionary calendar (Thermidor, etc.) and the 13 Hebrew months which I am totally unfamiliar with. Perhaps WeRelate has some Internationalization features that could help? --Jrich 10:34, 22 March 2011 (EDT)

I don't think this is an actual problem. Not to sound xenophobic, but the user base of WeRelate is overwhelmingly English-speaking. And the chance that a genealogical user whose native language is not English will not be familiar with U.S/British conventions in abbreviations is very, very small -- and that includes Hebrew-speakers. We should just go with the 3-letter English abbreviations and not worry about it.

My own beef is with the pages that were imported with equivocal number-only dates, like "5/10/25". Is that day-first or month-first? Arrrgh. --Mike^Talk 08:29, 28 March 2011 (EDT)

One of these days, we're going to start doing a better job looking for inconsistencies across the data base, and the foundation for a lot of that is going to be unambiguous date representations. Also, dates are a key part of the "look" of WeRelate, so there's a good argument to not prefer too many equivalent forms. But as always - preference isn't the same as absolute legality. I see no problem with someone uploading a GEDCOM using a dialect of the accepted GEDCOM forms, using those while they're doing the initial bashing of their content into shape and getting it tied in to WeRelate - So long as they don't mind that things will evolve toward a more narrowly defined representation. I can easily imagine an agent that would go through and do a lot of that sort of normalization automatically. --Jrm03063 10:26, 28 March 2011 (EDT)

Add explanation at top of page? [24 March 2011]

Can we add an explanation at the top that this style guide is intended for when someone creates a new page via the WR interface or edits page, not for data coming into WR via a GEDCOM import? I'd hate for someone to think that because they've entered their surnames in all caps or spelled out their months in full that they're not supposed to import that data. -- Amy (Ajcrow) 10:49, 22 March 2011 (EDT)

Well, is this really a set of rules, or is it a set of conventions? I think this is really a set of conventions - which means that this is the preferred way to do things if there isn't a compelling reason (perhaps on a temporary basis) to do something different. Perhaps we should title documents of this sort as "Style Conventions" rather than leaving an implication that departure from this is a violation instead of a less generally preferred form?--Jrm03063 10:31, 24 March 2011 (EDT)

Name Conventions [24 March 2011]

I have two comments on the naming suggestions:

• What is the benefit of requiring a period after an initial? I have never encountered a middle - or other name - that was solely an initial. So a capitalized letter standing alone is already understood to be an initial - why require a ".".

• "When two children in a family have the same given name, enter (1), (2), etc. in the Title Suffix field to clarify the birth sequence if you do not otherwise know a birth or christening date.". This just doesn't seem helpful. If you know enough to know that there are two children in a family with the same given name, you really MUST know something about when they were born - at least by estimation.--Jrm03063 10:22, 24 March 2011 (EDT)

"Harry Truman's middle name is S. Since the 'S' is not a middle initial, a period is not required." This is quoted from a website on English usage in Business, but three or four were returned by simply searching for "not a middle initial". I heard a story once about a person who had no middle name, but some official stuck in an X, apparently finding that the computer demanded he entered something. The X stood for nothing, more a symbolic way to say no middle initial? --Jrich 12:37, 24 March 2011 (EDT)

Style versus data entry [25 April 2011]

I am not sure Style Guide is the best title for this page. The content is mostly rules about data entry. I believe there is also a need for a Guide describing the preferred style for presenting various types of information. Maybe it gets added to this, maybe it's separate.

Obviously there are many approaches to presenting information, and one is not necessarily better or mutually exclusive with others. But I believe there is some value to a reader finding things presented similarly on most pages. And that there is some value to presenting examples that illustrate preferred ways of doing things. So, some potential discussion areas:

1. Purpose of the facts and other fields. Is the intent to create a timeline of events or just a short summary of the major ones?

• So every thing can be listed as a fact (see for example the "Other" facts on Person:Jeremiah Vail (9), or minor events can be embedded in the narrative or source citations (e.g., Person:William Clark (191)).
• Standard facts get repeated in the narrative to create a pretty biography, or should the narrative be written assuming the reader can see the summary on the same page, and avoid repeating facts with not additional information, or relisting children who are already listed in the infobox (see for example Person:Dorothy Bowne (3)).
• What is the appropriate way to deal with spelling variations, historical place names, etc. For example, the recent discussion on WeRelate talk:Support about German Surnames.

2. Purpose of page. What type of information should go on each page?

• Should sources proving the connection between child and parent go on child's page or parent's family page? Should sources giving date of marriage go on person's page or family page of marriage or both?
• When should a discussion of alternatives or theories go in the narrative and when on the talk page?
• How should "Disputed Lineages" and erroneous sources be presented to prevent them from being re-entered?
• Would it be useful to have a suggested list of section headers for the narrative, so there are standard places to find certain information if it is present, i.e., "Probate", "Immigration", "Military Service", etc.?

3. Length of information. I have an 80 page biography of my great great grandfather which is probably much more than all but a dozen people in the whole world want to see. Surveys of all the land transactions that a person was involved in can be pretty boring.

• Guidelines for the tone of the narrative. Is the page a scrapbook, full of pictures and decoration, or a detailed biography, giving every time a person was mentioned as a neighbor or witness, or a encyclopedia entry of a person, as short as possible while communicating important facts? Are there guidelines of what material should go into the narrative, and when other information should be put into separate articles?
• What should go in the narrative and what should go into source citations? Should the narrative be a coherent, flowing biography with footnotes to source citations giving the text of primary documents, or does a collection of primary documents itself, or a series of transcripts of secondary sources, make a useful narrative?
• Guidelines for presenting documents. For example, including wills: use an abstract or excerpt not longer than ??? with link to full transcript on separate page if desired, or link to website where it can be found. Or no length limits? (e.g., Person:William Cutter (5)).
• The validity of data is not determined by the number of secondary sources that repeat it, so guidelines on when additional sources are useful, and when they become clutter.
• Focus. Wholesale transcripts that are actually about the parents or grandparents or the original immigrant of the family seem to devalue the individual by implying they are only important because of who they are related to. Similarly, tracts on historical events or the nature of the area settled in probably belong elsewhere?

There are probably many other style issues that can be added. I realize that it is not intended that things only be done one way, but there are probably many people that come to WeRelate and would be happy to do things in a given manner, presumably designed to create some commonality of style, versus some manner that results by accident from their experiments in trying to figure out how the system works. --Jrich 11:08, 13 April 2011 (EDT)

I like this suggestion and agree that some guidance on these issues for those inclined to follow it would be helpful. I don't know what to name the pages, but I think they should be separate. This page is largely objective rules that we are likely to actually enforce, whereas, at least until we get more developed, the issues above are more flexible. At the least creating the page would provide a place to discuss pros and cons of different approaches.

I'll also add how to deal with census information to the list - sources v. narrative, head of household v. family members, person v. family pages. --Amelia 12:22, 13 April 2011 (EDT)

I'm the one who named this page; I called it style guide because nothing else came to mind at the time. But certainly it could (and maybe should) be renamed. Feel free to rename it. As you say, it's more about rules for data entry than about "style".--Dallan 19:05, 14 April 2011 (EDT)

I started a page here based on Jrich's questions. The actual page has some rules where I think there seems to be an uncontroversial best practice or where at least a strawman might be helpful. The questions are on the talk page to discuss what's there, register your opinion in favor of one way or another, or propose a guideline. And please add any other topics that come to mind. --Amelia 23:28, 25 April 2011 (EDT)

Date format [17 September 2011]

The Style Guide said the date format should be dd Mmm yyyy (but Do not use leading zeroes). I thought dd implied using a leading zero (when you format a cell in Excel using dd mmm yyyy, dates are changed to 06 Jan 1900). So, I removed the first d from this text. Is this in line with gedcom standards? If it is, we may want to edit our Help:Date Conventions page as well. --Jennifer (JBS66) 13:03, 15 September 2011 (EDT)

I have been using leading zeros on the year if there are fewer than four digits present. --jrm03063 13:23, 15 September 2011 (EDT)

The only thing I'm aware of regarding gedcom standards is just day-month-year format. So I think we're covered. I personally could go either way on leading zeros for year, but I'm inclined to agree with Jrm that in the very rare cases where you have a 3-digit year, it's best to add a leading zero so that others know you really mean to have a 3-digit year. I don't think we need to make a big deal about that though, since we're discouraging most people from adding those pages in the first place.--Dallan 22:11, 15 September 2011 (EDT)

I hadn't thought of years with leading zeros when I posed my question. I was updating another page, and realized that DD implies using a leading zero (like 06 Jan). Since I thought that we were discouraging that practice, I put d Mmm yyyy, but wanted confirmation so I could make the help pages consistent. --Jennifer (JBS66) 07:01, 16 September 2011 (EDT)

I think the change you made is good. I'd keep yyyy as it is.--Dallan 12:33, 16 September 2011 (EDT)

Not strictly pertinent to this page, but pertinent to this discussion perhaps, since it would make some of it moot. If upon saving, understandable dates got saved into the selected format (presumably, no leading zero on the day, 4 digits in the year, sentence case on the 3 letter month, preferred form of the qualifiers, etc.), then there would be less trivial edits (i.e., containing no genealogical contribution) just to make the date conform, not to mention the educational value that would happen when new users see all dates forced into this format. Understandable dates would be any form the system could convert automatically to the approved format. A date input with leading zeros, e.g., 06 Jan 1834, would be understandable, but would get saved in the preferred format, e.g., 6 Jan 1834. Further I would argue there would be value in turning non-understandable dates red as we do with broken links, etc., so that people would be given feedback that while the system is storing it as a string in the date field, it can't be understood or processed as a date. --Jrich 13:31, 16 September 2011 (EDT)

I like that idea. What do others think? Would we want to to standardize date qualifiers like "About" into "Abt" (or vice-versa) as well? Red-link if a date field contained a valid date but also contained an unknown date qualifier?--Dallan 18:07, 16 September 2011 (EDT)

I'd be tempted to skip standardizing the qualifiers only because there are so many permutations of them. Circa can be expressed as: Circa, circa, C, c, C., c., Ca, ca, Ca., ca., ~ (and probably a few more I haven't thought of). Also, any could be expressed with or without a space between the qualifier and the date. I don't think it's worth the time and effort to try to capture all of the variations just to standardize it. -- Amy (Ajcrow) 07:38, 17 September 2011 (EDT)

Technically, there are not so many legal permutations, there are only lots of personal styles that technically violate the GEDCOM standard which was the basis for the date guidelines. As I read that standard, it lists ABT EST And CAL (case doesn't matter). If, in the interests of outputting compliant GEDCOM, Dallan were to translate all those listed variations into ABT or EST or CAL on output, why not do it on input? Even if the WeRelate community decided they like ca better than abt (is that California?, Canada? oh yeah, it's circa), it would be better to use it consistently, instead of being a slave to every whim and personal preference out there. The second reason is to avoid the issue, which I see every time certain users spend time on WeRelate, of getting notified of changes to pages when the only change made was to change ABT to CA, or change a capitalized month to sentence case, or some other trivial changes unaccompanied by any genealogical contribution. Doesn't ABT communicate the same thing as CA? What makes ABT wrong and CA correct? Certainly not the date guidelines. This is not like writing the narrative where a diverse styles can be useful in communicating different aspects of an individual's life. It adds nothing useful, and only detracts from effective communication of dates, to have widely varying date formats. --Jrich 09:43, 17 September 2011 (EDT)

Dates matter - a lot. We want to export good GEDCOM data, and our date strings go into the GEDCOM file untouched. Standardizing is also important because - I think - we really want to take advantage of well formed dates in order eventually permit better integrity checking (see this document).

Putting in code to discipline dates at save time is a nice thing, but there are already several million pages out there. Maybe we should do that, but maybe we also need to have an agent that recognizes a superset of the GEDCOM date forms and is able to automatically turn them into the standard forms. For example:

• c. 1895 -> abt 1895
• about 1895 -> abt 1895
• ~1895 -> abt 1895
• Between 1775 AND 1780 -> bet 1775 and 1780
• JANUARY 1775 - 1780 -> bet Jan 1775 and 1780

I would also suggest that we narrow the standard and always put the keywords in lowercase and the three letter month abbreviation in mixed case. Lower case uses less screen real estate and mixed case (for month names) helps to visually distinguish them from keywords.--jrm03063 11:34, 17 September 2011 (EDT)

Use of the "Personal Information" Section [27 August 2021]

We should really add the fact that the Personal Information Section does not accept carriage returns and that <br>s are really necessary in lists (such as a census for a household) that may be put there.

Other quicky gripes:

• Including e-mail addresses of informers. Not only is it proof that someone provided the information for the user, but the user may be impinging on that person's privacy.
• Explain what the description box should contain, like street addresses and farm names, occupations reported on censuses. In other words, items that need not be in the databases that the central box can link to.
• Citing a source twice because it is referenced to twice.
• Listing citations from Ancestry as "notes". These urls all get directed to Ancestry's "welcome page".--Goldenoldie 11:02, 27 August 2021 (UTC)

Topics from the previous Help talk:Style guide (biography)

Discussion Questions

(Adapted from Help_talk:Style Guide)

Purpose of the facts and other fields. [18 April 2011]

• Is the intent to create a timeline of events or just a short summary of the major ones?
• So every thing can be listed as a fact (see for example the "Other" facts on Person:Jeremiah Vail (9), or minor events can be embedded in the narrative or source citations (e.g., Person:William Clark (191)).
• Standard facts get repeated in the narrative to create a pretty biography, or should the narrative be written assuming the reader can see the summary on the same page, and avoid repeating facts with not additional information, or relisting children who are already listed in the infobox (see for example Person:Dorothy Bowne (3)).

The most effective writing is written with the audience in mind. While quite diverse, the WeRelate audience is obviously interested in genealogy. The most likely reader of any page is someone who is trying to figure out if this page describes a person they are interested in, followed, in descreasing numbers, by someone who actually is interested in that person, and least of all, someone who is a direct descendant. For this reason, the ideal presentation will keep major genealogical data at the top of the page where it may be seen on the initial screen, with detailed, in-depth down below. This is very similar to the format used in most genealogical magazines where a summary of the person is given followed by more detailed discussion of the details.

Facts are provided to support the format of GEDCOMs and it is the style of some uploaded data to try and store all events as a fact, possibly overusing the "Other" fact type. This has the advantage of giving a fleshed out timeline of the person's life, but probably makes the page harder to use for the most numerous group of readers, those trying to quickly determine if this is a person they are interested in. Thus, it is encouraged, when editing pages, to use the facts to present the major genealogical events, and to embed other facts into the narrative or source citations, which any interested reader will still read.

Since all WeRelate Person pages contain infoboxes detailing marriages and children, and facts for birth (and/or christening) and death (and/or burial), all given in standard locations on the page using a standard format, it may be assumed that WeRelate users can digest the information in this form. Wholesale repetition of this data in the narrative should be avoided to minimize work if the data ever needs to be changed. Unless the narrative is adding details to the summary data, beyond what has already been given, there is no need to simply rehash data already displayed on the page.

If you disagree please comment.

Historical place names [18 April 2011]

Two questions, interdependent:

1. What page to link to. Place pages are based on 1900 names. Sometimes there is no conflict. But sometimes an event was in one town at the time it occurred, and was in 1900 in a different town/county/country. If the name merely changed, then the 1900 name should be linked to. But if someone was born and died in X town, and by 1900 the portion of the town in which they lived was called North X, which name to use? And how to tell? Does it matter if the vital records are all found in X?
2. What name to display. If the linked to page is not called the same thing as the place was when the event occurred, what to do?

• Leave the naked place page link, that is, use the place name as it was in 1900. This means people born in what is now West Virginia in 1840 (but was then Virginia) are listed as born in West Virginia, American colonists were born in the United States, and all European boundary changes are frozen in time. Use the source citations, or narrative, to detail the relationship between the historical name of the location and the name of the place page if you think it might be confusing to a reader. In many ways, this is probably the easiest approach.
• Use a pipe and enter the name of the place as it existed at the time after the pipe. As a purist rule, this means paying attention to just where, relative to the current town boundaries events occurred (probably assuming events occurred at home), and determining which county had jurisdiction at the time. This is hard and perhaps impossible to get absolutely correct.

• Variations on this one would put (then) in the place name after the pipe or use the naked link in the place field with the "historical" text in the description field. For example, the place may contain "Beverly, Essex, Massachusetts, United States|Beverly (Then Salem), Massachusetts Bay Colony", in other words, the location is in what is now known as Beverly but was then considered Salem. Or the Place may contain the standard place name "Lancaster, Worcester, Massachusetts, United States" and the description field can add "Then part of Middlesex County", or "Then known as Nashawena", depending on what time frame you are working with.
• It's also possible to mix these rules somewhat. For example, large-scale known changes like Virginia -> West Virginia or colonies -> United States that have fairly easily ascertainable times/boundaries could have stated forms, while more difficult or complicated determinations could either be left to user preference or ignored. This has the advantage of removing some obvious anachronisms and the disadvantage of being inconsistent.

Complications:

• Like all data, assertions about historical locations names need to be proved. If a birth is recorded in the records of Salem, how is it known that it occurred in what is now Beverly (the example above)? Such proof, whether done by you, or mentioned in a secondary source, usually requires tracking the homestead property through deeds down to a time period when Beverly existed, to show that it lies in that area.
• Be careful if the historical name is the same as a modern name. Inadequate explanation will leave the reader thoroughly confused, as it will not be clear that the intent is to give a historical name.
• Some changes are more important to current day than others, and neither absolutist rule captures them.

• Which jurisdiction has the records? Under the rule always labeling places as they were in 1900, the place name may not reflect where records are held if the 1900 place was created after the event, and may be misleading if both the old and new place still exist (Salem/Beverly, for example). Under the rule using the historical place name, places that have disappeared or moved obscure where the records are held (old Indian names, for example)
• Did they move? If a place name changed during someone's life, the historical rule will make it appear as if they moved, even if they didn't. It also requires removing some information, like counties in Massachusetts, that can tell readers useful information about where the event occurred in the state and whether events in different towns were close together. Conversely, the 1900 place names rule may obscure relevant political changes (like European boundary changes).
• Countries vs. counties vs. annexations - the bigger the change, the more it probably mattered at the time and the more likely people will notice now. Whether or not we label Texas as "United States" in the mid-1800s is likely to prompt many questions and different edits. Whether John Smith's homestead was within the Springfield city limits, not so much. If we can't get John Smith right, which we can't known in the vast majority of cases, does that mean we shouldn't try for historical accuracy on larger divisions?

(Alternative name spellings are addressed on Help:Style guide.)

Purpose of page/suggested layout [17 April 2011]

What type of information should go on each page?

Parent/child sources [18 April 2011]

• Should sources proving the connection between child and parent go on child's page or parent's family page? Should sources giving date of marriage go on person's page or family page of marriage or both?

Most relations involve connecting two pages and it can be difficult to know which page is the most appropriate place to put sources or discussions justifying that relationship. It may be necessary to place such information on both pages. For example, a probate document may indicate both that a widow remarried to a second husband, and provide a date that she remarried by. In that case, the document will want to be cited on the Family page of the second marriage to justify the estimated date, and on the widow's Person page, to justify that she was the one who participated in both of the marriages. The following very general guidelines are offered:

In general, proof and discussions of birth date and parentage should go on the child's Person page since such proofs are usually specific to the one child, and separate discussions may be needed for the other siblings in the same family. Particularly for estimate birth dates, the discussion is probably based on events in that Person's life, such as a deposition, time of marriage, or age at death, which have no place on the Family page of the parents. Analysis of these items can always reference information of discussion on the Family page if impacted by those discussions.

In general, discussions and analysis of birth order should go on the Family page, since it affects multiple children, and often a change will impact more than one child. It may be necessary to reference birth dates on the individual Person pages.

In general, proof that a specific marriage took place, its date and location should go on the Family page. If there are multiple candidates for one of the spouses, the Family page may be the best single place for a comparison of the various candidates until such time as the controversy is resolved. However, in general, detailed identification of the spouses involved in the marriage should go on the Person page of the spouse since it involves connecting this marriage to the other events in their lives. Further if this identification is wrong, the proof of the marriage taking place should still be pertinent and correct, and it is simply a matter of connecting the correct spouse in place of the incorrect one.

In general, proof connecting an individual of known parentage to a marriage (e.g., father naming his married daughter in a will), or showing that the same individual participated in multiple marriages (e.g., secondary source listing a person's 3 wives), would go on that individuals' Person page. These connections involve events and people that have no place on the Family page of any single marriage.

The inter-dependency of proof create some difficulties that no single organization is likely to resolve. For example, proof of a woman's death date goes on her Person page, but is almost always dependent on having correct proof of her marriage, which is on a different page, since the record of her death will use her married name. Likewise, the proof of a widow's second marriage goes on the Family page for that second marriage, but will use the surname from her first marriage which is proved on a different Family page, and will not match the maiden name displayed for her by WeRelate. But if a similar organization is used by all pages, readers will quickly know where to go to find the needed pieces of proof.

If you disagree please comment.

Alternative theory discussion

• When should a discussion of alternatives or theories go in the narrative and when on the talk page?
• How should "Disputed Lineages" and erroneous sources be presented to prevent them from being re-entered?

If you disagree with rules on the Help page, please comment.

Suggestion sections

• Would it be useful to have a suggested list of section headers for the narrative, so there are standard places to find certain information if it is present, i.e., "Probate", "Immigration", "Military Service", etc.?

Focus. [18 April 2011]

Wholesale transcripts that are actually about the parents or grandparents or the original immigrant of the family seem to devalue the individual by implying they are only important because of who they are related to. Similarly, tracts on historical events or the nature of the area settled in probably belong elsewhere?

Not all readers of a Person's page have the same interest as we do. To some, it is a child, to some a parent, to some a spouse, and to others a historical personage. But we must presume the reader is interested in this person, or they would stop reading as soon as it is determined they are not. Therefore material on a person's page should describe that person. We should also not assume that the person followed the same path we did, and so do not rely on the reader having seen information located on the parent's page, or the spouse's page, etc. Any need to reference information on other pages should be handled by giving explicit references and links to those pages, and otherwise, the page should make sense on its own.

In particular, the following practices are discouraged:

• Do not give detailed listings of several generations of this person's genealogy in the narrative. If the reader is interested, they will follow the links to the pages of the ancestors or descendants, and should find information on previous or subsequent generations there. A brief summary of ancestors and descendants may be given but it need not contain more than names, links to pages, and possibly relationships. For example, on the page of Eunice Treat, "Eunice Treat was daughter of Rev. Samuel Treat, granddaughter of Rev. Samuel Williard and Gov. Robert Treat, husband of Rev. Thomas Paine, and mother of Declaration signer Robert Treat Paine " might be acceptable, but a list of all the children born to her father Rev. Samuel Treat, or to one of her grandfathers, would not.
• Do not give extensive background information that is primarily historical and geographical, unless it is directly material to events in the person's biography. Most such material, like descriptions of battles, analysis of religious movements, founding of towns, is best handled by a reference to wikipedia, or other external sources, to allow the reader to pursue this information only if they desire.
• History and origins of surnames belongs on the Surname pages, not on the page of one individual having that name.
• Do not assume that a source citation on another page is adequate to justify a fact on the current page. A separate source citation should be on every page that draws on that source.

If you disagree please comment.

Style

(as in how is it written)

Length of information. [6 May 2011]

I have an 80 page biography of my great great grandfather which is probably much more than all but a dozen people in the whole world want to see. Surveys of all the land transactions that a person was involved in can be pretty boring.

Wikipedia defines genealogy as "the study of families and the tracing of their lineages and history". It further comments that "Some scholars differentiate between genealogy and family history, limiting genealogy to an account of kinship...". The name of this website is WeRelate, indicating that the primary focus is on relationships that interconnect everybody.

Biography is a useful tool for confirming genealogy. Thus, knowing that a person moved from one town to another is very useful in understanding why widely separated birth and death events are both attributed to the same person. A person's occupation is often useful in distinguishing like named persons living in the same town when reading colonial deeds.

But biography is not the primary purpose of WeRelate, and not all readers are descendants. Therefore, what biography that is placed on a page should attempt to remain of interest to a general audience, or be directly pertinent to the specific genealogy of a person. To go into further detail than just providing biographical highlights, a separate article would be more appropriate.

When a narrative exceeds more than two or three paragraphs, descriptive headings should be inserted to divide the narrative into sections. This allows readers to quickly spot and select the section that is most interesting to them. Further, it aids in editing by keeping edited text small, and reducing the chances of edit conflicts.

Tone

Guidelines for the tone of the narrative. Is the page a scrapbook, full of pictures and decoration, or a detailed biography, giving every time a person was mentioned as a neighbor or witness, or a encyclopedia entry of a person, as short as possible while communicating important facts? Are there guidelines of what material should go into the narrative, and when other information should be put into separate articles?

Source extracts [18 April 2011]

• What should go in the narrative and what should go into source citations? Should the narrative be a coherent, flowing biography with footnotes to source citations giving the text of primary documents, or does a collection of primary documents itself, or a series of transcripts of secondary sources, make a useful narrative?

• Guidelines for presenting documents. For example, including wills: use an abstract or excerpt not longer than ??? with link to full transcript on separate page if desired, or link to website where it can be found. Or no length limits? (e.g., Person:William Cutter (5)).

It is encouraged that excerpts or abstracts (consistent with copyright limitations) be given for all source citations when possible. WeRelate pages are not static, and while it may be clear today that the source citation supports the birth date listed elsewhere on the page, if that birth date ever gets changed, a stale source citation will appear to justify the new date when it actually disagrees. This is avoided if an excerpt or abstract makes it clear what the source actually does support.

In history as currently practiced, and also in genealogy, it is often desirable to quote from primary documents. But without care, this may make the page less useful to the reader, since it may be necessary to provide long passages of the original document to establish context, separate excerpts may appear disjointed or contradictory, and the reader may not have the foundation or interest to find long excerpts useful without supplementary explanation. The contributor is encouraged to keep such excerpts short (not more than four or five sentences), or possibly a brief abstract with one or two quoted passages to capture the flavor of the original document. If the whole document would be of value to some researchers, this may be done by creating a separate transcript and providing a link to that page (Proposal for Transcript Management?).

For example, a source citation might detail where a copy of a will was found, and the associated text in the source citation could present an abstract naming the persons mentioned in the will, the date written (when the named relations were true), the date proved (often helps to find the will). If it is desired to provide a verbatim copy of the will, that would go in a separate transcript. If there is some discussion about the will in the narrative, the abstract may be embedded in the narrative instead, and a footnote added, pointing back to the citation of the source where the will was found. Short quotes and excerpts can be added to the narrative to make it flow without excessive page jumping, but unless the will is very short, at most a few hundred words, the full transcript should be a separate page in the Transcript namespace.

If you disagree please comment.

Sources

Repeating secondary sources [6 May 2011]

• The validity of data is not determined by the number of secondary sources that repeat it, so guidelines on when additional sources are useful, and when they become clutter.

Are some sources so important they should always be included? Wikipedia? Great Migration? Savage? Find a Grave? How are they defined, and where is the line drawn? Conversely, some sources are so suspect, they should always be deleted when there is an alternative - Ancestry World Tree, WorldConnect, unsourced webpages generally.

Since WeRelate does not allow recording of living people, we cannot have first hand knowledge of most of the facts being entered into WeRelate. Therefore we rely on sources to know everything, and certainly to convince others that we don't known personally.

The most reliable sources are those created by people who had first hand knowledge of an event, and even better, recorded it at or near the time of an event. Good genealogy therefore, strives to find and cite contemporary sources made by people with first-hand knowledge (primary sources). The course of genealogical research is often a progression from unsupported assertions, to secondary sources describing primary documents, to the actual primary document itself. It is expected, and desired, that as a WeRelate page matures through exposure to more and more researchers, the quality of sources cited on a page will follow a similar progression in quality, with the goal being to identify the primary documents from which facts about a person are inferred.

Unfortunately in the age of the Internet, it is too easy to copy information, without taking the extra time and effort to copy sources. With each copying, it becomes more and more likely that errors are introduced, or facts are misapplied because the original context has been lost, or misinterpreted. In short order, these facts are more likely to be wrong than right. Therefore, Internet sources that do not provide sources should not be relied on, nor cited on WeRelate. Family trees on the Internet, Ancestral files, many Ancestry trees, etc. tend to all fall into this category. In addition, non-institutional Internet sources tend to suffer from impermanence, and so even good ones may not make for good source citations three or four years from now.

Source citations are given to inform readers of where useful facts or information are found. Every attempt should be made to make source citations clear, accurate, and useful.

Clear citations would provide enough information for a typical researcher to unambiguously identify the source and locate the information. Ideally source citations would link to a Source page which will usually contain enough information about a source that it won't be mistaken for a different one. The use of MySource citations, or less formal forms of source citations, need to be careful not to use abbreviated citations that could be mistaken for another source, e. g., "Reed Genealogy". Correct volume and pages numbers, or other pertinent locating information, should be provided for the cited information, not just as a courtesy, but to be sure the intended reference is found.

Abstracts, as suggested previously, will go a long way to making citations both accurate and useful. Accurate in that it will be clearer which facts the source supports and which it does not. Useful in that it will allow the reader to make a preliminary judgment about the worth of the source. If a reader is not familiar with a cited source, its citation may prompt a difficult, potentially expensive, search to track it down and find out if that is the longed-for source which will break their genealogical brick wall. This can be very frustrating when the source is found to only contain the barest mention of the studied person.

Consideration of the value to the reader should always be kept in mind when citing a source. Citing non-essential sources that add nothing new to previous citations, or exhaustive lists of every source where a person is mentioned, serve to merely clutter up a page. With abstracts, at least such redundant citations will be obvious for what they are. It is always desirable, however, to add source citations when they provide additional genealogical information, or useful interpretation, or when they are of a more reliable quality (i.e., adding a citation of a primary source even if a secondary source is already cited.)

Census

• Where do census records go (parent/child/family page)?

If census records are input as events with sources on the family page, they will appear on each spouse's page as well (reducing data entry requirements), but without a source. This would be in contrast to any records for that person as a child, single adult, or widow[er]. Also, if a census record contains a head of household, his second spouse, and children from the first marriage, it contains information relevant to the family pages for both the first and second marriages, but if placed on both pages will be duplicated on the head of household's person page.