COCs and other practices

COCs need action by PIs - IM has little say in what he/she gets from the field people, Kathy is a bit also in the dark. the process is still there, and while the technology workflow that backs it can be seriously improved, the real elephant in the room is the process itself. a better editorial and field workflow can be implemented using DEIMS, but there has to be the backing of the lords.

========
most stream core data is in. BUT we have some some records that were rejected cause their locations were not at the 'core location'. Adding such gage ids to the master gauge locations table would include some recent rejects, including DOC, NUT and CHEM tables. There is also the possibility of including non-long-term-locations by doing the strmgageid look-up (db constraint) to the more general gage locations table --while would include 95% of the rejects, it sort of breaks a bit the concept of these are repeated measurements in same locations: there is the question of whether those are still core-long-term records or not -- from the point of view of the measurable, yes, but the context of the measureble (location) changes a bit when including opportunistic/non-core locations.

topic for Tina to bring up in next PI meeting...

"The problem is that we'll receive a pile of samples to analyze in McMurdo with no COC form, so we don't know who collected them or what project they're associated with. That's what is listed in the "non-core" tab of the file I sent you - samples that came in with stream team samples, but aren't for "core" locations. We can sometimes guess who's samples they are based on where/when they were collected, but other times we have no idea. I don't know if it would be worth creating a separate table for all these "non-core" locations, because we don't know much about them. I think the best thing is to force people to fill out COCs and follow up with them regarding the details of the sample locations later that year, "

Status: 

Priority: 

Normal