WeRelate talk:Watercooler/Archive 2013

Watchers

Topics


Handling of parentage contenders? [5 January 2013]

In talking over the evidence for parentage of immigrant Richard Kimball, the discussion seemed to be heading towards consensus that neither the currently linked parents nor those suggested in The Great Migration were adequately supported.

This raises the general question of how this situation should be presented on WeRelate. What do people here think? Should no parents be linked for the person, or should both sets of parents should be linked as ("duplicate") parents? Presumably in either case the text of the Person: page should include some mention of the candidate parents and the issues. --Robert.shaw 04:24, 18 December 2012 (EST)

Since I was party to that discussion, I should make a comment. What I stated there was my preference; having duplicate parents will confuse readers. The man doesnt have 4 parents. But in Richard Kimball's case, there is insufficient proof for either set, so it would be wrong to link either sets as if they were equally true. My preference, as always, is to have a note on the person page discussing the problem, linking the sets of parents within said comment, but leaving them out on the actual 'parents' field. JRich and I came to similar compromise when I was still new here. Daniel Maxwell
The man doesn't have zero parents either. It would actually be clear to readers if two sets of parents were on the page that the page represents confusion about his parentage, and then when they read the notes it become clear why. There are people out there that are going to have one set, or the other set. So for searching purposes, having both sets will help either set of people looking for this page. Also, some GEDCOM may come that gives Richard Kimball one or the other set of parents, so that the one set will then be added as if they are the only candidates. Having both parents seems to be the best answer, because it would ensure that the uncertainty would continue to be represented through GEDCOM uploads, it would give good results for people searching for either case.
One distinction should be made clear. There is actually circumstantial evidence for both sets of parents (currently documented on the Talk page). They are not random guesses. Better to correctly indicate uncertainty than to indicate the wrong answer with certainty. --Jrich 10:04, 18 December 2012 (EST)
I dont mind having them both on the page. I only do not want them linked. Otherwise 'having' both in a discussion at the bottom doesnt bother me. What you have is evidence, not proof (there is a difference), and in that case I think it is wrong to pretend that it is proof. Daniel Maxwell
I would prefer that we avoid having multiple parents - since that's the sort of thing we want to be able to look for as a consistency item in mass sweeps of the database. I deal with situations like this with a narrative section called "disputed lineages" (search on that for examples). The content of the section would make note of the different potential parents and relevant facts. The section would be reproduced on the person page and the family pages for both sets of parents. If one set of parents is not only considered more probable than the other - but indeed likely - only then should it be hooked in fact. --jrm03063 11:33, 18 December 2012 (EST)

Is anyone aware of any system used by any other genealogy programme or website for potential relationships? I've never come across it, although it may be something that WeRelate could look to design that would give us an advantage over other websites. For now, I would agree that a narrative comment in the main text would be the best place for it, with no parents linked given that neither is proved. Although I acknowledge your point about future GEDCOM uploads - could this broader issue be addressed by somehow having a field that says that x should not be added as the parent of y? AndrewRT 18:23, 19 December 2012 (EST)

I don't think that we should ever represent that the results of a GEDCOM upload will ever be complete on any given page. The load should save on possible clerical work and errors, but a user should still expect to review every page they create (at least eventually). What I could imagine doing is providing fact types that allow us to make positive assertions about missing information. For examples:
  • Person not known to have ever married
  • Person married but spouse not known
  • Person married but children of marriage are not known
  • Person married but family not believed to have had children
  • Parents of person not presently known
We could make the GEDCOM upload smart enough to refuse to override these situations within the context of an upload. --jrm03063 18:38, 19 December 2012 (EST)
We could presumably come up with 5 new template along the lines of nomerge, that can only be removed by manual editing, and modify the GEDCOM upload to respect these. They don't exist now, and software changes seem to have a long lead time, so that's not much of an answer at the present. The other question is search, in case somebody searches for the Richard Kimball who is son of one or the other candidate parents, and nothing matches.
Nobody has duplicate parents in real life, but the state of our knowledge doesn't always quite know the actual situation. Clearly duplicate parents are listed because there are inadequate sources. But that is exactly the state of our collective knowledge in some cases, and when not, this is easily cleaned up by adding the definitive source and removing the wrong parents.
In a collaborative environment, it would seem there is value in being able to represent alternative theories. For example, by putting Richard Kimball into both families, you essentially involve the watchers of both Family pages in attempts to resolve it. Plus it makes it more likely that obvious contradictions with one answer, or the other, aren't overlooked.
Insisting on "proof" in order to enter data seems very problematic. First all, that would imply sources would be required, which they aren't. Second, it is clear that the varying standards for proof among researchers would make this a very ambiguous standard. Finally, there is many an accepted line based on significant amounts of assumption and circumstantial evidence, i.e., on less evidence than either of Richard Kimball's proposed parents. --Jrich 19:46, 19 December 2012 (EST)
Sources not being required? Is that not, in fact, the whole purpose of this website, rather just another gedcom dumping ground? The 'evidence' out there apparently hasnt lead to anyone else leaping to the conclusion of the other couple as the parents, so if it isnt up to any professional's standards why should it be up to 'ours'? Daniel Maxwell
Re Sources: I believe the official position is that sources are desired, not required. It seems to me that, at some point, some numbers were published, but if I recall correctly, it seems to me that the vast majority of pages didn't have sources. And no, the single most important point of this website would be collaboration. Now I might argue that collaboration requires sources so that things remain impersonal and objective, but there are clearly some who don't seem to think sources are needed.
Personally, I take all genealogist's statements as opinions, and want to see the evidence. Even good genealogists make mistakes and even bad ones get things right. Truth doesn't depend on who says it. In this case, there is no proof, and while there are sources on both sides, they all amount to guesses and opinions. So any kind of strict proof means no parents are listed. I just don't think that is the most useful presentation. --Jrich 21:02, 19 December 2012 (EST)
There is another way to deal with the uncertain spouses or parents when there is no preferred candidate --
1. Create an Unknown Family (for parents) and/or Person page.
2. Create Alt Names for each of the candidates. I believe Alt Names now show-up in search results?
3. Create Notes and/or Sources for each of the Alt Names with the relevant discussions/evidence.
And now for my question of what do you do when someone was adopted and there is no record of the birth parents?
--Jhamstra 22:57, 19 December 2012 (EST)
I never create an adopted child as the conventional child of the adopted parents. Instead, I will indicate the adoption as a fact on the family page, pointing at the person being adopted. Likewise, I'll create a fact on the person page indicating the adoption and pointing at the adoptive parents. --jrm03063 11:25, 20 December 2012 (EST)
"1. Create an Unknown Family (for parents) and/or Person page." - When I see this occasionally, I delete them. It seems like a waste of room, and by definition you cant really source it. Even if the majority of what is on WR is unsourced, the goal should be to strive toward sourced pages. There is however one exception to this - two persons are known to be siblings but the parents themselves are unknown. Honestly I dont see whats wrong with when seeing a page with no parents and the source says nothing about them, then they must not be known. "And now for my question of what do you do when someone was adopted and there is no record of the birth parents?" - well, their adopted parents arent really their parents. It would seem that if their biological parents arent known, that you dont add anything at all or have a note to that effect. Daniel Maxwell
I certainly support deletion of Unknown pages that do not contain any useful information. However if there is useful information, such as identifying siblings or other family members (eg parents), discussion of potentially who these people might have been, etc, then you should NOT be deleting the page. To me Unknown should mean unknown identity which is different than saying that nothing whatsoever is known about these persons. Sometimes much useful information can be known about someone whose name has not yet been established.
If we are going to operate from the assumption that Unknown pages should not exist then maybe we should title cases where the name has not been established as Uncertain rather than Unknown. But unless that convention is agreed and applied then blanket deletion of Unknown pages is a BAD PRACTICE.
--Jhamstra 09:35, 20 December 2012 (EST)
Let me clarify; by 'delete' I mean 'remove the link to'. I have no power to delete pages beyond the ones I created where I am the sole watcher. Several times I have run into an end of line 'John Smith' who for no reason has a stub 'Unknown Smith' and 'Unknown Mrs Smith' linked to him (in one case with 2 generations of 'Unknown'!). Thats the only thing I remove. I dont remove those in the case where there are known siblings but nothing is known of the parents. In fact, I did one of these recently when I was finishing up the early John Marsh of CT line. A sourced example - Person:Unknown Marsh (9). Daniel Maxwell
Feel free to mark such pages with the speedy delete template before cutting them loose. Also, when nominating a page for delete, don't feel that you have to be absolutely certain that the page is wrong. Probably is good enough. Also consider the difficulty of re-creating the page. If the page is essentially empty, or doesn't contribute a potentially useful link, it's no harder to re-create later than if you leave the page for now. In other words, the bar for speedy delete is very low for empty end-of-line pages. --jrm03063 11:22, 20 December 2012 (EST)
It occurs to me that my suggestion may not have been clear enough - I meant to do (1) and (2) and (3) - not (1) or (2) or (3). Creating an Unknown page with no further information does not add value to the database
Let me also offer another example of how I have dealt with the problem of uncertain parentage and known adoption. Consider Richard Stansell. There are no VRs for Livingston County MI in the 1830s. Circumstantial evidence seems to point to Richard being a son of Henry and Mary Stansell, however some researchers consider Richard to have been the fourth child of Nicholas and Susannah Stansell who reportedly died unmarried. After the death of his parents Richard was adopted by Linus and Phoebe Clark. Depending on who were his parents they either died before 1850 or after 1860.
--Jhamstra 09:58, 20 December 2012 (EST)

Replying to Jrich: "We could presumably come up with 5 new template along the lines of nomerge, that can only be removed by manual editing, and modify the GEDCOM upload to respect these. They don't exist now, and software changes seem to have a long lead time, so that's not much of an answer at the present" - yes I think that would be an excellent development, with benefits in several areas including this one. I understand the development time is fairly long at the moment but I think that's ok - surely that's one of the benefits of "beta" that we can still have these discussions? AndrewRT 16:03, 20 December 2012 (EST)
Yes, we could do this after the fashion of nomerge - but positive assertions about negative information are useful plain-sight facts. They also have potential utility in an exported GEDCOM, even if other systems couldn't use them automatically. --jrm03063 18:59, 20 December 2012 (EST)
How did we manage to have a duplicate topic on the Watercooler? This topic is duplicated twice. I do not support "duplicate" parents. My preference is to indicate the possible parents in the narrative with links to the parents. Regarding known siblings whose parents are unknown; I know of no way to link them without creating unknown parents. In the future WeRelate plans to have an interactive genealogy program. Our decisions should be compatible with a genealogy program. I do not know if any genealogy program supports duplicate parents. --Beth 19:36, 20 December 2012 (EST)
Hopefully I only removed the duplicated part (left by a previous poster).
Few genealogy programs are designed for use by more than one person at a time so if the person favors one theory, he simply enters it. The collaborative environment introduces new needs. In this case, I think there is general agreement the answer is unknown, but other cases there have been camps that feel strongly one way, other camps that feel strongly another way, and some people that think both are possible (e.g, magazine articles written when the argument was raging over how many wives Person:Thomas Prence (1) had, were passionate and presented believable evidence both ways). Usually, after the straightforward attempts are made to resolve such problems, the next step is to branch out to siblings and other close relations looking for clues that might solve such problems (such as real estate inherited, or descriptions of relationships mentioned in wills and deeds), so keeping such links has value in illustrating the impact of the proposed relationship. As mentioned before, the presence of two parent links pretty clearly indicates the links are unproven, as opposed to the typical case of one parental link.
We could add notes to explain this, if duplicate links were not to be used, though to be thorough, that involves adding notes to at least three pages, Richard Kimball's and the two prospective parents, each saying there is a possible connection, because really all three are affected by the potentiality of the prospective connection. The way WeRelate works, the adding of a Richard Kimball page by a new user could start in any of those three pages. The failure of a new user to see the note could result in a duplicate page, or adding one set of parents, or the other, because the new user is merely following the one source they have in front of them.
So, if duplicates aren't allowed and no parents are to be listed, I guess the protocol becomes every time some new user or GEDCOM adds one set of parents, or the other, the watchers inspect the provided sources, and simply remove the parents again, unless the author has cited some primary basis that can't be explained away? --Jrich 13:00, 21 December 2012 (EST)

I think it best to not link parents when there is insufficient evidence to establish their identity. To me this this is because we are trying to present truth here, and having a link to a parental family implies the (collaborative) site's assertion of adequate support for the relationship. This is true whether there is a known alternative hypothetical set of parents or not. So one should not keep a link to an unsupported parental family whether or not one can add an additional link to another unsupported parental family as well. Of course we should show on the person's page the conjectures for parentage and what limited supporting evidence there may be for or against them; they should just not be shown as formal parents.

From the discussion to this point it seems to me that this is the consensus: that neither of the contending sets of parents should be linked as parents. As brought up, there are some advantages to the alternative, but overall it sounds like people think it best to leave then unlinked.

The suggestions for flagging the problem with a template seems good to me. Maybe someday a software enhancement can use the flag to limit linking by GEDCOM upload, merging, or whatever. Even before that, though, I think a visible notification on the person page can be helpful in alerting people to the situation. This should reduce the attempts to add parents without adding supporting evidence but will not eliminate them, so we can expect to have to remove unsupported parents from time to time in spite of using such a template.

Towards this end, I have set up a draft template at Template:Parents Unknown. Please feel free to improve it, or discuss changes on the talk page there (or, of course, discuss the advisability of having it at all right here). --Robert.shaw 17:56, 21 December 2012 (EST)

Thanks for pushing the question. I agree that we should only link a parent, spouse, family, etc., when there's a very strong case to do so. Perhaps not perfect, but strong. If there are contenders, then we should indicate as much in a disputed lineages section on the person page and respective family pages (even though the text is duplicated - you can write it generically and often copy paste.
I want to be a little more careful on how we do the information/added fact templates. We want to allow for the description of a number of situations, and do so in a way that is easy to find and recognize (by humans AND software) later on. Let's get a full list of the things we know we want to assert. Then we can decide whether each one is a template on its own - or whether we can do this as a smaller number of templates with parameters. Even if there are multiple templates - we'll want to do them all in a similar manner. We should probably move that discussion somewhere else...I'm writing a suggestion called "assertions". --jrm03063 22:54, 21 December 2012 (EST)
You are speaking of missing info or known factual info; what about known errors? In my Jackson line there is a known error attributing the wrong parent to the wife of a Revolutionary soldier. The error was accepted by the DAR for years and so researchers accepted it. The DAR was notified and now does not accept applications based on that error. But numerous genealogy trees using that info are still floating around. I can describe the problem on her talk page but that wouldn't stop erroneous GEDCOM uploads. How could a template be worded to refuse to upload erroneous parental information? And how many folks would have to agree that it is erroneous before using such a template? --janiejac 15:12, 22 December 2012 (EST)
Very true. I'm not sure about handling it automatically, but that doesn't mean we shouldn't try to come up with a standard way to declare/structure this sort of thing. I'll take this over to the suggestions page on assertions... --jrm03063 19:18, 22 December 2012 (EST)
I don't know if this is the same conversation or a different one, but I think a key thing we can do in developing standards for a true pando is to tag relationships where there are a significant number of people elsewhere who have asserted it to be true but we have good reason to believe either it is false or suspect. Stage 2 is then to integrate this into GEDCOM uploads so that they aren't added in by future activity. AndrewRT 19:31, 22 December 2012 (EST)
I think it's the same conversation. For starters, the assertions couldn't do more than give us a standard way to note some key things. We would keep in mind that we want to make automatic use of such data, and try to make sure that people AND programs could understand it, but it would probably be some time before we had programs making use of it. I don't think there's a sane way to objectively represent more than one structure at a time in WeRelate. When there are differing interpretations, I don't see that we can do much better than choosing the best of the bunch (presuming one is considered to be the most likely), or choosing nothing. My practice would be to discuss both the prevailing and minority opinions in "Disputed Lineages" - and to carry that "Disputed Lineages" content to the different pages implied by the various interpretations. --jrm03063 00:20, 23 December 2012 (EST)
From a more theoretical point of view - I suppose you could create a genealogy environment where any given person or family page could have 1 or more interpretations. Connections to other person or family pages would have to name both the page and the interpretation at each connection. It might be able to be done - but I wonder how usable it would be. --jrm03063 00:27, 23 December 2012 (EST)
Thinking about this a little more - the above approach might work in the most common cases - but it would probably be impractical for someone like Henry I, where there are different interpretations for a number of potential children. Assuming four children who may (or not) be his - a full page level interpretation would mean 16 interpretations. Five children - 32, etc. Would have to think about whether there's a different way to structure different interpretations, such that you wouldn't get a combinatorial explosion. --jrm03063 00:40, 23 December 2012 (EST)
After a while I figured out you had put up a formal "Suggestion" (page here). This surprised me a bit since it seems like it needs some discussion before a suggestion for software implementation could be formalized. Also, I assume we want a design that editors can start using without waiting the probable very long time before the WeRelate implementors can do anything about it. Do you think the mechanism's needs and variations should be discussed and decided upon there, or here (new topic?), or on some other working/discussion page?
I'm so sorry if my "suggestion" implied that this was in any way ready for decisions to be made. Very far from it I should think! I thought that this might be getting a bit large for to be hosted on the watercooler - and that I wanted to expand it and formalize it enough to show a direction I thought this might go. I'll mark it to indicate that it's still the subject of very active revision and discussion. When the three or four of us who have shown interest start to approach consensus, then perhaps we offer it for consideration as a standard practice/convention. --jrm03063 21:13, 23 December 2012 (EST)
Anyway, plunging ahead: The idea of using an "other" event in "Facts and Events" seems a bit stretched, but investigating it I found that it at least would seem viable. If one adds an "other" event and places the template invocation in the "description" field, then the page displays it reasonably well. For an example of what it would look like for an assertion where we are trying loudly to make uploaders/mergers/browsers aware of the assertion, see this sample page. (Obviously we wouldn't use it in a simple end-of-line situation like the sample; it's just to show how an "other event" would display. The normal event-related date and place fields would not seem to have any use.
For GEDCOM exports, the "other event" generates a line like "1 EVEN {{Parents Unknown|parameters}}" which at least makes moderate sense if we name the templates well. What various programs would do when importing such a GEDCOM event is hard to say, but at worst it probably just gets thrown away.
That's good. I suppose it's also possible that the GEDCOM export could be made smart enough to recognize and expand/transform the templates on export. --jrm03063 21:13, 23 December 2012 (EST)
The use of an event does position it well on the WeRelate page it seems to me, as for at least some of these assertions we want the display high up and visible. I guess the only real alternative to using an event field is to place the template invocation in the general "content" text box, where it might tend to get lost. --Robert.shaw 17:41, 23 December 2012 (EST)
Thanks for your careful consideration/review. Please, feel free to modify/revise/expand the "suggestion" as you see fit. --jrm03063 21:13, 23 December 2012 (EST)
Well, it looks great on the displayed page, but on a merge screen(and probably on a GEDCOM upload - been so long since I've done one I can't say for sure), all you see is the text typed in, i.e., the name of the template. Further, even at face value, my response as a user would be: "You think the parents are unknown? Not me! I know who they are! After all, I found an Ancestry Family Tree that says so!" So it should something like "Please read all notes on this page before changing.", and it probably needs to be supported by the software before it is going to matter.
In your example, the template's invocation {{Parents Unknown|not|Arthur Miller}}, has arguments. But the template itself doesn't seem to take arguments? --Jrich 22:40, 23 December 2012 (EST)
Yeah, the parameters "not|Arthur Miller" are bogus and the template as it was drafted doesn't use any; I just put them there to cover that case for viewing & export and didn't bother with display. You're right that this (or any, I guess) template won't show up well for imports or merges wihtout software support. Just seems to be a fact of life.
The "parents are unknown? I know who they are!" issue is quite real. Because of that, I'm now leaning towards explicit naming of the unproven candidate(s) via parameter. The wording would have to be different. It may be much like "Debunked Parents" in structure, but needs wording more about unsupported, not proven wrong. --Robert.shaw 23:15, 23 December 2012 (EST)
I'll offer a couple things. I don't think the templates need to expand into a box - a standard text item ought to be enough. It might also be helpful if the template expansion included a link to a page describing in greater detail what the assertion templates are meant to do and what any given template implies. Finally, as with other facts - we would like to positively support them with sources and/or a note. To be sure, until there's software support, people can do what they will, but GEDCOM import time is just one moment in the life of the data. I still anticipate consistency checking software that wanders around the database looking for combinations of facts that are mutually exclusive (parents born after children, etc.). This sort of item just becomes another fact combination detected by that process - "parent unknown" with a connected parent page would be flagged as an inconsistency. --jrm03063 10:31, 24 December 2012 (EST)
GEDCOM import is just one moment in the life, but there are others, and all the moments where a page is being changed, be it merging, editing, etc., all you see is the template name, not the template message. Adding a template is really just a negative measure, in my opinion, to stop people re-adding stuff that has been removed. However, I still feel the need is to deal with possibilities, and not just is or isn't, all or nothing. A more positive approach may be to give each fact (including parents) a status of accepted, possible and rejected, for example. Then we don't have to throw away possible data just because it's not provable. It's the same idea that suggests there can be birth dates and alternate birth dates (e.g., Person:Elizabeth Cogswell (8), Person:Rhoda Aldrich (1)), even though we know a person can only be born once. Having multiple variations is a reflection of the state of our knowledge, not of what really happened. --Jrich 11:47, 24 December 2012 (EST)
I had an exchange above w/AndrewRT on a theoretical approach to handling multiple genealogical interpretations. I don't think it can be done in a way that is easy enough for humans to understand, general enough to handle all the situations, and structured enough to make it useful for software analyzing the database. I do think there are a handful of a useful special cases that we could support though. Certainly rejected corresponds to debunked and accepted corresponds to the actual connection structure. We could have another set of templates corresponding to the "Debunked" list, that indicate potential or candidate relationship connections. I'll scratch something in for folks to look at. --jrm03063 12:40, 24 December 2012 (EST)

I have copied the recent comments above which concern templates to a section of WeRelate talk:Suggestions/Assertions. I suggest we continue the template discussion on that page (since it is not directly about handling two contending sets of parents, the original topic here). --Robert.shaw 16:05, 26 December 2012 (EST)


reliable source? [30 December 2012]

I just found an online source for Source:Virkus, Frederick Adams. Abridged Compendium of American Genealogy : First Families of America: A Genealogical Encyclopedia of the United States. I added the URL to the book and created the repository. But I am not familiar with this work. Is it considered reliable data? --janiejac 11:15, 30 December 2012 (EST)


quick scan of its pages reveals no citations or footnotes. quickly scanned its intro as well and saw no reference to sources, but i could have missed. it. Jillaine 12:04, 30 December 2012 (EST)
It's encyclopedic, which is a big strike against it. Not to generalize too much, but these type of works usually have too much breadth to do a good job and usually end up pulling in information from various published sources without any real attempt to verify it, not to mention the limitations of a cramped format. I concur with Jilliane. Would want to verify anything it says with better sources.
There are actually 7 volumes and some indicated as limited seem pretty much full view.
  • Full view v.1 (original from University of Michigan)
  • Full view v.2 (original from University of Michigan)
  • Limited (search only) v.3 (original from University of Michigan)
  • Limited (search only) v.4 (original from University of Michigan)
  • Limited (search only) v.5 (original from University of Michigan)
  • Full view v.6 (original from University of Michigan)
  • Limited (search only) v.7 (original from University of Michigan) --Jrich 13:05, 30 December 2012 (EST)

Virkus is not considered a reliable source. He, among others, was discussed in the following excerpted from The American Genealogist, 73:316, October 1998:

"EDITORIAL NOTES AND OBSERVATIONS

COURTESY AMONG GENEALOGISTS; There is a general maxim among scholars that they should treat with courtesy those with whom they disagree. Too often it seems that this maxim is forgotten in the give-and-take of argumentation, but it is one that we try to hold to in TAG. There is a very human tendency to decide that those whose ideas we disagree with must be ignorant or evil or just plain wrongheaded. TAG, of course, is known for its critical articles and reviews, including some in this issue, and for its refusal to accept unproven traditions and legends But that does not mean that there is something wrong with the people who hold the views that we are criticizing. It is ideas and conclusions that must be held up to critical evaluation, not those who support them.

This statement, however, must be qualified. It does not apply to the dead, and we frequently reach conclusions about the quality of work of deceased genealogists. We would be irresponsible if we did not warn readers about such writers as Orra Eugene Monette, John S. Wurts, or Frederick Adams Virkus. Nor does it apply to those who have committed conscious fraud, like Gustave Anjou, Horatio Gates Somerby, and Harriet Bainbridge De Salis. …"

I would add that any of the massive compilations, such those edited by Cutter, should be treated with caution since they were often cut and paste efforts contributed by any number of correspondents other than the editor. These, and works by those mentioned in TAG, may provide useful clues but prudence dictates that they be checked against other sources.--jaques1724 13:57, 30 December 2012 (EST)

I've added a warning quote from Jacobus to the source page. Note the confusing fact that only the first volume of the seven volume set used "Abridged" in the title, and there were several subtitles. WeRelate has four source pages for variants. --Robert.shaw 17:11, 30 December 2012 (EST)
Wow! Thanks to everyone who took the time and effort to answer my question!! I knew you folks would know the answer to my question! --janiejac 18:54, 30 December 2012 (EST)

Attention Wing Nuts! [5 January 2013]

Ok, I wanted to use that topic... :) ! A recent GEDCOM has added a lot of Wing family members with citations mentioning only the Wing Family Directory. I also noticed that there were a couple different Source entries, seemingly, for the same directory. I've consolidated those in Source:Wing Family of America, Inc. Wing Family of America, Inc. Directory. I have also found that the directory content is actually maintained on RootsWeb, so I have created a template to support useful/linkable citations to the Wing database.

I would appreciate it if some folks more familiar with RootsWeb and/or the Wing family would review what I've done. --jrm03063 15:19, 2 January 2013 (EST)

The RootsWeb database for the wing family has proved to be extremely weak, and a note discouraging its use has been accordingly added to Source:Wing Family of America, Inc. Wing Family of America, Inc. Directory. --jrm03063 09:42, 5 January 2013 (EST)

Soldiers from the medieval period [4 January 2013]

This is an interesting site that I found recently.

You can search the 2 Databases, 'Muster' and 'Protection' under various criteria (I have used just the surname option so far) but you will need to be very flexible with the spelling ; these are records from the 1300's and 1400's ! It will accept wildcards, eg. Gr* or We*.

Even if your search is fruitless from a personal family history point of view (although if you do find a possible ancestor the problem is then making the link from the 18th or 19th century !) the information displayed is interesting from a purely historical point of view.


http://www.medievalsoldier.org/search.phpColin Madge 08:19, 4 January 2013 (EST)


Lost someone ? [4 January 2013]

Maybe a blacksheep of the family ?

This may be of interest to anyone, who whilst researching their family tree, have discovered female convicts who were transported to Australia.

The site is from the Female Convicts Research Centre http://www.femaleconvicts.org.au/

They are currently trying to connect the female convicts who were transported to Van Diemen's Land with their birth and marriage families in the UK and their descendants in Australia. They are searching for gaol and trial records and newspaper stories about our women.

All good stuff - Membership of the website is free and once a person joins they have free access to the database. All the work is done by volunteers.--Colin Madge 08:25, 4 January 2013 (EST)


US Immigration site 1830 - 1892 [4 January 2013]

The following website might be useful to those searching for ancestors who emmigrated to the United States. It pre dates the period covered by the Ellis Island website.

http://www.castlegarden.org/Colin Madge 08:37, 4 January 2013 (EST)


Proposed discussion on WeRelate's Person Page age limit [11 January 2013]

There's something I've been thinking about, which I'd like to bring up for discussion. Ever since I began doing research in the newly-released 1940 U.S. census, it strikes me that forbidding pages to be created on WeRelate for possibly still-living persons less than 110 years old is kind of pointless. I understand the issue of personal privacy and the potential for identity theft and all that, and I agree with it -- mostly. But, of course, I'm coming across quite a few children who are 1 or 2 years old in 1940, which means they would be in their mid-70s now, and many will still be alive. (I daresay there are a few regulars on WeRelate who have found themselves in 1940.) And then there are the now-public World War II draft registrations, which include quite a few persons who are still living. The 110-year limit is meant to eliminate all living persons (except for the handful of longevity record-holders worldwide) -- but is this unnecessary overkill? I know several states have gone full retard and have shut down their entire online vital records databases, including back into the early 19th century, which is a stupid bureaucratic over-reaction. And I don't know what the comparable age rule is in the UK for release of their censuses and other data. But if the 72-year limit is good enough for the U.S. Government in balancing privacy with access to public information, shouldn't it be good enough for us? --MikeTalk 10:30, 4 January 2013 (EST)

There are actually a lot of publicly available records (e.g., Minnesota, Birth Index, 1935-2002 and other familysearch collections) that go quite a bit past 1940, not to mention obituaries that mention various people. So availability of information by itself is a slippery slope (i.e., in the words of Dr. John, if you don't do it, somebody else will). With average life expectancy in the eighties, a limit of 72 doesn't quite seem long enough even if the government does use it. So there seems to be a need for a guiding principle and whatever it is, it will undoubtedly be inconvenient for some situations. --Jrich 10:59, 4 January 2013 (EST)
At the moment, the guiding principle seems to be one of inconsistency, which is what I'm questioning. --MikeTalk 08:35, 5 January 2013 (EST)

UK census release dates are 100 years after the event. And they are usually late.
Canada has a 92-year rule on censuses and 1921 is expected out late this summer. --goldenoldie 12:01, 4 January 2013 (EST)


I've been frustrated by that too, but if you're sure someone has passed, can't you fill in a "bef. 2012" DOD? Or is this something that you want to control at GEDCOM upload time? --jrm03063 12:40, 4 January 2013 (EST)

Well, yes, and I do that all the time. (Actually, I just put a "Y" in the Death field, which accomplishes the same thing.) But I also transcribe the 1940 census listings and include them on the page for the Head of Family, even when I don't create pages for the young children listed, so the protection supplied is specious. And I'm not willing to exclude the 1940 census, or to censor it by omitting people within the listing, so what does the limitation accomplish in this case? --MikeTalk 08:35, 5 January 2013 (EST)
I don't think the fact that some organizations have been less strict than others means we have to follow the most permissive. I agree that 72 years is too short, as a large percentage of people born in, at least, the decade before that are still alive. Regarding your last question, having a census transcription in the text, which often has misspelled names and estimated ages, is more opaque to both Google and humans as to who exactly the entry relates to than creating a page would be.--Amelia 10:51, 11 January 2013 (EST)

Handling true aliases and time-resolved name changes [4 January 2013]

I am working on inputting information related to Person:Francis Yockey (1), who was known to use several aliases during his life. It would be very useful to be able to suppress the auto-categorization to 'surname in place' categories for aliases. If you look at the record, you'll see that the aliases are treated exactly like the actual surname. Maybe the solution is to add an additional name-type of "alias" which does not trigger auto-categorization, but does not block manual categorization.

There is the very different matter in re name-in-place which could be time resolved. For instance, a person might be known by a particular name for a particular period of time and that would be valid in a particular place; then later, they would be known by a different name in a different place for a particular period of time. This is a much more complicated issue, which is mostly related to maiden vs. married names and legal name changes (such as transgender- or self-protection related changes).

Much to think about. --ceyockey 20:47, 4 January 2013 (EST)


Supercentenarians [8 January 2013]

I have created a category for supercentenarians. Wikipedia: A supercentenarian (sometimes hyphenated as super-centenarian) is someone who has reached the age of 110 years. Do you have anyone you are working on that would fit in that category? You can add them to the category by adding this to their page: [[Category:Supercentenarians|Last Name, First Name]] --cthrnvl 21:44, 7 January 2013 (EST)


Printable-WeRelate [16 January 2013]

I've added a project page for this little project. It produces printable output from werelate data: a big family tree with just BMD information, and an A4 book with everything (well, basic info, facts, relationships, biographies, and citations; there's more to come, like images, trascriptions, etc.).

