Talk:WeRelate

Affiliation with WMF?

I guess the discussions about affiliation (in whatever form that might be) with the Wikimedia Foundation have gone nowhere at the moment? Just wondering about the status of this. — Sam Wilson ( Talk • Contribs ) … 06:55, 19 March 2012 (UTC)

Wikidata

Wikidata can represent family trees as well. Would it be possible to connect them in some way or another? I understand that WeRelate will not only be for "notable" people, but Wikidata can already represent family trees (example visualization of a family tree from Wikidata information) PiRSquared17 (talk) 20:01, 11 July 2013 (UTC)

Wikidata can certainly include links to WeRelate pages. In the long run, Wikidata can also store much of the WeRelate's information, although this would require extensive reprogramming of the various features. But it can not completely replace a separate genealogy wiki, any more than it can replace Wikipedia. -- Ypnypn (talk) 20:52, 11 July 2013 (UTC)

Thanks for cleaning up this proposal, Ypn. Can you reach out to the people who expressed interest in the Rodovid migration as well? If we can combine the two requests in a meaningful way -- the other has a tremendous number of individual interested users, while WeRelate has a larger collection of genealogies -- we might move towards a unified global wiki-genealogy site. –SJ talk  01:51, 12 July 2013 (UTC)

Notability

I understand that on WeRelate people can add every person they like. Whether they are notable or not. While Wikipedia only allows notable persons, right? Maybe the project might be useful, but certainly not all the info is imho. I'm not convinced yet, also because Wikidata can do some stuff WeRelate does. Trijnstel_talk 09:26, 12 July 2013 (UTC)

WeRelate and Wikipedia have different notability rules because they have different goals. Wikipedia tries to provide articles on people only when there's a lot of (reliably sourced) things to say about them. WeRelate's goal is different: It wants to include every deceased person, because this allows people to trace their ancestors back many generations, even if each individual person wasn't very important.

You're right that Wikidata can do some of the stuff that WeRelate can do – and it can also do some of what Wikipedia does. But not all. I don't think Wikdata makes a separate genealogy wiki completely redundant. -- Ypnypn (talk) 20:56, 12 July 2013 (UTC)

I think that Wikimedia shouldn't get into that. There's very serious privacy concerns, and it's a very far stretch from "educational content". --NaBUru38 (talk) 00:46, 14 July 2013 (UTC)

There should actually be no privacy concerns at all, since living people are rarely permitted to be included. -- Ypnypn (talk) 03:10, 14 July 2013 (UTC)

I was going to mention that all pages on living people must meet the requirements of wmf:Resolution:Biographies of living people, but I'm sure Sj knows this. I guess it's not a problem if there are very few pages about living people allowed. PiRSquared17 (talk) 03:57, 14 July 2013 (UTC)

The notability issue lies at the heart of my question below in the "fresh start" section. If we proposed a WMF project for a wiki containing non-living people based upon Wikidata, which allowed people to create and edit Wikidata items, would it be acceptable to store information about non-notable people in Wikidata?--Dallan (talk) 00:40, 28 January 2014 (UTC)

Living people

Is there any specific reason why living people are excluded? Many users that will come to the site will expect to be able to put themselves into a family tree. --DixonD (talk) 11:17, 19 July 2013 (UTC)

For privacy reasons. Genealogy programs that allow living people always include privacy controls and protected content - something which is, IMO, opposed to the principles of WikiMedia. -- Jdfoote (talk) 16:52, 26 July 2013 (UTC)

How so? The privacy rights of living people have been the subject of a number of WMF directives over the last few years. LtPowers (talk) 19:21, 26 July 2013 (UTC)

How do I oppose

All I see is a place to add support votes, how do you oppose this? Retrolord (talk) 03:18, 21 July 2013 (UTC)

Maybe by adding a comment here (to the talk page), although I suppose adding a section to the page itself would be fine. But it might be better on the talk page. PiRSquared17 (talk) 03:28, 21 July 2013 (UTC)

Also, did you read WeRelate/FAQ? PiRSquared17 (talk) 03:35, 21 July 2013 (UTC)

After reading the FAQ its worse than I thought. You are actually trying to make a social network aswell. Retrolord (talk) 11:18, 21 July 2013 (UTC)

