diff options
Diffstat (limited to 'doc/development/contributing')
| -rw-r--r-- | doc/development/contributing/design.md | 4 | ||||
| -rw-r--r-- | doc/development/contributing/index.md | 5 | ||||
| -rw-r--r-- | doc/development/contributing/issue_workflow.md | 2 | ||||
| -rw-r--r-- | doc/development/contributing/merge_request_workflow.md | 5 | ||||
| -rw-r--r-- | doc/development/contributing/verify/index.md | 4 |
5 files changed, 10 insertions, 10 deletions
diff --git a/doc/development/contributing/design.md b/doc/development/contributing/design.md index def39a960d8..7f5c800216a 100644 --- a/doc/development/contributing/design.md +++ b/doc/development/contributing/design.md @@ -117,7 +117,7 @@ At any moment, but usually _during_ or _after_ the design's implementation: for additions or enhancements to the design system. - Create issues with the [`~UX debt`](issue_workflow.md#technical-and-ux-debt) label for intentional deviations from the agreed-upon UX requirements due to - time or feasibility challenges, linking back to the corresponding issue(s) or - MR(s). + time or feasibility challenges, linking back to the corresponding issues or + merge requests. - Create issues for [feature additions or enhancements](issue_workflow.md#feature-proposals) outside the agreed-upon UX requirements to avoid scope creep. diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md index ea54f36a7e5..8a4b06840a4 100644 --- a/doc/development/contributing/index.md +++ b/doc/development/contributing/index.md @@ -33,9 +33,8 @@ GitLab Inc engineers should refer to the [engineering workflow document](https:/ ## Security vulnerability disclosure -Report suspected security vulnerabilities in private to -`support@gitlab.com`, also see the -[disclosure section on the GitLab.com website](https://about.gitlab.com/security/disclosure/). +Report suspected security vulnerabilities by following the +[disclosure process on the GitLab.com website](https://about.gitlab.com/security/disclosure/). WARNING: Do **NOT** create publicly viewable issues for suspected security vulnerabilities. diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md index fe1549e7f34..97c8c179e09 100644 --- a/doc/development/contributing/issue_workflow.md +++ b/doc/development/contributing/issue_workflow.md @@ -108,7 +108,7 @@ Group labels specify which [groups](https://about.gitlab.com/company/team/struct It's highly recommended to add a group label, as it's used by our triage automation to -[infer the correct stage label](https://about.gitlab.com/handbook/engineering/quality/triage-operations/#auto-labelling-of-issues). +[infer the correct stage label](https://about.gitlab.com/handbook/engineering/quality/triage-operations/#auto-labelling-of-issues-and-merge-requests). #### Naming and color convention diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md index 5ed0885eed9..ee1ed744cd4 100644 --- a/doc/development/contributing/merge_request_workflow.md +++ b/doc/development/contributing/merge_request_workflow.md @@ -53,7 +53,7 @@ request is as follows: 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), 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. Push the commits to your working branch in your fork. 1. Submit a merge request (MR) to the `main` branch in the main GitLab project. 1. Your merge request needs at least 1 approval, but depending on your changes you might need additional approvals. Refer to the [Approval guidelines](../code_review.md#approval-guidelines). @@ -65,7 +65,7 @@ request is as follows: template already provided in the "Description" field. 1. If you are contributing documentation, choose `Documentation` from the "Choose a template" menu and fill in the description according to the template. - 1. Use the syntax `Solves #XXX`, `Closes #XXX`, or `Refs #XXX` to mention the issue(s) your merge + 1. Use the syntax `Solves #XXX`, `Closes #XXX`, or `Refs #XXX` to mention the issues your merge request addresses. Referenced issues do not [close automatically](../../user/project/issues/managing_issues.md#closing-issues-automatically). You must close them manually once the merge request is merged. 1. The MR must include *Before* and *After* screenshots if UI changes are made. @@ -81,6 +81,7 @@ request is as follows: 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](../shell_commands.md) +1. [Code changes should include observability instrumentation](../code_review.md#observability-instrumentation). 1. If your code needs to handle file storage, see the [uploads documentation](../uploads/index.md). 1. If your merge request adds one or more migrations, make sure to execute all migrations on a fresh database before the MR is reviewed. If the review leads diff --git a/doc/development/contributing/verify/index.md b/doc/development/contributing/verify/index.md index 828eb0a9598..01aacffd00f 100644 --- a/doc/development/contributing/verify/index.md +++ b/doc/development/contributing/verify/index.md @@ -231,5 +231,5 @@ building medical, aviation, and automotive software. Continuous Integration is a mission critical part of software engineering. When you are working on a subsystem for pipeline processing and transitioning -CI/CD statuses, request an additional review from a domain expert and hold -others accountable for doing the same. +CI/CD statuses, request an additional opinion on the design from a domain expert +as early as possible and hold others accountable for doing the same. |