Allow users to "lock" a person or couple's records from being edited.

LegacyUser

Cathy Anderegg said: One more thought. Kathryn's last comments are really smart. Good going.

And Family Tree is already a little schizophrenic with one side being Open Edit and the other being Read-only locked records. So let's push the envelope a little further and try Kathryn's ideas, or at least some of them.

LegacyUser

russellclintonduncan said: Great ideas, Kathryn! I almost think your post should be re-submitted as a separate idea. Otherwise, it may never be considered if it remains part of this discussion thread.

LegacyUser

Kathryn Grant said: Thanks, Cathy and Joe!

Cathy, I really like your idea #7. I don't think most people are malicious; they just don't really understand what they're doing. Validations such as you propose would be a huge help.

Joe, good point about relationships! I hadn't even though about that. Perhaps the lock could be put on the relationship itself--e.g., you'd have to go into the couple page to lock the relationship between a husband and wife.

I think the relationship locks themselves would have to be one-to-one. In other words, you'd only ever lock the relationship between one person and one other person at a time. But any person could have locks on any of their relationships: child to parent, spouse to spouse, etc. And a person who had more than one spouse or child could have a lock placed on the relationship with each one.

It sounds like there is some concern about the word "lock." I have mixed feelings. I like the implication that if something is locked, you shouldn't just change it on a whim. However, it might also give the impression to users that they can't unlock it, leading to frustration or support calls.

Russell suggested "approve" as an alternate. Going along with that, what if we used a green check mark instead of a lock? Hopefully people would think twice about changing information that has been "approved" or perhaps "validated."

LegacyUser

Landucci said: "Secured" or Protected" might be a good terminologies to use. Question: In your example above, I am assuming that if someone wanted to lock (secure) a marriage of say their mother and father they would also want to prevent other spouses from being added to the known single marriage (assuming that fact is indeed known). How would you secure it so that not only the husband and wife are "locked" but also that extra spouses (or for that matter, that extra children) were not added? Or that duplicate listings of the"locked" or not locked husband and wife did not show up as multiple parents for the children? You would almost have to secure a whole family unit to achieve the desired result.

LegacyUser

Kathryn Grant said: Hey, I just thought of another reason the green check marks might be more effective than lock icons. The green check marks could become a visible sign of trustworthiness. People might actually start wanting to have as many green check marks as possible. Check marks might become a motivation for people to be more thorough and careful in their research and documentation.

The number of check marks could even be translated into a trustworthiness rating at the top of the page. Maybe that's going a bit too far... but after all, FT is a collaborative site, even a social site. Evidence of reliability or trustworthiness can be an important component of a social site.

Joe, Russell suggested resubmitting my ideas as a separate post so they don't get lost. Since you've seen the original post, could you advise if it has enough visibility through you, or if it would be beneficial to start a new thread?

Landucci, you bring up some great points. I hadn't thought about those scenarios. Maybe this idea would have to be implemented in two phases: one for data (birth dates, death dates, etc.) and one for relationships. I think the relationship component would be a lot more complicated.

LegacyUser

Jade said: Kathryn said "I like the implication that if something is locked, you shouldn't just change it on a whim. However, it might also give the impression to users that they can't unlock it, leading to frustration or support calls."

Since FS-FT is largely composed of highly erroneous tree material that was entered into n.FS, it is likely to be believed by the hordes who have adopted/copied/promulgated the same or very similar tree configurations. Such treebies as are still living may object to changes made due to evidentiary research.

For example, I had a protracted discussion with a person who entered data for Ben C. saying he was siring children as late as 1859, and listed as his children those of his brother who were named in brother's will and estate records and actual parents given in the children's marriage and death records. The treebie did not agree that Ben C. had died in 1809 and had his own set of children (his and wife's identities established by sale of lands inherited from Ben C.'s father, denoted by will and by deed, as well as by their tax and estate records). Treebie's only reason given for her version was that this was published in X genealogy. I provided all the documentation I had. Treebie ceased responding to my messages.

When treebies can erect barriers to evidence-based changes, there will not be an incentive for actual researchers to go to the trouble to try to enter correct data. Especially if the program (being incapable of analytic thought regarding evidence) begins rewarding such barriers.

So go ahead, folks, institute voting by persons who mostly do no actual evidentiary research, add 'like' buttons and green check marks for mostly those who believe the 5 erroneous published genealogical accounts ("sources") and 138 online trees ("sources") regarding person X. And a star or numerical rating system.

FS-FT will then probably continue to be mostly populated by Widely Held Mistaken Beliefs. I think few evidentiary researchers will regard it as worth any more attention than the many other mostly-wrong internet-hosted trees.

LegacyUser

Kathryn Grant said: Jade, you make excellent points and I know many of us share your frustration.