Well, I'm not; I've never contributed there (and haven't supported [yet]). Would you mind elaborating on what you dislike about this proposal? PiRSquared17 (talk) 15:30, 21 July 2013 (UTC)

I don't see anything more in the "social networking" section of the FAQ than Wikipedia is already providing or used for. Amqui (talk) 17:35, 23 July 2013 (UTC)

I oppose adding WeRelate to WMF holdings. We have too many sister projects already and this does not inspire my confidence. Chris Troutman (talk) 01:21, 27 July 2013 (UTC)

Technical and Usability Issues

I want to start by saying that I think the mission of WeRelate is very important. The field of genealogy is currently dominated by "for profit" companies, which hoard data and charge a price for access. This is contrary to the basic goals of the Internet. I wish there were a place on the Internet where I felt comfortable entering genealogy data into a database that would eventually trace the lineage of every human being, especially those deceased long ago. Having said that, I have a few questions and observations:

• The WeRelate administration is wholly separate from the WMF and it is anticipated to remain that way. It looks like all they really want is the WMF Imprimatur.
• There is a real danger that WeRelate could degenerate into a series of cross-connected public eulogies/obituaries.
• The WeRelate software is based on a very old version of mediawiki. We have to assume that there will be no convergence, which has implications over the long run where software support is a limited resource. For instance, no improvements made to mediawiki will ever appear in WeRelate without an equivalent additional investment in software development.
• The WeRelate software is not open source or downloadable, so far as I can tell. this is important because not having access to the software prevents using the software to set up a personal/family genealogy wiki — where the standards for privacy and notability could be quite different from those of a public wiki. There is family lore that should never appear on a public genealogy wiki regardless of whether the individual is notable or living. At the same time those things should not be forgotten by the family involved (IMO).
• This might also include genome data, which is not currently supported by ANY genealogy software.
• Open source / distributed architecture genealogy software would allow a more flexible approach to uploads, references and support to the public wiki. That has huge positive implications for scalability, performance, usability, and access to information.
• These questions about the software architecture of WeRelate make me wonder whether it would be better to use WeRelate as a model of what is needed/desirable and just start over from scratch. This would involve building a software module on stable mediawiki calls/interfaces that can be snapped into current and future releases of mediawiki. This would also involve adding the badly needed support for distributed genealogy development and genome data. (The existing data could be migrated to the new architecture.)

Having said all this, I am left feeling overwhelmed by what is obviously needed. I work with various nonprofits and the question of finding and focusing resources for the mission at hand is ALWAYS in the air. Bob (talk) 07:32, 7 September 2013 (UTC)

Allow me to provide a rebuttal to some of these issues. I am not a core member of WeRelate, but I do follow the project, and have a basic understanding of what is going on there. The site was started, and mostly coded, by one developer, who also runs the hosting, etc. He basically has run the show from the beginning. He has lately been involved in other projects, and hasn't had as much time to devote to WeRelate. He (Dallan) has been working to make the code open source (progress here). I think that there is definite interest in making this a completely open source project, whether or not it becomes a WikiMedia project.

There are some people on the site who would prefer for it to stay just like it is (mostly because open genealogy projects have a terrible track record - they fill up with poorly-researched data very quickly), but some of us would love to grow the site, and I personally would love to see it become a WikiMedia project. -- Jdfoote (talk) 19:39, 14 September 2013 (UTC)

I like WR and genealogy efforts. I think that they are looking for both an imprimatur and long-term hosting; as well as interwiki links and single user login across the projects.

The WR software would likely be brought in line with recent MediaWiki, and made open source; the latter would be a requirement before adoption could begin.

Alternately, using WR as a model and building a genealogy site that could import exported WR data could work; or importing the raw data into WikiData and having a new wiki with an entry for each person. –SJ talk  09:15, 20 September 2013 (UTC)

I'll try to answer these questions. I'm the developer at WeRelate.

• The WeRelate administrators would be happy to integrate with the WMF administrators if that was an option. (I didn't think it was.)
• WeRelate is based on MediaWiki 1.7, which is ancient. I made about two dozen changes to the core so that the WeRelate extensions would work the way I wanted them to and never upgraded. Being on the latest version of MediaWiki wasn't important to any of our users in the beginning, and since I procrastinated it now represents a fair amount of effort. I'm starting the process of reviewing the changes I made and trying to find ways to make the WeRelate extensions work the way I want without core changes in the most-recent version. I expect this will take a couple of months.
• All of the WeRelate code is now available on github.
• Only a few WeRelate users are interested in genome data. I've asked them how WeRelate could support genome data but haven't received any concrete feedback yet.
• If someone wanted to start over from scratch, I'd be happy to help. Also, I'd be happy to migrate WeRelate onto the new software when it was done. I'm open to re-writing the software to sit on top of WikiData for example, but I'd want help. I'd love to be able to work with other developers if there was interest.

I've been working full-time on a consulting project for the past year so I haven't had much time to spend on WeRelate development, but that project is winding down and I'm able to spend more time now on WeRelate. If you have any additional questions, let me know.--Dallan (talk) 21:49, 4 December 2013 (UTC)

Brilliant, thank you for these updates. It's great to see the code up on github! Let's think about what it would take to do three separate things: 1) migrate WR as it stands today to Wikimedia hosting, 2) upgrade it to run on the latest MediaWiki, 3) synchronize its data with other well-researched and open-data genealogy projects (wikia, rodovid). These can all be pursued in parallel (though 2. might be needed to do 1. properly) –SJ talk  22:17, 5 December 2013 (UTC)

