Editin Reason Statements
FamilySearch allows for lots of editing opportunities ie: removing or adding family members, changing dates and places, correcting spellings, adding or deleting sources, unmerging a merge, restoring a person, etc. but it won't allow any editing of a reason statement. This needs to be addressed. With all the other editing allowed, what is the thinking behind locking a reason statement so cannot be changed but it there for eternity?
Comments
-
Part 1
Because FS is trying to accomplish 2 things using the same mechanism and it doesn't work well.
As a result, the "Reason this information is correct" text is schizophrenic in function. The label is misleading. The field should be more correctly labeled "Reason that making this change is correct". There is a SIGNIFICANT difference between these. That "reason" text is NOT stored with the vital or conclusion in the person record and therefor it does NOT have the persistence of the vital or other conclusion (as you are asking about). It is stored with the change description in the change history logs. It only applies to that one, single change that you made.
The "reason" that you want would be a NOTE attached to the vital or conclusion that describes how various sources (also attached to or "tagged" to it) have been interpreted and the logic by which the vital or conclusion is arrived at (i.e., the "derivation logic"). This is a global description that travels with the vital or other conclusion and at any given time explains why the value of the conclusion is correct. If someone wants to see how a particular conclusion (such as a birth date) was arrived at, they would look at the list of sources attached (tagged) to that birth date and any NOTES (derivation logic) that describe how those sources were interpreted.
Those sources and notes would stay tagged to the vital or other conclusions until someone feels that they need to change (i.e., an incorrect source was attached that doesn't apply). They could then adjust the list of sources and note tagged to a given conclusion.
(Unfortunately at this time, FS does not give you the ability to tag notes to the vitals and other conclusions the way they do with sources. As a result you have to always manually look at the notes anytime you are trying to figure out why a conclusion has been set to the value it has.)
…continued
0 -
Part 1
Because FS is trying to accomplish 2 things using the same mechanism and it doesn't work well.
As a result, the "Reason this information is correct" text is schizophrenic in function. The label is misleading. The field should be more correctly labeled "Reason that making this change is correct". There is a SIGNIFICANT difference between these. That "reason" text is NOT stored with the vital or conclusion in the person record and therefor it does NOT have the persistence of the vital or other conclusion (as you are asking about). It is stored with the change description in the change history logs. It only applies to that one, single change that you made.
The "reason" that you want would be a NOTE attached to the vital or conclusion that describes how various sources (also attached to or "tagged" to it) have been interpreted and the logic by which the vital or conclusion is arrived at (i.e., the "derivation logic"). This is a global description that travels with the vital or other conclusion and at any given time explains why the value of the conclusion is correct. If someone wants to see how a particular conclusion (such as a birth date) was arrived at, they would look at the list of sources attached (tagged) to that birth date and any NOTES (derivation logic) that describe how those sources were interpreted.
Those sources and notes would stay tagged to the vital or other conclusions until someone feels that they need to change (i.e., an incorrect source was attached that doesn't apply). They could then adjust the list of sources and note tagged to a given conclusion.
(Unfortunately at this time, FS does not give you the ability to tag notes to the vitals and other conclusions the way they do with sources. As a result you have to always manually look at the notes anytime you are trying to figure out why a conclusion has been set to the value it has.)
…continued
0 -
Part 2
So if you have 3 censuses, 2 birth records, a Death certificate, and a picture of a headstone all for the same person but all have different values, the reasoning that you use in determining the value that is recorded in the person's birth vital needs to go into a NOTE (probably titled with the name of the vital it applies to--in this case it could be titled "BIRTH").
Now when you are making a CHANGE to a vital (e.g., you discovered that one of the sources attached to that person actually belonged to someone else, so you've removed it and replaced it with a newly found birth certificate), you only need to document the reason that you are making the CHANGE (e.g., "actual birth certificate found and attached--see NOTE titled "BIRTH"). If you put a long and involved derivation logic in the "Reason this information is correct" field (the way the title incorrect entices you to do), it is only attached to that specific change.
That is why you typically cannot change it--because it is documenting a specific event in the change history log. Furthermore, as additional changes occur to a given vital, your nicely documented "reason that the value is correct" disappears and is buried further and further down into the change history for that vital. That is because the "reason" field is really a "reason that just the change you made is appropriate". If you use it to identify why "the value of the vital is correct", all your work will just be wasted!
The proper fix for this issue would consist of something like the following:
1) The "Reason this information is correct" field label needs to be corrected. It should say "Reason this CHANGE has been made". This also has the desirable effect of not having to repeat large blocks of text over and over again in the change history logs making them far more difficult to use.
2) Notes in the Notes List for the person record needs to be made tag-able to vitals and other conclusions in exactly the same way that sources in the Sources List for the person record currently are.
3) The way information is presented to the user when editing vitals and other conclusions needs to change so that it is not so misleading and confusing:
3a) The presentation of the "Reason this change is being made" needs to be separated from the editing of the conclusion. E.g., after a change is made, the Reason box could be brought up in a modal window as the last part of the change being made. Anything to separate the change reason from the attributes of the vital itself.
3b) The list of both sources and notes that apply to the vital or other conclusion should be made visible together with the ability to view and edit the notes in the same way as the sources are currently. Ideally, you shouldn't even have to go into an edit mode for the vital/conclusion itself in order to see all the sources and notes applicable to it.
There are other things that could be done in the user interface to make this much more intuitive, but at present, we can't even get the ability to tag notes to vitals added to the system.
So in the meantime, use the Notes that have been hidden below the "Collaboration" tab to document why the vitals and conclusions have the value that they do. Then use short texts in the inappropriately named "Reason this information is correct" field to identify why you made the CHANGE. If necessary, you can refer to the appropriate Note. If you want more detail in that reason field, you can always copy and paste from the Note that you've made.
0 -
Part 2
So if you have 3 censuses, 2 birth records, a Death certificate, and a picture of a headstone all for the same person but all have different values, the reasoning that you use in determining the value that is recorded in the person's birth vital needs to go into a NOTE (probably titled with the name of the vital it applies to--in this case it could be titled "BIRTH").
Now when you are making a CHANGE to a vital (e.g., you discovered that one of the sources attached to that person actually belonged to someone else, so you've removed it and replaced it with a newly found birth certificate), you only need to document the reason that you are making the CHANGE (e.g., "actual birth certificate found and attached--see NOTE titled "BIRTH"). If you put a long and involved derivation logic in the "Reason this information is correct" field (the way the title incorrect entices you to do), it is only attached to that specific change.
That is why you typically cannot change it--because it is documenting a specific event in the change history log. Furthermore, as additional changes occur to a given vital, your nicely documented "reason that the value is correct" disappears and is buried further and further down into the change history for that vital. That is because the "reason" field is really a "reason that just the change you made is appropriate". If you use it to identify why "the value of the vital is correct", all your work will just be wasted!
The proper fix for this issue would consist of something like the following:
1) The "Reason this information is correct" field label needs to be corrected. It should say "Reason this CHANGE has been made". This also has the desirable effect of not having to repeat large blocks of text over and over again in the change history logs making them far more difficult to use.
2) Notes in the Notes List for the person record needs to be made tag-able to vitals and other conclusions in exactly the same way that sources in the Sources List for the person record currently are.
3) The way information is presented to the user when editing vitals and other conclusions needs to change so that it is not so misleading and confusing:
3a) The presentation of the "Reason this change is being made" needs to be separated from the editing of the conclusion. E.g., after a change is made, the Reason box could be brought up in a modal window as the last part of the change being made. Anything to separate the change reason from the attributes of the vital itself.
3b) The list of both sources and notes that apply to the vital or other conclusion should be made visible together with the ability to view and edit the notes in the same way as the sources are currently. Ideally, you shouldn't even have to go into an edit mode for the vital/conclusion itself in order to see all the sources and notes applicable to it.
There are other things that could be done in the user interface to make this much more intuitive, but at present, we can't even get the ability to tag notes to vitals added to the system.
So in the meantime, use the Notes that have been hidden below the "Collaboration" tab to document why the vitals and conclusions have the value that they do. Then use short texts in the inappropriately named "Reason this information is correct" field to identify why you made the CHANGE. If necessary, you can refer to the appropriate Note. If you want more detail in that reason field, you can always copy and paste from the Note that you've made.
0 -
Pynnges,
I'm don't understand your question. I can edit, delete, and add sources or text to the "Reason this information is correct" text window with no problem. Can you explain in detail why you can't edit the reason window?
0 -
Pynnges,
I'm don't understand your question. I can edit, delete, and add sources or text to the "Reason this information is correct" text window with no problem. Can you explain in detail why you can't edit the reason window?
0 -
Pynnges
.
Exactly like 'Leroy' ...
.
I DO NOT understand your "Post", what you are 'on about'.
.
As far as I am aware ...
.
And, I stand corrected if I am wrong ...
.
Provided you are referring to "Reason Statements" (ie. "Reason This Information Is Correct") for:
(1) Individuals/Persons; and/or,
(2) "Couple" Relationships" and/or,
(3) "Parent-Child" Relationships
.
"Reason Statements" (ie. "Reason This Information Is Correct") are NOT "Locked".
.
"Reason Statements" (ie. "Reason This Information Is Correct") can ALREADY be:
(1) "Deleted"/"Removed"; or,
(2) "Edited"/"Changed"; or,
(3) "Replaced" altogether.
.
Now ...
That said ...
.
I think. "Terminology", may be. the confusion, here ...
.
Please correct me, if I am wrong ...
.
I have the 'sneaking' suspicion that you MAY be referring to "Discussions", under "Collaboration".
.
IF, that is the case; THEN, 'Yes' ... "Discussions" are the ONLY thing, that a User/Patron can "Add", that CANNOT be, either, "Edited"; and/or, "Deleted", by ANOTHER User/Patron.
.
And, rightly so ...
.
IF, a "Discussion" is CONTRARY to the "Code of Conduct"; THEN, a User/Patron, has the RIGHT, to "Request", that 'FamilySearch", to "Delete"/"Remove" it.
.
But, such "Discussion", MUST be in VIOLATION, of the "Code of Conduct", not that a User/Patron, just DOES NOT, like; or, agree; or, appreciate, it.
.
Question: Is that WHAT you are referring to ... "Discussion", under "Collaboration"?
.
Please advise.
.
Brett
.
0 -
Pynnges
.
Exactly like 'Leroy' ...
.
I DO NOT understand your "Post", what you are 'on about'.
.
As far as I am aware ...
.
And, I stand corrected if I am wrong ...
.
Provided you are referring to "Reason Statements" (ie. "Reason This Information Is Correct") for:
(1) Individuals/Persons; and/or,
(2) "Couple" Relationships" and/or,
(3) "Parent-Child" Relationships
.
"Reason Statements" (ie. "Reason This Information Is Correct") are NOT "Locked".
.
"Reason Statements" (ie. "Reason This Information Is Correct") can ALREADY be:
(1) "Deleted"/"Removed"; or,
(2) "Edited"/"Changed"; or,
(3) "Replaced" altogether.
.
Now ...
That said ...
.
I think. "Terminology", may be. the confusion, here ...
.
Please correct me, if I am wrong ...
.
I have the 'sneaking' suspicion that you MAY be referring to "Discussions", under "Collaboration".
.
IF, that is the case; THEN, 'Yes' ... "Discussions" are the ONLY thing, that a User/Patron can "Add", that CANNOT be, either, "Edited"; and/or, "Deleted", by ANOTHER User/Patron.
.
And, rightly so ...
.
IF, a "Discussion" is CONTRARY to the "Code of Conduct"; THEN, a User/Patron, has the RIGHT, to "Request", that 'FamilySearch", to "Delete"/"Remove" it.
.
But, such "Discussion", MUST be in VIOLATION, of the "Code of Conduct", not that a User/Patron, just DOES NOT, like; or, agree; or, appreciate, it.
.
Question: Is that WHAT you are referring to ... "Discussion", under "Collaboration"?
.
Please advise.
.
Brett
.
0 -
I believe Jeff has understood the problem correctly - i.e. this "idea" relates to the change log and not the editing of the statements inputted on the different pages in Family tree - e.g the "person" page.
Yes, it is annoying not to be able to alter / delete typos, etc., and to have several items (say a long piece of text you have regularly "saved" during typing) that are merely updates, but all then appear in the change log. However, there does need to be a complete record of all actions / inputs that have been made, otherwise you would also be able to delete important detail in the change log that should not be allowed to disappear.
In short, if you could edit the reason statements it almost certainly would mean you could disguise the history of inputs to a particular ID by being able to delete anything / everything else.
0 -
I believe Jeff has understood the problem correctly - i.e. this "idea" relates to the change log and not the editing of the statements inputted on the different pages in Family tree - e.g the "person" page.
Yes, it is annoying not to be able to alter / delete typos, etc., and to have several items (say a long piece of text you have regularly "saved" during typing) that are merely updates, but all then appear in the change log. However, there does need to be a complete record of all actions / inputs that have been made, otherwise you would also be able to delete important detail in the change log that should not be allowed to disappear.
In short, if you could edit the reason statements it almost certainly would mean you could disguise the history of inputs to a particular ID by being able to delete anything / everything else.
0 -
Paul
.
Wow ...
.
IF, so, it is the "ChangeLog"; THEN, that is a NON-ISSUE; as, you (a User/patron) should NEVER be able to ALTER to the "ChangeLog".
.
That is, in fact, would be, 'ridiculous' ...
.
Brett
.
0 -
Paul
.
Wow ...
.
IF, so, it is the "ChangeLog"; THEN, that is a NON-ISSUE; as, you (a User/patron) should NEVER be able to ALTER to the "ChangeLog".
.
That is, in fact, would be, 'ridiculous' ...
.
Brett
.
0 -
You can't actually change the original reason that has been recorded in the change log, but as Leroy Roberts pointed out, you CAN actually edit it but it just goes into a new change history event:
Note in my example above that you now have even ANOTHER inconsistency. The CHANGE column says that the vital was change, but in both entries above, that is WRONG. The vital was NOT changed. The Reason field text was changed.
So I also am not sure where Pynnges comment about not being able to edit the reason fields is coming from. Sure, the original entry in the change history cannot be modified, but no change history should ever be modifiable.
0 -
You can't actually change the original reason that has been recorded in the change log, but as Leroy Roberts pointed out, you CAN actually edit it but it just goes into a new change history event:
Note in my example above that you now have even ANOTHER inconsistency. The CHANGE column says that the vital was change, but in both entries above, that is WRONG. The vital was NOT changed. The Reason field text was changed.
So I also am not sure where Pynnges comment about not being able to edit the reason fields is coming from. Sure, the original entry in the change history cannot be modified, but no change history should ever be modifiable.
0