The book output is currently looking like this. (There're problems with it, certainly.) I'm currently working on the source citations: getting them formatted, and linked from the correct places. At the moment, it's just putting them in as footnotes to the fact list (and not even formatting them very well). Next will be the inclusion of images.

I'm only mentioning this here as a heads-up, really, and to see if anyone would be interested in being a beta-tester. I can set up a demo from your data. Leave a comment on the talk page if you are.

Sam Wilson ( TalkContribs ) … 19:52, 13 January 2013 (EST)

There doesn't appear to be attribution, as required by http://www.werelate.org//wiki/WeRelate:Terms_of_Use#Information_for_re-users. --Robert.shaw 00:49, 14 January 2013 (EST)
eek, yes, good point! I certainly always meant to add it; I'll do so.  :-) Thanks! — Sam Wilson ( TalkContribs ) … 00:51, 14 January 2013 (EST)
I've added a short copyright notice to the tree and book (e.g.). I will be including all contributors' usernames, once I've sorted out the bibtex stuff (which will be used for all citations; rather than the footnotes I've currently got it producing... I think... I'm open to suggestions...). — Sam Wilson ( TalkContribs ) … 05:03, 16 January 2013 (EST)

Website/s [18 January 2013]

I'm taking the liberty of moving the content of this discussion to the Source Portal talk page - where the source committee can reflect upon it at their leisure. --jrm03063 10:30, 18 January 2013 (EST)


Templates for marking questionable relationships [23 January 2013]

In an earlier Watercooler discussion ("Handling of parentage contenders?"), there were suggestions that it would be helpful if we had a good way of showing speculative relationships.

The main problem is that sometimes there is a candidate for a relationship (e.g. father) which is not presently adequately supported, yet some people browsing or editing may not realize it. We don't want to link the candidate normally (e.g. as the father) since that implies we know the relationship to be correct. So it was suggested that it would be good to have a standard way of presenting such a speculative relationship, perhaps using templates.

The discussion continued on WeRelate talk:Suggestions/Assertions and has now developed into a prototype system of templates to support this and related needs. These templates support:

  • Refuted relationships
  • Speculative relationships
  • No-accepted-relationship assertions
  • Confusion avoidance alerts

(I don't see this as replacing "Disputed Lineages" sections, as those are needed to present detail that these templates cannot.)

This is still a trial mechanism and we would like feedback from the community in order to assure it proceeds in the best direction possible.

You can learn about the template system at Help:Assertions.

Please try it out, and add comments and questions to Help talk:Assertions.

--Robert.shaw 15:41, 23 January 2013 (EST)


Hi Robert, one template some of us have used in the past to identify Person or Family Pages with "problems", such as children born before their parent's marriage date (or the parents for that matter), or other mostly obvious situations is this one:

Questionable Information Found
template for pages with questionable or incorrect data


I'm assuming that the difference between the "Refuted relationships" and "Speculative Relationship" depends whether you agree or disagree with the evidence (of lack thereof) provided, but some researchers have used "disambiguation" to distinguish between contemporaries with the same name or same area during the same time period.

I do like the idea of coming up with some type of "un-proven" relationship indicator, but it may cause some minor disagreements over lineage to become editing wars when the template is placed on a Person or Family Page. We should come up with a specific policy over WHEN and IF they should be used...

Just my $.02.

Best regards,

Jim

I hope the help descriptions of the different templates offer sufficient guidance on when they should be used. I'm also hopeful that some former disputes can be smoothed over, because it's now possible to compromise at "speculative" - taking concrete notice of a possible relationship - without either accepting it or dismissing it completely.
"Refuted" is a little different - as it is meant to provide a way to take concrete notice of things that formerly were accepted or - at least - published - but which the community now agrees are not true. It's meant to help us guard against the re-introduction of errors when innocent contributors work from older reference materials. Of course, if someone isn't really satisfied with a "refutation", then compromising at "speculative" remains a choice.
The notion of "disambiguation" is, I think, carried in the template for "NotToBeConfusedWith". Unless there's disagreement on whether a single name represents one or two people I supposed. --jrm03063 19:15, 23 January 2013 (EST)

Family History (What's Next) [7 February 2013]

I was wondering how future generations will cope with family history.

With more and more people choosing to live with someone , rather than marry.

Children with parents in "families" who have different fathers.

Gay marriage and Civil partnerships.

Hope we are ready and not to confused.

Colin--Colin Madge 08:54, 28 January 2013 (EST)

I have a tentative plan. I mean no disrespect to anyone's choice of partners, but I reserve the "family" object for either
  • a conventional heterosexual marriage
  • a heterosexual relationship that results in one or more children (even w/o formalities)
  • indicate relationships established by adoption, as a 'fact' that is present in both the adopted child's page and the adopted parents family page (assuming the adopted parents are married heterosexuals)
  • children of a same-gender relationship will either be adopted by one or both of the parents, and at most, the natural child of only one of the parents. In that case, the child's fact list would include adoption items for both parents, and the parents fact lists would contain items indicating the adoption and the formal relationship with their partner.
Or something like all that...
Alternatively, under the covers, WeRelate is capable of allowing multiple people of the same gender as spouses, but the interface as most people see it generally hides that. It's possible that the interface could be modified to allow a family to be specified as other than a heterosexual relationship - but that would mean software changes. The steps I note above could be accomplished with assertion templates - and no software changes. --jrm03063 11:24, 28 January 2013 (EST)
"It's possible that the interface could be modified to allow a family to be specified as other than a heterosexual relationship" - but then the person in question wouldnt be that person's parents. Whatever you think of homosexuality (and personally I really, really dislike this injection of politics on WR), paternal relationships are a biological fact that can not be argued with or changed. You either are or you are not a couple's child. I dont know what the current policy is with adoptees, but it seems that it is wrong to put adoptive parents as the actual parents of a child, because they are in fact not. Daniel Maxwell
For some years, there seems to have been a strong (and growing) division among family researchers over the definition of "family." Some insist on the "sociological" definition: Anyone raised by a couple is a "child" of that couple, whether adopted or not. The other side (which I subscribe to, personally) takes a genetic approach: A person is a "child" of the couple whose DNA that person carries. The first group tends to be really affronted when the second group tries to explain that adoptees aren't the same as biological offspring, genealogically speaking, and that this is not an attack on adoptees or gay couples or anyone else. It has nothing whatever to do with politics or social agendas. I have plenty of political opinions -- but as a genealogist, I'm interested in documenting someone's physical, generation-by-generation descent from those who lived earlier. And, God knows, my family has its share of "non-birth events" to struggle with, just like everyone else's. --MikeTalk 09:57, 29 January 2013 (EST)
I agree with you completely. It all boils down to biology. There is no intent to offend anyone. But its just a biological fact that every living human being has a father and a mother, and it cant be any one or anything else. Those adopted kids and illegitimate children do have biological parents, and finding out who they are is the entire purpose of genealogy. To the point though, I would oppose any of the sociological definitions being added to WR. Daniel Maxwell
When I suggested that a family relationship need not be of simple heterosexual form, I didn't take a position on whether such a family is allowed to link children in the ordinary way. My thinking is no - but that's all sort of beside the point. WeRelate is someone limited by the desire to be able to import and export GEDCOMs, and things that you can't sensibly represent in a GEDCOM are problematic. I think a more practical alternative is sketched out here. --jrm03063 10:23, 29 January 2013 (EST)

For me, the original poster is getting at the distinction between genealogy and family history. And do note that they used "family history" in the title, not genealogy, which as others have pointed out is the study of genetic relationships. But I'm sensing that there is an increasing interest in the intersection of these two approaches. And perhaps even a significant target audience as or more interested in history than genes. I know I have a foot in each camp. What the original message says to me is that the software-- whether wiki or elsewhere-- is not really "ready" for such a demand. And it could be that as more and more people want pto document their family history, they will seek tools and communities that will help them do so.

Jillaine 11:21, 29 January 2013 (EST)


I'm thinking that it would be wise if we had a working plan of record for handling this stuff - and it would be neither hard nor require software changes to do something. It would amount to agreement on a set of conventions for fact templates, of the same sort proposed for defining when the evidence for a relationship is questionable - but we still want to be able to objectively indicate the possibility. Is there any interest in such a proposal? --jrm03063 12:07, 29 January 2013 (EST)


I'm with Jillaine on this. And I would guess that family history is what is driving a lot of the interest in genealogy these days. This is one of the reasons WeRelate is my preferred site -- the Text field on each Person and each Family page allows the potential for narrative that can serve as family history and/or as the narrative that is one of the essential requirements of genealogical "proof". If, as Ancestry advertises, "every person has a story to tell", then WeRelate is a place where you can actually tell that story.

As for adoption, it is one of the events listed as an option on the Person page. The adoption wouldn't have to be legal to be added, if you ignore date and place and just fill in the name(s) of adoptive parent(s) or family in the description field (with links, if wanted). Still, I wonder if it would be possible to add an extra field to the Person page: "Adoptive Parent" (with the option of adding more than one); as well as an extra field to the Family Page: "Adoptive Child". For people just learning to use WeRelate, that would probably be the easiest way to deal with adoption and satisfy contributors' need to display both genetic and social relationships. (Templates are important and useful, but they are also a pain to learn/remember and learn to use. Sorry.) That would also reduce at least some of the Duplicate Pages that appear on the Duplicates list.

An input page that helps the user create such data would be better, but templates can let us accomplish what we need in the meantime. Moreover, the internal representation still has to make sense within the restrictions of GEDCOM input/output, so this sort of information would wind up being cast as "other" events anyway. --jrm03063 15:40, 29 January 2013 (EST)

The more interesting -- and probably more difficult -- issue is the one that Mike rather hints at. Documented "non-paternal" or "non-birth" events can be dealt with in narrative, at least. But what about the growing number of well-documented "standard" genealogical relationships that DNA is starting to disprove? This is a genealogical as well as a family history question.--GayelKnott 14:08, 29 January 2013 (EST)

When DNA disproves a long-held lineage - we have to treat it like any other piece of information that refutes previously held facts. --jrm03063 15:40, 29 January 2013 (EST)
I've been peripherally involved in two extended family/surname DNA projects, and in both of them the descent of more than one of the principal lines from the presumed progenitor seems not to be proving out. This has upset a number of people, mostly those who have tended to brag on their descent. (I think there's some karma at work there. . . .) The whole DNA thing is beginning to have a major effect, I think, on the assumptions of family researchers regarding the frequency of non-birth events in even recent history. Probably a good thing. --MikeTalk 07:29, 3 February 2013 (EST)
Totally agree. My question was: and how are we going to handle this in terms of computer programs that are based on lineage connections? Because the "blood" linkage is what is supposed to be charted, but many of these people probably assumed that the "blood" and social linkages were the same (i.e., they didn't know that their genetic and legal fathers were not identical) and lived their lives accordingly. So do we just throw out everything they knew and thought about their own lives because it doesn't fit the computer program? This, I guess, is where you really have to decide whether you are researching people (who lived lives) or names and dates (and had vital statistics). --GayelKnott 13:37, 7 February 2013 (EST)
If I understand it correctly, DNA (unless you get it for your immediate family) isn't showing anything about immediate ancestry - or any given lineage in particular. I think it makes both soft statements like lineage A->B1->C1->D1->...X1 is consistent/intact with respect to a lineage A->B2->C2->D2->...X2. In special cases (maternal mitochondrial DNA?) I think it can make hard claims (like what we've seen respecting Richard III). But even there, it's only saying that the historically recorded female line from Richard's time to the modern day descendant appears to be intact. It could be that the modern day sample source isn't a descendant of Richard - but they are a descendant of whoever's bones those are - but we accept this as proof because it seems unlikely that two implausible events would line up to still create a consistent result. So other than adding a fact in a descendant indicating that some accepted ancestral lineage has an unknown break - I'm not sure what else we could do.
Only if you know a specific link - that some child is not the genetic child of an accepted parent - would there be anything to do. Then - I suppose - you could drop that child from the family, and indicate them as de-facto adopted. --jrm03063 13:58, 7 February 2013 (EST)

New template to help avoid edit conflicts [17 February 2013]

If you are working on a page for a period of time and would like to avoid an edit conflict, you can add this template to the page to warn other users. There is a parameter to indicate how long you plan to work on the page and add an optional message about the changes you are making. Other users are advised not to edit the page while this template is in place. This is meant for short-term projects and should be removed promptly so that other users may contribute. This template is new, so if you have any questions or comments, just let me know! --Jennifer (JBS66) 11:22, 10 February 2013 (EST)

Many thanks.--GayelKnott 19:08, 13 February 2013 (EST)

This seems like a solution in search of a problem. The first time I experienced an editing conflict I realized why it happened. I learned if I had had an edit open for a significant time I would copy my edit into a wordpad file before saving the edit, then if there was a conflict, I lost nothing.--Scot 22:45, 16 February 2013 (EST)


Browsing templates [14 February 2013]

Is there a way to browse templates? I am sure others have deposited some good stuff, but how can one find it? --goldenoldie 02:56, 14 February 2013 (EST)

You can use the Browse Pages item in the Admin menu. It lets you page through a list of the templates (only shows 10 items at a time). -Moverton 13:24, 14 February 2013 (EST)
You might want to try browsing starting at Category:Templates. It looks like a categorization system was set up just over a year ago, and so you can get an idea of what sorts of templates are available. Of course if a template has not had appropriate Category lines added to it, you wouldn't find it this way. Be aware that some of the templates you find may be abandoned and never or rarely used; at least that's what I recall noticing when I skimmed some templates a couple of months ago. --Robert.shaw 14:41, 14 February 2013 (EST)
There is also this page to scan: http://www.werelate.org/w/index.php?title=Special%3AAllpages&from=&namespace=10 --janiejac 15:40, 14 February 2013 (EST)

Category surname - geographic location [28 February 2013]

Dear friends I have some issues / questions regarding categories and the overall strategy. I start with a component. If this is not the right place, then move my writings.

I spent a lot of energy to create categories, because I think it is important. On 15 February 2013 Klaas made me be aware that in the near future to automatically add a category surname - geographic location will be abolished. I was horrified. I find this auto category of great importance. Klaas motivated that there are now too many geographic locations are automatically added. I disagree.
A common surname contains the category name, a great mountain rice pudding to people with this surname in the earth. (I look at the most by F) It's nice that the people with this surname, through an automatic category a global distribution on this earth get. The states of USA and the countries of the world. 80% of people continue to be listed in one geographic location. (Country or state) In relation to the few people in more than two of these sites occur. (There is more mass when people used more than two surnames have. Again this is only a small percentage)

Advantages of category surname - geographic location.
-When I have a whole family in the Netherlands after 1850 can not be found, the search for a needle in a haystack. When I use the name of the man (or woman) find in eg Belgium / Denmark / Zuid-Afrika/India is an indication in that country further.
-With the advent in the U.S. often change the name. Johannes Mol was Jack Mole. Johannes Mol falls in the Netherlands not there are more than 1000. But the name Johannes Mol in Utah falls though, especially when he's actually just as Jack Mole known.
-Klaas Terpstra emigrated to Chicago, but it seems that 20 years later he married in the Netherlands. With the automatic categories Terpstra family in the U.S. to trace.

One can manually the category name - geographical location capture. The information would get more of the essential data is reduced. But who is going to do that? In a gedcom of 1000 people go to another view 1000 times. That will not happen. The categories thus giving only partial information and are thus less useful. For me there is no more motivation to create them. The chain is only as strong as its weakest link. Better as it goes nothing.

I find this useful Category:Hall surname

Greeting,--Lidewij 08:26, 21 February 2013 (EST)

Beste mensen ik heb een aantal kwesties/vragen ten aanzien van categorieën en de algemene strategie. Ik begin met één onderdeel. Wanneer dit niet de juiste plaats is, verplaats dan mij geschrift.
Ik bestede veel energie aan het maken van categorieën, omdat ik het belangrijk vind. Op 15 Februari 2013 maakte Klaas mij er op attent, dat in de nabije toekomst het automatisch toevoegen van een categorie familienaam – geografische plaats zal worden afgeschaft. Ik schrok vreselijk. Ik vind deze automatische categorie van groot belang. Klaas motiveerde dat er nu te veel geografische locaties automatisch worden toegevoegd. Ik ben het hier niet mee eens.
Een veel voorkomende achternaam bevat in de categorie achternaam, een grote rijstebrijberg aan personen met deze achternaam op de aarde. (bij F kijk ik het meest) Het is prettig dat deze de personen, met deze achternaam, via een automatische categorie een globale verdeling op deze aarde krijgen. De staten van USA en de landen van de wereld. 80% van de personen blijven genoteerd in één geografische locatie. (Land of staat) In verhouding zijn het maar weinig personen die in meer dan twee van die locaties voorkomen.(Er is meer massa wanneer personen meerdere dan twee gebruikte achternamen hebben. Ook dit is maar een klein percentage)

Voordelen van categorie familienaam – geografische plaats.
-Wanneer ik een heel gezin na 1850 in Nederland niet meer kan vinden, is het zoeken naar een speld in een hooiberg. Wanneer ik de achternaam van de man (of vrouw) vind in bv. België / Denemarken /Zuid-Afrika/India is dat een indicatie om in dat land verder te zoeken.
-Bij de binnen komst in de VS verandert men vaak de naam. Johannes Mol werd Jack Mole. Johannes Mol valt in Nederland niet op er zijn er meer dan 1000. Maar de naam Johannes Mol in Utah valt wel op, zeker wanneer hij daar eigenlijk alleen maar als Jack Mole bekend is.
-Klaas Terpstra emigreert naar Chicago, maar het lijkt er op dat hij 20 jaar later in Nederland trouwt. Met de automatische categorieën is familie Terpstra in de VS te traceren.

Men kan zelf handmatig de categorie familienaam – geografische plaats vastleggen. De informatie zou zo meer tot de wezenlijke gegevens gereduceerd. Maar wie gaat dat doen? Bij een gedcom van 1000 personen ga je dat nog eens 1000 maal bekijken. Dat zal dus niet gebeuren. De categorieën geven dus maar gedeeltelijke informatie en zijn op die manier minder zinvol. Voor mij is er dan geen motivatie meer om ze te maken. De ketting is zo sterk als de zwakste schakel. Beter zoals het nu gaat dan helemaal niets.

Ik vind dit zinvol Category:Hall surname

Met vriendelijke groet, Lidewij 08:26, 21 February 2013 (EST)


I had not yet had an opportunity to write the proposal that the Overview Committee spoke about recently. Let me explain the rationale now.

There are automatically created categories that exist at the bottom of most pages. These categories do not appear when you edit a page, only when viewing a page, thus, they cannot be edited. There are some limitations in their scope, their level of user-friendliness, and man power to organize.

Examples

Person & Family pages: Person:John Smith (90) automatic categories are Category:Smith surname and Category:Smith in Massachusetts. These are generated from the Surname and every place listed in the event fields.

Source pages: Source:Zubrinsky, Eugene. Carpenter Sketches automatic categories are listed at the bottom of the page and are generated from the Surname and Place fields.

Place pages: Place:Hatfield, Hampshire, Massachusetts, United States automatic category is one level up from the current page title.

Many times, you will see at the bottom of pages these categories are red-linked. Their hierarchy must be manually created - just adding text to these pages does not "create" them.

Some concerns

  • Must be manually created and organized by a person knowledgeable with the hierarchy structure
  • Categories are generated only to the Country level, except in the United States where they are generated to the State level
  • Confusion between Surname in Place categories such as Category:Schregardus in Netherlands and Surname in Place Articles such as Schregardus in Friesland, Netherlands
  • Automatic categories cannot be edited

The thought is the current (or an improved) search feature can better help users find and navigate pages and would not require such a large investment of time from users and administrators to manage. This would allow more specific user-created categories (such as Category:U.S. Presidents) to receive better attention. So, I'd like to ask for input. Do you find the automatically created categories to be useful? Do you use categories such as Category:Surnames, Category:Surnames by country, and Category:Hautes-Pyrénées, France to find a person/family/source/place you are looking for? Feedback and questions are welcomed! --Jennifer (JBS66) 09:13, 21 February 2013 (EST)

Jennifer, the manual creation of the categories can be seen as a disadvantage. The advantage is that you are right some control option. If an incorrect category is usually not the only problem with the pages that belong to that category. Old GEDCOM still need care come this way to the top. There are red link, but there are almost no categories with over 110 topics. And every week, that number down. Automatic categories can not be edited, but it can not be forgotten. And it can not be tampered with.

The Category:Hautes-Pyrénées, France is another story. Groet, --Lidewij 09:55, 21 February 2013 (EST)
I've found the automatic behavior of surname-oriented categories to be a headache for medieval and noble lineages. I offer a proposal of my current practices along with attempting to engage some discussion on the associated talk page. The two lines of thought emerging there (which may not be mutually exclusive) are to simply not use the surname field or to obtain software support that would let us deactivate the automatic behaviors associated with the surname. It was specifically observed that - where patronyms are concerned - the practice of supplying them as a surname may be so deeply embedded that discussions of whether that is or is not a proper/modern surname are somewhat beside the point.

I can't think of anything I have used categories for that doesn't work better with search even under the current system.--Amelia 10:39, 21 February 2013 (EST)


Until recently I avoided using categories. I could not get my head around their usage. Then recently I started working with a family which had been uploaded to WR by someone else who had not provided much more than bmd information, usually without sources. I decided to build up the 19th-century information for a section of this family that lived in Ontario, Canada, and which, much to my surprise, were related to my own family very distantly by marriage. Suddenly I found an automatically-produced category useful.

But I also found a problem. The surname has three or four spelling variations--sometimes invented by census enumerators and local registrars, sometimes passed down the family. Could a group of similar surnames be incorporated into one category manually? --goldenoldie 10:43, 21 February 2013 (EST)

I wonder if you could create category pages as redirects? That's what I'ld try anyway - taking whatever form is least common, then trying to make the category page a redirect to the form that is more common. Alternatively, you could indicate the less common form page as being in the category of the more common form. Then the less common form would show as a sub-category of the common form, but that's probably not what you want. Good luck anyway... --jrm03063 11:09, 21 February 2013 (EST)
Redirecting category pages is not recommended. See WP:Wikipedia:Redirect#Category redirects and WP:Wikipedia:Categories for discussion#Redirecting categories. --Jennifer (JBS66) 12:20, 21 February 2013 (EST)
Surname pages such as Surname:Swart include information on related name variations. The information entered on Surname pages is used to return variant names in searches. There was a large variant names project that was intended to replace the related names section of surname pages. I am not sure what stage this is at in regards to Dallan migrating all the information to the new system. --Jennifer (JBS66) 12:30, 21 February 2013 (EST)

Amelia, if you know exactly what you're looking for, you can use the search system. If too many topics that gives it all a lot less to use. Do not know the correct spelling then gets stuck. Groet,--Lidewij 11:02, 21 February 2013 (EST)

Actually, I think search is much more useful if you *don't* know what you're looking for - it automatically handles spelling variants and gives you additional information in the display, neither of which is true of categories.--Amelia 14:16, 21 February 2013 (EST)

Goldenoldie, you may submit multiple spelling variations use Add alternate name. You can also look at Surname:XXXX, for Related Names. We make this site, maybe you should still fill the other spelling variations. groet, --Lidewij 11:16, 21 February 2013 (EST)

- - - -

I would like to support the comments by Jennifer and Amelia. From when I first joined WeRelate two years ago I have always regarded Categories as awkward and unnecessary. From my background in systems engineering they are nothing but pushing off onto the users the burden of creating and maintaining database search indices - a process which good databases have automated for decades. If we try to (manually or automatically) create and maintain indices for all of the combinations that different users might care about (eg surnames with or without variants combined with location to whatever granularity is deemed appropriate) the entirely predictable result will be the "combinatorial explosion" of categories which the people who steer this site are now backing away from. Ditto for trying to maintain a hierarchy of Categories which is bound to break - history has shown that except for very simple databases hierearchal indices inevitably collapse over time.

Far better to invest the time and energy in a better search interface - more control over which data or combinations or variations "match" the query plus more control over the order in which the large numbers of matches are presented. If we allow users to create and save their own search and sort criteria things will go much better than if we try to anticipate in advance all the combinations of things users might wish to search. Automatically generated Categories can be better served by a small number of canned search or templates. This already exists for simple searches for People, Places, Sources etc and could be extended for combinations of People and Places, etc - and (very important) more control over how the matches are sorted (hierarchal sorting of results trumps hierarchal maintenance of indices). User-defined Categories can be better served by allowing users to create and save their own search templates. Consider adding Searches and MySearches pages, and showing in the Search drop-down a list of the common Searches followed (after a break line) with a list of MySearches. --Jhamstra 13:28, 21 February 2013 (EST)

I generally agree, but this -- "User-defined Categories can be better served by allowing users to create and save their own search templates." -- I don't agree with. By definition, a category should be generally applicable. The equivalents of "X's ancestors" and "Y's Descendants" are not allowed. Thus, any user-defined categories should be created to be useful to the community, both as a marker on pages and as a browsing mechanism. A personal search template doesn't do that.--Amelia 14:16, 21 February 2013 (EST)

My two cents is that I have found little use for categories, personally. If I have a relative that is a US President, it doesn't mean I care about the other 40+ enough to want to link them all together in a category. That seems much more geared towards an encyclopedia than genealogy. But certainly people engage in genealogical projects that involve grouping. But there is some question in my mind about what types of groupings are universal enough, since categories must be shared by all.

As far as automatic categories, due to spelling variations, they are probably useless. A surname article giving overview of branches of its family, and etymology of the name is all useful, but not sure how many people find a category page with 100s of people on it all that useful. Agree searching offers more more focused way to find the related people supposedly being grouped together by automatic categories.

I think a related issue is the use of template banners. I think they are trying to accomplish a function that seems appropriate for categories, and would rather remove the excessive glitz of the banners, as distracting, potentially clashing and intrusive, since many banners only represent groups important to the user that created them, but the banners are visible to all. If there is some overview or navigation common to a bunch of pages, it would seem like it should go on the category page which are easily accessible by link but less obtrusively displayed. --Jrich 14:32, 21 February 2013 (EST)

The private search save, must make sense. Once you found what you were looking for, you usually do not need it anymore. It is a human quality to a good search to start and not everyone has that quality. This search is not an option for someone who occasionally comes along. This Category:Hall surname is clear and inviting.

Everyone has a different way of doing genealogy. When I, in 2007 wikipedia, started contributing I never used the categories. When I am at the moment (10,000 contribs) I find something that usually through the categories. Unknown is unloved.--Lidewij 14:43, 21 February 2013 (EST)


As has been shown over time, different people learn and do research in different ways. What one person finds helpful, another may find cumbersome and vice versa. I, personally, find that categories are helpful in how I do research, because I am able to see at a glance up to 200 uncluttered people that fall under the surname which I am researching. This also gives me a quick, alphabetical snapshot of what research may or may not have been done, what resources someone else may have connected to a specific surname and whether someone else has touched on a family which may be of interest to myself. I understand that the search engine is supposed to be designed to bring the same information forward in one form or another, but I find that I prefer the organization and information of the category pages instead, as long as they are used properly. I admit that the Categories as they currently stand can be cumbersome if they are simply allowed to grow out of proportion, but any useful tool needs maintenance of some type and the Categories are no exception.

It would be unfortunate to lose what I consider a useful tool simply because it isn't used by everyone, unless of course this is actually a space issue (so many categories take up too much hard drive space). If that is the case, then, by all means, do as needs to be done to maintain the overall site, but if it is not, my position would be to keep Categories and find ways to make that tool easier to maintain.

SIDE NOTE: On running various tests of the search engine, I find that I am unable to determine why the individuals of the results given are ordered in the manner that appear on the screen. Anyone else have a handle on this one?--Khaentlahn 20:37, 28 February 2013 (EST)


The barriers are too high! I'm about to give up. [2 March 2013]

I am a mature and intelligent person. I am a seasoned genealogist, Mediawiki administrator-author-editor, and a former computer programmer for a public school system. I have tried placing my genealogy here, but the barriers are just too high.

I agree that uploading GEDCOMs may not be the best way to go for werelate.com. I uploaded some GEDCOMs, but can't find any software to prepare them for the standards expected by werelate.org. Manual data entry is just too time consuming for me to enter data here and maintain my research elsewhere.

I have had little success entering sources. They are the last straw. I do have very good sources, but don't seem able to enter them in a way that is acceptable to the demands of the software. Place names are another problem. I always use "local, regional, state, country." With no standard, things get confusing.

I may give it one more try. I think the basic idea for werelate.org is wonderful, and touches the future of genealogy. I am a septuagenarian anxious to get my work freely available to the public before it is lost. whroll 16:14, 24 February 2013 (EST)


We're trying to strike a balance here - between support of GEDCOM uploads and not letting the site be overwhelmed by content that people load - and then walk away from. I still routinely find myself dealing with content that was uploaded and abandoned from 2007.
Maybe if you pointed at a page or two where you're having difficulty, we could help you? --jrm03063 17:00, 24 February 2013 (EST)
I would be willing to show you some pointers. I will edit some of your pages to give you examples of how to use the sources. Once you realize that many of the sources you will need are actually already on the site, it becomes quite simple. user:DMaxwell

Mr. Roll, you can't give up! Not when I just found you again last night! I am not very computer literate and have found the learning curve very steep. I, too, am entering by hand rather than uploading a GEDCOM. And sources are, I agree, real bears but... you can't quite! You have too much to offer this forum and I really appreciated last night learning that you were here!


If you upload a GEDCOM with sources you can simply leave the sources as MySources. I might be speaking heresy but it is an option.

Jillaine 18:13, 24 February 2013 (EST)


It would be a shame for anyone with high quality data and good sources to give up on WeRelate, but I can sympathize with the difficulty of managing sources and places. I find this the most tedious part of loading GEDCOM files, but tell myself to have patience, grit my teeth and put in the time and effort. It usually takes me an hour or two to match sources, including creating new ones, each time I upload a GEDCOM file with 70-100 sources.

I have found, as DMaxwell says, that sources already exist for many books (although it can be a pain to determine if they refer to the correct edition, since they often include the reprint date instead of the original publication date). I also create new sources for individual journal articles. Maybe if you let us know what types of issues you are having with sources, we could offer more targeted advice.

In terms of place matching, I found when I was loading US data, automated place matching was almost complete and very reliable, but it is less so for other countries. My personal format is similar to WeRelate, but not identical (I usually includes "twp" when appropriate) - and the automated matching still works for places in the US.

As Jillaine says, it is not essential to match sources, and there is a suggestion to enhance WeRelate to make it possible to redirect MySource pages to Source pages, so if you decide to go that route, it should be possible to "fix" the sources relatively easily in the future. If anyone is looking at your data and can't stand that it is using a MySource, they could always change it to point to the correct Source page. It is all part of being a community that shares data.

If you are still finding GEDCOM upload too frustrating, don't deprive WeRelate of your data. At the very least, look for partners to help you load it, or turn it over to someone who is willing to load it. I am still in the process of adding my data to WeRelate, which involves doing more research to improve the quality first, so I'm not ready to take on anyone else's files yet, but I would expect that this is the kind of volunteer work I might do in a few years. As a point of interest, can you give us some idea on the volume of your data (number of people, number of sources and places, countries covered)?--DataAnalyst 19:43, 24 February 2013 (EST)

Volunteer Partners! What a wonderful idea! Is there any hope that this idea could be expanded somewhere? I have not had the time nor skill to break my large database into smaller bits to upload. This would really reinforce the idea of a collaborative site! I would love to have my database on WR but it has become a job too big for me. I haven't even been able to 'clean up' the pages I've already uploaded. --janiejac 11:26, 27 February 2013 (EST)
How large and how intertwined is your database? I have some experience with breaking a database into smaller parts - it is like a puzzle and is a nice occasional break from hunting down source citations. --DataAnalyst 21:29, 27 February 2013 (EST)
Thanks for asking. I wrote the details on your user page. --janiejac 13:05, 28 February 2013 (EST)

The most pertinant comment here is the lack of tools to prepare gedcoms for werelate I,d be interested to hear of peoples experiences in this regard


Your desktop program should have all of the tools you need available. I use PAF which is not as full featured as some other programs but has all of the capability required. 5 years ago I worked out a procedure that should work today. Find it posted on 20 Nov., 2007 at Muti copies of people and/or families? 24 November 2007 I don't know what happened to Ronnie, she used to welcome new users like Amy today--Scot 13:50, 28 February 2013 (EST)


Specifically, tools which could move data from FTM into werelate. FTM now syncs with ancestry and it does much of the source work for you It treats sources in a relational way not the heirarchy approach of gedcoms--Dsrodgers34 21:54, 25 February 2013 (EST)

That would end up being a mess; we definitely do not want to start syncing WR pages to FTM; FTM has fewer options for data and source entries (Ancestry.com is notorious for treating baptismal dates as birth dates, for instance, and burial dates for death dates, not to mention the many garbage 'sources' people use in trees there that would have to be scrubbed), which would screw with the whole site. I can just imagine the headache it would be to go back and fix pages that were 'synced' with someone's tree in FTM. user:DMaxwell

Sorry, you misunderstand me. I'm not talking about syncing just a simple upload. Ancestry, and its partner software, ftm has its problems for sure, but if it is used properly I'd rate it a 7 out of 10 compared to a huge amount of trees going around. Don't werelaters complain that gedcoms come in with a negligible amount of sources ?

What was proposed was discussion about some kind of tools which could be used to prepare gedcoms before upload into werelate. That way some of the common problems could be fixed with search and replace type tools. The alternative is lots and lots of manual rework within werelate, very tedious. I'll try to be clearer next time I contribute.--Dsrodgers34 14:59, 27 February 2013 (EST)

I'd be curious to know what kind of "massaging" of GEDCOM files is needed. I know I do some on mine, but what I do could all be handled by the WeRelate GEDCOM uploader if it were a priority to make the changes to the uploader. All the changes I make to my GEDCOM files are essentially for esthetics - remove DEAT Y, remove _SDATE tags (sort dates), convert months from uppercase to mixed case and "abt" and similar qualifiers from uppercase to lowercase. Additionally, for some reason I have never questioned, the Living fact gets converted to an Other fact by the WeRelate uploader and I have to fix them all in WeRelate. But none of this is earth-shattering or has anything to do with source citations, so it makes me curious what types of problems others are facing. BTW, I use RootsMagic, which I love. Each source is listed only once in each GEDCOM file, with citations for each fact refering to the source - am I right in inferring from the discussion that other genealogy tools don't do that?--DataAnalyst 21:26, 27 February 2013 (EST)

Although I haven't downloaded a gedcom in about 2 years I learned early on to keep them small - 30 to 50 people. I export first to my genealogy software, run my genealogy software potential problems tool on the new file, correct the problems and view and edit, then, if satisfied, create another gedcom and export it to WR. It would not be unusual to go through two cycles before exporting to WR. I abhor encountering duplicates and by keeping the number of people minimal I can do a quick search of WR for potential duplicates.--HLJ411 21:15, 27 February 2013 (EST)


I was going to suggest exactly the same thing. If you break up and load your gedcoms into specific families (obviously the ones that are well-researched and sourced are more preferable), it makes it easier to go through each smaller gedcom in order to 1) make sure it is correctly merged with existing families on WeRelate, and 2) keep the source data in place (which is important to many of us). As has been well-stated above, this is not a "dump and run" genealogy site where marginally researched and documented gedcoms will have to be "fixed" (or deleted) after the submitted leaves.... After you "get the hang of it" with smaller chunks, it gets easier with each one.

Thanks for your understanding and we hope you stick around and help to "raise the bar" on submissions here at WeRelate.

Best regards,

Jim


I definitely agree that the barriers are too high. It's too hard to contribute, either by adding individual entries or by uploading GEDCOMs. As a result, I personally think WeRelate is far too small to be useful as a resource - it needs to cover hundreds of millions of people not a couple of million. At this rate of growth the site is likely to be overtaken and die before it actually makes a significant impact. We don't need to raise the bar - we need to lower it. AndrewRT 17:31, 28 February 2013 (EST)

The entire point of WR is pool the best resources and sources together for the most accurate information. There is a tide of bad genealogy that WR is swimming against. That some people havent figured the quirks of our system is not the fault of the site. Lowering the bar (where, in my opinion, it actually needs to be raised) would turn this under another GEDCOM graveyard of misinformation. Genealogy isnt easy work, and many other sites need to stop giving the impression that it is. Daniel Maxwell
Yes, there is a tide of bad name-collecting genealogy, and WR should work against that, but nevertheless having unnecessary barriers to new users is a fault of the site. There is no need to lower the bar about the quality of additions, but there very much is a need to remove barriers that do not serve to improve the quality of the research presented. Specifically, the interface implies that one must link uploaded places to WR Place pages and sources to WR source pages. This does not improve the quality of the research presented on WR (although it does make WR very slightly more useful). These form barriers to new users, and these barriers tend to keep WR small and therefore less useful and relevant generally, and that situation may lead to its eventual demise. --Robert.shaw 18:08, 1 March 2013 (EST)
I completely disagree. Linking the items to said sources is one of the best features of the site. Now, one could make the case that it should be more automated, but it is not a detraction of the site. On the contrary, it is beneficial. One of the pitfalls of internet genealogy, particularly when moving from paper and pen family trees, is that the sources for the given information get lost. In some cases, even within my own tree, the originals cannot be found (if they are obscure), and we have what appear to be completely unfounded assertions, while they may not be. Other things you mention such as place names conforming to one other improve the neatness of the site. If there were a movement of the users on this site to remove links to sources to make the site easier (and therefore uglier), or to scrub the site of citations, source text, etc I would probably cease contributing completely. Daniel Maxwell
I've been lurking in the background following this discussion. In my opinion, I've made two really good decisions regarding the genealogical data I've collected over the last fifteen years or so. (1) Don't upload the data to the on-line data collections such as rootsweb or the Family Tree Maker site. I've got over 130,000 persons in my database (why so many is another discussion, suffice it to say that I'm very interested in a macro approach to early New England families, not the micro approach to only my own ancestry). Possibly 15-20 percent of those people were taken from questionable sources, rootsweb or the former LDS site. (2) In almost two years on WR, I have not uploaded a gedcom. Making the entries one at a time forces me to go back and evaluate the sources and, often, to discover better sources which I had not been aware of before. Thus, I'm inputting "better" data. I would add that I don't mind the drive-by gedcoms where folks have done a one-time upload and then disappeared. There are often kernels of fact embedded therein which lead to more substantive data.--jaques1724 19:22, 1 March 2013 (EST)
Yes, in fact when I joined here at first I too was confused about sources. Your excellent, neat work (among a couple of others) - which is what caused me to notice WR in the first place, I then used as a model in my work on WR - a model I had been wanting to move to my own personal tree and have since done so. Realizing the problems with GEDCOMs, I have never uploaded one to WR (though I started to) and I agree that it has made me think before I create a page - can I prove the data, or would it be better if I waited till I can prove it? With regard to the drive by uploaders, I guess its mixed to me; when I recently did the complete ancestry of the immigrant Jonas Austen (which took several days) I made all of the people, familes, sources etc by hand. But the result was much neater than if I had dealt with a messy ugly old gedcom upload, but it did take much longer. Daniel Maxwell

I've read the whole of this section with some interest. There seem to be several reasons why some people are thinking of leaving. If you fail to be dissuaded by the convincing-looking responses in this section, please consider or reconsider Familypedia, which is smaller, which does not yet have a recommended GEDCOM upload facility (though several thousand articles were created by a GEDCOM manipulation procedure), which has a very easy form-based system for adding and editing articles about individuals, and which does not have demanding standards about sources or places while it encourages the recording of sources. Familypedia also has Semantic Mediawiki, which is possibly superior to WR in some aspects of display and search results. You do have to put up with a little advertising (but even Rootsweb has that); you see less of it if you register. Robin Patterson 23:34, 1 March 2013 (EST) (another septuagenarian)


Discussions of evidence [26 February 2013]

While I'm here, I have a question concerning where is the best place to put a discussion of the evidence. It seems to me the Person page is best for biographical, narrative type of stuff rather than a down-in-the-weeds discussion of the fine points of comparing differing transcriptions sort of discussion dealing with alternative interpretations of the evidence. The Person Talk page might be better but there is no way to handle sources or quotes from transcriptions without retyping or doing cut and paste. How do others handle such discussions?--Renee Dauven 17:23, 24 February 2013 (EST)

The person talk page is really the best - if you're discussing evidence for that person - since the discussion becomes part of the record for others who follow. --jrm03063 17:53, 24 February 2013 (EST)
The talk page not a good place in theory because these issues are not discussions between two people (i.e, talk), but elaborations on the facts presented on the page, and are often as important to understanding why the fact is there as any source. The talk page is not a good place in practice either, as the indication that there is a talk page is too easy to miss, it stays "lit" even when the talk page was erased and has nothing on it, it often only has nomerges, and the talk page isn't visible during merge or gedcom upload. If the narrative gets too long, centralize these topics in a section with an appropriate header. Since this is not a single user site, there are several issues about dealing with alternative genealogies and uncertainty that there aren't good answers for, and good guidelines haven't been developed. --Jrich 20:38, 24 February 2013 (EST)
It depends on the nature of the comments and whether one is looking for feedback and interaction. If the latter, like you're wondering if fact X is significant to establishing a relationship, then the talk page seems appropriate. On the other hand, if you think there is some subtlety in the data supporting some stated fact about the person, something that people (who care about evidence) should be aware of, then the Person (or Family) page is appropriate. Remember that people will see what's on the Person page, but may not notice the Talk page, and that only the Person page information appears in a GEDCOM download.
It's fine for more than biography to appear on a Person page. Separate "== Sections ==" should be used to make clear what's what. For instance, it's been a common practice to have a "Disputed Lineages" section on a person page under which discussion is included about the evidence supporting alternative relationships (e.g. alternate parents). --Robert.shaw 17:28, 25 February 2013 (EST)

Robert do you know of a page were a disputed lineage section was created that I might look at and maybe use as an example? Thanks all for the suggestions.--Renee Dauven 19:21, 25 February 2013 (EST)

A little search turned some up; here are three using Disputed Lineage sections: Person:Thomas Welles (1), Person:William Marche (2), Person:Samuel Mayo (2). I don't know anything about those people, but in a somewhat similar vein, I added a section (not titled "Disputed Lineage") discussing evidence to Person:Isaac Van Camp (1). --Robert.shaw 03:00, 26 February 2013 (EST)

British nobility [5 March 2013]

There is a lot of public domain information readily available about British nobility, e.g. through the out of copyright editions of Burkes peerage on archive.org. Has anyone else attempted to add this information to werelate? Would anyone get interested in forming a mini-project to do this? Cheers AndrewRT 14:58, 3 March 2013 (EST)

A few people (including myself) have been adding records - I am not sure how complete. Other sources used are The Peerage by Darryl Lundy, who has made extensive use of books on British peers, as well as Medieval Lands by Charles Cawley, who has used many sources and gone back to original sources wherever possible. If there were to be a concerted effort to add records based on Burkes peerage, I would consult these other sources as well, as in some cases, they have more up-to-date research and/or evaluation of research (Cawley, in particular, but I am not as familiar with Lundy). Others have gone through existing records in WeRelate and linked them to Wikipedia articles, where relevant - with the knowledge that the quality in Wikipedia is hit-and-miss. I haven't worked on this for a couple of years, but would be interested in coming back to it in a few years.--DataAnalyst 22:23, 3 March 2013 (EST)

Interesting thanks. I like peerage.com very much but im wary about how database rights would come into play if we replicate a significant portion of his website. Has this been considered at all? AndrewRT 08:48, 4 March 2013 (EST)

I'm always leary about using a large chunk of another person's work (in respect to the work they have put into it), but the fact is that you cannot copyright the facts about another person (e.g., birth date and place, death date and place). It is the conclusions and commentary where we have to be careful, and always make sure to give credit. I haven't quite figured out how to do good quality genealogy without depending on other people's conclusions (e.g., "there were 2 Richard Bronson's in this town at this time and this is how I split the facts between them", or "I don't buy the tradition that so-and-so was the father of this person because of such-and-such"), so I try to make sure that I give credit, and, where feasible, dig into the sources myself and come to my own conclusions. I also try not to use a single source, but to cross-check it with other sources, so at least the new data is not a strict copy of someone else's work (parts of it might be, but not whole trees). I am pretty sure that whatever I do is legal as far as copyright is concerned, and I hope it is considered respectful as well. For British nobility, I would leverage Cawley and sources he points to as well as peerage.com. I think that is the essence of research - building on other people's research, and giving credit. --DataAnalyst 18:57, 4 March 2013 (EST)
Collections of facts DO have intellectual property protection in some non-U.S. jurisdictions (e.g. Europe), thus AndrewRT's reference to "database rights" as opposed to "copyright." I presume WeRelate wants to play on a global scale, so non-U.S. intellectual property laws are as important as U.S. laws. Tfmorris 23:39, 4 March 2013 (EST)

We're presently using Cawley on about 2700 pages, and Lundy on about 5700 (Follow-up of 3/5/13: as of this AM the real champion of DB usage is Wikipedia, on a total of about 20,800 Person pages, many of which are Royals and Nobles). I've exchanged e-mail with both of them and found them helpful and responsive. I've found a handful of duplicates in Lundy's database over the years, and he's always pleased to get any help of that sort. Cawley is much more of a specialist of course (no chance I'll find defects there!) but was very helpful when I asked what the best practice would be for us doing cites of his work, for purposes of link compatibility with future versions.

I'm not particularly interested in duplicating Lundy's content, but I am interested in - some day - being able to run cross-database consistency checks for content that both WeRelate and thepeerage share. I think we may be able to find issues in the content of both sites and to generate potential improvements for both.

I'm more interested in a semi-exhaustive representation of Cawley's work, at least for purposes of people who correspond to HTML anchors in his documents. If we get that far - maybe it would be worth discussing with him whether to add anchors more universally in his work (thereby allowing a systematic database of his content without him needing to change his preferred presentation or method of working). I've also recently started adding cites of Cawley to category pages for relevant houses of nobility, which is sort of slick.

I don't think either Cawley or Lundy are threatened by cites from WeRelate. I would think that we're driving traffic their way and giving them visibility, which is just as I would have it. We don't, and shouldn't, replicate their sources or narrative - so I figure we're legally clean as well as ethically so. --jrm03063 20:55, 4 March 2013 (EST)

---

Thanks for responding - very interesting. Yes it's the highly problematic European concept of "database rights" that I was specifically referring to as a worry. I would hate for us to be very successful and then find in a couple of years time that we had to delete loads of our content following a court case. Wikipedia is not a problem of course, given it is CC-BY-SA licensed like us. Hence my preference for out of copyright books.

Regarding, "replicating their sources or narrative": this sparked a thought - let's say they decided to donated their entire content, which part would not be suitable for use on WeRelate? I think pretty much all of it would be great additions here!

Regarding my mini-project, I've started some thoughts at User:AndrewRT/British_Nobility. The most promising lead I have seen so far relates to a book on "The royal lineage of our noble and gentle families". This sounds a great link to our vision of a pando as it will already link to many people already covered by WeRelate. All feedback welcome on that page or here. AndrewRT 16:33, 5 March 2013 (EST)


Wikipedia hi-jacked? WR agent taken in [5 March 2013]

The most recent upload of details from Wikipedia for the template {{Wp-Mitchell, Ontario-History}} gives the name of the first settler as Asif Patel in 1836. This is a change from a man named William Johnston in the previous upload. Both names are very common in their own cultures and much of Ontario now has residents who came from many lands, but in 1836 Johnson would have been much more expected than Patel.

Having written the above, I went over to Wikipedia to check its sources and found it cited an online book entitled History of Mitchell, Ontario by William Johnston; History of Perth County 1825-1902 Chapter XXV, Stratford 1903. The chapter in the book does not refer to William Johnston.

To top it off. Wikipedia does not list any changes to its article since 2009. The contributors' biographies are far from being those of mature historians. It is my suspicion that we are letting ourselves be duped along with Wikipedia. --goldenoldie 02:48, 5 March 2013 (EST)

{This note also to be found in {{Template talk:Wp-Mitchell, Ontario-History}})--goldenoldie 02:56, 5 March 2013 (EST)

Certainly has the potential to be a case of WP vandalism - would suggest you fix it both in the local WP template and on WP proper. --jrm03063 08:18, 5 March 2013 (EST)


This is a normal situation because WR periodically copies the latest version from Wikipedia, whether it's been vandalized or improved. In this case, it is vandalized, quite possibly by a young Asif Patel. (It's not hijacked, as Wikipedia allows anyone to change most anything, and someone did just that.) By the way the "Asif Patel" change went into Wikipedia on 17 January 2013, so that change is relatively recent.

This is not a great WR policy except if the Wikipedia text has never been inspected by human eyes on WR. Many place pages on WR have never-inspected Wikipedia text, so for them the periodic update is reasonable, since on average the text will have improved despite it sometimes being worse (as in this case). However, if a WR editor has looked over the Wikipedia text, we should somehow mark it so that it thereafter will not be automatically overlaid by a later Wikipedia version. --Robert.shaw 14:45, 5 March 2013 (EST)

I'm not sure I understand the benefit of periodically updating wikipedia text - the changes are as likely to be problematic (as the original requestor has moved on) as improvements. I would suggest we leave them as they are with an option for someone to request an update if required. AndrewRT 16:13, 5 March 2013 (EST)
I don't think so. We just did an update, and there have been many thousands of changes. This is the only one that has been singled out for this sort of problem, and presumably (if it hadn't been seen here) - it would have been fixed in the normal course of events by our next WP update. --jrm03063 16:45, 5 March 2013 (EST)

Family Tree is Live on FamilySearch.org [13 March 2013]

Family Tree is Live on FamilySearch.org for All Users - Wondering what the WR community thinks about this and the possible impact it will have on the future of this site? --Cos1776 16:02, 7 March 2013 (EST)

Already being a registered user of familysearch.org, I logged-on and looked at Family Tree a bit. It is a much simpler interface compared to WeRelate, but not obvious whether one can do some of the more-sophisticated things that WeRelate can do.
That being said, ease-of-use is NOT to be taken lightly and this tends to reinforce a concern that I have previously expressed and that comes up periodically. Whenever someone suggests that WeRelate consider if there might be an easier-to-use method for doing something, there seems to be instinctive push-back from the "Guardians of the Wiki" that we should resist making things "too easy" as this will only encourage carelessness on the part of newcomers. Better to keep the barriers high and discourage all but the most serious contributors. Nevertheless, best systems engineering practices include designing interfaces to encourage "proper" behavior by making it easier to do things the right way (capture sources, check for duplicates, etc) rather than the wrong way. Most of the suggestions to make things easier for WeRelate contributors seem to fall by the wayside - and probably take other potential contributors along with them.
I take the view that competition among genealogy web sites is healthy. Those that best meet the needs of the potential contributors will flourish and those that do not will wither. Demand for change is one of the prices of success of any product or service. Those that evolve to meet the changing needs of their market tend to prosper - those that resist change tend to either go away or survive in narrowly-defined niches. --Jhamstra 16:45, 7 March 2013 (EST)
I did not see a way to import a GEDCOM file. I know that GEDCOMs have been a source of controversy at WeRelate (too easy to add lots of bad data, too hard to use), but for me, it is the only practical way to meet my desire to have my own (quality) database and to share it without introducing a bunch of typos or having to copy source citations (of which I have a lot). Since FamilySearch starts with what appears to be the Ancestral File (which I hope they have cleaned up somewhat), it has the advantage of starting with lots of data, although there may be a lot of junk if they have not cleaned it up significantly.
I think one of the things that will continue to cause WeRelate to struggle is the limited programming resources. Dallan is great, but it is pretty hard to meet everyone's requests for new and improved features with only one developer. When I was in that position once, I had a permanent backlog of at least 100 items that would never become high enough priority to address - and I had a user community of only a dozen people, not hundreds. So, Dallan, we appreciate you, and personally, I appreciate the opportunity to have a say in how the site evolves, even if it is not possible to address everything we would like to see.--DataAnalyst 18:55, 7 March 2013 (EST)
I am probably one of those 'Guardians of the Wiki" you speak of. While I do not want to see it made *too* easy, I have always been happy to support improvements that will make it easier to *properly* contribute to the site without harming the caliber of contributions. But many of the suggestions that have had support either havent gotten added and others havent been commented on (such as moving cemeteries as places to oly the burial location box). This site needs new programming blood, as one man cannot do it all alone. Daniel Maxwell
WeRelate would greatly benefit from assistance across the board! Users who are interested in helping programmatically are encouraged to consider Website features or Bots for page maintenance. Users interested in less technical volunteer opportunities can look over the various patrols at Portal:Maintenance. Leave a message on the talk page of the group that interests you, and we'll let you know how you can help.--Jennifer (JBS66) 10:37, 10 March 2013 (EDT)
I've been using Family Tree for several months now, and while I tend to see it as the "Second Best" on-line site, I think WeRelate is far superior. For one thing, in spite of appearances, many of the changes that need to be made to relationships (parent/child or husband/wife) can be incredibly difficult and frustrating because they are totally counter-intuitive and require way more steps than anything here at WeRelate. And DataAnalyst is right about GEDCOM uploads. Not there. True, as he said, lots of entries already there, but some are old and have major, major problems. There are a lot of other limitations, as well. Positive points: it is a true "Match and Merge" site, it is Source Driven (as much as possible given human nature), and it's likely to be around for a very long time. I still prefer WeRelate and all the extra features it has, and, believe it or not, the fact that it is easier to use. --GayelKnott 20:54, 7 March 2013 (EST)
Please do not misunderstand me - I am NOT ready to jump to Family Tree. It is for some situations a simpler interface but I have not tried to do anything more complex there, nor am I likely to for a variety of reasons. Nevertheless, I find the lack a Source-driven interface for WeRelate to be very cumbersome, especially when trying to apply the same Source to tens or even hundreds of Persons and Families. I am sympathetic to the issue of "Dallan overload" but as with many other software systems where I have provided detailed feedback, it is sometimes difficult to tell the difference between "we think this is actually a bad idea" vs "we don't think we have the resources to do that" vs "we can't be bothered with divergent opinions about how things should be done". --Jhamstra 23:19, 7 March 2013 (EST)
It has always struck me as ironic that the same organization that provides access to the largest set of primary sources available, would also have the worst set of family trees online (i.e., the AFNs and PRFs). So the fact that this is based on AFNs is a huge turnoff to me regardless of how easy it is to use. I just looked up a page I worked on WeRelate, where I corrected some errors imported from AFNs, and yep, the errors are still there on Family Tree, just as ridiculous as when the old system was up (died young but shown with a husband, surname of father differs from maiden name of purported daughter, etc.) I can't say how the system will evolve over time. Perhaps a shared tree will be enough to correct the errors made by those who only copy other people's online family trees, I don't know. My sole criteria for using a site is my belief in its reliability, and years ago I gave up even consulting AFNs as a waste of time. It's not that I don't value ease of use, rather that reliability/accuracy is the only criteria that really matters to me. --Jrich 23:34, 7 March 2013 (EST)

I just checked it out and added a few records, the last of which was mergeable with a record they had. When I completed the merge, it only attached the individual, not the parents connected. That I do NOT understand. Jillaine 08:57, 10 March 2013 (EDT)


Others have said it well - too easy to just add random junk, barrier is too low (Yes Virginia, it shouldnt be too simple). I foresee fights when someone tries to remove a relationship for someone's 'royal pedigree'. I also find their interface ugly; WR is much more presentable and easy to read. Thats part of the problem with some of the other sites - they either make entering data too dang easy (how often will people upload New England colonists, causing the duplicate to rack up - a problem here on the early WR) or too difficult (a couple other genealogy websites allow one person to have ownership over people's pages - imagine the headache that would cause here for those of us that clean up old uploads). WR is the perfect balance, and that is why I only contribute here.--Daniel Maxwell 10:18, 10 March 2013 (EDT)


I've spent some time trying to clean up the Morrows that the Morrow DNA projected sorted out, and it's an odd experience. For context, these are extremely screwed up lines of people all named David, Samuel, and Robert - men are their own father, multiple sets of parents, etc. I can delete relationships at will, leaving unconnected people in my wake, but can't delete people that didn't exist. I am prompted at most points to explain "why I think this is correct" - but not for parentage. And other than those boxes (which don't exist for parentage and aren't always visible), there is no facility to add notes or explanations. There is no ability to use alternate information - you always replace what is there - which is particularly problematic when merging guestimates. Adding sources is also a pain and it's not clear to me that anyone else will ever see them (they are basically "mysources", and I can't find any other records, even ones that should be heavily edited, that display sources), so I have stopped bothering and just paste the source into the "why is this true" notes.

There is a facility to add records from an FS search to a tree entry, but it requires about 6 steps and starting with the search, and doesn't easily display the data that's actually in the record. (There's also no page number or other pin cite information generally - each "source" is designed to be a single record in one place, which will make managing these things on a large scale difficult.) But if this is improved - and has a relation back to the added entry like Ancestry does, it could be pretty slick. (example of an edited record if people are curious, since I haven't found others: [1])

Overall, I think there's value in crowd-sourcing the AF given how common the data is, but between the way display and edits function and the inability to describe or discuss evidence, there are clearly going to be edit wars with no good resolution.--Amelia 11:02, 10 March 2013 (EDT)

I remember reading something by one of FS's site devs some time ago that the feature wasnt intended to be an all inclusive family tree of perfection (like we aspire WR to become :)), but rather so that that alot of the old trees can be cleaned up. There used to be alot of grumbling, even in the 90s, that there was no one way to do this before. Some of these trees in their database date back to ones submitted in the 80s (remember the old Broderbund software on Apple II?), and many havent been changed since then, spreading the same errors, some of which were disproved decades ago. Based on this, I think its an attempt, however futile, to clean out some of that. Daniel Maxwell 11:40, 10 March 2013 (EDT)

I went back and cleaned-up the family tree for a few generations around Maj Ebenezer Wilson (a distant ancestor) https://familysearch.org/tree/?icid=fsGlobalNavFamilyTree#view=tree&person=L85D-9XV. I chose this because I knew from previous searches that there were a number of problems there with duplicate and downright erroneous AFNs and linkages between same (not to mention the confusion caused by four consecutive generations of Ebenezer Wilsons). It appears that Family Tree did a machine merge of all of these AFNs and then left it to the users to clean-up the mess. Well I cleaned-up enough of a few generations of Wilsons and also their relationship with the problematic Newtons (three consecutive generations of Isaacs) - I didn't even try to clean-up the Newtons. In any case it was not a pretty exercise. They have made it easy to enter new data but a real pain to clean-up what they have already loaded. Their Duplicate search is horrendous but I think WeRelate could borrow ideas from their Merge interface. --Jhamstra 00:51, 14 March 2013 (EDT)


Support page [18 March 2013]

I recently answered a question on the Support page and noticed something odd. There used to be numerous users watching the page - now there are only 2 (plus myself which I just re-added). I am not sure how the watchers disappeared, but if you are interested in helping to answer questions from other users - please visit the page and click the Watch link. Thanks, --Jennifer (JBS66) 19:52, 17 March 2013 (EDT)

I recently archived many of the older threads - I wonder if that did it? AndrewRT 16:45, 18 March 2013 (EDT)

Deceasedonline additions for London, England [29 March 2013]

Quoted from the blog "Anglo-Celtic Connections" of 28 Mar 2013

"With the addition of another 160,000 records for the period 25th March 1875 to 15th December 1898 the deceasedonline.com database for Manor Park Cemetery, Newham, East London [England] is now complete. In total 430,000 burial and cremation records are now available.--goldenoldie 08:14, 29 March 2013 (EDT)

inviting others to 'watch' my tree [2 December 2013]

I think I remember several years ago that there was a way to invite new members to 'watch' my tree and when they applied certain steps, they would be watching my whole tree. I cannot remember or find the details on how to do that. Can someone refresh our collective memory of this? I surely didn't imagine this. --janiejac 11:27, 31 March 2013 (EDT)

I've not seen such a thing, but it would certainly be useful. I've been tinkering with a little tool for traversing trees here (actual 'linked' trees, not people's 'defined' trees) and it could easily be extended to permit watching each page traversed. I've always figured it's more useful to actually follow the links in a tree, rather than relying on what's been defined as belonging to the tree, because the latter can sometimes miss branches (or include branches from completely unrelated families!). — Sam Wilson ( TalkContribs ) … 20:01, 4 April 2013 (EDT)
There is a way to do this. Go to My Relate>Trees. Then, click the e-mail link on the row of the tree you'd like to share. You can either send the email, or copy/paste the instructions into your own message. --Jennifer (JBS66) 08:54, 6 April 2013 (EDT)
Thank you! That is just what I needed! Sometimes the instructions for these features need to be repeated so that all viewers become aware of this. --janiejac 01:04, 8 April 2013 (EDT)



WeRelate growth [30 May 2013]

I started a discussion previously (see User:AndrewRT/Metrics) about how we could measure the success of WeRelate. Although a very crude measure, I have compliled a graph showing how the total number of pages in the "Person" namespace has expanded which others may find interesting:

Image:WeRelate growth.jpg

AndrewRT 17:45, 6 April 2013 (EDT)

It is interesting. Thanks. --GayelKnott 18:40, 6 April 2013 (EDT)

I too have been keeping track although in a different manner - years to add one million names. For instance, 1 Aug 2012 4.84 years and most recently, 3 Apr 2013 4.90 years.--HLJ411 20:00, 6 April 2013 (EDT)

Both sets of figures indicate a sharp slow down after the "drive by GEDCOMs" were stopped in 2008. Are we happy with the current rate of growth or should we be trying to increase it? If yes, how? AndrewRT 06:54, 7 April 2013 (EDT)
WR did experience a high rate of growth during 2007 - but the quality was horrendous. We've had so many threads here asking Dallan to delete the "junk" imports of various users from that period. It's a common benchmark for users who have been around here for a while - did the user upload their GEDCOM in 2007??? ahhh... that explains the mess... The quality of imports has improved significantly with WR's GEDCOM error detection and Family Match improvements.
One small item that impacts your chart - in March 2010, Dallan adjusted how he tracked the number of pages on the Home Page. He changed from #People and Families to just #People (in this one edit, he reduced the number by 200,000). Another factor is the number of pages people are merging into when they upload their files. The quantity of the pages may not be increasing as sharply as in 2007, but the quality has improved for users to build on. --Jennifer (JBS66) 08:54, 7 April 2013 (EDT)
I don't suggest we go back to the pre-2008 situation (I joined just after those changes were made) given the issues there were. However, I do wonder if there's a way to get the "best of both worlds" - i.e. getting back to those rates of addition but maintaining the quality. I'd also like to develop a metric that incorporated quality (e.g. person pages with at least one date & one source) but that would be hard to back-date. Any thoughts would be appreciated.
Regarding the change from person/family to person - yes I've adjusted for that in my figures. I'll go through the image page and put the full source I've used for each number.
My own experience is that whilst I've found many distant cousins on ancestry.com, which has hundreds of millions of people in their database, I have yet to match a single one on WeRelate. It's different when you're dealing with prominent families (as I've found with my british nobility mini-project, where I regularly match existing pages). I don't believe 2.5m is a big enough number for matching to make a significant different. If you see the rate of increase has actually gone up slightly between 2008 and 2013, despite the site growing by 70%. If matching were a significant factor, it would surely have gone down. AndrewRT 11:00, 7 April 2013 (EDT)
I have to ask - do we really want hundreds of millions of pages? Maintenance is already a problem on WR. To return to the old 'growth' levels, you would have to lower the bar to be similar to Ancestry.com's, who arguably contribute to the problem WR is supposed to solve. But I actually think the turn off for attracting new users is more related to two things (setting aside the learning curve, which should never be lowered) 1) No living people 2) No 'ownership' of pages, with more an emphasis on the first. There was supposed to be a system added to the tree function where living people could be added privately within the program, but not as people on WR itself. I don't think this ever happened. Of course, I never want to see living non-notable pages on WR, but I would like to see the solution that was proposed to happen. The second is a complain I occasionally hear from people who do not want to use WR, but unlike the first I do not sympathize with it - ownership of pages would eventually destroy the site and discourage collaboration. Daniel Maxwell 11:20, 7 April 2013 (EDT)
I have 2 comments to make. First, compiling data of reasonable quality is time-consuming. I only have about 7000 people to contribute to WeRelate, but it is taking me years to validate the info I picked up from a variety of sources. OK - I am also adding citation text as I go, which adds quite a bit of time, but just trying to find reasonable sources (VRs, published books and articles, gravestone inscriptions) to substantiate (and correct) the data that I picked up from other people's personal trees (RootsWeb, Ancestry.com, Pedigree) can take quite some time. It is definitely worth it - I discovered that I picked up quite a bit of garbage along the way, even after I realized that I had to be careful. So, growth based on amateurs like me validating their data before adding it to WeRelate will take time.
Second, I have come across some sizable amateur trees that appear to be quite well-researched. If we could personally invite those authors to submit their trees, or volunteer to submit them on their behalf, it would add a significant number of people. Andrew and I have volunteered to help someone load her tree (about 20,000 individuals). The quality is mixed, and I expect some of the data is incorrect, but it is not a bad starting point for these families. However, the author wanted "clean" place names that match WeRelate place page names, and it is taking me weeks to clean up the approx 7000 place names. So even this can take time (although months, rather than years). After this brief interlude to help load this tree, I want to go back to my own tree, but when I am done with that, I am interested in helping load other higher-quality trees. This type of collaboration in initial loading of data might reduce barriers for those who are overwhelmed with where to start.--DataAnalyst 11:35, 7 April 2013 (EDT)
And by the way, I found that I am distantly related by marriage to the woman whose tree I volunteered to help load (her third cousin 4 times removed married my third cousin 5 times removed)--DataAnalyst 11:40, 7 April 2013 (EDT)
The "best of both worlds" I see nothing good in the old way, just a lot of work.
The quality can not return a millimeter, but up. You can now upload a gedcom with: double persons. Many missing town and missing dates, and above all without sources. It is perhaps time to consider a few things to look seriously. --Lidewij 11:48, 7 April 2013 (EDT)
"do we really want hundreds of millions of pages? Maintenance is already a problem on WR". I certainly don't want unmanageable growth - we need to have growth in a way that is sustainable and maintains quality. But clearly if we had more people contributing information, we would also have more people helping with the maintenance. I do think there are sustantial benefits in having a significantly bigger site. The "pando" model really comes into its own when you have lots of connections between people interested in the same tree. This is simple network theory - the more people who are connected, the more potential connections there can be. I started researching my family tree 20 years ago and after a few years of research had some up with a tree of 250 people. I picked it up again 5 years ago and within a month I was up to 5,000 people, simply by linking into distant cousins who had managed to trace back our common ancestors and had uploaded their data. That happens because ancestry.com has hundreds of millions of people. It doesn't happen to the same extend when you're talking about a site with 2.5m people. AndrewRT 11:53, 7 April 2013 (EDT)
Networking should not be a goal in itself; accurate genealogy should be. Networking will be a natural consequence of growth, even if it may appear slow going. I have already found several just in the course of maintaining New England based pages. Data's point about inviting people with some of the better sourced trees and then helping then import it is a better strategy, as well as my point about fixing the issue with living people, which is BY FAR the biggest complaint people have about WR. Much of what you see on Ancestry.com are duplicates on a massive scale - it is not the best stick to measure WR against. Daniel Maxwell 12:07, 7 April 2013 (EDT)
The topic of helping is a key point in the last few comments. Whether it's helping other users import their GEDCOM, helping with site maintenance, or helping with software development - the community of WeRelate needs help to succeed. Essential to WR's growth is a strong base of organized volunteers, help pages that are streamlined and coherent, and mentors that can help new users. What can we do to increase the number of active volunteers? How can we create a firm foundation upon which increased growth will be solid rather than unstable? --Jennifer (JBS66) 12:40, 7 April 2013 (EDT)
'Evangelization' of WR to other researchers who care about good information is key to this, I think. Data has the right idea. Daniel Maxwell 12:50, 7 April 2013 (EDT)
I've been pondering the idea of going along to one of the genealogy society meetings near me (WAGS), to see if there's anyone else there using WeRelate and whether we mightn't help each other (sometimes more fun in person). How best might I connect with users here who are nearby though? Some additional subcategories to Category:Users? Userboxen, as they have on Wikipedia? — Sam Wilson ( TalkContribs ) … 02:25, 8 April 2013 (EDT)
Judy and I have been teaching genealogy classes & seminars and giving talks to local societies and at conferences for years. We discovered WeRelate shortly before its first birthday and joined up, and within a year we were proselytizing to local groups with "demo" programs. Local researchers are always interested in new ways to do what they do -- and the program chairmen of local groups are always looking for speakers. Make a list of all the societies within a couple hours' drive and get in touch with them. Also, our local public library sponsors genealogy workshops every year and we've done our stand-up routine there, too. Check with the nearest library that has a sizable genealogy collection, especially if they already have an arrangement with a society for volunteers and such. --MikeTalk 08:05, 30 May 2013 (EDT)
I have a draft article about WeRelate I'm writing for the Orkney FHS - would be great if there was somewhere on here we could share stuff like this and get inspiration from what others have done. AndrewRT 17:37, 8 April 2013 (EDT)

The curve certainly shows what you would expect when you go from a period of zero controls on upload to a more strict regime. It's also positive that the curve doesn't go completely flat in the aftermath. We don't have measurements to tell us that the per-page quality is moving up, but I certainly believe it is.

What I would have expected to see, is evidence of acceleration in the aftermath of the flattening episode. As our data set grows larger, gets better, and turns up on more and more searches (the Alexa data suggest that much at least) - I would expect increasing visibility to turn into increasing participation, new users, more Person pages, etc. Disturbingly, that does not seem to be happening.

The near-linear curve post controls suggests a static size core group - or at least - a static rate of new Person creation. Against a context of more and more people seeing us, that unfortunately means that the percentage of those who eventually choose to join is probably dropping.

Maybe the drop-off in acceptance isn't cause for concern. At some level, it's not the system, it's the data. The database is still free and can never be sold. If thought of as a 2.5M person GEDCOM, it's probably good enough that another effort - with appropriate open licensing - would be able to request (and obtain) the complete set of content as their starting point. If that other system has better usability factors, it will naturally become WeRelate's successor. WeRelate will drift into the sunset - having served its purpose. The data doesn't die, but software does have a life cycle.

I'm a little more optimistic than this might suggest - but we need some fresh ideas.

In the near term - could we start by losing our front-page exciting "News" from August of 2012? Something that tired, sends the wrong message. While the enclosed statement about "time to grow" might now qualify as dark humor, it's probably not a subject you want to lead with. If genuine expectations were behind that remark - well - oh dear.... --jrm03063 21:44, 17 April 2013 (EDT)


ancestry has about 2,500mill persons records at the moment. Theres obviously duplicates and just plain trash. Thre is also a large amount of seriously good genaalogy in there simply because itas so easy to link people to records and have sourcing done for you. When i look for serious connections for people i go to the records where you can see exactly which ancestry users have linked to sources. Their work is by definition more reliable, and less likely to be a copy of someone elses work. I'd love to know the figures of what proportion of census records have been linked for example but i would guess its certainly above half, but probably not more than 80%

Werelate is similar in that its north america europe centric, and most americans have european roots. Werelate excludes living people which means up to 1000 million of all possible records cannot be put in as it stands now. Perhaps the theoretical number of north americans and europeans who have lived, died and had records is somewhere approaching another 1000 million. Certainly not more.

If i had a guess at the number of duplicates in ancestry as 40%, they have 1500 million distinct people records, and 500 million are of good quality.

Therefore ancestry, if it was aiming for pando as good as it could be, they are a quarter of the way there.

But you would be correct to point out that you cant tell which are the good records and which are not--Dsrodgers34 02:03, 18 April 2013 (EDT)

There is good genealogy in lots of places if you are willing to do the work to document it yourself. The difference will hopefully be that someday most of WeRelate will be documented, making it obvious what is good genealogy and what is not. The above estimates of ancestry quality are way too high based on pages I have worked with (colonial era in New England). Reliability, meaning documented, verifiable sources, is what will differentiate WeRelate, since it can never hope to compete on sheer numbers.
There are competing forces that mean any assumption that page add is proportional to users is probably incorrect. Notably, the easy people are already added, and to add a truly new person, fewer generations need to be added to connect him to some other page. In 2008, it was not uncommon to find none of a family entered, and one might need to enter 5 or 6 generations in order to connect a newly added person to an existing page. Now, adding similar pages, it seems rare to have to add more than one or two generations to connect somebody to an existing page.
Of course, that is not to say all people have been added. And even for pages that have been, they are not complete, all correct, nor fully sourced. The importance of this work must not be ignored by only counting page adds.
It would certainly be encouraging to many people to see some progress towards leaving "Beta". --Jrich 11:53, 18 April 2013 (EDT)

Solution : Other languages ! French, german, ... Amicalement - Marc ROUSSEL - --Markus3 12:29, 18 April 2013 (EDT)