I'm definitely interested in helping. I've been tinkering with a couple of little WeRelate extensions (see https://github.com/samwilson?tab=repositories, search for 'werelate'), all working with the current system of storing data in XML in wiki pages. I keep thinking that it'd be worth investigating, like you say Dallan, Wikidata or SMW perhaps, but I've not done anything much in that direction. There is a pretty huge body of data in the existing schema after all; would be hard to change (and bring along all history). I quite agree with pulling data in from the other genealogical wikis! Very much worth doing. — Sam Wilson ( Talk • Contribs ) … 02:46, 6 December 2013 (UTC)

I should have a reasonable start on 2 by the end of the year. I'm hoping to be completely moved over by March.

Regarding a rewrite onto Wikidata, I did a quick check of the number of lines of code in various parts of WeRelate:

• 12K - wiki extensions (in php) to handle the current structured-data XML islands embedded in the wiki text
• 14K - other wiki extensions: showing possible duplicates, merging, allowing people to group wiki pages into trees, various hooks
• 3K - javascript for various functions
• 22K - gedcom import (85% java, 15% wiki extensions)
• 12K - search (85% java, 15% wiki extensions)
• 5K - gedcom review program to review and correct gedcom data in a staging area prior to wiki page creation (90% flex, 10% wiki extensions)
• 5K - various maintenance bots

So we're looking at roughly 70K lines of code that would need to be re-written from scratch or reviewed and modified to migrate WeRelate to wikidata. I'm thinking that's probably on the order of 1000 hours. I can dedicate roughly 8 hours a week to new development. (Other WeRelate support tasks take around 4 hours/week, and 12 hours/week is the total I can commit.) So a re-write would require 2 other people willing to work a day a week for a year, or 4 others willing to work half a day a week for a year. I'm up for that if others are.

Incorporating data from other wikis into WeRelate's existing XML-island approach wouldn't take nearly as much programming effort as a rewrite. The main effort there would be having human volunteers review potential matches and merge matching pages. That's a big job. When WeRelate started, it didn't have duplicate checking. By the time I added it, we already had 100K duplicate pages. (I didn't expect we would have had so many or I would have added it earlier.) It required maybe a thousand volunteer-hours to merge everything. I assume that merging Wikia and/or Rodovid would be roughly the same magnitude of effort. We would need to get enough people interested in the merger that they would be willing to do the review.--Dallan (talk) 22:14, 6 December 2013 (UTC)

Maintaining research quality

As Jdfoote mentiones above, and as some people mentioned in their opposition to the proposal, open genealogy projects tend to fill up with poorly-researched data.

How does WR currently avoid this? How do other sites avoid this? How could we avoid this with a more visible project that draws a larger audience of contributors? I thin kanswering this question is important to moving the proposal forward.

One possibility is to separate notable/multiply-validated entries (high quality) from cross-checked entries (medium quality) and un-checked entries (low quality). All could be allowed, but the low-quality entries might now show up in default searches (other than tree-merge searches), and each level of quality could have a different background page-color. –SJ talk  09:12, 20 September 2013 (UTC)

I don't know how WeRelate manages this.

However, in the GEDCOM standard, each 'factoid' can have an infinite number of citations. (And citations may be applied to more than one factoid, and almost always are.) Rather like Wikipedia articles, in fact, including that not all citations are created equal. Anecdotally, I find a high percentage of en.WP references to be crap from a research point of view because they're news articles (not objective, and/or disappeared behind a paywall, or just no longer available.)

Another related issue is use of original documents. A bad scan of a census entry or baptismal record may be open to multiple (mis)interpretations, but is probably better than solely oral histories. Still, oral histories are valid in gen research, and transcriptions & recordings should be accepted. - Amgine/^{meta wikt wnews blog wmf-blog goog news} 17:32, 10 October 2013 (UTC)

At present WeRelate does several things to manage quality:

• GEDCOM uploads go through about a dozen date consistency checks; e.g., mother having children too young or too old, children born on different days less than 6 months apart, date of death prior to date of birth. Uploaders are required to review and correct inconsistencies prior to upload. GEDCOMs with too many inconsistencies are rejected. (Roughly 30% of all uploads are rejected. There are a lot of bad GEDCOMs out there.)
• Each family in an uploaded GEDCOM is matched to the already-existing families. Uploaders are required to confirm potential matches or reject them. If a possible match is confirmed, the uploader merges the data from the GEDCOM into the existing matching family.
• An administrator does a quick sanity-check of each GEDCOM prior to import. GEDCOMs that have too many people missing dates and places are or that look obviously wrong in other ways are rejected.
• When a user attempts to create a page for a new person, the system first does a search for potential matches. If potential matches are found, the user is required to confirm the match or reject it. If the match is confirmed, the user is taken to the existing page. If the match is rejected, the user creates a new page.

There is more that could be done. We are just now starting to have conversations around the following ideas:

• From now on, perhaps require newly-created pages to contain at least one date (maybe an approximate year is ok), a place (maybe just a country is ok), and a source.
• We could run the same date consistency checks for pages that are created online (like we currently do for GEDCOM uploads), and notify users about pages that fail the checks.--Dallan (talk) 21:49, 4 December 2013 (UTC)

I support these two additional measures for improving the quality, but for the place one should introduce the possibility to add the prefix "est" (estimated) the same way it exist in GEDCOM for dates. In many cases the year and place of birth (or death) can be estimated with relatively high probability from biography context, but there are no formal document proving it at 100% certainty. This prefix "est" should not be part of the name, otherwise all indexes will be biased by it. Also the age limits for fathers and mothers should be probably a little more flexible: very rarely we can find 12 years mothers and 80 years fathers, so warnings are needed, but exceptional cases should be allowed probably by administrator decisions after users request.--Alexandre.rozanov (talk) 11:39, 11 February 2014 (UTC)

I agree that allowing "est" as a place prefix would be a good idea. The software currently understands "near" but not "est". Also, we currently have different warning levels in gedcom uploads: advisories, warnings, and errors. A 12-year-old mother would fall into the warning category; a 6-year-old mother would be an error. We could (and should) do something similar for on-line edits.--Dallan (talk) 03:10, 14 February 2014 (UTC)

Software development for WeRelate

The software that runs WeRelate (i.e. extensions and modifications to MediaWiki) is now on Github and there is some discussion about its development, at http://www.werelate.org/wiki/WeRelate_talk:Website_features#Full_WeRelate_source_code_and_installation_scripts_available_on_github_.5B16_October_2013.5D — Sam Wilson ( Talk • Contribs ) … 10:42, 20 October 2013 (UTC)

Thanks for the notice! -- Ypnypn (talk) 22:00, 20 October 2013 (UTC)

WeRelate has a several moving parts

In addition to the MediaWiki extensions, WeRelate includes a number of other software modules:

• A "gedcom review" program written in Adobe Flex that users use to review their gedcoms in a "staging area" prior to import. This doesn't require a separate server -- the SWF is simply served to the user's browser as a file, but it represents a non-standard language for WMF. This could be rewritten in PHP and javascript, but it would take time.
• A gedcom uploader program written in java that runs as a cron job, parses uploaded gedcoms, and adds pages for them using one of the WeRelate wiki extensions after users have matched & merged their gedcom with the existing wiki pages using the gedcom review program. This could be re-written in python maybe, but it would be a lot of work. I wouldn't want to write it in PHP. My preference would be to continue to maintain it in java.
• A search engine also written in java, based upon Tomcat + Apache SOLR with custom extensions for searching approximate names, dates, and places. The custom extensions for approximate name, date, and place matching are pretty important for finding potential duplicate pages.
• Various "bots" also written in java that read a daily pages.xml dump and update pages in various ways. These could be re-written in python if necessary. I wrote them in java because I'm more comfortable with Java than I am with Python.

These additional programs make WeRelate more complicated than a traditional wiki. I'm not sure how the WMF feels about this. I currently run the wiki on one sever, the gedcom uploader and bots on a second server, and the search engine on a third server (all m1.small servers on AWS). All of the code is available on github and I've recently developed a set of relatively straightforward installation scripts to install and configure everything. The scripts make things relatively easy to install, but there's more involved here than just running a standard LAMP stack. These additional processes could be run outside of the WMF server farm, but you may want them to run inside the WMF server farm for the same reason that you want the PHP code to run on the WFM server farm.

I anticipate that I and other developers would continue to maintain the WeRelate codebase - I would not ask the WFM developers to take over maintenance of the code, though I would welcome any help they wanted to give). If WeRelate were to be hosted by WMF, would these other modules also be hosted by WMF?--Dallan (talk) 21:49, 4 December 2013 (UTC)

Challenges unique to genealogy wikis

A challenge that is somewhat unique to a genealogy wiki is a high ratio of number of pages to contributors. Geni.com for example has over 66M profiles but probably fewer than 1M active users (I don't know for certain). A single user might upload a GEDCOM containing thousands of pages and might not be inclined to maintain / correct mistakes on so many pages. One implication of this is the number of "watchers" of an average page is low, so when someone makes a negative edit to a page, it's less likely that the edit will be corrected on WeRelate than it is on Wikipedia for example. In order to address this issue, I think we will need to experiment with ways to automatically contain or reduce the impact of negative edits in order to reduce the burden on human reviewers, which might make the software less "wiki-like". I'm not sure how the WMF would feel about this.

For example I'm seriously considering experimenting with some Quora/StackOverflow-like "voting" ideas. A wiki page might contain multiple assertions about someone's birthdate, each with a different source and each tracking which users have voted the assertion up/down. Perhaps users would not be able to edit assertions contributed by other users. They could add new assertions or vote existing assertions up or down. Only the "best" assertions (based upon the presence of a source / the net number of votes / the track record of the voters / etc.) would be visible by default. Other assertions might be hidden by default.

I honestly don't know if this would end up being a good idea or not. Due to our high ratio of pages to contributors, we need the flexibility to think outside the box in order to reduce the burden on human reviewers.--Dallan (talk) 21:49, 4 December 2013 (UTC)

Good points Dallan. I like the idea of the assertion-voting system also giving visibility to the non-primary assertions, too. I guess all the data for the votes would be stored in the XML in each page (prob indexed elsewhere too)? I've never had much problem with vandalism on WR so far. I wonder if Commons is a similar sort of thing where most files don't have that many watchers either; but of course, there are more users there.

By the way, what's the status of the MediaWiki upgrade? I've been meaning to get back to looking at that stuff... I see you've added a bit to the master branch, but not directly related to upgrading? Anyway, shout if there's anything I might be able to help with! :-) I'm still working on my LaTeX output stuff.

— Sam Wilson ( Talk • Contribs ) … 03:09, 5 December 2013 (UTC)

I'm starting to compare my version of the MediaWiki files with the original 1.7.1 files. Once I've found all of the changes, I'll post an issue for each one on the github repo for the wiki. I will also review all of the MediaWiki hooks that are currently being used, and I'll create issues for any hooks that do not appear in the latest version. I'll start posting issues tomorrow. The next step will be to discuss each issue: what's the best way to implement the functionality without making core changes in the latest version of MediaWiki. I would love to get your involvement in those discussions. I don't want to make any more changes to core, so we may need to forego some existing functionality as part of the upgrade. Once we have a plan to handle the migration issues, I can create a new branch of the wiki repo and we can start assigning tasks to people who are interested. How does that sound?--Dallan (talk) 22:14, 6 December 2013 (UTC)

A proposal to start fresh

As I've been looking at the custom code for WeRelate, the thought occurred to me: what if we were to start from scratch to create a genealogy wiki? Most of the WeRelate code was written over five years ago, not following the conventions that are used today. Starting from scratch would yield code that was easier to maintain in the long run. And it might be better to use templates or SMW or Wikibase instead of the XML islands that are currently used for storing structured data.

If we could reach an agreement that this new project would become a WMF sister project, I believe I could use that to raise $10-20K to help fund its development, and I could migrate the existing WeRelate users to the new site. We could work with Rodovid and others to migrate their data to the new site as well. Is there interest in this?--Dallan (talk) 13:34, 26 January 2014 (UTC)

It is just merely my opinion, but I think that WMF resources are concentrated more on Wikidata right now . And as you mentioned if we want to make a new project on top of Wikidata, first we need to have the full support of Wikidata (including queries and so on). So maybe it is just not the proper time for WeRelate? --DixonD (talk) 09:11, 27 January 2014 (UTC)

As I look more into Wikidata, it looks like a perfect solution. Maybe it's not the right time yet - I can wait until it is. Would it make sense to begin a proposal now though to see if the project was something the WMF would accept once Wikidata is ready? Having a proposal accepted contingent on Wikidata being ready would make it easier for me to raise money for development, and starting to work on a proposal would give me, Rodovid, Familypedia, WikiTree, and others time to reach consensus on how to integrate the databases so we'd be ready once Wikidata was ready. What do you think about starting a proposal now? If people like the idea, how would I go about doing this? How long do you think it will be before Wikidata is ready?

Specifically, I'm thinking about a project that would allow users to create, edit, and read language-independent Wikidata items about people, along with language-dependent wikitext about them, whether or not the people were notable. When a user began to create a new page for someone, they would be prompted to review existing potentially-matching Wikidata items to avoid creating duplicates. Sources for each property of a person would be strongly encouraged, and an item without any sources would not be allowed. I'm thinking that only people with one or more sources would be imported from the existing wikis, and that potential duplicates would be reviewed and merged by users on import. By putting these requirements in place I hope that Wikidata repository would become a source of reputable genealogical information about people - something that none of the current large online genealogical databases provides.--Dallan (talk) 23:01, 27 January 2014 (UTC)

I'm not so sure it's a good idea to merge WeRelate with Wikidata, since you'd have to merge the communities as well. For example, if WeRelate insists on stricter sourcing requirements than Wikidata does, we could end up with a lot of unnecessary conflict. Therefore, it might be better to make a new site using Wikidata's software, but with a different set of data meant for genealogy. -- Ypnypn (talk) 01:49, 28 January 2014 (UTC)

Ok, that makes sense. I figured that if Wikidata is where WMF projects will be storing structured data, that we would want to have a single database about people. But I could also see having a separate database with stricter sourcing requirements. If it's stored using the same software, it would be perhaps not too difficult to compare and/or copy data from one to the other, assuming that was desirable. What do you think about the proposal in general? How should I begin?--Dallan (talk) 03:20, 28 January 2014 (UTC)

I think we should try to obtain consensus from the Wikimedia community through a formal Request for Comments (RfC), similar to how Wikivoyage's successful RfC. To do this, we could make a page Requests for comments/WeRelate, and open a well-advertised discussion. If this gets significant support, we could formally ask the WMF board for approval. -- Ypnypn (talk) 14:23, 28 January 2014 (UTC)

Thanks for the pointer. I'll review Wikivoyage's Rfc, bring this up in our "WeRelate overview committee" meeting on Sunday, and create the page Sunday night.--Dallan (talk) 03:26, 29 January 2014 (UTC)

I think that it is a good idea to try to create this united Genealogical Wiki (for example WikiGenealogy) with the following important founding principles:

• 1)Multi language support (like Wikipedia and Rodovid). All family relations are the same in all languages. For universality each person should have at least english version.
• 2) Alternative family relations are allowed only by links in notes and discussions (no multiple mothers or fathers in the main tree). Adoption fathers/mothers links allowed only in notes.
• 3)Duplicated persons forbidden.
• 4)Mythological and fantasy persons not allowed in the wiki tree (reinforced by simple formal rules: estimation of the birth or death date are always given, no mothers before ~10 and after ~60, no fathers before ~10 and after ~90 years, no persons living more that ~140 years (exact numbers to be discussed).
• 5)Sources obligatory, but flexible as in scientific articles: strong sources (birth/death certificates, census, books, articles, graves etc) has priority for definition of the family links and weak sources (private communications, www links, memoires etc) are tolerated if they do not contradict strong sources or common sense rules. The proportion of the strong and weak sources may be different for different regions or historical periods. One should not discriminate the regions and periods, where the archives were destroyed or in a bad shape. If we put too strict rules for sources we will end up as the genealogical wiki only for US/GB, not for the full world.
• 6)No discrimination between notable (vip) or ordinary people.
• 7)Living persons allowed only if they have already personal pages on Wikipedia or if they give explicit agreement by signing special www form on the site.

