Allow multiple facts for each vital detail -- let everyone be entitled to their own facts! :)

LegacyUser

Brett said: Nathan

Then, don't you remember those days?
"Multiple" references for the same "Details"/"Vital"!
It was a 'nightmare'!
'Yes', we could all have our own 'slant' of the "Details"/"Vital".
But, ONLY 'One' was correct/fact - even if it appeared "Multiple" times.
The rest were just useless.

Brett

.

LegacyUser

Nathan Twyman said: I vaguely remember it. Frankly it has been a long time. I don't remember the problems. Saying it was a nightmare is fine, but can you explain the problem in more specific terms?

Also, could you verify that Adrian's assertion (apparently not a guess) that the "IT was horrendous" is correct?

LegacyUser

Nathan Twyman said: More particularly, they overwrite good data with bad. Even though, as you say, that isn't the right way. This change helps those people have their way, without destroying the good data in the process. They will eventually learn the right way, and change their preference to the correct option--which will still be there because they didn't overwrite it earlier.

LegacyUser

Brett said: Nathan

'Nightmare'; and, 'Horrendous', are both words that I would use to describe it.

I really wish I had "Screenshots" of the old "New.FamilySearch" days.

You had "Multiple" LINES (ie. references) for (ie. under) the same "Detail"/"Vital".

If you did not like what was there, you just added ANOTHER - your version, so to speak.

If I recall (and, I stand corrected if I am wrong); but, you could NOT "Edit"/"Amend" what was already there, that had been added by another User/Patron, the ONLY option was to "Add" something else/different.

Hence, 'Nightmare'; and, 'Horrendous', for BOTH, the Users/Patrons; and, the Programmers.

Brett

.

LegacyUser

Nathan Twyman said: Interesting, thanks Brett. I do not remember that at all. I don't see why it was a nightmare, though--that sounds great to me. I think it would be a nightmare to look at if all the entries for every vital were shown at once, but if only your preferred entry was shown, sounds great to me. I also do not see how the "IT was horrendous"? How do you know?

LegacyUser

Nathan Twyman said: you know, I wonder if that is why I thought this idea had been brought up before--maybe I was remembering it from new familysearch.

LegacyUser

Brett said: Nathan

That was just it ... all the entries for every vital were shown at once ... one after the other.

That was the 'nightmare'.

Although, I am NOT a "Programmer", I have worked as a "Users Representative" on the redevelopment of a National "Mainframe" Application (in fact, x2).

One aspect of the conversion of "New.FamilySearch" to "Family Tree" that MUST have been, both, a 'Nightmare'; and, 'Horrendous', was; as, there were "Multiple" LINES (ie. references) for (ie. under) the same "Detail"/"Vital" - which to you choose/which is correct!?

Brett

ps: 'Yes', I think you are correct about you thought.

.

LegacyUser

Nathan Twyman said: Brett--that's helpful to know; thank you.

LegacyUser

Christina Sachs Wagner said: I'm pretty sure I heard Ron Tanner say that people can no longer choose their preferred portrait. Once someone chooses one, it is the same view for everyone, until someone changes it, again. Let the battles begin!

LegacyUser

Nathan Twyman said: I wonder why that is. Perhaps it improves caching/load times.

LegacyUser

Brett said: Nathan

A "Programmer" once said to me that ...

"You cannot make a 'System' FOOLPROOF; because, fools are so ingenious".

So true.

I wish I could find a cartoon form long ago ... it was a simple "Swing" ... it was a classic ..

What the Users WANT; and, what the Programmers DELIVERED.

Brett

ps:

Here they are:

https://www.google.com/search?rlz=1C1...

.

LegacyUser

Robert Wren said: Nathan, perhaps this will help you understand the problems of new.FamilySearch and WHY it was changed:

THE CASE FOR MOVING TO “OUR TREE”
A FAMILYSEARCH WHITE PAPER
APRIL 2011

http://broadcast.lds.org/eLearning/fh...