Based on Jade’s input, I would modify my proposal as follows: legitimate sources (see item 2 in the first section of my proposal post above) do not include user trees. The system could either disallow them as sources, or at least they would not qualify for a green check mark of approval.*

Jade, under my proposal, “treebies” could not erect barriers to evidence-based changes—just the opposite. Here’s how your situation could be handled. For illustration, I’ll assume that Ben C’s record starts out with no legitimate sources and no green check marks to indicate proven data. I’ll also assume, based on your experience with this sister, that she is not open to evidence and just wants to insist on her view of things.

Scenario 1:

1. You add legitimate sources to data elements of Ben C’s record, which are then “approved” with a green check mark.

2. The sister removes your approval. She has to say why.

3. The sister tries to add an unsourced user tree as a source (probably from Ancestry, RootsWeb, or the Genealogies tab of FamilySearch). The system warns her that it does not qualify as an approved source. She can attach it, but data she tries to support with it does not get a green check mark.

4. You are immediately notified that your approval has been removed and you report abuse, supported by your evidence and your attempts to resolve the problem directly with this sister.

Scenario 2:

1. Let’s say, for the sake of illustration, that the sister manages to add a spurious user tree to have her assertions “approved” (maybe she links to some obscure tree that the system doesn’t disallow).

2. You see this, remove the approval, and add your own valid source which is approved. She cannot stop you from doing this.

3. If she insists, she can try to remove your approval. But she has to give a reason, and again, you are immediately notified and you can report abuse.

I know this is not perfect, but I think it could be a big step forward from the current “free-for-all” situation in Family Tree.
____________________________________________
*As much as these unsourced, error-laden trees frustrate us, they sometimes provide clues that lead careful researchers to valid information. So I wouldn’t want to make it impossible for them to be referenced. BUT... I think a warning should be put on them!

LegacyUser

Randy Hoffman said: You nailed it, and I agree that a second post should be added. Although I think the API could be designed to allow 3rd parties to unlock the data through the same process as the website.

I also feel that this could help me in my research in that I could treat the locks as a way to check off what I have proven.

I also would still like to see some sort of arbitration process involved in locking and unlocking.

LegacyUser

Randy Hoffman said: Or the lock could include a tool tip that says "Click to unlock"

LegacyUser

Randy Hoffman said: I also think that the barriers are small enough to not discourage others. I think the evidence-based researchers would be very happy to see that their data has a little more protection than in the past.

LegacyUser

Randy Hoffman said: Joe would have a much better answer than me, but I assume the data model roughly has points, which are people, that are connected to each other through lines, which are relationships. I assume it would be possible to say "This line cannot be touched," or "these types of lines can no longer be added."

You would then have to secure each relationship based on evidence, which gets so complicated that it may not happen. For example, if you lock the parent-child relationship between two individuals, you probably also want to prevent anymore parents from being added to that child or children to that parent. However, you would have to provide evidence that the child was never adopted, fostered, etc. and evidence that the parents have no more children.

LegacyUser

Kathryn Grant said: Randy, I think it would be okay for 3rd party programs to allow locking and unlocking (approving and unapproving) of data. I just wouldn't want them to override blindly any existing locks.

