Add various sizes of Merge Requests to the dev fixtures to allow for easier manual performance testing while developing
<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=23529) </details> <!--IssueSummary end--> # Problem we're solving It's hard to catch performance degradations while developing features in dev due to the fake projects not having extreme (yet somwhat common) cases. To make it easier to catch performance degradations, we should have several sizes of MRs available in dev environment to test while developing new features. # Suggestion * Have one project dedicated to performance be created on every dev environment * Create several merge requests with real-world usage (see below) * Eventually this test project could be used to supply other examples to test other features but would be focused in performance (issues, boards, etc). # Why not the regular projects we have? Having this in a project makes performance more visibile to developers and not just when releases reach staging for QA. # Examples of MRs portraying real-world usage ``` SMALL MR 150 changes ~100 additions ~50 removals ~50 changes 10 resolved discussions 5 unresolved discussions - MEDIUM MR 1500 changes ~1000 additions ~500 removals ~500 changes 50 resolved discussions 20 unresolved discussions - LARGE MR 15000 changes ~10000 additions ~5000 removals ~5000 changes 150 resolved discussions 50 unresolved discussions ```
issue