From a0e5c299e371ada2ff0229e09dbb002f51970794 Mon Sep 17 00:00:00 2001 From: Fabio Busatto Date: Fri, 9 Mar 2018 14:49:39 +0000 Subject: [PATCH] Simplified the process --- PROCESS.md | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index 6da55b632fe..29e66284989 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -240,8 +240,7 @@ available in the package repositories. Regressions are very important, and they should be considered high priority issues that should be solved as soon as possible, expecially if they affect -users. Anyway, ~regression label itself is not a [priority label], and this -means that regressions should still follow the scheduling process. +users. Anyway, ~regression label itself is not a [priority label]. When a regression is found: 1. Create an issue describing the problem in the most detailed way possible @@ -250,20 +249,17 @@ When a regression is found: and any other label that may apply in the specific case 3. Add the ~regression label 4. Add the proper milestone -4. Ping the Product Manager for proper scheduling, see - [product categories](https://about.gitlab.com/handbook/product/categories/) - to find who manages that specific area of the Product + +If the regression is relevant and not just a minor fix, ping the Product Manager +in the issue, see [product categories](https://about.gitlab.com/handbook/product/categories/) +to find who manages that specific area of the Product. In case you are in doubt +to ping or not, do it. A very important step is helping the PM to understand the impact the regression may have on users, by providing examples and how to reproduce it. This will -allow proper scheduling with a [priority label]. Normally it will be -~"Next Patch Release" if after the final release, or ~Deliverable if between the -feature freeze and the final release. - -In case of very urgent fixes, a developer can choose to pick up the issue even -before it is properly scheduled, in order to speed up the process. The PM should -be pinged in the issue anyway to get confirmation about the actual priority as -soon as possible. +allow proper scheduling. Feel free to put ~"Next Patch Release" label to the +issue so the fix can start immediately, the PM will discuss and prioritize it as +needed if necessary. ## Release retrospective and kickoff