Hello Matt, there are lots of great comments on your topic - good question!
For making feature classes easier to identify or find, we use the ISO codes. So for example, i18_CalTrans_MjrHwy_15, where the i18 (transportation ISO), CalTrans (author of data), MjrHwy (subject), 15 (year of publication). And then, if additional resources/information are needed, you can create a dictionary/catalog of your data which would include metadata and use restrictions.
Good luck and be sure to provide your method (if not proprietary, of course).
Perhaps break it down by usage type instead (this is extremely simplified).
Publish (read-only, non-versioned)
Edit (versioned workspace)
The Publish data would be highly-available data that is not affected by versioning/editing overhead and easily consumed by data viewers and probably a better option if you intend to publish services off of the data.
The edit data would only be available to editors and internal applications that require edit and/or versioned processes.
You'd need to have some extract-load processes in place to move data between the two environments, but you'd de-couple the versioning/editing from the published data for enterprise usage. This way db admin tasks that require more involved/time consuming processes will not affect published, widely used data).
Good luck and be sure to provide your method (if not proprietary, of course).
Crystal,.