I'm not aware that we preclude use of other languages for any purpose, but there's an obvious bias given where the initial world of contributors came from. I wonder if we could do something cute with respect to the 97,000 or so pages we currently source from WP. I wonder if there's a way for a user to specify a preferred language - such that a page inclusion for a person or place - would display in the user's preferred language (assuming that there was a version of that page, written in the user's preferred language)? Likewise a simple internationalization effort on the code, such that any stock label text is chosen from an appropriate language dictionary. I don't think we would want to create different language versions of the entire database - even though the approach is consistent w/WP. --jrm03063 14:44, 18 April 2013 (EDT)
I mean not a specific database for each language ! Only one database for genealogical informations. We need to translate the messages/titles ... Displaying in the user's preferred language is possible with Mediawiki. See this page. Between june 2008 and april 2011, I "worked" on Rodovid ... same tool ! Excuse my very bad english ! Amicalement - Marc ROUSSEL - --Markus3 15:10, 18 April 2013 (EDT)
Duplicating the database would be a bad idea - but that's the way that WP does it - so one does need to take notice. I'm all for internationalization, and certainly for using any support that's built in to accomplish it. Presumably, Special:Allmessages this page will look familiar. --jrm03063 16:35, 18 April 2013 (EDT)
Wikipedias in different languages are not duplicates of one another. Each is composed of either original articles composed in the language or articles which have been manually translated from one language into another. This is why most of the language-pedias have small numbers of articles. It's also worth to note that the content can differ dramatically for an article in one language versus another; there are few controls on the specific content for articles on the same topic across languages. --ceyockey 20:26, 18 April 2013 (EDT)
I get that - "duplicate" was an overbroad term. I understand that the different language-pedias have articles with their own history - sometimes even their own separate conclusions. By duplicate, I mean duplicate software, presumably the same save for internationalization. --jrm03063 22:18, 18 April 2013 (EDT)

Jrich i can accept my guesses are too high. I was more interested in the size of 'pando' for werelate purposes, and used ancestry figures to make a guess. I,d love to see some internal ancestry figures, particualrly the percentage of the various database records which have been linked. Has anyone found these anywhere ?--Dsrodgers34 00:00, 19 April 2013 (EDT)


Just as a matter of interest, has anyone contemplated the task were a group to systematically resolve all major source databases into the mythical 'pando' ?

A bit like we all seem to be doing with our chosen local areas - well some of us anyway--Dsrodgers34 00:03, 19 April 2013 (EDT)


As an example i have been attempting it with three parishes in england which translates to about 20,000 persons with about 45,000 sources so far. Ancestry tels me i still have 17,000 hints unseen ( half of them will be wrong) and im still working my way through the PRs. I have been at it for four years and still seem to be only half way through. I doubt i will add more than a couple of thousand more persons though. Youd have to have some kind of bots to resolve obvious ones and have humans decipher the complicated ones, to speed up the process--Dsrodgers34 00:11, 19 April 2013 (EDT)

Picking out databases to trust could be a problem. It's also an approach more apt to run afoul of copyright restrictions. "Bots" could be useful for identifying possible duplicates - but I don't think you would want automatic resolution. My interest is in trying to bring in various sources - which can then be systematically resolved against our existing database. It makes genealogy more like double-entry book-keeping. --jrm03063 13:42, 19 April 2013 (EDT)

Picking up on what jrm03063 said above about other projects using WeRelate data, I think this is an important step. I don't mean another project taking over, but rather the idea of making it easier to reuse data from here; of WeRelate becoming a central database (the "wikipedia of genealogy websites"; i.e. the go-to place). I absolutely love the idea of WeRelate.org being the central repository, off which can be built any number of things. This could mean that we include more "raw data", e.g. cemetery inscriptions, BMD indicies (intellectual property issues aside), so that the working-out can all be recorded here and sourced properly etc. I quite agree about it not being an automatic process — that's how the other big sites do it, and they get to be full of lots of wrong data.

I've been doing a bit of work on backing up my data from here, and it's not straightforward (the most tricky bit is probably retrieving the list of contributors for any given bit of content). It'll get better as the software here improves.

Sam Wilson ( TalkContribs ) … 20:42, 21 April 2013 (EDT)


GEDCOM upload questions [30 May 2013]

I have a file that is the result of a study done on all the Jacksons in two cemeteries in what is now Nassau County, New York. This file is a bit different from the typical descendants file as many of these Jacksons are not necessarily related. I've capitalized the surnames of those actually buried in the cemetery (as opposed to their descendants found in census records). So will these unrelated-ness issues cause a problem if or when I try to upload a GEDCOM to WeRelate? Will the capitalization stay or be converted to mixed case?

This was started as a hope of connecting some of these folks who were all living in the same general area and all buried in the same cemetery. It was a fun project that overflowed to a second cemetery! By posting this to WR perhaps I'll find more connections. --janiejac 21:40, 16 April 2013 (EDT)

The capitalisation will be preserved, I believe, but long-term should be converted to proper casing. The goal is to be able to determine which of these people are buried in a particular cemetery, isn't it? I'm not sure that there are well-developed guidelines about how to do this (I've not seen anything), but perhaps simply using the category system for this would work? E.g. [[Category:Buried in <Cemetery Name>]] Hmm... although, that is rather double-entering the data isn't it? But without changing the software I don't think it's possible to do this sort of categorisation automatically. — Sam Wilson ( TalkContribs ) … 22:51, 16 April 2013 (EDT)
I agree that capitalization is not the right way to maintain this relationship. It's too opaque of a signal - no one else will know that's the reason you've left the names in all caps. If you add a Burial event to each of these people, and link it to the cemetery, then you could go to the "What links here" page for that cemetery, and see everyone buried there (e.g., this page). I agree that a category would also work, but what would be the reason for having a list of people with the same surname buried in the same cemetery? -- Jdfoote1 09:05, 17 April 2013 (EDT)
In my ongoing "Red River Project," I've created MySources for dozens of cemeteries in the county, and I cite those on the Person pages. Which means, as you say, that clicking "What links here" on the MySource page gives a list of all those buried there for whom you have created pages. I often use it as a sort of checklist to see if I've omitted someone. --MikeTalk 08:17, 30 May 2013 (EDT)
I realize now that my purpose for capitalizing some names was only for my own reasons and won't be needed at WR because the folks who have burial information will be matched to the cemetery. So I can create a new file with the names mixed case for uploading and that leaves only the question that there are a lot of folks not connected in a line of descent. I think the system can handle that.
--janiejac 14:50, 17 April 2013 (EDT)

Do you have uploads pending ? How much ? When ? [23 April 2013]

In the light of the recent growth discussion I thought it might be useful to take a quick survey to see if people have projects pending which are intended to be uploaded to WeRelate. So if you have do add a few notes

For myself my initial upload was for the parish of Holme in West Yorkshire, england. The original upload was just under 4000 people with about 7500 sources, mainly 1841 to 1901 census. I then realised the parish church served three parishes so when I started resolving parish records ( which are now all on ancestry) i added these parishes, cartworth and austonley, census and all.

Im still a couple of years away from loading into WeRelate, i find it more straight forward to resolve in my ancestry tree, but when i am ready there might be about 22,000 people with 55,000 or so links to sources. Of course 4000 will overlap with the tree i uploaded before, and perhaps other peoples contributions. If its another two years before i do this it will hace taken six years--Dsrodgers34 04:55, 22 April 2013 (EDT)

I have uploaded my own ancestry (largely complete), a surname project around my mother's maiden name (information largely 'built' on ancestry but then uploaded here) and a British nobility mini-project (entered directly here). I'm comfortable adding research directly to werelate as it is built, although do find it easier sometimes to do this on ancestry first, link in their census source information and information from other trees and then transfer it to werelate. Ideally I would like to be able to build a tree directly here - perhaps using information on FreeBMD/FreeREG/FamilySearch. AndrewRT 14:59, 23 April 2013 (EDT)

Idea for a source / transcript [30 May 2013]

Not sure about the rest of the world, but I know that many US States take the time and trouble to create markers for events of historical significance. I've seen a few used here on WeRelate (for example, Ninth Texas Cavalry). Being the work of the state, the narratives can't be subject to private copyright. I presume that they can safely be reproduced verbatim, with only the usual academic requirement of indicating where the quote was found. Perhaps, if you are lucky, your state will even have a site with discrete pages/headers for each marker, providing additional supporting research.

These markers often contain useful information about individuals. For example, the marker above relates to Micajah Bankston, which presumably is the reason that it was added.

If you live in a state, and love it's history, maybe you'ld like to create a complete transcript of the historic markers present in your state? While this is apt to be only supporting secondary-source information for well known people, it seems like it would add some nice color to Person pages that otherwise lack images or context. Grabbing a casual reader and getting them more intrigued or involved can only help us.

Anyway - it's an idea...

--jrm03063 10:53, 22 April 2013 (EDT)

In the case of Texas, the Texas Historical Commission's website has a list of all historical markers in the state -- including the text that appears on them. I haven't searched, but I suspect some other states have similar databases. --MikeTalk 08:26, 30 May 2013 (EDT)

Great idea, I reckon! Have you heard about the Open Plaques project? Perhaps we could integrate with that somehow. Or not, of course; it's not a complicated idea.

Would we create a separate source for each marker? With a separate transcript page and image? Seems the easiest way to then be able to cite individual ones appropriately...

Sam Wilson ( TalkContribs ) … 22:11, 22 April 2013 (EDT)

Actually, I'm afraid I hadn't heard of that one, but the principles would probably be the same. My first thought was markers such as these. Doing the markers for a single state of interest, might be a lot more tractable, than something more extensive. For the case of the NH markers - I would expect to do a single source for the entire state - but I would also expect to create a transcript that had a single page per marker. The source page would get an extract from the WP page above, as well as indicate any State of NH web pages that provide further information. There would also be an entry that pointed to a top-level page for the WeRelate-based page transcripts. Individual transcript pages could be tagged with GIS numbers and/or a map, and indicate the highway markers of NH as their source. By breaking out the markers on a per-page basis, you can look go to referenced Person pages, then hit the "what links here" to get particulars for a cite. Pictures could be added of course, provided that someone felt they could take them or if they're available on fair use terms.
Not sure how brilliant an idea it is - but it's the sort of thing that someone with an interest could add - and that would benefit a group wider than normal. --jrm03063 00:23, 23 April 2013 (EDT)
One more thing - if someone really was interested - perhaps there's a really outstanding project to be done based on [[2]]. They seem to have searchable databases as well as GIS numbers and such. The US National Register also indicates whether a place was added based on a criterion, and criterion "C" is a person. It's a thought... --jrm03063 00:33, 23 April 2013 (EDT)

L O N G Wait [30 May 2013]

Do we really think folks are going to stick around when it takes this long to get a reviewed GEDCOM approved? I really wanted this to work but I feel like the system is broken. I guess I need to find something else to do.--janiejac 23:39, 1 May 2013 (EDT)

Is there something I can do to help? Please let me know... --jrm03063 09:24, 2 May 2013 (EDT)
Late Monday afternoon I finished reviewing the GEDCOM I had uploaded. I hit the import button and received the msg: "An administrator will review your GEDCOM shortly and finalize the import or contact you with any questions." Now it is three days later and the GEDCOM has still not be finalized or accepted. I feel like this is much too long to wait. By then folks, including me, have moved on to something else. If we want folks to stick around and review the new pages their GEDCOM generates, they/we need to be able to do it while the review is fresh in the mind. If there are not enough volunteers available to do this; then the site has a major problem :( --janiejac 11:49, 2 May 2013 (EDT)
I've never participated with that group or in that process. I just went to the appropriate tab, and I find some 18 GEDCOMs (apparently) pending review, but I'm not seeing one owned by you....does it have a name? --jrm03063 15:15, 2 May 2013 (EDT)
Someone apparently heard my plea. The GEDCOM has been finalized by WeRelate agent 13:19, 2 May 2013. I have no idea why it took so long. Thanks for your concern. I wasn't even aware there was a tab to go look at what's waiting. But knowing that wouldn't have helped since I'm not an admin and so couldn't have completed the process. I'm still of the opinion that this type of delay is a major put-off. . . Perhaps others don't mind. --janiejac 16:09, 2 May 2013 (EDT)
I'm not entirely sure you could see it, since it's on the "Admin" options... --jrm03063 17:03, 2 May 2013 (EDT)
Yes, non-sysop/admins can see the list of pending GEDCOms; the "Admin" menu is present for us and the "GEDCOM review" menu item on it does work. --Robert.shaw 14:24, 4 May 2013 (EDT)

Maybe, administrators in charge of GEDCOM approval should let the WeRelate community know that they are on holiday? Or a template message sent to GEDCOM uploaders to say there will be an unforeseen delay? --goldenoldie 16:56, 3 May 2013 (EDT)

An additional follow-up, I tend to agree that GEDCOM upload shouldn't be gated like this. This would be fine if there were lots of people ready to step up and perform the needed reviews, but I only see three admins that have signed up to do this. I've always been a supporter of a scheme where the size of GEDCOM you could upload would be a function of the number of hand edits you've performed. That admin involvement would only be needed if you wanted to upload more than your allowed GEDCOM size - or perhaps - if you wanted to perform an upload in spite if it having more than some threshold level of errors. Small GEDCOMs without many errors should be allowed without assistance. --jrm03063 17:09, 2 May 2013 (EDT)

For information the backlog page can be seen here. Is it worth putting a link to it on one of the GEDCOM notification templates? AndrewRT 17:50, 30 May 2013 (EDT)


Speaking of Volunteers [5 May 2013]

Does WeRelate have a policy about or materials that can be used in displays at local genealogy confereneces? I'll be giving a talk at our local conference this fall (with examples of "good genealogy" from WeRelate), but there is also a display hall, and I could ask for a table if there is something I could use to promote WeRelate. --GayelKnott 14:52, 3 May 2013 (EDT)

Hi Gayel, would you mind leaving a message on the Publicity talk page regarding this? Dallan has more information about available materials and we want to keep publicity related discussions in a central place. Thanks! --Jennifer (JBS66) 12:20, 5 May 2013 (EDT)

In Search of Madame Ihrig [7 May 2013]

I wrote a blog post about how I searched for one person - Hattie Chapin AKA Madame Ihrig - it's sort of an anatomy of a genealogy search. I list WeRelate at the bottom as the place I use to organize my information.

In Search of Madame Ihrig

I see that WeRelate has a new publicity project so I think I will try to compile people who are blogging about WeRelate. So let me know if you know about anyone.

Catherine dee Auvil : ) --cthrnvl 16:24, 5 May 2013 (EDT)

Interesting post! :-) I was wondering about Werelate bloggers the other day too. I'd love there to be a 'planet werelate' where they're all aggregated. Is there a page anywhere here for listing these things? (Not to confuse people searching for Blogs of course!) I sometimes blog about WeRelate:Printable-WeRelate and genealogy at http://samwilson.id.au/tag/genealogy/ — usually from a coding perspective. — Sam Wilson ( TalkContribs ) … 20:20, 5 May 2013 (EDT)

I will make a special page for bloggers at WeRelate and link to it at the publicity project. Thanks for the positive feedback : ) Catherine --cthrnvl 23:23, 6 May 2013 (EDT)


Maintenance pages' navigation bar? [7 May 2013]

Just wondering about adding a navigation right-side bar to all pages in the Maintenance portal. Something like {{Maintenance navigation}}. (But of course, not adding it to the portal page itself.) — Sam Wilson ( TalkContribs ) … 21:58, 5 May 2013 (EDT)

I really like this, nice job! I hadn't realized how much the pages needed navigation until seeing your example. You are more than welcome to add the template to the other Maintenance pages. Thank you for creating this! --Jennifer (JBS66) 07:21, 6 May 2013 (EDT)
Okay, done. :) — Sam Wilson ( TalkContribs ) … 00:43, 7 May 2013 (EDT)

Categories [6 mei 2013]

I understand the category name and surname location not match, the bottom of the page, but they are also as hidden category no longer made​​? So a new person Person: Magdalena van Beeck Calkoen (1) is not automatically added to

When this feature is no longer there, also there will be no more Surname: .... because Surname: Van Beeck Calkoen has no function.
Also Category: Surnames in the Netherlands and Category: Surname in place loses its function A red link was perhaps not beautiful, but it did have all his function and was using.
Search is a tragedy for me and probably not just for me. I often used it, it gave me too many useless / confusing information. (I used the advance continuously in the categories to come) The categories of information brought sorted / arranged together.
In the old search function FamilySearch did not much excess ballast.
Like reaction. --Lidewij 04:11, 6 May 2013 (EDT)

PS.If you want to have surnames in a category you must create them yourself. Now these are not automatically in a category, but over time, the categories created automatically disappeared. --Lidewij 09:04, 6 May 2013 (EDT)

Why have surname categories disappeared? [13 May 2013]

Why have surname categories disappeared from person pages and family pages? I have found them very useful and I have not found any discussion about removing them. What is going on? --Susan Irish 12:10, 6 May 2013 (EDT)

Over the last couple of years, Dallan has suggested removing the automatically-generated Surname and Surname-in-place categories. In February there was also a discussion here on the Watercooler about some of the problems WeRelate has been experiencing with these automatic categories. Some of these issues include: they caused confusion for many users, they were only generated at the Country level outside the United States, they required administrative time for their organization/development/management, they could not be edited, and users have complained about how they were sorted. Overall, Dallan believed their function could be better served by the current (or improved) search features.
The Overview Committee discussed this more in depth and decided the automatic categories should be removed. I did not have the details about exactly when or how that change would take place until yesterday. The first step is that Dallan has removed the automatically-created links on the bottom of pages. The next step will be to remove the links under Category:Surname and Category:Surnames by country. If anyone has specific examples of how the search function can be improved in light of these changes, please do let me know. --Jennifer (JBS66) 13:13, 6 May 2013 (EDT)
Manually create the categories at people costs, I think, much more time than just making the categories. The advantage is that people can now come in the category by first name.
First we thought it was a problem that links were red. Now there are no links, sorry the surname statements are immediately gone. I found that everyone with the same surname, could be found in the categories one of the strong points of this site. Now I want to first rethink whether I want here further.
With search, you should know what you want. The advantage of categories is that surprises you encounter that you were not looking.
Susan, really consultation has not been there, some have expressed their views. A poll I have not seen.
Susan, if you want to capture something you should do that now. The saved pages can then be used to quickly between people clicking. The categories are now only filled with sources and images. --Lidewij 17:37, 6 May 2013 (EDT)
While I am no fan of Categories, I think that Lidewij raises a valid point - there is no convenient way to browse through WeRelate unless you have a fairly good idea what you are looking for. So Jennifer, I will suggest some enhancements to Search criteria and results:
1) Provide a single Search query to return Persons, Families, Sources and Pictures. Provide check-boxes for each of these categories of results.
2) Provide the ability to filter Search results by kinds of fact, dates of facts, surnames, locations, etc.
3) Provide a convenient way to sort and then browse through the results of a Search.
4) There was talk sometime ago about adding a Faceted Search facility. I strongly endorsed that idea then and I think you need to seriously consider it now.
I still maintain that a better interface for searching and browsing would take most of the steam out of the Categories debate. --Jhamstra 20:23, 6 May 2013 (EDT)
In the discussion last February there were people who said they found the surname categories useful, while many objections seemed to be more theoretical than practical. The argument hat they caused confusion for many users as a reason for their removal would suggest that we also remove the place field for events, since this also clearly causes confusion for users who enter such things as birth dates, cause of death, names of family members, etc. in the place field. The problem of demand on Administrators time would seem to be more valid. I know it's hard to get people to volunteer for routine maintenance, but if more did volunteer, would this help?
I agree with both Lidewij and Jhamstra, the Surname in Place Categories did provide a convenient way to browse. I also agree that there does need to be some way to browse, and the current Search function does not serve this purpose. I tried using person search with just a surname and a birth location, which gives pages and pages which have to be read (with eyes slowly blearing) rather than quickly scanned. And, you can search only for birth and death, not marriage or residence. So the Search function does not serve the same purpose. The problems trying to browse or search for Sources using name and place are even worse.--GayelKnott 02:10, 7 May 2013 (EDT)

"The Overview Committee discussed this more in depth and decided the automatic categories should be removed. I did not have the details about exactly when or how that change would take place until yesterday." --Jennifer (JBS66) 13:13, 6 May 2013

And the rest of us ordinary users knew nothing about the change until Lidewij brought it to our attention yesterday. Is there a place where the decisions of the Overview Committee are announced? Do we get email advices about them? ----goldenoldie 02:53, 7 May 2013 (EDT)


I would like to make a suggestion based on the information provided in this post. I embarked on a personal project to attempt to bring pages upon which I landed, whether accidentally or on purpose, closer to the standards which have already been established on this site. The categories at the bottom of the Family and Person pages helped greatly in this endeavor as they glaringly indicated something was not following the standards and would lead to other pages with the same difficulty which could be remedied. I understand the categories are gone, not to return, but I'm afraid using the search engine provided on this site to do as I've been doing is not as intuitive, nor can I determine if there is a way to improve the search function to allow for this project to continue in the same manner.
Therefore, my suggestion is that the Categories page remain entirely intact to help facilitate finding the problem children. Perhaps it could be renamed or reused for this type of endeavor. If this is not possible, are there suggestions from other users which might accomplish this same project in another way to which I am ignorant?--Khaentlahn 07:46, 7 May 2013 (EDT)

I spent a lot of energy to create categories, because I think it is important. The category has a different effect than search. I'm generally ample time warned that there was no assurance that these categories remained.

When I stay active, I took the family, that my interest, add the full categories. Manually entering a category provides better quality. (The categories can I start entering the gedcom) I also use these categories to see what people are newly added. (compare an old store category pages) I also hope, by categories, to connect with people, who at the same surname search

The category indicates the connection of everything associated with that name. Visitors search for people (surname), not on the page of users. When I want to know, what is a family here present, I always look at the category. Only when I encounter in finding people with the same or similar first and surname, I use the search for a wider picture. In the category I see at a glance more than 40 couples a few cm2, always in the same order. Here I find what I'm looking for quickly. Nothing typing, but a single click. Without that I was looking for I see that there are no sources or pictures with a surname. (sometimes a catch of own ‘familie' foto's). In a single click I see the global spread of a surname

Category:Mol surname the family’s in an orderly row

Familie mol Werelate Search What find a visitor, relevance, page titel ??, date last modified ?? The first three are my work. What comes after it is no Mol

Only when entering a surname, the only concrete
Categories will come, even if they are not created automatically. It will take some time before the backlog is cleared.
Categories provide an opportunity for rapid control and bringing together interested parties in the same surname.
In genealogy everyone works in his own way, with its own goals and find that way of working minded alike. The families are now categorized manually will probably be checked for accuracy.
The gedcom that are bad are no longer up. That did happen during the making of the categories.
--Lidewij 08:53, 7 May 2013 (EDT)



Like others, I don't really use the Categories much, and I don't disagree with the decision to get rid of them. However, I think that this is a good time to rethink the way that the Overview Committee works. The fact that none of us knew that this decision was coming is a problem. I have no problem with having a committee of people generous enough to take their time to think about how to improve WeRelate, but I think that their meetings and decisions need to be more transparent, so that we know what they are talking about, and have time and opportunity to comment on decisions before they are implemented. -- Jdfoote1 08:57, 7 May 2013 (EDT)
Regarding the discusssion in February, I made no comment because I did not object to removing the automated category, the red links. However, I do object to the removal of the manually entered surname categories that I and others have worked countless hours on. So if one manually enters the surname category again will that also be removed? My time is too valuable to be wasted.--Beth 09:06, 7 May 2013 (EDT)
Beth, by manually entered surname categories do you mean pages like Category:Coleman in North Carolina? That category will be empty because none of the 17 pages contain the "Coleman in North Carolina" category any longer. If I do a search for Surname=Coleman Place=North Carolina "Exact match only", I get 17 pages, the same exact pages that appear in the category. If I search for Surname=Coleman Keywords=North Carolina instead, I get 54 pages - more because Coleman appears somewhere on the page where an automatic category would not have been generated for it. These searches show all of the namespaces but can be further filtered to show just Person or Family pages. --Jennifer (JBS66) 09:59, 7 May 2013 (EDT)
Coleman in North Carolina is not empty, there are, among other sources.
I get pages - more Coleman, that should not fall into the category of Coleman in North Carolina, what I saw was a pity about the time of the click and watch. --Lidewij 10:47, 7 May 2013 (EDT)
To me you have thrown out the baby with the bathwater, while I only understood that you were throwing out the bathwater. See Person:Absalom Anderson (2). This page now has no category. However this person is still on the category page Category:Anderson in Mississippi but now there is no link. --Beth 10:32, 7 May 2013 (EDT)
What you see is the cache (temporary memory) when you edit the person or touch it disappeared--Lidewij 10:47, 7 May 2013 (EDT)
That is correct, the pages currently do appear in the category. As I mentioned above "The first step is that Dallan has removed the automatically-created links on the bottom of pages. The next step will be to remove the links under Category:Surname and Category:Surnames by country." The links that appear in the categories now are essentially phantom links. Dallan needs to run another process to refresh the categories. Refreshing the categories will clear out pages that no longer "point" to them (meaning since the pages no longer have categories on them, they would not appear in the category).
Beth, your first comment was that you don't object to removing the automated categories (of which many were red-links) but you do object to removing the categories. Then, I mentioned that you can find the same information from a search. I want to understand better how the data from a category was better for you than the same information in a search? --Jennifer (JBS66) 10:54, 7 May 2013 (EDT)

This shows just how hot this topic is. While I was trying to put exactly what I wanted to say on the editing screen, another posting was made, and what I had carefully thought about disappeared.

Would the Overview Committee now look to editing Help:Categories, removing all reference to Categories: Surnames in Places, and making sense of what remains. Over the past year I have read over the topic a number of times and have always come away feeling that I did not understand.

The word "browse" has been used by a number of contributors to this discussion. We want to look around WeRelate and see what others have contributed. Searching is browsing with blinkers on. Can't we look around for morsels of information that might be an arm's length away (or, in genealogical terms, find a part of a family that was hiding on the other side of the nearest hill)? A month ago I suggested that we consider looking at places first, and surnames afterwards. There are all sorts of ways to spell a surname and one part of a family (or the person who wrote down their name) might adopt a different way than the part we have been looking at. Search engines are dependent on alphabetical characters, not on the sounds of names. To look at a variety of surname spellings within one small geographical area of the world may bring out all sorts of interesting considerations. Believe it or not, literacy for the general populace came earlier for the United States than for other parts of the English-speaking world. Families that did not all migrate together could lose touch and never find each other again. ----goldenoldie 10:40, 7 May 2013 (EDT)

@Goldenoldie, When an edit conflict, is at the bottom of your written text. So it was not gone.
Finding variant names via a Search is much better than through the use of categories. Categories did not take into consideration variant name spellings - search does. You said "Search engines are dependent on alphabetical characters, not on the sounds of names." Dallan has already incorporated the WeRelate:Variant names project into search results, so that when I search for Swart, I also get Zwart, Stewart, Schwart, Zwarts, etc. and I can limit that by a location. If I don't want to look through these variant names, I can choose "exact match only". Perhaps having an option to make the display more compact (ie, a checkbox to hide the husband, wife, marriage/birth date, children information) would be helpful? --Jennifer (JBS66) 11:07, 7 May 2013 (EDT)
I cannot explain why I prefer the category to using the search engine but I do. I do not know why we cannot have both options. I have no objection to removing the automation but as I previously stated I had no idea that the Overview Committee intended to delete countless hours of work by many volunteers. The Anderson link was not red. Anyway you have answered my question. There is no use in me manually reentering the category because it will be deleted. Does the Overview Committee plan on deleting all categories?--Beth 11:17, 7 May 2013 (EDT)
There is too much focus on the search. Search is a conscious action. On wikipedia you search. Yet one uses categories. Categories belong to the wiki. To connect topics together there are the categories on these pages you go leaves. These are useful when you are unable to search.
I assume that the categories that were made and to be made, even when some time will be empty, will stay ??? --Lidewij 11:25, 7 May 2013 (EDT)--Lidewij 14:41, 7 May 2013 (EDT)
No, these categories will not stay. It would not be beneficial to keep some of the categories because they too will be empty once the cache is cleared. All of the categories of the type Surname and Surname in Place, that appear underneath Category:Surnames and Category:Surnames by country will be removed. --Jennifer (JBS66) 07:26, 10 May 2013 (EDT)

---

"Perhaps having an option to make the display more compact (ie, a checkbox to hide the husband, wife, marriage/birth date, children information) would be helpful?" --Jennifer (JBS66) 11:07, 7 May 2013 (EDT)

Compacting the display would help--a default limit of 20 people on a page when there is a possibility of thousands doesn't get one very far very fast. Reducing the number of supplementary facts and placing them to the right would save space as would removing all but the original User. Frankly I did not know that the search engine covered such a wide field. Having started this afternoon putting "Help:Category" in the search box and come up with nothing made me skeptical. ----goldenoldie 11:59, 7 May 2013 (EDT)


"@Goldenoldie, When an edit conflict, is at the bottom of your written text. So it was not gone."

I looked, and didn't find it. ----goldenoldie 11:59, 7 May 2013 (EDT)



I am uncertain what needs to be done with the search function to alleviate the following example, but I bring it to your attention for just that purpose:

Original category that needed some work: Seaver in VT

First individual on the page: Elizabeth Seaver (23)

Initial search for Seaver (using Exact and Close) in Vermont produced 357 people, but I did not find her listed. While there are others in this search that clearly show VT for Vermont, I did not find her. (If that was an oversight on my part, I apologize, but I made a good effort to find her.)

More specific search for Elizabeth Seaver in Vermont produced 21 Elizabeths (or variations thereon) and Elizabeth Seaver (23) was still not listed. I needed to remove Vermont for her name to appear in a list of 385, which included quite a few individuals who were not Elizabeth in any way. Narrowing it by Exact (as opposed to Exact and Close) brought the list down to 70, but then obviously name variants are no longer present. If there is a fairly painless way to repair the original search oversight, that would be fabulous.

