Allow multiple facts for each vital detail -- let everyone be entitled to their own facts! :)
Comments
-
Paul said: Nathan
I've come to the conclusion this must be some kind of wind-up. You must know that users have been suggesting fundamental changes from when Family Tree was first released. Unless leaders of the LDS Church and/or senior the management of FamilySearch have a complete rethink about the whole project the concept stays exactly as it is.
There is no problem about presenting alternate data at present. There are clearly displayed reason statement fields (except for marriages, but that's another issue) into which users can easily see other possibilities (dates & places) about a person's birth, death, etc.
As suggested, there has to be just one, main set of data in order to get any worthwhile results from the search functions. Of course there are always going to be different suggestions about dates and places for events, but in most cases the facts can never be proved, even if there is an official document that records the details.
Everyone is entitled to raise an issue on this forum that they sincerely feel needs to be addressed / modified. However, in this case I think it is best to accept the consensus view AND that of those who matter - senior individuals in the Church / FamilySearch, Meaning, the blunt truth is your suggestion (serious or otherwise) will not be implemented.0 -
Christina Sachs Wagner said: I think that may have been the reason. It was a feature sacrificed for an improvement. That's all I remember.0
-
Nathan Twyman said: Thanks Paul for the response. Interesting conclusion. I'm not sure what "wind-up" you conclude is happening, or what led you to this conclusion. I suggest asking some questions before accusing or presuming you understand what someone is trying to do. Allow me to answer some of the questions you didn't ask:
By offering a suggestion, on any topic, no one should construe that I am attempting to dictate to FamilySearch. I surprisingly get accused of doing this a lot, but I can't see why my comments are construed that way. I try hard to carefully word what I say not to be accusatory or attacking towards FamilySearch, who I think is doing a wonderful job, one that I greatly appreciate. I recognize I am one lone voice and very few of the regulars on this feedback site ever agree with anything I suggest. I recognize that I have next to zero influence with FamilySearch, who doesn't know me from Adam.
Which is frankly why I pitched the idea here. In other forums I get lots of people saying some of my ideas would be a wonderful thing, some saying it may even encourage them to try out FamilySearch, or to try it out again. But here I know I will get pushback, and through the back and forth with the most thoughtful responses I can better see the weaknesses of the idea.
That said, I in no way consider this forum to be a representative sample of FamilySearch users and potential users. I respect and appreciate the activity of the handful of very active regulars, but I in no way believe their collective opinion represents a consensus. Nor do I believe in abandoning a potentially useful idea because a few forum power users don't like it or have pointed out some possible flaws.0 -
Nathan Twyman said: Thanks Christina. The document Robert posted seemed to suggest that all the variations of the vitals increased load times too. Important consideration.0
-
Nathan Twyman said: Thanks Joe for the response. I want to be clear that while I have situations like Ryan's, that is not the problem this suggestion was trying to address. Multiple competing theories where what is correct isn't totally clear is really not something I was trying to address.
I am apparently not being clear about the problem this (and other ideas I've proposed) is trying to address. I considered making another post in the forum to try and explain it in more detail, but I don't think that will get me anywhere. Please forgive my extended description here:
FSFT was designed to be a conclusionary tree, but at least for my relatives, there is a flaw in that design. We assume that with the current design, quality and accuracy will increase over time, but the reality is that for certain segments of my tree (mostly pre-1750 or so profiles), quality decreases over time. That means for this section of the tree, the end result is a hearsay/popular opinion/supposition tree, not an accurate tree.
I for one am not surprised that an open-edit model decreases quality on certain segments of the tree. People who know little are going to rely on hearsay or supposition when they first start out--it's kind of natural. People who are just starting to care a little aren't going to bother looking at the posted evidence, discussions, etc.--it's common to have a few people who unwittingly act like a bull in a china shop. It only takes a few, and we have a huge number of inexperienced users. For me its almost never the same person--I get new ones every week. "More research tools" and "better collaboration" will not stop the bulls or correct their destruction. There aren't enough bull tamers and shop cleaners to handle the destruction. And we (rightly, I believe) keep inviting the bulls into the shop.
I have abandoned most pre-1750s profiles I carefully researched because I can't keep up with the repairs. I've scaled back to keeping up only a few of my direct lines, but as the number of hit-and-run users increases, I can't even keep up with that. To keep my gut from wrenching, I try not to look at my ancestors' England profiles anymore (where everyone was named William and Elizabeth).
One of my last-ditch recent efforts has been to try to make changes to a few of my ancestors' profiles on wikitree, geni, and others, so fewer people can use the hearsay they see on those sites as excuses for overwriting quality research on FSFT. The moderators of those profiles on these sites so far respond to me citing the same problem--the changes are made, but soon thereafter a bull in a china shop comes in and puts everything back. They can't keep up with repairs either. It seems a hopeless battle, one that "more collaboration" and "better research tools" is not going to touch.0 -
Tom Huber said: There are instanes where one or more vitals are uncertain. I've found this happens most often with births and sometimes deaths.
Those who say that there is just one exact date and one exact place are correct and I fully support that approach -- what Joe Martel correctly calls "conclusion-based."
When a date and place is uncertain is where Nathan's approach is worthy of consideration. Then various elements need to be used, but not "alternates" -- there is a whole series of records where alt- (whatever) were entered into the Other section, and that is a valid approach, but what that is really telling me is that those involved with the record haven't spent the time fully researching the person. But then, there may not be supporting records for any of the dates or places. That's the real dilemma.
Family Search has provided a "collaboration" section for these discussions, but it is not up front and present, so it is seldom, if ever used. Notes are also useful, but again, they are hidden away under the collaboration tab.
This is a problem with the multiple-tab approach, but could be resolved by adding links to the conclusions to discussions/notes, just like links are added to sources for each conclusion area.
For an example of a person's record where there is conflicting information, especially for the birth, see Pieter Claesen 9312-XFX. There is currently a possible duplicate that needs to be merged, but it will take some effort to make sure everything is merged correctly. A cursory glance is beyond the time I have right now to work on it, other than to delete the fraudulent information for Pieter's father. The problem is that the Wyckoff line is one of those genealogies that had fabricated information produced by Gustave Anjou, a known fraud, so this continues to be a problematical person. I do not recormmend locking the record because there will be duplicates produced (as is evident in the currently possible duplicate).
The focus for the purpose of this discussion needs to be on Pieter's birth information. Normally, I do not like to put information into a record where the birth date and/or place is not known, but in this case, we had to use speculation, based upon an excellent little work that is cited in the sources, but cannot be reproduced because it is a recent and copyrighted work.0 -
Paul said: I apologise if my comments came across as some sort of direct, personal criticism. I believe, if you read my other contributions on this forum, you will find I generally try to be constructive with any criticism. However, I feel you have proved to be "your own worst enemy" in this thread, especially (I felt) with rather unkind remarks that were directed towards another regular contributor. We all have our own style of writing and way of expressing ourselves, so I guess I was a bit peeved about some of your comments and let this get in the way of having much empathy with your arguments. No offence intended.0
-
Adrian Bruce said: Nathan - for me the basic issue is that what you propose as a solution cuts 100% across the strategic architecture of FamilySearch FamilyTree. I am grateful to Joe for summarising that in the phrase "conclusionary tree".
Requirements are fine but proposed solutions cutting across the whole ethos of FSFT are never going to fly. Please note that does not necessarily say that I agree 100% with that ethos but it's pointless for me to suggest otherwise.
I totally agree with you that "this forum [is not] a representative sample of FamilySearch users and potential users". Nor a consensus. Let me explain however, that I started in FSFT in order to fix my ancestors who were their own grandchildren in a looping pedigree. I have no other desire other than one to see the best data in FSFT. I also have 30y experience in IT and hope that I can put some of that knowledge back into FS by helping others in a practical manner. That's all.0 -
Nathan Twyman said: To whoever I said unkind remarks to, I apologize.0
-
Robert Wren said: Joe Martel broached the subject of a Research tree to assist (?) the "conclusionary" tree. Tom mentions our common ancestor which he, personally, monitors and tries to 'maintain a semblance of reality in' - thankfully relieving me of that responsibility. (TOM is very diligent.) There are a couple dozen fellow 'watchers' on this 'first immigrant' among whom we are to collaborate (if we ever allowed to know who we are)
As Tom correctly observes the collaboration tab is not very effective (hidden, unexplained & not promoted). Therefore one of the 3 avowed FSTree goals has fallen short.
Nathan's suggestion seems to have led to the potential of a Research Page. I've been toying with that idea using Memories. As research generally is best conducted for a FAMILY, rather than simply a single PERSON in a family. (aka FAMILY HISTORY, formerly Genealogy!) "Memories" has the ability to present the data, conclusion, options, discussion, explanation, etc. (Interaction between users may be somewhat limited, at this point.)0 -
Tom Huber said: I like the idea of a "Research Page" especially for situations like our common ancestor. The only option we really have is to hijack the "Life Sketch" section for warnings and/or discussions about the person.
Hopefully, this is something that FamilySearch will consider adding, along with a flag at the top of the details page when there is information in the Research Page (not just a count like what is used for the "collaboration" tab.0 -
Adrian Bruce said: I would totally support the idea of an area (page? tab?) dedicated to research and the mulling over of alternative ideas. It seems to me that can be done within the basic architecture of FSFT. As I think I said above, if certain tabs within a profile might be locked while leaving the research tab open, then it might be possible to introduce (somehow!) the locking that some want without breaking that basic open edit framework.0
-
Robert Wren said: FWIW, Here's something I've was working on a few days ago for the Early Immigrant Bourne Family, which was not OVERLY active recently - 2 watchers (I'm one), an abundance of sources and more than a bit of confusion over the two sons of Jared, named Jared (with various name spelling, etc.) and a bevy of other confusions.
I did several merges within the family - added some of the comments about those merges to the source image.
I simply added a memory with an appropriate family compiled source, attached it to several PID's and added some explanations; I also added his will the same way.
This concept might be adaptable to more of a (BOURNE FAMILY Research Page)
I've OFTEN tried FSMail asking questions, conveying ideas and change notices to little avail.
It's very much a work in progress started with the last week. Likely needs some subject headers at al. I've posted similar types of thinks to discussions in the past, with little response (or apparent notice??).
BTW, MANY of the early New England first family immigrants, have had massive research conducted through American Ancestors, I often wonder why we even bother to make them "Open-Edit."
I would suggest that very little valuable CORRECT info is still being added by the average. BUT, in my experience (and 'watching' they seem to be the most active in 'changes.' (That's based onfifty plus years of experience and researching - and a former A.G.)0 -
Robert Wren said: The link to the page discussed above: https://www.familysearch.org/tree/per... (Might help to visualize what I'm talking about - posted right before I left the computer & forgot to add it - apologies)
Jared Bourne Jr 7 March 1651 – 13 October 1718 • LHLR-31W (Memories)
0 -
Justin Masters said: There can be situations where adoptive parents are listed along with biological parents. My own father (alive right now) is NOT sealed to his biological parents or the woman who married his father and who he's known all his life. He's given me instructions to seal him to both "sets" of parents.
Me, I'm kinda focused on the biological side, but when your biological mother died when you're 3, and only knew your step-mother (who has adopted you) your whole life, it becomes a "loyalty" question for him, and he is taking the "easy" way out by putting it in my hands. heh.0 -
Juli said: Rename the "collaboration" tab as "research" and add a longer-form text area (somewhat like the Life Sketch) at the top for the sorts of discursions that do not fit the "Discussion" and "Notes" functions.
Ideally, research notes could be tagged to conclusions the same way sources can be tagged to vitals. These would show if anybody went to edit the conclusion, hopefully slowing down bad edits. Even more ideally, this would be combined with expanding source tagging to every conclusion, not just vitals. And in the absolute best scenario, research notes could also be tagged with sources, making it easy to refer to exactly where the point of disagreement arises.0 -
Nathan Twyman said: I'm glad this sort of functionality would help some, but for me it would be worthless. I've had no success getting the flood of hit-and-run users to look at the sources I post and the reasoning I carefully spell out in every field in the details and sources pages. For hit-and-run users, the collaboration tab probably might as well be non-existent. In fact, I believe adding more detail to that section would simply make them even less inclined to look at it.0
-
terry blair said: Perhaps an impedance model something like the following might help with the problem: if a vitals field has no source, accept the proposed change; if the vitals field had a source available in FSFT, then ask the reason for the change and require a source - no source, no change; if there are two sources from FSFT with a different vital date, then look at the date on the source and provisionally accept that date. This might be effective for post say 1850 issues, but if there are few or no sources this idea would probably not work.0
-
Juli said: "Impedance model" is a good description, but you have to be careful: required fields are just a recipe for gibberish entries, or if carried too far, even spiteful damage. With the stupid modal window interface, not even an "are you sure?" message will work, because you pretty much _have to_ tag first and then edit, so that the data is accessible during your edit (because the aforementioned stupid modal interface renders everything inaccessible). This means that if you're doing actual source-based genealogy, there will pretty much always be a source tagged to a vital when you go to change that vital.0
This discussion has been closed.