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)