Move limit content from Performance guidelines to it's own item in DoD

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 & 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/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.
\ No newline at end of file

doc/development/merge_request_performance_guidelines.md

@@ -446,48 +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