Interesting side note, if I attempted to create another page for Elizabeth Seaver with the same basic information, and I used only Vermont as the place of birth, Elizabeth Seaver (23) did not appear, but if I expanded it to Manchester, Bennington, Vermont, United States, she does. I am uncertain why the City/County designation will bring her forward, but not the state. (And, no, I didn't create another page for her. :D) I hope this helps!--Khaentlahn 12:12, 7 May 2013 (EDT)

Addendum: I wish to note that this example is not a singular instance and I'm afraid editing Elizabeth Seaver (23) did not correct a similar issue with other pages which I'm afraid also fail the search engine test. Can we expect the search engine to be modified or will we need to figure out which pages are broken and fix them manually? I'm not vested in either instance, I would simply like to know how to proceed.--Khaentlahn 16:40, 7 May 2013 (EDT)
The reason Elizabeth Seaver (23) could not be found in a search is because the place was not properly formed and was red-linked (the page said Manchester, Bennington County, VT). Since the word Vermont did not appear on the page, you could not find her page by searching for Vermont. You did find her by searching for Manchester, Bennington because those terms did appear on the page. Elizabeth's page has since been edited to correct the place, so you can now find her by searching for Vermont. If the place on her page had been "piped" with an alternate name like Manchester, Bennington, Vermont, United States|Manchester, Bennington County, VT - the place would not be red-linked. In this case, even though VT is shown on the display, Vermont does appear on the page and will be found in search.
The question about how to find red-linked places on pages that need fixing is a good one. I will ask Dallan about ways to accomplish this other than using categories. In the short-term, when cleaning up places like this, I use the What links here page. First, I will see a place that needs fixing (like on this page) and open the red-linked place in another tab. Then, on that incorrect empty place page, I'll click on "What links here". That will display the other pages that refer to that place. I usually fix the Person pages first, refresh the browser view, then fix the remaining Family pages. The reason is that, many times, the error on the Family page will be resolved by fixing the connecting Person page. --Jennifer (JBS66) 07:26, 10 May 2013 (EDT)
I was aware of this situation prior to posting this example and my addendum question, though I am grateful for your description for those who were not. I realized that I did not phrase my question properly to communicate what I was asking. Can the place names that are not piped by the automated system, the ones that maintain broken places, be included in the basic search or will we need to repair these before they will be seen by specific searches? Though that had been what I was attempting to communicate, my brain shoved it a step further. Can the search be modified so that, as an example, when someone is searching for Vermont, the search also displays VT hits? Since the search brings up surname variants, can it not bring up typical place variants? Also, I am aware of how to find the red linked place names without the Categories, I simply wanted to know whether they will need to be fixed before the search engine will show people where they belong or if the search would be modified.
A minor comment on the order of repairing the broken places on Person pages, I would suggest repairing the Family page first only if the broken place name in question is where the marriage took place. For some reason, if the marriage place on the Family page is repaired after the Person page has been changed, though it will appear changed on the Person page's marriage line, the system still seems to connect the Person page to the broken place until the Person page has been opened and saved a second time.--Khaentlahn 09:28, 10 May 2013 (EDT)
Regarding your Vermont/VT question, I think this already happens for the non-red linked places. If I search for Massachusets in the Place field (listed on the Massachusetts page as a common misspelling), it returns MA and Massachusetts pages. The red-links are a different problem. Since they are not linked to a place page, they don't take advantage of the alt-names for that place. I wonder if a report, generated weekly, for pages that contained red-linked places might be useful. --Jennifer (JBS66) 16:26, 12 May 2013 (EDT)
Simply for clarification, are you referring to Special:Wantedpages, which is generated each week? It does not contain strictly Place red links, but that appears to be the main page type listed on it. Or at least something similar to it?--Khaentlahn 07:46, 13 May 2013 (EDT)
Khaentlahn is making an important point -- things can (or could) be found using the Surname in Place categories that likely aren't going to found any other way. Among other things, I found Henk's Groninger Emigranten/1892 article through the Knot in Netherlands category. I would never have found it, otherwise. Similarly, my Scott DNA Family in Georgia, Maryland, and North Carolina article also appears in Surname in Place categories, which gives it at least a minimally better chance of being found, I would hope. Neither Article will appear in a Person search, nor do images. (Nor do Families.)
And yes, if I search All, with Knot for surname and Netherlands for Place, Henk's Article might show up -- in the 21 pages I would have to read through in order to find it. This, I think is part of the point that Lidewij is making. Not likely that I will read through 21 pages just to see what's there. (And Knot is not a common name in the Netherlands -- I shudder to think of how many pages might show up for a common name using All to search.)
It's clear that several people have put time into working with the Category pages, because they find them useful. Being able to condense the results of a Person search would certainly help, but would still not help with other uses people make of the Surname in Place pages.--GayelKnott 23:46, 7 May 2013 (EDT)
Category:Knot in Netherlands is a relatively small category. As it stands, items are sorted by Namespace first, so you would need to overlook all of the F's and P's to find an article of interest to you. Categories become much more unwieldy as they grow, and the likelihood of being able to stumble upon an interesting article is much less likely. For example, you'd need to click (next 200) 26 times to stumble on the Genghis Khan 1853 Voyage to Australia article in the Brown surname category. A search of Surname=Brown Namespace=Article yields 24 specific results. --Jennifer (JBS66) 07:26, 10 May 2013 (EDT)
I agree with Beth - they've thrown out the baby with the bath water. Just because some people don't use categories is no reason to eliminate them from the folks that do use them. I have not seen an announcement that would clearly state the reasons for this change, why it would happen and what would be affected by the change. Are ALL categories eliminated or only those generated automatically? What about the categories that we have manually added to each page? Will they go away too? I'm grieving for the future of this site. --janiejac 10:36, 9 May 2013 (EDT)
No, ALL categories will not be eliminated. The automatically-created Surname and Surname in Place links that appeared at the bottom of pages were removed. Often times, these were red-links and category pages had not been created for them yet. Those that had been created (ie the categories that appear under Category:Surname and Category:Surnames by country) will be removed because they will be empty once the pages are "refreshed". Categories such as Category:U.S. Presidents and Category:Founders of Newport, RI will remain. --Jennifer (JBS66) 08:39, 10 May 2013 (EDT)

I have not read through everything in this thread, but I do perceive that most of the people writing are objecting to the change. I have invested heavily in the creation, revision and application of categories over time (if you look at my contributions, you'll see long stretches of edits with the comment "categorized", for instance). However, I am quite willing to accommodate the present change and give it a chance. Any change of this kind is disruptive, but the value of the end product might be greater than the original state. Consider the deficits in the search vs. categorization -- what changes to search or indexing would improve the search (or presentation of results) so that the result would be _more_ useful than categorization. The first thing that comes to mind is faceting based on country; presently search results are not faceted and introducing even the most minimal faceting would be a great improvement. In other words, let's live with the change and seek to suggest (or implement) changes in remaining aspects of the interface which yield a superior product. --ceyockey 20:43, 9 May 2013 (EDT)

I am befuddged by the reasoning or lack thereof behind this! I am not a programmer and so do not understand why categories have to be removed before we can improve the search function!! Why not improve the search FIRST if you think that will eliminate the need for categories?? Now we have neither! Sounds like this was planned by a committee . . . And by the looks of the suggestion page, Dallan doesn't have time to work on suggestions for search anyway. . .:( --janiejac 10:48, 11 May 2013 (EDT)
I've created a suggestions page for assembling ideas to make search more robust and to enhance the display of search results. For those unfamiliar with faceted search, I want to provide an example of this idea in action. Let's say that I'm searching for an area rug for my home and I look at the Kohl's website. On the left, there are filters with numbers in parentheses. I can filter the results in these ways. I want a 4'x6' rug so I click that box and the results are filtered. Then, I can say I want an orange rug, and the results are further refined. Maybe those are not enough options for me, so I can unclick the 4'x6' and just see the orange rugs. --Jennifer (JBS66) 07:26, 10 May 2013 (EDT)
First we throw overboard the automatically created categories and then we think if we can make a good search system.
Understand an English text through the google translation is a crime, search the genealogy through the furnishing of a house is even worse. --Lidewij 10:44, 10 May 2013 (EDT)

Faceting which is relevant to genealogists (to assuage complaints raised by the home furnishings example): go to http://search.ancestry.com/search/ and do a search. Look at the left hand panel. All those links like "Military" are facets; and under "Military" there is, for instance, "Casualities" - another facet. For the place-oriented categories, replace this with a continent/country/subdivision facet set. We already have some faceting; do a search via the open box on the front page of this site - voila, on the left are facets covering the different page types used here. --ceyockey 17:41, 10 May 2013 (EDT)


Dallan will be implementing a new option for condensed search view tomorrow. There will be a new Search checkbox, next to the results per page drop-down. Selecting this box when running a search will display only page links (with full names as they appear in current search results). Other information such as who is watching the page, when it was modified, birth/death information, etc will not be displayed. Also, the default number of results will be 200 for this condensed view.

Lidewij left a suggestion regarding the use of wildcards. As a side-note to that, I wanted to say that wildcards currently work in the Given name and Surname fields. So, if I search for Jon*, I get pages for Jonathan, Jonas, Jon, etc. The * takes the place of multiple letters and ? takes the place of one letter. There must be at least 3 letters before a wildcard. --Jennifer (JBS66) 18:52, 12 May 2013 (EDT)


Category:Surname and Category:Surnames by country [11 mei 2013]

I assume that the categories that were made and to be made, even when some time will be empty, will stay ??? --Lidewij 11:25, 7 May 2013 (EDT)--Lidewij 14:41, 7 May 2013 (EDT)

No, these categories will not stay. It would not be beneficial to keep some of the categories because they too will be empty once the cache is cleared. All of the categories of the type Surname and Surname in Place, that appear underneath Category:Surnames and Category:Surnames by country will be removed. --Jennifer (JBS66) 07:26, 10 May 2013 (EDT)

I have the situation since May 7 as viewed.

  • Category: Surname XXX will never be empty. This is filled with Surname: XXX, sources Surname: XXX and User: xxx'.
  • Most Category: Surnames country are not empty, they are filled with sources, image/photos and user names. Furthermore all kinds of other things that came up users.
    Some category will be empty for a moment but will still be needed within a few years. It would be a big mistake to temporarily remove these handmade categories. --Lidewij 10:30, 10 May 2013 (EDT)
These categories will be empty and thus removed. The Surname and Surname in Place links no longer appear on Source, Image, or User pages so what you are seeing are cached versions. --Jennifer (JBS66) 12:48, 10 May 2013 (EDT)
I had not seen that the sources were also without category. How unhandy can you make? I understand that the images are no longer linked. What a breakdown? Remains user and surname? There is not much left of what I found here good quality for a genealogy site.
Category:Andersson surname Surname:Andersson --Lidewij 13:25, 10 May 2013 (EDT)
Lidewij, I do realize that you are frustrated. There are multiple stages to this process, and I can only assume Dallan has not yet had time to remove the categories from Surname pages. In the event it was an oversight on his part, I will remind him that these too will need to be removed. --Jennifer (JBS66) 13:37, 10 May 2013 (EDT)
Is not productive! Productive I was many, many hours. (>10.000 cats. Now all turns to nothing) I understood that only the categories under the people might not materialize. (That might be better manually, in an additional category) But because these are very useful also for the sources, I see the point. Especially with the sources it is useful to see this at a glance.--Lidewij 14:01, 10 May 2013 (EDT)
Better turned in half, then completely lost.

The categories were removed under the pages because there was not enough interest to make the red link. Yet there are > 20,000 categories created by some people in a year. There are not many red categories with more than 100 items. When there is not enough interest is to make the simple categories, what do you expect for making the places. At the next step, also places no more linked? --Lidewij 16:24, 10 May 2013 (EDT)

When the sources are not categorized by the surname, these rarely or not found / seen /used. --Lidewij 09:54, 11 May 2013 (EDT)


News on the main page of the site - needs an update [30 May 2013]

Hello -- I think that the current news item on the main page should be replaced with a news item related to the elimination of auto-created categories and the availability of a suggestions page for enhancing other features of the site to overcome perceived and actual functionality that this elimination has and will lead to. Thanks for considering this. --ceyockey 20:44, 15 May 2013 (EDT)

Yes please! Is there a sandbox where non-admins can mock up Main Page changes? AndrewRT 17:41, 30 May 2013 (EDT)

Search Update [30 May 2013]

How often does the search update? Basically, when a change is made, roughly how soon before it will show up changed in the search?--Khaentlahn 09:28, 16 May 2013 (EDT)

It shows up immediately in the "unindexed" section. in my personal experience it's in the main index within days (although someone else may be able to provide a more precise answer) AndrewRT 17:40, 30 May 2013 (EDT)

New Browse Feature [30 May 2013]

Just saw a new "Browse" function under the "Watchers" on one of my pages -- very nice, and many thanks. I'm assuming it will eventually show up on other person and family pages as well. This should serve the needs of those people who like to browse, and looks much nicer than the old Name in Place Categories on the bottom of the page. Again, thanks. --GayelKnott 09:57, 16 May 2013 (EDT)

Did some exploring and found a useful source. Very nice.--GayelKnott 10:31, 16 May 2013 (EDT)
So this new Browse feature is a good idea (if I say so myself 8-). But it is rather flaky in its current form. For example if I go to [3] then I see Browse but if I go to the same Person without the diff [4] after I did a minor edit then the Browse feature evaporates? Also I would place it above Watchers rather than beneath. Still - this is real progress!--Jhamstra 15:55, 16 May 2013 (EDT)
This seems to be a very interesting bug? When first I click on a different page from any URL the Browse feature seems to appear. BUT - whenever I go back to the same page in the same session (via URL, browser Back Arrow, etc) the Browse magically disappears? I have tried this now with several different Person and Family pages with pretty consistent results. Dallan - you might want to look into this? Maybe some inconsistency between the cache and the underlying database? or ? --Jhamstra 16:09, 16 May 2013 (EDT)
I agree, very nice feature. Decidedly faster than invoking the Search page (which is slow on my computer) and using the "compact results" option. A bit frustrating when the Browse tool is not present or disappears from the sidebar. --Robert.shaw 16:30, 16 May 2013 (EDT)
Could someone perhaps do a write up explaining how the new feature work and possibly put a link to it from the "News" section on the Main Page (which is now rather old!). AndrewRT

Time for a new logo? [7 July 2013]

I mean no disrespect to whoever came up with the current WeRelate logo (heaven knows that I couldn't do any better), but I'm wondering if it's time for a new logo? I think it looks a little dated, not to metion that it's difficult to see what it has to do with "WeRelate" or genealogy or wikis, etc. I don't really have any brilliant ideas for a replacement, but I just wanted to get the conversations started. -- Jdfoote1 15:39, 14 June 2013 (EDT)

I agree the logo could use changing. The "falling pawns" image never made sense to me, and seemed unrelated to WeRelate. --Robert.shaw 16:25, 14 June 2013 (EDT)
Before anyone goes too far down the line on this it would be useful to know what the opinions of Dallan and the other oversight committee members are? AndrewRT 18:01, 15 June 2013 (EDT)
I and the other members of the oversight committee would welcome a new logo. Would someone be willing to design one? Perhaps a few logo proposals could be posted and we could vote on them here?--Dallan 21:51, 17 June 2013 (EDT)
Wonderful - I'd be happy to put together a page where people could upload their designs, if there are no objections? -- Jdfoote1 14:24, 18 June 2013 (EDT)
Thanks for replying Dallan - Jdfoote, Yes please! AndrewRT 18:03, 21 June 2013 (EDT)

GEDCOM production [26 June 2013]

In general experience, are there family tree programs which produce GEDCOMs with surnames which are all capped automatically or does this tend to be a user preference?--Khaentlahn 09:00, 16 June 2013 (EDT)


I think capped surnames used to be a default option in Legacy. But this has changed and now a warning pops up when a user first types one in.

Some family history societies prefer queries and trees for archiving to be set up that way. --Goldenoldie 02:09, 17 June 2013 (EDT)

Does the current GEDCOM upload process do anything to convert capitalised surnames? If not, is this something that could/should be developed? AndrewRT 18:05, 21 June 2013 (EDT)
The current upload process does nothing to convert capitalized surnames. If something like this could be implemented, that would be absolutely fabulous.--Khaentlahn 17:31, 26 June 2013 (EDT)

Overview meeting agendas posted [26 June 2013]

Overview committee meeting agendas will be posted as sub-pages of WeRelate:Overview committee. I just posted the May meeting agenda; in the future they'll be posted in advance of the meeting.--Dallan 23:33, 17 June 2013 (EDT)

Thanks Dallan - have you agreed the date for the next meeting yet? Do you have any kind of schedule or frequency in mind? AndrewRT 18:06, 21 June 2013 (EDT)
Seen this on the page now - thanks. AndrewRT 17:26, 26 June 2013 (EDT)

'in the news' [7 July 2013]

I would like to float the idea of having an "in the news" section on the Main Page. This seems to work fairly well on Wikipedia - the section is one of the most popular sections on their Main Page and gets quite a lot of traffic. The kinds of things that we might include could be:

Would this be a useful addition to the Main Page? AndrewRT 18:39, 21 June 2013 (EDT)

I think it's a great idea. Here's another idea for the Main Page - what about something like "Notable Anniversaries", where we list people whose birth/death/marriage dates were 100/200/300 years ago that week? -- Jdfoote1 07:21, 22 June 2013 (EDT)
You may want to bring this up to the committee that selects featured pages: WeRelate:Selecting featured pages. Perhaps they could alternate?--Dallan 22:14, 7 July 2013 (EDT)



Upload New Logo Ideas [24 June 2013]

I've created a page at Logo Suggestions for providing a place to display and discuss new logo ideas. Please upload any ideas to that page, and we can have a discussion about what direction to go for a new logo. -- Jdfoote1 20:28, 23 June 2013 (EDT)


WeRelate Standards [29 June 2013]

Has anyone put together a single page of all the various standards to which we hold WeRelate pages accountable? A quick reference page, if you will. Something which links to the various discussions for how those standards were derived without going into great detail on the quick reference page itself?--Khaentlahn 17:43, 26 June 2013 (EDT)


I think this could be useful. AndrewRT 13:24, 28 June 2013 (EDT)
I am very cynical about this issue. Personally, I have participated in some attempts to do this, but they have gone nowhere. (Example: Help:Style guide and its talk page, ). Undoubtedly, there are other attempts as well since I don't participate in many help pages, such discussions often being unproductive. Despite some specific cases where the rules seem clear, people (even admins) still do what they want, and new users don't bother taking the time to learn how this website works before using it. So why bother making even more rules? Rules without enforcement is pointless. There are several problems that make this hard. One is the lack of a clear decision process, so deciding which help page is a standard, and which is simply the author's opinion, is hard. (Personal opinion: Help should be a protected namespace, pages published there only after accepted by a committee.) Second is that there are a multitude of opinions (not surprising, I have heard genealogists are one of the fussiest groups of people known to man - except I heard the same thing about teachers, and doctors, and nurses, and ...). It is hard to reach a consensus, and there is no clear cut consensus-measuring mechanism on WeRelate. People claim consensus when there is none, and the people that disagree, don't see consensus, so disagree a decision has been made. Third, I think genealogy has traditionally been a very selfish activity, and people aren't used to working on a shared database that isn't meant to just reflect your own perspective. Personally, I don't think there has been a clear-enough vision statement of what the goal of this website is. Do we want to see how imaginative people will be with this website, no matter how narrow their focus; or is it about documenting latest and greatest knowledge in an objective, scientific way suitable to a shared tree contributed to by people who don't know each other; or do we simply want people to feel good about participating, no matter how crappy and unskilled their work is, so we get the greatest number of users? --Jrich 23:32, 28 June 2013 (EDT)
Thank you. The style guide at least fits the main criteria where people are concerned and the Help:Style guide (biography) appears to have some of the source requirements, as well as narrative. Would there happen to be one for producing sources or places which could be incorporated or linked with this guide?--Khaentlahn 07:50, 29 June 2013 (EDT)
'Rules without enforcement is pointless'. Well put! We should only document rules, guidelines, etc which are going to impact on the site, for instance: what pages are deleted; what GEDCOMs are rejected; how are disputes resolved and what do we encourage users to do. Regarding the last, education is a process and if we go there we need to think about how things are presented just as much as what they contain. Given our size I do agree that formal policies that are used for dispute resolution should be signed off by the oversight committee, but we don't necessarily need them to draft them. AndrewRT 05:41, 29 June 2013 (EDT)

Category Membership via Facts [16 July 2013]

This evening I scratched out a document, User:Jrm03063/Facts, Categories and Wikipedia. It describes some of the techniques I've been using lately to put some pages in (perhaps) better order, as well as to leverage Wikipedia pages other than simple places and biographies. Almost none of what I describe is original to my efforts, but this may be the first attempt to put it together.

For those who find reading a document too boring for words, I offer the page for Gen. Joshua Lawrence Chamberlain (fitting as we are a few days short of the 150th anniversary of his defense of Little Round Top). Notice that the page makes relatively rich use of Categories, but if you open the page for editing, you'll see that no category syntax appears in the narrative body proper. Categories are established by way of templates in fact descriptions. --jrm03063 23:49, 30 June 2013 (EDT)

Wikipedia indicates that adding pages to general content categories via a template is not recommended. Some of the reasons they list are
  • editors cannot see the category in the wikitext
  • removing or restructuring the category is made more difficult
  • inappropriate articles and non-article pages may get added to the category
  • sort keys may be unavailable to be customised per category
  • ordering of categories on the page is less controllable
  • the "incategory" search term will not find such pages.
WP:Help:Category#Categories_and_templates says:
"Changes to the template, however, may not be reflected immediately on the category page. When you edit an article to add a category tag directly, the list of category members is updated immediately when the page is saved. When a category link is contained in a template, however, this does not happen immediately: instead, whenever a template is edited, all the pages that transclude it are put into the job queue to be recached during periods of low server load. This means that, in busy periods, it may take hours or even days before individual pages are recached and they start to appear in the category list. Performing a null edit to a page will allow it to jump the queue and be immediately recached." --Jennifer (JBS66) 05:25, 1 July 2013 (EDT)
Thanks for your helpful observations. They are informative, but not persuasive. WeRelate is not Wikipedia. Specifically:
  • Wikipedia pages have no sense of genealogical facts, as we do
  • We need to ENCOURAGE more fact usage - and interesting categories and facts plainly are apt to coincide
  • The Wikipedia community is good at adding category syntax as needed - WeRelate users aren't.
Moreover:
  • Several of the templates I offer allow for sort keys
  • The "incategory" search term implementation, as you describe it, is broken. It should be fixed in mediawiki.
  • Re-caching behavior - my response - who cares? WP extracts are only updated a couple times a year and the source-wikipedia template gets run once a week.
--jrm03063 10:16, 1 July 2013 (EDT)
Persuasive is in the eye of the beholder. I suspect the wikipedia list of defects represents actual experience with this issue, and do not accept some of the hand-waving arguments made to counter them. In particular "We need to ENCOURAGE more fact usage" For example, pages that show residence facts every census even when the residence does not change tend to be nothing more than more cluttered, not better. (As usual, rote application of technology, just because one can do so, is not necessary good genealogy nor helpful to the usefulness of the page.) And I think the point of the re-caching argument may have been missed, as it has nothing to do with WP extracts, rather it would mean WeRelate re-caching (since we use the same software as WP) and the confusion that gets caused when recent edits don't necessary appear in all the places one would expect to see them. In regards to incategory, regardless of how it should be fixed, that doesn't rule out fixing it as a prerequisite. All that said, I believe putting categories in templates is a practice long-used by many of Amelia's ship templates, among others, and it would seem that usage of templates will rarely be done by GEDCOM uploads, so hopefully the editing user will be checking that their work produced the desired effects. This should hopefully minimize the misuse. --Jrich 11:24, 1 July 2013 (EDT)
  • The re-caching argument has not been missed. The issue raised is one of timeliness - and my response is that we already expect that a number of things do not happen in a timely way. In any case, the situation indicated as a concern is one where the template is changed and it takes time for the secondary effects to trickle out. The more common situation is adding a template on an individual page, and that matter doesn't have any such problem.
The caching of wikipedia pages for use on WeRelate is a different type of caching than the caching of changed WeRelate pages, having a fundamentally different scheduling mechanism. It is hard to see how it is relevant, since the delays of the two types of caching differ by orders of magnitude (minutes versus months). This appears to suggest the response addressed a different type of caching than referred to by the wikipedia defect list, i.e., missed the point. The occasional caching bug, such as when a parent link points to a family page that does not contain the child whose link brought you there, shows how confusing caching problems can be. Currently, I think our traffic, hence our latency, is low enough that this is not a big danger, but this is apparently viewed as a problem in the wikipedia list, probably because their load levels are so much higher and so their caching gets delayed more. Perhaps once we leave Beta, our load levels will cause increased caching latency. --Jrich 15:07, 1 July 2013 (EDT)
  • The primary insight that I offer is that categories apt to be genealogically interesting seem to be remarkably aligned with things that ought to appear as facts ("ship" templates obviously belong as "immigration" facts). I don't yet see that this has been disputed, so what I'm hearing amount to excuses why our users should be abused into handling something twice (First as a fact and secondly as a matter of membership in a category). That isn't an eye of the beholder issue - it's objective interface design. --Jrich 15:07, 1 July 2013 (EDT)
Facts can be good and bad (they often promote trivial information into a place of prominence, and rarely stand alone since they imply a need for sources and often include details not conveniently displayed in the structure fact fields). If they correlate with categories, besides implying linkage, it also implies redundant presentation: i.e., maybe both aren't needed. Regardless, this is a discussion of degree and guidelines and isn't covered by the overly simply statement that facts should be encouraged. It may be an issue of interface design, but the answer is not objective. Fact fields are a vestigial representation of data that appear to be inherited from the GEDCOM interface. Some important ones are needed for structured searching and infoboxes, but it not clear that all facts are inherently good versus a well-written narrative description. Perhaps if there was a way to toggle hiding and showing of lesser facts, or building a timeline viewer similar to the way the family tree may be opened up and viewed? --Jrich 15:07, 1 July 2013 (EDT)
I agree with the concern that there are major and minor facts, and that some control might need to be established (but I would think this is a "problem" that we would be glad to have!). I very much like the idea of limiting the fact display if the number or space taken by facts extends beyond some modest limits. I was observing this w.r.t. Chamberlain, and considering what the page would look like if I added every single battle where he is documented as present, and further, added every single change in rank and command. Those would be nice things to have, but it would indeed be overload for a casual observer. Perhaps one of us should add that as a suggestion?
My preference for facts is both to better encourage sourcing (which is more explicitly a part of creating facts) and because information created that way seems to me more apt to usefully persist if it should be exported to a GEDCOM.
I'm not against narrative, but I think it fundamentally needs as much work as an equivalent set of facts, and it's easy to do badly. It's also not everyone's forte - and we don't want to discourage solid contributions - even if modest. --jrm03063 15:53, 1 July 2013 (EDT)
  • I'm not claiming that a GEDCOM will be uploaded containing categories - what I instead claim is that placement of useful facts on a Person page - is more apt to yield re-useable information on Export - than to see a category syntax appended in some random way in another piece of software. Facts also allow for explicit support - which seems like it would be problematic in the context of category syntax in the narrative body.
I, of course, never said you said it, as it was an observation I added as a reason why I think this feature may be acceptable, even though wikipedia experience apparently argues against it. --Jrich 15:07, 1 July 2013 (EDT)
  • I would also note, that I've worked with at least some of the templates and practices for a while now. I'm not offering ideas simply because they are possible as a matter of technology. I have found them to be useful in practice, which is why I'm describing them for the public.
I'll add the criticisms to my document so that informed discussion can be resumed later. --jrm03063 12:59, 1 July 2013 (EDT)

Just picking up the point made about listing, for example, all census sightings of an individual - I agree they make pages look cluttered, however I wouldn't want to move away from listing them all, as it shows that a particular aspect of the research has been done. What I would far rather see is the list of all facts apart from birth/baptism, marriage(s) and death/burial moved to appear after the narrative biography (if someone has done it), so that it's the biographical bit the eye is drawn to first, not the great long list of facts. --RichardK 13:37, 2 July 2013 (BST)

Well this is good - perhaps it's a bit of consensus anyway! The idea being that too many facts can be overwhelming given the current display practice - but we don't want to solve it by having fewer facts. The ideas on how to deal with this (so far):
  • jrm - A simple limit, with an expandable section for overflow
  • jrich - some facts are "major" and some are "minor" (presumably by type?) - with minor facts being expandable and hidden by default.
  • richardk - primary facts appear as they do today, where they do today - any others appear in a separated section later
For my part, I don't have a strong preference for any of the alternatives (even my own), so long as the process is automatic (handled by the display software) and that the input/editing process for facts remains as it is.
--jrm03063 09:39, 2 July 2013 (EDT)
Partly because I tend to use the facts list in a different way than most people (example), should I assume I would be given the option of marking every fact as important? I wouldn't want the software deciding that for me. Also, I would suggest that anyone embarking on writing a normal biographical text would probably better serve the reader if they deleted all of the minor facts from the list as they added them to their text. Repetition of the sames facts isn't really necessary, although the birth/christening, death/burial, and marriage facts are required when available (those facts carry over to other pages and help with searching). -Moverton 17:04, 8 July 2013 (EDT)
Here's what I think we agree on (thus far):
  • It is possible that the number of facts for a Person can become burdensome for ordinary display purposes
  • Omitting explicit fact items is an undesirable way to limit/throttle the fact display (facts persist nicely in GEDCOMs, they encourage source association, and users who don't care to work in narrative are able to contribute)
I don't think we have a consensus on the details of how a limit would be implemented (or even if it would - only that the people who've discussed it so far seem to think that could be a good idea). If implemented, I doubt that the details would be user selectable on a per-page basis.
One aside - as I examine your page for William, my thinking is that I would have put descriptions of that length into a "Note", and attach the note to the fact. --jrm03063 17:31, 8 July 2013 (EDT)
That might work if the notes didn't appear in a separate unorganized list. Plus it is much harder to read if the user has to jump back and forth between the list of facts and the notes. (The same reason I don't put all that text in with the sources.) The way I'm using the fact list is more like a descriptive timeline of events in lieu of the usual biography. -Moverton 15:41, 9 July 2013 (EDT)
Unfortunately there are no real guidelines for how to lay out the pages, so people do interesting things, but with the result that the pages don't all work the same. I personally would rather the purposes of the facts in WeRelate was better defined so everybody did things the same way, so the casual reader (the one asking, is this my John Doe?) could quickly find what they are interested in. Clearly the interested researcher will read everything on the page, and probably have enough context to handle many presentation styles, so it is the casual reader that should be aimed at. I think the major facts should be viewed as basically conclusions that summarize all the evidence given by the sources. Personally I don't believe a source citation should assume the fact will always say what it says now: too many cases where a source was misapplied, turned out to be wrong, or superseded by a more complete source. I think a lot of information is kludged into fact fields when they don't really fit, e.g., occupations, and military ranks that may or may not have a definite year range, or definite locations. I think a lot of facts are poorly defined, e.g., difference of baptism vs. christening. Some researchers spend their whole life studying a single person and their set of facts would put anybody else to sleep. The narrative has the advantage of being split into sections and having a table of contents whereas a long list of facts can cause important information like the death date and even marriages to be so far down you must scroll to see them. --Jrich 17:43, 9 July 2013 (EDT)
What if notes that are attached somewhere are suppressed from the list of trailing notes? --jrm03063 18:02, 9 July 2013 (EDT)
Has anyone thought about changing the page structure, perhaps with different tabs... one tab for biographical text, one for timeline, one for sources, maybe one for all the family summary box info... you get the idea. Or is it preferred to just keep everything on one long page? -Moverton 13:26, 10 July 2013 (EDT)
I prefer it the way it is. If it isn't broken, don't fix it? Keep things simple as possible. Tabs are clutter. Daniel Maxwell 13:29, 10 July 2013 (EDT)
Let's ask a more basic question and step away from implementation questions - do you believe that a fully realized set of facts and events can be so overwhelming that a summary or reduced form would be preferable by default? --jrm03063 14:16, 10 July 2013 (EDT)
I would always want all facts to be shown somewhere on the page, but a change to seeing only a summary by default at the top could be positive. AndrewRT 16:03, 12 July 2013 (EDT)
I'm wondering if it might be better to have a summary section that is expandable - or maybe an analog to the tree display - perhaps an hour glass? - that gives a full blown timeline view? --jrm03063 17:32, 12 July 2013 (EDT)

Any effort to hide/suppress/or limit the listing of facts is essentially an effort to do away with the need for proof and good genealogy. Pretty may sell well to some people, but there are still some researchers who care about things like facts, documentation and proof. WeRelate's structure, which allows the addition of facts of whatever nature, is part of what makes it both unique and superior to any other data base on-line. --GayelKnott 15:13, 14 July 2013 (EDT)

I think an expandable section could be a good solution that provides the readable interface but also maintains the full list, although I don't know how easy this would be to develop. I would also want to think ahead to "web 2" concepts around automatic data sharing between websites (a "semantic web") where the more facts that are recorded in a structured way the better. AndrewRT 18:10, 16 July 2013 (EDT)

June Carter and Johnny Cash [16 July 2013]

I chose June Carter Cash as the subject of this week's contest because I watched the movie of her life starring the singer/actress Jewel. I was surprised that June is already in WeRelate. But there isn't any census data or other references so there is a lot of work to be done on her page. It made me think - I noticed that June passed away and then only 4 months later Johnny Cash passed. This is a an oddity I have noticed before - very close couples, long married, passing within a year of each other. Other examples would be Richard and Pat Nixon. And my own grandparents, Jean and Oscar. I'd like to make a category for these couples. What would I call it? --cthrnvl 15:07, 5 July 2013 (EDT)


I am the only one here interested in this sort of thing? I think I have Aspergers. --cthrnvl 11:57, 14 July 2013 (EDT)

If so you've probably come to the right place! I'm sure what's been written about Wikipedia here [5] would also apply to WeRelate :). AndrewRT 18:12, 16 July 2013 (EDT)


Edit summaries [14 July 2013]

If you aren't adding summaries to your edits why not? To me it is like someone has died and I have to search all over their house for some clue to find their relatives so I can tell them what happened. (This actually happened to me last winter.) Don't be that guy who doesn't care what happens when you are gone. I have a handy tip: If you go to the menu at the top of WeRelate - My Relate > Dashboard > Edit Preferences then click the "editing" tab. Now check the box for "Prompt me when entering a blank edit summary" (last choice in list). This will make it so you can't save a page unless you have given a summary. Thanks for contributing to WeRelate! --cthrnvl 15:20, 5 July 2013 (EDT)


I'll admit to rarely entering an edit summary - and I justify it by claiming that overwhelmingly my changes are obvious clean up or addition of source material - changes that would be obvious from the "diff" if someone actually looked at it. I try to use the edit summary if I make a change which wouldn't otherwise be obvious - were I to do otherwise - it would slow me down too much in making the rather vast number of changes that I'm typically making. --jrm03063 14:01, 9 July 2013 (EDT)
That, of course, assumes somebody looks at the diff. The email notifying one of changes, the listing of recent changes in one's watchlist, and recent activity or contribution logs all show the edit summary, but don't show the diff. Someone has to decide to pursue things to see the diff, and with no edit summary, of course, they are given no clue about whether it is a significant change. Further all your edits are marked minor because so many people complained when all your edits were marked major. --Jrich 14:32, 9 July 2013 (EDT)
Is there a point here? I'm afraid I'm not an expert on knowing what other people consider to be major, minor, or otherwise significant or informative. Perhaps there's a guideline to which I could be referred? Further, as a software developer, I consult diffs as a matter of routine. watchlist entries have an adjacent diff button for precisely this purpose. --jrm03063 15:44, 9 July 2013 (EDT)

Here is the Wikipedia page for edit summary. I always leave a summary but I especially like to add a summary when I fix format, spelling, typos - in that way if someone is watching a page they know they don't have to go try to figure out what I have done, it was a simple edit, no new information. If I don't add a summary a person may wonder Did she fix a typo? Or did she find the burial place for my 5th great grandfather?? Most people here have jobs or other responsibilities and I just think it is courteous to save them time by adding an edit summary. --cthrnvl 11:11, 12 July 2013 (EDT)

From your perspective, that makes perfect sense. If you're making a handful of changes, it probably seems like a pretty good idea - and anyone doing otherwise must be just rude. On WP, where pages have lots of narrative and weird structures, and could be spread out strangely, it's even more apt to be sensible to do. But there's another perspective. My dashboard routinely reports that I'm making about 30,000 edits over the last 90 days. That works out to 333 edits per day. Figure about 80 of those per page of text - and doing an edit summary faithfully would mean I'm writing another 4+ pages of gook EVERY DAY! - on the off chance that a few of those might relate to something that someone cares about - and further - that I won't lose my train of thought on what I'm trying to do across several pages, while I'm finishing off one. WeRelate changes - in my experience at least - are pretty obvious when you look at the diff - and I just don't find edit comments persuasive when I'm trying to decide what to look over. Beyond that, I too have a job and I'm a busy guy! Would the community be better served if I'm writing throw-away phrases on the edit summary - or actually adding/cleaning/standardizing/de-duplicating content? Content which in most cases is absent or has been abandoned and uncared for since GEDCOM upload years ago? I see your point - and I'm really not trying to be difficult - but I am pointing out that there is another valid perspective. jrm03063 17:31, 12 July 2013 (EDT)
It makes perfect sense from my perspective too. After all I'd rather enter edit summaries than enter pages. My favorite is entering sources, which probably saves me the trouble of entering 2 or 3 times as many person pages as I do. Thanks goodness this is a collaborative environment giving me an excuse to slow down, or I'd run out of pages to enter in no time. --Jrich 12:05, 13 July 2013 (EDT)
I think this is one of those things that belongs in the "encouraged but not mandatory" box. Yes please - I find it very useful to have edit summaries as it means I can see in the notification email whether to look at the diff or not and likewise with the history page and if I look at my watchlist. However, we shouldn't stress it to the extent that it puts people off editing. As they say on wikipedia, "Don't bite the newbies". :) AndrewRT 15:59, 12 July 2013 (EDT)

So jrm, you are saying that you are doing things that basically a 'bot would do? That is different from what the average user of WeRelate is doing and I am arguing that the average user has time to think about who comes after them and has time to leave a summary. The way I look at what I am doing is that if I don't have time to write a summary to help out those who follow me, then I don't have time to do that edit. And BTW, I believe that edits made on Wikipedia with no edit summary are considered suspicious - most vandals don't leave a summary. Maybe that is what got me on the summary bandwagon - I don't want a busy supervisor to revert my hard work because they see no summary and don't take time to figure out what I did (sometimes if I change the format, for example, it is not so easy to see when you compare before and after.) Another thing that makes me suspicious about an edit is when the user's name is red-linked! If you want me to take you seriously, or your project seriously, you should describe what you are doing and explain yourself a little on your profile page here. Thanks for listening : ) --cthrnvl 22:52, 13 July 2013 (EDT)


Knighting - what fact type? [12 July 2013]

Being made a knight of a particular order seems (KG, KB, KCBE, etc), during the lifetime of the individual, somewhat like a title of nobility. However, it isn't inherited (at least in most cases). So what do we think? Title of Nobility or Other? --jrm03063 11:52, 9 July 2013 (EDT)

I'm going to start using the nobility title fact type folks...ok? --jrm03063 17:31, 12 July 2013 (EDT)
Sounds reasonable. To the human reader I'm not sure it makes much difference although for a computer reading it may prefer to have something rather than just "other". AndrewRT 19:14, 12 July 2013 (EDT)

Growth [29 July 2013]

This thread follows from one entitled "WeRelate growth [30 May 2013]"

I've updated the previous chart to show the latest figures and added a new line being the number of new pages per day.

Image:Person pages werelate.jpg

Does anyone kow why there has been such a large drop in the last month? Is this just a seasonal thing with holidays? AndrewRT 19:56, 12 July 2013 (EDT)

By May 7 folks began learning that certain categories were going away. A lot of folks saw that unexpected event as a trashing of a lot of their hard work. Could that have had something to do with it? Go back and read their comments. --janiejac 21:42, 12 July 2013 (EDT)
I'm afraid I don't understand - can you point out some examples for me? --jrm03063 11:40, 13 July 2013 (EDT)
Go to the TOC top of this page to link to the extensive conversation concerning categories starting with:
9 Categories [6 mei 2013] and the section just beneath it
10 Why have surname categories disappeared? [13 May 2013] and
11 Category:Surname and Category:Surnames by country [11 mei 2013]
I see what you're talking about now. I can't say that I disagree with the changes in question, or that this particular change resulted in any genuine loss of data. But I agree that the process by which it was accomplished inspires more doubt than confidence - certainly in this long-time user. --jrm03063 18:36, 13 July 2013 (EDT)
Also I note my own comments (item 5) on the L O N G wait to get GEDCOMs accepted. So possibly the shortage of volunteer admins contributes to frustrations that folks have. You might examine a list showing the number of admins now compared to 2008. previous comment unsigned by janiejac
First, users that questioned the removal of Surname categories continue to actively use WeRelate. Also, you will see under New Browse Feature, that some users expressed they liked that new feature (which is intended to replace and improve upon Surname categories).
Secondly, WeRelate moved away from the former administrative structure and instituted various committees instead. Users can volunteer with any of these committees and will be given admin "rights" as needed for those duties. These users with admin rights are not listed on the old admin list, but since the committees have been formed, 5 users have been granted new admin rights. That being said, WR could certainly still use additional volunteers.
I would like to know from AndrewRT, where did you obtain the data showing the drop in new pages per day? Did this number include the creation of categories, because that will be a change since new Surname categories are not being created. --Jennifer (JBS66) 15:47, 13 July 2013 (EDT)

The source for the data is shown alongside the supporting page for the graph itself - essentially it is a blank search for pages within the "person" domain. Pages in other domains are not counted. The new pages per day is (current total - previous total) ÷ days elapsed. One flaw in this method is it is a NET value - new pages less deleted pages. I do know that lots of "living" pages have recently been deleted - does anyone know how I can work out how many this is? AndrewRT 17:07, 13 July 2013 (EDT)

For the more recently deleted pages, you can go to Admin>Logs>Deletion log (I'm not 100% sure if you can view it, if not, let me know). If a user deleted their tree, that should be indicated with a note (deleting tree). Also, if those deleted pages were restored there will be a note (X revisions restored). It looks like since July 1, about 6900 pages (the vast majority empty living pages) have been deleted. --Jennifer (JBS66) 17:46, 13 July 2013 (EDT)

Many thanks Jennifer. I've worked through the logs back from 13 July to 10 June, searching for "deleted "Person:" and found a total 19,685 entries. There are also 1,035 entries for "restored "Person:" which means a net impact of 18,650 or 565 pages per day. This could easily account for the change if there has been a significant increase in deletion activity recently (say from 100 to 565 pages per day). Does anyone know if this could have been the case? AndrewRT 18:13, 13 July 2013 (EDT)

This is definitely the case :) The most active user deleting living pages has been DMaxwell. This user joined the Speedy Delete committee on 25 June and according to their user page, they've already deleted about 10K living pages! That number does include Family pages, but you can see the strong push there has been recently (by a number of great volunteers!) to remove these pages from WR. Just a side note, these living person pages used to be created during GEDCOM upload. This is no longer the case, pages for living people are excluded from GEDCOM upload rather than having empty pages created for them. --Jennifer (JBS66) 18:24, 13 July 2013 (EDT)
Yes. I have had alot of spare time lately so when I've gotten bored I will simply type 'Living' in the name field and start to go through them. The vasty majority can be deleted right away, but I exersize some caution with those that are part of family groups - several I make attempts to track down if the person is dead, but if the info isn't available I delete them. There is a TON of work to be done in this area - I really could use some help going through them. I have the 'Living Unknown' person pages down under 5000 but there are still over 110,000 'living' pages of other names. Simply put it is a major undertaking, and although I know many were created in the GEDCOM upload process, there are some steps I would like to see the site admins take to prevent 'livings' from ever coming back. But to the point, it was inevidable that my work would show as a massive drop off of new pages. Daniel Maxwell 18:35, 13 July 2013 (EDT)

Mystery solved! The deletion logs seem to go back quite a long way and I've taken them back to 6 April. Between 6 April and 10 June there were 5,900 deletions and 770 restorations (average 79 net deletions per day). The net increase in new pages was 513 per day, hence the gross additions was 592. From 10 June to 13 July there were 19,685 deletions and 1,035 restorations. This corresponds to a net deletions of 565 per day. The net increase in new pages was 100 per day, meaning the gross additions has actually gone up to 665. This has certainly been a useful exercise although it does mean I'll have to go back to the drawing board in terms of defining a meaningful measure of success. Clearly this exercise in deleting living people is positive for the site (thanks DMaxwell and others for doing this!) so the measure needs to reflect this. AndrewRT 18:48, 13 July 2013 (EDT)

As an aside, without looking too closely at it right now, I wonder what is being restored. I hope people are not restoring 'living's out of spite, or coverting them to 'stealth living's (ie blank pages with just a name and no dates - another problem that needs to be addressed) Daniel Maxwell 15:35, 14 July 2013 (EDT)
No, the living pages are not being restored. In this case, a user deleted their tree and a few users with admin rights restored some of those pages. Right now, a user cannot delete pages that other users are watching, but ancestors of those people can be deleted (fixing this is a to-do list item). So, users with admin rights can restore these pages as needed. --Jennifer (JBS66) 17:42, 14 July 2013 (EDT)

AndrewRT -- could you tell us how you gathered the statistics for the graph? I'm interested in looking at the growth in the different namespaces, as these might be dramatically different. For instance, the number of new pages created in the (Main) space is very small (2 on 17 July and 1 on 19 July), but the number created in the _Person_ space is >500 across 21 and 20 July. Thanks. --ceyockey 11:52, 21 July 2013 (EDT)


Please see here for a description of the data sources. In simple terms the older data points for number of person pages was gathered by looking through the history of Main Page, as this has periodically been updated with the latest number. The current value can be calculated by looking at the number of pages returned with this query. I've just done it and it says "Viewing 1-20 of 2480642" which indicates there are currently 2,480,642 person pages on WeRelate. The net changes per day figure is derived from a formula as noted above (Current value - previous value) / Time elapsed. Please let me know if you want any more detail. AndrewRT 17:12, 21 July 2013 (EDT)

Thanks, that is quite helpful, Andrew. I'm wondering if anyone has or there might be an opportunity to obtain read access to the underlying database so that queries can be run (at low low priority) for statistics collection and analysis. --ceyockey 20:20, 24 July 2013 (EDT)
Something to keep in mind about stats like that ... I've seen on a few sites in the past that auto-collected and displayed aggregates stats like that can be incorrect for a variety of reasons. I am not saying that the stat _is_ incorrect (it likely is correct), but noting that validation against a more direct stat gather at least once would be prudent. --ceyockey 20:24, 24 July 2013 (EDT)
Understood, although it's something and previously we had nothing. If there is a better way I can practically do this then I'm all ears! Note I have a fuller article on the range of stats I'd like to get to at User:AndrewRT/Metrics - would welcome any comments there. As an immediate next step, I'm keen to start gathering stats on website readership (User:AndrewRT/Metrics#Page_views) - is anyone familiar with how to do this? AndrewRT 15:19, 29 July 2013 (EDT)

Living Persons [2 August 2013]

May I add a suggestion with regard to reducing the number of Living Persons who get into WeRelate in the first place.

Privacy is a big topic in the world of genealogy, just as it is in the wider world of life in general. But family researchers keen on expanding their family numbers to cousins of cousins of cousins forget that this may be an issue for the families beyond their inner circle. I intentionally left my deceased parents and their generation off my family tree on Ancestry only to have had them added by people copying my tree to theirs.

Now that I am adding families of far-flung cousins, I set a date limit on whether I will include later generations or not. As a rule of thumb it is a birh date of 1900, but I also take into consideration the birthdates of a whole family group and those of their first cousins. If I find a family group that has children born on both sides of 1900, I don't add any of the children. Instead the parents' pages include a note to say x and y had so many children: a sons and b daughters. Fifty years from now (ha ha!), another researcher will have a clue that another generation existed and is worth searching for.

Perhaps this suggestion could be written into the notes for new WR users. Just saying we never include Living Persons may not be enough for some people to understand why. --Goldenoldie 02:24, 15 July 2013 (EDT)

Could you clarify what the suggestion is your referring to that would be added in? AndrewRT 15:48, 15 July 2013 (EDT)
My thoughts stemmed from the topic above this one on the Watercooler--dealing with pages for Living Persons. I felt we ought to remind new users to omit Living People and explain why we ought to do so. This is not a suggestion from the suggestion box.
Trusting this clarifies the description above. --Goldenoldie 15:04, 16 July 2013 (EDT)
As I read it, the suggestion offered is to get more descriptive, so as to address specific issues and either provide workarounds, or emphasize to tempted people, that, yes, we mean you! As I read it, one example might be, people born after 1900 should only be entered if dead, and all their first cousins are likewise dead. If a deceased person has living children, it is allowed to enter the number of children on the Family page, but the children themselves, whether living or dead, should not be entered. That WeRelate would like its users to err on the side of caution out of respect for the collaborative environment. This seems to be another one of those areas where collaboration recommends different practices, going against the normally self-centered focus of private genealogy, and so detailed guidelines are needed to avoid misunderstanding and rationalization. --Jrich 15:18, 16 July 2013 (EDT)

You've got it. To get more descriptive and, at the same time, hopefully, friendlier. --Goldenoldie 15:39, 16 July 2013 (EDT)

Got it - thanks. Presumably the pages that you are talking about are ones like:

In addition to your list, there is also the intro to the Add Person page and the Edit screen of every Person page. These are the pages the ordinary user is more likely to see--and see quite often if he/she is building up a family.

I checked some of the pages you mention before making my first response above. I have now looked at all the textual ones.

Believe it or not the Person pages tutorial (main page) does not include the word "Living" and the ImportGedcom page only states "(Living people are handled specially.)". There is no link to a further explanation of this sentence which is in parentheses to start with.
And another entry four down: "What happens to living people in my GEDCOM?" are very instructional. Is there a plan to adjust the rules and the subsequent "blue pencil by software" operation on living people submitted? Should these paras be put closer together?
This is a brief warning of the WR consequences which assumes the reader has found Help:GEDCOM#What_about_living_people_listed_in_my_GEDCOM.3F
This is terribly involved and could easily go over some people's heads. Yet it does best explain where WR administrators get "suspicious" when looking at a GEDCOM.
I didn't looked at the video links. The WR server was v-e-r-y slow yesterday and I don't know whether it has improved today.
This gets down to the nitty gritty. Is this a new page? I'll send you a suggested second paragraph separately off Watercooler. --Goldenoldie 03:20, 17 July 2013 (EDT)

In light of this suggestion, I've revised the policy here: [6]. Given that this change is purely explanatory I'm not expecting any objections but it you do object please revert and discuss. If everyone is ok with this new wording we can roll it out to the other pages. Goldenoldie - would you like to suggest any other changes? AndrewRT 14:36, 18 July 2013 (EDT)

If this is the extent of the change, I think you're right that it should not be objectionable. But as one working on Person Patrol and Speedy Delete, I'd prefer not to have to enforce a rule like "all first cousins are dead" or even "all siblings are dead." It's just not knowable. "Parents are dead" is fine and enforceable. That's not to say people can't (they should) have more stringent rules of thumb for themselves, I'm just flagging the issue as a matter of policy. -Amelia 17:16, 18 July 2013 (EDT)

I think this a worthwhile revision to the FAQ. It will act as a reminder to people not to add everyone they can think of. There is a line in tree-building where the brakes have to be put on. I respect that in your work on Person Patrol and Speedy Delete you deal with entries that have already been made.

Any further suggestions? The list of places to consider expanding the explanation to the Living Persons rule should include Special:AddPage/108--the "Add a New Person Page" where even a link to the specific FAQ might be in order.

As to any other suggestions--not at the moment. But I have been glad to have had this opportunity to get involved. Now back to a family tree that may or may not tie together. --Goldenoldie 02:54, 19 July 2013 (EDT)


I assume the above discussion refers only to living individuals on Person pages. My question concerns living individuals in Sources or Notes. Obituaries are a good example; on one of my recent obituary notes I deleted the names of 13 living individuals yet I know that anyone can search for the obituary and see the names. Even if the Person page had no Source or no Note for a death in, for example, Concord, NH, Oct. 27, 2012, that would be enough information for someone to search the internet for the obituary to see if it mentioned living persons. Exactly what are the restrictions on living people on other than Person pages?--HLJ411 12:05, 2 August 2013 (EDT)


Protocol for living people named in documents addressed this question.--Khaentlahn 12:25, 2 August 2013 (EDT)
Thanks for pointing us in this direction, but that discussion didn't seem to have a conclusion - in particular there was a difference between the last comment by BobC and the reply by Dallan. It would be helpful if we could agree a policy on this. AndrewRT 16:34, 2 August 2013 (EDT)
Can I create pages for living persons? states "If a user objects to the inclusion of information about people who are still living, the information and/or pages will be deleted. On pages for People/Families who are deceased, information about still living people that is publicly available (ie, 1940 census data) - can be included on the pages." --Jennifer (JBS66) 16:45, 2 August 2013 (EDT)

New Logo Suggestions [16 July 2013]

Just a reminder... Logo Suggestions is looking for WeRelate logo design candidates. Entries will be accepted until 31 August and will then be presented for a vote. --Jennifer (JBS66) 11:59, 16 July 2013 (EDT)


I've added a draft - would appreciate any comments, good or bad! AndrewRT 18:06, 16 July 2013 (EDT)

auto suggestions and recently used sources - not working? [2 August 2013]

One very nice thing about this site is the suggestions for place names - to conform to the site to the same standard. This as well as the recently used source, which is nice for when you are using the same source over and over again. Is it just me, or are both of these things not working in the last day or so?--Daniel Maxwell 16:14, 23 July 2013 (EDT)

It seems to be working fine for me, and I use it constantly. Sorry that you are having difficulty. --Cos1776 17:14, 23 July 2013 (EDT)
Both of them? (the place suggestion and the recently used sources). The performance of WR over the last several days has been very poor in general - I have had alot of time outs, etc. It isn't on my end; all other websites are working fine except WR, which is tanking for me. Very dissapointing since I was in the middle of a bunch of updates and am now stalled. Daniel Maxwell 02:32, 24 July 2013 (EDT)
The lookahead failures you are seeing are most likely due to performance problems; that is what I've found on other sites. You might take a look at another site which offers lookaheads, like Google with the function enabled, to see if it might be something local to your machine, though, as sometimes local machine problems can cause a big delay in that functionality. You also might see whether you are having the same problem on a couple of browser types (if you use more than one browser) as the rendering performance will be different between browsers. --ceyockey 20:15, 24 July 2013 (EDT)
I tried 3 different browsers and I still have the same issue. I don't understand how a browser could affect the recently used source option. The auto suggestion feature is working about 25% of the time for me. I'd like to hear from Dallan or one of the admins as to what might be causing this...it's driving me up the wall. I must note that I am a Linux user, which has never been a problem with the site performance until the last week and a half or so. Daniel Maxwell 06:37, 1 August 2013 (EDT)

It wouldn't be something under Settings, would it? There are a lot of choices under the tabs. --Goldenoldie 07:04, 1 August 2013 (EDT)

I'll need some additional information. Can you bring up the site in chrome, right-click and select inspect element to open the inspector, click on the network tab, then do something that would normally bring up a places/sources list. Now click on the xhr button at the bottom. What do you see? There should be a request with a 200 response. (I figure that since you are a Linux user, this should not be a problem for you to do.)--Dallan 11:27, 2 August 2013 (EDT)
I will get to testing tonight. I've sent you an email at WR email so we can discuss this further without clogging up this page, since no one else seems to be having this issue Daniel Maxwell 18:26, 2 August 2013 (EDT)

In the news - can you help? [31 July 2013]

The oversight committee has given their green light to this idea that I mentioned above so I've created a page at WeRelate:Current_news_nominations as a starter. The main challenge is getting three or more people who are prepared to regularly contribute items so that we have a 'critical mass' to maintain the page. Is anyone on here willing to help out with this? AndrewRT 17:30, 30 July 2013 (EDT)

How many weeks (months?) did it take? I mean, the existing content is so fresh - I'm sure there was a lot to think about! --jrm03063 18:56, 30 July 2013 (EDT)
The two oldest stories I took from my previous comment here; the two newest ones - Prince George and Philippe of Belgium took a few hours to pull together because although they had a lot of their respective families on WeRelate already there were some gaps. My thinking is that as long as the page is present with some family it could be added into this page and that in turn will pull people in to edit and add more. AndrewRT 20:00, 30 July 2013 (EDT)

WeRelate vs Ancestry and Family Tree [23 August 2013]

I am sure that most of you have used Ancestry and are not happy with multiple family trees for the same person and also the copied trees with wrong info.

I have in the last week experimented with the Family Tree on Family Search. The trees that I accessed and entered data have no person watching them. Wondering if anyone can share their info with how conflicts were handled?--Beth 22:01, 2 August 2013 (EDT)

There doesn't seem to be much notion of "conflicts", so far as I can tell. When the wiki function first came out, I worked with it a bit, but the trees are in such a mess, I kind of got discouraged. I was able to take some satisfaction in deleting a bunch of garbage information, and while I was prompted for a reason, I could leave it blank. Given how much garbage there is, this is probably the right approach, but it would be just as easy to delete valid alternatives, too -- there's only one set of vital records fields, and no way to add alternatives, so you put in what you like best, and the next person can change it. I went and looked through the history on one of the people I'm watching, and it's hard to tell what's happened. I wasn't notified of any of the changes, though perhaps that's a setting somewhere.--Amelia 16:39, 4 August 2013 (EDT)


FS Family Tree is being actively developed and is not yet mature. There is no system in place to handle conflicting views between editors about what the right information for a person is. They are aware that something will need to be done but will start with just depending on the good will of editors generally, with locking of person records in extreme cases.
As far as recording conflicting data, as Amelia said, there is no structured way to do this (as there is on WeRelate with Alt Birth, etc.). One could add an "other" event for an alternate date, or put it down in a discussion note for the person, but that's about it.
Yes, anyone with an account can add or change data. The displayed data is just the last version entered. There is a change history, and one can "undo" changes with a button in the history.
As far as I know, there is no way to tell if another person is "watching" an entry or not. All you can tell is what entries your own account is watching. As of a few months ago, it seems that notification about changes to watched entries are being sent out (in weekly emails, at least with my settings).
The database is large, but filled with much mixed-up data. There are many data sources, not all completely reliable, and a noticeable portion of the editing has been done by people not expert with the tools and perhaps not conversant with genealogical proof. The cleanups needed there are much greater than here (but then will probably have many more working on them eventually).
---Robert.shaw 19:47, 4 August 2013 (EDT)
My experience was similar to Amelia. With considerable effort I was able to clean-up a problematic portion of my family tree where there is much garbage on various web sites. I might add to the previous commentors that the process for finding duplicate entries is hit-or-miss. Either the duplicates show-up immediately or it is really hard to bring them up. The interface has some nice ease-of-use features but when you try to deal with anything that is not entirely routine it gets very tedious. I would NOT abandon WeRelate for Family Tree. --Jhamstra 00:04, 5 August 2013 (EDT)
If you click on your user name on the menu and select settings there is an option to have weekly notices of changes on watched pages emailed to you. However today I finally merged a page that had another contributor but no email contact. Well I checked my name and it also shows no email contact although my email address is public on the settings site. Will have to get help tomorrow but check to see if your email address is listed on the contact page. And I haven't dealt with anything beyond the routine to make a comment. Using WeRelate which I do love is complicated and Family Tree seems less so. Ancestry trees I mainly use for research. Since I am a volunteer administrator of a DNA site I plan to use Family Tree to enter the data on people that I am not related to. I have not successfully recruited anyone to use Werelate other than to drop of their gedcoms. So if I ever make time to actually finish researching my direct line my preference would be to have it here but other families not so much. --Beth 00:45, 5 August 2013 (EDT)
Wikis have become such an incredibly standard item across many endeavors and disciplines. I am perplexed - whatever the perceived challenges in their use - that any organization - even LDS-backed - could seriously imagine building an alternative. I can't see a software engineering rationale for doing it. --jrm03063 10:49, 5 August 2013 (EDT)
Perplexed as you may be I think Family Tree has now accomplished the one family concept. I remember asking Solveig several years ago how we could compete and she said that Family Search trees did not work. Now Family tree has eliminated the automatic gedcom upload so you may now upload a gedcom but not automatically merge into the tree. On a person page you may also search for records and if found attach the records to your person. Only the vitals may be sourced to date, but I am sure that they will shortly change that.

You may merge people and some of the records seem to be created by a robot. For example they seem to have entered the data for the 1850 census without any regard that all of the household members are not actually the children of the head of the household. I have devoted many hours to this site but I see very little progress. Family Tree already has standardization entries for places and dates. Originally even some of the computers entered the data in non standard format but now at least there is a box to correct. Point what is our future here? We had this huge discussion about deleting certain specialty projects but not others and then we also have the committee that eliminates all of our work with nothing said from Dallan. Still in Beta. What is the future of Werelate? How do we compete with Family Tree and Ancestry?--Beth 00:48, 22 August 2013 (EDT)

One of the things that I love about FamilySearch (as compared to WeRelate) is how easy it is to add sources to people - I would love to have (and help build) tools to allow you to add data from FamilySearch, UKBMD, etc. directly to WeRelate people.
I don't know what the magic change is that would allow WeRelate to reach a tipping point of popularity, but making it easier to add people and sources is a pain point for me. -- Jdfoote1 10:53, 22 August 2013 (EDT)

WeRelate's content is in such better shape and its design sounds far superior. Has any effort been made to discuss using WR data instead of the mess they have at FS Family Tree?--Jillaine 07:26, 22 August 2013 (EDT)

Yes, I agree. "Easy" does not equal "better". WR is harder, yes. But it also attracts a better user, in my opinion. FS Family Tree is a garbled mess I would never touch. I've also never seen sources there, ever. It's just another grab bag like Ancestry.com's (unsourced) trees. WR's problem isn't so much that isn't this site or that site, but that the site admins (and not just minor ones like me) are not very responsive to comments/suggestions of users. There is an entire page of 'suggestions' that might get a comment here or two, but are not acted upon. Daniel Maxwell 11:48, 22 August 2013 (EDT)

Like Beth, I have information on both WeRelate and FamilyTree, but unlike Beth I much prefer WeRelate.
Both are wiki sites (as is Ancestry, although much more limited).
Both have garbage information (Ancestry is not alone.)
Both are collaborative sites (unlike Ancestry, despite their vaunted “sharing”). Collaborative sites let you clean up the garbage, and are probably the only way on-line genealogy will continue to survive.

As for ease of use, there are people who choose not to use WeRelate because of the need to do some typing rather than just click and save. That’s biggest difference I can see for all three. All three have learning curves, all three have areas of “clunky-ness”, although I still find WeRelate easier to use.

Points for WeRelate – 1) it’s way more open, allows way more information to be posted (Projects, Transcriptions, Articles, etc.);
- it’s more open in showing history of changes, the ability to navigate between pages (and different kinds of pages),
- it’s more open in that the format for your for “stories”, pictures, and so on is much less restricted; and in allowing user-developed templates and so on (quite a few good ones around, by the way)
2) a much better search engine to help you find people using a wide range of criteria (even if I have sometimes complained)
3) the ability to hyperlink between pages. This is critical when you research broad collateral lines, neighbors, communities, etc., for problem solving, and will become essential as genetic genealogy grows

