Laydown process for bugs and regressions

1 files changed, 42 insertions, 28 deletions

diff --git a/PROCESS.md b/PROCESS.md
index ef25efb61ff..2416ec93275 100644
--- a/PROCESS.md
+++ b/PROCESS.md
@@ -201,30 +201,53 @@ you can ask for an exception to be made.
 
 Check [this guide](https://gitlab.com/gitlab-org/release/docs/blob/master/general/exception-request/process.md) about how to open an exception request before opening one.
 
+## Bugs
+
+A ~bug ia a defect, error, failure which causes the system to behave incorrectly or preventing it from fulfill the product requirements.
+
+The level of impact of a ~bug can vary from blocking a whole functionality or a feature usability bug.
+
+A bug should always be linked to a severity level. Refer to our [severity levels](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#severity-labels)
+
+### Managing a Bug
+
+When a regression is created:
+1. Create an issue describing the problem in the most detailed way possible.
+1. If possible, provide links to real examples and how to reproduce the problem.
+1. Label the issue properly, using the [team label](../CONTRIBUTING.md#team-labels),
+   the [subject label](../CONTRIBUTING.md#subject-labels)
+   and any other label that may apply in the specific case
+1. Add the ~bug label
+1. Notify the respective Engineering Manager to evaluate the Severity of the regression and add a [Severity label](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#bug-severity-labels). The counterpart Product Manager is included to weigh-in on prioritization as needed to set the [Priority label](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#bug-priority-labels).
+1. From the Severity and Priority level the Engineering Manager then decides which milestone to set on the bug.
+
 ## Regressions
 
-A regression for a particular monthly release is a bug that exists in that
-release, but wasn't present in the release before. This includes bugs in
-features that were only added in that monthly release. Every regression **must**
-have the milestone of the release it was introduced in - if a regression doesn't
-have a milestone, it might be 'just' a bug!
+A ~regression implies that a previously **verified working functionality** no longer works.
+Regressions are a subset of bugs. We use the ~regression label to imply that the defect caused the functionality to regress.
+
+The regression label does not apply to ~bugs for new features which functionality was **never verified as working**. 
+That by definition are not regressions. The ~regression label is not removed as part of any rescheduling process. 
+If an issue is indeed a regression, it should carry such context forward until it's fully resolved.
 
-For instance, if 10.5.0 adds a feature, and that feature doesn't work correctly,
-then this is a regression in 10.5. If 10.5.1 then fixes that, but 10.5.3 somehow
-reintroduces the bug, then this bug is still a regression in 10.5.
+A regression should always have the `regression:xx.x` label on it to designate when it was introduced.
 
-Because GitLab.com runs release candidates of new releases, a regression can be
-reported in a release before its 'official' release date on the 22nd of the
-month. When we say 'the most recent monthly release', this can refer to either
-the version currently running on GitLab.com, or the most recent version
-available in the package repositories.
+### Managing a Regression
 
-### How to manage a regression
+**Prioritization**
 
-Regressions are very important, and they should be considered high priority 
-issues that should be solved as soon as possible, especially if they affect
-users. Despite that, ~regression label itself does not imply when the issue
-will be scheduled.
+A ~regression label tells us that something worked before and it needs extra attention from Engineering and Product Managers to schedule/reschedule. 
+
+Regressions should be considered high priority issues that should be solved as soon as possible, especially if they have severe impact on users. 
+
+We give higher priority to regressions that affected the last recent monthly release and the current release candidates. 
+The two scenarios below can [by pass the exception request in the release process](LINK_HERE_TO_RM_DOC)
+* A regression in the **Last recent monthly release**
+   * If in 11.0 we released a new `feature X` that is verified as working. Then in release 11.1 the feature no longer works this is regression for 11.0. The issue should have the `regression:11.0` label.
+   * **Note:** When we say `the last recent monthly release`, this can refer to either the version currently running on GitLab.com, or the most recent version available in the package repositories.
+* A regression in the **Current release candidates**
+   * If in 11.1-RC3 w
+   * **NOte:** Because GitLab.com runs release candidates of new releases, a regression can be reported in a release before its 'official' release date on the 22nd of the month. 
 
 When a regression is found:
 1. Create an issue describing the problem in the most detailed way possible
@@ -239,18 +262,9 @@ When a regression is found:
   1. If the regression was introduced in the previous release, label with ~"Next Patch Release"
 1. If the regression is an ~S4 severity, the regression may be scheduled for later milestones at the discretion of Engineering Manager and Product Manager.
 
-When a new issue is found, the fix should start as soon as possible. You can
-ping the Engineering Manager or the Product Manager for the relative area to
-make them aware of the issue earlier. They will analyze the priority and change
-it if needed.
-
-A ~regression label implies that a regress in functionality happened, a functionality which worked previously but no longer works currently.
-The ~regression label is not removed as part of the "Rescheduling" process. If an issue is indeed a regression, it should carry such context forward until it's fully resolved. 
-A ~regression label on a ~bug tells us that something worked before and it needs extra attention from Engineering and Product Managers to schedule/reschedule. 
+When a new issue is found, the fix should start as soon as possible. You can ping the Engineering Manager or the Product Manager for the relative area to make them aware of the issue earlier. They will analyze the priority and change it if needed.
 
-The milestone of a ~regression is used to schedule when the fix will be delivered. The creation time of a ~regression tells us which release it was found in.
 
-A ~regression label does not apply to ~bugs for new features. That by the definition above are not regressions.
 
 ## Release retrospective and kickoff