But, of course, FSTree seems to have strayed from those declared purposes - Better Sourcing, Minimizing Duplicates and Collaboration.

LegacyUser

Barbara Nelson said: There are situations where it would be nice to be able to document multiple vitals. I have seen a number of occasions where there are parish records showing the birth, including both baptismal and confirmation records; and sometimes marriage and emigration records. But for some reason, once they immigrate to the US they seem to forget when they were born. So you will find both draft registration and death records showing a different date of birth. Usually there is only a slight variance in days. I try to document the different birth date in the comments section, but it is a toss-up which date to use.

However, I think it could become a problem if everyone could pick the vital information they wanted. Especially if they didn't use valid sources.

LegacyUser

Nathan Twyman said: Thanks for your input Barbara. Can I ask why you think it would be a problem? As long as the system maintains the good, well-sourced data, is it a terrible thing if it also happens to have poor, unsourced data?

The proposed benefit is that people will no longer be overwriting good data with bad data--both will exist simultaneously so the good will not be lost.

LegacyUser

Nathan Twyman said: For the benefit of others, I'll post here the first relevant portion of the document:

"Take, for example, John Case.... His record contains 812 combined records, with over 10,000 pieces of information. If you dig into his details a bit, you’ll see:
• 39 spouses.
• Over 50 siblings connected to 4 sets of parents.
• Hundreds of children.
• 19 versions of his name, some obviously
belonging to someone else.
• 25 versions of his birth date, ranging from
1619 to 'about 1800.'

"At least 8,000 of Case’s descendants submitted him to the Church. When the database that became the new.familysearch.org was first created, John Case’s record contained each of these 8,000 submissions, resulting in more than 75,000 pieces of information.
"To prevent records like this from causing the system to crash, duplicate pieces of information were deleted. (No unique data was deleted.) This stabilized the system, but records like this are one of the main reasons that the system performs slowly.
"With so many errors, and so many contributors who are probably unavailable, it is unlikely that the records of crucial gateway ancestors like John Case will ever be correct unless the system itself changes."

LegacyUser

Nathan Twyman said: The document proposes a solution, which included "Conclusions" and "Opinions:"

"Conclusions are the best set of available facts about an individual in the tree. Each individual will have one set of conclusions, which you and a community of interested researchers maintain. Conclusions without sources are considered weak. Anyone can add a source to strengthen a conclusion or replace
a weak conclusion with a stronger one.
"Opinions are variations of the conclusions about an individual. They may be 'theories' that you post so that you can work with others to substantiate them with sources or disprove them. They may simply be variations submitted over time or contradictions found in various sources."
"Think of the conclusions as a sort of 'beefed up' individual summary and the opinions as all of the variations shown in the details."

In other words, multiple versions of vitals! I wonder why they ultimately chose not to implement it this way.

LegacyUser

Jeff Wiseman said: As has been discussed above, New.FamilySearch.org was originally designed exactly to do the very thing being requested in the original posting. This system was totally abandoned 5 or more years ago due to many problems and issues that were created by using that kind of structure.

Because I wasn't involved in those decisions, I cannot list any of those specific reasons. But there seems to me to have been one issue that was the crux of most of it--that is unique vitals.

Any vital event for a given person is completely unique. It happens on one exact date in one exact geographical location. It doesn't matter what anyone thinks it was or reasons for it being recorded a given way, it is either right or wrong. If you have 10 different people, all with a different set of "facts" for a given person's event, at the MOST, only ONE of those people can be correct--and even then, there is no guarantee that ANY of them are correct.

The whole reason that the church created this database from New.FamilySearch.org is to grow a single family tree for all people as quickly and accurately as possible. That includes a single record of the CORRECT events data for each person without a load of guesses and non-sourced (or incorrectly sources) data.

Allowing each patron to collect and control their own personal "clutch" of records and events would be totally counter-productive to the church's original intents of having this database. Nobody would be interested in updating their "own" data because, after all, they would typically consider it to be more correct than everybody else's anyway.

