Change log clutter

LegacyUser

Paul said: Until recently, I was rather baffled to see long comments / notes I had added against a particular ID repeated over and over again. Suddenly it clicked that it was down to my fussiness in correcting typos and making other minor changes.

I can see the reason users cannot edit items in the change log, but it is painful having to plough through all that "duplicate" detail. Also, I'd be so pleased to be able to add a note directly against some stupid action I'd taken, to clearly show I had immediately realised my mistake.

I don't know what other users' change logs look like, but many of mine appear as a rambling mess!

LegacyUser

Brett said: Paul

I know what you mean ...

Even something like the "FamilySearch" 'Wiki', where you can indicate if the "Edit" was a "Minor" one.

And, for example, if such was the case, in the "ChangeLog", it would appear as an 'Event' (ie. Change) that was "Collapsed"; but, could/would be "Viewed" (ie. "Expanded"); IF, one so desired.

Plus, it may even be a good idea to have such a feature/function/facility as "Retrospective" - that is to say, the ability to "Mark" an 'Event' (ie. Change) as "Minor" in the "ChangeLog". The real consideration would be if such would only apply (ie. be available) to the Original User/Patron who made the Original "Change"; or, any User/Patron.

Just a thought.

Brett

.

LegacyUser

Jeff Wiseman said: Yea, The text should be the justification for ONLY the one change to a given vital. The field should be blanked when the next change to the vital is made, since the justification for a subsequent change will ALWAYS be different from the previous one.

On top of this, if you go back in and change the reason field on a vital, THAT IS NOT A CHANGE EVENT! It is only a correction to the contents of the previous change event that was recorded in the log.

For example, if you make a change to the Birth Vital and then go back 3 more times and do spelling corrections in the reason field only, there should NEVER be 3 more change events recorded for that Birth Vital in the change history log since the Birth vital was only altered ONCE!

The persistence of text in that field from one change event to the next is completely WRONG. It is a result of an attempt to hack the justification for the change OF A SINGLE CHANGE EVENT into some kind of vital derivation logic which is a totally different thing and needs to be handled differently! The derivation logic does not belong there because that text is unique to one and ONLY one Change Event that has been recorded in the change history log.

That reason statement is NOT an attribute of the vital (the way a description of how the vital is derived from sources, etc). It is an attribute of a Change Event, and by mixing apples and oranges in the same field, it will never come across as an easy to understand entity because it will always be schizophrenic. On the surface it looks simple, but the way it is typically understood by people using it is frequently wrong (And they won't find out about it until data they entered appears to have disappeared from the edit screen for the vital)

Anytime a person goes into the system and wants to know why a vital has a particular value, YOU SHOULD NEVER HAVE TO GO INTO THE CHANGE HISTORY and attempt to gather together all the pieces that contribute to the conclusion. That text is only for the justification for those change events. You should be able to go to the vital and immediately see there either an attribute saved with the vital or a NOTE attached to it that fully describes the complete derivation of that vital's values. If the derivation is dirt simple (i.e., a source is a birth certificate and it is tagged to the Birth vital) the simple tagging of sources is more than adequate.

If you need more that that, put the derivation logic into a NOTE titled with the vital name--and BETTER YET, add the ability to TAG that note to the vital in an identical fashion as the sources are at present.

LegacyUser

ATP said: Yep! What you said! Especially last 2 paragraphs!

LegacyUser

Adrian Bruce said: But Change Logs are where I put my "Mr Pendantry" hat on. Either a Change Log is a record of all changes or it's a road to ruin.

No I can't possibly justify why I might want the system to record all your spelunking Miss Kates - but I can guarantee that as soon as we start giving the designers the option to record or not record, we will get wrong decisions from them and we'll be missing important stuff. We won't realise that they've dropped important data until months after the event but, sooner or later, that realisation will come. I'm not criticising the designers - just stating a fact that not every decision can be guaranteed 100% correct.

After all, we're already at the stage where the Change Logs don't include the result of place-name standardisation runs by FS. I therefore can't tell whether profiles that incorrectly have "Crewe-by-Farndon, Cheshire, England, United Kingdom" instead of "Crewe, Cheshire, England, United Kingdom", have that incorrect place-name as a result of someone choosing the wrong standardisation on original input or because FS ran a standardisation run that "corrected" "Crewe, Cheshire, England, United Kingdom" to "Crewe-by-Farndon, Cheshire, England, United Kingdom".

That's why I really, really want Change Logs to include everything that's changed. Anything else is a slippery slope to perdition.

(The exact details of that last issue are not relevant here - the important point is that I can't tell if a standardisation run has taken place.)

Incidentally, I am not dismissing Paul's clutter problem - what it illustrates is that the Change Log should not be used as a matter of course, only as a last resort. See Jeff's contention about the necessity for "why a vital has a particular value" being in one spot, not spread over Change Logs.

LegacyUser

Jeff Wiseman said:

But Change Logs are where I put my "Mr Pendantry" hat on. Either a Change Log is a record of all changes or it's a road to ruin.

Agreed. But again, Change Logs document Change Events and the justification for those CHANGES. See my recent entry in:

https://getsatisfaction.com/familysea...