Merge branch '7190-fix-docs' into 'master'

Resolve "Job Failed #87998831"

Closes #7190

See merge request gitlab-org/gitlab-ee!6856

doc/development/contributing/design.md

@@ -49,9 +49,9 @@ issues for implementation in an upcoming milestone.
 1.  [Testing][testing]
 1.  [JavaScript styleguide][js-styleguide]
 1.  [SCSS styleguide][scss-styleguide]
-1.  [Shell commands](doc/development/shell_commands.md) created by GitLab
+1.  [Shell commands](../shell_commands.md) created by GitLab
     contributors to enhance security
-1.  [Database Migrations](doc/development/migration_style_guide.md)
+1.  [Database Migrations](../migration_style_guide.md)
 1.  [Markdown](http://www.cirosantilli.com/markdown-styleguide)
 1.  [Documentation styleguide](https://docs.gitlab.com/ee/development/documentation/styleguide.html)
 1.  Interface text should be written subjectively instead of objectively. It
@@ -64,3 +64,7 @@ issues for implementation in an upcoming milestone.
 This is also the style used by linting tools such as
 [RuboCop](https://github.com/bbatsov/rubocop),
 [PullReview](https://www.pullreview.com/) and [Hound CI](https://houndci.com).
+
+---
+
+[Return to Contributing documentation](index.md)

doc/development/contributing/index.md

@@ -51,7 +51,7 @@ edition. Throughout this guide you will see references to CE and EE for
 abbreviation.
 
 If you have read this guide and want to know how the GitLab [core team]
-operates please see [the GitLab contributing process](PROCESS.md).
+operates please see [the GitLab contributing process](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/PROCESS.md).
 
 - [GitLab Inc engineers should refer to the engineering workflow document](https://about.gitlab.com/handbook/engineering/workflow/)
 
@@ -138,9 +138,9 @@ When contributing to GitLab, your merge request is subject to review by merge re
 
 When you submit code to GitLab, we really want it to get merged, but there will be times when it will not be merged.
 
-When maintainers are reading through a merge request they may request guidance from other maintainers. If merge request maintainers conclude that the code should not be merged, our reasons will be fully disclosed. If it has been decided that the code quality is not up to GitLab’s standards, the merge request maintainer will refer the author to our docs and code style guides, and provide some guidance.
+When maintainers are reading through a merge request they may request guidance from other maintainers. If merge request maintainers conclude that the code should not be merged, our reasons will be fully disclosed. If it has been decided that the code quality is not up to GitLab’s standards, the merge request maintainer will refer the author to our docs and code style guides, and provide some guidance.
 
-Sometimes style guides will be followed but the code will lack structural integrity, or the maintainer will have reservations about the code’s overall quality. When there is a reservation the maintainer will inform the author and provide some guidance.  The author may then choose to update the merge request. Once the merge request has been updated and reassigned to the maintainer, they will review the code again. Once the code has been resubmitted any number of times, the maintainer may choose to close the merge request with a summary of why it will not be merged, as well as some guidance. If the merge request is closed the maintainer will be open to discussion as to how to improve the code so it can be approved in the future.
+Sometimes style guides will be followed but the code will lack structural integrity, or the maintainer will have reservations about the code’s overall quality. When there is a reservation the maintainer will inform the author and provide some guidance.  The author may then choose to update the merge request. Once the merge request has been updated and reassigned to the maintainer, they will review the code again. Once the code has been resubmitted any number of times, the maintainer may choose to close the merge request with a summary of why it will not be merged, as well as some guidance. If the merge request is closed the maintainer will be open to discussion as to how to improve the code so it can be approved in the future.
 
 GitLab will do its best to review community contributions as quickly as possible. Specially appointed developers review community contributions daily. You may take a look at the [team page](https://about.gitlab.com/team/) for the merge request coach who specializes in the type of code you have written and mention them in the merge request.  For example, if you have written some JavaScript in your code then you should mention the frontend merge request coach. If your code has multiple disciplines you may mention multiple merge request coaches.
 
@@ -156,23 +156,23 @@ This [documentation](issue_workflow.md) outlines the current workflow labels.
 
 ### Type labels
 
-This [documentation](issue_worfklow.md) outlines the current type labels.
+This [documentation](issue_workflow.md) outlines the current type labels.
 
 ### Subject labels
 
-This [documentation](issue_worfklow.md) outlines the current subject labels.
+This [documentation](issue_workflow.md) outlines the current subject labels.
 
 ### Team labels
 
-This [documentation](issue_worfklow.md) outlines the current team labels.
+This [documentation](issue_workflow.md) outlines the current team labels.
 
 ### Milestone labels
 
-This [documentation](issue_worfklow.md) outlines the current milestone labels.
+This [documentation](issue_workflow.md) outlines the current milestone labels.
 
 ### Bug Priority labels
 
-This [documentation](issue_worfklow.md) outlines the current bug priority  labels.
+This [documentation](issue_workflow.md) outlines the current bug priority  labels.
 
 ### Bug Severity labels
 
@@ -236,7 +236,11 @@ This [documentation](merge_request_workflow.md) outlines the current acceptance
 
 ## Definition of done
 
-This [documentation](merge_request_workflow.md) outlines the defintion of done.
+This [documentation](merge_request_workflow.md) outlines the definition of done.
 
 ## Style guides
 This [documentation](design.md) outlines the current style guidelines.
+
+---
+
+[Return to Development documentation](../README.md)

doc/development/contributing/issue_workflow.md

@@ -95,7 +95,7 @@ The current team labels are:
 - ~Plan
 - ~Quality
 - ~Release
-- ~"Security Products"
+- ~Secure
 - ~UX
 
 The descriptions on the [labels page][labels-page] explain what falls under the
@@ -224,15 +224,14 @@ on those issues. Please select someone with relevant experience from the
 the commit history for the affected files to find someone.
 
 We also use [GitLab Triage] to automate some triaging policies. This is
-currently setup as a [scheduled pipeline] running on the [`gl-triage`] branch.
-
+currently setup as a [scheduled pipeline] running on [quality/triage-ops]
+project.
 
 [described in our handbook]: https://about.gitlab.com/handbook/engineering/issue-triage/
 [issue bash events]: https://gitlab.com/gitlab-org/gitlab-ce/issues/17815
 [GitLab Triage]: https://gitlab.com/gitlab-org/gitlab-triage
-[scheduled pipeline]: https://gitlab.com/gitlab-org/gitlab-ce/pipeline_schedules/3732/edit
-[`gl-triage`]: https://gitlab.com/gitlab-org/gitlab-ce/tree/gl-triage
-
+[scheduled pipeline]: https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/edit
+[quality/triage-ops]: https://gitlab.com/gitlab-org/quality/triage-ops
 
 ### Feature proposals
 
@@ -251,7 +250,7 @@ code snippet right after your description in a new line: `~"feature proposal"`.
 Please keep feature proposals as small and simple as possible, complex ones
 might be edited to make them small and simple.
 
-Please submit Feature Proposals using the ['Feature Proposal' issue template](.gitlab/issue_templates/Feature Proposal.md) provided on the issue tracker.
+Please submit Feature Proposals using the ['Feature Proposal' issue template](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab/issue_templates/Feature Proposal.md) provided on the issue tracker.
 
 For changes in the interface, it is helpful to include a mockup. Issues that add to, or change, the interface should
 be given the ~"UX" label. This will allow the UX team to provide input and guidance. You may
@@ -267,7 +266,7 @@ submitting your own, there's a good chance somebody else had the same issue or
 feature proposal. Show your support with an award emoji and/or join the
 discussion.
 
-Please submit bugs using the ['Bug' issue template](.gitlab/issue_templates/Bug.md) provided on the issue tracker.
+Please submit bugs using the ['Bug' issue template](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab/issue_templates/Bug.md) provided on the issue tracker.
 The text in the parenthesis is there to help you with what to include. Omit it
 when submitting the actual issue. You can copy-paste it and then edit as you
 see fit.
@@ -352,3 +351,7 @@ A recent example of this was the issue for
 [bringing the time tracking API to GitLab CE][time-tracking-issue].
 
 [time-tracking-issue]: https://gitlab.com/gitlab-org/gitlab-ce/issues/25517#note_20019084
+
+---
+
+[Return to Contributing documentation](index.md)

doc/development/contributing/merge_request_workflow.md

@@ -34,7 +34,7 @@ If you are new to GitLab development (or web development in general), see the
 some potentially easy issues.
 
 To start with GitLab development download the [GitLab Development Kit][gdk] and
-see the [Development section](doc/development/README.md) for some guidelines.
+see the [Development section](../README.md) for some guidelines.
 
 ### Merge request guidelines
 
@@ -81,9 +81,9 @@ request is as follows:
     beneath it to mark it resolved.
 1. If your MR touches code that executes shell commands, reads or opens files or
    handles paths to files on disk, make sure it adheres to the
-   [shell command guidelines](doc/development/shell_commands.md)
+   [shell command guidelines](../shell_commands.md)
 1. If your code creates new files on disk please read the
-   [shared files guidelines](doc/development/shared_files.md).
+   [shared files guidelines](../shared_files.md).
 1. When writing commit messages please follow
    [these](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
    [guidelines](http://chris.beams.io/posts/git-commit/).
@@ -92,7 +92,7 @@ request is as follows:
    to large changes in the MR, do this again once the review is complete.
 1. For more complex migrations, write tests.
 1. Merge requests **must** adhere to the [merge request performance
-   guidelines](doc/development/merge_request_performance_guidelines.md).
+   guidelines](../merge_request_performance_guidelines.md).
 1. For tests that use Capybara or PhantomJS, see this [article on how
    to write reliable asynchronous tests](https://robots.thoughtbot.com/write-reliable-asynchronous-integration-tests-with-capybara).
 
@@ -112,8 +112,7 @@ of the [Merge request coaches][team].
 Please ensure that your merge request meets the contribution acceptance criteria.
 
 When having your code reviewed and when reviewing merge requests please take the
-[code review guidelines](doc/development/code_review.md) into account.
-
+[code review guidelines](../code_review.md) into account.
 
 ### Contribution acceptance criteria
 
@@ -186,3 +185,7 @@ merge request:
 1. GitLab Development Kit https://gitlab.com/gitlab-org/gitlab-development-kit
 1. Test suite https://gitlab.com/gitlab-org/gitlab-ce/blob/master/scripts/prepare_build.sh
 1. Omnibus package creator https://gitlab.com/gitlab-org/omnibus-gitlab
+
+---
+
+[Return to Contributing documentation](index.md)