The only way for FS to accomplish the church's goals is to use the very structure that is in place today. The database has not really been created as a free offering for the personal pastimes of patrons to use for their own personal use and desires. It has been opened to the public so that if they choose, they can also contribute toward the primary goals that the database was created for in the first place (i.e., a single record for each person with as many sources that can be found for that person, and the single most logical vitals and events data that can be derived from these sources--all being determined in a fast a fashion as possible)

If you don't like a value assigned to a vital or event, it is totally intended for you to find additional sources, information, and logic that would justify it being changed, and then go and change it yourself, documenting why as you go. Anything other than this is tangential to the whole reason that the FS FamilyTree is there in the first place.

Lastly, as far as the "Editing Wars" that can occur, this happens when 1 or more of the individuals are stubborn and refuse to look as the data and reasoning that is currently available. They are NOT following the rules of a single communal tree (unfortunately these areas aren't policed effectively). Remember, for any given event there is only ONE correct value, and THAT is the one that is supposed to be recorded in the shared tree. Why would you also want to record a bunch of other values that, by definition, are wrong?

LegacyUser

Barbara Nelson said: I would question how both searches and finds would work if there are multiple dates. I have run into that problem with estimated dates that are years (in some cases decades) off. If a PID has multiple birth dates, would the system be able to catch duplicates? Conversely, would it present too many suggestions and cause a lot of extra work?

Lastly, I think it would complicate separating bad merges. I spent a long time today sorting out a family because the parents had the same names and were from the same parish. The parents were born about ten years apart, and if both sets of birth dates were allowed, I think it would be too easy for users to just go with the flow and leave the families all intertwined.

LegacyUser

Robert Wren said: "To a man with a hammer, everything looks like a nail."

LegacyUser

Nathan Twyman said: Once again, I am not suggesting there is more than one actually correct birth date for someone. We all agree on that. We're on the same page.

Once again, I am not suggesting there isn't already a proper way to handle discrepancies, involving examining evidence and making a determination. We all agree on that. We're on the same page. Why are these being repeated over and over when they've already been addressed over and over earlier in the thread?

Let me skip to the end. "Why would you also want to record a bunch of other values that, by definition, are wrong?" This has also been answered. Over and over. Let me repeat it again: It could help prevent people from overwriting good data with bad.

I will try and pre-empt the assertion that all we have to do is collaborate and resolve differences the data will continuously improve: that doesn't happen faster than the destruction happens, and the reason is the ratio of hit-and-run users to those power users who are actively monitoring.

I rarely have edit wars with one person. I can think of maybe 2 or 3 instances. My edit wars are with the masses (different person(s) each week) who believe whatever is on Geni/Ancestry/Wikitree/[insert preferred hearsay here] is absolute truth regardless of anything else. Most do not respond and those that do are not interested in learning or changing. Much, much good research that I personally have done has been overwritten by the latest hit-and-run user's preferred hearsay, and it remains that way because I ran out of time to keep up corrections long ago. I have seen my family's tree crumble all around my immediate line, and I know from facebook groups that I am not the only one, and that many abandon FSFT specifically because of this reason. We can tell everyone they are wrong and should simply use the system how it was intended, or we can consider ways of changing the system to improve both data quality and participation.

LegacyUser

Nathan Twyman said: "New.FamilySearch.org was originally designed exactly to do the very thing being requested in the original posting. This system was totally abandoned 5 or more years ago due to many problems and issues that were created by using that kind of structure."

See the quotes I pulled from the document Robert posted. They specifically called for multiple versions of vitals.

EDIT: I believe it does but Robert showed it could be interpreted differently.

LegacyUser

Nathan Twyman said: Robert, that's a great saying, but a better response would be to show why the "conclusions" and "opinions" are actually not multiple versions of vitals as I claimed.

LegacyUser

Robert Wren said: Conclusions are, or should be, based on facts. Opinions are, well, opinions - what one 'thinks' FSTree suggests these 'should' appear on the "collaboration" tab under 'discussions' - which obviously doesn't work because very few users seen aware of the feature.

In part, what your seem to be proposing might be a Research Page to discuss the various values of suggested vital info. THAT idea might have some value, BUT, as reluctant as FS is to act, I fear it would be tough to be implemented. Just my opinion.

LegacyUser

Ryan Torchia said: There is kind of a scenario where this could be handy, or at least I could just use some guidance.

This is a vastly simplified version of an ongoing edit war: There's some debate over the identity and maiden name of an early settler's wife, with two main likely candidates. No records exist proving which one. A genealogist published a paper suggesting naming one of them as the likely spouse, but admits it's mainly circumstantial evidence.

To address this, we eventually created a generic profile for "Mary" and added all the points for and against each likely person in Memories, mentioning the debate in the Life Story, and pointing to evidence and to the profiles for the two candidates.

So it's clear on the generic profile that this is unresolved and there are some strong opinions both ways, and people tend to respect that. There are, of course, a thousand GEDcoms and personal trees out there that are built on the assumption of one or other being correct, which means the profile gets periodically battered by imports and careless editors anyway, but there's one editor in particular who constantly comes by frequently -- every day for awhile -- and asserts that one answer is correct. They change the name and vital info to match their preference, add relationships, and even delete any mention of the disagreement, all without any communication whatsoever -- no new sources, no comments in the edits, no replies to messages from myself or others, and as soon as the damage is reverted, comes back and does it again.

So... this ended up being a call-out, which wasn't what I intended, but the question here is really: yes, you can't have your own facts, but people do have different thresholds of what's sufficient evidence, and people do come to different conclusions based on the evidence available. So how do we handle that?

LegacyUser

Nathan Twyman said: I can now see how "opinions" could be read that way instead of as specified alternate facts. Thanks for pointing that out.

LegacyUser

Nathan Twyman said: Good questions Barbara. Gives me some things to think about.

LegacyUser

joe martel said: Nathan, thanks for the idea and there is some good feedback. Going back in time FSFT was designed to be a "conclusionary" tree. That each person in the tree and their relationships should represent the actual real person. We each have a definite true birth event (date and place), death event, and maybe marriage event... The goal of the open-edit model of the tree was to have the community discover and conclude/share the actual truth of those persons. So most of this work today is trying to improve the quality of the FSFT persons and relationship to achieve to one true tree of mankind.

Now, FSFT thought about Research but determined the conclusionary tree was the most important thing to do for the goal of achieving quality work and for the goals of the organization that built and funds and supports this. But there is a need to support better Research. THere are lots of ideas about how to support a Research tree, and the ability to transfer, meld, augment... into the conclusionary tree. Those multiple value you desire do illustrate that need for a Research model. It's just not happening very quickliy. So many users use third party products, and discuss/collaborate when things aren't so perfect.

Ryan's scenario illustrates the dilemma. We may never find the Sources to absolutely make the FSFT Person truthful. Each user has to decide what level of quality they want and what level of work to achieve that. Personally, I have some persons in my tree I'm pretty picky about, but most I feel that if its good enough I go work somewhere else in my tree. I don't believe there is an exact correct answer and therein lies a very important aspect of this work - can we get along as humans where we have different opinions.

LegacyUser

joe martel said: Oh, and open-edit implies that a Person will change and they may start out sparse, and incorrect, but over time the community will converge to a more truthful representation of the Person. So FSFT is an attempt to achieve conclusions, via some path of Reearch, thought the research tools in the tree are minimal.

LegacyUser

Adrian Bruce said: Yes, Barbara - excellent points to think about.

LegacyUser

Adrian Bruce said: Yes, I like this scenario as something concrete to fix on. I like the idea of the research being documented in Memories.

While I agree with the Open Edit principle, I wonder if there is some way to identify a volatile profile such as you describe, lock everything on it apart from Memories and perhaps any other collaboration tools, and so confine changes to there until consensus emerges - if ever. Sort of a simple, text based version of Joe's Research person. All sorts of holes in that idea but...