As far as arbitration, maybe that happens when someone reports abuse? (See my response to Jade's concerns below...)

LegacyUser

Randy Hoffman said: I like a green check mark approach as well. Everyone loves green check marks.

LegacyUser

Randy Hoffman said: I think I would still like to see it before anything gets locked down. I think there should be a small barrier to locking and a small barrier to unlocking. However, until details can be worked out, I would take a green check mark and a pop-up over what we have now.

LegacyUser

Kurt Matthia said: I serve at international reference in the Family History Library and see many who put too much trust in the printed word. I often have to explain the difference between primary and secondary sources. Even the Ortsippenbuch for one of my family towns has many mistakes.

I am not as bleak about this as you are Jade, but we need to educate our users. What about a pop-up tip that appears when first clicking on Family Tree. State the concept and provide a link to a great and succinct page in the Wiki to open in a new window. I wouldn't let a user stop the tips until they get some kind of certification. I often leave the tips on in my complicated software long past the time that I am functional.

LegacyUser

Kathryn Grant said: And proving that something never happened, such as a marriage or adoption, is a lot more difficult than proving that something did. We can say that we can't find any evidence of it, but that doesn't mean we might not find something later on.

As Jade pointed out, people can hide portions of their lives--brief marriages, deceased children (I read of one case where a grieving mother literally blocked a deceased child from her mind).

LegacyUser

joe martel said: Kathryn, keep things going on this thread otherwise we have to track two different threads.

LegacyUser

Kathryn Grant said: Thanks, Joe--that's good to know. We'll keep the discussion on this thread.

LegacyUser

Jade said: Kathryn, I appreciate the thought you are putting into this problem of factual inaccuracies in a Wiki format.

The "report abuse" item has to have an outcome implemented by at least one person.

Judgment as to abuse is not necessarily related to judgment as to validity of evidence.

Say person A enters a string of evidentiary documentation regarding family identities, all properly cited through source box. Then person B enters a string of properly cited genealogies and changes a bunch of stuff in the same family. The FS-FT would have no way to judge what is accurate (in two of my family lines it is the 5 published genealogies that are wrong on key ancestral points).

Is there really going to be a panel of arbitrators, among whom one can take a day to look at the pertinent stuff in the books plus all the actual documentation, and draw a genealogical conclusion as to accuracy? What if the documentation group was insufficient to the arbitrator's mind? Think of the DAR's problems with examining documentation for completeness and accurate conclusions. Think about why Wikipedia's arbitration procedure is chiefly based on whatever is published on the internet -- for a person who has done original non-internet research that leads to a different conclusion about someone or something that is in Wikipedia, it can take months of struggle by the researcher to get the arbitration panel even to consider such research, let alone acknowledge that the research was properly done and should govern the Wikipedia item.

Part of my counterpoint here is based on experience with some old northern-WV families about whom much speculation and lore has been written by folks who did sometimes copy from genealogical files in a library but only one ever set foot in a courthouse or archive, and he mostly did not make use of the documentation that was there anyway. This area's genealogies are beset by ardent book/tree believers who do not play nice.

LegacyUser

Kathryn Grant said: Jade, I appreciate your reply. You're right that the assertion of abuse would have to be arbitrated. These types of details would have to be worked out if the decision is made to implement a proposal like the one I made.

I also agree that judgement as to abuse is not necessarily related to the validity of evidence. In the scenarios in my post, I considered the woman's actions abuse because she removed your approved evidence and didn't supply trustworthy evidence in its place, and she refused to discuss the evidence with you. Rules for what constitutes abuse would have to be clearly specified.

Another observation: under my proposal, the scenario you describe above couldn't happen, because so-called "genealogies" would not receive a green check mark. Green check marks or approvals would only be given to data supported by "legitimate" records—by that, I meant (reasonably) trustworthy sources such as birth, marriage, and death certificates, parish registers, civil registrations, wills, land records, court records, etc. Hearsay (genealogies, DAR applications, family traditions, etc.) could be attached as sources to person records, but they could not be used as proof resulting in a green check mark.

Which records qualify for green check marks would also have to be worked out.

If no trustworthy records are available, the data just doesn't get a green check mark. And that's okay: sometimes the records we want simply don't exist or have been destroyed. People would understand that data without a green check mark simply lacks evidentiary documentation.

Thanks again—I don't know if the ideas I proposed will amount to anything, but your comments are definitely helping to refine them.

LegacyUser

Randy Hoffman said: I noticed that you said the green check mark would not be given unless there was a legitimate record. I don't think that can be built into the system, so are you suggesting an arbitration of some sort before the green check mark is given?

LegacyUser

Kathryn Grant said: I just realized I should clarify what I mean by "couldn't happen" above. I just meant that (under the rules I envision) that no one could use hearsay to add or remove a green check mark. If the case went to arbitration, the rule disallowing hearsay would be enforced.

But again, that's just what I envision. The details would have to be worked out.

LegacyUser

Kathryn Grant said: Randy, it wouldn't be foolproof, but here's one way it could work:

1. For records available on FamilySearch, there could be a database table somewhere that flags each record type as "legitimate" (i.e., green check mark-worthy ) or not. For example, England Births and Christenings would be legitimate. Genealogies contributed by users would not. When those sources were used, the system would know if they were "legitimate" or not.

2. For records not on FamilySearch, the Add Source page would require users to specify the type of record (probably by clicking a radio button or selecting a record type from a dropdown list). The system would only allow green check marks for "legitimate" record types (again, as defined by the system).

If a person attached a user genealogy and called it something else just to get a green check mark (a birth record, for instance), other users would be able to correct the erroneous record type.

If FamilySearch decides this is an idea worth pursuing, there are clearly a lot of details to be worked out

LegacyUser

Randy Hoffman said: For option 2, I feel that it is starting to get too complicated. I would rather have one process for both types of records. I would prefer if, when you try to lock a record, an arbitrator looks at the attached sources and verifies that he data supports the conclusion (to the best of his or her ability), and that it is not a compiled source.

LegacyUser

Cynthia Louise Van Dam said: I like the idea of green checks on well sourced facts, (not published genealogies) it seems too complicated to make checks for each fact and each relationship, especially when we can tag sources.

LegacyUser

Landucci said: Just throwing out another scenario which may not even make any sense. Just an off the wall idea to dissect and scrutinize.

What would happen if the “report abuse” was tackled from the other direction. Let say that someone wanted to “protect” (for lack of a better word) their immediate family such as siblings (of course deceased), their parents, their grandparents, etc. or some other portion of their family ancestors. Also assuming that there is a way to “grant” ownership of said section to an individual (or group of individuals) within the FT program once that section has become fully documented via verifiable sources.

Now, along comes someone with new or different information that they want to incorporate into that “protected” section of the tree. Once an attempt is made to ADD new or EDIT the existing info the new contributor would be directed to contact the person(s) who were granted custody. A Discussion to review the new info (via emails or an open Discussion) would follow and hopefully resolve any issues BEFORE any changes can be made. After that a few different scenarios could play out: 1.) an agreement is confirmed and the new “error free” data is entered with all follow through of merges, duplicates being addressed, and sources added, 2.) a dispute is initiated via a Discussion which could pull in higher and higher levels of authority (requested by either party, if necessary) to review the claims and eventually come to some compromise, 3. the “caretaker” could totally refuse to address the new information.