Points for FamilyTree – It will probably last longer than anything else on-line. My first on-line postings were on RootsWeb when it was strictly volunteer, user supported. Much of that information is now gone. (Thanks, Ancestry) I also contributed, as did many other people, when something called MyFamily (I think) first appeared. Most of that information is now gone. (Thanks, again, Ancestry). If/when the craze for family research goes, Ancestry will fold, and take its information with it. The question is, will WeRelate have something that will make it survive?

Survival vs Competition
Ancestry publicizes “Discover your family story, it’s easy”.
FamilySearch publicizes “Make Connections, bring your family history to life, share a memory”
WeRelate publicizes "We're different"
WeRelate needs not just good information to survive, it needs “catchy” publicity, aimed specifically at those sectors of the population who can contribute the most to keep WeRelate surviving because of the quality of the information (the more informed, those with an interest in community genealogy such as genetic genealogists, local societies, etc.)
Because I think WeRelate really does have more to offer. I'd be willing to work with others, but it's not my area of expertise and age is beginning to slow me down.--GayelKnott 16:04, 22 August 2013 (EDT)

A good analysis, Gayel. I don't think, though, that WeRelate publicizes "We're different"; it seems to me WeRelate doesn't publicize anything. The impression I have is that WeRelate is a very quiet backwater of the genealogy internet. I was very surprised when I discovered WeRelate a year ago that it had been available since 2007 or so. I'd never run into it before, and I thought I was moderately well acquainted with the genealogy sites that were around. WeRelate is a quality site, and it's troubling that it has so little activity.
Without the support of a substantial community, it seems to me the future of WeRelate has to be in question. I'm sure the future of WeRelate is of concern to most of the editors here.
I'm not particularly concerned with "competition" with other sites, but they are alternatives and that means they have an impact on support for WeRelate. They won't be going away soon. FamilySearch has the long-term support of a theologically-motivated organization, and Ancestry is an effective monetarily-motivated organization. Ancestry has capably managed to eliminate its important potential commercial competitors over the years (mainly through buyout), not the least of which was the evisceration of the largely volunteer RootsWeb. ---Robert.shaw 20:53, 22 August 2013 (EDT)
With familysearch.org making many of the records that Ancestry publicizes available for free, how long will Ancestry remain commercially viable? How much help do they really give you to figure out things? Financially, it would not benefit them if you ever felt you found all the answers and stopped subscribing. They are the epitome of data, not information. Family Search has the captive audience but until they are willing to tell people they are wrong, the quality will never be good. I have spent time in Family History Centers and heard too many phone calls to Salt Lake City along the lines of one arguing about a name based on the grounds that "I am his son" and similar non-evidentiary reasons to believe they are ready to do the right thing (i.e., "OK, Mr. Doe, email me a copy of the birth certificate and we'll have the board review your claim"). Of course, WeRelate is a little lax about insisting on sources, too. It is only a small cadre of users here who are tediously documenting evidence that are keeping this site from irrelevance. It is sure not the pace of technological change here that gives WeRelate have much chance of continuing value.
Sorry, Gayle, you're wrong, it is exactly the quality of data, and nothing else, that can enable WeRelate to be meaningful. It has lost the battle of numbers (before it even started), and clearly it doesn't have the support structure to compete on a feature/enhancement basis. It is only if it is willing to make sources and quality "Job No. 1", that will enable WeRelate to be relevant as a shared (best efforts of many people) dynamic (reflecting latest research, not static like a published book or some dead person's research) reference (if it can provide data that is mostly right) site.
To Beth's point, don't fear the computer: no automated tool will make a difference: garbage in, garbage out. Until some person does the hard work of documenting evidence and doing detailed analysis, no computer can clean things up. Same with DNA. Expect no more from the computer than One World Tree, or treating the whole household as relatives. I'm sure organizations like Mayflower Descendants have a pretty good database of some reliability, but the difference is, they are not sharing it. This is what purpose WeRelate can serve, and be important if it accomplishes that. All other paths, it seems to me, lead to irrelevance. --Jrich 22:43, 22 August 2013 (EDT)
That is actually one of my greatest worries for WR - that it grows and gets sucked into either 1) a commercial entity, like Ancestry.com - and then goes behind a paywall or 2) that it becomes an off site for Wikipedia, a branch of it. We can debate the pros and cons of Wikipedia but there are a ton of problems with the site which I won't go into here. So more than just growth for growths sake or 'easiness' WR should just keep doing what we are doing, as well as strictly maintain WR's independence. Daniel Maxwell 23:20, 22 August 2013 (EDT)
I've been doing what I can - for a number of years - to make this place be the Wikipedia of Genealogy. It's the obvious way forward to a larger community of content contributors. We are legally and (substantially) technologically compatible. Instead of collectively shooting ourselves in the feet - kicking and screaming about how "we're not wikipedia" (even as we look for ways to update to the latest media-wiki release) - we should stop that self-destructive behavior and start asking the question of how we can thin out the border to the point of transparency. After all - it really isn't about "wikipedia" nor "werelate" - it's about a large open and free universe of information. Wikipedia isn't forever - and neither is Werelate. Other things will take over someday - but the body of information that has been brought together and usefully interconnected can and should carry forward - continuing to be improved - on whatever future platforms serve it up.
At present, we have correspondent pages for some 20,000 WeRelate Person to Wikipedia Biographical pages. Our place pages make use of something beyond 70,000 Wikipedia pages. In total, we're in the area of 99,000 pages that correspond on a one-to-one basis. --jrm03063 22:56, 22 August 2013 (EDT)
Hear hear, Jrm03063. I'm not that interested in whether or not WR becomes part of the WMF universe, so much as whether it can survive for (say) the next 200 years. (I'm only partly being non-serious.) I think the open model that we have here is far more likely to be resilient, because it doesn't really come down to any one group of people or one organisation or anything — I really want to work towards a way in which we're all free to get the data (and I don't just mean in Gedcom format, but in it's entirety and with all revision history) and do with it whatever we want (within CC-BY-SA of course). This, I think, is the massive advantage that we have over Ancestory et al.: we're here for the good of the data, not monetary profit. — Sam Wilson ( TalkContribs ) … 00:20, 23 August 2013 (EDT)
Yep - great point. In fact, this is one of my primary motivations for contributing here. Data on Ancestry or FamilySearch may very well go away if either of those organizations goes away. If WeRelate goes away, the data doesn't. The data can all be exported and moved somewhere else. I think that it's much more likely that contributions I make here will be accessible in 100 or 200 years than contributions made anywhere else. -- Jdfoote1 07:55, 23 August 2013 (EDT)
I see FamilySearch having three major advantages:
1) It is easier to use (for simple tasks) which has been noted already.
2) They appear to be automatically generating a lot of entries from their database of births, marriages, etc.
3) The sponsoring organization has a critical mass that is not likely to dissipate for a very long time.
But with these advantages come some interesting problems:
1) Their method of populating the database creates a large amount of duplicate entries for what are in fact the same people/families.
2) Although a lot of entries seem to have been automatically generated from their huge source databases, they did not bother to document the sources of these entries when they were created.
I think that in the short term (1) may be a greater problem, but over time a large team of volunteers (which they could probably muster) might clean things up.
On the other hand (2) seems to me to be a huge lost opportunity on their part to leapfrog the "competition" for genealogy mind-share. They could have built one of the best-sourced online databases out there but they missed the opportunity. If they had bothered to capture their sources for each of the entries they auto-populated in the database, this would offer me a huge incentive to go in and clean-up the duplicates and provide missing information for the people/families I care about.
As things stand I have to choose between having to expend a lot of energy adding sources to entries in WeRelate vs expending a lot of energy on cleaning-up and expanding the mess of entries on FamilySearch.
Bottom line for me:
1) I have a substantial personal investment of time in WeRelate, leveraged by substantial amounts of work by other WeRelate contributors, that I am loathe to walk away from.
2) Nevertheless I have serious reservations about how long my and other people's contributions to WeRelate will survive in Cyber Space.
3) As a backup I have gone into FamilySearch on a selective basis to clean-up the most problematic and puzzling parts of my genealogy that would probably be the most difficult for someone downstream from me to reconstruct.
--Jhamstra 09:55, 23 August 2013 (EDT)

What links here should open a search form [15 August 2013]

I'm thinking it would be most useful if the "What links here" were to open on a search form, similar to the form from the search widget at the upper left of the page.

For example, I would like to go to a place, and then return a list of Families or Persons (or whatever) that link to that place.

Every page has a "what links here". People, places, articles - everything - it's fundamental to media-wiki. But maybe what you mean is something that let's you do a "what links here" while working your way up or down through the place hierarchy. For example, when a person page references a place, you can go to the place and see the person page on "what links here". But if you go from the level of the town up to the county - you won't see a set of links for everything in the county AND enclosed places. Since it would be a merge of some readily available content - it seems like it would be very possible to do. However - the size of data domain becomes really huge really fast as you start collecting enclosed communities at the state/province or national level.

I understand completely why Categories are unmaintainable, unsustainable, but a filter like the existing search form provides could go a long way to towards the usefulness that categories might provide in theory.

The auto-generated categories are - I think - what you mean here. I'm more optimistic about categories where people have a real reason to maintain them.

I'm no programmer, but seems to me that a search would be structural, built into the site and so require little or no maintenance.

If not a full search, than even a simple filter by page type (All, Person, Family, Source, MySource, and so on) would be helpful to find more leads. Just a thought . . .--Gcrofford 00:03, 15 August 2013 (EDT)

If the lower-level "what links here" content could be grouped, it certainly seems like it could also be partitioned by name space - but there would definitely be some programming here.

Footnote text baseline [22 August 2013]

I can understand that the footnote number in the main body of the text needs to be a superscript number. However, in looking at text in the footnotes section itself, the text seems to be superscript as well. The text is smaller, and is not on the same baseline as the number or the arrow. It's elevated slightly. Is there a way for the footnote text to be the same size as the number and not slightly elevated? Parsa 21:59, 15 August 2013 (EDT)

It might help if you gave a page where you are experiencing this problem. Looking at your contributions, one of the last pages you worked on was MySource:Parsa/George Banks Muster Roll Cards. Things look fine to me on this page. I will make one observation: the baseline of the text is high enough to allow descending letters (y, g, p, etc.) to hang below the baseline. So the arrow, and the wikipedia GIF there appear to use the lower extent of the bounding box, not the baseline, which does kind of create the impression the text is slightly raised. But I think everything is OK if this is the page in question. --Jrich 22:44, 15 August 2013 (EDT)
Parsa, the notes on this page look just fine to me, too. I'm using the latest version of Firefox, and if you aren't, your browser may be interpreting things differently. Notes were deliberately set up to read this way -- non-superscript, on the baseline -- because that's the standard in all style manuals. --MikeTalk 11:55, 22 August 2013 (EDT)

