We have all user issues/requests logged on our production server as a particular item type. The workflow for that item type handles approvals, design, testing and promotion to the production server.
On that item type, we've added a multiselect pick field with all the item types in the system as well as a longtext field to mention the exact details. Administrators fill out those fields while working on the change for the specific item.
Before we promise a deploy date for a particular change, we look to those impact fields to analyze which changes are in flight and to determine if multiple changes need to be deployed simultaneously because they affect the same object.
Even though it is a manual process to both document and analyze the changes, we've found its better than just promoting from memory or based on the description of the change.
We've also found that by grouping the related changes up front (for example bundling several changes to a specific Type) then having those changes tested and cleared to deployed to production as a bundle, we end up having fewer collisions when it comes time to actually do the migration.
Of course sometimes critical things happen and in those cases, we back out the non critical changes to the object, deploy to production, then add the non-critical changes back in. Documenting the changes as we go is definitely helpful here, otherwise it ends up being poring through the object's history and hoping to not forget anything.
Matt Giltaji
PS, if there is any RFC for tying admin changes to an item along the same lines of how change packages tie to an item, and then migrating from staging to production along those lines, please add me to the RFC.
