Add latest changes from gitlab-org/gitlab@master

5 files changed, 72 insertions, 3 deletions

diff --git a/doc/development/README.md b/doc/development/README.md
index 7e1a563ea02..16b073045cc 100644
--- a/doc/development/README.md
+++ b/doc/development/README.md
@@ -151,6 +151,10 @@ description: 'Learn how to contribute to GitLab.'
 - [Frontend tracking guide](event_tracking/frontend.md)
 - [Backend tracking guide](event_tracking/backend.md)
 
+## Experiment Guide
+
+- [Introduction](experiment_guide/index.md)
+
 ## Build guides
 
 - [Building a package for testing purposes](build_test_package.md)
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index ee2a426db97..ccedb96d27d 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -267,7 +267,7 @@ GitLab CI is the open-source continuous integration service included with GitLab
 - Layer: Core Service (Processor)
 - Process: `gitlab-workhorse`
 
-[GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) is a program designed at GitLab to help alleviate pressure from Unicorn. You can read more about the [historical reasons for developing](https://about.gitlab.com/2016/04/12/a-brief-history-of-gitlab-workhorse/). It's designed to act as a smart reverse proxy to help speed up GitLab as a whole.
+[GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) is a program designed at GitLab to help alleviate pressure from Unicorn. You can read more about the [historical reasons for developing](https://about.gitlab.com/blog/2016/04/12/a-brief-history-of-gitlab-workhorse/). It's designed to act as a smart reverse proxy to help speed up GitLab as a whole.
 
 #### Grafana
 
diff --git a/doc/development/experiment_guide/index.md b/doc/development/experiment_guide/index.md
new file mode 100644
index 00000000000..5155433c9ad
--- /dev/null
+++ b/doc/development/experiment_guide/index.md
@@ -0,0 +1,65 @@
+# Experiment Guide
+
+Experiments will be conducted by teams from the [Growth Section](https://about.gitlab.com/handbook/engineering/development/growth/) and are not tied to releases, because they will primarily target GitLab.com.
+
+Experiments will be run as an A/B test and will be behind a feature flag to turn the test on or off. Based on the data the experiment generates, the team decides if the experiment had a positive impact and will be the new default or rolled back.
+
+## Follow-up issue
+
+Each experiment requires a follow-up issue to resolve the experiment. Immediately after an experiment is deployed, the deadline of the issue needs to be set (this depends on the experiment but can be up to a few weeks in the future).
+After the deadline, the issue needs to be resolved and either:
+
+- It was successful and the experiment will be the new default.
+- It was not successful and all code related to the experiment will be removed.
+
+In either case, an outcome of the experiment should be posted to the issue with the reasoning for the decision.
+
+## Code reviews
+
+Since the code of experiments will not be part of the codebase for a long time and we want to iterate fast to retrieve data,the code quality of experiments might sometimes not fulfill our standards but should not negatively impact the availability of GitLab whether the experiment is running or not.
+Experiments will only be deployed to a fraction of users but we still want a flawless experience for those users. Therefore, experiments still require tests.
+
+For reviewers and maintainers: if you find code that would usually not make it through the review, but is temporarily acceptable, please mention your concerns but note that it's not necessary to change.
+The author then adds a comment to this piece of code and adds a link to the issue that resolves the experiment.
+
+## How to create an A/B test
+
+- [ ] Add the experiment to the `Gitlab::Experimentation::EXPERIMENTS` hash in [`experimentation.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib%2Fgitlab%2Fexperimentation.rb):
+
+  ```ruby
+  EXPERIMENTS = {
+    other_experiment: {
+      #...
+    },
+    # Add your experiment here:
+    sign_up_flow: {
+      feature_toggle: :experimental_sign_up_flow, # Feature flag that will be used
+      environment: ::Gitlab.dev_env_or_com?, # Target environment
+      enabled_ratio: 0.1 # Percentage of users that will be part of the experiment. 10% of the users would be part of this experiments.
+    }
+  }.freeze
+  ```
+
+- [ ] Use the experiment in a controller:
+
+  ```ruby
+  class RegistrationController < Applicationcontroller
+   def show
+     # experiment_enabled?(:feature_name) is also available in views and helpers
+     if experiment_enabled?(:sign_up_flow)
+       # render the experiment
+     else
+       # render the original version
+     end
+   end
+  end
+  ```
+
+- [ ] Track necessery events. See the [event tracking guide](../event_tracking/index.md) for details.
+- [ ] After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) to enable the feature flag and start the experiment. For visibility, please run the command in the `#s_growth` channel:
+
+  ```
+  /chatops run feature set --project=gitlab-org/gitlab experimental_sign_up_flow true
+  ```
+
+  If you notice issues with the experiment, you can disable the experiment by setting the feature flag to `false` again.
diff --git a/doc/development/filtering_by_label.md b/doc/development/filtering_by_label.md
index 6aa7e7a5293..32df54eafd3 100644
--- a/doc/development/filtering_by_label.md
+++ b/doc/development/filtering_by_label.md
@@ -79,7 +79,7 @@ it did not improve query performance.
 
 ## Attempt B: Denormalize using an array column
 
-Having [removed MySQL support in GitLab 12.1](https://about.gitlab.com/2019/06/27/removing-mysql-support/),
+Having [removed MySQL support in GitLab 12.1](https://about.gitlab.com/blog/2019/06/27/removing-mysql-support/),
 using [Postgres's arrays](https://www.postgresql.org/docs/9.6/arrays.html) became more
 tractable as we didn't have to support two databases. We discussed denormalizing
 the `label_links` table for querying in
diff --git a/doc/development/testing_guide/end_to_end/quick_start_guide.md b/doc/development/testing_guide/end_to_end/quick_start_guide.md
index db32a9a87cf..2457d8ada5a 100644
--- a/doc/development/testing_guide/end_to_end/quick_start_guide.md
+++ b/doc/development/testing_guide/end_to_end/quick_start_guide.md
@@ -38,7 +38,7 @@ The GitLab QA end-to-end tests are organized by the different [stages in the Dev
 
 > There may be sub-directories inside the stages directories, for different features. For example: `.../browser_ui/2_plan/ee_epics/` and `.../browser_ui/2_plan/issues/`.
 
-Now, let's say we want to create tests for the [scoped labels](https://about.gitlab.com/2019/04/22/gitlab-11-10-released/#scoped-labels) feature, available on GitLab EE Premium (this feature is part of the Plan stage.)
+Now, let's say we want to create tests for the [scoped labels](https://about.gitlab.com/blog/2019/04/22/gitlab-11-10-released/#scoped-labels) feature, available on GitLab EE Premium (this feature is part of the Plan stage.)
 
 > Because these tests are for a feature available only on GitLab EE, we need to create them in the [EE repository](https://gitlab.com/gitlab-org/gitlab).