diff options
| author | Mek Stittri <mstittri@gitlab.com> | 2018-06-18 14:26:46 -0700 |
|---|---|---|
| committer | Mek Stittri <mstittri@gitlab.com> | 2018-06-18 14:44:54 -0700 |
| commit | 89897a05d6c373a6ac1ab9ee7d0e4290170d46df (patch) | |
| tree | 51daef2603840dd496b056d013f9d60e6c8c321c | |
| parent | afa47b7c481210df659706930a9f43d53023ce5e (diff) | |
| download | gitlab-ce-ux-issues-bypass-exception-request.tar.gz | |
Low risk UX issue that does not require an exceptionux-issues-bypass-exception-request
| -rw-r--r-- | PROCESS.md | 9 |
1 files changed, 7 insertions, 2 deletions
diff --git a/PROCESS.md b/PROCESS.md index a46fd8c25b4..ed174c29eb6 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -168,10 +168,15 @@ the stable branch are: * Fixes for [regressions](#regressions) * Fixes for security issues +* Fixes for low risk UX issues + * If the issue is a ~S4 Severity and does not require a Backend change to address. + * Requires a review from a UX team member for sign-off. * Fixes or improvements to automated QA scenarios * Documentation updates for changes in the same release * New or updated translations (as long as they do not touch application code) +Anything else needs to go through an [Exception Request](#asking-for-an-exception). + During the feature freeze all merge requests that are meant to go into the upcoming release should have the correct milestone assigned _and_ the `Pick into X.Y` label where `X.Y` is equal to the milestone, so that release @@ -192,7 +197,7 @@ to. For example: - `Pick into 10.0` - `Pick into 9.5` -### Asking for an exception +### Asking for an Exception If you think a merge request should go into an RC or patch even though it does not meet these requirements, you can ask for an exception to be made. @@ -209,7 +214,7 @@ Whether an exception is made is determined by weighing the benefit and urgency o (how important it is to the company that this is released _right now_ instead of in a month) against the potential negative impact (things breaking without enough time to comfortably find and fix them before the release on the 22nd). -When in doubt, we err on the side of _not_ cherry-picking. +When in doubt, we error on the side of _not_ cherry-picking. For example, it is likely that an exception will be made for a trivial 1-5 line performance improvement (e.g. adding a database index or adding `includes` to a query), but not for a new feature, no matter how relatively small or thoroughly tested. |