Merge branch 'samgratelimitdod' into 'master'

Add Limits to Definition of Done

See merge request gitlab-org/gitlab!80243

doc/development/contributing/merge_request_workflow.md

@@ -266,6 +266,7 @@ requirements.
    again.
 1. [Performance guidelines](../merge_request_performance_guidelines.md) have been followed.
 1. [Secure coding guidelines](https://gitlab.com/gitlab-com/gl-security/security-guidelines) have been followed.
+1. [Application and rate limit guidelines](../merge_request_application_and_rate_limit_guidelines.md) have been followed.
 1. [Documented](../documentation/index.md) in the `/doc` directory.
 1. [Changelog entry added](../changelog.md), if necessary.
 1. Reviewed by relevant reviewers, and all concerns are addressed for Availability, Regressions, and Security. Documentation reviews should take place as soon as possible, but they should not block a merge request.

doc/development/merge_request_application_and_rate_limit_guidelines.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Application and rate limit guidelines
+
+GitLab, like most large applications, enforces limits within certain features.
+The absences of limits can affect security, performance, data, or could even
+exhaust the allocated resources for the application. 
+
+Every new feature should have safe usage limits included in its implementation.
+Limits are applicable for:
+
+- System-level resource pools such as API requests, SSHD connections, database connections, storage, and so on.
+- Domain-level objects such as CI minutes, groups, sign-in attempts, and so on.
+
+## When limits are required
+
+1. Limits are required if the absence of the limit matches severity 1 - 3 in the severity definitions for [limit-related bugs](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#limit-related-bugs).
+1. [GitLab application limits](../administration/instance_limits.md) documentation must be updated anytime limits are added, removed, or updated.
+
+## Additional reading
+
+- Existing [GitLab application limits](../administration/instance_limits.md) 
+- Product processes: [introducing application limits](https://about.gitlab.com/handbook/product/product-processes/#introducing-application-limits)
+- Development docs: [guide for adding application limits](application_limits.md)

doc/development/merge_request_performance_guidelines.md

@@ -446,49 +446,6 @@ that accepts an upper limit of counting rows.
 In some cases it's desired that badge counters are loaded asynchronously.
 This can speed up the initial page load and give a better user experience overall.
 
-## Application/misuse limits
-
-Every new feature should have safe usage quotas introduced.
-The quota should be optimised to a level that we consider the feature to
-be performant and usable for the user, but **not limiting**.
-
-**We want the features to be fully usable for the users.**
-**However, we want to ensure that the feature continues to perform well if used at its limit**
-**and it doesn't cause availability issues.**
-
-Consider that it's always better to start with some kind of limitation,
-instead of later introducing a breaking change that would result in some
-workflows breaking.
-
-The intent is to provide a safe usage pattern for the feature,
-as our implementation decisions are optimised for the given data set.
-Our feature limits should reflect the optimisations that we introduced.
-
-The intent of quotas could be different:
-
-1. We want to provide higher quotas for higher tiers of features:
-   we want to provide on GitLab.com more capabilities for different tiers,
-1. We want to prevent misuse of the feature: someone accidentally creates
-   10000 deploy tokens, because of a broken API script,
-1. We want to prevent abuse of the feature: someone purposely creates
-   a 10000 pipelines to take advantage of the system.
-
-Examples:
-
-1. Pipeline Schedules: It's very unlikely that user wants to create
-   more than 50 schedules.
-   In such cases it's rather expected that this is either misuse
-   or abuse of the feature. Lack of the upper limit can result
-   in service degradation as the system tries to process all schedules
-   assigned the project.
-
-1. GitLab CI/CD includes: We started with the limit of maximum of 50 nested includes.
-   We understood that performance of the feature was acceptable at that level.
-   We received a request from the community that the limit is too small.
-   We had a time to understand the customer requirement, and implement an additional
-   fail-safe mechanism (time-based one) to increase the limit 100, and if needed increase it
-   further without negative impact on availability of the feature and GitLab.
-
 ## Usage of feature flags
 
 Each feature that has performance critical elements or has a known performance deficiency