Template talk:Person

Based upon the level of interest shown in this area, I'm going to add pedigree uploading sometime during the next few months. I'm thinking that a wiki page would be created for each person in an uploaded pedigree. The question is how to balance allowing anyone to edit the pages against the idea of maintaining what the original pedigree submission looked like. I hope to work up a proposal over the next few weeks and request comments. I'd love to hear people's ideas on this topic in the meantime.--Dallan 22:00, 17 March 2006 (MST)

Topics


Model

It is my opinion that the model should follow close to that of wikipedia.org. Users would upload their gedcom files directly to the site, and their entire family tree would be represented in wiki pages, with each individual and each family (as defined by the GEDCOM format) getting a page.

Then, as time goes on, people will merge together people that they believe to be the same person. Some may express concern with other people editing their ancestral line on the wiki, with the fear that they will mess up the data. While it is true that some may make misinformed edits of people or families, it should be easy to fix the problem. Each page (individual or family) can be watched by users, which means that they will get an e-mail when a person or family page is changed.

When I first heard about wikipedia, I marveled at how it could even work because I thought that everything would be quickly messed up by the misinformed or malicious bots. But it really is pretty neat to see how the wikipedia articles are able to settle to a consensus of what people believe to be true. I believe that the same thing will happen with the community genealogy pages. The truth will come out through consensus, sometimes after heated debate. I believe the data will settle close to the truth as people do things such as cite good sources.

The way that wikipedia controls vandalism and denial-of-service attacks is to simply block certain IP addesses or range of IP addresses.


Middle-Road Model

Now, Dallan has mentioned taking a middle road path between:

  • The wikipedia open way
  • Having users keep tight control of all of their uploaded data

In this middle road, the original user's data would stay intact and only be editable by the user himself. A copy of the original data would be created in the community to be edited by the public. Each of the individuals or families in the user's space would point to those in the community space, so that the user can easily see the changes that other people made, and he would have the option of incorporating those changes into his data, and vice versa.

I believe there are two additional problems with this method:

  1. It's confusing and complicated for the user. In order to properly use the site, they not only have to learn how to upload and edit their data, they also must:
    1. Learn the difference between community and user-space data. Many users will be mistified as to why changes in one space are not reflected in the other
    2. Learn how to merge community data with their own. This problem becomes more confusing and time consuming, and perhaps even frustrating, as the user is trying to keep their user data up to speed with the community changes.
    3. Learn how to navigate between personal and community space.
    4. I think most normal users will think it's strange that they have to deal with two sets of the same data, because they know that they only have one set of ancestors.
  2. Because the user has his data that only he can update, it seems likely that the user will feel more obligated to update his user space data, and will often forget to update the community pages. In this way, the user space would become little more than just another fancy GEDCOM editor, with lots of little separate family trees.

If the user wants to keep control of their own data, all they have to do is continue using the PC or web-interface programs that keeps their data naturally separate.


How I Would Use It

And if it were my GEDCOM, my data, I would want everyone to be able to change my stuff. Then, I could look back later, view all the changes to my data, and feel like my data is getting better practically on it's own. I would tend to not bother with the user space, because I know that it would soon become hopelessly out-of-date compared to the community version anyway. If there were any changes I disagreed with, I would simply change it to how it should be, and site a source or give a sound explanation as to why.


Needed Features

Some of the features that would be needed include:

  • Ability to easily upload their GEDCOM file. The user shouldn't be forced to match/merge everything right away. That is a process that could take weeks or months of effort.
  • The ability to download a pedigree of any individual
  • A program which lists persons that are likely matches to people that have been updated.
  • A user should be able to select an individual or pedigree that they are interested in. The system would then overnight or over time create a page which lists individuals in the interested pedigree that have matches.
  • The ability to easily merge individuals and un-merge them. This is a little bit tricky because it doesn't seem immediately obvious what to make the wiki-page names since many people have the same names. Maybe we need to some sort of naming convention for individuals and families. This is also a little bit tricky because all links to the merged individuals and families need to be merged as well as unmerged. I guess this might be taken care of in the history features of wikimedia?
  • Support for all of the attributes of GEDCOM, including notes and sources.
  • Ability to view standard pegigree chart would be really nice.
  • Ability to put a "watch" on an entire pedigree would be nice.
  • The user page has automatic or special links to parents or ancestors in the pedigree chart. That way, if any of them are merged, I will still know who my ancestors are in the community. (It would be sad to lose one's own ancestors, now wouldn't it)? :)

Conclusion

Anyway, I'm really excited about this feature because it means that my family and I will all be able to work together on our genealogy, and we will all have instant access to the most updated version. --Nathan Powell March 19, 2006 6:14 PM MST


Another proposed model

I agree with the problems with the "middle-road model" outlined above. It seems to onerous to require people to update two sets of changes. The underlying problem that needs to be addressed is that some people will be wary of allowing others to change their genealogy. Although they could watch all pages generated from their gedcom and be notified of changes, their might be a concern that they would miss some "bad" changes. They also want a way to share their version of their genealogy with others, that didn't include facts that were added to the person page but which they personally didn't agree with. The question is how to address these two concerns with a minimum of effort.

Here's another idea:

  • When I upload a gedcom, a "gedcom page" is created that contains links to all of the pages generated from that gedcom. What's important is that the page also identifies the version of each page. This page would also contain a link to the gedcom file I uploaded.
  • There is a function that allows me to see the differences between the versions of each of the pages listed on my "gedcom page" and the current versions of those pages. I can "accept" these differences, in which case the versions listed on my "gedcom page" are updated to the current version, and the gedcom file is updated with the latest information (allowing me to download it). This function also allows me to add new people linked-to from the people listed on my gedcom page but which are not currently in my gedcom.
  • If I disagree with one of the changes, I don't accept it, and I talk about my reasons for disagreement on the page for that person.
  • Merging individuals is done by moving pages (mediawiki already allows this, and does a redirect from the old page title to the new one) and semi-automatically merging the content. Unmerging is done by manually creating a new page and copying the information into it. Unmerging is hopefully a less-frequent function so I hope we don't need to automate it as much.


What do people think about this approach?--Dallan 12:50, 20 March 2006 (MST)