Hmmm, I would have thought the bottom of the arrow and the image would be the baseline, and that descending letters would naturally drop below the bottom of the arrow. I measured a line using the bottom of my screen from the baseline of the footnote number to the bottom of the footnote text, and it still looks like the text is elevated very slightly above the number's base. If you look at this reproduced article on my website, you can see the same W icon, and it's actually above the baseline, not below it. In any event, most of the text on the site looks quite small to me (compared to other websites), and I end up having to zoom in to read the text clearly. (And I don't even have any serious vision problems. Many genealogists are elderly, and I imagine this might be even more of a problem for them.) - Parsa 11:47, 16 August 2013 (EDT)

You may be thinking in terms of hardcopy-book typesetting, where certain fonts do drop below the baseline. Computer fonts don't follow any of those design "rules," though. And the horizontal bar of the arrows is supposed to be on the midline. The arrowhead part is standard X-height. The "W" on your website page is actually resting on the baseline. The underscore for the preceding words is below the baseline. (Hence UNDERscore. . . .) --MikeTalk 11:55, 22 August 2013 (EDT)
I see what you are talking about. The image is not vertically aligned correctly. In newer versions of the MediaWiki software you can align images, but it looks like it's not possible currently on WeRelate. I know that Dallan is hoping to open source the software soon, so we can get MediaWiki updated. -- Jdfoote1 15:44, 22 August 2013 (EDT)

IRC? [23 August 2013]

Is anyone here ever in the IRC channel? I am sometimes (during UTC+8 daylight, anyway) but I've never seen anyone else there. — Sam Wilson ( TalkContribs ) … 00:37, 23 August 2013 (EDT)

Never noticed that we have an IRC channel. I will try and check back there then. Daniel Maxwell 00:38, 23 August 2013 (EDT)
I'm not on IRC much, but I'll try to hang out there some, too. -- Jdfoote1 13:45, 23 August 2013 (EDT)

Template CN (Citation Needed) [23 August 2013]

Please comment on this deletion request AndrewRT 13:18, 23 August 2013 (EDT)


Costs to upgrade MediaWiki version [30 November 2013]

There has been an outstanding suggestion to upgrade the version of software we are running for over a year. It is mentioned on that page as "one of the primary focus". My question - how much would it cost to perform such an upgrade and if we were able to get funding, would werelate be happy to do this via the paid developer route? AndrewRT 20:05, 21 June 2013 (EDT)

My guess is if we were to hire someone to do this, it would cost somewhere in the neighborhood of low five figures. I can't do it myself because I'm working fulltime on a consulting project until the end of the year. In the meantime I'm in the process of open-sourcing the complete WeRelate codebase so that others can help out if they want to: https://github.com/DallanQ/werelate-wiki --Dallan 22:38, 7 July 2013 (EDT)
Terrific news Dallan (re getting the source code onto Github). Well done! :-) I know how hard it can be to find the time to work on these things.
As for paying someone to get it all working with the latest MW, I think you're probably right. My feeling is that there might be enough of us genealogy-hackers around to perhaps get a fair bit done in say the next year... Are you around enough to point people in the right direction and advise and whatnot? Anyway, worth a shot via the open-collaboration route, before trying for funding etc.
But enough talking, I'm off to look through the code! :-) Thanks again. — Sam Wilson ( TalkContribs ) … 22:50, 7 July 2013 (EDT)
Yes, that's the plan and the hope. I'm going to cut back to four days a week on the consulting project at the end of this month and I'll use the extra time to add documentation and provide pointers to anyone who wants to help.
Another thing to consider is http://www.wikidata.org . Wikidata is an effort to create a collaborative structured database for Wikimedia projects. It's been under development since 2006 and is still not quite ready for prime time, but it appears close. Not sure if we should consider using it or not.--Dallan 23:14, 7 July 2013 (EDT)
Wikidata certainly looks interesting. You mean for things like place names perhaps, that are of general interest beyond genealogy? Will definitely be something to look into. :-) I have been wanting to do some sort of analysis of the links between here and Wikipedia for a while... — Sam Wilson ( TalkContribs ) … 23:41, 7 July 2013 (EDT)
Actually I was thinking of the possibility of using the wikidata extensions to manage the database of people, in addition to places, etc. We may not write to the same datastore that the official Wikimedia projects write to, but perhaps we should consider switching over to use the wikidata format at some point if it's going to become a standard for storing structured data on Wikimedia projects. I was thinking it may help us petition to become an official Wikimedia project someday.--Dallan 00:36, 8 July 2013 (EDT)
That looks pretty cool. It looks like there is a MediaWiki extension for Wikibase, which looks like it would put us in good shape for using WikiData? -- Jdfoote1 14:18, 10 July 2013 (EDT)
I've been investigating this group of extensions a bit lately, and am playing around with a system for dynamically importing (as in, it traverses family trees and pulls what it can) data and files from werelate. Nothing to show yet though! :-) I'll post on the WR software page if I have anything. — Sam Wilson ( TalkContribs ) … 02:45, 29 July 2013 (EDT)
I'm curious - do you mean that you're walking the werelate tree and trying to pull data into a secondary database? In this case, WikiData? --jrm03063 10:51, 29 July 2013 (EDT)
Yep, exactly that. Well, not that it's functioning yet in the case of Wikibase, but I've been doing the same for other uses for a while. Basically, selecting two or four people and fetching all their ancestors and/or descendants. — Sam Wilson ( TalkContribs ) … 19:13, 29 July 2013 (EDT)
For what it's worth, I've been thinking that an additional way to rationalize our membership in wikimedia would be to demonstrate that we're the most wikipedia-hip genealogy environment going (not just another user of media wiki software, but a cooperating user/contributor respecting content. So, as a personal goal, I'm trying to get us to the point of being source-attached to 100,000+ WP articles (we're presently at about 98,500). Of those, about 21,000 relate to people/biographical pages, while most of the rest are places. There is however, a small but very interesting and growing group that relate to things that make for sensible genealogical categories (Houses of Nobility, Battles-Campaigns-Wars, Civil War Regiments, and more). The idea for the last sort of thing is something Amelia had quite some time back, but I've tried to run with it more actively since the beginning of this year. --jrm03063 15:57, 10 July 2013 (EDT)
"Low five figures" sounds like a figure that could be raised from a mixture of a grant application (e.g. the Wikimedia Foundation), a fundraising among site readers and perhaps some sponsorship. Is that something you would be prepared to consider? AndrewRT 19:07, 12 July 2013 (EDT)

I've found my way back to this discussion of "Wikidata" - in the context of language neutrality. In past discussions of use of English Wikipedia - concerns were raised that other languages might provide better pages than English.

It appears that language-independent Wikidata human "objects" are the way that different language versions of Wikipedia relate biographies of common individuals. To my mind, this suggests that we might want to move from an English Wikipedia orientation for relating pages between WeRelate and Wikipedia - to something that relates pages between WeRelate and Wikidata.

For example, for Louis XIV of France, the English WP page is perhaps less desirable than the french. However, this wikidata page represents both. It's also easy to see why Dallan thought the database might be a particularly appropriate way for us to represent our database of people - since the Wikidata pages seem to represent genealogy simply be some ordinary properties.

Anyway - thought that this might be a useful direction to go for the many Person pages currently related to English Wikipedia. Perhaps what we really want - is to relate Person pages to the Wikidata object - and somehow indicate one or two preferred language forms for an extract? Or something like that... --jrm03063 03:38, 1 December 2013 (UTC)

An additional idea - since user profiles include a language preference (which is presumably recoverable as a wiki variable) - perhaps there's a natural way to dynamically provide users with Wiki extracts from their preferred language wiki? --jrm03063 22:05, 1 December 2013 (UTC)



Foul language on other's talk page [26 September 2013]

I have just had a new user add vulgar and foul language on my talk page over a disputed point on a family line. Although I have admin powers, it isn't clear to me how one should proceed on this, or if there is even a given rule about this. I would have never thought that a geneological website this would be a problem, but I guess it takes all kinds.--Daniel Maxwell 19:41, 4 September 2013 (EDT)


Mediation might be a good strategy, no matter how disruptive the dispute becomes.

If a particular genealogical issue has potential to be disputed, I think it needs to be recorded somehow. If werelate becomes successful as a go to reference, others are likely to rediscover the issue in future. It would save future wasted energy.

Good luck with that, by the way--Dsrodgers34 19:48, 4 September 2013 (EDT)

This was with a line I wasn't currently working on, but that isn't the point. The user was adding unproven information on an important line (Kenelm Winslow, the oldest known member of the Winslow line). In stuations like this, he should have made a comment on the talk page before making major changes and from there discussed it. But that wasn't my point in commenting about this here. I have had disputes with several other people on unproven/etc information, but they also don't leave disgusting language on my talk page over it. That is why I brought this up here, what WR policy is toward this kind of behavior. Daniel Maxwell 19:51, 4 September 2013 (EDT)
In theory, this is a matter for the oversight committee, but don't hold your breath...
With respect to the issue at hand - and presuming constructive engagement among the parties - a number of templates have been created to help mark things like this. Situations such as no known parents, no known mother, speculative relationships and more. So if the present state of the genealogical art does not offer an accepted set of parents for Kenelm Winslow, then you can mark his page as such. If one or more families are offered as possible, as a matter of speculation, then templates exist to indicate such tenuous relationships.
Speaking as one of the parties that developed the templates, we saw the practice of limiting decisions to absolutes as a potential (and pointless) source of conflict. Instead of forcing decisions to be absolute - parties should be able to indicate alternatives that represent reasonable speculation (not pure guesses mind you - but informed conjecture). Likewise, assertions about a negative state of information (the no accepted connection templates) - also represents a kind of information that we wanted to be able to capture. Perhaps the unfortunate situation here would never have occurred, if Kenelm had been marked as having no accepted parents with some backing documentation indicating as much. Then the person adding that information might have been on notice and been able to avoid possible embarrassment.
In any case, good luck.... --jrm03063 21:19, 4 September 2013 (EDT)
I am of course aware of the 'alternate' tabs, although still new. That isn't the problem. I want to know if users who use vulgar language can be warned/blocked/banned. I just about pre emptively banned him for it I was so upset. Daniel Maxwell 21:32, 4 September 2013 (EDT)
Also, I want to be able to keep his edit of my talk page but have that revision hidden to anyone but admins - at wikipedia this is called 'oversighting' but I am unaware of how that works here.
I found a precedent (from 2009) that says that profanity is not allowed on WeRelate, and the user was blocked. I fully support blocking any user who is verbally abusive. Abusive behavior is upsetting and harmful to emotional and mental health (as recognized by all workplaces I have been in in the last decade or so), and none of us should have to put up with it. If you want to see the precedent, search WeRelate for "profanity" and check out the Talk page hit - the profanity was posted by another person on this person's talk page.--DataAnalyst 21:56, 4 September 2013 (EDT)
Thanks Data. I take it then the user should be blocked now? I was uncertain of this because there is no clear policy as to length of ban, etc. On Wiki it is for set lengths. Daniel Maxwell 22:00, 4 September 2013 (EDT)
I don't know the policy. Try asking User talk:Beth - she did the block in 2009.--DataAnalyst 23:12, 4 September 2013 (EDT)

I have nothing to say on the language issue that others can't say better.

The use of UNKNOWN can come across as capricious and arbitrary. There are plenty of cases where the leading experts present facts for which there is no primary documentation and which evidence actually argues against. Family:John Parkhurst and Abigail Garfield (1) is one case. There are others. I guess this should really be John Parkhurst and Abigail Unknown. But I figure anybody that is serious about this couple will read this page, and so does it really hurt to leave it as it stands? There are many cases where an answer is accepted by some number of researchers, so not considered unknown, but in truth they are based on a string of coincidences that may at some point turn out to be wrong when new evidence is presented. So to me, that is the key: present the evidence. This goes for the people who want to make the hypothetical case, and the people that apparently don't like the hypothetical case. If you can't disprove it, maybe the better policy is just to add a note registering that some author in year xxx said that as far as that one author was aware at that time, the fact was unknown, or that so-and-so authority thinks differently. But assume a person that is really interested will read the page, and don't insist that your personal understanding is the only correct one to display. It seems to me the goal is to collect more evidence and get rid of the unknowns, not to erase possibilities that aren't wrong only to add unknowns.

Arguing against me, of course, is the fact that people put outlandish facts with no sources, and these kind of submissions are almost always wrong when confronted by the need for proof, making it very hard to argue that we should try to respect them. So I can't stress that all this depends on both sides giving the primary basis for anything they think is true and clearly labeling as assumption anything that is not fact. But as a guideline, I suggest: if you can't disprove it, leave it. Register your objection, but no more, until you can earn your right to change it by actually proving the right answer. --Jrich 23:26, 4 September 2013 (EDT)

I know. We've been over this before. I don't mind differing opinions - that's why we have those little templates for weak lines that some might want to note. But this doesn't apply here. What I objected to in that case was that he deleted the unknown earlier wife of Kenelm even though the later wife Catherine was probably not the mother and that is what is believed by the current Winslow knowledge. There existed a page for that marriage (since Catherine is named in his will), but with no children listed because Winslow researchers believe the children were by an earlier wife as I said. So it was the other way around - he deleted it for HIS vision and objected when I reverted it, then used foul language. But if this were merely a simple dispute I wouldn't be posting this here. WR needs a clearer policy on vulgar language and abusive comments, there was one example of this in the past from 4 years ago but nothing is set in stone. Daniel Maxwell 23:49, 4 September 2013 (EDT)

How to handle user behavioral problems is a thorny area, but one aspect about it is clear to me - the involved parties shouldn't decide on and implement any sanctions. An admin who is the target of perceived abuse should avoid taking action like suspension or banning as they often are too close to the situation to make a wise decision. Someone who is targeted by abuse should raise the matter with uninvolved admins or experienced users. Just how to do that, and to whom, I'm not sure, and what guidance about abuse issues they should follow is also murky to me. --Robert.shaw 02:04, 5 September 2013 (EDT)

I'd agree, except that WR doesn't have enough admins for a large body of people monitoring this kind of thing. This is actually the first discussion of this issue on the site at all far as I can see, so this might be a discussion worth having. It sounds as though there is no disagreement with blocking/banning of someone who does it, just on how to implement it. I have not taken any action except for removing the offending remark from my page (which for now is viewable in the history). Daniel Maxwell 02:07, 5 September 2013 (EDT)
Per User:Beth, who dealt with a potty mouth before, I have blocked the offender for 1 week and I will post a warning on his talk page. In the future, when a more clear policy is arrived at, I will put it in the hands of other admins Daniel Maxwell 07:52, 5 September 2013 (EDT)
I awoke to this situation this morning and started a private discussion with the Overview Committee regarding creating a policy for this type of behavior. There are a number of issues here the committee will need to address and clarify for future situations:
1. Abusive communication. This type of conduct cannot be tolerated and a clear policy needs to be created.
2. The action of admins reverting edits before engaging a user in discussion. There are times when reverting a user's edits is warranted, but I believe this process needs to be better defined.
3. I agree with Robert.shaw that "the involved parties shouldn't decide on and implement any sanctions". The manner in which we block users needs to be in keeping with professional standards. When a user is involved in the situation, they are not impartial.
I will post back here when the Overview Committee has drafted a policy. --Jennifer (JBS66) 08:27, 5 September 2013 (EDT)
Let me explain myself. I only reverted the first time, and right after posted a notice on said user's talk page. I assumed I would get a reply and we could discuss it. I only reverted again when he put back the changes I had just explained the problem with. I did not do it without comment on my part. I also hesitated to act myself. As I said, in the future, I am happy to let uninvolved admins do the blocking/banning (unless someone is asking me to help in arbitration). Daniel Maxwell 08:31, 5 September 2013 (EDT)
The primary issue here is, without a doubt, the abusive communication. That needs a strong policy and perhaps even a committee under Portal:Maintenance to help manage. I will make sure this happens, because no user deserves this type of treatment. Secondarily to this, I feel that looking at what may precipitate this type of outburst would be good. I am not at all trying to blame your actions for this behavior! Recently, I have seen a few instances where users with admin rights have reverted then posted on the user's talk page - and the results were angry and unproductive. I am just trying to look at the big picture, so that we can prevent and deal with abusive communication in the future. --Jennifer (JBS66) 08:46, 5 September 2013 (EDT)
You're kidding, right? It's just coming to you now that abusive communication and arbitrary edit reversion needs to be dealt with? --jrm03063 09:02, 5 September 2013 (EDT)
OK, thank you. The user was making other unsourced edits to other sourced pages (see comment by jaques just before mine), 'fixing' things by looking around on rootsweb and the like. Lines before about 1750 or so are some of the better sourced (if not best sourced) material on WR, and those of us that have worked on them get a little territorial especially when unsourced information is added (though I admit, I hadn't cleaned up the Winslow line yet). I had considered asking Dallan to consider some kind of user guide for new users in editing people born before the earliest date the GEDCOM upload will allow (1700?) - in other words, pages where the user has to create them by hand. Daniel Maxwell 08:52, 5 September 2013 (EDT)
Wikipedia has a page called ANI - Administrators Noticeboard / Incidents. Do we need the same here, or is this watercooler followed by enough Admins? Given that there are only 30 sysops on this site, is the easiest process just to contact a handful of them to take action? As to an Oversight Committee policy - would this really be useful, or should we just adopt wikipedia:WP:NPA AndrewRT 16:25, 5 September 2013 (EDT)
I don't think there will be many incidents to justify an entire section like WP, where this kind of thing is probably constant. We are not THAT big, in fact not even close. I think JBS66 is right, this should be part of the rest of the Portal:Maintenance and just another aspect of their job.

A policy regarding "Profanity and lewd language" has been added to WeRelate:Policy and linked to from Help:Wiki etiquette as well. The policy states "WeRelate is a family-oriented genealogy site. The use of profanity and lewd language is not allowed. The first offense will result in a 1 week block with the offending language being removed from the page. The second offence will result in a permanent block from using WeRelate. If a complaint is lodged with the Overview Committee, they will use their discretion to address the situation."

I've also added text on the Help:Administrators' guide asking users with Admin rights to refer requests for blocking to the Overview Committee so that an impartial team can address the situation. --Jennifer (JBS66) 14:57, 26 September 2013 (UTC)


Wikipedia updates [8 September 2013]

Will there be an update of places from Wikipedia tomorrow? I have been incorporating Wikipedia data to a number of English places in the past two weeks. Thanks. --Goldenoldie 09:57, 7 September 2013 (EDT)

For whatever reason, it hasn't run for at least a couple weeks. I wasn't pestering Dallan about it because the current wikipedia extract we're working off is pretty old (there are several hundred that didn't resolve the last time it ran) and we really need an overall update. Don't worry though - hooking things to WP when possible has such a great upside long term! I've made a career of this for the last four years or so. --jrm03063 10:32, 8 September 2013 (EDT)

In the past week I've found several WP entries that have been altered since they were originally downloaded to WR. These allow me to ask for {{source-wikipedia|place}} again, along with selective requests for the remainder of the article, now split into sections. So much for trivial bits of late 20th-century "history". --Goldenoldie 11:36, 8 September 2013 (EDT)


Swedish farm location type? [12 December 2013]

In Swedish genealogy, a country side location typically will include the "Gård", or farm that the person lived at. This is highly useful information as many records will be ordered by Gård, and it's also highly useful to distinguish people from each other as people tended to be quite unimaginative with names. The same place also will naturally recur many times in a family tree, so I do think these should be places, not just notes or comments.

(I have an ancestor whose father, both grandfathers, two great grandfathers and two great-great grandfathers were called Per Matsson or Mats Persson, all from just two farms in the same parish during the 18th century. It's quite confusing.)

So the question then is what location type to use for these locations? It's not a farm. Originally a gård would most likely have been one farm, but by the time the record keeping starts they are typically split into several farms. It's not an estate, because it doesn't have a single ownership. And in any cases none of these words are in the list of location types anyway. It's not a village, because although the houses tend to be located together, it's usually just a question of three-four houses.

The Swedish word "gård" comes from proto-indo-europan *gardaz, meaning "enclosed area", but I don't know if that helps either.

Here you can see how one of these places look i real life.

Any opinions on this? --Lennart 08:37, 9 September 2013 (EDT)


My commiserations. My family comes from a rural area of Scotland that has the same kind of divisions (and the same lack of creativity in naming children). When parishes or townships or areas of other parts of the world are fairly large, it would be handy to have another level of "place". Nineteenth century censuses can show numerous individual dwellings on a single farm. --Goldenoldie 11:21, 9 September 2013 (EDT)


The gård sounds fairly similar to the Irish townland - a subdivision of the large parishes that isn't its own political or administrative entity, but does tend to be used as the basis for organising many of the records. Townland is allowed as a place type and many Irish townlands have place pages on WeRelate - on my own tree I know I've linked to several townlands, including: Place:Skirteen, Monasterevin, County Kildare, Republic of Ireland.--RichardK 11:55, 9 September 2013 (EDT)

I have some familiarity with this, and I do agree with Lennart that a gård distinction can be very helpful in differentiating between individuals and that Swedish records often group individuals living in the same gård together within a parish or locale. However, I am not sure it is necessary to give each gård a separate place page. I think it is just too small of a designation that only applies to a handful of individuals. Saying that someone lived in a particular gård is not much different than saying that they lived on a particular farm or small group of farms or on a particular block. I am curious why the desired differentiation can not be accomplished by putting the gård in the description field or the "name suffix" field in the same way that it is done on other pages (i.e. saying "of Beverly Manor" or "of Pike's creek")? --Cos1776 13:24, 9 September 2013 (EDT)

Indeed, a Townland seems very much like the same subdivision, and is of a very similar size, judging from this and this list of townlands.
We *could* put this into the description field, but it is a stable division that doesn't change much over the centuries. The "handful" of individuals are indeed less than a thousand in recorded history per gård, and of course it's not likely that we record the full history of a parish like that any time soon. But as an example, in the GEDCOM I have that's waiting for review there are 38 individuals, and Uddvide, Grötlingbo appears 14 times, Ronnings, Grötlingbo 13 times. For some individuals it appears twice, as the both die and are born there, but still. (The extended tree for Gotland I'm using as a base for my research contains 247 people born or died in Uddvide, btw).
However, I think the more important question here is searchability. You can search for persons on location, but not on the location description.
I'll defer to the general view of this here, but using Townload as the type would probably be acceptable. --Lennart 14:02, 9 September 2013 (EDT)
I have a similar situation to Goldenoldie - my ancestor's family are from Place:North Ronaldshay, Orkney, Scotland, where the so-called "House" was routinely used as the location for people, often contained several households and is actually a very useful tool in tracking family histories. Indeed in North Ronaldshay there are examples of people like "Person:Thomas Tulloch (36)" from Garso who was normally referred to as "Tommy Garso". Can I ask the question the other way round - what is the rationale for the current restriction on places to aggregations above a particular size? AndrewRT 15:43, 9 September 2013 (EDT)

Norway is similar to Sweden, and as far as I can tell, a Municipality in Norway (which appears to be the smallest division currently recommended in WeRelate) is not necessarily like a city in North America. It might be a city, but in rural areas, it is more like a township. I believe that it is the smallest division with an official administrative body (which I assume guides WeRelate policy), but I don't think that that is sufficient reason to make it the smallest division in WeRelate place pages. For one thing, tax lists have been organized by gård (see this example from 1950), making them of at least some administrative importance (at least as much, for example, as a census division, which is supported in WeRelate). I would like to see the gårds added as well - for the same reasons as given above.

I would draw the parallel with the Town of Hempstead in Nassau County, New York (which appears to me to be like a township) which includes many villages and hamlets (although you can't see that in WeRelate, because each hamlet or village just says that it is also in Nassau County). These villages and hamlets have their own place pages - not necessarily because they have/had their own administrative bodies (although they may have), but because they show up on maps, in VRs, etc.

As for the number of people living in a gård - there can be anywhere from 2-3 families to about 40 families - easily as large or larger than many of the villages and hamlets in North America that are recognized in WeRelate with their own place pages.

Lastly, there are at least 2 more-or-less authoritative sources for the list of gårds in Norway. A list begun by Oluf Rygh in the late 19th century (Norwegian Farm Names) is considered a standard, and there is also an updated version from the draft land registry of 1950 (link above).

I would also like to see a place type of "Gård" added, so that we don't have to characterize these as "Townlands". It would help to show that WeRelate is aware of other parts of the world besides the English-speaking world.--DataAnalyst 21:33, 9 September 2013 (EDT)

Gård has been added to the list of place types.--DataAnalyst 03:27, 12 December 2013 (UTC)
Note: People interested in this topic might also be interested in the discussion on place page names for Norway, as there appear to be similarities between Norway and Sweden.--DataAnalyst 03:30, 12 December 2013 (UTC)

Importing early ancestors [13 September 2013]

I just noticed this:

"The Early column is checked for people born 1750 or earlier. Early people are excluded from GEDCOM import."

Ho hum.

"WeRelate already has wiki pages for many early ancestors"

Yeah, that may be, but not for mine. Or is this site only for Americans?

OK, fair enough, these early ancestors often have bad sourcing, but I think the exclusion in that case should be for people who have no sources, not because they are early. --Lennart 17:16, 9 September 2013 (EDT)

This was a big problem when the site first started. Worsening GEDCOM duplicates of Mayflower passengers or other early immigrants were piling up badly, and when people who didn't know what they were doing merged with someone elses you ended up with a jumbled mess. I still run into these on occasion. But jrm03063 is probably right that certain instances it should be able to get waved when approached by an admin, but I still think our policy on this is the correct one. Daniel Maxwell 14:10, 13 September 2013 (EDT)
There's actually more reasons than simply the past transgressions of various GEDCOMs creating a bad impression. The further back you go, the more researchers you potentially intersect with, and the more appropriate it is to be careful in entering data. And of course, yes, everybody think their sources are appropriate. People that use no sources don't think they're necessary, people that use bad sources do so because they think that's all that needed. In previous discussions, no way to automatically assess source quality could be settled on. --Jrich 19:28, 9 September 2013 (EDT)
I am emphatically opposed to deleting unsourced people pages. Working on early New England families, I have often found data, usually from drive-by gedcoms, which is accurate but unsourced. If the source is relatively easy to find and add, it seems counter-productive to delete it only for some one coming along days or years later to have to start over. Even in cases where the sources aren't apparent (just because we don't know about a source does not mean it does not exist), the data sometimes furnishes clues which are helpful in putting families together.--jaques1724 20:35, 9 September 2013 (EDT)
different topic, I think. --Jrich 23:41, 9 September 2013 (EDT)
Definitely different topic, but might be worth bringing up. IMO unsourced people who has had no edits since import could be deleted. The information is typically easily found on other sites. But, no biggie. --Lennart 14:35, 13 September 2013 (EDT)
I agree with jaques. Eventually hopefully someday somebody will come along and clean up all those pages. But they are part of families that have been linked to, so form a junction in a big mesh that is our unified tree, and to create holes by deleting them is just as disruptive. For example, when somebody deletes their tree, it will often delete 2 or 3 children out of a family of, say 8, leaving the family incomplete, etc. Also, occasionally, the source is posted on the family page, and so it's there, just in a different spot than might be expected. Better to let the cleanup on existing problems be done in a thoughtful, careful manner, just limit the amount of new problems that can be created as much as possible. --Jrich 16:20, 13 September 2013 (EDT)
I'm pretty sure that any of these policies can be waived if someone thinks they have a special situation, or their GEDCOM content is particularly well done. The policies represent what seems to be good practice in the general case. Folks should feel free to appeal if they think it appropriate. --jrm03063 11:25, 10 September 2013 (EDT)

Help with a Transcript [10 September 2013]

I'm making my first attempt at creating a Transcript page and am not really clear on the most efficient/useful way of doing it. I'd appreciate it if some of you who have experience with transcripts would take a look at the initial part and provide suggestions on how to improve it.

Transcript:Biographical Sketches of Graduates of Harvard University, in Cambridge, Massachusetts:Wise, John, 1673

--jaques1724 23:00, 9 September 2013 (EDT)

I would be happy to help. Let me know where you want to converse... --jrm03063 11:27, 10 September 2013 (EDT)
[7]. --Jrich 11:51, 10 September 2013 (EDT)

New logo [12 September 2013]

What happens next with the Logo Suggestions? AndrewRT 17:03, 10 September 2013 (EDT)

The next step is a vote, but I will bring this up at the Overview Committee meeting on Sunday. --Jennifer (JBS66) 08:05, 12 September 2013 (EDT)

WR needs clarification of the 'Famous person' living exception [26 September 2013]

I apologize if this was discussed elsewhere, but I couldn't find anything in a quick search. I noticed that several siblings of President George HW Bush were tagged as speedy delete, which I have deleted. But I think WR needs to clarify what persons fall under the famous living person exception. Being the brother or sister of a famous person doesn't seem like a good enough reason, but this isn't defined anywhere I noticed. I suggested something else related to this to Dallan, but I want to bring it up here. Person:George Bush (2) has an ugly 'after 2010' in the death section so he could be added. Could this instead be replaced by a 'famous person' tag which will then enter him and anyone else with it into a category so it can be checked to be certain the person meets WR's criteria for 'famous'. Merely having a wikipedia page doesn't seem like a good enough rule for famous but before I go on a deletion spree of the siblings/nephews of George Bush I want to be sure.--Daniel Maxwell 13:54, 13 September 2013 (EDT)

When you say "clarification" do you mean that or do you mean "change"? My understanding was that the rule was clear cut: no living people unless they have a Wikipedia page. The rationale is simple: the website excludes living people in order to protect privacy. If you are the subject of a Wikipedia article then the information is already in the public domain so there can be no objection to having the information on here. Adding an extra rule trying to define "famous" would be a futile exercise and just lead to endless disputes. What possible advantage could there be in deleting this information? All it does is degrade the quality of this website and annoy the people who have spent time adding it in the first place. AndrewRT 16:47, 13 September 2013 (EDT)
I don't see anything 'clear cut'. In fact I see zero actual stated policy. I am not suggesting deleting George Bush, British royals, or other clear exceptions obvious at all. But what about border line cases? Brothers of famous people, nephews, etc. What about their spouses and children? Many of them are not considered notable enough for wikipedia, why here? And I also don't like the idea of being wedded to the hip of wikipedia policies. Alot of people on Wikipedia I do not believe are famous enough for their public information to be widely known and discussed. A wikipedia article is a pretty low bar considering what passes for 'notable' over there. But assuming that they are, why are non notable nephews of George Bush to be left intact? Daniel Maxwell 16:54, 13 September 2013 (EDT)
I think that the Wikipedia policy explained here makes a lot of sense for us to adopt as well. They say that people's private information (e.g., birthdates) should only be on WP if that information has been widely published or if the person has made it clear that they don't mind that information being known.
Wikipedia has a much larger community, and receives a lot more scrutiny. I definitely don't think we need stricter criteria than they do, and I think it makes a lot of sense to piggyback off of the natural scrutiny that pages there receive (especially pages about living people) - I vote that our criteria for including living people is that person must have a Wikipedia page with a birthdate. That seems both straightforward, and easy to "enforce". -- Jdfoote1 17:08, 13 September 2013 (EDT)
We are not a branch of Wikipedia. Let's get that out of the way first off - not to mention that Wikipedia condones the storing of large amounts of porno on their commons site - including some absolutely unspeakable images. Wikipedia is not a good example of a 'responsible' site. But let me given an example related to my point- perhaps a certain author, or military personnel, or reporter, notable enough for wikipedia - can we really say that some of the Generals added there are notable to have the names of their spouses, children, etc added to WR? +
Actually, this is a sidetrack about my actual point in my first post that AndrewRT flipped out over. Are the non notable siblings and relatives of Presidents now OK here? That is all I was talking about deleting. If there is notability, it should be on a case by case basis. Daniel Maxwell 17:16, 13 September 2013 (EDT)
I start to see the issue. I was just looking at the father of the Duchess of Cambridge. While he doesn't have his own WP page proper, he is discussed explicitly in a section on her WP page. So being absolutist about whether there is or isn't a WP page may be missing the mark a bit. But it does get dicey if we start letting people make an argument on a case-by-case basis. What if the requirement is that there be a WP page dedicated to the person, or that contains discussion of a person's genealogy - and further - that such WP page be provided as a source in support of a death fact/living person exception? --jrm03063 17:51, 13 September 2013 (EDT)
See this page as a for example - Person:Michael Middleton (3) --jrm03063 17:56, 13 September 2013 (EDT)
On the other hand, the page for his father seems more problematic. --jrm03063 18:01, 13 September 2013 (EDT)
It's quite possible that this is one of those things that was discussed to the point of a conclusion - but nothing was ever recorded in a way that we're able to find just now. That said, my understanding is that the only exception is for people with a Wikipedia page - and even then - the only thing we allow is the mechanical extract of the wikipedia content. When I've created such pages, I leave the death date and place empty, but add a description to the death fact that says "wikipedia notability excepetion". I suppose we should get this policy written down somewhere, and I should go back turning those descriptions into a template that takes people to a policy statement... --jrm03063 17:25, 13 September 2013 (EDT)
I think that it's simplest to understand and enforce if it's a hard and fast rule - living people must have a WP page of their own in order to be included here. -- Jdfoote1 17:59, 13 September 2013 (EDT)
But then it can ONLY be for that person. That is what I meant by case-by-case. General so and so's wife is not famous, and neither are his children, or his possibly still living parents. That is where I see the problem and where I believe it steps into invasion of privacy, or could. Under this rule, GWB's nephews are not famous and will be deleted unless they become notable in their own right. Daniel Maxwell 20:47, 13 September 2013 (EDT)

The policy is at WeRelate:Policy#Living People, and says;

Information on living people will be removed unless the person is a notable individual documented on Wikipedia whose shared ancestry is likely to be of interest to the community. (This exception is used primarily for heads of state.)

There is this guidance, which is similar but not the same, on Help: Person pages:

The exception [to "no living people"] is for famous and notable people whose ancestry is of interest to the general public. The general rule of thumb is that if someone has a Wikipedia page listing their birth information and/or parents, a WeRelate page may be created for them. This exception is used primarily for heads of state.

So having a Wikipedia page is a prerequisite, but they also need to be someone "whose ancestry is of interest to the general public." There is much discussion from 2006 to 2012 at WeRelate talk:Living people.--Robert.shaw 18:13, 13 September 2013 (EDT)


I'm going to chime in since I'm pretty sure I wrote both those help pages ... they express the original rationale for the exception that's described above: there's no point in deleting information about (originally, extremely) famous people who happen to be living, and a greater benefit to leaving it because it shows the common ancestry people might be interested in. The policy was defined when it was pretty much only used for Bill Clinton, the George Bushes, and Queen Elizabeth. I didn't expect at the time it would be as widely used as it is now (hence the head of state reference), but that goes to show that different people find different lines interesting. Since it's no longer true that the exception is used mostly for heads of state, that should be deleted.

While ideally I would argue that interest in the ancestry should also be its own criteria, as a practical matter that's impossible to enforce. The only way to have a clear enforceable rule that is something other than allowing or banning all living people is to refer to some external standard to define what's famous. Wikipedia, faults included, is the best thing I can think of -- it's readily accessible to all, it covers all types of famous people, it has a policy on this (that's arbitrated by far more people than we are), and it's constantly updated. It also has a benefit of making this a very easy question to answer--George W. Bush's siblings and one nephew get pages, if people so desire to create them. In relatively rare cases like the Duchess of Cambridge where there are living parents/grandparents not themselves famous, they can be links in the chain listed as "living" for now.--Amelia 01:35, 14 September 2013 (EDT)


I don't have anything more to offer on what the policy is or ought to be, other than running with an idea from User:DMaxwell to provide a common practice for labeling the situation. See this template and this category. Check out any of the pages listed in the category for examples of use of the template. --jrm03063 09:04, 14 September 2013 (EDT)


The Overview Committee discussed this today. The exception to the living person policy is only for people who themselves have a page on Wikipedia (on any of the language versions). The exception does not extend to living people who are mentioned in a Wikipedia article. In the example given above for the Duchess of Cambridge, she would have a page on WeRelate since she has a page on Wikipedia. However, her parents would not have pages on WeRelate. WeRelate no longer allows empty placeholder pages titled Living - so it is advised to place a link on the Duchess' page to her grandparents' page in the free text field as well as a link to her page on her grandparents' pages. This follows the policy that states "If you would like to link pages to others that would otherwise be linked through living people (in-laws with living children, for example), do so by creating direct links in the body of the pages. Do not put information about the living people on the pages."

I have not heard of any requirement that "the only thing we allow is the mechanical extract of the Wikipedia content." I will ask Dallan for clarification on this. --Jennifer (JBS66) 10:30, 15 September 2013 (EDT)

I encourage the committee to review this category. It collects Person pages of the living that I have found, entered by a variety of folks (oddly enough, mostly NOT me...). A number will be found to be without directly corresponding WP pages - but none of them strike me as an intrusion upon privacy. I expect to continue my search and tagging efforts.
My memory as to whether anything other than a mechanical extract is allowed may very well be flawed, as it may simply be my imperfect memory of a good way to prevent misuse of these exceptional pages for the living, and not a policy as such. --jrm03063 20:15, 15 September 2013 (EDT)
The policy states there must be a corresponding WP page for the living person exception. I wonder if it would be wise to add a few parameters to the exception template, namely the page title and language version. Then, the link in the death field could go to WP. The page could still be placed in the FamousLivingPersonException category, but there would be only one link to it on pages instead of two. --Jennifer (JBS66) 08:44, 16 September 2013 (EDT)
I'm not usually in favor of revisiting policy, but this is a case that may be justified on grounds of improved information on the issue. In particular:
  • We now know that the domain we're talking about is relatively small (the current category is just shy of 100 - assuming we double that - it's still pretty small).
  • It's clear that WP won't have a separate page for every person that is openly discussed. Spouses, parents, and other immediate family of a really famous person are often very explicitly discussed in WP - even though they may not justify a WP article in their own right.
  • The value of being able to add pages for a famous person is going to be seriously diminished if we can't also allow entry of linking people that connect to that person to their genealogical past.
I'm not going to try to suggest exactly what the policy really ought to be - beyond the (it seems) generally accepted principle that we should have a common practice for marking this situation. At present, I'm working through the category to see how many don't have their own exactly corresponding WP page. I'll bring those names forward when I have them for wider review. --jrm03063 15:44, 18 September 2013 (EDT)
Ok, I've walked the entire category, adding WP sources where needed, and all I've come up with is Person:Michael Middleton (3), (comment added by User:Jrm03063)

I'm glad that the Oversight Committee has given us a definitive policy on this now - as I said before, the main risk is that the website infers that a category of pages is acceptable, someone like me comes along and adds them and then some time later someone else comes along and deletes them because they have interpreted the policy differently. Now I hope we can all agree to implement the policy that's been agreed.

It's a pity, however, that Jennifer's explanation of the policy chose a bad example that was factually incorrect: "In the example given above for the Duchess of Cambridge, she would have a page on WeRelate since she has a page on Wikipedia. However, her parents would not have pages on WeRelate". Actually, Wikipedia has pages for both at https://en.wikipedia.org/wiki/Michael_Middleton and https://en.wikipedia.org/wiki/Carole_Middleton. Perhaps you can clarify what you meant by this - should we follow the words of your agreed policy or the specific example you gave?

As for her grandfather Person:Peter Middleton (3), he is clearly allowed on WeRelate as he died in 2010. The key thing about this family is that they are a notable family in their own right as they are descended from minor nobility, hence the interest in their ancestry. AndrewRT 20:57, 26 September 2013 (UTC)

Sorry, slight correction: Based on this discussion it seems that there are divergent views on Wikipedia as to whether or not they qualify for separate pages and the situation is currently still fluid. AndrewRT 21:14, 26 September 2013 (UTC)
When I wrote the above message it was factual ;) I checked WP to make sure pages did not exist for Michael or Carole. At that time, I am certain they were both redirected to Catherine's page. It's odd, because Carole's history on WP says it was un-redirected before I wrote the post. Anyway... it would be correct to follow the words "The exception to the living person policy is only for people who themselves have a page on Wikipedia (on any of the language versions). The exception does not extend to living people who are mentioned in a Wikipedia article." --Jennifer (JBS66) 21:25, 26 September 2013 (UTC)

Tree Delete Nomination [2 October 2013]

Been a while since I found anything quite as unhelpful. The GEDCOM upload of User:Wuiske on 7 Jan 2008 - not a large one - but seems uniformly disconnected and utterly unhelpful. I could delete it by hand on my own, but the few dates that it has put it outside the medieval spaces where I'm usually operating. --jrm03063 03:09, 15 September 2013 (EDT)

This tree also contains a large percentage of pages without dates, many of which may be living. Since these types of pages would be rejected in current GEDCOM upload standards, Dallan will delete the tree and inform the user. --Jennifer (JBS66) 10:32, 15 September 2013 (EDT)
The tree has been deleted.--Dallan 02:33, 3 October 2013 (UTC)

Too many DAR GRS Source pages [6 November 2013]

Please excuse this post if this has already been discussed elsewhere. I could not find mention of it.

I have been noticing that there are a lot of different source pages which all seem to be for the same source, namely the online DAR Genealogical Research System, so I did a little search and came up with the list below. It looks like all parties were going for the same thing, but had slightly different approaches and used different page titles which resulted so many duplicates.

What are the opinions on combining them ALL (yes, I did say "ALL") into one source page and what is the favored approach? This may cause some waves with some of the originators, but others seem to have moved on.

Did I miss any? --Cos1776 01:09, 20 September 2013 (UTC)


Well, "Applications for membership" seems more specific than the others. But otherwise, yes, merge. --Lennart 09:27, 20 September 2013 (UTC)

WELL! Please excuse me - I've merged the two "Genealogical Research System" sources and opened a discussion on this below. I'm not sure whether the Descendants database is really the same as the list of ancestors. I also seem to remember seeing a note somewhere that Applications for Membership do not appear online (and some of that material, which may be ordered, remains copyright to the DAR who explicitly refuses having it reproduced on line). So hmmmm! --jrm03063 15:30, 6 November 2013 (UTC)

Signing in [21 September 2013]

Until yesterday it was usually the case that one sign-in was enough for a day. Suddenly I am having to sign in every time I reopen my browser. This is a bit of a pain, but, okay, security is security. HOWEVER, I was just leaving a message on someone's talk page, went to preview it, and was told I had to sign in before editing. The message, which I had spent 15 minutes on, has disappeared. Grrr. --Goldenoldie 10:30, 21 September 2013 (UTC)

What browser & version are you using? --Jennifer (JBS66) 10:37, 21 September 2013 (UTC)

I am experiencing this as well using Chrome. It used to only happen when i stepped away for several hours which was understandable, but yesterday it was happening every 15 min or so. I feel your frustration goldenoldie. My workaround to avoid losing text is to open a new tab or window, sign on in the new window. Then go back to the old window, hit the back button and an alt-p (preview) and you should be able to continue editing. This is not a fix (which is still needed), just a salve to help you avoid losing your work in the future. Best wishes! --Cos1776 13:19, 21 September 2013 (UTC)

I've alerted Dallan to this problem. --Jennifer (JBS66) 13:24, 21 September 2013 (UTC)

I am using Firefox, latest version as far as I know. So glad to know I'm not the only frustrated one. Speed of upload has improved as the day wears on. (I am in the UK so I have been using WR for 8 hours already today.) --Goldenoldie 14:25, 21 September 2013 (UTC)

On another issue, Dallan said some hardware was changed out recently, perhaps some configuration wasn't quite preserved. There seems to be some changes with patrolling too. --Jrich 15:00, 21 September 2013 (UTC)

Problem with images? [22 September 2013]

Is anyone else having issues with some images loading? Like [Image:LibraryBook.GIF] or [Image:Letter from Fanny Cook to Catherine Munday, 29 November 1875, page 2.png]. I'm getting 404 errors for both. (The actual image files, I mean, not the description pages.) Most other images are working though. — Sam Wilson ( TalkContribs ) … 01:05, 22 September 2013 (UTC)

At least I now know it's not my computer or server. Lots of problems with loading thumbnails -- presumably to be fixed soon?
Of greater concern, I can't get the Duplicate families report -- it's "Not Found". --GayelKnott 01:33, 22 September 2013 (UTC)
Well, the site seemed altogether down for a while there. When systems come back up, they sometimes don't immediately return with their full complement of filesystems. It's pretty easy for me to believe that images live on a different filesystem from the wiki database proper. Other reports? Also possibly somewhere not currently up/accessible. So I'ld say hang in there for now... --jrm03063 01:44, 22 September 2013 (UTC)
Search server also seems down - so if you can tear yourself away - it's probably time to call it a night... :) !
Yes, let's see what happens in a few hours or tomorrow. I assume Dallan knows what's up? As for calling it a night — I've only just had breakfast! ;-) Sunday morning in WA... — Sam Wilson ( TalkContribs ) … 01:52, 22 September 2013 (UTC)

Thanks for the Wikipedia Update! [9 October 2013]

To Dallan et. al. - thanks for the wikipedia (WP) update of 9/22. It hadn't run for several weeks and the accumulated backlog of pages waiting for a WP extract was approaching 500. So let me start by saying I'm most appreciative...

However...the extract we're working from is getting a bit tired. Even after the refresh, 120 "source-wikipedia" templates were not resolved. Also, more and more I'm starting to notice that useful internal cross-links aren't resolved. By that I mean - if WP page "A" is extracted and has a reference to some yet-unreferenced page "B". Then, we add a new correspondence that creates a correspondence for "B". The extract present on "A" doesn't get the local cross link to "B" until we perform the full update. It's possible that there's value in having an intermediate WP update to pick up such cross-links - even if we don't go to a new full WP extract (I defer to those who do that work to know whether it's just as easy to do the full update with a new extract).

So thanks again, and please forgive me for asking for yet more! (BTW, our overall correspondence set w/WP is approaching 100,000 - which starts to make us look like we're serious about making use of WP content. I don't know of anyone else that has tried to bring open scholarship like this into genealogy on this scale - between WR native content and integrating WP content. I really think this matters - but then, I always did...). --jrm03063 14:35, 23 September 2013 (UTC)


I would like to second the vote of thanks for the wikipedia update of 9/22. My personal backlog of place pages was about 100--yesterday my email letter box was very large.

A couple of things I noticed: (1) distances appear to be coming across from Wikipedia to WeRelate--is this the end of place A being "about south of" place B? Sure hope so. (2) sometimes the Wikpedia page writers change their titles between our making an original request and the time the request is acted upon (for instance, writing separate sections for "History" and "Geography" when we had noted a single section entitled "History and Geography". In this case the update cannot be made--and worth checking if a section update is still sitting there untouched after several months. --Goldenoldie 19:47, 23 September 2013 (UTC)


New Logo Suggestions - please vote [19 January 2014]

It was suggested back in July that WeRelate could use a new logo. The Logo Suggestions page was set up to collect ideas. Now, we would like to put this to a vote. Please take a moment to view the logo ideas at Logo Suggestions. Then, sign your name here to vote for the logo you would like to see represent WeRelate. Please note that due to attribution requirements, the final logo may need to be tweaked a bit. --Jennifer (JBS66) 13:47, 26 September 2013 (UTC)


  • Votes for Single Tree
--Lennart 08:24, 29 September 2013 (UTC)
  • Votes for Collaborative Forest

I wish I could see where to sign my name. My vote is for Collaborative Forest--if the belt was deeper and more visible. --Goldenoldie 09:50, 29 September 2013 (UTC)

  • Votes for Delijim's Suggestion
--Jhamstra 16:37, 26 September 2013 (UTC)
--Cos1776 18:43, 26 September 2013 (UTC)
--Q 19:53, 29 September 2013 (UTC)
--User:janiejac Though the tree could be just a tad smaller; but NOT small like 'single tree'.
  • Votes for Relating
--AndrewRT 20:40, 26 September 2013 (UTC) My choice (assuming I can't vote for my own), although as per Jrich, I would prefer they were narrowed down and then iterated.
  • Votes for Sharing (color)
--Daniel Maxwell 22:34, 26 September 2013 (UTC)
--Lidewij 08:11, 29 September 2013 (UTC)
  • Votes for Sharing (gray)
  • Votes for keep the original logo
--RichardK - I'm not particularly inspired by any of the suggestions. The current logo may not immediately shout 'genealogy' at you, but it's distinctive, bright and slightly eccentric. I say stick with it unless and until someone comes up with something truly worth changing for.
--Prcb 17:46, 19 January 2014 (UTC) I actually kind of like it, it's abstract, simple, and active. The very clean look of WR is enhanced by this logo. I'd vote for change if an alternative were a clear improvement.
  • Votes for none of the above
Nothing strikes me, nor do I think the old one great. No real ideas, I might combine Relating (interconnected) and Sharing (puzzle) ideas? --Jrich 19:46, 26 September 2013 (UTC)
I do want to express my appreciation for the efforts invested so far, but I don't feel like we're there yet. I would rather see the interested parties continue to work the issue. Changing when we're not ready - leading to another change too soon - would be very unfortunate. --jrm03063 23:04, 26 September 2013 (UTC)
While I did vote, I do think this could use some more work. A ton of other genealogical sites use some kind of tree/branch/forest for a logo. I cannot say I am a fan of the 'pawns' logo, either though. Daniel Maxwell 02:44, 27 September 2013 (UTC)
Agree with users Jrich and jrm 03063. --Beth 00:07, 27 September 2013 (UTC)
I prefer to keep the existing logo while we keep working on something unique to WeRelate. --Susan Irish 17:25, 28 September 2013 (UTC)
Ditto. I like the idea of Relating (prototype), but it is definitely a prototype, and doesn't suggest genealogy. The Trees, however trite, are recognizable as genealogy. So, relating (connecting), collaboration, and quality -- all in one? --GayelKnott 18:59, 28 September 2013 (UTC)
I agree that we aren't there yet, but I think that we can't just let things die here. I think that almost any of the suggestions would be an improvement to the current logo, but I think that it's not worth changing until we've found something we love. My worry is that we'll just push this off forever. How do we move forward to actually get closer to a new logo? -- Jdfoote1 20:23, 28 September 2013 (UTC)
I suggest we leave it open for a couple more weeks to let everyone have their say and then see what the verdict is, although the current prevailing view seems to be that more work is needed. AndrewRT 20:49, 29 September 2013 (UTC)
--Artefacts 03:49, 10 December 2013 (UTC)"Sharing Genealogy" and "Sharing Genealogy Through Collaboration" could be tighter: "Collaborative Genealogy" or "Genealogy Collaboration". Or, there is an opportunity to really globalize the site with "The World Family Tree" as the second line, like how Wikipedia has "The Free Encyclopedia". If that is considered taken, maybe "The Free World Family Tree" of "The Free World Genealogy"? The font in the wordmark seems slightly less professional than possible, given that Wikipedia itself uses an open-source Libertine font: http://en.wikipedia.org/wiki/Logo_of_Wikipedia. To get people to fully associate WeRelate with the idea of a wiki like wikipedia (an online collaboration that goes beyond a database and includes articles), I would go with an all-grey logo and the puzzle piece does seem to draw that association as well -- is it possible to take the puzzle piece globe from wikipedia and stick a tree on top of it?

--Artefacts 05:18, 10 December 2013 (UTC)I don't have Adobe Photoshop c5 but if somebody does: http://psd.tutsplus.com/tutorials/3d/create-a-spherical-3d-puzzle-with-photoshop/ --Artefacts 06:38, 10 December 2013 (UTC)Put my money where my mouth was and built what I could Talk:Logo_Suggestions#Implying_the_Collaboration_with_Wikipedia_elements_.5B10_December_2013.5D


Howdy, I thought I'd take a stab at a "compromise Logo" combining two of the logos that may be a good alternative (combined 5 votes so far):

Jim--Delijim 16:22, 30 September 2013 (UTC)


A good logo is a really hard thing to do. It needs to be identifiable when it's shrunk down to be the tiny left-hand side icon on a browser URL type-in field (perhaps 8x8 pixels?). It also needs to look nice when it's grown to a much larger size. You probably can't just rely on automatic algorithms to do the growth/shrinkage - you will probably have to create a number of different explicit sized versions for tiny, medium, large, and extra-large variants. Somewhat perversely, the different versions will be needed in order to get different size images that will be perceived by a human as, in fact, the same image (the next set of candidates should be shown at different sizes).
If I had a really expensive Madison Avenue firm designing a logo for us, I'ld ask them to try to come up with a design that suggests as much of the following as possible (in no particular order):
  • a single shared space/tree
  • A collaboration environment that isn't just optional - it's fundamental/required
  • We're a wiki
  • We're the cool way to do genealogy.
  • Your information is safely in the care of a real library
  • We're free - and so is your information - now and forever
  • trees (as images) suggest genealogy well enough, but I'm not sure identifying us as another genealogy site/software system is what we need from our logo. I feel like people will already know that - what they need to know is how we're different from the others.
  • Words or a motto can be nice in/underneath the larger versions of the logo, but it would be unfortunate if a wordless version (required in the tiny form) didn't suggest any of the key features/differences about WeRelate versus non-collaborative approaches
Some rough ideas that try to break/expand the trend of trees and individual puzzle pieces -
  • people holding hands suggests collaboration - people working together and making one of those pyramids that we made in HS gym classes years ago suggests something about collaboration and yet a single entity.
  • It wouldn't be a sin to use elements of the existing logo to create the new one - in could be a benefit. Could a different arrangement of the people do a better job suggesting key themes of our site? Different people working on the same puzzle? One of our existing logo's "people" on one side w/a puzzle piece below them, another adding a second piece to the first. Or even - two such people looking down from different sides at two linked puzzle pieces.
Like I said - I'm pretty sure that this is the sort of thing that's really hard to do well. I'm pretty sure I'ld be awful at it. So the people making this effort have my respect and gratitude. That said - if we go to a new logo - I hope we're really sure that it's an improvement, lest we do more harm than good. --jrm03063 17:52, 30 September 2013 (UTC)

Ok, I'm not sure how we'd possibly be able to accomplish communicating everything you've listed above without coming up with a logo with way too much text or way too busy.

My take is as follows:
  • the Logo needs to be fairly clean and not cluttered with "mixed messages", IMO.
  • The collaborative environment of a wiki is still an unknown to many, that is I believe the most important aspect of what wiki sites like WeRelate "bring to the party", and needs to be emphasized most, IMHO. I still run into people that are working on their family tree that are unaware or somewhat unaware of the positives of a wiki environment.
  • Althouth I didn't come up with the puzzle piece logo, the more I thought about it, genealogy is like trying to assemble a very large puzzle, where some pieces fit, but many do not, so I think the puzzle part of the logo works for most serious genealogical researchers, unless they just don't like puzzles. :)
  • As one person noted above, the tree symbol may be sort of over-used, but it still remains the "universal symbol" of genealogy.
  • I'm not particularly big on logos with people "holding hands" and the whole "cumbaya" thing, but maybe that's just me.
  • Finally, I'm not sure we'll ever be able to reach a consensus on this since we have so many varying opinions, which reminds me that a camel was a horse designed by committee, so if anyone wants to step-up and give it a better try, then I'm not sure we'd ever get total agreement.

Anyway, just my $.02. Best regards to all,

Jim

I entertain no illusion that all of what I note could be accomplished - like I think I said - if I had a ton of money and could ask for the sky, the moon, and the stars - it might look something like that. Still, there is something there that I'm wanting to stress: we should know what we're trying to communicate in a new logo. The extent to which a new logo does or doesn't do a better job of communication, is the extent to which it should be favored. I don't favor new for the sake of new - because that costs you whatever market identity you already have - without any clear idea that you're going to improve something.
Maybe the holding hands thing isn't your thing - and I'm not sure it's mine - but I think there are more female genealogy enthusiasts than there are male - and maybe it would reach them? Maybe a different image - one of our current WR logo "people" handing a puzzle piece off to another WR "person"?
If you think that people don't know that WeRelate is a genealogy site, then a tree makes sense. Still, a tree on its own is pretty weak and we ought to be able to send a bigger message. Maybe a tree with a trunk that looks like a big number "1"? Suggesting that we're working on one tree? Maybe a tree in front of an obvious background containing a big "1"?
When I see another round of logos - I'm going to try to imagine how they do (compared to what we've got) - on communicating ideas like those in my notes above. They could be subjectively great art and beautiful even - but this is art with a purpose. I mean no disrespect to the people who are working on this - I think this is really, really hard - but I felt like I couldn't vote on other people's efforts without being clear about how I'm measuring them. --jrm03063 19:25, 30 September 2013 (UTC)
Just thinking about process here, there isn't a clear favourite here so it sounds like there needs to be another "round". I suggest the process needs to include some kind of "reward" for the people who have spent the time to develop their logo suggestions, so how about we say the three logos that got more than one vote (i.e. sharing, relating and Delijim, counting jrich and GayelKnott per their comments) should go through and people should be able to submit logos that are developed from one or more of these three? Given the small voting base here, should we try to sample non-users of the site as well? AndrewRT 20:11, 30 September 2013 (UTC)

