Select Reason for attachment of source
After attaching a source we must provide a reason. Would it not be an improvement
to have a list of reason for people to select from a list of options. It will take lest time
to select than to come up with an reason. Possible have a space to provide a reason of
their choose.
Comments
-
That reason is not required. I never use it. (Obviously, I'm attaching it because I believe it applies. I see absolutely no point to saying that.)
1 -
In my experience, when merging (which does provide default reasons), people always use the same reason regardless of whether that reason is actually true, i.e. "No details conflict", when, in fact, some of the details do conflict. Would it not be better if people actually took a moment to actually explain their reasoning, rather than lie through a default answer? The lack of any default reasons encourages people to actually think about what they say.
1 -
I use the reason statement rarely - most often when I'm repairing connections that have been made in error. I include a reason to support the disambiguation.
A reason for attaching a source and a reason for a merge are entirely different things.
2 -
Requiring a reason is useless if there's no consequences for not doing it or for the reason given being untrue or insufficient. I've seen countless merges saying "everything matches" when only the (very common) names match. I've also seem merges where two different couples were merged with the comment "wrong parents" which may have been correct for one child, but not for the rest of the family.
I've also seen "X" and 😃 given as reasons, though to be fair, it's hard to argue with those.
2 -
There are currently (as far as I know) only two circumstances under which a reason statement is required on FS: merges and some Source Linker-initiated profile creations.
Merges have four "boilerplate" reasons provided. Unfortunately, they're all equally useless and pointless and it doesn't really matter which one people choose, because the only actually useful detail in it will be the two PIDs involved. (Those are invaluable when you encounter the statement on a family member's profile, usually accompanying a scary-looking nonsensical "action" such as "relationship deleted".)
In merges, I use one of the standard reasons to get the IDs, and then edit it to explain what I found about the origin of the duplicate. (If you know why a profile was created, you have a much better chance of knowing who it was meant to be.) For example, the format I use most frequently is "PID2 was a legacy-data duplicate of PID1 based on the indexed baptism of his daughter {name} in {year}".
The other place where a reason is sometimes required is the "add person" screen that you get to from Source Linker. If the index entry you're working from is recent, then the "save" button is disabled unless there is at least one character in the box that's labeled at that point as something like "reason why you think this person is deceased". (It definitely says "reason why", which is just the start of the ugh.) This utterly-nonsensical requirement is in place regardless of what birth and death details you just finished adding for your person, which means that 99.9999% of the time, it's just an infuriating stupidity. As I've said before in this Community, my standard response is an exclamation mark, as a stand-in for the expletives that I actually want to say.
(No, I don't know how Source Linker defines "recent" for purposes of the required reason. I assume it depends on the indexed event date, but I don't know what the cutoff date is.)
The reason box for attaching a source is never -- thank goodness! -- required, and I seriously hope this never changes, because my lord, talk about infuriating stupidity! I mean, yes, it should be available, because sometimes it's helpful to be able to point out that "he's the godfather" or whatever, but how often does that apply?
1 -
@Julia Szent-Györgyi I don't know the exact point at which it asks you to make sure a person is deceased, but it is my understanding that it stops requiring that somewhere around the 100 years old mark. I personally think it should go for even longer, as 120 is sometimes, albiet rarely, surpassed.
0