On top of these fundamental principles few pragmatic points are important:

• 1)Good GEDCOM import and review system like in WeRelate for all users.
• 2)Special effort by few administrators to import best quality GEDCOM's from different regions for the period before 1700, before opening the project to most of the users.
• 3)Good multi generations trees like on Rodovid (in WeRelate trees are limited in number of generations (10)).
• 4)Tools for easy import (including review) the persons and families from Rodovid, Familypedia, WikiTree into WikiGenealogy. This import process may take some time to unite the communities, agree on the same standard of sources, clean the mythological, junk and duplicates.--Alexandre.rozanov (talk) 18:18, 10 February 2014 (UTC)

These points seem reasonable.

• I'm actually wondering if we should stop GEDCOM uploads. GEDCOM's often contain a lot of bad data, and it doesn't take that much longer to enter information by hand than to upload a GEDCOM and clean it up after the fact.
• If there are disagreements about parentage and we don't allow alternate parents except in notes, who gets to decide which set of parents goes in the parent fields and which go into the notes? Also, what happens when someone wants to record biological and adoptive parents? It seems like multiple sets of parents is something we'd want to support as an exception rather than the rule.
• Where in WeRelate are trees limited to 10 generations? They may be, but it seems like an arbitrary limit rather than something baked into the software. I'm curious where you found this.
• Do these other sites support GEDCOM export? If so, we could use the GEDCOM importer to import them, and maybe turn it off after we finish for the quality reasons listed above.
• I'm going to look into the Wikibase extensions to see if we can use them to make a multi-lingual site from the start. This seems like the best way to go, even if it delays things a bit.

