diff options
Diffstat (limited to '.gitlab/merge_request_templates')
| -rw-r--r-- | .gitlab/merge_request_templates/Documentation.md | 69 | ||||
| -rw-r--r-- | .gitlab/merge_request_templates/Quarantine End to End Test.md | 2 | ||||
| -rw-r--r-- | .gitlab/merge_request_templates/Security Release.md | 4 |
3 files changed, 21 insertions, 54 deletions
diff --git a/.gitlab/merge_request_templates/Documentation.md b/.gitlab/merge_request_templates/Documentation.md index 9c6b5a73b4f..99ad233c7e0 100644 --- a/.gitlab/merge_request_templates/Documentation.md +++ b/.gitlab/merge_request_templates/Documentation.md @@ -13,62 +13,29 @@ <!-- Link related issues below. --> -## Author's checklist (required) +## Author's checklist - [ ] Follow the [Documentation Guidelines](https://docs.gitlab.com/ee/development/documentation/) and [Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/). -- If you have **Developer** permissions or higher: - - [ ] Ensure that the [product tier badge](https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#product-tier-badges) is added to doc's `h1`. - - [ ] Apply the ~documentation label, plus: - - The corresponding DevOps stage and group labels, if applicable. - - ~"development guidelines" when changing docs under `doc/development/*`, `CONTRIBUTING.md`, or `README.md`. - - ~"development guidelines" and ~"Documentation guidelines" when changing docs under `development/documentation/*`. - - ~"development guidelines" and ~"Description templates (.gitlab/\*)" when creating/updating issue and MR description templates. - - [ ] [Request a review](https://docs.gitlab.com/ee/development/code_review.html#dogfooding-the-reviewers-feature) - from the [designated Technical Writer](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments). +- [ ] Ensure that the [product tier badge](https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#product-tier-badges) is added to doc's `h1`. +- [ ] [Request a review](https://docs.gitlab.com/ee/development/code_review.html#dogfooding-the-reviewers-feature) based on the documentation page's metadata and [associated Technical Writer](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments). -/label ~documentation -/assign me - -Do not add the ~"feature", ~"frontend", ~"backend", ~"bug", or ~"database" labels if you are only updating documentation. These labels will cause the MR to be added to code verification QA issues. - -When applicable: - -- [ ] Update the [permissions table](https://docs.gitlab.com/ee/user/permissions.html). -- [ ] Link docs to and from the higher-level index page, plus other related docs where helpful. -- [ ] Add the [product tier badge](https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#product-tier-badges) accordingly. -- [ ] Add [GitLab's version history note(s)](https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#gitlab-versions). -- [ ] Add/update the [feature flag section](https://docs.gitlab.com/ee/development/documentation/feature_flags.html). +To avoid having this MR be added to code verification QA issues, don't add these labels: ~"feature", ~"frontend", ~"backend", ~"bug", or ~"database" ## Review checklist -All reviewers can help ensure accuracy, clarity, completeness, and adherence to the [Documentation Guidelines](https://docs.gitlab.com/ee/development/documentation/) and [Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/). - -**1. Primary Reviewer** - -* [ ] Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes. - -**2. Technical Writer** +Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on [Documentation Guidelines](https://docs.gitlab.com/ee/development/documentation/) and the [Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/). -- [ ] Technical writer review. If not requested for this MR, must be scheduled post-merge. To request for this MR, assign the writer listed for the applicable [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages). - - [ ] Ensure docs metadata are present and up-to-date. - - [ ] Ensure ~"Technical Writing" and ~"documentation" are added. - - [ ] Add the corresponding `docs::` [scoped label](https://gitlab.com/groups/gitlab-org/-/labels?subscribed=&search=docs%3A%3A). - - [ ] If working on UI text, add the corresponding `UI Text` [scoped label](https://gitlab.com/groups/gitlab-org/-/labels?subscribed=&search=ui+text). - - [ ] Add ~"tw::doing" when starting work on the MR. - - [ ] Add ~"tw::finished" if Technical Writing team work on the MR is complete but it remains open. +- [ ] If the content requires it, ensure the information is reviewed by a subject matter expert. +- Technical writer review items: + - [ ] Ensure docs metadata is present and up-to-date. + - [ ] Ensure the appropriate [labels](https://about.gitlab.com/handbook/engineering/ux/technical-writing/workflow/#labels) are added to this MR. + - If relevant to this MR, ensure [content topic type](https://docs.gitlab.com/ee/development/documentation/structure.html) principles are in use, including: + - [ ] The headings should be something you'd do a Google search for. Instead of `Default behavior`, say something like `Default behavior when you close an issue`. + - [ ] The headings (other than the page title) should be active. Instead of `Configuring GDK`, say something like `Configure GDK`. + - [ ] Any task steps should be written as a numbered list. + - If the content still needs to be edited for topic types, you can create a follow-up issue with the ~"docs-technical-debt" label. +- [ ] Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review. +- [ ] Ensure a release milestone is set. -For more information about labels, see [Technical Writing workflows - Labels](https://about.gitlab.com/handbook/engineering/ux/technical-writing/workflow/#labels). - -For suggestions that you are confident don't need to be reviewed, change them locally -and push a commit directly to save others from unneeded reviews. For example: - -- Clear typos, like `this is a typpo`. -- Minor issues, like single quotes instead of double quotes, Oxford commas, and periods. - -For more information, see our documentation on [Merging a merge request](https://docs.gitlab.com/ee/development/code_review.html#merging-a-merge-request). - -**3. Maintainer** - -1. [ ] Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review. -1. [ ] Ensure a release milestone is set. -1. [ ] If there has not been a technical writer review, [create an issue for one using the Doc Review template](https://gitlab.com/gitlab-org/gitlab/issues/new?issuable_template=Doc%20Review). +/label ~documentation +/assign me diff --git a/.gitlab/merge_request_templates/Quarantine End to End Test.md b/.gitlab/merge_request_templates/Quarantine End to End Test.md index 5794a62df96..772167af3e9 100644 --- a/.gitlab/merge_request_templates/Quarantine End to End Test.md +++ b/.gitlab/merge_request_templates/Quarantine End to End Test.md @@ -21,7 +21,7 @@ the noise (due to constantly failing tests, flaky tests, and so on) so that new - [ ] Quarantine test check-list - [ ] Follow the [Quarantining Tests guide](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantining-tests). - [ ] Confirm the test has a [`quarantine:` tag with the specified quarantine type](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantined-test-types). - - [ ] Note if the test should be [quarantined for a specific environment](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/environment_selection.html#quarantining-a-test-for-a-specific-environment). + - [ ] Note if the test should be [quarantined for a specific environment](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/execution_context_selection.html#quarantine-a-test-for-a-specific-environment). - [ ] Dequarantine test check-list - [ ] Follow the [Dequarantining Tests guide](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#dequarantining-tests). - [ ] Confirm the test consistently passes on the target GitLab environment(s). diff --git a/.gitlab/merge_request_templates/Security Release.md b/.gitlab/merge_request_templates/Security Release.md index 77e8718c34f..33c0a5b98a8 100644 --- a/.gitlab/merge_request_templates/Security Release.md +++ b/.gitlab/merge_request_templates/Security Release.md @@ -30,8 +30,8 @@ See [the general developer security release guidelines](https://gitlab.com/gitla ## Maintainer checklist -- [ ] Correct milestone is applied and the title is matching across all backports -- [ ] Assigned to `@gitlab-release-tools-bot` with passing CI pipelines and **when all backports including the MR targeting master are ready.** +- [ ] Correct milestone is applied and the title is matching across all backports. +- [ ] Assigned to `@gitlab-release-tools-bot` with passing CI pipelines. /label ~security |