Ok, so now I have my screenshots, but I still have no idea what I am looking at.
I think there are two basic problems with genealogy.
1. Genealogy is a time-series problem. What existed in 1400 is not what exists now.
2. Genealogy is a massively parallel task. What I am working on is tied to what you are working on, it is just a matter of time before we step on each others work.
This thread is not really concerned with the first, so I will leave that for now.
2:
If we are going to merge your genealogy to mine, we need some mechanism to do so. We have to be able to identify and resolve conflicts, and knit parts of the trees together that match.
With nFS, this is a HUGE problem, since we have a massive amount of work that has been siloed for a long time. Now we need to merge this work together.
We can learn a lot about the way to solve this problem by looking at existing systems that solve similar problems. I offer a few examples.
Source code repositories are the industry standard way of getting large teams of developers coordinated on large code repositories. These systems can be very simple, from one-at-a-time, to auto-conflict resolution and submission filters that check the code for certain attributes before allowing submissions (whitespace comes to mind). Often these systems are also part of a larger system that runs a sanity check (nightly build) periodically to verify that no critical parts fail (nightly unit testing).
Wiki's are large collaborative documents that almost anyone can modify. A few interesting trends have come from large wiki projects like Wikipedia. Most Wikipedia articles have an adoptive editor. These people protect the pages from malicious editing and obvious erroneous entries. These editors are often not permitted admin or moderator rights, they simply build a reputation for correctness. Editors also often report other users to moderators for more drastic corrections.
Wikipedia articles that are unstable are marked as such. Most of these pages do not allow edits to the main page without first agreement on the 'talk' page. Articles are also marked if they contain usable, but problematic information, or if other editing is needed.
Many open source projects have large repositories of bugs written by the user community. These bugs are often incomplete, vague, erroneous, or otherwise useless. Buried in these lists are bugs that are well written, complete and important.
Bugzilla uses a voting system to push good bugs up, and allow bad bugs to stagnate. Voting does not remove or add a bug, but only can elevate the status of existing bugs. Viewing voting statistics shows the relative importance of a bug.
All of these systems have a few things in common:
1. They all require the author to be identified. In rare cases, this is only by IP, or some other non-deterministic name. Generally anonymous users are not given the same privileges or deference to identified users. Users build credibility by with meaningful identified contribution.
2. All these systems require the contributor to justify their contribution with some sort of message. The contribution is judged by its content, AND its stated purpose at submission. Often, contributions that would otherwise be acceptable are rejected because their justification does not match the actual submission.
3. All of these system keep a complete change history. Deletions are rare, and normally only permitted to privileged users. There is always a history of all changes made, and often an easy mechanism to go back to a previous version.
4. General consent is needed before accepting a submission. Sometimes (seems half of my examples) this is implied by lack of action reverting the change. Systems that offer simple methods to roll-back changes seem to use lack-of-action. Systems that are more difficult to roll-back use more overt methods of change acceptance.
So, I don't think that answers any questions as to the way sorting should be done
. I do think it gives a good argument for the four points above to be included.
Personally, I will stick by my stance that genealogy needs to be built in a version control system like software. I think I should have my genealogy 'branch' and I should be responsible to resolve conflicts between it and the 'trunk' version of my genealogy. Only uncontested, well verified information should exist in 'trunk'.
So, if I were to sort the above. I would only show my submitted information. I would mark records that conflicted or partially matched other submissions. I would then have the option of merging the two records, or staying with my own record. I might make it possible to adopt parts of another record without merging the whole record. If I wanted to see the other records submitted. I would select the contested record and run the conflict tool to see the other records and their conflicts with my own.
Barring that, I think I would prefer the ability to filter out the records that I did not submit, and the ability to sort by submitter, or by some other criteria (like DOB or name).
I find it problematic that some information (like submitter) would be only shown in the record color. That may cause accessibility problems.
The Earl
