code table policy

[dustymc]

A few recent issues seem to be caused by not having sufficiently thorough policies regarding code tables. Can we do better, ideally (I think) as some sort of checklist or pathway: thingA has happened so now we can address thingB, and nobody will possibly consider thingC until thingB has been done and crossed off. I think I'm essentially asking for an expansion of https://github.com/ArctosDB/arctos/issues/new?assignees=&labels=Function-CodeTables&template=authority-request.md&title=Code+Table+Request+-+, but I'm really up for anything as long as it gets us all on the same page. Can we just add some sort of decision and implementation (or rejection) policy/checklist/???? to that template?

#5707 is relevant - Identifiers is the one subject that seems to necessitate arbitrary decisions, this may not be completely possible without addressing that first.

[Jegelewicz]

https://handbook.arctosdb.org/how_to/How-To-Manage-Code-Table-Requests.html was how I started, but it has never been formally accepted as how we do things. We want procedures, but we don't want to spend the time it takes to follow them. See also #2326

Which includes these things:

Code Table Admin Position Description
Code Table Management Procedures
Code Table Management Procedures Lite

I spent a lot of time on this and I am reluctant to spend any more if the answer will still be - "yes, that sounds like a good way to stop issues, but we don't have time to do that."

[dustymc]

Thanks!

I seem to whine about this because fairly often because I get stuck on cleanup duty, and from that perspective there's no possible way this couldn't be an efficiency. It must be frustrating for the collections who get caught up in it as well.

It looks like we need a 'someone added without following the procedures' procedure. I suggest this: DBAs will save what data they can while removing the offending terms in whatever way proves necessary. (That's also said in the interest of efficiency - the longer we wait around, the harder it is to stop messes, and those messes inspire messes.)

Access is perhaps less important under good procedures, but the list should be reviewed periodically.

"Doesn't stop Issues" should be a critical component of this. If that's me - and I suspect Lam or I reviewing is necessary to prevent the stuff that cost me several hours (and that's not done) over the last few days - then I'm very happy to put this in front of almost everything.

I'm happy to preemptively sign off on adding collection_cde to existing terms.

I'm happy to preemptively sign off on some specific scenarios - Nicole adding rock data doesn't make any messes, at least not any I'm capable of preemptively detecting, for example.

@mkoo can we just adopt https://handbook.arctosdb.org/how_to/How-To-Manage-Code-Table-Requests.html as some sort of Official Arctos Policy? (That should involve a move and re-name.) I'm sure it's imperfect but it seems like a very good start and - like all policies - it should be subject to amendment.

I will add some of the post-request stuff to the template in anticipation of that.

We also need more guidelines/policy aimed at definitions

• Definitions should explain how the term is used in collections; why data entry personnel should select it or a researcher would want to borrow it, and
• Updating definitions should be treated like a request for a new term; it is that, but with even more potential for messes.