Help get this topic noticed by sharing it on Twitter, Facebook, or email.

Nice New Update that Makes Reason Statements Critical

Reply
  • Which is even more reason to try to protect those Reason statements - right now it's way too easy for me to explain my update as "Standardising place-name" (say) and over-write what's already there. Especially when FamilyTree actually asks, "Are you sure you don't want to explain your update?"...
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • Reason statements are too easily overwritten during the merge process. Would it be possible to keep both reason statements in cases where the conclusions are the same? - such as when each duplicate has the same birthdate?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • I’m thankful.
    I agree with Carolyn Wheeler, and Adrian Bruce. I am guilty of not explaining myself, and my reasoning well.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • I guess I'm not understanding. If there is a Reason statement say for Birth: 1909, then when I go edit that Birth to 1909 and don't change the Reason statement it reminds me to do a Reason statement, but the original Reason statement is pre-populated and thus preserved.
    • view 2 more comments
    • Indeed - but you have to know that you might blow it away... I thought for ages that the Reason Statement that I gave was an addition to what was already there. Then I found out that it was a Replacement.
    • Exactly. And if you don't do anything, it will tag the text that was already there as now being YOUR reason! So when I add text describing why I have added a source and then someone comes along and just detaches it with no reason given, the change log takes MY reason for adding it, and places that into the other guy's reason for REMOVING it under HIS name as though he entered it!

      However, for the very reason that you've identified, I never put very much into the reason statements. I usually put something there but if there is extended logic into how the conclusion was formed, I will record that in a Note for the profile.

      Furthermore, Notes will convey between genealogical sites and GEDCOMs carry them as well. I need those for my records. There aren't any sites or tools out there yet that will sync FS's proprietary reason texts. Notes on a person have been there from the dawn of Genealogical data collecting time :-)
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • My experience with merges is that reason statements can be overwritten and lost.

    For instance, if the reason statement on the left reads “Death date and location were found in the christening record” and it is replaced by a reason statement on the right that only says “deceased” that the more detailed reason statement on the left is lost in the merge process.

    Is this not the case? Is there an error in my understanding?
    • So far as I know, you are correct, Carolyn. It only doesn't seem much of a problem to me because I take care to ensure that the most detailed value survives, eg the one with the church in the place name. That usually is the one with a useful Reason Statement. But of course that's not necessarily true....
    • You are right, that is not necessarily true. Perhaps a better example would be a reason statement for a calculated birth date. When I calculate a birth date (for an end of line person, for instance) I always add a detailed reason statement about how I calculated it. Where else would I write that information? It could go in Notes, but the logical place is the reason statement. It’s just simply too easy to overwrite this during a merge. You and I may be very careful to keep such information, but many are not, and then the info is gone for good.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • Gordon

    Sorry to seem so thick, but could you expand on what the new update is and how it should prompt us to make a reason statement? The only point I am getting is that the display of the place name from the source is a new feature. The difference between it and the standardised place name is now more obvious and should prompt the user to enter a reason statement accounting for the difference. Is that what you are illustrating?
    • Correct. Having dates and names show up under the source title is new, or at least least I only noticed it this week. Before you could have the correct information on the record and hope that no one would ever open the source and see any discrepancy.

      Now the two conflicting pieces of information are staring you in the face and to make sure the next user doesn't simply copy the incorrect information out of the source by just highlighting and copying the information that is sitting right there and pasting it over the correct information without ever opening the source to see your explanation in the source notes as to why the source in wrong, you need a reason statement to tell them not to.

      I did just check, however. Fortunately, the date and place information listed under the source title cannot be highlighted and copied. So to copy over the information, you do have to open the source so people might take the time to read any notes there. But a reason statement right under the information should still act as a hindrance on copying incorrect source information.

      Also, ideally, people would check all three sources on my example and see why the indexed record's place information was wrong.

      I should mention that it was pointed out in a RootsTech lecture I subsequently listened to that this new feature is only available when the information listed is contained in the underlying structure of the source. In other words, it can only be shown for indexed sources.

      Also, I suspect that having it listed will give those indexed sources more weight in the eyes of many people than necessarily warranted.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • This reply was removed on 2019-04-01.
    see the change log
  • Thank you for confirming that, Gordon. This led me to finding a "before" rather than "after" (adding reason statement, that is) example of my own. I thought I had added the same reason statement to all of these, but perhaps just confined this to my reason statement when attaching the source. (You can see I did do this in the example shown here.) Yes, it is best to make the situation as clear as possible, in a hope another user will not insist on changing the burial place to Corbridge (because that's what it says in the source)!

    No reason statement from me - but new feature now highlights the unexplained different place names:


    At least I did explain the situation in my reason statement when attaching the source:
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated

  • Yes, I wonder what the logic is that drives the display of the place on the right?

    I'd not seen this behaviour and still don't see it generally, but fortunately managed to remember an example where I thought the new right-hand place might pop up.


    This shows one of my relatives where I thought the new r/h place display might appear. You will see that I have recorded Margaret's baptism as being at Talke, Staffs - whereas the parish register source is actually that for Audley, Staffs. (Quite usual to see baptisms at a chapel, which is what Talke was, in the parish register of the mother church - Audley in this case).


    Shows part of the expansion of the source - the place is Audley in the FS Historical Index. I thought that having Talke on the left might clash with Audley on the right and generate the extra line of display. However, as the first image shows, there is no extra line. But you will observe in that first image that I had altered the source-title after attachment to include the text "1805, baptism, Talke (chapel to Audley)" - so if the check for differing places is done for my MM, then the check includes the source title (as updated by me) and not just the text of the index.

    Unless anyone can see a flaw in my logic...
    • Theory: Since the extraction record is marked as a baptism, the event date and place is not pulled to be displayed for the christening field. (Seems there have been discussions about this baptism/christening dichotomy before.)

      Make sure this event is tagged to the child's name then check the editing screen for the name. I predict you will see the name listed under the source title.

      I like that only the pertinent piece of information in the source is listed against that item in the vital records. It keeps the screen view cleaner and the ability to compare the information easier.
    • Indeed - in the Name display, all the sources tagged show a name from the source - be it Margaret Mayer (birth) or Margaret Higgins (married) or Margaret or (an error in the original) Mary.

      On the birth details, similarly - the census entries show the calculated approximation plus the transcribed birthplace.

      So yes - the so-called christening event doesn't show anything because the tagged source is of type baptism. (Yet more idiocy! It makes it look even more stupid!)

      So yes, Gordon, you are right.

      It's not perfect (aside from the blank refusal to treat Baptism as Christening) I've just seen a dated burial source, with an age at burial, that I tagged to the birth event. Presumably because there is no calculated birth (unlike censuses?) it's not clear why the burial is tagged unless you open the source up to see.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited indifferent, undecided, unconcerned kidding, amused, unsure, silly sad, anxious, confused, frustrated