My understanding of a Logo is that it is simple so it is easily recognised. This is a good example, the banks logo is well know by all Australians but what does it have to do with banking? [8] I like the tree and jigsaw idea but keep it "symbolic". Use the KISS method of design! "Designing a good logo is no simple task" quote from Wikipedia but it doesn't have to be a complicated design.--burgjoh 23:56, 2 October 2013 (UTC)

I am a terrible artist but I am quite good at visualization. Here are my thoughts:

1) A slogan and a logo are not the same thing - they are processed in different parts of the brain. I dislike any verbiage in a logo. It takes too long to read whereas a distinctive logo can be instantly grasped by the visual part of the brain without having to invoke the language processing center.

2) I think that if we simply put hands on opposite sides of the puzzle piece(s) it will convey collaboration. Two hands, each on a separate piece with the pieces interlocking, should convey the concept.

3) I would flatten the tree into the puzzle piece(s) and leave it incomplete - branching off the edges.

I can see this in my head but I cannot draw it: two interlocking side-by-side pieces each held between thumb and forefinger, thumb and forefinger on opposite sides (and rotated) - one above and one below, tree spreads across the two pieces. --Jhamstra 00:57, 3 October 2013 (UTC)

Maybe a snipped of the hands from "The Creation of Adam" - but with the hands a little further separated holding interlocking puzzle pieces? Sacrilegious I know - but struck me a little funny! :) --jrm03063 16:48, 3 October 2013 (UTC)

This graphic and this site is a good place to look for inspiration

http://www.123rf.com/photo_18407421_jigsaw-pieces-being-joined-shows-teamwork-and-assembling.html

Would be nice to convey yhe concept of the whole being greater than the sum of the parts and high quality (Gold standard) maybe one of the pieces could be golden and just connecting mahes the others turn gold (graduated fill)--Dsrodgers34 03:51, 3 October 2013 (UTC)


Based on the hands and jigsaw pieces, how about a dynamic logo ?

Three pieces are already there, could have symbols on them.

A hand adds a fourth gold piece, and the other pieces turn gold

An alternative could be to have the tree or a plant growing out of it--Dsrodgers34 00:22, 4 October 2013 (UTC)

The graphic is a bit of a thought bubble. Im imagining it put on a sphere like wikipedia. The vine represents the connectedness, the interlocking pieces represent exactness and scholarly work


I like this - I think a jigsaw of a tree could be a cool logo - puts together the ideas of collaboration (via puzzle) and genealogy (a tree) -- Jdfoote1 14:31, 6 October 2013 (UTC)
I agree with a lot of what jrm and others have said above, but I'm not sure a puzzle on its own is enough to communicate "collaboration". This is what I had in mind with the shaking hands, although I do agree that the 123rf logo does this better with different people putting pieces into a puzzle. AndrewRT 21:31, 8 October 2013 (UTC)
That is why I suggested different fingers putting different pieces together from opposite sides of the puzzle. Working on jigsaw puzzle with someone is a good way to learn to collaborate.--Jhamstra 22:21, 8 October 2013 (UTC)

My thought was we could leverage of the wikipedia jigsaw globe, which does suggest the collaboration, th exactness. I m suggesting the vine draped over the globe instead of the wikipedia symbols the vine is closer to the pando idea than a single tree symbol--Dsrodgers34 22:44, 8 October 2013 (UTC)

Wow! Cool! Maybe we could go with my mash-up for the Wikipedia inclusion project! :) (ok, probably not...)



Suggesting:

Image:WeRelateLogoProposal.jpg

Talk:Logo_Suggestions#Implying_the_Collaboration_with_Wikipedia_elements_.5B10_December_2013.5D --Artefacts 06:49, 10 December 2013 (UTC)

This logo seems a step forward to me. But the tree is too small, which I assume is to allow the features of the globe to be seen, so I would probably make it green to increase it prominence. Actually an animated gif going from the proposed picture to a smaller puzzle and bigger tree would also work, i.e., showing progress. Further, I don't like the word "free". Advertises the wrong message, imho, attracting people who want to dump their GEDCOM and invest nothing. I would prefer long-time participants because genealogy is an ongoing process: you never know if you have the final answer. I would prefer something like "Finding Out How We Relate". Personally I find the parallels with wikipedia overdone, but this would be most easily accomplished by calling it WikiRelate instead of WeRelate. --Jrich 15:21, 10 December 2013 (UTC)
I really like this. I mentioned a few concerns on the Talk page for the logo suggestions. I just wanted to chime in here to say thank you for getting this conversation going again - let's keep thinking and working on this, and get a new logo! :) -- Jdfoote1 02:09, 11 December 2013 (UTC)
I love the globe covered with puzzle pieces. Could we overlay a tree on this globe? The tree planted on top looks a bit tacky and out-of-place to me. --Jhamstra 05:15, 11 December 2013 (UTC)
I'm aesthetically challenged, and plan to abstain from the next round of voting on that basis. I did want to offer a couple ideas though (maybe they're horrid - but I wouldn't know...). What if it weren't a globe with a tree on top - but instead - a tree trunk that reached up into the globe? (a sort of lolly-pop tree). Alternatively, what if it were an incomplete puzzle piece globe (only the northern hemisphere with a handful of pieces missing) - with the trunk stretching up and starting to fan out - before it disappears into the northern hemisphere of a puzzle globe? --jrm03063 16:22, 11 December 2013 (UTC)

My vote would be for the single tree (with the poodle cut) in green on the gray puzzle piece. Also, fewer words would be better, so just "Sharing Genealogy" or some such below the image.

I never did quite get the original logo.--KayS 20:37, 11 December 2013 (UTC)


Lost GEDCOM matches [29 September 2013]

I'm in the middle of going through the errors and warnings on a GEDCOM and when I opened it today I noticed all the work I've done on it seems to have disappeared! Is this linked to the problems that other people have been having recently? Is there any way of getting it back? AndrewRT 21:11, 26 September 2013 (UTC)

From my view of your file, 120 families are matched and 143 are not matched and only 2 are updated. 249 places out of 251 are matched. Had you matched or updated more families than this, or are the matched families not appearing in your GEDCOM review? What other work had you done that is missing? Just trying to get more details so I can message Dallan. --Jennifer (JBS66) 21:32, 26 September 2013 (UTC)
Thanks - seems to be ok now. AndrewRT 20:52, 29 September 2013 (UTC)

Full source code for WeRelate available on github [10 December 2013]

The full WeRelate source code and installation scripts are now available on GitHub. This means that developers can now use the WeRelate source code to create custom family wikis and wikis for genealogical societies. In addition, it means that anyone can now help implement new features for WeRelate.org. If you have experience developing software and would like to help us move WeRelate forward, I'd love to have your help! See WeRelate talk:Website features for more information.--Dallan 02:11, 15 October 2013 (UTC)

--Artefacts 03:55, 10 December 2013 (UTC) Hi, I have no programming experience but was wondering how to start, if possible, with creating a feature that would post a summary table to a family page (or person page??) that counts the number of grandchildren, greatgrandchildren, and great-greatgrandchildren from that point and lists their birth and death locations (in summary format so that places are no duplicated?) based on pages entered. Something like this:

Grandchildren: 16 Greatgrandchildren: 42 GGGrandchildren: 108 Birthplaces: Toronto, York, Ontario Canada; London, London, England; etc. etc.


Sandbox is back [14 October 2013]

The Sandbox is back. The sandbox is a bare-bones playground that runs the same software as WeRelate but with a nearly-empty database. New features will be tested on the sandbox before they are moved to WeRelate.org. If you want to play around with ideas that you don't want to become a permanent part of WeRelate, create an account at the sandbox and try them out there.--Dallan 02:15, 15 October 2013 (UTC)


Bye for Now [27 October 2013]

This is a bit of a swan song because you may not see my contributions on the place pages for a while--I have the first of two much-needed cataract operations this afternoon. Hoping to get back to "work" in a few weeks, --Goldenoldie 09:56, 25 October 2013 (UTC)

Best wishes for a successful operation and speedy recovery :-) --Jennifer (JBS66) 10:20, 25 October 2013 (UTC)
Best wishes for a successful operation and speedy recovery.--Lidewij 14:15, 25 October 2013 (UTC)

Get back ASAP and bring back a few more as helpful and competent as you. All the best.--HLJ411 19:59, 25 October 2013 (UTC)


Get well soon! (and maybe a large monitor and large fontsize? :) ?! --jrm03063 20:07, 25 October 2013 (UTC)


Thanks for all your good wishes. The first cataract was very bad and when the dressing first came off yesterday morning I realized what the expression "seeing though a glass darkly" was all about. Now everything is bright and shiny and blue is BLUE. The screen is still pretty bright, so my not be fixing many p;ace pages for a while.

For your information, Jrm03063, I bought the bigger monitor back in August and fiddled with all kinds of settings. When I opened my computer yesterday I first headed to Excel 2007 where I can now see the upper part of the ribbon--I had been depending on lengths of words to get down to the second choices.

Hoping to get back to work on Yorkshire fairly soon (BYW I started with the West Riding). --Goldenoldie 09:04, 27 October 2013 (UTC)


Which to keep? [7 November 2013]

Two repository pages for the same thing. Which name follows conventions?

???

--jrm03063 15:48, 2 November 2013 (UTC)

Absent guidance, I've merged to Repository:England and Wales. General Register Office. --jrm03063 15:25, 6 November 2013 (UTC)
According to Help:Repository_pages#Is_there_a_format_for_repository_page_titles.3F, "WeRelate automatically creates a Repository page title that uses the fields you've entered to create a unique Page Title". I can't exactly work this out but I think this means it uses the place.title format, similar to sources, which would indicate that your redirection is the consistent one. AndrewRT 21:29, 7 November 2013 (UTC)

DAR Genealogical Research System [6 November 2013]

I've started working with content from this source. For starters, I found that the source was duplicated as both the "DAR Genealogical Research System" and "Daughters of the American Revolution. Genealogical Reseach System". I merged to the latter (hope that was the right choice!). After the fashion of the Find A Grave templates, I've also created a template to conveniently create references to the site's pages for ancestors (those would be folks with an assigned "Annnnnn" number). For example, for Daniel Boone, the record name for this reference contains {{dargrs|012096|BOONE, DANIEL}}, which displays as BOONE, DANIEL.

As I've worked through more pages with this reference, I've noticed that some folks cite member numbers and other sorts of pages on the DAR site, so there may be a need for several templates (and "dargrs" maybe should be "darancestor" or similar).

I'ld like to hear from anyone familiar with that site, on whether there are different types of pages worth citing from WeRelate.

I'ld also like to hear from anyone with an opinion of whether "dargrs" is a sufficient name, and/or whether the "Annnnn" number should be exposed when the template displays - I could make the above noted example display "A012096 BOONE, DANIEL", "A012096: BOONE, DANIEL", etc., etc.

Also - a quick note to the purists out there - I KNOW - this is a secondary source! But it's of a lot of interest to average folks, and it can be the basis for someone looking further.

Thanks! --jrm03063 15:22, 6 November 2013 (UTC)


Free Census [7 November 2013]

I have been asked to post this, though undoubtedly others know more about this than I. Images of all the censuses are available at archive.org for free. Some are available for free at familysearch.org (at least 1850, 1870, my favorite 1900, also 1940, maybe others). familysearch is much easier to use because they have a search engine and then just click on the link to get to the image. You can simply copy the address from the browser navigation bar to the source citation. However, the familysearch.org search engine can also be used to make archive.org easier to use (as could other search engines, such as heritagequest.com, and yes, even the ancestry search engine). As a result of this, it should be possible to totally avoid links to fee-based census images, or to convert existing links to free alternatives.

I assume using familysearch.org is easy enough to need no explanation. Then I hop over to archive.org to find the actual page. For example, search historical records at familysearch.org, I ask for Name: Theodore Roosevelt, Birth: New York 1855-1860 (he was in early 40's when became President in 1901), Residence: New York 1880-1880 (because I want 1880 census).

Usually I use the reel and image number to get close in archive.org. The familysearch film number usually has the reel number as the last three digits. In the above example, 1254895, so reel 895. Event Place is New York (city), New York (county), New York (state), United States. Image is given as 256, page 426B.

So in archive.org, I search for "1880 New York county Census" in archive.org, then find the desired reel number (895) in the list returned by archive.org. For small counties, there may be only one candidate and you can find the reel simply from the description. If you don't have the reel number, the enumeration district (ED) can also help you locate the correct reel since the description given on archive.org may list the enumeration districts covered by each reel. Click on the reel and select "view online" to browse the actual images.

Drag the slider button at the bottom over until it is on the desired image, 256. I use one up viewing, just one page at a time, for simplicity. It is my experience that the image number given by familysearch is off by one or two. So then use the page number they give, 426B, stepping forward and back until you find the desired page. In this case, page 426B turns out to be image 255. You often have to find the "A" page to find the page number, then backtrack to the "B", "C", or "D" page as necessary. Page numbers are not consistent, usually at the top, sometimes at the bottom, sometimes they have been renumbered, so this is not always this trivial, but most of the time it works well. In this case, page 426B turns out to be image 255 according to the slider, one off from where I started: dwelling 236.

For the most part, page numbers are ordered within an enumeration district, which is identified at the top of the page. So if you are not getting the right town, etc., check that the page you are viewing is in the right enumeration district. It seems like most of the time, the enumeration districts are on the film in order so you can usually jump forward and back if the first attempt doesn't put you in the correct location. I seem to recall some of the older ones (pre-1850) didn't use enumeration districts, rather alphabetical by town, but this becomes obvious pretty quickly as you page forward and back.

Most of the time I find this to be a quick process. One or two cases involved lengthy explorations. Not sure if this was pilot error, or just inaccurate or inconsistent indexing. But experience seems to make this easier. --Jrich 16:11, 6 November 2013 (UTC)


Question: Does archive.org support censuses from other countries, or just from the United States? --Goldenoldie 17:04, 6 November 2013 (UTC)

Personally I don't know. You would have to try searching from the main screen. --Jrich 17:52, 6 November 2013 (UTC)
Ok! This is great information. I'll have to take some time to digest it. I've been wanting to fix my fee-based links for a long time - since I left ancestry years ago because I didn't want to be a shill for them. Hope there aren't any hitches due to [this]! --jrm03063 20:10, 6 November 2013 (UTC)

So now I'm looking at some of my "ancestry.com" generated census cites. The first one on the page for my Grandfather comes with the usual ancestry stuff. The question - how much of this is worth keeping? The standard stuff present there is:
I'm going to start by assuming that the two ancestry.com URLs are worthless outside the ancestry.com universe (I think they may code up individual lines in the census document, but they're not doing it in a way that seems worth reverse-engineering).
Since the source title is Source:Carroll, New Hampshire, United States. 1930 U.S. Census Population Schedule, 1930, Caroll, and New Hampshire seem redundant. Enumeration district on the actual image shows as "2-5", not simply "5". Sheet No. does correspond to "Page: 5B". "Image: 548.0" seems not to have any relevance for the archive.org content - which itself is reached on page "555". I suspect that those numbers are specific to ancestry.com and archive.org respectively.
A minimal, but absolutely specific, reference to the archive.org image could be {{USCensus1930|1298|555}}, line 52 -

[[Transcript:1298, United States. 1930 U.S. Census Population Schedule/555/{{{3}}}|{{{4}}}]], line 52. But I'm reluctant to drop things like the enumeration district - which presumably had some meaning even if it isn't needed for this purpose. Likewise the sheet/page number.

 ???? --jrm03063 23:00, 6 November 2013 (UTC)
Very interesting question - I have been thinking about this myself as well, not just for the ancestry generated cites but also for the FreeCEN citations I've added myself. Given modern indexing, I suspect much of this is redundant if you know the name and location of the record in question, although I would appreciate any other views on this. As a related question, is there any benefit in splitting up the source pages into the individual areas rather than just linking them all to the generic country/census year source? AndrewRT 21:24, 7 November 2013 (UTC)
I'm starting to think that there's a role for either a translation table or even a limited (very sparse) transcript. The hierarchy for 1930 seems like this: state/county/enumeration_district/sheet/line. We've already decided that the sources for 1930 go down to the level of the county - so if you create a transcript for any given 1930 census source, you could create a hierarchy of enumeration districts, and beneath them, their pages. While each page could be a full transcript, it could also be as simple as a list of the 52? lines on that page - and a header that points at the image(s) available from various providers. Of course, the value of having the names on such pages is to link them where possible - which starts to give you a reverse-citation process that could be processed by software into nice back-links. What I don't really like is to populate the individual (person) page records with items that are artifacts of someone's scanning process - and not actual census reference parameters. --jrm03063 21:58, 7 November 2013 (UTC)

Wikipedia - over 100K pages correspond now - time for a fresh extract? [11 November 2013]

We've reached a bit of a milestone with inclusion of wikipedia content. There are now over 100,000 WeRelate pages that correspond to individual Wikipedia pages. They come in a number of forms, so I'll break it out a little bit:

  • 76,822 Place pages - (including 5084 cemeteries or burial locations, 83 castles)
  • 22,374 Person pages
  • 877 Category pages (battles, campaigns, wars, military units, royal dynasties & houses of nobility)
  • 72 Surname pages
  • 53 Repository pages
  • 47 Source pages
  • 12 Givenname pages

Among the more extensive and interestingly nested categories are Wars and Houses of Nobility.

Remember, the point of "attaching" to a WP page in this way is to try to derive whatever benefits we can from the WP community of contributors and content - both as it exists presently and as it may exist when currently modest WP articles are expanded. It doesn't mean WeRelate won't provide unique content - but we need to use care to remain engaged with as wide a community of contributors as possible. When we provide alternative content to that present on WP - we should do so because it is specifically appropriate or necessary for genealogical research. --jrm03063 19:36, 11 November 2013 (UTC)



An overly done page....! [16 November 2013]

I've taken a small but notable historical document and done everything with it that I can imagine. The document is known as The Exeter Combination, and the group can be best understood starting from the corresponding category. It has:

  • A template (transcribed text of the document, with links to appropriate Person pages)
  • A source
  • An image (which includes the template)
  • A transcript (which also includes the template)

The Person pages referenced, themselves refer to the source and include the image (which is attached to the source as an appropriate "I<n>"). The Person pages fact lists contain entries supported by the source - containing a fact that is described with a reference to the category. The only actual bit of category syntax is found in the template page.

It's much more than the situation requires, but I thought it might be an interesting example of some of the possibilities.

--jrm03063 20:04, 11 November 2013 (UTC)

Jrm, I think you've just demonstrated what WeRelate could hope to be some time in the future. --GayelKnott 20:28, 11 November 2013 (UTC)

Thank you so much for this example! I've been trying unsuccessfully to get my head around using Categories / Templates / Transcripts / Sources and what the relationships between them all are intended to be. Your example is fantastic and I've bookmarked it for future reference. One question, though - to my way of thinking a Transcript is the purest form of extract - the very words to be read. You use the Template for this function, and then refer to this from the Transcript. Is there a reason it is done this way (and thanks in advance).--Wongers 10:54, 12 November 2013 (UTC)
In principle, you're exactly right. However, I wanted the same text to appear on a transcript page and the text box for the image - but I wanted only one "live" copy for maintenance purposes. The fundamental wiki item for doing that is a template - even though we more commonly think of it as a way to do orderly parameter substitution and handle nasty little bits of syntax. An alternative approach would be to let the text live on the transcript page, and transclude that into the text box of the image. I havn't tried that (feel free to try and see what happens) but I think you would wind up with a mish-mash of transcript-specific items mixed in on the image page.
All that said, as I've continued to reflect on this, I think the approach I took creates more problems than it solves. I agree that the transcript ought to be pure and we don't want to distract from that. Instead, I might put a small "See transcript" active link in the image page's text box (perhaps also a link to the source page). The image page already has a separate mechanism for creating bi-directional links with the person page - so the hyperlinked text is semi-redundant in that respect. I'll be changing this shortly. Stay tuned and let me know what you think!
Thanks also for your kind words and observations! I had hoped a small example could bring together some of the nuances of how the different page types can be made to relate (pun intended) usefully! --jrm03063 15:31, 12 November 2013 (UTC)
Following up on my prior remarks: I've made the changes that I contemplated. I think this makes the group easier to comprehend and doesn't cost anything in terms of capabilities. Only a minor cosmetic - on the presentation of the image page - at least on my browser - the bullets of my bullet list are overlaid by the image. Can anyone offer some syntax that will cause the text to be shifted below the image - pretty much regardless of browser circumstances? --jrm03063 15:52, 12 November 2013 (UTC)
I've added some HTML into Image:Exeter Combination.jpg which I think does what you wanted. It uses style "clear:left" which causes following things to come only after the lefthand side is clear. I got the relevant syntax from Wikipedia's {{Clear}} template. (If there's a general need, we could have that template here). --robert.shaw 08:20, 16 November 2013 (UTC)
Thanks! --jrm03063 17:30, 16 November 2013 (UTC)

Early rule [2 December 2013]

The pre-1700 "Early" rule is a major turn-off from WR. The stated purpose - to save time from duplicates since almost every documented human before 1700 is already in WR - is demonstrably, clearly, starkly, and obviously mistaken. Perhaps there were multiple uploads of Mayflower passengers, however there were 150,000 to 200,000 other pre-1700 immigrants, including over 5000 enslaved Africans, besides this. (see http://www.zanran.com/preview/pdf/113151005.010101?q=north+american+immigration+history) Not to mention the millions around the world who missed their chance to immigrate to America before 1700, and the millions of Native Americans who were already here to greet the Pilgrims. And not to mention the millions of pre-1700 descendants the immigrants produced.

This rule wastes so much human time and effort. And it contradicts the stated aim of WR to link genealogies. It works squarely against that purpose. I've taken to listing pedigree outlines to link early northern Clevelands with more modern ones. Someone else can hand-enter the thousands of early Clevelands not in WR. I've done my share, thank you.

I have a pending GEDCOM upload with about 1/3 rejected because they were early. There was one semi-famous family - Richard "Bull" Smith of Smithtown, LI - that I deleted from the GEDCOM before I tried to upload it.

This amount of rejection turns the GEDCOM into a disjointed, unmanageable mess. What's the point of having a GEDCOM upload at all?

I understand the desire to control quality and merge GEDCOMs. This is not the way to do it. How about having at least one reference not to an amateur website or GEDCOM? There a thousands of WR persons without any refs at all!

Similarly the "One Date" rule is misguided. Some people - like my hillbilly southern ancestors - didn't leave many written records. This does not mean they didn't exist. Again, having some sort of source for these people would be more helpful than forcing manual entry and linking of their family members, which may entail a substantial effort for even one rejected person.

In summary, I simply don't understand why these onerous and senseless rules are tolerated. I hope they can be changed.

Prcb 21:27, 16 November 2013 (UTC)

In respect, were it not for a rule like this, WeRelate would probably not still be here.
In the early days - there were no rules. Enormous amounts of unsourced content was dumped by users who then disappeared. Those of us who want the site to succeed, have spent years trying to clean up and de-duplicate content that was loaded back then. To get an idea of the scale of the problem, I invite you to look at the page for Charlemagne. From there, go to the "what links here" page. Count up the number of "redirect" pages. Each such redirect represents a GEDCOM with lineage to Charlemagne - and many thousands of intervening individuals - every one needing de-duplication and individual editing.
You are quite right that many pages don't have references of any quality at all. That is unfortunate - but it too is a product of the early days of no rules at all. It's not a great reason to continue an unsound practice.
We have found that the larger the GEDCOM - the greater the reason to be concerned. The best use - and only one I would suggest for a GEDCOM - is to use it for your personal and immediately documented family. Perhaps a few thousand individuals at most. If you are determined to bring a large amount of material to the site - then we would suggest breaking your GEDCOM into chunks.
Finally - if you feel that your content is of an unusually high quality - you can ask that the rules be waived. You would need to justify that - but it's a possibility if you really have some good content. --jrm03063 21:48, 16 November 2013 (UTC)

Your comments are perpendicular to my criticism.

I quite agree with breaking the GEDCOM into chunks and merging small pieces. This would be my my plan.

Likewise, I understand that regulating GEDCOM imports to WR is essential and important. I am remarking that you are doing it wrongly and harmfully.

It is rather astounding that you would allow this criticism, which illustrates how unnecessarily painful WeRelate is to use for many people with substantial new content to contribute, to pass without some cogent response.--Prcb 22:15, 16 November 2013 (UTC)

Simply for clarification, all but one of the excluded individuals within your GEDCOM already have Person pages represented on WeRelate. Peter and Alice Wright and Nicholas Wright and Margaret Nelson are two of the families which represent many of your Wright family ancestors. It is unfortunate that the upload system did not match the pages to show you this fact, but hopefully this will help to at least resolve the immediate issue, if not the far-reaching issue you describe.--Khaentlahn 22:37, 16 November 2013 (UTC)

Indeed the rejected ones are in WR. This casts doubt over my impression that many of my uploads are being spuriously rejected. Are matches not shown for pre-1700 uploads? If so, in my case it gave a negative impression about WR.

Also, please forgive my use of the word "senseless". I believe your policies and procedures are for good purpose and intentions.

Prcb 23:20, 16 November 2013 (UTC)

Perhaps someone with experience on the back-end of this system can answer your question about the way individuals are matched in the upload system (that would not be me, sorry). All the best, --Khaentlahn 23:36, 16 November 2013 (UTC)

Point taken about the vast number of people before 1700 not in WeRelate. I have made the same argument myself in the past, and was granted the right to upload people prior to 1700 (after demonstrating the quality of post-1700 data I was uploading). I recently uploaded a number of German Mennonites living in Prussia in the 1600's, with just a handful of matches. However, I support the WeRelate rule because I believe that it gives us a reasonable balance between efficiency of uploading information and effectiveness in getting it right. I spent 6 months cleaning up medieval data in WeRelate and just scratched the surface (luckily others have taken up the work), so I am well aware of the garbage that was dumped in WeRelate through GEDCOM uploads prior to the establishment of the rule.

Once you prove yourself to be a careful contributor (well-researched and cited data, good citizen about matching and not adding duplicates, etc.), and if you still find that you have a significant amount of pre-1700 data that is not in WeRelate, ask for the right to upload it.

A note about the absence of dates: While you might not have dates for some of your ancestors, a GEDCOM with no dates at all is usually a sign of unsubstantiated poor quality data (hence the rule). If it is truly impossible to find any dates for a whole tree, it should be at least possible to estimate some years, which adds greatly to the value of the information. If this is not possible, that particular tree might not be ready for sharing. My personal approach is to add at least an estimated birth year to every record that has no dates, as it is extremely useful in searching (and has also helped me to discover errors in family groupings).

Welcome to WeRelate. I hope you find that through collaboration, you find information to add value to your own personal family tree.--DataAnalyst 15:35, 17 November 2013 (UTC)


I felt I had to offer a defense of the measures taken to avoid GEDCOM dumping. While I'm sorry for the burden that some people feel they impose, I remain of the belief that WeRelate would have died without them.

The measures taken to avoid bad GEDCOM dumps can, and should, continue to be reviewed and discussed.

Were it up to me - the real measure wouldn't be on any GEDCOM - but on the user offering the GEDCOM. I would allow new users a tiny amount of total GEDCOM upload content - perhaps a few hundred people. I would expand it as a function of the hand-edits/contributions that they made, and/or on the basis of the quality of the work they were seen to be doing. I'm not concerned if a GEDCOM starts out as weak content - as long as the user is committed to WeRelate and to the ongoing integration and improvement of whatever they're adding. --jrm03063 22:20, 17 November 2013 (UTC)


I'd like to second Jrm's reasoning for NOT allowing pre-1700 gedcoms. I too have spent perhaps hundreds of hours cleaning up many inaccurate and unsubstantiated lineages that were "dumped" here, left for many of us to cleanup the "mess" left behind. It is certainly easy for some to criticize what has evolved here (perpendicular or not), especially when they have no idea how much time has been spent by many here making sure WeRelate doesn't turn into what most of the "Ancestry Member Trees" have become, poorly researched, poorly sourced and questionable lineage at best. There have been way to many "gedcom dumpers" that have come here and left for us to turn back the clock and go back to how it was. We've learned from this, and frankly, even though it is somewhat more difficult, we don't need to repeat the mistakes we've already learned from. Those who think otherwise have not "walked in our shoes"..... --Delijim

A bit late to this party, but I have to agree with the pre 1700 rule, which can be waived in certain circumstances. I have spent the last year cleaning up alot of unsourced pre 1700 ancestries. I've started to make a crack at nobility/visitations, but the going there is slow. The amount of garbage that was dumped here in 2007-9 is STAGGERING. Between myself and about 4-5 other admins, we have deleted about 25,000 'living' person pages, with over 90,000 left to go, and another unknown number of 'livings' that are simply undated. The early site was pure chaos. JRM is right. Without these 'strict' rules, this site would probably today be a parked godaddy webpage. Daniel Maxwell 13:55, 2 December 2013 (UTC)
I have to say I'm also a bit frustrated about this rule. It can be particularly annoying to have the "heads" chopped off a GEDCOM upload - the temptation is to leave them off rather than going through and manually adding them back in again. It's interesting that people are open to "waivers" for experienced contributors and I think this would be a positive thing to publicise more - it would give an incentive for people to stay around and contribute more! I wonder if it's worth have something more formal and more explicit about saying that experienced users - maybe ones who have already been here x months and uploaded y GEDCOMs - are allowed to upload GEDCOMs with an earlier date cut-off or ones that are larger in size? AndrewRT 22:25, 2 December 2013 (UTC)
The rule for it probably needs to be formalized. I think if you are an established user, and you are able to show that 1) the material you are adding is of a high quality, and 2) that there not many (or any) duplicates (this is key I think), then on a case by case by basis it could be waved after checking by an admin. I would never want to see 'auto-waving' because it would bring back the old problems, particularly with royals/nobles/unsubstantiated lines going back to 100 BC.. But I don't know that I would publicize it so much - when the general public hears something like that they may think "WR is dropping their standards" Daniel Maxwell 23:49, 2 December 2013 (UTC)

Content Language Neutrality via Wikipedia/Wikidata [5 December 2013]

Moved this item to WeRelate:Suggestions/Content Language Neutrality via Wikipedia/Wikidata, and follow up discussion to the associated talk page. --jrm03063 18:30, 6 January 2014 (UTC)



Policy update regarding inclusion of obituaries [5 December 2013]

The Overview Committee has updated WeRelate's policy regarding the inclusion of Obituaries. This policy is similar to those found on other websites (such as Find-A-Grave). As with other texts, if an obituary is published after 1923, it may be subject to copyright and should not be added to WeRelate. However, some of the facts contained in the obituary such as name, age, birth/marriage/death/burial dates and places, names of parents/spouse/siblings/children are not copyrighted. You may include a link to the obituary (if published online), a brief summary of the facts (please exclude names of living relatives), the name of the newspaper, and date of publication. The full policy can be found here.--Jennifer (JBS66) 11:59, 4 December 2013 (UTC)

The policy was revised slightly to be more in line with guidelines that appear on Help:FAQ that say "On pages for People/Families who are deceased, information about still living people that is publicly available (ie, 1940 census data) - can be included on the pages." That is why I crossed out a bit of the text above. --Jennifer (JBS66) 12:10, 5 December 2013 (UTC)
Just to be clear - I'm not seeing a policy change per se. This seems only to be a revised description of practice, calculated to better help people to avoid inadvertently infringing. Right? If not, then I'm missing something... --jrm03063 14:58, 5 December 2013 (UTC)

Savage Transcript Contents Updated! [9 December 2013]

The contents page for the WeRelate transcript of Savage's Dictionary has been rebuilt.

The former version was obtained from direct processing of Dr. Kraft's ASCII files, using logic that was necessarily imprecise. The result being that section names were sometimes abruptly shortened (leaving out alternate name forms) or even missed altogether. The new version is built directly from the WeRelate transcript pages, processed through a program that recognizes the section marking template. While not strictly a part of the transcript (Savage's dictionary had no such table), I hope others will find it as helpful as I have.

For example, the following:

OAKLEY OAKMAN OATES OBBINSON OBER OCKINGTON or OKINGTON ODELL or ODLE ODERIC ODIORNE ODLIN OFFITT

Became:

OAKLEY; OAKMAN; OATES; OBBINSON; OBER; OCKINGTON or OKINGTON; ODELL or ODLE; ODERIC; ODIORNEODLIN, ODLYN, original. AUDLEY, or AUDLIN; OFFITT


And, this:

UFFORD, UFFOOTE or UFFIT UMPHERVILE UNDERHILL

Became:

UFFORD, UFFOOTE, or UFFIT; UMPHERVILE, UMBERFIELD, HEMPEHREVILLE, UMFREVILLE; UNDERHILL


Besides offering a more faithful representation of Savage's section names/introducers, the new index also creates a single link entry per transcript page (combining all the sections that begin on a particular page into a single link - hence a larger individual text/mouse target). Since we don't have anchors that allow addressing within individual pages, there is no value in having separate links that all head to the same page. Separate links are also now set off from each other with bullets, while sections on the same page are set off with a semi-colon.

Questions, comments and corrections welcomed!

--jrm03063 17:36, 9 December 2013 (UTC)