## Reasoning In https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/952, I'm using almost the same code for a non-reactive policy as from a reactive policy: https://gitlab.com/gitlab-org/quality/triage-serverless/-/merge_requests/171. It made me realize that, reactive and non-reactive policies can be very similar when their "actions" are defined in Ruby. If we'd have a single `triage-ops` project that handle both reactive and non-reactive policies, we could share such Ruby classes. Also, from the perspective of someone outside of the team, it just makes more sense to have a single `triage-ops` project to contribute to. Having a single project would also be a step forward https://gitlab.com/gitlab-org/quality/triage-serverless/-/issues/62. ## Plan 1. [x] Prepare MR for tools/projects/documentation (e.g. handbook, documentation) that rely on `triage-serverless` for the transition 1. [x] Prepare to migrate `triage-serverless` code to `triage-ops` 1. [x] Prepare to migrate `triage-serverless` CI config to `triage-ops` 1. [x] Prepare to migrate `triage-serverless` cluster to `triage-ops` 1. [x] Prepare to migrate `triage-serverless` open issues to `triage-ops` 1. [Before change] Communicate - [x] Slack `#development`, `#product`: https://gitlab.slack.com/archives/C02PF508L/p1637145464266000 1. [x] Migrate `triage-serverless` CI config, code, cluster, and issues 1. [x] Replicate project variables from https://gitlab.com/gitlab-org/quality/triage-serverless/-/settings/ci_cd 1. [x] Deprecate `triage-serverless` and update its README. Block new issues, MRs, and pushes/merges. 1. [x] Update tools/projects/documentation that depends on `triage-serverless` 1. [After change] Communicate - [x] Engineering week in review