Here is where the “report abuse” would switch around. In the latter case the “caretaker” would be reported for the abuse which would then be reviewed by a higher authority with the possible removal of his “grant” for that section of the tree. This would help keep the caretaker’s objectives directed toward a flourishing FT and the solving of all disputes. There could also be multilevel backup contacts for the particular section of the tree just in case the main contact is unavailable (a 24 hour window) or heaven forbid, no longer with us. These “grants” would be fluid wherein the caretaker would have to verify their continued interest in maintaining their commitment to the “grant” by verifying the public’s accessibility to them (let’s say on a monthly basis). If they lose interest or fail to comply to the email verification the result would be the removal of the grant or it could be made available to others. The caretaker would not want to lose this grant so most disputes would be resolved quickly with only a few being resolved by an arbitrator.

The advantage for the caretaker is that they would be kept appraised of all attempted changes beforehand but they would not have absolute power to keep (lock) everyone else out. Something like this could be used to “protect” specific data such as birth dates, etc as well as the relationships between individuals. Hopefully this could provide an environment where mandated Discussions would keep disputes resolved and prevent bad data from creeping into well maintained sections of the universal family tree. Feel free to criticize as I have not fully thought this through and it may not even be forth discussing.

LegacyUser

Kurt Matthia said: The idea of an individual (not a corporation or organization) locking/watching records just doesn't appeal to me. The major problem is that we have not solved the "digital legacy" problem.

How and to whom can I pass "ownership" of my watch list, photos, stories, source box, etc. to when I become disinterested, die or become incapacitated?

For non-LDS accounts, you can probably just give someone else your log-in information and no one will be the wiser. However for Latter-day Saints, the day their death is reported to the ward clerk their account will become inaccessible. The same issue affects my notebook, scripture markings, and study journal entries.

We need to solve the "digital legacy" problem to make more people comfortable about working with personalized information in the cloud. Irrevocable loss of digital assets is not acceptable to most people.

LegacyUser

Charlie Black said: I understand the concerns for locking data if a user has no recourse for having the data unlocked. My frustrations from yesterday are with users who have incorrectly merged individuals and me not having recourse to unmerge the mistakes. I have read the guidance on how to unmerge individuals, but what I see at my end differs from the screen shots in the guidance. No "unmerge" button ever appears. I merged several duplicate individuals last night then tried to restore them today - no success whatsoever. A couple of weeks ago, I had to create new individuals just to segregate a family whose records had become hopelessly comingled with at least three other families all because I couldn't unmerge the father (someone had incorrectly merged him with four men of the same name - I don't want to "report" this person as being abusive, I want the ability to unmerge his/her mistakes). As I mentioned in my comments yesterday, these problem mergers seem to be increasing not decreasing. I don't take issue with the open-edit wiki concept for adding/editting information for an individual, but please find a better solution for this merge-unmerge dilemma. If this needs to be in a separate topic thread, I'll be happy to start one.

LegacyUser

Christopher Allen Young said: I think the current term is now "restore" person rather than unmerge

If you do the research and you cannot undo then the proper procedure is to open a feedback case and get a data admin to restore the person. Thats about the only course you have otherwise

LegacyUser

Kathryn Grant said: In theory the caretaker idea sounds good. And I think it could work in many scenarios (like findagrave). I'm just not sure it would work in a system like Family Tree, the goal of which is to provide one accurate tree for all of humankind.

Kurt raises some important issues below. In addition, how would the decision be made about who became the caretaker and backups? Who would decide the boundaries of "ownership"? A family line could potentially have dozens of people wanting to "own" it.

I'm glad you raised the idea, and maybe there are some ways to resolve these issues that I'm not seeing. It's definitely work exploring!