We are moving our very outdated and unorganized system to the Enterprise Geodatabase format. My biggest fear is people are going to be creating content, naming it randomly (or names only they understand), and dropping it willy-nilly into our shiny new system. In 3 years, we'll be back to this mess we have now. I'd love hear people's thoughts and systems for file organization, especially data file/layer naming nomenclature. What works for your organizations?
@RachaelMurtaugh, a few best practices I can suggest (hopefully not obvious things you've already put into practice):
I'll try to post a few more as I remember them. I hope these will be helpful!
@ThomasHamill Agreed! Especially the suffixes part. When we moved our stuff from a legacy system to our new setup, we had so many badly-named files, like "layer_final", "layer_final_2", "layer_final_final_x". It was impossible to know what was what.
I don't know how much of this applies to your situation, but we moved as many of our GIS layers to our Portal as possible, and the Enterprise Geodatabase is not available directly, only via registered services. Since layers there are referenced by URL or ID, the visible name, categorization, ownership, etc., can all be endlessly reconfigured to make things easier to find and interact with.
For our non-spatial stuff like files, some of it can also be added to a Portal, like shared project packages and templates. For other operational documents, we use GitHub to manage things like scripts and custom-built viewers, so that any of our staff can pull in the latest official version of things, on any machine, and you can then take advantage of things like multiple branches to develop new ideas or test things out without risking "damage".
Of course, not everything makes sense to have on GitHub, and sometimes it's just a folder on the network. I don't have as much helpful advice on that, because our network drive is a bit of a mess. If you can establish a folder structure ahead of time and maybe some basic filename conventions, and then get other staff to actually stick to it, I think that's a start.
Sort of "above" all of that, we maintain a department wiki. Any time we need to document, establish, or refine a process or standard, we do it there. That way, any current and future staff will be able to easily reference standard operating procedures. I'm a big fan of having internal wikis, I think they're very helpful. (And I'd highly recommend wiki.js for anyone thinking about making one!)
Not sure if you’re looking for SDE object naming conventions or not, but a few come to mind: