Skip to content

Adds rollout plan and roles definitions for Support Change Mangement

Mike Dunninger requested to merge mdunninger-support-change-rollout into master

Why is this change being made?

The first phase of our Change Management in Support process has been published (see this page). This is the next iteration on the process definition, focused on how to announce and roll out changes.

See the Rolling Out Changes issue for the discussion that preceded this MR.

The proposed changes:

  1. Add guidance on the use of issues and MRs in managing change proposals
  2. Define roles that are relevant to change management in our support team
  3. Introduce the use of the new issue template for rolling out changes. This issue template contains the bulk of the process change being proposed here. Please review it in addition to the Support Change Management page in the handbook.

Author Checklist

  • Correct MR template applied (e.g blog post)
  • 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 your manager.
    • 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.

For help with failing pipelines reach out in #mr-buddies in Slack

Merge request reports