--Dallan (talk) 03:10, 14 February 2014 (UTC)

Here are my answers and comments:

• I'm actually wondering if we should stop GEDCOM uploads. GEDCOM's often contain a lot of bad data, and it doesn't take that much longer to enter information by hand than to upload a GEDCOM and clean it up after the fact.

For short GEDCOMs you are right, but for GEDCOMs with several thousands of persons it is not practical to enter them by hand. If you will not allow GEDCOM import you will push away too many genealogists. In order to reduce the work of cleaning some small improvements in the GEDCOM import software are needed. For example correct bugs like +TITL, +BURI events, automatic Upper/Lower case control option, better doublication person search algorithm etc.

That may be. But we would need to set high quality standards on GEDCOM imports so we don't end up creating thousands of unsourced pages with every import.

I agree. One possible action could be to require during Review that at least 80% of new persons from GEDCOM should have the source.--Alexandre.rozanov (talk) 16:59, 15 February 2014 (UTC)

• If there are disagreements about parentage and we don't allow alternate parents except in notes, who gets to decide which set of parents goes in the parent fields and which go into the notes?

We have for that the discussion page to discuss which of the parents is more probable and that person is marked as a father/mother. All other potential candidates for father/mother are also introduced in the database, but the link to them as potential parents is given only in the notes with the appropriate arguments why this parent is less probable, but not excluded. The advantage of Wiki is that with the arrival of new documents and/or genetic markers this can be always corrected by future genealogists.

