Process to release revenue impacting changes

Why is this change being made?

Although we try to work by our core values, including iteration, some larger projects we've released over the past year, specifically those which impact revenue, have required more scrutiny by other organizations than is common with other GitLab engineering projects, and this likely to continue going forward.

I'm not sure what the process should be to release revenue impacting changes, but I'd like to have that conversation and document it rather than being implemented in an ad-hoc fashion.

Author Checklist

• Provided a concise title for the MR
• Added a description to this MR explaining the reasons for the proposed change, per say-why-not-just-what
• Assign this change to the correct DRI
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the "Maintained by" section in on the page being edited.
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies.
  • If the changes relate to any part of the project other than updates to content and/or data files please make sure to ping @gl-static-site-editor in a comment for a review and merge. For example changes to .gitlab-ci.yml, JavaScript/CSS/Ruby code or the layout files. (this requirement has been removed pending identification of a new DRI for the handbook)