Save Observer Confidence in the Observation

Presently Observation Confidence is being stored in the Observer, but is not copied to the Observation.  Do we want this behavior?

This would mean that at the time of sighting the confidence would be copied over.

Plus:
It would match what we know about them at the time of sighting - in case they later spent eight years studying biology we'd have an archive of what we thought they knew then.

Minus:
Any time we updated our confidence in an observer we'd have to march through all their old records and decide which records got updated and which didn't.  We'd need timespans effectively on confidence.

Please discuss...

What if they were an expert and we didn't know it?

Priority: -> normal
State: -> active
Client: -> Observations
Assigned: unassigned -> idfg-aschmidt

I could see us tagging an observer with a low confidence, without knowing they are actually an 'expert'. We would then have to go back to their previous entries and update those observations with the appropriate confidence value.  Would this also be a 'minus' in your mind? 

Yes, this is what I am

Yes, this is what I am referring to.  There's lots of room to maybe do it correctly.  There's no way to cleanly automate it.

So if it was archived in the observation and you changed an observer's confidence you'd have to march back through their observations and decide which ones to update.  Now we could (eventually) have it load up a view of all their old observations after a confidence is changed and prompt you to check a checkbox next to old observations to update.  Still, this is nasty.

It seems to me, the number of cases where someone's confidence changes over time is low enough to not necessitate this complexity.  Typically what is changing is our perception of their competence, not their actually skills.  If it's just our perception, then it makes sense to leave it just on the observer and it will naturally update the old records when joined to the observer field.

I would have to say most of

I would have to say most of the 'upgrades' we have had in the ACD/PCD were because we became aware of their competence - so keeping it in the observer would be fine.

However, with the public being involved more and more in our data contribution it may be useful to store it in the observation. 

One option is that we could just keep it in the observer area and see if it creates problems down the road. 

 

I would have to say most of

I would have to say most of the 'upgrades' we have had in the ACD/PCD were because we became aware of their competence - so keeping it in the observer would be fine.

However, with the public being involved more and more in our data contribution it may be useful to store it in the observation. 

One option is that we could just keep it in the observer area and see if it creates problems down the road. 

 

Totally unrelated (and

Totally unrelated (and probably should be a separate ticket) but I find these threaded comments annoying and would prefer a flat comment stream.  Does anyone disagree?

They also seem to encourage subthreading (opening new issues like this one inside another issue).  I don't think we want to encourage that.  It makes issues impossible to close.

Good points. When we run the

Good points.

When we run the algorithm/script to update the overall confidence, we'll need to account for what the new observation confidence is, anyway. What I'm saying is, the algorithm is going to want to/need to check that observer confidence anyway. How much "hands on" do we want in that process?

I say keep it in the observer and let the algorithm figure it out.

 

I disagree. Stop thinking

I disagree. Stop thinking about it.

Closed - works as designed

State: active -> closed

We'll open a new ticket later if we decide this is a road we want to go down.

Tough call.  My take is to

State: closed -> active

Tough call.  My take is to store with the observation.  

Yes, the majority of people will likely stay the same through their usage of the system.  However, others, such as myself have improved over time.  I spent five years collecting data for the Forest Service while going to college for a range science degree.  I would venture to guess that my collections in the first years weren't as good as the later ones.  On top of that, my background is strongest in botany and soils, while I have an animal record for wolf scat collected (I would give lower confidence than plants).  My current observations would receive high confidence, while I would leave the early ones low.  Along these lines, we receive data from BLM for field tech, doing summer work, while on school recess.  Perhaps, one solution may be to add areas of expertiese with date ranges to the observer profile (e.g., for me: Botany 20% prior to 2001; Botany 40% 2001-2003; Botany 60% 2004; Botany 80% 2005-present; Animal 60%).

Additionally, confidence shouldn't just be a blanket rating, just because of your email address extension (e.g., @idfg, @ blm, @ gmail, ...).  There are probably several people working for IDFG that should not receive a high confidence just because they're with IDFG.  Just like there are serveral experts that use personal email accounts that should be able to receive a high confidence (i.e., Roger Rosentreter and Curtis Bjork).

In most cases though wouldn't

In most cases though wouldn't this then be a different person?  I mean, not really.  But effectively we have the Jim at college, the Jim at Forest Service and the Jim at IDFG?

That works if the primary key

That works if the primary key is the email.  If we are trying to tie to a name/individual person, then it seems the confidence would overwrite.

State: active -> closed

Closing this for now.