• Also, what happens when someone wants to record biological and adoptive parents? It seems like multiple sets of parents is something we'd want to support as an exception rather than the rule.

We should plan for longer term future. In few years the genealogy of any person will be possible to reconstruct or cross-check from his genetic code. So the only reasonable definition of the father/mother in the tree is the biological parent. The link to adaptive parents should be indicated in the notes with corresponding explanations. The attempts to hide the adoption in the modern world with genetic code methods are useless and will produce only confusions and conflicts in future.

Others will likely want to chime in on this. I'm happy to go along with the consensus.

• Where in WeRelate are trees limited to 10 generations? They may be, but it seems like an arbitrary limit rather than something baked into the software. I'm curious where you found this.

If you launch FTE you can see only up 10 generations up and 10 generations down. If you know the hint how to increase it, i will be interested to know.

The "Family tree" link near the top of every person page is a better approach for the future than the FTE. It's written in javascript rather than flash, doesn't have a 10-generation limit, and doesn't require everyone in the tree to be in your watchlist. We could easily make it a full-screen Special page, with person-page links opening in separate tabs.

That "Family tree" is a very good tool, but it has two main problems: 1)by defaults it shows only 4 generations up. So to see many generations up or down one should do a lot of clicks on "+". That in unpractical for big trees. The solution could be to leave 4 generation by default, but give to the user two parameters: number of generations up and down to be displayed like in FTE, but not limited to 10. 2)In case of common ancestors they are duplicated in "Family tree". This is certainly much more complicated to program, but in Rodovid programmers managed somehow to avoid duplications in the graphical trees.--Alexandre.rozanov (talk) 16:59, 15 February 2014 (UTC)

