Docs: (EE Port) Merge EE doc/development to CE

70bedf4c · Marcel Amirault · Achilleas Pipinellis · 2ef5e28c · 70bedf4c · 70bedf4c
Commit 70bedf4c authored May 05, 2019 by Marcel Amirault Committed by Achilleas Pipinellis May 05, 2019
9 changed files
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -14,26 +14,29 @@ an issue (if there isn't one already) and leave a comment asking for it
 to be marked as `Accepting Merge Requests`. Please include screenshots or
 wireframes of the proposed feature if it will also change the UI.

-Merge requests should be submitted to the main project at
-[GitLab.com](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests).
+Merge requests should be submitted to the appropriate project at GitLab.com, for example
+[GitLab CE](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests),
+[GitLab EE](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests),
+[GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests),
+[GitLab Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests), etc.

 If you are new to GitLab development (or web development in general), see the
 [I want to contribute!](index.md#i-want-to-contribute) section to get started with
 some potentially easy issues.

-To start with GitLab development download the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit)
-and see the [Development section](../../README.md) for some guidelines.
+To start developing GitLab, download the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit)
+and see the [Development section](../../README.md) for the required guidelines.

 ## Merge request guidelines

-If you can, please include tests when submitting a merge request with a fix or
-improvement. If you don't know how to fix the issue but can write a test
+If you find an issue, please submit a merge request with a fix or improvement, if
+you can, and include tests. If you don't know how to fix the issue but can write a test
 that exposes the issue, we will accept that as well. In general, bug fixes that
 include a regression test are merged quickly, while new features without proper
-tests will be slower to receive feedback. The workflow to make a merge
+tests might be slower to receive feedback. The workflow to make a merge
 request is as follows:

