diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-04-20 10:00:54 +0000 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-04-20 10:00:54 +0000 |
commit | 3cccd102ba543e02725d247893729e5c73b38295 (patch) | |
tree | f36a04ec38517f5deaaacb5acc7d949688d1e187 /doc/development/contributing | |
parent | 205943281328046ef7b4528031b90fbda70c75ac (diff) | |
download | gitlab-ce-3cccd102ba543e02725d247893729e5c73b38295.tar.gz |
Add latest changes from gitlab-org/gitlab@14-10-stable-eev14.10.0-rc42
Diffstat (limited to 'doc/development/contributing')
-rw-r--r-- | doc/development/contributing/design.md | 8 | ||||
-rw-r--r-- | doc/development/contributing/issue_workflow.md | 6 | ||||
-rw-r--r-- | doc/development/contributing/merge_request_workflow.md | 8 | ||||
-rw-r--r-- | doc/development/contributing/verify/index.md | 5 |
4 files changed, 11 insertions, 16 deletions
diff --git a/doc/development/contributing/design.md b/doc/development/contributing/design.md index 463a7ee0e0b..def39a960d8 100644 --- a/doc/development/contributing/design.md +++ b/doc/development/contributing/design.md @@ -49,7 +49,7 @@ Check these aspects both when _designing_ and _reviewing_ UI changes. ### Visual design Check visual design properties using your browser's _elements inspector_ ([Chrome](https://developer.chrome.com/docs/devtools/css/), -[Firefox](https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector/How_to/Open_the_Inspector)). +[Firefox](https://firefox-source-docs.mozilla.org/devtools-user/page_inspector/how_to/open_the_inspector/index.html)). - Use recommended [colors](https://design.gitlab.com/product-foundations/colors/) and [typography](https://design.gitlab.com/product-foundations/type-fundamentals/). @@ -66,7 +66,7 @@ Check visual design properties using your browser's _elements inspector_ ([Chrom Check states using your browser's _styles inspector_ to toggle CSS pseudo-classes like `:hover` and others ([Chrome](https://developer.chrome.com/docs/devtools/css/reference/#pseudo-class), -[Firefox](https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector/How_to/Examine_and_edit_CSS#viewing_common_pseudo-classes)). +[Firefox](https://firefox-source-docs.mozilla.org/devtools-user/page_inspector/how_to/examine_and_edit_css/index.html#viewing-common-pseudo-classes)). - Account for all applicable states ([error](https://design.gitlab.com/content/error-messages), rest, loading, focus, hover, selected, disabled). @@ -78,7 +78,7 @@ like `:hover` and others ([Chrome](https://developer.chrome.com/docs/devtools/cs ### Responsive Check responsive behavior using your browser's _responsive mode_ ([Chrome](https://developer.chrome.com/docs/devtools/device-mode/#viewport), -[Firefox](https://developer.mozilla.org/en-US/docs/Tools/Responsive_Design_Mode)). +[Firefox](https://firefox-source-docs.mozilla.org/devtools-user/responsive_design_mode/index.html)). - Account for resizing, collapsing, moving, or wrapping of elements across all breakpoints (even if larger viewports are prioritized). @@ -99,7 +99,7 @@ Check accessibility using your browser's _accessibility inspector_ ([Chrome](htt When the design is ready, _before_ starting its implementation: - Share design specifications in the related issue, preferably through a [Figma link](https://help.figma.com/hc/en-us/articles/360040531773-Share-Files-with-anyone-using-Link-Sharing#Copy_links) - link or [GitLab Designs feature](../../user/project/issues/design_management.md#the-design-management-section). + link or [GitLab Designs feature](../../user/project/issues/design_management.md). See [when you should use each tool](https://about.gitlab.com/handbook/engineering/ux/product-designer/#deliver). - Document user flow and states (for example, using [Mermaid flowcharts in Markdown](../../user/markdown.md#mermaid)). - Document animations and transitions. diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md index 4db686b9b1e..fe1549e7f34 100644 --- a/doc/development/contributing/issue_workflow.md +++ b/doc/development/contributing/issue_workflow.md @@ -31,11 +31,7 @@ on those issues. Please select someone with relevant experience from the If there is nobody mentioned with that expertise, look in the commit history for the affected files to find someone. -We also use [GitLab Triage](https://gitlab.com/gitlab-org/gitlab-triage) to automate -some triaging policies. This is currently set up as a scheduled pipeline -(`https://gitlab.com/gitlab-org/quality/triage-ops/-/pipeline_schedules/10512/edit`, -must have at least the Developer role in the project) running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops) -project. +We also have triage automation in place, described [in our handbook](https://about.gitlab.com/handbook/engineering/quality/triage-operations/). ## Labels diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md index a9b4d13ab06..5ed0885eed9 100644 --- a/doc/development/contributing/merge_request_workflow.md +++ b/doc/development/contributing/merge_request_workflow.md @@ -144,7 +144,7 @@ document from the Kubernetes team also has some great points regarding this. ### Commit messages guidelines -Commit messages should follow the guidelines below, for reasons explained by Chris Beams in [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/): +Commit messages should follow the guidelines below, for reasons explained by Chris Beams in [How to Write a Git Commit Message](https://cbea.ms/git-commit/): - The commit subject and body must be separated by a blank line. - The commit subject must start with a capital letter. @@ -203,7 +203,7 @@ Example commit message template that can be used on your machine that embodies t # Do not use Emojis # Use the body to explain what and why vs. how # Can use multiple lines with "-" for bullet points in body -# For more information: https://chris.beams.io/posts/git-commit/ +# For more information: https://cbea.ms/git-commit/ # -------------------- ``` @@ -286,8 +286,8 @@ requirements. ### Production use 1. Confirmed to be working in staging before implementing the change in production, where possible. -1. Confirmed to be working in the production with no new [Sentry](https://about.gitlab.com/handbook/engineering/#sentry) errors after the contribution is deployed. -1. Confirmed that the [rollout plan](https://about.gitlab.com/handbook/engineering/development/processes/rollout-plans) has been completed. +1. Confirmed to be working in the production with no new [Sentry](https://about.gitlab.com/handbook/engineering/monitoring/#sentry) errors after the contribution is deployed. +1. Confirmed that the [rollout plan](https://about.gitlab.com/handbook/engineering/development/processes/rollout-plans/) has been completed. 1. If there is a performance risk in the change, I have analyzed the performance of the system before and after the change. 1. *If the merge request uses feature flags, per-project or per-group enablement, and a staged rollout:* - Confirmed to be working on GitLab projects. diff --git a/doc/development/contributing/verify/index.md b/doc/development/contributing/verify/index.md index a2bb0eca733..828eb0a9598 100644 --- a/doc/development/contributing/verify/index.md +++ b/doc/development/contributing/verify/index.md @@ -55,7 +55,7 @@ and they serve us and our users well. Some examples of these principles are that - Feedback needs to be available when a user needs it and data can not disappear unexpectedly when engineers need it. - It all doesn’t matter if the platform is not secure and we are leaking credentials or secrets. -- When a user provides a set of preconditions in a form of CI/CD configuration, the result should be deterministic each time a pipeline runs, because otherwise the platform might not be trustworthy. +- When a user provides a set of preconditions in a form of CI/CD configuration, the result should be deterministic each time a pipeline runs, because otherwise the platform might not be trustworthy. - If it is fast, simple to use and has a great UX it will serve our users well. ## Building things in Verify @@ -189,8 +189,7 @@ Slack channel (GitLab team members only). After your merge request is merged by a maintainer, it is time to release it to users and the wider community. We usually do this with feature flags. While not every merge request needs a feature flag, most merge -requests in Verify should have feature flags. [**TODO** link to docs about what -needs a feature flag and what doesn’t]. +requests in Verify should have [feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags). If you already follow the advice on this page, you probably already have a few metrics and perhaps a few loggers added that make your new code observable |