Use These Automation Options Sparingly

A published piece of content may include a mix of author-managed text and images along with automated values such as Content Management System (CMS) author, published date, or last updated date.

There are some automation options that I've seen implemented well (and easily with SDL Tridion, btw), but don't reflect the actual long-term business or visitor requirements.

• Original author. Relevant because we want to automate adding the author to a given piece of content. Organizations also want audit, track, and blame, I mean credit who created what.
• Original publish date. Relevant because we don't want authors to have to manually add this value.
• Last updated date. Relevant because we want to know if content has been updated.

These are all great requirements, but don't rely on just your CMS's automated values for these.

• Original author may not match the editor that enters the content. Typical scenarios include a a centralized team of authors creating and managing content. Your subject matter expert might want to review that blog post or their upcoming article, but they might not actually enter it into the system (or might not be the author that starts the article).
• The system's initial publish date is fine until you move content between environments or migrate parts of content. 
• Last update date is tricky because this can't just be the last published date or the last edit. For content types where dates matter (policies, guidelines, and other official documentation), you'll tend to need several types of dates such as:
• Published, Posted, or Release Data
• Effective Date

To better reflect these requirements, consider a mix of approaches:

• Set good defaults and make options select-able. For example, by default set author to the most prolific author for a given type of content.
• Read values from organizational items (folders), metadata, and taxonomy--if items have the same author you could manage all articles by a given author in the same folder and have your templates get this information from the folder's metadata. 
• Automate these values, possibly in creation, but leave them in actual content fields to give authors the ability to change and update them as needed.
• Default to system values unless authors enter something different. The automated options then become just-in-case "fall backs."

Which approach to choose? It depends on your team's skills and interests and content strategy. I've seen everything from organizations fully extending the CMS's UI to developers that can easily automate  anything to teams that live mostly in delivery (.NET or Java).

If accurate, timely updates help your organization accomplish it's mission (revenue, conversions, whatever) or incorrect values can lead to pain (i.e. lawsuits), put in the effort to create a good experience for the visitor and your authors. If the numbers, research, or your authors' feedback suggest no one reads this part of your site, then maybe skip these altogether and work on the content and context that matters.

Update: We recently saw a question on how to get the Last Published Date for SDL Tridion on Tridion Stack Exchange from community member, Hiren. This value isn't as bad as original publish date or last updated, except for system changes. It's worth confirming if authors would ever want to "back date" the value--if so, then we'd want an actual component field or way of letting authors change this value.