Clarify master:broken guidelines can use the dev-escalation
Why is this change being made?
There are circumstances where releases may be blocked by an unresolved ~master:broken and this change helps clarify that dev-escalation can be used for those circumstances.
The current dev escalation guidelines cover the example that was raised to my attention:
GitLab.com deployment or a security release is blocked due to pipeline failure.
This also clarifies that the default resolution option is to Revert.
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(this requirement has been removed pending identification of a new DRI for the handbook)@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.
Edited by Kyle Wiebers