• Do these other sites support GEDCOM export? If so, we could use the GEDCOM importer to import them, and maybe turn it off after we finish for the quality reasons listed above.

The Rodovid site had GEDCOM import at the beginning, but they quickly closed it, because they are missing automatic identification of double persons and Review software. Rodovid developers has no free time to develop this software and this is the main critics of users toward Rodovid. WikiTree has GEDCOM import, but with a lot of bugs, so many GEDCOMs could not be loaded. I think that the strongest advantage of WeRelate to respect to other genealogical Wiki sites is the GEDCOM import and review software focused on the elimination of double persons.

What about GEDCOM export? If the other sites supported GEDCOM export, then it wouldn't take much to export GEDCOMs from those sites and import them into the new site.

WikiTree support GEDCOM export. Very unfortunately Rodovid does not support GEDCOM export now.--Alexandre.rozanov (talk) 16:59, 15 February 2014 (UTC)

• I'm going to look into the Wikibase extensions to see if we can use them to make a multi-lingual site from the start. This seems like the best way to go, even if it delays things a bit.

One more important feature is the GEDCOM export. Many users will be more confident to start introducing their trees into site similar to WeRelate if they will be sure that at any moment they can export their tree to GEDCOM if they want to change to another site or look on the tree on the local PC.--Alexandre.rozanov (talk) 16:20, 14 February 2014 (UTC)