-1. [Fork](../../workflow/forking_workflow.html#creating-a-fork) the project into
+1. [Fork](../../workflow/forking_workflow.md#creating-a-fork) the project into
   your personal namespace (or group) on GitLab.com.
 1. Create a feature branch in your fork (don't work off `master`).
 1. Write [tests](../rake_tasks.md#run-tests) and code.
@@ -42,7 +45,8 @@ request is as follows:
   [documentation guidelines](../documentation/index.md).
 1. Follow the [commit messages guidelines](#commit-messages-guidelines).
 1. If you have multiple commits, combine them into a few logically organized
-   commits by [squashing them](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing)
+   commits by [squashing them](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing),
+   but do not change the commit history if you're working on shared branches though.
 1. Push the commit(s) to your working branch in your fork.
 1. Submit a merge request (MR) to the `master` branch in the main GitLab project.
   1. Your merge request needs at least 1 approval, but feel free to require more.
@@ -103,8 +107,8 @@ in mind.

 ### Keep it simple

-Please keep the amount of changes in a single MR **as small as possible**. If you
-want to contribute a large feature, think very carefully about what the
+*Live by smaller iterations.* Please keep the amount of changes in a single MR **as small as possible**.
+If you want to contribute a large feature, think very carefully about what the
 [minimum viable change](https://about.gitlab.com/handbook/product/#the-minimally-viable-change)
 is. Can you split the functionality into two smaller MRs? Can you submit only the
 backend/API code? Can you start with a very simple UI? Can you do just a part of the
@@ -169,8 +173,9 @@ the contribution acceptance criteria below:
 1. If the merge request adds any new libraries (gems, JavaScript libraries, etc.),
   they should conform to our [Licensing guidelines](../licensing.md). See those
   instructions for help if the "license-finder" test fails with a
-   `Dependencies that need approval` error.
-1. The merge request meets the [definition of done](#definition-of-done), below.
+   `Dependencies that need approval` error. Also, make the reviewer aware of the new
+   library and explain why you need it.
+1. The merge request meets GitLab's [definition of done](#definition-of-done), below.

 ## Definition of done

@@ -179,14 +184,14 @@ code. We use the following [definition of done](https://www.agilealliance.org/gl
 Your contribution is not *done* until you have made sure it meets all of these
 requirements.

-1. Clear Description explaining the relevancy of the contribution.
+1. Clear description explaining the relevancy of the contribution.
 1. Working and clean code that is commented where needed.
 1. [Unit, integration, and system tests](../testing_guide/index.md) that all pass
   on the CI server.
 1. Performance/scalability implications have been considered, addressed, and tested.
 1. [Documented](../documentation/index.md) in the `/doc` directory.
 1. [Changelog entry added](../changelog.md), if necessary.
-1. Reviewed by relevant UX/FE/BE teams and any concerns are addressed.
+1. Reviewed by relevant (UX/FE/BE/tech writing) reviewers and all concerns are addressed.
 1. Merged by a project maintainer.
 1. Added to the [release post](https://about.gitlab.com/handbook/marketing/blog/release-posts/),
   if relevant.

--- a/doc/development/elasticsearch.md
+++ b/doc/development/elasticsearch.md
-# Elasticsearch knowledge
+# Elasticsearch knowledge **[STARTER ONLY]**

 This area is to maintain a compendium of useful information when working with elasticsearch.


--- a/doc/development/fe_guide/style_guide_scss.md
+++ b/doc/development/fe_guide/style_guide_scss.md
@@ -16,10 +16,12 @@ New utility classes should be added to [`utilities.scss`](https://gitlab.com/git

 **Background color**: `.bg-variant-shade` e.g. `.bg-warning-400`  
 **Text color**: `.text-variant-shade` e.g. `.text-success-500` 
+
 - variant is one of 'primary', 'secondary', 'success', 'warning', 'error'
 - shade is on of the shades listed on [colors](https://design.gitlab.com/foundations/colors/)

 **Font size**: `.text-size` e.g. `.text-2`
+
 - **size** is number from 1-6 from our [Type scale](https://design.gitlab.com/foundations/typography)

 ### Naming

--- a/doc/development/geo.md
+++ b/doc/development/geo.md
-# Geo (development)
+# Geo (development) **[PREMIUM ONLY]**

 Geo connects GitLab instances together. One GitLab instance is
 designated as a **primary** node and can be run with multiple
@@ -90,7 +90,7 @@ projects that need updating. Those projects can be:
  timestamp that is more recent than the `last_repository_successful_sync_at`
  timestamp in the `Geo::ProjectRegistry` model.
 - Manual: The admin can manually flag a repository to resync in the
-  [Geo admin panel](../user/admin_area/geo_nodes.md).
+  [Geo admin panel](https://docs.gitlab.com/ee/user/admin_area/geo_nodes.html).

 When we fail to fetch a repository on the secondary `RETRIES_BEFORE_REDOWNLOAD`
 times, Geo does a so-called _redownload_. It will do a clean clone
@@ -299,7 +299,7 @@ basically hashes all Git refs together and stores that hash in the
 The **secondary** node does the same to calculate the hash of its
 clone, and compares the hash with the value the **primary** node
 calculated. If there is a mismatch, Geo will mark this as a mismatch
-and the administrator can see this in the [Geo admin panel](../user/admin_area/geo_nodes.md).
+and the administrator can see this in the [Geo admin panel](https://docs.gitlab.com/ee/user/admin_area/geo_nodes.html).

 ## Glossary


--- a/doc/development/go_guide/index.md
+++ b/doc/development/go_guide/index.md
@@ -40,7 +40,7 @@ of possible security breaches in our code:
 - SQL injections

 Remember to run
-[SAST](../../user/application_security/sast/index.md)
+[SAST](https://docs.gitlab.com/ee/user/project/merge_requests/sast.html)
 **[ULTIMATE]** on your project (or at least the [gosec
 analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/gosec)),
 and to follow our [Security
@@ -94,9 +94,9 @@ become available, you will be able to share job templates like this
 Dependencies should be kept to the minimum. The introduction of a new
 dependency should be argued in the merge request, as per our [Approval
 Guidelines](../code_review.md#approval-guidelines). Both [License
-Management](../../user/application_security/license_management/index.md)
+Management](https://docs.gitlab.com/ee/user/project/merge_requests/license_management.html)
 **[ULTIMATE]** and [Dependency
-Scanning](../../user/application_security/dependency_scanning/index.md)
+Scanning](https://docs.gitlab.com/ee/user/project/merge_requests/dependency_scanning.html)
 **[ULTIMATE]** should be activated on all projects to ensure new dependencies
 security status and license compatibility.


--- a/doc/development/licensed_feature_availability.md
+++ b/doc/development/licensed_feature_availability.md
-# Licensed feature availability
+# Licensed feature availability **[STARTER]**

 As of GitLab 9.4, we've been supporting a simplified version of licensed 
 feature availability checks via `ee/app/models/license.rb`, both for 
@@ -7,8 +7,8 @@ on-premise or GitLab.com plans and features.
 ## Restricting features scoped by namespaces or projects

 GitLab.com plans are persisted on user groups and namespaces, therefore, if you're adding a
-feature such as [Related issues](../user/project/issues/related_issues.md) or 
-[Service desk](../user/project/service_desk.md), 
+feature such as [Related issues](https://docs.gitlab.com/ee/user/project/issues/related_issues.html) or 
+[Service desk](https://docs.gitlab.com/ee/user/project/service_desk.html), 
 it should be restricted on namespace scope.

 1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in 
@@ -22,8 +22,8 @@ project.feature_available?(:feature_symbol)

 ## Restricting global features (instance)

-However, for features such as [Geo](../gitlab-geo/README.md) and 
-[Load balancing](../administration/database_load_balancing.md), which cannot be restricted 
+However, for features such as [Geo](https://docs.gitlab.com/ee/administration/geo/replication/index.html) and 
+[Load balancing](https://docs.gitlab.com/ee/administration/database_load_balancing.html), which cannot be restricted 
 to only a subset of projects or namespaces, the check will be made directly in 
 the instance license.


--- a/doc/development/packages.md
+++ b/doc/development/packages.md
-# Packages
+# Packages **[PREMIUM]**

-This document will guide you through adding another [package management system](../administration/packages.md) support to GitLab.
+This document will guide you through adding another [package management system](https://docs.gitlab.com/ee/administration/packages.html) support to GitLab.

-See already supported package types in [Packages documentation](../administration/packages.md)
+See already supported package types in [Packages documentation](https://docs.gitlab.com/ee/administration/packages.html)

 Since GitLab packages' UI is pretty generic, it is possible to add new
 package system support by solely backend changes. This guide is superficial and does 
@@ -46,7 +46,7 @@ Group-level and instance-level endpoints are good to have but are optional.

 NOTE: **Note:**
 To avoid name conflict for instance-level endpoints we use 
-[the package naming convention](../user/project/packages/npm_registry.html#package-naming-convention)
+[the package naming convention](https://docs.gitlab.com/ee/user/project/packages/npm_registry.html#package-naming-convention)

 ## Configuration


--- a/doc/development/rake_tasks.md
+++ b/doc/development/rake_tasks.md
@@ -31,7 +31,7 @@ project.
 #### Seeding issues for Insights charts **[ULTIMATE]**

 You can seed issues specifically for working with the
-[Insights charts](../user/group/insights/index.md) with the
+[Insights charts](https://docs.gitlab.com/ee/user/group/insights/index.html) with the
 `gitlab:seed:insights:issues` task:

 ```shell

--- a/scripts/ee_specific_check/ee_specific_check.rb
+++ b/scripts/ee_specific_check/ee_specific_check.rb
@@ -81,13 +81,13 @@ module EESpecificCheck
    'doc/ci/variables/**/*',
    'doc/ci/yaml/**/*',
    'doc/container_registry/**/*',
-    # 'doc/customization/**/*',
-    # 'doc/customization/branded_login_page/**/*',
-    # 'doc/customization/branded_page_and_email_header/**/*',
-    # 'doc/customization/favicon/**/*',
-    # 'doc/customization/help_message/**/*',
-    # 'doc/customization/new_project_page/**/*',
-    # 'doc/customization/system_header_and_footer_messages/**/*',
+    'doc/customization/**/*',
+    'doc/customization/branded_login_page/**/*',
+    'doc/customization/branded_page_and_email_header/**/*',
+    'doc/customization/favicon/**/*',
+    'doc/customization/help_message/**/*',
+    'doc/customization/new_project_page/**/*',
+    'doc/customization/system_header_and_footer_messages/**/*',
    'doc/development/*.md',
    'doc/development/contributing/**/*',
    'doc/development/documentation/**/*',