WeRelate currently supports GEDCOM export.--Dallan (talk) 03:53, 15 February 2014 (UTC)

Thanks a lot for pointing into it. It is a very good feature of WeRelate and i already tested it.--Alexandre.rozanov (talk) 16:59, 15 February 2014 (UTC)

Question about editorial policy

I've raised the question about joining WMF to users at WeRelate. One of the big questions that's coming out in the discussion is whether WeRelate would continue to maintain their own editorial policy independent of the policy of other WMF projects like Wikipedia. I've been operating under the assumption that WeRelate would continue to maintain its own editorial policy and use its own administrators. Can anyone tell me if that is true? Should I ask the people at WikiVoyage?--Dallan (talk) 19:42, 19 February 2014 (UTC)

WeRelate would keep its own administrators, although stewards appointed here would be able to act as admins under extremely rare circumstances (such as if all WeRelate admins resigned). And WeRelate would keep and decide its own policies on almost all issues. However, there may be some issues where the WMF cares enough they'd override local policies. For example, they refused to implement an en.wiki consensus to limit new article creation to autoconfirmed users. -- Ypnypn (talk), who also commented on the WeRelate discussion: 21:24, 19 February 2014 (UTC)

Thanks for the information. (BTW, WeRelate limits editing to users who have confirmed email addresses. We significantly reduced (but did not eliminate) spam problems when we did that.--Dallan (talk) 23:05, 19 February 2014 (UTC)

Incidentally, you may want to check out mw:Manual:Combating spam for more ways to do so, including requiring a CAPTCHA to add external links, or using the AbuseFilter to selectively proscribe such links, etc. But if you feel strongly about this (and I certainly understand if you do), you may want to contact a WMF board member or the like directly, to see if this would be a big issue with them. -- Ypnypn (talk) 01:27, 20 February 2014 (UTC)